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

[Richard Matsunaga]

Frank, I recovered this post from the archives. 

I have the same problem, where I am converting files (CSV, SHP, TAB) to
PostGIS and it is creating a new SRID for them (although this doesn't seem
all that consistent - but at any rate it isn't using the pre-existing EPSG
4326 that I want it to).

The real problem that I'm having with this is that GeoServer doesn't like
the assigned SRID, since it is using it to search for the EPSG code and
failing. I can force the EPSG 4326, but this is all part of an automated
process and for file formats with embedded SRS, the user shouldn't have to
worry about setting the EPSG.

It seems very odd that when converting a CSV file (with a VRT) and assigning
the SRS of EPSG:4326 that it would create a new entry in the spatial_ref_sys
table.

It also seems like it would be nice to carry around the EPSG code in some
cases, especially if the WKT is preferred over the proj4 representation and
the WKT diverges from the "master" EPSG definition.

Richard


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.