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 su
> Even,
>
> I'm not convinced that a distinct EXIF domain is the best way to go.
> Non-default metadata domains are often not carried with images
> during translation or other processing and are (imho) more appropriate
> for data that would no longer apply to transformed imagery or that is
> bulky
On Mon, Jul 23, 2012 at 1:48 AM, Even Rouault
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 from? To my
> knowled
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
/osgeo-org.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 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 mo
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,
ssette
> 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 image file to read its EXIF info and index the files in memory?
&
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, http://activitywor
--
De : 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
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 suc
Hi Tamas,
Sounds like a great idea. I don't know if it's of use but I recently put
together a python script to create KMZ files of geotagged photos using
the Python Imaging Library to read EXIF data. It also exports a list of
photos and coordinates as a CSV file, for loading into a GIS. You co
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
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
MapServe
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 al
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 poi
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 as
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
18 matches
Mail list logo
