[Gdal-dev] RE: ogr2ogr to PostGIS gives wrong SRID?

[Frank Warmerdam]

Randy George wrote:
> Hi,
> 
>  
> 
> I am attempting to use ogr2ogr to load some shp files into PostGIS
> 
> When translating a .shp file that is in EPSG:2239 and reprojecting to 
> EPSG:4326 like this:
> 
>  
> 
> ogr2ogr -f PostgreSQL PG:"user=user dbname=GA host=localhost 
> password=pass port=5432" 06_ZoneA.shp -s_srs EPSG:2239 -t_srs EPSG:4326 
> -nln test –append
> 
>  
> 
> The resulting table has correct coords but not a valid srid:
> 
> "SRID=32771;LINESTRING(-81.3993398544517 
> 31.4233644295052,-81.4019931984873 31.4217494430945,-81.4036082752935 
> 31.4205958831135,-81.4047618947201 31.4192116162976,-81.4062616063205 
> 31.4179427019781,-81.407645959851 31.4171352080714,-81.4096071087392 
> 31.4144 (..)"

Randy,

What is happening is that ogr2ogr is expanding EPSG:4326 into the
full well known text definition.  It is then doing a comparison of this
WKT to all the WKT values in the spatial_ref_sys table, and when no
match is found it creates and populates a new entry in the table with
code 32771 (the next free value).  Then it assigns this value to the table
and all geometries.

There is nothing inherently wrong with this, but it makes it difficult mix
the geometries with other geometries using SRID 4326.

The assumption that SRID is the same as EPSG code is not exactly true -
it just happens that the default set of SRIDs are matched with EPSG.

Unfortunately I don't see a creation option to allow forcing use of
a particular pre-existing SRID with the PG driver.  I think there is
already an enhancement request for this in bugzilla, but you might want
to verify that, and file one if you can't find such a request.

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