Re: [OSM-ja] 日本の「Acces / 交通手段による制限 - 陸上交通 車両種別アクセス」について

[yuu hayashi]

hayashiです

muramotoさまの (1)(2)(3)(4)はどれもとても有意義なご指摘だと思います。

(1)(2)でKeyのネーミングについてのご提案がありました。

私の原案と比較しても甲乙つけがたいと思います。
実際の現在の例に挙げている以上に複雑な実例が報告されなければ シンプルなmuramoto案のほうが優れていると思います。

どちらの案を採用するかの判断材料として 私の原案について説明させていただきます。

わたしの提案方式では OSM標準と日本ローカルとを完全に分離させることを主眼においた方式です。
日本固有の事情はすべて`transportation_mode=*`に封じ込めました。
既存のOSMタグには一切手を加えていません。
このことによって、マッパーにたいして OSM標準に準拠した入力を強いています。
どうしても正確に入力できないような日本固有の事情だけは`transportation_mode=*`に入力します。
`transportation_mode:xxx=*`は「コメント」みたいなものです。

日本の事情を知らないアプリは、`transportation_mode`を無視しますが、日本のマッパーは`transportation_mode`以外のOSMタグに、世界標準に従って入力しているので
アプリは日本固有の事情を勘案する必要はありません。
日本の事情をより正確に読み取りたいアプリだけが `transportation_mode:xxx=*` を読み取ることでより詳細な情報を得られます。

# `transportation_mode`という名前

つぎに,`transportation_mode`という長ったらしい名前についてですが、

* まず、`transportation_mode`という名前は現在のところ使われていません。（`transportation`は使われている）
* `transportation_mode`とは何？ と OSM wiki
を検索すると、このタグと密接に関係ある「JA:条件付き制限」に行きつきます。
* また、タグ`transportation_mode`は、`Tag access`よりも`JA:条件付き制限`により強く依存しています。

だから、`transportation_mode`にしました。

`motorcar:transportation_mode=*` は、既存の`Tag
access:motorcar`の拡張タグになるので、OSM標準の拡張になります。
(だから悪いということではなく、むしろOSM標準を拡張する方が王道かもしれません)

[JA:条件付き制限](
https://wiki.openstreetmap.org/wiki/JA:%E6%9D%A1%E4%BB%B6%E4%BB%98%E3%81%8D%E5%88%B6%E9%99%90
)


## [transportation_mode]から「:xxx」をとる

muramotoさんの提案(1)にインスパイアされました。

 transportation_mode:jp =  @ <定義>[; @ <定義>]

  例）`transportation_mode:jp = motorcar @ 大型`

とする案が浮かびました。利点は

* 提案するタグが「transportation_mode:jp」だけで済む（従来は motorcar,goods,hgv,bus の４つ）
* Value側の書式を[JA:条件付き制限]と同一にできる
* [motorcar,goods,hgv,bus]の種類にとらわれない柔軟な記述が可能になる（汎用性）


# 「transportation_mode」に「:jp」をつけるか否か

[transportation_mode]を日本だけのローカルルールではなく、OSMのローカライズ手法として標準化するなら「:jp」をつける方がいいと思います。
（「:jp」がなくとも標準化できるような気がしますが、あった方が扱いやすい）

ただし、私の語学力では無理なので 逃げてました。

現在のところ日本には存在していないと思いますが。
例えば、国際ライセンス運転者向けの交通標識が併設されていた場合に[:ja/:na]が役に立つかもしれません。


# その他

このほかにも、vehicle,`motor_vehicle`,`motorcar`+`motorcycle`,`(motorcar AND (NOT
goods))`についての意見をいただいてますが
それに関しては別途投稿いたします。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] 日本の「Acces / 交通手段による制限 - 陸上交通 車両種別アクセス」について

[yuu hayashi]

muramotoさま、石野さま レスありがとうございます。

お二方共通のJapanTaggingのImpliesの件について私の意見を述べます。
（muramoto様の他のご意見については別途返信します）

前回の投稿では「JapanTaggingが間違っている」と決めつけましたが、現状では'間違い’と論理的に断定することはできません。

もし、JapanTaggingを改定しようとするなら、改定案を提出することになりますが

   どのような改定案を提出しますか？

前回の投稿では、「小二輪」を`moped`としていますが、

 * `moped` → 「原付」じゃないの？

というような議論が先に必要になるのではないでしょうか？

ほかにも

* `motorcar`って、日本でいうところの何よ？
* `motorcycle`って、日本でいうところの何よ？「二輪」？、「自二輪」？
* 「大型トラック」は`motorcar`に含まれるのか？
など

こっちを先に決めないと、JapanTaggingのImpliesが 間違っているのか どうかすら判断できないと思います。

私は今回の提案で、これらの車両区分を明確に定義したから、 「JapanTaggingを訂正した方がいい」という結論になりますが、
この提案が否決されれば、 JapanTaggingを訂正する根拠もなくなります。

なので、access:* の日本での定義を確定させるのが先だと考えています。
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[Talk-br] Cedência dos dados de cartografia da IPPUC de Curitiba / Importação de numeração predial

[santamariense]

Olá pessoal,

Conseguiu-se autorização formal do Instituto de Pesquisa e
Planejamento Urbano de Curitiba quanto a cedência dos dados de
cartografia para o OSM disponibilizados em
http://ippuc.org.br/geodownloads/geo.htm e a declaração está
disponível em 
https://wiki.openstreetmap.org/wiki/File:Declara%C3%A7%C3%A3o_de_Ced%C3%AAncia_de_dados_IPPUC.pdf

Gostaria que analisassem a declaração e dessem um feedback, caso
alguém discorde que sim, está suficientemente claro que os dados podem
ser importados para o OSM.

A ideia principal, e para isso estou sendo incumbido, é importar a
numeração predial da cidade que está disponível em "Lotes -
(julho/2018)". Não é disponível o shapefile de prédios, mas sim dos
lotes. A proposta é transformar a área do lote em ponto no centroide
do seu respectivo lote, e realocar cada um dos pontos gerados para a
proximidade da rua onde o endereço está localizado, ou seja, dentro do
prédio, porém, mais próximo de onde provavelmente esteja a porta de
entrada dele.

Conforme as boas práticas, será mantido o histórico dos endereços já
mapeados no OSM, inclusive suas coordenadas, sem haver duplicação de
objetos na base de dados do OSM.

A documentação está sendo feita em
https://wiki.openstreetmap.org/wiki/Curitiba/Importa%C3%A7%C3%A3o_IPPUC

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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Santiago Higuera]

Lo siento, yopaseopor, no me convencen tus argumentos, me sigue
pareciendo mejor el procedimiento actual para clasificar las carreteras
que el que tú propones.

El vie, 26-10-2018 a las 21:05 +0200, yo paseopor escribió:
> > ¿De verdad? ¿Qué ruteadores son esos? ¿No sería más fácil que esos
> > ruteadores se pusieran la día con los criterios que utilizan?
> > ¡Menuda
> > patata de ruteador, si no utiliza la cantidad de etiquetas que hay
> > en
> > la base de datos!
> Te soy sincero, conocimientos técnicos en esta materia no tengo por
> desgracia pero creo que la primera etiqueta que tienen en cuenta la
> gran mayoría de los es la categoría de highway, pero dicho esto, dado
> que los ruteadores tienen en cuenta muchos parámetros, no importará
> que categoría ya no esté asignado a la administración que la gestiona
> pues para ello ya está la primera letra de reference y la etiqueta
> operator, que estoy seguro que esos ruteadores tan avanzados pueden
> tener en cuenta si es lo que buscamos
> > 
> > Pues no lo parece
> En qué te basas para decir que me muevo por los colores: me muevo por
> las categorías, porque estas estén bien usadas, porque una trunk sea
> una vía principal y no el simple ramal de una autovía que a veces la
> parte en dos sin solución de continuidad. Porque cuando yo veo trunk
> pienso en una vía que me va a dar seguridad, que me va a dar tráfico,
> que me va a permitir una conducción agradable , sin sobresaltos, con
> preferencia. Y hay muchas de esas nacionales que , desde que tienen
> autovías a su alrededor ya no cumplen con esos parámetros. 
> > 
> > ¿Por qué consideras que han dejado de ser 'principales'? ¿Cuál
> > consideras que debe ser es el criterio para considerar que una
> > carretera es 'principal'? ¿La IMD? 
> ¿La intensidad de uso de una vía te parece mal baremo para saber si
> una vía es "principal" o no?
> ¿La velocidad media y su fluidez te parecen mal baremo para saber si
> una vía es "principal" o no?
> ¿El hecho de ser una vía segura, sin sobresaltos, con una conducción
> cómoda, con cruces internivel, etc. te parece mal baremo para saber
> si una vía es "principal" o no?
> ¿El hecho de que una vía pertenezca a Fomento te parece el único
> parámetro válido para considerar si una vía es principal?
> > Sí, noto cierta animadversión con las vías de gestión estatal 
> Yo no tengo nada en contra de Fomento en particular y mucho menos en
> contra del estado en general, lo tengo en contra del criterio de esta
> comunidad de no replantearse la mejora de un etiquetado más ajustado
> a la realidad práctica - la mayoría de usuarios no miramos quien
> gestiona una vía a no ser que eso implique un pago por uso inmediato
> - en las vías de un solo carril por sentido por el simple hecho de
> pertenecer a una administración determinada, que en este caso
> concreto es Fomento (lo cual se traduce en carretera nacional). 
> De hecho muchas autovías pertenecen a Fomento y no tengo nada en
> contra de ellas ni he hecho tal manifestación. Y lo mismo valdría
> para cualquier administración, pero se da el caso de que ese proceso
> con esas otras administraciones ya lo hemos ido haciendo, el ejemplo
> combinado de Ávila-Salamanca vs. Leganés-Móstoles lo dejó bastante
> claro.
> Por poner un ejemplo que refuerza esta idea, la comunidad OSM en
> Catalunya, no considera que todas las vías consideradas por la
> Generalitat de Catalunya como principales deben de ser trunk,
> primary, secondary o tertiary y su categoría va variando en función
> de esos otros parámetros de los que aquí propongo para Fomento. Eso
> no genera errores de rutaje ni ningún problema o dificultad para el
> usuario, simplemente acaba dando , de forma muy visual la mejor
> opción para un recorrido determinado. Equivocarse escogiendo un
> recorrido "más corto" puede convertirse en 30 minutos más de viaje.
> 
> Saludos
> yopaseopor
> ___
> 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-us] New United States Bicycle Routes!

[Kerry Irons]

Yes,

It's the Kentucky Transportation Cabinet.  Apparently all state "departments" 
are officially called "cabinets."  Took me at least 2 years to get used to KYTC 
instead of KYDOT.


Kerry

-Original Message-
From: OSM Volunteer stevea  
Sent: Friday, October 26, 2018 7:01 PM
To: Kerry Irons ; Greg Morgan 
; talk-us 
Subject: Re: [Talk-us] New United States Bicycle Routes!

Sorry, I should use the abbreviation of KYTC as Kerry does, not KDOT.
SteveA


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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

Sorry, I should use the abbreviation of KYTC as Kerry does, not KDOT.
SteveA

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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

"Having little confidence that KDOT got it right, either" is exactly why I 
didn't change the names:  let the locals (cities, counties, local 
residents/citizens) hash this out as well as KDOT, if KDOT wants to get 
involved.  For whatever reason, I've only seen these serious differences of 
this magnitude in the state of Kentucky, lest the greater-in-US OSM community 
suddenly panic that TIGER needs a major boost in fixing.  (I mean, let's STAY 
busy cleaning up TIGER, but let's not panic that it is especially bad).

OK, TIGER data are "only fair to poor" in Kentucky.  I will say that.  I'm not 
laying blame or pointing fingers, simply observing that entering route data 
from a state DOT was frequently perplexing given the need to match highway 
infrastructure of current TIGER data there.

SteveA
California

> On Oct 26, 2018, at 3:48 PM, Kerry Irons  wrote:
> 
> We had the same experience in creating a RideWithGPS map and route log for 
> USBR 21 in KY.  There are even places where a given road has two different 
> spellings; you can tell it's the same road but the name spelling apparently 
> is not agreed by the locals.  You learn to live with it.  While you would 
> think that the KYTC names would be definitive, I have little confidence that 
> that is true.
> 
> 
> Kerry

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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Jorge Sanz Sanfructuoso]

El vie., 26 oct. 2018 a las 23:24, yo paseopor ()
escribió:

>
>> En un mensaje anterior estas hablando desde trunk hasta unclassified. Eso
>> abarca todas las carreteras, no solo las de fomento.
>>
> ¿Ademas porque la de fomento sí y el resto no?
>>
> -Propongo la revisión de las carreteras de plataforma única (1 carril por
> sentido) de Fomento ...porque es la que no se ha realizado aún. Y si falta
> hacer la revisión de las vías de alguna otra administración adelante, animo
> a la comunidad de la zona a que la realice , aunque algo me dice que son
> muchas sino todas las que ya lo habeis hecho.
>
Yo no conozco esas revisiones que comentas en todas las carreteras menos en
las nacionales.

> - Y no, he dicho todas las categorías que puede abarcar una carretera
> perteneciente a Fomento...como pasa con el resto de administraciones.
> Hay nacionales que se han convertido en puras vías de servicio, hay otras
> que hacen de vía local generando tráfico entre dos localidades muy
> próximas. Otras hacen de vía comarcal , otras son útiles para la movilidad
> interna de la provincia, otras hacen de nexo entre provincia y otras no
> tienen por qué variar de categoría puesto que mantienen el tráfico, la
> velocidad media y la seguridad (cruces internivel) y comodidad de una vía
> principal.
> Suele pasar que en muchos casos el tráfico general circula por la
> autovía/autopista o bien por un eje paralelo ,normalmente en mejores
> condiciones, a no mucha distancia.
>
Hay un problema muy claro en esta propuesta y que todavía no esta aclarado
y nunca aclaras y vas cogiendo de un sitio y de otro y no concretas. Tan
pronto hablas de IMD, como de cruces a nivel, velocidad media, cómo algún
otro parámetro. Una propuesta no puede ser una mezcla de todo sin definir
cómo se usa claramente. No digo que no se pueda combinar todo, que puede
que sí. Pero es que no concretas nada. Usa todo ¿cómo dice tu propuesta que
se use todo eso concretamente? de una manera que no lleve a líos y
ambigüedades? ¿Vamos por trocitos de carretera? ¿carreteras completas?
Ya varias cosas de estas te las he comentado pero son cosas que si no se
concretan claramente no se puede usar nada. Eso desde el primer mensaje que
se ha dicho que no es objetivo es el mayor problema y todavía no lo he
visto solucionado.


>> Como ya he comentado no es un dato tan fiable y no he sido el único que
>> lo ha dicho. Se mide en lugares concretos, no es una medida continua de la
>> carretera, porque eso no es fácil de hacer ni barato.
>>
> A juzgar por lo que se ve en el mapa de Fomento, las estaciones son
> variopintas y están situadas por toda la geografía nacional, creo que es
> una medición que , aunque con errores, como todos los sistemas es muy
> válida para esta propuesta
>
>>
>> Yo cuando he usado los datos tampoco me encontrado muchos casos que me
>> lleve por sitios disparatados como esta actualmente los datos. Normalmente
>> son por otro tipo de errores las rutas raras que me encontrado que no
>> tienen nada que ver.
>>
> -Porque en los casos donde la dicotomía entre plataforma única y doble
> plataforma el ruteador lo tiene claro. La autovía prima sobre todo , sea de
> Fomento o no lo sea. Pero eso no quita que se pueda tener en cuenta otros
> baremos para categorizar las carreteras en OSM, en este caso las
> gestionadas por Fomento. OSM es algo más que ruteadores, por ello es
> importante cambiar efectivamente esas categorías en las vías que se estime
> oportuno en base a unos estudios y parámetros complejos pero objetivos.
>
Vale los ruteadores entonces no dan problemas. ¿dónde esta el problema
entonces? Si es solo para que se vea un estudio es añadirlo a una etiqueta
que muestre ese estudio (tampoco es el cometido de OSM creo pero bueno se
podría poner). Si es añadir ancho y otros parámetros que ya tienen
etiquetado no hace falta cambiar nada. Depende de las necesidades ya usaras
esos datos para lo que necesites. Y si necesitas combinarlos puedes crear
un render que los combine. El problema tan grande para cambiar todo no
termino de verlo.


>> Por ahora en estos correos lo que encontrado es una comunidad que no ve
>> el cambio como tú. No veo a la comunidad actualmente en el estado que esta
>> detrás de este cambio.
>>
> -Que la comunidad no lo "vea" no significa que no se pueda intentar
> proponer. Y puestos a ver, de los 28 mensajes emitidos, de momento en este
> debate, escritos por 7 personas he visto en contra 3, a favor 2 y 1 que no
> se opone, así que yo no veo a la comunidad (si es que no interviene más
> gente, tampoco voy a obligar a intervenir a nadie, faltaría más) tan
> alejada del debate ni veo a una posición muy por encima de la otra.
>
Se ha quedado uno descolgado y creo que es otro en contra, que son 4. Claro
que se puede proponer faltaría mas.


> Ya lo he dicho más veces hay muchos flecos y es donde veo el mayor
>> problema. Y es donde esta el lio de ediciones, interpretaciones y lo que
>> ves tan claro en verdad no lo es. No es ni 

Re: [Talk-us] New United States Bicycle Routes!

[Kerry Irons]

We had the same experience in creating a RideWithGPS map and route log for USBR 
21 in KY.  There are even places where a given road has two different 
spellings; you can tell it's the same road but the name spelling apparently is 
not agreed by the locals.  You learn to live with it.  While you would think 
that the KYTC names would be definitive, I have little confidence that that is 
true.


Kerry

-Original Message-
From: OSM Volunteer stevea  
Sent: Friday, October 26, 2018 6:31 PM
To: talk-us 
Cc: Greg Morgan ; Kerry Irons 
Subject: Re: [Talk-us] New United States Bicycle Routes!

I have completed a first draft of USBR 21 in Kentucky.  This was actually quite 
difficult as the TIGER name tags frequently do not match what highway names on 
the application from Kentucky's DOT says.  I did not change these, I'll leave 
that for "locals," but there is a great deal of work to do to change highway 
names in OSM in Kentucky, as it appears that counties, cities and KDOT change 
names (and segment breaks that make them up) quite a lot in the last 11 years 
since TIGER data were entered.

As our wiki says and as is good practice in OSM, Greg's 23 and my 21 data entry 
deserve a "double-check review" by another OSM volunteer, and while these are 
"green" in our wiki, they are a "light green" until this is completed.  Greg, 
if you email me off list and agree to double-check 21, I'll do the same to 23.  
Others are welcome, of course; email one or both of us if you are interested in 
helping.

SteveA
California

> On Oct 26, 2018, at 10:51 AM, OSM Volunteer stevea 
>  wrote:
> 
> Wow, Greg, you are quick.  Thank you!
> 
> Additionally, (a major reason I'm including Kerry in this missive), I removed 
> from OSM segments of Kentucky's USBR 23 which overlapped with ACA's 
> Transamerica Trail (TA) "Mammoth Cave Loop."  (Now largely superseded by 76 
> and 23).  These were between Highland Springs ("mid-state") and further north 
> to Tanner, where 23 now connects to 76 at a T-intersection.  There are many 
> reasons why OSM has been deprecating ACA routes in OSM:  these are 
> proprietary and likely don't belong in OSM first place, and we document in 
> our wiki that "over time, these tend to be replaced by USBRs" (among other 
> reasons, like that they can get old and drift from updates that ACA can make 
> or already has made).  Indeed, once again (as in the case of the northern 
> segment of 76 in Kentucky replacing Mammoth Caves Loop earlier when 76 was 
> approved in Kentucky), this segment of 23 100% overlaps with this ACA route, 
> so yet another significant ACA route segment now deleted from OSM (as it is 
> USBR now).
> 
> Thanks again for your work to enter this, and keep up the great entry I'm 
> guessing you are doing with USBR 21.
> 
> Steve
> 
>> On Oct 26, 2018, at 6:18 AM, Greg Morgan  wrote:
>> 
>> Kentucky USBR 23  is done.  
>> https://www.openstreetmap.org/relation/8843677#map=10/37.4960/-85.4712
> 



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

Re: [Talk-us] New United States Bicycle Routes!

[OSM Volunteer stevea]

I have completed a first draft of USBR 21 in Kentucky.  This was actually quite 
difficult as the TIGER name tags frequently do not match what highway names on 
the application from Kentucky's DOT says.  I did not change these, I'll leave 
that for "locals," but there is a great deal of work to do to change highway 
names in OSM in Kentucky, as it appears that counties, cities and KDOT change 
names (and segment breaks that make them up) quite a lot in the last 11 years 
since TIGER data were entered.

As our wiki says and as is good practice in OSM, Greg's 23 and my 21 data entry 
deserve a "double-check review" by another OSM volunteer, and while these are 
"green" in our wiki, they are a "light green" until this is completed.  Greg, 
if you email me off list and agree to double-check 21, I'll do the same to 23.  
Others are welcome, of course; email one or both of us if you are interested in 
helping.

SteveA
California

> On Oct 26, 2018, at 10:51 AM, OSM Volunteer stevea 
>  wrote:
> 
> Wow, Greg, you are quick.  Thank you!
> 
> Additionally, (a major reason I'm including Kerry in this missive), I removed 
> from OSM segments of Kentucky's USBR 23 which overlapped with ACA's 
> Transamerica Trail (TA) "Mammoth Cave Loop."  (Now largely superseded by 76 
> and 23).  These were between Highland Springs ("mid-state") and further north 
> to Tanner, where 23 now connects to 76 at a T-intersection.  There are many 
> reasons why OSM has been deprecating ACA routes in OSM:  these are 
> proprietary and likely don't belong in OSM first place, and we document in 
> our wiki that "over time, these tend to be replaced by USBRs" (among other 
> reasons, like that they can get old and drift from updates that ACA can make 
> or already has made).  Indeed, once again (as in the case of the northern 
> segment of 76 in Kentucky replacing Mammoth Caves Loop earlier when 76 was 
> approved in Kentucky), this segment of 23 100% overlaps with this ACA route, 
> so yet another significant ACA route segment now deleted from OSM (as it is 
> USBR now).
> 
> Thanks again for your work to enter this, and keep up the great entry I'm 
> guessing you are doing with USBR 21.
> 
> Steve
> 
>> On Oct 26, 2018, at 6:18 AM, Greg Morgan  wrote:
>> 
>> Kentucky USBR 23  is done.  
>> https://www.openstreetmap.org/relation/8843677#map=10/37.4960/-85.4712
> 


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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[Rafael Avila Coya]

Sólo un comentario sobre la hipotética incorporación de IMD's a OSM:

1. Sería una importación de datos. Dudo que fuese bien recibida por la 
comunidad global. A mí no me parece buena idea en principio, entre otras 
razones por la dificultad del mantenimiento.


2. Salvo que mappers se pusiesen a calcular IMD's (lo dudo muchísimo), 
sería un dato sólo recabable de Fomento. Seguir importando.


Saludos,

Rafael.

O 25/10/18 ás 11:28, Santiago Higuera escribiu:

Hola:
La IMD (Intensidad Media Diaria) es un dato muy interesante para que
estuviera en la base de datos. Pero no creo que sea un buen criterio
para clasificar las carreteras, por múltiples motivos:
  - La IMD se asigna por tramos. Dentro de una misma carretera, en
pequeños tramos, puede haber IDM's muy diferentes.
  - La IMD es un valor agregado que recoge una media. Hay carreteras en
las que la intensidad de vehículos que circula varía mucho según el día
de la semana, o según la época del año.
  - En las carreteras que unen localidades próximas a las grandes áreas
metropolitanas, se dan casos de IMD's muy elevadas, pero que no le
quita el carácter local a dichas carreteras. Por poner un ejemplo, la
carretera de Leganés a Móstoles en Madrid, seguramente tiene IMD muy
superior a la carretera Ávila - Salamanca, pero eso no quita para que
la carretera Leganés-Móstoles siga siendo 'secondary' y la carretera
Ávila-Salamanca siga siendo una 'primary'.

En realidad, las IMD's se utilizan para otras cosas. Para estudios de
tráfico origen-destino, para estudiar la conveniencia o no de
determinada variante o desdoblamiento de calzada, etc. Las campañas de
recogida de datos no suelen ser muy uniformes. Periódicamente se hacen
estudios de aforo, pero solo en determinados puntos estratégicos, o
bien en zonas donde se quiere estudiar alguna modificación de la red
existente.

Creo que incorporar a la base de datos la IMD sería fantástico, pero
también creo que sería un trabajo ímprobo y muy difícil de mantener
actualizado. No creo que merezca la pena acometerlo, creo que hay otras
tareas más interesantes para dedicar trabajo en OSM.

Saludos
Santiago Higuera



El mié, 24-10-2018 a las 21:25 +0200, yo paseopor escribió:

Saludos, Santiago te respondo:

1-Acertado o no sí, te puede parecer, eres libre, faltaría más, de
expresar tu opinión ;)
2-Ahora bien "cualquier otro criterio" no hace falta que sea
subjetivo, almenos en la propuesta que he realizado. Repito los
"ejes" de la propuesta:

-Tener en cuenta IMD - Intensidad Media Diaria: son estudios anuales
hechos por Fomento y otras administraciones y entes. No son
subjetivos, los números son los que son y determinan las vías más
usadas,además de forma proporcional, por provincias.
-Tener en cuenta la jerarquía de las vías adyacentes: tienen las
categorías administrativas que tienen, no es opinable.
-Características físicas: dudo que la existencia o no de puentes y
túneles en su trazado sea una cosa subjetiva y que se pueda cambiar a
corto plazo: o se tienen o no se tienen

3- La información administrativa ya está representada por la primera
letra en las referencias, no hace falta sobrerepresentarla
4-Lo que fue subjetivo en su día fue escoger el criterio inglés
(administrativo) y no el alemán (físico) en el momento en que se
consideró en la comunidad española de OSM en su día. Podemos estar de
acuerdo o no, nos pueden gustar más o menos los criterios, se puede
ser todo lo reticente a los cambios que se quiera, pero subjetivo,
con estudios de Fomento y realidades físicas de por medio, poco o
nada.
5-Otra cosa muy subjetiva es el conocimiento local y nadie lo pone en
duda como fuente para mapear.

yopaseopor

On Wed, Oct 24, 2018 at 1:42 AM Santiago Higuera 
wrote:

Hola:
Sigo pensando que mantener criterios administrativos en el
etiquetado
principal de las carreteras es lo más acertado. El resto de
descripciones de las vías se pueden hacer con etiquetas
adicionales,
que pueden usar los programas de routing. La denominación
administrativa y los pk's son el criterio fundamental para poder
identificar sin lugar a error los puntos de las carreteras.
A los niveles administrativos españoles (Estatal, CCAA, Provincial)
hay
que añadir, actualmente, el nivel europeo de las vias E).
Cualquier otro criterio es subjetivo y no me parece acertado.

Es mi opinión.
Un saludo

Santiago Higuera


El mié, 24-10-2018 a las 00:13 +0200, yo paseopor escribió:

Saludos gente:
Os podeis imaginar que si lleva en el título la palabra

"Carreteras"

y viene de mí tendrá como motivo la que considero necesaria
reclasificación de la red de carreteras en nuestro país.
  
El motivo es el siguiente: esa clasificación, con pequeños

retoques,

no se ha modificado en gran parte del territorio por parte de

Fomento

desde hace , sin exagerar,20/30 años (algunas veces se ha

limitado a

cambiar la nomenclatura y poco más, con lo cual tenemos alguna
carretera nacional que tiene la forma de comarcal que tuvo
originariamente, se puede comprobar con los 

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

D'accordo su tutta la linea, ma... ci vedi qualcosa di sbagliato nel mettere 
una "note"?


On 2018-10-26 23:31, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 26. Oct 2018, at 17:09, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> ma la tua stessa frase spiega perché sarebbe opportuno fornire *anche *un 
>> riferimento temporale alla misura: tu dici "/... puoi anche immaginare 5 
>> anni dopo che forse potrebbe essere cresciuto un po’ .../" e io ti chiedo 
>> "/5 anni dopo quando?/"
>
>
> Questo è un tipico problema con gli import: i dati sono sempre più vecchi 
> rispetto al nostro standard. Normalmente la data di caricamento è anche più o 
> meno la data del rilievo, mentre per gli import la data del rilievo è 1-50 
> anni prima del caricamento ;-)
>
> Comunque, una cosa è certa, i dati hanno sempre al minimo l’età del tempo 
> passato dal caricamento.
>
> Sono d’accordo con chi l’ha scritto sopra: i dati dei rilievi sono da 
> inserire nel changeset / wiki linkato dal changeset.
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



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

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

[François Lacombe]

Merci Marc pour la réponse, on est d'accord

Je vais essayer de corriger ca dès que possible

François

Le sam. 20 oct. 2018 à 20:01, marc marc  a
écrit :

> Le 18. 10. 18 à 23:55, François Lacombe a écrit :
> > La 1ere pour sur le filaire river :
> > https://www.openstreetmap.org/way/34907146
>
> c'est globalement correct https://www.openstreetmap.org/relation/1075117
> même s'il y a de nombreux soucis sur la relation dont des zones
> sans rôle mainstream et à l'inverse des zones avec plusieurs mainstream
> au même endroit.
> J'ai corrigé une partie du tracé hier mais pas encore touché
> à la relation pour éviter d'être à plusieurs dessus.
>
> > La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve :
> > https://www.openstreetmap.org/relation/660056
>
> en plus d'être déconseillé par le wiki et inutile
> c'est incorrect :
> - un ensemble de polygone qui se touche ne forment un multipolygone.
> un multipolygone dans osm est un ou plusieurs polygones qui ne se touche
> pas.
> Le rendu osm.org avait même parlé d’arrêté de faire de la devinette
> et de ne plus faire aucun rendu de certains multipolygone erronés
> afin que l'erreur soie visible au lieu d'avoir des problèmes en cascade.
> - Les berges du Rhône ne s'appelle pas le Rhône, il y a confusion.
>
> > 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 ?
>
> oui
>
> la page sur le wiki fr mériterait aussi d'être rafraîchie/rapprochée
> avec le contenu de la version anglaise.
>
> Et tant qu'à dire, les rôles tributary conflictuels
> sont sur la mauvaise relation
> https://wiki.openstreetmap.org/wiki/Relation:watershed
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] signification multiple crossing=zebra

[marc marc]

En fait le soucis est quand tu fais l'inverse :
tu prend une image sat d'un endroit que tu ne connais pas,
tu édites avec iD, tu vois un zebra au sol,
tu ajoutes un "passage piéton zebra" et iD fait la supposition 
qu'automatiquement c'est un passage sans feu de circulation parce
qu'aux UK, il semblerait que le marquage au sol soie différent
pour les passages avec et sans feu, ce qui n'est pas le cas
ni en France ni en Belgique ni en Suisse
c'est cette supposition là que je propose de corriger.
si tu renseignes passag piéton avec zebra, ca veux juste dire cela.
permettant ainsi à ceux qui le souhaite d'ensuite compléter les
données pour renseigner si le passage piéton a ou non des feux.

