Talk:Tag:amenity=bank

Proposed icon

Hello, I think, this amenity needs an icon, which will be displayed on rendered maps. Here my purposal:

Feel free to use it, if it convinced. I declare, that I'm the creator of this pictogram, so it is public domain.

TomsDidi 21:48, 09 May 2008 (UTC)

One problem: This symbol only apply to banks in Euro-zone. More international please. I remember there was a symbol with Euro, Dollar, Yen, and British Pounds. But forget where I saw it. Something like that in a house would work for me. --Bahnpirat 06:56, 10 May 2008 (UTC)

Hm... ;-) OK... perhaps like this one? I will try to get it sharper...

Bank1b.png

TomsDidi 18:16, 10 May 2008 (UTC)

They are now in "diamond"-position (top-left-right-bottom). Wouldn't it be better in "square"-position (top-left,top-right, bottom-left,bottom-right)? Thus, the symbol is good enough to use now. What about a green house, like Dollar? Well Euro is blue and Yen is ...? Color doesn't matter at all. But I don't want just black symbols on the map. I found the symbol with the four currencies. --Bahnpirat 12:46, 13 May 2008 (UTC)

Yes, I know this symbol, but it is used for little offices, where you can exchange money. That's why I'm searching for an other symbol for a bank. A bank is more then money exchange.

TomsDidi 18:11, 14 May 2008 (UTC)

What about this? --Bahnpirat 06:35, 17 May 2008 (UTC)

Please note that there is a generic symbol for currency in Unicode that might be used: "¤" Arlo James Barnes (talk) 18:31, 27 June 2018 (UTC)

It is unlikely that more than 0,1% of people would recognize it as a generic symbol for currency 05:49, 28 June 2018 (UTC)

atm tagging

Map_Features#Amenity says : "a bank (for a bank that also has an ATM, use amenity=bank and atm=yes)". there's also amenity=atm, so in the end we have at least two ways to tag atms... seems confusing to me. also, this supplemental tag is not listed on this page. i think amenity=atm would be better tag to use in all situations. marking it as connected to the particular bank branch could be done with relations (if required at all). User:Richlv 09:12, 17 September 2008

I agree. Although since the operator of the bank is going to be the same as the ATM, could we use "amenity=bank;atm, operator=HSBC"? User:Timmmm 14:39, 28 March 2009

This bank;atm semicolon notation is unlikely to be interpreted correctly by many existing tools. I appreciate that this isn't necessarily a reason to not use it, so let me give you other reasons...

As I see it, the preferred approach should be to put in separate nodes for these things. I will update the page accordingly. As User:Richlv said. amenity=atm is a better tag to use in all situations. But it's a level of detail thing. The level of detail we should strive for / progress towards, is to put the ATM (or multiple ATMs) as nodes separate to the bank. It's useful as the obvious way to indicate the number of ATMs and which side of the building they're on. However I can imagine mappers might prefer to slap in atm=yes on a bank node out of laziness, or because they don't have detailed notes of where the ATM is in relation to the bank.

Linking the ATM to the bank via some name/operator matching... yes it's a difficult problem, but it's also a very low priority problem. As and when somebody needs to write software which makes such a link (struggling to think why really) then the developer may have to do some basic location heuristics.

-- Harry Wood 11:48, 9 June 2009 (UTC)

I disagree about amenity=atm being the correct tag to use in all situations, simply because there aren't any really good ways to render that. If you have a bank with four atms outside and two inside and you mark all of them separately your render is going to be a mess even at zoom level 18 because it will be trying to render 7 nodes in approximately the same location. Also, using relations to show that an atm is connected with a bank is just an incredibly clunky and mapper unfriendly method. Also, the atm=* tag can easily denote the number of atms as well. Just use atm=# of atms (eg, atm=3.) When I map I actually use an extended version of the atm tag. The tags I use are as follows:

Tag	Description
outside_atm=*	Yes, No, #. These are atms that are outside and available 24 hours a day.
vestibule_atm=*	Yes, No, #. These atms are available 24 hours a day but are in a vestibule. Access is granted by swiping your atm card through a reader in a door.
inside_atm=*	Yes, No, #. These are atms that are only available during the banks hours of operation.
drive_through_atm=*	Yes, No, #. Available 24 hours a day. Not all that common but you do see a few of them around.
depository=*	Yes or No. A night depository box. Used by business customers who need to deposit money after hours. The boxes are usually outside but are sometimes in a vestibule as well.

This doesn't give you the which side of the bank is the atm on information but I don't think thats as big of a problem as being able to render the data in a sane manner. For standalone atms unconnected to a bank I use an operator tag to denote which company runs the atm tag and a capacity tag to denote how many atms are at that location. If there is a set of three HSBC atms I will only put one node and then a capacity=3 tag. The outside, inside etc information is important because it allows for time constrained routing. For instance if you told your OSM routing enabled phone to find you the nearest open Wells Fargo atm it wouldn't point you to one inside a closed bank or grocery store. I have been thinking however that changing the tags a bit to atm:inside=*, atm:outside=* might fit better with standard OSM conventions. Thoughts? Gregory Arenius 09:52, 21 June 2009 (UTC)

I am currently looking at a bank with multiple 24/7 atms in a vestibule, but they can be accessed by anyone - no card reader in a door. I think I'll create a separate amenity=atm node with respective access tags.

I think your proposed tagging scheme is quite convoluted - why use underscores instead of something like atm:drive_through=* - clearly denominating this as a sub-category.

-- Xerus (talk) 11:46, 24 May 2020 (UTC)

Name/Operator tagging

In Tag:amenity=atm the bank's name is proposed to be tagged by "operator". Mapnik does not render names at all. Osmarender does render 'name=' at zoom 17 but does not render 'operator='. I think it is very important to use whatever the Name finder is looking for to search on. I would think it is 'name', and not 'operator'.--Mdeen 11:08, 5 December 2008 (UTC)

Operator allows for a map with bank logos to be rendered, or even to single out only banks of one specific operator. That will increase the usability of the map, and gives us the ability to search for terms like "all the banks of <insert operator> in <city>" or nearest <bank of operator> to <my location>". --Skippern 11:48, 5 December 2008 (UTC)

BIC / SWIFT / IBAN

This should not be tagged on each individual bank, but rather as a value of a grouping relation, as BIC and SWIFT usually relates to all banks of a certain branch in the entire country. I use both terms as there are no global coverage of one or the other. Both values are good to know though. For instance, all HSBC banks in all of Brazil have the same value, while HSBC in Vietnam have another. --Skippern 17:04, 1 December 2008 (UTC)

Building Societies

Should we be using this tag for building societies, or should they have a separate tag? Frankie Roberto 16:17, 31 May 2009 (UTC)

I believe the answer should be "yes" since we should be indicating the type of services offered, rather than the ownership structure of the operator. Building societies offer banking services, even if they aren't legally a "bank" under English law. --ADMcD 21:21, 7 October 2012 (BST)

