Importeren of niet?

Naar aanleiding van een aantal discussies in dit forum aangaande imports (onder andere de tuinimports in Tilburg) wil ik hier toch de zaak ‘import’ wat fundamenteler aan de orde stellen.

De OSM-NL community is ‘gezegend’ met een headstart toen de landuse in NL door een AND-import ongeveer compleet was.

In hoeverre de AND-import toen foutloos was kan en wil niemand - ik in ieder geval niet – meer controleren.

Feit is dat deze import, behoorlijk grofstoffelijk bovendien, in ons aangeharkte en omgeploegde landje in ieder geval volstrekt niet actueel meer is, wat we ook zien doordat veel van deze landuse inmiddels op basis van waarnemingen in het veld, PDOK-luchtfoto’s etc. aangepast zijn (het dan verwijderen van de source-tag AND_import zou wat consencieuzer kunnen plaatsvinden :))

Zo ook hebben we in Nederland de eenmalige BAG-import gehad (in 2014), waar ongeveer alle (legale) gebouwen in Nederland met hun adresgegeven geïmporteerd zijn, daarbij eerdere handmatig gemapte gebouwen vervangend.

Deze “BAG-gebouwen” worden steeds onderhouden door een aantal ‘BAGgeraars’ onder wie ik.

Bij deze imports en updates moeten we steeds omzichtig te werk gaan: veel gebouwen staan in de BAG, maar zijn er in het echt niet (meer) of nog lang niet en ook staan er gebouwen niet in de BAG. Deze verificatie vindt plaats door de ‘tipgevers’ in het betreffende BAG-import topic, in het veld of door vergelijk met PDOK-aerial (bijvoorbeeld een BAG-fabriekshal met bouwjaar 1910, die op de PDOK-luchtfoto niet meer staat; daar kun je van aannemen dat die inmiddels gesloopt is en de - officiële - BAG-registratie onjuist.)

Wat ik met bovenstaand wil aantonen, is dat handwerk vereist is en we niet op import uit overheidsdata kunnen vertrouwen.

De vraag - en het antwoord - of we moeten importeren wat we kunnen importeren ( "omdat het kan"), is meer persoonlijker, maar mijn argumenten wil ik toch delen, voor wat het waard is:

OSM is niet en zal het ook nooit zijn, een 100% afspiegeling van alle overheidsdata; OSM is geen back-updatabase voor de overheid. Als overheden gebruik maken van OSM, voor wat dan ook, is dat geheel voor eigen risico; immers: iedere janlul kan OSM veranderen.

Het importeren van hydranten (met aansluitmaten!), lantaarnpalen, kavelgrenzen en wat dies meer kan maar behoeft imho zeker niet.

De toegevoegde waarde van dergelijke elementen in OSM acht ik nul (voor lantaarnpalen hebben we lit=yes op een highway, dat is voldoende informatie om een nachtelijke rit te kunnen uitzoeken). Als een mapper op basis van survey dergelijke elementen mapt: soit, maar een massa-import (met het oogmerk volledig, compleet en actueel te zijn en blijven?) acht ik zinloos en ongewenst.

Als een import bovendien bewezen fouten bevat, vind ik dat die import sowieso niet gebeuren moet. Niet een massa importeren, de fouten (hoe?) beginnen te corrigeren, er achter komen dat dat toch wel moeilijk is en veel tijd kost, hopen dat “de anderen” jouw import wel gaan corrigeren: fout! Niet doen!

Ga naar buiten, pak je fiets, kijk en map!

Dit is mij uit het hart gegrepen:

Ik kan echt niet begrijpen waarom sommige mensen objecten toevoegen aan de kaart die ze kennelijk niet de moeite waard vinden om naartoe te gaan. :wink:

Maar je hebt waarschijnlijk zelf al gezien dat het vandaag geen fietsweer is. :frowning:

Heel goed stuk Martin!
Geheel mee eens.

Vanmorgen om zeven uur met lichte motregen en wind mee op de racefiets naar het werk! Deels over een recent aangelegd, over een voormalig spoortracé, zelf gemapt, fietspad :smiley:

+1 ook helemaal mee eens.

Sluit ik me helemaal bij aan.

En als toevoeging: het is vrij eenvoudig een externe database met objecten als layer op de OSM kaart te leggen.
De gemeente Groningen bijvoorbeeld gebruikt OSM als basis voor zijn online-klachten portaal. Daarboven keurig een laag met alle lichtmasten etc.

Geautomatiseerde imports zijn riskant met het huidige detailniveau van de Nederlandse kaart (en dat is alleen maar mooi), maar door mappers gevalideerde data kan soms wel de moeite waard zijn. Ik heb dankbaar gebruik gemaakt van de CBS-grenzen voor wijken en buurten om de wijken en buurten in Leeuwarden in kaart te brengen. (Hier nader beschreven.) Elk stukje grens, naamgeving, en classificatiekeuze (buurt of wijk) is door mijn handen gegaan, en gebruikt waar overeenkomend met de werkelijkheid, of aangepast, simpelweg hertekend, of niet gebruikt waar niet.

Sommige wijken kloppen exact. Anderen komen in de CBS-data voor geen meter overeen met de werkelijkheid (omdat de CBS-data wijken een buurten indeelt voor statistische doeleinden).

Maar bij zo’n aanpak spreek je meer over een handmatige import denk ik. Je laat in ieder geval de kennis van de (lokale) mapper voorgaan.

Ik ben het volledig eens met het betoog van Martin en met de reacties!

Tot nu toe zijn alle externe databronnen waarvan ik dacht “die zou handig zijn voor import” uitgedraaid op handwerk.
Eenmalige import kan MI wel, maar de voorwaarden zijn nogal streng:

  • Een geverifieerde en in principe betrouwbare bron (met de juiste toestemming uiteraard).
  • De kwaliteit/juistheid moet bekend zijn. Het hoeft niet 100% te zijn, maar wel behoorlijk hoog, en je moet een inschatting kunnen maken van de hoeveelheid werk (en de urgentie) die het gaat opleveren om te korrigeren. Dat je daar een haalbaar plan voor hebt.
  • Het mag nooit bestaande data vervangen of verwijderen. Maar er zal meestal bestaande data zijn of kunnen zijn.

Als je zo’n eenmalig import hebt gedaan en gekorrigeerd, dan rijst altijd het volgende punt: Bijhouden!

Want de brondata zal veranderen en de OSM data ook. Uiteindelijk heb je altijd een sync-situatie. Dus dan moet je als eerste stap een diff doen: beide dataverzamelingen vergelijken en beslissen wanneer iets toegevoegd, weggehaald of aangepast moet worden. Daaruit volgt wat er gemuteerd gaat worden.

Dus dan is het verhaal niet meer: kan je het importeren en wat zijn de datatransformaties (datamapping) maar: hoe beslis je wat er in alle mogelijke gevallen moet gebeuren? Kun je dat automatiseren of is het geval voor geval afhankelijk van de omstandigheden?

Door deze dingen zal het meestal slecht aflopen voor de importmogelijkheden!

Een tool die MI voor alle vormen van synchronisatie nuttig zou zijn is: een verschillenlijstmaker. Maar ik zie daar geen generieke oplossing voor, dus per bronverzameling zou je er een moeten hebben. Of een generieke tool met per verzameling een plugin voor kontroles en datamapping. De verwerking van de verschillen lijkt mij in de meeste gevallen toch op handwerk uitdraaien, maar daarbij zou het wel heel erg helpen!

Voorbeeld: stel de geplande centrale database van Stolpersteine komt daadwerkelijk tot stand. Veel stolpersteine zijn in OSM opgenomen, er is een taggingschema voor. Je kan een datamapping maken van die database naar OSM. Als je nou OSM kompleet wil maken mbv die database kan je hem niet rucksichtlos gaan importeren (zelfs als de datakwaliteit 100% is en de geolokaties exact kloppen). Handmatig kijken welke er al gemapt zijn, die aanpassen, en de nieuwe ff invoeren is eeen krankzinnig werk, en als het klaar is kan je opnieuw beginnen want de brondata is alweer veranderd!

Wat je dus nodig hebt is een lijst van verschillen waar je mee aan de slag kan. Nieuwe objecten kunnen toegevoegd worden, dat zou misschien automatisch kunnen; OSM-objecten die in de verse brondata niet voorkomen moet je laten staan; en waar de objecten matchen moet je de verschillen beoordelen en doorvoeren indien gewenst en indien mogelijk.

MI kan dit ook alleen voor databronnen die genoeg vastigheid hebben, en voor OSM-doelen die genoeg vaste belangstellende mappers hebben.

Ik ben in grotendeels met het betoog.
De importen in het verleden (AND en 3shapes) hebben voor mij OSM zowel letterlijk als figuurlijk op de kaart gezet.
Als je met niets begint heb ik liever een kaart die voor 99% correct is dan een kaart waarvan 10% van het land gevuld is met 100% correcte data (die daarna ook weer verouderd). Zonder beide imports zou ik in een wit gebied leven en nooit met OSM begonnen zin.

