On 2015-06-04 01:48, pmailkeey . wrote:
On 3 June 2015 at 09:45, Lester Caine <[email protected]> wrote:
On 03/06/15 01:04, pmailkeey . wrote:
OSM's k=v design is completely a serious and unnecessary flaw.
Similarly
are 'categories' like man_made', and 'amenity'.
Why can we not simply stick to hard facts rather guessing what
categor(ies) an object fits in
This is a bit like saying XML is the wrong base format. and actually
I
would agree with that, but the majority of material only works with
a
k=v structure. While for a few VALUES there are potentially only one
k=v, they are very few and far between.
I'm not convinced. A value of yes as a stand-alone item is meaningless
but a value of hedge is sufficient to indicate we're talking about a
barrier. (please read below before responding to this item)
But equally important is a consistent way of offering your data. And
offering not necesserily to end-users but most importantly to
application builders.
Nothing is more annoying than seeing multiple types of data being
offered because for each type you have to program something differently.
Sure, "residential" on an object may be sufficient to see that it is a
road and it is classified as a residential road. But now you want to get
all roads. So you have to select residential, tertiary, secondary...
etc. How much more easy is it then to select all ways with key
"highway".
I agree that some values may be self explanatory, but I'm sure it does
not weigh up to the added burden of having to work with them.
Maarten
_______________________________________________
talk mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk
