Added an address field to the returned location packet.

[wir3z]

Contains the geocoded address, if available, or the lat/lon if not.

[wir3z]

I realize that there are situations where the phone geocode will not resolve the address, but this reduces the expense of having to do that same work server side now that Google has reduced the free geocode tokens per month..

[ckrey]

I think this approach was discussed and rejected a while ago: owntracks/ios#769

[wir3z]

How rate limited is iOS? Android will also rate limit, but you need to be sending a lot of geocodes in succession.

Issue I'm trying to address is Google has reduced their free credit tier for geocodes. If you have 4-users on OwnTracks, and I configured the recorder to use Google as a geocode service, I'd end up with a $100 Google bill every month for this. Others have seen much worse depending on update frequency.

I was coupling this into a different server side app, using the phone addresses when available (which is most of the time) and then back filling with server side geocode to address the over charge issue.

[jpmens]

The recorder cashes Geo look ups so if those four users are frequently together, and the geohash width isn't too high then caching should reduce the look up frequency.

As an aside: have you compared limits to those in Opencage's free tier?

[wir3z]

What I was seeing is all users are semi-independent, which was resulting in a bill from Google for exceeding the free credits on geocoding.

Opencage changed their tiers when Google restricted theirs. Opencage gives 2500/day, but it you are caught using it more than short term testing, you will be get blocked.

[growse]

~~I seem to remember there's a ToS constraints on both the Google and opencage geocoders that their returned results are for display only and not transmission/storage.

Might be hallucinations, will have a look tomorrow~~.

Edit I'm wrong about opencage.

I'm not against this in principle, but I think it should be a user preference (default off).

(On my phone, not done a review yet, so you may have already added this in).

We'd also presumably need a tweak to the recorder to detect the incoming address on the wire and add that to the db, rather than doing a lookup on the recorder side @jpmens ?

[wir3z]

Let me know if it is something you'd accept, and I can rework with a user preference.

[jpmens]

OpenCage explicitly permits storage.

[jpmens]

Our primary data source is OpenStreetMap, which means you can store data as long as you like, display it on any map, use it publicly or privately, for any usecase, on the web, in print, or behind a firewall.

https://opencagedata.com/guides/how-to-compare-and-test-geocoding-services

[wir3z]

~~I seem to remember there's a ToS constraints on both the Google and opencage geocoders that their returned results are for display only and not transmission/storage.

Might be hallucinations, will have a look tomorrow~~.

Edit I'm wrong about opencage.

I'm not against this in principle, but I think it should be a user preference (default off).

(On my phone, not done a review yet, so you may have already added this in).

We'd also presumably need a tweak to the recorder to detect the incoming address on the wire and add that to the db, rather than doing a lookup on the recorder side @jpmens ?

Are you thinking a new slider in the "Preferences -> Reporting" section, similar to "Extended Data"? Or just couple this with the "Extended Data"?

[jpmens]

