Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Michal Fabík]

2018-01-24 22:17 GMT+01:00 Lukáš Karas :
>> Jinak za mě taky nedělitelné mezery do tagů nedávat, ať si to ošetří
>> renderer, zas taková věda to snad není.
>
> Tohle mi přijde hrozně lokální pohled na problematiku (podobně jako spousta
> jiných věcí co se zde na listu řeší). Já bych rád aby se české názvy rozumě
> zalamovaly a zobrazovaly i v rendereru který si napíše třeba Japonec. Někdo
> mimoevropský nebude vůbec řešit jaké tu v Česku máme typografická pravidla.
>
> Zkuste u nějakého renrereru na githubu vytvořit issue že se nějaký český název
> špatně zobrazuje a že si to přeci může vyřešit. Taková věda to přeci není.
> Ještě těch chudákům vývojářům můžete poradit že exituje probram "vlnka" který
> to přeci dokázal před deseti lety.
>
> Stejně tak já nedokážu posoudit jestli se arabské jméno hospody má vykreslit
> zleva doprava nebo zprava doleva a už vůbec (bez unicode hitnů) nedokážu
> napsat renderer kde arabský název obsahuje číslovku!

Tohle mně zas přijde jako argumentace nefungující, neřkuli přímo
záměrně zlomyslnou, komunikací mezi uživatelem a autorem rendereru.
Přece když budu chtít, aby si japonský renderer správně poradil s
nějakým obskurním aspektem české typografie, tak autorovi neřeknu: "V
českých názvech máte špatně pevné mezery, spravte si to, tohle si
přece můžete vyřešit, vlnka to umí taky". Naopak, vysvětím, proč je to
důležité, popíšu jednotlivá pravidla, dám příklady, třeba ukážu _jak_
to ta vlnka dělá (a ne, že už to dělá deset let). Podobně, až budu mít
ve svém rendereru problém se zobrazováním arabštiny, zeptám se někoho,
kdo umí arabsky. Asi to vidím naivně, ale s jazykovými daty pracuju a
přesně taková komunikace je pro mě naprosto normální a v podstatě
nevyhnutelná.

Podle mě prostě ty pevné mezery jsou tagging for the renderer. Pevná
mezera slouží ke správnému _zobrazení_, tj. renderingu, žádnou věcnou
informaci nenese.

-- 
Michal Fabík

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

Re: [OSM-talk-fr] positionnement des adresses et ménage

[thevenon . julien]

- Mail original -
De: "JB" 
> Euh, j'ai laissé tomber la lecture de threads longs, pointus et qui 
> dévient souvent. Comme celui-là en fait partie, je ne l'ai pas lu 
> jusqu'à la fin. Et l'introduction ne m'a pas appris grand chose. Tu 
> pourrais donner un exemple, qu'on voit de quoi on parle ? (Parler dans 
> le vide, ça permet de discuter longtemps, mais souvent dans le vide, 
> tiens…).

Dommage les exemples etaient a la fin de son mail ;-)

SInon globalement je suis plutot d accord avec la proposition de Marc

Julien

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

Re: [OSM-talk-fr] positionnement des adresses et ménage

[JB]

Le 25/01/2018 à 00:01, marc marc a écrit :

La confusion entre nœud adresse postale et routage provoque des
problèmes parfois insolubles et de nombreux besoins sont non satisfait.
Euh, j'ai laissé tomber la lecture de threads longs, pointus et qui 
dévient souvent. Comme celui-là en fait partie, je ne l'ai pas lu 
jusqu'à la fin. Et l'introduction ne m'a pas appris grand chose. Tu 
pourrais donner un exemple, qu'on voit de quoi on parle ? (Parler dans 
le vide, ça permet de discuter longtemps, mais souvent dans le vide, 
tiens…).

JB.
PS : j'ai lu qu'on parle de tracer des routes pour ne pas avoir de 
problème de routage… ben oui, se plaindre qu'une adresse sans route à 
proximité met le foutoir… ben c'est un peu abuser, j'ai l'impression. On 
parle de contributeurs, ici ?
PS2 : oui, j'ai la super pêche, ça va ! Assez pour pouvoir râler sans 
morosité !


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

[Talk-us] Microsoft Building Import for Greenville, SC

[Mike N]

The OSM Upstate SC group is planning an import of Microsoft building 
shapes for the city of Greenville, SC.   The candidate wiki page is at


https://wiki.openstreetmap.org/wiki/Greenville_SC_Building_Import

  The actual import won't take place for 1-2 months yet to allow time 
to review the plans.


  Mike

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

Re: [Talk-ca] Talk-ca Digest, Vol 119, Issue 10

[Jonathan Brown]

Thank you for this useful information, John. The Washington DC Georgia Ave 
Youth Ambassador Mapping Project involving 7 university students and 20 high 
school ambassadors from underrepresented groups  
http://teachosm.org/en/cases/georgia-ave/ is a good example of how OSM could 
support youth in gaining 21st Century competencies. 
They started with a good base map, used a form developed by NGOs to collect 
data, spoke to business owners about entrepreneurship and business skills, 
refined an “elevator pitch” to meet 21st century competencies in the curricula, 
and collected info on building facades and structures that business could use 
to apply for Great Streets revitalization grants. 
As part of their summer job as Youth Ambassadors, students mapped around 268 
places. Some of the lessons learned that they posted on their wiki page 
included: 
• Being able to work with an the OSM MappingDC user group who already had a 
volunteer base, survey forms, and a good idea for a project was helpful. [Note: 
This is where cloning or forking an open data in education: what problem do you 
want to solve would be useful for communities that do not have access to these 
civic tech minded user groups. I have to drive over an hour to access these 
kinds of user groups from the rural community I live in here in Ontario]
• the use of Field Papers from the start 
https://wiki.openstreetmap.org/wiki/Field_Papers to organize data collection
• more training on iD (e.g., how to add to an existing place, here's how to 
search for the correct tag in iD and the Wiki)
• some formal training on mouse and keyboard skills for some students was 
necessary
• community-based organizations may not have the right computers for the 
students to use. Chromebooks seemed to always crash with every “save” in OSM iD 
Editor. 
• Used 6 computers and divided students into small groups based on area they 
were assigned to map and gave everyone a chance to "drive" for a while so that 
each student got familiar with the system
• HOT Task manager and volunteers mapped all the buildings ahead of time so 
that the students could focus on the businesses 
•  Figuring out what is the best means of communication and having a regular 
check-in
• a small outreach campaign to tell businesses that the students were coming, 
but some didn't want to talk to them. Perhaps some kind of official 
sticker/shirt/hat for the students to wear, to make it more clear that they are 
part of a program
• field trip to Mapbox, a web mapping company, to show them how OpenStreetMap 
and geography is used for work and potential career pathways was well received 
by students. Include some swag for students.
• the 20 youth ambassadors were supported by partners included an NGO mentoring 
organization http://www.momiestlc.org/, professor from 
https://geography.columbian.gwu.edu/ and the MappingDC usergroup that set up 
TeachOSM http://teachosm.org/en/cases/ with great use cases in education. Note: 
Professors Nuala Cowan & Richard Hinton suggested that the “instructional 
module/assignment is applicable to many disciplines and teaching scenarios, and 
the objective of the TeachOSM resource is to open that possibility to these 
other fields, in a comprehensive user friendly way.” The Kathmandu Living Lab 
national housing reconstruction project is a great example of citizen science 
and civic engagement using 21st century mobile apps as is the Mapping the 
Forests of Nepal 
http://www.kathmandulivinglabs.org/events/geography-awareness-week-2c-pokhara-mapathon

Technical Questions:
• How could Overpass Turbo be used to collect data from multiple mapathon 
events and communities from OSM? 
• What’s the difference between the mobile app Alessandro commissioned for 
Building Canada 2020i and PushPin OSM? 
• I wonder if there is a way to create a better quality poster map than the one 
the students posted:  Ideally, these maps could be embedded in municipal and 
regional open data portal GIS maps.
Jonathan

From: talk-ca-requ...@openstreetmap.org
Sent: Wednesday, January 24, 2018 11:25 AM
To: talk-ca@openstreetmap.org
Subject: Talk-ca Digest, Vol 119, Issue 10

Send Talk-ca mailing list submissions to
talk-ca@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-ca
or, via email, send a message with subject or body 'help' to
talk-ca-requ...@openstreetmap.org

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

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


Today's Topics:

   1. Re: BC2020i and Mapathons with High Schools (john whelan)
   2. Re: Talk-ca Digest, Vol 119, Issue 9 (Jonathan Brown)


--

Message: 1
Date: Wed, 24 Jan 2018 07:41:04 -0500
From: john whelan 
To: keith hartley 

Re: [Talk-es] Cómo mapear una mina de agua

[dcapillae]

Gracias, Javier.

Usaré «man_made=adit» y «resource=water», creo que se ajusta mejor a una
mina de agua. Lo cambiaré también en el wiki.

El mapeado de la zona en torno a la mina no me lo había planteado. Las que
hay en los Montes de Málaga son minas de uso más bien doméstico, asociadas a
antiguos lagares o junto a abrevaderos para animales. Tampoco son muy
profundas, de apenas unos metros.

Veo en la página del wiki que las galerías de Tenerife se destinan a la
captación de agua subterránea. Las minas de agua en Málaga son también
excavaciones horizontales, pero no captan agua subterránea, sino que recogen
el agua de lluvia por filtración. No sé si son lo mismo o no. En cualquier
caso, se parecen bastante.

Gracias de nuevo.



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

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

Re: [Talk-es] Importación de Catastro

[Rodrigo Rega]

Ojalá vaya todo bien.

Gracias por todo el trabajo de programación y documentación, Javier.

Un saludo.

El 24 de enero de 2018, 2:11, Javier Sánchez Portero 
escribió:

> Hola
>
> Ya está enviada la propuesta a la lista imports:
> https://lists.openstreetmap.org/pipermail/imports/2018-January/005342.html
>
> Tengo que agradecer a Alan su colaboración corrigiendo la traducción y a
> Néstor por sus contribuciones al código, que se suman a las de Rodrigo Rega.
>
> Hay publicada una nueva versión del programa con mejoras. Actualizar a
> 1.1.0.
>
> Saludos
>
> El 13 de enero de 2018, 16:57, Javier Sánchez Portero <
> javiers...@gmail.com> escribió:
>
>> Lo has entendido bien, pero con revisar un 1-2% de las tareas es
>> suficiente.
>>
>> Yo creo que la conclusión de la validación ya la tenemos. Los datos hace
>> falta corregirlos como se explica en la página correcciones, más otras
>> cosas que irán apareciendo. No hace falta que terminemos todos los
>> municipios de la tabla, pero es bueno que hagas alguno para ir conociendo
>> los datos.
>>
>> El 13 ene. 2018 16:25, "Joaquim"  escribió:
>>
>>> Hola a todos
>>>
>>>
>>> Vengo siguiendo desde hace tiempo la lista de correo. Quiero participar
>>> en los trabajos de importación del Catastro, pero, la verdad es que me
>>> pierdo un poco.
>>>
>>> Creo que una tarea ahora es la "Revisión respecto a las imágenes
>>> aéreas". Si no lo he entendido mal, se trata de:
>>>
>>> -tomar un municipio de la lista de los 36 municipios escogidos como
>>> pilotos
>>>
>>> -extraer mediante el programa catatom2osm los datos
>>>
>>> -anotar en la tabla de "Revisión manual" el municipio, mi nombre, el
>>> total de tareas
>>>
>>> -hacer la revisión de algunas de las tareas generadas (¿cuantas?)
>>>
>>> -pasar la información obtenida a la tabla
>>>
>>>
>>> Si es así puedo empezar a revisar concordancia de las imágenes, si no lo
>>> he entendido bien os ruego que me lo expliquéis con más detalle.
>>>
>>> Gracias
>>>
>>> Joaquim
>>>
>>> ___
>>> 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
>
>


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

Re: [OSM-talk-fr] positionnement des adresses et ménage

[marc marc]

Bonsoir,

Vu que mon email est très long, je fais un résumé pour ceux
qui n'ont pas envie de tout lire :
La confusion entre nœud adresse postale et routage provoque des 
problèmes parfois insolubles et de nombreux besoins sont non satisfait.
une séparation simple entre adresse postale et routage tout en créant
un lien avec les bâtiments permet de résoudre tous ces problèmes.
Cette solution peux-être aussi simple que déplacer légèrement
le nœud adresse jusqu'à le mettre SUR ou DANS l'aire qui le concerne
et tracer les routes manquantes.
On peux bien sur imaginer une une solution + complexe pour
ceux qui ne souhaitent pas la fin de cette confusion.
Si quelqu'un trouve un défaut à la solution proposée, qu'il l'exprime.
Mais cela ne peux fonctionner que si les besoins non couvert
sont compris.

Le 22. 01. 18 à 17:45, Christian Quest a écrit :
> faire le lien avec le bâtiment est une fausse bonne idée.

Nulle part dans ton email tu n'expliques POURQUOI c'est une
fausse bonne idée ni le moindre problème de la solution proposée.
Tu te contentes de dire que c'est pas ta logique ou que
ce n'est pas ton besoin.
Ce besoin est pourtant ce que je constate de mon utilisation
mais aussi ceux des autres en ayant regardé quasi tous
les changeset de nouveaux contributeurs en France depuis 3 mois.
Tous ceux qui ont ajouté une adresse ont fait un lien
entre le bâtiment et son adresse.
La question n'est donc pas "faut-il ou pas un lien ?"
mais "si on ne le fait pas, pourquoi ? et quel autres
solutions proposes-tu pour répondre aux besoins ?"
et "s'il n'y a pas de pourquoi autre que l'habitude,
comment faire ce lien manquant harmonieusement ?"
cfr fin de message pour 10 besoins concrets.

>> ce que je propose n'a cependant rencontré aucun cas qui
>> ne fonctionne pas. et pourtant je pense avoir croisé tous les cas.
>> Faut pas s'attendre à voir une solution unique adoptée si elle casse
>> ce que l'autre solution apporte. Dire que les autres ont tord ne suffit
>> pas si on ne propose pas en même temps une solution globale aux 2 faces
>> de la même pièce.
> 
> On ne peut pas résoudre les 2 (ni 3) d'un coup sans modéliser  
> chaque type d'info à part. En voulant mélanger, 
> on ne décrit ni l'un ni l'autre  correctement.

