[gdal-dev] GeoTiff null values

Hi List, I'm running tests with GDAL 1.7 and python for achieving a function for the sum of GeoTIFF file. I found some difficulty in handling null values. I wanted to know if you can assign a specific value (like 99) to null when I call the Open function. The code is as follows: # Open t

Re: [gdal-dev] the format of satellite picture

Sure. On GDAL website there is a link to supported format [1], from there you are going to find several raster formats. Some of those formats are used by satellite data provider to deliver remote sense images, some are software specific formats, some are DBMS type extensions, some are desktop an

[gdal-dev] the format of satellite picture

I know that one of the the formats of satellite picture is geotiff(its extention is .tif ,and GDAL can read coordination from it ),could you tell me other formats? GDAL can read info from it?___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://list

Re: [gdal-dev] Compiled gdal.lib v1.7.2 ==> doubled file size

Yes it's possible. And if you compile the same for x64 it results even larger files. But why is this important? Best regards, Tamas 2010/7/30 Paul Meems > I've just compiled v1.7.2 of GDAL with VS2010, using an almost identical > makefile as before with v1.7.1 (compiled with VS2008). > > The

[gdal-dev] Compiled gdal.lib v1.7.2 ==> doubled file size

I've just compiled v1.7.2 of GDAL with VS2010, using an almost identical makefile as before with v1.7.1 (compiled with VS2008). The file size of the v1.7.1 lib file is 78MB and the lib file of v1.7.2 is 138MB. That is almost twice the file size? Is that normal or did I miss a setting? Thanks, P

[gdal-dev] [off-topic] public beta for GIS Stack Exchange

Hello Folks, The vendor neutral GIS Q&A site based on the Stack Exchange platform I wrote about last month is now open for public beta: *http://gis.stackexchange.com/*

Re: [gdal-dev] Memory leak from GDALRasterIO

Kevin F Webb wrote: Good day! I am experiencing a memory leak from looped calls to GDALRasterIO(). It may be something I am doing improperly because I use/call RasterIO() in a C++ program that runs leak free. I "migrated" the C++ code to the GDAL C API so that I can integrate some real

[gdal-dev] Memory leak from GDALRasterIO

Good day! I am experiencing a memory leak from looped calls to GDALRasterIO(). It may be something I am doing improperly because I use/call RasterIO() in a C++ program that runs leak free. I "migrated" the C++ code to the GDAL C API so that I can integrate some really old C code downstream

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

> > One that occurs to me is the KML driver, where styles may exist seperately > from the features; parsing the style KML (and applying all the cascading > stylesheets, etc.) could be expensive, and excluding it could save > some processing time in theory. > > In practice, I don't know whether this

[gdal-dev] Re: Trouble with gdal2tiles.py

Greg Coats mac.com> writes: > > > First, instead of using GDAL 1.6.0 from December 2008, why not use GDAL 1.7.2 from April 2010? > Second, since your objective is to create a tiled GeoTIFF, you can do that with one gdal_translate command. > > $ gdal_translate --version > GDAL 1.7.2, released 2

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

Frank, If you refer to the OGR_GEOMETRY, OGR_GEOM_WKT, OGR_GEOM_AREA special fields, both return a meaningful value (ie. an empty string) when the geometry is null. In this regard it would be enough to disable only the geometry column of that layer. However since the geometry column is not necessa

Re: [gdal-dev] Trouble with gdal2tiles.py

First, instead of using GDAL 1.6.0 from December 2008, why not use GDAL 1.7.2 from April 2010? Second, since your objective is to create a tiled GeoTIFF, you can do that with one gdal_translate command. $ gdal_translate --version GDAL 1.7.2, released 2010/04/23 $ gdal_translate -of GTiff -ot Byte

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

On Jul 29, 2010, at 1:07 PM, ext Frank Warmerdam wrote: > Tamas Szekeres wrote: >> Martin, >> >> I didn't follow all conclusions made earlier in this thread, but I don't >> think it makes much sense to enable/disable the special fields since >> those are derived from the attributes of the feat

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

Tamas Szekeres wrote: Martin, I didn't follow all conclusions made earlier in this thread, but I don't think it makes much sense to enable/disable the special fields since those are derived from the attributes of the feature instead of fetching the values physically from the data source. For

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

Martin, I didn't follow all conclusions made earlier in this thread, but I don't think it makes much sense to enable/disable the special fields since those are derived from the attributes of the feature instead of fetching the values physically from the data source. For example OGR_STYLE correspon

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

Martin Dobias wrote: Another reason for going with SelectFields instead of SetIgnoredFields might be that in case a new special field OGR_FOO will be introduced in future version, it will be ignored implicitly when using SelectFields, while with SetIgnoredFields the client will have to explicitly

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

On Thu, Jul 29, 2010 at 3:15 PM, Daniel Morissette wrote: > Martin Dobias wrote: >> >> I've updated the RFC to reflect your suggestions: >> >> http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields >> >> Given that there has been no further discussion, can we mark the RFC >> as proposed and start th

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

Martin Dobias wrote: > > I've updated the RFC to reflect your suggestions: > > http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields > > Given that there has been no further discussion, can we mark the RFC > as proposed and start the voting? > Sorry if this comment comes late, but I didn't real

Re: [gdal-dev] RFC 29: OGR Set Desired Fields

On Wed, Jul 21, 2010 at 6:59 PM, Martin Dobias wrote: > > So, in case there will be no further comments, I'll update the RFC to > match the API you've proposed. Hi Frank, I've updated the RFC to reflect your suggestions: http://trac.osgeo.org/gdal/wiki/rfc29_desired_fields Given that there has