NAD problems on OSX 10.5 Leopard

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

NAD problems on OSX 10.5 Leopard

William Kyngesburye
This is an odd one.  On OSX 10.5 (Leopard), as a 64bit binary PROJ/
cs2cs correctly translates betwen NAD27 and NAD83.  But, as a 32bit  
binary it translates in the opposite direction.  The OSX 10.4 (Tiger)  
build (32bits-only) also correctly translates datums (ie, it's the  
same as the 64bit translation).

$ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
-118 38
118d0'3.385"W 37d59'59.751"N 0.000

$ arch -i386 cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong  
+datum=NAD83
-118 38
117d59'59.748"W 38d0'3.385"N 0.000


The Tiger binary, even running on Leopard gets the translation  
correct, so I wonder if something is happening in the compilation.

long's can be trouble, since on 32bit OSX they are 32bit, but on 64bit  
OSX they are 64bit.  Looking at nad2bin (and a few library sources), I  
see that longs are used in the NAD tables (lam and phi), so the NAD  
binary files are getting built with 64bit longs, then the 32bit PROJ  
is trying to read 32bit longs.

Are the NAD tables meant to always be 64bit longs?  Should long long  
be used instead, to guarantee 64bit longs, or maybe they should be  
configured?


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

Frank Warmerdam
William Kyngesburye wrote:

> This is an odd one.  On OSX 10.5 (Leopard), as a 64bit binary PROJ/cs2cs
> correctly translates betwen NAD27 and NAD83.  But, as a 32bit binary it
> translates in the opposite direction.  The OSX 10.4 (Tiger) build
> (32bits-only) also correctly translates datums (ie, it's the same as the
> 64bit translation).
>
> $ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
> -118 38
> 118d0'3.385"W    37d59'59.751"N 0.000
>
> $ arch -i386 cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong
> +datum=NAD83
> -118 38
> 117d59'59.748"W    38d0'3.385"N 0.000
>
>
> The Tiger binary, even running on Leopard gets the translation correct,
> so I wonder if something is happening in the compilation.
>
> long's can be trouble, since on 32bit OSX they are 32bit, but on 64bit
> OSX they are 64bit.  Looking at nad2bin (and a few library sources), I
> see that longs are used in the NAD tables (lam and phi), so the NAD
> binary files are getting built with 64bit longs, then the 32bit PROJ is
> trying to read 32bit longs.
>
> Are the NAD tables meant to always be 64bit longs?  Should long long be
> used instead, to guarantee 64bit longs, or maybe they should be configured?

William,

Pretty bizzare behavior.

The nadcon style datum shift files are expected to be platform specific and
that means a 32bit generated datum shift file cannot be used by 64bit
program safely (amoung other things).  I *suspect* this is at the root
of your problem.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

William Kyngesburye
On Jan 15, 2008, at 8:31 PM, Frank Warmerdam wrote:

