Sure, we could experiment with storing "preset id" in the OSM features, e.g. preset_id=Q12345 would imply that this feature should have `leisure=pitch+sport=soccer+surface=grass`. Also, in some cases it might even be possible to have multiple presets for the same feature. I don't think we should use wikidata key for that - despite technical limitation of not allowing OSM wiki to use non "Q" values, those are different from wikidata. Wikidata ID most often implies that this specific instance is described in Wikidata, whereas preset_id indicates item class.
All these ideas are great, but we may want to take the low hanging fruit first - migrate existing wiki pages to use dynamic data from Wikibase, and make iD, JOSM, and other tools use this new data. On Tue, Sep 18, 2018 at 4:09 PM Janko Mihelić <jan...@gmail.com> wrote: > Each tag combination could have a wikidata link that describes what that > combination really "is". So if we make an item for combination > leisure=pitch+sport=soccer, we can put a property wikidata=Q8524[1]. That > means that someone can make a script that finds all wikidata items Q8524 on > the map. Our tags finally get a real semantic definition. That is really > exciting! > > P.S. There mustn't be more than one OSM item with the same Wikidata item. > So a minimal combination of OSM tags should have the wikidata tag. For > example, in my opinion leisure=pitch+sport=soccer+surface=grass shouldn't > get the Q8524 because a pitch can have artificial grass, and it would still > be considered a football field. > > [1] https://www.wikidata.org/wiki/Q8524 > > Janko > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging >
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
