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<[email protected]>:
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?
_______________________________________________
Mapcss mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/mapcss
