Voor tags waarvan je niet wilt dat ze naar OSM worden opgeladen is het het beste om tags te gebruiken die automatisch zullen worden verwijderd, voorbeelden zijn created_by en odbl. Laat me weten als er meer nodig zijn. Ze zitten ergens in de broncode van JOSM.
Ik zou dus die tags gebruiken ipv CRAB:source. 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 list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
