| Version 1 (modified by , 14 years ago) ( diff ) |
|---|
World Mapping Issues
This is an old version of the World Mapping Issues from around 2005, see World Mapping Issues for a more up to date report on issues. This text is retained for context and in case some things aren't addressed in the new topic.
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. 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.
I will start with this excellent email message from Dan Stahlke, but will try to better organize the optic later.
There are three bugs that show up when using an orthographic projection (other projections are affected too) in WMS-client mode with a source in geographic projection:
- If the projection is valid along the borders, but contains the north pole, the source bounding box will not be correct. In these cases the whole grid needs to be sampled in order to determine the source bounds. Perhaps this should be a processing parameter option?
- If there are invalid points on a particular scanline, the whole scanline fails. The problem is that pj_transform returns a failure and the whole scanline is discarded by mapserver. It seems like pj_transform should transform valid points and set invalid ones to HUGE_VAL, but this is not the case. Maybe this is a bug in proj4... the manpage doesn't really say what the behavior should be in this case.
- If the destination image contains the -180/180 border, there will be a stripe of invalid data there. The pixels that are near 180 degrees longitude will correspond to points in the source image that are up to 0.5 pixels past the right-hand edge of the image. It seems to me that somewhere in GDALGetGeoTransform? there is a 0.5 that is inappropriately added. A quick fix is to allow a one-pixel margin of error in msSimpleRasterResampler?.
Attached to this message is an example map file and perl script that will demonstrate the problems. The zoomed-in image will have a blank area near the north pole and the zoomed-out image will only draw the center third: the top and bottom will be blank. There is also a quick-hack patch that shows a workaround for these problems.
As a side note, it would be nice to have an option that causes a higher-res source image to be downloaded in order to avoid the oversampling effect that sometimes happens (the demo script included with this message produces a noticably pixelated image).
- Dan Stahlke
See also: http://trac.osgeo.org/mapserver/ticket/723
After the above patch, you may need this one if you are using WMS cascading with global extents:
http://trac.osgeo.org/mapserver/ticket/740
BBOX handling across the antimeridian: http://trac.osgeo.org/mapserver/ticket/25
Linework:
Lines will inevitably either disappear off the edge of the globe (for projections like orthographic) or jump across cut regions (such as -180 => 180 in geographic projection or across cuts in Goode's Homolosine). It will be hard in general to test whether a line jumps across a cut. Perhaps the best way would be to test whether the length of the line is too long. If a line is too long or if one endpoint doesn't project then the line should be recursively subdivided. Long lines should be subdivided even if they don't do anything funny, so that they will trace out great-circle arcs rather than just being straight.
Filled polygons will be much harder. They could be recursively subdivided into quadrants... It will take a lot of subdivisions to draw a polygon that disappears off the edge of a curved surface (such as the edge of the globe in orthographic projection).
