VALLI DI COMACCHIO

Ciao a tutti. Il problema è il seguente: le Valli di Comacchio sono composte dalle seguenti 4 singole valli che ho tracciato singolarmente con i rispettivi nomi
• Valle di Magnavacca
• Valle di Campo
• Valle Fossa di Porto
• Valle di Fatibello

Ho creato una nuova relazione “Specchio d’acqua” che è composto da queste 4 aree.

Il problema è che il rendering mostra i singoli 4 nomi delle Valli sopraelencate ma non il nome della relazione “Valli di Comacchio”.
So bene che una delle regole di OSM è di non mappare per il rendering, ma è altresì vero che un normale utente che vede la mappa di OSM con la scritta “Valle di Magnavacca” al posto di Valli di Comacchio” rimane quantomeno spiazzato, ritenendo poco affidabile la mappatura di OSM.

Come si può risolvere l’inghippo?
Grazie a tutti.

Secondo me il problema è un altro, allo stato attuale il tag natural=water é duplicato su due livelli (relazione e membri), e non mi sembra corretto nella logica di OSM. Forse si potrebbe sistemare intendendo la relazione madre come area protetta (che non mi sembra sia ancora mappata, vedere 1 e 2) e non come specchio d’acqua?

Per quanto riguarda il rendering, ad esempio il layer Tracetrack Topo renderizza “Valli di Comacchio” addirittura due volte, quindi come al solito dipende dal renderer:

