Hoe zit het met het nodige papierwerk rond de import ? Zijn daar al vorderingen gemaakt ?
groeten m 2014-10-26 13:18 GMT+01:00 Thomas <[email protected]>: > De code staat op https://github.com/aptum/aptum.github.io. De code van > het python-conversiescript staat er nog niet op omdat ik nog wat dingen aan > het omschuiven ben. Ik probeer dat script zo snel mogelijk ook daarbij te > zetten. De nieuwste variant van het javascript en de website (met > uitzondering van die twee regels code om 'mijn' tag in JOSM in te laden; > regels 358-359) kun je bij Sander vinden: > https://github.com/sanderd17/sanderd17.github.io/ > > Het inladen van gegevens uit de overpass is op zich wel mogelijk, maar we > moeten denk ik wel heel erg opletten dat het geen allegaartje wordt. CRAB > en OSM strikt gescheiden houden heeft misschien ook wel voordelen; tenzij > je een specifiek doel voor ogen hebt? > > Groeten, > Thomas > > Jo schreef op 26-10-2014 12:58: > > Hallo Thomas, > > Waar staat de broncode nu? Ik had het graag nog 's bekeken. Ook de JS die > ik de vorige keer gemist heb... Is er een mogelijkheid om wat je afhaalt > met Overpass ook mee te geven naar JOSM? Of is dat niet zo'n goed idee. > > Van zodra duidelijk is welke discardable tags je gebruikt, zal ik een > MapCSS-stijl maken. > > Jo > > Op 26 oktober 2014 10:20 schreef Thomas <[email protected]>: > >> De validator geeft inderdaad netjes melding van de meerdere punten op >> elkaar. Ik vraag me af of we daar nog iets mee moeten. Veel (alle?) van de >> adressen zonder positie uit jouw script vallen nu samen met een ander punt. >> Voor wat ik zo snel even kon bekijken zijn dat toch best veel punten. Daar >> moet dus sowieso handmatig op ingegrepen worden (zoals eigenlijk op heel >> veel punten). >> >> Moeten we nog iets doen met een hulptag over appartementsnummer, >> busnummers of huisnummerlabels? Over dat laatste zegt het AGIV in de >> documentatie: “Opgelet: Komen er op de coördinaat van het CRAB adres >> meerdere huisnummers voor die in dezelfde straat liggen, dan bevat het >> label het laagste en het hoogste huisnummer (bv. label 10-14 voor het >> perceel met de huisnummers 10, 12 en 14 in de Molenstraat).”. Het zou ook >> mogelijk moeten zijn om voor deze punten automatisch een samengestelde >> addr:housenumber-value te maken die een samenstelling is van de >> verschillende punten die samenvallen. Dat valt nog wel te coderen. >> >> Los van de technische vraag is de inhoudelijke vraag dus eigenlijk: wat >> doen we met die samenvallende punten? Schuiven we de punten handmatig uit >> elkaar, of voegen we ze samen met een samengesteld label als 15A-B voor de >> adressen “15A” en “15B”. Dat laatste kan automatisch, maar het is dan weer >> de vraag of dat wenselijk is. Er zullen vast situaties zijn waarin je die >> punten niet wil mergen maar juist individueel houden. Het hele idee is ook >> dat we puur adressen (en eventuele bisnummers) in OSM stoppen en geen >> subadressen (busnummers en appartementnummers). Dus: indien de adrespositie >> voor twee adrespunten gelijk is, moeten deze dan automatisch worden >> samengevoegd tot 1 punt met een samengesteld label, of laten we dat ter >> beoordeling van de mapper? >> >> Ik ga nog even kijken naar wat checks op die straatnamen met een >> gelijkaardige naam en een verschillende id. Het zou interessant zijn als >> die gevallen opgepikt worden. Ik ben het ermee eens dat veel van de >> foutopsporing in het algemeen best aan de JS-kant gebeurt. Daar heb je ook >> je overpass-query beschikbaar. Aan de andere kant vind ik dat een aantal >> basis-integriteits-dingen toch al door het python-gedeelte mogen worden >> opgepikt. De loopduur van het script moet aan de andere kant ook weer zo >> kort mogelijk gehouden worden. Ik denk dat het een beetje zichzelf wijst. >> Een aantal checks (zoals zelfde straatnaamid, verschillende straatnaam) >> hebben geen of een zeer lage kost, terwijl deze toch een zekere >> basiskwaliteit van de dataset opleveren. >> >> De scripts eerst vergelijken en evalueren lijkt me prima. Ik heb een >> eigen github aangemaakt zodat het onderscheid tussen beide scripts nu eerst >> helder is. Ik heb de data van de laatste conversie alvast opgeladen samen >> met de webpagina en het JS. Aan de webpagina heb ik helemaal niets >> gewijzigd. Aan het JS heb ik enkel de extra tag toegevoegd, binnen een >> conditional. >> >> Ik ga nog wat kleine puntjes aanpakken en het python-script wat robuuster >> opbouwen. Misschien dat ik met een parallelle architectuur nog wat >> snelheidswinst kan boeken. Vanaf nu kan er in elk geval weer getest gaan >> worden. Ook alle problemen met de dataset die in de laatste mails gemeld >> werden ga ik nader bekijken. >> >> Bij deze dus het verzoek aan al diegenen die mee willen testen: jullie >> kunnen op http://aptum.github.io/import.html mijn script testen. Het >> verschil met de pagina van Sander is dat mijn pagina gebruik maakt van de >> adressenlijst in plaats van de adresposities. Uiterlijk is er niets >> veranderd, maar het conversiescript is vrijwel compleet nieuw. Daarnaast >> heb ik een extra tag toegevoegd (CRAB:source) die weergeeft waar de >> informatie uit het CRAB vandaan komt. Deze geeft aan hoe het adrespunt >> bepaald is, en zegt daarmee iets over de nauwkeurigheid van de plaats van >> het label. Deze tag mag niet naar OSM opgeladen worden! Graag hoor ik het >> als er nog problemen gesignaleerd worden. Bij deze ook credits voor het >> vele en goede werk van Sander en voor het ter beschikking stellen van alle >> code! >> >> Groeten, >> Thomas >> >> Sander Deryckere schreef op 25-10-2014 21:17: >> >> >> >> Op 25 oktober 2014 20:57 schreef Thomas <[email protected]>: >> >>> >>> Inmiddels ook de codering in gehoorzaamheid gedwongen. Blijkt dat de >>> codering van de shapefile gewoon Latin-1 is en niet die vage CP-720. Dat >>> scheelt ook maar weer. >>> >>> De snelheid van mijn script valt me al bij al wel mee. Op dit moment >>> gebruikt hij maar 1 thread. Het inlezen van het bestand in de dictionaries >>> duurt zo'n 50 minuten. Het schrijven naar de JSON-bestanden een kleine 10 >>> minuten (op een SSD'tje). Het schrijven gaat volgens mij wat trager omdat >>> ik de adres-dictionary vervangen heb door een tuple. Dat scheelt toch een >>> kleine 500MB in geheugengebruik. In totaal gebruikt het script maar iets >>> van 2GB ram dacht ik, maar dat moet ik nog even nakijken. Sinds die >>> wijziging heb ik in elk geval geen geheugenproblemen meer gehad. >>> >>> Qua tags hoeven we inderdaad enkel de addr:housenumber en addr:street >>> over te nemen. Daarnaast wil ik graag het herkomst-veld als tag invoeren, >>> zodat de punten gestyled kunnen worden op basis daarvan. Naar mijn idee is >>> die herkomst zeer bepalend voor de “nauwkeurigheid” van de punten. Ik heb >>> dat nu geïmplementeerd als een “CRAB:herkomst”-tag. De Engelse variant >>> “CRAB:source” vond ik een beetje misleidend. Aan de andere kant gaat het >>> natuurlijk wel over hoe ze de locatie van het punt bepaald hebben. Dat kun >>> je dus wel als “source” zien. >>> >> >> CRAB:source=* lijkt me goed. Als de waarden enigszins duidelijk zijn, >> dan is alles ok. >> >>> >>> Daarnaast misschien nog iets van een tag om waarschuwingen mee te >>> communiceren, bijvoorbeeld over de schrijfwijze van de straatnaam. Aan de >>> andere kant heb ik geen enkel geval kunnen vinden waar twee adressen een >>> zelfde straatnaam-id hebben maar een verschillende straatnaam (bijvoorbeeld >>> een andere spelling). Dat soort fouten lijken me maar beperkt aanwezig en >>> kunnen dus waarschijnlijk allemaal opgevangen worden met de FIXME-tag. Het >>> huidige gebruik (om punten zonder locatie mee aan te geven) is in feite >>> overbodig, omdat alle punten een locatie hebben. >>> >>> De JOSM validator kan hier ook nuttig zijn. Als de coordinaten >> volledig overeenkomen, dan zal de validator sowieso klagen denk ik. Dus is >> een fixme tag misschien niet volledig noodzakelijk >> >> De straatnaam id is in de posities database de enige manier om de >> straatnaam te vinden. Dus als er enige overeenkomst tussen de databases is, >> dan is het normaal dat je geen straatnaam-id vindt met twee verschillende >> namen. De andere kant kan wel voor komen: dezelfde straatnaam (of bijna >> dezelfde) met een verschillende straat id. >> >> >>> Ik ben nu nog wat aan het kijken welke fouten ik met het python-script >>> moet opsporen en welke best in de javascript naar boven gehaald kunnen >>> worden in combinatie met de overpass-query. Het belangrijkste zijn de >>> punten die samenvallen. Dat is een situatie die niet ingevoerd mag worden >>> in OSM, dus ook hier lijkt een FIXME-tag mij het meest geschikt. Dat ga ik >>> in elk geval nog even netjes documenteren. >>> >>> Ik zou het foutopsporen vooral voor de JS kant houden. Dan kunnen we >> dat gemakkelijker aanpassen (zonder een script van een uur te draaien om >> dan een klein tikfoutje te ontdekken). >> >> >>> Nog een praktisch punt: hoe willen we deze tweede variant beschikbaar >>> stellen? Moet dat naast de huidige komen te staan zodat we kunnen >>> vergelijken, of moeten we juist vermijden dat er twee varianten in gebruik >>> zijn en dat er verwarring ontstaat? Voor de gewone gebruiker is er >>> eigenlijk geen verschil tussen beide systemen, dus dat is potentieel >>> verwarrend. Anderzijds is het in de huidige beperkte opzet niet zo'n punt >>> en misschien juist handig. Wat zijn jullie ideeën hierover? >>> >>> Ik zou het nog even naast elkaar houden, kwestie van vergelijking. Na >> het evalueren van de tools kunnen die dan onder een beter adres beschikbaar >> gesteld worden. >> >> Host je het onder je eigen server (desnoods je eigen github account) of >> wil je toegang tot de repo die ik nu heb? >> >> Groeten, >> Sander >> >>> >> >> >> _______________________________________________ >> Talk-be mailing >> [email protected]https://lists.openstreetmap.org/listinfo/talk-be >> >> >> >> _______________________________________________ >> Talk-be mailing list >> [email protected] >> https://lists.openstreetmap.org/listinfo/talk-be >> >> > > > _______________________________________________ > Talk-be mailing > [email protected]https://lists.openstreetmap.org/listinfo/talk-be > > > > _______________________________________________ > Talk-be mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-be > >
_______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
