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! > > -- 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.
