>> GDAL_API_RPC
>> GDAL_API_PROXY
>> GDAL_API_SERVER
IIUC, the proposed functionality is not really a Remote Procedure
Call, or a Proxy, or a SErver.
i.e. could the driver be run on a remote server with this mechanism?
Rather, it is a way to run a driver in a sub-process. So maybe:
DGAL_SUBPR
On Wed, Jan 30, 2013 at 12:03 PM, Carl Godkin wrote:
> 2. Tiles
>
> I don't understand why or when I'd use a tiled vs. untiled request. If I'm
> interested in a JPEG or PNG from a particular server covering a particular
> area in a particular coordinate system, why would I choose one over the
>
On Wed, Nov 14, 2012 at 3:15 PM, Chris Barker wrote:
> On Wed, Nov 14, 2012 at 4:53 AM, Jaak Laineste (Nutiteq)
> wrote:
>
>> Have you found workaround for this?
>
> nope.
>
>> I just created index bounding boxes for
>> all the NOAA BSB charts using GDAL
&
Tom,
I'd look for re-gridding code designed for modeling -- in particular
ESMF has a bunch of good stuff, designed specifically for this sort of
thing:
http://www.earthsystemmodeling.org/
They even have python bindings to at lest some of the re-gridding code.
-Chris
On Tue, Nov 13, 2012 at 9
On Fri, Nov 9, 2012 at 2:48 PM, Even Rouault
wrote:
> ok, I see what happens. In _3 and _4 cases, the BSB driver manages to compute
> a geotransform from the GCPs and then assigns a projection, in addition to the
> GCP projection.
> In the _1 and _2 cases, the BSB driver doesn't manage to compute
On Tue, Oct 16, 2012 at 1:59 PM, Antonio Falciano wrote:
>> Does anybody know of a way to set the data type in the call ReadAsArray.
>> It is currently reading a field as an unsigned int and it needs to be read
>> as a signed int.
> ReadAsArray returns substantially a numpy array, so you can use
On Sun, Oct 7, 2012 at 8:33 PM, Tim Keitt wrote:
>> cool! though I"m a little confused as to how this fits with OGR.
>
> OGR is used for i/o.
>
I see -- so you've written something like the triangle command line
utility, but with OGR for IO, so you don't need to use triangles
particular data fil
On Thu, Oct 4, 2012 at 6:31 PM, Tim Keitt wrote:
> Just letting folks know that we've released an OGR wrapper for the
> Triangle library. It would be great if folks could test it. I could
> also use some help improving the OGR bits.
cool! though I"m a little confused as to how this fits with OGR.
On Mon, Jul 30, 2012 at 8:19 AM, Jay L. wrote:
> Chris,
>
> Thanks for the link / info. My issue is not working with the ctypes array,
> but the fact that, I believe, GDAL returns a numpy array using
> gdal.ReadAsArray(). Perhaps it is possible to use the GDAL python bindings
> ReadAsArray() to
On Fri, Jul 27, 2012 at 8:40 PM, Jay L. wrote:
> Currently the workflow is to open the dataset and grab the first band, as
> usual. I then read in the array, create an empty ctype array, and use
> memmove to move the numpy array to my ctypes array.
numpy comes with some utilities for working wit
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 b
On Mon, May 28, 2012 at 10:16 AM, Chao YUE wrote:
> I have a shapefile of boreal foest (which further contains some ecoregion
> types) in North America and I want to like convert it to a NetCDF file (or
> numpy masked array)
Well, what's in the shape file? polygons? You'll need to know more
abou
On Thu, May 24, 2012 at 2:40 PM, Even Rouault
wrote:
> Ok, see http://trac.osgeo.org/gdal/ticket/4682 for a fix. Basically, the
> current caching strategy is maintained (cache all bands that have been
> accessed), until a threshold is reached (arbitrarly set to 100 MB by default).
seems reasonabl
Even,
Thanks so much!
> ok I reproduce your issue.
>
> The GRIB driver actually caches all the raster data from a band the first type
> you access it, and never releases it.
I just tested reading only a subset of teh band (because I don't need
the whole thing), and it used exactly the same amoun
Hi folks,
I"m finding what appears to be a memory leak, using the GRIB reader,
with the python bindings.
What I'm trying to do is read the data one band at a time, then throw
it away and read the next band -- there are 1129 bands in the file at
hand, and I can't hold it all in memory (32 bit stil
On 1/25/11 4:07 PM, Jason Roberts wrote:
I didn't think we were discussing platform-independent solution for
linking bindings with the GDAL libs, as different operating systems
have radically different installation locations.
sure, but pure python that points to a path, it a lot easier than
lo
On 1/6/2011 4:25 PM, Joaquim Luis wrote:
By the way, isn't there some new stuff about "side by side" installs
or something -- that's supposed to help dll hell?
I think you are referring to the "manifests" but here also MS has
changed their mind (aleluia). VC2010 doesn't have them anymore which
Ole,
The netcdf data model is pretty different than the GDAL data model, I"m
not surprised that GDAL can't figure out the grid.
Can you just go hand-edit the AAIGRID?
If you need to script this, I'd tend to look for another solution -- it
would be pretty easy to parse the ncdump output and
scizmeli wrote:
I would strongly encourage the inclusion of netcdf-4 inside GDAL. Not merely
for HDF5, but also for OpenDAP.
+1
I just recently discovered that OpenDAP libraries are now being included
built-in in the new netcdf4 : http://www.unidata.ucar.edu/software/netcdf/.
yes, but it's
Simon Greener wrote:
What else is there to do for its adoption as the new shapefile for the
open source community?
I heard someone say once that a specification isn't a standard unless
there is more than one implementation (preferably more). Is there any
other way to read or write a spatialit
Belaid MOA wrote:
I do not see how gdal_wrap could be used to find the pixels in the
source image that map to
the same pixel in the destination image?
sorry for the typo, that's "gdalwarp"
My point was not that you could use it to find the pixels, but that you
could use it to do the whole jo
Belaid MOA wrote:
> Thanks for the reply. I do not see how anti-aliasing techniques could be
> used here.
anti-aliasing when warping rasters requires computing how much the
pixels of the source and destination overlap each-other.
> Does anyone else have simple answers to the two elementary ques
Are there Windows binaries of 1.6.1 anywhere?
http://download.osgeo.org/gdal/win32/1.6/
seems to have only 1.6.0, and the FWtools and Geoinformatica packages
don't seem to be set up for use with the Python bindings on PyPi. I
also can't tell what version they have anyway!
Thanks,
-Chris
-
23 matches
Mail list logo
