-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow additional sources for my.location #154
Comments
Once Im done with splitting the databases by type, I think it would make sense to move the Since for locations here, this uses the Could also merge the gpslogger module here, and then make |
Another thing I've been thinking about for fallbacks (other than just Haven't looked into how to do that/if its possible, but is something I wanted to look into (maybe hooking into some API which has flight data?) My locations only go back to about 2015, but if I can use old passports to figure out flights or something, it could go back to something like 2000 |
Some other things to consider as well:
|
btw maybe makes sense to keep accuracy in meters? it's actually present in google takeout data, e.g.
Then for IP data it could be either some ridiculously big number (city radius? :) ), or just
yeah let's got for
Yep, that would be great! |
Yeah, that makes sense -- the bool was a quick fix on my end
reason I named it I think to allow for deprecation of the current google takeout files here, I could name it |
Just a list of things to keep in mind for the migration to the new takeout parser:
|
Dont expect any changes on this problem any time soon, just creating this issue to track the problem I'm having
Currently I have to overlay
time.tz.via_location
, since I use a different data source (combined from gpslogger, ips from google, facebook, discord etc)On this repo, it uses
location.google
to grab that info. Slightly unrelated, but I've also parsed the takeout using lxml instead, so my structure there is differentI would prefer if there was a common entrypoint (like
my.location.all
) that could take multiple entrypoints as input, falling back to empty iterators if they aren't enabled/fail to be imported, as that would localize my overlayed changes to themy.location
packageYou can see the current structure for
my.location
hereI created this following the discussion we had regarding merging pushshift data
I've also slightly modified the Location NT, so it can track whether this source was from an accurate (e.g. Google or gpslogger) or estimate (geolocation based on ip)
Am a bit conflicted on how to handle this many data sources...
Would need some modifications, would probably create individual files for:
google
apple
(locations from gdpr export)ip-based
(need inidividual empty fallbacks forblizzard
,facebook
,discord
)gpslogger
Some of those could stay on my branch if you're not interested in having them here, I think its more important to have the following here:
common.py
file, including:Location
NT which all other location providers would convert their NT/DTs tomerge_locations
function, with the typicalset
/emitted
behaviorThen, to enable additional
location
providers, I could either just overlay theall.py
file, including my additional imports -- which probably wouldn't ever have to be changedSomething like what was described in the comment here
If there are no issues you foresee here, I'm willing to implement this at some point in the future.
Will probably not touch the
location.google
file here, except to create a standard interface across all the submodules whichall.py
would then import from.Also, unsure if you settled on using
all.py
ormain.py
, I tend to preferall.py
for namespace packages which are merging multiple data sourcesThe text was updated successfully, but these errors were encountered: