Re: [DebianGIS] Fw: Re: [Proj] NAD27 and WGS84 woes
On Wed, Nov 26, 2008 at 09:20:28PM -0800, Hamish wrote:
> Francesco:
> > ntf_r93.gsb: data
> > ntv1_can.dat: data
> > nzgd2kgrid0005.gsb: data
> >
> > Three files are in binary format: the .gsb files are NTv2 binaries,
> > the other not (maybe NTv1?)
>
> from its filename, apparently the Canadian file is NTv1 format.
>
>
> > I wonder if those files are managed correctly by proj on all archs.
>
> there has never been a complaint I know of through all the years of
> PPC Mac OSX, so I would say there is no issue there. The endianness
> issue I spoke of before was WRT how the USA ascii files are processed
> to binary by GRASS. This was a grass bug from long long ago, so forget
> I mentioned it.
>
I had a look to the binary NTv2 format where int and floats are used
and that was the reason to ask. FrankW already clarified that the
code is endianess-aware, so ignore me about that.
>
> > I found a reference to NTv2 formats,
>
> http://www.geod.nrcan.gc.ca/tools-outils/ntv2_e.php
> "The software is generically written for DOS, and the supplied FORTRAN source code can easily be recompiled by the end-user to modify the formats for the input and output coordinate data, or to port the NTv2 to other platforms such as UNIX, VAX/VMS, and MAC/OS. Complete grid shift file structure specifications and access algorithms facilitate more complex integration into end-user systems."
>
>
Apparently there's a well known NTv2 Developer's Guide and I found
other references to both binary and ascii formats. So NTv2 blobs
are perfectly ok for me now because documented and well managed
on any archs by proj.
> > but not for the second file. Do you have more information about that?
>
> the NTv1 format?
>
>
Yes, I would prefer including a reference to NTv1 format. Undocumented
binaries are evil.
> Francesco email #2:
> > As explained in the related bug report, I'm afraid that those blobs
> > are not endianess-safe.
>
> what bug report is that?
> I believe that they are endian safe. To resolve that we'd need to look
> in the PDF spec in the above .gc.ca URL.
>
Err, sorry my fault. I was replying to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458369
but my mail has been dropped for some reasons :-/
>
> > The NTv2 binary has an ASCII counterpart, so it is probably better
> > pre-convert them in ASCII format.
>
> you could say the same for RGB bitmaps in common image formats.
> To me that's a waste of time and risks introducing unintended changes
> for no gain.
>
> I don't see any problem with the binary NTv[12] files. The format is
> publicly documented in PDF, fortran code exists on the Canadian site
> to work with them.
>
> > Do you have a reference for the NTv1 format?
>
> I don't, but it'll surely be out there somewhere and can be found before
> submitting the package. Natural Resources Canada personel are active in
> the FOSS world and should be able to help.
>
>
> > Also, it's better avoiding binary blobs, which are always looked
> > with suspect by ftpmasters.
>
> again, for a documented binary format with code it's really not much
> different than a RGB bitmap image. Undocumented binary blobs are
> questionable, documented ones are without question as long as links to
> the format documents are provided in a README.
>
>
> > A general problem anyway is about a missing accompanying license for
> > those files.
>
> Debian rules state that anything going into Debian has to come with
> a license documentation. This should not be so hard to arrange,
>
> of the 15 files:
> ----------------
>
> The 12 USA ones are sourced from the 1993 release of PROJ4 by Gerald
> Evenden when he worked at the USGS. Gerald remains the maintainer of
> libproj to this day and can be found on the proj mailing list if needed.
> see ftp://ftp.remotesensing.org/proj/from_kai/ for historic release notes.
> or just download his current MIT/X libproj and go from there.
>
> The NTv1 Canada file I don't know about; someone else will.
> Natural Resources Canada personel are active in the FOSS world
> and should have access to it.
>
> Permission to use the French grid file (ntf_r93) is in the proj mailing
> list archives, URL in my prev email.
>
> Permission to use the New Zealand grid file (ntf_r93) is in the proj
> and grass mailing list archives. I have the original correspondence.
>
>
> > People say they are public domain, but there's no evidence about that.
>
> see above.
>
> > There are many places where they are distributed, but this is does not
> > imply they are public domain...
>
> except if one of those places is the USGS and the rest have documentation
> from their source.
> As "Public Domain" has a specific legal meaning, I do not think it is
> right to apply that term to the non-US data. Better to say the given
> consent is compatible with the DFSG and provide the words given.
>
Yes, I'm perfectly sure about US/Canada/New Zealad. I see french data too, and
notoriously many european countries are less liberal with their data.
That was the reason to ask about references/statements.
>
> Frank:
> > Nevertheless, if the position of the Debian project is that they don't
> > trust the license status of these files,
>
> the position of the Debian project (which is the DFSG text) is that they
> need *a* license file with any package they are to redistribute.
> And proj-datumgrid-1.4.tar.gz only has data in it.
> A license file in a separate .tar.gz in the same FTP dir isn't good enough
> because it is for something else.
>
> I believe that the READMEs in the proj ftp site "from_kai" dir may suffice
> for the US data though.
>
>
>
> regards,
> Hamish
>
Hamish many thanks for the explanations and additional details provided.
I'm afraid my non-native english had caused some misunderstanding about
the licensing issue. It was not intended to be offensive, just preventive
for possible problems within the Debian project and DFSG constraints,
as privately explained to Frank.
--
Francesco P. Lovergine
Reply to: