In aanvulling op alle goede opmerkingen hierboven, wil ik ook nogmaals voor Gerrit benadrukken dat het toevoegen van willekeurige Nederlandstalige gegevensvelden vanuit een GIS systeem aan OSM ongewenst is.
Alleen als alle gegevensvelden naar een zinvolle engelstalige “key” worden omgezet, heeft invoer in OSM nut en zin. OSM is niet een lokale database waaraan door iedereen willekeurig lokale gegevens worden toegevoed, het is een wereldwijd ingezette database, met toepassingen die wereldwijd moeten kunnen functioneren. Denk aan b.v. routeringssystemen die “over de grenzen” gaan, die hebben niets aan data ingevoerd in een lokale taal.
OpenStreetMap is zeer zeker ook niet een vervanging voor een eigen organisatiebrede ‘WebGIS’…
Het streven moet bij een OSM import, waar dit toch zeer sterk op lijkt, nooit zijn om de maximale hoeveelheid gegevens mee te nemen, maar juist de absoluut minimale die nut heeft en aansluit bij de bestaande data / keys, en tagging conventies vastgelegd in de Wiki van OpenStreetMap. Alleen op die manier wordt een breed inzetbare database gegarandeerd.
“Strenge regels kunnen wel een belemmering worden mutaties. Stimuleerd niet om de map te verbeteren.”
Om toch nog de impact van deze import te illustreren: stel je zelf de volgende vraag:
Wat zou jij persoonlijk er van vinden als wij toegang hadden tot de zorgvuldig beheerde gemeentelijke CAD/GIS systemen, en daar van alles naar onze eigen hand en voorkeur in gaan stellen, b.v. de line en entity types van de CAD bestanden, of gegevensvelden hernoemen zodat geen enkele kaart meer het juiste weergeeft?
Hoor ik daar een binnensmondse vloek als je 's ochtends op je werk komend ontdekt wat er gebeurd is??
Dat is dus de impact van een dergelijke import… OSM is met zijn vrije tagging systeem misschien meer wild-west dan we soms willen, maar dat betekent niet dat er het duidelijke streven is om tot tagging conventies en standaarden te komen, en dat er al veel is vastgelegd in de Wiki.
Zoals anderen al hebben aangegeven: indien de bestaande tags niet passen voor bepaalde attributen, dan heb je twee keuzes: 1) weglaten en alleen datgene toevoegen dat wel past, dit is de meest voor de hand liggende optie, en 2) een voorstel doen om nieuwe tags aan te maken, en liefst in de Wiki vastleggen.
Persoonlijk, kijkend naar de voorbeeld screenshots die Commodoortje heeft geplaatst, denk ik dat hooguit 5 tot maximaal 10 van de zichtbare attributen, direct gerelateerd aan adressen, een plaats hebben in OSM, de rest zou weggelaten moeten worden.
Als laatste: het negeren van JOSM validator errors is voor de originele editor dan misschien wel een leuke tijdsbesparing, maar zorgt in de toekomst voor veel extra werk voor diegenen die het originele werk willen aanpassen. Het is niet voor niets dat b.v. in het landelijke BGT (Basisregistratie Grootschalige Topografie), waar je ongetwijfeld van gehoord hebt of ook bijdragen aan moet leveren, een strenge topologie en inhouds controle is ingebouwd.
