Updates on svgMap

For the Maps for HTML CG zoom F2F at TPAC2021, I’ ve summarized the recent updates on svgMap development in the following pages.

https://satakagi.github.io/mapsForWebWS2020-docs/update202110.html

• Custom Projection Definition Functions
• svg-map custom element
• PWA (Progressive Web Apps)

I think there was a discussion related to the following at the TPAC2021 zoom meeting:

I think it would be good if the mapml specification could be split into two parts: one part focusing on the basic map conceptual structure of the map element and layer element, and the other part relating to the markup language for geomretry data and map tile data as geographic information that can be read in the layer element.

The former could be written as a “map element and layer element” specification.

I feel that if we do this, it would be relatively simple to start implementing svgMap.js by focusing on the former map element and layer element support. The latter part will take a lot of time to harmonize, as SVGMap has unique and useful features related to tile data, vector data, and WebApps associated with those layered data.

Of course, it would be interesting to extend these SVGMap features to map and layer elements. Also, a study towards this is the svg-map custom element described in the update above.

Satoru

Nice to see progress on the SVGMap proposal! I’ve filed a bug on the SVGMap’s layer element: https://github.com/svgmap/svgMapLv0.1/issues/27.

I think there was a discussion related to the following at the TPAC2021 zoom meeting

Referencing related minutes: https://www.w3.org/2021/10/29-m4h-minutes.html.

I think it would be good if the mapml specification could be split into two parts

Noting that separating the proposed (HTML) “Web mapping elements” and the “Map markup elements” (MapML document elements) was discussed before in https://discourse.wicg.io/t/the-mapml-proposal-part-two/4894/3:

P.S. It seems to me that the map element and layer element specifications (section 4 2) can be considered as another specification separate from the mapml specification (section 5 2).

It used to be that way, but that was found to be an issue that complicated understanding the proposal as a whole, so we are moving towards a single specification at the current time. The intention is to eventually write the specification as a pull request to the WHATWG HTML specification, once we are ready with sufficient implementation experience, support, feedback etc.

OTOH, seeing how the simplistic <model> proposal was recieved I’m starting to think it’d be nice to have 2 separate proposals: one for web maps and one for MapML in particular. As it’s perhaps easier to support a generic web maps proposal without having to at the same time learn about and support a particular format.

/cc @PeterR

I think it would be good if the mapml specification could be split into two parts: one part > focusing on the basic map conceptual structure of the map element and layer element,

To briefly summarize the MapML proposal: The <mapml-viewer>, or map, identifies the coordinate reference system of the map, by declaring it via the projection attribute, and the location of the map viewport centre via its lat/lon/zoom attributes. The child layer element(s) may contain data inline, or reference the data via the layer src attribute. The only thing a layer element could contain, itself being HTML, is HTML, of course.

SVGMap has unique and useful features related to tile data, vector data, and WebApps associated with those layered data.

Agreed.

Of course, it would be interesting to extend these SVGMap features to map and layer elements. Also, a study towards this is the svg-map custom element described in the update above.

Indeed, it would be interesting to try to implement an SVGMap layer as the content of a MapML <layer>content managed by SVGMap.js</layer>, maybe even as <svgmap-layer></svgmap-layer>, possibly even today, but certainly as part of the overall goal.

Integrating a custom element version of a mapping framework (SVGMap.js) with another custom element version of a different mapping framework (Leaflet.js or any other) would be hard due to the degree that we are ‘faking it’, or making a façade of a native <mapml-viewer> implementation in our polyfill, and the challenge requires us to look together to see if it is actually possible, even as a concept demonstration. This challenge is the fundamental lack of interoperability that we see today between Web mapping frameworks, and is one of the central challenges for which a native <mapml-viewer> element in HTML would provide a technical solution.

However, this (making a custom element layer ‘renderer’, in the “creates HTML/SVG elements sense of the word ‘rendering’”) is perfectly in scope for the full proposal, I believe, and could have the merit of ‘staging’ the overall proposal, allowing it to be useful to SVGMap.js users from the start. Also other Web mapping frameworks which decide to support rendering content into <layer>s – I don’t see why they all wouldn’t want to. I think that what a scaled-back (stage) of the proposal misses (and needs) is the purely declarative approach of MapML-HTML which includes real-world feature/object semantics (an accessibility requirement), but maybe it would be a good way to get started building the <map> <layer> </layer></map> infrastructure that would set up the basic map / coordinate reference system semantics, with real-world feature/object semantics temporarily, or for the interim, polyfilled by custom script-rendered SVG.

The key primitive capabilities that are required for the scaled back / staged proposal seem to be: browser CRS infrastructure and DOM layer rendering (pan/zoom) support.

Peter

OTOH, seeing how the simplistic <model> proposal was recieved I’m starting to think it’d be nice to have 2 separate proposals: one for web maps and one for MapML in particular. As it’s perhaps easier to support a generic web maps proposal without having to at the same time learn about and support a particular format.

I understand. The intent is that the “particular format” would be an extended HTML, MapML being an extended subset of HTML, so: not special, documented in the same place as HTML, in the same way and so on. We don’t need another standard, we need to extend the one we’ve got.

If I understand the <model> proposal correctly, animations and so on would be part of a new rendering engine that would have to be implemented by browsers, and would be embedded in the remote graphics files, the formats of which implies a variety of parsers/codecs, rendering and animation engines.

Judging by the <model> element proposal, I guess that by suggesting a simplified Web mapping proposal to match the shape of that proposal, you’re suggesting to eliminate <layer>content goes here</layer> part of the MapML proposal, opting solely for:

<layer src=”https://example.org/what-is-this?thing></layer>

or similar?

In the current MapML proposal, the layer content (whether inline or remote) can be only declarative HTML (MapML) elements, accessed under the text/mapml media type. Remote content would not be scriptable, nor its DOM available to page scripts; I believe the various types of SVG content (inline, object/iframe, img@src) should inform the DOM / programmatic / style considerations for the <layer> element.

One core value of the current proposal is to “pave the geospatial Web cowpaths”, by leveraging tile caches and software that exists today. Inventing a new binary format that everyone should switch to seems beyond the realm of possibility. Anyway I think you understand that. I’m all for breaking the problem down into implementable chunks fwiw.

Judging by the <model> element proposal, I guess that by suggesting a simplified Web mapping proposal to match the shape of that proposal, you’re suggesting to eliminate <layer>content goes here</layer> part of the MapML proposal, opting solely for:

<layer src=”https://example.org/what-is-this?thing></layer>

or similar?

I wasn’t suggesting that, I was merely talking about potentially splitting the proposal explainer (MapML-Proposal) into 2 parts, sorry, I should’ve made that clear. One would be a generic proposal for inclusive/interoperable/extensible/secure/privacy-preserving declarative maps (the what and the why), the other (MapML) would build on that generic proposal and attempt to answer the how.

The idea is that it’d be very easy to be supportive of a generic proposal, while the MapML solution is perhaps opinionated and takes time to understand thus may dissuade people from supporting it. At the same time others may think they have a better solution, and so they can propose their own solution if they don’t think MapML is the way to go. But maybe that doesn’t make much sense, or not worth the trouble at this time. Just a thought.

it would be interesting to try to implement an SVGMap layer as the content of a MapML <layer>content managed by SVGMap.js</layer>, maybe even as <svgmap-layer></svgmap-layer>

A type attribute on the layer element would allow UAs and/or the polyfill to support media types other than the proposed text/mapml. Perhaps that’d be sufficient to support the SVGMap proposal? i.e. <layer type="image/svg+xml"> (although SVGMap seemingly relies on attributes non-existent in the MapML spec so I don’t quite understand how it attempts to support the “Web mapping elements”, @satakagi?), or <layer type="application/geo+json"> to support GeoJSON (and GeoJSON-T)?

So far we’ve discussed:

1. Potentially separate the MapML spec’s “Web mapping elements” (<map>, <layer>, etc.) and the “Map markup elements” (<mapml> & CO).

   I don’t think this needs to happen for SVGMap to support the Web mapping elements, it just needs to reference that part of the spec. Should we continue to discuss that here? Or otherwise open an issue on the MapML repo for further discussion/feedback?

2. Potentially separate the explainer into 2 (one generic proposal for declarative maps that does not necessarily discuss technical solutions and one for the MapML solution)

   Not sure if this is worth doing or that it actually makes sense. I suppose we either drop this idea or open an issue on the MapML-Proposal repo.
   Edit: I guess we kind of already have a generic proposal in the form of a web Want: https://webwewant.fyi/wants/61/.

3. Supporting SVGMap in the MapML polyfill / harmonizing SVGMap and MapML

   Open an issue on the polyfill repo?

<mapml-viewer> , or map, identifies the coordinate reference system of the map, by declaring it via the projection attribute,… The child layer element(s) may contain data inline, or reference the data …

Each layer in svgMap is a projected map in itself. In other words, also each layer has its own projection information.

Of course, the container that combines the layers together, which corresponds to the svg-map element, is also projected map and has projection information.

For example, I’d like to combine a layer of Mercator projection and a layer of plate carrée, and draw it as a map with azimuthal equidistant projection. We are working on implementing this in SVGMap.js.

Is this consistent with the concept of map and layer elements you have in mind?

However, this (making a custom element layer ‘renderer’, in the “creates HTML/SVG elements sense of the word ‘rendering’”) is perfectly in scope for the full proposal

Agreed.

I think it would be realistic to start by creating a system where as many transparent iframes as there are layers are placed at the same position in the parent html document, and the inside of each iframes are occupied by individual map frameworks, and synchronizing the geographic display areas of those iframes.

Satoru