Een allegaartje van antwoorden en opmerkingen:
- 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.
- 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
- 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.
- Het kadaster is volgens mij niet rechtsgeldig (zie bv
http://bouwinfo.be/forum/threads/136644-buurman-zet-afsluiting-1-5m-over-de-scheidingslijn/page2
)
- 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 ?
- 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 ?
- 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.
- Zijn huisnummers niet belangrijker voor autonavigatie dan de gebouwen ?
- 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.
met vriendelijke groeten
m
2014-10-23 0:15 GMT+02:00 Thomas <[email protected] <mailto:[email protected]>>:
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).
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.
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.
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 geopunt.be <http://geopunt.be>) 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.
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.
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.
Voor wat betreft de workflow van het importeren van de adressen
kom ik nu tot volgende richtlijnen:
– In de basis altijd het gebouw de adres-tags meegeven. In
principe geen losse adres-nodes, tenzij:
* gebouw nog niet ingetekend maar wel aanwezig op luchtfoto:
→ gebouw intekenen en adres-tags toevoegen OF punt midden
boven gebouw plaatsen.
* gebouw nog niet ingetekend en niet zichtbaar op luchtfoto
maar wel gezien bij survey:
→ adres-punt op gesurveyde locatie plaatsen
– Wanneer er meerdere adressen binnen 1 gebouw zijn:
→ gezamenlijke kenmerken op gebouw taggen, al de rest op de
individuele adres-nodes (“Nederlands systeem”)
– Wanneer er meerdere adressen zich precies boven elkaar bevinden:
→ de adressen individueel registreren als punt, maar de punten
mogen niet op elkaar vallen.
– Over het hoe en wat voor adrespunten zonder locatie zal het
vooronderzoek eerst duidelijkheid moeten brengen
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...
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?
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?
Groeten,
Thomas
Sander Deryckere schreef op 22-10-2014 21:40:
Op 22 oktober 2014 20:57 schreef Marc Gemis <[email protected]
<mailto:[email protected]>>:
Sander, (& anderen)
ik heb je website daarstraks eens geprobeerd. Jammer genoeg
kreeg ik niets anders dan "Loading". Niet lang genoeg gewacht
? Server overladen ? Verkeerde browser ?
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)?
Ik vraag me nu af hoe ik een en ander in mijn workflow kan
inpassen.
Ik ook :D Dat vraagt natuurlijk wat onderzoek en wat denkwerk.
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 :-) ).
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.
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.
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.
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).
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.
Ik kan niet meer data aanbieden dan we van AGIV krijgen ;)
Ik weet ook niet als het sneller zal gaan, maar ik denk dat met
de CRAB data slechts onvolledige surveys zouden nodig zijn.
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.
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.
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.
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).
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.
Hoe zien jullie dat ? Hoe kunnen we het harde werk van Sander
het beste gebruiken ?
met vriendelijke groeten
Opmerkingen zijn altijd welkom.
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
