[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