An essay about MapML, TL;DR
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:
-
Part 1: The motivations of an outspoken Spaniard
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.
-
Part 2: The Mutant Hacks of the Terms Of Service
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.
-
Part 3: Three Vertical Elephants
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.
-
Part 4: Thumbs-up for document accesibility
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.
-
Part 5: The Gold, the Moor, and the Sausage Machine
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.<geo>
/<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.
(Addendum 2020-09-09: Do read also Cory Doctorow’s musing about adversarial interoperability and intellectual property)