[gdal-dev] Curve support in OGR
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/databases we use: Postgis (Geodata Warehouse) Oracle Spatial (production system for survey data, linked to Autodesk Topobase) dxf/dwg (file exchange) SVG (presentation format) sdf (used for Mapguide) Most of our survey data contains circular arcs, some datasets also contain splines. I know that curve support in Postgis is somehow limited, but each release improves a bit on it and the list of curve-aware operators is growing: http://postgis.refractions.net/documentation/manual-svn/ch08.html#PostGIS_Curved_GeometryFunctions If OS GIS wants to further penetrate in Switzerland it has to be able to deal with curves (at least circular arcs) since they are used all over the place. Of course we are willing to partially help to finance such a development (hopefully with some others) if the OGR developers are interested in adding curve support and can offer an estimate on how much it would cost to implement this (at least on the core and for selected formats). Thanks, Andreas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Java bindings build issue
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/gdal/ogr mkdir -p org/gdal/osr 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: *** [gdal_wrap.cpp] Error 1 Any ideas? The swig version is 1.3.29. Regards, Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Towards more user-friendly error messages
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 default off at least in Perl bindings) and when he then calls SetFeature the error is: RuntimeError Error in psSHP-sHooks.FSeek() or fwrite() writing object to .shp file. Which for the initiated hints that maybe the file was opened read-only, but for a newbie is just scary. In this case there are two issues: - the error is at layer method, although the data source was opened read-only (does the layer know its data source and is it easy to query from the data source, how it was opened - at least in the bindings there's no method for that?) - where to report the error nicely, for example Can't call SetFeature with a read-only layer, you moron. Is this a policy issue, or is this a case-by-case issue? How could we find and list the frequently made mistakes? Regards, Ari -- Prof. Ari Jolma Environmental Management Information Technology Teknillinen Korkeakoulu / Helsinki University of Technology tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] How to delete shapefile
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,
VSIFilesystemHandler *poHandler )
{
if( osPrefix == )
Get()-poDefaultHandler = poHandler;
else
Get()-oHandlers[osPrefix] = poHandler;
}
The calling methods are passing what appears to be valid strings but the
osPrefix contents in this method always seem to be different that the calling
method. One thing that looks odd although it may be valid is using std::string
as an array index. The program will go through InstallHandler a few times
before it crashes. When it does the calling method is passing double quotes
yet this method falls to the else condition then crashes.
Are there any settings that need to be changed for the versions after 1.5.3?
Thanks again for your help.
Bruce
The stack trace is shown below.
Stack trace for 1.6.1 is relatively the same but it failed on the
GZIPFileSystemHandler (I think that was the name)
Stack trace for 1.7.0
msvcr80d.dll!cmpDWORD(const void * lhs=0x6973762f, const void *
rhs=0x0012e8a0) + 0x18 bytes C
msvcr80d.dll!unaligned_memcmp(const unsigned char * bLHS=0x69737637,
const unsigned char * bRHS=0x0012e8a8, unsigned int siz=8) + 0x264 bytes C
msvcr80d.dll!memcmp(const void * lhs=0x6973762f, const void *
rhs=0x0012e8a0, unsigned int siz=8) + 0x19a bytesC
msvcp80d.dll!std::char_traitschar::compare(const char *
_First1=0x6973762f, const char * _First2=0x0012e8a0, unsigned int _Count=8)
Line 553 + 0x11 bytesC++
msvcp80d.dll!std::basic_stringchar,std::char_traitschar,std::allocatorchar
::compare(unsigned int _Off=0, unsigned int _N0=12, const char *
_Ptr=0x0012e8a0, unsigned int _Count=8) Line 1978 + 0x2f bytes C++
msvcp80d.dll!std::basic_stringchar,std::char_traitschar,std::allocatorchar
::compare(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Right=/vsimem/) Line 1939 C++
msvcp80d.dll!std::operatorchar,std::char_traitschar,std::allocatorchar
(const std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Left=Bad Ptr, const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Right=/vsimem/) Line 135 + 0xc bytes C++
OccurrenceTool.exe!std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar
::operator()(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Left=/vsisubfile/, const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Right=) Line 143 + 0xe bytesC++
OccurrenceTool.exe!std::_Treestd::_Tmap_traitsstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,VSIFilesystemHandler
*,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
const ,VSIFilesystemHandler * ,0 ::_Lbound(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Keyval=) Line 1174 + 0x19 bytes C++
OccurrenceTool.exe!std::_Treestd::_Tmap_traitsstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,VSIFilesystemHandler
*,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
const ,VSIFilesystemHandler * ,0 ::lower_bound(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Keyval=) Line 987 + 0x10 bytes C++
OccurrenceTool.exe!std::mapstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,VSIFilesystemHandler
*,std::lessstd::basic_stringchar,std::char_traitschar,std::allocatorchar
,std::allocatorstd::pairstd::basic_stringchar,std::char_traitschar,std::allocatorchar
const ,VSIFilesystemHandler * ::operator[](const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
_Keyval=) Line 170C++
OccurrenceTool.exe!VSIFileManager::InstallHandler(const
std::basic_stringchar,std::char_traitschar,std::allocatorchar
osPrefix=, VSIFilesystemHandler * poHandler=0x023d56e8) Line 651 + 0x13
bytes C++
OccurrenceTool.exe!VSIInstallMemFileHandler() Line 694 + 0x48 bytes
C++
OccurrenceTool.exe!VSIFileManager::Get() Line 601 C++
OccurrenceTool.exe!VSIFileManager::GetHandler(const char *
pszPath=0x01cb4e10) Line 616 + 0x5 bytesC++
OccurrenceTool.exe!VSIReadDir(const char * pszPath=0x01cb4e10) Line 63
+ 0x9 bytes C++
OccurrenceTool.exe!OGRSFDriverRegistrar::AutoLoadDrivers() Line 763 +
0x12 bytes C++
OccurrenceTool.exe!OGRRegisterAll() Line 43C++
OccurrenceTool.exe!GdalWrapper::Initialize() Line 125 + 0x5 bytes
Re: [gdal-dev] Java bindings build issue
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 org/gdal/gdal mkdir -p org/gdal/gdalconst mkdir -p org/gdal/ogr mkdir -p org/gdal/osr 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: *** [gdal_wrap.cpp] Error 1 Any ideas? The swig version is 1.3.29. Regards, Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Java bindings build issue
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: *** [gdal_wrap.cpp] Error 1 Any ideas? The swig version is 1.3.29. hmm, at least for Perl all is (almost) well: swig -Wall -I../include -I../include/perl -I../include/perl/docs -DPERL_CPAN_NAMESPACE -I -c++ -perl -o gdal_wrap.cpp gdal.i ..\include\gdal.i(705): Warning(322): Redundant redeclaration of 'GeneralCmdLineProcessor', ..\include\ogr.i(1818): Warning(322): previous declaration of 'GeneralCmdLineProcessor'. swig -Wall -I../include -I../include/perl -I../include/perl/docs -DPERL_CPAN_NAMESPACE -I -perl -o gdalconst_wrap.c gdalconst.i swig -Wall -I../include -I../include/perl -I../include/perl/docs -DPERL_CPAN_NAMESPACE -I -c++ -perl -o ogr_wrap.cpp ogr.i swig -Wall -I../include -I../include/perl -I../include/perl/docs -DPERL_CPAN_NAMESPACE -I -c++ -perl -o osr_wrap.cpp osr.i i.e., cpl.i is ok for Perl 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. my swig is 1.3.36 Regards, Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- Prof. Ari Jolma Environmental Management Information Technology Teknillinen Korkeakoulu / Helsinki University of Technology tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Java bindings build issue
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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] hdf5 to esri shape-file converter
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 ** This communication contains information which is confidential and may also be legally privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), disclosure, copying, distribution, or other use of, or action taken or omitted to be taken in reliance upon, this communication or the information in it is prohibited and maybe unlawful. If you have received this communication in error please notify the sender by return email, delete it from your system and destroy any copies. ** ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
RE: [gdal-dev] hdf5 to esri shape-file converter
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 raster to vector data is called Vectorization. And Vectorization is not a straightforward thing. See e.g http://en.wikipedia.org/wiki/Vectorization_(computer_graphics) Thanks for the info. It is very useful for me. But HDF5 can actually many different things: Are you talking about HDF5 files with raster or vector data? [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? I thought that just inspecting the hdf-file to grab the vector data somehow will be really cool if it holds that and the same can be converted to shape files using ogr api. May be it is not that cool :( Many a thanks, Chandra ** This communication contains information which is confidential and may also be legally privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), disclosure, copying, distribution, or other use of, or action taken or omitted to be taken in reliance upon, this communication or the information in it is prohibited and maybe unlawful. If you have received this communication in error please notify the sender by return email, delete it from your system and destroy any copies. ** ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] How to delete shapefile
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 data
source.
Bruce,
Are you saying that you are unable to run this simple program successfully?
#include ogrsf_frmts.h
int main()
{
OGRRegisterAll();
}
If you indeed can not run it, it probably means your GDAL installation
is not configured properly or broken.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Towards more user-friendly error messages
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 indicate if it is opened in read-only or update mode. I'm not sure there is a policy for error reporting and how it could be formulated if there was one ! If we can make it clearer in situations where it is not currently, just report it as you did. I'd note that you can check for most operations on OGR Layers if they are possible by using the TestCapability() method, which is mapped to swig. For example, for SetFeature() with the OLCRandomWrite flag. (By the way, in that commit I've also fixed a few cases where the answer was not correct for other flags) Best regards, Even Le Wednesday 17 June 2009 16:25:04 Ari Jolma, vous avez écrit : 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 default off at least in Perl bindings) and when he then calls SetFeature the error is: RuntimeError Error in psSHP-sHooks.FSeek() or fwrite() writing object to .shp file. Which for the initiated hints that maybe the file was opened read-only, but for a newbie is just scary. In this case there are two issues: - the error is at layer method, although the data source was opened read-only (does the layer know its data source and is it easy to query from the data source, how it was opened - at least in the bindings there's no method for that?) - where to report the error nicely, for example Can't call SetFeature with a read-only layer, you moron. Is this a policy issue, or is this a case-by-case issue? How could we find and list the frequently made mistakes? Regards, Ari ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL/ArcObjects based app crashes with newer GDAL versions (was How to delete shapefile)
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 am linking to the GDAL static
library when the crash occurs. If I try to link to the gdal_i.lib then
the program does not crash but it does not let me step into any of the
methods even though it is a debug library and no GDAL functions work.
You mentioned configuration. Does GDAL 1.6 and new code require some
configuration on Windows XP that was not required before?
Bruce
-Original Message-
From: Mateusz Loskot [mailto:mate...@loskot.net]
Sent: Wednesday, June 17, 2009 1:15 PM
To: Clay, Bruce
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to delete shapefile
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
data
source.
Bruce,
Are you saying that you are unable to run this simple program
successfully?
#include ogrsf_frmts.h
int main()
{
OGRRegisterAll();
}
If you indeed can not run it, it probably means your GDAL installation
is not configured properly or broken.
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
This message and any enclosures are intended only for the addressee. Please
notify the sender by email if you are not the intended recipient. If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful. Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GDAL/ArcObjects based app crashes with newer GDAL versions (was How to delete shapefile)
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 (contrary to
C API). Just relinking will not be sufficient.
* for same reason, if you try to load GDAL plugins compiled with an older
version into a different GDAL version, you'll get crashes. Some checks have
been introduced starting with GDAL 1.5.0 into plugin code to detect those
situations and error out properly.
* if your application links directly or indirectly with several copy of GDAL
library at the same time, it will likely not work too
Le Wednesday 17 June 2009 20:59:24 Clay, Bruce, vous avez écrit :
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 am linking to the GDAL static
library when the crash occurs. If I try to link to the gdal_i.lib then
the program does not crash but it does not let me step into any of the
methods even though it is a debug library and no GDAL functions work.
You mentioned configuration. Does GDAL 1.6 and new code require some
configuration on Windows XP that was not required before?
Bruce
-Original Message-
From: Mateusz Loskot [mailto:mate...@loskot.net]
Sent: Wednesday, June 17, 2009 1:15 PM
To: Clay, Bruce
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to delete shapefile
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
data
source.
Bruce,
Are you saying that you are unable to run this simple program
successfully?
#include ogrsf_frmts.h
int main()
{
OGRRegisterAll();
}
If you indeed can not run it, it probably means your GDAL installation
is not configured properly or broken.
Best regards,
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Fwd: RE: [gdal-dev] GDAL/ArcObjects based app crashes with newer GDAL versions (was How to delete shapefile)
Forwarding to the list as others might be able to help you. No more idea on my
side.
---BeginMessage---
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
in the path. When I switch from one test to another I switch both the include
path and the library path.
I switched to a much simpler test program and it is also having problems. It
will run properly with GDAL 1.5.3 with either the static library or the dynamic
library. GDAL 1.6.1 and GDAL 1.7.0 will run if I link against the dynamic
library (gdal_i.lib) and use the dll but crash in the same area as the main
application I was working on that included ArcObjects. This application only
includes those applications related to GDAL and the operating systems.
One thing I noticed is that the static debug library is around 90 MB in size
where the dynamic library is only around 8 MB. They are both supposed to be
debug versions but a major difference in size.
When I link to the dynamic debug library I can not step into it with the
debugger with any version.
Bruce
-Original Message-
From: Even Rouault [mailto:even.roua...@mines-paris.org]
Sent: Wednesday, June 17, 2009 3:33 PM
To: gdal-dev@lists.osgeo.org
Cc: Clay, Bruce; Mateusz Loskot
Subject: Re: [gdal-dev] GDAL/ArcObjects based app crashes with newer GDAL
versions (was How to delete shapefile)
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 (contrary to
C API). Just relinking will not be sufficient.
* for same reason, if you try to load GDAL plugins compiled with an older
version into a different GDAL version, you'll get crashes. Some checks have
been introduced starting with GDAL 1.5.0 into plugin code to detect those
situations and error out properly.
* if your application links directly or indirectly with several copy of GDAL
library at the same time, it will likely not work too
Le Wednesday 17 June 2009 20:59:24 Clay, Bruce, vous avez écrit :
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 am linking to the GDAL static
library when the crash occurs. If I try to link to the gdal_i.lib then
the program does not crash but it does not let me step into any of the
methods even though it is a debug library and no GDAL functions work.
You mentioned configuration. Does GDAL 1.6 and new code require some
configuration on Windows XP that was not required before?
Bruce
-Original Message-
From: Mateusz Loskot [mailto:mate...@loskot.net]
Sent: Wednesday, June 17, 2009 1:15 PM
To: Clay, Bruce
Cc: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] How to delete shapefile
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
data
source.
Bruce,
Are you saying that you are unable to run this simple program
successfully?
#include ogrsf_frmts.h
int main()
{
OGRRegisterAll();
}
If you indeed can not run it, it probably means your GDAL installation
is not configured properly or broken.
Best regards,
This message and any enclosures are intended only for the addressee. Please
notify the sender by email if you are not the intended recipient. If you are
not the intended recipient, you may not use, copy, disclose, or distribute this
message or its contents or enclosures to any other person and any such actions
may be unlawful. Ball reserves the right to monitor and review all messages
and enclosures sent to or from this email address.
---End Message---
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