Justement tu mélange dans ton explication adresse et routage.
Je propose à l'inverse de faire une différence entre l'adresse,
le bâtiment et le routage tout en créant les liens évidents
qui les unissent.
- Si tu veux modéliser un bâtiment, fait un bâtiment.
- Si tu veux router un endroit, trace une ou des routes.
le lien entre adresse et routage n'est pas 1-1 comme tu penses mais 1-x,
tu peux avoir plusieurs point d'entré sur la parcelle, parfois plusieurs 
pour un même profil (un site universitaire avec plusieurs routes), 
parfois des entrées différentiées selon le profil (voiture <> piéton). 
ta confusion entre l'adresse du lieu et son point d'entrée est un 
handicap sérieux au routage de qualité. si tu comprend la confusion,
tu facilites ces routages multiples et différentiée (prendre l'entrée 
nord si tu arrives par le nord, prend l'entrée sud si tu arrives du sud, 
prendre l'accès piéton parfois + proche au lieu de marcher jusqu'à la 
route d'accès) tout cela implique que si tu veux router vers une 
adresse, celle ci doit être situé vers le milieu de la zone concernée
et non pas sur une entrée arbitraire que ta méthode va privilégier au 
détriment des autres entrées.
- Si tu veux modéliser la limite de la parcelle, fais une parcelle au 
lieu de mélanger cette info dans la position du nœud. ceci sans compter 
les nombreux cas oü il est impossible sur le terrain de voir cette info.
Ceci sans juger du fait que ce niveau de détail me parait - important
vu que des besoins + important sont loin d'être couvert à 100%.
Mais je respecte sans soucis ceux qui trouve que c'est important.
- Si tu veux mettre une adresse postale, ce n'est pas une cordonnée gps, 
elle a un lien avec d'autres objets osm.
De la même manière on trace des polygones pour les communes,
on ne se contente pas d'un nœud en disant "c'est environ par là"
Il faudrait qu'il y a un lien avec ce quelque chose. cela peux être
un bâtiment/entrée/surface des écoles pour les cas les plus simple
et majoritaires.
bref tout SAUF "adresse = point de routage sans lien avec le reste"

>> Pour rappel ma solution simple :
>> Le lien addr-bâtiment pourrait se faire au choix :
>> - soit en positionnant le nœud sur ou dans le contour du bâtiment (comme
>> cela se fait déjà pour les maisons mitoyennes en zone urbaine dense...
>> parfois ce n'est qu'une question de cm pour avoir ce lien !)
> Tu veux parler des maisons sur rues, avec la façade en bord de parcelle 
> ? Elle ne sont pas forcément mitoyennes... et le point d'accès au 
> domaine privé, n'est pas forcément sur la façade du bâtiment.

Oui je parle de ce genre de cas.
Mais l'accès n'est pas forcément unique (un site universitaire entre
4 rues en ville, cela existe), ce que ta solution ne gère pas.
Et l'accès 

Re: [Talk-es] Cómo mapear una mina de agua

[Javier Sánchez Portero]

PD: Aquí se denominan galerías.

El 24 de enero de 2018, 22:18, Javier Sánchez Portero 
escribió:

> En Tenerife son muy comunes y la fuente principal de suministro.
>
> Yo he mapeado la bocamina con
>
> man_made=adit
> resource=water
>
> Y la zona con
>
> landuse=industrial
> man_made=water_works
> name = *
>
> https://wiki.openstreetmap.org/wiki/ES:Importaci%C3%B3n_
> de_infraestructuras_hidr%C3%A1ulicas_de_Tenerife
>
> El 24 de enero de 2018, 21:42, dcapillae  escribió:
>
>> Hola,
>>
>> Traslado a la lista esta cuestión sobre la forma más adecuada de mapear
>> una
>> mina de agua. Las minas de agua son pequeñas excavaciones horizontales
>> destinadas a recoger el agua de lluvia que se filtra desde la superficie
>> hasta el suelo de la mina. En Málaga son muy comunes, y se las puede
>> encontrar tanto abandonadas como todavía en funcionamiento.
>>
>> https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a/C%C3%B3mo
>> _mapear_un#Mina_de_agua
>>
>> No son manantiales, puesto que tienen un origen humano. Por supuesto, no
>> son
>> minas. Lo más parecido sería un pozo, aunque en este caso el agua no
>> procedería de un acuífero sino de la lluvía. También se podría considerar
>> que son depósitos, aunque en realidad no lo son. Muchas de estas minas se
>> conecta luego a un depósito, que es donde se almacena el agua en grandes
>> cantidades, pero la mina funciona más bien como fuente o manantial. De
>> hecho, algunos catálogos incluyen las minas de agua junto a fuentes y
>> manantiales .
>>
>> Al tratarse de excavaciones artificiales, a lo que más se me asemejan
>> sería
>> a un pozo, por eso he pensado que se podrían mapear como:
>>
>> man_made=water_well
>> name=Nombre-de-la-mina
>> pump=no
>> description=Mina de agua
>> drinking_water=yes/no
>>
>>
>>
>> -
>> Daniel Capilla
>> OSM user: dcapillae
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Cómo mapear una mina de agua

[Javier Sánchez Portero]

En Tenerife son muy comunes y la fuente principal de suministro.

Yo he mapeado la bocamina con

man_made=adit
resource=water

Y la zona con

landuse=industrial
man_made=water_works
name = *

https://wiki.openstreetmap.org/wiki/ES:Importaci%C3%B3n_de_infraestructuras_hidr%C3%A1ulicas_de_Tenerife

El 24 de enero de 2018, 21:42, dcapillae  escribió:

> Hola,
>
> Traslado a la lista esta cuestión sobre la forma más adecuada de mapear una
> mina de agua. Las minas de agua son pequeñas excavaciones horizontales
> destinadas a recoger el agua de lluvia que se filtra desde la superficie
> hasta el suelo de la mina. En Málaga son muy comunes, y se las puede
> encontrar tanto abandonadas como todavía en funcionamiento.
>
> https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a/C%C3%
> B3mo_mapear_un#Mina_de_agua
>
> No son manantiales, puesto que tienen un origen humano. Por supuesto, no
> son
> minas. Lo más parecido sería un pozo, aunque en este caso el agua no
> procedería de un acuífero sino de la lluvía. También se podría considerar
> que son depósitos, aunque en realidad no lo son. Muchas de estas minas se
> conecta luego a un depósito, que es donde se almacena el agua en grandes
> cantidades, pero la mina funciona más bien como fuente o manantial. De
> hecho, algunos catálogos incluyen las minas de agua junto a fuentes y
> manantiales .
>
> Al tratarse de excavaciones artificiales, a lo que más se me asemejan sería
> a un pozo, por eso he pensado que se podrían mapear como:
>
> man_made=water_well
> name=Nombre-de-la-mina
> pump=no
> description=Mina de agua
> drinking_water=yes/no
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] Nomi delle strade e numeri civici

[Martin Koppenhoefer]

sent from a phone

> On 24. Jan 2018, at 19:20, Andrea Musuruane  wrote:
> 
> Dovresti leggere quello che - tanto faticosamente - ho scritto sulla wiki, se 
> non altro, per rispetto per il tempo che ho impiegato a raccogliere le 
> informazioni e documentarle.


al suo tempo avevo letto per intero delle pubblicazioni ISTAT sui nomi e ti 
sono grato di aver messo un riassunto nella wiki. 

Per me la pagina sui nomi più importante da quelli citati da te è questa:
https://wiki.openstreetmap.org/wiki/IT:Key:name

Potremmo comunque davvero mettere dei tags come ISTAT, che spezzano i nomi nei 
loro componenti.

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

Re: [Talk-de] Königreich Württemberg

[Michael Kugelmann]

Am 23.01.2018 um 01:52 schrieb Martin Koppenhoefer:

Nachdem sich hier alle einig waren, habe ich mich mal an Württemberg
gemacht.

[...]
TNX!  (oder müsste ich das las ChangeSet-Kommentar machen?)


Grüße,
Michael.


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

[Talk-es] Cómo mapear una mina de agua

[dcapillae]

Hola,

Traslado a la lista esta cuestión sobre la forma más adecuada de mapear una
mina de agua. Las minas de agua son pequeñas excavaciones horizontales
destinadas a recoger el agua de lluvia que se filtra desde la superficie
hasta el suelo de la mina. En Málaga son muy comunes, y se las puede
encontrar tanto abandonadas como todavía en funcionamiento.

https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a/C%C3%B3mo_mapear_un#Mina_de_agua

No son manantiales, puesto que tienen un origen humano. Por supuesto, no son
minas. Lo más parecido sería un pozo, aunque en este caso el agua no
procedería de un acuífero sino de la lluvía. También se podría considerar
que son depósitos, aunque en realidad no lo son. Muchas de estas minas se
conecta luego a un depósito, que es donde se almacena el agua en grandes
cantidades, pero la mina funciona más bien como fuente o manantial. De
hecho, algunos catálogos incluyen las minas de agua junto a fuentes y
manantiales .

Al tratarse de excavaciones artificiales, a lo que más se me asemejan sería
a un pozo, por eso he pensado que se podrían mapear como:

man_made=water_well
name=Nombre-de-la-mina
pump=no
description=Mina de agua
drinking_water=yes/no



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

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

Re: [Talk-it] Aggiornamento IIS Avogadro (OSM va a scuola)

[mbranco2]

Grazie @Giovanni, stavo appunto usando osmcha per controllarli.
Ho sempre diffidato di Telegram (solo per voci e dicerie, lo ammetto: forse
sono un po' paranoico a riguardo).
Come software di condivisione stiamo usando Trello (l'hanno proposto i
ragazzi, io non lo conoscevo).

Il giorno 24 gennaio 2018 15:42, Cascafico Giovanni 
ha scritto:

> Ho iniziato ad inserire gli utenti che hai segnalato... ma mi son fermato
> ad ITI-Avogadro02.. puoi andare avanti a costruire il filtro [1] che ho
> iniziato. Ci puoi anche mettere un RSS [2] in Telegram, così quando
> qualcuno edita, ti arriva il msg :-)
>
> Il giorno 24 gennaio 2018 15:13, mbranco2  ha scritto:
>
>
>> Perciò come doppio controllo li ho fatti registrare con gli
>> account ITI-Avogadro01, ITI-Avogadro02 ITI-Avogadro25, quindi non
>> dovrebbe sfuggire niente.
>>
>
> [1] https://osmcha.mapbox.com/filters?aoi=f89a53af-66d1-
> 4c3d-9fbf-1a9919ea3512
> [2] https://osmcha.mapbox.com/api/v1/aoi/f89a53af-66d1-4c3d-
> 9fbf-1a9919ea3512/changesets/feed/
>
> ___
> 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] Nomi delle strade e numeri civici

[Marco_T]

Andrea Musuruane wrote
> Ogni commento è, ovviamente, ben accetto.

Ciao Andrea,
mi complimento per l'ottimo lavoro di ricerca e sintesi.
Questo aggiornamento era indispensabile per creare una base di discussione.

Per quanto riguarda ISTAT sono daccordo con te: le regole nazionali sono
quelle e pian piano tutti dovranno adeguarsi.
L'Agenzia Entrate (imposte, catasto, demanio...), le Conservatorie dei
registri immobiliari etc., che sono la base del sistema di amministrazione
ed archiviazione fiscale ed immobiliare italiano, da anni adottano quelle
regole.

Più delicato il discorso maiuscole e minuscole che non è propriamente
normato ma esistono "regole di stile" e consuetudini.
Oltre alla tua sitografia segnalo anche questo link per ulteriori spunti ed
esempi da inserire nella wiki:
https://it.wikipedia.org/wiki/Aiuto:Maiuscolo_e_minuscolo
In FVG quando abbiamo normalizzato i nomi, per i titoli nobiliari e cognomi
con preposizione (De, Di ...) abbiamo seguito il link precedente (vedi
sezione Persone) che è diverso da quanto da te scritto...non è un problema
se il consenso segue la tua proposta si può adeguare.

Per il resto mi trovi daccordo.

Grazie di nuovo!

-- 
Marco_T



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

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Lukáš Karas]

> Jinak za mě taky nedělitelné mezery do tagů nedávat, ať si to ošetří
> renderer, zas taková věda to snad není.

Tohle mi přijde hrozně lokální pohled na problematiku (podobně jako spousta 
jiných věcí co se zde na listu řeší). Já bych rád aby se české názvy rozumě 
zalamovaly a zobrazovaly i v rendereru který si napíše třeba Japonec. Někdo 
mimoevropský nebude vůbec řešit jaké tu v Česku máme typografická pravidla.

Zkuste u nějakého renrereru na githubu vytvořit issue že se nějaký český název 
špatně zobrazuje a že si to přeci může vyřešit. Taková věda to přeci není.
Ještě těch chudákům vývojářům můžete poradit že exituje probram "vlnka" který 
to přeci dokázal před deseti lety.

Stejně tak já nedokážu posoudit jestli se arabské jméno hospody má vykreslit 
zleva doprava nebo zprava doleva a už vůbec (bez unicode hitnů) nedokážu 
napsat renderer kde arabský název obsahuje číslovku!

Otevřete trochu svoji mysl a myslete prosím za hranice českého rybníčku.

Lukáš

signature.asc
Description: This is a digitally signed message part.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[Philippe Verdy]

Ou la version lisible aussi sur Wikipedia de la liste complète (générée par
bot depuis la même source, intégrée aussi à Wikidata contenant de nombreux
noms de langues traduits, intégrée aussi aux modules Lua de langues et de
traductions de Wikipedia, Commons et MetaWiki)

https://en.wikipedia.org/wiki/List_of_ISO_639-3_codes

On en a aussi une version sur le Wiktionnaire francophone (intégrée dans
les listes de labels de localisation BCP 47)

https://fr.wiktionary.org/wiki/Wiktionnaire:BCP_47

Cependant il peut encore manquer des ajouts plus récents, mais la date de
mises à jour est indiquée dans les tableaux. Ceci provbient non pas de
l'ISO 639-3 (dont certains codes sont exclus de BCP 47) mais du registre
IANA.

Le 24 janvier 2018 à 19:16,  a écrit :

> Une autre solution pour trouver le code langue ffr c'est de regarder la
> version publique de l'ISO639-3 :
>
> http://www-01.sil.org/iso639-3/codes.asp?order=reference_name=%25
>
> Jean-Yvon
>
> Le 24/01/2018 à 12:30, Francescu GAROBY - windu...@gmail.com a écrit :
>
> En cherchant "frr" dans Wikipedia, on arrive sur cette page de résultats
> .
>
>
> Francescu
>
> Le 24 janvier 2018 à 12:24, Charles MILLET  a
> écrit :
>
>> Merci Francescu pour l'info. Je suis curieux de savoir comment tu as
>> trouvé la référence au code, je ne l'ai pas vue dans la page
>> https://wiki.openstreetmap.org/wiki/Multilingual_names et d'autre pages
>> internet dédiées aux codes (peut-être trop orientées pays).
>>
>
>
> ___
> 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-lt] Dėl proskynų žymėjimo

[Mindaugas]

Sveiki,


esu Mindaugas ir paskutinį pusmetį šiek tiek prisidėjau prie OSM. Su
Tomu pasirašinėjome asmeniškai, bet jis pasiūlė parašyti į
konferenciją ir paskelbti/padiskutuoti su visa liaudimi.

Kalba yra apie proskynų (man_made=cutline) žymėjimą. Su jom atrodo
kaip ir viskas gerai, tačiau turi vieną niuansą - proskyna gali eiti
pakankamai rimtas track/grade1 kelias ir proskyna gali būti išarta ir
važiuojama tik traktoriumi. Abu šie kraštutinumai iš ortofoto atrodo
vienodai, todėl kyla klausimas, kaip jas žymėti pagal ortofoto -
nenuvykus apžiūrėti? Be abejo, galima nieko nežymėti kol nenuvykai į
vietą, bet tai nelabai konstruktyvu, nes taip proskynos, nors ir
ryškiai matomos tiek ortofoto, tiek vietovėje, lieka nepažymėtos.

===
Taigi, jeigu negalime detaliau nustatyti ar proskynoje yra keliukas žymime taip:

Variantai (1):
A) Tik man_made=cutline
Taip mažiausiai įtakos routinimui, nes mašinos nebus nukreipiamos
važiuoti išartom proskynom.

B) man_made=cutline + highway=path
Kai kur taip mėgstama žymėti. Pvz.:
https://www.openstreetmap.org/#map=15/55.1503/25.9427
Netgi jei proskyna išarta ir patogiau eiti šalia jos nei ja pačia, ji
yra naudojama kaip objektas pestiesiems.

C) man_made=cutline + highway=track
Argumentas kaip B varianto, bet atsižvelgiama į tai, kad highway=path
turi turėti vieną "vėžę", o highway=track dvi vėžes. Proskynos visada
turės dvi, tik kartais jos gali būti važiuojamos tik traktoriumi...

Siūlau A variantą, bet gal bus kitokių minčių.

===
Kitas klausimas yra kaip žymėti keliuką/takelį kuris eina išilgai proskynos.

Variantai (2):
A) Keičiame man_made=cutline į highway=track (path)
Prarandame informaciją, kad tai yra proskyna. Be to iškarpius jas
gabalais kur eina keliukai gauname pakankamai šlykštų default OSM
žymėjimą.

B) Papildome highway=track (path) atributą prie ankstesnio
man_made=cutline tai pačiai linijai
Tokiu būdu papildomai išskiriame keliukus einančius proskyną nuo kitų.
Iš žemėlapio duomenų galime gauti iš pilną keliukų tinklą ir pilną
proskynų tinklą.

C) Piešiame antrą highway=track (path) liniją šalia ankstesnės man_made=cutline
Topografiniuose žemėlapiuose proskynos braižomos punktyru, kaip
keliukas, tik skirtingo storio. Tokiu atveju pagaminę topografinį
žemėlapį turėtume nubraižytus du lygiagrečiai einančius keliuko
punktyrus - vienas proskynos, kitas tikro keliuko.

Siūlomas variantas B.

Tuo pačiu kyla klausimas (ypač pasirinkus B) ar per mišką einančios
elektros linijos irgi turi turėti man_made=cutline, nes jos irgi eina
proskyna? Gal ne, nes elektros linija visada eina proskyna, tad
man_made=cutline nieko papildomo neprideda, o keliukas gali eiti ir
proskyna ir be jos.
===

Kiti klausimai, mintys, pasiūlymai:
1) Klausimas: Ar reikia nutraukti proskynos liniją, kai ji kerta kelią
(ir kitoje pusėje nuo miško krašto pradėti naują)?
https://www.openstreetmap.org/#map=19/55.26438/25.84389

2) Pasiūlymas: Keliukai (takeliai) neturėtų prasidėti ir baigtis
proskyna, nes jie tampa nebepasiekiami routinimui. Reikia stengtis
parinkti proskyną kuri labiausiai tikėtina turi ir keliuką, uždėti
highway=track(path), ir taip pasimetusį keliuką prijungti prie bendro
kelių tinklo https://www.openstreetmap.org/#map=17/53.92442/23.73023
Beje, visas šis Baltarusijos miškas prieš savaitę buvo išpaišytas
pagal 1B variantą, o dabar kažkas highway=path nuėmę ir padarė 1A
variantą - man dar kai kurias kaladėles/kai kuriuose zoom lygiuose
naršyklė paišo su takeliu išilgai proskynos.

3) Lietuvos teritorijoje nedokumentuotą man_made=fire_break,
priklausomai nuo to, kas ja pažymėta, mesti arba keisti į
man_made=cutline
http://overpass-turbo.eu/?Q=(way%5B%22man_made%22%3D%22fire_break%22%5D(%7B%7Bbbox%7D%7D)%3B)%3Bout%3B%3E%3Bout%20skel%20qt%3B=53.9;23.9;11
Ji randama tik Gardino apylinkėse - matyt kokio nors baltaruso "išradimas".


Iki,
Mindaugas

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

Re: [OSM-talk-fr] positionnement des adresses et ménage

[osm . sanspourriel]

Le 22/01/2018 à 17:45, Christian Quest - cqu...@openstreetmap.fr a écrit :


Le 22/01/2018 à 12:48, marc marc a écrit :

Le 22. 01. 18 à 11:32, Cyrille37 OSM a écrit :

Le résumé de Christian pourrait être déposé délicatement,
mais très visiblement, sur le wiki.openstreetmap.org ?

L’existence d'une relation x-y entre les adresses et les bâtiments
est déjà écrit sur la page wiki des adresses.
Je veux bien me charger de mieux rédiger les arguments de ceux qui
tagent pour le routing et de ceux qui tager pour le lien avec les 
bâtiments.


J'étais visiblement pas assez clair... vouloir faire le lien avec le 
bâtiment est une fausse bonne idée.
On voit un bâtiment, on veut savoir son adresse, ça ne me semble pas 
stupide.
Ou on nous dit que tel POI est à telle adresse et on veut savoir quels 
sont les bâtiments potentiellement concernés, ça ne me semble pas non 
plus stupide.



Cependant, j'aurais aimé naïvement que les partisans de la position
en bord de parcelle prennent en compte le revers de la médaille :
l'absence de lien entre le(s) bâtiment(s) et leur(s) adresse(s).
Cela aurait permit de mettre en place une solution qui résout les 2
problèmes au lieu d'avoir 2 version qui ne résolvent que la moitié
du problème.
Je comprend d'autant moins qu'avec un (maigre) millier d'adresses
à mon actif, ce que je propose n'a cependant rencontré aucun cas qui
ne fonctionne pas. et pourtant je pense avoir croisé tous les cas.
Faut pas s'attendre à voir une solution unique adoptée si elle casse
ce que l'autre solution apporte. Dire que les autres ont tord ne suffit
pas si on ne propose pas en même temps une solution globale aux 2 faces
de la même pièce.


C'est parce que la pièce à 3 faces... et même pas deux: adresses, 
parcelles, bâtiments.

Comme dans OSM on ne met pas les parcelles... 3-1=2 CQFD ;-).

On ne peut pas résoudre les 2 (ni 3) d'un coup sans modéliser chaque 
type d'info à part. En voulant mélanger, on ne décrit ni l'un ni 
l'autre correctement.
Concrètement tu veux mettre l'adresse quasiment sur la voie et des 
contact:addr sur les bâtiments même sans POI ?

Pour rappel ma solution simple :
Le lien addr-bâtiment pourrait se faire au choix :
- soit en positionnant le nœud sur ou dans le contour du bâtiment (comme
cela se fait déjà pour les maisons mitoyennes en zone urbaine dense...
parfois ce n'est qu'une question de cm pour avoir ce lien !)


Tu veux parler des maisons sur rues, avec la façade en bord de 
parcelle ? Elle ne sont pas forcément mitoyennes... et le point 
d'accès au domaine privé, n'est pas forcément sur la façade du bâtiment.
non mais si elles sont non mitoyennes tu peux mettre le nœud au niveau 
de l'entrée (partie non bâtie).
- ou de l'aire concernée (comme cela se fait déjà souvent pour les 
écoles)
En bord d'aire ? Au point d'accès donc entre domaine public et 
privé... on y revient ;)



- soit en travaillant sur une relation style associatedAddr.
Le routage est fait avec les routes (donc si on a un problème de routing
pour se rendre à un bâtiment, on trace la route de déserte manquante).


Je ne comprends pas ce besoin qui me semble purement théorique.

Pour le routage, on rentre quoi comme info ? Une adresse... et une 
adresse n'est pas un identifiant de bâtiment (chose qui n'existe pas 
vraiment actuellement).
Je crois que c'est ce que veut dire Marc : créer ce lien quand il n'est 
pas trivial entre adresses et bâtiments.


N. B. : je rappelle qu'en mettant l'adresse à la limite public/privé on 
obtient un rendu assez mauvais car les numéros sont mangés par les 
routes. Pourquoi pas, il "suffit" d'améliorer le moteur de rendu.

En poussant les numéros au niveaux des bâtiments par exemple ;-).

Je signale que dans associatedStreet, house est ce qui est raccroché à 
l'adresse.
Si ça s'appelle house et non number, il y a peut-être une raison (qui 
peut-être mauvaise).


Si on met les adresses au bord des routes, à quoi bon mettre une 
associatedStreet, la rue la plus proche doit être la bonne.


Car s'il n'y a pas les bâtiments et pas les accès privés non plus reste 
juste une arrête de poisson avec une rue et les points de part et 
d'autre. Bon, c'est plus une branche avec des boutons ;-).


N. B. : question bête, le bon endroit pour l'adresse n'est ce pas là où 
est affiché le numéro ?


Bref, alors que je suis assez d'accord avec Christian sur les adresses, 
je ne vois pas l'intérêt de ne pas mettre les adresses "sur" les 
bâtiments (nœuds distincts) quand on a N adresses pour un bâtiment.
Voici l'Allée des Glénans reprise : 
https://www.openstreetmap.org/#map=19/48.37355/-4.58535


1 adresse pour M bâtiments, ça ne marche pas, on s'arrête au niveau de 
la rue publique ?
Ça ne marche pas non plus toujours : 
https://www.openstreetmap.org/#map=18/48.09952/-1.61681
Là c'est un gros b... : le 40 c'est tout ce qui est desservi par les 
deux voies au sud de la rue du Bignon.
Pour simplifier le tout, les rues à l'intérieur du Forum de la Rocade 
(c'est le nom de ce b...) n'ont pas de 

Re: [Talk-de] Königreich Württemberg - Wikidata

[Stefan Kaufmann]

Am 2018-01-24 um 15:50 schrieb Frederik Ramm:

>> Hm - die Einigkeit bestand darin, dass "sowas"
>> *besser bei Wikidata aufgehoben ist*.
> 
> Du meinst "OpenHistoricalMap"? Wikidata hat ja keine Geometrien.

Sorry, das war mein Fehler – ich dachte, das Feature sei dort schon
vorhanden, weil zu den klassischen Beispielen von Mehrdeutigkeit dort
sowas wie „wozu gehoert eigentlich die Insel, auf der Taipeh liegt“ oder
„zu welchem Land gehoert die Krimhalbinsel“ gehoert. Danke fuer den
Hinweis auf OpenHistoricalMap!

Die Relevanzkriterien und die allgemeine Kultur nehme ich bei Wikidata
BTW derzeit deutlich anders wahr als in manchen Wikipedien ;)

regards,
-stk

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

Re: [Talk-it] Nomi delle strade e numeri civici

[Andrea Musuruane]

Ciao,

2018-01-24 18:25 GMT+01:00 Martin Koppenhoefer :

> 2018-01-24 17:32 GMT+01:00 Andrea Musuruane :
>
>> Ciao,
>>vi avevo già scritto a inizio anno, dicendo che ho modificato le
>> seguenti pagine della wiki:
>> https://wiki.openstreetmap.org/wiki/IT:Key:name
>> https://wiki.openstreetmap.org/wiki/IT:Italian_Roads_Tagging#name
>> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and
>> _Conventions#Nomi_delle_strade
>>
>> Le prime due ora fanno riferimento all'ultima, in modo da avere un unico
>> posto dove sono inserite le regole per i nome delle strade.
>>
>> Ho cercato di inserire - in modo sintetico - le informazioni principali
>> riportate dall'ISTAT, evidenziando le eccezioni di OpenStreetMap (nomi NON
>> tutti in maiuscolo, uso di lettere accentante, prima lettera maiuscola,
>> ecc).
>>
>
>
> Io francamente vorrei insistere nel utilizzare la dicitura ufficiale, vera
> e legale. Quella della delibera che ha dato il nome, anche e in particolare
> riferito all'utilizzo di maiuscoli e minuscoli (questo per le strade).
> ISTAT per i nomi non ha alcun significato, è semplicemente un database
> esterno parallelo, con la speranza che i comuni si adeguino alle loro
> regole, e mettono in vigore cosa ISTAT ha "inventato" / normalizzato. ;-)
>

Continui a far fatica a comprendere la situazione legale italiana.

ISTAT non è un "semplice" database parallelo, è per legge l'ente che decide
le norme per la definizione dello stradario comunale in Italia (art. 45
d.P.R. 30/5/1989, n. 223).

I comuni devono seguire le regole ISTAT e queste dicono che il nome deve
essere scritto con caratteri maiuscoli, senza lettere accentate, ecc, ecc.
I comuni quindi in delibera devono scrivere il nome in questo modo. Tra
l'altro, in questa ML, noi abbiamo sempre detto di non voler seguire questa
regola e infatti nella wiki ciò è opportunamente documentato.


> Invece per i nomi di altre cose, utilizzerei il nome che viene usato dal
> proprietario/gestore, quando è maiuscolo e minuscolo insieme. Per esempio
> un albergo HOTEL DOLCE VITA con le attuale regole nel wiki sarebbe da
> inserire "Hotel dolce vita", mentre loro stessi scrivono "Hotel Dolce Vita"
> http://www.hotel-dolcevita.it/
>

Questo argomento esula dal contento di questo thread.

[ A proposito della numerazione civica]

Ho cercato di raccogliere tutte le convenzioni ISTAT che abbiamo deciso di
>> seguire e le regole di inserimento di cui abbiamo discusso in mailing list
>> negli ultimi anni.
>>
>
>
> comunque, oltre alle regole che decidiamo noi per il paese, ci sono quelle
> regole principali, universali, come "ground truth", "verificabilità" e c'è
> la situazione legale.
>
> Non dico che ISTAT non ha alcun valore, è un altro punto di vista, sempre
> ben venuto, e visto che loro sono la statistica nazionale, ha sicuramente
> senso poter utilizzare i nostri dati facilmente con i loro dati, ma non
> vuol dire che dobbiamo adeguare i nostri _nomi_, invece si potrebbe
> aggiungere un tag "name:istat" per la versione secondo ISTAT.
>

Dovresti leggere quello che - tanto faticosamente - ho scritto sulla wiki,
se non altro, per rispetto per il tempo che ho impiegato a raccogliere le
informazioni e documentarle.

ISTAT non è un altro punto di vista e non si occupa solo di statistica.
Infatti, l'art. 42 d.P.R. 30/5/1989, n. 223, definisce un numero civico e
dice anche che la numerazione degli accessi deve essere effettuata in
conformità alle norme stabilite dall'Istituto nazionale di statistica.

Ciao,

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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[osm . sanspourriel]

Une autre solution pour trouver le code langue ffr c'est de regarder la 
version publique de l'ISO639-3 :


http://www-01.sil.org/iso639-3/codes.asp?order=reference_name=%25

Jean-Yvon


Le 24/01/2018 à 12:30, Francescu GAROBY - windu...@gmail.com a écrit :
En cherchant "frr" dans Wikipedia, on arrive sur cette page de 
résultats .



Francescu

Le 24 janvier 2018 à 12:24, Charles MILLET > a écrit :


Merci Francescu pour l'info. Je suis curieux de savoir comment tu
as trouvé la référence au code, je ne l'ai pas vue dans la page
https://wiki.openstreetmap.org/wiki/Multilingual_names
 et
d'autre pages internet dédiées aux codes (peut-être trop orientées
pays).



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

Re: [Talk-de] Königreich Württemberg - Wikidata

[Markus]

Hi Frederik,

>> Hm - die Einigkeit bestand darin, dass "sowas"
>> *besser bei Wikidata aufgehoben ist*.
> 
> Du meinst "OpenHistoricalMap"? Wikidata hat ja keine Geometrien.

Hey, das ist ja cool:
http://www.openhistoricalmap.org

Bin gespannt, wie dort eine zeitliche Schichtung in "unserer"
2-dimensionalen DB realisiert wird.

Und ja: ich dachte, dass WD inzwischen Geometrie kann.
Aber OpenHistoricalMap ist eine hervorragende Lösung.

Also besser:

1. Historische Geo-Daten gehören nach *OpenHistoricalMap*.
>> 2. Wenn jemand sich die Mühe gemacht hat, historische Daten in OSM
>> einzupflegen (JOSM und QGIS sind dafür gute Werkzeuge), dann
3. sind die historischen Daten nach OpenHistoricalMap zu transferieren
>> 4. /bevor/ sie in OSM gelöscht werden.

:-)

> Das geht so nicht. 

Ich verstehe Deine Sorge:

> Maximal ginge: "... dann ist demjenigen eine Frist
> von 4 Wochen einzuräumen, um die Daten nach OHM zu übertragen, bevor sie
> in OSM gelöscht werden". 
> Sonst wäre die Last des Übertragens nach OHM ja bei uns.

Dennoch wünsche ich mir für OSM weiterhin eine kooperative Kultur,
in der wir andere partnerschaftlich unterstützen :-)

Klar ist OSM nicht der Platz für historische Daten.
Das kann und soll man klar kommunizieren.
Wenn sich aber jemand die Mühe gemacht hat, ohne den besseren Weg zu
kennen, dann hoffe ich, dass nette Mapper dem Neuling das freundlich und
wohlwollend erklären und ihm den Weg zu OHM zeigen, und dass sich fähige
Daten-Spezialisten finden, die so ein Datenset "bei uns ausschneiden und
dort einfügen".

Denn "Löschen" wirkt immer verletzend.

Durch die System-Gleichheit müsste ein Verschieben doch möglich sein?

> Aber auch wenn die Daten bei uns gelöscht sind, kriegt man sie
> immer noch leicht aus der History zurück. Vielleicht würde es reichen,
> ein "Verzeichnis gelöschter historischer Objekte" in OSM anzulegen, aus
> dem sich OHM-Fans dann bei Bedarf bedienen können...

Das ist vermutlich ein technisch sinnvoller Ansatz.

Menschlich muss aber die Kommunikation vorher und erfolgreich verlaufen.

Verstehst Du wie ich das meine?

Mit herzlichem Gruss,
Markus

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

Re: [Talk-it] Nomi delle strade e numeri civici

[Martin Koppenhoefer]

2018-01-24 17:32 GMT+01:00 Andrea Musuruane :

> Ciao,
>vi avevo già scritto a inizio anno, dicendo che ho modificato le
> seguenti pagine della wiki:
> https://wiki.openstreetmap.org/wiki/IT:Key:name
> https://wiki.openstreetmap.org/wiki/IT:Italian_Roads_Tagging#name
> https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_and
> _Conventions#Nomi_delle_strade
>
> Le prime due ora fanno riferimento all'ultima, in modo da avere un unico
> posto dove sono inserite le regole per i nome delle strade.
>
> Ho cercato di inserire - in modo sintetico - le informazioni principali
> riportate dall'ISTAT, evidenziando le eccezioni di OpenStreetMap (nomi NON
> tutti in maiuscolo, uso di lettere accentante, prima lettera maiuscola,
> ecc).
>


Io francamente vorrei insistere nel utilizzare la dicitura ufficiale, vera
e legale. Quella della delibera che ha dato il nome, anche e in particolare
riferito all'utilizzo di maiuscoli e minuscoli (questo per le strade).
ISTAT per i nomi non ha alcun significato, è semplicemente un database
esterno parallelo, con la speranza che i comuni si adeguino alle loro
regole, e mettono in vigore cosa ISTAT ha "inventato" / normalizzato. ;-)

Invece per i nomi di altre cose, utilizzerei il nome che viene usato dal
proprietario/gestore, quando è maiuscolo e minuscolo insieme. Per esempio
un albergo HOTEL DOLCE VITA con le attuale regole nel wiki sarebbe da
inserire "Hotel dolce vita", mentre loro stessi scrivono "Hotel Dolce Vita"
http://www.hotel-dolcevita.it/




>
> Ho cercato di raccogliere tutte le convenzioni ISTAT che abbiamo deciso di
> seguire e le regole di inserimento di cui abbiamo discusso in mailing list
> negli ultimi anni.
>


comunque, oltre alle regole che decidiamo noi per il paese, ci sono quelle
regole principali, universali, come "ground truth", "verificabilità" e c'è
la situazione legale.

Non dico che ISTAT non ha alcun valore, è un altro punto di vista, sempre
ben venuto, e visto che loro sono la statistica nazionale, ha sicuramente
senso poter utilizzare i nostri dati facilmente con i loro dati, ma non
vuol dire che dobbiamo adeguare i nostri _nomi_, invece si potrebbe
aggiungere un tag "name:istat" per la versione secondo ISTAT.

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

[Talk-it] Nomi delle strade e numeri civici

[Andrea Musuruane]

Ciao,
   vi avevo già scritto a inizio anno, dicendo che ho modificato le
seguenti pagine della wiki:
https://wiki.openstreetmap.org/wiki/IT:Key:name
https://wiki.openstreetmap.org/wiki/IT:Italian_Roads_Tagging#name
https://wiki.openstreetmap.org/wiki/IT:Editing_Standards_
and_Conventions#Nomi_delle_strade

Le prime due ora fanno riferimento all'ultima, in modo da avere un unico
posto dove sono inserite le regole per i nome delle strade.

Ho cercato di inserire - in modo sintetico - le informazioni principali
riportate dall'ISTAT, evidenziando le eccezioni di OpenStreetMap (nomi NON
tutti in maiuscolo, uso di lettere accentante, prima lettera maiuscola,
ecc).

In seguito ai feedback ricevuti, ho fatto qualche modifica per specificare
meglio quando usare l'iniziale maiuscola.

Inoltre, ho creato una versione italiana della la pagina sugli indirizzi:
https://wiki.openstreetmap.org/wiki/IT:Addresses

Infatti non c'era ancora e, oltre alla traduzione della parte originaria in
inglese, mancava anche un riferimento dove fossero scritte tutte le regole
specifiche per la comunità italiana:
https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_specifiche_per_l.27Italia

Ho cercato di raccogliere tutte le convenzioni ISTAT che abbiamo deciso di
seguire e le regole di inserimento di cui abbiamo discusso in mailing list
negli ultimi anni.

Ogni commento è, ovviamente, ben accetto.

Ciao,

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

Re: [Talk-ca] Talk-ca Digest, Vol 119, Issue 9

[Jonathan Brown]

I concur on the point of needing to tie the mapathon activity into a local 
problem-solving task if it is going to address the expectations of provincial 
and territorial curricula. Keith, I like the idea of accessibility. I think 
Clifford would agree that the accessibility challenge has a direct link to the 
curricula (secondary and postsecondary) through the principles of Universal 
Design for Learning (i.e., what’s necessary for some is good for all – machine 
readable closed captioning formats that support muting while viewing a video in 
a noise-sensitive public space). 

It would be good to identify a number of challenges that could be tied to 
cross-curricular tasks like the one on accessibility. For example, we are also 
looking at climate change and using open source resources like iTree for 
assessing and managing forests and community trees http://www.itreetools.org/ 
to estimate  the value of trees in adapting to climate change. The other one we 
came up with is the inequity of access to free internet and other resources 
needed to support the education and career/life goals of students in urban, 
rural and remote and communities. Here are some other project ideas from 
Development Seed https://www.developmentseed.org/projects/

Lastly, I wonder with how the education sectors are jumping on the coding 
STE[A]M bandwagon there might be ways to incorporate critical thinking into a 
mapathon activity. For example, the Green Schools tree planting initiative may 
increase the gap between inner-city schools with no where to plant trees and 
those in neighbourhoods with the green space to take advantage of these types 
of government-funded programs. For example, using machine learning to scaffold 
the tasks based on skill level 
https://www.developmentseed.org/blog/2017/09/15/power-mapping-with-machine-learning/
 or using DigitalGlobe’s Building Footprint to simplify the task of selecting 
buildings in OSM 
http://explore.digitalglobe.com/rs/782-PEE-248/images/Building_Footprints.pdf. 

Students become immediately invested and are motivated and informed when they 
go to speak to their communities about the value of trees. For example, they 
can extrapolate nice reports from iTreeDesign to back up what they are doing 
with data analysis and data visualization. They can also use these reports to 
construct a persuasive, evidence-based pitch to council about the value over 
the next 99 years of planting a tree in a specific location (e.g. school yard, 
park or home). Not only do they demonstrate the economic value of trees through 
site analysis, they can also demonstrate the aesthetic value of publicly-owned 
and privately-owned trees for the citizen’s and wildlife’s health and wellbeing 
in a neighbourhood. This information can be used to augment a place-based 
forest management strategy.

Keith the OpenSideWalks example could easily be adapted to other challenges and 
applied to school yards and other  public  spaces. Thanks for sharing that. The 
other one that would work is Cycle Travel: http://cycle.travel/

Clifford, can we set up a conference call with the Manitoba group your working 
with to share ideas? Here is one example of how a professor at the University 
of Guelph is working with high school teachers to connect math and GIS to the 
Ontario grade 12 data management course: 
https://mathstat.uoguelph.ca/outreach/opendata

Alessandro has limited resources to work with their developer on a simple 
process for exporting data from OSM to other data analysis environments (e.g., 
through APIs or something like arcgis-osm editor in GitHUB)


Jonathan 

From: talk-ca-requ...@openstreetmap.org
Sent: Wednesday, January 24, 2018 7:00 AM
To: talk-ca@openstreetmap.org
Subject: Talk-ca Digest, Vol 119, Issue 9

Send Talk-ca mailing list submissions to
talk-ca@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-ca
or, via email, send a message with subject or body 'help' to
talk-ca-requ...@openstreetmap.org

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

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


Today's Topics:

   1. Re: BC2020i and Mapathons with High Schools (Clifford Snow)


--

Message: 1
Date: Tue, 23 Jan 2018 22:16:31 -0800
From: Clifford Snow 
To: keith hartley 
Cc: "Alasia, Alessandro \(STATCAN\)" ,
Steven Hills , talk-ca

Subject: Re: [Talk-ca] BC2020i and Mapathons with High Schools
Message-ID:

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

On Tue, Jan 23, 2018 at 8:30 PM, keith hartley 

Re: [OSM-talk-fr] Fwd: [OSM-Science] Openstreetmap background in scientific paper

[Christian Quest]

La notion de produced work est valable dans le cadre de l'ODbL, donc vis 
à vis des données.


En tout cas, il est faux de dire "OpenStreetMap derived products should 
be released under a CC-BY-SA licence"


Si je fais un rendu des données OSM sous licence ODbL, je fais un 
produced work, je peux le mettre dans n'importe quelle licence car on 
n'est plus dans le cadre d'une database.


Donc oui, c'est la licence choisie pour le rendu qui importe si c'est ça 
sur quoi tu t'appuie dans ta publication.


Si il est en CC-by-SA, ça coince effectivement... sauf si on considère 
que ce n'est qu'une citation (car ce n'est pas une copie complète du 
rendu qui couvre sûrement le monde entier sur de multiples zoom).


De quel rendu s'agit-il ? Il est aussi possible de demander à son auteur 
de faire jouer cette possibilité de citation.



Il y a quand même beaucoup de publication qui ne se sont pas embarrassée 
de ce genre de chose, et côté OSM, on est plutôt très content de voir 
des cartes OSM dans des publications scientifiques !




Le 24/01/2018 à 15:56, Vincent Bergeot a écrit :


Bonjour,

