[gdal-dev] gdal_rasterize 1.8.0 options

[Marius Jigmond]

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 at 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 at 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 at lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>