A few weeks ago, I hastily wrote about my thoughts towards the W3C/OGC Joint Workshop Series For Maps On The Web AKA “let’s work on MapML”; but the original writing caused quite a stir among some of the readers. That stir, combined with finally being able to enjoy the countryside for the fist time in this weird COVID-19 year, led me to rewrite parts of the statement, and expand on some sub-topics that I didn’t cover at first.
The end result is a (somewhat informal) essay about maps on the web about 7000 words long; it might take half an hour to read it in full. I encourage you to do so, but if you’re short on time, this summary should give you an overall idea on where I stand in regards to web maps:
I might not be like you. I’m a FLOSS nerd, involved in OSM, OSGeo and Leaflet; I speak for myself; and I am bound by some cultural, moral and political biases. The explanation of my background and biases should help everybody else understand my position and motivations about maps on the WWW.
Of all the work I’ve done in Leaflet, perhaps the most interesting piece from a “why does this even exist?” point of view are the plugins in which I use DOM mutation observers to overcome legalese restrictions that otherwise would create performance issues.
In an ideal world, the root non-technical reasons for these hacks should not exist. Standardization cannot affect those reasons.
Somebody needs to say this: the majority of the web browser market is held by an oligopoly which also holds a big chunk of the web maps market. As a consequence, any standard that web browsers implement is liable to affect or be exploited by web browser makers/maintainers. I think there is a real risk there.
(Due to my biases) I think it’s of paramount importance to be aware of the possible worst-case scenario consequences of a standard for maps on the web. These consequences can be reason enough for me to reject any proposals.
I can navigate through web maps using a thumbstick. To me, this poses some accessibiltiy questions to me - should any web map implementation be able to be modified to accept such interaction?
Looking at how the
<video>HTML element fared over the years can offer some insight. There’s a specific set of low-level interactions, and for a time we had a (mostly) consistent UI for video players, until web authors started to put custom UI on top.
The boundary between a video asset and a video player application is more or less intuitive, but I don’t yet think that we have a clear distinction between map assets and map viewer application. This might be a problem, and maybe tile pyramids can help.
I make actual proposals (even though they might seem radical, weird, random and/or outlandish): don’t cap interoperability by means of ToS; standards should enforce code licensing in addition to granting patent rights; fix the “layer” nomenclature; create a P2P protocol for distributing map tiles; browser implementations of slippy (pannable-zoomable) interfaces should be generic (i.e.
<slippy>) and not geographical (i.e.
<mapml>); create a SVG-like markup language for low-ish level OpenGL/WebGL triangles; and a wishlist of how I’d like DOM subtrees to behave.
I shall welcome comments to my essay, preferably in the form of (argumented) written articles/essays.