occasion de diffuser l'info concernant cette nouvelle liste de 
discussion (scie...@openstreetmap.org : 
https://lists.openstreetmap.org/listinfo/science)


Et avoir votre avis ? J'ai tendance à penser que cela dépend de la 
licence sur le rendu du fond qu'ils ont utilisé ?




 Message transféré 
Sujet : [OSM-Science] Openstreetmap background in scientific paper

Dear all,
I hope this my first question is pertinent to this new OSM list...
We have recently submitted a scientific paper to an open access 
journal. One figure has an OpenStreetMap background, correctly attributed.
One reviewer has argued that that figure can't be included in the 
paper because OpenStreetMap derived products should be released under 
a CC-BY-SA licence, while the paper will be released with a CC-BY licence.
My point is to consider a figure with OSM background as a Produced 
work 
(https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline) 
and so not bounded to the SA condition.

What are your experiences and suggestions with this (or similar) issue?



--
Christian Quest - OpenStreetMap France

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

Re: [Talk-de] Königreich Württemberg - Wikidata

[Martin Koppenhoefer]

Am 24. Januar 2018 um 15:21 schrieb Markus :

> > Nachdem sich hier alle einig waren
>
> Hm - die Einigkeit bestand darin, dass "sowas"
> *besser bei Wikidata aufgehoben ist*.
>



es besteht Einigkeit (auch dokumentiert, z.B. hier:
https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_historic_events_and_historic_features
und hier https://wiki.openstreetmap.org/wiki/Verifiability und hier
https://wiki.openstreetmap.org/wiki/Lifecycle_prefix etc.), dass nicht mehr
bestehende administrative Grenzen und Gebietskörperschaften nicht gemappt
werden. Hier überhaupt nochmal einen Thread deswegen zu starten habe ich
nur gemacht, weil die Objekte immerhin relativ gut gemappt waren ;-)



>
> > habe ich mich mal an Württemberg gemacht.
> > Die Relation ist ja schnell gelöscht, aber die ways, die mit
> > Hohenzollern habe ich gleich mitgelöscht
> >
> > Unterm Strich war das sicher viel Arbeit, diese Relationen anzulegen
>
> Ich hoffe, Du hast sie nach Wikidata "gerettet"?!
>
>

ehrlich gesagt war es so schon Arbeit, die ohne Diskussion hier 1-2 Stunden
gedauert hat (inkl. JOSM Absturz). Wie man so was nach Wikidata kopieren
kann, ist mir unklar, was ich aber weiss ist dass die Sachen aus der
history geholt werden können, auch per overpass-API (AFAIK), insofern sind
sie nicht einfach weg, insbesondere, weil ich jeweils die Relationen-IDs
angegeben habe, so dass man sie leicht finden kann.


Ich fände es gut, wenn wir Prozessregeln aufstellen
> und die zur Umsetzung erforderlichen Tools bauen:
> 1. Historische Geo-Daten gehören nach Wikidata.
>


keine Ahnung, das muss Wikidata entscheiden.



> 2. Wenn jemand sich die Mühe gemacht hat, historische Daten in OSM
> einzupflegen (JOSM und QGIS sind dafür gute Werkzeuge), dann
> 3. sind die historischen Daten nach Wikidata zu transferieren
> 4. /bevor/ sie in OSM gelöscht werden.
>


das halte ich nicht für praktizierbar oder sinnvoll. Wer sich für solche
Daten interessiert, soll sie dort eintragen, wo sie gern genommen werden,
nicht bei OSM, wo sie seit vielen Jahren erklärtermaßen nicht erwünscht
sind. Erinnerst Du Dich noch an Roßleben? Vor Jahren gab es dort einen sehr
aktiven Mapper, der historische Daten von nicht mehr existenten Dingen
relativ systematisch eingetragen hat, nach einiger Zeit war die Gegend kaum
noch editierbar, weil so viele Schichten "Verschwundenes" die Realität
überdeckt haben.



> Mit graut vor einer "wikipeiaesken" Kultur bei OSM.
> "Gelöscht" ist so schnell...
>


im Unterschied zur WP kann man bei uns gelöschte Dinge auch dann sehen,
wenn man kein Admin ist. Ansonsten gebe ich Dir Recht, die Kultur bei WP
ist nicht grundsätzlich nachahmenswert, ich bin da auch schon mehrmals
unangenehmen Erfahrungen ausgesetzt gewesen.



> Die damit zerstörte Motivation und der dadurch erzeugte Frust sind duch
> nichts mehr wiedergutzumachen :-(
>


ich finde, ich habe hier nicht "einfach" gelöscht, sondern parallel zwecks
Doku diesen Thread hier alimentiert und dem Ersteller per Changeset
Kommentar eine Nachricht zukommen lassen (hatte den Eindruck, er wusste
schon, dass er das eigentlich gar nicht hätte eintragen sollen).


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

Re: [Talk-it] FOSS4G-IT 2018

[Martin Koppenhoefer]

alternante con FOSSGIS (quindi ricaricate se non lo vedete)

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

Re: [Talk-it] FOSS4G-IT 2018

[Martin Koppenhoefer]

Segnalo che il banner è online, su osm.org

Grazie a tutti per i commenti e aiuti!

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

[OSM-talk-fr] Fwd: [OSM-Science] Openstreetmap background in scientific paper

[Vincent Bergeot]

Bonjour,

occasion de diffuser l'info concernant cette nouvelle liste de 
discussion (scie...@openstreetmap.org : 
https://lists.openstreetmap.org/listinfo/science)


Et avoir votre avis ? J'ai tendance à penser que cela dépend de la 
licence sur le rendu du fond qu'ils ont utilisé ?




 Message transféré 
Sujet : [OSM-Science] Openstreetmap background in scientific paper

Dear all,
I hope this my first question is pertinent to this new OSM list...
We have recently submitted a scientific paper to an open access journal. 
One figure has an OpenStreetMap background, correctly attributed.
One reviewer has argued that that figure can't be included in the paper 
because OpenStreetMap derived products should be released under a 
CC-BY-SA licence, while the paper will be released with a CC-BY licence.
My point is to consider a figure with OSM background as a Produced work 
(https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Produced_Work_-_Guideline) 
and so not bounded to the SA condition.

What are your experiences and suggestions with this (or similar) issue?


Merci

--
Vincent Bergeot

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

[OSM-talk] OpenWhateverMap

[Ilya Zverev]

Hi folks,

I think you'd be happy to know I've revived the OpenWhateverMap, originally by 
Grant Slater:

http://openwhatevermap.xyz/

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

Re: [Talk-de] Königreich Württemberg - Wikidata

[Frederik Ramm]

Hi,

On 24.01.2018 15:21, Markus wrote:
> Hm - die Einigkeit bestand darin, dass "sowas"
> *besser bei Wikidata aufgehoben ist*.

Du meinst "OpenHistoricalMap"? Wikidata hat ja keine Geometrien.

> 2. Wenn jemand sich die Mühe gemacht hat, historische Daten in OSM
> einzupflegen (JOSM und QGIS sind dafür gute Werkzeuge), dann
> 3. sind die historischen Daten nach Wikidata zu transferieren
> 4. /bevor/ sie in OSM gelöscht werden.

Das geht so nicht. Maximal ginge: "... dann ist demjenigen eine Frist
von 4 Wochen einzuräumen, um die Daten nach OHM zu übertragen, bevor sie
in OSM gelöscht werden". Sonst wäre die Last des Übertragens nach OHM ja
bei uns. Aber auch wenn die Daten bei uns gelöscht sind, kriegt man sie
immer noch leicht aus der History zurück. Vielleicht würde es reichen,
ein "Verzeichnis gelöschter historischer Objekte" in OSM anzulegen, aus
dem sich OHM-Fans dann bei Bedarf bedienen können...

Bye
Frederik

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

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

Re: [Talk-it] Aggiornamento IIS Avogadro (OSM va a scuola)

[Cascafico Giovanni]

Ho iniziato ad inserire gli utenti che hai segnalato... ma mi son fermato
ad ITI-Avogadro02.. puoi andare avanti a costruire il filtro [1] che ho
iniziato. Ci puoi anche mettere un RSS [2] in Telegram, così quando
qualcuno edita, ti arriva il msg :-)

Il giorno 24 gennaio 2018 15:13, mbranco2  ha scritto:


> Perciò come doppio controllo li ho fatti registrare con gli
> account ITI-Avogadro01, ITI-Avogadro02 ITI-Avogadro25, quindi non
> dovrebbe sfuggire niente.
>

[1]
https://osmcha.mapbox.com/filters?aoi=f89a53af-66d1-4c3d-9fbf-1a9919ea3512
[2]
https://osmcha.mapbox.com/api/v1/aoi/f89a53af-66d1-4c3d-9fbf-1a9919ea3512/changesets/feed/
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] Königreich Württemberg - Wikidata

[Markus]

Hallo Martin,

> Nachdem sich hier alle einig waren

Hm - die Einigkeit bestand darin, dass "sowas"
*besser bei Wikidata aufgehoben ist*.

> habe ich mich mal an Württemberg gemacht. 
> Die Relation ist ja schnell gelöscht, aber die ways, die mit
> Hohenzollern habe ich gleich mitgelöscht
> 
> Unterm Strich war das sicher viel Arbeit, diese Relationen anzulegen

Ich hoffe, Du hast sie nach Wikidata "gerettet"?!

> daher finde ich es einerseits bedauerlich, dass alles wieder "gelöscht"
> wurde, andererseits gibt es sehr viele historische Grenzen 
> und verblichene Objekte, und es gibt dazu mittlerweile klare
> Regeln, dass diese historischen Dinge nicht in OSM gehören

Ich fände es gut, wenn wir Prozessregeln aufstellen
und die zur Umsetzung erforderlichen Tools bauen:
1. Historische Geo-Daten gehören nach Wikidata.
2. Wenn jemand sich die Mühe gemacht hat, historische Daten in OSM
einzupflegen (JOSM und QGIS sind dafür gute Werkzeuge), dann
3. sind die historischen Daten nach Wikidata zu transferieren
4. /bevor/ sie in OSM gelöscht werden.

zu 3:
Hier brauchen wir ein Tool, das das simpel ermöglicht.
Vielleicht eine Aufgabe für Stefan?
Oder für das JOSM-Team?
--> Wer kann das dort als "Issue" einbringen?

zu 2:
Hier brauchen wir ein Tool, das auf der Basis von OSM direkt Wikidata
Properties erzeugt.
Vielleicht kann man dazu das Tool von 3. nutzen?

- - - -

Mit graut vor einer "wikipeiaesken" Kultur bei OSM.
"Gelöscht" ist so schnell...
Die damit zerstörte Motivation und der dadurch erzeugte Frust sind duch
nichts mehr wiedergutzumachen :-(

Mit besorgten Grüssen,
Markus

PS: selbstverständlich gibt es Dinge, die "einfach so" gelöscht werden
dürfen - aber auch damit ist sorgfältig umzugehen. Denn nicht alles, was
auf den ersten Blick "nicht hierher" gehört, ist nach einem zweiten
Blick immer noch so.

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

Re: [Talk-it] Aggiornamento IIS Avogadro (OSM va a scuola)

[mbranco2]

Grazie @ale della possibilità, prossimamente la sfrutteremo di sicuro!
(anche se ha avuto la sua finalità didattica, quello di capire/scoprire che
zona geografica è "l'anfiteatro morenico di Ivrea", e poi di rovistarci
dentro cercando un posto e "riservandoselo" per evitare conflitti con gli
altri)

@Giovanni, grande idea, adesso "ti chiedo l'amicizia" in osm :-))
In effetti se mi darete una mano, riuscirò ad andare a letto prima,
prossimamente...
Datemi un paio di giorni: domani gli ribadisco le cose-base tipo
ortogonalizzare  gli edifici e non metterli sopra le strade, quindi faremo
le correzioni.
Dopodichè, se trovate qualcosa che non va, commentategli pure i changeset
e/o contattateli sul loro account OSM, così cominciano ad interagire con la
comunità.
Per tutto il progetto metteremo il tag "#ASL-Avogadro18" su tutti i
changeset (ma io per primo mi sono a volte dimenticato di mettere hashtags,
in progetti di import oppure di HOT...)
Perciò come doppio controllo li ho fatti registrare con gli
account ITI-Avogadro01, ITI-Avogadro02 ITI-Avogadro25, quindi non
dovrebbe sfuggire niente.

Il giorno 24 gennaio 2018 14:24, Cascafico Giovanni 
ha scritto:

> Bravi!
> Avete usato un tag specifico per i changeset, così magari ci diamo
> un'occhiata?
>
> Il giorno 24 gennaio 2018 13:39, mbranco  ha scritto:
>
>> Ciao Lista,
>> vi aggiorno sull'attività in corso, che vi avevo anticipato in [1] :
>>
>> il progetto è iniziato il 17 gennaio e ad oggi abbiamo fatto 3 incontri (7
>> ore), nei quali abbiamo fatto un'ntroduzione generale alla cartografia,
>> parlato di open data e open source, imparato ad usare le varie
>> funzionalità
>> del sito (osm.org).
>> Nell'ultimo incontro (di lunedì scorso) abbiamo imparato ad usare iD, gli
>> studenti si sono registrati e hanno cominciato a fare la prima mappatura:
>> per evitare di iniziare con le difficoltà tipiche dell'area metropolitana
>> abbiamo deciso di cominciare a mappare "in campagna", limitandoci per ora
>> all'edificato, e scegliendo come zona l'anfiteatro morenico di Ivrea.
>> Ci siamo fatti un tasking manager casalingo :-) (uno spreadsheet
>> condiviso... ) dove ogni studente ha indicato il paese che sceglieva
>> perchè
>> poco mappato, e sono partiti.
>> Gli avevo chiesto di fare "qualche" building a testa, che domani li
>> avremmo
>> rivisti insieme, ma sto vedendo ora che siamo già a più di 1000 building!
>> Di strafalcioni (strade che attraversano case, ecc) ovviamente ne stanno
>> facendo, ma correggeremo tutto, promesso!
>>
>> Alla prossima,
>> Marco
>>
>>
>> [1] http://gis.19327.n8.nabble.com/OSM-va-a-scuola-tp5909681.html
>>
>>
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[Erwan Salomon]

> Le 24 janv. 2018 à 12:11, marc marc  a écrit :
> 
> 
> surtout pour maps.me qui est connu pour gérer que partiellement
> les polygones.
> 

Je viens de vérifier
il se trouve que maps.me s’en sort bien cette fois ci
il affiche la relation avec « Mer Noire » 
et un peu plus bas le nœud avec « Black Sea » 
du coup ça fait bien doublon
passer le nœud en label pourrait être une solution, mais il semble que les 
relations multipolygones proscrivent l’usage des nœuds (je passe la mains aux 
habitués des relations) 

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

Re: [Talk-it] Aggiornamento IIS Avogadro (OSM va a scuola)

[Cascafico Giovanni]

Bravi!
Avete usato un tag specifico per i changeset, così magari ci diamo
un'occhiata?

Il giorno 24 gennaio 2018 13:39, mbranco  ha scritto:

> Ciao Lista,
> vi aggiorno sull'attività in corso, che vi avevo anticipato in [1] :
>
> il progetto è iniziato il 17 gennaio e ad oggi abbiamo fatto 3 incontri (7
> ore), nei quali abbiamo fatto un'ntroduzione generale alla cartografia,
> parlato di open data e open source, imparato ad usare le varie funzionalità
> del sito (osm.org).
> Nell'ultimo incontro (di lunedì scorso) abbiamo imparato ad usare iD, gli
> studenti si sono registrati e hanno cominciato a fare la prima mappatura:
> per evitare di iniziare con le difficoltà tipiche dell'area metropolitana
> abbiamo deciso di cominciare a mappare "in campagna", limitandoci per ora
> all'edificato, e scegliendo come zona l'anfiteatro morenico di Ivrea.
> Ci siamo fatti un tasking manager casalingo :-) (uno spreadsheet
> condiviso... ) dove ogni studente ha indicato il paese che sceglieva perchè
> poco mappato, e sono partiti.
> Gli avevo chiesto di fare "qualche" building a testa, che domani li avremmo
> rivisti insieme, ma sto vedendo ora che siamo già a più di 1000 building!
> Di strafalcioni (strade che attraversano case, ecc) ovviamente ne stanno
> facendo, ma correggeremo tutto, promesso!
>
> Alla prossima,
> Marco
>
>
> [1] http://gis.19327.n8.nabble.com/OSM-va-a-scuola-tp5909681.html
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[Charles MILLET]

C'était bien le nœud il semble car sur www.mapcat.com on voit bien Mer 
Noire. Merci encore marc marc.


On 24/01/2018 12:31, Charles MILLET wrote:
Bien vu ! J'avais (trop) rapidement cherché la présence d'un nœud mais 
sans succès. Je fais la mise à jour du nœud pour le test.


