On Saturday 24 February 2007 22:37, Frank Warmerdam wrote:
> Balint Cristian wrote:
> > BTW,
> > gdal should be updated to use '-logdi' aka `ogdi-config --libs` ,
> > '-logdi31' is dead now ;-)
> > but the best is to convince gdal to use 'ogdi-config', wich can tell
> > exactly where odi lives now,
> > olso flags lookup `ogdi-config --cflags`.
>
> Balint,
>
> I'm willing to update this in GDAL trunk, and possibly the GDAL 1.4.1 release,
> but currently it seems installing ogdi did not install ogdi-config.  Shouldn't
> it?

   Right. I fix it today.


>
> Best regards,

--
Balint Cristian (Red Hat Release Engineering Team)

On Saturday 24 February 2007 22:56, Frank Warmerdam wrote:
>
> Balint,
>
> I notice that OGDI libraries are now being installed in $prefix/lib/ogdi
> instead of $prefix/lib.  What is the reason for this?  I find the practice
> quite distruptive, and it means I need to extend my LD_LIBRARY_PATH with a
> new location.

     Those are plugins only.

      * We shouldn't expose plugin libs to system wide lib search path,
         this would break FHS (http://www.pathname.com/fhs/),
         its better to keep them hidden, and only ogdi binary handle those
         thorough dlopen()

You shouldn't update LD_LIB_PATH !!!


During compile time there is:
CFLAGS  = $(INCLUDES) $(COMMON_CFLAGS) -DMODULES_PATH="\"$(INST_LIB)/ogdi/\""

And from source code where dlopen() is invoked is a fallback in case INST_LIB
doesnt comes:

#if !defined(MODULES_PATH)
#define MODULES_PATH "/usr/lib/ogdi/"
#endif


I test that here, plugins loaded normaly without LD_LIB_PATH


>
> Best regards,

--
Balint Cristian (Red Hat Release Engineering Team)

patch in CVS as 'new revision: 1.2'

My further debugs on x86_64:

some valgrind test looks better now:

==15875== LEAK SUMMARY:
==15875==    definitely lost: 0 bytes in 0 blocks.
==15875==      possibly lost: 0 bytes in 0 blocks.
==15875==    still reachable: 4,520 bytes in 11 blocks.
==15875==         suppressed: 0 bytes in 0 blocks.
==15875== Reachable blocks (those to which a pointer was found) are not shown.
==15875== To see them, rerun with: --show-reachable=yes
--15875--  memcheck: sanity checks: 12 cheap, 1 expensive
--15875--  memcheck: auxmaps: 236 auxmap entries (15104k, 14M) in use
--15875--  memcheck: auxmaps: 731117 searches, 1271252 comparisons
--15875--  memcheck: SMs: n_issued      = 40 (640k, 0M)
--15875--  memcheck: SMs: n_deissued    = 0 (0k, 0M)
--15875--  memcheck: SMs: max_noaccess  = 524287 (8388592k, 8191M)
--15875--  memcheck: SMs: max_undefined = 0 (0k, 0M)
--15875--  memcheck: SMs: max_defined   = 354 (5664k, 5M)
--15875--  memcheck: SMs: max_non_DSM   = 40 (640k, 0M)
--15875--  memcheck: max sec V bit nodes:    0 (0k, 0M)
--15875--  memcheck: set_sec_vbits8 calls: 0 (new: 0, updates: 0)
--15875--  memcheck: max shadow mem size:   4784k, 4M
--15875-- translate:            fast SP updates identified: 3,399 ( 88.3%)
--15875-- translate:   generic_known SP updates identified: 329 (  8.5%)
--15875-- translate: generic_unknown SP updates identified: 118 (  3.0%)
--15875--     tt/tc: 12,060 tt lookups requiring 12,370 probes
--15875--     tt/tc: 12,060 fast-cache updates, 5 flushes
--15875--  transtab: new        4,444 (103,561 -> 1,961,334; ratio 189:10) [0
scs]
--15875--  transtab: dumped     0 (0 -> ??)
--15875--  transtab: discarded  12 (257 -> ??)
--15875-- scheduler: 1,273,179 jumps (bb entries).
--15875-- scheduler: 12/10,780 major/minor sched events.
--15875--    sanity: 13 cheap, 1 expensive checks.
--15875--    exectx: 30,011 lists, 250 contexts (avg 0 per list)
--15875--    exectx: 2,903 searches, 2,951 full compares (1,016 per 1000)
--15875--    exectx: 0 cmp2, 6 cmp4, 0 cmpAll

olso the main test look better now:
Test dted-toronto-1 passed.
Test dted-toronto-2 passed.
Test dted-toronto-3 passed.
Test rpf-ftdrum-1 passed.
Test rpf-ftdrum-2 passed.

And vpf looks OK:

cat vpf/texas-?.diff
---------------------/--------------------------//-----------------------------
8a9
> GET_TABLE_ELEMENT: Invalid field number -1
2182a2184,2189
>
> vpf_open_table: error opening
</home/rezso/ogdits-3.1/data/vpf/vm2alv2/texash/elev/F/J/HB/1500/FAC>
>
> vpf_open_table: error opening
</home/rezso/ogdits-3.1/data/vpf/vm2alv2/texash/elev/F/J/HB/1500/RNG>
>
> vpf_open_table: error opening
</home/rezso/ogdits-3.1/data/vpf/vm2alv2/texash/elev/F/J/HB/1500/FBR>
8a9
> GET_TABLE_ELEMENT: Invalid field number -1
8a9
> GET_TABLE_ELEMENT: Invalid field number -1
8a9
> GET_TABLE_ELEMENT: Invalid field number -1
8a9
> GET_TABLE_ELEMENT: Invalid field number -1
--------------------------------//////------------------------------------------\
----------------------
Still pending path case-insensitive patch to workaround those outputs for vpf
driver.


--
Balint Cristian (Red Hat Release Engineering Team)

Balint Cristian wrote:
>
>
> On Saturday 24 February 2007 22:56, Frank Warmerdam wrote:
>  >
>  > Balint,
>  >
>  > I notice that OGDI libraries are now being installed in $prefix/lib/ogdi
>  > instead of $prefix/lib. What is the reason for this? I find the practice
>  > quite distruptive, and it means I need to extend my LD_LIBRARY_PATH
> with a
>  > new location.
>
> Those are plugins only.
>
> * We shouldn't expose plugin libs to system wide lib search path,
> this would break FHS (http://www.pathname.com/fhs/
> <http://www.pathname.com/fhs/>),
> its better to keep them hidden, and only ogdi binary handle those
> thorough dlopen()

Balint,

On my system all the ogdi libraries got installed in this directory
including libogdi.so, libzlib_ogdi32.so and libexpat_ogdi32.so.  If this
is unintentional then perhaps there is something in the install targets that
needs to be fixed.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

On Sunday 25 February 2007 17:04, Frank Warmerdam wrote:
> Balint Cristian wrote:
> >
> >
> > On Saturday 24 February 2007 22:56, Frank Warmerdam wrote:
> >  >
> >  > Balint,
> >  >
> >  > I notice that OGDI libraries are now being installed in $prefix/lib/ogdi
> >  > instead of $prefix/lib. What is the reason for this? I find the practice
> >  > quite distruptive, and it means I need to extend my LD_LIBRARY_PATH
> > with a
> >  > new location.
> >
> > Those are plugins only.
> >
> > * We shouldn't expose plugin libs to system wide lib search path,
> > this would break FHS (http://www.pathname.com/fhs/
> > <http://www.pathname.com/fhs/>),
> > its better to keep them hidden, and only ogdi binary handle those
> > thorough dlopen()
>
> Balint,
>
> On my system all the ogdi libraries got installed in this directory
> including libogdi.so, libzlib_ogdi32.so and libexpat_ogdi32.so.  If this
> is unintentional then perhaps there is something in the install targets that
> needs to be fixed.

wierd.

    Can please provide me the enviroment parameters and the what you passed to
config
scripts and an output of ls -l where installs lives now on your system?


Personaly i used for build (notice that i didnt use INST_LIBS anymore):
------------------------------------//////////----------------------------------\
------------------------>
[root@rezso ADUSE]# tar -xzf ogdi-3.2.0.beta1.tar.gz
[root@rezso ADUSE]# cd ogdi-3.2.0.beta1
[root@rezso ogdi-3.2.0.beta1]#

export CFLAGS="-g3 -fPIC -DPIC -DDONT_TD_VOID -DUSE_TERMIO"
export TOPDIR=`pwd`
export TARGET=Linux

./configure --prefix=/usr --libdir=/usr/lib64 --with-binconfigs  --with-expat
--with-proj --with-zlib
make

make -C ogdi/tcl_interface  TCL_LINKLIB="-ltcl"
make -C contrib/gdal ODBC_LINKLIB="-lodbc"
make -C ogdi/attr_driver/odbc ODBC_LINKLIB="-lodbc"

make install

[root@rezso ogdi-3.2.0.beta1]# find /usr/lib64/ogdi/ /usr/lib64/libogd*
/usr/lib64/ogdi/
/usr/lib64/ogdi/libdted.so
/usr/lib64/ogdi/librpf.so
/usr/lib64/ogdi/libadrg.so
/usr/lib64/ogdi/libremote.so
/usr/lib64/ogdi/libdtcanada.so
/usr/lib64/ogdi/libdtusa.so
/usr/lib64/ogdi/libvrf.so
/usr/lib64/ogdi/libskeleton.so
/usr/lib64/libogdi.so
/usr/lib64/libogdi.so.3
/usr/lib64/libogdi.so.3.2

[root@rezso ogdi-3.2.0.beta1]# find /usr/include/ecs*
/usr/include/ecs.h
/usr/include/ecs_util.h

[root@rezso ogdi-3.2.0.beta1]# find /usr/bin/ogdi_i*
/usr/bin/ogdi_import
/usr/bin/ogdi_info

#install plugins
make install -C ogdi/tcl_interface
make install -C contrib/gdal
make install -C ogdi/attr_driver/odbc

[root@rezso ogdi-3.2.0.beta1]# make install -C ogdi/tcl_interface
make: Entering directory `/ADUSE/ogdi-3.2.0.beta1/ogdi/tcl_interface'
mkdir -p /usr/lib64/ogdi
cp /ADUSE/ogdi-3.2.0.beta1/bin/Linux/libecs_tcl.so /usr/lib64/ogdi
make: Leaving directory `/ADUSE/ogdi-3.2.0.beta1/ogdi/tcl_interface'
[root@rezso ogdi-3.2.0.beta1]# make install -C contrib/gdal
make: Entering directory `/ADUSE/ogdi-3.2.0.beta1/contrib/gdal'
mkdir -p /usr/lib64/ogdi
cp /ADUSE/ogdi-3.2.0.beta1/bin/Linux/libgdal.so /usr/lib64/ogdi
make: Leaving directory `/ADUSE/ogdi-3.2.0.beta1/contrib/gdal'
[root@rezso ogdi-3.2.0.beta1]# make install -C ogdi/attr_driver/odbc
make: Entering directory `/ADUSE/ogdi-3.2.0.beta1/ogdi/attr_driver/odbc'
mkdir -p /usr/lib64/ogdi
cp /ADUSE/ogdi-3.2.0.beta1/bin/Linux/liblodbc.so /usr/lib64/ogdi
make: Leaving directory `/ADUSE/ogdi-3.2.0.beta1/ogdi/attr_driver/odbc'

[root@rezso ogdi-3.2.0.beta1]#  find /usr/lib64/ogdi/
/usr/lib64/ogdi/
/usr/lib64/ogdi/libdted.so
/usr/lib64/ogdi/libgdal.so
/usr/lib64/ogdi/librpf.so
/usr/lib64/ogdi/libadrg.so
/usr/lib64/ogdi/libremote.so
/usr/lib64/ogdi/libdtcanada.so
/usr/lib64/ogdi/libdtusa.so
/usr/lib64/ogdi/libvrf.so
/usr/lib64/ogdi/libecs_tcl.so
/usr/lib64/ogdi/libskeleton.so
/usr/lib64/ogdi/liblodbc.so
----------------------------------/////////-------------------------------------\
-----------------<

Which is pretty correct.

Some tasks arised in my mind to enhance build infrastucture a bit:
1) get rid of TOPDIR, i think 'pwd' can do the trick for GNU systems or solaris,
cygwin too.
2) get rit of TARGET at least can be detected for GNU or solaris, cygwin too.
3) those plugins can be enabled with --enable-tcl --enable-contrib --enable-odbc



