[postgis-tickets] [PostGIS] #3712: Address MVT issues reported by specification author

[PostGIS]

#3712: Address MVT issues reported by specification author
----------------------+----------------------------
  Reporter:  strk     |      Owner:  Björn Harrtell
      Type:  defect   |     Status:  new
  Priority:  blocker  |  Milestone:  PostGIS 2.4.0
 Component:  postgis  |    Version:  trunk
Resolution:           |   Keywords:
----------------------+----------------------------

Comment (by flippmoke):

 Just as some background, when we started developing version 2.0 of the
 specification we were doing so because we were having vector tiles sent to
 clients more often then being rendered on our servers at Mapbox. Part of
 the problem we were having besides winding order issues was that polygon
 data was often messy and had many self intersections and other oddities.
 This was causing a lot of problems our use of triangulation algorithms,
 specifically in earcut. https://github.com/mapbox/earcut and
 https://github.com/mapbox/earcut.hpp

 In response we put some guidelines in the polygon ring definition in the
 v2 specification. It is a little loose in its definition because at the
 time the specification was made we were not certain how well we could
 always create OGC valid and simple geometries which was our goal.
 https://github.com/mapbox/vector-tile-spec/blob/master/2.1/README.md#4344
 -polygon-geometry-type

 We have found numerous issues in the use of Vector Tiles were valid
 geometries always produce correct results. The primary issue is that
 Vector Tiles are primarily used on clients and typically speed is a
 requirement. This means that in most situations clients can not do a lot
 of heavy processing such as polygon correction prior to using the data.

 It is for all these reasons that I ended up having to develop
 https://github.com/mapbox/wagyu/ as a solution for the problems we were
 experiencing with validity of geometry. I know specifically that you speak
 about speed as a concern, this is always a concern for me as well and is
 another reason that I have spent a lot of time developing wagyu -- as it
 is a way for us to have our own "MakeValid" (by doing a union of all
 existing data).

 It is for all these reasons I think you also need to consider always
 running a "ST_MakeValid" like routine every time for polygon data. The
 data going into ST_asMVT might or might not be valid so you will likely
 need to always execute this. I know that this is likely against the style
 of PostGIS as each tool is doing one specific task, but when dealing with
 this special encoding of Vector Tiles things get complex. Therefore, I
 wouldn't leave it up to the user to ST_MakeValid the geometry prior to
 running this routine. The reason is that the problems might show up in
 rare cases downstream far away from PostGIS -- and manifest in ways that
 users can not easily debug.


 TLDR;

 The winding order problems are one issue alone I have found while creating
 vector tiles, validity of polygons is also very important.

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3712#comment:5>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.