Re: [gdal-dev] HFA (.img) driver prints Warning 1: NaN converted to INT_MAX when float raster has nan as the NoData value

re metadata fields that the HFA driver opens. That must come from that. Always shutting down the warning could be inappropriate, but perhaps in the context where the warning is emitted the driver could avoid emitting it. But we need to have access to the file to better understand the call p

Re: [gdal-dev] HFA (.img) driver prints Warning 1: NaN converted to INT_MAX when float raster has nan as the NoData value

1: NaN converted to INT_MAX. Jason On 5/8/25 18:39, Even Rouault wrote: There are metadata fields that the HFA driver opens. That must come from that. Always shutting down the warning could be inappropriate, but perhaps in the context where the warning is emitted the driver could avoid emitting

Re: [gdal-dev] HFA (.img) driver prints Warning 1: NaN converted to INT_MAX when float raster has nan as the NoData value

/2025 à 23:01, Jason Roberts via gdal-dev a écrit : Hi GDAL team, I'm working with the GDAL Python API. I have some HFA (.img) files that are float32 and that use nan as their NoData value. As far as I can tell, using nan is allowed but I could be wrong. When I open them, I get "

[gdal-dev] HFA (.img) driver prints Warning 1: NaN converted to INT_MAX when float raster has nan as the NoData value

Hi GDAL team, I'm working with the GDAL Python API. I have some HFA (.img) files that are float32 and that use nan as their NoData value. As far as I can tell, using nan is allowed but I could be wrong. When I open them, I get "Warning 1: NaN converted to INT_MAX." Everything seems to work fin

Re: [gdal-dev] Python Wheels for gdal

As a 15-year user of GDAL's Python bindings and a long time lurker on this list, I just wanted to thank all of you who are contemplating the Python packaging problem (and thank you for GDAL in general). I maintain a small package of Python-based utilities used by marine ecologists, mainly in an

Re: [gdal-dev] "RFC 75: Multidimensional arrays" available for preliminary review

Dear Even, Thank you for exploring the possibility of making GDAL more multidimensional. In the 10+ years I've lurked on this list I recall this coming up periodically. It's a hard problem; perhaps now will be the time to actually do it! Over that period, I have worked with a lot of 3D (x,y,z a

Re: [gdal-dev] How to add GDAL as a dependency to a Python package?

Luís, gdal-dev is the correct list. By “they”, I mean the maintainers of GDAL’s Python bindings; AFAIK they all follow gdal-dev. Best, Jason From: Luí­s de Sousa [mailto:luis.de.so...@protonmail.ch] Sent: Tuesday, April 12, 2016 9:30 AM To: Jason Roberts ; gdal-dev@lists.osgeo.org Subject: RE

RE: [gdal-dev] RFC 39

-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ari Jolma Sent: Thursday, May 03, 2012 2:35 AM To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] RFC 39 On 05/02/2012 09:56 PM, Jason Roberts wrote: > Hi Ari, > > I have been following this proposal with interest. I ha

RE: [gdal-dev] RFC 39

Hi Ari, I have been following this proposal with interest. I have a couple of questions; sorry to bring them up late in the RFC process. It looks like the inspiration for this was the Overlay toolset in the ArcGIS geoprocessing toolbox. That is nice for people like me who regularly work with ArcG

RE: [gdal-dev] Layer operations, a proposal

g] Sent: Thursday, April 19, 2012 4:03 AM To: Tyler Mitchell Cc: Jason Roberts; gdal-dev@lists.osgeo.org Subject: RE: [gdal-dev] Layer operations, a proposal Selon Tyler Mitchell : > > > Jason Roberts wrote: > ... > > For scenarios involving large numbers of features, I suspect

RE: [gdal-dev] Layer operations, a proposal

