Ik zie dat in de Top10NL de inrichtingselement_punten van het type plaatsnaambord nog niet allemaal zijn ingewonnen. Wel biedt de Top10NL de polygonen van woonplaatsgrenzen.
Is het nu zo dat waar zo’n polygoon een verharde weg snijdt, daar eigenlijk een plaatsnaambord verwacht mag worden?
Groeten,
JW
Hoi Jan-Willem,
In de catalogus wordt het gebruik van (witte en blauwe) plaatsnaamborden genoemd bij objecten van de objectklasse ‘Plaats’ waarbij attribuut typeGebied = ‘woonkern’ of ‘industriekern’ of ‘recreatiekern’ en/of attribuut bebouwdeKom = ‘ja’.
Als je de vlakken hiervan samenvoegd (evt rekening houdend met verschillende namen), dan kun je m.i. verwachten dat op de rand van deze samengevoegde polygonen er plaatsnaamborden staan.
Groet, Maarten.
Een tijdje geleden was de woonplaatsindeling een opdeling van het volledige grondgebied van een gemeente. Ik neem aan dat dit niet veranderd is. Een woonplaats is iets anders dan de bebouwde kom welke door plaatsnaamborden gemarkeerd worden.
Zo woon ik in de woonplaats Wijk bij Duurstede maar wel buiten de bebouwde kom.
Klopt. De begrenzing van woonplaatsen is beschikbaar in de BAG. De begrenzing van de bebouwde kommen is beschikbaar in de BRT/Top10NL. Maar ik ben nog geen bestand tegengekomen met de exacte punten van alle bebouwde kom borden (wat ik plaasnaamborden noem).
De Bebouwde kom borden (RVVcode H1 en H2) zitten in de NDW data bebording:
Verkeersborden | Nationaal Dataportaal Wegverkeer.
De dataset is niet 100% accuraat.
In Nederland kan de bebouwde kom per regeling verschillend zijn.
Bron: Bebouwde kom - Wikipedia
Ik ben op zoek naar de verkeerskundige bebouwde kom. Dus het gebied dat wordt ontsloten door de bebouwde kom verkeersborden (RVV code H1, zie Reglement verkeersregels en verkeerstekens 1990).
Het Kadaster heeft in de BRT in de tabel ‘plaats’ een kolom bebouwde kom ‘ja’. Hierin wordt beoogd de verkeerskundige bebouwde kom te ontsluiten. Deze heeft volgens het kadaster de volgende definitie:
Bebouwde kommen worden omsloten door blauwe plaatsnaam borden.
Kadaster: brt: bebouwde kom
De H1 borden zitten as good as it gets ook in de NDW Data. De borden zijn gekoppeld aan wegvakken uit het NWB. In onderstaande is op deze data gerouteerd met het kortste pad algoritme om te kijken welke gebieden afgesloten bebouwde kom zones zijn.
In onderstaande analyse zijn alle alle wegen die niet bereikbaar zijn zonder een H1 bord tegen te komen groene lijnen. Het wegvak waar het H1 aan gekoppeld is, is blauw. De BRT bebouwde kom gebieden zijn de groene polygonen. Dit is het dorp Hulsel, in Brabant. Een gesloten zone.
Op deze manier spiegel ik de 2 ‘gebieden’. Ik ga contact zoeken met het Kadaster om te vragen hoe ze hun dataset ‘Bebouwde kom’ maken/onderhouden.
De analyse levert plekken op waar de bebording potentieel ontbreekt, zoals op deze plek:
Op deze plek staat geen H1 bord:
De Kadaster benadering suggereert dat bebouwde kommen (volgens de wegenverkeerswet) sluitende polygonen zijn. Dat gaat voorbij aan snelwegkruisingen, waarbij de secundaire weg onderdeel vd bebouwde kom is, terwijl de snelweg die wordt gekruisd absoluut niet tot de BBK hoort.
Nog sterker: datzelfde is op sommige (maar lange niet alle) invalswegen, ook het geval.
Bijv. de stadsautowegen S112 in A’dam en N281 in Heerlen.
Het Kadaster-attribuut “bebouwde kom” bij objecttype “plaats” zou ik formeel dan ook interpreteren als “deze plaats kent een aanduiding heeft bebouwde kom/maakt onderdeel uit van bebouwde kom”, maar niet als "de polygoon van deze plaats is de bebouwde kom.
Daadwerkelijke effect op een analyse zal natuurlijk afhangen van je use case:
Terechte punten.
Het Kadaster heeft geen bebouwde kom voor Amsterdam. Geen groene polygoon
In Heerlen is die er wel, maar deN281 is daar niet uitgesloten
Het Kadaster benadert de bebouwde kom maar is niet sluitend.
Vanuit het Kadaster kan ik aangeven dat de manier waarop de objectklasse Plaats wordt bijgehouden beschreven is in de Catalogus: imbrt | Informatiemodel van de Basisregistratie Topografie
De objectklasse Plaats in de BRT bevat (onder andere) de topografische bebouwde kommen, welke anders zijn dan de bebouwde kom volgens de Wegenverkeerswet. Voor deze topografische bebouwde kommen maken we o.a. gebruik van de plaatsnaamborden op de toegangswegen, die dan weer geplaatst zijn volgens de Wegenverkeerswet. Het heeft dus zeker met elkaar te maken.
De bebouwde kom van Amsterdam is wel degelijk aanwezig als Plaats:
@daniel.tewinkel
Dat zou kunnen Ik heb de volgende versie gebruikt. Daarin zie ik geen multi polygonen als ik qgis gebruik
top10nl-gml-nl-nohist.zip (https://service.pdok.nl/brt/topnl/atom/downloads/top10nl-gml-nl-nohist.zip) 2.56 Gb 05-06-2023
https://service.pdok.nl/brt/topnl/atom/top10nl.xml
En dan de file top10nl_plaats.gml
Interessant, ook met het oog op de aankomende BRT.Next 
Ik zit met de geopackage van 2023 voor mijn neus in QGis.
Zie daarin idd zowel plaats_vlak als plaats_multivlak.
Dat is op zich al verwarrend (waarom een vlak niet beschouwen als een multivlak met multipliciteit=1 ?)
Nóg verwarrender is dat er plaatsen (o.a… Amsterdam, Den Haag, Dordrecht, en delen van Almere) zijn die zowel door plaats_vlak als plaats_multivlak bedekt worden. Plaats_vlak meestal voor wijken en buurten (die zo te zien de aanduiding bebouwdekom=nee hebben), en Plaats_multivlak voor de gehele plaats (die meestal aanduiding bebouwdekom=ja hebben)
In Amsterdam-Noord is de puzzel het grootst:
Zal wel komen omdat A’dam-Noord het enige A’damse stadsdeel is dat een multi-polygon is (ja, een heel fliebertje ten westen van de Coentunnel!).
Volgens de gebruikte Geopackage-standaarden bevat een tabel in een Geopackage altijd maar één geometrietype. Aangezien een vlak een ander geometrietype is dan een multi-vlak, zit de informatie in twee tabellen.
De attribuutwaarde bebouwdeKom = “ja” is alleen mogelijk bij plaatsen met typeGebied = “woonkern”, “industrikern” of “recreatiekern”. Bij andere typen is de attribuutwaarde bebouwdeKom altijd “nee”, omdat deze gebeiden geen woonplaats omvatten, maar er sub-onderdeel ervan zijn.
Definitie attibuut bebouwdeKom = “Aanduiding of het gebied de bebouwde kom van een plaats omvat.”
Hallo @Daniel,
1 tabel per geometrytype is i.d.d. GPKG-standaard.
(30 jaar geleden niet gedacht dat dat anno 2023 nog nodig zou zijn, maar het zij zo )
Maar of een (enkel-)vlak nou wezenlijk anders is dan een multi-vlak zie ik nog niet. Met name omdat in deze context (utlevering BRT) ik niet kan bedenken wat het voor voordeel heeft vlakken en multi-vlakken uit elkaar te trekken, en ik (o.a. in deze use-case) wel nadelen zie.
Omdat er hoe dan ook multi-vlakken in zitten moet de client-software sowieso met multi-vlakken overweg kunnen, dus dat kan de reden niet zijn?
Wordt vervolgd!
Nu ben ik het even kwijt. Op ‘imbrt | Informatiemodel van de Basisregistratie Topografie’ lees ik
“en de status van de plaats als bebouwde kom voor de Wegenverkeerswet en als woonplaats in de Basisregistratie Adressen en Gebouwen (BAG).”
Daaruit maak ik op dat er een status van ‘verkeerskundige bebouwde kom’ in de BRT zou zitten. Dat sluit ook aan bij:
Alle aaneengesloten bebouwing inclusief erven. Bebouwing buiten een bebouwingskern die alleen bereikbaar is vanuit de bebouwde kom en waar niet met plaatsnaamborden is aangegeven dat de bebouwing buiten de bebouwde kom ligt, alsmede bedrijventerreinen aan de rand van een plaats vallen ook binnen het vlak.
Autosnelwegen zoals de A10 vallen dan buiten de bebouwde kom, zo lees ik bovenstaande passage. Lees ik het goed?
Het is heel moeilijk om de bebouwde kom polygoon uit data te destilleren. Helemaal als er op straat bebording soms ontbreekt waardoor er geen zone is. Ik lees de ambitie van het kadaster om in de documentatie om dit te doen. Dat is een struggle waar ik het kadaster mee zien worstelen
Off-topic natuurlijk, maar ik hoor/lees wel vaker dat dit een soort ouderwetse beperking in een bestandsformaat zou zijn. Daar ben ik het niet mee eens, het helpt namelijk ook data te structureren waardoor deze gemakkelijker te gebruiken is. En een gpkg is een database, waarin het gebruikelijk is om data-typen te scheiden. Je kunt ook geen integers en floats in dezelfde kolom stoppen.
Het onderscheid tussen multipolygon en polygon begrijp ik trouwens niet zo goed, dat zou naar mijn mening altijd multipolygon moeten zijn (waarin je namelijk ook een single polygon kunt opslaan).
In de BRT worden topografische bebouwde kommen getekend. Doordat het een topografisch element is, moet de begrenzing ervan zichtbaar zijn in het terrein. Ook geven we in de documentatie aan wat er tot deze topografische bebouwde kom behoort. Snelwegen worden daarbij niet genoemd, dus ik snap de verwarring.
In de documentatie staat dat alleen voor door de topografische bebouwde kom omsloten landbouwgebied een uitzondering gemaakt wordt: dat is geen onderdeel van het topografische bebouwde kom vlak. Snelwegen die de kom doorkruisen hierdoor dus wel.
In ons bijhoudingsproces komen we inderdaad plekken tegen waar geen bebouwde kom bord staat, waar we het wel verwachten. Dat maakt het afbakenen van de topografische bebouwde kom soms lastig. Omdat het niet het enige topografische element is waarop de topografische bebouwde kom gebaseerd is, is het niet onoverkomelijk.
Wederom dank voor de toelichting; ik begin het te begrijpen.
Wel zou voor mij de relatie tussen die topografische bebouwde kom en het attribuut bebouwde kom nog wat eenduidiger mogen worden omgeschreven.
In de definitie staat nu:
“Aanduiding of het gebied de bebouwde kom van een plaats omvat”. is dat “omvat” wat cryptisch. Dat klinkt als een soort geometrische “completely contains”-relatie. Het bijbehorende domein heet “PL_isBebouwdeKom”, waarin dat “is” doet vermoeden dat de (topografische) geometrie 1:1 samenvalt met de bebouwde kom (volgens wegenverkeerswet).
Bedankt voor alle informatie. Begrijp ik het goed? / Is dit de juiste manier om te bepalen of een adres uit de BAG binnen de bebouwde kom ligt?
geospatial join tussen de BAG x,y coördinaten en polygonen uit de laag plaats (alleen de polygonen met het typeGebied ‘woonkern’, ‘industriekern’, ‘recreatiekern’ want de polygonen van de andere typen gebieden overlappen én hebben default bebouwdeKom nee)
de kaartlaag plaats is niet landsdekkend => als een adres (BAG x,y) niet binnen de kaartlaag plaats valt dan betekent dit ook buiten de bebouwde kom.
Dan kom ik op deze aantallen adressen voor heel Nederland:
typeGebied bebouwdeKom Aantal adressen
0 industriekern ja 15.181
1 industriekern nee 7.278
2 recreatiekern ja 5.136
3 recreatiekern nee 3.014
4 woonkern ja 6.329.027
5 geen match nee? 1.504.373
Ter infomatie, bijvoorbeeld von Flotowlaan 48 Eindhoven, BAG nummeraanduiding_id 0772200001032033 geeft in de join met de hele kaartlaag plaats 4 matches:
isBAGwoonplaats bebouwdeKom typeGebied naamOfficieel naamNL
9676850 ja ja woonkern Eindhoven Eindhoven
9676850 nee nee wijk None Oud-Gestel
9676850 nee nee stadsdeel None Gestel
9676850 nee nee buurt None Genderdal
