[Mapcss] Subselectors

[Paul Hartmann]

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