Re: [Talk-es] Qué poner en source cuando la fuente es una guía, catálogo o hemeroteca...

[dcapillae]

Citar una fuente en un trabajo académico o en un artículo de la Wikipedia no
es lo mismo que reutilizar una información y citar la fuente, que es lo que
se pretende. En OSM no usamos las fuentes como se usan en un trabajo
académico o en la Wikipedia: no consultamos fuentes y luego creamos un
trabajo original de investigación o un artículo de Wikipedia de elaboración
propia, igualmente original. En el caso del periódico, nosotros tomamos una
información que no nos pertenece, que no es generada por nosotros, y la
reproducimos (sin permiso) por otros medios, autorizando su reutilización
para fines para los que quizás no tengamos derecho, como puede ser el uso
comercial. Eso es algo más que citar una fuente. O mejor dicho, no es lo
mismo que citar una fuente (en un trabajo académico).

Como decía Miguel en un mensaje previo: 


Miguel Sevilla-Callejo wrote
> Recuerda que el espíritu original de OSM está en que nosotros generemos
> nuestra propia información espacial [...] Es más, si no podemos contrastar
> ínsito esa información quizá no tenga cabida en la base de datos que es
> OSM.

Si lo que dice el periódico lo comprobamos por nosotros mismos y lo subimos
a OSM, entonces no habría problema. En ese caso, la información compartida
en OSM no sería la generada por el periódico, sino la generada por nosotros.

Si no está claro si una información se puede reutilizar, creo que lo mejor
sería presuponer que no se puede usar y, en todo caso, tratar de contactar
con el titular de la información para conocer las condiciones de uso y pedir
autorización si fuese necesario. Muchas fuente publicadas bajo condiciones
de licencia Creative Commons, supuestamente con vocación de ser
reproducibles, generan no pocos problemas para integrarse en OSM, así que
conviene ser prudentes con estos temas.

Haría falta un abogado especialista para salir de todas las dudas que surgen
cuando nos enfrentamos con la protección de los derechos de autor. Como
probablemente pocos de nosotros seamos especialistas en ese campo, sugiero
seguir la estrategia más conservadora, no usar ninguna información que no
sea pública o recopilada directamente por nosotros sobre el terreno, y usar
sólo fuentes expresamente autorizadas o claramente compatibles sin duda
alguna con la ODbL.



-
Daniel Capilla 
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-es] Qué poner en source cuando la fuente es una guía, catálogo o hemeroteca...

[David Marín Carreño]

A ver... Tengo serias dudas de que al extraer información, no geolocalizada
inicialmente, desde un periódico para ponerla en el mapa a través de un
proceso no automatizado y que requiere un proceso de la transformación de
datos manual (y mental) importante, un periódico pudiera conservar el
copyright de dicha información.

Por esa regla de tres, el copyright de la Wikipedia, de un proyecto fin de
carrera o de una tesis doctoral sería el de todas sus fuentes.

Una cosa es importar datos, y otra muy distinta es inferir datos.

Por ello, mi duda para responder a esta pregunta es: ¿De qué clase de datos
estás hablando? ¿Se puede poner un ejemplo concreto de extracción de datos
de un catálogo o una hemeroteca?

Un cordial saludo,

El lun., 15 oct. 2018 1:34, dcapillae  escribió:

> Hola.
>
> Debes indicar la fuente que tú usaste, no la fuente que uso dicha fuente.
> Por tanto, en el caso del periódico local (caso 1), debes indicar el
> periódico, no la fuente que uso el periódico. Si el periódico publicó esa
> información bajo condiciones de licencia restrictivas (protegida por
> derechos de autor), tendrás que pedir permiso si quieres citar al periódico
> en OSM. No podemos usar información protegida por derechos de autor,
> únicamente información en dominio público o procedente de fuentes abiertas
> cuyas condiciones de licencia sean compatibles con las condiciones de
> licencia ODbL. Si no puedes encontrar esa misma información a través de
> otras fuentes (autorizadas), no la uses.
>
> En cuanto al nombre de las calles (caso 2), yo no me complicaría demasiado
> citando la fuente, salvo que sea una fuente autorizada y la estés usando de
> forma sistemática. El nombre de las calles se puede verificar sobre el
> terreno, así que siempre podrás citar como fuente tu conocimiento local
> («source=local knowledge») o el reconocimiento del terreno
> («source=survey»), según sea el caso. Nunca cites (ni uses) una fuente que
> no esté claro que se pueda usar.
>
> Respecto a la guía de arte urbano (caso 3), es un caso similar al del
> periódico, no puedes usarla como fuente si la obra está protegida por
> derechos de autor. Necesitarás solicitar permiso a los autores o a los
> titulares de los derechos si quieres usarla expresamente citando la fuente.
> No reutilices la información sin permiso. Si pudieses usarla como fuente,
> la
> fuente sería la propia guía, no las diversas fuentes que usaron sus autores
> para elaborarla. Lo que sí puedes hacer es usar la guía como referencia
> para
> obtener esa misma información a partir de otras fuentes o sobre el terreno.
> De una obra de arte público siempre se puede conocer su ubicación, quizás
> también su nombre, su autor o la fecha de creación. Cualquier otra
> información que te ofrezca esa guía y que no puedas obtener a través de
> otras fuentes (autorizadas) o sobre el terreno, no deberías usarla.
>
> P. D.: Anteriormente se colocaba la etiqueta «source=*» en los elementos de
> OSM (nodos, vías, relaciones). Esta práctica está en desuso y desaconsejada
> actualmente. Ahora únicamente se usa la etiqueta «source=*» en los
> conjuntos
> de cambios.
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> 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

Re: [OSM-ja] 日本にVillage Greenとタグ付けできる場所は存在していますか?

[bnj_2_h]

松村です。
leisure=commonというのもありました。
https://wiki.openstreetmap.org/wiki/JA:Tag:leisure=common
共有地（入会地）と説明にあります。こちらはVillage greenのような「法的」な要件はないように思います。


松村英俊(MATSUMURA Hidetoshi)
bnj_...@muf.biglobe.ne.jp ,icar...@mac.com
http://fineview.sakura.ne.jp/

> 2018/10/19 の 23:40 に Keisuke Oki  によって書かれました: 
> 
> "Village Green"が日本に相当するのは'里山'と考えられるのではないでしょうか ？
> 里山は入会地であり 、英語の"Village Green"の説明が" A  village green  is a  
> [common](https://en.wikipedia.org/wiki/Commons)  open area within a  
> [village](https://en.wikipedia.org/wiki/Village)  or other 
> settlement."というところで共通しています 。 
> 
>  日本でも環境省や地方自治体が里山保護を行なっています。全国的に里山やそれに類するエリアをVillage 
> Greentと考えるのは適していると思いますが、いかがでしょう？
> 下記は東京の例です： 
>  https://tokyo-satoyama.jp/
> 
> 沖啓介
> 
> 2018年10月19日(金) 22:58 MATSUMURA Hidetoshi < bnj_...@muf.biglobe.ne.jp>: 
> > 松村です。 
> > 
> >  調べてみたら、JOSMのvillage_greenの翻訳が「緑地公園」になっていました。 
> > 
> >  Overpass turboとかで検索すると「◯◯緑地」に対して使われているケースが多いので、これが影響しているのかもしれないです。 
> > 
> >  iPhoneから送信 
> > 
> >  2018/10/19 14:54、Jun Nogata < noga...@gmail.com>のメール: 
> > 
> > > hayashiさん、岩崎さん 
> > > 
> > > 野方です。 
> > > 
> > > Village_greenは、共有地という意味ではhayashiさんの書かれた入会地に近いんですが、 
> > > 共同管理公園的な意味もあって方向性がちょっと違う感じなんですよね。 
> > > 
> > > それと、入会地をタグ付けしたとしても東京にこんなにそういう場所があるの? 
> > > http://overpass-turbo.eu/s/CUF 
> > > という疑問もあります。 
> > > 
> > > 調べると九州以外でもvillage_greenでタグ付けされてるところがかなりありました。 
> > > 
> > > ということで今、日本で使われているvillage_greenはタグ付けの誤用では?という疑問と 
> > > そして、village_greenをタグ付けするならどんな場所?という疑問があります。 
> > > 
> > > 入会地を知っててタグ付けをしたなら、それはそれでいいのですが、 
> > > 公園っぽいものをvllage_greenとタグ付けは違う気がするのですが 
> > > ちょっと謎です…。 
> > > 
> > > 
> > > 2018年10月19日(金) 12:19 Nobusuke IWASAKI < wata...@gmail.com>: 
> > >> 
> > >> みなさま 
> > >> 
> > >> いわさきです。 
> > >> 
> > >> hayashiさんのおっしゃる通り、日本にも「入会地」はあります。その名残か、地名に「入会地」と残っている場所もあります。ただこれが、今回議論されているVillage_greenと同じかというと、ちょっと違うようにも感じました。
> > >>  
> > >> 
> > >> Wikipediaでは、「Traditionally, a village green was common grassland at the 
> > >> centre of a rural settlement used for grazing with a pond for watering 
> > >> cattle and other stock.」と記述されており、日本における入会地（入会草地？）とは、ちょっと様相が違うようにも思います。 
> > >> 
> > >> https://en.wikipedia.org/wiki/Village_green 
> > >> 
> > >> 一応、参考までにお知らせします。 
> > >> 
> > >> On 2018/10/18 20:05, yuu hayashi wrote: 
> > >> 
> > >> hayashiです 
> > >> 
> > >> 日本にも「入会地」とよばれる集落の共有地があります。 
> > >> https://ja.wikipedia.org/wiki/%E5%85%A5%E4%BC%9A%E5%9C%B0 
> > >> 
> > >> 私有地でもなく、村有地とも違って、江戸時代以前から集落の共有地として現在も利用されています。 
> > >> イギリスとの違いは集落の中心部ではなく、耕作地の中心部や周辺部にあって、薪や肥料 山菜の共同採集場所として使われます。 
> > >> 
> > >> https://wiki.openstreetmap.org/wiki/JA:Tag:landuse=village%20greenにも 
> > >> 「入会地」という言葉が使われていますし、歴史的形成の過程や役割などからしても 
> > >> Village_greenに「入会地」を割り当てることに問題はないと思います。 
> > >> 
> > >> ちなみに山梨県の私の家の周りは入会地だらけなのですが、そこが入会地かどうかは地元の人にしかわかりません。 
> > >> そのため、入会地をマッピングするのは難しいです。 
> > >> 他の地域の人が知らずに入り込むと「キノコ泥棒」扱いされますのでサーベイしようなどとは思わない方がいいです。 
> > >> 
> > >> 
> > >> 
> > >> 2018年10月18日(木) 0:43 Jun Nogata < noga...@gmail.com>: 
> > >>> 
> > >>> 野方です。 
> > >>> 九州を見ていたら、landuse=village_greenでタグ付けされている場所があり 
> > >>> ました。 
> > >>> 
> > >>> - https://www.openstreetmap.org/way/507693755#map=18/33.51813/130.49285 
> > >>> 
> > >>> Village Greenは、村や地域などが管理する緑地でイギリス独特の場所だと思っ 
> > >>> てて日本には無いものだと思っていたのですが、こういう場所は日本でも存在 
> > >>> するのでしょうか? 
> > >>> 
> > >>> - https://wiki.openstreetmap.org/wiki/JA:Tag:landuse=village%20green 
> > >>> - https://en.wikipedia.org/wiki/Village_green 
> > >>> 
> > >>> イギリスのバンドThe Kinksの歌詞にも出てくるけど、翻訳にも困るような場所 
> > >>> 
> > >>> - https://www.youtube.com/watch?v=lc7dmu4G8oc 
> > >>> - http://d.hatena.ne.jp/komasafarina/20060715#20060715f1 
> > >>> 
> > >>> 公園と間違えたのかと思って、idエディタで公園を検索すると、ちゃんと公園 
> > >>> (leisure=park)が出てくるので間違えたのでもなさそうです。 
> > >>> 
> > >>> ということで、Village Greenは自分が知らないだけで、日本にそういう場所 
> > >>> が存在しているのでしょうか? 
> > >>> 
> > >>> -- 
> > >>> 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com 
> > >>>                     - web: http://www.nofuture.tv/diary/ 
> > >>> ___ 
> > >>> Talk-ja mailing list 
> > >>> Talk-ja@openstreetmap.org 
> > >>> https://lists.openstreetmap.org/listinfo/talk-ja 
> > >> 
> > >> 
> > >> ___ 
> > >> Talk-ja mailing list 
> > >> Talk-ja@openstreetmap.org 
> > >> https://lists.openstreetmap.org/listinfo/talk-ja 
> > >> 
> > >> ___ 
> > >> Talk-ja mailing list 
> > >> Talk-ja@openstreetmap.org 
> > >> https://lists.openstreetmap.org/listinfo/talk-ja 
> > > 
> > > 
> > > 
> > > -- 
> > > 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com 
> > >                     - web: http://www.nofuture.tv/diary/ 
> > > ___ 
> > > Talk-ja mailing list 
> > > Talk-ja@openstreetmap.org 
> > > https://lists.openstreetmap.org/listinfo/talk-ja 
> >  ___ 
> >  Talk-ja mailing list 
> >  Talk-ja@openstreetmap.org 
> >  https://lists.openstreetmap.org/listinfo/talk-ja
> 
> ___ 
> Talk-ja 

Re: [OSM-talk] OpenStreetMap Carto release v4.16.0

[Daniel Koć]

W dniu 19.10.2018 o 07:39, Maarten Deen pisze:

> Does this mean that amenity=atm only gets rendered in zoom 19 and
> higher? If so, why? It is now rendered from 17 onward, shops get
> rendered from 18 onward.
> It seems to me that atms are at least as important as shops.


Yes, you get it right. I based this solution on size principle, because
this is the only universal rule I know that helps managing the mess
which is best visible on z17 in big, well mapped cities. Here are two
real life illustrations of the problem with small amenities I gave
during long and hot discussion:


https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-423373856
https://github.com/gravitystorm/openstreetmap-carto/pull/3372#issuecomment-426308795


( BTW: I've made a mistake in the subject, so I fix it now - it's
v4.16.0, not v4.15.0 )


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



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

Re: [Talk-es] Fwd: Reconocimiento IGN en OSM

[Santiago Crespo]

Hola,

Acabo de modificar la página de contributors según lo que nos han pedido
desde el IGN (quitar el símbolo de © y poner el texto y enlace a
scne.es/ign.es según corresponda) [1]

Que yo sepa, la situación sigue exactamente igual desde que envié el
correo de Junio que ha enlazado Daniel.

Por si acaso no puedo asistir a la reunión mañana, quiero dejar por aquí
mis propuestas de consenso:

1.- Copiar toda la información de que haga falta de la sección "Our
contributors" de la página de copyright a la página Contributors en la
wiki. Una vez esté todo, solicitar a la OSMF que únicamente deje el
enlace a la página de contributors y elimine el listado histórico de
contribuidores para solucionar el agravio comparativo.

O mejor aún, que pongan un "iframe" o similar para que todos los
contribuidores que estén en la wiki aparezcan por igual en la página de
copyright. Las secciones "Copyright infringement" y "Trademarks" podrían
moverse más arriba para que aparezcan antes de "Our contributors".

2.- Una vez esté resuelto el tema de la atribución "a un click", pedir
al IGN que nos firmen la carta de exención[2] para CC BY 4.0 para todos
sus productos. No sé a quién habría que solicitar esta exención para los
productos del Sistema Cartográfico Nacional, como OrtoPNOA.

Saludos,
Santiago Crespo

[1]
https://wiki.openstreetmap.org/w/index.php?title=Contributors=revision=1683092=1681993

[2] https://wiki.openstreetmap.org/wiki/File:PermisoCCBY.odt


On 10/19/18 2:58 PM, dcapillae wrote:
> Hola, Miguel.
> 
> En el wiki hay un espacio reservado donde anotar todo lo relacionado con el
> IGN [1]: personas de contacto, conversaciones, reuniones, cronología de
> hechos, trabajos de colaboración, etc. Hace unos meses surgieron de nuevo
> los problemas de atribución. Puse un enlace a la lista de correo donde se
> intentó clarificar la cuestión [2].
> 
> Sería bueno que cualquier tema tratado con el IGN se anotase en esa sección
> de la página del wiki, a modo de resumen, para que todos sepamos en
> cualquier momento cuáles son los antecedentes y la situación actual en que
> nos encontramos con respecto al Instituto. Si los que tenéis un trato más
> directo y fluido con el IGN podéis usar ese apartado para resumir los
> detalles, creo que sería de gran utilidad para la comunidad.
> 
> 
> [1]
> https://wiki.openstreetmap.org/wiki/ES:España/Contribuidores#Instituto_Geográfico_Nacional
> [2]
> http://gis.19327.n8.nabble.com/Importaciones2018-Reorganizacion-td5908090i20.html#a5917752
> 
> 
> 
> -
> Daniel Capilla 
> OSM user: dcapillae 
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
> 
> ___
> 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

Re: [Talk-cz] historic=tomb se nerenderuje na Mapniku

[Pavel Pilát]

To je paráda, díky! :-)

On Fri, Oct 19, 2018 at 1:02 PM majka  wrote:

> Nejlépe asi přes overpass turbo, wizard zafunguje pro většinu případů.
> Konkrétně historic=tomb  , je třeba
> najet na odpovídající místo. Nebo by se daly vyhledat všechny v Čechách
>  (celkem 98 bodů)
> On Fri, 19 Oct 2018 at 12:52, Pavel Pilát  wrote:
>
>> Lze mimochodem v OSM hledat přímo objekty s určitým tagem? Např.
>> konkrétně by mě zajímalo, kde je kolem Koryčan další nejbližší
>> historic=tomb .
>>
>> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-ca] Import des arrêts d'autobus de l'ARTM

[Pierre Béland]

Bonjour Claude, 

Je connais peu les relations pour itinéraires de services de transport.
Le groupe de discussion Import de OSM suit de très près tout import. Et la 
question de licence c'est toujours très litigieux. Si pas indiqué OdBL, il faut 
habituellement une autorisation écrite permettant spécifiquement à OSM 
d'utiliser les données.
Licences ; À première vue RTL Longueuil et STL Laval ont la même licence avec 
un libellé indiquant que pas pour fin commerciales 
-> Automatiquement, cela est non conforme à OdBL et donc il faudrait une 
autorisation écrite
 
Pierre 
 

Le vendredi 19 octobre 2018 13 h 55 min 35 s HAE, Alouette955 
 a écrit :  
 
 Bonjour, Il y a quelques temps je lançais une consultation sur ma proposition 
d’import pour les arrêts d’autobus du Réseau de transport Métropolitain, 
maintenant EXO. J’attends incessamment leur autorisation pour l’import avec 
mention sur la page des contributeurs.    
https://wiki.openstreetmap.org/wiki/FR-Import_arr%C3%AAts_d%27autobus,_EXO_r%C3%A9seau_de_transport_m%C3%A9tropolitain
 Tout commentaire sur ma méthodologie est bienvenue. Depuis j’ai compris que 
EXO, tout comme la STM (Montréal), la STL (Laval) et le RTL (Longueuil) sont 
des opérateurs distincts mais qui collaborent sous l’égide de l’ARTM. Un peu 
compliqué mais maintenant clarifié. J’en ai profité pour créer une page pour 
l’ARTM dans le wiki:   
https://wiki.openstreetmap.org/wiki/FR-ARTM_-_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain
 La STL et le RTM ont une licence qui me semble beaucoup plus permissive:   
http://www.rtl-longueuil.qc.ca/fr-CA/donnees-ouvertes/  
https://www.stl.laval.qc.ca/fr/stl-synchro/developpeurs/ (voir à l’encadré 
Conditions d’utilisation) Je songe donc les inclure à mon projet d’import sans 
autre formalité autre de les indiquer dans la page des contributeurs. La 
question est: Aie-je bien compris ces licences?  Il ne me semble pas que 
l’import dans la base de données OSM est une utilisation commerciale ou quasi 
commerciale mais peut-être y a-t-il un précédent qui m’obligerait à obtenir une 
autorisation spécifique. Merci, Claude 
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Étiquetage padza

[Philippe Verdy]

Une forme de désertification où l'homme a joué un rôle initial, et la
nature a fait le reste en amplifiant le problème.

Comment traiter alors les zones en voie de désertification en Afrique et
ailleurs, même en Espagne, le sud de l'Italie et d'autres îles
méditerranéennes, ou encore en Australie centrale et an Amérique du Sud
dans d'anciennes riches vallées agricoles?

L'homme y jour un rôle mais souvent à une échelle bien plus grande que
locale (l'effet amplificateur d'échelle vient de la nature et n'est pas
directement celui de l'homme qui a cru son action aurait un effet seulement
purement local ou temporaire, une sorte "d'effet papillon").

L'agriculture n'est pas la seule en cause, il y a aussi un rôle majeur dans
l'utilisation urbaine des ressources en eau. Et parfois comme en Indonésie,
ou en Haïti, ou dans l'île de Pâques, au Mexique dans les civilisations
précolombiennes, ce n'était pas l'agriculture mais l'exploitation abusive
de ressources forestières non renouvelables, ces pratiques on les trouve
maintenant aussi en Amazonie (pas forcément pour l'agriculture, mais pour
l'orpaillage ou la construction de barrages).

En Afrique aussi pour la production de charbon (pas d'agriculture, on coupe
direct, on brûle sur place et on ramasse, et on ne gère pas du tout en
replantant...).

Dans les Antilles (hormi Haïti), oui on peut parler de l'impact direct par
l'agriculture. A Mayotte (ou dans les îles voisines) la situation est mixte
mais surtout influencé par des besoins urbains avec une pression
démographique massive où l'usage des coupes devient plus important que
l'usage réellement agricole qui a stagné ou régressé alors qu'il gérait
mieux les ressources, même si un temps cela s'est fait par la vieille
technique facile du brûlis qui a remplacé celle des anciennes plantations
basées sur le travail humain, notamment l'esclavage dans le passé, faute de
réel autre moyen de développer d'autres techniques agricoles demandant des
financements importants et un système de commercialisation efficace car on
ne leur proposait que le machinisme, les engrais et l'agriculture intensive
et ultra-sélective qui pourtant ont montré leurs limites et leur
inefficacité dès le court terme, donc conduit à raser des surfaces de plus
en plus vastes pour "remplacer" les terres infertilisées).

Mais on a un phénomène similaire aussi dans notre développement urbain qui
délaisse des terrains en friches polluées et économiquement plus
"rentables". L'aspect est différent (en terme de matériaux) mais la
latérite des "padzas" est finalement comparable aux montagnes de remblais
qui s'accumulent et créent un sol artificialisé qui n'évoluera plus en
terre fertile. On peut également parler des terrils, des montagnes de
déchets enterrés sous les anciennes décharges, juste couvert par une fine
couche naturellement infertile (et tout arrêt d'entretien, mais aussi la
dégradation par l'écoulement naturelle des eaux fait réapparaitre ces
matériaux quelque part), et des anciennes mines (même ferméees et
partiellement rebouchées, ou simplement laissées s'inonder pour former des
étangs, d'où remonteront plus tard des effluents).

Toutes les déforestations ne sont pas humaines, certaines proviennent
d'événements naturels depuis toujours (par exemple les incendies par la
foudre, les ouragans/cyclones, le volcanisme, les tsunamis, les glissements
de terrain et effondrements d'origine naturelle: tectonique ou érosive).

Les roches érodées sont des terrains "en transition" rapide, la nature y
reprendra elle-même ses droits mais sous une forme différente, pour peu
qu'on la laisse faire, et pour moi les "padzas" sont bien des éléments
naturels (à un stade précoce de cette transition), de la même façon que les
plages et haut-fonds de sables ou galets en bord de mer ou sur les cours
d'eau. Pour l'instant l'homme ne peut plus y faire grand chose même s'il a
pu en être une des causes ou un facteur déclenchant, catalyseur ou
accélérateur. Il est même fort probable que ce phénomène se serait produit
de toute façon (il aurait suffit d'un seul cyclone ou tsunami, ou éruption
volcanique comme deux qui ont dévasté nombre d'îles carribéennes, et
d'autres îles du Pacifique quasi inhabitées comme les Kouryles dans le
détroit de Bering et presque toute la Polynésie, ou encore les Andes, une
bonne partie de l'erg saharien, ou l'ancienne vallée fertile entre Ethiopie
et le haut Nil où est née l'humanité avant qu'elle soit obligée d'émigrer
et conquérir le monde). On peut encore citer des terres du centre-nord de
l'Amérique.


Le ven. 19 oct. 2018 à 18:09, Waxy  a écrit :

> Salut,
>
> Comment étiquetteriez-vous ceci…
> https://fr.wikipedia.org/wiki/Padza
>
> J'ai mis :
> natural=bare_rock
> surface=ground
>
> En fait ce n'est pas très naturel. C'est le résultat d'une pratique
> "agricole".
>
> @+
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Martin Koppenhoefer]

sent from a phone

> On 19. Oct 2018, at 15:06, Frederik Ramm  wrote:
> 
> leider kommt es immer wieder zu Changeset-Diskussionen wie hier:
> 
> https://www.openstreetmap.org/changeset/63602349


wie im Heise Forum. 
o_O

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

Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Martin Koppenhoefer]

sent from a phone

> On 19. Oct 2018, at 15:06, Frederik Ramm  wrote:
> 
> Ich werde Benutzer, die sich in solche Changeset-Diskussionen
> verzetteln, künftig deswegen sperren.


kannst Du das spezifizieren? Wenn es ums Verkleben geht, soll man neue Mapper 
freundlich begrüßen und höchstens in einem Nebensatz das Verkleben ansprechen? 
Oder ist jeder Hinweis darauf verboten, wenn es um Neulinge geht? 
Neuling ist z.B. jeder der höchstens ein Jahr dabei ist und weniger als 50 
Änderungen hat?

Nicht dass ich mich direkt angesprochen fühle, aber Changesetcomments sind 
unser wichtigstes Kontaktmedium, wenn es um Edits geht. Bei Leuten die noch 
kurz dabei sind finde ich es auch wichtig, dass ein freundliches Klima und 
logischerweise Nachsicht hinsichtlich der Edits rüberkommt, das Thema Mappen 
ist zu komplex, um da gleich alles überblicken zu können (das kann vermutlich 
sowieso niemand ). Andererseits, wenn deren erste Aktionen sind, massenhaft 
Flächen an Straßen zu kleben, dann sollte man die schon auch anschreiben 
dürfen. Aber freundlich.



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

Re: [OSM-talk] talk Digest, Vol 170, Issue 22

[Oleksiy Muzalyev]

On 19.10.18 19:08, John Whelan wrote:
> A map created with this technology could revolutionize quite a few industries. For example 
the agriculture [2], internet sales & delivery, etc. Basically, the 
roads, paths, alleys, etc. on the map could be precise enough to be 
used by a slow-moving robotized vehicles without constant LIDAR laser 
scanning.


 Agreed but could you trust OSM as a source for this?  Unfortunately 
we are open to vandalism even if the ways were mapped to high accuracy 
in the first place and there is still the problem of temporary 
obstacles in the way.


Cheerio John


Hi John,

The first basic phone appeared in 1849. However, the full potential of 
this technology started to demonstrate itself by 30s, several decades 
later. Computerized maps are only about 15 years old.


The "DJI’s Ultimate Mapping Solution" is still quite expensive, however 
if this technology becomes affordable with mass production, what is 
DJI's specialty, then it will be the brave new world.


If one could go to a common shopping center and buy a device which 
allows to map several square kilometers per day with one centimeter 
precision (0.39 inch) both horizontally and vertically, it would 
probably generate many new ideas both in programming and physical 
applications.


Best regards,

Oleksiy

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

[Talk-ca] Missing Maps Mapathon - October

[Brian Bancroft]

Hi everyone,

MSF is running the third monthly back-to-back missing maps event in support
of HOTOSM this Wednesday in Toronto down at 551 Adelaide St W, in downtown
Toronto. If you're in the area and want to help out, there is always need
of mentors of all skill levels, and I'd be happy to introduce you to the
organizers who are keen to put the right people in the right place. If
you're not around, and you still want to offer a hand, there is certainly a
need of validators for the first-line validation before the results are
taken to people on the ground for the last round of checks.

The last event in September was impressive. I counted more than 80 people
at any given time of all walks of life. Students, elders, and yuppies! A
lot of them were new to openstreetmap, and they were all there to map.

The organizers were no slouches either! On the ground, there were tutorials
as well as FAQs printed on the walls and on the tables. And this was in
addition to the early-evening lecture *and* the roving mentors that ensured
that everyone could get on board, no matter their preferred means of
learning or skill level.

If you've got time, do consider coming on down and giving a hand. If you're
an OSM vet, and want to validate from a distance, feel free to ask and I'll
pass up the task number when they let me know. We went through one and a
half tasks last month, and we're itching to digitize just as many squares
this time through. Come join us as we do good on the platform we know and
love.

https://www.facebook.com/events/155608332048587/

Brian Bancroft,
*Polygon Artisan*
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Import des arrêts d'autobus de l'ARTM

[Alouette955]

Bonjour,

Il y a quelques temps je lançais une consultation sur ma proposition d’import 
pour les arrêts d’autobus du Réseau de transport Métropolitain, maintenant EXO. 
J’attends incessamment leur autorisation pour l’import avec mention sur la page 
des contributeurs.

   
https://wiki.openstreetmap.org/wiki/FR-Import_arr%C3%AAts_d%27autobus,_EXO_r%C3%A9seau_de_transport_m%C3%A9tropolitain

Tout commentaire sur ma méthodologie est bienvenue.

Depuis j’ai compris que EXO, tout comme la STM (Montréal), la STL (Laval) et le 
RTL (Longueuil) sont des opérateurs distincts mais qui collaborent sous l’égide 
de l’ARTM. Un peu compliqué mais maintenant clarifié. J’en ai profité pour 
créer une page pour l’ARTM dans le wiki:

  
https://wiki.openstreetmap.org/wiki/FR-ARTM_-_Autorit%C3%A9_r%C3%A9gionale_de_transport_m%C3%A9tropolitain

La STL et le RTM ont une licence qui me semble beaucoup plus permissive:

  http://www.rtl-longueuil.qc.ca/fr-CA/donnees-ouvertes/
  https://www.stl.laval.qc.ca/fr/stl-synchro/developpeurs/ (voir à l’encadré 
Conditions d’utilisation)

Je songe donc les inclure à mon projet d’import sans autre formalité autre de 
les indiquer dans la page des contributeurs.

La question est: Aie-je bien compris ces licences? 

Il ne me semble pas que l’import dans la base de données OSM est une 
utilisation commerciale ou quasi commerciale mais peut-être y a-t-il un 
précédent qui m’obligerait à obtenir une autorisation spécifique.

Merci,

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

Re: [OSM-talk-ie] OpenStreetMap Ireland CLG launch

[Colin Broderick]

Unfortunately I wont be able to make it tomorrow but I hope the launch goes
well!

Colin

On Tue, 16 Oct 2018 at 05:28, Ciarán Staunton 
wrote:

> As most of you know we are creating an OpenStreetMap Ireland Company
> Limited by Guarantee in order to have the necessary legal entity to go
> forward as a OpenStreetMap chapter. The company comprises of Directors who
> are legally "subscribers" of the company and are responsible for its
> adherence to all regulations as a trading entity. The launch of the company
> also allows the community to expand, for bigger venues to be used, and for
> us to brand things so that we promote work that has been done at a smaller
> scale to a wider participating audience.
>
> To move forward we are launching this company in Maynooth this Saturday the
> 20th October at 12 noon. The event will be formal for a few minutes, and
> then we want to open the floor for an open mic to allow those who are
> present speak about what they like mapping. To find further details please
> look at the events link on the openstreetmap.ie website and reserve your
> place on the eventbrite ticketing thingymajigger. Hope to see loads of you
> there!
> ___
> Talk-ie mailing list
> Talk-ie@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ie
>


-- 
Colin Broderick
+32 473559902 |  www.cbroderick.me  
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

Re: [OSM-talk] talk Digest, Vol 170, Issue 22

[John Whelan]

A  map created with this technology could revolutionize quite a few 
industries. For example the agriculture [2], internet sales & delivery, 
etc. Basically, the roads, paths, alleys, etc. on the map could be 
precise enough to be used by a slow-moving robotized vehicles without 
constant LIDAR laser scanning.


 Agreed but could you trust OSM as a source for this?  Unfortunately we 
are open to vandalism even if the ways were mapped to high accuracy in 
the first place and there is still the problem of temporary obstacles in 
the way.


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

[OSM-talk-fr] Étiquetage padza

[Waxy]

Salut,

Comment étiquetteriez-vous ceci…
https://fr.wikipedia.org/wiki/Padza

J'ai mis :
natural=bare_rock
surface=ground

En fait ce n'est pas très naturel. C'est le résultat d'une pratique
"agricole".

@+


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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[marc marc]

résumé de la modif automatique proposée en France
en tenant compte de tous les suggestions :
7371 amenity=swimming_pool
- 71 qui ont déjà un tag leisure
- 272 avec un tag name
- 39 avec un tag building
- 18 avec une surface dams josm areasize > 2000m2

cela fait environ 7000 à modifier en leisure=swimming_pool.
pas d'objection ?

Pour le reste, je m’abstiens de le faire en automatique,
mais je donne volontiers un coup de main pour le faire
à la main, en regardant chaque objet.

Le 19. 10. 18 à 08:42, Paul Desgranges a écrit :

>      les "amenity=swimming_pool + name=*" 
>  en "leisure=sports_centre + 
> sport=swimming"

Je doute que tu puisses tirer une conclusion aussi binaire de
la présence d'un nom, j'ai déjà croisé souvent des name=piscine privée
Je pense que pour ceux là, soit on les inclus dans le groupe général 
(c'était supposé être un bassin, si c'est faux, cela reste faux)
soit c'est plus raisonnable de les charger dans josm et de faire
un contrôle humain pour mettre l'éventuel faux nom dans description
et tag d'accès plutôt que de changer le sens en centre sportif
car c'est une supposition hasardeuse.

> "amenity=swimming_pool + name!=*" 
>  en "leisure=swimming_pool"

critère "tag name" ajouté ci dessus pour l'édition de masse

> "amenity=swimming_pool + building=yes" 
>  en "leisure=sports_centre

- critère "pas de tag building" ajouté pour l'édition de masse.
- Mais convertir en centre sportir uniquement sur la base de la présence 
d'un tag building, c'est se tromper lorsqu'un bassin est couvert avec
un bâtiment en dur donc je passe mon tour pour faire cette modif là
en automatique (mais je ne suis pas vexé si quelqu'un veux faire 
autrement à ma place)
il y en a que 39 et un risque d'erreur trop élevé que pour justifier
de le faire à l'aveugle.

> Mais là, a-t-on la possibilité de faire une requête overpass turbo pour 
> les sélectionner sur ce critère de taille?

Je n'ai pas vu, Jérome parlait d'overpass
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-dk] cykelstier ved Njalsgade og Amagerbrogade

[Henrik Puukka-Sørensen]

For et år siden blev der lagt selvstændige cykelstier på Njalsgade og 
Amagerbrogade. 

De er nu fjernet og på Amagerbrogade erstattet cykelstier som integreret del af 
Amagerbrogade, dog med tag bicycle=no.

Jeg kan ikke lige finde ud af hvad og hvornår det er sket.

Jeg kan ikke lige gennemskue hvad der er mest rigtigt i forhold til at have 
selvstændige cykelstier, men lige nu er tag på Njalsgade mht bicycle=no forkert.


venlig hilsen
Henrik Puukka-Sørensen
3190 0339

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

Re: [OSM-ja] 日本にVillage Greenとタグ付けできる場所は存在していますか?

[Keisuke Oki]

"Village Green"が日本に相当するのは'里山'と考えられるのではないでしょうか？
里山は入会地であり、英語の"Village Green"の説明が"A *village green* is a common
 open area within a village
 or other settlement."というところで共通しています。

日本でも環境省や地方自治体が里山保護を行なっています。全国的に里山やそれに類するエリアをVillage
Greentと考えるのは適していると思いますが、いかがでしょう？
下記は東京の例です：
https://tokyo-satoyama.jp/

沖啓介


2018年10月19日(金) 22:58 MATSUMURA Hidetoshi :

