[Tagging] Feature Proposals - RFC for multiple features - Education Reform - Magnetic Levitation Trains

[Martin Koppenhoefer]

sent from a phone

> On 17. Sep 2017, at 10:52, Tobias Knerr <osm at tobias-knerr.de> wrote:
> 
> . If we were to reform
> the tagging system, my ideal solution would be a "type"/"thing"/"class"
> key that is used for the main tag of all features.


the downside with this approach is that many things are kind of a mixture of basic things/concepts, so this would lead to a lot more of different main features, as if you could create them by combination.

E.g. hotel and restaurant are combinable today (up to a certain point, sometimes you still have to split things into several objects due to different properties they have, that you want to map).

Maybe we could overcome this problem in your proposal by adding combination relations, that e.g. say: these 2 (basic) objects are the same business / part of this complex object, with the same name, operator, parking lot, etc.

You can have entrance=yes exit=emergency on the same object and don't have to decide whether it's mostly an entrance or an emergency exit.


> Other than this
> unlikely step, the next best solution is continued use of amenity as a
> catch-all for most features.


+1, I agree there's no point in moving universities or schools away from amenity, and there's generally no such thing as a "crowded" key (what is frequently brought up for amenity with the proposal to move things from amenity to other keys).

For dataconsumers it can make things easier when there's different keys at a toplevel, e.g. if you're only interested in streets you can reasonably filter them by looking at the presence of a highway key (you'll still get a bit more than streets), similarly for railways or waterways and areas. Or buildings. etc.

It's nothing we couldn't solve, you'd have to look at other tags and find the same things, but any system will have to decide how to deal with many special cases (due to the complexity of the world), and a shift to a system with basically a "main object tag" and k/v properties for the rest will not lead to something simpler (if it wants to differentiate all these cases), it would only be different (shifting the doubt from one tag to another).

cheers,
Martin