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

[Eric G. Miller]

On Sun, 06 Jan 2002 01:40:39 +0000, David D Gray <ddgray at armadce.demon.co.uk> wrote:

> Hi

Welcome back...

> 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 (?).

I prefer "spaghetti format", although I realize "spaghetti" technically
can't define areal features...

> 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'

I haven't looked at the code, but I'm confused by your description of
splitting lines, or rather finding nodes?  It doesn't seem sufficient.

> 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.

Anyway, I'm not aware of any addition of dbm since you last worked on
GRASS.  I don't see any problem adding it, but maybe help out with
configure rules?

> 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.

I'm sure user's will rejoice if v.in.shape can be made more robust.  I
think it can never fully work for polygons without some concept of
complex features in GRASS (i.e. one face mapping to one or more areas).

Perhaps, if you get bored, you'll want to look at the d.area polygon
hole problem?  I've been working on it in fits and starts, but haven't
managed to figure out how to implement an algorithm that should work
nicely (the algorithm, with modification, could extend to a general
intersector).

-- 
Eric G. Miller <egm2 at jps.net>