Tag namespaces already provide a kind of "data structure" facility. IMHO a syntax that is close to the traditional way of representing vectors of structures would be something like this:
addr[1]:housenumber=1234 addr[1]:street=Main Street addr[2]:housenumber=7654 addr[2]:street=Elm Avenue All house numbers are called "housenumber", addr[1] and addr[2] are both instances of an address. In fact, if the ":" is replaced by a ".", it starts to look very familiar.... Is the maximum length of a value still 255 characters (or is it bytes?)? With the ";" syntax we could easily come up against that limit, whereas an array / key-based syntax would allow 255 for each individual value. Obviously (at least IMHO) the data model of OSM would benefit from having a defined method to represent higher-level constructs. Some people are already talking about having an "area" or a "polygon" distinct from a "way" with start=end. Why not have a proper discussion about how to represent lists of values? Of course it helps to have some examples in mind, but let's step back and find a more generic solution which will also address our current problem. I really don't think the fact that some people don't understand regular expressions is a good reason to not look to the future. Once a standard is defined, the software will soon catch up - if the standard is well-specified. If the standard is not well-specified, poorly documented, too many exceptions etc then it will be "ignored". Colin On 2015-01-23 17:29, Tod Fitch wrote: > On Jan 23, 2015, at 7:47 AM, Richard Welty wrote: > On 1/23/15 10:13 AM, jgpacker wrote: I don't understand the insistence in > using regexes as some kind of argument against semicolon lists. A semicolon > list is an extremely simple pattern. Such a pattern can be easily parsed even > WITHOUT regexes. Me and other developers in this thread (Imagic, Friedrich, > David, Dmitry, Marc) are trying to tell you semicolons are not a problem. +1 > competent languages provide simple mechanisms for splitting strings on single > characters. sometimes the function is even called "split" richard Yes, nearly every scripting language I've used has an easy way to split a string on a character or substring. Is there is a value string that contains a semi-colon that is part of the actual value rather than a delimiter between values. I can't think of any but since for some key names the value field is free form I suppose it could happen. A semantic solution to that would be to document which keys may have (or maybe a shorter list of exceptions that cannot have) multiple values separated by semi-colons. However there is the related question of how to deal with things like multiple addresses for one object, the subject of another current thread. In this case you probably don't want to be dealing with: addr:housenumber=1234;7654 addr:street=Main Street;Elm Avenue So you will be dealing with something like: addr:housenumber=1234 addr:street=Main Street addr:housenumber_1=7654 addr:street_1=Elm Avenue Coming up with a uniform way of dealing with arrays of values would mean that a simple and consistent solution could be used for both problems. I don't much care if the syntax of the key is "key:1", "key_1", "key#1" or "key[1]" but I do think that something needs to be picked for sets of keys that have related values. And once you do that the solution could be applied as an alternative to semi-colon delimited values in the case being discussed here. Having one approach that solves two issues seems better to me than having two solutions. Yes, any robust data consumer software will have to deal with all the existing ways things are done now. But standardizing on way to go forward should help in the future. Cheers, Tod Fitch _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: ------ [1] https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
