Open seniorm0ment opened 3 years ago
Nice idea but osmand shows info/maps from openstreetmap that doesn't contains such data. I think that the plugin should be developed for this. Can you show some examples of such services?
It would have to be a plugin/overlay of course yes. I don't use any of the apps because they're all pretty privacy unfriendly and not libre, however I know there are many apps. Just try searching "gas price" or something and I know there's multiple apps. I know https://www.gasbuddy.com/ is one with a website.
From #13866:
This data can be tagged in OSM directly. See
charge:conditional
.That way, it's available for everyone, worldwide. All while preserving freedom (rather than yet another proprietary plugin, as a workaround).
The problem of maintaining recent prices remains, regardless. However, a StreetComplete quest could solve that.
While prices (in machine-readable format) are a nice-to-have (automation for the win), there's a whole lot more basic data to add, first. Such as which fuels are available at each station.
Edited it add: found some real examples via Overpass Turbo. There seems to only be a handful in the world, so far.
However, as for data sets / sources:
France-only: OpenFuelMap. Seems to get the data from a published dataset (perhaps a result of regulatory requirements).
In Spain have the fuel price on https://geoportalgasolineras.es/#/Descargas
We in austria also have some kind of api but I don't know if it's allowed to be used without permission. Example: https://api.e-control.at/sprit/1.0/search/gas-stations/by-address?latitude=46.9&longitude=15.3&fuelType=SUP&includeClosed=false
I think the main problem here is that every api has a different format, so there has to be some way for users to contribute the schema of specific apis
Does anyone know what became of OSMFuel? It would be awesome to have an open source alternative to gasbuddy, even though it means we would have to create our own version of their database (I definitely would be willing to help pay for it), as discussed in:
The stated reason is that although basic data is in OSM, such as which fuels are available at each station, it's considered good practice to "don't map temporary events and temporary features". However, creating such a separate database would be the most straightforward way to allow different users from different countries that use different APIs to connect their data into a common database. And of course, most governments are so backwards that such an API doesn't even exist for all but a handful, so the only way to get the data would be crowdsourcing (e.g. fueleconomy.gov just links to gasbuddy).
Noting that GasBuddy’s API is purportedly public: https://www.reddit.com/r/homeassistant/comments/xaairs/comment/int949q/
resource: https://www.gasbuddy.com/graphql
method: POST
headers:
Content-Type: application/json
payload: |
{
"operationName": "LocationBySearchTerm",
"variables": {
"fuel": 1,
"maxAge": 0,
"search": "YOUR_ZIP_HERE"
},
"query": "query LocationBySearchTerm($search: String) { locationBySearchTerm(search: $search) { trends { areaName country today todayLow } } }"
}
Of course it would be better to load the data from a community resource only, and let users provide their prices as they change, as gasbuddy does.
GasBuddy is probably the way, but I have a possibly unrealistic dream for an app or plugin:
You take a picture of the prices, either on the pump ⛽ or on the sign 🪧, and the data is extracted and posted to the community database. It might even be able to include octane ratings. The reason it might be possible is that the price display tends to follow very predictable patterns.
You could do that with a compiled ml vision model.
Projects based solely on user activity have never become fully functional. Only those apps that operate on the basis of information provided by stations by law, enforced by governments, work properly.
Sad but true
I just had this idea and was wondering why this isn't a thing yet (not just for this but any map application), then I did a search because I'm sure others have had the same and I didn't want to make a new issue if one already existed.
To expand on this though, it would be great when using navigation if it would suggest the cheapest station between start and end points.
Possibly with a modifier of how far off the route you'd be willing to travel (within reason.) Be even cooler if it would tell you not to bother because the cost of spent gas would negate any money actually saved.
Could possibly even make it offline and then just download the updated gas data for that region. Maybe even localize it since I wouldn't need my entire state's data but just a few counties I might be traveling through.
Projects based solely on user activity have never become fully functional. Only those apps that operate on the basis of information provided by stations by law, enforced by governments, work properly.
Sad but true
I'm pretty sure GasBuddy started out that exact way (I'm not sure if it still works that way though since I don't have an account) and Waze is still around too. Trapster has been gone a long time but it can be argued that it was pretty successful in its heyday.
But not fully functional is fine, people can use it if they want or not. It might suffer in rural areas but I'm sure it would do well in the metropolitan ones and maybe even the suburban ones too.
It looks to me like the big blocker here is simply somebody doing the work to implement something useful. Likely there’s been discouragement in the past because of small controversies around different parts, but it’s still possible for somebody to step in and do work, controversies or not.
Note, alternatives to formal systems for accurate results include trust networks and curation models, kind of a separate problem though. Reaching out to companies and governments for data is another path.
The ability to see the cheapest gas prices around your current position would be a very nice feature introduction, especially with the current high gas prices. There are a handful of sites that have this data, I'm not sure which allow scraping.