I agree. It's might feel a little clumsy and the pedants will say it's incorrect to use the word bank on a building society, but it would be even more clumsy to not use the same tag on something which is so similar (please no!!) Pretty sure most mappers are doing so anyway. Think of it as a regional eccentricity (rather like other tag usage e.g in the U.S. they're not called "motorways", but they use the highway=motorway tag) But I propose we mention something in the top description: "as well as building societies and similar financial institutions" to make it clear -- Harry Wood 14:08, 8 October 2012 (BST)

Bank without cashier

The HSBC branch on Edgeware Road in London has no cashiers, only ATMs and staff to speak to about mortgages and business accounts. Should there be a tag for this, maybe cashier=yes/no, or cashiers=count? Bitplane 18:29, 21 February 2010 (UTC)

Office number

In my bank, all the buildings have one reference (the number of office of bank). How can I tag it? As ref=number?

Thanks.--Xan 22:24, 23 May 2011 (BST)

I second that question. Also, all the buildings have a reference name. I'm using ref=number and agency_name=name for them. --Nighto (talk) 13:58, 8 February 2013 (UTC)

The discussion of this matter should definitely evolve into the official guide for the tag. It would be a HUGE differential, IMHO. By the way, I second the way Nighto is mapping. --Vitorrdias (talk) 23:24, 14 September 2015 (UTC)

Same question as Xan and Vitorrdias, here. This issue should be definitely addressed in some way... --Camminatoreseriale (talk) 23:34, 22 August 2021 (UTC)

ref=* seems fine for that given presented info Mateusz Konieczny (talk) 07:52, 23 August 2021 (UTC)

@Mateusz Konieczny, in my country (Italy), each branch usually has a number (eg: Banca Carige, agency n. 1, n. 2 n. 3 etc.), it is almost a "name" for that specific branch/building, and we use it pretty often in commercial and financial conversations. Do you suggest to use ref=* for this case as well? --Camminatoreseriale (talk) 06:44, 24 August 2021 (UTC)

If it is used as a name I would put it into a name tag Mateusz Konieczny (talk) 06:57, 24 August 2021 (UTC)

"operator" or "brand" ?

Which one "operator" or "brand" should be used to mark that the bank belongs to a particular banking corporation?. On Tag:amenity=bank "operator" is advised, but Key:brand advises using "brand". Any suggestions which should be used?

brand sounds more reasonable. "Deutsche Bank" is a brand same as "Shell". Pull request for main rendering will use brand: https://github.com/gravitystorm/openstreetmap-carto/pull/972 --Stephankn (talk) 08:32, 8 December 2014 (UTC)

I find the description on this wiki quite vague, stating operator=* like Barclays and brand=* like Deutche Bank, gives me the understanding that these two keys are the same. Could somebody try to rewrite these two points to make it clearer? Also when this is done, the translated pages needs to be updated. --Skippern (talk) 12:38, 18 February 2015 (UTC)

I agree. Look at my edit, please.--Stemby (talk) 00:10, 27 February 2016 (UTC)

I'm still not clear of the distinction. Are we saying "brand" is a sort of "display name". The familiar name written on the bank (which might also be written on a map label) while the operator is the full company name? Was this to settle an argument among mappers between the pedantic full name "Deutche Bank AG" versus the pragmatic "Deutche Bank"? -- Harry Wood (talk) 10:55, 16 August 2016 (UTC)

How name, brand and operator have to used is still unclear to me and obviously many other mappers as well - for example in Freiburg (German city), all combinations exist, so e.g. (fictional values to make the point more clear) "Santander" as name and empty brand+operator, "Santander" as brand and/or operator with empty name or with "branch Freiburg" as name, sometimes at a point or way, sometimes at a relation (e.g. multipolygon). Consequence is that searching is much more difficult than it shall be (you have to consider all combinations) and that also the renderers display a useful text only in a fraction of cases. Is there anyone who really understands the name/brand/operator tagging scheme? If yes, please explain it in a really clear + unambiguous way, if not, we shall change the tagging scheme ;-) --Schoschi (talk) 14:09, 18 March 2017 (UTC)

I think they just need very concise definitions so there is no ambiguity. The way I see it is the operator=* would be the legally registered name of the company (which may not be obvious looking at the store) and brand=* would be the chain name they use to market their store (should be obvious from outside of the store). Then some stores have an additional unique name such as that of the town or manager which I would assign for the branch=*. As for the name=*, it's more subjective, should be intuitive from the outside of the store and would usually just be a concatenation of the other tags although sometimes this isn't the case such as "Hendrix's No Frills" where Hendrix is a unique name and No Frills is the name of the chain. The other tags, once filled out, help make it more machine readable somewhat analogous to having multiple address tags (addr:housenumber=*, addr:street=*, etc) instead of a single "address=*" tag. So once the other tags are filled out, apps should use them for improved labeling consistency and search functionality, and the name tag would likely become redundant. In Canada for example we have many 'different' supermarkets such as Loblaws, Superstore, No Frills, Box, etc, but they are infact all owned by the same company, Loblaws Companies Inc. There's a list here. Tangerine would be an example for a bank in Canada. If the operator and brand are the same, then both tags would be the same, but usually isn't the case. Looking at Walmart, I'd put brand=Walmart (what you see), and operator=Wal-Mart Stores, Inc. (legally registered). However where I get a little stuck is if the operator should be the subsidiary or the parent company. For example Walmart Canada Corp. is a subsidiary of Wal-Mart Stores, Inc. I'd be inclined to put the operator as the parent (holding) company, then just to create more confusion, add a new tag called subsidiary=*. The last bit of confusion for me comes with franchising and affiliation. I think I would use the owner=* as the name of the franchisee and the operator as the franchiser. McDonald's for example, has ownerships, affiliations and franchises of it's many locations and it might be nice to distinguish between them at some point. It would be good to have people with global experience in this field to come up with a classification scheme and some concise definitions to help nail this down. And just to complete this, there's ref=* to specify the branch number. DFyson (talk) 18:20, 18 March 2017 (UTC)

Mapping Bank with Drive-Through Separate from Bank Building

This is the second time I have run across a bank that has the drive-through area separate from the bank itself. (Underground vacuum tubes are used to exchange items.) The drive-through is usually nearby (such as across a street). How should I map the drive through area? --MRPockets 01:55 24 September 2015 (UTC)

name=* and brand=*

Currently name=* is mandatory, and brand=* is optional. IMO the importance of the two keys should be reversed: the brand is what people see on the premises, so it should be mandatory; name=* should be used only for the branch name, and only when a branch name exists, so the description of the name=* tag should be simplified:

• name=* - the branch name.

(There is no point in duplicating the operator tag).

Do you agree? If so, I think this CartoCSS rule should be modified ("[name]" → "[brand]"). See also here.--Stemby (talk) 01:05, 27 February 2016 (UTC)

name=* and branch=*

Why is the name tag used for specifying the branch when the branch tag exists for that exact purpose?

As it stands, the name tag has become too technical and thus highly prone to inconsistancis unless every editor reads this amenity=bank page. The name should simply be left to what is most intuitive to the mapper, novice or advanced alike which usually ends up as whatever is most obvious on the ouside of the building, in this case usually the operator. It's even mentioned if the branch isn't known then use the operator. So what I'm seeing is the name tag for amenities like banks is an inconsistant mix of operator and/or branch names which is annoying for how to best render the label.

So I suspect the best way would be to render the label with the branch and operator/brand tags if they are filled out, otherwise use the name tag. DFyson (talk) 07:46, 11 September 2016 (UTC)

Tagging ATMs seprately: the "preferred" approach? By whom?

"You can use a atm=yes or atm=no - to quickly specify whether a public cash machine (ATM) is also available at the branch. However the preferred level of detail is to place separate nodes for each ATM machine, tagged with amenity=atm. This indicates the number of ATMs and which side of the building they are on."

This recommendation has been present on the page since 2009, it was added by 1 person and only 1 person challenged it in this discussion, even though revealing the usage of non-existent tags, which is worse imo.

Preferred level of detail by whom? How does tagging 10 ATMs as nodes within a very small room make any sense?

Banks have ATMs that belong to the same brand/operator, they all serve the exact same purpose and are enclosed in the same building, so mapping ATMs separately as nodes involves unnecessarily repeating the same information N times just for the sake of getting a nice rendering, under the false premise of indicating its existence. Tagging every bench in a park is one thing, but tagging every table in, let's say, an outdoors restaurant is another. If there are multiple ATMs of the same bank, they can simply be grouped into one node and tag it separately when necessary (e.g. when the machines are located too far away from the main entrance, making customers having to get around possible obstacles to get to them, etc.).

When looking at a map in OSM, the user doesn't need to know how many ATMs a bank has, the same way they don't have to know how many stalls a bathroom has. Such elements are merely indicated in a way the user knows they exist but its number is rather trivial since their existence is subject to constant change (removed, out of service, etc). --Absay (talk) 09:10, 26 March 2017 (UTC)

Ya that seems like it would be more annoying than it would useful. Another problem would be searching for an ATM in OsmAnd for example, you'd get like 5 hits all for the same bank which would drive me insane. If one really needs to know how many ATMs there are in a room at a bank, there could be another tag like atm:quantity= analogous to parking capacity. Or another option could be to map all the ATMs but use a relation so apps can easily determine that they all belong to the one bank. DFyson (talk) 05:10, 27 March 2017 (UTC)

Alright. I removed the section. The OSM example of providing several meaningless results for the same place is enough to illustrate why tagging stuff this way is a bad idea. --Absay (talk) 20:52, 27 March 2017 (UTC)

I really think you have degraded these pages by removing advice on tagging ATMs. DFyson's points entirely relate to something which can be/should be resolved by the data consumer. In general common practice is to map ATMs separately when they are located on an external wall or otherwise generally accessible (for instance in a building open 24/7), and atm=yes for those which can only be accessed inside the business premises. There are other reasons why ATMs need to be mapped separately: for instance the ATM might be available at times other than the relevant opening hours. Before changing the wiki, you should have looked at tag usage & the patterns of usage. SK53 (talk) 21:26, 27 March 2017 (UTC)

You are misunderstanding the issue, which is not tagging where the ATMs are located but tagging each device separately, as in N number of machines that in many cases are a few centimeters next to each other, and which is what the recommendation dealt with. If you re-read my OP: "If there are multiple ATMs of the same bank, they can simply be grouped into one node and tag it separately when necessary (e.g. when the machines are located too far away from the main entrance, making customers having to get around possible obstacles to get to them, etc.)", and judging by your answer we both agree on this.

As for degradation of wiki, there's no such thing. It can be reverted, but I decided to remove it for the reasons I stated in my OP.--Absay (talk) 21:50, 27 March 2017 (UTC)

I edited the page again and re-added the section but replaced the original recommendation: instead of tagging single machines, tag single locations. Does this make more sense? Yes? No? Why? --Absay (talk) 22:24, 27 March 2017 (UTC)

