Hi,

I agree that such a provider would probably slow - too slow for a server, unless the data is cached somewhere (e.g. sqlite) and ogr only reads new/updated files, and the rest from the cache.

On the other hand it would still be useful for conversion into other formats, where speed perhaps doesn't matter that much.

Andreas

On Mon, 23 Jul 2012 11:26:31 -0400, Daniel Morissette wrote:
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 <even.roua...@mines-paris.org
<mailto:even.roua...@mines-paris.org>>

    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
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Reply via email to