This transmission is intended for the named addressee(s) only and may contain confidential, sensitive or personal information and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.
···
Note that if you are using PostGIS (or Oracle?) GeoTools will ask the database to simplify
Andrea will know better (of course!), but I think last time this came up the notion was that Oracle’s no-where near as good as PostGIS at this.
Cheers,
Jonathan
On 13 August 2014 07:22, Jody Garnett <jody.garnett@anonymised.com> wrote:
Interesting, I am reminded of the gvSig renderer which can “draw” the shapefile index - getting off the ride when the index node gets down below the size of a pixel. Think that is one of the only optimisations they have left that we did not implement.
Note that if you are using PostGIS (or Oracle?) GeoTools will ask the database to simplify (stepping size based on the distance a pixel covers at current zoom level). This is great as it allows less data to be sent over from the database. For most other data stores it will simplify in Java before transform and rendering.
Chris it would be great if you could write the occasional blog for the geotools website - this is really cool stuff you are working on.
Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
Jody Garnett
On Tue, Aug 12, 2014 at 5:36 PM, Chris Bennight <chris@anonymised.com> wrote:
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)
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
On Tue, Aug 12, 2014 at 2:01 PM, PREVOSTO, Laurent <laurent.prevosto@anonymised.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.grogan@anonymised.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.
On Wed, Aug 6, 2014 at 5:39 AM, PREVOSTO, Laurent <laurent.prevosto@anonymised.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
