[Patch in progress] MapCSS: 'line' selector and the future of the standard

[plepe]

According to ​osmwiki:MapCSS/0.2
there's also a 'line' selector, for "A way where the start and finish nodes are not the same node, or area=no has been set".

[simon04]

What do you think?

[bastiK]

First of all, I'd like to say that the MapCSS specification isn't set in stone. (Well, version 0.2 is probably fixed.) Not everything you find in the wiki has been discussed thoroughly or even tested in practice. Of course the whole point of a specification is that people can rely on it and styles get implementation independent. However, JOSM is probably at the moment the project with the most active MapCSS user base, both for style authors and people that use MapCSS styled map display. If we find, that a concept doesn't work, we shouldn't stick to it slavishly, but try to find a better solution and maybe work towards MapCSS version 0.3.

Ok, back on topic. :)

Line and area are quite simple concepts, geometrically, but in OSM it is not so easy. A closed way can represent a line or an area feature, depending on the tags.

A street and a fence are typical examples of lines, so the style should look like:

line[highway=*] {
    width: 2;
    color: #c0c0c0;
}
line[barrier=fence] {
    width: 3;
    color: #F0F050;
}

However, more often than not, a fence is a closed way, so the current definition of line, it wouldn't match. The same is true for highways, they can be a closed way: Most commonly for roundabouts or a footway around a lake, etc.

For some features, a closed way is a line, but becomes an area when adding the tag area=yes (e.g. highway=pedestrian or barrier=hedge).

There is also the more exotic case (e.g. for public_transport=platform) where it is a line for unclosed way and is considered an area for closed ways (without additional area=yes). This would actually match the proposed semantic of the line selector, but it is quite rare.

The point of adding an abstraction over OSM specific data types, would be to make it more logical and easier to use. Ideally the node, way and relation selectors should be abandoned and only point, line and area would be used in the style. This requires, that we actually match the right OSM objects, and with the current definition (as it is written in the wiki), I think this is not the case.

If we lift the condition, that the way must be closed, then a line would be just an alias for way (so a little pointless).

[bastiK]

About the JOSM definition of area which does not match the specification:

The basic idea is that it is an error to have an unclosed way with an area style on the map. The validator will warn about this and the user is supposed to fix it. When all errors are corrected, both definitions of area are effectively the same. So normally (without errors) there isn't really a difference.

The reason why we do this is mostly historical: It worked like this with the XML styles, so I didn't change it. We could discuss again, which is better. Maybe if we don't draw areas for unclosed ways, some problems are spotted earlier (e.g. terraced housed, where one wall for a house is missing).

[plepe]

I see your concerns about 'line', it is something I had my problems in other projects too. In pgmapcss I just use the interpretation of osm2pgsql which is reasonable in most cases.
I think it would be the easiest to handle 'line' equal 'way', maybe with the exception of area=yes.

I would also say that the MapCSS specification is not set to stone - there are many things which are not well thought of and the eval function list is a joke. (I started extending the list today and add a list of support - at least for JOSM and pgmapcss).

Some time ago I raised the idea of a better specification discussion process, using Github and pull requests. I raised a discussion some time ago on the MapCSS mailinglist, unfortunately there was not much interest: ​https://lists.openstreetmap.org/pipermail/mapcss/2013-August/000380.html

My dream is to have the ability the use the same MapCSS styles on all kinds of devices and platforms: Paper, Background tiles, interactive overlays, editors, smartphones, ... To have a thorough specification would be a big step towards that. Would you (either as persons or as JOSM team) be interested on working towards this goal?

[bastiK]

I've added a patch for the line implementation that doesn't require the way to be closed. However I'm not sure, if it is a good idea to apply this, as the addition of the selector doesn't add any new functionality and it would be in clear contradiction to the MapCSS 0.2 wiki page.

[bastiK]

Replying to plepe:

[...] and the eval function list is a joke.

I think the eval wiki page is not part of the specification and really not more than a quick first draft. It was agreed at the time, that eval expressions are a "higher order" problem and the specification should focus on more basic features first.

(I started extending the list today and add a list of support - at least for JOSM and pgmapcss).

Looks good!

Some time ago I raised the idea of a better specification discussion process, using Github and pull requests. I raised a discussion some time ago on the MapCSS mailinglist, unfortunately there was not much interest: ​https://lists.openstreetmap.org/pipermail/mapcss/2013-August/000380.html

A GitHub repository may not be ideal for this project, as it creates an asymmetry between the people who make pull request and the ones who accept them. I would say, the best place for discussions is sill the MapCSS mailing list.

My dream is to have the ability the use the same MapCSS styles on all kinds of devices and platforms: Paper, Background tiles, interactive overlays, editors, smartphones, ... To have a thorough specification would be a big step towards that. Would you (either as persons or as JOSM team) be interested on working towards this goal?

In JOSM, we have added a lot of features over time, mostly without prior discussion on the mailing list. Now, simply making a list of these features and declaring them as MapCSS 0.3 would certainly be rude.

What I could imaging, that we concentrate on a single feature, create a detailed working draft and put it up for discussion. The result should be a separate module that implementors can either support (and be compatible to each other) or simply ignore.

Here are some features that in my opinion have proven useful and could be specified in a module:

• symbol-* properties
• repeat-image* properties
• meta selector for general information
• multiple layers using subpart syntax (::layer)
• child selector syntax with conditions (... >[role=xx] ...)
• refined z-index handling
• eval

These features are backwards compatible and independent, which makes it much easier than getting agreement on changes that break the current specified behavior. Although there are certainly things, that should be reconsidered, I would be more motivated to go after the low hanging fruit first...

[plepe]

Concerning the future of MapCSS - will you be on the SOTM-EU? I will be there and also give a talk about pgmapcss. I hope we can meet and have some discussion there.

I admit, that maybe we should try to keep the MapCSS standard small and simple, so it's easy to add new implementations. Additionally we could define possible extensions, like you mentioned. Though especially ::layer is really important, I would suggest to add it to the basic definition.

By the way, lately I discovered that JOSM implements @media selectors - a very wise move, I will add support in pgmapcss with the next version. I was thinking, maybe we could introduce feature dependencies, like:

@media (feature: repeat-image) { something with repeat image }
@media not (feature: repeat-image) { alternative code for renderers which do not implement this feature }

What do you think?

[bastiK]

Sorry, forgot this ticket.

Replying to plepe:

Concerning the future of MapCSS - will you be on the SOTM-EU? I will be there and also give a talk about pgmapcss. I hope we can meet and have some discussion there.

I will not be on the SOTM-EU, but according to the program, Simon will be there and give a talk. He contributed a great deal to the MapCSS development in JOSM, especially adopting it for the validator.

I admit, that maybe we should try to keep the MapCSS standard small and simple, so it's easy to add new implementations. Additionally we could define possible extensions, like you mentioned. Though especially ::layer is really important, I would suggest to add it to the basic definition.

Agreed.

By the way, lately I discovered that JOSM implements @media selectors - a very wise move, I will add support in pgmapcss with the next version. I was thinking, maybe we could introduce feature dependencies, like:

@media (feature: repeat-image) { something with repeat image }
@media not (feature: repeat-image) { alternative code for renderers which do not implement this feature }

What do you think?

Good idea, I didn't think of that! An optional version number should be useful. In addition, modules that are indispensable in the style could be listed in the meta section:

meta {
  [...]
  requires: "symbols-1.0,repeat-image-1.1";
}

[plepe]

Yeah, I already met Simon (e.g. on Linuxwochen 2014 in Vienna) - in fact, he suggested to create issues concerning mapcss compatibility ;)

About future of MapCSS standard: I thought, maybe some kind of proposals like OSM uses for new tags could be useful - separate pages in the OSM Wiki, with discussion and the option to vote. So, soon I'll create a proposal for the addition of those "::layer"-selectors. I will announce it on mapcss-mailinglist.

[bastiK]

Ticket #13477 has been marked as a duplicate of this ticket.