Le 26. 10. 18 à 18:59, Gwenaël Jouvin a écrit :
> Bonsoir,
> 
> Lors de mes relevés je m’efforce de placer les passages (au moins ceux qui 
> apparaissent sur mes photos) et surtout, s’il y a des bandes d’éveil de 
> vigilance (tactile_paving=yes|no) et s’ils sont accessibles 
> (wheelchair=yes|limited|no).
> 
> Par contre, je ne vois pas véritablement la pertinence de l’attribut zebra 
> car, s’il a certainement une signification au Royaume-Uni ; c’est différent 
> en France où, par définition, tout passage pour piétons est marqué sur la 
> chaussée, donc ils sont tous « zebra » par défaut.
> 
> Bien sûr, on trouve dans certaines villes des « passages » mieux intégrés 
> dans l’urbanisme, par exemple délimités par des pavés, des clous voire un 
> revêtement ou des pierres colorées.
> Si ce sont bien des passages pour piétons par l’usage, ce n’en sont pas du 
> point de vue de la signalisation routière [1, art. 118].
> Je pense que l’on pourrait ajouter crossing=unmarked pour ces cas clairs par 
> l’usage mais litigieux par la loi.
> 
> Enfin pour finir sur les points litigieux, on voit aussi des passages 
> intégralement peints, en rouge par exemple. C’est illégal [2, II-1], en plus 
> d’être périlleux pour les deux-roues.
> 
> Gwenaël
> 
> 
> [1] IISR 7 : 
> http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_7ePARTIE_VC_20160215_cle217e65.pdf
> [2] Circulaire du 15-05-1996 : 
> https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT00376640
> 
> 
> Le 25/10/2018 à 23:51, marc marc a écrit :
>> Bonjour,
>>
>> j'aurais du vous proposer une édition de masse sur ce sujet.
>> c'était en préparation depuis longtemps depuis que le problème avait été
>> identifié lors d'une discussion cartomobilité qui discute entre autre
>> des problèmes de comment osm peux aider pour renseigner l'accessibilité
>> multiple.
>> mais voila, ces oir josm a poussé un patch qui complique encore la
>> chose. je vais donc vous exposer le problème en français, traduction
>> de celui que je viens de poster sur tagging (la ml mondiale anglaise
>> pour les problèmes de tag).
>>
>> Bonjour. Bonjour,
>>
>> J'ai un gros problème avec crossing=zebra.
>> il empêche de remplir d'autre valeur pour le croisement comme
>> crossing=traffic_signals (passage piéton avec un feu de circulation)
>> crossing=uncontrolled (passage piéton sans feu)
>> le wiki[1] dit que crossing=zebra est un raccourci pour
>> crossing=uncontrolled + crossing_ref=zebra au Royaume-Uni
>> mais beaucoup de zébra tant au Royaume-Uni, qu'en France et ailleur
>> ont des zébra avec feu qui doivent donc être renseign avec
>> crossing=traffic_signals
>> donc à la fin, crossing=zebra n'a pas de sens... peut-être
>> que le contributeur précédent voulait dire crossing=uncontrolled +
>> crossing_ref=zebra
>> mais peut-être qu'il veut dire seulement crossing_ref=zebra et qu'il n'a
>> aucune idée de la présence de feu ou pas (ajout depuis l'imagerie sat
>> par exemple).
>> J'ai corrigé il y a quelques semaines beaucoup de crossing=zebra
>> crossing_1=signals_traffic_signals
>> ou crossing=zebra;traffic_signals qui montrent que c'est un problème.
>>
>> un ticket a été fermé dans iD[2] il y a quelque temps parce que "son dev
>> n'aime pas crossing_ref" (c'est en fait un nom très laid pour le tag)
>> en ce moment josm[3] change le preset pour supprimer cossing_ref=zebra
>> en faveur du croissing=zébra
>>
>> Je fais partie d'un groupe de cartographes travaillant sur
>> l'accessibilité yant l'intention d'ouvrir une discussion pour y
>> remédier, mais l'actualité des commit nous a précédés.
>>
>> donc ma requête est : comment éviter à nouveau une balise multi sens ?
>>
>> Peut/doit-on séparer le type de croisement du marquage au sol ?
>> en résumé : changer les crossing=zebra au profit d'une autre balise ?
>> si oui crossing_Ref est-il si laid que dans le même temps un autre tag
>> en a besoin à utiliser pour le marquage au sol ?
>> (ajout hors traduction : perso je suis partisant d'étape limité séparée
>> et donc initialement j'aurais changer crossing=zebra en
>> crossing_ref=zebra et reporté le choix d'un meilleur non pour le
>> marquage dans un autre sujet)
>>
>> évitons l'argument "il y a trop de cas à régler",
>> cela ne m'effraie pas de proposer une édition de masse une fois qu'un
>> schéma 

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Martin Koppenhoefer]

sent from a phone

> On 26. Oct 2018, at 17:09, Sergio Manzi  wrote:
> 
> ma la tua stessa frase spiega perché sarebbe opportuno fornire anche un 
> riferimento temporale alla misura: tu dici "... puoi anche immaginare 5 anni 
> dopo che forse potrebbe essere cresciuto un po’ ..." e io ti chiedo "5 anni 
> dopo quando?"


Questo è un tipico problema con gli import: i dati sono sempre più vecchi 
rispetto al nostro standard. Normalmente la data di caricamento è anche più o 
meno la data del rilievo, mentre per gli import la data del rilievo è 1-50 anni 
prima del caricamento ;-)

Comunque, una cosa è certa, i dati hanno sempre al minimo l’età del tempo 
passato dal caricamento.

Sono d’accordo con chi l’ha scritto sopra: i dati dei rilievi sono da inserire 
nel changeset / wiki linkato dal changeset.

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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[yo paseopor]

>
>
> En un mensaje anterior estas hablando desde trunk hasta unclassified. Eso
> abarca todas las carreteras, no solo las de fomento.
>
¿Ademas porque la de fomento sí y el resto no?
>
-Propongo la revisión de las carreteras de plataforma única (1 carril por
sentido) de Fomento ...porque es la que no se ha realizado aún. Y si falta
hacer la revisión de las vías de alguna otra administración adelante, animo
a la comunidad de la zona a que la realice , aunque algo me dice que son
muchas sino todas las que ya lo habeis hecho.
- Y no, he dicho todas las categorías que puede abarcar una carretera
perteneciente a Fomento...como pasa con el resto de administraciones.
Hay nacionales que se han convertido en puras vías de servicio, hay otras
que hacen de vía local generando tráfico entre dos localidades muy
próximas. Otras hacen de vía comarcal , otras son útiles para la movilidad
interna de la provincia, otras hacen de nexo entre provincia y otras no
tienen por qué variar de categoría puesto que mantienen el tráfico, la
velocidad media y la seguridad (cruces internivel) y comodidad de una vía
principal.
Suele pasar que en muchos casos el tráfico general circula por la
autovía/autopista o bien por un eje paralelo ,normalmente en mejores
condiciones, a no mucha distancia.

>
> Como ya he comentado no es un dato tan fiable y no he sido el único que lo
> ha dicho. Se mide en lugares concretos, no es una medida continua de la
> carretera, porque eso no es fácil de hacer ni barato.
>
A juzgar por lo que se ve en el mapa de Fomento, las estaciones son
variopintas y están situadas por toda la geografía nacional, creo que es
una medición que , aunque con errores, como todos los sistemas es muy
válida para esta propuesta

>
> Yo cuando he usado los datos tampoco me encontrado muchos casos que me
> lleve por sitios disparatados como esta actualmente los datos. Normalmente
> son por otro tipo de errores las rutas raras que me encontrado que no
> tienen nada que ver.
>
-Porque en los casos donde la dicotomía entre plataforma única y doble
plataforma el ruteador lo tiene claro. La autovía prima sobre todo , sea de
Fomento o no lo sea. Pero eso no quita que se pueda tener en cuenta otros
baremos para categorizar las carreteras en OSM, en este caso las
gestionadas por Fomento. OSM es algo más que ruteadores, por ello es
importante cambiar efectivamente esas categorías en las vías que se estime
oportuno en base a unos estudios y parámetros complejos pero objetivos.

>
> Por ahora en estos correos lo que encontrado es una comunidad que no ve el
> cambio como tú. No veo a la comunidad actualmente en el estado que esta
> detrás de este cambio.
>
-Que la comunidad no lo "vea" no significa que no se pueda intentar
proponer. Y puestos a ver, de los 28 mensajes emitidos, de momento en este
debate, escritos por 7 personas he visto en contra 3, a favor 2 y 1 que no
se opone, así que yo no veo a la comunidad (si es que no interviene más
gente, tampoco voy a obligar a intervenir a nadie, faltaría más) tan
alejada del debate ni veo a una posición muy por encima de la otra.

> Ya lo he dicho más veces hay muchos flecos y es donde veo el mayor
> problema. Y es donde esta el lio de ediciones, interpretaciones y lo que
> ves tan claro en verdad no lo es. No es ni comparable con la claridad del
> sistema actual. Que igualmente no es perfecto pero tiene poco lugar a
> interpretación.
>
Yo no le veo tantos flecos, ya va bien que le busquemos tres pies al gato.
Evidentemente que el sistema actual es claro, porque sólo se basa en un
parámetro concreto, pero ¿eso es lo correcto? ¿Es el único criterio que nos
puede ofrecer una base de datos colaborativa con multitud de informaciones
como es OSM? Francamente, yo espero más de OSM, espero el reflejo de la
complejidad del mundo real, espero datos lo más ajustados posibles y con
más variables tenidas en cuenta para cubrir todas las posibilidades. Para
fijarme solo en la administración de las carreteras ya existe la extinta
Guía Campsa (hoy Repsol), el mapa aquel mítico que editaba el MOPU, o los
mapas impresos de Michelín - perdón, estos últimos no guardan exactamente
las categorías para las administraciones sino que hacen su propia
interpretación, una pena que estén desactualizados a más no poder - .

>
> Abría que ver todo pero que el primer sitio que mire me encuentre con esto
> me mosquea. Puede que sea casualidad pero habría que asegurarse.
>
Por supuesto los errores en los datos hay que corregirlos y tener en cuenta
que son errores. Pero dado que Javi explicó que Fomento usa esos estudios
dudo que estén mal realizados de forma generalizada. Creo que la gente que
los hace debe cumplir con unos procedimientos y estándares de calidad a
nivel europeo y mundial que seguramente hagan que sean correctos y por lo
tanto puedan ser un baremo fiable como para basarnos para marcar las
categorías de una carretera en OSM.

Saludos
yopaseopor
___
Talk-es mailing list

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[yo paseopor]

>
> ¿De verdad? ¿Qué ruteadores son esos? ¿No sería más fácil que esos
> ruteadores se pusieran la día con los criterios que utilizan? ¡Menuda
> patata de ruteador, si no utiliza la cantidad de etiquetas que hay en
> la base de datos!
>
Te soy sincero, conocimientos técnicos en esta materia no tengo por
desgracia pero creo que la primera etiqueta que tienen en cuenta la gran
mayoría de los es la categoría de highway, pero dicho esto, dado que los
ruteadores tienen en cuenta muchos parámetros, no importará que categoría
ya no esté asignado a la administración que la gestiona pues para ello ya
está la primera letra de reference y la etiqueta operator, que estoy seguro
que esos ruteadores tan avanzados pueden tener en cuenta si es lo que
buscamos

>
> Pues no lo parece
>
En qué te basas para decir que me muevo por los colores: me muevo por las
categorías, porque estas estén bien usadas, porque una trunk sea una vía
principal y no el simple ramal de una autovía que a veces la parte en dos
sin solución de continuidad. Porque cuando yo veo trunk pienso en una vía
que me va a dar seguridad, que me va a dar tráfico, que me va a permitir
una conducción agradable , sin sobresaltos, con preferencia. Y hay muchas
de esas nacionales que , desde que tienen autovías a su alrededor ya no
cumplen con esos parámetros.

>
> ¿Por qué consideras que han dejado de ser 'principales'? ¿Cuál
> consideras que debe ser es el criterio para considerar que una
> carretera es 'principal'? ¿La IMD?
>
¿La intensidad de uso de una vía te parece mal baremo para saber si una vía
es "principal" o no?
¿La velocidad media y su fluidez te parecen mal baremo para saber si una
vía es "principal" o no?
¿El hecho de ser una vía segura, sin sobresaltos, con una conducción
cómoda, con cruces internivel, etc. te parece mal baremo para saber si una
vía es "principal" o no?
¿El hecho de que una vía pertenezca a Fomento te parece el único parámetro
válido para considerar si una vía es principal?

> Sí, noto cierta animadversión con las vías de gestión estatal
>
Yo no tengo nada en contra de Fomento en particular y mucho menos en contra
del estado en general, lo tengo en contra del criterio de esta comunidad de
no replantearse la mejora de un etiquetado más ajustado a la realidad
práctica - la mayoría de usuarios no miramos quien gestiona una vía a no
ser que eso implique un pago por uso inmediato - en las vías de un solo
carril por sentido por el simple hecho de pertenecer a una administración
determinada, que en este caso concreto es Fomento (lo cual se traduce en
carretera nacional).
De hecho muchas autovías pertenecen a Fomento y no tengo nada en contra de
ellas ni he hecho tal manifestación. Y lo mismo valdría para cualquier
administración, pero se da el caso de que ese proceso con esas otras
administraciones ya lo hemos ido haciendo, el ejemplo combinado de
Ávila-Salamanca vs. Leganés-Móstoles lo dejó bastante claro.
Por poner un ejemplo que refuerza esta idea, la comunidad OSM en Catalunya,
no considera que todas las vías consideradas por la Generalitat de
Catalunya como principales deben de ser trunk, primary, secondary o
tertiary y su categoría va variando en función de esos otros parámetros de
los que aquí propongo para Fomento. Eso no genera errores de rutaje ni
ningún problema o dificultad para el usuario, simplemente acaba dando , de
forma muy visual la mejor opción para un recorrido determinado. Equivocarse
escogiendo un recorrido "más corto" puede convertirse en 30 minutos más de
viaje.

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

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[yo paseopor]

>
> Lo que quiero decir no es que la realidad de un país, sea el que sea,
> del continente que sea, tenga que compararse con la de España. Nada más
> lejos que eso. Lo que digo es que la wiki refleja claramente cual debe
> ser el criterio general que se debe seguir para la clasificación de las
> distintas carreteras, que no es la velocidad máxima ni el estado de la
> carretera. Para eso, y para otras características, ya hay etiquetas
> apropiadas (maxspeed, surface, smoothness, etc).
>
Y se usa reference para determinar qué referencia tiene esa carretera (y
las primeras letras así lo dictaminan) y operator para hablar del operador
de la vía, la administración que gestiona esa vía, no el tipo en highway

>
> Un ejemplo: Es bastante común ver a mapeadores etiquetando como tracks a
> carreteras típicamente unclassified simplemente por el hecho de estar
> sin asfaltar. No son muy frecuentes, pero las hay. Un ejemplo es este
> tramo de unclassified: https://www.openstreetmap.org/way/187731930

¿En España qué determina que es carretera y qué camino o pista?

>
> Un último comentario: creo que la propuesta tiene sentido para algunos
> tramos de antiguas N-XXX que dejaron de tener esa función primary, pero
> no estoy de acuerdo en aplicar criterios como velocidad, estado de la
> carretera y otros para clasificar a los viales. Además, veo muy
> complicado para la mayoría de mappers tomar decisiones para cada caso
> concreto.
>

¿Vemos complicado  usar los datos de catastro para importar los edificios?
¿Vemos complicado usar un programa de conversión en linux?
¿Vemos complicado leernos cinco o seis páginas de la wiki sobre
instrucciones para seguir este proceso?
¿Vemos complicado usar QGIS para darle forma a las diversas zonas que nos
apetezca modificar?
¿Vemos complicado crear una tarea en el gestor de tareas siguiendo las
instrucciones de la wiki?
¿Vemos complicado bajarnos esos datos y combinarlos con los ya existentes
en OSM?
¿Vemos complicado validar una parcela parecida?

Eso lo está ejecutando la comunidad en estos momentos.

¿Vemos complicado mirar un pdf con IMD provinciales sobre nuestra provincia
pintados en colores y aplicar el código resultante?
¿Vemos complicado mirar un pdf (velocidades media) sobre esos tramos ?
¿Vemos complicado usar iD o JOSM con el complemento de Mapillary activado
para ver imágenes a pie de calle?
Son los datos que nos pediría usar esta propuesta amén de, como siempre,
tener a la comunidad pendiente para ayudar a la gente que lo pida, como
siempre se ha hecho.

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

Re: [OSM-talk-fr] Correction des voies de chemin de fer gare d'Austerlitz

[François Lacombe]

Salut Florian,

Tu m'accompagnes pour aller voir ca de visu ? :=)


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 


Le ven. 26 oct. 2018 à 18:57, Florian LAINEZ  a écrit :

> Hello,
> En faisant une mise-à-jour dans la gare Austerlitz j'ai remarqué qu'il
> manquait des voies au niveau -1 le long des quais du RER C.
> J'ai rajouté ça ici :
> https://www.openstreetmap.org/way/638180762
> https://www.openstreetmap.org/way/638180763
> Je ne sais pas ce que ces voies deviennent au nord et au sud du quai ni
> les détails à rajouter sur ces segments donc pour l'instant je les ai
> raccordé au réseau ferré avec un fixme.
> Peut-être que cela intéresse les spécialistes des réseaux, qui sait ? ;)
>
> Une fois sur la gare dans JOSM, utilisez les filtres de niveaux qui
> apparaissent en haut à gauche pour bien visualiser ce que j'ai fait.
>
> PS : J'ai fait ça aussi dans la gare souterraine de Musée d'Orsay et je
> vais continuer comme ça pour les autres gares parisiennes ...
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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] signification multiple crossing=zebra

[Gwenaël Jouvin]

Bonsoir,

