ciao,
vedo che hai mappato parti di molti edifici singoli con building=* quando invece soltanto il perimetro esterno dovrebbe essere mappato come building e le parti con caratteristiche diverse come building:part=yes.
Inoltre posso chiedere come hai riportato l'altezza degli edifici? Vedo che è riportata al centimetro e alcuni edifici hanno altezze bizzarre (height=0). Si tratta per caso di un import tramite qualche plugin?

ciao, perché è stata eliminata l'area del resort Poggio all'Agnello? A quanto mi risulta l'area è privata ed è di proprietà del resort, fra l'altro il perimetro coincide con la rete posta a delimitazione dell'area

Sono d'accordo, va eliminata. Non mi risulta nessuno progetto/studio di fattibilità per questa per ora fantomatica linea 5.

Questo tracciato cosa dovrebbe essere?
Se si tratta di un itinerario escursionistico ufficiale andrebbe mappato tenendo conto dell'esistente, quindi utilizzando una relazione di tipo route (vedi osm.wiki/IT:Hiking).
Così come è ora non rispetta le linee guida di mappatura dato che interseca e si sovrappone ad altre strade lungo tutto il suo percorso e andrebbe quindi eliminato o trasformato in relazione di tipo route utilizzando i percorsi esistenti come membri della relazione. Stesso discorso per il changeset #52329039

ok, grazie

Ciao sembola, un tratto (#482887844) di strada comunale m.marittima-accesa è indicato con access=no. Mi pare di averla percorsa quest'estate, forse era stata chiusa solo temporaneamente per lavori?

Hi, these ways were supposed to be highway=service. Thank you for pointing me to the error!

Ciao,
Vedo che sei nuovo e che usi l'editor ID. Ti invito a considerare in futuro l'uso di un editor più preciso e completo come Josm. In genere ID si utilizza per modifiche minori che non richiedono grande precisione geometrica. Ciao!

si, già quasi tutti i landuse=residential hanno all'interno altri landuse, il problema è che ci sono ancora molte aree prive di landuse perchè di identificazione incerta. Adesso tutte queste appaiono invece come residential (argini, zone di pertinenza ferroviaria, ecc..).
Non ho guardato in inglese ma sul wiki it non è specificato che l'utilizzo di place come poligono debba essere usato soltanto in caso di confini ben individuati, ma "il poligono indica in genere il confine della zona edificata". Inoltre in questo caso il confine del place è quasi interamente delimitato dal mare, dalla ferrovia e da una SP, come normalmente riconosciuto da chiunque sia della zona.
Non credo che una interpretazione possa avere un valore diverso da un'altra fino a che non ci sia un consenso generale o non sia chiaramente specificato nel wiki.
Cmq a parte questo l'idea originale di usare il place=town come poligono era di assegnargli altri tag come population per esempio, per poter indicare appunto la popolazione soltanto del paese/città capoluogo e non di tutto il comune come viene fatto attualmente con il nodo admin_centre, a meno che non ci siano altri metodi.

Ciao,
perchè è stato modificata la relazione #3665361 ?
Precedentemente con place=town indicava approssimativamente l'area della zona urbana e periurbana quindi non solo quella residenziale.
Con landuse=residential appaiono invece come residenziali aree che in realtà non lo sono, oltre a sovrapporsi ai landuse=residential già taggati che coincidono con le aree urbane dei rioni del paese.
Fra l'altro place=town come multipoligono viene consigliato anche dalla wiki italiana osm.wiki/IT:Key:place

Ciao, riguardo questo changeset vedo che i sentieri 14B e parte del 15 sono stati uniti in un'unica way perdendo alcuni dettagli, ma più che altro i valori dei tag "mtb:scale:uphill", "smoothness", "trail_visibility" e "incline" appaiono ora
errati (valori multipli dove non sono ammessi). Provvedo a revertare il changeset per intanto e aggiungo il tag bicycle=yes che in effetti era mancante

test

?

Ok, ora è tutto chiaro, grazie per le delucidazioni. Vada per caravans=yes e motorcar=yes. ciao!

Ciao, per quanto riguarda la way "287654141", la key "designation" è stata modificata in "description". In tal caso il valore della chiave rispecchiava le indicazioni del cartello davanti al parcheggi o, cosa che dovrebbe renderla una restrizione legale ufficiale; non vedo quindi perchè non possa andare bene "designation". Forse è meglio aggiungere tourism=caravan_site oltre ad amenity=parking?

Ho rifatto quel sentiero: alla fine si, probabilmente è più indicato mtb:scale1. Ho impostato la prima parte a 1, mediamente un po' più difficile da affrontare, fino all'intersezione con M&M e il resto a 0+, specificando vari punti con un valore maggiore (non tutti i tornanti naturalmente, soltanto due punti più ostici). Sono d'accordo sul valore per gli altri sentieri, anche per il 3dita probabilemente è più indicato 3, il rock-oh invece non ricordo di averlo fatto.
Per ora direi di rimanere così senza discostarsi troppo dalle indicazioni del wiki (dove in effetti stanno abbastanza bassi)..
Ciao!

spero di non essere stato troppo pedante e se credi sia il caso può andare anche 1 come mtb:scale, 2 però è obiettivamente troppo soprattutto considerando il contesto.. sarebbe da mettere alle votazioni se partecipasse qualcun'altro ;)

Per quanto riguarda l'aggiunta del ref al nome, non credo sia corretto perchè appunto il nome che si dà all'oggetto dovrebbe corrispondere esattamente al nome reale dello stesso, senza aggiunte (anche se in questo caso, come hai notato, sarebbe meglio usare "mtb:name", ma lasciamo perdere:). Il fatto che l'identificativo del sentiero non sia visibile nella mappa di default di osm non giustifica la sua aggiunta al nome: agire così rientra nel caso di "tagging for the renderer" (http://goo.gl/IGc2Fp); e` infatti compito del renderer (la mappa) visualizzare i dati immessi ma non ci si può aspettare che la mappa di base renderizzi tutto ciò che viene immesso. Ci sono mappe specifiche che visualizzano il campo "ref" come waymarkedtrails.org o il progetto di mappe offline openandromaps (http://goo.gl/tMDQsE), ad esempio.
Quindi come buona pratica generica sarebbe meglio taggare seguendo le linee guida senza dare troppa importanza a come osm.org visualizza i dati inseriti.
Per quanto riguarda la difficoltà mtb, qui in effetti si rientra in un campo un po' più soggettivo.. Personalmente sarei più indirizzato a usare mtb:scale=0 per un lungo sentiero che non presenta difficoltà alcuna se non in due o tre punti come in questo caso, magari taggando quei punti con un valore maggiore. Comunque, apparte questo, ormai in tutta la zona e anche nelle zone limitrofe sono presenti dei valori di mtb:scale piuttosto bassi e raramente si vedono mtb:scale maggiori di 2 se non per indicare trail piuttosto tecnici dal quasi trialistico in su. Utilizzando mtb:scale=2 ci ritroveremmo con altri sentieri molto più tecnici ma con mtb:scale uguale o minore a questo e si dovrebbe così cambiare la scala di riferimento un po' per tutti i sentieri.. magari si potrebbe usare mtb:scale=0+ per questo, prima mi pare fosse 0.

ho controllato meglio e il punto 4 in effetti non è da considerare dato che il tracciato non era diviso in segmenti.. gli altri punti però rimangono.

Perchè sono state apportate queste modifiche al sentiero "I Cavalli"?
Non seguono le linee guida del wiki in quanto:
1. mancano i commenti alle modifiche apportate.
2. aggiunto campo "ref", già presente nella relazione di tipo "route" cui fa parte l'oggetto.
3. modifica del nome del sentiero con aggiunta del valore del campo "ref".
4. Segmenti del sentiero unificati in uno solo con conseguente perdita di dettagli.
5. mtb:value=2 errato in quanto il sentiero non presenta alcuna difficoltà, tranne che in alcuni punti. (osm.wiki/IT:Key:mtb:scale)