Idee om wat met BAG te gaan doen

De ervaring leert anders. Ik kan naar alle straten in NL toe navigeren met OSMAND, maar er worden meestal alleen kruisende straten getoond in het keuze menu van de functie “zoeken”. Huisnummers zie ik alleen bij straten waar huisnummers zijn toegevoegd aan OSM. Die verschijnen in het keuze menu i.v.p. de kruisende straten. Maakt voor de navigatie niet uit of die nummers aan een gebouw hangen of aan een point.

In het weergeven op de kaart in OSMAND zit echter wel verschil. Dat heeft te maken hoe de gegevens in OSM ingevoerd zijn. Als de adresgegevens aan het gebouw hangen worden de nummers wel weergegeven op de kaart, maar als de adresgegevens aan een point hangen zie je ze niet. Voor de navigatie maakt het niks uit of het nummer zichtbaar is of niet, maar als je de huisnummer zichtbaar wilt hebben op de kaart in OSMAND, moet je wel aan bepaalde voorwaarden voldoen. Je komt daar pas achter na een update van je kaart in OSMAND. Online bij openstreetmap.org zie je het verschil niet.

zie http://kiekkast.nl/OSM/

René.

René, voor specifieke Osmand bugs zou je je vragen beter kunnen droppen op het forum van osmand: https://groups.google.com/forum/#!forum/osmand
Dan kunnen de ontwikkelaars er wat mee doen.

Nog altijd geen antwoord gehad op mijn vraag waarom de import tool niet de gebouwen tagged i.p.v. losse punten.

Juist, daarom ben ik er ook over begonnen. Het zou mooi zijn als de import tool dat gelijk doet.

@richardbrinkman en rivw

Op http://wiki.openstreetmap.org/wiki/BAGimport en de bijbehorende discussiepagina zie je de weergave van de meeting die afgelopen november plaatsvond waar de plaatsing van adresnodes onderdeel van was. Gegeven de structuur van de BAG (adressen logischerwijze op verblijfsobjecten) en de precisie van de plaatsing van de verblijfsobjecten in de BAG is toen besloten om bij de import de coördinaat van het verblijfsobject intact te laten. Dit laat onverlet om na de import bij bijvoorbeeld een POI waar sprake is van één gebouw en één verblijfsobject de info uit het verblijfsobject op de gebouwcontour te zetten, waarbij tegelijk de ingang wordt aangegeven met entrance=main. Ik heb dat zelf diverse keren gedaan, maar dan had ik wel kennis (‘ground truth’) over de werkelijke positie van de ingang.

Over osmand: ik ga geheel mee in de opvatting van ligfietser. osmand is een renderer, die net als Mapnik in staat zou moeten zijn om losse adresnodes weer te geven

Er zijn nog plaatsen beschikbaar voor de workshop op 8 maart in Duivendrecht. Je kunt daar aan de slag met de - in mijn ogen - meest geavanceerde JOSM plugin wereldwijd qua importeren van adressen en gebouwen

Hoe gaat de importtool om met flatgebouwen. Komen er dan tientallen nodes op elkaar te liggen, ofzo? Dat lijkt me namelijk voor een renderer nogal lastig om daar nog iets fraais van te maken.

Heb je die link die Ligfietser gaf wel goed bekeken en het aparte Netherlands Address (= BAG) bestand voor Osmand gedownload? Zo ja zie je dan in je zoekscherm bij Regio zowel Netherlands als Netherlands Address? Die laatste moet je hebben en die toont bij mij gewoon alle huisnummers.

Goeie opmerking. Dat is precies het punt wat momenteel de meeste aandacht heeft. Daar wordt aan een (technisch uitvoerbare) oplossing gewerkt.

Je zou dat als je de gebouwen tagged in plaats van de nodes heel elegant kunnen oplossen in de importtool. In pseudocode:


foreach bag_address_node as $node do
    if $node has surrounding building $building then
        foreach bag_address_node in $building as $other_nodes do
            convert $other_nodes to nice interpolation (min, max, even/odd)
            tag $building with that interpolation
    else
        add osm node with info from $node

't Zal dus ietsiepietsie lastiger voor de ontwikkelaar van de import plugin, maar zorgt er wel voor dat niet ieder gebouw met de hand hoeft te worden gecontroleerd. En ik blijf erbij dat het semantisch netter is om het gebouw te taggen als een willekeurig punt in het gebouw die ook verder geen relatie heeft met het gebouw.
En beter iets meer werk gestoken in een import tool, dan een import tool waarna nog heel veel handwerk nodig is om nodes aan gebouwen te gaan koppelen.

Inderdaad PeeWee. Het werkt. Alle huisnummers in beeld.

Ik realiseer me nu dat ik me met een item bemoei waar al maanden over gediscusieerd wordt. :smiley:

René.

@richardbrinkman Op http://www.openstreetmap.org/user/lxbarth/diary/20261 staat een interessante discussie over het plaatsen van de adresnodes, waarbij ik de bijdrage van Vincent de Phily erg volledig vond. Ik ontken overigens zeker niet dat het semantisch netter is om de adresnode op een gebouw te hebben. Maar daar is dus niet voor gekozen in november omdat je dan nuttige informatie automatisch weggooit, te weten de positie van de ingang.

@allen Ik heb een signaal ontvangen van een overigens zeer ervaren mapper dat de huidige BAGimport te ingewikkeld zou zijn voor beginners. Ik ben benieuwd naar jullie ervaringen.

Ik kan me deze opmerking heel goed voorstellen. Als alle stappen door 1 en de zelfde mapper uitgevoerd moeten worden zullen beginners vermoedelijk snel afhaken. Onder andere om deze reden heb ik al eens voorgesteld om de taken wat te verdelen.

Stel dat een beginnende mapper zijn stad van BAG panden voorzien zou willen hebben maar hij dat zelf te ingewikkeld vind om te doen dan kan me een volgend scenario voorstellen.

  1. Deze beginnende mapper zorgt dat hij met JOSM alle relevante validaties opgelost voordat de import begint. Dat lijkt me ook voor een beginnende mapper te doen.
  2. De ervaren mapper verwijdert de oude panden, zet de nieuwe BAG panden erin en zet relevante oude tags over op de nieuwe panden.
  3. De beginnende mapper lost vervolgens alle verlangde validaties op (bv wegen die door huizen/schuurtjes blijken te lopen, en kruisende gebouwen, gebouwen binnen gebouwen) . Dit laatste kan best veel werk zijn maar is over het algemeen genomen niet echt heel erg ingewikkeld. Commodoortje heeft hier al een aantal verhelderende video’s van gemaakt

Ik reken mezelf even als ervaren mapper en zou het helemaal geen bezwaar vinden om voor (een deel van) een stad stap2 uit te voeren als ik een afspraak maak met een beginnende mapper die de stappen 1 en 3 voor zijn rekening neemt.

Ik weet dat de DWG als eis heeft dat de stappen 2 en 3 eigenlijk tegelijkertijd uitgevoerd zouden moeten worden maar ik kan me ook niet voorstellen dat als we met een goed plan komen om taken te verdelen ze daar voor blijven liggen.

Oops, dat bedoelde ik niet Peter. Waar het hem om gaat is dat het voor een beginner lastig is nadat de BAGimport heeft plaatsgevonden. Er is immers logischerwijze meer data in de database, waardoor een beginner het lastig zou kunnen vinden om bijvoorbeeld een POI toe te voegen met de editors iD en Potlatch. Eigenlijk ben ik via deze oproep dus op zoek naar een beginner die in een reeds geïmporteerd BAG gebied een edit uitvoert :smiley:

@ allen; als je graag de BAG adressen en gebouwen in je woonplaats wilt maar liever niet zelf de (gehele) import uitvoert, geef dat dan svp via dit forum aan. Het proces dat Peter aandraagt is dan een goede mogelijkheid. Maar ook als je geen JOSM gebruikt is het mogelijk om gezamenlijk je woonplaats te voorzien van adressen en panden.

