Jochen Topf wrote: >> This proposal [1] moves values into the key to describe conditions. >> (Although you could argue, it should be done like that anyway...) >> [1] >> <http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags>, > > I think thats a misguided use of tag keys probably invented by people who have > never actually tried to write code that tries to interpret OSM tags.
No speculation required, I'm the one who is to blame for that proposal. Before I finished the text that's still in the wiki, however, I /did/ write an experimental implementation* for this syntax, as well as an alternative syntax, to find out whether the ideas could work from a developer's perspective. I didn't encounter any significant problems. In retrospect ... well, maybe it wasn't the best of ideas to write that implementation based on the GraphView plugin for JOSM. After all, I figure that working on a comparably small in-memory dataset makes a significant difference for the way you would deal with keys. Add to this that I didn't have to deal with any web issues, or in fact any interface between programs at all (-> no encoding issues), and it probably wasn't remotely a representative development experience. Unfortunately, it seems this will produce exactly the outcome I didn't intend at all: more "variety" in tagging. People will continue to use those parts of the proposal that don't require special characters (maxspeed:wet, :forward and the like), so we will use completely different solutions for simple and for more complex cases. Well, I'll file this as "failed attempt of overzealous newbie to build tagging cathedral". Tobias Knerr * I ended up never publishing the implementation, though - not due to condition handling itself, but because I never got around to implement a proper opening_hours parser. Turns out that's actually more work than the entire rest of the syntax. _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
