Large and Intersecting Polygons causing graphical glitches

[RossWorkman]

Describe the bug
Rare occurrence but when an extremely large polygon is used for a single feature, or a cluster of intersecting polygons is used for multiple feature, strange graphical glitches start to occur when zooming into the large polygon, including chunks of it suddenly being cut out.

To Reproduce
Steps to reproduce the behavior:

1. Open up default Arches landing page
2. Click on 'Search'
3. Locate or create a feature with a polygon of an abnormally large size
4. Begin to zoom in as close as possible to the feature and scroll up and down its length
5. Chunks of the Polygon will disappear at certain points of the Polygon

Screenshots

Expected behavior
Polygon shape should remain consistent despite the zoom level

Your Arches Information

• Version used: 4.4.1
• Operating System and version: Windows 7
• Browser Name and version: Chrome and Firefox, Desktop

[RossWorkman]

Hey folks.
Could you let me know when you've got a chance to look over this issue and update me on its progression, as the current project I am working on needs to know if we will have to go live with this issue in place. Either in this thread or to my email ([email protected]) would be much appreciated.

Thanks!

[dwuthrich]

This issue appears to be related to Tilestache, the library Arches uses to create and manage vector map tiles for resource instances. I can confirm that Tilestache creates odd vector tiles under the conditions described in this ticket and a user zooms the map to a high zoom level.

One possible workaround: You can define a view in PostGIS that collects the attributes and geometry of the resource model(s) that aren't being displayed properly and use another map server (I used GeoServer) to serve your data as map layers. Although this is extra work, I have confirmed that it resolves the map display issue.

[RossWorkman]

Hello

Cheers for that! We're having a look into that workaround at the moment. Is there a rough ETA on when this issue may be fixed?

[dwuthrich]

@RossWorkman Here's a longish answer to your simple question: we need to start working on porting Arches from python 2.7 to 3 (due to the end of support for 2.7 coming at the end of this year). This means that we need to confirm that the various python libraries we use throughout Arches are supported in 3, or that comparable (ideally even better) libraries exist. Tilestache is one library that we're a bit unsure will port well to 3, so we've held off on trying to resolve the large polygon issue that you've logged.

We'll be evaluating mapping libraries as we start porting to python 3, and would welcome any suggestions that you might have.

[aj-he]

@dwuthrich @RossWorkman I have been testing a bit of a hack in our Arches 4.4.1 installation that overcomes some of the issues but has some rendering drawbacks.

I have changed a setting in the arches.app.datatypes.GeojsonFeatureCollectionDataType.get_layer_config function to re-enable clipping on the TileStache.Goodies.VecTiles provider.

I noticed in the TileStache API documentation that it specifically says things will "probably draw wrong" if clip is disabled.

{
            "provider": {
                "class": "TileStache.Goodies.VecTiles:Provider",
                "kwargs": {
                    "dbinfo": {
                        "host": database["HOST"],
                        "user": database["USER"],
                        "password": database["PASSWORD"],
                        "database": database["NAME"],
                        "port": database["PORT"]
                    },
                    "simplify": simplification,
                    "clip": True, #<-- Enabled clipping
                    "queries": sql_list
                },
            },
            "allowed origin": "*",
            "compress": True,
            "write cache": config["cacheTiles"]
}

I am assuming that this was disabled as it has the unwanted side effect of creating a grid effect using the outline and also if the fill has some transparency?

Was there any other reason I should be aware of before we apply the fix?

[mradamcox]

I'm experiencing this too, on a very small and simple polygon:
zoomed in

zoomed out

@dwuthrich As the python 3 upgrade as progressed a lot since your initial post, do you have any updates on what you guys are thinking about TileStache?

@AJ-HistoricEngland Have you had any trouble since you implemented that fix?

[mradamcox]

@dwuthrich Also, you mentioned using GeoServer, could you give a little more details about that? Did you serve vector tiles from GeoServer and then add the layer as an overlay? Did the pop-up windows work correctly? I understand that Geoserver is extra work to set up, but it does have an API, and a very solid user base, so I would love to know more about how well it works as a replacement for serving resource layers from Arches.

[aj-he]

@mradamcox we've not had any trouble other than the grid style artifacts. It has meant that we've needed to set the outline to transparent for polygons. The users seem happy to accept this as a work around.

[mradamcox]

Ah, ok. I will consider this then. Right now I have a transparent fill and an outline, so I would have to invert that style, and I'm not yet sure that I want to do that...

[dwuthrich]

@mradamcox Yes, I served vector tiles from GeoServer and added the service as an overlay to Arches. Its been long enough that I don't remember exactly, but I think that there may have been an issue with popups. However, the popup issue may have been resolved in recent work that we've done.

[dwuthrich]

@mradamcox Regarding the use of Tilestache with Arches running on Python 3; we're just starting to address this question. We are definitely open to suggestions on whether to use Tilestache and welcome suggestions on alternatives to it. @robgaston may have some input on work that we've done using geojson as an alternative to Tilestache

[mradamcox]

@dwuthrich thanks for the responses. I don't know any good specific alternatives to tilestache, but would like to have some way around it. GeoServer is my personal preference, and a single geoserver instance could service multiple Arches installations, but a lighter-weight solution really would be best by default. Simply caching .geojson representations of the resources and using https://github.com/mapbox/geojson-vt (just found this library, I have no experience with it) may be a good route.

[robgaston]

@mradamcox the library you referenced is intended to be used in a browser to parse geojson into vector tiles and is actually already used by default when you add a geojson source to mapbox gl js. What this means is that you will get good performance in the browser w/ large geojson files, so the primary concern re: performance would be simply the payload size (as it's coming to the browser as a single file containing all data). A way to do what you've proposed (use the geojson service to drive a cache of vector tiles) would be to write a koop provider that could pull data from the Arches geojson service (which should be very easy to do, as koop expects geojson, so this would basically just be pass through). This could then be used in conjunction with the vector tiles output (and other outputs, such as ESRI Geoservices) to present services (and cache data) for use on web maps (or otherwise). It seems likely to me that a koop provider for Arches will become an official part of the project in the not too distant future as we consider possibly replacing Tilestache in version 5.

[mradamcox]

Nice, I'd say Koop looks like a good fit for this. It also offers the opportunity to make this portion of the app pretty interchangeable with GeoServer, which would be preferable for users with the need to serve historic maps/other raster layers. Koop inputs from Arches could be identical to what works for GeoServer. Both would also provide easy to access endpoints for vector tiles (which Arches would consume) or WMS, etc. which could be consumed by any other web mapping software.

[chiatt]

Closing because the latest Arches no longer uses TileStache by default