Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Fra Mauro
Due osservazioni / dubbi sul tema.

Sui gradini: io ho provato a mappare i gradini proprio pensando ai problemi di 
accessibilità. Ecco un incrocio di esempio:

https://www.openstreetmap.org/#map=19/41.86103/12.55477

Ovviamente ci sono questi aspetti da chiarire:
- è funzionale per i disabili?
- come distinguere dove il gradino non è stato mappato da dove non esiste? Da 
questo punto di vista kerb=no è molto utile

Secondo punto: vivendo a Roma mi rendo conto che il tipo di superficie pone 
anche esso problemi di accessibilità. Il surface smoothness, per capirci... 
Avete considerato questo aspetto?

Grazie

Il 3 Dicembre 2019 10:03:47 CET, Sara di giorgio  
ha scritto:
>Buongiorno,
>sto lavorando all'interno di un progetto per la città di Milano,
>sull'accessibilità ai disabili.
>Stiamo costruendo un grafo pedonale e mappando le barriere
>architettoniche
>all'interno del Municipio 1 della città.
>Chiedo un'informazione in merito ad un dubbio sulla mappatura dei
>marciapiedi nelle vie del centro in cui questi sono solo segnalati
>tramite
>segnaletica orizzontale, ma sono molto stretti (ad esempio non ci
>passerebbe una sedia a rotelle, ma poichè è tutto allo stesso livello
>della
>carreggiata, è possibile passare anche se si "invaderebbe" la strada").
>Per il momento abbiamo mappato i marciapiedi come footway=sidewalk.
>In questi casi potrebbe essere una buona idea aggiungere la larghezza
>con
>il tag width?
>inoltre, poichè di fatto il cordolo del marciapiede è allo stesso
>livello
>della strada, potrebbe essere una buona idea inserire anche il tag
>kerb=no
>per tutto il marciapiede?
>
>Grazie

-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Alessandro Sarretta

Scusa Sara, vedo solo ora che ho leggermente frainteso la tua richiesta.

Pur confermando tutto quanto scritto nell'altra mia e-mail riguardo ai 
marciapiedi, mi sembra di capire che tu faccia riferimento non a 
marciapiedi veri e propri ma a delle corsie pedonali ricavate solamente 
tramite linee colorate sulla carreggiata.


In questo caso non credo che la mappatura di way separate come 
footway=sidewalk sia correttissima, o quantomeno è ancora molto 
discussa. Recentemente se ne è discusso sulla mailing list 
(https://lists.openstreetmap.org/pipermail/tagging/2019-November/049024.html) 
e c'è una proposta 
(https://wiki.openstreetmap.org/wiki/Proposed_features/Pedestrian_lane) 
però per ora rifiutata.


Mi pare di comprendere che la soluzione più "standard" sarebbe 
descrivere la way principale (la strada) con un ulteriore tag come 
footway:left/right=lane che descriva che c'è una corsia pedonale che 
però fa parte della carreggiata stessa e non è separata fisicamente, 
allo stesso modo in cui si usa per le corsie ciclabili: 
https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dlane


Ale

On 03/12/19 10:03, Sara di giorgio wrote:

Buongiorno,
sto lavorando all'interno di un progetto per la città di Milano, 
sull'accessibilità ai disabili.
Stiamo costruendo un grafo pedonale e mappando le barriere 
architettoniche all'interno del Municipio 1 della città.
Chiedo un'informazione in merito ad un dubbio sulla mappatura dei 
marciapiedi nelle vie del centro in cui questi sono solo segnalati 
tramite segnaletica orizzontale, ma sono molto stretti (ad esempio non 
ci passerebbe una sedia a rotelle, ma poichè è tutto allo stesso 
livello della carreggiata, è possibile passare anche se si 
"invaderebbe" la strada").

Per il momento abbiamo mappato i marciapiedi come footway=sidewalk.
In questi casi potrebbe essere una buona idea aggiungere la larghezza 
con il tag width?
inoltre, poichè di fatto il cordolo del marciapiede è allo stesso 
livello della strada, potrebbe essere una buona idea inserire anche il 
tag kerb=no per tutto il marciapiede?


Grazie

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare una scuola due

2019-12-03 Per discussione Martin Koppenhoefer
Am Mo., 2. Dez. 2019 um 21:17 Uhr schrieb Francesco Ansanelli <
franci...@gmail.com>:

> Anche a me sembra una questione importante Non è sempre cosi facile
> identificare un poligono, in quel caso, meglio un nodo, no?
>


direi quando è _impossibile_ individuare un poligono è meglio usare nodi
(oppure preliminarmente quando non ti va, ma in quel caso se qualcuno dopo
crea un poligono questo sarebbe la rappresentazione migliore)



> Comunque mappando un po' di scuole ho raccolto qualche dubbio:
>
> - ref oppure ref:MIUR?
>


non importa ;)




> - istituti che vanno dall'asilo alle medie? Va bene fare 3 nodi?
>


3 oggetti, che possano essere nodi o poligoni (nel caso siano 3 scuole,
cosa normalmente sarà il caso, quindi 3 direttori, 3 codici, ecc.)



> - come si distingue il nido dal micronido? Solo max/min age è sufficiente?
>


penso di sì


> - doposcuola per aiuto compiti? after_school=yes sembra solo per gli
> asili.
>


direi che vada bene per tutti.

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare una scuola due

2019-12-03 Per discussione Francesco Ansanelli
Grazie per il riscontro Martin!

Il mar 3 dic 2019, 10:07 Martin Koppenhoefer  ha
scritto:

>
>
> Am Mo., 2. Dez. 2019 um 21:17 Uhr schrieb Francesco Ansanelli <
> franci...@gmail.com>:
>
>> Anche a me sembra una questione importante Non è sempre cosi facile
>> identificare un poligono, in quel caso, meglio un nodo, no?
>>
>
>
> direi quando è _impossibile_ individuare un poligono è meglio usare nodi
> (oppure preliminarmente quando non ti va, ma in quel caso se qualcuno dopo
> crea un poligono questo sarebbe la rappresentazione migliore)
>
>
>
>> Comunque mappando un po' di scuole ho raccolto qualche dubbio:
>>
>> - ref oppure ref:MIUR?
>>
>
>
> non importa ;)
>

Però per uniformare i dati bisogna sceglierne quale adottare e aggiornare
il Wiki.

>
>
>
>
>> - istituti che vanno dall'asilo alle medie? Va bene fare 3 nodi?
>>
>
>
> 3 oggetti, che possano essere nodi o poligoni (nel caso siano 3 scuole,
> cosa normalmente sarà il caso, quindi 3 direttori, 3 codici, ecc.)
>

Siamo d'accordo. L'unico dubbio può ancora essere sul tipo di Building...
Ma credo che school sia il più indicato in quel caso.

>
>
>
>> - come si distingue il nido dal micronido? Solo max/min age è sufficiente?
>>
>
>
> penso di sì
>

Non sono super-esperto, ma propongo: maxage=1 e minage=1+maxage=4
Per entrambi
nursery=yes
+amenity=kindergarten
+isced:level=0


>
>> - doposcuola per aiuto compiti? after_school=yes sembra solo per gli
>> asili.
>>
>
>
> direi che vada bene per tutti.
>

Però amenity=childcare? Come per I baby parking?

>
> Ciao
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare una scuola due

2019-12-03 Per discussione Martin Koppenhoefer
Am Di., 3. Dez. 2019 um 12:58 Uhr schrieb Francesco Ansanelli <
franci...@gmail.com>:

>
>
>> Comunque mappando un po' di scuole ho raccolto qualche dubbio:
>>>
>>> - ref oppure ref:MIUR?
>>>
>>
>>
>> non importa ;)
>>
>
> Però per uniformare i dati bisogna sceglierne quale adottare e aggiornare
> il Wiki.
>


direi che nel caso non ci siano altri codici "ref" la cosa più naturale
sarebbe "ref" e basta. Anche perché non sappiamo se in futuro ci sara un
MIUR o se cambia nome, viene messo insieme ad un altro ministero ecc.



>
>>
>>
>>
>>> - istituti che vanno dall'asilo alle medie? Va bene fare 3 nodi?
>>>
>>
>>
>> 3 oggetti, che possano essere nodi o poligoni (nel caso siano 3 scuole,
>> cosa normalmente sarà il caso, quindi 3 direttori, 3 codici, ecc.)
>>
>
> Siamo d'accordo. L'unico dubbio può ancora essere sul tipo di Building...
> Ma credo che school sia il più indicato in quel caso.
>


nei casi che ho mappato spesso di edifici che ne sono tante (più come un
"campus" che come un edificio unico), ma questo chiaramente dipende dal
contesto urbanistico e dalle scelte architettoniche. Comunque, non
supponiamo che ci sia sempre un solo edificio. Il valore di "building" è il
tipo di edificio, non ci sono particolarità per le scuole, generalmente
saranno "building=school". Quando riscontriamo funzioni diversi nello
stesso edificio, io mi porrei la domanda: si tratta di una scuola dentro un
(altro) edificio, oppure di un'altra cosa dentro una scuola?

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Martin Koppenhoefer
Am Di., 3. Dez. 2019 um 12:54 Uhr schrieb Alessandro Sarretta <
alessandro.sarre...@gmail.com>:

>
> Secondo me il tipo di mappatura che hai fatto è graficamente utile per
> visualizzare il bordo dei marciapiedi, ma non molto funzionale per il
> routing di persone con disabilità e anche molto impegnativo e
> dispendioso in termini di tempo.
>


al momento si, ma quando si aggiungono le strade e marciapiedi come aree con
area:highway=* il lavoro sarà già fatto...

L'approccio parametrico (proprietà al marciapiede) non esclude di mappare
anche il kerb stesso (solo che è un po' ridondante da un certo punto di
vista).
In generale l'informazione più importante è l'altezza al punto dove un
pedone incrocia un kerb, per esempio dove ci sono le vie di accesso alle
proprietà, traverse, oppure attraversamenti pedonali. Dal punto di vista
del routing l'informazione più facile da digerire (credo) è un nodo alla
posizione del kerb.





>
> L'approccio che abbiamo usato a Padova è stato quello mi sembra più
> standard, cioè di aggiungere un nodo sulla way dell'attraversamento
> pedonale appena oltre rispetto all'intersezione tra marciapiede e
> attraversamento.



+1

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Martin Koppenhoefer
Am Di., 3. Dez. 2019 um 10:04 Uhr schrieb Sara di giorgio <
sara.digiorgi...@gmail.com>:

> In questi casi potrebbe essere una buona idea aggiungere la larghezza con
> il tag width?
>


sì, forse su un nodo oppure su un pezzo piccolo? Perché nelle situazioni
che ho riscontrate la larghezza varia.



> inoltre, poichè di fatto il cordolo del marciapiede è allo stesso livello
> della strada, potrebbe essere una buona idea inserire anche il tag kerb=no
> per tutto il marciapiede?
>


forse sì, non è ancora chiaro: https://wiki.openstreetmap.org/wiki/Key:kerb
dice "open issues: 2. kerb tags on ways"
Potresti iniziare una discussione sulla lista tagging

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Alessandro Sarretta

Ciao Fra Mauro,

On 03/12/19 11:33, Fra Mauro wrote:

Due osservazioni / dubbi sul tema.

Sui gradini: io ho provato a mappare i gradini proprio pensando ai 
problemi di accessibilità. Ecco un incrocio di esempio:


https://www.openstreetmap.org/#map=19/41.86103/12.55477

Ovviamente ci sono questi aspetti da chiarire:
- è funzionale per i disabili?


Secondo me il tipo di mappatura che hai fatto è graficamente utile per 
visualizzare il bordo dei marciapiedi, ma non molto funzionale per il 
routing di persone con disabilità e anche molto impegnativo e 
dispendioso in termini di tempo.


L'approccio che abbiamo usato a Padova è stato quello mi sembra più 
standard, cioè di aggiungere un nodo sulla way dell'attraversamento 
pedonale appena oltre rispetto all'intersezione tra marciapiede e 
attraversamento. Al nodo abbiamo solitamente aggiunto i tag 
kerb=flush/lowered/raised accoppiandolo a un dato quantitativo misurato 
kerb:height=* (es. kerb:height=0.02) e eventualmente 
tactile_paving=yes/no/primitive


Qui un esempio: https://www.openstreetmap.org/node/6611899865

- come distinguere dove il gradino non è stato mappato da dove non 
esiste? Da questo punto di vista kerb=no è molto utile


Se non è stato mappato il fatto che non ci sia è un elemento sufficiente 
per me :-)


Se si è valutato ma non c'è il gradino, il valore più corretto secondo 
me sarebbe kerb:flush + kerb:height=0


Secondo punto: vivendo a Roma mi rendo conto che il tipo di superficie 
pone anche esso problemi di accessibilità. Il surface smoothness, per 
capirci... Avete considerato questo aspetto?


Come descritto qui 
https://wiki.openstreetmap.org/wiki/PEBA_Comune_di_Padova#Elementi_da_mappare_e_tag_suggeriti 
non solo smoothness è sicuramente utile, ma anche altro.


Ale



___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Martin Koppenhoefer
Am Di., 3. Dez. 2019 um 12:36 Uhr schrieb Alessandro Sarretta <
alessandro.sarre...@gmail.com>:

> Il kerb=no secondo me non è molto corretto, preferirei un kerb:height='0
> m', ma dovrebbe essere assegnato a un elemento lineare che rappresenta il
> kerb (la connessione tra marciapiede e la carreggiata) e non il marciapiede
> stesso. La cosa si fa complessa, ma mi farebbe piacere approfondirla.
>


il lo vedo così:
ad un elemento che rappresenta il kerb:
height=0

ad un'altro elemento che "dispone" di un kerb (marciapiede o strada):
kerb:height=0

oppure anche
kerb:left:height (se mappato su una strada e le altezze sono diverse).

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


[Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Sara di giorgio
Buongiorno,
sto lavorando all'interno di un progetto per la città di Milano,
sull'accessibilità ai disabili.
Stiamo costruendo un grafo pedonale e mappando le barriere architettoniche
all'interno del Municipio 1 della città.
Chiedo un'informazione in merito ad un dubbio sulla mappatura dei
marciapiedi nelle vie del centro in cui questi sono solo segnalati tramite
segnaletica orizzontale, ma sono molto stretti (ad esempio non ci
passerebbe una sedia a rotelle, ma poichè è tutto allo stesso livello della
carreggiata, è possibile passare anche se si "invaderebbe" la strada").
Per il momento abbiamo mappato i marciapiedi come footway=sidewalk.
In questi casi potrebbe essere una buona idea aggiungere la larghezza con
il tag width?
inoltre, poichè di fatto il cordolo del marciapiede è allo stesso livello
della strada, potrebbe essere una buona idea inserire anche il tag kerb=no
per tutto il marciapiede?

Grazie
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Alessandro Sarretta

Ciao Sara,

a Padova, per il PEBA - Piano di eliminazione delle barriere 
architettoniche (http://www.padovanet.it/peba) si è fatto un grosso 
lavoro sull'utilizzo del tagging per l'accessibilità.


 * qui alcune linee guida/appunti sul wiki OSM:
   
https://wiki.openstreetmap.org/wiki/PEBA_Comune_di_Padova#Elementi_da_mappare_e_tag_suggeriti
 * qui il poster presentato al SOTM di Heidelberg:
   https://doi.org/10.5281/zenodo.3370704

Nello specifico

On 03/12/19 10:03, Sara di giorgio wrote:

Buongiorno,
sto lavorando all'interno di un progetto per la città di Milano, 
sull'accessibilità ai disabili.
Stiamo costruendo un grafo pedonale e mappando le barriere 
architettoniche all'interno del Municipio 1 della città.
Chiedo un'informazione in merito ad un dubbio sulla mappatura dei 
marciapiedi nelle vie del centro in cui questi sono solo segnalati 
tramite segnaletica orizzontale, ma sono molto stretti (ad esempio non 
ci passerebbe una sedia a rotelle, ma poichè è tutto allo stesso 
livello della carreggiata, è possibile passare anche se si 
"invaderebbe" la strada").

Per il momento abbiamo mappato i marciapiedi come footway=sidewalk.
In questi casi potrebbe essere una buona idea aggiungere la larghezza 
con il tag width?
Assolutamente sì, misurando e quindi assegnando il tag width=* a tratti 
omogenei
inoltre, poichè di fatto il cordolo del marciapiede è allo stesso 
livello della strada, potrebbe essere una buona idea inserire anche il 
tag kerb=no per tutto il marciapiede?


A Padova abbiamo cercato di essere più quantitativi possibile, sia per 
width, sia per incline, gradini ecc..


Per i marciapiedi alla stessa altezza della carreggiata, in realtà 
abbiamo segnato per il tratto di marciapiede relativo il valore height='0 m'


Il kerb=no secondo me non è molto corretto, preferirei un kerb:height='0 
m', ma dovrebbe essere assegnato a un elemento lineare che rappresenta 
il kerb (la connessione tra marciapiede e la carreggiata) e non il 
marciapiede stesso. La cosa si fa complessa, ma mi farebbe piacere 
approfondirla.


Mi pare che ci siano varie esperienze di approfondimento sul tema 
dell'accessibilità. Potremmo aggragarle per scrivere qualche pagina 
condivisa e strutturata sul wiki? Io sono più che disponibile a contribuire.


Ale

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Martin Koppenhoefer
Am Di., 3. Dez. 2019 um 13:29 Uhr schrieb Alessandro Sarretta <
alessandro.sarre...@gmail.com>:

> Mi pare di comprendere che la soluzione più "standard" sarebbe descrivere
> la way principale (la strada) con un ulteriore tag come
> footway:left/right=lane che descriva che c'è una corsia pedonale che però
> fa parte della carreggiata stessa e non è separata fisicamente, allo stesso
> modo in cui si usa per le corsie ciclabili:
> https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dlane
>


generalmente, la carreggiata è definita come lo spazio dedicato alla
circolazione di veicoli (cfr. accordo NU di Vienna sul traffico del 1968).
Non è del tutto chiaro come ci comportiamo in OSM, sopratutto che la
proposta per ora è stata rigettata.

https://www.unece.org/fileadmin/DAM/trans/conventn/Conv_road_traffic_EN.pdf
1, 1 (e)

Ciao
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


[Talk-it] Posizione di trainee al JRC su integrazione INSPIRE-OSM

2019-12-03 Per discussione Marco Minghini
Ciao a tutti,
il team della Commissione Europea - Joint Research Centre (JRC) in cui
lavoro ha appena aperto una posizione per un trainee (durata: 5 mesi) per
lavorare sull'integrazione tra dati INSPIRE e OpenStreetMap.

Le posizioni da trainee sono per persone giovani (indicativamente cerchiamo
una persona che stia completando la Laurea Specialistica, o stia facendo un
Dottorato oppure lo abbia concluso da poco) e permettono di fare una breve
esperienza lavorativa al JRC.

Trovate maggiori informazioni (inclusi i link alla call e alla pagina per
candidarsi) qui:
https://inspire.ec.europa.eu/news/trainee-position-inspire-openstreetmap-integration

Sarà un progetto seguito principalmente da me, e su cui spero di poter già
presentare i primi risultati al prossimo FOSS4G-IT di Torino.

Vi prego di diffondere la call a chiunque possa essere interessato. Per
chiunque non potesse/volesse applicare ma è comunque interessato al
progetto: contattatemi senza problemi!

Grazie,
Marco
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Alessandro Sarretta

Grazie Martin,

On 03/12/19 14:32, Martin Koppenhoefer wrote:
Am Di., 3. Dez. 2019 um 13:29 Uhr schrieb Alessandro Sarretta 
mailto:alessandro.sarre...@gmail.com>>:


Mi pare di comprendere che la soluzione più "standard" sarebbe
descrivere la way principale (la strada) con un ulteriore tag come
footway:left/right=lane che descriva che c'è una corsia pedonale
che però fa parte della carreggiata stessa e non è separata
fisicamente, allo stesso modo in cui si usa per le corsie
ciclabili: https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dlane



generalmente, la carreggiata è definita come lo spazio dedicato alla 
circolazione di veicoli (cfr. accordo NU di Vienna sul traffico del 
1968). Non è del tutto chiaro come ci comportiamo in OSM, sopratutto 
che la proposta per ora è stata rigettata.


interessante questa differenza rispetto alle corsi ciclabili.

Per quello che ho capito (dimmi se tu la vedi in modo diverso) la 
proposta è stata rigettata anche perché il termine pedestrial_lane 
sembrava una duplicazione di altre cose.


La discussione mi sembra si sia arenata, però l'esigenza continua ad 
esserci.


Personalmente un tag da aggiungere alla highway principale tipo

footway:lane=left|right|both|no

o

footway[:left|right|both]=lane

(io preferisco la prima) mi sembra che con un po' di discussione in 
lista possa passare... secondo te Martin c'è margine per ristrutturare 
la proposta e riprovare?


Sugli attraversamenti di una "corsia pedonale" come queste con una 
strada laterale in effetti avrei ancora dubbi...


Ale

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Martin Koppenhoefer
Am Di., 3. Dez. 2019 um 16:09 Uhr schrieb Alessandro Sarretta <
alessandro.sarre...@gmail.com>:

> Per quello che ho capito (dimmi se tu la vedi in modo diverso) la proposta
> è stata rigettata anche perché il termine pedestrial_lane sembrava una
> duplicazione di altre cose.
>


personalmente mi sono astenuto, ma non mi piaceva che non c'era
definizione, non era chiaro chi poteva usare queste corsie di default
(l'esempio della Svizzera, che era il motivo per la proposta, prevede che
le macchine possono usare questi spazi, quindi non sono assolutamente
paragonabili alle marciapiedi). Come risultato avremmo ottenuto dei
features taggati uguale, ma completamente diverse nelle varie parti del
mondo.

Altri utenti invece volevano vedere queste corsie come sorta di
marciapiede, e quindi hanno bocciato la proposta perché secondo loro un tag
già c'era: sidewalk.

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


[OSM-talk] OSMF candidate office hours, ask me anything

2019-12-03 Per discussione Michal Migurski
Hi everyone,

I’m one of the twelve candidates running for OSMF board. When I was an OSM US 
board member in 2012, I had good luck starting a weekly “office hours” session 
for people to chat about OpenStreetMap (it ended up turning into Geobreakfast 
and still happens in SF and NYC 7 years later; find us on Twitter).

If you’ve read my candidacy manifesto, you might have noted that I’m running 
with the explicit encouragement and permission of my employer, Facebook: 

https://wiki.openstreetmap.org/wiki/Foundation/AGM19/Election_to_Board/Answers_and_manifestos#Michal_Migurski

A candidate working in a company like FB and not specifically trying to 
disconnect OSM involvement from their day job is a potentially weird new thing 
in the community, so I thought it worth making myself available for questions, 
conversations, or whatever via conference call. I‘ve set up five hour-long 
blocks on my calendar accessible to a variety of time zones between now and 
when voting closes, and I’ll be hanging out ready to chat if you have anything 
you’d like to ask or share. Looking forward to chatting!

Times:

Hour 1, December 4 9:30am PST
Video call: https://bluejeans.com/791594022
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+1=20191204T0930=388=1

Hour 2, December 4 10pm PST
Video call: https://bluejeans.com/537172017
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+2=20191205T2200=388=1

Hour 3, December 6 9am PST
Video call: https://bluejeans.com/656483413
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+3=20191206T0900=388=1

Hour 4, December 8 4pm PST
Video call: https://bluejeans.com/565915593
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+4=20191208T1600=388=1

Hour 5, December 10 9am PST
Video call: https://bluejeans.com/925750882
Time: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSMF+Office+Hours+5=20191210T0900=388=1

-mike.


michal migurski- contact info and pgp key:
sf/cahttp://mike.teczno.com/contact.html


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-at] Radknotenpunktnetz Murtal

2019-12-03 Per discussione Robert Grübler
Robert Grübler [mailto:robgrueb...@gmail.com] schrieb am 9. November 2019
19:21

> Liebe Mapper,
> im Murtal gibt es eine in Österreich einzigartige Radinfrastruktur – das
Radknotenpunktnetzwerk „Nimm’s Radl“. 
> Das Netz mit 101 Knotenpunkte auf 350 km wurde im April 2016 eröffnet.
Heute – > 3 ½ Jahre später – ist davon 
> in OSM noch immer keine Spur zu sehen. 
>
> Das kann’s nicht sein, das soll sich ändern. Mitwirkende gesucht!

Hier -
https://wiki.openstreetmap.org/wiki/WikiProject_Austria/Radknotenpunktnetze
- gibt es schon die ersten Bausteine zum Diskutieren.
Kommentare sind willkommen.

Liebe Grüße Robert (robhubi)




___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Alessandro Sarretta
Secondo me in questo caso il marciapiede, anche se non ha un gradino
elevato, è comunque ben definito e il valore di width sarebbe importante
segnalarlo correttamente. Il fatto che una carrozzina debba andare in
strada per superare un tratto di marciapiede stretto rappresenta
sicuramente una situazione di pericolo, tanto più che la strada ha un
superficie con sanpietrini (mi pare) che solitamente sono difficoltosi per
le carrozzine.
Ale

Il mar 3 dic 2019, 21:50 Cascafico Giovanni  ha
scritto:

> Mi sono trovato anch'io a dover definire una situazione come questa [1],
> in cui il marciapiede "ufficiale" è stretto (<90cm) ma è comunque
> transitabilie senz difficoltà. Non metterei al marciapiede una width che lo
> precluda alle wheelchair. Kerb=no sul marciapiede lo esescluderei: sarebbe
> difficile da interpretare per i router.
>
>
>
> [1] https://www.mapillary.com/map/im/09BIcIFfAGxu8RJgQKb3_A
>
> Il mar 3 dic 2019, 10:04 Sara di giorgio  ha
> scritto:
>
>> Buongiorno,
>> sto lavorando all'interno di un progetto per la città di Milano,
>> sull'accessibilità ai disabili.
>> Stiamo costruendo un grafo pedonale e mappando le barriere
>> architettoniche all'interno del Municipio 1 della città.
>> Chiedo un'informazione in merito ad un dubbio sulla mappatura dei
>> marciapiedi nelle vie del centro in cui questi sono solo segnalati tramite
>> segnaletica orizzontale, ma sono molto stretti (ad esempio non ci
>> passerebbe una sedia a rotelle, ma poichè è tutto allo stesso livello della
>> carreggiata, è possibile passare anche se si "invaderebbe" la strada").
>> Per il momento abbiamo mappato i marciapiedi come footway=sidewalk.
>> In questi casi potrebbe essere una buona idea aggiungere la larghezza con
>> il tag width?
>> inoltre, poichè di fatto il cordolo del marciapiede è allo stesso livello
>> della strada, potrebbe essere una buona idea inserire anche il tag kerb=no
>> per tutto il marciapiede?
>>
>> Grazie
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare una scuola due

2019-12-03 Per discussione Martin Koppenhoefer


sent from a phone

> On 3. Dec 2019, at 22:10, Francesco Ansanelli  wrote:
> 
> 
> In quel caso il ref sarebbe diverso, no?
> Usare ref:MIUR mi sembra più in linea con i distributori che usano 
> ref:mise... Vorrei sentire anche qualche altra opinione...


penso che non sia paragonabile, perché il mise non è il gestore dei benzinai, 
non è il ref ufficiale ma soltanto una chiave estranea, mentre il ref delle 
scuole è ufficiale e quello di chi gestisce le scuole. Forse mi sbaglio e anche 
nel caso delle scuole non è il ref principale?


Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Cascafico Giovanni
Mi sono trovato anch'io a dover definire una situazione come questa [1], in
cui il marciapiede "ufficiale" è stretto (<90cm) ma è comunque
transitabilie senz difficoltà. Non metterei al marciapiede una width che lo
precluda alle wheelchair. Kerb=no sul marciapiede lo esescluderei: sarebbe
difficile da interpretare per i router.



[1] https://www.mapillary.com/map/im/09BIcIFfAGxu8RJgQKb3_A

Il mar 3 dic 2019, 10:04 Sara di giorgio  ha
scritto:

> Buongiorno,
> sto lavorando all'interno di un progetto per la città di Milano,
> sull'accessibilità ai disabili.
> Stiamo costruendo un grafo pedonale e mappando le barriere architettoniche
> all'interno del Municipio 1 della città.
> Chiedo un'informazione in merito ad un dubbio sulla mappatura dei
> marciapiedi nelle vie del centro in cui questi sono solo segnalati tramite
> segnaletica orizzontale, ma sono molto stretti (ad esempio non ci
> passerebbe una sedia a rotelle, ma poichè è tutto allo stesso livello della
> carreggiata, è possibile passare anche se si "invaderebbe" la strada").
> Per il momento abbiamo mappato i marciapiedi come footway=sidewalk.
> In questi casi potrebbe essere una buona idea aggiungere la larghezza con
> il tag width?
> inoltre, poichè di fatto il cordolo del marciapiede è allo stesso livello
> della strada, potrebbe essere una buona idea inserire anche il tag kerb=no
> per tutto il marciapiede?
>
> Grazie
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare una scuola due

2019-12-03 Per discussione Francesco Ansanelli
Il mar 3 dic 2019, 13:13 Martin Koppenhoefer  ha
scritto:

> Am Di., 3. Dez. 2019 um 12:58 Uhr schrieb Francesco Ansanelli <
> franci...@gmail.com>:
>
>>
>>
>>> Comunque mappando un po' di scuole ho raccolto qualche dubbio:

 - ref oppure ref:MIUR?

>>>
>>>
>>> non importa ;)
>>>
>>
>> Però per uniformare i dati bisogna sceglierne quale adottare e aggiornare
>> il Wiki.
>>
>
>
> direi che nel caso non ci siano altri codici "ref" la cosa più naturale
> sarebbe "ref" e basta. Anche perché non sappiamo se in futuro ci sara un
> MIUR o se cambia nome, viene messo insieme ad un altro ministero ecc.
>

In quel caso il ref sarebbe diverso, no?
Usare ref:MIUR mi sembra più in linea con i distributori che usano
ref:mise... Vorrei sentire anche qualche altra opinione...

>
>
>
>>
>>>
>>>
>>>
 - istituti che vanno dall'asilo alle medie? Va bene fare 3 nodi?

>>>
>>>
>>> 3 oggetti, che possano essere nodi o poligoni (nel caso siano 3 scuole,
>>> cosa normalmente sarà il caso, quindi 3 direttori, 3 codici, ecc.)
>>>
>>
>> Siamo d'accordo. L'unico dubbio può ancora essere sul tipo di Building...
>> Ma credo che school sia il più indicato in quel caso.
>>
>
>
> nei casi che ho mappato spesso di edifici che ne sono tante (più come un
> "campus" che come un edificio unico), ma questo chiaramente dipende dal
> contesto urbanistico e dalle scelte architettoniche. Comunque, non
> supponiamo che ci sia sempre un solo edificio. Il valore di "building" è il
> tipo di edificio, non ci sono particolarità per le scuole, generalmente
> saranno "building=school". Quando riscontriamo funzioni diversi nello
> stesso edificio, io mi porrei la domanda: si tratta di una scuola dentro un
> (altro) edificio, oppure di un'altra cosa dentro una scuola?
>

Capisco cosa intendi... Ma dicevo tra Building kindergarten e school direi
che è più indicato school perché da un senso più ampio del termine...



> Ciao
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Martin Koppenhoefer


sent from a phone

> On 3. Dec 2019, at 21:50, Cascafico Giovanni  wrote:
> 
> Kerb=no sul marciapiede lo esescluderei: sarebbe difficile da interpretare 
> per i router.


sicuramente molto più facile da interpretare rispetto ad un marciapiede senza 
informazioni sul kerb e con un kerb mappato a parte. Io non ci vedo problemi, 
nel senso che non si crea alcun problema ignorando questa informazione

Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare marciapiedi stretti

2019-12-03 Per discussione Alessandro Sarretta

On 03/12/19 13:01, Martin Koppenhoefer wrote:

il lo vedo così:
ad un elemento che rappresenta il kerb:
height=0

ad un'altro elemento che "dispone" di un kerb (marciapiede o strada):
kerb:height=0

oppure anche
kerb:left:height (se mappato su una strada e le altezze sono diverse).


Giustissime le tue osservazioni Martin.

Guardando nel dettaglio come si descrive l'uso del tag barrier=kerb 
(https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dkerb) capisco che si 
considera come default il caso che ci sia una parte alta e una bassa e 
che quella bassa stia a destra della direzione di disegno della linea.


Per complicare le cose, ci possono essere casi in cui c'è un cordolo tra 
un marciapiede e una pista ciclabile (es. 
https://www.mapillary.com/map/im/G1IAo_4MG5Vfyr-4Az6BOA). Si mappa 
comunque come barrier=kerb? In questo caso sarebbe corretto mappare le 
altezze da entrambi i "lati" del kerb con height:left=* e height:right=*?


Ale


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [Talk-it] Mappare una scuola due

2019-12-03 Per discussione Francesco Ansanelli
Il mar 3 dic 2019, 23:07 Martin Koppenhoefer  ha
scritto:

>
>
> sent from a phone
>
> > On 3. Dec 2019, at 22:10, Francesco Ansanelli 
> wrote:
> >
> >
> > In quel caso il ref sarebbe diverso, no?
> > Usare ref:MIUR mi sembra più in linea con i distributori che usano
> ref:mise... Vorrei sentire anche qualche altra opinione...
>
>
> penso che non sia paragonabile, perché il mise non è il gestore dei
> benzinai, non è il ref ufficiale ma soltanto una chiave estranea, mentre il
> ref delle scuole è ufficiale e quello di chi gestisce le scuole. Forse mi
> sbaglio e anche nel caso delle scuole non è il ref principale?
>
> Si tratta di codice "meccanografico", assegnato dal MIUR per quanto ne so,
in quanto dovrebbe comparire anche nei loro bollettini.
Mi domando se abbia un significato al di fuori del MIUR... Es. nel ref
potrei voler mettere un numero assegnato dal comune: media 1, media 2 ecc
ecc... Al momento ho usato alt name per questi casi.
Martin che ne dici se contiamo i ref delle scuole con e senza MIUR finale e
facciamo vincere la maggioranza?

>
>
>
>
> Ciao Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


Re: [OSM-talk-fr] dégradation notable d'OSM

2019-12-03 Per discussione Florimond Berthoux
+1 Tous les îlots ne sont pas là pour "calmer" (ralentir) le trafic,
bien au contraire, les îlots de ronds points sont fait pour séparer le
trafic et les insérer avec un angle de giration sympathique permettant
une bonne allure.
Il ne faut pas utiliser traffic_calming=island pour cela !

Le lun. 2 déc. 2019 à 21:01, Stéphane Péneau
 a écrit :
>
> Bizarre, Osmand ne m'a jamais fait ce genre d'erreur, ou alors je ne
> m'en suis pas rendu compte.
>
> En tout cas traffic_calming ne me semble pas vraiment approprié si on se
> réfère à son sens premier. La séparation à l'entrée/sortie d'un
> giratoire n'est pas là pour ralentir le trafic.
>
> Stf
>
> Le 02/12/2019 à 18:50, Dominique Rousseau a écrit :
> > Le Fri, Nov 29, 2019 at 09:46:14PM +0100, osm.sanspourr...@spamgourmet.com 
> > [osm.sanspourr...@spamgourmet.com] a écrit:
> > [...]
> >>> - Suppression des pattes d'oie à l'arrivée sur un rond point
> >> Tu veux dire les haricots séparant les voies ? Si ça se trouve c'est
> >> parce qu'il en a marre qu'OSMAND ne compte pas bien les sorties !
> >> On peut aussi modéliser avec des traffic_calming=island
> >> .
> > Ah, merci !
> > J'ai dejà eu l'occasion de créer des ways séparés pour représenter des
> > choses comme ça, et je trouvais ça plutot moche.
> > Maintenant je saurais comment les faire :)
> >
> >
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



-- 
Florimond Berthoux

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [talk-cz] OSM pivo 4Q 2019

2019-12-03 Per discussione Tom Ka
Jen pripominam, ze v Brne klasika - U Kormidla od 18:00.

Bye tom.k

po 2. 12. 2019 v 17:31 odesílatel Jan Macura  napsal:
>
> Nějaký zájemce o OSM pivo z Plzně? Já bych měl čas.
> Navrhuji KMP nebo Pivotečku.
>
> H.
>
> On Monday, 2 December 2019, Marián Kyral  wrote:
> > Ahoj,
> > nějaký zájemce o pivko z Ostravy? V Praze budu bohužel až příští týden :-(
> > Marián
> > -- Původní e-mail --
> > Od: Milan Cerny 
> > Komu: OpenStreetMap Czech Republic 
> > Datum: 30. 11. 2019 21:11:25
> > Předmět: [talk-cz] OSM pivo 4Q 2019
> >
> > Zdravím, jen připomínám, ve středu je termín kvartálního piva.
> >
> > https://docs.google.com/spreadsheets/d/12zGtW414R9se_g_87FdmpHj2B6xO1gf5mG94avTmFb4
> >
> > Milan
> >
> > ___
> > talk-cz mailing list
> > talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> > https://openstreetmap.cz/talkcz
> >
>
> --
> Sent from phone
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


Re: [OSM-talk-fr] "Vandalisme" à Gravelines de la part de l'OT

2019-12-03 Per discussione Vincent Bergeot

Bonjour,
heureusement qu'il y a les guillemets :) à vandalisme, ne rentrons pas 
dans cette représentation lorsque c'est des gens qui sont maladroits, ne 
connaissent pas, ...


Déjà le commentaire laisse supposer que quelqu'un valide derrière. 
Beaucoup d'ajout de tag sur le point adresse, idem ignorance je pense !


et des ajouts d'attributs intéressants aussi !

Je bosse un peu avec le tourisme et franchement ceux sont des gens qui 
connaissent super bien le territoire, atout non négligeable pour tenir 
les données à jour, car ils en ont besoin à chaque saison !!!


à plus




Le 03/12/2019 à 07:51, Yves P. a écrit :

Bonjour,

Un point géodésique  à 
été modifié avec le sympathique commentaire :
/"Bonjour veuillez prendre en compte les modifications apportées sur 
la commune de Gravelines. Clémence Office de Tourisme de Gravelines »/


Je fais un reverse pour celui-ci en mettant à jour le phare qui 
intéresse l’OT .


Il y a 12 autres modifications du même genre : 
https://www.openstreetmap.org/user/Clem%20OT%20Gravelines/history 


Je laisse les locaux regarder ça de plus près.

—
Yves

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--
Vincent Bergeot

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Gareth L
Potentially use https://www.quora.com/How-can-I-put-OpenStreetMap-on-my-website

Gareth

On 3 Dec 2019, at 09:47, Edward Bainton  wrote:


Hi all

General Elections 
Online
 (hosted at parliament.uk) have got a failed page where 
the Google map is overlaid with "Development purposes only".

I was planning to suggest they use OSM instead.

Can anyone point me to the precise technical detail their webmaster will need? 
Is it the wiki page, Deploying your own Slippy 
Map?

Thanks,

Edward
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [talk-au] Kathmandu + OSM

2019-12-03 Per discussione David Wales
They're even using Leaflet, which I'm sure suggests the correct
attribution if you use all the default settings!

On 3/12/19 10:24 am, Adam Horan wrote:
> The tiles seem to be coming from tile.osm.org  -
> i thought that was a no-no ? Might depend on whether their site counts
> as 'heavy usage' https://operations.osmfoundation.org/policies/tiles/  ?
>
> I feel they do deserve some credit for actually using OSM rather than
> google maps (although they do use google maps for directions)
>
> On Tue, 3 Dec 2019 at 08:55, Andrew Harvey  > wrote:
>
> There is also a wiki
> page https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution to
> try to keep track of these kinds of issues.
>
> On Mon, 2 Dec 2019 at 23:39, Ben Kelley  > wrote:
>
> Hi.
>
> I noticed that Kathmandu's web site (the clothing retailer,
> rather than the city in Nepal) uses OSM for their store
> locator, but it does not include the correct copyright
> information. https://www.kathmandu.com.au/stores
>
> I sent them some feedback on their web site to this effect, so
> I'll see how it goes.
>
>  - Ben.
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au



signature.asc
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


Re: [OSM-talk-fr] "Vandalisme" à Gravelines de la part de l'OT

2019-12-03 Per discussione Yves P.
@Vincent
> heureusement qu'il y a les guillemets :) à vandalisme, ne rentrons pas dans 
> cette représentation lorsque c'est des gens qui sont maladroits, ne 
> connaissent pas, …
Je partage tes remarques, d’où les guillemets 

> Je bosse un peu avec le tourisme et franchement ceux sont des gens qui 
> connaissent super bien le territoire, atout non négligeable pour tenir les 
> données à jour, car ils en ont besoin à chaque saison !!!
Ils ont juste besoin de contributeurs « locaux » pour les guider.

—
Yves
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Edward Bainton
Hi all

General Elections Online

(hosted
at parliament.uk) have got a failed page where the Google map is overlaid
with "Development purposes only".

I was planning to suggest they use OSM instead.

Can anyone point me to the precise technical detail their webmaster will
need? Is it the wiki page, Deploying your own Slippy Map
?

Thanks,

Edward
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [OSM-talk-fr] Utilisation de données OSM sur france-cadastre.fr

2019-12-03 Per discussione Georges Dutreix via Talk-fr
Bonjour, 

On devine même un filigrane copyright "openmaptiles" sur les cartes
france-cadastre.fr. Mais il n'est pas fait pour sauter aux yeux. 

C'est peut-être à eux d'ajouter cette attribution, et pas uniquement une
référence à leaflet. 

Georges 

Le 2019-12-02 15:30, Frédéric Rodrigo a écrit :

> Je confirme que c'est bien des données OSM.
> Le fond OSM superposé est un rendu rester d'un style vectoriel 
> klokantech-basic basé sur OpenMapTiles : https://openmaptiles.org/styles/
> 
> Frédéric.
> 
> Le 02/12/2019 à 15:09, rainerU a écrit : 
> 
>> Bonjour,
>> 
>> J'ai contacté une commune (Arles-sur Tech, INSEE 66009) pour lever un doute 
>> sur le nom officiel de quelques rues. Dans leur réponse, il m'ont renvoyé 
>> vers un plan cadastral interactif sur leur site [1 [1]]. Ce plan est édité 
>> par FranceCadastre [2 [2]] et composé d'un calque cadastre superposé d'un 
>> calque voirie. Je soupçonne que le calque voirie est basé sur les données 
>> OSM car on y retrouve des erreurs d'orthographe présents dans OSM, par 
>> exemple "Domaine de la Batille" au lieu de "Domaine de la Batllie" sur ce 
>> chemin [3 [3]]. Les données OSM semblent être au niveau d'avant octobre 2017 
>> car des voies ajoutés à cette date ne figurent pas sur la carte, par exemple 
>> ce chemin [4 [4]].
>> 
>> Cette carte devrait donc porter une attribution OSM ce qui n'est pas le cas 
>> ni sur la carte ni ailleurs sur le site. Est-ce que cela vaut la peine de 
>> les contacter pour leur demander d'ajouter une attribution ? J'hésite car je 
>> l'ai fait récemment pour deux autres sites [5 [5]] [6 [6]], mais sans aucune 
>> réaction.
>> 
>> Rainer
>> 
>> [1] http://www.ville-arles-sur-tech.fr/plan-cadastre/
>> [2] https://france-cadastre.fr/cadastre/arles-sur-tech
>> [3] https://www.openstreetmap.org/way/449199916
>> [4] https://www.openstreetmap.org/way/534312613
>> [5] https://www.mairie-perpignan.fr/fr/carte/culture/patrimoine/monuments
>> [6] http://www.oph-perpignan.com/
>> 
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr

 

Links:
--
[1] http://www.ville-arles-sur-tech.fr/plan-cadastre/
[2] https://france-cadastre.fr/cadastre/arles-sur-tech
[3] https://www.openstreetmap.org/way/449199916
[4] https://www.openstreetmap.org/way/534312613
[5]
https://www.mairie-perpignan.fr/fr/carte/culture/patrimoine/monuments
[6] http://www.oph-perpignan.com/___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Quand Waze perturbe fortement le trafic

2019-12-03 Per discussione Xavier Cremaschi

https://www.francetvinfo.fr/elections/municipales/mon-maire/c-etait-devenu-apocalyptique-a-meudon-le-maire-a-debarrasse-une-rue-des-embouteillages-provoques-par-l-application-waze_3712737.html

Une histoire intéressante et assez terrible, sur comment des rues se 
retrouvent noyer sous le trafic routier dès lors qu'une appli GPS les 
désigne comme nouveau meilleur chemin...



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione David Woolley

On 03/12/2019 09:47, Edward Bainton wrote:


General Elections Online 
 (hosted 
at parliament.uk ) have got a failed page where 
the Google map is overlaid with "Development purposes only".


I was planning to suggest they use OSM instead.



The advantage to them of using Google is that Google provides the tile 
servers.  OSM tile servers aren't funded to support a mass market use 
like this, so the organisation will have to install and run their own 
tile servers.



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


[OSM-talk-fr] OSM et accessibilité: CDD et projets

2019-12-03 Per discussione Jean-Marie Favreau
Bonjour,

Depuis deux ans maintenant, nous menons à Clermont-Ferrand une activité de 
recherche autour de l'accessibilité spatiale pour les déficients visuels. On 
utilise bien évidemment OpenStreetMap comme source d'information géographique.

Nos activités en cours sont présentées sur le site Compas :
https://compas.limos.fr/

En particulier, nous démarrons en janvier 2020 un projet ANR qui durera sur 4 
ans, en collaboration avec un laboratoire de l'IGN, l'IRIT, et FeelObject. Le 
projet s'appelle ACTIVmap. Plus d'information à venir sur le site du projet, 
où nous publierons progressivement les offres de stage, puis de thèses :
http://activmap.limos.fr/

Nous venons également d'obtenir un budget pour recruter un développeur web sur 
6 mois, afin d'améliorer les outils de contribution sur les questions 
d'accessibilité :
https://compas.limos.fr/OD4M/offre-emploi/
N'hésitez pas à diffuser l'appel autour de vous, le poste est à Clermont-
Ferrand.

Nous serons bien sûr présents pour présenter nos travaux à State of the map 
France, si l'événement est planifié comme les autres années.

Au plaisir d'échanger sur ces projets !

-- 
Jean-Marie Favreau - http://jmfavreau.info



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] OSM et accessibilité: CDD et projets

2019-12-03 Per discussione Frédéric Rodrigo

Bonjour.

C'est une belle initiative que de vouloir investir sur l'amélioration 
des outils de contributions.


Je me permets toutes fois de lever une alerte sur une piste qui pourrait 
être envisagée à la vue de l'offre.


Il y a des déjà beaucoup de projets de fork d'iD mort nées dédiés à des 
thématiques. Le travail est à chaque fois perdu.


My 2cents.
Frédéric.


Le 03/12/2019 à 14:53, Jean-Marie Favreau a écrit :

Bonjour,

Depuis deux ans maintenant, nous menons à Clermont-Ferrand une activité de
recherche autour de l'accessibilité spatiale pour les déficients visuels. On
utilise bien évidemment OpenStreetMap comme source d'information géographique.

Nos activités en cours sont présentées sur le site Compas :
https://compas.limos.fr/

En particulier, nous démarrons en janvier 2020 un projet ANR qui durera sur 4
ans, en collaboration avec un laboratoire de l'IGN, l'IRIT, et FeelObject. Le
projet s'appelle ACTIVmap. Plus d'information à venir sur le site du projet,
où nous publierons progressivement les offres de stage, puis de thèses :
http://activmap.limos.fr/

Nous venons également d'obtenir un budget pour recruter un développeur web sur
6 mois, afin d'améliorer les outils de contribution sur les questions
d'accessibilité :
https://compas.limos.fr/OD4M/offre-emploi/
N'hésitez pas à diffuser l'appel autour de vous, le poste est à Clermont-
Ferrand.

Nous serons bien sûr présents pour présenter nos travaux à State of the map
France, si l'événement est planifié comme les autres années.

Au plaisir d'échanger sur ces projets !




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Andy Mabbett
On Tue, 3 Dec 2019 at 10:05, Gareth L  wrote:
>
> Potentially use 
> https://www.quora.com/How-can-I-put-OpenStreetMap-on-my-website

Fun though Quora is, I'd rather we pointed people at something that is
part of the OSM ecosystem;

   https://switch2osm.org/

which as created for this very purpose.

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Edward Bainton
I sense this is a good idea someone is sure to have had before and nixed -
or else it's not a good idea at all.

Is there any reason why OSM can't set up a user co-op (for instance) that
would offer a paid tileserver service?

On Tue, 3 Dec 2019 at 15:58, Mark Goodge  wrote:

>
>
> On 03/12/2019 15:48, Tom Hughes wrote:
> > The reason they're getting that error is almost certainly that they
> > aren't paying and they're either not passing an API key at all or
> > they're passing one that is for a different site.
> >
> > Most likely the site was developed before API keys were required
> > and has never been updated, but if they add a key they will almost
> > certainly exceed the free allowance and have to pay which is likely
> > why they haven't done so.
>
> They are passing an API key. But it doesn't seem to have billing enabled
> on it. Hence it won't be allowed to generate billable API calls.
>
> Mark
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Edward Bainton
I'll gladly help with the incorporation and structuring the finance. No
good at hardware or software though, and not sure what a sysadmin does...

So I take your point! I guess I wasn't really saying "someone should" but
"in principle could someone?"

On Tue, 3 Dec 2019 at 17:09, Richard Fairhurst  wrote:

> Edward Bainton wrote:
> > Is there any reason why OSM can't set up a user co-op (for instance)
> > that would offer a paid tileserver service?
>
> It's an idea that's been thrown around now and then. In OSM, of course,
> "why
> can't OSM..." is usually best rephrased as "hey, let's...". First person
> plural. Thanks for volunteering! :)
>
> (Alternatively, if you want someone else to do it for you, then you can
> consider voting for OSMF board candidates who are likely to pursue this. I
> would really caution against this, though, because OSM infrastructure is
> currently run by volunteers and partly served by donated hardware; turning
> that into an, at least partially, paid-for service would probably
> necessitate rethinking the sysadmin and hardware situation from the ground
> up.)
>
> Richard
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Edward Bainton
Interesting. Do they pay Google for the map and tileserver use (even if
they don't realise that's what they're paying for)?

Or rather, since they've clearly not updated whatever agreement they had
with Google for a while, *if* the map were functioning would that mean they
were paying Google?

On Tue, 3 Dec 2019 at 14:46, David Woolley 
wrote:

> On 03/12/2019 09:47, Edward Bainton wrote:
> >
> > General Elections Online
> > <
> https://electionresults.parliament.uk/#Cities%20of%20London%20and%20Westminster>
>  (hosted
>
> > at parliament.uk ) have got a failed page where
> > the Google map is overlaid with "Development purposes only".
> >
> > I was planning to suggest they use OSM instead.
> >
>
> The advantage to them of using Google is that Google provides the tile
> servers.  OSM tile servers aren't funded to support a mass market use
> like this, so the organisation will have to install and run their own
> tile servers.
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Tom Hughes

The reason they're getting that error is almost certainly that they
aren't paying and they're either not passing an API key at all or
they're passing one that is for a different site.

Most likely the site was developed before API keys were required
and has never been updated, but if they add a key they will almost
certainly exceed the free allowance and have to pay which is likely
why they haven't done so.

Tom

On 03/12/2019 15:21, Edward Bainton wrote:
Interesting. Do they pay Google for the map and tileserver use (even if 
they don't realise that's what they're paying for)?


Or rather, since they've clearly not updated whatever agreement they had 
with Google for a while, /if/ the map were functioning would that mean 
they were paying Google?


On Tue, 3 Dec 2019 at 14:46, David Woolley > wrote:


On 03/12/2019 09:47, Edward Bainton wrote:
 >
 > General Elections Online
 >


 (hosted

 > at parliament.uk  )
have got a failed page where
 > the Google map is overlaid with "Development purposes only".
 >
 > I was planning to suggest they use OSM instead.
 >

The advantage to them of using Google is that Google provides the tile
servers.  OSM tile servers aren't funded to support a mass market use
like this, so the organisation will have to install and run their own
tile servers.


___
Talk-GB mailing list
Talk-GB@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-gb


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb




--
Tom Hughes (t...@compton.nu)
http://compton.nu/

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Mark Goodge



On 03/12/2019 15:21, Edward Bainton wrote:
Interesting. Do they pay Google for the map and tileserver use (even if 
they don't realise that's what they're paying for)?


Or rather, since they've clearly not updated whatever agreement they had 
with Google for a while, /if/ the map were functioning would that mean 
they were paying Google?


Depending on how much usage it got, yes.

All Google Maps API usage now requires an API key. Each key has to be 
associated with a billing account, and all usage is chargeable. But each 
billing account gets $200 credit every calendar month, so if your total 
usage is less than that it remains free.


(There is still an embeddable non-API version of Google Maps, but it's 
very limited in functionality).


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Mark Goodge



On 03/12/2019 15:48, Tom Hughes wrote:

The reason they're getting that error is almost certainly that they
aren't paying and they're either not passing an API key at all or
they're passing one that is for a different site.

Most likely the site was developed before API keys were required
and has never been updated, but if they add a key they will almost
certainly exceed the free allowance and have to pay which is likely
why they haven't done so.


They are passing an API key. But it doesn't seem to have billing enabled 
on it. Hence it won't be allowed to generate billable API calls.


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Richard Fairhurst
Edward Bainton wrote:
> Is there any reason why OSM can't set up a user co-op (for instance) 
> that would offer a paid tileserver service?

It's an idea that's been thrown around now and then. In OSM, of course, "why
can't OSM..." is usually best rephrased as "hey, let's...". First person
plural. Thanks for volunteering! :)

(Alternatively, if you want someone else to do it for you, then you can
consider voting for OSMF board candidates who are likely to pursue this. I
would really caution against this, though, because OSM infrastructure is
currently run by volunteers and partly served by donated hardware; turning
that into an, at least partially, paid-for service would probably
necessitate rethinking the sysadmin and hardware situation from the ground
up.)

Richard




--
Sent from: http://gis.19327.n8.nabble.com/Great-Britain-f5372682.html

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-se] Flera skoloperatörer på samma skolområde - hur tagga?

2019-12-03 Per discussione Andreas Vilén
Det viktiga i frågan är att man inte ska mappa baserat på vad som är "lätt"
eller vad som ser bra ut på kartan, utan efter hur verkligheten är. En
annan grundregel är en tagg per objekt. Man ska alltså inte tagga en skola
flera gånger för att få med en yta om man inte kan reda ut skolans
utbredning i ett område med flera. Då blir det bra med en nod per skola,
fram till man har möjlighet att ta reda på varje skolas utformning.

MVH Andreas

On Mon, Dec 2, 2019 at 9:14 AM Lennart Romberg 
wrote:

> Tja, när jag insåg problemet så tänkte jag att det kanske fanns nån
> landuse=school som inte skulle komma i konflikt med amenity=school.
> Fast på wikin om landuse står att man ska tagga skolområden med amenity.
> / Lennart
>
> Den mån 2 dec. 2019 kl 08:43 skrev :
>
>> Gör så, det bliver bra. Skriv gärna en not på området om detta.
>> Vår tagging av skolor skulle som du märker behöva förbättras. Du är
>> hjärtligt välkommen med förslag till tagging listan.
>> Verkligheten är inte så sällan mera komplex än vår tagging klarar av att
>> återspegla.
>> Vi har en liknande skola här i Härnösand f.ö. där samma problemställning
>> finns.
>>
>> On December 2, 2019 8:27:04 AM GMT+01:00, Lennart Romberg <
>> lennart.romb...@gmail.com> wrote:
>>>
>>> Hm, två motsägande svar på samma fråga. Men det blir svårt att rita
>>> olika ytor per skoloperatör, de håller till i olika delar och olika
>>> våningar i samma byggnad.
>>> Jag är mer inne på att återställa skolområdet och sätta punktnoder på
>>> rimliga ställen i byggnaden för de olika operatörerna.
>>>
>>> Den mån 2 dec. 2019 kl 07:52 skrev Andreas Vilén :
>>> >
>>>
  Validatorn har rätt. Du kan rita en skolyta per skola och bör inte rita 
 en allmän för skolområde och en för varje skola.

  /Andreas

  Skickat från min iPhone

  2 dec. 2019 kl. 07:26 skrev pang...@riseup.net:

  Ignorera validatorn denna gång. Den validitetsregel är till för att fånga 
 upp tex parkering i parkering, m.m.
  mvh

  On December 2, 2019 7:22:59 AM GMT+01:00, Lennart Romberg 
  wrote:

>  I närheten av där jag bor finns ett skolkomplex där flera olika 
> skoloperatörer håller till. Området var taggat amenity=school och sen 
> finns noder för olika operatörer, också taggade med amenity=school. JOSM 
> varnar för "amenity inside amenity". Testade att ta bort det i mitt tycke 
> intetsägande området och bara behålla operatörerna men då försvann 
> färgrenderingen av området.
>
>  Tänkte man kunde göra nåt men "landuse" i stället för att både äta kakan 
> och ha den kvar, men på wikin om landuse står att skolområden ska taggas 
> "amenity".
>
>  Så hur gör man om man har flera skoloperatörer på samma skolområde?
>
 --
  Talk-se mailing list
  Talk-se@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-se
 --
  Talk-se mailing list
  Talk-se@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-se

>>> --
>>> Talk-se mailing list
>>> Talk-se@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-se
>>>
>>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [Talk-GB] Elections Online website - candidate for OSM?

2019-12-03 Per discussione Andy Townsend

On 03/12/2019 09:47, Edward Bainton wrote:

Hi all

General Elections Online 
 (hosted 
at parliament.uk ) have got a failed page where 
the Google map is overlaid with "Development purposes only".


I was planning to suggest they use OSM instead.

Can anyone point me to the precise technical detail their webmaster 
will need? Is it the wiki page, Deploying your own Slippy Map 
?



It depends very much on what they want to do.

At the highest level, they have a choice of two options - they can pay 
someone else to provide a service to them or they can create something 
themselves without using a third party.


IF someone else is providing a service the amount work that they need to 
do could be anything from nothing (like a new kitchen planned and 
installed for you for lots of £) to quite a lot (order some units from 
B and assemble it yourself).


Andy's already mentioned https://switch2osm.org/ - that has an 
(incomplete) providers list at https://switch2osm.org/providers/ .  Many 
of the organisations there will be able to help and will be able to help 
them and may offer different products for different levels of involvement.


There's also the "completely do it yourself" option, which is actually 
somewhat easier than the kitchen analogue of a pile of timber from 
Jewson's.  One option that would achieve this would need:


 * Some map tiles underneath (which don't need to be hugely detailed)
 * A way of displaying constituency boundaries on top
 * A way of handling "user clicks on constituency A, display details"

The hard part might actually be making the whole lot robust enough to 
cope with demand over the next couple of weeks.  What wouldn't be a good 
idea would be using an existing set of free-at-the-point-of-use map 
tiles (such as the ones at OpenStreetMap.org) and expecting them to 
"just cope" with the volume - see 
https://twitter.com/OSM_Tech/status/1122495446465810438 for what 
happened when the London Marathon did that (for completeness the 
relevant policy is at 
https://operations.osmfoundation.org/policies/tiles/ ).


If they did want to "completely do it themselves" then 
https://switch2osm.org/serving-tiles/manually-building-a-tile-server-18-04-lts/ 
will get them some raster map tiles, and 
https://switch2osm.org/using-tiles/ and the examples at (to pick just 
one example) https://leafletjs.com/ will allow them to create overlays 
over those, and allow people to click through for particular information.


With regards to the "hard part" they can restrict the map zoom to 
something that is not too high (enough so that constituencies are 
visible and clickable should be good enough) prerender tiles and cache 
them, but I'm sure they must have lots of familiarity with this sort of 
problem given that they already run a public and intermittently very 
busy website.


Best Regards,

Andy


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [OSM-talk-fr] dégradation notable d'OSM

2019-12-03 Per discussione osm . sanspourriel

Stéphane et David, vu que vous êtes ceux qui avez le plus investi dans
la vérification des modifications et que toutes les remarques sur les
modifications sont restées sans réponse :

http://resultmaps.neis-one.org/osm-discussion-comments?uid=2322305, je
crois que vous êtes les mieux placés pour demander un blocage au DWG le
temps que cette personne réponde à vos interrogations.

Je vois aussi parmi les métriques : Osmose issues
: Level 1=96, Level
2=999, Level 3=1870.

Oui près de 100 erreurs de niveau 1.

Sinon effectivement j'ai compris pourquoi OSMand déconnait : il ne passe
pas par où passent OSRM, GraphHooper ou Bibi : il préfère doubler la
distance que de prendre un raccourci par une route moins importante.
Donc c'est une question de poids de certains éléments pour le calcul du
trajet et non un mauvais comptage des sorties.

N. B. : Stéphane en fait je vois que tu le suis (subis !) depuis un
moment, quant au bout d'une "certain temps" le contributeur ne répond
pas et continue ses mauvaises pratiques, ça ne sert à rien de continuer
sur le même mode il faut essayer un autre canal.

Jean-Yvon

Le 02/12/2019 à 21:09, David Crochet - david.croc...@free.fr a écrit :

Bonjour

Le 29/11/2019 à 21:46, osm.sanspourr...@spamgourmet.com a écrit :

Je pense naïvement que si c'était si mauvais on s'en serait aperçu
plus tôt. mais pas sûr du tout.



C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et
il vient seulement d'y contribuer et mal, et c'est en regardant
l'historique que j'ai vu qu'il cartographier mal depuis un moment.

Cordialement

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [Talk-se] Ska adresser ha land, stad, postnummer och allt?

2019-12-03 Per discussione Andreas Vilén
Hej!

För några år sedan genomförde jag en stor adressimport för Helsingborgs
kommun. Utöver detta har jag mappat otaliga adresser manuellt, har ett
intresse för adressättning och jag arbetar även med adresser i yrkeslivet.
Här är några av mina erfarenheter som jag samlat på mig genom åren.

1) Officiella adresser är fler än skyltade adresser
Med detta menar jag att i officiella register är principen att varje entré
får en adress. Olika kommuner är olika strikta med detta, men i kommuner
som följer detta strikt innebär det att varenda sidoentré, butik, miljöhus
osv får en egen adress. Det innebär även i vissa kommuner att alla
hörntomter har dubbla adresser, ibland tom tre eller fyra baserat på
kvarterens utformning. Dessa finns naturligtvis med i officiella dataset,
men är väldigt svåra att bekräfta på marken och inte alltid vettiga att ha
med i OSM-databasen.

2) Officiella adresser stämmer inte alltid överens med skyltade adresser
Även detta är något jag lärt mig inom yrkeslivet framför inom OSM, men båda
har gett mig insikter om detta. Adresser byts av naturen ut då och då. Ett
hus kan ha en adress satt för decennier sedan. Huset kan ha byggts om, en
entré flyttats och plötsligt får huset en ny adress, men de boende ändrar
inte på sin skylt och en mappare som går förbi mappar naturligtvis what's
on the ground, dvs det som står på skylten. Detta är rimligt och så OSM ska
fungera. Här är det närmast en filosofisk fråga om den officiella adressen
ska skriva över vad som faktiskt finns skyltat. Detta är en fråga som vi
även många gånger diskuterat på jobbet och aldrig riktigt kommit till en
ordentlig slutsats.

3) Officiella adresser ligger inte alltid rätt
För en tid sedan blev jag, även då på jobbet, uppmärksammad om att
adresserna i det här området var fel:
https://www.openstreetmap.org/changeset/74756989 Eftersom det ligger i
närheten av mig gick jag dit och tog en titt. Lo and behold, i princip alla
adresser var felmappade. Jag fick byta plats på nästan alla A och B. Jag
fick också skämmas lite eftersom jag själv mappat detta fel en gång i
tiden, baserat på Lunds kommuns officiella data som vi hade möjlighet att
kartera av. Utöver att det kan bli så här dramatiskt fel kan det också bli
mindre fel såsom adresser som kommer i fel ordning (det var flera ACB och
liknande i Helsingborg, som jag dubbelkollat IRL. Vissa stämde, andra var
fel). I vissa kommuner har man missat att koordinatsätta adresser
ordentligt. I Svedala kommun har man exempelvis (av misstag?) koordinatsatt
alla adresser per radhus i ett område på exakt samma position, istället för
där respektive radhus befinner sig. Om man då ersätter redan mappad data
med importerad finns risken att det blir väldigt fel.

4) Det finns udda "nödfallsadresser"
Olika kommuner har olika policy, men exempelvis Helsingborgs kommun
adressätter alla lekplatser, Lunds kommun adressätter parker, Vellinge
kommun adressätter offentliga toaletter, osv. Allt detta är vettigt utifrån
ett perspektiv att en ambulans ska hitta rätt och liknande, men är i
princip omöjligt att bekräfta on the ground. Dessa adresser är inte
nödvändigtvis något vi ska undvika (jag har behållit alla lekplatsadresser
i Helsingborg) men kan leda till "clutter" och går som sagt inte att
kontrollera.

5) Bostadsområden adressätts långt innan de byggs
Ofta sätter kommuner adresser långt innan ett bostadsområde byggts, eller
ens har beslutat om att det ska byggas. Ett exempel i Vellinge kommun där
ett område överklagats så många gånger att det troligen inte blir av. Detta
området har varit adressatt åtminstone sedan början av 2010-talet. I
Helsingborgs kommun adressatte man ett område där man skulle bygga
flyktingbostäder, men efter att flyktingvågen minskade behövdes inte
området längre, men adresserna ligger kvar. Sådana här adresser finns det
ingen större mening med att ha med i OSM, och är väldigt märkliga att stöta
på när området är åker eller skog och det inte ens verkar finnas planer på
att bebygga det.

6) Det tar tid att genomföra en adressimport
När jag importerade adresser i Helsingborgs kommun använde jag det här
användarkontot: https://www.openstreetmap.org/user/Grillo_import. Mitt
första changeset, ett mindre test, skapades 21 januari 2017:
https://www.openstreetmap.org/changeset/45345277, det sista 9 april samma
år: https://www.openstreetmap.org/changeset/47602913. Då arbetade jag med
detta nästan dagligen. Totalt 161 noter skapades varav 24 fortfarande är
öppna:
https://ent8r.github.io/NotesReview/expert/?limit=500=Grillo_import=true
Flera av dem har visat sig svåra eller omöjliga att lösa, eftersom det
handlar om adresser inne på låsta innergårdar (där en import är till stor
hjälp, men datan är svår att bekräfta om man inte bor i huset eller har
något ärende dit).

