mirror of
https://github.com/OpenEPaperLink/OpenEPaperLink.git
synced 2026-03-21 00:04:28 +01:00
[GH-ISSUE #155] Geocoding problem #3389
Assignees
sascha_hemi
Clear assignees
sascha_hemi
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/OpenEPaperLink#3389
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kvandt on GitHub (Nov 4, 2023).
Original GitHub issue: https://github.com/OpenEPaperLink/OpenEPaperLink/issues/155
Originally assigned to: @nlimper on GitHub.
When selecting a location on Current Weather, Weather forecast and Buienradar content, I can only type the name of the place. Since I live in Soest (in The Netherlands) I enter "Soest". The geocoding ends up with Soest in Germany. I cannot change this by entering "Soest NL", "Soest Utrecht" or whatever variant. For Buienradar content, I managed to change the Lat/Lon values in the tagDB.json and they remain, so this is a relatively simple manual correction. When doing the same for Current weather and Weather forecast, the geocoding is continuously redone (because the Lat Lon values keep being overwritten for Soest Germany).
To Reproduce
Expected behavior
I would expect the geocoding (getLocation) to be done only once (saves a lot of API calls to open-meteo), when entering the cityname. A city does not move... When manually updated Lat/Lon values, these should be kept.
Ideally the Lat/Lon values can be edited from UI. So you enter a cityname, Lat/Lon values are retrieved from geocoding and presented in the UI, then accept manual change and save.
Edit: There seems to be something strange as well in the Geocoding API: If I send
https://geocoding-api.open-meteo.com/v1/search?name=soest%2C+nederland&count=2&language=en&format=json(count = 2), then I get 1 result. If I do the same with count = 1
https://geocoding-api.open-meteo.com/v1/search?name=soest%2C+nederland&count=1&language=en&format=jsonthen I do not get a result.
@scottjl commented on GitHub (Nov 27, 2023):
same issue here. would be easier if the latitude and longitude fields weren't locked. i'm in a city in the US with a rather common name, typing in my city name alone gets the wrong state. as it currently is, weather is pretty much useless (which is one of the main reasons i wanted these).
@nlimper commented on GitHub (Dec 30, 2023):
fixed, unlocked the lat/lon fields
424cf2faf6@kvandt commented on GitHub (Jan 1, 2024):
Hi Nic, I see you fixed this for the weather forecast and current weather, bit not for Dutch buienradar. Can you do the same magic for this content type?
@nlimper commented on GitHub (Jan 1, 2024):
done (on my internal development file, it will show up in some later commit).
If you want to change it for your own install: download, unpack and edit /wwwroot/content_cards.json.gz and change
"type": "ro"to"type": "text"in the Buienradar part, that's all.@kvandt commented on GitHub (Jan 2, 2024):
I modified the code, and can now update the Lat/Lon. But every update the Lat/Lon are overwritten by a geocoding call. This geocoding call should only happen once when entering the location.
So unfortunately the fix is not done yet...
EDIT: I now recall that I already knew this. When manually modifying the Lat/Lon in the json configuration file, it was overwritten at the first update... Ideally the geocoding would be done on explicit request (with a button after entering the location). Then no automated magic needs to happen.
@nlimper commented on GitHub (Jan 5, 2024):
yeah, I need to work on the some more. :-) I reopened this issue.
@kvandt commented on GitHub (Jan 5, 2024):
Thnx. It looks like the
cfgobjparameter is not correctly filled (or updated) when enteringgetLocation. Even when lat / lon are filled, it apparently does meet theif (util::isEmptyOrNull(lat) || util::isEmptyOrNull(lon)) {statement and therefore does a new geocoding. Unfortunaltely I cannot debug this.Must be something between the "save" of the tag config in the webpage, and entering the first update of the buienradar/weather/forecast.
@nlimper commented on GitHub (Jan 5, 2024):
no need to debug it, I know exactly what the problem is. :-)
The #lat and #lon are hidden fields, they are not saved at the front end side. But also, I want to make a nicer solution.
But anyway, for now, just fill in a more unique place name of a location nearby.
@kvandt commented on GitHub (Jan 5, 2024):
Clear on the hidden fields... But does this also explain why it does not work when I edit the lat and lon values in the tagDB.json file on the ESP? The first update of the tag still triggers a geocoding call.
I now use Soestdijk, which works for me but does not look nice when living in Soest ;-)
@nlimper commented on GitHub (Jan 6, 2024):
tagDB.json is just a copy of the actual database that is in memory, which is saved every 5 minutes. If you edit tagDB.json and want to use it, you should pull the power plug after editing, because if you reboot any other way, the databasefile is overwritten with the version from memory.
@kvandt commented on GitHub (Jan 9, 2024):
Just tried 2.07b. I love the solution of showing a dropdown to select the "correct" location. For now it seems to work nicely. I will keep an eye on it. Thnx!
@nlimper commented on GitHub (Jan 9, 2024):
thanks for letting me know!