Parsing important bits (timestamp, lat, long) of tracks seems easy: 
https://github.com/tajtiattila/track

Track points could be stored in the index as "track|<wholeRef>|<timestamp>" 
→ "<lat> <long>".

I would like to have this to geotag photos without explicit location 
(EXIF/GPS or permanode attrs) so that they show up in search results and on 
the map UI.

To do this, Perkeep needs to know what permanode to use as the location 
history. This could be specified with the following permanode attrs:

    "type": "locationHistory"
    "locationHistory": "default"
    "camliMember": "sha1-foo"
    "camliMember": "sha1-bar"
    ...

The attr "locationHistory" would make it possible to add support for 
multiple location histories (eg. for photos from SO, kids, friends etc) in 
the future.


On Tuesday, December 19, 2017 at 8:30:30 PM UTC+1, Brad Fitzpatrick wrote:
>
> There have been discussions in the past, but no agreement on the schema 
> for storing it.
>
> Daily dumps is one way, but kinda gross. Also, how do you define a day? 
> UTC is one obvious choice, but would break many people's daily activity up 
> across two days. It'd be nice to make sure the cut point is when then they 
> were likely sleeping.
>
> Identifying "tracks" from the data and adding a permanode of a GPX or KML 
> file per track is another way.
>
> At the other far extreme, you could have one permanode ("Brad's Location") 
> and just constantly add new attribute update claims against that permanode, 
> updating the lat/long. But that's gross (and maybe taxing on the system) 
> for other reasons.
>
>
>
>
> On Mon, Dec 18, 2017 at 9:39 PM, Attila Tajti <[email protected] 
> <javascript:>> wrote:
>
>> I'd like to perkeep my location history. Have someone devised a system to 
>> do it?
>>
>> I have Google location history from Android (a big JSON file from google 
>> takeout), and GPX/KML from GPSLogger from Android.
>>
>> It should be possible to update location history. Obviously it grows with 
>> time, but also data in the past can change if it is corrected (eg. on the 
>> google maps timeline interface). Therefore it should not be stored as a 
>> single file but as a set of fragments (maybe one blob per UTC day?)
>>
>> The ultimate goal is to have the ability to assign an implicit location 
>> to elements without an explicit location such as photos and videos made 
>> with cameras based on the file time and a location history.
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Camlistore" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Camlistore" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to