I think there is an argument to be said for tagging all the ATMs since they can each offer different services such as various currencies. Although a counter argument (or different scheme) might be to combine the services offered by the different ATMs into a single node knowing that when you go into that room of ATMs, at least one ATM will offer it. In theory you should be able to add as much detail to OSM as you want so long as you are able to organize and manage it well, then let the data consumer be responsible for 'downsampling' or filtering out detail. However, as it stands, I don't see an easy reliable way to filter/organize ATMs as part of the same branch (a relation might work well, or filter all ATMs with the same operator & branch tags as the bank?). So until that is figured out and documented along with it, I don't think it should be advertised as the preferred way to do it. I prefer how it's written now. DFyson (talk) 22:55, 27 March 2017 (UTC)

DFyson, does amenity=bank assume the bank has ATMs by default? --Absay (talk) 22:24, 27 March 2017 (UTC)

Assumed yes, implied no. I can't think of a bank that doesn't have an ATM so I tend to assume all do. But if one didn't, I'd certainly want to know about it before going there. So that's the message I'm trying to get across. DFyson (talk) 22:55, 27 March 2017 (UTC)

Okay so let's assume I'm in this unknown city and I need to withdraw money from an ATM blonging to the popular Duck Bank, which in turn belongs to a larger commercial chain with stores and other services of the Duck brand. Turns out, a bank without ATM tags is a few blocks away from my position, and there's another one with the atm=yes tag a couple of kilometers away from me. If I try to search for "duck atm" (using this specific query in whatever software I'm using), will I get both locations in the results? Because as far as I know, I will only get a hit for the one that is farther away, unless this is software-specific, but regardless it would be also more appropriate to use atm=yes, no? --Absay (talk) 20:46, 28 March 2017 (UTC)

Well that would depend on the search algorithm. It could assume that banks without an atm=* tag will have an ATM since I know not everyone will add the atm=* tag. But it's better not to assume and I agree it would be better that it is explicitly stated for either yes or no. So ya maybe it would be better to forget about what I wrote, just keep it simple and unbiased to yes or no. If that's what your thinking feel free to change it. DFyson (talk) 22:39, 28 March 2017 (UTC)

Hi there. I'm the one person who added the sentence back in 2009. It's not meant to be a super hard rule. I certainly don't want push a unilateral preference, but I don't think that's what this is. Quite the opposite. I think it's really an expression of very widely held preference of the mapping community: We prefer higher levels of detail (in general). We don't require it (so a summary tag atm=yes on a bank is fine) but we prefer it. If somebody comes along and converts it into richer data showing the locations of ATMS, then that should be regarded as an improvement. That was intention of the sentence, but maybe there's a better way of writing it. Maybe "preferred" is the wrong word.

"How does tagging 10 ATMs as nodes within a very small room make any sense?" I think is a fair question. It's true I mainly think of positioning ATMs around external walls. 10 ATMs in a room would be hyper-detailed indoor mapping (Not the most crazy hyper detail people map actually. It does still "make sense". But yeah a bit crazy)

Your duck bank example may be an important use case to think about. It highlights the importance of people setting atm=no on banks with no atms, and also operator on separate amenity=atm nodes. Where that data is missing a data user may be left with a tricky choice about defaults. It's true. I don't really see where you're going with that line of argument though. Are you hoping that we'll all decide we should merge our detailed ATM locations back onto bank objects in order better cater to that use case? Hunting down missing operator tags and atm=no tags could be a good QA tool/fixup challenge.

Sorry about the reverting on the Tag:amenity=atm page earlier today. The change seemed to be out-of-the-blue on that page. I hadn't noticed this big discussion. I've crossed-linked the discussions now. So maybe there's a better sentence to be added over on that page. Like I say maybe "preferred" is the wrong word.

-- Harry Wood (talk) 22:06, 19 May 2017 (UTC)

Just to give another perspective, I think the paragraph was correct, as knowing where any individual atm is located is useful and strictly better than only knowing about the existence of an unspecified number of atm somewhere. Some updates to the text to reflect on the issues you mentioned seem sensible, but I don't think that the wholesale removal of the paragraph is in any way justified. --Tordanik 14:57, 21 May 2017 (UTC)

payment_terminal=yes

Should we add payment_terminal=yes to indicate that you can also make transfers and statements at a terminal. It is similar to atm=yes. See also amenity=payment_terminal for a separate node. --geozeisig (talk) 07:52, 2 December 2023 (UTC)