> 松村です。
>
> 調べてみたら、JOSMのvillage_greenの翻訳が「緑地公園」になっていました。
>
> Overpass turboとかで検索すると「◯◯緑地」に対して使われているケースが多いので、これが影響しているのかもしれないです。
>
> iPhoneから送信
>
> 2018/10/19 14:54、Jun Nogata のメール:
>
> > hayashiさん、岩崎さん
> >
> > 野方です。
> >
> > Village_greenは、共有地という意味ではhayashiさんの書かれた入会地に近いんですが、
> > 共同管理公園的な意味もあって方向性がちょっと違う感じなんですよね。
> >
> > それと、入会地をタグ付けしたとしても東京にこんなにそういう場所があるの?
> > http://overpass-turbo.eu/s/CUF
> > という疑問もあります。
> >
> > 調べると九州以外でもvillage_greenでタグ付けされてるところがかなりありました。
> >
> > ということで今、日本で使われているvillage_greenはタグ付けの誤用では?という疑問と
> > そして、village_greenをタグ付けするならどんな場所?という疑問があります。
> >
> > 入会地を知っててタグ付けをしたなら、それはそれでいいのですが、
> > 公園っぽいものをvllage_greenとタグ付けは違う気がするのですが
> > ちょっと謎です…。
> >
> >
> > 2018年10月19日(金) 12:19 Nobusuke IWASAKI :
> >>
> >> みなさま
> >>
> >> いわさきです。
> >>
> >>
> hayashiさんのおっしゃる通り、日本にも「入会地」はあります。その名残か、地名に「入会地」と残っている場所もあります。ただこれが、今回議論されているVillage_greenと同じかというと、ちょっと違うようにも感じました。
> >>
> >> Wikipediaでは、「Traditionally, a village green was common grassland at the
> centre of a rural settlement used for grazing with a pond for watering
> cattle and other stock.」と記述されており、日本における入会地（入会草地？）とは、ちょっと様相が違うようにも思います。
> >>
> >> https://en.wikipedia.org/wiki/Village_green
> >>
> >> 一応、参考までにお知らせします。
> >>
> >> On 2018/10/18 20:05, yuu hayashi wrote:
> >>
> >> hayashiです
> >>
> >> 日本にも「入会地」とよばれる集落の共有地があります。
> >> https://ja.wikipedia.org/wiki/%E5%85%A5%E4%BC%9A%E5%9C%B0
> >>
> >> 私有地でもなく、村有地とも違って、江戸時代以前から集落の共有地として現在も利用されています。
> >> イギリスとの違いは集落の中心部ではなく、耕作地の中心部や周辺部にあって、薪や肥料 山菜の共同採集場所として使われます。
> >>
> >> https://wiki.openstreetmap.org/wiki/JA:Tag:landuse=village%20greenにも
> 「入会地」という言葉が使われていますし、歴史的形成の過程や役割などからしても
> Village_greenに「入会地」を割り当てることに問題はないと思います。
> >>
> >> ちなみに山梨県の私の家の周りは入会地だらけなのですが、そこが入会地かどうかは地元の人にしかわかりません。
> >> そのため、入会地をマッピングするのは難しいです。
> >> 他の地域の人が知らずに入り込むと「キノコ泥棒」扱いされますのでサーベイしようなどとは思わない方がいいです。
> >>
> >>
> >>
> >> 2018年10月18日(木) 0:43 Jun Nogata :
> >>>
> >>> 野方です。
> >>> 九州を見ていたら、landuse=village_greenでタグ付けされている場所があり
> >>> ました。
> >>>
> >>> -
> https://www.openstreetmap.org/way/507693755#map=18/33.51813/130.49285
> >>>
> >>> Village Greenは、村や地域などが管理する緑地でイギリス独特の場所だと思っ
> >>> てて日本には無いものだと思っていたのですが、こういう場所は日本でも存在
> >>> するのでしょうか?
> >>>
> >>> - https://wiki.openstreetmap.org/wiki/JA:Tag:landuse=village%20green
> >>> - https://en.wikipedia.org/wiki/Village_green
> >>>
> >>> イギリスのバンドThe Kinksの歌詞にも出てくるけど、翻訳にも困るような場所
> >>>
> >>> - https://www.youtube.com/watch?v=lc7dmu4G8oc
> >>> - http://d.hatena.ne.jp/komasafarina/20060715#20060715f1
> >>>
> >>> 公園と間違えたのかと思って、idエディタで公園を検索すると、ちゃんと公園
> >>> (leisure=park)が出てくるので間違えたのでもなさそうです。
> >>>
> >>> ということで、Village Greenは自分が知らないだけで、日本にそういう場所
> >>> が存在しているのでしょうか?
> >>>
> >>> --
> >>> 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
> >>> - web: http://www.nofuture.tv/diary/
> >>> ___
> >>> Talk-ja mailing list
> >>> Talk-ja@openstreetmap.org
> >>> https://lists.openstreetmap.org/listinfo/talk-ja
> >>
> >>
> >> ___
> >> Talk-ja mailing list
> >> Talk-ja@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-ja
> >>
> >> ___
> >> Talk-ja mailing list
> >> Talk-ja@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-ja
> >
> >
> >
> > --
> > 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
> > - web: http://www.nofuture.tv/diary/
> > ___
> > Talk-ja mailing list
> > Talk-ja@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-ja
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[OSM-talk-fr] Ces collectivités qui misent sur Openstreetmap et la cartographie participative

[Christian Quest]

Article paru sur un site du Ministère de l’Economie, de l’Industrie et du
Numérique...

https://labo.societenumerique.gouv.fr/2018/10/17/collectivites-misent-openstreetmap-cartographie-participative/

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

Re: [OSM-talk-fr] Voting Default Language Format

[Philippe Verdy]

Le "name:fr" est le nom **d'usage courant** en français, il n'est pas
forcément le nom **officiel** (quel que soit sa langue d'origine, française
ou régionale) qui lui figure dans "official_name=*"

Il peut y avoir plusieurs noms officialisés **localement** dans quelques
langues, dont le français, et pour les distinguer on peut ajouter
"official_name:fr=*" et "official_name:=*", mais on n'en
mettra pas d'autres et donc aucun autre nom dans une langue non
officialisée; au plan national le seul nom officiel est celui officialisé
en français donc nécessairement alors "official_name:fr=*" prévaut sur
"official_name=*" pour cette utilisation légale nationale franco-française.

En revanche les rendus affichent les noms officiels seulement comme
métadonnées, rarement sur les cartes. Les rendus OSM par défaut n'affichent
que les noms d'usage le plus courant "name=*" ou "name:lang=*". Mais il
n'est pas forcément le plus courant localement et pour ça on a "loc_name=*"
(éventuellement aussi avec "loc_name:=*" s'il y a plusieurs parlers
locaux) qui est lui aussi une métadonnée rarement utilisée dans le rendu
mais seulement visible si on demande les infos détaillées sur un objet
particulier.

Il faut se demander quel est le but d'un rendu "100% français" et quel
public est visé. Si on veut faire une carte "officielle" de la France selon
la législation française, on devra privilégier "official_name:fr=*" et
sinon "official_name=*", à "name:fr=*" en dernier recours avant "name=*"
qui n'est que le nom d'usage (supposé officiel s'il n'y a pas
"official_name:fr=*" indiqué explicitement) et on ignorera tous les
"loc_name=*" et "loc_name:=*".

OSM est assez souple pour permettre à un rendu de déterminer ses priorités
selon le public et l'usage qu'il vise.

