Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

This question is an exact duplicate of:

This seems to be an old problem with an already known solution (ie. "...stop using 900913 and start using 3857..."), but not sure whether this problem is about software versions, the raster itself or just projections.

The thing is that I did a quite big raster (TIFF image + its PGW projection text file based on lon/lat values) with the software GMT (Generic Mapping Tools). It covers a big area (range: -83ºW, -75ºW, -17ºS,-5ºS). Its center is around -79ºS and -11ºS. To produce it, GMT requires both the lon/lat ranges and the projection. For the former I used the previous lon/lat range and for the latter I used a Mercator projection and a arbitrary width (in GMT language: -JM10i). So, the output raster was beautifully produced (as usual), and I loaded into my HTML with OL (of course) and served by Mapserver (as WMS). It overlays google, bing and esri base maps (so in MAP file I added the corresponding EPSG:4326 and 900913 as usual, and the latter was added to the epsg file in the /usr/share/proj directory, plus the usual "projection" and "displayProjection" calls in OL).

So, it loaded normally as the other ones served by Mapserver (I have some more TIFF like this one, ie. GMT raster, but much more small ones, ie. less area). However, I noticed that around -80ºS and -8ºS, it should line up with other WMS layers (eg. seismic lines) but it didn't (it has an offset of ~3 km to the north in regard to other WMS layers), so I started changing things (900913 by 3857) in my MAP file and the HTML but nothing, the problem didn't go away. Interestingly, I did some tests and merged all the TIFFs and got only a unique TIFF (ie. new range: -83 W,-70 W,-19 S,-5 S), and this one produced an offset of ~10 km (instead of 3 km at the same location). Also, I loaded all the WMS layers and used the unique TIFF as base layer (because all the WMS layers served by Mapserver are in epsg4326), but the erroneous offset is still there.

So, I was wondering if this problem could be caused by the OL 2.11, or Mapserver 5.6.7 and Proj 4.8.0 (these two are RPMs from ELGIS for RHEL5) I'm using. Another possibility is that the -JM10i used in GMT to generate the TIFF was the problem, or it is because the TIFF area (in lon/lat) covers two UTM zones (UTM zone 17 South and UTM zone 18 South).

I think the "EPSG:900913 or EPSG:3857" thing is not the problem. After testing both in Mapserver and OL, I checked in Firebug and saw that the request (SRS=EPSG) were the same for both cases, ie. when 900913 was used it appeared SRS=EPSG=900913, and when 3857 was used: SRS=EPSG=3857. I also read that using either one of them it should work all in the same way (even though this may imply the other way: http://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/). In my case I prefer using 900913 because google v3 uses it as far as I know.

I hope someone could enlighten me here and provide me a solution,

Thanks in advance,

Gery

share|improve this question

marked as duplicate by Devdatta Tengshe, BradHards, Fezter, iant May 26 '13 at 15:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

    
It is not a point of preferring the code number. The special treatment of the projection on a sphere instead of an ellipsoid is solved in GDAL with EPSG:3857, but in EPSG:900913 it is wrong. –  Andre Joost Jan 23 at 18:53
add comment

1 Answer 1

up vote 0 down vote accepted

I found the solution, "divide and conquer". After I cut the image in small pieces, they aligned correctly with google and my other layers. As I supposed from the beginning, this problem is because this big raster crosses two UTM zones (17 and 18 south), and the normal stretching must occur close to the Equator (its northern edge gets up to 5ºS). Thus, epsg:900913/epsg:3857 exposes clearly this problem or conflict when dealing with epsg:4326. Hope this helps some people dealing with misalignment of rasters (served by whatever they are served) and google (900913).

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.