[REFERENCE] Change detection workflows: exploring data on GC-Explorer, syncing alerts with CoMapeo via Windmill

[rudokemper]

[rudokemper]

In this guide can refer to https://docs.google.com/document/d/16gcTGoJkQW2N77DCI0cPn4o6P64ycgnsx2YH4g_ivac/edit?tab=t.0

[rudokemper]

@nicopace since you've been on a documentation blitz, and setting up change detection flows for partners, do you mind taking this one on in Sprint 6?

[nicopace]

The general workflow is to be explained here. The change detection happens somewhere else and it's already available or could be made available through an analysis process. Then Guardian Connector consumes that information through windmill scripts that need to be configured. And the operator should be able to set this up based on the information that will be provided in this page.

And this information can be seen in a GC Explorer page. And it could be set up to be synced to Comapeo through the Comapeo archive server. Windmill script again for the operator to be configured.

[nicopace]

In this guide can refer to https://docs.google.com/document/d/16gcTGoJkQW2N77DCI0cPn4o6P64ycgnsx2YH4g_ivac/edit?tab=t.0

Do we want to refer to all of these options as possible options to be included in the Explorer and Comapeo alerts? Or shall we list them as possibilities and use one as an example to show the potential? I mention this because I am not sure whether we are able to bring them all already or if it's something that needs to be developed for some of these alerts.

And also because depending on the alert, if it's near real time, it makes sense to do it in some ways. While if it's not that kind, it might be better to do it in another way. And I guess it would make sense to have sections for the different kind of change detections or remote alerts based on the kind of data that you get.

As an example, If it's data that can be seen as a point, could be an alert in an alerts dashboard, in an Explorer map. If it's a map, can be a background map within Explorer and so on and so forth.

[rudokemper]

In this guide can refer to https://docs.google.com/document/d/16gcTGoJkQW2N77DCI0cPn4o6P64ycgnsx2YH4g_ivac/edit?tab=t.0

Do we want to refer to all of these options as possible options to be included in the Explorer and Comapeo alerts? Or shall we list them as possibilities and use one as an example to show the potential? I mention this because I am not sure whether we are able to bring them all already or if it's something that needs to be developed for some of these alerts.

Thanks for asking about this. Most of the content in this doc is not consumable in the same way as alerts_gcs or GFW alerts. And I think the nature of this proposed reference doc has evolved since the original thinking. I don't think this document needs to make its way into this guide at all.

I think this is exactly right:

The general workflow is to be explained here. The change detection happens somewhere else and it's already available or could be made available through an analysis process. Then Guardian Connector consumes that information through windmill scripts that need to be configured. And the operator should be able to set this up based on the information that will be provided in this page.

And this information can be seen in a GC Explorer page. And it could be set up to be synced to Comapeo through the Comapeo archive server. Windmill script again for the operator to be configured.

Since we don't reveal our proprietary alerts provider, I think that initial language of "the change detection happens somewhere else" is right. And then you could say something like "While there are many options of change detection systems, in what follows we will use Integrated Deforestation Alerts from Global Forest Watch as an exemplary dataset".