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

[Dan Stoica]

> indicating whether to emphasize correctness or speed would be useful.

What if the geometry is cached? E.g. initially fetched for speed and later used for spatial queries?

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Thursday, July 16, 2009 3:28 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] Please review FDO RFC 38 - Multi-polygon support for SHP



> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Frank Warmerdam
> Sent: Thursday, July 16, 2009 3:19 PM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] Please review FDO RFC 38 - Multi-polygon
> support for SHP
> 
> 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.
> 

Unless someone used a tool like a current version Map3D to export from SHP
to SDF via FDO. But in general yes, I agree that it's a different 
situation since they can represent multi-polygons natively.

> > 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.
> 

Will there be a setting for "Both". :)

> 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
> 
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals