Thanks for the extra tips Rob. Not sure how far I'll go in this case, but having the SQL available will definitely be useful in the future.
Adam On Monday, January 29, 2018 at 12:55:57 PM UTC-6, Rob Gaston wrote: > > Hi Adam, > > You are correct in your assertions here. You will need to tune the > simplify value for your data so that any slivers/distortion are acceptable > to the eye. It defaults to 1.0, which is quite aggressive, so you will > generally want to set this value yourself. Just bear in mind that > reducing/removing simplification (as you mention, setting to 0 will remove > it entirely) will increase the size of your tiles and result in greater > network latency when loading tiles, so you will need to weigh both sides > (presentation & performance) of this compromise as they both impact the > overall UX. > > You are also correct that you could create another table or view that > shows just the outlines of your polygons. You could also do this directly > in your tileserver SQL; here’s an example using the PostGIS function > "ST_ExteriorRing” and Arches's "mv_geojson_geoms” view: > > SELECT resourceinstanceid::text, > false AS poly_outline, > (row_number() over ())::text as __id__, > geom AS __geometry__ > FROM mv_geojson_geoms > WHERE ST_GeometryType(geom) = 'ST_Polygon' > UNION > SELECT resourceinstanceid::text, > true AS poly_outline, > (row_number() over ())::text||'-outline' as __id__, > ST_ExteriorRing(geom) AS __geometry__ > FROM mv_geojson_geoms > WHERE ST_GeometryType(geom) = 'ST_Polygon'; > > > Then you can use filters in your mapbox styles to paint the outlines and > fills based on the “poly_outline” property. Bear in mind, that this > approach sacrifices additional server overhead (due to the spatial > processing to create the exterior rings, primarily) in an attempt to reduce > the data volume in your tiles. This may, however, backfire depending on > the size of your geometries relative to the zoom levels users will commonly > view them at. ie you will be able to clip your geometries, but each tile > will include duplicated coordinate values for every vertex. If duplicating > vertices generates more coordinates per tile than turning clipping off then > this approach could both increase server overhead and tile data size. > > Of course, which solution is best depends on your data, application and > use cases. I would encourage anyone to use some trial & error to determine > what will work best for a particular context. You can use the admin UI to > modify your tileserver configurations, which is a nice way to try things > out w/o having to use SQL to update records directly. > > Also, you should always consider using caching, but be aware that you’ll > need to manage your own caches (for example, creating scheduled jobs to > truncate/reseed, if needed). > > - Rob > > > > On Jan 29, 2018, at 10:30 AM, Adam Cox <mr.adam...@gmail.com> wrote: > > Hey Rob, this worked great! Thanks for the quick response. > > One other thing I'm noticing is that the generalizing that there seems to > be a default, non-zero value for "simplify"... I removed that parameter > because simplifying adjacent polygons created gaps at some zoom levels. > However, it wasn't until I explicitly set "simplify":0 that it actually > rendered without any simplification. Ultimately, it would probably be best > to make a separate postgis that has the outlines as lines, not polygons, > and add that into the mix. > > Adam > > On Mon, Jan 29, 2018 at 12:20 PM, Rob Gaston <rgas...@fargeo.com> wrote: > >> Hi Adam, >> >> You should be able to handle this by using the “clip” parameter for the >> VecTiles provider (see here: >> http://tilestache.org/doc/TileStache.Goodies.VecTiles.server.html). >> >> Here’s a quick example using the “rivers.json” file, note the “clip” >> parameter included in the provider definition: >> >> { >> "type": "vector", >> "layers": [{ >> "id": "rivers", >> "type": "line", >> "source": "rivers", >> "source-layer": "rivers", >> "layout": { >> "visibility": "visible" >> }, >> "paint": { >> "line-width": 2, >> "line-color": "rgb(37, 58, 241)" >> } >> }], >> "config": { >> "provider": { >> "class": "TileStache.Goodies.VecTiles:Provider", >> "kwargs": { >> "dbinfo": { >> "host": "localhost", >> "user": "postgres", >> "password": "postgis", >> "database": "arches", >> "port": "5432" >> }, >> "simplify": 0.5, >> “clip": false, >> "queries": [ >> "select gid as __id__, name, st_asgeojson(geom) as geojson, >> st_transform(geom, 900913) as __geometry__ from rivers" >> ] >> } >> }, >> "allowed origin": "*", >> "compress": true, >> "write cache": false >> } >> } >> >> >> >> You should note: in some cases (depending on the resolution and size of >> your geometries) turning off clipping may impact performance as the entire >> geometry will be included in your tiles. I think that turning clipping off >> is really only useful for layers where you need a polygon outline style. I >> would imagine that in most cases the performance impact of this can be >> mitigated by tuning your simplification and cache parameters. >> >> - Rob >> >> >> >> On Jan 29, 2018, at 9:46 AM, Adam Cox <mr.adam...@gmail.com> wrote: >> >> While trying to add a new tileserver layer to my Arches 4.0.1 >> installation, I came across a rendering issue that I'm wondering if anyone >> else has dealt with. My layer is a postgis table of polygons, and in QGIS >> it shows up just fine (these are boundaries of multi-county regions in >> Florida). However, when I make a tileserver layer in Arches from it, I get >> the following result, which has an extra perpendicular grid that is >> non-existent in the dataset. >> >> >> <https://lh3.googleusercontent.com/-lrfenYtfbMs/Wm9cUm_glfI/AAAAAAAAB0A/FXMvWrQ54p8TlyR2Xv7DgeOpJDPTe1gqQCLcBGAs/s1600/tileserver%2Bissue.png> >> From the way this grid shows up (variably at different zoom levels, >> etc.), I can tell it's an outline of the actual tiles themselves. Does >> anyone know how to fix this? In the Arches Map Layer manager, I have the >> following for the Service Styling: >> >> [ >> { >> "layout": { >> "visibility": "visible" >> }, >> "paint": { >> "fill-color": "#343434" >> }, >> "source": "FPAN Regions", >> "source-layer": "FPAN Regions", >> "type": "fill", >> "id": "fpan_region" >> }, >> { >> "layout": { >> "visibility": "visible" >> }, >> "paint": { >> "line-color": "#ee0000", >> "line-width": 2 >> }, >> "source": "FPAN Regions", >> "source-layer": "FPAN Regions", >> "type": "line", >> "id": "fpan_region-outline" >> } >> ] >> >> Thanks! >> Adam >> >> -- >> -- To post, send email to archesproject@googlegroups.com. To >> unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. >> For more information, visit >> https://groups.google.com/d/forum/archesproject?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Arches Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to archesproject+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> > > -- -- To post, send email to archesproject@googlegroups.com. To unsubscribe, send email to archesproject+unsubscr...@googlegroups.com. For more information, visit https://groups.google.com/d/forum/archesproject?hl=en --- You received this message because you are subscribed to the Google Groups "Arches Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to archesproject+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