> William Kyngesburye wrote:
>> This is an odd one.  On OSX 10.5 (Leopard), as a 64bit binary PROJ/
>> cs2cs correctly translates betwen NAD27 and NAD83.  But, as a 32bit  
>> binary it translates in the opposite direction.  The OSX 10.4  
>> (Tiger) build (32bits-only) also correctly translates datums (ie,  
>> it's the same as the 64bit translation).
>> $ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
>> -118 38
>> 118d0'3.385"W    37d59'59.751"N 0.000
>> $ arch -i386 cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong  
>> +datum=NAD83
>> -118 38
>> 117d59'59.748"W    38d0'3.385"N 0.000
>> The Tiger binary, even running on Leopard gets the translation  
>> correct, so I wonder if something is happening in the compilation.
>> long's can be trouble, since on 32bit OSX they are 32bit, but on  
>> 64bit OSX they are 64bit.  Looking at nad2bin (and a few library  
>> sources), I see that longs are used in the NAD tables (lam and  
>> phi), so the NAD binary files are getting built with 64bit longs,  
>> then the 32bit PROJ is trying to read 32bit longs.
>> Are the NAD tables meant to always be 64bit longs?  Should long  
>> long be used instead, to guarantee 64bit longs, or maybe they  
>> should be configured?
>
> William,
>
> Pretty bizzare behavior.
>
> The nadcon style datum shift files are expected to be platform  
> specific and
> that means a 32bit generated datum shift file cannot be used by 64bit
> program safely (amoung other things).  I *suspect* this is at the root
> of your problem.

I poked around to try to understand it better.  The lam/laml/phi/phil  
that are longs, appear to be only used in reading the text source  
lla's.  The CTABLE that is written in binary form uses only doubles,  
floats and ints, which don't change between 32 and 64bit OSX.  At  
least, the number of bytes used doesn't change - would the binary  
format be different?  That doesn't make sense.

Comparing the binary files, on 64bits and 32bits, Tiger and Leopard:

64bit-Leo file
32bit-Tiger file
32bit-Leo file

The headers are all exactly the same - the ints and doubles for the  
lower-left coord, cell size, and grid size match in all files.  The  
floats for the conversion matrix don't match, immediately.  There are  
4 bytes in the 32bit files, and 8 bytes in the 64bit files, before the  
matrix that I can't account for.  After that the matrixes of floats  
match.  The calculated size of the matrix from the grid size matches  
the byte count after those mystery bytes.

Did I miss something in the CTABLE (pardon my ignorance here):

struct CTABLE {
        char id[MAX_TAB_ID]; /* ascii info */
        LP ll;      /* lower left corner coordinates */
        LP del;     /* size of cells */
        ILP lim;    /* limits of conversion matrix */
        FLP *cvs;   /* conversion matrix */
};

Is maybe the bulk fwrite of *cvs prepending something?  It looks like  
an integer of some sort.  And then the nad_init functions are reading  
them as part of the matrix float data.

So, I manually deleted those extra bytes.  Now 32bit and 64bit  
translations match.  And make more sense really (if I understand in  
right, datum transforms give me a headache) - when translating the  
datum of a latlong coordinate, the latlong doesn't actually change,  
it's the projected coordinate that changes.

$ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
-118 38
118dW 38dN 0.000

$ arch -i386 cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong  
+datum=NAD83
-118 38
118dW 38dN 0.000

Or, bad NAD file:

$ cs2cs +init=EPSG:26711 +to +init=EPSG:26911412199.39 4206081.09
412118.95 4206279.97 0.00

$ arch -i386 cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412208.85 4206391.01 0.00

and good NAD file:

$ cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412201.58 4206286.75 0.00

$ arch -i386 cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412201.58 4206286.75 0.00


I dug back into my ancient binaries and it's been like this since I  
started packaging PROJ and friends!

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the  
past isn't a fiction designed to account for the discrepancy between  
my immediate physical sensations and my state of mind?"

- The Ruler of the Universe


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

Frank Warmerdam
William Kyngesburye wrote:

> I poked around to try to understand it better.  The lam/laml/phi/phil
> that are longs, appear to be only used in reading the text source
> lla's.  The CTABLE that is written in binary form uses only doubles,
> floats and ints, which don't change between 32 and 64bit OSX.  At least,
> the number of bytes used doesn't change - would the binary format be
> different?  That doesn't make sense.
>
> Comparing the binary files, on 64bits and 32bits, Tiger and Leopard:
>
> 64bit-Leo file
> 32bit-Tiger file
> 32bit-Leo file
>
> The headers are all exactly the same - the ints and doubles for the
> lower-left coord, cell size, and grid size match in all files.  The
> floats for the conversion matrix don't match, immediately.  There are 4
> bytes in the 32bit files, and 8 bytes in the 64bit files, before the
> matrix that I can't account for.  After that the matrixes of floats
> match.  The calculated size of the matrix from the grid size matches the
> byte count after those mystery bytes.

William,

I believe the difference is in alignment within the structure between
32bit and 64bit systems.  Because the memory image of the structure is
dumped to disk, the file access is very sensitive to differences in
how fields are packed into structures in memory.  This can vary based
on many things.

Really, my preference would be to completely get rid of nadcon style
binary files in favor of NTv1 or NTv2 style files which are platform
independent but doing so would require more work than I'm willing
to invest at this time.

In the meantime, I imagine it would not be too hard to alter the nadcon
reading and writing functions to use some sort of consistent binary
file.  But I'm even to lazy to attempt that just now.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

William Kyngesburye
On Jan 15, 2008, at 10:42 PM, Frank Warmerdam wrote:

> William,
>
> I believe the difference is in alignment within the structure between
> 32bit and 64bit systems.  Because the memory image of the structure is
> dumped to disk, the file access is very sensitive to differences in
> how fields are packed into structures in memory.  This can vary based
> on many things.
>
> Really, my preference would be to completely get rid of nadcon style
> binary files in favor of NTv1 or NTv2 style files which are platform
> independent but doing so would require more work than I'm willing
> to invest at this time.
>
> In the meantime, I imagine it would not be too hard to alter the  
> nadcon
> reading and writing functions to use some sort of consistent binary
> file.  But I'm even to lazy to attempt that just now.

Ah, the extra bytes are pointer for the *cvs part of the CTABLE  
structure?

   fwrite(ct.cvs, tsize, 1, stdout)


Or is it written as part of the &ct fwrite?

   fwrite(&ct, sizeof(ct), 1, stdout)

How about:

   fwrite(ct.id, sizeof(ct.id), 1, stdout)
   fwrite(ct.ll, sizeof(ct.ll), 1, stdout)
   fwrite(ct.del, sizeof(ct.del), 1, stdout)
   fwrite(ct.lim, sizeof(ct.lim), 1, stdout)

This way it skips the pointer part of ct.cvs.


On the other side, though, with the current extra bytes, the fseek()  
in nad_ctable_load() doesn't seem to be skipping over those bytes, so  
they are read as part of the data.  Could it be due to sizeof(ct) used  
in nad2bin, but sizeof(struct CTABLE) used in nad_ctable_load()?  Or  
an fseek bug?


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the  
past isn't a fiction designed to account for the discrepancy between  
my immediate physical sensations and my state of mind?"

- The Ruler of the Universe


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

William Kyngesburye
On Jan 15, 2008, at 11:30 PM, William Kyngesburye wrote:

> On Jan 15, 2008, at 10:42 PM, Frank Warmerdam wrote:
>
>> In the meantime, I imagine it would not be too hard to alter the  
>> nadcon
>> reading and writing functions to use some sort of consistent binary
>> file.  But I'm even to lazy to attempt that just now.
>
> Ah, the extra bytes are pointer for the *cvs part of the CTABLE  
> structure?
>
>  fwrite(ct.cvs, tsize, 1, stdout)
>
I guess not, since...

>
> Or is it written as part of the &ct fwrite?
>
>  fwrite(&ct, sizeof(ct), 1, stdout)
>
> How about:
>
>  fwrite(ct.id, sizeof(ct.id), 1, stdout)
>  fwrite(ct.ll, sizeof(ct.ll), 1, stdout)
>  fwrite(ct.del, sizeof(ct.del), 1, stdout)
>  fwrite(ct.lim, sizeof(ct.lim), 1, stdout)
>
> This way it skips the pointer part of ct.cvs.
>
This works:

if (fwrite(&ct.id, sizeof(ct.id), 1, stdout) != 1 ||
        fwrite(&ct.ll, sizeof(ct.ll), 1, stdout) != 1 ||
        fwrite(&ct.del, sizeof(ct.del), 1, stdout) != 1 ||
        fwrite(&ct.lim, sizeof(ct.lim), 1, stdout) != 1 ||
        fwrite(ct.cvs, tsize, 1, stdout) != 1) {
        fprintf(stderr, "output failure\n");
        exit(2);
}

This creates a file consistent enough at least for different  
architectures on OSX.  Combined with my endian patches, which forces  
the files to be little-endian on both PPC and Intel, the NAD files are  
usable on PPC + Intel, 32bit + 64bit.

> On the other side, though, with the current extra bytes, the fseek()  
> in nad_ctable_load() doesn't seem to be skipping over those bytes,  
> so they are read as part of the data.  Could it be due to sizeof(ct)  
> used in nad2bin, but sizeof(struct CTABLE) used in  
> nad_ctable_load()?  Or an fseek bug?
>

So, is sizeof(struct CTABLE) supposed to be the size including the  
*cvs pointer?  If so, then it's a bug (OSX at least) in sizeof.  But  
the pj_malloc(sizeof(struct CTABLE)) in nad_ctable_init() seems to be  
working properly.

To make sure, how about:

sizeof(&cd.id) + sizeof(&cd.ll) + sizeof(&cd.del) + sizeof(&cd.lim)

>

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those  
least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

William Kyngesburye
Sorry to keep responding to myself...

On Jan 16, 2008, at 9:08 AM, William Kyngesburye wrote:

>> On the other side, though, with the current extra bytes, the  
>> fseek() in nad_ctable_load() doesn't seem to be skipping over those  
>> bytes, so they are read as part of the data.  Could it be due to  
>> sizeof(ct) used in nad2bin, but sizeof(struct CTABLE) used in  
>> nad_ctable_load()?  Or an fseek bug?
>>
>
> So, is sizeof(struct CTABLE) supposed to be the size including the  
> *cvs pointer?  If so, then it's a bug (OSX at least) in sizeof.  But  
> the pj_malloc(sizeof(struct CTABLE)) in nad_ctable_init() seems to  
> be working properly.
>
> To make sure, how about:
>
> sizeof(&cd.id) + sizeof(&cd.ll) + sizeof(&cd.del) + sizeof(&cd.lim)
>
>>


no sizeof bug.  I was probably (still) misunderstanding datum  
transforms a bit, and the  latlong to latlong tests and utm27 to utm83  
tests, though the same, were still wrong. Now, with the writing of the  
NAD files leaving out the extra bytes, AND and reading in the nad_init  
seeking to the proper place with the above sizeof change, it's all  
consistent, and agrees with the Tiger 32bit-only transform:


$ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
-118 38
118d0'3.385"W 37d59'59.751"N 0.000

$ arch -i386 cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong  
+datum=NAD83
-118 38
118d0'3.385"W 37d59'59.751"N 0.000

$ cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412118.95 4206279.97 0.00

$ arch -i386 cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412118.95 4206279.97 0.00


Is there a definitive way to verify this?  I'm basing the  
"correctness" of this by the NAD83 ticks on a USGS topo map.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those  
least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

Frank Warmerdam
William Kyngesburye wrote:

> no sizeof bug.  I was probably (still) misunderstanding datum transforms
> a bit, and the  latlong to latlong tests and utm27 to utm83 tests,
> though the same, were still wrong. Now, with the writing of the NAD
> files leaving out the extra bytes, AND and reading in the nad_init
> seeking to the proper place with the above sizeof change, it's all
> consistent, and agrees with the Tiger 32bit-only transform:
>
>
> $ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
> -118 38
> 118d0'3.385"W    37d59'59.751"N 0.000

William,

The above matches the expected results.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: NAD problems on OSX 10.5 Leopard

Ed McNierney-4
In reply to this post by William Kyngesburye
William -

I wouldn't claim to be "definitive" but I get the same results as you report on PROJ 4.5.0 running on Windows, and with my interactive JavaScript coordinate/datum converter on the TopoZone site (which uses PROJ behind the scenes for datum shifts).

     - Ed

Ed McNierney
Chief Mapmaker
Demand Media / TopoZone.com
73 Princeton Street, Suite 305
North Chelmsford, MA  01863
[hidden email]
Phone: +1 (978) 251-4242
Fax: +1 (978) 251-1396
-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of William Kyngesburye
Sent: Wednesday, January 16, 2008 10:43 AM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard

Sorry to keep responding to myself...

On Jan 16, 2008, at 9:08 AM, William Kyngesburye wrote:

>> On the other side, though, with the current extra bytes, the  
>> fseek() in nad_ctable_load() doesn't seem to be skipping over those  
>> bytes, so they are read as part of the data.  Could it be due to  
>> sizeof(ct) used in nad2bin, but sizeof(struct CTABLE) used in  
>> nad_ctable_load()?  Or an fseek bug?
>>
>
> So, is sizeof(struct CTABLE) supposed to be the size including the  
> *cvs pointer?  If so, then it's a bug (OSX at least) in sizeof.  But  
> the pj_malloc(sizeof(struct CTABLE)) in nad_ctable_init() seems to  
> be working properly.
>
> To make sure, how about:
>
> sizeof(&cd.id) + sizeof(&cd.ll) + sizeof(&cd.del) + sizeof(&cd.lim)
>
>>


no sizeof bug.  I was probably (still) misunderstanding datum  
transforms a bit, and the  latlong to latlong tests and utm27 to utm83  
tests, though the same, were still wrong. Now, with the writing of the  
NAD files leaving out the extra bytes, AND and reading in the nad_init  
seeking to the proper place with the above sizeof change, it's all  
consistent, and agrees with the Tiger 32bit-only transform:


$ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
-118 38
118d0'3.385"W 37d59'59.751"N 0.000

$ arch -i386 cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong  
+datum=NAD83
-118 38
118d0'3.385"W 37d59'59.751"N 0.000

$ cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412118.95 4206279.97 0.00

$ arch -i386 cs2cs +init=EPSG:26711 +to +init=EPSG:26911
412199.39 4206081.09
412118.95 4206279.97 0.00


Is there a definitive way to verify this?  I'm basing the  
"correctness" of this by the NAD83 ticks on a USGS topo map.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those  
least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

William Kyngesburye
Thanks for the verifications.

I can use my patch in my binaries for now.  I'll add a feature request  
for a consistent binary file format, either as my quick patch, or as  
NTv* type files.

On Jan 16, 2008, at 10:09 AM, Ed McNierney wrote:

> William -
>
> I wouldn't claim to be "definitive" but I get the same results as  
> you report on PROJ 4.5.0 running on Windows, and with my interactive  
> JavaScript coordinate/datum converter on the TopoZone site (which  
> uses PROJ behind the scenes for datum shifts).
>
>     - Ed


On Jan 16, 2008, at 10:00 AM, Frank Warmerdam wrote:

> William Kyngesburye wrote:
>> $ cs2cs +proj=latlong +datum=NAD27 +to +proj=latlong +datum=NAD83
>> -118 38
>> 118d0'3.385"W    37d59'59.751"N 0.000
>
> William,
>
> The above matches the expected results.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

Karl Swartz
In reply to this post by William Kyngesburye
> >Ah, the extra bytes are pointer for the *cvs part of the CTABLE  
> >structure?
> >
> > fwrite(ct.cvs, tsize, 1, stdout)

No.

> >Or is it written as part of the &ct fwrite?
> >
> > fwrite(&ct, sizeof(ct), 1, stdout)

Yes.  The cvs element of that structure is a pointer, which is 32-bits
in x86 mode and 64-bits in x86-64 mode.  The extra four bytes are due to
the larger pointer.

> This works:
>
> if (fwrite(&ct.id, sizeof(ct.id), 1, stdout) != 1 ||
> fwrite(&ct.ll, sizeof(ct.ll), 1, stdout) != 1 ||
> fwrite(&ct.del, sizeof(ct.del), 1, stdout) != 1 ||
> fwrite(&ct.lim, sizeof(ct.lim), 1, stdout) != 1 ||
> fwrite(ct.cvs, tsize, 1, stdout) != 1) {
> fprintf(stderr, "output failure\n");
> exit(2);
> }

That doesn't write the pointer, so yes, it should work, so long as both
architectures have the same format for ther other values (which is true
for x86 and x86-64).

> So, is sizeof(struct CTABLE) supposed to be the size including the  
> *cvs pointer?

Of course.

> sizeof(&cd.id) + sizeof(&cd.ll) + sizeof(&cd.del) + sizeof(&cd.lim)

In this case it should work though in general it will not since it
assumes no padding.  For example, if MAX_TAB_ID were 1 or 81 (it's
actually 80), an x86 compiler should add three pad bytes so cd.ll is
aligned on a 4-byte boundary.  On some architectures (and on x86 if
you use gcc's -malign-double option), there will be seven pad bytes
in this example, or other amounts depending upon the alignment of a
double.

(Again, on x86 and x86-64, there should be no padding so this should
work.)

A better way of writing this would be

    #include <stddef.h>

    if (fwrite(&ct, offsetof(ct, cvs), 1, stdout) != 1)
        ...

The avoids writing out the pointer (which is useless anyway) but depends
on cvs being the last element of the structure.

Writing each element individually (as you did above) is the safest,
depending only on the encoding of the underlying types.

 -- Karl
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

Paul Kelly
In reply to this post by William Kyngesburye
On Wed, 16 Jan 2008, William Kyngesburye wrote:

> Thanks for the verifications.
>
> I can use my patch in my binaries for now.  I'll add a feature request for a
> consistent binary file format, either as my quick patch, or as NTv* type
> files.

Just pointing out for completeness because it doesn't seem to have been
mentioned really in this thread, the "conventional" way of dealing with
this issue is for the binary installer to automatically run the nad2bin
program to regenerate the platform-dependent gridshift files during the
installation process. E.g. this is what the GRASS binary installer script
does.

Paul
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

William Kyngesburye
Understood.  But OSX is outside conventions here.  A single binary can  
contain 4 combinations of PPC & Intel, 32bit & 64bit architectures.  
Support data files need to be consistent across that range.

On Jan 16, 2008, at 12:27 PM, Paul Kelly wrote:

> On Wed, 16 Jan 2008, William Kyngesburye wrote:
>
>> Thanks for the verifications.
>>
>> I can use my patch in my binaries for now.  I'll add a feature  
>> request for a consistent binary file format, either as my quick  
>> patch, or as NTv* type files.
>
> Just pointing out for completeness because it doesn't seem to have  
> been mentioned really in this thread, the "conventional" way of  
> dealing with this issue is for the binary installer to automatically  
> run the nad2bin program to regenerate the platform-dependent  
> gridshift files during the installation process. E.g. this is what  
> the GRASS binary installer script does.
>
> Paul
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those  
least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

rgreenwood
In reply to this post by Ed McNierney-4
On Jan 16, 2008 9:09 AM, Ed McNierney <[hidden email]> wrote:
> William -
>
> I wouldn't claim to be "definitive" but I get the same results as you report on PROJ 4.5.0 running on Windows, and with my interactive JavaScript coordinate/datum converter on the TopoZone site (which uses PROJ behind the scenes for datum shifts).
>
>      - Ed

Ed,

I curious about your JavaScript coordinate converted because I've done
a little work on one myself. I took a quick look on TopoZone and
didn't see it. Could you point me to it?

Rich

--
Richard Greenwood
[hidden email]
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: NAD problems on OSX 10.5 Leopard

Ed McNierney-4
Rich -

It's actually not much, and is pretty hardwired for NAD27/NAD83 support
and converting UTM to lat/lon coordinates.

All maps displayed on TopoZone are in the UTM projection.  I calculate
the bounding box coordinates for each map in NAD27 UTM and NAD83 UTM,
and pre-load that data on the page, accessible to JavaScript (just some
global variables).  As a subscriber moves the mouse over the map, the
coordinates of the point under the cursor are displayed in the browser
status bar.  For UTM coordinates, it's simple linear interpolation
across the image extent.  If the user chooses lat/lon display, I use the
JavaScript code below to convert on the fly as the mouse is moved over
the map. It's a one-way conversion from UTM to LL, and relies on a
global variable (datumFlag) to indicate NAD27 (0) or NAD83 (1).

Please remember that this is not a general solution but is designed only
to work properly for valid NAD27 (North American) coordinates.

        - Ed

function UTMtoLL(UTMNorthing, UTMEasting, UTMZone)
{
        var deg2rad = Math.PI / 180;
        var rad2deg = 180.0 / Math.PI;

        var k0 = 0.9996;
        var a;
        var eccSquared;
        var eccPrimeSquared;
        var e1;
        var N1, T1, C1, R1, D, M;
        var LongOrigin;
        var mu, phi1, phi1Rad;
        var x, y;
        var ZoneNumber;

        if (datumFlag == 0)
        {
                a = 6378206;
                eccSquared = 0.006768658;
        } else
        {
                a = 6378137;
                eccSquared = 0.00669438;
        }
                       
        e1 = (1-Math.sqrt(1-eccSquared))/(1+Math.sqrt(1-eccSquared));
        x = UTMEasting - 500000.0; //remove 500,000 meter offset for
longitude
        y = UTMNorthing;

        ZoneNumber = UTMZone;

        LongOrigin = (ZoneNumber - 1)*6 - 180 + 3;  //+3 puts origin in
middle of zone

        eccPrimeSquared = (eccSquared)/(1-eccSquared);

        M = y / k0;
        mu =
M/(a*(1-eccSquared/4-3*eccSquared*eccSquared/64-5*eccSquared*eccSquared*
eccSquared/256));

        phi1Rad = mu + (3*e1/2-27*e1*e1*e1/32)*Math.sin(2*mu)
                                +
(21*e1*e1/16-55*e1*e1*e1*e1/32)*Math.sin(4*mu)
                                +(151*e1*e1*e1/96)*Math.sin(6*mu);
        phi1 = phi1Rad*rad2deg;

        N1 =
a/Math.sqrt(1-eccSquared*Math.sin(phi1Rad)*Math.sin(phi1Rad));
        T1 = Math.tan(phi1Rad)*Math.tan(phi1Rad);
        C1 = eccPrimeSquared*Math.cos(phi1Rad)*Math.cos(phi1Rad);
        R1 =
a*(1-eccSquared)/Math.pow(1-eccSquared*Math.sin(phi1Rad)*Math.sin(phi1Ra
d), 1.5);
        D = x/(N1*k0);

        Lat = phi1Rad -
(N1*Math.tan(phi1Rad)/R1)*(D*D/2-(5+3*T1+10*C1-4*C1*C1-9*eccPrimeSquared
)*D*D*D*D/24
       
+(61+90*T1+298*C1+45*T1*T1-252*eccPrimeSquared-3*C1*C1)*D*D*D*D*D*D/720)
;
        Lat = Lat * rad2deg;
        LatS = formatDeg (Lat,0) + "N";
       
        Long =
(D-(1+2*T1+C1)*D*D*D/6+(5-2*C1+28*T1-3*C1*C1+8*eccPrimeSquared+24*T1*T1)
       
*D*D*D*D*D/120)/Math.cos(phi1Rad);
        Long = LongOrigin + Long * rad2deg;
        LongS = formatDeg (Long,0) + "W";
}

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Richard Greenwood
Sent: Wednesday, January 16, 2008 11:13 PM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard

On Jan 16, 2008 9:09 AM, Ed McNierney <[hidden email]> wrote:
> William -
>
> I wouldn't claim to be "definitive" but I get the same results as you
report on PROJ 4.5.0 running on Windows, and with my interactive
JavaScript coordinate/datum converter on the TopoZone site (which uses
PROJ behind the scenes for datum shifts).
>
>      - Ed

Ed,

I curious about your JavaScript coordinate converted because I've done
a little work on one myself. I took a quick look on TopoZone and
didn't see it. Could you point me to it?

Rich

--
Richard Greenwood
[hidden email]
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

rgreenwood
Ed,

Thanks for the detailed explanation. Nice, clean solution (I'd expect
no less fro you)!

I've done a bit of work on porting cs2cs to JavaScript. Grid shift
transformations pose an interesting challenge if you want to transfer
a minimum of data to the browser. Which is why I was curious as to
what you were doing.

Rich



On Jan 17, 2008 10:58 AM, Ed McNierney <[hidden email]> wrote:

> Rich -
>
> It's actually not much, and is pretty hardwired for NAD27/NAD83 support
> and converting UTM to lat/lon coordinates.
>
> All maps displayed on TopoZone are in the UTM projection.  I calculate
> the bounding box coordinates for each map in NAD27 UTM and NAD83 UTM,
> and pre-load that data on the page, accessible to JavaScript (just some
> global variables).  As a subscriber moves the mouse over the map, the
> coordinates of the point under the cursor are displayed in the browser
> status bar.  For UTM coordinates, it's simple linear interpolation
> across the image extent.  If the user chooses lat/lon display, I use the
> JavaScript code below to convert on the fly as the mouse is moved over
> the map. It's a one-way conversion from UTM to LL, and relies on a
> global variable (datumFlag) to indicate NAD27 (0) or NAD83 (1).
>
> Please remember that this is not a general solution but is designed only
> to work properly for valid NAD27 (North American) coordinates.
>
>         - Ed
>
> function UTMtoLL(UTMNorthing, UTMEasting, UTMZone)
> {
>         var deg2rad = Math.PI / 180;
>         var rad2deg = 180.0 / Math.PI;
>
>         var k0 = 0.9996;
>         var a;
>         var eccSquared;
>         var eccPrimeSquared;
>         var e1;
>         var N1, T1, C1, R1, D, M;
>         var LongOrigin;
>         var mu, phi1, phi1Rad;
>         var x, y;
>         var ZoneNumber;
>
>         if (datumFlag == 0)
>         {
>                 a = 6378206;
>                 eccSquared = 0.006768658;
>         } else
>         {
>                 a = 6378137;
>                 eccSquared = 0.00669438;
>         }
>
>         e1 = (1-Math.sqrt(1-eccSquared))/(1+Math.sqrt(1-eccSquared));
>         x = UTMEasting - 500000.0; //remove 500,000 meter offset for
> longitude
>         y = UTMNorthing;
>
>         ZoneNumber = UTMZone;
>
>         LongOrigin = (ZoneNumber - 1)*6 - 180 + 3;  //+3 puts origin in
> middle of zone
>
>         eccPrimeSquared = (eccSquared)/(1-eccSquared);
>
>         M = y / k0;
>         mu =
> M/(a*(1-eccSquared/4-3*eccSquared*eccSquared/64-5*eccSquared*eccSquared*
> eccSquared/256));
>
>         phi1Rad = mu    + (3*e1/2-27*e1*e1*e1/32)*Math.sin(2*mu)
>                                 +
> (21*e1*e1/16-55*e1*e1*e1*e1/32)*Math.sin(4*mu)
>                                 +(151*e1*e1*e1/96)*Math.sin(6*mu);
>         phi1 = phi1Rad*rad2deg;
>
>         N1 =
> a/Math.sqrt(1-eccSquared*Math.sin(phi1Rad)*Math.sin(phi1Rad));
>         T1 = Math.tan(phi1Rad)*Math.tan(phi1Rad);
>         C1 = eccPrimeSquared*Math.cos(phi1Rad)*Math.cos(phi1Rad);
>         R1 =
> a*(1-eccSquared)/Math.pow(1-eccSquared*Math.sin(phi1Rad)*Math.sin(phi1Ra
> d), 1.5);
>         D = x/(N1*k0);
>
>         Lat = phi1Rad -
> (N1*Math.tan(phi1Rad)/R1)*(D*D/2-(5+3*T1+10*C1-4*C1*C1-9*eccPrimeSquared
> )*D*D*D*D/24
>
> +(61+90*T1+298*C1+45*T1*T1-252*eccPrimeSquared-3*C1*C1)*D*D*D*D*D*D/720)
> ;
>         Lat = Lat * rad2deg;
>         LatS = formatDeg (Lat,0) + "N";
>
>         Long =
> (D-(1+2*T1+C1)*D*D*D/6+(5-2*C1+28*T1-3*C1*C1+8*eccPrimeSquared+24*T1*T1)
>
> *D*D*D*D*D/120)/Math.cos(phi1Rad);
>         Long = LongOrigin + Long * rad2deg;
>         LongS = formatDeg (Long,0) + "W";
> }
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Richard Greenwood
> Sent: Wednesday, January 16, 2008 11:13 PM
> To: PROJ.4 and general Projections Discussions
> Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard
>
>
> On Jan 16, 2008 9:09 AM, Ed McNierney <[hidden email]> wrote:
> > William -
> >
> > I wouldn't claim to be "definitive" but I get the same results as you
> report on PROJ 4.5.0 running on Windows, and with my interactive
> JavaScript coordinate/datum converter on the TopoZone site (which uses
> PROJ behind the scenes for datum shifts).
> >
> >      - Ed
>
> Ed,
>
> I curious about your JavaScript coordinate converted because I've done
> a little work on one myself. I took a quick look on TopoZone and
> didn't see it. Could you point me to it?
>
> Rich
>
> --
> Richard Greenwood
> [hidden email]
> www.greenwoodmap.com
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>



--
Richard Greenwood
[hidden email]
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: NAD problems on OSX 10.5 Leopard

Ed McNierney-4
Rich -

The one thing that significantly surprised me was how well that code
performed on low-end machines.  I think I released it in 2002 - maybe
2001 - and there were plenty of "slow" computers visiting TopoZone.  I
realize it's just math (other than updating the status bar with the
formatted coordinate text), but I was really expecting to see some kind
of lag if you waved the mouse quickly on a slow machine, but I never saw
the slightest delay.  I have found that I sometimes worry excessively
about performance!

        - Ed

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Richard Greenwood
Sent: Thursday, January 17, 2008 8:34 PM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard

Ed,

Thanks for the detailed explanation. Nice, clean solution (I'd expect
no less fro you)!

I've done a bit of work on porting cs2cs to JavaScript. Grid shift
transformations pose an interesting challenge if you want to transfer
a minimum of data to the browser. Which is why I was curious as to
what you were doing.

Rich



On Jan 17, 2008 10:58 AM, Ed McNierney <[hidden email]> wrote:
> Rich -
>
> It's actually not much, and is pretty hardwired for NAD27/NAD83
support
> and converting UTM to lat/lon coordinates.
>
> All maps displayed on TopoZone are in the UTM projection.  I calculate
> the bounding box coordinates for each map in NAD27 UTM and NAD83 UTM,
> and pre-load that data on the page, accessible to JavaScript (just
some
> global variables).  As a subscriber moves the mouse over the map, the
> coordinates of the point under the cursor are displayed in the browser
> status bar.  For UTM coordinates, it's simple linear interpolation
> across the image extent.  If the user chooses lat/lon display, I use
the
> JavaScript code below to convert on the fly as the mouse is moved over
> the map. It's a one-way conversion from UTM to LL, and relies on a
> global variable (datumFlag) to indicate NAD27 (0) or NAD83 (1).
>
> Please remember that this is not a general solution but is designed
only

> to work properly for valid NAD27 (North American) coordinates.
>
>         - Ed
>
> function UTMtoLL(UTMNorthing, UTMEasting, UTMZone)
> {
>         var deg2rad = Math.PI / 180;
>         var rad2deg = 180.0 / Math.PI;
>
>         var k0 = 0.9996;
>         var a;
>         var eccSquared;
>         var eccPrimeSquared;
>         var e1;
>         var N1, T1, C1, R1, D, M;
>         var LongOrigin;
>         var mu, phi1, phi1Rad;
>         var x, y;
>         var ZoneNumber;
>
>         if (datumFlag == 0)
>         {
>                 a = 6378206;
>                 eccSquared = 0.006768658;
>         } else
>         {
>                 a = 6378137;
>                 eccSquared = 0.00669438;
>         }
>
>         e1 = (1-Math.sqrt(1-eccSquared))/(1+Math.sqrt(1-eccSquared));
>         x = UTMEasting - 500000.0; //remove 500,000 meter offset for
> longitude
>         y = UTMNorthing;
>
>         ZoneNumber = UTMZone;
>
>         LongOrigin = (ZoneNumber - 1)*6 - 180 + 3;  //+3 puts origin
in
> middle of zone
>
>         eccPrimeSquared = (eccSquared)/(1-eccSquared);
>
>         M = y / k0;
>         mu =
>
M/(a*(1-eccSquared/4-3*eccSquared*eccSquared/64-5*eccSquared*eccSquared*

> eccSquared/256));
>
>         phi1Rad = mu    + (3*e1/2-27*e1*e1*e1/32)*Math.sin(2*mu)
>                                 +
> (21*e1*e1/16-55*e1*e1*e1*e1/32)*Math.sin(4*mu)
>                                 +(151*e1*e1*e1/96)*Math.sin(6*mu);
>         phi1 = phi1Rad*rad2deg;
>
>         N1 =
> a/Math.sqrt(1-eccSquared*Math.sin(phi1Rad)*Math.sin(phi1Rad));
>         T1 = Math.tan(phi1Rad)*Math.tan(phi1Rad);
>         C1 = eccPrimeSquared*Math.cos(phi1Rad)*Math.cos(phi1Rad);
>         R1 =
>
a*(1-eccSquared)/Math.pow(1-eccSquared*Math.sin(phi1Rad)*Math.sin(phi1Ra
> d), 1.5);
>         D = x/(N1*k0);
>
>         Lat = phi1Rad -
>
(N1*Math.tan(phi1Rad)/R1)*(D*D/2-(5+3*T1+10*C1-4*C1*C1-9*eccPrimeSquared
> )*D*D*D*D/24
>
>
+(61+90*T1+298*C1+45*T1*T1-252*eccPrimeSquared-3*C1*C1)*D*D*D*D*D*D/720)
> ;
>         Lat = Lat * rad2deg;
>         LatS = formatDeg (Lat,0) + "N";
>
>         Long =
>
(D-(1+2*T1+C1)*D*D*D/6+(5-2*C1+28*T1-3*C1*C1+8*eccPrimeSquared+24*T1*T1)
>
> *D*D*D*D*D/120)/Math.cos(phi1Rad);
>         Long = LongOrigin + Long * rad2deg;
>         LongS = formatDeg (Long,0) + "W";
> }
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Richard
Greenwood
> Sent: Wednesday, January 16, 2008 11:13 PM
> To: PROJ.4 and general Projections Discussions
> Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard
>
>
> On Jan 16, 2008 9:09 AM, Ed McNierney <[hidden email]> wrote:
> > William -
> >
> > I wouldn't claim to be "definitive" but I get the same results as
you

> report on PROJ 4.5.0 running on Windows, and with my interactive
> JavaScript coordinate/datum converter on the TopoZone site (which uses
> PROJ behind the scenes for datum shifts).
> >
> >      - Ed
>
> Ed,
>
> I curious about your JavaScript coordinate converted because I've done
> a little work on one myself. I took a quick look on TopoZone and
> didn't see it. Could you point me to it?
>
> Rich
>
> --
> Richard Greenwood
> [hidden email]
> www.greenwoodmap.com
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>



--
Richard Greenwood
[hidden email]
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

rgreenwood
On Jan 17, 2008 8:28 PM, Ed McNierney <[hidden email]> wrote:

> Rich -
>
> The one thing that significantly surprised me was how well that code
> performed on low-end machines.  I think I released it in 2002 - maybe
> 2001 - and there were plenty of "slow" computers visiting TopoZone.  I
> realize it's just math (other than updating the status bar with the
> formatted coordinate text), but I was really expecting to see some kind
> of lag if you waved the mouse quickly on a slow machine, but I never saw
> the slightest delay.  I have found that I sometimes worry excessively
> about performance!
>
>         - Ed

