On 07/06/2011 11:54 PM, Alex Zolotarev wrote:
Would you please list some "special cases" which are not supported yet?
First of all the database queries for the individual layers.
Fortunately the interaction between database query and Filter seems to
be relatively simple: Either all conditions are in the filter or all the
logic is in the query. But there are some cases that are more
complicated and magic keywords are defined in the query:
select distinct on (p.way) p.way as way,l.highway as int_tc_type
from planet_osm_point p
join planet_osm_line l
on ST_DWithin(p.way,l.way,0.1) ...
int_tc_type is then used in the filter.
The number of layers is manageable, I'll probably hard-code this stuff
(if it can be expressed in MapCSS).
Next problem: In normal MapCSS, line, icon and area and text properties
are merged into one namespace and in the end we figure out, what styles
can be derived from the final list of properties. Mapnik does it in a
more conventional way and there is a Symbolizer for each element that
should be rendered on the map. Multiple Symbolizers can apply to a given
osm object (e.g. LineSymbolizer and TextSymbolizer).
The brute force answer to this are the MapCSS' layers, also known as
subparts. You'd have a counter on the (Mapnik-)rules and label the
translated MapCSS rules with ::layer1, ::layer2, ... And also set an
increasing z-index for each Rule to respect painting order.
(This is not the whole story, see e.g. layer "sports_grounds" to see why)
I guess I'll forget about 100% equivalence for now and try to create a
style that is as close as you can get without torturing the MapCSS
syntax too much.
Paul
_______________________________________________
Mapcss mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/mapcss
