HARN nadgrid files

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

HARN nadgrid files

rgreenwood
I've been following a few of the recent threads on this list regarding enhancements to Proj's datum transformations. Pretty exciting stuff! 

One group of transformations that seems to have been ignored for a number of years is applying the HARN hpgn grids in the Proj epsg file. For example the Proj epsg entry for epsg:3758 uses +towgs84=0,0,0,0,0,0,0 but I believe that is should use +nadgrids=wyhpgn.gsb, or at least that's what I change it to, which produces results that match NADCON.

Is anyone aware of a reason that nadgrids are not referenced in the epsg file? Is it maybe just an oversight, something that nobody ever got around to? Or because distributing nadgrids would become burdensome?

It seems like pretty low hanging fruit. HARN has been around for about 20 years. The nadgrid files are already there. Differences between +towgs84=0,0,0,0,0,0,0 and +nadgrids=XXhpgn.gsb are on the order of a meter in the few places I have looked, so it's a fairly significant correction (or error, depending on your point of view).  "grep -c HARN epsg" returned 264 and "grep -c 'hpgn' epsg" returned 0, so effects a lot of definitions.

Maybe I'm missing something. I'd be interested in any comments.

Rich

--
Richard W. Greenwood, PLS
www.greenwoodmap.com

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

Re: HARN nadgrid files

Sebastiaan Couwenberg
On 12/22/2016 09:40 PM, Richard Greenwood wrote:
> One group of transformations that seems to have been ignored for a number
> of years is applying the HARN hpgn grids in the Proj epsg file. For example
> the Proj epsg entry for epsg:3758 uses +towgs84=0,0,0,0,0,0,0 but I believe
> that is should use +nadgrids=wyhpgn.gsb, or at least that's what I change
> it to, which produces results that match NADCON.
>
> Is anyone aware of a reason that nadgrids are not referenced in the epsg
> file? Is it maybe just an oversight, something that nobody ever got around
> to? Or because distributing nadgrids would become burdensome?

wyhpgn.gsb is not included in proj-datumgrids, so referencing it in the
epsg file in proj doesn't make sense as the definition would be unusable.

If wyhpgn.gsb is licensed freely enough to be included in
proj-datumgrids, updating the definition to use it is an option.

I've looked for the authoritative source for wyhpgn.gsb but didn't find
it. Who provides the file and under which license?

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: HARN nadgrid files

Even Rouault-2
In reply to this post by rgreenwood

On jeudi 22 décembre 2016 13:40:23 CET Richard Greenwood wrote:

> I've been following a few of the recent threads on this list regarding

> enhancements to Proj's datum transformations. Pretty exciting stuff!

>

> One group of transformations that seems to have been ignored for a number

> of years is applying the HARN hpgn grids in the Proj epsg file. For example

> the Proj epsg entry for epsg:3758 uses +towgs84=0,0,0,0,0,0,0 but I believe

> that is should use +nadgrids=wyhpgn.gsb, or at least that's what I change

> it to, which produces results that match NADCON.

>

> Is anyone aware of a reason that nadgrids are not referenced in the epsg

> file? Is it maybe just an oversight, something that nobody ever got around

> to? Or because distributing nadgrids would become burdensome?

 

Richard,

 

I don't think we would want to force people using grids to be able to use EPSG codes (because of the required space or licensing terms), but we could generate +nadgrids=@bla syntax to make them optional. What could be useful is to have both +nadgrids= and +towgs84 with the priority given to the grids when they are present but this isn't implemented right now in proj.4 (if you have both +nadgrids and +towgs84, I believe +nadgrids is always used, even if the grids are missing on the system)

 

As far as adding the grid info, in the current workflow, this would be a matter of doing that in the https://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/build_pcs.py script, presumably adding a new column in the gcs.csv file, and some logic/dictionary to match the datum name with a grid name, and then updating GDAL to use that new information when reading the .csv files.

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com


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

Re: HARN nadgrid files

rgreenwood
In reply to this post by Sebastiaan Couwenberg


On Thu, Dec 22, 2016 at 1:50 PM, Sebastiaan Couwenberg <[hidden email]> wrote:
On 12/22/2016 09:40 PM, Richard Greenwood wrote:
> One group of transformations that seems to have been ignored for a number
> of years is applying the HARN hpgn grids in the Proj epsg file. For example
> the Proj epsg entry for epsg:3758 uses +towgs84=0,0,0,0,0,0,0 but I believe
> that is should use +nadgrids=wyhpgn.gsb, or at least that's what I change
> it to, which produces results that match NADCON.
>
> Is anyone aware of a reason that nadgrids are not referenced in the epsg
> file? Is it maybe just an oversight, something that nobody ever got around
> to? Or because distributing nadgrids would become burdensome?

wyhpgn.gsb is not included in proj-datumgrids, so referencing it in the
epsg file in proj doesn't make sense as the definition would be unusable.

Not sure I follow you. It works for me.
 
If wyhpgn.gsb is licensed freely enough to be included in
proj-datumgrids, updating the definition to use it is an option.

I've looked for the authoritative source for wyhpgn.gsb but didn't find
it. Who provides the file and under which license?

I probably should have included this in my original post:


--
Richard W. Greenwood, PLS
www.greenwoodmap.com

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

Re: HARN nadgrid files

rgreenwood
In reply to this post by Even Rouault-2
I meant to reply to list.

On Thu, Dec 22, 2016 at 2:21 PM, Richard Greenwood <[hidden email]> wrote:


On Thu, Dec 22, 2016 at 2:00 PM, Even Rouault <[hidden email]> wrote:

On jeudi 22 décembre 2016 13:40:23 CET Richard Greenwood wrote:

> I've been following a few of the recent threads on this list regarding

> enhancements to Proj's datum transformations. Pretty exciting stuff!

>

> One group of transformations that seems to have been ignored for a number

> of years is applying the HARN hpgn grids in the Proj epsg file. For example

> the Proj epsg entry for epsg:3758 uses +towgs84=0,0,0,0,0,0,0 but I believe

> that is should use +nadgrids=wyhpgn.gsb, or at least that's what I change

> it to, which produces results that match NADCON.

>

> Is anyone aware of a reason that nadgrids are not referenced in the epsg

> file? Is it maybe just an oversight, something that nobody ever got around

> to? Or because distributing nadgrids would become burdensome?

 

Richard,

 

I don't think we would want to force people using grids to be able to use EPSG codes (because of the required space or licensing terms),


Space might be an argument, but I don't think licensing is. The grids are produced by the USGS and USGS data is freely available (one thing we can still take pride in post-election).
 

but we could generate +nadgrids=@bla syntax to make them optional. What could be useful is to have both +nadgrids= and +towgs84 with the priority given to the grids when they are present


That would be a very nice solution.
 

but this isn't implemented right now in proj.4 (if you have both +nadgrids and +towgs84, I believe +nadgrids is always used, even if the grids are missing on the system)

 

As far as adding the grid info, in the current workflow, this would be a matter of doing that in the https://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/build_pcs.py script, presumably adding a new column in the gcs.csv file, and some logic/dictionary to match the datum name with a grid name, and then updating GDAL to use that new information when reading the .csv files.


I took a look at that workflow a few years ago before the modernization and backed off from it, but I'm interested in looking at it again. Not being very familiar with build_pcs.py or the epsg database, this is a pretty naive question, but why aren't the nadgrids being reference already? Is the issue with the build_pcs.py script or with the epsg database? 

--
Richard W. Greenwood, PLS
www.greenwoodmap.com



--
Richard W. Greenwood, PLS
www.greenwoodmap.com

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

Re: HARN nadgrid files

support-2
In reply to this post by rgreenwood

Hello,


It looks like the reasons why grid shift files are not much used or referenced is that usually there are other ways available to fix small map errors ... and using grid shift files would require too much knowledge in the subject ... and also give too much unrequired accuracy since the source material is already so much off the line. So most users and applications are happy with the towgs84 mechanism.


Other questions with grid shift files are:

How much their usage slows down the end product that uses Proj.4 library?

How difficult their usage is for end users to be realistic that they ever used them?

How could the above questions (or problems) be fixed the most easy way (for the end user)? Meaning that adding more good code to Proj.4 and/or choosing better data formats instead of writing more complex manuals would be preferred.


