De adresgegevens zijn verzameld op een nieuw aangemaakte adresnode
De adresgegevens van de 2 nodes met de bedrijfsgegevens zijn verwijderd
Die gegevens zijn samengevoegd in de associated_address relatie.
Je hebt het ook nog over verdiepingen, maar omdat het gebouw (waar ik dus niets aan heb gewijzigd) ook niet in 3D is getekend, heb ik daar ook niets mee gedaan.
Het voordeel van de associated_address mehode is dat de adresgegevens nu gescheiden zijn van de gegevens van de bedrijven en dat je er ook makkelijk nieuwe bedrijven aan kunt toevoegen, maar dat is natuurlijk maar betrekkelijk, zo vaak verandert er ook niet iets.
Als je gaat zoeken naar associated_address in de wiki’s kom je ook niet veel tegen omdat er maar weinigen gebruik van maken. Maar het is inderdaad handig als er meer bedrijven op één adres zitten.
Nu de structuur er eenmaal ligt, kun jij zelf weer aanpassen wat er eventueel nodig is.
Graag gedaan.
Vanmorgen nog een kleine update mbt. role van de adresonderdelen gedaan zodat het klopt volgens deze proposal.
In die proposal (die dus is afgewezen, maar de tag wordt wel ondersteund en gerenderd) staat ook een mooi voorbeeld van een shopping mall.
Die ‘manier’ kende ik wel, maar ben altijd een beetje huiverig om het als mogelijkheid te geven. Het is immers een proposal.
Er wordt wel vaak naar een oplossing gevraagd net als G.J.
Hoe zit het met de vindbaarheid van de bedrijven bij een zoekslag in de verschillende apps?
Is dan ook adres gekoppeld aan bedrijf/winkel?
Met associated_street werkte het ook niet optimaal.
Het probleem kan ook opgelost worden door de adresnode op de ingang van het gebouw te zetten en daarna de POI van de bedrijven binnen de gebouwcontour te plaatsen. Dat was ook een van de redenen voor een tegenstem bij het proposal.
Met zoekfuncties kun je altijd vinden op de bedrijfsnaam, want die zit in de POI, maar de adresgegevens komen lang niet altijd mee.
De meest robuuste methode is:
Adresnode (met alle beschikbare gegevens) op ingang van gebouw