[Mapcss] MapCSS 0.2 finalization - zoom levels
wendorff at uni-paderborn.de
Fri May 4 14:58:03 BST 2012
In the c-lab (university of Paderborn, Germany) a MapCSS renderer
written in .NET/C# is currently in development as part of a MapFramework
Therefore, as the mapframework is in principle able to handle arbitrary
map projections, even the mapcss rendering engine may be used in
non-tiled map-projections, too (at least in theory).
Practical considerations for our current use cases use tile based maps,
only, but the map framework itself should be able to do more.
For the "users" (application programmers) point of view this map
framework uses the zoomscale in the view center as common unit and
derives zoomlevels from that according to the map region shown (scaling
bitmaps up or down when using tile based maps to fit intermediate scales).
I think, it's probably worth to consider even a zoomscale for rules
selectors, but the best solution should probably be figured out.
1) assume, a zoomscale selector is mapped to the zoomscale in the maps
1.1) Would work for many "zoomed-in" maps, that only show "small" areas
of the world.
1.2) fits, if there's no static pre-rendering, as the map may change
it's view while panning around
1.3) for tile based, prerendered projections it's not possible to use
2) We could provide both options. Let's look at (a) the display
projection and (b) the defined zoom selectors (scale, level, both, none)
2.1) A renderer rendering tiles prefers selectors to zoomlevel and vice
2.2) If there's no zoomlevel selector, but a zoomscale selector, a
tile-based renderer can
2.2.1) map zoomlevels to zoomscales (e.g. assume a average - let's say,
sth. around 30° North/South) - relatively simple to do in this
direction, why not?
2.2.1) ignore the selectors - bad idea, as all rules would be applied to
2.2.2) ignore the rules - bad idea, the map is incomplete, as many rules
Comparing 2.2.1 and 2.2.2 both are bad, but probably acceptable -
depends on stylesheet purpose and rendering purpose, I think
2.3) If there's only a zoomlevel selector, but the renderers uses a
2.3.1) the renderer may derive the "zoomlevel" applied to a specific
part of the world/map and using the matching selectors here. That's
probably difficult, I don't know how to do that best ;)
In general the drawback of the zoomlevel approach for woldwide
renderings is, that it's quite different between areas near the equator
and areas near the poles.
Btw: Is there any selector yet to allow the definition of different
zoomscales necessary to display the same icons depending on the area?
 http://www.mapframework.de (while the front page is in German, the
documentation itself is mostly (not sure if completely) in English)
Am 04.05.2012 15:00, schrieb Komяpa:
> 2012/5/1 Richard Fairhurst<richard at systemed.net>:
>> On 01/05/2012 14:47, Paul Hartmann wrote:
>>> In my opinion, it should be the same in MapCSS and the definition of the
>>> zoom selector should be based on map scale rather than on the projected
>>> coordinates in the Mercator projection.
> Here we come to usual problem:
> - those who came from traditional maps think in scales;
> - those who came from web-GIS think in zoom levels.
> There's no useful "scale" in EPSG:3857 - it changes depending on
> latitude. So it is possible that renderer has to mix styles for
> different scales in one screen.
> If you're using a different projection, and it's majorly different
> from EPSG:3857, you have no "default" tiles grid.
> Do we have any real application now that uses not EPSG:3857 aka
> Spherical Mercator for rendering?
More information about the Mapcss