why doesn't the epsg file reference the hpgn grids?

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

why doesn't the epsg file reference the hpgn grids?

rgreenwood
The epsg file included with proj has definitions for hpgn coordinate systems that do not use the grid shift files, for example:
# NAD83(HARN) / Wyoming West (ftUS)
<3758> +proj=tmerc +lat_0=40.5 +lon_0=-110.0833333333333 +k=0.9999375 +x_0=800000 +y_0=100000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs  <>

So there is no datum transformation applied. But proj has the appropriate harn grid shift files here:

And changing the above definition to include the grid shift files like below seems more appropriate:
# NAD83(HARN) / Wyoming West (ftUS)
<3758> +proj=tmerc +lat_0=40.5 +lon_0=-110.0833333333333 +k=0.9999375 +x_0=800000 +y_0=100000 +ellps=GRS80 +nadgrids=wyhpgn.gsb +units=us-ft +no_defs  <>

Does the proj epsg file get created from data at www.epsg.org? And is that data lacking the reference to the grid shift files, or is it "lost in translation"? It seems like there is the wonderful resource in the harn grids that isn't getting used, but maybe I'm overlooking something.

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: why doesn't the epsg file reference the hpgn grids?

peifer
On 2015-03-18 2:59, Richard Greenwood wrote:
>
> Does the proj epsg file get created from data at www.epsg.org
> <http://www.epsg.org>? And is that data lacking the reference to the
> grid shift files, or is it "lost in translation"? It seems like there is
> the wonderful resource in the harn grids that isn't getting used, but
> maybe I'm overlooking something.
>

Here a few observations, from a simple user perspective:
There is a somewhat complex (mysterious?) epsg-to-csv conversion process
with "upstream" elements around libgeotiff and "downstream" locations
near PROJ.4, which results in ever surprising changes in the generated
lookup files.

The changes are partly based on EPSG database updates (which is fine, of
course) but also on changing conversion logic: about which parameter set
to select in case of several available, which numeric precision to
choose when converting radians from EPSG into arc seconds used in
towgs84 values, and so on.

There are plenty of helpful grid shift files listed at
http://trac.osgeo.org/proj/wiki, but PROJ.4's epsg lookup table lists
none of them, only the null grid appears there:

$ grep nadgrids local/share/proj/epsg
<3785> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
+y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs <>
<3857> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
+y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs <>

There haven't been many releases of PROJ lately, which brought some
stability into coordinate transformations, as the positive side-effect
of an otherwise sad story. However, this is expected to change and what
I did anyway some time ago was to add my own lookup table as
local/share/proj/hermann in order to gain control over my own
transformations.

Now I can use: +init=hermann:4314, which resolves to my transformation
parameters (+proj=longlat +ellps=bessel +nadgrids=BETA2007.gsb), whereas
epsg:4314 translates to: +proj=longlat +datum=potsdam +no_defs

Hope this helps, Hermann


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

Re: why doesn't the epsg file reference the hpgn grids?

Even Rouault-2
Selon Hermann Peifer <[hidden email]>:

> On 2015-03-18 2:59, Richard Greenwood wrote:
> >
> > Does the proj epsg file get created from data at www.epsg.org
> > <http://www.epsg.org>? And is that data lacking the reference to the
> > grid shift files, or is it "lost in translation"? It seems like there is
> > the wonderful resource in the harn grids that isn't getting used, but
> > maybe I'm overlooking something.
> >
>
> Here a few observations, from a simple user perspective:
> There is a somewhat complex (mysterious?) epsg-to-csv conversion process
> with "upstream" elements around libgeotiff and "downstream" locations
> near PROJ.4, which results in ever surprising changes in the generated
> lookup files.

As an open source code, there is no real "mystery" involved, although it is
indeed non trivial. The process is decently documented here :
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README

