Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 11 01:16
    justb4 closed #273
  • Jan 11 01:16
    justb4 commented #273
  • Jan 08 12:08
    holtkamp commented #64
  • Dec 20 2019 12:30

    justb4 on master

    vervang referenties aan http://… Verduidelijk "real-release" zip… Merge pull request #274 from re… (compare)

  • Dec 20 2019 12:30
    justb4 closed #274
  • Dec 20 2019 12:30
    justb4 commented #274
  • Dec 20 2019 12:16
    reinvantveer commented #274
  • Dec 20 2019 12:15
    reinvantveer synchronize #274
  • Dec 20 2019 12:00
    justb4 commented #274
  • Dec 20 2019 11:43
    justb4 milestoned #274
  • Dec 20 2019 11:43
    justb4 review_requested #274
  • Dec 20 2019 11:43
    justb4 assigned #274
  • Dec 20 2019 11:43
    justb4 labeled #274
  • Dec 20 2019 11:43
    justb4 labeled #274
  • Dec 20 2019 11:40
    justb4 labeled #274
  • Dec 20 2019 11:28
    reinvantveer opened #274
  • Dec 16 2019 10:56
    fsteggink synchronize #242
  • Dec 16 2019 10:56

    fsteggink on brk-column-fixes

    #273 verkorteopenbareruimtenaam… Fix for writing temp BGT files … Merge remote-tracking branch 'o… (compare)

  • Dec 16 2019 10:55
    fsteggink synchronize #241
  • Dec 16 2019 10:55

    fsteggink on brk-speedup

    #273 verkorteopenbareruimtenaam… Fix for writing temp BGT files … Merge remote-tracking branch 'o… (compare)

Sicco van Sas
@siccovansas

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?

Just van den Broecke
@justb4
@siccovansas @/all er is idd iets misgegaan bij laatste (2019_04_08 april 2019 BAG) NLExtract BAG cronjob, lijkt erop dat er teveel processen tegelijk liepen, ook net de BRK Dump bijv. Nu even handmatig opgestart, wel even geduld nog.
Sicco van Sas
@siccovansas
Top! Ik heb mijn eigen database inmiddels handmatig bijgewerkt, maar goed om te horen dat het gefixed wordt :)
Django Eijgensteijn
@django23
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?
Just van den Broecke
@justb4
@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
Django Eijgensteijn
@django23
@justb4 interessant. Ik ben al wat verder gekomen, maar heb het nog niet werkend.
Succes met het integreren in ieder geval!
Just van den Broecke
@justb4
Met "PostGIS" en "Voronoi" kan veel, zie ook bijv: https://longair.net/blog/2017/07/10/approximate-postcode-boundaries/
Bas Hendrikse
@Bash-
Hallo NLExtract community, heeft iemand hier ervaring met het overbrengen van het NWB naar een PostgreSQL met PostGIS? Ideale situatie zou zijn dat de database automatisch geüpdate wordt bij een nieuwe versie
Just van den Broecke
@justb4
@Bash- kun je de vraag iets specifieker maken? "NWB" is brede term en zie dat verschillende bestanden en formaten worden aangeboden: bij RWS en via PDOK. Welke bestanden precies en welke formaten? ESRI Shapefiles zijn eenvoudig met GDAL/OGR ogr2ogr in te lezen.
Bas Hendrikse
@Bash-
@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"
Just van den Broecke
@justb4
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.
Bas Hendrikse
@Bash-
Duidelijk, bedankt voor je hulp!
Bas van der Heijden
@basvdheijden

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?

Bas van der Heijden
@basvdheijden
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
Just van den Broecke
@justb4
@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.
Bas van der Heijden
@basvdheijden
Dank.
Ik heb de vraag ook daar gesteld.
Tino de Bruijn
@tino
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).
Sicco van Sas
@siccovansas

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.

Tino de Bruijn
@tino
Ha @siccovansas! Ja ik geloof dat in het Fries alles een 2e naam heeft, maar daar ga ik nog niet aan beginnen, das een aparte taal ;). Maar goed, dan laat ik het hier bij en hardcoden we DH en DB als synoniemen in de code.
William Loosman
@botenvouwer

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 -2029986190

Zoals 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?

Marie-Anne
@marieanneb_gitlab
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?
Pander
@PanderMusubi
@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?
Just van den Broecke
@justb4

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...

Willy Tadema
@FrieseWoudloper
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?
Willy Tadema
@FrieseWoudloper
@PanderMusubi Bedoel je iets wat vergelijkbaar is met http://www.histopo.nl of https://www.geonames.org ?
Just van den Broecke
@justb4
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.
Stephan Preeker
@spreeker
wie of wat doen aan het actief bijhouden van OSM <-> (BGT, BAG ect) ?
Edward Smit
@edwardsmit
@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?
Just van den Broecke
@justb4
Probleem is bekend, er wordt gewerkt aan oplossing: https://groups.google.com/forum/?hl=en#!topic/nlextract/NMx47b2wLx4
Frank Steggink
@fsteggink
@edwardsmit Issue is nu opgelost. Ik heb het BAG-updateproces wat robuuster gemaakt.
@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
Frank Steggink
@fsteggink
@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 ;)
Pander
@PanderMusubi
@FrieseWoudloper histopo.nl en genonames.org kende ik nog niet. Wat ik heb gemaakt is wat anders maar ga het zeker bekijken. Dank!
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).
William Loosman
@botenvouwer
@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.
Frank Steggink
@fsteggink
@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.
Frank Steggink
@fsteggink
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.
Rob van Loon
@borrob
@fsteggink Behoorlijke puzzel. Mooi gevonden!
William Loosman
@botenvouwer
@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.
Rein van 't Veer
@reinvantveer
Hoi NLExtract! Ik heb een vraag over de BAG 2.0: zijn er plannen om die te verwerken met NLExtract?
Of gaan daar geen aanpassingen van het script mee gemoeid?
Just van den Broecke
@justb4
Ja, wel plannen, en al wat voorwerk, zie issue #259.
Rein van 't Veer
@reinvantveer
Ah ok dank, heel interessant
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.