I created a PR to add deposit locations and taromats to Osmalyzer: https://github.com/OSMLatvija/Osmalyzer/pull/32
Here's file with data used there (converted to CSV for ease of working): file
Thanks! I assume nothing matches in Riga for kiosks because the conversion to kiosk/amenity is ongoing from that other topic?
Yes. Precisely that.
Riga has a lot of them =((
https://osmlatvija.github.io/Osmalyzer/Depoz%C4%ABta%20punkti%20report.html
What an absolute mess that data is for the fields that are supposedly machine-readable...
HellMap said:
What an absolute mess that data is for the fields that are supposedly machine-readable...
I could not agree more.
Also, there is a problem I just noticed, that cannot be solved programmatically: their map considers "punkts" as an organizational unit. And thus two kiosks near this Maxima (yet to be converted back, but you'll get what I mean) are not separate items(
And who knows how many more of this is present.
Hmmm... urgh. :melting_face:
The current Correlator© does not deal with multi-matches, but it theoretically could. I am not sure how I even would extend it to do that - this is probably soemthing extremely convoluted as now I need "range of elements that may be grouped as one logical element". I guess one could group semi-identical OSM elements close to each other into a "superelement" and let the correlator treat it as a single point.
I guess we can see how many of these will be on the map once some tagging is fixed, so I'm not adding complex functionality for like 2 stores
Although I suppose if we micromap vending machines that are in stores - they will totally repeat
HellMap said:
The current Correlator© does not deal with multi-matches, but it theoretically could. I am not sure how I even would extend it to do that - this is probably soemthing extremely convoluted as now I need "range of elements that may be grouped as one logical element". I guess one could group semi-identical OSM elements close to each other into a "superelement" and let the correlator treat it as a single point.
I feel like it would be easier to try and guess where 1 json object ~ 2 kiosks. At least for this problem.
And I've seen your issue about manual ticking issues like "it should be this way": it would be beneficial in this case =)
But I'm not ready to commit to implementing something like this for now.
Is it actually possible to guess from the data?
Guess - for sure.
Get a somewhat reliable result - don't know. Will need to reference content of the csv I've sent earlier with reality.
And I'm pretty sure that at least for now two kiosks as a part of same location is something out of hand. Doubt it will be more than a handful of them.
HellMap said:
The current Correlator© does not deal with multi-matches, but it theoretically could. I am not sure how I even would extend it to do that - this is probably soemthing extremely convoluted as now I need "range of elements that may be grouped as one logical element". I guess one could group semi-identical OSM elements close to each other into a "superelement" and let the correlator treat it as a single point.
...which could hide accidental items that are duplicated in OSM data?
Yeah, I suppose. This is why I describe this as a convoluted issue and it would need to be smart enough to not cause false negatives. I suppose it would be impossible to tell if someone, for example, mapped a new DP building instead of moving an existing one if it suddenly gets relocated.
Manual exceptions (or just ignoring the known one or two cases) seem to make the most sense :)
Welp, kiosks can have "vidējais" machine in data, so RIP being able to distinguish kiosks even from that. May be the data is old or wrong though. For example, https://www.openstreetmap.org/way/1283887212 is a kiosk but data has 23019 - A - vidējais taromāts - Automatizēta pieņemšana
. The kiosk has been there for about 2 years, so I'm assuming it was always a kiosk.
Hm. Maybe we should hide Kiosks part for now. I feel like with it's consistency, it might bring more problems than solutions.
Last updated: Dec 22 2024 at 05:29 UTC