Requirement: Support Existing Content

[prushforth]

The title of this issue derives from the HTML Design Principle of the same name. The intent of that issue was talking about actual HTML / Web content, but it is vitally important to accommodate existing map content to the extent possible, without requiring that map content to change significantly.

Now we are following this principle as we evaluate existing map library behaviours, but we also need to reconcile new markup approaches that may or may not come out of our efforts with existing server-side APIs and standards, which give access to the wealth of map content already created.

In some instances, we will have no control over whether or not a service chooses to make content available to the new HTML web of maps, but in others, such as GeoServer, MapServer and others, we will be able to move the needle.

[prushforth]

So an idea I've been thinking about a bit, and one I would appreciate some contributions from the community about, relates to this issue, in a way.

Specifically, we haven't done much API design for for maps, trying instead to focus on the markup design so as to capture existing content such as WMS, WMTS, "WFS" etc.

But maybe the time has come to start thinking about what the API should be, and to start getting Web developers to try it out. This seems after all, to be at the heart of the proposed Web feature lifecycle proposed by the Extensible Web Manifesto. I have been reluctant because I don't want to waste people's time.

However, what about supporting existing content in the following manner:

Develop a Web mapping library that sits on top of the

Now the 'existing content' that is supported is Leaflet plugins, specifically, and they'll probably work slower, given the potential for additional overhead. But maybe it would be a way of demonstrating the compatibility of the

This effort might (almost certainly would) inform the design of our markup and its api.

WDYT?

[prushforth]

@zcorpan the existing web of geospatial content is significant, and is the reason we started this project: the platform doesn't support it, beyond the existing tools that are mentioned. It's been my intention to get a better handle on exactly how big the web of existing content is, but a first estimate can be provided by a look at geoseer.net stats.

And that's only the data that someone has taken the trouble to provide a service for; there's probably a lot more that is zipped shapefiles etc.

So a primary challenge, or requirement, of the project is to do our best to incorporate that content. The MapML initiative has been mostly dedicated to crafting a vocabulary of HTML :-) that is close to doing that, with the idea in mind to turn a switch (sort of) to turn at least the geoseer.net content into HTML map content by influencing the tools (MapServer, GeoServer, GDAL/OGR and many others we've approached and will continue to lobby) to align with our vocabulary and be able to produce it.

Then there's another layer of adaptation that we could attempt, which is described in the previous comment / request for comment; create the ability to extend the declarative HTML map vocabulary so as to provide a foundation for "Leaflet 2.0"-type libraries.

An additional consideration is that we can and should engage the OGC community who are in the R&D phase of developing Web-friendly (JSON) APIs for geospatial information as their next generation of standards. That initiative could and should be reciprocally informed by Web platform initiatives to develop a map-support vocabulary. Given the existing collaboration between the W3C and the OGC, it seems like an opportunity to engage. Members of OGC are also members of W3C and have an inherent interest in better standards for Web maps, e.g. Google This is the reason that the Maps for HTML Community Group was established: to work together.