[fdo-internals] Please review FDO RFC 38 - Multi-polygon support for SHP

[Frank Warmerdam]

Traian Stanev wrote:
> It can be optimized but the cost will never be zero, like it is now... I
> guess we will have to find some sample data to compare the performance
> before and after, but from what I remember last time we had this check, it
> made rendering intolerably slow for some data sets (if you compared SHP to
> the equivalent SDF).
> 
> Another thing to consider is that there are other providers which don't
> validate geometry like that -- SDF, SQLite for example -- so client code
> will still have to compensate for polygons whose rings are disjoint so
> should be treated as multipolygons, regardless of whether the SHP provider
> fixes the geometry.

Traian,

I believe that SDF and SQLite already have a proper representation for
multipolygons.  It's possible they contain invalid data of course, but in
general use there is not reason to doubt them.

> So I'd argue that the fixing of the geometry should be done by code that
> requires it to be fixed -- i.e. take the performance hit only when
> necessary. This way rendering would not have to suffer the performance hit.

I would argue that a connection parameter for the shape provider indicating
whether to emphasize correctness or speed would be useful.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent