Re: [gdal-dev] encoding problem when reading DXF file

[Dmitry Baryshnikov]

24.07.2012 5:37, dequan chen ?:

hi all,
I download the latest gdal-19-1600-core.msi from
http://www.gisinternals.com/sdk and installed, then copy gdal_csharp.dll,
ogr_csharp.dll, osr_csharp.dll etc to read .DXF file. But it has the 
problem

of charactor encoding. My DXF file contains chinese charactor that code is
GB2312. If i use DLLs from FWTOOLS, the charactor encoding correctly, 
but i

cannot to run my compiled EXE (both debug and release versions). The
application just crashes.
What more work should i do ? thanks advanced.


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Hi Dequan,

It seems to me that is the similar issue 
http://trac.osgeo.org/gdal/ticket/4650

Check TestCapability method of DXF driver

Best regards,
Dmitry

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset

[Rutger]

Hey,

I really like the idea. But the first thing that came to my mind was graphs
(images) instead of photographs. So i would love to see it being general
enough so that your not limited to a photo with EXIF data.

See for example something like this:
http://www.cpc.ncep.noaa.gov/products/global_monitoring/temperature/weur_90temp.shtml
http://www.cpc.ncep.noaa.gov/products/global_monitoring/temperature/weur_90temp.shtml
 

You could of course write your own 'fake' EXIF to any image file, that would
be a workaround.


Regards,
Rutger






--
View this message in context: 
http://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

Re: [gdal-dev] how to create NETCDF with several 3D variables?

[Anton Korosov]

Etienne, Chris, thank you very much for your response!

I'll take a closer look at this software, though I wish to be dependent 
on fewer packages.


Anton


On 07/23/2012 08:09 PM, Etienne Tourigny wrote:

Chris is right - the netcdf driver in gdal was designed to read netcdf
data and create netcdf files from other formats, not write complex
files.

Anything else is a hack - better to use other tools if you want to
combine bands, variables, etc.

Etienne

On Mon, Jul 23, 2012 at 2:07 PM, Chris Barker  wrote:

On Mon, Jul 23, 2012 at 7:50 AM, Anton Korosov  wrote:


how to create a NetCDF file with several variables that have more than two
dimensions?


I"m sure you can get this to work, but...

netcdf has a pretty different data model than GDAL -- I suspect you'll
be fighting that regularly. You may be better off workign with a more
native netcdf driver. If you are at all familiar with Python, the
"netCDF4" python module is great:

http://netcdf4-python.googlecode.com/svn/trunk/docs/netCDF4-module.html

( you can read stuff in other formats with GDAL, and write with
netcdf4, if that makes sense )

you may want to give it a try.

-Chris



I have to save time series of several fields (sst, chlorophyll, etc) in one
file.

I found that in order to create one 3D variable I can add
NETCDF_DIM_EXTRA, NETCDF_DIM_time_DEF, NETCDF_DIM_time_VALUES to the
metadata in a VRT file. Then I use 'gdal_translate -of NetCDF' or
gdal.GetDriverByName('NetCDF').CreateCopy() to generate a .nc file.

However I cannot make several 3D variables!

Here are two VRTs. One works fine (one variable: 'sst', 3 dimentions: time,
x, y). Another one produces two variables (chl, sst)  but time dimension is
not added!
Is it possible to do it in theory?

I use the latest release of GDAL 2.0dev

With best regards and great thanks for the developers of the fantastic
NetCDF driver!

Anton

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev




--

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to identify a point is belong to a polygon ?

[Chaitanya kumar CH]

Tai,

The environment variables can be set at the command prompt temporarily
using

SET LD_LIBRARY_PATH=C:\path\to\gdal\libraries
SET GDAL_DATA=C:\path\to\gdal\libraries\data

You can set them in the project settings in VC++. I don't know how.
You can also set them system wide at MyComputer->Settings.

On Tue, Jul 24, 2012 at 9:50 AM, taibc  wrote:

> Thanks Chaitanya,
>
> I haven't set LD_LIBRARY_PATH and GDAL_DATA yet.
>
> Do you know how to set them on Visual C++ 2010 ?
>
> Kind regards,
> Tai
>
>   --
> *From:* chaitanya_ch [via OSGeo.org] <[hidden 
> email]
> >
> *To:* taibc <[hidden 
> email]>
>
> *Sent:* Tuesday, July 24, 2012 10:38 AM
>
> *Subject:* Re: How to identify a point is belong to a polygon ?
>
>  Tai,
>
> If your rebuild was successful with geos, the only reason for you to get
> the error is that the application is accessing the wrong libraries
> somewhere in your system. Do a clean rebuild and make sure the
> LD_LIBRARY_PATH and GDAL_DATA are set correctly.
>
> On Tue, Jul 24, 2012 at 7:37 AM, taibc <[hidden email]> wrote:
>
> Thanks Mateusz,
>
> I edited the nmake.opt by adding below lines:
>
> GEOS_DIR = C:/geos-3.3.5
> GEOS_LIB = $(GEOS_DIR)/src/geos_c_i.lib
> GEOS_CFLAGS = -I$(GEOS_DIR)/capi -I$(GEOS_DIR)/include/geos -DHAVE_GEOS
>
> Then, I rebuilt GDAL, but still got the error: "GEOS support not enable".
>
> Kind regards,
>
> Tai
>   --
> *From:* Mateusz Loskot [via OSGeo.org ] <[hidden 
> email]
> >
> *To:* taibc <[hidden 
> email]>
>
> *Sent:* Monday, July 23, 2012 5:56 PM
> *Subject:* Re: How to identify a point is belong to a polygon ?
>
>  On 23 July 2012 11:52, taibc <[hidden email]> wrote:
> > I installed GEOS succesfful, and copy file geos.dll into my project. But
> I
> > still got the error: "GEOS support not enable" when using the method
> > "Within"
> >
> > Are there something wrongs ?
>
> You need to edit nmake.opt and rebuild GDAL.
> Check this thread:
> http://lists.osgeo.org/pipermail/gdal-dev/2010-March/023829.html
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> ___
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990029.html
>  To unsubscribe from How to identify a point is belong to a polygon ?, click
> here.
> NAML
>
>
>
> --
> View this message in context: Re: How to identify a point is belong to a
> polygon 
> ?
>
> Sent from the GDAL - Dev mailing list 
> archiveat
> Nabble.com .
>
> ___
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> --
> Best regards,
> Chaitanya kumar CH.
>
> +91-9494447584
> 17.2416N 80.1426E
>
> ___
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990248.html
>  To unsubscribe from How to identify a point is belong to a polygon ?, click
> here.
> NAML
>
>
>
> --
> View this message in context: Re: How to identify a point is belong to a
> polygon 
> ?
> Sent from the GDAL - Dev mailing list 
> archiveat 

Re: [gdal-dev] How to identify a point is belong to a polygon ?

[taibc]

Thanks Chaitanya,

I haven't set LD_LIBRARY_PATH and GDAL_DATA yet.

Do you know how to set them on Visual C++ 2010 ?

Kind regards,
Tai




 From: chaitanya_ch [via OSGeo.org] 
To: taibc  
Sent: Tuesday, July 24, 2012 10:38 AM
Subject: Re: How to identify a point is belong to a polygon ?
 

Tai,

If your rebuild was successful with geos, the only reason for you to get the 
error is that the application is accessing the wrong libraries somewhere in 
your system. Do a clean rebuild and make sure the LD_LIBRARY_PATH and GDAL_DATA 
are set correctly.


On Tue, Jul 24, 2012 at 7:37 AM, taibc <[hidden email]> wrote:

Thanks Mateusz,
>
>
>I edited the nmake.opt by adding below lines:
>
>
>GEOS_DIR = C:/geos-3.3.5
>GEOS_LIB = $(GEOS_DIR)/src/geos_c_i.lib
>GEOS_CFLAGS = -I$(GEOS_DIR)/capi -I$(GEOS_DIR)/include/geos -DHAVE_GEOS
>
>
>
>Then, I rebuilt GDAL, but still got the error: "GEOS support not enable".
>
>
>Kind regards,
>
>
>Tai
>
>
> From: Mateusz Loskot [via OSGeo.org] <[hidden email]>
>To: taibc <[hidden email]> 
>Sent: Monday, July 23, 2012 5:56 PM
>Subject: Re: How to identify a point is belong to a polygon ?
> 
>
>On 23 July 2012 11:52, taibc <[hidden email]> wrote: 
>> I installed GEOS succesfful, and copy file geos.dll into my project. But I 
>> still got the error: "GEOS support not enable" when using the method 
>> "Within" 
>> 
>> Are there something wrongs ? 
>
>You need to edit nmake.opt and rebuild GDAL. 
>Check this thread: 
>http://lists.osgeo.org/pipermail/gdal-dev/2010-March/023829.html
>
>Best regards, 
>-- 
>Mateusz Loskot, http://mateusz.loskot.net
>___ 
>gdal-dev mailing list 
>[hidden email] 
>http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>>
> 
>If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990029.html
 
