Zoals vaker in OSM wordt het steeds lastiger consensus te bereiken. Op de basale items lukt het aardig maar inmiddels zijn we op meer details aangeland en dan wordt het lastig. Eén van die items zijn de meta data tags. In het verleden hadden we de “source” tag. Daarvan was dacht ik ooit afgesproken deze op de changeset te zetten en niet meer als key te gebruiken maar als ik de wiki lees is niet iedereen het daar mee eens en wordt verwijderen afgeraden. Inmiddels is het aantal metadata tags bijna niet bij te houden. We hebben nu al tig varianten op de source tag maar er zijn er nog meer.
Om data, opslag en traffic te verminderen en performance te verbeteren zou het helpen om een lijst te hebben van meta data tags waar de meeste data consumers niets mee doen. Ik ben op zoek naar zo’n lijst maar kon helaas niets vinden. Toen ben ik zelf maar begonnen en heb inmiddels al een aardige lijst maar ik ben benieuwd of jullie nog meer meta data tags kennen of een lijst weten met al deze tags.
Tot nu toe heb ik : survey, survey:date, survey_date en 91 tags met XXX:source of source:XXX.
NB Ik wil die lijst voor eigen gebruik toepassen en ben dus niet van plan OSM te ontdoen van deze tags.
Ik doe beide, om eerlijk te zijn, om te zorgen dat het vanuit elke context duidelijk is (het bijt elkaar zelden). Maar sommige zijn wel echt beter op het object, zoals het door EveryDoor standaard gehanteerde check_date.
Het “lastige” in Nederland vind ik dat source en source:date op het object vaak al “geclaimd” worden door BAG.* Daardoor kan bijv. survey:date (in dien van toepassing) of idd check_date dus inderdaad een interessante aanvulling zijn. Want je kunt wel dingen toevoegen aan source met puntkomma, maar waar hoort de source:date dan bij?
Ik vul de source op het object iig. wel aan als ik het toegevoegde waarde heeft, bijv. omdat anders echt niet duidelijk is hoe je aan de toegevoegde informatie komt (vaak Survey of Oblique). En zet de bronnen dan ook netjes in de changeset. Een changeset bevat vaak weer meerdere en ik gebruik niet voor elk object elke source - op die manier kan de geïnteresseerde dat dan terugvinden. Zie ik zelf als een “beleefdheids-ding”, net als het maken van een goeie changeset-omschrijving bijvoorbeeld.
*) Voor gebouwen zou het bijvoorbeeld mooier zijn als voor de BAG-bronvermelding naar source:geometry en source:geometry:date gebruikt zouden worden. In het buitenland, waar BAG niet speelt, zie je bijv. vaak source:geometry=Bing ofzo.
Zover als hoe ik het had begrepen was het de bedoeling om source= alleen op objecten te gebruiken voor imports, dus wanneer externe data binnen osm gebracht wordt.
En source op de changeset wanneer je een handmatige wijziging hebt gedaan bijvoorbeeld met local knowledge of een met specifiek beeldmateriaal.
Het probleem met source op het object zit er vooral in dat meerdere bewerkingen achter elkaar verschillende bronnen kunnen hebben en dan bij een wijziging de source niet altijd weggehaald wordt ook als de bron van de nieuwe wijziging anders is.
Maar het is toch ook helemaal niet nodig om met tags aan te geven hoe je aan die data komt? Ik heb als mapper die behoefte niet en ik vermoed ook dat data consumers die niet hebben. Als ik twijfel heb over een edit van jou dan kan ik dat toch gewoon navragen op je changset?
Gezien de enorme variatie aan source:XXXX tags denken er een aantal anders over maar ik snap je punt. Voor mij geldt dat als iemand een maxspeed=30 toevoegt dat er dan geen source:date:maxspeed=XXX en/of een source:maxspeed=XXX nodig is. Maar er zijn mappers die dat graag doen.
Ik heb de lijst wat uit kunnen breiden en dat scheelt ongeveer 1,5% aan opslag bij de tags van “highway=*”.
Voor een vaste/doorlopende import is het wel handig als het object getagd is met de herkomst plus de datum van import.
(Als daar een extern permanent object-id aan vastzit heb je in principe ook mogelijkheden voor automatische sync, maar daar zijn zoveel mitsen en maren en haken en ogen, dat dat in de praktijk eigenlijk nooit tot stand komt.)
Andere bronnen zijn prima als je echt specifiek per object aangeeft waar je dat object vandaan gehaald hebt en op welke datum. Voorbeeld: BAG. De betrouwbaarheid is echter niet groot, want deze tags worden meestal niet onderhouden/bijgewerkt bij aanpassingen. Bijvoorbeeld 3dShapes source tags, niks meer aan af te lezen want iedere mapper behandelt ze verschillend en de meesten laten ze bij aanpassingen ongemoeid.
Source tags waar alleen lagen of algemene bronnen in staan zijn zinloos. Ook op changesets zijn ze niet al te betrouwbaar, trouwens, want er zitten ook allerlei andere edits tussen, en wie specificeert bij een grote changeset precies wat waarvandaan komt, of maakt specifieke changesets per bron of voor elk object?
Kortom, over het geheel gezien kan je er weinig mee. Soms een beetje, samen met de history van het object, mits de source-datum erbij staat.
Bij mapping-projecten kan het wel handig zijn om metadata tijdelijk toe te voegen, je kan daar MapRoulette missies en dergelijke op baseren. Mijn persoonlijke voorwaarde is dan dat er een einddatum op het project staat, en dat je de afhandeling goed regelt.
Een source tag als bijvoorbeeld 3dshapes, Bing of AHN lijkt mooi. Maar wat als ik daarna een aanpassing doe op basis van BGT en luchtfoto? Dan haal ik de oorspronkelijke source tag niet weg. Maar heeft deze dan nog wel waarde?
En andersom: als het object weg is uit Bing gaat iemand het dan ook uit OSM halen? Nee.
Bij de adressen uit de BAG is het anders. Deze worden toegevoegd, omdat ze in de BAG staan. En ook weer verwijderd, omdat ze niet meer in de BAG staan.
Eigenlijk heeft een source tag alleen zin denk ik als het bestaan van het object in OSM gekoppeld is aan de bron waar het uit komt. Dus: weg uit bron dan ook weg uit OSM. (Of aangepast zodat source weg is)
Bronnen bij een changeset zelf zijn dan wel weer heel waardevol. Zoals: survey of AHN. Dat zegt iets over de bron van wijzigingen.
Ik probeer data en metadata te scheiden. Het zou mooi zijn als dat al in OSM zelf gebeurde maar helaas is dat technisch niet mogelijk. Dit nog even los van de vraag of dat praktisch wel zou werken. Voor het scheiden is het makkelijker te filteren op meta data ipv de echte data omdat simpelweg veel minder metadata tags zijn. Ik vermoed dat ik met het huidige filter al 95% te pakken heb. Naast de eerder genoemde voordelen wil ik dit ook doen om het defragmenteren van wegen te verbeteren. Momenteel worden samenvoeg opties niet gedetecteerd als tags identiek zijn op 1 meta tag na (bv source)
Aha, ja daar heb ik op ook al eens over lopen nadenken.
Hoe ik meestal te werk ga is statistisch en iteratief:
Wat betreft statistieken zou ik hier kijken uitvinden hoeveel wegen meer gecombineerd kunnen voor het weglaten van een alle tags die je voor komt en die lijst sorteren. Boven aan die lijst zullen dingen als surface, highway, mofa/moped, traffic_sign staan, wat interessant is wat onderaan staat en of die in de ignore lijst thuis horen.
Iteratief zou je kunnen beginnen met een “agressieve” regel als “als 70% van de tags overeenkomt” en dan aan het werk gaan. Voor elke situatie beoordelen of het goed zo is en zo niet de regels uitbreiden, de set opnieuw genereren en verder totdat je weer een probleem vindt en het script weer aanpassen etc. etc. Hiervoor is het handig als je korte cycles kan maken.
Het enige waar ik eigenlijk altijd een source tag bij doe is bij landuse.
Die staan soms ingetekend met het losse handje, heel vaak op basis van 3DShapes.
Ik pas die aan op basis van de BGT en PDOK beeld en vermeld dan bij source bijvoorbeeld: BGT & PDOK 8 cm Oct23.
In de hoop dat een volgende mapper niet rücksichtslos de omtrek van de bosjes weer als leidraad gaat gebruiken.
Aan deze lijst kun je description=* en authoritative=* toevoegen. Ook de meeste ref*=* tags, zoals ref:bag, ref:ProRailID en ref:ProRailSpoortak ga je in de meeste gevallen niet nodig hebben.
Natuurlijk kun je ook Taginfo afstruinen voor meer obscure tags.
Ik snap je punt maar dat is meer voor later. Er valt nog zo veel samen te voegen met de huidige strikte regel (tags 100% uniek) dat het nog wel ff zal duren voor ik daar energie in ga steken. Ik heb sinds een paar dagen het script gewijzigd waardoor ik niet meer kijk naar meta tags. Het valt me daarbij op dat er een mapper is die wegen opknipt en dan op een deel daarvan een link naar Mapillary opneemt als meta tag. Heel bizar. Als ik dat zou doen met mijn mapillary fotos dan zouden we er binnenkort meer dan 1 miljoen highways bij krijgen
Voor het uitfilteren van meta-tags in je eigen afgeleide OSM-bestanden zou je ook nog kunnen kijken naar de volgende keys (deels ook op nodes / relaties):
expectedXXX= (op nodes, voor validatie van knooppuntnetwerken, ca 25k in NL)
XXdistanceXX= (20k , zitten paar tussen die geen metadata zijn)
Op de knooppuntpaaltjes kan je die tagwaarde vinden: het is het aantal routes waarheen gewezen wordt. Lijkt mij een gewone tag.
Deze tag is de basis voor een van de gevoeligste detectors van problemen met de topologie en consistentie van alle knooppuntnetwerken. Knooppuntnet monitort dat volcontinu.
Met die vermelding zeg ik niet dat die data niet betekenisvol is, maar dat het metadata is in de zin van “data over de data”.
En met die roundtrip, length en expected is nog iets anders aan de hand: als de boel correct gemapt is, dan kan je die data ook al afleiden uit de bestaande data (anders dan bijvoorbeeld source:name=) . Ze dienen voor een belangrijk deel dus vooral validatie-doeleinden.
Wat mij betreft heel mooi en zeker geen reden om ze uit OSM te verwijderen / ontmoedigen, maar als je een lijst zoekt met metadata om uit te filteren uit je eigen afgeleide databestanden dan zouden het wat mij betreft wel kandidaten zijn.
Zeker, maar alleen als die data al aanwezig is in de juiste relatie, en klopt. Bij expected… is de waarde in het veld te zien zonder enige bijkomende data, kennis of survey. Al bestaat er nog maar 1 paaltje, dan nog kun je het zien en taggen als eigenschap van het object. Dus dat vind ik een reguliere tag.
Ook ik zie dit niet als meta data. Het zijn m.i. objectief vast te stellen attributen van het object die geen andere waarde kunnen hebben. Het is zeker mogelijk dat er een aantal af te leiden zijn uit andere eigenschappen maar daarmee is het m.i. nog geen metadata in de zin dat het data over data is. Dus … echt wel anders dan source, survey_date, image etc. Daar zijn vele andere waardes geldig afhankelijk van wie e.e.a. invoert.
