Peter Rushforth: The

Peter Rushforth: First, first workshop on map for the web.

Peter Rushforth: Week 2 Day 3

Peter Rushforth: We are going to record this and I'm going to start over.

Peter Rushforth: Sorry Ted, I don't have recording permission and so, oh it's already recording. Very good. So moving on.

Peter Rushforth: So today's theme of talks is going to be advanced web graphics for mapping and then followed by a

Peter Rushforth: Stakeholder panel on commercial mapping services and then we'll have a breakout breakout session on collaborative web mapping by Karel Charvat and his team.

Peter Rushforth: And I just like to remind you that we have a Gitter chat channel open all the time. So that's a good place to have threaded discussions about about ongoing topics and

Peter Rushforth: The presenters will certainly welcome discussion, and after the presentations today, I will create Discourse topics in the web incubator community group for each of the presentations to

Peter Rushforth: So that we can comment.

Peter Rushforth: on an ongoing basis there about web mapping, it helps to gain attention to the topic of web mapping

Peter Rushforth: In the browser community. I'd like to remind everybody that the workshop is conducted under the W3C code of conduct which is linked from the, each workshop page.

Peter Rushforth: So with that, I'd like to hand over the

Peter Rushforth: Presenter controls to Iván Sánchez Ortega of the Leaflet Community, he's going to give us a presentation on

Peter Rushforth: Map adventures in Weird web standards, gyroscopes, texture cubes and mutants

IvanSanchez: That's me.

IvanSanchez: Perfect.

IvanSanchez: So I won't be here too.

IvanSanchez: Okay so hi everybody. This is me Iván Sánchez, I'm going to talk about joysticks, texture cubes and mutants, I have to change that, for reasons that will be later.

IvanSanchez: So for those who don't know me, I am a nerd. I have been doing this lecture, maps and webs literally 15 years ago.

IvanSanchez: My allegiances are towards OpenStreetMap. I have been a member of the board of the foundation a few years ago. I am a charter member of OSGeo and I am a maintainer

IvanSanchez: of Leaflet. I am very skeptical of this proposal, so skeptical that I cannot tell you why in 15 minutes so I wrote a lengthy essay about it, it's my position statement as well. So please read it if you have a time

IvanSanchez: To save half your time, I'm going to focus on this part of the joke. I don't think that the MapML standard covers use cases. I know this

IvanSanchez: Because I have been dealing with approving Leaflet plugins for a while and they are literally hundreds, each plugin is a use case. And I don't think

IvanSanchez: The standard as it currently stands, is able to cover all those use cases or even to accept the integration needed to cover these use cases.

IvanSanchez: Since I really short on time I'm going to focus on integrations with existing browser APIs in particular,

IvanSanchez: a few APIs that you probably didn't know that existed, which are the Gamepad API, the textStorage3D from what we have to DOM mutation observers. So let's get on with it. Joysticks.

IvanSanchez: How do we interact with maps. We do most in our scripts, pointer events, we do keyboard events. We also follow the user via Geolocation API.

IvanSanchez: We also rotate the map, when we are navigating with the compass orientation with relative orientation sensors API.

IvanSanchez: We can also do an experiment about tilting a phone tablet and then making them up slide off the surface of the phone and tablet, by adapt some traditional sensor which I didn't really have time to play with the demo, but you can also do joysticks via the Gamepad API.

IvanSanchez: And moving things with a Joystick actually works. It works nice. It's easy to do something like this. You just hook up

IvanSanchez: The new events and works and it's an interaction that nobody really has been thinking about, works pretty well with Gamepads as well.

IvanSanchez: And I have to say, this feels good. And I also have this feeling that interaction with joysticks or gamepad it's something that

IvanSanchez: I don't know what it's useful for but I feel like this is really useful for something. I don't know what for, still.

IvanSanchez: So if this has hooks to haptic peripherals, maybe under that, maybe we want some accessibility features, because some people might handle a controller below keyboard and mouse. I don't know how that would work work and I don't know how these kind of interactivity belongs or works with

IvanSanchez: With my, with MapML at all.

IvanSanchez: One of the things I'm not sure about.

IvanSanchez: I'm going to talk now about Texture Cubes. So back when it was 2017, I was doing some weird experiments

IvanSanchez: Replacing the images from tile maps with canvases. And each canvas receives a buffer from Web GL and then you handle the textures and

IvanSanchez: The tile goes through a whole process to basically change the color. And I have this feeling of this is useful for something. I don't know what, what for, but this has to be useful for something.

IvanSanchez: So one of the things I learned, and this is important to keep in mind is WebGL or OpenGL is not a 3D engine. It's a 2D rasterization engine,

IvanSanchez: That takes a lot of four dimensional vectors, combines it with buttloads of linear algebra and uses images as texture and before the Code of Conduct police comes to me.

IvanSanchez: And different about most of the youth the unit of measurement of alcoholic beverages, which is, in my opinion, with one person needs to really understand what the hell is going on in linear algebra

IvanSanchez: You know, a normal person will think that a picture is just an image, a color image, 8-bit red and blue. And that's it.

IvanSanchez: For instance, people who have been working in video games, know that textures coming more than images, do you have something like the bump map, plus specular map, which is how a surface reflects the light that goes into a surface.

IvanSanchez: And that can be put as different formats 5-5-6 bits, 16-bit or float32, it's not it's not necessarily 8-bit.

IvanSanchez: Then when you come to learn to learn what the GIS nerds are doing, for them, raster data is temporal multispectral/thematic data, which is a lot of tiny little squares and or cubes which each holding 16 or 32-bit examples, one or more samples per pixel or per boxel.

IvanSanchez: The breakthrough is realizing that the GIS raster data feeds natively into geotextures, and I mean presently nobody has noticed this before.

IvanSanchez: So you can use get data from GeoTIFF, put the texture and that will get the texture and that will get the native data,

IvanSanchez: The raw data with no transformations from the GeoTiff file. One of the nicest things about WebGL2 is that you get float32 format and you get actual data cubes in the form of 3D textures.

IvanSanchez: So in this example in getting, this pseudo code. Anyway, but you get the idea. I can get several samples from a GeoTiff file. And since they are packed together, one

IvanSanchez: After the other, they will have the same format or the same data structure that 3D textures need for this.

IvanSanchez: And then you just fetch the initiator and then you can fit coordinates, you can use. In this example I will be using just the different

IvanSanchez: Channels are the same as samples of a GeoTiff file or the set coordinate, but you could easily, easily change these

IvanSanchez: handle the coordinates with a buttload of linear algebra to access changes or whatever you want.

IvanSanchez: One up sample. I have been working on is this one with some sentinel data in this I have an actual data cube or tile.

IvanSanchez: It's of the 253 256 a pixel style. It's not a tile, It's a small data cube like 256, 256 by 7,

IvanSanchez: So you can fetch textures for any of those points, I can do the linear interpolation between the points, you can do all that kind of stuff. And I can do something nice, really nice, which is real time raster processing and analysis, which is

IvanSanchez: For me it's just beautiful.

IvanSanchez: Things like this. I don't know what I'm doing. But I'm doing the real time on the GPU with a raw 16-bit GeoData from actual Sentinel satellites. This is great.

IvanSanchez: I want to throw some buzzwords at you because I feel like doing this. It makes me a cool person. This is real time, meaning it happens once per frame which for for normal people is real time.

IvanSanchez: For electronics people it's not real time. It's a different

IvanSanchez: Discussion. This is real time GPU-accelerated because it happens in a graphics card. It's cloudless because it doesn't depend on this cloud of servers, which are somewhere that you don't worry about

IvanSanchez: It's edge computing because it happens on the user's computer. It's for cloudless imagery because you can apply the algorithms for removing clouds from Sentinel data for multi or

IvanSanchez: Hyperspectral data. And one of the issues I think this has is that it's difficult to monetize because we've, cloud computing, it's really easy to know how many CPU cycles you have been selling to the users, but once that happens on the user's computer

IvanSanchez: You can't really measure how much work the user's computer has done using your code. So yeah, there's not a lot of money and people involved in this kind of research. Right.

IvanSanchez: Anyhow, I do predict by the in three years time, every GIS person involved in Earth observation and raster analysis will ask themselves how did we not do this sooner.

IvanSanchez: I don't know how MapML will work with this, and seeing the performance of GL and having seen how a low level data abstractions work,

IvanSanchez: I do not know how can we squeeze this thing. I do not know how can we make non 3D GL more accessible to any other developers, because geo has a lot of potential for raster analysis and we're not squeezing it

IvanSanchez: I think it's because the APIs. Whenever we talk about WebGL, We already think, we are already thinking into 3D and 3D models and a camera and an object and light sources.

IvanSanchez: How can we change this perception, because if we change this perception. I think we will improve raster analyses and any other kinds of sciences. I don't know. I want to make this happen. So I don't know how to get rid of the preconception that we should use SVG for

IvanSanchez: For doing graphics. I don't know. I'm unsure.

IvanSanchez: I'm going to go to part three. So mutants.

IvanSanchez: And I'm going to start with this fact that I am not going to accept any discussion on this fact. Leaflet users want to display Google Basemaps, they want to. This is a fact.

IvanSanchez: Now it's easy. You just put this tile definition and it works. And you have to do nothing else and you know one line of code, it works.

IvanSanchez: But.

IvanSanchez: Google doesn't want you to do that at least if they didn't, as of 2018, with this wording of the terms of service, you might not access map tiles through interfaces that are not documented

IvanSanchez: Or that you don't have access to. The wording of the current terms of services are not clear. So I know that Parsons is somewhere in the room. So can I have a clarification of this, please. Pretty please with sugar on top?

IvanSanchez: Anyhow, how do you overcome this limitation. What do you do you get a Leaflet, one side of the screen and a Google map on another side of the screen. Do you hook them up so whenever you move the Leaflet map the Google Map morphs

IvanSanchez: Whenever you zoom, the Leaflet map, the Google Map moves and then you do CSS trickery.

IvanSanchez: And it works. It kind of works. So right now you can do Leaflet with some Google Base maps and but, that lags, a lot of lagging

IvanSanchez: There's a lot of lag when you're moving it because the Google Map will lag at least one frame behind,

IvanSanchez: And when you're zooming, zooming you see animations that not, that don't follow the same function so stuff gets, not very user friendly.

IvanSanchez: So you can overcome that by doing DOM manipulation, which is even dirtier. So you make the same thing. You hook them up. So whenever the Leaflet map moves, the Google Map moves and then you manipulate the DOM to steal the titles.

IvanSanchez: And it works. And now the tiles and the Leaflet container and there's no lag because the movements are controlled only by Leaflet I don't care what the Google map might be doing with her and now empty tile container.

IvanSanchez: You have to resteal the tiles anytime you move and there's a lot of race conditions because this synchronous because it depends on the network. And then you have so many issues. So the synchronicity is hard. And you know what new tiles will come in.

IvanSanchez: So you can use mutation observers.

IvanSanchez: Do you lose some, you create a container or for the Google Map, then you set an observer and you get told whenever any DOM element is created inside that

IvanSanchez: In that in that way you can automatically steal the tiles to your document DOM fragment whenever the title is ready. And it works! And it works pretty nicely.

IvanSanchez: So,

IvanSanchez: It just works. And obviously, there's the same CSS trickery to get logo on the bottom and stuff like that. But it works and compared to Leaflet

IvanSanchez: Native geometries, there's absolutely no lag whatsoever. The zoom is perfect. It just works. Now this has been called and for me this is high praise.

IvanSanchez: "Absolutely brilliant and terrible at the same time." And I think so. This is somethign that shouldn't exist.

IvanSanchez: And this is, to me, one of my hard points of view, might be controversial, but I, this is one of the hills I will die on

IvanSanchez: Vendors should be able to expose, should be exposing standard interfaces.

IvanSanchez: Authors should be able to cache all the map assets. Clients should be able to interchangem exchange the those map assets by P2P, because one of the excuses that we have been given for paying for maps is that there is a cost associated with it, if it was peer to peer that cost would go down.

IvanSanchez: So that's something that, for me, it's quite important. I also think that DOM mutation observers shouldn't exist, they break

IvanSanchez: The encapsulation of coding web applications. And it's the as dirty, it allows very dirty hacks and Google Mutant as a whole as a concept, It shouldn't exist. I shouldn't

IvanSanchez: Have to spend any time making it. Really, it has no reason, there should be no reason for it to exist at all. So one of my biggest complaints or

IvanSanchez: Critiques about MapML is that MapML shall not fix any of this. MapML will will not make vendors explose standard interfaces, will not author cache map assets so they can

IvanSanchez: They can control all the things that they displaying their web pages, it will not let clients P2P-exchange map assets, it would be a boon for all

IvanSanchez: For everybody. It will not deprecate browser APIs, because we all, we only put more and more and more and more in browsers and it will not stop people from doing ugly hacks.

IvanSanchez: That's my main point about why I don't like MapML, or very condensed in this short talk

IvanSanchez: And that's what I have. Please read my essay, and that's it.

Peter Rushforth: Well, thank you Ivan for that excited tour of your, your thinking on the subject and I put a few comments in chat and I'm happy to engage on that.

Peter Rushforth: So, with that, we're going to move on to

Peter Rushforth: Our next presentation, which is map compositions format by Karel Charvat.

Peter Rushforth: Karel, over to you.

Peter Rushforth: I think you're on mute.

Karel Charvat: Hello?

Karel Charvat: Thanks to give us chance to make our presentation here, now in just short introduction, I will only make some messy,

Karel Charvat: short messages about what we are doing and

Karel Charvat: To the data, we will present it later in breakout session where my colleagues or will give you also more technical details so

Karel Charvat: Ivan before spoke about things related to his Leaflet. We will now move to other technologies more or to OpenLayers and

Karel Charvat: QGIS but first I will tell about what and why we are speaking about map composition. What Ivan presented it was mainly focus on some expert work with

Karel Charvat: Geographic information. But what what is clear.

Karel Charvat: Sorry, why is this not working. I'm not able to move past this image.

Karel Charvat: I have problem to move to move this presentation. I don't know why.

Peter Rushforth: Um,

Peter Rushforth: Are you sharing it off your desktop or from the web.

Karel Charvat: No, I, I'm doing this is from my desktop as

Peter Rushforth: Well maybe exit presentation mode and go back in.

Ted Guild: At the bottom boundary I was also seeing a next, next and back button too. Move your mouse, the bottom, can move your mouse to the bottom.

Ted Guild: The presentation, you're hovering over or the end. I've seen some some buttons here.

Karel Charvat: Where are the buttons? I don't see

Ted Guild: You move further down

Ted Guild: Move your mouse further down

Ted Guild: Here you go.

Karel Charvat: Now, okay, okay. Sorry for this. So why we are speaking about map composition and we will speak also not only about map composition, but about

Karel Charvat: Cooperation, if you are looking on the classical map.

Karel Charvat: Is there is a

Karel Charvat: Number of different information now with your geographic information systems, we are dealing with layers. Yes, but layers are not map, and what is important.

Karel Charvat: For people who are not expert, to move from layers to maps. We open this first time when we develop, you know, the Czech Inspire Geo Portal, it was around 2010 you can see on one side how it looks on maps, on the other side, if we are looking on the data. It looks approximately

Karel Charvat: Such but we have to move from this layer paradigm to

Karel Charvat: paradigm also map and first time we talked about this when we implemented this Inspire Geo portal and in this time we start to use web map context.

Karel Charvat: In the past, some OGC standard about with some limitation, and this limitation was mainly that it will work only with the WMS services and not there are no possibility to integrate

Karel Charvat: Other data, but we extended this, in this time to this concept and on the Czech Inspire Geo portal we start to offer to the people thematic maps, not layers but the non expert was able to select the

Karel Charvat: Some concrete composition of layers and work with this because for many people it is very difficult to understand,

Karel Charvat: WMS, understand other things, and also decided in which scale, you have to put the

Karel Charvat: which layer. So this could be or has to be in some way described in this map composition or what we are now calling the maps. You can see here we have

Karel Charvat: Number of layers, but on the entry to have the maps, for example, just combination of this satellite images, OpenStreetMap or other, and we have a huge number of new technologies HTML, CSS, JSON and

Karel Charvat: It is important to use this technology, how to describe map, we develop our own JSON format for describing of map composition later in the evening, right, this will

Karel Charvat: Tell you about this. And I think that today we think is also good opportunity. How to discuss and speak, how, for example, this approach, which we are now pushing, can be combined with other effort and other standard in OGC or in W3C and

Karel Charvat: Having here, my colleague, I think that it is a good opportunity to start discussion with other, how we can combine this our approach, which is now used very often, we implemented this approach, not only for OpenLayers, but we are able to share maps with

Karel Charvat: QGIS and we start also some tests, with Leaflet. So the idea is that the map is defined and could be shared.

Karel Charvat: On other places. Yes. Right, you are now sharing music, you are sharing other you can have the silos and you can from the silos, you'll be able

Karel Charvat: To share the map. The silos could be some map catalog, not only catalogs for WMS services or other, but to have the catalogs also the maps and to be able to share with other people, you know the maps. Second thing, we you will today speak much more is

Karel Charvat: What we are calling now map whiteboard. What is it,

Karel Charvat: You are probably all working with Google Documents. Google Documents is something where you can share the text and many people can edit this text

Karel Charvat: From different places and collaborative way you can work with the map. It could be important for many application for education. It could be good for farmers, it could be good in

Karel Charvat: Crisis Management. If you are able to share the maps, you are able to share all else, you are able to

Karel Charvat: Share your drawings immediately and other people can communicate, who is this of course this is now more and more important in covid period to have real collaborative work. And this is what we are now working and what we will speak, as I mentioned, there is so many

Karel Charvat: Many application where this could be used, of course, in education, typical place would be spatial planning, it could be agriculture, to be possible to share the maps and to edit the maps collaboratively and to share this map with

Karel Charvat: Other people. So this is some short introduction, and I hope that some from you will be able to stay to the end and we will be able to expand you in today what is our map position. And what is this map whiteboard.

Karel Charvat: Hello.

Peter Rushforth: Sorry. Thank you very much Karel.

Peter Rushforth: We're going to move on to Daniel Morrissette of Mapgears who will be talking about

Peter Rushforth: The implementation of MapML and Map Server GDAL and OGR. over to you, Daniel.

Daniel Morissette: Thank you, Peter. So my slides are on right

Daniel Morissette: As soon so

Daniel Morissette: So,

Daniel Morissette: Talk about yeah the implementations that we put in place a Map Server GDAL and OGR essentially kicking the tires to see how it goes with the current draft version of the spec as of the spring.

Daniel Morissette: Okay, so for those who may not be from the GIS World, Map Server is a web mapping engine.

Daniel Morissette: Open Source web mapping engine, the GDAL library is, I guess, the Swiss Army Knife of GIS. It's a library that supports hundreds of raster and vector data formats and both are open source projects of the Open Source Geospatial Foundation

Daniel Morissette: So the stuff I'm going to talk about today's implemented and available as a reference implementation in open source format.

Daniel Morissette: First for the keys of Map Server, there's a link to the documentation there. It's been discussed in MapServer RFC 123 is going to be included in the MapServer 8 release.

Daniel Morissette: At the moment it's available to a git, source, GitHub source fork, but the implementation is going to be released later this fall.

Daniel Morissette: Essentially, for those who know Map Server. You've probably all already published WMS an OGC WMS Service. So all you need is a WMS enabled map file that you've got already

Daniel Morissette: you enable the GetMapML, a new vendor specific GetMapML request, and that's it. The rest is magic handled by Map Server and the polyfill viewer through the MapML Spec so

Daniel Morissette: Essentially in your map layer tags, know the MapML layer tags, you include

Daniel Morissette: A custom URL, which is service=WMS&request=GetMapML, and then you specify which layer, you're referring to, from your map file and the projection using the projection code, the MapML production code. So essentially,

Daniel Morissette: Yeah, it looks like this in the HTML.

Daniel Morissette: And

Daniel Morissette: Yeah, this is the actual source code from an example.

Daniel Morissette: And I'm gonna swap to just to show to show it in action. Just show that it's a real thing and it really works. So

Daniel Morissette: I this is by the way, this is the documentation from the MapServer side. So it talks about the metadata elements, the configuration elements that you can use to control the behaviors.

Daniel Morissette: And essentially, the viewer looks like this. So it's just a simple Leaflet. It's the polyfill viewer that you are that you're seeing here.

Daniel Morissette: Pointing to WMS layer. So the source code of this page is this with this GetMapML URL pointing to the Map Server map file.

Daniel Morissette: And if you look at the source of what Map Server returns. It's a MapML document so implementing the draft specification

Daniel Morissette: Which contains link rel="image" so full screen image maps are requested using this URL template.

Daniel Morissette: And for the get, when you query the map. So the link rel="query" points to GetFeatureInfo using the template. So all this you know this is a bit verbose, but it's all handled by Map Server, you don't need to do any of that really all the

Daniel Morissette: All you need to do is create this layer element in your HTML to make it work and have a Map Server WMS and rebuild Map Server map file. So back to the slides.

Daniel Morissette: Yep. So that's what I talked about. There's a, so the case, I've been showing was the link rel="image" which returns

Daniel Morissette: full page WMS request, but the implementation also support tiled request. So you can request tiled WS request or

Daniel Morissette: There's a custom mode mapserv which is mode="tile" which mimics I believe the Google Maps API

Daniel Morissette: Tile requests or that one is supported as well. There is a future plan to have the ability to do a WFS get feature we using link rel="feature". And as I mentioned earlier,

Daniel Morissette: Link rel="query" would point to Get FeatureInfo to the WMS GetFeature and forth to allow you to query the map.

Daniel Morissette: So that's it for the Map Server implementation and now

Daniel Morissette: For those who like to work with data, or would like to generate a static data set and host it without

Daniel Morissette: Any server side components, an implementation has been made as well on in GDAL for the raster side and in OGR for the vector side. So as I said,

Daniel Morissette: The GDAL library support hundreds of vector and raster formats and what's been done on the OGR side that's been added recently in

Daniel Morissette: OGR version 3.1, which was sometimes in the spring or the summer the documentation is available at this URL. So it's part of the, it's MapML, essentially, an OGR driver.

Daniel Morissette: And it will read and write MapML vector features. So, it reads its own MapML, it will not read any MapML because there could be too many variants

Daniel Morissette: But it will spit out MapML output. And the command for those who are familiar with the ogr2ogr syntax, which is probably not too many people because it's very cryptic,

Daniel Morissette: Essentially, if you were to use it with ogr2ogr. You would specify, let's say, in this case I'm going from a point file, which is a shape file, I'm creating a MapML file.

Daniel Morissette: And I'm running an SQL query on it to just select some attributes I'm interested in, and only select the the populated places have more than 100,000 people and I'm passing some custom contents for the HTML header for the MapML header in this case.

Daniel Morissette: So that's the way to do it on the command line with ogr2ogr. For those who are familiar with that or just export to MapML from an OGR enabled software and

Daniel Morissette: About any piece of GIS software does support OGR so that would make it fairly widely available, then you will refer to this MapML file from earlier element in the map.

Daniel Morissette: To be fair, I, I have had some glitches with the current polyfill trying to do that. So I need to do more tests and probably go back and forth with Peter on the implementation, but the implementation in OGR does produce the valid MapML

Daniel Morissette: And then on the raster side.

Daniel Morissette: The gdal2tiles utility, which can be used to

Daniel Morissette: Taking a raster image and generate a tile pyramid and it can, it already supported the HTML output. So it's been extended to support

Daniel Morissette: MapML output. So essentially when you run it will take a raster image, creatd a tile pyramid, a tileset out of it, and then create a MapML header file that refers to it that you can use to host the data afterwards.

Daniel Morissette: And the command looks something like this. So it's a command line utility in that case.

Daniel Morissette: So, and then you take your output folder and then and place it on your web server to host and refer to it in from your map element in the HTML.

Daniel Morissette: I Have to say that this, the implementations in GDAL and OGR were done by Evan Rouault who is the maintainer of GDAL and OGR so he has to be thanked for that work.

Daniel Morissette: And that's about it. So the quick introductions on three implementations. I know there are more. Geo Server has an implementation as well.

Daniel Morissette: That's been done. And there's a few others that maybe people will be better than me to list, but there's a few reference implementations. So that's, I guess, a good way to start to see the MapML in action and see how it goes.

Peter Rushforth: Yeah, great. Thanks a lot, Daniel. The anyhow. It's great to see a MapML being incorporated into these mainstream open source tools, showing the web platform community that we are in serious and intend to meet them halfway. So what we're trying to get them to come out of their houses.

Peter Rushforth: OK, so moving on to

Peter Rushforth: Our next presentation we're going to have a lightning, lightning round from Andreas Hocevar from the OpenLayers project on Offscreen Canvas for rendering performance and risk. Are you ready to go?

Andreas Hocevar: Ready to go, thank you.

Peter Rushforth: Your audio is a little choppy right now I

Peter Rushforth: Don't know if there's anything you can do but

Andreas Hocevar: Turn on screen sharing

Yeah.

Andreas Hocevar: So I'm going to talk about a way to improve rendering performance of huge vector tiles data sets in OpenLayers. And I guess this topic might be of interest.

Andreas Hocevar: Because as long as MapML is not available in mainstream browsers, mapping libraries will have to provide their own renders

Andreas Hocevar: And the goal here is of a project that was funded as part of the Maps4HTML effort which I'm very thankful for, was proof of concept to improve rendering performance, and avoid blocking the UI in OpenLayers.

Andreas Hocevar: For those who don't come from a web mapping background, OpenLayers is a library for creating interactive maps.

Andreas Hocevar: On the Web and it can display map tiles, which can be raster tiles, like the ones that Daniel was talking about, but also vector tiles.

Andreas Hocevar: Also untiled vector data and super markers loaded from any source on any web page. And this can really be a huge amount of data later on in this presentation I will be showing

Andreas Hocevar: vector tiles data set where a single title which covers more than 512 by 512 pixels on the screen can be more than 500 kilobytes, which translates to 10s of thousands of vectors.

Andreas Hocevar: And unfortunately, the makers of OpenLayers which include myself, are not as smart as the makers of MapBox GL JS, which has a super fast and performant and good looking

Andreas Hocevar: Web GL renderer in Open Layers.Rendering is done using the canvas 2D API, which means the GPU can not be leveraged to such a high extent.

Andreas Hocevar: And this is also the reason why such heavy maps as I just mentioned can cause slight performance problems.

Andreas Hocevar: So what is the problem. Typical rendering pipeline for Web Map consists of loading data, parsing data, rendering the data and then of course, the user interacting with the data, which means zooming and panning the map, querying attribute informations and things like that.

Andreas Hocevar: With the standard browser APIs for asynchronous, neatly fetching data loading already runs without blocking the UI. So in this graphics that I'm going to show,e each row

Andreas Hocevar: Represents things that that have has to have to be done in parallel. So in this standard OpenLayers map, loading can happen in parallel, while other tasks go on, parsing, rendering and interacting with the data.

Andreas Hocevar: Loading the data is not the problem here. Interesting. It gets interesting with parsing data, the more data you have, the longer it takes to parse it, but the

Andreas Hocevar: The real bottleneck with a canvas 2D render is the rendering process itself, OpenLayers is also very flexible with rendering it allows you to style your map, your vector map

Andreas Hocevar: With functions that can look at each feature and decide based on that, how to render the feature.

Andreas Hocevar: So it's very flexible here and it's all in this context is also not easy to prepare that data in a way that GPU can

Andreas Hocevar: Run it in in a in a parallel way that would give a huge performance benefit. That's also one of the differences to MapBox GL JS where you have styling language and not arbitrary style, JavaScript functions to style your data.

Andreas Hocevar: So,

Andreas Hocevar: One thing we could do would be to use the web workers API that's available in all modern web browsers.

Andreas Hocevar: This would allow us to load and parse data in parallel. And in one thread and to render and interact in another

Andreas Hocevar: The problem here is that transferring data between a worker and the main thread is only efficient with structured data like type arrays.

Andreas Hocevar: And at this stage, we don't have that structured data already. We still have vector data that could be

Andreas Hocevar: Different types of geometries and we have to combine them with styles that are still JavaScript functions. So, we cannot really create a type structure that can be efficiently transferred from the worker to the main thread

Andreas Hocevar: So one solution to that, would be the use of Offscreen Canvas. That's a new API that's already available in Chrome. And what I'm going to show now is a proof of concept of making use of this API.

Andreas Hocevar: By using OffScren canvas, we can also use also put the rendering, separate from interacting with the map, which in

Andreas Hocevar: As a consequence, results in no more blocked UI by heavy calculations going on. So we can load, parse and render the data in a worker, Offscreen Canvas allows us to prepare a canvas in a worker and transfer it efficiently to the main thread, where we interact with the map.

Andreas Hocevar: Now let me show you how that looks. When we apply that technique. In this video I'm going to show on the left.

Andreas Hocevar: You see the use of Offscreen Canvas, on the right you see the same map rendered with OpenLayers, without any any workers and this is the data set I talked about were just a single tile can have tens of thousands of vectors.

Andreas Hocevar: So this is how it looks.

Andreas Hocevar: As you can see on the left, everything smooth. The only delay comes from loading and parsing the data, but the UI is not blocked and you see on the right side how the UI is stuttering as this automatic animation that zooms and pans the map around, is going on.

Andreas Hocevar: So why don't we use this by default.

Andreas Hocevar: As I already mentioned.

Andreas Hocevar: It's already available in Chrome.

Andreas Hocevar: But that's about it. So it's available in the blink engine, which is now also used by Microsoft Edge, there is limited

Andreas Hocevar: Offscren Canvas support in Firefox, but only for WebGL contexts, not for the Canvas2D context that we use in OpenLayers and it's hidden behind an experimental flag, so not available to the average user and it's not available at all in WebKit engine, which is used by Safari.

Andreas Hocevar: So this is, please, WebKit and Gecko developers implement Offscreen Canvas. When this is available in all mainstream browsers, we can provide good performance improvements.

Andreas Hocevar: And it will make it easier to wait until browsers have native map rendering available with MapML in a hopefully not too far away future

Andreas Hocevar: Thanks in advance WebKit and Gecko for implementing that, hopefully soon. And thanks again Maps4HTML community for funding this effort that allowed us to explore the benefits we can gain from using Offscreen Canvas in OpenLayers. Thank you.

Peter Rushforth: Thank you very much Andreas for your contribution to the community and hopefully we'll get some attention for those features in

Peter Rushforth: Safari and Firefox as a result of your efforts. So

Peter Rushforth: Moving on to our next presentation we're going to hear about dynamic and observational spatial data from Thomas Usländer, Hylke van der Schaaf, Katharina Schleidt

Peter Rushforth: Have I pronounced that correctly?

Kathi Schleidt: Mine is correct.

Kathi Schleidt: Anything, Um, can I take the screen.

Kathi Schleidt: Good, working? Yep. Okay. So we're going to start filling, some of the gaps which have been showing up in today's presentations I admit I noticed the word sensor being there and suddenly going away.

Kathi Schleidt: So now it comes back, big time, what are we, what are we talking about these various dynamic data in a spatial context.

Kathi Schleidt: And we start with

Kathi Schleidt: How we provide a basic attributes. So in a normal world. You've got some some object, you have two characteristics of the object, the color, the expression

Kathi Schleidt: These are simple attributes pertaining to the object and they have values and everything is fine until you start realizing you need additional metadata.

Kathi Schleidt: So that's why we've got the observational models where you realize, okay, yes I know the color is yellow, but

Kathi Schleidt: That what methodology, how was that used, what could the colors be, what is the data quality, all of this information is missing with simple attributes.

Kathi Schleidt: And we need this with measurement data. The problem is when you get confronted with a pile of these, it is not easy to play with.

Kathi Schleidt: And so the users get this. They look very confused, what they really want this. This they want nice simple flat tables, they can stuff into there, and get on with it.

Kathi Schleidt: Or some simple way of mapping, but not the holy mess. So they have have a simplified world, but then they start realizing that all of these additional bits were relevant after all.

Kathi Schleidt: And then they're not happy or, and this is where we've been making good progress with SensorThings technology because really allows us the various different viewpoints on this. The only problem is how do we get on to a map.

Kathi Schleidt: So a short background of SensorThings as I'm aware of this community is not familiar with this.

Kathi Schleidt: It's a technology that produced by OGC 2016. It comes from the IoT world. It's a wonderful standardized way of representing sensors, actuators also simulations.

Kathi Schleidt: And it's built on a long history of OGC standards dealing with what they refer to a sensor web enablement that's insulated determining how can we get this type of dynamic sensor measurement, observation data sanely connected with with maps and spatial data.

Kathi Schleidt: Relevant domains which is being applied, I mean, it's very strongly in the in the environmental sector.

Kathi Schleidt: It's also used in building management systems, Smart Cities, industry 4.0 is going in this direction, but

Kathi Schleidt: The world has been working with this model, we've realized it's so flexible that one of our recent prototypes has been putting European demography data online and it works beautifully.

Kathi Schleidt: So it's a really a very nice flexible technology. When you've got dynamic data pertaining to your spatial objects.

Kathi Schleidt: Um, okay, that's the bit of the history of it. I'll keep it short.

Kathi Schleidt: What's it about. It's got a core data model in the background, which covers all of the concept we need to really nicely structure measurement data.

Kathi Schleidt: This comes from the background of it is the OGC observations and measurement standard has been formalized as either ISO19156

Kathi Schleidt: That provides its basic core. It's been a bit specialized here for the purpose of SensorThings and provides when has the, the resulting values, but when also has what was observed, how was it observe, Where was it observe, all this information, it's all there.

Kathi Schleidt: But the problem is, okay, let me just more explanation of this. It's based on the OASIS OData model we've got various get, post, patch, put, delete, you can input output all of your data.

Kathi Schleidt: And we've got various query parameters which allow you to really nicely deal with the RESTful interface. And we've got an MQTT interface in the back end, so, totally suited for clicking on sensors, plug and play.

Kathi Schleidt: The problem is the query logic and if you think back to the data model I was showing before, most simple spatial application deal of individual objects with attributes and geometries.

Kathi Schleidt: They do not have this complex structure between the classes. And this is a central in order to really access the data because you need the the pieces from the individual concepts, thus the SensorThings query logic allows you to really,

Kathi Schleidt: You can formulate your queries, based on the graph defined by the data model. And so this way. We basically we haven't come up with a query you cannot formulate and nicely query.

Kathi Schleidt: And what we want to do with this, Here's an example from the Austrian air quality data, you've got to put your data on the map. You've got your points where you have it.

Kathi Schleidt: The problem is what happens you have too many points, you need to put little circles with numbers.

Kathi Schleidt: Want to get to the points, you want to see what is available there, the list here are the observable properties available from the station office now.

Kathi Schleidt: And then if you click on one of these, you want to see the time series of the actual value. This is what we would want. And this is what to at least until a few weeks ago any the developer who want to expose this data have to do manually.

Kathi Schleidt: A further trick which we have there also pertains to multi resolution data. If you zoom in or if you're looking at a very coarse map of Europe, you don't need also details.

Kathi Schleidt: And more you zoom in, the more you really need all of the tricky bits. And we see this nicely. There's an example from from Norway, we've got on the left, we've got the

Kathi Schleidt: Sort of the big picture data which vaguely finds the islands. On the right, we've got the very high, very high resolution each fjord is in their

Kathi Schleidt: Center things allows us to cope with this because one spatial object you have multiple locations. And so we've made good use of this by

Kathi Schleidt: storing all five different resolutions as locations, having a flag in the data showing which resolution it is, and the map viewer pulls the right resolution it needs.

Kathi Schleidt: So what did we do to get out of this. We currently have a, we've been discussing what do we call it, it's not really a plug in, it's for a plug off.

Kathi Schleidt: It's a small little JavaScript library which handles all of the tricky bits we've been discussing, the uh, how do you show the different resolutions, how do you out alternate

Kathi Schleidt: Alternatively show pin pins for the individual stations, you can show if it's too many just provide number

Kathi Schleidt: That various integrated callbacks so you can pre configure it and say, when you click on the point then get this callback to show the observable properties. When you click on individual thing there, all that function to show the graph. It's available on GitHub by the link here.

Kathi Schleidt: Functionality I've shown. Here, We've got an overview of the configuration options. I mean, is basically one large, not even large, medium sized JSON object which you configure

Kathi Schleidt: Fill up fill out these parameters, fill out the parameters. The next page.

Kathi Schleidt: And it then you once you have this filled, you have to tell it is working with Leaflet OpenLayers and then it seamlessly integrates with whatever map software you have underneath, adds all of this functionality, everything is good.

Kathi Schleidt: So conclusion, SensorThings API is becoming increasingly deployed, more and more domains are covering the power of it.

Kathi Schleidt: Map based visualization has been the tricky point and with our SensorThings API map library. We think this is a

Kathi Schleidt: good first step at providing simple support for this. More information that's what was the work was done under the API for INSPIRE project founded by the European ELISE program. More information at the link I presented. Thank you for your attention.

Peter Rushforth: Thank you very much. Kathi, Thomas and Hylke. A very interesting presentation on and

Peter Rushforth: So that's, we're a little bit ahead of schedule but that's good, because that leaves lots of time to chat. And at this point, maybe I'll turn it over to Ted Guild on the W3C who's going to moderate a panel for us today. So I'll

Peter Rushforth: Pass it over to you, Ted.

Ted Guild: Thank you, Peter. My name is Ted Guild I am the

Ted Guild: W3C Automotive Lead and also the contact for geospatial o nthe web.

Ted Guild: And also part of the program committee for this workshop. Today, we will have a stakeholder, stakeholder panel on commercial mapping services on the web from the providers perspective.

Ted Guild: We are joined by number of commercial map service providers, who will give partial overview of their current solutions, as well both business and technical perspectives on specific challenges and opportunities they see for the global map community to consider.

Ted Guild: As we seek to make a HTML maps a first class citizen on the web.

Ted Guild: Peter at the outset, had reminded us about the W3C code of conduct and

Ted Guild: Unlike Chris Wallace in his moderation of the US Presidential Debate, I will not hesitate to mute people trying to speak over each other or trading insults.

Ted Guild: Bad joke maybe, anyhow.

Ted Guild: More seriously, like to have this an open discussion.

Ted Guild: open dialogue and my role is to try and facilitate the conversation, try and engage the various panelists

Ted Guild: To speak to each other directly and when and where possible, I'd like to involve the audience in that as well.

Ted Guild: So with that, I'll introduce the panelists and going alphabetically by last name, we'll start off with Ed Parsons from Google.

Ted Guild: Ed is the geospatial technologist at Google. He's responsible for evangelizing Google's missions, organizing the world's information using geography.

Ted Guild: He's a member of the board of directors for the Open Geospatial Consortium, was co-chair of the W3C OGC Spatial data on the web working group. Ed, could you please

Ted Guild: Further, tell us a little bit about yourself.

Ed Parsons (Google): Hi all, thank you very much Ted, it's great to have two eggs together, two eggs in in one as my mother always used to say.

Ed Parsons (Google): And yeah, I've been involved, I suppose in in geospatial for pretty much all of my career, I set up a

Ed Parsons (Google): Original HTTPD server on an old Mac in my office. When I was an academic, many, many years ago. And one of the first things I tried to do then was to put a map on to a web page using the original map tag in HTML.

Ed Parsons (Google): And I've been trying, I suppose, to make geospatial information more mainstream, more usable ever since. I think we've done a good job in doing that, up until this point in time, and I continue to do that in my job at Google.

Ted Guild: Thank you. Next we have your Johannes Lauer from HERE, Johannes works as the principle technical product manager within the department of content engineering

Ted Guild: at HERE technologies, where community map making, map content ingestion are the main fields of his interest.

Ted Guild: Johannes, Can you please tell us a bit more about yourself.

Johannes Lauer: Yes, thanks for the brief introduction, Ted. I just have to look for the mute button.

Johannes Lauer: Alright so hi everybody. So my name is Johannes Lauer as Ted mentioned I'm working at HERE technologies. Before joining HERE, roughly five years ago.

Johannes Lauer: I worked at Heidelberg University and did a lot of things about geographic data sets. OpenStreetMap, things like that, volunteer geographic information and parts of my PhD was about

Johannes Lauer: Doing sensor data analytics from agricultural machinery, building maps out of the movement and the telemetry data of tractors.

Johannes Lauer: So,

Johannes Lauer: Yeah, building the digital representation of

Johannes Lauer: The current reality into the map.

Johannes Lauer: All right.

Ted Guild: Thank you. Next, Daniel Lewis from GeoTab. Daniel's a senior data scientists working on smart cities projects and predictive maintenance projects on the data analytics team at GeoTab

Ted Guild: He's focused primarily on leveraging machine learning tools and techniques which is spatial data to create innovative products from connected vehicle data, ranging from congestion analysis.

Ted Guild: To identification that road network changes. Daniel, could you please tell us more about yourself.

Daniel: Sure. Thanks Ted. So yeah, I come into this kind of conference as a

Daniel: Very much a newbie to geospatial data and maps. My background, my undergrad is actually in semiconductor physics and my masters in biomedical engineering. So pretty far away from

Daniel: Mapping technologies, then through interest and happenstance, I ended up working in the telematics space where of course primarily

Daniel: Almost all of our data is geospatial based and been kind of on a rapid learning curve getting up to speed on this map things so it can bring a perspective from someone who's not ingrained in the field from the outset.

Ted Guild: Thank you, Thomas Lee from MapBox is currently the Policy Lead there and parse that he was leading the engineering search team.

Ted Guild: His work includes extensive use of Open Geospatial technologies and standards as well as engagement with projects and communities like open addresses and OpenStreetMap.

Ted Guild: Tom, can you please tell us a bit more about yourself.

Tom Lee: Yeah, of course. Thank Ted.. It's a real pleasure to be here. So yeah, as you mentioned, I've done a bunch of things at MapBox yesterday was my six year anniversary here actually include everything from leading the

Tom Lee: engineering team that works on our search engine to product work on the map side to being had a policy last couple of years just focused on interaction, standards bodies, and government

Tom Lee: Before this, I was CTO at the Sunlight Foundation which was a transparency org, nonprofit in the US that focus heavily on advocacy for open data, which is kind of the path that led me here. So,

Tom Lee: It's been a thrill to learn what the geospatial world is like and how it connects to the larger world of open knowledge.

Ted Guild: So as I mentioned,

Ted Guild: I'll keep an eye on the chat window if there's questions from the audience. I feel there's time we'll take them now, unless I save them towards the end.

Ted Guild: We have

Ted Guild: Our esteemed panelists have a mix of experiences, backgrounds. Some cases veterans and geospatial area and others, including myself, new to this area and are, I believe, Daniel has much more experience in geospatial than, than I do.

Ted Guild: And what I like to see is what lessons we have learned and future of mapping on the web and

Ted Guild: Including for fresh perspectives, you know, in case of people are new, this

Ted Guild: Tell us a few things that are you feel are worth sharing about where you see mapping now, or you think

Ted Guild: Things we can learn from historically, where you like to go

Ted Guild: Since

Ted Guild: no particular order. If someone feels like jumping in, feel free. Otherwise, I'll just call on someone sort of a ad hoc kind of thing. And as I said, feel free to sort of feed off eachother, you know, interchange and interact with each other as we go.

Tom Lee: I'd be happy to jump in if folks don't mind.

Tom Lee: I apologize. Everyone else here. I had put together a slide deck, because I totally screwed up trying to connect before this, I've got this whole thing loaded in my head. I just got to get it out, but I will be brief.

Tom Lee: So there are three things that I wanted to try and convey to this audience in the hopes that can inform the work is being done by the group.

Tom Lee: The first, I think, is that there's there's reason for better sense of optimism about interoperability in the mapping world than I've seen in some of the materials presented so far.

Tom Lee: I have some blinders on here because I'm really proud of the work that MapBox has done in the open on these questions, but I do want to underscore the fact that there are is a universe of open standards, either like admirably open

Tom Lee: Gone through standards bodies or just de facto ones like shape file that are sort of the PDF or Word docs of the universe that everyone can read, but isn't exactly happy about.

Tom Lee: You know, my colleagues Jon Gillies got Geo JSON through the ITF process, the official standard. The MapBox vector tile spec is used by lots of organizations, including OpenLayers like Andreas just presented

Tom Lee: It's an open spec and available to all. And in general, I think that there is like, a bit less of lock in and has been reported here, I would encourage people to check out the awesome vector tiles repo on GitHub, which lists a ton of different open projects and

Tom Lee: vendors that are using the, the standard.

Tom Lee: The second thing I want to focus on is just like trying to underscore the fact that

Tom Lee: Maps and tiles in particular, and the technology behind the classic preprocessing versus runtime trade off and people need to bear that in mind as we're considering technologies.

Tom Lee: To address this problem of use cases. There's a baseline of basically 60 frames per second cross platform performance.

Tom Lee: As well as bandwidth efficiency that have to be met if any work coming out of just going to be relevant, and that has to be cross platform. I'm afraid we

Tom Lee: restrict ourselves to web browsers on desktop usually. I'm like,

Tom Lee: Raster tiles are at one end of this where you can do a lot of pre computation but lose kind of flexibility. Vector tiles are at the other end and their various points along the spectrum.

Tom Lee: Where you can make different choices. The industry is that vector tiles now and I would strongly suggest folks.

Tom Lee: You know the raster tiles are still an essential part of the picture, if we're talking about imagery base layers are some types of pre processing, but

Tom Lee: They're not where the action is right now and really vector tiles and particular, rendering on GPU is where the industry is and where work needs to be done to push things forward.

Tom Lee: And then the final point I'll make is that I think there's a real important need for 'batteries included' approach to any proposal that comes out.

Tom Lee: Web oh sorry, Geo Data is data big

Tom Lee: Our MapBox street tile set, which is a small sort of highway use case oriented tile set

Tom Lee: It's like comparable to what you would want in your, your, you know, Google Maps application, is at least 400 gigabytes with with train data closer to 800

Tom Lee: And our satellite imagery layer is measured in petabytes, this is not stuff that's going to ship with a Firefox download, thoughts need to be given to

Tom Lee: How users who want the ease of the HTML authoring experience and deserve it, are going to get that

Tom Lee: There is a need for some level of centralization, for instance authoritativeness

Tom Lee: For dealing with licensing across geo data. And in general, I think, to make this map like compelling, it's got to get beyond throwing a simple vector data set that fits in a GeoJSON file into a browser. It's unfortunately pretty far from where meaningful use cases are

Ted Guild: Some more that, unpack some more than a little bit more later on.

Ted Guild: Ed, Johannes,

Ted Guild: Daniel. Anyone else want to jump in on this one?

Ed Parsons (Google): And I don't disagree with anything from that said there is, I think, from interoperability point of view.

Ed Parsons (Google): There are there are enough bandwidth to make sure that the the very kind of building blocks that we need to sort of build solutions now and into the

Ed Parsons (Google): medium term future are mostly there with work to do, but I think sometimes we need to sort of step back and say, well,

Ed Parsons (Google): Actually, what are we trying to do, you know what is a map fundamentally is is a communication tool for displaying a particular message, communicating something that is relevant to us.

Ed Parsons (Google): And that's going to change on a minute by minute, second by second basis, depending on the message we're trying to communicate.

Ed Parsons (Google): That in itself is only a small part of the broader geospatial industry and, you know, many cases the solutions in geospatial processing might be a yes, no decision, it might be a cell that you put into a spreadsheet.

Ed Parsons (Google): If anything, we've we've learned over the last 20 years is that geospatial industry is very diverse indeed you know the the presentations, we've seen over the last week or so

Ed Parsons (Google): In this workshop. We're seeing huge diversity of different applications people are trying to do. So I guess my initial point is around focus, I think, to make

Ed Parsons (Google): Geospatial information on the web in the browser, a better citizen, we might need to focus quite finally on a limited number of use cases, where we get the maximum benefit because there's a huge breadth of things that you probably don't want to standardize at this point in time.

Ed Parsons (Google): But there were some core things perhaps around, you know, simple static map display.

Ed Parsons (Google): That would give us initial early benefit and will allow us to move forward and there's just such a diversity here. I think that that that focus that product management approach is really important.

Ted Guild: Thank you.

Ted Guild: Daniel or Johannes

Daniel: Yeah. Again, I can't really disagree with anything that's already been said here anymore, the things that's

Daniel: Tom Lee mentioned, it was a lot more being done and exciting things and just kind of like throwing GeoJSON but that is a lot of what I actually do in my

Daniel: Day to day work but like how many smarter, better ways to integrate

Daniel: That kind of data with the actual vector map tiles for our customers is something that like I definitely want going forward. And there are cases where

Daniel: We need smarter ways to be able to do that because even sometimes we're able to show, for example, the map representation of our

Daniel: Customers data in an anonymized way, but we can't actually share the data itself and there's no easy way to do that, just overlaying GeoJSON on a map. So having better integrated ways and to dynamically generate that and such is

Daniel: Something that I would be excited about going forward, for sure. And then, yeah. Again, I can't disagree with anything, that is as well about the dynamic nature of the space, that different array of products and applications.

Ted Guild: Thank you, Johannes.

Johannes Lauer: Yeah, thank you. So I'm I'm completely aligned with all the speakers see, and around, and I think it's a super heterogeneous space where we are currently moving through so

Johannes Lauer: I think it's just the peak of the ice cube that we scratched, with mainly visualizations and some small things of mapping when you look backwards. So the whole thing about cartography, which has been made over

Johannes Lauer: decades and centuries, more or less. You see how you combine the maps and now with the maps for the web. It is changing. It's getting more dynamically, but you need all this

Johannes Lauer: Visualizations to represent the informations to have a better decision making process, make it faster. And besides that you're getting

Johannes Lauer: A super heterogeneous set of data, which is coming in that you need to process within a very short time and present this to

Johannes Lauer: The decision makers at the end. And I think there will be an evolution, which will be, yeah probably faster than it was within the last year, and the

Johannes Lauer: Request for standardized inputs and and yeah very yeah maybe agnostic way of working with with data and different data sets to represent this data to

Johannes Lauer: Be had. A whole heterogeneous set of decision makers from politicians to engineers to researchers and so on, and also for software engineers to handle the data. I think it's, it's quite broad. And we definitely need a broad set of tools for that.

Ted Guild: So, thank you.

Ted Guild: Something that

Ted Guild: you sort of touched upon was sort of the openness of data. Silos exist from commercial interests, including your own,

Ted Guild: Because costs are considerable you want us to protect those assets and quite a few of you,

Ted Guild: Are, your companies are finding ways to opening them up in various ways and forms, not just the customers but for other purposes.

Ted Guild: We also sort of often hear of silos existing within organizations as well, where different departments only know how to open up and share data with each other. People take a very narrow specific

Ted Guild: Focus on a given problem and don't think about how to architect and engineer data for for future openness and interoperability

Ted Guild: So like to sort of hear some of your experiences

Ted Guild: In that and part of it is also where the benefits of open data.

Ted Guild: I know that

Ted Guild: There's been several cases where people, some of the panelists companies here have been extremely helpful in helping various disasters.

Ted Guild: As far as looking data in real time, making available for emergency responders and governments and where it's just sort of realized the impact and sort of really sort of target their focuses

Ted Guild: As far as this will probably expect to see more of, with climate change and all the various wild fires we're seeing increased so

Ted Guild: There's a lot of information that

Ted Guild: Is being collected that can be harnessed and leveraging shared and very useful and meaningful way.

Ted Guild: So just

Ted Guild: In general, maybe a bit about

Ted Guild: experiences with silos, opening up,

Ted Guild: The benefits for opening up, including my the sort of mentioning as far as basically helping helping our fellow citizens of this planet, a little bit about your experiences and thoughts.

Ted Guild: Since Johannes the pleasure of going last, I'm calling on him first. But let's let people sort of jump in. I don't know if he's squirming too much, but your camera is still on in front of me. So

Johannes Lauer: All right. Yeah, we can start with it.

Johannes Lauer: And it would start with, and quite famous sentence which you probably all know, so the whole thing is more than the sum of its parts. So when I think that's the motivation, so that the sentences from Aristotle this. It's quite famous

Johannes Lauer: And if you're having in mind all this research project, for example, within the European Union, you have, for example, this horizon 2020 programs.

Johannes Lauer: They are companies, research institutes, NGOs, governmental institutions and so on are getting partly funded to do some projects together, which is partly research focus, more innovation focus, but also for building new ways of

Johannes Lauer: Getting money, building new businesses and so on.

Johannes Lauer: So when you see how companies are working so

Johannes Lauer: Not having the whole thing of a solution for potential customers, but also being in one boat within with several competitors and trying to find a solution. I think

Johannes Lauer: The cake of the geospatial stuff is increasing and it will be increasing for the next years or even decades, because we are still in exploring the things

Johannes Lauer: So I think we, together, you will probably get more than you will get alone within your own business and it will widen the scope and with this, interoperability is for sure one one key part, and also within our

Johannes Lauer: Our panelists here. So there. Yeah, at least two other competitors of HERE in this panel is where we have like the same fields of businesses but I definitely think that every competitor has its, its own yeah focus, and specialties that we can bring into

Johannes Lauer: Yeah, solve customer needs at the end. And I think this is something that needs to be explored.

Ted Guild: Daniel? Thomas?

Ted Guild: Any of you?

Daniel: Yeah, I can jump in there.

Daniel: I mean yeah interoperability is kind of like a key thing going through all of this. Of course, I mean, you, you mentioned a couple of things, when you were talking there, Ted. Also, I was told my mic is quiet. So someone yell at me if it's still too quiet. I'm just trying to get closer to it here.

Daniel: One of the things you mentioned was going to like social good and that kind of thing. Like, that's something that we tried to do a lot, we actually have a portal where we release a whole bunch of just open source data sets. And then there's a few reasons for that.

Daniel: It's not entirely selfless, one is like, it's an interesting kind of like business draw, but also, we find that like putting data out kind of builds up

Daniel: A couple things. One is just like partnerships and ideas of like, better ways to use our data and interesting things that we can do. Part of it is also just like

Daniel: As you mentioned, there's disaster. So our devices. The plug into vehicles. They have an onboard gyroscopes accelerometers, so you know when tremor start happening we're able to measure that.

Daniel: From from earthquakes and vehicles and when the

Daniel: Mexico one happened I think was last year, the year before we able to detect that and the aftershocks and stuff and pinpoint areas that were that were hit harder and

Daniel: Likewise with hurricanes and stuff. And we release all of that and the ability for decision makers to quickly go in and get access to that kind of data.

Daniel: Present it, make decisions based on it. So that's come up a couple times in presentations like ultimately the point of this stuff is

Daniel: The human is looking at it and wants to do something actionable, make a decision, go somewhere decide on some policy change something, so having the ability to quickly iterate on that and productize things is really important.

Daniel: And then another thing that was brought up was was siloing so that definitely happens even within GeoTab here. We've got a lot of different departments.

Daniel: Some of which are newer, older there's legacy systems. There's a lot of interoperability things over the last few years, we've migrated most of our services internally on to the Google Cloud Platform. And actually, last year,

Daniel: BQGIS came out. So we use Big Query as our data warehousing environment and they added native geospatial support into Big Query.

Daniel: So I've been told and departments at different ways of kind of storing and and managing the geospatial information.

Daniel: In different ways of trying to visualize that and play with it but just the fact of just baking in that standard into the tool that everybody uses

Daniel: Now, like, by default, if your geospatial data is in Big Query. I know it's in the right format because it's natively supported

Daniel: And that made it a lot easier to just communicate and save share data across the departments that we have here. So baking these standards and immediately starts to break down the silos, at least in my experience.

Ted Guild: Thank you.

Tom Lee: Yeah, so I, I, one of the things that attracted me to MapBox is the kind of humanitarian work folks have talked back here, the OpenStreetMap team does amazing work activating

Tom Lee: In the wake of disasters and we've been, we've been privileged to help to arrange donations that imagery from partners like Maxar,

Tom Lee: Formerly Digital Globe, but, you know, in some ways that's like, that's an outlier. I think that there is a more predictable process by which data gets open

Tom Lee: When I was running the search team at MapBox. Our coin of the realm was addressed data points. That's what we really need to provide accurate geo codes for end users for a lot of important use cases.

Tom Lee: And, you know, of course, the first thing we do is go around individual governments and see if they have them available on their Open Data Portal is really interesting to learn

Tom Lee: Sort of where the dividing line and density was

Tom Lee: You know, highly populous and economically successful areas typically have these points available for download or you get them easily enough

Tom Lee: And then more remote places that were focused on extractive industries, oil, and gas timber, stuff like that. You'd have to send in a check and then they burn you a DVD-ROM or whatever.

Tom Lee: Or they just didn't have the data at all. And, you know, this makes sense if you think about just in terms of infrastructure, if you are trying to build a road into remote wilderness to service the property, you pay somebody to do it.

Tom Lee: But it's a socialized cost downtown to maintain the roads because it doesn't make sense to

Tom Lee: You know, send everybody a bill individually except as part of their taxes. It's a piece of infrastructure, everyone can use and people, you know,

Tom Lee: If I better understanding of the same holds true for geospatial data, which is great.

Tom Lee: It means that we can expect the open offerings around the world to keep getting better and better.

Tom Lee: And partly, that's the work of governments and partly it's the work of dedicated volunteers. I just dropped a link in chat to the OpenStreetMap statistics page.

Tom Lee: And you'll see like, you know, there's millions of nodes getting added every single day to this project.

Tom Lee: Now there are other challenges with it one familiar to anybody who follows Wikipedia,in terms culture ostracizing and the welcoming this new contributors and there's also questions about new types of data.

Tom Lee: You know, the classic use case of tracing roads and buildings from satellite imagery is something that anybody can do from their armchair at any point in the world. It's harder to map turn restrictions.

Tom Lee: Or other more subtle types of data that require additional data sets aren't available in the open.

Tom Lee: Or what are frankly just really tedious require a lot of technical knowledge to do. I think there's also open questions about different types of mapping that are being done that rely on

Tom Lee: GPS sensor traces. There is a capability to upload that go with them, but the large scale collection of stuff to do things like detect real time traffic conditions.

Tom Lee: Nobody's yet figured out how to do this safely and totally open way because there's really important privacy considerations and economies of scale that you have to

Tom Lee: Cross that mean that commercial entities or governmental ones are really the ones that are in the best position to solve these problems. So

Tom Lee: There are some real challenges related to sort of the next frontier for spatial data, how are we going to get the street level imagery on an open basis refreshed frequently enough to be relevant. How are we going to get a truly navigable

Tom Lee: fully open road graph, but, you know, in general, the trend toward open. This has been great. And I think it's really super powered, a lot of the industry and businesses with people on this call.

Ed Parsons (Google): Yeah. Again, it's hard to sort of disagree, although I think there probably are if we honest limits that openness, I think, by all means. So the direction of travel is towards greater that was an openness, because it reduces friction that allows us to

Ed Parsons (Google): Interoperate, allows us to break those silos down. And when we choose to share data, it makes sharing more valuable.

Ed Parsons (Google): But I think we also have to recognize that there you know there are business models around adding value to data sets to,

Ed Parsons (Google): creating processes algorithms that use data to produce another product in other service and we need to recognize that they will coexist. And I sort of

Ed Parsons (Google): I suppose example I use. I had a call earlier on today with some people in the UK who are building an open data portal for buses, national bus routes and so

Ed Parsons (Google): Many, many years ago, a few years ago and GTFS was created as a open standards for people that wanted to publish bus and public transit information is now used across the industry by many vendors. It's a mechanism by which if you choose to make data available.

Ed Parsons (Google): It's a way that you can do that in a standardized fashion and it allows an ecosystem to then develop around that where app developers can build their apps that you know if you are passenger

Ed Parsons (Google): If you get information about how well your bus is running. If you're a provider of services to the bus operator, you can build them an app that

Ed Parsons (Google): That consumes in danger and ads you know their own management information as well. So it's those examples where you can identify

Ed Parsons (Google): Here's a case where everyone wants to get access to very similar data can we put in place a mechanism that

Ed Parsons (Google): meets the needs of 80% of that community and then allows those ecosystems to develop around that now allows you know some companies, if they wish to to to be commercial and make money out of the process.

Ted Guild: I wanted to touch on a few things that

Ted Guild: For this topic that a sort of come across

Ted Guild: Certainly for both internally and

Ted Guild: For exposing dates others in the importance of standards is one thing I heard, trying to settle on some core ontologies

Ted Guild: Or data models. There's the government entities were mentioned, there are some the richest producers of open data sets, for sure. There's also quite a bit of

Ted Guild: researchers that have taken a

Ted Guild: Tax dollars, you know, public funds, but have otherwise sort of encumbered their results.

Ted Guild: For various reasons. And as we sort of mentioned there's even though lot of commercial providers are are exposing some of their data, there's some things that they're keeping closed

Ted Guild: For temselves, but it seems like

Ted Guild: There needs to be

Ted Guild: Some way to have sort of open understanding of what data is available out there, even if it's under restricted terms, and it may be sort of multiple licensing capabilities for research purposes if you

Ted Guild: Are using this data set and what you have to do as far as giving back, for like a like a

Ted Guild: Like Apache Software license kind of thing, or what have you, or

Ted Guild: No commercial interest you know where you're doing the value add, you'd be making money off of this data, what you should be giving back know if if you're getting commercial data source. Are there

Ted Guild: Are there sort of things along these lines that can can maybe

Ted Guild: Help us to sort of figure out how to make people aware of what's available in trying to

Ted Guild: normalize the concept of catalogs and exchanges. There are some various efforts. I know

Ted Guild: National Research Council of Canada is doing a big project and that where they're trying to build huge catalogs, data lakes is their kind

Ted Guild: Of private and public sector data and not sure how much that is being used and mirrored and model for elsewhere, but if people have knowledge of things like that or ideas on

Ted Guild: What we can try to do better there in order to, people can find data.

Ted Guild: Proactively instead of, you know, when there's a crisis or when there's a business need or generate revenue streams, additional revenue streams for your companies these sort of things.

Ed Parsons (Google): I think I'm a bit of a radical in this position, and now I'm no great fan of data catalogs and for the traditional approach that we've taken as a geospatial industry for

Ed Parsons (Google): separating out the content and the metadata, we've had the meta data catalogs, we've gone down the route of creating quite sophisticated and schemas for describing geospatial content which he would go to a specialized server

Ed Parsons (Google): Come up with the query language to negotiate with that. So that, and you might identify that some data sets exists somewhere.

Ed Parsons (Google): But as a result of that, like a result of that, in many ways, artificial separation between content and the metadata about that content. It's been hard to access information that is useful and this is actionable.

Ed Parsons (Google): Unfortunately, I think, you know, things are changing. You see, you see things like the stack and you see

Ed Parsons (Google): The direct process, the direct publishing of raster data sets.

Ed Parsons (Google): In a much more accessible form where you actually are tying the meta data to the actual data itself and with a traditional search paradigm to try and

Ed Parsons (Google): Query across those data sets and to pass them in that way. It's making geospatial information more mainstream, more like any other data set that was published on on the web. And now, indeed, we're beginning to have those initial

Ed Parsons (Google): forays into a Linked Dataor approach to geospatial information, coming up with better semantics to understand how we published geospatial data. I think

Ed Parsons (Google): Where we need to do to move forward again you know is I guess that was my message is, we need to be more mainstream. We need to be much more standard citizens of the web as opposed to creating our own separate Geospatial web where we did things differently.

Johannes Lauer: Yes

Johannes Lauer: May I step in.

Ted Guild: This is

Johannes Lauer: I think the one thing is making the information available and kind of searchable. The other thing is to make it digestible and

Johannes Lauer: Make it easy to evaluate this information for for consumers, for users of the data. So you need to figure out, okay, is this data usable is, does it have and fitness for my use case is the for example the road network that is available by governmental institution or by

Johannes Lauer: MapBox or by HERE, by OpenStreetMap itself by Google, or whatever, who is the supplier is this fitting to my use case and having this in an kind of standardized way and

Johannes Lauer: Making it easy for the consumer to evaluate the data. I think in many use cases even consumers do not know about the requirements for the use case. And there is in in many things not standard way to evaluate the quality of spatial data.

Daniel: Yeah, yeah. And just have

Tom Lee: Sorry, go ahead Daniel.

Daniel: And yeah, just having the data available is like, just very simple and first step and that I mean like Statistics Canada. And like other thing other websites in the US and

Daniel: Abroad have lots of data kind of these little data lakes that they've just sort of dumped their from historical uses because they've gotten the mandate to do that, but not all of it is high quality, not all of it is useful.

Daniel: Most of it is not accessible with an API or any simple method. So like

Daniel: I've got a team of interns running around trying to scrape like open data from all these open data portals and then spend weeks, getting it into our

Daniel: Environment and then visualize it and then see half of it is useless. Like there's no easy way to get all that or to understand its utility after, until like a lot of work has been put into it.

Tom Lee: Yeah, I think.

Tom Lee: This is one of the reasons why I get very excited about some of the ideas around distributed tiles that had been discussed in earlier presentations.

Tom Lee: But it's hard for me to see it working. What do you suggest trying to, I think, for me, occasionally run into right where we can see a customer maybe wants to render MapBox tiles and route against HERE tiles and that can lead to really weird behaviors.

Tom Lee: Even just using OSM by itself, you kind of need to know which version canonical you're pulling down, you've got to have workflows to watch for vandalism.

Tom Lee: And, you know, other ways of correcting bugs, since it is a widely used database.

Tom Lee: One other thing I'll say, I'm sorry that I will always go back to address points by example, but probably should all just resign yourself to that for he next 30 minutes

Tom Lee: Is the OpenAddresses project. So there are a ton of governments in the publishing address point data, a lot of them have decided to invent their own data licenses, which is not super helpful to be perfectly honest.

Tom Lee: Others are aiming for compatibility OpenStreetMaps open database license, which is

Tom Lee: Great, because they are doing it so it can get into OSM. In practice they're political, cultural legal obstacles to

Tom Lee: Simply import there. Imagining ODBL not really used by anybody else, has known flaws and has never been tested in court.

Tom Lee: So that situation is not great, and you wind up with then standards bodies writing these gigantic hundreds of pages long XML documents about address specs that nobody uses

Tom Lee: And instead, their efforts like OpenAddresses this again. I'm biased here, you know, a few volunteers going out, finding the URLs of the dataset.

Tom Lee: Writing simple little JSON snippets would say, Okay, this is what they called

Tom Lee: The latitude column, this is what they called the longitude column, this is the projection it seems to be in

Tom Lee: This is whether it requires attribution, whether it's share-alike or whether none of that is required and you're still going to have your own lawyer to go through all this stuff, but

Tom Lee: The output of our system is a big CSV that you can import and you don't have to do this for every county in the US for, you know, every department in France.

Tom Lee: And that's, like, that's the reality of what you actually have to do to use this data, putting it up on to

Tom Lee: Government website with a bunch of metadata is one thing, and you can pat yourself on the back for a job well done. But for any user who's use case extends beyond your borders.

Tom Lee: I think that more attention to operability would be really welcome and would deliver a lot of value to your citizen users.

Ted Guild: So the geospatial or spatial data in the web is your scripts we reach our dream. They're taking up overhauling the

Ted Guild: Especially the web best practices document, and this may be an opportunity to,

Ted Guild: Without something that is not, not, you know, a confusing standard that noone adopts and does involve the various stakeholders and no one finds out about it

Ted Guild: And won't get there. Hopefully there's ways that we can try to improve where it is and prove create some baselines.

Ted Guild: Maybe an opportunity so that work is is kicking off right now, so that's an opportunity and focusing a lot on on data and sort of apologies, I guess for that, this is maps in the workshop. This is the content that's going in, in behind it.

Ted Guild: And, you know, extremely sort of valuable, necessary, is, it is, there is a wealth of information out there, but it's

Ted Guild: Hearing and heard in the past how unusableit is, and a lot of cases.

Ted Guild: And greed know, to the extent that you can keep things simple. So because you have to keep in mind the multitude of audiences producing this information. If you can sort of boil it down to something

Ted Guild: You know, kind of treading even here CSV in this day and age, but you know it is it is a

Ted Guild: Is a common denominator, is something that people can produce and readily and you don't have to submit, as you every government entities, you know,

Ted Guild: Told to open up this data in some format and their eyes will get crossed trying to figure out how. If we can find if we can give them some some basic guidance, some ways to do that, that would be a huge help. And then hopefully be able to increase it from there.

Ted Guild: We have a question.

Ted Guild: From Karel about OGC user feedback.

Ted Guild: So the spatial on the web group is a part of that. So I guess I preempted your question with the partial response.

Ted Guild: As far as what the OGC community itself is doing. But as far as the

Ted Guild: OGC/W3C joint committee which is spatial on the web group.

Ted Guild: But other other people either panelists wor in the audience that can maybe speak a little bit to that as far as what sort of feedback you're hearing on on on geospatial data in general and sorta openness.

Ed Parsons (Google): Well, I mean, I can speak from an OGC point of view, being a director, at least on the board of directors for OGC. So as you see that there's a big is a big change for the OGC in the past,

Ed Parsons (Google): I'd say two years probably, where there is now a focus of becoming much more developer friendly in terms of building

Ed Parsons (Google): APIs that are again more standardized using Swagger, OpenAPI as a design principle and making sure that you know much more of the

Ed Parsons (Google): Activity happens in the open so you see much more work now happening in GitHub, and

Ed Parsons (Google): It allows you a hopefully a more more open process. And, you know, there are still challenges there as you see traditionally has been dominated by large government agencies.

Ed Parsons (Google): I think we, OGC as an organization needs to work hard to sort of broaden it its appeal to that that wider community of users of geospatial data.

Ed Parsons (Google): As opposed to producers, that's, I guess where the the balance needs to shift a bit, but I would hope the most people on this call see OGC now as a, as a more open organization, then it was perhaps in the past.

Ted Guild: W3C went through similar transition while ago. And so, you know, this is always a balancing act and both organization are similar in their revenue models, you know, being membership.

Ed Parsons (Google): I think it is it is a recognition that it's

Ed Parsons (Google): It's more than the technology. It's about bringing communities together you know Tom made a really good point about, you know, openness.

Ed Parsons (Google): And around the complexity of licenses and I think there's still a lot of work that we need to do to come up with

Ed Parsons (Google): You know, a robust form of data licensing that parallels what we do with with software development, you know, we know

Ed Parsons (Google): What an Apache License is, we know what a GPL licenses. We don't have the same level of granularity when it comes to how we process and we publish data. So I think there's still more work to be done there,

Ted Guild: Most likely the question Creative Commons licenses, maybe more.

Ted Guild: Palpable offhand, but I'm not a lawyer, thankfully.

Ted Guild: Anyone else

Ted Guild: Have sort of thoughts on on this this particular

Ted Guild: question or topic at present.

Johannes Lauer: Yeah, I think this is a super important point. So, and it's definitely comparable to the things that you do have in the software industry.

Johannes Lauer: And you need to figure out when when you shipping software to a customer, you need to have an license compliance, so in many software products, there's like,

Johannes Lauer: 80% of the software is open source. And you have the whole bunch of software licenses. And the same would

Johannes Lauer: Be the case for geographic data sets and it would be even more complicated and having a look at all the open database or open data license models that you have,

Johannes Lauer: At least here for Germany and for all over Europe. I think in Germany every Federal State has its own open data license for the

Johannes Lauer: data sets that are given by their governmental institutions by each municipality and so on that,

Johannes Lauer: Yeah, super mess of licenses and data. And if you want to make use of that and harmonize this this data for an end to end routing, let's say, across Europe or across all over the world that is getting super complicated

Johannes Lauer: And you need to have an homogeneous handling of this licenses, of the data formats and so on. And if you then implement on top and as an in between layer. For example, a routing engine or search engine. You need to digest this data, you need to take care on the

Johannes Lauer: Different license model and this is, at the end, this is the business that HERE is doing for roughly 35 years, by providing this for automotives.

Johannes Lauer: In such a case.

Ted Guild: Chris Little provided a another answer.

Ted Guild: To this question saying that, uh,

Ted Guild: Maybe she's talking about the OGC Center for user feedback and provide the link which will be

Ted Guild: I will make sure it's part of the Minutes proceedings and it's currently in, zoom chat. Thank you, Chris.

Ted Guild: So, looking at the clock and

Ted Guild: We still plenty of time. But try and get back to

Ted Guild: GIS data is going to drive out to the web, is providing the content and

Ted Guild: But what are some business use cases that

Ted Guild: Pertain to your companies as far as what you'd like to see this, this effort this mapping community address that will help

Ted Guild: Help you become stakeholders in this activity help you help driveand shape that help with sort of considerations would you like to try and get

Ted Guild: Them to think, think of up front. What are some of the cost benefits for you instead of having to, if you can use the web browser as your, your interface your end customers, does that reduce your costs, you know, if you're leveraging the more the web stack instead of

Ted Guild: Doing proprietary interfaces, for example.

Ted Guild: What sort of, we've had quite a bit of presentations and panels on accessibility enhancements, which is extremely important part of maps on the web. How do you make

Ted Guild: How do you currently make

Ted Guild: Your mapping solutions accessible or try to

Ted Guild: See that the the importance of open standards for a harmonized approach for helping increase the accessibility of mapping on on the web. So what are some like

Ted Guild: Business cases or or things that you think may influence this

Ted Guild: This effort, this activity, in ways that you can maybe bring it back within your companies and help make the argument for why they should be involved, kind of thing.

Tom Lee: Well for us, unlocking performance is really important. There's always more that we would like to do to enable more flexibility on the client side and we're really bounded by what's possible.

Tom Lee: And this gets down to the nitty gritty of browser implementation. So this is less standards work than just getting the implementations right.

Tom Lee: This was alluded to, in Andreas's presentation on OpenLayers and some of the constraints they're facing using Offscreen Canvases. I've run into, you know, varying

Tom Lee: differences in how the performance Resource Timing API is implemented web workers across browsers which interfered with some of our benchmarking.

Tom Lee: That's like, that's pretty deep. I would say it's hard to find very many tickets about this stuff being broken

Tom Lee: But that's really important. Moving to a native implementation could really unlock some additional performance.

Tom Lee: But it's going to have to be at the leading edge and in turn that performance is going to open up

Tom Lee: new capabilities for doing stuff on the client. Like, I think I spoke too dismissively of the idea of throwing GeoJSON at,

Tom Lee: On top of the map. That is like an incredibly flexible and powerful use case, and if your data is small enough to do it that way.

Tom Lee: You can do more with the data in that form, then basically anything else. The problem is that it's not performant when you start adding too much. And so you have to do pre processing in the tiles, or other optimizations, you have to

Tom Lee: You know, rather than relying on the lovely vector drawing API as it exists in the browser, you have to try and each line and triangles in Web GL right now.

Tom Lee: Anything that can be done to unlock more performance will push the frontier forward and if standardization can be part of that, then that's really great.

Ted Guild: Anyone else want to speak on that one.

Ed Parsons (Google): Yeah.

Daniel: Percent like a lot of a lot of this stuff there go really close my microphone for me in the chat. So he getting complaints, um,

Daniel: Yeah, a lot of this stuff that we're doing now, we're like, we're coming up with workarounds around performance constraints, likes there's stuff that we could be doing with we have petabytes of

Daniel: Movement data from vehicles, like there's a ton of stuff we are doing and could do with that, but there's only so much stuff that we can put on a map with like, you know, GeoJSON rendering on top of

Daniel: Raster tiles, as soon as we get to like a couple of million points using like current implementations. It just grinds to a halt, especially because most of the renderings happening on the user side.

Daniel: And there's only so much their computers can do, especially when we're working with public sector

Daniel: Community. So that's really a limiting factor. And then, I mean, you mentioned the accessibility. So I actually just had a call this morning. We've got a mandate internally and make sure

Daniel: Every single one of our products is align with the AODA, which is the Ontario, where I live, province for

Daniel: Disability stuff. There's the ADA stuff, etc. Kind of

Daniel: How do we do that with with all of the novel, like mapping representations that we're coming up with, smart cities is not an easy thing. It's not something that's really standardized right now. So that's going to be a challenge for us, for sure.

Daniel: And then the other thing is just kind of coming back to interoperability. We're working with a lot of cities that got different data, different legacy systems, different ways that they want to look at things and

Daniel: If I've generated data sets, for example, with OpenStreetMap and they want to see it kind of projected onto Google Maps and somebody else wants to see it

Daniel: Routed with HERE or something. There's like a lot of different interoperability considerations, even in just visualizing this that I currently struggle with.

Ed Parsons (Google): I look at it from a different perspective. You know, I look at web pages as a source of data and you know let's take for example.

Ed Parsons (Google): A location of a business or hotel or shopping center, you see web page or which there may be a map presented on it but almost certainly, there will be textual description

Ed Parsons (Google): Of the address. Maybe the opening hours when I became of is you know better semantic tagging of that content on the page so that your

Ed Parsons (Google): Screen reader can read the address that they have the semantic understanding that in this case

Ed Parsons (Google): This particular store is in Ottawa, which is in Ontario, which is in Canada, then you can you ask, have a dialogue with an intelligent assistant that understood that content as geospatial information, understood the geo spatial relationships that were presented there, and could almost do that

Ed Parsons (Google): without reference to the map because the map, by its very nature is a very visual representation. If we can

Ed Parsons (Google): Have that same content expressed in other ways mean the geospatial ideas behind that information also presented,

Ed Parsons (Google): I think that's going to give as many other opportunities in the future, not just from an accessibility point of view, but from, you know, the machine to machine processing of this data moving forward.

Ted Guild: Johannes, have anything on this one or?

Ted Guild: No pressure

Johannes Lauer: Yes, fully true

Johannes Lauer: I agree with that. Yeah.

Johannes Lauer: I think, maybe, maybe one point. So, as we talked a little bit about business models or what could accelerate this behavior and also just saw Jonathan

Johannes Lauer: Put some some data into the chat of this massive database about licenses and license models which are available of this

Johannes Lauer: Somehow open accessible data sets via mainly via OGC interfaces, but also by ESRI proprietary interfaces.

Johannes Lauer: And I think this is definitely something where we need some some work on to clarify how this data can be used. We do have on consumer side safety on use this data and building business models, maybe out of that and having as a consumer and the producer.

Johannes Lauer: The opportunity to yeah, to make money out of data and building businesses on top of that.

Johannes Lauer: If the provider of the data is not able to provide an exact license of the product which is yeah being yeah open for public

Johannes Lauer: Then it's it's very unsecure to build a business case on top of that, because you don't know how the decision would be, and this is a layer which is needed to bring some safety into the market and this will also start thinking about the quality of data and figuring out what kind of

Johannes Lauer: Attributes and variables are are needed to specify to describe the data, which would go probably beyond the meter data description which is currently available.

Ted Guild: Sorry.

Ted Guild: To not, I'm using my iPad for zoom and getting some, way too many dings, apologies for that. I hope they're not coming through.

Ted Guild: They probably are.

Ted Guild: So,

Ted Guild: A big, revenue and regulations are the two of the biggest motivations for for commercial interests.

Ted Guild: Daniel mentioned ADA and the Canadian equivalent

Ted Guild: And of course these similar things exist in EU and other parts of world and

Ted Guild: Just to sort of drive home the point that I feel about, and clearly a lot of our participants do

Ted Guild: You know, it's part of this workshop, it's a sort of reminder not to, you know, not directed at the panelists, but to all attendees.

Ted Guild: That towards the day, it's not just protecting yourself from lawsuits for creating products that are not accessible as required by law. It's also keeping in mind, a good portion of your audience, your customer base. I had stats from a previous

Ted Guild: Conversation I did with someone from the Web Accessibility Initiative about how pronounced

Ted Guild: portion of the population has varying accessibility needs. So you're, just a reminder that you're sort of carry out a big piece of your, your customer demographic if you're not doing this at the outset, you're not thinking about it.

Ted Guild: Response to the licensing as far as business use cases. So we're talking, sort of combines the earlier topic, as far as data and trying to be able to license it. You know people, you know, using an open web stack and making this so that

Ted Guild: Maps for that maps to the web are first class citizen, then you can sort of tailor your products

Ted Guild: To be cheaper later and available and more platforms more readily and without having sort of port your, your custom interface because you know there'll be a browser runtime there.

Ted Guild: But it's also allowing opportunities to license, not just the data, some various services on top of it that does the value add, to other people who will be able to

Ted Guild: To take your products to next step further or to specific target audiences. It's not just accessible,

Ted Guild: Not just for accessibility means

Ted Guild: So, uh,

Ted Guild: What are some current technical challenges that you see that

Ted Guild: It's kind of worse with the business use cases of it,

Ted Guild: but any sort of,

Ted Guild: Technology challenges that you like to

Ted Guild: We've, we've actually heard several throughout this. So I guess this is sort of an opportunity to express the additional ones that you like to try and get out there and

Ted Guild: Get in people's ears and minds as they're working on maps for the web. What are some some things that you like to some challenges you face that you feel that

Ted Guild: This community will, as well as they try to make maps more prominent on the web, right, the

Tom Lee: Let me jump in Ted because you mentioned accessibility. I just talked briefly say this is one of the reasons why I think it's really important for people to engage with vector tiles as the technology, because they carry semantic content, not just

Tom Lee: Rendered visual content where the raster tiles do. They can be inspected on the client side. And you can do all kinds of things that make the map experience dramatically more accessible.

Tom Lee: Just couple weeks ago I saw somebody dissertation cross my inbox, an iOS app with extremely high contrast mode and tactile feedback to make the

Tom Lee: Make the map vibrate when your finger crossing the road line for people with visual impairments and that's possible, you know, using the exact same vector tiles, you might use to power a conventional display.

Tom Lee: So that's one of the things to make that technology really exciting. Still faces constraints though, this is one of those things that I, you know, for all the hype I do think that we're going to see some exciting things with 5G and other

Tom Lee: Technologies deployed because, you know, right now, our rule of thumb that we enforce is 500 kilobytes per tile.

Tom Lee: That limits how many languages, we can support for labels, labels, it limits the precision of geometry, limits to how many features we can include that at a given zoom level.

Tom Lee: We're optimizing around this to try and balance the incredible power you can pack into one of these things using Google's protobuf technology

Tom Lee: binary representation with a good experience over mobile networks and you know that's gonna that's gonna keep getting better. I don't know that it's

Tom Lee: I don't know everybody who's on the zoom and if any of them are responsible for the state of our wireless networks, but if you are, keep up the good work. I think we're going to get better map thanks to your efforts.

Ted Guild: Thoughts from others?

Ed Parsons (Google): I guess my wishlist, if there is such a thing is is a better positioning technology we produce quite good solutions now that work outside with a clear view of the sky

Ed Parsons (Google): But we spend the, at the moment, we spend an awful lot of time indoors, where most of that technology stops working as well. And we can't really do very well the transition between indoors and outdoors and particularly again from that accessibility point of view if you're dealing with people with

Ed Parsons (Google): limited vision, having accurate turn by turn directions delivered by, by voice both outside, inside require us to be able to position ourselves down to

Ed Parsons (Google): Less than the meter, all of the time and there is no real technological solution for doing that at scale at this point in time.

Ed Parsons (Google): There's work in progress. I think in the next five years, we will come up with those solutions, but if we can solve that problem now, that that opens up a huge range of new applications that

Ed Parsons (Google): They will regard the indoors as as as a geospatial realm, just as the same way to regroup regard the outside as a geospatial realm. I think it's a change of scale, that we're operating at that. I think that's going to be really, really exciting near future.

Ted Guild: So I haven't been there a while, I work at the status center.

Ted Guild: MIT, actually we got bumped to another building, but, um, it's a Frank Gehry building. There's not a lot of

Ted Guild: Straight lines in that place and they've tried with various NFC and other things to try and help people navigate, there's

Ted Guild: per accessbility laws they're spread all over the place, as well. But it's such that

Ted Guild: Indoors is normally a challenge. And there's ways to make even more so. There's a couple of community groups at W3C we heard from the linked data for accessibility folks before. There's also the linked building data group that's looking to

Ted Guild: They're actually more focused on building capabilities and what it sort of has to offer. Then the internal and navigation, but the linked data for accessibility folks are trying to

Ted Guild: Include data as far as what how to move within the building. What itss capabilities are, offerings, things like that.

Ted Guild: So what are a, we only have few minutes left.

Ted Guild: Give the audience, some opportunity to throw in some more questions.

Ted Guild: For us to sort of wrap up and, but in the meantime, like

Ted Guild: What are some new opportunities, some offerings that you see that

Ted Guild: improved maps on the web can bring. We personally sort of come up sort of already, but those were the last of my topics on the list. So

Ted Guild: Any sort of

Ted Guild: What do you see this this activity, possibly opening up as far as smart cities, more sort of interoperability.

Ted Guild: multimodal transportation coordination.

Ted Guild: For when we can travel again.

Ted Guild: Various things like that, you know, anything sort of come to mind that sort of, you think might be sort of

Ted Guild: Among the various killer apps that'll help sort of drive this the space or,

Ted Guild: Ah, shouldn't use killer apps. Where's the big sort of bigger picture initiatives that can can really sort of benefit from this that that might come to mind.

Ted Guild: Go on, sorry.

Tom Lee: I guess I would take it from the, from the other side, right, is that I think

Tom Lee: They are simple use cases, it should be simpler, and you don't necessarily have to bite off augmented reality or, you know, some of the stuff into the bleeding edge right, like the there are a lot of people who want to do some simple thematic mapping or heat maps or, you know, or

Tom Lee: Corn plants like, things that it would be really nice if you don't understand the difference between like the natural data set. And, you know,

Tom Lee: What OpenLayers versus Leaflet is to get up and running in your web browser stuff that you know the spammy W3Schools links should cover.

Tom Lee: I think it would be great if we could clear that bar and make the basic and generally openly licensed ADM 0 and ADM 1 geometry

Tom Lee: Ship with browsers and ideally have like wiki data links so that people can tie into a semantic universe associated data and just make like the simple stuff simple. That'll be really cool.

Ted Guild: A quick clarification W3Schools is not related to W3C

Ted Guild: We never sent a cease and desist way back in the 90s when they started

Ted Guild: But anyway.

Ted Guild: I will say,

Ted Guild: They do some good stuff though nonetheless.

Ed Parsons (Google): Yeah, I agree with Tom I think just getting the simple things right. What you know what appealed to me about this whole Maps4HTML

Ed Parsons (Google): Program and the work that Peter has been doing is, is actually making it even simpler than it is now. You could argue, well over the past 10 or 15 years we've made

Ed Parsons (Google): Maps in the web, much simpler they once were. And, you know, but actually there's still a long way to go to make it as simple as possible. And for most importantly for anyone, creating

Ed Parsons (Google): A web site, a web application doing anything in the browser to actually understand. Okay,

Ed Parsons (Google): That's a piece of geospatial content. I know what that does. I know how I can interact with that without

Ed Parsons (Google): You know, necessarily building the huge JavaScript libraries that we have at the moment, if there is a core amount of functionality to allow, someone's put a map up on a web page

Ed Parsons (Google): Have basic interactivity and put a pin on that map that makes geospatial more mainstream. That's what we should be aiming at.

Ted Guild: Thank you..

Ted Guild: Daniel, Johannes

Ted Guild: going that question, should have gone with with closing remarks kind of things as we are coming up to the top of the hour rather rapidly, but if you guys also have a brief opportunity to put something out there

Ted Guild: and just a reminder to everyone Discourse links exists on on the agenda page in the minutes or so things as far as continuing the conversation well, after this workshop

Ted Guild: Daniel, Johannes any sort of either. So we're closing remarks are some ways that what the future hold, and what are some opportunities which are meant to be kind of that topic as well.

Daniel: So yeah, just, just briefly, I guess those pile into that and then that kind of feeds into your, your question.

Daniel: Like making things simpler going forward. It's like our business model is primarily through resellers like we realized early on we can't be all things to all people.

Daniel: Maps are really complicated and our end users can't really handle a lot of that on their own. Our value like I think is in the data and the algorithms that we apply on top of that.

Daniel: We're not mapmakers, we leverage maps to display that information to our customers. And we have a whole team of people building interfaces for them to do that.

Daniel: But if there were simpler ways for our resellers to just ingest the data that we're generating for them and customize it to each of their own customers and we can be a lot more hands off on that.

Daniel: And as he's kind of standards involved to make that easier going forward. We can redouble our efforts on what our core business model is and where our expertise is and less on building up these custom interfaces for end users.

Ted Guild: Thanks. Johannes?

Johannes Lauer: Right.

Johannes Lauer: So yeah, briefly, my conclusion for the future would be making the interfaces and the interaction possibilities for end user customers.

Johannes Lauer: Is is a key thing that we, you setting the the right leverage to make it easy for users that are not in the GI science or the geospatial

Johannes Lauer: Community to step into that and make use of this data, just make it easy, and then let them explore the world because it's getting more complicated. You, you see how

Johannes Lauer: Drones are working with data, the IMU stuff. The whole D Odyssey stuff which is super important for having high precise navigation.

Johannes Lauer: And having an understanding of the quality of the data and how useful it is for my use case. What do I need, what, how, how should I evaluate the data for my special use case, and the easy access to the

Johannes Lauer: Let's say the first level, this will open the door for the broad universe of geospatial content and

Johannes Lauer: spatial temporal content at the end.

Ted Guild: Thank you.

Ted Guild: Tom, Ed, any very brief last parting words of wisdom beyond, cause lik you're answering the question and

Ted Guild: It sort of was along those lines as far as last steps and you kind of give that I can keep it simple, simple, for now, but there's any other

Ted Guild: parting things before we wrap up.

Ed Parsons (Google): Addomg anything complicates things, just keep it simple.

Ted Guild: Keep it simple. This is good, good, good thing.

Ted Guild: Tom?

Tom Lee: Yeah my copy made me talk more than what I should have. But yeah, I think, keeping it simple is a good place to start. And I really encourage everyone to

Tom Lee: Try and engage with the, I think that the open mapping community has not done as good of a job as it could have making clear how this stuff works to other web communities with important exception. I mean, I was delighted to see Ivan here to see a

Tom Lee: Andreas here, that I know there's there's important amount of overlap but there's also like a lot of work that this effort could be taking advantage of what's out there. And yeah, I'm excited to see what the proposal goes.

Ted Guild: Thank you all for the panel, for your participation.

Ted Guild: Apologies, might stop looking at the clock group because it was, you know, whether we're going around right out of time, we've gone too far by a couple minutes.

Ted Guild: Peter,

Ted Guild: You want to be to hand back over to you and see if there's any reminders you want to make before we wrap up.

Peter Rushforth: No, but I just want to thank the panel for being such good sports and participating today. It's great to engage the community and different mapping providers and so on, as Tom was

Peter Rushforth: Mentioning there. We've tried our best to keep it out in the open. I mean, no we don't have a big publicity machine, but it's a community group.

Peter Rushforth: And we are welcoming of all contributions, large and small, so yeah, how to keep it simple is not as simple as one might imagine. So definitely welcome contributions in that regard.

Peter Rushforth: And with that, I guess we should move on to our next part of our program today, which is a breakout session that's going to be led by Karel Charvat, again, about their whiteboard application technology for collaborative mapmaking over you, Karel.

Karel Charvat: Thank you.

Karel Charvat: I would like ask you if you can share

Karel Charvat: The presentation and I would like to start that I'm happy. What I heard on

Karel Charvat: The conclusion, make the things simple as I think that this is something what we see as, very important today.

Karel Charvat: To explain how we are trying to do things simple, maybe that we can discuss how to do a little more simple in the future, I would like to ask Runar if you can start with some introduction

(Stein) Runar Bergheim: I will

(Stein) Runar Bergheim: Can you see my screen is what I'm first asking.

(Stein) Runar Bergheim: Yes. Okay, so you can see something saying collaborative matchmaking

(Stein) Runar Bergheim: Okay, good. So I'm going to try and make some sort of introduction to this in. Europe, of course, it is evening. I don't know how it is

(Stein) Runar Bergheim: For how our audience distributes among different places, but I expect that during the next half an hour to hour, we're going to discuss a couple of ideas that that that we have had that we will believe, it's probably a layer above in complexity of what we've been discussing so far.

(Stein) Runar Bergheim: Where we've been

(Stein) Runar Bergheim: Sort of discussing the base enabling technologies that

(Stein) Runar Bergheim: The wiring that is required to efficiently and interopably deploy base maps. We are sort of one step

(Stein) Runar Bergheim: less sophisticated perhaps on higher higher up.

(Stein) Runar Bergheim: In the value chain, depending on how you draw up the draw the diagram between the technology and

(Stein) Runar Bergheim: End user, but okay. And we're going to divide the time a little bit between three different speakers, it's Raitis Berzins from from Baltic Open Solutions in Latvia. Karel Charvat, who is some sort of competence of the copy of all technology companies in Czech Republic.

(Stein) Runar Bergheim: And myself, Runar Bergheim. I'm from a

(Stein) Runar Bergheim: Company in Norway that didn't think that it would ever operate outside of Norway when it chose its name. So it's called Asplan.

(Stein) Runar Bergheim: Which makes many people believe that we are some sort of assembly of proctologists, which is not a good thing. and we

(Stein) Runar Bergheim: All belong to some sort of a siblinghood that goes by the name of the Plan4All Association, which is a spin off from a new year project back in the day.

(Stein) Runar Bergheim: So far back in the day that it was back when people still shook hands and said hello to each other.

(Stein) Runar Bergheim: And. And finally, it's also the intention that this should be an interactive session and most interactive sessions never turn out to be so, but we have nevertheless the discussion section on this where people should feel free to attack.

(Stein) Runar Bergheim: And

(Stein) Runar Bergheim: And or give voice their support to do whatever we say. Now, so I'm going to first try to put this into a little bit of context. And then we're going to demonstrate these two concepts.

(Stein) Runar Bergheim: And

(Stein) Runar Bergheim: So the first thing is that we were sort of encouraged by the first presentation here today, when we have this wonderful sentence

(Stein) Runar Bergheim: "And I believe this is useful for something, but I don't know exactly what" because this is sort of the universe we come from. But when we we have had a relatively small idea.

(Stein) Runar Bergheim: Of something that we think could be new and valuable.

(Stein) Runar Bergheim: And we worked on this idea, not because it was scientifically smart or because the world sort of was screaming for it. And this was a need that would sort of radically change everything universe.

(Stein) Runar Bergheim: And but once we are presenting this to the OGC which is sort of a behemoth of organizations on maps standardization and contribution to the common good.

(Stein) Runar Bergheim: We felt the need to sort of wrap what we are saying in a quasi scientific innovation. So, like so many before us.

(Stein) Runar Bergheim: We are going to try and retro actively fit a scientific rationale to our little idea.

(Stein) Runar Bergheim: And had it not been for the fact that I'm telling you this, this had might have lead us to come out in a more favorable light when you when you assess us.

(Stein) Runar Bergheim: And we are talking about collaboration, collaborative map creation and and we have become very good at collaboration, I think, I think it's fair to say over the past 20 years we have become very, very good at this.

(Stein) Runar Bergheim: With a process that has involved many of you on various stages and

(Stein) Runar Bergheim: I mean, you have made some, some of you who are global players have made decisions and choices in your organizations that, from your perspective, have been business decisions, but that propagated to a massive amount of value creation in small communities around Europe that you would never

(Stein) Runar Bergheim: Imagine that even existed, like my background here, for example.

(Stein) Runar Bergheim: And but there are a few things that are still remaining. I mean, the first barrier that was torn down was map data licensing and

(Stein) Runar Bergheim: access to high quality maps used to be used to be one prime barrier of mapping

(Stein) Runar Bergheim: But and and we had all these sort of mapping agencies that came out of the military tradition that thought that if people would gain access to data on public roads, it would immediately

(Stein) Runar Bergheim: Lead to the full collapse of national security. But then, of course, Google, our friends, started to to to publish global base maps that were

(Stein) Runar Bergheim: Better, more concurrent and and suddenly there was no sort of good political rationale for saying that we can't give you our data anymore.

(Stein) Runar Bergheim: And the second catalyst. I think that was that has been very, very successful was the web map service, but it doesn't, of course, give you access to the data.

(Stein) Runar Bergheim: And that limits a little bit the usefulness when it comes to many business cases, although it does greatly facilitate the base map delivery aspect.

(Stein) Runar Bergheim: But strangely, as was mentioned there before, I mean that there are still a couple of file formats and sharing modes that are still common state in 2020 despite being equally common in 1985 well

(Stein) Runar Bergheim: Maybe '85 but 1995 at least the shape file as has a very long life has been a difficult to kill it. And I would say that in this era of public sector information ports the .gov or list of CSV files.

(Stein) Runar Bergheim: Although technologically not particularly interesting have been the big winner, this is, this is the format that carries the most public sector information and also a surprising amount of the geospatial information. This is point data comes in this in this guise.

(Stein) Runar Bergheim: we've become quite good at sharing map applications and these applications come out of two camps as I see them now.

(Stein) Runar Bergheim: There are those that lend heavily from the professional GIS software and tried to replicate somehow on the web, what ArcGIS used to be in the 1990s, and there are those that come out of the slipping map APIs like the Leaflet, OpenLayers

(Stein) Runar Bergheim: Type of maps that that take it and what we will say, a performance approach to creating a good map experience on the web, that is not necessarily designed for people who have been working with GIS since the 80s.

(Stein) Runar Bergheim: And however these math applications they give you this challenge that they often give you a tool, they give you a blank map which doesn't necessarily look unpleasing.

(Stein) Runar Bergheim: And and it's very good. If you know what you want and if you know what you can expect to find there but it often challenges you to make this map yourself.

(Stein) Runar Bergheim: And this old time map that tells a story is nowhere to be found anymore. So we are not so adept at sharing maps as we are sharing data and applications.

(Stein) Runar Bergheim: We become quite good at creating data, our satellite missions, of course, nowadays provides so much data that we couldn't possibly do anything about it, whether we tried

(Stein) Runar Bergheim: And why Lancet, of course, as a foreigner, I'm European, I need to show Sentinel

(Stein) Runar Bergheim: But we have become quite good at this, we become quite good at creating data together too, I mean the OpenStreetMap is a ubiquitous base map.