rations, a proposal On 04/18/2012 03:07 AM, Jason Roberts wrote: > As I have mentioned previously > (http://lists.osgeo.org/pipermail/gdal-dev/2010-January/023089.html) Thanks for pointing this out. > I think > something like this would be a great addition to OGR. No doubt it

RE: [gdal-dev] Layer operations, a proposal

As I have mentioned previously (http://lists.osgeo.org/pipermail/gdal-dev/2010-January/023089.html) I think something like this would be a great addition to OGR. No doubt it would be a huge job--basically turning OGR into a GIS--but if it could be done well, with sufficient performance and in the c

RE: [gdal-dev] FGDB Opening Sample File

FWIW, the error code -2147467259 is probably a Microsoft HRESULT. In hex, it is 0x80004005, which is a generic "access is denied" error. Not that this is much of a clue about what is going on. You could check for some kind of permissions or access problem... Jason -Original Message- From:

RE: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows

o: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows On 1/25/11 2:57 PM, Jason Roberts wrote: > Rather than introduce a DLL into the system directory, why not > statically link the code into the bindings themselves, when possibl

RE: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows

Roberts Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows 2011/1/25 Jason Roberts Tamas, Are you still planning to implement the registry-based approach? I ask because you seemed in favor of avoiding modifying PATH, if at all

RE: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows

, jason From: Tamas Szekeres [mailto:szeker...@gmail.com] Sent: Tuesday, January 25, 2011 3:03 PM To: Jason Roberts Cc: Alain Cembro; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows 2011/1/25 Jason Roberts Tamas, Could

RE: [gdal-dev] Problem with GDAL Python bindings and ECW format under Windows

Alain I think the solution that Tamas proposed for that problem is not to automatically set the environment variables, but instead to modify the GDAL core installer to store the installation location in the registry and then have the Python bindings read it and initialize GDAL by calling appropria

RE: [gdal-dev] GDAL windows installers available

BTW, when we get to the Python bindings installer, this is another reason to build the Python bindings installer as a .msi rather than a .exe. That is possible with Python 2.5 and later. I didn't find this option working with my Python installation (2.5 and 2.6), is that something which have been

RE: [gdal-dev] GDAL windows installers available

Tamas, Nice job getting something out so quickly. You remind me of this Dilbert cartoon from back in the day. Due to various deadlines I won't be able to look at this until Wedne

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

Frank, Thanks for the clarification of the various issues. I will start an RFC for this next week. Jason -Original Message- From: Frank Warmerdam [mailto:warmer...@pobox.com] Sent: Friday, January 07, 2011 10:29 AM To: Jason Roberts Cc: gdal-dev@lists.osgeo.org Subject: Re: Fwd: Re

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

read the registry to determine their location. This is also a fairly standard way to do things on Windows, but it would be slightly more complicated for the bindings. Jason From: Joaquim Luis [mailto:jl...@ualg.pt] Sent: Friday, January 07, 2011 10:27 AM To: Jason Roberts Cc: 'Tama

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

ables if calling the Win32 API is not easy for particular bindings. Jason From: Tamas Szekeres [mailto:szeker...@gmail.com] Sent: Friday, January 07, 2011 5:26 AM To: Jason Roberts Cc: Frank Warmerdam; gdal-dev@lists.osgeo.org Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0 20

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

Frank, > I would suggest building it as an installer .exe, perhaps using NSIS as > I did for FWTools, or perhaps the method mentioned by Jurgen produces > a nice installer. If possible, I would suggest the final output be a .msi (Windows Installer package) rather than a .exe. In an effort to make

RE: [gdal-dev] FWTools and GDAL 1.7.0

> Windows 7 might actually be different - perhaps they now even now use symlinks > to point a localized path to a hidden "Program Files". Good point. In Vista, Microsoft introduced a "virtualization" feature that silently redirects write attempts to Program Files. This is part of the very complica

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

1.Modify the makefiles for your SDK so that it runs release--dev\gdal\swig\python\setup.py with the "bdist --formats=wininst" option. This will produce an installation program such as gdal-1.7.3.win32-py2.5.exe. This is what the user will run to install the Python bindings together with

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

we could instruct the user to download an official GDAL build and install it, and then just use it from there. What do you think? Jason -Original Message- From: Frank Warmerdam [mailto:warmer...@pobox.com] Sent: Thursday, January 06, 2011 5:49 PM To: Jason Roberts Cc: gdal-dev@lists.

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

42 PM, Christopher Barker wrote: > On 1/6/11 12:31 PM, Jason Roberts wrote: >> Here are some comments on specific parts of your mail: >>> Program Files\GDAL\1.6\gdal.dll >>> and >>> Program Files\GDAL\1.6\gdal.dll > >> Those would be reasonable locatio

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

Chris, Here are some comments on specific parts of your mail: > me neither, with Python (or anything Windows, for that matter). Maybe > Jason knows better, but I *think* we should be OK with a standard > location for GDAL. But could you have: > > Program Files\GDAL\1.6\gdal.dll > and > Progra

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

Does that sound like the right direction? Jason From: Tamas Szekeres [mailto:szeker...@gmail.com] Sent: Thursday, January 06, 2011 11:07 AM To: Jason Roberts Cc: gdal-dev@lists.osgeo.org Subject: Re: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0 2011/1/6 Jason Roberts 2.Build an insta

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

ean, standardized way to do that. There are some innovations related to the "easy_install" thing I mentioned earlier, but nothing has become standard in Python itself, at least with the 2.x releases. Jason From: Tamas Szekeres [mailto:szeker...@gmail.com] Sent: Thursday, January 06

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

te-packages\gdal) and set PATH, PROJ_LIB, GDAL_DRIVER_PATH, and GDAL_DATA to the correct things. I could potentially help you develop that. It looks like most of what is needed is already there. Jason From: Tamas Szekeres [mailto:szeker...@gmail.com] Sent: Wednesday, January 05, 2011 6:12

RE: Fwd: Re: [gdal-dev] FWTools and GDAL 1.7.0

Specifically regarding Python programmers who primarily or exclusively use Windows: The majority of popular Python packages are delivered to Windows users by one of two mechanisms: 1.A stand-alone installation program (either a .exe or .msi file) that the user just downloads and runs, o

RE: [gdal-dev] Can't make Python binding work

Martin, http://vbkto.dyndns.org/sdk/ is a popular location for GDAL binaries and bindings for Windows. For Python 2.6 on 32-bit Windows, I would recommend downloading "MSVC2008 (Win32) -stable" from the first table on the page (i.e. http://vbkto.dyndns.org/sdk/release-1500-gdal-1-7-mapserver-5-6.z

RE: [gdal-dev] Creating aux.xml files for GTiff using Python

Matt, Since nobody else more knowledgeable replied and I was in the original discussion, I'll take a shot. To review: for some situations and formats, the following code would work: statistics = band.GetStatistics(False, True) # Force calculation of statistics band.SetStatistics(*statistics)

RE: [gdal-dev] Delete a sqlite database

Hi Ludovic and Frank, As I understand from discussions with Evan Rouault, Destroy() is an obsolete method in the Python bindings that should not be used. See http://trac.osgeo.org/gdal/wiki/PythonGotchas#CertainobjectscontainaDestroym ethodbutyoushouldneveruseit. If that understanding is not corr

RE: [gdal-dev] Issue with python bindings.

Ivan, Frank, A month ago I started a gotchas page with Even Rouault that discusses this issue: http://trac.osgeo.org/gdal/wiki/PythonGotchas. If you have a moment, please consider adding your examples as other cases that cause the lifetime problem. Also (Frank) if there is any general advice yo

RE: [gdal-dev] gdal_merge: stacking and band statistics

ategorical scheme, I would greatly appreciate that knowledge! Best, Jason -Original Message- From: Peter J Halls [mailto:p.ha...@york.ac.uk] Sent: Thursday, October 21, 2010 2:12 AM To: Jason Roberts Cc: 'Matt Hanneman'; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] gdal_merge: stac