>To unsubscribe from How to identify a point is belong to a polygon ?, click 
>here.
>NAML 
>
>
>>
> View this message in context: Re: How to identify a point is belong to a 
> polygon ?
>
>Sent from the GDAL - Dev mailing list archive at Nabble.com.
>
>___
>gdal-dev mailing list
>[hidden email]
>http://lists.osgeo.org/mailman/listinfo/gdal-dev
>


-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E

___ 
gdal-dev mailing list 
[hidden email] 
http://lists.osgeo.org/mailman/listinfo/gdal-dev 


 
If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990248.html
 
To unsubscribe from How to identify a point is belong to a polygon ?, click 
here.
NAML 



--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990251.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

Re: [gdal-dev] How to identify a point is belong to a polygon ?

[Chaitanya kumar CH]

Tai,

If your rebuild was successful with geos, the only reason for you to get
the error is that the application is accessing the wrong libraries
somewhere in your system. Do a clean rebuild and make sure the
LD_LIBRARY_PATH and GDAL_DATA are set correctly.

On Tue, Jul 24, 2012 at 7:37 AM, taibc  wrote:

> Thanks Mateusz,
>
> I edited the nmake.opt by adding below lines:
>
> GEOS_DIR = C:/geos-3.3.5
> GEOS_LIB = $(GEOS_DIR)/src/geos_c_i.lib
> GEOS_CFLAGS = -I$(GEOS_DIR)/capi -I$(GEOS_DIR)/include/geos -DHAVE_GEOS
>
> Then, I rebuilt GDAL, but still got the error: "GEOS support not enable".
>
> Kind regards,
>
> Tai
>   --
> *From:* Mateusz Loskot [via OSGeo.org] <[hidden 
> email]
> >
> *To:* taibc <[hidden 
> email]>
>
> *Sent:* Monday, July 23, 2012 5:56 PM
> *Subject:* Re: How to identify a point is belong to a polygon ?
>
>  On 23 July 2012 11:52, taibc <[hidden email]> wrote:
> > I installed GEOS succesfful, and copy file geos.dll into my project. But
> I
> > still got the error: "GEOS support not enable" when using the method
> > "Within"
> >
> > Are there something wrongs ?
>
> You need to edit nmake.opt and rebuild GDAL.
> Check this thread:
> http://lists.osgeo.org/pipermail/gdal-dev/2010-March/023829.html
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> ___
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990029.html
>  To unsubscribe from How to identify a point is belong to a polygon ?, click
> here.
> NAML
>
>
>
> --
> View this message in context: Re: How to identify a point is belong to a
> polygon 
> ?
>
> Sent from the GDAL - Dev mailing list 
> archiveat 
> Nabble.com.
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>



-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to identify a point is belong to a polygon ?

[taibc]

Thanks Mateusz,

I edited the nmake.opt by adding below lines:

GEOS_DIR = C:/geos-3.3.5
GEOS_LIB = $(GEOS_DIR)/src/geos_c_i.lib
GEOS_CFLAGS = -I$(GEOS_DIR)/capi -I$(GEOS_DIR)/include/geos -DHAVE_GEOS


Then, I rebuilt GDAL, but still got the error: "GEOS support not enable".

Kind regards,

Tai


 From: Mateusz Loskot [via OSGeo.org] 
To: taibc  
Sent: Monday, July 23, 2012 5:56 PM
Subject: Re: How to identify a point is belong to a polygon ?
 

On 23 July 2012 11:52, taibc <[hidden email]> wrote: 
> I installed GEOS succesfful, and copy file geos.dll into my project. But I 
> still got the error: "GEOS support not enable" when using the method 
> "Within" 
> 
> Are there something wrongs ? 

You need to edit nmake.opt and rebuild GDAL. 
Check this thread: 
http://lists.osgeo.org/pipermail/gdal-dev/2010-March/023829.html

Best regards, 
-- 
Mateusz Loskot, http://mateusz.loskot.net
___ 
gdal-dev mailing list 
[hidden email] 
http://lists.osgeo.org/mailman/listinfo/gdal-dev



 
If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990029.html
 
To unsubscribe from How to identify a point is belong to a polygon ?, click 
here.
NAML 



--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990235.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

[gdal-dev] encoding problem when reading DXF file

[dequan chen]

hi all,
I download the latest gdal-19-1600-core.msi from
http://www.gisinternals.com/sdk and installed, then copy gdal_csharp.dll,
ogr_csharp.dll, osr_csharp.dll etc to read .DXF file. But it has the problem
of charactor encoding. My DXF file contains chinese charactor that code is
GB2312. If i use DLLs from FWTOOLS, the charactor encoding correctly, but i
cannot to run my compiled EXE (both debug and release versions). The
application just crashes.
What more work should i do ? thanks advanced.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset

[Tamas Szekeres]

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 

> 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 > >
>>
>>
>> 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
>> shape

Re: [gdal-dev] New OGR driver: Imageset (Tamas Szekeres)

[Tamas Szekeres]

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, C# Java
whatever) which is more complicated to utilize in most cases.

Best regards,

Tamas



2012/7/23 Daniel Clewley 

