To my opinion there should be a clear distinction between linear objects like highway=* and area objects e.g. landuse=*.
pedestrian areas are of the second kind and there is a method of doing this: highway:area=pedestrian
area:highway=*
I consider the subtag area=yes as just an auxiliary mean to indicate areas where there is no other possibility.
The main difference of both methods is during routing: area:highway is not used for routing - you need linear ways across the area. There is a tag virtual=yes to indicate that this is not a clearly visible way. But nevertheless it gives a much more realistic way of actual movement.

The tagging with area=yes is valid, but it is not the only possibility to tag areas.
But if there is common consent in the portuguese community to tag pedestrian areas only this way, I will not touch them any more.

In Deutschland darf sich eine Einrichtung erst Zoo nennen, wenn sie mindestens vier Tierarten hat und mindestens eine davon kein Huftier.
Aber OSM hat ja seine eigenen Begriffe und dort läuft ein schnödes Wildgehege im deutschen Wiki unter tourism=zoo samt enclosure. Zur Fleischproduktion dienen sie mMn nicht, da praktisch in jedem Wildgehege zur Bestandskontrolle Tiere "entnommen" werden müssen, die dann auf der Speisekarte der umliegenden Gasthäuser auftauchen. Die Hauptfunktion ist das aber nicht.
Im englischen Wiki ist das alles so genau nicht spezifiziert, aber widerspricht jedenfalls nicht dem deutschen.
Über attraction kann man sich streiten, mir würde das "Wildgehege" reichen, es beißt sich aber ja nicht mit tourism=zoo.
Was auf jeden Fall aber überfüssig ist, ist das animal=*, denn die genaue Tierart ist ja inzwischen getaggt.

Ok, then Portugal is rather different from the rest of the world.
But the local community decides and I will not touch the place hierarchy (in Portugal) any more.

According to the Wiki (also in portuguese) a hamlet consists of no more than 100 - 200 inhabitants, that means typically about 20 to 50 houses.
The next settlement Barrocas e.g. is of that type.
Another additional criteria is the presence of a sort of centre with denser population and some residential streets.
In Capelas that would be around the crossing of Rua Principal and Rua dos Aliados.

But the distinguishing between hamlet and village is of course neverwhere exact.

Das Messgerät für SRTM war ein Altimeter.
Ich war mal bei der Erzeugung von Radarbildern beteiligt, wir hatten nie Schwierigkeiten mit Wolken. Das war aber im L-Band-Bereich, X- und C-Band mit kürzerer Wellenlänge sind da wohl empfindlicher.
Die Reflexion, Diffusion und Absorption von Oberflächen hängt von vielen Parametern ab, bei trockenem Schnee kann da möglicherweise zu wenig zurückkommen.

40 m prominence may be reason enough for tagging a peak in the lowlands but for me not in the mountains. But that is as I already said not a big issue.
Steep terrain is not the only reason for data gaps, but at least the hole east of P.5678 may arise from that.
DEM-based maps with contour lines usually use more than one source, but in Nepal LIDAR campaigns may be too difficult and expensive. Postprocessing (filling gaps by interpolation etc) may be different and the algorithms for generating contour lines may vary, too.

I didn't argue based on DEM, but on the Topo Map. I got obviously the same map from a different source. There P.5678 is less than 40 m (distance of contour lines) higher than its surroundings.
But that is not an important issue, I just wanted to explain why I thought the peak was at the wrong position.
BTW: The altimeter radar is insensitive to clouds. The "craters" originate from missing data points which appear frequently here because very steep slopes scatter the radar pulses mostly aside and less back.

Ok, I agree that AMS is not a reliable source here.
I have no access to FinnMaps, but I loaded another 1:50000 Topo Map. It seems to have almost the same height points.
What I considered as inaccurate peak positions are height measurement points not at peaks.
E.g. point 5678 just 800 m east from the just shifted "AMS-Sisne" peak 5973 is not a peak but just a point where a falling ridge to east splits in two ridges to two saddles in both the topo and the Tracestrack Map.

You are right, the height information is from the AMS and not from the JOG map.
I agree that the AMS map is very inaccurate in this region. But I wouldn't rely too much on horizontal position of any topographic map and aerial image in high mountains.
A better indication is obtainable on DEM-based maps like Tracestrack Topo Universal since these data are derived from Altimeters which look down perpendicular at a 30 m horizontal grid. Position of sharp peaks can therefore be well located in that grid. Height is less reliable since each single radar return contains contributions of a large span of heights.
Looking at the DEM-Map countour lines I consider several of your lately introduced peak positions based on FinnMaps as also considerably inaccurate.

The name and height (19791 ft) are from an US Army Map out of the license-free Perry Castaneda Library at Texas University, 1:250000 Jumla NH 44-11 (1954).
The actual official name may differ and very often names change from one valley to the other.
Height and precise coordinates may vary, too, since a differing projection and geoid model have been used.

Ganz löschen wäre nicht korrekt, da Überreste ja noch vorhanden sind, z.B. die Brücke über die Erms vor der ehemaligen Künkele-Mühle. Spezifische Eisenbahn-Einträge wie Spurweite, electrified=no und service=spur gehören eigentlich nicht mehr in OSM.
Die letzten paar Meter und die letzte Weiche aber gibt es sicher nicht mehr, da steht jetzt ein Gebäude.
Grundsätzlich müsste man vor Ort nachsehen, was noch vorhanden ist.

Hallo,

ich bin gerade in Portugal zu Gange und hatte dort den OSM-Instektor laufen. Nebenher wurde mir beim Nachsehen von was ganz anderem im Browser ein Gebiet bei Dingelstädt zu JOSM dazugeladen, ohne dass ich es bemerkte..
So kam es, dass mir der OSMI auch einen doppelten Punkt dort anzeigte, den ich mit korrigierte. So kam es zu dem riesigen Gebiet im Changeset.
Die Änderung selber war letztlich die Umwandlung von zwei Umrissrelationen in zwei normale Flächen und damit waren auch die zwei übereinander liegenden, aber unverbundenen Punkte weg, die OSMI beanstandete.

Sorry, I can't remember what I saw there. It has been 11 years ago and I haven't been there for years.
I must have been some source of water, definitely no tap, as can be found often in the mountains.
Tagging hasn't been so detailed at that time and I can give no further details. I can't even confirm that the object still exists.

I'm mapping since 2008 and I do take care of JOSM-Inspector warnings.
I can't reconstruct what happened at that time. Maybe a "broken" upload that completed after I uploaded a clean one.

I can't remember having added names.
If so, I have taken them from free usable sources like the map collection at the University of Texas.
In Nepal there are dozens of languages, several scripts and even more transliterations.
When comparing e.g. village names on navigational versus election related maps, it is not uncommon to have even more than two versions of latin transliteration.
So I'm not able to tell whether a name is official, just locally used or outdated.

Stimmt.
Ich hatte die letzte und nicht die erste Bearbeitung (vor 14 Jahren) erwischt.

Zu diesem Änderungssatz (genauer: zur Schulwegrelation) gibt es gerade eine Diskussion im OSM-Forum:
https://community.openstreetmap.org/t/relation-schulwege/111459

The language versions are often not translations but interpretations with additions.
The portuguese version also states "when not narrow consider using waterway=canal".
The english version makes the distinction between canal and drain/ditch according to superfluous water vs. useful water.
But anyway "consider using" is a recommendation, not a strict law.

Please use the English version when there are differences:
waterway=drain
There: "For artificial waterways created for carrying useful water or for transport consider using waterway=canal. "
I used ditch/drain for some time before, but when i came across waterway=canal & irrigation=yes I looked at the english version and changed to canal.

In contrary your mass edit of levadas in Madeira is not correct.

These lines were mostly tagged with power=pole, not with power=tower. The latter is usual with high-tension lines and I therefore got warnings by OSMI.
Mid-tension lines (<50kV) are used for distribution, high-tension lines (>100kV) for long distance exchange.
The 60kV lines in Algarve are mostly used for collecting wind park energy and are somehow in between.
By having a closer look the tagging of these lines in this region is very inconsistent: It is a mix of line/minor_line and with tower/pole although of same size and pole/tower distance. In high resolution images it looks more like single poles than (lattice) towers.
Anyway, I have no objections against power=line at 60kV, but this should be done consistently.