4

I think it is time to re-design the result presentation of my reachability analyses (which are computed using multimodal isochrones).

Right now I am just showing a multipolygon on a leaflet map that indicates, if a street is reachable or not. However, I really think that I'd make sense to dim the rest of the leaflet map so what I want is to "enlighten" the reachable area.

In fact this was not that hard to do when using GeoJSON and leaflet. I only had to built a polygon where the outer ring spreads over the whole world and the inner rings are the polygons from the computed MultiPolygon.

So I got from this presentation: Isochrone visualization before (Isochrone visualization in bolzano, base layer from © OpenStreetMap contributors)

to that one: Isochrone visualization after changes (Isochrone visualization in bolzano, base layer from © OpenStreetMap contributors)

That is exactly what I want, but - as you can easily guess - I would not post this question, if everything has already been solved :-)

The problem is that when I use Geoserver to deliver WMTS tiles instead of GeoJSON, things get a bit weird.

But first things first... lets explain my Geoserver/Java/PostGIS setup a bit:
I am using Java to calculate isochrones that then can be visualized on a map. Java communicates with Geoserver and PostGIS. At first, I create the GeoJSON layers (and the workspace and the datastore) in Java and then my computation results are stored using PostGIS tables that are then used by Geoserver.

My first thought is that all I need to do is to use ST_Difference in PostGIS to achieve what I want. Of course a big poylgon has to be used together with ST_Difference, so for my projection (EPSG:3857) I tried to build the difference with that polygon

'POLYGON((-20026376.39 -20048966.10, -20026376.39 20048966.10, 20026376.39  20048966.10, 20026376.39 -20048966.10, -20026376.39 -20048966.10))'

From what I can see within PostGIS that idea of mine works great. When converting the result to GeoJSON (and to EPSG:4326) the result is the expected one when visualized with GeoJsonLint.

But not when using the layer that is provided by Geoserver.
In this case the Geoserver layer dims the whole world and the inner elements of the polygons are missing. Even more wired is that when I tried to use a smaller masking polygon by accident, Geoserver shows the inner elements correctly. The smaller polygon I used is this one:

'POLYGON((-10000000.00 -10000000.00, -10000000.00  10000000.00, 10000000.00  10000000.00, 10000000.00 -10000000.00, -10000000.00 -10000000.00))'

Here is some data that can be used for testing.
It shows a very small isochrone over bolzano... not as big as the one in the pictures above. It uses EPSG:3857 and WKT. Do not care about the "MULTIPOLYGON" type... that's just there so it can be stored in the same table as the old representation.

Working with geoserver:

MULTIPOLYGON(((-10000000 -10000000,-10000000 10000000,10000000 10000000,10000000 -10000000,-10000000 -10000000),(1263703.25522208 5860465.83248726,1263715.83196484 5860465.75420434,1263714.92461937 5860440.27420493,1263714.95531969 5860440.19192054,1263714.91949477 5860440.11173447,1263714.06118938 5860408.87153549,1263712.34668544 5860374.30842544,1263712.70175723 5860373.31457192,1263712.34698648 5860372.32061089,1263714.48057553 5860329.57073682,1263721.03609557 5860315.73817625,1263735.45264563 5860310.59253154,1263749.28520621 5860317.14805159,1263754.43085091 5860331.56460165,1263752.34686607 5860373.32057592,1263754.02301501 5860407.11047801,1263753.94291004 5860407.33469354,1263754.04003213 5860407.55207963,1263754.9021743 5860438.93192778,1263755.82774871 5860464.92383092,1263797.70961396 5860463.42673455,1263812.05198292 5860468.77566224,1263818.41130623 5860482.69951164,1263813.06237854 5860497.04188061,1263799.13852914 5860503.40120392,1263757.61312918 5860504.88555819,1263759.89525378 5860547.46943944,1263754.8025924 5860561.90479102,1263740.99420201 5860568.51107061,1263726.55885044 5860563.41840923,1263719.95257084 5860549.61001885,1263717.60173289 5860505.74396342,1263696.32008009 5860505.87642934,1263696.19602274 5860505.9274539,1263690.34299244 5860505.91287365,1263673.69730521 5860505.87140825,1263659.56980571 5860499.97833325,1263653.74718831 5860485.82164926,1263659.64026331 5860471.69414976,1263673.7969473 5860465.87153235,1263677.38817805 5860465.88047833,1263690.42281294 5860460.49937365,1263703.25522208 5860465.83248726)))

