Basisregistratie Grootschalige Topografie (BGT)

Hoi,

Deze thread wil ik graag gaan gebruiken voor de discussie over hoe de Basisregistratie Grootschalige Topografie (BGT) binnen OSM ontsloten kan worden en of (en zo ja hoe) informatie vanuit OSM op de een of andere manier aan de BGT teruggeleverd kan worden. Het idee hiervoor is ontstaan tijdens de samenwerkingssessie bij Rijkswaterstaat op 19 sept. jl.

De BGT is natuurlijk een heel breed onderwerp. We moeten allereerst vaststellen wat we ermee kunnen en waar de behoefte ligt. Van hieruit kunnen kleinere onderwerpen worden opgepakt, die in meer detail besproken kunnen worden. Eén van die onderwerpen is bijv. kunstwerken.

Het is NIET de bedoeling van deze discussie om de BGT integraal te importeren in OSM. Ik kan me wel indenken dat dit voor sommige zaken wel gaat gebeuren, maar ik denk dat er betere manieren te verzinnen zijn om de BGT en OSM te combineren. Mocht er sprake zijn van import in een bepaalde vorm, dan zal natuurlijk aan de importrichtlijnen van OSM voldaan moeten worden.

De belangrijkste reden dat ik zelf ben aangehaakt, is omdat ik van plan ben om de BGT binnen NLExtract te ondersteunen. GML is nogal een complex formaat en het datamodel van de BGT (gebaseerd op CityGML en het informatiemodel geografie, ofwel IMGeo) maakt het nog complexer. Wanneer de data eenmaal in PostGIS geladen is, kan het veel gemakkelijker voor andere doeleinden worden gebruikt.

Om de discussie te starten, stel ik een aantal vragen:

  • Hoe zou jij de BGT graag binnen OSM gebruikt zien? Heb je speciale wensen?
  • Op wat voor manier kan informatie vanuit OSM gebruikt worden om de BGT te verrijken?
  • Hoe kunnen gegevens tussen de BGT en OSM uitgewisseld worden (mapping)?

Groeten,

Frank

Netjes Frank, Jij kunt bijna meer vragen dan … :slight_smile:
Voor mij is het denk ik wel duidelijk, maar ik struikel als er geen “import” plaatsvindt. Niet dat ik dat nodig heb want ik ga voor gedetaileerde inzage daar kan ik wel mee werken. bv kunstwerken maar daar ligt al voor jaren werk, er zijn er ongezien <1.000.000. Maar voor andere zaken is import zeker handig, je kunt de import anders net zover doorzetten als je wil. Als ik op een forum zie dat iemand de lichtmasten gaat mappen, denk ik ga je gang, ik houdt het per wegvak op lit=yes.

De route van open data tot OSM.

We kennen de BAG en de import, deze werd vanaf een wfs server met josm plugin omgezet.
Hoe oud is de data van de server? meen dagelijks.
De vraag is, is hier tussen, de omzet met NLextract gebruikt?

Hoe is dat bij BGT, in welke vormen komt dat beschikbaar?
Welke vorm met gebruik NLextract?
Welke vorm zonder gebruik van NLextract?

Zorgt de licentie niet voor problemen? De BGT is beschikbaar onder de CC-BY-licentie, waardoor de data niet zomaar gebruikt mag worden in OSM. Aan de eis voor naamsvermelding van het Kadaster wordt namelijk niet voldaan op de meeste OSM-kaarten.
Bij de BAG was dit anders, die is beschikbaar als public-domain data.

Bedankt voor de opzet Frank!

@ Allroads: De BGT wordt nu wekelijks (in de weekenden) geüpdatet, maar in de toekomst wordt dit dagelijks. Wel is voor de BGT geen WFS server voorzien omdat de bestanden zo enorm groot zijn. Je kan ze dus alleen als WMTS bekijken of als GML download. Binnenkort komt hier ook StuFgeo bij, maar dit is denk ik interessanter voor overheden.

Als er nog wensen zijn voor andere formaten, dan hoor ik het graag. Dan kan ik wellicht een balletje opgooien! We willen namelijk graag vanuit de overheid dat geo-informatie ‘webvriendelijker’ wordt. Wel moet dus rekening gehouden worden met de omvang van de bestanden: een stad als Leiden is qua bestandsformaat in GML al bijna 1 GB (ongeveer 1,3 miljoen objecten).

@ Cavit: goed punt… Ik zal binnen IenM eens navragen wat de gedachte achter deze licentie is. En hoe ‘zichtbaar’ de naamvermelding moet zijn. In principe is het natuurlijk een hele vrije licentie.

