Re: [gdal-dev] GDALOpenShared: warning about "filename" vs "description"

[chris english]

To my eye this looks like a very old 'warning' from Frank W's era,
where he was taming cats (user community) and dsn were, reasonably,
file names of a sort. Would overhead of regex comparing terminating
characters after final '/' meet the file name versus descriptor still
be useful? I imagine he was reacting to some many "I downloaded X and
now can't find it" (because it might have been renamed in process)
kinds of conditions, and the warning might trigger one to check. Just
an inkling on the annoyance.

On Sun, Apr 23, 2023 at 11:09 PM Michael Sumner  wrote:
>
>
> When invoking  info on this vrt connection
>
> gdalinfo 
> "vrt://https://herbariumnsw-pds.s3-ap-southeast-2.amazonaws.com/images/NSW041500.jp2?a_ullr=0,9661,7180,0;
>
> I see this warning
>
> Warning 6: A dataset opened by GDALOpenShared should have the same filename 
> (https://herbariumnsw-pds.s3-ap-southeast-2.amazonaws.com/images/NSW041500.jp2)
>  and description (/vsimem/http_1/NSW041500.jp2)
>
> The warning seems unreasonable given that we are quite far from a "filename" 
> for a dsn? There's no warning on the bare url or with /vsicurl:
>
> gdalinfo  
> https://herbariumnsw-pds.s3-ap-southeast-2.amazonaws.com/images/NSW041500.jp2
>
> gdalinfo  
> /vsicurl/https://herbariumnsw-pds.s3-ap-southeast-2.amazonaws.com/images/NSW041500.jp2
>
> ## GDAL version and provenance
>
> Ubuntu 20.04
>
> GDAL 3.7.0dev-717dcc0eed, released 2023/04/22 (debug build)
>
>
>
>
> --
> Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> Hobart, Australia
> e-mail: mdsum...@gmail.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CMAKE Report:[ 98%] Linking CXX executable pytest_runner; recompile with -fPIE/-fPIC

[chris english]

This following line say there was no python(3.6 in this case).so to compile
against found,
/usr/bin/ld: /usr/local/lib/libpython3.6m.a(pylifecycle.o): relocation
R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE
object; recompile with -fPIE

Reinstall python, ./configure --enable-shared # in this case python-3.6.9
from source (because mention of this version was deep in the CMake weeds),
and things go surprisingly smoothly.
git describe
v3.3.0-2898-gba4e7c404b

~/gdal$ gdalinfo --version
GDAL 3.5.0dev-ba4e7c404b, released 2022/02/28

DODS exclusion by turning both GDAL driver and OGR to OFF
Updated Netcdf, HDF4 & HDF5 - so stack improved there

I got so conditioned to out of tree builds that I tried it on the python
reinstall.
CMake, it's more than a build, it's an adventure.

Chris


On Sat, Mar 5, 2022 at 10:50 PM chris english 
wrote:

> This can't be a novel 'almost got there', but then not.
> [ 98%] Linking CXX executable pytest_runner
> /usr/bin/ld: /usr/local/lib/libpython3.6m.a(pylifecycle.o): relocation
> R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE
> object; recompile with -fPIE
> /usr/bin/ld: /usr/local/lib/libpython3.6m.a(pystate.o): relocation
> R_X86_64_32S against symbol `_PyEval_EvalFrameDefault' can not be used when
> making a PIE object; recompile with -fPIE
>
> In ubuntu-20.04, so have Python2.7, Python3.6, Python3.8, and 3.9, and
> generally advised against summarily removing any, so...they stay.
> Still working with git describe: v3.3.0-2898-gba4e7c404b
>
> I'd like to say -fPIE is probably -fPIC, but beyond that I don't know how
> to proceed.
> Previously, to get to here, eliminated all DODS, libdap, netcdf, mrsid
> references.
> Any help to get beyond 98% to 100% good news appreciated.
> Chris
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] crunch lib

[chris english]

I defer, though had the opposite experience and the DaemonEngine fork
seemed more recently maintained,
suggested to be the reason for their fork.

On Sun, Mar 6, 2022 at 1:31 PM Even Rouault 
wrote:

> Can you be more explicit of what does not work exactly ?
>
> - I've just tried https://github.com/DaemonEngine/crunch and it does
> build, but doesn't install headers or a library file, so can't be easily
> used by GDAL
>
> - I've just tried successfully the build instructions at
> https://gdal.org/drivers/raster/dds.html#build-crunch (for Linux), and
> then managed to build GDAL against it with "cmake ..
> -DCMAKE_PREFIX_PATH=/home/even/install-crunch"
>
> Even
>
> Le 04/03/2022 à 01:48, chris english a écrit :
> > https://github.com/DaemonEngine/crunch
> > appears to be a better source to point to for crunch, as it builds,
> > whereas crunch link in docs doesn't.
> > And builds for the hapless, as I believe I've demonstrated.
> > Chris
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

[chris english]

Noted. And it seems this reflects the generosity of the gdal/cmake find
process, that any pertinent libs found will be included on the premise that
if one went to the effort to have them, one must want them. And when no
longer needed, remove them, which most users neglect to do at their peril;
but, they are not long sighted Maintainers.

And there are those few GDAL/OGR couplets where both must be addressed, but
if the logic is that you can't do OGR but that you have GDAL
driver...though it seems that's neither the logic nor code, they are
separate, and both will be addressed.

On Sun, Mar 6, 2022 at 1:50 PM Even Rouault 
wrote:

>
> Le 05/03/2022 à 06:30, chris english a écrit :
>
> Kai,
> Rebuilt Geos with your insight, and two spaces between all -D entries,
> including eliminating MrSid that was complied under gcc 521 or so and might
> likely cause problems, using GDAL build hints
> <https://gdal.org/build_hints.html>, and we have success on on *target
> gcore_mdreader*, and I'll move on to sorting out what is wrong with
> missing symbols in whatever provides 'nc_open_mem', viz:
> [ 89%] Built target gcore_mdreader
> [ 89%] Linking CXX shared library libgdal.so
> /usr/bin/ld: frmts/netcdf/CMakeFiles/gdal_netCDF.dir/netcdfdataset.cpp.o:
> in function `netCDFDataset::Open(GDALOpenInfo*)':
> netcdfdataset.cpp:(.text+0x283d4): undefined reference to `nc_open_mem'
> /usr/bin/ld: netcdfdataset.cpp:(.text+0x2852a): undefined reference to
> `nc_open_mem'
>
> nc_open_mem is provided by the netCDF library. Your issue might come
> perharps from doing an initial cmake run with some netCDF version that
> includes that symbol , and re-running with an older one that hasn't it, and
> then cmake is confused becaused it has kept in cache that the netCDF lib
> has the nc_open_mem symbol. Removing CMakeCache.txt and re-running would
> solve it.
>
>
> Looks like updating libnetcdf...or perhaps not netcdf won't play nice
> with hdf5-1.12.1 till 4.9 dist release
> <https://github.com/Unidata/netcdf-c/issues/2166> so drop netcdf for now.
> And have to figure out turning off DODs, but wow, spotting a missing
> space, I'd have to perl that or something. But, have now arrived at:
>
> Which version of libdap do you use ? Note that support for DODS is likely
> to be dropped as we lack maintainers for it (see
> https://github.com/OSGeo/gdal/issues/5173)
>
>
> [ 86%] Built target gcore_mdreader
> [ 86%] Linking CXX shared library libgdal.so
> /usr/bin/ld: frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o: in
> function `get_variable(libdap::DDS&, std::__cxx11::basic_string std::char_traits, std::allocator > const&)':
> dodsdataset2.cpp:(.text+0x624): undefined reference to
> `libdap::www2id(std::__cxx11::basic_string,
> std::allocator > const&, std::__cxx11::basic_string std::char_traits, std::allocator > const&,
> std::__cxx11::basic_string,
> std::allocator > const&)'  <--snip
>
> and appears -DGDAL_ENABLE_DRIVER_DODS:BOOL=OFF is not doing it.
>
> That's weird... Note that there's also a OGR DODS driver, so to fully
> remove any DODS support -DOGR_ENABLE_DRIVER_DODS:BOOL=OFF would be needed
> too
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CMAKE poppler c++17

[chris english]

I will follow your lead locally and comment out the GCC version check as
MrSid is useful, and perhaps Maintainer to Maintainer
would have more effect over at LizardTech. And apologies for inflicting
this on your work email threads.

I noted a desire to get feedback in anticipation of the CMAKE
transition/requirement, and these are one person's prat falls.
Halfway through a python .so testing now (hadn't given much thought to 'Do
I have a python .so?' as I've been building gdal since 1.10.1,
and all gdal tools have worked- so what? me worry?).

I think the -DODs transition could be a little smoother as it creates a
head scratch, what to do about dap and netcdf, and am a little discouraged
by the -D use deprecated approach as it seems =NO, rather than =YES,
doesn't unentangle DODS from dap and netcdf, but don't anticipate needing
them again for a little while so will see how it develops.

Anyway, at the end, I hope to both be successful, note the things one must
be mindful of in anticipation of using cmake (like having a python.so &
etc), as this has really forced me to come to grips with cmake, and why it
would be advantageous both to users as maintainers.

Thanks again for the MrSid tip.
Chris


On Sun, Mar 6, 2022 at 1:42 PM Even Rouault 
wrote:

> | Thereafter, MrSid driver cratered on some 2004 Lizardtech defines in
> lt_platform.h that defined possible GCC compilers topping out at <= 5
> (rather than a future unimaginable 9 or 12). Removing a desire for MrSid,
> in this instance through ccmake,
>
> That's completely unrelated to building GDAL through autoconf or cmake.
> This is an issue with the LizardTech SDK that indeed remains stuck to
> ancient GCC versions
>
> I see I locally patched line 40 of lt_platform.h to remove the GCC version
> check, and then things go flawlessly
>
> #if (defined(__GNUC__) || defined(__GNUG__)) // && (3 <= __GNUC__ &&
> __GNUC__ <= 5)
>
> I've just tried to submit this issue to their support service.
>
> Even
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] CMAKE Report:[ 98%] Linking CXX executable pytest_runner; recompile with -fPIE/-fPIC

