Just kind of very quick introduction of kind of what 50 to North is. So it's a long time, the spatial information research company, a kind of nonprofit private research

organization in the field of geoinformatics. And our background, kind of how do we work? We work in kind of publicly and privately funded R&D projects, and also provide professional services to develop mostly open source solutions to different customers to kind of resolve their problems.

And what we're kind of keen on is fostering open science through open data and open source software. So while also kind of supporting education in the field of geoinformatics and spatial statistics. And we have a couple of shareholders, which is kind of University of Munster and the Institute for Geoinformatics in particular, University of Trent with the ITC and two companies

Conterra from Munster and Esri from Redlands, you all know. I would like to shed some light on kind of research projects that we currently do. And one is the Mari Data Research Project, kind of the overall aim to kind of reduce the emissions of cargo ships worldwide. And the aim is kind of to go there by kind of

10% cut down just by kind of improving how the ships are operated and how the routing is done just based on kind of hydrodynamical optimizations based by the idea, if we can put in kind of much more environmental data and forecasts to kind of better plan the routes of the ships and also kind of decide how the ship should lay in the water and do some kind of optimizations there.

It's a long list of partners on this project. It's funded by the Federal Ministry of Economic Affairs and Energy in Germany. So let's start with more deep rated. So the challenge of Mari Data is kind of, we kind of have a route going from harbor A to harbor B and someone will know which is the best way.

Of course, you could start with the shortest pass that we can travel. Avoiding islands, of course, this does work. But of course, we can also kind of add some additional data that we have these days, basically from the Copernicus Marine Environmental Monitoring Service. We can add very detailed forecast for the next up to kind of few weeks, what can be the sea state.

So it's gonna be wind speed, wind directions, wave heights, wave directions, and all these obviously have an impact on the energy demand of the ship, but they also kind of set of constraints. So we have to meet the schedule, we have to be there on time. The ship has certain properties that has an influence kind of based on the Hollis design, also what kind of maximum speed the ship can go.

And of course, there's some tidal effects, some permanent currents and some temporal currents we have to take into account. So kind of get a complex system we have to optimize here. The major components that affect the energy demand of a ship, so the dimension and load of the ship, which kind of leads to displacement and they're kind of mainly to different draw

than the bow in the rear, which kind of makes a difference. So changing this by kind of one meter might kind of increase or reduce the energy demand by like 5% or something, which is kind of substantial or very kind of small change at no cost more or less. So that's kind of in some of the trim. We also have waves, currents, wind, water temperature and salinity

kind of have an impact as well, because it kind of depends how easily the ship may go through the water and also how deep it kind of goes into the water. And what you see kind of here in the pictures, kind of where the energy is used on a typical cargo ship. So it's more like 40% is going into the propulsion and the entire kind of movement of the ship

and that's kind of the best part we can target here to reduce the energy demand. So a bunch of data demands, the data sources. So we have the marked trajectories of the ships, this kind of observed data on what was the engine load, what was the fuel consumption, we have set of vector data, kind of current position in the ship states, tabular data, which is like the summation,

charter orders, schedules we have to follow. We also have like raster data, the earth observation data, one of the CMAMs data, which is mainly the forecast, base maps, a lot of electronic nautical charge to kind of find the right way, knowing where are kind of obstacles, where are kind of environmental protection zones

we have to kind of avoid by kind of planning our routes and a lot more. And we also have a kind of a zoo of different file types and APIs we would like to use and access to get data from different sources. So it's a very kind of mixed system with all kinds of file types, data types and APIs would like to use and to include here.

What you currently have and which kind of already helps a lot, it's a very simple web interface, but just to get a unified data access. So we have different data providers providing us with wind speeds, wave heights and so forth. And kind of just have a unified data access right now, we can just kind of pick up the different variables we are interested in

and also can kind of select them at different file formats, select temporal ranges and to just get one file back with all the data in it. And this especially helps our research partners work on the hydrodynamical optimization because they can get real data and kind of what was the condition

where the ship has been traveling when they received the data. What we also can do currently, so it's still in the first year, we got some reported data from our partners in the project and we can now kind of integrate this data into the data spectrum

and also combine it with environmental data and also look at the data that they provided us in terms of the maximum engine load. So these lines on the bottom are the different engine loads during the journey of this ship here. And they typically have their main engine and Oxley engines. So the ship on its own, a couple of components that have to kind of play well

with each other. And we use this data obviously to kind of learn about how the energy demand develops through traveling through sea and those kinds of to train our models later on to kind of have better predictions of what the energy demand might be in the end. With that we use machine learning approaches. Also just kind of this few routes we have from the partner

but we use the AIS system, which is kind of every ship on sea has kind of sent the signal and sent positions and sea state and different information. So combine this data with the environmental data we have seen. So salinity wind speed verified and so forth. And can kind of understand based on the machine learning model, what drives the energy demand of a ship

and how well can we model it in the end. And just when we understand what drives the energy demand we can also control our machine learning optimization to find the best route with the lowest energy demand in the end. The immediate results we have. So we do this kind of estimation of speed over ground

and course over ground. The course over ground and speeds are kind of different from the heading and the true speed in water, of course. And that's what we can kind of estimate from the machine model quite well so far. And what we can see, so if you have different environmental conditions, different weather conditions, we can see how the ship slows down

and how the energy demand would increase if you would try to have the same speed forward. Now we can see kind of what are the effects of these different variables. Next step then is to kind of use machine learning routing approaches to find the best way through the water from harbor A to B.

And it's by nature a multiple objective optimization problem. So we try different algorithms here. So thinking about generalized adaptive A star, genetic approaches that should kind of prove model could also go up to reinforcement learning. So we kind of tried to find the best route here through simulations and then kind of combine different routes,

different simulations to find the overall best route. And of course with different criteria, we have to look at the travel distance with a certain velocity, kind of time span and can approximate the fuel consumption that we have had during the simulated routing at this time point T and can just kind of have to look at the ETA,

the estimated time of arrival, a couple of safety constraints. Of course you can't suggest route for the ship to go, the cargo is at risk or the ship entirely is at risk because the weather is kind of too heavy. So the additional constraints we have to follow and different actions we can take during this simulation would be kind of change the heading,

speed up, slow down obviously, could also tolerate a delay, a waiting time because if you're not in time at the harbor, you either have to wait, which costs money or you have to kind of pay extra because you're being late or might even kind of lose your slot at all. So it's kind of pretty expensive of course because you can't sell the goods you have on board.

What else is, we of course need also analysis-ready data. We've kind of briefly seen in the talk before. So the definition isn't pretty clear from here at least what analysis-ready data actually is. So it really depends on the use case and depends on the modeler and what kind of how a theme the model is to do some extra steps or not.

Obviously we don't want to start with the raw data and have to kind of make this data ready for our use case. And then the MariData project, these kind of use cases will provide environmental data for the routing applications. So we have kind of space cross time corridors along trajectories that we would like to efficiently extract from our data cube

and to provide to the machine learning infrastructure kind of to find the best route within this corridor along space time. So kind of thinking of, well, so tubes in a space time creep. You're thinking about reducing environmental data through hydrodynamic models. So the hydrodynamic team,

they provide models kind of how the impact the energy demand on the ship looks if you have kind of different input parameters. And we could just kind of reduce the amount of data we have to send to the ship to do the optimization on board. We could reduce the dimension already in the data cube, providing these models on top of the data cube and then just kind of sending the estimated energy demand

throughout the ship and the ship can then just find the best route through this space time corridor. Of course, we have to directly integrate the entire processing with Python machine learning in processing workflows. So there's no sense kind of sending data around. We have to make it kind of in close to the data.

So we explore different solutions. We're looking to do you know, and kind of write how cloud ready it is for our purpose. So combining the three data stores, which didn't work out so well in the first place, but kind of could be improved and was kind of sufficient solution in the end.

So what's really nice about Geonote is consequent use of interoperable interfaces. So it makes it very easy to extend and enlarge an entire ecosystem. And it's based on established open source software, obviously, and why it's not yet cloud native by how it's available right now,

but there are kind of certain additions you can make. And what we're lacking here is kind of the native processing environment. And we also tried the open data cube, which worked well for a set of products with the unique part access and the different data sources combined in the data cube, especially for geo chips we used it.

And it works pretty well. And so we also provided a kind of PI geo API provider for the open data cube to make it easier to integrate an entire system and inserted geo chip data, digital elevation data, and so forth. Well, different product,

not the marine product in the first place. Use of cloud deployment, which kind of works pretty well. And now have kind of the APIs, OGC APIs, coverages, records, and processes, which are available for geo API here. So what's kind of nice to have the Netherlands ready data in place in the open data cube, that's entirely Python based.

So it's actually pretty easy to integrate it with the Python based AI approaches. And so we'd like to, in the future work, extend, adopt it to meet our data management and also further evaluate the cloud technologies staying at three cloud also match geo chip. Just quickly, the architecture of our marine data system that we currently have.

So a bunch of data sets at the bottom, geo node layer, more or less in between, feed it by PI geo API and geo server, providing different OGC APIs and custom APIs to the geo portal that you provide to the marine data users, the routing application, and also to this decision support system, which is going to be the system running on board of the ship to guide the crew

to find the best route from harbor A to B. Second project, I briefly want to mention just two slides very related because it helped us also to kind of define this entire data infrastructure, research data infrastructure. The Ithaca project and kind of the idea here

is the motivation is to bridge the gap between domain knowledge and infrastructure. So we have many metal walls kind of very keen on doing machine learning algorithms, but they kind of don't know how to get the data in. We are in this room, but kind of larger audience and kind of set of partners from universities and research institutes in Germany,

and we're gonna work on different sets of applications. And in the kind of framework of the KISSA project, we're gonna also host the next year's open geo summer school, hopefully mostly in person, but most likely also as a hybrid event, at least in some sessions. The challenge of the KISSA project

is also access across different data providers. So every application have different data sources. And also we'd like to support different analytical infrastructures. So being able to use it locally, being able to within the clouds, but also on a high performance computing cluster and usually here and especially in the different fields of applications, what you see in the right hand side.

So we have like cloud prediction, snow and ice prediction, water quality and water resources up to rainfall, which goes into a gravitational aspects. So kind of health of plants and it goes kind of all together in the atmosphere. So we can look at all these five different use cases and we're gonna want to build in the end

is also the e-learning platform to make it easier for practitioners or such people new to AI and machine learning in the field of geo applications to make it easier for them to kind of use these tools there. In summary, what we learned is kind of, we need to move towards kind of integrated research data infrastructure.

So it's not just spatial data. We also have to kind of get in more data and different data resources and also provide help kind of along the entire research process. So not just having data here, but we're also kind of finding data, acquiring data, pre-processing data up to kind of revenue of data and models.

So that's something kind of we learned from these two projects here. The typical processing patterns we'd like to support. We think that standardization will help us kind of make the system easy to adopt to other use cases and to make it easier standards. We're looking forward to a cloud-like deployment, but have in mind that it's gonna be

most likely federated systems. So different data sources in different places, but should be kind of for the user, for the front-end user, it should kind of just behave like a one-play system with a single unified interface, no matter what the data is in the background. And we will build on existing frameworks, GeoNode, NetCDF formats.

And well, next on the agenda is kind of to further look into stack and cloud optimized geotiffs. And the deployment so far is cloud-based, but it's not really native cloud-based scaling. So there's a bit more work to do.