Op 25 oktober 2014 18:46 schreef Thomas <o...@aptum.nl>: > Ik ben inmiddels bijna klaar met het nieuwe script dat de adressenlijst > (in plaats van de adresposities) moet beschikbaar stellen via de website > die Sander gemaakt heeft. > > Geweldig nieuws ;)
> Het oude script kon ik maar voor kleine stukjes hergebruiken omdat het > bestandsformaat en de datastructuur toch redelijk anders zijn. Ik ben > uitgegaan van precies dezelfde JSON-uitwisselbestanden te genereren zodat > de website wel volledig compatibel is (op misschien wat extra tags in > javascript na dan). Het was niet eenvoudig om een goed werkend script op te > zetten vanwege de door Sander genoemde coderingsproblemen en vanwege het > feit dat deze adressenlijst in feite 1 grote tabel is tegenover de > adresposities die in feite een 'database' zijn of een collectie van > kleinere tabellen. Daardoor liep ik tegen nogal wat geheugenprobleempjes > aan. > > De beschikbare modules om GML in te lezen in python bleken niet robuust > genoeg om én met de vreemde codering om te gaan én met de enorme omvang van > het bestand (ca. 3GB). Daarom heb ik ervoor gekozen om als bron het > shp-bestand te gebruiken (dat 'slechts' 1GB in omvang is, door een > efficiëntere datastructuur). Daarmee kreeg ik wel alles aan de praat. > Ik had ook al wat zaken opgezocht om het GML bestand te splitsen en pas daarna te verwerken, om zo slechts XML kind per kind in het geheugen te laden en geen geheugen tekort te komen. Maar dat werd een serieus gepruts, en ik verwachtte ook dat het te traag zou zijn door de vele lees en schrijf operaties. Geheugenproblemen had ik sowieso verwacht, want zelft met het huidige script moet ik zorgen dat Firefox en JOSM alletwee gesloten zijn voor ik het script start. Anders loopt mijn computer onherroepelijk vast in het page-swapping. > > Ik ben nu een aantal extra checks in de code aan het inbouwen en te kijken > wat handig is qua extra tags (evt. gekoppeld aan wat CSS). Het blijft ook > wat worstelen met de omvang. Mijn eerste tests werken in elk geval bij mij. > Als het een beetje wil komt dat dus dit weekend af. Ook alle gemelde > 'problemen' met de huidige dataset ga ik bekijken in deze nieuwe dataset. > > Voor alle duidelijkheid: voor de gebruikers verandert er weinig tot niets > tegenover de huidige versie. Belangrijkste wijzigingen zijn het feit dat er > punten zonder positie zullen zijn en dat er misschien wat extra tags > automatisch ingeladen worden in JOSM als je een straat importeert. Die > extra tags moeten helpen om de informatie naar waarde te schatten. In elk > geval in deze eerste test-fase kunnen ze zeer handig zijn om beter bepaalde > zaken te begrijpen. > > Ik heb nu voor het patroon “CRAB:key” gekozen als key voor de tags die ik > in JOSM inlaad maar die niet in OSM thuishoren. Zijn er alternatieve > patronen voor dit soort “tijdelijke” werk-tags die OSM nooit mogen > bereiken? In de link die Marc eerder doorstuurde lees ik vooral dat onze > Nederlanders een aantal overbodige tags in OSM hebben zitten n.a.v. een > aantal imports. Het lijkt me op zich een mooi streven om al dat soort tags > buiten OSM te houden, wat onze 'import' betreft. > > Moet er overigens nog een “source=CRAB”-tag toegevoegd worden, of willen > we dit juist vermijden omdat het toch al niet om een automatische import > gaat? > source=* tags zijn beter op hun plaats op het changeset object dan op objecten in de DB. Natuurlijk kan een specifieke bron (zoals afkomstig van de voordeur, gebouw or perceel) wel op het object zelf. Postcode en gemeente zijn sowieso niet nodig, die kunnen gerust uit de JSON gelaten worden. Welke andere keys twijfel je nog over? > > Groeten, > Thomas > > Sander Deryckere schreef op 25-10-2014 17:52: > > Hmm, blijkbaar hebben alle tabellen een mogelijkheid tot deleten via > "einddatum". > > En blijkbaar gaat dat niet altijd samen. > > Ik heb nu net eens het script laten lopen met alle records waar > "einddatum" bijstond genegeerd, en dat resulteert vooral in terreinobjecten > die genegeerd worden, waardoor er vooral extra adressen zonder positie zijn > :/ > > Heb ook eens de Koningin Louisa-Marialaan bekeken met die nieuwe data, en > daar blijkt er nu geen verschil te zijn O_o > > Dus denk ik dat ik het script nog niet zal aanpassen. > > Groeten, > Sander > > Op 25 oktober 2014 16:11 schreef Sander Deryckere <sander...@gmail.com>: > >> >> >> Op 25 oktober 2014 14:48 schreef Sus Verhoeven <sus...@gmail.com>: >> >>> In Leopoldsburg 3970 op de Koningin-Louisalaan is er in CRAB een hele >>> reeks huizen met dubbele huisnummers niet op dezelfde plaats, in GRB staat >>> er maar een van deze reeksen. >>> Eigenaardig. >>> >>> Sus >>> >>> >> Dit lijkt een straat die onlangs hernummerd is, en waarvan de oude >> nummers nog niet verwijderd zijn. >> >> Ook de GRB basiskaart is niet volledig duidelijk. Zo is er daar een >> nummer 13-125 te zien, wat een veel te grote range is om te kunnen kloppen. >> Ik zou voorstellen om eens ter plaatse te gaan kijken wat er nu echt juist >> is. >> >> Volgens de documentatie van de databases zouden ze verouderde nummers >> moeten deleten door er een "einddatum" aan te geven. In het extract script >> test ik ook op die einddatum, dus als ze correct verwijderd zijn, dan >> zouden ze niet meer in de data mogen voorkomen. >> >> Het is natuurlijk niet eenvoudig om in dit geval te controleren als het >> script of de data fout is, omdat het nu eenmaal niet vaak gebeurt dat een >> straat hernummerd wordt. >> >> In Leuven werd onlangs een straat hernummerd (zie >> http://www.nieuwsblad.be/article/detail.aspx?articleid=DMF20130218_00473793) >> en ik denk dat de CRAB data overeenkomt met de huidige data, dus dat de >> verwijderde nummers wel degelijk niet meer zichtbaar zijn. Maar 1 voorbeeld >> is natuurlijk wat weinig om op voort te gaan. >> >> Groeten, >> Sander >> >> > > > _______________________________________________ > Talk-be mailing > listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be > > > > _______________________________________________ > Talk-be mailing list > Talk-be@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-be > >
_______________________________________________ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
