Re: [OSM-ja] トンネルの銘板

[info]

muramotoさん

そこまで言われて初めて気づきました。「発注者」は英語で「owner」ですね。
でも tunnel:owner=* だと、どうしても所有者のイメージです。
muramotoさん案のとおり tunnel:inscription:owner=* が現場表記を忠実に
表現した感があっていいのではないでしょうか。
もしくは tunnel:construction:owner=* か。
tunnel:construction:operatorは、私も施工者をイメージしました。

** Ras and Road **
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Philippe Verdy]

J'ai tendance à penser que si la route ne concerne qu'une seule compétition
un jour donné pendant juste quelques heures, ce n'est pas une route d'usage
général et que cet objet temporaire n'a pas trop la place dans OSM, sinon
on n'a pas fini d'étaler les circuits des nombreuses compétitions sportives
qui bougent sans arrêt, et fréquemment (parfois même plusieurs fois par an
si l'épreuve a lieu plusieurs fois dans l'année).

Je pense que cela devrait être plutôt dans des bases externes ou des cartes
dérivées (uMap, cartes sur Commons) liées à des articles de fond portant
sur l'épreuve elle-même, ses compétiteurs, ses résultats, ses analyses et
autres pronostics. La carte ne sera de toute façon pas assez détaillée non
plus pour les compétiteurs qui ont leurs propres roadbooks annotés de façon
personnels et leurs programmes d'entrainement.

Certaines épreuves sont notables (Tour de France, Olympisme, compétitions
officielles nationales ou internationales) mais il y a tellement de sports
et de fédérations concernées, et aussi des problème de droit qu'on ne va
pas reproduire le fiasco des actuels circuits de grande randonnée et la
galère que cela représente.

Même pour le public de ces épreuves la carte a un intérêt vraiment trop
limité et n'est pas suffisante pour les accès et les perturbations qu'il y
a autour (dont la plupart sont imprévues et se décident sur place et même
en cours d'épreuve). La seule bonne source d'information valable c'est
l'organisateurs de l'épreuve, et sinon des articles de presse, les deux
étant des sources protégées la plupart du temps.


Le ven. 12 oct. 2018 à 17:27, jabali  a écrit :

> Je viens de tomber sur ceci
> https://www.openstreetmap.org/relation/8595631
> vous en pensez quoi ?
> Itinéraire cyclable ?
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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

Re: [OSM-ja] 糸魚川市オルソ写真のトレース許諾がとれました

[tomoya muramoto]

いいだ様

糸魚川市様から許諾をとっていただき、ありがとうございます。

糸魚川市様に対してもこの場を借りて感謝申し上げます。

で、ちょっとだけですが早速トレースしてみました。
解像度はBing<<地理院ort<<糸魚川市ort
と圧倒的ですね。

鉄道レールもはっきり見えるので、レール分岐マイクロマッピングもできそうな雰囲気です。

ありがとうございました。

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

Re: [OSM-ja] place=city_block

[tomoya muramoto]

>block_numberが日本だけで使われているのであればよいのですが、
>実際には、フィリピンの一部（まだストリートが無い振興開拓地で、まだ開発中のところ）でも使われている、と聞いています。
>なので、JPは、あったほうがよいかな、と思っています。

日本のplace=neighbourhoodと海外のplace=neighbourhoodは定義が異なるように、
日本のref:block_numberと海外のref:block_numberの定義が異なっていても問題がないように私は思います。

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

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Florimond Berthoux]

Si j'ai cité le wiki pour la Key:route c'est pour bien noter que le fait
que l'itinéraire soit officiel à une organisation ou soit balisé sur le
terrain n'est pas déterminant.
Ce qui compte c'est : en allant voir sur le terrain, y-a-t-il des
cyclotouristes qui prennent cette itinéraire régulièrement ?
C'est probablement difficile à vérifier.

Un tenancier d'auberge sur le chemin peut-il nous renseigner ? ;)

Le ven. 12 oct. 2018 à 19:32, Pierre-Yves Mevel  a
écrit :

> Je suis tombé dessus en voulant faire une carte des itinéraires cyclables
> de Fougères et j'avoue que j'ai bien failli tout supprimer. Ce qui m'a fait
> hésiter est que le contributeur est assez expérimenté (
> https://www.openstreetmap.org/user/Jean-Pierre%20Rondeau). En tout cas,
> sur le terrain, il n'y a aucun balisage et je pense aussi que ce genre
> d'information devrait se trouver ailleurs que sur OSM.
>
> Le ven. 12 oct. 2018 à 19:11, Gwenaël Jouvin 
> a écrit :
>
>> Bonsoir,
>>
>> Merci d’amener ce sujet ici : en préparant une rando il y a quelques
>> semaines, j’étais surpris que brouter m’emmène par l’ancienne nationale 164
>> (une route vraiment pas drôle pour rouler à vélo)… il a simplement suivi la
>> relation indiquée comme ncn !
>>
>> Pour moi c’est une erreur : le Paris – Brest – Paris est une épreuve
>> cycliste et pas du tout un itinéraire balisé par une institution comme le
>> sont la Véloscénie ou la Scandibérique :
>> https://www.openstreetmap.org/relation/7163558
>> https://www.openstreetmap.org/relation/2345035
>>
>> Peut-être faudrait-il contacter ses auteurs afin de comprendre leur
>> motivation ?
>>
>> À mon avis, il faudra au minimum retirer l’attribut network=ncn car il
>> est ici inapproprié.
>>
>>
>> Le 12/10/2018 à 17:26, jabali a écrit :
>> > Je viens de tomber sur ceci
>> > https://www.openstreetmap.org/relation/8595631
>> > vous en pensez quoi ?
>> > Itinéraire cyclable ?
>> >
>> >
>> >
>> >
>> >
>> > --
>> > Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>> >
>> > ___
>> > 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
>>
> ___
> 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-GB] Fwd: Open MasterMap progress since Policy Announcement

[Mark Goodge]

On 12/10/2018 21:32, Nick Whitelegg wrote:


Interesting. "Detailed path network" in particular looks interesting, is 
this rights of way or physical paths on the ground I wonder?


It would be physical paths on the ground.

Mark

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

Re: [Talk-GB] Fwd: Open MasterMap progress since Policy Announcement

[Nick Whitelegg]

Interesting. "Detailed path network" in particular looks interesting, is this 
rights of way or physical paths on the ground I wonder?


Nick



From: Rob Nickerson 
Sent: 12 October 2018 19:35:16
To: Talk-GB
Subject: [Talk-GB] Fwd: Open MasterMap progress since Policy Announcement

Hi all,

Recap: The Ordnance Survey are working with the new Geospatial Commission on 
opening up access to more of their data.

Today this email landed in OSM UK's inbox (you too can subscribe for updates). 
It is a tad confusing because there are releasing things under two different 
routes (free up to a threshold, and fully free under OGL open data licence). 
This is explained on their website [1] but hidden under a FAQ. Here is the text:


OS MasterMap will be made available for free, up to a threshold, through an 
API. This will include:

  *   OS MasterMap Topography Layers, including building heights and functional 
sites
  *   OS MasterMap Greenspace Layer
  *   OS MasterMap Highways Network
  *   OS MasterMap Water Network Layer
  *   OS Detailed Path Network

In addition, key parts of Ordnance Survey's highly detailed OS MasterMap are 
being made completely open under Open Government Licence (OGL). This includes:

  *   Property extents derived from OS MasterMap Topography Layer
  *   Spatial identifiers:
 *   OS MasterMap Topography Layer TOIDs (Topographic Object Identifiers) 
will be incorporated into the features in OS Open Map-Local.
 *   Over the next 12 months the Geospatial Commission will work with 
GeoPlace, LGA, the Improvement Service (on behalf of Scottish Local 
Government), and OS to investigate how best to open up the key identifiers UPRN 
and USRN, together with their respective geometries, for the whole of Great 
Britain under OGL terms. Due to the importance of these identifiers this will 
need to be done in a such a way that protects the integrity and authority of 
these identifiers. A way to give both businesses and public sector 
organisations the confidence to continue to rely on these within their own 
products and services, without restricting their ability to use and benefit 
from them.

UPRN = Unique Property Reference Number
USRN = Unique street reference number

Clearly we feel that "free and without restriction" is not compatible with free 
open data and that they should be going further with their OGL release. This is 
something we will be feeding back. I encourage you to do the same if time 
and/or business interest allows.

They also link to the Geospatial Commission consultation, something that we are 
well into writing an answer. You can continue to feed back via OSM UK, or you 
can submit your own response.

[1] 
https://www.ordnancesurvey.co.uk/business-and-government/products/open-mastermap.html

Thanks,
Rob

 Original Message 

Subject:Open MasterMap progress since Policy Announcement
Date:   2018-10-12 15:04
From:   "ordnancesur...@connect.os.uk" 
mailto:ordnancesur...@connect.os.uk>>





An update on Open MasterMap Open MasterMap progress since Policy announcement 
Following the Open MasterMap Policy announcement in June by Cabinet Office, 
Ordnance Survey set up the Open MasterMap Implementation Programme (OMMIP) to 
successfully deliver the elements of the announcement that
[https://cdn.uploadlibrary.com/OSPricingandLicensing/Os-Logo-New-background.jpg]








An update on Open MasterMap

Open MasterMap progress since Policy announcement






Following the Open MasterMap Policy announcement in June by Cabinet Office, 
Ordnance Survey set up the Open MasterMap Implementation Programme (OMMIP) to 
successfully deliver the elements of the announcement 

 that OS is responsible for. We have continued to work closely with the 
Geospatial 
Commission,
 an expert committee within the Cabinet Office, on delivery plans, and we are 
now in a position where we can start to share more of the proposed Outputs for 
your information and feedback.



Details of the proposed 'Utility' APIs and a summary of the proposed delivery 
plan can be found on our website 
>



We believe that the APIs we're proposing will ensure that users have better 
access to our world class mapping and geospatial data, but we'd welcome your 
feedback on these. We have also shared the summary of our proposed delivery 
plan in order to demonstrate several things:

  1.  Our approach to delivery will be collaborative in nature, i.e. co-design 
principles of user testing will influence Outputs
  2.  Outputs will be delivered throughout the programme, rather than a 
'big-bang'.

We're currently working with the Geospatial Commission to agree the more 
detailed delivery 

Re: [Talk-GB] OSM on BBC4's 'Magic Numbers'

[Dave F]

I noticed that, but only on her phone. The graphic afterwards used to 
explain relative locations was something else.


On 12/10/2018 20:30, jc...@mail.com wrote:

OpenStreetMap was credited at the end of episode one from the documentary 
series 'Magic Numbers: Hannah Fry's Mysterious World of Maths' shown on BBC4 on 
Wednesday - https://www.bbc.co.uk/programmes/b0bn6wtp
The map was only on screen for a few seconds near the end of the programme but 
was nevertheless pleasing to see.

Jez C

___
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-it] Canale per centrale idroelettrica

[Sergio Manzi]

"/ditch/" è propriamente un fosso e "/drain/" uno scolmatore.

Il canale che alimenta la caduta d'acqua in condotta forzata (/penstock/), in 
Inglese si chiama "/culvert/" quando è in galleria e "/race/" quando è a cielo 
aperto.

Nel wiki la "race" la vedo citata come "headrace" (/ci sta.../), sia qui [1] 
che qui [2], dove ci sono anche esempi fotografici.

Sempre secondo il wiki [3] sembra che sia meglio usare tunnell=flooded invece 
di tunnel=culvert, soprattutto quando si tratta di lunghe tratte

