of you, and how you can do that using the ogc-geo-package standard. So stay with us.

Next one. Let me see if this works. This is the problem, no? Yeah, okay. So no? Okay,

the PDF reader misinterpreted some images, but it's okay. So the first thing I wanted

to tell you about is, before everything, I wanted to show you some scenarios, which hopefully are familiar to you. So the first scenario is about Linu, who has been working

with GIS, assembling all this information about his favorite spot, and then suddenly he wants to share his Quanto.js project with his neighbor. But there is just one problem. His neighbor doesn't have any internet connection. So wouldn't it be really

nice if Linu could just pop up the project in a USB stick with all the data, all the information, and just pass this USB stick to his neighbor? So the second scenario is that, although he's a free and open source geek, at this day time Linu is working with

Esri software, with proprietary software. So he's been working in this project for a while, and now he wants to share the project with his colleagues from a different office. But there is just one problem. The people in the other office, they just

work with a free and open source software, and they don't have any Esri licenses. So wouldn't it be really nice if Linu could just export the project in ArcGIS and

then load it in the other end, in Quanto.js? I think many people in this room have probably been there. And these were our motivations to start thinking how we can support

these scenarios. And this part played a role in the OGC Geopackage, which my colleague is going to tell you a little bit more about. OGC Geopackage is mainly a container for data exchange. So I made my first talk

in Barcelona about Spatial Light, the shapefile of the future, which eventually became the Geopackage, the shapefile of the future. It has the advantage that it can store, roster, and record our data in one single file, which has a database-like interface

through a library, which is this SQLite database, this file-based database. And in the meantime, this is reality. Geopackage is here. Many vendors support Geopackage.

And so what we are showing here is the next step. And we're using one mechanism of Geopackage, which are extensions. The Geopackage standard is not so big. It has the minimal things in it, which are needed, and then they define extensions.

And there are some extensions which are mentioned in the spec. For instance, nonlinear jointly types, curves, and so on, and also spatial indexes. And you're free to write your own extensions. And there is, in the meantime,

a kind of informal third-party extension registry, where you can ask for it to be listed. And there are already quite some extensions, which are defined for storing, like maybe PyCloud data or what else, in a Geopackage file.

And what we define is an extension for storing styles in a Geopackage. And what we've done, we have written a QGIS plugin.

This was done by an intern of us, Sele Kristin, and me. And our goal was to exchange data and styles between the QGIS users. And later it was extended by Geocat. More about that later.

This plugin is quite easy. It has mainly two buttons. You can store your project in a Geopackage and load from a Geopackage. And it has also a command line tool for doing the same thing on a command line.

And the third functionality is shown later, which is not only storing QGIS project information, but also OWS SLE styling in the Geopackage. So the goal here is the first goal. I have QGIS.

I want to store, I have data in the Geopackage. I want to store the project and the resources it needs. And on a different QGIS installation, I can take this Geopackage and have everything I need. And the data ends the project. I'll show how this looks like.

Okay, I'm loading a Geopackage here. Two layers. I'm styling the vector layer. Simple style. Adding a label. The next thing is I'm adding a print composer print layout.

And now the next step is to store this styling information in the Geopackage.

This has happened now. I close the project and start from scratch. And then I load from a whole project from a Geopackage and get exactly the same map. I have the data from Geopackage and styling from Geopackage.

And also the print composer. Together with images like logos in the print composer and so on are included in this Geopackage.

Okay, so now about the other extensions, the OWS extension. As I said, it was targeting a scenario of migration between different GIS systems.

Eventually not only desktop. It could be also between server-side systems. So the goal was to have interoperability. And for that we focus on using standards, OGC standards.

So in this case the style is encoded in a table as an SLD. And the project information is stored using the OWS context standard. So there we have all the information about which layers are loaded, what is the layer order,

some information about the project, like project name, abstract, and so on. And then apart from that we also store, as in the other extension, the data and associated resources.

So what I would like to show you about is the complete workflow. So going from proprietary software, ArcGIS, and then to Quantum GIS. And for that we use Geocat Bridge, which is an ArcGIS extension.

The developer of Bridge is sitting here. So if you want you can just contact him later for more information or even for a demo. So what Bridge does is encoding the ArcGIS project in this geopackage using the OWS extension.

And this enables us in the other end, in Quantum GIS, to open the project using the Quantum GIS plugin, the geopackage plugin. So I'm going to also do a demo here.

Okay, so you can see here, this is yours.

I always try to... Okay, so not this one. Okay, here it is. Let's see if I can push it a bit further. So you can see here, in ArcGIS, we have a project complete with layers and styling.

And now we are going to save it using the Bridge extension. We are going to export it to the geopackage format. And now we go to Quantum GIS. QGIS. Sorry, you don't say Quantum GIS anymore.

And we load the geopackage we just exported. And you can see it here. So you have exactly the same project. So I think what we show now, just to compare, they are the same.

And just quickly we show you a little bit how it is within the geopackage.

So as you may know, geopackage is an SQLite database. So here you have the different tables where we store the different components of information. So this is where we store the context and is using the OGC standard.

