Re: [gdal-dev] Delete a sqlite database

Hello Even Yes you are right, it works perfectly Thanks a lot Ludovic Le 28/11/2010 17:23, Even Rouault a écrit : Le lundi 22 novembre 2010 10:26:26, Ludovic Granjon a écrit : Hi all I try in a python script to delete a sqlite database that I use in an OGR ExecuteSQL. Let me give you an exampl

Re: [gdal-dev] Error building GDAL with GEOS on Solaris

Hi, I modified few options in configuration script to resolve if any dependencies, it is as below: ./configure --prefix=/usr/local \ --with-threads \ --with-ogr \ --with-geos=yes \ --without-libtool \ --with-libz=internal \

[gdal-dev] Making non-rectangular image edges transparent

Hi, I am looking for a commandline recipe with gdal_translate/gdalwarp to create transparent areas as edges of (historic) rastermaps. The situation is as follows: - (800) source PNG images, samples: http://kademo.nl/public/histmap - each image is georeferenced (4 corners of visible area) - vi

[gdal-dev] geotiff conflict

Hello, I'm reviving an already known problem about the gdal packages for Ubuntu/Debian, related to the use of the hide-internal-symbols configure option. To sum it up, we get into troubles with the gdal packages since we also use the geotiff API. Until recently, we knew only about a proble

Re: [gdal-dev] RFC 31 - OGR 64bit Support

Guys, Just fyi, a long on my machine (Linux 2.6.35.6-48.fc14.x86_64) is 8 bytes. It's the same as long long. Dave On 11/28/2010 02:39 PM, Even Rouault wrote: Frank, If I agree we can upgrade the C++ API of OGRLayer::GetFeature() and DeleteFeature() to use GIntBig instead of long, I'm wond

Re: [gdal-dev] geotiff conflict

Julien, To be fair, I think that --with-hide-internal-symbols just does what it advertizes : it hides GDAL internal symbols (internal libtiff, internal libgeotiff) to applications that link with libgdal. I mean that they cannot use those symbols (if they only link to libgdal). The advantage is tha

Re: [gdal-dev] RFC 31 - OGR 64bit Support

David, yes, on most 64bit platforms, sizeof(long long)=sizeof(long)=8. Except on Win64, where sizeof(long) still = 4 ( see http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models ). And of course on 32bit platforms, sizeof(long)=4. So the need for an explicit 64bit API is needed. > Gu

Re: [gdal-dev] RFC 31 - OGR 64bit Support

On 29/11/10 14:57, Even Rouault wrote: David, yes, on most 64bit platforms, sizeof(long long)=sizeof(long)=8. Except on Win64, where sizeof(long) still = 4 ( see http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models ). And of course on 32bit platforms, sizeof(long)=4. So the need f

[gdal-dev] GML to .shp Using OGR

Hi all, Hopefully this is also the forum to post OGR-related enquiries. I don't see a specific OGR list. I have a very large .gml file with multiple layers in it. I would like to export one of these layers to .shp. It is a polygon layer (of lakes). However, I am getting the error: ERROR 1: U

Re: [gdal-dev] RFC 31 - OGR 64bit Support

On 11/29/2010 10:09 AM, Mateusz Loskot wrote: On 29/11/10 14:57, Even Rouault wrote: David, yes, on most 64bit platforms, sizeof(long long)=sizeof(long)=8. Except on Win64, where sizeof(long) still = 4 ( see http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models ). And of course

Re: [gdal-dev] GML to .shp Using OGR

The Surface tag is not supported before GDAL/OGR v1.8 I had a similar GML a few weeks back. Using the beta release of GDAL/OGR v1.8 you can convert. -- Paul *Paul Meems * Release manager, configuration manager and forum moderator of MapWindow GIS. www.mapwindow.org Owner of MapWindow.nl - Supp

Re: [gdal-dev] geotiff conflict

Even, I am working with Julien on the same project, and you are right about the --hide-internal-symbols option : if symbols are not hidden, we recognize that gdal exposes tiff symbols and we manage to deal with this case by forcing all tiff access to use gdal internal tiff library (we have to

Re: [gdal-dev] geotiff conflict

Hello Even, Thank you for your answer. Le 29/11/2010 15:51, Even Rouault a écrit : Julien, To be fair, I think that --with-hide-internal-symbols just does what it advertizes : it hides GDAL internal symbols (internal libtiff, internal libgeotiff) to applications that link with libgdal. I mean

[gdal-dev] Having a GDAL version OSGEO4w that supports GRIBs

Greetings Ihave been running GDAL (with GRASS) on Ubuntu and Gdal's version support GRASS (without any problem). Now, I'm trying to run the same scripts in OSGEo4w and I realized that GDAL does not support GRIB. How can I change this (if possible)? Thanks Antonio _

Re: [gdal-dev] Having a GDAL version OSGEO4w that supports GRIBs

Hi Antonio, On Mon, 29. Nov 2010 at 21:58:04 +0100, antonio.ro...@deimos.com.pt wrote: > Ihave been running GDAL (with GRASS) on Ubuntu and Gdal's version > support GRASS (without any problem). Now, I'm trying to run the same > scripts in OSGEo4w and I realized that GDAL does not support GRIB.