Discussione:
strade extraurbane non pavimentate
alberto
2009-05-14 13:08:59 UTC
Permalink
Come vi regolate nel taggare strade extraurbane di campagna con
pavimentazione in ghiaino?
Le mettete come hoghway=unclassified o come track?
Premetto, non sono piste per trattori, parlo di strade non asfaltate.
direte che mi sono risposto da solo, ma ho il dubbio, il rendering non
le distingue dalle asfaltate e la differenza c'è...
Ciao
Alberto
Andrea Musuruane
2009-05-14 13:31:43 UTC
Permalink
Post by alberto
Come vi regolate nel taggare strade extraurbane di campagna con
pavimentazione in ghiaino?
Le mettete come hoghway=unclassified o come  track?
Premetto, non sono piste per trattori, parlo di strade non asfaltate.
direte che mi sono risposto da solo, ma  ho il dubbio, il rendering non
le distingue dalle asfaltate e la differenza c'è...
Io le traccio come highway=track e tracktype=grade1.

http://wiki.openstreetmap.org/wiki/Track
Track: Roads for agricultural use [...]

http://wiki.openstreetmap.org/wiki/Key:tracktype
grade1: Paved track or heavily compacted hardcore.

Ciao,

Andrea.
alberto
2009-05-14 15:01:52 UTC
Permalink
Post by Andrea Musuruane
Io le traccio come highway=track e tracktype=grade1.
http://wiki.openstreetmap.org/wiki/Track
Track: Roads for agricultural use [...]
http://wiki.openstreetmap.org/wiki/Key:tracktype
grade1: Paved track or heavily compacted hardcore.
Ciao,
Andrea.
Mi sembra una buona scelta, la adotterò.
Ciao
alberto
Alberto Nogaro
2009-05-14 15:10:53 UTC
Permalink
-----Original Message-----
Sent: giovedì 14 maggio 2009 15.32
To: openstreetmap list - italiano
Subject: Re: [Talk-it] strade extraurbane non pavimentate
Post by alberto
Come vi regolate nel taggare strade extraurbane di campagna con
pavimentazione in ghiaino?
Le mettete come hoghway=unclassified o come  track?
Premetto, non sono piste per trattori, parlo di strade non asfaltate.
direte che mi sono risposto da solo, ma  ho il dubbio, il rendering non
le distingue dalle asfaltate e la differenza c'è...
Secondo me dipende dall'uso, non dalla pavimentazione. Sono track se
rispettano tre condizioni:

- sono adibite prevalentemente ad uso agricolo o forestale
- non hanno alcuna funzione di collegamento tra località diverse
- sono abbastanza larghe da permettere il passaggio di mezzi di trasporto
(altrimenti sono path).

Altrimenti sono unclassified (o anche superiore, se a dispetto della
pavimentazione sono sufficientemente importanti).
In questo caso per specificare lo stato fisico della strada puoi usare
chiavi come surface=*, smoothness=*, width o est_width.

Ciao.
albertobonati
2009-05-14 15:57:44 UTC
Permalink
Post by Alberto Nogaro
Secondo me dipende dall'uso, non dalla pavimentazione. Sono track se
- sono adibite prevalentemente ad uso agricolo o forestale
- non hanno alcuna funzione di collegamento tra località diverse
- sono abbastanza larghe da permettere il passaggio di mezzi di trasporto
(altrimenti sono path).
Altrimenti sono unclassified (o anche superiore, se a dispetto della
pavimentazione sono sufficientemente importanti).
In questo caso per specificare lo stato fisico della strada puoi usare
chiavi come surface=*, smoothness=*, width o est_width.
Ciao.
Beh, le strade che ho in mente dopotutto rispettano anche le condizioni
per essere track:
- sono strade che non collegano località o frazioni
- sono abbastanza larghe da permettere il passaggio di mezzi di trasporto
- sono utilizzate prevalentemente per uso agricolo o per accesso a fondi
agricoli.

Mi sembra importante comunque differenziarle dalle asfaltate, altrimenti
si finisce a visualizzarle come fa Google dove sembrano ottime e comode
strade anche dei tratturi erbosi tra i campi, solo perchè hanno un nome
(e magari anche una targa stradale, caso visto personalmente).... :-)
Ciao
Alberto
Elena of Valhalla
2009-05-14 16:44:40 UTC
Permalink
Post by albertobonati
Beh, le strade che ho in mente dopotutto rispettano anche le condizioni
- sono strade che non collegano località o frazioni [...]
in questo caso track va benissimo
Post by albertobonati
Mi sembra importante comunque differenziarle dalle asfaltate,
per questo c'e` il tag surface: sta semmai ai render controllare la
sua presenza (e magari renderizzare le unclassified non asfaltate con
i bordi tratteggiati, o qualcosa del genere, ma distinto dalle track)
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Cristian Testa
2009-05-14 19:49:47 UTC
Permalink
Sono d'accordo con te. Mi sembra che condizioni necessarie per una track
siano innanzitutto la mancanza di pavimentazione e la possibilità di accesso
ai mezzi.
Il fatto che colleghino il centro abitato con cascine o località vicine a
mio parere è secondario. Dal wiki le unclassified si applicano alle strade
urbane ed a quelle extraurbane che soddisfano i requisiti minimi per essere
chiamate strade... e per me una strada propriamente detta deve almeno essere
pavimentata (asfalto, porfido, autobloccanti) e deve riuscire a passarci una
piccola auto. Se non sono pavimentate per me sono tutte track.
Ciao
Cristian

----- Original Message -----
From: "albertobonati" <albertobonati-VGgt2q2+T+***@public.gmane.org>
To: "openstreetmap list - italiano" <talk-it-3+rWM/WnaLOn4i5uJCXUsti2O/***@public.gmane.org>
Sent: Thursday, May 14, 2009 5:57 PM
Subject: Re: [Talk-it] strade extraurbane non pavimentate
Post by Alberto Nogaro
Secondo me dipende dall'uso, non dalla pavimentazione. Sono track se
- sono adibite prevalentemente ad uso agricolo o forestale
- non hanno alcuna funzione di collegamento tra località diverse
- sono abbastanza larghe da permettere il passaggio di mezzi di trasporto
(altrimenti sono path).
Altrimenti sono unclassified (o anche superiore, se a dispetto della
pavimentazione sono sufficientemente importanti).
In questo caso per specificare lo stato fisico della strada puoi usare
chiavi come surface=*, smoothness=*, width o est_width.
Ciao.
Beh, le strade che ho in mente dopotutto rispettano anche le condizioni
per essere track:
- sono strade che non collegano località o frazioni
- sono abbastanza larghe da permettere il passaggio di mezzi di trasporto
- sono utilizzate prevalentemente per uso agricolo o per accesso a fondi
agricoli.

Mi sembra importante comunque differenziarle dalle asfaltate, altrimenti
si finisce a visualizzarle come fa Google dove sembrano ottime e comode
strade anche dei tratturi erbosi tra i campi, solo perchè hanno un nome
(e magari anche una targa stradale, caso visto personalmente).... :-)
Ciao
Alberto
Elena of Valhalla
2009-05-14 20:49:06 UTC
Permalink
Post by Cristian Testa
Dal wiki le unclassified si applicano alle strade
urbane ed a quelle extraurbane che soddisfano i requisiti minimi per essere
chiamate strade... e per me una strada propriamente detta deve almeno essere
pavimentata (asfalto, porfido, autobloccanti) e deve riuscire a passarci una
piccola auto. Se non sono pavimentate per me sono tutte track.
ci sono un sacco di superfici non pavimentate su cui un'auto normale
puo` tranquillamente passare, anche se lentamente, un esempio su tutti
la terra battuta o il generico sterrato[1]

se un tratto del genere e` dotato di nome, e magari porta su case
dotate di numero civico, per me e` piu` che degno di essere chiamato
unclassified o residential a seconda dei casi, con la specifica di
surface=unpaved o simili

[1] primo esempio trovato su google images per spiegare cosa intendo:
http://www.motoinfuoristrada.com/Immagini/Via Del Sale 2005/Inizio
sterrato Col del Mulo.jpg
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Andrea Musuruane
2009-05-14 20:58:58 UTC
Permalink
Post by Elena of Valhalla
Post by Cristian Testa
Dal wiki le unclassified si applicano alle strade
urbane ed a quelle extraurbane che soddisfano i requisiti minimi per essere
chiamate strade... e per me una strada propriamente detta deve almeno essere
pavimentata (asfalto, porfido, autobloccanti) e deve riuscire a passarci una
piccola auto. Se non sono pavimentate per me sono tutte track.
ci sono un sacco di superfici non pavimentate su cui un'auto normale
puo` tranquillamente passare, anche se lentamente, un esempio su tutti
la terra battuta o il generico sterrato[1]
Io invece sono pienamente d'accordo con Cristian. Se la strada
dell'immagine non è una track, non so cosa lo sia.

Ciao,

Andrea.
Elena of Valhalla
2009-05-14 21:09:59 UTC
Permalink
Post by Andrea Musuruane
Io invece sono pienamente d'accordo con Cristian. Se la strada
dell'immagine non è una track, non so cosa lo sia.
in quel caso e` probabile che sia anche in mezzo al nulla, ma ho visto
piu` casi di strade con esattamente quel tipo di fondo che portavano a
villette (non fattorie o case rurali, proprio villette)
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Cristian Testa
2009-05-14 21:28:30 UTC
Permalink
Scusa.... ma questa sarebbe "unclassified"??? Va bene che un'auto lì ci
possa anche passare, ma quando si parla di "requisiti minimi" per strade
extraurbane non penso che ci si riferisca ad una mulattiera....
Per la classificazione io mi baso sul wiki:

http://wiki.openstreetmap.org/wiki/IT:Map_Features

che ha tanto di foto. Il fatto che poi quelle strade abbiano anche un nome e
dei numeri civici per me è secondario.
Ti posso dire che criteri uso io per i tag delle strade extraurbane:

- Strada statale: primary
- Strada regionale: secondary (primary in casi eccezionali)
- provinciale con almeno una corsia per senso di marcia e linea di mezzeria:
secondary
- Provinciale stretta ma sufficiente per due auto, senza linea di mezzeria:
tertiary (vedi le classiche provinciali strette in montagna)
- Strade extraurbane strette, sufficienti per due auto, senza linea di
mezzeria: tertiary
- Strade asfaltate di larghezza sufficiente per una sola auto (e ce ne
sono), nessuna mezzeria: unclassified
- Non asfaltate: track. Il tracktype lo definisco in base alla compattezza
del fondo.

Le urbane per me sono tutte unclassified (non asfaltate a parte che
considero track) tranne le vie di transito principali che considero
tertiary.
Nel caso una strada di importanza maggiore attraversi il centro abitato mi
riservo di mantenerne la classificazione se le dimensioni e la
percorribilità non subiscono variazioni sostanziali. Non so se sia
completamente corretto quello che faccio, ma mi sembra il giusto compromesso
tra l'importanza della strada sulla carta e le sue caratteristiche fisiche,
nel rispetto delle indicazioni del wiki.
Se qualcuno ha regole più precise per la classificazione mi piacerebbe
conoscerle.

Ciao
Cristian

----- Original Message -----
From: "Elena of Valhalla" <elena.valhalla-***@public.gmane.org>
To: "openstreetmap list - italiano" <talk-it-3+rWM/WnaLOn4i5uJCXUsti2O/***@public.gmane.org>
Sent: Thursday, May 14, 2009 10:49 PM
Subject: Re: [Talk-it] strade extraurbane non pavimentate
Post by Elena of Valhalla
Post by Cristian Testa
Dal wiki le unclassified si applicano alle strade
urbane ed a quelle extraurbane che soddisfano i requisiti minimi per essere
chiamate strade... e per me una strada propriamente detta deve almeno essere
pavimentata (asfalto, porfido, autobloccanti) e deve riuscire a passarci una
piccola auto. Se non sono pavimentate per me sono tutte track.
ci sono un sacco di superfici non pavimentate su cui un'auto normale
puo` tranquillamente passare, anche se lentamente, un esempio su tutti
la terra battuta o il generico sterrato[1]
se un tratto del genere e` dotato di nome, e magari porta su case
dotate di numero civico, per me e` piu` che degno di essere chiamato
unclassified o residential a seconda dei casi, con la specifica di
surface=unpaved o simili
http://www.motoinfuoristrada.com/Immagini/Via Del Sale 2005/Inizio
sterrato Col del Mulo.jpg
--
Elena ``of Valhalla''
homepage: http://www.trueelena.org
_______________________________________________
Talk-it mailing list
http://lists.openstreetmap.org/listinfo/talk-it
Paolo Monegato
2009-05-16 10:51:12 UTC
Permalink
Cristian Testa ha scritto
Post by Cristian Testa
- Strada statale: primary
- Strada regionale: secondary (primary in casi eccezionali)
secondary
tertiary (vedi le classiche provinciali strette in montagna)
- Strade extraurbane strette, sufficienti per due auto, senza linea di
mezzeria: tertiary
- Strade asfaltate di larghezza sufficiente per una sola auto (e ce ne
sono), nessuna mezzeria: unclassified
- Non asfaltate: track. Il tracktype lo definisco in base alla compattezza
del fondo.
Le urbane per me sono tutte unclassified (non asfaltate a parte che
considero track) tranne le vie di transito principali che considero
tertiary.
Ciao
Cristian
Io uso questa proposta:
http://wiki.openstreetmap.org/wiki/IT:Italian_Roads_Tagging
Per me la strada regionale è quasi sempre primary: in Veneto molte
statali sono diventate regionali, penso ad esempio alla SS53
Treviso-Vicenza che è statale da Vicenza fino a metà strada e poi è
regionale. Ancor più clamoroso il caso della SS47 Padova-Trento che da
Padova fino all'incrocio con la 53 è stata declassata addirittura a
provinciale...
Le strade provinciali le mapperei sempre come secondary e userei
tertiary come indicato nella pagina che ho linkato.
Per le urbane classificherei unclassified le principali (quelle non
classificate come tertiary) e residential le altre.
Ciao
Paolo
Carlo Stemberger
2009-05-16 12:19:10 UTC
Permalink
Post by Paolo Monegato
http://wiki.openstreetmap.org/wiki/IT:Italian_Roads_Tagging
Per me la strada regionale è quasi sempre primary: in Veneto molte
statali sono diventate regionali, penso ad esempio alla SS53
Treviso-Vicenza che è statale da Vicenza fino a metà strada e poi è
regionale. Ancor più clamoroso il caso della SS47 Padova-Trento che da
Padova fino all'incrocio con la 53 è stata declassata addirittura a
provinciale...
Le strade provinciali le mapperei sempre come secondary e userei
tertiary come indicato nella pagina che ho linkato.
Per le urbane classificherei unclassified le principali (quelle non
classificate come tertiary) e residential le altre.
Come già detto tante (tante, tante...) altre volte, questo è un po' il
compromesso che abbiamo raggiunto nell'ultimo anno, ma non è ancora del
tutto soddisfacente (soprattutto in ambito urbano) non essendo aderente
a quanto fatto all'estero. Spero di trovare un po' di tempo quest'estate
per sistemare una volta per tutte.

In ogni caso non ci si può basare né sulla classificazione
amministrativa (per quanto detto da Paolo), né sul tipo di fondo (per il
quale esiste per l'appunto una chiave apposita): i due elementi possono
al massimo essere considerati come un'indicazione di massima, un aiuto
per scelta, ma non sono assolutamente dei criteri assoluti; ad esempio
le residential non asfaltate, pur non essendo comunissime, esistono
anche da me, in Brianza, non esattamente definibile come zona in via di
sviluppo.

Se poi l'indicazione del fondo non viene renderizzata, questo è un
problema da segnalare a chi di dovere, ma che non dobbiamo aggirare noi
cambiando i tag.
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Cristian Testa
2009-05-16 13:57:24 UTC
Permalink
Sulle regionali ti do ragione: l'unica regionale mappata in zona è in effetti marcata come primary, anche se, per la struttura a due carreggiate separate, due corsie per senso di marcia e il divieto per mezzi non agricoli e non a motore potrebbe essere benissimo taggata come trunk....
Per le provinciali non farei di tutta l'erba un fascio: è vero che come importanza potrebbero benissimo essere tutte secondary, ma se ti facessi un giro sulle colline dalle mie parti troveresti molte strade segnate come provinciali molto strette, dove due auto ci passano a malapena e senza nessuna riga di mezzeria ed altre, sempre segnate come provinciali, belle larghe e con tanto di mezzeria e guard-rail. A me sembra possa valere la pena distinguerle "degradando" quelle più strette.
Sono comunque d'accordo con te di non eccedere troppo e, almeno per le statali e le regionali, usare sempre il tag primary.
Ciao
Cristian
----- Original Message -----
From: Paolo Monegato
To: openstreetmap list - italiano
Sent: Saturday, May 16, 2009 12:51 PM
Subject: Re: [Talk-it] strade extraurbane non pavimentate


Cristian Testa ha scritto
Ti posso dire che criteri uso io per i tag delle strade extraurbane:

- Strada statale: primary
- Strada regionale: secondary (primary in casi eccezionali)
- provinciale con almeno una corsia per senso di marcia e linea di mezzeria:
secondary
- Provinciale stretta ma sufficiente per due auto, senza linea di mezzeria:
tertiary (vedi le classiche provinciali strette in montagna)
- Strade extraurbane strette, sufficienti per due auto, senza linea di
mezzeria: tertiary
- Strade asfaltate di larghezza sufficiente per una sola auto (e ce ne
sono), nessuna mezzeria: unclassified
- Non asfaltate: track. Il tracktype lo definisco in base alla compattezza
del fondo.

Le urbane per me sono tutte unclassified (non asfaltate a parte che
considero track) tranne le vie di transito principali che considero
tertiary.

Ciao
Cristian
Io uso questa proposta:
http://wiki.openstreetmap.org/wiki/IT:Italian_Roads_Tagging
Per me la strada regionale è quasi sempre primary: in Veneto molte statali sono diventate regionali, penso ad esempio alla SS53 Treviso-Vicenza che è statale da Vicenza fino a metà strada e poi è regionale. Ancor più clamoroso il caso della SS47 Padova-Trento che da Padova fino all'incrocio con la 53 è stata declassata addirittura a provinciale...
Le strade provinciali le mapperei sempre come secondary e userei tertiary come indicato nella pagina che ho linkato.
Per le urbane classificherei unclassified le principali (quelle non classificate come tertiary) e residential le altre.
Ciao
Paolo
Federico Cozzi
2009-05-18 07:24:43 UTC
Permalink
Post by Cristian Testa
Per le provinciali non farei di tutta l'erba un fascio: è vero che come
Concordo: la famosa tabellina italiana
statale, regionale -> primary
provinciale -> secondary
comunale -> da tertiary in giù
secondo me indica la classificazione "media".
Cioè ci possono essere provinciali (ad es. statali declassate) che
sono primary, mentre altre provinciali sono così minuscole e poco
trafficate da essere tertiary.
(così come possono esistere strade comunale primary o secondary, ma
questo è un altro discorso...)

Ciao
Paolo Monegato
2009-05-16 10:33:09 UTC
Permalink
Post by Elena of Valhalla
Post by Cristian Testa
Dal wiki le unclassified si applicano alle strade
urbane ed a quelle extraurbane che soddisfano i requisiti minimi per essere
chiamate strade... e per me una strada propriamente detta deve almeno essere
pavimentata (asfalto, porfido, autobloccanti) e deve riuscire a passarci una
piccola auto. Se non sono pavimentate per me sono tutte track.
ci sono un sacco di superfici non pavimentate su cui un'auto normale
puo` tranquillamente passare, anche se lentamente, un esempio su tutti
la terra battuta o il generico sterrato
se un tratto del genere e` dotato di nome, e magari porta su case
dotate di numero civico, per me e` piu` che degno di essere chiamato
unclassified o residential a seconda dei casi, con la specifica di
surface=unpaved o simili
Concordo.
Dalle mie parti (alta padovana) fino a qualche anno fa molte vie non
erano asfaltate ed avevano un fondo sterrato/ghiaino. In seguito molte
sono state asfaltate ma alcune sono rimaste unpaved. Per me quelle sono
residential con la specifica surface=gravel. Altre strade sterrate,
senza nome e periferiche che portano a poche case sparse ma soprattutto
a campi le classificherei come track (anche se collegano località).

Quoto Alberto, sarebbe importante che la mappa visualizzasse in modo
Post by Elena of Valhalla
Mi sembra importante comunque differenziarle dalle asfaltate, altrimenti
si finisce a visualizzarle come fa Google dove sembrano ottime e comode
strade anche dei tratturi erbosi tra i campi, solo perchè hanno un nome
Cristian Testa
2009-05-16 14:09:17 UTC
Permalink
Concordo. Se sono effettivamente strade che portino a zone residenziali con villette o simili, è corretto che vengano taggate come residential specificandone il tipo di fondo. Ciò però per me non vuol dire che le suddette villette siano a km di distanza ma nelle immediate vicinanze del centro abitato.
Per quelle che vanno in mezzo ai campi (anche come prosecuzione delle suddette residential) anche per me il tag track è il più indicato.
Dovremmo forse solo raggiungere un punto di vista comune sull'assegnazione dei grade.

Ciao
Cristian
----- Original Message -----
From: Paolo Monegato
To: openstreetmap list - italiano
Sent: Saturday, May 16, 2009 12:33 PM
Subject: Re: [Talk-it] strade extraurbane non pavimentate

Concordo.
Dalle mie parti (alta padovana) fino a qualche anno fa molte vie non erano asfaltate ed avevano un fondo sterrato/ghiaino. In seguito molte sono state asfaltate ma alcune sono rimaste unpaved. Per me quelle sono residential con la specifica surface=gravel. Altre strade sterrate, senza nome e periferiche che portano a poche case sparse ma soprattutto a campi le classificherei come track (anche se collegano località).

Quoto Alberto, sarebbe importante che la mappa visualizzasse in modo differente strade asfaltate e strade non asfaltate:

Mi sembra importante comunque differenziarle dalle asfaltate, altrimenti
si finisce a visualizzarle come fa Google dove sembrano ottime e comode
strade anche dei tratturi erbosi tra i campi, solo perchè hanno un nome
Giovanni Fasano
2009-05-16 19:53:45 UTC
Permalink
Post by Cristian Testa
Concordo. Se sono effettivamente strade che portino a zone residenziali
con villette o simili, è corretto che vengano taggate come residential
specificandone il tipo di fondo. Ciò però per me non vuol dire che le
suddette villette siano a km di distanza ma nelle immediate vicinanze del
centro abitato.
Per quelle che vanno in mezzo ai campi (anche come prosecuzione delle
suddette residential) anche per me il tag track è il più indicato.
Dovremmo forse solo raggiungere un punto di vista comune sull'assegnazione dei grade.
Io invece non sono d'accordo, sarà perchè abito in una di queste vie.
Il fondo è di ghiaia, è a un paio di km dalla città più vicina ma serve in
pratica solo per l'accesso alle case (ci passerà un trattore al mese se è
tanto).
Per me la distinzione la fa l'utilizzo, non il fondo.

Attualmente sarei orientato a mappare secondo questi criteri:

In città:
- strada che serve esclusivamente delle case, tipicamente senza uscita o
comunque non utilizzabile per andare in altri posti: residential
- strada che permette altre destinazioni oltre alle case che si affacciano
sulla stessa, ma che non ospita normalmente traffico di transito:
unclassified
- strada che ospita principalmente traffico di transito: tertiary o
superiore se è un arteria più importante che attraversa il centro abitato.

Fuori città:
- strada che serve delle case, in cui il traffico è principalmente
automobilistico: unclassified
- strada che serve solo per l'accesso a fondi agricoli: track

Il fondo non è a mio avviso assolutamente importante per questa
classificazione e va comunque riportato nel tag apposito (soprattutto per
le strade di transito, in quelle senza uscita fa poca differenza).

Ciao Gio.
Martin Koppenhoefer
2009-05-17 02:47:55 UTC
Permalink
Post by Giovanni Fasano
Io invece non sono d'accordo, sarà perchè abito in una di queste vie.
Il fondo è di ghiaia, è a un paio di km dalla città più vicina ma serve in
pratica solo per l'accesso alle case (ci passerà un trattore al mese se è
tanto).
Per me la distinzione la fa l'utilizzo, non il fondo.
+1
Post by Giovanni Fasano
- strada che serve esclusivamente delle case, tipicamente senza uscita o
comunque non utilizzabile per andare in altri posti: residential
+1, quando sono proprietà privata alle volte anche service
Post by Giovanni Fasano
- strada che permette altre destinazioni oltre alle case che si affacciano
unclassified
+1
Post by Giovanni Fasano
- strada che ospita principalmente traffico di transito: tertiary o
superiore se è un arteria più importante che attraversa il centro abitato.
+1
Post by Giovanni Fasano
- strada che serve delle case, in cui il traffico è principalmente
automobilistico: unclassified
+1
Post by Giovanni Fasano
- strada che serve solo per l'accesso a fondi agricoli: track
+1 agricoli o simili (foresta, montagna, ecc.)

d'accordo con tutto

ciao,
Martin
Paolo Monegato
2009-05-17 20:38:11 UTC
Permalink
Post by Giovanni Fasano
Post by Cristian Testa
Concordo. Se sono effettivamente strade che portino a zone residenziali
con villette o simili, è corretto che vengano taggate come residential
specificandone il tipo di fondo. Ciò però per me non vuol dire che le
suddette villette siano a km di distanza ma nelle immediate vicinanze del
centro abitato.
Per quelle che vanno in mezzo ai campi (anche come prosecuzione delle
suddette residential) anche per me il tag track è il più indicato.
Dovremmo forse solo raggiungere un punto di vista comune sull'assegnazione dei grade.
Io invece non sono d'accordo, sarà perchè abito in una di queste vie.
Il fondo è di ghiaia, è a un paio di km dalla città più vicina ma serve in
pratica solo per l'accesso alle case (ci passerà un trattore al mese se è
tanto).
Dipende da quante case ci sono. Comunque lascerei libero il mappatore di
decidere.
Post by Giovanni Fasano
Per me la distinzione la fa l'utilizzo, non il fondo.
e su questo siamo d'accordo.

Ciao
Paolo
alberto
2009-05-18 08:56:21 UTC
Permalink
Anche se sono d' accordo col principio che la classificazione delle
strade la fa l' utilizzo e non il tipo di fondo stradale e che sarebbe
auspicabile differenziare sul rendering strade della stessa
classificazione ma con fondo stradale differente, credo che allo stato
attuale del rendering questo modo di vedere le cose porti in pratica a
non apprezzare sulla mappa un parametro importante della strada, cioè la
sua percorribilità.
Se ho due strade, parlo sempre di strade di campagna non importanti, che
funzionalmente sono unclassified e quindi le taggo ambedue in quel modo,
ma una è asfaltata e l' altra è ghiaiata ma magari con buche che dopo
piovuto hanno un palmo d' acqua, perchè non dovrei apprezzare sulla
mappa questo stato di cose?
Il rendering non farebbe differenza, ed io darei una informazione
sbagliata dichiarandole ambedue percorribili allo stesso modo.
Una mappa mi serve per organizzare un percorso, devo potere avere
informazioni in tal senso.
Mi direte che guardo troppo al risultato visivo della mappa, ma alla
fine è quello che poi serve a chi la usa.
Ora come ora abbiamo a disposizione una gamma di tipologie di strade
renderizzate in un certo modo, dall' autostrada alla "track", nulla mi
dice che in futuro avrò a disposizione altre varianti grafiche che
tengano conto del fondo stradale.
Ciao

Alberto
Elena of Valhalla
2009-05-18 09:00:59 UTC
Permalink
Post by alberto
Anche se sono d' accordo col principio che la classificazione delle
strade la fa l' utilizzo e non il tipo di fondo stradale e che sarebbe
auspicabile differenziare sul rendering strade della stessa
classificazione ma con fondo stradale differente, [snippone galattico]
sono d'accordo, ma la soluzione e` richiedere una modifica del
rendering che tenga conto dei valori noti di surface
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Carlo Stemberger
2009-05-18 09:36:59 UTC
Permalink
Post by Elena of Valhalla
Post by alberto
Anche se sono d' accordo col principio che la classificazione delle
strade la fa l' utilizzo e non il tipo di fondo stradale e che sarebbe
auspicabile differenziare sul rendering strade della stessa
classificazione ma con fondo stradale differente, [snippone galattico]
sono d'accordo, ma la soluzione e` richiedere una modifica del
rendering che tenga conto dei valori noti di surface
Esatto. E invito a farlo.

Se l'errore sta nel rendering (e nessuno lo nega), il problema non va
aggirato malamente, ma affrontato.
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Federico Cozzi
2009-05-18 09:37:04 UTC
Permalink
Post by Elena of Valhalla
sono d'accordo, ma la soluzione e` richiedere una modifica del
rendering che tenga conto dei valori noti di surface
E qui si ritorna alla mia critica del tag surface... è un minestrone
incomprensibile.
Sarei quasi per introdurre un altro tag, paved, che possa valere solo
paved=yes
paved=no
Faccio la rivoluzione? ;-)

Ciao
alberto
2009-05-18 09:51:29 UTC
Permalink
Post by Federico Cozzi
E qui si ritorna alla mia critica del tag surface... è un minestrone
incomprensibile.
Sarei quasi per introdurre un altro tag, paved, che possa valere solo
paved=yes
paved=no
Faccio la rivoluzione? ;-)
Ciao
Il tag "track" ha tutta una serie di varianti grafiche per i vari gradi
che ne indicano la percorribilità, paved=no non è così preciso....
Federico Cozzi
2009-05-18 10:02:54 UTC
Permalink
Il tag "track" ha tutta una serie di varianti grafiche per  i vari gradi
che ne indicano la percorribilità, paved=no non è così preciso....
Ma il tracktype ha comunque una scala ben definita di valori: l'utente
del tag (umano o software) può comunque capire che tt3 è intermedio
tra tt2 e tt4.
Viceversa se un router vuole "evitare le strade non asfaltate" (come
ad esempio i navigatori Garmin permettono) perché hai una macchina
sportiva o una bicicletta da corsa, non riesce assolutamente a capire
se "inserisci il nome di surface più assurdo qui" è da considerarsi
paved o unpaved.

Cerco di spiegarmi meglio: non sto sostenendo che il tag surface sia
inutile. Può servire ad un navigatore eccezionalmente intelligente e
programmabile dall'utente, che gli dice "per me è accettabile il
macadam, non è accettabile il gravel".

Ma alla stragrande maggioranza dei navigatori esistenti (e, mi azzardo
a sostenere, anche futuri) serve una classificazione "interpretata"
della realtà: è paved oppure no?
Quindi ritengo che, accanto a surface=TheCraziestSurfaceManCanInvent,
ci vorrebbe anche un più semplice e impreciso paved=yes/no

Ciao
Carlo Stemberger
2009-05-18 10:09:17 UTC
Permalink
Post by Federico Cozzi
Cerco di spiegarmi meglio: non sto sostenendo che il tag surface sia
inutile. Può servire ad un navigatore eccezionalmente intelligente e
programmabile dall'utente, che gli dice "per me è accettabile il
macadam, non è accettabile il gravel".
Ma alla stragrande maggioranza dei navigatori esistenti (e, mi azzardo
a sostenere, anche futuri) serve una classificazione "interpretata"
della realtà: è paved oppure no?
Quindi ritengo che, accanto a surface=TheCraziestSurfaceManCanInvent,
ci vorrebbe anche un più semplice e impreciso paved=yes/no
Bello! Mi piace assai!!!

+1
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Federico Cozzi
2009-05-18 10:12:19 UTC
Permalink
Post by Federico Cozzi
Ma alla stragrande maggioranza dei navigatori esistenti (e, mi azzardo
a sostenere, anche futuri) serve una classificazione "interpretata"
della realtà: è paved oppure no?
Quindi ritengo che, accanto a surface=TheCraziestSurfaceManCanInvent,
ci vorrebbe anche un più semplice e impreciso paved=yes/no
Provo a spiegare meglio il concetto di "descrivere la realtà" vs
"interpretare la realtà a beneficio dei fruitori della mappa".

Supponiamo che una ditta cinese inventi una nuova mescola di asfalto,
che è migliore dell'asfalto (maggiore scorrevolezza, maggiore durata
ecc.) ed è funzionalmente identica (cioè ci posso andare in auto con
la stessa cura con cui vado sull'asfalto).
Supponiamo anche che questa ditta, essendo cinese, usi un nome cinese
per il suo prodotto.
Supponiamo ora che un mapper cinese mappi una strada cinese in cui è
stata usata questa mescola e, giustamente, scriva
surface=NomeDellaMescolaInCineseEScrittoInIdeogrammi (dopotutto OSM è
Unicode)

Questa informazione "descrive la realtà" con una precisione indiscutibile.
Eppure questa informazione è inutile ad una buona percentuale di
utenti di OSM, e anche per gli utenti cinesi non aggiunge molto valore
rispetto ad un impreciso surface=paved.

Questo è un caso in cui la "descrizione della realtà", senza
l'interpretazione del cartografo, rende pressoché inutile la
mappatura.

Dopotutto lo scopo di OSM è quello di produrre una mappa "stradale"
del mondo, non certo di sostituirsi ai piani regolatori dei vari enti
locali (che possono ben censire con estrema precisione la qualità del
fondo stradale).

Insomma secondo me un cartografo è per prima cosa un interprete della
realtà e, quando abdica a questo ruolo in nome della "descrizione
fedele", viene meno ai suoi compiti nei confronti dell'utente finale.

Ciao
Elena of Valhalla
2009-05-18 10:15:57 UTC
Permalink
Post by Federico Cozzi
Ma alla stragrande maggioranza dei navigatori esistenti (e, mi azzardo
a sostenere, anche futuri) serve una classificazione "interpretata"
della realtà: è paved oppure no?
Quindi ritengo che, accanto a surface=TheCraziestSurfaceManCanInvent,
ci vorrebbe anche un più semplice e impreciso paved=yes/no
se non ricordo male c'era una proposta che parlava di smoothness e
potrebbe essere appropriata, ma credo che non si sia mai raggiunto il
consenso su come misurarla
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Carlo Stemberger
2009-05-18 10:23:43 UTC
Permalink
Post by Elena of Valhalla
se non ricordo male c'era una proposta che parlava di smoothness e
potrebbe essere appropriata, ma credo che non si sia mai raggiunto il
consenso su come misurarla
No, no, io appoggio pienamente il grezzo

paved=yes/no

eventualmente associabile a tutti i tag che si vogliono (surface,
smoothness, quel_che_si_vuole).


Da iniziare ad usare fin da subito!

Ovviamente bisognerebbe stabilire che valore è sottinteso (implies) nei
vari casi.

Io direi

highway=* ---> paved=yes (quindi va solo indicato paved=no,
eventualmente)
highway=track ---> paved=no (quindi va solo indicato paved=yes,
eventualmente)


Cosa ne dite?
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Carlo Stemberger
2009-05-18 10:31:23 UTC
Permalink
Post by Carlo Stemberger
Ovviamente bisognerebbe stabilire che valore è sottinteso (implies)
nei vari casi.
Aggiungo: per fare un lavoro sopraffino si potrebbero stabilire i valori
di paved (yes/no) per ogni tipo di surface, così non c'è bisogno di
aggiungere alcun tag in tutte le strade che presentano la chiave
surface, se questa è recensita.

Es:

---
Tag surface implies tag paved
---
gravel no
cobblestone yes
sand no
asphalt yes
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Federico Cozzi
2009-05-18 10:48:51 UTC
Permalink
highway=*  ---> paved=yes   (quindi va solo indicato paved=no,
eventualmente)
highway=track ---> paved=no  (quindi va solo indicato paved=yes,
eventualmente)
Indiscutibile.

Rimane il dubbio su footway, bridleway e cycleway.
-Per footway e bridleway l'indicazione grezza paved vs unpaved è
pressoché inutile (grezzamente, paved e unpaved sono identici per chi
cammina; se vuoi invece fare il fine, devi davvero ricorrere al tag
surface)
-Nelle cycleway invece l'indicazione è utilissima: forse è sensato
usare paved=yes come default, ma è uno dei casi in cui sarebbe meglio
taggare esplicitamente tutte le way.

Ciao
Carlo Stemberger
2009-05-18 10:53:41 UTC
Permalink
Post by Federico Cozzi
Rimane il dubbio su footway, bridleway e cycleway.
-Per footway e bridleway l'indicazione grezza paved vs unpaved è
pressoché inutile (grezzamente, paved e unpaved sono identici per chi
cammina; se vuoi invece fare il fine, devi davvero ricorrere al tag
surface)
No: prova a dire ad una ragazza coi tacchi a spillo di passare per un
sentiero sterrato dopo una pioggia...

Paved=yes/no è utile anche in questo caso (sì per autobloccanti,
asfalto, ecc., no per sterrato, ghiaia, ecc.)
Post by Federico Cozzi
-Nelle cycleway invece l'indicazione è utilissima: forse è sensato
usare paved=yes come default, ma è uno dei casi in cui sarebbe meglio
taggare esplicitamente tutte le way.
Però mettere un default secondo me non è sbagliato: bisogna verificare
qual è il caso più comune e scegliere di conseguenza.

Secondo me l'assenza di un default è da lasciare unicamente nel caso in
cui 2 o più casi si presentino circa con la stessa frequenza.


Ciao!
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Daniele Forsi
2009-05-18 11:02:36 UTC
Permalink
Post by Carlo Stemberger
Però mettere un default secondo me non è sbagliato: bisogna verificare
qual è il caso più comune e scegliere di conseguenza.
però con un default implicito e due soli valori yes/no non si può
indicare il caso in cui non si conosca il tipo di superficie, il che
sarebbe utile per pianificare un survey

aggiugnere un terzo valore esplicito, ad esempio paved=yes|no|unknown
però ha dei problemi:
* ci allontana dall'eleganza della proposta originale e invita a una
proliferazione dei valori :-)
* "unknown" è più difficile da scrivere correttamente di yes/no :-)
--
Daniele Forsi
Carlo Stemberger
2009-05-18 11:20:29 UTC
Permalink
Post by Daniele Forsi
però con un default implicito e due soli valori yes/no non si può
indicare il caso in cui non si conosca il tipo di superficie, il che
sarebbe utile per pianificare un survey
Come si fa a non conoscere la superficie? Significa non conoscere il
territorio, ciò che si mappa ---> deprecato

Nel caso di mapping da foto satellitari, cartografia preesistente, ecc.
ecc. è implicito che si possano fare degli errori: si spera che qualcuno
poi correggerà.


Ciao!
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Federico Cozzi
2009-05-18 11:04:04 UTC
Permalink
Post by Carlo Stemberger
Post by Federico Cozzi
-Per footway e bridleway l'indicazione grezza paved vs unpaved è
pressoché inutile (grezzamente, paved e unpaved sono identici per chi
cammina; se vuoi invece fare il fine, devi davvero ricorrere al tag
surface)
No: prova a dire ad una ragazza coi tacchi a spillo di passare per un
sentiero sterrato dopo una pioggia...
Era esattamente quello che pensavo io quando dicevo "se vuoi fare il
fine devi ricorrere al tag surface".
Se il tuo problema sono i tacchi a spillo è chiaro che non basta paved
vs unpaved.
Cobblestone è peggio di macadam, e anche sul tipo di asfalto devi
essere preciso (è quello che si scioglie quando fa caldo oppure no?).
Ci sono le grate sul marciapiede?
Insomma in quei casi il semplice paved=yes/no è chiaro che non basta,
quindi è pressoché inutile un default: se hai scarpe normali le
superfici paved o unpaved sono equivalenti, se hai scarpe speciali la
distinzione non è fine a sufficienza.
Post by Carlo Stemberger
Però mettere un default secondo me non è sbagliato: bisogna verificare
qual è il caso più comune e scegliere di conseguenza.
Allora andiamo con il default paved=yes per le cycleway che in ogni
caso è il più comune.

Ciao
Carlo Stemberger
2009-05-18 11:10:37 UTC
Permalink
Post by Federico Cozzi
Era esattamente quello che pensavo io quando dicevo "se vuoi fare il
fine devi ricorrere al tag surface".
Se il tuo problema sono i tacchi a spillo è chiaro che non basta paved
vs unpaved.
Hai ragione. Ma l'assenza di un default si traduce nel mancato rendering
finché il tag non viene specificato. Io per questo metterei anche in
questo caso un "inutile" paved=yes come default. Se invece ritieni che
l'indicazione del tipo di superficie sia fondamentale, non metti il
default, il che si traduce nell'obbligo di aggiungere la chiave surface
(altrimenti niente rendering).
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Federico Cozzi
2009-05-18 10:44:23 UTC
Permalink
Post by Elena of Valhalla
se non ricordo male c'era una proposta che parlava di smoothness e
potrebbe essere appropriata, ma credo che non si sia mai raggiunto il
consenso su come misurarla
Spesso le proposte si incagliano quando sono troppo complesse...
Smoothness ha circa 10 valori, non numerici, e ricordarli è impossibile.

Ciao
Luca Delucchi
2009-05-18 12:03:34 UTC
Permalink
Post by Federico Cozzi
E qui si ritorna alla mia critica del tag surface... è un minestrone
incomprensibile.
Sarei quasi per introdurre un altro tag, paved, che possa valere solo
paved=yes
paved=no
Faccio la rivoluzione? ;-)
non fai la rivoluzione secondo me crei solo un doppione, surface
all'inizio era paved/unpaved e io continuo ad usare quella che è la
cosa migliore perchè un unpaved può essere terriccio con erba o erba
con ghiaia ecc ecc usare solo paved e unpaved mi sembra la cosa
migliore!
Post by Federico Cozzi
Ciao
ciao
Luca
Carlo Stemberger
2009-05-18 12:14:22 UTC
Permalink
Post by Luca Delucchi
all'inizio era paved/unpaved e io continuo ad usare quella che è la
cosa migliore perchè un unpaved può essere terriccio con erba o erba
con ghiaia ecc ecc usare solo paved e unpaved mi sembra la cosa
migliore!
No, non è un doppione: surface, secondo me giustamente, si è evoluto ed
è diventato molto raffinato, non è più quello che era in origine.
Secondo me oggi deve essere considerato come un tag opzionale, un
qualcosa in più che sicuramente migliora la ricchezza della mappa, ma
che non è certo prioritario.

Sostanzialmente secondo me la soluzione ideale è proprio quella indicata
da Federico: la creazione della nuova chiave "paved", con i valori di
default preimpostati; quindi la chiave funziona automaticamente anche
senza indicarla, così router e render sono a posto.

A questo punto i tag surface=paved e surface=unpaved devono venire
abrogati, non avendo più alcun senso.

Mi sembra pulitissimo e non vedo controindicazioni.
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Luca Delucchi
2009-05-18 12:24:43 UTC
Permalink
Post by Carlo Stemberger
Post by Luca Delucchi
all'inizio era paved/unpaved e io continuo ad usare quella che è la
cosa migliore perchè un unpaved può essere terriccio con erba o erba
con ghiaia ecc ecc usare solo paved e unpaved mi sembra la cosa
migliore!
No, non è un doppione: surface, secondo me giustamente, si è evoluto ed
è diventato molto raffinato, non è più quello che era in origine.
Secondo me oggi deve essere considerato come un tag opzionale, un
qualcosa in più che sicuramente migliora la ricchezza della mappa, ma
che non è certo prioritario.
Sostanzialmente secondo me la soluzione ideale è proprio quella indicata
da Federico: la creazione della nuova chiave "paved", con i valori di
default preimpostati; quindi la chiave funziona automaticamente anche
senza indicarla, così router e render sono a posto.
A questo punto i tag surface=paved e surface=unpaved devono venire
abrogati, non avendo più alcun senso.
Mi sembra pulitissimo e non vedo controindicazioni.
io continuo ad essere dell'idea che sia un doppione, per il rendering
basta fare un filtro con surface=paved e un'altro con surface!=paved
ed ecco risolto il problema rendering!

ciao
luca
Elena of Valhalla
2009-05-18 12:29:39 UTC
Permalink
Post by Luca Delucchi
io continuo ad essere dell'idea che sia un doppione, per il rendering
basta fare un filtro con surface=paved e un'altro con surface!=paved
ed ecco risolto il problema rendering!
il problema e` con i valori di surface tipo cobblestones, che
probabilmente sarebbero da considerare come paved, ma non sono
presenti in nessun elenco facilmente individuabile
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Carlo Stemberger
2009-05-18 12:30:18 UTC
Permalink
Post by Luca Delucchi
basta fare un filtro con surface=paved e un'altro con surface!=paved
ed ecco risolto il problema rendering!
?

Spiega un po' meglio, sinceramente non ho capito. Come fai a decidere se
un tipo di fondo è paved o unpaved? E se quel fondo è nuovo e non è mai
stato inserito da nessun altro?

Secondo me è bene proprio fare una mappatura a vari "livelli" di
accuratezza: una prima mappatura in cui si disegna il grafo più i tag
essenziali (vengono usati i valori di default), una seconda passata in
cui si aggiungono dei tag magari un po' grossolani ma utili (paved=no
dove c'è uno sterrato, ad esempio) e poi via via si va a contare il
numero dei fili d'erba presenti in un prato.
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Luca Delucchi
2009-05-18 12:35:54 UTC
Permalink
Post by Carlo Stemberger
Spiega un po' meglio, sinceramente non ho capito. Come fai a decidere se
un tipo di fondo è paved o unpaved? E se quel fondo è nuovo e non è mai
stato inserito da nessun altro?
con mapnik ci sono i filtri e nei filtri puoi mettere un po' quello
che ti pare perciò puoi fare un filtro sui tipi di strada perciò
mettere surface=paved and surface=cobblestone (così rispondo anche ad
elena) e dargli uno stile poi in un altro mettere surface!=paved and
surface!=cobblestone e mettergli un altro stile o magari lasciare
quelli asfaltati normali e mettere agli strerrati un qualcosa tipo
spiaggia con tutti i puntini
Post by Carlo Stemberger
Secondo me è bene proprio fare una mappatura a vari "livelli" di
accuratezza: una prima mappatura in cui si disegna il grafo più i tag
essenziali (vengono usati i valori di default), una seconda passata in
cui si aggiungono dei tag magari un po' grossolani ma utili (paved=no
dove c'è uno sterrato, ad esempio) e poi via via si va a contare il
numero dei fili d'erba presenti in un prato.
questo è possibile con i maxscaledenom e minscaledenom e i filtri spiegati sopra

ciao
Luca
Carlo Stemberger
2009-05-18 12:45:16 UTC
Permalink
Post by Luca Delucchi
con mapnik ci sono i filtri e nei filtri puoi mettere un po' quello
che ti pare perciò puoi fare un filtro sui tipi di strada perciò
mettere surface=paved and surface=cobblestone (così rispondo anche ad
elena) e dargli uno stile poi in un altro mettere surface!=paved and
surface!=cobblestone e mettergli un altro stile o magari lasciare
quelli asfaltati normali e mettere agli strerrati un qualcosa tipo
spiaggia con tutti i puntini
Sì, ma se io arrivo e metto, chessò, surface=$(english for "ciottoli di
terracotta"), un software come fa a dire se è paved o unpaved? Il povero
garmin come ne esce fuori?

L'umano sa che è unpaved, anche se non è scritto da nessuna parte (wiki,
ecc.), quindi con l'introduzione della nuova chiave mi basterebbe mettere

paved=no
surface=$(english_for "ciottoli di terracotta")

e sarebbero contenti tutti. Non credo che sia possibile mettere due
valori alla stessa chiave, quindi non è possibile mettere

surface=paved
surface=$(english_for "ciottoli di terracotta")

dunque a mio avviso non si tratta di un doppione.
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Luca Delucchi
2009-05-18 12:52:19 UTC
Permalink
Post by Carlo Stemberger
Sì, ma se io arrivo e metto, chessò, surface=$(english for "ciottoli di
terracotta"), un software come fa a dire se è paved o unpaved? Il povero
garmin come ne esce fuori?
affari tuoi! come usare bar, newsagent ecc ecc quel rendering non
terrà conto di quel tag, se per te è così importante fai un rendering
ad hoc
Post by Carlo Stemberger
dunque a mio avviso non si tratta di un doppione.
non posso importi di pensarla come me, proponetelo e poi si vede, io
voterò contrario :-P

ciao
Luca
Carlo Stemberger
2009-05-18 12:57:48 UTC
Permalink
Post by Luca Delucchi
non posso importi di pensarla come me, proponetelo e poi si vede, io
voterò contrario :-P
Giusto.

Forza Federico! Proponi, hai già il mio voto.


Ciao!

Carlo
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Carlo Stemberger
2009-05-18 12:45:27 UTC
Permalink
Post by Luca Delucchi
con mapnik ci sono i filtri e nei filtri puoi mettere un po' quello
che ti pare perciò puoi fare un filtro sui tipi di strada perciò
mettere surface=paved and surface=cobblestone (così rispondo anche ad
elena) e dargli uno stile poi in un altro mettere surface!=paved and
surface!=cobblestone e mettergli un altro stile o magari lasciare
quelli asfaltati normali e mettere agli strerrati un qualcosa tipo
spiaggia con tutti i puntini
Sì, ma se io arrivo e metto, chessò, surface=$(english for "ciottoli di
terracotta"), un software come fa a dire se è paved o unpaved? Il povero
garmin come ne esce fuori?

L'umano sa che è unpaved, anche se non è scritto da nessuna parte (wiki,
ecc.), quindi con l'introduzione della nuova chiave mi basterebbe mettere

paved=no
surface=$(english_for "ciottoli di terracotta")

e sarebbero contenti tutti. Non credo che sia possibile mettere due
valori alla stessa chiave, quindi non è possibile mettere

surface=unpaved
surface=$(english_for "ciottoli di terracotta")

dunque a mio avviso non si tratta di un doppione.
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Elena of Valhalla
2009-05-18 12:51:17 UTC
Permalink
Post by Luca Delucchi
con mapnik ci sono i filtri e nei filtri puoi mettere un po' quello
che ti pare perciò puoi fare un filtro sui tipi di strada perciò
mettere surface=paved and surface=cobblestone (così rispondo anche ad
elena)
quello che manca perche' questo funzioni e` un elenco di tutti i
valori possibili ed immaginabili da considerarsi equivalenti a paved,
oltre al fatto che risulterebbe un filtro decisamente complicato
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Luca Delucchi
2009-05-18 12:54:18 UTC
Permalink
Post by Elena of Valhalla
quello che manca perche' questo funzioni e` un elenco di tutti i
valori possibili ed immaginabili da considerarsi equivalenti a paved,
oltre al fatto che risulterebbe un filtro decisamente complicato
io mi baserei su quello delle mapfeatures, non mi sembra così
complicato come filtro; ce ne sono di più complessi nel file xml di
OSM
Post by Elena of Valhalla
--
Elena ``of Valhalla''
ciao
Luca
Cristian Testa
2009-05-19 22:22:20 UTC
Permalink
Ciao a tutti.
Stavo rileggendo il thread sul tagging delle strade non pavimentate ho
maturato una considerazione più generale sul mapping delle strade:
dal wiki i tag primary, secondary, tertiary, ecc. compaiono tra le
caratteristiche fisiche delle strade, ma a quanto pare nell'assegnazione si
dà molto più peso a quella che è la classificazione del legislatore o la
destinazione d'uso piuttosto che sulla conformazione fisica vera e propria.
Si lascia poi a chi traccia la strada la possibilità "degradare" un percorso
in presenza di condizioni particolari (ad esempio una strada provinciale
molto stretta che venga degradata a tertiary).
Ciò a mio giudizio, se da una parte contribuisce ad avere una mappa simile a
quelle commerciali, dall'altra snatura in parte il senso di una "mappa
globale".
Mi spiego meglio: la prima cosa che personalmente mi aspetto quando guardo
una mappa è quella di apprezzare la "fisicità" del luogo, la dimensione
delle strade ed il loro grado di percorribilità, le difficoltà di percorso,
insomma, che potrei incontrare per andare dal posto A al posto B. Il fatto
che per farlo io debba passare sulla SS287 o la E23 o la XYX99B dal mio
punto di vista è un aspetto secondario, legato esclusivamente alla
denominazione delle strade in quel luogo.
Quello che intendo dire è che la mappatura di base andrebbe effettuata sui
parametri fisici della strada definendone il tipo in base a questi ed
aggiungere successivamente i parametri "logici" legati alla classificazione
stabilita dal legislatore in quel posto. So che esiste ad esempio il
parametro est_width per definire la larghezza di una strada, ma mi sembra
nella maggioranza dei casi di fatto inapplicabile e lasciato all'occhio di
chi mappa.
Chiunque invece è in grado di stabilire se la tipologia di una strada è
A,B,C o D se deve farlo valutando parametri fisici oggettivi immediatamente
visibili come ad esempio il numero di corsie, se le corsie sono larghe o
strette, se è presente una mezzeria, se la strada è asfaltata, ecc.. Allo
stesso modo chiunque sarebbe in grado di assegnare il corretto livello di
importanza guardando la denominazione della stessa su un cartello stradale.
Sarà poi compito del renderer disegnare una strada larga, stretta, a tratto
continuo o tratteggiata in funzione dei parametri fisici della stessa e
magari variarne il colore in funzione della classificazione legale o della
destinazione d'uso, ottenendo una mappa ibrida che tenga in considerazione
tutti i parametri. O scegliere esclusivamente quella logica o fisica
variando la larghezza delle strade in funzione degli uni o gli altri
parametri.
Otterrei due grossi vantaggi: potrei apprezzare immediatamente quali strade
mi troverò davanti e l'importanza che queste hanno nelle comunicazioni del
luogo (ad esempio potrei vedere che tra due paesini hanno costruito una
strada a 4 corsie che ha però lo scopo di una tertiary, o che in alcune
zone una strada non asfaltata in mezzo al nulla è l'unica via di
comunicazione tra due grandi città e ha importanza di primary) e toglierei
completamente di mezzo il giudizio soggettivo di chi effettua la mappatura
di una certa zona.
Non so voi cosa ne pensate ma mi piacerebbe avere un vostro giudizio in
merito.
Ciao

Cristian
Federico Cozzi
2009-05-19 23:21:16 UTC
Permalink
Post by Cristian Testa
Stavo rileggendo il thread sul tagging delle strade non pavimentate ho
dal wiki i tag primary, secondary, tertiary, ecc. compaiono tra le
caratteristiche fisiche delle strade, ma a quanto pare nell'assegnazione si
dà molto più peso a quella che è la classificazione del legislatore o la
destinazione d'uso piuttosto che sulla conformazione fisica vera e propria.
Non sono d'accordo.

Decenni di mappe stradali "cartacee" hanno mostrato la necessità di
classificare le strade secondo un criterio di importanza (dalle più
importanti alle meno importanti). Questa gerarchia svolge in un colpo
solo questi ruoli:
1. assegna un diverso stile grafico al render (strade più importanti
sono più evidenti di strade meno importanti)
2. decide a quali scale deve essere disegnata ciascuna strada
3. permette di pianificare un percorso.
Come dicevo prima, in tutte le mappe cartacee questi tre bisogni (e
probabilmente me ne sono perso qualcuno), del tutto indipendenti tra
di loro, sono soddisfatti da un'unica gerarchia.
A questo punto qualsiasi cartografo deve decidere sulla base di quale
criterio assegnare la classificazione alle strade, ma comunque non
riesce a sfuggire al concetto di gerarchia.

Quello che tu sostieni è che la gerarchia non debba esistere nella
cartina prodotta dal cartografo, ma solo nella visione che della
cartina ne ha l'utente. Cioè tu sostieni che la gerarchia, che è un
criterio indiscutibilmente soggettivo, debba essere abbandonata e
sostituita da vari criteri oggettivi:
1. larghezza della carreggiata
2. numero di corsie
3. tipo di fondo

Questo approccio secondo me ha due controindicazioni:

A. la determinazione dei criteri oggettivi è un lavoro lungo e
necessariamente incompleto: nel tuo elenco ad esempio non accenni al
numero di veicoli/giorno che transitano sulla strada (e che è un
parametro molto importante per un urbanista!). Inoltre molti criteri
oggettivi saranno necessariamente misurati in maniera soggettiva
(potrai davvero contare quanti veicoli transitano al giorno? qual è la
scala della "qualità" del fondo stradale?) e quindi il miraggio
dell'oggettività rimarrà tale, perché necessariamente verrà introdotta
una dose di soggettività.

B. come ho già detto in un'altra mail (ho il difetto di ripetermi
spesso ;-) secondo me il cartografo non "descrive" la realtà, ma la
"interpreta". Cioè non si limita a riprodurre in maniera oggettiva la
realtà (anche se in scala ridotta), ma la modifica in modo da renderla
più fruibile all'utente. Per questo motivo secondo me non ha senso
parlare de "La Mappa Universale", perché una (buona) mappa contiene al
suo interno anche il fine per cui è stata progettata. Paradossalmente
una mappa è tanto più chiara tanto più il cartografo *elimina* i dati
inutili.

Cito Borges che è molto più bravo di me :-)

"In quell’impero, l’Arte della Cartografia raggiunse tale perfezione
che la mappa d’una sola provincia occupava tutta una città, e la mappa
dell’Impero, tutta una provincia.
Col tempo, codeste mappe smisurate non soddisfecero e i Collegi dei
Cartografi eressero una mappa dell’Impero, che uguagliava in grandezza
l’Impero e coincideva puntualmente con esso.
Meno dedite allo studio della cartografia, le generazioni successive
compresero che quella vasta mappa era inutile e non senza empietà la
abbandonarono alle inclemenze del sole e degl’inverni.
Nei deserti dell’Ovest rimangono lacere rovine della mappa, abitate da
animali e mendichi; in tutto il paese non è altra reliquia delle
discipline geografiche."

Ciao,
Federico
Martin Koppenhoefer
2009-05-20 02:06:20 UTC
Permalink
Post by Federico Cozzi
Come dicevo prima, in tutte le mappe cartacee questi tre bisogni (e
probabilmente me ne sono perso qualcuno), del tutto indipendenti tra
di loro, sono soddisfatti da un'unica gerarchia.
A questo punto qualsiasi cartografo deve decidere sulla base di quale
criterio assegnare la classificazione alle strade, ma comunque non
riesce a sfuggire al concetto di gerarchia.
+1
Post by Federico Cozzi
Quello che tu sostieni è che la gerarchia non debba esistere nella
cartina prodotta dal cartografo, ma solo nella visione che della
cartina ne ha l'utente. Cioè tu sostieni che la gerarchia, che è un
criterio indiscutibilmente soggettivo, debba essere abbandonata e
1. larghezza della carreggiata
2. numero di corsie
3. tipo di fondo
A. la determinazione dei criteri oggettivi è un lavoro lungo e
necessariamente incompleto: nel tuo elenco ad esempio non accenni al
numero di veicoli/giorno che transitano sulla strada (e che è un
parametro molto importante per un urbanista!).
+1
Post by Federico Cozzi
Inoltre molti criteri
oggettivi saranno necessariamente misurati in maniera soggettiva
+1
Post by Federico Cozzi
B. secondo me il cartografo non "descrive" la realtà, ma la
"interpreta". Cioè non si limita a riprodurre in maniera oggettiva la
realtà (anche se in scala ridotta), ma la modifica in modo da renderla
più fruibile all'utente. Per questo motivo secondo me non ha senso
parlare de "La Mappa Universale", perché una (buona) mappa contiene al
suo interno anche il fine per cui è stata progettata. Paradossalmente
una mappa è tanto più chiara tanto più il cartografo *elimina* i dati
inutili.
si, pero noi non siamo facendo "una mappa" ma un geodatabase aperto,
che permette di creare varie mappe, il cartografo OSM invece è quello
che renderizza una mappa con questi dati. Lui è la persona chi
generalizza e seleziona.

Martin
Federico Cozzi
2009-05-20 07:55:45 UTC
Permalink
Post by Martin Koppenhoefer
Post by Federico Cozzi
B. secondo me il cartografo non "descrive" la realtà, ma la
"interpreta". Cioè non si limita a riprodurre in maniera oggettiva la
realtà (anche se in scala ridotta), ma la modifica in modo da renderla
più fruibile all'utente. Per questo motivo secondo me non ha senso
parlare de "La Mappa Universale", perché una (buona) mappa contiene al
suo interno anche il fine per cui è stata progettata. Paradossalmente
una mappa è tanto più chiara tanto più il cartografo *elimina* i dati
inutili.
si, pero noi non siamo facendo "una mappa" ma un geodatabase aperto,
che permette di creare varie mappe, il cartografo OSM invece è quello
che renderizza una mappa con questi dati. Lui è la persona chi
generalizza e seleziona.
Vorrei sfatare questo mito, o per lo meno sostenere che è irraggiungibile.
L'idea che OSM possa contenere "tutto" e che poi l'utente estragga le
informazioni che gli servono è bella ma impossibile.

Noi cartografi OSM, quando carichiamo dati nel geodatabase, facciamo
delle scelte irreversibili che non permettono l'estrazione di
"qualsiasi" mappa:
1. mappiamo la mezzeria delle strade e non i marciapiedi: va bene se
vuoi estrarre una mappa 1:25000, inizia a scricchiolare se vuoi una
mappa 1:10000 ed è insufficiente se vuoi una mappa 1:2000
2. quali edifici mappiamo? (building=yes) So che qualcuno risponderà
"tutti" ma questo ha senso se si vuole una mappa 1:2000. Se invece si
vuole una mappa 1:50000 bisogna mostrare solo gli edifici
significativi (attualmente il tag building non è così raffinato)
3. con che criterio mappiamo il landuse? In aperta campagna, in una
zona totalmente agricola, metto un solo poligono landuse=farm oppure
mappo ogni singolo campo e lascio scoperte le zone di passaggio tra i
campi/i fossi/i filari/i muretti?
4. con quale precisione mappo le way? In una pista ciclopedonale (bici
+ pedoni) a corsie separate (cartello blu con la barra di separazione
tra bici e pedoni) traccio due way (una ciclabile, l'altra pedonale)
oppure ne metto una sola (highway=cycleway, foot=designated,
segregated=yes=?
5. con che precisione traccio la linea costiera? (Mandelbrot si
chiese: "quanto è lunga la costa della Gran Bretagna?" e nacque la
geometria frattale)
6. ecc.

Volente o nolente, qualsiasi inserimento di dati in un geobase è
inevitabilmente una semplificazione della realtà che è accettabile
solo avendo ipotizzato un uso futuro della carta per il quale quella
semplificazione è indifferente.

Si potrebbe risolvere osservando che la fruizione della carta sarà
limitata dalla precisione del sistema GPS, che è dell'ordine dei 5
metri, e quindi il nostro obiettivo potrebbe essere quello di produrre
un'ottima carta 1:2000 (non avrebbe senso produrre carte a scale
maggiori perché sarebbero infruibili). Dalla carta master 1:2000 uno o
più software otterrebbero carte a scala minore.
Obietto che anche questo è impossibile, non solo oggi con i software
un po' semplicistici che abbiamo, ma anche in futuro: i problemi
legati alla "semplificazione" in cartografia richiedono spesso
algoritmi NP-hard o anche peggio, cioè l'inesistenza di un software
che faccia una buona semplificazione non è dovuta a pigrizia dei
programmatori ma ad una impossibilità teorica (a meno che qualcuno non
dimostri che P=NP...)

Ciao
Cristian Testa
2009-05-20 10:35:59 UTC
Permalink
Come giustamente stai facendo notare, il concetto di approssimazione
accettabile è intrinseco in qualsiasi rapprensentazione ed acquisizione di
dati in funzione della precisione ottenibile durante le singole fasi: se il
mio gps riesce a darmi una posizione con un'approssimazione di 3m è ovvio
che neanche se piangessi in arabo riuscirei a definire una posizione con una
precisione superiore senza avvalermi di tecniche più sofisticate.
E su questo di do perfettamente ragione, come pure sul fatto che OSM non può
contenere il mondo millimetro per millimetro.
Come pure concordo con te che non si possa estrarre "qualsiasi mappa" ma
solo un sottoinsieme basato sui dati effettivamente presenti.
Non sono invece per niente d'accordo sul fatto che OSM inteso come
geodatabase debba già in partenza basarsi su una delle visualizzazioni
possibili.
Per cosa poi? Risparmiare un paio di parametri che aiuterebbero in una
migliore definizione della struttura fisica del territorio?
Quello che dico io, e torno a ripetermi, è che almeno nella fase di
introduzione dei dati relativi ad un certo posto venga separata la parte
"fisica" dalla parte "logica" delle strade. Nulla di più di
un'approssimazione accettabile nella rappresentazione della realtà che mi
dia un'informazione fisica slegata dalle intenzioni del legislatore di di
quella zona e che un renderer possa utilizzare per visualizzarla, non con
maggiore "precisione", ma con una maggiore somiglianza alla realtà.
E con il vantaggio, a mio giudizio, di non dover far troppo affidamento sul
buon senso di chi introduce i dati (e che molto probabilmente di cartografia
ne sa poco o nulla) nell'assegnazione di una definizione di una tipologia
ibrida tra logico e fisico.

Ciao
Cristian
----- Original Message -----
From: "Federico Cozzi" <f.cozzi-***@public.gmane.org>
To: <mk-eUCU/1tUcITYPTWX/***@public.gmane.org>; "openstreetmap list - italiano"
<talk-it-3+rWM/WnaLOn4i5uJCXUsti2O/***@public.gmane.org>
Sent: Wednesday, May 20, 2009 9:55 AM
Subject: Re: [Talk-it] Riflessioni sulla mappatura
Post by Federico Cozzi
Vorrei sfatare questo mito, o per lo meno sostenere che è irraggiungibile.
L'idea che OSM possa contenere "tutto" e che poi l'utente estragga le
informazioni che gli servono è bella ma impossibile.
Noi cartografi OSM, quando carichiamo dati nel geodatabase, facciamo
delle scelte irreversibili che non permettono l'estrazione di
... omissis....
Volente o nolente, qualsiasi inserimento di dati in un geobase è
inevitabilmente una semplificazione della realtà che è accettabile
solo avendo ipotizzato un uso futuro della carta per il quale quella
semplificazione è indifferente.
Si potrebbe risolvere osservando che la fruizione della carta sarà
limitata dalla precisione del sistema GPS, che è dell'ordine dei 5
metri, e quindi il nostro obiettivo potrebbe essere quello di produrre
un'ottima carta 1:2000 (non avrebbe senso produrre carte a scale
maggiori perché sarebbero infruibili). Dalla carta master 1:2000 uno o
più software otterrebbero carte a scala minore.
...
Federico Cozzi
2009-05-20 12:58:15 UTC
Permalink
Post by Cristian Testa
Non sono invece per niente d'accordo sul fatto che OSM inteso come
geodatabase debba già in partenza basarsi su una delle visualizzazioni
possibili.
Per cosa poi? Risparmiare un paio di parametri che aiuterebbero in una
migliore definizione della struttura fisica del territorio?
Provo a spiegarmi meglio.

OSM ti permette di introdurre tutti i parametri che vorresti
introdurre tu: width (est_width), lanes, maxspeed, smoothness, ecc.
Mancano i dati sulle mezzerie disegnate (perché nel resto del mondo di
solito non si risparmia sulla vernice per la segnaletica orizzontale)
ma non sarebbe impossibile aggiungerli.

Con il tuo approccio in ultima analisi taggheremmo così:
highway=road
lanes=2
smoothness=very_good
width=6
surface=paved
segnaletica_orizzontale=presente
classificazione_amministrativa=strada_provinciale

A questo punto dovremmo istituire uno o più sistemi di pesi che permettano a:
-render
-router
-convertitori di formato (OSM -> Garmin)
di:
-assegnare una vestizione
-decidere a che scala mostrare la strada
-assegnare una bontà di percorribilità
-assegnare una tipologia nel formato di destinazione (il formato
Garmin ha il concetto di gerarchia di strade)
ecc.

Questo "semplice" lavoro, cioè la istituzione dei sistemi di pesi,
sarebbe complicatissimo perché già adesso non riusciamo a concordare
se una strada urbana a scorrimento veloce debba essere taggata
tertiary, secondary o primary! (tutto questo senza considerare quanto
siano larghe le corsie o quale sia la qualità dell'asfalto)

In più, come dicevo, esistono alcuni parametri non fisici che
influiscono molto sulle caratteristiche di una strada. Non hai
contemplato il numero di veicoli al giorno che è importantissimo per
il routing (per alcune categorie di veicoli)
Post by Cristian Testa
Quello che dico io, e torno a ripetermi, è che almeno nella fase di
introduzione dei dati relativi ad un certo posto venga separata la parte
"fisica" dalla parte "logica" delle strade. Nulla di più di
Puoi già farlo: highway=foobar indica la parte logica.
Tutti gli altri tag (lanes, width, ecc.) indicano la parte fisica.
Post by Cristian Testa
un'approssimazione accettabile nella rappresentazione della realtà che mi
dia un'informazione fisica slegata dalle intenzioni del legislatore di di
Ma lo scopo di una cartina stradale non è dare un'informazione
*fisica* della realtà!
Per quella esistono le foto, anzi le ortofoto.
Una cartina stradale fornisce un'informazione "pre-masticata" della
realtà (dal cartografo) affinché la lettura sia più chiara.

Ti faccio un esempio: quando pianifichi un itinerario su Google Maps o
simili, usi il layer fotografico oppure il layer cartografico?
Post by Cristian Testa
maggiore "precisione", ma con una maggiore somiglianza alla realtà.
La somiglianza alla realtà è inutile in una cartina.

Ti faccio un altro esempio: nella OpenCycleMap i rilievi sono colorati
a seconda della loro altitudine, con uno sfumo che va dal verde al
marrone al bianco.
Ebbene questo sfumo è totalmente artificiale e non combacia
assolutamente né con la linea della vegetazione né con la linea delle
nevi.
Se tu volessi assomigliare alla realtà, dovresti calcolare le quote di
sfumo in modo che siano bianchi solo i rilievi innevati. Ma ritengo
che una carta del genere, oltre che essere un casino da realizzare,
non sarebbe più leggibile di quella attuale, anzi forse lo sarebbe
meno.
Post by Cristian Testa
E con il vantaggio, a mio giudizio, di non dover far troppo affidamento sul
buon senso di chi introduce i dati (e che molto probabilmente di cartografia
ne sa poco o nulla) nell'assegnazione di una definizione di una tipologia
ibrida tra logico e fisico.
Questa è utopia: nessun software, dati i parametri fisici della
strada, riesce a "capire" una strada meglio di chi conosce quella
strada dal vivo (il cartografo). Tu stai sostenendo, implicitamente,
che il lavoro del cartografo non sia affidabile e debba essere
affidato ad un algoritmo che, a partire da dati oggettivi, deduca
deterministicamente le caratteristiche di una strada.

Ma questo dipende da un milione di parametri fuori dal tuo controllo:
a. presenza di punti di interesse nei dintorni (una scuola elementare
genera traffico in determinate ore del giorno)
b. temporizzazione dei semafori
c. rete stradale, che fa sì che di due strade fisicamente equivalenti
una sia più trafficata di un'altra (perché il grafo è organizzato in
maniera tale da spingere il traffico da una parte e non da un'altra)

Secondo me funziona tutto meglio se ci si appoggia a pochi parametri,
intrinsecamente "riassuntivi" e soggettivi, come ad esempio il tag
highway.

Ciao,
Federico
Martin Koppenhoefer
2009-05-20 13:51:59 UTC
Permalink
Post by Federico Cozzi
segnaletica_orizzontale=presente
hm, presente? Probabilmente meglio continuo, interrotto, muro, ecc.
Avevo fatto la proposta di una relazione allo scopo di descrivere le
divisioni (solo sulla ML tedesca): l'idea è di mappare i way (ove
necessario) separatamente e poi unirli nel caso, dove sono uniti in
realtà (corsie). Per esempio mappare un marciapiede separatamente
dalla strada per poter indicare, dove il "bordstein" (non ho trovato
la parola italiana:
Loading Image...)
è abbassato, qual'è la divisione di due corsie separate
per es.
divider=grass
divider:width=0,5 (m)

oppure
divider=wall
divider:height=1

con questo sistema si potrebbe anche unire corsie paralleli, indicare
da dove a dove si po uscire dell'autostrada (lungo la corsia di
uscita).
Post by Federico Cozzi
classificazione_amministrativa=strada_provinciale
quello abbiamo di già e si chiama "ref"
Post by Federico Cozzi
-render
-router
-convertitori di formato (OSM -> Garmin)
-assegnare una vestizione
-decidere a che scala mostrare la strada
abbiamo: highway
Post by Federico Cozzi
-assegnare una bontà di percorribilità
secondo quale fattori? Con quale fonti?
Post by Federico Cozzi
-assegnare una tipologia nel formato di destinazione (il formato
Garmin ha il concetto di gerarchia di strade)
fa quello che fa le mappe (utente di mkgmap)
Post by Federico Cozzi
Questo "semplice" lavoro, cioè la istituzione dei sistemi di pesi,
sarebbe complicatissimo perché già adesso non riusciamo a concordare
se una strada urbana a scorrimento veloce debba essere taggata
tertiary, secondary o primary! (tutto questo senza considerare quanto
siano larghe le corsie o quale sia la qualità dell'asfalto)
perché secondome la qualità del asfalto o la larghezza della strada
non serve molto per qn. chi vuole andare da A a B: se la strada è
quella, si deve usare anche nel caso che l'asfalto è male.
Post by Federico Cozzi
In più, come dicevo, esistono alcuni parametri non fisici che
influiscono molto sulle caratteristiche di una strada. Non hai
contemplato il numero di veicoli al giorno che è importantissimo per
il routing (per alcune categorie di veicoli)
+1
Post by Federico Cozzi
Puoi già farlo: highway=foobar indica la parte logica.
Tutti gli altri tag (lanes, width, ecc.) indicano la parte fisica.
+1
Post by Federico Cozzi
Secondo me funziona tutto meglio se ci si appoggia a pochi parametri,
intrinsecamente "riassuntivi" e soggettivi, come ad esempio il tag
highway.
+1

Martin
Cristian Testa
2009-05-20 16:33:05 UTC
Permalink
Post by Federico Cozzi
OSM ti permette di introdurre tutti i parametri che vorresti
introdurre tu: width (est_width), lanes, maxspeed, smoothness, ecc.
Mancano i dati sulle mezzerie disegnate (perché nel resto del mondo di
solito non si risparmia sulla vernice per la segnaletica orizzontale)
ma non sarebbe impossibile aggiungerli.
Noi purtroppo viviamo in Italia... :-)
Post by Federico Cozzi
highway=road
lanes=2
smoothness=very_good
width=6
surface=paved
segnaletica_orizzontale=presente
classificazione_amministrativa=strada_provinciale
Non proprio... l'idea sarebbe:
highway = primary, secondary, etc... in funzione della classificazione (SS,
SR, SP, residenziale...) e dell'uso come ora (e dipenderebbe ovviamente dal
luogo)
Stato_fisico = A, B, C, D (con A, B, C, D assegnati secondo una tabellina
come l'esempio della mail di prima)
Paved = y/n

Gli altri parametri, surface, smoothness, ref per il nome li lascerei
opzionali esattamente
come ora.
Post by Federico Cozzi
-render
-router
-convertitori di formato (OSM -> Garmin)
-assegnare una vestizione
-decidere a che scala mostrare la strada
-assegnare una bontà di percorribilità
-assegnare una tipologia nel formato di destinazione (il formato
Garmin ha il concetto di gerarchia di strade)
ecc.
Questo "semplice" lavoro, cioè la istituzione dei sistemi di pesi,
Mica ho detto che il lavoro di istruzione del renderer o del calcolo dei
pesi per il router sia semplice:
due parametri in più (perchè sono poi solo due) potrebbero complicare non di
poco le attuali routine.
Post by Federico Cozzi
sarebbe complicatissimo perché già adesso non riusciamo a concordare
se una strada urbana a scorrimento veloce debba essere taggata
tertiary, secondary o primary! (tutto questo senza considerare quanto
siano larghe le corsie o quale sia la qualità dell'asfalto)
Quindi vieni dalla mia parte? Non sarebbe più semplice per un mapper
definire un tipo "fisico" di strada guardando una serie di foto esplicative
e taggarne la gerarchia semplicemente leggendo la classificazione su un
cartello? Toglieresti di mezzo ogni dubbio.
Post by Federico Cozzi
In più, come dicevo, esistono alcuni parametri non fisici che
influiscono molto sulle caratteristiche di una strada. Non hai
contemplato il numero di veicoli al giorno che è importantissimo per
il routing (per alcune categorie di veicoli)
Non mi pare di aver visto un parametro neppure ora.... e poi quello non è
legato alla sua "fisicità" di base, ma alla maggiore o minore difficoltà nel
percorrerla.
Post by Federico Cozzi
Puoi già farlo: highway=foobar indica la parte logica.
Tutti gli altri tag (lanes, width, ecc.) indicano la parte fisica.
Ma lo scopo di una cartina stradale non è dare un'informazione
*fisica* della realtà!
Per quella esistono le foto, anzi le ortofoto.
Una cartina stradale fornisce un'informazione "pre-masticata" della
realtà (dal cartografo) affinché la lettura sia più chiara.
Non abbiamo parlato di "cartina stradale" in senso stretto, o sbaglio? Non
si parlava di un geodatabase e della generazione renderizzata di *una*
rappresentazione fruibile della realtà?
Se giro in macchina avrò determinate necessità di "traduzione" dal fisico
alla mappa, se vado in bicicletta o a piedi ne avrò altre.
Post by Federico Cozzi
Ti faccio un esempio: quando pianifichi un itinerario su Google Maps o
simili, usi il layer fotografico oppure il layer cartografico?
Dipende dal luogo e da come mi dovrò muovere in loco. Una volta che saprò
come
sono fisicamente le strade saprò ad esempio che dovrò munirmi di
fuoristrada.
Saputo quello molto probabilmente mi affiderò ad un router che mi calcolerà
un itinerario in base ad altri parametri.
Post by Federico Cozzi
La somiglianza alla realtà è inutile in una cartina.
E chi l'ha detto? Non ritieni utile sapere che devi percorrere una primary a
doppio senso che ha la larghezza di una smart???
Post by Federico Cozzi
Ti faccio un altro esempio: nella OpenCycleMap i rilievi sono colorati
a seconda della loro altitudine, con uno sfumo che va dal verde al
marrone al bianco.
Ebbene questo sfumo è totalmente artificiale e non combacia
assolutamente né con la linea della vegetazione né con la linea delle
nevi.
Non mi sembra un esempio calzante: la linea della vegetazione e
dell'innevamento variano con la stagione, mentre le caratteristiche alle
quali mi riferisco io si presume che restino costanti durante l'anno.
Le curve di livello per la cycle map sono molto più utili in quanto ti danno
l'informazione sulle pendenze che ti troverai ad affrontare... ed anche
queste rimangono costanti nell'anno.
Post by Federico Cozzi
Questa è utopia: nessun software, dati i parametri fisici della
strada, riesce a "capire" una strada meglio di chi conosce quella
strada dal vivo (il cartografo). Tu stai sostenendo, implicitamente,
che il lavoro del cartografo non sia affidabile e debba essere
affidato ad un algoritmo che, a partire da dati oggettivi, deduca
deterministicamente le caratteristiche di una strada.
Non esattamente: io sostengo che il numero di "cartografi" in gioco è troppo
elevato e potresti trovare 10 persone che mappano parti della stessa zona
con criteri di "approssimazione" completamente diversi e soggettivi. Quale
sarebbe il risultato finale se non di non riuscire ad ottenere una
sufficiente omogeneità nella mappatura??
Post by Federico Cozzi
a. presenza di punti di interesse nei dintorni (una scuola elementare
genera traffico in determinate ore del giorno)
b. temporizzazione dei semafori
c. rete stradale, che fa sì che di due strade fisicamente equivalenti
una sia più trafficata di un'altra (perché il grafo è organizzato in
maniera tale da spingere il traffico da una parte e non da un'altra)
Non mi pare di aver letto da nessuna parte che la tangenziale di Milano
dalle 7 alle 8 del mattino deve essere taggata come unclassified e non come
motorway perchè la congestione del traffico la rende di fatto
impercorribile... o sbaglio??
Post by Federico Cozzi
Secondo me funziona tutto meglio se ci si appoggia a pochi parametri,
intrinsecamente "riassuntivi" e soggettivi, come ad esempio il tag
highway.
La semplicità è sicuramente la cosa migliore, ma non mi sembra che per una
mappatura "di base"
highway, stato_fisico e paved siano poi un'esagerazione.

Ciao
Cristian
Giovanni Fasano
2009-05-20 19:19:08 UTC
Permalink
Post by Cristian Testa
highway = primary, secondary, etc... in funzione della classificazione
(SS, SR, SP, residenziale...)
Il problema è che attualmente la classificazione di una strada non ha
niente a che vedere con le sue caratteristiche o la sua importanza ma
indica solo qual'è l'ente che ci fa manutenzione. Inoltre i criteri non
sono uniformi da regione a regione abbiamo quindi la stessa strada che può
essere statale, regionale, provinciale e comunale. Non mi sembra che
questo dato sia molto importante per chi utilizza i dati/le mappe e al
limite si ricava da "ref" o se proprio si vuole si potrebbe utilizzare un
tag apposito.

Ciao Gio.
Cristian Testa
2009-05-20 19:27:33 UTC
Permalink
Attualmente quello è il criterio base utilizzato per definire se una strada
sia primary, secondary, ecc.
La mia proposta va appunto nella direzione di dare un tag "fisico" per
definire di che tipo di strada si parli e lasciare highway a tag logico che
rispetti la classificazione stabilita dal legislatore in loco. E ref e name
vanno benone in ogni caso per battezzarle sulla mappa...
Ciao
Cristian
----- Original Message -----
From: "Giovanni Fasano" <gvf-+***@public.gmane.org>
To: "openstreetmap list - italiano" <talk-it-3+rWM/WnaLOn4i5uJCXUsti2O/***@public.gmane.org>
Sent: Wednesday, May 20, 2009 9:19 PM
Subject: Re: [Talk-it] Riflessioni sulla mappatura
Post by Cristian Testa
highway = primary, secondary, etc... in funzione della classificazione
(SS, SR, SP, residenziale...)
Il problema è che attualmente la classificazione di una strada non ha
niente a che vedere con le sue caratteristiche o la sua importanza ma
indica solo qual'è l'ente che ci fa manutenzione. Inoltre i criteri non
sono uniformi da regione a regione abbiamo quindi la stessa strada che può
essere statale, regionale, provinciale e comunale. Non mi sembra che
questo dato sia molto importante per chi utilizza i dati/le mappe e al
limite si ricava da "ref" o se proprio si vuole si potrebbe utilizzare un
tag apposito.

Ciao Gio.
Martin Koppenhoefer
2009-05-20 22:01:46 UTC
Permalink
Post by Cristian Testa
Attualmente quello è il criterio base utilizzato per definire se una strada
sia primary, secondary, ecc.
La mia proposta va appunto nella direzione di dare un tag "fisico" per
definire di che tipo di strada si parli e lasciare highway a tag logico che
rispetti la classificazione stabilita dal legislatore in loco. E ref e name
vanno benone in ogni caso per battezzarle sulla mappa...
Ciao
                           Cristian
si puo propongere tutto, ma una questione del genere (cambiare il modo
principale di classificare le strade) in un progetto mondiale la
dovresti porre alla mailing-list internazionale (talk). Io onestamente
penso che per cambiarlo si dovrebbe fare un fork. Poi finora funziona
anche col sistema corrente, basta capirlo e applicarlo in modo
"giusto", quindi non capisco bene perché la vuoi cambiare.

Martin
Cristian Testa
2009-05-21 20:52:02 UTC
Permalink
In realtà io non voglio cambiare nulla, nè tantomeno stravolgere il
progetto. E nemmeno quella fisica dovrebbe necessariamente essere la nuova
base.
Sarebbe esclusivamente una coppia di tag che, se presente, potrebbe essere
utilizzata per permettere una visualizzazione più "realistica" combinando la
situazione fisica e quella logica delle strade, tolgliendo
contemporaneamente di mezzo eventuali disomogeneità nella mappatura a causa
degli aggiustamenti (o della mancanza degli stessi) da parte dei vari
mapper: non so se nel resto del mondo esista una diretta corrispondenza tra
la larghezza delle strade e la loro classificazione amministrativa (che lì
renderebbe almeno il parametro di aspetto fisico ridondante), ma la
situazione italiana è sicuramente alquanto variegata, con strade con
caratteristiche fisiche anche molto diverse classificate alla stessa
maniera.
So benissimo che esistono già alcuni tag fisici molto più raffinati, come la
est_width per la larghezza o la surface per la definizione dei materiali
che, se adeguatamente valorizzati ed utilizzati da un renderer e da un
router potrebbero dare risultati spettacolari, ma ritengo che l'utilizzo di
parametri di tipo on/off come paved oppure con pochi valori per stimare la
larghezza della strada siano più facili da valutare ad occhio per i più e
probabilmente anche da inserire in un algoritmo di rendering / routing.
Ciao
Cristian

----- Original Message -----
From: "Martin Koppenhoefer" <***@gmail.com>
To: "openstreetmap list - italiano" <talk-***@openstreetmap.org>
Sent: Thursday, May 21, 2009 12:01 AM
Subject: Re: [Talk-it] Riflessioni sulla mappatura
Post by Martin Koppenhoefer
Post by Cristian Testa
Attualmente quello è il criterio base utilizzato per definire se una strada
sia primary, secondary, ecc.
La mia proposta va appunto nella direzione di dare un tag "fisico" per
definire di che tipo di strada si parli e lasciare highway a tag logico che
rispetti la classificazione stabilita dal legislatore in loco. E ref e name
vanno benone in ogni caso per battezzarle sulla mappa...
Ciao
Cristian
si puo propongere tutto, ma una questione del genere (cambiare il modo
principale di classificare le strade) in un progetto mondiale la
dovresti porre alla mailing-list internazionale (talk). Io onestamente
penso che per cambiarlo si dovrebbe fare un fork. Poi finora funziona
anche col sistema corrente, basta capirlo e applicarlo in modo
"giusto", quindi non capisco bene perché la vuoi cambiare.
Martin
_______________________________________________
Talk-it mailing list
http://lists.openstreetmap.org/listinfo/talk-it
Martin Koppenhoefer
2009-05-22 02:03:34 UTC
Permalink
Sarebbe esclusivamente una coppia di  tag che, se presente, potrebbe essere
utilizzata per permettere una visualizzazione più "realistica" combinando la
situazione fisica e quella logica delle strade, tolgliendo
contemporaneamente di mezzo eventuali disomogeneità nella mappatura a causa
degli aggiustamenti (o della mancanza degli stessi) da parte dei vari
mapper: non so se nel resto del mondo esista una diretta corrispondenza tra
la larghezza delle strade e la loro classificazione amministrativa (che lì
renderebbe almeno il parametro di aspetto fisico ridondante), ma la
situazione italiana è sicuramente alquanto variegata, con strade con
caratteristiche fisiche anche molto diverse classificate alla stessa
maniera.
il metodo ufficiale di classificazione in Germania consiste di 2 livelli:
http://de.wikipedia.org/wiki/Stra%C3%9Fenkategorie
(sempre tedesco, mi dispiace, ma non trovo mai niente in italiano)
uno secondo alla funzione (~sosta, ~accesso, collegamento): A,B,C,D,E
uno secondo il tipo di collegamento: I, II, III, IV, V, VI

poi secondo questa classificazione insieme alla velocità progettata,
si puo scegliere una sezione tipica da usare:
http://de.wikipedia.org/wiki/Entwurfsgeschwindigkeit
(se guardi la tabella a destra qui:
http://de.wikipedia.org/wiki/Entwurfsgeschwindigkeit#Bemessungsgeschwindigkeit%20vB
ti disce la larghezza in metri (RQ ... metri) per velocità progettata
(la velocità è anche importante per disegnare le curve).

la classificazione amministrativa non c'entra, quella ti disce chi
paga per costruzione e manutenzione.

quell articolo indicato sopra fa un riassunto delle normative RAS-L,
RAS-Q e RAS-K. Altri leggi e normative per strade:
http://de.wikipedia.org/wiki/Liste_der_technischen_Regelwerke_und_amtlichen_Bestimmungen_f%C3%BCr_das_Stra%C3%9Fenwesen

se guardi tutto questo il nostro piccolo mondo OSM è abbastanza semplice ;-)

ciao,
Martin
Federico Cozzi
2009-05-22 07:24:14 UTC
Permalink
Post by Martin Koppenhoefer
http://de.wikipedia.org/wiki/Stra%C3%9Fenkategorie
Secondo me l'obiezione di Cristian nasce dal fatto che l'Italia non è
la Germania.
Mentre in Germania (e probabilmente in altri paesi razionali) le
caratteristiche fisiche di una strada sono determinate sulla base di
una classificazione (non necessariamente amministrativa) ragionata a
tavolino (questa strada è di categoria A -> allora deve avere due
corsie, la mezzeria, i marciapiedi ecc.), in Italia le caratteristiche
fisiche delle strade sono spesso slegate non solo dalla
classificazione amministrativa, ma anche dalla "importanza" delle
strada. Ci sono statali che sono indiscutibilmente primary e che però
hanno una corsia e mezza in tutto, mentre altre hanno le carreggiate
separate e due corsie per senso di marcia (e magari sono meno
importanti per la rete stradale)

Quello che succede in Italia è quindi:
a. se assegnamo primary, secondary ecc. sulla base delle
caratteristiche fisiche, otteniamo una mappa insensata dal punto di
vista "logico" della rete stradale, dove appaiono più importanti
strade che nella realtà lo sono meno
b. se assegnamo primary, secondary ecc. sulla base esclusivamente
della classificazione amministrativa otteniamo altri assurdi (statali
declassate ecc.)
c. se, come facciamo ora, assegnamo primary secondary ecc. anche sulla
base dell'importanza della strada nella rete stradale, si ha che la
classificazione primary/secondary/ecc. non ha effettivamente alcun
legame con le caratteristiche fisiche, cioè se vedo "primary" non so
prevedere se ha 4 corsie oppure 1 e mezza.

Obietto che però l'approccio c. è il migliore dal punto di vista della
restituzione grafica (segue la tradizione delle cartine stradali
italiane) e del routing, e che comunque in OSM è possibile aggiungere
le caratteristiche fisiche delle strade appunto tramite width, lanes
ecc.

Ciao
Martin Koppenhoefer
2009-05-22 12:21:41 UTC
Permalink
Post by Federico Cozzi
Secondo me l'obiezione di Cristian nasce dal fatto che l'Italia non è
la Germania.
lo so! Pero le differenze (al livello normativo/legale) sono come
spesso non così grandi. Ho trovato un po di materiale in italiano che
corrisponde a quello citato sopra in tedesco:

-legge 12 febbraio 1958 n° 126 "classificazione delle strade"
- circolare A.N.A.S. del 10/5/1960 che fornisce i criteri di
progettazione in base al traffico.
- CNR 10004-63 "costruzione e manutenzione delle strade urbane"
- CNR 10005-63"costruzione e manutenzione delle strade-caratt. geometriche"
- CNR 10006-63"costruzione e manutenzione delle strade-tecnica di
impiego delle terre"
-CNR 28/02/73 n°31 "norme sulle caratteristiche geometriche delle strade"
-CNR 28/06/80 n°78 "norme sulle caratteristiche geometriche delle
strade extraurbane"
vedere anche il DM 1404 del 1/05/1968 per quanto riguarda la
classificazione stradale.

(non ho letto tutto questo, ma dei titoli vedo che pare simile)
Post by Federico Cozzi
Mentre in Germania (e probabilmente in altri paesi razionali) le
caratteristiche fisiche di una strada sono determinate sulla base di
una classificazione (non necessariamente amministrativa)
esatto, non amministrativa (anche se non è completamente slegato,
perché una strada statale è di solito di alta categoria di
collegamento, ecc., ma quello è quasi un effetto laterale, non la
classificazione).
Post by Federico Cozzi
ragionata a
tavolino (questa strada è di categoria A -> allora deve avere due
corsie, la mezzeria, i marciapiedi ecc.), in Italia le caratteristiche
fisiche delle strade sono spesso slegate non solo dalla
classificazione amministrativa, ma anche dalla "importanza" delle
strada.
anche in Italia le strade vengono progettate a tavolino con dei
criteri simile a queste riportate, ma non significa che tutte strade
si trovano anche in uno stato che corrisponde in maniera ottima a la
normativa.
Post by Federico Cozzi
Ci sono statali che sono indiscutibilmente primary e che però
hanno una corsia e mezza in tutto, mentre altre hanno le carreggiate
separate e due corsie per senso di marcia (e magari sono meno
importanti per la rete stradale)
la realtà dipende anche di altri vincoli (soldi, possibilità di
estensione (vicini, topologia, aree protette, spazio, corruzione(?))
Post by Federico Cozzi
a. se assegnamo primary, secondary ecc. sulla base delle
caratteristiche fisiche, otteniamo una mappa insensata dal punto di
vista "logico" della rete stradale, dove appaiono più importanti
strade che nella realtà lo sono meno
b. se assegnamo primary, secondary ecc. sulla base esclusivamente
della classificazione amministrativa otteniamo altri assurdi (statali
declassate ecc.)
per quello le normative classificanno le strade secondo la loro
funzione non secondo alla classificazione amministrativa o sulla base
delle caratteristiche fisiche (funziona al contrario: una strada viene
individuata (classificata) come importante, poi si cerca di adeguare
le caratteristiche fisiche a questa classificazione, - se ci sono
soldi e interesse pubblico per farlo).
Post by Federico Cozzi
c. se, come facciamo ora, assegnamo primary secondary ecc. anche sulla
base dell'importanza della strada nella rete stradale, si ha che la
classificazione primary/secondary/ecc. non ha effettivamente alcun
legame con le caratteristiche fisiche, cioè se vedo "primary" non so
prevedere se ha 4 corsie oppure 1 e mezza.
dove si trova questo mito nel Wiki che una primary deve avere per
forza 4 corsie?
Post by Federico Cozzi
Obietto che però l'approccio c. è il migliore dal punto di vista della
restituzione grafica (segue la tradizione delle cartine stradali
italiane) e del routing, e che comunque in OSM è possibile aggiungere
le caratteristiche fisiche delle strade appunto tramite width, lanes
ecc.
+1

ciao,
Martin
Federico Cozzi
2009-05-22 07:27:24 UTC
Permalink
Post by Cristian Testa
router potrebbero dare risultati spettacolari, ma ritengo che l'utilizzo di
parametri di tipo on/off come paved oppure con pochi valori per stimare la
larghezza della strada siano più facili da valutare ad occhio per i più e
probabilmente anche da inserire in un algoritmo di rendering / routing.
Ritengo che gli eventuali parametri "fisici" dovrebbero essere
condivisi a livello mondiale, perché altrimenti col cavolo che i
render/router li useranno.
Insomma quello che bisognerebbe fare, secondo te, è usare più spesso
lanes e width/est_width; usare surface, oppure il non ancora proposto
ma discusso paved; eventualmente introdurre nuovi tag che descrivano
lo stato della segnaletica orizzontale.
Ma, oltre a creare i tag, poi bisogna taggare le strade esistenti...

Ciao
Federico
Martin Koppenhoefer
2009-05-22 12:25:24 UTC
Permalink
Post by Federico Cozzi
Insomma quello che bisognerebbe fare, secondo te, è usare più spesso
lanes
si, quello sempre mettrei se ci sono piu di due (o più di una per un oneway)
Post by Federico Cozzi
e width/est_width;
non serve tantissimo, visto che le "lanes" già danno più o meno quello
Post by Federico Cozzi
usare surface
si, sempre, se un highway e altro di asfalto (perché asfalto viene
cosiderato default per le highway).
Post by Federico Cozzi
oppure il non ancora proposto
ma discusso paved;
secondome un doppione per chi non si fida di surface
Post by Federico Cozzi
eventualmente introdurre nuovi tag che descrivano
lo stato della segnaletica orizzontale.
alla fine, se abbiamo tempo ;-)
Post by Federico Cozzi
Ma, oltre a creare i tag, poi bisogna taggare le strade esistenti...
+2

ciao,
Martin
Martin Koppenhoefer
2009-05-20 13:25:26 UTC
Permalink
Post by Federico Cozzi
Post by Martin Koppenhoefer
si, pero noi non siamo facendo "una mappa" ma un geodatabase aperto,
che permette di creare varie mappe, il cartografo OSM invece è quello
che renderizza una mappa con questi dati. Lui è la persona chi
generalizza e seleziona.
Vorrei sfatare questo mito, o per lo meno sostenere che è irraggiungibile.
L'idea che OSM possa contenere "tutto" e che poi l'utente estragga le
informazioni che gli servono è bella ma impossibile.
ah si?
Post by Federico Cozzi
Noi cartografi OSM, quando carichiamo dati nel geodatabase, facciamo
delle scelte irreversibili che non permettono l'estrazione di
1. mappiamo la mezzeria delle strade e non i marciapiedi: va bene se
vuoi estrarre una mappa 1:25000, inizia a scricchiolare se vuoi una
mappa 1:10000 ed è insufficiente se vuoi una mappa 1:2000
Ho già visto dei tentativi di ricostruire la superficie delle strade
(come area) da singoli way centrici: ha funzionato meglio di come me
lo aspettavo. Ovviamente sono utile indicazioni per larghezze delle
strade, ma pure sensa funziona abbastanza bene, visto che la larghezza
delle corsie è normato
(http://de.wikipedia.org/wiki/Stra%C3%9Fenquerschnitt
http://de.wikipedia.org/wiki/Richtlinie_f%C3%BCr_die_Anlage_von_Stra%C3%9Fen_-_Querschnitt).
Inoltre aspetto che nel futuro mappiamo anche le strade come aree
(simile ai fiumi e riverbank) _in più_ alle way centrali (per il
routing).
Post by Federico Cozzi
2. quali edifici mappiamo? (building=yes) So che qualcuno risponderà
"tutti" ma questo ha senso se si vuole una mappa 1:2000. Se invece si
vuole una mappa 1:50000 bisogna mostrare solo gli edifici
significativi (attualmente il tag building non è così raffinato)
si, che lo è. Building=yes è molto povero, invece si dovrebbe mettere
building=_tipo-di-fabbricato_
http://tagwatch.stoecker.eu/Europe/En/keystats_building.html
si vede che la maggior parte è (ancora) "yes" ma ci sono anche qualche
altri valori, e i render usano qualsiasi valore per renderizzare un
building (probabilmente pure building=no ;-) )
Post by Federico Cozzi
3. con che criterio mappiamo il landuse? In aperta campagna, in una
zona totalmente agricola, metto un solo poligono landuse=farm oppure
mappo ogni singolo campo e lascio scoperte le zone di passaggio tra i
campi/i fossi/i filari/i muretti?
lo secondo ch'hai detto. Prima o poi.
Post by Federico Cozzi
4. con quale precisione mappo le way? In una pista ciclopedonale (bici
+ pedoni) a corsie separate (cartello blu con la barra di separazione
tra bici e pedoni) traccio due way (una ciclabile, l'altra pedonale)
oppure ne metto una sola (highway=cycleway, foot=designated,
segregated=yes=?
in realtà quello sarebbe highway=path, foot=designated,
bicycle=designated, segregated=yes se la barra è verticale
http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_241.svg&filetimestamp=20060729030321
nel caso orrizontale
http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_240.svg&filetimestamp=20060917131312
senza il segregated=yes
http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dpath
(lo so, solo in tedesco questo, e in generale il path non mi piace
molto, ma per i percordi condivise è l'unico modo di indicarlo in un
modo preciso).
Separatamente (quindi con 2 way) sarebbe in ogni caso sbagliato, perché
1. si tratta di una strada che viene usato insieme sullo stesso spazio
2. si po cambiare ovunque da un way al'altro, cosa non viene
rappresentato nella versione due way
Post by Federico Cozzi
5. con che precisione traccio la linea costiera? (Mandelbrot si
chiese: "quanto è lunga la costa della Gran Bretagna?" e nacque la
geometria frattale)
piu preciso possibile per te con i tuoi mezzi. Non mi sembra un vero
problema, visto che non si tratta di una linea precisa fino al
dettaglio dei atomi, perché il mare è sempre in movimento.
Post by Federico Cozzi
6. ecc.
si, ecc.
Post by Federico Cozzi
Volente o nolente, qualsiasi inserimento di dati in un geobase è
inevitabilmente una semplificazione della realtà che è accettabile
solo avendo ipotizzato un uso futuro della carta per il quale quella
semplificazione è indifferente.
si, la scala in generale viene già dato dei mezzi (precisione gps,
foto yahoo, alle volte forse anche misurazione a mano)
Post by Federico Cozzi
Si potrebbe risolvere osservando che la fruizione della carta sarà
limitata dalla precisione del sistema GPS, che è dell'ordine dei 5
metri, e quindi il nostro obiettivo potrebbe essere quello di produrre
un'ottima carta 1:2000 (non avrebbe senso produrre carte a scale
maggiori perché sarebbero infruibili).
infruibili nel senso che un gps non ti disce precisamente, dove ti
trovi, anche se i dati sono più precisi, ma si potrebbe cmq. usare
anche i dati più precisi (metti qualcuno mette rilievi di scavi
archeologiche dentro OSM (con la precisione 2 cm): si potrebbe sempre
renderizzarli anche sullo schermo di un GPS, nonostante la precisione
del GPS non ti fa capire essatamente la tua posizione (solo con errore
di 5-10m).

Martin
Cristian Testa
2009-05-20 09:51:37 UTC
Permalink
----- Original Message -----
From: "Federico Cozzi" <f.cozzi-***@public.gmane.org>
To: "openstreetmap list - italiano" <talk-it-3+rWM/WnaLOn4i5uJCXUsti2O/***@public.gmane.org>
Sent: Wednesday, May 20, 2009 1:21 AM
Subject: Re: [Talk-it] Riflessioni sulla mappatura
Post by Federico Cozzi
Non sono d'accordo.
Decenni di mappe stradali "cartacee" hanno mostrato la necessità di
classificare le strade secondo un criterio di importanza (dalle più
importanti alle meno importanti). Questa gerarchia svolge in un colpo
1. assegna un diverso stile grafico al render (strade più importanti
sono più evidenti di strade meno importanti)
2. decide a quali scale deve essere disegnata ciascuna strada
3. permette di pianificare un percorso.
Come dicevo prima, in tutte le mappe cartacee questi tre bisogni (e
probabilmente me ne sono perso qualcuno), del tutto indipendenti tra
di loro, sono soddisfatti da un'unica gerarchia.
A questo punto qualsiasi cartografo deve decidere sulla base di quale
criterio assegnare la classificazione alle strade, ma comunque non
riesce a sfuggire al concetto di gerarchia.
Non mi sembra che il mio approccio sia molto diverso:
1. un renderer furbo sarebbe perfettamente in grado di scegliere se
visualizzare una mappa "fisica" (dimensionando le strade in base ad un grado
A,B,C riferito alle dimensioni della strada), gerarchica (utilizzando i tag
primary, secondary, ecc. riferiti alla classificazione stabilita dal
legislatore) o una versione ibrida delle due con dimensioni e tratto basate
su parametri fisici e colori indicanti l'importanza.
2.La scala alla quale ti stai riferendo è puramente fittizia, un tratto più
o meno largo a seconda dell'importanza della strada e non attivente alla
realtà dei fatti.
3. Per la pianificazione di un percorso stiamo solo parlando della visita di
un grafo alla ricerca del cammino minimo tra due nodi e qualsiasi software è
capace di farlo in base ai pesi assegnati agli archi che congiungono i nodi.
Quali parametri e come vengano tenuti in conto nel calcolo del peso
complessivo dell'arco dipende solo dalla scelta in quel momento.
Post by Federico Cozzi
Quello che tu sostieni è che la gerarchia non debba esistere nella
cartina prodotta dal cartografo, ma solo nella visione che della
cartina ne ha l'utente.
Cioè tu sostieni che la gerarchia, che è un
criterio indiscutibilmente soggettivo, debba essere abbandonata e
1. larghezza della carreggiata
2. numero di corsie
3. tipo di fondo
Noi noi siamo cartografi, o almeno io non lo sono, e non stiamo
producendo nessuna cartina... stiamo creando un database globale di strade,
terreni, costruzioni e quant'altro possa essere localizzato con un GPS con
un certo grado di approssimazione, e mi
pare che uilizzare come parametro "base" per le strade la classificazione
del legislatore locale si scontri un po' con la possibilità di confrontare
oggettivamente due zone distinte del pianeta.
Il cartografo vero è poi il renderer, che in funzione dei parametri che
viene istruito a considerare nella visualizzazione genererà una possibile
rappresentazione della realtà, e quindi una cartina che soddisfi i bisogni
dell'utente in quel momento e in quella zona specifica.
Post by Federico Cozzi
A. la determinazione dei criteri oggettivi è un lavoro lungo e
necessariamente incompleto: nel tuo elenco ad esempio non accenni al
numero di veicoli/giorno che transitano sulla strada (e che è un
parametro molto importante per un urbanista!). Inoltre molti criteri
oggettivi saranno necessariamente misurati in maniera soggettiva
(potrai davvero contare quanti veicoli transitano al giorno? qual è la
scala della "qualità" del fondo stradale?) e quindi il miraggio
dell'oggettività rimarrà tale, perché necessariamente verrà introdotta
una dose di soggettività.
Ferma, ferma.... io non sto parlando di precisione assoluta, ma di una serie
di parametri fisici di base oggettivamente misurabili, ma ad occhio, mica in
maniera millimetrica.
Parametri cioè che chiunque guardi la strada sia in grado di definire:
- numero di corsie
- presenza di una linea di mezzeria
- asfalto o non asfalto (il famoso parametro paved y/n).
- larghezza. Intesa però non come larghezza assoluta, ma percepita con un
auto media.

Ti faccio un esempio:
strada tipo A: 2 o più corsie per senso di marcia, linea di mezzeria
presente
strada tipo B: 1 corsia per senso di marcia, larghezza sufficiente per un
transito agevole dei mezzi pesanti, linea di mezzeria presente.
strada tipo C: 1 corsia per senso di marcia, buona per le auto ma stretta
per i camion, linea di mezzeria presente
strada tipo D: 1 corsia per senso di marcia, strettina anche per le auto,
linea di mezzeria non presente
strada tipo E: larghezza equivalente ad una corsia o poco più. occorre
fermarsi per far passare le auto che arrivano dall'altra direzione, linea
di mezzeria non presente
A questo tipo aggiungerei un paved y/n.

Gli altri parametri per avere una maggiore specificità rimarrebbero come ora
opzionali: surface, smoothness, ecc...
Un dato sul traffico non è sicuramente chi si trovasse a passare di lì per
caso che potrebbe valutarlo...
Quello che sto dicendo io in sostanza non è di stravolgere completamente il
lavoro fatto, ma che servirebbe introdurre una doppia classificazione per le
strade:
una, chiamiamola aspetto fisico, basata esclusivamente su una serie di
parametri visivamente apprezzabili ed una, chiamiamola pure highway, che
definisca l'importanza della strada e la loro destinazione d'uso.
Post by Federico Cozzi
B. come ho già detto in un'altra mail (ho il difetto di ripetermi
spesso ;-) secondo me il cartografo non "descrive" la realtà, ma la
"interpreta". Cioè non si limita a riprodurre in maniera oggettiva la
realtà (anche se in scala ridotta), ma la modifica in modo da renderla
più fruibile all'utente. Per questo motivo secondo me non ha senso
parlare de "La Mappa Universale", perché una (buona) mappa contiene al
suo interno anche il fine per cui è stata progettata. Paradossalmente
una mappa è tanto più chiara tanto più il cartografo *elimina* i dati
inutili.
Infatti, e sono pienamente d'accordo con te in proposito tranne che per una
cosa: la fruibilità di una mappa da parte di un utente la definisce l'utente
stesso; il cartografo si limita a tradurre la realtà oggettiva in una che
soddisfi le esigenze di chi guarderà quella cartina.
Visto che, come ho detto sopra, stiamo creando un database di luoghi potrà
essere l'utente stesso a chiedere al renderer-cartografo di visualizzare la
realtà necessaria in quel momento, togliendo tutti i fronzoli inutili.
Post by Federico Cozzi
Cito Borges che è molto più bravo di me :-)
Mi perdoni Borges se l'ho brutalmente tagliato dalla mail .. :-)
ma a me sembra che il risultato finale sia il medesimo e perfettamente in
linea con il suo ed il tuo pensiero; è il punto di partenza che cambia.
Io parto dal presupposto che qualunque cartografo non possa creare una
cartina fruibile di una zona che non conosce e l'unico modo per fargliela
conoscere veramente è quello di fornirgli quanti più dati oggettivi
possibili su quella zona.
Sarà poi compito suo estrarre i dati e visualizzarli in funzione dello scopo
della cartina che andrà a creare. E lasciare troppo spazio alla soggettività
del giudizio in fase di istruzione del cartografo sicuramente non permetterà
di estrarre correttamente molte delle rappresentazioni possibili.

Ciao
Cristian
Federico Cozzi
2009-05-20 13:18:11 UTC
Permalink
2009/5/20 Cristian Testa <testa.cristian-***@public.gmane.org>:
Infatti, e sono pienamente d'accordo con te in proposito tranne che per una
Post by Cristian Testa
cosa: la fruibilità di una mappa da parte di un utente la definisce l'utente
stesso; il cartografo si limita a tradurre la realtà oggettiva in una che
soddisfi le esigenze di chi guarderà quella cartina.
Questo è l'approccio alla X-Windows, che personalmente detesto ;-)

Ciao
Federico Cozzi
2009-05-18 16:56:05 UTC
Permalink
Post by Luca Delucchi
questo è possibile con i maxscaledenom e minscaledenom e i filtri spiegati sopra
Anche questi filtri devono appoggiarsi a qualcosa.

Guarda qui:
http://wiki.openstreetmap.org/wiki/Key:service
I vari service=yard, spur, ecc. servono proprio per capire quando far
scattare i maxscaledenom e minscaledenom.

Ciao,
Federico
Federico Cozzi
2009-05-18 16:54:10 UTC
Permalink
Post by Luca Delucchi
non fai la rivoluzione secondo me crei solo un doppione, surface
all'inizio era paved/unpaved e io continuo ad usare quella che è la
cosa migliore perchè un unpaved può essere terriccio con erba o erba
con ghiaia ecc ecc usare solo paved e unpaved mi sembra la cosa
migliore!
Insomma siamo fondamentalmente d'accordo anche se non sembra ;-)
Anch'io sarei d'accordo ad una chiave con due soli valori: paved oppure unpaved.
Il problema è che surface è (a mio parere) "degenerata" in una cosa da
ingegneri con la descrizione precisa del tipo di superficie. Questa è
un'assurdità che non ho mai visto su nessuna cartina né stradale né
escursionistica (dove le strade sono asfaltate o non asfaltate).

Nota che la ricchezza del tag surface è ben diversa dalla ricchezza
del tag amenity: se qualcuno inventa amenity=foobar, e io non so cosa
sia un foobar, semplicemente non lo vedo sulla mappa: perdo un oggetto
che *non* conosco.
Se invece qualcuno inventa surface=foobar perché è più preciso di
surface=paved, perdo un oggetto *che conosco*: non so più capire se la
strada è asfaltata oppure no, quindi ad esempio non posso farci
routing in bicicletta se ho una bicicletta da corsa.

Per questo avevo proposto il tag "luddista" paved: chi vuole fare il
fine continuerà a usare surface, chi vuole fare il grezzo può
benissimo usare paved.

Gli utenti "fini" leggeranno il tag surface, gli utenti "grezzi"
leggeranno il tag paved

Ciao
Martin Koppenhoefer
2009-05-18 17:40:21 UTC
Permalink
Post by Federico Cozzi
Insomma siamo fondamentalmente d'accordo anche se non sembra ;-)
Anch'io sarei d'accordo ad una chiave con due soli valori: paved oppure unpaved.
-1
Post by Federico Cozzi
Il problema è che surface è (a mio parere) "degenerata" in una cosa da
ingegneri con la descrizione precisa del tipo di superficie. Questa è
un'assurdità che non ho mai visto su nessuna cartina né stradale né
escursionistica (dove le strade sono asfaltate o non asfaltate).
certo di non, anchio sono d'accordo che per le mappe generale non è da
differenziare graficamente fino al'infinito (nelle mappe per
biciclette invece l'interesse è già più grande, e se non esiste ancora
un prodotto ne anche comerciale che le segna: per quello siamo (tra
altro) noi in corso a crearne). Chi fa il render potrebbe benissimo
creare due regole per pavimentato e non pavimentato sfregandosi dei
dettagli. Chi fa il routing invece probabilmente è interessato ad un
persorso individuale (quindi chi va in bici da corso imposta il router
con le apposite regole e lo dice quale superficie sono da evitare).

Il problema non è difficile da risolvere quando una strada è taggato
surface=sand oppure surface=pebblestone che non è pavimentata, invece
si po mai sapere di una strada surface=unpaved, se quella va ancora
bene o non.

Martin
Martin Koppenhoefer
2009-05-18 17:49:13 UTC
Permalink
Post by Federico Cozzi
Insomma siamo fondamentalmente d'accordo anche se non sembra ;-)
Anch'io sarei d'accordo ad una chiave con due soli valori: paved oppure unpaved.
onestamente dei valori in uso ci sono tanti ;-)

http://tagwatch.stoecker.eu/Europe/En/keystats_surface.html

e la maggiorparte è pure da uniformare secondome, ma ci sono anche dei
casi che sono indispensabili:
cobblestone (=paved ma non va bene per biciclette)
ground (=unpaved, ma potrebbe essere bene anche per bici, vedi smoothness)
e qualche altro.

Martin
Luca Delucchi
2009-05-18 17:53:42 UTC
Permalink
Post by Martin Koppenhoefer
onestamente dei valori in uso ci sono tanti ;-)
http://tagwatch.stoecker.eu/Europe/En/keystats_surface.html
siamo fuori di testa? ok essere un wiki ma un minimo di regole bisogna
darle, non si possono avere tutti questi valori quelli sotto i 100
vanno aboliti e modificati! Se si avesse un database relazionale
sarebbe molto meglio avendo chiavi esterne ecc ecc
Post by Martin Koppenhoefer
Martin
ciao
Luca
Carlo Stemberger
2009-05-18 17:58:13 UTC
Permalink
Post by Luca Delucchi
non si possono avere tutti questi valori quelli sotto i 100
vanno aboliti e modificati!
Assolutamente no!

È una mappa libera, ognuno può avere i propri interessi a mappare in un
certo modo.

Metti che ci sia un folle che vuol renderizzarsi la mappa di tutte le
strade ricoperte di ciottoli in terracotta, perché impedirglielo?

Per questo la chiave "paved" è fortissima: dà un'indicazione di massima
ma lascia libero lo sviluppo della chiave "surface" fino ad un grado di
dettaglio pressoché infinito.
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Stefano Pallicca
2009-05-18 18:07:22 UTC
Permalink
_______________________________________________
Talk-it mailing list
Talk-it-3+rWM/WnaLOn4i5uJCXUsti2O/***@public.gmane.org
http://lists.openstreetmap.org/listinfo/talk-it
Carlo Stemberger
2009-05-18 18:11:31 UTC
Permalink
Beh, almeno cercare di correggerne alcuni per uniformare quelli che
indicano la stessa cosa
Ovvio: un errore è un errore.


L'idea però di applicare una "censura" sui dati immessi proprio non mi
piace, se non fortemente motivata.
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Martin Koppenhoefer
2009-05-18 18:06:03 UTC
Permalink
Post by Luca Delucchi
Post by Martin Koppenhoefer
onestamente dei valori in uso ci sono tanti ;-)
http://tagwatch.stoecker.eu/Europe/En/keystats_surface.html
siamo fuori di testa?
è la prima volta che guardi tagwatch? Certo, surface è uno dei casi
gravi, ma prima di mettere mano discuterei con l'emittente del tag
(penso che la maggior parte non è in Italia).
Post by Luca Delucchi
ok essere un wiki ma un minimo di regole bisogna
darle, non si possono avere tutti questi valori quelli sotto i 100
vanno aboliti e modificati!
essendo un wiki potresti sempre cambiare anche tu. Siamo tutti
risponsabile della situazione. Pero alcune casi non cambierei sensa
notificare a nessuno (altri si, per esempio se un francese scrive
"bois" invece di "wood" lo cambierei). Poi si deve anche vedere che
danni fanno. Io se farebbe un applicazione per lavorare con le
superficie, userei qualche poche tag per pavimentato (paved, concrete,
asphalt, concrete_plates), è il resto potrebbe rimanere tutto "il
resto". Oppure si mette a differenziare il resto in altri "pacheti"
più differenziati, cmq.: quello la generalisazione è il processo di
selezione per la mappa / il routing / qualsiasi altro uso, non è il
modo di inserire dati nel database (anche li si generaliza, ma più
fino secondome).

Martin
Carlo Stemberger
2009-05-18 18:50:11 UTC
Permalink
Post by Martin Koppenhoefer
cobblestone (=paved ma non va bene per biciclette)
Vallo a spiegare ai corridori della Parigi-Roubaix :-)
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Martin Koppenhoefer
2009-05-18 14:49:04 UTC
Permalink
Post by alberto
Anche se sono d' accordo col principio che la classificazione delle
strade la fa l' utilizzo e non il tipo di fondo stradale e che sarebbe
auspicabile differenziare sul rendering strade della stessa
classificazione ma con fondo stradale differente, credo che allo stato
attuale del rendering questo modo di vedere le cose porti in pratica a
non apprezzare sulla mappa un parametro importante della strada, cioè la
sua percorribilità.
la percorribilità delle strade non viene renderizzato. Dipende di
tanti fattori (tra altro il traffico sulla strada!).
Post by alberto
Se ho due strade, parlo sempre di strade di campagna non importanti, che
funzionalmente sono unclassified e quindi le taggo ambedue in quel modo,
ma una è asfaltata e l' altra è ghiaiata ma magari con buche che dopo
piovuto hanno un palmo d' acqua, perchè non dovrei apprezzare sulla
mappa questo stato di cose?
Il rendering non farebbe differenza, ed io darei una informazione
sbagliata dichiarandole ambedue percorribili allo stesso modo.
non, non dai una informazione sbagliata, e se aggiungi i tag surface
diventa ancora più preciso. Secondome la classificazione highway
indica la posizione delle strade dentro la rete stradale, non la
percorribilità.
Post by alberto
Una mappa mi serve per organizzare un percorso, devo potere avere
informazioni in tal senso.
Mi direte che guardo troppo al risultato visivo della mappa, ma alla
fine è quello che poi serve a chi la usa.
http://wiki.openstreetmap.org/wiki/Surface
se sei interessatissimo alle superficie, richiedi una mappa delle
superficie (adesso ci sono sperimenti in corso per renderizzare
proprio quello, vedi per es. qui:
http://openstreetmap.org/?lat=51.77111&lon=7.44373&zoom=17&layers=0B00FTFT
Loading Image...
Loading Image...
Loading Image...
Loading Image...
Loading Image...
http://www.informationfreeway.org/?lat=49.039&lon=8.2913&zoom=17
Post by alberto
Ora come ora abbiamo a disposizione una gamma di tipologie di strade
renderizzate in un certo modo, dall' autostrada alla "track", nulla mi
dice che in futuro avrò a disposizione altre varianti grafiche che
tengano conto del fondo stradale.
sara, fidati, solo che chi fa le mappe (render) deve anche stare
attento a non creare troppo confusione con troppe informazioni (più
differenziazione c'è più difficile diventa).

Ciao,
Martin
albertobonati
2009-05-18 15:55:05 UTC
Permalink
Post by Martin Koppenhoefer
http://wiki.openstreetmap.org/wiki/Surface
se sei interessatissimo alle superficie, richiedi una mappa delle
superficie (adesso ci sono sperimenti in corso per renderizzare
http://openstreetmap.org/?lat=51.77111&lon=7.44373&zoom=17&layers=0B00FTFT
http://daten.mueck.de1.cc/osm/grades-z15.PNG
http://daten.mueck.de1.cc/osm/surface_rendering2.PNG
http://daten.mueck.de1.cc/osm/grades-z16.PNG
http://daten.mueck.de1.cc/osm/grades-z17.PNG
http://daten.mueck.de1.cc/osm/surface_rendering.PNG
http://www.informationfreeway.org/?lat=49.039&lon=8.2913&zoom=17
Si, così potrebbe andare.

Ma qua

http://openstreetmap.org/?lat=51.77111&lon=7.44373&zoom=17&layers=0B00FTFT

sembra sbucata fuori (guardo la Map Key) una categoria che si chiama
"Unsurfaced Road" che non è la track...

Nel wiki non la trovo...

Si può utilizzare?

Ciao

Alberto
Martin Koppenhoefer
2009-05-18 16:14:33 UTC
Permalink
Post by albertobonati
sembra sbucata fuori (guardo la Map Key) una categoria che si chiama
"Unsurfaced Road" che non è la track...
è la soluzione per i tuoi desideri? highway=xy(strada, non percorso),
surface=unpaved?
Post by albertobonati
Nel wiki non la trovo...
surface = 'altro di paved, asfaltato, concrete'?
Post by albertobonati
Si può utilizzare?
si utilizza come proposto nei vari commenti in questo thread:
highway=unclassified (nel tuo caso)
surface="pebblestone" o "gravel" (secondo la grandezza dei pezzi nel tuo caso).
oppure surface=unpaved (sconsigliato, perché vecchio e lo scopo è
diventato di mettere più precisione).

Non sono sicuro se questi Mapkey (sono per mapnik) sono attuali, e se
ti renderizza un attuale ***@H questo (se non, potresti inventare te la
regola o richiederla nel trac).

Martin
Martin Koppenhoefer
2009-05-17 02:42:02 UTC
Permalink
Post by Cristian Testa
Concordo. Se sono effettivamente strade che portino a zone residenziali con
villette o simili, è corretto che vengano taggate come residential
le strade piccole con le villette a canto sono i residential, ma le
strade che portano in queste zone posso ben essere anche primary, sec,
etc.

Martin
Federico Cozzi
2009-05-15 07:30:13 UTC
Permalink
Post by Alberto Nogaro
Secondo me dipende dall'uso, non dalla pavimentazione. Sono track se
[...]
Post by Alberto Nogaro
Altrimenti sono unclassified (o anche superiore, se a dispetto della
pavimentazione sono sufficientemente importanti).
Hai teoricamente ragione, ma obietto:
1. in Italia e nel mondo civilizzato tipicamente le strade di
importanza unclassified o superiore sono asfaltate, quindi una strada
di campagna non asfaltata è ragionevolmente track
2. unclassified è proprio il livello minimo delle strade su OSM: se
una strada non asfaltata è sufficientemente importante per la
viabilità locale da non essere classificata come track (ad esempio
perché è l'unica strada che collega due nuclei abitati), probabilmente
la promuoverei direttamente a tertiary

Ciao
Elena of Valhalla
2009-05-15 07:59:35 UTC
Permalink
Post by Federico Cozzi
Post by Alberto Nogaro
Secondo me dipende dall'uso, non dalla pavimentazione. Sono track se
[...]
Post by Alberto Nogaro
Altrimenti sono unclassified (o anche superiore, se a dispetto della
pavimentazione sono sufficientemente importanti).
1. in Italia e nel mondo civilizzato tipicamente le strade di
importanza unclassified o superiore sono asfaltate,
in teoria
Post by Federico Cozzi
quindi una strada
di campagna non asfaltata è ragionevolmente track
una strada di campagna che serve solo ai mezzi agricoli per me e`
track anche se per qualche strano motivo l'hanno asfaltata (o, piu`
probabile, se ci han messo un po' di cemento)

se pero` cominciano a costruirci un ristorante o una villetta, e la
strada viene usata piu` da auto che da mezzi agricoli, per me non e`
piu` una strada di campagna da track
Post by Federico Cozzi
2. unclassified è proprio il livello minimo delle strade su OSM: se
una strada non asfaltata è sufficientemente importante per la
viabilità locale da non essere classificata come track (ad esempio
perché è l'unica strada che collega due nuclei abitati), probabilmente
la promuoverei direttamente a tertiary
una strada non asfaltata che porta ad un gruppo di case troppo piccolo
per essere considerato un nucleo abitato o ad un ristorante, o la
prosecuzione (non asfaltata) di una strada urbana unclassified o
residential, magari in quanto aggiunta recente verso case di nuova
costruzione, non mi sembrano ne' strade agricole ne' strade degne di
essere tertiary
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Federico Cozzi
2009-05-15 08:38:17 UTC
Permalink
Post by Elena of Valhalla
una strada di campagna che serve solo ai mezzi agricoli per me e`
track anche se per qualche strano motivo l'hanno asfaltata (o, piu`
probabile, se ci han messo un po' di cemento)
Infatti in quel caso è trackgrade1
Post by Elena of Valhalla
una strada non asfaltata che porta ad un gruppo di case troppo piccolo
per essere considerato un nucleo abitato o ad un ristorante, o la
prosecuzione (non asfaltata) di una strada urbana unclassified o
residential, magari in quanto aggiunta recente verso case di nuova
costruzione, non mi sembrano ne' strade agricole ne' strade degne di
essere tertiary
Insomma stai descrivendo:
1. una strada senza uscita
2. una strada che porta a case sparse
3. una strada non asfaltata
(4. plausibilmente è una strada in campagna)
secondo me è track

Ciao
Elena of Valhalla
2009-05-15 08:44:56 UTC
Permalink
Post by Federico Cozzi
Post by Elena of Valhalla
una strada non asfaltata che porta ad un gruppo di case troppo piccolo
per essere considerato un nucleo abitato o ad un ristorante, o la
prosecuzione (non asfaltata) di una strada urbana unclassified o
residential, magari in quanto aggiunta recente verso case di nuova
costruzione, non mi sembrano ne' strade agricole ne' strade degne di
essere tertiary
1. una strada senza uscita
a volte si`, a volte si ricollega anche dall'altra parte a strade esistenti
di sicuro non e` una strada di passaggio
Post by Federico Cozzi
2. una strada che porta a case sparse
oppure che porta ai cancelli di ville / villette, comunque che viaggia
all'interno di terreni recintati e di uso residenziale
Post by Federico Cozzi
3. una strada non asfaltata
si`, ma ovviamente con un fondo percorribile da auto normali senza
grossi problemi
Post by Federico Cozzi
(4. plausibilmente è una strada in campagna)
non proprio, ai margini tra citta` e campagna, tendenzialmente
Post by Federico Cozzi
secondo me è track
secondo me una casa che porta a ville e villette, dove non passera`
mai un trattore (a meno che non si sia perso) e` molto piu`
residential
--
Elena ``of Valhalla''

homepage: http://www.trueelena.org
email: elena.valhalla-***@public.gmane.org
Alberto Nogaro
2009-05-15 11:49:33 UTC
Permalink
-----Original Message-----
Sent: venerdì 15 maggio 2009 9.30
To: openstreetmap list - italiano
Subject: Re: [Talk-it] strade extraurbane non pavimentate
1. in Italia e nel mondo civilizzato tipicamente le strade di
importanza unclassified o superiore sono asfaltate
In Italia si, le strade sono prevalentemente asfaltate. Ma ci sono paesi che
sicuramente includerei nel mondo civilizzato, tipicamente scarsamente
popolati, o dove le condizioni climatiche rendono oneroso mantenere le
strade pavimentate, dove tuttavia anche strade di importanza nazionale
possono essere non pavimentate.

Per quanto riguarda il dare più importanza allo stato della strada
(asfaltatura) o al suo utilizzo (agricolo o forestale) per decidere se
classificare o meno come track, il wiki mi sembra abbastanza chiaro. La
pagina in inglese è in effetti un po’ ambigua, perchè aggiunge alla lista
delle strade classificabili come traccie un 'etc.' che apre a tutte le
interpretazioni possibili. Ma la pagina in tedesco dice chiaramente che si
applica a strade:

- tra i campi o tra i boschi
- a prevalentemente utilizzo agricolo/forestale
- adatte a veicoli a quattro (o più) ruote.

La superficie può andare dal completamente asfaltato, alla presenza di
binari, fino alle strade in terra. Per definire al meglio lo stato sarebbe
bene usare entrambi tracktype=<grade1-5> e surface=*, perché il significato
non è sovrapponibile.

Anche dall'esistenza di un tracktype=1 per le tracce pavimentate mi sembra
evidente che la distinzione tra tracce e unclassified (o superiore) non si
può basare solo sullo stato delle pavimentazione.

Considerazione personale: alla fin fine di sapere se la strada è
classificata come unclassified o track non mi importa molto. Se i tag di
accesso (se l'accesso è riservato ai mezzi agricoli o forestali va indicato
esplicitamente, la classificazione come track non implica nulla), lo stato
fisico della strada (surface, tracktype, smoothness, width), ed il percorso
sono indicati chiaramente, ho tutto gli elementi che mi servono per decidere
se quella strada la voglio percorrere o meno, anche senza guardare la
classificazione.

Ciao
Martin Koppenhoefer
2009-05-16 04:25:30 UTC
Permalink
Post by Andrea Musuruane
Post by alberto
Come vi regolate nel taggare strade extraurbane di campagna con
pavimentazione in ghiaino?
Le mettete come hoghway=unclassified o come  track?
Premetto, non sono piste per trattori, parlo di strade non asfaltate.
direte che mi sono risposto da solo, ma  ho il dubbio, il rendering non
le distingue dalle asfaltate e la differenza c'è...
Io le traccio come highway=track e tracktype=grade1.
dipende, se quello è una strada per accedere ad un paese (piccolo),
per me sarebbe highway=unclassified. track è per le piste per trattori
come scrive alberto.
Post by Andrea Musuruane
http://wiki.openstreetmap.org/wiki/Track
Track: Roads for agricultural use [...]
esatto, track sono viottoli di campagna, non strade.
Post by Andrea Musuruane
http://wiki.openstreetmap.org/wiki/Key:tracktype
grade1: Paved track or heavily compacted hardcore.
il grade1 è spesso asfaltato o la superficie è simili ad asfaltato,
quindi sicuramente non va bene per una pista in ghiaino (massimo tt2
(ghiaino piccolo), se non 3). In questo caso pero
highway=unclassified, surface=pebblestone o gravel

http://wiki.openstreetmap.org/wiki/Surface

Martin
Gianluca Frare
2009-05-22 09:54:00 UTC
Permalink
Spero di non intromettermi in modo molesto, volevo solo dire la mia.
Ho seguito la discussione sulla classificazione, cercando di capire come
la pensate. Io per ora ho usato l'approccio estetico della mappa, cioè
ho ricreato quello che sono abituato a vedere nelle altre mappe disponibili.
Sono però d'accordo con la classificazione originale del wiki EN, ha
senso creare un db
con le informazioni esatte, tuttavia credo dovrebbero essere introdotti
dei layout
di render che mi permettono di vedere la cartina come sono abituato a
vederla
in modo da non disorientarmi. Se un nuovo mappatore vede lo stato della
mappa
con il render di come dovrebbe essere seguendo le indicazioni in inglese
del wiki,
si troverebbe un po' disorientato. Almeno io lo sarei.
Per esempio se il render con layout italiano prevedesse che le SS, le SR
e le SP fossero
comunque disegnate come siamo abituati noi penso che seguirei più
volentieri le linee guida perchè
comunque vedo una cartina più familiare a me, ma il db conserva le
informazioni e la coerenza
di cui ha bisogno a livello internazionale.
Immagino che fare il render personalizzato sia oneroso ma risolverebbe
tutti vari discorsi
che sono stati fatti e la nostra reinterpretazione delle highway che mi
sembra si scontri con quella originale.
gianluca
Carlo Stemberger
2009-05-24 11:56:15 UTC
Permalink
Post by Gianluca Frare
Per esempio se il render con layout italiano prevedesse che le SS, le SR
e le SP fossero
comunque disegnate come siamo abituati noi penso che seguirei più
volentieri le linee guida perchè
comunque vedo una cartina più familiare a me, ma il db conserva le
informazioni e la coerenza
di cui ha bisogno a livello internazionale.
A quanto pare vale la pena ripetere un'altra volta una cosa detta decine
di volte (non esagero) nell'ultimo anno: _il tag highway non indica la
classificazione amministrativa_, ma la sua importanza. Come stabilire
l'importanza è già stato detto varie volte (scavare nella mailing-list o
nel wiki).

In sintesi:
classificazione amministrativa ---> ref
grado di importanza ---> highway
caratteristiche fisiche ---> tante altre chiavi
--
.' `. | Registered Linux User #443882
|a_a | | http://counter.li.org/ .''`.
\<_)__/ +--- : :' :
/( )\ ---+ `. `'`
|\`> < /\ Registered Debian User #9 | `-
\_|=='|_/ http://debiancounter.altervista.org/ |
Martin Koppenhoefer
2009-05-24 20:55:20 UTC
Permalink
Post by Carlo Stemberger
classificazione amministrativa ---> ref
grado di importanza ---> highway
caratteristiche fisiche ---> tante altre chiavi
+3

beh si, alla fine ne meno per chi progetta strade e secondo le
normative la classa amministrativa è quella importante.

Sono contento che ci siamo avvicinando alla situazione internazionale,
manca adesso solo qualche primary e secondary in città per farmi
contento ;-)

Martin

Continua a leggere su narkive:
Loading...