[GRASS-dev] vector large file support

Markus Metz markus.metz.giswork at googlemail.com
Mon Feb 16 05:38:56 EST 2009


Moritz Lennert wrote:
> On 15/02/09 11:14, Markus Metz wrote:
>
>> Can you developer cracks confirm that?
>
> I am not in this category at all... So, sorry, but this will have to 
> be between Glynn and you.
OK, let's hope for Glynn's comments.
>
>> What should I do now? Submit a patch to trac or commit to trunk or 
>> leave it open for discussion?
>
> I don't think anyone is actually seriously working on the vector libs 
> (Glynn, correct me if I'm wrong), so I would think that as long as you 
> test carefully before doing so, and announcing what you commit, I 
> would plead for committing to trunk so that it gets tested as widely 
> as possible.
More on the spatial index. With my patch, all the entries, i.e. all 
bounding boxes for all features in the vector, are still in the RTree, 
therefore in the spatial index. The patched RTree has less internal 
nodes than the original RTree. These internal nodes (level > 0) are 
created by the RTree algorithm during insertion and deletion to help 
find the items you are looking for, say all lines overlapping with a 
search bounding box. The bboxes of these lines are RTree leaves aka 
branches of a node with level 0. The original RTree is blowing up the 
number of internal nodes and bboxes, maybe also creating duplicate 
leaves, very difficult to debug.
>
> We definitely need someone who has your expertise in coding 
I don't have enough expertise in coding for the vector libs. I am 
willing to put effort in these, but I need the help of you developers. I 
think my mind is weird enough to wrap itself around n-dimensional 
RTrees, other search trees, A * Search, sorted heaps, and the like. My 
coding has to be cross-checked though, I can point to the parts where 
I'm not sure if this is right.
BTW, what is this btree in the libs (lib/btree)? It is used by r.mapcalc 
and looks like an unbalanced binary search tree, but I could not find 
any documentation or helpful comments. Glynn, do you know more?
> and knows the vector stuff intimately
I start to understand it, i.e. I could find and fix some bugs, but 
substantial changes are beyond me. LFS would be an additional feature, 
that is relatively easy to add, but I don't want to try to change e.g. 
the topology building process. Never touch a running system.
> , since ASAIK it has been more or less orphaned since Radim left the 
> development team.
Which is really a pity because the GRASS vector model is quite powerful, 
but it could do with a bit of updating.

Markus M



More information about the grass-dev mailing list