Janne.


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


Richard Greenwood kirjoitti 2016-12-22 22:40:

I've been following a few of the recent threads on this list regarding enhancements to Proj's datum transformations. Pretty exciting stuff! 
 
One group of transformations that seems to have been ignored for a number of years is applying the HARN hpgn grids in the Proj epsg file. For example the Proj epsg entry for epsg:3758 uses +towgs84=0,0,0,0,0,0,0 but I believe that is should use +nadgrids=wyhpgn.gsb, or at least that's what I change it to, which produces results that match NADCON.
 
Is anyone aware of a reason that nadgrids are not referenced in the epsg file? Is it maybe just an oversight, something that nobody ever got around to? Or because distributing nadgrids would become burdensome?
 
It seems like pretty low hanging fruit. HARN has been around for about 20 years. The nadgrid files are already there. Differences between +towgs84=0,0,0,0,0,0,0 and +nadgrids=XXhpgn.gsb are on the order of a meter in the few places I have looked, so it's a fairly significant correction (or error, depending on your point of view).  "grep -c HARN epsg" returned 264 and "grep -c 'hpgn' epsg" returned 0, so effects a lot of definitions.
 
Maybe I'm missing something. I'd be interested in any comments.
 
Rich
 

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

Re: HARN nadgrid files

rgreenwood
On Mon, Dec 26, 2016 at 11:47 PM, <[hidden email]> wrote:

Hello,

It looks like the reasons why grid shift files are not much used or referenced is that usually there are other ways available to fix small map errors ... and using grid shift files would require too much knowledge in the subject ... and also give too much unrequired accuracy since the source material is already so much off the line. So most users and applications are happy with the towgs84 mechanism.

I don't think most users have any idea what datum transformation is being used. But they do expect results that match other geospatial software.
 

Other questions with grid shift files are:

How much their usage slows down the end product that uses Proj.4 library?

 I'd venture to guess that grid transformations are computationally less expensive than 7 parameter transformations. 

How difficult their usage is for end users to be realistic that they ever used them?


I'm proposing changes only to the "epsg" file that is a part of the Proj.4 distribution.  However this would require that the hpgn grids here https://trac.osgeo.org/proj/wiki/HarnGrids be included in the Proj.4 distribution. They are 354kB zipped. There are at least two grid files in the nad/ directory that are already part of the distribution. But as time goes by we see more, and larger, grid shift files. So I can see some resistance to adding more.
 

How could the above questions (or problems) be fixed the most easy way (for the end user)? Meaning that adding more good code to Proj.4 and/or choosing better data formats instead of writing more complex manuals would be preferred.

Even Rouault suggested adding code that would use the +nadgrids definition if the required grid shift file was present, otherwise the +towgs84 definition would be used.


Janne.


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


Richard Greenwood kirjoitti 2016-12-22 22:40:

I've been following a few of the recent threads on this list regarding enhancements to Proj's datum transformations. Pretty exciting stuff! 
 
One group of transformations that seems to have been ignored for a number of years is applying the HARN hpgn grids in the Proj epsg file. For example the Proj epsg entry for epsg:3758 uses +towgs84=0,0,0,0,0,0,0 but I believe that is should use +nadgrids=wyhpgn.gsb, or at least that's what I change it to, which produces results that match NADCON.
 
Is anyone aware of a reason that nadgrids are not referenced in the epsg file? Is it maybe just an oversight, something that nobody ever got around to? Or because distributing nadgrids would become burdensome?
 
It seems like pretty low hanging fruit. HARN has been around for about 20 years. The nadgrid files are already there. Differences between +towgs84=0,0,0,0,0,0,0 and +nadgrids=XXhpgn.gsb are on the order of a meter in the few places I have looked, so it's a fairly significant correction (or error, depending on your point of view).  "grep -c HARN epsg" returned 264 and "grep -c 'hpgn' epsg" returned 0, so effects a lot of definitions.
 
Maybe I'm missing something. I'd be interested in any comments.
 
Rich
 

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



--
Richard W. Greenwood, PLS
www.greenwoodmap.com

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