| 17 | | 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 addresed in #3179. |
| | 17 | 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. |
| | 18 | |
| | 19 | 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. |
| | 20 | |
| | 21 | eg. |
| | 22 | {{{ |
| | 23 | PROJECTION |
| | 24 | "+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +units=m +over +no_defs" |
| | 25 | END |
| | 26 | }}} |
