Re: [Qgis-developer] ​Geophoto management

[Albin Blaschka]

Hello!

I see the storing of pictures inside the database as problematic - due 
to the pure file size to be expected, especially if it also possible to 
store RAW-files: Just an example from my own work (ecological study):
In a project I have 16 plots studying the development of vegetation, 
working there for three years, just if I make 5 photos per year (which 
is almost nothing), we end up with 16 * 3 * 5 = 240 pics. I own an 
Olympus E1, so a relatively old camera with "just" 5 Megapixel, the 
RAW-file has 10.2 MB, so that would be around 2.5 GB of Data overall in 
this theoretical case. Small project, old camera, meaning relatively 
small resolution...
Even if we take just the jpg (for me and my camera, most of the time 
something between 0.5 - 1.2 MB) still around 200 MB... so specially for 
mobile devices or portability between devices not ideal I'd say... Maybe 
storing just a thumbnail and defining a root-directory were the pictures 
are would be an option?


I hope, not being a developer, my thoughts are not taken as an offense! 
The features discussed are great and I would be very pleased if they are 
implemented, but storing big binary data in a database could be 
problematic, as I said...


Thank you all for your efforts!
Greetings,
Albin


Am 04.07.2016 01:34 PM, schrieb Matthias Kuhn:

Hi Mark

On 07/04/2016 12:35 PM, Mark Johnson wrote:

​Work is being done in this area, intended to be an extension of the
RasterLite2 library (of the spatialite project), which will hopefully
come out this year.

The Raster-support in RasterLite2 supports Georeferenced images called
Raster-Coverage's.

The idea would be to add support for Geotaged images in the form of an
'Album'
- one Album containing images
- each Album could belong to another Album


Will it easily be possible to extract such a photo from the spatialite 
file?


Thinking about QField (mobile application), I like the in-database
approach for its portability but fear that the photos will be locked in
there and that it will be quite hard to use them for a report written 
in

an application that does not support RasterLite2.

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer


--
| Dr.rer.nat. Albin Blaschka
| Etrichstrasse 26, A-5020 Salzburg
| * www.standortsanalyse.net *
| * www.researchgate.net/profile/Albin_Blaschka *
| - It's hard to live in the mountains, hard but not hopeless!
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Mark Johnson]

>
> Will it easily be possible to extract such a photo from the spatialite file?
>
> No, once created, the database itself could retrieve all the data without
spatialite
- the exception being that the geometry could not be read
The position(s) are stored in extra fields
The image itself is a simple blob
- when written to a file (or read in as a QImage)
-- (in the case of jpg) a jpg with exif-Information will be read

While developing the concept, the idea was to create a general Album-logic
- that a non-spatialite drive could still read/write
-- but without out the geometry support

>
> Thinking about QField (mobile application), I like the in-database
> approach for its portability but fear that the photos will be locked in
> there and that it will be quite hard to use them for a report written in
> an application that does not support RasterLite2.
>
> Matthias
>
> With the exception of the last field 'album_geom', everything else can be
read by a simple sqlite3 driver:

Here the CREATE statement for a table containing the images of one Album:

CREATE TABLE "Alt_Berlin_album_data"
(
 id_album INTEGER PRIMARY KEY AUTOINCREMENT,
 title TEXT NOT NULL DEFAULT '*** missing Title ***',
 abstract TEXT NOT NULL DEFAULT '*** missing Abstract ***',
 date_original DATETIME DEFAULT (datetime('now','localtime')),
 mime_type TEXT NOT NULL,
 tag_info TEXT NOT NULL DEFAULT 'historic:place',
 copyright TEXT NOT NULL DEFAULT '',
 image_path TEXT NOT NULL UNIQUE,
 width INTEGER NOT NULL DEFAULT 0,
 height INTEGER NOT NULL DEFAULT 0,
 sample_type TEXT NOT NULL DEFAULT '*** undefined ***',
 pixel_type TEXT NOT NULL DEFAULT '*** undefined ***',
 num_bands INTEGER NOT NULL DEFAULT 1,
 compression TEXT NOT NULL DEFAULT 'NONE',
 nodata_pixel DOUBLE NOT NULL DEFAULT 0.0,
 extent_min_x DOUBLE DEFAULT 0.0,
 extent_min_y DOUBLE DEFAULT 0.0,
 altitude DOUBLE DEFAULT 0.0,
 extent_max_x DOUBLE DEFAULT 0.0,
 extent_max_y DOUBLE DEFAULT 0.0,
 distance DOUBLE  DEFAULT 0.0,
 bearing DOUBLE  DEFAULT 0.0,
 image BLOB,
 image_thumbnail BLOB,
 exif_json TEXT NOT NULL DEFAULT ''
 , "album_geom" MULTIPOINT)

If an sqlite3 driver inserted a record, leaving the geometry field(s) NULL
- the spatialite logic would simply create the geometries either from
-- the extent_min* for GPS
-- the extent_max* for GPS_DEST
or by reading the image when it contains Exif-Gps Information

The goal was to make it useable for all
- with an extra for GIS aware software

--

Here the CREATE statement for the administration table
- the extents are calculated during an INSERT/UPDATE with spatialite, but
the result is readable by any sqlite3 driver
-- again the geometries would only useful for spatialite aware software

CREATE TABLE "album_coverages"
(
 id_album INTEGER PRIMARY KEY AUTOINCREMENT,
 id_parent INTEGER DEFAULT 0 ,
 album_name TEXT NOT NULL,
 title TEXT NOT NULL DEFAULT '',
 abstract TEXT NOT NULL DEFAULT '',
 images_count INTEGER DEFAULT 0 ,
 extent_min_x DOUBLE DEFAULT 0.0,
 extent_min_y DOUBLE DEFAULT 0.0,
 extent_max_x DOUBLE DEFAULT 0.0,
 extent_max_y DOUBLE DEFAULT 0.0
, "album_geom" POLYGON, "album_points" MULTIPOINT, "album_linestrings"
MULTILINESTRING, "album_geomcollection" GEOMETRYCOLLECTION)

Mark
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] ​Geophoto management

[Matthias Kuhn]

Hi Mark

On 07/04/2016 12:35 PM, Mark Johnson wrote:
> ​Work is being done in this area, intended to be an extension of the
> RasterLite2 library (of the spatialite project), which will hopefully
> come out this year.
> 
> The Raster-support in RasterLite2 supports Georeferenced images called
> Raster-Coverage's.
> 
> The idea would be to add support for Geotaged images in the form of an
> 'Album'
> - one Album containing images
> - each Album could belong to another Album

Will it easily be possible to extract such a photo from the spatialite file?

Thinking about QField (mobile application), I like the in-database
approach for its portability but fear that the photos will be locked in
there and that it will be quite hard to use them for a report written in
an application that does not support RasterLite2.

Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Mark Johnson]

>
> Thank you very much. Will this be Spatialite only, or you think of
> extending it to Geopackage too?

The intention is building this in to the RasterLite2 Library parallel to
(and not interfering with) the present Raster/Vector-Coverage logic and
utilizing the functionality that exist there already
- for the creation of a Geotagged Hierarchical Photo-Album

This would probably not fit into the Geopackage specification, which is
similar in the area of Vectors, but for Rasters is Tile based.

Since RasterLite2 is a Spatialite based system, adapting everything to work
also to the Geopackage specification had not occurred to me.

Mark Johnson
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] ​Geophoto management

[Paolo Cavallini]

Il 04/07/2016 12:35, Mark Johnson ha scritto:
> ​Work is being done in this area, intended to be an extension of the
> RasterLite2 library (of the spatialite project), which will hopefully
> come out this year.

Thank you very much. Will this be Spatialite only, or you think of
extending it to Geopackage too?
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] ​Geophoto management

[Mark Johnson]

​Work is being done in this area, intended to be an extension of the
RasterLite2 library (of the spatialite project), which will hopefully come
out this year.

The Raster-support in RasterLite2 supports Georeferenced images called
Raster-Coverage's.

The idea would be to add support for Geotaged images in the form of an
'Album'
- one Album containing images
- each Album could belong to another Album

For each Image, the Exif-Information would be extracted and stored in the
row together with the original image.
- spatialite already has reading capabilities for Exif-Information (but at
the moment no writing)
The GPS-Information is then stored in a MULTIPOINT Geometry
- 2 points if GPSDest* Information was found

Since the Exif-Information is stored in the row
- the idea would be that it could be changed and the image updated (and
exported)

Based in the existing RasterLite2 logic, where there is an extra TABLE
containing a summery of Information about for each Raster-Coverage
- there would be a corresponding 'Album-Coverage' would exist with one
entry per Album (as a summery), containing
-- the area the photos inside the Album contains --> to zoom to the area
-- a MULTILINE GEOMETRY which shows all the LINESTRING that exist in the
Album
-- a MULTIPOINT GEOMETRY which shows all the images that do not have
GPSDest* Information
-- an GEOMETRYCOLLECTION, containing both) also exists, but in my version
of QGIS at least,  GEOMETRYCOLLECTION cannot be displayed
- Bearing and distance being calculated when possible.

This had be developed about 2 years ago for a historical Database project
- about 600 images were at that time collected
- short (title) long (image description) where collected an added with the
exiftool
-- setting fields used by linux, mac and windows file explorers (each
system using different fields)
- the estimated position where the photo was shot from being set as the
GPSLat/Long value
- the main point of interest set as the GPSDest* value

The RasterLite2 tool 'rl2sniff' was initially used as a base
- which runs through a directory, searching for Georeferenced images

This tool was adapted (called 'rl2sniff_album') to also look for geotagged
images
- and add it to the Database
-- after a refresh in QGIS, the POINTS or LINESTRINGs show up so that
correction can be made when needed

So much of what of what is being requested, is being considered and at the
moment I am working
on moving the present logic from the rl2-tool into RasterLite2-Library so
that it can be SQL-Driven
- retrieve, Import, Export, update

My intention was to suggest this to Sandro after the first release of
RasterLite2
- but since this has been delayed, I am working on this now and will summit
the concept when completed
  (So Sandro has no idea about this concept of adding the 'poor cousin'
geotaged images to RasterLite2)

As for the importing of external 'RAW' files
- at the moment the idea was to support the exiftool-json format
-- so that when a non-geotaged image was found, but a exiftool-json
existed, that would be used
(just as is done with a tif with a world file)
So adding a reading support for these RAW-files using the same logic would
be practicable

The present documentation is based on the code of 2 years ago, but will be
updated when the integration has been completed.

Mark Johnson, Berlin Germany
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Paolo Cavallini]

Il 04/07/2016 11:52, Matthias Kuhn ha scritto:
> FYI,
> 
> we are currently investigating the possibilities to link photos to
> geometries in QField.
> 
> The idea is to use the ExternalResource widget with image flag as
> indicator that photos are a suitable input for this field.
> Then save them in a subfolder of the QGIS project + the relative path to
> the file in the attribute.
> 
> It's only partially related, but it may be interesting nontheless.

Interesting, yes.
Thanks.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Matthias Kuhn]

FYI,

we are currently investigating the possibilities to link photos to
geometries in QField.

The idea is to use the ExternalResource widget with image flag as
indicator that photos are a suitable input for this field.
Then save them in a subfolder of the QGIS project + the relative path to
the file in the attribute.

It's only partially related, but it may be interesting nontheless.

Matthias


On 07/04/2016 11:09 AM, Paolo Cavallini wrote:
> Il 04/07/2016 10:31, Neumann, Andreas ha scritto:
>> Yes - I can start with a specification document. But not this week -
>> later this month.
> 
> Thanks - I'm available for help, just let me know if I can be useful.
> All the best.
> 
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Paolo Cavallini]

Il 04/07/2016 10:31, Neumann, Andreas ha scritto:
> Yes - I can start with a specification document. But not this week -
> later this month.

Thanks - I'm available for help, just let me know if I can be useful.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Neumann, Andreas]

Yes - I can start with a specification document. But not this week -
later this month. 

Andreas 

On 2016-07-04 08:54, Paolo Cavallini wrote:

> Il 04/07/2016 08:49, Neumann, Andreas ha scritto: 
> 
>> Hi,
>> 
>> I also think that there is enough interest by many people/organizations
>> to have support for it in QGIS core.
>> 
>> I would have the following (mostly additional) requirements:
> 
> Thanks a lot Andreas.
> 
>> Paolo: do you have funding for such improvements? I may be able to
>> contribute privately in autumn in a crowd-funding effort (esp. for items
>> 2-6 above)
> 
> Let's talk about funding on the next PSC. Crowdfunding is certainly a
> good option.
> 
>> Perhaps we should first write a complete specification of what we expect
>> from such a tool.
> 
> Agreed. Since you have lots of material, would you mind starting it?
> IMHO better divide the tasks in basic and nice to have, so we can do it
> in steps.
> All the best.

  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Paolo Cavallini]

Il 04/07/2016 08:49, Neumann, Andreas ha scritto:
> Hi,
> 
> I also think that there is enough interest by many people/organizations
> to have support for it in QGIS core.
> 
> I would have the following (mostly additional) requirements:

Thanks a lot Andreas.

> Paolo: do you have funding for such improvements? I may be able to
> contribute privately in autumn in a crowd-funding effort (esp. for items
> 2-6 above)

Let's talk about funding on the next PSC. Crowdfunding is certainly a
good option.

> Perhaps we should first write a complete specification of what we expect
> from such a tool.

Agreed. Since you have lots of material, would you mind starting it?
IMHO better divide the tasks in basic and nice to have, so we can do it
in steps.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Neumann, Andreas]

Hi, 

I also think that there is enough interest by many people/organizations
to have support for it in QGIS core. 

I would have the following (mostly additional) requirements: 

1. being able to read a whole folder with photos
2. Support for additional graphic file formats next to JPEG.
Professional photographers don't store their data in JPEG documents, but
in their RAW files(e.g. NEF (Nikon Raw format), CRW (Canon Raw format))
3. Support for GPSDestXX Tags to diplay the target point. The target
point is in my opinion more important than the point where the photo was
taken
4. Support for GPSDestBearing/GPSDestDistance to show the direction from
the photo standpoint to the target point
5. When clicking on a photo it would be nice if the view angle could be
visualized, taking into account the fov (field of view) of the lense,
GPSDestCoordinates or GPSDestBearing/Distance, based on whatever is
available in the EXIF data
6. Being able to interactively edit EXIF data in QGIS, esp.
GPSDestLongitude/GPSDestLatitude, GPSDestBearing/GPSDestDistance. 

See http://www.exif.org/Exif2-2.PDF and
http://www.geofoto.ch/geophotomap/ (when you click with the "i" Button
on a photo point, the view angle is displayed (see item 5 above)) 

Paolo: do you have funding for such improvements? I may be able to
contribute privately in autumn in a crowd-funding effort (esp. for items
2-6 above) 

Perhaps we should first write a complete specification of what we expect
from such a tool. 

Andreas 

On 2016-07-04 08:09, Paolo Cavallini wrote:

> Oh, right, good suggestion, thanks Nathan. Moreover, it can also create
> thumbnails:
> http://www.gdal.org/frmt_jpeg.html
> So the work from QGIS side seems considerably reduced.
> In the far past, reading EXIF was a bit a black magic, beacuse vendors
> implemented it with lots of variations, thus many exif readers failed
> often: does anybody have recent experience, is GDAL driver working in
> most or all cases?
> Thanks again.
> 
> Il 04/07/2016 07:58, Nathan Woodrow ha scritto: 
> 
>> GDAL also seems to support reading EXIF information if we want to use
>> that to avoid any extra libraries.
>> 
>> On Mon, Jul 4, 2016 at 3:51 PM, Paolo Cavallini > > wrote:
>> 
>> Hi all,
>> a frequent request from user is a better management of geotagged photos.
>> What most users expect is to:
>> 1. be able to load geotagged photos
>> 2. display the locations
>> 3. display the photo clicking on the location
>> * possibly also to show a miniature.
>> Currently we have:
>> * an old and relatively complex C++ plugin, much more powerful than
>> this, and thus overkill for such a simple task
>> * the external plugin photo2shape, that only do #1 and #2, has issues
>> with py libraries, and leaves photos in an external path
>> * a plugin that helps georeferencing photos.
>> My suggestion would be to modify photo2shape to save on a
>> spatialite/geopackage db:
>> * the photos
>> * their locations
>> * the line joining consecutive points
>> * the photos themselves
>> * a form that will display the photo on click.
>> Such a plugin would be IMHO a good candidate for inclusion in core.
>> Is anyone working on something similar? Better ideas?
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu [1] 
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org 
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

  

Links:
--
[1] http://www.faunalia.eu
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Paolo Cavallini]

Oh, right, good suggestion, thanks Nathan. Moreover, it can also create
thumbnails:
http://www.gdal.org/frmt_jpeg.html
So the work from QGIS side seems considerably reduced.
In the far past, reading EXIF was a bit a black magic, beacuse vendors
implemented it with lots of variations, thus many exif readers failed
often: does anybody have recent experience, is GDAL driver working in
most or all cases?
Thanks again.

Il 04/07/2016 07:58, Nathan Woodrow ha scritto:
> GDAL also seems to support reading EXIF information if we want to use
> that to avoid any extra libraries.
> 
> On Mon, Jul 4, 2016 at 3:51 PM, Paolo Cavallini  > wrote:
> 
> Hi all,
> a frequent request from user is a better management of geotagged photos.
> What most users expect is to:
> 1. be able to load geotagged photos
> 2. display the locations
> 3. display the photo clicking on the location
> * possibly also to show a miniature.
> Currently we have:
> * an old and relatively complex C++ plugin, much more powerful than
> this, and thus overkill for such a simple task
> * the external plugin photo2shape, that only do #1 and #2, has issues
> with py libraries, and leaves photos in an external path
> * a plugin that helps georeferencing photos.
> My suggestion would be to modify photo2shape to save on a
> spatialite/geopackage db:
> * the photos
> * their locations
> * the line joining consecutive points
> * the photos themselves
> * a form that will display the photo on click.
> Such a plugin would be IMHO a good candidate for inclusion in core.
> Is anyone working on something similar? Better ideas?
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu 
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org 
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 


-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Geophoto management

[Nathan Woodrow]

GDAL also seems to support reading EXIF information if we want to use that
to avoid any extra libraries.

On Mon, Jul 4, 2016 at 3:51 PM, Paolo Cavallini 
wrote:

> Hi all,
> a frequent request from user is a better management of geotagged photos.
> What most users expect is to:
> 1. be able to load geotagged photos
> 2. display the locations
> 3. display the photo clicking on the location
> * possibly also to show a miniature.
> Currently we have:
> * an old and relatively complex C++ plugin, much more powerful than
> this, and thus overkill for such a simple task
> * the external plugin photo2shape, that only do #1 and #2, has issues
> with py libraries, and leaves photos in an external path
> * a plugin that helps georeferencing photos.
> My suggestion would be to modify photo2shape to save on a
> spatialite/geopackage db:
> * the photos
> * their locations
> * the line joining consecutive points
> * the photos themselves
> * a form that will display the photo on click.
> Such a plugin would be IMHO a good candidate for inclusion in core.
> Is anyone working on something similar? Better ideas?
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Geophoto management

[Paolo Cavallini]

Hi all,
a frequent request from user is a better management of geotagged photos.
What most users expect is to:
1. be able to load geotagged photos
2. display the locations
3. display the photo clicking on the location
* possibly also to show a miniature.
Currently we have:
* an old and relatively complex C++ plugin, much more powerful than
this, and thus overkill for such a simple task
* the external plugin photo2shape, that only do #1 and #2, has issues
with py libraries, and leaves photos in an external path
* a plugin that helps georeferencing photos.
My suggestion would be to modify photo2shape to save on a
spatialite/geopackage db:
* the photos
* their locations
* the line joining consecutive points
* the photos themselves
* a form that will display the photo on click.
Such a plugin would be IMHO a good candidate for inclusion in core.
Is anyone working on something similar? Better ideas?
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer