[postgis-devel] Another question

[Nicklas Avén]

Thanks Paul  I think you are right about counting first and doing next is the right approach here. I have spent several hours in som home made solution of creating new arrays as they gets full and then copy it all in one big array at the end when I know the size.  I didn't know about realloc. Does that move everything to a larger array or does it link the arrays in some way? As I wrote in the other mail I don't think I should try a new approach now but instead take a step back and deliver a solid solution with the new fast algoritm without the subgeometry handling. I just hope that my difficulties is not connected to my LWGEOM-handling in general but to this subgeometry handling as I expect. But if the problem persist when I heve removed the subgeometry process I think I will commit and it should be quite easy for someone of you proff to see what I'm missing.  /Nicklas 

2009-11-18 Paul Ramsey wrote:

On Sun, Nov 15, 2009 at 11:56 PM, Nicklas Avén
> wrote:
>
>> 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?
>
>I generally start with a moderately large expected value, then realloc
>twice as much each time if I break that number. There's an example I
>just wrote today here:
>
>http://trac.osgeo.org/postgis/browser/trunk/liblwgeom/lwcollection.c#L599
>
>> 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?
>
>Sometimes a two-step process (first count, then do) results in a lot
>more code simplicity than a one-pass process that has to account for
>things simultaneously. You'll see that in the serialized_size
>routines, for example, that (a) walk the whole lwgeom finding the
>necessary size for the serialization then (b) malloc it and walk the
>whole lwgeom *again* writing it into the bufer.
>
>Computers are pretty fast, you can get away with that kind of thing...
>
>P.
>
>> /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
>>>
>>>
>> _______________________________________________
>> 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/20091118/abae3f8e/attachment.html>