7) Vi bör respektera det arbete som lagts på att lägga in adresser manuellt
Detta kanske kan verka lite fuzzy och feelgood, men många människor har
lagt många timmar på att lägga in adresser manuellt i OSM. Jag tillhör 

[Talk-bo] Lago Poopó nuevo contorno

2019-12-03 Per discussione Marco Antonio
Hola,

Hace un mes más o menos estuve editando alrededor del Lago Poopó, bien
conocido últimamente  por haberse secaso casi completamente. utilicé
imagenes maxar premium parece 2018 diciembre...

https://www.openstreetmap.org/relation/10231018#map=10/-18.8075/-66.7955

Ahora ya se actualizó el render a todo nivel y es posible ver el
controno del agua máxima, estacional, y los lodos salitrosos que se
secaron como parte del antiguo límite máximo

Le puse que no hay lanchas a motor, porque no encontré mucha
referencia a este tipo sino más bien botes y canoas que serían los
similares a los botes de totoras

También mejoré las islas internas y los flujos de los ríos, estaba mal
el flujo hacia el salar de coipasa

Un dato interesante que encontré leyendo por ahí, es que el poopó está
en proceso de convertirse salar O_O

Abrazos,

Marco Antonio

___
Talk-bo mailing list
Talk-bo@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-bo


Re: [OSM-talk-fr] dégradation notable d'OSM

2019-12-03 Per discussione Philippe Verdy
Attention: les erreurs associées à un utilisateur ne sont pas de son fait
pour la plupart, cela se produit notamment indirectement pour des
modifications locales (correctes) de relations dont d'autres membres
avaient déjà des problèmes ailleurs mais n'ont pas été modifiés pour
autant. Cas typique:
- les relations de transport où on peut trouver des intersections
route/rivière (sans pont ou tunnel) ou route/bâtiment: il y en a encore des
tas dans la base et pas attribuées à l'utilisateur correct ayant créé ces
intersections.
- des tags laissés de côté mais pas retirés/modifiés car cela aurait
conduit à des modifs en cascade et des changesets gigantesque pour fouiller
chacune des dépendances sur des problèmes très éloignés de la zone qui a
été réellement modifiée.
Bref concernant les erreurs de "niveau1" sur les relations, ce n'est pas si
critique que ça, sauf concernant la géométrie des relations elles-mêmes
(chemins membres polygones qui doivent être fermés, et tronçons manquant
sur les relations linéaires (mais bien souvent les anomalies viennent de
tronçons qui étaioent déjà retirés ailleurs, et les longues relations de
transport sont souvent concernées par ces tronçons mal reliés quand
quelqu'un d'autre a redessiné un carrefour mais omis de relier les segments
de connexion. L'utilisateur suivant qui vient faire une modif ailleurs mais
ne touche pas à la géométrie ou fait une modif correcte ailleurs ne verra
pas toujours qu'il manque des éléments (et faire le tri pour corriger ce
qui manque ailleurs prend un temps fou: l'erreur était déjà là, elle
subsiste, mais l'attribution donnée au dernier modificateur n'indique pas
qu'il est responsable de cette erreur qui était déjà là avant lui.
N'importe qui travaillant beaucoup sur OSM et correctement se voit
automatiquement "attribué" ensuite des erreurs sans même rien toucher, à
cause des dépendances sur d'autres objets qu'il n'a même pas touché
lui-même mais ont été touchés par d'autres.
Bref ce n'est qu'une indication mais pour le détail il faut revoir
l'historique et visiblement peu de gens savant interpréter les historiques
(même les outils automatiques ont du mal à s'y retrouver tellement c'est
compliqué): c'est un problème inhérent au modèle de données OSM. Là pas le
choix il faut s'y coller erreur par erreur, localement mais celui qui s'y
colle et vient corriger chacune une par une se voit ensuite attribuer des
erreurs qu'il n'a pas encore traitées mais concernant d'autres problèmes
ailleurs sur les mêmes relations touchées.
Bref ne pas trope se fier aux attributions d'auteurs qui n'indiquent que
l'auteur de la dernière modif effectuée sur un objet, mais rarement
l'auteur de la modif plus ancienne qui a produit cette erreur. C'est pour
ça qu'on ne devrait pas appeler cela "erreur" mais juste "signalement. Oui
il y a un problème, mais rarement de l'auteur indiqué, l'outil de neis-one
ne faisant pas dans le détail pour fouiller les hiostoriques des modifs
pour en trouver l'origine réelle avec l'analyse poussée des diffs.


Le mar. 3 déc. 2019 à 21:16,  a écrit :

> Stéphane et David, vu que vous êtes ceux qui avez le plus investi dans la
> vérification des modifications et que toutes les remarques sur les
> modifications sont restées sans réponse :
>
> http://resultmaps.neis-one.org/osm-discussion-comments?uid=2322305, je
> crois que vous êtes les mieux placés pour demander un blocage au DWG le
> temps que cette personne réponde à vos interrogations.
>
> Je vois aussi parmi les métriques : Osmose issues
> : Level 1=96, Level 2=999, 
> Level
> 3=1870.
>
> Oui près de 100 erreurs de niveau 1.
>
> Sinon effectivement j'ai compris pourquoi OSMand déconnait : il ne passe
> pas par où passent OSRM, GraphHooper ou Bibi : il préfère doubler la
> distance que de prendre un raccourci par une route moins importante. Donc
> c'est une question de poids de certains éléments pour le calcul du trajet
> et non un mauvais comptage des sorties.
>
> N. B. : Stéphane en fait je vois que tu le suis (subis !) depuis un
> moment, quant au bout d'une "certain temps" le contributeur ne répond pas
> et continue ses mauvaises pratiques, ça ne sert à rien de continuer sur le
> même mode il faut essayer un autre canal.
>
> Jean-Yvon
> Le 02/12/2019 à 21:09, David Crochet - david.croc...@free.fr a écrit :
>
> Bonjour
>
> Le 29/11/2019 à 21:46, osm.sanspourr...@spamgourmet.com a écrit :
>
> Je pense naïvement que si c'était si mauvais on s'en serait aperçu plus
> tôt. mais pas sûr du tout.
>
>
>
> C'est achavi qui m'a donné " l'alerte " car je surveille une zone, et il
> vient seulement d'y contribuer et mal, et c'est en regardant l'historique
> que j'ai vu qu'il cartographier mal depuis un moment.
>
> Cordialement
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list

Re: [Talk-se] Ska adresser ha land, stad, postnummer och allt?

2019-12-03 Per discussione pangose
Hej Andreas

Tusen tack för alla detaljer. 

Jag hade hoppats att datan var bättre kvalitet än vad du berättar här.

Jag har inte kollat Gävles data än.

Vi får nog ta det väldigt försiktigt om det du beskriver även stämmer på Gävle 
och övriga landets data.

Jag har själv lagt in en del adresser i Härnösand, men det finns mycket kvar 
att göra. Jag  är sugen på att göra nått åt det och att mappa efter ett lager 
med adressdata utan att förstöra dem tiotusentals adresser vi redan har låter 
som en bättre väg fram.

När jag lagt till adresser har jag oftast bara behövt kolla några få hus per 
väg och sedan kunnat räkna ut resten och placera dem effektivt med ett josm 
plugin.
Om ett datalager finns bliver det ju ännu enklare för då ser man kanske hur dem 
ligger vid korsningarna utan att behöva kolla överallt.

Metoden jag här beskriver gör att automatiska uppdateringar bliver omöjliga,  
MEN vi skulle kunna göra difflager så alla adresser från 2019 är gröna och alla 
som ändrades i 2020 är röda. Då är det bara att kolla alla röda vid varje 
datasläpp.

WDYT?

Mvh
pangoSE

On December 3, 2019 8:08:42 PM GMT+01:00, "Andreas Vilén" 
 wrote:
>Hej!
>
>För några år sedan genomförde jag en stor adressimport för Helsingborgs
>kommun. Utöver detta har jag mappat otaliga adresser manuellt, har ett
>intresse för adressättning och jag arbetar även med adresser i
>yrkeslivet.
>Här är några av mina erfarenheter som jag samlat på mig genom åren.
>
>1) Officiella adresser är fler än skyltade adresser
>Med detta menar jag att i officiella register är principen att varje
>entré
>får en adress. Olika kommuner är olika strikta med detta, men i
>kommuner
>som följer detta strikt innebär det att varenda sidoentré, butik,
>miljöhus
>osv får en egen adress. Det innebär även i vissa kommuner att alla
>hörntomter har dubbla adresser, ibland tom tre eller fyra baserat på
>kvarterens utformning. Dessa finns naturligtvis med i officiella
>dataset,
>men är väldigt svåra att bekräfta på marken och inte alltid vettiga att
>ha
>med i OSM-databasen.
>
>2) Officiella adresser stämmer inte alltid överens med skyltade
>adresser
>Även detta är något jag lärt mig inom yrkeslivet framför inom OSM, men
>båda
>har gett mig insikter om detta. Adresser byts av naturen ut då och då.
>Ett
>hus kan ha en adress satt för decennier sedan. Huset kan ha byggts om,
>en
>entré flyttats och plötsligt får huset en ny adress, men de boende
>ändrar
>inte på sin skylt och en mappare som går förbi mappar naturligtvis
>what's
>on the ground, dvs det som står på skylten. Detta är rimligt och så OSM
>ska
>fungera. Här är det närmast en filosofisk fråga om den officiella
>adressen
>ska skriva över vad som faktiskt finns skyltat. Detta är en fråga som
>vi
>även många gånger diskuterat på jobbet och aldrig riktigt kommit till
>en
>ordentlig slutsats.
>
>3) Officiella adresser ligger inte alltid rätt
>För en tid sedan blev jag, även då på jobbet, uppmärksammad om att
>adresserna i det här området var fel:
>https://www.openstreetmap.org/changeset/74756989 Eftersom det ligger i
>närheten av mig gick jag dit och tog en titt. Lo and behold, i princip
>alla
>adresser var felmappade. Jag fick byta plats på nästan alla A och B.
>Jag
>fick också skämmas lite eftersom jag själv mappat detta fel en gång i
>tiden, baserat på Lunds kommuns officiella data som vi hade möjlighet
>att
>kartera av. Utöver att det kan bli så här dramatiskt fel kan det också
>bli
>mindre fel såsom adresser som kommer i fel ordning (det var flera ACB
>och
>liknande i Helsingborg, som jag dubbelkollat IRL. Vissa stämde, andra
>var
>fel). I vissa kommuner har man missat att koordinatsätta adresser
>ordentligt. I Svedala kommun har man exempelvis (av misstag?)
>koordinatsatt
>alla adresser per radhus i ett område på exakt samma position, istället
>för
>där respektive radhus befinner sig. Om man då ersätter redan mappad
>data
>med importerad finns risken att det blir väldigt fel.
>
>4) Det finns udda "nödfallsadresser"
>Olika kommuner har olika policy, men exempelvis Helsingborgs kommun
>adressätter alla lekplatser, Lunds kommun adressätter parker, Vellinge
>kommun adressätter offentliga toaletter, osv. Allt detta är vettigt
>utifrån
>ett perspektiv att en ambulans ska hitta rätt och liknande, men är i
>princip omöjligt att bekräfta on the ground. Dessa adresser är inte
>nödvändigtvis något vi ska undvika (jag har behållit alla
>lekplatsadresser
>i Helsingborg) men kan leda till "clutter" och går som sagt inte att
>kontrollera.
>
>5) Bostadsområden adressätts långt innan de byggs
>Ofta sätter kommuner adresser långt innan ett bostadsområde byggts,
>eller
>ens har beslutat om att det ska byggas. Ett exempel i Vellinge kommun
>där
>ett område överklagats så många gånger att det troligen inte blir av.
>Detta
>området har varit adressatt åtminstone sedan början av 2010-talet. I
>Helsingborgs kommun adressatte man ett område där man skulle bygga
>flyktingbostäder, men efter att flyktingvågen minskade behövdes 

Re: [Talk-se] Flera skoloperatörer på samma skolområde - hur tagga?

2019-12-03 Per discussione Lennart Romberg
Jag tycker att det logiska i det här fallet skulle vara att tagga hela
skolområdet (typ ett kvarter) med landuse=school och sedan varje
"skoloperatör" med en nod (eller byggnad) beroende på var den håller till.
Nu säger ju landuse-wikin (
https://wiki.openstreetmap.org/wiki/Landuse#How_to_tag_land_use ) att man
ska använda "amenity=school" för området så då gjorde jag det, får en
varning för varje nod, men ser inget bättre alternativ.
Handlar om
https://www.openstreetmap.org/changeset/77833076#map=16/59.3729/13.5003

/ Lennart


Den tis 3 dec. 2019 kl 19:30 skrev Andreas Vilén :

> Det viktiga i frågan är att man inte ska mappa baserat på vad som är
> "lätt" eller vad som ser bra ut på kartan, utan efter hur verkligheten är.
> En annan grundregel är en tagg per objekt. Man ska alltså inte tagga en
> skola flera gånger för att få med en yta om man inte kan reda ut skolans
> utbredning i ett område med flera. Då blir det bra med en nod per skola,
> fram till man har möjlighet att ta reda på varje skolas utformning.
>
> MVH Andreas
>
> On Mon, Dec 2, 2019 at 9:14 AM Lennart Romberg 
> wrote:
>
>> Tja, när jag insåg problemet så tänkte jag att det kanske fanns nån
>> landuse=school som inte skulle komma i konflikt med amenity=school.
>> Fast på wikin om landuse står att man ska tagga skolområden med amenity.
>> / Lennart
>>
>> Den mån 2 dec. 2019 kl 08:43 skrev :
>>
>>> Gör så, det bliver bra. Skriv gärna en not på området om detta.
>>> Vår tagging av skolor skulle som du märker behöva förbättras. Du är
>>> hjärtligt välkommen med förslag till tagging listan.
>>> Verkligheten är inte så sällan mera komplex än vår tagging klarar av att
>>> återspegla.
>>> Vi har en liknande skola här i Härnösand f.ö. där samma problemställning
>>> finns.
>>>
>>> On December 2, 2019 8:27:04 AM GMT+01:00, Lennart Romberg <
>>> lennart.romb...@gmail.com> wrote:

 Hm, två motsägande svar på samma fråga. Men det blir svårt att rita
 olika ytor per skoloperatör, de håller till i olika delar och olika
 våningar i samma byggnad.
 Jag är mer inne på att återställa skolområdet och sätta punktnoder på
 rimliga ställen i byggnaden för de olika operatörerna.

 Den mån 2 dec. 2019 kl 07:52 skrev Andreas Vilén :
 >

>  Validatorn har rätt. Du kan rita en skolyta per skola och bör inte rita 
> en allmän för skolområde och en för varje skola.
>
>  /Andreas
>
>  Skickat från min iPhone
>
>  2 dec. 2019 kl. 07:26 skrev pang...@riseup.net:
>
>  Ignorera validatorn denna gång. Den validitetsregel är till för att 
> fånga upp tex parkering i parkering, m.m.
>  mvh
>
>  On December 2, 2019 7:22:59 AM GMT+01:00, Lennart Romberg 
>  wrote:
>
>>  I närheten av där jag bor finns ett skolkomplex där flera olika 
>> skoloperatörer håller till. Området var taggat amenity=school och sen 
>> finns noder för olika operatörer, också taggade med amenity=school. JOSM 
>> varnar för "amenity inside amenity". Testade att ta bort det i mitt 
>> tycke intetsägande området och bara behålla operatörerna men då försvann 
>> färgrenderingen av området.
>>
>>  Tänkte man kunde göra nåt men "landuse" i stället för att både äta 
>> kakan och ha den kvar, men på wikin om landuse står att skolområden ska 
>> taggas "amenity".
>>
>>  Så hur gör man om man har flera skoloperatörer på samma skolområde?
>>
> --
>  Talk-se mailing list
>  Talk-se@openstreetmap.org
>  https://lists.openstreetmap.org/listinfo/talk-se
> --
>  Talk-se mailing list
>  Talk-se@openstreetmap.org
>  https://lists.openstreetmap.org/listinfo/talk-se
>
 --
 Talk-se mailing list
 Talk-se@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-se

 ___
>>> Talk-se mailing list
>>> Talk-se@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-se
>>>
>> ___
>> Talk-se mailing list
>> Talk-se@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-se
>>
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
>
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se


Re: [OSM-talk-fr] dégradation notable d'OSM

2019-12-03 Per discussione Philippe Verdy
Ceci dit on voit tout de même des infos pertinentes concernant les erreurs
de cet utilisateur, notamment avec des détections assez précises comme
"relations à 1 seul membre" qui indique qu'il a retracé par exemple des
carrefours mais omis les relations de restriction d'accès, vraiment très
locales): il découpe n'importe comment, ne se soucient pas du tout de
remettre les relations d'aplomb: il retrace, supprime ce qui le gêne ou
fait doublon pour lui sans jamais se préoccuper des dépendances de ce qu'il
supprime. Au passage il omet pas mal de tags ou les remet mal sur les
objets de remplacement.
Il ne se soucie pas non plus de la précision et ses tracés sont vite faits
à la louche, très anguleux, de fait inévitablement ils vont entrer en
intersection avec des bâtiments dans les villes aux rues étroites.
Le résultat c'est une carte de Caen qui maintenant ressemble à un patchwork
découpé à grand coup de ciseaux, il n'y a plus aucun angle correct, ce
n'est plus un plan, c'est un schéma. Visiblement il se fouit pas mal de la
précision. On se retrouve aussi avec des équipements du mauvais côté de la
rue. Je pense qu'il utilise l'éditeur à très mauvais escient et va beaucoup
trop vite, qu'il manque de formation. C'est acceptable pour des
utilisateurs occasionnels, mais là avec son usage fréquent, il s'attaque à
des choses qu'il ne maitrise vraiment pas assez pour faire des modifs aussi
massives et fréquentes que les autres ont du mal à suivre ensuite pour
corriger ses nombreux "oublis". Mais comme il fait tout dans son coin et ne
paarticipe à aucune discussion, il n'apprend rien de plus. On doit donc le
freiner et lui apprendre à collaborer et écouter les enseignements. Sinon
il ne s'améliorera jamais et laisse tous les dégâts à la charge des autres
qui doivent ensuite passer beaucoup plus de temps pour corriger chacune de
ses erreurs que le temps très rapide avec lequel il modifie quantité
d'objets.
Pour des cas comme ça, il serait souhaitable qu'OSM dispose d'une option
permettant de freiner un utilisateur en limitant le nombre de changesets et
d'objets: s'il y a trop d'erreurs laissées derrière, il vaudrait mieux
avoir un moyen de dire que des modifs hors d'une zone précise sont
proscrite, afin de l'obliger à passer du temps à corriger ce qui reste en
fonction d'un certain nombre de rapports d'anomalies ou de signalements
laissés sans réponse de sa part.


Le mar. 3 déc. 2019 à 23:08, Philippe Verdy  a écrit :

> Attention: les erreurs associées à un utilisateur ne sont pas de son fait
> pour la plupart, cela se produit notamment indirectement pour des
> modifications locales (correctes) de relations dont d'autres membres
> avaient déjà des problèmes ailleurs mais n'ont pas été modifiés pour
> autant. Cas typique:
> - les relations de transport où on peut trouver des intersections
> route/rivière (sans pont ou tunnel) ou route/bâtiment: il y en a encore des
> tas dans la base et pas attribuées à l'utilisateur correct ayant créé ces
> intersections.
> - des tags laissés de côté mais pas retirés/modifiés car cela aurait
> conduit à des modifs en cascade et des changesets gigantesque pour fouiller
> chacune des dépendances sur des problèmes très éloignés de la zone qui a
> été réellement modifiée.
> Bref concernant les erreurs de "niveau1" sur les relations, ce n'est pas
> si critique que ça, sauf concernant la géométrie des relations elles-mêmes
> (chemins membres polygones qui doivent être fermés, et tronçons manquant
> sur les relations linéaires (mais bien souvent les anomalies viennent de
> tronçons qui étaioent déjà retirés ailleurs, et les longues relations de
> transport sont souvent concernées par ces tronçons mal reliés quand
> quelqu'un d'autre a redessiné un carrefour mais omis de relier les segments
> de connexion. L'utilisateur suivant qui vient faire une modif ailleurs mais
> ne touche pas à la géométrie ou fait une modif correcte ailleurs ne verra
> pas toujours qu'il manque des éléments (et faire le tri pour corriger ce
> qui manque ailleurs prend un temps fou: l'erreur était déjà là, elle
> subsiste, mais l'attribution donnée au dernier modificateur n'indique pas
> qu'il est responsable de cette erreur qui était déjà là avant lui.
> N'importe qui travaillant beaucoup sur OSM et correctement se voit
> automatiquement "attribué" ensuite des erreurs sans même rien toucher, à
> cause des dépendances sur d'autres objets qu'il n'a même pas touché
> lui-même mais ont été touchés par d'autres.
> Bref ce n'est qu'une indication mais pour le détail il faut revoir
> l'historique et visiblement peu de gens savant interpréter les historiques
> (même les outils automatiques ont du mal à s'y retrouver tellement c'est
> compliqué): c'est un problème inhérent au modèle de données OSM. Là pas le
> choix il faut s'y coller erreur par erreur, localement mais celui qui s'y
> colle et vient corriger chacune une par une se voit ensuite attribuer des
> erreurs qu'il n'a pas encore traitées mais concernant d'autres