[GRASS5] v.in.shape/mif - the sequel

David D Gray ddgray at armadce.demon.co.uk
Sat Jan 5 20:40:39 EST 2002


Hi

I've started work on re-arranging the vector import facilities for 
so-called geometric formats, ie. those that are based on whole 
polygon/multiline features and tend to be stored and processed from the 
top with techniques of computational geometry, like shapefile, MapInfo, 
DXF (?).

As you may know, the technique used to date to `split' lines at nodes is 
to identify vertices that co-incide by storing them in some kind of 
spatially keyed database. The database doesn't need to be spatially 
aware, so the fastest kind to use is a hash table. I want to use a hash 
table to store the co-ordinates in the new version. Most applications 
use a dbm type feature that comes with the system for this purpose, and 
this moreover has a sort of standard. I've done a

grep -r '[nsog]?dbm\.h'

on the source tree, but I can't find any reference to common dbm types. 
Does anyone see any problem with #include'ing dbm.h on any particular 
platform? Especially useful would be information about non-Gnu 
platforms. GNU systems like linux, cygwin should pick up gdbm which is good.

I might also mention here, that I intend to continue developing the old 
(or current) v.in.shape. I had planned to retire this and not maintain 
it beyond bugfixes, but it's good at what it does for the current state 
of the vector library, so it seems worth taking the effort to get it 
working properly. That really requires a bit more work than just 
bugfixing as the numerous bug reports show. This would include the 
long-awaited projection support - optionally the source projection is 
given, and input is re-projected to the current projection. And a better 
  set of procedures for cleaning linework and detecting and removing 
artefacts. This is for 5.0 or a maintenance release, the earlier changes 
mentioned are for 5.1.



David




More information about the grass-dev mailing list