[chris english]

This can't be a novel 'almost got there', but then not.
[ 98%] Linking CXX executable pytest_runner
/usr/bin/ld: /usr/local/lib/libpython3.6m.a(pylifecycle.o): relocation
R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE
object; recompile with -fPIE
/usr/bin/ld: /usr/local/lib/libpython3.6m.a(pystate.o): relocation
R_X86_64_32S against symbol `_PyEval_EvalFrameDefault' can not be used when
making a PIE object; recompile with -fPIE

In ubuntu-20.04, so have Python2.7, Python3.6, Python3.8, and 3.9, and
generally advised against summarily removing any, so...they stay.
Still working with git describe: v3.3.0-2898-gba4e7c404b

I'd like to say -fPIE is probably -fPIC, but beyond that I don't know how
to proceed.
Previously, to get to here, eliminated all DODS, libdap, netcdf, mrsid
references.
Any help to get beyond 98% to 100% good news appreciated.
Chris
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

[chris english]

Kai,
Rebuilt Geos with your insight, and two spaces between all -D entries,
including eliminating MrSid that was complied under gcc 521 or so and might
likely cause problems, using GDAL build hints
, and we have success on on *target
gcore_mdreader*, and I'll move on to sorting out what is wrong with missing
symbols in whatever provides 'nc_open_mem', viz:
[ 89%] Built target gcore_mdreader
[ 89%] Linking CXX shared library libgdal.so
/usr/bin/ld: frmts/netcdf/CMakeFiles/gdal_netCDF.dir/netcdfdataset.cpp.o:
in function `netCDFDataset::Open(GDALOpenInfo*)':
netcdfdataset.cpp:(.text+0x283d4): undefined reference to `nc_open_mem'
/usr/bin/ld: netcdfdataset.cpp:(.text+0x2852a): undefined reference to
`nc_open_mem'

Looks like updating libnetcdf...or perhaps not netcdf won't play nice with
hdf5-1.12.1 till 4.9 dist release
 so drop netcdf for now.
And have to figure out turning off DODs, but wow, spotting a missing space,
I'd have to perl that or something. But, have now arrived at:

[ 86%] Built target gcore_mdreader
[ 86%] Linking CXX shared library libgdal.so
/usr/bin/ld: frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o: in
function `get_variable(libdap::DDS&, std::__cxx11::basic_string, std::allocator > const&)':
dodsdataset2.cpp:(.text+0x624): undefined reference to
`libdap::www2id(std::__cxx11::basic_string,
std::allocator > const&, std::__cxx11::basic_string, std::allocator > const&,
std::__cxx11::basic_string,
std::allocator > const&)'  <--snip

and appears -DGDAL_ENABLE_DRIVER_DODS:BOOL=OFF is not doing it. So,
continuing.
Thanks again.



On Fri, Mar 4, 2022 at 2:26 PM  wrote:

> It looks like you missed a " " after -DCMAKE_BUILD_TYPE=Release when
> configuring GEOS:
>
> > set_property(TARGET GEOS::geos APPEND PROPERTY IMPORTED_CONFIGURATIONS
> RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL)
>
> Kai.
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

[chris english]

This generated file, local.cmake, seems to suggest that the build should
still be pointing (GEOS_DIR) /usr/local/lib/cmake/GEOS, but
GEOS::geos_c location still doesn't get set.
#
# Generated CMake target import file for configuration
"Release-DCMAKE_INSTALL_PREFIX=/usr/local".
#

# Commands may need to know the format version.
set(CMAKE_IMPORT_FILE_VERSION 1)

# Import target "GEOS::geos" for configuration
"Release-DCMAKE_INSTALL_PREFIX=/usr/local"
set_property(TARGET GEOS::geos APPEND PROPERTY IMPORTED_CONFIGURATIONS
RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL)
set_target_properties(GEOS::geos PROPERTIES
  IMPORTED_LOCATION_RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL
"${_IMPORT_PREFIX}/lib/libgeos.so.3.10.2"
  IMPORTED_SONAME_RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL
"libgeos.so.3.10.2"
  )

list(APPEND _IMPORT_CHECK_TARGETS GEOS::geos )
list(APPEND _IMPORT_CHECK_FILES_FOR_GEOS::geos
"${_IMPORT_PREFIX}/lib/libgeos.so.3.10.2" )

# Import target "GEOS::geos_c" for configuration
"Release-DCMAKE_INSTALL_PREFIX=/usr/local"
set_property(TARGET GEOS::geos_c APPEND PROPERTY IMPORTED_CONFIGURATIONS
RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL)
set_target_properties(GEOS::geos_c PROPERTIES

IMPORTED_LINK_DEPENDENT_LIBRARIES_RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL
"GEOS::geos"
  IMPORTED_LOCATION_RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL
"${_IMPORT_PREFIX}/lib/libgeos_c.so.1.16.0"
  IMPORTED_SONAME_RELEASE-DCMAKE_INSTALL_PREFIX=/USR/LOCAL "libgeos_c.so.1"
  )

list(APPEND _IMPORT_CHECK_TARGETS GEOS::geos_c )
list(APPEND _IMPORT_CHECK_FILES_FOR_GEOS::geos_c
"${_IMPORT_PREFIX}/lib/libgeos_c.so.1.16.0" )

# Commands beyond this point should not need to know the version.
set(CMAKE_IMPORT_FILE_VERSION)

On Fri, Mar 4, 2022 at 2:02 PM chris english 
wrote:

> Concerning (executed in either git download directory or build):
> ~/gdal$ git describe
> v3.3.0-2898-gba4e7c404b
>
> Condition: was building and stopped with
> [ 89%] Built target gcore_mdreader
> CMakeFiles/GDAL.dir/build.make:2661: *** target pattern contains no '%'.
> Stop.
> make[1]: *** [CMakeFiles/Makefile2:4871: CMakeFiles/GDAL.dir/all] Error 2
> make: *** [Makefile:146: all] Error 2
>
> As we were building objects in gcore, the
> 'CMakeFiles/GDAL.dir/build.make:2661:'
> refers to ~/gdal/build/gcore/CMakeFiles/GDAL.dir/build.make, line 2661
> that is in the neighborhood of a problem at line 2667:
> GEOS::geos_c-NOT FOUND
> Well, that could be bad, and says the problem is local rather than with
> the git.
> Perhaps a sudo ldconfig is called for. Done.
> In ~/gdal/build rm CMakeCache.txt
> Run cmake .. again
> Copy and paste all output to editor and down at bottom find
> IMPORTED_LOCATION not set for imported target "GEOS::geos_c" configuration
>   "Release".
> OK, so not something that ldconfig fixes. Pass in libgeos...how?
> Resorting to ccmake ..
> Pg 25 of 44
> GEOS_DIR  /usr/local/lib/cmake/GEOS
> contains:
> ls /usr/local/lib/cmake/GEOS
> geos-config.cmake  geos-config-version.cmake  geos-targets.cmake
>  local.cmake
> So, nothing looking very useful, change to /usr/local/lib and try again
> change to /usr/local/lib/libgeos_c.so
> And try:
> build$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local
> -DCMAKE_BUILD_TYPE=Release -DGEOS_DIR=/usr/local/lib/libgeos_c
> And finally, this is where I am stuck.
> Chris
>
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Attempting a coherent CMAKE problem report from a git clone- steps taken

[chris english]

Concerning (executed in either git download directory or build):
~/gdal$ git describe
v3.3.0-2898-gba4e7c404b

Condition: was building and stopped with
[ 89%] Built target gcore_mdreader
CMakeFiles/GDAL.dir/build.make:2661: *** target pattern contains no '%'.
Stop.
make[1]: *** [CMakeFiles/Makefile2:4871: CMakeFiles/GDAL.dir/all] Error 2
make: *** [Makefile:146: all] Error 2

As we were building objects in gcore, the
'CMakeFiles/GDAL.dir/build.make:2661:'
refers to ~/gdal/build/gcore/CMakeFiles/GDAL.dir/build.make, line 2661 that
is in the neighborhood of a problem at line 2667:
GEOS::geos_c-NOT FOUND
Well, that could be bad, and says the problem is local rather than with the
git.
Perhaps a sudo ldconfig is called for. Done.
In ~/gdal/build rm CMakeCache.txt
Run cmake .. again
Copy and paste all output to editor and down at bottom find
IMPORTED_LOCATION not set for imported target "GEOS::geos_c" configuration
  "Release".
OK, so not something that ldconfig fixes. Pass in libgeos...how?
Resorting to ccmake ..
Pg 25 of 44
GEOS_DIR  /usr/local/lib/cmake/GEOS
contains:
ls /usr/local/lib/cmake/GEOS
geos-config.cmake  geos-config-version.cmake  geos-targets.cmake
 local.cmake
So, nothing looking very useful, change to /usr/local/lib and try again
change to /usr/local/lib/libgeos_c.so
And try:
build$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local
-DCMAKE_BUILD_TYPE=Release -DGEOS_DIR=/usr/local/lib/libgeos_c
And finally, this is where I am stuck.
Chris
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] crunch lib

[chris english]

https://github.com/DaemonEngine/crunch
appears to be a better source to point to for crunch, as it builds, whereas
crunch link in docs doesn't.
And builds for the hapless, as I believe I've demonstrated.
Chris
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] CMAKE [ 89%] Built target gcore_mdreader *** target pattern contains no '%'

[chris english]

This subject line is a mash up of this:

[ 89%] Built target gcore_mdreader
CMakeFiles/GDAL.dir/build.make:2661: *** target pattern contains no '%'.
Stop.
make[1]: *** [CMakeFiles/Makefile2:4871: CMakeFiles/GDAL.dir/all] Error 2

and hereafter I have no idea of how to proceed. I've previously dispensed
with other recalcitrant drivers (MrSid), can I do the same with target
'gcore' without the world collapsing upon me and would my functionality be
greatly reduced.?

Chris
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] CMAKE poppler c++17

[chris english]

Thanks Jeff.
Process details matter, I missed that Poppler source was actually at gitlab
rather than my github based clone, so rebuilt poppler, using CMAKE this
time.
[100%] Built target poppler-render
Install the project...
-- Install configuration: "Release"
-- Installing: /usr/local/lib/libpoppler.so.119.0.0
-- Up-to-date: /usr/local/lib/libpoppler.so.119
-- Set runtime path of "/usr/local/lib/libpoppler.so.119.0.0" to
"/usr/local/lib"

which in the context of the patch 089f84b:
if ("${POPPLER_VERSION_MINOR}" MATCHES "0?[0-9]+")
string(REGEX REPLACE "0?([0-9]+)" "\\1" POPPLER_VERSION_MINOR
${POPPLER_VERSION_MINOR})
endif ()
if (POPPLER_VERSION_MAJOR GREATER 21)
target_compile_features(gdal_PDF PRIVATE cxx_std_17)
endif ()
target_compile_definitions(gdal_PDF PRIVATE -DHAVE_POPPLER
-DPOPPLER_MAJOR_VERSION=${POPPLER_VERSION_MAJOR}
-DPOPPLER_MINOR_VERSION=${POPPLER_VERSION_MINOR})
endif ()

and happily, 119 remains > 21, so poppler patch 089f84b worked.
Thereafter, MrSid driver cratered on some 2004 Lizardtech defines in
lt_platform.h that defined possible GCC compilers topping out at <= 5
(rather than a future unimaginable 9 or 12). Removing a desire for MrSid,
in this instance through ccmake,
Re-clone gdal and we get to this, new, somewhat indecipherable, not quite
there, but achingly close:
[ 89%] Building CXX object
gcore/mdreader/CMakeFiles/gcore_mdreader.dir/reader_spot.cpp.o
[ 89%] Built target gcore_mdreader
CMakeFiles/GDAL.dir/build.make:2661: *** target pattern contains no '%'.
Stop.
make[1]: *** [CMakeFiles/Makefile2:4871: CMakeFiles/GDAL.dir/all] Error 2

And from there I guess I will attempt to chug along.

Losing MrSid is a disappointment as the earliest USGS experimental
photogrammetry data available, albeit without sufficient viable GPCs (for
local areas as many were lost through time), was predicated on coastal
overflights related to beach erosion control efforts/federal expenses from
100 years ago. To my view, sufficient GPCs still exist within and across
the dataset, that it could serve as an historic measure, with an
appropriate eye toward the geographic basis that remaining GPCs indicate.
But it will no longer be local area, though that is what a certain client
wants.

Happily, or unhappily, my above error reveals some 8 google responses, with
none censored to show most relevant.

And, as CMAKE is our fate, and gdal is our best tool, we will endeavor to
persevere, so we can also get sf in R to load again.

Chris


On Thu, Mar 3, 2022 at 3:26 PM Jeff McKenna 
wrote:

> Hi Chris,
>
> I'm not sure if this is exactly related to your issue, but here are my
> thoughts:
>
> I do know that the recent poppler release relies on the C++17 standard,
> and there was a recent change in GDAL to accommodate this (see
> https://github.com/OSGeo/gdal/issues/5071 ).
>
> In my case (for the Windows / MS4W community) I had to patch GDAL 3.4.1
> for this, but in your case you might want to grab GDAL-master from git
> as that will be easier to handle the new poppler.
>
>
> -jeff
>
>
>
> --
> Jeff McKenna
> GatewayGeo: Developers of MS4W, MapServer Consulting and Training
> co-founder of FOSS4G
> http://gatewaygeo.com/
>
>
>
>
> On 2022-03-03 4:03 p.m., chris english wrote:
> > Hi,
> > I am a weak link when it comes to CMAKE. Geos-3.10.2 and PROJ-8.2.1 were
> > a breeze nonetheless.  A source build of libpoppler.so.119 via
> > ./configure went smoothly.
> >
> > I have consistently failed at ogrpdflayer (well, only four times so far)
> > on 'optional', that is a C++17 thing. <-  an example of a feeble
> > understanding of build process requirements.
> >
> > Recklessly editing lines in CMakeLists.txt:
> > 41 # check compiler and set preferences.
> > 42 set(CMAKE_CXX_STANDARD 17)
> > [ 44%] Built target gdal_STACIT
> > [ 44%] Building CXX object
> > frmts/pdf/CMakeFiles/gdal_PDF.dir/ogrpdflayer.cpp.o
> >
> > but further along we run across c++17 be contra-indicated as to
> >
> > [ 49%] Built target gdal_PostGISRaster
> > [ 49%] Building CXX object
> > frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o
> >
> > from /home/chris/gdal/frmts/dods/dodsdataset2.cpp:38:
> > /usr/local/include/libdap/RCReader.h:114:16: error: ISO C++17 does not
> > allow dynamic exception specifications
> >114 | RCReader() throw(Error);
> >
> > which leads to a set by individual target approach as is said to be
> > available
> >
> > set_property(TARGETtgtPROPERTYCXX_STANDARD17)
> > set_property(TARGETtgtPROPERTYCXX_STANDARD11)
> >
> > and were this the solution, what would it look like and where might it
> > reside in say
>

[gdal-dev] CMAKE poppler c++17

[chris english]

Hi,
I am a weak link when it comes to CMAKE. Geos-3.10.2 and PROJ-8.2.1 were a
breeze nonetheless.  A source build of libpoppler.so.119 via ./configure
went smoothly.

I have consistently failed at ogrpdflayer (well, only four times so far) on
'optional', that is a C++17 thing. <-  an example of a feeble understanding
of build process requirements.

Recklessly editing lines in CMakeLists.txt:
41 # check compiler and set preferences.
42 set(CMAKE_CXX_STANDARD 17)
[ 44%] Built target gdal_STACIT
[ 44%] Building CXX object
frmts/pdf/CMakeFiles/gdal_PDF.dir/ogrpdflayer.cpp.o

but further along we run across c++17 be contra-indicated as to

[ 49%] Built target gdal_PostGISRaster
[ 49%] Building CXX object
frmts/dods/CMakeFiles/gdal_DODS.dir/dodsdataset2.cpp.o

from /home/chris/gdal/frmts/dods/dodsdataset2.cpp:38:
/usr/local/include/libdap/RCReader.h:114:16: error: ISO C++17 does not
allow dynamic exception specifications
  114 | RCReader() throw(Error);

which leads to a set by individual target approach as is said to be
available

set_property(TARGET tgt PROPERTY CXX_STANDARD 17)
set_property(TARGET tgt PROPERTY CXX_STANDARD 11)

and were this the solution, what would it look like and where might it
reside in say

CMakeCache.txt, or have I just gotten this all wrong, as I expect I have.

Ubuntu 20.04, gcc-9.3.0, and happy to have broken through to 49%, but wouldn't

that's 99% good news.

Chris
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] building gdal-3.3.0-dev with proj free(): invalid pointer

[chris english]

Hi.

Been building and rebuilding gdal-3.3.0-dev and arrive at this output:

chris@jacie:~$ gdalinfo --version
GDAL 3.3.0dev-96fab634a5, released 2021/03/02
free(): invalid pointer
Aborted

two version of libproj are involved:

chris@jacie:~$ ldd /usr/local/bin/gdalinfo | grep libproj
libproj.so.22 => /usr/local/lib/libproj.so.22 (0x7f3a6cecc000)
libproj.so.19 => /usr/local/lib/libproj.so.19 (0x7f3a659da000)

This is because when built with libproj.so.22 only, gdalinfo complained
libproj.so.19 couldn't be loaded on attempting to execute. libproj.so.22 is
in /usr/local and prjo.h is from libproj.so.22, also in /usr/local. 19 is
ln from /usr/local/lib.
in gdb I get:

gdb) set substitute-path /build/glibc-eX1tMB/glibc-2.31
/home/chris/glibc-2.31
(gdb) frame 1
#1  0x7f8b2a4a3859 in __GI_abort () at abort.c:79
79  raise (SIGABRT);
(gdb) frame 2
#2  0x7f8b2a50e3ee in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x7f8b2a638285 "%s\n") at
../sysdeps/posix/libc_fatal.c:155
155abort ();
(gdb) frame 3
#3  0x7f8b2a51647c in malloc_printerr (
str=str@entry=0x7f8b2a6364ae "free(): invalid pointer") at malloc.c:5347
5347  __libc_message (do_abort, "%s\n", str);
(gdb) frame 4
#4  0x7f8b2a517cac in _int_free (av=, p=,
have_lock=0) at malloc.c:4173
4173malloc_printerr ("free(): invalid pointer");
(gdb) frame 5
#5  0x7f8b27035480 in __gnu_cxx::new_allocator::deallocate (
this=0x557019391ff0, __p=)
at /usr/include/c++/9/ext/new_allocator.h:119
119  deallocate(pointer __p, size_type)
(gdb) frame 6
#6  std::allocator_traits >::deallocate (__a=...,
__n=, __p=)
at /usr/include/c++/9/bits/alloc_traits.h:470
470  { __a.deallocate(__p, __n); }
(gdb) frame 7
#7  std::__cxx11::basic_string,
std::allocator >::_M_destroy (__size=,
this=0x557019391ff0)
at /usr/include/c++/9/bits/basic_string.h:237
237  { _Alloc_traits::deallocate(_M_get_allocator(), _M_data(), __size
+ 1); }
(gdb) frame 8
#8  std::__cxx11::basic_string,
std::allocator >::_M_dispose (this=0x557019391ff0)
at /usr/include/c++/9/bits/basic_string.h:232
232  _M_destroy(_M_allocated_capacity);
(gdb) frame 9
#9  std::__cxx11::basic_string,
std::allocator >::~basic_string (this=0x557019391ff0,
__in_chrg=)
at /usr/include/c++/9/bits/basic_string.h:658
658  { _M_dispose(); }
(gdb) frame 10
#10 osgeo::proj::common::UnitOfMeasure::Private::~Private (
this=0x557019391ff0, __in_chrg=) at
iso19111/common.cpp:72
72 struct UnitOfMeasure::Private {
(gdb) frame 11
#11
std::default_delete::operator()
(this=0x7f8b272e1f60 ,
__ptr=0x557019391ff0) at /usr/include/c++/9/bits/unique_ptr.h:81
81 delete __ptr;
(gdb) frame 12
#12 std::unique_ptr
>::~unique_ptr (
this=0x7f8b272e1f60
,
__in_chrg=) at /usr/include/c++/9/bits/unique_ptr.h:292
292  get_deleter()(std::move(__ptr));
(gdb) frame 13
#13 osgeo::proj::common::UnitOfMeasure::~UnitOfMeasure (
this=0x7f8b272e1f50 ,
__in_chrg=) at ../include/proj/common.hpp:60
60 class PROJ_GCC_DLL UnitOfMeasure : public util::BaseObject {
(gdb) frame 14
#14 0x7f8b2a4c815e in __cxa_finalize (d=0x7f8b1fdec720)
at cxa_finalize.c:83
83cxafn (cxaarg, 0);
(gdb) frame 15
#15 0x7f8b1fb399b7 in __do_global_dtors_aux ()
   from /usr/local/lib/libproj.so.19
(gdb) frame 16
#16 0x7ffe33879550 in ?? ()
(gdb) frame 17
#17 0x7f8b2d55ef5b in _dl_fini () at dl-fini.c:138
138((fini_t) array[i]) ();

Haven't been able to further clarify frame 16 function call. Which I guess
would be useful. Any thoughts on how to proceed greatly appreciated.

Chris
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fema Flood Maps NAV88 - proj4text

[Chris English]

Just to close this out,
New York New Jersey FEMA advisory Base Flood Elevations are ESPG:3857

 From: sgl...@hotmail.com
 To: g...@ir.bbn.com; gdal-dev@lists.osgeo.org
 Date: Sat, 2 Feb 2013 11:39:23 -0500
 Subject: Re: [gdal-dev] Fema Flood Maps NAV88 - proj4text
 
 
 The parcels are, of course, horizontal only datum.
 from the .prj
 
 PROJCS[NAD_1983_StatePlane_New_Jersey_FIPS_2900_Feet,
 GEOGCS[GCS_North_American_1983,
 DATUM[D_North_American_1983,SPHEROID[GRS_1980,6378137.0,298.257222101]],
 PRIMEM[Greenwich,0.0],UNIT[Degree,0.0174532925199433]],
 PROJECTION[Transverse_Mercator],PARAMETER[False_Easting,492125.0],
 PARAMETER[False_Northing,0.0],PARAMETER[Central_Meridian,-74.5],
 PARAMETER[Scale_Factor,0.],
 PARAMETER[Latitude_Of_Origin,38.84],UNIT[Foot_US,0.3048006096012192]]
 
 and from a representative flood map .prj
 
 PROJCS[WGS_1984_Web_Mercator_Auxiliary_Sphere,GEOGCS[GCS_WGS_1984,
 DATUM[D_WGS_1984,SPHEROID[WGS_1984,6378137.0,298.257223563]],
 PRIMEM[Greenwich,0.0],UNIT[Degree,0.0174532925199433]],
 PROJECTION[Mercator_Auxiliary_Sphere],PARAMETER[False_Easting,0.0],
 PARAMETER[False_Northing,0.0],PARAMETER[Central_Meridian,0.0],
 PARAMETER[Standard_Parallel_1,0.0],PARAMETER[Auxiliary_Sphere_Type,0.0],UNIT[Meter,1.0]]
 
 which seems now, looking at them, should just be a standard transform. But 
 then this from
 Adv_MO_FloodZones.shp.xml 
 
 -geodetic
 horizdnGCS WGS 1984/horizdn
 ellipsWorld Geodetic System 1984/ellips
 semiaxis6378137.00/semiaxis
 denflat298.257222/denflat
 /geodetic
 /horizsys
 vertsys
 gridsysnNAVD88/gridsysn
 planduFEET/plandu
 /vertsys
 
 well, I'll continue to muddle and head scratch.
 
  From: g...@ir.bbn.com
  To: sgl...@hotmail.com
  CC: gdal-dev@lists.osgeo.org
  Subject: Re: [gdal-dev] Fema Flood Maps NAV88 - proj4text
  Date: Sat, 2 Feb 2013 08:21:11 -0500
 
 
  You may want to join the proj list.
 
  Your parcel maps are in EPSG (ESRI, really) 102711, which is:
 
  http://spatialreference.org/ref/esri/102711/
 
  This is a horizontal-only datum. I have only encountered horizontal
  data in parcel maps (Mass, not NJ). Do you have any heights presented
  with this? If so, do you understand what they are? If there are
  heights, I would expect they are in NAVD88, but they could be in
  ellipsoidal height relative to the GRS80 ellipsoid and the NAD83
  orientation. Ellipsoidal height is relatively recent, and estimated
  orthometric heights based on geoid models and observed ellispoidal
  heights is where NGS is heading, but I would doubt most practitioners
  are doing that yet.
 
  Your flood maps are in EPSG:5703:
  http://spatialreference.org/ref/epsg/5703/
  This is a vertical-only datum. Are there horizontal coordinates? If
  so, what are they in? I would expect some sort of NAD83, and their
  purpose is to locate where the heights are given.
 
  So what I think you want is to know the NAVD88 heights around the parcel
  of interest, so you therefore want all your horizontal coordinates in
  NAD83, and to leave the height in NAVD88. (Water flows downhill in
  NAVD88, but does not necessarily flow towards lower height values in
  ellipsoidal height coordinates!!)
 
  You were talking about a geoid file, which presumably transforms NAVD88
  height to something, which is probably ellipsoidal height based on
  NAD83. That's the typical geoid model published by NGS.
  There are also geoid models from WGS84 ellipsoidal height, but these do
  not transform to NAVD88.
 
  Do you have any height data in other than NAVD88? If so, please
  describe it.
 
 ___
 gdal-dev mailing list
 gdal-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/gdal-dev

  ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fema Flood Maps NAV88 - proj4text

[Chris English]

The parcels are, of course, horizontal only datum.
from the .prj

PROJCS[NAD_1983_StatePlane_New_Jersey_FIPS_2900_Feet,
GEOGCS[GCS_North_American_1983,
DATUM[D_North_American_1983,SPHEROID[GRS_1980,6378137.0,298.257222101]],
PRIMEM[Greenwich,0.0],UNIT[Degree,0.0174532925199433]],
PROJECTION[Transverse_Mercator],PARAMETER[False_Easting,492125.0],
PARAMETER[False_Northing,0.0],PARAMETER[Central_Meridian,-74.5],
PARAMETER[Scale_Factor,0.],
PARAMETER[Latitude_Of_Origin,38.84],UNIT[Foot_US,0.3048006096012192]]

and from a representative flood map .prj

PROJCS[WGS_1984_Web_Mercator_Auxiliary_Sphere,GEOGCS[GCS_WGS_1984,
DATUM[D_WGS_1984,SPHEROID[WGS_1984,6378137.0,298.257223563]],
PRIMEM[Greenwich,0.0],UNIT[Degree,0.0174532925199433]],
PROJECTION[Mercator_Auxiliary_Sphere],PARAMETER[False_Easting,0.0],
PARAMETER[False_Northing,0.0],PARAMETER[Central_Meridian,0.0],
PARAMETER[Standard_Parallel_1,0.0],PARAMETER[Auxiliary_Sphere_Type,0.0],UNIT[Meter,1.0]]

which seems now, looking at them, should just be a standard transform. But then 
this from
Adv_MO_FloodZones.shp.xml 

-geodetic
horizdnGCS WGS 1984/horizdn
ellipsWorld Geodetic System 1984/ellips
semiaxis6378137.00/semiaxis
denflat298.257222/denflat
/geodetic
/horizsys
vertsys
    gridsysnNAVD88/gridsysn
    planduFEET/plandu
/vertsys

well, I'll continue to muddle and head scratch.

 From: g...@ir.bbn.com
 To: sgl...@hotmail.com
 CC: gdal-dev@lists.osgeo.org
 Subject: Re: [gdal-dev] Fema Flood Maps NAV88 - proj4text
 Date: Sat, 2 Feb 2013 08:21:11 -0500


 You may want to join the proj list.

 Your parcel maps are in EPSG (ESRI, really) 102711, which is:

 http://spatialreference.org/ref/esri/102711/

 This is a horizontal-only datum. I have only encountered horizontal
 data in parcel maps (Mass, not NJ). Do you have any heights presented
 with this? If so, do you understand what they are? If there are
 heights, I would expect they are in NAVD88, but they could be in
 ellipsoidal height relative to the GRS80 ellipsoid and the NAD83
 orientation. Ellipsoidal height is relatively recent, and estimated
 orthometric heights based on geoid models and observed ellispoidal
 heights is where NGS is heading, but I would doubt most practitioners
 are doing that yet.

 Your flood maps are in EPSG:5703:
 http://spatialreference.org/ref/epsg/5703/
 This is a vertical-only datum. Are there horizontal coordinates? If
 so, what are they in? I would expect some sort of NAD83, and their
 purpose is to locate where the heights are given.

 So what I think you want is to know the NAVD88 heights around the parcel
 of interest, so you therefore want all your horizontal coordinates in
 NAD83, and to leave the height in NAVD88. (Water flows downhill in
 NAVD88, but does not necessarily flow towards lower height values in
 ellipsoidal height coordinates!!)

 You were talking about a geoid file, which presumably transforms NAVD88
 height to something, which is probably ellipsoidal height based on
 NAD83. That's the typical geoid model published by NGS.
 There are also geoid models from WGS84 ellipsoidal height, but these do
 not transform to NAVD88.

 Do you have any height data in other than NAVD88? If so, please
 describe it.
  
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Fema Flood Maps NAV88 - proj4text

[Chris English]

All,

I am trying to view some parcel maps (NJ state plane EPSG 102711) in conjunction
with FEMA Flood maps (EPSG 5703).  I can view one group, the compliment of FEMA
Flood maps, or the parcels, but not both, so clearly a transform is required.

I find myself looking for a proj4 text string for EPSG 5703 to (hopefully) 
transform in
PostGIS and view in qgis.  

I found this string proj=longlat +datum=WGS84 +no_defs 
+geoidgrids=g2009conus.gtx

in Ben Discoe's overview of Vertical and Geocentric coordinate support in 
OGR/Proj4
http://lists.maptools.org/pipermail/proj/2011-August/005844.html

and I've added g2009conus.gtx to my PROJ_LIB.

1) is the string the correct proj4 string for NAV88D

2) am I being hopelessly naive to think that just adding the string to a 
user-defined
    95703 in Postgis spatial_ref_sys is going to do anything useful to achieve 
the
    transform of the parcel maps so they may be viewed in conjunction with the
    FEMA maps

3) if 2 is correct, should I prepare the layer in gdal following Ben's approach
    and then import into Postgis

I am attempting this because when one is confronted with a flood map one wants
to know what is the elevation of one's particular parcel in relation the the 
flood maps
as against the more generalized representation of the flood zone stops about 
here.

thank you for your advice and consideration,

Chris English
  
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] SetUTM - how to say how far north Python

[Chris English]

Hi,
Assuming the following:
 src_ds = gdal.Open('test_3.ter') dst_ds = 
 driver.CreateCopy('test_6.hf2', src_ds, 0) 
 dst_ds.SetGeoTransform([582495,1,0.5,4512717,0.5,-1])0 srs = 
 osr.SpatialReference() srs.SetUTM(18,1)0 
 srs.SetWellKnownGeogCS('WGS84')0 dst_ds.SetProjection( 
 srs.ExportToWkt())0 dst_ds = None src_ds = None 
 gdalinfo.main(['foo','test_6.hf2'])Driver: HF2/HF2/HFZ heightfield 
 rasterFiles: test_6.hf2   test_6.hf2.aux.xmlSize is 4, 4Coordinate 
 System is:PROJCS[UTM Zone 18, Northern Hemisphere,GEOGCS[WGS 84,
 DATUM[WGS_1984,SPHEROID[WGS 84,6378137,298.257223563,   
  AUTHORITY[EPSG,7030]],TOWGS84[0,0,0,0,0,0,0],  
   AUTHORITY[EPSG,6326]],PRIMEM[Greenwich,0,   
  AUTHORITY[EPSG,8901]],UNIT[degree,0.0174532925199433,
 AUTHORITY[EPSG,9108]],AUTHORITY[EPSG,4326]],
 PROJECTION[Transverse_Mercator],PARAMETER[latitude_of_origin,0],
 PARAMETER[central_meridian,-75],PARAMETER[scale_factor,0.9996],
 PARAMETER[false_easting,50],PARAMETER[false_northing,0],
 UNIT[Meter,1]]Origin = (0.000,0.000)Pixel Size = 
 (1.000,1.000)Metadata:  
 VERTICAL_PRECISION=1.00Corner Coordinates:Upper Left  (   0.000,   
 0.000) ( 79d29'19.48W,  0d 0' 0.01N)Lower Left  (   0.000,   
 4.000) ( 79d29'19.48W,  0d 0' 0.13N)Upper Right (   4.000,   
 0.000) ( 79d29'19.35W,  0d 0' 0.01N)Lower Right (   4.000,   
 4.000) ( 79d29'19.35W,  0d 0' 0.13N)Center  (   2.000,   
 2.000) ( 79d29'19.41W,  0d 0' 0.06N)Band 1 Block=256x1 Type=Float32, 
 ColorInterp=Undefined  Unit Type: m0 
and assuming I wanted to be nearly in New York rather than La Concordia 
Peru,how to say 'how far north'?
Thanks in advance,
Chris ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Python syntax for Terragen band::SetUnitType()

[Chris English]

Hi,
What is the proper Python syntax for SetUnitType(m) for Terragen ?
 type(dst_ds)class 'osgeo.gdal.Dataset'
The dataset (Terragen) exists, and (I think) in order for the 
MIN/MAXUSERPIXELVALUESto make sense it seems you'd have to SetUnitType() prior 
to WritingArrayin the same way you'd establish SetGeoTransform()  etc before 
WriteArray.
dst_ds.SetGeoTransform ~


Thank you for you assistance.chris


  
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] VPF - Failure fetching requested layer OGDI

[Chris English]

On Windows:
I'm trying to build some shape files from VPF files using OGDI in 
FWTools-2.4.7,I finally got my gltp:/vrf/  going and that resulted in:
C:\gisdata\vdu\software\um\DNC16ogrinfo  
gltp:/vrf/gisdata/vdu/software/um/DNC16/a160ERROR 4: OGDI Driver doesn't 
support update.Had to open data source read-only.INFO: Open of 
`gltp:/vrf/gisdata/vdu/software/um/DNC16/a160'  using driver `OGDI' 
successful.1: landm...@cul(*)_area (Polygon)2: tra...@cul(*)_area (Polygon)3: 
tra...@cul(*)_line (Line String)4: build...@cul(*)_point (Point)5: 
built...@cul(*)_point (Point)6: co...@cul(*)_point (Point)7: 
indu...@cul(*)_point (Point)8: ecra...@ecr(*)_area (Polygon)9: 
fores...@ecr(*)_area (Polygon)10: coa...@ecr(*)_line (Line String)11: 
isla...@ecr(*)_point (Point)...32: dang...@obs(*)_area (Polygon)33: 
haza...@obs(*)_area (Polygon)34: re...@obs(*)_area (Polygon)35: 
rui...@obs(*)_area (Polygon)36: brid...@obs(*)_line (Line String)37: 
haza...@obs(*)_line (Line String)38: pipel...@obs(*)_line (Line String)39: 
dang...@obs(*)_point (Point)...
Going for more specifics at the layer level
C:\gisdata\vdu\software\um\DNC16ogrinfo  -al 
gltp:/vrf/gisdata/vdu/software/um/DNC16/a160 'dang...@obs(*)_area'ERROR 4: 
OGDI Driver doesn't support update.Had to open data source read-only.INFO: Open 
of `gltp:/vrf/gisdata/vdu/software/um/DNC16/a160'  using driver `OGDI' 
successful.FAILURE: Couldn't fetch requested layer 'dang...@obs(*)_area'!
Playing around with case sensitivity to no avail.
C:\gisdata\vdu\software\um\DNC16ogrinfo  
gltp:/vrf/gisdata/vdu/software/um/DNC16/a160 'dang...@obs(*)_area'ERROR 4: 
OGDI Driver doesn't support update.Had to open data source read-only.INFO: Open 
of `gltp:/vrf/gisdata/vdu/software/um/DNC16/a160'  using driver `OGDI' 
successful.FAILURE: Couldn't fetch requested layer 'dang...@obs(*)_area'!
I'm not sure how much more info I'd get from the specific call to the layer 
level.Generally, I know it is there.
C:\gisdata\vdu\software\um\DNC16ogr2ogr a160_danger_a.shp  
gltp:/vrf/gisdata/vdu/software/um/DNC16/a160 'dang...@obs(*)_area'FAILURE: 
Couldn't fetch requested layer ''dang...@obs(*)_area''!
Ah, failure to fetch means no shape file.  Any help in pushing this into shape 
greatlyappreciated, there's some danger I need to map.
Chris English

  ___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev