Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-19 Thread 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@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.29998,
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,50],
PARAMETER[false_northing,50],
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,50],
PARAMETER[false_northing,50],
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


Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-19 Thread Even Rouault
Le dimanche 20 février 2011 00:24:16, Marius Jigmond a écrit :
 
 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,

The .prj file of shapefiles stores WKT in ESRI WKT, not OGC WKT. 
http://trac.osgeo.org/gdal/changeset/21627 (which is a fix not found in 1.8.0) 
translates the ESRI Stereographic into the OGC Oblique_Stereographic, to 
be consistant with what is done in the reverse transformation

 
 -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


Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-19 Thread Marius Jigmond
Should it then match http://spatialreference.org/ref/epsg/3844/esriwkt/
because it does not seem to? I apologize if my questions seem silly.

-marius

On Sun, 2011-02-20 at 00:38 +0100, Even Rouault wrote: 
 Le dimanche 20 février 2011 00:24:16, Marius Jigmond a écrit :
  
  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,
 
 The .prj file of shapefiles stores WKT in ESRI WKT, not OGC WKT. 
 http://trac.osgeo.org/gdal/changeset/21627 (which is a fix not found in 
 1.8.0) 
 translates the ESRI Stereographic into the OGC Oblique_Stereographic, to 
 be consistant with what is done in the reverse transformation
 
  
  -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


Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-19 Thread Even Rouault
Le dimanche 20 février 2011 00:46:07, Marius Jigmond a écrit :
 Should it then match http://spatialreference.org/ref/epsg/3844/esriwkt/
 because it does not seem to? I apologize if my questions seem silly.

With all respect due to the great job of that site, I'm not sure you can 
blindly trust spatialreference.org to be always a genuine reference (I'm not 
sure that in the world of SRS, there is *a* reference ...). The data in there 
comes from the output of various software packages, including GDAL or 
GeoTools, that might not be the most recent ones and have some bugs. This WKT 
with the space in Oblique_Stereographic is likely coming from GeoTools.  See 
http://www.osgeo.org/pipermail/metacrs/2008-December/000187.html that gives 
some hint on where data of spatialreference.org comes from.

Anyway, with latest GDAL trunk, if I do a ogr2ogr -a_srs EPSG:3844 
foo_3844.shp foo.shp,

foo_3844.prj is :

PROJCS[Pulkovo_1942_58_Stereo70,GEOGCS[GCS_Pulkovo 
1942(58),DATUM[D_Pulkovo_1942_Adj_1958,SPHEROID[Krassowsky_1940,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,50],PARAMETER[false_northing,50],UNIT[Meter,1]]

And ogrinfo reads it back as :

PROJCS[Pulkovo_1942_58_Stereo70,
GEOGCS[GCS_Pulkovo 1942(58),
DATUM[Pulkovo_1942_58,
SPHEROID[Krassowsky_1940,6378245,298.3]],
PRIMEM[Greenwich,0],
UNIT[Degree,0.017453292519943295]],
PROJECTION[Oblique_Stereographic],
PARAMETER[latitude_of_origin,46],
PARAMETER[central_meridian,25],
PARAMETER[scale_factor,0.99975],
PARAMETER[false_easting,50],
PARAMETER[false_northing,50],
UNIT[Meter,1]]

which is nearly identical to the output of gdalinfo (except that the 
ESRI'fication loses the AUTHORITY nodes)

 
 -marius
 
 On Sun, 2011-02-20 at 00:38 +0100, Even Rouault wrote:
  Le dimanche 20 février 2011 00:24:16, Marius Jigmond a écrit :
   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,
  
  The .prj file of shapefiles stores WKT in ESRI WKT, not OGC WKT.
  http://trac.osgeo.org/gdal/changeset/21627 (which is a fix not found in
  1.8.0) translates the ESRI Stereographic into the OGC
  Oblique_Stereographic, to be consistant with what is done in the
  reverse transformation
  
   -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


[gdal-dev] gdal_rasterize 1.8.0 options

2011-02-04 Thread Marius Jigmond
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.

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?

-marius

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-04 Thread Marius Jigmond
Eli,

Both input datasets (mask and raster) exist, which is why 1. works.
Option 1 doesn't use any of version 1.8.0 flags, which is why I thought
something else was introduced behind the scenes with the new flags.

-marius

On Fri, 2011-02-04 at 12:08 -0800, Eli Adam wrote: 
 Marius,
 
 I don't know about 1. but possibilities for 2. and 3 below.  
 
  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.
  
  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?
 
 Does sample.tif exist?  If not, the docs say you need to use -tr or -ts, 
 Since GDAL 1.8.0, the target GDAL file can be created by gdal_rasterize. One 
 of -tr or -ts option must be used in that case.  I don't know why that error 
 would not also come from 1. 
 
 
 Bests, Eli
 
  
  -marius
  
 
 
 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-04 Thread Eli Adam
Marius,

I don't know about 1. but possibilities for 2. and 3 below.  

 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.
 
 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?

Does sample.tif exist?  If not, the docs say you need to use -tr or -ts, Since 
GDAL 1.8.0, the target GDAL file can be created by gdal_rasterize. One of -tr 
or -ts option must be used in that case.  I don't know why that error would 
not also come from 1. 


Bests, Eli

 
 -marius
 


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


Re: [gdal-dev] gdal_rasterize 1.8.0 options

2011-02-04 Thread Marius Jigmond


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

Thanks.

 
  
  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.

Thanks for the clarification as it's not apparent from the web page.
Would have loved the -a_nodata to be available for existing datasets.

 
  
  -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