RE: [gdal-dev] gdal_merge: stacking and band statistics

Matt, Although I have not worked with multi-band HFA format, I have experimented fairly extensively with single-band, GDAL-produced, HFA-format files in ArcGIS 9.3.1 SP1. Maybe my experience will be interesting to you anyway. My experience was that calculating the statistics with GDAL and w

RE: [gdal-dev] With Python bindings, should geometry objects created by ogr.Geometry() be explicitly destroyed?

: Jason Roberts Cc: Even Rouault; gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] With Python bindings, should geometry objects created by ogr.Geometry() be explicitly destroyed? On Mon, Sep 20, 2010 at 6:29 PM, Jason Roberts wrote: > Even, > > Thank you very much for your comments. Based o

RE: [gdal-dev] With Python bindings, should geometry objects created by ogr.Geometry() be explicitly destroyed?

.0 they would have worked fine with 1.4.1. If you know the details and care to update the page, please go for it... Thanks again, Jason -Original Message- From: Christopher Barker [mailto:chris.bar...@noaa.gov] Sent: Monday, September 20, 2010 2:32 PM To: Even Rouault Cc

RE: [gdal-dev] With Python bindings, should geometry objects created by ogr.Geometry() be explicitly destroyed?

ds, Jason -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Saturday, September 18, 2010 5:52 AM To: gdal-dev@lists.osgeo.org Cc: Jason Roberts Subject: Re: [gdal-dev] With Python bindings, should geometry objects created by ogr.Geometry() be explicitly

RE: [gdal-dev] With Python bindings, should geometry objects created by ogr.Geometry() be explicitly destroyed?

occurring on subsequent GDAL API calls.) Now back to the "to destroy or not to destroy" question. From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Jason Roberts Sent: Friday, September 17, 2010 3:03 PM To: gdal-dev@lists.osgeo.org Subject:

[gdal-dev] With Python bindings, should geometry objects created by ogr.Geometry() be explicitly destroyed?

I have some Python code that uses OGR geometry objects internally, creating them like this: point = ogr.Geometry(ogr.wkbPoint) Does this code need to explicitly destroy these geometries, like the following, to avoid leaks, or can it simply allow them to go out of scope and have Python's ref

RE: [gdal-dev] ArcGIS 10 and GIO driver

Matt, Donno if you are still working on this problem (I've been on vacation) but here is one possibility. If the GIO driver uses ArcObjects, it might need to call this new "LoadVersion" function before making any other ArcObjects calls. I had a C++/ATL ArcObjects program that worked fine with 9.x

RE: [gdal-dev] ArcGIS 10

tly but I looked at the Python 2.6.5 code and it seemed like it would not have any ill effects. No promises, however... Jason -Original Message- From: Francis Markham [mailto:fmark...@gmail.com] Sent: Wednesday, August 11, 2010 10:14 PM To: Jason Roberts Cc: Discourse Maps; gdal-dev@list

RE: [gdal-dev] ArcGIS 10

Hannes, When I installed ArcGIS Desktop 10 on an XP machine that had no Python installed on it, the ArcGIS 10 installer created the directory C:\Python26\ArcGIS10.0. Unlike a normal Python installation, all of the Python files were under this C:\Python26\ArcGIS10.0 directory, rather than C:\Python

RE: [gdal-dev] ArcGIS 10

ArcGIS 10 installs Python 2.6 and numpy 1.3.0. It does not install GDAL with Python bindings. It includes a new Python module from ESRI called ArcPy. This module supposedly provides the capability of reading and writing raster layers in the form of numpy arrays, similar to GDAL's Python bindings. I

RE: [gdal-dev] Motion: Adopt RFC 29: OGR Set Ignored Fields

Sorry to jump in as another non-voting user of the API, but I second Raji's opinion. As a user of the API, I would expect to find consistency with other APIs and the SQL language, which typically require to specify the fields you want to retrieve, not the ones you want to ignore. The RFC presents

RE: [gdal-dev] Building debug Python bindings (e.g. _gdal.pyd) with MS Visual Studio

ing. There might be some issues with the VC runtime library though. If anyone has any further hints please let me know... Thanks, Jason -Original Message- From: Howard Butler [mailto:hobu@gmail.com] Sent: Saturday, July 17, 2010 12:15 PM To: Jason Roberts Cc: gdal-dev@lists.osgeo.

[gdal-dev] Building debug Python bindings (e.g. _gdal.pyd) with MS Visual Studio

This is probably a question for Tamas Szekeres and Howard Butler, but I'm emailing the whole list in case others are knowledgeable or interested. As part of trying to figure out http://trac.osgeo.org/gdal/ticket/3672, I would like to step through GDAL's SWIG-generated Python bindings in the Vis

RE: [gdal-dev] Problem calling Python bindings' band.ReadAsArray() from ArcGIS 9.3 - SWIG issue?

. End Time: Wed Jun 30 18:19:13 2010 (Elapsed Time: 1.00 seconds) Thanks, Jason From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Jason Roberts Sent: Wednesday, June 30, 2010 6:16 PM To: gdal-dev@lists.osgeo.org Subject: [gdal-dev]

[gdal-dev] Problem calling Python bindings' band.WriteArray() from ArcGIS 9.3 - SWIG issue?

Greetings GDAL developers, I am encountering what I suspect is a SWIG issue with the GDAL Python bindings. I am using the bindings from Python scripts invoked by ArcGIS on Windows. Starting with version 9.3, ArcGIS instantiates the Python interpreter internally with Python's C API and executes

RE: [gdal-dev] How to represent multi-dimensional array

etCDF arrays), making full multi-band support a bit awkward - and then formats like GRIB add another level of complication, interleaving bands and dimensions etc. Cheers, Mike. On Tue, Jun 22, 2010 at 1:17 AM, Jason Roberts wrote: >> > The trick is your netCDF has to meet a bunch >>

RE: [gdal-dev] How to represent multi-dimensional array

ed to show time stamps of a tsunami propagation models) > that loads those files and show their content interactively with the > help of a slider. Not much help for this, but it's a cool tool, thanks for the link. Jason Roberts wrote: > I have some experience trying to get ArcG

RE: [gdal-dev] Re: ESRI file geodatabase support

Peter, Although I have not seen the acknowledgement you mention, I have noticed that ArcGIS 9.x appears to create SQLite databases in the user's temp directory during certain operations. Perhaps they are just using it internally to implement various processing. Jason -Original Message- F

RE: [gdal-dev] How to represent multi-dimensional array

Chris, I have some experience trying to get ArcGIS to work well with time series satellite imagery and 4D ocean models (e.g. HYCOM, ROMS). Similar to GDAL, it does not appear that multidimensionality was designed into the current versions of ArcGIS. Like GDAL, ArcGIS appears mainly designed to wor

RE: [gdal-dev] Can't read HDF4 - TRMM

Ivan, This sounds very much like the classic problem with HDF and netCDF where the formats are extremely flexible and allow data to be stored in a variety of ways, but the data providers could not all agree on the same way of doing it. Different providers adopted different conventions such as HDF-

RE: [gdal-dev] Re: Hoe to convert ERDAS imagine(.img) files to ARC info ASCII files viceversa

Sorry, I meant to say "I looked at the ASCII files you mentioned" not "I looked at the IMG files you mentioned". Sorry for any confusion. Jason -Original Message- From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Jason Rob

RE: [gdal-dev] Re: Hoe to convert ERDAS imagine(.img) files to ARC info ASCII files viceversa

I'm not sure what you mean by getting the metadata information from the source dataset to the destination dataset. If you are referring to the metadata that ArcGIS maintains, such as all of the FGDC metadata it keeps in an XML file, I suspect that GDAL does not recognize that metadata. That metadat

RE: [gdal-dev] Re: Hoe to convert ERDAS imagine(.img) files to ARC info ASCII files viceversa

On possible problem in this particular example is that the ArcInfo ASCII Grid (AAIGrid) driver does not support the Create method of the GDAL API, only the CreateCopy method, correct? (Please correct me if I am wrong about this.) Therefore the procedure for converting IMG to ArcInfo ASCII Grid with

RE: [gdal-dev] Using GDAL with Windows 7

Here is an email thread that describes one possible reason you may not be able to use GDAL from an ArcGIS 9.3.1 Python geoprocessing script: http://lists.osgeo.org/pipermail/gdal-dev/2009-November/022661.html Basically, to be able to load the GDAL DLL into an ArcGIS 9.3.x process, you have to com

RE: [gdal-dev] KyngChaos Frameworks: GDAL's numpy vs Enthought's numpy

I recall a recent discussion regarding an "ABI breakage" with numpy 1.4. Please see http://mail.scipy.org/pipermail/numpy-discussion/2010-February/048203.html. Perhaps this could be the problem? The thread is very long and I did not follow it to the end. > GDAL python *should* be able to use a la

RE: [gdal-dev] Re: rgdal source code

that it could be done soon enough for you to make the R 2.11 date. But if you are interested, contact me offline and I'll see what can be done. Best, Jason -Original Message- From: Roger Bivand [mailto:roger.biv...@nhh.no] Sent: Friday, March 26, 2010 2:51 PM To: Jason Roberts Cc

RE: [gdal-dev] Re: rgdal source code

Roger, Pardon me for interrupting with a question I've had for a while but not asked you. On Windows at least, it appears that rgdal renames the GDAL shared library (e.g. gdal16.dll) to an rgdal-specific name (e.g. libgdal-1.dll). On windows, this has the advantage of avoiding DLL name collisions

[gdal-dev] When should OGRLayer::TestCapability be called?

Dear OGR devs, OGRLayer::TestCapability allows you to determine if an OGRLayer supports various things, such as creating new features or updating or deleting existing features. Can you advise me whether there are any drivers for which the capabilities differ for a given layer depending on wheth

RE: [gdal-dev] field name in ESRI file

Oz, The specification that Peter refers to is http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf. Also, check out the OGR Shapefile driver's documentation http://www.gdal.org/ogr/drv_shapefile.html. It documents this issue, as well as others that might be of interest. Finally, if you a

RE: [gdal-dev] Layer.DeleteFeature problems

Spencer, Although I have not tried the DeleteFeature method (yet), I do recall that the ESRI Shapefile driver docs mention this: "The OGR shapefile driver supports rewriting existing shapes in a shapefile as well as deleting shapes. Deleted shapes are marked for deletion in the .dbf file, and the

RE: [gdal-dev] gdal_translate and ArcGIS

Adam, I am by no means a gdal_translate expert but I do have experience with ArcGIS, so I can offer a few comments. ArcInfo ASCII Grid format does not include a specification of the bit depth, or even whether the file contains integers or floats. When ArcGIS reads the file, it infers all of this

[gdal-dev] When is GDAL_DATA environment variable read by OGR?

I am curious to know when OGR will read the GDAL_DATA environment variable. After looking at the code and reviewing this email thread, it appears that the environment variable is currently only read at initialization time (OGRSFDrive

RE: [gdal-dev] Nullable fields in OGR

is pointless or not doable at this moment in time, then I guess I am crazy. Jason -Original Message- From: Mateusz Loskot [mailto:mate...@loskot.net] Sent: Thursday, February 18, 2010 3:23 PM To: Jason Roberts Cc: 'gdal-dev' Subject: Re: [gdal-dev] Nullable fields in OGR Jason

RE: [gdal-dev] Nullable fields in OGR

hind a common abstraction (or will there be a QgisLayer driver for OGR?) Jason -Original Message- From: rbur...@gmail.com [mailto:rbur...@gmail.com] On Behalf Of Ragi Y. Burhum Sent: Thursday, February 18, 2010 2:30 PM To: gdal-dev@lists.osgeo.org; Jason Roberts Subject: Re: [gdal-dev] Null

RE: [gdal-dev] Nullable fields in OGR

ons%20for%20shapefile%20output. Does OGR do something different? Thanks, Jason -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Thursday, February 18, 2010 1:09 PM To: gdal-dev@lists.osgeo.org Cc: Jason Roberts Subject: Re: [gdal-dev] Nullable fields in OGR

[gdal-dev] Nullable fields in OGR

Many relational databases allow fields to be set to NULL. Is this supported in OGR? How does one detect whether a field is nullable or not? Looking at the class documentation, I see functions OGRFeature::IsFieldSet and OGRFeature::UnsetField. Are these intended for checking whether a field is N

RE: [gdal-dev] Open source vector geoprocessing libraries?

> > Yes, I see what you mean. But I suggest to the open source community > > that there is still value in implementing such features, either as > > part of OGR or another library, even if optimal performance cannot be > > guaranteed in all scenarios. > > Perhaps you'll find these inspiring: > > htt

RE: [gdal-dev] Open source vector geoprocessing libraries?

, January 13, 2010 12:53 PM To: gdal-dev@lists.osgeo.org Subject: RE: [gdal-dev] Open source vector geoprocessing libraries? Date: Wed, 13 Jan 2010 10:27:43 -0500 From: "Jason Roberts" Subject: RE: [gdal-dev] Open source vector geoprocessing libraries? To: "'Peter J Halls&#

RE: [gdal-dev] Open source vector geoprocessing libraries?

om: Duarte Carreira [mailto:dcarre...@edia.pt] Sent: Wednesday, January 13, 2010 4:54 AM To: Jason Roberts Cc: gdal-dev Subject: RE: [gdal-dev] Open source vector geoprocessing libraries? Jason, Have you looked at GeoKettle [1]? And recently I found GearScape [2], which seemed very interes

RE: [gdal-dev] Open source vector geoprocessing libraries?

GR directly. At any rate, I'm sure it is nice being able to do all your work in a spatially-enabled DBMS... Best, Jason -Original Message- From: Peter J Halls [mailto:p.ha...@york.ac.uk] Sent: Wednesday, January 13, 2010 2:33 AM To: Mateusz Loskot Cc: Jason Roberts; 'gdal-dev&#

RE: [gdal-dev] Open source vector geoprocessing libraries?

[mailto:mate...@loskot.net] Sent: Tuesday, January 12, 2010 8:33 PM To: Jason Roberts Cc: 'gdal-dev' Subject: Re: [gdal-dev] Open source vector geoprocessing libraries? Jason Roberts wrote: > Mateusz, > > I'm not an expert in this area, but I think that big performance >

RE: [gdal-dev] Open source vector geoprocessing libraries?

ssage- From: Mateusz Loskot [mailto:mate...@loskot.net] Sent: Tuesday, January 12, 2010 5:51 PM To: Jason Roberts Cc: 'gdal-dev' Subject: Re: [gdal-dev] Open source vector geoprocessing libraries? Jason Roberts wrote: > By integrating with GEOS, OGR can perform various spatia

RE: [gdal-dev] Open source vector geoprocessing libraries?

hat remains unresolved. Best, Jason -Original Message- From: Emilio Mayorga [mailto:emiliomayo...@gmail.com] Sent: Tuesday, January 12, 2010 1:26 PM To: Jason Roberts Cc: gdal-dev Subject: Re: [gdal-dev] Open source vector geoprocessing libraries? Hi Jason, This may not be quite what you h

RE: [gdal-dev] Open source vector geoprocessing libraries?

stGIS appears to provide a richer set of spatial operators. Jason From: doug_newc...@fws.gov [mailto:doug_newc...@fws.gov] Sent: Tuesday, January 12, 2010 12:29 PM To: Jason Roberts Cc: 'gdal-dev'; gdal-dev-boun...@lists.osgeo.org Subject: Re: [gdal-dev] Open source vecto

RE: [gdal-dev] Open source vector geoprocessing libraries?

Frank, Thanks for your thoughts on this. > I'd like to see something along this line happen. I to do it efficiently > it would be necessary to dig into GEOS past the C interface so that > a spatial index on a collection of features can be maintained over time > rather than created and discarded

[gdal-dev] Open source vector geoprocessing libraries?

Dear geospatial software experts, By integrating with GEOS, OGR can perform various spatial operations on individual geometries, such as buffer, intersection, union, and so on. Is there a library that efficiently performs these kinds of operations on entire OGRLayers? For example, this library

RE: [gdal-dev] SWIG Version

FWIW, the Python bindings generated by the old version of SWIG you were using has a compatibility problem with ArcGIS 9.3.x; the problem is fixed by 1.3.9 (possibly one of the builds in between, but I don't know which). A new feature of ArcGIS 9.3.x is to allow Python-based geoprocessing tools to

RE: [gdal-dev] tab delimited to shapefile

Hi Bruce, A while ago I wrote a little utility to convert delimited text files to shapefiles, based on an old version of shapelib. (This is before I knew about the OGR project.) You can download a copy from ESRI's ArcScripts site at http://arcscripts.esri.com/details.asp?dbid=14268. It does wor

RE: [gdal-dev] "Minimalist" GDAL 1.6.2 / 1.6.3 binaries for Windows to work around Xerces binary conflicts?

t ESRI and MathWorks are breaking interoperability, and I'd have a hard time making a case that GDAL should do anything different... Jason -Original Message- From: Joaquim Luis [mailto:jl...@ualg.pt] Sent: Monday, November 16, 2009 3:38 PM To: Jason Roberts Cc: 'Tamas Szekeres&

RE: [gdal-dev] "Minimalist" GDAL 1.6.2 / 1.6.3 binaries for Windows to work around Xerces binary conflicts?

e everyone's best efforts, and one finds oneself the loser by reaching for too much interoperability. (Sorry for the dramatic statement.) Jason -Original Message- From: Tamas Szekeres [mailto:szeker...@gmail.com] Sent: Monday, November 16, 2009 2:25 PM To: Jason Roberts Cc: g

[gdal-dev] "Minimalist" GDAL 1.6.2 / 1.6.3 binaries for Windows to work around Xerces binary conflicts?

Greetings GDAL team, The main GDAL download page http://trac.osgeo.org/gdal/wiki/DownloadingGdalBinaries contains a link to "minimalist" Windows executables for GDAL 1.6.0, built by Frank W when GDAL 1.6.0 was released. Is there any possibility you could offer similar binaries of 1.6.2 or the u

RE: [gdal-dev] Setting the spatial reference of an existing shapefile with OGR

ood approach, should I also call morphToESRI first, if I know the coordinate system has not already been morphed to ESRI? Thanks, Jason -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Thursday, November 12, 2009 7:43 PM To: Jason Roberts Cc: 'gdal-dev&#x

[gdal-dev] Setting the spatial reference of an existing shapefile with OGR

Greetings OGR experts, I have a shapefile for which no spatial reference was defined when the shapefile was created, but I know the spatial reference and would like to set it on this existing shapefile. Is this possible with the OGR Python API? It looks like the only place that takes an OGR

RE: [gdal-dev] GetStatistics and signed 8-bit IMGs and GeoTIFFs

Even, Thanks for the response. Please see http://trac.osgeo.org/gdal/ticket/3151. Best, Jason -Original Message- From: Even Rouault [mailto:even.roua...@mines-paris.org] Sent: Thursday, September 24, 2009 5:19 AM To: Jason Roberts Cc: 'gdal-dev' Subject: RE: [gdal-dev] Get

RE: [gdal-dev] GetStatistics and signed 8-bit IMGs and GeoTIFFs

that. So. does anyone know whether band.GetStatistics is supposed to work for these signed 8-bit files? If not, I guess I will write a workaround so my app will calculate statistics itself for signed 8-bit files. Thanks, Jason From: Jason Roberts [mailto:jason.robe...@duke.edu] Sent: Wednesda

RE: [gdal-dev] GetStatistics and signed 8-bit IMGs and GeoTIFFs

does the GDAL caller determine through GDAL that a given file is signed 8-bit or unsigned 8-bit? Thanks again, Jason From: gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Jason Roberts Sent: Wednesday, September 23, 2009 3:11 PM To: 'gdal-dev

[gdal-dev] GetStatistics and signed 8-bit IMGs and GeoTIFFs

Is band.GetStatistics() supposed to work with signed 8-bit integer rasters with the HFA or GTiff driver? With GDAL 1.6.0, I can successfully create a signed 8-bit raster with the HFA or GTiff driver using the PIXELTYPE=SIGNEDBYTE option: >>> a = numpy.array([[-128, -1, 0, 1, 127]], dtype='i

RE: [gdal-dev] Reading/Converting .GDB files ?

Felix, That sounds like it is in ArcGIS "file geodatabase" format. As far as I know, OGR cannot read that format. OGR can read ArcGIS "personal geodatabase" format with the PGEO driver. If you know someone with ArcGIS, ask them to convert the file geodatabase to a personal geodatabase and then you

RE: [gdal-dev] Re:

that ArcGIS 9.3.1 does recognize the NoData value properly in the scenario above. Jason -Original Message- From: Frank Warmerdam [mailto:warmer...@pobox.com] Sent: Thursday, September 17, 2009 3:58 PM To: Jason Roberts Cc: 'Riki Tiki'; gdal-dev@lists.osgeo.org Subject: Re:

RE: [gdal-dev] Re:

Riki, Please let us know whether Frank's suggestion works or not. I have been experimenting with writing GeoTIFFs using GDAL 1.6.0 and the Python bindings and have not been successful so far at using GDAL to calculate statistics that ArcGIS recognizes. It would be interesting to know whether this

[gdal-dev] OGRSpatialReference::MorphFromESRI handling WKT with single quotes returned by ArcGIS geoprocessor API

I am trying to understand how to use OGR to process spatial reference WKT obtained from ArcGIS. I have noticed that ArcGIS WKT strings returned by ESRI's geoprocessing API includes single quotes around names of things: >>> import arcgisscripting >>> gp = arcgisscripting.create() >>> d = gp.De

RE: [gdal-dev] UTF-8 String Support in GDALOpen() and OGRSFDriverRegistrar::Open()

> A remaining question is : should we provide a 'compatibility mode' for users > that only deal with non-ASCII character in the ANSI range of their local code > page and can use it successfully currently ? This could be controlled by a > environment variable (CPL_ANSI_FILENAMES=ON) that would rever

RE: [gdal-dev] Reading signed 8-bit Erdas Imagine .img (HFA driver)

Message- From: Frank Warmerdam [mailto:warmer...@pobox.com] Sent: Tuesday, September 01, 2009 11:05 PM To: Jason Roberts Cc: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] Reading signed 8-bit Erdas Imagine .img (HFA driver) Jason Roberts wrote: >>>> band.GetMetadata() > {'LAYER_

  1   2   >