As another take on this same problem we've been working on a Z-order occlusion based distributed renderer. (This is for an accumulo <-> geoserver datastore implementation).
Currently working is a point only implementation (well, it works for polygons/linestrings, but calculates occlusion for the centroid only - so only works "right" for points)) It's implemented as a WPS render transform process https://github.com/ngageoint/geowave/blob/f40a547a5227540d1b68bd75ab2057ecc7ed00cd/geowave-gt/src/main/java/mil/nga/giat/geowave/gt/DecimationProcess.java Here's the query setup code https://github.com/ngageoint/geowave/blob/f40a547a5227540d1b68bd75ab2057ecc7ed00cd/geowave-gt/src/main/java/mil/nga/giat/geowave/gt/SpatialDecimationQuery.java Index thinning https://github.com/ngageoint/geowave/blob/f40a547a5227540d1b68bd75ab2057ecc7ed00cd/geowave-gt/src/main/java/mil/nga/giat/geowave/gt/FixedCardinalitySkippingIterator.java This implementation doesn't distribute the rendering process; rather it defines a pixel space -> index range transform function, and when a feature (point in this case) is found it's returned, and the seek function in the database skips to the next pixel Here's a graphic example: https://dl.dropboxusercontent.com/u/6649380/decimation.png -- The next phase, and what I think a general solution to the problem you describe is to distribute the rendering process (in accumulo the database "nodes" sit on top of multiple instances for easy horizontal scalability). This portion has to take into account the SLD selected as well, as the style can have a big impact on how features are rendered. Basically each featurestylerule results in a distributed call for that feature type - and the tile for that rule is rendered local to the majority of the data (best effort) in the cluster. When the tile is completely covered (or passes some heuristic, i.e. 80%, etc.) the seek stops and the "full" tile returns. (There is some skipping here to - when a feature is rendered an internal table of index ranges <-> pixel transforms is modified to remove the covered pixels/ranges - so the next feature always overlaps a non-colored region.) All the tiles are now composted together in geoserver based on the ordering from the SLD - and hopefully we have now skipped reading and writing a bunch of data we don't have a "pixel budget" to actually display. This portion is still in work - I think we might have an upcoming geoserver pull request, as we need to make a few private methods protected so we can distribute the render process across the cluster. Our internal implementation just cuts and pastes a bunch of GPL code, and I didn't want to include that since the rest of the project is apache 2.0 and, well, I didn't want to explain the intermingled licenses. Our torture case right now is basically one of the openstreetmap SLD's at ~ zoom level 17 rules, rendered globally (with the full osm planet dump). -- That said, these methods have to be implemented at the geotools datastore level - and specifically you have to have control enough of the indexing so that you can short circuit reads. But it's something that could conceptually (implementation would be slightly different) be to other systems as well (certainly on postgis, since it's open source) On Tue, Aug 12, 2014 at 2:01 PM, PREVOSTO, Laurent <laurent.prevo...@sfr.com > wrote: > Hi, > > I understand your approach but i definately prefer to draw nothing or an > “error” tile than just draw a random part of the network (a wrong > information) > > Because, users tend to believe what they see J > > > > In my case, I am tempted to lower the timeout rendering of geoserver and > consider that a tile that needs more than, let’s say, 10 sec to draw is not > worth rendering. > > But then Apache mod_jk load-balancer put that very Tomcat in FAIL state > and I could not figure out a configuration that actually works. > > > > Regards, > > > > Laurent > > > > *De :* Mike Grogan [mailto:d.michael.gro...@gmail.com] > *Envoyé :* vendredi 8 août 2014 18:04 > > *À :* PREVOSTO, Laurent > *Cc :* geoserver-users@lists.sourceforge.net > *Objet :* Re: [Geoserver-users] Limiting rendering for large resultsets > > > > A crude approach I have used in the past is to add an integer attribute to > my points or lines and then to assign a random attribute value from a range > that is based on the density of features in the area. I then specify in > the SLD that only features greater than some number should be displayed for > particular zoom levels. > > > > For instance, > > > > For your city features, you might assign a random integer attribute to > each of them from a range between, say, 0 and 1000. > > > > For your countryside features, you might assign a random integer attribute > that have a range between 700 and 1000. > > > > Then, say for a zoom level 5 or 6, you might specify in the SLD to only > show features whose attribute > 700. > > > > Doing this, you end up keeping all of the countryside features, but > randomly filtering out city features. > > > > At greater zoom levels ... just say 9, 10, or so (depending on your > situation), you then show features whose attribute > 500, 400, etc., > thereby allowing more city features to be shown as you zoom in. > > > > I could probably have done some statistics to tell me the exact ranges to > use, but trial & error worked fine for me. > > > > - Mike Grogan > > > > > > > > > > On Wed, Aug 6, 2014 at 5:39 AM, PREVOSTO, Laurent < > laurent.prevo...@sfr.com> wrote: > > Hello, > > We have geoserver based WMS services that display a quite large network > (lots of points and polylines stored in an Oracle Spatial database). > > > > When in the cities, the number of items can be very large > > In the countryside, of course, the density of polylines is quite low. > > > > If I try to render a whole city, since there are too many items to > render, the request will timeout. > > But if I set a scale condition to avoid drawing thousands of lines when in > a large city, users complain that they can’t find the cables when in the > countryside… > > > > So my question was : is there a way to tell geoserver to render a blank > image if there are more than n items in the Oracle resultset ? > > That way, I could keep a large scale in my TLD without going timeout in > areas where there is a high density of items. > > > > Regards, > > > > Laurent > > > > ------------------------------------------------------------------------------ > Infragistics Professional > Build stunning WinForms apps today! > Reboot your WinForms applications with our WinForms controls. > Build a bridge from your legacy apps to the future. > > http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk > _______________________________________________ > Geoserver-users mailing list > Geoserver-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-users > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Geoserver-users mailing list > Geoserver-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-users > >
------------------------------------------------------------------------------
_______________________________________________ Geoserver-users mailing list Geoserver-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-users
