[postgis-devel] WKT Parser changes for Curve support

[Mark Leslie]

Mark Cave-Ayland wrote:
> Mark Leslie wrote:
> 
>> I've cobbled together a quick RFC describing some changes I'd like to 
>> impose upon the parser in order to support the CompoundCurve and 
>> CurvePolygon properly.  I've committed it to trunk: 
>> http://svn.refractions.net/postgis/trunk/doc/rfc/postgis_rfc_04.txt
>>
>> The short summary is that our practise of using global variables to 
>> define constraints such as minimum number of points or ring closure no 
>> longer work once we start dealing with nesting of multiple geometry 
>> types and constraints between sub-geometries, such as checking the 
>> continuity of a compound curve.
>>
>> My proposed change moves the validation to the level of a complete 
>> geometry, instead of validating each point array on completion.  The 
>> down sides are that it will need to traverse the list of tuples to 
>> properly validate which can only degrade performance, and it will no 
>> longer report which point array is in violation of a given constraint, 
>> only which geometry.
>>
>> Please have a look at the rfc and share any comments you have.
> 
> 
> Hi Mark,
> 
> I've had a read of the RFC and must admit I'm not happy about losing 
> positional information in the geometry - this has helped me several 
> times in testing, and this is before it's even hit any live servers.
> 
> I agree that the use of global variables in the parser is particularly 
> bad and would love to see them go. My thoughts at the moment are that it 
> would make more sense to push the constraints onto the stack (i.e. add 
> an extra field to the tuple) so that when you reach the end of an inner 
> geometry, a pop/popc() call would check the existing constraints and 
> then restore the previous ones.
> 
> 
> ATB,
> 
> Mark.
> 

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.

Have I understood this correctly?

Mark Leslie
Geospatial Software Architect
LISAsoft