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.

No one has undone any mapping work here, mapwitch has just split a non-maintainable giant multipolygon stretching over thousands of kilometers, without doubts the largest riverbank polygon in the database, into smaller, easy to handle parts. There is no loss in information and mapping work involved in that. This is completely in line with established mapping practice world wide and a very positive contribution making future edits in the area much easier.

Riverbank polygons should always be split into relatively small, easy to handle parts. Large riverbank polygons are difficult to edit and to properly verify for validity for the mapper and more difficult to handle for the data user, they break much more frequently than small polygons and with much more severe consequences.

Thanks. That's a very good deed.

Hello ronic,

thanks for your contributions to Antarctic mapping.

You seem to have problems choosing the right tags for what you map. place=neighbourhood indicates a populated area in an urban environment, it is not a fitting choice for tagging physical geography features. natural=saddle (osm.org/node/2335535216) is not compatible with something located directly at the coast. If you are unsure about choice of tags for certain features (which is not uncommon in an exotic environment like here) just ask on one of the OSM communication channels like mailing lists or forum in your preferred language or at least add a description tag explaining what kind of feature you want to map here.

A Bluff (like in osm.org/node/5537488267) is an exposed rock area or cliff, you can tag the name on a natural=bare_rock area (which already exists here - osm.org/relation/2968576) or draw a line along the edge of the cliff and tag it natural=cliff.

Dass sich künstlich und natürlich nicht unterscheiden lassen ist ein gelegentlich in Analogie vorgebrachtes Argument, das greift aber bei Fließgewässern im Grunde nicht. Natürlicher Wasserlauf bedeutet nicht naturbelassen, sondern dass seine Existenz natürlich bedingt ist.

Im Flachland ist das nicht immer ganz einfach zu erkennen, im Gebirge aber meist schon, insbesondere wenn man das Relief mit betrachtet - welches ja durch die natürlichen Wasserläufe entscheidend geformt wird.

Und die Benennung eines Baches als Graben ist wie gesagt kein Indiz für eine künstliche Anlage. In der Umgebung der Wutachschlucht rühren solche Namen vermutlich einfach daher, dass sich die Bäche in den Untergrund eingraben.

Hallo BeKri,

bitte achte darauf, kleine natürliche Wasserläufe immer als waterway=stream zu taggen, waterway=ditch ist ausschließlich für künstlich angelegte Gräben. Das ist unabhängig von der Benennung - dass etwas 'Graben' heißt bedeutet nicht, dass unbedingt es sich um einen waterway=ditch handelt.

Grüße,

Christoph

Hello Carolina,

could you explain what you are trying to do here with

osm.org/way/520138444
osm.org/way/44036775
osm.org/relation/7526598

This clashes with the purposes of natural=water and natural=coastline.

Hello visaman-import,

could you point me to where this import and its tagging have been discussed and are documented?

The data of this and other changesets from you in the same area uses undocumented and partly redundant tags, URLs that redirect to an empty page and the data in parts contradicts existing data in OSM.

Based on

osm.wiki/One_feature,_one_OSM_element

i deleted nodes for reefs that are also mapped as areas - after transferring tags to the area.

natural=tundra does not say anything about the vegetation except for that it is without trees. I would advise against it. Grassland is completely fine here for areas with vegetation.

Thanks.

If you can reliably identify differences in the vegetation from available images it does not hurt to differentiate them with supplemental tags (like grassland=*).

Hello dikkeknodel,

nice mapping work on South Georgia - but you should probably be aware that there is no scrub vegetation around there - to my knowledge there are hardly any woody plants growing on South Georgia. What you identify as scrubland on images is probably mostly tussock grass formations.

See

http://nora.nerc.ac.uk/id/eprint/509458/1/The%20vascular%20flora%20of%20South%20Georgia%20-%20BAS%20Scientific%20Report%2045.pdf

for background info on the vegetation of South Georgia.

This is just my assessment of the situation - i won't insist on changing anything here. But i am pretty sure the position is wrong, not wrong by a few hundred meters but wrong by likely many kilometers - either much closer to the shore or much further to the east (that is the problem with secondary sources - you have this kind of error in Wikipedia all the time).

Regarding future improvements - it is unlikely that when suitable images are available for the area such a volatile feature still exists.

Hello Dave,

i would advise against trying to map features where you have nothing even close to verifiable position data for.

The location of node 5125769091 is a highly unlikely position for an islet or even a gravel bar based on the sea ice movement in the area - ice would not be able to move across such a feature freely - but it does in the area.

There are lots of well verifiable features missing in the north of Greenland in OSM - lets concentrate on those and not on data of questionable reliability like this.

velmyshanovnyi,

you need to verify your edits more diligently otherwise this can only be seen as a mechanical edit/import. For example at:

https://mc.bbbike.org/mc/?lon=-153.046905&lat=70.038537&zoom=12&num=2&mt0=bing-satellite&mt1=mapnik

the islands in the lake are actually clouds and residual ice. If you familiarize yourself with the region and use other readily available image sources for verification you can see that. You don't do anyone a favor by mechanically tracing thousands of lakes this way without checking for such errors.

And you should definitely not use the 15 year old low resolution images in Bing at z12 and below as a basis. Both Bing and DigitalGlobe have higher resolution and newer images in most of the areas you are working on. Make use of that. And it might be good to ask other experienced scanaerial users like Vort and Jake Strine for help with best practice in using such techniques.