Dan Little gave a presentation on the GeoMoose open source (OSGEO) Web GIS project. A recording of the presentation is here. Note that the GeoMoose project was a pioneering effort in describing Web maps declaratively, and has added behavior over time using modern frameworks. The experience of that project can help identify requirements for standardizing Web maps, perhaps.
Collecting comments from the live chat during the presentation (skipping the “great presentation, Dan” comments, because there were a lot of those!):
Iván Sánchez Ortega @IvanSanchez Sep 20 23:22
@theduckylittle I have a secret plan to describe multiband raster data. Teach raster people GLSL instead of their domain-specific raster algebra language 
Dan “Ducky” Little @theduckylittle:
@IvanSanchez_gitlab 
We can keep chatting! I’m doing some active work in that space.
Bryan Haberberger @thehabes: @theducky Way to get the initial groundwork done with XML. How fast did you get yourself into GeoJSON
Dan “Ducky” Little @theduckylittle:
Very quickly We’ve never replaced the XML work but GeoJSON provides a lot of useful tools for lightweight communication of features.
Bryan Haberberger: @theducky I have people feeding me XML and KML files for Leaflet, but their scripts for GeoJSON to get it to draw. Then I ask “well do you have it as GeoJSON”? “Yeah, but I’ve always just fed it the XML”
Dan “Ducky” Little: The current application also uses Redux to manage state and since GeoJSON can be described with Javascript primitives we can use GeoJSON to describe features in the map.
Bryan Haberberger: Yep, JSONing around Features has done wonders for the Web. What Feature format draws in the most viewers out of the box would you say in your experience? I am comparatively new to this, and GeoJSON seems to be one of those de facto things.
Doug Schepers @shepazu: @theduckylittle, have you been contributing to the use cases and requirements document? That would be really helpful your experience is invaluable
Peter Rushforth @prushforth: @thehabes GeoJSON is the simplest thing that works,. HTML could be even better, I think, because it supports linking, but it could be a natural receiver for GeoJSON, if it had a element. Not to give out spoilers though.
@theduckylittle you and GeoMoose have been through almost the full evolution of Web maps. Congratulations for that longevity, for one thing. Great perspective on both server and client concerns.
Really wonderful to hear about the history of GeoMoose and to take a look at what web maps looked like back then. Thank you Dan!
Hi Ducky,
Some of the key features of GeoMoose that you mention, and which align with certain Use Cases and Requirements for Web Mapping:
You mentioned that nearly every county in Minnesota had/has a GeoMoose installation. If we extrapolate this to other jurisdictions, not only those using GeoMoose, but perhaps something similar, does this say something about the need for author-level standards? You noted that the FGDC used grants to enable people to share data. Maybe we could persuade the FGDC to help standardize Web maps ;-). That would be sharing on a grand scale.
In reviewing your presentation about developing a client to interface with Minnesota MapServer back in 2003, and using all the latest features of IE6 at the time, I was wondering if it ever occurred to your project (in that era) that building maps into the browser might be a path forward, and if so, why didn’t GeoMoose pursue that? I have often wondered why this wasn’t done or at least proposed in the early Web mapping years. You do say that you would have been sympathetic to the idea of having the browser do more of the rendering back then. Has your view of that changed? Should the browser be involved, or is there too much mapping legacy, or some other consideration that has changed the need for the browser to help render maps?
You mentioned that it was a GeoMoose 2.0 design goal to separate the concerns of layers from data sources. In MapML, we’ve tried to decouple the <layer> from the server-side (or client-side, for that matter) variety of data services, to the extent possible without making the client-side implementation impossible. For example, we’ve specified the semantics of <input type=location> in terms of the Tiled Coordinate Reference System concept, on the assumption that we can describe many of the dominant service types using that framework. I would be very interested in the GeoMoose project’s comments on this mechanism.
Question about z-index, the catalog and Web maps vs Web GIS
Is the catalog abstraction a fundamental difference between / characteristic of (Web) “GIS” vs. Web maps? Is the “catalog” defined in reverse of what we (normally) see in Web maps? I.e. is (catalog) document order the opposite of the z-index rendering order? (“first in last out”)? You say layers at the top of the catalog were displayed “at the top of their map”. Do you mean that the layer control (on the left of the GeoMoose screen, IIRC) was reversed from what we commonly see on the Web today? I.e. layers at the top of the layer control are higher in z-index value?
I’ll do my best to answer all of the questions above! It’s a lot of ground to cover:
Re: FGDC + GeoMoose / MN Counties. GeoMoose was very popular, especially before the era of ArcGIS Online. For counties/cities that have larger amounts of data and already have hosting infrastructure it is still pretty popular. The nature of the tools makes it scale more easily to frequently updated and large datasets. During the FGDC days, the requirement of our grant was to demonstrate that it was possible to establish some voluntary standards to make map data easier to communicate between jurisdictions. We assembled the following ideas into our demonstration:
So for a short time in a few northern states we had a casual-standard for web maps covering a storage standard, a service standard, a cartography standard, and a customizable client that could index all of it.
Re: IE and the year 2003. I believe we felt the browser was more of a container for applications than a provider of application functionality. But when we first started we would have done more to exercise the already available resources. Older Javascript engines really required a lot of ugly code to get performance bumps and the capability of CSS was much more limited. I think if we had a Map-HTML element, or projection library, that was reasonably standard across the browsers those would have been baked into the implementation. Though I also suspect extending it would have been our first order of business. Contemporaneously, I recognize there needs to be different levels of solutions to mapping in the browser. As someone from the open-source community, I do worry about the browser dictating too much of what a map may or may not do. Particularly with the most prominent browser in use being provided by the most dominant player in the mapping space. Current mapping projects encourage the use and participation in open collaborative mapping data source (OSM). At this point, without a competitive browser market place, I fear standardizing HTML maps means standardizing maps to center around a single provider’s set of data. Having mapping primitives, however, to help the browser know how to render particular bits of the page allows browser developers to create optimizations that current library developers do not have access to. Shifting the burden of computation from Sandboxed Javascript to C++/Rust could be a real boon in long term performance from which everyone would benefit.
Re: <layer> vs <map-source> vs the server-side. Also, Re: Z-Ordering. In the 1.X days of GeoMoose, the order in which layers were displayed were directly linked with the order in which they were added to the map. This was a confusing story to tell users even though fixing layer stacking issues was as easy as adjusting the select box they had right in front of them. In our next attempt to make user’s lives easier, we forced the order in the catalog to match the stacking order in the map. Layers at “the top” of the legend were “at the top” of the map. This didn’t work either as catalogs and legends are sorted by function and not in aesthetically pleasing order. That required GeoMoose 2+ to delineate between the two concepts. Ostensibly, MapML is not looking to provide a catalog or terribly advanced legend making this distinction less important.
The example shown in the video handles the simplest of cases – “I want to show some tiles on a map.” But I think things become substantially more difficult when trying to look at other issues like if those tiles are not raster tiles. Or if those raster tiles are coming over the pipe without any render curving (IE data tiles). There is no way of describing what query capabilities that endpoint may or may not provide. For example, a WMS service may or may not have GetFeatureInfo enabled, that changes how the user can interact with it.
Forgive the dumb question, but why is this more difficult? This is an area that people have actually commented on, for example, “we might successfully create the machinery to load raster tiles, but what about vector data, like MVT for instance”.
Tiles are an actual proposed element and event in MapML, so it could be as simple as handing the parsing and rendering responsibility back to the scripting at appropriate moments. Maybe that is naïve, but I would like to explore my and your understanding a bit more.
Further, the browser decodes and renders images and video data quite well. If there was a prominent and well-established format for vector tiles, perhaps rendering of that format could eventually be incorporated into the browser as well, one thing at a time though.
Finally what do you mean by “render curving” / data tiles? Thanks!
I think I’m of the same mind as other commenting re: MVT. MVT has a lot of uptake in the wild. There is also uptake for TiledJSON.
I am doubtful there will ever be a bespoke way of simply rendering those types of tiles in the browser since they don’t carry their cartography information with them. Maybe standardizing on an extension to CSS that is cartography-centric would help but both Carto and MapBox have tried and the latter definitely felt it was problematic.
I may also need to noodle over the concept of hooking into the tile events a bit more. Having something akin to an onPreRender, onRender, and onPostRender family of events with proper callbacks and refs would enable a developer to manipulate the tiles however they please. This is just me riffing but something like this could work:
<tiles
... attributes for the tiles ...
onTileRender={(tileResponse, tileCanvas) => {
if (tileResponse.status === 200) {
// calls some rendering library ala Mapbox GL
drawWithStyle(someStyleDefintiionObject, tileResponse, tileCanvas);
} else {
console.error('Failed to load canvas at URL', tileResponse.url);
// some function that maybe writes "error" on the tile and colours it pink
drawTileError(tileCanvas);
}
}}
/>
Please excuse the JSX/ES6 styles above… it’s where I spend a lot of my day. 
Re: Curving data rendering. Outside of GeoMoose, I work heavily with satellite data in the browser. One of the current limitations of the browser is that it really only supports, at best, RGB images with 8-bits per pixel and usually some form of compression on those images. There is active work trying to get around that limitation. By “recurving” or “render curving” the data I’m talking about the process of fetching raw data from an endpoint, applying a color curve, and outputting an RGB image. There are multiple organizations working on this concept right now, so I don’t think it’s far off from becoming a common feature. Though if there are event hooks to intercept the data before it’s rendered on the map, similar to what I sketched out above for vector tiles, that may be workable.
I think one of the problems that the blog post you link to above points out is that CartoCSS isn’t CSS, which makes it not a great fit for what they were trying to do with it. But in the browser, CSS is how you style content. If there are features that would help support maps that don’t exist yet, part of the purpose of this project is to get us all into the space of having those conversations with the people who design and implement CSS, not on a fork that doesn’t quite fit the environment.
I would have you spend your day in standards! Seriously though, riffing is what we do here.
Sounds interesting. Will be prioritizing getting to writing client code that consumes these events to see what is possible.
FWIW, here’s a video of our polyfill rendering MapML tiles of polygons, and styling them according to a linked CSS stylesheet. There is a working demo file of this over in our polyfill.
Thanks for your contribution to the workshop! /overandout