Lors de mes relevés je m’efforce de placer les passages (au moins ceux qui 
apparaissent sur mes photos) et surtout, s’il y a des bandes d’éveil de 
vigilance (tactile_paving=yes|no) et s’ils sont accessibles 
(wheelchair=yes|limited|no).

Par contre, je ne vois pas véritablement la pertinence de l’attribut zebra car, 
s’il a certainement une signification au Royaume-Uni ; c’est différent en 
France où, par définition, tout passage pour piétons est marqué sur la 
chaussée, donc ils sont tous « zebra » par défaut.

Bien sûr, on trouve dans certaines villes des « passages » mieux intégrés dans 
l’urbanisme, par exemple délimités par des pavés, des clous voire un revêtement 
ou des pierres colorées.
Si ce sont bien des passages pour piétons par l’usage, ce n’en sont pas du 
point de vue de la signalisation routière [1, art. 118].
Je pense que l’on pourrait ajouter crossing=unmarked pour ces cas clairs par 
l’usage mais litigieux par la loi.

Enfin pour finir sur les points litigieux, on voit aussi des passages 
intégralement peints, en rouge par exemple. C’est illégal [2, II-1], en plus 
d’être périlleux pour les deux-roues.

Gwenaël


[1] IISR 7 : 
http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_7ePARTIE_VC_20160215_cle217e65.pdf
[2] Circulaire du 15-05-1996 : 
https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT00376640


Le 25/10/2018 à 23:51, marc marc a écrit :
> Bonjour,
> 
> j'aurais du vous proposer une édition de masse sur ce sujet.
> c'était en préparation depuis longtemps depuis que le problème avait été 
> identifié lors d'une discussion cartomobilité qui discute entre autre 
> des problèmes de comment osm peux aider pour renseigner l'accessibilité 
> multiple.
> mais voila, ces oir josm a poussé un patch qui complique encore la 
> chose. je vais donc vous exposer le problème en français, traduction
> de celui que je viens de poster sur tagging (la ml mondiale anglaise 
> pour les problèmes de tag).
> 
> Bonjour. Bonjour,
> 
> J'ai un gros problème avec crossing=zebra.
> il empêche de remplir d'autre valeur pour le croisement comme 
> crossing=traffic_signals (passage piéton avec un feu de circulation) 
> crossing=uncontrolled (passage piéton sans feu)
> le wiki[1] dit que crossing=zebra est un raccourci pour 
> crossing=uncontrolled + crossing_ref=zebra au Royaume-Uni
> mais beaucoup de zébra tant au Royaume-Uni, qu'en France et ailleur
> ont des zébra avec feu qui doivent donc être renseign avec 
> crossing=traffic_signals
> donc à la fin, crossing=zebra n'a pas de sens... peut-être
> que le contributeur précédent voulait dire crossing=uncontrolled + 
> crossing_ref=zebra
> mais peut-être qu'il veut dire seulement crossing_ref=zebra et qu'il n'a 
> aucune idée de la présence de feu ou pas (ajout depuis l'imagerie sat 
> par exemple).
> J'ai corrigé il y a quelques semaines beaucoup de crossing=zebra 
> crossing_1=signals_traffic_signals
> ou crossing=zebra;traffic_signals qui montrent que c'est un problème.
> 
> un ticket a été fermé dans iD[2] il y a quelque temps parce que "son dev 
> n'aime pas crossing_ref" (c'est en fait un nom très laid pour le tag)
> en ce moment josm[3] change le preset pour supprimer cossing_ref=zebra
> en faveur du croissing=zébra
> 
> Je fais partie d'un groupe de cartographes travaillant sur 
> l'accessibilité yant l'intention d'ouvrir une discussion pour y 
> remédier, mais l'actualité des commit nous a précédés.
> 
> donc ma requête est : comment éviter à nouveau une balise multi sens ?
> 
> Peut/doit-on séparer le type de croisement du marquage au sol ?
> en résumé : changer les crossing=zebra au profit d'une autre balise ?
> si oui crossing_Ref est-il si laid que dans le même temps un autre tag 
> en a besoin à utiliser pour le marquage au sol ?
> (ajout hors traduction : perso je suis partisant d'étape limité séparée
> et donc initialement j'aurais changer crossing=zebra en 
> crossing_ref=zebra et reporté le choix d'un meilleur non pour le 
> marquage dans un autre sujet)
> 
> évitons l'argument "il y a trop de cas à régler",
> cela ne m'effraie pas de proposer une édition de masse une fois qu'un 
> schéma cohérent a été établi.
> mais le fait d'avoir la moité des outils qui remplissent une valeur avec 
> une autre signification que l'autre ou que la signification historique 
> est un gros problème pour l'utilisation. des données.
> 
> [1] https://wiki.openstreetmap.org/wiki/Key:crossing
> [2] https://github.com/openstreetmap/iD/issues/4788
> [3] https://josm.openstreetmap.de/ticket/16793
> https://taginfo.openstreetmap.fr/search?q=%3Dzebra
> 
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

[OSM-talk-fr] Correction des voies de chemin de fer gare d'Austerlitz

[Florian LAINEZ]

Hello,
En faisant une mise-à-jour dans la gare Austerlitz j'ai remarqué qu'il
manquait des voies au niveau -1 le long des quais du RER C.
J'ai rajouté ça ici :
https://www.openstreetmap.org/way/638180762
https://www.openstreetmap.org/way/638180763
Je ne sais pas ce que ces voies deviennent au nord et au sud du quai ni les
détails à rajouter sur ces segments donc pour l'instant je les ai raccordé
au réseau ferré avec un fixme.
Peut-être que cela intéresse les spécialistes des réseaux, qui sait ? ;)

Une fois sur la gare dans JOSM, utilisez les filtres de niveaux qui
apparaissent en haut à gauche pour bien visualiser ce que j'ai fait.

PS : J'ai fait ça aussi dans la gare souterraine de Musée d'Orsay et je
vais continuer comme ça pour les autres gares parisiennes ...

-- 

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

Re: [OSM-talk] Mobile Application for optimizing OSM ski area data

[Nick Whitelegg]

As others have said, users should authenticate with their own OSM accounts so 
that malicious edits can be detected.


There's a very good Java library - osmapi - which I would strongly recommend 
for doing editing from within an Android app. It's developed by Tobias Zwick, 
developer of StreetComplete, and is available here:


https://github.com/westnordost/osmapi



To use OAuth, you can use another very good open source library: Signpost.


I myself have developed a custom editor in recent months, using osmapi and 
Signpost - it's aimed at allowing England and Wales footpath mappers to add 
rights of way quickly and easily to OSM. It's a bit rough round the edges, but 
you might find the code useful for reference. StreetComplete itself is also a 
good point of reference, though that's a significantly more complex app.


https://gitlab.com/nickw1/mapthepaths-android


Nick








From: Valentina Böhm 
Sent: 26 October 2018 13:22:16
To: talk@openstreetmap.org
Subject: [OSM-talk] Mobile Application for optimizing OSM ski area data


I am planning to develop an mobile app to optimize ski area data provided by 
OSM. The user should be able to use the app for locating him- or herself in a 
ski area and have a look at all the different slopes and lifts and all their 
details. But the user should also be able to optimize the data of the ski area. 
First of all for the better experience when using the app for navigating. But 
also for providing OSM optimized and more detailed data about ski areas.

If a user wants to optimize the data he or she can either manually change the 
data, for example, edit the name or reference number of a slope or lift. Or he 
or she can provide their movement data by tracking it with the application 
while skiing. The tracked data should, in the end, help to fill gaps between 
slopes or slopes and lifts. Or even detect new unknown slopes.

What would you recommend regarding authentication? Is it ok if users of my app 
are committing data on my behalf or should all users have their own OSM account?

If users have their own account, is it possible and ok if I prepare the data 
with my algorithm and commit the data on their behalf?

In general, what is your recommendation regarding this kind of third-party 
integration? Are special API tokens provided for third-party apps?

I’m also interested in feedback about the idea. Are there similar projects? 
What do you think of my idea?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-es] Propuesta de cambios en la normalización para España de carreteras nacionales

[yo paseopor]

Las carreteras se gestionan por las diferentes administraciones,
> siguiendo, en general, criterios en relación con el recorrido que
> hacen, en Madrid y en cualquier sitio de España. Si la carretera
> atraviesa más de una Comunidad Autónoma, en general, la gestiona la
> Administración Central. Si une ciudades dentro de una sola comunidad,
> en general, la gestiona la Comunidad Autónoma correspondiente y, en el
> caso de las comunidades multiprovinciales, si une localidades dentro de
> una misma provincia, la gestiona la Diputación Provincial. Puede
> suceder que la herencia del pasado incluya algunas excepciones.
>
Y son estas excepciones las que hemos de controlar midiendo si realmente
cumple con esos parámetros que una vía de máxima categoría debe dar, a
través de su uso (IMD) ,su velocidad media, y su seguridad (cruces
internivel, etc.)

>
> No coincido. Yo creo que si una carretera une dos capitales de
> provincia es primary, la gestione quien la gestione.

Ya me parece bien, el problema es que muchas son trunk por el simple hecho
de ser de Fomento, no por unir capitales, por tener gran tráfico, por tener
unas condiciones acordes con los tiempos (Velocidad media, cruces
internivel, etc.)

> Lo que suele
> suceder es que esas carreteras las gestiona Fomento. Ahora bien, si en
> Cataluña o en otra Comunidad hay alguna carretera que una capitales de
> provincia y la gestione la CCAA, pues creo que también es primary. No
> es la administración que gestiona la que determina si una carretera es
> primary o no, es la función que cumple la carretera, al menos eso
> pienso yo
>
En eso coincidimos, lo que ya no sé si coincidiremos es cuando te explique
que la función que cumple esa trunk que técnicamente une capitales ha
cambiado especialmente porque tiene a su lado una autovía de dos carriles
por sentido y tres en muchos tramos para unir esas mismas dos capitales,
duplicando el recorrido y dejando esa trunk para un uso marginal como
podemos determinar por el IMD.

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

Re: [OSM-talk] Zoom to search results on the map

[Andrew Buck]

You can hit the "back" button in the browser to go back to the list 
after clicking on one (this is not obviously communicated to the user 
but it does work).  I agree in general though that this part of the site 
is not great UI wise.  Not sure what to do to change it for the better, 
but it definitely could use work.  I guess one improvement would be a 
"back" or "return to search results" kind of button when you click on 
something.  Yes you can use the browser back button to do this now, but 
there is no conveyance in the UI that this is an option.  Adding an 
explicit button would go a long way on the usability front.


-AndrewBuck



On 10/26/18 1:26 AM, Maarten Deen wrote:
When you search on something in the searchbox on openstreetmap.org that 
returns multiple results, the map moves to the first result and when you 
hover over the result it displays a marker.
But for all the other results, you need to click to see where it is. 
This removes the search results and displays details of the object you 
clicked.  Suppose this is not what you're looking for, you now have to 
enter the search parameters again and nominatim now searches from the 
last point the map was centred at. So the search results differ from the 
first try. Now you have to remember what results you've looked at so you 
don't look at them again.


Is there no way to show the second, third, etc, result on the map 
without removing the search results?


Regards,
Maarten

___
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: [Talk-it] Mancata attribuzione.... due al prezzo di una

[Marcello]

Alessandro,

avevo visto una mia foto relativa alle mura megalitiche di Amelia,
presente su Commons, nella pagina
https://www.paesionline.it/italia/monumenti-ed-edifici-storici-amelia,
dalla quale non è possibile ricavare alcuna informazione sull'autore,
aprendo la pagina del monumento la foto non c'è più e compare la mappa
OSM di localizzazione del monumento senza attribuzione.

In tutte le pagine del sito dove c'è la mappa di localizzazione questa è
senza attribuzione, per le foto  girando un po' ho capito il loro 'modus
operandi', gli utenti possono registrarsi sul sito e a quel punto
possono caricare del materiale e scrivere recensioni di monumenti,
locali, ecc. Per ogni città c'è una pagina che raccoglie le foto, nel
caso di Amelia è https://www.paesionline.it/italia/foto-immagini-amelia,
passando con il mouse sulla miniatura delle foto compare il nome
dell'utente che l'ha caricata in PaesiOnLine, cliccandola apre la pagina
con la foto e i crediti (nel mio caso è sbagliato ma è un errore di
battitura).

Ieri mattina mi ha risposto Marianna Di Pilla, Ufficio Editoriale e
Social Media Manager di PaesiOnLine, a cui ho chiesto di inserire
l'attribuzione sulle mappe e per le foto che da ogni miniatura visibile
cliccandoci si possa richiamare la pagina con la foto e i crediti, non
solo dalla pagina di raccolta delle foto, non facile da trovare. La
reazione è stata veloce, vediamo se anche l'aggiornamento lo sarà
altrettanto.

Ciao
Marcello

On 25/10/2018 15:10, Alessandro Palmas wrote:
> Il 25/10/18 08:56, Marcello ha scritto:
>> Salve,
>>
>> ho trovato un altro sito che usa le mappe OSM con solo la scritta
>> Leaflet, nessuna menzione di OpenStreetMap, oltretutto anche le foto dei
>> monumenti molto spesso sono prese da Wikimedia Commons senza nessuna
>> attribuzione. Loro invece si riservano tutti i diritti ecc. ecc.
>>
>> il sito è www.paesionline.it, ho scritto a entrambe le mail che ho
>> trovato, amministrazi...@valica.it e sa...@valica.it, vi terrò al
>> corrente della risposta (se arriverà).
>>
>
> Ciao Marcello,
> ho verificato la presenza di mappa OSM. Mi daresti giusto un
> riferimento a una foto presa da Commons (così non sto a fare ricerche
> se l'hai già fatta tu)?
>
> E cosa grave dichiarano la proprietà dei contenuti.
>
> https://www.paesionline.it/info/legal
> "MARCHI E DIRITTI
> Tutti i contenuti del Sito, quali a titolo esemplificativo e non
> esaustivo, testi, grafici, marchi, loghi, icone, immagini, brani
> audio, database o software sono protetti dalla legge sul diritto
> d’autore, n. 633/41, e sono di proprietà del Titolare ovvero dei
> relativi fornitori"
>
> Alessandro
>
>

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Sì, ma coste, fiumi e montagne *normalmente *cambiano in una scala di tempo 
molto più lunga: non per nulla si usa dire "tempi geologici" per indicare un 
lungo lasso di tempo...

Sono d'accordo nell'indicare, le dimensioni dell'albero (/soprattutto quando 
"interessanti"/), ma la tua stessa frase spiega perché sarebbe opportuno 
fornire *anche *un riferimento temporale alla misura: tu dici "/... puoi anche 
immaginare 5 anni dopo che forse potrebbe essere cresciuto un po’ .../" e io ti 
chiedo "/5 anni dopo quando?/"

Ciao!

Sergio


On 2018-10-26 16:55, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 26. Oct 2018, at 14:40, Gabriele Sani  wrote:
>>
>> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo non 
>> e' esattamente corretto: cioe', in teoria si mappa cio' che non e' effimero 
>> (o almeno che potrebbe non esserlo). Le misure di un albero, altezza e 
>> circonferenza, cambieranno PER FORZA nel corso del tempo...
>
>
> tutto cambia col tempo, le coste, il percorso di un fiume, l’altezza di una 
> montagna, tanto più gli edifici, le strade, i negozi ecc.
>
> Se tu vedi nei dati un albero alto 20metri e di una certa età e specie, puoi 
> anche immaginare 5 anni dopo che forse potrebbe essere cresciuto un po’, ciò 
> non toglie l’utilità dell’informazione.
>
> Ciao, Martin 
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Martin Koppenhoefer]

sent from a phone

> On 26. Oct 2018, at 16:55, Martin Koppenhoefer  wrote:
> 
> Se tu vedi nei dati un albero alto 20metri e di una certa età e specie, puoi 
> anche immaginare 5 anni dopo che forse potrebbe essere cresciuto un po’, ciò 
> non toglie l’utilità dell’informazione.


scusate, riprovo questo in italiano:
se tu vedessi, 5 anni dopo l’inserimento, i dati di un albero alto 20 metri... 
potresti anche immaginare che forse potrebbe..
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Martin Koppenhoefer]

sent from a phone

> On 26. Oct 2018, at 16:00, Cascafico Giovanni  wrote:
> 
> Osm non è un catalogo per naturalisti, ne' un entry point di wikidata. Non 
> pensate che un paio di semplici tag possa aiutare meglio per esempio un 
> turista?


il turista potrebbe usare un’app che mette insieme osm con altri fonti. Utilità 
per turisti non è un criterio forte, altrimenti mapperemo anche le critiche sui 
ristoranti ;-)


> Eppoi perché allora creare i tag leaf_type e leaf_cycle?


penso siano stati introdotti per le foreste e i boschi, per singoli alberi la 
specie specifica dovrebbe bastare.


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

Re: [OSM-talk] Mobile Application for optimizing OSM ski area data

[Yves]

A middle ground could be that your users upload a gpx file with osm-compatible 
information so that more skilled OSM contributors can use them to edit the map.
It relieve your app from the burden of being a map editor.
However, information will probably be lost in the process, we prefer first hand 
contributions.
Yves - (Opensnowmap) 

Le 26 octobre 2018 14:54:05 GMT+02:00, Frederik Ramm  a 
écrit :
>Hi,
>
>On 26.10.2018 14:22, Valentina Böhm wrote:
>> What would you recommend regarding authentication? Is it ok if users
>of
>> my app are committing data on my behalf or should all users have
>their
>> own OSM account?
>
>Using a central account for aggregated user contributions is
>discouraged; if some of your users commit vandalism or add data from
>illegal sources, it becomes very difficult to separate the good from
>the
>bad. Also, other OSM mappers might want to contact the user who has
>added or changed something.
>
>> If users have their own account, is it possible and ok if I prepare
>the
>> data with my algorithm and commit the data on their behalf?
>
>This is possible with OAuth authentication, and other programs like
>wheelmap or StreetComplete already do something similar. Although I am
>a
>little worried when you say "prepare the data with your algorithm" -
>you
>should always make sure the user has full control over what they
>submit,
>you should not submit something that might come as a surprise to the
>user later.
>
>> I’m also interested in feedback about the idea. Are there similar
>> projects? What do you think of my idea?
>
>"Topical" editors - software that allows specialist contributions in
>niche areas - can be a valuable addition to the OSM editing landscape,
>so in general I think it sounds like a good idea!
>
>Best
>Frederik
>
>-- 
>Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09"
>E008°23'33"
>
>___
>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: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Martin Koppenhoefer]

sent from a phone

> On 26. Oct 2018, at 14:14, Cascafico Giovanni  wrote:
> 
> Che ne dite di questo [1] tagging?
> 
> natural=tree


ok


> ref=28/l483/UD/06


questo lo vedo scritto sull’albero? Io darei un’indicazione di chi è il ref, 
tipo
ref:xyz=*


> circumference=3 


ok


> ele=170 


si riferisce al terreno intorno, vero? È in WGS84, oppure qual’è il sistema di 
riferimento?



> height=20 


ok


> leaf_cycle=deciduous 
> leaf_type=broadleaved 


ok


> taxon=Cupressus cashmeriana 
> taxon:it=Cipresso del Cashmere 


userei species, e non metterei nomi comuni (it). species è più specifico ed è 
usato 5volte di più rispetto a taxon. Taxon lo vedo come tag preliminare se non 
sai di che livello di classificazione biologica si tratta.

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Martin Koppenhoefer]

sent from a phone

> On 26. Oct 2018, at 14:40, Gabriele Sani  wrote:
> 
> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo non 
> e' esattamente corretto: cioe', in teoria si mappa cio' che non e' effimero 
> (o almeno che potrebbe non esserlo). Le misure di un albero, altezza e 
> circonferenza, cambieranno PER FORZA nel corso del tempo...



tutto cambia col tempo, le coste, il percorso di un fiume, l’altezza di una 
montagna, tanto più gli edifici, le strade, i negozi ecc.

Se tu vedi nei dati un albero alto 20metri e di una certa età e specie, puoi 
anche immaginare 5 anni dopo che forse potrebbe essere cresciuto un po’, ciò 
non toglie l’utilità dell’informazione.

Ciao, Martin 


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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

L'idea che me ne sono fatto è che servano soprattutto a descrivere boschi 
(natural=wood) [1] in cui c'è una popolazione non omogenea di diverse specie di 
piante, ma globalmente/prevalentemente dalle stesse caratteristiche.

Concordo che OSM non sia un catalogo per naturalisti e che "/presentare/" 
l'informazione riguardo ai leaf_type e leaf_cycle possa essere 
interessante/utile, ma questa info può essere desunta indirettamente (/per 
esempio da Wikidata/) se so esattamente di che "taxon" si tratta, così come il 
nome in Italiano o qualsiasi altra lingua.

[1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood


On 2018-10-26 16:00, Cascafico Giovanni wrote:
> Eppoi perché allora creare i tag leaf_type e leaf_cycle?



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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Cascafico Giovanni]

Sui tag per le foglie: Osm non è un catalogo per naturalisti, ne' un entry
point di wikidata. Non pensate che un paio di semplici tag possa aiutare
meglio per esempio un turista?
Eppoi perché allora creare i tag leaf_type e leaf_cycle?

Il ven 26 ott 2018, 14:27 Sergio Manzi  ha scritto:

> Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"
>
> Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa
> quando (*com'è naturale*) l'albero cresce? Serve un riferimento temporale
> che stabilisca quando le misure sono state fatte?
>
> "ele" può anche andare bene, ma in realtà sembra essere più pensato per le
> montagne. E' diffuso l'utilizzo di questa key per altre features?
>
> Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it": sono
> tutte informazioni ridondanti e derivabili da un "look-up" sulla base della
> chiave "taxon".
>
> Ciao!
>
> Sergio
>
> On 2018-10-26 14:14, Cascafico Giovanni wrote:
>
> Che ne dite di questo [1] tagging?
>
> natural=tree
> ref=28/l483/UD/06
> circumference=3 
> ele=170 
> height=20 
> leaf_cycle=deciduous 
> leaf_type=broadleaved 
> taxon=Cupressus cashmeriana 
> taxon:it=Cipresso del Cashmere 
>
>
> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>
>
>>
>>
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Cascafico Giovanni]

Il dataset degli alberi monumentali elenca alberi "cresciutelli" :-)
I sopralluoghi sono stati fatti tra il 2013 ed il 2018: credo sia
sufficiente un source:date sul changeset per dedurre improbabili modifiche
dimensionali.
Piuttosto verranno fatti gli aggiornamente sui nuovi inclusi nel catalogo e
gli abbattuti.

Il ven 26 ott 2018, 14:49 Sergio Manzi  ha scritto:

> ... o anche lasciare height e circumference e mettere una note del tipo
> "note=Height and circumference as of 2018-10-26"
>
> On 2018-10-26 14:46, Sergio Manzi wrote:
>
> Concordo, ma d'altro canto sono info che potrebbero avere una certa
> rilevanza, sopratutto quando si tratta di "misure eccezionali" che potrebbe
> essere interessante segnalare. Forse meglio in note=* o note:it=*  ?
>
> On 2018-10-26 14:40, Gabriele Sani wrote:
>
> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo
> non e' esattamente corretto: cioe', in teoria si mappa cio' che non e'
> effimero (o almeno che potrebbe non esserlo). Le misure di un albero,
> altezza e circonferenza, cambieranno PER FORZA nel corso del tempo...
>
> Il giorno ven 26 ott 2018 alle ore 14:27 Sergio Manzi  ha
> scritto:
>
>> Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"
>>
>> Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa
>> quando (*com'è naturale*) l'albero cresce? Serve un riferimento
>> temporale che stabilisca quando le misure sono state fatte?
>>
>> "ele" può anche andare bene, ma in realtà sembra essere più pensato per
>> le montagne. E' diffuso l'utilizzo di questa key per altre features?
>>
>> Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it":
>> sono tutte informazioni ridondanti e derivabili da un "look-up" sulla base
>> della chiave "taxon".
>>
>> Ciao!
>>
>> Sergio
>>
>> On 2018-10-26 14:14, Cascafico Giovanni wrote:
>>
>> Che ne dite di questo [1] tagging?
>>
>> natural=tree
>> ref=28/l483/UD/06
>> circumference=3 
>> ele=170 
>> height=20 
>> leaf_cycle=deciduous 
>> leaf_type=broadleaved 
>> taxon=Cupressus cashmeriana 
>> taxon:it=Cipresso del Cashmere 
>>
>>
>> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>>
>>
>>>
>>>
>>
>> ___
>> Talk-it mailing 
>> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-cz] Fody - otevreni oblasti fotky v JOSM

[Tom Ka]

Ahoj,

pridal jsem do Fody krome moznosti otevreni na mapach i otevreni oblasti
pomoci dalkoveho ovladani JOSM.

https://osm.fit.vutbr.cz/fody/?id=18296
(prvni polozka vlevo od fotky)

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

Re: [Talk-cz] AlzaBox, jak mapovat?

[petr . kadlec]

Ahoj,

On Fri, Oct 26, 2018 at 2:43 PM mahdi1...@centrum.cz 
wrote:

> co toto? https://wiki.openstreetmap.org/wiki/Tag:vending%3Dparcel_pickup


Souhlas. https://www.openstreetmap.org/node/4464821389

A vůbec

https://www.openstreetmap.org/search?query=alzabox

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

Re: [Talk-us] New United States Bicycle Routes!

[Greg Morgan]

Kentucky USBR 23  is done.
https://www.openstreetmap.org/relation/8843677#map=10/37.4960/-85.4712

