[postgis-devel] WKT Parser changes for Curve support

[Mark Cave-Ayland]

Mark Leslie wrote:

> Hmm, I gave something like that a try and it turned into a mess when 
> trying to find the geometry tuple from the counting tuple where the 
> validation occurred.  But it sounds like you're suggesting having the 
> global variables, but restoring them when popping a geometry. Hmm.
> 
> The reason it became a mess before was that the geometry tuple had the 
> flags while the counting tuples were validated.  This meant that it 
> would have to look one or more tuples into the stack to find the correct 
> flags depending on teh geometry type, but it had to sort this out with 
> no knowledge of the geometry type.  The globals would actually solve 
> that.  So the constraint flags would be stored globally again as well as 
> in the stack.  The stack would also preserved any previous flags.  popc 
> would validate as before and pop would restore any previously stored flags.
> 
> There would still need to be a fancier check for the continuity of a 
> compound curve, since that can't be applied on each point arrays counter 
> but needs the sub-geometry counter tuple.  I might be able to handle 
> that in a manner similar to the is-closed check.

I think there are already strange hacks in the counting tuples for 
supressing the prefix for certain parts of a CURVEPOLYGON IIRC, so you 
may be able to hack into one of those.

> Have I understood this correctly?

I think so; the other option of course is to stick with that you are 
doing and add the parser position as part of the tuple. Hence when you 
check the geometry retrospectively, you can still correctly return the 
error position back to PostgreSQL.


HTH,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063