[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