allow concat function in mapcss expressions

[cmuelle8]

• allow concat(Object... args) in mapcss to enable composing freeform labels
• word split the string in Label Composer
  • if a word is a key for the prop, substitute the value
  • else append the word as is

e.g.

text: eval(concat("smoothness -- ", "surface"));

will render something like "bad -- asphalt" if the tags are set accordingly.

Greetings

cmuelle8

[cmuelle8]

superseded by #6129

[cmuelle8]

Closed as duplicate of #6129.

[bastiK]

I'd like to use this ticket to discuss label composer part of the patch.

First question: What is the difference between

    text: eval(concat("smoothness -- ", "surface"));

and

    text: "smoothness -- surface";

?

[cmuelle8]

None, it was just an example to explain it's use - usually, you would nest functions into the concat arguments, like

 concat("way with surface: ", prop(surface-text), " and smoothness: ", prop(smoothness-text), " and width ", get_tag_value(width));

Replying to bastiK:

I'd like to use this ticket to discuss label composer part of the patch.

First question: What is the difference between

    text: eval(concat("smoothness -- ", "surface"));

and

    text: "smoothness -- surface";

?

[cmuelle8]

Oh, maybe you read the explanation too quick. Again, the label composer will take any string

 text1: "halli galli war auch mal name eines kartenspiels";
 text2: "symbol und name sind osm tags";

Let's say an osm object is tagged with symbol=green_fence and name=Pfad, then the result for the texts will be

 text1: "halli galli war auch mal Pfad eines kartenspiels";
 text2: "green_fence und Pfad sind osm tags";

Concat is completely unrelated to what the label composer does, it just adds the string parts of it's arguments to form one, new concatenated string..

Greets

[bastiK]

What if you want

node[amenity=restaurant][cuisine] {
  text: "\"name\" (cuisine)";
}

or something with colon, slash, comma or semicolon?

[anonymous]

You can very easily do:

node[amenity=restaurant][cuisine] {
   text: "\" name \"   ( cuisine )";
}

Tokens are determined by a simple space now. Of course you can always change the code to determine the words you do a tag lookup for with another grammar, like "${KEY}" (${KEY2}). Whoever needs it, can write a patch to modify and enhance current code. This is (was?) an OSS paradigm. There is always room for improvement, in any patch..

Most simple thing to realize the behavior you want, is to kill the last "space" in res and not append a new one for _any_ (but only if) substitution done. You would still need to correctly "space" the rule, but the result will be what you want..

Greetings

Replying to bastiK:

What if you want

node[amenity=restaurant][cuisine] {
  text: "\"name\" (cuisine)";
}

or something with colon, slash, comma or semicolon?

[bastiK]

Replying to anonymous:

You can very easily do:

node[amenity=restaurant][cuisine] {
   text: "\" name \"   ( cuisine )";
}

Tokens are determined by a simple space now. Of course you can always change the code to determine the words you do a tag lookup for with another grammar, like "${KEY}" (${KEY2}). Whoever needs it, can write a patch to modify and enhance current code. This is (was?) an OSS paradigm. There is always room for improvement, in any patch..

With your patch you implicitly propose an extension to the MapCSS standard. People will start to use the feature and it may find its way in other MapCSS implementations. Standards can evolve as well, of course, but it's much more painful when you have to break backwards compatibility. This is why I would prefer a more fully developed solution that we can be satisfied with, as it stands.

If it was called

text-format-by-christian: "smoothness -- surface";

it couldn't say much against it because it would be obvious that it's one method among others.

[bastiK]

For the record, it would be useful to have something like:

    text-...: "smoothness - {smoothness}, surface - {surface}";

Where the Strings in curly brackets get replaced. AFAIK, with you patch you have to write "SMOOTHNESS - smoothness , SURFACE - surface" or something like that.

[cmuelle8]

Replying to bastiK:

For the record, it would be useful to have something like:

    text-...: "smoothness - {smoothness}, surface - {surface}";

Where the Strings in curly brackets get replaced. AFAIK, with you patch you have to write "SMOOTHNESS - smoothness , SURFACE - surface" or something like that.

right, or append a colon. your arguments about evolving standards are very plausible, thx. but then, if we want to do best we can, question is, how is variable substitution done elsewhere in the mapcss / JOSM / OSM universe? is using curly braces found elsewhere? or what about other CSS implementations? if not, I suggest using sh shell compatibility - ${var}. for me curly braces would suffice, you know if this method is found some place else?

[bastiK]

I'm not aware of something like this in any MapCSS implementation or elsewhere in OSM (but I don't know much of this universe :) ). In JOSM, the TMS URL is created like this:

tms:http://oatile1.mqcdn.com/naip/{zoom}/{x}/{y}.png

But I suppose this is not a strong argument.

Regarding Shell compatibility: The analogy is only limited as shell variables must be C identifiers but a tag key can be an arbitrary string. Colon and dash are quite common actually. I think this syntax is inspired by Perl hashes, where you would write $tags{smoothness} or $tags->{smoothness}. (But in Perl it has to be quoted if the key is not an identifier.)

[stoecker]

{} has been used as it easy to understand and cannot appear in an URL.

[bastiK]

In [4008/josm]:

see #6122 - allow concat function in mapcss expressions (patch by cmuelle8)

[bastiK]

see #6150

text: ... is a little overloaded by now, so the following syntax would be an alternative:

   text: format;
   text-format: ...;