Concernant la suppression du doublon, je n'ai pas une bonne vision des 
avantages et inconvénient alors je n'ai pas d'avis.


On 24/01/2018 12:11, marc marc wrote:

Peut-être parce qu'il n'y a pas de name:fr sur le nœud doublon
du poylgone (comme pour 13 autre name:xx)
https://www.openstreetmap.org/node/4347858678
https://www.openstreetmap.org/relation/7160849
surtout pour maps.me qui est connu pour gérer que partiellement
les polygones.

L'idéal serrait de supprimer le doublon.
un contributeur a d’ailleurs mis un fixme pour cela.
Mais dans la pratique j'ajouterai les names:xx manquant
+ poser la question sur une ml internationale pour voir
s'il y a un consensus pour virer le doublon (je n'ai pas
regardé si le wiki donne une explication au doublon)

Le 24. 01. 18 à 11:52, Francescu GAROBY a écrit :

Bonjour,
"frr" est le code pour le frison septentrional
, une langue
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
"name:frr" devraient être traités distinctement. Sauf à penser que le
code qui recherche la langue recherche une clé *commençant par* 
"name:fr"...


Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET > a écrit :

 Bonjour,

 J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
 vérifié aussi sur www.mapcat.com ), la Mer
 Noire n'est pas nommée en français alors que la clé name:fr est 
bien

 renseignée. Par contre il y a le tag name:frr=Suart Sia. Et j'ai
 cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je 
pense
 que le problème d'affichage du nom en français vient peut-être 
de la

 présence de cette clé mais je n'ai pas de piste pour corriger le
 problème sans me mettre à dos tout un pays... Si quelqu'un a une
 idée je suis preneur.

 Bonne journée.


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




--
Francescu


___
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-it] FOSS4G-IT 2018

[stefano campus]

Alessandro wrote
> Un "Conferenza annuale italiana" risolve tutte le questioni 

Sono d'accordissimo con te Alessandro.
Non metterei nulla.

s.



--
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-ca] BC2020i and Mapathons with High Schools

[john whelan]

I would still make the comment that it is a live map and even University
> students can get creative.
>
> I would recommend having someone go over the edits carefully.  Ideally an
> experienced validator.  Both from the point of view of accuracy and also to
> give feedback to the students.  If you're mapping in Canada be aware people
> will not welcome inaccurate mapping and can be quite vocal about it.  Don't
> assume because you are a teacher you know enough about the subject.
> Locally a University professor asked their students to add detail to the
> map but restrict it to on Campus.  They didn't restrict themselves and I
> believe both added and modified existing data incorrectly which took
> considerable clean up effort from a number of local mappers.
>
> The more flexibility you give the students the steeper the learning
> curve.  It takes about an hour before a new adult mapper feels comfortable
> adding building outlines.
>
> When working with Bjenk on the Canadian building project it was apparent
> that the building outline was only part of what they were after.
> Alessandro was the first person I've seen to accurately map a building
> outline in iD so it can be done. The other information they were after was
> the number of floors.  How many does a split level have by the way?  The
> use, commercial, residential etc.  Ask Alessandro nicely and he might even
> give you a list of what they are after.  StreetComplete runs on an Android
> smartphone and can be used to add this type of data.
>
> On the visually impaired side we have special tactile pads in the side
> walk at junctions but I haven't worked out how to map and tag them yet and
> I'm fairly experienced.
>
> If you go a HOT project then in theory they have validators on their
> projects.  Bug me nicely and I might even point you to one that is actively
> validated.
>
> The following maybe of interest.
>
> https://wiki.openstreetmap.org/wiki/Education
>
> The links contained give access to people who have done it before.
>
> Cheerio John
>
>
>
>
>
> On 23 January 2018 at 23:30, keith hartley 
> wrote:
>
>> Hi Jonathan,
>> I work with a GIS users group in Manitoba (MGUG.ca) and we were talking
>> about how to use OSM as a learning tool for high school students as well.
>> From our education sub-committee we discussed that building footprints or
>> adding roads doesn't add to what the provincial high school geo subject
>> curriculum needs. One suggestion was rather then adding new data and
>> supervising edits, we can augment the map to be more detailed. (better
>> trails, active transport, or building accessibility for disabled people)
>>
>> One example  would be addressing mobility and accessibility around the
>> school. If we could get a few high schools within an area to participate,
>> we could could add buildings that are accessible via ramps ect, or maybe
>> signaled crosswalks. That information could show the students issues that
>> vision impaired, or mobility restricted people face, while at the same time
>> improving the map. (similar to wheel map https://wheelmap.org)
>>
>> We're still at the discussion stage, but just a thought!
>>
>> Thanks,
>> Keith
>>
>>
>>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-it] Aggiornamento IIS Avogadro (OSM va a scuola)

[mbranco]

Ciao Lista,
vi aggiorno sull'attività in corso, che vi avevo anticipato in [1] :

il progetto è iniziato il 17 gennaio e ad oggi abbiamo fatto 3 incontri (7
ore), nei quali abbiamo fatto un'ntroduzione generale alla cartografia,
parlato di open data e open source, imparato ad usare le varie funzionalità
del sito (osm.org).
Nell'ultimo incontro (di lunedì scorso) abbiamo imparato ad usare iD, gli
studenti si sono registrati e hanno cominciato a fare la prima mappatura:
per evitare di iniziare con le difficoltà tipiche dell'area metropolitana
abbiamo deciso di cominciare a mappare "in campagna", limitandoci per ora
all'edificato, e scegliendo come zona l'anfiteatro morenico di Ivrea.
Ci siamo fatti un tasking manager casalingo :-) (uno spreadsheet
condiviso... ) dove ogni studente ha indicato il paese che sceglieva perchè
poco mappato, e sono partiti.
Gli avevo chiesto di fare "qualche" building a testa, che domani li avremmo
rivisti insieme, ma sto vedendo ora che siamo già a più di 1000 building!  
Di strafalcioni (strade che attraversano case, ecc) ovviamente ne stanno
facendo, ma correggeremo tutto, promesso!

Alla prossima,
Marco


[1] http://gis.19327.n8.nabble.com/OSM-va-a-scuola-tp5909681.html





--
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] FOSS4G-IT 2018

[Alessandro]

Il 24/01/2018 12:41, stefano campus ha scritto:

...
eviterei, dal mio punto di vista, di dare etichette di paternità esclusiva
ma anzi che siano il più possibile inclusive.

s.



Un "Conferenza annuale italiana" risolve tutte le questioni :-)

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

Re: [Talk-it] FOSS4G-IT 2018

[Marco Minghini]

eviterei, dal mio punto di vista, di dare etichette di paternità esclusiva
> ma anzi che siano il più possibile inclusive.
>

ciao Stefano,
non volevo dare nessuna etichetta, solo far notare che scrivere "nona
edizione" sopra al logo del FOSS4G-IT non è corretto.
La nona edizione è "solo" di OSMit!
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] FOSS4G-IT 2018

[stefano campus]

ciao marco, è pur vero però che FOSS4G IT 2018 comprende il XIX Meeting degli
utenti italiani di GRASS e  il XI GFOSS DAY.
Lo scopo di FOSS4G è appunto condividere le esperienze e unire le comunità.
non mi sento di dire che FOSS4G IT 2018 è l'evento di gfoss.it nè che sia
osmit 2018.
eviterei, dal mio punto di vista, di dare etichette di paternità esclusiva
ma anzi che siano il più possibile inclusive.

s.



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

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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[Charles MILLET]

Bien vu ! J'avais (trop) rapidement cherché la présence d'un nœud mais 
sans succès. Je fais la mise à jour du nœud pour le test.


Concernant la suppression du doublon, je n'ai pas une bonne vision des 
avantages et inconvénient alors je n'ai pas d'avis.


On 24/01/2018 12:11, marc marc wrote:

Peut-être parce qu'il n'y a pas de name:fr sur le nœud doublon
du poylgone (comme pour 13 autre name:xx)
https://www.openstreetmap.org/node/4347858678
https://www.openstreetmap.org/relation/7160849
surtout pour maps.me qui est connu pour gérer que partiellement
les polygones.

L'idéal serrait de supprimer le doublon.
un contributeur a d’ailleurs mis un fixme pour cela.
Mais dans la pratique j'ajouterai les names:xx manquant
+ poser la question sur une ml internationale pour voir
s'il y a un consensus pour virer le doublon (je n'ai pas
regardé si le wiki donne une explication au doublon)

Le 24. 01. 18 à 11:52, Francescu GAROBY a écrit :

Bonjour,
"frr" est le code pour le frison septentrional
, une langue
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
"name:frr" devraient être traités distinctement. Sauf à penser que le
code qui recherche la langue recherche une clé *commençant par* "name:fr"...

Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET > a écrit :

 Bonjour,

 J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
 vérifié aussi sur www.mapcat.com ), la Mer
 Noire n'est pas nommée en français alors que la clé name:fr est bien
 renseignée. Par contre il y a le tag name:frr=Suart Sia. Et j'ai
 cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je pense
 que le problème d'affichage du nom en français vient peut-être de la
 présence de cette clé mais je n'ai pas de piste pour corriger le
 problème sans me mettre à dos tout un pays... Si quelqu'un a une
 idée je suis preneur.

 Bonne journée.


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




--
Francescu


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


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



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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[Francescu GAROBY]

En cherchant "frr" dans Wikipedia, on arrive sur cette page de résultats
.


Francescu

Le 24 janvier 2018 à 12:24, Charles MILLET  a écrit :

> Merci Francescu pour l'info. Je suis curieux de savoir comment tu as
> trouvé la référence au code, je ne l'ai pas vue dans la page
> https://wiki.openstreetmap.org/wiki/Multilingual_names et d'autre pages
> internet dédiées aux codes (peut-être trop orientées pays).
>
> Concernant le problème d'affiche, j'avais imaginé la même hypothèse que
> toi... mais marc marc a remarqué que le nœud en doublon n'avait pas la clé
> name:fr
>
>
> On 24/01/2018 11:52, Francescu GAROBY wrote:
>
> Bonjour,
> "frr" est le code pour le frison septentrional
> , une langue
> d'Allemagne.
> Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
> "name:frr" devraient être traités distinctement. Sauf à penser que le code
> qui recherche la langue recherche une clé *commençant par* "name:fr"...
>
> Francescu
>
> Le 24 janvier 2018 à 11:45, Charles MILLET  a
> écrit :
>
>> Bonjour,
>>
>> J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai vérifié
>> aussi sur www.mapcat.com), la Mer Noire n'est pas nommée en français
>> alors que la clé name:fr est bien renseignée. Par contre il y a le tag
>> name:frr=Suart Sia. Et j'ai cherché à quoi correspondait FRR mais je n'ai
>> rien trouvé. Je pense que le problème d'affichage du nom en français vient
>> peut-être de la présence de cette clé mais je n'ai pas de piste pour
>> corriger le problème sans me mettre à dos tout un pays... Si quelqu'un a
>> une idée je suis preneur.
>>
>> Bonne journée.
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Francescu
>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [Talk-it] Vecchia calchera

[liste DOT girarsi AT posteo DOT eu]

Il 24/01/2018 11:48, Volker Schmidt ha scritto:

2018-01-24 11:17 GMT+01:00 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu>:



In questo caso la fornace è un vero e proprio muro a secco circolare,
interrato o con sbancamento di terra ai bordi.

Per essere precisi, questo non è corretto: Il way del retaining_wall

definisce la posizione della superficie interna del muro (di parecchio
spessore) della fornace.
Sono d'accordo che bisogna aggiungere o un area o un nodo dove mettere i
tag descrittivi.
Candidato per l'area potrebbe essere la recinzione.




In questo caso ci starebbe, ma nei molti altri, la recinzione non c'è.

Una seconda way circolare della stessa geometria del retaining_wall, con 
landuse=gravel ad indicare il fondo, ci stà come complemento del 
multipoligono?


Praticamente farei come membri outer il muro e il fondo ghiaioso.


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

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

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[Charles MILLET]

Merci Francescu pour l'info. Je suis curieux de savoir comment tu as 
trouvé la référence au code, je ne l'ai pas vue dans la page 
https://wiki.openstreetmap.org/wiki/Multilingual_names et d'autre pages 
internet dédiées aux codes (peut-être trop orientées pays).


Concernant le problème d'affiche, j'avais imaginé la même hypothèse que 
toi... mais marc marc a remarqué que le nœud en doublon n'avait pas la 
clé name:fr



On 24/01/2018 11:52, Francescu GAROBY wrote:

Bonjour,
"frr" est le code pour le frison septentrional 
, une langue 
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et 
"name:frr" devraient être traités distinctement. Sauf à penser que le 
code qui recherche la langue recherche une clé *commençant par* 
"name:fr"...


Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET > a écrit :


Bonjour,

J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
vérifié aussi sur www.mapcat.com ), la Mer
Noire n'est pas nommée en français alors que la clé name:fr est
bien renseignée. Par contre il y a le tag name:frr=Suart Sia. Et
j'ai cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je
pense que le problème d'affichage du nom en français vient
peut-être de la présence de cette clé mais je n'ai pas de piste
pour corriger le problème sans me mettre à dos tout un pays... Si
quelqu'un a une idée je suis preneur.

Bonne journée.


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





--
Francescu


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


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

Re: [Talk-it] FOSS4G-IT 2018

[Marco Minghini]

Solo un commento per sottolineare che il FOSS4G-IT è alla sua seconda
edizione... piuttosto meglio menzionare OSMit (che sarà un evento interno
al FOSS4G-IT), che invece è alla nona edizione.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[marc marc]

Peut-être parce qu'il n'y a pas de name:fr sur le nœud doublon
du poylgone (comme pour 13 autre name:xx)
https://www.openstreetmap.org/node/4347858678
https://www.openstreetmap.org/relation/7160849
surtout pour maps.me qui est connu pour gérer que partiellement
les polygones.

L'idéal serrait de supprimer le doublon.
un contributeur a d’ailleurs mis un fixme pour cela.
Mais dans la pratique j'ajouterai les names:xx manquant
+ poser la question sur une ml internationale pour voir
s'il y a un consensus pour virer le doublon (je n'ai pas
regardé si le wiki donne une explication au doublon)

Le 24. 01. 18 à 11:52, Francescu GAROBY a écrit :
> Bonjour,
> "frr" est le code pour le frison septentrional 
> , une langue 
> d'Allemagne.
> Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et 
> "name:frr" devraient être traités distinctement. Sauf à penser que le 
> code qui recherche la langue recherche une clé *commençant par* "name:fr"...
> 
> Francescu
> 
> Le 24 janvier 2018 à 11:45, Charles MILLET  > a écrit :
> 
> Bonjour,
> 
> J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai
> vérifié aussi sur www.mapcat.com ), la Mer
> Noire n'est pas nommée en français alors que la clé name:fr est bien
> renseignée. Par contre il y a le tag name:frr=Suart Sia. Et j'ai
> cherché à quoi correspondait FRR mais je n'ai rien trouvé. Je pense
> que le problème d'affichage du nom en français vient peut-être de la
> présence de cette clé mais je n'ai pas de piste pour corriger le
> problème sans me mettre à dos tout un pays... Si quelqu'un a une
> idée je suis preneur.
> 
> Bonne journée.
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> 
> -- 
> Francescu
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [Talk-it] FOSS4G-IT 2018

