[gdal-dev] Re: GDAL compiler & GDAL utility use

[Randy]

Hi Peter,
Thank you very much!
With your help,I fixed this problem!
The reason is that my GDAL_DATA environment variable is not true.
I set it first by the GDAL
FAQ(http://trac.osgeo.org/gdal/wiki/FAQInstallationAndBuilding#HowtosetGDAL_DATAvariable) which tells me :$ export GDAL_DATA=/usr/local/share/gdal/data
but I find in my default installing path,there is not "data" folder and
all the dates is in its parent directory:"/usr/local/share/gdal". So I
reset my GDAL_DATA environment variable,and it works well now.I forgot
my this variable value in my last Ubuntu9.04 OS,it was a long time
ago.And I think the GDAL FAQ "How to set GDAL_DATA variable?" should
change its answer.

Thank you,Peter,again!

Best regards,
Randy
> Aha ...
> 
> > ERROR 1:Invalid index :-1
> > ERROR 1:Invalid index :-1
> > ERROR 1:Invalid index :-1
> > ERROR 1:Invalid index :-1
> 
> I think this is where the key to your problem lies.  This message, I believe, 
> implies that the input structure does not match that expected by the driver, 
> such that it is failing to extract key control information.  The best way to get 
> at the meaning of this is to locate where in the s57 driver this error is 
> generated - it may be in more than one location, however.  Given the 
> condition(s) pertaining to the error, you should be able to deduce the 
> underlying problem.  It is possible to turn the internal debug on with a switch 
> to ogrinfo / ogr2ogr: that may help.
> 
> Does *any* of the output look plausible?  Can you read the file successfully 
> elsewhere - I've assumed you can?
> 
> One possibility relates back to configure: has this identified the byte order 
> correctly?
> 
> I do not think these errors are going to relate to runtime environment 
> variables, but it is possible for environment variables to override parameters 
> to configure - I often forget to unset ORACLE_HOME, for example, which wreaks 
> havoc with accessing the include files and then wonder why it refuses to include 
> the Oracle driver.  I do not know quite how this operates in Windows - I use 
> Cygwin for my GDAL work there and have to be as careful as on Solaris.
> 
> 
> Best wishes,
> 
> Peter
> 
> > //...a lot as the same as above
> > Layer name: DSID
> > ...
> > Layer name:Point
> > .....
> > Layer name:Line
> > ..........
> > 
> > While the ogrinfo in FWTools ,the result is as follows:
> > Layer name: DSID
> > ...
> > Layer name: ACHARE
> > ...
> > Layer name: BCNLAT
> > ...
> > 
> > Then, I'd like to know what else I should do when I build GDAL in a default way:
> > cd 
> > ./configure
> > ./make
> > ./sudo make install
> > What I do else until now is just set GDAL_DATA environment variable and OGR_S57_OPTIONS. And I use GDAL1.7.2 release version.
> > 
> > Best regards,
> > Randy
> > -----Original Message-----
> > From: Peter J Halls [mailto:P.Halls at york.ac.uk] 
> > Sent: Thursday, June 17, 2010 4:54 PM
> > To: randy
> > Subject: [!! SPAM] Re: [gdal-dev] problem on function "OGR_FD_GetName"
> > 
> > Randy,
> > 
> >     I've not worked with your platforms but, extrapolating from my 
> > Solaris(Sparc) environment ...
> > 
> >     GDAL uses Environment Variables as an alternative to the configure script 
> > parameter list.  I'm old fashioned here and prefer the parameter list, as I find 
> > it easier to debug.  Having said that, these control things like the compiler to 
> > use and the additional libraries to configure: I do not think any of these are 
> > likely to affect the way OGR_FD_GetName works.  Are you using the same hardware 
> > environment with different operating systems?  Has Configure correctly 
> > determined the hardware environment?  You can work through Config.status and 
> > Config.log to check this - if the two GDAL environments are supposed to be the 
> > same, can you diff these as a quick way of finding any differences?
> > 
> >     There are also a few Environment Variables involved at runtime eg PATH, 
> > LD_LIBRARY_PATH, ORACLE_HOME, TNS_ADMIN, and so on.  The last two control the 
> > Oracle interface; the first two affect loading a program at runtime.  If any of 
> > these are wrong, I would not expect execution to start or get as far as you 
> > have.  On that basis, I think it unlikely that you have an Environment variable 
> > problem.
> > 
> >     I presume that you are reading the same file on each platform?  The 'new' 
> > results you are reporting look to me as though the data definition is being 
> > reported instead of the feature name: could it be that you are effectively 
> > reading alternate lines?  Do you have a problem prior to calling OGR_FD_GetName 
> > that may be reading the next entry in the dataset to fulfil the input request 
> > and thus giving the impression of the incorrect feature name?  This could come 
> > back to the GDAL Configure results, prior to building GDAL.  [Did you transfer 
> > the GDAL source directory from one platform to the other?  If so, did you run a 
> > 'make clean' before building GDAL on the second, problematic platform?  It is 
> > possible for bits of an old configuration to 'linger' if the clean is not run ...]
> > 
> > Hoping there is something there that helps,
> > 
> > Best wishes,
> > 
> > Peter
> > 
> > -----------------------
> > 
>