Apart from the general question above:
I visually checked the undone reverts and current display of seagrass in OSM (26.6.2023 18 hrs UTC). So far I found only one instance, where an older version of an anchoring area (way/588629274) now incorrectly overlaps the protected seagrass (way/1003725381). I will leave few days distance to the revert and undo process and then correct this way/588629274 manually.

Great how you managed to undo the revert for the seagrass, which existed in OSM before this changeset. The initial visibility of the seagrass in OSM illustrates the purpose of the seagrass tagging and will lay ground for future careful work in OSM on seagrass and the nature of the seabed. Thanks to SomeoneElse again. Jo

Thanks also for this question.

I thought carefully on it this afternoon. I know parts o the wiki quite well, especially the taging schemes, have used it continuously as reference before I used new keys and even have amended parts of the wiki on the seamark tagging scheme. But in this case, if you don't know the existance of the import guideline, you would hardly start searching it in the wiki.

I have also gained quite some experience with OSM work in JOSM, applied the presets carefully and always checked carfully the validation results before uploading. Also in this case of the large seagrass import I made much effort to check, address and solve all validation errors and 95% of the warnings.

From my perspective I can name two things, that would certainly have stopped me importing a very large set of already very carefully and well JOSM validated data:

1. A dedicated upload warning window or explicit well described validation warning for the large amount of data in the upload. Such warning should best include a direct link to the required (for me unknown) import guidelines and any other procedures to be checked in the wiki. There the requirement to open a website, ask for community review, use a special user name, etc. would have popped up. I know some other cases, where warning windows in JOSM included a link to further explanation in a special wiki website.

2. A warning or error messeage during the upload procedure requesting in the upload description for the large amount of data to include as a value the reference to the import plan website. Again this request to provide something, that I did not know of, would have started me to think twice and search for it in the wiki.

The question is: Does OSM experience tell a reasonable size of an upload, above one can most likely assume, that the import guideline should be applied. Then a combination of both would work best:
1. a JOSM validation error or validation warning with a link to the 'import Guideline' (osm.wiki/Import/Guidelines) and a request to use a seperate username for such large upload and
2. the requirement in the JOSM upload to link the created wiki page outlining the details of the import plan (Step 3.2 in the guideline), e.g. next to and in addition to the source information.

I hope this idea is helpful and that this laboursome experience can perhaps add some value for the future of OSM.

