OpenStreetMap + App = OsmAnd!

210 readers

4 users here now

OsmAnd is a great open source Maps mobile app that uses OpenStreetMap!

founded 4 years ago

MODERATORS

[email protected]

ATMs are a shit show in OSM and need to be reworked with more fields and criteria (slrpnk.net)

submitted 1 month ago* (last edited 1 month ago) by [email protected] to c/[email protected]

2 comments fedilink hide all child comments

Whoever designed the OSM db either never uses ATM machines or they have never experienced anything like the ATM disaster in Netherlands. The OSM db has most ATM brands incorrect for Netherlands and seriously needs more fields so travelers can actually find a functioning ATM.

brands are mostly incorrect

Pick any Dutch city. Search » Categories » custom search » Finance » ATM. The brands are mostly misinfo. These ATM brands do not exist anywhere in Netherlands:

Rabobank
ABN AMRO
Ing
SNS

All those banks removed all their ATM machines and joined a monopolistic consortium called “Geldmaat”. There is generally an ATM at those locations but it’s always a Geldmaat ATM. So a simple find and replace is needed on all the Dutch maps.

For indoor ATMs, the brand is often incorrectly named after the shop it’s in. That’s useful for finding it but still missing important info: the actual ATM brand. ATM brand is very important because different ATM brands give differing degrees of shitty treatment. If brand X refuses your card, all instances of that ATM brand will likely refuse your card. So the “brand” field should always reflect the ATM operator. Having a separate shop name field would be useful for locating the machine.

missing key attributes

Travelers should not have to spend hours running from one ATM to another until they find one that works. There are lots of basic variables that need to be accounted for in the db:

(real or fixed point) ATM fee
(enum set) currencies other than local (a rare but very useful option is to e.g. pull out GBP or USD in the eurozone)
(enum set) card networks supported (visa, amex, discover, maestro, etc)
(enum set) UI languages supported
(integer) transaction limit for domestic cards
(integer) transaction limit for foreign cards
(integer set) denominations in the machine (Netherlands quietly removed all banknotes >€50 from all ATMs IIUC)
(boolean) whether customers can control the denominations
(boolean) indoor/outdoor (if the txn limit field is empty, indoor machines often have higher limits)
- (string) hours of operation (if indoor)
- (string) name of shop the ATM is inside (if indoor)
(enum) whether a balance check is supported: [no | only some cards | any card]; this feature is non-existent in Belgium but common in Netherlands. Note that some ATMs only give balance on their own cards.
- (enum) whether the balance is on screen or printed to the receipt, or both
(boolean) insertion style -- whether the card is sucked into the machine (this is very important because if the card is sucked in by a motor there is a real risk that the machine keeps the card [yes, that’s deliberate]). Motorised insertion is more reliable but carries the risk of confiscation. Manual insertion can be fussy and take many tries to get it to read the card but you never have to worry about confiscation.
(boolean) dynamic currency conversion (DCC)
(boolean) whether there is an earphone port for blind people (not sure if that’s always there)

top 2 comments

sorted by: hot top controversial new old

[–] [email protected] 3 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

Hi @activistPnk, you have some good ideas and you can directly start contributing to it.

The OpenStreetMap Database is a very flexible and open key-value store. Everybody can add any values to the Database even when they are not documented yet. This is how we came so far and successful with OpenStreetMap. This journey continues as long as enough people contributed their ideas to OpenStreetMap and try to find consens with the other mappers for common meanings.

So for a lot of examples you mentioned there are already established keys:

name=* brand=* operator=* network=* fee=* charge=* currency:EUR=yes/no currency:USD=yes/no currency:GPB=yes/no cash_out:notes:denominations=* cash_withdrawal:limit=* indoor=yes/no opening_hours=*

For your other information you can just invent new tags and use them. Maybe then more people will jump on them. Best practice is, to regularly visit taginfo.openstreetmap.org for used keys and values. Also wiki.openstreetmap.org is useful to documente used values. And vote for things in Proposals, when different solutions are competing against each other.

[–] [email protected] 2 points 3 weeks ago

thanks for the feedback. Glad to hear the parameters are in place. I guess it’s a matter of contributors populating those fields. My view of openstreetmap is generally influenced by what OSMand shows. So it’s also possible that an app limitation might be a culprit.

As for the non-existent ATM brands that litter the db nationwide in Netherlands, that correction probably should not rely on individual review. Someone probably needs to run an SQL statement like "update $table set brand=geldmaat where (brand is Ing or brand is abn·amro or brand is rabobank or brand is SNS) and country is netherlands”.. my pseudo sql might be rough there but you get the idea. A global change is needed on that.