Thanks Even, that worked perfectly. Mike
On 4/11/11 1:29 PM, "Even Rouault" <even.roua...@mines-paris.org> wrote: > Le lundi 11 avril 2011 18:47:16, Chaitanya kumar CH a écrit : >> Mike, >> >> Can you provide the version number and perhaps a sample dataset that shows >> this problem? > > No, need for it. This is the "expected" behaviour by looking at the code of > the PGEO driver. It will be able to fetch the SRS only when working directly > with layers, not with SQL requests. You could try specifying the -dialect > OGRSQL option to ogr2ogr, in which case the SQL will be evaluated by OGR SQL > engine and not by the ODBC engine. The OGRSQL engine should be able to > retrieve the SRS from the layer. > >> >> On Mon, Apr 11, 2011 at 9:51 PM, Smith, Michael D ERDC-CRREL-NH < >> >> michael.sm...@usace.army.mil> wrote: >>> All, >>> >>> Using GDAL trunk, I can read and reproject a personal geodatabase using >>> the internal projection as the source projection. However, when I use >>> sql (as I need to add a new field to the output), the source projection >>> can no longer be read. >>> >>> C:\temp>ogr2ogr -t_srs EPSG:4326 -f "ESRI Shapefile" temp1.shp >>> CL_01_LDS_20101201_A.mdb CL_01_LDS_20101201_A_Contour_Smoothed >>> Warning 6: Normalized/laundered field name: 'Shape_Length' to >>> 'Shape_Leng' >>> >>> C:\temp>ogr2ogr -t_srs EPSG:4326 -f "ESRI Shapefile" temp1.shp >>> CL_01_LDS_20101201_A.mdb -sql "select * from >>> CL_01_LDS_20101201_A_Contour_Smoothed" >>> Can't transform coordinates, source layer has no coordinate system. Use >>> -s_srs to set one. >>> >>> Mike >>> >>> >>> -- >>> Michael Smith >>> Remote Sensing/GIS Center >>> US Army Corps of Engineers >>> >>> >>> >>> _______________________________________________ >>> gdal-dev mailing list >>> gdal-dev@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
