Amelia Bellamy-Royds: Okay. Welcome, all. We have a busy schedule today. So we're going to get started right away.

Amelia Bellamy-Royds: If you're not sure we're at the W3C OGC workshop on Maps for the Web. This is day three.

Amelia Bellamy-Royds: If you missed day one or day two. I think they are both now up on YouTube and we will get the links integrated into the agenda soon.

Amelia Bellamy-Royds: There is also the ongoing live chat on Gitter. And there are multiple links to it now, from the zoom chat and

Amelia Bellamy-Royds: More long form discussion on Discourse somebody can throw a link to that into the chat as well.

Amelia Bellamy-Royds: I would like to remind you that we are operating under the W3C's code of conduct and respectful behavior is expected from everyone.

Amelia Bellamy-Royds: Beyond that, I think we're gonna get started, our theme for the first hour is a native map viewer for the web platform. Can we add something to the web that tells browsers, how to display maps.

Amelia Bellamy-Royds: Are on that theme we have four different talks to start it off. We have Brian Kardell, Brian Kardell works at Igalia as a

Amelia Bellamy-Royds: Advocate and networker extraordinary. But even before that he's been involved in web standards in various capacities, he's going to be talking to us about extending the web with new features and something about pie. So I hope you brought enough for everyone, Brian.

Brian Kardell: Okay, I'm going to share my screen.

Brian Kardell: Let me know if you can see that

Amelia Bellamy-Royds: It's working.

Brian Kardell: Okay and I'm going to also drop in a link

And

Brian Kardell: If you open that link in your chromium or your browser tab, it should advance as we go. And you'll get a smoother experience, probably, if you prefer that

Brian Kardell: Okay. So yeah, I am Brian Kardell. This is my website you recognize it as a website because you see it in a web browser with the URL. But in that same browser, you can do pretty much anything that you would want to do on the computer, which is amazing.

Brian Kardell: But also, many of the desktop apps and mobile apps that you download and use as first class things on your devices are also under the covers using web engines.

Brian Kardell: And so are lots of embedded devices. Now your smart refrigerators, your TVs, car and airplane infotainment systems digital signage point of sale systems.

Brian Kardell: Basically, as long as there's a UI, you can bet that there's somebody working on trying to do that with web technology. In fact, even if there isn't a UI, we're using aspects of the web platform.

Brian Kardell: Even if US went on out into the forest or on a remote beach somewhere and read a paper book, there's a pretty good chance that

Brian Kardell: web technology and web standards were involved in the printing and creation of that book. So what I'm trying to say here is that the web platform is infrastructure. It's a huge commons on which we've built basically all of society at this point.

Brian Kardell: But if you're on the edges of that and you're trying to improve the platform and you don't work for a vendor. You're just a developer, you want to make things better.

Brian Kardell: It can feel a little bit frustrating sometimes it can feel like you've been put on hold and even though they might say your call is important to us. It sure doesn't feel that way sometimes

Brian Kardell: So part of my talk. I want to give a pep talk here. Yes, I think we could do this, but I would also like to explain the reasons why it can feel this way and the practical challenges and kind of keep us grounded in reality. So the reason is pie.

Brian Kardell: So that needs some explaining. So as an illustration. We're all here giving some amount of our finite time and energy pie to think about and discuss this topic.

Brian Kardell: Now we all have different amounts of pie. Some of us are here because it's a labor of love, we just really believe in it. We think it's the right thing to do and lots of others of us work for companies and our companies have obviously different amounts of pie.

Brian Kardell: We have very, very different budgets of pie, as we're coming into this discussion and some of us bring the most pie, we bring the most critical pie and the one to make a rendering engines are the most critical

Brian Kardell: But it's important to recognize that their pie is still finite and also it's voluntary.

Brian Kardell: It's not cheap. I want to point out that there are thousands of person years investment into each one of these rendering engines and that is just the code part that isn't the standards part which is really, really big.

Brian Kardell: The wants from folks like us as the commons grows are only accelerating and every want represents and ask for some slice of pie and

Brian Kardell: The slice, how much we're asking for differs from engine to engine because

Brian Kardell: These are different companies with different budgets and they have different constraints and priorities limited to staffing and talent.

Brian Kardell: And they also have different architectures. So things cost different amounts so realistically, we have to prioritize. There is absolutely no choice but lots follows from this, it has big domino effect.

Brian Kardell: The first one is in order to be involved in any discussions, they just like we do have to make some value judgment. We're not doing other things that we could be doing right now we're doing this.

Brian Kardell: And we're doing that, based on some judgment. But how do you estimate what it takes to be involved is very difficult if you're a vendor because you know what it really takes

Brian Kardell: And so lots and lots of stuff takes a really long time to get past 'Go' or some things never do, or maybe some things just haven't yet like maybe maps.

Brian Kardell: So the result of this is that in 30 years that the web's been around we have created about 130 elements for HTML.

Brian Kardell: And over half of those are just spicy dibs is how a friend of mine, Dave Rupert calls them. These are things like paragraph strong emphasis, they have very low implementation costs, but very, very high standardization costs while we discussed them.

Brian Kardell: But even if you make it past those steps now you get to where we have to actually get it done and we have to get it done everywhere. We have to get it done interoperably

Brian Kardell: Which we frequently learn along the way. We have to get it accessible and styleable, which are things that we frequently still get wrong, especially in early implementations

Brian Kardell: And costs go up very quickly with complexity. Like even a little bit of complexity. So to illustrate this in 30 years we have created one non form based interactive standard UI control element.

Brian Kardell: Like the sort of thing that you would find in a standard UI toolkit that isn't about collecting information and that is summary details which looks like this. It is probably the simplest UI widget in existence. It has been around as long as there have been GUIs

Brian Kardell: And this has been a work in progress for a long time. The last major browser added support in June or in January of this year and that was accomplished. Actually, the full parity was accomplished by one of the rendering engine disappearing when

