Amelia Bellamy-Royds: Hello everyone who's joined so far.
Amelia Bellamy-Royds: I think we might wait a moment or two, just to make sure people
Amelia Bellamy-Royds: Figured out the technology.
Amelia Bellamy-Royds: I wanted to confirm that our capture was all hooked up, and I see it's already working. So that's great.
Amelia Bellamy-Royds: If you would like that somewhere near the bottom of the screen there should probably be a CC button.
Amelia Bellamy-Royds: It might be hidden in the three dots more menu and you'll get subtitles of what people are saying
In case.
Amelia Bellamy-Royds: You
Amelia Bellamy-Royds: Have hard hearing or hard time with English or people's accents. Hopefully this will help.
Amelia Bellamy-Royds: As I said I'll wait a couple more minutes and then we'll actually get started.
Amelia Bellamy-Royds: Shall we begin
Amelia Bellamy-Royds: So, welcome all.
Amelia Bellamy-Royds: Thank you for joining us, especially if this is an awkward time of day for you.
Amelia Bellamy-Royds: My name is Amelia Bellamy Royds I'm one of the members of the programming committee who has been organizing this workshop
Amelia Bellamy-Royds: So welcome to what you are participating in is the W3C OGC.
Get this title correctly.
Amelia Bellamy-Royds: W3C OGC workshop on maps for the web.
Amelia Bellamy-Royds: Um,
Amelia Bellamy-Royds: So our host organizations. The W3C, the World Wide Web Consortium.
Amelia Bellamy-Royds: Works on standards for the web platform.
Amelia Bellamy-Royds: The OGC, the Open Geospatial Consortium works on standards for
Amelia Bellamy-Royds: Geospatial data and mapping and
Amelia Bellamy-Royds: Are
Amelia Bellamy-Royds: More specific hosts the Maps4HTML community group which is a
Amelia Bellamy-Royds: Open to
Amelia Bellamy-Royds: Pretty much every one group of people interested in getting a
Amelia Bellamy-Royds: Map presentation on the web more standardized and our host slash sponsor is Natural Resources Canada who have been
Amelia Bellamy-Royds: Funding a lot of this work and who are
Amelia Bellamy-Royds: Paying for the captioning and a few other logistics related to the workshop
Amelia Bellamy-Royds: So speaking of logistics. If you are here in person, then you have successfully join the zoom conference.
Amelia Bellamy-Royds: glad you made it here. If you are watching a archived video because you weren't able to join the zoom conference.
Amelia Bellamy-Royds: For reasons due to troublemakers jumping on zoom calls. We're not posting the live zoom links on the web. But if you registered for the conference in advance. You should have gotten an email from Ted Guild that says something about workshop logistics in the title and it will have the
Amelia Bellamy-Royds: Zoom link.
Amelia Bellamy-Royds: If you are registered and you
Amelia Bellamy-Royds: Can't find that email, then do try to reach out to the programming committee members their email addresses on the website and we will try and get you connected up for the rest of the workshop
Amelia Bellamy-Royds: Um
Amelia Bellamy-Royds: Related to that, if you can't participate in the live sessions.
Amelia Bellamy-Royds: They are going to be all different times of the day and we know they aren't convenient for everyone. We will be recording all the sessions and trying to post them online within a day or two, so you can catch up by watching the recording.
Amelia Bellamy-Royds: And
Amelia Bellamy-Royds: The recordings will be hosted on the W3C YouTube channel. The discussion will continue on the WICG Discourse server.
Amelia Bellamy-Royds: And we'll have kind of open forum on each topic where people can add comments add more examples really go in more depth than we can on videoconference situation.
Amelia Bellamy-Royds: There is also a live chat on Gitter that we've set up. So that's just
Amelia Bellamy-Royds: more casual conversation as we go along.
Amelia Bellamy-Royds: It's where we'll be sharing links and such as we go.
Amelia Bellamy-Royds: And just during the course of the workshop. It's a way to ask questions of other participants or any logistical issues that come up
Amelia Bellamy-Royds: And if you're not familiar with Gitter, it's just a
Amelia Bellamy-Royds: chat application.
Amelia Bellamy-Royds: single column chat room, you can log in with a GitHub account with a Twitter account. I think you might be able to make an account directly on the site, but hopefully most participants have at least one of those ways to login
Amelia Bellamy-Royds: And finally, a note there is a chat built into the zoom interface.
Amelia Bellamy-Royds: We're going to try and keep that to zoom specific comments. If there are technical difficulties. If you can't hear someone if you can't see their screen share you can
Amelia Bellamy-Royds: Put it in the zoom chat, but
Amelia Bellamy-Royds: The Gitter and Discourse will be kind of the more lasting chat that persist even after we close down the telecom
Amelia Bellamy-Royds: One final important thing to mention this is a professional event we are operating under the W3C's code of conduct, we expect
Amelia Bellamy-Royds: Respectful treatment of everyone. If you have any concerns about that if you want to read the full code of content is linked from the Web site.
Amelia Bellamy-Royds: Somebody could even put a link into the chat so you can show that the chat works and if you do have any concerns about
Amelia Bellamy-Royds: Any of the content in the of the behavior of other participants, you can reach out to the programming committee members or the W3C on boots office.
Amelia Bellamy-Royds: And I think that was all my
Amelia Bellamy-Royds: Logistics and introduction home I took 10 minutes
Amelia Bellamy-Royds: So with
Amelia Bellamy-Royds: That all out of the way, I'd like to introduce our first speaker of the workshop
Amelia Bellamy-Royds: Peter Rushforth
Amelia Bellamy-Royds: Is a
Amelia Bellamy-Royds: Geologist in GIS expert who now works at National Resources Canada with a specific focus on standardization for geospatial information and maps and he's been one of the most persistent driving forces behind the maps for HTML project.
Amelia Bellamy-Royds: He is going to be talking to us today, kind of as a
Amelia Bellamy-Royds: Big introduction to the whole purpose of the workshop why maps for the web are worth talking about are worth standardizing are worth getting excited about.
Amelia Bellamy-Royds: Okay, Peter, are you ready to go.
Peter Rushforth: Good evening, and good morning. My name is Peter Rushforth, and I work for Natural Resources Canada's
Peter Rushforth: Center form
Earth observation in the Canadian geospatial data infrastructure division.
Today I want to talk about why we need to standardize maps for the web in HTML.
There are many reasons that people need or want to make web maps in the domain in which I work, it's a requirement of most projects. But how do you make a Web Map. It's easy right? There are lots of ways to make a Web Map. You just need to pick a framework.
Each framework has its merits. Some are easy to get started with some come with a bunch of free data layers built right in.
Others require significant knowledge and or manipulation of data and access to computing resources accessibility is not guaranteed and it's easy to mess it up.
Interoperability pretty much does not exist. In short, there is no simplest choice and it can be a big decision.
Once you decide, all the code that you write does belong to you, except it's bound to the framework, you've chosen making any change expensive and painful. The result?
The result is silos. Although each web mapping framework is somewhat similar known share the same foundation and they are not interoperable, except in that the user can see a map. The result is bad for users and the web.
Why do silos exist?
Silos this might be caused by a proprietary interest, such as those created to lock users into software platforms, but more likely they exist because we didn't take the trouble to collaborate and eliminate the barriers or or to create interoperability.
The proposal we'd like to make in this workshop is, why don't we work together to support all the users mapping framework providers are all trying to serve their users collectively, the sum of their users is approximately equivalent to humanity as a whole.
All the map providers use the web as their medium of choice to deliver their products together let's improve the web to serve all of the providers equally well
Possibly reducing their individual frameworks responsibilities. Let's make a standard that helps with the common core that these providers can progressively enhance if need be.
Let's make a standard to serve users needs directly through common accessibility privacy, safety, linguistic, and usability infrastructure, just as we try to do for users in the real world with roads, bridges, sidewalks, crosswalks, signs, etc. While we're at it.
Let's make the standard a natural first step in learning so that maps can be taught at school, giving children a common starting point for learning about geography and the web without frameworks.
Can silos truly disappear though? The test of independent invention first described by Tim burners Lee is a kind of thought experiment. The notion is that any new protocol or format must be designed for introduction into an environment that has incumbents or it cannot succeed.
At the invention of the web for example FTP, Gopher, waste all existed in the mainstream already
HTTP, HTML and URLs were designed to work with the existing protocols somewhat satisfying the test of in independent invention, which can never be perfectly resolved, you can't make silos disappear. But over time, they can resolve on their own.
In the real world, infrastructure, often describes public facilities created for the benefit of all without prejudice.
Such infrastructure must be safe and accessible, safe for everyone to use it must be fair and inclusive. What good would roads and bridges be if you could only drive a Ford on them.
It must be durable, because everybody uses it, infrastructure must be built to serve. And last, and finally, it must be cost effective.
Infrastructure should make it less costly for everyone to achieve their goals knows that that that this does not mean that it's free. In fact, it can be quite costly, but it should be maximally shareable
In the virtual world, the world wide web, and the software that supports it is virtual but nonetheless real infrastructure.
But how do we avoid creating more silos in standardizing maps and spatial data for the web. The situation in web mapping standards is a little bit like this XKCD comic
There are probably more than 14 different ways to create a Web Map and trying to make the situation better by adding another framework risks creating a worse situation. So what to do. Can we fix the situation by adding another standard, probably not.
Many existing formats for geospatial information already exist if one of them was suitable it probably would be a web standard
The challenge is to create a new format that enables web maps without requiring web browsers to radically change or change their architecture which is impossible.
proposed solution is to add and extend mapping elements in HTML.
HTML is widespread and it's the foundation of web architecture and browsers are based on processing it
The bonuses that HTML already implements basic map semantics.
HTML, pictured here, is the core language of the web and it was designed to bridge the divide between programmers and users.
Ideally it allows everyone to have access to content regardless of ability. Further, it is straightforward enough to allow users to to become authors. This is embodied in the idea of "view source culture" in which the medium itself teaches the user what is possible and how to achieve it.
Why are maps in HTML preferred over maps in JavaScript in the future? Because HTML requires and delivers interoperability, the browser will become a spatial integration platform shared standardized semantics mean interoperability.
Discovery, because of the rule of least for power web pages could have location indexing pages by location search engines will become spatial discovery platforms.
HTML requires and delivers inclusivity, understandable and created by created by browser authors who are not necessarily programmers or authors who are not necessarily matters for that matter.
HTML requires and delivers accessibility because things, not just web pages of location, the browser will tell the user about their physical environment, as described by a Web Map or website for public spaces real infrastructure will be represented also as virtual infrastructure.
HTML requires and delivers performance less runtime costs to HTML into JavaScript mean map rendering is better and more suitable for native code.
HTML requires and delivers scalability related to performance and inclusivity and possibly other aspects of this list.
Scalability means maps will work in constrained or powerful environments.
HTML is like the standard library of the web, a single element encapsulates processing steps, especially rendering from the layers below.
Maps and location belong in the web's standard library so that sophisticated applications can be built on top of the web, without having to reinvent the wheel.
HTML is simple enough for a web crawler to understand but scales to underlie very sophisticated application development, even though
modern web crawlers can execute web applications to reveal the application generated HTML and text content.
They can't understand semantics that aren't there, such as maps and location which don't exist yet in HTML. Standardized location is important not only for search and discovery, but also for accessibility and internationalization.
Peter Rushforth: A key aspect of HTML is that it is standard. Its elements have defined visual and accessibility semantics, making it inherently inclusive.
Peter Rushforth: Adding maps to HTML could aid important use cases for users, such as search and discovery.
Peter Rushforth: Reducing the need for special purpose catalogs and the same link ability or web superpower that allows crawlers to enable search and discovery will also enable Map Service Federation and location information sharing
Peter Rushforth: HTML is inherently cross platform, making it the ideal target for standardizing location information.
Peter Rushforth: These aspects, taken together mean that maps in HTML will be more economically effective than our current silos, leading to better return on investments for society.
Peter Rushforth: HTML was a massive decade long effort and there's little appetite in the web standards community to repeat such an effort
Peter Rushforth: HTML does however constantly change and today the HTML standard itself is evergreen with new ideas being integrated and browsers implementing constantly
Peter Rushforth: So how does the process work? Ideally developers like us who use JavaScript, HTML and CSS provide feedback to the web platform engineers.
Peter Rushforth: Who prioritize implementing low level features that are of use to the largest number of people often these features are of JavaScript, but also of CSS and HTML.
As low level features are implemented, the thinking goes, developers will develop high level features as libraries or custom elements.
As the high level functionality that browser that becomes widely used, it just becomes an emergent or de facto standard
These de facto standards can then be implemented natively by browser developers, giving rise to wider and improved use of the web and consequent generation of new requirements from new communities like our own participating in the virtuous cycle and so on.
That maps are an emergent characteristic of the web even constituting a Geo Web is obvious to the most casual observer.
Maps in the HTML of the future might look like this, starting with a map element containing one or more child layer elements.
There already exists as somewhat neglected map element in HTML with similar enough semantics to provide a good extension point in keeping with the HTML design principles.
by specifying a new child layer element HTML could immediately incorporate dynamic Web Map semantics as commonly understood providing the shareable infrastructure that web maps and geospatial information require
HTML has evolved over time. It began as simple text documents linked together. It was the linking that made them special linking has been described as the web superpower.
Over time, media types have been added in response to user needs. And most recently, with the advent of the mobile web and responsive design, maps should be the next big thing.
So we're actually is this virtuous feedback loop of which I spoke the Maps4HTML community group was created based on the conviction that web mapping is an emergent or de facto standard of the web.
As sought by the extensible web manifesto. The main way to provide feedback to the browser standards community is for you, especially representing your organization or company to join the Map4HTML community group to contribute ideas comments and even code.
Another important path for feedback from web mapping community to the web platform, folks, is the annual Mozilla web developer needs assessment or web DNA survey, please share the link. Mention web mapping, mention maps in HTML.
A key feature of the URL driven web of HTML is the ability to share documents using their URL. This feature of the web.
also enables linking within and between resources, not to mention search and discovery, the simple architectural characteristic could make a geo web of the future, a benefit to users around the globe and to the interests that rely on it. In other words, everyone.
HTML will provide a common foundation for maps and location for all stakeholders.
spatial information is infrastructure and a standard that represents is common foundation will unlock the true value of that infrastructure.
Maps standardized in HTML will allow us to encode and share our understanding of the world. Let's achieve the understanding of our physical world by enabling the representation of that world in HTML together.
Thank you.
Peter Rushforth: Hello.
Peter Rushforth: I'm done is that
Amelia Bellamy-Royds: Okay. Thank you, Peter.
Peter Rushforth: Thank you.
Amelia Bellamy-Royds: Okay, I think, in future, we'll probably have breaks between themes. But since today is a short day I might just jump right ahead.
Amelia Bellamy-Royds: So,
Amelia Bellamy-Royds: Next talk of the day is by Amelia Bellamy-Royds, that's me.
Amelia Bellamy-Royds: So before I got
Amelia Bellamy-Royds: Distracted into organizing a workshop
Amelia Bellamy-Royds: My first
Amelia Bellamy-Royds: Task working
Amelia Bellamy-Royds: With the Maps4HTML community group was to really
Amelia Bellamy-Royds: Assess the project that Peter and others in the geospatial community had done and focus on ways it can move forward within the web standards world. I've been working within web standards for a few years now, primarily
Amelia Bellamy-Royds: SVG vector graphic, CSS also accessibility as it relates to those two topics and
Amelia Bellamy-Royds: Found the potential of web standards and also some of the
Amelia Bellamy-Royds: Limitations. We can't just
Amelia Bellamy-Royds: Add everything and anything to the web because the web platform is implemented in multiple environments that need to run on all sorts of devices and
Amelia Bellamy-Royds: It's not unlimited what these devices can do. We can't just keep adding code and whatever we do add pretty much has to
Amelia Bellamy-Royds: Stick indefinitely or at least that's the goal of web standardization that once we have websites that are out there and that were web browsers. Try to support those going forward as much as possible. So, there's a lot of
Amelia Bellamy-Royds: Caution in the web standards world about adding new features to make sure that those features
Amelia Bellamy-Royds: Are the right ones and are designed correctly.
Amelia Bellamy-Royds: So,
Amelia Bellamy-Royds: One of the most important mental frameworks that is currently adopted by web standards folks, is this idea
Amelia Bellamy-Royds: Of an extensible web that the best thing the web platform can do is to create tools from which website authors and web application developers
Amelia Bellamy-Royds: Can build the features they want and test them out and get the right shape of the features as the website authors like them. And as website users like them.
Amelia Bellamy-Royds: With the end goal, at least in theory that by demonstrating that there is a demand for a certain feature in a certain design then
Amelia Bellamy-Royds: They can bring that to the web standardization process and say this is a tested idea. This is a proven design pattern there is clear demand for it. Let's standard the standards so
Amelia Bellamy-Royds: Now I'm coming from with
Amelia Bellamy-Royds: The Maps4HTML project. My first task was to
Amelia Bellamy-Royds: Look at what maps are already on the web. And there are maps on the web. There have been maps on the web, since the
Amelia Bellamy-Royds: Very beginning
Amelia Bellamy-Royds: Well, almost the beginning. Ever since there's been images on the web. There have been maps on the web. There have been
Amelia Bellamy-Royds: Pictures of maps the same way in a printed textbook, you have a picture of a map and shortly after that there was the first interactive maps using the map element that Peter mentioned briefly.
Amelia Bellamy-Royds: The map element as it currently exists in HTML isn't specifically about geographic maps, but it can be used for it and you'll see on my screen. I have a image map that is on one of the websites I use every day. The weather forecast in Canada and
Amelia Bellamy-Royds: It's just a simple picture that they generate on their web server of a map of Canada with icons and text baked in.
Amelia Bellamy-Royds: But then there are different links to different forecast and you can click through and find out that here where I am in Edmonton, it's currently 14 degrees Celsius on a Sunday evening.
Amelia Bellamy-Royds: Now this has nice features, it's supported widely in most browsers. It's even accessible to keyboard, although I discovered when I was
Amelia Bellamy-Royds: Playing with it earlier, that it's no longer fully accessible in Chrome, because I tapping through these links in the picture and you can't tell where I'm tapping. So even browsers break accessibility now and then. And that's not a great thing, but
Amelia Bellamy-Royds: The good thing about it is, once they fix this bug every image map will get fixed on the browser, because the browser actually knows what it's looking at it knows that these are links, it knows that the links have a certain shape.
Amelia Bellamy-Royds: And so there is some semantic information there. But this is really all the browser knows about a map is a picture with certain regions of that picture, having links on them that isn't
Amelia Bellamy-Royds: The map as we think about web maps today. So the current conception of a Web Map probably looks something more like this. Here's a Google Maps embed
Amelia Bellamy-Royds: And it's zoomed in to Edmonton, but I can zoom out. So you can see all of North America, I can pan over to Europe, I can do lots of things. And I could also have links on this, but it's interactive it's
Amelia Bellamy-Royds: Not just a single image, it's a complex data model behind what the map is so
Amelia Bellamy-Royds: This is really the very simplest modern conception of a Web Map is something which we can work with and the user can find the information that they need within it.
Amelia Bellamy-Royds: So,
Amelia Bellamy-Royds: From that
Amelia Bellamy-Royds: We go into this idea of what are the use cases and requirements for web maps, if we actually define what are those features that make what we now consider to be a Web Map.
Amelia Bellamy-Royds: Um, and because I'm working from this extensible web model of looking at what website developers and users have already come to expect, the approach taken for this report, which is still incomplete draft and we welcome your contributions, is we're going to be looking at
Amelia Bellamy-Royds: existing implementations of web maps and what are the common features that they have, what are the use cases they serve. And also, what are the limitations.
Amelia Bellamy-Royds: Because of course, if the existing web maps solve all the use cases, then we don't need to change anything. We don't need any new standards, but there are limitations that come from the fact that
Amelia Bellamy-Royds: These maps are being rendered using a lot of code that needs to be downloaded and every website and the final representation doesn't have a semantic meaning that the browser can understand and build on and adapt.
Amelia Bellamy-Royds: So the specific
Amelia Bellamy-Royds: Exam examples, we're looking at, and we can maybe add more these but they get a lot. So we're looking at two types. The
Amelia Bellamy-Royds: Sort of more declarative approach that's currently available on the web are anybody can go to one of these major mapping services, create a map in the
Amelia Bellamy-Royds: User Interface visual or user interface that looks good and get an embed code which they can copy somewhere else. So that's the easy to use for a website author content creator who might not be an expert in web mapping
Amelia Bellamy-Royds: Excuse me. And then the other type of web maps, we're looking at are the JavaScript frameworks which are
Amelia Bellamy-Royds: Require a little more expertise for the website author to code them up and
Amelia Bellamy-Royds: Run the code on their site that builds the map dynamically, but they're a lot more flexible for website developers who want to add their own features or their own content.
Amelia Bellamy-Royds: So this page is one of the many pages of examples for building for the report, just so we can look at how these different existing tools.
Amelia Bellamy-Royds: Implement the features. So this is the very minimum basic map that comes up. What do you get when you just say put a map on this web page on some cases it's very plain, no labels.
Amelia Bellamy-Royds: Others have a more content in the initial
Amelia Bellamy-Royds: And for the scripted ones we've got the examples of how much code you need to include in order to get that map on your web page, which of course goes to the accessibility for
Amelia Bellamy-Royds: Website authors.
Amelia Bellamy-Royds: That gets me to a question when we're talking about use cases, it's worth thinking about use cases for whom, who are we thinking of using these web mapping tools. So within the report, we're looking at three main groups.
Amelia Bellamy-Royds: Or against
Amelia Bellamy-Royds: Three main groups, the content author who's creating a website or creating content for a website or a blog or something on the web and they just want to add a map to their blog post, to their article, to their Web Store.
Amelia Bellamy-Royds: They're not geospatial experts, they're not necessarily programming experts. They want the map for the content it presents and so
Amelia Bellamy-Royds: What type of content. What are the basic types of maps.
Amelia Bellamy-Royds: Simple
Amelia Bellamy-Royds: Point on a map for this is where my restaurant is located. This is where my store is located.
Amelia Bellamy-Royds: More complex data or more complex imagery it
Amelia Bellamy-Royds: Builds up depending on where they are. So some of the slightly more complex examples, we're looking at have a pop up next to the marker. So there's a marker on the map, but you want extra information, a little bit of HTML. So
Amelia Bellamy-Royds: We've got an example of the different ways you can do that in different
Amelia Bellamy-Royds: Libraries and the amount of code that it takes to do that. So leaflet has a very built in method of how to create a pop up and you get a lot out of the box from a couple lines of authoring code and you get event handling for opening and closing and it positions and you can
Amelia Bellamy-Royds: Zoom out.
And it still works.
Amelia Bellamy-Royds: So there's a lot of behavior there other libraries takes a little more manual code to get the same behavior that's the OpenLayers code for the demo. And so
Amelia Bellamy-Royds: The website author to get this particular same behavior of a pop up from a marker point needs little more work. So those are the kinds of things we're looking at use cases.
Amelia Bellamy-Royds: Not only what you're doing. But how much work it takes far as writing code to make that happen.
Amelia Bellamy-Royds: Some other quick examples of content author use cases highlighting a region, rather than just a marker point. So for this example, we're using GeoJSON as the data format for describing that polygon.
Amelia Bellamy-Royds: And how easy is it to get that custom GeoJSON shape into our map so that it lines up and can be styled custom
Amelia Bellamy-Royds: Sorry Zoom is popping up and blocking my
Screen.
Amelia Bellamy-Royds: Go over there. Okay.
Amelia Bellamy-Royds: Then another use case is actually not mapping at all. This is
Amelia Bellamy-Royds: Not a map. It's a painting, but it's a painting rendered within the mapping applications. This is Leaflet JS, not with Open Street Map tiles.
Amelia Bellamy-Royds: But the reason you might want to have a painting in a mapping application is so that you can use the tiling with zoom effect.
Amelia Bellamy-Royds: Where as you zoom in you load additional images with higher resolution instead of loading a giant file at the beginning. So this is an important
Amelia Bellamy-Royds: aspect that we're considering within our use cases report is how can the mapping tools and the features that are necessary for a good web maps. How can they also be used for other things that people want to do within the web platform.
Amelia Bellamy-Royds: And if we can find these connections find these additional use cases for the primitives, then we find more people who are interested in getting these features standardized and
Amelia Bellamy-Royds: working too. Now I said a little content author the website owner is only one target of our use cases is the next one is our website visitor. So is someone going to a
Amelia Bellamy-Royds: website have things that I want to do with a map that maybe the website owner didn't think about so
Amelia Bellamy-Royds: Um
Amelia Bellamy-Royds: Maybe the website on it didn't think about accessibility and the fact that I need to use my keyboard to tab through things. And I'd like to see what's currently focused
Amelia Bellamy-Royds: Maybe the
Amelia Bellamy-Royds: website owner didn't think about the fact that I'm going to need to print out that map or I'm going to need to export an address in a form that I can use in my GPS somehow
Amelia Bellamy-Royds: There are lots of use cases that are from that end user perspective that are separate from
Amelia Bellamy-Royds: The
Amelia Bellamy-Royds: Desires or plans of the person who actually created the website.
Amelia Bellamy-Royds: And I'm not going to get too much detail here. We've actually got a another talk later in the week Nic Chan will be talking about her assessment for this report on some of the interaction patterns in the
Amelia Bellamy-Royds: Various web mapping tools and what that relates to the accessibility of the web maps for people who use the web in various ways.
Amelia Bellamy-Royds: So moving on to our third category of use cases. That's your application developer. So this is again, a website creator, but someone who's interested in maps in a more complicated level interested in adding new features, because
Amelia Bellamy-Royds: There is so much that could be done with maps on the web. And we're never going to have those all built into a standard tool.
Amelia Bellamy-Royds: There are always going to be custom use cases. In addition, so for the application developer who wants to build additional geospatial features
Amelia Bellamy-Royds: the use cases are about how much they can extend and build on the
Amelia Bellamy-Royds: standard tool
Amelia Bellamy-Royds: without having to recreate all the basic features from scratch.
Amelia Bellamy-Royds: So one of our use case examples we've got is add a extra control that does something, so trying to keep it simple, so
Amelia Bellamy-Royds: this was our contributor Nick Fitzsimmons who added this one. So this is the feature it describes where the math is centered as we move it shows
Amelia Bellamy-Royds: A different latitude and longitude and I can mark the current latitude and longitude at the center of it and I can pan away, and then I hit another button and it returns back so
Amelia Bellamy-Royds: Simple functionality, but actually there is a lot going on here.
Amelia Bellamy-Royds: Updating when I pan the map and it's changing the position of the marker and then it's changing the position of the map on a different button and it's responding to the button clicks, as well as the movement of the map itself and so
Amelia Bellamy-Royds: We've got lots of different interaction patterns between what the user is doing what the
Amelia Bellamy-Royds: Web Map library code is doing. And then what the custom JavaScript is doing. And again, we've got this implemented in many different libraries with
Amelia Bellamy-Royds: Similar behavior we can mark the center pan away, return back
Amelia Bellamy-Royds: Again, differing amounts of code, depending on how well
Amelia Bellamy-Royds: Optimized
Amelia Bellamy-Royds: The library is for these particular things we're trying to do, although at this point. Pretty much all of them. There's a lot of custom code because that's what we're doing. We're extending the map.
Amelia Bellamy-Royds: So within all these use cases. As I said, there are a lot of little pieces that need to go together. So we're calling those the individual capabilities. So these are the low level features that need to be available in order for you to build up the full use case.
Amelia Bellamy-Royds: And within of the each of these capabilities were then looking at is it implemented in existing tools? Is i implemented in a consistent way where we can say there is a clear pattern of be
Amelia Bellamy-Royds: Implementation that this is how the standards should be designed, because this is how users or developers expect it to be designed
Amelia Bellamy-Royds: We're looking at, are there any connections to existing web standards that could be
Amelia Bellamy-Royds: reused in a pattern that's consistent with the web or are there proposals that are for other web features that we could connect up and are their use cases for this low level feature that is use cases beyond so
Amelia Bellamy-Royds: I've already shown the example of wanting to be able to zoom in and adjust resolution on non-map content more generally just having pan and zoom as
Amelia Bellamy-Royds: It's a really complex interaction. There's different ways of panning and zooming depending on using mouse or keyboard gestures and there are lots of stuff on the web that use pan and zoom
Amelia Bellamy-Royds: Zooming in on a product photo on a store that's not map related, but there are similarities. And so if we had these low level features and sort of browser awareness of what pan and zoom is it could be used in multiple places.
Amelia Bellamy-Royds: The idea of having a pop up tool tip.
Amelia Bellamy-Royds: Sort of or an info box that pops up, that's something that happens in lots of user interfaces.
Amelia Bellamy-Royds: But we don't have a built in way to position things, that are pop this up next to
Amelia Bellamy-Royds: Some other anchored thing but don't let it go off the edge of the screen or don't let it obscure something else that's
Amelia Bellamy-Royds: Anybody who's done a website coded that by hand those. There's a lot of things you have to think about to get right. If there was a built in primitive feature in the web for positioning a pop up where the browser
Amelia Bellamy-Royds: Can do it once and do it right for every website instead of every website author having to do is to write that code again.
Amelia Bellamy-Royds: There are lots of use cases for that beyond mapping
Amelia Bellamy-Royds: But that said, there are lots of things that are needed for maps that are map specific. Maps need to understand latitude and longitude. They need to understand how that gets sent to different projections and coordinate systems.
Amelia Bellamy-Royds: And
Amelia Bellamy-Royds: Beyond this,
Amelia Bellamy-Royds: basic primitives within all the little parts that you need for a map. There is definitely once you have those there's a benefit of having the integrated features the very convenient declarative features so that the
Amelia Bellamy-Royds: restaurant owner who just wants to put a map on their website with a pointer to the restaurant doesn't have to think of all the little parts that go into making them up. They can just say, here's the location. Draw me the map.
Amelia Bellamy-Royds: So,
Amelia Bellamy-Royds: That's a brief overview of the project. One thing that
Amelia Bellamy-Royds: Has been very clear working on this project is just how many detailed features There are once you start trying to list them all within the standard maps. So we are still working on the report we are welcoming contributors to the report, it's all on
Amelia Bellamy-Royds: GitHub.
And
Amelia Bellamy-Royds: We've got
Amelia Bellamy-Royds: Sort of issue discussion pages for every section of the report that are linked back from
Amelia Bellamy-Royds: Sorry link back from each section about
Amelia Bellamy-Royds: Let's discuss what should we mentioned here. What should we conclude about, is this an essential feature of a Web Map, is this a nice to have feature of a Web Map, is this okay this is never going to happen in the browser feature.
Amelia Bellamy-Royds: And we're going to have all of those. But we definitely welcome your contributions and I've gone follow for 15 minutes. So I'm going to wrap this up now.
Amelia Bellamy-Royds: And go back to my hosting duties.
Amelia Bellamy-Royds: Final talk of the day is by Dan 'Duck' Little who has been building maps on the web for many years since 2004
Amelia Bellamy-Royds: When JavaScript was still
Amelia Bellamy-Royds: New and wild so Geomoose is built using XML and Dan will be telling us about some of the lessons learned from that project and
Amelia Bellamy-Royds: Take it away. Hopefully we can hear you.
Duck Little: Oh, thank you. Am I getting through a little bit here.
Duck Little: Okay, fantastic. So this is going to be a little bit different. I'm going to be covering something that's maybe a little bit more in the style of a retrospective on a project that's been around for a while.
Duck Little: Which uses
Duck Little: Which is playing on the tune instead of HTML. We've used XML.
Duck Little: I can be found all over the internet with the handle The Ducky Little if anyone wants to have some follow up conversation, about Geomoose, or any of the controversial things I may or may not end up saying today a
Duck Little: Little bit of background on the project itself. It's actually an OS geo project.
Duck Little: GeoMoose is a WebGIS client that started with a co worker and myself at the city of St. Paul in Minnesota in the US.
Duck Little: The first release was back in '04, and our big kind of coming out party was at the 2005 Map Server user group meeting. For folks who are maybe not into
Duck Little: Open Source GIS software history The Map Server user groups were the precursor to the FOSS4G conference. So this is how, like, I started feeling old knowing that we were presenting at conferences that were the precursor to FOSS4G.
Duck Little: And we've done some cool stuff. Amelia mentioned that we use XML. And yes, we use XML and a healthy dose of JavaScript as much of it as we've been able to squeak through the browser through the years, but to do some really cool things such as describing pop ups.
Duck Little: providing detailed measure tools in the browser. That seems to be the like one of the next logical steps as soon as you can put a map in it, can I measure it.
Duck Little: And a lot of health, a lot of having support for OGC services through the years, including WFS-T supports doing editing on the web and also adopting sort of web friendly technologies as they come through such as, you know, the early GML, GeoJSON and MapBox vector tiles.
Duck Little: But I'm going to put us in the Wayback Machine and talk about the web of 2003.
Duck Little: It was a different place.
Duck Little: There was a lot of
Duck Little: Things going on that were really innovative, but people were still trying to figure it out. For us as a GIS project one of our big first goals was to talk to MapServer.
Duck Little: So I mentioned that we come out of Minnesota and folks may remember that MapServer used to be called Minnesota Ma Server or the University of Minnesota MapServer and
Duck Little: My coworker James Klassen and I did actually work with Steve L'chaim on early MapServer code and it was sort of the de facto standard for how you render
Duck Little: A complex map for the web. And because it's 2003 we wanted to use all of the cool features of the latest and greatest browser at the time, IE6
Duck Little: There might be a few of you on this call, or, you know, kind of curse at on a regular basis. The, the word Internet Explorer, but it was our best deploy platform at the time.
Duck Little: Now, those two things were both pretty normal. Actually, there are other people working in the space that we that really have those two goals in mind.
Duck Little: What made GeoMoose unique was that we were dealing with a data for for large municipality that had multiple departments that were trying to inventory lots and lots of different assets and that meant we had hundreds of different data layers that were being digitized and produced
Duck Little: So this was sort of Genesis. You'll notice that there isn't hundreds of layers here but it deals with
Duck Little: Trying to describe different layers and catalog. It has basic map controls.
Duck Little: This was what a modern web application, including occasionally the broken images seen here looked like circa 2003. But this is sort of what we started with. And one of our first keys was the fact that we can describe these layers and controls actually using XML.
Duck Little: So,
Duck Little: We put all of this together and created an XML catalog. Because really we looked at the various pieces that we had and that we need to assemble so MapServer's configured using a format called map file. You can think of that is like a styling file for an for for a shape file.
Duck Little: Because that's also what would have been popular circa 2003-2007 and we had a lot of people contributing so XML was really, really
Duck Little: Unique for us and having a very basic markup was necessary for us because we needed to be able to describe you know how to organize all of these individual smaller pieces of work.
Duck Little: So what GeoMoose became was a really, really fancy XSLT. So that took the XML and translated to HTML, which then also had a giant JavaScript file next to it to render it
Duck Little: So I'm very sympathetic to the idea of we need to make the browser do more of this work. I really would have been sympathetic and oh yeah during this development time too.
Duck Little: And because nothing's more fun than a code snippet, we can take a look at what this actually turned into. You can see that we described a map book. If you've ever looked at Old School maps, particularly atlases, those were referred to frequently as a map book generically.
Duck Little: Because you had a book with multiple pages of different maps. So we created a map book XML format.
Duck Little: And it had the ability to organize things hierarchically. So we call it the catalog was part of the map book each layer got a label and a description to its source file and whether it was on or off could also be grouped because again we're dealing with hundreds of different layers.
Duck Little: And this is what we got to, from that Genesis moment to this and you can see a lot of interesting components that are going on here.
Duck Little: As the maps evolved. There was a lot of things that were necessary. We're also trying to convert people from using dedicated AutoCAD licenses for viewing maps so
Duck Little: If this looks more like a CAD application than we achieved our goal at the time, but you can see in the catalog. Many, many layers very well organized
Duck Little: rudimentary controls for navigation were available and
Duck Little: This entire user interface was described using XML.
Duck Little: And then we made it pretty!
Duck Little: Um, one of the cool things that we were able to do is because
Duck Little: At the time the FGDC was offering grants that allowed for cross community collaborations.
Duck Little: To share data. Well, having data defined as an XML format made it easy for us to interchange with other cities and counties.
Duck Little: And so we were able to access some of that funding to develop the application some more and refined the XML format a bit more so that we could exchange these formats and the applications with different counties.
Duck Little: At one point, nearly every county in Minnesota had a GeoMoose website because and quite a few in North Dakota and other neighboring
Duck Little: US states. In fact, we keep finding GeoMoose installations all across the world because people were able to really dig into the idea that you could describe a map using XML.
Duck Little: And whoa, it was good things were really fast to render even on you know hardware that would have come with IE6 as the upgrade browser, it still ran really fast.
Duck Little: And just like we were talking about HTML earlier being really great for editors and that that sort of source driven
Duck Little: epiphany that you can have by looking at the site and looking at the source, we had that by being able to directly map in the definition of the way or an XML to what they would see in the user interface.
Duck Little: some drawbacks to this.
Duck Little: One of the big ones was that the order in the catalog. So how do you define that XML structure was how it was seen in the map.
Duck Little: So if for some reason somebody put an aerial photography layer at the top of their catalog because they wanted users to see it. It would also end up being the layer that was had the top of their map obscuring the entire view.
Duck Little: There was also, because we had targeted MapServer and event and then evolve that to WMS there wasn't really good ways of
Duck Little: targeting different types of data sources. As much as you can come up with a way for defining how to describe that there's a data source there
Duck Little: The data sources are always going to be varied and that's continued to grow through the web at even though there are standard ways of doing it.
Duck Little: The other issue. We had this was an implementation detail is that every layer created an image tag. Really really cool because again, AJAX wasn't a thing. But then we started doing tiled maps. It broke, it broke it was making hundreds of requests in a second.
Duck Little: So we started the next version of the project.
Duck Little: Because GeoMoose was built using a custom mapping library we were sort of the 15th standard that XKCD refers to whereas
Duck Little: And the reason for that was because OpenLayers itself wasn't functional enough for us to switch over, but around 2007 it did.
Duck Little: It also had much better cross browser support because, well, you know in '07, you could still basically target IE and run everywhere.
Duck Little: And we also work with later versions of Netscape because they had the bank men, the JavaScript debugger.
Duck Little: But early versions of Firefox for coming out there. We're getting really usable JavaScript was becoming slightly less Wild Wild West-y with the concept of classes and even user interface toolkits
Duck Little: But really the main motivation was we needed to fix the relationship between a layer in the map and the definition of the map source.
Duck Little: So we evolved the format.
Duck Little: Here you can see it's a map book we gave it a version of 2.0
Duck Little: And we define this code snippet here that is for, in this case, a layer of fire stations. It's saying that the type of this data is coming from MapServer.
Duck Little: The name of the sources is the map source and this file element here is a shorthand to tell it 'Okay, this is the map file so form the URL to work with that map file' and inside of that map file. There's a layer named 'Fire Stations'.
Duck Little: This allows you to do quite a few things. First of all, it allows you to group multiple layers into a single request because you can put 10 layers from single WMS source in that way.
Duck Little: It also lets you break out as an administrator. The defining the catalog. You can have a difference between how those layers are stacked where there's where those layer where those rendered layers are getting data from and how they're sorted in the hierarchy of your catalog.
Duck Little: And this is a pretty basic GeoMoose 2.0 application, you can still see there's many, many layers that it's processing all at the same time. It's providing that asynchronous layer stack here in the map, along with a number of controls.
Duck Little: But not everything was great about it.
Duck Little: In terms of technical implementation, we had issues with what required what was a basically a custom Java compiler to
Duck Little: Put the different bits of JavaScript together, certain components stop working on newer versions of Internet Explorer.
Duck Little: And a lot of JavaScript is moved to functional programming models which there was no way we could support with what we were doing. But most importantly, the downside was
Duck Little: Because we had push all of the description into our map book XML format it got unwieldy large, it was unsustainable to define every UI element inside of the XML. We inlined all of these all of the code for styling data feedback, including pop ups and identify templates and
Duck Little: So it was hard to keep moving it forward, it was hard to evolve the application because we've sort of built ourselves into a into a tag corner in XML.
Duck Little: Some other pretty important things happened while we were developing it Google took over the whole world about 10 different times and about 10 different ways, people started putting mobile supercomputers in their hands,
Duck Little: The Open Street Map project started, you know, publishing new innovative ways of structuring some Geo data.
Duck Little: And a lot of vector data has gone to the web. You know, you think about the adaptation of GeoJSON or MapBox vector tiles. And the way you an administrator used to think about data was 'I have shape files, I'm going to render them using my favorite
Duck Little: Map rendering service and it's going to get put in the browser.' But now,
Duck Little: You could just have data sitting in in an S3 bucket somewhere. And I want to put that on my map, and that includes
Duck Little: You know, GeoJSON data includes like MapBox vector tiles could pre render a whole region of vector tiles and this even includes,
Duck Little: More streamable formats like cloud optimized GeoTIFFs. What if I just have a picture I want to slice and dice and it's properly indexed.
Duck Little: Or Streamable JSON, things like new line delimited JSON that work with streamable web servers. I mean, cheap cloud compute means you can put terabytes of data on a map for pennies.
Duck Little: So we thought we should adapt to the times and that brought about the GeoMoose 3.0 development.
Duck Little: But even during our evaluation, even with all of the modern stuff that we were trying to to adopt and looking at new patterns
Duck Little: Of programming, we still came back to the best way to describe some of this stuff is knowing that there's a map that there are layers and that there are map sources and we can describe that in XML.
Duck Little: So we can still use us pretty familiar tags. So the new implementation was so fresh and so clean
Duck Little: And looked almost exactly the same to to a lot of users, because what we were able to
Duck Little: Develop a brand new application on a completely fresh stack, both to our administrators who are real target and
Duck Little: To the users the application looked very, very the same. In fact, we were able to write a small conversion tool that allowed users of GeoMoose 2 to to upgrade their XML to GeoMoose 3. In fact about 90% of the tags were able to migrate forward.
Duck Little: This has helped a lot. We've got the ability to handle different types of data sources be them be them raster vector or even
Duck Little: Things like GeoJSON and vector tiles. We can parse them natively and render them for users.
Duck Little: We also created the idea of a 'query as' concept because sometimes you have browsers have different capabilities and you might want to present the data differently.
Duck Little: For example you we have the ability to define a layer as being displayed in the map using a WMS source. But if you want to get the attributes for a feature it'll use WFS.
Duck Little: But we learned some stuff and some real important lessons here. Cartography is hard.
Duck Little: Picking how you want to style those features once they're in the browser can be very, very difficult. And there's been a lot of successes and failures. Over the years, you know, map CSS.
Duck Little: There's been I think three different flavors of that throughout the years.
Duck Little: SLD the OGC standard for how to define a layer, that gets pretty verbose, and can be very scary for people, even with editors.
Duck Little: MapBox GL style sheets has been sort of a one organization show though it's been pretty innovative. OpenLayer styles styling, as you saw, as you could see in previous examples
Duck Little: Just in the demo set, can get very complicated for simple things like a point and MapServer map files are really
Duck Little: Great for styling stuff on the server. But there's no implementation in the client. And these are just the ones I could think of quickly that were mostly successes at one point. T,here's been a lot of other things that have failed that the haven't quite made it through.
Duck Little: The other thing we discovered is that performance can be quite hard. It's important to think about what happens when someone takes that really cheap available cloud compute power and tries to stuff it into your browser.
Duck Little: Even with Web GL. You don't want to put gigabyte, you need to think about how you're going to put gigabytes of data onto your map.
Duck Little: And communicating. How do you the complex definitions can be hard as well. The 'query as' thing that I was previously bragging about is also one of the hardest concepts to explain to our administrators who are trying to do is get their data on the web.
Duck Little: Also some future challenges just in the mapping sphere that I think are, are
Duck Little: We're trying to deal with as a project we're trying to think about them. The first is 3D that beyond how you define that data and how you communicate that data.
Duck Little: Point Clouds are as a technology really really evolving. There's an end, there's a project called entwine that puts 3D points into the map.
Duck Little: And they've also become cheap and available because you can put a light or puck on relatively inexpensive hardware and collect gigabytes worth of 3D points very, very quickly.
Duck Little: Growing through mobile is also hard. People just expect a single site to work on just about every device that they have no one wants to think about going to the /m.html site anymore.
Duck Little: And a lot of maps cheat this by having an m.html site somewhere or require or saying this doesn't work in your browser. But users are no longer accepting that they wanted to work on their tablet their laptop.
Duck Little: Their 30 inch screen and their 3.75 inch diagonal screen that they carry with them all the time.
Duck Little: The other thing that's really ramping up that that it's going to get harder to describe is with a lot of the new satellite data Lance at Planet, etc. There's a lot of accessibility towards detailed multi band data that are getting pushed to the browser.
Duck Little: And that's going to be a future challenge for describing a map.
Duck Little: So some big takeaways from the GeoMoose project through the years, you can XML it. There is a way of describing maps
Duck Little: Where we can use XML and HTML tags to describe them and describe them effectively. We've got 15 years in the business at doing this. And so I think, and I think we do a good job.
Duck Little: Also, I really think the idea of having a map source definition and a layer definition is very, very important. You'll hit a wall very quickly if there isn't some sort of definition between there.
Duck Little: Styling is hard and gets complicated and needs to be considered hard and yes, eventually a user will indeed try to stuff multiple gigabytes of data and render it in your browser.
Duck Little: All right, I went kind of fast because it's
Duck Little: Hoping to get a lot of content in. But I'm always open to questions.
Peter Rushforth: Thanks, Dan. That was really interesting.
Amelia Bellamy-Royds: Indeed, and
Amelia Bellamy-Royds: A great
Amelia Bellamy-Royds: Starting session for the workshop to give that historical perspective of how much has changed and how much we still have to work on.
Amelia Bellamy-Royds: The main forum for questions that we're going to
Amelia Bellamy-Royds: Try and encourage people to
Amelia Bellamy-Royds: Use is the discourse.
Amelia Bellamy-Royds: at discourse.WICG.io and
Amelia Bellamy-Royds: That way people can ask questions, even if they weren't here on the live session, they can
Amelia Bellamy-Royds: Follow up from watching the video.
Amelia Bellamy-Royds: So unless anyone else has any logistics. I think we will wrap it up for the day.
Amelia Bellamy-Royds: remind everyone to check the agenda for the next session, which is a little over 30 hours from now.
Amelia Bellamy-Royds: So either tomorrow or the next day depending on what time zone you're starting in and
Amelia Bellamy-Royds: I will not be hosting that one I think Peter Rushforth is up for hosting day two.
Amelia Bellamy-Royds: Will be talking about
Amelia Bellamy-Royds: The map data and server standards, OGC, and how those standards are good for the web or maybe not good enough for the web. And we'll also have a hopefully very interesting panel,
Amelia Bellamy-Royds: Representatives from government geospatial data providers on
Amelia Bellamy-Royds: What web maps mean to their organizations.
Amelia Bellamy-Royds: So I'd
Amelia Bellamy-Royds: Like to thank everyone who has joined us today, or who is watching after the fact.
Peter Rushforth: I posted links to the discourse,
Peter Rushforth: Discourse forum with some topics. And as soon as that Dan's presentation is available via video, I will post a link to that, but I'll post a link to his slides first. And with my appreciation Dennis really interesting, I would like to chat.
Peter Rushforth: Anytime offline.
Duck Little: Thanks, everyone.
Peter Rushforth: Thank you.
Peter Rushforth: All right, we'll see you tomorrow.