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
_______________________________________________
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
