You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When shorelines are extracted as points and then exported as geoJSON lines, shorelines that have breaks in them due to the shoreline shape or cloud objects are not preserved and points are threaded together across breaks. For example, at a harbour entrance, shoreline points are extracted and able to be visualised, but shoreline lines thread straight across the entrance, which means an incorrect map representation and extra work to manually create multipart lines with breaks in them.
Describe the solution you'd like
Ideally, shoreline lines should be separate line objects with shared attributes (such as dates, image names and ROI IDs). One way to achieve this would be to convert contours to multiline features at the 'process shorelines' step, using a format like a geopandas GeoDataFrame. The multiline feature would (for the harbour entrance example) be made up of one shoreline with one set of attributes, but encompassing two separate LineString objects. The GeoDataFrame could then be exported to a geoJSON (or alternative file format) where the separate LineString objects all create individual features, but share the same attributes.
The text was updated successfully, but these errors were encountered:
I apologize for the delay responding to this issue I've been working on a solution and I was hoping to have it finished by the time I responded. Its possible keep each shoreline contour separate by modifying the process_shoreline function in the coastsat_package to not combine all the shoreline contours into a single numpy array before applying the filters to remove the shoreline points that are too close to the no data and cloud masks. What makes this issue tricky to implement is I am trying to implement this change while not modifying the underlying logic used to process the shoreline, since this workflow is meant to emulate the original CoastSat method.
What I have finished so far is that I've modified the process_shoreline function to return a geodataframe containing all the shoreline contours for a single date, then I modified the extract_shorelines function to create a geodataframe that combines all the shorelines from all the dates together. This solution solves the issue of the "knitting" shorelines that are common at harbors like you mentioned. To finish implementing this in CoastSeg I need to finish modifying both the zoo and coastsat workflows to use this new extract shorelines method as well update the code that plots the extracted shorelines on the map.
Thanks @2320sharon for your thorough response and efforts to address this suggestion, I believe it will really improve the overall user experience! Happy to close this whenever you are.
For review 6683
Is your feature request related to a problem? Please describe.
When shorelines are extracted as points and then exported as geoJSON lines, shorelines that have breaks in them due to the shoreline shape or cloud objects are not preserved and points are threaded together across breaks. For example, at a harbour entrance, shoreline points are extracted and able to be visualised, but shoreline lines thread straight across the entrance, which means an incorrect map representation and extra work to manually create multipart lines with breaks in them.
Describe the solution you'd like
Ideally, shoreline lines should be separate line objects with shared attributes (such as dates, image names and ROI IDs). One way to achieve this would be to convert contours to multiline features at the 'process shorelines' step, using a format like a geopandas GeoDataFrame. The multiline feature would (for the harbour entrance example) be made up of one shoreline with one set of attributes, but encompassing two separate LineString objects. The GeoDataFrame could then be exported to a geoJSON (or alternative file format) where the separate LineString objects all create individual features, but share the same attributes.
The text was updated successfully, but these errors were encountered: