Now soliciting feedback on a proposal to categorize all education features under an education key. Similar to healthcare, existing tags would not be deprecated.
https://wiki.openstreetmap.org/wiki/Proposal:Education_tag
Please, cross post this announcement on the tagging mailing list on my behalf by sending an email to: tagging@openstreetmap.org
Posted to Tagging
Several of these seems to simultaneously make the tagging much more unwieldy while also making it less specific.
amenity=flight_school - a place where you learn to fly aircraft becomes: education=training + training=aviation a place where you might learn to fly but also might learn aircraft maintenance? or how to work as ground crew ? Air traffic controllers too? The current description is “Indicates that the facility provides aviation training.” with aviation defined in e.g. wikitionary as:
So basically anything remotely related to the industry.
Similarly:
amenity=dojo - a place to learn or practive Japanese martial arts. becomes the less specific: education=training + training=martial_art which could also cover sport=fencing, wrestling, boxing, hapkido, kickboxing .
If the aim is to eventually take over the main classification for these amenities as with healthcare, shouldn’t they be more specific rather than less?
I have some issues with the “education=training, training=*” concept
too. Most places where you go to practice a sport will also be places
where you learn that sport (maybe by practicing?), but sports clubs
are not mainly for education. The already-mentioned amenity=dojo is a
place where you can practice and learn Japanese martial arts but I would
not say that a dojo is first an foremost an “educational” establishment.
Unsure if this is just a language thing. And yes, I know that prisons
are not generally considered amenities - but let’s not add more top
level tags that (in OSM) cover something that people would not (in the
real world) search under that term.
I’m a big fan of education=* . In general, this will really streamline the tagging of education facilities and enable more specificity while increasing usage by simplifying queries.
@InsertUser, you mentioned some really good aspects within the Aviation training sector. Could you come up with a couple more tags that might better capture training in that sector? Like education=training + training=aviation + aviation = maintenance …=ATC …=… . I think this structure actually fits perfectly and would enable folks who are interested in aviation education to expand this concept. It provides flexibility to those with particular interests while providing a natural “home”, without forcing “amenity” to be the generic catch all. I think the failure of some of the previous education efforts were exactly because they were overly prescriptive and some users felt pigeon-holed into something. I certainly am not qualified to think about all of the nuances of aviation education, I think that should be left to that particular OSM userbase. I think this education=* proposal enables a structure that offers users more flexibility and specificity without constraining them.
@woodpeck, and @InsertUser since training=* was rejected. I think you both mention some key points for clarification. Does the addition of training=* take away from sport=* ? Is there a difference in places that have sport only, or also include training? I would argue that education=training + training=fencing implies sport=fencing (and should be tagged as such), and would certainly not replace it but sport=fencing does not imply that instruction is performed. This would also apply to your examples of wrestling, boxing, hapkido, and kickboxing.
Given the previous highly ambitious that were not successful on the basis of being too broad. I think the scope is right for this one. Again, I think it provides a nice option, and a framework which, as @InsertUser demonstrates so clearly, could be applied in a variety of contexts, each of which could be proposed to meet the needs of that specific OSM user base. From a functionality perspective, since this deprecates no tags, there will be no compatibility issues with pre-existing hardware or software, but instead makes an option to streamline queries, just like healthcare=* did.
I look forward to seeing more discussion! (edited because * and the period put everything in italics)
My main issue here is somehow assuming that what we did with amenity and healthcare is actually a success with nothing to back it up. IMHO we need at least look at how that has evolved before we simply repeat the same thing again.
I recently looked on the principal healthcare tags, for pharmacies, hospitals, doctors and dentists, “classic tags” were still leading with a constant offset, i.e. both tagging variants growing in similar rates.
It’s no secret why: id-tagging-schema (and iD before it) pairs the amenity=* tags with healthcare=* tags.
I’m not sure that the success or failure of Healthcare 2.0 is really a story of usage numbers anyways. The original proposal envisioned the healthcare=* tags eclipsing the traditional amenity=* tags through an automated edit, to be carried out only after editors/renderers/geocoders added “support” for the new scheme. The editors might be a done deal at this point, but do we know if major renderers and geocoders support the new scheme on its own?
I don’t think this measure of Healthcare 2.0’s success is particularly relevant to the new education proposal, which wants to be purely additive. As this proposal focuses on queryability, do we suspect that people these days are more likely to query by healthcare=* than by the amenity=* tags?
A different way to gauge Healthcare 2.0’s success is that it opened up an avenue for tag development. In integrated medicine and alternative medicine, a facility couldn’t necessarily be categorized into one of the traditional amenities or offices. It’s a lot less scary to any-tag-you-like a novel value under either healthcare=* or office=* than under amenity=*. I think that’s because you can expect a reasonable generic map icon or search result label based on the key. The same goes with some other thematic keys such as police=* and playground=*, and to a lesser degree with some others like craft=* and historic=*.
With education=*, I think a risk is that pulling too many learning- or training-related features into the same theme may dilute the theme, so that neither data consumers nor mappers feel as comfortable making assumptions about a given tag’s relevance to core educational infrastructure. But it’s really hard to draw the line between learning and training facilities.
Most of the training=* features I’ve mapped have been things like this fire training center, where professional firefighters conduct annual required training as part of a professional development program. Occasionally the same physical feature appears on the grounds of a vocational school. To a 3D renderer, these are the same thing: the same model of a cross-section of a two-story house will apply regardless of who goes in and saves the day. A geocoder might call them both “firefighter training centers”, but technically they’re both just towers, the main physical plant of two different kinds of institutions. Does this difference matter to the sort of analyst who queries based on education=* instead of based on amenity=*?
According to “taginfo” pretty much no - just the usual suspects represented there, which often (if the thing also has an amenity tag) just leads to extra code.
The extra code is needed because (taking dentistry as an example) some mappers do it the old way, some exclusively the new and some a mixture. That’s challenging because some of the facilities “only tagged the new way” are regular dentists and some are not.
For me, the main gripe I have with current educational tagging is that university departments are mapped under the rather unhelpful, unsupported and vague amenity=department. amenity=faculty is not faring much better, but at least it is less ambiguous.
If nothing else, education=department is less likely to be mistaken for shop=department or government=ministry.
For the rest of the current discussion, I would probably concur: training=* is rather clunky.
Thank you all for the discussion. I have updated the proposal to incorporate your feedback. Notably, I have removed the nesting of values like driving_school under training=. They are instead mapped directly under education, e.g. education=driving_school. This means that the proposal does not redefine the meaning of any existing tag values.
Please let me know if there are any remaining sore points. Otherwise I will submit the proposal for voting by the end of this week.
What hooks into this is the landuse=education with 31K use so far. It has no cross mention in the proposal. landuse=education | Tags | OpenStreetMap Taginfo
The big absent in the render department being Carto S. You need amenity=school to get the yellow background for the area… 9.8K have been double tagged.
@SekeRob I’m open to argument but I don’t really think landuse=education falls under the scope of the proposal. The education key is meant to be used for a school in the organizational sense, not the physical sense. The number of education tags should match the number of schools regardless of whether they are mapped as point or areas or whether or not they share a campus.
By the way, 267 features use education=* to iteratively refine landuse=education. If the proposal passes, then each of these features would be reinterpreted as a dual-tagged education=* POI and landuse=education land use area. Coincidentally, the approved landuse=education proposal explicitly provided for dual-tagging with amenity=school etc. as a temporary measure. Layering another dual-tagging scheme on top of this one would effectively make the transition period permanent (if it isn’t already).