Adrestags, mogen we daar aankomen?

Bij de BAG import zijn ook alle adrestags meegekomen, en mijn vraag is of ik aan zo’n adrestag wat mag toevoegen?
Nu ik bezig ben met al die amenity en shop tags, zou het praktisch zijn om aan zo’n adrestag ook de overige eigenschappen van dat adres toe te voegen.
Dus als ik het adres van de bakker weet, mag ik dan aan die adrestag ook shop=bakery vastmaken?

Dit mag, is misschien ook wel de bedoeling.

Het mooiste zou zijn dat alles op 1 gebouw met 1 adrestag, alle keys zoals shop=* op het pandcontour gemerged worden.
(CTRL+SHIFT+G met de Utillities2 plugin geinstalleerd)

De meningen lopen op het samenvoegen uiteen, omdat bij een volgende import een automatisch proces zou kunnen bemoeilijken.
Het is aan de plugin maker (gert jan) de mooie taak om zijn plugin hierop aan te passen. En in de gevallen dat het niet volledig in de plugin aan te passen is, is het noodzaak om de extra handelingen te verrichten om de extra aangebrachte tags te behouden.

Persoonlijk vind ik (in JOSM) het mooier dat een bv shop=* een uit een losse node bestaat, dan valt hij in JOSM namelijk meer op. Maar zoals ik de fora gevolgd heb omtrent dit onderwerp is het meer gewenst om alles op de pandcontouren te zetten (nogmaals: alleen als het pand 1 adresnode heeft)

Interessante discussie, en zal dit lijntje blijven volgen om misschien wel een consensus te bereiken.

Het lijkt me aardig om de voor- en nadelen eens op een rijtje te zetten, zodat er begrip opgebracht kan worden om de noodzaak (of juist niet) van alles op de pandcontour uitgelegd te krijgen in dit draadje.

Ik ben van mening dat het beste is, dat alles los staat.

Ik heb nog weinig fora gezien waarbij men zegt dat het gewenst is.

De vraag van Marc ging over de losse adresnode, of hier toevoegingen op mogen plaatsvinden.

Dit heeft (volgens mij) als voordeel dat bij gezochte informatie, ook de adresgegevens meekomen. Als de informatie is toegevoegd op de adresnode wel te verstaan.
Het is dus zeker toegestaan om aanvullingen op de adresnode te plaatsen.

Daarnaast vind ik de discussie interessant omdat ik de voor- en nadelen niet ken om alles op de pandcontouren te zetten.

Tijdens de BAG import is een passage opgenomen in de handleiding in STAP 2, derde puntje na G.

Bij één POI/één gebouw mag je eventueel alle tags inclusief het adres op de outline zetten (CTRL-SHIFT-G), maar voeg dan de tag entrance=main toe bij de ingang

Dit heb ik als handvat gebruikt in algemene zin, soms heb je namelijk meer shops in één winkel, denk bijvoorbeeld aan een Bruna, waar naast boeken, ook kranten, TNT post balie, ING agentschap en een Geldautomaat kunnen huisvesten. Zoiets red je (volgens mij) niet als je alles op een pandcontour gaat zetten. In zulke gevallen gebruik ik meerdere nodes om in het voorbeeld de mogelijkheden wel te benutten.

In mijn beleving is er op het Netherlands gedeelte ook regelmatig over gesproken, en hiervan is mij bijgebleven dat het zeker voordelen heeft om alles op het pandcontour te mergen.
Misschien kan iemand die hierover de ins- en outs weet iets over schrijven.

Het antwoord, dit mag, had jij al gegeven.

Ging verder in op de discussie, gewenst.
In je quote, “mag je eventueel”, dit vertaal ik niet als meest gewenst, eerder het omgekeerde.
Alles wat we taggen, waar en hoe, moet een render uit elkaar trekken/samenvoegen tot, plaatsen op kaart, op een voor hem gewenste plaats, verwerken in tabellen.
een shop en amenity op een pand of node moet uit elkaar getrokken worden om beide zichtbaar te maken op een gewenste plaats. De tagger weet in het gebouw op welke plaats deze activiteit het meeste plaats vind.

Zo ook bij adresnode en shop, wil je beide zichtbaar hebben op de kaart, wij de tagger en eindgebruiker hebben wel voorkeur hoe wij het willen zien.
Ik zie graag een kaart met adresnummer zichtbaar en de poi. Niet op elkaar.

In de zwaardere tagvoorbeelden moet de render al de poinode voorzien/combineren met een adresnode of een adrespandway tag, de render moet al twee methoden onderhouden. Ze kunnen niet het ene of het andere doen, want beide zijn tagmethode binnen OSM.

Waarom in de lichter tagvoorbeelden het anders doen als in de zwaardere tagvoorbeelden.

Ik kan me een ding bedenken, men wil (de tagger die ook eindgebruiker is) dat de school het vlak, gebouw, een andere kleur krijgt op de kaart, herkenbaar als school op de kaart.
Maar de render kan dat toch ook verzorgen als de school op één node in het gebouw staat. Het is de renders keuze.

En vaak wordt alleen het resultaat beoordeelt op de Mapnik OSM kaart. Het staat niet als vlak op die kaart dus het moet op het gebouw. Kan een redenatie zijn.

Komt er een poi bij in, een gebouw half school half shop, dat moet de tagger de school weer van het gebouw halen met de nodige tags. En de shop vraagt een nieuw huisnummer aan.

Wij kunnen de render nog een beetje helpen door, associated_adress te taggen, dan is dan nog een methode waaraan de render zich moet gaan houden, helpen we hem daar mee of niet.
Dit is wel een hulp als een activiteit buiten een gebouw ligt en tot dat adres behoort. De schakel.

Ik verduidelijk nog even mijn vraag:
(Ik schreef trouwens adrestag waar ik feitelijk adresnode bedoelde!)

Dit is de situatie:

