<div dir="ltr">Een allegaartje van antwoorden en opmerkingen:<div><br></div><div>- Ja, dit is een import (je kopieert data van een andere databank zonder survey) en dus moet je voldoen aan de import procedure. Deze moet dus beschreven worden en voorgelegd worden aan de import lijst. Een van de voorwaarden is een specifieke account..Je mag dus nu feitelijk nog geen data overnemen via de tool, omdat de procedure nog niet is goedgekeurd. Ik vraag me wel af in hoeverre deze werkwijze tegemoet komt aan de vragen/eisen die er met de vorige manier opdoken.</div><div>- Ik heb Chrome gebruikt (te lui om ook Firefox te installeren) en hoopte dat dat ook zou werken. Sander, Welke vieze trucks heb je gebruikt omdat het enkel op Firefox zou werken ? (grapje :-) Eerst met 2840 (Rumst), daarna met de A-straten (10 of zo), dan met 1 straat. Kreeg geen resultaat. Zal later nog wel eens met Firefox proberen</div><div>- Als je geen initiële survey doet, hoe weet je dan of de nummers in AGIV Crab juist zijn ? Ik wil daar niet vanuit gaan, heb al een paar problemen gezien. Ook ontbreken er soms nummer (niet alleen nieuwbouw). Als je nu de nummers gewoon overneemt, zonder controle, gaan die fouten er maar heel langzaam uitgaan. Waar geven we de voorkeur aan: geen data of data met ?? fouten. Ik heb er nog steeds geen zicht op hoe goed AGIV Crab is. 5% fouten ? meer ? minder ? Dit is volgens mij een van de vragen van de import mailing list.</div><div>- Het kadaster is volgens mij niet rechtsgeldig (zie bv <a href="http://bouwinfo.be/forum/threads/136644-buurman-zet-afsluiting-1-5m-over-de-scheidingslijn/page2">http://bouwinfo.be/forum/threads/136644-buurman-zet-afsluiting-1-5m-over-de-scheidingslijn/page2</a> )</div><div>- Het is nu de bedoeling dat de gemeenten de huizen gaan intekenen (meen ik begrepen te hebben van Gilbert). Volgens zijn "contact" persoon tekenen zij ook de huizen in vanaf de luchtfoto's. Moeten we daar niet nog eens contacten leggen, een presentatie geven ?</div><div>- Waarvoor wil je de gegevens van de gebouwen tekenen ? Hoe groot mag de foutenmarge zijn ? Een dakgoot is volgens mij niet meer dan 1 of 2 pixels. Wat is het fouten percentage als je die volgt ? Het perspectief geeft een grotere fout. Ik wil best meewerken aan de beste kaart, maar gaat het volgen van de dakgoot de kwaliteit van de kaart zodanig naar beneden halen dat ze niet meer bruikbaar is voor je toepassing ?</div><div>- Wat is het nut om een huisnummer op de voordeur van een privé woning te zetten ? Voor deur naar deur routering voor slechtzienden ? Maar dan moet het ook wel echt juist zijn. Een meter of 2 naar rechts of links helpt dan ook niet. Bij grote gebouwen (bedrijven, of evenementshallen) kan ik er nog inkomen, maar dan moet je ook entrance=... erbij zetten. Een huisnummer bij de deur plaatsen is enkel nodig indien er verschillende huisnummers in een gebouw zijn met elk een eigen ingang. En dat kan je enkel weten door een survey.</div><div>- Zijn huisnummers niet belangrijker voor autonavigatie dan de gebouwen ?</div><div><br></div><div>- oh ja, ook nog een +1 voor Glenn's antwoord i.vm. met al dan niet overtekenen van GRB kaart, de mogelijke easter eggs en zijn standpunt dat als alles correct is de 2 kaarten toch gelijk zouden moeten zijn. </div><div><br></div><div>met vriendelijke groeten</div><div><br></div><div>m</div><div><br></div><div><br></div><div> </div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-23 0:15 GMT+02:00 Thomas <span dir="ltr"><<a href="mailto:osm@aptum.nl" target="_blank">osm@aptum.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div>Ik heb nu de laatste variant van de
website van Sander even snel uitgeprobeerd; een dikke twee uur
geleden werkte alles prima, maar het laatste uur krijg ik steeds
een 400: bad-request van JOSM terug op het request vanaf het
js-script, met daarbij “no command specified” (ongeacht welke van
de 4 sets per straat ik gebruik). OSM-data inladen via de
straatnaam werkt perfect. Het vergelijk met OSM werkt wel perfect,
alleen het inladen in JOSM gaat dus fout. Wissen van de cache
heeft geen effect (Firefox 33).<br>
<br>
Uit een aantal snelle eerste vergelijkingen lijken in mijn regio
(Oostende) vrijwel alle adresposities zéér mooi uit te lijnen op
het midden van de gebouwen op de AGIV-luchtfoto. Alle reeds
gemaakte opmerkingen over afwijkende positionering zal volgens mij
vooral gelden voor de meer plattelandsgemeenten. Ik moet het nog
even goed bekijken. In elk geval voor de woonwijken in Oostende
zou ik de adrespunten zeer vlot kunnen verwerken en als punt
importeren, als we het eens zouden zijn dat dat de nu de beste
aanpak is.<br>
<br>
Ik ben het zeker eens met het feit dat de gebouw-contouren hebben
veel 'rijker' is voor de kaart dan puur de adrespositie. Toch vind
ik dat die adrespositie op zichzelf waarde heeft. Volgens alle
richtlijnen van OSM zijn adrespunten, naar mijn idee, zeker de
moeite waard, ook al zijn de bijbehorende gebouwen nog niet
ingetekend. Dat die gebouwen eigenlijk belangrijker zijn dan de
nummers vind ik een terechte opmerking, maar we hebben niet de
beschikking over die gegevens. Daarnaast blijf ik bij mijn eerdere
standpunt dat alle gebouwen intekenen zeer veel werk is, vrij
onnauwkeurig door perspectiefvertekening en schaduwwerking en
buitengewoon frustrerend als over een paar maand de GRB-data
alsnog open zou worden. Ikzelf zie heel vaak af van het intekenen
van gebouwen vanaf de luchtfoto omwille van bovenstaande redenen.
In mijn werkomgeving ben ik ook vaak bezig met data-entry in
GIS-systemen. Ik vind het zeer frustrerend om zo onnauwkeurig te
werken als bij het intekenen van gebouwen vanaf een luchtfoto.<br>
<br>
Daartegenover moet ik zeggen dat ik de GRB-data in mijn regio
volgens mij extreem nauwkeurig is (los van tijdsdiscrepanties).
Volgens mij is die data afkomstig van het kadaster. De moderne
gegevens zijn met professionele GPS ingemeten, de oudste volgens
mij zijn gedigitaliseerd van de analoge kaarten. Kadaster-gegevens
hebben een bijzondere 'rechtspositie'. Volgens mij hangen de
licentie-problemen daar mee samen. De 'eigendom' van die gegevens
is een zeer complexe zaak. De oorspronkelijke data stamt formeel
uit het begin van de 19de eeuw en is daarmee auteursrechtenvrij.
De oorspronkelijke kaarten (ondermeer uitgegeven door Popp en
raadpleegbaar op <a href="http://geopunt.be" target="_blank">geopunt.be</a>) zijn op zich auteursrechtenvrij maar
de scans zijn dat niet. De huidige kadastrale systemen zijn een
directe voortzetting van dat historische systeem. Hoe en wat
precies met rechten op de data is buitengewoon complex.<br>
<br>
Over de workflow: ik vind dat de adrespunten op zichzelf
geïmporteerd mogen worden; ook bij afwezigheid van het gebouw.
Uiteraard moeten de punten wel handmatig 1 voor 1 gecontroleerd
worden met de AGIV-luchtfoto. Een automatische datapomp is een
echte no-go, maar daar lijken we het allemaal over eens te zijn.
Wanneer de situatie niet duidelijk is, kan nog een beroep gedaan
worden op de GRB-gegevens (zonder de contouren over te nemen!) of
bij aanhoudende onduidelijkheid kan survey ter plaatse
noodzakelijk zijn en/of moet van import van de specifieke punt
uiteraard afgezien worden. Wanneer het gebouw aanwezig is (een
relatieve zeldzaamheid, heb ik het idee) mogen wat mij betreft de
adresgegevens op het gebouw getagd worden en mag het punt
verwijderd worden. Dat er dan adressen op gebouwen staan en
anderzijds adressen op punten lijkt mij geen probleem. Uit mijn
eerste testen besluit ik dat ik met deze werkwijze zeer vlot een
regio kan verwerken, zonder onzin-data te importeren. Het aantal
“moeilijke gevallen” is in mijn regio zeer beperkt. Dat kan
uiteraard per regio verschillen.<br>
<br>
Over Bing versus AGIV: Bing zal altijd bekender zijn dan AGIV. Hoe
eenvoudig het ook wordt om de AGIV-luchtfoto te gebruiken: als
'startende OSM-editende leden' ook voor Bing kunnen kiezen zullen
ze dat heel snel doen. Dit als belangrijk punt naar voor schuiven
in de 'how-to-get-started'-lijstjes lijkt mij enkel de drempel te
verhogen. Het is volgens mij belangrijker om de aandacht te
vestigen op de onnauwkeurigheid van luchtofotografie in het
algemeen. De misvattingen over schaduwen, perspectief etc. zorgen
voor een verkeerde interpretatie van de luchtfoto en bijgevolg het
verkeerd aanpassen / corrigeren van wél correct ingevoerde
gegevens. Het klopt dat de voetafdruk van een gebouw haast nooit
netjes uitlijnt met de dakgoot-contour. Die contour is echter wél
heel duidelijk zichtbaar op de luchtfoto. Het is een natuurlijke
reflex om een gebouw-contour te tekenen rond die dakgoot, maar
daarmee nog niet minder fout. Ik ben het wel volledig eens met het
verder promoten van de AGIV-luchtfoto voor Vlaanderen.<br>
<br>
Voor wat betreft de workflow van het importeren van de adressen
kom ik nu tot volgende richtlijnen:<br>
– In de basis altijd het gebouw de adres-tags meegeven. In
principe geen losse adres-nodes, tenzij:<br>
* gebouw nog niet ingetekend maar wel aanwezig op luchtfoto:<br>
→ gebouw intekenen en adres-tags toevoegen OF punt midden
boven gebouw plaatsen.<br>
* gebouw nog niet ingetekend en niet zichtbaar op luchtfoto
maar wel gezien bij survey:<br>
→ adres-punt op gesurveyde locatie plaatsen<br>
– Wanneer er meerdere adressen binnen 1 gebouw zijn:<br>
→ gezamenlijke kenmerken op gebouw taggen, al de rest op de
individuele adres-nodes (“Nederlands systeem”)<br>
– Wanneer er meerdere adressen zich precies boven elkaar bevinden:<br>
→ de adressen individueel registreren als punt, maar de punten
mogen niet op elkaar vallen.<br>
– Over het hoe en wat voor adrespunten zonder locatie zal het
vooronderzoek eerst duidelijkheid moeten brengen<br>
<br>
Over de precieze locatie van de adres-nodes kan gediscussieerd
worden. Zoals Sander voorstelt (het punt op de ingang plaatsen) is
het in veel gevallen logisch. In veel andere gevallen is het
volgens mij lastig om de ingang precies aan te wijzen, zonder
survey. Ik vrees dat in de praktijk veel nodes toch lukraak op het
gebouw zullen belanden. De richtlijn om het punt op de ingang te
plaatsen is dan misschien enkel verwarrend, wanneer het niet
consequent toegepast wordt. Maar daar zijn vast ook heel andere
meningen over...<br>
<br>
Bij de vorige stap naar de import-lijst was er discussie over het
al dan niet gebruiken van een dedicated account. Is er consensus
over hoe hiermee om te gaan? Of is het een kwestie waar we het
niet over hoeven te hebben en gewoon 'de regels' volgen en de
import met een dedicated account uitvoeren?<br>
<br>
Is er verder nu ook consensus over het feit dat de twee tags
(huisnummer en straatnaam) op de node of het gebouw getagd worden
in tegenstelling tot het koppelen van alle huisnummers aan de
straat met een relatie?<br>
<br>
Groeten,<br>
Thomas<br>
<br>
Sander Deryckere schreef op 22-10-2014 21:40:<br>
</div>
<blockquote type="cite"><div><div class="h5">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">Op 22 oktober 2014 20:57 schreef Marc
Gemis <span dir="ltr"><<a 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">Sander, (& anderen)
<div><br>
</div>
<div>ik heb je website daarstraks eens geprobeerd.
Jammer genoeg kreeg ik niets anders dan "Loading".
Niet lang genoeg gewacht ? Server overladen ?
Verkeerde browser ?</div>
<div><br>
</div>
</div>
</blockquote>
<div>Welke browser? Welke postcode (misschien een grote stad
waarbij het niet werkt)? Heb je het net nog geprobeerd
(mogelijks moet je de browser cache legen om de verbeterde
versie van het JS script opnieuw te downloaden)?<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Ik vraag me nu af hoe ik een en ander in mijn
workflow kan inpassen.</div>
</div>
</blockquote>
<div> </div>
<div>Ik ook :D Dat vraagt natuurlijk wat onderzoek en wat
denkwerk. <br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>Het overzicht van wat er al in OSM zit is heel
handig, maar dan zou het resultaat onmiddellijk
zichtbaar moeten zijn. Zou dit kunnen door het script
's nachts te laten lopen en de resultaten te cachen in
een DB ? (sorry maar hier komt mijn achtergrond naar
boven :-) ).</div>
</div>
</blockquote>
<div> </div>
<div>Niet met de huidige code. Alles gebeurt client-side,
wat maakt dat het (eenmaal de kinderziekten verdwenen
zijn) bijna geen onderhoud zal vragen. Als je werkt met
een DB, dan moet er altijd server infrastructuur
onderhouden worden, waardoor er kostbare mapping tijd
verloren gaat.<br>
<br>
</div>
<div>Ik denk ook dat niet in elke gemeente elke dag gemapt
zal worden. Dus is het jammer om elke dag alle adressen te
downloaden, wanneer er misschien hoogstens in 20 gemeenten
per dag a.d.h.v. CRAB data gemapt wordt. <br>
<br>
</div>
<div>Een ander voordeel van live-queries is dat binnen
enkele minuten na het uploaden naar OSM je al het
resultaat zou moeten zien. Dus kan je eenvoudig straat per
straat mappen, zonder dat je er de volgende dag op moet
terug komen om te kijken als je geen fouten gemaakt hebt.<br>
</div>
<div><br>
</div>
<div>Normaal is het laden van de data snel genoeg, en ik kan
de overpass query nog wat verbeteren om het laden nog
sneller te maken (en zal dat zeker doen).<br>
<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div><br>
</div>
<div>De adrespunten in JOSM overnemen, is handig, maar
gaat het mij tijdwinst opleveren (gesteld dat ik nog
steeds eerst een survey doe) ? Ik vrees ervoor. Ik heb
al eens gewerkt met de osmose site vorig jaar en dat
ging niet sneller. Als we de adressen niet op de
gebouwen zouden plaatsen zou er wel een snelheidswinst
inzitten. Dit is een beetje zoals ze het in Nederland
doen. Hoewel je dan in sommige gevallen toch nog het
adres op het gebouw moet plaatsen, bv. bij
supermarkten waar de POI gegevens op het gebouw gezet
worden.</div>
<div><br>
</div>
</div>
</blockquote>
<div>Ik kan niet meer data aanbieden dan we van AGIV krijgen
;)<br>
<br>
</div>
<div>Ik weet ook niet als het sneller zal gaan, maar ik denk
dat met de CRAB data slechts onvolledige surveys zouden
nodig zijn.<br>
<br>
Door een routine te creëren zal je zien waar er problemen
kunnen zijn met de CRAB data (zeker al met de punten die
geen positie hebben), en specifiek die probleemplaatsen
gaan opzoeken. Ik denk, als je begint met een volledige
survey, zonder CRAB data, dan kom je thuis, zie je dat er
op sommige plaatsen nog onduidelijkheden zijn, en moet je
nog eens terug. Deze eerste survey zou kunnen vermeden
worden door eerst de duidelijke CRAB data te importeren.<br>
<br>
</div>
<div>Een andere tool die we kunnen gebruiken (weet niet als
deze al bestaat), is een tool om "probleemplaatsen" te
markeren. Een soort geografische TODO lijst. Ofwel gedeeld
of persoonlijk. Zodat we aan de computer, tijdens de
initiële CRAB import, deze probleemplaatsen eenvoudig
kunnen markeren en vergeten, om dan later alle plaatsen te
gaan bezoeken.<br>
<br>
</div>
<div>Deze tool is moeilijker te maken, omdat het afhangt van
de mapping voorkeuren (mappen op papier, met Android, met
iPhone, ...). Dus hoop ik dat er al ergens een bruikbaar
systeem bestaat dat we gewoon kunnen gebruiken.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>Ik had de indruk dat Sus ongeveer hetzelfde
schreef. een huisnummer toevoegen in JOSM is 2 kliks
(HouseNumberTool plugin CMD-K/CTRL-K of
terracer-tool).</div>
<div><br>
</div>
</div>
</blockquote>
<div>Daarom laat ik het downloaden als extra layer. Dan kan
je die (met een aangepast stylesheet) ook als
achtergrondlaag gebruiken, en zelf je eigen gegevens
ingeven. Na het mappen is de laag eenvoudig te
verwijderen. Daarnaast blijft mijn tool nuttig als
controle na het mappen.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div dir="ltr">
<div>Hoe zien jullie dat ? Hoe kunnen we het harde werk
van Sander het beste gebruiken ?</div>
<div><br>
</div>
<div>met vriendelijke groeten</div>
<span></span></div>
</blockquote>
<div><br>
</div>
<div>Opmerkingen zijn altijd welkom.<br>
<br>
</div>
<div>Groeten,<br>
</div>
<div>Sander <br>
</div>
</div>
<br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div></div><span class=""><pre>_______________________________________________
Talk-be mailing list
<a href="mailto:Talk-be@openstreetmap.org" target="_blank">Talk-be@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
<br></blockquote></div><br></div>