PDA

View Full Version : Geocoding (GPS) support in EE


DavidW
7th of October 2006 (Sat), 08:30
Tommy's post here (http://photography-on-the.net/forum/showthread.php?p=2088046) about the possibility of a framer in EE inspired me to mention an idea I have for EE.


My current project with my own photos

A long term aim of mine is to geocode my outdoor photos. I've got the necessary GPS recording working with my iPAQ, Bluetooth GPS and GpsGate (http://franson.com/gpsgate/) - I'm recording RMC (for time, date, latitude and longitude) and GGA (so that I also get altitude) to a file every ten seconds. That 'logger' works fine for several hours on battery power for both the iPAQ and the GPS with my Pocket PC's backlight turned off. Using GpsGate doesn't interfere with use of my GPS in other applications, as they can connect to a GpsGate virtual COM port. I keep the file recorder in a separate instance of GpsGate so that I can turn it on and off independently of the rest of the application.

Indeed, I can also send my position back to my home computer using UDP to GpsGate on my Windows machine (for economy on my GPRS bill I use the same 10 second repeat of RMC and GGA), though if all you want is a way of sharing your GPS on your Pocket PC and logging data to a file, you just need the Pocket PC program.

Certainly from now on I intend to record GPS data whenever I shoot outside - if I've got the data I can always make use of it at a later date.


To geocode the pictures using that recorded data, RoboGEO (http://www.robogeo.com) looks like the favourite application, especially when teamed with Google Earth. Unfortunately RoboGEO doesn't (yet) support XMP sidecar files (though it does support JPEG and DNG), though I've been in touch with the author and he's interested in adding XMP support. If you want to add a 'me too', then the email address for suggestions is at the bottom of the FAQ page (http://www.robogeo.com/home/faq.asp).


Both GpsGate and RoboGEO are commercial software, but both are inexpensive. If you already have a handheld GPS with a suitable cable, you may well be able to get the necessary data directly into RoboGEO. For various reasons, my only GPSes are Pocket PC based ones.


Where EE comes in

When I get some geocoded photos (even if I finish up doing my post-processing, then using RoboGEO to geocode the resulting JPEGs - though it would be neater to geocode the XMP sidecars so that GPS data is in the metadata of all the resulting files), I'll be looking to add GPS data to EE's metadata reading routines.

Once EE is capable of reading GPS metadata, it would be a case of agreeing which tables and fields would be used to store this in the EE database with Pekka, and add the necessary code to store the GPS metadata in the database.


Once GPS data is in the EE database, there's all manner of ways it can be used. Particularly exciting to me are the possibilities for outputting KML files to Google Earth, which can, of course, be dynamically generated using PHP. KML feeds of galleries, latest pictures and so on are all possible.


I must stress that this is a long term project that may take some time to come to fruition. I'm hoping that the initial stages of this - getting as far as having GPS data in the EE database - may be possible within the next two months. However, I can't promise if any of this will actually happen - my priorities may change as my life is, like everyone's subject to outside pressures.


Some thoughts about third party development of EE

Pekka - are you interested in working with other developers on enhancements to EE code, on the basis that all code is contributed to the main EE2 distribution under the terms of the EE2 licence, and that you remain in overall control of your project? I believe that the EE user community has the capability of offering significant enhancements to all EE users.


If any significant efforts are made by other developers, it may be worth moving EE to a revision control system such as Subversion (http://en.wikipedia.org/wiki/Subversion_(software)) to keep hold of the master EE code. That would offer various advantages, such as the ability to revert individual (mistaken) changes, and even the possibility of offering read-only access to the repository for people to retrieve interim versions of files to solve individual problems.

There are open source Subversion clients around, such as Web Client for SVN (http://polarion.org/index.php?page=overview&project=svnwebclient) and Subversion (http://subversion.tigris.org/) is itself open source. One advantage of using Subversion is that the server itself can be run under Apache 2 using WebDAV. Windows binaries for the server are available, too.


Final thoughts

For now, my priorities are to get a debuggable jailed Apache and PHP setup running on my FreeBSD box (hopefully today - we'll see), and work on a few glitches that I'm seeing in the metadata handling, with any fixes contributed back to Pekka via the forums.

None of this other stuff I've mentioned is necessarily going to happen, but I thought I'd float it here as EE excites me tremendously.


To be clear, I am not suggesting any move from the current setup, where EE is Pekka's project that Pekka is in control of. I'm also not suggesting any deviation from the licence that Pekka has placed EE2 under.

I'm merely trying to suggest ways that the community could add features to EE under Pekka's oversight, and suggesting that consideration is given to handling EE files under a revision control system (for which Subversion looks particularly attractive due to it being available free of charge to run under a Windows or UNIX based Apache 2 server).



David

kheops
7th of October 2006 (Sat), 13:23
don't want to hijack your thread David but i've found this program http://www.itagsoftware.awswa.com/ to insert gps infos in exif fields in my jpg
so i really second your request :)

Pekka
7th of October 2006 (Sat), 20:29
I am always fond of logical solutions and here I have though that as EE already has a location database it would be logical to expand it to contain positional data which would then be reused by EE in photos and elsehwere (like photo location maps). Of course this data could be read from EXIF/XMP and I welcome any help with that. But it should also be possible to enter it was e.g. Google Map code - we probably need map code fields for each display technique.

David, I welcome all coding help as long as what is being done is discussed and it fits EE overall logic. I code in quite simple way as you have seen, but that is because it is also very easy to debug and I see more challenges worth my time in structure of the program, funcionality and how it works for the user. All coding by other will be credited but they must be given free to EE under its licence. And I'm more than happy to receive bug reports and fixes and advice on how to best do some things, I know I suck with regexp, hex handling (like EXIF) and I have not had time to study benefits of classes (I believe they are more bug prone and slower than functions anyway) so if someone needs help it is me :)

Elan Remford
8th of December 2006 (Fri), 02:00
What would make even more sense would be to place the GPS data where it makes the most sense in the workflow, which is to embed it in the RAW source image alongside every other shot-specific parameter.

Though RoboGeo has had the foresight to support the DNG format, for those of us not shooting with Leicas whose inherent RAW format happens to be DNG and who would rather not compromise the true RAW source of their CR2, CRW, NEF, etc. files during the conversion process to DNG, not to mention avoid the overhead of processing and storing the DNG files to boot, native-format RAW support would seem to be the true "best practice" approach, using XMP Sidecars as a means of carrying forward any additional data for which a particular file format doesn't offer an EXIF slot.

Is anyone aware of such an application which specifically supports the Canon CR2/CRW raw format(s)? Thanks in advance for any relevant assistance.

DavidW
10th of December 2006 (Sun), 12:05
Contact the RoboGEO author about XMP sidecar support, using the link at the bottom of the FAQ page (http://www.robogeo.com/home/faq.asp), as mentioned in my previous post. I haven't found a similar application that supports XMP sidecars.

Tim has indicated to me that he's willing to add XMP sidecar support (and it should be relatively straightforward as he's supporting DNG, which is a similar format for metadata; XMP is just metadata in an XML file). Unfortunately he's not using Photoshop CS2, but as per his request I've sent him some example XMP sidecars.

The more people that indicate that there's money in it for him if he adds XMP sidecar support, the sooner it is likely to happen!


The work-round might be to bind late to the GPS data. Preserve EXIF throughout your workflow, then run RoboGEO on the resulting JPEGs and TIFFs. I'm not sure whether this works properly or not; I've not tried it, because I too am interested in a 'bind early' setup. I'd far rather run RoboGEO on the sidecars once I've done my initial metadata tweaking in Bridge.


I haven't forgotten about the suggestion to add geocoding support to EE that I made here; I do intend to take it forwards, but life has taken my energy in other directions in recent weeks. Maybe once we get into January, I'll have some more time to work on this.



David