Hoe kun je het beste ATM’s taggen die zich in een bank, winkel, etc. bevinden. Ik heb een of twee oudere topics hierover gevonden, maar wat is het beste? Als apart punt taggen, of als tag atm=yes bij de winkel, bank (zoals hier gezegd wordt: Tag:amenity=atm - OpenStreetMap Wiki)? Het gaat er mij om, dat ze zichtbaar/vindbaar worden op de kaart, en dat is volgens mij met atm=yes niet het geval.
Wat ik doe bij een atm in een winkel deze als punt mappen omdat je dan ook precies kan laten zien waar exact de atm in de winkel staat.
Bovendien kun je (nu spreek ik even alleen over Geldmaat atm omdat die het vaakst in mijn leefomgeving aanwezig zijn) extra operator info middels de keys: operator & operator:website bijvoegen.
1 Like
Dit doe ik ook inderdaad. Het is feitelijk vaak ook een zelfstandige voorziening in de winkel.
Naast dat je de exacte locatie kunt aangeven, kun je er ook beter andere gegevens kwijt die behulpzaam/informatief zijn. Ik voeg bijv. meestal een note toe om aan te geven dat de automaat in winkel X staat (en/of evt. nog een exactere beschrijving waar). De brand/operator (zelfstandig) toevoegen, maakt de vind- en zichtbaarhied baarheid groter. Dit wordt ook uitgelegd op atm=yes.
Overigens hoeft een losse node niet uit te sluiten dat je alsnog atm=yes toevoegt aan de locatie waarbinnen de geldautomaat staat (zoals in dit voorbeeld de winkel). Vergelijkbaar bijvoorbeeld met een prullenbak bij een bushalte:
bin=yes: there is a waste basket. Additionally, it may or may not be mapped as a nearby node with amenity=waste_basket.
Als de pinautomaat onderdeel is van een bank vind ik dat minder logisch op één of andere manier - en de wiki geeft dat ook aan:
Note that ATMs located in or near bank branches may be tagged as amenity=bank with atm=yes. If the bank and the ATM have different opening hours, it might be worth to use amenity=atm instead.
Maar gek genoeg kom ik dat hier in de buurt eigenlijk niet meer tegen. Heeft wellicht met onderstaande te maken:
Je kunt er denk ik vanuit gaan dat dit voor het merendeel van de automaten geldt. In 2018 hebben de grootbanken het beheer van de pinautomaten onder gebracht in de (reeds bestaande) “joint venture” Geldmaat en structureel alle pinautomaten vervangen/geconsolideerd. Zie bijvoorbeeld de wikipagina over Geldmaat of dit (oude) nieuwsbericht voor meer context.
2 Likes
Dank, ik had dat inmiddels ook zo gedaan bij twee Bruna winkels die ik ken, zowel atm=yes bij de winkel, als een aparte node amenity=atm in de winkel met in de note dat ze zich in de Bruna winkel bevinden. Beide Geldmaat inderdaad
2 Likes
Als je de operator:website= key gebruikt en de exacte lokatie van de Geldmaat url daar in copy paste wordt vanzelf laten zien in welke winkel deze zich bevindt met daarbij nog enkele andere nuttige data elementen.
Voorbeeld:operator:website= https://www.locatiewijzer.geldmaat.nl/nl/?search=Spoorwegstraat%2C+2015+BL+Haarlem%2C+Nederland
Oh, mooi. Zou je in dit geval dan niet deze moeten gebruiken? https://www.locatiewijzer.geldmaat.nl/nl/location/2015001/
Ja kan ook maar heel raar soms komt zo’n url niet met goed werkende site terug is mijn ervaring inmiddels & nog een nadeel: je ziet dan niet dichtbijzijnde atm’s. Boeien zou je zeggen totdat je atm in storing is of in onderhoud en je daardoor een dichtbijzijnde atm nodig hebt… Met de wetenschap dat steeds vaker atm’s in storing zijn wel een extraatje aan nuttige info 
Beide link-soorten hebben hun eigen nadelen. Jouw zoek-link-variant laadt bij mij (zowel op desktop als op mobiel) bijvoorbeeld zo:
… en da’s niet echt bruikbaar 
terwijl de link van lukask99 zo laadt:
Dan vindt ik dat toch echt een stuk behulpzamer. Als je direct de automaten in de omgeving ziet, is dat w.s. óf omdat je de website toegang gaf tot je locatie, óf omdat 'ie de locatie nog heeft onthouden van je eerdere bezoek.
Niet helemaal waar: je kunt op het kruisje rechtsboven klikken, dan komt de kaart weer tevoorschijn. Dus dit zou m.i. toch de te prefereren link moeten zijn.
Voldoet gevoelsmatig ook beter aan deze definitie:
Choose specific URLs over home pages. For example, use
https://www.islandbuses.info/services/SVCT/8instead ofhttps://www.islandbuses.info/as the former it related to the element. Consider brand:website=, network:website= or operator:website=* if you want to store a URL for them.
(Bron: Wiki - Key:website - kopje best practices)
Een link naar een zoekopdracht is namelijk minder specifiek dan een link naar één van de resultaten.
Conform de uitleg daar zou je operator:website overigens moeten gebruiken voor de “gewone” website en op het object naar de zo nauwkeurig mogelijke aan de locatie gerelateerde website moeten verwijzen, dus in dit geval:
website=https://www.locatiewijzer.geldmaat.nl/nl/location/2015001/
operator:website=https://www.geldmaat.nl
Ja en nee: als de automaat in storing staat is het fijn dat je direct ziet wat er in de omgeving is, maar dat is pas relevant als je bij de automaat bent én als de automaat in storing staat.
Als je de automaat opzoekt, dan zijn de openingstijden en winkel-informatie in eerste instantie nuttiger. Bij het zoekscherm moet je daarvoor nog een keer voor doorklikken (priegelen op mobiel), terwijl je die informatie de deeplink naar het resultaat die direct (zonder nog een extra klik) te zien krijgt. Het hangt dus van de omstandigheden af welke informatie nuttig(er) is. 
Als dat idd het beeld is wat je krijgt met de url die ik gegeven heb dan heb je gelijk maar: dit is mijn screendump met een iPad wat geladen wordt razend snel…
Streven naar goed, beter, best ben ik altijd voor !
Operator:website gebruik ik omdat ik ook operator gebruik omdat er meerdere atm operators zijn in Nederland.
In het lijstje is dan netter gegroepeerd: operator, operator:website
Wat betreft: operator:website zouden we dan dit kunnen doen:
operator:website= https://www.locatiewijzer.geldmaat.nl/nl/location/2015001/ ; IPad_Iphone: https://www.locatiewijzer.geldmaat.nl/nl/?search=Spoorwegstraat%2C+2015+BL+Haarlem%2C+Nederland
Je realiseert je dat je daarmee afwijkt van de voorgeschreven standaard voor die tag, en dat je daar uiteindelijk niemand mee helpt?
We maken de kaart niet voor de data, maar voor de (verschillende) eindgebruikers, die allemaal verwachten dat data volgens die standaard wordt ingevoerd. Als je daar vanaf gaat wijken, wordt het voor de eindgebruiker niet of niet goed meer weergegeven. 
Zoals ik al eerder zie:
Ik merk als ik nu test (met private browsing/wissen van cache) dat de link naar het zoekresultaat (ook) niet consistent werkt. Mogelijk een vergelijkbaar probleem als je zelf met de andere link ervoer - en ligt dat aan de website in zijn geheel (niet aan welke link je gebruikt) dat het niet consistent goed werkt.
Dat kan sowieso niet. De website tag ondersteunt maar één link per tag en iPad_iPhone is geen bestaande tag. Dan maak je het in de praktijk alleen maar stuk voor apps en renderers die er iets mee proberen te doen maar dat niet verwachten - en dus onbruikbaar voor iedereen. Daar zou ik van wegblijven.
Zie /wiki/Key:website of specifiek #Prefixed voor wat er wel mogelijk is. Er is ruimte om buiten de gebaande paden te gaan, maar dan zou je er dus in ieder geval een aparte tag per link voor moeten gebruiken. En het liefst sluit je dan aan bij iets wat al bestaat, voorgesteld is (proposed) of veelgebruikt is. In dit geval bestaat website:map= al en wordt volgens taginfo redelijk gebruikt, dus als je die wat ruim opvat zou je die ervoor kunnen gebruiken (je linkt immers naar een kaart met de ATM).
Houdt er vooral rekening mee dat wat je tagt in principe algemeen/objectief (of in ieder geval: zo objectief mogelijk) van toepassing zou moeten zijn voor iedereen - en dus geen persoonlijke voorkeur zoals in dit geval.
Daarnaast is suggereert iPad_iPhone (of wat je bedoelt is dan feitelijk website:iPad_iPhone, of eigenlijk website:mobile, want er is natuurlijk meer dan alleen Apple ) feitelijk onjuist: je linkt niet naar een website die specifiek bedoelt is voor mobiele apparaten, maar (opnieuw) naar wat jouw persoonlijke voorkeur heeft op die apparaten - en dat is eigenlijk nooit de bedoeling.
moet operator:website in dit geval niet zijn https://www.geldmaat.nl ? Dat is hoe ik operator:website interpreteer
Mijn voorkeur voor de kaartlink zou ook zijn website:map
1 Like
los van welke tag je gebruikt doe je er goed aan om die ‘lange URLs’ te mijden. Het is een van de grootste categorien die door de mand valt in deze Maproulette en in mijn ordinaire Firefox werken ze evenmin als in de test van Tjuro.
1 Like
Een OSM-team bestaat uit keepers, aanvallers enz.
Een team dat bestaat uit alleen keepers (lees: regeltjes uitpluizen) die daardoor hun eigen team remt in creativiteit helpt een Google-team…
Willen we als OSM alleen keepers in het team dan ga je een wedstrijd tegen Google verliezen…
Juist een mix & match team zal talenten van de 1 en onvolkomenheden van diezelfde persoon versterken in de eerste en verzwakken in de andere situatie…
Ik ga voor: lean, gebruiksgemak & regels waar ik een balans in wil vinden zodat zoveel mogelijk gebruikers plezier hebben in het gebruik van OSM en daardoor populairder wordt en middels collectieve idee-en met gemak Google kan verslaan.
Regels helemaal mee eens, maar laat het altijd een mix zijn van: lean, gebruiksgemak & regels… Zo blijven we een team met als gezamelijk doel: goed beter best…
Naar mijn weten bestaat deze nog niet…
En hoe lang duurt het voordat dat wel gaat werken ?
Als dat operationeel zou zijn heb je de rest niet nodig zoals: website, operator:website immers met website:map ben je al op operators website en voldoe je daardoor aan de lean ‘regel’
Tevens kwa onderhoudbaarheid ook fijner want je hoeft maar te checken op 1 url regel kwa dead-links…
Je hebt binnen openstreetmap het principe van Any tag you like. Je bent vrij om een nieuwe tag te bedenken, waarbij die het liefst ook is gedocumenteerd. website:map is wereldwijd al 1140x gebruikt (bron).
Kijk maar natural=shrubbery. Die tag heeft nooit een stemming gehaald maar is ondertussen wel al 30.000x gebruikt en is hiermee organisch gegroeid
1 Like
Dat was inderdaad ook mijn suggestie eerder:
Dus eens.
Ik heb je nu al een aantal keer naar de Openstreetmap Wiki verwezen, als je de moeite had gedaan die een keer goed te bekijken, had je gezien dat dit een bestaande prefix is. Vierde item van boven in deze tabel: https://wiki.openstreetmap.org/wiki/Key:website#Prefixed
Dat is een prachtig pleidooi, zonder daadwerkelijk argument waarom in dit geval de door door jou voorgestelde oplossing, die feitelijk niets anders is dan je persoonlijke voorkeur, beter is en een beter (met Google concurrerend, als dat dan je doel moet zijn) resultaat oplevert.
Terwijl ik je wel heb uitgelegd dat als je tags anders gebruikt dan de consensus, de eindgebruiker er alleen maar nadeel van ondervindt (ook tov. Google) omdat de producten die de data gebruiken (apps, kaartimplementaties op websites, etc) de data niet daar of op die manier verwachten, niet kunnen interpreteren, en dus niet of onjuist weergeven.
Regels of richtlijnen zijn voor mij geen doel op zich, maar een middel. Hetzelfde geldt voor er vanaf wijken: omdat binnen de regels geen (goede) bestaande oplossing is om een doel te bereiken. Maar dat is hier niet het geval.
Je betoog is een mooie “contradiction”, maar je geeft geen inhoudelijke argumenten waarom jouw methode beter is.
Dat is dus helemaal niet nodig, want de tag is al officieel goedgekeurd en in gebruik, als ik de wiki als leidend mag nemen. Maar, je zegt hetzelfde als ik hier feitelijk al eerder zei:
… dus we zijn het eens.
Top daar kan ik wat mee super !
Alleen Carto doet het op een team-vriendelijk manier.
Ik wil je niet de les lezen omdat ik een teamplayer ben maar Carto’s manier is teamplayer vriendelijker en leaner kwa communicatie.
Blokcitaat Je betoog is een mooie “contradiction”, maar je geeft geen inhoudelijke argumenten waarom jouw methode beter is.
Ik hoef geen gelijk (daar verschillen wij in kwa karakter)
Ik wil een lean, gebruikersvriendelijke team-oplossing binnen de regels en die heb ik gekregen via Carto middels een rustige uitleg.
Daarmee heeft team-OSM gewonnen
“Ik wil je niet de les lezen” maar ik doe het toch". 
Je bent nu afgezakt naar “responding to tone” (zie: https://debatepyramid.ca/). Dat past een teamplayer ook niet - en ga ik verder niet op in.
Je doet een aannames: Gelijk krijgen/hebben is niet mijn doel. Ik was op zoek naar redenen waarom jouw oplossing ook een goede/betere kan zijn (en gefrustreerd door het uitblijven daarvan, terwijl je vervolgens - om voor mij onbegrijpelijke redenen - toch vasthoudt aan een objectief minder goede oplossing voor de eindgebruiker).
Ik ben blij dat de andere manier van uitleggen je heeft geholpen om tot dezelfde conclusie/oplossing te komen die ik je eerder ook probeerde aan te dragen. 
Zoals je zegt, daarmee wint OSM.
Mocht je verder inhoudelijke feedback op mijn schrijfstijl willen geven, zoals welke (objectieve) zaken eraan bijdragen dat mijn eerdere berichten (voor Carto) jouw inziens “niet rustig” of “niet team-vriendelijk” zijn, staat mijn DM open.
Nee dat is jouw interpretatie…
Ik DM alleen vriendelijke teamplayers
@ moderators mag dit draadje dicht ?