[Gdal-dev] Fwd: Gdal-dev Digest, Vol 31, Issue 22

[Alejandro Silva]

---------- Forwarded message ----------
From: gdal-dev-request at lists.maptools.org <
gdal-dev-request at lists.maptools.org>
Date: 10-dic-2006 18:02
Subject: Gdal-dev Digest, Vol 31, Issue 22
To: gdal-dev at lists.maptools.org

Send Gdal-dev mailing list submissions to
        gdal-dev at lists.maptools.org

To subscribe or unsubscribe via the World Wide Web, visit
        http://lists.maptools.org/mailman/listinfo/gdal-dev
or, via email, send a message with subject or body 'help' to
        gdal-dev-request at lists.maptools.org

You can reach the person managing the list at
        gdal-dev-owner at lists.maptools.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gdal-dev digest..."


Today's Topics:

   1. Re: ogr2ogr Default Output SRS (Martin Spott)
   2. Re: ogr2ogr Default Output SRS (Frank Warmerdam)


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

Message: 1
Date: Sat, 9 Dec 2006 19:15:43 +0000 (UTC)
From: Martin Spott <Martin.Spott at mgras.net>
Subject: Re: [Gdal-dev] ogr2ogr Default Output SRS
To: gdal-dev at lists.maptools.org
Message-ID: <elf20v$oag$1 at osprey.mgras.de>

Hi Frank, thanks for responding,

Frank Warmerdam wrote:

> There are some "sensitivities" in how ogr2ogr identifies which SRID to use
> in postgis.  If it doesn't find a match then it creates a new SRID at the
> "top" of the table, which I suspect did for the 32767 case.
>
> It may be that the spatial_ref_sys tables in your different versions of
> postgis are slightly different in the formatting of the WKT entries and
> this is in one SRID 4326 gets used and in the other it doesn't.

But what can a user actually do about this, whose "fault" is it if
'ogr2ogr' and PostGIS don't place together nicely, and, which I
consider even more important, which route to take to solve this issue ?

Apparently PostGIS started shipping newer versions of the
spatial_ref_sys table with 1.1.6 and 'ogr2ogr' somehow doesn't 'agree'
with the contents of this table.
I just ran a test with PostGIS-1.2.0 - same effect as with 1.1.6, still
using the respective spatial_ref_sys that comes with the very PostGIS
release. I then pushed the contents of the spatial_ref_sys table from
PostGIS-1.1.5 into the DB, still running PostGIS-1.2.0, and everything
is fine. So, is this sort of a bug in 'ogr2ogr' that shows some
incapability to handle newer EPSG declarations or is this to be
considered as a misfeature in the recent EPSG files that breaks
'ogr2ogr' ?

Cheerio,
        Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------


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

Message: 2
Date: Sun, 10 Dec 2006 00:24:34 -0500
From: Frank Warmerdam <warmerdam at pobox.com>
Subject: Re: [Gdal-dev] ogr2ogr Default Output SRS
To: Martin.Spott at mgras.net
Cc: gdal-dev at lists.maptools.org
Message-ID: <457B9A12.6080906 at pobox.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Martin Spott wrote:
> Hi Frank, thanks for responding,
>
> Frank Warmerdam wrote:
>
>> There are some "sensitivities" in how ogr2ogr identifies which SRID to
use
>> in postgis.  If it doesn't find a match then it creates a new SRID at the
>> "top" of the table, which I suspect did for the 32767 case.
>>
>> It may be that the spatial_ref_sys tables in your different versions of
>> postgis are slightly different in the formatting of the WKT entries and
>> this is in one SRID 4326 gets used and in the other it doesn't.
>
> But what can a user actually do about this, whose "fault" is it if
> 'ogr2ogr' and PostGIS don't place together nicely, and, which I
> consider even more important, which route to take to solve this issue ?

Martin,

Normally there is no great harm in creating a new SRID for what is a
slightly different formatting of a coordinate system that from a
meaningful point of view matches an existing SRID.

However, the solution, I think would be for OGR to:

  o Do the search based on the proj.4 string rather than the WKT.
    The proj.4 strings are less likely to suffer from formatting
    variations over time.

  o Provide a mechanism (a layer creation option for instance) so
    that the user can force use of a particular SRID whether OGR
    thinks the coordinate systems match or not.

> Apparently PostGIS started shipping newer versions of the
> spatial_ref_sys table with 1.1.6 and 'ogr2ogr' somehow doesn't 'agree'
> with the contents of this table.
> I just ran a test with PostGIS-1.2.0 - same effect as with 1.1.6, still
> using the respective spatial_ref_sys that comes with the very PostGIS
> release. I then pushed the contents of the spatial_ref_sys table from
> PostGIS-1.1.5 into the DB, still running PostGIS-1.2.0, and everything
> is fine. So, is this sort of a bug in 'ogr2ogr' that shows some
> incapability to handle newer EPSG declarations or is this to be
> considered as a misfeature in the recent EPSG files that breaks
> 'ogr2ogr' ?

Note that the spatial_ref_sys for PostGIS is generated with OGR.  So
there is no reason to believe the newer spatial_ref_sys will differ
from what newer OGR versions expect.  Upgrading GDAL/OGR may therefore
help.

Generally speaking comparing coordinate systems is *hard*.  Especially if
you wish to do so efficiently.

If you file a bug against OGR with the two earlier suggestions, I'll try
and have them implemented at some point.  Ideally in time for the GDAL
1.4.0 release.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam,
warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org



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

_______________________________________________
Gdal-dev mailing list
Gdal-dev at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/gdal-dev

End of Gdal-dev Digest, Vol 31, Issue 22
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20061211/6c07d66b/attachment.html