[GRASS-dev] vector large file support

[Markus Metz]

Glynn Clements wrote:
> Markus Metz wrote:
>
>   
>> I suspect the bugs in rtree to be in index.c at line 119
>> b.child = (struct Node *)tid;
>> b.child is a pointer to the next node in the RTree. tid is the line 
>> number for which a new bounding box will be inserted in the RTree. This 
>> is a cast from integer to pointer, giving a compile time warning.
>> and at lines 284 - 286
>>             RTreeInsertRect(&(tmp_nptr->branch[i].rect),
>>                     (int)tmp_nptr->branch[i].child,      <-- cast from pointer to integer of different size
>>                     nn, tmp_nptr->level);
>>
>> I understand the concept of RTrees better than this code, but I suspect 
>> that at line 119, line number is used as memory address for a pointer 
>> and at line 285, the memory address of a pointer is used as line number. 
>> Can you developer cracks confirm that?
>>     
>
> ISTR something like that. This isn't necessarily a problem, so long
> as:
>
> 1. The field is wide enough to hold both types.
> 2. The code doesn't attempt to read an integer when a pointer was
> stored, and vice versa.
>   
That thing branch[i].child is a pointer to the next node in the tree, if 
I understand the code correctly. This is a standard tree design, not 
only of RTrees, but of many search trees. So your condition #2 would be 
violated, because a pointer is passed as an integer to 
RTreeInsertRect(). I believe the compile warning was there for a reason.
> Having said that, using a union would be preferable. Using distinct
> fields would be more robust (although use slightly more memory), as
> that would enable point #2 above to be verified at run-time.
>   
In my patch I am using two more fields in the branch structure and thus 
expected higher memory consumption, but for some unknown reason I end up 
with fewer internal nodes, which in turn means that memory consumption 
is lower and vector processing faster. I'm not complaining as long as 
everything works as before, now without segfault :-)
>> What should I do now? Submit a patch to trac or commit to trunk or leave 
>> it open for discussion?
>>     
>
> I suggest committing it. AFAIK, no-one really understands the rtree
> code, so I doubt that you'll get much feedback from a patch.
>   
OK, I want to test a bit more and have a closer look at the spatial 
index dumps. If I can't find crucial differences I will commit to trunk.