Possible better coastline dataset?

[thejollygeo]

The Global Shorelines Vector (GSV) dataset on the Awesome-GEE catalogue (link) is perhaps a better coastline option. Even though it is 3 years older (this is 2014, LSIB is 2017), it is generally way more precise as it includes more coastal and estuarine detail (channels, islands etc), whereas LSIB is quite generalised. Here's an example over Casamance, Senegal. Green = Continental mainlands Blue = Big Islands (greater than 1 km2) Red = Small Islands (smaller than 1 km2)

A merge of these 3 GSV layers would create a single, much higher accuracy coastline dataset. This would improve Module 1 outputs in three ways:

1. The coastline buffer analysis is more precise, resulting in a better refined ROI, with less unwanted areas included
2. Image tide assignment would be more accurate, as a significant part of the intertidal zone is along river channels that LSIB often ignores (this would help GEM's poor results over Casamance)
3. Better low-tide composites will result in a better water mask.

For comparison here's the LSIB over the same area, with far less coastal detail and inland borders included ('ve compared the two on this GEE URL)

The big bays of NW Mada (Mahajamba Bay and Mahajunga Bay) are another great example:

I can assess the dataset more thoroughly but want to get your thoughts before I spend more time on this.

Cheers

[thejollygeo]

Additional testing suggests the incorrect tide assignment and therefore poor quality composites over Casamance are more likely due to the use of a poor coastline dataset, resulting in a poorly placed tidal zone, rather than the impact of open or closed dams. In fact, it turns out the large dam is 5000 m from the LSIB coastline, so it doesn't even come into play for the tidal zone (which is a 2000 m seaward buffer from the LSIB coastline).

This has resulted in us using the HLOT composite as the best HHOT representation we could find! As shown in this slide.

[zibnix]

Nice work Sam! This does look like quite an improvement.

Here is a link to a version of module 1 that uses these new datasets in place of the LSIB one so you can see how it looks within the GEM workflow:

https://code.earthengine.google.com/85bd1344fbfc0043f6db11f02e577529?noload=true

It seems to be working well, and I'm happy to make the switch if this seems like it will help!

[zibnix]

This is now the dataset we use for our coastlines.

[thejollygeo]

There is an interesting artifact in the shoreline dataset we now use as the coastline dataset in GEM. In Velondriake (SW Mada) there is an annoying line that isn't really coastline but is present as a tile boundary or something. It influences our coastline buffer as so:

These tile boundary lines feature across the entire dataset, as you can see on GEE or in the graphic below:

So it's just luck as to whether these odd lines appear in our ROIs or not. In TAB they do not, in VEL they do.

Is there a way to strip out these non-coastline lines? Some of them are straight, some slightly curved. For the current VEL mapping I will add an excluded area to cover the falsely retained area.

[zibnix]

Gotcha, yes I will look into this. Fortunately the points on these odd lines seem fairly spaced out, and I may be able to use that to differentiate them from the rest of the coast.

[zibnix]

This is now fixed for the vast majority of cases by dissolving/union-ing the polygons from these collections that intersection the ROI together, which removes points along shared borders. In Madagascar, the issue should be resolved. I have applied the method in some other areas and the effect is always positive, but there are still a few of these points that might creep in occasionally.

That said, I think it is essentially solved for us for the foreseeable future!

[thejollygeo]

Genius, thanks! I guess this is documented in your code and that's enough of an audit trail?