Hi, ST_Simplify tends to return every now and then invalid geometries from polygon layers. What happens when Geoserver meets for example a big simplified lake with self-intersection? I know that Mapserver is sensitive for self-intersections and the lake might be dropped or even the whole request can fail. On the other hand, Thomas Bonfort wrote:
"MapServer already simplifies geometries at the pixel level before sending them to the renderers, and from my testing at the time was more efficient at doing so than using st_simplify(), with the added bonus that the cellsize (resolution, units per pixel) does not need to be factored in the actual SQL query, and that the simplification applies to all data backends. Doing the simplification inside postgis does however make sense if the data transfer from db to mapserver is a bottleneck, and/or potentially if reprojection is involved (as less points would need to be fed into proj)". Have we considered pixel level simplification, what ever it is? -Jukka Rahkonen- ________________________________ Andrea Aime wrote: > Hi, > if you have followed the previous benchmarking related threads the usage of > ST_Simplify over the Warwickshire data set provided a significant benefit, but as said in that thread, it was also due to the "business" of those maps (lots of data). > The FOSS4G 2010 benchmark on the other side has maps using far less data, and > using it quite a bit close to its native resolution. So I wanted to make a test and see if using ST_Simplify had some benefits, or caused slowdowns. > And the result is (in requests per second at various load levels): Threads Postgis - vanilla Postgis - ST_Simplify Throughput difference compared to vanilla 1 21,19 21,74 2,61 2 34,57 33,62 -2,72 4 52,22 51,69 -1,01 8 62,70 63,96 2,01 16 67,54 72,35 7,11 32 61,82 66,77 8,02 64 60,54 63,23 4,44 > The benchmark has been run using OpenJDK and the current trunk, that has PNGJ > merged and enabled by default. > As you can see the ST_Simplify usage provides a insignificant slowdown in a > couple of cases, and some light speedup in the higher thread counts. > Well, with the evidence gathered so far, it seems having it enabled by > default is a win. Shall we go ahead and make it the default for 2.5.x? Do we want to roll a system variable to disable it just in case someone stumbles into issues with it? (we could also roll a store parameter, but if we do it would have to stay there for a long time...) Cheers Andrea -- == GeoSolutions will be closed for seasonal holidays from 23/12/2013 to 06/01/2014 == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
