Peter Rushforth: Well, welcome everyone to the day two of the Maps for the Web workshop, the joint W3C OGC maps for the web workshop, I'm Peter Rushforth and I'm pleased
Peter Rushforth: that you've all joined us today.
Peter Rushforth: We have a very tight schedule.
Peter Rushforth: So we'll be pretty strict about the times for for talks. But before we get there,
Peter Rushforth: I would just like to mention that there are
Peter Rushforth: The few web links that we have to share. We try to make the sessions as interactive as possible without running
Peter Rushforth: over each other. So we have a Gitter chat room that there, everybody should hang out in and Ted will paste that link into the chat, has pasted it here into the chat and
Peter Rushforth: Each day, I will, I will post the the slides and and materials for the presentations, shortly before the presentation so as to not give the give the whole story away before the for the story is told. And then as that.
Peter Rushforth: After the after the presentation, I'll create a
Peter Rushforth: Discourse
Peter Rushforth: topic for discussion in the Web Incubator Community Group web mapping category. And if you have comments that could help.
Peter Rushforth: You know, identify things that that or any comments about a participants presentation that's a good place to talk about them, because browser developers hang out there and are sort of listening sometimes, and anyhow it's a it's a good good place to chat about people's presentations.
Peter Rushforth: And I just like to remind everybody that we're
Peter Rushforth: operating under the W3C code of conduct and there, Ted'll paste a link to that as well. So if you have
Peter Rushforth: Basically, it's all about professional conduct and interaction, so
Peter Rushforth: If you have concerns, please approach to any, any one of the conference committee who are online.
Peter Rushforth: And with that, I would like to introduce the agenda or speaker agenda for the day. We're going to start off with Dr. Gobe Hobona, of the Open Geospatial Consortium, who will speak about the
Peter Rushforth: The global OGC APIs effort that is underway. And with that, I'll let Gobe share his screen and I will put myself on mute, as I hope everybody else will.
Gobe Hobona (OGC): I will share my screen.
Gobe Hobona (OGC): Can you see my current slide.
Gobe Hobona (OGC): Okay, thank you. Okay, good. Good day everyone. So my name is Gobe Hobona, I work for the Open Geospatial Consortium, also known as the OGC and want to talk to you today about OGC API standards for the web.
Gobe Hobona (OGC): I'll first of all, introduce the OGC and then provide some background about OGC API standards, the development of those standards.
Gobe Hobona (OGC): I'll also explain some of the motivation behind the development of the standards and provide an overview of the OGC API standards.
Gobe Hobona (OGC): I'll also describe the innovation initiatives that we're using to support the development of the standards and explain how anyone, any member of the general public can get involved in the development of those standards.
Gobe Hobona (OGC): OGC is a global consortium, with more than 500 member organizations. T,hose organizations include in this commercial organizations, government
Gobe Hobona (OGC): Departments, research and academic institutions. OGC provides a neutral and trusted forum for tackling interoperability issues and OGC is a hub for thought leadership and innovation for all things related to location.
Gobe Hobona (OGC): Now, more than 500 organizations that are part of the OGC and those organizations come from the commercial, government, research and academic sectors.
Gobe Hobona (OGC): Commercial organizations come to the OGC to improve our business development to enhance competitive technical advantage, to glow that global brands and also to increase the likelihood of receiving innovation funding in the future from all the networking and knowledge
Gobe Hobona (OGC): Transfer that takes place within the OGC. Gobe Hobona (OGC): To gain trusted advice to, expand our international partnerships, and to improve our corporate policy support and certification. Gobe Hobona (OGC): Research and academic organizations come to OGC to expand our applied research partnerships, to improve the chances of receiving innovation funding in the future based on all the Gobe Hobona (OGC): Interactions with commercial and other organizations, but to also expand by international collaborations and increase citations as well. Gobe Hobona (OGC): So over the past couple of decades OGC has developed a suite of standards. Some of those standards deal with OGC web services. Gobe Hobona (OGC): Some of the more popular OGC web service standards include the Web Map Service standard, also known as WMS, the Web Map Tile Service, also known as WMTS, Gobe Hobona (OGC): The Web Feature Service, also known as WFS, and the Web Coverage Service, also known as WCS. These standards have been used in areas such as geology, transportation Gobe Hobona (OGC): City management, environmental data, management, hydrology and other areas. There are currently more than 200,000 OGC web services deployed across the web. Gobe Hobona (OGC): So about five years ago OGC started looking into the relationship between representational state transfer or REST approaches Gobe Hobona (OGC): In relation to OGC web services. And what you can see on the slide right now is an analysis conducted in 2015 which related characteristics of REST approaches, which is what you see on the far left column, Gobe Hobona (OGC): in relation to OGC web services, which is what you see on the right hand side of the slide. Gobe Hobona (OGC): So in 2015, OGC conducted research comparing REST to classical OGC web services and then in 2016 the focus shifted from rest to web APIs Gobe Hobona (OGC): In 2017 or OGC published a white paper on Open Geospatial APIs, and in 2018 work on version three of the Web Feature Service started Gobe Hobona (OGC): In 2019 the WFS3 or the version three of the Web Feature Service that was renamed and called the OGC API features and that was in recognition that the approach that was being adopted by the WFS3 was offering a new paradigm within the Gobe Hobona (OGC): OGC suite of standards, for the OOGC standards baseline. Then by the end of 2019 OGC API Features Part One, was published as an official OGC standard Gobe Hobona (OGC): So why are we concerned with all this API, why we developed all these OGC APIs? Well, Web APIs are a very popular and effective method for rapid software development. Gobe Hobona (OGC): And what we have found is that with the proliferation of web APIs, the variations and those web APIs has to an extent to created interoperability. Gobe Hobona (OGC): So open standards are being developed to enable interoperability between independent implementations and OGC APIs are being developed with a view of improving geospatial interoperability between web APIs. Gobe Hobona (OGC): And then number of principles that the OGC is using to develop these OGC API standards, some of the principles are shown on this slide. Gobe Hobona (OGC): First and foremost, the OGC API standards are being developed to offer modular API building blocks. Those building blocks will specially enable web APIs in a consistent way. Gobe Hobona (OGC): And by using a number of principles and approaches identified in the Spatial Data on the Web Best Practices, which have been developed jointly between OGC and the W3C. Gobe Hobona (OGC): What you see API standards leverage the OpenAPI specification specifically to help describe the APIs themselves, as well as implementations of those OGC APIs Gobe Hobona (OGC): Another key principle is that the OGC API's are being developed to be as developer friendly as possible. So there's a specific focus on developing experience and usability. Gobe Hobona (OGC): And we do all of this development work publicly on GitHub on a public repository, while using any implementations of the OGC API standard. Gobe Hobona (OGC): To involve the general public at using initiatives such as sprints and by using that to Gobe Hobona (OGC): To solicit feedback from the public and to use that field feedback to help us validate and improve those standards. Gobe Hobona (OGC): Another key principle is that of API first. So we're using an API first approach to develop other APIs using OpenAPI, the OpenAPI Gobe Hobona (OGC): specification to describe those APIs and this enables us to describe in a machine readable way the resources offered by the API, the behavior of the API as well as other aspects, supported by the OpenAPI specification. Gobe Hobona (OGC): So what are those API standards? Gobe Hobona (OGC): So we have the OGC API features standard. So this is a fully fledged OGC standard, part one, although the OGC API standards standard was published towards the end of 2019 and work is ongoing on developing additional parts and extensions to OGC API. Gobe Hobona (OGC): For the sake of features. There's also a number of other OGC API standards that are currently under development for instance OGC Common Gobe Hobona (OGC): Which provides a series of requirements that are applicable across all OGC API standards. Gobe Hobona (OGC): We've got OGC API Coverages which deals with access to coverage data such as raster imagery, OGC API Records which deals with access to meta data. Gobe Hobona (OGC): OGC API Processes which deals with access to geospatial processes such as buffering, routing, hydrologic models and so on. Gobe Hobona (OGC): OGC API Tiles, which deals with access to tiled resources such as vector tiles, tiled raster coverages, tiled maps and so on. Gobe Hobona (OGC): OGC API Maps which deals with access to electronic rendered maps, OGC API Environmental Data Retrieval, which deals with access to environmental data such as metallurgical and weather data. Gobe Hobona (OGC): And then we also have OGC API Styles, which deals with access to information such as styles and symbology. We're also working on a number of future concepts, for instance, an API for discrete global grid systems as well as another for routing. Gobe Hobona (OGC): Now, what can you expect from each approved OGC API standard? you can expect a standard document and an OpenAPI definition document. Gobe Hobona (OGC): You can expect an executable test suite to how implementors validate whether or not the implementations comply with those standards. You can also expect tutorials and guides, what you can see on the screen on Gobe Hobona (OGC): Examples specifically focusing on OGC API features which provides access to vector feature data. Gobe Hobona (OGC): We've set out a roadmap, as shown on the slide. Gobe Hobona (OGC): With a number of the standards. Gobe Hobona (OGC): planned to be published by the end of this year, as well as others that will be published in 2021 Gobe Hobona (OGC): Another thing you can, you'll notice from this slide is that many of the standards are being developed as multi part standards. What this means is that they are, there's one core specification, as well as a number of extensions, all within the same standard standard Gobe Hobona (OGC): And we're using a number of innovation initiatives to develop these standards. Examples include Sprints, hackathons, pilots, testers, as well as others. But you can see on the slide, are some of the innovation initiatives, we've held since 2019. Gobe Hobona (OGC): We hold a hackathon in London in June 2019 and we had about 70 participants literally participating from across the globe. Gobe Hobona (OGC): We've held several sprints since then. Gobe Hobona (OGC): And next on the calendar is a virtual code sprint. On September 29 to the 30th, we will focus on the OGC API Gommon and OGC API Features standards in order to participate in the sprint, you'll have to register this URL shown on the slide. Gobe Hobona (OGC): And and that's it. If you have any questions please feel free to send an email message to the address shown on this Gobe Hobona (OGC): slide and you can also visit the OGC API at ogcapi.ogc.org website where you'll find information about OGC API's as well as initiatives that we're planning to develop those standards and that's it. Thank you. Peter Rushforth: Great, thank you very much, Gobe. Peter Rushforth: It's a monumental initiative with lots of moving parts, and it's a it's pretty interesting to see it move along. Peter Rushforth: Well, I'd like to introduce our next speakers and then keep things moving here so Peter Rushforth: The next topic will be about pygeoapi, which I believe is a OGC API implementation by Tom Kralidis, Angelos Tzotsos and Francesco Bartoli, who are all present today so Peter Rushforth: With that, I'll let Peter Rushforth: Tom, take the take the lead and Please. Welcome them. Peter Rushforth: Tom, I think you're on mute. Tom Kralidis: Oh thanks. Sorry. Can you hear me. Tom Kralidis: Yeah, can, can folks see my screen. Gobe Hobona (OGC): Yeah. Tom Kralidis: Excellent. Okay, so thanks for thanks for the introduction. Tom Kralidis: We will give a small presentation today on the pygeoapi project. So the pygeoapi project is a OS geo community project. Tom Kralidis: And it currently implements many of the OGC, of the evolving OGC API standards. It is a reference implementation for already for the OGC API Feature standard so Tom Kralidis: Whoops. So I'm just going to give an overview, following on from Gobe's presentation around. I won't get into all of these Tom Kralidis: As they sort of echo what what Gobe is saying, but I'll talk a little bit about the the project itself, some of the core capabilities as well as example of production instances and where we're hoping to go Tom Kralidis: Moving forward. Tom Kralidis: So the project was created. Tom Kralidis: In 2018 Tom Kralidis: So, as Gobe mentioned, there was a some initial work on on code sprints and hackathons around WFS3, which was called at the time so we Tom Kralidis: We participated in in that sprint and have been participated in the visibility in the subsequent sprint from OGC on OGC APIs. So project has been around for for a couple of years. Tom Kralidis: We designed it sort of as a geospatial data, data API framework where Tom Kralidis: It where it can be very extensible and is available through numerous web front-end technology approaches, at least for at least for Python. Tom Kralidis: And we really wanted it to be extensible on the back end to be able to integrate many different formats or or other services, there's a growing international team. Tom Kralidis: There really should be a map here, I guess. But there's a growing international team from many countries and time zones. So meetings are always interesting to schedule but gives you an idea of Tom Kralidis: The participation and the widespread interest in these evolving approaches and and we're happy to have everybody contributing that Tom Kralidis: That already is. Tom Kralidis: So again, it's an OGC API server implementation in in Python. It chooses to it publishes data. So we don't really get into massaging data too much, but it's basically a data publishing tool. Tom Kralidis: And it leverages the powerful ecosystem of Python packages. So for those who are familiar with, with Python, there's a huge ecosystem of geospatial tooling underneath and pygeoapi API is a is basically a shim on top of all of that to be able to provide this functionality. Tom Kralidis: So you can run pygeoapi from the, from the command line or you can run it from from a web application. Tom Kralidis: I'll just give you an idea of the of the overall architecture of the implementation. So we have a core, which is our course from the Python API. Tom Kralidis: And then we have a series of web front-ends. So if you're familiar with Python web frameworks. They're available in Flask and Starlette and other other frameworks. Tom Kralidis: If you have your, your own downstream implementation, you can use pygeoapi as a library and deploy it alongside your own mem your own your own implementation. Tom Kralidis: So again, we have a very small but robust and flexible core and which has made made available through these through these web APIs and that core itself takes takes a number of different back ends or format or databases or search index through Tom Kralidis: Through these data provider plugins. So we have a a plugin mechanism for the entire project where you're able to Tom Kralidis: You know, plug your data into the pygeoapi framework, no matter where it sits or how it's sorted out. As long as you implement the API accordingly. Then, then you'll be able to, you know, publish your data through pygeoapi thereby Tom Kralidis: satisfying the OGC API standards. Tom Kralidis: There's a number of different back ends already out of the box or some of you may be familiar with some of these, but we do also support the GDAL Tom Kralidis: Underlying underlying software which reads, hundreds of different formats. So if you're geospatial data is compatible with GDAL-OGR are it's automatically compile compatible with pygeoapi. And you can put it out to the OGC APIs quite easily. Tom Kralidis: We recently implemented the support for covered data providers. So those of you who are into grids, or raster data or multi dimensional data, Tom Kralidis: Earth observation data that this is now possible through pygeoapi and the evolving OGC API coverages specification. So really exciting stuff here. Tom Kralidis: We've recently implemented in terms of tiles. So we have the, the ability to connect to a directory structure for for tiles or object storage, Tom Kralidis: local or remote. We'll talk a little bit about that later. Tom Kralidis: And we also implement the schema.org sort of linked data approaches to make to make resources available through pygeoapi search engine friendly and and discoverable through through mass market approaches. Tom Kralidis: So I'll walk you through some screenshots in terms of in terms of capabilities. So here's a default view of when you stand up a pygeoapi instance you get Tom Kralidis: A web presence and as Gobe may have mentioned the you know HTML or web page web page capabilities in OGC APIs is a Tom Kralidis: Is a desirable thing for mass market integration. So here's an HTML view of the landing page for a pygeoapi Tom Kralidis: implementation. Here we can see, you can browse the, you know what, what kind of collections are configured what processes are available, how a developer can interact with the API through the API definition as well as a conformance page to find out what standards are implemented. Tom Kralidis: Here's our OpenAPI page so, API first approach, you can walk through all the different endpoints and find out more about what parameters are accepted what their data types are, what a response looks like and so on. Tom Kralidis: Here's a screenshot around OGC API features. So this is showing some, some, like some lake data. Tom Kralidis: We've recently implemented in the last month or so, OGC API Coverages so that was a provided by USGS Tom Kralidis: Into the project. So we're appreciative of that. So there you can see an example of some global temperature, temperature data, which is a which is provided through OGC API Coverage to in the coverage JSON format. And then we can see Tom Kralidis: A map there of the data. Tom Kralidis: Fresh off the press. We just implemented, OGC API tiles. So Francesco who's on this Tom Kralidis: Presentation recently implemented that. So that's a valued edition. And, you know, thank you very much for that. But here's, here's what we were talking about Tom Kralidis: Around publishing tiles to pygeoapi, whether they're local tiles or whether they're available remotely through through object storage. Tom Kralidis: As well as OGC API Processes. So you can configure any kind of process that you want, whether it's synchronous or a synchronous using the pygeoapi framework and making that available through through all the proc Tom Kralidis: Finally we've we have implementation, we have support for the spatial temporal asset catalog or the STAC implementation, which allows for a browser catalog of Tom Kralidis: Of geospatial temporal assets. So you can drill down directory trees of geospatial data and then get to the actual files,peruse and see what they look like, and then download them if you wish. Tom Kralidis: So that's a little bit of an overview about what the project is all about how how it sort of setup and what its core capabilities are, I'll walk you through some examples of production instances. Tom Kralidis: So we here at the Meteorological Service of Canada and deployed pygeoapi as part of our National Geospatial API weather climate water API platform, which is called GEOMET Tom Kralidis: So we provide real time weather, data from numerical weather prediction, as well as hydrometric and climate archive data. Tom Kralidis: So we initially use pygeoapi to provide our climate or hydrometric and our climate data through the the OGC API feature standard and that's made available through Tom Kralidis: Through geo.weather.gc.ca, as you can see there. So you can go to that link and and and look at, you know, hundreds of years of climate archive data in the in the in the WFS3 format. We also implemented a Tom Kralidis: data extraction capabilities through OGC API processes, which basically looks through Tom Kralidis: simulations of climate data, forecast data and extracting time series out of those in providing, basically providing time series extraction from a Tom Kralidis: Coverage into into a CSV or a GeoJSON, we are looking at increasing we are looking at providing more support more pygeoapi capability through our platform. So we're looking into doing things with coverages as well as the evolving OGC API records standard Tom Kralidis: There's also an implementation from the global soil information system by by UNFAO. So they they've provided a lot of work and examples on doing JSON LD in in in pygeoapi, So you can click and visit that website, Tom Kralidis: When you have a chance. Tom Kralidis: And finally, finally roadmap, so Tom Kralidis: I think the project for just over two years is is a is implemented quite a bit. And there's been a lot of rapid development and I think Tom Kralidis: I think this is very telling of the the the OGC API efforts and the goals of lowering the barrier for developer implementation. So this very quick update to this project by Tom Kralidis: By increasing number of developers. And that's, I think that's a core reason why having said that, there's still more work to do. Tom Kralidis: We're looking to, you know, given the OGC API standards development efforts are public, we are you know sort of moving along with the evolution of those standards. So we're looking to implement the maps, tiles and Tom Kralidis: And records as part of as part of a future future implementation and we're looking to we're always improving the API support. Tom Kralidis: And the next one will be improving is the processes a support with some of the updates that have been going on in the Processing Standards Working Group. Tom Kralidis: More data providers. So we want to provide them as flexible a capability for people to hook up their data as possible. We recently had Google Summer of Code contributions from two students to provide capability on supporting the common query language or CQL Tom Kralidis: Standard as well as doing doing transaction. So create update, update, delete, we're looking into better content negotiation, as well as spreading the project through through through through more approaches. So OSU live is a live DVD Tom Kralidis: Or live implementation that you can download and run all of the ways to sort of software free and open source geospatial software. So that's a very popular Tom Kralidis: Implementation and we're looking to get our software on to that to be able to to spread the news about the project and make it more easily available to as much people as possible. Tom Kralidis: And there's a variety of support mechanisms that Tom Kralidis: If you're looking for support through these various organizations, we have a, we have a Gitter channel that that folks can come in and ask questions. There's a mailing list. There's documentation you can peruse all the links as you wish there and Tom Kralidis: That's, that's, that's pretty much it. So thank you for listening and unless Angelos or Francesco has any comments or things to add that I may have missed. I'd like to thank everybody for listening. Peter Rushforth: Thank you very much, Tom. Peter Rushforth: If we have time at the end. Peter Rushforth: And Peter Rushforth: Francesco asked if we could do see a demo. And we'll just keep a close eye on the clock and see if that's possible. Peter Rushforth: But thank you very much. It looks like a very interesting project and something that pretty much anybody in geospatial could use Peter Rushforth: So with that, we're going to move on to the next. Peter Rushforth: Next talk in our agenda and with thanks to Heather our closed caption or for her great efforts so far because we're, we're really making them work hard today. Peter Rushforth: So I'll pass the control over to Joan Masó will talk to us about the connection of the MapMP initiative with a OGC standards such as the new OGC API tiles. Peter Rushforth: Talk and the OGC WMS. So, Joan, are you on unmuted. Peter Rushforth: I'm not hearing Joan Joan Masó (CREAF): I believe now I am Joan Masó (CREAF): now I'm online Thank you. Joan Masó (CREAF): Okay, thank you for for presenting me and working at graph here in Barcelona close Joan Masó (CREAF): Always close working with the with the OGC with different standards evolving. Joan Masó (CREAF): Let me, let me just start by saying that Joan Masó (CREAF): There are several ways that you can send from the server to a client up and they have different levels of complexity, the most Joan Masó (CREAF): Low level thing that you could do is to serve packet some kind of a description of the geospatial objects or maybe the pixels from the server, bend some kind of a protocol and send it Joan Masó (CREAF): To the client, you would also think about creating some kind of a JavaScript code that will allow you to manipulate data and to present it into the screen, or you could think that HTML. Joan Masó (CREAF): could actually be able Joan Masó (CREAF): To do the mapping thing by itself. And we all know that MapML is precisely that approach. But I wanted to present that in Joan Masó (CREAF): In perspective, because actually the first approach is what OGC web services has been doing for more than a decade. Joan Masó (CREAF): This idea of having these key value pair requests. And then this responds with a geospatial format into the client that will be able to present Joan Masó (CREAF): That we are now transitioning into the OpenAPI world. And this is going to make some of these things are a little bit more easy because, for instance, we are Joan Masó (CREAF): Changing from an XML to the JSON that worked more naturally into the into the web client. But essentially, we are we are kind of doing the same thing. Joan Masó (CREAF): In the JavaScript world. You can you can use Leaflet, you can use Google Maps, you know, the experience of doing that. It's Joan Masó (CREAF): Easier, and in the low level, in this Joan Masó (CREAF): You know down level here we have the MapML. MapML is just some elements into HTML page Joan Masó (CREAF): That you could use to actually communicate them up to the client actually the OGC has a standard is called always context. I didn't make a set of resources that you can see together in a client that plays a similar but different role is not, of course, an extension of Joan Masó (CREAF): HTML is actually an atom in colleague Joan Masó (CREAF): So if we can discuss a little bit. These four levels. Let's say that in the first level it is kind of a good way of doing things for desktop solutions for Joan Masó (CREAF): Communicating services among them, but it's difficult to do that in in the browser, because you have to manually build JavaScript code that Joan Masó (CREAF): builds these GET KVP request, interpret the response, maybe a GML maybe maybe a, you know, TIFF file, something like that and then create some HTML content. Joan Masó (CREAF): Using these JavaSCript to be in order for the user to actually see something maybe you could use Canvas instead. But the idea is the thing. Joan Masó (CREAF): With the with the approach of OpenAPI. This is number two here in my slide you can automatically create some content from code from the OpenAPI document. Joan Masó (CREAF): You'll have the ability to parse automatically JSON from JavaScript that's something but still you need to manually extract Joan Masó (CREAF): And show the information that it's actually great for maximum flexibility and for combining several services together. but this is complicated. We all know that that you know you can take Leaflet. If you know a little bit of JavaScript. Joan Masó (CREAF): You can simply program using some sentences here and there in your HTML page and it's reasonably easy to do at least the minimum map visualization, but with with MapML you have simply tax. Joan Masó (CREAF): You you have elements that you add into your HTML describing what the map should have, not how it should be presented. But what is it Joan Masó (CREAF): We have been exploring for more than four years now. The relation between the OGC standards on the on the MapML Joan Masó (CREAF): Standard and we, Joan Masó (CREAF): I have collected these experiences of the different test beds and you can you can visit this URL there on the right, on the right hand side, sorry, Joan Masó (CREAF): It's difficult to summarize, so I will say that in Joan Masó (CREAF): In in '17 Joan Masó (CREAF): What we did was Joan Masó (CREAF): Our first experience and we compare MapML with all the various contexts. In '18, what we did was Joan Masó (CREAF): To suggest that MapML should include your URL templates and actually these ended up into the into the MapML specification in Testbed 15, what we did was, for instance, suggesting that OGC API features could never see a MapML content in the items part of the of the API Joan Masó (CREAF): Implementation and in 16 in the Testbed 16 that it's currently happening. We are more focused on on building clients that could show inputs of machine learning processes. Joan Masó (CREAF): From my point of view, and I'm biased, it's all about tiles. So what do you see a MapML is exactly the same title model. Joan Masó (CREAF): in OGC it's called Tile Matrix Set, in MapML it's called Tiled Coordinate Reference System, but each kind of the same. MapML defines four Joan Masó (CREAF): Tiled Coordinate Reference Systems. Well in the OGC, you could define the Tile Matrix Set you like as far as you are able to describe it. Joan Masó (CREAF): Actually we make an effort Joan Masó (CREAF): To allow for three of the four TCRS as in math ML to be also in the OGC a standard called Two Dimensional Matrix Set Annex D. And those are the equivalence between the MapML names in the left hand side on the Joan Masó (CREAF): OGC names in the right. Joan Masó (CREAF): Tile sets. So we are talking about tile sets, we are talking about collections of tiles that are going to be Joan Masó (CREAF): Partially presented to the to the user and will be kind of automatically replaced by others while user pans and zooms. Those are represented by URL templates, both in OGC API Tiles and WMTS as presented by Gobe before, and also in MapML. Joan Masó (CREAF): So the same URL template is useful there, you'll see the representation in the OGC OpenAPI Joan Masó (CREAF): georepresentation. And you see below in MapML document I took the liberty to actually replace the x, y and z variables why the valuables that usually Joan Masó (CREAF): Usually used in OGC, I believe I'm not violating the MapML standard by doing that. And these looks more similar. Joan Masó (CREAF): So, actually. Joan Masó (CREAF): In MapML tiles are used, but MapML doesn't specify how you will produce them. Joan Masó (CREAF): In MapML there is no specification on how you will produce a mapping document, it's just telling you what a MapML should look like. On the other hand, in the OGC API tiles, the collection can be distributed as tiles. Joan Masó (CREAF): So each style could be available as your as a URL responding to the URL template and the OGC map tiles, there is a new thing that is called the tileset metadata document. Joan Masó (CREAF): That it's going to be explained after that and I will try to convince you that actually the MapML is a tileset metadata document. Joan Masó (CREAF): First let me say that the OGC API will have several other sources that are listed here. And the last one allows us to connect or to transform our collection into tiles. Joan Masó (CREAF): But what I would like to present to you is the tileset object. And this tileset object is in these particular path of the of the API representation, you have a JSON document describing the tileset Joan Masó (CREAF): A bit of metadata, TileMatrixSet definition, TileMatrixSetLimits, URI template Joan Masó (CREAF): Maybe some description of the content of the tiles, and this is a diagram of how how it looks like. But actually, as I say, is Joan Masó (CREAF): Going to be a JSON file, but if you tried to compare that MapML is actually something that does a very similar thing. Joan Masó (CREAF): It provides some bit of metadata, a title there, it points to the TileMatrixSetDefinition, or tile in this case. Joan Masó (CREAF): It's states some limits, for instance, the maximum zoom will be 15, and it points to a URL template as you can see there. So, I mean, the similarities is so clear that, actually, I Joan Masó (CREAF): You know I manipulated the OGC API Tile example that I'm using it Joan Masó (CREAF): In the Github, no, in the SwaggerHub. Just to tell, that actually apart from the JSON representation, we could have a MapML representation. So maybe because I cannot use Joan Masó (CREAF): The actual media type for MapML, because then the SwaggerHub doesn't recognize that this is the XML, or or micro XML. Joan Masó (CREAF): But you, you see this is this is a new connection that we are seeing Joan Masó (CREAF): That really really Joan Masó (CREAF): Makes this relation between MapML and an OGC API Tiles possible. So in conclusion, MapML is the simplest way for adding geospatial information in web browser that I know and MapML makes use Joan Masó (CREAF): Of the OGC Joan Masó (CREAF): Tiles Joan Masó (CREAF): To make it the OGC API Tiles use simpler in browser. So it provides a way to communicate two of the API resources (tileset and tile URI templates) to the browser itself. Joan Masó (CREAF): So the OGC API tiles provides a way to automatically generate MapML documents, or at least that is our assumes that could have a representation in that Joan Masó (CREAF): Form. Joan Masó (CREAF): And the OGC API style could become the CGI of the MapML form. So, actually. Joan Masó (CREAF): What I'm suggesting here in this presentation is that the OGC API is part one to consider to describe how to generate MapML documents as an alternate the format to the current JSON tile set Joan Masó (CREAF): Meta data that needs on the OGC to the tile matrix set standard and actually we are also considering an alternative format for vector tiles for MapBox vector tiles that is called TileJSON Joan Masó (CREAF): So, thank you. Peter Rushforth: Thank you very much Joan. So very interesting and would be great to connect the monumental effort of the OGC API work with the Peter Rushforth: Browser community through a media type. So with that we'll move on to Peter Rushforth: Jonathan Moules of GeoSeer Peter Rushforth: Which is a Geospatial web services search engine and he's got a Peter Rushforth: Few points to make about about his experience in developing that search engine. So Jonathan. Thank you very much and I'll pass it over to you. Jonathan: Hello. Can you hear me. Jonathan: And see me on Jonathan: Screen anyway. Jonathan: So good. Excellent. Thank you. Ah, hello, everyone. Welcome to Edinburgh. Imagine your hair gray sky gray buildings. Jonathan: That's Edinburgh. They're very nice buildings to be fair. Jonathan: So we've set the scene. I am here to talk to you about some of the limitations to the use of OGC spatial web services. Jonathan: Specifically, the discovery problem. How do you find the services, what's the point of having all these services. If you can't find them. Jonathan: To wit. I've created GeoSeer, which is a search engine for such services and then some thoughts and conclusions around such finding the services and what the problems currently are. Jonathan: So the discovery problem. That's just a second one. Jonathan: Yeah, so Jonathan: We've lost the page. So specifically, we're talking about the services WMS, WMTS, WFS, WCS, Gobe has already talked about them. They're all OGC services. They're all lots and lots of them on the Internet. Question is how do you find them? Jonathan: You can try Googling but it's difficult. There are lots of portals. So the primary way to really find these things is with photos. The problem with the portals is there are a lot of them. Jonathan: So I am aware of about 200 CKAN portals and 150 CSW portals. There is some overlap between them. But the short version is there are literally hundreds of these. Jonathan: On top of that, you've got Inspire portal and then all the ArcGIS ones as well. There are a lot of them. And the interesting thing about these is they don't actually have many of the services on them, but we'll get to that in a bit. Jonathan: So that brings us on to GeoSeer, GeoSeer is designed to help you try and find services. Great. This isn't actually a talk about GeoSeer, per se, but the data that I've discovered Jonathan: Or we've discovered from the creation of GeoSeer and the GeoSeer analysis to see from having this huge index on the services. So GeoSeer is a search engine. Jonathan: For the services, the way it works behind the scenes, very short version. It goes out finds get capabilities documents which all of the services present at scrapes them to extract all the meta data have Jonathan: Some all the metadata lives there, optimistic right therm and present turns it into basically a plastic Search Database behind it. Jonathan: And make that searchable. Great. Jonathan: So, Jonathan: What the results of that well GeoSeer has pined it Jonathan: has managed to find 5000 different hosts or data and our host is basically domain name example.com, arcgis.com, two different domains, two different hosts. Jonathan: USGS is one host, usda.gov is one host. I forgot the top of my head, where the subdomains counters have per host. But either way, there are many there are 5000 of them. As you can see here this is data from December. Jonathan: That she served as even well it's about the same number of hosts. Now, but more data sets. So you've got 5000 hosts. Peter Rushforth: John, are your slides advancing? Jonathan: They should be. Which one are you looking at? Peter Rushforth: We're looking at the WMS, WMTS, WFS and WCS slide Jonathan: Yeah computer's broken. Yes, I've got a few slides. Let's just stop the screen sharing and restart it. Jonathan: Have I progressed? Jonathan: Has it changed? Peter Rushforth: Yeah yeah, we can see portals. Jonathan: Excellent. So yes, this is what I was talking about when there are like 200 portals and so you've got your 200 CKAN portals and 150 CSW portals. Jonathan: This is just a screenshot GeoSeer when I was talking about that, get capabilities document was just XML. Everyone loves that. Jonathan: So this was what I was just talking about. Peter Rushforth: Maybe I think the, when you go into Peter Rushforth: full screen mode, it's not advancing, maybe you should just do it in edit mode. Yeah. Yep. Jonathan: Better? Yeah. Jonathan: Libre office seems to be quite for broken presenting stuff, ironic. My goodness. Big fan of Open Source. So this is hopefully showing you the number of hosts and number of services and stuff. Yeah. Good stuff. Jonathan: So, Jonathan: Yeah, sorry. Well as like good thing. This is a lightning talks, so bad time for technical problems. Jonathan: The number of. You can see the weirdness going on there with open. I don't know. Anyway, Jonathan: Technology right that's what we all do the number of hosts. So we've got 5000 on GeoSeer you can see that if you look at all of the CKAN portals minus the USA one because it's different because it is Jonathan: You've only got 5% of the total number of hosts, and about 3% of the total number of data sets are available via all of those 200 CKAN portals as compared to Jonathan: Being on GeoSeer, you know, CSW 6%, even if you to manually go through those 350 portals, you would only find a small fraction of the data that is actually out there. Now there's own. These are all of these numbers of services that actually out there and actually live and actually current Jonathan: So they should respond. They did respond to get capabilities request. So that actually there Jonathan: The stuff on the portal is portals, of course, don't necessarily always have current live data. So the actual number of claimed hosts may be higher, but this is number, it's actually there so you can see the problem with portals is Jonathan: Well, they don't really have much on them. Jonathan: And of course there are so many, so there's an entire blog post about it. Jonathan: So let's move on to other problems metadata. Everyone loves talking about fact that everyone fills in metadata. This is the only slide on it. But the short version is they really don't. And if you actually look at, say, the blue bits are decent metadata that's Peter Rushforth: I think, sorry, John the slide for mine is still on. Peter Rushforth: Number nine. Jonathan: Oh dear, what is going on here. Gobe Hobona (OGC): You might, it might be best to export it as a PDF and then Gobe Hobona (OGC): And then Gobe Hobona (OGC): Show that PDF Jonathan: That Peter Rushforth: Well, actually, I know you're on 10 according to my screen. Jonathan: Brilliant. Okay. Yep. So 10 is the data set meta data. Keep going on this, tell me if it doesn't update. I'll tell you when I do the next slide. It's all part of the fun. Jonathan: Data Set meta data. So basically, no one fills in for WMS there's Jonathan: barely any meta data. Jonathan: filled in for the abstracts Jonathan: Less than half of the services have any Jonathan: Metadata filled in the abstract. So how are you going to find the services are out there, and it's just not there. Jonathan: Next slide. Jonathan: Hopefully a map. Peter Rushforth: Hmmm, Peter Rushforth: Nothing here. I'm going to Jonathan: Click around a bit and Peter Rushforth: There you go. Yeah. Jonathan: I have to click a lot apparently before zoom picks it up. Jonathan: Yeah, so this is global coverage of where all these data sets are, mostly Europe, these, this is just the title of in map of interest, mostly Europe so be quite a few North America. There's a hotspot over the Belgium and France, Germany, try point Jonathan: And but there are more of those maps more details, without the Hotspots Jonathan: at that URL. Jonathan: Next Slide, going to click a lot Jonathan: Here we go, so GeoSeer usage. So despite GeoSeer having a huge number of index of being completely free to use, doesn't even have adverts Jonathan: there's actually very little uptake of it, which indicates there isn't much call for searching for the services in the first place. So we've got 2 million data sets and GeoSeer only gets around 1500 searches per month. Jonathan: So all of these data sets are out there. They're all published Jonathan: Huge amounts of money being spent to publish them, but just collect them publish them alone, Inspire, for example, the end result is that doesn't seem to be a huge amount of uptake in actually collect, uh, in people finding these data sets or being interested in finding these data sets. Jonathan: Which brings us on to the conclusions. Jonathan: Click around there Jonathan: We are hopefully thoughts and conclusions. Jonathan: The obvious one. People are terrible at filling metadata. Jonathan: Surprise. Jonathan: There doesn't seem to be much call for service and data discovery, it's a problem that's being solved on and off the last 15 years Jonathan: Most of services that have ever existed doing it are now defunct I don't think the slide advanced. Jonathan: No? This is just thoughts and conclusions, I'm effectively reading them out. You're not missing a huge amount. Jonathan: Yeah. Zoom Plus Libre office is not a combination you want to use. Jonathan: Zoom on Firefox. So it's like the open source option. I don't know. Anyway, Jonathan: Federation of data portals is a great idea, but the end result is you just end up far far too many data portals which themselves don't necessarily have much data on Jonathan: And the question. Jonathan: That I suppose I want to ask or to put forward is how many of these services exist for the purposes of sharing data. Jonathan: Isn't just to share and how many exists, just to host data for their own data portals. So if you build a web app you happen to come with the web app happens to come with a WMS Jonathan: That built, that's just deployed for its own portal as compared to ones that are explicitly designed for is all our data habits about it. Jonathan: Doesn't even if there is much of that explicit sharing that doesn't seem too much explicit usage based on GeoSeer Jonathan: Search usage uptake and that's me. One very exciting presentation filled with lots of entertaining bugs. The Peter Rushforth: Technical guide because Jonathan: Well, if you're not working. Jonathan: Struggling get bugs. Yes. Peter Rushforth: You very much. I mean apart, aside from the technical bugs, which are always a bit confounding when you're live for the presenter, but not so much for us. I mean, I think we got the idea you presented some very interesting food for thought and thank you for that. Jonathan: Thank you. Peter Rushforth: So with that, I think what I'll do is Peter Rushforth: Since it's a Peter Rushforth: It's 9am Peter Rushforth: Ted, do you think we have time for a short demo from from Peter Rushforth: Francesco and Tom and before we move into our panel situation. Ted Guild: Let's give it a shot. Ted Guild: Okay, since the final Ted Guild: Few minutes if necessary. Peter Rushforth: Yeah. Yeah, true. Probably the panel is not going to go too long. All right. So Tom and Angelos and Francesco, could Peter Rushforth: one of you share your screen and give us a demo that you were proposing. Francesco Bartoli: Yes, sure. I'm going Francesco Bartoli: To share my screen. Francesco Bartoli: Just a moment. Francesco Bartoli: Hello. Francesco Bartoli: Are you seeing my screen. Peter Rushforth: Not yet. Francesco Bartoli: Do you see, do you see my screen. Francesco Bartoli: No, I'm sharing Peter Rushforth: Okay, now I am Francesco Bartoli: Okay, cool. Now this is the landing page of pygeoapi, we-, this is a local obviously obviously this is a local instance just to give you more detail, detail about this permission from Tom. We have two resources. One, it's the now famous large lakes. Francesco Bartoli: The lake, sir, is rules the lakes layer as two kind of specification under the providers. One is the feature the GAC API feature. And the other one is the OGC API tiles. As you can see here the, the actual data for the Francesco Bartoli: OGC API tile and point comes from a local instance, a local object store provided by a menial server. So we have Francesco Bartoli: MapBox vector tileset loaded into an object store and provided Francesco Bartoli: Locally to configure it to the pygeoapi API. So Francesco Bartoli: Essentially from the landing page, we can go through the collection, we can explore all the collection in this instance and if you Francesco Bartoli: If you go Francesco Bartoli: Over the large lakes year there is the an introduction HTML. These is the HTML representation. But essentially, on the link in the upper right side, we have also the JSON representation and the JSON LD. So essentially if you want to Francesco Bartoli: To go to the actual vector tiles representation for large lakes. We can follow these links and we open up Francesco Bartoli: The HTML representation on the maps which dynamically load and proxy the vector tiles. So the MapBox vector tiles Francesco Bartoli: Which are provided by the backend server. And from here, we have also the meta data representation in the tile JSON format. So if you go to that link a new HTML page is shown and obviously there is also it's JSON representation and Francesco Bartoli: Just to reinforce the concept that John Francesco Bartoli: told you before, there is obviously here the JSON representation of the Francesco Bartoli: Vector, yeah, of the vector tiles and points. So you can have the actual URI template Francesco Bartoli: With the different Tile Matrix Set ID and where that Tile Matrix Set ID resides, Francesco Bartoli: resides in terms of actual JSON content and tht, Francesco Bartoli: I think for what regarding what regards the maps. I think it can be all apart from that, obviously, we can go to the Francesco Bartoli: Also to the Francesco Bartoli: Actual Francesco Bartoli: OGC API feature HTML representation here you have the, an overview already in provided in HTML map and essentially the Francesco Bartoli: Nice HTML representation of the records and all of these can be also Francesco Bartoli: Correlate as a JSON representation which provides the feature. So as a geo JSON. We, the official collection. Francesco Bartoli: payload. Francesco Bartoli: And I think it's Francesco Bartoli: That's it. I don't know if Francesco Bartoli: There is some question about Francesco Bartoli: pygeoapi in general or the vector style implementation. I'm open to to answer. Francesco Bartoli: I don't hear you, Peter. I'm going to stop sharing. Ted Guild: Also not hearing Peter, Ted Guild: But next up we have Ted Guild: Shoppers in this panel on Ted Guild: On, Sorry. Ted Guild: Yeah, no. Stakeholders Gobe Hobona (OGC): The microphone selection thing. Ted Guild: Lost your audio again. Peter Rushforth: Yeah. Peter Rushforth: There we go. My okay Peter Rushforth: Okay, so Peter Rushforth: We're going to go over to our panel now of stakeholders for government geospatial data providers on the web. Peter Rushforth: And we have from the National Centre of Geographic Information in Spain, Emilio López Romero and from the Canadian Geospatial Data Infrastructure, we have Cameron Wilson, I hope, and Sébastien Durand from the Canadian Federal Geospatial Platform. Peter Rushforth: And Dan Sullivan from NASA Peter Rushforth: And so Peter Rushforth: What I'd like to do is to ask each of them starting with Sébastien Peter Rushforth: To introduce themselves and tell us a little bit about Peter Rushforth: About their background and the and their potential use of maps for the web maps in HTML and and help. I'll leave that up to you guys. So, Sébastien, over to you. Sébastien Durand (Canada - NRCAN - CGP): Well, thank you. Sébastien Durand (Canada - NRCAN - CGP): First, I'd like to thank everybody on the phone or on the line today. I'm really pleased to be part of that. Sébastien Durand (Canada - NRCAN - CGP): That workshop. I think it's a perfect setup for for the Canadian geospatial platform. It's quite a context. So I just want to say a big thanks and I'm quite amazed with the pertinence of the conversation. Sébastien Durand (Canada - NRCAN - CGP): Has been happening so far. So kudos to all. So myself, I'm a geoanalytics team manager within the Canadian geospatioal platform. We are within the Natural Resource Canada obviously for the Government of Canada. Sébastien Durand (Canada - NRCAN - CGP): Part of my general responsibilities are to provide products to the to the different clients we have, and it does provide over time, a lot of expertise and not expertise but a good sense of what are the requirements. Sébastien Durand (Canada - NRCAN - CGP): Of all the geo people, people who have interesting geo need maps, for example. So just going back to the Canadian geospatial platform itself. Sébastien Durand (Canada - NRCAN - CGP): We are an organization that aims to enable the government and what we we did find is lately, I mean, while the platform has been actively importing data from diverse level of jurisdiction being Sébastien Durand (Canada - NRCAN - CGP): From federal, provincial and territorial sources. The platform is also working at improving its web presence. Sébastien Durand (Canada - NRCAN - CGP): The Canadian geospatial platform didn't realize how crucial it is to facilitate search discovery and visualization through the web. Sébastien Durand (Canada - NRCAN - CGP): I mean, nowadays, even in COVID situation where we realize that the web is gaining even more Sébastien Durand (Canada - NRCAN - CGP): precedence, it's the primary means of communication. So it's, it is really at the front end and how we disseminate content so that's crucial content, crucial Sébastien Durand (Canada - NRCAN - CGP): element to consider. So now with the geo lens information from all fields definitely can be integrated to provide insight through both space and time. And I guess that's a everybody around the table has figured that Sébastien Durand (Canada - NRCAN - CGP): But there's actually a magical feeling when we see information of interest and it's viewed and put into context on a map, not only because it's it provides a unique experience online, the user to understand the situation. Sébastien Durand (Canada - NRCAN - CGP): But also because it provides a feel of a common operating picture to all users that is the true value of a geo product, it, it transcends all the different spheres of in which the information has been gathered from, you can put it all together. Sébastien Durand (Canada - NRCAN - CGP): So if effort is put it into any product you can officially provide a common operating picture that means provide Sébastien Durand (Canada - NRCAN - CGP): Tangible information and simple fashion so that people can consume it and and there's no real like there's no equivalent to substitute have the capacity Sébastien Durand (Canada - NRCAN - CGP): So, until now, I mean expert have been using scripts, search engines, optimization, APIs along with advanced software to make and publish maps. Sébastien Durand (Canada - NRCAN - CGP): But I think we have to ask ourselves the following question is whether or not does this make the geo information through the available and accessible and consumable Sébastien Durand (Canada - NRCAN - CGP): Nowadays, I guess, the web is the primary means of expression, like I mentioned before, and an HTML is obviously at it's core and it does act as a lowest common denominator. Sébastien Durand (Canada - NRCAN - CGP): Because we see that over 90% of the new not quite data now poesses geo references down to just images that you take with your phone. Sébastien Durand (Canada - NRCAN - CGP): It makes logical sense to see that this community investigate and address how we can, how can the act of mapping be made more accessible to all HTML users directly from their browsers as they actually code their page. So I think that is providing a bit of a Sébastien Durand (Canada - NRCAN - CGP): Perspective that is both mine and that of the GP or Canadian geospatial platform and I'll be happy to answer any other questions or give some further insights or maybe address some challenges that we may have if that's of interest to the panel. Sébastien Durand (Canada - NRCAN - CGP): Thank you very much. Peter Rushforth: Thank you very much, Sébastien. So I'll pass it over to Emilio López Romero from the Inspire initiative in Spain. Peter Rushforth: Thank you and welcome. Peter Rushforth: I'm muting you Emilio López (CNIG): Okay. Thank you, Peter. And thank you for the opportunity to participate in this panel. Emilio López (CNIG): My name is Emilio López. director of the National Centre of Geographic Information. One of the main goals of my institution is the coordination of the national spatial data infrastructure office paying Emilio López (CNIG): There are Emilio López (CNIG): Several organizations involved at different administrative levels, national, regional and local Emilio López (CNIG): And I think that it's important to notice that in Europe, the Member States has to fulfill the requirements of Inspire Directive of the European Commission, establishing SDI for Europe, consisting of national SDA and aim to facilitate the decision making process regarding environment. Emilio López (CNIG): Hence a standardization harmonization and common specification have become not only mandatory but crucial for us. Emilio López (CNIG): Since we are providing a with web services achieving AT companies use our services has been an important challenge. Emilio López (CNIG): Even though they are free and open Emilio López (CNIG): Therefore, fill in the gap between our web services Web Map will feature work cattle services and web developers is vital and OpenAPI new geo specification map futures on the web at fundamental level will be part of the solution. I'm sure Emilio López (CNIG): I have Emilio López (CNIG): To say, I would like to say that Emilio López (CNIG): A one out of four maps that load using our platforms Emilio López (CNIG): Are the loaded via web services. Emilio López (CNIG): And other important aspect because there are several administration using our web services like the canister Department of Emilio López (CNIG): Agriculture ministry and have the most important Emilio López (CNIG): Clients, we have, but our feeling is that the private sector is not using the our free -I'm hoping- resources Emilio López (CNIG): Enough. Emilio López (CNIG): Thank you. This is what I would like to say first time. Peter Rushforth: Thank you very much, Emilio, that is interesting, it aligns with some of the things we talked about today. Peter Rushforth: So, Peter Rushforth: Now I'd like to introduce Cameron Wilson of the Canadian Geospatial Data Infrastructure and let him speak for himself. Thanks, Cameron. cawilson: Welcome everyone. cawilson: My name is Cameron Wilson. cawilson: I may work with Natural Resources Canada and I've been working on spatial data infrastructures for going on 20 years now. cawilson: In a program called geo connections program. I'm the manager of the program. And we've been doing a lot of work on standards in the Arctic and Canada's geospatial data infrastructure and also trying to incorporate both marine and land based infrastructures. cawilson: My formal training and as a geographer, and that as part of that training, everything has a location and everything is in time. cawilson: That's one bias I sort of like to declare right off the bat. And so this lends itself well to where we're having these conversations but be more integrated into the general web environment of the world and having that value of location and time. cawilson: Also another bias like to declare and this is cawilson: It's about analytics and analytics have predictive capabilities. cawilson: Maps are effectively the PowerPoint of those analytics. They're the output of those analytics. So as we move forward. You know, how do we make those maps popular. How do we make those analytics, seen by more and more people cawilson: I have, I've been an open data champions since 1998 with the formation of a website called geo gratis and the main value around that was out of data democratization. cawilson: What I didn't realize at that point in time 20 years ago is that we also need a democratization for access cawilson: Those early days, you know, the data access was strictly through an FTP server, was very simple, very crude but also quite effective for a certain audience. cawilson: Today, while I would argue a veneer of geography, a very thin veneer geography is available through popular apps that we use on our phones on a regular basis. cawilson: These apps are to primarily designed to maximize advertising revenue. cawilson: For those people putting out the content and provides driving directions. So those will seem to the two main use cases for any for the apps you have on your phone. cawilson: They do not begin to address the social, economic or environmental needs of an analytical functions that come with GIS imagery and imagery analysis methodologies. cawilson: Conversely, are sort of what we are bread and butter that we're all kind of comfortable with is, I guess, so the old term was GIS on the web, well effectively we're still doing it, cawilson: Data catalogs and other sort of portal implementations. They remain would argue that niche for the general public usage. You see, all my kids now old, are in their 20s and 30s. cawilson: You know, they're looking for maps, unless they're going hunting and even then, one of my son's has a horrible, horrible time trying to find all this stuff with geographically data portals. cawilson: So that being said, I think that's a good introduction, but I think like the core of this discussion is how to make geography part of our day to day web usage or mass market implementation. Peter Rushforth: Thank you very much. Cameron well said. Peter Rushforth: So now I'd like to introduce Don Sullivan from NASA to Peter Rushforth: to round out our panel today. Peter Rushforth: Don's only on the phone today. So over you Don Peter Rushforth: If you're still there. don sullivan: Alrighty, thank you can hear me now. Yes. All right. Yeah, I gotta go to mute and unmute into play here. So good morning all don sullivan: I'm sorry about the lack of video on my laptop, I'm on a NASA laptop and videos disabled. don sullivan: would also like to preface this with with all of what I'm going to be saying this morning is is my opinion, my personal opinion, and it's not necessarily the don sullivan: Policy of NASA or the US government. So, blah, blah, blah, blah, blah. In any case have been have been don sullivan: Thinking around the GIS World Forum for a long time. Um, well. Okay, before we do that. Technically I'm, I'm the system engineer. I work for the NASA airborne science program in the Ames Research Center in Silicon Valley of California. So background I first started don sullivan: Doing them doing GIS on the web. When I worked on a program that displayed the USGS digital or the photo quarter quad. don sullivan: On telco base maps. don sullivan: This was, this was, um, I don't know '94, '95, something like that. don sullivan: The browser, we used was mosaic. For those of you who remember this, and we had a CERN web server in any case. don sullivan: That was, that was horrible. All the geo installations on, were on the server. It was just, it was a nightmare. But we did it anyhow. I'm one of the authors of the first implementations of the web map service for the OGC don sullivan: Lucian Plesea and Jeff De La Beaujardiere were the other ones. don sullivan: I'm the maps representative to the Open Geospatial Consortium technical committee where I co-chair a few don sullivan: working groups. They're merging disaster management systems aviation. don sullivan: I'm the, the Chair of the US delegation to ISO TC 211 G is here. And when I heard about this. don sullivan: Map on the web and and and maps as first class citizens. I went, oh my God, yeah. So, um, so I'm, I'm here, just as a don sullivan: Champion. I think this is just an amazing idea that that is that has been way too long in coming out, I've been waiting for this for over 20 years now so so good morning all and I'll go back to you. But I'll be glad to answer questions. Peter Rushforth: Okay. Peter Rushforth: Well, we haven't done a panel yet. So this is a first. So I guess we could probably entertain questions, but maybe if you want to type your questions. Well, I'll ask the first question, and then Peter Rushforth: If you have other questions you can type them into the the the chat panel and I'll repeat them or you can raise your hand, somehow, I'm not sure how that works on zoom Peter Rushforth: So yeah, I have a question, Cameron. Peter Rushforth: How, uh, you know, if you were looking for the non commercial Peter Rushforth: Information that governments can provide. Like how would that how do you see that Peter Rushforth: You know, how do you see that being, Peter Rushforth: Happening on the web and like non-commercial government information that could be provided in a way to make it more useful. How do you see that being, Peter Rushforth: What's the scenario in which you see that being useful. cawilson: Um, cawilson: Oh, cawilson: I like to think of it in terms of something that cawilson: A person might do in their house that has nothing to do with geography. cawilson: You know like they have a task to do, a household has a task to do. cawilson: I noticed, you know, I don't know what it's like in every in every other city, but I know many cities in Canada, the real estate market has just gone nuts. cawilson: I don't know if it's due to COVID or whatever, but the the demand exceeds supply. So if I wanted to go buy a house or a cottage right now. How would I do that. cawilson: And I know how I would do it even as a geographer knowing about all this great stuff. I would just go to my favorite browser, and I would start searching for a house. cawilson: And let's say that house in a different city to make it a bit more interesting. So I know nothing about where I'm looking. I just know I want to be in a certain area for some reason. So, cawilson: My family laughs at me because once I get on a browser, I can have 20, 30, 40 tabs going. I'm actually surprised the browser can still work. cawilson: And you get, you know, so you're what you're searching for. Well, you know, I have this area of interest to buy a house or a cottage. So I'm looking around that area but, what are the values of those of those properties in that area. cawilson: What is around the houses, is there a factory behind, is there a school behind or toxic dump behind it, or is it a beautiful park. cawilson: Is there education for myself and family to go to. What's the crime rate. What's the access to health facilities, retail and public transit. cawilson: And before you know you've got, you know, all these very small tabs on your browser open and you still don't have a map. cawilson: You know, I'd have nothing to actually guide me as to all these options. No one, as I said earlier, the PowerPoint of the analysis, something I can show my family, you know, here it is. I can't go around showing with 20 or 30 tabs. cawilson: So imagine you know we're now I can just drag one tab on to another tab, drag and drop, basically, and it will build up a visual representation cawilson: Of my research and I can say, oh, look, I found this place. I found that place. This one's kind of beautiful park. This one's really nice, but there's no hospital nearby. cawilson: And this is what happens. So I see that as one scenario where, you know, the general public, just, you know, I think he up you know the fact I can just create this cawilson: Synthesis of my research in a map form rather intuitively being driven by the browser engine is suddenly tapping into some sort of plugin. cawilson: We also see other examples, we do a lot of work in the Arctic. cawilson: And you know, it's very important because this is, the Poles are being devastated by climate. cawilson: So how, and the people that live in the Arctic in these remote communities. cawilson: Learning about geography and APIs, and all this stuff is the absolute last thing on their mind they're dealing with, you know, cawilson: serious health issues, employment issues. cawilson: Clean water. cawilson: Very you know fundamentals to life. Peter Rushforth: Somebody on the chat pointed out that you know there's portals like Zillow and realestate.com available for like house search. And I guess that's true. But I guess it doesn't apply to Peter Rushforth: You know, while it might not be as relevant for the Arctic, for example. Peter Rushforth: For things that you're you're looking for in the Arctic, because I'm not sure they're on Zillow for one thing. cawilson: No, no, there's cawilson: Really, but I'm just what I'm suggesting is even, even with we have real estate sites, of course, you can get to that real estate site. But then when you get you get a listing cawilson: It's not showing what the hospital, is it doesn't say there's a Children's Hospital. It doesn't say if you know you know i don't get mugged when I walk out the door. You know you want all this ancillary information with, the questions is how to easily combine that in summary information. Peter Rushforth: Right. Okay. Well, another question that's come in is, what is the role and ultimate need of Peter Rushforth: Government in regards to mapping on the web. So maybe I'll hand that off to Sébastien from the Canadian geospatial platform. Sébastien Durand (Canada - NRCAN - CGP): That's a, that's a good question. Just to give some context. Sébastien Durand (Canada - NRCAN - CGP): The platform does a provide a stepping stone and answers they need from maybe half of the government departments and agencies. So that's the number of contributors, we have Sébastien Durand (Canada - NRCAN - CGP): We are in the process of onboarding almost all of the provinces and territories also just at least to gather information and then share it, but Sébastien Durand (Canada - NRCAN - CGP): After all that, you know, I think that to answer the question is Sébastien Durand (Canada - NRCAN - CGP): I would first want to go with what is the role of government in in all this. And how do we enroll government is, is to administer certainly an easy, an easy fact, Sébastien Durand (Canada - NRCAN - CGP): Now the question is, how does the government administer, technically you actually define rights, restrictions and responsibilities on features through time and space. So again, you kind of set up the framework that way. Sébastien Durand (Canada - NRCAN - CGP): Now what's unique about government is that we can legally define information as law so that information becomes authoritative and really provides an ultimate framework that can, you know, shape, decision making and operations. Sébastien Durand (Canada - NRCAN - CGP): The ultimate need of the government is to be able to leverage such ultimate framework. So now the platform moves into the cloud, for example, we're trying to establish all that properly. Sébastien Durand (Canada - NRCAN - CGP): But build the knowledge base over that framework so that we can then render authoritative map products. And I think the best example for that is, is COVID Sébastien Durand (Canada - NRCAN - CGP): Having a count of your local area on COVID cases is very pertinent. But everybody wants to see Sébastien Durand (Canada - NRCAN - CGP): Where's the hotspots. How does it go in time. What's the, what are the trends, so that you can actually represent properly the, the epidemiological situation associated with COVID Sébastien Durand (Canada - NRCAN - CGP): So, so that perspective requires actually an integrated perspective, it requires an effort from a coalition of groups that actually built on the authoratative of data to deliver something that is usable, the question about Sébastien Durand (Canada - NRCAN - CGP): Something that Jonathan mentioned before about about data being used, or sometimes not really used as much as I think it's not really the question. Sébastien Durand (Canada - NRCAN - CGP): We want to make the data out there available, but what we're missing is Sébastien Durand (Canada - NRCAN - CGP): We as technical experts or technocrats or John or Joe special experts, we need to bring the products, up to a point where it, it becomes a viable entity. Sébastien Durand (Canada - NRCAN - CGP): That can be consumed by anyone. And that's what actually makes the system work and and we see the OGC doing a fair amount of work from a backbone standpoint. Sébastien Durand (Canada - NRCAN - CGP): But in the end, this whole environment ecosystem. I'm a biologist from background information. I know that if if you cannot duplicate yourself if you cannot grow and spread your genes. You're not living Sébastien Durand (Canada - NRCAN - CGP): Your just a rock waiting for, you know, decay so that that living capacity needs to be provided through the mapping experience from the back-end up to the front-end whole experience so Sébastien Durand (Canada - NRCAN - CGP): The need of government from a mapping standpoint is to be able to connect to what matters so that we can deliver the right information in the consumable way to the users. Sébastien Durand (Canada - NRCAN - CGP): That is, to me, the real challenge. Peter Rushforth: Okay. Peter Rushforth: Thank you for that. Um, I guess I would encourage the other panelists to chime in with editorials on other on the panel responses just cawilson: Like just to add a point to that Sébastien just mentioned, about the role of government. cawilson: So if we consider you know you know what's popular on the web. You know, like I'll be honest I use Google Maps a lot when I have to go find something. I'm looking for a supplier. cawilson: A restaurant, I need driving directions, there's an accident on the road. It's great for that. And that's all. And you know a lot of that's monetized through advertising revenue cawilson: In that case, Google or whatever the platform is would receive cawilson: But government's responsibilities are very broad. As I mentioned, economic, social and environment. And government is not monetizing through advertising, government monetizes through taxes. cawilson: So in order to meet you know what the voters want ostensibly. So how does the richness of all all that data around, especially the environment, society and economy, make it into cawilson: mass market applications. I think that's a fundamental question for government. Peter Rushforth: Okay, Peter Rushforth: I have a question for Don from the audience up through the, through the Peter Rushforth: Gitter channel. Peter Rushforth: Are there special needs and requirements for maps for NASA like timeline dimension. don sullivan: Okay, I'm sorry I wasn't quite catching that timeline dimensions repeat the question please? Peter Rushforth: Are there special needs or requirements for maps for NASA like timeline dimensions or other things. don sullivan: Um, boy. Okay, so that they can be answered so many different ways. There, there certainly are. don sullivan: Time sensitive dimensions to almost everything we do, we're primarily data providers, although in the airborne science program where I spend most of my time, don sullivan: We're, we're data consumers primarily of aviation, that visualize really, really quickly and accurately. So yes, there is a, there certainly as a temporal domain to it. I'm still not exactly sure what the questions, go on. But, but, yes, the and again I'll take note of airborne science programs specifically don sullivan: We live with data that is s temporarily define and and both produce it and consume it. So if you could elaborate on the question a little bit. I'd be glad to go where the questioner don sullivan: Was heading. Peter Rushforth: Okay, well, Peter Rushforth: Let me see if there is more information. cawilson: And Peter and john I can probably compliment on that one a little bit cawilson: I was talking about the Arctic a little bit earlier. cawilson: And one of the goals for socializing right now is the notion of a six dimensional Arctic exhibition data infrastructure. So the six dimensions would be x, y and z, but based on any coordinate system, including discrete global grid systems which can also like well into MapML cawilson: And then can be anywhere from, you know, geology, right up to the atmosphere. The other, the other reference systems, of course, the other dimensions are time cawilson: Obviously for change detection. The next one is any scalar vectors. So anything with a direction and magnitude. So I'm thinking currents and migration. cawilson: Would be in that and the sixth one is what I would call grey literature. So the whole bibliographic community around the scientific literature, cause they all have a location as well and how will that be incorporated Peter Rushforth: Great. Peter Rushforth: Well, I guess in defense of the MapML specification. We try to Peter Rushforth: Pay attention to the WMS and WMTS use of dimensions. So you can in theory query the map source at any value of discrete dimension that is provided as a select list and I'll go through that in my breakout Peter Rushforth: But Peter Rushforth: So there's a question about, is it, the cost effectiveness of Peter Rushforth: Of Peter Rushforth: Maps in HTML or versus API implementations of it. And I think that the question is more, Peter Rushforth: And I'll put it out to the panel. I mean, I think the the idea of maps in HTML is to make it simple, like the simplest possible interface to get a basic map going and and the idea behind that is not to choose between APIs and Peter Rushforth: And client technology, but to have both, you know, to make them work compatibly and, so would simplifying the developer experience, let's say for at the low end Peter Rushforth: Or at the entry level, or simplifying the entry level make a difference to the consumption of your services. Is that something that Peter Rushforth: Would be of interest and valuable for your, for your business, your use cases. Peter Rushforth: And I'll maybe I'll put that to Emilio Emilio López (CNIG): Yes, thank you. Um, I was thinking that one product, at least for us when your web services are free. I'm hoping is that sometimes ah, We don't know Emilio López (CNIG): Very much about our clients. Emilio López (CNIG): Because Emilio López (CNIG): Yes, we know, then the number of requests. But, if you don't have information in the user agent or the fields of the HTTP protocol. It's impossible to know to know Emilio López (CNIG): Some very important information of our clients and this is a Emilio López (CNIG): Difficulty that we suffer with our services. Emilio López (CNIG): And I would like to say something about alternative data because always a mapping agencies talk about that our data Emilio López (CNIG): Alternative, but I think that it is not enough. For instance if you use topographic map from our National Geographic Institute and finally, you are lost in the forest. Emilio López (CNIG): We don't have any Emilio López (CNIG): There are not any legal implication, so that our data alternative, it's not enough. It's important, the quality and Emilio López (CNIG): Updating of the data. Emilio López (CNIG): Or the thing is for coverage data in this case in Spain, a cluster data. Emilio López (CNIG): Around our not only authorative, but are Emilio López (CNIG): legally binding as well. So I think that this is an important aspect of a government data sets and services. don sullivan: Peter this is Don, if I could pipe in for a second here. Peter Rushforth: Yes, please. don sullivan: Just a thought. And, and, again, maybe I'm almost face the rest of the panelists and folks online would correct me right away if I could please, or if you would please. don sullivan: But, but I'm looking at this as not being really issue of of authoritative or or more, who has it or month Sizing it. don sullivan: And again, maybe I'm being very simplistic, but I, as a consumer of geographic data visualizing in a browser. don sullivan: I'm really tired of having to deal with 'Am I going to use Leaflet, or Carto GD or MapShip and you know I mean about and how am I going to do the rendering and, you know, and don sullivan: And so now we we already have a system or in airborne science. We've got a visualization tool kit, a common operating picture don sullivan: System that we ingest regular web services. Well, we really need, you know, we really need other services, we really need threads. So now we've got threads in there too and and don sullivan: And I would love to, I would love to be able to write something really simple in HTML with a map tag or something like that and and I thought, that's kind of what this don sullivan: This whole thing was, was going to, um, so, so, correct me if I'm wrong but but but if we could just take the abstruction up to the to the very highest level. don sullivan: And aren't we talking about making it simpler and getting rid of a lot of these these questions, moving them moving them into different different layers of the picture. What am I missing. Peter Rushforth: Sébastien, I'll let you answer. Sébastien Durand (Canada - NRCAN - CGP): Well, I'm actually would like just to resonate with this, I think, I think this is actually a crucial requirement. Sébastien Durand (Canada - NRCAN - CGP): That's what I was trying to do with the opening statement. Sébastien Durand (Canada - NRCAN - CGP): 90% of the newly acquired data is geo referencing, as georeference. So we should by default try to facilitate the depiction of the depiction through a map capacity. Sébastien Durand (Canada - NRCAN - CGP): On HTML, through HTML. Make that barrier as simple as possible. The reason is from my standpoint as to why this is important. Sébastien Durand (Canada - NRCAN - CGP): We have a limited amount of resource, geo resource and technical experts within our organization and trying to sustain the communication requirements associated with all of these data whether or not they are authoritative Sébastien Durand (Canada - NRCAN - CGP): We can't, we can't even making a nudge to the domain. Sébastien Durand (Canada - NRCAN - CGP): It's like saying, that's trying to ah, Sébastien Durand (Canada - NRCAN - CGP): It's a communication tool that communication to be as simple as possible. And because most of the information nowadays is geoenabled, HTML should be directly geo enable, that means have the capacity to show that information. Sébastien Durand (Canada - NRCAN - CGP): That barebone requirement in my, in my perspective. Peter Rushforth: I mean, I guess the only editorial I can comment, try, try and combine what Don was asking, With Peter Rushforth: My view is that Peter Rushforth: The user is the integrating Peter Rushforth: Person, element in this architecture right like, HTML is made for users. It's designed for accessibility elements bring Peter Rushforth: Feature set users need to interact with with the content. So, I mean, Peter Rushforth: It's not that you can't do these things in in script or in programming. It's that Peter Rushforth: It's that the the common facilities that users need can be built into the Peter Rushforth: Language of the web. And so, you know, maps are very much a user oriented thing. And I think that we need to think about. I mean the difference between thinking about it, things like API's and services and thinking about Peter Rushforth: A facility in HTML is, the difference is the user right in an API and in a service you're thinking about the user being a programmer. Peter Rushforth: Whereas when you're thinking about providing something in HTML, you're thinking about the user is the person sitting, consuming the thing that you're producing Peter Rushforth: And so that's the difference. So I think it's a mindset thing. So web developers are thinking about that user when they produce. Ideally, they're thinking hard about that user when they produce their websites. Um, but we have the the HTML layer that we have, in theory, access to Peter Rushforth: From it at design time. And so I think that what what the Maps4HTML initiative is trying to do is to get the geospatial community to think about how can we bring the factors that affect all users Peter Rushforth: When using maps, into that common framework and let, Peter Rushforth: Web developers can should be able to enhance that. But there should be, we should think about how people consume maps and spatial information at the standards level as well. cawilson: And just a comment a little bit more on Don's point cawilson: So Don, I believe these certain when you started your time. He said, You didn't think this was related to cawilson: The data reliability or the authoratative of the data and to monetization. I agree with you. I think the authoritative data. This is just another channel. So the data is either authoritative or nonauthoritative with or without MapML cawilson: The monetization point though. I think the point around that. As you know, the very popular web interfaces, we see today are based on advertising. cawilson: And I think there's the, but as I said, that's just a veneer of the data. So how do we get all the other data, you know the rest of the iceberg. cawilson: Available in an easy to use format, just to save you said like, no, you can't expect the average user to start playing with Leaflet or whatever. So why isn't this just a simple browser query and integration within the browser should be that simple, using you know simple languages like HTML. Sébastien Durand (Canada - NRCAN - CGP): And I just want to add another thing there about the comment about authoratativeness of the data. I understand it's not the topic of that discussion, but Sébastien Durand (Canada - NRCAN - CGP): It is important when you put yourself in the in the shoes of anyone trying to make a map for whatever reason. Sébastien Durand (Canada - NRCAN - CGP): If they can have confidence in the product that they will produce, that is important and and at the DG level when I create something they all want to know where the information comes from Sébastien Durand (Canada - NRCAN - CGP): So that they can have confidence in the product so that, that concept of authoritative nurse or legally binding data is actually quite critical. Sébastien Durand (Canada - NRCAN - CGP): And should be conveyed throughout the application down to the end user. Sébastien Durand (Canada - NRCAN - CGP): But in a nutshell. Even if you have the best infrastructure around with all that authoritative data, legally binding. If you're not enabling the users to easily create those products on the, on the page, it's Sébastien Durand (Canada - NRCAN - CGP): Again bottleneck in communication and Sébastien Durand (Canada - NRCAN - CGP): Again COVID. I was pretty engaged in COVID this year and trying to provide again a response to different departments, and I can tell you that making those maps were Sébastien Durand (Canada - NRCAN - CGP): extremely painful. It was a painful process and just try to find Sébastien Durand (Canada - NRCAN - CGP): The proper ways to do that communication, making sure that the map products, but also the dashboards and all those things were actually meeting requirements, Sébastien Durand (Canada - NRCAN - CGP): from WCAG assessment, the Canadian government web template and all those things, these are the type of of hurdles we have to go through when we want to push any information out there to the public. We need to make sure it is Sébastien Durand (Canada - NRCAN - CGP): consumable and meets all the laws. What we have to do it relatively short, like in a short time fashion when it's to address and answer a crisis such as COVID Sébastien Durand (Canada - NRCAN - CGP): So that brings back even more the requirement to have a simple well vetted integrated solution that is ideally Sébastien Durand (Canada - NRCAN - CGP): Directly supported by the browser developers so that we can just okay, let's rely on that thing. It is really a standard. It's not a. It's not a schema or whatever it is a standard for all to depict, Sébastien Durand (Canada - NRCAN - CGP): That it's the 'Go-To' way to make a map on the web. And that would be a big, big, big uplift our capacity to to connect, interpret and make the information interoperable. Sébastien Durand (Canada - NRCAN - CGP): And give the tools and ammunition for anybody who has to communicate something important to the web, give them the tools to do so. Sébastien Durand (Canada - NRCAN - CGP): Anyway, my perspective again. don sullivan: You know, I like I completely. I completely agree. And also I wanted to make sure that that I'm not leaving a perception that don sullivan: That I'm saying accuracy is not important. Or, or, you know, some sort of quality metric is not important, Sébastien and Cameron, please. I don sullivan: Didn't mean to say that at all. As a matter of fact, I would suggest that that don sullivan: We reconsider our traditional metrics for for accuracy. I mean, you know, we deal with some, you know, where's it on the on the ground run, or three space and six space and and don sullivan: And so we're going to use the geological surveys plus or minus 40 meters accuracy or we're going to use the don sullivan: The, the firefighters. I mean I deal with them with wildfires and imaging fires a lot and and there don sullivan: The accuracy metric I got from them is, don't put fire on the wrong side of the road. So now we're talking plus or minus a meter absolute accuracy. So, so, so I think we need to to rethink that. don sullivan: There's a, there's a group in the organization called AISA aeroscience information partnerships that is looking at that whole that whole issue and they've come up with like don sullivan: I consider a really novel and valuable approach and its operational readiness level. So it sort of abstracts don sullivan: The idea of accuracy and and you know and data quality into usability, you know. Is it is it good for this, this group, or is it the good for this group. And that's an orthogonal don sullivan: Issue to maps on the web, but it's certainly important. So again, I wanted to make sure that I wasn't proceed denigrating accuracy or or or quality in any fashion. don sullivan: Other than saying that was that was orthogonal to putting it as putting a map as a first class citizen HTML. So, so one to get the in before the end of the panel. I wanted to make sure that wasn't leaving you on the pressure. My apologies. Sébastien Durand (Canada - NRCAN - CGP): Oh, that's good. Sébastien Durand (Canada - NRCAN - CGP): Obviously coming from tjhat side, 'accuracy doesn't matter', would have issues. Peter Rushforth: Okay, well, Peter Rushforth: I think the panel has about run its course. But I, but I would like to extend my thanks to Emilio and Don and Sébastien and Cameron for being willing participants and in the discussion and Peter Rushforth: I'm going to hang around on Gitter for a long time, another two weeks. So anyhow, I hope that they will tune in on Gitter as well and potentially interact with other members of the audience Peter Rushforth: There so I'll be posting links to the the presentations and the discourse. Peter Rushforth: Discussions about, about those things. So those are good places to comment, make comments about, about thing those presentations for the authors to get feedback about and to answer questions or whatever. Peter Rushforth: So, Peter Rushforth: If maybe I'll just pull the program committee if they have other words, but I think we're pretty much ready to close at this point. Peter Rushforth: Hearing none. Peter Rushforth: I will thank everyone for participating today and look forward to chatting with you online. Francesco Bartoli: Thank you. don sullivan: Thank you.