De complete BGT importeren zou een beetje zonde zijn van het huidige OSM-werk, maar er zijn denk ik een hoop objecten die een goede aanvulling kunnen zijn. In het IMGEO objectenhandboek is duidelijk visueel aangegeven wat voor soort objecten je in de BGT en het ‘plusmodel’ IMGEO kan verwachten. Ik ben benieuwd naar welke jullie het meest uitkijken!

Bedankt voor het starten van dit draadje en de reacties zover.

Hoe lang hebben bronhouders de tijd om bij te werken? Op de RWS dag dacht ik iets van 1/2 jaar te hebben gehoord. Deze vraag stel ik zodat we een beeld krijgen van de actualiteit van de data.

De meest interessantste delen wat mij betreft lijken de wegdelen. Ook de panden (niet zijnde BAG) zouden er wat mij betreft bij kunnen. Ook de borden kunnen interessant zijn maar zijn zo te zien geen verplichte items en als ze aangeleverd worden dat is de vraag of af te leiden is welk verkeersbord het is.

Het zou leuk zijn als we de BGT data als overay/underlay kunnen bekijken t.o.v. een OSM kaart. Zo kan een ieder voor zijn interessegebied een beeld kan krijgen wat er nog een OMS ontbreekt of aangepast zou moeten worden.

OSM data richting BGT kan natuurlijk ook. Wellicht met Overpass queries specifieke bevragingen doen die voor BGT interessant zijn. Met overpass turbo of varianten op de bekende web kaartjes zoals bv de BTM. Hopelijk kunnen BGT kenners aangeven welke OSM data het meest interessant is om te bekijken.

Ook mijn dank voor het starten van dit draadje, het was een leerzame dag op 19 september in het LEF gebouw in Utrecht.
De eerste bijeenkomst heeft veel stof tot nadenken gebracht.

Op de sheets die voorbij zijn gekomen zijn een aantal links gegeven die ik jullie niet wil onthouden.

http://geoservices.rijkswaterstaat.nl/services-index.html
https://data.overheid.nl/
https://www.pdok.nl/
http://nationaalgeoregister.nl/

http://www.rijkswaterstaat.nl/apps/geoservices/geodata/dmc/nwb-wegen/geogegevens/shapefile/
http://www.rijkswaterstaat.nl/apps/geoservices/geodata/dmc/nwb-vaarwegen/geogegevens/shapefile/
http://www.rijkswaterstaat.nl/apps/geoservices/geodata/dmc/nwb-spoorwegen/geogegevens/shapefile/

http://www.rijkswaterstaat.nl/apps/geoservices/geodata/dmc/weggeg/geogegevens/shapefile/

Wegdelen:
De omtrek belijning, beter kunnen wij het niet intekenen.
Maar de wegdelen zullen hier en daar toch bewerkt moeten worden, op geknipt worden, om de juiste tags er op te kunnen zetten. area:highway=residential secondairy etc. Daarnaast het knippen bij kruispunten, oversteken voetganger/fiets.

Troittoirs en parkeevlakken komen mooi op zijn plaats te liggen, die troittoirs zijn gelijk goed als vlak en later als routeerbaar te gebruiken. De ene gemeente per auto vlak ingetekend de ander als verzamelvlak, laadpalen, gehandicapten vlak moet ter plaatse bekeken worden De borden zijn niet beschikbaar

De term voetpaden, kunnen we niet allemaal overnemen als voetpad, path en track komen ook voor en ook stukken waar je met de auto overheen mag, access ingevuld op de area. Ook bij voetpad knippen om doorstekken te maken voor andere typen van voortbeweging

Parkeervlakken, grote voor mensen van buiten, in de wijk meer residential gebruik, de tagging anders.

Kortom er is toch nog wel wat handwerk nodig.

Dus 1:1 importeren, dat wordt het hem niet. Ben wel blij als we de ligging goed hebben, over kunnen nemen.
Kennis van de omgeving of luchtfoto is nodig, bij het nodige knipwerk.

area:highway
dat wordt in ander landen de laatste tijd steeds meer opgepakt (discussie), en zou met deze import mogelijkheid een behoorlijke zet kunnen krijgen in NL.
http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area
http://forum.openstreetmap.org/viewtopic.php?id=31929
http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway

Van OSM naar BGT.
Of andere overheids bronnen

Na ervaringen met BAG import en de mogelijkheid per geval een opmerking/melding te maken.
Bij BAG kwamen per Gemeente (verschillend) honderden foutjes voor, deze manier van melden was niet werkzaam.

Gedachte:
We werken met JOSM.
Retour naar BGT.
Een tool plugin geschreven voor JOSM, waarbij de geselecteerde node/way, in de BGT laag, met knop naar meldingslaag gekopieerd kan worden, deze meldingslaag geupload, met omschrijving probleem naar een verzameldepot overheid gestuurd. Zichtbaar gemaakt een op kaart, waaruit notes ontstaan voor de BGT ingevende instanties,
daarna wanneer opgelost een terug melding naar die kaart of aan OSM aangever.

Hendrikklaas, ik zeg niet dat we helemaal niet moeten importeren, maar de import van de BGT als geheel is niet het doel van deze thread. Dan zou OSM een duplicaat van de BGT worden en daar schiet uiteindelijk niemand mee op. Sterker nog, dan wordt het alleen maar lastig om OSM te onderhouden.

De BAG, de laatste grote dataset die in Nederland is geïmporteerd, bestaat alleen uit gebouwen, maar ook hier is de import niet zonder slag of stoot gegaan. Bij het importeren moest er rekening worden gehouden met bestaande data, want je wilt zeker niet waardevolle informatie kwijtraken. Verder is er geen updateproces voor de BAG. Updates vinden alleen op verzoek plaats. De BGT is qua omvang veel groter dan de BAG, dus dat wordt een onhoudbare situatie.

Wat het detailniveau betreft waarmee sommige mensen zich bezighhouden: zolang het vrijblijvend is en niet “verplicht”, vind ik het best. Maar dat onderscheid is heel lastig te maken en ook subjectief, want iedereen heeft andere interesses. Stel dat ik bijv. 3D belangrijk vind (wat ook zo is, dus dit is een goed voorbeeld) en ik ga veel tijd en moeite stoppen in het 3D maken van gebouwen (hoogte, dakvorm, steeds meer detail), in hoeverre is het dan “vrijblijvend” (dus des OSMs) en in hoeverre is het “verplicht”? Als alle gebouwen in Nederland van 3D-informatie zijn voorzien, dan “moeten” alle wijzigingen daar ook rekening mee houden. Ik vind dat een lastige keuze.

Bij imports dan leg je op een bepaalde manier ook je eigen wil (want jij wilt die import) op aan de rest van de community. Maar dat gebeurt ook als je veel tijd hebt en handmatig bepaalde wijzigingen systematisch doorvoert. Alleen is dan de drempel vanwege het arbeidsintensieve karakter veel hoger dan bij imports (die ook best arbeidsintensief zijn).

Anyways, ik ben weer lekker aan het uitwijden :wink:

Ander voorbeeld: busroutes! Hierdoor zijn bepaalde wijzigingen aan wegen veel moeilijker, bijv. als er een middengeleider komt, dus een rijbaan in twee richtingen wordt opgedeeld in twee éénrichtingsrijbanen. Ga er maar aanstaan :S

Allroads, een van de redenen om de BGT in PostGIS te laden (wel stukken, niet landelijk vanwege de omvang) is dat je de data lokaal beschikbaar hebt in een formaat dat zich veel beter leent voor verdere bewerkingen. Het is niet moeilijk om vanuit hier OSM-bestanden te genereren. Dat kan ook rechtstreeks vanuit GML, maar dat is bewerkelijker, vanwege de complexiteit van GML zelf.

Cavit, v.w.b. de licentie: Rijkswaterstaat is de grootste bronhouder van de BGT en zij hebben laatst een bijeenkomst gehouden om de samenwerking met OSM op te zoeken. Ik verwacht niet dat de licentie van de BGT een issue zal zijn, maar het is natuurlijk wel iets dat geregeld moet worden.

Jaap-Willem: grote imports worden hier vermeld: http://wiki.openstreetmap.org/wiki/Import/Catalogue. Het is ook de bedoeling om de bron van imports te vermelden bij het uploaden van de changeset. Hiermee is de herkomst te achterhalen en daarmee de attribution, maar het is ondoenlijk om op websites alle rechthebbenden te noemen, want dan houd je geen ruimte meer over voor content. Als je een paar datasets bij elkaar gooit in een systeem is het nog wel te doen, maar niet bij honderden datasets, aangevuld met bijdragen van duizenden individuele gebruikers.

Peewee, het issue met de actualiteit heb je ook met de BAG. Ik weet niet de wettelijke termijnen, maar lees de BAG-thread maar na over hoe sommige gemeenten hiermee omgaan.

V.w.b. het gebruik als overlay: je zou kunnen kijken of je de WMTS-laag van PDOK in JOSM kunt gebruiken. Een groot nadeel is dat je heel ver moet inzoomen om wat te kunnen zien! I.i.g. heeft Jaap-Willem gezien dat PDOK ook Web Mercator (EPSG:3857) en WGS84 (EPSG:4326) ondersteunt bij WMS, maar ik weet niet of dat ook voor WMTS geldt.

Overpass is een interessante optie om data uit OSM te halen. Maar ook bij het terugleveren zit je met licenties, dus moeten we kijken hoe we hier slim mee om kunnen gaan. Ik denk dat dit meer een heikel punt gaat worden dan andersom. Eventueel kan het als een soort bulk-terugmeldvoorziening gebruikt worden, zodat bronhouders OSM alleen gebruiken als inputsignaal voor mutaties, maar de data zelf verder niet gebruiken.

Je snijdt hier een aantal goede zaken aan. Die moeten we zeker voor later erin houden. Ik denk dat we ons eerst met algemenere vragen bezig moeten houden, voordat we de diepte ingaan. Bijv. wegdelen: moeten we die wel als polygon importeren? In Frankrijk zijn ze daarmee begonnen, maar ik weet niet op welke schaal dat gebeurt. Ik ben benieuwd hoe het daar uitpakt.

Hoe ga je zoiets managen? Je krijgt nl. meerdere representaties van hetzelfde object (als lijn en als vlak), net zoals bij de BRT (wegdelen vs hartlijnen). Bij OSM zal er ook sprake zijn van een verschillend aggregatieniveau, vanwege het ontbreken van harde relaties tussen objecten. Ja, je zou een wegdeel en hartlijn bij elkaar in een relationship kunnen gooien, maar dat is niet te onderhouden. In mijn optiek ook niet nodig, omdat je wel een implicieite, geografische relatie hebt.

Ik ben het met je eens dat de ligging al een heel goed begin is. Als je de BGT van een gebied in een database hebt, kun je OSM importeren en dan kijken of er OSM-wegen buiten de BGT-wegdelen liggen. Het kan ook handmatig als je een goede en actuele overlay-laag hebt, maar dat kost veel tijd. Voordeel is wel dat je wijzigingen gelijk kunt doorvoeren, dus uiteindelijk kan dat best beter werken.

Jaap-Willem houdt zich o.a. bezig met terugmeldingen. Gezien de omvang van OSM is dit zeker iets waar wat mee zal moeten gebeuren.

Kan je aangeven waar in osm, ik zie in Frankrijk weinig area:highway.

WMTS http://creativecommons.org/licenses/by/4.0/
toevoeging ?SERVICE=WMTS&REQUEST=getcapabilities

En dat zijn lagen die JOSM niet ondersteund.

Verdraaid, ik heb inderdaad alleen een steekproef gehouden naar WMS’en in PDOK en daarin ook alleen gekeken naar EPSG:4326 ipv 3857. Ik zie wel dat er in de WMTS iets staat over WGS84 en zelfs de Google Projectie (900913), maar dat gaat volgens mij meer over de positionering van de tiles (en 3857 staat er niet tussen…). Ik ga hierover navraag doen om te kijken of deze wens al in beeld is en zo nee, of dit op termijn realiseerbaar is.

Ah ik zie daar dus al genoeg data met eenzelfde licentie staan (CC-BY 4.0). Ik neem aan dat een vermelding op deze pagina plus een ‘source=BGT’ per geïmporteerd object dan ook voldoende is. Ik denk niet dat er iemand binnen de overheid is die hier moeilijk over zal gaan doen.

Binnenkort starten we inderdaad met de ontwikkeling van een BGT terugmeldsysteem aan de slag. Dit systeem zal qua functionaliteit in eerste instantie vergelijkbaar zijn met het terugmeldsysteem van de BRT. In ieder geval dus een stuk laagdrempeliger dan het huidige formulier van de BAG. Het is waarschijnlijk dat met dit systeem ook wordt doorontwikkeld naar de BAG, BRT en wie weet wat voor open data nog meer. In de toekomst zal er waarschijnlijk ook een koppelvlak komen waarmee andere systemen meldingen kunnen inschieten. Dit is voorlopige nog toekomstmuziek, dus pin me er niet op vast. Maar dit is natuurlijk ook een wens die je hoort bij veel professionele BGT gebruikers, dus zeker iets wat we in beeld hebben!

Voor het NWB wil Eric graag een app ontwikkelen (BGT terugmeldsysteem wordt in eerste instantie een website), waar ook meerdere geo-registraties zoals de BGT op aanhaken.

Ik zal binnenkort anders wel een topic openen over dit onderwerp, omdat ik OSM’ers uiteraard als serieuze terugmelders zie en graag ook jullie wensen meeneem in de ontwikkeling.