noordfiets heeft in twee recente posts aangegeven dat het goed kan zijn voor OSM om de database te splitsen. Ik begrijp dit niet helemaal. Het lijkt op een discussie over lagen die elders in OSM wel eens gevoerd is. Waar voordelen aan zitten (zo kun je bijvoorbeeld uitsluiten dat beginnende mappers een landsgrens verminken, en zo kun je ook bijvoorbeeld vrij eenvoudig maandelijks nieuwe BAG adresdata binnenhalen), maar ook nadelen (hoe ga je om met lagen die van tags worden voorzien die in andere lagen thuishoren, hoe ga je om met adressen die aan amenity=building-objecten zijn verbonden). Een argument om de database in zijn geheel intact te laten: een programma als JOSM heeft fantastische mogelijkheden om te filteren op bepaalde tags. De overpass-api (ken ik niet zo goed) kan zoiets volgens mij ook. En er zijn al diverse kaartweergaven die ook gebruik maken van filteren van info uit de huidige enkele database.
Deze post is vooral bedoeld om die voor- en nadelen uit te schrijven. Graag reactie!
De kaartinformatie (bv. wegen, omtrek van de gebouwen, topografische kenmerken, openbaar vervoer haltes, treinlijnen) afsplitsen lijkt mij geen goed idee.
Als dat in elk land gebeurd in een andere database krijgen we straks een witte kaart.
De tools zijn universeel te gebruiken.
Als ik bv. een papieren kaart wil printen kan ik nu maposmatic.org gebruiken.
Voor informatie die veel veranderd of voor specifieke Nederlandse toepassingen heeft een aparte database wel voordelen.
Hier denk ik bv. aan file informatie, openingstijden, openbaar vervoer schema’s, etc.
De grootte van de database lijkt mij geen thema. Je gebruikt de tags die je nodig heb en de rest negeer je.
Het splitsen van een database in aparte systemen of het selectief uitlezen van bepaalde tags uit een database lijkt wat gebruik betreft veel op elkaar.
Alleen het beheer is dan verschillend.
Niet splitsen. Hiervoor is geen enkele reden. We kunnen op de Wet van Moore vertrouwen dat de computersystemen waar OSM op draait de grootte van de database wel kunnen bijhouden.
In de fysieke wereld heb je toch ook niet aparte “lagen” met gebouwen, busroutes, etc. De wereld is 1 groot GIS-systeem op 1:1 schaal, maar helaas zonder query-functionaliteit Alles wat in de OSM-database zit heeft een bepaalde geografische basis en daarmee veel relaties met nabijgelegen objecten (en minder met verderaf gelegen objecten).
Een ander argument is dat als je de database thematisch opsplitst, je extra moeite moet doen om alles in sync te houden. Dat is nu al lastig, maar dan wordt dat helemaal een probleem. En als je thematisch wil opsplitsen, waar leg je dan de grens? Die is niet te leggen, net zoals nu het al lastig is om veel objecten d.m.v. de juiste tagging aan te geven.
Je kunt natuurlijk wel filteren. En als je bijv. de BAG wil gebruiken ipv de OSM-adressen, kan dat ook prima, door de adressen in OSM eruit te filteren.
Alles wat in de OSM-database zit heeft een bepaalde geografische basis en daarmee veel relaties met nabijgelegen objecten (en minder met verderaf gelegen objecten).