Problem with min_zoom in Earth layer in v1.9.0

[rwrx]

Hello, thank you a lot for v1.9.0 release. I have tried it out, but I have encountered a problem with min_zoom for Earth layer. It is asserting on this line: https://github.com/tilezen/tilequeue/blob/master/tilequeue/process.py#L391

I have printed out data with which it has a problem:
(<shapely.geometry.polygon.Polygon object at 0x7f4d2d4ce390>, {'source': 'osmdata.openstreetmap.de', 'min_zoom': None, 'area': None}, 178712, Metadata(source='shp'))

I am not sure how to debug it more or when the problem could be. Could I ask you for assitence resolving this issue? Thank you a lot.

[nvkelso]

Hey there stranger!

It's possibly related to this PR? https://github.com/tilezen/vector-datasource/pull/1858/files

Note that PR requires an updated version of Tilequeue, are you using the newer version?

Please note: development of Vector-Datasource has been stopped. The Tilezen schema is still evolving (and actively being reimplemented) over at Protomaps > Basemaps. The build system there using Planetiler can generate the whole world very quickly even on a single machine at extremely low cost.

[rwrx]

Hi @nvkelso!

Thank you a lot for your really fast answer. Yes, it is possibly related to this PR. I have pulled it from this git repo and prepared Slovakia osm extract. Yes, I am using latest version of Tilequeue. Could I just comment out that assert line? Or how to fix it? I have tried something, but I did not found out why it does not contain min_zoom property for earth layer. All other layers are ok.

Thank you for mentioning that develoment o Vector-Datasource has been stopped. It is looking really good. :) It could be later used also as a replacement for Vector-Datasource and Tangram pipeline?

[nvkelso]

Yes, that's the goal (replacement). The basic setup works well now but it'll take a while to come to full feature parity for extras like road shields.

[nvkelso]

If you don't need the earth layer then try commenting that out in the main layers yaml config?

https://github.com/tilezen/vector-datasource/blob/master/queries.yaml

It's probable that earth and transit layers were disabled via an override during final QA of v1.9 which could explain this bug?

[rwrx]

That is great. But will tangram styles work in MapLibre? Or will MapLibre styles use also Vector-datasource scheme?

I also need earth layer. I am not sure if it is possible that they were disabled during final QA of v1.9. I am not sure where to look why osmdata.openstreetmap.de earth layer features does not contain min_zoom property. Maybe there is something missing in data import or processing data after import.

[nvkelso]

Styles have to be ported to MapLibre, and MapLibre doesn't support all the options Tangram had. But onward...

There are a few Protomaps styles now that are feature complete and workable. But no outdoor specific style yet.

If you need help with a migration strategy I'm happy to talk live on a call. My username here at gmail.com and we can find time this week or later this month.

[nvkelso]

(I'll try to debug the earth layer issue tomorrow for you...)

[rwrx]

Thank you a lot. I will write you an e-mail. Also thank you a lot that you will debug it.

[rwrx]

I have also noticed that for v1.9 I am gettng empty tiles. For example 0/0/0 (zoom/x/y) tile has no data when I imported slovakia.osm.pbf. I am still using import script based on https://github.com/tilezen/vector-datasource/wiki/Mapzen-Vector-Tile-Service

[rwrx]

Basically we fixed this with @nvkelso by commenting out this line:

vector-datasource/data/perform-sql-updates.sh

Line 65 in 0a09b57

psql $PSQLOPTS $@ -f apply-highway_99_fixes.sql

[nvkelso]

@rwrx Can you remind me what the error was? Something about miss-matched projections?

[rwrx]

@nvkelso Yes, the error was:

Fixing funky road classification in Seattle, Washington, USA in OSM
psql:apply-highway_99_fixes.sql:6: ERROR:  Geometry SRID (0) does not match column SRID (3857)