Processing conservation indicators with open source tools: lessons learnt from the Digital Observatory for Protected Areas
CC Attribution 4.0 International:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Bastin, Lucy
Mandrici, Andrea
Battistella, Luca
Presenters: Lucy Bastin, Andrea Mandrici, & Luca Battistella - Joint Research Centre of the European Commission
 Good morning everybody. Today we are going to talk about the Digital Observatory for Protected Areas, especially focused on the workflow that allows us to process, visualize and share the geospatial data and indicators. The Digital Observatory for Protected Areas is under development at the JRC, the Joint Research Centre of the European Commission. I'm going to spend just a couple of words about the JRC. So the Joint Research Centre is the research body of the European Commission and provides scientific and technical support to the policy makers at the EU, and it deals with a broad range of topics. Today we are mainly going to be focused on protected areas. So what is the Digital Observatory for Protected Areas? It's a global reference information system that provides a wide range of indicators and is a support for policy makers at the European Commission, but not only also to other countries and other organizations like the Convention on Biological Diversity in Montreal. So I'm going to be focused now more on the application and the rest APIs that we provide. So what you can actually do with the Digital Observatory for Protected Areas? Well, it depends. If you are a developer, you can use our rest APIs to include them, include indicators or geospatial data in your web application. If you are an end user, a scientist, you can query and search out of more than 21,000 protected areas and get summary results very quickly at protected area level, at the country, ecoregion and soon region level. Then we have dedicated pages for protected areas, countries and ecoregion. So here is an example of a dashboard, a protected dashboard. In the right side you see the water occurrence map and the statistics down below, and on the left side you see the land cover on the top and the land cover change on the bottom. So to better understand the processing that allows us to show this kind of data, I will give the floor to Andrea, which is the geospatial developer, and we are working together more in the front end part. Morning everybody. Now that the output should be clear, let's go back to this picture and see the first part of the workflow, the one on the left, by element, but not necessarily in this order. We use peer-reviewed methods to calculate indicators on state pressures and threats. For instance, the disconnectivity indicator evaluates if a protected area is well connected to others, in the way to allow movement of animals considering different dispersal capacities. This specific indicator at the moment takes long time to be calculated and updated. Many indicators were developed independently, one from another, by different developers, sometimes with a desktop-based approach. At the moment we have something like 396 indicators to update, all of them global. Time matters and how often can we update our service? We use, talk about data, we use openly available data set with clearly documented provenance, including some high quality data set developed in-house at JRC. I give you a quick couple of examples. We use the global surface water 30-meter product, derived from 30 years of Landsat data, more than 2 million since, to calculate statistics on permanent seasonal water within each protected area of the world. And to calculate statistics on human pressures on protected areas, we evaluate the use of the global human settlement map, this one also developed at JRC by another unit. At the moment the real solution of this is 250 meters, but a 38-meter resolution version is planned. Let's see some external data set that we use. How is made our country-based data set? We start from the last versions of the global administrative unit layer and the last version of the exclusive economic zones. They use these two data sets, use different coastlines, they have different attribute structures and they share only isotric code as a common field. We keep all the information related to disputed areas that come with the sources. And we merge them using mainly postures where they overlap Gaul winds. For problematic coastlines for number of vertices like in Chile, Alaska, Canada, Norway, all these difficult coastlines, we use some SAGA processing models in QGIS, that was very effective. Then due to different coastlines we have holes that we fill with desktop approach. We tested many automated procedures, they work more or less, but we wanted someone really thinking where to assign the empty polygons, especially near the borders. Then we dissolve the two merged information on the isotry field and we join any other ancillary information as the isotric code on or the UNM49 codes. We review the newsletter of ISO admin of the last 10 years to do this. Let's see another external data set that how we always made our ecoregions data set. We start from the last terrestrial marine and marine ecoregions and pelagic provinces. They have similar attribute structure and marine ecoregions are less not cut on the coastline. So we merge them smoothly, much more than the previous data set using postures and where they overlap terrestrial ecoregion winds. There are no holes to be filled here because there is always intersection with marine and terrestrial ecoregion because the marine are not cut on the coastline. Then we merge countries and ecoregions and we obtain our base layer that has 2018 objects, which can give us information on how much surface of a country is covered by one ecoregion, or is marine or terrestrial or the opposite, how much of an ecoregion is covered by a country and so on. If we intersect this one with other data set like protected areas or land cover, we get more complex indicators such as how much surface of a country is protected or is covered by a portion of a protected region and so on. This layer can become a postage topology and not a simple feature, but we had a problem in the very last step, that is the merge of the country and ecoregions, that we made quickly with ArcGIS Pro, which introduced some geometric artifacts that were not present in the two original sources for which we check the topology within ArcGIS. We are going to merge them again using grass. A key data set that DOPA uses is the world that are based on protected areas. This data set presents technical challenges for us and legal restrictions, technical challenges which are big, it's over 200,000 polygons, some of them with very complex geometry. The most complex is in Sweden, has over 862 vertices, and because of this nature, it's more a collection of shapefiles, simple features, most of them overlapping each other than a structured geodata base. There are some problems on some 1000 geometries such as self-intersection, which ArcGIS can open nicely but postage doesn't open, and doesn't have a versioning from the author, and it's updated every month. Legal restrictions, the data set is open but we cannot redistribute it. We do not want to build a grass or postage topology for this data set, since it would be a reasonably complex time consuming and will introduce more problems. This data set goes through many pre-processing and processing steps, using different tools like postage, Google Earth Engine, Radoop, GDAL, up to grass at the moment. For pre-processing, we mainly clean up, we use tools of postage to do it. Each time that we get a new version, we must do a new clean up again. We filter on some fields following the author recommendations, we buffer 10 km around each protected area to calculate external pressures, and at the moment we rasterize it, looping through each individual PA protected area, with a resolution at the moment of 100 meters at the equator, but not long WGS84 project. And at the end we send it to grass to make analysis. We introduce one of the many thematic layers that we query with the base layers. This is the 2017 European Space Agency Climate Change Initiative, Lankover EAR product, from 1992 to 2015, 300 meters resolution. We use of these five epochs from 19 to 2015 with five year steps, with four levels of aggregation, the original is 38 classes, we aggregate up to four classes, the one on the left, the one that you see on the map, to analyze Lankover. Then we calculate Lankover change from which category to which category, which surface using grass. We do it on the most aggregated reclass on the whole period from 1992 to 2015, one epoch of the whole period, because if we go deeper, we get millions of combinations of classes or epochs. Okay, now that we know something about our base and thematic data, we put them together, let's see how we put them together. We use the protected area as an example of base data, but these steps are valid also for countries and ego regions. And we calculate statistical Lankover as an example of thematic data. All this process that you see, they happen using a couple of post-gis and grass scripts. This is an area of Italy where many protected areas overlap. We select one of these protected areas, that is the Sibylini National Park, which has an area that is bigger than 50 square kilometers. We process areas bigger than 50 square kilometers. This gives us 10% of the number of the global protected areas, that is 21,000 out of 215,000, but give us the 99% of surface protected globally. Last run, we started from rasterized protected area. Next time, we would like to split each protected area as post-gis views. The script on the right is the one that loop through and split the protected areas and import each view in grass as vector. Around this protected area, we build a buffer of 10 kilometers around the area to calculate external pressures. Last run, we used buffers prepared using ADUP. We are testing using post-gis and grass. There are problems on protected areas that cross the data line, where the buffer falls over the geographical limit. ArcGIS doesn't create problems on this side, but is slow and often creates self-intersection, and we should clean up again the output. You can see that part of this buffer overlaps other protected areas. We build a flat global protected area, a union of all the protected areas. Last run, we did raster using GDAL, but there is a dissolve that is running right now at home. To do it vector, to merge all the protected areas vector, we need to split by blocks of 50,000 to avoid any memory overflow. Then we erase whatever is protected from the buffer using the just mentioned flat protected layer. Last run, we did raster using grass. There are no problems of doing it vector in post-gis if inputs are clean. And finally, we calculate statistics as category extension and land cover change, overlaying the protected area and buffer on our land cover. This process takes less than one second for each protected area and buffer, calculating at the same time statistics for five land cover epochs and land cover change. It is so quick because we do not actually overlay them at all. We just use grass to restrict the region to the single protected area or buffer. We set the base object as a mask and we calculate base statistic for the land cover using air stats. We loop it through each protected area or buffer, and this way we shorten the time from six months needed by ArcMap 10. Or nine days needed by ArcGIS Pro, but on one single thematic layer to 15 hours with grass scripting. And this can also be parallelized keeping protected area and buffers in different grass mapset because you can run contemporary on two different mapsets. After this, we create the postgres functions that can be SQL or Procedure language and that are fed by the producer tables that we did before. And we go back to the rest service that Luca showed before. The indicator is made available using the public rest services. The rest web interface we developed from scratch using webby and postgres. It is consumed by Dopa Explorer, but also by other projects like as such Biopama which cover ACP countries. And we go back to the land cover and land cover change statistics output that show Luca. I summarize to wrap up in our organization for security reasons. We are not root super user or admin. To give you an example, processing was stopped often by schedule Pidge Dump. Postgres processing was stopped by the admin activities. And the upgrade from postgres 9.3 to 9.6 required six months. And we should develop with our IT administrators, but IT at JRC is a service and not a collaboration. We solve this with a dedicated processing server and Docker. We try to avoid processing of the same data with different tools because topology won't match 99% of the time. We already experimented how to keep every step in postgres vector and raster with positive results. We can get statistics on land cover in 12 milliseconds for each protected area, but needs time to be implemented. As we say, time matters. We are trying to reorganize all the processing steps originally developed independently within one structure and systematic workflow. We shortened the time required for update, at least for some indicators, from six months to 15 hours. We, me and Luca, work a lot together to adapt the output to the interface and, least frequently, the interface to the output. And we try to develop procedures which can be easily adapted to different data sets. The script that works for land cover can work for human settlement. You change one variable name. And we try to script everything with Bash Python and to share with our partners. If we cannot share processed data sets, we can share processing procedures. It is not so easy because every run we have different problems of geometries introduced mainly by the WDPA. When everything is clean, data and procedures, we share everything on our web platform where there is a wiki and everything is accessible. Thank you all. We finished. We actually had eight seconds left in 2017. I want to say something. We have a special guest today because Jorge is the one that started DOPA in 2012. We met here. Okay, so we have about nine minutes for questions. Who is the user community of this? Who do you see as the user community of this system? At first we prepare services for DEFCO. Mainly for the European Commission on Body, so DEFCO, the environment, countries, local governments, UN through the Convention on Biological Diversity and the World Bank also use some data. Many policy makers. I don't have a question, but I just want to return to that. Sorry for the presentation, but I wonder if you have some kind of connection with the LEPIS, LEPAR, certification system of this rural subsidies for agriculture? I am not aware of this. We are the developers of this site. The political part is managed by Lucy, and mainly by Gregor that is the project leader. Lucy takes a lot of care of the scientific part and connections. Are there other kind of cadets? Do you have any kind of connection with cadets and information like titles, registries? Not with the cadets, but we have also another project which is BIPAMA, which basically tried to body date the data at local level. So BIPAMA runs mainly in the Pacific, Africa and the Caribbean countries. So from there we can take local data and body date the global data we produce here, but we don't cooperate or collaborate with the cadastrial offices. Maybe I should have said something about the datasets that we use that are, I mean, especially the WDPA. It is a data collection that is managed by UNEP, WCMC, and they collect all the information from countries. So there is a lot of work behind the datasets that we use. We work global level, it's difficult to go deeper. We must always use, sometimes we save sources that are very interesting, but that we cannot use because they will be valid only from some part of the world and they do not cover something else. So we try to use good datasets, global datasets, and like BIPAMA, they filter on our data and they go deeper using a journal approach that allows them to upload more accurate data, but global datasets are often some problem of different occurrences. Other comments? I've got another one if you don't mind me doing it. I was fascinated with the paper you showed in the beginning of 2017. It was about, I picked up on assisted migration of wildlife, protected areas of how connected they are, and this idea of climate and the challenges wildlife is going to have both continental scales potentially and more locally, and I've got a colleague in UMass University, and I've got a landscape ecologist who does this kind of work at a state level, or maybe a little bit broader than that. So I got wondering about getting at the co-chairing piece of this. You can see a model, I've had this idea at this conference actually, in OSGO we have projects, there are software projects. I think we're at a point now where we should start moving toward thematic projects. So you can see a protected area project that's built on the stack of Phosphor G. But all we need is one or two or three individual locations of the world, like my landscape ecologist in my department, who might be taking the same exact application of development, but scaling it to the local with more finer scale. And so throwing this out as an idea, there's a lighting system, but I think we're at a point now where we should start thinking about not just software projects, but thematic projects, so I'm starting to think, what's your reaction to that? I agree completely. The presentation, we had 20 minutes, we had to cut a lot of topics just to show what we do, actually we were the speakers and we introduced mainly what we do, but there is a paper related to this presentation where we put a bunch of what you said about... Let's see that page. Yeah, yeah, yeah. Maybe after this. It's a... We shared the approach. Okay, thank you. Any other points or comments? So we have about four minutes, so let's thank you very much for...
 Good morning everybody. Today we are going to talk about the Digital Observatory for Protected Areas,  especially focused on the workflow that allows us to process, visualize and share the geospatial data and indicators.  The Digital Observatory for Protected Areas is under development at the JRC, the Joint Research Centre of the European Commission.  I'm going to spend just a couple of words about the JRC.  So the Joint Research Centre is the research body of the European Commission and provides scientific and technical support to the policy makers at the EU,  and it deals with a broad range of topics.  Today we are mainly going to be focused on protected areas.  So what is the Digital Observatory for Protected Areas?  It's a global reference information system that provides a wide range of indicators and is a support for policy makers at the European Commission,  but not only also to other countries and other organizations like the Convention on Biological Diversity in Montreal.  So I'm going to be focused now more on the application and the rest APIs that we provide.  So what you can actually do with the Digital Observatory for Protected Areas?  Well, it depends. If you are a developer, you can use our rest APIs to include them, include indicators or geospatial data in your web application.  If you are an end user, a scientist, you can query and search out of more than 21,000 protected areas and get summary results very quickly at protected area level,  at the country, ecoregion and soon region level. Then we have dedicated pages for protected areas, countries and ecoregion.  So here is an example of a dashboard, a protected dashboard.  In the right side you see the water occurrence map and the statistics down below, and on the left side you see the land cover on the top and the land cover change on the bottom.  So to better understand the processing that allows us to show this kind of data, I will give the floor to Andrea, which is the geospatial developer,  and we are working together more in the front end part.  Morning everybody. Now that the output should be clear, let's go back to this picture and see the first part of the workflow, the one on the left, by element, but not necessarily in this order.  We use peer-reviewed methods to calculate indicators on state pressures and threats. For instance, the disconnectivity indicator evaluates if a protected area is well connected to others,  in the way to allow movement of animals considering different dispersal capacities.  This specific indicator at the moment takes long time to be calculated and updated.  Many indicators were developed independently, one from another, by different developers, sometimes with a desktop-based approach.  At the moment we have something like 396 indicators to update, all of them global. Time matters and how often can we update our service?  We use, talk about data, we use openly available data set with clearly documented provenance, including some high quality data set developed in-house at JRC.  I give you a quick couple of examples. We use the global surface water 30-meter product, derived from 30 years of Landsat data, more than 2 million since, to calculate statistics on permanent seasonal water within each protected area of the world.  And to calculate statistics on human pressures on protected areas, we evaluate the use of the global human settlement map, this one also developed at JRC by another unit.  At the moment the real solution of this is 250 meters, but a 38-meter resolution version is planned.  Let's see some external data set that we use. How is made our country-based data set? We start from the last versions of the global administrative unit layer and the last version of the exclusive economic zones.  They use these two data sets, use different coastlines, they have different attribute structures and they share only isotric code as a common field. We keep all the information related to disputed areas that come with the sources.  And we merge them using mainly postures where they overlap Gaul winds. For problematic coastlines for number of vertices like in Chile, Alaska, Canada, Norway, all these difficult coastlines, we use some SAGA processing models in QGIS, that was very effective.  Then due to different coastlines we have holes that we fill with desktop approach. We tested many automated procedures, they work more or less, but we wanted someone really thinking where to assign the empty polygons, especially near the borders.  Then we dissolve the two merged information on the isotry field and we join any other ancillary information as the isotric code on or the UNM49 codes. We review the newsletter of ISO admin of the last 10 years to do this.  Let's see another external data set that how we always made our ecoregions data set. We start from the last terrestrial marine and marine ecoregions and pelagic provinces.  They have similar attribute structure and marine ecoregions are less not cut on the coastline. So we merge them smoothly, much more than the previous data set using postures and where they overlap terrestrial ecoregion winds.  There are no holes to be filled here because there is always intersection with marine and terrestrial ecoregion because the marine are not cut on the coastline. Then we merge countries and ecoregions and we obtain our base layer that has 2018 objects, which can give us information on how much surface of a country is covered by one ecoregion,  or is marine or terrestrial or the opposite, how much of an ecoregion is covered by a country and so on. If we intersect this one with other data set like protected areas or land cover, we get more complex indicators such as how much surface of a country is protected or is covered by a portion of a protected region and so on.  This layer can become a postage topology and not a simple feature, but we had a problem in the very last step, that is the merge of the country and ecoregions, that we made quickly with ArcGIS Pro, which introduced some geometric artifacts that were not present in the two original sources for which we check the topology within ArcGIS.  We are going to merge them again using grass. A key data set that DOPA uses is the world that are based on protected areas. This data set presents technical challenges for us and legal restrictions, technical challenges which are big, it's over 200,000 polygons, some of them with very complex geometry.  The most complex is in Sweden, has over 862 vertices, and because of this nature, it's more a collection of shapefiles, simple features, most of them overlapping each other than a structured geodata base.  There are some problems on some 1000 geometries such as self-intersection, which ArcGIS can open nicely but postage doesn't open, and doesn't have a versioning from the author, and it's updated every month.  Legal restrictions, the data set is open but we cannot redistribute it. We do not want to build a grass or postage topology for this data set, since it would be a reasonably complex time consuming and will introduce more problems.  This data set goes through many pre-processing and processing steps, using different tools like postage, Google Earth Engine, Radoop, GDAL, up to grass at the moment.  For pre-processing, we mainly clean up, we use tools of postage to do it. Each time that we get a new version, we must do a new clean up again. We filter on some fields following the author recommendations, we buffer 10 km around each protected area to calculate external pressures,  and at the moment we rasterize it, looping through each individual PA protected area, with a resolution at the moment of 100 meters at the equator, but not long WGS84 project.  And at the end we send it to grass to make analysis. We introduce one of the many thematic layers that we query with the base layers. This is the 2017 European Space Agency Climate Change Initiative, Lankover EAR product, from 1992 to 2015, 300 meters resolution.  We use of these five epochs from 19 to 2015 with five year steps, with four levels of aggregation, the original is 38 classes, we aggregate up to four classes, the one on the left, the one that you see on the map, to analyze Lankover.  Then we calculate Lankover change from which category to which category, which surface using grass. We do it on the most aggregated reclass on the whole period from 1992 to 2015, one epoch of the whole period, because if we go deeper, we get millions of combinations of classes or epochs.  Okay, now that we know something about our base and thematic data, we put them together, let's see how we put them together. We use the protected area as an example of base data, but these steps are valid also for countries and ego regions.  And we calculate statistical Lankover as an example of thematic data. All this process that you see, they happen using a couple of post-gis and grass scripts. This is an area of Italy where many protected areas overlap.  We select one of these protected areas, that is the Sibylini National Park, which has an area that is bigger than 50 square kilometers. We process areas bigger than 50 square kilometers.  This gives us 10% of the number of the global protected areas, that is 21,000 out of 215,000, but give us the 99% of surface protected globally.  Last run, we started from rasterized protected area. Next time, we would like to split each protected area as post-gis views. The script on the right is the one that loop through and split the protected areas and import each view in grass as vector.  Around this protected area, we build a buffer of 10 kilometers around the area to calculate external pressures. Last run, we used buffers prepared using ADUP. We are testing using post-gis and grass.  There are problems on protected areas that cross the data line, where the buffer falls over the geographical limit. ArcGIS doesn't create problems on this side, but is slow and often creates self-intersection, and we should clean up again the output.  You can see that part of this buffer overlaps other protected areas. We build a flat global protected area, a union of all the protected areas. Last run, we did raster using GDAL, but there is a dissolve that is running right now at home.  To do it vector, to merge all the protected areas vector, we need to split by blocks of 50,000 to avoid any memory overflow.  Then we erase whatever is protected from the buffer using the just mentioned flat protected layer. Last run, we did raster using grass. There are no problems of doing it vector in post-gis if inputs are clean.  And finally, we calculate statistics as category extension and land cover change, overlaying the protected area and buffer on our land cover.  This process takes less than one second for each protected area and buffer, calculating at the same time statistics for five land cover epochs and land cover change.  It is so quick because we do not actually overlay them at all. We just use grass to restrict the region to the single protected area or buffer.  We set the base object as a mask and we calculate base statistic for the land cover using air stats. We loop it through each protected area or buffer, and this way we shorten the time from six months needed by ArcMap 10.  Or nine days needed by ArcGIS Pro, but on one single thematic layer to 15 hours with grass scripting.  And this can also be parallelized keeping protected area and buffers in different grass mapset because you can run contemporary on two different mapsets.  After this, we create the postgres functions that can be SQL or Procedure language and that are fed by the producer tables that we did before.  And we go back to the rest service that Luca showed before.  The indicator is made available using the public rest services.  The rest web interface we developed from scratch using webby and postgres. It is consumed by Dopa Explorer, but also by other projects like as such Biopama which cover ACP countries.  And we go back to the land cover and land cover change statistics output that show Luca.  I summarize to wrap up in our organization for security reasons. We are not root super user or admin.  To give you an example, processing was stopped often by schedule Pidge Dump. Postgres processing was stopped by the admin activities.  And the upgrade from postgres 9.3 to 9.6 required six months. And we should develop with our IT administrators, but IT at JRC is a service and not a collaboration.  We solve this with a dedicated processing server and Docker.  We try to avoid processing of the same data with different tools because topology won't match 99% of the time.  We already experimented how to keep every step in postgres vector and raster with positive results.  We can get statistics on land cover in 12 milliseconds for each protected area, but needs time to be implemented.  As we say, time matters. We are trying to reorganize all the processing steps originally developed independently within one structure and systematic workflow.  We shortened the time required for update, at least for some indicators, from six months to 15 hours.  We, me and Luca, work a lot together to adapt the output to the interface and, least frequently, the interface to the output.  And we try to develop procedures which can be easily adapted to different data sets. The script that works for land cover can work for human settlement.  You change one variable name.  And we try to script everything with Bash Python and to share with our partners.  If we cannot share processed data sets, we can share processing procedures.  It is not so easy because every run we have different problems of geometries introduced mainly by the WDPA.  When everything is clean, data and procedures, we share everything on our web platform where there is a wiki and everything is accessible.  Thank you all. We finished.  We actually had eight seconds left in 2017.  I want to say something. We have a special guest today because Jorge is the one that started DOPA in 2012.  We met here.  Okay, so we have about nine minutes for questions.  Who is the user community of this?  Who do you see as the user community of this system?  At first we prepare services for DEFCO.  Mainly for the European Commission on Body, so DEFCO, the environment, countries, local governments,  UN through the Convention on Biological Diversity and the World Bank also use some data.  Many policy makers.  I don't have a question, but I just want to return to that.  Sorry for the presentation, but I wonder if you have some kind of connection with the LEPIS,  LEPAR, certification system of this rural subsidies for agriculture?  I am not aware of this. We are the developers of this site.  The political part is managed by Lucy, and mainly by Gregor that is the project leader.  Lucy takes a lot of care of the scientific part and connections.  Are there other kind of cadets? Do you have any kind of connection with cadets and information like titles, registries?  Not with the cadets, but we have also another project which is BIPAMA,  which basically tried to body date the data at local level.  So BIPAMA runs mainly in the Pacific, Africa and the Caribbean countries.  So from there we can take local data and body date the global data we produce here,  but we don't cooperate or collaborate with the cadastrial offices.  Maybe I should have said something about the datasets that we use that are, I mean, especially the WDPA.  It is a data collection that is managed by UNEP, WCMC, and they collect all the information from countries.  So there is a lot of work behind the datasets that we use.  We work global level, it's difficult to go deeper.  We must always use, sometimes we save sources that are very interesting,  but that we cannot use because they will be valid only from some part of the world and they do not cover something else.  So we try to use good datasets, global datasets, and like BIPAMA, they filter on our data  and they go deeper using a journal approach that allows them to upload more accurate data,  but global datasets are often some problem of different occurrences.  Other comments? I've got another one if you don't mind me doing it.  I was fascinated with the paper you showed in the beginning of 2017.  It was about, I picked up on assisted migration of wildlife, protected areas of how connected they are,  and this idea of climate and the challenges wildlife is going to have both continental scales potentially  and more locally, and I've got a colleague in UMass University,  and I've got a landscape ecologist who does this kind of work at a state level,  or maybe a little bit broader than that.  So I got wondering about getting at the co-chairing piece of this.  You can see a model, I've had this idea at this conference actually,  in OSGO we have projects, there are software projects.  I think we're at a point now where we should start moving toward thematic projects.  So you can see a protected area project that's built on the stack of Phosphor G.  But all we need is one or two or three individual locations of the world,  like my landscape ecologist in my department, who might be taking the same exact application of development,  but scaling it to the local with more finer scale.  And so throwing this out as an idea, there's a lighting system,  but I think we're at a point now where we should start thinking about  not just software projects, but thematic projects,  so I'm starting to think, what's your reaction to that?  I agree completely.  The presentation, we had 20 minutes, we had to cut a lot of topics just to show  what we do, actually we were the speakers and we introduced mainly what we do,  but there is a paper related to this presentation where we put a bunch of what you said about...  Let's see that page.  Yeah, yeah, yeah.  Maybe after this.  It's a...  We shared the approach.  Okay, thank you.  Any other points or comments?  So we have about four minutes, so let's thank you very much for...
Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_0_995.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_996_1415.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_1416_1715.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_1716_2927.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_2928_3191.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_3192_3803.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_3804_4559.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_4560_5903.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_5904_6287.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_6288_7643.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_7644_8075.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_8076_8579.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_8580_9059.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_9060_9923.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_9924_10511.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_10512_11075.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_11076_11663.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_11664_14711.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_14712_14903.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_14904_16391.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_16392_18059.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_18060_18671.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_18672_19859.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_19860_25175.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_25176_26435.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_26436_26759.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_26760_27419.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_27420_27563.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_27564_30947.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_30948_32603.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_32604_32651.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_32652_32699.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_32700_32759.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_32760_32807.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_32808_32927.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_32928_33959.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_33960_37643.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_37644_37691.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_37692_37763.png Processing_conservation_indicators_with_open_source_tools__lessons_learnt_from_the_37764_41067.png