Not working with geoserver

MULTIPOLYGON(((-20037508.34 -20048966.1,-20037508.34 20048966.1,20037508.34 20048966.1,20037508.34 -20048966.1,-20037508.34 -20048966.1),(1263703.25522208 5860465.83248726,1263715.83196484 5860465.75420434,1263714.92461937 5860440.27420493,1263714.95531969 5860440.19192054,1263714.91949477 5860440.11173447,1263714.06118938 5860408.87153549,1263712.34668544 5860374.30842544,1263712.70175723 5860373.31457192,1263712.34698648 5860372.32061089,1263714.48057553 5860329.57073682,1263721.03609557 5860315.73817625,1263735.45264563 5860310.59253154,1263749.28520621 5860317.14805159,1263754.43085091 5860331.56460165,1263752.34686607 5860373.32057592,1263754.02301501 5860407.11047801,1263753.94291004 5860407.33469354,1263754.04003213 5860407.55207963,1263754.9021743 5860438.93192778,1263755.82774871 5860464.92383092,1263797.70961396 5860463.42673455,1263812.05198292 5860468.77566224,1263818.41130623 5860482.69951164,1263813.06237854 5860497.04188061,1263799.13852914 5860503.40120392,1263757.61312918 5860504.88555819,1263759.89525378 5860547.46943944,1263754.8025924 5860561.90479102,1263740.99420201 5860568.51107061,1263726.55885044 5860563.41840923,1263719.95257084 5860549.61001885,1263717.60173289 5860505.74396342,1263696.32008009 5860505.87642934,1263696.19602274 5860505.9274539,1263690.34299244 5860505.91287365,1263673.69730521 5860505.87140825,1263659.56980571 5860499.97833325,1263653.74718831 5860485.82164926,1263659.64026331 5860471.69414976,1263673.7969473 5860465.87153235,1263677.38817805 5860465.88047833,1263690.42281294 5860460.49937365,1263703.25522208 5860465.83248726)))

So all in all I have two major questions:
1. How can this behavior be explained? Does Geoserver use the extend of the layer to interpolate results in some way (so that my small inner element is lost when using a large outer polygon mask)? Can this be changed somehow?
2. Is there an other way to achieve what I want when using Geoserver. Maybe something related to a Style definition??

  • do you have simplification turned on in the postgis store? it may be deleting your small area holes – Ian Turton Jul 14 '16 at 16:09
  • I just double-checked that. In the store simplification is turned off. Only "prepared statements" and "loose bbox" are enabled (I tried to turn both of them off, but even then... no change in behavior) – Nikolaus Krismer Jul 14 '16 at 22:56
  • can you add the WKT of a simplish polygon that shows this behaviour to the question? – Ian Turton Jul 15 '16 at 8:47
  • added WKT some test data.. @iant: thanks for the suggestion :-) – Nikolaus Krismer Jul 16 '16 at 11:21
  • I know it is not related to the topic but any chance to share the isochrome generating code? just for education purposes.. – Balazs Jul 19 '16 at 15:28
3

Try to disable the "Support on the fly geometry simplification" parameter in the postgis store configuration in GeoServer. And make sure your polygon stays within the "world" boundaries, best if it's not touching the datelines. Also disable "advanced projection handling" in the WMS settings

  • That's what iant already asked in a comment... the parameter is already disabled. – Nikolaus Krismer Jul 17 '16 at 9:38
  • I also just double-checked the coordinate bounds again: using a polygon from -20000000.00 to 20000000.00 (for x and y; which are valid coordinates according to openlayers doc and from within twcc.fr) does not work (although it should) – Nikolaus Krismer Jul 17 '16 at 9:51
  • Which version of GeoServer are you using again? – Andrea Aime Jul 17 '16 at 20:13
  • It's version 2.9.0 (stable) (with fedora 24 and jdk 1.8.0_92) – Nikolaus Krismer Jul 17 '16 at 21:32
  • 1
    Try disabling the advanced projection handling in WMS. It has a reprojection heuristics that assumes anything larger than half a globe is the result of a "around the dateline" projection and it sets up to unwrap it, generating a new polygon sitting around the dateline (think about having a polygon in 4326 across the dateline, reproject it to 4326, and you get one with world wrapping east to west lines which is wrong). If you have better (and still fast) way to detect a world wrap reprojection event I'm all ears! – Andrea Aime Jul 18 '16 at 14:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.