Thomas Davie wrote:
I'm just trying to get straight in my head exactly what the semantics
of a subselector in MapCSS is depending on the combination of
node/way/relation/area/line used.
1) Are ways ever contained within areas/lines i.e. does
area[landuse=comercial] way[barrier=fence] have any meaning beyond
area[landuse=comercial][barrier=fence]. My gut feeling is that
"area" "line" and "way" all describe the same thing, but with subtle
preconditions, and thus should not be usable in subselectors in this
way. Is this correct?
I think at the moment, there is no definite answer, 'area' is a relatively new idea and it will be, what people make of it. For my part, I consider
area[landuse=comercial] {}
to be a shortcut for
way[landuse=comercial], relation[type=multipolygon][landuse=comercial] {}.
In OSM, there is no simple way to determine if a closed way is an area or a
linear feature (but it depends on the tags). If this was more clear, we could
exclude linear features (e.g. highway=roundabout) from the definition of
'area'. But in practice, this is not a problem - you simply don't include a
stile rule like
area[highway=roundabout] {}
but write
line[highway=roundabout] {}
or
way[highway=roundabout] {}.
Regarding the descendant selectors: This is interesting. With the simple translation I gave above, for multipolygons, "area[landuse=comercial] way[barrier=fence]" would be correct to select the member ways tagged as barrier=fence, but "area[landuse=comercial][barrier=fence]" would not apply unless the barrier=fence tag is on the multipolygon relation itself. On the other hand, when you have a simple closed way, "area[landuse=comercial][barrier=fence]" would indeed select that way, but the descendant selector version "area[landuse=comercial] way[barrier=fence]" wouldn't work, because technically, the area and the outline are the same OSM object and there is no form of ancestry involved. This is of course unfortunate, as the whole point of 'area' is, to keep it simple and make it "just work".
So I suggest, that in the special case "area ancestor of line", this applies to a
closed way the matches both left & right conditions (so it acts both as area and line in
this case).
2) Given the above it becomes clear that relation becomes the parent,
beneath which you may have a choice of area/line/way
I'd consider the relation to be the area object itself.
(or possibly
none), beneath which the nodes that make up the areas lines and ways
sit. The implication of that to me is that
relation[type=multipolygon] node[barrier=bollard] should select all
nodes tagged barrier=bollard that are a member of any way that is a
member of a multipolygon relation. Is this correct?
Yes, but seriously, who wants that? For HTML styling, the descendant selector
makes perfect sense, as for example you like to have bold font for all the list
items in the navigator bar. There can be arbitrary nesting, so you write
div#navigaton li { font-weight:bold; }
However, in OSM, we usually have only one level of nesting, so I prefer the
child selector [1], which was introduced in CSS 2. In your hypothetical
example, one could write
relation[type=multipolygon] > way > node[barrier=bollard] {}
to make it explicit.
Btw., in JOSM we have introduced 2 new concepts: "link selector" and "parent
selector", see [2] for details.
[1] http://www.w3.org/TR/CSS21/selector.html#child-selectors
[2] http://josm.openstreetmap.de/wiki/Help/Styles/MapCSSImplementation
Regards, Paul
_______________________________________________
Mapcss mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/mapcss
