Photo Organizer

  • Status Unconfirmed
  • Percent Complete
  • Task Type Feature Request
  • Category Backend / Core
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 2.36
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Photo Organizer
Opened by gio - 2008-10-02

FS#390 - gps data in a spatial enabled database?

I think it would be a cool feature to make PO spatial enabled. I mean that it would be possible to use gps data (geolocated images) to search for "photo taken near some point" or "all the photo taken near some street". Or simply to create an interface a la panoramio for look/find for pictures. It should be not to difficult to implement.

pizza commented on 2008-10-02 15:05

A while back I was handed a massive patch (well, modified PO sources) that did what you're describing. [un]fortunately it was built on top of PostGIS (, which on one hand made geospatial operations trivially easy to implement, but on the other hand it required PostGIS, which while quite powerful is a bit of a beast to set up -- and there was no way to make that support optional as supplied.

Later this month I plan on picking up a GPS unit for my camera, so once I have raw spatial data to play with I'm sure I'll be motivated to put together something that takes advantage of it.

Use of a full GIS backend makes a lot of things possible -- we can do area-based calculations instead of just points and approximate distances between them.

That said, simply adding "search for photos taken near point X" wouldn't be too hard with the existing GPS data as it doesn't depend on any external data sources, but translating GPS coordinates to street names (etc) is another matter entirely.

So... Precisely defining what you mean by "spatially enabled" is crucial here; PO already stores lat/long data and links that to google maps, but nothing fancier yet.

gio commented on 2008-10-02 15:46

Yes, i was thinking of PostGIS for spatial extensions. For what i know it's not too hard to set up (not too much harder than set up a postgresql server...). Once you have it, it should be possible to fetch data from various resources (es., and display/search point on a map. Maybe even a user supplied map (i.e. with qgis you can create a shapefile and load on postgres, than look for picture taken along a river). If I record correctly, you can query google map for translation street address->lat,lng
All this it's not easy to implement, but maybe an interesting direction to move on. In fact no photo management software can do search based on geographic informations.

pizza commented on 2008-10-02 16:46

It is quite an interesting direction to move in, but ... is it the right direction?

What's the use case for "photo management" with that level of GIS integration? Everything I can come up with is GIS first, with photos as a distant secondary attribute/feature. (That said, I know PO is used by at least one municipality to store photos relating to their tax rolls, but crucially I have no idea about the rest of their systems or workflow.)

It may make more sense to integrate PO into a pre-existing geospatial app/framework (eg MapServer) than to try and build these features out piecemeal. (ie deal with external authentication/session frameworks, provide a sane external API..)

Still, the next logical steps from where things are at now:

* Search for photos taken within X distance from point Y.
* Generate a map (via google/whatever) with locations for a given set of photos marked.
* Investigate the feasibility of optional PostGIS support. (basically reimplement current geospatial features "properly")

gio commented on 2008-10-03 12:40

I agree with you that it would be a better approach to provide an integration to pre-existing geospatial apps to PO. In fact, as you can see in this example page, you can build an interactive map querying multiple sources. One of these could be PO. All this just to say that the steps you indicate are in a right direction (from my point of view), but probably integrating postGIS from the beginning it would be better. Enable the spatial feature in a database require 3 commands, and doing all the math without it i think it will be a pain... Not just for computing the distance between two points, but - for example - to show only the photos taken inside a region (if you generate - from google or whatever - a map, you have a max/min lat-long to search photos taken inside this box).
Oh, and if you are considering buying a gps device, i suggest this one:

thanks for your works!

pizza commented on 2008-10-03 13:14

Yesterday I ordered a Geomet'r GNC-35: -- it directly attaches to (and is powered by) my camera. Nikon's coming out with a slick new unit sometime in November, but I needed something before that. (I probably could have built one, but it would have likely cost me about the same in the end..)

Anyway -- Once I'm done with my current changes (caching static-ish DB queries and general DB cleanups) I'll set up a PostGIS-enabled server and play around with it. I'm not comfortable with adding a blanket requirement for PostGIS, but adding optional support would be a testing/maintenance nightmare...

(At least Fedora includes PostGIS packages now!)

Thanks for the various links, by the way.

pizza commented on 2008-10-05 03:23

PostGIS will greatly complicate the process of generating clean schema dumps for PO. I think it is the right thing to do if I want to get serious. Too bad there's no easy way to poll the userbase...

gio commented on 2008-10-05 18:04

I'm not a postgresql expert, neither i know how PO is structured, but maybe an easy way could be to use just 1 table with geometry feature. Just the essential to provide photo_id->lat/lng. In this way you'll duplicate lat/lng information (you'll have it in exif data and as POINT() in this table), but maybe it will be possible to use this table only if postGIS is installed. If postGIS it's not installed you can easily drop the table. If somewhere in time postGIS get installed, you only have to fetch exif data to create the geometry table. Maybe you don't have to include such a table in a dump, but just generatin it at the first start.
I was thinking of it reading this paper:
maybe you'll find it useful.



Available keyboard shortcuts


Task Details

Task Editing