Mais en général les rendus "standards" d'OSM utilisent les noms d'usage
courant (peu importe s'ils sont officiels ou pas) indiqués dans
"name:=*" (si l'utilisateur a une **préférence** pour une langue
donnée, ce qui n'est pas une obligation légale) ou sinon dans "name=*"
(quel que soit la langue).


Le ven. 19 oct. 2018 à 09:06, rainerU  a écrit :

> Bonjour,
>
> Je me pose des questions sur l'impact de cette proposition sur les objets
> qui
> ont un nom officiel en langue régionale :
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>
> Si j'ai bien compris la proposition, on mettrait default:language=fr sur
> la
> frontière de la France (ou des régions, départements,...) et les
> applications
> utiliseraient name=fr comme nom standard.
>
> A mon avis, cela pose un problème dans les cas où le nom officiel d'un
> objet est
> en langue régionale mais existe aussi un nom en français. Il y a eu un fil
> de
> discussion sur cette liste sur la manière de tagguer ces cas avec le
> schéma
> actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je taggue
> name= officiel>, name:ca=, name:fr=. Avec le schéma
> proposé, un rendu en langue standard afficherait le nom français et pas le
> nom
> officiel en catalan. Si par contre on mettait name:fr=, on ne
> pourrait plus créer un rendu 100% français.
>
> Est-ce que cette question a déjà été discuté ici ou ailleurs, si oui
> quelle
> était la conclusion ?
>
>
>
> ___
> 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] 日本にVillage Greenとタグ付けできる場所は存在していますか?

[MATSUMURA Hidetoshi]

松村です。

調べてみたら、JOSMのvillage_greenの翻訳が「緑地公園」になっていました。

Overpass turboとかで検索すると「◯◯緑地」に対して使われているケースが多いので、これが影響しているのかもしれないです。

iPhoneから送信

2018/10/19 14:54、Jun Nogata のメール:

> hayashiさん、岩崎さん
> 
> 野方です。
> 
> Village_greenは、共有地という意味ではhayashiさんの書かれた入会地に近いんですが、
> 共同管理公園的な意味もあって方向性がちょっと違う感じなんですよね。
> 
> それと、入会地をタグ付けしたとしても東京にこんなにそういう場所があるの?
> http://overpass-turbo.eu/s/CUF
> という疑問もあります。
> 
> 調べると九州以外でもvillage_greenでタグ付けされてるところがかなりありました。
> 
> ということで今、日本で使われているvillage_greenはタグ付けの誤用では?という疑問と
> そして、village_greenをタグ付けするならどんな場所?という疑問があります。
> 
> 入会地を知っててタグ付けをしたなら、それはそれでいいのですが、
> 公園っぽいものをvllage_greenとタグ付けは違う気がするのですが
> ちょっと謎です…。
> 
> 
> 2018年10月19日(金) 12:19 Nobusuke IWASAKI :
>> 
>> みなさま
>> 
>> いわさきです。
>> 
>> hayashiさんのおっしゃる通り、日本にも「入会地」はあります。その名残か、地名に「入会地」と残っている場所もあります。ただこれが、今回議論されているVillage_greenと同じかというと、ちょっと違うようにも感じました。
>> 
>> Wikipediaでは、「Traditionally, a village green was common grassland at the 
>> centre of a rural settlement used for grazing with a pond for watering 
>> cattle and other stock.」と記述されており、日本における入会地（入会草地？）とは、ちょっと様相が違うようにも思います。
>> 
>> https://en.wikipedia.org/wiki/Village_green
>> 
>> 一応、参考までにお知らせします。
>> 
>> On 2018/10/18 20:05, yuu hayashi wrote:
>> 
>> hayashiです
>> 
>> 日本にも「入会地」とよばれる集落の共有地があります。
>> https://ja.wikipedia.org/wiki/%E5%85%A5%E4%BC%9A%E5%9C%B0
>> 
>> 私有地でもなく、村有地とも違って、江戸時代以前から集落の共有地として現在も利用されています。
>> イギリスとの違いは集落の中心部ではなく、耕作地の中心部や周辺部にあって、薪や肥料 山菜の共同採集場所として使われます。
>> 
>> https://wiki.openstreetmap.org/wiki/JA:Tag:landuse=village%20greenにも 
>> 「入会地」という言葉が使われていますし、歴史的形成の過程や役割などからしても 
>> Village_greenに「入会地」を割り当てることに問題はないと思います。
>> 
>> ちなみに山梨県の私の家の周りは入会地だらけなのですが、そこが入会地かどうかは地元の人にしかわかりません。
>> そのため、入会地をマッピングするのは難しいです。
>> 他の地域の人が知らずに入り込むと「キノコ泥棒」扱いされますのでサーベイしようなどとは思わない方がいいです。
>> 
>> 
>> 
>> 2018年10月18日(木) 0:43 Jun Nogata :
>>> 
>>> 野方です。
>>> 九州を見ていたら、landuse=village_greenでタグ付けされている場所があり
>>> ました。
>>> 
>>> - https://www.openstreetmap.org/way/507693755#map=18/33.51813/130.49285
>>> 
>>> Village Greenは、村や地域などが管理する緑地でイギリス独特の場所だと思っ
>>> てて日本には無いものだと思っていたのですが、こういう場所は日本でも存在
>>> するのでしょうか?
>>> 
>>> - https://wiki.openstreetmap.org/wiki/JA:Tag:landuse=village%20green
>>> - https://en.wikipedia.org/wiki/Village_green
>>> 
>>> イギリスのバンドThe Kinksの歌詞にも出てくるけど、翻訳にも困るような場所
>>> 
>>> - https://www.youtube.com/watch?v=lc7dmu4G8oc
>>> - http://d.hatena.ne.jp/komasafarina/20060715#20060715f1
>>> 
>>> 公園と間違えたのかと思って、idエディタで公園を検索すると、ちゃんと公園
>>> (leisure=park)が出てくるので間違えたのでもなさそうです。
>>> 
>>> ということで、Village Greenは自分が知らないだけで、日本にそういう場所
>>> が存在しているのでしょうか?
>>> 
>>> --
>>> 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
>>> - web: http://www.nofuture.tv/diary/
>>> ___
>>> Talk-ja mailing list
>>> Talk-ja@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ja
>> 
>> 
>> ___
>> Talk-ja mailing list
>> Talk-ja@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ja
>> 
>> ___
>> Talk-ja mailing list
>> Talk-ja@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ja
> 
> 
> 
> -- 
> 野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
> - web: http://www.nofuture.tv/diary/
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[Philippe Verdy]

>
> Les choses seraient plus simples si OSM ne permettait plus de représenter
> une surface avec des chemins d'orientation quelconque et imposait la même
> restriction que le GIS standard. On n'aurait même pas besoin non plus des
> rôles "inner" et "outer" qui ne sont qu'indicatifs (pour les humains) mais
> même pas réellement distinctifs (pour tous les moteurs de rendus ou
> d'analyse, qui de toute façon doivent ignorer cette distinction apparente
> et les traiter de la même façon).
>
> Mais alors pourquoi OSM ne l'impose pas ? Simplement parce que les chemins
> dans OSM sont "partagés" et peuvent être réutilisés en tant que membres par
> plusieurs relations de surface (chacune définissant une "orientation GIS"
> différente au sens surfacique) et avoir en plus une orientation ne
> dépendant pas des relations de surface mais de ce qu'impose d'autres objets
> "filaires" (par exemple : orientation des cours d'eau waterway=*, ou sens
> unique des rues highway=*, ou voies ferrées railway=*).
>

J'ajoute en plus  que le fait qu'OSM n'impose pas l"orientation GIS des
chemins membres d'un "multipolygon" pose un problème non seulement dans les
rendus, mais aussi dans les éditeurs utilisés (à cause de limite mémoire,
que ce soit dans un éditeur web comme iD où la limite est imposée par le
navigateur utilisé ou un éditeur externe comme JOSM (par exemple la limite
mémoire des VMs Java) : on ne peut pas charger la totalité de la géométrie
d'un multipolygone san imposer une charge lourde au serveur OSM, et sans
saturer en plus la mémoire de l'éditeur.

On doit donc pouvoir travailler dans un éditeur avec une géométrie
partiellement téléchargée pour les relations. Le rendu dans l'éditeur du
coté "intérieur" ou "extérieur" n'est donc pas toujours exact et
l'utilisateur doit se guider sur les indications des rôles "inner" et
"outer" pour éviter de casser la géométrie de ces relations surfaciques
(mais c'est un guide partiel qui ne répond pas à toutes les questions, le
rendu dans l'éditeur peut rester malgré tout incorrect tant que la
géométrie de la relation n'est pas téléchargée en totalité en mémoire...)

C'est pour ça qu'on demande aux utilisateurs de limiter la géométrie des
multipoygones afin que le nombre total de points ne dépasse pas quelques
milliers de points. Sinon on leur demande de scinder les multipolygones en
plusieurs parties.

Ce sera à l'export GIS de préparer les géométries complètes de polygones
afin d'en faire un rendu exact (et pour cela il n'a absolument pas besoin
de la distinction des rôles "inner" et "outer"), en défusionnant les
ways OSM partagés (pour les importer dans des polygones surfaciques
complets et correctement orientés plaçant l'intérieur à gauche, quelque
soit l'orientation des chemins utilisés dans OSM).

Bref on a un compromis dans OSM favorisant plutôt les utilisateurs afin de
leur permettre d'éditer la carte sans avoir nécessairement une machine
puissante avec plein de mémoire (ou beaucoup de stockage dans une base
locale externe : c'est ce qu'a fait iD en ne chargeant plus tout en mémoire
dans le navigateur, mais en utilisant une fonctionnalité "base de données
locale" offerte par les navigateurs web récents, où des données peuvent
être stockées sur disque et pas gardées en mémoire, ce qui le rend
utilisable même dans des navigateurs limités en 32 bits mais disposant d'un
stockage local généralement plus confortable). En attendant les rôles
"inner" et "outer" restent utiles car on continue de l'utiliser sans avoir
forcément téléchargé la totalité de la géométrie des relations (même via
une "base de données externe" locale) et parce que le rendu local dans
l'éditeur ne s'en sert pas (cela imposerait trop de données en mémoire ou
nécessiterait que l'éditeur précalcule une "orientation GIS" et la mette en
cache dans sa base externe locale)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] [Alberi monumenmtali] Quale licenza?

[Andrea Musuruane]

Ciao,
innanzitutto grazie per proporre questo import.

On Wed, Oct 17, 2018 at 11:30 AM Cascafico Giovanni 
wrote:

> Per inquadrare l'import ho imbastito la wiki [3].
> [3]
> https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG
>


-
>
> *Data source site:* RAFVG
> 


Il link è errato. Manca www.

-
>
> *Data license:* public as defined in Regione Autonoma Friuli Venezia
> Giulia site
> 


Qui è scritto che la licenza è la IODLv2.
http://irdat.regione.fvg.it/consultatore-dati-ambientali-territoriali/chooseOperation.do

3 nome_volga nome volgare name Leccio name:it
>

Non mi sembra corretto usare il tag name per indicare il nome volgare
dell'albero. Il  tag name deve essere usato per nomi propri, non per quelli
comuni (infatti non scriviamo name=Fontanella o name=Bar).

Inoltre, l'uso del tag source sui dati è deprecato. Meglio usare solo
quello sul changeset, magari fornendo anche altre info. Ad esempio:

   - source=Regione Friuli-Venezia Giulia
   - source:license=IODLv2
   - type=import
   - url=
   
https://wiki.openstreetmap.org/wiki/Import/Catalogue/AlberiMonumentali-RAFVG-opendata

Ciao,

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

Re: [Talk-es] Fwd: Reconocimiento IGN en OSM

[Miguel Sevilla-Callejo]

Hola Daniel,
Efectivamente esa es la idea y pensé que aun ni estaba, perdonad mi torpeza
ahí irán todas las anotaciones y actualizaciones que surjan.
Muchas gracias

On Fri, 19 Oct 2018, 14:59 dcapillae,  wrote:

> Hola, Miguel.
>
> En el wiki hay un espacio reservado donde anotar todo lo relacionado con el
> IGN [1]: personas de contacto, conversaciones, reuniones, cronología de
> hechos, trabajos de colaboración, etc. Hace unos meses surgieron de nuevo
> los problemas de atribución. Puse un enlace a la lista de correo donde se
> intentó clarificar la cuestión [2].
>
> Sería bueno que cualquier tema tratado con el IGN se anotase en esa sección
> de la página del wiki, a modo de resumen, para que todos sepamos en
> cualquier momento cuáles son los antecedentes y la situación actual en que
> nos encontramos con respecto al Instituto. Si los que tenéis un trato más
> directo y fluido con el IGN podéis usar ese apartado para resumir los
> detalles, creo que sería de gran utilidad para la comunidad.
>
>
> [1]
>
> https://wiki.openstreetmap.org/wiki/ES:España/Contribuidores#Instituto_Geográfico_Nacional
> [2]
>
> http://gis.19327.n8.nabble.com/Importaciones2018-Reorganizacion-td5908090i20.html#a5917752
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> 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

Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[Philippe Verdy]

Dernière note importante : les surfaces "riberbank" peuvent être des
relations "multipolygon", mais leur complexité géométrique s'accroît vite
et peut poser des difficultés au rendu s'ils couvrent des surfaces très
étendus. En effet un rendu ne peut pas se contenter de chercher les ways
présents dans sa "bounding box" d'intérêt, pour détecter des chemins
membres d'une relation avec des rôles "inner" et "outer" même correctement
définis car il peut encore manquer des chemins pour savoir quel est le côté
intérieur ou extérieur.

En effet il pourrait trouver dans sa "bounding box" d'intérêt (celle qu'il
veut tracer) seulement deux chemins avec un rôle "outer" et ne peut PAS
conclure que la surface entre les deux (dans sa "bounding box") est
couverte en eau, car un cours d'eau peut faire des méandres et donc la
surface en eau pourrait s'étendre en fait de chaque côté des deux chemins
"outer" trouvés (jusqu'au moins les limites de la "bounding box") mais
justement pas entre les deux chemins. Un rendu doit alors charger les
relations au complet pour énumérer tous les chemins et déterminer
correctement le côté intérieur ou extérieure des chemins.

Cela pose des difficultés de performance justement pour les cours d'eau qui
formeraient une surface "riverbank" unique. Pour ces raisons, il est admis
que les surfaces "riverbank" d'un cours d'eau peuvent ne pas être uniques,
afin de rendre la complexité géométrique des surfaces moins grande.

De plus les relations "riverbank" ne suivent pas exactement les
restrictions des "multipolygon" car ils est admis que ces relations peuvent
inclure des polygones jointifs (partageant des chemins ou ayant des chemins
fermés partiellement superposés). Ces relations "riverbank" n'imposent donc
pas de déplacer les attributs "riverbank" de leurs way membres vers la
relation qui les collecte tous.

Les "riverbank" sont donc à traiter de la même façon que les surfaces de
"landuse=*" et "natural=*", qui ont les mêmes difficultés : il a été décidé
de limiter la complexité géométrique des multipolygones et de ne les
réserver qu'à des objets pas trop étendus, dont la géométrie global ne
totalise pas plus de quelques milliers de noeuds (quel que soit le nombre
de chemins qui les joignent et sont les membres des multipolygones).

Une telle complexité en revanche a été admise pour les relations "boundary"
qui ne posent pas de problème aux rendus (en vectoriel ou bitmap) : les
frontières ne sont jamais rendues comme surface (ou seulement un
prétraitement de "simplification géométrique" pour les niveaux de zoom
faibles) mais seulement en filaire (qui peut lui aussi avoir un
prétraitement de simplification géométrique).

La complexité géométrique des "coastlines" en revanche fait objet d'une
exception : on ne représente pas la mer comme une surface, mais pour
contourner le problème, on y impose l'orientation des chemins pour que le
côté "mer" soit à droite (cette conditions supplémentaire n'existe pas pour
les autres surfaces d'OSM, c'est tout le problème, contrairement aux
spécifications GIS standard qui imposent la même orientation à toute
surface délimitée par des contours fermés, avec le côté intérieur à gauche
et le côté extérieur à droite dans le sens du parcours du chemin).

De ce fait les coastlines font l'objet du côté d'OSM d'un prétraitement
spécifique qui les extrait dans une base à part destinée aux moteurs de
rendus, pour qu'ils n'utilisent pas les mêmes règles que les autres
surfaces OSM et conservent l'orientation indiquée dans cette base.

Alors que pour tous les autres objets OSM l'orientation des chemins reste à
déterminer par un algorithme coûteux devant prendre en compte la totalité
de la géométrie des objets (et qui ne peut pas se contenter des deux roles
"outer" et "inner" pour distinguer les cas, car ils ne suffisent pas à
déterminer comment réorienter des chemins en plaçant l'intérieur à gauche
et l'extérieur à droite, afin de pouvoir ensuite en faire un rendu
surfacique, ou à déterminer si un autre point quelconque est à l'intérieur
ou à l'extérieur de la surface).

Le coût de cet algorithme s'accroît vite quand les surfaces sont
représentées par des mulitpolygones dont les chemins membres comptent plus
de quelques milliers de points, et il impose d'utiliser des requêtes
lourdes en volume à la base de données (pour les mers cela représenteraient
à chaque fois des millions de points, et c'est pour ça qu'une exception a
été faite au "modèle OSM" pour les coastlines: le serveur de données ne
peut pas répondre "en ligne" à de telles demandes, cela doit être fait par
un export spécifique.

Les choses seraient plus simples si OSM ne permettait plus de représenter
une surface avec des chemins d'orientation quelconque et imposait la même
restriction que le GIS standard. On n'aurait même pas besoin non plus des
rôles "inner" et "outer" qui ne sont qu'indicatifs (pour les humains) mais
même pas réellement distinctifs (pour tous les moteurs de rendus ou
d'analyse, qui de toute 

Re: [OSM-talk-fr] Voting Default Language Format

[Christian Quest]

ça ajoute quand même une info :

name + name:ru sur un objet, mais avec des valeurs différents ne permet pas
de savoir la langue de ce name (cas bien courant)
avec le default:name=fr on sait que name est en français, sans avoir à
doubler avec un name:fr

Par contre, pour le rendu, la requête pour le retrouver va être assez
violente côté postgis vu la tête du mega-multi-polygone sur lequel on va
mettre ce tag... j'ai un doute sur son usage effectif dans la vraie vie.

La solution que j'ai adopté sur le rendu FR (utilisé pour les exemples)
s'en passe heureusement !

Le ven. 19 oct. 2018 à 15:00, marc marc  a
écrit :

> Je pense que le but de la propal est mal expliquée.
> S'il y a un name qui est égale au name:fr, on sait déjà déduire
> que le nom est en Français. et s'il y a un name=Viva Pizza name:it=Viva
> Pizza on sait déjà déduire que le nom du resto est en italien.
> On sait déjà faire un rendu "priorité fr" comme celui osm-fr
> ou dans une autre langage comme le montre ceux d'osm-be de bzh
> La propal ne change rien pour cela.
>
> Je trouve que le réel intérêt, c'est de dire de manière structurée :
> s'il a qu'un SEUL name, En France, le plus probable c'est que
> c'est du français tandis que c'est sans doute de l'allemand
> en Suisse mais à nouveau du Français dans le canton de Genève.
> tout en pouvoir surcharger cela si on le veux sur un poi.
> Le gros avantage que je vois c'est les routages vocaux.
> Il y aura un moyen d'encoder l'information nécessaire
> à une prononciation plus adaptée au contexte local.
>
> Le 19. 10. 18 à 12:52, Christian Quest a écrit :
> > Elle règle une partie des problèmes, mais ne permet pas de gérer du 100%.
> >
> > Ceci dit, on n'est pas obligé de l'utiliser cette info ou bien le faire
> > avec intelligence...
> >
> > Cas du rendu FR: si default:language=fr, je prends les name, sinon je
> > prends les name:fr
> >
> > Du coup, on aura bien le "name" sur le territoire français, même si il
> > n'est pas en français mais occitan ce qui est au final l'objectif
> > recherché, non ?
> >
> > Pour savoir véritablement dans quelle langue est name=*, il faut le
> > comparer aux différents name:xx=* , il n'y a finalement que ça de fiable
> > si c'est cette info qu'on veut obtenir.
> >
> >
> > Le ven. 19 oct. 2018 à 12:28, Rpnpif  > > a écrit :
> >
> > Le 19 octobre 2018, rainerU a écrit :
> >
> >  > Bonjour,
> >  >
> >  > Je me pose des questions sur l'impact de cette proposition sur
> > les objets qui
> >  > ont un nom officiel en langue régionale :
> >  >
> >  >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
> >  >
> >  > Si j'ai bien compris la proposition, on mettrait
> > default:language=fr sur la
> >  > frontière de la France (ou des régions, départements,...) et les
> > applications
> >  > utiliseraient name=fr comme nom standard.
> >  >
> >  > A mon avis, cela pose un problème dans les cas où le nom officiel
> > d'un objet est
> >  > en langue régionale mais existe aussi un nom en français. Il y a
> > eu un fil de
> >  > discussion sur cette liste sur la manière de tagguer ces cas avec
> > le schéma
> >  > actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je
> > taggue name= >  > officiel>, name:ca=, name:fr=. Avec le
> > schéma
> >  > proposé, un rendu en langue standard afficherait le nom français
> > et pas le nom
> >  > officiel en catalan. Si par contre on mettait name:fr= > catalan>, on ne
> >  > pourrait plus créer un rendu 100% français.
> >  >
> >  > Est-ce que cette question a déjà été discuté ici ou ailleurs, si
> > oui quelle
> >  > était la conclusion ?
> >
> > Bonjour,
> > Oui je suis d'accord avec toi : ce n'est pas une proposition
> > pertinente.
> >
> > --
> > Alain Rpnpif
> >
> > ___
> > 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
> >
>
> ___
> 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-it] Il 26 ottobre a Cuneo una giornata dedicata ad OpenStreetMap

[Luca Delucchi]

On Fri, 12 Oct 2018 at 19:48, mbranco2  wrote:
>
> Ciao Lista,
>

Ciao,

> vi informo che venerdì 26 ottobre, a Cuneo, ci sarà un incontro dedicato ad 
> OSM.
>

sarebbe bello tenere storia degli eventi nelle pagine dedicate sul wiki

https://wiki.openstreetmap.org/wiki/WikiProject_Italy/Events
https://wiki.openstreetmap.org/wiki/WikiProject_Italy/PastEvents

>
> Un saluto,
> Marco
>

-- 
ciao
Luca

www.lucadelu.org

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

[Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie

[Frederik Ramm]

Hallo,

leider kommt es immer wieder zu Changeset-Diskussionen wie hier:

https://www.openstreetmap.org/changeset/63602349

Irgendein Neuling mappt irgendwas mit "zusammengeklebten" Flächen,
irgendeiner meckert dran rum, dann kommen flohoff und OF0 und hauen noch
obendrauf, weil sie ihren privaten Kreuzzug führen, und zurück bleibt
ein Neuling mit einem Riesen-Fragezeichen im Gesicht, der gar nicht
versteht, was er da ausgelöst hat.

Das ist nicht gut. Wenn diese Debatte nicht projektweit oder wenigstens
deutschlandweit vernünftig geführt und das Problem nicht gelöst werden
kann, dann sollte man auch nicht versuchen, "seine" Ansicht ungefragt
armen Newbies aufs Auge zu drücken, nach dem Motto, die können sich ja
nicht wehren.

Ich werde Benutzer, die sich in solche Changeset-Diskussionen
verzetteln, künftig deswegen sperren.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

[OSM-talk-fr] Fwd: [OSM-dev] OpenStreetMap Carto release v4.16.0

[marc marc]

Pour info (rendu osm.org, cela prendra du temps pour la maj des tuiles)

hasard de calendrier, icône en plus pour les centres sportif :)

 Message transféré 
Sujet : [OSM-dev] OpenStreetMap Carto release v4.16.0
Date :  Fri, 19 Oct 2018 05:44:45 +0200
De :Daniel Koć 
Pour :  osm-dev List 


Dear all,

Today, v4.16.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before all
tiles show the new rendering.

Changes include
- Changing societal amenities color to less intensive
- Adding rendering for natural=strait
- Adding rendering for leisure=track on lines
- Adding icon for amenity=vehicle_inspection
- Adding icon for leisure=sports_centre + sport=swimming and 
leisure=swimming_area
- Adding icon for tourism=gallery
- Changing color for aeroway=apron in aerodromes
- Moving amenity=post_box to z19+
- Moving amenity=atm to z19+
- Replacing icon for information=tactile_model
- Ordering amenity_lines by layer
- Small documentation and code fixes

Thanks to all the contributors for this release including dryo, a new 
contributor|.|

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.15.0...v4.16.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"My method is uncertain/ It's a mess but it's working" [F. Apple]

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

Re: [Talk-es] Fwd: Reconocimiento IGN en OSM

[dcapillae]

Hola, Miguel.

En el wiki hay un espacio reservado donde anotar todo lo relacionado con el
IGN [1]: personas de contacto, conversaciones, reuniones, cronología de
hechos, trabajos de colaboración, etc. Hace unos meses surgieron de nuevo
los problemas de atribución. Puse un enlace a la lista de correo donde se
intentó clarificar la cuestión [2].

Sería bueno que cualquier tema tratado con el IGN se anotase en esa sección
de la página del wiki, a modo de resumen, para que todos sepamos en
cualquier momento cuáles son los antecedentes y la situación actual en que
nos encontramos con respecto al Instituto. Si los que tenéis un trato más
directo y fluido con el IGN podéis usar ese apartado para resumir los
detalles, creo que sería de gran utilidad para la comunidad.


[1]
https://wiki.openstreetmap.org/wiki/ES:España/Contribuidores#Instituto_Geográfico_Nacional
[2]
http://gis.19327.n8.nabble.com/Importaciones2018-Reorganizacion-td5908090i20.html#a5917752



-
Daniel Capilla 
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [OSM-talk-fr] Voting Default Language Format

[marc marc]

Je pense que le but de la propal est mal expliquée.
S'il y a un name qui est égale au name:fr, on sait déjà déduire
que le nom est en Français. et s'il y a un name=Viva Pizza name:it=Viva 
Pizza on sait déjà déduire que le nom du resto est en italien.
On sait déjà faire un rendu "priorité fr" comme celui osm-fr
ou dans une autre langage comme le montre ceux d'osm-be de bzh
La propal ne change rien pour cela.

Je trouve que le réel intérêt, c'est de dire de manière structurée :
s'il a qu'un SEUL name, En France, le plus probable c'est que
c'est du français tandis que c'est sans doute de l'allemand
en Suisse mais à nouveau du Français dans le canton de Genève.
tout en pouvoir surcharger cela si on le veux sur un poi.
Le gros avantage que je vois c'est les routages vocaux.
Il y aura un moyen d'encoder l'information nécessaire
à une prononciation plus adaptée au contexte local.

Le 19. 10. 18 à 12:52, Christian Quest a écrit :
> Elle règle une partie des problèmes, mais ne permet pas de gérer du 100%.
> 
> Ceci dit, on n'est pas obligé de l'utiliser cette info ou bien le faire 
> avec intelligence...
> 
> Cas du rendu FR: si default:language=fr, je prends les name, sinon je 
> prends les name:fr
> 
> Du coup, on aura bien le "name" sur le territoire français, même si il 
> n'est pas en français mais occitan ce qui est au final l'objectif 
> recherché, non ?
> 
> Pour savoir véritablement dans quelle langue est name=*, il faut le 
> comparer aux différents name:xx=* , il n'y a finalement que ça de fiable 
> si c'est cette info qu'on veut obtenir.
> 
> 
> Le ven. 19 oct. 2018 à 12:28, Rpnpif  > a écrit :
> 
> Le 19 octobre 2018, rainerU a écrit :
> 
>  > Bonjour,
>  >
>  > Je me pose des questions sur l'impact de cette proposition sur
> les objets qui
>  > ont un nom officiel en langue régionale :
>  >
>  >
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
>  >
>  > Si j'ai bien compris la proposition, on mettrait
> default:language=fr sur la
>  > frontière de la France (ou des régions, départements,...) et les
> applications
>  > utiliseraient name=fr comme nom standard.
>  >
>  > A mon avis, cela pose un problème dans les cas où le nom officiel
> d'un objet est
>  > en langue régionale mais existe aussi un nom en français. Il y a
> eu un fil de
>  > discussion sur cette liste sur la manière de tagguer ces cas avec
> le schéma
>  > actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je
> taggue name=  > officiel>, name:ca=, name:fr=. Avec le
> schéma
>  > proposé, un rendu en langue standard afficherait le nom français
> et pas le nom
>  > officiel en catalan. Si par contre on mettait name:fr= catalan>, on ne
>  > pourrait plus créer un rendu 100% français.
>  >
>  > Est-ce que cette question a déjà été discuté ici ou ailleurs, si
> oui quelle
>  > était la conclusion ?
> 
> Bonjour,
> Oui je suis d'accord avec toi : ce n'est pas une proposition
> pertinente.
> 
> -- 
> Alain Rpnpif
> 
> ___
> 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
> 

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

Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[Philippe Verdy]

Note: Positron est le seul ici à ne pas accepter de faire un rendu des
multipolygon des surfaces de riverbank. C'est pourtant partie du schéma
standard : toute surface fermée représentée par un chemin fermé peut
librement devenir un multipolygon avec les mêmes attributs (juste le tag
"type=multipolygon" ajouté, les chemins membres devant comprendre au moins
un way avec un rôle "outer", et leurs attributs transférés vers la relation)
Ici il n'a pas prévu cette possibilité et donc ne trace que le filaire.
Les autres rendus tracent les deux : les surfaces, et par dessus (en plus)
le filaire qui comble les trous non couverts par les surfaces, dont
notamment les chemins souterrains (qui peuvent passer sous des surfaces qui
ne sont pas des riverbank comme des constructions de barrages, des parties
construites, ou de véritables tunnels naturels ou artificiels y compris les
"culvert" sous une voirie, ou des dérivations alimentant un canal ou
déviant une partie des eaux d'une agglomération pour limiter le risque
d'inondation, par des canaux intermittents).
Il semble donc que Positron lui ait fait le choix de ne faire le rendu que
du filaire, et des surfaces mais seulement si elles sont des polygones
fermés (ce qui n'est pas le cas partout, il a oublié qu'il pouvait y avoir
aussi des relations "multipolygon"). Bref c'est un bogue de Positron, pas
d'OSM.

Le jeu. 18 oct. 2018 à 23:57, François Lacombe 
a écrit :

> Bonsoir,
>
> Une petite question sur les deux relations qui qualifient Le Rhône :
> La 1ere pour sur le filaire river :
> https://www.openstreetmap.org/way/34907146
> La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve :
> https://www.openstreetmap.org/relation/660056
>
> Je ne comprends pas l'intérêt de la deuxième.
> Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer la
> 2nde pour ne laisser que des polygones riverbanks continus sans relation ?
>
> On dirait que ça met le bazar sur des rendus comme Positron :
> https://www.maptiler.com/maps/#positron//vector/15.12/5.81699/46.054843
> (même si on ne tag pas pour le rendu)
>
> Merci par avance pour vos retours, bonne soirée
>
> François
> ___
> 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-cz] ŘSD - ploty - odpověď

[Honza Cibulka]

Dobrej je komentář k InfZ [1] od Jelínkové a Tuháčka, praktický je (i když 
trochu starší) komentář od Korbela [2]. A úřady k výkladu používají nejčastěji 
komentář od Furka, Rothanza a Jirovce [3], ale ten je už hodně podrobný (a 
právě ten třeba řeší obcházení zpoplatnění tím, že požádá „někdo druhý“, který 
chce už vyhledaná a zpracovaná data).

 

Užitečná je poradna Otevřené společnosti (možno hledat starší dotazy) [4]

 

A samotná judikatura je dohledatelná na webu NSS [5], v rozšířeném formuláři 
třeba vybrat Oblast úpravy: Právo na informace.

 

[1] 
https://obchod.wolterskluwer.cz/cz/zakon-o-svobodnem-pristupu-k-informacim-prakticky-komentar.p4143.html

[2] 
https://www.kosmas.cz/knihy/186463/prehled-judikatury-ve-vecech-prava-na-informace/

[3] https://www.beck.cz/zakon-o-svobodnem-pristupu-k-informacim-komentar

[4] http://poradna.otevrenaspolecnost.cz/pravo-na-informace

[5] http://nssoud.cz/main0Col.aspx?cls=JudikaturaBasicSearch 
 
=0

 

From: Michal Poupa  
Sent: pátek 19. října 2018 8:55
To: OpenStreetMap Czech Republic 
Subject: Re: [Talk-cz] ŘSD - ploty - odpověď

 

Je někde ta judikatura? Potřebuji něco od ŘLP a měli podobný postoj

 

  Michal

 


19. 10. 2018 v 7:26, Honza Cibulka mailto:ho...@datastory.cz> >:

Bohužel, judikatura už dovodila, že je to obcházení zákona (stejně jako kdyby o 
to samý teď požádal někdo jinej) a že ty peníze můžou účtovat, dokud to jednou 
někdo nezaplatí ;)

Jan Cibulka

 

tel. 776   307 158

http://datastory.cz  


On 18 Oct 2018, at 23:22, Pavel Machek mailto:pa...@ucw.cz> > 
wrote:

AhoJ!




To je zajímavý: Oni píšou, že už ty informace dohledali a teď chtějí

úhradu, což je zjevně lež - pokud by to opravdu tak náročný bylo,

řekli by si o peníze předem. Takhle riskujou, že žadatel nezaplatí a

těch 600+ hodin práce spadne pod stůl.


No, ono to je jeste zajimavejsi. V prvnim odstavci pisou ze zadatel je
povinen do 60ti dnu uhradit.

Na konci pisou ze data dostane jen kdyz uhradi. Hmm.

Co takhle pockat 60 dni, a pak si o data rict znova? Pak uz se nebudou
moct vymlouvat ze to hledaj ;-).
   Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

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

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

Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[Philippe Verdy]

Les multipolygons des riverbanks arrivent justement parce que tous les
riverbanks ne sont pas des polygones fermés et ont du à un moment être
découpés (à cause des difficultés liées aux superpositions des ways avec
divers autres polygons attenants, mais aussi parce qu'il y a assez souvent
aussi des iles à exclure au milieu).
Globalement les riverbanks doivent être tagués comme surfaces. Mais leur
géométrie cadre mal avec le filaire (qui en sont une version simplifiée) et
ont aussi des relations optionelles pour les grouper, et aussi les associer
entre eux (par des membres "tributary", spécifiques qux relations
waterway=*, mais non compatibles avec les relations multipolygon).
On ne peut pas mélanger les ways du filaire et les ways des multipolygon,
cela donne des anomalies entre plus critiques. Si on change le type de
relation waterway en multipolygon, ce multipolygon se retrouve avec des
ways "inner" et "outer" et souvent aussi d'autres sans role, pour les
riverbanks; mais en plus aussi pour le filaire des ways membres
"main_stream" et "secondary_stream", mais encore assez souvent des ways
sans rôle, sui du coup sont ambigus entre l'interprétation surfacique et
l'interprétation filaire.)
Enfin on trouve assez souvent des ways partagés entre le filaire
(waterway=*) et le surfacique (water=riverbank) dans des sections étroites.
C'est difficile de faire cohabiter les deux sans créer diverses anomalies
de géométrie.
Je pense que les relations séparées se justifient et c'est plutôt Poitron
qui a des problèmes à distinguer les deux types et tente de tout mélanger.
On voit ce que cela provoque chez lui.
Il vaut mieux avoir deux relations (d'autant plus que les surfaces des
"riverbank" ne sont pas toujours contigues, car il peut y avoir des parties
de cours d'eau souterraines ou parce que tout le cours d'eau n'a pas été
tagué avec des riverbanks : typiquement pas pour les parties en amont et
diverses sources)
Les relations filaires contiennent aussi d'autres membres optionnels : un
ou plusieurs noeuds de rôle "stream" pour la ou les sources, un membre
relation de rôle "riverbank" associant la relation "riverbank" collectant
toutes les surfaces).
Je pense que c'est une mauvaise idée de tout mélanger dans une seule
relation, cela posera encore plus de problèmes. Ton problème est plutôt une
anomalie spécifique du rendu Positron qui tente d'interpréter ou "réparer"
à sa façon.
Les relations "multipolygon" des surfaces riverbank sont plutôt à laisser
inchangés et entièrement compatibles avec les polygones fermés simples, la
transformation de l'un en l'autre étant possible à tout moment, mais ne
doivent avoir aucun membre supplémentaire (chemins "main_stream", noeuds
"stream", relation "tributary", qui sont pour les relations filaires, où
les chemins membres "*_stream" sont tous orientés, contrairement aux
chemins membres des relations multipolygon de surface).
La complétude du filaire est également bien plus avancée (que celle des
surfaces), elle forme un réseau (ce n'est pas le cas des surfaces riverbank
qui sont toutes parcellaires). La priorité est donnée encore au filaire des
relations "waterway" qui devrait être interconnecté en réseau orienté. les
surfaces c'est un "luxe" supplémentaire ajouté séparément pour représenter
autre chose (globalement l'utilisation du sol).

Le jeu. 18 oct. 2018 à 23:57, François Lacombe 
a écrit :

> Bonsoir,
>
> Une petite question sur les deux relations qui qualifient Le Rhône :
> La 1ere pour sur le filaire river :
> https://www.openstreetmap.org/way/34907146
> La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve :
> https://www.openstreetmap.org/relation/660056
>
> Je ne comprends pas l'intérêt de la deuxième.
> Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer la
> 2nde pour ne laisser que des polygones riverbanks continus sans relation ?
>
> On dirait que ça met le bazar sur des rendus comme Positron :
> https://www.maptiler.com/maps/#positron//vector/15.12/5.81699/46.054843
> (même si on ne tag pas pour le rendu)
>
> Merci par avance pour vos retours, bonne soirée
>
> François
> ___
> 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-it] nomi vie con numeri romani

[Marcello]

On 19/10/2018 12:13, Cascafico Giovanni wrote:
> Il giorno ven 19 ott 2018 alle ore 11:55 Marco_T  > ha scritto:
>
>
> In questo caso il nome del mese non è usato come nome comune ("in
> aprile
> arrivano le rondini") ma come nome proprio della via in quanto
> appellativo
> toponomastico unico ed individuale della strada all'interno del
> Comune.
> Pertanto a mio parere le iniziali vanno in maiuscolo. Come se una
> persona si
> chiamsse Primo (nome), Agosto (cognome).
> Mia opinione.
>
>  
>
> +1
>
+1

Anche nel manuale di stile di Wikipedia [1] c'è scritto che il nome
andrebbe in maiuscolo, poi i nomi degli avvenimenti storici di grande
importanza sono considerati nomi propri, da scrivere con le maiuscole,
quindi per me va messo Primo Maggio, Venticinque Aprile, ecc.

[1] https://it.wikipedia.org/wiki/Aiuto:Maiuscolo_e_minuscolo#Odonimi

Ciao
Marcello

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

Re: [Talk-it] nomi vie con numeri romani

[Andrea Musuruane]

Ciao,

On Thu, Oct 18, 2018 at 11:34 PM demon.box  wrote:

> Andrea Musuruane wrote
> > Le regole ISTAT, che i comuni devono seguire per dare i nomi alle aree di
> > circolazione sono le seguenti:
> >
> >- Le aree di circolazioni che riportano date complete, si inseriscono
> >utilizzando la la numerazione naturale (1, 2, 3, ecc.) per i giorni e
> > per
> >l'anno, e il mese con caratteri alfabetici (gennaio, febbraio, ecc.).
> > Es.
> >Via 18 agosto 1944.
> >- Le aree di circolazione che riportano date composte solo da giorni e
> >mese, si inseriscono esplicitando il giorno in lettere. Es: Via
> > venticinque
> >aprile.
>
> ciao Andrea, ma nel caso di "Via Papa Giovanni XXIII", stesso schema?
>
> name=Via Papa Giovanni Ventitreesimo
> alt_name=Via Papa Giovanni XXIII
> short_name=Via Papa Giovanni 23°
>
> siamo d'accordo?
>

Il name è corretto; è quello che prevede l'ISTAT (es:  "Via Papa Pio
Dodicesimo"). alt_name direi che va bene. Ho qualche dubbio invece sullo
short_name: non mi sembra una grafia che sia mai stata usata.

Ciao,

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

Re: [Talk-it] nomi vie con numeri romani

[Sergio Manzi]

-1


On 2018-10-19 12:13, Cascafico Giovanni wrote:
> Il giorno ven 19 ott 2018 alle ore 11:55 Marco_T  > ha scritto:
>
>
> In questo caso il nome del mese non è usato come nome comune ("in aprile
> arrivano le rondini") ma come nome proprio della via in quanto appellativo
> toponomastico unico ed individuale della strada all'interno del Comune.
> Pertanto a mio parere le iniziali vanno in maiuscolo. Come se una persona 
> si
> chiamsse Primo (nome), Agosto (cognome).
> Mia opinione.
>
>  
>
> +1
>
>
>
> ___
> 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-es] Fwd: Reconocimiento IGN en OSM

[Miguel Sevilla-Callejo]

Magnífico, muchas gracias
Mañana hablaremos del tema en Madrid
Un saludo

--
*Miguel Sevilla-Callejo*
Doctor en Geografía


On Fri, 19 Oct 2018 at 13:11, Matías h  wrote:

> Hola de nuevo.
>
> A ver si soy capaz de encontrarlo todo.
>
> [1] Carta autorizando el USO.
> [2] Conversacion Enero 2018:* Permiso expreso IGN-PNOA (era WMS
> CartoCiudad). *
> [3] Conversacion Diciembre 2016: *IGN en página de Copyright de OSM y
> reunión inminente*
> [4] Acta Reunion Virtual 07/02/2017: *Se comenta Lo tratado en la Reunión
> con IGN por parte de Santiago Crespo.*
>
> [1]
> https://wiki.openstreetmap.org/wiki/File:OPENSTREETMAPCartaAbiertaIGN-espa%C3%B1ol.pdf
> [2]
> http://gis.19327.n8.nabble.com/Re-Permiso-expreso-IGN-PNOA-era-WMS-Cartociudad-td5909745.html#none
> [3]
> http://gis.19327.n8.nabble.com/IGN-en-pagina-de-copyright-de-OSM-y-reunion-inminente-td5887304i20.html#a5887604
> [4] https://wiki.openstreetmap.org/wiki/ES:Acta_20170207
>
> Seguro que en algún correo más se ha tratado, pero lo esencial está aquí.
>
> En la wiki también hay mucha documentación sobre como se iban a realizar
> algunas importaciones e incluso Santiago Crespo desarrollo algunas
> herramientas para empezar con al red Hidrográfica, pero quizás eso no sea
> ahora lo importante ni mucho menos.
>
> Aparte de esto, tengo varios correos mantenidos con Antonio F. tratando
> sobre el tema.
>
> A ver si por fin, llegamos a algo.
> Saludos.
>
>
>
>
> El vie., 19 oct. 2018 a las 12:46, Miguel Sevilla-Callejo (<
> msevill...@gmail.com>) escribió:
>
>> Hola Matías,
>>
>> Gracias por tu pronta respuesta, como vamos a volver a tener
>> conversaciones con Antonio, te agradecería si pudieras buscar los enlaces
>> concretos a los documentos y los hilos de conversación y luego si es
>> necesario abrir una página exclusiva en la wiki para desarrollar y
>> documentar el tema.
>>
>> Respecto a lo de la FOSM, si no se ha hecho (juraría que alguien contactó
>> directamente con Simon Poole), quizá sea ahora el momento de enviar un
>> correo para que nos aclare definitivamente el tema.
>>
>> Ya sabes que discrepo con respecto al uso de la autorización que
>> mencionas, pero en caso de que no sirviera para nada, es el momento de
>> resolver el tema pues entiendo que el espíritu del IGN es el de
>> facilitarnos el acceso a los datos e incluso colaborar activamente con
>> nosotros.
>>
>> A colación de todo esto está que NO SOMOS capítulo local de OSM al tener
>> "desactivada" la asociación por lo que nos podemos dirigir a la FOSM de
>> diferente manera a si lo fueramos.
>>
>> Gracias por la información
>>
>> Un saludo
>>
>> --
>> *Miguel Sevilla-Callejo*
>> Doctor en Geografía
>>
>>
>> On Fri, 19 Oct 2018 at 11:56, Matías h  wrote:
>>
>>> Hoola.
>>>
>>> A ver, creo recordar y así lo tengo registrado en mis correos con
>>> Antonio, que desde el IGN se les mandó una carta (LA misma que tenemos en
>>> la wiki con las autorización expresa). Lo que desconozco es si la Fundación
>>> les contestó con algún requisito más o hizo silencio administrativo, ni
>>> idea.
>>>
>>> Yo le pregunté a Antonio en ese intercambio de correos, si con esa carta
>>> significaba que aceptaban las condiciones de la OSM Fundation y me dijo que
>>> sí. Entendimos que las condiciones que cumple ahora mismo la OSM es poner
>>> las atribucciones, no donde quería el IGN, sino en la página de la wiki.
>>>
>>> En varias ocasiones a lo largo de estos últimos años, he repetido que
>>> habría que ponerse en contacto con la Fundación y conseguir una respuesta
>>> suya a este respecto, sea la que sea, pero hasta ahora no se si alguien ha
>>> conseguido algo.y seguimos haciendo lo que nos parece con los datos del
>>> IGN.
>>>
>>> La Carta de autorización que tenemos NO SIRVE PARA NADA tal y como está
>>> redactada porque se remiten a la licencia y tal licencia no es compatible
>>> con OSM.
>>>
>>>
>>> El vie., 19 oct. 2018 a las 11:29, Miguel Sevilla-Callejo (<
>>> msevill...@gmail.com>) escribió:
>>>
 Hola,

 El asunto que trato en este correo es de GRAN RELEVANCIA:

 Os remito más abajo (leer desde los correos de abajo hacia arriba) el
 intercambio de correos que he tenido estos días con el subdirector adjunto
 con Antonio F. Rodríguez Pascual, Subdirector adjunto del Centro Nacional
 de Información Geográfica.

 Desde esta institución vuelven a llamarnos la atención con la
 atribución de los datos en el proyecto.

 Como podréis leer ya le he remitido a alguna de nuestras discusiones en
 el pasado pero quiero recordar que los últimos pasos que se dieron, la
 menos en el tema de la aparición del IGN en la página de Copyright de OSM
 se había llevado a la gente de la FOSM pero no encuentro qué se dijo
 finalmente. Es más, pensé que desde el IGN esto ya estaba zanjado.

 Todo el material de lo que ya hemos discutido y lo que se había
 acordado al respecto más vuestras opiniones será de gran ayuda para
 reestablecer 

Re: [Talk-es] Fwd: Reconocimiento IGN en OSM

[Matías h]

Hola de nuevo.

A ver si soy capaz de encontrarlo todo.

[1] Carta autorizando el USO.
[2] Conversacion Enero 2018:* Permiso expreso IGN-PNOA (era WMS
CartoCiudad). *
[3] Conversacion Diciembre 2016: *IGN en página de Copyright de OSM y
reunión inminente*
[4] Acta Reunion Virtual 07/02/2017: *Se comenta Lo tratado en la Reunión
con IGN por parte de Santiago Crespo.*

[1]
https://wiki.openstreetmap.org/wiki/File:OPENSTREETMAPCartaAbiertaIGN-espa%C3%B1ol.pdf
[2]
http://gis.19327.n8.nabble.com/Re-Permiso-expreso-IGN-PNOA-era-WMS-Cartociudad-td5909745.html#none
[3]
http://gis.19327.n8.nabble.com/IGN-en-pagina-de-copyright-de-OSM-y-reunion-inminente-td5887304i20.html#a5887604
[4] https://wiki.openstreetmap.org/wiki/ES:Acta_20170207

Seguro que en algún correo más se ha tratado, pero lo esencial está aquí.

En la wiki también hay mucha documentación sobre como se iban a realizar
algunas importaciones e incluso Santiago Crespo desarrollo algunas
herramientas para empezar con al red Hidrográfica, pero quizás eso no sea
ahora lo importante ni mucho menos.

Aparte de esto, tengo varios correos mantenidos con Antonio F. tratando
sobre el tema.

A ver si por fin, llegamos a algo.
Saludos.




El vie., 19 oct. 2018 a las 12:46, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> Hola Matías,
>
> Gracias por tu pronta respuesta, como vamos a volver a tener
> conversaciones con Antonio, te agradecería si pudieras buscar los enlaces
> concretos a los documentos y los hilos de conversación y luego si es
> necesario abrir una página exclusiva en la wiki para desarrollar y
> documentar el tema.
>
> Respecto a lo de la FOSM, si no se ha hecho (juraría que alguien contactó
> directamente con Simon Poole), quizá sea ahora el momento de enviar un
> correo para que nos aclare definitivamente el tema.
>
> Ya sabes que discrepo con respecto al uso de la autorización que
> mencionas, pero en caso de que no sirviera para nada, es el momento de
> resolver el tema pues entiendo que el espíritu del IGN es el de
> facilitarnos el acceso a los datos e incluso colaborar activamente con
> nosotros.
>
> A colación de todo esto está que NO SOMOS capítulo local de OSM al tener
> "desactivada" la asociación por lo que nos podemos dirigir a la FOSM de
> diferente manera a si lo fueramos.
>
> Gracias por la información
>
> Un saludo
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
>
>
> On Fri, 19 Oct 2018 at 11:56, Matías h  wrote:
>
>> Hoola.
>>
>> A ver, creo recordar y así lo tengo registrado en mis correos con
>> Antonio, que desde el IGN se les mandó una carta (LA misma que tenemos en
>> la wiki con las autorización expresa). Lo que desconozco es si la Fundación
>> les contestó con algún requisito más o hizo silencio administrativo, ni
>> idea.
>>
>> Yo le pregunté a Antonio en ese intercambio de correos, si con esa carta
>> significaba que aceptaban las condiciones de la OSM Fundation y me dijo que
>> sí. Entendimos que las condiciones que cumple ahora mismo la OSM es poner
>> las atribucciones, no donde quería el IGN, sino en la página de la wiki.
>>
>> En varias ocasiones a lo largo de estos últimos años, he repetido que
>> habría que ponerse en contacto con la Fundación y conseguir una respuesta
>> suya a este respecto, sea la que sea, pero hasta ahora no se si alguien ha
>> conseguido algo.y seguimos haciendo lo que nos parece con los datos del
>> IGN.
>>
>> La Carta de autorización que tenemos NO SIRVE PARA NADA tal y como está
>> redactada porque se remiten a la licencia y tal licencia no es compatible
>> con OSM.
>>
>>
>> El vie., 19 oct. 2018 a las 11:29, Miguel Sevilla-Callejo (<
>> msevill...@gmail.com>) escribió:
>>
>>> Hola,
>>>
>>> El asunto que trato en este correo es de GRAN RELEVANCIA:
>>>
>>> Os remito más abajo (leer desde los correos de abajo hacia arriba) el
>>> intercambio de correos que he tenido estos días con el subdirector adjunto
>>> con Antonio F. Rodríguez Pascual, Subdirector adjunto del Centro Nacional
>>> de Información Geográfica.
>>>
>>> Desde esta institución vuelven a llamarnos la atención con la atribución
>>> de los datos en el proyecto.
>>>
>>> Como podréis leer ya le he remitido a alguna de nuestras discusiones en
>>> el pasado pero quiero recordar que los últimos pasos que se dieron, la
>>> menos en el tema de la aparición del IGN en la página de Copyright de OSM
>>> se había llevado a la gente de la FOSM pero no encuentro qué se dijo
>>> finalmente. Es más, pensé que desde el IGN esto ya estaba zanjado.
>>>
>>> Todo el material de lo que ya hemos discutido y lo que se había acordado
>>> al respecto más vuestras opiniones será de gran ayuda para reestablecer
>>> relaciones con el IGN y plantearles soluciones a sus inquietudes.
>>>
>>> Mañana en la reunión de la Geocamp sacaré el tema y reflexionaremos al
>>> respecto los que allí estemos. En cuento sepa la hora para conexión remota
>>> os pongo al corriente (espero enviar correo al respecto).
>>>
>>> Un saludo
>>>
>>> --
>>> 

Re: [Talk-cz] historic=tomb se nerenderuje na Mapniku

[majka]

Nejlépe asi přes overpass turbo, wizard zafunguje pro většinu případů.
Konkrétně historic=tomb  , je třeba najet
na odpovídající místo. Nebo by se daly vyhledat všechny v Čechách
 (celkem 98 bodů)
On Fri, 19 Oct 2018 at 12:52, Pavel Pilát  wrote:

> Lze mimochodem v OSM hledat přímo objekty s určitým tagem? Např. konkrétně
> by mě zajímalo, kde je kolem Koryčan další nejbližší historic=tomb .
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Voting Default Language Format

[Christian Quest]

Elle règle une partie des problèmes, mais ne permet pas de gérer du 100%.

Ceci dit, on n'est pas obligé de l'utiliser cette info ou bien le faire
avec intelligence...

Cas du rendu FR: si default:language=fr, je prends les name, sinon je
prends les name:fr

Du coup, on aura bien le "name" sur le territoire français, même si il
n'est pas en français mais occitan ce qui est au final l'objectif
recherché, non ?

Pour savoir véritablement dans quelle langue est name=*, il faut le
comparer aux différents name:xx=* , il n'y a finalement que ça de fiable si
c'est cette info qu'on veut obtenir.


Le ven. 19 oct. 2018 à 12:28, Rpnpif  a écrit :

> Le 19 octobre 2018, rainerU a écrit :
>
> > Bonjour,
> >
> > Je me pose des questions sur l'impact de cette proposition sur les
> objets qui
> > ont un nom officiel en langue régionale :
> >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
> >
> > Si j'ai bien compris la proposition, on mettrait default:language=fr sur
> la
> > frontière de la France (ou des régions, départements,...) et les
> applications
> > utiliseraient name=fr comme nom standard.
> >
> > A mon avis, cela pose un problème dans les cas où le nom officiel d'un
> objet est
> > en langue régionale mais existe aussi un nom en français. Il y a eu un
> fil de
> > discussion sur cette liste sur la manière de tagguer ces cas avec le
> schéma
> > actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je taggue
> name= > officiel>, name:ca=, name:fr=. Avec le
> schéma
> > proposé, un rendu en langue standard afficherait le nom français et pas
> le nom
> > officiel en catalan. Si par contre on mettait name:fr=, on
> ne
> > pourrait plus créer un rendu 100% français.
> >
> > Est-ce que cette question a déjà été discuté ici ou ailleurs, si oui
> quelle
> > était la conclusion ?
>
> Bonjour,
> Oui je suis d'accord avec toi : ce n'est pas une proposition
> pertinente.
>
> --
> Alain Rpnpif
>
> ___
> 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-cz] historic=tomb se nerenderuje na Mapniku

[Pavel Pilát]

Lze mimochodem v OSM hledat přímo objekty s určitým tagem? Např. konkrétně
by mě zajímalo, kde je kolem Koryčan další nejbližší historic=tomb .

On Thu, Oct 18, 2018 at 3:46 PM Pavel Pilát  wrote:

> OK, děkuju za informace. :-)
>
> On Thu, Oct 18, 2018 at 3:38 PM Marián Kyral  wrote:
>
>> Data na poloha.net se většinou aktualizují každý den po půlnoci.
>>
>> Marián
>>
>> -- Původní e-mail --
>> Od: xkomc...@centrum.cz 
>> Komu: talk-cz@openstreetmap.org
>> Datum: 18. 10. 2018 14:44:04
>> Předmět: Re: [Talk-cz] historic=tomb se nerenderuje na Mapniku
>>
>> Ta je hostovaná na serveru poloha.net, který patří Petrovi Vejsadovi.
>> Nevím jak moc sleduje tento list, kdyby dlouho nedopovídal a nikdo jiný
>> nevěděl, kontaktní formulář na něj je kdyžtak tady -
>> http://www.poloha.net/contact
>>
>> On 18.10.2018 14:18, Pavel Pilát wrote:
>>
>> Zajímala by mě tedy hlavně vrstva "Turistická mapa (ČR)".
>>
>> On Thu, Oct 18, 2018 at 2:12 PM majka  wrote:
>>
>>
>>
>> On Thu, 18 Oct 2018 at 14:10, Pavel Pilát  wrote:
>>
>> Ještě se vrátím k jedné otázce z mého úvodního příspěvku (pokud někdo
>> víte):
>>
>> Jak často jsou vlastně české mapy aktualizovány?
>>
>> Které konkrétně?
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
>>
>>
>> ___
>> Talk-cz mailing 
>> listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-czhttps://openstreetmap.cz/talkcz
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
>>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-es] Fwd: Reconocimiento IGN en OSM

[Miguel Sevilla-Callejo]

Hola Matías,

Gracias por tu pronta respuesta, como vamos a volver a tener conversaciones
con Antonio, te agradecería si pudieras buscar los enlaces concretos a los
documentos y los hilos de conversación y luego si es necesario abrir una
página exclusiva en la wiki para desarrollar y documentar el tema.

Respecto a lo de la FOSM, si no se ha hecho (juraría que alguien contactó
directamente con Simon Poole), quizá sea ahora el momento de enviar un
correo para que nos aclare definitivamente el tema.

Ya sabes que discrepo con respecto al uso de la autorización que mencionas,
pero en caso de que no sirviera para nada, es el momento de resolver el
tema pues entiendo que el espíritu del IGN es el de facilitarnos el acceso
a los datos e incluso colaborar activamente con nosotros.

A colación de todo esto está que NO SOMOS capítulo local de OSM al tener
"desactivada" la asociación por lo que nos podemos dirigir a la FOSM de
diferente manera a si lo fueramos.

Gracias por la información

Un saludo

--
*Miguel Sevilla-Callejo*
Doctor en Geografía


On Fri, 19 Oct 2018 at 11:56, Matías h  wrote:

> Hoola.
>
> A ver, creo recordar y así lo tengo registrado en mis correos con Antonio,
> que desde el IGN se les mandó una carta (LA misma que tenemos en la wiki
> con las autorización expresa). Lo que desconozco es si la Fundación les
> contestó con algún requisito más o hizo silencio administrativo, ni idea.
>
> Yo le pregunté a Antonio en ese intercambio de correos, si con esa carta
> significaba que aceptaban las condiciones de la OSM Fundation y me dijo que
> sí. Entendimos que las condiciones que cumple ahora mismo la OSM es poner
> las atribucciones, no donde quería el IGN, sino en la página de la wiki.
>
> En varias ocasiones a lo largo de estos últimos años, he repetido que
> habría que ponerse en contacto con la Fundación y conseguir una respuesta
> suya a este respecto, sea la que sea, pero hasta ahora no se si alguien ha
> conseguido algo.y seguimos haciendo lo que nos parece con los datos del
> IGN.
>
> La Carta de autorización que tenemos NO SIRVE PARA NADA tal y como está
> redactada porque se remiten a la licencia y tal licencia no es compatible
> con OSM.
>
>
> El vie., 19 oct. 2018 a las 11:29, Miguel Sevilla-Callejo (<
> msevill...@gmail.com>) escribió:
>
>> Hola,
>>
>> El asunto que trato en este correo es de GRAN RELEVANCIA:
>>
>> Os remito más abajo (leer desde los correos de abajo hacia arriba) el
>> intercambio de correos que he tenido estos días con el subdirector adjunto
>> con Antonio F. Rodríguez Pascual, Subdirector adjunto del Centro Nacional
>> de Información Geográfica.
>>
>> Desde esta institución vuelven a llamarnos la atención con la atribución
>> de los datos en el proyecto.
>>
>> Como podréis leer ya le he remitido a alguna de nuestras discusiones en
>> el pasado pero quiero recordar que los últimos pasos que se dieron, la
>> menos en el tema de la aparición del IGN en la página de Copyright de OSM
>> se había llevado a la gente de la FOSM pero no encuentro qué se dijo
>> finalmente. Es más, pensé que desde el IGN esto ya estaba zanjado.
>>
>> Todo el material de lo que ya hemos discutido y lo que se había acordado
>> al respecto más vuestras opiniones será de gran ayuda para reestablecer
>> relaciones con el IGN y plantearles soluciones a sus inquietudes.
>>
>> Mañana en la reunión de la Geocamp sacaré el tema y reflexionaremos al
>> respecto los que allí estemos. En cuento sepa la hora para conexión remota
>> os pongo al corriente (espero enviar correo al respecto).
>>
>> Un saludo
>>
>> --
>> *Miguel Sevilla-Callejo*
>> Doctor en Geografía
>>
>>
>> -- Forwarded message -
>> From: Rodríguez Pascual Antonio Federico 
>> Date: Fri, 19 Oct 2018 at 10:00
>> Subject: RE: Reconocimiento IGN en OSM
>> To: Miguel Sevilla-Callejo 
>>
>>
>> Gracias por todo Miguel.
>> Claro que puedes reenviar este mensaje a quien quieras.
>> Entiendo que el IGN no ha contribuido tanto a OSM como otros, ok.
>> Pero preferiria que todos los reconocimientos se hicieran en la mima
>> pagina e independientemente, se describiese cuantitativamente la aportacion
>> con alguna metrica: por ejemplo muy poco , poco, media, alta y muy alta,
>> distinguiendo datos aportados (hay cierta obligacion) de esfuerzo en horas
>> perona (se teconoce por agradecimiento).
>> Un abrazo.
>> Antonio
>>
>>
>> Enviado desde mi dispositivo Samsung
>>
>>
>>  Mensaje original 
>> De: Miguel Sevilla-Callejo 
>> Fecha: 19/10/18 9:46 (GMT+01:00)
>> Para: Rodríguez Pascual Antonio Federico 
>> Asunto: Re: Reconocimiento IGN en OSM
>>
>> Hola Antonio,
>>
>> Voy a llevar este tema a la reunión de la Geocamp y lo voy a volver a
>> mover por la lista de correos de OSM para que me refresquen el tema pues si
>> no recuerdo mal es la tercera vez que tratamos el asunto de cómo aparecéis
>> en los créditos de OSM y creo recordar que la última vez se contactó con la
>> Fundación OSM, de la que depende finalmente la 

Re: [OSM-talk-fr] Voting Default Language Format

[Rpnpif]

Le 19 octobre 2018, rainerU a écrit :

> Bonjour,
> 
> Je me pose des questions sur l'impact de cette proposition sur les objets qui 
> ont un nom officiel en langue régionale :
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
> 
> Si j'ai bien compris la proposition, on mettrait default:language=fr sur la 
> frontière de la France (ou des régions, départements,...) et les applications 
> utiliseraient name=fr comme nom standard.
> 
> A mon avis, cela pose un problème dans les cas où le nom officiel d'un objet 
> est 
> en langue régionale mais existe aussi un nom en français. Il y a eu un fil de 
> discussion sur cette liste sur la manière de tagguer ces cas avec le schéma 
> actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je taggue 
> name= officiel>, name:ca=, name:fr=. Avec le schéma   
> proposé, un rendu en langue standard afficherait le nom français et pas le 
> nom 
> officiel en catalan. Si par contre on mettait name:fr=, on ne 
> pourrait plus créer un rendu 100% français.
> 
> Est-ce que cette question a déjà été discuté ici ou ailleurs, si oui quelle 
> était la conclusion ?

Bonjour,
Oui je suis d'accord avec toi : ce n'est pas une proposition
pertinente.

-- 
Alain Rpnpif

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

Re: [Talk-it] nomi vie con numeri romani

[Cascafico Giovanni]

Il giorno ven 19 ott 2018 alle ore 11:55 Marco_T  ha
scritto:

>
> In questo caso il nome del mese non è usato come nome comune ("in aprile
> arrivano le rondini") ma come nome proprio della via in quanto appellativo
> toponomastico unico ed individuale della strada all'interno del Comune.
> Pertanto a mio parere le iniziali vanno in maiuscolo. Come se una persona
> si
> chiamsse Primo (nome), Agosto (cognome).
> Mia opinione.
>


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

Re: [Talk-es] Fwd: Reconocimiento IGN en OSM

[Matías h]

Hoola.

A ver, creo recordar y así lo tengo registrado en mis correos con Antonio,
que desde el IGN se les mandó una carta (LA misma que tenemos en la wiki
con las autorización expresa). Lo que desconozco es si la Fundación les
contestó con algún requisito más o hizo silencio administrativo, ni idea.

Yo le pregunté a Antonio en ese intercambio de correos, si con esa carta
significaba que aceptaban las condiciones de la OSM Fundation y me dijo que
sí. Entendimos que las condiciones que cumple ahora mismo la OSM es poner
las atribucciones, no donde quería el IGN, sino en la página de la wiki.

En varias ocasiones a lo largo de estos últimos años, he repetido que
habría que ponerse en contacto con la Fundación y conseguir una respuesta
suya a este respecto, sea la que sea, pero hasta ahora no se si alguien ha
conseguido algo.y seguimos haciendo lo que nos parece con los datos del
IGN.

La Carta de autorización que tenemos NO SIRVE PARA NADA tal y como está
redactada porque se remiten a la licencia y tal licencia no es compatible
con OSM.


El vie., 19 oct. 2018 a las 11:29, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> Hola,
>
> El asunto que trato en este correo es de GRAN RELEVANCIA:
>
> Os remito más abajo (leer desde los correos de abajo hacia arriba) el
> intercambio de correos que he tenido estos días con el subdirector adjunto
> con Antonio F. Rodríguez Pascual, Subdirector adjunto del Centro Nacional
> de Información Geográfica.
>
> Desde esta institución vuelven a llamarnos la atención con la atribución
> de los datos en el proyecto.
>
> Como podréis leer ya le he remitido a alguna de nuestras discusiones en el
> pasado pero quiero recordar que los últimos pasos que se dieron, la menos
> en el tema de la aparición del IGN en la página de Copyright de OSM se
> había llevado a la gente de la FOSM pero no encuentro qué se dijo
> finalmente. Es más, pensé que desde el IGN esto ya estaba zanjado.
>
> Todo el material de lo que ya hemos discutido y lo que se había acordado
> al respecto más vuestras opiniones será de gran ayuda para reestablecer
> relaciones con el IGN y plantearles soluciones a sus inquietudes.
>
> Mañana en la reunión de la Geocamp sacaré el tema y reflexionaremos al
> respecto los que allí estemos. En cuento sepa la hora para conexión remota
> os pongo al corriente (espero enviar correo al respecto).
>
> Un saludo
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
>
>
> -- Forwarded message -
> From: Rodríguez Pascual Antonio Federico 
> Date: Fri, 19 Oct 2018 at 10:00
> Subject: RE: Reconocimiento IGN en OSM
> To: Miguel Sevilla-Callejo 
>
>
> Gracias por todo Miguel.
> Claro que puedes reenviar este mensaje a quien quieras.
> Entiendo que el IGN no ha contribuido tanto a OSM como otros, ok.
> Pero preferiria que todos los reconocimientos se hicieran en la mima
> pagina e independientemente, se describiese cuantitativamente la aportacion
> con alguna metrica: por ejemplo muy poco , poco, media, alta y muy alta,
> distinguiendo datos aportados (hay cierta obligacion) de esfuerzo en horas
> perona (se teconoce por agradecimiento).
> Un abrazo.
> Antonio
>
>
> Enviado desde mi dispositivo Samsung
>
>
>  Mensaje original 
> De: Miguel Sevilla-Callejo 
> Fecha: 19/10/18 9:46 (GMT+01:00)
> Para: Rodríguez Pascual Antonio Federico 
> Asunto: Re: Reconocimiento IGN en OSM
>
> Hola Antonio,
>
> Voy a llevar este tema a la reunión de la Geocamp y lo voy a volver a
> mover por la lista de correos de OSM para que me refresquen el tema pues si
> no recuerdo mal es la tercera vez que tratamos el asunto de cómo aparecéis
> en los créditos de OSM y creo recordar que la última vez se contactó con la
> Fundación OSM, de la que depende finalmente la página de OSM como ya te
> adelantaba.
>
> Aquí tienes uno de los hilos abiertos en la lista de correos hace ya casi
> dos años y en el que puedes, si ir mas lejos leer mi opinión al respecto:
> http://gis.19327.n8.nabble.com/IGN-en-pagina-de-copyright-de-OSM-y-reunion-inminente-td5887304.html
>
> La verdad es que tendría que volver a leer los mensajes pero creo recordar
> que a pesar de lo que nos planteas en tu documento el IGN está muy lejos de
> las aportaciones que han hecho otras instituciones plenamente integradas,
> no sol oen datos, si no también en esfuerzos (horas de trabajo de su
> personal) en la construcción de este proyecto colectivo.
>
> De todos modos es muy interesante poder volver a contactar con vosotros
> para poner en orden toda esta cuestión de las licencias pues, aunque no soy
> un experto, creo que hemos de tenerlas claras y meridianas para poder
> seguir trabajando con la inestimable ayuda de los datos abiertos del IGN.
>
> Entiendo perfectamente la frustración que has de tener con todo el asunto,
> me pongo plenamente en tu posición, primero con la cuestión de no poder
> hablar claramente con una persona en concreto en la comunidad, después con
> la "desorganización" y falta 

Re: [Talk-it] nomi vie con numeri romani

[Marco_T]

Lorenzo Pesci-2 wrote
> Come specificato da Istat (e prima ancora dalla grammatica italiana)
> i nomi dei mesi hanno iniziale minuscola!

In questo caso il nome del mese non è usato come nome comune ("in aprile
arrivano le rondini") ma come nome proprio della via in quanto appellativo
toponomastico unico ed individuale della strada all'interno del Comune.
Pertanto a mio parere le iniziali vanno in maiuscolo. Come se una persona si
chiamsse Primo (nome), Agosto (cognome).
Mia opinione.

-- 
Marco_T



--
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-es] Fwd: Reconocimiento IGN en OSM

[Miguel Sevilla-Callejo]

Hola,

El asunto que trato en este correo es de GRAN RELEVANCIA:

Os remito más abajo (leer desde los correos de abajo hacia arriba) el
intercambio de correos que he tenido estos días con el subdirector adjunto
con Antonio F. Rodríguez Pascual, Subdirector adjunto del Centro Nacional
de Información Geográfica.

Desde esta institución vuelven a llamarnos la atención con la atribución de
los datos en el proyecto.

Como podréis leer ya le he remitido a alguna de nuestras discusiones en el
pasado pero quiero recordar que los últimos pasos que se dieron, la menos
en el tema de la aparición del IGN en la página de Copyright de OSM se
había llevado a la gente de la FOSM pero no encuentro qué se dijo
finalmente. Es más, pensé que desde el IGN esto ya estaba zanjado.

Todo el material de lo que ya hemos discutido y lo que se había acordado al
respecto más vuestras opiniones será de gran ayuda para reestablecer
relaciones con el IGN y plantearles soluciones a sus inquietudes.

Mañana en la reunión de la Geocamp sacaré el tema y reflexionaremos al
respecto los que allí estemos. En cuento sepa la hora para conexión remota
os pongo al corriente (espero enviar correo al respecto).

Un saludo

--
*Miguel Sevilla-Callejo*
Doctor en Geografía


-- Forwarded message -
From: Rodríguez Pascual Antonio Federico 
Date: Fri, 19 Oct 2018 at 10:00
Subject: RE: Reconocimiento IGN en OSM
To: Miguel Sevilla-Callejo 


Gracias por todo Miguel.
Claro que puedes reenviar este mensaje a quien quieras.
Entiendo que el IGN no ha contribuido tanto a OSM como otros, ok.
Pero preferiria que todos los reconocimientos se hicieran en la mima pagina
e independientemente, se describiese cuantitativamente la aportacion con
alguna metrica: por ejemplo muy poco , poco, media, alta y muy alta,
distinguiendo datos aportados (hay cierta obligacion) de esfuerzo en horas
perona (se teconoce por agradecimiento).
Un abrazo.
Antonio


Enviado desde mi dispositivo Samsung


 Mensaje original 
De: Miguel Sevilla-Callejo 
Fecha: 19/10/18 9:46 (GMT+01:00)
Para: Rodríguez Pascual Antonio Federico 
Asunto: Re: Reconocimiento IGN en OSM

Hola Antonio,

Voy a llevar este tema a la reunión de la Geocamp y lo voy a volver a mover
por la lista de correos de OSM para que me refresquen el tema pues si no
recuerdo mal es la tercera vez que tratamos el asunto de cómo aparecéis en
los créditos de OSM y creo recordar que la última vez se contactó con la
Fundación OSM, de la que depende finalmente la página de OSM como ya te
adelantaba.

Aquí tienes uno de los hilos abiertos en la lista de correos hace ya casi
dos años y en el que puedes, si ir mas lejos leer mi opinión al respecto:
http://gis.19327.n8.nabble.com/IGN-en-pagina-de-copyright-de-OSM-y-reunion-inminente-td5887304.html

La verdad es que tendría que volver a leer los mensajes pero creo recordar
que a pesar de lo que nos planteas en tu documento el IGN está muy lejos de
las aportaciones que han hecho otras instituciones plenamente integradas,
no sol oen datos, si no también en esfuerzos (horas de trabajo de su
personal) en la construcción de este proyecto colectivo.

De todos modos es muy interesante poder volver a contactar con vosotros
para poner en orden toda esta cuestión de las licencias pues, aunque no soy
un experto, creo que hemos de tenerlas claras y meridianas para poder
seguir trabajando con la inestimable ayuda de los datos abiertos del IGN.

Entiendo perfectamente la frustración que has de tener con todo el asunto,
me pongo plenamente en tu posición, primero con la cuestión de no poder
hablar claramente con una persona en concreto en la comunidad, después con
la "desorganización" y falta de acreditación de los datos en la base de
datos pero has de entender un poco la dinámica de este tipo de proyectos y
cómo funcionamos la comunidad pues, la práctica totalidad de nosotros
hacemos esto "por amor al arte" y sin ninguna retribución por ello, claro,
por lo que siempre tenemos alguna otra prioridad vital por delante.

Sería genial poder tener una reunión y hablar tranquilamente del tema, me
temo que al vivir yo en Zaragoza tendrá que ser remotamente, pero lo
intentamos.

Por favor, confirmamé que puedo rebotar este y los otros correos a la lista
de la comunidad para tenerlos al corriente de nuestras conversaciones.

De todos modos me llevo copia de tu documento a Madrid para hablar del tema.

Un saludo

Miguel

--
*Miguel Sevilla-Callejo*
Doctor en Geografía
Asistente de investigación en el Instituto Pirenaico de Ecología (CSIC)
Profesor Asociado en el Dpto. de Geografía y Ordenación del Territorio de
la Univ. de Zaragoza
Coordinador del grupo de investigación/acción Mapeado Colaborativo en
Zaragoza Activa (Ayto. de Zaragoza)
Consultor freelance. Colegiado #698 del Colegio Oficial de Geógrafos


On Fri, 19 Oct 2018 at 04:50, Rodríguez Pascual Antonio Federico <
afrodrig...@fomento.es> wrote:

> Hola, Miguel, te adjunto un documento que resume nuestras inquietudes. Lo
> he 

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Noémie Lehuby]

Salut Paul,

On est quasiment d'accord !

Mon plan était de commencer par la proposition de Marc de transformer
toutes les amenity=swimming_pool en leisure=swimming_pool comme première
étape.

Puis de faire ce que tu décris, mais sur les leisure=swimming_pool,
puisque comme tu l'as indiqué, il y a aussi des leisure=swimming_pool
qui devraient être leisure=sports_centre. 

Noémie 

Le 2018-10-19 08:42, Paul Desgranges a écrit :

> Bonjour,
> Je n'avais peut-être pas compris le sens du mail de Noémie, et je cherche 
> ci-dessous à le ré-exprimer, voir si on est d'accord :
> 
> L'idée principale consiste à transformer les  "amenity=swimming_pool" 
> soit en "leisure=sports_centre + sport=swimming", 
> soit en "leisure=swimming_pool" 
> 
> Et ceci suivant les heuristiques suivantes :
> 
> 1) Par exemple on peut transformer 
> les "amenity=swimming_pool + name=*" [1] en "leisure=sports_centre + 
> sport=swimming" 
> et les "amenity=swimming_pool + name!=*" [2] en "leisure=swimming_pool" 
> car effectivement quand il y a un nom, c'est un "sports_centre" et quand il 
> n'y a pas de nom, c'est un simple bassin.
> 
> 2) Autre exemple on peut transformer 
> les "amenity=swimming_pool + building=yes" [1] en "leisure=sports_centre + 
> sport=swimming + building=yes" 
> car quand il y a aussi un building, c'est un "sports_centre". A noter que 1) 
> et 2) vont se recouvrir en partie. 
> 
> 3) Il y a des heuristiques sur la taille aussi comme disait Jérôme:
> Quand c'est "petit", c'est plutôt un bassin.
> Quand c'est "grand", c'est plutôt  un sports_centre
> Mais là, a-t-on la possibilité de faire une requête overpass turbo pour les 
> sélectionner sur ce critère de taille? 
> 
> D'autre part, si les "amenity=swimming_pool" sont à éliminer, on peut aussi 
> transformer :
> les "leisure=swimming_pool + building=yes" [3] en "leisure=sports_centre + 
> sport=swimming + building=yes" 
> car les piscines qui sont aussi des buildings sont en fait des 
> "sports_centre". Les contributeurs ont taggué par erreur en "bassin" ce qui 
> plutôt des "sports_centre".  
> 
> Et les transformations ci-dessus seraient à faire avant de faire celles 
> relatives à "covered" (et qui qui sont discutées dans l'autre mail ?) 
> 
> Voilà, y-a-t-il des erreurs ? Est-ce plus clair ? 
> 
> Paul 
> 
> Le 15/10/2018 à 23:04, Paul Desgranges a écrit : 
> 
>> Bonsoir,
>> 
>>> Le 14. 10. 18 à 22:12, Paul Desgranges a écrit :
 Un truc en plus, le terme 'piscine' de manière générale peut signifier à 
 la fois le bassin, le bâtiment, mais aussi le complexe sportif :
 - "leisure=swimming_pool" seul, donc ça serait le bassin, mais 
 "leisure=swimming_pool" + "building=yes" là on parlerait du 'bâtiment 
 piscine'  (le bassin est alors parfois à l'extérieur)
>>> 
>>> cette interprétation me semble erronée.
>>> leisure=swimming_pool est selon moi clairement définit comme étant le 
>>> bassin.
>>> "leisure=swimming_pool" + "building=yes c'est donc un bassin "couvert" 
>>> par un bâtiment. c'est assez rare mais j'en connais un : je suis passé 
>>> plusieurs fois devant en me demandant si c'était un garage entière vitré 
>>> ou une serre en dur... avant d'un jour apercevoir que l'intérieur est 
>>> entièrement constitué d'un bassin d'eau (piscine privé).
>>> si le bassin n'est pas dans le bâtiment, il faut selon moi 2 objets.
>> 
>> Ce n'est pas rare du tout :-) il y en a des centaines, si je l'ai dit c'est 
>> que j'avais regardé avant.
>> Je ne suis pas passé devant ;-) j'ai regardé ici 
>> https://overpass-turbo.eu/s/CMB  
>> Les contributeurs ont assez largement utilisé cette façon pour mapper les 
>> piscines-bâtiments (bâtiments qui contiennent une piscine). 
>> C'est effectivement une interprétation erronée, mais certainement pas de 
>> moi, des contributeurs plutôt 
>> qui auraient dû mapper ça comme ça : "leisure=sports_centre" + 
>> "sport=swimming"
>> Ce que je voulais dire par => on a souvent le cas : "leisure=sports_centre" 
>> + "sport=swimming" = "leisure=swimming_pool" + "building=yes"
>> 
>>> Salut,
>>> 
>>> Du coup, je pense qu'on peut imaginer un plan d'action comme ça :
>>> - modification massive de amenity=swimming_pool vers 
>>> leisure=swimming_pool comme proposé par Marc
>>> - analyse Osmose qui vérifie la taille des leisure=swimming_pool et 
>>> remonte un signalement quand c'est vraiment trop grand (en utilisant la 
>>> formule de Jérôme)
>>> - mission maproulette pour identifier des leisure=swimming_pool qui 
>>> devraient en fait être des leisure=sports_centre
>>> 
>>> Pour le dernier point, j'ai l'impression qu'en cherchant les 
>>> leisure=swimming_pool qui ont un tag name, on tombe principalement sur 
>>> des éléments mal taggés qui devraient être des sports_centre, on doit 
>>> pouvoir broder autour de ça pour Maproulette, même si on aura quelques 
>>> faux positifs.
>> Oui, dans les trois cas ci-dessus on peut en trouver beaucoup déjà avec 
>> "leisure=swimming_pool" + "building=yes"
>> 
>>> 
>>> Qu'en 

Re: [OSM-talk] talk Digest, Vol 170, Issue 22

[Oleksiy Muzalyev]

Dear St Niklaas,

Indeed, this message looked like an ad, though it was not. I have no 
affiliation to the DJI company whatsoever.


Rather I wanted to share the news that the RTK, real time kinematic, 
technology [1] becomes available via major producers. We know that in a 
city the GPS precision is not very great, only up to 15 - 20 meters. The 
RTK GPS, however, provides up to centimeter-level accuracy, both 
horizontally and even vertically(!).


A map created with this technology could revolutionize quite a few 
industries. For example the agriculture [2], internet sales & delivery, 
etc. Basically, the roads, paths, alleys, etc. on the map could be 
precise enough to be used by a slow-moving robotized vehicles without 
constant LIDAR laser scanning.


The purpose of my message was to share this news, I am sorry if it was 
understood as an ad.


[1] https://en.wikipedia.org/wiki/Real-time_kinematic
[2] https://youtu.be/2WO-1E3WJdE

Best regards,
Oleksiy

On 18.10.18 16:29, St Niklaas wrote:


What the  how did this message came through to the Talk list ?

It looks like an ad to me or is it my mistake ?


Greetz




*Van:* talk-requ...@openstreetmap.org 
*Verzonden:* donderdag 18 oktober 2018 14:00
*Aan:* talk@openstreetmap.org
*Onderwerp:* talk Digest, Vol 170, Issue 22
Send talk mailing list submissions to
    talk@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk 

talk Info Page - lists.openstreetmap.org Mailing Lists 


lists.openstreetmap.org
To see the collection of prior postings to the list, visit the talk 
Archives.. Using talk: To post a message to all the list members, send 
email to talk@openstreetmap.org. You can subscribe to the list, or 
change your existing subscription, in the sections below.



or, via email, send a message with subject or body 'help' to
    talk-requ...@openstreetmap.org

You can reach the person managing the list at
    talk-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of talk digest..."


Today's Topics:

   1. Phantom 4 RTK launched roday: DJI’s Ultimate Mapping
  Solution (oleksiy.muzal...@bluewin.ch)


--

Message: 1
Date: Wed, 17 Oct 2018 17:13:12 +0200
From: "oleksiy.muzal...@bluewin.ch" 
To: talk 
Subject: [OSM-talk] Phantom 4 RTK launched roday: DJI’s Ultimate
    Mapping Solution
Message-ID:
<-a729umlwlno2-aygy9og8ns5j-zhosakv8kafb9w6pbm-68mcx0-x8vdx6640bzx-rn6o21o37g1le47vfh-16d1oo-5crvr2-9tppz1-ehhm05cn5inqq7mcme-ued5iaau4r1n-wkskmsoxttr2-82mob.1539789025...@email.android.com>

Content-Type: text/plain; charset=utf-8

For your information:

https://dronelife.com/2018/10/15/phantom-4-rtk-launched-globally-today-djis-ultimate-mapping-solution/
Best regards
Oleksiy

Sent from my Huawei Mobile

--

Subject: Digest Footer

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


--

End of talk Digest, Vol 170, Issue 22
*


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



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

Re: [OSM-talk-fr] Osmose - École non intégrée

[Christian Quest]

J'ai rencontré il y a peu la personne qui s'occupe de maintenir la première
base (établissements du 1er et 2nd degré) et on n'a absolument pas parlé du
reste qui doit être hors de son périmètre.

Donc, le plus probable c'est que chaque base est gérée séparément, pas
différents services, et que le site que tu indiques à la fin agrège tout ça
pour permettre une recherche.


Le jeu. 18 oct. 2018 à 19:33, deuzeffe  a écrit :