Brian Kardell: Chrome(editor's note: Edge) switched their internal rendering engine from theirs to Chromium. They just got it by default.

Brian Kardell: And then finally, if you make it past all of those hurdles. It's finally real like it is actually literally everybody can use it. It works everywhere, it is by all definitions, the standard

Brian Kardell: But that doesn't mean that everybody knows that we've reached that point yet so it takes some time for people to learn about it.

Brian Kardell: And then it takes even more time for them to find a use case where they need to try it. And then finally, at that point, we get developers involved, way, way at the end.

Brian Kardell: And we asked them, hey, how is that super expensive pie taste that took a decade and millions of dollars and the response is frequently

Brian Kardell: It could be better, to be honest.

Brian Kardell: So that sounds very, very depressing. But that is sort of like the historical challenge, and that is why several years ago.

Brian Kardell: A group of us got together and discuss these problems and created this document called the extensible web manifesto and what it says basically is we can do better than this.

Brian Kardell: One way we can do better than this. Is that the cow paths currently aren't very clear, we say that we pave the cow paths, but really it's a little bit like reading the runes,

Brian Kardell: We're looking at many other cow paths and trying to build a new road that meets all of the same criteria in a completely different way.

Brian Kardell: So a better way to do this is to give developers mostly the same abilities that browsers have to create new elements.

Brian Kardell: And let developers, bring the early pie. They're the ones with all the ideas and they're the ones that are actually capable of testing things

Brian Kardell: They're the ones that are ultimately have to accept this solution as adequate and we can find out do developers actually like and use it or not, because very frequently we are wrong.

Brian Kardell: Because a failure in this model is a feature, right, like we can float lots of ideas and people can say what about this, this seems great and people can say no. But we can do better than that. And very quickly adjust

Brian Kardell: This also I think plays into the ability for us to explore adjacent possibles when we give people new tools they dream new dreams that we hadn't even thought of yet.

Brian Kardell: I think this is important because so many things wind up being fantastically successful at something they weren't even designed for

Brian Kardell: Including the web itself, actually. So this document suggests that we should get out of the way we should enable

Brian Kardell: Developers to explore these spaces we should give them the tools and we should not spend those precious resources debating

Brian Kardell: How developers might use things or what they might like in give them the tools to show us and focus on science to know when they're discovered something so that we can write it down. And that can work more like dictionaries.

Brian Kardell: There aren't committees for dictionaries that create words, they they write down the words. So this is all high level stuff.

Brian Kardell: But I think there are some important details at least they're important to me that I would like to discuss, which is that one of the goals here in my mind is for this to lay a nice bright unambiguous path.

Brian Kardell: That we can then pave that has proof that is accessible, that is acceptable to developers that it ticks all the boxes and it is estimable and it explains how does this map very well to the web platform.

Brian Kardell: So I think that what the extensive web manifesto is saying a lot of it is to break it down to reduce the magic required in anything, expose the parts and aim for the middle

Brian Kardell: So an example of this is dialog, dialog is this element that is in almost every UI toolkit and it creates this layer on top that you

Brian Kardell: Interact with, but it also does all these other subtle things and inside it is magic, lots of magic. It does things like prevent you from selecting the text behind it prevent your tab focus for moving out of it. Give you controls for styling that and so on.

Brian Kardell: Change the how things are exposed to accessibility.

Brian Kardell: So the original proposal for dialog is a big ask for a budget and if we succeed in delivering it will deliver that thing I showed on a few panels ago and will it be adequate? We don't know, but it will be helpful in solving only that problem.

Brian Kardell: But if you look a crack open the magic. There is this concept of inertness, that is used to define dialog, which is

Brian Kardell: All that other stuff that I said it does about managing text selection and ARIA and everything. And it's fundamentally necessary for dialogue, but it's also useful for lots of other UI.

Brian Kardell: Patterns and components that we haven't even started talking about standardizing yet maybe some that we never will like drawers.

Brian Kardell: So we split that out and made an exposed to developers and we focused on doing that, first, so that is delivers a lot of value.

Brian Kardell: For a lot of things that can explore the space and it reduces the overall amount of pie that is required for dialog that changes the calculus of whether it's worth the investment. It's much more estimable and it is very much follows basic software development ideas.

Brian Kardell: Then it allows developers to use inert to explore the space with other controls and the way to pay for those controls, then it's very clear because we know that is inert. We don't have to reinvent that

Brian Kardell: So exposing these middle layers actually helps build resilience and adaptability and helps make sure we're not biting too much off and as the web changes like we have the ability to adapt.

Brian Kardell: So what's all this got to do with maps. I know it feels like I'm a little bit off topic, but should the web have maps is the question we're asking and yes

Brian Kardell: It seems clear, sure.

Brian Kardell: But we need so much. There's so many things that the web should have that the web doesn't have. And there's just not enough pie.

Brian Kardell: So another thing you can do is you can bring more pie

Brian Kardell: My company Igalia. That's what we do. The reason that the current model the historic model exists is simply because that's what we let happen but

Brian Kardell: Igalia and other companies like Bocoup who's presenting also today can help you.

Brian Kardell: When you have prioritization problems where you can't get the attention that you need from somebody who has the expertise and the knowledge to help this move along. So we have done that for things like CSS grid.

Brian Kardell: And lots of lots and lots of features.

Brian Kardell: So for maps, though I think my advice, though, is that all of these things that I was just talking about apply, we have this problem of we have lots of maps sort of that have lots of commonalities and it feels like there's a path there. But how do you map it into HTML. And it's very difficult.

Brian Kardell: And which features should it include, and what is ultimately good enough, I think, despite the fact that we have lots of experts and we have libraries and things like that. I think we don't know what's good enough until

Brian Kardell: We try some things and developers will tell us like they'll know it when they see it and it might be shocking. What is good enough, HTML was certainly shockingly, you know, good enough, there were better solutions before HTML came along.

Brian Kardell: But also at the end of that when we have an answer, it's important that it fits well into the platform and that it's aware self aware of the pie it's asking for. So I think

Brian Kardell: Break it down and aim for the middle and improve the cost benefit analysis, find unlikely allies.

Brian Kardell: Like find ways that we can deliver parts of it and share the pie that we're asking for. So one way to do this is to ask what are the things that are making it hard technically today and are those things only hard for you and I would suggest maybe squint at it a little bit.

Brian Kardell: There are very similar course green needs for like video game maps or maps of fictional spaces. If you want to their maps of Mordor. For example,

Brian Kardell: If you squint even a little bit harder things that aren't maps at all that also have very similar needs product images for e commerce is a really big one that people aren interested in, technical drawings

Brian Kardell: So basically, the web is lacking lots of coarse grain features that we can that we can do and low level things like pan and zoom is a great one.

Brian Kardell: Lots of things need that. Offscreen canvas, maybe hardware accelerated SVG. This is one of the challenges that we don't know what the necessary parts are yet.

Brian Kardell: But I don't have the answers. I think there's probably a lot and I am here to hear your ideas and see how I can help. So thank you.

Sébastien Durand (Canada - NRCAN - CGP): I just want to say, Great presentation was very fun to watch good content too. Thanks.

Brian Kardell: Thank you.

Amelia Bellamy-Royds: Indeed, thank you, Brian.

was amazing.

Amelia Bellamy-Royds: Good way to start the day

Amelia Bellamy-Royds: We are going to continue now with something a little more map focused Peter Rushforth is going to present in more detail what he hinted at the other day, the proposal he built for a MapML a specific way of

Amelia Bellamy-Royds: Including map viewers in HTML using markup.

Peter Rushforth: Thanks, Amelia.

Peter Rushforth: I recorded my presentation. So it kind of auto plays, but that was great presentation Brian, and thank you very much for bringing your personal energy and effort to this and we definitely welcome your words of wisdom.

Peter Rushforth: And we'll try to follow them.

Peter Rushforth: So I'm going to go and share this and start my presentation.

Peter Rushforth: Thank you.

Good morning. In this presentation, I'll give an overview of the MapML proposal.

MapML is a proposal to extend HTML in the HTML namespace to include elements into attributes that implement maps and layers.

The objective of our proposal is to introduce a small set of HTML elements that will directly support maps and mapping applications with approximately the same authoring complexity as video or audio or image.

Why do we need a map element, exactly? We need a map element to provide a declarative semantic entry point in web standards for a few reasons. Above all, we need to standardize Web Map client technology because we should. It is the ethical thing to do.

We need to make standard web maps learnable by children, not by binding such an important facet of human existence, not to mention survival to proprietary frameworks.

Having made that decision. We need a map element to obtain more efficient rendering of spatial content.

Next we need to define and standardize what accessibility means for web maps and especially Web Map content.

Finally, we need to establish an organic, not based on metadata basis for spatially indexing web pages. So that search engines can return search results based

Not only on ranking the text of documents against search terms, but also based on spatial indexing of map elements in the page.

Like the PageRank algorithm. But instead of or as well as backlinks increasing a hits relevance, the pages literally nearer to the search term would raise the result rank.

We propose to extend the existing map element by adding attributes and new child layer elements.

The map element is a reasonable candidate for extension, not only because of the element name.

But mostly because of the elements processing model is already that of an interactive, albeit static map with layers represented by the image and area elements and the image map semantics potentially provide

A path to script lists accessible graceful degradation. This is the basis upon which other proposals to modify HTML have been successfully made, for example the image source set attribute, among others. This approach also seems to be encouraged by various HTML design principles.

The design principles aren't a license to propose changes to HTML, but they are a framework to help guide decisions, design discussions.

So if you have a concern about any of the design you hear about today, please consider joining the group and contributing those ideas.

If we consider a diversity of viewpoints and experience, we will achieve a stronger proposal.

The result of the proposed extension, whether it results in a map element or something else should be a map widget or viewer that is designed for accessibility and is progressively enhanceable. In other words, scriptable.

It's not the intention of the proposal to accommodate by means of native browser implementation all use cases of web maps today.

It is a key objective of the proposal to expose DOM APIs, events and other facilities such as styling that relate to loading, rendering and using and creating map content.

I've got more to talk about today than I have time for. So I'll cover some of the big ideas first. To begin, I'll talk about the key elements of the proposal, the map, layer and extent elements.

Then I'll spend time talking about titled coordinate reference systems or TCRS because understanding those concepts is key to making sense of most of the proposal.

Map projections define the coordinate systems in effect

In the scope of the map. So that coordinates of places on Earth or potentially other planets too maybe drawn on a 2D plane.

Every map has a coordinate system that is shared by its layers. So the proposed map element has a set of defined projection values. The default value if unspecified is OSM tile, which corresponds with Web Mercator

The set of projections is small yet extensible. In the same way that, for example, HTML rel values are extensible. In other words, by agreement.

I'm using the attribute name projection here as a user friendly term to describe the concept that I call tiled coordinate reference systems or TCRS

The term TCRS is defined in this proposal and represents a framework for naming and discussing the integrated concepts of tile caches,geospatial coordinate reference systems and Web Map client concerns.

Web maps all define their starting conditions, typically via a lat long coordinate pair representing the center of the map. So the map element has required lat long attributes describing it starting center point.

On the web as in real life, maps have scale. So the map element has a required to zoom attribute which define the starting scale.

This is actually a very important point, and one that can go unrecognized. Web maps are in fact real life maps in which paper or mylar has been exchanged for pixels. Everything that is represented must be represented according to an intended scale, including geographic features.

The Boolean controls attribute turns controls on or off. Controls are created by default in a closed shadow root. Like the video element, the controls list attribute can prune the set of native native controls provided

We need a layer element to be a child of the map element because map layer is a primitive abstraction that is shared by many, if not most maps, both on and off the web.

Layer elements represent map content and each must share the coordinates systems defined by the parent map elements projection attribute

Map Layers and their content are in the light DOM in the same way that SVG content is in the DOM.

Layers are added. According to the painters model in document order. Their label attribute will appear in document order in the layer control.

Layers are children of the map element only and do not nest. Content can be in line or located in a document at the source attribute URL.

A layer has a text label attribute

A 'checked' layer renders on the map.

A hidden layer is not shown in the layer control that is rendered on the map. This can be useful for preventing the user from turning off important content and becoming confused.

Layers can have inline content as shown here, that is loaded and rendered by the browser.

Web maps need a standard mechanism to load map data that does not involve knowing how to access server APIs beyond the strict uniform interface of HTTP.

Browsers standardized HTML forms as a means to flexibly request and transmit data to and from any server within the constraints of the HTTP uniform interface.

Web Map Server data comes in a wide and growing variety of formats and interfaces. This poses severe challenges for interoperability.

So, we designed a mechanism for loading and accessing server information based on established patterns, for example, URL templates and standards like WMS WMTS and OpenStreetMap Slippy tiles and informed by the HTML form element.

The extent element represents the part of the layers content that binds to the viewport of the map.

The extent element is somewhat analogous to the form element being the parent of various inputs and links the values of which are serialized during extent processing.

Extent processing differs from form processing in that the user is not expected to fill in input values manually because the extent being bound to the map viewport triggers content requests automatically as the map requires new content to paint.

New content is typically required as the user either manipulates the map by panning or zooming, or the device by rotating or moving it

The rel="tile" value, shown here associated to tile based URL templates reflects a core abstraction in modern web maps that of map tiles.

The rel value tells the browser what the purpose is of the resource that it is loading. So as the rendering engine iterate over the tiles that it needs the browser fires events which are serialized to variables identified by name.

Each input variable binds to one or more variable references in the URL template links within the extent elements scope.

Once all the variable references are resolved the URL template becomes an actual resource URL that is fetched and rendered

An extent can contain as many such URL template links as it needs to compose the map layer.

In the example shown above the geometry and labels of the layer are referenced by separate links.

Tiled Coordinate Reference System or TCRS is a term coined by me to standardize and describe a system of talking about spatial coordinate reference systems from the web clients and users point of view.

When working with maps and spatial information we inevitably need to talk about coordinate reference systems and especially scale and TCRS is my attempt to unify the vocabulary for coordinate reference systems so that this core concept can be made interoperable and teachable.

Historically geographic information systems have kept the concerns of map scale separate from those of the coordinate systems definition.

By maintaining intimate and detailed metadata about the coordinate systems of the data they manage so that data can be interoperable combined or overlaid at runtime.

Web architecture requires that resource metadata be encoded into media type specifications. So that runtime exchanges are not necessary or desirable. So we needed to develop the TCRS concept in order to encode it into the MapML or eventual HTML specification

A TCRS has a defined number of integers zoom levels.

A zoom level is an integer proxy for expressing a real world distance units per pixel ratio. In other words, the pixel size at a defined location, depending on the projection typically the projection origin.

The reason the set of zoom levels is defined and not infinite is because in some cases, there isn't a mathematical relation between zoom levels.

In other words they're not necessarily evenly spaced as shown. They may have been chosen for reasons, specific to the application.

And the fact that beyond a certain distance per pixel. It doesn't make real world sense. By agreement and specification, then the zoom levels are defined and known.

For each zoom level in a TCRS, there exists a pair of 2D coordinate systems in which the units are pixels and tiles, respectively.

These coordinate systems follow the conventions of coordinate systems in computer graphics having their origin at the top left of the screen.

With the vertical axis being positive down and the horizontal axis positive to the right of the screen.

The pixel based coordinate system is called a TCRS with axes named x and y, the tile based coordinate system is called a tile matrix. After the OGC concept of that name at its axes are named column and row.

Tiles are defined in 256 square aggregations of pixels and the pixels and tiles are geo referenced by a defined planar transformation to the coordinates space, defined by the projected coordinate reference system or PCRS

The coordinates and units of the PCRS are defined by a mathematical transfer of coordinates to and from a defined geographic coordinate reference system or GCRS according to defined parameters of the projection method.

To additional coordinate reference systems are defined to correspond with the same concepts from the WMS and WMTS standards.

The map coordinate system is defined by the maps dynamic viewport, and has its origin in the upper left corner of the map.

The horizontal axis is named I while the vertical axis is named J this coordinate system corresponds to the image coordinate system in HTML client side image maps.

It's also used by WMS Get feature info requests to record to to query server databases for features at a given pixel within a defined request.

The tilee coordinate system is created relative to each tile and also has I and J axes.

It is created in MapML in order to support MTS get feature info requests.

Thank you.

Amelia Bellamy-Royds: Thank you, Peter.

Amelia Bellamy-Royds: Lots of information there, but I hope it was enough to get people intrigued into looking more and the scope of the project.

Amelia Bellamy-Royds: Um,

Amelia Bellamy-Royds: Our next talk is going to

Amelia Bellamy-Royds: Take another look at MapML, specifically a more critical assessment from the web standard side.

Amelia Bellamy-Royds: Simon Pieters is been involved in web standards and browser development for many, many years. He currently works for Bocoup which is another sort of web browser development, web standards development for hire companies with a specific focus on

Amelia Bellamy-Royds: Testing and cross browser interoperability work and Simon was commissioned over the past few months to sort of assess the MapML proposal as it is and how it can be moved forward. Simon, why don't you take it away.

Simon Pieters: Thank you for that introduction.

Simon Pieters: I'm going to try to share my screen. So let's see if that successful

Simon Pieters: Can you see my screen.

Amelia Bellamy-Royds: Yep.

Yes.

Simon Pieters: Excellent.

Simon Pieters: So hi, everyone. I'm Simon Pieters, I'll talk a bit about Bocoup's review of MapML that we did earlier this year.

Simon Pieters: So again, a short introduction to Bocoup, we're a web consultancy, web platform consultancy firm. We participate in Ecma, W3C, WHATWG.

Simon Pieters: Work on improving the web platform through specifications and test suites, we have experienced standardizing both new and legacy features in HTML and CSS.

Simon Pieters: Also JavaScript and writing corresponding conformance tests for browsers.

Simon Pieters: So we can help with the standardizing new feature is for the web and collaborate with the browser implementers.

Simon Pieters: We participated in the OGC Testbed 16 program to review the technical specifications for MapML. So here are our findings and recommendations.

Simon Pieters: We reported 21 issues for MapML from minor to more fundamental

Simon Pieters: One of the fundamental issues is whether and how MapML should being be an extension to HTML.

Simon Pieters: My understanding is that it's the intent, but it's not really define the such currently.

Simon Pieters: If it is to extend HTML than it should be done properly, and ideally involve the maintainer of the HTML standard in the process.

Simon Pieters: Another aspect is integration with CSS. MapML that it should be scalable with CSS, but it's not defined how

Simon Pieters: I think CSS not does not yet have the necessary primitives to represent web maps without resorting to solutions that are working against the browser, which is not ideal for performance or accessibility as well as other aspects.

Simon Pieters: We reported an issue for the CSS Working Group to consider adding a new panning and zooming primitive

Simon Pieters: For use with web maps. This is one of the primitives or low level capabilities that

Simon Pieters: Brian mentioned. Web maps have

Simon Pieters: Many

Simon Pieters: Possible capabilities that are missing from the web platform, but this is

Simon Pieters: One that we identified.

Simon Pieters: So the CSS working group discussed this

Simon Pieters: In July, and agreed that it would be interesting to investigate, but they need a concrete proposal.

Simon Pieters: So David Baron is

Simon Pieters: from Mozilla

Simon Pieters: And

Simon Pieters: Said that it was interesting, but need a concrete proposal and Tab Atkins is

Simon Pieters: From Google, one of the editors of the many CSS specifications.

Simon Pieters: Essentially agreeing that

Simon Pieters: It's something that would make sense to solve but

Simon Pieters: There's no no proposal yet.

Simon Pieters: So again, going back to the extensible web manifesto that has been mentioned a couple of times.

Simon Pieters: I think the approach that is more likely to have success in changes in browsers at this time, is to start with specifying the primitives, or a low level capabilities that are needed to layer MapML on top.

Simon Pieters: Even if there is skepticism about adding maps to the web. People seem supportive

Simon Pieters: Of adding new primitives that benefits web maps and this approach is in line with the extensible web manifesto, which says to focus on primitives first and then develop high level solutions in JavaScript using those primitives.

Simon Pieters: Allowing web developers to iterate without breaking the web.

Simon Pieters: Another thing we think would be good is to better demonstrate the need for web maps in terms of impact for web developers.

Simon Pieters: One way to do this is to ask about web maps and the MDN developer needs assessment survey.

Simon Pieters: Which is currently in the final stages of preparation.

Simon Pieters: Last year, the survey had responses from 28,000 web developers and the results impacted the prioritization for browser vendors

Simon Pieters: Our summary of work for this review is available at the URL at the top of this slide bit.ly/bocoup-testbed16

Simon Pieters: And that's all I have. Thank you.

Amelia Bellamy-Royds: Thank you, Simon.

Simon Pieters: Thank you.

Amelia Bellamy-Royds: And I'm looking forward to creating the

Amelia Bellamy-Royds: Discussion page and we can get all those links and easily clickable forum so people can go look at and comment on the issues.

Amelia Bellamy-Royds: For our final talk on this theme we're going to switch over a little bit. Satoru Takagi of KDDI has been building maps using web technology for

Amelia Bellamy-Royds: Many years now using a base of SVG and

Amelia Bellamy-Royds: Has developed proposals for what needs to get added to SVG, to make it more Web Map friendly. So he and Peter Rushforth are going to be introducing some of the work they've done on that.

Amelia Bellamy-Royds: Peter, if you're talking, we cannot hear you.

Peter Rushforth: Yes, of course.

Peter Rushforth: Ah sorry Satoru Takagi-san and a colleague from Katie di corporation have developed

Peter Rushforth: Two papers for this workshop which are linked to their

Peter Rushforth: To their agenda item and I promised Satoru-san to to present the introduction, introduce these two

Peter Rushforth: Papers that are very, very interesting and expertly crafted and

Peter Rushforth: I promised to introduce them at the workshop. And I think that there is, in particular, well worth reading because Satoru has been working for years within the many years within the

Peter Rushforth: SVG community in the W3C Consortium to standardize web maps using web technology and

Peter Rushforth: I strongly believe that we share a lot of, you know, fundamental primitive understandings of how the web works and

Peter Rushforth: He has got some spicy commentary, spicy yet polite commentary in his in his papers and the first of them is on decentralized web mapping and it's very important to read them in order. Because decentralized web mapping sort of sets up the second paper and

Peter Rushforth: In decentralized web mapping,

Peter Rushforth: Layers are conceived of as the primitive feature of web maps and are accessible at their undifferentiated URLs, just as in the map ML proposal, but in the in the SVG map proposal

Peter Rushforth: In this framework, the, the target of those URLs is an SVG document that links to an HTML

Peter Rushforth: Logic bundle. And so each layer comes with its logic built into the actual document that is loaded. So what this means is that it can adapt, it's an adaptive framework to virtually any tiling system proprietary or otherwise. And I think that's there's a lot of genius in that in that

Peter Rushforth: Package right there.

Peter Rushforth: And that leads to the discussion of quad tree composite tiling and the standardization of tiling and which Satoru-san has applied the techniques of SVG map to use adaptive quad tree tiling to vector information which is

Peter Rushforth: Which is efficient very efficient and and so for raster data standard file system seem to make more sense plus or minus the different APIs that are

Peter Rushforth: used to access them. But for vector data, because vector data is meant to be efficient, an adaptive tiling system.

Peter Rushforth: Has real performance benefits. So I urge everyone to read those two papers and provide feedback and commentary to Satoru-san and his colleague

Peter Rushforth: Whose

Peter Rushforth: Links are here to their GitHub profiles, but there there are discourse entry for they're talking the agenda is in the agenda. So that's all. Thank you.

Amelia Bellamy-Royds: Thank you Peter for the introduction. Do you have anything to add Takagi-san, or just that we should read the papers.

Amelia Bellamy-Royds: Well, we've all got the papers and

Amelia Bellamy-Royds: The links are in Gitter and in Discourse, I think, then we will take 10 minutes to catch up on that and then start back up with our new theme and panel.

Amelia Bellamy-Royds: Recording again? Take it away, Doug.

Doug Schepers: Great. Hi everyone, welcome back. Thank you so much for joining.

Doug Schepers: Next up is our internationalization and security

Doug Schepers: Presentation and following we'll have 30 minutes, two talks in 30 minutes and following that we will have

Doug Schepers: Our world, our panel, which is worldwide web maps challenges in the global context. So with no further ado, I'd like to welcome Brandon Liu

Doug Schepers: Who is going to be talking to us today about multilingual text rendering and Brandon is the geospatial software engineer from. No, I'm sorry. He's a

Doug Schepers: He's the creator of Protomaps. It's just a new internationalisation focused system for maps on the web. He's been working on map rendering and data tools related to the Open Street Map project since 2013

Doug Schepers: He also created

Doug Schepers: 80s.nyc a Web Map based viewer for historical street views of New York which sounds really cool. Ready to take it away. Brandon, take it away, please.

Brandon Liu: Awesome. I'm going to try to share my screen right now. So please tell me if that's working.

Brandon Liu: Oops.

Brandon Liu: It's one window at a time.

Brandon Liu: Are you able to see that.

Doug Schepers: This weekend. Thank you.

Brandon Liu: Well, telling you will text rendering. Awesome. I'll get started then.

Brandon Liu: So hi, everyone. I'm Brandon, I'm going to talk about multilingual text. That doesn't sound initially like it has a lot to do with maps, but I'm going to explain more about that in just a moment.

Brandon Liu: So why text?

Brandon Liu: I know this

Brandon Liu: Topic this conference is mostly about MapML

Brandon Liu: I'm going to try to go a little bit outside of that scope for this short presentation and talk really about the essence of a map. So in my mind map has geometry

Brandon Liu: In some coordinate system, but it also has textual properties. This might be a data associated with map features. It might be a map labels even.

Brandon Liu: So even if things like putting labels onto maps are outside the scope of MapML, text is so essential to what a map is that is worthy of forward thinking

Brandon Liu: And you might think about this like if you have a vector data set and you want to render it in the browser, you have to show the texts in some way, whether that's canvas or SVG or some or some fashion.

Brandon Liu: And then why do I care about this? A little bit about me.

Brandon Liu: I work mainly with OSM

Brandon Liu: Right now my projects are mainly focused on East Asia, which is going to be relevant to this talk. I'm building a new web API called Protomaps. It uses the OpenStreetMap data set.

Brandon Liu: One interesting thing about OSM. It has a wealth of multilingual content. So it started in the UK in the 2000s, but it's now a truly global project.

Brandon Liu: And I also want to say for this short presentation, it's going to have a very narrow focus on Han or Chinese script.

Brandon Liu: Which is only one part of global text. So I'm not going to get into, you know, text that goes right to left or South Asian scripts, for example. Now that's a huge topic, but I'm only going to focus on one very narrow thing.

Brandon Liu: So sort of following the MapML proposed markup for data sets. I wanted to use this as sort of the illustrating example.

Brandon Liu: Which is a data set that has two features to point features. One of them is Hong Kong, and one of them is Minato which is a special municipality in Tokyo.

Brandon Liu: These are just two point features and you can see they have like a lat long or long lat they have some properties, which is the name in the native script and the population as a number

Brandon Liu: So this is like a pretty basic data set, you know, just as simple as it can get

Brandon Liu: And how might it look on a map. So I just made, you know, sort of these absolutely position divs on an HTML page.

Brandon Liu: That puts you know these place names and data onto the map. And even if you don't read Chine se or Japanese. You might notice something interesting about this map, which is that these two characters are very similar. So the second character in Hong Kong and the first character here.

Brandon Liu: And the interesting thing about this is, is that these are actually the same Unicode code point

Brandon Liu: So the design of Unicode is such that

Brandon Liu: There's a range of character is called the CJK Chinese, Japanese, and Korean unified ideographs and these are glyphs or not really glyphs, but these are characters that were that were unified between the different languages.

Brandon Liu: So there's no way in the data set to actually know that one of them is,

Brandon Liu: It should be rather than the Chinese style and the other one should be under the like in the Japanese style. On the left here, you can see that there is a slight difference between these two characters.

Brandon Liu: And these aren't really cherry picked like this. These variations are quite pervasive, especially in geographic data where certain components of characters

Brandon Liu: Have different conventions and how they're written and Unicode was designed to be legible to users where if you see a variant that is from a different region

Brandon Liu: It should make sense, but it is not really how it's written in that locale. And the other thing I want to say is that place names are proper nouns. And people might be more sensitive to how these are rendered than just body texts on the web.

Brandon Liu: And my main central point in this presentation is to push this idea that maps are inherently multilingual, they're not edge cases. Like I'm I think of documents on the web as being multilingual in some cases like for

Brandon Liu: you know, language education or for travel. But I think the special thing about maps is multilingual text is inherent to any map that you know goes beyond just one national boundary of, for example,

Brandon Liu: So web standards have a lot of things to say about multilingual content.

Brandon Liu: There's a link in this article or there's a link in this presentation to this article that's 'why use the language attribute?' So in HTML text

Brandon Liu: You can add a lang attribute which has it BCP 47 language tag to, you know, the top of the DOM, or even to any element within the DOM.

Brandon Liu: So you can have an individual span or div of text and that has a language attribute that will control how that text is rendered

Brandon Liu: So there's a very powerful solution that HTML already offers, which is to have the element level lang attributes and this is this kind of localization for text is supported directly by markup.

Brandon Liu: And also language attributes are needed for accessibility. If you wanted to have a screen reader, for example, that would pronounce text in a language. You need to know or have some tag about what spoken language.

Brandon Liu: Is associated with that text. This is especially important for Chinese, Japanese, and Korean

Brandon Liu: So overall, there is this sort of tension between the document view of the world, like HTML where documents have a language time versus maps, which is sort of a wild west of different standards or different libraries and you can see on the web, some

Brandon Liu: Some map services they have only one version for the entire world.

Brandon Liu: And if they're rendered on the client side they might still display the local name of a place. And I think that's sort of like a good target

Brandon Liu: For globalization, like if you have a map service in Japan, for example that shows that says Tokyo Bay, like Google Maps here, you still have the native language on the map, even for English speakers or

Brandon Liu: Or users of the website that are using English. And I think that's like sort of a good convention that we have.

Brandon Liu: So what's the state of these localization issues on web maps right now.

Brandon Liu: Firstly, do graphics elements in HTML like SVG or Canvas support element level language tagging.

Brandon Liu: How about web maps in general, if I go to, you know, like a Leaflet Web Map or a MapBox GL or a vector map are these language issues solved sufficiently. And how does this relate to web standards.

Brandon Liu: For SVG.

Brandon Liu: I sort of recreated that same HTML map with an SVG elements and you can see here that Safari, which I'm using right now does not actually handle this.

Brandon Liu: So you can see that these two characters are rendered the exact same way for different languages.

Brandon Liu: You can see the code on the top here. It's to text elements and actually the only major browser to support element level language rendering is Firefox. So Safari, Chrome and edge on they just, you know, they default to

Brandon Liu: One language or the other.

Brandon Liu: Canvas, for example, doesn't really have any localization features.

Brandon Liu: There's no way to specify a language when you are saying this, this run of text

Brandon Liu: In canvas is global, you know, there's sort of this global font property and you don't have any control over the language, there is some proposals on enhancements to the canvas standards to make this work.

Brandon Liu: How about server rendered maps like if you're using that MapML and you wanted to bring in a raster tiles layer, sort of like you would use Leaflet for right now.

Brandon Liu: It's sort of someone else's problem on the server side.

Brandon Liu: There.

Brandon Liu: Most common is to use a library like Mapnik to render maps and even Mapnik right now does not have great support for these locale variants, this is something I'm actively working on, for example, OpenStreetMap. The main

Brandon Liu: Like main tile set called OSM-carto

Brandon Liu: Sort of defaults to Japanese variants for Chinese place names, which is not ideal, something that can be improved.

Brandon Liu: But how about client rendered maps? So client, like most state of the art

Brandon Liu: Map vendors that are done in Web GL day sort of skip this problem completely by shipping their own stack.

Brandon Liu: They Signed Distance Fields which are really good for performance that can be scaled infinitely, rotated.

Brandon Liu: But this approach has very little in common with web standards and it doesn't really reach parity for some scripts such a South Asian scripts

Brandon Liu: These map render is don't really do a great job. The visual fidelity has some trade offs. If you're rendering complex character is like Chinese characters.

Brandon Liu: So I think that web standards have a lot of potential to improve the state of the art.

Brandon Liu: And you can see this in some hybrid app libraries. The one I'm focused mainly on right now is called Tangram, as it was a map sent project and now is by Linux Foundation, but it uses web standard text it renders text to Canvas first move that to the GPU and shows them on the map.

Brandon Liu: There's some performance trade offs here. You can't resize text, and I know OpenLayers it's a similar design. I'm working on a new library called Protomaps 2D, which is vector rendering for Leaflet.

Brandon Liu: In all these cases Offscreen Canvas would be important to make these faster.

Brandon Liu: As an aside, HTML video which we've talked about as sort of analog for making maps work well on the web.

Brandon Liu: Has an accompanying standard called WebVTT for subtitles.

Brandon Liu: Subtitles are exactly this, this problem, which is how to present texts on the web. And you can see here, I just have a video in this presentation.

Brandon Liu: And I put in these characters one rendered in, attempted to be better than Chinese one in Japanese style and it doesn't really handle that.

Brandon Liu: This does, however, working Firefox. So WebVTT has explicit element called Cue language spans to mark up different languages inside of the subtitles and that is implemented inconsistently across browsers, but it is part of that markup standard

Brandon Liu: I'm running out of time.

Brandon Liu: In conclusion, my main point is that multi-language or multi-script maps should not be treated as edge cases, we should think about multilingual out of the box for for for all map standards on the web.

Brandon Liu: text documents on the web with HTML have a good solution right now element level languages. This has potential to improve the state of the art for web maps

Brandon Liu: Graphical standards or anything that is responsible for a presentation to the user, whether that's SVG, Canvas video or a bad element should have those capabilities as well.

Brandon Liu: So you can find me via email or Twitter Brandon@protomaps.com or bdon on Twitter, that's all I have. Thank you.

Doug Schepers: Fantastic.

Doug Schepers: Thank you so much, Brandon.

Doug Schepers: Really a complex issue dealing with languages, especially when when Unicode sorta folded them all into one block.

Doug Schepers: Maybe that was a mistake.

Doug Schepers: We do have a quick question. How, how can we support the same label but multiple languages and offer the choice. I assume that the question is to offer the choice to the user to to to pick one of the labels.

Brandon Liu: I think that would require mapping libraries to have some notion of user language or it would need to be inferred from the user agent, but then that gets into very tricky issues, like for example

Brandon Liu: One common feature is for map labels to be sort of Romanized are transliterated into Latin characters for non Latin scripts and those would be common among different

Brandon Liu: Sort of Latin using languages. So you might need to have some kind of tree or fallback language that says if I'm browsing a map

Brandon Liu: In France that has an English alternative label set. Should I show the English one instead of French one if I don't have French, for example? And I think he gets into a very tricky subset of questions that maybe web standards is not prepared to have a complete solution.

Doug Schepers: Excellent. Thank you so much. That's very thoughtful answer.

Doug Schepers: And with that, it is time now to move on to our next presentation.

Doug Schepers: Thank you once again, Brandon. Excellent. Well done. So next we have Thijs Brentjens

Doug Schepers: He is a geospatial Software Engineer. He's from the Netherlands, he's specialized in open standards from the geospatial domain,

Doug Schepers: Develops applications based on those standards for Genova he has been active for several years and developing national profiles, international standards has been contributing to the development of the Inspire, which is a European infrastructure for spatial information

Doug Schepers: In the Netherlands and internationally. He's also active in the field of web accessibility for the geospatial domain and for and usability, and his presentation today is entitled

Doug Schepers: Excuse me, fuzzy geolocation Thijs. Do you want to take it away. Yeah.

Thijs Brentjens (Geonovum, NL): Thank you, Doug.

Thijs Brentjens (Geonovum, NL): thanks all for this opportunity. I'll

Thijs Brentjens (Geonovum, NL): Try to share my screen now.

Let me see where my mouse is

Thijs Brentjens (Geonovum, NL): Please let me know if you're not able to see this.

Doug Schepers: Looks great.

Doug Schepers: looks right. Okay.

Doug Schepers: Oh my zoom meeting itself is not

That

Thijs Brentjens (Geonovum, NL): Okay. Just one moment please.

Thijs Brentjens (Geonovum, NL): I have a list of participants participants in my screen just in front of my slides so sorry for that.

Thijs Brentjens (Geonovum, NL): Need to close this down. Okay, there we are.

Thijs Brentjens (Geonovum, NL): Yes, thanks.

Thijs Brentjens (Geonovum, NL): Thanks for this opportunity. I'm going to talk about fuzzy geolocation and

Thijs Brentjens (Geonovum, NL): I hope this concept will be clear through my sheets.

Thijs Brentjens (Geonovum, NL): But first, before. I'm going to talk about this how we are going to do this in the digital age. I'd like to

Thijs Brentjens (Geonovum, NL): Give you a thought.

Thijs Brentjens (Geonovum, NL): In the age of analog maps.

Thijs Brentjens (Geonovum, NL): We were, a user of a map was let's say he was alone, he or she was alone in looking at the map. And who else than this user knew exactly what the user was looking for on a map.

Thijs Brentjens (Geonovum, NL): And I think you can imagine now in this new digital age for maps and online resources, a lot of logging or tracking, tracing can be done

Thijs Brentjens (Geonovum, NL): Via user or what the user is doing so.

Thijs Brentjens (Geonovum, NL): The context for this concept of fuzzy geolocation, is that we have found out that the digital applications use geolocation more and more. It's very valuable.

Thijs Brentjens (Geonovum, NL): Especially with with mobile applications, your location is one of the main, let's say, characteristics sometimes for your personal environment. If you're looking at some website or applications and

Thijs Brentjens (Geonovum, NL): But there. There may be there are many use cases where your geolocation, your personal location

Thijs Brentjens (Geonovum, NL): May also be

Thijs Brentjens (Geonovum, NL): It may not be that you wish that it is shared. For example, you want to use a Web Map and navigate to a doctor, you don't want to use your navigation system because you don't want some tech company to trace you

Thijs Brentjens (Geonovum, NL): Or another one.

Thijs Brentjens (Geonovum, NL): A police officers investigation, is investigating some area.

Thijs Brentjens (Geonovum, NL): You don't want to that, that this let's say extra attention is somehow locked somewhere.

Thijs Brentjens (Geonovum, NL): Because it might be a security risk at some point or might may compromise privacy and it may sound a bit far fetched, but in the Netherlands, we have this we have had a very big debate on

Thijs Brentjens (Geonovum, NL): COVID-19 Tracing apps and also that the geolocation was not allowed to be part of it because of fear of people that their personal geolocation would be stored somewhere on servers owned by the government. So even this this let's say this privacy awareness that that many users have nowadays.

Thijs Brentjens (Geonovum, NL): It puts us for an extra assignment. We have to do better in communicating our geolocation. So yes, I think we can do better. We should just not send

Thijs Brentjens (Geonovum, NL): An exact geo location or area of interest to all kinds of online services, just like we have, for example, a privacy mode for

Thijs Brentjens (Geonovum, NL): browser tabs or do not track me kind of things. And now it's very, a binary you either provide your geolocation or you don't, and but still if you are using online data services, your, your, the area you are interested in is still communicated over

Thijs Brentjens (Geonovum, NL): To services so

Thijs Brentjens (Geonovum, NL): I think, and this is an idea we have in within Geonovum

Thijs Brentjens (Geonovum, NL): Originating from this COVID-19 discussion as well.

Thijs Brentjens (Geonovum, NL): We should do better. And the thing is, how can we do it. And I'm now going to present a sample. An example of an interaction pattern how we could maybe improve this, but I have a very either. I'd like to challenge you in sharing other ideas as well.

Thijs Brentjens (Geonovum, NL): So this is concept of fuzzy geolocation. We have been talking now in Geonovum.

Thijs Brentjens (Geonovum, NL): For example, as a user, I'd like to have a map around this specific location you see here.

Thijs Brentjens (Geonovum, NL): Very low, around my house I

Thijs Brentjens (Geonovum, NL): Currently, that this location is directly sent to some

Thijs Brentjens (Geonovum, NL): To some online service. I'm getting a notice here that my internet connection is unstable is am I still

It's still

Badita Florin: It's

Doug Schepers: You look and sound fine.

Amelia Bellamy-Royds: The audio is breaking up a little so if you have any other apps in the background that, closing them sometimes helps.

Thijs Brentjens (Geonovum, NL): So there's no there shouldn't be anything

Brian Kardell: Stopping your

Thijs Brentjens (Geonovum, NL): Problem is that my children are looking a movie now but

Thijs Brentjens (Geonovum, NL): Sorry for that.

Brian Kardell: Maybe, maybe.

Doug Schepers: Twice. Maybe you can stop your video.

Yeah.

But otherwise, just go ahead. Ah.

OK.

Thijs Brentjens (Geonovum, NL): I hope my slides are skewed are cleared and okay, what we can do, instead of sending the the area.

Thijs Brentjens (Geonovum, NL): Of interest directly, we cann also

Thijs Brentjens (Geonovum, NL): Change maybe the center of the map or enlarge the area or add random other areas. Before we engage other online services and use this kind of this kind of pattern to retrieve information from from APIs and then with some post processing, go back to the end user and

Thijs Brentjens (Geonovum, NL): filter out only the relevant part for the end user.

Thijs Brentjens (Geonovum, NL): It puts a burden, a bit more on some APIs, on our services. So we realized that, but as a thought that this might help in let's say we're putting more privacy, security or

Thijs Brentjens (Geonovum, NL): Or at least not compromise privacy that much and

Thijs Brentjens (Geonovum, NL): So this, this fuzzy, this fuzziness, it can be added by we think now into two points, for example by a third party, a broker, that adds all kinds of

Thijs Brentjens (Geonovum, NL): Smart algorithms or smart ways to add fuzziness and do all communication with all my services and it can also a broker can also provide additional services, for example, cache other map resources, add random requests, or maybe fake users

Thijs Brentjens (Geonovum, NL): To to not make clear where you are at that point.

Thijs Brentjens (Geonovum, NL): Another approach might be that the mapping clients or maybe user agents or maybe in browsers themselves. There may be smarter ways of preparing requests before you engage online services.

Thijs Brentjens (Geonovum, NL): So these are some ideas we have now. And I'd like to conclude this with with an invitation to collaborate on this idea. I know this this community I'm presenting for now is quite diverse

Thijs Brentjens (Geonovum, NL): And I hope that that many of you have ideas how we can

Thijs Brentjens (Geonovum, NL): Help or improve privacy and security for for these kind of geospatial applications.

Thijs Brentjens (Geonovum, NL): Our organization will create a proof of concept and we will share all the resources, I will put them on Discourse as well put pointers to them.

Thijs Brentjens (Geonovum, NL): We will provide some OGC APIs if you need them and you want to try some things for ourselves but but the main thing is I'd like to ask you to share your ideas, your criticism as well and and help us in improving this idea.

Thijs Brentjens (Geonovum, NL): I'll provide you my contact details later, we are also available to help. As I said, we will provide some OGC APIs is that you can use for testing or to demo the, the concept

Thijs Brentjens (Geonovum, NL): But if you need any other help, please contact us because we think that this community might be a very nice and powerful community and we'd like to

Thijs Brentjens (Geonovum, NL): Get the, bring this further together so

Thijs Brentjens (Geonovum, NL): That's about what I'd like to talk to you about fuzzy geolocation and privacy. I hope my message came across

Thijs Brentjens (Geonovum, NL): And that it was not disturbed too much.

Thijs Brentjens (Geonovum, NL): And I hope to hear from you.

Doug Schepers: Thank you Thijs. That was a really interesting presentation that I, I didn't have. I was able to see everything. Fine. I don't think you need to worry.

Doug Schepers: This I have, this reminds me of things like Tor and other sort of obfuscation techniques that have been used in non map tech on map domains. So it seems sensible to me. Uh, let's see if there are any questions, um,

Doug Schepers: Let's see.

Doug Schepers: What is the path that you recommend to see this done, should there be an OGC geolocation privacy/fuzzy API should maybe maybe be something in W3C. See, I know the W3C tackled this

Doug Schepers: Or tackled some of the controversy here when they, when they added the Geolocation API to the browser. So how do you, what do you think that the path forward is do you think this is something goes in the browser. Do you think this is a protocol thing.

What do you think

Thijs Brentjens (Geonovum, NL): Good question, in fact, I don't know yet. I think one of the things that we need to find out what's the appropriate place or the way to tackle this. But it might not be discussion whether we should do it either in browser or using some kind of other protocol. It might be an end as well.

Thijs Brentjens (Geonovum, NL): I think for the, let's say, the maximum reach out. I think it would be best if browsers would support some kind of some kind of pattern to

Thijs Brentjens (Geonovum, NL): Do, add this fuzziness geolocation, but I can imagine that for some organizations they are looking for other security measures and they will have their own

Thijs Brentjens (Geonovum, NL): Let's say their own brokers themselves.

Doug Schepers: Hmm.

Thijs Brentjens (Geonovum, NL): Be sure that they are in control of what is sent to other services. So let's find out together. I'd say, but

Doug Schepers: Some someone else notes, that asked a question. Could it be could user agent provide this in a privacy in a private map mode. In other words, in an incognito mode, could they, they could communicate that. So maybe it doesn't.

Doug Schepers: It isn't an always on things. So it doesn't always do the but if you're doing a something like Tor, for example.

Doug Schepers: If there are enough queries. Could you actually aggregate them through a third party and sort of allocates, allocate who gets what information based on this aggregation, sort of like the multiple users doing that.

Doug Schepers: Um

Doug Schepers: I didn't friend that as a question. Do you want to answer that?

Thijs Brentjens (Geonovum, NL): I think very powerful options will be

Thijs Brentjens (Geonovum, NL): If we use

Thijs Brentjens (Geonovum, NL): Let's say broker somehow

Thijs Brentjens (Geonovum, NL): Yeah, because then we can add some all kinds of additional services, we can, you can, if you do it in a user agent. There's always the trigger event coming from a user agent and if you do it using some kind of a broker. You can even add

Thijs Brentjens (Geonovum, NL): That's what I meant with fake users.

Doug Schepers: Yeah.

Doug Schepers: Yeah yeah

Thijs Brentjens (Geonovum, NL): If you are not using it, you can still interact a service or you can do caching or, you know, with all these more modern APIs and vector tiles, it's, it, it may be easier to build such a system.

Doug Schepers: That's great. That's really, really.

Thijs Brentjens (Geonovum, NL): Just a thought. It's not

Doug Schepers: Well, again, everyone, uh,

Doug Schepers: Both Thijs and Brandon ask you to reach out to them so

Doug Schepers: If this is a topic that interests you, please make sure to talk about it in our various channels for the workshop, but also reach out to them directly. And we'll

Doug Schepers: Hopefully some good things will happen from from the presentations, both really great presentations. Thank you so much. And I'm going to have the pleasure of joining you,

Doug Schepers: Having you join me again. We're going to start the panel now.

Doug Schepers: So the panel today is called

Doug Schepers: World Wide Web Maps: challenges in the global context. And I'm going to reintroduce

Doug Schepers: Brandon and Thijs. And there's two other participants as well Siva and Nicolas and so

Doug Schepers: Let's get started right now if that's all right.

Doug Schepers: So,

Doug Schepers: Let's start with Thijs, Thijs, you're already here. Again, Thijs is a geospatial software engineer from the Netherlands, he specialized in open standards and the geospatial domain.

Doug Schepers: And developing applications based on the standards for Geonovum. He's been active for several years in developing

Doug Schepers: National profiles of international standards and he's been contributing to the development of Inspire, which is the European infrastructure for spatial information in the Netherlands and internationally.

Doug Schepers: He's also active in the fields of web accessibility and usability in the geospatial domain. So Thijs you want to give us

Doug Schepers: Any additional words you seem to be frozen.

Thijs Brentjens: Frozen now?

Doug Schepers: Nope.

Doug Schepers: You're unfrozen now, go ahead

Thijs Brentjens (Geonovum, NL): Oh, okay. Oh, additional words.

That's my video, maybe it's better

Doug Schepers: That's better.

Doug Schepers: Thijs, Do you have any other anything else to say about what you're doing.

Thijs Brentjens (Geonovum, NL): Oh, no.

Thijs Brentjens (Geonovum, NL): No, I'm not saying nothing else to add, for now. No.

Doug Schepers: Okay. Great. Thanks. Okay.

Doug Schepers: So to reintroduce Brandon

Doug Schepers: Brandon is the creator of Protomaps, which is an internationalization focus system for maps on the web.

Doug Schepers: He's been working on a map rendering and Data Tools related to the OpenStreetMap projects, since 2013. He also created

Doug Schepers: That's 80s.nyc, a web map viewer for historical street views of New York and Brandon you want to say anything more about what you're working on right now.

Brandon Liu: I don't have anything to add now, thanks.

Doug Schepers: Okay. Wonderful. Okay, next we have Siva Pidaparthi, Siva is a software developer working at ESRI with a focus on mapping visualization building desktop applications and make mapping services on the server.

Doug Schepers: He works with design and development, OGC related mapping services in desktop clients, REST based services and clients and web maps stored as documents online, tools by various platforms.

Doug Schepers: Siva, can you say hi.

Siva: Hey,

Siva: Hi everybody. Can you hear me.

Doug Schepers: Yep, we can hear you fine. Good.

Doug Schepers: Thanks. I was just told that my internet connection is unstable if I drop off. Y'all know the questions so

Doug Schepers: And Brent and I also sent them to

Doug Schepers: Peter Rushforth and

Doug Schepers: Hopefully if if something happens to my connection. Peter can can step up.

Doug Schepers: And finally, we have Nicolas Palomino, Nicolas is relatively new to mapping,

Doug Schepers: He's more focused on the subsystems underlying the development of web maps and the utility for the industrial and for industrial uses like

Doug Schepers: Big data manipulation and observation, advanced analytics and AI integration and other upcoming telecommunications technologies for planetary observation and beyond.

Doug Schepers: Nicolas. Do you want to say hi.

Doug Schepers: Yeah.

Nicolas: Hello.

Okay.

Doug Schepers: All right. Wonderful. Um, hey y'all.

Doug Schepers: Excellent. Let's go ahead and get started.

Doug Schepers: The first question we have is,

Doug Schepers: OGC and W3C have spatial data on the web, best practices, you know, OGC is very actively working on new API specifications. It could facilitate better publication and easier use of geospatial data.

Doug Schepers: But that's the theory. How do you think we put this in practice on active projects and y'all can just jump in, everybody's free to answer the question.

Doug Schepers: Do we want to start with maybe a

Doug Schepers: Thijs

Thijs Brentjens (Geonovum, NL): Yeah, well,

Thijs Brentjens (Geonovum, NL): I think this is an interesting one because on the one end you say these APIs are quite new and

Thijs Brentjens (Geonovum, NL): There might be large interest, but what we see currently in at least in Netherlands says that there's not that much interest in really implementing them because of legacy constraints.

Thijs Brentjens (Geonovum, NL): One driver could have been that on the European level, we have a law prescribing, what kind of technology to use to exchange information between countries, and I don't know if this is solutions, but this might be

Thijs Brentjens (Geonovum, NL): I think one of the aspects, is that too, especially for governmental organizations, we might need stronger policy on using APIs.

Thijs Brentjens (Geonovum, NL): Knowledge that I think there are many challenges there but that's one of the things I'd like to propose and of course doing experiments in live environments. But that requires organizations. Okay, of course, are set up.

Doug Schepers: Siva, Nicolas, Brandon, any thoughts.

Siva: I'd like to pass.

Doug Schepers: Okay, Nicolas?

Nicolas: I'll pass on this one too

Doug Schepers: Okay, great. Brandon, you have any thoughts on this.

Brandon Liu: Yeah.

Brandon Liu: I think one interesting thing about sort of spatial especially for open source spatial is that that I know the landscape, really, it's not that large like, a lot of sort of developers are working with PostGIS,

Brandon Liu: And to have or fun sort of a reference implementation or a driver for some of these major special projects, things like PostGIS that and QGIS or yeah um and also doodle.

Brandon Liu: I think is having a good implementation that makes it into, you know, like a release has a big impact.

Brandon Liu: So I think like, it's sort of an advantage that it's not like JavaScript frameworks, where you know there's 101, you know there's a new JavaScript framework coming out every day.

Brandon Liu: I think a lot of this sort of open source spatial world is quite stable. So having a reference implementation in those is a pretty reasonable target. Okay, great. Yeah.

Doug Schepers: That makes a lot of sense. [alarm rings] Oops. Stop.

Doug Schepers: Okay.

Doug Schepers: Apologies. I'm just timing you

Doug Schepers: And my clock went off and you had a perfect timing.

Doug Schepers: Okay. So the second question I have is, there are many localization features of maps that would benefit from browser support.

Doug Schepers: Some examples are the ability to produce place names and the writing system that the user can use as we saw earlier and Brandon's presentation, designing or authoring a multilingual map based on the locale.

Doug Schepers: Handling dynamic formatting of numeric or time related data and other interesting cartographic practices from around the world that aren't yet widespread in digital mapmaking like vertical text.

Doug Schepers: Which is supported in some aspects in in the web. But how often is it using web mapping. So what should web browsers and web standards do to provide solutions. I'd like to start with Siva here.

Doug Schepers: Siva, any thoughts.

Siva: Can you hear, can you hear me. Yeah.

Siva: Yeah, sorry. Yeah, I like the Brandon's presentation on this topic.

Siva: The only additional thing I wanted to talk about in that respect is if I as an author want to support multiple languages within the same map.

Siva: Then I should be able to advertise or like, you know, provide the metadata of what the languages are that this particular map supports that way.

Siva: The browsers will allow the users to pick which language to use. For example, instead of just locking to one specific language that the browser is pointing to.

Siva: So yeah, that those were some of the thoughts I have. I always deal with the dynamic, dynamic rendering or like the server side rendering aspect of it. But I think for WMTS. For example, you could potentially use this tile, for example, for the language.

Siva: But do you will have to come up with some kind of a formalization of this language feature which in the metadata for the WMTS, for example.

Siva: Then you'll be able to use tile or other template parameters for language. For example, where you could make a given map multilingual

Dough Schepers: Hmm.

Doug Schepers: Yeah, that makes a lot of sense. Nicolas, do you have anything to say on this one.

Doug Schepers: If you do, you're muted, if not. Let's move on to

Doug Schepers: Brandon

Brandon Liu: Are you able to hear me.

Brandon Liu: Yes. Okay, cool. Um, some thoughts on maps and languages.

Brandon Liu: I think one thing you see common on the on web maps is I think I mentioned this earlier but transliteration of place names. For example, if a place name isn't an online script, then the backend might provide

Brandon Liu: Yeah, the backend might provide a Latin transliteration which should be able to be served to all users that use Latin scripts.

Brandon Liu: Now, like, in that case, that's kind of open ended. If you look at how BCP 47 language tags are structured. You wouldn't want to specify every single, you know, German, French

Brandon Liu: English, all those but there might need to be some intermediate sort of like scripts tag that defines certain languages as a lot like as using certain writing systems.

Brandon Liu: Like I haven't thought about this a lot, and there might be some fatal flaws to this approach, but I think that would get you part of the way there.

Brandon Liu: You know, in terms of being able to show maps to users in different locales. Now how much that that interacts with web standards, I think, is

Brandon Liu: Is a tricky question because I think for something that's for something to become a web standard, it's not good to give like a half-baked internationalisation solution, like it's not good if

Brandon Liu: If the internationalization solution is just minimum viable product that only works for languages like that. That only works for left to right, languages, for example.

Brandon Liu: Right, so I think like

Brandon Liu: There needs to be a lot of care in pushing something as a standard versus having a low level set of tools that can be used to accomplish something

Brandon Liu: And I think that's like one of the overall tensions between talking about you know Map ML versus here's a bunch of JavaScript do something with it.

Doug Schepers: Sure.

Brandon Liu: So I think that is

Brandon Liu: I don't really have

Brandon Liu: I guess the knowledge and know what the right approaches here.

Brandon Liu: The second thing I want to talk about that I mentioned is

Brandon Liu: Things like vertical text that's something I added to the question list.

Brandon Liu: It's something that I really like. Or it's a topic I'm interested in, and I think the browsers

Brandon Liu: Have a lot of good progress in making that work well on the web, even though it's not used.

Brandon Liu: Like for example for CJK, it's common for for print typesettings to use the vertical text on the web, sort of the status quo is for text to always be horizontal, it would be nice to have that as something that's well supported and web maps.

Brandon Liu: For example, if you look at print maps that are published in Chinese for features that are mostly a vertical from the perspective of, you know, the viewer.

Brandon Liu: They will label those vertically and that's like a very common practice in print maps, but on the web, there's only a couple of rendering libraries that support that.

Brandon Liu: So I'm curious if there's some way that

Brandon Liu: The things that have been built for

Brandon Liu: Web browsers already can influence broader cartographic possibility

Brandon Liu: For web maps.

Doug Schepers: That's, that's a definite definite that's definitely a

Doug Schepers: An area where we need to look at what the standards are already doing and what browsers already doing and have that inform what we're doing with maps

Brandon Liu: It's such a deep rabbit hole because a lot of web maps also need text on curved paths, and that's something that's

Brandon Liu: That's something that people want for SVG, for example, I'm not sure what the current status on curve text is

Doug Schepers: Yeah, I can tell you that curve text does work for SVG. So bringing that into

Doug Schepers: And that works across browsers. So bringing that into it should

Doug Schepers: Should be possible. I'm going to ask

Doug Schepers: Thijs if he has anything to jump in here.

Thijs Brentjens (Geonovum, NL): Nothing to add.

Doug Schepers: No. Okay. Um,

Doug Schepers: I'd love to go in in further, but we also have more questions, um, this is a fertile topic for conversation.

Doug Schepers: So the, the next question. Thank you all for for those thoughtful answers. What are the challenges for security and privacy for personal geospatial data in international context Thijs, can you start with this one.

Thijs Brentjens (Geonovum, NL): Yeah. Well, for those who heard my presentation before I think we, the main challenge in the end is that we need to

Thijs Brentjens (Geonovum, NL): Get in between the ears in our heads that that privacy and security may may become, you know all the benefits we have to geospatial data. They may also have a, we have to pay a price for it with privacy and security.

Thijs Brentjens (Geonovum, NL): So that, that's maybe the main challenge and then it comes down to, how can we

Thijs Brentjens (Geonovum, NL): act upon it. So I'd say propose experiments, but also share ideas and maybe like you have if you do a security tests in for web applications, you have this list of OWASP.

Thijs Brentjens (Geonovum, NL): OWASP? I'm not sure if I pronounced correctly, but there's just checklists, you need to check whether you are, you comply to them or not. It gives them new ideas, what you can do for security and privacy. We don't have that as far as I know, for geospatial applications.

Doug Schepers: Right

Thijs Brentjens (Geonovum, NL): And I think that that's one of the things that in an international context, we might try to

Thijs Brentjens (Geonovum, NL): Work on create such a list.

Doug Schepers: Right.

Thijs Brentjens (Geonovum, NL): And then of course we have the technology implementation, etc. But it should also start with creating all those kinds of risks and identifying them and share them and help each other out with that. Get in the awareness, let's say,

Doug Schepers: Absolutely. Siva, do you have anything to add here.

Siva: No, I don't have nothing much.

Nicolas?

Doug Schepers: Okay, Nicolas, we're not hearing you.

Doug Schepers: If you,

Doug Schepers: Okay and Brandon, do you have anything to add here.

Doug Schepers: Hopefully we still have Nicolas online.

Brandon Liu: Nope.

Doug Schepers: Okay, great.

Brandon Liu: Um,

Doug Schepers: Yeah, this is definitely a topic with, internationalization touches on law and

Doug Schepers: Ethics, privacy, security, all of these things are multifaceted international issues, um,

Doug Schepers: So,

Doug Schepers: Next question

Doug Schepers: We have here is Web Mercator

Doug Schepers: Is a defacto standard for the web. But as well and flaws, for example, like Pacific centered mapmaking. What's the right balance for web standards and making these choices for users and developers? Who wants to start off here.

Doug Schepers: Siva, Thijs, Brandon, Nicolas

Brandon Liu: I'll start.

Doug Schepers: Sure. Thank you.

Brandon Liu: Um, yeah, I think maybe it's a little bit of a gut reaction, but I think to sort of

Brandon Liu: Sort of. Sort of privilege Web Mercator as

Brandon Liu: You know, the first class frame of reference for web maps, I think that might get some pushback from parts of the world.

Brandon Liu: Especially like, you know, just like, because I think the truth is, for a lot of like map presentation layer is they will say,

Brandon Liu: If you have features that cross the integrity and you need to pre process them so that you know like the those features they only go to, you know, from whatever, to 180 and from -180 to whatever

Brandon Liu: And I think that it's it's a little bit tough because I feel like the number of applications that are affected by this issue is large

Brandon Liu: And the solutions are really non trivial because the solutions is essentially like you might author your GeoJSON to have coordinates that cross the entire meridian.

Brandon Liu: But then in order to make it work correctly, you need to bring it alive right like Turf.js that you know slices up your future is, for example, and that's already like approaching the level of developer sophistication that is that is not as simple as just putting some markup on a map.

Brandon Liu: So I think the entire issue of like of map coordinates, it does demand and inherent sophistication like mathematical sophistication.

Brandon Liu: That is, might be a hard sell for this. Imagine the audience of, you know, every web developer in the world can author, you know, spatial content.

Brandon Liu: I don't have a good answer. It might just mean that we need to

Brandon Liu: Like

Brandon Liu: You know, suggest a set of libraries to do spatial operations in the browser.

Brandon Liu: I'm not sure if anyone else has suggestions.

Brandon Liu: On this issue of map projections and you know different centers of projections. Like if you wanted to have a Pacific center Mercator maybe just adding that that other option might be a possible solution. I'm curious what other people have to say.

Doug Schepers: I think MapML tries to address this by actually having some projections built in. So that's, that's some ground for thought. Siva, Thijs, anybody else. By the way, folks, I'm, I apologize. Nicolas is

Doug Schepers: Apparently, having some sound, sound issues, unfortunately. So if he has an answer. He's just going to type it to me and and I'll read it out. But, I apologize, Nicolas, that this isn't working for you.

Doug Schepers: So Thijs, Siva, do you have any thoughts about the Web Mercator?

Thijs Brentjens (Geonovum, NL): Thijs here. I think I really like this topic as as a discussion topic because it's very hard one to crack this nut.

Thijs Brentjens (Geonovum, NL): And

Thijs Brentjens (Geonovum, NL): What we see now is that that many people and

Thijs Brentjens (Geonovum, NL): children growing up with Web Mercator they think that Greenland is

Thijs Brentjens (Geonovum, NL): Maybe as large as Africa is is all content know so it might distort even the image we have of

Thijs Brentjens (Geonovum, NL): Countries, or whatever. So it's, it's, I think it's a very important topic, and at the same point Just as Brandon pointed out, it's very hard to explain to others, not in the geospatial, not working in as a geospatial, with geospatial knowledge, projections are hard and

Thijs Brentjens (Geonovum, NL): Especially if all kinds of libraries support mainly a Web Mercator, if that's the Go To projection

Thijs Brentjens (Geonovum, NL): And you need to finish off a project, very quickly. That's what you do all kinds of resources are available in that projection only

Thijs Brentjens (Geonovum, NL): So I think there's a major challenge and can we find a reasonable alternative for some use cases somehow and and are we able to get all kind of software working. That easy, that we can use these

Thijs Brentjens (Geonovum, NL): Alternatives as easy as we cannot

Thijs Brentjens (Geonovum, NL): I don't have a real answer to that, but I think it's a very important topic with more impact than just let's say a mathematical discussion.

Doug Schepers: Yeah, absolutely. Definitely goes, I mean there's there's definitely goes to a social justice and international

Doug Schepers: And inclusiveness issue so and if anything, hopefully what maps are, maps will do is bring people together around the world.

Doug Schepers: So we have one more question. We prepared.

Doug Schepers: I don't see anything from Nicolas here, is Siva, did you, you did you have something to say Siva?

Siva: Nothing much. The only thing I would say about that is, like, like, you know, when we are looking at new standards, like, you know, we should also be thinking about other coordinate different systems, not just

Siva: Like you knowWweb Mercator like WGS84 or whatever, right, like, you know, which are good for the global data, but for local they are not very good. So I think it is just a mindful kind of a thing.

Siva: Where you know we should just take care of

Siva: Additional coordinare reference systems into the account. Yeah.

Doug Schepers: Yeah, I really liked the idea of

Doug Schepers: Perhaps promoting some other non Mercator projection that that could maybe catch in the public imagination. So it could be easy for people to, not just easy for them to do, but easy for it to be top of mind for them.

Siva: Exactly that.

Doug Schepers: That could be of help. Finally, the last of the prepared questions WPC is a leader and accessibility. Like, for example, you know, the Web Content Accessibility Guidelines and accessibility is now demanded by law in several countries, but is difficult and often not taken seriously.

Doug Schepers: To apply these guidelines for mapping and geospatial data.

Doug Schepers: I'll note that we have two upcoming panels later in this workshop on accessibility, but in an international context, what do you have any thoughts on how we can make this easier.

Doug Schepers: Siva, we'll start with you.

Siva: Um, I come from a desktop world, you know, where the standards are pretty like, you know, standard, I would say, in that sense, and we comply to a lot of

Siva: The standards and we pay attention to it. We make sure every bit of UX we have works well. But I can understand how this can be complicated for a browser or browser applications which has to deal with lots of generic you know controls and implementations are elements, basically. Yeah.

Siva: That's all I have to say I don't have much expertise on the website.

Doug Schepers: Okay.

Doug Schepers: Thijs?

Thijs Brentjens (Geonovum, NL): Well,

Thijs Brentjens (Geonovum, NL): Me personally, I think this is a very important topic in you see the on W3C conferences that that the attention for accessibility is there, always there and it's not in the geospatial work and then simply this, this idea that maps are visual and it's visual only, it's

Thijs Brentjens (Geonovum, NL): Just what we do. You can't make that accessible. So we just don't do it.

Thijs Brentjens (Geonovum, NL): And I think they're there are again we maybe we should share a more ideas of what we can do to make things accessible to make maps and the information on maps accessible and it requires is also to step or maybe it will step back and think of what maps are just as a representation

Thijs Brentjens (Geonovum, NL): Of some data. And there are other ways for that they may not be the ones you prefer as a geospatial developer or they may not be as user friendly as you might think. But I think we need to

Thijs Brentjens (Geonovum, NL): discuss that more and also try to have a common libraries, Brandon pointed out in an earlier question common use libraries, we, we should try to improve accessibility in these libraries.

Doug Schepers: Right

Thijs Brentjens (Geonovum, NL): That those are things I'm thinking of. But I'm for sure other experts in this in this workshop. Are they are there a lot of interesting things to say. Yeah. On this, I think,

Thijs Brentjens (Geonovum, NL): But, but it also start with the idea breaking down the idea that we wish that maps are not easy to make accessible because I think there are options and

Doug Schepers: Okay well we're going to explore some of those options. Later on in the

Doug Schepers: Workshop.

Doug Schepers: Brandon. Do you have any thoughts or Nicolas?

Doug Schepers: If not, we have another question. Oh, Brandon, did you have something to say.

Doug Schepers: No. Okay.

Brandon Liu: Thanks.

Doug Schepers: Yeah, uh,

Doug Schepers: So we have a couple of where we have actually several questions, we only have four minutes left. How are context menus handled internationally? And I think this came in, Brandon, while you were talking, so maybe do you want to handle that first

Brandon Liu: Context menus, is it specific HTML?

Doug Schepers: I don't Know, I think it's really thinking about

Doug Schepers: I'm not sure exactly

Peter Rushforth: What I was thinking about the maps or, you know, we have a layer control and there's some, you know, you have to have internationalization considerations in providing a widget. So there's going to be, you know, like challenges involved there. So I just wanted to see what

Doug Schepers: You mean like vertical versus horizontal, Peter?

Peter Rushforth: Yeah, okay.

Brandon Liu: Right. I think the good solution is just to say anything.

That

Brandon Liu: Like, that's just an HTML sub DOM within that thing that's rendered

Brandon Liu: I mean, that's the approach that I think Leaflet takes is you can just put whatever you want inside of an element that's rendered on the DOM. And if that's if that's a spec, you know, I have no idea how hard that is to implement

Brandon Liu: Because that seems like you could get into a lot of pathological cases.

Brandon Liu: But it seems like that is the best internationalize that that's the best internationalization solution because anything that's that is capable with regular HTML can just apply within that context menu. I mean that's ideal for my perspective.

Doug Schepers: We actually have Nicolas said

Doug Schepers: I'm going to read his reply here

Doug Schepers: For question three about privacy. He says, Privacy is one of one of the most important components of the system.

Doug Schepers: He doesn't know what challenges exactly what it could bring as as as we apply as we actively apply such applications because laws differ from country to country. Another important thing, I think, is that this could be possible.

Doug Schepers: Could possibly generate a large amount of data as it turns out, this data could be a matter of national security as well. And that actually leads into another question that we had,

Doug Schepers: Which was

Doug Schepers: From Fred Esch, if we have the time, in a global challenge how do data costs and performance get factored in Siva, have you, has ESRI

Doug Schepers: Looked into this. Have you thought about this.

Siva: Um, yeah, I'm not that much on the content side of the things so I might not be able to answer this, yeah.

Doug Schepers: Okay, any of the other any of the rest of you have thoughts about that.

Thijs Brentjens (Geonovum, NL): Thank you. So I don't understand fully understand the

Thijs Brentjens (Geonovum, NL): Question or the

Doug Schepers: Thijs, I think it is. I think you kind of touched on in your presentation.

Thijs Brentjens (Geonovum, NL): Data okay the data we

Thijs Brentjens (Geonovum, NL): We may or burden.

Doug Schepers: We only have we only have one minute left. So if you can just keep it very brief.

Thijs Brentjens (Geonovum, NL): Okay. I think it's a challenge, but if you use, for example, smart cacheing systems, you might be

Thijs Brentjens (Geonovum, NL): Able to reduce load.

Thijs Brentjens (Geonovum, NL): Maybe on some other services as well.

Thijs Brentjens (Geonovum, NL): But in the end, adding all those kind of extra things will add

Thijs Brentjens (Geonovum, NL): Asks something extra, somewhere.

Doug Schepers: Right.

Thijs Brentjens (Geonovum, NL): Either in processing vector tiles, either in, you know, it will it will

Thijs Brentjens (Geonovum, NL): It will be at some cost.

Doug Schepers: Y'all thank

Doug Schepers: You so much. This has been great.

Doug Schepers: Thank y'all so much for participating in this panel. Sorry for the technical snafus, especially to Nicolas. Thank you everybody for

Doug Schepers: For attending or for watching afterwards, and I hope that all these conversations, come back around, please contact the individuals who participated in this if if you have thoughts, either in the workshop or afterwards. And thank you so much and have a wonderful day.

Brian Kardell: Thank you.

Brian Kardell: You too.

Doug Schepers: Bye. Oh.

Thanks, everybody.

Amelia Bellamy-Royds: Thanks.

Amelia Bellamy-Royds: Okay, we're sliding into one of our breakout sessions. Peter and Gethin, do you want us set that up. I think we're just going to continue using the same

Amelia Bellamy-Royds: Chat. So if you're interested in extending GeoJSON for web applications. Please stay on. We've got a couple talks on that topic.

Peter Rushforth: Over to you Gethin.

Gethin Rees: Okay, thanks very much, Peter. So welcome to the first breakout

Gethin Rees: Group, I believe, of the

Gethin Rees: Workshop.

Gethin Rees: I'm a curator for digital mapping at the British Library and

Gethin Rees: We've got a couple of presentations from people that work with cultural heritage detail now. Um, I believe that this is a valuable perspective for the workshop in a couple of ways. Um, first, um, it was really interesting to hear about

Gethin Rees: people's thoughts about Mercator projection earlier, you know, I'm being a curator interest in history of cartography.

Gethin Rees: You know, I believe the, is really interesting. How big could test that when Mercator projection is and and i think working with cartography can help us understand

Gethin Rees: Projections going forward, but also second

Gethin Rees: Is the use, we encode your heritage, we use web maps a lot to present collections for discovery and interpretation.

Gethin Rees: Now here we have developed to open standards and within our relatively small community. That's why it's a good day to outline them. So we're going to just talk about a couple of the

Gethin Rees: Couple of on the extensions to GeoJSON that we've been working within that community. And we're not suggesting that these should be added to the MapML spec

Gethin Rees: But we are interested to see, hear about by views from a broader community here related to these developments and see what the reaction of a wider audience will be on

Gethin Rees: It is a breakout group. So these are going to be quite short presentations and afterwards and we're hoping to always, just in general about the relationship between a MapML and GeoJSON and we'll be taking, suppose if the organizers can

Gethin Rees: Run this but I think in the initial instance will be taking questions and the Gitter channel. Um, I think there's

Gethin Rees: You know the number of participants is quite manageable. So if participants is meant to be a breakout group. So if it's okay with the organizers of participants did want to

Gethin Rees: Mention the Gitter channel that they had something to see perhaps you could unmute themselves and speak as well. Is that is that is that okay?

Amelia Bellamy-Royds: That makes sense. I mean, we've got 16 people on the line right now so we can probably just open this up as a chat.

Amelia Bellamy-Royds: Presentations, of course, to start it off.

Gethin Rees: Yeah, that

Gethin Rees: Says, um, yeah. So this is

Gethin Rees: A couple of short presentations on first. In cultural heritage we deal with cultural information and so nuance, uncertainty and really the humanity

Gethin Rees: Of these data not peripheral concerns. Representations of place can be at odds with positive positive is systems like coordinates. And so that's what a lot of work to focus on data modeling -

Gethin Rees: The semantic structure here offers flexibility and complexity and the ability to model flexibility and complexity. This isn't without drawbacks either so know Brian

Gethin Rees: Haberberger who's a full stack software developer at the Walter J Ong SJ Center for Digital Humanities at St Louis University, is going to talk about this topic on and his work on expressing GeoJSON as

Gethin Rees: data 1.1. Thanks, Brian.

Bryan Haberberger: Thanks, Gethin thanks for the intro. Hi everybody, I'm going to stop sharing my video and share my screen and hope that kind of helps keep things smooth. So let's get going here.

Bryan Haberberger: Can you all see my screen.

Doug Schepers: Yes.

Great.

Bryan Haberberger: So again, my name is Brian Haberberger, along with being a full stack developer at the Walter J Ong SJ Center for Digital Humanities, I am also the IIIF maps technical specification group chair or one of multiple, and what that group is doing is sort of working within

Bryan Haberberger: The framework they have set up, which is very based on JSON and JSON-LD, and allowing away for standardized coordinate assertions to sort of enter the fray.

Bryan Haberberger: So why Linked Data. I think Gethin gave a good intro about it. But essentially, the semantics allow for interrelated data sets on the web. So if I have a data set that describes people, places and things and you do too,

Bryan Haberberger: I would like to be able to pull some of your vocabulary and direct meaning and use it to express that in my data set and in that way we can sort of enhance each other's data sets and encourage each other for the the well coded data for the future in cycle.

Bryan Haberberger: And so there's Linked Data, Linked Open Data, Linked Open Usable Data. It's all essentially the same. But in settings where the sources are open sources, that's when we say linked open data and usable is always just a hopeful.

Bryan Haberberger: But we like to use that word.

Bryan Haberberger: So how does this kak with GeoJSON-LD. We're not going to talk about the GeoJSON-LD spec directly

Bryan Haberberger: Instead, what I'm going to talk about is the Linked Data vocabulary and context that have been created for it.

Bryan Haberberger: JSON-LD is a W3C specification and like we just said it recently had an update as you can figure out GeoJSON is JSON and so there has been work to make a GeoJSON-LD context that's compatible with the JSON-LD 1.0 version.

Bryan Haberberger: That's sort of what allowed GeoJSON data notes to be a part of the Linked Data system going on and all the things we use

Bryan Haberberger: So, one important thing to note about GeoJSON-LD is that nested GeoJSON coordinate arrays are incompatible with the model. I'll show you exactly what that means and what that means for functionality here in a second.

Bryan Haberberger: But sort of at a top level concept. What this means is GeoJSON-LD is unable to express polygonol shapes.

Bryan Haberberger: Not that it can't but rather that when it does that, it's not able to process it as an LD. And so applications that are

Bryan Haberberger: Specifically, trying to be LD ignore what they can't process. So that would mean all of your polygons would be ignored, which is a massive problem for geography. Yeah, I'd assume you all like to be able to use polygons.

Bryan Haberberger: So the LD 1.1 release. The most important thing that came about, about it was that it allowed for list of lists structures so that things can actually be rendered. So I'll just give you a real small demo here real quick. Hopefully if the Internet

Bryan Haberberger: Will allow it.

Bryan Haberberger: So here's the JSON-LD playground and if I come in with that data, you'll see right away it tells me

Bryan Haberberger: This is not a valid syntax. I can't do lists of lists. What that means, sort of exactly is laid out a little better

Bryan Haberberger: In the spec to tell you why they chose not to do that.

Bryan Haberberger: But as people started specifically to work with GeoJSON and GeoJSON-LD, it became clear that the list of lists structure was going to be necessary for data.

Bryan Haberberger: And so that's when the LD 1.1 spec came out and just to show you that I'm not kidding.

Bryan Haberberger: It now specifically states that lists of lists are fully supported. So what that means is we would hope if I came into the LD 1.1 playground, that if I put that data in

Bryan Haberberger: It was successfully process, which it does. So just a super fast overview of what Linked Data does. You can see in the GeoJSON use terms like properties, geometry, type and coordinates.

Bryan Haberberger: And those are all directly mapped to a vocabulary or specific definition that that allows the keys to understand exactly what they are. So you can see by geometry, I mean, what GeoJSON says about geometry.

Bryan Haberberger: And so on and so forth. And you can see here how successfully can do. I'm a list, I contain a list that has a list, and that can go on forever, but it's obvious that that is is allowed now.

Bryan Haberberger: So that's mainly what I wanted to show you here. And then of course I'm sure you want to see it draw.

Bryan Haberberger: So if we go to the GeoJSON validator with that object we just had and paste it in and test it, you'll see that it draws my shape and it's my very crude a bounding area for the Eiffel Tower.

Bryan Haberberger: So we know it's GeoJSON compatible and now we know it's only 1.1 compatible. So we sort of have a way to properly describe these data sets, using Linked Data.

Bryan Haberberger: So now I'm going to talk about another

Bryan Haberberger: Another W3C specification called Web Annotation and specifically how that connects with Web Entities. So as I talked about earlier. I work in a Digital Humanities Center, and we are more of a dev shop than a content shop. We actually don't hold a lot of content.

Bryan Haberberger: So what my use cases is I need to be able to add descriptive information to content that's owned somewhere else and still

Bryan Haberberger: Be able to use the data connected with that data, know that I'm targeting

Bryan Haberberger: Trying not to go too much into it. I think it's a lot easier if I just show sort of a pipeline for for that looks like.

Bryan Haberberger: And sorry for clicking. So let's say I know a repository, a portal, as we've talked about earlier.

Bryan Haberberger: That I can go to to look for resources, Stanford has one of those. And it says that its resources are IIF so we'll go to something recent they had, like this Black Lives Matter memorial. And if I go into it.

Bryan Haberberger: If the Internet will load with me.

Bryan Haberberger: You'll see that loads up here and it has its the images that go along with it and probably other information about it.

Bryan Haberberger: I can specifically just asked for the data object that's in the background of this

Bryan Haberberger: So if I do...

Bryan Haberberger: And I just happened to know to use this because I work with these guys, so I know how their portal works.

Bryan Haberberger: You can see the object in the background. This is very IIIF I'm not going to go into it too much, but they have context and everything to sort of describe their keys in terms as well.

Bryan Haberberger: So if I bring this manifest and I say, I would like to say I know where that manifest is at

Bryan Haberberger: I Could bring it in here and say that's the URL I wanna use. There's the object, we know that it is. And I know it's somewhere over in California. So I'm just gonna kinda, Yes, sure. Probably not there. But let's go for it.

Bryan Haberberger: So what that does is generate a Web Annotation that connects that resource to the coordinate properties. And you can see here the body of the Web Annotation is GeoJSON. And so these contexts combined mean this works as a 1.1 Web Annotation and in particular because of some dumb luck.

Bryan Haberberger: This context actually has at version 1.1 which means process this as LD 1.1 and so the GeoJSON

Bryan Haberberger: Context, which does not contain that, sort of gets it for free, just by property of how combining contexts work. So now if I go ahead and create that annotation.

Bryan Haberberger: Great. It says go see it and Leaflet.

Bryan Haberberger: So I'll get to what that is in a second. So you can see there how it just provided a target, made JSON body for it, and made them relate to each other.

Bryan Haberberger: So now what I can do is ask data sets that I know we're doing this to just supply me with all of those coordinate assertions they've made.

Bryan Haberberger: And when I do, they'll show them here on a map for me.

Bryan Haberberger: So these are just those Web Annotations that I pulled out. And here you can see I never supplied a label. I never supplied a description, but the target data had it. And so I can just resolve that target lifetime.

Bryan Haberberger: And show data about that target lifetime without ever manipulating that data directly. So if anybody changes the label. If I refresh this page we're going to see that new label.

Bryan Haberberger: And that's sort of how we realize our pipeline. We don't have the content, but other people don't have the developers or the annotation systems to describe their content. How can we all still, you know, work in that in that process.

Bryan Haberberger: And so here's what I just showed you this is this is what what it looks like. And you can see here instead of using the

Bryan Haberberger: IIIF presentation context. I use the Web Annotation context, the IIIF context contains the Web Annotation context so that I don't have to include it as a third one.

Bryan Haberberger: I'll show you just super fast in a Linked Data context how you might go about doing that.

Bryan Haberberger: Oh, that is the wrong one. I'm sorry, my fault.

Bryan Haberberger: To see here they pulled in description for an annotation collection, annotation page in an annotation and say I use their context. But as we just described about when the new internationalization problem IIIF really deals with

Bryan Haberberger: International labels and so they needed to define a way to say I can provide multiple labels of a certain language.

Bryan Haberberger: More descriptive then just the label that that web the annotation wants to use. And so how that gets realized

Bryan Haberberger: One of the things IIIF maps community group is working on is providing recipes

Bryan Haberberger: For making these kinds of assertions and so you'll see here how we actually have to make the label. It's not just label colon string. It's actually an object containing arrays of information attached to language.

Bryan Haberberger: Which is what that lead contexts will need to do so that I know as the developer now to make my labels like this so that the viewers know to grab them and show them based on the language of they're in

Bryan Haberberger: It's just sort of an example of how Linked Data tries to connect that entire pipeline and then down here. Further, like we've shown you before. Here's what it looks like.

Bryan Haberberger: The IIIF

Bryan Haberberger: API uses annotations and inside those annotations are Web Annotations. So what this is right here is an actual Web Annotation, with its own coordinates.

Bryan Haberberger: That are outlining city to sort of fuzzy locate what resources being described here. And that was sort of how we realized that pipeline. So these recipes are up and and something you can go look at I've got notes included, links included in my notes and with the slides, when we get there.

Right.

Gethin Rees: It's now quarter past so could wrap up please.

Bryan Haberberger: Yes! So that was actually the end of it. So now the, I'm trying to Gethin. So now the future of GeoJSON.

Bryan Haberberger: IIIF community group is working to take that specification and get it somewhere where it can be maintained and we can add things like that version 1.1 property to the context to make this 1.1

Bryan Haberberger: Because we think GeoJSON will continue to be used in sort of like standards being promoted in this workshop and it should continue to have definition for it on the web.

Bryan Haberberger: And that's sort of our charge right now. And I think the next piece is what Carl, the next speaker is going to talk about is extending it even further to maybe include other dimensions.

Bryan Haberberger: And then hopefully, being able to take the sort of format here as JSON and realize it as a markup language in ways to connect with like WebML.

Bryan Haberberger: So that's it. Thank you.

Gethin Rees: Okay.

Gethin Rees: Thanks. Thanks, Bryan. Um, that's

Gethin Rees: A great explanation of how on we can use these Web Annotations to make assertions about

Gethin Rees: About documents on the web on and those can take to use the predicate, those can take a variety of forms. So for example, if we're talking about a place

Gethin Rees: We can say this is either this is within on the edge of outside that place and attached to your JSON-LD. In order to do that. So the next speaker Karl Grossner,

Gethin Rees: Is going to talk about bringing

Gethin Rees: Time into GeoJSON

Gethin Rees: GeoJSON-T, adding time into GeoJSON. He's technical director of the world historical gazetteer, and he's based in the University of Pittsburgh and

Gethin Rees: In cultural heritage, we've had a lot of success with sharing data using standards and this GeoJSON-T standard is certainly something we're using at the British Library and I'm trying to push it, the British Library.

Karl Grossner: Okay. Can y'all hear me.

Bryan Haberberger: Yeah, I can hear you.

Karl Grossner: Good.

Karl Grossner: Thanks.

Karl Grossner: I'd like to make a comment first before I share my screen and slides.

Karl Grossner: I wasn't until this session.

Karl Grossner: I haven't been aware of the map markup language and the extent as an extension HTML effort, and I'm not really sure how how that new technology would handle vector data and my where I'm coming from is entirely a

Karl Grossner: HTML and JavaScript world of making web maps which I've been doing for 15 years in the context of

Karl Grossner: Historical research and so on. So let me just race through these slides, guess I'll share my screen

Karl Grossner: And

Karl Grossner: So I'm assuming that everyone here is familiar with GeoJSON. It's really quite a standard and the universe of, in the admittedly messy universe of JavaScript mapping libraries that render maps to web screens.

Karl Grossner: It's in very common use, it's more or less a defacto standard. In fact, from my perspective, for making web maps for the data that

Karl Grossner: Web maps render

Karl Grossner: GeoJSON looks something like this. At its core, it's quite simple. You have feature collections, consists of features and features can have properties which can be anything at all. Say, and and they can have geometry.

Karl Grossner: Some conditions that I encounter routinely and people in the world of cultural heritage and historical research

Karl Grossner: Much more generally that spans many disciplines

Karl Grossner: And even modern applications, admittedly, I'm much more focused on historical application.

Karl Grossner: That has some features, for some features time is absolutely an essential aspect of them that it's not the answer to where is not some location, but it's a location that time. And this is an example in a little

Karl Grossner: Pilot demo thing I built a while back, indicating Poland.

Karl Grossner: As a very, very dynamic place, it even disappeared for a while.

Karl Grossner: Other cases that I encounter would include things like this. This is a

Karl Grossner: Map of the commodity flows between Venice and many forks over a period of several hundred years rendered

Karl Grossner: In a map, the geometry of it rendered in the map and the temporal attributes rendered in this case in the histogram.

Karl Grossner: Some other sorts of cases that

Karl Grossner: Me and I and people like me encounter routinely would be something like this, a trajectory, this is a particular journey taken sometime during the fourth century.

Karl Grossner: And

Karl Grossner: And in this case, and the temporal attributes are

Karl Grossner: A great interest both overall for the fact that occurred within some hundred years span.

Karl Grossner: But also each of those points follows each other in a sequence all of these cases are not handled at all by GeoJSON in any standard way people make do, they use the properties element to

Karl Grossner: To put in attributes that they want to render dynamically, and then they have JavaScript that interprets those properties and those things in the browser.

Karl Grossner: My proposal this, now, a few years old this to include a standardized 'when' in GeoJSON, they could appear in a couple of different locations. It can be used to temporally scope, a single feature, the way you see it here, which, for example, might apply to a single feature for

Karl Grossner: For, well for anything really.

Karl Grossner: A more complex case. In the case of Poland, for example, as you might have a single feature and this geometry is a geometry collection.

Karl Grossner: Each geometry of which has its own 'when' its own temporal scoping. This is a relatively simple thing to do and and it allows for doing some oddball-ish sorts of things. I think like journeys and flows and so forth.

Karl Grossner: And the question then becomes, what should be the structure of 'when' the idea is that there be some standard structure for a 'when' element wherever it appears in the GeoJSON feature.

Karl Grossner: That software that supports GeoJSON-T would know about with know where to look for it and know and have some idea what to do with it.

Karl Grossner: At this point I'm going to point you to some links that appear in the last slide of

Karl Grossner: Of this and are available to you and I'll display them also here.

Karl Grossner: A 'when' object can include any number of time spans. So that might be interrupted time spans that are relevant to a particular feature. Could be, it can include named periods. There are

Karl Grossner: Time period gazetteers in the world at least a couple in broad use within the domain I'm in,

Karl Grossner: And sometimes that's all we can say

Karl Grossner: About time and these other elements duration follows, which is intended to handle sequences and so

Karl Grossner: This is a bonus slide. It doesn't appear in the slide deck that's been uploaded I'm adding it because

Karl Grossner: The reason for my presentation is that Gethin's group at the British Library and Gethin particularly as instigated an effort called Web Maps-T

Karl Grossner: That attempts that is attempting to develop collaboratively.

Karl Grossner: Software modules as a open software modules for maps and timelines, taken together. Because for us, as Gethin mentioned in his library contexts and collections, this is a very common use case.

Karl Grossner: Geographic data is dynamic and this needs to be rendered in various ways it could be histograms and it could be stepped

Karl Grossner: points along the timeline that sort of thing. And there are many other things that creative people will undertake that so WebMaps-T is intended to work towards a set of

Karl Grossner: modules that developers of web maps in this realm can just plug in and customize to suit their particular situation.

Karl Grossner: The goal of my talk is simply to raise the question of time. As I said at the beginning, I don't really understand how

Karl Grossner: Vector data would be handled with the map element in HTML.

Karl Grossner: And this is very much about data models. So this is all happening before it arrives at the browser, I think, I don't know. I'm here to learn what

Karl Grossner: What is intended by this group. And just to raise the point that time matters an awful lot, and not only in historical cases.

Karl Grossner: But in modern cases as well as all sorts of trajectory data, all sorts of modern, relatively modern data about crime mortality, etc.

Karl Grossner: All of those features can have very important temporal attributes and standardizing a representation in the most common format currently in use GeoJSON seems to make sense to me.

Karl Grossner: That's all I've got. Okay.

Amelia Bellamy-Royds: Oh, thank you very much Karl. I'm going to jump in.

Amelia Bellamy-Royds: Just on the point sort of your question about MapML. MapML's vector model currently is almost directly compatible with GeoJSON is just converted into a markup form.

Amelia Bellamy-Royds: Peter can jump in with more specific questions, but it's designed to be as directly compatible as possible.

Karl Grossner: Well, I look forward to investigating that

Peter Rushforth: Yeah.

Karl Grossner: And then, and then any link that would direct me to a spec or a draft spec would be useful

Bryan Haberberger: Ditto for me.

Peter Rushforth: Okay, great. Well, I'm gonna give part two of the presentation that I didn't have time for today, tomorrow as part of my breakout

Peter Rushforth: Following your guys example I'm

Peter Rushforth: Using the time most judiciously to communicate as as efficiently as I can. So I'll do

Peter Rushforth: I'll give that presentation and then we can do it like a demo or whatever. Once I've done that presentation demos almost not necessary, but always nice to click on stuff and but thank you very much, time is a, time is a challenge and

Peter Rushforth: You know we are collecting Amelia has been leading the charge on collecting use cases for maps on the web.

Peter Rushforth: That, you know, we're going to reconcile the maps for HTML specifications with that use cases

Peter Rushforth: And in an iterative fashion. So, I mean, part of the challenges to what's in what's out and what should be handled by the browser "in theory", you know I know Brian and Simon or, or, you know, like, whoa, keep the

Peter Rushforth: Keep the request down to the bare minimum, but

Peter Rushforth: What, you know and we we live in that spirit as well. So, you know, what is the minimum viable product that we can ask that serves you know the most number of people.

Peter Rushforth: And I hate to call it the least common denominator, but that's effectively what it is right, and that's not a bad thing when you're thinking about math when you're learning, learning math when you're a kid, right when you

Peter Rushforth: When you bring things to the least lowest common denominator, you're able to integrate them then, right you're able to add them up. So hopefully the analogy works that way. No great presentation. I don't want to steal your time so go in.

Bryan Haberberger: I just, it's most interesting to me because it's all I have is the features. How do I

Bryan Haberberger: reconcile that with I just had the features I want to give to you a map and that's that's literally it. How do I just retain those features and make it so that it works within that markup language.

Peter Rushforth: Yeah. Well, there is a feature element that we're proposing that basically is based on GeoJSON, you know, I mean, the thing is that GeoJSON is strictly tied to WGS84. It doesn't have any notion of scale and there are no other

Peter Rushforth: There's no styling of that stuff. It's all up to the browser. So this is like JavaScript and CSS or CSS and JavaScript on a debate.

Peter Rushforth: Right. Yeah. So I mean, what we would like to do for feature is give it a home in HTML somehow right so that one con- geometry context is the map and the and the textual content is the

Peter Rushforth: Is a 2D browsing contest or like a regular browsing context, I guess. So somehow, work on, work that out but anyhow.

Peter Rushforth: I will talk more about that tomorrow.

Karl Grossner: Oh of course libraries like Leaflet take a data stream like some GeoJSON data and generate a ton of stuff elements in the DOM that are entirely proprietary

Karl Grossner: For each one

Karl Grossner: So ultimately, they live as elements in the DOM

Karl Grossner: All of these data objects

Peter Rushforth: But yeah, and the Linked Data idea like so you know Linked Data in the DOM is parsible, I suppose, like data crawlers in the sense. So giving features a home in the DOM could be part and parcel of making

Peter Rushforth: You know the geo web probable

Peter Rushforth: And more importantly indexable. So, yeah.

Bryan Haberberger: Yeah, and like it's the only difference between the GeoJSON and GeoJSON-LD is that context. So sort of at a really simple level, all I have to be able to do supply context.

Bryan Haberberger: You could do with a simple attribute

Karl Grossner: One thing, as I mentioned, real quick, is that GeoJSON-T

Karl Grossner: Is not LD compatible, such as it is this draft spec that's we're playing with the British Library and elsewhere. There's not LD compatible it

Karl Grossner: Predates really an effort to do that, but it has formed the basis for another format link for which was going a lot. And my last slide, which is Linked Places format.

Karl Grossner: Which is being used and world historical gadgets here which is LB compatible and is valid GeoJSON, it's valid JSON-LD 1.1 and

Karl Grossner: But is much more elaborate. It's designed specifically as a

Karl Grossner: Integration or contribution format for a couple of gazetteer platforms.

Karl Grossner: So GeoJSON-T very much should become GeoJSON-LDT

Bryan Haberberger: Yes. And just to give you a really easy idea of what that means, the context for everything else already exists, all it has to do is add

Bryan Haberberger: Some vocabulary and some constraints around 'when' to say, 'when' is a JSON object, not an array and I expected it to contain this or that and by 'when' I mean geographer.org/when

Bryan Haberberger: You know, and that's it. It would just be literally connecting up that new element that he's trying to introduce and of course some work with the GeoJSON standard people period, because at some point it would have to be sort of a, an approved extension kind of thing.

Karl Grossner: Yeah, I

Karl Grossner: See that is way out.

Bryan Haberberger: It is

Karl Grossner: I've been dealing with this for a long time, and proposing adding time to GeoJSON for a very long time, and I just

Karl Grossner: That group is not especially been responsive to the ideas or just throwing something out there and if I'm using it in some real applications and demonstrating and talking about it and

Karl Grossner: And inviting others to collaborate and making it an actual spec and Gethin is very much in that category. He saw it and that it suits what he has in mind that would serve

Karl Grossner: The Library and Museum communities and cultural heritage and so we're just moving forward and inviting people to help make it a true spec from what it is.

Bryan Haberberger: And so people like me. The chair of a IIIF community group, I take that as a call and to know now I should take this to the group when I when we have our next meeting to say hey guys, I know we're a year out from thinking about time. But look, there's already

Bryan Haberberger: A good JSON implementation for it. Is there anything we can use. Should we just use this and asked, Karl, if we can move it, like, what, what do we do

Karl Grossner: I'll take Peters point very seriously the minimum viable product or least common denominator. This is in my encounters with the world of standards development. This is always front and center.

Karl Grossner: And it's a frustration for people in my position because I'm encountering just all sorts of use cases. And I want to honor all of them.

Karl Grossner: But, but there is. I think there's a simple least common denominator for saying something about time in GeoJSON and one of the authors of GeoJSON has has said very explicitly yes there's such a thing as an event like feature.

Karl Grossner: But the the task. It just seems overwhelming and coming as I think from the world of geography academic, geography and geoscience is the task of merging or

Karl Grossner: Space and time in models and then computation has been an enormous challenge. And by and large is just simply ignored or in terms of standardization so

Karl Grossner: Yeah, it's not an easy thing at all to do or to think about that.

Karl Grossner: Maybe we can make some progress.

Doug Schepers: I have a question

Doug Schepers: I. Oh, sorry.

Gethin Rees: Go ahead. No, exactly. I was going to just say, does anyone else have questions and one on the mute themselves so perfect.

Doug Schepers: I have a couple of thoughts.

Doug Schepers: The first is that the minimum viable product. The 'viable' part is the important bit in there.

Doug Schepers: It's only viable if it allows for extensions. If it allows to be it to be grown into its natural set of use cases

Doug Schepers: and requirements even if not everything's supported at first there needs to be a really good use case and requirements discovery phase in which things are not excluded from being future enhancements of the thing.

Doug Schepers: So that's one thing that the MVP needs to be 'viable'. It can't just be a a bolted on solution.

Peter Rushforth: Yes, I think you need to have a story. You need to have a coherent story for for extension right so

Peter Rushforth: In my world that I think of that as progressive enhancement. So what is the what is the core

Peter Rushforth: behavior that you want to have, and how can you move forward from there. How can you put those times sliders that that make the animate the map and so on. And and and that's what I think, that's how I think of it anyway, is through progressive enhancement and

Doug Schepers: You actually had,

Doug Schepers: We didn't rehearse this folks, that's a natural segue into my next point, which is animation.

Doug Schepers: There are two ways that time is dealt with in the web right now.

Doug Schepers: Well, two main ways I'm thinking like in the HTML context. The first is timed media things like video and the second is animation, as in CSS animation SVG animation or JavaScript animation in general and

Doug Schepers: You know,

Doug Schepers: Karl if if you were to take the data from that Poland right and timestamp, the different states right, I mean by states. I mean, the different

Doug Schepers: Geometric bounds.

Doug Schepers: You could animate. You could use CSS, for example, to tween or SVG to tween between different states, different expansions and I think

Doug Schepers: I think that animation in that sense, really needs to be considered. What are the native animation capabilities of the web. And how is that going to feed into

Doug Schepers: The geometric expressions. So I'd love to see for example like Poland go from small to larger and larger and shriink again to nothing and then bounce back into existence. Over time, lots of other animations of like movements of language groups through through Europe, use of

Doug Schepers: You know, changes in borders in general, political movements, animations of

Doug Schepers: trade routes, etc.

Doug Schepers: animations of slave routes. I saw a really compelling one recently of, you know, where the slave started and where they ended up in you know way they started in Africa and where they ended up in the Americas and it was

Doug Schepers: and the pace at which it increased until it started slowing down and died off.

Doug Schepers: You know, that was emotionally, culturally relevant a

Doug Schepers: Piece of thing and that's, you can't do that if you don't consider time as a natural part of geometry. I mean, for, for that matter, the world spins. Right. Like what, like when, when is something open as well, like a

Doug Schepers: When is a business open

Doug Schepers: Okay, I know where the business is, when is the business right

Doug Schepers: When did it close down, this also ties into the time aspect that Brandon talked about earlier. He has, well he didn't mention it much, but he has this project of, you know, 80s.nyc which looks at historical

Doug Schepers: Things about the

Doug Schepers: New York City. Again, temporal, right, 'when' did any given event occur in a timeline at a particular location. I don't see how we can really think that we're representing geospatial information if we're not if it's not also temporal so Karl, thank you. That's

Karl Grossner: The money line. Thank you.

Doug Schepers: You're welcome at

Karl Grossner: All costs or

Doug Schepers: You can paypal me the the the agreed upon amount later.

Karl Grossner: Haha, that's great. All of the historical cases, you mentioned are quite routine cases that are being done right now routinely in academic research applications and so forth. But they're being done with

Karl Grossner: unique ways of expressing time within properties in GeoJSON and JavaScript. That's way they're being done so.

Karl Grossner: We're because we're interested in the Linked Data world and being able to share things and we have the sort of standard way of dealing with space.

Karl Grossner: There's a real impetus to include time in that standardization to facilitate integration via Linked Dta so so

Karl Grossner: I know that there are myriad modern examples that you mentioned some are stores opening and so forth. That's not my universe so I, you know, I'd be bringing these historical cases to the table, but

Karl Grossner: I know, and I've seen other discussions about time time modeling and so forth, W3C time modeling and all that, but there are very many modern cases and and there is a W3C time that has produced documents and standards and so forth.

Doug Schepers: Yeah.

Doug Schepers: I just wanna-

Karl Grossner: and delivering that to the web is a

Karl Grossner: Is a kind of a separate but very connected issue.

Doug Schepers: Yeah, I wanted to, I wanted to say I wanted to reiterate something I just glossed over which is that we should be looking at how

Doug Schepers: Mainstream things like CSS deal with time as well. Right. And make sure that there's a concordance between

Doug Schepers: How we represent it in GeoJSON and how it could actually possibly at be animated. Just a thought.

Doug Schepers: Where animation is relevant. Right. It's not always going to be relevant, but

Doug Schepers: But sometimes it will be

Gethin Rees: I think,

Gethin Rees: Also the edge case issue is one both presentations on time deal with well in that when you get a group of curators or academics together, you

Gethin Rees: I'm like this, there was this particular building and it moved here and then it moved there

Gethin Rees: And then it moved here and where do we actually put the building, you know, when it changed name and then change back to its original name, for example, and so Brian's

Gethin Rees: Presentation, you know, Web Annotations allows us to actually make assertions that can take advantage of those on what they will they can communicate the complexity of those edge cases.

Gethin Rees: And I knew that Karl in working through quite a few different iterations of temporal, spatial moderate modeling has also really consider those very well. And so I think that's something in in in understanding those edge cases that something this community can bring to a broader

Gethin Rees: Audience or a broader set of use cases.

Bryan Haberberger: More stories, please.

Gethin Rees: Are there any other, I don't know what the time limit actually is on this.

Amelia Bellamy-Royds: We'll cap it at the end of the hour.

Amelia Bellamy-Royds: I guess one question is sort of what what comes next. What are you hoping I mean, I think it sounds like you're going to have lots of collaborations between the GeoJSON-LD and the GeoJSON-T projects. What else from the web community or the rest of the geospatial community.

Bryan Haberberger: So I know with IIIF maps, that community group, for example.

Bryan Haberberger: As I showed you the GeoJSON all the context as it is right now is a no-go. So we are trying to just support the migration of that specifications that I can add that at version tag and perhaps maybe supply some more bounds to properties, having some things so

Bryan Haberberger: Open is actually sort of against some of the things like data once with permanence. We don't really want it to be anything we want it to be flexible on these terms. And so we need to

Bryan Haberberger: Do a little bit of work around that. So I'm working with community groups and I chatted in the Gitter sort of, the links to the stories that we've collected in IIIF.

Bryan Haberberger: And bringing in those use cases and bringing them to thinking on, you know, how are we doing this with resources. I mean, what I showed you was a simple geolocation

Bryan Haberberger: Example, but imagine in a map is an image of a map when there are no coordinates involved, a map is just an image.

Bryan Haberberger: What gives map it's mapping is and correct me if I'm getting my vocabulary wrong geo rectification. So I showed you simple geo locations that assumed a geo rectification, but what if my entity was just that image.

Bryan Haberberger: And I want to apply the geo rectification to it in my own data set as an annotation, you know, is that even possible.

Bryan Haberberger: So how this spreads. You know, it's not it. There's so many things you can do with geo

Bryan Haberberger: And so many things that are just image specific that aren't map specific. So I think a lot of the work we're trying to do for the future is what are those maps specific things that go beyond this being an image

Bryan Haberberger: That we need to account for. And of course, this takes stories and use cases and trial and error and and people like Karl come in and going "You guys didn't even consider the time dimension, what are you thinking like", it's all of that.

Doug Schepers: Well, actually, the annotation working group did consider the time dimension, annotations can be time stamped

Bryan Haberberger: Yes, they can. And especially with IIF AV, We have worked in those temporal assertions for things like a video and audio files, but not for images which again is important for

Bryan Haberberger: An image of a map, you have to realize at its base, that's that's a lot of times just what a what a person takes a map is if you just give me the image with no geo rectification, I can only treat it like an image.

Peter Rushforth: Well, I guess what to pitch my product a bit more like I'm not already doing that enough, but the

Peter Rushforth: Map element would be to geo rectified. So if you wanted to geo rectify and image, you would have a geo rectified target into which to

Peter Rushforth: To do that process. So I can imagine that would be a hefty WASM or JavaScript process. But I mean, I've seen I've seen know like, yeah, I think the New York library had

Peter Rushforth: A site that you could geo rectify images to

Peter Rushforth: Historical basemap

Bryan Haberberger: So yeah, lots of little demos out there. We've, we've looked at them.

Peter Rushforth: Yeah.

Peter Rushforth: So anyhow,

Gethin Rees: Okay. Well, I mean, if people don't have further questions.

Peter Rushforth: Um, web of layers to it. You know, I think layers are an important fundamental thing of of maps, sorry to stretch things out for people, but I just wanted to get some of the you know the primitive

Peter Rushforth: I want to, you know, basically, see what you guys think about

Peter Rushforth: You know, what is a primitive feature of maps and in my world, layers that are everywhere.

Peter Rushforth: I'm seeing Ivan Sanchez was saying everything's all there in his blog post. Everything's a layer. Forget the idea of layers.

Bryan Haberberger: Yeah.

Bryan Haberberger: You know,

Peter Rushforth: Yeah, sort of makes it a good target to actually implement

Bryan Haberberger: Yeah, I mean, in our, in our use cases, things like that, go completely outside of maps, but like a layer that is transcription and layer that is translation. How do we supply that for for for our objects.

Bryan Haberberger: We don't have a specific layer we use the combination of annotation collections and annotation pages and a structure called a range to sort of

Bryan Haberberger: Organize whole or pieces of

Bryan Haberberger: Of like entities and then supply the different

Bryan Haberberger: Layers, if you would, collections or pages of information. And that's sort of how IIIF deals with that primitive in their case.

Bryan Haberberger: I don't have a direct answer for you. I just have the one you know that's around my community.

Peter Rushforth: Can you provide a link for both on that topic?

Bryan Haberberger: Sure let me go grab it.

Peter Rushforth: Well, not now, but whenever

Peter Rushforth: That would be interesting.

Bryan Haberberger: Yeah, I can absolutely I can actually grab you a link on that topic.

Bryan Haberberger: We did talk about it.

Amelia Bellamy-Royds: I will say, I've been

Amelia Bellamy-Royds: Keeping notes in the chat. So kind of drowning the chat in the notes, but I'll copy them over into a Discourse and we can add all sorts of links and whatever there. And of course, we are still recording, so this will go up with the YouTube video of the main talks.

Peter Rushforth: Thanks Amelia for doing that.

Amelia Bellamy-Royds: So this definitely doesn't have to be the end of the conversation.

Gethin Rees: Thanks.

Gethin Rees: Something fantastic I'm sharing because it's been dropping in and out for me a bit.

Gethin Rees: Really appreciate that.

Karl Grossner: I think, you mentioned Amelia next steps and it occurs to me you were talking about extending GeoJSON, so you know natural thing to think about is

Karl Grossner: How to put these ideas about extensions before the GeoJSON

Karl Grossner: maintainers, or

Karl Grossner: Community developers and so forth and

Karl Grossner: There's no

Karl Grossner: There's no immediate uptake, as has been mentioned in the talk about MVP GeoJSON has a term that specified called the

Karl Grossner: Foreign member. Foreign members are allowed. They'll just simply be ignored by all software that doesn't specifically look for them.

Karl Grossner: And that's what, when, when in GeoJSON, a mouse to a foreign member. And at some level, the GeoJSON maintainer could care less what foreign members anybody ads and what they might want to do with them. So the idea, you know, my initial inclination was well time ought to be part of core

Karl Grossner: You know, following

Karl Grossner: What some I've been saying, you know, I mean, it's really elemental I think that a very long list of use cases can be put forward but

Karl Grossner: It's not clear how that's going to proceed. I mean, that JSON-LD a GeoJSON-LD is does not really non existent. I mean, it's not

Karl Grossner: It's not really truly respect at all. It has a has an alias file that just points to some stuff that

Karl Grossner: I don't think makes it really useful RDF,

Karl Grossner: So I don't know. That's a big open, that's my open question, for what next, and in the meantime, I'm just going to keep proceeding working with Gethin to and others who may

Karl Grossner: To create a format that sort of software modules, he's imagining, map plus timeline can work with and then put it out there and say, 'isn't this cool'

Karl Grossner: Is this cool enough to standardize are there enough use cases to support even thinking of it as a standard so

Bryan Haberberger: Now, and if he's working with communities like us, even in that prototype stage, we could probably produce an LD context for it, just to bring you into that game.

Bryan Haberberger: And then you're there.

Bryan Haberberger: And it's, it's in a place where we can start to test it and tell people to use it and give us feedback.

Karl Grossner: It's definitely getting some traction. So in the work that Gethin is doing nd then the IIIF community, the idea of adding time has

Karl Grossner: caught people's attention and there's attention to it. So that's great and

Karl Grossner: In the meantime, I'm writingsoftware.

Doug Schepers: Writing software is the best thing you can do. That way we can pave the cow paths, right. Find

Doug Schepers: actually what the

Doug Schepers: Hard parts are, fix the hard parts in code, theoretic and then standards can follow after

Karl Grossner: That's that's been that's been our game for number of years now

Karl Grossner: Where you can say some time and in action and some of the links that are on my last slide, including world historical gazetteer, which was intended to be

Karl Grossner: Intended to add time intrinsically to place names to places, their names their geometries, their types and their relationship to other places. So 'when' appears all over the place in the standard for that.

Karl Grossner: It is Geo-JSON compatible, well it does work.

Peter Rushforth: What do you do for scale? Like GeoJSON doesn't have notion of zoom built into it. So what do you do for for that.

Karl Grossner: Everything is in JavaScript. So, I mean, you know what, I, I work with Leaflet almost exclusively, I've done other things, D3 and

Karl Grossner: OpenLayers, way back when, but mostly for JavaScript or just make the spaghetti but all people who talk about standards hate,

Karl Grossner: But they love to draw attention to. I make spaghetti and you know it's, it works and it's you know it's a lot of the things I've built a pretty robust, you know, still running after years and so

Karl Grossner: There's a better way forward. And the whole idea of sharing which Linked Data and the LD universe proposes is really

Karl Grossner: My focus. And I think in

Karl Grossner: Gethin and Bryan and also the

Karl Grossner: That introduces

Karl Grossner: It almost compels standard models and ontologies behind those models

Peter Rushforth: Great.

Peter Rushforth: Very interesting.

Bryan Haberberger: I was gonna say the very next thing I would like to see happen is a webpage goes up that just says geospatial not equal to spatial temporal because so many people just assume that because I've done something geospatial for them.

Bryan Haberberger: It's like they can do it you know that timeline and and I say without time. You cannot have a timeline. Don't you understand geospatial it's not spatial temporal. It's so funny because these things are so connected that people just assume

Karl Grossner: Well, there's just a ton of geospatial data for which time is an assumption because you're making snapshots at a given time. So you have this temporal frame. And that's what you're looking at the stuff that tries to get dynamic

Karl Grossner: Is different.

Bryan Haberberger: Machines don't like abstraction that needs to be like, you know, officially said in the data and like you're saying it's not a lot of times

Karl Grossner: Right.

Karl Grossner: It's hard.

Peter Rushforth: Yeah, bet it's hard. I mean, it's so hard for two dimensions and you add the time dimension in there and you disappear.

Karl Grossner: I haven't even mentioned fuzzy time, and uncertainty and so on and so forth.

Karl Grossner: Yeah, all of which are great interest with people who do history.

Karl Grossner: And they're very difficult to formalize

Bryan Haberberger: I've heard a lot of, I saw a lot of talking in Gitter about the static pages and just could you imagine representing someone's location over a day using time you'd have to have a layer or feature for each second of the day like that would be I mean, wow.

Peter Rushforth: Yeah.

Karl Grossner: Thank you all for your comments,

Karl Grossner: Very useful.

Bryan Haberberger: Yes, thank you, everybody.

Peter Rushforth: Thank you for

Peter Rushforth: Joining us. It's been great to

Peter Rushforth: Have you guys join the join the conversation.

Doug Schepers: I want to point out so much

Doug Schepers: Sorry, I want to point out one thing, somebody commented into the

Doug Schepers: Like there. They didn't know what this word meant and caught in the context of MapML and Peter, correct me if I'm wrong, but I want to emphasize that this is not a MapML workshop

Doug Schepers: This is maps on the web. So it's all this stuff is welcome all this stuff in forms.

Doug Schepers: And it doesn't even have to be W3C or OGC. Right. It's this is ultimately this is about what are all the moving parts. And what do we need to do to to connect them and to get them all meshing

Doug Schepers: And there are lots of moving parts. So I want to make sure that people feel like their contributions are welcome in this workshop, because otherwise we're just going to have a partial solution that doesn't solve everything.

Peter Rushforth: Yeah well said Doug. I think the point of this workshop, which we should have had years ago,

Peter Rushforth: But which was only suggested to me by Mike Smith last year, so I blame Mike,

Peter Rushforth: Was

Peter Rushforth: Is to just to highlight exactly how valuable and important maps and location are to humanity and to try and put that into the context of the the information system that is the web into, you know, raise the profile of how we are dealing with maps, we're

Peter Rushforth: In my opinion, we're not we're not, we don't recognize it, everything, like you said, everything has a location every second of every day,

Peter Rushforth: And that is just as important as in some ways as human thought, right giving the web to having the web to allow the expression of that information in a, in an easy way like a way that the web, you know, has paved over for us is

Peter Rushforth: Is valuable I think, I think it's like an inestimably valuable, actually. So that's why the workshop is is here. It's not about, I mean, we've been working on MapML as a community group for

Peter Rushforth: A few years now since 2014 we started the community group at the when the spatial data on the web community, our interest group was created it at a workshop by, you know,

Peter Rushforth: I had my own say and we started the community group and, you know, over time, I've just become you know more convinced that spatial information is

Peter Rushforth: It's a primitive. It's a primitive in society and

Peter Rushforth: We'll see where it goes.

Badita Florin: Can I add something. Yeah, because, like for me like I'm also very glad that this workshop is happening because I'm working with maps like 10 years and

Badita Florin: Most of the times, like I needed to use like QGIS of other things like that. And when I started to going to Web Map, So if that is kind of that found

Badita Florin: But yeah I envision the future when we will not need to have like Leaflet and other things things like that and also to be like really simple, like when you learn HTML

Badita Florin: HTML five to be able to, Yeah, to be able to implement the map, very simply, and have

Badita Florin: Simple things that maybe we will be able to implement yet in the standard like maybe also because

Badita Florin: I'm working with like bigger dataset, like I need to show 50,000 points on the map. And usually when the DOM doesn't handle these so it will need to be see how we could do that at scale, and like clustering, like when you have 50,000 points. Definitely clustering, and that currently using

Badita Florin: Like Leaflet and the clustering, but I think it would be much more better to to be able to kind of get rid of all of these

Badita Florin: libraries that some will become unsupported, like we've seen Leaflet. But most of the people at Leaflet, they are now working

Badita Florin: At MapBox so they will probably not continue to evolve or Leaflet in the same way. So I think is really good to have something more of a standard than different libraries.

Bryan Haberberger: Yeah, that's really good way to put it.

Peter Rushforth: Yeah, absolutely. That's great. And I just come back to progressive enhancement, you know, the objective of

Peter Rushforth: Maps in HTML is not to get rid of libraries, but it's to is to make them faster, better, easier and and to, like, you know, the whole human

Peter Rushforth: World of thought and ingenuity can be applied to maps and, you know, we could take the lowest common denominator and build that into the engine that everybody uses, the browser,

Peter Rushforth: That would be that would be a big step forward in my opinion. And you know, I don't think there's any magic solution to 50,000 points in the browser, right, like like there, That's a lot of data and you have to have strategies.

Peter Rushforth: But anyhow,

Bryan Haberberger: Just sit there and let it lazy load for a week.

Peter Rushforth: Haha, yeah.

Peter Rushforth: Well, right, we're kind of out of time. Right.

Doug Schepers: Yeah.

Peter Rushforth: I'll let you shut us down Doug, or Amelia, take it.

Peter Rushforth: Thank you very much everyone for participating anyway.

Doug Schepers: Very inspiring.

Doug Schepers: Really enjoyed participating in this conversation. Thanks for organizing it.

Doug Schepers: And thanks, Gethin.

Doug Schepers: Thanks Bryan and Karl for really

Doug Schepers: seeding the conversation with some excellent material. And with that, I think we will convene for the day, Amelia. Do you have any final housekeeping.

Amelia Bellamy-Royds: No I think everybody left knows the deal. For now, so I hope to see most of you again tomorrow. And I'd like to thank you all for this session, since we didn't really know how it was going to work out. But this was a really great conversation.

Gethin Rees: Yeah. Thanks very much, everyone really appreciate it,

Gethin Rees: Really njoyed the whole week so far, you know, it's been great. I've really learned a lot.

Bryan Haberberger: Yeah, very refreshing to see how much work is going into this

Peter Rushforth: Awesome. Thanks. Okay, bye for now, then

Bryan Haberberger: All right, bye everybody.

Thanks everyone.

Badita Florin: Thanks. Bye.