>
> Best regards,

--
Balint Cristian (Red Hat Release Engineering Team)

Balint Cristian wrote:
>  > Balint,
>  >
>  > On my system all the ogdi libraries got installed in this directory
>  > including libogdi.so, libzlib_ogdi32.so and libexpat_ogdi32.so. If this
>  > is unintentional then perhaps there is something in the install
> targets that
>  > needs to be fixed.
>
> wierd.
>
> Can please provide me the enviroment parameters and the what you passed
> to config
> scripts and an output of ls -l where installs lives now on your system?

I built using:

export TOPDIR=`pwd`
export CXXFLAGS="-O2 -fPIC"
export CFLAGS="-O2 -fPIC"
./configure --prefix=$HOME/bld --with-proj=$HOME/bld
make
make install

warmerda@amd64[12]% ls ~/bld/lib/ogdi
libadrg.so      libdtusa.so         libremote.so    libvrf.so
libdtcanada.so  libexpat_ogdi32.so  librpf.so       libzlib_ogdi32.so
libdted.so      libogdi.so          libskeleton.so

Strangely I didn't get any of the .so.3 or anything like that.

I didn't notice before, but it seems there were some errors during the
make install like this:

cp *.h /home/warmerda/bld/include
make[2]: Leaving directory `/wrk/home/warmerda/pkg/ogdi-3.2.0.beta1/ogdi/include
'
make[2]: Entering directory `/wrk/home/warmerda/pkg/ogdi-3.2.0.beta1/ogdi/c-api'
mkdir -p /home/warmerda/bld/lib/ogdi
cp /wrk/home/warmerda/pkg/ogdi-3.2.0.beta1/bin/Linux/libogdi.so /home/warmerda/b
ld/lib/ogdi
mv -f /home/warmerda/bld/lib/libogdi.so.3.2 /home/warmerda/bld/lib
mv: cannot stat `/home/warmerda/bld/lib/libogdi.so.3.2': No such file or
directory
make[2]: *** [install-so-link] Error 1

Best regards,
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

> I built using:
>
> export TOPDIR=`pwd`
> export CXXFLAGS="-O2 -fPIC"
> export CFLAGS="-O2 -fPIC"
> ./configure --prefix=$HOME/bld --with-proj=$HOME/bld
> make
> make install

Hello Frank,

I ve tryred (as root user):

export TOPDIR=`pwd`
export CXXFLAGS="-O2 -fPIC"
export CFLAGS="-O2 -fPIC"
export TARGET="Linux"
./configure --prefix=$HOME/bld --with-proj --with-zlib --with-expat
make
make install

and got:

/root/bld/
/root/bld/bin
/root/bld/bin/ogdi_import
/root/bld/bin/example1
/root/bld/bin/ogdi_info
/root/bld/bin/gltpd
/root/bld/bin/example2
/root/bld/lib
/root/bld/lib/libogdi.so
/root/bld/lib/ogdi
/root/bld/lib/ogdi/libdted.so
/root/bld/lib/ogdi/librpf.so
/root/bld/lib/ogdi/libadrg.so
/root/bld/lib/ogdi/libremote.so
/root/bld/lib/ogdi/libdtcanada.so
/root/bld/lib/ogdi/libdtusa.so
/root/bld/lib/ogdi/libvrf.so
/root/bld/lib/ogdi/libskeleton.so
/root/bld/lib/libogdi.so.3
/root/bld/lib/libogdi.so.3.2
/root/bld/include
/root/bld/include/ecs.h
/root/bld/include/ecs_util.h


Which is very ok, and for correct work of stuff:

LD_CONFIG should have /root/bld/lib/ only
and PATH should have /root/bld/bin/

i've tested the functionality even in home folders, and can see that my
compiler lines had:  -DMODULES_PATH="\"/root/bld/lib/ogdi/\""
which mean dlopen() will load plugins from /ogdi subfolder withoult proplems.


   Across the GNUmake's there is a INST_LIB env var not quite corectly treated,
i saw some strangeness even in 3.1.5 where one of my case wont work as i wanted
to
do.



> warmerda@amd64[12]% ls ~/bld/lib/ogdi
> libadrg.so      libdtusa.so         libremote.so    libvrf.so
> libdtcanada.so  libexpat_ogdi32.so  librpf.so       libzlib_ogdi32.so
> libdted.so      libogdi.so          libskeleton.so
>
> Strangely I didn't get any of the .so.3 or anything like that.
>
> I didn't notice before, but it seems there were some errors during the
> make install like this:
>
> cp *.h /home/warmerda/bld/include
> make[2]: Leaving directory
`/wrk/home/warmerda/pkg/ogdi-3.2.0.beta1/ogdi/include
> '
> make[2]: Entering directory
`/wrk/home/warmerda/pkg/ogdi-3.2.0.beta1/ogdi/c-api'
> mkdir -p /home/warmerda/bld/lib/ogdi
> cp /wrk/home/warmerda/pkg/ogdi-3.2.0.beta1/bin/Linux/libogdi.so
/home/warmerda/b
> ld/lib/ogdi
> mv -f /home/warmerda/bld/lib/libogdi.so.3.2 /home/warmerda/bld/lib
> mv: cannot stat `/home/warmerda/bld/lib/libogdi.so.3.2': No such file or
directory
> make[2]: *** [install-so-link] Error 1

