Provide a way to escape special characters in field names
Closed this issue · 19 comments
In a good working stylesheet I replaced {name} with existing fieldname {name:fr} (and also tried quoting it in various ways) but it is not recognized. See also:
tilezen/vector-datasource#105 (comment)
We've reserved various punctuation characters, including the colon, for potential future use, e.g. token defaults. Mapbox vector sources use an underscore instead, e.g. {name_fr}.
ok, thx.
@jfirebaugh Is there any plan to allow {"name:fr"} to access the property named "name:fr", while still preserving the token defaults?
Is there another existing technique to access a property besides the mustache syntax (like feature["name:fr"])?
What's the ideal syntax for escaping special characters in field names? Some ideas:
{"name:fr"}{name\:fr}{[name:fr]}
@nvkelso Could provide a suggestion that would work for you?
Either of these floats my boat (first one, quoted, is my preferred option):
{"name:fr"}- this seems most straight forward and SQL-like{[name:fr]}- this is more like how Cascadenik used to do it, which is a nod to the past and optional.
This seems annoying:
{name\:fr}
+1 for {"name:fr"}
Rather than extending our text-substitution mini-language with defaults and escaping, I'd rather abandon the mini-language entirely in favor of built-in JSON syntax. Something like:
"icon-image": {
"type": "substitution",
"value": [{"ref": "maki"}, "-12"]
}
Where elements in the "value" array are either strings or objects with a "ref" property whose value names a feature property key. This value would have no reserved characters or escaping.
Evaluation would proceed by replacing refs with stringified feature property values, leaving strings as literals, and then concatenating the resulting array of strings.
This extends to support (recursive) defaults nicely:
"icon-image": {
"type": "substitution",
"value": [{"ref": "maki", "default": default}, "-12"]
}
where default can be another string literal or ref object.
I don't recall the exact syntax we decided on for data-driven functions but essentially "substitution" should be just another function type.
@jfirebaugh, your suggestion would be great, much better than a mini-language that will inevitably become as featureful and tricky to use as Bash variable operations. Would #104 (comment) require a different type, perhaps?
+1
On Dec 4, 2015, at 11:02, Lucas Wojciechowski notifications@github.com wrote:
@1ec5 We're open to syntax suggestions!
―
Reply to this email directly or view it on GitHub.
+1
This is a blocker to render localized maps in studio using the name:lang tags exported from OSM. One needs to manually rename the tags in the data currently.
@lucaswoj Any news on this?
this would also unlock some diagnostic mapping for the geocoder that relies on carmen properties which include colons
@jfirebaugh @ansis Given that we don't want to go the route of a "mini-language" for token defaults, can we just lift the restrictions using colons in field names to unblock these use cases?
Good point -- yes, I think we can (with the exception of { and }, of course).