API access to recorded point database

Would it be ok to direktly load the tracks.db file by using https://github.com/asamm/locus-api/blob/5bfd2b9143577c549943a1555842835882c083ad/locus-api-android/src/main/java/locus/api/android/utils/LocusInfo.java#L188 ?

It should be at /data/database/tracks.db

Or would you like to provide a content uri?

Good day Falco,

access to track database directly is, of course, possible, anyway not a recommended solution as changes in the database may not be handled correctly.

Access to content over content URI is definitely recommended a solution. If such access will be possible, it is not something directly useful for ordinary users. It is for developers only. There is interest in writing an application that requires this feature? If someone, maybe you, will want to write geo-tagging feature, be aware that you may simply import data into application so it is definitely not reliable to search for points based on time. More logical should be to pick one recorded track and geotag photos based on this track. And this is already doable by registering own function under track by this method.

Thank you for the quick response.

Is the whole track point list fetched into the track object?

https://github.com/asamm/locus-api/blob/35223423ffafcad3db2f051952810aa6fffe0c07/locus-api-core/src/main/java/locus/api/objects/extra/Track.java#L41

That could be alot of data.

Are phones fast enoght to load the whole point table of a single track into memory, or did you speed it up by skipping some location fields?

I thought about a usecase to geotag based on "file got copied into my watch folder" because tasker does already have watch folder, sql query and write exif tasks buildin. Is there a content URI for table "locations" to get only some points based on parent_id (trackid) and time? If not, I will start with geotag by track menu entry.

Yes, the whole track is loaded into this object without any skipping.

And yes, it may be quite big, up to 1Mb in memory, but it is usually not a problem for modern devices. It may anyway be a problem to send over Uri, because there is usually limited to 1 or 2Mb per cursor.

Anyway, Locus currently does not offer any other access to tracks, except over own item in the track menu. This gives you access to one single track ID which may be then used to load whole track content.

If there will be interest, I may try to offer any other options, just please be aware, that I'm currently little bit out-of-time, so I may refuse extra work on API if it will be more complicated (like perfectly working Uri to whole track database over ContentProvider system). Thanks for understanding.

Thank you for telling me the limit of track access. If I need more I would just go the unstable way and react on database changes. We don't need a stable way of selecting locations, that would be not flexible enoght enyway.

Here another reason why we should never implement API access to locations:

timebased SQL operation on locations table does only make sense if we have an locations_time index but this will expand database size by 10%!

No way that this should be applied to all users this is only needed for frequently geo taggers.

I will create both soltutions. One stable solution with track menu integration and one for power users with watch folder and time index.

Prof of conzept - closest match to timestamp 1529800000000:

CREATE INDEX IF NOT EXISTS "locations_time" ON "locations" (
	"time"
);

SELECT abs(1529800000000 - loc.time)/1000 time_diff, latitude, longitude, elevation, tracks.name, tracks._id FROM (
  SELECT latitude, longitude, elevation, parent_id, min(time) time FROM "locations" WHERE time >= 1529800000000
  UNION SELECT latitude, longitude, elevation, parent_id, max(time) time FROM "locations" WHERE time <= 1529800000000
) loc INNER JOIN tracks ON loc.parent_id = tracks._id
ORDER BY time_diff limit 1;

Good day Falco,

hope you will find good usage for your experiments and invested time :). Please just keep in mind that is possible that the structure of the database may change in the far future. And good luck.