Wil je beide lijsten (busnrs en apptnrs) los in de JSON hebben, of
samengevoegd als “subadressenlijst”? Ik had het als dat laatste al
ingebouwd, maar ik kan het natuurlijk eenvoudig weer uit elkaar trekken.
De lijsten worden toch al los van elkaar opgebouwd.
Groeten,
Thomas
Sander Deryckere schreef op 29-10-2014 12:06:
Hoi Thomas,
Net het script wat verder aangepast voor de nieuwe data, en geuploaded
naar jouw repo. Dus aan iedereen, gelieve vanaf nu vooral
http://aptum.github.io/import.html te testen,
Kan je de appartementsnummers en busnummers als aparte lijsten in de
JSON zetten? Dan kan ik ook het script updaten om addr:flats te
ondersteunen. Lijsten zijn het best aangezien ze gemakkelijker
omgevormd kunnen worden naar de correcte formaat. Ook die best
alfabetisch sorteren voor de diffs. En misschien enkel de lijsten aan
de JSON toevoegen indien wel degelijk (dat zal bandbreedte sparen voor
de vele adressen die geen busnummers of appartementsnummers hebben).
Aangezien de overlappende en de niet overlappende nummers nu in
verschillende kolommen staan, is daar geen verschillende CSS voor
nodig. Een verschillende CSS voor de herkomst kan wel helpen.
Momenteel staat die herkomst nog in CRAB:source om de waarden
gemakkelijk te kunnen aflezen. Dus momenteel die tags nog niet gaan
uploaden.
Als het goed is voor iedereen, dan breng ik die tags naar de vorm
* odbl:note=CRAB:manueleAanduidingVanGebouw
* odbl:note=CRAB:geinterpoleerdObvNevenliggendeHuisnummersGebouw
* ...
odbl:note lijkt mij de meest neutrale van alle discardable tags, en
het voorvoegsel CRAB: kan zorgen voor unieke CSS selectors.
De grootste problemen momenteel zijn de huisnummers met een
underscore. Ik kan moeilijk beslissen als ik die naar bis, ter, ... of
naar /1, /2, /3, ... breng. Maar het overlaten aan de mapper kan er
voor zorgen dat de huisnummers met een underscore rechtstreeks
geuploaded worden.
Het andere grote probleem is de spelling van de straatnaam. Dat is
moeilijk om af te leiden met de beperkte OSM data die ik heb in de
webpagina (vooral als er nog geen adressen in OSM zijn). Een
spellingsverschil kan er voor zorgen dat huisnummers geuploaded worden
waarbij addr:street verschilt van de straatnaam in OSM. Wat natuurlijk
voor problemen zal zorgen. Maar hierbij kan Jo misschien helpen, of de
JOSM validator.
Als die problemen opgelost zijn, dan lijken de tools klaar, en wordt
het tijd om enkele definitieve beslissingen te maken:
* Huizen tekenen of niet
* Aparte gebruikersnaam of niet
* Welke tags moeten op de changeset
* Hoe contacteren we het AGIV met opmerkingen?
* ...
Groeten,
Sander
Op 29 oktober 2014 08:39 schreef Sander Deryckere <sander...@gmail.com
<mailto:sander...@gmail.com>>:
Nog niet,
eerst onze tools maken, dan kunnen we het opnieuw presenteren.
Groeten,
Sander
Op 29 oktober 2014 05:08 schreef Marc Gemis <marc.ge...@gmail.com
<mailto:marc.ge...@gmail.com>>:
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 <o...@aptum.nl
<mailto:o...@aptum.nl>>:
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 <o...@aptum.nl
<mailto:o...@aptum.nl>>:
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
<o...@aptum.nl <mailto:o...@aptum.nl>>:
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
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
<mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-be
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org <mailto: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
_______________________________________________
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be