On Wed, Oct 24, 2018 at 12:30 PM OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> AASHTO has completed it's "Autumn 2018 round" of national route numbering
> approvals (almost) and there are new USBRs for OSM to map.
>
> One is already completed (thank you, user:micahcochran!):  USBR 15 was
> extended from Georgia into Florida to connect to Florida's existing USBR 90.
>
> In Kentucky, route data for USBR 21 (Georgia also has 21) and USBR 23
> (connecting to Tennessee's 23) are also available.  While our WikiProject
> (see https://wiki.osm.org/wiki/WikiProject_U.S._Bicycle_Route_System )
> has route data for both of these — PDF maps and turn-by-turn spreadsheets —
> the route is not quite yet approved.  I have been told by a knowledgable
> source that "the AASHTO bureaucrat in charge of preparing the vote didn't
> put the (Kentucky) applications in front of the committee.  As a result,
> the applications were sent to the committee for an email vote, which is not
> yet concluded."  That's OK.
>
> So, as is our usual (established for at least the last five years)
> process, we can take the sometimes substantial time and effort it takes to
> enter these while we wait for this "email vote approval" to complete, while
> the route is tagged state=proposed in the meantime.  Kentucky's 21 and 23
> are each "seeded" in one southern county, properly tagged, they simply need
> completion.  If AASHTO's email vote approves these, we remove the
> state=proposed tag, whether the route is fully entered into OSM or not.
> Let's enter it sooner rather than later!  Details on how to do so and links
> to route data in the cloud are found at the WikiProject link above.  Step
> right up, please!
>
> Thank you for making OSM (and its companion renderer OpenCycleMap, as well
> as other great bicycle routing tools) one of the most comprehensive bicycle
> routing platforms in the world.  Like "E pluribus, unum" in the USA, "Ex
> data, multum" in OSM:  "From data, much."  (Yes, I did just make that up!)
>
> SteveA
> California
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Mobile Application for optimizing OSM ski area data

[Frederik Ramm]

Hi,

On 26.10.2018 14:22, Valentina Böhm wrote:
> What would you recommend regarding authentication? Is it ok if users of
> my app are committing data on my behalf or should all users have their
> own OSM account?

Using a central account for aggregated user contributions is
discouraged; if some of your users commit vandalism or add data from
illegal sources, it becomes very difficult to separate the good from the
bad. Also, other OSM mappers might want to contact the user who has
added or changed something.

> If users have their own account, is it possible and ok if I prepare the
> data with my algorithm and commit the data on their behalf?

This is possible with OAuth authentication, and other programs like
wheelmap or StreetComplete already do something similar. Although I am a
little worried when you say "prepare the data with your algorithm" - you
should always make sure the user has full control over what they submit,
you should not submit something that might come as a surprise to the
user later.

> I’m also interested in feedback about the idea. Are there similar
> projects? What do you think of my idea?

"Topical" editors - software that allows specialist contributions in
niche areas - can be a valuable addition to the OSM editing landscape,
so in general I think it sounds like a good idea!

Best
Frederik

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

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

Re: [OSM-talk-fr] opening_hours contre les parcs parisiens

[Philippe Verdy]

D'ailleurs à mon avis je supprimerais complètement le "off" de l'attribut
"opening_hours=*" (il complique tout inutilement)

A la place je mettrais un autre attribut "closing_hours=*" (avec la même
syntaxe, mais là aussi sans "off" ni "on") et qui n'a de sens que s'il est
associé à un attribut "opening_hours=*" (à interpréter en premier, le
"closing_hours=*" n'apportant que des exceptions).

Dans ce cas plus d’ambiguïté du tout, plus besoin de virgule (encore moins
le "|" inutile), le point-virgule suffit à tout, chacune des deux listes
étant écrite dans un ordre quelconque.


Le ven. 26 oct. 2018 à 14:31, Philippe Verdy  a écrit :

> Note: si tous les éléments sont "on" (il n'y a aucun "off") utiliser la
> virgule ou le point-virgule ne donnera aucune différence puisque l'ordre
> n'est alors pas significatif. C'est pour ça que le point-virgule est aussi
> autorisé, mais il est à éviter totalement s'il y a même un seul élément
> "off" (qu'on doit placer à la fin, donc toujours après une virgule).
>
>
> Le ven. 26 oct. 2018 à 14:28, Philippe Verdy  a
> écrit :
>
>>
>>
>> Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  a écrit :
>>
>>> On Thu, 25 Oct 2018, Megan Parat wrote:
>>> [...]
>>> > En utilisant les particularités des séparateurs de règles, et un ordre
>>> > particulier, j'ai cette expression d'opening_hours qui comporte 161
>>> > caractères :
>>> >
>>> > 08:00-17:45; PH,Sa,Su 08:00-09:00 off, Mar 01-Mar Su[-1] 17:45-19:00,
>>> > Oct 01-Oct Su[-1] 17:45-19:30, Mar Su[-1]-Apr 30,Sep 17:45-20:30, May
>>> > 01-Aug 31 17:45-21:30
>>> >
>>> > Je crois qu'elle est valide.
>>>
>>> Joli !
>>> Après consultation de la "spécification complète" (dont je ne trouve le
>>> lien que dans la version anglaise du wiki), je crois aussi qu'elle est
>>> valide.
>>>
>>> Là où la page opening_hours laisse penser que la virgule ne peut être
>>> utilisée que dans les listes (d'années, de mois ou d'heures), la
>>> spécification complète indique qu'on peut l'utiliser partout où on peut
>>> utiliser le point-virgule :
>>>
>>> |  opening_hours = 
>>> |  :  {  
>>> }
>>> |  any_rule_separator: ';' | ',' | '||'
>>>
>>
>> Pas tout à fait :
>> * le point-virgule dans un attribut indique une liste non-ordonnée (dont
>> les éléments peuvent être librement permutés sans changement
>> d'interprétation) : c'est valable normalement pour tout attribut OSM.
>> * alors que la virgule impose un ordre de priorité.
>>
>> De fait les éléments séparés par point-virgules doivent être indépendants
>> (ne pas se recouvrir, ou bien être équivalents sémantiquement)
>>
>> Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la
>> liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du
>> second (qui indique des horaires différents pour certaines dates).
>>
>> Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple,
>> où la virgule dans un liste vient ajouter des éléments (ajouter des plages
>> horaires, ou en retirer avec "off")  à la liste en modifiant les précédents.
>>
>> La syntaxe utilisée ci-dessus est en fait ambiguë puisque la partie
>> séparée par des virgules (une fois le point-virgule converti en virgule)
>> contient les éléments suivants, qui doivent être lus dans l'ordre, chaque
>> élément modifiant le calendrier:
>> - au départ (liste vide), par défaut tout est fermé, tous les jours
>> quelque soit l'heure
>> - "08:00-17:45" : ajoute l'ouverture tous les jours à cette plage horaire
>> (cela remplace la fermeture
>> - "PH" : n'indique aucune plage horaire, donc veut dire que cela ajoute
>> l'ouverture toute la journée (24/24) des jours fériés
>> - "Sa" : n'indique aucune plage horaire, donc veut dire  que cela ajoute
>> l'ouverture toute la journée (24/24) de tous les samedis (fériés ou pas)
>> - "Su 08:00-09:00 off" : exclue de tout ce qui précède l'ouverture de 8h
>> à 9h si c'est un dimanche (donc le dimanche reste ouvert 23h sur 24 si
>> c'est férié, sinon ouvert seulement de 9h à 17h45)
>> - "Mar 01-Mar Su[-1] 17:45-19:00 : ajoute l'ouverte à cette plage horaire
>> tous les jours de entre le 1er du mois de mars et le dernier dimanche de
>> mars (n'a pas d'effet sur les dimanches fériée de mars, mais les autres
>> dimanches non fériés de mars ont une ouverture allongée)
>> - etc. (autres plages horaires ajoutées pour d'autres dates)
>>
>> Cette liste ne peut pas être librement permutée (notamment entre les
>> éléments contenant des "off" et ceux qui sont "on" par défaut), mais peut
>> être permutée entre deux éléments "on" s'il n'y a aucun élément "off" entre
>> les deux.
>>
>> Et c'est le cas ici car tous les éléments sont "on" (par défaut), SAUF le
>> 4e (Su 08:00-09:00) qui est "off".
>>
>> Hors je ne pense pas que ce soit ce que tu voulais (pas convaincu que tu
>> voulais mettre des jours fériés avec une ouverture 24/24 (ou 23/24 le
>> dimanche). Si tu retire le 4e élément (Su 08:00-09:00 off), tous les autres
>> éléments sont librement permutables puisqu'ils sont tous "on" par 

Re: [OSM-talk] Mobile Application for optimizing OSM ski area data

[Maarten Deen]

On 2018-10-26 14:22, Valentina Böhm wrote:


What would you recommend regarding authentication? Is it ok if users
of my app are committing data on my behalf or should all users have
their own OSM account?


I would not let users edit on your account. Then you will get the 
comments and possibly grief if edits are not correct.
I would require the users to use their OSM account or give the 
possibility to add an anonymous note. You can use OAuth for 
authentication.


Regards,
Maarten

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

... o anche lasciare height e circumference e mettere una note del tipo 
"note=Height and circumference as of 2018-10-26"


On 2018-10-26 14:46, Sergio Manzi wrote:
>
> Concordo, ma d'altro canto sono info che potrebbero avere una certa 
> rilevanza, sopratutto quando si tratta di "misure eccezionali" che potrebbe 
> essere interessante segnalare. Forse meglio in note=* o note:it=*  ?
>
>
> On 2018-10-26 14:40, Gabriele Sani wrote:
>> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo non 
>> e' esattamente corretto: cioe', in teoria si mappa cio' che non e' effimero 
>> (o almeno che potrebbe non esserlo). Le misure di un albero, altezza e 
>> circonferenza, cambieranno PER FORZA nel corso del tempo...
>>
>> Il giorno ven 26 ott 2018 alle ore 14:27 Sergio Manzi > > ha scritto:
>>
>> Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"
>>
>> Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa 
>> quando (/com'è naturale/) l'albero cresce? Serve un riferimento temporale 
>> che stabilisca quando le misure sono state fatte?
>>
>> "ele" può anche andare bene, ma in realtà sembra essere più pensato per 
>> le montagne. E' diffuso l'utilizzo di questa key per altre features?
>>
>> Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it": 
>> sono tutte informazioni ridondanti e derivabili da un "look-up" sulla base 
>> della chiave "taxon".
>>
>> Ciao!
>>
>> Sergio
>>
>>
>> On 2018-10-26 14:14, Cascafico Giovanni wrote:
>>> Che ne dite di questo [1] tagging?
>>>
>>> natural=tree
>>> ref=28/l483/UD/06
>>> circumference=3 
>>> ele=170 
>>> height=20 
>>> leaf_cycle=deciduous 
>>> leaf_type=broadleaved 
>>> taxon=Cupressus cashmeriana 
>>> taxon:it=Cipresso del Cashmere 
>>>
>>>
>>> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Talk-it mailing list
>>> Talk-it@openstreetmap.org 
>>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>



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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Concordo, ma d'altro canto sono info che potrebbero avere una certa rilevanza, 
sopratutto quando si tratta di "misure eccezionali" che potrebbe essere 
interessante segnalare. Forse meglio in note=* o note:it=*  ?


On 2018-10-26 14:40, Gabriele Sani wrote:
> A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo non 
> e' esattamente corretto: cioe', in teoria si mappa cio' che non e' effimero 
> (o almeno che potrebbe non esserlo). Le misure di un albero, altezza e 
> circonferenza, cambieranno PER FORZA nel corso del tempo...
>
> Il giorno ven 26 ott 2018 alle ore 14:27 Sergio Manzi  > ha scritto:
>
> Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"
>
> Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa 
> quando (/com'è naturale/) l'albero cresce? Serve un riferimento temporale che 
> stabilisca quando le misure sono state fatte?
>
> "ele" può anche andare bene, ma in realtà sembra essere più pensato per 
> le montagne. E' diffuso l'utilizzo di questa key per altre features?
>
> Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it": 
> sono tutte informazioni ridondanti e derivabili da un "look-up" sulla base 
> della chiave "taxon".
>
> Ciao!
>
> Sergio
>
>
> On 2018-10-26 14:14, Cascafico Giovanni wrote:
>> Che ne dite di questo [1] tagging?
>>
>> natural=tree
>> ref=28/l483/UD/06
>> circumference=3 
>> ele=170 
>> height=20 
>> leaf_cycle=deciduous 
>> leaf_type=broadleaved 
>> taxon=Cupressus cashmeriana 
>> taxon:it=Cipresso del Cashmere 
>>
>>
>> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>>
>>
>>
>>
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-it
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



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

Re: [Talk-cz] AlzaBox, jak mapovat?

[Jan Sten Adámek]

Mapoval bych to jako packstation:
https://wiki.openstreetmap.org/wiki/DE:Packstation#Tagging

Sten

Dne pátek 26. října 2018 14:35:53 CEST, majka napsal(a):
> U schránek jsem narazila na jednu, která mě v datech irituje už delší dobu
> - je zadaná jako name=AlzaBox , je to v Říčanech.
> Pokud je to opravdu AlzaBox, tak to určitě není poštovní schránka.
> 
> Jak by to tyhle boxy měly být zmapované správně?
> 
> Majka





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

Re: [Talk-cz] AlzaBox, jak mapovat?

[mahdi1...@centrum.cz]

Ahoj,

co toto? https://wiki.openstreetmap.org/wiki/Tag:vending%3Dparcel_pickup

mahdi
majka wrote:
U schránek jsem narazila na jednu, která mě v datech irituje už delší 
dobu - je zadaná jako name=AlzaBox , je to v Říčanech.

Pokud je to opravdu AlzaBox, tak to určitě není poštovní schránka.

Jak by to tyhle boxy měly být zmapované správně?

Majka


___
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-it] poliambulatorio e centro medicina dello sport

[Sergio Manzi]

Come si dice dalle mie parti... /me par ben/!  :-)


On 2018-10-26 14:17, demon.box wrote:
> ciao, un poliambulatorio medico dove ci sono vari medici che effettuano
> visite specialistiche di vario genere (c'è un neurologo, un cardiologo,
> ecc.) lo taggo come amenity=clinic ?
>
> e nel caso invece di un centro con più dottori che eseguono però
> esclusivamente visite per il rilascio del certificato all'attività sportiva
> agonistica e non agonistica, lo taggo come amenity=doctors ?
>
> grazie
>
> --enrico
>
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it



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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Gabriele Sani]

A mio avvisto "mappare" le misure di un qualcosa che le cambia col tempo
non e' esattamente corretto: cioe', in teoria si mappa cio' che non e'
effimero (o almeno che potrebbe non esserlo). Le misure di un albero,
altezza e circonferenza, cambieranno PER FORZA nel corso del tempo...

Il giorno ven 26 ott 2018 alle ore 14:27 Sergio Manzi  ha
scritto:

> Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"
>
> Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa
> quando (*com'è naturale*) l'albero cresce? Serve un riferimento temporale
> che stabilisca quando le misure sono state fatte?
>
> "ele" può anche andare bene, ma in realtà sembra essere più pensato per le
> montagne. E' diffuso l'utilizzo di questa key per altre features?
>
> Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it": sono
> tutte informazioni ridondanti e derivabili da un "look-up" sulla base della
> chiave "taxon".
>
> Ciao!
>
> Sergio
>
> On 2018-10-26 14:14, Cascafico Giovanni wrote:
>
> Che ne dite di questo [1] tagging?
>
> natural=tree
> ref=28/l483/UD/06
> circumference=3 
> ele=170 
> height=20 
> leaf_cycle=deciduous 
> leaf_type=broadleaved 
> taxon=Cupressus cashmeriana 
> taxon:it=Cipresso del Cashmere 
>
>
> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>
>
>>
>>
>
> ___
> Talk-it mailing 
> listTalk-it@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-it
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-cz] AlzaBox, jak mapovat?

[majka]

U schránek jsem narazila na jednu, která mě v datech irituje už delší dobu
- je zadaná jako name=AlzaBox , je to v Říčanech.
Pokud je to opravdu AlzaBox, tak to určitě není poštovní schránka.

Jak by to tyhle boxy měly být zmapované správně?

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

Re: [OSM-talk-fr] opening_hours contre les parcs parisiens

[Philippe Verdy]

Note: si tous les éléments sont "on" (il n'y a aucun "off") utiliser la
virgule ou le point-virgule ne donnera aucune différence puisque l'ordre
n'est alors pas significatif. C'est pour ça que le point-virgule est aussi
autorisé, mais il est à éviter totalement s'il y a même un seul élément
"off" (qu'on doit placer à la fin, donc toujours après une virgule).


Le ven. 26 oct. 2018 à 14:28, Philippe Verdy  a écrit :

>
>
> Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  a écrit :
>
>> On Thu, 25 Oct 2018, Megan Parat wrote:
>> [...]
>> > En utilisant les particularités des séparateurs de règles, et un ordre
>> > particulier, j'ai cette expression d'opening_hours qui comporte 161
>> > caractères :
>> >
>> > 08:00-17:45; PH,Sa,Su 08:00-09:00 off, Mar 01-Mar Su[-1] 17:45-19:00,
>> > Oct 01-Oct Su[-1] 17:45-19:30, Mar Su[-1]-Apr 30,Sep 17:45-20:30, May
>> > 01-Aug 31 17:45-21:30
>> >
>> > Je crois qu'elle est valide.
>>
>> Joli !
>> Après consultation de la "spécification complète" (dont je ne trouve le
>> lien que dans la version anglaise du wiki), je crois aussi qu'elle est
>> valide.
>>
>> Là où la page opening_hours laisse penser que la virgule ne peut être
>> utilisée que dans les listes (d'années, de mois ou d'heures), la
>> spécification complète indique qu'on peut l'utiliser partout où on peut
>> utiliser le point-virgule :
>>
>> |  opening_hours = 
>> |  :  {   }
>> |  any_rule_separator: ';' | ',' | '||'
>>
>
> Pas tout à fait :
> * le point-virgule dans un attribut indique une liste non-ordonnée (dont
> les éléments peuvent être librement permutés sans changement
> d'interprétation) : c'est valable normalement pour tout attribut OSM.
> * alors que la virgule impose un ordre de priorité.
>
> De fait les éléments séparés par point-virgules doivent être indépendants
> (ne pas se recouvrir, ou bien être équivalents sémantiquement)
>
> Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la
> liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du
> second (qui indique des horaires différents pour certaines dates).
>
> Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple,
> où la virgule dans un liste vient ajouter des éléments (ajouter des plages
> horaires, ou en retirer avec "off")  à la liste en modifiant les précédents.
>
> La syntaxe utilisée ci-dessus est en fait ambiguë puisque la partie
> séparée par des virgules (une fois le point-virgule converti en virgule)
> contient les éléments suivants, qui doivent être lus dans l'ordre, chaque
> élément modifiant le calendrier:
> - au départ (liste vide), par défaut tout est fermé, tous les jours
> quelque soit l'heure
> - "08:00-17:45" : ajoute l'ouverture tous les jours à cette plage horaire
> (cela remplace la fermeture
> - "PH" : n'indique aucune plage horaire, donc veut dire que cela ajoute
> l'ouverture toute la journée (24/24) des jours fériés
> - "Sa" : n'indique aucune plage horaire, donc veut dire  que cela ajoute
> l'ouverture toute la journée (24/24) de tous les samedis (fériés ou pas)
> - "Su 08:00-09:00 off" : exclue de tout ce qui précède l'ouverture de 8h à
> 9h si c'est un dimanche (donc le dimanche reste ouvert 23h sur 24 si c'est
> férié, sinon ouvert seulement de 9h à 17h45)
> - "Mar 01-Mar Su[-1] 17:45-19:00 : ajoute l'ouverte à cette plage horaire
> tous les jours de entre le 1er du mois de mars et le dernier dimanche de
> mars (n'a pas d'effet sur les dimanches fériée de mars, mais les autres
> dimanches non fériés de mars ont une ouverture allongée)
> - etc. (autres plages horaires ajoutées pour d'autres dates)
>
> Cette liste ne peut pas être librement permutée (notamment entre les
> éléments contenant des "off" et ceux qui sont "on" par défaut), mais peut
> être permutée entre deux éléments "on" s'il n'y a aucun élément "off" entre
> les deux.
>
> Et c'est le cas ici car tous les éléments sont "on" (par défaut), SAUF le
> 4e (Su 08:00-09:00) qui est "off".
>
> Hors je ne pense pas que ce soit ce que tu voulais (pas convaincu que tu
> voulais mettre des jours fériés avec une ouverture 24/24 (ou 23/24 le
> dimanche). Si tu retire le 4e élément (Su 08:00-09:00 off), tous les autres
> éléments sont librement permutables puisqu'ils sont tous "on" par défaut :
> ils forment une combinaison (en "ou") de tous les horaires indiquer, ne
> peuvent pas se contredire entre eux mais peuvent se recouvrir mutuellement.
>
> Si tu utilises le ";" les éléments doivent être mutuellement exclusifs
> entre les dates concernées, mais c'est encore sujet à ambiguïté (le
> point-virgule ne devrait dont pas être utilisé du tout, la virgule en
> revanche garantie et impose l'ordre d'interprétation).
>
> En général il est plus simple de concevoir les opening_hours en listant
> d'abord au début tous les éléments "on" (par défaut) dans un ordre
> quelconque pour ajouter des horaires d'ouverture, et seulement ensuite en
> listant tous les éléments "off" aux aussi dans un ordre quelconque pour
> retirer 

Re: [OSM-talk-fr] opening_hours contre les parcs parisiens

[Philippe Verdy]

Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  a écrit :

> On Thu, 25 Oct 2018, Megan Parat wrote:
> [...]
> > En utilisant les particularités des séparateurs de règles, et un ordre
> > particulier, j'ai cette expression d'opening_hours qui comporte 161
> > caractères :
> >
> > 08:00-17:45; PH,Sa,Su 08:00-09:00 off, Mar 01-Mar Su[-1] 17:45-19:00,
> > Oct 01-Oct Su[-1] 17:45-19:30, Mar Su[-1]-Apr 30,Sep 17:45-20:30, May
> > 01-Aug 31 17:45-21:30
> >
> > Je crois qu'elle est valide.
>
> Joli !
> Après consultation de la "spécification complète" (dont je ne trouve le
> lien que dans la version anglaise du wiki), je crois aussi qu'elle est
> valide.
>
> Là où la page opening_hours laisse penser que la virgule ne peut être
> utilisée que dans les listes (d'années, de mois ou d'heures), la
> spécification complète indique qu'on peut l'utiliser partout où on peut
> utiliser le point-virgule :
>
> |  opening_hours = 
> |  :  {   }
> |  any_rule_separator: ';' | ',' | '||'
>

Pas tout à fait :
* le point-virgule dans un attribut indique une liste non-ordonnée (dont
les éléments peuvent être librement permutés sans changement
d'interprétation) : c'est valable normalement pour tout attribut OSM.
* alors que la virgule impose un ordre de priorité.

De fait les éléments séparés par point-virgules doivent être indépendants
(ne pas se recouvrir, ou bien être équivalents sémantiquement)

Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la
liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du
second (qui indique des horaires différents pour certaines dates).

Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple,
où la virgule dans un liste vient ajouter des éléments (ajouter des plages
horaires, ou en retirer avec "off")  à la liste en modifiant les précédents.

La syntaxe utilisée ci-dessus est en fait ambiguë puisque la partie séparée
par des virgules (une fois le point-virgule converti en virgule) contient
les éléments suivants, qui doivent être lus dans l'ordre, chaque élément
modifiant le calendrier:
- au départ (liste vide), par défaut tout est fermé, tous les jours quelque
soit l'heure
- "08:00-17:45" : ajoute l'ouverture tous les jours à cette plage horaire
(cela remplace la fermeture
- "PH" : n'indique aucune plage horaire, donc veut dire que cela ajoute
l'ouverture toute la journée (24/24) des jours fériés
- "Sa" : n'indique aucune plage horaire, donc veut dire  que cela ajoute
l'ouverture toute la journée (24/24) de tous les samedis (fériés ou pas)
- "Su 08:00-09:00 off" : exclue de tout ce qui précède l'ouverture de 8h à
9h si c'est un dimanche (donc le dimanche reste ouvert 23h sur 24 si c'est
férié, sinon ouvert seulement de 9h à 17h45)
- "Mar 01-Mar Su[-1] 17:45-19:00 : ajoute l'ouverte à cette plage horaire
tous les jours de entre le 1er du mois de mars et le dernier dimanche de
mars (n'a pas d'effet sur les dimanches fériée de mars, mais les autres
dimanches non fériés de mars ont une ouverture allongée)
- etc. (autres plages horaires ajoutées pour d'autres dates)

Cette liste ne peut pas être librement permutée (notamment entre les
éléments contenant des "off" et ceux qui sont "on" par défaut), mais peut
être permutée entre deux éléments "on" s'il n'y a aucun élément "off" entre
les deux.

Et c'est le cas ici car tous les éléments sont "on" (par défaut), SAUF le
4e (Su 08:00-09:00) qui est "off".

Hors je ne pense pas que ce soit ce que tu voulais (pas convaincu que tu
voulais mettre des jours fériés avec une ouverture 24/24 (ou 23/24 le
dimanche). Si tu retire le 4e élément (Su 08:00-09:00 off), tous les autres
éléments sont librement permutables puisqu'ils sont tous "on" par défaut :
ils forment une combinaison (en "ou") de tous les horaires indiquer, ne
peuvent pas se contredire entre eux mais peuvent se recouvrir mutuellement.

Si tu utilises le ";" les éléments doivent être mutuellement exclusifs
entre les dates concernées, mais c'est encore sujet à ambiguïté (le
point-virgule ne devrait dont pas être utilisé du tout, la virgule en
revanche garantie et impose l'ordre d'interprétation).

En général il est plus simple de concevoir les opening_hours en listant
d'abord au début tous les éléments "on" (par défaut) dans un ordre
quelconque pour ajouter des horaires d'ouverture, et seulement ensuite en
listant tous les éléments "off" aux aussi dans un ordre quelconque pour
retirer certains horaires ajoutés par la première liste (donc mentionner
des exceptions à la première liste) : il n'y a alors aucun risque
d'ambiguité.

L'ennui de la syntaxe actuelle est qu'elle oblige à répéter explicitement
la propriété "off" pour chacun des éléments "off" de la seconde liste; il
aurait juste suffit d'imposer l'ordre "liste de tous les horaires
d'ouverture", puis un mot clé "off" suivi de la liste des exceptions où des
horaires sont fermés). On aurait eu une syntaxe allégé (plus d'obligation
de répéter "off", plus facile à interpréter, et jamais ambiguë

Mais 

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Sergio Manzi]

Perfettamente d'accordo sul "taxon=Cupressus cashmeriana"

Anche "circumference" e "height" mi sembrano corrette, ma... cosa si fa quando 
(/com'è naturale/) l'albero cresce? Serve un riferimento temporale che 
stabilisca quando le misure sono state fatte?

"ele" può anche andare bene, ma in realtà sembra essere più pensato per le 
montagne. E' diffuso l'utilizzo di questa key per altre features?

Non sono invece d'accordo con "leaf_cycle", "leaf_type" e "taxon:it": sono 
tutte informazioni ridondanti e derivabili da un "look-up" sulla base della 
chiave "taxon".

Ciao!

Sergio


On 2018-10-26 14:14, Cascafico Giovanni wrote:
> Che ne dite di questo [1] tagging?
>
> natural=tree
> ref=28/l483/UD/06
> circumference=3 
> ele=170 
> height=20 
> leaf_cycle=deciduous 
> leaf_type=broadleaved 
> taxon=Cupressus cashmeriana 
> taxon:it=Cipresso del Cashmere 
>
>
> [1] http://audit.osmz.ru/run/AM-RAFVG/33
>
>
>
>
>
> ___
> 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

[OSM-talk] Mobile Application for optimizing OSM ski area data

[Valentina Böhm]

I am planning to develop an mobile app to optimize ski area data provided by 
OSM. The user should be able to use the app for locating him- or herself in a 
ski area and have a look at all the different slopes and lifts and all their 
details. But the user should also be able to optimize the data of the ski area. 
First of all for the better experience when using the app for navigating. But 
also for providing OSM optimized and more detailed data about ski areas.

If a user wants to optimize the data he or she can either manually change the 
data, for example, edit the name or reference number of a slope or lift. Or he 
or she can provide their movement data by tracking it with the application 
while skiing. The tracked data should, in the end, help to fill gaps between 
slopes or slopes and lifts. Or even detect new unknown slopes.

What would you recommend regarding authentication? Is it ok if users of my app 
are committing data on my behalf or should all users have their own OSM account?

If users have their own account, is it possible and ok if I prepare the data 
with my algorithm and commit the data on their behalf?

In general, what is your recommendation regarding this kind of third-party 
integration? Are special API tokens provided for third-party apps?

I’m also interested in feedback about the idea. Are there similar projects? 
What do you think of my idea?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-it] poliambulatorio e centro medicina dello sport

[demon.box]

ciao, un poliambulatorio medico dove ci sono vari medici che effettuano
visite specialistiche di vario genere (c'è un neurologo, un cardiologo,
ecc.) lo taggo come amenity=clinic ?

e nel caso invece di un centro con più dottori che eseguono però
esclusivamente visite per il rilascio del certificato all'attività sportiva
agonistica e non agonistica, lo taggo come amenity=doctors ?

grazie

--enrico






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

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

Re: [Talk-it] [Tagging] alberi (era albereri monumentali: quale licenza?)

[Cascafico Giovanni]

Che ne dite di questo [1] tagging?

natural=tree
ref=28/l483/UD/06
circumference=3 
ele=170 
height=20 
leaf_cycle=deciduous 
leaf_type=broadleaved 
taxon=Cupressus cashmeriana 
taxon:it=Cipresso del Cashmere 


[1] http://audit.osmz.ru/run/AM-RAFVG/33


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

Re: [OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

[Nicolas Bétheuil]

J'ai été poser la question

https://ask.openrouteservice.org/t/roadworks-and-how-to-handle-it/45
https://groups.google.com/forum/#!topic/osm-android-bikerouting/bsRYArj8fCM
https://groups.google.com/forum/#!topic/opentripplanner-users/ryjK46IoOY8

pour commencer

Le ven. 26 oct. 2018 à 08:28, Phyks  a écrit :

> Merci ! J'avais pensé à verser les signalements de cyclassist dans OED
> (et utiliser OED plutôt qu'une base différente pour cyclassist), mais je
> n'étais pas sûr que ça ait parfaitement sa place dans OED. J'avais eu un
> peu de mal à trouver de la doc / des points de contact aussi :/
>
> Mais c'est quelque chose qui pourrait changer facilement, il y a de quoi
> faire un dump des signalements de Cycl'Assist facilement.
>
>
> Concernant les travaux, pour l'instant je récupère des points libres
> mais je voudrais reprendre ça pour les associer à des objets OSM. La
> plupart des sources fournissent une aire touchée par les travaux et il
> suffit alors de chercher les intersections avec les objets OSM. C'est
> sur ma liste de trucs à faire.
>
>
> Concernant les modes de transport affectés (ou les fermetures partielles
> / totales etc), c'est très souvent donné dans un champ texte libre, avec
> toutes les variations possibles du coup… rien de normalisé et de facile
> à réutiliser j'ai l'impression :/
>
>
> Pour réutiliser ça dans un calculateur d'itinéraires, je sais que
> certains proposent d'éviter des zones (OpenRouteService proposé par JB,
> brouter aussi). Du coup, pas besoin d'associer ça précisément à un objet
> OSM. Le seul problème que je vois avec les zones à éviter c'est que ces
> zones de travaux ne sont pas forcément "à éviter" mais plutôt "à
> pénaliser", du moins tant que l'information précise des éléments
> (trottoirs, chaussée, fermeture partielle ou totale) n'est pas bien
> connu. Des travaux sur un trottoir impliquent probablement des
> complications pour les automobilistes, mais il n'y a aucune raison a
> priori d'éviter totalement la zone.
>
> --
> Phyks
>
> Le 25/10/2018 à 10:45, Nicolas Bétheuil a écrit :
> > Classe ! Félicitations !
> > J'adore la richesse d'OSM ! Ou de verser cyclassist dans OED ? L'api
> d'OED
> > est publique.
> > Dire si ça concerne que les vélos où aussi les voitures, les piétons,
> > mobilité réduite ?
> > Après pour que ce soit exploitable dans OSM par un calculateur
> > d'itinéraire, il faut rattacher ça à des objets OSM pour les tagguer ?
> >
> > Le jeu. 25 oct. 2018 à 09:33, Phyks  a écrit :
> >
> >> Salut,
> >>
> >>> Vu que chaque ville à sa propre base / api ça me paraît compliqué que
> les
> >>> calculateurs d'itinéraire le prenne en compte nottament avec les
> >> arguments
> >>> déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import dans OSM
> >>> mais que des contributeurs revalident ces données, modifier OSM me
> parait
> >>> aussi compliqué en automatique : ce n'est pas qu'ajouter un POI, faire
> >> une
> >>> conflation ... les différents chantiers ont différents impact donc à
> >>> tagguer différemment.
> >>
> >> J'ai
> >>
> https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
> >> en stock avec toutes les opendata sur les travaux que j'ai trouvées en
> >> France pour l'instant (et qui les uniformise un minimum).
> >>
> >> Ça devrait être possible de reprendre un script du genre et de
> >> l'injecter dans OED, non ?
> >>
> >> --
> >> Phyks
> >>
> >>
> >>
> >> ___
> >> Talk-fr mailing list
> >> Talk-fr@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-fr
> >>
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-cz] Nahrávani fotek do Fody přes osmap.cz

[Tom Ka]

Diky Mariane, nasazeno:

https://openstreetmap.cz/#map=15/49.3288/16.7986=xG

Bye


pá 26. 10. 2018 v 10:58 odesílatel Marián Kyral  napsal:

> Může být tohle?
>
>
> Marián
>
> -- Původní e-mail --
> Od: Tom Ka 
> Komu: OpenStreetMap Czech Republic 
> Datum: 26. 10. 2018 10:19:33
> Předmět: Re: [Talk-cz] Nahrávani fotek do Fody přes osmap.cz
>
> Do kodu doplnim, nakreslis tu ikonu?
>
> pá 26. 10. 2018 v 8:51 odesílatel xkomc...@centrum.cz 
> napsal:
>
> Ahoj,
>
>
> díky moc. Mohl bych ještě poprosit o jinou ikonu pro body záchrany? Teď se
> zobrazují stejně jako rozcestníky a mate to.
>
>
> Díky
>
> Jirka Komárek
>
> On 26.10.2018 08:41, Tom Ka wrote:
>
> Ahoj, v rámci rozdělení Fody tagů pro cyklistiku pro 'tereni' a 'silnicni'
> cyklistiku (viz diskuze dříve) jsem upravil i rozhraní pro nahrávání fotek
> do Fody na osmap.cz. Kromě přidaného tagu 'silnicni' pro varianty
> rozcestníku jsem doplnil i dvě často používané varianty fotek do možností
> 'Objekt na fotografii'  - nově je tak jednodušší nahrávat přehledové fotky
> a body záchrany.
>
> Zároveň tímto prosím při nahrávání cyklistických fotek rozlišovat oba typy
> značení - ukázky viz.
> https://openstreetmap.cz/git/tom.k/Fody/wiki/PhotosExamples
>
> Konec hlášení :-)
>
>
> ___
> 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
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-ja] 日本の「Acces / 交通手段による制限 - 陸上交通 車両種別アクセス」について

[tomoya muramoto]

基本的な方向性に賛同します。

(1)`transportation_mode:motorcar=大型` よりも、`motorcar:transportation_mode=大型`
のほうが良いのではないでしょうか？
(例えば、tunnel=yesに詳細情報をつける際は、tunnel:nameの順序となります)

(2)シンプルに、`motorcar:type=大型`または`motorcar:type:jp=大型`ではいかがでしょうか。もっとシンプルに、`vehicle:type:jp=大型`はいかがでしょうか。
`foot`等が適用範囲に含まれるのであれば`transportation`とするのも理解できますが、「交通標識で示される範囲」にて「OSMでは「vehicle=*」以下が範囲です。」と記載されており、`foot`等は適用範囲外です。

(3)「自動車」の定義が`motorcar`+`motorcycle`となっていますが、`motor_vehicle`でよいのではないでしょうか。

(4)例えば特定中乗をタグ付けする際に、`(motorcar AND (NOT
goods)),transportation_mode:motorcar=特定中乗`
と入れるのは大変だと思います。`motorcar,transportation_mode:motorcar=特定中乗`だけにして、`NOT
goods`は別途impliesを定めてはいかがでしょうか。

(5)石野様が言及されていますが、Japan taggingのImpliesに不明瞭な点があるのであれば、まずはJapan
tagging改定の合意をとったほうが良いのではないでしょうか。

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

Re: [Talk-cz] Vrstevnice v Maperitivu

[kayle]

Pre 10m je to 
generate-contours interval=10

Samozrejme treba si upravit aj styl.


Na piatok, 26. októbra 2018 11:34:35 CEST Martina napísali:
> Ahoj,
> pracuji s OSM daty v Maperitivu a  potřebovala bych upravit rozestup
> vrstevnic. Nevíte kde se dá upravit nastavení vrstevnic?





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

Re: [Talk-GB] Facebook Map Query - Thames rendered as Thanames

[Dave F]

I'd be more concerned that on Facebook's mobile website (Android/Silk 
Browser) that image clicks through to Google Maps.


Cheers
DaveF

On 26/10/2018 01:44, Steve Doerr wrote:
A user on the Facebook group 'UK Places Editors' has commented on the 
fact that some maps on Facebook pages in the vicinity of Putney Bridge 
(London) show the River Thames as 'Thanames'. See, for example, 
https://www.facebook.com/pages/Putney-Bridge/103150243057869



A bit of browser debugging shows that it's accessing the URL 
https://external-lhr3-1.xx.fbcdn.net/static_map.php?v=1013_provider=2=324x160=15=51.46701240%2C-0.21317368=en_GB=2



Note the parameter _provider=2


Can anyone shed light on what tile service is being used here and what 
could be causing the Thanames name to appear? I can see that adjacent 
tiles rendered at different times, so that the label 'Thames' occurs 
in a different position, could cause something that looks like 
'Thanames' when they are joined together, but I can't produce any 
evidence of this.






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

[Talk-cz] Vrstevnice v Maperitivu

[Martina]

Ahoj,
pracuji s OSM daty v Maperitivu a  potřebovala bych upravit rozestup
vrstevnic. Nevíte kde se dá upravit nastavení vrstevnic?___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-es] Calles residenciales en Madrid

[dcapillae]

Hola, Ikanian.

Como dice Polyglot, es suficiente con añadir «oneway:bicycle=no» para
indicar que las bicis pueden circular indistintamente en ambos sentidos a lo
largo de una vía de sentido único («oneway=yes»). No hace falta nada más.



-
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-lt] CartoCon 2018

[Tomas Straupis]

Sveiki

  Šių metų lapkričio 30d. Lietuvos kartografų draugija kartu su VU
organizuoja konferenciją CartoCon 2018.
  Bus ir mūsų pranešimų apie vektorinius žemėlapius.
  Bus ir praktinė sesija su vektoriniais žemėlapiais.

  Taigi prisijunkite!

  https://cartocon.lt/

-- 
Tomas

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

Re: [Talk-cz] Nahrávani fotek do Fody přes osmap.cz

[Marián Kyral]

Může být tohle?









Marián



-- Původní e-mail --
Od: Tom Ka 
Komu: OpenStreetMap Czech Republic 
Datum: 26. 10. 2018 10:19:33
Předmět: Re: [Talk-cz] Nahrávani fotek do Fody přes osmap.cz
"
Do kodu doplnim, nakreslis tu ikonu?




pá 26. 10. 2018 v 8:51 odesílatel xkomc...@centrum.cz
(mailto:xkomc...@centrum.cz) mailto:xkomc...@centrum.cz)> napsal:

"

Ahoj,





díky moc. Mohl bych ještě poprosit o jinou ikonu pro body záchrany? Teď se
zobrazují stejně jako rozcestníky a mate to.




Díky

Jirka Komárek



On 26.10.2018 08:41, Tom Ka wrote:

"


Ahoj, v rámci rozdělení Fody tagů pro cyklistiku pro 'tereni' a 'silnicni'
cyklistiku (viz diskuze dříve) jsem upravil i rozhraní pro nahrávání fotek
do Fody na osmap.cz(http://osmap.cz). Kromě přidaného tagu 'silnicni' pro
varianty rozcestníku jsem doplnil i dvě často používané varianty fotek do
možností 'Objekt na fotografii'  - nově je tak jednodušší nahrávat
přehledové fotky a body záchrany.




Zároveň tímto prosím při nahrávání cyklistických fotek rozlišovat oba typy
značení - ukázky viz. https://openstreetmap.cz/git/tom.k/Fody/wiki/
PhotosExamples(https://openstreetmap.cz/git/tom.k/Fody/wiki/PhotosExamples)





Konec hlášení :-)








___
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(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)
https://openstreetmap.cz/talkcz(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-GB] Facebook Map Query - Thames rendered as Thanames

[Robert Whittaker (OSM lists)]

On Fri, 26 Oct 2018 at 01:44, Steve Doerr  wrote:
> A user on the Facebook group 'UK Places Editors' has commented on the
> fact that some maps on Facebook pages in the vicinity of Putney Bridge
> (London) show the River Thames as 'Thanames'. See, for example,
> https://www.facebook.com/pages/Putney-Bridge/103150243057869
>
> A bit of browser debugging shows that it's accessing the URL
> https://external-lhr3-1.xx.fbcdn.net/static_map.php?v=1013_provider=2=324x160=15=51.46701240%2C-0.21317368=en_GB=2

I'm pretty sure that this is not a data issue, but a rendering issue,
cause by adjacent tiles being updated at different times and trying to
show the label in slightly different positions. Look closely at the
text and you'll see a slight discontinuity along a horizontal line
through the "n". Rather than being "Thanames" I think we're seeing the
upper tile showing "Tha" and the first part of an "m", and the lower
tile showing part of an "h" and then "ames".

Robert.

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

Re: [OSM-talk] Zoom to search results on the map

[Warin]

On 26/10/18 17:26, Maarten Deen wrote:
When you search on something in the searchbox on openstreetmap.org 
that returns multiple results, the map moves to the first result and 
when you hover over the result it displays a marker.
But for all the other results, you need to click to see where it is. 
This removes the search results and displays details of the object you 
clicked.  Suppose this is not what you're looking for, you now have to 
enter the search parameters again and nominatim now searches from the 
last point the map was centred at. So the search results differ from 
the first try. Now you have to remember what results you've looked at 
so you don't look at them again.


Is there no way to show the second, third, etc, result on the map 
without removing the search results?


Right click - open in a new window/tab. Works for google searchers too.

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

Re: [Talk-cz] Nahrávani fotek do Fody přes osmap.cz

[Tom Ka]

Do kodu doplnim, nakreslis tu ikonu?

pá 26. 10. 2018 v 8:51 odesílatel xkomc...@centrum.cz 
napsal:

> Ahoj,
>
>
> díky moc. Mohl bych ještě poprosit o jinou ikonu pro body záchrany? Teď se
> zobrazují stejně jako rozcestníky a mate to.
>
>
> Díky
>
> Jirka Komárek
>
> On 26.10.2018 08:41, Tom Ka wrote:
>
> Ahoj, v rámci rozdělení Fody tagů pro cyklistiku pro 'tereni' a 'silnicni'
> cyklistiku (viz diskuze dříve) jsem upravil i rozhraní pro nahrávání fotek
> do Fody na osmap.cz. Kromě přidaného tagu 'silnicni' pro varianty
> rozcestníku jsem doplnil i dvě často používané varianty fotek do možností
> 'Objekt na fotografii'  - nově je tak jednodušší nahrávat přehledové fotky
> a body záchrany.
>
> Zároveň tímto prosím při nahrávání cyklistických fotek rozlišovat oba typy
> značení - ukázky viz.
> https://openstreetmap.cz/git/tom.k/Fody/wiki/PhotosExamples
>
> Konec hlášení :-)
>
>
> ___
> 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

Re: [Talk-it] progetti: come funziona?

[Gabriele Sani]

Ottimo, ho abbozzato la cosa [1] e inizialmente creero' una tabella per
ogni sezione CAI. Poi la correzione delle relazioni (che si puo' fare da
casa) la faccio con calma, mentre per i cartelli segnavia e' meglio fare
rilevamenti sul posto!

Grazie ancora a tutti

[1] https://wiki.openstreetmap.org/wiki/Emilia_Romagna/Sentieri

Il giorno ven 26 ott 2018 alle ore 08:09 Alfredo Gattai <
alfredo.gat...@gmail.com> ha scritto:

> > https://wiki.openstreetmap.org/wiki/WikiProject_Italy/Sentieri
>>
>>
> +1
> si continuiamo il lavoro da qui che e' la pagina che fu creata apposta e
> che qualcuno continua ad aggiornare (io lo faccio per la Liguria)
>
>
>> > Purtroppo da parte del CAI stanno andando un po' a rilento, in molte
>> zone
>> > ancora non abbiamo nessun dato e in altre ci sono i sentieri inseriti ma
>> > raramente ho avuto conferma dal CAI che la relazione in OSM corrisponde
>> al
>> > loro percorso 'ufficiale', ma ci sto lavorando.
>>
>>
> Nel giro di qualche giorno verra' messo in piedi un tasking manager e
> verranno messi a disposizione dati CAI proprio per fare cio'. Pazientate
> ancora qualche giorno.
>
>
>> Per ora volevo limitarmi al CAI perche' sono socio da quest'anno e volevo
>> andare a parlare di persona con i vari responsabili della mia sezione
>> (Faenza). Ho visto che molti sentieri sono stati inseriti in OSM il
>> 01/01/2018, quindi qualcuno deve averci guardato "recentemente". L'unico
>> problema che ho trovato e' la sintassi, cioe' manca totalmente il tag name
>> nelle relazioni che e' invece spesso (erroneamente) sostituito da diversi
>> tag name nelle way che compongono il sentiero. Questa cosa la corrego in
>> armchair. In seguito l'idea sarebbe di mappare in loco i vari segnavia e da
>> quelli ricostruire i percorsi ufficiali. Grazie mille per l'imbeccata
>> comunque!
>>
>>
> In Emilia-Romagna abbiamo cominciato a lavorarci io e Dino senza contare
> quello fatto da altri, e' per questo che trovi gia' alcuni contenuti
>
> Alfredo
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] Nahrávani fotek do Fody přes osmap.cz

[xkomc...@centrum.cz]

Ahoj,


díky moc. Mohl bych ještě poprosit o jinou ikonu pro body záchrany? Teď 
se zobrazují stejně jako rozcestníky a mate to.



Díky

Jirka Komárek


On 26.10.2018 08:41, Tom Ka wrote:
Ahoj, v rámci rozdělení Fody tagů pro cyklistiku pro 'tereni' a 
'silnicni' cyklistiku (viz diskuze dříve) jsem upravil i rozhraní pro 
nahrávání fotek do Fody na osmap.cz . Kromě přidaného 
tagu 'silnicni' pro varianty rozcestníku jsem doplnil i dvě často 
používané varianty fotek do možností 'Objekt na fotografii'  - nově je 
tak jednodušší nahrávat přehledové fotky a body záchrany.


Zároveň tímto prosím při nahrávání cyklistických fotek rozlišovat oba 
typy značení - ukázky viz. 
https://openstreetmap.cz/git/tom.k/Fody/wiki/PhotosExamples


Konec hlášení :-)


___
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-GB] Facebook Map Query - Thames rendered as Thanames

[Andrew Black]

I have seen similar but can't recall where or which tile provider.  To
state obvious, it only occurs at certain zoom levels.
Once i realised it was probably transient I lost interest.


On Fri, 26 Oct 2018, 01:44 Steve Doerr,  wrote:

> A user on the Facebook group 'UK Places Editors' has commented on the
> fact that some maps on Facebook pages in the vicinity of Putney Bridge
> (London) show the River Thames as 'Thanames'. See, for example,
> https://www.facebook.com/pages/Putney-Bridge/103150243057869
>
>
> A bit of browser debugging shows that it's accessing the URL
>
> https://external-lhr3-1.xx.fbcdn.net/static_map.php?v=1013_provider=2=324x160=15=51.46701240%2C-0.21317368=en_GB=2
>
>
> Note the parameter _provider=2
>
>
> Can anyone shed light on what tile service is being used here and what
> could be causing the Thanames name to appear? I can see that adjacent
> tiles rendered at different times, so that the label 'Thames' occurs in
> a different position, could cause something that looks like 'Thanames'
> when they are joined together, but I can't produce any evidence of this.
>
>
> --
>
> Steve
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-cz] Nahrávani fotek do Fody přes osmap.cz

[Tom Ka]

Ahoj, v rámci rozdělení Fody tagů pro cyklistiku pro 'tereni' a 'silnicni'
cyklistiku (viz diskuze dříve) jsem upravil i rozhraní pro nahrávání fotek
do Fody na osmap.cz. Kromě přidaného tagu 'silnicni' pro varianty
rozcestníku jsem doplnil i dvě často používané varianty fotek do možností
'Objekt na fotografii'  - nově je tak jednodušší nahrávat přehledové fotky
a body záchrany.

Zároveň tímto prosím při nahrávání cyklistických fotek rozlišovat oba typy
značení - ukázky viz.
https://openstreetmap.cz/git/tom.k/Fody/wiki/PhotosExamples

Konec hlášení :-)
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

[Phyks]

Merci ! J'avais pensé à verser les signalements de cyclassist dans OED
(et utiliser OED plutôt qu'une base différente pour cyclassist), mais je
n'étais pas sûr que ça ait parfaitement sa place dans OED. J'avais eu un
peu de mal à trouver de la doc / des points de contact aussi :/

Mais c'est quelque chose qui pourrait changer facilement, il y a de quoi
faire un dump des signalements de Cycl'Assist facilement.


Concernant les travaux, pour l'instant je récupère des points libres
mais je voudrais reprendre ça pour les associer à des objets OSM. La
plupart des sources fournissent une aire touchée par les travaux et il
suffit alors de chercher les intersections avec les objets OSM. C'est
sur ma liste de trucs à faire.


Concernant les modes de transport affectés (ou les fermetures partielles
/ totales etc), c'est très souvent donné dans un champ texte libre, avec
toutes les variations possibles du coup… rien de normalisé et de facile
à réutiliser j'ai l'impression :/


Pour réutiliser ça dans un calculateur d'itinéraires, je sais que
certains proposent d'éviter des zones (OpenRouteService proposé par JB,
brouter aussi). Du coup, pas besoin d'associer ça précisément à un objet
OSM. Le seul problème que je vois avec les zones à éviter c'est que ces
zones de travaux ne sont pas forcément "à éviter" mais plutôt "à
pénaliser", du moins tant que l'information précise des éléments
(trottoirs, chaussée, fermeture partielle ou totale) n'est pas bien
connu. Des travaux sur un trottoir impliquent probablement des
complications pour les automobilistes, mais il n'y a aucune raison a
priori d'éviter totalement la zone.

-- 
Phyks

Le 25/10/2018 à 10:45, Nicolas Bétheuil a écrit :
> Classe ! Félicitations !
> J'adore la richesse d'OSM ! Ou de verser cyclassist dans OED ? L'api d'OED
> est publique.
> Dire si ça concerne que les vélos où aussi les voitures, les piétons,
> mobilité réduite ?
> Après pour que ce soit exploitable dans OSM par un calculateur
> d'itinéraire, il faut rattacher ça à des objets OSM pour les tagguer ?
> 
> Le jeu. 25 oct. 2018 à 09:33, Phyks  a écrit :
> 
>> Salut,
>>
>>> Vu que chaque ville à sa propre base / api ça me paraît compliqué que les
>>> calculateurs d'itinéraire le prenne en compte nottament avec les
>> arguments
>>> déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import dans OSM
>>> mais que des contributeurs revalident ces données, modifier OSM me parait
>>> aussi compliqué en automatique : ce n'est pas qu'ajouter un POI, faire
>> une
>>> conflation ... les différents chantiers ont différents impact donc à
>>> tagguer différemment.
>>
>> J'ai
>> https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
>> en stock avec toutes les opendata sur les travaux que j'ai trouvées en
>> France pour l'instant (et qui les uniformise un minimum).
>>
>> Ça devrait être possible de reprendre un script du genre et de
>> l'injecter dans OED, non ?
>>
>> --
>> Phyks
>>
>>
>>
>> ___
>> 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

[OSM-talk] Zoom to search results on the map

[Maarten Deen]

When you search on something in the searchbox on openstreetmap.org that 
returns multiple results, the map moves to the first result and when you 
hover over the result it displays a marker.
But for all the other results, you need to click to see where it is. 
This removes the search results and displays details of the object you 
clicked.  Suppose this is not what you're looking for, you now have to 
enter the search parameters again and nominatim now searches from the 
last point the map was centred at. So the search results differ from the 
first try. Now you have to remember what results you've looked at so you 
don't look at them again.


Is there no way to show the second, third, etc, result on the map 
without removing the search results?


Regards,
Maarten

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

Re: [Talk-it] progetti: come funziona?

[Alfredo Gattai]

>
> > https://wiki.openstreetmap.org/wiki/WikiProject_Italy/Sentieri
>
>
+1
si continuiamo il lavoro da qui che e' la pagina che fu creata apposta e
che qualcuno continua ad aggiornare (io lo faccio per la Liguria)


> > Purtroppo da parte del CAI stanno andando un po' a rilento, in molte zone
> > ancora non abbiamo nessun dato e in altre ci sono i sentieri inseriti ma
> > raramente ho avuto conferma dal CAI che la relazione in OSM corrisponde
> al
> > loro percorso 'ufficiale', ma ci sto lavorando.
>
>
Nel giro di qualche giorno verra' messo in piedi un tasking manager e
verranno messi a disposizione dati CAI proprio per fare cio'. Pazientate
ancora qualche giorno.


> Per ora volevo limitarmi al CAI perche' sono socio da quest'anno e volevo
> andare a parlare di persona con i vari responsabili della mia sezione
> (Faenza). Ho visto che molti sentieri sono stati inseriti in OSM il
> 01/01/2018, quindi qualcuno deve averci guardato "recentemente". L'unico
> problema che ho trovato e' la sintassi, cioe' manca totalmente il tag name
> nelle relazioni che e' invece spesso (erroneamente) sostituito da diversi
> tag name nelle way che compongono il sentiero. Questa cosa la corrego in
> armchair. In seguito l'idea sarebbe di mappare in loco i vari segnavia e da
> quelli ricostruire i percorsi ufficiali. Grazie mille per l'imbeccata
> comunque!
>
>
In Emilia-Romagna abbiamo cominciato a lavorarci io e Dino senza contare
quello fatto da altri, e' per questo che trovi gia' alcuni contenuti

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

Re: [Talk-cz] Fody - ukazky v dokumentaci

[Tom Ka]

OK, provedl jsem vymenu fotek za spravne otocene a zaroven pouzil nahledy
aby byla tabulka mensi a prehlednejsi.

Diky za pripominky.

čt 25. 10. 2018 v 16:26 odesílatel Mikoláš Štrajt 
napsal:

> Zdar,
> prohlížeče (FF a Vivaldi na Windows) neotáčí fotky otočené pomocí EXIFu,
> které jsou vloženy do stránky. Vidím tak v dokumentaci rozcestníky "ležící
> na boku".
>
> --
> Severák
>
> -- Původní e-mail --
> Od: Tom Ka 
> Komu: OpenStreetMap Czech Republic 
> Datum: 25. 10. 2018 15:13:14
> Předmět: [Talk-cz] Fody - ukazky v dokumentaci
>
> Ahoj, do dokumentace Fody jsem doplnil ukazky fotek a jejich tagovani ve
> Fody:
>
> https://openstreetmap.cz/git/tom.k/Fody/wiki/PhotosExamples
>
> Po zakazani fotek zacnu resit revizi tagovani jednotlivych fotek (aka
> silnicni vs. cyklo apod.) a reseni nevyuzitych fotek z OsmHiCheck.
>
> Bye
> ___
> 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