Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: Support for tile services in local coordinate systems #120

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Huite
Copy link

@Huite Huite commented Feb 9, 2020

This currently adds:

  • Some lightly edited functions, which take some additional data from the Provider.
  • projecttile rather than mercantile for some tile handling, located here: https://github.com/Huite/projecttile
    It doesn't have dependencies currently, except if you'd want to generate a list of providers yourself in which case pyproj and owslib are necessary.
  • Adds a script for fetching the data of a WMTS services, which uses scripts/parse_leaflet_providers.py
  • A notebook with two basic examples

I initially hoped that I wouldn't have to explicitly set all providers. My hope was that you could just present a WMTS url, take a peek at what it's serving, and pick a layer. There's some issues with this:

  • it requires owslib, although it's not a very heavy dependency
  • it requires pyproj for one the fly reprojection of the bounding box, although since rasterio is already required it's probably also not a big deal(?)
  • it doesn't seem straightforward to extract a URL using owslib, so I couldn't get the retryer to work; you'd have to use owslib, but it does its own things with requests.
  • However, by far the worst: it appears that a good deal of WMTS services play pretty loose with the standards (for as far as a standard exists), so I couldn't get owslib to fetch the tile.

Instead, I've now chosen to keep it a little simpler and more explicit by generating a list of providers. A user can just choose a provider, or create one, and it should work. I think the upshot is also that there's very fine control: it the WMTS URL doesn't comply to standards, you can just edit the URL template to whatever works.

WIP

I haven't added any tests yet, because I'd like to get a little bit feedback. To make it maximally clear what changes are necessary, I've just copy-pasted and edited some functions and appended _wmts. This is not my preferred interface, it's just for communications purposes.

Maybe it's most straightforward to create another TileProvider, WebMapTileServiceProvider, and dispatch on the type?

In overview, the changes required:

  • _calculate_zoom requires boundaries: currently it's always 360:
    zoom_lon = np.ceil(np.log2(360 * 2.0 / lon_length))
    zoom_lat = np.ceil(np.log2(360 * 2.0 / lat_length))
    zoom = np.max([zoom_lon, zoom_lat]
  • I need a _clamp zoom_level to avoid getting invalid URLs (doesn't that come up currently, if you plot a very small feature?)
  • mercantile -> projecttile for .tiles
  • Skip conversions of WebMercator <-> Lat-Lon
  • A s_crs for warp_tiles?

If you do make a decision on if and how to include these changes, I'll be happy to setup CI properly, also for projecttile.

Note: not a 100% of them work. The issue appears to be some inconsistency in the URL (which does not match PDOK's own description...). This appears to be rather common case with these WMTS services. In this specific case, however, owslib IS able to fetch a tile, so there's like something that can be done.

There are also cases where the WMTS URL structure looks nothing like what owslib expects. I suppose manual tweaking is required in that case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant