.1560.n6.nabble.com/gdal-dev-New-OGR-driver-Imageset-tp4989980p4990271.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
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
On Mon, Jul 23, 2012 at 1:48 AM, Even Rouault
even.roua...@mines-paris.org wrote:
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
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
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
Hi Tamas,
That would be interesting. So the user could specify a folder with
images and GDAL would create an OGR layer that would expose the photo
location? The OGR feature would have certain EXIF data exposed as
attributes?
If you work on this, could you also expose other EXIF data, such
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
Hi Andreas,
Yes I wanted to expose further information, too. It could probably be user
configurable. The driver would be read only, the EXIF would be extracted by
using the corresponding GDAL drivers.
The site you refer to is very interesting,. This is something that we'd
like to achieve. It is
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
Le lundi 23 juillet 2012 11:27:01, Tamas Szekeres a écrit :
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.
Do you imagine something like :
ogrinfo my_directory_with_images
or
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
: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org]De la part de Daniel Morissette
Envoyé : lundi 23 juillet 2012 17:27
À : gdal-dev@lists.osgeo.org
Objet : Re: [gdal-dev] New OGR driver: Imageset
If I understand correctly, in the Open() call, this driver would open
each
At one point I used GDAL's ability to access EXIF data along with sed
and bash to make a shapefile photo index, like ogrtindex but for
photos and points rather than geo-rasters and polygons. It worked ok
but had precision issues and I stopped working on it when I found
GPSPrune,
17:27
À : gdal-dev@lists.osgeo.org
Objet : Re: [gdal-dev] New OGR driver: Imageset
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
Daniel,
Thanks for the input, I'm still thinking whether an offline or an online
solution would be more sufficient. OGR driver would somewhat be simple even
if it's used to convert the data source to shapefile directly (ogr2ogr).
Scripting requires the user to set up further environments (Python,
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
16 matches
Mail list logo
