[gdal-dev] warp from ch1903 to google maps(mercator) projection - what t_srs to use

Nikos Alexandris nikos.alexandris at felis.uni-freiburg.de
Thu Feb 14 20:41:21 EST 2008


Hi!

Although I am probably not helping you any further...

On Fri, 2008-02-15 at 00:50 +0100, Vasile Cotovanu wrote:
> Hello all, this is my first post on this list, first of all I want to
> congratulate anybody involved in this fantastic library ! 
> 
> I have an issue that is fixed with a workaround but I want to avoid
> this workaround, here it is : 
> 
> I'm using gdalwarp to reproject imagery from EPSG:21781 (CH 1903) to
> Google Maps (mercator based) projection. 

...please note that there is a difference between

"CH1903 / LV03" -> EPSG:21781

and

"CH1903" -> EPSG:4149

> 
> Currently I have been using for -t_srs the suggestion from this blog
> entry
> http://www.sharpgis.net/post/2007/07/26/The-Microsoft-Live-Maps-and-Google-Maps-projection.aspx
> 
> so 
> 
> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 
> +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs 
> 
> which defines a perfect sphere(not ellipsoid) but i am not happy with 
> the results because : 
> - if i am transforming the bounds of image from CH1903 to WGS84 and 
> then to Google Maps pixel coordinate system, the result will be a 
> parallelogram (it is normal, the image will be distorted from CH1903 
> to Mercator) that can be included in a box with a pair of width/height
> in pixels 
> - if i am using gdalwarp the result will be a distorted image (again 
> it's normal) with another pair of width/height. 
> 
> The expected result after tis 2 operations would be 2 pairs of
> width/height WITH SAME ration width/height. However, this issue can be
> fixed by FORCING the gdalwarp "-ts width 
> height" parameter and imagery it's just drawn fine. 
> 
> So my question is, in order not to do this workaround, can you tell
> me 
> if you use another -t_srs value, and if yes, which one ? 
> 
> I suppose that should be different for each zoom level, as GoogleMaps
> does use different radius for each zoom level. (on zoom level 0 the
> imagery is drawn in a single tile 256x256 pixels, so the radius will
> be circumference/(2*pi()) pixels , on zoom 1 : circumference is 512
> px, then radius is 2 times bigger than zoom level 0, etc) 
> 
> Thank you in advance, 
> Vasile Cotovanu 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
-- 
Nikos Alexandris
.
Department of Remote Sensing & Landscape Information Systems
Faculty of Forestry & Environmental Sciences, Albert-Ludwigs-University Freiburg
.
Tel.  +49 (0) 761 203 3697 / Fax.  +49 (0) 761 203 3701 / Skype: Nikos.Alexandris
.
Address: Tennenbacher str. 4, D-79106 Freiburg i. Br., Germany
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.osgeo.org/pipermail/gdal-dev/attachments/20080215/4d9cf0b2/attachment-0001.bin


More information about the gdal-dev mailing list