[openstreetmap/openstreetmap-website] Added color preview box in tag browser sidebar (#1779)
notifications at github.com
Wed Mar 7 14:57:39 UTC 2018
stefanb commented on this pull request.
> @@ -188,4 +190,16 @@ def telephone_link(_key, value)
+ def colour_preview(key, value)
+ return nil unless (key =~ /^(|building:|ref:|roof:)colour$/ || key =~ /^(int_)?ref:colour(_(bg|tx))?$/) && !value.nil?
Yes, it is very important to indicate whether tagging was done *correctly* or not.... as much as possible.
The colour tag **value** is well defined and thoroughly checked and preview box is only shown if the value is a valid colour. User can then validate the colour correctness visually (editors could offering color pickers).
**Key** validation on the other hand is performed in the key column of the sidebar. Currently the only visual indicator is the presence of the link to wiki. That link is unfortunately missing for many valid keys (eg when key legitimately contains some variable or the wiki page is not existing or redirecting to a more general key). There might be also cases when the key was deprecated, but the link still exists because the page remained in wiki for reference. Key validity indication could be improved, to not just existence of wiki page but
- also some other metadata from wiki (redirect, status...) or
- link to most suitable wiki page (eg it the key is "building:levitating" which does not exist in wiki, just link to the first part "building" to the "key:building" wiki page which would give editors more hints about the topic and how to fix the tagging) or
- OSM data (eg order tags by key occurance count)
- some keys are only valid on specific elements (relations, ways, nodes),
- some keys are requiring presence of related tags (eg drink:* tag requires appropriate shop or amenity tag)
Key validation is a complex topic to be tackled separately.
The question here is to what extent should the key validity influence the value validation, given that OSM has an evolving schema where no key can be "totally wrong", just maybe discouragd and less (or not at all) supported by some tools (renderers, routing engines...), and the community tries to reach consensus before introducing new keys, and educating newcomers of established schema.
Some minimal influence (key must at least contain "colour") is needed to prevent color preview boxes showing up occasionally in the name and other totally irrelevant tags.
It would not be clear to users to know why they don't see the colour preview box for their mispelled "buidling:colour=#aaa" tag. Absence of color preview box may say that *something* is wrong, but it would not point to the key, but would most likely leave user wondering whether should it be "#aaaaaa" or "lightgrey" or "lightgray" or "paledesertwhite" or ...?
I have played a bit with [100 most common keys sontaining "colour"](https://taginfo.openstreetmap.org/api/4/keys/all?query=colour&sortname=count_all&sortorder=desc&page=1&rp=100) and came up with a rather long regex:
Which matches roughly 50% of these keys and some unrealistic fake ones (added by me at the end) - You can experiment yourself: http://rubular.com/r/nAjRBYjvUZ
(Please note that in the above regex the ```(?: ... )``` and ```(?> ... )``` are non-capturing and atomic-grouping performance optimisations, as we don't need individually matched components.)
Or we can stick to the [KISS principle](https://en.wikipedia.org/wiki/KISS_principle) and use simple (cheap to execute and easy to maintain) regex:
as the first filter and indication that user might have wanted to tag a colour value, and only then we try to interpret that given value as a colour.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rails-dev