> On 10/18/18 9:56 AM, Christian Quest wrote:
> > Ces mentions sont normales (même si elles datent un peu) et
> correspondent à
> > la Licence Ouverte, c'est donc tout à fait réutilisable pour OSM.
>
> Merci pour la confirmation :)
>
> > Qu'est-ce qui est ventilé façon puzzle sur data.gouv ? Des liens seraient
> > utiles...
>
> Les bases "enseignement" qu'osmose utilise pour l'OD. Par exemple :
> - producteur MEN :
> -- enseignement primaire (écoles maternelles et élémentaire), ici :
>
> https://www.data.gouv.fr/fr/datasets/adresse-et-geolocalisation-des-etablissements-denseignement-du-premier-et-second-degres/
> -- enseignement secondaire (collèges et lycées) : même base
>
> Jusque là, tout va bien.
>
> - producteur : ONISEP
> -- Enseignement supérieur : "établissements" (entre quote parce qu'il y
> manque les établissements au sens administratif du terme, voir le
> descriptif du jeu de données) :
>
> https://www.data.gouv.fr/fr/datasets/etablissements-denseignement-superieur-2
> ()
>
> Ce que n'utilise pas osmose :
> - source MESRI
> -- les rectorats :
>
> https://www.data.gouv.fr/fr/datasets/les-rectorats-dacademies-et-vice-rectorats/
>
> -- les BU (2 jeux) :
>
> https://www.data.gouv.fr/fr/datasets/bibliotheques-de-lenseignement-superieur/
> et
>
> https://www.data.gouv.fr/fr/datasets/services-de-documentation-et-sieges-des-bibliotheques-de-lenseignement-superieur/
> -- les implantations des établissement publics d'ens. sup. avec les UFR
> (entre autres) :
>
> https://www.data.gouv.fr/fr/datasets/implantations-des-etablissements-denseignement-superieur-publics/
> -- les principaux établissements d'ens. sup. :
>
> https://www.data.gouv.fr/fr/datasets/principaux-etablissements-denseignement-superieur/
>
> Et plein d'autres bases que je n'ai pas eu le temps de chercher.
>
> Cependant, une rapide recherche sur acce
> (http://www.education.gouv.fr/acce_public/index.php ) montre que tout ça
> y est déjà plus plein d'autres services/établissements/UA du domaine
> éducation. Soit il n'y a qu'une seule base, soit une métabase, soit...
>
> Bref, dommage qu'on ne puisse pas intégrer (intégrer, j'ai dit !) plus
> de choses plus finement par manque d'interopérabilité (?). Même s'il
> faut de la découpe pour les fines analyses réalisées par osmose.
>
> --
> deuzeffe, archiviste ou bibliothécaire, suivant les heures.
>
> ___
> 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

[OSM-talk-fr] Voting Default Language Format

[rainerU]

Bonjour,

Je me pose des questions sur l'impact de cette proposition sur les objets qui 
ont un nom officiel en langue régionale :


https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format

Si j'ai bien compris la proposition, on mettrait default:language=fr sur la 
frontière de la France (ou des régions, départements,...) et les applications 
utiliseraient name=fr comme nom standard.


A mon avis, cela pose un problème dans les cas où le nom officiel d'un objet est 
en langue régionale mais existe aussi un nom en français. Il y a eu un fil de 
discussion sur cette liste sur la manière de tagguer ces cas avec le schéma 
actuel mais il n'y a pas eu de consensus, à mon avis. Moi, je taggue name=officiel>, name:ca=, name:fr=. Avec le schéma 
proposé, un rendu en langue standard afficherait le nom français et pas le nom 
officiel en catalan. Si par contre on mettait name:fr=, on ne 
pourrait plus créer un rendu 100% français.


Est-ce que cette question a déjà été discuté ici ou ailleurs, si oui quelle 
était la conclusion ?




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

Re: [talk-au] PSMA Administrative Boundaries

[Andrew Harvey]

Is there a problem with crossing ways? Why do they need a shared node when
they are different admin levels?

On Fri., 19 Oct. 2018, 5:56 pm Joel H.,  wrote:

> Just took a look at the crossing boarders without ways error, and it
> seems some level 10 boundaries are indeed overlaping. Check out
> -22.5639465 147.0726169 in Queensland.
>
> As for way too long, I also don't think that needs fixing, just some
> automated JOSM warning not taking context into consideration.
>
> On 18/10/18 12:30 pm, Andrew Harvey wrote:
> > I tried to find out more about two JOSM warnings but I couldn't.
> >
> > 1. Way segment too long
> >
> > What's wrong with long way segments? I'm not convinced we should add
> > nodes where they aren't necessary for detail.
> >
> > 2. Crossing borders without a shared way.
> >
> > This should only happen when you have an LGA boundary crossing a
> > Suburb/Locality boundary, do we need a shared node between these?
> >
> >> I can see your point about not wanting to upload ways and nodes that
> just going to be deleted immediately after. However if we don't then it's
> going to make my idea for QA harder.
> > Could we delay that QA step until after these have been manually fixed
> > up to use the existing state borders?
> >
> >> I'd assumed that we'd be uploading valid multi-polygons which means
> that we could use Overpass and the JOSM validator for QA. I guess we might
> be able to come up with another approach but I'm not sure it's worth the
> effort just to avoid adding and removing a few tens of thousands of nodes
> in comparison to the size of the import.
> > I was leaning this way to avoid this import dumping duplicates on top
> > of existing mappers work on the state boundaries.
> >
> >
> > On Thu, 18 Oct 2018 at 12:46, Andrew Davidson 
> wrote:
> >> On Wed, Oct 17, 2018 at 6:29 PM Andrew Harvey 
> wrote:
> >>>
> >>> So I guess at this point do people want to checkout the simplified OSM
> >>> files for any issues?
> >>>
> >> They look OK, but I would like to have an opportunity to clean up the
> JOSM warnings before we upload them (except the relations with the same
> members warning as these are real).
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Changesets étranges

[Jean-Christophe Becquet]

Le 19/10/2018 08:48, Antoine Riche a écrit :
> Le 19/10/2018 à 07:25, Jean-Christophe Becquet a écrit :
>> Y a t-il un moyen de retrouver les changesets sur lesquels j'ai laissé
>> un message ?
> 
> Le site https://hdyc.neis-one.org/ de Pascal Neis inclut une rubrique
> "Changeset discussions", avec un lien qui liste les commentaires créés.

Merci Antoine !

Il s'agissait donc du changeset suivant, commentaire resté sans réponse
https://www.openstreetmap.org/changeset/55099941

JCB
-- 
Debian GNU-Linux
http://www.apitux.org/index.php?2006/07/10/15-debian-gnu-linux

==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: [talk-au] PSMA Administrative Boundaries

[Joel H.]

Just took a look at the crossing boarders without ways error, and it
seems some level 10 boundaries are indeed overlaping. Check out
-22.5639465 147.0726169 in Queensland.

As for way too long, I also don't think that needs fixing, just some
automated JOSM warning not taking context into consideration.

On 18/10/18 12:30 pm, Andrew Harvey wrote:
> I tried to find out more about two JOSM warnings but I couldn't.
>
> 1. Way segment too long
>
> What's wrong with long way segments? I'm not convinced we should add
> nodes where they aren't necessary for detail.
>
> 2. Crossing borders without a shared way.
>
> This should only happen when you have an LGA boundary crossing a
> Suburb/Locality boundary, do we need a shared node between these?
>
>> I can see your point about not wanting to upload ways and nodes that just 
>> going to be deleted immediately after. However if we don't then it's going 
>> to make my idea for QA harder.
> Could we delay that QA step until after these have been manually fixed
> up to use the existing state borders?
>
>> I'd assumed that we'd be uploading valid multi-polygons which means that we 
>> could use Overpass and the JOSM validator for QA. I guess we might be able 
>> to come up with another approach but I'm not sure it's worth the effort just 
>> to avoid adding and removing a few tens of thousands of nodes in comparison 
>> to the size of the import.
> I was leaning this way to avoid this import dumping duplicates on top
> of existing mappers work on the state boundaries.
>
>
> On Thu, 18 Oct 2018 at 12:46, Andrew Davidson  wrote:
>> On Wed, Oct 17, 2018 at 6:29 PM Andrew Harvey  
>> wrote:
>>>
>>> So I guess at this point do people want to checkout the simplified OSM
>>> files for any issues?
>>>
>> They look OK, but I would like to have an opportunity to clean up the JOSM 
>> warnings before we upload them (except the relations with the same members 
>> warning as these are real).
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [Talk-cz] ŘSD - ploty - odpověď

[Michal Poupa]

Je někde ta judikatura? Potřebuji něco od ŘLP a měli podobný postoj

  Michal


19. 10. 2018 v 7:26, Honza Cibulka :

> Bohužel, judikatura už dovodila, že je to obcházení zákona (stejně jako kdyby 
> o to samý teď požádal někdo jinej) a že ty peníze můžou účtovat, dokud to 
> jednou někdo nezaplatí ;)
> 
> Jan Cibulka
>  
> tel. 776 307 158
> http://datastory.cz
> 
>> On 18 Oct 2018, at 23:22, Pavel Machek  wrote:
>> 
>> AhoJ!
>> 
>>> To je zajímavý: Oni píšou, že už ty informace dohledali a teď chtějí
>>> úhradu, což je zjevně lež - pokud by to opravdu tak náročný bylo,
>>> řekli by si o peníze předem. Takhle riskujou, že žadatel nezaplatí a
>>> těch 600+ hodin práce spadne pod stůl.
>> 
>> No, ono to je jeste zajimavejsi. V prvnim odstavci pisou ze zadatel je
>> povinen do 60ti dnu uhradit.
>> 
>> Na konci pisou ze data dostane jen kdyz uhradi. Hmm.
>> 
>> Co takhle pockat 60 dni, a pak si o data rict znova? Pak uz se nebudou
>> moct vymlouvat ze to hledaj ;-).
>>Pavel
>> -- 
>> (english) http://www.livejournal.com/~pavelmachek
>> (cesky, pictures) 
>> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-fr] Changesets étranges

[Antoine Riche]

Le 19/10/2018 à 07:25, Jean-Christophe Becquet a écrit :

Y a t-il un moyen de retrouver les changesets sur lesquels j'ai laissé
un message ?


Le site https://hdyc.neis-one.org/ de Pascal Neis inclut une rubrique 
"Changeset discussions", avec un lien qui liste les commentaires créés.


Antoine.


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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Paul Desgranges]

Oui, une façon de tagguer ces piscines tournesols ou à toits 
rétractables (qui sont ni location=indoor et ni location=outdoor) est en 
plus nécessaire, mais
 ceci ne doit pas nous empêcher de mapper la très grande majorité de 
piscines qui sont soit des piscines indoor, soit des piscines outdoor ...


Il faut voir si on arrive à se mettre d'accord sur le sens de "covered" 
pour les piscines ?
La proposition serait de réserver l'attribut "covered" aux bassins de 
piscines, et de lui faire signifier la présence ou pas d'un abri-piscine:
 c'est à dire qu'on réserverait ça aux piscines-bassins 
(leisure=swimming_pool),
  et donc que ça n'aurait pas lieu d'être sur les piscines-bâtiments 
(leisure=sports_centre + sport=swimming)

Dans cette logique, il faudrait transformer :
    les "leisure=sports_centre + sport=swimming + covered=yes" 
 en "leisure=sports_centre + 
sport=swimming + location=indoor"
et les "leisure=sports_centre + sport=swimming + covered=no" 
  en "leisure=sports_centre + 
sport=swimming + location=outdoor"



Mais ceci serait à faire après la transformation (discutée par Noémie, 
Marc, Jérôme, ...) qui consisterait à transformer les 
"amenity=swimming_pool" soit en "leisure=sports_centre + 
sport=swimming", soit en "leisure=swimming_pool" suivant quelques 
heuristiques, voir l'autre fil de discussion ...


Paul


Le 16/10/2018 à 13:50, Philippe Verdy a écrit :
C'est un modèle assez courant de piscine fermé à toit mobile. J'en 
avais déjà parlé avant


Le mar. 16 oct. 2018 à 09:35, Christian Quest > a écrit :


Désolé, je vais casser l'ambiance en sortant ma "piscine tournesol":


https://2.bp.blogspot.com/-mhCVrMV3K-8/UX2VXYXJUgI/A0g/fwvAWxZV4rI/s1600/Nangis_2.jpg

;)


Le mar. 16 oct. 2018 à 09:17, Paul Desgranges
mailto:desgranges.p...@laposte.net>>
a écrit :

Là-aussi je me suis mal fait comprendre peut-être alors je
vais essayer de faire mieux (puisqu'on est dans les piscines
)

A propos de indoor/outdoor et covered=yes/no, il y a aussi
plusieurs façons de faire actuellement. En tout cas si on
parle de "leisure=swimming_pool" (donc pour les piscines de
type "bassin")
    1. le bassin peut être à l'intérieur ou à l'extérieur, pas
trop de confusion possible
    - bassin intérieur => "location=indoor" : pas visible par
photo aérienne, on est dans un bâtiment, c'est du mapping
indoor, (mais il y en a des mappés comme ça )
    - bassin extérieur => "location=outdoor" : visible par
photo aérienne, ça pourrait être la valeur par défaut, mais
c'est plus explicite qd ça y est

   2. le bassin peut être "couvert" ou pas. De manière
générale, en dehors d'OSM, quand on dit "bassin couvert" on
veut dire "bassin intérieur" et "bassin découvert" on veut
dire bassin extérieur, donc il y a une confusion possible et
on peut la constater dans les faits.
    Actuellement "covered=yes" a été employé manifestement
dans différents cas :
    - Soit le contributeur a voulu signifier que la piscine
était "couverte" au sens bassin intérieur
    - Soit le contributeur a voulu signifier que la piscine
était "couverte" au sens la piscine dispose d'un "abri
piscine" (on distingue bien ces abris en photographie
aérienne), les piscines privées dans les jardins, avec un abri
pour : sécurité chute, déperdition d'énergie, feuilles mortes,
etc.
    Et "covered=no" est assez employé, mais dans quelle
intention a été utilisé ce tag, s'agit-il d'un bassin
extérieur, ou s'agit-il d'un bassin ne disposant pas d'abri ?
Pas forcément clair.

  Alors comment documenter ces 2 attributs
("location=indoor/outdoor" et "covered=yes/no") pour que
l'usage en soit clair ?

Bonne journée
Paul


-- 
Christian Quest - OpenStreetMap France

___
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] Piscine municipale vs piscine privée

[Paul Desgranges]

Bonjour,
Je n'avais peut-être pas compris le sens du mail de Noémie, et je 
cherche ci-dessous à le ré-exprimer, voir si on est d'accord :


L'idée principale consiste à transformer les "amenity=swimming_pool"
    soit en "leisure=sports_centre + sport=swimming",
    soit en "leisure=swimming_pool"

Et ceci suivant les heuristiques suivantes :

1) Par exemple on peut transformer
    les "amenity=swimming_pool + name=*" 
 en "leisure=sports_centre + 
sport=swimming"
et les "amenity=swimming_pool + name!=*" 
 en "leisure=swimming_pool"
car effectivement quand il y a un nom, c'est un "sports_centre" et quand 
il n'y a pas de nom, c'est un simple bassin.


2) Autre exemple on peut transformer
    les "amenity=swimming_pool + building=yes" 
 en "leisure=sports_centre + 
sport=swimming + building=yes"
car quand il y a aussi un building, c'est un "sports_centre". A noter 
que 1) et 2) vont se recouvrir en partie.


3) Il y a des heuristiques sur la taille aussi comme disait Jérôme:
 Quand c'est "petit", c'est plutôt un bassin.
 Quand c'est "grand", c'est plutôt  un sports_centre
Mais là, a-t-on la possibilité de faire une requête overpass turbo pour 
les sélectionner sur ce critère de taille?



D'autre part, si les "amenity=swimming_pool" sont à éliminer, on peut 
aussi transformer :
    les "leisure=swimming_pool + building=yes" 
 en "leisure=sports_centre + 
sport=swimming + building=yes"
 car les piscines qui sont aussi des buildings sont en fait des 
"sports_centre". Les contributeurs ont taggué par erreur en "bassin" ce 
qui plutôt des "sports_centre".



Et les transformations ci-dessus seraient à faire avant de faire celles 
relatives à "covered" (et qui qui sont discutées dans l'autre mail ?)


Voilà, y-a-t-il des erreurs ? Est-ce plus clair ?

Paul




Le 15/10/2018 à 23:04, Paul Desgranges a écrit :

Bonsoir,

>Le 14. 10. 18 à 22:12, Paul Desgranges a écrit :
>>/Un truc en plus, le terme 'piscine' de manière générale peut signifier à />>/la fois le bassin, le bâtiment, mais aussi le 
complexe sportif : />>/ - "leisure=swimming_pool" seul, donc ça serait le bassin, mais 
/>>/"leisure=swimming_pool" + "building=yes" là on parlerait du 'bâtiment />>/piscine'  (le bassin est alors 
parfois à l'extérieur) />
>cette interprétation me semble erronée.
>leisure=swimming_pool est selon moi clairement définit comme étant le bassin.
>"leisure=swimming_pool" + "building=yes c'est donc un bassin "couvert" 
>par un bâtiment. c'est assez rare mais j'en connais un : je suis passé 
>plusieurs fois devant en me demandant si c'était un garage entière vitré 
>ou une serre en dur... avant d'un jour apercevoir que l'intérieur est 
>entièrement constitué d'un bassin d'eau (piscine privé).

> si le bassin n'est pas dans le bâtiment, il faut selon moi 2 objets.

Ce n'est pas rare du tout :-) il y en a des centaines, si je l'ai dit c'est que 
j'avais regardé avant.
Je ne suis pas passé devant ;-) j'ai regardé icihttps://overpass-turbo.eu/s/CMB   
Les contributeurs ont assez largement utilisé cette façon pour mapper les piscines-bâtiments (bâtiments qui contiennent une piscine).

C'est effectivement une interprétation erronée, mais certainement pas de moi, 
des contributeurs plutôt
qui auraient dû mapper ça comme ça : "leisure=sports_centre" + "sport=swimming"
Ce que je voulais dire par => on a souvent le cas : "leisure=sports_centre" + "sport=swimming" = 
"leisure=swimming_pool" + "building=yes"


>Salut,
>
>Du coup, je pense qu'on peut imaginer un plan d'action comme ça :
>- modification massive de amenity=swimming_pool vers 
> leisure=swimming_pool comme proposé par Marc
>- analyse Osmose qui vérifie la taille des leisure=swimming_pool et 
>remonte un signalement quand c'est vraiment trop grand (en utilisant la 
>formule de Jérôme)
>- mission maproulette pour identifier des leisure=swimming_pool qui 
>devraient en fait être des leisure=sports_centre

>
>Pour le dernier point, j'ai l'impression qu'en cherchant les 
>leisure=swimming_pool qui ont un tag name, on tombe principalement sur 
>des éléments mal taggés qui devraient être des sports_centre, on doit 
>pouvoir broder autour de ça pour Maproulette, même si on aura quelques 
>faux positifs.

Oui, dans les trois cas ci-dessus on peut en trouver beaucoup déjà avec 
"leisure=swimming_pool" + "building=yes"

>
>Qu'en dites-vous ?

Bien d'accord !
  
  --

Noémie Lehuby
Donc l'idée




___
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