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

[David D Gray]

Eric G. Miller wrote:

> On Sun, 06 Jan 2002 01:40:39 +0000, David D Gray <ddgray at armadce.demon.co.uk> wrote:
> 
> [...]
> 
>>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.
> 
> 

Hi Eric

Lines are not really split. what happens is that as lines are extracted 
they are added to the database, keyed on position (but this is just an 
identifier, we don't need to have storage that can do spatial search.) 
Links are stored as part of the structure that holds a vertex. On 
re-extraction, nodes are identified (not always correctly) as vertices 
with 3 or more links, and we track the links from one node to another as 
a separate `line', whose vertices are marked blank so as not to be 
traversed again.


> [...]
> 
> 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).
> 
> 


Yes, I had followed some of the discussion about this, but didn't have 
time to do much about it. The import stuff and vector5.1 have priority 
for me, but its worth having a look at as it may give some indicator as 
to how we manage the thorny problem of intersections.

David