[1] https://wiki.openstreetmap.org/wiki/Waterways
[2] https://wiki.openstreetmap.org/wiki/Tag%3Ausage%3Dheadrace
[3] https://wiki.openstreetmap.org/wiki/Tag:tunnel%3Dculvert


On 2018-10-12 21:10, Alfredo Gattai wrote:
> Al di la dello scopo, secondo me e' piu' adatto waterway=drain oppure 
> waterway=ditch se piu' piccolo. Per la parte coperta e vedere qualche esempio 
> fai qualche query in valle d'Aosta,  ce ne sono molti antichi e che qualcuno 
> comincia a restaurare.
>
> Il Ven 12 Ott 2018, 20:52 demon.box  > ha scritto:
>
> Sergio Manzi wrote
> > Visto così, a cielo aperto e di portata sicuramente ridotta (/e per quel
> > //_poco_//che ne so!/) mi sembra strano che possa alimentare una 
> centrale
> > idroelettrica: penso più ad un canale di irrigazione o ad uno
> > scolmatore...
>
> ciao, guarda ne sono sicuro al 101% perchè l'ho ispezionato di persona.
> in pratica quello che vedi nelle foto è un tratto di canale diciamo "in
> piano" che esce da un bacino di accumulo.
> alla fine di questo tratto di canale c'è il classico tubo 
> (man_made=pipeline
> + usage=penstock) che scende in picchiata fino a raggiungere il fondovalle
> dove c'è la centrale idroelettrica.
>
> ma tornando alla mia domanda: come faccio a taggare il tratto coperto
> peraltro appena al di sopra del livello del terreno?
>
> forse
>
> waterway=canal
> tunnel=culvert ?
>
> grazie
>
> --enrico
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Canale per centrale idroelettrica

[Lorenzo Beltrami]

Il giorno ven 12 ott 2018 alle ore 21:34 demon.box 
ha scritto:

> se mi attengo a ciò che c'è scritto nel wiki, waterway=canal è perfetto
>
> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dcanal


Effettivamente tempo fa si usava waterway=canal principalmente per per la
navigazione, poi ci si è accorti che poteva avere anche altri utilizzi tra
cui l'irrigazione o la derivazione per le centrali elettriche.

perciò in definitiva sono convinto che waterway=canal sia appropriato,
> soltanto che non sò come indicare la parte coperta...
>

Sul wiki ho trovato tunnel=flooded[1], dove si cerca di differirlo da
tunnel=culvert in base alla dimensione: un flooded più grande di un culvert.
Da notare anche l'accoppiata con usage=headrace[2], pensato proprio per le
centrali elettriche.

Puoi fare riferimento alla pagina di approvazione dell'approvvigionamento
delle centrali idroelettriche[3], molto ben curata dall'utente francese
Fanfouer che ha messo un sacco di schemini e di casi d'esempio.

[1] https://wiki.openstreetmap.org/wiki/Tag:tunnel%3Dflooded
[2] https://wiki.openstreetmap.org/wiki/Tag:usage%3Dheadrace
[3]
https://wiki.openstreetmap.org/wiki/Proposed_features/Hydropower_water_supplies

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

Re: [Talk-it] Proposed features/mtb:type

[Nogaro]

Questa per un caso simile, mi sembra una mappatura ragionevole:

 

https://www.openstreetmap.org/way/62329897

 

 

Ciao

Alberto

 

 

From: suburbanstu...@runbox.com  
Sent: 11 October 2018 19:37
To: talk-it@openstreetmap.org
Cc: talk-it-...@openstreetmap.org
Subject: Re: [Talk-it] Proposed features/mtb:type

 


Mi riferisco tecnicamente a percorsi o tracce che sono create appositamente per 
le discese (e non salite) in mtb nel puro stile enduro o freeride come si usa 
dire oggi.
Percorsi che qualche mapper magari va a fare e li tagga come normale 
highway:path  non specificando che in realtà si tratta di un sentiero designato 
per le biciclette in discesa e basta.
Che fare ? anche per questioni di sicurezza se un escursionista si trovasse in 
mezzo ad uno di questi potrebbe essere travolto dalle biciclette in discesa...
In sintesi non sono propriamente sentieri ma piste in discesa per le 
bicicletteMTB trails nello specifico tecnico + o meno infrastrutturate :
https://images.singletracks.com/blog/wp-content/uploads/2018/01/IMG_0953-33-1200x798-1.jpg
https://image.redbull.com/rbcom/010/2016-06-05/1331798649609_1/0010/1/950/633/1/un-secondo-posto-meritato-pe-tracey-hannah.jpg
https://www.singletracks.com/Mountain-Bike-Trails-bike-trails_0.html?filterBy=|loc:39.891667~-105.762500~25~Winter+Park%2C+CO

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

Re: [Talk-it] Canale per centrale idroelettrica

[demon.box]

liste DOT girarsi AT posteo DOT eu wrote
> Io una cosa simile, tempo fa alle prime armi, la taggai come 
> man_made=pipeline e tunnel=culvert, insieme a layer=-1.
> 
> Canale mi sa più una cosa per fruire dell'acqua, qui porta acqua ad una 
> centrale, per cui ci può stare anche un waterway=drain, ovvero un canale 
> artificiale per uso industriale, in questo caso per portare acqua per 
> far funzionare una turbina.

se mi attengo a ciò che c'è scritto nel wiki, waterway=canal è perfetto

https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dcanal

visto che dice proprio

Use waterway=canal for man-made open flow (free flow vs pipe flow) waterways
used to carry useful water for (...), hydro-power generation

mentre man_made=pipeline in questo caso non ce lo vedo per nulla perchè
sempre il wiki dice chiaramente che per essere tale ci devono essere dei
tubi...

perciò in definitiva sono convinto che waterway=canal sia appropriato,
soltanto che non sò come indicare la parte coperta...

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-GB] OSM on BBC4's 'Magic Numbers'

[jc...@mail.com]

OpenStreetMap was credited at the end of episode one from the documentary 
series 'Magic Numbers: Hannah Fry's Mysterious World of Maths' shown on BBC4 on 
Wednesday - https://www.bbc.co.uk/programmes/b0bn6wtp
The map was only on screen for a few seconds near the end of the programme but 
was nevertheless pleasing to see.

Jez C

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

Re: [Talk-it] Canale per centrale idroelettrica

[liste DOT girarsi AT posteo DOT eu]

Il 12/10/18 20:52, demon.box ha scritto:

Sergio Manzi wrote

Visto così, a cielo aperto e di portata sicuramente ridotta (/e per quel
//_poco_//che ne so!/) mi sembra strano che possa alimentare una centrale
idroelettrica: penso più ad un canale di irrigazione o ad uno
scolmatore...


ciao, guarda ne sono sicuro al 101% perchè l'ho ispezionato di persona.
in pratica quello che vedi nelle foto è un tratto di canale diciamo "in
piano" che esce da un bacino di accumulo.
alla fine di questo tratto di canale c'è il classico tubo (man_made=pipeline
+ usage=penstock) che scende in picchiata fino a raggiungere il fondovalle
dove c'è la centrale idroelettrica.

ma tornando alla mia domanda: come faccio a taggare il tratto coperto
peraltro appena al di sopra del livello del terreno?

forse

waterway=canal
tunnel=culvert ?

grazie

--enrico



Io una cosa simile, tempo fa alle prime armi, la taggai come 
man_made=pipeline e tunnel=culvert, insieme a layer=-1.


Canale mi sa più una cosa per fruire dell'acqua, qui porta acqua ad una 
centrale, per cui ci può stare anche un waterway=drain, ovvero un canale 
artificiale per uso industriale, in questo caso per portare acqua per 
far funzionare una turbina.





--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-it] Canale per centrale idroelettrica

[Alfredo Gattai]

Al di la dello scopo, secondo me e' piu' adatto waterway=drain oppure
waterway=ditch se piu' piccolo. Per la parte coperta e vedere qualche
esempio fai qualche query in valle d'Aosta,  ce ne sono molti antichi e che
qualcuno comincia a restaurare.

Il Ven 12 Ott 2018, 20:52 demon.box  ha scritto:

> Sergio Manzi wrote
> > Visto così, a cielo aperto e di portata sicuramente ridotta (/e per quel
> > //_poco_//che ne so!/) mi sembra strano che possa alimentare una centrale
> > idroelettrica: penso più ad un canale di irrigazione o ad uno
> > scolmatore...
>
> ciao, guarda ne sono sicuro al 101% perchè l'ho ispezionato di persona.
> in pratica quello che vedi nelle foto è un tratto di canale diciamo "in
> piano" che esce da un bacino di accumulo.
> alla fine di questo tratto di canale c'è il classico tubo
> (man_made=pipeline
> + usage=penstock) che scende in picchiata fino a raggiungere il fondovalle
> dove c'è la centrale idroelettrica.
>
> ma tornando alla mia domanda: come faccio a taggare il tratto coperto
> peraltro appena al di sopra del livello del terreno?
>
> forse
>
> waterway=canal
> tunnel=culvert ?
>
> grazie
>
> --enrico
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> 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] Canale per centrale idroelettrica

[demon.box]

Sergio Manzi wrote
> Visto così, a cielo aperto e di portata sicuramente ridotta (/e per quel
> //_poco_//che ne so!/) mi sembra strano che possa alimentare una centrale
> idroelettrica: penso più ad un canale di irrigazione o ad uno
> scolmatore... 

ciao, guarda ne sono sicuro al 101% perchè l'ho ispezionato di persona.
in pratica quello che vedi nelle foto è un tratto di canale diciamo "in
piano" che esce da un bacino di accumulo.
alla fine di questo tratto di canale c'è il classico tubo (man_made=pipeline
+ usage=penstock) che scende in picchiata fino a raggiungere il fondovalle
dove c'è la centrale idroelettrica.

ma tornando alla mia domanda: come faccio a taggare il tratto coperto
peraltro appena al di sopra del livello del terreno?

forse

waterway=canal
tunnel=culvert ?

grazie

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [Talk-es] La app Vespucci me posiciona con mucho error. ¿Os pasa?

[Miguel Sevilla-Callejo]

Hola,

A mi no me ha pasado esto de la falta de precisión de localización de
vespucci frente a otras apps pero se me ocurre que puede estar relacionado
con  los servicios de posicionamiento de Google del móvil (posicionamiento
por redes wifi por ejemplo) que este programa no use por defecto o por una
configuración particular.

Yo tengo todos esos servicios "extras" deshabilitados y solo uso la señal
GPS, que por otro lado, gracias al buen receptor de.mi aparato, parece que
funciona con errores en campo abierto por debajo de 3m.

Prueba a ver y nos comentas.

Saludos

On Thu, 11 Oct 2018, 14:15 Rodrigo Rega,  wrote:

> Podría ser que tengas en Android el posicionamiento configurado como
> "Ahorro de batería", pero por lo que dices tampoco me cuadra. ¿Has
> verificado que lo tienes en "solo teléfono"?
>
> El jue., 11 oct. 2018 8:04, Alberto Llorente 
> escribió:
>
>> La app Vespucci (
>> https://play.google.com/store/apps/details?id=de.blau.android), al menos
>> en mi móvil, situa la posición malísimamente. Si es asi para todo el mundo,
>> lo veo un peligro de la repera al editar en directo.
>>
>> La he probado varios días y esa es mi experiencia. Cuando el GNSS me
>> sitúa en un punto, hay errores de decenas de metros respecto a la posición
>> real. En ese momento, consulto Orux, Ozi y Google Maps y me sitúan
>> perfecto, con el típico error de +-3 m.
>>
>> ¿A alguien le pasa lo mismo?. Al final, de momento sólo me sirve para
>> editar posicionando a mano
>>
>> Nunca he tenido problemas de posicionamiento con ninguna app.
>>
>> :)
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[Talk-it] Il 26 ottobre a Cuneo una giornata dedicata ad OpenStreetMap

