De herkomst voor de punten die in mijn script samenvallen is
vaak/meestal/altijd onderling niet verschillend, noch wijkt die herkomst
af van de andere punten in de straat. Het gaat sowieso niet om
busnummers / appartementnummers. Die heb ik net als in jouw script niet
opgenomen. Het gaat steeds om verschillende adressen die dezelfde
positie meegekregen hebben. Soms gaat het om verschillende nummers (vb
21 en 23) die samenvallen, soms om verschillende bisnummers (vb 25A en
25B) die samenvallen. Het zijn dus wel steeds echt verschillende adressen.
In deze Adressenlijst vormt elke huisnummer-busnummer combinatie een
eigen record. Stel: je hebt 2 huisnummers: nr 4 en nr 6. Beide behoren
tot 1 gebouw. Voor beide nummers heb je 5 busnummers: bus1, bus2, bus3,
bus4 en bus5. In de adressenlijst heb je dan 12 records (2 x 1 adres
zonder busnummer en 2 x 5 adressen met busnummer). Het huisnummerr-label
(HNRLABEL) is voor alle 12 records hetzelfde: “4-6”. In mijn script
registreer ik (net zo als in het script van Sander) de adressen in een
dictionary per straat met als key het huisnummer. Daarmee worden al die
verschillende busnummer / appartementnummers genegeerd. Omdat de
informatie verder toch gelijk is, is het overschrijven op basis van
huisnummer als key in principe voldoende, en hoeft er verder niets
gemerged te worden.
Wat daar inhoudelijk moet gebeuren hangt af van de situatie ter plaatse,
denk ik. Het meest handig is denk ik een FIXME-tag die aangeeft dat de
punten samenvallen. Er moet immers steeds iets gebeuren met die punten.
Daar kan dan eventueel het huisnummer-label aan worden toegevoegd, maar
dat moeten we enkel doen als we dat een aanvaardbare situatie vinden
(dat die punten worden samengevoegd tot 1 adres met zo'n samengesteld
label). Als we dat samenvoegen in beginsel onwenselijk vinden (zo veel
mogelijk los) dan moeten we dat label misschien juist niet aanleveren en
enkel die FIXME-tag instellen.
Dat sorteren heb ik over het hoofd gezien. Ik pas het aan; bij de
volgende omzetting zal het weer netjes geordend staan.
Het gebruiken van discardable keys is een goed punt; dat ga ik nog even
verder bekijken. Ook het enkel gebruiken van discardable keys in de
wrong-laag lijkt me een goed punt. Ook de upload=no ga ik toepassen. Dat
is allemaal een beetje voer voor het javascript; daar heb ik nog maar
weinig aandacht aan besteed. Ik pak het op.
Verder is er nog iets gek aan de hand met het bepalen van de
“Missing”-punten, zowel in mijn script als die van Sander. Voor veel
plaatsen werkt dat prima. Nu keek ik naar postcode 9000, straat
“Hoogpoort”. Daar lijkt het helemaal niet te werken (voor de hele
postcode); niet bij jouw script en niet bij mijn script. In heel
postcode 9000 (Gent) zou geen enkel “Wrong” punt zijn; dat kan niet.
Mijn script levert geen “NoPos” punten op, dus dat is wel anders, maar
de bestaande adressen in OSM worden niet opgepikt. Dat terwijl voor
bijvoorbeeld postcode 8400 alles perfect gaat.
Als ik de requests bekijk, krijgt JS netjes een JSON antwoord van
overpass, maar voor postcode 9000 is die leeg (8400 is netjes gevuld).
Dat doet me denken aan een soort timeout van je query. Handmatig het
query invoeren levert overigens ook geen resultaten op. Misschien heeft
het specifiek met Gent te maken, dat daar het selectiemechanisme om tot
de postcode te beperken niet werkt of zo? Dat moeten we nog even goed
bekijken.
Overigens zag ik dat ik nog de oude variant van de webpagina en het
JS-script gebruik. Die ga ik ook netjes updaten.
Groeten,
Thomas
Jo schreef op 26-10-2014 11:41:
Het lijkt mij ook aangewezen om voor de nummers die in de wronglaag
worden geladen geen addr:housenumber/addr:street te gebruiken. Daar
zou ik enkel discardable keys gebruiken, die we dan zichtbaar maken
mbv MapCSS. (Wel Expert modus gebruiken, anders worden ze niet getoond)
Zo ontstaat er geen verwarring bij het samenvoegen van die lagen. Als
die nodes enkel discardable keys bevatten, zoals:
"tiger:upload_uuid", "tiger:tlid", "tiger:source", "tiger:separated",
"geobase:datasetName", "geobase:uuid", "sub_sea:type", "odbl",
"odbl:note", "yh:LINE_NAME", "yh:LINE_NUM", "yh:STRUCTURE",
"yh:TOTYUMONO", "yh:TYPE", "yh:WIDTH_RANK"));
dan worden die allemaal weggehaald en dan zal de validator daarover
klagen. Even testen. Ai, de tags en hun waardes worden pas weggehaald
na de validatie. Dat moet nog beter kunnen.
Wat me ook belangrijk lijkt, is om voor die wrong-laag, upload=no aan
te zetten in het XML-bestand:
<osm version="0.6" upload="no" generator="Python/JS script">
<changeset>
<tag k="source" v="CRAB"/>
</changeset>
Dan zal JOSM tenminste toch al klagen, als je die laag zonder meer zou
proberen door te sturen.
Met die changeset/source tags wordt spijtig genoeg geen rekening
gehouden, voor zover ik kan zien. Maar toch lijkt het me wel goed om
die toe te voegen.
Jo
Op 26 oktober 2014 11:09 schreef Jo <[email protected]
<mailto:[email protected]>>:
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]
<mailto:[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]
<mailto:[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 list
[email protected] <mailto:[email protected]>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
[email protected] <mailto:[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
