Heb er net 1 op can’t complete gezet maar zie al wat er aan de hand is. Geldmaat toont zelf de verkeerde locatie op de site.
https://www.locatiewijzer.geldmaat.nl/nl/location/6511005/
Logisch dat het script die dan heeft gekoppeld aan deze node: Node: Rabobank (2847397204) | OpenStreetMap
De Geldmaat uit de Maproulette lijkt zo te zijn verdwenen maar juist op die locatie zijn de automaten er wél: Node: 3459867620 | OpenStreetMap
Dank voor informatie, er is iets geks met deze ATM, hij komt niet voor in de lijst die je kan opvragen van “alle” Geldmaten maar de specifieke website voor deze ATM werkt wel. Goed om te weten dat dit soort problemen bestaan.
Ook bedankt voor de informatie en het bijwerken!
Één vraag: Op de plaats van die Rabobank node is er geen ATM meer toch? Zo ja, dan graag die node verwijderen 
Vermoedelijk niet, maar wil dat nog wel even controleren. Misschien is er nog een ATM in het gebouw, al lijkt me dat me dat onwaarschijnlijk gezien er al een Geldmaat aan de zijgevel zit.
Overigens hoeft die node niet weg, alleen atm=yes eraf.
Info: @emvee
Als ik de Geldmaat site correct begrijp dan zijn er dus op deze locatie 4 machines:
Ik heb er zelf voor gekozen om individuele machines te taggen. Wat is jullie idee hierover?
Dit was al besproken! Iedere automaat een eigen node 
Dat had ik even gemist 
Het zou kunnen dat de automaat voor sealbag storten binnen is.
edit Een niet nader te noemen bron (iets met gekleurde letters) laat zien dat de sealbag-automaat om de hoek zit maar wel degelijk aan de buitenzijde.
Maar sowieso moeten het dus 3 nodes gaan worden aan de buitenzijde van het gebouw? (en een 4e na echte observatie)
Tijd voor een update, het script weet inmiddels om te gaan met meerdere machines binnen een geldmaat locatie.
De manier waarop ik het script schrijf is stukje bij stukje, elke keer als er is onverwachts gebeurd kan laadt ik de OSM data in josm en print een overzicht van de Geldmaat data in z’n formaat dat ik het gelijk kan gebruiken om de OSM data bij te werken, bijv.
addr:city=Zaltbommel
addr:housenumber=10
addr:postcode=5301KE
addr:street=Van Heemstraweg-Oost
amenity=atm
brand=Geldmaat
brand:wikidata=Q74051230
brand:wikipedia=nl:Geldmaat
cash_out=yes
cash_out:coins=yes
cash_out:notes=no
description=Alleen muntrollen opnemen
name=Geldmaat
opening_hours=Mo-Sa 09:00-21:00
ref=530110
speech_output=no
website=https://locatiewijzer.geldmaat.nl/nl/location/530110
Aldus flink wat Geldmaat winkels toegevoegd en problemen met locaties met meerdere automaten (die ik veelal zelf had veroorzaakt) opgelost.
Een eerdere versie van het script had waarschijnlijk problemen met Sealbag automaten (cash:out=yes), die zijn inmiddels opgelost.
@kesenai gaf de suggestie om amentiy=atm en indoor=yes te gebruiken maar dat werkt niet voor mij, dat is een automaat. Ik heb maar gekozen voor shop=money en gebruik daarvoor de adres node. De geldmaten in de winkel worden gewoon als amentiy=atm getagd.
Wat betreft openingstijden, dit kom ik zo af en toe tegen:
opening_hours=Mo-Su 00:00-01:59,07:00-23:59
https://locatiewijzer.geldmaat.nl/nl/location/8891001/
Iets voor uitgaanspubliek? Volgens mij betekend dit 07:00-02:00.
Ja drie nodes, ik heb ze inmiddels bijgewerkt zodat het script snapt welke welke is, goed te zien op S&P Oblique.
Offline: Ik moest even kijken, This is the Worst Intersection in the Netherlands
Verder zag ik dat @lyctkel en @Kees_59 ook goed bezig zijn.
Wat nieuwe statistieken:
Verdeling van automaten in de Geldmaat data:
cash_out:notes)cash_out:notes + cash_in:notes)cash_in:coins)cash_in:sealbags)cash_out:coins)679 ref matches
220 addr matches
898 1-on-1 matches
2771 ATM's in openstreetmap
2213 Geldmaat
151 <unknown>
118 Rabo
62 ING
41 Byecoin
38 Euronet
33 ABN
30 GWK
27 YourCash
20 SNS
10 AllTransact
8 Global ATM Network
7 In2Retail
4 Regiobank
3 ASN
Ik ga eens kijken naar de mismatch tussen 2213 Geldmaten in OSM en 898 1-on-1 matches.
Het script genereert ook een geopackage en dat ziet er in QGIS zo uit voor mij:
Oranje is Geldmaat, blauw OSM. Een kruis is geen match, een cirkel een 1-op-1 match, een ster een 1-op-meer match. Die laatste categorie is nog niet bijgewerkt voor meer machines binnen een geldmaat locatie.
Lijkt me ook handig voor anderen, dus hier een link naar mijn pCloud drive:
Zou hopelijk hetzelfde moeten werken als:
Ben benieuwd hoe je dat hebt gedaan, zie er momenteel geen tag op zitten waarmee je de koppeling naar een specifieke automaat zou kunnen maken. Ik had zelf de ref al toegevoegd op basis van de Geldmaatwebsite maar die is gelijk voor alle automaten op die plek.
Top! Ook weer een mooie gelegenheid om QGIS weer eens te installeren. Openen vanuit het menu (Project > Openen vanuit > Geopackage) werkte niet omdat er dan geen selecteerbaar project is in de dropdown. Wat wel werkt hier is het .gpkg-bestand in QGIS slepen.
edit: Nog een klein dingetje:
Merk er verder ook niets van want de tekst uit geopackage-data wordt netjes gerenderd. Misschien een verschil in systeem, heb hier wel Liberation Sans maar geen Open Sans.
Oranje kruis is dus wel in locatiewijzer maar niet in OSM. in elk geval twee van die situaties in Nijmegen centrum zijn automaten binnen een winkel (Primera en AH). Hierbij staat in OSM atm=yes op de winkelnode. Als ik dit topic goed begrijp is het de bedoeling dat er alsnog een aparte node voor de ATM bijkomt met indoor=yes en note=in {winkelnaam}?
Het antwoord hierop is min of meer te vinden onder “Verdeling van automaten in de Geldmaat data:” in mijn vorige post maar dit is de python code:
key2functionality = {
'cash_out:notes': 'Geldautomaat',
'cash_in:notes': 'Geld storten en opnemen', # Note also has cash_out:notes
'cash_in:coins': 'Muntstortautomaat',
'cash_in:sealbags': 'Sealbag-automaat',
'cash_out:coins': 'Muntrolautomaat',
}
functionality = 'Geldautomaat'
for key in key2functionality:
if key in atm_data['tags'] and atm_data['tags'][key] in ['yes', 'customers']:
functionality = key2functionality[key]
Goed te horen dat de geopackage werkt voor jou.
Inderdaad een Oranje kruis is waren volgens Geldmaat wel een geldautomaat staat maar geen OSM node te vinden is. Wel neemt het script ook nodes met atm=yes mee, die zouden dus als blauwe node te vinden moeten zijn, als je aanwijzingen heb dat dit niet zo is dan hoor ik het graag. Deze Geopackage is gebaseerd op ref + adres matches en afstand-matches voor < 20 meter.
Ja, atm=yes zou vervangen moeten worden door een aparte geldautomaat node in zoverre er nog daadwerkelijk een geldautomaat te vinden is.
Heb geprobeerd om het topic goed terug te lezen maar mogelijk nog wat informatie gemist, bedankt in elk geval voor de opheldering. Als het 20 meter is dan is het wel te verklaren. De node van de AH staat >30 meter van de pin uit de locatiewijzer af. Die node heeft qua ref natuurlijk ook geen match met Geldmaat. Wat ook niet mee heeft geholpen is dat AH op verkeerde adresnode stond, meteen maar even gecorrigeerd.
Automaten bij Winkelcentrum Malden ook bijgewerkt. Ben benieuwd of ze nu wel goed gematcht kunnen worden. Dit is een lastige misschien voor het script omdat de pin te ver weg staat (60 meter ongeveer) en het adres dat Geldmaat meldt niet klopt voor het gebouwtje: https://www.locatiewijzer.geldmaat.nl/nl/location/6581007/ (er staat ook nabij) Deze ref is nu wel op 2 ATMs toegepast. Op de Geldmaatnodes staat wel het correcte BAG-adres.
Grappig is dat op het bonnetje het nummer van de specifieke automaat terugkomt. Dit staat ook in de data van Geldmaat API. Lijkt me niet heel zinvol om dit in OSM op te nemen omdat we al een ref hebben. Of het moet iets als ref:machine worden?
De eerste stap van het script is het matchen van de ref zonder naar de afstand te kijken. Ik dacht gisteren, daar moet toch ik eens naar kijken en wat is beter dan een histogram…
n1005576453 - 5328001 56.1m
n3944383504 - 8525001 60.5m
n1229054873 - 5931006 61.7m
n887873815 - 5011003 94.1m
n4596103962 - 1082003 59.0m
n1121621937 - 3111003 84.7m
n12913158268 - 1503006 51.3m
n618282622 - 5764001 100.0m
n12914124927 - 6171002 170.9m
n2308198530 - 5658001 72.8m
n936519791 - 2851001 71.6m
n12077255840 - 44634 58.4m
n12974919489 - 44634 59.5m
n12974919490 - 44634 58.9m
n699155628 - 5171003 105.7m
n2496444447 - 2641001 103.4m
n12078521629 - 4681001 60.6m
n765570051 - 5628002 80.4m
n690094368 - 5628001 78.3m
n4906034396 - 9166002 52.0m
n6835229615 - 4841003 100.5m
n12983278104 - 4841003 101.2m
n10229467813 - 4691005 84.0m
n428040338 - 4462001 83.8m
n1719756033 - 3841004 73.7m
n599030244 - 5672002 60.7m
n1579337810 - 1602002 70.3m
n7442065975 - 4542001 55.3m
n4230768096 - 4336001 73.8m
n1274108446 - 8855001 288.7m
n1275862954 - 3335002 57.0m
n2741693545 - 3332003 194.0m
n12633096332 - 530110 80.3m
n12996832708 - 530110 83.2m
n12996832709 - 530110 81.6m
n3910273978 - 7707001 56.2m
n485808461 - 8441001 66.5m
n12993704567 - 79423 81.2m
n6271710546 - 7221001 69.4m
n3884065039 - 7412002 50.1m
n12917374646 - 1261003 71.0m
n5357511021 - 4697001 60.3m
n9123966490 - 2861001 63.2m
n1149234981 - 3845001 50.0m
n871978796 - 1824001 56.2m
n12978780374 - 1824001 56.2m
n10039427645 - 6581007 59.0m
n12997865913 - 6171001 109.7m
Conclusie beter een afstandslimiet van 50 meter gebruiken dan 20 meter.
Grappig is dat op het bonnetje het nummer van de specifieke automaat terugkomt. Dit staat ook in de data van Geldmaat API. Lijkt me niet heel zinvol om dit in OSM op te nemen omdat we al een ref hebben. Of het moet iets als ref:machine worden?
Nee, ref:machine lijkt me niet nodig, op zich zelf is ref denk ik al niet zo belangrijk voor gebruikers maar het maakt de Conflation wel een heel stuk makkelijker.
Het machine nummer staat ook niet in de Geldmaat data, zie bijv. de json data voor 6581007.
Daar staat het wel, daarom viel het me ook op:
Maar verder eens dat het voor de gebruiker weinig toevoegt.
Mwwh, goed dat er iemand mee kijkt
Ja, je hebt gelijk, op een gegeven moment dacht ik dat ook maar later kon ik het niet terug vinden.
Op zich zou ik dit nummer eerder in het ref veld zetten omdat het uniek is per machine, de locatie ref zouden we weg kunnen laten, die staat ook in de website link of location_ref?
Het zou voor mij geen probleem zijn om voor alle Geldmaat-OSM matches deze machine ref automatisch bij te werken.
Ja kan gebeuren, geen probleem om even mee te kijken 
Nadeel van dit veld vind ik wel dat je het ook alleen maar terugziet in de JSON-data (en het bonnetje). In dit voorbeeld zijn er twee automaten met duidelijk andere functionality, dus kun je op basis daarvan matchen en id toekennen, duidelijk. Maar als die gelijk is (zie eerder voorbeeld 2 x storten + opnemen. 1 x alleen opnemen) hoe weet je in het script dan welke machine-id er bij welke OSM-node hoort? Als we zulke specifieke data automatisch gaan toewijzen moet het m.i. ook wel correct zijn.
