[OSM-talk] "Second decade" visions

[Daniel Koć]

W dniu 12.03.2015 12:48, Martin Koppenhoefer napisał(a):

> this might be a philosophical question, but I believe that
> amenity=school for the whole area is more precise than amenity=school
> on just a building. The outdoor areas of schools typically serve for
> recreation purposes, and recreation is undoubtedly (I hope) part of
> the institution school. You can see this point of view also reflected
> in other occasions like the rules for the pupils, which often allow
> them to move freely on the school premises during school, but not to
> leave them.
> 
> We do not gain anything by making things "uniform" that are not
> comparable.

The schoolyard is not that different than churchyard or even industrial 
area. There can be some special facilities inside (pitch, cemetery, 
warehouse) that can have special purposes (recreation, religious cult, 
storing goods) - or not at all, but basically they are just a space 
belonging to some entity and often surrounding some buildings.

In the current state of things we have to know how to treat each type of 
"*yard", but that way you loose the feeling there is a logic behind it, 
which is crucial thing to efficiently use such complex system as ours. 
How many times you are urged to check the wiki to not make a mistake in 
some cases? For me it's much too often - and I'm here for years.

> Generally having a precise tag for a very common case makes mapping
> and interpretation easier than having a combination of 3 tags, but it
> really depends on the single case.

When you target only very common cases, you cut all the "uncommon" cases 
- it's just like  "if all you have is a hammer, everything looks like a 
nail". And that means cheating or dropping those uneven ones. I don't 
know what is the range of a problem, but I blindly guess that it can be 
a very "long tail".

Tags combinations gives you the ability to match some "half-baked" 
objects (like deconsecrated church) or the object you have only partial 
knowledge about (service=food). You can combine them into common cases, 
but in current tagging scheme you can't say what is unusual in otherwise 
plain object - you have to invent new tags. It's easy to add features to 
the object, but how could we "subtract" them? You are also pushed by the 
technical k=v model to choose if there are equally important features 
sharing the same namespace, and I think combinations should not be 
restricted that way.

> Everybody
> who wanted to make a map would have to check for every school whether
> there was an additional tag that said: "this is not a school of the
> type you might expect", with a potentially infinite number of such
> additional tags (because there will be "schools" for almost every kind
> of profession or leisure activity etc.), while it also required 2 tags
> for what could be tagged with one (amenity=police_academy) and which
> would still leave uncertainty because you would not know whether this
> was a police academy or a police station and a school on the same
> ground.

Let's forget about "tags" as we know it (or any tags, because redesigned 
system can look way different) and think about "primitives" or "bricks":

police + school -> police academy
police + service -> police station
police + museum -> ...
police + headquarters -> ...

It doesn't mean we can't have special combinations with 1:1 mapping for 
all the typical objects: parking_aisle is a - cascading - combination 
already and the "typical" church is now also a combination, so we have a 
taste. Such a common library of templates is very handy and that's why 
we use them.

So you could search all the "school + children_facilities" (let's say 
that would be the combination for a typical school) as easy as it's now, 
but if you would like to make a "children map" you can just search all 
the "children_facilities" - while now you have to enumerate every type 
of such things and there's "potentially infinite number of such 
additional tags", because there will be facility for almost every kind 
of children's activity.

But wait - do we really have them in our database or there are endless 
debates about one-and-only correct daycare tagging (and if we need it at 
all)? What if it was always easy to tag a partial features of the 
objects so we could search the most common (or just very useful) 
combinations straight from the taginfo to make another template in our 
library of "ready to use" objects? And remember about the power of 
features recombining according to the system logic!

This way some things that are now under our radar would pop up on the 
surface. There is no such thing as unbiased data (rendering things on 
default map is even more critical factor for many people), but at least 
we would know better what kind of features are simply observed in the 
wild, so we can make more realistic choices what is important (lack of 
existing examples is a strong reason to drop the tagging scheme 
proposition).

As you see my vision is not completely different. I would like to keep 
the best things we have now (standard objects library) with opening 
gates for simpler building bricks to not fall deeper into the trap of 
countless "cases" with no clear general rules.

The downsides? I see mainly those:
- more typing (but I tend to use JOSM templates a lot and only change 
tags manually when needed)
- work to be done in every aspect of the project (editors, rendering 
styles, tracers, search engines, documentation...)
- project's inertia

The second and the third one are the reason I think it would be a 
long-term process, even if there will be enough people to really start 
it.

-- 
Piaseczno Miasto Wąskotorowe