[gdal-dev] New OGR driver: Imageset
Stephen Woodbridge
woodbri at swoodbridge.com
Tue Jul 24 10:03:39 PDT 2012
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 <dmorissette at mapgears.com
> <mailto:dmorissette at mapgears.com>>
>
> 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.rouault at mines-paris.org
> <mailto:even.rouault at mines-paris.org>
> <mailto:even.rouault at mines-__paris.org
> <mailto:even.rouault at 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 at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> 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
> gdal-dev at lists.osgeo.org <mailto:gdal-dev at lists.osgeo.org>
> http://lists.osgeo.org/__mailman/listinfo/gdal-dev
> <http://lists.osgeo.org/mailman/listinfo/gdal-dev>
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
More information about the gdal-dev
mailing list