Nog niet, eerst onze tools maken, dan kunnen we het opnieuw presenteren.
Groeten, Sander Op 29 oktober 2014 05:08 schreef Marc Gemis <[email protected]>: > 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 > >
_______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