> 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 could use OGR to
> output a vector data source instead.
>
> The script can be downloaded from here:
>
> http://dropbox.aber.ac.uk/?**KJHsTqst
>
> Thanks,
>
> Dan
>
> On Mon, 23 Jul 2012 09:51:14 +0200, Tamas Szekeres wrote:
>
> > 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.
> >
> > Best regards,
> >
> > Tamas
> >
>
> __**_
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/**mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Oracle support available by default in any OSGeo software

[Ivan Lucena]

Hi Vincent,

So I think we can agree that OCILIB does not bring any advantage other than 
some unlikely inconvenience of having OCI header and libraries available. You 
cannot remove the dependence of having access to an Oracle server anyway.

The use of OCILIB was evaluated and discussed during the development of 
GDAL/GeoRaster and it didn't make the final cut. I know that some other FOSS 
projects went to the same conclusion.

But you are absolutely right, the OGR/OCI driver does need some love and care. 
I would suggest reusing the code in frmts/georaster/oci_wrapper.h to access 
OCI. That same code is already shared by others OSGeo projects to support Point 
Cloud data for example. 

But again, changing the OCI wrapper or using a "dependency-free" wrapper is not 
going to give you any improvement. After that someone would need to look into 
performance issues and limitations, anyway.

Today, the GDAL/GeoRaster driver have a limitation. It does not support RPC. It 
is just a matter of passing some metadata notation to and from the driver to 
GDAL but when the driver was first develop GDAL didn't support RPC. The OGR/OCI 
driver must have some of those historical reasons too.

Thanks for your interest in helping.

Best regards,

Ivan


>  ---Original Message---
>  From: vincent rogier 
>  To: Ivan Lucena 
>  Cc: Nicolas Simon , gdal-dev@lists.osgeo.org
>  Subject: Re: [gdal-dev] Oracle support available by default in any OSGeo 
> software
>  Sent: Jul 23 '12 13:02
>  
>  Hi all,
>  
>  I just want to add some precisions about what was said in that
>  conversation.
>  
>  Ivan is right, OCILIB is a wrapper around OCI.
>  But OCILIB can be built without any dependencies as it does not require
>  oracle headers or libraries to compile and it can dynamically load any
>  Oracle Client runtime.
>  
>  If the current used driver is stable, fully compliant with its desired
>  usage and if it delivers acceptable performances, there is no point trying
>  to make another one using OCILIB for example.
>  
>  I had a quick look at the gdal oci driver wiki page. It apparently shows
>  some limitations.
>  I also looked at the code, and it seems limited in some areas such as
>  data type support, ...
>  It could be also optimized in terms of OCI usage and performances.
>  
>  I often see discussion in dev mailing lists like this one. And sometimes, i
>  see negative reactions about using a third party wrapper for OCI because
>  there are just wrappers. Yes, indeed, But wrappers like OCILIB handle all
>  the common nightmares like portability across platforms, runtime oracle
>  versions, and delivivers a much more maintainable application code, much
>  shorter code, performance improvement due to OCI internal expertise,
>  etc
>  
>  But once again, if the current driver matches its intended use really well,
>  is stable, scalable and does not restrict future enhancements, you should
>  stick to it and grab some pre built binaries for you OS.
>  
>  
>  Best regards,
>  
>  Vincent
>  
>  
>  On Mon, Jul 23, 2012 at 7:26 PM, Ivan Lucena <[LINK:
>  mailto:ivan.luc...@princeton-ma.us] ivan.luc...@princeton-ma.us> wrote:
>  Nicolas,
>  
>  If you install QGIS from OSGeo4W you should be able to also install the
>  Libs package "gdal-oracle: OGR OCI and GDAL GeoRaster Plugins for Oracle"
>  with the files gdal_GEOR.dll and ogr_OCI.dll. That is all you need in QGIS.
>  
>  But if you don't use OSGeo4W you can grab the same files from Tamas
>  Szekeres website (see [LINK:
>  http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries]
>  http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries).
>  
>  
>  >  >  I't very frustrating, each time I would like to use OSGeo
>  software
>  >  >  (GDAL/OGR, QGIS, ...) they don't support oracle database.
>  Every time,
>  
>  >  >  everything should be recompiled from source with oracle support
>  enabled. A
>  >  >  long and not easy process...
>  
>  I understand your frustration. But note that all GDAL/OGR driver that have
>  dependency should not be incorporated by default into product distribution
>  to avoid annoying "cannot find shared library xxx" messages or any other
>  more serious error. Those driver are build as plugins so that they can be
>  easily added or removed from the path.
>  
>  
>  >  >
>  >  >  The reason usually evoked for this situation, is that Oracle build
>  >  >  needs Oracle files that aren't freely redistributable. Ok
>  It's a good
>  >  >  reason.
>  
>  You can freely download all the necessary files to compile against OCI
>  from [LINK: http://oracle.com] oracle.com.
>  
>  >  >
>  >  >  I found a library, called OCILIB (<[LINK:
>  >  >  [LINK: http://orclib.sourceforge.net/]
>  http://orclib.sourceforge.net/] [LINK: http://orclib.sourceforge.net/]
>  http://orclib.sourceforge.net/>), that
>  
>  >  >  enable your software to dynamically connect to your oracle
>  database. This
>  >  >  library does not require any oracle library to compile.

[gdal-dev] Updated rgb2pct.py for greyscale images

[Kreiser, Kevin]

I ran into a small limitation of rgb2pct.py when processing the 
http://www.glcf.umd.edu/data/landcover/data.shtml 1km AVHRR landcover data set. 
Essentially the data is structured such that there is a single color channel in 
which each pixel has a value between 0 - 14. Where 0 is water and 1-4 are 
forest etc.

At any rate, I needed a way to map those values to colors so I wanted to 
paletize the image. I of course tried rgb2pct.py but it only supported rgb 
images. So I set out to overcome this with a short hack to the script. I wasn't 
sure where to post this so I'm trying th is mailing list in case someone might 
want it in the repositor.

Anyway I've attached my modified version of the script to this post.

Thanks to the creators/contributers of gdal for these awesome resources!


#!/usr/bin/env python
#**
#  $Id: rgb2pct.py 18952 2010-02-28 11:59:53Z rouault $
# 
#  Name: rgb2pct
#  Project:  GDAL Python Interface
#  Purpose:  Application for converting an RGB image to a pseudocolored image.
#  Author:   Frank Warmerdam, warmer...@pobox.com
# 
#**
#  Copyright (c) 2001, Frank Warmerdam
# 
#  Permission is hereby granted, free of charge, to any person obtaining a
#  copy of this software and associated documentation files (the "Software"),
#  to deal in the Software without restriction, including without limitation
#  the rights to use, copy, modify, merge, publish, distribute, sublicense,
#  and/or sell copies of the Software, and to permit persons to whom the
#  Software is furnished to do so, subject to the following conditions:
# 
#  The above copyright notice and this permission notice shall be included
#  in all copies or substantial portions of the Software.
# 
#  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
#  OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
#  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
#  THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
#  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
#  FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
#  DEALINGS IN THE SOFTWARE.
#**

try:
from osgeo import gdal
except ImportError:
import gdal

import sys
import os.path

def Usage():
print('Usage: rgb2pct.py [-n colors | -pct palette_file] [-of format] source_file dest_file')
sys.exit(1)

# =
#  Mainline
# =

color_count = 256
format = 'GTiff'
src_filename = None
dst_filename = None
pct_filename = None

gdal.AllRegister()
argv = gdal.GeneralCmdLineProcessor( sys.argv )
if argv is None:
sys.exit( 0 )

# Parse command line arguments.
i = 1
grey = False
while i < len(argv):
arg = argv[i]

if arg == '-of':
i = i + 1
format = argv[i]

elif arg == '-n':
i = i + 1
color_count = int(argv[i])

elif arg == '-pct':
i = i + 1
pct_filename = argv[i]

elif arg =='-grey':
grey = True

elif src_filename is None:
src_filename = argv[i]

elif dst_filename is None:
dst_filename = argv[i]

else:
Usage()

i = i + 1

if dst_filename is None:
Usage()

# Open source file

src_ds = gdal.Open( src_filename )
if src_ds is None:
print('Unable to open %s' % src_filename)
sys.exit(1)

if grey == False and src_ds.RasterCount < 3:
print('%s has %d band(s), need 3 for inputs red, green and blue.' \
  % (src_filename, src_ds.RasterCount))
sys.exit(1)

# Ensure we recognise the driver.

dst_driver = gdal.GetDriverByName(format)
if dst_driver is None:
print('"%s" driver not registered.' % format)
sys.exit(1)

# Generate palette

ct = gdal.ColorTable()
if pct_filename is None:
err = gdal.ComputeMedianCutPCT( src_ds.GetRasterBand(1),
src_ds.GetRasterBand(2 if grey == False else 1),
src_ds.GetRasterBand(3 if grey == False else 1),
color_count, ct,
callback = gdal.TermProgress,
callback_data = 'Generate PCT' )
else:
pct_ds = gdal.Open(pct_filename)
ct = pct_ds.GetRasterBand(1).GetRasterColorTable().Clone()
# Check palette is legal for grey scale image (each channel of a given color is the same value, ignore alpha)
if grey == True:
for i in range(0, ct.GetCount()):
c = ct.GetColorEntry(i)
if c[0] != c[1] or c[0] != c[2]:
print('Non-greysacle color "%s" found in pct but provided image

Re: [gdal-dev] how to create NETCDF with several 3D variables?

[Etienne Tourigny]

Chris is right - the netcdf driver in gdal was designed to read netcdf
data and create netcdf files from other formats, not write complex
files.

Anything else is a hack - better to use other tools if you want to
combine bands, variables, etc.

Etienne

On Mon, Jul 23, 2012 at 2:07 PM, Chris Barker  wrote:
> On Mon, Jul 23, 2012 at 7:50 AM, Anton Korosov  wrote:
>
>> how to create a NetCDF file with several variables that have more than two
>> dimensions?
>
> I"m sure you can get this to work, but...
>
> netcdf has a pretty different data model than GDAL -- I suspect you'll
> be fighting that regularly. You may be better off workign with a more
> native netcdf driver. If you are at all familiar with Python, the
> "netCDF4" python module is great:
>
> http://netcdf4-python.googlecode.com/svn/trunk/docs/netCDF4-module.html
>
> ( you can read stuff in other formats with GDAL, and write with
> netcdf4, if that makes sense )
>
> you may want to give it a try.
>
> -Chris
>
>
>> I have to save time series of several fields (sst, chlorophyll, etc) in one
>> file.
>>
>> I found that in order to create one 3D variable I can add
>> NETCDF_DIM_EXTRA, NETCDF_DIM_time_DEF, NETCDF_DIM_time_VALUES to the
>> metadata in a VRT file. Then I use 'gdal_translate -of NetCDF' or
>> gdal.GetDriverByName('NetCDF').CreateCopy() to generate a .nc file.
>>
>> However I cannot make several 3D variables!
>>
>> Here are two VRTs. One works fine (one variable: 'sst', 3 dimentions: time,
>> x, y). Another one produces two variables (chl, sst)  but time dimension is
>> not added!
>> Is it possible to do it in theory?
>>
>> I use the latest release of GDAL 2.0dev
>>
>> With best regards and great thanks for the developers of the fantastic
>> NetCDF driver!
>>
>> Anton
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Oracle support available by default in any OSGeo software

[Ivan Lucena]

Nicolas,

If you install QGIS from OSGeo4W you should be able to also install the Libs 
package "gdal-oracle: OGR OCI and GDAL GeoRaster Plugins for Oracle" with the 
files gdal_GEOR.dll and ogr_OCI.dll. That is all you need in QGIS.

But if you don't use OSGeo4W you can grab the same files from Tamas Szekeres 
website (see http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries).

>  >  I't very frustrating, each time I would like to use OSGeo software
>  >  (GDAL/OGR, QGIS, ...) they don't support oracle database. Every time,
>  >  everything should be recompiled from source with oracle support enabled. A
>  >  long and not easy process...

I understand your frustration. But note that all GDAL/OGR driver that have 
dependency should not be incorporated by default into product distribution to 
avoid annoying "cannot find shared library xxx" messages or any other more 
serious error. Those driver are build as plugins so that they can be easily 
added or removed from the path.

>  >  
>  >  The reason usually evoked for this situation, is that Oracle build
>  >  needs Oracle files that aren't freely redistributable. Ok It's a good
>  >  reason.

You can freely download all the necessary files to compile against OCI from 
oracle.com.

>  >  
>  >  I found a library, called OCILIB (<[LINK:
>  >  http://orclib.sourceforge.net/] http://orclib.sourceforge.net/>), that
>  >  enable your software to dynamically connect to your oracle database. This
>  >  library does not require any oracle library to compile. It's available on
>  >  any platform where oracle client is available and it licensed with LGPL.

The OCILIB library is just a shell around OCI. You still need OCI distribution 
from a server, client or instant client installation in order to compile or run 
any code based on that library. 

>  >  But before going further, I would like to know if it seems to you a
>  >  good way to have Oracle support available by default in any OSGeo software

The OSGeo4W and Tamasz packages solutions are working pretty well for Windows 
users, so far. For QGIS all you have to do is to enable the Oracle Raster 
driver, is you want to use GeoRaster. Works pretty fast if the image has 
overviews. Please note that other OSGeo and commercial software can also access 
Oracle Spatial through GDAL.

>  >  Depending of your answers, I 'll come back to ask you how it's the
>  >  best way to do that ?

I hope that would answer your question.

Regards,

Ivan
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OSM Driver and World Planet file (pbf format)

[Smith, Michael ERDC-CRREL-NH]

Even, 

[osmusr@bigserver-proc osm]$ ogr2ogr -progress -f oci
oci:user/pass@tns:tmp planet-latest.osm.pbf -lco dim=2 -lco srid=4326 -lco
geometry_name=geometry -lco launder=yes --debug on  2>osm_debug.log
0...10...20...30...40...50...60Š70
[osmusr@bigserver-proc osm]$



>From the debug output

OCI: Flushing 100 features on layer POLYGONS
OCI: Flushing 100 features on layer POLYGONS
OCI: Flushing 100 features on layer POLYGONS
OCI: Flushing 100 features on layer POLYGONS
OCI: Flushing 100 features on layer POLYGONS
OCI: Flushing 100 features on layer POLYGONS

OCI: Flushing 100 features on layer POLYGONS
OSM: Switching to 'lines' as they are too many features in 'polygons'
OGR2OGR: 32827 features written in layer 'POLYGONS'
OCI: In Create Layer ...
OCI: Prepare(CREATE TABLE "MULTILINESTRINGS" ( OGR_FID INTEGER, geometry
MDSYS.SDO_GEOMETRY ))
OGR2OGR: 0 features written in layer 'MULTILINESTRINGS'
OCI: In Create Layer ...
OCI: Prepare(CREATE TABLE "MULTIPOLYGONS" ( OGR_FID INTEGER, geometry
MDSYS.SDO_GEOMETRY ))
OGR2OGR: 0 features written in layer 'MULTIPOLYGONS'
OCI: In Create Layer ...
OCI: Prepare(CREATE TABLE "OTHER_RELATIONS" ( OGR_FID INTEGER, geometry
MDSYS.SDO_GEOMETRY ))
OGR2OGR: 0 features written in layer 'OTHER_RELATIONS'
OCI: Flushing 23 features on layer POINTS
OCI: Flushing 99 features on layer LINES
OCI: Flushing 27 features on layer POLYGONS
OSM: nNodeSelectBetween = 50006
OSM: nNodeSelectIn = 94362
VSI: ~VSIUnixStdioFilesystemHandler() : nTotalBytesRead = 12682608949


(note that I removed some alter table lines for clarity)


Mike

On 7/23/12  9:16 AM, "Smith, Michael ERDC-CRREL-NH"
 wrote:

>Even,
>
>It stopped cleanly (no segfault) at 70%. OS is RHEL 6.2 64 bit. Import
>time was about 340 min.
>
>Command was 
>
>ogr2ogr -progress -f oci oci:user/pass@tns:tmp planet-latest.osm.pbf -lco
>dim=2 -lco srid=4326 -lco geometry_name=geometry -lco launder=yes
>
>I'm rerunning now with the debug log to a file.
>
>Mike
>
>-- 
>Michael Smith
>
>Remote Sensing/GIS Center
>US Army Corps of Engineers
>
>
>
>On 7/23/12  7:05 AM, "Even Rouault"  wrote:
>
>>Le lundi 23 juillet 2012 12:56:12, Smith, Michael ERDC-RDE-CRREL-NH a
>>écrit :
>>> I'm finding that the new OSM Driver (I tested again with r24699) has a
>>> problem when working with the whole planet file. When I tried with the
>>>US
>>> Northeast subset, I got multipolygons and multilinestring entries. When
>>> reading the whole planet file, I did not. It gets to 70% and then ends
>>> (but without an error message). I also got fewer polygons than I was
>>> expecting. It seems like the reading got interrupted by some non
>>>reported
>>> error.
>>> 
>>> I was writing to Oracle for this importing but got the same results
>>>writing
>>> to sqlite. It seems that smaller extracts work fine but the are some
>>> reading issues with the whole planet file (in pbf format). I can try
>>>with
>>> the .osm format.
>>
>>I didn't try yet with whole planet files. Takes too much time :-)
>>
>>Which command line did you use exactly ?
>>
>>Did it stop cleanly or with a segfault ? In the latter case, (assuming
>>you are 
>>on Linux), running under gdb might be useful.
>>
>>What is your OS, 32/64 bit ? Perhaps, you could add --debug on. I'd
>>suggest 
>>redirecting standard error file to a file because the log file can be
>>huge.
>>___
>>gdal-dev mailing list
>>gdal-dev@lists.osgeo.org
>>http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>___
>gdal-dev mailing list
>gdal-dev@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] how to create NETCDF with several 3D variables?

[Chris Barker]

On Mon, Jul 23, 2012 at 7:50 AM, Anton Korosov  wrote:

> how to create a NetCDF file with several variables that have more than two
> dimensions?

I"m sure you can get this to work, but...

netcdf has a pretty different data model than GDAL -- I suspect you'll
be fighting that regularly. You may be better off workign with a more
native netcdf driver. If you are at all familiar with Python, the
"netCDF4" python module is great:

http://netcdf4-python.googlecode.com/svn/trunk/docs/netCDF4-module.html

( you can read stuff in other formats with GDAL, and write with
netcdf4, if that makes sense )

you may want to give it a try.

-Chris


> I have to save time series of several fields (sst, chlorophyll, etc) in one
> file.
>
> I found that in order to create one 3D variable I can add
> NETCDF_DIM_EXTRA, NETCDF_DIM_time_DEF, NETCDF_DIM_time_VALUES to the
> metadata in a VRT file. Then I use 'gdal_translate -of NetCDF' or
> gdal.GetDriverByName('NetCDF').CreateCopy() to generate a .nc file.
>
> However I cannot make several 3D variables!
>
> Here are two VRTs. One works fine (one variable: 'sst', 3 dimentions: time,
> x, y). Another one produces two variables (chl, sst)  but time dimension is
> not added!
> Is it possible to do it in theory?
>
> I use the latest release of GDAL 2.0dev
>
> With best regards and great thanks for the developers of the fantastic
> NetCDF driver!
>
> Anton
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset

[Etienne Tourigny]

It might be worth enhancing gdaltindex, using gdal's native exif file reading.

Etienne

On Mon, Jul 23, 2012 at 12:38 PM, Nicolas Simon
 wrote:
> Hi
> For me it looks like a variant of gdaltindex with input made from 
> specials fields (EXIF data).
> Output (shapefile for instance) could be translated into whatever you 
> want through ogr2ogr.
>
> Regards
>
> Nicolas
>
> -Message d'origine-
> 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
> 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 > >
>>
>> 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.
>>
>> Doin

Re: [gdal-dev] how to create NETCDF with several 3D variables?

[Etienne Tourigny]

Hi

glad you like the driver.  Interesting that you were able to create a
3d file like that! I had thought of it but never tested. Those
NETCDF_DIM_* metadata I added to be able to deal with 3d variables in
a clean manner.

I'm afraid you cannot combine several variables (or subdatasets as
gdal calls them) inside one netcdf file with the driver. You should
use other tools for that.  You could, for example, use 'cdo merge
ifile1.nc ifile2.nc ofile.nc'.

See https://code.zmaw.de/projects/cdo/

Etienne
On Mon, Jul 23, 2012 at 11:50 AM, Anton Korosov  wrote:
> Dear list,
>
> how to create a NetCDF file with several variables that have more than two
> dimensions?
> I have to save time series of several fields (sst, chlorophyll, etc) in one
> file.
>
> I found that in order to create one 3D variable I can add
> NETCDF_DIM_EXTRA, NETCDF_DIM_time_DEF, NETCDF_DIM_time_VALUES to the
> metadata in a VRT file. Then I use 'gdal_translate -of NetCDF' or
> gdal.GetDriverByName('NetCDF').CreateCopy() to generate a .nc file.
>
> However I cannot make several 3D variables!
>
> Here are two VRTs. One works fine (one variable: 'sst', 3 dimentions: time,
> x, y). Another one produces two variables (chl, sst)  but time dimension is
> not added!
> Is it possible to do it in theory?
>
> I use the latest release of GDAL 2.0dev
>
> With best regards and great thanks for the developers of the fantastic
> NetCDF driver!
>
> Anton
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogr: ExecuteSQL with MSSQL and geometry column

[Benjamin]

Now, I am able to answer to me.

Correct me if I am wrong but :

With the MSSQL Driver ,when you execute a statment with SQLExecute() the
result is a table without geometry field.
Then the in the layer give by "SELECT *  FROM my_table WHERE CHART_ID =
'my_id'" the geometry column is consider as a simple field like another.

In fact, you can see this field by .GetField(int i), and you can't see a
geometric field like that.

So to have a geometric field I have to use :
DataSource.GetLayerByName("my_table").SetAttributFilter("CHART_ID =
'my_id'")

I don't know if it is as efficient as a SELECT statment, but it work fine !

Thank to all your answers !

Best regards,
Benjamin.


Benjamin wrote
> 
> If you want I can remove the MemoryDriver, but it is still the same thing.
> 
> [code]
> string request = "SELECT *  FROM MY_TABLE WHERE CHART_ID = 'Z15F43AJ'";
> Layer serverLayer = RclDataSource.ExecuteSQL(request, null, "");
> 
> int nbFeature = serverLayer.GetFeatureCount(1);
> Feature serverFeature = serverLayer.GetNextFeature();
> string[] namesColumnsArray = new string[3];
> for (int i = 0; i < serverFeature.GetFieldCount(); i++)
> namesColumnsArray[i] = serverFeature.GetFieldDefnRef(i).GetName();
> Geometry serverGeometry = serverFeature.GetGeometryRef();
> [/code]
> 
> Results:
> nbFeature = 39
> namesColumnsArray = { D , CHART_ID, WKB_GEOMETRY }
> serverGeometry = null
> 
> 
> For me the fact is that the result of the SQL request is a layer without
> geometry field, just 3 usuals fields.
> I suppose that is normal because if you ask for a request like :
> "Select column_geo1, column_geo2
> From Table1, Table2"
> Unless I am wrong, you can't have 2 geometrics fields in a layer.
> 
> For me this result is normal (but I am a beginner with ogr so maybe not).
> 
> Reminder : I just want fetch my geometry.
> 
> In any cases, thank for all you reply Chaitanya_ch.
> 
> Benjamin.
> 
> 
> chaitanya_ch wrote
>> 
>> Benjamin,
>> 
>> First thing: You don't need to use a memory datasource here. OGR doesn't
>> make round trips to the database server every time you run
>> GetNextFeature(). Do that first. I'm sure it will make it less
>> complicated.
>> 
>> I don't understand why you are getting the null. Hopefully we can figure
>> that out after you simplify your code by removing the memory driver
>> stuff.
>> 
>> On Wed, Jul 18, 2012 at 8:52 PM, Benjamin LUX wrote:
>> 
>>> Hi again Chaitanya,
>>>
>>> ** **
>>>
>>> If you look my previous mail you can see the code.
>>>
>>> But in a compact way this is a copy/paste of my running code.
>>>
>>> Note that RoleEnvironment.GetConfigurationSettingValue(“”) just
>>> provide me parametrables strings (like argv[n]).
>>>
>>> [code]
>>>
>>> Ogr.RegisterAll();
>>>
>>> string option = String.Format(
>>> "Tables=dbo.{0}(WKB_GEOMETRY);GeometryFormat=wkb;",
>>>
>>> RoleEnvironment.GetConfigurationSettingValue(
>>> "CatalogueRclAllName")
>>>
>>> );
>>>
>>> RclDataSource = Ogr.Open(String.Format("MSSQL:{0}{1}", RoleEnvironment
>>> .GetConfigurationSettingValue("DataBaseConnectionString"), option),
>>> 0);***
>>> *
>>>
>>> string request = String.Format("SELECT *  FROM {0} WHERE CHART_ID =
>>> '{1}'"
>>> ,
>>>
>>> RoleEnvironment.GetConfigurationSettingValue("CatalogueRclAllName"),
>>>
>>> "Z15F43AJ");
>>>
>>> ** **
>>>
>>> Layer serverLayer = RclDataSource.ExecuteSQL(request, null, "");
>>>
>>> ** **
>>>
>>> Driver memDriver = Ogr.GetDriverByName("Memory");
>>>
>>> DataSource memDataSource = memDriver.CreateDataSource(GetWorkPath(
>>> "nomimprobale"), null);
>>>
>>> Layer memLayer = memDataSource.CopyLayer(serverLayer,
>>> serverLayer.GetName(), null);
>>>
>>> Feature memFeature = memLayer.GetNextFeature();
>>>
>>> string[] namesColumnsArray = new string[5];
>>>
>>> for (int i = 0; i < memFeature.GetFieldCount(); i++)
>>>
>>> namesColumnsArray[i] = memFeature.GetFieldDefnRef(i).GetName();
>>>
>>> Geometry memGeometry = memFeature.GetGeometryRef(); 
>>>
>>> [/code]
>>>
>>> ** **
>>>
>>> Results :
>>>
>>> namesColumnsArray = { D , CHART_ID, WKB_GEOMETRY }
>>>
>>> memGeometry = null
>>>
>>> ** **
>>>
>>> I don’t see what I can add to this :/
>>>
>>> If you want more details said me.
>>>
>>> ** **
>>>
>>> Link to the thread :
>>> http://osgeo-org.1560.n6.nabble.com/gdal-dev-Ogr-ExecuteSQL-with-MSSQL-and-geometry-column-tp4988831.html
>>> 
>>>
>>> ** **
>>>
>>> Best regards,
>>>
>>> Benjamin
>>>
>>> ** **
>>>
>>> *De :* Chaitanya kumar CH [mailto:chaitanya.ch@]
>>> *Envoyé :* mercredi 18 juillet 2012 16:53
>>> *À :* Benjamin LUX
>>> *Cc :* gdal dev
>>> *Objet :* Re: Ogr: ExecuteSQL with MSSQL and geometry column
>>>
>>> ** **
>>>
>>> Hi Benjamin,
>>>
>>> Can you provide some more details?
>>> How did you try to retrieve the geometry?
>>>
>>> On Wed, Jul 18, 2012 at 8:02 PM,

Re: [gdal-dev] New OGR driver: Imageset

[Eli Adam]

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://activityworkshop.net/software/gpsprune/index.html,
which did what I wanted but better.

I think that this would be a useful utility.

Eli

On Mon, Jul 23, 2012 at 8:26 AM, 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 > >
>>
>>
>> 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.
>>
>>  

Re: [gdal-dev] New OGR driver: Imageset

[Nicolas Simon]

Hi 
For me it looks like a variant of gdaltindex with input made from 
specials fields (EXIF data).
Output (shapefile for instance) could be translated into whatever you 
want through ogr2ogr.

Regards

Nicolas 
  
-Message d'origine-
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 
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  >
>
> 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
>
>
>
>
> 

Re: [gdal-dev] New OGR driver: Imageset

[Daniel Morissette]

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 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




--
Daniel Morissette
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset (Tamas Szekeres)

[Daniel Clewley]

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 could 
use OGR to output a vector data source instead.


The script can be downloaded from here:

http://dropbox.aber.ac.uk/?KJHsTqst

Thanks,

Dan

On Mon, 23 Jul 2012 09:51:14 +0200, Tamas Szekeres wrote:

> 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.
>
> Best regards,
>
> Tamas
>

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] how to create NETCDF with several 3D variables?

[Anton Korosov]

Dear list,

how to create a NetCDF file with several variables that have more than 
two dimensions?
I have to save time series of several fields (sst, chlorophyll, etc) in 
one file.


I found that in order to create one 3D variable I can add
NETCDF_DIM_EXTRA, NETCDF_DIM_time_DEF, NETCDF_DIM_time_VALUES to the 
metadata in a VRT file. Then I use 'gdal_translate -of NetCDF' or 
gdal.GetDriverByName('NetCDF').CreateCopy() to generate a .nc file.


However I cannot make several 3D variables!

Here are two VRTs. One works fine (one variable: 'sst', 3 dimentions: 
time, x, y). Another one produces two variables (chl, sst)  but time 
dimension is not added!

Is it possible to do it in theory?

I use the latest release of GDAL 2.0dev

With best regards and great thanks for the developers of the fantastic 
NetCDF driver!


Anton

  GEOGCS["Clarke_1866",DATUM["Clarke_1866",SPHEROID["Clarke 
1866",6378206.4,294.9786982139006]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]]
   -1.799491497874e+02,  8.335816860199e-02,  
0.e+00,  9.002544373274e+01,  0.e+00, 
-8.335816860199e-02
  
{time}
{3,6}
{0,1,2}
  
  

  0
  sst

Gray

  gdal_test/alwdgg.tif
  1
  
  
  

  
  

  1
  sst

Gray

  gdal_test/alwdgg.tif
  1
  
  
  

  
  

  2
  sst

Gray

  gdal_test/alwdgg.tif
  1
  
  
  

  


  GEOGCS["Clarke_1866",DATUM["Clarke_1866",SPHEROID["Clarke 
1866",6378206.4,294.9786982139006]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]]
   -1.799491497874e+02,  8.335816860199e-02,  
0.e+00,  9.002544373274e+01,  0.e+00, 
-8.335816860199e-02
  
{time}
{0,6}
0
  
  

  0
  sst

Gray

  gdal_test/alwdgg.tif
  1
  
  
  

  
  

  0
  chl

Gray

  gdal_test/alwdgg.tif
  1
  
  
  

  

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Coordinate Transformation issue

[Christiaan Janssen]

Hi,

I've been working with the OGR coordinate transformations for some time and
as long as I can remember, when calling the Transform function, no matter
what I'm transforming to or from I always need to convert the unit length
type of the Z component manually. For example, I've created a "from"
Coordinate System that is WGS84 Lat/Long METERS and a "to" Coordinate
System that is NAD83 State Plane North Carolina FEET. When I call the
Transform function, supplying all three components, the X and Y components
are transformed correctly while the Z component is left unchanged. I
realize that no vertical Datum transformation is done, which is fine, but
what's odd is that the Z value is still in the original meters and not in
feet. What I'm curious of is if this is intended result or am I doing
something wrong. The reason I'm asking is that version 1.9.0 started
converting the Z values for me (I noticed the changelog lists a change of
adding vertical unit support which I presume would be why it does this now)
but when I compiled 1.9.1 it seemed to revert back to its old ways of not
changing Z. It's probably an issue on my end but I was hoping someone could
help. If you need any additional information, just let me know. Thanks.

Christiaan
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

[Rahkonen Jukka]

Even Rouault wrote:
23. heinäkuuta 2012 13:27

> Le lundi 23 juillet 2012 00:09:05, Jukka Rahkonen a écrit :
>> Even Rouault  mines-paris.org> writes:
>> > > > However, select with SQL feels sub-optimal.
>> > >
>> > > Yes, when you use ogr2ogr with explicit layer names, there are
>> > > optimizations. For example, when you only specify the layer 'points',
>> > > the OSM driver will not even try to index the nodes into the temporary
>> > > database because it is not needed. However, as you noticed, there is
>> > > not yet any optimization when a SQL request is specified.
>> >
>> > Optimization for SQL request added in r24690
>
>> I had a try with r24696 today, downloaded from
>> http://gisinternals.com/sdk/Download.aspx?file=release-1500-gdal-mapserver.
>> zip
>>
>> Filtered commands give me errors. An example:
>> ogr2ogr -f "ESRI Shapefile" test germany.osm.pbf multipolygons -gt 2
>> -progress --config OGR_SQLITE_SYNCHRONOUS OFF -where "natural='forest'"
>>
>> ERROR 1: Failed inserting node 420797898: database schema has changed

> I could also reproduce and I suppose there was at the begnning of the sequence
> of errors : "ERROR 1: Failed inserting node : I/O error"

Most probably yes but I saw only the last lines of the first thousand which were
printed on the screen.

> It turned out that the mechanism to transfer the temporary in-memory DB file 
> to
> disk when it is too big had been broken by a previous commit, so it stayed on
> RAM and at some point, it couldn't fit in RAM, hence the error. Should be 
> fixed
> now with r24699.

> I'm experimenting with removing the internal use of SQLite for the temporary
> database and replacing it with something custom. Actually, it won't replace it
> completely in all cases, but it could definitely be used in well-behaved cases
> where the elements in the .osm/.pbf are listed in increasing id order, which
> is the case of the data in geofabrik files for example. The first results seem
> to show increased performance.

> Note: in your above example, you don't need to specify -gt and --config
> OGR_SQLITE_SYNCHRONOUS OFF when the output format is not sqlite/spatialite.
> And the internal use of SQLite in the OSM driver already sets the
> corresponding parameters to the values that give the best performance.

Sure true with extra parametes, I just forgot to remove them when doing
a quick verification for seeing if the error occurs similarly for spatialite 
and 
shapefile outputs.

-Jukka-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OSM Driver and World Planet file (pbf format)

[Smith, Michael ERDC-CRREL-NH]

Even,

It stopped cleanly (no segfault) at 70%. OS is RHEL 6.2 64 bit. Import
time was about 340 min.

Command was 

ogr2ogr -progress -f oci oci:user/pass@tns:tmp planet-latest.osm.pbf -lco
dim=2 -lco srid=4326 -lco geometry_name=geometry -lco launder=yes

I'm rerunning now with the debug log to a file.

Mike

-- 
Michael Smith

Remote Sensing/GIS Center
US Army Corps of Engineers



On 7/23/12  7:05 AM, "Even Rouault"  wrote:

>Le lundi 23 juillet 2012 12:56:12, Smith, Michael ERDC-RDE-CRREL-NH a
>écrit :
>> I'm finding that the new OSM Driver (I tested again with r24699) has a
>> problem when working with the whole planet file. When I tried with the
>>US
>> Northeast subset, I got multipolygons and multilinestring entries. When
>> reading the whole planet file, I did not. It gets to 70% and then ends
>> (but without an error message). I also got fewer polygons than I was
>> expecting. It seems like the reading got interrupted by some non
>>reported
>> error.
>> 
>> I was writing to Oracle for this importing but got the same results
>>writing
>> to sqlite. It seems that smaller extracts work fine but the are some
>> reading issues with the whole planet file (in pbf format). I can try
>>with
>> the .osm format.
>
>I didn't try yet with whole planet files. Takes too much time :-)
>
>Which command line did you use exactly ?
>
>Did it stop cleanly or with a segfault ? In the latter case, (assuming
>you are 
>on Linux), running under gdb might be useful.
>
>What is your OS, 32/64 bit ? Perhaps, you could add --debug on. I'd
>suggest 
>redirecting standard error file to a file because the log file can be
>huge.
>___
>gdal-dev mailing list
>gdal-dev@lists.osgeo.org
>http://lists.osgeo.org/mailman/listinfo/gdal-dev

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotransform rotation and gdal_merge

[David Hoese]

Chaitanya,

I attempted a few small examples with GCPs and gdalwarp told me:
"ERROR 1: Failed to compute GCP transform: Transform is not solvable

I tried it with 2 GCPs at the sides from a 1x15 image array and another 
with every point's GCP defined, both failed with that error.  Sorry I 
forgot to mention this, I'll be using the python API and the data is 
provided as 3 numpy arrays, image/lat/lon. I've tried using rotation now 
then running it through gdalwarp which seems to work (although you lose 
a lot of data with the settings I was using).  And by work I mean that 
gdalwarp recognizes the rotation of the data and puts it into an 
aligned/square grid.  Another thing I may not have mentioned is that 
I'll eventually be putting this data into MapServer for WMS viewing.


If I'm not missing something, doesn't gdalwarp essentially do the same 
thing as gdal_merge.py, at least in this case?  It's even better if it 
actually uses the rotation in its calculations.


Also, I know the pixels won't be aligned exactly because the instrument 
is on an aircraft that's moving/turning.  It's more important that the 
data gets shown, not that its in the exact location.


-Dave

On 7/23/12 7:02 AM, Chaitanya kumar CH wrote:

Dave,

The reason you have lat/lon values for each pixel is because they may 
not be aligned exactly.
Even though it is not very 'efficient', you have to define the GCPs 
for each pixel with the lat/lon values of that pixel. Then you use 
gdalwarp while forcing use of these GCPs to combine all the images.


How are the lat/lon values stored?


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Oracle support available by default in any OSGeo software

[Ivan Lucena]

Hi Nicolas,

What operational system do you want to use?

Regards,

Ivan

>  ---Original Message---
>  From: Nicolas Simon 
>  To: gdal-dev@lists.osgeo.org
>  Cc: vince.rog...@gmail.com
>  Subject: [gdal-dev] Oracle support available by default in any OSGeo software
>  Sent: Jul 23 '12 05:20
>  
>  Hi ,
>  I't very frustrating, each time I would like to use OSGeo software
>  (GDAL/OGR, QGIS, …) they don't support oracle database. Every time,
>  everything should be recompiled from source with oracle support enabled. A
>  long and not easy process…
>  
>  The reason usually evoked for this situation, is that Oracle build
>  needs Oracle files that aren't freely redistributable. Ok It's a good
>  reason.
>  
>  I found a library, called OCILIB (<[LINK:
>  http://orclib.sourceforge.net/] http://orclib.sourceforge.net/>), that
>  enable your software to dynamically connect to your oracle database. This
>  library does not require any oracle library to compile. It's available on
>  any platform where oracle client is available and it licensed with LGPL.
>  
>  So it seems possible to create an OGR driver for Oracle, based on
>  OCILIB, that doesn't require any Oracle copyrighted files.
>  
>  So what I propose is to develop, with the help of any volunteer,
>  this kind of driver.
>  
>  But before going further, I would like to know if it seems to you a
>  good way to have Oracle support available by default in any OSGeo software
>   
>  
>  
>  Depending of your answers, I 'll come back to ask you how it's the
>  best way to do that ?
>  
>  Thanks a lot
>  
>  Nicolas Simon
>  
>  ___
>  gdal-dev mailing list
>  [LINK: compose.php?to=gdal-dev@lists.osgeo.org] gdal-dev@lists.osgeo.org
>  [LINK: http://lists.osgeo.org/mailman/listinfo/gdal-dev]
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] geotransform rotation and gdal_merge

[Chaitanya kumar CH]

Dave,

The reason you have lat/lon values for each pixel is because they may not
be aligned exactly.
Even though it is not very 'efficient', you have to define the GCPs for
each pixel with the lat/lon values of that pixel. Then you use gdalwarp
while forcing use of these GCPs to combine all the images.

How are the lat/lon values stored?

On Sun, Jul 22, 2012 at 7:44 PM, David Hoese  wrote:

>  Sure, pixels were probably not the best word to use. I have 15
> points(elements) per scan line per "variable" directly from an aircraft
> instrument.  So I might have a 15 element array of brightness temperatures,
> a 15 element array of latitudes corresponding to those points in the BT
> array, and another 15 element array of longitudes corresponding to those
> points in the BT array.  So the first element in the brightness
> temperature(BT[0]) array represents an area of the earth located at
> lon[0],lat[0] (I'm actually not sure if its the center of the area or the
> corner, but at the moment that doesn't matter).
>
> Does that make sense?
>
> -Dave
>
>
> On 7/21/12 9:46 AM, Chaitanya kumar CH wrote:
>
> Dave,
>
> You said that you have lat/lon values for each pixel. Can you explain?
>
> On Fri, Jul 20, 2012 at 8:44 PM, David Hoese  wrote:
>
>>  I'm attempting to put aircraft scan data into geotiffs (1-3 scanlines
>> each) and then use gdal_merge.py to combine them into one large geotiff
>> that has the entire aircraft's path.  The scan lines are 15 pixels wide and
>> taken every 10 seconds, the geotiffs are wgs84 lat/lon, and I have lat/lon
>> values for each pixel.  To handle the case when the aircraft isn't flying
>> straight north I think I have to use the 2 rotation parameters in the
>> affine geotransform, is that right?  I don't have any test cases, but I
>> think if I don't use rotation anything that reads the geotiff will think
>> that the image is square(aligned) in lat/lon space.
>>
>> Whether or not I need to use this, can someone explain to me how to use
>> the rotation coefficients?  What are the actual values of the coefficients
>> supposed to be?  I couldn't find a good example and I couldn't get any
>> basic situations to make sense, like a 2x3 array turned 45 degrees.  I used
>> these equations:
>>
>> Xgeo = GT(0) + Xpixel*GT(1) + Yline*GT(2)
>> Ygeo = GT(3) + Xpixel*GT(4) + Yline*GT(5)
>>
>>
>> And lastly, does gdal_merge.py handle rotation?  I checked the source and
>> it doesn't ever seem to use elements 2 and 4 in its calculations.
>>
>> Thanks for any help.
>>
>> -Dave
>>
>> ___
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
> --
> Best regards,
> Chaitanya kumar CH.
>
> +91-9494447584
> 17.2416N 80.1426E
>
>
>


-- 
Best regards,
Chaitanya kumar CH.

+91-9494447584
17.2416N 80.1426E
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OSM Driver and World Planet file (pbf format)

[Even Rouault]

Le lundi 23 juillet 2012 12:56:12, Smith, Michael ERDC-RDE-CRREL-NH a écrit :
> I'm finding that the new OSM Driver (I tested again with r24699) has a
> problem when working with the whole planet file. When I tried with the US
> Northeast subset, I got multipolygons and multilinestring entries. When
> reading the whole planet file, I did not. It gets to 70% and then ends
> (but without an error message). I also got fewer polygons than I was
> expecting. It seems like the reading got interrupted by some non reported
> error.
> 
> I was writing to Oracle for this importing but got the same results writing
> to sqlite. It seems that smaller extracts work fine but the are some
> reading issues with the whole planet file (in pbf format). I can try with
> the .osm format.

I didn't try yet with whole planet files. Takes too much time :-)

Which command line did you use exactly ?

Did it stop cleanly or with a segfault ? In the latter case, (assuming you are 
on Linux), running under gdb might be useful.

What is your OS, 32/64 bit ? Perhaps, you could add --debug on. I'd suggest 
redirecting standard error file to a file because the log file can be huge.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] OSM Driver and World Planet file (pbf format)

[Smith, Michael ERDC-RDE-CRREL-NH]

I'm finding that the new OSM Driver (I tested again with r24699) has a problem 
when working with the whole planet file. When I tried with the US Northeast 
subset, I got multipolygons and multilinestring entries. When reading the whole 
planet file, I did not. It gets to 70% and then ends (but without an error 
message). I also got fewer polygons than I was expecting. It seems like the 
reading got interrupted by some non reported error.

I was writing to Oracle for this importing but got the same results writing to 
sqlite. It seems that smaller extracts work fine but the are some reading 
issues with the whole planet file (in pbf format). I can try with the .osm 
format.




___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to identify a point is belong to a polygon ?

[Mateusz Loskot]

On 23 July 2012 11:52, taibc  wrote:
> I installed GEOS succesfful, and copy file geos.dll into my project. But I
> still got the error: "GEOS support not enable" when using the method
> "Within"
>
> Are there something wrongs ?

You need to edit nmake.opt and rebuild GDAL.
Check this thread:
http://lists.osgeo.org/pipermail/gdal-dev/2010-March/023829.html

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How to identify a point is belong to a polygon ?

[taibc]

chaitanya_ch wrote
> 
> Tai,
> 
> GDAL needs GEOS to perform these geometry functions. Make sure you install
> that.
> 
> On Sat, Jul 21, 2012 at 12:19 PM, taibc  wrote:
> 
> 

Hi Chaitanya,

I installed GEOS succesfful, and copy file geos.dll into my project. But I
still got the error: "GEOS support not enable" when using the method
"Within"

Are there something wrongs ?

Thanks and regards,

Tai



--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/How-to-identify-a-point-is-belong-to-a-polygon-tp4989501p4990028.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

[gdal-dev] Oracle support available by default in any OSGeo software

[Nicolas Simon]

Hi , 
I't very frustrating, each time I would like to use OSGeo software 
(GDAL/OGR, QGIS, ...) they don't support oracle database. Every time, 
everything should be recompiled from source with oracle support enabled. A long 
and not easy process... 

The reason usually evoked for this situation, is that Oracle build 
needs Oracle files that aren't freely redistributable. Ok It's a good reason.

I found a library, called OCILIB (), 
that enable your software to dynamically connect to your oracle database. This 
library does not require any oracle library to compile. It's available on any 
platform where oracle client is available and it licensed with LGPL.

So it seems possible to create an OGR driver for Oracle, based on 
OCILIB, that doesn't require any Oracle copyrighted files.

So what I propose is to develop, with the help of any volunteer, this 
kind of driver.
 
But before going further, I would like to know if it seems to you a 
good way to have Oracle support available by default in any OSGeo software ?
   
Depending of your answers, I 'll come back to ask you how it's the best 
way to do that ? 

Thanks a lot

Nicolas Simon



___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver to read OpenStreetMap .osm / .pbf files

[Even Rouault]

Le lundi 23 juillet 2012 00:09:05, Jukka Rahkonen a écrit :
> Even Rouault  mines-paris.org> writes:
> > > > However, select with SQL feels sub-optimal.
> > > 
> > > Yes, when you use ogr2ogr with explicit layer names, there are
> > > optimizations. For example, when you only specify the layer 'points',
> > > the OSM driver will not even try to index the nodes into the temporary
> > > database because it is not needed. However, as you noticed, there is
> > > not yet any optimization when a SQL request is specified.
> > 
> > Optimization for SQL request added in r24690
> 
> I had a try with r24696 today, downloaded from
> http://gisinternals.com/sdk/Download.aspx?file=release-1500-gdal-mapserver.
> zip
> 
> Filtered commands give me errors. An example:
> ogr2ogr -f "ESRI Shapefile" test germany.osm.pbf multipolygons -gt 2
> -progress --config OGR_SQLITE_SYNCHRONOUS OFF -where "natural='forest'"
> 
> ERROR 1: Failed inserting node 420797898: database schema has changed

I could also reproduce and I suppose there was at the begnning of the sequence 
of errors : "ERROR 1: Failed inserting node : I/O error"

It turned out that the mechanism to transfer the temporary in-memory DB file to 
disk when it is too big had been broken by a previous commit, so it stayed on 
RAM and at some point, it couldn't fit in RAM, hence the error. Should be fixed 
now with r24699.

I'm experimenting with removing the internal use of SQLite for the temporary 
database and replacing it with something custom. Actually, it won't replace it 
completely in all cases, but it could definitely be used in well-behaved cases 
where the elements in the .osm/.pbf are listed in increasing id order, which 
is the case of the data in geofabrik files for example. The first results seem 
to show increased performance.

Note: in your above example, you don't need to specify -gt and --config 
OGR_SQLITE_SYNCHRONOUS OFF when the output format is not sqlite/spatialite. 
And the internal use of SQLite in the OSM driver already sets the 
corresponding parameters to the values that give the best performance.


> 
> Same error with Spatialite output.
> 
> -Jukka Rahkonen-
> 
> 
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Ogr: Difference betwen SQLexectue() and SetAttributFilter() ?

[Even Rouault]

Le lundi 23 juillet 2012 11:19:48, Benjamin a écrit :
> Hi,
> 
> There is a difference betwen :
> 
> layer = ds.ExecuteSQL("SELECT * FROM MY_TABLE WHERE ID='my_id'", null, "");
> 
> And
> 
> layer = ds.GetLayerByName("MY_TABLE");
> layer.SetAttributeFilter("ID='my_id'");
> 
> ?

Short answer:

Generally, there should not be a visible difference between both syntax. There 
might be very subtle performance differences due to internal implementation 
details, but I doubt you could notice them. So use the one that is the most 
convenient for you.


Long answer :

For drivers that are not based on relational database manager, such as 
Shapefile, in both cases, the filter will be evaluated on "client-side" (there 
is no server side ;-))

For drivers such as PG, MySQL, SQLite, etc, the ExecuteSQL() is directly 
transfered to the database engine. But the SetAttributeFilter() is also used 
to synthetize a "SELECT * FROM the_table WHERE the_attribute_filter" 
internally, that is transfered to the database engine, so the performance will 
also be good.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset

[Even Rouault]

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

ogrinfo IMAGESET:my_directory_with_images

The first syntax is convenient, but in the case the user isn't specifically 
interested in this driver, it could create performance problems if it 
GDALOpen() each file in the specified directory. There also could be a 
"competition" problem with, let's say, the shapefile or MITAB driver that also 
accept directory names : if the directory contains JPEG images, and also a 
shapefile or a .mif/.tab file, the new driver will not be used.

> 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.

Seems reasonable

> I could imagine a driver configuration file to specify which driver should
> be used for a particular image format

GDALOpen() should do it for you automatically. Unless you intend to have a 
list of known extensions, ".jpg", ".jpeg", ".tif", ".tiff" to avoid useless 
GDALOpen() attempts.

> and where the specific information is
> located, I don't require to harmonize the metadata structure at this time.

That could be an opportunity to do so. But you could just try exploring the 
contents of GetMetadata(NULL) and GetMetadata("EXIF") without caring which 
driver exposes the stuff in which domain. The code for both driver is the same 
and is located in gcore/gdalexif.cpp
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset

[Tamas Szekeres]

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 

> 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

[gdal-dev] Ogr: Difference betwen SQLexectue() and SetAttributFilter() ?

[Benjamin]

Hi,

There is a difference betwen :

layer = ds.ExecuteSQL("SELECT * FROM MY_TABLE WHERE ID='my_id'", null, "");

And 

layer = ds.GetLayerByName("MY_TABLE");
layer.SetAttributeFilter("ID='my_id'");

?

When you fetch your feature with layer.getNextFeature(), there are numerous
request with the 2nd way ?

Links :
http://www.gdal.org/ogr/classOGRDataSource.html#aa6acc228db6513784a56ce12334a8c33
http://www.gdal.org/ogr/classOGRLayer.html#acb2c6cc5fa3577df5be538284c1b0dde

Best regards,
Benjamin.




--
View this message in context: 
http://osgeo-org.1560.n6.nabble.com/gdal-dev-Ogr-Difference-betwen-SQLexectue-and-SetAttributFilter-tp4990004.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

Re: [gdal-dev] New OGR driver: Imageset

[Tamas Szekeres]

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 also possible to render the symbols as the image
thumbnails by using the image file path attribute in the mapping
applications.

Best regards,

Tamas



2012/7/23 Andreas Neumann 

> 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 the
> viewpoint coordinates, the image direction, the FOV or focal length, the
> sensor size, etc. - this information could be used to create a field of
> view angle of the picture.
>
> You can try this at 
> http://www.geofoto.ch/**geophotomap/index.svgwhere
>  you can click on a picture standpoint and the browser will display an
> angle where the picture is looking at.
>
> I'd be interested in such a provider, as it would open a lot of
> possibilities to display photo information in various applications.
>
> Are you aware of EXIFTOOL - the perl-script that allows getting and
> setting image metadata, such as EXIF, IPTC, XMP, etc.? See
> http://www.sno.phy.queensu.ca/**~phil/exiftool/-
>  it is sort of the Swiss Army Knife of photo metadata and one of the fewer
> apps that can also set metadata - not just read.
>
> Andreas
>
>
> On Mon, 23 Jul 2012 09:51:14 +0200, Tamas Szekeres wrote:
>
>> 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.
>>
>> Best regards,
>>
>> Tamas
>>
>
> --
> --
> 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
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New OGR driver: Imageset

[Even Rouault]

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

Re: [gdal-dev] New OGR driver: Imageset

[Andreas Neumann]

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 the 
viewpoint coordinates, the image direction, the FOV or focal length, the 
sensor size, etc. - this information could be used to create a field of 
view angle of the picture.


You can try this at http://www.geofoto.ch/geophotomap/index.svg where 
you can click on a picture standpoint and the browser will display an 
angle where the picture is looking at.


I'd be interested in such a provider, as it would open a lot of 
possibilities to display photo information in various applications.


Are you aware of EXIFTOOL - the perl-script that allows getting and 
setting image metadata, such as EXIF, IPTC, XMP, etc.? See 
http://www.sno.phy.queensu.ca/~phil/exiftool/ - it is sort of the Swiss 
Army Knife of photo metadata and one of the fewer apps that can also set 
metadata - not just read.


Andreas

On Mon, 23 Jul 2012 09:51:14 +0200, Tamas Szekeres wrote:

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. 

Best regards,

Tamas


--
--
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

[gdal-dev] New OGR driver: Imageset

[Tamas Szekeres]

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.

Best regards,

Tamas
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev