<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">In de discussie over node vs gebouw kan
ik zeker meegaan in wat Sander zegt. Bij nader inzien hoeft een
combinatie van beide geen probleem te zijn. Wat mij betreft kunnen
in dat opzicht ook zeker adresposities geimporteerd worden zonder
dat daar gelijk een gebouw-polygoon voor moet ingetekend zijn. Dat
de CRAB-positie in veel gevallen het perceel-centroid is en
daarmee niet wenselijk als adrespositie binnen OSM klopt ook.
Binnen de workflow kan dan opgenomen worden dat de adresposities
minimaal op de AGIV-luchtfoto op het gebouw moeten komen te staat
dat het dichtst aan de weg ligt. Hoewel dat toch zeer wenselijk is
als uiteindelijk doel denk ik dat het 'eisen' dat er een
gebouw-polygoon aanwezig moet zijn toch veel mensen afschrikt om
mee te werken aan de import. Nu wordt in de wiki ook al aangegeven
dat het zeer wenselijk is om gelijk ook de gebouw-polygonen te
tracen van de luchtfoto. De verwoording in de wiki lijkt mij wat
dat betreft prima. <br>
<br>
Voor een aantal woonwijken zal het erop neer komen dat 'alle'
adresposities binnen CRAB prima op het gebouw vallen en daarmee
rechtstreeks geimporteerd kunnen worden (uiteraard na handmatige
controle van elke individuele node). Voor heel veel landelijke
gebieden zal dan de adrespositie handmatig verschoven moeten
worden (met de luchtfoto als leidraad) tot boven het gebouw dat
het dichtst aan de straat ligt. In de workflow moet dan even
duidelijk vermeld worden dat het gebruiken van de AGIV-GRB-kaart
heel handig is om zaken mee te vergelijken, maar dat de
adresposities niet op de GRB-kaart mogen worden uitgelijnd en dat
ook de gebouw-contouren niet mogen worden overgenomen van die
kaart. Wanneer er een bestaande polygoon is voor dat adres kunnen
de gegevens uit het CRAB daar aan toegevoegd worden. Daarnaast
bestaat dan uiteraard altijd de mogelijkheid om het gebouw gelijk
in te tekenen.<br>
<br>
Op technisch gebied gaat het volgens mij best goed. Ik wil zeker
mee kijken naar de software zelf; als de scripts beschikbaar
kunnen worden gesteld: graag! De laatste variant van de webpagina
werkt bij mij prima. Nog iets om bij stil te staan: nog los van
waar de punten zonder positie geplaatst worden bij import
(middelpunt van de straat?); nu worden ze op elkaar weergegeven.
Misschien kan daar met een offset gewerkt worden of zo, zodat
visueel al bij import duidelijk is dat er meerdere punten op
elkaar liggen. Alternatief is dat zo'n punt op het dichtste punt
langs de straat wordt geplaatst, maar die gegevens heb je volgens
mij niet beschikbaar in het import-script. Nog een alternatief is
dat de punten precies verticaal boven/onder elkaar worden
geplaatst langs de westelijke of oostelijke rand van de extent,
ter hoogte van een overeenkomstig punt (als query een gelijk
numeriek gedeelte in het nummer-veld). Maar misschien vinden
jullie het helemaal geen issue dat er meerdere punten op elkaar
liggen bij import.<br>
<br>
Over het niet uitvoeren van een grootschalige import zijn we het
denk ik allemaal eens. Ook is het duidelijk dat er specifieke
richtlijnen moeten zijn (of in elk geval een plan van aanpak) voor
een aantal specifieke issues met de brondata, zoals de
aanwezigheid van adressen zonder positie. Daarnaast heb ik het
idee dat het geheel op de import-lijst voor een gedeelte is
afgeketst door het niet formeel beschreven zijn van de
quality-assesment van de brondata, een eisenspecificatie van de
software en het plan voor het beheren van updates in de toekomst.<br>
<br>
Als ik het zo bekijk is het meeste toch minstens gedeeltelijk
besproken. Ik denk dat als we dat wat formeler op een rij zetten,
we ook een betere 'case' hebben voor de import-lijst. In elk geval
is dan voor externen beter te beoordelen wat nu juist de bedoeling
is.<br>
<br>
Ook voor de software is het denk ik handig om een concrete lijst
van eisen te hebben zodat verschillende software-opties tegen
elkaar afgewogen kunnen worden. Er zijn meerdere softwarematige
opties mogelijk maar we hebben geen formele manier om ze te
vergelijken en te beoordelen welke de 'beste' is. Bij de vorige
gang naar de import-lijst kwamen er vragen over het waarom niet
gebruik maken van de task-manager en zo. Door concreet een lijst
van eisen te hanteren kan heel duidelijk gemaakt worden waarom die
software niet voldoet en waarom alternatieve software daar beter
voor geschikt is (in dit geval lijkt het belangrijkste punt mij
het per-straat kunnen werken in plaats van per
oppervlakte-polygoon).<br>
<br>
Concreet moeten er denk ik 4 formele lijstjes van
voorwaarden/richtlijnen/plannen opgesteld worden:<br>
1) Kwaliteitsbeoordeling van de brondata: welke data is het, welke
kenmerken heeft de data en hoe kan de kwaliteit beoordeeld worden.<br>
2) Kwaliteitsbeoordeling en 'normering' voor de import-software:
wat moet de software precies wel en niet doen en hoe wordt de
werking daarvan beoordeeld.<br>
3) Richtlijnen voor de menselijke handelingen bij de import:
workflow. De wiki-pagina geeft hier al heel wat aanwijzingen maar
is niet compleet.<br>
4) Heel belangrijk: plan van aanpak voor het continu updaten van
de gegevens.<br>
<br>
Deze formele lijsten kunnen bij de import-aanvraag gevoegd worden
als onderbouwing, mogelijk als wiki-pagina over de import op zich.
Verder kan de inhoud ervan volgens mij best verwerkt worden op de
(bestaande) wiki-pagina's. Ik denk dat het belangrijk is dat deze
lijsten opgesteld worden. Het zou toch erg jammer zijn als het
voorstel op de import-lijst afketst omdat bepaalde zaken niet
voldoende uitgewerkt zijn. Dat zou ook heel erg jammer zijn voor
de vele inspanningen die al geleverd zijn.<br>
<br>
Als jullie het hiermee eens zijn ben ik zeker bereid om deze
lijsten vorm te gaan geven. Voor de eerste lijst moet ik me nog
wat verdiepen in de formele beschrijving van de dataset; daar kom
ik op terug. Voor de andere drie lijsten gelijk een voorzet:<br>
<br>
1) Kwaliteit van de brondata. Specifieke issues:<br>
– adressen zonder positie<br>
– verkeerde spelling<br>
2) Eisen voor het import-script:<br>
a) Oplossing voor alle specifieke issues met de brondata?<br>
b) Wat wel/niet te importeren (naast specifieke issues)? <br>
Beoordeling van volledigheid van import-script?<br>
vb: Vakbondstraat in Willebroek ontbrekende nrs tussen 9
en 41<br>
c) Welke tags worden mee geimporteerd? (zie ook 3.d relaties
en 4.a)<br>
d) Het systeem moet het mogelijk maken een latere update te
beheren<br>
3) Richtlijnen voor de workflow:<br>
a) Gegevens worden geimporteerd met het script<br>
b) Adrespunten worden verplaatst tot boven het gebouw
(AGIV-luchtopname)?<br>
Is hier consensus over? Wat met het issue uit mijn vorige
bericht aan Marc?<br>
c) Gegevens uit adrespunt worden toegevoegd aan
gebouw-polygoon.<br>
– indien polygoon aanwezig en eenduidig voor adres:
adrespunt wordt verwijderd<br>
– indien polygoon aanwezig maar niet eenduidig <br>
vb: meerdere adressen in 1 gebouw: appartement,
winkelcentrum, etc<br>
→ adrespunt op zichzelf laten bestaan. <br>
→ Waar precies? Ingang/centroide? (zie ook punt b)<br>
→ Hoe adrespunten die precies boven elkaar liggen te
behandelen? <br>
→ POI-tags komen dan niet op polygoon maar op het punt
te staan.<br>
Wanneer POI volledige polygoon bestrijkt: tags op
polygoon laten.<br>
– indien polygoon niet aanwezig:<br>
* Bij voorkeur gebouw intekenen<br>
* Indien niet haalbaar: adrespunt op zichzelf laten
bestaan<br>
* Indien gebouw niet duidelijk aanwijsbaar of afwezig:
niet importeren<br>
d) Richtlijnen voor straatgegevens op gebouw, punt of als
relatie?<br>
e) Richtlijn voor dedicated account?<br>
f) Registratie voortgang import: overzicht? kaart?<br>
4) Plan van aanpak voor het up to date houden:<br>
a) bron-tags (zoals CRAB-id) bij import handhaven tbv latere
update?<br>
b) diffs-worden automatisch gegenereerd<br>
c) Hoe weten gebruikers wat geupdate moet worden? overzicht?<br>
<br>
Deze lijsten lijken mij het best te passen binnen
<a class="moz-txt-link-freetext" href="http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import">http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import</a> . De inhoud
moet dan verder verwerkt worden in
<a class="moz-txt-link-freetext" href="http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data">http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data</a>
en de daaraan gekoppelde subpagina's. <br>
<br>
De richtlijnen voor huisnummers en zo kunnen dan gekoppeld worden
aan of verwerkt worden in <br>
<a class="moz-txt-link-freetext" href="http://wiki.openstreetmap.org/wiki/User:Escada/JOSM_and_Housenumbers">http://wiki.openstreetmap.org/wiki/User:Escada/JOSM_and_Housenumbers</a><br>
<br>
<br>
Wat denken jullie over het wat formeel op een rij zetten van de
hierboven genoemde zaken? Hebben jullie ideeën voor een verdere
concrete invulling hiervan?<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 20-10-2014 22:34:<br>
</div>
<blockquote
cite="mid:CABUOUO9W_zMkkJdZ06JMiitRZR+Ne7f+oBc-f4Y8=++ViYy_Xw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Eindelijk een versie die werkt met JOSM remotecontrol
(na een JOSM patch, dus werkt het enkel met de SVN
versie). <br>
<br>
<a moz-do-not-send="true"
href="http://sanderd17.github.io/import.html?8840">http://sanderd17.github.io/import.html?8840</a><br>
<br>
</div>
Nu ben ik nog van plan een afstands-check toe te voegen
(met instelbare afstand), en dan kan het terug naar de
import lijst.<br>
<br>
</div>
We moeten enkel nog wat richtlijnen bedenken mbt huisnummers
zonder positie, en met de richtlijnen over waar een
huisnummer te plaatsen (node, gebouw, waar exact) moet alles
in orde zijn.<br>
<br>
</div>
Groeten,<br>
</div>
Sander<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 18 oktober 2014 17:46 schreef Marc
Gemis <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:marc.gemis@gmail.com" target="_blank">marc.gemis@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote"><span class="">2014-10-17 23:27
GMT+02:00 Thomas <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:osm@aptum.nl" target="_blank">osm@aptum.nl</a>></span>:<br>
</span><span class="">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
Daar waar gebouw-polygonen beschikbaar zijn, zijn
ze vaak ingetekend op basis van een luchtfoto (die
op die schaal toch een aanzienlijke vertekening
heeft). In vrijwel alle gevallen die ik bekeken
heb is het CRAB-adrespunt nauwkeuriger
gepositioneerd dan de polygoon die in OSM aanwezig
is.</blockquote>
</span></div>
<br>
Dit begrijp ik niet helemaal. Bedoel je dat de polygoon
in OSM helemaal niet rond het adres punt is getekend ? </div>
<div class="gmail_extra">Voor het overige plaatst de
standard rendering van OSM het huisnummer gewoon in het
midden van de polygoon (als de gegevens op de polygoon
staan).</div>
<div class="gmail_extra">Sommige mensen plaatsen het
huisnummer ongeveer op de deur, dus op de rand van het
gebouw, of gewoon ergens in het gebouw. Er is geen regel
waar het adrespunt moet komen. In Denemarken zijn ze er
wel strenger op waar de huisnummers moet komen (alvast
niet op het gebouw, dat is het enige dat ik kan
onthouden :-) )</div>
<div class="gmail_extra">Dus als er geen regels zijn, kan
je IMHO ook niet spreken over "nauwkeuriger
gepositioneerd", als het nummer op/in het juiste huis
staat, is het juist gepositioneerd voor OSM.
Nauwkeuriger kan niet :-)</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">met vriendelijke groeten</div>
<span class="HOEnZb"><font color="#888888">
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">m</div>
<div class="gmail_extra"><br>
</div>
</font></span></div>
<br>
_______________________________________________<br>
Talk-be mailing list<br>
<a moz-do-not-send="true"
href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
<a moz-do-not-send="true"
href="https://lists.openstreetmap.org/listinfo/talk-be"
target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-be mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-be">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</blockquote>
<br>
</body>
</html>