[Proj] Passing 64-bit floats to proj with -b option works for some numbers but not others

[Jason Roberts]

PROJ folks,

 

I am trying to invoke proj as a child process using the -b option, pass
binary 64-bit floats to stdin, and receive binary 64-bit floats from stdout:

 

proj -b +proj=merc +ellps=WGS84

 

I have discovered that I can successfully project the point 37.782 0.0 but
not the point 37.783 0.0. When I write the first point to stdin (in radians,
of course), proj responds by writing 16 bytes to stdout. This is the
projected point. But when I write the second point, proj does not write
anything to stdout. I have reproduced the problem on a Windows XP machine
with a Pentium M and a Windows Vista machine with a Core 2 T74000. I am
using ftp://ftp.remotesensing.org/proj/proj446_win32_bin.zip.

 

Can anyone explain why I can project one point but not the other? If this is
a bug in proj, can you fix it? Thanks very much for any help anyone can
provide. If it is a bug and no fix is possible, I would suggest that the -b
or -i options not be used by anyone unless someone can explain the
circumstances in which they may be safely used.

 

Here is a detailed demonstration of the problem. First, I can successfully
project both points if I invoke proj in normal mode (not using -b):

 

C:\temp2>proj +proj=merc +ellps=WGS84

37.782 0.0

4205873.00      0.00

37.783 0.0

4205984.32      0.00

 

In order to use the -b option, it is necessary to pass in radians. I wrote a
C++ program, compiled with Visual Studio 2005 as a Win32 console
application, to convert to radians and display the hex values of the 64-bit
float representations:

 

#include <stdio.h>

 

void main()

{

    double value = 3.14159265358979323846 / 180.0 * 37.782;

    unsigned char *p = (unsigned char *)&value;

    printf("value = %.17f (%02X %02X %02X %02X %02X %02X %02X %02X)\n",
value, p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7]);

    value = 3.14159265358979323846 / 180.0 * 37.783;

    printf("value = %.17f (%02X %02X %02X %02X %02X %02X %02X %02X)\n",
value, p[0], p[1], p[2], p[3], p[4], p[5], p[6], p[7]);

}

 

This produced the output:

 

value = 0.65942029798849755 (C6 BB C5 98 F8 19 E5 3F)

value = 0.65943775128101756 (F9 FD EF 32 1D 1A E5 3F)

 

As an aside, because I ultimately want to invoke proj from Python, I did the
same thing in Python 2.5, to verify that Python and C++ produced the same
representations:

 

>>> import array, math

>>> ' '.join(map(hex, map(ord, array.array('d',
[math.radians(37.782)]).tostring()))).replace('0x', '').upper()

'C6 BB C5 98 F8 19 E5 3F'

>>> ' '.join(map(hex, map(ord, array.array('d',
[math.radians(37.783)]).tostring()))).replace('0x', '').upper()

'F9 FD EF 32 1D 1A E5 3F'

 

Using a hex editor, I wrote the binary values for the two points to two
16-byte files, 37.782.bin and 37.783.bin. Note that the 64-bit float
representation of 0.0 is 0x0000000000000000.

 

C:\temp2>hexdump 37.782.bin

HEXDUMP of Mon, 13 Jun 2005, copyright (c) 2005 by Rich Pasco

C:\temp2\37.782.bin  16 bytes    9/26/2007   9:22:50

 

          -0 -1 -2 -3  -4 -5 -6 -7  -8 -9 -A -B  -C -D -E -F

 

00000000- C6 BB C5 98  F8 19 E5 3F  00 00 00 00  00 00 00 00
[.......?........]

 

C:\temp2>hexdump 37.783.bin

HEXDUMP of Mon, 13 Jun 2005, copyright (c) 2005 by Rich Pasco

C:\temp2\37.783.bin  16 bytes    9/26/2007   9:22:56

 

          -0 -1 -2 -3  -4 -5 -6 -7  -8 -9 -A -B  -C -D -E -F

 

00000000- F9 FD EF 32  1D 1A E5 3F  00 00 00 00  00 00 00 00
[...2...?........]

 

I verified that I could use the -i option with O/S redirection to pass in
37.782.bin and get the expected result:

 

C:\temp2>proj -i +proj=merc +ellps=WGS84 < 37.782.bin

4205873.00      0.00

 

But now, when I pass in 37.783.bin, proj does not write anything to stdout:

 

C:\temp2>proj -i +proj=merc +ellps=WGS84 < 37.783.bin

 

When I invoke it from a Python program using the -b option, the same
situations result (except the output for the first point is 16 bytes and the
second point is nothing). For brevity, I'm not including that program here.

 

Again, thanks for your help,

 

Jason

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20071001/42ff2ac7/attachment.html