[postgis-devel] Another question

Paul Ramsey pramsey at cleverelephant.ca
Tue Nov 17 17:58:21 PST 2009


On Sun, Nov 15, 2009 at 11:56 PM, Nicklas Avén
<nicklas.aven at jordogskog.no> 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
>
>



More information about the postgis-devel mailing list