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.
I saw the same around Málaga: a lot of peaks some even in the city with an elevation of 24 meters in a residential building.
Hola.
Esos conjuntos de cambios son míos. Los datos están tomados del Instituto Geográfico Nacional (IGN), diferenciando picos de collados. El IGN ya nos dio permiso hace años para la utilización de sus mapas y datos publicados bajo licencia CC-BY y el Instituto está correctamente acreditado en la página de colaboradores de OSM.
That’s something the spanish community is aware of. These elements come from the Centro de Descargas del CNIG (IGN), since they are rendered by the IGN raster map (it’s cartographic information). Actually, they’re altitude level marks.
The big issue here is the render, specifically, the carto-css or mapnik, which is doing nothing about it, since 2019:
You can test different renders to see how they deal with natural=peak (spoiler: better)
If they are just elevation marks then they should be not be tagged with natural=peak. natural:peak denotes the top of a mountain. These are not tops of mountains.
To blame the renderer for this is IMHO incorrect.
No me importaría volver a revisar los datos para eliminar la etiqueta «natural=peak» y dejar solo la clave «ele» donde corresponda. Usé «natural=peak» porque no se recomienda usar la clave «ele» sin otra etiqueta. No obstante, como los datos son de interés, entiendo que se podría dejar la clave «ele» sin contradecir las directrices del wiki: «OpenStreetMap does not try to be a general elevation database, so do not tag elevation of nodes with no other tags, as well as for objects whose elevation is not an information of general interest».1
Esperaré a que más colaboradores opinen sobre este punto para empezar a revisar los datos. Donde las fuentes faciliten curvas de nivel creo que será fácil determinar puntos singulares. Donde no esté claro, eliminaré la etiqueta «natural=peak».
Hola de nuevo.
Tras esperar comentarios, este fin de semana comenzaré la revisión de puntos singulares del terreno en el municipio de Málaga para eliminar aquellos objetos que efectivamente no sean picos.
Seguiré el siguiente procedimiento:
Apunto en este hilo el más genérico que está abierto sobre los puntos con elevación pero sin nombre aquí y que animo que se siga allí la discusión.