[Martin Koppenhoefer]

nuova versione banner, senza i loghi:

V4



[image: Inline-Bild 1]



V5

[image: Inline-Bild 2]
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[Francescu GAROBY]

Bonjour,
"frr" est le code pour le frison septentrional
, une langue
d'Allemagne.
Mais tout ça n'explique pas le bug que tu rencontres : "name:fr" et
"name:frr" devraient être traités distinctement. Sauf à penser que le code
qui recherche la langue recherche une clé *commençant par* "name:fr"...

Francescu

Le 24 janvier 2018 à 11:45, Charles MILLET  a écrit :

> Bonjour,
>
> J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai vérifié
> aussi sur www.mapcat.com), la Mer Noire n'est pas nommée en français
> alors que la clé name:fr est bien renseignée. Par contre il y a le tag
> name:frr=Suart Sia. Et j'ai cherché à quoi correspondait FRR mais je n'ai
> rien trouvé. Je pense que le problème d'affichage du nom en français vient
> peut-être de la présence de cette clé mais je n'ai pas de piste pour
> corriger le problème sans me mettre à dos tout un pays... Si quelqu'un a
> une idée je suis preneur.
>
> Bonne journée.
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

[Talk-it] Sessione Accademica a State of the Map 2018

[Marco Minghini]

Ciao a tutti,
è stata pubblicata anche la call per le presentazioni accademiche per State
of the Map 2018, la trovate qui in italiano [1] e qui in inglese [2]. Per
qualsiasi dettaglio contattatemi pure!

Ricordo che si può anche mandare una proposta per una presentazione
standard [3] e, per chi necessitasse di supporto economico per partecipare,
chiedere una borsa [4].

A presto!
Marco

[1] https://2018.stateofthemap.org/it/academictrack/
[2] https://2018.stateofthemap.org/academictrack/
[3] https://blog.openstreetmap.org/2018/01/11/session-proposals-sotm-2018/
[4]
https://blog.openstreetmap.org/2018/01/17/apply-for-support-to-join-us-in-milan-for-state-of-the-map-2018/

Marco Minghini, Ph.D.
GEOlab, Politecnico di Milano - DICA
Piazza Leonardo da Vinci 32, 20133 Milano (Italy)
+39 02 23996409
marco.mingh...@polimi.it
@MarcoMinghini 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Vecchia calchera

[Volker Schmidt]

2018-01-24 11:17 GMT+01:00 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu>:

>
> In questo caso la fornace è un vero e proprio muro a secco circolare,
> interrato o con sbancamento di terra ai bordi.
>
> Per essere precisi, questo non è corretto: Il way del retaining_wall
definisce la posizione della superficie interna del muro (di parecchio
spessore) della fornace.
Sono d'accordo che bisogna aggiungere o un area o un nodo dove mettere i
tag descrittivi.
Candidato per l'area potrebbe essere la recinzione.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] Mer Noire / Black Sea – Problème d'affichage du nom français

[Charles MILLET]

Bonjour,

J'ai remarqué que dans les rendu d'OsmAnd et Maps.Me (et j'ai vérifié 
aussi sur www.mapcat.com), la Mer Noire n'est pas nommée en français 
alors que la clé name:fr est bien renseignée. Par contre il y a le tag 
name:frr=Suart Sia. Et j'ai cherché à quoi correspondait FRR mais je 
n'ai rien trouvé. Je pense que le problème d'affichage du nom en 
français vient peut-être de la présence de cette clé mais je n'ai pas de 
piste pour corriger le problème sans me mettre à dos tout un pays... Si 
quelqu'un a une idée je suis preneur.


Bonne journée.


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

Re: [Talk-it] Vecchia calchera

[liste DOT girarsi AT posteo DOT eu]

Il 24/01/2018 11:35, Martin Koppenhoefer ha scritto:

2018-01-24 11:27 GMT+01:00 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu>:



Non ha senso, perchè la fornace è solo quel muro a secco, il resto è
semmai un'area di produzione.





in una ipotetica prigione all'aperto (recinto), la prigione è solo la
recinzione, oppure anche lo spazio che viene delimitato?

Ciao,
Martin




Il recinto, lo spazio è già implicito ci sia dentro.


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

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

Re: [Talk-it] FOSS4G-IT 2018

[Martin Koppenhoefer]

2018-01-24 6:33 GMT+01:00 stefano campus :

> Ciao a tutti,
> Scusatemi non volevo creare problemi con la licenza.
> Volevo semplicemente dare un riconoscimento all'autore che ci ha dedicato
> un
> sacco di tempo.
>


va benissimo, e l'attribuzione la metterei pure sul sito della conferenza,
anche se con cc0 non è richiesto. (Vicino alla dicitura: "Business casual
is a free to use, open source Bootstrap theme created by Start Bootstrap"),
mentre per altri contesti (t-shirt, buste, banner ecc.) complica
inutilmente il lavoro.




> Nessun problema a renderlo più semplice.
> Piuttosto attenzione a non togliere il marchio de la sapienza: sono i
> padroni di casa e sono molto attenti, oltre ovviamente al fatto che sarebbe
> scortese eliminarlo.
>


nel banner non c'è spazio (oltre allo spazio fisico, non c'è possibiltà di
integrarlo visivamente, visto che è rosso bordeaux), ma posso togliere
tutti i loghi.

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

Re: [talk-au] correct mapping of overtaking lanes

[Marc Gemis]

possible tags:

lanes, lanes:forward, lanes:backward, change:lanes:forward,
change:lanes:backward

https://wiki.openstreetmap.org/wiki/Lanes
https://wiki.openstreetmap.org/wiki/Key:lanes
https://wiki.openstreetmap.org/wiki/Proposed_features/change

On Wed, Jan 24, 2018 at 8:11 AM,   wrote:
> Can someone point me to some examples of the correct method of mapping
> overtaking lanes on country highways?
>
>
>
> I need examples for where it is both permissible and not permissible for the
> contrary direction to use the overtaking lane.
>
>
>
> Thanks
>
>
>
> Ian
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [Talk-it] Vecchia calchera

[Martin Koppenhoefer]

2018-01-24 11:27 GMT+01:00 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu>:

>
> Non ha senso, perchè la fornace è solo quel muro a secco, il resto è
> semmai un'area di produzione.




in una ipotetica prigione all'aperto (recinto), la prigione è solo la
recinzione, oppure anche lo spazio che viene delimitato?

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

Re: [Talk-it] Vecchia calchera

[liste DOT girarsi AT posteo DOT eu]

Il 24/01/2018 11:20, Martin Koppenhoefer ha scritto:

si, ma la mappatura è sbagliata. Non dovrebbe essere un unico oggetto. Io
farei un way per il retaining_wall e un multipolygon che riusa questo way
per definire un'area e diventa il kiln.



Non ha senso, perchè la fornace è solo quel muro a secco, il resto è 
semmai un'area di produzione.



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

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

Re: [Talk-it] Vecchia calchera

[Martin Koppenhoefer]

2018-01-24 11:17 GMT+01:00 liste DOT girarsi AT posteo DOT eu <
liste.gira...@posteo.eu>:

> Il 24/01/2018 11:13, Martin Koppenhoefer ha scritto:
>
>> per me un "kiln" dovrebbe essere o un nodo o un'area (preferibile). Il tag
>> barrier=retaining_wall invece non può che essere messo su un way
>> (lineare),
>> quindi per me sono da separare il retaining wall dal kiln (2 oggetti).
>>
>> Ciao,
>> Martin
>>
>
> In questo caso la fornace è un vero e proprio muro a secco circolare,
> interrato o con sbancamento di terra ai bordi.
>


si, ma la mappatura è sbagliata. Non dovrebbe essere un unico oggetto. Io
farei un way per il retaining_wall e un multipolygon che riusa questo way
per definire un'area e diventa il kiln.

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

Re: [Talk-it] Vecchia calchera

[liste DOT girarsi AT posteo DOT eu]

Il 24/01/2018 11:13, Martin Koppenhoefer ha scritto:

per me un "kiln" dovrebbe essere o un nodo o un'area (preferibile). Il tag
barrier=retaining_wall invece non può che essere messo su un way (lineare),
quindi per me sono da separare il retaining wall dal kiln (2 oggetti).

Ciao,
Martin


In questo caso la fornace è un vero e proprio muro a secco circolare, 
interrato o con sbancamento di terra ai bordi.



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

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

Re: [Talk-it] Vecchia calchera

[liste DOT girarsi AT posteo DOT eu]

Il 24/01/2018 10:55, Volker Schmidt ha scritto:

- Non capisco perché utilizzi "lime_kiln" con historic, ma "kiln" con
man_made
- Poi penso che "old:" come life cycle prefix non pare corretto:
"dismantled:" o  forse "disused:"
- old:product=quicklime è ridondante nel senso che il prodotto è già
indicato con lime_kiln


Credo che per old:man_made, ed i restanti old, ho ragionato guardando 
questa pagina:


https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dkiln

Comunque il tuo ragionamento è validissimo, per cui rimetto mano ai tag 
delle varie calchere presenti in valle, in questa maniera, fatte salve 
eventuali differenze in loco:


barrier=retaining_wall

historic=lime_kiln

name=Calchèra

disused:man_madelime_kiln

surface=gravel (sul fondo c'è ghiaione)

tourism=attraction

wall=dry_stone

description:it=Storica fornace, non più in uso, per produrre calce.


operator ancora non lo conosco chi si occupa della gestione


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

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

Re: [Talk-it] Vecchia calchera

[Martin Koppenhoefer]

2018-01-24 10:55 GMT+01:00 Volker Schmidt :

>
> Hai mappato:
> barrier 
> retaining_wall
> 
> cutting 
> yes
> historic 
> lime_kiln
> layer  -1
> name  Calchèra
> *old:man_made* kiln
> *old:product* quicklime
> surface 
> gravel
> tourism 
> attraction
> 
> *wall* dry_stone
> 
>
> Vedo delle cose "migliorabili"
>
>- "cutting=yes" cosi si applica solo a strade dove il "taglio" è
>presente su entrambi i lati. C'è "cutting:left|right" per il caso che la
>strada è tagliata nel terreno solo su un lato. Ma per il caso qua penso che
>sia ridondante: "retaining_wal"l è sufficiente.
>- Layer=-1 mi sembra ridondante. La struttura è visibile e non si
>trova sotto qualcos'altro
>- Non capisco perché utilizzi "lime_kiln" con historic, ma "kiln" con
>man_made
>- Poi penso che "old:" come life cycle prefix non pare corretto:
>"dismantled:" o  forse "disused:"
>- old:product=quicklime è ridondante nel senso che il prodotto è già
>indicato con lime_kiln
>
>
per me un "kiln" dovrebbe essere o un nodo o un'area (preferibile). Il tag
barrier=retaining_wall invece non può che essere messo su un way (lineare),
quindi per me sono da separare il retaining wall dal kiln (2 oggetti).

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

Re: [talk-au] correct mapping of overtaking lanes

[Andrew Harvey]

Have you seen https://wiki.openstreetmap.org/wiki/Key:overtaking?

PS this is for overtaking by entering the lane used by traffic going in the
opposite direction, not for when a 1 lane opens up to 2 lanes to allow
overtaking.

On 24 January 2018 at 18:11,  wrote:

> Can someone point me to some examples of the correct method of mapping
> overtaking lanes on country highways?
>
>
>
> I need examples for where it is both permissible and not permissible for
> the contrary direction to use the overtaking lane.
>
>
>
> Thanks
>
>
>
> Ian
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] [OT] Administrative level risultati Nominatim

[Cascafico Giovanni]

Il giorno 24 gennaio 2018 10:51, Andrea Musuruane  ha
scritto:

> Ciao,
>
> 2018-01-24 10:36 GMT+01:00 Cascafico Giovanni :
>
>> provando in giro, pare che quando:
>> admin_centre è place=village, diventa "frazione"
>> admin_centre è place=town, diventa "villaggio"
>> admin_centre è place=city, resta "città"
>>
>
> Aggiungo:
>
> place=hamlet -> "Gruppo di case"
> place=farm -> "Area agricola"
> place=isolated_dwelling -> "Case sparse"
>
> queste ultime almeno non sono admin_centre per cui non si notano :-)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Vecchia calchera

[Volker Schmidt]

Ed infine ho mappato in questo modo:
>
> https://www.openstreetmap.org/way/397324302#map=19/46.04943/11.56621
>

Grazie di averci ricordato di questa vechia discussione. Ho guardato bene
come lo hai fatto tu, perché io ne ho mappato alcuni, ma senza il livello
di dettaglio tuo.

Hai mappato:
barrier 
retaining_wall

cutting  yes
historic 
lime_kiln
layer  -1
name  Calchèra
*old:man_made* kiln
*old:product* quicklime
surface 
gravel
tourism 
attraction

*wall* dry_stone


Vedo delle cose "migliorabili"

   - "cutting=yes" cosi si applica solo a strade dove il "taglio" è
   presente su entrambi i lati. C'è "cutting:left|right" per il caso che la
   strada è tagliata nel terreno solo su un lato. Ma per il caso qua penso che
   sia ridondante: "retaining_wal"l è sufficiente.
   - Layer=-1 mi sembra ridondante. La struttura è visibile e non si trova
   sotto qualcos'altro
   - Non capisco perché utilizzi "lime_kiln" con historic, ma "kiln" con
   man_made
   - Poi penso che "old:" come life cycle prefix non pare corretto:
   "dismantled:" o  forse "disused:"
   - old:product=quicklime è ridondante nel senso che il prodotto è già
   indicato con lime_kiln

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

Re: [Talk-it] [OT] Administrative level risultati Nominatim

[Andrea Musuruane]

Ciao,

2018-01-24 10:36 GMT+01:00 Cascafico Giovanni :

> provando in giro, pare che quando:
> admin_centre è place=village, diventa "frazione"
> admin_centre è place=town, diventa "villaggio"
> admin_centre è place=city, resta "città"
>

Aggiungo:

place=hamlet -> "Gruppo di case"
place=farm -> "Area agricola"
place=isolated_dwelling -> "Case sparse"

Direi che sono tutte traduzioni orribili:
https://github.com/openstreetmap/openstreetmap-website/blob/master/config/locales/it.yml#L772

La peggiore:
place=block -> "Blocco"

Ciao,

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

Re: [Talk-it] Vecchia calchera

[liste DOT girarsi AT posteo DOT eu]

