[MetaCRS] Re: [postgis-users] st_transform, irreversible?

Mikael Rittri Mikael.Rittri at carmenta.com
Mon Aug 23 04:03:44 EDT 2010


Erik Rehn wrote:

> The solution to that was to add "+towgs84=414.1,41.3,603.1,-0.855,2.141,-7.023,0"
> to the spatial_ref_sys table for srid 3021. Why isn't that in there by default?

Paul Ramsey wrote:

> It should be, our spatial_ref_sys is generated from gdal which generates from epsg. 

To be precise, gdal gets datum shifts from libgeotiff which generates them from epsg. 
The datum shift appropriate for each geodetic datum is taken from the file 

	gcs.csv

In the latest version of libgeotiff (1.3.0, May 2010), there are still many 
geodetic datums that lack a datum shift in this file.  The Swedish RT90 is 
just one example.  

The problem is that a geodetic datum, in the EPSG data model, does not 
have any component that is a unique and perfect datum shift to WGS84.  
The datum shifts (or "coordinate transformations") are separate entities
that can connect any geodetic datum to any other.  So, a specific
geodetic datum like RT90 may in the EPSG database have no, one, or 
many datum shifts to WGS84.  

The selection of a single datum shift for each datum is not trivial.  
Libgeotiff is conservative, and selects a datum shift only if there
is exactly one possibility in EPSG (there may be some manual exceptions 
to this rule.) For RT90, there are unfortunately two datum shifts available
in EPSG, since there is an older datum shift that is "superseded" but not 
"deprecated".  The horizontal difference between the two alternatives 
is about 6 centimeters in average... 

As I understand it, there is work in progress to implement a better
way to extract datum shifts from EPSG.  In the libgeotiff trunk,

http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/

there are many more datum shifts in gcs.csv.

Best regards,
  Mikael Rittri
  Carmenta AB
  Sweden
  www.carmenta.com

-----Original Message-----
From: metacrs-bounces at lists.osgeo.org [mailto:metacrs-bounces at lists.osgeo.org] On Behalf Of Paul Ramsey
Sent: den 17 augusti 2010 18:17
To: erik at slagkryssaren.com; PostGIS Users Discussion
Cc: metacrs at lists.osgeo.org
Subject: [MetaCRS] Re: [postgis-users] st_transform, irreversible?

It should be, our spatial_ref_sys is generated from gdal which generates from epsg. You have a pretty recent postgis, so I'm surprised it's missing.
P

On Tue, Aug 17, 2010 at 1:57 AM, Erik Rehn <erik at slagkryssaren.com> wrote:
> Thank you guys! You were right, I had flipped the coordinates in the 
> test I made.
>
> But that didn't explain the error I got in the KML. The solution to 
> that was to add "+towgs84=414.1,41.3,603.1,-0.855,2.141,-7.023,0" to 
> the spatial_ref_sys table for srid 3021. Why isn't that in there by default?
>
> erik
>
> On 2010-08-12 17:05, Ricardo Bayley wrote:
>>
>> very nice explanation Mike
>>
>> On Thu, Aug 12, 2010 at 11:39 AM, Mike Toews <mwtoews at gmail.com 
>> <mailto:mwtoews at gmail.com>> wrote:
>>
>>    Hi,
>>
>>    Your coordinates may be flipped. Was it 59N 18E? If so, use x,y
>>    notation: 'POINT(18 59)', which results in 'POINT(18.0000000000006
>>    58.9999999999905)', which is close enough.
>>
>>    Also keep in mind that you are outside the projection bounds:
>>    http://spatialreference.org/ref/epsg/3021/ (just a bit too far east).
>>    Whenever you are outside the projection bounds, the likelihood of
>>    storage precision errors increase. To understand why this is, you 
>> can
>>    think of taking the tangent of a two angles that are nearly a
>>    right-angle (89.9991 and 89.9992) which have very different 
>> results
>>    due to nature of the geometry.
>>
>>    -Mike
>>
>>    On 11 August 2010 13:10, Erik Rehn <erik at slagkryssaren.com
>>    <mailto:erik at slagkryssaren.com>> wrote:
>>     > Hello Postgis Users!
>>     >
>>     > This is my first post on this list so I will start by asking
>>     > a simple (and probably stupid) question. :)
>>     >
>>     > While using ST_AsKml() to produce an overlay for Google Earth I
>>     > noticed that all my geometries where shifted slightly south-east.
>>     > I figured this had something to do with the transformation 
>> between
>>     > the projection that my geometries are stored in (SRID 3021) and
>>    WGS84 (4326)
>>     > that is outputted by ST_AsKml()
>>     >
>>     > Just to test I ran this:
>>     >
>>     > SELECT ST_AsText(
>>     >    ST_Transform(
>>     >        ST_Transform(
>>     >            ST_GeomFromText('POINT(59 18)',4326),
>>     >        3021),
>>     >    4326));
>>     >
>>     > I input a point in WGS84 (59,18), transforms it to 3021 and 
>> then
>>    back to
>>     > WGS84. The result I get is:
>>     > POINT(58.8672757036296 18.0394763349359)
>>     >
>>     > Can anyone explain this? Am I missing something regarding
>>    ST_Transform()?
>>     >
>>     > Im running Postgis 1.5 on Windows.
>>     >
>>     > Thank you for any help!
>>     > /Erik
>>     >
>>     > --
>>     > Erik Rehn
>>     > Slagkryssaren
>>     > erik at slagkryssaren.com <mailto:erik at slagkryssaren.com>
>>     > www.slagkryssaren.com <http://www.slagkryssaren.com>
>>     > _______________________________________________
>>     > postgis-users mailing list
>>     > postgis-users at postgis.refractions.net
>>    <mailto:postgis-users at postgis.refractions.net>
>>     > http://postgis.refractions.net/mailman/listinfo/postgis-users
>>     >
>>    _______________________________________________
>>    postgis-users mailing list
>>    postgis-users at postgis.refractions.net
>>    <mailto:postgis-users at postgis.refractions.net>
>>    http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>
> --
> Erik Rehn
> Slagkryssaren
> erik at slagkryssaren.com
> www.slagkryssaren.com
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
_______________________________________________
MetaCRS mailing list
MetaCRS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/metacrs


More information about the MetaCRS mailing list