Naar mijn mening lost een nieuwe tag dit niet op; denk dat er weinig animo zal zijn om deze te adopteren door de verschillende apps - kan immers niet automatisch verwerkt worden.
Tjuro’s oplossing is mooi, maar verlegt het probleem naar de eigenaar/webbeheerder - ook weer, waarom iets “moeilijks” als een openings_hours.txt aanmaken als de moeite al niet gedaan kan worden om het zelf direct op OSM goed te zetten? - oftewel weer een lage adoptie graad.
Wat wel nuttig kan zijn - gezien in een eerdere discussie in Eindhoven - is een gestandaardiseerde “openings_hours=see_website” variant (en dan de echte ‘website’ tag volgen). In dit geval ging het expliciet om een winkel eigenaar met flexibele openingstijden die geen zin had om OSM telkens te updaten. De door gebruikers toegevoegde openings_hours werden namelijk meteen verwijderd.
Terug komend op Dillen_GJ’s nieuwe tag voorstel - ik ben er niet voor om OSM alle problem op te laten lossen van restaurants met flexibele openingstijden die zelf geen moeite willen doen om de openingstijden te communiceren. Bijvoorbeeld door een simpele site te maken - wat eigenlijk de enige reden is om naar een custom URL te verwijzen.
Expliciet OSM niet willen onderhouden als eigenaar kan ik me nog wel iets bij voortstellen.
Iets in de richting van het volgende misschien met als opmerking “Openingstijden onder voorbehoud, bel ons of bezoek onze website: hgcgolf.nl/Golfbaan/Golfbaan-informatie/Openingstijden-winterperiode”
In zo’n geval zou ik ook voor makkelijk gaan.
Ook de link naar de juiste pagina op een website wordt wel eens aangepast. Gevolg is… pagina bestaat niet.
…opening_hours zijn aan te passen.
Steeds meer bedrijven checken de vermelding in osm.
Er zijn ook apps die bedrijven helpen met het toevoegen van hun bedrijf op osm.
Die werken nu met opening_hours.
Die tag is wereldwijd nu zoveel gebruikt. Daar zou ik niet aan willen tornen.
Verwijzing naar een website:opening_hours zou wel een aanvulling kunnen zijn.
… van website:menu bestaat ook een wiki.
Een verwijzing naar de algemene website lijkt me voldoende.
Goed idee Eggie !
Als dit mogelijk gemaakt wordt dan heb je zowel offline als online info over openingstijden, bovendien zijn deze 2 dan elkaars info backup…
In het specifieke geval van deze golfclub bestaan er heb ik gezien 2 urls: zomer openingstijden & winter openingstijden (verander voor de gein in mijn eerdere url post winter maar in zomer).
Ik weet niet of het een goed idee is. Ben meer van 'KISS (Keep it simple and stupid.)
Dus opening_hours= en een website.
Wanneer het mogelijk is om naar een websitedeel te verwijzen middels een url is dat natuurlijk een goede aanvulling.
Ik kijk ook hoe incidentele mappers mappen en dan zie ik dat de drempel al snel te hoog is.
Voor openingstijden gebruik ik deze tool. Er zijn er overigens meer.
Even een andere vraag omtrent het zelfde mapping object:
Hoe map ik ELEGANT 2 bedrijven (in dit geval: een golfclubhuis bestaand uit 2 verdiepingen & een restaurant op de 1ste verdieping) op 1 adres ?
Als er een ELEGANTE manier is wil iemand dit dan voor mij mappen ?
Ik ben een zeer recente mapper (newbie) die op dit moment niet de tijd heeft om te mappen maar middels OSM planmatig & budgettair zoveel mogelijk tijd met mijn familielid (waar ik 24/7 voor mantelzorg) feestdagen mee wil doorbrengen voor zolang ze nog te leven heeft…
Ik beloof me na die tijd volledig te storten op OSM…
Top Marc ! Ik zet een opmerking bij ‘restaurant de drie gemalen’ en clubhuis de Haarlemmermeersche golfclub te Cruquius. Waarbij het clubhuis 2 verdiepingen heeft en het restaurant daar op de 1ste verdieping onderdeel van is.
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
