EPSG 7.9 Upgrade in Trunk

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

EPSG 7.9 Upgrade in Trunk

Frank Warmerdam
Folks,

I have upgraded libgeotiff, PROJ.4 and GDAL with EPSG definitions regenerated
from the EPSG 7.9 database.  New "preferred datum shift selection" rules are
also in place which will give preference to 7 parameter datum shifts over
3 parameter datum shifts are also in place causing a fair amount of churn
in the definitions.

The updates are in "trunk" for each of the projects.  I plan to produce
libgeotiff and PROJ.4 release candidates soon with the new definitions
so if you think you might have objections please investigate and speak
up promptly.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/warmerda
and watch the world go round - Rush    | Geospatial Software Developer

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

Re: EPSG 7.9 Upgrade in Trunk

hamish-2
Frank wrote:

> I have upgraded libgeotiff, PROJ.4 and GDAL with EPSG
> definitions regenerated from the EPSG 7.9 database.  New
> "preferred datum shift selection" rules are also in place which
> will give preference to 7 parameter datum shifts over
> 3 parameter datum shifts are also in place causing a fair
> amount of churn in the definitions.
>
> The updates are in "trunk" for each of the projects.
> I plan to produce libgeotiff and PROJ.4 release candidates
> soon with the new definitions so if you think you might have
> objections please investigate and speak up promptly.

Hi,

as per
  https://trac.osgeo.org/proj/ticket/122
and
  https://trac.osgeo.org/grass/ticket/1452  [*]

pre-selecting datum transform terms on our behalf, while at the
same time removing all indication of what the +datum originally
was, really fouls things up for GRASS, and more locally for all
us EPSG file users in New Zealand, where tectonic shear from
the west coast to the east is on the order of about 4cm/year
over a distance of hundred km or so & the choice in the matter
has a rather big impact on our results / it's good to be forced
to specify which flavor your dealing with.

Ideally, for datums known to the osgeo stack I'd beg for the
+datum term be reinstated and that datum transform terms not be
decided on our behalf, with no way to back out of the pre-
selected choice.

More generally it means we can't really use the epsg file as a
semi-authoritative source of what some given epsg code refers
to anymore. :-(


--
ignoring my argument that it isn't really possible/a good idea,
and just assuming that it is possible to choose between 7-term
vs. 3-term vs. grid file as the sensible default, it is my
understanding that the 7-term solutions are in general only
valid (respected?) in a much smaller geographic area than the
3-term ones. aka 7-term does not necessarily mean more correct,
and if the epsg code covers a wide area, in much of the region
a locale-specific 7-term solution would be the worse choice
than a less precise 3-term solution. ISTR that Cliff(??) had
published an article about this paradox some time ago.
 


thanks,
Hamish


*see also
 https://trac.osgeo.org/grass/browser/grass/trunk/lib/proj/datum.c#L59

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

Re: EPSG 7.9 Upgrade in Trunk

support.mn
In reply to this post by Frank Warmerdam
Frank,

I hate geotiff since it does not carry the full information inside the
tiff file but can make an outside reference which nobody knows
where it leads. One should not allow any external references
except those that were once available when the geotiff was
created since all current and old programs can not handle new
external references since they do not carry the fresh database
with them. New definitions should carry all the data inside the
geotiff file but does geotiff even allow you to have any free datum
or similar?

The whole geotiff should be rewritten so that it would be more
stable and able to handle all current and future references
without any updates to the standard or databases. Preferably
a standard that would not need any external databases (which
BTW: the proj.4 definition almost is [if you count out those few
ellipses and datum names]).

Regards: Janne.

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


Frank Warmerdam [[hidden email]] kirjoitti:

> Folks,
>
> I have upgraded libgeotiff, PROJ.4 and GDAL with EPSG definitions regenerated
> from the EPSG 7.9 database.  New "preferred datum shift selection" rules are
> also in place which will give preference to 7 parameter datum shifts over
> 3 parameter datum shifts are also in place causing a fair amount of churn
> in the definitions.
>
> The updates are in "trunk" for each of the projects.  I plan to produce
> libgeotiff and PROJ.4 release candidates soon with the new definitions
> so if you think you might have objections please investigate and speak
> up promptly.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> light and sound - activate the windows | http://pobox.com/warmerda
> and watch the world go round - Rush    | Geospatial Software Developer
>
> _______________________________________________
> 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: EPSG 7.9 Upgrade in Trunk

Mikael Rittri
In reply to this post by Frank Warmerdam
Not a prompt reply, but anyway:

I noticed that for the British datum OSGB 1936, gcs.csv in the libgeotiff trunk ( http://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv ) uses
the 3-parameter datum shift

        EPSG:1195, "OSGB 1936 to WGS 84(1)", accuracy 21 m.

I would have expected the more accurate 7-parameter datum shift

        EPSG:1314, "OSGB 1936 to WGS 84(6), accuracy 2 m.

This is a special case of the ticket

        http://trac.osgeo.org/geotiff/ticket/33

and since the general case won't be fixed, I suggest that OSGB 1936
needs special treatment (in datum_shift_pref.csv).

> New "preferred datum shift selection" rules are also in place which
> will give preference to 7 parameter datum shifts over 3 parameter
> datum shifts

You mean that some 7 parameter datum shifts are listed as preferred
in datum_shift_pref.csv ?  Because in build_pcs.py, I couldn't see
that 7-parameter shifts are preferred over 3-parameter shifts in general (but maybe I missed it).

Best regards,

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Frank Warmerdam
Sent: Thursday, September 29, 2011 9:04 AM
To: PROJ.4 and general Projections Discussions; GeoTIFF; gdal-dev
Subject: [Proj] EPSG 7.9 Upgrade in Trunk

Folks,

I have upgraded libgeotiff, PROJ.4 and GDAL with EPSG definitions regenerated
from the EPSG 7.9 database.  New "preferred datum shift selection" rules are
also in place which will give preference to 7 parameter datum shifts over
3 parameter datum shifts are also in place causing a fair amount of churn
in the definitions.

The updates are in "trunk" for each of the projects.  I plan to produce
libgeotiff and PROJ.4 release candidates soon with the new definitions
so if you think you might have objections please investigate and speak
up promptly.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/warmerda
and watch the world go round - Rush    | Geospatial Software Developer

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