Over het per definitie werken met overlays ipv data overnemen ben ik minder enthousiast. Als bepaalde data wereldwijd ingevoerd wordt, dan zie ik de data in Nederland liever in OSM dan in een overlay.
Stel dat de leggers met waterstromen 100% perfect zouden zijn, dan zou een overlay hiervan efficienter zijn. Maar als ik dan een app gebruikt dan staat er geen enkele waterstroom meer in.
Overlays zijn m.i. perfect voor beheerders en data waarin de andere kaartgebruikers geen interesse in hebben.

Stolpersteine vind ik zelf juist een voorbeeld waar het gebruik van een overlay niet meer gewenst is als er internationale apps komen die de stenen in heel Europa laten zien op basis van osm.
Een complete import hiervan zie ik niet zitten. Wel een handmatige import door het vergelijken van OSM met een centrale database.
Als deze apps de centrale database gebruiken wordt het juist weer andersom.
M.a.w. voor mij hangt de vraag of je wel of niets in OSM moet invoeren sterke samen met hoe de vraag naar de data is.
Zouden de apps die stolpersteine laten zien OSM gebruiken en als er dan in Nederland maar beperkt ingevoerd zijn dan kun je wachten op iemand die vanuit het buitenland de informatie uit de database gaat overzetten in OSM.

Vandaar mijn pleidooi voor een standaard vergelijkingsprogramma met plugins per dataverzameling. Output is een verschillenlijst, die vervolgens naar beide zijden toe in ieder geval handmatig verwerkt kan worden. Ook handig voor bespreking vooraf van geautomatiseerde imports, dan weet je precies waar je het over hebt.

In veel landen hebben zo’n imports nooit plaatsgevonden en nochtans lopen die niet echt achter.

Niet echt achter?
Lopen ze wel of niet achter?

We liepen volgens mij echt wel voor door die imports, maar door de ahum magere kwaliteit trad de wet van de remmende voorsprong in werking. Als je NL als geheel bekijkt zijn we extreem gedetailleerd in kaart gebracht, maar als je heel gedetailleerd ergens aan het mappen bent kom je veel kwalitatief teleurstellende dingen tegen.

Ik ben ook zeer blij met de 3dShapes en AND.
Als ik bijvoorbeeld hier vlak over de grens kijk waar een Duitse mapper alles, maar dan ook alles met polygonen aan elkaar lijmt dan ben ik blij dat ik door onze oude imports gezien heb dat het ook anders kan.
Het klopt dat oude stukken gras en bos soms erg fout zijn in Nederland maar het was een goed begin :slight_smile:

Zo’n tien jaar geleden had ik de gekochte City Navigator kaart van Garmin nog nodig in Frankrijk anders fietste ik in het “niets”
De OSM had ik als extra op m’n etrex erbij, maar veel had je er niet aan.
Nu is het precies andersom.
In Frankrijk hadden velen nog Minitel en geen PC. OSM liep daardoor hopeloos achter. Minitel is ook zo’n voorbeeld van de remmende voorsprong.
Toch zie je in Nederland nog wel de erfenis van AND. Veel binnenstraten staan nog op unclassified en toegangswegen naar boerderijen op highway=pedestrian.

Ja … en dat plakken in Duitsland is een ramp. Zo is Den Haag ook op de “Duitse manier” aan elkaar geplakt.
Mapper was niet voor rede vatbaar, maar daar zie ik meer voorbeelden van.

edit: In Frankrijk is nu ook veel import geweest van voornamelijk “bos”. Dat ligt helaas wel heel willekeurig en is in niets te vergelijken met onze import.

Hi Martin, ++ zoals je het verwoord. Het voordeel boven alle andere items (kaarten) van OSM is de survey, ga uit en leg vast en niet vanuit een arial view, dan is er geen onderscheid tussen een oude heg en een bomenrij.

Niet. Landuse is Vlaanderen is voor het grootste deel handwerk.
En de kwaliteit is volgens mij beter dan die 3D data die er nog tegen de grens ligt.

Even een side-topic. Momenteel worden de Natura2000 gebieden door AdVerburg toegevoegd uit PDOK data, viel me toevallig op.

Waar wordt zo’n import besproken, en hoort die discussie niet gelinkt te worden in iedere changeset van de desbetreffende import?

Aan de snelheid van het toevoegen te zien lijkt dat niet om een automatische import te gaan, maar worden de natuurgebieden handmatig toegevoegd m.b.v. PDOK-data.