Special literal meaning "linebreak"

[ger-benjamin]

Feature Request

Hello,

In some solutions, it's possible to have a "new line" between two texts. Example: Wanted result:

1234
My shape

With ArcGIS: "[FOKR]&vbNewLine& [FOKRNAME] "

With GeoServer:

            <Label>
              <ogc:Function name="Concatenate">
                <ogc:PropertyName>fokr</ogc:PropertyName>
                <ogc:Function name="Concatenate">
                  <ogc:Literal><![CDATA[
]]></ogc:Literal>
                  <ogc:PropertyName>fokrname</ogc:PropertyName>
                </ogc:Function>
              </ogc:Function>
            </Label>

Describe the solution you'd like It would be great to have a special literal for that in the Geostyler style format. Maybe something like a WellKnownName ? Or it is already existing and I missed it ?

[jansule]

Good point! This looks like something we do not support yet. Do you have a specific literal in mind?

Currently, we use {{COLUMN_NAME}} (wrapping the respective column name into two curly braces) for resolving placeholders. So this literal is already reserved.

@KaiVolland what do you think?

[ger-benjamin]

Do you have a specific literal in mind?

That's the hardest part ! I think {{NEW_LINE}} or {{LINE_BREAK}} would be good. Maybe there are other "WellKnownPlaceholder", we could add both as a new type ?

[jansule]

That's the hardest part

True :grinning:

My previous comment might have been too imprecise. Sorry for that. Using two curly braces is already reserved for resolving placeholders. COLUMN_NAME was only used to show that users can provide any column name there, e.g.

label: "count: {{COUNT}}"

would render a label as

count: 10

for a feature with the value 10 in a column COUNT.

So, using {{NEW_LINE}} or {{LINE_BREAK}} will not be an option, since users would not be able to reference columns with the names NEW_LINE or LINE_BREAK.

[ger-benjamin]

Oh ok I get it.

It's still possible to have reserved terms like {{reservedTerms://line_break}} and check it starts with reservedTerms:// Then we use only brackets for replacements.

Otherwise, we have to reserve a new characters, like [[LINE_BREAK]] or %%LINE_BREAK%% ,or .... If we check the double character start and closing, any not alphanumeric character should be safe enough.

Then we could have labels like {{id}}%%LINE_BREAK%%{{place}}

[KaiVolland]

Actually I'm not sure if and how should deal with the existing placeholder/template syntax as we now support functions in geostyler-style and especially the use of feature properties.

The thing with the linebreak is indeed a problem that occured more often. E.g. here: https://github.com/geostyler/geostyler/issues/2008

My personal preference would be to make use of an existing simple concept like escape sequences. So we could just use \n for a newlince. The parsers should then do the things they have to do to transform it to their syntax.

[jansule]

So we could just use \n for a newlince

I think that's a good point. This also leads to users being able to just press ENTER in the input fields in the UI, which is already the case.

[ger-benjamin]

Okay, +1 But the \n notation must be defined in the doc to let the user know that this special value exists and is used for that.

[jansule]

Absolutely. I think we should also explicitly specify this in geostyler-style. Something like

type newlineToken = '/n';

[ger-benjamin]

Closed with #561