[OSM-talk] OSM is a right mess

[Maarten Deen]

On 2015-06-04 01:48, pmailkeey . wrote:
> On 3 June 2015 at 09:45, Lester Caine <lester at lsces.co.uk> 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