(Stein) Runar Bergheim: Map and I think particularly the efforts of the humanitarian OpenStreetMap team shows that this methodology scales. I mean, the non centralized ad hoc data capturing to support humanitarian needs on demand, this, this is something that that works very well.

(Stein) Runar Bergheim: And this is progress. These are problems that have been solved. But once we have solved the big problems, new ones appear and they are perhaps smaller

(Stein) Runar Bergheim: less significant petty, petty problems one might say and, but user generated content as it is today is very much a dialogue between the user and the application it works with.

(Stein) Runar Bergheim: And this of course presumes that the user creates data is also the user who knows both technology GIS and has the knowledge about the local terrain where he works and and we believe there is some room to enhance this process as we will try to go on to demonstrate

(Stein) Runar Bergheim: And then looking at creation of maps together and we have become good at creating data together. I don't think we have become good at creating maps together and we don't do it. And I would say that the state of cartography in the world

(Stein) Runar Bergheim: Has shown a unanimously negative development where early maps used to be you know works of art with borders showing

(Stein) Runar Bergheim: Fanciful pictures of the waterfall at the edge of the world and here be dragons and, you know, things that are distinctly pleasing to look at

(Stein) Runar Bergheim: Today's cartography is very much more on the nature on on the on the left, they may be more useful. They may be put to better use, they may be part of common operating pictures in in operation centers but they are not beautiful

(Stein) Runar Bergheim: And we think that could be a use case for collaborative mapmaking too

(Stein) Runar Bergheim: And the reason for this is that there is five things that haven't changed as much as we could have hoped for during the last 40 years and

(Stein) Runar Bergheim: One of them is that somewhere in some deep dark recesses of most governments GIS departments in 2020 there is still some sort of a large format plotter looming.

(Stein) Runar Bergheim: And there is still a significant chunk of middle aged grey humans who are who are huddled around poorly ventilated meeting room tables.

(Stein) Runar Bergheim: peering over some sort of a printout of a map appointing and stipulating and spilling coffee and cookie crumbs and whatever they do in this process.

(Stein) Runar Bergheim: That invariably annotating these maps by markers and they're pointing the fingers a lot to explain what they mean. And finally, this is hand over to a GIS specialist who then has the very hapless and

(Stein) Runar Bergheim: tragic fate of trying to distinguish what is the chocolate chips smudge and what is a new development area that should be adjusted in this map.

(Stein) Runar Bergheim: And thus, maps are still edited collaboratively in 2020 so we think that is the room for some improvement there and if 2020 so there's anything

(Stein) Runar Bergheim: Except that when it rains, it really, really pours, it is that a lot of physical meetings were are and hopefully shall remain non essential

(Stein) Runar Bergheim: And even those of us who are most opposed to progress have been forced to find some sort of way to live with online cooperation in this year.

(Stein) Runar Bergheim: And so we think that some sort of evolution of of sharing technology could be apt at this moment in time. And we're looking at some sort of a client to client map data creation that allows for a better experience in this way and possibly better quality.

(Stein) Runar Bergheim: And so I think this is the question that would form yourself in your mind as you hear me drone on about this, there is a

(Stein) Runar Bergheim: Distinctive first world flavor to the type of problems that I have listed here. This is not something that is going to solve world hunger or anything like that but it rings, a little bit of this first presentation of what 'we think this could be useful'.

(Stein) Runar Bergheim: 'We don't know exactly how but we think it could be useful'.

(Stein) Runar Bergheim: So we leave you to judge whether that is so or not. And we will move on to introduce the two different concepts.

(Stein) Runar Bergheim: And the two are,

(Stein) Runar Bergheim: And

(Stein) Runar Bergheim: And interoperable way of describing storing and exchanging a map and, in this context, we're not talking about the map tiles or the rendering of it as such but

(Stein) Runar Bergheim: What can you say a portable equivalent of the project files from QGIS and ArcGIS and whatnot. Something that would draw heavily on

(Stein) Runar Bergheim: The obvious context or the that map context standards that that were created far back, but that doesn't gain a lot of enthusiasm these days, although they are in use.

(Stein) Runar Bergheim: And the second part is a client to client some technology platform to enable client to client interactions for common JS tasks and for these two things we have given some names 'Map compositions' and 'map whiteboards'.

(Stein) Runar Bergheim: So the first thing we're going to talk about is the map composition and that I'm going to hand over to Raitis, I will still operate a computer, I think so. I will be clicking the forward key, but I think Raitis will speak up. So you're just telling me when you want the next slide.

Raitis Bērziņš : Okay, thank you Runar.

Raitis Bērziņš : Can you hear me.

(Stein) Runar Bergheim: I can hear you. Yeah.

Raitis Bērziņš : So yeah, I'm Raitis, representing Baltic Open Solution Center, and I will tell you a little bit more about the compositions

Raitis Bērziņš : So, next slide please.

(Stein) Runar Bergheim: Yes.

Raitis Bērziņš : Um, well, as Runar mentioned, map composition can be looked upon as a project files and they are kind of a canvas on which we can

Raitis Bērziņš : Draw the feature so, add some new elements and

Raitis Bērziņš : If they have been developed, gradually, together with the the open source components which are listed at the bottom of the slide, namely HSLayers layers,

Raitis Bērziņš : Which is a UI extension of OpenLayers.

Raitis Bērziņš : And

Raitis Bērziņš : Micka metadata catalog and Layman for uploading shape files and converting them into WMS services.

Raitis Bērziņš : But actually the origins of the map composition were very humble. We just needed a way to store the context, context of the current Web Map between reloads of the page.

Raitis Bērziņš : So later on.

Raitis Bērziņš : First we had some layers and then we added the possibility for the users to draw some new features on the layers. And later on

Raitis Bērziņš : To add more layers to the map.

Raitis Bērziņš : But when the pages were reloaded. Everything was

Raitis Bērziņš : erased and user had to start from scratch. So we needed to save it somehow. And from this capability we have had developed it

Raitis Bērziņš : We created a way to share this context.

Raitis Bērziņš : So we just had to tell one parameter in the URL of this map application and the user of the GeoPortal was able to share this context between other users.

Raitis Bērziņš : And this composition could be exported to the metadata catalog main which also can at least have different WMS services or some raster images and so on. And these kind of data layers could be then

Raitis Bērziņš : Mixed in various configurations

Raitis Bērziņ: and shared. Next slide.

Raitis Bērziņš : The map composition format

Raitis Bērziņš : Is very much based on the old

Raitis Bērziņš : Web OGC Web Map Context and it's later success successor OWS context. But what we have done is to

Raitis Bērziņš : encode the data into JSON format, so it's easier to parse in the

Raitis Bērziņš : Web applications which we have been developing, developing in JavaScript.

Raitis Bērziņš : So it's easier implementation.

Raitis Bērziņš : Next, please.

Raitis Bērziņš : And here is an example of map composition and on the right side you can see the structure of it.

Raitis Bērziņš : It's, it's very much resembles the OWS context but it in a in a more simplified form. So what you have here is some basic, basic attributes describing the context of the whole map or the container like description and current extent of the map and

Raitis Bērziņš : Current selected base layer because there can be only one of them and the map projection based on upon which the application can decide whether to reproject the layer or not

Raitis Bērziņš : And also some information about the permissions. So

Raitis Bērziņš : The application then can decide whether to give right permission to the users, we try to mimic the Linux file system using this and then the main or the most important part of the map composition is the list of layers

Raitis Bērziņš : Where the order of layers matters. So the first layer in the array is considered to be the bottom one.

Raitis Bērziņš : And

Raitis Bērziņš : Yeah, so then continues the actual list of layer definitions and it consists of basically two parts. The parameters which are sent to the server request.

Raitis Bērziņš : Either that is WMS or WFS or different kind of

Raitis Bērziņš : Web service and also the parameters which are used by the client side application. Currently we have implemented the map compositions

Raitis Bērziņš : On top of OpenLayers and also some experimentation was done on Leaflet.

Raitis Bērziņš : So these kind of client side parameters could be

Raitis Bērziņš : Single tile attribute

Raitis Bērziņš : Which tells the application there to request the tile as as one tile for the whole

Raitis Bērziņš : Whole Map window or it will be

Raitis Bērziņš : separated into different smaller tiles

Raitis Bērziņš : And of course the visibility of the layer or transparency or opacity.

Raitis Bērziņš : And so on. And for WMS layers, we can request the legend graphics from the web service itself, but for some static layers.

Raitis Bērziņš : Or static images we have to also provide an array of legends.

Raitis Bērziņš : And same four dimensions.

Raitis Bērziņš : So at the bottom of the slide you can see the the the URL of the schema of the map composition, but that is basically only meant for validating the composition against

Raitis Bērziņš : A schema, which could be used on HS Layers

Raitis Bērziņš : Map library so if if some other

Raitis Bērziņš : geoportal solution would

Raitis Bērziņš : Use this composition format, then of course it could have different schema because it could support different kinds of layers and different parameters for them.

Raitis Bērziņš : Next slide please.

Raitis Bērziņš : The main attribute, which is present for all the layers apart from the URL, of course, is the class or type name of the layer. we currently support WMS, WFS

Raitis Bērziņš : And

Raitis Bērziņš : Vector layers. And vector layers is interesting that

Raitis Bērziņš : The end result is a vector layer, but the data can come from different sources. For example, it can be GeoJSON file or it can be a WFS request or it can be also

Raitis Bērziņš : Added from Sparql endpoint or KML.

Raitis Bērziņš : And we can. We also support x, y, z players for OpenStreetMap, Bing Maps and Google Maps and ArcGIS rest layers that also supported. The last three types of layers are

Raitis Bērziņš : Derived from the layer definitions of OpenLayers.

Raitis Bērziņš : Next, please.

Raitis Bērziņš : Vector layers are

Raitis Bērziņš : Subdivided by protocol property.

Raitis Bērziņš : But

Raitis Bērziņš : We could support for example Sparql endpoints, and what we try to do in this example. This image was tried to load the data from Sparql endpoint

Raitis Bērziņš : It's a five star open linked data

Raitis Bērziņš : Format or endpoint from with also where the data

Raitis Bērziņš : Comes described, where the data is described in the,

Raitis Bērziņš : where the metadata data is contained in the data which comes from the Sparql endpoint itself. So it's not separated

Raitis Bērziņš : But everything in one package and it's easy for the developers to then go deeper to explore the semantics of the data.

Raitis Bērziņš : And it was also this topic touched in, the panel discussion before

Raitis Bērziņš : But for vector layers. The support this single type of

Raitis Bērziņš : Data as JSON format.

Raitis Bērziņš : And yeah, one of counterintuitive, but quite useful capability is the store GeoJSON encoded features directly into the composition, as opposed to having a link to some external file or service. This was intended for temporary low volume data such as scratch layers

Raitis Bērziņš : Or some layers, where the user can freely draw some features

Raitis Bērziņš : Or take notes. For example,

Raitis Bērziņš : But we discovered it quite useful in the map whiteboard application which we are developing

Raitis Bērziņš : And when this scratch layer is being populated by user at some point the features could be stored or sent to some WFS service or the Layman application which, as I was mentioning before,

Raitis Bērziņš : Which converts

Raitis Bērziņš : Data either the shape file or GeoJSON vector data into WFS services and it serves them with geo

Raitis Bērziņš : geo

Raitis Bērziņš : Geoserver so

Raitis Bērziņš : So at the end, the features can be merged from the whiteboard server into this map composition and then requested by the user using just one request, for example where this, the application.

Raitis Bērziņš : Just gives them an idea of the composition and then

Raitis Bērziņš : Your turn gets back that the whole composition description with the metadata, the layer definitions. They can be vectors and vector features or they can be pointers to WMS or WFS services and also the features which have been drawn using the map.

Raitis Bērziņš : Yeah, that's all from me.

Karel Charvat: You didn't mention one thing that through Miska and Layman, this composition can be shared also with QGIS as desktop solution and also from QGIS you are able to publish sitemap composition

Karel Charvat: Into catalog, which could be also shared with web environment.

Raitis Bērziņš : Yes, that's some kind of late development,

Raitis Bērziņš : recent development, we have been developing QGIS plugin for creating this vector layers and complete map compositions actually can be created in QGIS, and then export it to the Layman and converted into lists of layers, WMS layers very easily and published

Raitis Bērziņš : But it's still under development so

Raitis Bērziņš : But going well.

Raitis Bērziņš : If anybody's interested. It's available on GitHub. If you search Layman or HSlayers for that matter.

(Stein) Runar Bergheim: Okay.

(Stein) Runar Bergheim: So then we might move on to say something about this map whiteboard which we've been referring to a lot now, but which we haven't actually told you what it is.

(Stein) Runar Bergheim: And I can, I have very unfortunate

(Stein) Runar Bergheim: Situation of having developed a cough, which is not a good thing nowadays. And if if nothing else, you stand at risk to be rolled in tarred and feathered by your neighbors, but I hope you will bear with me.

(Stein) Runar Bergheim: I can also see from the camera here that I have turned purple. But I think that's more a question of lighting than really general health condition. So hopefully you shouldn't be too worried by the fact that I'm coughing

(Stein) Runar Bergheim: And Map whiteboard as such is not a patented term if it is, it's not patented by us. It doesn't mean anything except whatever you put into the

(Stein) Runar Bergheim: Your own associations.

(Stein) Runar Bergheim: However, for the purpose of tonight. It is or today, I should say, to be slightly more globally inclusive, and it may be considered to be a peer to peer technology.

(Stein) Runar Bergheim: That allows map interactions and modifications to be to be propagated from one connected with client or other connected all other websites.

(Stein) Runar Bergheim: Why they're looking at the same map. So when someone moves the cursor. I can see it on my screen when someone draws a feature I can see on my screen, I can edit the features they've drawn. They can edit mine, we can add layers to the maps and they will show up for all of us, and so on.

(Stein) Runar Bergheim: So I had uploaded here a now. Okay.

(Stein) Runar Bergheim: What, why, why did we want such a thing.

(Stein) Runar Bergheim: The first thing is that

(Stein) Runar Bergheim: In the early days when we saw

(Stein) Runar Bergheim: Sort of the the business cases for GIS with with moving things on screen. We were very

(Stein) Runar Bergheim: enticed by this idea of seeing things moving, rather than just a static maps. And we saw that these fleet monitoring thing.

(Stein) Runar Bergheim: We had GPS transponders on trucks and taxis that allowed you to see where things were. This was very, very pleasing purely from a technical point of view, very pleasing. We don't own these taxes. We don't don't these companies. There was nothing in it for us. It was pleasing.

(Stein) Runar Bergheim: And so more relevant to our own lives, of course, we've been using Google Docs a lot for collaborative

(Stein) Runar Bergheim: Development of documents.

(Stein) Runar Bergheim: And that is a very closely related discipline, when it comes to certain things. And we've been writing documents and we had the pleasure of seeing, you know, working multiple parties on the same things without causing any sort of

(Stein) Runar Bergheim: The,

(Stein) Runar Bergheim: conflicts among our texts and we would like to see the same thing in Maps.

(Stein) Runar Bergheim: We also been working on user generated content, and we have been bothered by the fact that it's always one person or two people sitting physically together in the same room.

(Stein) Runar Bergheim: Working towards one client application, whereas this possibility of cooperating would require some sort of screen sharing online conferencing tool.

(Stein) Runar Bergheim: So we like that and it would still allow only one person at a time to to to work in the map. And so we thought you'd like to see something like that.

(Stein) Runar Bergheim: And then of course we have this irrational decided to see things move on the screen.

(Stein) Runar Bergheim: And I have tried to make a small video of this and I saw that that one wouldn't play so I will try to play it. I will try to change the different window and play it there.

(Stein) Runar Bergheim: And this is no bells and whistles. Nothing. Nothing particularly exciting, but just for the purpose of illustrating the concept made, two full screen map surfaces. These are rendered in opens in OpenLayers.

(Stein) Runar Bergheim: We have made the same client for Leaflet because it's not necessarily meant so that this needs to work in one technology or another, it should work on any any platform.

(Stein) Runar Bergheim: But I'm going to start playing it now and see if you are able to see anything. So the first thing is that when I move my cursor in one map,

(Stein) Runar Bergheim: The people connected the map can see where I am and each person is assigned that unique color. Now I will ask this question, can you see my screen still?

(Stein) Runar Bergheim: Can you see the video playing?

(Stein) Runar Bergheim: Very good.

(Stein) Runar Bergheim: Because otherwise this will be

(Stein) Runar Bergheim:Just

