Wenn das hier gemappte tatsächlich entspreched Tagging ein militärisches Sperrgebiet ist, dann wäre eine Angabe der Quelle für die Ausdehnung wichtig - es gibt dazu dann lokal sicher öffentliche Verlautbarungen, aus denen das hervor geht.

Falls das nicht der Fall its, handelt es sich um Tagging für den Renderer. Das kann man schon so machen, aber dann sollte man das mit entsprechenden Anmerkungen in den Daten auch so erkenntlich machen und klar sagen: Wir malen hier im Moment eine Karte und die Semantik der Daten ist dabei nicht von Bedeutung.

This is indeed the most common way to map tidally exposed rocky areas. The combination natural=bare_rock + tidal=yes has more than 12k uses. For permanently water covered rock areas the more common tagging is natural=reef + reef=rock.

All of the points i made in my original comment still stand. It does not matter if you disguise this as a (new) New Zealand Address import or try retroactive piggy-bagging on a decade old New Zealand Import that might or might not have discussed back then - at a time when the data you are importing here did not even exist yet and when there was almost no manual mapping in the Antarctic yet.

If you want to have feedback on your import you need to follow correct procedure and offer your plans for discussion on the imports list before the actual import - including links to the specific data you like to import, the tagging to be used and the procedure to deal with pre-existing mapping. I will gladly provide my suggestions in that case. But i will not spend my time doing post import QA on an import that has been done in disregard of the established procedures we have and in disrespect of mappers working in the Antarctic.

The irony by the way is that you are not only littering OSM with data garbage and discouraging the few mappers who have worked in the area to add useful information from ever contributing there again, you are also making LINZ topographic mapping efforts in the Antarctic look much worse than they are. By learning the specific structure and semantics of the LINZ antarctic topographic mapping, familiarizing yourself with the geography of the area, the pre-existing mapping in OSM and available imagery sources you could make this a valuable contribution to OSM. But as it stands it is not.

I am not going to engage in a rule lawyering discussion here. My comment was a courtesy message giving you the opportunity to recognize and fix the error in your approach yourself. It is your choice what you make of it.

Please stop this import, revert the changes made and discuss your plans following the import guidelines on the imports mailing list before adding further data.

Specifically you are:

* importing natural features in the Antarctic under the disguise of this being a New Zealand Address import.

* not linking to a documentation of the import documenting sources and tagging used and procedure on the OSM wiki from either the changeset tags or the import user account page

* just dumping data in complete disregard with how it matches existing data in the area or if it duplicates existing features.

Note that nested multipolygon relations (multipolygons with other multipolygons as members) are not supported by applications and likely will never be. Multipolygons can only have ways as members.

Be advised you have mapped an iceberg here.

And for mapping an island you would have needed to add the natural=coastline tag by the way - see osm.wiki/Tag:natural%3Dcoastline

You are very welcome to map in polar regions where much too little mapping takes place overall - but it is important to familiarize yourself with the geography of the region and the pitfalls of reading imagery from there - see also osm.wiki/Armchair_mapping.

For reference: Previous discussion on the matter can be found on

osm.org/changeset/44837047

https://lists.openstreetmap.org/pipermail/talk-us/2016-January/thread.html#15819

For several years now this region has required special processing for anyone who wants to derive a consistent coastline data set from OSM data - for map rendering or other purposes. In fact the whole US east coast is now globally by far the area that deviates most from the global consensus regarding coastline placement (as measured by the number of cases where it deviates from that, not by surface area of course, here the Rio de la Plata has the undisputed lead).

The discussion here seems to lead towards a reiteration of the discussion regarding the Rio de la Plata we had a few months ago on tagging. I would therefore like to point to the question i had asked back then already:

https://lists.openstreetmap.org/pipermail/tagging/2020-August/054519.html

Side note:

These riverbank polygons:

osm.org/relation/1357743
osm.org/relation/6840775
osm.org/relation/177638
osm.org/relation/1344442
osm.org/relation/6840775

are mapped incorrectly because

(a) the name of a river by broad consensus goes to the waterway line (waterway=river), not to the riverbank polygons.

(b) some of these don't even have a waterway line mapped - which by consensus is mandatory for a river.

No reformatting of the date information was done during the import so those tags are as they are in the source data - which is not consistent and as you point out in parts ambiguous. In some cases the possibilities can be narrowed down through other information available, for example in case of the way you linked to there is a note "Digitized from LIMA" - which means it has to be 1999-2003.

I see no real use in a mechanical edit here. The main use of that data is as possibly helpful to mappers editing in the area and for this purpose a mechanical edit is not in any way helpful.

Hello Marc,

I don't have the original data available any more so i don't know if this error was already in there or if it is the result of the conversion process and the actual dates could be reconstructed from the source data.

While i agree that using ISO date format for the date tags is advisable this is not a requirement and not universal practice in use of these tags. And for survey:date it was not even documented as a suggested rule back when the import was made.

As useful as the survey date is in particular in polar regions it is fair to say i think that seven years after the import and with up-to-date image sources in good quality being much more widely available now if some existing data represents the 2000 state or the 2010 state (which is about the most common range of survey dates in the ADD 6.0 at the coast and outside the Antarctic peninsula) is of only very minor importance.

Hello mapwitch,

you have mapped two large natural=water polygons here:

osm.org/relation/11044890

