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

[Kurt Schwehr]

What about adding this to the command line?  It seemed to work for us  
with S57 data conversion.  We did that and then tried renaming the  
table to be lower case (alter table "CBLARE" rename to cblare;) but  
were then still not able to get mapserver/openlayers to display, so  
this might not be the solution....

ogr2ogr -a_srs "EPSG:4326" ...

-kurt


On Jun 26, 2007, at 5:01 PM, gdal-dev-request at lists.maptools.org wrote:

> Message: 9
> Date: Tue, 26 Jun 2007 17:00:18 -0400
> From: "Richard Matsunaga" <richard.matsunaga at waypointinfo.com>
> Subject: [Gdal-dev] RE: ogr2ogr to PostGIS gives wrong SRID?
> To: "'gdal-dev'" <gdal-dev at lists.maptools.org>
> Message-ID: <008801c7b835$00994290$cd012b0a at Richard>
> Content-Type: text/plain;	charset="US-ASCII"
>
>
> 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.