(http://www.openstreetmap.org/#map=19/51.64549/5.28306)

Het gaat me om het toevoegen/plaatsen van die Boulangerie Goossens.

Toevoegen/samenvoegen aan/met die pandcontour kan hier niet want in dat pand zitten 10-tallen andere bedrijven en woonhuizen.
Blijft over dat ik de oplossing kies zoals die er nu uitziet (2 afzonderlijke nodes), óf dat ik die twee tags die nu de bakkerij markeren, toevoeg aan die adresnode.
Eigenlijk heeft dat laatste mijn voorkeur, omdat dan met minimale middelen een mooie, duidelijk situatie ontstaat.

Als je naar een geocoder kijkt (en niet naar een renderer), dan kan niet niets aanvangen met afzonderlijke POI en adres node. Dus kan je de POI niet aan het adres koppelen. Of de geocoder moest een nabij adrespunt mogen gebruiken, wat in sommige gevallen dan weer tot de verkeerde keuze zou leiden.
Ik tag dus eerder zodat niet-render software er iets kan mee aanvangen. Mij maakt het niet uit of de renderer er nu een icoontje en een nummer zet of niet. Als het adres van de POI maar kan gevonden worden. (dus andere insteek dan Allroads die alles los wil en beide op de standaard kaart wil zien)

Dus voor eenvoudige programma’s : POIs en adressen op 1 node of vlak.
voor slimmere programma’s : POIs zonder adres in gebouwen met adres (bv. Nominatim) kunnen ook.

Regel die dikwijls terugkomt: POI op gebouw als er geen andere activiteit in het gebouw is. Typisch bij een supermarkt. POI in gebouw als er bv. naast een winkel ook een woongedeelte is. Maar dan krijgen die in Nederland toch afzonderlijk huisnummer, niet ?

Eens

Marc, een zijspoortje nav van het bedrijfsverzamelgebouw, is iemand daar ooit een OSM term voor tegengekomen ?

Niks moet in OSM, maar alles “los” op nodes, betekent wel dat het praktisch bezien moeilijk wordt om nog specifieke kleuren / rendering aan panden / polygonen van gebouwen te hangen. Ja, er worden wel eens op de Github openstreetmap-carto code repository vergaande voorstellen gedaan om zaken als “punt-in-polygoon” of “intersect/union” GIS achtige analyses uit te voeren om een bepaalde geavanceerde rendering te bereiken, maar praktisch bezien levert dit veel hoofdpijn op. Werken met wereldwijde data in een tientallen of misschien wel honderden gigabytes grote database, maakt dat tot een aardige nachtmerrie qua processing…

Nu is het zo dat specifieke rendering van gebouwen m.b.v. kleuren, mede daarom denk ik, nog nauwelijks wordt toegepast in OSM, OSM Standard rendert bijna alle gebouwen bruin. Maar in mijn ArcGIS renderer, blijkt daar toch ook wel nog wat mogelijk. Echter, niet als alles op de nodes hangt…

Mijn renderer pakt alleen de info op de gebouwcontouren, OF rendert voor een kleine selectie van belangrijke “amenities” en “tourism” features, een icoon op de node met de info, maar ik voeg zeker niet via “punt-in-polygoon” analyses de data samen…

Kortom: ik ben wel een voorstander van “op de gebouw” contour, tenzij het echt om een multifunctionele brij gaat van functies in 1 gebouw, waarvan geen chocolade meer is te maken zonder aparte nodes. Zelfs in dat geval, zou ik toch ook liever zien dat in ieder geval de hoofdfunctie van het gebouw (er vanuit gaande dat die er is), op de gebouwcontour wordt geplaatst, en dan eventuele nevenfuncties op aparte nodes, maar dus liever niet een “functieloos” gebouw bestaand uit niets dan een loze contour…

Zoveel mogelijk op de gebouw contour sluit ook beter aan op de gedachte van “One Feature, One OSM Element”:

http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element

Gelet op alles wat je schrijft Marco, heb ik nog een vraag die je mogelijk kunt beantwoorden:

Zie deze situatie:

Daarbij horen één pandcontour en 2 nodes:

http://www.openstreetmap.org/way/272337026 (pandcontour)
http://www.openstreetmap.org/node/2772771504 (adresnode)
http://www.openstreetmap.org/node/3229936461 (infonode)

Ik zou zelf de infonode en de adresnode samenvoegen, maar dan staat er dus niets op de pandcontour zoals jij dat liever zou hebben.
Of stel jij voor om in dit geval (er is slechts één adresnode) alledrie samen tevoegen?
Kun je dat nog even verduidelijken?

Persoonlijk zou ik de pandcontour en de adresnode samenvoegen. Dit is ook de standard manier van werken in België. In Denemarken mag dat dan weer niet.

Als de “boulangerie” de volledige ruimte van het pand in beslag neemt, zet ik hem ook op de contour. Anders hou ik hem afzonderlijk en herhaal ik de adresinformatie op de infonode.

Ik sluit mij grotendeels aan bij wat escada hier schrijft. Echter, het herhalen van de adresinformatie zou niet mijn voorkeur hebben, dit levert alleen meer weer ruimte-verslindende doublures op bij labeling in de kaartweergave, en ruimte om labels en iconen te plaatsen zonder overlapping is al zo beperkt. Dit is echt een kostbaar goed… Alleen als het een “sub-” adres is, zoals 15A of 15B, dan zou ik het apart opnemen.

En daar ligt de flessenhals:

Twee manieren van taggen, BE/BK, met nog een vertakking van meervoudig adres op nodes mogelijk.

Als renders het niet doen om, via “punt-in-polygoon” analyses de data samen te voegen, wanneer nodig, dan zullen de taggers hun eigen gang gaan en voegen aan elke punt adressen toe voegen. Deze poi hoort bij dat adres.

Als het alleen bij simpele direct rendering blijft, zie ik de gevolgen.

Ik loop ook met die overweging rond, om alles los te taggen, en dan elke poi node zonodig van een adres te voorzien.
Vandaar dat ik nog weinig poi heb getagd. Ik vind het een dilemma.

Dubbele adressen veel werk, dubbele namen op kaart, renders maken een tegenbeweging om dat vereffenen.
Of je “punt-in-polygoon” analyse, geen dubbele namen-adressen, op kaart.

De sleutel-oplossing ligt bij de renders hoe de taggers gaan taggen.

Praten deze renders wel met elkaar,…om tot een lijn te komen of zijn ze nog ieder voor zich bezig.?

Recentelijk ben ik wel aan het afstappen van het idee om het adres dubbel te taggen, omdat Nominatim het al juist oplost. De anderen zullen dan wel volgen of doen het misschien al, maar je ziet daar niets over verschijnen. Je moet het allemaal maar zelf uitvissen.