[Gdal-dev] ogr2ogr Default Output SRS

[Martin Spott]

Bill Thoen wrote:
> Am I missing something here? When I use ogr2ogr to export a shapefile I
> don't have to specify an output SRS; it seems happy to use the one
> specified in the geometry_columns table. But when I try to export a
> MapInfo tab file I MUST specify either -t_srs or -a_srs or I get a error
> saying it couldn't open the file with any of its drivers.

Do we probably see an effect where 'ogr2ogr' behaves different
depending on the surrounding environment ?

I'd like to explain a case where I recently got into trouble with the
output SRS ....  and, to be honest, where I wish to get pointed at a
place where to look for the source of the trouble. I hope people will
read my explanation even though it'll get a bit longer ....

Everything takes place on the same machine. I'm using 'ogr2ogr' for the
purpose of importing VMap0 data into a PostGIS DB. I've compiled
'ogr2ogr' from gdal-1.3.2 together with proj-4.4.9, geos-2.2.3 and
ogdi-3.1.5 as 32-bit binaries, because ODGI doesn't work as 64 bit
binary. These tools remain unchanged !

On the server side I use PROJ.4 4.4.9 and GEOS 2.1.1 as shipped with
the Debian Sarge distribution in order to build PostGIS. And here comes
the difference.
First try with PostgreSQL-8.1.4/PostGIS-1.1.3, second try with
PostgreSQL-8.2.0/PostGIS-1.1.6. I don't change any flag that I use with
'ogr2ogr' (the respective shell script is still the same) and the
binary is exactly the same (as mentioned before), still the SRID in the
resulting table is different !?!?!

This is how I'm proceeding. In the result table of the first try
(postgresql-8.1.4/postgis-1.1.3) the CONSTRAINT
enforce_srid_wkb_geometry is tied to EPSG 4326, in the second try
(postgresql-8.2.0/postgis-1.1.6) it ready EPSG 32767 and both tables
actually _do_ cointain the expected data. How is such behaviour
triggered !?


foxtrot: ~> /opt/GRASS/bin/ogrinfo -ro -summary gltp:/vrf/home/martin/live/vmap0/v0eur/vmaplv0/eurnasia 'swampa at veg(*)_area'
INFO: Open of `gltp:/vrf/home/martin/live/vmap0/v0eur/vmaplv0/eurnasia'
using driver `OGDI' successful.

Layer name: swampa at veg(*)_area
Geometry: Polygon
Feature Count: 12511
Extent: (-10.371299, 40.065544) - (179.999900, 75.659821)
Layer SRS WKT:
GEOGCS["NAD83",
    DATUM["North_American_Datum_1983",
        SPHEROID["GRS 1980",6378137,298.257222101,
            AUTHORITY["EPSG","7019"]],
        TOWGS84[0,0,0,0,0,0,0],
        AUTHORITY["EPSG","6269"]],
    PRIMEM["Greenwich",0,
        AUTHORITY["EPSG","8901"]],
    UNIT["degree",0.0174532925199433,
        AUTHORITY["EPSG","9108"]],
    AXIS["Lat",NORTH],
    AXIS["Long",EAST],
    AUTHORITY["EPSG","4269"]]
id: Integer (10.0)
f_code: String (5.0)
veg: Integer (5.0)
tile_id: Integer (5.0)
fac_id: Integer (10.0)

foxtrot: ~> /opt/GRASS/bin/ogr2ogr -f PostgreSQL 'PG:host=localhost user=martin dbname=landcover' -t_srs "EPSG:4326" gltp:/vrf/home/martin/live/vmap0/v0soa/vmaplv0/soamafr -where f_code=BH095 -nln marsh_temp 'swampa at veg(*)_area'

foxtrot: ~> echo "\d marsh_temp" | psql
                                 Tabelle »public.marsh_temp«
    Spalte    |      Typ      |                          Attribute
--------------+---------------+--------------------------------------------------------------
 ogc_fid      | integer       | not null default nextval('marsh_temp_ogc_fid_seq'::regclass)
 wkb_geometry | geometry      |
 id           | numeric(10,0) |
 f_code       | character(5)  |
 veg          | numeric(5,0)  |
 tile_id      | numeric(5,0)  |
 fac_id       | numeric(10,0) |
Indexe:
    »marsh_temp_pk« PRIMARY KEY, btree (ogc_fid)
Check-Constraints:
    »enforce_dims_wkb_geometry« CHECK (ndims(wkb_geometry) = 2)
    »enforce_geotype_wkb_geometry« CHECK (geometrytype(wkb_geometry) = 'POLYGON'::text OR wkb_geometry IS NULL)
    »enforce_srid_wkb_geometry« CHECK (srid(wkb_geometry) = 32767)

foxtrot: ~> echo "select count(ogc_fid) from marsh_temp;" | psql
 count
-------
  1849
(1 Zeile)


Any ideas ? I could revert to using PostgreSQL-8.1.4/PostGIS-1.1.3 but
I guess the same should work with PostgreSQL-8.2.0/PostGIS-1.1.6 as
well ?

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