[gdal-dev] VPF support

[Even Rouault]

Le mercredi 31 août 2011 15:52:39, Martin Spott a écrit :
> "Sommer, Martin" wrote:
> > current OGDI sources (betas) need a bit of tweaking, if you want it to
> > build yourself. Version 3.1.5 is far way better to build.
> 
> It's just an imprecise annotation, yet I'd like to share my findings
> with you that the simple joy of getting an OGDI library built without
> errors doesn't necessarily yield a working result.
> 
> Everybody who ever had a look at the VMap0 land cover data is familiar
> with the 'usual' voids in northern Africa, middle east and Asia.  Yet,
> when converting VMap0 into Shapefiles using the "3.2" version of OGDI
> which is included in Linux Debian/AMD64, I've encountered many more
> void areas then I was used to.
> As a consequence I built OGDI 3.1.5 on 32 bit Linux in order to get the
> familiar results.  I have to admit that I forgot wether the difference
> was due to the OGDI version or some 32/64 bit mismatch.

Hum, your statement stroke me, so I did a bit of testing with a Linux 32bit 
build of ogdi 3.1.5 vs ogdi 3.2.0beta2 used by GDAL. My test dataset is the 
eurnasia VMAP0 dataset.

The protocol was :

OGR_OGDI_LAUNDER_LAYER_NAMES=YES 
LD_LIBRARY_PATH=$PWD:/home/even/gdal/svn/32bit/trunk/gdal/install-
ogdi-3.1.5/lib apps/ogrinfo 
gltp:/vrf//home/even/gdal/data/vmap/v0eur/vmaplv0/eurnasia -ro | awk '{print 
$2}' > layers.txt

for i in `cat layers.txt`; do echo $i; OGR_OGDI_LAUNDER_LAYER_NAMES=YES 
LD_LIBRARY_PATH=$PWD:/home/even/gdal/svn/32bit/trunk/gdal/install-
ogdi-3.1.5/lib apps/ogrinfo 
gltp:/vrf//home/even/gdal/data/vmap/v0eur/vmaplv0/eurnasia -ro -q $i -
geom=SUMMARY > 315/$i.txt; done

for i in `cat layers.txt`; do echo $i; OGR_OGDI_LAUNDER_LAYER_NAMES=YES 
LD_LIBRARY_PATH=$PWD:/home/even/gdal/svn/32bit/trunk/gdal/install-
ogdi-3.2.0beta2/lib apps/ogrinfo 
gltp:/vrf//home/even/gdal/data/vmap/v0eur/vmaplv0/eurnasia -ro -q $i -
geom=SUMMARY > 320beta2/$i.txt; done

The only differences I could observe are slight precision differences in the 
coordinates of the geometry reported, and 2 missing features in the 3.2.0beta2 
on watrcrsl at hydro(*)_line layer. Those 2 missing features are :

OGRFeature(watrcrsl at hydro(*)_line):187392
  id (Integer) = 187393
  f_code (String) = BH140
  hyc (Integer) = 6
  nam (String) = UNK
  tile_id (Integer) = 24
  edg_id (Integer) = 9219
  LINESTRING (13.68719482421875 30.0,13.691277503967285 30.0)

and

OGRFeature(watrcrsl at hydro(*)_line):193488
  id (Integer) = 193489
  f_code (String) = BH140
  hyc (Integer) = 6
  nam (String) = UNK
  tile_id (Integer) = 25
  edg_id (Integer) = 7800
  LINESTRING (16.324306488037109 30.0,16.322221755981445 30.0)

I'm not sure why there is that difference, but this certainly doesn't account 
for large voids you could observe.

So perhaps the issue you saw was specifically a 64bit issue.

> 
> Cheers,
> 	Martin.