Nogmaals: meerdere objecten op één adresnode (datastapelingen)

In het verleden al meerdere keren ter sprake gekomen (zie ook de relevante links onder deze post):

Hoe taggen we de situatie waar op één node feitelijk meedere (verwante) zaken moeten komen te staan? Denk bv. aan de situatie waarbij je meerdere telefoonnummers wilt tonen bij een bedrijf. In feite praten we hier over meerdere waarden voor één sleutelveld.
Een probleem daarbij is dat het renderen van dergelijk gegevens niet goed gaat. Als je bv. opgeeft dat iets zowel een bar alswel een restaurant is, dan zou je willen aangeven:

amenity=bar;restaurant

Heel duidelijk voor mij om te lezen en te begrijpen en dataconsumers kunnen met die syntax (waarden gescheiden door een “;”) ook overweg. Maar de renderers die er nu zijn raken van slag en laten helemaal niets zien! Daarover is trouwens op diverse andere fora en mailinglijsten ook al vaker gesproken.
Soms zie je het ook zó:

amenity_1=bar
amenity_2=restaurant

Maar ook dat rendert niet goed.

Het probleem dat ik nu tegenkwam zie je hier:

afbeelding 1:

Waarom komt dat adresnummer “4” drie keer voor op dat gebouw?

Eens kijken met OpenPoiMap wat daar zit:
afbeelding 2:

Het blijken 3 bedrijven te zijn die alledrie op hetzelfde adres zijn gevestigd: Oude Hoogeveensedijk 4 in Dwingeloo. Die bedrijven zijn weliswaar gerelateerd, maar hebben toch alledrie een eigen website en dienen andere doelen en doelgroepen. Maar ze zijn alledrie gevestigd op nummer 4.

afbeelding 3:

**afbeelding 4:
**

Verder onderzoek leert dat de BAG import (van Allroads) later is aangevuld door (hit and run) mapper Michel Arts.
Hij heeft daarbij op de oorspronkelijke adresnode de gegevens van een bedrijf toegevoegd, en daarna voor de twee andere bedrijven nogmaals twee adresnodes aangemaakt.
Je ziet nu 3 keer adres met nummer “4”, maar je ziet nog steeds niets meer in de standaardrendering omdat de tag office=research niet wordt gerenderd. Bovendien ontbreekt de name=* tag.

De beste oplossing voor dit moment lijkt mij:

  1. Verwijder de adresgegevens van de overbodige adresnodes (de BAG import blijft dus staan, maar krijgt alleen wat toegevoegd)
    2. Voeg de name=* tag toe aan alle drie de nodes.

Daarmee verdwijnen de overbodige (gedupliceerde) adressen. Een nadeel daarvan is dus dat de adresinformatie van die 2 bedrijven (in afbeelding 3 en 4) dus weer van de kaart (en uit OpenPoiMap) verdwijnt.

Andere oplossingen denkbaar?

Relevante forum links:
https://forum.openstreetmap.org/viewtopic.php?id=28864
https://forum.openstreetmap.org/viewtopic.php?id=27834
https://forum.openstreetmap.org/viewtopic.php?id=30430&p=3 (post #70)

====
Edit: name=* was wel aanwezig.
Edit2: typo

De name=* tag moet er inderdaad absoluut bij.

Ik zou wel de adresinfo bij de ‘duplicaten’ laten staan; die info lijkt me toch erg relevant. Eventueel de BAG-tags bij de ‘duplicaten’ verwijderen.

Die zijn er niet want die extra adresnodes zijn juist door de andere mapper geplaatst.

http://wiki.openstreetmap.org/wiki/Proposed_features/associatedAddress
Met ook andere oplossing modellen.
De uiterste oplossing
relatie met type=associatedAddress

Voor meerdere bedrijven of activiteiten van een bedrijf.

want name=x;y amenity= a;d wat hoort bij elkaar,werkt niet.
one feature one element

Meerdere nodes of building:part intekenen.

BAG Import afspraak

Voorkeur adres op node

Met relatie klaar voor de toekomst?

nog niet gebruikt
https://taginfo.openstreetmap.org/relations/?rtype=associatedAddress

Mapper bepaald de combinatie.

Ik kwam met tagging tegen postadres en bezoekadres.
Acquisitie niet gewenst.

Dat was niet zo, maar door de opmerkingen van Allroads heb ik eens gekeken of de oplossing met een relatie werkbaar is.
Dat heb ik nu gedaan, alhoewel de relatie “associatedAddress” nog niet wordt ondersteund (de proposal is van 2011!) heb ik hem toch maar toegepast. Er zitten wel meer dingen in de OSM database die (nog) niet worden ondersteund.
In JOSM ziet het er nu zo uit (wat precies de Rol moet worden weet ik ook nog niet):

Op de kaart blijft nu gewoon 1 keer het adres met nummer 4 staan maar de gegevens van de bedrijven zijn ook nu nog niet zichtbaar en in OpenPoiMap zie je wel de bedrijven, maar de adresgegevens kunnen nu niet worden gevonden. Dat is ook logisch omdat het relatietype totaal onbekend is…

Ik ga daar nog wat experimenteren, dus als je soms wat raars ter plekke op de kaart ziet verschijnen, dan ben ik dat…

Update 2020: associatedAddress was het oorspronkelijk voorstel. Na overleg is dat het goed werkende/renderende associated_address geworden.

De rendering van de office=* tag is het probleem, want die bestaat namelijk nog niet.
Zelfs de naam van een met office=* getagd object wordt niet gerenderd! Maar als er een huisnummer aanwezig is, dan wordt dat getoond! Een merkwaardige beslissing die, zoals je in de discussies kunt lezen, tot meer dubbele vermeldingen aanleiding heeft gegeven.

Carto Style is er wel mee bezig, hier en hier.

Mijn voorkeur zou uit gaan naar meerdere nodes.

Building:part kan als je weet hoe de gebouwenindeling is, maar dan moet je het gebouw in.
En bij een hotel kan er nog een openbaar restaurant en cafe in op een verschillende verdieping zijn.

https://wiki.openstreetmap.org/wiki/Proposed_features/associatedAddress
De verschillende manieren van taggingsmogelijkheden, zie voorbeelden, heeft als gevolg dat renders en database verwerkers, verschillende verbindingsmechanismen moeten ontwikkelen, met als laatste de volledigste een relatie mechanisme.

Hierbij kan je ook een activiteit buiten het gebouw of in een bijgebouw koppelen aan de adresnode in het gebouw.
Wat bij andere mechanismen, moeilijk/onmogelijk kan zijn.

Die link had je al gegeven, maar die proposal is uit 2011, en de indiener daarvan heb ik ook gesproken, maar hij is niet erg actief meer op OSM laat hij me weten.
Omdat die proposal gewoon helemaal stil ligt, gebeurt er ook niets aan verdere ontwikkeling op dat gebied en kunnen we van alles ermee doen, zoals gebruiken op de manier zoals voorgesteld en door mij toegepast in de betreffende situatie zoals eerder beschreven, maar ik kan net zo goed een relatie aanmaken en die schoenzool noemen, maar dat rendert ook voor geen meter!

Ik zal de zaak eens aankaarten op de tagging-list, misschien zijn er mensen die er iets in zien…

Maar feitelijk is het veel belangrijker dat er een goede rendering van de office=* tag komt, want wat we nu ook aan offices taggen, ze zijn niet zichtbaar op de kaart.

Deze 3448 offices (in Nederland) [overpass] staan wel in OSM maar niet herkenbaar op de kaart, anders dan met hun huisnummer:

Het ministerie van Buitenlandse Zaken is bv. niet te zien! [link naar kaart]

Voor veel mappers is een relatie best lastig om te maken/onderhouden.

Helemaal mee eens om (nogmaals?) een verzoek te doen tot rendering van de office=* tag.
Weet iemand of dit al weleens is aangevraagd?

Math1985 weet jij of het kans van slagen heeft?

Zie mijn post #6 onderaan.

En nog een andere situatie met soortgelijke problemen:

Het Singer gebouw in Laren.

Ik was er vandaag en na de recente verbouwingen en uitbreidingen is het volgende van toepassing:

Er is één adres:
Oude Drift 1, Laren.

Het hele complex heet: Singer Laren, en die naam heb ik op het gebouw gezet. Op dat gebouw stond de tag: amenity=arts_centre, dat heb ik laten staan omdat het niet onwaar is, want:
In dit gebouw zijn twee verschillende zaken ondergebracht:

1. een Museum
2. een Theater (voorheen Singer concertzaal).

Beiden zijn uitsluitend toegankelijk via één gemeenschappelijke ingang.
Ik heb nu op de adresnode uitsluitend de BAG gegevens staan.
Ik heb de 2 nodes (binnen de gebouwcontour) aangepast en daar respectievelijk het museum en het theater mee aangeduid.

Dat lijkt me voorlopig de beste oplossing.