You can see here the different tables. So both of these extensions, the specification is published in the same GitHub repository where you have the plugin.

So we also have metadata. It's a good idea to mention that it's also stored in the geopackage.

Unfortunately, we don't know much with it in Quantum GIS and QGIS because there's not much support yet for metadata and QGIS. If you come to my talk tomorrow, we are going to discuss a little bit about the roadmap for metadata in QGIS.

So this is the point where we talk about future developments. So I don't know if you want to say something. I mean, there was an experiment said that initially this was a geocat fork.

The plugin developed this extension, but now they are merged. So now you have a plugin which supports both scenarios, so both extensions. It was merged and is already available on the plugin repository from QGIS.

So you can download it and try it in your computer. It's experimental, so you need to make sure you check this plug-on. And there are still a few things that are missing.

I don't know if you want to… The missing thing is that the SLD of WOS is only one way, so we can't export from QGIS to WOS SLD. And also the command line interface does not support this new functionality.

But yeah, it is published. It's still kind of proof of concept, so we're looking for users. We're looking for people who have a need for that, giving us feedback.

We're open for feedback, and I think we made it because it is a good thing. We think it's possible, so we do it. But now we're looking for people working with that and using that. These are all the links to your package,

and the second one is the source code of the plugin, but you only have to install it as a QGIS plugin, so you don't need all these links. But yeah, it's everything open source. That's it. Thank you very much.

Now we've got about… You guys finished a little bit early, so we actually have a little bit over five minutes for questions. So I'm going to start off with a question. I work on the GeoSuger project, and we also work with SLD and interoperability.

And we've had some difficulties with the SLD support in QGIS, and one of our members, Andrea Amy, has gone in and fixed up some of that functionality, such as labeling. Do you know of any plans or any enthusiasm towards working on this kind of interoperability?

Yes, it's mainly coming from the GeoService side that we are improving the SLD export in QGIS. I think there are pull requests coming, and there are also coming calls for financing improvements of that.

But I think that's really a good way to go, that we have improved SLD export of QGIS, and then we can either directly export for use in GeoServer, or we can export in the GeoPackage

for an exchange of data together with styles. I think it will come. I mean, the interest directly from the QGIS community is not that big because they don't win much with that. I think the interest is coming from GeoServer

or from other SLD users. Other questions?

The first one was correspondence between QGIS and ArcGIS. Maybe Anton wants to reply to this.

Okay. Can you repeat? Yes. The question is if we have any set correspondence between the styles exported from QGIS, what it is, and the different way as well.

So it's only one way. It's only one way. So right now, you can only write the styles in ArcGIS and then load them in QGIS. Oh, I see. So we don't have the other scenario yet. And we have another correspondence or there is some limit?

Not 100%. So if I remember well, there were some features that were not supported, like more complex features of the styles. I don't remember exactly, but yeah. So the example that you saw, it was quite simple, but there are some scenarios that are not as simple.

There are also challenges with SRE icons, which you're not really allowed to use on the platform. So I guess you would also need to implement some mapping between SRE icon fonts and open mapping.

And regarding the license, Bridge is a license tool. So you need to purchase a license. Any more questions? Okay, lots of questions.

You may not speak. Yes, thank you. Actually, it's not exactly a question. I would like to make a recommendation about interoperability. I would just like to add that the current state of software, SRE, QGIS, and those software, for interoperability, I would strongly recommend

to use an equal net reference system with access in degrees and meters and avoid other units. The reason for that is that the CRS is specified in the window text format. This format was defined 20 years ago and add ambiguity in the way that it defined a unit of measurement.

This ambiguity has been fixed later, but most software, including JEDA, has not followed the clarification and JEDA interprets the unit in a way which is different than what the Joe package software,

the Joe package standard asks. So the OGC is aware of this issue and for this reason, they have defined a new window text format, which is window text 2, published last year, which is now ISO 9162. So the best fix for resolving this interoperability issue

is to use the window text 2 format. But there is very few software at this time that support window text 2. There is SRE. JEDA does not yet support it. So in the current state, to avoid interoperability issue, I recommend to use only degrees and meters.

I just wanted to clarify that. I think it was a comment, so I'm not in on the questions now. I'm not going to say anything.

We have time for one? Does the Geocap bridge plugin support annotations from ArcGIS to QGIS?

There is limited support for annotation. It has the capability to export the annotation layers to a shapefile and then to style the labels,

but it doesn't really work. You don't really get the same results entirely. Please stand up, sir. Sorry. Sorry. So the annotation, there is limited support for annotations because it won't entirely look the same as in ArcGIS, as in QGIS.

And I don't have any experience with how it, in the end, will look in QGIS. Also in bridge, it's still sort of proof of concept for the moment, and there's still some features missing. I'd like to thank our presenters here and a little bit of air support.

Where can they find you if they'd like to ask questions after this? Do you guys have a booth that you can visit at? Yes, we have a booth. Okay, so please follow up with Geocat and South Pole? South Pole, yeah. Yeah, after this. Okay. And can I just invite everyone to thank them? Thank you.