Thank you very much for your effort to sort this out. My first visual inspection tells, that all seegrass preexisting (included before this reverted changeset #137667141) is visible again. I will have a closer look tonight. Likely, everything is fine now. As soon as I get a positive feedback from the Greek Seagrass Meadows authors, I will closely follow the guidelines you have mentioned to make all steps necessary for including this valuable open access data on seagrass. I learned a lot and was before not aware of these import procedures and guidelines. They make a lot of sense to me, including the use of a dedicated user name for the import only.

Thanks a lot again for your effot and sorry for the confusion and work related to sorting this out.

Jo

Shall I work on this 'undeleting' and then what is the best procedure to do this in JOSM. I can contribute the exact map history knowledge in these cases of what was there before changeset #137667141. But I want to be sure together with you that we don't do things on two sides and would need some assurance to identify the correct way of doing this in JOSM in order to avoid any additional complications. Your advice or instruction on these two questions will be very welcome. Jo

@SomeoneElse,
I'm sorry that the revert turns out complicated. Yes, some of the seagrass, that has been there since long and which is not part of this changeset #137667141 has been deleted completely, too. However, I can certainly say that minor amendments to this preexisting seagrass have all been committed as minor changeset before the changeset #137667141.

For theses minor changes, we should now look for the revert of the revert. I can further assure that these were all the seagrass around the islands of Ios, Iraklia and west side of Shinousa. This seagrass, carefully manually mapped from bing, maxar, Esri and Mapbox as well as by diving in some of the areas are now lost.

Can you identify this by the exact timing of the changesets before and after changeset #137667141?

This would be the correct and precise solution to this revert complication.

If you tell me 'how to' I am happy to help this necessary sorting process.

Jo

for inormation and an effective revert process: There have been nil "edits" to the existing OSM with this commit, it was all pure "addition". So normally a revert by complete "deletion" should perfectly revert all elements of this commit.

Let me know if I can or should support the revert process somehow from my side. I will do everything to set up and discuss the process appropriately. josail

To clarify this: The source is neither Google nor Landsat but a completed and stand-alone scientific work published here https://www.seanoe.org/data/00765/87740/ , which in itself among many other sources used also Google and Landsat. The correct attribution is made in the attribution tag. I will suggest to clarify this in the source, i.e. name the primary source https://www.seanoe.org/data/00765/87740/, and only give indication that this completed work has been performed with diferent satellite imagery, in some cases including indirectly also Google and Landsat.
I hope this makes it clear, and clarification of CC BY 4.0 permission for the original and primiary source for OSM is already requested.
Thank you very much for your reviews and indication of clarifications to be done for using the published data in OSM. I hope to get feedback of the authors soon and will then open a dedicated wiki page for further description and discussion. Your further input will be very welcome. Greetings, Josail

I have now
* started the CC BY permission request with the authors
* performed a 'simplify way' calculation over night resulting in:

1. -750000 nodes @ 0.5m precision, testing @ 0.25m precision showed much less effect, corresponding to the fact, that most nodes are 5 to 50 m apart, so in reasonable distances for the task of mapping the seagrass areas

2. doubling of the .osm file size
1 and 2 are contradicting, but I guess, the .osm file keeps the 'simplify way' change information, so, doubling information. Is there a way to consolidate this 'simplify way' change (erase the original from the .osm, keep the reduced data), to see the net effect?

In no case do I want to double the data load and would like to confirm the effectivness of the 'simplify way' procedure @0.5m precision.

Regarding few pixellated areas: These originate from the dataset and in some cases its development from interpretation of satellite imagery by the researchers. It means, that it represents the original and expert 'best knowledge' so far. Hopefully the OSM nautical community with all their local perspectives will find interest in further refining this data with local (not satellite pixellated) information, once this becomes apparent by initial display of the existing seagrass information. Intentionally, the icon fill for seagrass areas is designed without border lines of the area, so that pixellated source data has less pixellated optical impact in its OpenSeaMap, OpenNauticalChart and OSMAND representations.

Hi Taya,

thanks a lot for your advice. I was not aware of the dedicated guidelines for this and like to follow up accordingly.

Regarding

Step 1) Regarding the biggest concern of overlap I can tell, that this is minimal so far, as the seagrass tag is relatively new both in internatinal IHO code INT-1 and OSM seamarks. The current example is at islands Ios and Iraklia in Kyklades and this one I have taken good care of to not overlap with the import. Further, the coastal waters lack seabed information and there is so far no risk of overlap with existing seagrass and seabed tags in the near shore coastal areas in Greece. Indeed the import of Seagrass Meadows in Greek Sea near shore, after becoming visible, will likely motivate others to use, apply and further amend these OSM tags. That is the intention of the import in the best sense of OSM mapping.

Step 2+3.1) I will clarify CC BY 4.0 waiver with scientific authors

Step 3.2 and following)
I will apply and follow the Guidelines with an appropriate process.
If I understand right, I need to open a dedicated wiki page. I will use osm.wiki/Import/Plan_Outline. Much of the work for adjusting to OSM and validating tags, including a very good comparison between my earlier findings and the outcome of the scientific report, I have already completed, so quite clear to describe it.

Where I could really need some advice is the size of imports. I have the entire set of data for Seagrass Meadows in Greek Sea as one OSM, validated, all errors solved. This is what I tried uploading and it looks, the size was ok, but here I'm not certain. Can you tell me, whether there is a need to artificially split this changeset or can it stay in this size.

Any further advice and comments are welcome.

Josail

Does this explain the case. Happy to answer further questions or need for clarifications. Best regards, Jo

Hi Taya,
seagrass has been amended in the IHO INT-1 standard as parallel to seaweed but distinct feature. It has 2021/2022 been discussed with opeanseamap authors and was integrated in the amendments for the nature of the seabed according to INT-1 section J: osm.wiki/Seamarks/INT-1_Section_J

Landsat-8/Google do not play a direct role. Rather the commit is based on a comprehensive scientific work, which in itself has been using a combination of ground truthing and satellite imagary. Its product was published as open access work CC BY 4.0 on https://www.seanoe.org/data/00765/87740/. Attribution to the team of authors of the scientific work has been made appropriately both by inclusion of the tag attribution and in the tag source of the commit. The further work for OSM validation I commit as OSM mapper.
If you see further problem here, could you specify this, so that I could approach the authors of HCMR with a detailed additional request?
The puorpose is clearly the indication of protected vegetated areas of the seabed in coastal waters and this is in my view very much achived for skippers of leisure crafts and their anchoring strategies by visibility of seagrass in the OpenSeaMap, OpenNauticalChart, OSMAND and other OSM map derivatives. Such visibility is much reflecting the purpose of the original scientific work published as open access data by HCMR.