On 17.09.2017 07:54, Erkin Alp Güney wrote: > This brings education key instead of amenity=school.
In my opinion, and speaking broadly, the job of the OSM tagging system is to answer two questions: - What kind of feature is this? - What properties does this feature have? The first question can usually be answered by a single word, such as "university" or "driving school". The second is more naturally answered with key-value pairs: The "name" is "Foobar University", the "website" is "http://example.com" and so on. So while our key-value tags lend themselves well to the second job, they are a bit of an awkward fit for the first job. We need to put something in the key even though it does not add any meaningful information. An education=university would not be any different from an amenity=university – all the information is already there in the value. My preferred response to this situation is to minimize the significance and required brain space for this vestigial key. 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. Other than this unlikely step, the next best solution is continued use of amenity as a catch-all for most features. Contrary to this, some mappers (and your proposal) prefer to use the superfluous key as a makeshift category system. I feel that's the wrong way to go, though: How to best group features into categories depends on the application you have in mind, and providing a categorization is not any more the tagging system's job than making rendering style decisions is. OSM data tells you that there is an education ministry in that location. Whether that feature is filed under the "education", "office" or "government" heading is an application developer's responsibility, and should be of no concern for the OSM data model. tl;dr: Keys are not categories. Tobias _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging