Hi Even, I'm not trying to re-ignite the stereo debate but I think there's more to the issue with the warning. I've realized that the particular EPSG code 3844 (not sure about others) is reported totally different by ogrinfo and gdalinfo. It's not the actual reporting that's wrong but the way -a_srs is applied by ogr2ogr versus gdal_translate. Below is an example: marius@mobi:~/data/romania/test$ gdalinfo RGB321-K-34-005.tif Driver: GTiff/GeoTIFF Files: RGB321-K-34-005.tif Size is 2985, 2775 Coordinate System is: PROJCS["Pulkovo 1942(58) / Stereo70", GEOGCS["Pulkovo 1942(58)", DATUM["Pulkovo_1942_58", SPHEROID["Krassowsky 1940",6378245,298.2999999999998, AUTHORITY["EPSG","7024"]], AUTHORITY["EPSG","6179"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4179"]], PROJECTION["Oblique_Stereographic"], PARAMETER["latitude_of_origin",46], PARAMETER["central_meridian",25], PARAMETER["scale_factor",0.99975], PARAMETER["false_easting",500000], PARAMETER["false_northing",500000], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AUTHORITY["EPSG","3844"]] Origin = (96676.434833699619048,290247.117718913941644) Pixel Size = (14.256214353408733,-14.256214353408733) ...
marius@mobi:~/data/romania/test$ ogrinfo -where 'FID=0' -geom=summary -fields=no ../caroiaje/caroiaje_100k_EPSG3844.shp caroiaje_100k_EPSG3844 INFO: Open of `../caroiaje/caroiaje_100k_EPSG3844.shp' using driver `ESRI Shapefile' successful. Layer name: caroiaje_100k_EPSG3844 Geometry: Polygon Feature Count: 1 Extent: (94505.736838, 203681.624680) - (905494.263162, 771251.195001) Layer SRS WKT: PROJCS["Stereographic", GEOGCS["GCS_Krassovsky, 1942", DATUM["unknown", SPHEROID["krass",6378245,298.3]], PRIMEM["Greenwich",0], UNIT["Degree",0.017453292519943295]], PROJECTION["Stereographic"], PARAMETER["latitude_of_origin",46], PARAMETER["central_meridian",25], PARAMETER["scale_factor",0.99975], PARAMETER["false_easting",500000], PARAMETER["false_northing",500000], UNIT["Meter",1]] INDICATIV: String (25.0) OGRFeature(caroiaje_100k_EPSG3844):0 POLYGON : 65 points Is the disconnect simply a reporting issue and reprojections are handled properly behind the scenes when using this EPSG code? It seems that what gdalinfo reports is in accordance to http://spatialreference.org/ref/epsg/3844/html/ . -marius On Sat, 2011-02-05 at 00:06 +0100, Even Rouault wrote: > Le vendredi 04 février 2011 20:25:43, Marius Jigmond a écrit : > > Hi Everyone, > > > > Some of the options (I didn't test all) introduced with version 1.8.0 > > seem to behave strangely. Here's what I'm doing: > > 1. gdal_rasterize -burn 0 -i -l mask mask.shp sample.tif > > works fine but I get the following warning: > > Warning : the output raster dataset and the input vector layer do not > > have the same SRS. > > Results might be incorrect (no on-the-fly reprojection of input data). > > even though both inputs use the same projection, EPSG:3844. > > Unrelated with GDAL 1.8.0. The issue was that the transformation between OGC > WKT and ESRI WKT didn't handle well the Oblique Stereographic projection. > Fixed in trunk in http://trac.osgeo.org/gdal/changeset/21627 > > > > > 2. gdal_rasterize -burn 0 -i -a_srs EPSG:3844 -l mask mask.shp > > sample.tif > > fails with: '-tr xres yes' or '-ts xsize ysize' is required. > > > > 3. gdal_rasterize -burn 0 -i -a_nodata 0 -l mask mask.shp sample.tif > > fails with: '-tr xres yes' or '-ts xsize ysize' is required. > > > > >From http://www.gdal.org/gdal_rasterize.html it doesn't seem that -a_srs > > or -a_nodata would require -tr or -ts. Am I doing something wrong? > > When those 2 new options are used, they imply creating a new dataset. So they > actually need to be used with -tr or -ts option. > > > > > -marius > > > > _______________________________________________ > > 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