[Proj] The trouble with grid datum correction files

[support.mn at elisanet.fi]

Hello,

why not but a BOM in the beginning of every (binary) file, and if that is missing
then assume that it is little endian, if that yiels bad scanning then switch to
big endian and restart... and finally if that does not work either... assume that
the data file is not in right format or corrupted. With that strategy there is no
way to fail. I assume that most editors do it just like that... they simply try to
figure it out them self each time (Tiff reader at least does so).

Janne. / MNS Support

--------------------------------------

strebe [strebe at aol.com] kirjoitti: 
> 
> I advise revising that expectation. There is no such standard or convention in the broader context of computer science. Indeed, the Shapefile specification, for an example directly relevant to this list, even mixes big- and little endian byte sex within the format. Graphic image formats such as TIFF allow the TIFF writer to specify which endian. Many other binary formats are exclusively little endian because of their development and propagation on the i86 platform.
> 
> Regards,
>  daan Strebe
> 
> 
> On Jul 4, 2009, at 4:27:25 PM, "Christopher Hunt" <huntc at mac.com> wrote:
> Hi there,
> 
> I do not claim to fully understand the context of the issue here, but 
> as a software developer I have an expectation for portable binary data 
> to be presented in big endian form. My expectation is derived from the 
> big endian nature of data in binary network protocols (http://en.wikipedia.org/wiki/Endian#Endianness_in_networking 
> ).
> 
> Kind regards,
> Christopher
> 
> 
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj