[postgis-devel] in_gml

Olivier Courtin olivier.courtin at oslandia.com
Sun Nov 21 11:33:37 PST 2010


On Nov 21, 2010, at 12:41 AM, Paul Ramsey wrote:

> In the in_gml regression, on *one* OS/X machine (but not another that
> is one the same versions of OS and compiler) I'm seeing failures in
> xlink_1 and xlink_11. I don't think this has anything to do with the
> code in xlink, I think I'm seeing a transient failure due to some
> other bad memory issues.


I could reproduce it on 2 Linux box 64 bits both
(on the other hand it works perfectly fine on my Mac)

But when i reproduce it, i also got 2 others regress:
measures and tickets, with for instance:

ERROR:  getPoint_internal called outside of ptarray range (n=0,  
pa.npoints=5, pa.maxpoints=-1)
On 3dDistancetest2

Do you think this could be linked ?

I create a ticket


> I think the final solution will be pulling the in_* code into
> liblwgeom where we can properly valgrind it in isolation.

Moving to liblwgeom should be anyway a good idea for
the  import functions.
But for GML one i met architecture issue before, see #444 comments.
Thoughts welcome !


>
>> Is there now with your new point array API a way to add point without
>> having to use dynamic point array ?
>
> [Snip Yes, ptarray_append_point and ptarray_insert_point ]

Ok thanks for the detailled explanation !

>
> Anyhow, I have to track down the issues Regina has found first, then I
> should look at flipping the parsers and emitters over to the new code.
> Everything is becoming quite interdependent. In fact, your FLAGS refit
> is now pretty key, since it will allow me to flag ptarrays that are
> created on top of memory they don't own as READ-ONLY, so we can avoid
> nastiness.
>
> Incidentally, you'll note there's a liblwgeom_internal.h header file
> now where I'm trying to move truly internal function signatures.
>
> This whole process has also led me back into the ./postgis directory
> where I'm finding a surprising amount of core code that has to be
> ported back into liblwgeom :)
>
> Anyhow, I'm looking forward to your FLAGS work going in, it will make
> it easier to complete the ptarray API in a rational way.

FLAGS patch is now commited,


> If, while you're at it, you can change lwgeom->SRID to lwgeom->srid,
> that would warm my pedant's heart. I hate having that attribute upper
> case while all the others are lower case.

I think it could be done in the same time than moving -1 to SRID_UNKNOWN


> Are you changing over the bbox (from BOX2DFLOAT4 to GBOX) in this pass
> too? If not, that should be your next goal, IMO.

Yeap that was done,
Now we have GBOX in each LWGEOM.

Next step on this, will be to serialize GBOX
And then to remove all box2dfloat stuff.

--
Olivier



More information about the postgis-devel mailing list