Il 24/01/2018 09:35, Martin Koppenhoefer ha scritto:

2018-01-24 8:30 GMT+01:00 demon.box :


Interessante, ci sono nuovi spunti e non posso fare a meno di notare un
"nuovo" prefisso "old:"... Quando si usa?




non si usa ;-)
E' pratticamente inesistente:
https://taginfo.openstreetmap.org/search?q=old%3A
e il significato non è documentato (credo).

Ciao,
Martin



olendo al posto di old, metto disused, perchè coomunque può essere 
ancora usata, non mi ricordo erchè avevo messo old, forse per vecchio uso.



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

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

Re: [OSM-talk-fr] D281 en Loire-Atlantique

[Jean-Claude Repetto]

Le 24/01/2018 à 09:11, Gwenrannad a écrit :
> 
>  -> Pour la représentation de la voie :
> Le tag "highway=unclassified" est effectivement trop contraignant car il
> fait disparaitre le graphisme de la voie et qu'il serait préférable de
> lui affecter un tag de type "highway=path" de manière temporaire jusqu'à
> l'ouverture officielle de la voie avec un "access=no" pour éviter le
> routage .

Bonjour,

Tu veux dire que highway=unclassified ferait disparaître la voie de la
carte ? Si oui, pourquoi ?
highway=path ne me paraît pas adapté, car cela correspond à un sentier
(voie trop étroite pour permettre le passage d'un véhicule).

Jean-Claude

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

[Talk-cz] Fwd: Lednový Missing Maps mapathon

[Marián Kyral]

Došlo na weeklyosm...

-- Původní e-mail --
Od: Veronika Kotková 
Komu: wee...@openstreetmap.cz
Datum: 23. 1. 2018 12:43:45
Předmět: Lednový Missing Maps mapathon
"

Zdravím všechny,






poslední úterý v měsíci, tj. 30.1.2018, se opět koná pravidelný pražský
Missing Maps mapathon. Tentokrát bude akce probíhat v coworkingovém centru
Opero poblíž Staroměstského náměstí.


Místo konání:

Opero(http://www.openstreetmap.org/node/4556733089)




Registrace možná přes Eventbrite
(https://www.eventbrite.co.uk/e/lednovy-missing-maps-mapathon-v-praze-v-coworkingu-opero-registration-42272733885)


Za organizátory srdečně zve


Veronika Kotková

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

Re: [Talk-it] [OT] Administrative level risultati Nominatim

[Cascafico Giovanni]

provando in giro, pare che quando:
admin_centre è place=village, diventa "frazione"
admin_centre è place=town, diventa "villaggio"
admin_centre è place=city, resta "città"

Il giorno 24 gennaio 2018 10:17, emmexx  ha scritto:

> Ho provato a cercare un paio di comuni nella pagina principale di OSM. I
> risultati mi paiono piuttosto fuorvianti, quantomeno per l'uso di alcuni
> vocaboli che hanno un'accezione abbastanza precisa in italiano.
>
> Ricerca 1: Castelmola
> 1' risultato è "Frazione Castelmola, Messina, Sicily, Italia"
> Ma Castelmola non è una frazione ma un comune.
> Cliccando sul risultato appare la scheda con i tag che riporta
> correttamente admin_level = 8
>
> Ricerca 2: Rovato
> 1' risultato è "Villaggio Rovato, Brescia, Lombardia, Italia"
> Rovato però non lo definirei propriamente un villaggio, ha 2
> abitanti, superficie di 26 km quadrati.
> admin_level sempre 8
>
> Ricerca 3: Gallarate
> 1' risultato è "Villaggio Gallarate, Varese, Lombardia, 21013, Italia"
> Altro villaggio da 53000 abitanti
>
> Risultati simili per Busto Arsizio (8 abitanti), Cesena (96000
> abitanti).
>
> C'è sicuramente una logica (sbagliata), quale?
>
> grazie
> maxx
>
> ___
> 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] [OT] Administrative level risultati Nominatim

[emmexx]

Ho provato a cercare un paio di comuni nella pagina principale di OSM. I
risultati mi paiono piuttosto fuorvianti, quantomeno per l'uso di alcuni
vocaboli che hanno un'accezione abbastanza precisa in italiano.

Ricerca 1: Castelmola
1' risultato è "Frazione Castelmola, Messina, Sicily, Italia"
Ma Castelmola non è una frazione ma un comune.
Cliccando sul risultato appare la scheda con i tag che riporta
correttamente admin_level = 8

Ricerca 2: Rovato
1' risultato è "Villaggio Rovato, Brescia, Lombardia, Italia"
Rovato però non lo definirei propriamente un villaggio, ha 2
abitanti, superficie di 26 km quadrati.
admin_level sempre 8

Ricerca 3: Gallarate
1' risultato è "Villaggio Gallarate, Varese, Lombardia, 21013, Italia"
Altro villaggio da 53000 abitanti

Risultati simili per Busto Arsizio (8 abitanti), Cesena (96000
abitanti).

C'è sicuramente una logica (sbagliata), quale?

grazie
maxx

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

Re: [OSM-talk-fr] D281 en Loire-Atlantique

[marc marc]

Bonjour,

Pour son baptême du feu, on a aussi oublié de lui dire que parfois
on aime bien les complications :)

je pense qu'il faut faire simple, et documenter les faits
pour essayer d'être le moins subjectif

accès : il y a 2 panneaux B1 ? donc légalement on ne peux plus passer
access=no
foot=yes
note:access=panneaux B1 à chaque extrémité de la route
source:access=survey
et si on veux vraiment documenté cette situation changeante 
survey:date=la date à laquelle quelqu'un les a vu
et si on veux faciliter la stabilité, je met parfois sur le changeset
website=https://wiki.openstreetmap.org/wiki/FR:Road_signs_in_France
Celui qui lit la modif et n'est pas d'accord peux d'un clic voir que 
c'est pourtant ce qui est documenté pour le moment sur le wiki.
Même si le cas du double sens-unique est évidement pas sur le wiki,
on peux cependant comprendre que cela se tag comme un accès interdit.

En passant envoi d'un petit email au responsable panneau
pour lui signaler qu'il a confondu B0 et B1 :)

type de highway :
pour rappel, tertiaire c'est un état en fonction des panneaux
est-ce que les panneaux route départementale 281 ont été supprimé ?
si oui on peux dégrader la classe de la route.
highway=unclassified (j'ai beaucoup de mal à imaginer
qu'on considère une route encombrée comme un chemin)
note:highway=les panneaux D281 ne sont plus là
et changer ref en old_ref.
Mais je n'ai pas l'impression que cela soie le cas.
Si c'est une route départementale temporairement fermée,
mais qui est toujours départementale.
highway=tertiary
note:highway=les panneaux D281 sont toujours là

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

Re: [Talk-it] Vecchia calchera

[Martin Koppenhoefer]

2018-01-24 8:30 GMT+01:00 demon.box :

> Interessante, ci sono nuovi spunti e non posso fare a meno di notare un
> "nuovo" prefisso "old:"... Quando si usa?
>


non si usa ;-)
E' pratticamente inesistente:
https://taginfo.openstreetmap.org/search?q=old%3A
e il significato non è documentato (credo).

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

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Jan Dudík]

 není mezera, je to html zápis mezery, která jinak není vidět :-)
Přijde mi, že tato problematika je zatím příliš futuristická, v době, kdy v
mapě chybí ještě sposuta existujících objektů, my už řešíme drobné grafické
finesy. (což nemusí být nutně špatně)
A druhá věc - jak často nastává případ, že je nutné zalomit dlouhý název,
který obsahuje někde kolem poloviny nedělitelnou mezeru?
Většina názvů jí obsahuje hned na začátku (V°Jámě, U°Dlouhého mostu), byť
se najdou Výjimky (Rokytnice v°Orlických horách, U°Karla°IV.)

JAnD

---
Ing. Jan Dudík
projekce dopravních staveb
tel. 777082195

Dne 24. ledna 2018 8:45 Matěj Cepl  napsal(a):

> On 2018-01-23, 21:06 GMT, Mikoláš Štrajt wrote:
> > Důvod je jednoduchý - nejsou vidět a zároveň nejsou mezera (ve
> > smyslu ASCII/ UTF-8 znak 32). Domnívám se, že nad daty OSM
> > operuje dost věcí, které namejí skutečnou podporu Unicode
> > a spíše zneužívají toho, že UTF-8 je zpětně kompatibilní
> > s ASCII.
>
> Jenom pro upřesnění:  je mezera, alespoň patří do
> kategorie WSpace=Y v Unicode
> (https://en.wikipedia.org/wiki/Whitespace_character).
>
> Matěj
> --
> http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
> GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
>
> Experience is what you get when you don't get what you want.
>-- Dan Stanford
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] D281 en Loire-Atlantique

[Gwenrannad]

Bonjour à tous :) 

Merci à vous pour tous vos retours et c'est pour un moi un sacré baptême de 
discussion :) 
J'ai pris bonne note de toutes vos remarques relatives à vos différentes 
sensibilités et je vous propose maintenant de conclure cet échange, riche en 
temps de lecture ;) 

-> Pour la dénomination : 
Comme le précise Mathieu, il a un consensus sur le alt_name="Route des 
Chicanes" 

-> Pour la représentation de la voie : 
Le tag "highway=unclassified" est effectivement trop contraignant car il fait 
disparaitre le graphisme de la voie et qu'il serait préférable de lui affecter 
un tag de type "highway=path" de manière temporaire jusqu'à l'ouverture 
officielle de la voie avec un "access=no" pour éviter le routage . L'ajout 
d'une note expliquant l’affectation de ces tags temporaires permettra 
d'éclairer ce choix et de préciser que ces tags évolueront en fonction de 
l'actualité de la voie. 
Cette note serait un peu à l'image des alertes wikipedia sur les articles qui 
font l'objet d'une actualité récente ou en cours. 

Encore merci pour le temps que vous m'avez consacré et pour vos éclairages. 
Tout ceci m'a permis de revoir ma manière de contribuer et de gagner encore 
plus de justesse. 

Stéphane alias Gwenrannad 

PS: Je vais vite vous solliciter de nouveau à propos des PDIPR mais ça c’est 
une autre histoire :D 

- Mail original -

De: "Mathieu"  
À: "Discussions sur OSM en français"  
Cc: gwenran...@free.fr 
Envoyé: Mercredi 24 Janvier 2018 05:05:15 
Objet: Re: [OSM-talk-fr] D281 en Loire-Atlantique 

Bonjour à tous, 

(et enchanté, c'est aussi ma première discussion ici !) 

Tout d'abord merci à tous pour ces échanges, et en particulier à 
Stéphane. C'est effectivement agréable de pouvoir discuter de ces 
sujets "sensibles" sans rentrer dans des guerres d'édition. 

C'est moi qui avait mis le nom "name=Route des Chicanes" dans 
https://www.openstreetmap.org/changeset/52404728, pour décrire la 
situation sur le terrain et le nom utilisé médiatiquement. Je n'avais 
pas connaissance à l'époque du nom officiel. Je pense aussi que OSM 
doit pouvoir retrouver cette appellation. 

En tout cas, au vu des précédents messages, en particulier ceux de 
Christian et Jean-Yvon, "alt_name" (ou bien "loc_name") semble faire 
consensus, en particulier dans la proposition "name=Route de la 
Pâquelais, alt_name=Route des Chicanes" qui me semble effectivement 
non polémique (bien que "name=Route des Chicanes, official_name=Route 
de la Pâquelais" pourrait aussi se défendre). 

Je viens donc de mettre ces noms dans 
https://www.openstreetmap.org/changeset/55701254. Je me suis permis au 
passage de changer la "note" pour faire référence à cette discussion 
plutôt de laisser penser que les modifications sont "réservées" à un 
utilisateur particulier. Je n'ai pas touché au statut de la route 
"abandonned" (qui en plus évolue rapidement). 

Mathieu (magiraud) 

2018-01-23 23:02 GMT+01:00 : 
> Antoine, merci pour ces précisions même si Stéphane s'est très bien défendu 
> tout seul et a bien vu le soucis (approche : l'administration décide) alors 
> que ses arguments sont parfaitement rationnels. 
> 
> Ce qu'il pense de l'Ayrault-port, peu m'importe, il y a des manières de 
> taguer qui sont assez neutres et oui entre militant et salarié il peut être 
> utile d'avoir 2 comptes. Ça m'a permis de dire du bien du travail fait par 
> Charles à Charles sans savoir que c'était la même personne ;-). 
> 
> Ceci dit j'attends que l'un comme l'autre trouvent des manières de taguer 
> compatibles avec les autres points de vue. 
> 
> name 
> Route des Chicanes pour moi (et je précise comme vous vous en doutez que je 
> suis content que le gouvernement ait abandonné un projet vieux d'un 
> demi-siècle prévu pour le Concorde) c'est un loc_name, un alt_name, pas un 
> name. 
> 
> Stéphane, fais la requête qui n'est pas politiquement correcte La Bite à 
> Mathon : tu tombes sur le monument aux morts de Brest, appelé ainsi par les 
> Brestois à cause de sa forme et de l'architecte ayant reconstruit la ville. 
> 
> Et oui, lors d'une manif les Brestois se donnent rendez-vous au pied de la 
> bite à Mathon, pas au pied du monument aux morts. Je vais peut-être 
> susciter des vocations pour le nom alternatif d'une sculpture à Vénissieux. 
> 
> C'est un alt_name, ça aurait pu être un loc_name. 
> 
> C'est ce qui met de la souplesse. Regarde l'historique : la toute première 
> fois que le monument a été décrit il comportait déjà ce second nom. 
> 
> Je ne dis pas name car a priori on met des noms officiels (ou affichés sur 
> le terrain), ce qui ne me semble pas être le cas et comme dans le 
> laboratoire de qualification du sous-sol de Bure pour en faire une poubelle 
> nucléaire (ce qui aurait été une description neutre ;-)), mettre en name un 
> nom potentiellement polémique, autant éviter. 
> 
> Route de la ZAD aurait été sans doute plus neutre 

Re: [Talk-cz] Nedělitelné mezery v názvech ulic

[Matěj Cepl]

On 2018-01-23, 21:06 GMT, Mikoláš Štrajt wrote:
> Důvod je jednoduchý - nejsou vidět a zároveň nejsou mezera (ve 
> smyslu ASCII/ UTF-8 znak 32). Domnívám se, že nad daty OSM 
> operuje dost věcí, které namejí skutečnou podporu Unicode 
> a spíše zneužívají toho, že UTF-8 je zpětně kompatibilní 
> s ASCII.

Jenom pro upřesnění:  je mezera, alespoň patří do 
kategorie WSpace=Y v Unicode 
(https://en.wikipedia.org/wiki/Whitespace_character).

Matěj
-- 
http://matej.ceplovi.cz/blog/, Jabber: mceplceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Experience is what you get when you don't get what you want.
   -- Dan Stanford


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