<html>
<head>
<title></title>
<meta name="GENERATOR" content="MSHTML 8.00.6001.18852"></meta>
</head>
<body>Thanks Paul
<div align="left"> </div>
<div align="left"> </div>
<div align="left">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. </div>
<div align="left"> </div>
<div align="left">I didn't know about realloc. Does that move everything to a larger array or does it link the arrays in some way?</div>
<div align="left"> </div>
<div align="left">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.</div>
<div align="left"> </div>
<div align="left">I just hope that my difficulties is not connected to my LWGEOM-handling in general but to this subgeometry handling as I expect. </div>
<div align="left">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.</div>
<div align="left"> </div>
<div align="left"> </div>
<div align="left">/Nicklas</div>
<div align="left"> </div>
<div align="left"><br />
<br />
2009-11-18 Paul Ramsey wrote:<br />
<br />
On Sun, Nov 15, 2009 at 11:56 PM, Nicklas Avén<br />
>
<nicklas.aven@jordogskog.no></nicklas.aven@jordogskog.no> wrote:<br />
><br />
>> Before (in the spike now), since I didn't needed the process to deliver this<br />
>> list I just said that is the number of combinations exceeds 200, execute<br />
>> those and come back for more. All I risked was some performance.<br />
>> I have tries to read some about handling lists of unknown length, bu it<br />
>> seems like there can be many different ways handle it.<br />
>> Is there a "best way" of doing it?<br />
><br />
>I generally start with a moderately large expected value, then realloc<br />
>twice as much each time if I break that number. There's an example I<br />
>just wrote today here:<br />
><br />
>http://trac.osgeo.org/postgis/browser/trunk/liblwgeom/lwcollection.c#L599<br />
><br />
>> The call I hope to solve by sending a void pointer to the function and then<br />
>> get the number of items in the list in return and then define the length of<br />
>> the list in the calling functions afterwards. Is that a possible way for<br />
>> that?<br />
><br />
>Sometimes a two-step process (first count, then do) results in a lot<br />
>more code simplicity than a one-pass process that has to account for<br />
>things simultaneously. You'll see that in the serialized_size<br />
>routines, for example, that (a) walk the whole lwgeom finding the<br />
>necessary size for the serialization then (b) malloc it and walk the<br />
>whole lwgeom *again* writing it into the bufer.<br />
><br />
>Computers are pretty fast, you can get away with that kind of thing...<br />
><br />
>P.<br />
><br />
>> /Nicklas<br />
>> 2009-11-15 Paul Ramsey wrote:<br />
>><br />
>> The actual allocation of space for these things is handled in a<br />
>>>type-aware way, so that they are properly sized. LWGEOM is just a<br />
>>>superclass so that they can be passed around to different<br />
>>>functionality without having to be aware of what's inside (only the<br />
>>>'type' number has any real important meaning).<br />
>>><br />
>>>The lwcollection_getsubgeom() appears to be doing internally what I<br />
>>>end up writing out anyways, which is collection->geoms[i] to retrieve<br />
>>>the subgeometry. So that's not the source of your crashes (getting a<br />
>>>bad count for numgeoms, on the other hand, would do it).<br />
>>><br />
>>>P.<br />
>>><br />
>>>On Sun, Nov 15, 2009 at 8:24 AM, Nicklas Avén<br />
>>> wrote:<br />
>>>> Hallo<br />
>>>><br />
>>>> I'm trying to get my distance-code working with LWGEOM from early in the<br />
>>>> process. From some hours of frustration I have to ask what I'm missing.<br />
>>>><br />
>>>> If I look at lwgeom_deserialize()<br />
>>>><br />
>>>> http://postgis.refractions.net/documentation/postgis-doxygen/d3/dc8/lwgeom_8c-source.html#l00022<br />
>>>><br />
>>>> I see that the function is returning tye LWGEOM<br />
>>>> LWGEOM looks like this:<br />
>>>> typedef struct<br />
>>>> {<br />
>>>> uchar type;<br />
>>>> BOX2DFLOAT4 *bbox;<br />
>>>> uint32 SRID;<br />
>>>> void *data;<br />
>>>> }<br />
>>>> LWGEOM;<br />
>>>><br />
>>>> so it needs 16 bytes (?) according to sizeof()<br />
>>>><br />
>>>> But lwgeom_deserialize is also supposed to return Multigeometries and<br />
>>>> linestrings and polygons. Thosa all have an integer more than LWGEOM.The<br />
>>>> integer number of geometries for Multi geometries and number of rings for<br />
>>>> LWPOLY. That makes those types needing 20 bytes.<br />
>>>><br />
>>>> I wouldn't dare to say something is wrong here but I get strange server<br />
>>>> crashes when using lwcollection_getsubgeom()<br />
>>>> Since I don't see lwcollection_getsubgeom() is used by any other process<br />
>>>> I<br />
>>>> get little suspicous that it is not that hard tested.<br />
>>>> I hope I'm just stupid here, but want to find out in what way :-)<br />
>>>><br />
>>>> Thanks<br />
>>>> Nicklas<br />
>>>><br />
>>>><br />
>>>> _______________________________________________<br />
>>>> postgis-devel mailing list<br />
>>>> postgis-devel@postgis.refractions.net<br />
>>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>>><br />
>>>><br />
>>>_______________________________________________<br />
>>>postgis-devel mailing list<br />
>>>postgis-devel@postgis.refractions.net<br />
>>>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>>><br />
>>><br />
>> _______________________________________________<br />
>> postgis-devel mailing list<br />
>> postgis-devel@postgis.refractions.net<br />
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
>><br />
>><br />
>_______________________________________________<br />
>postgis-devel mailing list<br />
>postgis-devel@postgis.refractions.net<br />
>http://postgis.refractions.net/mailman/listinfo/postgis-devel<br />
><br />
></div>
</body>
</html>