search

nlextract / NLExtract

Convert (ETL) and visualize free Dutch geo-datasets.
https://nlextract.nl
GNU General Public License v3.0
153 stars 83 forks source link

top10nl: importeerd niet alle objecten #232

Closed VNuhaan closed 6 years ago

VNuhaan commented 6 years ago

Beste NLExtract,

ik heb een probleem met importeren van top10nl onder windows. Na importeren blijk ik objecten te missen. Na enig speurwerk heb ik uitgevonden dat de objecten wel in het unzipte bestand(en) zitten maar niet in het top10-tmp.gml bestand. Ik verwacht daarom een probleem in het vertalen van de geometryen. Zijn er suggesties wat ik kan doen?

Vincent

justb4 commented 6 years ago

Beste Vincent, Heb je wat meer gegevens? Bijv:

fsteggink commented 6 years ago

Beste Vincent, dank voor je melding. Ik heb dit probleem ook geconstateerd bij het verwerken van de TOP10NL van afgelopen november. Het issue treedt zowel op mijn eigen computer (Windows) op als de NLExtract server (Ubuntu). Aangezien ik mijn tanden erop stuk gebeten heb, was ik er nog niet aan toegekomen om dit netjes in Github te melden... :(

De oorzaak is nog steeds een raadsel. De features die ontbreken, zien er v.w.b. de GML goed uit. Ze zijn identiek aan de features in september, m.u.v. misschien het ID. Wat ook vreemd is, is dat op beide machines andere features ontbreken. Er zijn verschillende featureklassen waarbij features ontbreken, maar bij waterdelen is dit het meest in het oog springend.

Het verwerken van de TOP10NL dump met losse kaartbladen gaat wel goed. Dit probleem heb ik daar niet geconstateerd. (Zal ik nog nakijken voor de zekerheid.)

Waarschijnlijk is er niks met de features zelf aan de hand die ontbreken, maar wordt er een bug getriggerd door andere features die alleen in de GML-chunck levering zitten. Dus beide leveringen moeten naast elkaar worden gelegd en honderdduizenden of miljoenen features worden vergeleken...

Je bent al verder dan ik door te constateren dat ze niet in het top10-tmp.gml bestand zitten. Dan zit het probleem niet bij OGR. We moeten echt af van die XSLT en/of het opknippen van de bestanden, want dat blijft fragiel. Deze oplossing is nog gebaseerd op GDAL 1.10, maar we kunnen nu rustig GDAL 2 als basis nemen. Helaas zal dit waarschijnlijk wel samengaan met een wijziging van het datamodel.

justb4 commented 6 years ago

Mee. eens: we moeten van de XSLT af. Met GDAL 2 is veel mogelijk, met 2.2 zelfs CityGML, zie bijv https://3d.bk.tudelft.nl/svitalis/citygml/gdal/2017/07/24/messing-around-with-citygml-on-gdal-2.2.html .

VNuhaan commented 6 years ago

Allereerst de beste wensen voor 2018.

Ik gebruik een Windows 7 computer met NLExtract 1.3.0 (met stetl), PostgrSQL 10.1 en OSGeo4W (lxml: 4.1.1, libxml: 2.9.1, GDAL: 2.2.3). De problemen die ik ondervind is vooral met de gml chunks van November 2017, maar daarvoor had ik het ook al maar veel minder. Ik heb ook de kaartbladen gml geprobeerd maar die geeft mij andere missende objecten. Met beide gml extracties is het bij mij vooral zichtbaar in wegdeel_vlak en waterdeel_vlak.

Ik heb al wat onderzoeken gedaan en zie ook alleen een verschil in ID's. Het lijkt dat korte ID's wel importeren en ID's die langer zijn niet. Wellicht zijn de ID te negeren. Het veranderen van de max_features heeft geen invloed, daarmee lijkt het geen geheugen probleem.

VNuhaan commented 6 years ago

Ik heb net ondekt dat het niet aan de gml:id van een missend object is. Als ik het object wat ervoor zit wis, dan wordt het missende object geimporteerd. Maar dan wordt het object wat erna komt niet geimporteerd.

Ik vermoed dat er niets mis is met de gml data maar iets met xmlelement verwerking. Wellicht iets met de bufferlengtes.

justb4 commented 6 years ago

Mbt gebruik geheugen: in je options/host.args bestand laatste regel staat: max_features=20000. Dat is aantal features waarvoor in geheugen steeds een doc wordt opgebouwd tbv XSLT en DB verwerking via top10-gml.gml temp bestand. Als je van 20000 bijv 1000 maakt, treedt het Dan ook op?

VNuhaan commented 6 years ago

Het verlagen van de max_features naar 1000 heeft geen effect. Ik blijf objecten missen.

VNuhaan commented 6 years ago

Ik heb een andere manier gevonden om de top10nl te importeren. Het is een pure GDAL methode. Ik heb een testje gedaan met een aangepast gfs bestand. Het is mij gelukt om alle wegdeel objecten te importeren. Nu moet ik het gfs bestand aan gaan passen voor alle objecten.

Wat ik doe is aan het gfs bestand de geometrien toevoegen zodat deze in verschillende kolommen. Wat ik nu heb is een tabel genaamd wegdeel. En daarin kolommen per geometrietype, dus geometrie_punt, geometrie_lijn en geometrie_vlak.

Het importeren gaat veel sneller via deze pure GDAL metode.

Ik hou jullie op de hoogte.

justb4 commented 6 years ago

Ja dat kan inderdaad, alleen krijg je 3 geometrie-kolommen, daar kunnen meeste tools, bijv QGIS, niet mee omgaan. Dat (splitsen) was een van de redenen voor de XSLT-stap (andere was het extraheren, dmv XPath, van kolommen uit XML-elementen). Je kunt overigens ook de 3 geometrieën splitsen door 3 VIEWs aan te maken, waarbij je steeds via een SELECT alle attributen en steeds andere geometrie meeneemt uit de feature tabel.

Voor een nieuwe ETL kunnen we iets equivalent aan de BRK-DKK verwerking doen: https://github.com/nlextract/NLExtract/tree/master/brk/etl, werkt ook op basis GDAL2 en GFS. Voor het opsplitsen naar geometrie kan ook steeds een geometrie-(kolom)-specifieke GFS ingezet worden. Daarnaast heeft Stetl sinds versie 1.1 de mogelijkheid om een Chain te splitsen: http://www.stetl.org/en/latest/using.html#chain-splitting. Dus bijv na de .zip extractie 3 sub-Chains, ieder met geo-kolom-specifieke .gfs zou mogelijk zijn. Met VIEWs kan natuurlijk ook, maar maakt de ETL PostGIS specifiek...

VNuhaan commented 6 years ago

Ik heb het nog niet werkend, maar zit dicht bij. Ik kom er net achter dat de gfs nieuwer moet zijn dan de gml.

Bendankt voor de tips.

Ik probeer ook terug te komen tot de drie basis geometrien.

Overigens wordt in verwerking van de BGT niet alles tot de drie basis geometrien terug gebracht. Dat is voor mij een probleem waardoor ik nog steeds niets met de BGT data kan.

justb4 commented 6 years ago

On 07-01-18 21:42, Vincent Nuhaan wrote:

Ik heb het nog niet werkend, maar zit dicht bij. Ik kom er net achter dat de gfs nieuwer moet zijn dan de gml. Ja klopt, daarom wordt m.i. .gfs steeds gecopieerd voor de ogr2ogr run binnen de huidige Top10 ETL.

Bendankt voor de tips.

Ik probeer ook terug te komen tot de drie basis geometrien.

Overigens wordt in verwerking van de BGT niet alles tot de drie basis geometrien terug gebracht. Dat is voor mij een probleem waardoor ik nog steeds niets met de BGT data kan. BGT is apart issue. BRT-Top10NL is veel simpeler (=platter) en lijkt meer op BRK daarin. Laten we dat eerst goed krijgen.

VNuhaan commented 6 years ago

Ik heb succesvol met een aangepaste gfs Top10NL kunnen importeren. Het probleem van de missende objecten lijkt daardoor niet aan de gml bestanden te liggen. Ik gebruik de gml chunks.

Het probleem zit in het gedeelte voor het genereren van het tijdelijke bestand dat geimporteerd wordt. Ik zal nog eens het origineel naast het tijdelijke bestand leggen opzoek naar verschillen in missende opbjecten. Ik heb daarvoor een tijdelijk bestand gegenereerd dat niet opgeknipt is in kleine stukjes van 20.000 objecten.

VNuhaan commented 6 years ago

Ik heb een gml bestand (nummer 91) uit de chunk_gml dump vergeleken met het tijdelijke top10-tmp.gml bestand. En heb een verrassent iets gevonden. Ik heb van alle missende objecten in het tijdelijke bestand de positie in het originele bestand opgezocht. Als ik vervolgens deze posities met elkaar vergelijk, blijkt er een veelvoud van ongeveer 33000 bytes tussen de missende objecten te zitten. Dus 33000, 66000, 99000 enz. Dit lijkt erop of per +/-33000 bytes worden ingelezen en verwerkt. Of Is er ergens anders een buffer van +-33000?

VNuhaan commented 6 years ago

Gevonden

In november is er nog iets veranderd, is stetl is er een clear toegevoegd om geheugen op te schonen. Als ik deze uitcommenteer dan importeert de hele dataset weer volledig.

emacgillavry commented 6 years ago

Dankjewel Vincent voor je speurwerk!

Op 14 jan. 2018 22:51 schreef "Vincent Nuhaan" notifications@github.com:

Gevonden

In november is er nog iets veranderd, is stetl is er een clear toegevoegd om geheugen op te schonen. Als ik deze uitcommenteer dan importeert de hele dataset weer volledig.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nlextract/NLExtract/issues/232#issuecomment-357545554, or mute the thread https://github.com/notifications/unsubscribe-auth/ABe9AJf7lrA1EwPA6N94vD2AEAX8z_hEks5tKnb-gaJpZM4RPl1r .

VNuhaan commented 6 years ago

Ik ben nieuw in Python en heb geprobeerd het extractie proces te snappen. Als ik het goed begrijp is het de bedoeling dat na het parsen van een gml element dit element uit het geheugen wordt gewist. Dit wordt geactifeerd als de sluitende tag wordt gevonden, dan wordt er een 'end' event getriggerd. Bij het verwerken van het 'end' event wordt het complete etree geheuden (object) gewist met self.root.clear(), niet alleen het geparste element. Aangezien de bestanden streaming verwerkt worden, worden deze bloks gewijs ingelezen, toch? Kan het dan misschien zo zijn dat het 'end' event ook gegenereerd wordt aan het einde van verwerken van een blok data?

justb4 commented 6 years ago

On 14-01-18 22:51, Vincent Nuhaan wrote:

Gevonden Top! Dan ben je er echt diep ingedoken.

In november is er nog iets veranderd, is stetl is er een clear toegevoegd om geheugen op te schonen. Als ik deze uitcommenteer dan importeert de hele dataset weer volledig. Is dat deze fix? https://github.com/geopython/stetl/commit/9eb451075a35cf57ab9a367960f64617516925c0#diff-9cdf5d143c225bd41b9bf86db1bf4dd6

Ik moet zelf ook weer achterhalen hoe de opzet precies was. Uit mijn hoofd:

Basis idee is dat we een XSLT transformatie doen op de GML input zodat deze "hapklaar" is voor PostGIS (any OGR) output. Omdat de GML gezipped is lezen we de files direct uit .zip file (zonder uitpakken) en daarna in streaming XML parser. Daarbij wordt in geheugen steeds een XML DOM tree opgebouwd van N elementen, omdat inlezen volledig GML bestand uit geheugen zou lopen. De XML DOMs (etree's) gaan steeds XSLT filter in. Omdat de ouput via ogr2ogr verloopt worden getransformeerde nu SImple Feature GML elementen eerst in tempfile weggeschreven die weer door ogr2ogr wordt ingelezen.

Doel en dus uitdaging blijft dat we de BGT (en Top10NL, BRK en toekomst BAG) extraheren geheel via een Stetl config, zonder specifieke Python code. Daarin altijd verbeterd worden, zeker gezien recente GDAL (v2+) versies. Hulp zoals van Vincent is daarbij ontontbeerlijk "Given enough eyeballs, all bugs are shallow" (ESR).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nlextract/NLExtract/issues/232#issuecomment-357545554, or mute the thread https://github.com/notifications/unsubscribe-auth/AAjj5nTEWwbVsjlTj30eHQchmkUXSicqks5tKnb-gaJpZM4RPl1r.

VNuhaan commented 6 years ago

Is dat deze fix? geopython/stetl@9eb4510#diff-9cdf5d143c225bd41b9bf86db1bf4dd6

Ja

VNuhaan commented 6 years ago

Ik heb de fix gevonden!!

Afgelopen nacht met succes de dataset geïmporteerd.

Is dat deze fix? geopython/stetl@9eb4510#diff-9cdf5d143c225bd41b9bf86db1bf4dd6

Vervang self.root.clear() door elem.clear() en het werkt weer.

justb4 commented 6 years ago

Mooi! Ik zat ook al in die richting te denken. Iets dergelijks gebeurt bij een Stetl XML Streaming Input.

Kun je een PR submitten voor Stetl? Kan geheel binnen GH: https://github.com/geopython/stetl maak Fork naar je eigen account. Edit stetl/filters/xmlelementreader.py en maak Pull Request aan.

fsteggink commented 6 years ago

Afgelopen nacht heb ik ook via Stetl en de fix van Vincent de TOP10NL ingelezen. En gisteren TOP50NL t/m TOP1000NL. Nu is de BGT al aan het laden. Hij is nu 12 uur bezig en ik denk dat, als het eerdere geheugenissue nog speelt waarvoor ik self.root.clear() heb toegevoegd, dit allang opgetreden zou zijn.

Elem.clear() is iets minder ideaal, omdat het root document loze entries blijft houden, maar afdoende voor het geheugenissue.

En toch blijft het ergens gek, omdat het element dat blijkbaar niet wordt weggeschreven vlak daarvoor met deepcopy wordt gekopieerd... Ik vraag me af of het zin heeft dit verder uit te zoeken.

fsteggink commented 6 years ago

De BGT was succesvol geladen. Wat mij betreft kan het issue worden gesloten. Nog even een PR-retje maken voor het bijwerken van het commentaar.