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

[Richard Matsunaga]

Yes, I do assign the SRS, particularly with the CSV case, where it is
required. I found another old post indicating that you need to use s_srs,
but that doesn't cause the SRID to get set at all.

Richard

> -----Original Message-----
> From: gdal-dev-bounces at lists.maptools.org 
> [mailto:gdal-dev-bounces at lists.maptools.org] On Behalf Of 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.
> 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev