het plaatje Deurningen komt uit QGIS. OpenSource en gratis en zeer goed!
1 like
Beste Kasper,
Zou je, in de beste open source traditie, de uitkomst van je puzzel ook hier willen delen? Dan hebben anderen die in de toekomst een vergelijkbaar probleem hebben en op dit draadje stuiten er ook wat aan.
Succes!
2 likes
Hoi Kasper,
Er zijn veel manieren om centroides te berekenen voer een polygoon, zoals:
- gemiddelde xy-coordinaat
- midden van de “bounding box”
- wilekeurig punt dat gegarandeerd in de polygoon ligt
- punt dat het verst ligt van de grens
- etc.
Voor een vergelijkbare vraag heb ik ooit de gemiddelde x- en de gemiddelde y-coordinaat bepaald van alle verblijfsobjecten (adressen) in een BAG-woonplaats. Dat gaf een heel aardig resultaat.
Succes!
Raymond
1 like
Ik heb ook even gekeken bij OpenStreetMap. Wellicht is dat een simpelere route.
https://nominatim.openstreetmap.org/ui/search.html?q=deurningen
Hier lijkt inderdaad het “centrum” van de bebouwde kom goed aangegeven (iig als je het gemeente Dinkelland deel pakt van Deurningen).
Ik zal m’n proces even vastleggen en hier delen.
Ik vrees dat dat je overal wel tegen uitzonderingen gaat aanlopen. Als je Hoorn opzoekt in OSM bijvoorbeeld, komt de locatie helemaal niet in de binnenstad uit, wat “men” als centrum aanduid. Lintdorpen zijn ook een leuke uitdaging, en kleinere dorpen waar bij het CBS de Buurt gelijk is aan de woonplaats zo’n beetje.
En de BRT: Ik heb niet echt naar de dataset gekeken, maar daarbij loop je het risico dat je daar het cartografische plaatsingspunt van de plaatsnaam te pakken hebt (en da’s vrijwel nooit in het centrum maar in een kaal stukje er vlak in de buurt).
Dus het is ook heel erg afhankelijk van waarvoor je dit nodig hebt. Je hebt best kans dat het nog het snelst is en het beste resultaat geeft om handmatig alle woonplaatsen af te lopen 
Je zou eens kunnen navragen bij de ANWB, die plaatst over het algemeen de borden met dingen als “Centrum” er op. Die moeten een idee hebben van welk bord welke richting op moet wijzen lijkt me, dus misschien hebben die iets. Maar ik weet niet of zij hun data willen delen.
1 like
Hoi Kasper,
De plaatsvlakken uit de BRT kunnen gebruik worden voor het selecteren van de plaatsen. Plaatsvlakken van het type “woonkern”, “recreatiekern” of “industriekern” bevat de plaatsen aangeduid met de blauwe kom-borden, waarbij de geometrie de bebouwing omsluit. Het buitengebied is dus niet meegenomen. Informatie over hoe deze plaatsvlakken ingewonnen worden kun je hier vinden: imbrt | Informatiemodel van de Basisregistratie Topografie
Naast de BRT API kun je wellicht ook van de Geopackage gebruik maken: https://service.pdok.nl/kadaster/top10nl/atom/v1_0/top10nl.xml
Het berekenen van het centrum zal je zelf moeten uitvoeren, dat gegeven zit niet in de BRT.
Succes!
2 likes
De geometrieën van wijken en buurten kan je eventueel ook ophalen via de PDOK locatieservice, door de vrije geocodeerservice te gebruiken, zie https://github.com/PDOK/locatieserver/wiki/Zoekvoorbeelden-Locatieserver.
OSM data is via overpass-turbo.eu eenvoudig te bevragen vanuit je browser. Met de volgende query kan je de locaties van de plaatsen op vragen:
[out:json][timeout:25];
(
node["place"="city"]({{bbox}});
node["place"="town"]({{bbox}});
node["place"="village"]({{bbox}});
node["place"="suburb"]({{bbox}});
node["place"="hamlet"]({{bbox}});
);
out body;
>;
out skel qt;
Bovenstaande query is uiteraard afhankelijk van wat je als plaats beschouwt. Zie de OSM wiki over key:place. Zoals @sbjager aangeeft geeft een plaats in OSM niet altijd het centrum aan, maar zo over het algemeen lijkt het wel te kloppen. Het mooie van OSM is ook dat je de data zelf kan aanpassen 
Dank. Inderdaad, zo krijg ik wijken terug:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?q=enschede&fq=type:wijk
Al is dat iets te gedetailleerd, soms zijn er ook delen als Noord, Oost etc. die krijg ik hier niet terug lijkt het.
Bedankt, qua punten lijkt dit nauwkeurig genoeg. Weet je of OSM ook bebouwde kom grenzen heeft?
@daniel.tewinkel Ook bedankt, dit helpt. Ik heb het bestand al ingelezen in QGIS (nu nog een beetje wegwijs worden in dit programma).
1 like
De bebouwde kom grenzen zit als zodanig niet in OSM, maar OSM bevat wel Key:landuse. Hiermee kan je gebieden die bebouwd zijn als polygonen opvragen. Zie hier een voorbeeld query.
Ik denk dat je het verst komt door alle suggesties hier te combineren. Ik zie in de CBS data bijvoorbeeld dat er twee buurten “Binnenstad” zijn voor Hoorn, die zou je kunnen combineren met de bebouwde komgrenzen, en eventueel met de OSM gegevens als je het geautomatiseerd wil opzetten. Maar dan nog loop je tegen een heleboel uitzonderingen aan, en tegen zaken als kleine lintdorpen die niet echt een centrum hebben. Of bijvoorbeeld Lelystad: waar ligt het centrum van Lelystad?
Betekent wel dat je aan het eind van deze klus waarschijnlijk een QGis expert bent geworden 
Overigens wel een erg interessante uitdaging om het te automatiseren (dat zegt de geo-nerd in mij 
)
Ik heb er eindelijk even een dag goed voor kunnen zitten, dus ook op verzoek van @marco_duiker even de uitkomsten tot nu toe.
Mijn doel. Ik wil zoekresultaten organiseren op afstand van een plaats. Kortom ik wil een punt hebben van elke plaats in het “midden” van de bebouwde kom.
Daarnaast wil ik ook simpele reversegeo kunnen doen, iemand deelt positie van telefoon. Sta je in een bebouwde kom, dan wil ik die plaats terughebben. Sta je buiten de een bebouwde kom, dan wil ik de plaats van de dichtstbijzijnde bebouwde kom terugkrijgen.
Ik wil de geojson als uitkomst om te importeren in MongoDB.
Dank voor de QGIS tip, fijn en visueel programma. En eigenlijk alle problemen, vragen die ik heb zijn al ooit eens gesteld en dus te Googlen (en dan kom ik eigenlijk standaard uit bij https://gis.stackexchange.com/).
Ik gebruik de top10 geopackage van het BRT met daarin de bebouwde kommen.
top10nl_Plaats.gpkg
Even een overzicht van de stappen die ik heb genomen.
Punten in midden van bebouwde kom.
1. Filteren (right click layer):
In de layers “plaats_vlak” en “plaatsmultivlak” filteren op woonkern en recreatiekern.
DMV: “TYPEGEBIED” = “woonkern” OR “TYPEGEBIED” = “recreatiekern”
2. Mergen en conversie naar EPSG:4326
De BRT kaart is in EPSG:28992. LAT/LON gebruikt EPSG 4326
Je kan gelijk layers mergen en converteren naar een ander coordinaat systeem.
- Vector > Data Management Tools > Merge Vector layers…
- Set destination CRS naar de default EPSG:4326.
- Save as a shape file.
3. Velden opschonen
Ik kwam er bij export achter dat velden met hele getallen in 1 keer decimalen kregen.
Door column type aan te passen kon ik dat oplossen (change type of a column).
Processing > Toolbox > QGIS geoalgorithms > Vector table tools > Refactor fields
Hier komt dan een nieuwe laag van terug, waarmee ik verder werk.
4. Centroid layer maken
Dit was erg eenvouding.
Vector > Geometry Tools > Centroids
Ik heb ook een 2e manier gevonden, door velden lat/lon te calculeren. _
> Field calculator, create new field, decimal number: precision 6
_ 1. lon: y(centroid($geometry))
_ 2. lat: x(centroid($geometry))_
Uiteindelijk voor de eerste optie gegaan, omdat ik geojson nodig heb, kortom ik ga de centroid layer exporteren als geojson en dan heb ik gelijk het point type te pakken.
5. Opslaan
Export > Save Features As…
- Velden selecteren die ik wil behouden.
- decimalen achter komma op 6 zetten (15 is te precies, 6 is voldoende).
Polygons van bebouwde kommen (Voor simpele reversegeo)
Polygonen hoeven niet heel precies te zijn, kortom wat opschoonwerk om data te besparen.
1. Simplify
Op basis van de refactored layer (na punt 3) ga ik verder.
Via simplify data gereduceerd how to simplify geometries.
Visueel gekeken naar het effect. Uiteindelijk Area als methode gebruikt en tolerance of 0,001.
2. Drop z/m
Na inspectie van een file export lijkt het z-coordinaat altijd 0, kortom die data kan weg. Via Drop z/m functie.
QGIS 3 tool is called Drop m/z values. It’s in the Processing Toolbox, under Vector Geometry.
BAG woonplaatsnaam als field in centroid file
Een aantal “bebouwde kommen” vallen onder één woonplaats in de bag. Die wilde ik ook graag in de set hebben. Om even bij mij in de regio te blijven (Enschede). Zowel Lonneker en Usselo zijn dorpen die in de bag als woonplaats Enschede zijn. Ze zijn ook niet apart als woonplaats te vinden in het georegister: https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?fq=type:woonplaats&fl=*&q=lonneker&rows=10
Via geoparaat heb ik de nieuwste BAG als geopackage download. Hierin zit de woonplaats layer.
Ik kijk welke centroids in de polygon van de woonplaats liggen, dan voeg ik dat woonplaats veld toe aan de centroid.
Data management tools > Join attributes by location.
- Input laag: centroids
- Join laag: bag
- within selecteren.
- Join type: Take attributes of the feature with largest overlap only…
Ik moest de BAG laag nog wel even fixen qua geometry, anders werkte dat niet.
Via “fix geometries”.
Conclusie
Goed dit ging dus redelijk makkelijk, heb er 1,5 dag aanbesteed.
Ik heb nu 2 geojson files polygonen is ongeveer 2.5mb en de centroids iets van 600kb.
Eén vraag die ik nog heb.
Is het gebruikelijk om zowel de centroids als de polygonen in 1 file te zetten? GeoJSON heeft iets als een GeometryCollection. Dan kan ik daar zowel de centroid in zetten als de multipolygon.
Geen idee of dit standaard is en in QGIS kwam ik hier ook niet helemaal uit (merge vector layers gaf de fout: All layers must have same geometry type! Encountered a Polygon layer when expecting a Point layer. ).
Wat zijn best practices in dit opzicht?
1 like
Voor de geojson is het geen enkel probleem, ik doe het zelf ook altijd. Openlayers heeft er geen enkel probleem mee als je dat doet, bijvoorbeeld. Maar veel applicaties kunnen (willen?) daar niet mee omgaan, en willen expliciet maar 1 type geometrie in een table of bestand. Persoonlijk vind ik dat nogal irritant, want het beperkt me in mijn datamodellering.
Ik weet dat QGis het wel kan inlezen als je zoiets doet, maar dan maakt ie er zelf twee legenda items van. Of je het kunt exprteren weet ik eigenlijk niet zeker. Maar omdat je bestanden niet zo groot zijn, zou je het als eenmalige actie met een tekst editor bij elkaar kunnen zetten. Wat alleen werkt als het niet heel frequent word bijgewerkt.
1 like
Dank voor je uitvoerige beschrijving!! Daar help je vast in de toekomst weer anderen mee die rond-googelen naar oplossingen. En mooi dat het gelukt is natuurlijk.
Ik vraag me nog af waarom je naar epsg:4326 hebt geconverteerd. Als je analyses doet is het aan te raden om geprojecteerde coordinaten te gebruiken zoals epsg:28992. Soms maakt het niet uit, maar vaak wel. Vooral als je iets met afstanden gaat berekenen.
Over het mengen van geometrie-typen, dat is inderdaad niet gebruikelijk en veel bestandsformaten staan het niet toe. Ook kan software (zoals QGIS) er niet altijd mee omgaan, omdat veel algoritmen een bepaald data type als input nodig hebben (bijvoorbeeld “lines to polygons”) en punten, lijnen en polygonen heel verschillende stijl- en label-opties hebben.
1 like
Ik ga de data in mongoDB gebruiken en die heeft epsg:4326 als default.
(Eigenlijk kwam ik er tijdens dit projectje pas achter dat er verschillende projectie systemen zijn).
Nog even een aanvulling. Ik had wat issues met de bebouwde kom layer, waar mongoDB geen index van wilde maken. Uiteindelijk lag dat aan self-intersecting lines, die waren op te lossen door fix geometries te doen (volgens mij kun je dat het beste doen naar elke bewerkingsstap lijkt het).
Ik kwam mapshaper als tool tegen. Die laat dit soort problemen mooi visueel zien:
1 like
Dit topic is 180 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.