(Stein) Runar Bergheim: Additional fog. Okay, so every cursor is assigned a different color. And when I move in what my connected client, my counterpart can see my cursor with it with a specific color so that

(Stein) Runar Bergheim: Essentially

(Stein) Runar Bergheim: Takes out the

(Stein) Runar Bergheim: Business Case of

(Stein) Runar Bergheim: Pointing with your fingers when you're standing around this map around this paper map on the table.

(Stein) Runar Bergheim: So then the second thing is that I can create data and immediately when I create this data they show up at all connected clients.

(Stein) Runar Bergheim: And I can connect, create or simple features according to the simple features specifcation, I mean, this just depends on the implementation that the transfer of data is using

(Stein) Runar Bergheim: GeoJSON, might be that we should go to some more compressed thing because

(Stein) Runar Bergheim: The volume here could easily drive up traffic but you're able to create geometries of any, any kind, and we are able to see that they show up and when I have created the geometry,

(Stein) Runar Bergheim: A person can go to that geometry and modify it in the other window. So we have read write access to all features that we have created collaboratively.

(Stein) Runar Bergheim: And and the same mechanism.

(Stein) Runar Bergheim: Applies for property. Property property editing, so attribute editing and also for adding another layer

(Stein) Runar Bergheim: To the, I don't know what's happening there, also for adding another layer to the map. So if we are sitting in this sort of a map user context in a government department and

(Stein) Runar Bergheim: We are we are assessing some some map. We can say that 'okay we need, we need some supporting information I can add to the WMS service from my side or or a shape file' or whatever and then immediately be visible to all other users as contextual information that can be turned on and off in the map.

(Stein) Runar Bergheim: And similar things and then we can we can see as data too. So we are able to both author the maps themselves and the cartography as well as the data content of the maps.

(Stein) Runar Bergheim: And that satisfies a number of business cases that we

(Stein) Runar Bergheim: Many of our customers are suffering from and that is a bigger problem for them in the era of COVID-19 than it was before. When they at least had the opportunity to meet in these very small meeting rooms of theirs.

(Stein) Runar Bergheim: And their technical architecture of this

(Stein) Runar Bergheim: Is based on

(Stein) Runar Bergheim: HTML5 client,

(Stein) Runar Bergheim: Could be could be of course desktop clients, QGIS, ArcGIS, or whatever I mean any sort of connected client or it could be rendered on on MapML for that in the future and

(Stein) Runar Bergheim: These could be implemented using any any library we have so far just implemented this for an OpenLayers and and Leaflet and something some branches, I should say some branches of OpenLayers

(Stein) Runar Bergheim: And in addition to standard OpenLayers. And then, initially we thought of just having this as a standalone editing technology that that only allowed you to edit vector geometries and in our, in a random GeoJSON layer.

(Stein) Runar Bergheim: But then we had in peril, this map compositions format which which has great overlaps with the old WS context and so on, which is might be questionable, but we had that one in our stack.

(Stein) Runar Bergheim: Because we just described, we needed it for some some projects. So we thought, okay, maybe, maybe it would be neat to be able to edit both the vector layers themselves and to edit the map. So we chose to use the map composition as the carrier

(Stein) Runar Bergheim: And in terms of lightness of load, because here, there's a lot of messages going back and forth between the client and the server, and then being distributed again.

(Stein) Runar Bergheim: We chose GeoJSON because it's fairly light,

(Stein) Runar Bergheim: fairly light way of encoding data,

(Stein) Runar Bergheim: So the server part of this,

(Stein) Runar Bergheim: Has

(Stein) Runar Bergheim: Documented API. It's written in node.js and socket.io yeah and it would typically be hosted behind some reverse proxy when it is in a production environment.

(Stein) Runar Bergheim: And and immediately when my cursor moves, of course, there goes a message to the whiteboard server that user so on so connected to map so on so

(Stein) Runar Bergheim: has moved this message is immediately propagated to every connected client and the state is synchronized on each client independently.

(Stein) Runar Bergheim: But of course, if a client falls out and reconnects that it's necessary also to synchronize this on the server. So we have

(Stein) Runar Bergheim: State management in MongoDB, that sits behind this. So, whenever we make any sort of map update is immediately flush to MongoDB. So there is a completely updated version of the GeoJSON and all of the map composition sitting on the server at any time.

(Stein) Runar Bergheim: So if you if you connect and disconnect and come back. Nothing is lost, it remains.

(Stein) Runar Bergheim: And there is of course a few issues here also, because if you want to have. I mean, this is a far less demanding technology that is what is it, it's not basic infrastructure like what what the early presentations here described this is sort of an edge feature and application.

(Stein) Runar Bergheim: And but still it has some performance issues because

(Stein) Runar Bergheim: If you would like to have smooth cursor movement and very very

(Stein) Runar Bergheim: Responsive interfaces, you would need to transfer data on personal positions in roughly every 20 milliseconds, like this.

(Stein) Runar Bergheim: And that leads, of course, to a lot of data being sent back and forth. So even GeoJSON might be might be too bulky for this. So you might use something like a protocol for something like this to to speed up or minimize the data that are being that are being transferred

(Stein) Runar Bergheim: And

(Stein) Runar Bergheim: This is a very simple thing.

(Stein) Runar Bergheim: But surprisingly, of course, an API that should be able to handle this on the server side needs to include quite a lot of stuff and

(Stein) Runar Bergheim: We have to have user management. I shouldn't mess up your map, you shouldn't mess up mine. And so even though we allow people to collaborate, we need to have the same permission model as exists in in

(Stein) Runar Bergheim: In Google Docs, where people can have read access or editor access or comment access, suggest access and so on.

(Stein) Runar Bergheim: We need to document management needs to be able to upload and download these things and control who can do it and we need methods to handle

(Stein) Runar Bergheim: Streaming of all these interactions.

(Stein) Runar Bergheim: From the server to the connected client and the server doesn't really care very much about the rendering of this

(Stein) Runar Bergheim: It cares just about propagating messages.

(Stein) Runar Bergheim: But it needs to have some basic level ,so features and properties are represented as GeoSON features are stored in layers layers are stored in map compositions and map composition are rendered as maps on

(Stein) Runar Bergheim: Their users have cursors that move on the map. Whenever move or hover interaction hover event is detected, it's propagated all connected clients.

(Stein) Runar Bergheim: And users can add layers to the map and shift the layer order which will also cause the same to happen on all connected clients, but only for the specific map that they're connected to, of course.

(Stein) Runar Bergheim: So that is the essence of this little feature.

(Stein) Runar Bergheim: Now is this something to talk about to the OGC is this really a standardized interaction protocol or is it an application feature I can't say with great certainty, if map white boards have a potential beyond being a feature.

(Stein) Runar Bergheim: But it is something that

(Stein) Runar Bergheim: Is fairly interesting to the day to day business of many of our, our clients and people who are collaborating across government departments.

(Stein) Runar Bergheim: Find this intriguing and and have have started to sort of express interest in in buying it and

(Stein) Runar Bergheim: More politically, they buy it integrated into their solutions.

(Stein) Runar Bergheim: And the people who are operating field data capturing applications where typically one professional is trying to have a dialogue with a non professional, find this interesting because it allows one person to have a dialogue with another one

(Stein) Runar Bergheim: While they can see the same thing on the map and they can point, one person can create data. One person can indicate his local knowledge, while working in the same

(Stein) Runar Bergheim: So perhaps they do. The API that we are making at least would be open and published as an open specification. It's not an open specification, but it will be published as as an open thing and whoever might find it interesting could contribute to it, evolve it or slaughter it at will.

(Stein) Runar Bergheim: And but then again standardization should not be applied where standardization is not due, so I'm not sure if this is something that we should tout as a standard thing. But I think it's something that is

(Stein) Runar Bergheim: Relatively interesting, but the discussion section that we have some time for now, 12 minutes, I suppose, specifically, is devoted to the value proposition of this and and I think the discussion should be centered on the value

(Stein) Runar Bergheim: Creation, rather than revenue creation. I mean, if this can add value to someone or something. It's a good

(Stein) Runar Bergheim: If it can create revenue that's perhaps interesting but it's not interesting to discuss in a group. And so let's stick to the high road and the nobler goals.

(Stein) Runar Bergheim: What can we do in terms of creating value. And with that, I shall remain silent. I think and hand the road back to Karel who will moderate this Chris Wallace style. There was no

(Stein) Runar Bergheim: tokens of obvious violence in the first section. So I imagine this would go well. And this last twelve minutes or so.

(Stein) Runar Bergheim: So Karel, yours.

(Stein) Runar Bergheim: Are you still there Karel?

Karel Charvat: Sorry, I was mute.

Karel Charvat: One thing is to discuss about potential

Karel Charvat: Technology can be used as

Karel Charvat: What

Karel Charvat: Is my job and I am the most involved is

Karel Charvat: Farming. And what we see that

Karel Charvat: There are discuss usage of as observation data and other data and the

Karel Charvat: Farmer is never using directly

Karel Charvat: Data and never processing this data. So there is usually some interesting chain or the people who are preparing for data and preparing recommendation.

Karel Charvat: On other side to the most of farmers hate to work with black box and to be not able to understand why they have to do something so

Karel Charvat: There is really necessary that the for example advisor, who's preparing some recommendation for farmer, has the possibility to communicate with the farmer, exchange with him

Karel Charvat: The result, ask him for the comments and in some cases farmer is telling. Okay, I know that this part of the field has different

Karel Charvat: Behavior and please I would like ask you to change the parameters for, for example, applying of nitrogen in this field and this could be the way how

Karel Charvat: That could be communicate, of course, I think that the typical things which could be used is any type of planning because usually

Karel Charvat: Planning is based on the fact that planner is preparing some plan, then it is discuss with public servant if there is, for example, spatial plan, then it is discussed. So is people usually the way sides that the plans are in

Karel Charvat: Better case visible on the internet, worst case you have to go to the office and to draw on the maps, what is necessary.

Karel Charvat: For education, I think that it is also very good

Karel Charvat: Instrument.

Karel Charvat: We see the potential in some type of the crisis situation where the

Karel Charvat: Person who is managing the team can online, put some information for for the user. So there is the number of potential areas where we are thinking and we are now trying to apply this technology. And generally, we will be interested about your ideas next.

Peter Rushforth: Are you willing to take questions?

Karel Charvat: Yeah. Yes, yes, we can, yes, you can have some questions, we are ready to answer.

Peter Rushforth: Great. Well, I have a question from Bryan Haberberger, The Habes in Gitter, says you have essentially done everything besides contextualizing your data. Have you looked into producing five star data.

Peter Rushforth: And he provide a link so

Peter Rushforth: Five Star Linked Data.

Karel Charvat: I think that

Karel Charvat: Right. This mentions that

Karel Charvat: We are able to visualize Five Star data. Yes, he mentioned that we are able to read the idea of data. Other things is that our metadata catalog

Karel Charvat: It is based, initially, it is based on is all this 19150 and 1939 standard, but the this Miska is also supporting meta data in

Karel Charvat: Geo cut IP saw this five stars meta data, we are working, we are moving in this direction and also know we have some data which are five star like part point of interest. And this is the reason why we are trying to do this. So we are moving to the five star.

Peter Rushforth: Okay, thanks. So

Bryan Haberberger: I just wanted to say thank you, I'm Bryan. Thank you.

Bryan Haberberger: I'm glad, I'm glad that catch the question didn't catch you off guard. I was actually expecting something different. I'm glad you guys have thought about it.

(Stein) Runar Bergheim: And we have in this Plan4all Association, which we we have introduced a terrible amount of concepts without this explaining what they are here, but this Plan4All Association, we have among others, a few big linked open data sets.

(Stein) Runar Bergheim: Which are, where are some of the content is the content varies between three and five star according to the standard, and we are trying to use, among other things, this technology in

(Stein) Runar Bergheim: A coordinated user generated content effort to complete, increase the quality of the data.

(Stein) Runar Bergheim: To to achieve five star data. So it's, it is close to home in terms of our, our day to day problems.

Bryan Haberberger: Yes, that's, that's good to hear. How have you looked at the GeoJSON LD specification. Because essentially, if you get

Bryan Haberberger: You get, you get five star data for free with that context.

(Stein) Runar Bergheim: Yes, yes, the

(Stein) Runar Bergheim: Only problem with with every,Yes, yes. I mean, it's, I agree fully. The only problem with standards is that

(Stein) Runar Bergheim: When we work on developing standards we always, we always become very happy when the standard is finished. But once the standard is finished, we have to populate it so so the population part is

(Stein) Runar Bergheim: Not going as fast as the standard. But I think the standard is definitely

(Stein) Runar Bergheim: It's definitely helpful.

(Stein) Runar Bergheim: To to allow us not to make some sort of massive duplication of effort.

Bryan Haberberger: Yes, definitely. And all it would do as it exists, is provide that modular support for the GeoJSON and you guys are doing something much more in supporting other formats, which obviously GeoJSON LD would do

Bryan Haberberger: Nothing for you for this thing, your, your context is much more complicated than just that simple web context for the GeoJSON format.

(Stein) Runar Bergheim: It is. It's conceivable but then again, I think what we are doing is probably a great deal less complicated than it sounds like, and it's

(Stein) Runar Bergheim: part by the fact that we have been given an hour to talk about it and we are very intimidated by the presence of all this greatness

(Stein) Runar Bergheim: In the audience. So we feel the need to wrap it in in scientific sort of rationale. But what we, what we're doing is fairly simple.

(Stein) Runar Bergheim: shamefully so in comparison with much of what you're doing, but it is sort of a connectivity between what happens on the infrastructure level and the business value that we still think is an interesting part of the value chain, but it might, it might not be

(Stein) Runar Bergheim: It might not be on the same precision level as as as what happens in the great strategic decisions of the world.

Bryan Haberberger: Thank you. It was great to see. And that was that's that's the gist of what I wanted to say.

Peter Rushforth: Well, thank you very much for your discussion and presentation.

Karel Charvat: Maybe Runar can you go, in a slide deck.

(Stein) Runar Bergheim: I think I can, think that should be within my cognitive abilities.

(Stein) Runar Bergheim: This one you mean?

Karel Charvat: No no no no, this one.

Karel Charvat: Because this

Karel Charvat: This development is now included as a part of so called COVID INSPIRE hackathon. It is the UN, which is running two months and the first what Raitis presented in his talk, in this first challenge and the second is

Karel Charvat: In this challenge. So if anybody will be interested to discuss these things with us, we will be very happy to invite you and to continue in the discussion because this development will continue.

Karel Charvat: One month and as we mentioned, we are not only trying to finalize the solution, but we are also looking for different business cases. So if you'd be interested, we can share with you more details.

Peter Rushforth: Do you want to share the links or,

Karel Charvat: In the presentation.

Karel Charvat: presentation will be available this are the links, I can, I can send or I can share a link later because this is a presentation will be available, it is

Karel Charvat: Possible to go.

Bryan Haberberger: If it helps, I just went to the agenda, and I was able to download the PowerPoint. So I have those links now.

Bryan Haberberger: Okay, they already have it up.

Bryan Haberberger: I think I'm pretty sure that's what this is.

Peter Rushforth: Great.

Karel Charvat: Okay, I think that if there is no more question, I think that our time is almost over Runar, you expected that we will be shorter, but seems that we use all our time.

(Stein) Runar Bergheim: Well, I don't think there's anyone who will cry for this. I think

(Stein) Runar Bergheim: People will fall asleep tonight with a ringing, ringing of our voices in their ears and wondering why. So I think we should have preemptively apologize to those and thank everyone for attending.

Peter Rushforth: Thank you for presenting a very interesting application. It looks like it's going to be a winner.

Peter Rushforth: So I guess with that, we can, we'll sign off.

Peter Rushforth: Unless there's some more messages, there's links in the chat that if you want to have a look at those.

Peter Rushforth: And so we can end the recording and we will post the recordings, as soon as possible and talks as you submit them. So thank you all for participating today and tonight.

Peter Rushforth: And have a good day. We'll see you tomorrow.

Karel Charvat: Peter, thank you to give us opportunity to make to present our works. Thank you very much.

Peter Rushforth: Lovely.

Bryan Haberberger: Thank you. Yes, thank you, all presenters. That was a great day.

(Stein) Runar Bergheim: Thank you very much. And the best of days to you.

Peter Rushforth: Awesome.

(Stein) Runar Bergheim: I shall return to pine for the fjords

(Stein) Runar Bergheim: Bye.

Karel Charvat: See you. Bye.

Peter Rushforth: Bye bye.

Raitis Bērziņš : Bye.