MapML Should the default first "progressive enhancement" of the <map> element be "non-geospatial"?

When I was talking with Satoru Takagi at TPAC, we agreed that progressive enhancement was a desirable quality in the design of extensions to the <map> element. When I originally thought of using the <map> element as the basis for geospatial maps as a progressive enhancement of “client side image maps”, I did not anticipate the adjacent use case of progressive enhancement of the <map> element to provide “deep zoom” (aka zooming and panning) of non-spatial images, or at least I didn’t prioritize that use case in my design of the progressive enhancement OVER that of geospatial maps. So, I thought that the absence of a projection=”...” attribute on the element, coupled with other signals such as the presence of a child <layer> element, should default to a projection=”OSMTILE” value, given that OSMTILE is the de facto geospatial Web map projection standard as defined by Google and OpenStreetMap, and others. Anyway, in thinking about this in light of the a) the current lack of geospatial-ness of the <map> element and b) the importance of “deep zoom”, maybe it is conceptually simpler / less cognitive load for the novice if the absence of the <map projection=”...”> attribute would default to the TCRS value that we designate as being appropriate for “deep zoom” (maybe this will be the same definition as WGS84, with a different name -- hopefully this will work, TBD). At that point, step one of PE would be deep zoom. The next step would be geospatial coordinate awareness, which wouldn’t be that big of a leap technically at that point, but which would require you to specify a TCRS projection by name. Currently what happens when an author attaches a layer that is not projection-compatible to the map is that the map tries to negotiate the correct projection from the layer if possible. If that’s unavailable, the layer is added to the <map> child DOM, but does not display on the map (is present in layer control, though) and is inert.

Feb 25 '19 20:02 prushforth

I've recently done some work with a non-geo (game) map in Leaflet and the default behaviour is that 1 image pixel = 1 map unit. If you specify multiple map units per pixel, then combined with the standard/default tiling scheme this means that you end up needing to use negative zoom values to allow zooming in as far as you might want. Furthermore there is the issue of wrapping at date-line, which you don't want in the "image coordinate system" - at least not at the default 180-pixel mark, though perhaps you do want wrapping at the edge of the image, and you might even want to allow vertical wrap. I still haven't resolved all of these issues, I expect I will be able to, but they seem relevant to bring up on this topic.

In short, it seems to me that WGS84 is not the same as an image coordinate space, and we would do well to consider this

Feb 25 '19 23:02 cmhodgson

you end up needing to use negative zoom values to allow zooming in as far as you might want

When you zoom, are you zooming on a single image, or do you provide different tiles at different zoom levels?

the issue of wrapping at date-line, which you don't want in the "image coordinate system" - at least not at the default 180-pixel mark

Curious - why would you not want to wrap at 180?

you might even want to allow vertical wrap

Seems to me that wrap or hard stop are the options.

they seem relevant to bring up on this topic.

They sure are, and thank you for discussing here as your process unfolds.

Feb 26 '19 14:02 prushforth

In my case i am using a single image, something like 3000x2000px, with an "imaginary" coordinate space bbox defined as 0,0 -> 10000,10000.
if the coordinate space is larger than 180 units (as in my 10k units example), you don't want to wrap at 180 - eg. leaflet was displaying my image layer just fine but wrapping the coordinates of an overlaid point layer at the 180 limit so all my points were crammed in the lower left corner of the map
if your coordinate space doesn't actually wrap (as in the case of deep zoom of a flat image, or an imaginary flat-world map, or a partial-world map) then you probably don't want to display it with wrapping

Feb 26 '19 18:02 cmhodgson