Basisregistratie Grootschalige Topografie (BGT)

Ik heb me de laatste tijd vanwege tijdgebrek een beetje afzijdig gehouden in de BGT-discussie, maar nu heb ik weer tijd om e.e.a. op te pakken. Zoals ik gisteren al gemeld heb, was ik al bezig om in NLExtract ondersteuning voor de BGT in te bouwen. Wanneer dit gereed is en ik een PostGIS-dump heb gemaakt, wil ik graag iedereen van harte uitnodigen om hiervan gebruik te maken.

Vervolgens ben ik van plan om zelf ergens een server te huren om daar spullen op te hosten. Eén van de dingen waaraan ik denk is BGT aanbieden volgens de OGC-services (WMS/WFS/WMTS) in World Mercator. Naast de ondersteuning van RD in JOSM (dank, Cavit!), is dit de andere manier om dit issue op te lossen. Ik ga het gat opvullen dat PDOK “aan de markt overlaat”.

Naast het ontsluiten van de BGT via OGC, zit ik er ook aan te denken om een downloadservice aan te bieden van de BGT in OSM-formaat. Ik ben nog steeds geen voorstander van grootschalige import, maar ik denk wel dat het beter is om e.e.a. goed op te zetten, i.p.v. dat iedereen het wiel gaat proberen uit te vinden.

Voordat het laatste mogelijk is, moet het volgende gebeuren:

  • Overeenstemming over de tagging van BGT-data in het OSM-model. Heeft iemand zin om dit op te pakken / te leiden?
  • Schrijven van de conversie-/downloadservice. Alhoewel ik de server beschikbaar stel, zoek ik een vrijwilliger voor het schrijven van de software. Ik zit te denken aan een WPS-service via Geoserver. Voor de OGC-services ben ik ook van plan gebruik te maken van Geoserver.
  • Nadenken over mutaties in de BGT.

Wat de planning betreft: ik ga de komende dagen aan de ondersteuning in NLExtract werken. De hosting misschien volgende week, maar ik wil eerst aan de slag met de ondersteuning van de Basisregistratie Kadaster (percelen) in NLExtract.

De server regel (betaal) ik zelf wel. Tijdgebrek is een veel nijpender issue.

Ik heb pas onlangs deze mogelijkheid ontdekt voor BAG en TOP10NL en dat bevalt prima. Als je klaar ben geef dan maar een seintje

Prima plan. Ik vraag me wel af of je dan alles (kan dat?) of slechts een subset van de data bechikbaar moet stellen. Die subset zou dan de set kunnen we zijn waarvan we als community vinden dat die bestaansrecht heeft in OSM. Voor je het weet gaat iemand goedbedoeld allerlei “zooi” in OSM zetten waar de community niet op zit te wachten.

Dan heb je het over het “mappen” van BGT data naar OSM data neem ik aan. Ik denk dat het een goed plan is maar ben eerst nog nieuwsgierig naar wat er allemaal in de BGT data zit en wat de kwaliteit daarvan is. Pas daarna kunnen we wat mij betreft hier op het forum bespreken wat we evt. in OSM opgenomen willen zien. Als daar overeenstemming over is kunnen we de “mapping” regelen. Ik denk dat we daar gezamenlijk wel uitkomen.

Bedankt voor je inzet zover Frank. Ik kan helaas niet voldoende programmeren. Wellicht kan ik wel wat lijstjes maken met verschillende waardes (en aantallen) van de kolommen in de diverse BGT tabellen. Zo krijgen mensen die wat minder handig zijn met databases inzicht in wat er allemaal beschikbaar is en of dat voldoende waardevol is om überhaupt op te nemen in OSM.

Een voorbeeld van de waardes van de kolom plus_type uit de tabel functioneel gebied (uit de nog niet complete BGT data)

