hi!
i may in andalusia since 15+years - but current i see import of peak-data without spirit.
look the data of Changesets by itrivi | OpenStreetMap current.
the definition of peak is Tag:natural=peak - OpenStreetMap Wiki - but here are peaks with less meters differens in the height.
Just because the data is available doesn’t mean you have to include it in OpenStreetMap.
We aren’t mapping for the renderer, but the result here is that something should be attributed differently.
regards Jan
Hm, yes, perhaps a bit too much.
As a rough rule of thumb, I think, one needs a good reason to include a natural=peak if a name can’t be found. Sure, nameless peaks a fine, but “I have survey point elevation data” isn’t a good enough reason alone IMO.
HI! can you write to the mapper, as he probably comes from Spain and I don’t know the language very well. Regards Jan
No sé muy bien el español 
I absolutely agree with you that contacting the mapper is what’s next, but I’m sorry to say that I’m only a drive-by mapper myself.
I noticed at least one example where it seems there may be duplication (2 peaks with the same elevation very close to each other, where I can only see one on the IGN map). I asked about that in the changeset comments here:
Aside from that, I’m not sure if there is a problem here. There seems to be no guidance about how prominent a peak needs to be to be recorded in OSM. Arguably if IGN thinks it is worth marking, it could be worth recording in OSM also. I am based closer to the city of Málaga where a lot of peaks are already mapped in this way, by a different mapper or mappers.
I am more concerned about this possibly being some sort of stealth
import - I spotted one example where what the user mapped was clearly
not from either of the sources specified so I asked what the real source
was here: Changeset: 150749353 | OpenStreetMap
In that example, the IGN map shows either 981m or 982m depending on how far you zoom in. I suppose there are two series with different scales, perhaps surveyed at different times. Of course that leaves the question of which series is being used and whether it is used consistently.
Taking a quick look at its changesets, they are made through iD, so I presumably discard an import.
He’s clearly using the IGN raster map to include all these peaks, as you can see in the following pictures:
Notice he’s not adding at least the mountain passes as natural=peak (whose elevation is included in the IGN raster map also).
So I bet he’s doing this process manually, and that’s the reason to miss/wrong some features.
Manual or not, and regardless of the tooling used, this is a data import and should be discussed and reviewed as such.
I would propose to look into “Topographic prominence” for some formal definitions and suggestions.
As an example, we could imagine a rule such as "Only map a natural=peak if either
name=* or any additional relevant tag aside from ele=* (for example summit:cross=yes, wikipedia=*, …)where I leave the definition of X and Y to people who understand the topic better than me.
Peaks not satisfying any of those conditions don’t need to be in OSM, and can be calculated readily from elevation maps like the SRTM.
Since this is the only place I found discussing this mapper: Has anything been done wrt to all these peaks?
This is really going to the absurd.
There are “peaks” on the same elevation just meters apart. All the Canary Island look like high mountain terrain with peaks everywhere.
I think this needs to stop. It’s entirely pointless as has been said above.
On the “standard” layer, yes. But that’s largely because they render all “peaks” regardless of any other consideration such as whether the peak has a name. Tracestrack Topo, for example, uses the same data to produce a rendering that looks OK to me.
Standard
Tracestrack Topo
Right. The display part is certainly half of the problem. Tracestrack looks nice because they use full isolines, and drop many not so prominent features. The standard map consideres all peaks important enough to display (when used well, they well suited for navigation).
The other half of the problem is that two “peaks” 50 meters apart simply are no “peaks”. The OSM wiki says the node defined “The top (summit) of a hill or mountain”. Nobody would call a height difference of less than one’s own height a hill.
So far the OSM principle has been to not map elevation data, but to amend it from other sources when required. Having a “peak” just about everywhere quite goes against that.
