Er lijkt iets fout gegaan te zijn bij de maandelijkse BAG release?
Als je op https://data.nlextract.nl/bag/csv/ kijkt is bag-adressen-full-laatst.csv.zip slechts 184 bytes en bag-adressen-laatst.csv.zip maar 174 bytes in plaats van respectievelijk 334MB en 245MB.
Mijn automatische updater is daar jammer genoeg op kapot gegaan waardoor mijn BAG database nu leeg is en mijn gebruikers problemen ervaren. Ik ga wat betere checks inbouwen :), maar aan de kant van NLExtract hoort dit ook niet te kunnen gebeuren lijkt me?
Beste allemaal, ik ben op zoek naar een overzicht van alle postcodes (4cijfers) met hun grenzen, zodat ik deze op een kaart kan tonen. Het liefst in SQL. Hebben jullie een idee of deze dataset bestaat, en/of deze te maken valt via al het werk wat NLExctract ons aanbied?
@django23 grappig, we zijn net aan het kijken om die in NLExtract te integreren i.s.m. maker/aanbieder @raymondnijssen van TerGlobo, zie ook http://terglobo.nl/postcodekaart.html
Succes met het integreren in ieder geval!
Met "PostGIS" en "Voronoi" kan veel, zie ook bijv: https://longair.net/blog/2017/07/10/approximate-postcode-boundaries/
@justb4 bedankt voor je antwoord. Ik zou graag gebruik willen maken van "Wegen wegvakken" via PDOK, waarbij ik het in een PostGIS database opsla met projectie EPSG:3857. Als er een nieuwe versie wordt gepubliceerd zou ik het liefste deze zonder handmatig werk willen ophalen. Ik heb gezien dat er via ATOM, WFS en WMS gebruikt gemaakt kan worden, ik ben hier nog redelijk onbekend mee, dus ben benieuwd of jij weet welke source het meest geschikt is.
Inmiddels ook wat wijzer geworden. Ik voer nu dit commando uit en dat lijkt te werken (de count werkt alleen niet), weet jij of dit een geschikte oplossing is?
ogr2ogr -lco GEOMETRY_NAME=geom -overwrite -f "PostgreSQL" -a_srs EPSG:3857 PG:"dbname=gisdb user=[USER] password=[PASSWORD] host=localhost" -nln public.gistable "WFS:https://geodata.nationaalgeoregister.nl/nwbwegen/wfs?&service=WFS&version=2.0.0&request=GetFeature&typeNames=nwbwegen:wegvakken&count=10&startIndex=0"
Inmiddels ook wat wijzer geworden. Ik voer nu dit commando uit en dat lijkt te werken (de count werkt alleen niet), weet jij of dit een geschikte oplossing is?
ogr2ogr -lco GEOMETRY_NAME=geom -overwrite -f "PostgreSQL" -a_srs EPSG:3857 PG:"dbname=gisdb user=[USER] password=[PASSWORD] host=localhost" -nln public.gistable "WFS:https://geodata.nationaalgeoregister.nl/nwbwegen/wfs?&service=WFS&version=2.0.0&request=GetFeature&typeNames=nwbwegen:wegvakken&count=10&startIndex=0"
via WMS krijg je alleen plaatjes en via WFS zit beperking aantal objecten dat je terugkrijgt. Via ATOM is meest logisch, daar zit ook metadata in die versie/datum aangeeft. Als je de http://geodata.nationaalgeoregister.nl/nwbwegen/extract/nwbwegen.zip file uit de Atom download en uitpakt moet je via ogr2ogr het Shapefile bestand
nwb-wegen/geogegevens/shapefile/nederland_totaal/Wegvakken/Wegvakken.shp. COmmando wordt dan iets als: ogr2ogr -lco GEOMETRY_NAME=geom -overwrite -f "PostgreSQL" -s_srs EPSG:28992 -t_srs EPSG:3857 PG:"dbname=gisdb user=[USER] password=[PASSWORD] host=localhost" Wegvakken.shp -nln public.gistable om ook de geo-transformatie te doen.
Hallo! Ik heb een vraag over de data die ik zie in de CSV download op: https://data.nlextract.nl/bag/csv/bag-adressen-laatst.csv.zip.
Het gaat hierbij om de precieze schrijfwijze van de gemeenten. Een voorbeeld:
Hierin wordt gebruikgemaakt van schrijfwijze Bergen (NH.) met punt achter NH. Echter als ik de BAG viewer van het kadaster raadpleeg, zie ik een andere schrijfwijze: Bergen (NH) zonder punt achter NH. Dit kun je zien onder het kopje 'Bronhouder' bij: https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=bergen&resultOffset=0&objectId=3047&geometry.x=108059.332&geometry.y=519863.726&zoomlevel=2&detailsObjectId=3047
Kunnen jullie hier licht op schijnen? Als het goed is zou deze data toch uit dezelfde bron putten en dus een verschil in schrijfwijze niet mogelijk moeten zijn?
Achterliggend probleem hierbij is dat ik gebruikmaak van de CSV file voor het herkennen van Nederlandse gemeentenamen. Een partij waarmee ik samenwerk gebruikt ook de BAG data, maar een andere bron (dan die CSV klaarblijkelijk). Nu krijg ik van hen gemeentenamen die niet matchen met mijn systeem. Bergen (NH.) is hier een voorbeeld van. Een ander voorbeeld is: Hengelo (O) vs. Hengelo
@basvdheijden Denk dat je deze vraag beste kunt stellen op https://geoforum.nl/c/datasets/bag , daar zitten ook de API ontwikkelaars. Strict genomen gaat BAG niet over gemeente(namen), maar t/m Woonplaats en meen ik alleen koppeling naar gemeentecode. NLExtract doet deze verrijking met gemeente+provincie op basis CBS gegevens.
Ik heb de vraag ook daar gesteld.
Hi, ik ben op zoek naar een conversie tabel van gebruikelijke naar officiële plaatsnamen. Ik weet uit mijn hoofd alleen Den Haag en Den Bosch en kan verder niet zo snel een lijst vinden. Op https://github.com/PDOK/locatieserver/wiki/API-Locatieserver zie ik ook alleen deze twee. Zijn dit de enigen? Zit deze informatie in BAG of een andere dataset? (Had dit hier gepost nlextract/NLExtract#270 maar @fsteggink verwees mij naar de mailinglijst of hier. Dacht ik post het hier want het hoeft niet direct opgenomen worden in de Extract als het alleen om deze twee gaat wmbt).
Hee @tino jij hier :D! Ik heb daar toevallig voor waarismijnstemlokaal.nl ook naar gekeken, alleen dan enkel naar gemeentenamen. Naast Den Haag en Den Bosch kwam ik nog op de volgende 3 Friese gemeentenamen die een alternatieve spelling hebben:
De Friese Meren / De Fryske Marren
Noordoost-Friesland / Noardeast-Fryslân
Zuidwest-Friesland / Súdwest-Fryslân
Wellicht zijn er dus meer Friese plaatsen die een alternatieve spelling hebben.
He beste mensen,
Ik ben bezig met het scripten van een bgt extract. Ik gebruik NLExtract en het werkt heel goed, waarvoor hulde. Ik loop alleen vast op een foutmelding:
2019-09-13 14:51:44,792 fileinput INFO Pop file record: {'file_path': './todo/bgt_148.zip', 'name': u'bgt_pand.gml'}
2019-09-13 14:51:51,877 subfeaturehandler INFO In SubFeatureHandler.invoke
2019-09-13 14:51:51,879 subfeaturehandler INFO In SubFeatureHandler.invoke
2019-09-13 14:53:51,806 component INFO ZipFileInput invokes=33 time(total, min, max, avg) = 0.032 0.001 0.002 0.001
2019-09-13 14:53:51,808 component INFO ZipFileExtractor invokes=33 time(total, min, max, avg) = 59.312 0.004 9.082 1.797
2019-09-13 14:53:51,808 subfeaturehandler INFO Exit: SubFeatureHandler
2019-09-13 14:53:51,808 component INFO SubFeatureHandler invokes=33 time(total, min, max, avg) = 5.280 0.001 5.212 0.160
2019-09-13 14:53:51,809 subfeaturehandler INFO Exit: SubFeatureHandler
2019-09-13 14:53:51,809 component INFO SubFeatureHandler invokes=33 time(total, min, max, avg) = 0.039 0.001 0.003 0.001
2019-09-13 14:53:51,809 gfspreparationfilter INFO Exit: GFS preparation filter
2019-09-13 14:53:51,810 component INFO GfsPreparationFilter invokes=32 time(total, min, max, avg) = 94.830 0.090 22.033 2.963
2019-09-13 14:53:51,810 component INFO Ogr2OgrExecOutput invokes=32 time(total, min, max, avg) = 141.180 0.121 31.823 4.412
Traceback (most recent call last):
File "../../externals/stetl/stetl/main.py", line 147, in <module>
main()
File "../../externals/stetl/stetl/main.py", line 138, in main
etl.run()
File "/mnt/d/repo/NLExtract/externals/stetl/stetl/etl.py", line 159, in run
chain.run()
File "/mnt/d/repo/NLExtract/externals/stetl/stetl/chain.py", line 174, in run
packet = self.first_comp.process(packet)
File "/mnt/d/repo/NLExtract/externals/stetl/stetl/component.py", line 218, in process
packet = self.next.process(packet)
File "/mnt/d/repo/NLExtract/externals/stetl/stetl/component.py", line 218, in process
packet = self.next.process(packet)
File "/mnt/d/repo/NLExtract/externals/stetl/stetl/component.py", line 218, in process
packet = self.next.process(packet)
File "/mnt/d/repo/NLExtract/externals/stetl/stetl/component.py", line 204, in process
packet = self.invoke(packet)
File "/mnt/d/repo/NLExtract/bgt/etl/stetlbgt/subfeaturehandler.py", line 146, in invoke
xf.flush()
File "src/lxml/serializer.pxi", line 925, in lxml.etree.xmlfile.__exit__
File "src/lxml/serializer.pxi", line 1263, in lxml.etree._IncrementalFileWriter._close
File "src/lxml/serializer.pxi", line 1269, in lxml.etree._IncrementalFileWriter._handle_error
File "src/lxml/serializer.pxi", line 199, in lxml.etree._raiseSerialisationError
lxml.etree.SerialisationError: unknown error -2029986190Zoals je kunt zien is het een hele duidelijke unknown error uit een onderliggende library die gebruikt word om XML uit te lezen. Ik denk dat de XML een syntax foutje of iets dergelijk bevat. Weet iemand hoe ik dit kan debuggen/ oplossen?
@tino @siccovansas @justb4 @basvdheijden Op 1 juli heb ik een presentatie gegeven bij de GI-raad voor de Rijksoverheid waar de Nederlandse OSM-community en Nederlandse spellingcontrole tegenaan lopen bij aardrijkskundige namen. Was interessant om te zien dat exact dezelfde problemen ook naar voren werden gebracht door Kadaster, Nederlandse gemeenten, veiligheidsregios, etc. (Presentatie kan ik doorsturen aan wie dat wil) Er is een systeem in de maak dat naast 1 officiële naam ook met een alternatieve naam om kan gaan, maar dat gaat nog wel even duren. Dus een hardcoded lijst met vertalingen en alternatieven voor NLExtract is zeker op zijn plaats. Waar in de repo kan ik de huidige vertalingen en alternatieven vinden?
Hi allemaal, voor een mobiliteitsvraagstuk ben ik op zoek naar de locaties/coordinaten van de op- en afritten van het Nederlandse snelwegennetwerk. Heeft iemand tips/tricks waar ik deze gegevens kan vinden?
Normaal gesproken via Rijkswaterstaat het NWB bestand of DTB, maar waarschijnlijk gemakkelijkst via OpenStreetMap: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_link dan via Overpass API de juiste queries uitvoeren, maar zal m.i. klein projectje zijn...
Ik zou graag willen dat de CSV-bestanden en PostGIS dump van de BAG verrijkt worden met het wijk en buurt id. Zie deze issue nlextract/NLExtract#64. @justb4 wees me er terecht op dat er aanvullende informatie nodig is, bijvoorbeeld ten aanzien van de bron en de datamodellering. Ik wil het graag oppakken, maar weet niet zo goed hoe ik het aan moet pakken. Kan iemand me op weg helpen? Of is er iemand die het samen met me wil doen?
@PanderMusubi Bedoel je iets wat vergelijkbaar is met http://www.histopo.nl of https://www.geonames.org ?
Volgens mijn gegevens wordt BRK-DKK (oa Kadastrale Percelen) v3 na 30 sept 2019 niet meer geactualiseerd ten faveure van v4 (lees alles hierover op geoforum.nl). Moeten we dus iets mee heb daarom issue #272 geopend met snelle analyse en vragen. Als je ideeën/opmerkingen/antwoorden hebt graag daar in issue commentaren plaatsen.
@here Is er iemand van op de hoogte dat https://data.nlextract.nl/bag/csv/bag-adressen-full-laatst.csv.zip een lege file is? Of weet iemand waar ik dit kan melden zodanig dat het opgelost wordt?
Probleem is bekend, er wordt gewerkt aan oplossing: https://groups.google.com/forum/?hl=en#!topic/nlextract/NMx47b2wLx4
@spreeker Je kunt hiervoor beter terecht op het OSM NL forum: https://forum.openstreetmap.org/viewforum.php?id=12. De andere kant uit (basisregistraties "bijwerken") moet door middel van terugmeldingen. Voor de BAG gaat dit via de BAG-viewer: https://bagviewer.kadaster.nl/lvbag/bag-viewer/#?geometry.x=160000&geometry.y=455000&zoomlevel=0 en voor de BGT en BRT gaat dit via Verbeter de kaart: https://verbeterdekaart.kadaster.nl/#?geometry.x=160000&geometry.y=455000&zoomlevel=3
@marieanneb_gitlab Je kunt ook hiervoor de TOP10NL dump (https://data.nlextract.nl/brt/postgis/top10nl-latest.backup) gebruiken en dan wegdeel.geometrie_hartlijn gebruiken. Het attribuut fysiekvoorkomen geeft mede aan of het betreffende wegdeel op een op- of afrit ligt en typeweg geeft het wegtype aan. In beide gevallen moet je LIKE gebruiken: fysiekvoorkomen LIKE '%op oprit/afrit%' AND typeweg LIKE '%autosnelweg%'. Dit omdat deze attributen meerdere waarden kunnen hebben en we die in de database in 1 veld willen hebben. Een array zou ook een optie zijn, maar vanwege minder ervaring hiermee en zeker met het oogpunt op softwareondersteuning, hebben we hier niet voor gekozen.
@botenvouwer Benieuwd hoe ver je nu bent. Kun je een update geven? Ik zal beloven iets vaker op Gitter te kijken ;)
Leuk weetje, via Stichting OpenTaal (die je spellingcontrole voor op de computer maakt) hebben we een typo gevonden in een openbare ruimte in Suriname. De https://www.openstreetmap.org/changeset/76480638 de Dr. Voigtstraatstraat moest zijn Dr. Voigtstraat (een verlengd stuk had al de goede naam).
@fsteggink Helaas heb ik nog geen tijd gehad om er verder mee te gaan. Ik heb de (docu)[https://lxml.de/4.3/lxmldoc-4.3.3.pdf] van lxml doorgenomen en daarin heb ik ontdekt dat het mogelijk is om meer details over de foutmelding te vinden als je hem catched in python. Ik werk zelf direct vanuit een docker image. Ik kan deze pushen naar de docker repo, dan kan jij of iemand anders mee kijken. Ik ben deze week op de Esri beurs in Berlijn, daar wilde ik even de tijd nemen om er weer verder naar te kijken (druk druk op werk). Ik zat er ook over te denken om de nieuwe pdok endpoints te gebruiken voor het downloaden van de bgt. Dezer hier (https://download.pdok.io/lv/bgt/viewer/). Ik weet niet of dat out of the box gaat werken, maar het zou wel top zijn. De bgt word in dat geval namelijk via Azure blob storage gedownload en dat zou behoorlijk snel moeten gaan.
@botenvouwer Ik heb er zelf ingedoken, omdat het op mijn verwerkingsserver ook mis ging. Dit met de huidige versie van NLExtract. Ook ging het laatst met een lokale dump mis. Met die dump kon ik testen. Het viel me op dat het gegenereerde tijdelijke bestand iets groter was dan 2,1GB. De foutmelding was iets groter dan -2,1 miljard. Dat vind ik verdacht, omdat het in de buurt van 2^31 ligt. Maar als ik de bestandsgrootte en de (positieve) foutcode optel (wie doet zoiets), kwam ik wel EXACT op 2^32 uit. Dat kan geen toeval. Achteraf gezien is het wel toeval dat de lokale dump een bestand genereert dat maar net iets groter is dan 2^31 bytes.
Vervolgens ging ik in de code van lxml kijken, op de plek die in de stack trace wordt aangegeven. Zie https://github.com/lxml/lxml. De onderliggende fout bleek in in libxml te zitten, specifiek in xmlOutputBufferClose. Zie http://www.xmlsoft.org/html/libxml-xmlIO.html#xmlOutputBufferClose. Hier staat: "Returns: the number of byte written or -1 in case of error.". Aha! En aangezien libxml in C geschreven is en het returntype een int is, is dit een signed 32 bit integer, genereert libxml2 deze fout (en wordt ook als zodanig door lxml als fout gezien) wanneer het bestand groter is dan 2^31 bytes. Maar wanneer je bestand groter dan 4 miljard (2^32) bytes is, gaat het weer goed, omdat het getal dan weer als een positieve waarde wordt gezien. Dit is een klassieke integer overflow fout.
De hele wereld gebruikt libxml, dus ik verwacht niet dat dit ooit gefixed gaat worden. Zal ongetwijfeld al eerder gerapporteerd zijn en men heeft er mee leren leven. Dus in NLExtract heb ik besloten om die fout af te vangen en na afloop het tijdelijke bestand te controleren. Dit doe ik met iterparse, omdat ik niet wil dat een hele tree wordt opgebouwd. Zie nlextract/NLExtract@b1f7793.
@fsteggink Heel goed om te horen, ik heb het zelf ook met een try opgelost. Het bracht me alleen nog niet het antwoord op wat er fout was gegaan en had er verder nog niet naar gekeken. Op dit moment is het een vrijdagmiddag project waar ik binnenkort weer meer tijd voor heb. Jouw oplossing is prima, als ik mijn oplossing af heb zal ik de aanpassingen voor python 3 support wel delen. Ook zal ik mijn docker image en definitie delen.
Je kan overigens volgens de lxml documentatie in de Exceptie meer informatie vinden over wat fout gaat. Misschien is het interessant om daar ook nog naar te kijken.
Of gaan daar geen aanpassingen van het script mee gemoeid?
Ik ga bij mijn werkgever overleggen of ik een bijdrage (in tijd) kan leveren
Ben aardig onderlegd in Python, dus zou kunnen bijdragen in code, documentatie, tests, testconfiguraties etc. etc.