opengeospatial / ideas

Public repository for Innovation Program Ideas
20 stars 3 forks source link

Develop and test Vector Tile (VT) as output format for WMTS (WMTS-VT) #62

Open jeffharrison opened 6 years ago

jeffharrison commented 6 years ago

Develop and test Vector Tile (VT) as output format for WMTS (WMTS-VT)

jerstlouis commented 6 years ago

This is also covered in #58.

jeffharrison commented 6 years ago

Thank you. Yes, I see that now. It's likely a good sign that multiple organizations are interested in this. One thing to keep in mind is that a WFS is likely not the most efficient interface for getting vector tiles (VTs), because it doesn't seem to have a mechanism for describing the tile matrix (?).

jerstlouis commented 6 years ago

Jeff,

Yes, vector tiles are crucial. Note that we are having a vector tiles ad hoc session Thursday morning at the TC.

We have looked at this extensively in the Testbed 13 Vector Tiles package, and demonstrated working extensions for both WMTS and WFS.

WMTS is fine if you have limited vector needs, but WFS allows a lot more flexibility in terms of filtering and querying.

What we proposed is to keep WFS tiling extensions simple and reference well known tiling schemes from WMTS. Alternatively, support to describe tile matrix set using same notation as WMTS could also be introduced.

Rather than using tile ID, a 'clipping box' could also be used rather than an 'intersecting box' like &BBOX. This avoids having to define the tile matrices but makes it very easy to support in existing WFS clients and services, as only an extent (and optionally a generalization level or scale) are specified.

Also we proposed the Unified Map Service ( #61 ) which can serve imagery, coverage and vector equally well, which can also describe tile matrices:

http://maps.ecere.com/ums?service=UMS&request=GetTilingScheme&tilingScheme=GoogleMapsCompatible&on=json

Regards,

-Jerome

On 2018-06-05 12:36 PM, jeffharrison wrote:

Thank you. Yes, I see that now. It's likely a good sign that multiple organizations are interested in this. One thing to keep in mind is that a WFS is likely not the most efficient interface for getting vector tiles (VTs), because it doesn't seem to have a mechanism for describing the tile matrix (?).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/opengeospatial/ideas/issues/62#issuecomment-394815841, or mute the thread https://github.com/notifications/unsubscribe-auth/AE5uaqLZq1Y0htHYQQVU-0KtvJhhlsrLks5t5s_LgaJpZM4UbPfS.

jeffharrison commented 6 years ago

I was going to recommend WFS originally, but multiple folks indicated the tile matrix issue. WFS would make a great addition to potential VT services if possible.

jerstlouis commented 6 years ago

We're recommending both, so that users as well clients and services providers can go with whichever solution is better suited to their needs. And we are recommending a unified approach going forward, which I believe could leverage the next generation services work going on with WFS 3.0.

The fact that that this whole WFS or WMTS for vector tiles question is being posed shows that they really should be converging.

An example WFS request referencing GoogleMapsCompatible tiling scheme:

http://maps.ecere.com/wfs?SERVICE=WFS&REQUEST=GetFeature&TYPENAMES=ne_10m_admin_0_countries&tilingScheme=GoogleMapsCompatible&zoomLevel=1&tileCol=0&tileRow=0&hiddenSegments=1&outputFormat=geo+json

jeffharrison commented 6 years ago

Both WFS and WMTS serving Vector Tiles would be outstanding

jeffharrison commented 6 years ago

Thank's again for your thoughts on this topic. Years ago many OGC services were built with an intersecting 'bbox' embedded. Maybe it's time for a 'clipping box'. 'clipbox' for short -)

jerstlouis commented 6 years ago

Yes if you have 'clipbox' (or even shorter 'cbox'?), then the WFS server and client can leave the whole 'how to cut the tiles' aspect out of the communication. That makes it very easy to adapt existing clients and services. (e.g. we demonstrated QGIS working out of the box with some 'Refreshes needed' caveats if we hijack the meaning of &BBOX).

The one thing you still need is the generalization level, and for this you can either specify a scale denominator, or you can reference a level of a Well known scale set (e.g. GlobalCRS84Scale level 0 is 1:500,000,000). The alternative of a level/row/col has its advantages as well, so I'd still suggest supporting that option as well even in WFS.

These are the kind of things we can test out and show they work well in the plugfest that we are trying to put together!

jeffharrison commented 6 years ago

;-)