Using WGS84 yields squishes tiles along Y-axis

[dbazile]

I specify a layer that uses WGS84, I get tiles that are squished along the Y-axis:

I think it might be a regression because if I roll back to 0.3.2, it works as expected, but my config might just be missing something. I've included the relevant bits of my configurations below and have posted the Docker sandbox I'm using at https://github.com/dbazile/sandbox-tegola.

Environment

Tegola	0.4.0-alpha, 0.4.0-beta
OS	Debian Stretch (Docker)
Data Set	Natural Earth Data Countries (imported via shp2pgsql)

Configurations

The command used to import the shapefiles:

shp2pgsql -s 4326 ne_10m_admin_0_countries.shp countries | psql -U postgres -d world

My config.toml:

[webserver]
port = ":80"


[[providers]]
name = "world"
type = "postgis"
host = "localhost"
port = 5432
database = "world"
user = "postgres"
password = ""
srid = 4326

    [[providers.layers]]
    name = "countries"
    geometry_fieldname = "geom"
    id_fieldname = "gid"
    fields = ["name"]


[[maps]]
name = "world"

    [[maps.layers]]
    provider_layer = "world.countries"
    min_zoom = 0
    max_zoom = 20

[ARolek]

@gdey can you take a look at this?

[gdey]

We are about to push issue-56 into v0.4.0. I had noticed some regressions and fixed them. When this push happens I'll revisit this to see if the issue still exists, and debug.

[gdey]

@dbazile Can you see if this has been addressed by v0.4.0-rc1? Thank you.

[gdey]

@dbazile I think the regression still exists. I continue to look into it.

[dbazile]

@gdey sorry for the delay! I tried out 0.4.0-rc1 this morning but nothing renders at all now:

git show of https://github.com/dbazile/sandbox-tegola:

commit b63136744627b825cb1e2e4cba67e73fa0fad328 (HEAD -> master, origin/master)
Author: David Bazile <dbazile@users.noreply.github.com>
Date:   Thu Nov 2 14:18:22 2017 -0400

    Update to RC1

diff --git a/Dockerfile b/Dockerfile
index 62058c3..9b242ea 100644
--- a/Dockerfile
+++ b/Dockerfile
@@ -4,8 +4,8 @@ RUN set -ex \
 	&& apt-get update \
 	&& apt-get install -y postgis sudo wget vim

-ENV TEGOLA_VERSION 0.4.0-beta
-ENV TEGOLA_SHASUM f7bfce61378dc2458c0bd7f9afc25688a6da36fdfc94b7444019600f2abfd46e
+ENV TEGOLA_VERSION 0.4.0-rc1
+ENV TEGOLA_SHASUM 8d4be44c8b881b91bca2ffcce51e5fe28bbf6a805e2cf4bac5e09b632524df32

 WORKDIR /server

Screenshot of OpenLayers 4 in Chrome:

[dbazile]

I also tried adding srid to the provider.layers block which didn't look like it made a difference.

[gdey]

Yeah, I changed something that is causing this. Trying to figure out where the regression is. The obvious places are currently not yield anything.

[gdey]

Looks like I introduced this regression in 0912fc9 . (I found this using git bisect). Will keep this issue updates as I learn more.

[gdey]

@dbazile found the regression. Thank you for the bug report. Once the above pull request is merged it should no longer be an issue.

[ARolek]

@dbazile this is now fixed in the v0.4.0-rc2 release I just pushed. I will leave this issue open in case you see any other errors while testing.

Thanks again for the report!

[dbazile]

@ARolek @gdey Just bumped to 0.4.0-rc2; the tile requests are super slow at low zoom levels (no response >= 120s). If I zoom down to 8 or 9, things start to show up but it takes about 5 seconds or so per tile.

$ time curl 'http://127.0.0.1:8000/maps/world/0/0/0.pbf' -o/dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  340k    0  340k    0     0   1680      0 --:--:--  0:03:27 --:--:-- 93148

real	3m27.395s
user	0m0.018s
sys	0m0.031s

[dbazile]

Out of curiosity, I also tested against MapBox's Web Mercator version of the Natural Earth countries data and it looks like it's having the same delays there too.

$ time curl 'http://127.0.0.1:8000/maps/world/0/0/0.pbf' -o/dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  342k    0  342k    0     0   2559      0 --:--:--  0:02:16 --:--:-- 79982

real	2m16.935s
user	0m0.011s
sys	0m0.015s

[gdey]

@dbazile Yeah, I've not optimized the new code base. It's now doing simplification, clipping, and makevalid on all polygons. This brings us up to spec for v2 of mvt. However, there are still some makevalid bugs (You will see some phantom triangles due to cutouts in holes), and the speed of the makevalid func is slow. There are two reasons for this:

1. It's not yet parallelized.
2. It's probally over allocating objects.

[ARolek]

@dbazile as @gdey mentioned the goal for v0.4.0 has been to be compliant with MVT v2 spec. This was a rather large effort to implement the necessary algorithims for simplification, clipping and making invalid polygons valid. Now that we're end to end we're going to start working on performance profiling and benchmarking to speed up the tiles that are slow to process. As you have discovered it's mainly the lower zooms as they come with the most complex polygons.

We're still working on documentation, but a feature that also came with v0.4.0 to help alleviate this pain is a file cache. You can turn it on by adding the following to your config file:

[cache]
type="file"
basepath="/tmp/tegola-cache" #where do you want the tiles stored

The cache also supports a max_zoom parameter to limit when the cache is used. We're currently leveraging the cache layer to help with the lower zooms which don't change often.

Regarding the issue (Using WGS84 yields squishes tiles along Y-axis) has this been addressed for you in the newest build?

[dbazile]

Got it. In that case, the tiles that appear are WGS84 and unsquished. 👍