Changes between Version 1 and Version 2 of MapRotation
- Timestamp:
- Jan 29, 2009, 12:19:28 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MapRotation
v1 v2 1 1 = Producing Rotated Maps = 2 2 3 MapServer 4.3 (as of May 25th, 2004) includes the experimental ability to render rotated maps implemented by FrankWarmerdam.3 !MapServer 4.3 (as of May 25th, 2004) includes the experimental ability to render rotated maps implemented by FrankWarmerdam. 4 4 5 5 == Via .map file == … … 35 35 == Usage Limitations == 36 36 37 While the map is rendered rotated, the fact that it is rotated is not preserved in the form variables used in regular MapServer cgi mode. That is, subsequent zoom, recenter, query and other operations will not be aware of the rotation and will not take the rotation into account when mapping screen locations to georeferenced space.37 While the map is rendered rotated, the fact that it is rotated is not preserved in the form variables used in regular !MapServer cgi mode. That is, subsequent zoom, recenter, query and other operations will not be aware of the rotation and will not take the rotation into account when mapping screen locations to georeferenced space. 38 38 39 In short, rotation is primaril iy useful inMapScript where the rotation can be generated and taken into account explicitly.39 In short, rotation is primarily useful in !MapScript where the rotation can be generated and taken into account explicitly. 40 40 41 41 Internally rotation is hidden internally as if it was part of the reprojection operation. Thus for rotation to work properly it is currently necessary to include a valid projection object on the map and every layer of the map. If no real reprojection is needed the projection objects should contain the same projection definition. … … 53 53 This geotransform[] represents an affine transformation capable of accounting for offset, shear and rotation. The geotransform is the same (primary) means used by GDAL to relate pixel/line and georeferenced coordinates in a raster context. 54 54 55 The geotransform is carried in a geotransformObj structure in MapServer. It looks like this:55 The geotransform is carried in a geotransformObj structure in !MapServer. It looks like this: 56 56 {{{ 57 57 #!c … … 90 90 Rather than change this, the approach taken was to "trick" the vector renderer by applying the rotation within the reprojection operation and resetting the EXTENTS and cellsize information to some arbitrary coordinate system during the render operation. 91 91 92 In practice this is accomplished by altering the extents and cellsize temporarily within the msDrawMap?() function (mapObj->draw() in MapScript). A EXTENT value of "0 0 <width_in_pixels> <height_in_pixels>" is used during rendering and the projectionObj on the map is altered take care of mapping from map georeferenced coordinates to this pseudo-coordinate system during the projection operation.92 In practice this is accomplished by altering the extents and cellsize temporarily within the msDrawMap?() function (mapObj->draw() in !MapScript). A EXTENT value of "0 0 <width_in_pixels> <height_in_pixels>" is used during rendering and the projectionObj on the map is altered take care of mapping from map georeferenced coordinates to this pseudo-coordinate system during the projection operation. 93 93 94 94 So when the various vector rendering functions convert the vertice locations between layer georeferenced coordinates and map georeferenced coordinates the extra geotransform transformation is applied. However, in the actual vector rendering code there is no awareness of the geotransform and the fake extents and cellsize are being used. While this seems to work properly, it may cause problems in the future.
