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 <o...@aptum.nl>: > 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) 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 <marc.ge...@gmail.com>: > >> 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 > listTalk-be@openstreetmap.orghttps://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
