How should ROI size be calculated?

[2320sharon]

How ROI Size is Currently defined

CoastSeg's ROI size should be accurate across all of the Earth so the user knows how much land their ROIs cover. Currently, the ROI's size is defined in meters according to ESPG 3857 and converted back to ESPG 4326 so it can be displayed on the ipyleaflet map. Unfortunately ESPG 3857 is not accurate across all of the world because in some regions the meters are squished together while in others they are much farther apart.

How to Proceed?

I am no expert on CRS and I don't know when I should convert from one to another. How should the size of the ROIs be defined in a way that's more accurate than the current method of defining it in meters in ESPG 3857?

Resources

1. This post explains how each espg is used for Google Maps and Google Earth.
2. Here is the units for espg 3857.
3. https://www.esri.com/arcgis-blog/products/arcgis-pro/mapping/coordinate-systems-difference/

[ddbuscombe]

You are correct that coercing all ROIs into a certain epsg code could cause error, and the error would be a function of latitude. It is not ideal, especially because ROIs must be kept under a certain size (see, for example, kvos/CoastSat#321)

Perhaps a path forward is to automatically compute the epsg code from the provided ROI's centroid (mean 2d position) converted to UTM coordinates?

e.g. from here:

import utm
utm.from_latlon(51.2, 7.5)

which outputs
(395201.3103811303, 5673135.241182375, 32, 'U')

The epsg code is therefore epsg:32632 (the 32 is the UTM zone). From here, epsg codes are constructed from the root (326 for the N hemisphere and 327 for the southern), then the UTM zone, hence 32632

[2320sharon]

Thank you so much for finding these resources and linking to them. This looks like it should improve the accuracy of distance calculations since we can use the lat-lng coordinates of the ROI to choose the proper UTM which can then be converted into shapely compatible coordinates that can be used to calculate the area.

Using this solution will require more thought into how to quickly convert the bounding box/ROIs into these projections, determine the size, then create the right ROIs for the map.

[2320sharon]

What units would the area be in once the conversion is complete?

[kvos]

I would say sqm if the ROI is in projected coordinates..

[2320sharon]

Makes sense thank you!

[kvos]

Another solution could be to use a unique equal-area projection, these are projections that conserve area: https://gisgeography.com/equal-area-projection-maps/
One example is epsg:6933 https://epsg.io/6933

[2320sharon]

Brief Description of Update and Problems

So I have an update on the ROI size problem. Using the method Dan suggested here I have created a function called convert_wgs_to_utm to determine which CRS the bounding box was drawn in. Another function to create ROIs (squares) using the side length specified by the user-controlled variable square_size in the CRS calculated by convert_wgs_to_utm and then converting the ROIs back to espg:4326 so they can be rendered on the map. I have used geojson.io's area package to check the area of the ROIs rendered onto the map the problem is it shows the area (in squared meters) being a bit off.

What's confusing is that when I check the area of the ROIs created in the fishnet_create function before converting them to espg:4326 using the geopandas area function it shows that the areas are correct. Is this a normal margin of error caused by the conversion to another CRS?

Notebook Containing the new code

I've included instructions on how to replicate this behavior in a special notebook on my fork of coastseg. Please try it out and let me know if you see anything wrong with my methods.
⭐ Please check the notebook roi_size_notebook.ipynb on my repo https://github.com/2320sharon/CoastSeg/tree/new_roi_size_functions it contains the new functions used to calculate the ROIs the new way.

Warning

⚠️ you will need to install the utm package to run the notebook.conda install -c conda-forge utm -y

[ddbuscombe]

We investigated this offline and found this made << 1% difference in area of ROI. We have concluded that this is too small an error to worry about and will proceed with this method