>
> The changes are partly based on EPSG database updates (which is fine, of
> course) but also on changing conversion logic: about which parameter set
> to select in case of several available, which numeric precision to
> choose when converting radians from EPSG into arc seconds used in
> towgs84 values, and so on.
>
> There are plenty of helpful grid shift files listed at
> http://trac.osgeo.org/proj/wiki, but PROJ.4's epsg lookup table lists
> none of them, only the null grid appears there:
>
> $ grep nadgrids local/share/proj/epsg
> <3785> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
> +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs <>
> <3857> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
> +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs <>
>
> There haven't been many releases of PROJ lately, which brought some
> stability into coordinate transformations, as the positive side-effect
> of an otherwise sad story. However, this is expected to change and what
> I did anyway some time ago was to add my own lookup table as
> local/share/proj/hermann in order to gain control over my own
> transformations.

As most of the "heavy" grids are not directly distributed with proj, it might be
tricky to propose a reasonable +nadgrids parameter. Although we could use the @
syntax to make their presence optional. But there's currently no way of doing
the association between a datum and corresponding grids when the "raw" CSV files
are processed in the gcs.csv/pcs.csv. Perhaps something similar to
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/datum_shift_pref.csv
could be used.

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: why doesn't the epsg file reference the hpgn grids?

peifer
On 2015-03-18 4:53, Even Rouault wrote:
> Selon Hermann Peifer <[hidden email]>:
>
>> Here a few observations, from a simple user perspective: (...)
>
> As an open source code, there is no real "mystery" involved, although it is
> indeed non trivial. The process is decently documented here :
> http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README
>

In my first line, I mentioned the "simple user" on purpose. The one who
might not know what SVN or trunk is, or who might not speak English in
the first place (there is machine translation, I know..)

Don't understand me wrong: local/share/epsg is more than fine for
beginners, but somewhat advanced users might want to have more control
and stability when it comes to transformation parameters, at least I do.

I also did not mention that the meaning of e.g. +datum=potsdam changed
over the few years I have been using PROJ. The potsdam datum seems to be
hard-wired into pj_datums.c.

$ grep potsdam pj_datums.c
"potsdam",  "towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7", ...

I assume that earlier changes to pj_datums.c were yet another downstream
processing step. I can only assume, as this isn't mentioned in the
indicated README.

In summary: local/share/epsg is probably as fine as it can be, I do
however feel safer when using local/share/hermann.

Hermann

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

Re: why doesn't the epsg file reference the hpgn grids?

rgreenwood
In reply to this post by Even Rouault-2
On Tue, Mar 17, 2015 at 9:53 PM, Even Rouault <[hidden email]> wrote:
 
As most of the "heavy" grids are not directly distributed with proj, it might be
tricky to propose a reasonable +nadgrids parameter. Although we could use the @
syntax to make their presence optional.

What is the "@ syntax"? 
 
But there's currently no way of doing
the association between a datum and corresponding grids when the "raw" CSV files
are processed in the gcs.csv/pcs.csv. Perhaps something similar to
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/datum_shift_pref.csv
could be used.

I'm still unclear as to how epsg.org addresses grid shifts. I randomly surfed thru the files in http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/ and found no clues. It seems like it would be nice to enhance the processing of the epsg.org source definitions to reference grid shift files if possible. By "if possible" I mean if there is sufficient information in the epsg.org source definitions to do that. If not, then I agree that something like datum_shift_pref.csv would be good.

Thanks,
Rich


 

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

Re: why doesn't the epsg file reference the hpgn grids?

rgreenwood
In reply to this post by peifer
 be used.
On Tue, Mar 17, 2015 at 9:32 PM, Hermann Peifer <[hidden email]> wrote:

I did anyway some time ago was to add my own lookup table as
local/share/proj/hermann in order to gain control over my own
transformations.

Now I can use: +init=hermann:4314, which resolves to my transformation
parameters (+proj=longlat +ellps=bessel +nadgrids=BETA2007.gsb), whereas
epsg:4314 translates to: +proj=longlat +datum=potsdam +no_defs

Hermann, thank you for the suggestion. I'm doing the same thing (creating my own lookup file) which of course works fine for me, but doesn't help anyone else. I believe that there are about 600 coordinate systems in the Proj4 epsg file that say "HARN" but do actually reference the HARN grid shift files, nor give the user any obvious clues that these grid files are available and could, and should, be used.

Thanks,
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: why doesn't the epsg file reference the hpgn grids?

Mikael Rittri

A problem with using HARN/HPGN is that the grid files overlap each other,

but they don’t agree with each other in the common areas. I don’t know what

the best practice is, but this and similar problems are discussed here:

 

http://trac.osgeo.org/csmap/wiki/CsMapRfc7

 

Best regards,

 

Mikael Rittri

Carmenta

Sweden

http://www.carmenta.com

 


From: [hidden email] [mailto:[hidden email]] On Behalf Of Richard Greenwood
Sent: Wednesday, March 18, 2015 3:18 PM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] why doesn't the epsg file reference the hpgn grids?

 

 be used.

On Tue, Mar 17, 2015 at 9:32 PM, Hermann Peifer <[hidden email]> wrote:


I did anyway some time ago was to add my own lookup table as
local/share/proj/hermann in order to gain control over my own
transformations.

Now I can use: +init=hermann:4314, which resolves to my transformation
parameters (+proj=longlat +ellps=bessel +nadgrids=BETA2007.gsb), whereas
epsg:4314 translates to: +proj=longlat +datum=potsdam +no_defs

 

Hermann, thank you for the suggestion. I'm doing the same thing (creating my own lookup file) which of course works fine for me, but doesn't help anyone else. I believe that there are about 600 coordinate systems in the Proj4 epsg file that say "HARN" but do actually reference the HARN grid shift files, nor give the user any obvious clues that these grid files are available and could, and should, be used.

Thanks,

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: why doesn't the epsg file reference the hpgn grids?

Andre Joost
In reply to this post by peifer
Am 18.03.2015 um 05:39 schrieb Hermann Peifer:

>
> I also did not mention that the meaning of e.g. +datum=potsdam changed
> over the few years I have been using PROJ. The potsdam datum seems to be
> hard-wired into pj_datums.c.
>
> $ grep potsdam pj_datums.c
> "potsdam",  "towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.7", ...
>
> I assume that earlier changes to pj_datums.c were yet another downstream
> processing step. I can only assume, as this isn't mentioned in the
> indicated README.


The change of the potsdam datum was a follow-up of this openstreetmap
forum topic: http://forum.openstreetmap.org/viewtopic.php?id=12723

Since high-resolution aerial image was georeferenced with a better
transformation than the 3-parms used before, there was a need to adjust
the proj.4 datum definition.

BTW: In the same file you find the only predefined usage of datum shift
grids, NADCON/CONUS for the US and ntv2 for Canada.

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

Re: why doesn't the epsg file reference the hpgn grids?

peifer
In reply to this post by rgreenwood
On 2015-03-18 15:17, Richard Greenwood wrote:

>   be used.
> On Tue, Mar 17, 2015 at 9:32 PM, Hermann Peifer <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     I did anyway some time ago was to add my own lookup table as
>     local/share/proj/hermann in order to gain control over my own
>     transformations.
>
>     Now I can use: +init=hermann:4314, which resolves to my transformation
>     parameters (+proj=longlat +ellps=bessel +nadgrids=BETA2007.gsb), whereas
>     epsg:4314 translates to: +proj=longlat +datum=potsdam +no_defs
>
>
> Hermann, thank you for the suggestion. I'm doing the same thing
> (creating my own lookup file) which of course works fine for me, but
> doesn't help anyone else. I believe that there are about 600 coordinate
> systems in the Proj4 epsg file that say "HARN" but do actually reference
> the HARN grid shift files, nor give the user any obvious clues that
> these grid files are available and could, and should, be used.
>

[1] has source_crs_code and target_crs_code, plus the
coord_op_method_code. I get some 80+ results when looking for
coord_op_method_code = 9615 = NTv2. There might be other hints in other
csv files.

Another example, directly from EPSG database: [2]. Obviously, there are
other grid shift file formats, which I however don't use, as the NTv2
format is nowadays quite popular, here in Europe.

Hermann

[1]
http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/coordinate_operation.csv 


[2]
http://epsg-registry.org/export.htm?wkt=urn:ogc:def:coordinateOperation:EPSG::5338
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj