Would it be possible to combine this with VRT XML such that when the
images were read to build the VRT file that it also added the EXIF tags
there. This would collect all the info into the VRT file and avoid
re-reading all the individual images. Sorry this might be a dumb
question as I'm not sure to what extent attributes can be imported from
the source files into the VRT file, but maybe this is a valid use case
for such an extension.
-Steve W
On 7/23/2012 5:13 PM, Tamas Szekeres wrote:
Hi Daniel,
Thanks for your comments. Your concerns are valid about the
performance. But writing a script to convert images to shapefiles would
likely provide similar performance. With regards to the usability,
having a driver (and the use of ogr2ogr) would be more convenient even
if that's used mostly as an offline solution. I'm not too satisfied with
the practice of outsourcing significant tasks to external (language
specific) scrips as "official" tools. This requires the user to be
prepared to install further things (like runtime environments,
additional libraries etc) in order to have the things up and
running. The concept of having a new driver would provide further
possibilities related to the common object model (like having OGR SQL to
work)
Best regards,
Tamas
2012/7/23 Daniel Morissette <[email protected]
<mailto:[email protected]>>
If I understand correctly, in the Open() call, this driver would
open each image file to read its EXIF info and index the files in
memory? This would work fine with a dozen images, but as the number
of images increases the performance will suffer a lot and this would
become unusable in apps such as MapServer, and even for Desktop apps
with hundreds of images.
If I needed this kind of functionality myself I would use a script
to create an OGR point file as suggested by Even, to avoid the
overhead caused by opening all the images.
My 0.02$
Daniel
On 12-07-23 5:27 AM, Tamas Szekeres wrote:
Hi Even,
I just want to use the directory name to define the connection
to the
images, we could also provide to scan the files in subdirectories if
needed. I would prefer to have a new driver not just an offline
tool for
creating OGR datasets, in this case many existing applications (like
MapServer) would be capable to utilize this feature.
I could imagine a driver configuration file to specify which driver
should be used for a particular image format and where the specific
information is located, I don't require to harmonize the metadata
structure at this time. We should probably allow mixing jpegs
and tiffs
in the same directory, but the configuration should specify how the
similar attributes are provided by each (sub)driver.
Best regards,
Tamas
2012/7/23 Even Rouault <[email protected]
<mailto:[email protected]>
<mailto:even.rouault@mines-__paris.org
<mailto:[email protected]>>>
Le lundi 23 juillet 2012 09:51:14, Tamas Szekeres a écrit :
> Hi All,
>
> We're thinking about implementing a new OGR driver which
would
represent a
> set of images as a vector data source. The images are
taken from
any GPS
> compatible mobile device, and each picture would be
represented
as a point
> feature, the positions would be extracted from the exif
information. The
> file name and path would be provided as an attribute for
each
feature. This
> data source could then be used by higher level apps to
provide
symbols at
> the picture locations in the map and display the picture
when the
feature
> is selected. The driver would definitely use GDAL to extract
information
> about the provided images.
>
> I'm not sure whether we already have some kind of
alternative
solution to
> this, let me know if you know about any. Further ideas
about this
topic
> would also be helpful.
The JPEG driver already exposes EXIF information if found :
$ gdalinfo ../autotest/gdrivers/data/__albania.jpg
Driver: JPEG/JPEG JFIF
Files: ../autotest/gdrivers/data/__albania.jpg
Size is 361, 260
Coordinate System is `'
Metadata:
[...]
EXIF_GPSLatitude=(41) (1) (22.91)
EXIF_GPSLatitudeRef=N
EXIF_GPSLongitude=(19) (55) (42.35)
EXIF_GPSLongitudeRef=E
[...]
$ gdalinfo ../autotest/gcore/data/exif___and_gps.tif -mdd EXIF
Driver: GTiff/GeoTIFF
Files: ../autotest/gcore/data/exif___and_gps.tif
Size is 1, 1
Coordinate System is `'
[..]
Metadata (EXIF):
[...]
EXIF_GPSLatitude=(77) (5) (60)
EXIF_GPSLatitudeRef=S
EXIF_GPSLongitude=(34) (12) (0)
EXIF_GPSLongitudeRef=E
[..]
Are you thinking to other raster formats to extract EXIF
info from?
To my
knowledge, the JPEG driver, and recently the GTiff driver,
are the
only one
that extract EXIF for now. I see that the JPEG driver
exposes it in the
default metadata domain, whereas I chose EXIF for the GTiff
driver.
For GTiff,
the specific EXIF metadata domain seemed better to me to avoid
'polluting' the
default metadata domain, but I didn't want to change the
JPEG driver
at that
point. But this would probably requires some harmonization.
So with some scripting, you could create for example a point
shapefile, with
the filename as attribute and GPS position as geometry.
In its syntax, this could be something similar to gdaltindex.
Doing that as a OGR driver would be also doable of course.
The only
point to
solve is the definition of the connexion string to specify
the image
set.
>
> Best regards,
>
> Tamas
_________________________________________________
gdal-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/__mailman/listinfo/gdal-dev
<http://lists.osgeo.org/mailman/listinfo/gdal-dev>
--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000
_________________________________________________
gdal-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.osgeo.org/__mailman/listinfo/gdal-dev
<http://lists.osgeo.org/mailman/listinfo/gdal-dev>
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
