[Tagging] Extended Conditions - response to votes

Eckhart Wörner ewoerner at kde.org
Fri Jul 6 12:41:52 BST 2012


Hi Frederik,

Am Freitag, 6. Juli 2012, 01:12:55 schrieb Frederik Ramm:
> In my eyes this proposal is a typical 
> designed-on-the-desk-of-a-database-person idea.

Wow, that is the most compelling argument ever made in the discussion.

> But I think these kinds of complex tagging schemas only satisfy a few 
> über mappers who are delighted to be able to model something complex. 
> They won't be adopted by a large enough group of people to even remotely 
> rely on these tags being present and correct.

Before you start to "think" and make some completely wrong assumptions, you could as well have a look at taginfo and realize that the scheme is in widespread use already. Let me pick some numbers for you:
4 583 maxspeed:forward
4 397 maxspeed:backward
3 442 maxspeed:hgv
566 maxspeed:wet
447 maxspeed:children_present
377 maxspeed:(22:00-06:00)

What you (and some other people) fail to see is that this proposal is designed to just "blend in", something *all* other proposals so far failed to do.

> I suggest the following course of action:
> 
> 1. Use the proposed tag in a limited area somewhere.

This limited area is the world, and people use it.

> 2. Create an application that acutally makes good use of the proposed 
> tag, something where people go: "Wow, great, this bicycle routing engine 
> on my iphone gives me different routes depending on whether the 
> pedestrian area is open for traffic or not, that's something I have *so* 
> been waiting for!"
> 
> 3. Then, based on the strength of "this cool real-world application will 
> work better if these access rules are properly mapped so let's all agree 
> on the best way to do it", get the discussion going.

You're trying to create a classic chicken-and-egg situation here. Why should anybody invest time (and maybe money) into a routing application based on "if this application becomes successful, go back to the drawing table and break it"?

> With this procedure, there's a remote chance that people will indeed use 
> the tag because they get tangible results. Even then it will be 

I already addressed your "remote chance".

> difficult because we already demand a lot of our mappers. Frankly, I'm 
> sick of hearing "oh we'll just make a nice template in the editor for 
> this" because those templates already give every mapper the impression 
> that a simple street with a name is not enough anymore - a new mapper 
> stupid enough to open the JOSM preset for a residential road is already 
> asked whether the road is lit, how many lanes it has, what the surface 
> and the maximum speed were, how wide the road was (in metres), whether 
> there was an incline... this has all grown from the "oh let's just make 
> a nice template then mappers can enter this stuff" idea but the result 
> is that every mapper is left feeling inadequate because he cannot 
> remember if there were street lights in the street he surveyed.

And what is your point here? There is no template in this proposal, and with current JOSM, this is also impossible.

> I'm a big fan of the "show application, introduce tags" idea. Everything 
> else is just "wouldn't it be nice if..." tag wanking that gets us nowhere.

"show application, introduce tags" is broken, as argued above. I would agree with "show compelling use case, introduce tags", and this one is imho pretty compelling; just look at any good commercial routing application out there - if we want to get there, we need this proposal.

> As long as there are no real-world applications for this kind of 
> detailed access mapping one can simply use the "note" tag and add stuff 
> in natural language. That's my proposal for now ;)

And you're the one who is then going through the already huge number of 257 572 different values of the note key?

Eckhart



More information about the Tagging mailing list