Sono d’accordo con Ivan, I singoli water andrebbero in una relazione di tipo diverso.
Forse type=site, ma non sono sicuro
Altro problema è che natural=water è generico, si deve aggiungere un water=* per indicare cos’è. E anche salt=yes visto che l’acqua è salata
Credo che il più corretto sia lagoon (https://wiki.openstreetmap.org/wiki/Tag:water%3Dlagoon)

Il rendering logico dovrebbe far vedere il nome della relazione a livelli bassi e il nome dei componenti a livelli alti. Nel caso che fa vedere Ivanbranco invece il nome viene ripetuto sui quattro outer della relazione.
Inoltre hai modificato la salina, oltre ai lidi ecc. e ora c’è un buco senza tag descrittori.

Ivo

Grazie a tutti per le indicazioni. Rispondo punto per punto:
Convenite che il tag Natural=water essendo duplicato su due livelli, va modificato solo sulle singole Valli mentre per la relazione si usa altro? Ma cosa? Le Valli di COmacchio sono si, area protetta, ma anche acqua salata e palude. Se i singoli water vanno in una relazione diversa, quale sarebbe?

Per il rendering io penso che sia quello di OSM a fare da riferimento. Dunque secondo me sarebbe questo da considerare per le eventuali valutazioni.

Aggiungfere il tag salt = yes è un a bazzessola. L’ho già fatto con uno, lo farò anche con gli altri 3. Idem per lagoon.

Nocciolo del problema: premetto cher sono completamente daccordo con Jrachi Reano Ivo nel sostenere che "Il rendering logico dovrebbe far vedere il nome della relazione a livelli bassi e il nome dei componenti a livelli alti. ". Ordunque: come procedere? Io non lo so.

Infine le saline e i buchi. L mappatura è in lavorazione e avevo lasciato quelle zone buche per mapparle dettagliatamente. Tuttavia ora le ho riempite temporaneamente, nell’attesa (breve) di mapparle in dettaglio.

Ultimissima domanda: che landuser suggerite per le numerose isolette? Sono del luogo e sono poco più che erba o pianmte a basso fusto.

La struttura di questa relazione (un multipoligono la cui geometria è composta da altri multipoligoni composti) è molto difficile da gestire dai consumatori di dati e se interpreto bene la documentazione non è neanche standard. Infatti openstreetmap.org non lo renderizza per niente e cercando per bbox su overpass non lo trova (se si fa la ricerca globale lo trova ma non lo renderizza). Non so esattamente i dettagli dei sistemi di rendering dei vari stili, ma è probabile che molti di loro semplicemente non sappiano capire qual è la geometria di quella relazione.
In situazioni come questa per agevolare il lavoro ai consumatori io seguo le istruzioni delle boundary relation: uso le relazioni delle sottoaree con il ruolo di subarea, non di outer, definendo la geometria dell’area padre direttamente sull’elemento padre (usando le way esterne che definiscono il perimetro dell’area padre).
Per esempio la relazione del Parco regionale Vena del Gesso Romagnola (che contiene varie sottoaree con livelli di protezione diversa) è strutturata così:

Premesso che questo è lo standard delle relazioni boundary quindi va bene a prescindere da come viene renderizzato, quasi tutti gli stili mostrano (direi correttamente) solo la relazione padre a basso zoom e le relazioni figlie ad alto zoom:
image

Secondo me dovremmo strutturare le Valli di Comacchio in maniera simile con la relazione padre contenente:

Per quanto riguarda il tagging della relazione padre

In realtà credo (correggetemi se sbaglio) che l’area protetta sia un’altra cosa, ovvero il Parco del Delta del Po, abbia un’estensione molto più ampia e vada gestito separatamente.
Io per la relazione delle Valli di Comacchio proporrei nautral=wetland, però non sono assolutamente certo che sia il tag giusto.

Sono due cose differenti, la zona speciale di conservazione/zona di protezione speciale “Valli di Comacchio” e il parco regionale “Delta del Po”. Il primo é compreso quasi (dice il sito della regione) interamente dentro al secondo.

Ok, vedo che quell’area protetta non include solo lo specchio d’acqua con le quattro valli ma anche parte dell’area attorno e capisco meglio la tua domanda di prima

Io direi che ha senso tenere l’attuale relazione per lo specchio d’acqua con natural=... + wikidata=Q1891671, applicando tutte le modifiche del caso che stiamo discutendo. In aggiunta si potrebbe mappare quest’area protetta creando un’ulteriore relazione con type=boundary + boundary=protected_area + wikidata=Q55443069 + tutti i tag del caso relativi all’area protetta.

Sono d’accordo ma non avendo mai mappato delle subaree non so ocme si fa. Sono impostazioni dei tag o delle relazioni?

Quando vai ad aggiungere le relazioni figlie come membri della relazione madre scrivi come ruolo subarea invece che outer.

Esempio su JOSM:

Esempio su iD:

Io ho messo subarea alle 4 zone che compongono le Valli di Comacchio ma il rendering OSM non ha prodotto nessun effetto. Accettasi altri suggerimenti e/o iniziative.

Grazie a tutti.

Come dicevo sopra:

Nella relazione mancavano le way del perimetro per definire la geometria delle Valli di comacchio. Le ho aggiunte e ora osm.org renderizza la relazione:

Attendiamo che si pulisca la cache per vedere il rendering aggiornato della mappa sotto

Mi pare che ora la mappa venga renderizzata correttamente:

Screenshot 2024-03-11 175319

Rimuovere la sezione sottolineata in giallo della multipoligono

Ho corretto. Qualcuno mi può dire se ora è tutto ok come credo sia

Si tratta di un multipoligono a 1 membro, non inner a se stesso. Ricostruito con lo relation toolbox di JOSM per trasformarlo in un poligono semplice. Non ho idea di come farlo rapidamente in ID Editor.

Penso che gli isolotti debbano essere interni alle sottoaree e non alla principale, per questo vengono resi come acqua.

E la surface degli islets?

In realtà credo che per avere la certezza che venga renderizzato come isola ogni elemnto debba essere presente come inner sia sulla relazione madre che sulla figlia. Prima erano solo sulla figlia. Li ho aggiunti anche a quella madre. Ora attendiamo per vedere se così funziona

Ora no d’accordo JOSM e ID Editor

Le ruote macinano lentamente… Ho applicato alcune correzioni commentate è CS Changeset: 148593732 | OpenStreetMap. Ci sono altri isolotti che devono essere aggiunti al VdC MP esterno che viene reso come acqua e deve essere aggiunto un tag landuse o natural per indicare di cosa sono ricoperti gli isolotti (già notato in precedenza). Altri problemi sono stati segnalati da JOSM, come i multipoligoni annidati. Si potrebbe considerare di convertire le Valli di Comacchio in una relazione di boundary typo protected area, consentendo una grande semplificazione. Valli di Comacchio - Wikipedia & Tag:boundary=protected_area - OpenStreetMap Wiki.

ciao

Si era già parlato di questo tema e eravamo rimasti che quest’area non corrisponde con nessuna area protette (ce ne sono due ma coprono delle aree in più:

Comunque non mi è chiaro da cosa deriverebbe la semplificazione: anche un type=boundary+boundary=protected_area richiede che gli elementi che definiscono la geometria siano presenti come inner e outer nella relazione stessa