Location data

[bdil...@peachbush.com]

I understand (and see) how photos with GPS data are parsed and you can search for location... no problem there.

What about photos that don't have GPS data? I could add it via EXIF before import, but I would think it could be nice to add as a parameter (that is then recognized) inside of Camlistore.

Actually, I would (ideally) be able to assign locations to things beside pictures (files, notes, whatever) and search them the same way...

Not implemented, or am I missing the obvious?

:-)

Thanks all...

[Mathieu Lonjaret]

I believe this is pretty much
https://github.com/camlistore/camlistore/issues/778 and related to
https://github.com/camlistore/camlistore/issues/777

> --
> 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 camlistore+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Attila Tajti]

After being stuck with the issues mentioned by Matthieu and seeing the problem with time values in Exif spec itself (no timezone) I decided to experiment with file metadata formats instead.

In the end I started my own Exif package which can also write exif metadata, not just read it like github.com/rwcarlsen/goexif does. With it one could embed GPS location in the jpeg file, perhaps based on location attributes of its permanode in camlistore.

The function indexEXIF pkg/index/receive.go stores all Exif tags in their original, close to raw format. Perhaps some fields should have special processing:

- GPSLatitude/Longitude in float instead of rational array

- GPSTimeStamp (rational) recorded together with GPSDateStamp in RFC3339

- time stamps (DateTimeOriginal and DateTimeDigitized) should use RFC3339 (without TZ when missing from exif)

These could then be returned similar to media tags in search.Describe. One problem is that there are at least 117 exif tags I found in the spec (see github.com/tajtiattila/metadata/blob/master/exif/exiftag/name.csv). Perhaps we should just store (and implement query and describe for) selected tags instead, like it is done for audio files.

[Mathieu Lonjaret]

Thanks for the reminder about that issue.

Given that:
1) the search pkg already supports looking for a location, and that it
looks for either a permanode based location, or a file based location
2) there currently is no way for a user to effectively set a location
on a permanode (because the indexer will ignore it)

then I think the most urgent item is to let a user set a (GPS
coordinates) location on a permanode as simply as possible, isn't it?

I may be missing a point that was made in
https://github.com/camlistore/camlistore/issues/778 against, and if
so, please point me to it.

Attila, if you agree with the above, do you think
https://camlistore-review.googlesource.com/6456 could become the
implementation for it? In any case, I'll have another look at it
tonight.

[Attila Tajti]

The fairly straightforward change in corpus.go (Corpus.PermanodeLatLong) in https://camlistore-review.googlesource.com/6456 would enable geotagging using permanode attributes "latitude" and "longitude", i.e. they would show up in location searches, but would not filter photos having another location in Exif.

The other bits of https://camlistore-review.googlesource.com/6456 are about returning the Exif location info already in the index.

I don't know if location info is so important that it warrants special handling. Perhaps it would be better to return everything (or just selected fields) from Exif instead. That would complicate location attribute lookup a bit for clients like the map UI from Eric, because clients would need check first the permanode attrs, and if they are missing also try the file tags/attrs (once they are returned in DescribedBlob). 

Attila

On 25.07.2016 20:25:56, Mathieu Lonjaret <mathieu....@gmail.com> wrote:

Thanks for the reminder about that issue.

Given that:
1) the search pkg already supports looking for a location, and that it
looks for either a permanode based location, or a file based location
2) there currently is no way for a user to effectively set a location
on a permanode (because the indexer will ignore it)

then I think the most urgent item is to let a user set a (GPS
coordinates) location on a permanode as simply as possible, isn't it?

I may be missing a point that was made in
https://github.com/camlistore/camlistore/issues/778 against, and if
so, please point me to it.

Attila, if you agree with the above, do you think
https://camlistore-review.googlesource.com/6456 could become the
implementation for it? In any case, I'll have another look at it
tonight.

You received this message because you are subscribed to a topic in the Google Groups "Camlistore" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/camlistore/QKT1kpnvGoo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to camlistore+...@googlegroups.com.

[Mathieu Lonjaret]

On 25 July 2016 at 20:51, Attila Tajti <attila...@gmail.com> wrote:
> The fairly straightforward change in corpus.go (Corpus.PermanodeLatLong) in
> https://camlistore-review.googlesource.com/6456 would enable geotagging
> using permanode attributes "latitude" and "longitude", i.e. they would show
> up in location searches, but would not filter photos having another location
> in Exif.
>
> The other bits of https://camlistore-review.googlesource.com/6456 are about
> returning the Exif location info already in the index.
>
> I don't know if location info is so important that it warrants special
> handling.

I think location is a pretty damn important info for humans, and
therefore we do need to have a way to make it easily
searchable/described to clients. And to let whatever's in a file (EXIF
GPS) be overriden by whatever is set in the containing permanode (if
the info is more recent, as usual).

> Perhaps it would be better to return everything (or just selected
> fields) from Exif instead.

Yes, we could do as you were saying for the audio attrs, and index a
lot of the EXIF that way, but I think we should do that in addition to
the above (and probably later on).

> That would complicate location attribute lookup a
> bit for clients like the map UI from Eric, because clients would need check
> first the permanode attrs, and if they are missing also try the file
> tags/attrs (once they are returned in DescribedBlob).

I don't think that's such a terrible idea to let the clients parse the
described blobs and decide where they want to get their info from.
That's kindof what the webUI does when e.g. it chooses what title it
should show for an item (filename if exists VS title attr on the
permanode VS blobRef if all fails).

imho, the key is what we decide to do with Location
*camtypes.LocationInfo in DescribedBlob, and how we define
camtypes.LocationInfo. The rest should follow from there. See
corresponding comment in CL please.

[bdil...@peachbush.com]

I think location is a pretty damn important info for humans, and

therefore we do need to have a way to make it easily
searchable/described to clients. And to let whatever's in a file (EXIF
GPS) be overriden by whatever is set in the containing permanode (if
the info is more recent, as usual).

Agreed :-)
 

> Perhaps it would be better to return everything (or just selected
> fields) from Exif instead.

Yes, we could do as you were saying for the audio attrs, and index a
lot of the EXIF that way, but I think we should do that in addition to
the above (and probably later on).

Also agreed... the more returned the merrier, if I understand. Would let you search on camera type, etc.
 

I don't think that's such a terrible idea to let the clients parse the
described blobs and decide where they want to get their info from.
That's kindof what the webUI does when e.g. it chooses what title it
should show for an item (filename if exists VS title attr on the
permanode VS blobRef if all fails).

imho, the key is what we decide to do with Location
*camtypes.LocationInfo in DescribedBlob, and how we define
camtypes.LocationInfo. The rest should follow from there. See
corresponding comment in CL please.

I agree with a "search order" defined by the client. Or I guess it would be possible for the client to support the user choosing, as long as the data is available.

Anyhow, I like the idea of giving the user a way of adding the data at the permanode level, and using that, and if it doesn't exist, looking at the file level, etc.

Thanks!

 

[Attila Tajti]

Location info is very important to me (that is why I made the CL in the first place), but I am obsessed with maps. Thanks for the info on humans in general. :o)

I've added my own comment on https://camlistore-review.googlesource.com/6456, PTAL.