Onverenigbare tags (n.a.v. osmose)

In dit gebied:

https://www.openstreetmap.org/way/80769165

wordt de volgende melding gegeven:

http://osmose.openstreetmap.fr/nl/error/1103514282

De tags “natural=" en "leisure=” kunnen niet voor hetzelfde gebruikt worden.

Van sommige tags kan ik me goed voorstellen dat ze onverenigbaar zijn (“amenity”/“highway”, “building”/“natural” enz), maar van een meertje (“natural=water”) kan ik me wel degelijk voorstellen dat je er kunt ontspannen (“leisure=fishing”)!
In een ander draadje van mijn kwam al iets dergelijks voor mbt. “amenity” en “leisure” die niet samen voor mogen komen op dezelfde node.

Vraag 1: hoe zou ik de tags moeten plaatsen zodat bovengenoemde situatie geen fouten meer oproept bij osmose?
Vraag 2: als bepaalde tags inderdaad niet samen kunnen (mogen?) gaan, zou er dan geen waarschuwing moeten komen (van bv. josm) dat er iets niet klopt? (ik krijg in bovenstaande situatie geen enkele feedback/melding van josm)

//overpeinzing aan
Die situatie met onverenigbare tags komt vrij regelmatig voor valt me op, nu ik osmose wat vaker gebruik. Iedere database bevat foute data en ieder programma bugs, maar iets meer foutcontrole vanuit de database zelf zou helpen om die database ook nuttig te houden in de toekomst. Als ik bij mijn bankprogramma mijn naam invul in het veld dat bedoeld is voor een rekeningnummer, dan wordt dat echt niet geaccepteerd!
Ik heb het even geprobeerd: in josm (en dus ook in OSM) kan ik een meertje ook een parkeerplaats EN ziekenhuis laten zijn!
Wat moet een renderer doen als hij iets dergelijks tegenkomt?
Dat vind ik op zijn minst een ontwerpfout! (van die database)
In eerdere posts van mij kwam dit ook al ter sprake mbt. bv. gemeentegrenzen. (een grens is geen water, maar hij kan wel door het water lopen)
//overpeinzing uit

Marc,

Met deze opmerkingen raak je aan het absolute hart of zogezegd de essentie van wat OSM is… OSM is geen relationele database (RDBMS) met een strak geregisseerd data model, met eenduidige vastomschreven vertalingen van “werkelijkheid” naar objecten in de database, zoals een kadaster dat b.v. zou maken.

Voor zover ik het kan beoordelen, op basis van alles wat ik tot nu toe heb gelezen over OSM en de oorsprong van het project, is OSM al vanaf zijn inceptie een volledig “free-tagging” systeem, waarbij elke gebruiker volledig vrij is om elke willekeurige node, way of relation, een willekeurige tag mee te geven. Dus ja, vanuit OSM technisch opzicht, is er dus absoluut niets mis met een parkeerplaats op het water…

OSM werkt feitelijk op basis van een diffuus “consensus” begrip, waarbij de meerderheid van de OSM “contributors” min of meer bepaalt wat de juiste semantiek voor bepaalde objecten uit de werkelijkheid is. Dat daarbij flinke interpretatie verschillen optreden, is inderdaad onvermijdelijk, en geeft aanleiding tot vele discussies die je op de Wikipedia pagina’s voor Keys en Tags kunt tegen komen. Dat wil niet zeggen dat het totale “wild-west” is. Enerzijds weet iedereen “gevoelsmatig” al enigzins wat de juiste manier van taggen is (weinig mensen zullen b.v. een gigantische koeltoren bij een elektriciteitscentrale als punt object opnemen in OSM als ze een micro-kartering van alle objecten in een centrale gaan doen, maar toch automatisch voor een cirkelvormige “way” kiezen, hetzelfde geldt voor een olietank in de Botlek), en anderzijds doen sommige edittools al min of meer suggesties voor de juiste vorm van taggen via presets zoals een puntsymbool voor een picnickplaats en bijbehorende attributen. Daarnaast zijn er meerdere controle tools, die een poging wagen om al te grote “onzin” of geometrische problemen, te detecteren. Als laatste is er het (ook niet onomstreden) “voting” systeem, dat een soort van besluitproces over tagging moet ondersteunen.

Als rechtgeaarde DBA’er kan je van dit alles een beetje schrikken, maar het is ook in die wereld een trend om non-relationele databases en gegevensvelden steeds meer toe te passen. Ook de grote RDBMsen bieden hier tegenwoordig ondersteuning voor.

En ja, uiteindelijk is het inderdaad aan de renderers, om nog enigzins “chocolade” van dit alles te maken, of de tagging nu in iemands ogen fout is of niet (maar bedenk dat iemand anders een reden kan hebben voor een ongebruikelijke tagging…). Dat is inderdaad geen makkelijke klus, en al helemaal niet een die een soort absolute “waarheid” kan laten zien, en mede een aanleiding voor vele verzoeken, issuemeldingen en vragen op de Github Mapnik/CartoCSS site.

De werkelijkheid is grijs, niet zwart-wit, en OSM is dit ook…

Maar wie bepaalt dan dat amenity=* en leisure=* op één node onverenigbaar zijn?
Want dat is waar mijn vraag over ging (en maar heel zijdelings over de structuur van de database).
Iedere tag bestaat uit een “key” en een “value”. Volgens mij kun je die “value” inderdaad iedere waarde meegeven die je wilt en is je keus voor “key” wat beperkter en wordt je geacht te kiezen uit de lijst van de beschikbare (of overeengekomen) waarden.

Als osmose dus die onverenigbaarheid vaststelt (“conflict between tags” meldt osmose), op basis van welke regels gebeurt dat dan?
En dat komt behoorlijk vaak voor. In het gebied romdom mijn woonplaats (15 km rond Vught) tref ik er al tientallen aan. En daar is heel vaak het paar amenity/leisure bij, maar ook amenity/highway en amenity/landuse.

Het is als eerste mijn verantwoordelijkheid om te zorgen dat ik geen onzin op de kaart zet, maar klaarblijkelijk hebben veel mappers daar dan toch moeite mee als we afgaan op osmose. En het zou dan dus ook handig zijn als de editors die we gebruiken (JOSM, iD, Potlach enz.) ook weet hebben van de regels en je laten melden dat de node die een tag highway=primary en amenity=bus_stop heeft, op zijn minst niet erg logisch is.
Dat een bushalte langs de weg ligt is normaal, maar klaarblijkelijk zijn er veel mappers die dus één van de nodes die de weg markeren ook maar als bushalte aanmerken. Terwijl je daar dus eigenlijk een nieuwe node voor moet plaatsen.
Kijk nog eens naar deze:
http://www.openstreetmap.org/node/677812667#map=17/51.30859/4.94832

Kan niet zegt osmose. Maar waarom niet?

Dus daarom dan mijn vraag aan jou: welke regels hanteert osmose en waarom?

Die vraag kan je beter stellen aan de ontwikkelaars van Osmose:

Ik ga ervan uit dat de ontwikkelaars van Osmose het principe One feature, one OSM element hanteren.