[postgis-devel] Another question

[Nicklas Avén]

Tahnks PaulI found it, I had missed to check if LWGEOM had bbox. The subgeometries I pulled , naturally had no bboxes and that caused very strange errors much earier in the code than I expected. Now I think I have it working with LWGEOM, but ehen I dis the rewriting I did at the same time make some other changes.I wanted to get the part ordering the combinations of subgeometries by thair distances to be a isolated process which can be called in other situations. The problem then is that I don't know before how many combinations I will get. I collect combinations that is closer than the geometries with closest max-distance between bboxes. Than I know I have the geometries that is closest collescted. But I don't know from before if the function will generate a list of 10 or 500 combinations. What is the common way to handle that.Before (in the spike now), since I didn't needed the process to deliver this list I just said that is the number of combinations exceeds 200, execute !
 those and come back for more. All I risked was some performance.
I have tries to read some about handling lists of unknown length, bu it seems like there can be many different ways handle it.Is there a "best way" of doing it? The call I hope to solve by sending a void pointer to the function and then get the number of items in the list in return and then define the length of the list in the calling functions afterwards. Is that a possible way for that? /Nicklas
2009-11-15 Paul Ramsey wrote:

The actual allocation of space for these things is handled in a
>type-aware way, so that they are properly sized. LWGEOM is just a
>superclass so that they can be passed around to different
>functionality without having to be aware of what's inside (only the
>'type' number has any real important meaning).
>
>The lwcollection_getsubgeom() appears to be doing internally what I
>end up writing out anyways, which is collection->geoms[i] to retrieve
>the subgeometry. So that's not the source of your crashes (getting a
>bad count for numgeoms, on the other hand, would do it).
>
>P.
>
>On Sun, Nov 15, 2009 at 8:24 AM, Nicklas Avén
> wrote:
>> Hallo
>>
>> I'm trying to get my distance-code working with LWGEOM from early in the
>> process. From some hours of frustration I have to ask what I'm missing.
>>
>> If I look at lwgeom_deserialize()
>>  http://postgis.refractions.net/documentation/postgis-doxygen/d3/dc8/lwgeom_8c-source.html#l00022
>>
>> I see that the function is returning tye LWGEOM
>> LWGEOM looks like this:
>> typedef struct
>> {
>>  uchar type;
>>  BOX2DFLOAT4 *bbox;
>>  uint32 SRID;
>>  void *data;
>> }
>> LWGEOM;
>>
>> so it needs 16 bytes (?) according to sizeof()
>>
>> But lwgeom_deserialize is also supposed to return Multigeometries and
>> linestrings and polygons. Thosa all have an integer more than LWGEOM.The
>> integer number of geometries for Multi geometries and number of rings for
>> LWPOLY. That makes those types needing 20 bytes.
>>
>> I wouldn't dare to say something is wrong here but I get strange server
>> crashes when using lwcollection_getsubgeom()
>> Since I don't see lwcollection_getsubgeom() is used by any other process I
>> get little suspicous that it is not that hard tested.
>> I hope I'm just stupid here, but want to find out in what way :-)
>>
>> Thanks
>> Nicklas
>>
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>_______________________________________________
>postgis-devel mailing list
>postgis-devel at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091116/7db3d1f2/attachment.html>