Modify

Opened 12 years ago

Closed 8 years ago

Last modified 8 years ago

#6122 closed enhancement (fixed)

allow concat function in mapcss expressions

Reported by: cmuelle8 Owned by: team
Priority: normal Milestone:
Component: Core mappaint Version:
Keywords: Cc:

Description (last modified by Don-vip)

  • 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

Attachments (1)

mapcss-concat.patch (3.1 KB) - added by cmuelle8 12 years ago.

Download all attachments as: .zip

Change History (20)

Changed 12 years ago by cmuelle8

Attachment: mapcss-concat.patch added

comment:1 Changed 12 years ago by cmuelle8

Resolution: duplicate
Status: newclosed

superseded by #6129

comment:2 Changed 12 years ago by cmuelle8

Closed as duplicate of #6129.

comment:3 Changed 12 years ago by bastiK

Resolution: duplicate
Status: closedreopened

comment:4 Changed 12 years ago by 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";

?

comment:5 in reply to:  4 ; Changed 12 years ago by 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";

?

comment:6 in reply to:  5 Changed 12 years ago by 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

comment:7 Changed 12 years ago by bastiK

What if you want

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

or something with colon, slash, comma or semicolon?

comment:8 in reply to:  7 ; Changed 12 years ago by 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?

comment:9 in reply to:  8 Changed 12 years ago by 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.

comment:10 Changed 12 years ago by 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.

Last edited 12 years ago by bastiK (previous) (diff)

comment:11 in reply to:  10 Changed 12 years ago by 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?

comment:12 Changed 12 years ago by 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.)

comment:13 Changed 12 years ago by stoecker

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

comment:14 Changed 12 years ago by bastiK

In [4008/josm]:

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

comment:15 Changed 12 years ago by bastiK

see #6150

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

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

comment:16 Changed 11 years ago by bastiK

Type: defectenhancement

comment:17 Changed 11 years ago by stoecker

Summary: [PATCH] allow concat function in mapcss expressionsallow concat function in mapcss expressions

comment:18 Changed 8 years ago by Don-vip

Description: modified (diff)
Resolution: fixed
Status: reopenedclosed

comment:19 Changed 8 years ago by Don-vip

Component: CoreCore mappaint

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.