On Thu, Apr 19, 2012 at 6:40 PM, Frank Warmerdam wrote:
> Charlie,
>
> The typical reason would be that adding opendap adds stuff into the
> libraries list that results in other "test links" failing. It would
> be helpful if you could file a bug and attach the config.log.
>
> Best regards,
> Fran
Charlie,
The typical reason would be that adding opendap adds stuff into the
libraries list that results in other "test links" failing. It would
be helpful if you could file a bug and attach the config.log.
Best regards,
Frank
On Thu, Apr 19, 2012 at 6:20 PM, Charlie Sharpsteen
wrote:
> I'm tr
I'm trying to add support for OpenDAP to a build of GDAL on OS X. However,
when I add `--with-dods-root` to my configure arguments,
I inexplicably loose support for Epsilon, cURL, SpatiaLite and FreeXL.
Full configure logs can be found here:
https://gist.github.com/2425147
The diff between the
Asuka,
I do not understand what is your intent - creating files from scratch,
copying from other format, using gdalwarp/gdal_translate?
If you are using the CreateCopy mechanism (like in gdal_translate),
then you can set the variable name in the Band-level metadata
NETCDF_VARNAME. This is what i
19.04.2012 6:28, chenliang wang ???:
Thanks a lot . GeoTrellis is real powerful. What a pity that the
platform I want to buid is just an desktop application without web
services. I want to find some geoprocessing scripts including map
algebra , zonal computation, reclassifity , vector oper
Normal 0 false false falseEN-US JA X-NONE
MicrosoftInternetExplorer4
> As far as a general spatial indexing for any OGR datasource, I don't know
how it would be possible because a spatial index only makes sense if you can
have random access to the features. And a lot of OGR formats currently don't
support (efficient) random access, due to the nature of the storage (
Have you examined the Grass or Qgis development pages. They have plenty of
scripting examples.
http://grass.osgeo.org/wiki/Development
just a thought :)
2012/4/18 chenliang wang
> Hi,all:
> I am going to write a platform to process some geospatial data based on
> GDAL. But I noticed I need to
Selon Ari Jolma :
> On 04/19/2012 03:04 PM, Even Rouault wrote:
> >> http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
> >>
> >
> > 3) I'm wondering if it would not be more appropriate to separate the
> creation of
> > fields of the output layer in a separate method that might be called, or
On 04/19/2012 03:04 PM, Even Rouault wrote:
http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
3) I'm wondering if it would not be more appropriate to separate the creation of
fields of the output layer in a separate method that might be called, or not,
before the real operation. For exam
> http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
>
Ari,
I have reviewed your proposal and it looks interesting. Here are my observations
:
1) Argument order. A.Operation(B, C) where C is the target layer doesn't seem
very intuitive, but I'm not sure I have something fundamentally better
If you use gdal-1.9 the driver will use the variable name from the
original netcdf file (if any).
for example, if you use the following command the original filename
will be preserved.
gdal_translate -of netcdf in.nc out.nc
However, if copying from other formats (such as gtiff), or creating a
new
On 04/18/2012 02:32 AM, Frank Warmerdam wrote:
Ari,
I think this would be an interesting addition. Would you be willing
to write up an RFC?
http://trac.osgeo.org/gdal/wiki/rfc39_ogr_layer_algebra
In there I call for discussion on the method names. They are now:
Intersection, Union, Identit
Hello everybody,
I have a question about netCDF creation.
I am using GDAL 1.9.0 in python.
Creation Issues in http://www.gdal.org/frmt_netcdf.html mentions
“each variable array is names Band1, Band2,… ”.
I would like to change the names.
Can anyone give me ideas?
Thank you for your time.
Kind
Selon Tyler Mitchell :
>
>
> Jason Roberts wrote:
> ...
> > For scenarios involving large numbers of features, I suspect it is much
> > harder to do it fast and within available memory. It is probably necessary
> > to do a multi-pass approach, where the first step operates only on the
> > spatial
On 04/18/2012 11:06 PM, Jason Roberts wrote:
For scenarios involving large numbers of features, I suspect it is much
harder to do it fast and within available memory. It is probably necessary
to do a multi-pass approach, where the first step operates only on the
spatial indexes of the layers invo
16 matches
Mail list logo