I believe it was you who coined the term "premature optimization",
which always gets a chuckle when I use it. And I too have been amazed
at the performance of the JavaScript code I ported that does one or
more a projections (or unprojections) and a 7 parameter datum
transform for every pixel the user passes over. I kind of remember
computer science texts that discouraged us from using floating point
math if it could possibly be done with integers.

--
Richard Greenwood
[hidden email]
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: NAD problems on OSX 10.5 Leopard

strebe

"Premature optimization" was probably coined by pioneering computer scientist C.A.R. Hoare, who said, "Premature optimization is the root of all evil." Sadly, this is often misunderstood to mean, "Engineering for scalability is the root of all evil."

Regards,
-- daan Strebe


-----Original Message-----
From: Richard Greenwood <[hidden email]>
To: PROJ.4 and general Projections Discussions <[hidden email]>
Sent: Thu, 17 Jan 2008 8:50 pm
Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard

On Jan 17, 2008 8:28 PM, Ed McNierney <[hidden email]> wrote:
> Rich -
>
> The one thing that significantly surprised me was how well that code
> performed on low-end machines. I think I released it in 2002 - maybe
> 2001 - and there were plenty of "slow" computers visiting TopoZone. I
> realize it's just math (other than updating the status bar with the
> formatted coordinate text), but I was really expecting to see some kind
> of lag if you waved the mouse quickly on a slow machine, but I never saw
> the slightest delay. I have found that I sometimes worry excessively
> about performance!
>
> - Ed

I believe it was you who coined the term "premature optimization",
which always gets a chuckle when I use it. And I too have been amazed
at the performance of the JavaScript code I ported that does one or
more a projections (or unprojections) and a 7 parameter datum
transform for every pixel the user passes over. I kind of remember
computer science texts that discouraged us from using floating point
math if it could possibly be done with integers.

--
Richard Greenwood
[hidden email]
www.greenwoodmap.com
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

More new features than ever. Check out the new AOL Mail!

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

RE: Re: NAD problems on OSX 10.5 Leopard

Ed McNierney-4

Daan & Rich –

 

I think I’d want to remember that “premature optimization” really reminds us to “make it work correctly, THEN make it work quickly”!  This is related to the observation that any code can be made to execute arbitrarily quickly as long as it is not required to produce the right answer.

 

I have to say that whatever its origin, I picked up the phrase from my friend and co-worker Bob Frankston (author of VisiCalc), who was (and is) fond of pithy pronouncements.

 

-          Ed

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Friday, January 18, 2008 12:21 AM
To: [hidden email]
Subject: [Proj] Re: NAD problems on OSX 10.5 Leopard

 

 

"Premature optimization" was probably coined by pioneering computer scientist C.A.R. Hoare, who said, "Premature optimization is the root of all evil." Sadly, this is often misunderstood to mean, "Engineering for scalability is the root of all evil."

Regards,
-- daan Strebe

 

-----Original Message-----
From: Richard Greenwood <[hidden email]>
To: PROJ.4 and general Projections Discussions <[hidden email]>
Sent: Thu, 17 Jan 2008 8:50 pm
Subject: Re: [Proj] NAD problems on OSX 10.5 Leopard

On Jan 17, 2008 8:28 PM, Ed McNierney <[hidden email]> wrote:

> Rich -

>

> The one thing that significantly surprised me was how well that code

> performed on low-end machines.  I think I released it in 2002 - maybe

> 2001 - and there were plenty of "slow" computers visiting TopoZone.  I

> realize it's just math (other than updating the status bar with the

> formatted coordinate text), but I was really expecting to see some kind

> of lag if you waved the mouse quickly on a slow machine, but I never saw

> the slightest delay.  I have found that I sometimes worry excessively

> about performance!

>

>         - Ed



I believe it was you who coined the term "premature optimization",

which always gets a chuckle when I use it. And I too have been amazed

at the performance of the JavaScript code I ported that does one or

more a projections (or unprojections) and a 7 parameter datum

transform for every pixel the user passes over. I kind of remember

computer science texts that discouraged us from using floating point

math if it could possibly be done with integers.



-- 

Richard Greenwood

[hidden email]

www.greenwoodmap.com

_______________________________________________

Proj mailing list

[hidden email]

http://lists.maptools.org/mailman/listinfo/proj

More new features than ever. Check out the new AOL Mail!


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
12