[Mapcss] MapCSS 0.2 finalization - zoom levels

Peter Wendorff wendorff at uni-paderborn.de
Fri May 4 14:58:03 BST 2012


Hi.
In the c-lab (university of Paderborn, Germany) a MapCSS renderer 
written in .NET/C# is currently in development as part of a MapFramework 
[1].
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.

some thoughts:
1) assume, a zoomscale selector is mapped to the zoomscale in the maps 
center.
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 
zoomscales directly

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 
versa.

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 
any zoomlevel.
2.2.2) ignore the rules - bad idea, the map is incomplete, as many rules 
are missing.
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 
non-tiled projection
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?

regards
Peter

[1] 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 mailing list