You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm in the process of migrating from Google Timeline to Owntracks Recorder. It sounds like using the importer isn't ideal and so I've been following that blog entry (and others who are doing the same) to extend and improve that python import code to consume the Google Timeline JSON and render it into Owntracks rec files.
This has worked well. And I want to acknowledge that this method of importing historical data is not supported (as it's not going through the recorder API and instead just being written to the store files directly)
My question is, what would the best way be to get timezones working on this historical data. I've noticed that data points that are in the same timezone that I'm in do render correctly. I'm assuming this is because
I'm adding new records from the Android app through the recorder API
The recorder is doing the correct reverse geocoding and capturing in the LMDB database timezone information on those new records
The recorder API understands that these historical data points are "near" to the new data points and so they must have the same timezone
or maybe the recorder just shows times in the browser's local timezone when it doesn't know the timezone of the data point?
(correct me if I'm wrong)
The problem with missing this timezone data for historical records is that it looks like they just display in my local timezone which makes the time of day for the data points displayed incorrect.
I know I can't do reverse geocoding on 13 years of data. I'm wondering if there's a way to seed the minimal number of historical reverse geocoded data points in other timezones so that all of the other historical data points in those timezones show up with the correct timezone correction.
The text was updated successfully, but these errors were encountered:
As long as you write the .rec files correctly, there is no reason why you shouldn't be creating them programmatically, that is perfectly acceptable.
That said, I am wondering whether there is a confusion between time zone data and reverse Geo coding. To respond to your second question first you could direct bulk reverse Geo code the date that you are importing into the rec files if you find a service which is willing to provide the data. We have had very very good experiences with OpenCage; you might want to look into their service offerings.
As for the time zone issue, I need a different explanation, please. There is no relationship between time zone and the LMDB database. The latter is used for reverse geocoded information
I'm in the process of migrating from Google Timeline to Owntracks Recorder. It sounds like using the importer isn't ideal and so I've been following that blog entry (and others who are doing the same) to extend and improve that python import code to consume the Google Timeline JSON and render it into Owntracks
rec
files.This has worked well. And I want to acknowledge that this method of importing historical data is not supported (as it's not going through the recorder API and instead just being written to the store files directly)
My question is, what would the best way be to get timezones working on this historical data. I've noticed that data points that are in the same timezone that I'm in do render correctly. I'm assuming this is because
or maybe the recorder just shows times in the browser's local timezone when it doesn't know the timezone of the data point?
(correct me if I'm wrong)
The problem with missing this timezone data for historical records is that it looks like they just display in my local timezone which makes the time of day for the data points displayed incorrect.
I know I can't do reverse geocoding on 13 years of data. I'm wondering if there's a way to seed the minimal number of historical reverse geocoded data points in other timezones so that all of the other historical data points in those timezones show up with the correct timezone correction.
The text was updated successfully, but these errors were encountered: