Forwarding to the list as others might be able to help you. No more idea on my
side.
--- Begin Message ---
Even:
Thanks for the reply.
Yes I am rebuilding the application with the related hearer files. I have 3
parallel directories to test my applications. Each has the GDAL version number
i
Le Wednesday 17 June 2009 23:17:42 Gong, Shawn (Contractor), vous avez écrit :
> hi list,
>
> I use these codes for CreateCopy()
> src_ds = gdal.Open( src_filename )
> dst_ds = driver.CreateCopy( dst_filename, src_ds, 0 )
>
>
> If the src_ds has two bands and my dst_ds has only one band, is
hi list,
I use these codes for CreateCopy()
src_ds = gdal.Open( src_filename )
dst_ds = driver.CreateCopy( dst_filename, src_ds, 0 )
If the src_ds has two bands and my dst_ds has only one band, is there a
way to CreateCopy just one band? Or is there a way to remove bands in
Gdal Python?
I'm not familiar at all with SDE and Windows subtelties, so my comment might
be unrelevant. But the following statements are at least universally true :
* if your application uses GDAL/OGR C++ API, you must recompile it against
headers of newer GDAL version as C++ ABI changes from 1.x to 1.y (con
Mateusz:
Yes that is the case. The same application works fine with GDAL 1.5.4
but not with any newer version.
I am beginning to suspect SDE / GDAL interaction. I think SDE uses GDAL
1.4. My GDAL library is built with SDE support and I am linking in
ArcObjects libraries to my application. I a
huh - processing using Make - clever.
We are researching several different approaches for this also but I
imagine we will use Conductor, created by (UofA). Another of our
commercial systems uses Condor (open source -
http://www.cs.wisc.edu/condor/ ) .
Currently the UofA Conductor HiRISE pipeli
Ari,
It's funny because I myself got caught by the same issue a few days ago.
So I've just improved error reporting on shapefile layer for SetFeature(),
CreateFeature() and DeleteFeature() operations in trunk (r17255). It was
trivial in that case as the OGRShapeLayer object has a flag to indicat
Hi Chandra,
> [Chandra ] I have hdf files holding vector data only(basically
> longitude, latitude, speed etc).
> Do you think that it will easier now to convert it to shape files?
Most probably, because you can skip the Vectorization.
You could use CSV as an intermediate format:
* Create a CSV
Clay, Bruce wrote:
Mateusz:
Thanks for your reply. Unfortunately I can not get far enough to do
that. The crash is occurring down stream from OGRRegisterAll. That is
to say, the last call in my code space before the crash is
OGRRegisterAll. I can not get OGR initialized to be able to open a
Steffen,
>Hi Chandra,
>
>> I was looking for a converter tool to convert a given hdf5 file
(.mh5)
>to
>> esri shape-files(.shp) and vice versa.
>
>GDAL supports reading of HDF5 raster data.
[Chandra ] this is really cool news for me.
>But Shape files are vector
>data.
>The process to convert from
Hi Chandra,
> I was looking for a converter tool to convert a given hdf5 file (.mh5) to
> esri shape-files(.shp) and vice versa.
GDAL supports reading of HDF5 raster data. But Shape files are vector data.
The process to convert from raster to vector data is called Vectorization.
And Vectorization
Hi,
I was looking for a converter tool to convert a given hdf5 file (.mh5)
to esri shape-files(.shp) and vice versa.
Does anyone has any idea about the same?
Does anyone see any utility in developing this(if it doesn't exists
already somewhere)?
Thanks,
Chandra
**
Clay, Bruce wrote:
Frank: Thanks for the information. I tried to update to a newer
version of GDAL (I tried both 1.6.1 and 1.7.0) but the both crash on
RegisterAll
In both cases the problem seems to be in the following method
void VSIFileManager::InstallHandler( const std::string& osPrefix,
line 214 at cpl.i is #ifndef SWIGRUBY
the corresponding #endif seems to be on the last line and without
newline, maybe that's confusing your swig? Add a newline to the end of
the file and say make.
Yeah, that's it. Thanks for saving my day :-)
Cheers,
Stefan
_
Stefan Moebius kirjoitti:
swig -Wall -I../include -I../include/java -I../include/java/docs
-outdir "org/gdal/gdal" -package "org.gdal.gdal"
-I/home/devbuild/gdal-1.7
-c++ -java -o gdal_wrap.cpp gdal.i
../include/cpl.i:EOF: Error: Missing #endif for conditional starting
on line 214
make: ***
Same problem with OGR enabled.
Stefan Moebius wrote:
Hi,
I'm trying to build gdal-trunk with Java bindings on rhel-5.
I succeeded with GDAL itself, but had to disable expat.
I also disabled OGR, but included PROJ.4.
Next I configured gdal/swig/java/java.opt and ran make.
Result is:
mkdir -p
Frank:
Thanks for the information. I tried to update to a newer version of GDAL (I
tried both 1.6.1 and 1.7.0) but the both crash on RegisterAll
In both cases the problem seems to be in the following method
void VSIFileManager::InstallHandler( const std::string& osPrefix,
A colleague of mine is beginning to use GDAL via the Perl bindings (the
bindings are not the main issue however). He makes quite simple errors,
but is perplexed when he gets rather scary looking / uninformative error
messages. For example he forgot to open Shapefile with update turned on
(it is by
Hi,
I'm trying to build gdal-trunk with Java bindings on rhel-5.
I succeeded with GDAL itself, but had to disable expat.
I also disabled OGR, but included PROJ.4.
Next I configured gdal/swig/java/java.opt and ran make.
Result is:
mkdir -p org/gdal/gdal
mkdir -p org/gdal/gdalconst
mkdir -p org
Hi all,
I am sure this topic is coming up once in a while. I wonder what the
take is on curve support in the OGR feature model.
Most formats we use now support curves, but our favorite translation
engine does not. For curve support I currently have to use FME.
These are the formats/database
20 matches
Mail list logo