[geos-devel] GEOS Exceptions
artem at pavlenko.uklinux.net
Tue Apr 19 08:46:51 EDT 2005
>Parsing WKT includes creation of GEOS objects, which is probably
>different then creating Mapnik objects.
Yep, in my test I'm creating a 'dummy' geometries, something like
vector<pair<double,double> > ponts;
>A fair test would be implementing it in GEOS and see how it compares
>with current GEOS wkt parser (CVS version).
Yes, I'll be into that. Once I conquer SLD/Filter I'll be able to do that.
>GEOS development has so far followed JTS development (slowly, very slowly).
>Easy of maintainence currently goes with easy of comparison with JTS.
Umm...? It also runs " ..slowly, very slowly.."
Better design == easy maintenance
>Since JTS is getting its own C/C++ wrappers this might change in the
>future letting GEOS take its own path, but I can't tell how long would
>it take and if that would be worth the trouble.
Are you serious? C/C++ wrappers is the future?
Anyway, what about Dale Lutz efforts? Are we going to see those changes?
Is it going to be GEOS2?
Could we have GEOS2 experimental branch? I'd like to get involved if
anybody else is interested?
>BOOST usage has been discussed for other things as well (smart pointers)
>and I always tried to avoid dependency on it. Anyway, if it really gives
>us a good performance improvement and we can ship required headers with
>GEOS we can do it w/out big problems.
I dont see any problems with that. AFAIK current boost licence is
compatible with (L)GPL.
>>Also, I've noticed that GEOS using incorrect WKT grammar IMHO e.g
>>OpenGIS Simple Features Specification rev1.1 EBNF:
>><Point Text> := EMPTY | (<Point>)
>>According to ISO/IEC 14977 'EMPTY' means literally empty as far as I
>>and valid WKT for point geometry: POINT or POINT (x y)
>>The same applies to the rest.
>>Have you looked into that? Am i missing something?
>PostGIS parser doesn't also understand 'POINT' but handles 'POINT EMPTY'.
Add OGR to this list as well. If this is not correct let's change it now.
>... do you have knowledge of other WKT readers using that interpretation
>of OGC EBNF ?
Assuming 'that interpretation' means OGC Simple Features Specification,
then mapnik's parser is fully compatible with OGC EBNF for WKT. Anyway,
the point I'm trying to make is that it will take one liner change to go
from POINT EMPTY to POINT in grammar based parser. Not so easy with
I suspect cadcorp and others do a better job at parsing WKT:), but I
haven't tried it for a while
More information about the geos-devel