Closed prushforth closed 4 years ago
Looking at that example, I see it follows the TMS convention of the y axis positive upwards. This is intentionally not covered by MapML, as it was deemed 'niche' and would require (I think) a non-declarative solution. Maybe we can think up a way to make it a "progressive enhancement"-covered situation. Note that the way Leaflet and OpenLayers both deal with this is by using a special template variable {-y} which conveys to them that the y axis is reversed, and that the origin of the tile matrix is at the bottom left, instead of the top left. I don't think it a simple matter of using a modified URL template like:
https://maps4html.org/TiledArt-Rousseau/TheBanksOfTheBièvreNearBicêtre/{z}/{x}/-{y}.png
(putting the '-' outside the template variable reference), for example, because the semantics of their {-y}
includes both the change of origin position of the tile matrix, as well as the reversed y axis orientation.
I added a comment to the use case
Wouldn't something like this need a different projection? Something similar to L.CRS.Simple, which defines a map with the 0,0 at the bottom left rather than top left?
Wouldn't something like this need a different projection? Something similar to L.CRS.Simple, which defines a map with the 0,0 at the bottom left rather than top left?
Maybe we need a new TCRS to support this use case. If I read L.CRS.Simple correctly, 0,0 is still at the top-left, with y positive downwards, but it treats L.latLng as though lat is x and y is lon. I found Leaflet's treatment of coordinates and coordinate systems to be quite confusing.
0,0 is still at the top-left, with y positive downwards,
ok I believe that's incorrect; y axis is +ve upwards and the origin is at lower left. This may be a reasonable basis for a non-geographic map, per Leaflet docs' comment:
May be used for maps of flat surfaces (e.g. game maps)
Again, maybe we need to define a non-geographic TCRS which combines characteristics of TMS and this "L.CRS.Simple".
This is intentionally not covered by MapML, as it was deemed 'niche' and would require (I think) a non-declarative solution.
Based on our discussion this morning, I will open an issue suggesting that we implement a tms
boolean attribute <link rel=tile tms tref=...>
that acts as a flag to implement the TMS origin and row axis orientation manipulation required to treat TMS services as though they are like WMTS. It avoids the crypto-technique of communicating that through the inclusion of a -
sign in the row template.
The benefit of this approach, we hope, is that we don't have to add TMS-specific TCRS which will increase overall proposal complexity, while maintaining some degree of compatibility with existing TMS services. Let's see if it works out, and specify it if so. Browsers may or may not implement, but at least we won't have to explain why the MapML proposal doesn't support TMS.
This use case needs a demo in our code, if it's possible. If it's not possible, we should figure out why and correct that.
I suggest we use the painting from the Leaflet/OpenLayers examples in the UCR.
I think the example is incomplete (incompletely specified, perhaps). The HTML author should be able to provide links on the map, etc., that enable Web features such as hyperlinking to metadata and whatnot.
We should start a system for naming based on the UCR. @shepazu will be looking at a formal way to connect requirements, specifications and polyfill implementation. I'll set up a meeting time to discuss.