(TIL github notifications don't trigger when added during an edit.)

tweak to the recorder to detect the incoming address on the wire and add that to the db,

doable if we know which JSON element to detect on

[growse]

~~I seem to remember there's a ToS constraints on both the Google and opencage geocoders that their returned results are for display only and not transmission/storage.

Might be hallucinations, will have a look tomorrow~~.

Edit I'm wrong about opencage.

I'm not against this in principle, but I think it should be a user preference (default off).

(On my phone, not done a review yet, so you may have already added this in).

We'd also presumably need a tweak to the recorder to detect the incoming address on the wire and add that to the db, rather than doing a lookup on the recorder side @jpmens ?

Are you thinking a new slider in the "Preferences -> Reporting" section, similar to "Extended Data"? Or just couple this with the "Extended Data"?

This feels "extended data" to me. I think we put stuff in there that's platform-specific, and we're not (I think) going to be doing this on iOS any time soon?

Good place to start and see how it fits.

[ckrey]

The recorder includes address data from its geohash database as follows including country, locality, tzname and local time.

      ...
      "ghash": "9q9hrj4",
      "cc": "US",
      "addr": "West Homestead Rd, Cupertino, CA 94087, USA",
      "locality": "Cupertino",
      "tzname": "America/Los_Angeles",
      "isolocal": "2025-04-01T01:27:28-0700"
      ...

When sending any of these value to the recorder, we may want to use different key e.g. add a prefix:

        "client_cc":
        "client_addr":
        "client_locality":
        "client_tzname":
        "client_isolocal":

We will have to decide whether recorder will update its Geohash database from the client provided data and how to deal with situations where database address and client provided address data are both available

[wir3z]

I seem to remember there's a ToS constraints on both the Google and opencage geocoders that their returned results are for display only and not transmission/storage.
Might be hallucinations, will have a look tomorrow.
Edit I'm wrong about opencage.
I'm not against this in principle, but I think it should be a user preference (default off).
(On my phone, not done a review yet, so you may have already added this in).
We'd also presumably need a tweak to the recorder to detect the incoming address on the wire and add that to the db, rather than doing a lookup on the recorder side @jpmens ?

Are you thinking a new slider in the "Preferences -> Reporting" section, similar to "Extended Data"? Or just couple this with the "Extended Data"?

This feels "extended data" to me. I think we put stuff in there that's platform-specific, and we're not (I think) going to be doing this on iOS any time soon?

Good place to start and see how it fits.

I pushed a patch moving it to the extended data field.

[wir3z]

Another question, is there a way to trigger the jobs on the patch push? It seems the last didn't trigger anything.

[growse]

/run-tests

[github-actions]

Build & Test complete. ✨
View workflow run

[wir3z]

/run-tests

[wir3z]

/run-tests

[wir3z]

/run-tests

The above doesn't seem to work for me. Github isn't picking up the action?

[wir3z]

Can I get git actions re-triggered on this one?

[growse]

/run-tests

[growse]

Can I get git actions re-triggered on this one?

Currently it only takes commands from project maintainers. Should probably add PR authors to this too....??

[github-actions]

Build & Test complete. ✨
View workflow run

[wir3z]

It's got a clean build now, but fails on 'Push to default publish to internal track'. Is that outside my scope?

Oh wait is that separate from the actions?

[wir3z]

Can I get git actions re-triggered on this one?

Currently it only takes commands from project maintainers. Should probably add PR authors to this too....??

Seems that without that magic power, it doesn't allow me to push a patchset and re-trigger the tests.

[jpmens]

/run-tests

[jpmens]

(Just guessing from previous comments 😇)

[wir3z]

Thanks!

[github-actions]

Build & Test complete. ✨
View workflow run

[wir3z]

Is there a difference between the Android Studio ktfmt (1.3.0.61) and what runs with the git actions? Locally, it's not recommending any changes, the actions are failing with:

Task :app:ktfmtCheckMain
[ktfmt] Invalid formatting for: /home/runner/work/android/android/project/app/src/main/java/org/owntracks/android/services/MessageProcessor.kt
[ktfmt] Invalid formatting for: /home/runner/work/android/android/project/app/src/main/java/org/owntracks/android/services/LocationProcessor.kt
[ktfmt] Invalid formatting for: /home/runner/work/android/android/project/app/src/main/java/org/owntracks/android/services/BackgroundService.kt

[growse]

Is there a difference between the Android Studio ktfmt (1.3.0.61) and what runs with the git actions? Locally, it's not recommending any changes, the actions are failing with:

Task :app:ktfmtCheckMain
[ktfmt] Invalid formatting for: /home/runner/work/android/android/project/app/src/main/java/org/owntracks/android/services/MessageProcessor.kt
[ktfmt] Invalid formatting for: /home/runner/work/android/android/project/app/src/main/java/org/owntracks/android/services/LocationProcessor.kt
[ktfmt] Invalid formatting for: /home/runner/work/android/android/project/app/src/main/java/org/owntracks/android/services/BackgroundService.kt

Shouldn't be..... that's weird. Let me see what happens locally for me.

[growse]

Yeah, running just format (which is basically gradle app:ktfmtFormat) makes changes. I'm sus about android studio's formatter.......

[wir3z]

/run-tests

Ok, that worked. Can I get someone to trigger the tests again please? :)

[jpmens]

/run-tests

[github-actions]

Build & Test complete. ✨
View workflow run

[wir3z]

/run-tests

[wir3z]

Sorry. need tests one more time (needed to merge master).

[jpmens]

/run-tests

[github-actions]

Build & Test complete. ✨
View workflow run

[wir3z]

Just poking if I need to do anything further on this one.