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
> >
> > -----------------------
> >
>