Discussion: How to handle tile errors (i.e. render what we can, or fail entirely?)

[ARolek]

There are two schools of thought developing around how to handle tile errors within tegola. I want to use this issue as a place to centralize the discussion. The two thought process:

• Render what we can
• Fail entirely

The "Render what we can" thinking tries to process a tile and if a layer fails (i.e. an unsupported geometry type is encountered like a geometry collection or an SQL error happens) we log the error and continue processing. This is discussed in the PR https://github.com/go-spatial/tegola/pull/430.

• Pro: The user is potentially less likely to experience "holes" in the map as some errors can be ignored.
• Con: The user could be looking at incomplete tile data.
• Con: Invalid tiles are persisted in the cache.

The "Fail entirely" approach is essentially the inverse of "Render what we can". A tile would fail to be served if any error is encountered. This is discussed somewhat in #585 in regards to handling SQL errors.

• Pro: When a map tile is delivered it's assumed no errors are suppressed.
• Pro: The cache will only have tiles that were processed successfully.
• Con: The user may experience "holes" in the map.

There are other pros/cons to both approaches so I'm looking to have an open discussion of what approach tegola should take moving forward. Once we pick an approach we should plan on sticking with it for the foreseable future.

cc: @paumas @tomass @gdey @pnorman

[pnorman]

I'm in favour of fail entirely. Relying on logs is iffy and serving only some layers sounds like a recipe for subtle hard to detect failures.

[gdey]

I want to bring in @tomass comment here, has it has merit to this discussion.

Which brings into question, what are "expected situations" for types of things. Where is that documented, and is there a clear rule outlining what is and isn't an "expected situation."

@ARolek I'm not sure I understood your question correctly, but here is my opinion. I would go for skipping the tile entirely when an error occurs. But I would not count empty collection in response as an "error". It is an expected situation. Here is an example where this situation occurs: The place is here: https://topo.openmap.lt/#t/14/55.73044/21.09655/0/0 Red lines are tile boundaries. The large waterbody in all tiles except upper right is a Baltic sea plus Curonian lagoon which is a large geometry. Firstly I have a cartographic task: I want all water to have a darker outline, in order to have no lines on water intersection waterbodies must be concatenated before adding them to the tile. I use st_union to do that. Secondly I have a technical/speed task: as the geometry of such a large waterbody is a large one (even tho I do clip it into smaller parts in database beforehand), I do not want to be passing full geometry on all scales to Tegola for clipping, I do the clipping in the PostgreSQL side by using st_intersection and !bbox!. And in the place depicted in the picture above we get a situation that bounding box of waterbody overlap with upper right tile - so waterbody geometry matches where clause of the query and is thus selected. But the st_intersection in the select part of the query returns empty geometry (as it is more exact calculation compared to envelope overlapping) which goes into union and thus produces an empty collection. Full query:

SELECT
  row_number() over() AS gid,
  ST_AsBinary(ST_Union(ST_Intersection(geom, !BBOX!))) AS geom,
  'coastline' AS kind
FROM
  coastline
WHERE
  geom && !BBOX! AND
  res = 150

Opinion. Theoretically I could wrap the query in another query and filter out empty geometries, but then there will be other users of Tegola who would hit this situation and it would not be easy for them to understand why are they getting an error of unknown type on some tiles or they could fail to see such an error while testing if testing area does not have such a situation.

Originally posted by @tomass in https://github.com/go-spatial/tegola/pull/430#issuecomment-476499736

[ARolek]

I think we're generally in agreement that we should fail a tile when an error happens. @pnorman this gives us a direction on #585.

@tomass I have been thinking about your particular case and it sounds like an empty geometry collection is returned by PostGIS, which is passing the len(geobytes) == 0 check but the geometry Collection has 0 features. Looking back at @paumas PR #430, I'm in favor of the geometry collection length check that was submitted.

Your detailed explination is very helpful. I would like to turn this into a test case so it's properly documentd and handled going forward.