hmm, strange. Cant figure out why for me work.
Can send me the full log of build ?

On Monday 26 March 2007 17:20, Francesco P. Lovergine wrote:
> Hi
>
> Frank Warmerdam pointed me to you for a question about ogdi.
> I'm currently working on the very first OGDI debian package for
> DebianGis. I noted that modifying relevant makefiles I can get
> a version 3 soname for ogdi-3.2.0beta1. It would like to know
> if that is definitively the solib version for the current ogdi API
> or you have in program to change the versioning scheme before
> releasing. The default building scripts do not use sonames, which is
> a problem for us, so I need to versioning.
> Is your intention to use a major version only scheme
> and using the minor version for non-API or back-compatible changes
> only? This is useful to know to be compliant with our library
> maintainance and upgrading Policy. I also would avoid to have
> a soname which could be not compatible with other distros.
>
> Thanks in advance for your attention.

Hello !

  I  intoduced the soname versioning, becouse (probably) you agree  with me
that current distros have settled as MUST over any library providing packages to
have upstream soname
versioning to reflect current ABI, this is i think an modern requirement these
days.
   Olso please notice the there are some dlopen()-ned plugins, i completly hide
tham
during make install into something like /usr/lib/ogdi/*.so and those doenst get
marked
with soname-ing, this in accord to the latest FSH rules over modern linux
distros.

The ABI versioning schema is simple in case of ogdi:

   We are now in the stage of 3.2.0 pre releases, so "3.2" soname is whatever we
will hold
over all 3.2.x series, and soname will _not_ change until 3.3.x series, but 3.3
series have to
be a major change in ogdi functionality. Its i thin a classical rel-eng schema.

    I defenetly olso look forward to enhanche whole build infrastructure in the
very final 3.2.0
release, mean here three things:

1) Try get rid to export TOPDIR TARGET and INST_LIB exports (v. ugly ....)
2) introduce --with-{tcl,odbc,contrib} flags to not do manual separate e.g "make
-C ogdi/tcl_interface TCL_LINKLIB="-ltcl"
3) introduce "make uninstall target" if it is possible.

Olso please notice that we have to keep in shape win32 port oloso, so any touch
over build infra have to
keep win32 functional !

   Francesco, if have some ideas or some cool patches to make it _better_, I thin
we looking forward for tham.

   Basicaly till now i put effort to fix tons of compile warrnings, fix
64bitness, and fix all license issues,
it tooked some times, and implyed to reworte some routines, so why new 3.2.x is
bornning out of ogdi.


I attach you how fedora do in .spec the build process, it may help you (still
looks ugly  there),
i hope final 3.2.0 build infra will look more simple understandable and not need
to do in 1000 steps ..

i dream something simple like:
./configure --with-whatever --with-anotherwhatever
--prefix=your_favourite_home_path
make
make install
make uninstall


right now looks like (too many steps):

--------------------////-----------------------<
%build

TOPDIR=`pwd`; TARGET=Linux; export TOPDIR TARGET
INST_LIB=%{_libdir}/;export INST_LIB

# do not compile with ssp. it will trigger internal bugs (to_fix_upstream)
OPT_FLAGS=`echo $RPM_OPT_FLAGS|sed -e 's/-Wp,-D_FORTIFY_SOURCE=2//g'`
export CFLAGS="$OPT_FLAGS -fPIC -DPIC -DDONT_TD_VOID -DUSE_TERMIO"
%configure \
         --with-binconfigs \
         --with-expat \
         --with-proj \
         --with-zlib

# WARNING !!!
# using %{?_smp_mflags} may break build
make

# build tcl interface
make -C ogdi/tcl_interface \
           TCL_LINKLIB="-ltcl"

# build contributions
make -C contrib/gdal

# build odbc drivers
ODBC_LINKLIB="-lodbc"
make -C ogdi/attr_driver/odbc \
           ODBC_LINKLIB="-lodbc"

%install
rm -rf $RPM_BUILD_ROOT

# export env
TOPDIR=`pwd`; TARGET=Linux; export TOPDIR TARGET

make install \
         INST_INCLUDE=$RPM_BUILD_ROOT%{_includedir}/%{name} \
         INST_LIB=$RPM_BUILD_ROOT%{_libdir} \
         INST_BIN=$RPM_BUILD_ROOT%{_bindir}

# install plugins olso
make install -C ogdi/tcl_interface \
         INST_LIB=$RPM_BUILD_ROOT%{_libdir}
make install -C contrib/gdal \
         INST_LIB=$RPM_BUILD_ROOT%{_libdir}
make install -C ogdi/attr_driver/odbc \
         INST_LIB=$RPM_BUILD_ROOT%{_libdir}

# remove example binary
rm $RPM_BUILD_ROOT%{_bindir}/example?

# install pkgconfig file and ogdi-config
mkdir -p %{buildroot}%{_libdir}/pkgconfig
install -p -m 644 ogdi.pc %{buildroot}%{_libdir}/pkgconfig/
install -p -m 755 ogdi-config %{buildroot}%{_bindir}
--------------------///-----------------------<


Cheers,
/cristian

I propose a patch that fixes the following things for VPF products read:

  * fix filename case sensitivy problems with VPF products (for Unix-like
systems). The muse_*** functions now try different combinations of lowercase
and uppercase letters when the filename is not found at first attempt.
  * fix incorrect use of sprintf in vrf_GetMetadata
  * report wgs84 instead of nad83. I'm not sure whether that is true for all
VPF products, but at least it's correct for VMAP products that *must* be
WGS84. A better fix would be to read the VPF table that contains this
information
  * fix a few minor memory leaks and memory usage issues (found by Valgrind)
  * enable XMIN, YMIN, XMAX and YMAX columns to be of type double in EBR and
FBR files (necessary to read the VMAP2i 'MIG2i000' product)
  * add .pjt and .tjt as possible extensions for join tables (VMAP2i 'MIG2i000'
product)
  * fix duplicated layers report (VMAP2i 'MIG2i000' product)
  * handle 'L' (Latin1) type for text files (GEOCAPI 'MIGxxx' products)
  * optionnaly, convert text to UTF-8 when environment variable
CONVERT_OGDI_TXT_TO_UTF8 is defined. This part is not portable on Windows I
guess (only tested on Linux) and maybe too specific.
  * enable reading of VPF products without table indexes file (GEOCAPI 'MIG013'
and 'MIG016' products). VPF norm says that when there is a variable length
field in one table, an index should exist, but some test products don't
follow this. The approach here is to read the whole table content and build
the index in memory.

For your information, VMAP2i is an essentially French derivative of VMAP2 and
GEOCAPI a set of rules, test procedures and test products that the French
defence procurement agency (DGA) makes available to its industrial
contractors to validate their GIS developments.

All of this has been tested with OGDI 3.1.6, but the patch also applies
cleanly on OGDI 3.2.0beta, though I guess it should be integretated after the
3.2.0 release.

On Friday 04 May 2007, Even Rouault wrote:
> I propose a patch that fixes the following things for VPF products read:



Hello Even,

    I will test this patch, mainly in 3.2.0beta, if patch is fine (mean nothing
that worked before
  is affected) we can respin a  3.2.0beta2 after this patch. The patch feauture
enhachements
looks great maybe Frank W. agree with 3.2.0beta2 test release with patch
included ?


>  * fix filename case sensitivy problems with VPF products (for Unix-like
> systems). The muse_*** functions now try different combinations of lowercase
> and uppercase letters when the filename is not found at first attempt.
>  * fix incorrect use of sprintf in vrf_GetMetadata
>  * report wgs84 instead of nad83. I'm not sure whether that is true for all
> VPF products, but at least it's correct for VMAP products that *must* be
> WGS84. A better fix would be to read the VPF table that contains this
> information
>  * fix a few minor memory leaks and memory usage issues (found by Valgrind)
>  * enable XMIN, YMIN, XMAX and YMAX columns to be of type double in EBR and
> FBR files (necessary to read the VMAP2i 'MIG2i000' product)
>  * add .pjt and .tjt as possible extensions for join tables (VMAP2i 'MIG2i000'
> product)
>  * fix duplicated layers report (VMAP2i 'MIG2i000' product)
>  * handle 'L' (Latin1) type for text files (GEOCAPI 'MIGxxx' products)
>  * optionnaly, convert text to UTF-8 when environment variable
> CONVERT_OGDI_TXT_TO_UTF8 is defined. This part is not portable on Windows I
> guess (only tested on Linux) and maybe too specific.
>  * enable reading of VPF products without table indexes file (GEOCAPI 'MIG013'
> and 'MIG016' products). VPF norm says that when there is a variable length
> field in one table, an index should exist, but some test products don't
> follow this. The approach here is to read the whole table content and build
> the index in memory.
>
> For your information, VMAP2i is an essentially French derivative of VMAP2 and
> GEOCAPI a set of rules, test procedures and test products that the French
> defence procurement agency (DGA) makes available to its industrial
> contractors to validate their GIS developments.
>
> All of this has been tested with OGDI 3.1.6, but the patch also applies
> cleanly on OGDI 3.2.0beta, though I guess it should be integretated after the
> 3.2.0 release.
>
>
>
> Yahoo! Groups Links
>
>
>
>



--
Balint Cristian (Red Hat Release Engineering Team)

Registered Address: Red Hat Czech s.r.o.,
Purkyňova 99/71, 612 45 Brno, Czech Republic
Registered in Brno under identification number CZ27690016

Balint Cristian wrote:
> On Friday 04 May 2007, Even Rouault wrote:
>> I propose a patch that fixes the following things for VPF products read:
>
>
>
> Hello Even,
>
>    I will test this patch, mainly in 3.2.0beta, if patch is fine (mean nothing
that worked before
>  is affected) we can respin a  3.2.0beta2 after this patch. The patch feauture
enhachements
> looks great maybe Frank W. agree with 3.2.0beta2 test release with patch
included ?

Balint,

Yes, I think this seems like a great idea.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

Hello,

here's an updated version of the patch I previously sent (in fact there are
two possibilities, thus two versions, discussed hereafter).
This update adds a small fix for the handling of 'Integer' and 'Smallint'
column types in the VRF driver.

It's necessary because otherwise the conversion of attribute from VMAP to
Shapefile (with ogr2ogr) is incorrect when dealing with smallint : a value
like -32767,-32766, etc (really common in VMAP products
for 'unknown', 'invalid', etc) is truncated as -3276 in the DBF of the
shapefile. It's due to the fact that, currently, smallint is declared as 5
character-wide and not 6. So the fix is to increase of 1 the size of smallint
(5 -> 6) and integer types (10 -> 11).

But you need also a similar patch in OGR (GDAL) since currently OGR recognizes
numeric columns of 11 characters or more as double and not integer...

I see 2 possibilities :
* make accept the two patches together : gdal-1.4.1-ogr-integer.patch and
ogdi-3.1.6-with-integer-and-smallint-fix.patch (it means that OGDI >= 3.2
should be a requirement for the version of GDAL that would incorporate
gdal-1.4.1-ogr-integer.patch)
* if the sync between the two projects is two complicated, just fix in OGDI
the smallint case which is the one I really needed to fix for my problem :
ogdi-3.1.6-with-smallint-fix.patch. And keep in mind that the Integer case
may rise problems with big negative values.

On Wednesday 09 May 2007, Even Rouault wrote:
> Hello,
>

Hello Even ,

I checked into CVS your patches, pretty nice !

I marked your email addr and reference as comment in
Changelog, to make sure we dont have license/origin
problems, hope it will not mind you, and agree.

    As a mention we try switch to 3.2.0, so i strongly recomand
try focus and feedback over that, instead 3.1.x series.

    BTW, i still concern my new matrix.c routine, did you encounter
strangenesses with it ? I ask, you look like stressed a lot ogdi
functionality. Or you use 3.1.6 ?!

     Now testing win32 build olso than as Frank W. agreed
i release the beta2 tarball, its trivial to have native win32
working also, I have to test olso breakage of this before I
release tarball on sf.net.

  I think till tomorrow i can finish it (pretty late now, go sleep).

For now can check and feedback the code:

cvs -d:pserver:anonymous@...:/cvsroot/ogdi login
cvs -z3 -d:pserver:anonymous@...:/cvsroot/ogdi co -P devdir


> I see 2 possibilities :

> * make accept the two patches together : gdal-1.4.1-ogr-integer.patch and
> ogdi-3.1.6-with-integer-and-smallint-fix.patch (it means that OGDI >= 3.2
> should be a requirement for the version of GDAL that would incorporate
> gdal-1.4.1-ogr-integer.patch)

> * if the sync between the two projects is two complicated, just fix in OGDI
> the smallint case which is the one I really needed to fix for my problem :
> ogdi-3.1.6-with-smallint-fix.patch. And keep in mind that the Integer case
> may rise problems with big negative values.

    I think Frank W. can check into gdal olso that small patch, it sounds a
resonable
good fix to extend a bit that field length.
    But since they release recently the 1.4.1 probably the next release will have
a bit
to wait till hit tarballs.

The patch for gdal (as reminder) was:

---------------------------------//////////////--------------------->
diff -ur gdal-digest-1.4.1-ori/ogr/ogrsf_frmts/shape/dbfopen.c
gdal-digest-1.4.1/ogr/ogrsf_frmts/shape/dbfopen.c
--- gdal-digest-1.4.1-ori/ogr/ogrsf_frmts/shape/dbfopen.c       2007-05-02
16:53:35.000000000 +0200
+++ gdal-digest-1.4.1/ogr/ogrsf_frmts/shape/dbfopen.c   2007-05-09
09:54:47.000000000 +0200
@@ -958,7 +958,7 @@
               || psDBF->pachFieldType[iField] == 'F' )
      {
         if( psDBF->panFieldDecimals[iField] > 0
-            || psDBF->panFieldSize[iField] > 10 )
+            || psDBF->panFieldSize[iField] > 11 )
             return( FTDouble );
         else
             return( FTInteger );
---------------------------------//////////////--------------------->


/cristian

>  * report wgs84 instead of nad83. I'm not sure whether that is true for all
> VPF products, but at least it's correct for VMAP products that *must* be
> WGS84. A better fix would be to read the VPF table that contains this
> information

Hmm ...

ogdidts-3.1 test env olso has some texas map. A grep of mine through
binary blobs of texas vpf maps shows clearly 'WGS 84', but ogdi reported
till now NAD datum wich is incorect ...

  At last WGS 84 string appear in a .grt files.

I am looking now at specification of this VMAP format to double check.



   No one noticed before, this render the test case of ogdits-3.1 olso false
for vpf.

--- In ogdidev@yahoogroups.com, "krzysztof_1324" <blah2@...> wrote:
>
> Hello
>
> I have tried to build GDAL with VPF support (Win .NET platform). As I
> know, the one way to do it, lead up to OGDI package. I don't want to
> describe following troubles during building all the needed sources
> (proj, ogdi) but only ask the question about a success in this matter.
> Is it done by somebody ? (I mean Win + C++ .NET + GDAL + OGDI +
> VPFVIEW).
>
>
> Krzysztof
>


Were you ever able to get any information regarding this matter?

Matt

Sorry if this has been addressed before:

Could anyone walk me through how to compile the OGDI package in Visual
Studio 2005?  If this is a "road less traveled" could anyone point me
in the direction to obtain CADRG, ADRG, and/or CIB dll's (and lib
files) for win32 application.

Thanks in advance,

Matt
Software Engineer II

There has been work recently in GDAL trunk (future 1.5.0 release) to support
CADRG (and CIB ?) products (A.TOC file reading).
And there is a patch in GDAL trac (http://trac.osgeo.org/gdal/ticket/1877) to
add direct ADRG support too.

Le Monday 29 October 2007 21:01:11 solo78solo, vous avez écrit :
> Sorry if this has been addressed before:
>
> Could anyone walk me through how to compile the OGDI package in Visual
> Studio 2005?  If this is a "road less traveled" could anyone point me
> in the direction to obtain CADRG, ADRG, and/or CIB dll's (and lib
> files) for win32 application.
>
> Thanks in advance,
>
> Matt
> Software Engineer II
>
>
>
>
> Yahoo! Groups Links
>
>
>

---

To: ogdidev@yahoogroups.com
From: even.rouault@...
Date: Mon, 29 Oct 2007 22:15:31 +0200
Subject: Re: [ogdidev] VS 2005 compile or dll's

There has been work recently in GDAL trunk (future 1.5.0 release) to support
CADRG (and CIB ?) products (A.TOC file reading).
And there is a patch in GDAL trac (http://trac.osgeo.org/gdal/ticket/1877) to
add direct ADRG support too.

Le Monday 29 October 2007 21:01:11 solo78solo, vous avez écrit :
> Sorry if this has been addressed before:
>
> Could anyone walk me through how to compile the OGDI package in Visual
> Studio 2005? If this is a "road less traveled" could anyone point me
> in the direction to obtain CADRG, ADRG, and/or CIB dll's (and lib
> files) for win32 application.
>
> Thanks in advance,
>
> Matt
> Software Engineer II
>
>
>
>
> Yahoo! Groups Links
>
>
>

Hi,

    I am currently using OGDI for reading vpf data. I have read
point/line/area feature file, but do not know how to read information
from int.vdt file?
I select objects from, for example, point file by selecting the
layer(industp@cul(*)) and then just use:

result = cln_GetNextObject(m_clientId);

But I have read that to connect labels I need to read values from
int.vdt file. How to do this? What kind of object will be the outcome?

I do appreciate any help.

Thank you

Kacper

Hello,

   It was a while since previous beta, unfortunateley I received
few feedbacks, and olso I hadnt got time to dedicate myself for
a better release-engineering.
   I would like to invite you to try and consider 3.2.0.beta2 as
more stable one, since couple of enhanchements and bugfixes
are involved.

Most notable improvements in this release:

enhanchements:
* fix path case sensitive problem for folders in vpf driver (finaly !)
* fix filename case sensitivy problems (for Unix-like systems)
* fix build on GNU/kFreeBSD
* optionaly, convert text to UTF-8 when environment variable
    CONVERT_OGDI_TXT_TO_UTF8 is defined.
* handle 'L' (Latin1) type for text files (GEOCAPI 'MIGxxx' products).
* enable reading of VPF products without table indexes file
    (GEOCAPI 'MIG013' and 'MIG016' products). VPF norm says that when
    there is a variable length field in one table, an index should exist,
    but some test products don't follow this. The approach here is to read
    the whole table content and build the index in memory.
* report wgs84 instead of nad83, not sure whether that is true
    for all VPF products, but at least it's correct for VMAP products
    that *must* be WGS84.
* add .pjt and .tjt as possible extensions for join tables
    (VMAP2i 'MIG2i000' product).
* gmath.* removed completely from this tarball, new math.* replace
    it however since a beta1.

bugfix:
* avoid bashism in makefiles
* fix incorrect use of sprintf in vrf_GetMetadata.
* fix a few minor memory leaks and memory usage issues.
* enable XMIN, YMIN, XMAX and YMAX columns to be of type double
    in EBR and FBR files (for read the VMAP2i 'MIG2i000' product).
* fix duplicated layers report (VMAP2i 'MIG2i000' product).


Remark:
   Its quite a lot improvement and bugfixes, i did some tests and must
notice a short todo list for next release:

ToDO:
  1)  Before, a next release need check over more products the WGS84 issue,
   consult the documentation how to exactly interpret .grt index file, looks
   like there are more fields than one describing the geospatial parameters.
  2) See why DOWNGRADE_DATE is not reported anymore :(
  3) Try make a VC projectfile, try to see how works with VC2008 too.

     As final, must mention that some credit in this release goes for,
Even Rouault and Thomas Sailer  for the good enhancements and
patches.

/Cristian.

Hi Cristian

In fact, the value of DOWNGRADING_DATE from the LHT table was broken in ogdi
3.1.6. The value was pure junk, because of getting a non-existing field :

The code was :

get_table_element(table_pos("DOWNGRADING_DATE_DATE",spriv->lhtTable), row,
spriv->lhtTable, (void *)&datee, &count)

instead of  :

get_table_element(table_pos("DOWNGRADING_DATE",spriv->lhtTable), row,
spriv->lhtTable, (void *)&datee, &count)

(The difference is the extra _DATE).

Most of the time, the DOWNGRADING_DATE is 00000000000000.00000, because
there's no downgrading. By the way, just look at the value of
the "DOWNGRADING" field and you'll see that it's "NO" ...

I should have mentionned that fix in my changelog, but it got lost in the
middle of many other fixes...



I'm also attaching a small patch that fixes a memory leak when opening a
non-existing dataset.
For example, this fixes the leaks reported by 'valgrind --leak-check=yes
ogdi_info -u gltp:/vrf/junk_path'

Best regards,

Even


Le Wednesday 28 May 2008 07:54:30 Balint Cristian, vous avez écrit :
> Hello,
>
>   It was a while since previous beta, unfortunateley I received
> few feedbacks, and olso I hadnt got time to dedicate myself for
> a better release-engineering.
>   I would like to invite you to try and consider 3.2.0.beta2 as
> more stable one, since couple of enhanchements and bugfixes
> are involved.
>
> Most notable improvements in this release:
>
> enhanchements:
> * fix path case sensitive problem for folders in vpf driver (finaly !)
> * fix filename case sensitivy problems (for Unix-like systems)
> * fix build on GNU/kFreeBSD
> * optionaly, convert text to UTF-8 when environment variable
>    CONVERT_OGDI_TXT_TO_UTF8 is defined.
> * handle 'L' (Latin1) type for text files (GEOCAPI 'MIGxxx' products).
> * enable reading of VPF products without table indexes file
>    (GEOCAPI 'MIG013' and 'MIG016' products). VPF norm says that when
>    there is a variable length field in one table, an index should exist,
>    but some test products don't follow this. The approach here is to read
>    the whole table content and build the index in memory.
> * report wgs84 instead of nad83, not sure whether that is true
>    for all VPF products, but at least it's correct for VMAP products
>    that *must* be WGS84.
> * add .pjt and .tjt as possible extensions for join tables
>    (VMAP2i 'MIG2i000' product).
> * gmath.* removed completely from this tarball, new math.* replace
>    it however since a beta1.
>
> bugfix:
> * avoid bashism in makefiles
> * fix incorrect use of sprintf in vrf_GetMetadata.
> * fix a few minor memory leaks and memory usage issues.
> * enable XMIN, YMIN, XMAX and YMAX columns to be of type double
>    in EBR and FBR files (for read the VMAP2i 'MIG2i000' product).
> * fix duplicated layers report (VMAP2i 'MIG2i000' product).
>
>
> Remark:
>   Its quite a lot improvement and bugfixes, i did some tests and must
> notice a short todo list for next release:
>
> ToDO:
>  1)  Before, a next release need check over more products the WGS84 issue,
>   consult the documentation how to exactly interpret .grt index file, looks
>   like there are more fields than one describing the geospatial parameters.
>  2) See why DOWNGRADE_DATE is not reported anymore :(
>  3) Try make a VC projectfile, try to see how works with VC2008 too.
>
>     As final, must mention that some credit in this release goes for,
> Even Rouault and Thomas Sailer  for the good enhancements and
> patches.
>
> /Cristian.
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

Hello Even,

   Yes, i noticed those fields. Puzzeld becouse using a hexeditor i saw those
fields there as existent but didnt check if they are at right position. Still
didnt make  it to read the vmap specs, however that date is pretty non
trivial issue.


> I'm also attaching a small patch that fixes a memory leak when opening a
> non-existing dataset.
> For example, this fixes the leaks reported by 'valgrind --leak-check=yes
> ogdi_info -u gltp:/vrf/junk_path'

  Thank you, ill check it in.

>
> Best regards,
>
> Even


/cristian.

Hi,

    I using OGDI to read VPF Data. I Read
AFT,LFT,PFT,TFT(Area/Line/Point/Text) features, but my DNC data also
contain additional notes for chart in DNC libraries.
THere is a NOTES.RAT file containing a table like this: ID NOTE ID
NOTE ID NOTE....; IDs are starting from 1 and asc; To connect Notes
with charts I would have to write my own methods; I am wondering can
OGDI read .RAT FILES or maybe, at least, could help me to connect
Features with notes;

dqyarea.aft (charts) <--CONNECT--> notes.rat(notes for charts)

There is no direct connection between .rat/.aft I would have to read
.njt(join table) to get the info, but I do not want to "invent the
wheel" again.


Thank you for any hints,

Kacper

kasper_gazda wrote:
>
>
> Hi,
>
> I using OGDI to read VPF Data. I Read
> AFT,LFT,PFT,TFT(Area/Line/Point/Text) features, but my DNC data also
> contain additional notes for chart in DNC libraries.
> THere is a NOTES.RAT file containing a table like this: ID NOTE ID
> NOTE ID NOTE....; IDs are starting from 1 and asc; To connect Notes
> with charts I would have to write my own methods; I am wondering can
> OGDI read .RAT FILES or maybe, at least, could help me to connect
> Features with notes;
>
> dqyarea.aft (charts) <--CONNECT--> notes.rat(notes for charts)
>
> There is no direct connection between .rat/.aft I would have to read
> .njt(join table) to get the info, but I do not want to "invent the
> wheel" again.

Kacper,

It isn't conclusive, but I don't know a way of getting at this data
through OGDI.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent

--- In ogdidev@yahoogroups.com, Frank Warmerdam <warmerdam@...> wrote:
>
> kasper_gazda wrote:
> >
> >
> > Hi,
> >
> > I using OGDI to read VPF Data. I Read
> > AFT,LFT,PFT,TFT(Area/Line/Point/Text) features, but my DNC data also
> > contain additional notes for chart in DNC libraries.
> > THere is a NOTES.RAT file containing a table like this: ID NOTE ID
> > NOTE ID NOTE....; IDs are starting from 1 and asc; To connect Notes
> > with charts I would have to write my own methods; I am wondering can
> > OGDI read .RAT FILES or maybe, at least, could help me to connect
> > Features with notes;
> >
> > dqyarea.aft (charts) <--CONNECT--> notes.rat(notes for charts)
> >
> > There is no direct connection between .rat/.aft I would have to read
> > .njt(join table) to get the info, but I do not want to "invent the
> > wheel" again.
>
> Kacper,
>
> It isn't conclusive, but I don't know a way of getting at this data
> through OGDI.
>
> Best regards,
> --
>
---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@...
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>


Hi,

  Thank you for replying so fast and explaining the situation.
  I suppose I am going to show all notes or write my own methods.
  Maybe I could help to add the VPF RAT reading to OGDI ?

Kacper

Hi there,

I'm stuck into the common debug/release dll hell of Visual Studio. When I'm
debugging my application linked against gdal, the VRF driver of OGDI won't load.
Everything is fine in release mode.

So I was thinking about a way out. Is there a way to link the driver statically
into OGDI ? Does anyone has a better idea ?

Thanks for your help,

Jean-Charles

Compiled on Redhat EL version 5.6  64 bit

When trying to run ogrinfo (pulled directly from examples).  VMAP files are on
my local box.

ogrinfo gltp:/vrf/imagery/v0eur/vmaplv0/eurnasia 'watrcrsl@hydro(*)_line'

I get the following error Parse_data_definition: malloc
failed.Parse_data_definition: malloc failed.FAILURE:
Unable to open datasource 'gltp:/vrf/imagery/v0eur/vmaplv0/eurnasia' with the
following drivers:

<list of drivers>

I followed the build instructions here: http://ogdi.sourceforge.net/build.html.

Any ideas?