[postgis-users] Comparing two WKT... howto?

Luigi Pirelli l.pirelli at acsys.it
Fri Nov 19 05:58:13 PST 2004


thanks,

I did some test following your suggestions.
This some results using this two data set:

A) in grass current location
    g.proj -wf
WKT = PROJCS["UTM Zone 32, Northern 
Hemisphere",GEOGCS["international",DATUM["European_Datum_1950",SPHEROID["international",6378388,297],TOWGS84[-87.000,-98.000,-121.000]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",9],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["meter",1]]

    g.proj -jf
PROJ4 = +proj=utm +zone=32 +a=6378388 +rf=297 +no_defs 
+towgs84=-87.000,-98.000,-121.000

B) select * from spatial_ref_sys where srid=23032 (should be the same projection)
WKT = 
PROJCS["ED_1950_UTM_Zone_32N",GEOGCS["GCS_European_1950",DATUM["D_European_1950",SPHEROID["International_1924",6378388,297]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",500000],PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",9],PARAMETER["Scale_Factor",0.9996],PARAMETER["Latitude_Of_Origin",0],UNIT["Meter",1]]
PROJ4 = +proj=utm +zone=32 +ellps=intl +units=m

I roughly tested with IsSame method (class OGRSpatialReference).... they differ!
but their PROJ4 representation using exportToProj4 method of the same class is 
slightly different and this is the result:

A.WKT->exportToProj4 = "+proj=utm +zone=32 +ellps=intl 
+towgs84=-87.000,-98.000,-121.000 +units=m +no_defs"

B.WKT->->exportToProj4 = "+proj=utm +zone=32 +ellps=intl +units=m +no_defs"

differs only in +towgs84 string.




I tried to do a reverse test using g.proj grass command (ok is OT in this list) 
and it seems that g.proj is not able to recognise its product. e.g.

g.proj -jf
+proj=utm +zone=32 +a=6378388 +rf=297 +no_defs +towgs84=-87.000,-98.000,-121.000

g.proj -jf > temp.txt
g.proj -wf wkt=./temp.txt
XY location (unprojected) <- it cannot reverse!

I've no found a unique (or not customised) solution :-(

Thaks for your help.

Regards, Luigi Pirelli
www.riade.net
www.acsys.it


Frank Warmerdam wrote:
> Luigi Pirelli wrote:
> 
>> Hi,
>>
>> I've this problem, I've to compare two WKT strings (first extracted 
>> bye spatial_ref_sys PostGis table and second from g.proj -wf Grass 
>> commad).
>>
>> They differ in format but they refer to the same projection (e.g 
>> ellipsoy could expressed by symbolic name or geometric parameters)
>>
>> There's applications of library that help to compare them?
>>
>> could be simplest to compare PROJ4 strings (+format)?
> 
> 
> Luigi,
> 
> Good question(s)!  In general comparing coordinate systems can be 
> challenging.
> 
> Comparing PROJ.4 strings will often be easier than comparing WKT but if 
> the PROJ.4
> representations are produced by different software (or by hand!) then 
> arguments
> are likely to be in different orders and one definition may contain 
> parameters
> that are just the defaults, and omitted from the other.   Ideally PROJ.4 
> itself
> would have a comparison function but currently it does not.
> 
> If comparing WKT strings you pretty much have to have an "in depth" 
> comparitor
> since lots stuff, such as coordinate system names, can differ with no real
> significance.  Likewise there are lots of optional elements in WKT that may
> appear in one representation and not another with no real significance.
> 
> If both definitions include an AUTHORITY definition on the root level 
> object,
> you have a short cut available to compare the authority codes.  If those 
> match
> you aren't required to check everything else.
> 
> In the GDAL/OGR library, the OGRSpatialReference class includes an IsSame()
> method that can be used to compare two coordinate systems generated from
> WKT.  But to be honest, the implementation is far from complete.  If within
> the context of what you are doing you know you will have OGR available I
> would suggest using that method, and then we can cooperate to make it 
> better
> if/when you run into limitations.
> 
> Best regards,



More information about the postgis-users mailing list