Hallo Thomas, Mooi werk (Sander ook natuurlijk!).
Eerst de vraagjes op het einde. De source hoort volgens mij thuis op de changeset en niet op elk object apart. JOSM gooit een aantal tags automatisch weg, voordat er geupload wordt. created_by en odbl. De rest van de lijst zit in de verwijizing die Marc aangaf. Bij mijn importscripts voor TEC en De Lijn, voeg ik odbl=new/odbl=tttttt toe (mbv MapCSS wordt dat dan een soort grafische todolist) en zet ik overbodige adresgegevens in created_by. Deze zijn dan wel overbodig voor de bushaltes, maar soms is het interessant om te weten bij welke straat zo'n halte hoorde, of gewoon nog maar om te zien dat een straatnaam in OSM waarschijnlijk fout is. (Dat was voordat we de beschikking hadden over AGIV en CRAB). Wat de (foute) huisnummers betreft die wel in OSM, maar niet in CRAB zitten. Volgens mij zou het beter zijn om die volledig op te bouwen met dat soort discardable tags, ipv addr:housenumber. Dat resulteert dan in tagloze nodes die door de validatie in JOSM worden gerapporteerd in het geval iemand op upload zou drukken, voordat deze manueel werden verwijderd. Of ze stomweg zou vergeten, zoals mij nog wel zou kunnen overkomen... Ik kan de MapCSS aanpassen zodat die er nog prominenter uitspringen dan de rest. Als die MapCSS 'klaar' is, dan zal ik ervoor zorgen dat die gemakkelijk beschikbaar wordt in JOSM. Wat de conversie betreft. Ik zou geneigd zijn om dat zootje eerst helemaal in PostGIS te laden. Dan een Overpass query en die info in een aparte tabel. Het probleem is dan echter dat je ergens een platform nodig hebt, om dat te draaien en te serven + web frontend. Het voordeel is dat achteraf queries schrijven dan een stuk gemakkelijker wordt en dat je ook progress reports kan maken. Als we daar ooit een platform voor hebben, zou het niet slecht zijn, als we dat ook voor De Lijn en TEC konden gebruiken. Nu doe ik dat zowat dagelijks op mijn portable, maar wat als ik wegval? In Frankrijk hebben ze servers, in Nederland misschien ook. Eventueel wil ik het daar wel eens vragen. Zelf iets opzetten en hosten zie ik, eerlijk gezegd, ook niet zitten. Vandaar dat ik de oplossing van Sander wel elegant vind. Jo 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. > > 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 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? > > 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