osm.org/relation/11045349

that do not represent inland waterbodies but tidal channels and therefore need to be outside the coastline for accurate mapping. Could you change the tagging to represent that?

See here:

osm.org/#map=10/-5.2359/137.4513

for an example for correct coastline mapping in a similar setting.

I think you are both right in some way: dmgroom_ct is correct that the continuity of the coastline without branching needs to be maintained at all times. But Joseph E is right that this needs to happen in a way that represents the actual geography. And that is not the case any more after the changes by dmgroom_ct - the coastline in this area is now a meaningless hull drawn around the actual coastline details which are drawn using natural=water polygons. It would be good if you could change that back to the original mapping as done by Joseph E.

Hello andershl,

the import guidelines are there for a reason, they are not just a pointless bureaucratic hurdle. In particular the scrutiny of the legal situation of the data used is of high importance.

When asking for permission to use data it is essential to (a) get it from someone who clearly has the authority to give it and (b) make sure the owner of the data understands exactly what you are asking permission for, i.e. to include the data in a database that is used by a lot of people for various purposes without individual data providers being attributed directly. Now i don't understand Danish so i can't really assess this - that would need to be done by the Danish/Greenland community. But it is essential to be extra careful about this to avoid bad surprises and wasted work later.

I think much of the data you prepared would be useful for OSM but importing the data in OSM would definitely need to involve conflation with existing data to avoid duplication. Adding the data without this in the hope that other mappers will in the future sort this out is not a good idea. In particular in a rarely visited area like this the likeliness that this would not happen for years and broken data continues to be present for a long time is very high - we have seen this in other parts of the world.

You seem to be manually conflating data now - like in

osm.org/changeset/68559362

but you are not removing the duplicate nodes. I am not sure what your plan is in that regard.

All i am saying is that Britain does not administer or claims to administer the British Antarctic Territory. It only maintains this as a dormant claim under the Antarctic Treaty that has no practical meaning as long as the Antarctic Treaty is in place. And this claim is obviously a non-verifiable statement in terms of the OSM verifiability principle - it depends on a single claiming entity and cannot be verified independent of that.

The rest of the British Overseas Territories is likely verifiably administered by Britain so before the addition of the BAT boundary=administrative might have been a valid tag - although it seems that these do not actually form a single administrative unit making this relation more of a category relation as per

osm.wiki/Relations/Relations_are_not_Categories

muralito is right, this change is not in line with established OSM mapping practice. Although the UK considers this part of their overseas territories it does not actually administer or even claim to administer any land south of 60 degrees south as per the Antarctic Treaty. The relation does not have an admin_level tag so for most data users there is no ill-effect but boundary=administrative is definitely wrong here - likewise for

osm.org/relation/3394112

The common practice for tagging Antarctic claims (which are obviously non-verifiable) has been so far mostly to use (undocumented) boundary=region:

osm.org/relation/3394111
osm.org/relation/3394110

There have however also been other attempts to push for boundary=administrative:

osm.org/changeset/62032683
osm.org/changeset/62032457

See also:

osm.org/changeset/52212342

Very nice work!

Hello Ryzen,

you have removed a lot of geometries of evidently existing islands here without replacing them with new and more accurate geometries. No matter how bad the original geometries were they were still better than no data at all so please either re-map them in better quality or restore the original data.

In der momentanen Erfassung ist das Ganze hier kompletter Unsinn, denn:

* Der gängige Name für das gesamte Gewässer ist Zalew Szczeciński/Stettiner Haff
* Das Objekt hierfür (Relation 8119947) ist ungültig, da Multipolygone keine Relationen als member haben können.
* Die drei Objekte haben alle falsche Namen und falsche Tags. Das Tag für Buchten (so sie denn tatsächlich einen lokal gebräuchlichen Namen haben, was bei Seen eher selten der Fall ist) ist natural=bay, nicht natural=water.

Hello Viriato,

the tagging of this way is wrong, this is not a place=archipelago and it is not an area as indicated by the name tag - if it was an area in the form of a distinct administrative unit it would have to be a boundary relation and not a closed way.

It is just the 12 miles limit of Madeira and as such should be a member of various boundary relation. The only tags that should go on the way are boundary=administrative, maritime=yes and admin_level=2.

This is only unique in the way that this is the only place on Earth where anyone attempted to aggregate such a huge extent of riverbank mapping into a single multipolygon. Most other places where this was tried elsewhere (which are very few) are all several orders of magnitude smaller and even there the multipolygon usually suffers from being constantly broken.

The fixme note for the Amazon riverbank multipolygon being too large and that it should be split was added half a year ago by me. The first split into two parts happened two months ago in:

osm.org/changeset/59875449

which was not ideal since it created two new relations instead of splitting off one from the existing one. But dealing with this kind of giant MP relations is difficult so this is an understandable mistake. mapwitch simply further split one of the parts (which was still extremely large on its own) into manageable chunks.

So this was not a surprising ad hoc edit, it was done in several steps over multiple months by several people based on mapping practice widely used also in this country.

And splitting large polygons for riverbanks or landuse into smaller ones is not something that usually requires advance discussion. This is a good faith edit intended to make future mapping easier.

I think it is great that you care about the Amazon river mapping but you should recognize i think that those who have edited the riverbank polygons from abroad have done so with good intentions and good reasons for making their edits.