World Mapping Issues
There are various issues in doing world scale mapping with MapServer. Some related to crossing the anti-meridian (the dateline), and some related to conversion between lat/long and polar projections near the pole, and some related to attempts to map off the bounds of validity of some projections (ie. over the horizon). This topic is intended to act as a location to discuss some of the issues, include hints, and collect a set of use-cases that break but that we want to make work.
An older version of this discussion from around 2005 may also be of some interest, though in some respects the situation has changed.
Rendering Lines Over Dateline
When lines are read from a projected data source, and reprojected into geographic coordinates for rendering it is common the have lines drawn across the width of the map. For instance, if the world is rendered, Siberia line segments may stretch across the map from -180 to +180 since line segments that cross the dateline will suddenly go from near -180 to near +180. This is discussed in #15.
A solution has been put in place to attempt to do special processing when reprojecting vectors from projected coordinates to geographic coordinates (msProjectShape()). Basically, preference is given to rewrapping shapes so that they cross the dateline rather than warping to the other side of the world. In the case of a small linestring or polygon crossing the dateline it may end up with extents like -185 to -175 longitude rather than a bit of stuff between -175 and -180 and a bit of stuff between 175 and 180. This logic is found in msTestNeedWrap() and msProjectShapeLine() in mapproject.c.
In the case of world spanning polygons this logic can sometimes mis-fire resulting in features getting stretched over more than 360 degrees.
Rendering features multiple times when requested bounding box spans the Dateline
When the request is for extent wider or taller the valid input data range it would be useful to duplicate each feature more times to cover the whole extent. This would be tipically useful for long-lat data where a point at -180,0 may also be represented as being at 180,0 and at 540,0 and at -540,0 and so on. The idea is that rather than starting from input and project each point to output a opposite strategy should be taken (take each of the output pixel and find what's there).
It has been reported by Frank [1] that the suggested strategy is already in place for raster layers but only if they undergo resampling.
Note that geoserver recently added support for this: http://blog.geoserver.org/2010/02/23/geoserver-map-wrapping/.
[1] http://lists.osgeo.org/pipermail/mapserver-dev/2010-February/009713.html
BBOX Transformation
One fairly common use case is maps rendered in projected coordinates but read from geographic raster sources (sometimes a cascaded WMS). In these cases the projected map region needs to be reprojected into lat/long and used to fetch raster data for resampling. If the projected rectangle crosses the dateline it is easy to end up requesting a window of data that wraps around the world. This wouldn't be so bad, but because MapServer tries to request raster data from remote WMSes or raster files at roughly the size of the output map it ends up getting much lower resolution data in the actual area of interest than will be needed to render well. This problem is addressed in #3179.
The most important outcome of this investigation is that PROJ.4 supports a +over flag that disables the wrapping of longitude into the range -180 to 180 by PROJ.4. This means that projected values east of the -180 dateline will be returned as longitudes less than -180 rather than wrapping around to +180. This makes all sorts of bounding rectangle and other issues much smoother.
eg.
PROJECTION "+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +units=m +over +no_defs" END