Dat was een mooi voorbeeld van krommunicatie :wink:

Maar de BAG nodes staan toch helemaal niet bij de ingang? Ik heb lang en breed gezocht naar een BAG node die bij de ingang zou staan, maar er geen enkele gevonden. De meeste nodes staan gewoon midden in een gebouw. Sommigen zijn weliswaar wat verschoven, maar echt niet waar de ingang zit. De preciese locatie van de BAG nodes is dan ook niet iets wat we koste wat kost zouden willen bewaren, toch?

Uit het merendeel van de discussie die jij citeert blijkt ook dat de conventie is om het gebouw te taggen en niet een losse node. Het argument van "One Feature One OSM Element (http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element) vond ik ook een heel sterke. Met de importtool zeggen we hier definitief vaarwel tegen. Aangezien we dan 2 elementen hebben per gebouw:

  • de building-way, die de contour aangeeft en tags heeft om de hoogte en het aantal verdiepingen aan te geven.
  • de losse adres node, die postcode, huisnummer en straatnaam draagt.

Dit druist in tegen de regels van OSM. Ik citeer:

Zijn dit soort argumenten in november besproken en toch besloten voor de adres nodes i.p.v. buildings?

Het is natuurlijk nooit verkeerd dat problemen in OSM opgelost worden. Ik schaar me nog onder de groep “beginnende” JOSM gebruikers. En heb inmiddels redelijke ervaring opgedaan. Natuurlijk zijn er nog veel vragen. Vandaar dat ik alleereerst het compliment uit wil brengen naar de vele leden van dit forum die op een zeer nette en heldere manier uitleg geven bij beantwoording van de vragen. Ik ken fora waar dit wel anders is. Een compliment waard om het nog eens te vermelden.

Mocht de opschonende mapper dan vragen hebben over de validator check, dan kan deze haar vragen in het hiervoor aangemaakte topic dit aangemaakte topic stellen.

@richardbrinkman enkele voorbeelden waarbij je nuttige info weg zou gooien als je automatisch de nodes merged met de contour: http://www.openstreetmap.org/?mlat=51.99471&mlon=4.39765#map=17/51.99471/4.39765
http://www.openstreetmap.org/#map=19/52.03563/4.38521

Imports worden bediscussieerd op @import. Daar zitten mensen bij die alle regels van OSM uitstekend beheersen (onder anderen de DWG’ers). De discussie waar ik je naar verwees op de dagboekpagina van Alex Barth is een onderdeel geweest van een discussie op de importlist over de NYC import. Die discussie eindigde in een gelijkspel tussen voor - en tegenstanders van losse adresnodes / adressen op de contour. Ons besluit uit november is ook op de importlist behandeld. Er werd daar geen probleem van gemaakt dat we in NL de losse adresnodes importeren. De importlist had wel problemen met twee andere zaken, namelijk de ref:bag op de gebouwcontour en de sourcetags.

@Peewee, alle relevante validaties oplossen? Wat bedoel je precies hiermee? Dat is voor de doorgewinterde mapper al niet eens meer te volgen.:smiley:

Ik wilde daar nog even niet over uitwijden omdat het niet relevant is voor de voorgestelde methode. (de 3 punten) Met relevant bedoelde ik eigenlijk te zeggen de voor de import door de DWG verlangde validaties dus zeker niet alle. Daar moet ik al helemaal niet aan denken :open_mouth:

Edit: Bedenk me opeens dat je misschien wel iets anders bedoelt. JOSM kent een zgn validator die Errors en/ of waarschuwingen geeft . Een aantal daarvan zijn voor de BAG import van belang en zouden langs gelopen moeten worden maar zeker niet allen.
Die validator is een leuk tool voor de liefhebbers die hun stadje helemaal tip top willen krijgen in OSM. Daar kun je best wat avondjes mee vullen.