“begraafplaats”;1002
“functioneel beheer”;459
“functioneel beheer: hondenuitlaatplaats”;316
“bedrijvigheid”;278
“recreatie: speeltuin”;271
“recreatie”;218
“recreatie: sportterrein”;103
“maatschappelijke en/of publieksvoorziening”;85
“”;69
“recreatie: volkstuin”;44
“bushalte”;39
“benzinestation”;8
“recreatie: park”;8
“recreatie: camping”;6
“recreatie: bungalowpark”;4
“waterbergingsgebied”;3
“carpoolplaats”;1

Ik denk een subset, maar dat volgt vanzelf uit de discussie over de tagging.

Ja, ik heb het over het “mappen” van BGT naar OSM. Hier kun je de BGT-standaarden vinden, waaronder de gegevenscatalogus. Er zijn vast ook wel presentaties te vinden die een algemener beeld geven. Mocht ik die tegenkomen, dan zal ik ze hier melden. Mocht jij of iemand anders ze tegenkomen, dan bij deze het verzoek om ze hier ook te melden.

Ik zou juist de plustopografie en plus-attributen voorlopig buiten beschouwing laten. Deze zijn optioneel, dus wanneer de BGT helemaal gevuld is, hoeven deze gegevens nog lang niet compleet te zijn. Het is bij wijze van spreke zelfs niet gezegd of je overal onderscheid kunt zien tussen bos en gras, omdat alles als “groenvoorziening” is opgenomen.

Hier is een link naar de managementssamenvatting (PDF). Dat lijkt me een uitstekend begin om te lezen. :slight_smile:

Bericht over de voortgang:

De issues zijn ondertussen aangemaakt:

Een paar handige links:

Verder is Jan-Willem van Aalst de afgelopen weken druk bezig geweest met visualisatie van de BGT in OpenTopo. Dit is gebeurd o.b.v. mijn PostGIS dump. Deze bevat alles wat vlak voor de kerst in de BGT zat, behalve de plaatsbepalingspunten.

Als ik nu naar de BGT-vulling in PDOK kijk en dit vergelijk met de beschikbaarheid in een kaartje gevisualiseerd door Jan-Willem van Aalst (o.b.v. dump van 21 dec), lijkt het dat de afgelopen weken best veel extra data is toegevoegd. Dat ziet er prima uit!

Om de BGT/IMGeo discussie hier wat aan te wakkeren heb ik een wiki pagina gemaakt met wat info en ideeen. Ik denk dat het goed is om het beeld van de BGT/IMGeo wat helderder te krijgen alvorens een goede te discussie op te starten. Ik vind het lastige materie en heb ook lang nog niet alles helder. Bij deze het verzoek aan geintesseerden om de wiki te verbeteren. Ik had al een tijd niets meer geen wiki pagina aangepast en was dan ook aangenaam verrast dat het editten tegenwoordig veel makkelijker kan dan voorheen. Je hoeft niet meer al die markup codes te kennen. Een verademing.

NB hij staat nu nog als een subpagina van mijzlef dus als iemand een betere locatie weet… dan mag ie verplaatst worden.

Is het probleem van naamsvermelding BGT al opgelost voor OSM?

Ik neem aan dit slaat op het punt dat Cavit eerder in dit draadje aandroeg

Ik zal Jaap Willem een PM sturen want het zou me niet verbazen dat hij hier niet dagelijks kijkt.

Ja, ik heb nog geen groen licht gezien voor OSM om het te kunnen gebruiken.

Gevolg casus Dankelman en inzichten.

Welk bestand.

Na een gesprek met een Gemeente, waar ik was, terloops over BGT en de voortgang. Nader uitgediept via telefonisch gesprek
Wat ter sprake kwam.

Kwaliteit BGT
Omdat bij de BAG nogal wat fouten waren en ik me af vroeg of we te vroeg met import gestart zijn, want na die tijd is binnen een half jaar, een behoorlijk kwaliteitsslag gemaakt. wat ons minder herstel werk zou hebben opgeleverd.
Nu de vraag, hoe is het met de kwaliteit van BGT gegevens. Antwoord: beter.
Is dit algemeen bekend?

BGT binnen een gebied.
Kan je in de data terug vinden, wie het aangeleverd heeft binnen een gemeentelijk gebied.
Antwoord: dat weet ik niet maar we hebben als gemeente alle data aangeleverd er is geen andere partij.
Met de Provincie Waterschappen Rijkswaterstaat etc. zijn daar afspraken over gemaakt.

Licentie:
Op dit bronbestand eigendom Gemeente, welke licentie rust daar op.
Antwoord; Het is open data, gebruik, wat je gebruiken wil zonder beperkingen.
Maar, nu onder de noemer BGT uitgebracht onder licentie CC 4.0 en attributie (naamsvermelding)
Antwoord het is hetzelfde als met de BAG, aangegeven BAG public domain 1.0.
Dus ik mag van u (Gemeente) deze data zo gebruiken. Antwoord ik zie geen problemen.
Dit verder beken op nationaal georegister site, het verwonderde hem. Gevolg contact kadaster.

Hoe verkrijg ik deze data?
Antwoord: uit BGT, ik zal eens contact opnemen met het kadaster.

Dus een gemeente mag zelf beslissing of ze dit bronbestand ter beschikking steld. Gemakshalve noemt men het BGT bestand, bestand voor BGT. Maar heeft op dat moment nog geen licentie voorwaarden van het kadaster.
Wat misschien ook is gebeurd in casus Dankelman.

Jammer, dat we de BGT wms layer van National Georegister niet mogen gebruiken.

Hier kon je mooi alleen de wegen bgt wegdeel aanzetten en alle wegen op uitlijnen.

Is er al hoop?

De laatste informatie die ik heb is dat Jaap-Willem een toestemmingsdocument in voorbereiding heeft dat OSM de BGT mag gebruiken. Dus er is zeker hoop. Hopelijk kan hij binnenkort hier iets meer over melden.

Ik wil niet stoken, maar doe het toch: wat met ons belastinggeld betaald is mogen we toch in ieder geval ruimhartig raadplegen?

Toch?

Op 16 maart bezocht Melanie Schultz van Haegen, de minister van Infrastructuur en Milieu, het Kadaster. Hier werd een testversie van ‘Verbeter de Kaart’, het laagdrempelige terugmeldsysteem voor de Basisregistratie Grootschalige Topografie (BGT) getoond.

https://bgtweb.pleio.nl/blog/view/42867112/minister-maakt-kennis-met-bgt-terugmeldsysteem-%E2%80%98verbeter-de-kaart%E2%80%99

Het is een soortgelijk systeem als het OSM note systeem, bewust gekozen voor laagdrempeligheid direct op de kaart.
Op dit moment is het meldsysteem in een testfase.
https://verbeterdekaart.kadaster.nl/

Naar aanleiding van de ook door anderen al aangestipte wens voor het eventueel overnemen van de wegdeelvlakken, wilde ik ook van mijn kant uit nog wat input leveren.

Ik ben al circa 3 jaar bezig met de ontwikkeling van een zeer geavanceerde OpenStreetMap renderer voor ArcGIS (`ArcGIS Renderer for OpenStreetMap´ - nog niet publiek beschikbaar!), die custom styles ondersteund op basis van ArcGIS layer files. Wanneer dit klaar is, biedt dit een alternatief voor de nu meest gebruikte osm2pgsql/postgis/mapnik render tool chain.

Daarin heb ik in de laatste versie ook ondersteuning voor de area:highway tagging ingebouwd. De vlakken worden pas vanaf een schaal >= 1:3750 weergegeven, en liggen over de corresponderende weglijnen heen, zodat ze vanaf 1:3750 de lijnen verbergen. Wel zijn de lijnen nog nodig, om de wegnaam-labels weer te geven. Ik laat ze dus gewoon in de weergave zitten, hoewel ze op plekken met area:highway vlakken dus bedekt worden. Ik denk dat dit een acceptabele oplossing is voor het probleem van de “dubbele” weergave (vlak/lijn) van de wegen, en de meest bevredigende oplossing.

Het renderen van area:highway is overigens volledig facultatief (net zoals voor alle render rules), je kunt ze ook weglaten in de style.

In het Duitse forum had ik onder de thread Strassen als Fläche (http://forum.openstreetmap.org/viewtopic.php?id=26317&p=14), al eens een aantal voorbeelden gepost, die ik bij deze ook hier in de post heb opgenomen. Deze voorbeelden zijn van de stad Szczecin in Polen, een van de weinige plekken waar vrij grootschalig al vlakken met area:highway zijn ingevoerd. De bijgaande plaatjes laten de resultaten van de rendering van de area:highway vlakken duidelijk zien. Ik denk dat dit aardig om van te `watertanden´ is… :wink:

Merk een aantal belangrijke details van de rendering op:

  • area:highway vlakken worden correct volgens de layer=x tag gestapeld. Er is dus geen slordige willekeurige weergave van de vlakken, of foutieve versmelting van de vlakken op verschillende layer niveau’s.
  • Heel belangrijk, ook man_made=bridge features worden gerenderd volgens de layer=x tag. Daarmee is er fysieke verticale scheiding tussen fly-overs en de onderliggende wegen. Ik zou er dus voor willen pleiten om bij overname van wegdeelvlakken, ook viaducten correct over te nemen en van de juiste tags te voorzien.
  • De weergave toont voor de wegdeelvlakken een kleur op basis van de surface=x tag. Persoonlijk zie ik weinig tot geen nut van het weergeven van wegdeelvlakken op basis van de area:highway=x classificatie zelf. Immers, de weergave van wegclassificatie vindt veel beter plaats op kleinere schalen, terwijl op grote schaal de surface interessant wordt. Dit betekent wel dat ook een surface=x tag moet worden opgenomen bij elk area:highway=x feature!

Overigens heb ik zelf in dit gebied, en speciaal ook bij het grote viaduct naast de rivier, ook nog veel correcties op de tagging en ligging van lijn- en vlakelementen moeten uitvoeren. Bij deze weergave is het namelijk van cruciaal belang dat de highway=x weglijnen, area:highway=x vlakken en de man_made=bridge features perfect op elkaar aansluiten. Is dat niet het geval, dan vallen er namelijk rare gaten in de weergave, doordat b.v. een man_made=bridge met layer=1 ineens over een area:highway=x vlak met layer=0 valt, dat wel gewoon in het verlengde van dezelfde weg / viaduct ligt! (de er onderdoor gaande kruisende weg moet natuurlijk wel afgedekt worden). Dit komt dan dus doordat of de man_made=bridge feature met layer=1 te ver doorloopt, of doordat het er op liggende area:highway=x vlak met ook layer=1 te snel op houdt / te kort is ingetekend.

Het heeft al met al meerder cycli van editing gekost, om de boel op deze specifieke voorbeeldplek, op orde te krijgen. De terugkoppeling van de render resultaten was daarbij cruciaal, omdat dit snel fouten aantoonde met de layering, die in de OSM editors totaal onzichtbaar zijn!

Mvg,

Marco

ArcGIS Renderer for OpenStreetMap - City of Szczecin, Poland, image1

ArcGIS Renderer for OpenStreetMap - City of Szczecin, Poland, image2

ArcGIS Renderer for OpenStreetMap - City of Szczecin, Poland, image3

Het is wat stil geworden in deze thread…, zijn er desondanks nog verdere plannen of ideeën voor activiteiten op het gebied van de overname van BGT gegevens?

Voor zover ik weet is het nog wachten op toestemming. Tot die tijd kunnen we niet zo veel.

Ondertussen is deze wms niet meer actief.

Krijg een error, error when loading tiles, staat ook niet meer in het Nationaal Georegister.

Dit is jammer voor de toekomst, want je kon de wegdelen apart aan zetten.
En als de BGT toestemming er zou zijn, de layer gebruikt kon worden om wegen uit te lijnen.