[mbranco2]

Ciao Lista,

vi informo che venerdì 26 ottobre, a Cuneo, ci sarà un incontro dedicato ad
OSM.
Ci hanno contattato per organizzare l'evento Maria Claudia Bodino e il
Centro Europe DIrect di Cuneo, qui [1] il primo comunicato cui ne
seguiranno altri in vari canali di comunicazione.

Al mattino ci saranno vari talk su OSM e HOT, al pomeriggio faremo dei
workshop sia in aula (con iD) e sul campo (con varie app).

Sarà una bella occasione per conoscersi tra osmer locali, ma naturalmente
sarà gradita in generale la partecipazione e l'intervento di tutti i membri
della nostra comunità che potranno trovarsi in zona quel giorno.

Ci fosse qualche senior che può dare una mano per i workshop del
pomeriggio, mi contatti: ce ne sarà certamente bisogno.

Un saluto,
Marco

[1] https://www.facebook.com/events/245919409386210
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Canale per centrale idroelettrica

[Sergio Manzi]

Visto così, a cielo aperto e di portata sicuramente ridotta (/e per quel 
//_poco_//che ne so!/) mi sembra strano che possa alimentare una centrale 
idroelettrica: penso più ad un canale di irrigazione o ad uno scolmatore... ci 
mandi le coordinate?

Ciao,

Sergio


On 2018-10-12 19:24, demon.box wrote:
> ciao, se ho un canale che scorre appena sopra il livello del terreno ed
> alimenta una centrale idroelettrica fatto così:
>
>  
>
>  
>
> parte scoperta:
>
> waterway=canal
> usage=headrace
>
> parte scoperta?
>
> waterway=canal
> usage=headrace
> covered=yes
>
> oppure cos'altro?
> grazie
>
> --enrico
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Pierre-Yves Mevel]

Je suis tombé dessus en voulant faire une carte des itinéraires cyclables
de Fougères et j'avoue que j'ai bien failli tout supprimer. Ce qui m'a fait
hésiter est que le contributeur est assez expérimenté (
https://www.openstreetmap.org/user/Jean-Pierre%20Rondeau). En tout cas, sur
le terrain, il n'y a aucun balisage et je pense aussi que ce genre
d'information devrait se trouver ailleurs que sur OSM.

Le ven. 12 oct. 2018 à 19:11, Gwenaël Jouvin  a
écrit :

> Bonsoir,
>
> Merci d’amener ce sujet ici : en préparant une rando il y a quelques
> semaines, j’étais surpris que brouter m’emmène par l’ancienne nationale 164
> (une route vraiment pas drôle pour rouler à vélo)… il a simplement suivi la
> relation indiquée comme ncn !
>
> Pour moi c’est une erreur : le Paris – Brest – Paris est une épreuve
> cycliste et pas du tout un itinéraire balisé par une institution comme le
> sont la Véloscénie ou la Scandibérique :
> https://www.openstreetmap.org/relation/7163558
> https://www.openstreetmap.org/relation/2345035
>
> Peut-être faudrait-il contacter ses auteurs afin de comprendre leur
> motivation ?
>
> À mon avis, il faudra au minimum retirer l’attribut network=ncn car il est
> ici inapproprié.
>
>
> Le 12/10/2018 à 17:26, jabali a écrit :
> > Je viens de tomber sur ceci
> > https://www.openstreetmap.org/relation/8595631
> > vous en pensez quoi ?
> > Itinéraire cyclable ?
> >
> >
> >
> >
> >
> > --
> > Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> >
> > ___
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] Canale per centrale idroelettrica

[demon.box]

ciao, se ho un canale che scorre appena sopra il livello del terreno ed
alimenta una centrale idroelettrica fatto così:

 

 

parte scoperta:

waterway=canal
usage=headrace

parte scoperta?

waterway=canal
usage=headrace
covered=yes

oppure cos'altro?
grazie

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

[Johnparis]

Bonjour,

Il y a deux discussions mélées dans ce sujet : les routes de substitution
et l'utilité de route_ref.

Je m'adresse d'abord aux lignes.

Moi je pense que la "substitution" applique aux relations, pas aux noeuds
(arrêts). Normalement, le noeud désigne un endroit physique. Si je pense
d'un arrêt de substitution et d'un arrêt "normale", dois-je les fusionner ?
Si oui, le tag "subsitution=yes" a tort, parce que l'arrêt lui-même n'est
pas un arret de subsitution.

Alors, substitution:route_ref est preferable. Mais je pense que
route_ref:substitution=* est meilleur. C'est les routes (et donc les
route_ref) qui sont de substitution, pas les noeuds.

Je ne trace pas les lignes de substitution, mais chacune a son route_ref.
Par exemple, on peut dire pour le StopPoint:76:150 :

name=Gare du Nord Surface
route_ref:substitution=H SSB-PAR

... et pour la relation ...
name=Bus H SSB-PAR : Travaux Sarcelles St Brice - Paris Est
ref=H SSB-PAR
substitution=yes

Si l'on veut indiquer la ligne substituée, on peut ajouter sur la relation :
substitution:route_id=800:H (ou substitution:ref=Train H ou Ligne H)

===

Deuxième chose : les route_ref si la relation existe.

Moi je suis pour les route_ref, après avoir utilisé les deux methodes.

1. Il y a des arrêts où la desserte est secondaire, mais seulement la
relation de la desserte principale existe dans OSM.
2. Cela ameliore la contrôle de la qualité. Si l'on trouve un desaccord
entre la relation et le noeud, Osmose peut signaler un problème.
3. Le problème des données qui ne sont pas perennes existent dans les deux
cas. OSM, comme Wikipedia, est toujours une approximation sujet à
l'amelioration. Mais si les lignes changent, c'est plus facile de savoir si
l'on a le route_ref.
4. Pour le consommateur, c'est plus facile de lire un tag "route_ref" que
construire les relations.
5. Encore pour le consommateur, imaginez un noeud avec
route_ref=1;2;3;4;5;6 qui est dans les relations avec ref=1,2,5,6. (Les
relations 3 et 4 ne sont pas encore construit.) Si vous retirez juste les
"doublons" on trouve route_ref=3;4. Mais si le consommateur regarde le
noeud, et trouve route_ref=3;4, normalement il va penser qu'il n'y a que
deux lignes qui desservent l'arrêt, non ?

Cordialement,

John






On Fri, Oct 12, 2018 at 6:13 PM Florian LAINEZ  wrote:

> Hello,
> Je suis d'accord avec Marc : l'utilisation d'une relation est à terme la
> meilleure manière de faire. Et créer un tag qui devrait être une relation
> est risqué pour la pérennité des données.
> Néanmoins je suis aussi d'accord avec Charles : pour l'instant
> l'utilisation d'un tag est le plus simple.
> substitution:route_ref me parait en effet tout indiqué.
>
> pour moi l'élément clef qui nous pousse à ne pas utiliser les relations à
> ce stade est que l'on ignore 1. les différents arrêts desservis par chaque
> ligne de substitution 2. le trajet de ceux-ci.
> Étant donné que l'on ignore tout des lignes à ce stade, je suis d'avis de
> mapper directement avec des tags sur les arrêts.
>
>
> Le ven. 12 oct. 2018 à 13:40, Charles MILLET  a
> écrit :
>
>> Merci beaucoup pour tes précisions Marc !
>>
>> Je suis globalement d'accord avec tes arguments pour ce qui est de la
>> redondance, j'attends un peu d'avoir à nouveau les explications des
>> "pour" avant d'avoir un avis définitif.
>>
>> Effectivement ce serait assez cohérent d'utiliser substitution:route_ref
>>
>> On 12/10/2018 12:58, marc marc wrote:
>> > Bonjour,
>> >
>> > Le 12. 10. 18 à 11:24, Charles MILLET a écrit :
>> >> Pour résumer tu n'est pas pour parce que tu n'est déjà
>> >> pas pour le route_ref ?
>> > oui en résumé c'est exactement cela. je suis contre subtitution:lines
>> > permanent parce que je suis contre l'utilisation permanente de route_ref
>> >
>> > Si c'est un tag temporaire comme un étape intermédiaire renseignant
>> > les informations destiné à la création des relations, c'est utile
>> > mais autant garder la même logique et créer subtitution:route_ref
>> > Et je passerai à la relation même imparfaite dès que possible.
>> >
>> >> https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :
>> >> [route_ref=* can easily be added to individual bus stops without
>> knowing
>> >> the whole route a service takes. It can serve as a basis to add the
>> full
>> >> route relation LATER on]
>> > je partage cet avis :
>> > route_ref est utile quand il est utilisé temporairement "je suis passé
>> > devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter
>> > PLUTARD à la relation par ex avec un outil + adapté", c'est donc
>> > à mes yeux signe de "ce n'est pas finit, il y a des choses à faire".
>> > (même si je trouve qu'utiliser une clef spécifique pour une note/fixme
>> > dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à
>> > requêter" et si chaque catégorie de donnée utilisait une clef
>> > différente, ce serrait pas génial)
>> >
>> > mais quand il est permanent, c'est une donnée dupliquée avec la galère
>> > que cela 

Re: [Talk-de] Smoothness nur für Wege oder auch für Straßen

[Volker Schmidt]

Hallo Thomas,

du hast Recht. Das Wiki spricht von vehicle, was ich inkorrekterweise als
Auto uebersetzt habe. Natuerlich sind Fahrraeder auch Fahrzeuge,
Die Werteskale gilt fuer alle Fahrzeuge.

Volker

On Fri, 12 Oct 2018 at 14:59, Tobias Wrede  wrote:

> Am 12.10.2018 um 07:39 schrieb Volker Schmidt:
> > Die Were des "smoothness" tag sind auf Autos bezogen, nicht auf
> Fahrräder,
> > wenn du im wiki nachschaust. Sind dann aber von der user community auch
> für
> > Radfahrer verwendet worden.
> >
> In welchem Wiki schaust du denn? Im OSM-Wiki (und auch schon im
> Proposal)  beziehen sich die wenigsten Beispiele auf Autos. In den
> beiden höchsten Klassen sind Autos noch nicht mal erwähnt.
>
> Tobias
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Gwenaël Jouvin]

Bonsoir,

Merci d’amener ce sujet ici : en préparant une rando il y a quelques semaines, 
j’étais surpris que brouter m’emmène par l’ancienne nationale 164 (une route 
vraiment pas drôle pour rouler à vélo)… il a simplement suivi la relation 
indiquée comme ncn !

Pour moi c’est une erreur : le Paris – Brest – Paris est une épreuve cycliste 
et pas du tout un itinéraire balisé par une institution comme le sont la 
Véloscénie ou la Scandibérique :
https://www.openstreetmap.org/relation/7163558
https://www.openstreetmap.org/relation/2345035

Peut-être faudrait-il contacter ses auteurs afin de comprendre leur motivation ?

À mon avis, il faudra au minimum retirer l’attribut network=ncn car il est ici 
inapproprié.


Le 12/10/2018 à 17:26, jabali a écrit :
> Je viens de tomber sur ceci
> https://www.openstreetmap.org/relation/8595631
> vous en pensez quoi ?
> Itinéraire cyclable ?
> 
> 
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
> 
> ___
> 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

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

[Florian LAINEZ]

Hello,
Je suis d'accord avec Marc : l'utilisation d'une relation est à terme la
meilleure manière de faire. Et créer un tag qui devrait être une relation
est risqué pour la pérennité des données.
Néanmoins je suis aussi d'accord avec Charles : pour l'instant
l'utilisation d'un tag est le plus simple.
substitution:route_ref me parait en effet tout indiqué.

pour moi l'élément clef qui nous pousse à ne pas utiliser les relations à
ce stade est que l'on ignore 1. les différents arrêts desservis par chaque
ligne de substitution 2. le trajet de ceux-ci.
Étant donné que l'on ignore tout des lignes à ce stade, je suis d'avis de
mapper directement avec des tags sur les arrêts.


Le ven. 12 oct. 2018 à 13:40, Charles MILLET  a
écrit :

> Merci beaucoup pour tes précisions Marc !
>
> Je suis globalement d'accord avec tes arguments pour ce qui est de la
> redondance, j'attends un peu d'avoir à nouveau les explications des
> "pour" avant d'avoir un avis définitif.
>
> Effectivement ce serait assez cohérent d'utiliser substitution:route_ref
>
> On 12/10/2018 12:58, marc marc wrote:
> > Bonjour,
> >
> > Le 12. 10. 18 à 11:24, Charles MILLET a écrit :
> >> Pour résumer tu n'est pas pour parce que tu n'est déjà
> >> pas pour le route_ref ?
> > oui en résumé c'est exactement cela. je suis contre subtitution:lines
> > permanent parce que je suis contre l'utilisation permanente de route_ref
> >
> > Si c'est un tag temporaire comme un étape intermédiaire renseignant
> > les informations destiné à la création des relations, c'est utile
> > mais autant garder la même logique et créer subtitution:route_ref
> > Et je passerai à la relation même imparfaite dès que possible.
> >
> >> https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :
> >> [route_ref=* can easily be added to individual bus stops without knowing
> >> the whole route a service takes. It can serve as a basis to add the full
> >> route relation LATER on]
> > je partage cet avis :
> > route_ref est utile quand il est utilisé temporairement "je suis passé
> > devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter
> > PLUTARD à la relation par ex avec un outil + adapté", c'est donc
> > à mes yeux signe de "ce n'est pas finit, il y a des choses à faire".
> > (même si je trouve qu'utiliser une clef spécifique pour une note/fixme
> > dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à
> > requêter" et si chaque catégorie de donnée utilisait une clef
> > différente, ce serrait pas génial)
> >
> > mais quand il est permanent, c'est une donnée dupliquée avec la galère
> > que cela implique à chaque fois qu'il y a une différence entre les 2 :
> > si un utilisateur vire route_ref sans virer l'arrêt de la relation,
> > cela signifie-t-il que l'arrêt n'est plus desservit et qu'il faut
> > virer de la relation ? ou cela signifie-t-il qu'il a juste viré
> > une clef qu'il trouve inutile ?
> > Idem quand route_ref est présent mais différent des relations,
> > pour en avoir corrigé un bon paquet, quelle perte de temps à faire
> > une 2ieme fois les modifs en devinant le sens de la désynchro.
> > J'ai croisé des désynchro qui avait des années... c'est un peu
> > comme les notes non traitée, on a l'info mais faut quelqu'un
> > repasse une 2ieme fois pour que cela deviennent utilisable.
> >
> >> on est pas mal dans cette situation au final sauf qu'au lieu
> >> d'utiliser route_ref qui ne serait pas adapté et risquerait de parasiter
> >> cette clé, on propose d'utiliser : substitution=yes +
> >> subtitution:lines=* qui ont une vocation plus temporaire
> >> (1 an, 2 ans ?).
> > en temporaire oui pourquoi pas.
> > dans cette optique, autant aller jusqu'au bout avec
> > subtitution:route_ref qui dit clairement que cela a pour but
> > à terme d'être ajouté dans une relation de substitution.
> > mais il ne faudrait pas en arriver à "durabiliser" ce "fixme"
> > hors on va le mettre dans le wiki comme façon de tager un arrêt
> > de substitution
> > puis il y aura la tentation de faire un umap
> > ou n'importe quoi d'autre pour montrer l'avancement..
> > et du coup le temporaire devient permanent...
> > Tu parles de 2 ans...
> > pq pas faire une relation imparfaite ? une relation ligne de bus
> > qui contient juste les quelques arrêts identifié dans le mois,
> > ce n'est pas complet mais c'est utilisable, un tag wiki sur
> > la relation vers la page qui explique l'expérimentation,
> > il serra toujours temps + tard d'affiner.
> > Mais je comprend/partage l'avis que la relation n'est pas
> > la priorité quand vous en êtes à l'étape d'identifier les arrêts.
> >
> >> Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile
> >> de la rejeter, perdre son utilité juste pour gagner en "pureté"
> >> de la données ?
> > Le problème principal ce n'est pas la pureté.
> > C'est le fait qu'avoir les données de 2 manières différentes implique
> > que par erreur ou par méconnaissance, certains contributeurs vont
> > modifié l'un, d'autre vont modifier 

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Vincent de Château-Thierry]

Bonjour,

> De: "Florimond Berthoux" 
> 
> J'en pense « Key:route : This can be used to describe routes. A route
> is a customary or regular line of passage or travel, often
> predetermined and publicized. Routes consist of paths taken
> repeatedly by people and vehicles: a ship on the North Atlantic
> route, a car on a numbered road, a bus on its route or a cyclist on
> a national route. »
> 
> Est-ce un itinéraire ? Oui
> Est-ce un itinéraire pris régulièrement par des cyclistes en dehors
> de la course ? Euh, faut voir, a priori non, mais j'imagine que
> certain prennent la trace pour la rouler en partie, est-ce qu'il y a
> réellement un débit de cycliste de l'ordre d'une eurovélo ?

Est-ce que l'itinéraire est, une fois l'épreuve terminée, vérifiable par 
n'importe qui sur le terrain ? J'en doute. Et pour obtenir la trace pour la 
rouler en partie, autant aller la chercher à la source, par exemple ici : 
http://www.paris-brest-paris.org/index2.php?lang=fr=randonnee=Etape8 
(voir le bouton "Chargez la trace GPS").
Bref la seule raison que je vois pour rentrer cette relation dans OSM est 
historique, et je trouve cette raison bien mince. Ou alors on se lance dans la 
saisie des épreuves plus généralement : une relation par Tour de France 
cycliste, une par Paris-Dakar, une par Marathon de Paris, New-York, etc. Ca ne 
me paraît pas du tout une bonne idée dans OSM directement. Umap est parfait 
pour mettre en valeur ce type d'informations, non ?

> N'y-a-t-il pas un droit d'auteur dessus ?
Bonne question, la première à se poser. Je n'ai rien vu sur le site du PBP, 
mais sur le site du club organisateur, on voit une mention "© Audax Club 
Parisien - All right reserved." en pied de page (par exemple : 
http://www.audax-club-parisien.com/FR/41%20-%20Paris-Brest-Paris.html). Rien de 
bien libre a priori.

vincent

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

Re: [OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[Florimond Berthoux]

Bonjour,

J'en pense « Key:route : This can be used to describe routes. A route is a
customary or regular line of passage or travel, often predetermined and
publicized. Routes consist of paths taken repeatedly by people and
vehicles: a ship on the North Atlantic route, a car on a numbered road, a
bus on its route or a cyclist on a national route. »

Est-ce un itinéraire ? Oui
Est-ce un itinéraire pris régulièrement par des cyclistes en dehors de la
course ? Euh, faut voir, a priori non, mais j'imagine que certain prennent
la trace pour la rouler en partie, est-ce qu'il y a réellement un débit de
cycliste de l'ordre d'une eurovélo ?

N'y-a-t-il pas un droit d'auteur dessus ?


Le ven. 12 oct. 2018 à 17:26, jabali  a écrit :

> Je viens de tomber sur ceci
> https://www.openstreetmap.org/relation/8595631
> vous en pensez quoi ?
> Itinéraire cyclable ?
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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

[OSM-talk-fr] Epreuve Cyclo-randonnée Paris-Brest-Paris dans OSM

[jabali]

Je viens de tomber sur ceci
https://www.openstreetmap.org/relation/8595631
vous en pensez quoi ?
Itinéraire cyclable ?





--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-ja] place=city_block

[Satoshi IIDA]

いいだです。

> ＞ref:JP:block_number
> boundary=administrativeをつけるのであれば、日本の行政体系の一部であることは明らかなので、JPは不要と考えます。
block_numberが日本だけで使われているのであればよいのですが、
実際には、フィリピンの一部（まだストリートが無い振興開拓地で、まだ開発中のところ）でも使われている、と聞いています。
なので、JPは、あったほうがよいかな、と思っています。

ちなみに、2014年でチト古いですが、当時のスレッド（フィリピンとの議論）はこちらです。
https://lists.openstreetmap.org/pipermail/talk-ph/2014-April/005033.html

> admin_level=11の策定については慎重であるべき
はい、他の方のご意見を伺いたいです。





2018年10月11日(木) 19:52 tomoya muramoto :

> ＞案(4) ref:block_numberを新設
> ＞・boundary=administrative
> ＞・ref:block_number=*
> なるほど。これはアリですね。
>
> ＞ref:JP:block_number
> boundary=administrativeをつけるのであれば、日本の行政体系の一部であることは明らかなので、JPは不要と考えます。
>
> admin_level=11の策定については慎重であるべきと私も考えます。
> ですので現時点での議論では、積極的に策定する理由に乏しいと思いますので、これ以上議論が発展しない場合はペンディングでしょうか。
> (もちろん、策定に向けた議論は大いにすべきです)
> (ついでと言ってはなんですが、各地方についていたadmin_level=3を削除しました)
>
> muramoto
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] 司法書士/行政書士事務所のタグ

[Satoshi IIDA]

いいだです。

反応おくれてすみません。
lawyer=* のタグは、正直まだ未整備だと感じます。

https://wiki.openstreetmap.org/wiki/Key:lawyer

こういうのを整備するときには、まずは国際的な標準があるかどうかを探すのが
いちばん手っ取り早い（＆制定する際に各国の抵抗が少ない）と思っているのですけれど、
ざっとGoogleさんに聞いてみたかんじではなかなかそういう名称の一覧は無いみたいですね。。。

病院の診療科目（Healthcare 2.0）でも一時期探したのですけれど、
国際的なものは無い様子。
どなたかご存知無いでしょうか？





2018年9月27日(木) 20:26 tomoya muramoto :

>
> lawyer:ja=司法書士
> はいかがでしょうか？
>
> muramoto
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] place=city_block 町内会や自治体

[Satoshi IIDA]

いいだです。
情報ありがとうございます。

以前にadmin_levelなどを策定する議論をしたときには、正直なところあまり深く突っ込んでいなかったのですが、
いただいた情報からしても、町内会については別の境界線を用いてエリア化するほうがよさそうですね。

町内会の組成については、特に歴史の深いところや、田舎にゆけばゆくほど例外がでてきそうですし、
admin_levelとは別に考えたほうがよさそうです。

実際、僕の田舎のほうでも、部落、という単位で実質的な町内会が組まれていますし、
それはboundaryとはニアイコールな関係である、というのが正直な印象です。
boundaryの外縁になればなるほど、所属するかどうかは都度判断で、
商店街に加盟しているかどうかというのにも近いかも。
（ちなみに部落、という言葉ですが、部落差別とか意味は全く無く、
「このへんの集落」ということで部落、と呼ばれています。もし気になる方いらしたらすみません）



2018年10月11日(木) 22:09 Ryosuke Amano :

> 横浜のあまのです
>
> いいださんが話に出した、町内会や自治体に関して
>
> 町内会や自治会をadmin_levelに紐づけるのは、避けるべきと考えます
> というのも、その括りは結論から言ってしまうと町丁界とはあまり関係がないと考えられるからです。
>
> ローカルな例ですが、いくつか実例を。
> 23区の例として、世田谷区の町会・自治会の一覧
> http://setagaya-chousouren.org/joinsearch.html
> （他に大田区、江戸川区も地区ごとですが一覧があります）
>
> もちろん１町丁＝１町会となっている地区もありますが
>
> 1)団地や大型マンション、アパートは町会が別
> 2)住居表示、町名整理以前の旧町や小名由来の町会がある
> （守山町会、千駄山町会など）
> 3)1丁目から〇丁目まで全域、という町会もあれば、複数の町丁にまたがる町会もある
>
> ということがわかります。
>
> また私が一番土地勘のある、横浜市保土ヶ谷区の町会・自治会の一覧
> http://www.hodogaya-kurenkai.jp/kanyu/ichiran.html
>
> そしてそれを図示したのが、↓PDFの2ページ目
> http://www.hodogaya-kurenkai.jp/jichi/pdf/map_h30.pdf
> 見にくいですが、1点鎖線が町丁界です。
> また白抜きで番号も何も入っていないエリアは公園・学校・オフィス街等、居住人口がゼロなエリアです。
>
> 一覧を見ればわかる通り、1町丁＝1町会というところはあまりありません。
> 上記1)〜3)の状況も同じく見られますが、さらに加えて、
>
> 4)地勢的な影響
>
> もあるのかと思います。
> 保土ヶ谷区は区内のほとんどが丘陵地で、かつ斜面も急な個所が多々あります。
> そうすると、道路や川が町丁界であっても遠く険しい同じ町内よりも、至便な向かいの別町と同じ町会の方が何かと便がいい、そういうこともあるのかと思います。
> 谷沿いの「元町自治会」(←旧神戸下町、もしかしたら中世の程ヶ谷宿からの流れか？）
> 丘の上の「桜ヶ丘自治会」はそんなケースかもしれません。
> また上新地区の「望洋台自治会」や「芙蓉ケ丘自治会」といったところは、上記1)のケースなのですが、集合住宅ではなく、宅地造成をして戸建分譲した地区です。
>
> かと思えば、集合住宅の団地「コンフォール明神台」のようにこの名がつく町会が３つもある場合もあります。（URと市営、賃貸と分譲、そういった区別が関係しているのか？）
>
>
> こうしてみてみると、町会・自治会は確かに地方自治の最下部の組織ではありますが、行政界や町丁界と結びついているというよりも、総合的に見て、町丁界とはあまり関係なく、居住している人（おそらくは世帯単位）同士が『同じような環境の下で集住している』単位であるように思えます。
>
> 他の地域ではまた違う事象も出てくるでしょうけども、やはり根本のところは日本全国あまり変わらないのではないか、と思います。
>
> あまの
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-ja] 糸魚川市オルソ写真のトレース許諾がとれました

[Satoshi IIDA]

いいだです。

個人的な活動の一環として
オープンデータとして公開されている航空写真の収集というのをしていまして、
先日、新潟県 糸魚川市が航空写真を公開していることを知りました。

ダウンロードもできるので、すべてダウンロードしてタイル化しまして、
オンラインで公開しました。

OpenStreetMapでも利用できるように、市役所のかたに許可をいただきましたので、
もし興味ある方がいらっしゃいましたら活用ください。
情報は、以下のページにまとめています。

https://wiki.openstreetmap.org/wiki/Itoigawa_ortho

また、他の市町村についても、いくつか、公開および利用許諾取得の準備を進めています。
準備が整い次第、ご連絡します。

地元の市町村の航空写真を利用してみたい、というかたがいらっしゃいましたら、
僕の方でオープンデータの担当あるいは適切な部署に聞いてみたりしたいと思っています。
お知らせいただけると嬉しいです。

1700も自治体ありますので、使いたい、という要望のあるところから進めたいです。

よろしくですー (/･ω･)/
-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Comment taguer une piste cyclable à double sens sur chaussée ?

[Christian Quest]

Le ven. 12 oct. 2018 à 11:26, marc marc  a
écrit :

>
> il n'existe pas un unique lieu d'avis international,
> il y a :
> - le wiki (tant la pagecycliste que la page qui explique
> qu'on fait 2 way lorsqu'il y a un obstacle entre les 2)
> - la mailling tagging
> - et même s'il veux pas l'entendre, la communauté locale est un avis à
> prendre en compte.
>


De mon point de vue, le wiki doit vraiment rester la référence, car les
discussions à n'en plus finir sur les mailing-list sont inexploitables.
Une fois le consensus trouvé (et les communautés locales y participent
indirectement), il faut vraiment mettre à jour le wiki.

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

Re: [OSM-talk-fr] Espace de coworking qui croire entre iD et le wiki OSM

[Christian Quest]

office me semble plus adapté à un espace de coworking privé et amenity pour
un espace d'accès plutôt public...

Le ven. 12 oct. 2018 à 11:33, François Lacombe 
a écrit :

> Bonjour Jean-Christophe,
>
> La politique d'iD est de ne créer des presets que sur les tags les plus
> utilisés.
> Ceci sans tenir compte de ce qui est écrit sur le wiki (notamment pendant
> les périodes de transitions ancien => nouveau tag), il faut donc suivre le
> wiki.
>
> Je n'ai pas d'avis sur le cas particulier de amenity vs office.
>
> Bonne journée
>
> François
>
> Le ven. 12 oct. 2018 à 07:51, Jean-Christophe Becquet  a
> écrit :
>
>> Bonjour,
>>
>> Pour un Espace de coworking
>> https://www.openstreetmap.org/node/5954418134
>>
>> iD me propose le tag
>> office=coworking
>>
>> Le wiki dit
>> amenity=coworking_space
>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcoworking_space
>>
>> et office=coworking est une Page de redirection vers
>> amenity=coworking_space
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:office%3Dcoworking=no
>>
>> sur taginfo amenity=coworking_space (854) gagne légèrement contre
>> office=coworking (598).
>> https://taginfo.openstreetmap.org/tags/?key=amenity=coworking_space
>> https://taginfo.openstreetmap.org/tags/?key=office=coworking
>>
>> Bref qui croire entre iD et le wiki OSM ?
>>
>> Merci par avance pour vos éclaircissements
>>
>> Bonne journée
>>
>> JCB
>> --
>> Il y aura un retour d'expérience "Cartographies participatives avec les
>> habitants" par Jean-Christophe Becquet, avec pour support #OpenStreetMap.
>> https://twitter.com/OsmGrenoble/status/104695420100610
>>
>> ==APITUX : le choix du logiciel libre==
>>
>> APITUX - Jean-Christophe Becquet
>> BP 32 - 04001 Digne-les-Bains Cedex
>> 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
>> SIRET : 452 887 441 00031 - APE : 6202A
>>
>> ===
>>
>>
>>
>>
>> ___
>> 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
>


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

Re: [OSM-talk-fr] ?==?utf-8?q? Comment taguer une piste cyclable à double sens sur chaussée ?

[Christian Quest]

C'est sans fin ces discussions sur les voies/pistes cyclables !

De ce que j'ai vu, les différents cas de ways séparés respecte le principe
général de séparation physique qu'on a depuis longtemps sur OSM.

Il n'y a que S5 qui me semble étrange où parce que le type de revêtement
est différent on extrapole à une séparation physique... que je trouve un
peu virtuelle ;)


Le ven. 12 oct. 2018 à 11:16, Charles MILLET  a
écrit :

> Le choix des way multiple est déjà celui recommandé ! (cf. T1
> https://wiki.openstreetmap.org/wiki/Bicycle)
>
> Je veux bien qu'on remette ça en question et qu'on vérifie si ce n'est
> pas quelque chose qui a été introduit de manière cavalière mais on va
> pas faire la même chose non plus dans l'autre sens.
>
> Bon en même j'ai pas pris de le temps de mettre en place un vrai débat à
> ce sujet la dernière fois qu'on en a parlé.. J'ai pas mal de boulot en
> retard sur ces sujets.
>
> On 03/10/2018 17:34, Axelos wrote:
> > Coucou,
> >
> > Le Mercredi, Octobre 03, 2018 09:19 CEST, Thomas Ruchin <
> truchi...@gmail.com> a écrit:
> >> Question subsidiaire. S'il persiste, puis je demander le soutien du DWG
> >> avant que cela ne dégénère en guerre d'édition. De ce qu'il m'écrit, il
> >> n'accepte que les argument de la communauté "internationale".
> > Je pense qu'il s'agit d'une incompréhension. Je te suggère de suivre son
> choix et de lui proposer de mettre à jour la page wiki version anglaise
> bicycle cas T2 en mettant le choix du chemin unique en recommandé, ce qui
> correspondra à l'avis international.
> >
> >
> > ___
> > 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
>


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

Re: [Talk-de] Smoothness nur für Wege oder auch für Straßen

[Tobias Wrede]

Am 12.10.2018 um 07:39 schrieb Volker Schmidt:

Die Were des "smoothness" tag sind auf Autos bezogen, nicht auf Fahrräder,
wenn du im wiki nachschaust. Sind dann aber von der user community auch für
Radfahrer verwendet worden.

In welchem Wiki schaust du denn? Im OSM-Wiki (und auch schon im 
Proposal)  beziehen sich die wenigsten Beispiele auf Autos. In den 
beiden höchsten Klassen sind Autos noch nicht mal erwähnt.


Tobias


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

Re: [Talk-it] Segnalazione violazione licenza - Comune di Vercelli

[Simone Saviolo]

Scusate, l'ho segnalata anch'io in un altro thread perché non avevo visto
questo!

Ciao,

Simone

Il giorno gio 11 ott 2018 alle ore 15:06 Andrea Musuruane <
musur...@gmail.com> ha scritto:

>
> https://www.comune.vercelli.it/articolo/21deg-raduno-alpino-del-primo-raggruppamento
>
> Ciao,
>
> Andrea
>
> ___
> 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] tracciamo il futuro di OpenStreetMap in Italia?

[Maurizio Napolitano]

Sulla proposta di Marco ho aperto questo documento
https://hackmd.io/obMDTskMTnynK7U4YcvMRg?view
Fatto brainstorming si passa poi al documento ufficiale.

LA SCADENZA È LA PROSSIMA SETTIMANA

Siete invitati a fare modifiche (lo strumento tiene traccia delle evoluzioni)

Grazie

On Thu, Oct 11, 2018 at 10:37 PM Marco Minghini
 wrote:
>>
>> Ciao,
>>
> Ciao Napo, tutti,
>>
>>
>> C'è qualcuno interessato a produrre un documento di azioni?
>>
> Posso dare una mano volentieri. Idea: almeno come primo step, un 
> brainstorming "grezzo" su un documento condiviso online forse può essere la 
> cosa migliore per allargare il più possibile la partecipazione, cosa di cui 
> mi sembra abbiamo tanto bisogno! In un secondo momento si può fare una 
> sintesi delle idee raccolte e cominciare a buttare giù da un'altra parte il 
> documento più strutturato.
>
> Marco
>
>
> Marco Minghini, Ph.D.
> @MarcoMinghini
>
> Don't miss the Special Issue Open Source Geospatial Software, submit a paper 
> before November 15!
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



-- 
Maurizio "Napo" Napolitano
http://de.straba.us

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

Re: [OSM-talk-fr] Comment taguer une piste cyclable à double sens sur chaussée ?

[Charles MILLET]

On 12/10/2018 11:25, marc marc wrote:

Le 12. 10. 18 à 11:15, Charles MILLET a écrit :

Le choix des way multiple est déjà celui recommandé ! (cf. T1
https://wiki.openstreetmap.org/wiki/Bicycle)

Je veux bien qu'on remette ça en question et qu'on vérifie si ce n'est
pas quelque chose qui a été introduit de manière cavalière mais on va
pas faire la même chose non plus dans l'autre sens.


Le 12. 10. 18 à 10:34, Charles MILLET a écrit :

Quelqu'un peut me dire où il est question de l'avis international en
faveur de "cycleway=track" ?

il n'existe pas un unique lieu d'avis international,
il y a :
- le wiki (tant la pagecycliste que la page qui explique
qu'on fait 2 way lorsqu'il y a un obstacle entre les 2)
- la mailling tagging
- et même s'il veux pas l'entendre, la communauté locale est un avis à
prendre en compte. on devrait s'uniformer au niveau mondial mais c'est
pas une raison pour ne pas tenir compte du local.
au lieu d'essayer de deviner ce qu'il prend comme source,
le mieux serrait de lui demander ou de lui montrer que sur la page des
cyclistes avec le cas T1 dit clairement que plusieurs ways sont recommandés,
l'utilisation d'un seul way étant une version simplifiée quand on n'a
pas tous les éléments" ou quand on veux faire "un premier jet simplifié
qu'on raffinera + tard
Je veux pas bitché mais ne vous attendez pas trop à avoir des échanges 
très constructifs avec ce contributeur... après je ne demande qu'à avoir 
tord. Le wiki offre suffisamment d'interprétation (et c'est bien aussi) 
pour que quelqu'un qui veut défendre son point de vue puisse trouver les 
élément qui vont dans son sens.



sens, puisqu'on a déjà du mal à définir des règles claire pour choisir
entre un way propre et un tag sur la chaussée, on va encore créer du
flou sur le sujet.

pourtant même moi le grand partisan d'un non excès des way séparé,
je trouve qu'il se trompe. mais ce n'est pas un avis international :)
Ça me fait vraiment plaisir de lire ça ! Je veux dire, le fait qu'on 
peut encore en discuter et continuer de peser le pour et le contre et de 
faire en sorte de définir les cas où il vaut mieux utiliser le track, etc.




___
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

Re: [OSM-talk-fr] openinframap

[François Lacombe]

Bonjour

Le serveur de tuiles d'OpenInfraMap est de nouveau opérationnel.
Les mises a jour ont été faites.

François

Le sam. 1 sept. 2018 à 12:23, François Lacombe 
a écrit :

> Bonjour
>
> A noter que russs n'intervient sur openinframap qu'entre Noel et le nouvel
> an habituellement
>
> J'ai bien proposé de l'aider dans sa tache mais sans réponse. Il y a
> pourtant beaucoup à faire
>
> Bonne journée
>
> François
>
> Le sam. 1 sept. 2018 à 10:26, marc marc  a
> écrit :
>
>> Bonjour,
>>
>> info de Gazer75 (qui ne parle pas français) sur irc :
>> I think it has stopped due to a problem,
>> but ru is quite busy atm.
>>
>> en français : il y a un problème :-)
>> mais "russs", le gars qui s'en occupe, est débordé pour le moment.
>> Le mieux est de prendre contact directement avec lui ou chercher s'ils
>> ont un système de ticket pour être au courant des changements.
>>
>> Cordialement,
>> Marc
>>
>> Le 01. 09. 18 à 08:44, Laurent Combe a écrit :
>> > petit up gentil
>> > le problème de rafraichissement semble toujours présent
>> >
>> > Le mer. 22 août 2018 à 21:34, François Lacombe
>> > mailto:fl.infosrese...@gmail.com>> a
>> écrit :
>> >
>> > Bonsoir,
>> >
>> > Relativement à ce problème, il semble toujours présent dans la zone
>> > https://openinframap.org/#13/43.8486/1.4224/Power-Telecoms
>> >
>> > Il y a comme une espèce de ligne au nord de laquelle rien ne passe.
>> > Surement un problème de mise à jour
>> > A voir si les admins consentent à recharger la base
>> >
>> > François
>> >
>> > Le lun. 20 août 2018 à 08:48, François Lacombe
>> > mailto:fl.infosrese...@gmail.com>> a
>> écrit :
>> >
>> > Bonjour Laurent
>> >
>> > En effet, on dirait qu'il y a une ligne horizontale au nord de
>> > laquelle il n'y a pas de postes ou de lignes
>> >
>> > On va attendre encore quelques jours pour voir si ca se débloque
>> >
>> > François
>> >
>> > Le lun. 20 août 2018 à 08:13, Laurent Combe
>> > mailto:laurent.co...@free.fr>> a
>> écrit :
>> >
>> > alors quelque chose m'échappe
>> > au nord de toulouse, commune de Fronton par exemple , la
>> > carte affichée par openinframap ne se réactualise plus
>> > depuis qques jours
>> > aucune nouvelle ligne electrique n'apparait dans ce secteur
>> >
>> > j'ai viré cookie, cache, ...
>> >
>> > je ne vois pas
>> >
>> > Laurent
>> >
>> >
>> > Le dim. 19 août 2018 à 19:54, François Lacombe
>> > > > > a écrit :
>> >
>> > Bonjour
>> >
>> > Environ 1 cache de 24h
>> >
>> > François
>> >
>> > Le dim. 19 août 2018 à 19:38, Laurent Combe
>> > mailto:laurent.co...@free.fr>>
>> a
>> > écrit :
>> >
>> > Bonjour
>> >
>> > Savez-vous a quelle fréquence se regénère les tuiles
>> > d'OpenInfraMap ?
>> >
>> > Laurent
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > 
>> > https://lists.openstreetmap.org/listinfo/talk-fr
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org > 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
>> >
>> > ___
>> > 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
>> >
>>
>> ___
>> 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

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

[Charles MILLET]

Merci beaucoup pour tes précisions Marc !

Je suis globalement d'accord avec tes arguments pour ce qui est de la 
redondance, j'attends un peu d'avoir à nouveau les explications des 
"pour" avant d'avoir un avis définitif.


Effectivement ce serait assez cohérent d'utiliser substitution:route_ref

On 12/10/2018 12:58, marc marc wrote:

Bonjour,

Le 12. 10. 18 à 11:24, Charles MILLET a écrit :

Pour résumer tu n'est pas pour parce que tu n'est déjà
pas pour le route_ref ?

oui en résumé c'est exactement cela. je suis contre subtitution:lines
permanent parce que je suis contre l'utilisation permanente de route_ref

Si c'est un tag temporaire comme un étape intermédiaire renseignant
les informations destiné à la création des relations, c'est utile
mais autant garder la même logique et créer subtitution:route_ref
Et je passerai à la relation même imparfaite dès que possible.


https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :
[route_ref=* can easily be added to individual bus stops without knowing
the whole route a service takes. It can serve as a basis to add the full
route relation LATER on]

je partage cet avis :
route_ref est utile quand il est utilisé temporairement "je suis passé
devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter
PLUTARD à la relation par ex avec un outil + adapté", c'est donc
à mes yeux signe de "ce n'est pas finit, il y a des choses à faire".
(même si je trouve qu'utiliser une clef spécifique pour une note/fixme
dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à
requêter" et si chaque catégorie de donnée utilisait une clef
différente, ce serrait pas génial)

mais quand il est permanent, c'est une donnée dupliquée avec la galère
que cela implique à chaque fois qu'il y a une différence entre les 2 :
si un utilisateur vire route_ref sans virer l'arrêt de la relation,
cela signifie-t-il que l'arrêt n'est plus desservit et qu'il faut
virer de la relation ? ou cela signifie-t-il qu'il a juste viré
une clef qu'il trouve inutile ?
Idem quand route_ref est présent mais différent des relations,
pour en avoir corrigé un bon paquet, quelle perte de temps à faire
une 2ieme fois les modifs en devinant le sens de la désynchro.
J'ai croisé des désynchro qui avait des années... c'est un peu
comme les notes non traitée, on a l'info mais faut quelqu'un
repasse une 2ieme fois pour que cela deviennent utilisable.


on est pas mal dans cette situation au final sauf qu'au lieu
d'utiliser route_ref qui ne serait pas adapté et risquerait de parasiter
cette clé, on propose d'utiliser : substitution=yes +
subtitution:lines=* qui ont une vocation plus temporaire
(1 an, 2 ans ?).

en temporaire oui pourquoi pas.
dans cette optique, autant aller jusqu'au bout avec
subtitution:route_ref qui dit clairement que cela a pour but
à terme d'être ajouté dans une relation de substitution.
mais il ne faudrait pas en arriver à "durabiliser" ce "fixme"
hors on va le mettre dans le wiki comme façon de tager un arrêt
de substitution
puis il y aura la tentation de faire un umap
ou n'importe quoi d'autre pour montrer l'avancement..
et du coup le temporaire devient permanent...
Tu parles de 2 ans...
pq pas faire une relation imparfaite ? une relation ligne de bus
qui contient juste les quelques arrêts identifié dans le mois,
ce n'est pas complet mais c'est utilisable, un tag wiki sur
la relation vers la page qui explique l'expérimentation,
il serra toujours temps + tard d'affiner.
Mais je comprend/partage l'avis que la relation n'est pas
la priorité quand vous en êtes à l'étape d'identifier les arrêts.


Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile
de la rejeter, perdre son utilité juste pour gagner en "pureté"
de la données ?

Le problème principal ce n'est pas la pureté.
C'est le fait qu'avoir les données de 2 manières différentes implique
que par erreur ou par méconnaissance, certains contributeurs vont
modifié l'un, d'autre vont modifier l'autre et tu finis par avoir
des données de moindre qualité que si tu as une seule manière
de le renseigner.
Idem pour l'utilisation des données : certains vont utiliser l'un
parce que + présent au début, d'autre vont utiliser l'autre...
et donc les outils n'auront qu'une vision partielle des données,
sauf à devoir se farcir les 2 manières et donc le temporaire
devient "durable".


Bon voilà, j'oserai plus utiliser des notes ;)

:) à bon escient :)

Cordialement,
Marc
___
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

[OSM-talk-be] Foss4g : register for your free ticket

[joost schouppe]

Hi,

In October 25th, there will be another Belgian Foss4g conference. This is
the yearly event bringing together open source geo developers and users.
There will also be some OpenStreetMap related presentations: about
switching to OSM by Jonathan Beliën and about mapping future change by
yours truly.

We hope to see you there!

Program and registration through the website:
https://2018.foss4g.be/
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

[marc marc]

Bonjour,

Le 12. 10. 18 à 11:24, Charles MILLET a écrit :
> Pour résumer tu n'est pas pour parce que tu n'est déjà 
> pas pour le route_ref ?

oui en résumé c'est exactement cela. je suis contre subtitution:lines 
permanent parce que je suis contre l'utilisation permanente de route_ref

Si c'est un tag temporaire comme un étape intermédiaire renseignant
les informations destiné à la création des relations, c'est utile
mais autant garder la même logique et créer subtitution:route_ref
Et je passerai à la relation même imparfaite dès que possible.

> https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :
> [route_ref=* can easily be added to individual bus stops without knowing 
> the whole route a service takes. It can serve as a basis to add the full 
> route relation LATER on]

je partage cet avis :
route_ref est utile quand il est utilisé temporairement "je suis passé 
devant l'arrêt, il désert la ligne 42, je le renseigne pour l'ajouter 
PLUTARD à la relation par ex avec un outil + adapté", c'est donc
à mes yeux signe de "ce n'est pas finit, il y a des choses à faire".
(même si je trouve qu'utiliser une clef spécifique pour une note/fixme 
dédié aux lignes c'est une mauvaise idée, c'est "une chose de + à 
requêter" et si chaque catégorie de donnée utilisait une clef 
différente, ce serrait pas génial)

mais quand il est permanent, c'est une donnée dupliquée avec la galère 
que cela implique à chaque fois qu'il y a une différence entre les 2 :
si un utilisateur vire route_ref sans virer l'arrêt de la relation,
cela signifie-t-il que l'arrêt n'est plus desservit et qu'il faut
virer de la relation ? ou cela signifie-t-il qu'il a juste viré
une clef qu'il trouve inutile ?
Idem quand route_ref est présent mais différent des relations,
pour en avoir corrigé un bon paquet, quelle perte de temps à faire
une 2ieme fois les modifs en devinant le sens de la désynchro.
J'ai croisé des désynchro qui avait des années... c'est un peu
comme les notes non traitée, on a l'info mais faut quelqu'un
repasse une 2ieme fois pour que cela deviennent utilisable.

> on est pas mal dans cette situation au final sauf qu'au lieu 
> d'utiliser route_ref qui ne serait pas adapté et risquerait de parasiter 
> cette clé, on propose d'utiliser : substitution=yes + 
> subtitution:lines=* qui ont une vocation plus temporaire 
> (1 an, 2 ans ?).

en temporaire oui pourquoi pas.
dans cette optique, autant aller jusqu'au bout avec 
subtitution:route_ref qui dit clairement que cela a pour but
à terme d'être ajouté dans une relation de substitution.
mais il ne faudrait pas en arriver à "durabiliser" ce "fixme"
hors on va le mettre dans le wiki comme façon de tager un arrêt
de substitution
puis il y aura la tentation de faire un umap
ou n'importe quoi d'autre pour montrer l'avancement..
et du coup le temporaire devient permanent...
Tu parles de 2 ans...
pq pas faire une relation imparfaite ? une relation ligne de bus
qui contient juste les quelques arrêts identifié dans le mois,
ce n'est pas complet mais c'est utilisable, un tag wiki sur
la relation vers la page qui explique l'expérimentation,
il serra toujours temps + tard d'affiner.
Mais je comprend/partage l'avis que la relation n'est pas
la priorité quand vous en êtes à l'étape d'identifier les arrêts.

> Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile 
> de la rejeter, perdre son utilité juste pour gagner en "pureté" 
> de la données ?

Le problème principal ce n'est pas la pureté.
C'est le fait qu'avoir les données de 2 manières différentes implique 
que par erreur ou par méconnaissance, certains contributeurs vont 
modifié l'un, d'autre vont modifier l'autre et tu finis par avoir
des données de moindre qualité que si tu as une seule manière
de le renseigner.
Idem pour l'utilisation des données : certains vont utiliser l'un
parce que + présent au début, d'autre vont utiliser l'autre...
et donc les outils n'auront qu'une vision partielle des données,
sauf à devoir se farcir les 2 manières et donc le temporaire
devient "durable".

> Bon voilà, j'oserai plus utiliser des notes ;)
:) à bon escient :)

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

Re: [OSM-talk-fr] Comment taguer une piste cyclable à double sens sur chaussée ?

[Stéphane Péneau]

Le 12/10/2018 à 11:25, marc marc a écrit :
mais ce n'est pas un avis international :) 

Écris-le en anglais, et il le deviendra :-)

...je sors...

Stf

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

Re: [OSM-talk-fr] Cartographie des arrêts de bus de substitution de la ligne RER C

[Charles MILLET]

Merci pour ton retour (plus des commentaires dans le corps).

Pour résumer tu n'est pas pour parce que tu n'est déjà pas pour le 
route_ref ?


Pourtant si on regarde cette page 
https://wiki.openstreetmap.org/wiki/Key:route_ref et cette remarque :


[route_ref=* can easily be added to individual bus stops without knowing 
the whole route a service takes. It can serve as a basis to add the full 
route relation later on]


...on est pas mal dans cette situation au final sauf qu'au lieu 
d'utiliser route_ref qui ne serait pas adapté et risquerait de parasiter 
cette clé, on propose d'utiliser : substitution=yes + 
subtitution:lines=* qui ont une vocation plus temporaire (1 an, 2 ans 
?). Moi ça me semble plus adapté dans un premier temps plutôt que de 
mettre beaucoup d'énergie à mettre en place une relation (et j'aime les 
relations ;) qui sera encore plus difficile à maintenir. Je propose de 
voir ça dans un second temps.


J'attends aussi les arguments de Florian mais je crois qu'il est cloué 
au lit en ce moment.


On 11/10/2018 18:15, marc marc wrote:

Le 11. 10. 18 à 17:05, Charles MILLET a écrit :

Nous pensons utiliser quelque chose comme ça
substitution=yes

sur l'arrêt de bus, pour ma part je ne rajouterais pas de tag
en particulier, c'est un arrêt de bus, y dupliquer l'information
de tous les type de lignes pouvant éventuellement l'utiliser ne semble
à la fois peu pratique et surtout galère à maintenir (parce qu'à chaque
changement, il faut veiller à dupliquer le changement pour garder
la cohérence, faire une analyse osmose ou autre pour surveiller
les inévitables désynchronisation entre les 2 et avoir quelqu'un
qui passe du temps à resynchroniser les données).
Je pense que l'utilisation des données du type de ligne qui passe
à un arrêt doit se faire par les infos de(s) relation(s) de l'arrêt.
Mais je sais qu'on a au moins 2 champions de la duplication dans
la communauté qui ne manqueront pas de faire valoir l'inverse :-)
Oui il faudrait une relation pour décrire ces lignes temporaires mais là 
il s'agit de décrire que l'arrêt de bus fait aussi l'objet d'un arrêt de 
substitution


Tu parles de la clé route_ref c'est ça ? Est-ce vraiment utile de la 
rejeter, perdre son utilité juste pour gagner en "pureté" de la données 
? Je crois que c'est un autre débat, comme je n'y ai pas trop participé 
je donne rapidement mon avis à ce sujet :  je suis pour la redondance 
des lignes sur les arrêts dans la mesure où elle ne pose pas de 
problèmes et apporte des informations très utiles.





subtitution:lines=RER C

pour les relations représentant les lignes,
Une possibilité serrait d'avoir exactement le même nom
et donc j'aurais plutôt vu quelque chose genre
name=RER C (mais j'ai vu que le nom des lignes RER est un mix entre
le nom, le from, le to, la ref et la branche...)
substitution=only (la ligne n'existe que quand l'autre est en panne)
substitution:of=train (elle remplace une relation train)
et éventuellement sur la relation du RER C:
substitution:by=bus
en ajoutant l'itinéraire de substitution dans la relation route_master
on pourrait sans doute faciliter une utilisation futur + poussée.
le soucis que je vois c'est que c'est pas prévu d'avoir des route=bus
fils d'une relation route_master=train
ce serrait sans doute utile d'en discuter sur tagging
avec une exemple de relation bus comparable à la relation rer
histoire de rendre la chose compréhensible pour ceux qui n'ont
rien de semblable chez eux.
c'est sans doute un peu prématuré si pour le moment vous en êtes
aux arrêts de bus eux-même.
Les relations, si elles existent un jour, ne sont pas pour tout de 
suite, c'est un peu compliqué de me plonger dans une réflexion sur la 
façon de les taguer.



Ces tag pourrons être complétés par une note au besoin.

les notes peuvent être utile pendant l'expérience sur la première
relation mais à long terme, des outils/contributeurs considèrent
la note comme étant souvent le signe que c'est pas stable d’où
le besoin de transmettre une information et qu'il faut donc
un éventuel coup de main pour transformer la note en tag + adapté.
url=la page wiki sur le changeset serrait très utile pour le
contributeur qui veux en savoir plus sur le projet.

Bon voilà, j'oserai plus utiliser des notes ;)


Cordialement,
Marc
___
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

Re: [OSM-talk-fr] Espace de coworking qui croire entre iD et le wiki OSM

[François Lacombe]

Bonjour Jean-Christophe,

La politique d'iD est de ne créer des presets que sur les tags les plus
utilisés.
Ceci sans tenir compte de ce qui est écrit sur le wiki (notamment pendant
les périodes de transitions ancien => nouveau tag), il faut donc suivre le
wiki.

Je n'ai pas d'avis sur le cas particulier de amenity vs office.

Bonne journée

François

Le ven. 12 oct. 2018 à 07:51, Jean-Christophe Becquet  a
écrit :

> Bonjour,
>
> Pour un Espace de coworking
> https://www.openstreetmap.org/node/5954418134
>
> iD me propose le tag
> office=coworking
>
> Le wiki dit
> amenity=coworking_space
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcoworking_space
>
> et office=coworking est une Page de redirection vers
> amenity=coworking_space
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:office%3Dcoworking=no
>
> sur taginfo amenity=coworking_space (854) gagne légèrement contre
> office=coworking (598).
> https://taginfo.openstreetmap.org/tags/?key=amenity=coworking_space
> https://taginfo.openstreetmap.org/tags/?key=office=coworking
>
> Bref qui croire entre iD et le wiki OSM ?
>
> Merci par avance pour vos éclaircissements
>
> Bonne journée
>
> JCB
> --
> Il y aura un retour d'expérience "Cartographies participatives avec les
> habitants" par Jean-Christophe Becquet, avec pour support #OpenStreetMap.
> https://twitter.com/OsmGrenoble/status/104695420100610
>
> ==APITUX : le choix du logiciel libre==
>
> APITUX - Jean-Christophe Becquet
> BP 32 - 04001 Digne-les-Bains Cedex
> 06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
> SIRET : 452 887 441 00031 - APE : 6202A
>
> ===
>
>
>
>
> ___
> 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

Re: [OSM-talk-fr] Comment taguer une piste cyclable à double sens sur chaussée ?

[marc marc]

Le 12. 10. 18 à 11:15, Charles MILLET a écrit :
> Le choix des way multiple est déjà celui recommandé ! (cf. T1 
> https://wiki.openstreetmap.org/wiki/Bicycle)
> 
> Je veux bien qu'on remette ça en question et qu'on vérifie si ce n'est 
> pas quelque chose qui a été introduit de manière cavalière mais on va 
> pas faire la même chose non plus dans l'autre sens.
> 
Le 12. 10. 18 à 10:34, Charles MILLET a écrit :
> Quelqu'un peut me dire où il est question de l'avis international en 
> faveur de "cycleway=track" ?
il n'existe pas un unique lieu d'avis international,
il y a :
- le wiki (tant la pagecycliste que la page qui explique
qu'on fait 2 way lorsqu'il y a un obstacle entre les 2)
- la mailling tagging
- et même s'il veux pas l'entendre, la communauté locale est un avis à 
prendre en compte. on devrait s'uniformer au niveau mondial mais c'est 
pas une raison pour ne pas tenir compte du local.
au lieu d'essayer de deviner ce qu'il prend comme source,
le mieux serrait de lui demander ou de lui montrer que sur la page des 
cyclistes avec le cas T1 dit clairement que plusieurs ways sont recommandé,
l'utilisation d'un seul way étant une version simplifiée quand on n'a 
pas tous les éléments" ou quand on veux faire "un premier jet simplifié 
qu'on raffinera + tard

> sens, puisqu'on a déjà du mal à définir des règles claire pour choisir 
> entre un way propre et un tag sur la chaussée, on va encore créer du 
> flou sur le sujet.
pourtant même moi le grand partisan d'un non excès des way séparé,
je trouve qu'il se trompe. mais ce n'est pas un avis international :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] ?==?utf-8?q? Comment taguer une piste cyclable à double sens sur chaussée ?

[Charles MILLET]

Le choix des way multiple est déjà celui recommandé ! (cf. T1 
https://wiki.openstreetmap.org/wiki/Bicycle)


Je veux bien qu'on remette ça en question et qu'on vérifie si ce n'est 
pas quelque chose qui a été introduit de manière cavalière mais on va 
pas faire la même chose non plus dans l'autre sens.


Bon en même j'ai pas pris de le temps de mettre en place un vrai débat à 
ce sujet la dernière fois qu'on en a parlé.. J'ai pas mal de boulot en 
retard sur ces sujets.


On 03/10/2018 17:34, Axelos wrote:

Coucou,

Le Mercredi, Octobre 03, 2018 09:19 CEST, Thomas Ruchin  a 
écrit:

Question subsidiaire. S'il persiste, puis je demander le soutien du DWG
avant que cela ne dégénère en guerre d'édition. De ce qu'il m'écrit, il
n'accepte que les argument de la communauté "internationale".

Je pense qu'il s'agit d'une incompréhension. Je te suggère de suivre son choix 
et de lui proposer de mettre à jour la page wiki version anglaise bicycle cas 
T2 en mettant le choix du chemin unique en recommandé, ce qui correspondra à 
l'avis international.


___
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

Re: [OSM-talk-fr] Ref A, N, D, C ... M ?

[Jean-Christophe Becquet]

Le département des Alpes de Haute-Provence vient de publier en opendata
2 jeux de données qui pourraient être utiles :

Description du réseau routier des Alpes de Haute-Provence (départemental
et national).
https://trouver.datasud.fr/dataset/routes-departementales-alpes-de-haute-provence

Points de repère du réseau routier départemental (Alpes de Haute-Provence)
https://trouver.datasud.fr/dataset/points-de-repere-du-reseau-routier-departemental-alpes-de-haute-provence

JCB
-- 
Il y aura un retour d'expérience "Cartographies participatives avec les
habitants" par Jean-Christophe Becquet, avec pour support #OpenStreetMap.
https://twitter.com/OsmGrenoble/status/104695420100610

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===


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

Re: [OSM-talk-fr] ?==?utf-8?q? Comment taguer une piste cyclable à double sens sur chaussée ?

[Charles MILLET]

Quelqu'un peut me dire où il est question de l'avis international en 
faveur de "cycleway=track" ? Parce que si on change le wiki dans ce 
sens, puisqu'on a déjà du mal à définir des règles claire pour choisir 
entre un way propre et un tag sur la chaussée, on va encore créer du 
flou sur le sujet.


On 03/10/2018 17:34, Axelos wrote:

Coucou,

Le Mercredi, Octobre 03, 2018 09:19 CEST, Thomas Ruchin  a 
écrit:

Question subsidiaire. S'il persiste, puis je demander le soutien du DWG
avant que cela ne dégénère en guerre d'édition. De ce qu'il m'écrit, il
n'accepte que les argument de la communauté "internationale".

Je pense qu'il s'agit d'une incompréhension. Je te suggère de suivre son choix 
et de lui proposer de mettre à jour la page wiki version anglaise bicycle cas 
T2 en mettant le choix du chemin unique en recommandé, ce qui correspondra à 
l'avis international.


___
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

Re: [Talk-de] Smoothness nur für Wege oder auch für Straßen

[Martin Scholtes]

Ich stimme Sepp zu.

Am 11.10.2018 um 21:28 schrieb sepp1...@posteo.de:
> Michael,
>
> würdes Du bitte, wenn Du von Neuen Bundesländern sprichst, bzw.
> schreibst, im Umkehrschluss auch von Gebrauchten Bundesländern schreiben?
>
> Das Straßenproblem ist also ein Problem DEUTSCHLANDWEIT und die ein
> oder andere Betonplatte hält bereits mehrere Jahrzehnte, d.h. deutlich
> länger als ein vergleichbarer Straßenbelag aus Asphalt und ein alter
> Pflasterunterbau ist aus straßenbautechnischer Sicht allemal
> haltbarer, als die oben drauf geschmierte Asphaltdecke.
>
> Das nur nebenbei.
>
> Sepp
>
> Am 11.10.2018 19:36 schrieb Michael Reichert:
>> Hallo Andreas,
>>
>> Am 11.10.2018 um 16:21 schrieb Andreas Meier:
>>> Hallo,
>>> Mich würde ein Stimmungsbild interessieren: bisher tagge ich
>>> Smoothness nur an Radwegen, Fußwegen und Tracks/Paths. Residential
>>> Highways nicht, weil die fast immer good bis excellent sind und ich
>>> keine sinnlose Redundanz massenhaft erzeugen will wo sie keinen
>>> nützt. Im Wiki scheint dazu nichts zu stehen.
>>
>> Welch Glücklicher, der du in einer Gemeinde lebst, deren Straßenbeläge
>> frei von Schlaglöchern und anderen Unebenheiten sind. Leider besteht
>> Deutschland nicht nur aus frisch asphaltierten Straßen und gerade in den
>> neuen Bundesländern gibt es zahlreiche Straßen von
>> residential/unclassified bis secondary, die mit uralten Pflastersteinen,
>> zerbröselten/zerbröselnden Betonplatten oder mit Asphalt bedeckten
>> Pflastersteinen befestigt sind. Genau diese Pisten, ähh Straßen, sind
>> der Grund, warum ich smoothness=* erfasse.
>>
>> Anmerkung: Auch im Westen gibt es Straßen, die ich als Nutzer eines
>> ungefederten Fahrrads aus Komfortgründen meide, weil sie entweder mit
>> Kopfsteinpflaster befestigt sind oder mehr aus Flicken als aus
>> originalem Fahrbahnbelag bestehen.
>>
>> Anders ausgedrückt, es ist gerechtfertigt praktisch alle Straßen bis
>> hoch zu secondary oder stellenweise sogar primary mit smoothness zu
>> erfassen.
>>
>> Viele Grüße
>>
>> Michael
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-de
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

[Talk-it] Alberi monumentali

[Cascafico Giovanni]

L'anno scorso Borruso si era impegnato ad adattare i disordinati fogli
excel del ministero in un dataset utilizzabile. Ad agosto 2018 sono stati
integrati ulteriori alberi, fatte (forse) le correzioni.

Nel mezzo (aprile 2018) la regione Friuli Venezia Giulia (recependo le
direttive ministeriali) ha pubblicato come "dato pubblico" il dataset degli
alberi monumentali. Sul portale nazionale non viene tuttora specificata
nessuina licenza, quindi credo che per anche per il resto d'Italia la
definizione spetti alle regioni.

Ho impostato una umap [1] per valutare il dato geo.

https://umap.openstreetmap.fr/en/map/alberi-monumentali_255685
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Modification de tags en masse dans JOSM

[Philippe Verdy]

Encore une fois une mauvaise idée: la modif en masse ne va pas tenir compte
des voies à tronçonner et les limites ne sont pas exactement celle de la
métropole. Il vaut mieux se fier à des listes open data émises par les
métropoles sur les routes dont la gestion leur a effectivement bien été
gérée.
De plus il n'est pas dit que la numérotation soit identique (on l'a vu avec
les transferts de nationales en départementales, les chiffres des centaines
ou supérieurs sont fréquemment changés pour éviter des doublons avec
d'autres voies départementales déjà existantes ailleurs).
Attendons au moins les textes des arrêtés, et la publication des mises à
jour des fichiers de la métropole, et ensuite vérifions les sections de
routes concernées : une départementale qui traverse plusieurs fois la
limtie de métropole ou ne fait qu'y transiter sur une section très courte
ne va pas changer de numérotation pour quelques centaines de mètres ou même
juste quelques kilomètres si cette section ne connecte pas au moins deux
communes ou agglomérations de la métropole.
Bref une modif à l'aveugle "D*" en "M*" ne va faire que produire des
erreurs (et même si on le fait sur une liste, il serait bon de garder
"old_ref=D*" pour pouvoir annuler facilement, d'autant plsu que les
panneaux ne changeront pas du jour au lendemain et qu'on aura encore besoin
pendant quelques temps des anciens numéros.
Ce qui est "robotisable" en revanche c'est **d'ajouter** un
"planned:ref=M*" et ensuite demander un passage en revue pour voir quand
cela va réellement changer (ou pas) : on peut l'indiquer en ajoutant aussi
un FIXME:ref="renumérotation future planifiée depuis le jj/mm/", qui
fait apparaître des notes dans Osmose par exemple sur ce qui est encore
incertain.

Le jeu. 11 oct. 2018 à 19:25, Nicolas Moyroud  a écrit :

> Bonjour à tous,
>
> J'avais déjà posé la question mais elle était noyée dans un autre fil de
> discussion, comme personne n'a répondu je me permet de la reposer dans
> ce fil spécifique.
>
> Je voulais savoir si il y en a parmi vous qui savent comment avec JOSM
> on peut modifier en masse seulement une partie de la valeur d'un tag. Ce
> que je voudrais faire par exemple c'est modifier pour le tag ref="D 165"
> le D en M. Le problème c'est que j'aimerai faire la modification pour
> toutes les valeurs différentes ref="D*" en un seul coup. J'ai une astuce
> pour ça qui consiste à sauver dans un fichier OSM et modifier avec
> l'éditeur de texte puis recharger le fichier dans JOSM. Mais c'est un
> peu tordu et si je pouvais le faire direct avec JOSM ce serait plus simple
> !
>
> Nicolas
>
>
> ___
> 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

[Talk-it] Mancata attribuzione - Comune di Vercelli

[Simone Saviolo]

Ciao a tutti,

mi spiace dover segnalare una violazione della licenza (mancata
attribuzione su un'opera derivata) da parte del Comune di Vercelli. Mi
spiace perché è il mio Comune, e perché negli scorsi anni ho incontrato
alcuni assessori e tecnici per sensibilizzare sul tema open data e OSM.

Sabato e domenica si terrà a Vercelli il raduno degli Alpini, e il Comune
ha pubblicato questa mappa delle strade chiuse al traffico:
https://www.comune.vercelli.it/articolo/21deg-raduno-alpino-del-primo-raggruppamento

La cartina è basata su OSM (tiro a indovinare che sia una mappa dei
parcheggi dai cerchietti con numerino, che corrispondono a occhio e croce a
raggruppamenti dovuti allo zoom), con sovrimpressioni (belle, per una
volta) aggiunte dal Comune stesso.

Come devo procedere?

Grazie,

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

[OSM-talk-fr] Ajout de limites de vitesse à l'aveugle

[pepilepi...@ovh.fr]

Le 11/10/2018 à 10:53, marc marc a écrit :
> Le 10. 10. 18 à 22:08, Sébastien Dinot a écrit :
>> Avez-vous une idée pour remédier à ce problème de manière efficace 
>> et un peu plus subtile ?
> faire un revert "à l'aveugle" de l'ensemble de ces doubles changements 
> de vitesse puis aller voir sur le terrain la réalité

Bonjour,

Juste pour ma culture : n'importe quel contributeur peut faire un revert
d'un changeset de n'importe quel autre contributeur ?

Merci,

JP

> ___
> 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