Re: [Talk-es] Etiquetado de municipios pequeños con varios núcleos // Códigos INE

[Javier Sánchez Portero]

Hola

El 19 de marzo de 2018, 23:55, Lanxana .  escribió:

> Buenas!
>
> revisando los municipios de mi comarca me he encontrado con uno del que no
> se veía el núcleo, investigando un poco he visto que está compuesto por dos
> núcleos pero ambos están etiquetados como place=hamlet. [1] [2]
>

Verse, se ven, a partir del nivel de zoom 15.


> Se trata de Palau de Santa Eulàlia, que no aparece en el listado de
> pueblos en la wiki [3]. Pese a ser un municipio pequeño (96 habitantes)
> creo que la entidad principal, o al menos la que reconoce como tal el INE
> debería etiquetarse como place=village, ¿no?
>

Ese listado se refiere a ciudades pequeñas (place=town), tienes que
buscarla en pueblos (place=village). Allí si aparece:
https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a/Normalizaci%C3%B3n/village

Si, según lo que se definió aquí y está puesto en la wiki, a pesar de tener
una población tan baja (que sería place=hamlet), aquí en españa le
asignamos place=village por ser capital de municipio a este tipo de
pueblos. El razonamiento que se dio en su momento es justamente el que tu
has dado, que es la entidad principal del municipio.

Por otro lado, he empezado por el núcleo de Santa Eulàlia, que es el tiene
> el ayuntamiento, pero al ver que en el etiquetado no había código INE, he
> estado investigando cómo conseguirlo (el enlace que hay en otros núcleos no
> funciona). Si a alguien le sirve, he podido descargar el listado de [4]. Al
> consultar el otro núcleo, Palau, ahí sí estaba el código INE. Mi consulta
> es si debería ponerle también el código correspondiente al núcleo de Santa
> Eulàlia.
>

He estado mirando el historial de los nodos y parece que hubo un error al
importar EGRN en 2011. La capital Santa Eulàlia se situó en la posición de
Palau, cono nodo (1324175538). Entonces tenía etiqueta place=village.
Posteriormente, en 2015, alguien se dio cuenta del error, cambió el nombre
de Santa Eulàlia a Palau y añadió el nodo para Santa Eulalia (1460478639).
El fallo es que debería haberse llevado la etiqueta capital=8, la
referencia del INE y corregir también el 'admin_centre' en la relación de
límites del municipio. He hecho las correcciones para que quede bien.


> Estos son los datos del INE:
>
> 1711900PALAU DE SANTA EULÀLIA
>  96 58 38
> 17119000300PALAU DE SANTA EULÀLIA
>  12  7  5
> 17119000301PALAU DE SANTA EULÀLIA
>  12  7  5
> 17119000399*DISEMINADO*
> 0  0  0
> 17119000400SANTA EULÀLIA
> 84 51 33
> 17119000401SANTA EULÀLIA
> 57 35 22
> 17119000499*DISEMINADO*
>27 16 11
>
> entiendo que para el núcleo de Santa Eulàlia el código sería 1711900400,
> dado que el de Palau es el 171190.
>
> No. 171190 es el código de todo el municipio de Palau de Santa Eulàlia
(población total 96 habitantes), no del pueblo Palau. El municipio está
formado por dos entidades singulares:
- Palau de Santa Eulàlia, población 12 habitantes y código 17119000300
- Santa Eulàlia, población 84 habitantes y código 17119000400

12 + 84 = 96

Santa Eulàlia, a su vez, tiene sus 84 habitantes divididos entre el núcleo
del pueblo (57) y 27 dispersos. 57+27 = 84

La población Palau de Santa Eulàlia en OSM está como Palau, no se cual será
más correcto, pero si aparece con el nombre completo tanto en INE como en
IDESCAT quizá habría que ponerselo y poner name_loc=Palau. Eso os lo dejo a
los locales.


>
> Para terminar de rizar el rizo, el IDESCAT [5] identificaba 4 unidades de
> población para el mismo municipio:
> Unitats de població de Catalunya (a 02-02-1989)
> NivellCodiNomCategoria
> Unitat població171194 01 Comuns, els Masos
> Unitat població171194 02 Estanyet Veïnat
> Unitat població171194 03 Palau de Santa Eulàlia Població
> Unitat població171194 04 Santa Eulàlia Llogarret
>
Habría que añadirlas al mapa. Por la población que deben tener seguramente
serán hamlet o isolated_dwelling.



> Me falta averiguar qué equivalencia hay entre el INE y el IDESCAT (el
> código de municipio coincide menos el 4 final que aparece en el IDESCAT) y
> a qué se refiere el IDESCAT con "Població", "Llogarret" o "Veïnat", qué
> criterio sigue (o siguió en 1989) para hacer esa distinción, y si sería
> aplicable a las etiquetas de hamlet, suburb, neighbourhood,
> isolated_dwelling...
>
> Este fin de semana salió el tema del etiquetado de pueblos pequeños con
> entidades diseminadas en el grupo de Telegram, y  creo que sería buena idea
> abrir un hilo propio en la lista para consensuar cómo tratar estos casos.
>
> Saludos!
>

Lo que comenté en Telegram es que en su momento se decidió que en España,
diferenciándonos del resto de OSM, promover poblaciones muy pequeñas de
hamlet a village por ser capital de municipio. Eso está bien en municipios
como el que comentas. Sin embargo, si lo consideramos como un criterio
restrictivo "para ser village tiene que ser capital de municipio", en cada
municipio sólo podrá haber 

Re: [OSM-talk-fr] Les mappeurs tchèques sous pression "policière"

[Philippe Verdy]

Regarde les historiques, je ne vois pas de réelle raison à cette réaction
et cette citation soudaine et inattendue. Je modifie très peu de choses en
fait, juste ce qui ne marche pas bien, des liens essentiellement, ou des
mises en forme problématiques pour les traductions suivantes; de petits
détails qui semblent mineurs mais qui facilient la réutiiisation ensuite.
Là il se base sur un article qui avant était nommé il y a quelques mois
CS+SK, et qui avait été publiquement annoncé comme tel, et qu'ensuite il
avait décidé seul de renommer sans référence à la Slovaquie qui était
pourtant coorganisatrice même si cela se passait en République tchèque. Des
mois après (même si à l'époque cela semblait réglé), il décide juste
d'abandonner et tout effacer pour poster son message incendiaire à la place.
J'ai pu me tromper à l'occasion, mais je l'ai laissé largement libre, et il
a pu revenir ou annuler certaines choses mais je l'ai laissé continuer à
gérer "sa" catégorie fourre-tout pour le tchèque (il voulait suivre
certains articles sur lesquels il est passé, OK, je le lui ai laissé même
si les catégories ne sont pas faites pour des listes de suivi personnelles
et si partout ailleurs, et la décision ne venait pas de moi, la catégorie
fourre-tout pour tous les articles et catégories ou sous-catégories dans
une langue particulière a été abandonnée: cela devenait ingérable).
Je peux me tromper mais il ne sait pas se servir d'un wiki, et heureusement
il y a eu d'autres discussions ailleurs et différentes solutions proposées
ou évaluées ou pas encore en place (connaissant les limites techniques du
wiki que certains ne veulent pas admettre, croyant que le wiki est un
fourre-tout où chacun stocke ce qu'il veut où il veut et ne souhaite pas
que d'autres puissent même trouver ou intervenir).
Dans le cas présent il a continué tout seul, le compromis pour sa solution
à lui seul je l'avais accepté; mais vu qu'il ne sait pas gérer et abandonne
le navire, cette solution de compromis (qui complique les choses et
paralyse les changements techniques qui rendrait le tout plus efficace) me
semble plus vouée aussi à disparaitre.

Alors non je n'interviens pas sur tout, il y a en gros 600 utilisateurs
différents chaque mois qui font des choses très bien sur lesquels il n'y a
rien à redire sur le contenu, mais qu'on peut aider pour que ce qu'ils
voulaient faire puisse fonctionner et que leur contenu soit bien référencé
et facilement trouvé. Des erreurs courantes sont la non compréhension de
certains éléments de syntaxe wiki, HTML, CSS, des pages énormes qui ne sont
même pas rendues correctement et que j'aide à les faire fonctionner (sans
intervenir sur le contenu lui-même).

Alors effectivement je fais plein de choses sur le wiki, qui peuvent
sembler mineures ou trop lourdes à faire pour beaucoup et éviter des
anomalies ultérieures (et il y en a des tas sur le wiki). J'ai largement
amélioré les performances et l'universalité des modèles pour pouvoir
s'adapter aux usages que j'ai trouvés et permettre justement à plus de
monde de travailler et structurer leur travail plus facilement et pouvoir
aussi réviser ultérieurement leurs textes et données postées. J'ai tous les
mois des demandes nombreuses qui me sont adressées pour aider à corriger ou
mettre en place ce qu'ils n'arrivent pas à faire. Et notamment chez les
non-anglophones et dans les pays en développement om les "bras" manquent et
donc aussi des compétences particulières.

Concernant WeeklyOSM ses problèmes propres existent depuis longtemps, ils
ont existé depuis le début avant même que j'intervienne dessus. Une
solution a été mises en place à la suite de son changement
d'adminsitrateur, car une autre méthode de publication du "calendrier" a
été mise en place. Tout a été documenté, mais lui il n'a pas participé. Il
y a encore des problèmes chez WeeklyOSM (qui eux aussi manquent de bras et
de temps mais surtout manquent de traducteurs et de réviseurs et se
contentent encore de quelques outils automatiques même quand ils ne
fonctionnent pas correctement: la lettre WeeklyOSM est postée telle quelle
sans aucune relecture).

J'ai proposé diverses solutions mais je n'ai pas les moyens de modifier la
façon dont WeeklyOSM fonctionne. Pendant longtemps c'était un projet privé
avec une seule personne, puis c'est passé à une autre personne unique après
des mois d'arrêt, maintenant une autre. Je ne peux certainement pas obliger
ces personnes à y consacrer plus de temps et d'attention, si elles ne sont
pas capables de gérer ça avec leurs moyens et si le projet ne s'ouvre pas
un peu plus (sinon des solutions de maintenance auraient pu être
développées mais le code utilisé est totalement fermé, invisible).

Essayez donc de voir comment il fonctionne et vous verrez que même s'ils
demandent des traducteurs, ils n'ont presque aucune capacité à gérer au
delà les problèmes techniques ou évaluer des solutions possibles. WeeklyOSM
reste intéressant, mais on en voit les limites actuelles : il fonctionne 

[Talk-es] Etiquetado de municipios pequeños con varios núcleos // Códigos INE

[Lanxana .]

Buenas!

revisando los municipios de mi comarca me he encontrado con uno del que no
se veía el núcleo, investigando un poco he visto que está compuesto por dos
núcleos pero ambos están etiquetados como place=hamlet. [1] [2]
Se trata de Palau de Santa Eulàlia, que no aparece en el listado de pueblos
en la wiki [3]. Pese a ser un municipio pequeño (96 habitantes) creo que la
entidad principal, o al menos la que reconoce como tal el INE debería
etiquetarse como place=village, ¿no?

Por otro lado, he empezado por el núcleo de Santa Eulàlia, que es el tiene
el ayuntamiento, pero al ver que en el etiquetado no había código INE, he
estado investigando cómo conseguirlo (el enlace que hay en otros núcleos no
funciona). Si a alguien le sirve, he podido descargar el listado de [4]. Al
consultar el otro núcleo, Palau, ahí sí estaba el código INE. Mi consulta
es si debería ponerle también el código correspondiente al núcleo de Santa
Eulàlia. Estos son los datos del INE:

1711900PALAU DE SANTA EULÀLIA
 96 58 38
17119000300PALAU DE SANTA EULÀLIA
 12  7  5
17119000301PALAU DE SANTA EULÀLIA
 12  7  5
17119000399*DISEMINADO*
0  0  0
17119000400SANTA EULÀLIA
  84 51 33
17119000401SANTA EULÀLIA
  57 35 22
17119000499*DISEMINADO*
   27 16 11

entiendo que para el núcleo de Santa Eulàlia el código sería 1711900400,
dado que el de Palau es el 171190.


Para terminar de rizar el rizo, el IDESCAT [5] identificaba 4 unidades de
población para el mismo municipio:
Unitats de població de Catalunya (a 02-02-1989)
NivellCodiNomCategoria
Unitat població171194 01 Comuns, els Masos
Unitat població171194 02 Estanyet Veïnat
Unitat població171194 03 Palau de Santa Eulàlia Població
Unitat població171194 04 Santa Eulàlia Llogarret Me falta averiguar qué
equivalencia hay entre el INE y el IDESCAT (el código de municipio coincide
menos el 4 final que aparece en el IDESCAT) y a qué se refiere el IDESCAT
con "Població", "Llogarret" o "Veïnat", qué criterio sigue (o siguió en
1989) para hacer esa distinción, y si sería aplicable a las etiquetas de
hamlet, suburb, neighbourhood, isolated_dwelling...

Este fin de semana salió el tema del etiquetado de pueblos pequeños con
entidades diseminadas en el grupo de Telegram, y  creo que sería buena idea
abrir un hilo propio en la lista para consensuar cómo tratar estos casos.

Saludos!


[1] https://www.openstreetmap.org/node/1324175538
[2] https://www.openstreetmap.org/node/1460478639
[3]
https://wiki.openstreetmap.org/wiki/ES:Espa%C3%B1a/Normalizaci%C3%B3n/town
[4]
http://www.ine.es/dyngs/INEbase/es/operacion.htm?c=Estadistica_C=1254736177010=resultados=1254736195532=1254734710990
[5] https://www.idescat.cat/codis/?id=50=9=171194=es


Libre
de virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Les mappeurs tchèques sous pression "policière"

[Christian Rogel]

> Le 19 mars 2018 à 23:38, Philippe Verdy  a écrit :
> 
> J'ai vu ça je laisse l'auteur juge de son opinion, alors qu'il a fait et 
> obtenu pratiquement ce qu'il a voulu. Il a changé le nom d'une ancienne 
> conférence CS+SK (annoncée alors comme telle) en "CS" pour "réécrire 
> l'histoire". Il a défendu sa propre catégorie tchèque spécifique, je la lui 
> ai laissée mais il ne s'est pas occupé du reste. Maintenant il ne sait plus 
> comment gérer le contenu qu'il s'est approprié.
> Je pense que la communauté slovaque prendra ses propres décisions et 
> reviendra sur ses choix.
> Malheureusement dans un cas comme ça il est impossible que tout convienne à 
> tout le monde et qu'il s'enferme dans une logique tchéco-tchèque qui n'est 
> sans doute même pas celle voulue par sa communauté qui souhaite certainement 
> plus d'intégration.
> Normalement je devrais répondre à ce message posté publiquement car je suis 
> cité nommément de façon agresssive, mais je m'attends à plus de problèmes et 
> ça envenimerait (alors qu'en fait il ne m'a pas contacté du tout, il réagit 
> ici même des mois après coup et n'a pas participé non plus aux discussions 
> récentes concernant WeeklyOSM en général pour tenter de le faire fonctionner 
> après plusieurs ratés de publication et surtout un manque de supervision et 
> de contributeurs techniques, et une gestion interne de ce projet annexe à mon 
> avis trop fermée qui ne permet pas de le faire évoluer pour corriger les 
> défauts déjà constatés; la situation est presque figée, malgré le fait que 
> WeeklyOSM a changé d'administrateur, l'ancien ayant décidé d'abandonner par 
> manque de temps et de moyens).
> 
> Le 19 mars 2018 à 22:03, Christian Rogel  > a écrit :
> Les malheureux Tchèques n’auront pas été épargnés : après 40 de dictature 
> policière, leur communauté OSM se dit sous la pression d’une supposée police 
> locale.
> 
> Le dossier est pourtant mince :
> 
> Une brève en première place sur l’hebdoOSM n° 399 
>  du 18 mars concernant le 
> déménagement de la version en langue tchèque de cette newsletter hebdo sur un 
> site différent.
> 
> Et un motif inhabituel donné :
> 
> 
> 
> De quoi méditer sur la porosité des frontières ;-)


Connaissant pourtant ta tendance à modifier des rédactions, j’étais très 
sceptique sur la possibilité que cela mérite une qualification aussi 
outrancière. Effectivement, c’est à eux de régler la question sans intervention 
de ta part.

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

Re: [OSM-ja] JOSMとJava

[Jun Nogata]

野方です。

Java 8が2020年12月までサポートなので、そのまま使っていて大丈夫なようです。
Java 11からOpenJDKのバイナリも提供されるそうなので、移行はそれからでも良いのではないでしょうか。

- Java 10が本日付で正式リリース。ローカル変数の型推論、ガベージコレクタが入れ替え可能、不揮発性メモリ対応など。Java
9は早くもサポート期間終了 － Publickey:
http://www.publickey1.jp/blog/18/java_10java_9.html
- 来月にはJava 10が登場し、9月にはJava
11が登場予定。新しいリリースモデルを採用した今後のJava、入手方法やサポート期間はこう変わる（OpenJDKに関する追記あり） －
Publickey: http://www.publickey1.jp/blog/18/java_109java_11java.html


2018年3月14日 21:26 ribbon :
> On Tue, Mar 13, 2018 at 09:54:15PM +, Kenichiro MATOHARA wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> matohara@鹿児島です．
>>
>> Linux環境ですが以前よりOpenJDKを利用しています．
>> Debian sid amd64/Ubuntu 16.04 LTS ARM64環境では以下のような感じで動いています．
>>
>> - 
>> OpenJDKのインストール(8以降)
>> $ sudo apt install openjdk-8-jre
>
> Linux環境だと、わざわざOracle Java入れることはないので、
> 普通は、open-jdk ですね。
> でも、Windows版はそうもいかない。
>
> JOSM使うときはLinuxにしないと駄目なのかな。
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja



-- 
野方 純 (NOGATA,Jun) - mail: noga...@gmail.com
 - web: http://www.nofuture.tv/diary/
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Les mappeurs tchèques sous pression "policière"

[Philippe Verdy]

J'ai vu ça je laisse l'auteur juge de son opinion, alors qu'il a fait et
obtenu pratiquement ce qu'il a voulu. Il a changé le nom d'une ancienne
conférence CS+SK (annoncée alors comme telle) en "CS" pour "réécrire
l'histoire". Il a défendu sa propre catégorie tchèque spécifique, je la lui
ai laissée mais il ne s'est pas occupé du reste. Maintenant il ne sait plus
comment gérer le contenu qu'il s'est approprié.
Je pense que la communauté slovaque prendra ses propres décisions et
reviendra sur ses choix.
Malheureusement dans un cas comme ça il est impossible que tout convienne à
tout le monde et qu'il s'enferme dans une logique tchéco-tchèque qui n'est
sans doute même pas celle voulue par sa communauté qui souhaite
certainement plus d'intégration.
Normalement je devrais répondre à ce message posté publiquement car je suis
cité nommément de façon agresssive, mais je m'attends à plus de problèmes
et ça envenimerait (alors qu'en fait il ne m'a pas contacté du tout, il
réagit ici même des mois après coup et n'a pas participé non plus aux
discussions récentes concernant WeeklyOSM en général pour tenter de le
faire fonctionner après plusieurs ratés de publication et surtout un manque
de supervision et de contributeurs techniques, et une gestion interne de ce
projet annexe à mon avis trop fermée qui ne permet pas de le faire évoluer
pour corriger les défauts déjà constatés; la situation est presque figée,
malgré le fait que WeeklyOSM a changé d'administrateur, l'ancien ayant
décidé d'abandonner par manque de temps et de moyens).

Le 19 mars 2018 à 22:03, Christian Rogel 
a écrit :

> Les malheureux Tchèques n’auront pas été épargnés : après 40 de dictature
> policière, leur communauté OSM se dit sous la pression d’une supposée
> police locale.
>
> Le dossier est pourtant mince :
>
> Une brève en première place sur l’hebdoOSM n° 399
>  du 18 mars concernant le
> déménagement de la version en langue tchèque de cette newsletter hebdo sur
> un site différent.
>
> Et un motif inhabituel donné :
>
>
> De quoi méditer sur la porosité des frontières ;-)
>
>
>
> Christian R.
>
> ___
> 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] Import CORINE Land Cover - Attributs bruts comme tags

[Philippe Verdy]

Note: un outils comme Corine serait maintenant plus intéressant dans des
pays en développement où presque tout est à faire, notamment en Afrique
centrale ou dans les immenses territoires ruraux de Russie, de Chine ou
d'Australie (bien que là il doit exister des sources locales comparables:
Corine en Europe c'est un peu comme TIGER aux USA): ça va bien pendant un
temps et c'est très utile pour avancer et mieux que rien du tout car ça
permet de localiser plein d'objets relativement et dresser un état du
terrain pour ensuite se concentrer sur des zones plus petites et améliorer
la précision; mais ensuite on doit gérer cet historique de façon plus
incrémentale et on ne réimporte pas à nouveau ce type de source.
Au Canada il y a eu certains imports dans l'Est mais c'est visiblement
difficile de continuer, la progression est devenue très lente, malgré la
relativement bonne qualité des données topographiques.

Le 19 mars 2018 à 20:22, Magalie Dartus  a écrit :

> Merci pour cet historique complet et très intéressant de CLC dans OSM.
>
>
> Le 19 mars 2018 à 19:25, Philippe Verdy  a écrit :
>
>> Le cadastre n'a rien preque qui correspond à nos landuses (hormis les
>> surfaces d'eau de précision appromimative mais un peu plus précise que
>> Corine, le bati, les limites de parcelles, la tononymie et des adresses).
>> Nos landuses sont basés beaucoup plus sur l'imagerie aérienne de
>> meilleure précision que celle utilisée par Corine. Corine est davantage un
>> élément de comparaison pour identifier le type de végétation et de sol si
>> on ne voit pas bien. ou pour détecter de grosses incohérences. Corine a été
>> utilisé pour fournir une couverture minimale du sol partout en France avant
>> même qu'on finisse le tracé des communes et l'essentiel du réseau routier,
>> puis des tas de petits chemins et le détail des rues et adresses.
>> Depuis on a pas repris les imports car partout on a largement amélioré
>> les choses, en tenant justement compte des routes, du bati, des tracés plus
>> précis des cours d'eau. Les surfaces forestières et agricoles de Corine
>> sont vraiment trop floues, même chose pour les surfaces des agglomérations
>> (résidentielles, commerciales, industrielles, ferroviaires) et
>> l'aménagement public des parcs et jardins.
>>
>> Il y a encore de nombreux éléments de Corine dans la base quand le plus
>> gros de leur surface n'a pas eu besoin d'être redécoupé, ou seulement
>> affiné localement sur les bords. Mais on ne se gêne plus pour les découper,
>> et aussi réunir des fragments de gros polygones Corine dont le découpage
>> était sur des lignes de coupe arbitraires: quand on fait ce nettoyage, et
>> que les nouveaux polygones ne correspondent plus à rien d'identifiable sur
>> Corine, on vire ces références anciennes: nos objets sont bien plus petits
>> et plus précis, ce qui était un gros polygone contigu est devenu des séries
>> de polygones séparés avec d'autres éléments plus petits intercalaires qui
>> ne correspondent pas du tout à la classification Corine: on n'a plus rien
>> de commun, ni les tags de classification, ni la géométrie, donc pas besoin
>> de garder les anciens identifiants d'imports.
>>
>> D'ailleurs d'une édition à l'autre de Corine il n'y a aucune stabilité
>> des identifiants, et parfois des changements dans les codes de
>> classification (et pas liés non plus à des évolutions du terrain physique),
>> donc on a pas moyen de revenir dessus: ces identifiants Corine dans OSM
>> sont des outils temporaires destinés juste à vérifier la qualité des
>> imports réalisés, on n'a aucun système de retour qualité d'OSM vers Corine,
>> et pas moyen de comparer réellement par des moyens automatiques de veille
>> qualité. La source Corine devient donc de moins en moins pertinente.
>>
>> Attention cependant à ne pas les supprimer en masse : cette suppression
>> se fait de façon graduelle au fil des améliorations et travaux de
>> nettoyage. La suppression en masse serait un abus des droits d'auteur de
>> Corine (même si globalement, OSM indique que Corine a été utilisé comme une
>> source sans indiquer précisément où, on indique juste la trace des années
>> de références utilisées, et ça peut servir à détecter des zones qui
>> auraient besoin d'être révisées quand de nouvelles sources deviennent
>> disponibles et commencent à être utilisées).
>>
>> Aujourd'hui nos landuses en France sont passés à des précisions
>> inférieures au mètre parfois même décimétrique pour améliorer le tracé des
>> courbes alors que Corine était dessiné avec une précision décamétrique
>> voire hectométrique par endroit, en omettant moultes détails (surtout dans
>> les zones forestières et de montagne, mais même concernant les périphéries
>> urbaines qui demandent partout  à être revues car Corine fait des
>> découpes trop arbitraires au travers des zones résidentielles et
>> industrielles). Corine n'est également pas assez précis le long des côtes
>> et surfaces lacustres.

Re: [OSM-talk] Unify Mapping and wiki accounts? -- WAS: Vote cheating?

[Richard]

On Mon, Mar 19, 2018 at 01:51:54AM -0300, Nicolás Alvarez wrote:
> El 18 mar. 2018, a la(s) 20:50, François Lacombe  
> escribió:
> 
> > 
> > 2018-03-19 0:38 GMT+01:00 Michael Kugelmann :
> >>> Am 18.03.2018 um 20:45 schrieb Richard:
> >>> fundamental decission - maybe osm and osm-wiki accounts should be the 
> >>> same?
> >> This had been independent in the very old history. And now you have 
> >> conflicts => will not work w/o huge effort...
> >> There had been requests like this 5 years ago or so w/o success. Not 
> >> because nobody wanted to implement but because it was not possible.
> > 
> > This is a great idea.
> > 
> > Can you sum up what are the technical issues which make it not possible 
> > please ?
> 
> Suppose user 'John' currently has a wiki account called 'JohnW'. That's 
> currently possible, since the accounts are independent. What do you do if you 
> unify the accounts? Does OSM user John get a new wiki account called John? 
> What if that wiki account already exists? Or does he have to manually connect 
> the OSM and Wiki accounts?
> 
> What if an OSM user called JohnW also exists (but never used the wiki yet), 
> what wiki account do you create for him if the name JohnW is already taken on 
> the wiki?

just keep the different names for each project - and link them if user agrees 
or rather asks 
for it (eg for example ask on next login).
There are also users who have 2 or more OSM editing accounts for legitimate 
reasons and other
corner cases but start with the simple stuff first: That is a new user creates 
an account
in either place so he should also get an account created in the other place 
with the same
name. He could later still choose to create many other accounts under other 
names and
I guess we don't have any policy prohibiting this but most people won't do it 
without
good reason.

> Users can rename OSM accounts. What happens if a user has accounts on both 
> OSM and the wiki, with the same name, but changes his user name to 
> "Javiersanp"? That name isn't taken in OSM, but it's taken in the wiki. Does 
> the rename get rejected?

should be rejected indeed. Even if it is allowed to have different names in the 
wiki and OSM
creating fresh confusion like that happens 99% by accident so the user would be 
helped if
it is rejected and 1% malice so it should be forbidden.

> There are different OSM users "nicolas" and "Nicolas". Wiki usernames always 
> have a uppercase first letter, so if accounts get unified, those two 
> different OSM users can't get different wiki accounts. There is a similar 
> problem with the wiki considering " " (space) and "_" (underscore) 
> equivalent, while OSM doesn't.

keep the old accounts and enforce consistent rules on new ones.

Richard

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

Re: [Talk-it] tagging per un ostacolo sull'attraversamento ciclopedonale

[Volker Schmidt]

>
>
>  maxwidth non è questo tag che descrive la larghezza della luce, invece
> indica un divieto legale.
>

Allora quale è il tag giusto per i casi dove c'è de fatto una limitazione
dalla larghezza nel senso di un ostacolo fisico, ma no c'è cartello. Il
termine inglese mi sembra è "clear width" e non trovo niente.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-au] Collaborative Australian Protected Areas Database (CAPAD) 2016

[Andrew Harvey]

I recently approached the CAPAD owners and they completed the OSMF CC BY
waiver https://wiki.openstreetmap.org/wiki/File:CAPAD_CCBY_waiver.pdf so
we're in a better position re licensing now.

They requested some minor changes to the attribution statement to include
the contributing agencies which I've already changed at
https://wiki.openstreetmap.org/wiki/Contributors#Department_of_the_Environment_and_Energy

Is anyone currently working on comparing the CAPAD 2016 data with what's in
OSM?

On 30 August 2017 at 09:55, Andrew Harvey  wrote:

> Just wanted to add, that we should get the rights holder to complete the
> OSMF CC BY waiver
> https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/ (regardless
> of if it's CC BY 3 or CC BY 4) before using this data.
>
> Also noting from the blog "Please do not forget that imports need to
> follow our Import Guidelines",
> http://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> On Tue, 29 Aug 2017, at 11:51 AM, nwastra wrote:
> >
> > Thanks Andrew
> > I remember reading about the rights holder not having time to review
> > their CC-BY xx wording for a while yet, so CC-BY 3.0 is ok.
> > This is a large import so I we expect it to take some time to get right
> > and it is preferable to wait for that instead of mappers adding the data
> > in a piecemeal fashion prior.
> > Keep up the good work.
> >
> > > On 29 Aug 2017, at 10:48 AM, Andrew Davidson 
> wrote:
> > >
> > > The data came out over a month ago but I hadn't bothered to do any
> processing on it because I had been led to believe that the data was going
> to be released under CC-BY 4.0 and the OSM view seems to be that we need to
> get the rights holder to sign a wavier (https://www.mail-archive.com/
> talk-au@openstreetmap.org/msg10796.html) even if they had already said
> yes.
> > >
> > > However, I've just checked and the dataset is actually CC-BY 3.0 so we
> may still be OK to go.
> > >
> > > It'll take a while for me to recreate the processing I did on
> CAPAD2014 and I'm not sure when I'll have time to do it.
> > >
> > > On 29/8/17 10:16, nwastra wrote:
> > >> Further to my previous query…
> > >> I have viewed the thread leading to these…
> > >> https://lists.openstreetmap.org/pipermail/talk-au/2017-
> February/011272.html
> > >> https://lists.openstreetmap.org/pipermail/talk-au/2017-
> March/011302.html
> > >> and assume that the permission part is ok and the import is still on
> track.
> > >> Is there an update on the timeframe of the import?
> > >>> Hi
> > >>> I had been expecting that valid explicit permission to use
> Collaborative Australian Protected Areas Database (CAPAD) 2016 to edit and
> add information to the OpenStreetMap would have been obtained by now but I
> assume that the legal licence compatibility issues need to be resolved.
> > >>> Is there an estimated timeframe to resolution?
> > >>>
> > >>> regards
> > >>> Nev Wedding
> > >> ___
> > >> Talk-au mailing list
> > >> Talk-au@openstreetmap.org
> > >> https://lists.openstreetmap.org/listinfo/talk-au
> >
> >
> >
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-it] tagging per un ostacolo sull'attraversamento ciclopedonale

[liste DOT girarsi AT posteo DOT eu]

Il 19/03/2018 19:49, Martin Koppenhoefer ha scritto:

Scusa, mi sono riguardato la foto, parliamo sempre di questo:
https://www.mapillary.com/app/?focus=photo=TwMG9gZUK_BnBiXT9kNgbQ=45.4284670998=11.95386070064=17=0.4920888476137404=0.505704875474801=0

Non ci sono proprio limitazioni fisici, forse ci sono legali (si può
intuire che qualcuno non vuole che si superasse in macchina quella
"barriera", ma è fatto in maniera di consentire comunque il passaggio (per
esempio un'ambulanza ci potrebbe fare tranquillamente inversione).
Sicuramente non vedo alcun motivo per mettere maxwidth=1 (tra altro,
probabilmente con un passeggino da gemelli, largo 1,20 m ci passaresti
comunque).

Ciao,
Martin


Guardando le altre foto, questa si vede meglio.

https://www.mapillary.com/app/?focus=photo=WMR9PsdcGkWdWdkGzycBIg=45.42874299005021=11.953993118492463=17

Senza entrare sui ragionamenti dell'amministrazione comunale a riguardo 
il restringimento in quel punto, mi pare maggiore di 1,5 Mt a occhio, 
comunque un maxwidth per me ci stà, ma solo in quel punto.



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

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

Re: [Talk-cz] Newsletter 2018

[Pavel Zbytovský]

Ahoj,

dával jsem dnes do šablony ty textíky z draftovacího dokumentu a narazil
jsem na pár problémů:

1) není tam vlastně moc užitečných informací pro outsidery :-)
2) většina linků z newsletteru bude potřeba vylepšit po stránce UX:
  - přidání vlastního bodu na mapu v podstatě nejde najít :-)
  - "bohatý přepínač vrstev" neukazuje defaultně rozbalený info textík
  - stránka turistiky by měla mít i nějaké tipy "jak turistické vrstvy
zobrazit"
3) textíky je potřeba zkrátit na cca 160 znaků, aby se do šablony vešly.

No, zkrátka zatím neposíláme. Pokusím se to výhledově vyladit a pak sem dám
vědět.
Dík Honzovi Macurovi za přípomínky v textu.

Pavel


On Fri, Mar 16, 2018 at 9:00 PM Jan Macura  wrote:

> Od: Pavel Zbytovský 
>>>
>> O víkendu budu offline, poslal bych to v pondělí ráno. Těším se na vaše
>>> podněty. :)
>>>
>>
> Ahoj,
>
> ehm.. ten Google dokument má být něco jako Release Candidate? Tohle má jít
> mezi lidi? Vypadá to spíš jako First Draft...
>
> H.
>
> ___
> 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

[OSM-talk-fr] Les mappeurs tchèques sous pression "policière"

[Christian Rogel]

Les malheureux Tchèques n’auront pas été épargnés : après 40 de dictature 
policière, leur communauté OSM se dit sous la pression d’une supposée police 
locale.

Le dossier est pourtant mince :

Une brève en première place sur l’hebdoOSM n° 399 
 du 18 mars concernant le 
déménagement de la version en langue tchèque de cette newsletter hebdo sur un 
site différent.

Et un motif inhabituel donné :



De quoi méditer sur la porosité des frontières ;-)



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

Re: [Talk-it] tagging per un ostacolo sull'attraversamento ciclopedonale

[Martin Koppenhoefer]

sent from a phone

> On 19. Mar 2018, at 21:25, Volker Schmidt  wrote:
> 
> Ho sbagliato io, in questo caso. Guardando la stessa posizione su Streetview
> https://goo.gl/maps/coLQgxE2dHy
>  si vede che ci sono due archetti quasi una chicane (con maxwidth=1.5). 



si, ma sono gli unici ostacoli in quel punto, potresti passare a sinistra o 
destra senza problemi (per esempio con una carriola con carico ingombrante)



> 
> Non vedo un'altro tag per indicare che in certi posti c'è un limite di 
> larghezza dovuto a ostacoli fisici che sono nodi su una way. Io ne vedo a 
> centinaia sulle ciclopedonali fra bollard e cycle_barrier che bloccano il 
> passaggio a veicoli più larghi di x cm.


 maxwidth non è questo tag che descrive la larghezza della luce, invece indica 
un divieto legale.

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

Re: [Talk-it] Rendering "cliff"

[aldoct]

Scusa Enrico, ma il problema l'ho riscontrato proprio con Base Camp,
installando il file "mtbitaly.exe" dal sito
"https://ftp.gwdg.de/pub/misc/openstreetmap/openmtbmap/odbl/;. La
visualizzazione dal WEB è normale. Non ho fatto caso a come si comporta il
mio GPSMAP64.
Saluti, Aldo




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

[OSM-talk-be] Fwd: [OSM-talk] OSCAL 2018/Call for proposals

[Jonathan Beliën]

Hello everyone,

Some of you probably know it, I'm (also) a member of a hackerspace in 
Tirana, Albania.
Here is some information about our annual international Open Source Free 
Software Conference !


Wish you a pleasant evening !

Jonathan



 Message transféré 
Sujet : [OSM-talk] OSCAL 2018/Call for proposals
Date :  Mon, 19 Mar 2018 21:36:37 +0100
De :Anisa Kuci 
Pour :  t...@openstreetmap.org



Hello,


OSCAL  is the annual international Open 
Source Free Software Conference in Albania dedicated to empowering 
Software Freedom, Open Knowledge, Free Culture and Decentralization.


We would like to invite anyone who is interested to submit proposals.

CALL FOR PROPOSALS : 
deadline is extended to 1 April and we would love to have as much OSM 
presence as possible.


Let us know if you have any questions.


Happy mapping,
Anisa




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

[OSM-talk] OSCAL 2018/Call for proposals

[Anisa Kuci]

Hello,


OSCAL  is the annual international Open Source
Free Software Conference in Albania dedicated to empowering Software
Freedom, Open Knowledge, Free Culture and Decentralization.
We would like to invite anyone who is interested to submit proposals.

CALL FOR PROPOSALS :
deadline is extended to 1 April and we would love to have as much OSM
presence as possible.

Let us know if you have any questions.


Happy mapping,
Anisa




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

Re: [Talk-it] tagging per un ostacolo sull'attraversamento ciclopedonale

[Volker Schmidt]

Ho sbagliato io, in questo caso. Guardando la stessa posizione su Streetview
https://goo.gl/maps/coLQgxE2dHy
 si vede che ci sono due archetti quasi una chicane (con maxwidth=1.5).

Non vedo un'altro tag per indicare che in certi posti c'è un limite di
larghezza dovuto a ostacoli fisici che sono nodi su una way. Io ne vedo a
centinaia sulle ciclopedonali fra bollard e cycle_barrier che bloccano il
passaggio a veicoli più larghi di x cm. Un (futuro) router per bici
potrebbe tenerne conto.

Ecco un caso per mappatori avanzati:

https://www.mapillary.com/map/im/ipIAx2sWbQfXBVt4puEhXw

Questo lo posso tipicamente due volta al giorno in bici!




On 19 Mar 2018 7:50 p.m., "Martin Koppenhoefer" 
wrote:

> Scusa, mi sono riguardato la foto, parliamo sempre di questo:
> https://www.mapillary.com/app/?focus=photo=TwMG9gZUK_Bn
> BiXT9kNgbQ=45.4284670998=11.95386070064=17
> =0.4920888476137404=0.505704875474801=0
>
> Non ci sono proprio limitazioni fisici, forse ci sono legali (si può
> intuire che qualcuno non vuole che si superasse in macchina quella
> "barriera", ma è fatto in maniera di consentire comunque il passaggio (per
> esempio un'ambulanza ci potrebbe fare tranquillamente inversione).
> Sicuramente non vedo alcun motivo per mettere maxwidth=1 (tra altro,
> probabilmente con un passeggino da gemelli, largo 1,20 m ci passaresti
> comunque).
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] uso di addr:unit per le lettere dei civici

[Martin Koppenhoefer]

2018-03-19 20:50 GMT+01:00 Alessandro :

> intendevo che potrebbe trattarsi di un utente non italiano, non era in
> alcun modo riferita a te. ;-)




credo che sia un mappatore locale in questo caso. Lo scriverei, potresti
indirizzarlo qui o nel wiki, penso che abbia agito in buona fede. Comunque,
quando si _modifica_ (e non fai la prima versione) è auspicabile si
verificasse bene il significato dei tag prima di fare un upload ;-)

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

Re: [Talk-it] uso di addr:unit per le lettere dei civici

[Alessandro]

Il 19/03/2018 19:02, Fra Mauro ha scritto:

Grazie.
Sembrava sbagliato anche a me ma ho pensato di verificare!



Io con la frase


si capisce subito, se si è italiani o se si conosce un minimo l'Italia,
che la correzione effettuata è errata.


intendevo che potrebbe trattarsi di un utente non italiano, non era in 
alcun modo riferita a te. ;-)


Alessandro

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

Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags

[Magalie Dartus]

Merci pour cet historique complet et très intéressant de CLC dans OSM.


Le 19 mars 2018 à 19:25, Philippe Verdy  a écrit :

> Le cadastre n'a rien preque qui correspond à nos landuses (hormis les
> surfaces d'eau de précision appromimative mais un peu plus précise que
> Corine, le bati, les limites de parcelles, la tononymie et des adresses).
> Nos landuses sont basés beaucoup plus sur l'imagerie aérienne de meilleure
> précision que celle utilisée par Corine. Corine est davantage un élément de
> comparaison pour identifier le type de végétation et de sol si on ne voit
> pas bien. ou pour détecter de grosses incohérences. Corine a été utilisé
> pour fournir une couverture minimale du sol partout en France avant même
> qu'on finisse le tracé des communes et l'essentiel du réseau routier, puis
> des tas de petits chemins et le détail des rues et adresses.
> Depuis on a pas repris les imports car partout on a largement amélioré les
> choses, en tenant justement compte des routes, du bati, des tracés plus
> précis des cours d'eau. Les surfaces forestières et agricoles de Corine
> sont vraiment trop floues, même chose pour les surfaces des agglomérations
> (résidentielles, commerciales, industrielles, ferroviaires) et
> l'aménagement public des parcs et jardins.
>
> Il y a encore de nombreux éléments de Corine dans la base quand le plus
> gros de leur surface n'a pas eu besoin d'être redécoupé, ou seulement
> affiné localement sur les bords. Mais on ne se gêne plus pour les découper,
> et aussi réunir des fragments de gros polygones Corine dont le découpage
> était sur des lignes de coupe arbitraires: quand on fait ce nettoyage, et
> que les nouveaux polygones ne correspondent plus à rien d'identifiable sur
> Corine, on vire ces références anciennes: nos objets sont bien plus petits
> et plus précis, ce qui était un gros polygone contigu est devenu des séries
> de polygones séparés avec d'autres éléments plus petits intercalaires qui
> ne correspondent pas du tout à la classification Corine: on n'a plus rien
> de commun, ni les tags de classification, ni la géométrie, donc pas besoin
> de garder les anciens identifiants d'imports.
>
> D'ailleurs d'une édition à l'autre de Corine il n'y a aucune stabilité des
> identifiants, et parfois des changements dans les codes de classification
> (et pas liés non plus à des évolutions du terrain physique), donc on a pas
> moyen de revenir dessus: ces identifiants Corine dans OSM sont des outils
> temporaires destinés juste à vérifier la qualité des imports réalisés, on
> n'a aucun système de retour qualité d'OSM vers Corine, et pas moyen de
> comparer réellement par des moyens automatiques de veille qualité. La
> source Corine devient donc de moins en moins pertinente.
>
> Attention cependant à ne pas les supprimer en masse : cette suppression se
> fait de façon graduelle au fil des améliorations et travaux de nettoyage.
> La suppression en masse serait un abus des droits d'auteur de Corine (même
> si globalement, OSM indique que Corine a été utilisé comme une source sans
> indiquer précisément où, on indique juste la trace des années de références
> utilisées, et ça peut servir à détecter des zones qui auraient besoin
> d'être révisées quand de nouvelles sources deviennent disponibles et
> commencent à être utilisées).
>
> Aujourd'hui nos landuses en France sont passés à des précisions
> inférieures au mètre parfois même décimétrique pour améliorer le tracé des
> courbes alors que Corine était dessiné avec une précision décamétrique
> voire hectométrique par endroit, en omettant moultes détails (surtout dans
> les zones forestières et de montagne, mais même concernant les périphéries
> urbaines qui demandent partout  à être revues car Corine fait des
> découpes trop arbitraires au travers des zones résidentielles et
> industrielles). Corine n'est également pas assez précis le long des côtes
> et surfaces lacustres.
>
>
> Le 19 mars 2018 à 18:59, Magalie Dartus  a écrit :
>
>> Ok.
>>
>> Est-ce que les unités plus précises correspondent au cadastre? Ou bien
>> est-ce que c'est des polygones autres?
>>
>> Le 19 mars 2018 à 18:54, Philippe Verdy  a écrit :
>>
>>> Il me semblait que le tag utilisé dans OSM c'était plutôt CLC:year=2006,
>>> et sinon CLC:id=*
>>> Et pas la peine de garder les anciennes versions de CLC si un nouvel
>>> import a eu lieu, d'autant plus qu'on n'en fait plus parce que la précision
>>> de CLC est largement inférieure à ce qu'on a maintenant dans OSM et qu'on
>>> met maintenant plutôt nos propres landuse=* entièremetn redéfinis sans
>>> référence à CLC qui n'est qu'une estimation statistique moyenne ne
>>> répondant plus à nos besoins. Dans tous les endroits où on a redéfini les
>>> données plus précises, on ne fait plus référence à CLC du tout et on vire
>>> les anciens polygones s'ils sont trop grossiers et qu'on doit les
>>> redécouper en plus petites unités plus précises.
>>>
>>> Le 19 

Re: [Talk-dk] De sidste 30 km af NCN 3 (Hærvejsruten, cykel) mangler?

[Michael Andersen]

On mandag den 19. marts 2018 17.20.36 CET Mikkel Kirkgaard Nielsen wrote:
> On 2018-03-19 12:00, Andreas Hammershøj wrote:
> > https://www.openstreetmap.org/relation/61491#map=11/57.4053/10.4142
> > =C Osm.org vil ikke lade mig loade historikken, da den er for lang. > Er
> > der nogen som kan: -  hjælpe mig med at finde ud af hvad der er sket?
> 
> Historikken kan hentes udenom web-interfacet via API'et
> (http://api.openstreetmap.org/api/0.6/relation/61491/history), men så
> får man dog bare de rå data.
> Med lidt Python, eller andet xml-fortolkende grej, kan man analysere på
> indholdet. Tænker at antallet af relationens members er en god
> indikation hvis der decideret mangler ways. Flikkede et script sammen
> der kan tælle antallet af members, her dette års versioner:
> 
> v: 567 , time: 2018-01-07T16:14:32Z , user: osmviborg , members: 834
> v: 568 , time: 2018-01-20T11:07:04Z , user: Lytter1 , members: 834
> v: 569 , time: 2018-01-24T12:32:03Z , user: Hjart , members: 834
> v: 570 , time: 2018-01-27T09:56:04Z , user: osmviborg , members: 836
> v: 571 , time: 2018-02-24T15:47:36Z , user: Hjart , members: 834
> v: 572 , time: 2018-02-27T13:39:16Z , user: Hjart , members: 834
> v: 573 , time: 2018-02-28T17:25:15Z , user: Hjart , members: 820
> v: 574 , time: 2018-02-28T19:59:22Z , user: Hjart , members: 815
> v: 575 , time: 2018-03-05T20:16:41Z , user: Hjart , members: 815
> v: 576 , time: 2018-03-07T23:02:50Z , user: Hjart , members: 814
> v: 577 , time: 2018-03-19T14:55:02Z , user: Jørn-osm , members: 852
> 
> Det ser ud som om Hjart har reduceret i antallet for nyligt, primært i
> version 573 (cs;56762401) og 574 (cs:56766795). Måske han melder ind her
> hvad intentionen med ændringerne var?

Jeg har i flere omgange gennemgået de nationale cykelruter og især lappet 
mindre huller. Enkelte steder har det været oplagt at forenkle stisystemer 
lidt. Derfor det lille fald i antal medlemmer af relationen her.
JOSM's relationseditor er langt det mest effektive værktøj til den slags 
arbejde, men der er desværre kun meget få aktive bidragsydere der er 
tilstrækkeligt fortrolige med den til at kunne bruge den effektivt og bl.a. 
derfor har jeg påtaget mig arbejdet.

> 
> Jørn-osm har lige nu her lavet v577
> (https://www.openstreetmap.org/changeset/57320936) hvor han skriver at
> han genskaber ud fra en slettet relation
> (https://www.openstreetmap.org/relation/1871785), den ændring er dog 5
> måneder gammel så den hænger ikke sammen med ovenstående.

Den relation Jørn-osm (som jeg ellers troede ikke fulgte med på listen her) 
henviser til var en dublet af ruten, som jeg havde funderet over længe og til 
sidst valgte at slette. Jeg syntes ellers jeg var omhyggelig med at sikre mig 
at jeg ikke gjorde noget galt, men noget må alligevel have snydt mig der.
Den slettede dublet havde åbenbart de nordligste 30 km med, men var så vidt 
jeg husker yngre og iøvrigt mindre komplet.

Jeg vil iøvrigt sætte stor pris på et værktøj der grafisk kan vise hvordan 
ruterelationer er ændret over tid. Jeg forestiller mig et kort der viser 
relationen og har en skyder så man kan hurtigt kan spole frem og tilbage og se 
hvordan de enkelte versioner har set ud.



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

Re: [Talk-it] tagging per un ostacolo sull'attraversamento ciclopedonale

[Martin Koppenhoefer]

Scusa, mi sono riguardato la foto, parliamo sempre di questo:
https://www.mapillary.com/app/?focus=photo=TwMG9gZUK_BnBiXT9kNgbQ=45.4284670998=11.95386070064=17=0.4920888476137404=0.505704875474801=0

Non ci sono proprio limitazioni fisici, forse ci sono legali (si può
intuire che qualcuno non vuole che si superasse in macchina quella
"barriera", ma è fatto in maniera di consentire comunque il passaggio (per
esempio un'ambulanza ci potrebbe fare tranquillamente inversione).
Sicuramente non vedo alcun motivo per mettere maxwidth=1 (tra altro,
probabilmente con un passeggino da gemelli, largo 1,20 m ci passaresti
comunque).

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

Re: [Talk-it] null

[Andrea Musuruane]

Wikipedia is your friend 

Ciao,

Andrea


Il lun 19 mar 2018, 19:25 Martin Koppenhoefer  ha
scritto:

> storicamente, come mai si è creata questa doppia numerazione?
>
> Ciao,
> Martin
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] tagging per un ostacolo sull'attraversamento ciclopedonale

[Martin Koppenhoefer]

2018-03-19 15:34 GMT+01:00 Volker Schmidt :

>
>
> su un highway farei un nodo bollard e width,
>
>
> Ho messo un nodo
> barrier=bollard
> bicycle=yes
> foot=yes
> maxwidth=1
>
> Preferisco maxwidth per indicare la larghezza massima del  veicolo che può
> passare.
>


certo, non sapevo che c'era una prescrizione, normalmente con gli ostacoli
si affidano alla larghezza fisica senza mettere cartelli sulla larghezza
amessa e quindi non potresti mettere una restrizione legale come maxwidth.

Comunque, potresti anche taggare "width" del highway.

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

Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags

[Philippe Verdy]

Le cadastre n'a rien preque qui correspond à nos landuses (hormis les
surfaces d'eau de précision appromimative mais un peu plus précise que
Corine, le bati, les limites de parcelles, la tononymie et des adresses).
Nos landuses sont basés beaucoup plus sur l'imagerie aérienne de meilleure
précision que celle utilisée par Corine. Corine est davantage un élément de
comparaison pour identifier le type de végétation et de sol si on ne voit
pas bien. ou pour détecter de grosses incohérences. Corine a été utilisé
pour fournir une couverture minimale du sol partout en France avant même
qu'on finisse le tracé des communes et l'essentiel du réseau routier, puis
des tas de petits chemins et le détail des rues et adresses.
Depuis on a pas repris les imports car partout on a largement amélioré les
choses, en tenant justement compte des routes, du bati, des tracés plus
précis des cours d'eau. Les surfaces forestières et agricoles de Corine
sont vraiment trop floues, même chose pour les surfaces des agglomérations
(résidentielles, commerciales, industrielles, ferroviaires) et
l'aménagement public des parcs et jardins.

Il y a encore de nombreux éléments de Corine dans la base quand le plus
gros de leur surface n'a pas eu besoin d'être redécoupé, ou seulement
affiné localement sur les bords. Mais on ne se gêne plus pour les découper,
et aussi réunir des fragments de gros polygones Corine dont le découpage
était sur des lignes de coupe arbitraires: quand on fait ce nettoyage, et
que les nouveaux polygones ne correspondent plus à rien d'identifiable sur
Corine, on vire ces références anciennes: nos objets sont bien plus petits
et plus précis, ce qui était un gros polygone contigu est devenu des séries
de polygones séparés avec d'autres éléments plus petits intercalaires qui
ne correspondent pas du tout à la classification Corine: on n'a plus rien
de commun, ni les tags de classification, ni la géométrie, donc pas besoin
de garder les anciens identifiants d'imports.

D'ailleurs d'une édition à l'autre de Corine il n'y a aucune stabilité des
identifiants, et parfois des changements dans les codes de classification
(et pas liés non plus à des évolutions du terrain physique), donc on a pas
moyen de revenir dessus: ces identifiants Corine dans OSM sont des outils
temporaires destinés juste à vérifier la qualité des imports réalisés, on
n'a aucun système de retour qualité d'OSM vers Corine, et pas moyen de
comparer réellement par des moyens automatiques de veille qualité. La
source Corine devient donc de moins en moins pertinente.

Attention cependant à ne pas les supprimer en masse : cette suppression se
fait de façon graduelle au fil des améliorations et travaux de nettoyage.
La suppression en masse serait un abus des droits d'auteur de Corine (même
si globalement, OSM indique que Corine a été utilisé comme une source sans
indiquer précisément où, on indique juste la trace des années de références
utilisées, et ça peut servir à détecter des zones qui auraient besoin
d'être révisées quand de nouvelles sources deviennent disponibles et
commencent à être utilisées).

Aujourd'hui nos landuses en France sont passés à des précisions inférieures
au mètre parfois même décimétrique pour améliorer le tracé des courbes
alors que Corine était dessiné avec une précision décamétrique voire
hectométrique par endroit, en omettant moultes détails (surtout dans les
zones forestières et de montagne, mais même concernant les périphéries
urbaines qui demandent partout  à être revues car Corine fait des découpes
trop arbitraires au travers des zones résidentielles et industrielles).
Corine n'est également pas assez précis le long des côtes et surfaces
lacustres.


Le 19 mars 2018 à 18:59, Magalie Dartus  a écrit :

> Ok.
>
> Est-ce que les unités plus précises correspondent au cadastre? Ou bien
> est-ce que c'est des polygones autres?
>
> Le 19 mars 2018 à 18:54, Philippe Verdy  a écrit :
>
>> Il me semblait que le tag utilisé dans OSM c'était plutôt CLC:year=2006,
>> et sinon CLC:id=*
>> Et pas la peine de garder les anciennes versions de CLC si un nouvel
>> import a eu lieu, d'autant plus qu'on n'en fait plus parce que la précision
>> de CLC est largement inférieure à ce qu'on a maintenant dans OSM et qu'on
>> met maintenant plutôt nos propres landuse=* entièremetn redéfinis sans
>> référence à CLC qui n'est qu'une estimation statistique moyenne ne
>> répondant plus à nos besoins. Dans tous les endroits où on a redéfini les
>> données plus précises, on ne fait plus référence à CLC du tout et on vire
>> les anciens polygones s'ils sont trop grossiers et qu'on doit les
>> redécouper en plus petites unités plus précises.
>>
>> Le 19 mars 2018 à 18:05, Magalie Dartus  a écrit :
>>
>>> Il me semble que CODE_12 est le champ qui défini l'occupation du sol
>>> (selon la nomenclature de CLC).
>>> En ce qui concerne le _12 cela correspond à l'année d'édition de CLC.
>>> Pour CLC 2006 nous 

Re: [Talk-it] null

[Martin Koppenhoefer]

storicamente, come mai si è creata questa doppia numerazione?

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

Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags

[Magalie Dartus]

Ok.

Est-ce que les unités plus précises correspondent au cadastre? Ou bien
est-ce que c'est des polygones autres?

Le 19 mars 2018 à 18:54, Philippe Verdy  a écrit :

> Il me semblait que le tag utilisé dans OSM c'était plutôt CLC:year=2006,
> et sinon CLC:id=*
> Et pas la peine de garder les anciennes versions de CLC si un nouvel
> import a eu lieu, d'autant plus qu'on n'en fait plus parce que la précision
> de CLC est largement inférieure à ce qu'on a maintenant dans OSM et qu'on
> met maintenant plutôt nos propres landuse=* entièremetn redéfinis sans
> référence à CLC qui n'est qu'une estimation statistique moyenne ne
> répondant plus à nos besoins. Dans tous les endroits où on a redéfini les
> données plus précises, on ne fait plus référence à CLC du tout et on vire
> les anciens polygones s'ils sont trop grossiers et qu'on doit les
> redécouper en plus petites unités plus précises.
>
> Le 19 mars 2018 à 18:05, Magalie Dartus  a écrit :
>
>> Il me semble que CODE_12 est le champ qui défini l'occupation du sol
>> (selon la nomenclature de CLC).
>> En ce qui concerne le _12 cela correspond à l'année d'édition de CLC.
>> Pour CLC 2006 nous avons un champ CODE_06.
>>
>> Du coup c'est CLC 2012 qui est présent dans OSM... le détail est
>> important non?
>>
>> Le 19 mars 2018 à 17:19, Philippe Verdy  a écrit :
>>
>>> A minima, "ne pas perdre l'info" OK à condition de cloisonner les tags
>>> de repli utilisés. Pour CLC, ces tags étaient identifiables par un préfixe
>>> commun "CODE_12" ne signifie rien du tout en tant que tel, rien n'indique
>>> que cela vient de CLC.
>>> Bref la bonne pratique si on veut ne rien perdre (car on droit faire un
>>> travail ultérieur de reclassification/normalisation ou bien les tags
>>> candidats sont encore incertains ou ambigus et à résoudre manuellement, ou
>>> bien les plus appropriés ont été précédemment dépréciés contre d'autres qui
>>> ne conviennent plus du tout) c'est de préfixer chaque tag (la présence
>>> d'autres tags CLC par exemple ne signifie pas que tous les tags viennent de
>>> CLC, de même les tags de source dans le changeset sont difficiles à suivre).
>>> Ceci dit il est bon de se demander si tous les tags d'une sources sont
>>> utiles: hormi l'identifiant unique de la source ou sa propre date de
>>> référence, pas la peine de tout mettre, surtout si la source est facilement
>>> consultable hors d'OSM). Pour que l'import soit utile et approprié il faut
>>> tout de même trouver  des correspondances suffisantes permettant d'utiliser
>>> les objets dans l'écosystème OSM. Si le seul tag qu'on trouve c'est un
>>> "name", l'import n'est pas à faire du tout, il faudra discuter et détailler
>>> un plan d'intégration et des attributs proposés sur une page dédiée à cet
>>> import ou cette source (où on citera les URLs des descriptions source, les
>>> infos relatives aux licences ou accords de publicationn les points de
>>> contact éventuels pour les remontées d'informations, et d'autres
>>> indications comme la fréquence estimée des mises à jour et leur couverture,
>>> ainsi que si la couverture est totale ou fractionnée en plusieurs sous-jeux
>>> de données qu'on peut traiter séparément pour ne pas tout faire en masse
>>> mais régler déjà sur un premier jeu de teste et l'évaluer avant d'importer
>>> le reste).
>>> Evidememnt il faut ouvrir un espace de discussion à ce sujet (et il doit
>>> rester ouvert même après pour permettre de revoir ce qu'on fera des données
>>> si leur mise à jour tarde trop et leur précision n'est plus suffisante).
>>>
>>> Le 16 mars 2018 à 17:31, Adrien André  a écrit :
>>>
 Bonjour,

 on trouve des polygones importés de CORINE Land Cover avec les tags
 AREA_HA, id et CODE_12 [1].
 Osmose les relève en tant qu’erreurs [2].

 Dans le Wiki [3], on lit, à propos de l'import,
 "Ne pas perdre d'informations, même si CLC a des types plus riches que
 OSM"

>>>
>>>
>>> ___
>>> 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] uso di addr:unit per le lettere dei civici

[Fra Mauro]

Grazie.
Sembrava sbagliato anche a me ma ho pensato di verificare!

Il 19 Marzo 2018 16:58:07 CET, Alessandro Palmas 
 ha scritto:
>Il 19/03/2018 16:46, Fra Mauro ha scritto:
>> Scusate, ho notato che un utente sta trasformando i civici da me 
>> inseriti se questi hanno un civico con lettera.
>> 
>> In pratica
>> addr:street Via Milano
>> addr:housenumber 11A
>> 
>> diventa
>> addr:street Via Milano
>> addr:housenumber 11
>> addr:unit A
>> 
>> Esempio: https://www.openstreetmap.org/node/2637171824/history
>> 
>> La cosa mi giunge nuova.
>> Pensate che sia un tagging corretto???
>> 
>
>Ciao,
>andando nella wiki inglese
>https://wiki.openstreetmap.org/wiki/Key:addr#Detailed_subkeys
>si capisce subito, se si è italiani o se si conosce un minimo l'Italia,
>
>che la correzione effettuata è errata.
>
>E' scritto infatti:
>The number, letter, or name of a single unit or flat that exists within
>
>a larger complex. While a big building could have only one entrance, 
>sometimes the way inside divides into different units or staircases, 
>where certain apartments/flats/offices can only be reached through a 
>specific unit. Useful for apartment, suite, or office numbers. 
>Information necessary for postmen, for example.
>
>In Italia non è così, l'esponente che segue il numero è usato anche in 
>abitazioni singole. Mando subito un messaggio all'utente.
>
>Alessandro
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it

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

Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags

[Philippe Verdy]

Il me semblait que le tag utilisé dans OSM c'était plutôt CLC:year=2006, et
sinon CLC:id=*
Et pas la peine de garder les anciennes versions de CLC si un nouvel import
a eu lieu, d'autant plus qu'on n'en fait plus parce que la précision de CLC
est largement inférieure à ce qu'on a maintenant dans OSM et qu'on met
maintenant plutôt nos propres landuse=* entièremetn redéfinis sans
référence à CLC qui n'est qu'une estimation statistique moyenne ne
répondant plus à nos besoins. Dans tous les endroits où on a redéfini les
données plus précises, on ne fait plus référence à CLC du tout et on vire
les anciens polygones s'ils sont trop grossiers et qu'on doit les
redécouper en plus petites unités plus précises.

Le 19 mars 2018 à 18:05, Magalie Dartus  a écrit :

> Il me semble que CODE_12 est le champ qui défini l'occupation du sol
> (selon la nomenclature de CLC).
> En ce qui concerne le _12 cela correspond à l'année d'édition de CLC.
> Pour CLC 2006 nous avons un champ CODE_06.
>
> Du coup c'est CLC 2012 qui est présent dans OSM... le détail est important
> non?
>
> Le 19 mars 2018 à 17:19, Philippe Verdy  a écrit :
>
>> A minima, "ne pas perdre l'info" OK à condition de cloisonner les tags de
>> repli utilisés. Pour CLC, ces tags étaient identifiables par un préfixe
>> commun "CODE_12" ne signifie rien du tout en tant que tel, rien n'indique
>> que cela vient de CLC.
>> Bref la bonne pratique si on veut ne rien perdre (car on droit faire un
>> travail ultérieur de reclassification/normalisation ou bien les tags
>> candidats sont encore incertains ou ambigus et à résoudre manuellement, ou
>> bien les plus appropriés ont été précédemment dépréciés contre d'autres qui
>> ne conviennent plus du tout) c'est de préfixer chaque tag (la présence
>> d'autres tags CLC par exemple ne signifie pas que tous les tags viennent de
>> CLC, de même les tags de source dans le changeset sont difficiles à suivre).
>> Ceci dit il est bon de se demander si tous les tags d'une sources sont
>> utiles: hormi l'identifiant unique de la source ou sa propre date de
>> référence, pas la peine de tout mettre, surtout si la source est facilement
>> consultable hors d'OSM). Pour que l'import soit utile et approprié il faut
>> tout de même trouver  des correspondances suffisantes permettant d'utiliser
>> les objets dans l'écosystème OSM. Si le seul tag qu'on trouve c'est un
>> "name", l'import n'est pas à faire du tout, il faudra discuter et détailler
>> un plan d'intégration et des attributs proposés sur une page dédiée à cet
>> import ou cette source (où on citera les URLs des descriptions source, les
>> infos relatives aux licences ou accords de publicationn les points de
>> contact éventuels pour les remontées d'informations, et d'autres
>> indications comme la fréquence estimée des mises à jour et leur couverture,
>> ainsi que si la couverture est totale ou fractionnée en plusieurs sous-jeux
>> de données qu'on peut traiter séparément pour ne pas tout faire en masse
>> mais régler déjà sur un premier jeu de teste et l'évaluer avant d'importer
>> le reste).
>> Evidememnt il faut ouvrir un espace de discussion à ce sujet (et il doit
>> rester ouvert même après pour permettre de revoir ce qu'on fera des données
>> si leur mise à jour tarde trop et leur précision n'est plus suffisante).
>>
>> Le 16 mars 2018 à 17:31, Adrien André  a écrit :
>>
>>> Bonjour,
>>>
>>> on trouve des polygones importés de CORINE Land Cover avec les tags
>>> AREA_HA, id et CODE_12 [1].
>>> Osmose les relève en tant qu’erreurs [2].
>>>
>>> Dans le Wiki [3], on lit, à propos de l'import,
>>> "Ne pas perdre d'informations, même si CLC a des types plus riches que
>>> OSM"
>>>
>>
>>
>> ___
>> 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] numeri civici "rossi"

[Alessandro Palmas]

Il 19/03/2018 18:04, Martin Koppenhoefer ha scritto:


ho mandato una breve mail a "tagging".

Le mie domande:
- come fanno le persone se devono ricevere posta (cosa usano)?



Parlandoti di Genova ...
per essere sicuro scrivi rosso; se scrivi R il postino più o meno lo
capisce vedendo se è indirizzata a un'azienda o a un privato, ma se
scrivi rosso non hai questa ambiguità.



- esiste lo stesso numero due volte, rosso e nero, a posizioni diversi?



Certamente. Sono proprio due numerazioni diverse.
Ti faccio un esempio:
Via XX Settembre 37 rosso https://www.openstreetmap.org/node/1475157260
Via XX Settembre 37 https://www.openstreetmap.org/node/2376150091
sono a una distanza di 600 m uno dall'altro.

Alessandro


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

Re: [Talk-it] null

[Alessandro Palmas]

Il 19/03/2018 18:04, Martin Koppenhoefer ha scritto:

ho mandato una breve mail a "tagging".

Le mie domande:
- come fanno le persone se devono ricevere posta (cosa usano)?



Parlandoti di Genova ...
per essere sicuro scrivi rosso; se scrivi R il postino più o meno lo 
capisce vedendo se è indirizzata a un'azienda o a un privato, ma se 
scrivi rosso non hai questa ambiguità.




- esiste lo stesso numero due volte, rosso e nero, a posizioni diversi?



Certamente. Sono proprio due numerazioni diverse.
Ti faccio un esempio:
Via XX Settembre 37 rosso https://www.openstreetmap.org/node/1475157260
Via XX Settembre 37 https://www.openstreetmap.org/node/2376150091
sono a una distanza di 600 m uno dall'altro.

Alessandro

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

Re: [OSM-talk-fr] Traduction : les quartiers ne durent qu'un trimestre ; )

[Eric Brosselin - Osm]

/Le 19/03/2018 à 17:43, Julien Lepiller a écrit ://
/

/Le 2018-03-19 17:28, Rpnpif a écrit : //
/

/Dans Id, place=quarter est traduit en place=trimestre au lieu de //
//place=quartier. //
/ /
//Un contre-sens qui peut gêner les débutants... et les autres. //
/ /
//Un exemple dans les réponses de : //
//Cherchez : les guerches vern-d'anjou //
//https://www.openstreetmap.org/ //
/ /
//Comment corriger ça ? //
/

/
//Le site web est traduit via 
https://translatewiki.net/wiki/Translating:OpenStreetMap, iD est 
traduit via https://www.transifex.com/openstreetmap/id-editor/. //

/ /
//voir https://wiki.openstreetmap.org/wiki/Translation //
/ /
//Là le problème est plutôt sur le site, non ? /


Oui c'est bien sur le site openstreetmap.org et non dans iD

*C'est traduit depuis samedi dernier*
Voir >>> 
https://translatewiki.net/w/i.php?title=Osm:Geocoder.search_osm_nominatim.prefix.place.quarter/fr=next=7853791


Il faut être patient jusqu'à l'actualisation du site

Je me suis attelé à ça parce qu'il y avait pas mal de choses bizarres 
et/ou mal traduites.


Dans les résultats de recherche il reste  des tags en anglais car il ne 
sont pas encore inclus dans le fichier source à traduire.

Notamment pas mal de choses concernant les limites, frontières

D'ailleurs si vous voyez d'autres éléments que ceux-ci à traduire faites 
m'en part afin que je puisse demander à ce qu'on ajoute ça dans le 
fichier de traduction.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags

[Magalie Dartus]

Il me semble que CODE_12 est le champ qui défini l'occupation du sol (selon
la nomenclature de CLC).
En ce qui concerne le _12 cela correspond à l'année d'édition de CLC.
Pour CLC 2006 nous avons un champ CODE_06.

Du coup c'est CLC 2012 qui est présent dans OSM... le détail est important
non?

Le 19 mars 2018 à 17:19, Philippe Verdy  a écrit :

> A minima, "ne pas perdre l'info" OK à condition de cloisonner les tags de
> repli utilisés. Pour CLC, ces tags étaient identifiables par un préfixe
> commun "CODE_12" ne signifie rien du tout en tant que tel, rien n'indique
> que cela vient de CLC.
> Bref la bonne pratique si on veut ne rien perdre (car on droit faire un
> travail ultérieur de reclassification/normalisation ou bien les tags
> candidats sont encore incertains ou ambigus et à résoudre manuellement, ou
> bien les plus appropriés ont été précédemment dépréciés contre d'autres qui
> ne conviennent plus du tout) c'est de préfixer chaque tag (la présence
> d'autres tags CLC par exemple ne signifie pas que tous les tags viennent de
> CLC, de même les tags de source dans le changeset sont difficiles à suivre).
> Ceci dit il est bon de se demander si tous les tags d'une sources sont
> utiles: hormi l'identifiant unique de la source ou sa propre date de
> référence, pas la peine de tout mettre, surtout si la source est facilement
> consultable hors d'OSM). Pour que l'import soit utile et approprié il faut
> tout de même trouver  des correspondances suffisantes permettant d'utiliser
> les objets dans l'écosystème OSM. Si le seul tag qu'on trouve c'est un
> "name", l'import n'est pas à faire du tout, il faudra discuter et détailler
> un plan d'intégration et des attributs proposés sur une page dédiée à cet
> import ou cette source (où on citera les URLs des descriptions source, les
> infos relatives aux licences ou accords de publicationn les points de
> contact éventuels pour les remontées d'informations, et d'autres
> indications comme la fréquence estimée des mises à jour et leur couverture,
> ainsi que si la couverture est totale ou fractionnée en plusieurs sous-jeux
> de données qu'on peut traiter séparément pour ne pas tout faire en masse
> mais régler déjà sur un premier jeu de teste et l'évaluer avant d'importer
> le reste).
> Evidememnt il faut ouvrir un espace de discussion à ce sujet (et il doit
> rester ouvert même après pour permettre de revoir ce qu'on fera des données
> si leur mise à jour tarde trop et leur précision n'est plus suffisante).
>
> Le 16 mars 2018 à 17:31, Adrien André  a écrit :
>
>> Bonjour,
>>
>> on trouve des polygones importés de CORINE Land Cover avec les tags
>> AREA_HA, id et CODE_12 [1].
>> Osmose les relève en tant qu’erreurs [2].
>>
>> Dans le Wiki [3], on lit, à propos de l'import,
>> "Ne pas perdre d'informations, même si CLC a des types plus riches que
>> OSM"
>>
>
>
> ___
> 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] numeri civici "rossi"

[Martin Koppenhoefer]

ho mandato una breve mail a "tagging".

Le mie domande:
- come fanno le persone se devono ricevere posta (cosa usano)?
- esiste lo stesso numero due volte, rosso e nero, a posizioni diversi?

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

Re: [Talk-it] numeri civici "rossi"

[Martin Koppenhoefer]

2018-03-19 16:48 GMT+01:00 Alessandro Palmas :

> Ciao lista,
> come scrivevamo poco fa nell'argomento dell'import dei civici della
> Toscana, sarebbe il caso di uniformare la mappatura dei numeri civici
> "rossi" esistenti a Firenze, Genova e Savona.
> Sembrerebbe che la notazione senza ambiguità sia quella di Genova che usa
> specificatamente la parola rosso (es.: 112 rosso). Questo per distinguere
> dai normali esponenti (es.: 112R) o evitare cose strane nel caso si trovi
> un 112R rosso (che a Genova si scrive proprio così).
>
> Vorrei quindi aprire la discussione per giungere a una decisione condivisa
> e fissare la decisione sulla wiki.
>



mi chiedo se non dovrebbe essere in inglese: 112 red
sicuramente nel caso di Genova in italiano ha più utilità, perché un umano
che lo legge lo capisce.

Chiederei anche alla lista internazionale (forse ci sono già altri schemi
in uso).

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

Re: [OSM-talk-fr] Traduction : les quartiers ne durent qu'un trimestre ; )

[Julien Lepiller]

Le 2018-03-19 17:28, Rpnpif a écrit :

Dans Id, place=quarter est traduit en place=trimestre au lieu de
place=quartier.

Un contre-sens qui peut gêner les débutants... et les autres.

Un exemple dans les réponses de :
Cherchez : les guerches vern-d'anjou
https://www.openstreetmap.org/

Comment corriger ça ?


Le site web est traduit via 
https://translatewiki.net/wiki/Translating:OpenStreetMap, iD est traduit 
via https://www.transifex.com/openstreetmap/id-editor/.


voir https://wiki.openstreetmap.org/wiki/Translation

Là le problème est plutôt sur le site, non ?

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

Re: [Talk-it] numeri civici "rossi"

[Lorenzo "Beba" Beltrami]

Ciao a tutti,
premesso che dove vivo io (a Reggio Emilia) non ci sono numeri "colorati"
per cui mi potrebbe sfuggire qualche caso particolare a me verrebbe da dire
che la scelta si può far ricadere su due alternative:

1. La più semplice (stile Genova)
addr:housenumber="numero[esponente] [rosso|nero|blu]"

2. La più rigorosa (stile database)
addr.housenumebr="numero[esponente]" (com'è già ora)
addr:category="[rosso|nero|blu]"

Entrambe permettono di eseguire ricerche specifiche per colore (la 1.
cercando nella stringa, la 2. mette a disposizione un campo specifico).
La prima è più leggibile (e scrivibile) dall'uomo, la seconda dalla
macchina.

Da informatico mi sembra più completa la 2., però comprendo che per il
resto del mondo potrebbe avere molto più senso la 1. ;-)

My 2 cents
Lorenzo

Il giorno 19 marzo 2018 16:48, Alessandro Palmas <
alessandro.pal...@wikimedia.it> ha scritto:

> Ciao lista,
> come scrivevamo poco fa nell'argomento dell'import dei civici della
> Toscana, sarebbe il caso di uniformare la mappatura dei numeri civici
> "rossi" esistenti a Firenze, Genova e Savona.
> Sembrerebbe che la notazione senza ambiguità sia quella di Genova che usa
> specificatamente la parola rosso (es.: 112 rosso). Questo per distinguere
> dai normali esponenti (es.: 112R) o evitare cose strane nel caso si trovi
> un 112R rosso (che a Genova si scrive proprio così).
>
> Vorrei quindi aprire la discussione per giungere a una decisione condivisa
> e fissare la decisione sulla wiki.
>
> Alessandro Ale_Zena_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

[OSM-talk-fr] Traduction : les quartiers ne durent qu'un trimestre ; )

[Rpnpif]

Dans Id, place=quarter est traduit en place=trimestre au lieu de
place=quartier.

Un contre-sens qui peut gêner les débutants... et les autres.

Un exemple dans les réponses de :
Cherchez : les guerches vern-d'anjou
https://www.openstreetmap.org/

Comment corriger ça ?

-- 
Alain Rpnpif

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

Re: [Talk-dk] De sidste 30 km af NCN 3 (Hærvejsruten, cykel) mangler?

[Mikkel Kirkgaard Nielsen]

On 2018-03-19 12:00, Andreas Hammershøj wrote:
> https://www.openstreetmap.org/relation/61491#map=11/57.4053/10.4142=C
> Osm.org vil ikke lade mig loade historikken, da den er for lang. > Er der 
> nogen som kan: -  hjælpe mig med at finde ud af hvad der er
> sket?

Historikken kan hentes udenom web-interfacet via API'et
(http://api.openstreetmap.org/api/0.6/relation/61491/history), men så
får man dog bare de rå data.
Med lidt Python, eller andet xml-fortolkende grej, kan man analysere på
indholdet. Tænker at antallet af relationens members er en god
indikation hvis der decideret mangler ways. Flikkede et script sammen
der kan tælle antallet af members, her dette års versioner:

v: 567 , time: 2018-01-07T16:14:32Z , user: osmviborg , members: 834
v: 568 , time: 2018-01-20T11:07:04Z , user: Lytter1 , members: 834
v: 569 , time: 2018-01-24T12:32:03Z , user: Hjart , members: 834
v: 570 , time: 2018-01-27T09:56:04Z , user: osmviborg , members: 836
v: 571 , time: 2018-02-24T15:47:36Z , user: Hjart , members: 834
v: 572 , time: 2018-02-27T13:39:16Z , user: Hjart , members: 834
v: 573 , time: 2018-02-28T17:25:15Z , user: Hjart , members: 820
v: 574 , time: 2018-02-28T19:59:22Z , user: Hjart , members: 815
v: 575 , time: 2018-03-05T20:16:41Z , user: Hjart , members: 815
v: 576 , time: 2018-03-07T23:02:50Z , user: Hjart , members: 814
v: 577 , time: 2018-03-19T14:55:02Z , user: Jørn-osm , members: 852

Det ser ud som om Hjart har reduceret i antallet for nyligt, primært i
version 573 (cs;56762401) og 574 (cs:56766795). Måske han melder ind her
hvad intentionen med ændringerne var?

Jørn-osm har lige nu her lavet v577
(https://www.openstreetmap.org/changeset/57320936) hvor han skriver at
han genskaber ud fra en slettet relation
(https://www.openstreetmap.org/relation/1871785), den ændring er dog 5
måneder gammel så den hænger ikke sammen med ovenstående.

-- 
Mikkel


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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[Pierre Béland]

J'ai ajouté short_name pour le Québec, mais je pense effectivement que c'est 
inutile à comparer avec Ontario. Dans ce cas, le ON fonctionne sans doute à 
cause de state_code=ON.
Et effectivement, lorsque les relations de territoires sont ajoutées et 
fonctionnelles, les is_in et addr:province sont inutiles et Nominatim fourni 
correctement l'info.  


 
Pierre 
 

Le lundi 19 mars 2018 11 h 18 min 23 s HAE, Matthew Darwin 
 a écrit :  
 
  Searching on "110 Laurier Avenue West, on" in Nominatim already works (it 
finds Ottawa City hall) even though the address has no addr:province tag for 
City Halle.  So I don't think this is a good reason to be adding 
addr:province/addr:province:short_name tags. IMO.  Unless there is another use 
case I am missing.  Similarly your example of searching for "Toronto, ON" works 
fine.
 
 I'm guessing this works because the Ontario admin relation has ISO3166-2 tag 
of CA-ON
 
 
 


  On 2018-03-10 04:51 PM, Pierre Béland wrote:
 
   Non, inutile si relations. Dans relation province d'Ontario - ajouter 
short_name='ON'. 
  De cette façon, Recherche Toronto, ON
  devrait fonctionner. A essayer :)
  
   
 Pierre 
   
  
 Le samedi 10 mars 2018 15:39:53 HNE, john whelan  a 
écrit :  
  
  So you're suggesting adding short_name='ON' to ones that have 
addr:province=Ontario
 
  How would that work?
 
 addr:province=Ontario 
  addr:province:short_name=ON ?
 
  Merci John
   
   
 
   ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Import CORINE Land Cover - Attributs bruts comme tags

[Philippe Verdy]

A minima, "ne pas perdre l'info" OK à condition de cloisonner les tags de
repli utilisés. Pour CLC, ces tags étaient identifiables par un préfixe
commun "CODE_12" ne signifie rien du tout en tant que tel, rien n'indique
que cela vient de CLC.
Bref la bonne pratique si on veut ne rien perdre (car on droit faire un
travail ultérieur de reclassification/normalisation ou bien les tags
candidats sont encore incertains ou ambigus et à résoudre manuellement, ou
bien les plus appropriés ont été précédemment dépréciés contre d'autres qui
ne conviennent plus du tout) c'est de préfixer chaque tag (la présence
d'autres tags CLC par exemple ne signifie pas que tous les tags viennent de
CLC, de même les tags de source dans le changeset sont difficiles à suivre).
Ceci dit il est bon de se demander si tous les tags d'une sources sont
utiles: hormi l'identifiant unique de la source ou sa propre date de
référence, pas la peine de tout mettre, surtout si la source est facilement
consultable hors d'OSM). Pour que l'import soit utile et approprié il faut
tout de même trouver  des correspondances suffisantes permettant d'utiliser
les objets dans l'écosystème OSM. Si le seul tag qu'on trouve c'est un
"name", l'import n'est pas à faire du tout, il faudra discuter et détailler
un plan d'intégration et des attributs proposés sur une page dédiée à cet
import ou cette source (où on citera les URLs des descriptions source, les
infos relatives aux licences ou accords de publicationn les points de
contact éventuels pour les remontées d'informations, et d'autres
indications comme la fréquence estimée des mises à jour et leur couverture,
ainsi que si la couverture est totale ou fractionnée en plusieurs sous-jeux
de données qu'on peut traiter séparément pour ne pas tout faire en masse
mais régler déjà sur un premier jeu de teste et l'évaluer avant d'importer
le reste).
Evidememnt il faut ouvrir un espace de discussion à ce sujet (et il doit
rester ouvert même après pour permettre de revoir ce qu'on fera des données
si leur mise à jour tarde trop et leur précision n'est plus suffisante).

Le 16 mars 2018 à 17:31, Adrien André  a écrit :

> Bonjour,
>
> on trouve des polygones importés de CORINE Land Cover avec les tags
> AREA_HA, id et CODE_12 [1].
> Osmose les relève en tant qu’erreurs [2].
>
> Dans le Wiki [3], on lit, à propos de l'import,
> "Ne pas perdre d'informations, même si CLC a des types plus riches que OSM"
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?

[Rpnpif]

Le 19 mars 2018, marc marc a écrit :

> Le 19. 03. 18 à 10:13, Rpnpif a écrit :
> > Le 17 mars 2018, deuzeffe a écrit :
> >   
> >> Mmmhhh ??? On peut utiliser QGis pour mettre à jour JOSM qui mettra à
> >> jour osm ? C'est plus intéressant que JOSM seul ?  
> > 
> > Oui puisque chez moi JOSM est trop lent et bloque avec autant de
> > données.
> > 
> > Bien sûr, le but est de sélectionner une petite zone (communale au
> > plus).
> > Mais je vais peut-être me rabattre sur la couche rapatriée sur Id.  
> 
> Il ne faut pas télécharger la France entière.
> Josm rame à cause de la quantité démesurée de données.
> 
> A noter que josm permet lui aussi d'afficher BD Carthage comme une 
> couche limité à la zone visible de ton écran au lieu de tous le pays.
> c'est dans menu imagerie, BD Carthage :)
> 
> Mais c'est 2 choses assez différente.
> l'un sont les données pour intégrer un à un les rivières.
> l'autre est de l'affichage pour des retouches ponctuelles

Oui et finalement, je vais me rabattre vers Id et ponctuellement vers
la sous-couche dans JOSM comme tu l'indiques. 

Merci.
-- 
Alain Rpnpif

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

Re: [OSM-talk] Unify Mapping and wiki accounts? -- WAS: Vote cheating?

[Matej Lieskovský]

Maybe we could use OAuth only to link the accounts - wiki user X is (proven
by OAuth) to be OSM contributor Y. Inelegant, but it would make it simpler
to identify the active mappers among the wiki accounts. Obviously an opt-in
system.

On 19 March 2018 at 08:25, Andrew Hain  wrote:

> You could say that every existing edit is by an “old” account and new
> ones going forwards are by main site accounts which occasionally have the
> same name. Perhaps you could link some of the old wiki accounts to the OSM
> user names where they are known to be the same person.
>
>
> --
>
> Andrew
>
>
> --
> *From:* Nicolás Alvarez 
> *Sent:* 19 March 2018 04:51
> *To:* osm-talk
> *Subject:* Re: [OSM-talk] Unify Mapping and wiki accounts? -- WAS: Vote
> cheating?
>
> El 18 mar. 2018, a la(s) 20:50, François Lacombe <
> fl.infosrese...@gmail.com> escribió:
>
>
> 2018-03-19 0:38 GMT+01:00 Michael Kugelmann :
>
> Am 18.03.2018 um 20:45 schrieb Richard:
>
> fundamental decission - maybe osm and osm-wiki accounts should be the same?
>
> This had been independent in the very old history. And now you have
> conflicts => will not work w/o huge effort...
> There had been requests like this 5 years ago or so w/o success. Not
> because nobody wanted to implement but because it was not possible.
>
>
> This is a great idea.
>
> Can you sum up what are the technical issues which make it not possible
> please ?
>
>
> Suppose user 'John' currently has a wiki account called 'JohnW'. That's
> currently possible, since the accounts are independent. What do you do if
> you unify the accounts? Does OSM user John get a new wiki account called
> John? What if that wiki account already exists? Or does he have to manually
> connect the OSM and Wiki accounts?
>
> What if an OSM user called JohnW also exists (but never used the wiki
> yet), what wiki account do you create for him if the name JohnW is already
> taken on the wiki?
>
> Users can rename OSM accounts. What happens if a user has accounts on both
> OSM and the wiki, with the same name, but changes his user name to
> "Javiersanp"? That name isn't taken in OSM, but it's taken in the wiki.
> Does the rename get rejected?
>
> There are different OSM users "nicolas" and "Nicolas". Wiki usernames
> always have a uppercase first letter, so if accounts get unified, those two
> different OSM users can't get different wiki accounts. There is a similar
> problem with the wiki considering " " (space) and "_" (underscore)
> equivalent, while OSM doesn't.
>
>
> I would love it if wiki accounts and OSM accounts were unified, but that
> would need to be done since the start. Now it seems too hard to do it; too
> many conflicts with existing accounts.
>
> --
> Nicolás
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-dk] De sidste 30 km af NCN 3 (Hærvejsruten, cykel) mangler?

[Andreas Hammershøj]

2018-03-19 15:46 GMT+01:00 Jørgen Elgaard Larsen :

> Hov, jeg glemte:
>
>
> Andreas Hammershøj skrev:
>
>> Er der nogen som kan:
>>
>> -  hjælpe mig med at finde ud af hvad der er sket?
>>
>
> Hvis du har et eksempel på et vej-id, der er faldet ud, kan jeg godt kigge
> efter, hvornår, det er sket.
>
> - rulle ændringerne tilbage, så jeg ikke skal tegne det ind én gang til?
>>
>
> Det kommer an på, hvordan og hvornår det er sket, og hvad der er sket
> siden da.
>
> - give et bud på hvordan den slags fejl undgås i fremtiden?
>>
>
> Med OSM's frie struktur er den bedste metode nok at gøre præcis, hvad du
> har gjort: Hold øje med kortet.
>
> Man kunne nok lave et stykke software, som holdt øje med ændringer og
> alarmerede nogen, når der skete tilpas store ændringer.
>
> Der findes allerede noget i den retning, f.x. https://osmcha.mapbox.com/
>
>
>
> - Jørgen
>
>
Hej,
tak for svar.

En flink mapper ved navn Jørn har fundet fejlen og revertet sletningen så
nu er ruten tilbage i sin helhed. Jeg er dog stadig nysgerrig på hvordan
det gik galt.
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-it] import numeri civici Regione Toscana

[Andrea Musuruane]

Ciao,

2018-03-19 16:49 GMT+01:00 Alessandro Palmas :

> Il 19/03/2018 16:37, Andrea Musuruane ha scritto:
>
> ...
> Secondo me è sbagliato adeguarsi all'esistente (e di conseguenza avere 3
> specifiche diverse: una per Genova, una per Savona e l'altra per Firenze).
>
> L'utente finale non può sapere che ci sono 3 regole differenti e che a
> seconda di dove vuole fare una ricerca deve immettere i dati in modo
> diverso.
>
> Secondo me la specifica usata a Genova è quella migliore perché, come fai
> notare tu Alessandro, non ha ambiguità.
>
>
>
> Era uscita dopo una certa discussione diversi anni fa. Io inizialmente
> inserivo "r" per l'esponente e "R" per i rossi, poi dopo la discussione
> abbiamo stabilito così.
> Vogliamo pensare (magari cambiando topic delle mail) di deciderlo e
> scriverlo sulla wiki?
>

Sì, l'avevo letta e riportata sulla wiki (anche perché era l'unica che era
stata discussa):
https://wiki.openstreetmap.org/wiki/IT:Addresses:

Ciao,

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

Re: [Talk-it] uso di addr:unit per le lettere dei civici

[Alessandro Palmas]

Il 19/03/2018 16:46, Fra Mauro ha scritto:
Scusate, ho notato che un utente sta trasformando i civici da me 
inseriti se questi hanno un civico con lettera.


In pratica
addr:street Via Milano
addr:housenumber 11A

diventa
addr:street Via Milano
addr:housenumber 11
addr:unit A

Esempio: https://www.openstreetmap.org/node/2637171824/history

La cosa mi giunge nuova.
Pensate che sia un tagging corretto???



Ciao,
andando nella wiki inglese
https://wiki.openstreetmap.org/wiki/Key:addr#Detailed_subkeys
si capisce subito, se si è italiani o se si conosce un minimo l'Italia, 
che la correzione effettuata è errata.


E' scritto infatti:
The number, letter, or name of a single unit or flat that exists within 
a larger complex. While a big building could have only one entrance, 
sometimes the way inside divides into different units or staircases, 
where certain apartments/flats/offices can only be reached through a 
specific unit. Useful for apartment, suite, or office numbers. 
Information necessary for postmen, for example.


In Italia non è così, l'esponente che segue il numero è usato anche in 
abitazioni singole. Mando subito un messaggio all'utente.


Alessandro

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

Re: [Talk-it] uso di addr:unit per le lettere dei civici

[Andrea Musuruane]

Ciao,

2018-03-19 16:46 GMT+01:00 Fra Mauro :

> Scusate, ho notato che un utente sta trasformando i civici da me inseriti
> se questi hanno un civico con lettera.
>
> In pratica
> addr:street Via Milano
> addr:housenumber 11A
>
> diventa
> addr:street Via Milano
> addr:housenumber 11
> addr:unit A
>
> Esempio: https://www.openstreetmap.org/node/2637171824/history
>
> La cosa mi giunge nuova.
> Pensate che sia un tagging corretto???
>
>
E' sicuramente NON corretto. addr:unit è usato per indicare  "The number,
letter, or name of a single unit or flat that exists within a larger
complex. ". Tradotto nella realtà italiana, dovrebbe identificare l'accesso
interno.

Mentre addr:housenumber indica il numero civico ovvero l'accesso esterno
che dall’area di circolazione (strada, piazza, via, ecc) immette
direttamente o indirettamente alle unità immobiliari (abitazioni, esercizi
commerciali, uffici, garage, ecc.).

Figura esplicativa:
http://slideplayer.it/slide/531265/1/images/7/METODI+E+NORME+-+Accessi+esterni+diretti+e+indiretti.jpg

Tra l'altro non è assolutamente detto che lo stesso numero ed esponenti
differenti siano dati ad accessi che conducono allo stesso complesso.

Ciao,

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

Re: [Talk-it] import numeri civici Regione Toscana

[Alessandro Palmas]

  
  
Il 19/03/2018 16:37, Andrea Musuruane
  ha scritto:


  ...

  

  Secondo me è sbagliato adeguarsi all'esistente (e di
conseguenza avere 3 specifiche diverse: una per Genova,
una per Savona e l'altra per Firenze). 

L'utente finale non può sapere che ci sono 3 regole
differenti e che a seconda di dove vuole fare una
ricerca deve immettere i dati in modo diverso.

Secondo me la specifica usata a Genova è quella migliore
perché, come fai notare tu Alessandro, non ha ambiguità.

  

  

  



Era uscita dopo una certa discussione diversi anni fa. Io
inizialmente inserivo "r" per l'esponente e "R" per i rossi, poi
dopo la discussione abbiamo stabilito così.

Vogliamo pensare (magari cambiando topic delle mail) di deciderlo e
scriverlo sulla wiki?


Alessandro
  


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

[Talk-it] numeri civici "rossi"

[Alessandro Palmas]

  
  
Ciao lista,
come scrivevamo poco fa nell'argomento dell'import dei civici della
Toscana, sarebbe il caso di uniformare la mappatura dei numeri
civici "rossi" esistenti a Firenze, Genova e Savona.
Sembrerebbe che la notazione senza ambiguità sia quella di Genova
che usa specificatamente la parola rosso (es.: 112 rosso). Questo
per distinguere dai normali esponenti (es.: 112R) o evitare cose
strane nel caso si trovi un 112R rosso (che a Genova si scrive
proprio così).

Vorrei quindi aprire la discussione per giungere a una decisione
condivisa e fissare la decisione sulla wiki.

Alessandro Ale_Zena_IT
  


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

Re: [Talk-us] Help fight advertising

[Jordan Brod]

"Firstly, many rules in OSM are not written down"

So while I get that OSM is an evolving and collaborative effort, don't you
think that having unwritten rules leads to less collaboration and less
civil interactions?  We have a code of conduct for behavior, guidelines for
using the data, import guidelines, etc. Would it not be a good thing to
adopt a set of conduct or guidelines for editing?  Put it in one place and
stick it in the walkthrough for using the browser editor.  Get the voting
members to agree to it so that it has authority.  Otherwise it comes off
as, "Hey a bunch of us don't like this and so we are going to delete it."
That can catch innocent contributors up and they might decide not to
contribute again.

Just for clarification, I don't support putting advertising in the
description or spam.  I just find it a little to vague when things aren't
obviously spelled out and we'll defined.  Looking at the key wiki entry it
simply says "advertising" and "spam" without offering a definition of
either terms.  Someone could put description= "A discount/low price
store".  It may be an accurate description of a thrift store, but it could
also be considered advertising.  Low Price is an often used advertising
phrase.  I know that common sense drives a lot of this and that we are all
using the best of intentions and discretion to work on this, I just want to
make sure it's all crystal clear.  For one thing I don't want to make edits
multiple times or have edits deleted for violating unwritten rules.  I know
my personality and I wouldn't try to fix the area and I wouldn't try to map
in that area again. I would let the rollback stand.

Thanks for the great discussion and for pointing out where that prohibition
was.  Hopefully I didn't upset anyone, I just want to help make the map
better.

On Mar 19, 2018 6:28 AM, "Frederik Ramm"  wrote:

> Hi,
>
> On 19.03.2018 01:08, Jordan Brod wrote:
> > I went looking for any information printed in guidelines or code of
> > conduct about advertising in the attributes of a feature and I couldn't
> > find where it is approved/prohibited or even mentioned.  Does anybody
> > know where the rule against this is?
>
> Firstly, many rules in OSM are not written down. Just because there's no
> policy that says "don't do X" doesn't mean that X is welcome in OSM, or
> that someone who got their X deleted has a legitimate basis for a
> complaint.
>
> The current situation with written rules is that
> http://wiki.openstreetmap.org/wiki/Key:description
> says "Never use description=* to add advertising messages.", and
> more generally our "How We Map" rules
> (http://wiki.openstreetmap.org/wiki/How_We_Map) say that what you add
> must be truthful and verifiable, both of which is rarely the case for
> advertising.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk-fr] Cartographie des voies d'eau sous pression

[François Lacombe]

Bonjour à tous,

Pour info, le vote s'est terminé hier sur la proposition que j'ai lancé il
y a quelques mois
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Hydropower_water_supplies

Le tagging a été approuvé à 78%.

TL;DR :  Parmi les 3 types d'écoulement d'eau existant, waterway ne servait
dans OSM que pour l'écoulement libre. On ajoute ici l'écoulement en charge
et il restera les infiltrations qui ne rentrent pas dans les deux premières
catégories (écoulement percolé).


Malgré la complexité apparente de ce qui est proposé, sur le terrain c'est
très simple :
- Ajouter waterway=pressurised sur tous les conduits transportant de l'eau
et pour lesquels la prise d'eau est conçue pour être sous le niveau minimal
de l'eau captée.

Sur les barrages, la centrale ne peut fonctionner qu'au dessus d'un certain
niveau du lac ou de a rivière. C'est très facilement vérifiable et une info
capitale pour la gestion de la ressource.

- Ajouter tunnel=flooded sur tous les conduits qui ne sont pas des
pipelines (construit avec des bouts de tubes), dont les dimensions
permettraient à un homme de circuler mais dont la présence d'eau en
quantité importante empêche l'accès.
Les différences avec tunnel=culvert sont surtout les dimensions et la
longueur (on parle ici de galeries qui font plusieurs km à travers la
montagne)

- Utiliser usage=* pour préciser la destination des ouvrages.

Tout ceci sera détaillé sur le wiki prochainement.

Bonne carto

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

[Talk-it] uso di addr:unit per le lettere dei civici

[Fra Mauro]

Scusate, ho notato che un utente sta trasformando i civici da me inseriti se 
questi hanno un civico con lettera.

In pratica 
addr:street Via Milano
addr:housenumber   11A

diventa
addr:street Via Milano
addr:housenumber   11
addr:unit  A

Esempio: https://www.openstreetmap.org/node/2637171824/history

La cosa mi giunge nuova. 
Pensate che sia un tagging corretto???

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

Re: [Diversity-talk] Who Maps The World

[Rory McCann]

On 19/03/18 16:18, Philip Barnes wrote:
Baby hatch sounds a horrible tag, sounds mechanical uncaring and 
impersonal. I assume it means a maternity ward?


They're literally hatches for babies ( 
https://en.wikipedia.org/wiki/Baby_hatch ). They're in some countries, 
and are attached to maternity hospitals. They are places for new mothers 
to leave their babies.


There are a lot of crisis pregnancies, and sometimes repressive 
societies, and sometimes new mothers make rash decisions[1] and there 
are plenty of newborn babies who are left to die. The theory here is 
that if they are going to abandon the baby, better the baby is left 
somewhere safe(r), than the side of a road, or worse.


--

[1] Until recently Ireland was such a society. 15 year old Ann Lovett 
died giving birth in a grotto, and the last slave labour factory for 
unmarried mothers closed less than a decade before OSM was founded.


___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Talk-it] import numeri civici Regione Toscana

[Andrea Musuruane]

Ciao,

2018-03-19 16:20 GMT+01:00 Alessandro :

> Vorrei far notare che, ad oggi, a differenza di Genova, Savona e Firenze
>> non seguono la seguente regola per i numeri civici:
>> /Nel caso sia presente la specificità "rosso" (a Genova, Savona e
>> Firenze), questa si inserisce in lettere minuscole e con uno spazio di
>> separazione dal numero civico (es: addr:housenumber <
>> https://wiki.openstreetmap.org/wiki/Key:addr:housenumber>=9 rosso <
>> https://wiki.openstreetmap.org/w/index.php?title=Tag:addr:
>> housenumber%3D9_rosso=edit=1>). La specificità "nero" non
>> si deve inserire.
>>
>> /
>> A Firenze oggi viene usata la lettera R maiuscola per indicare i numeri
>> rossi, con uno spazio di separazione dal numero civico.
>>
>> Nel tagging plan andrebbe quindi specificato meglio come viene composto
>> il valore di *addr:housenumber*.
>>
>
> Ho notato la notazione che stanno usando a Firenze. Ovviamente ci si
> adeguerà all'esistente, anche se mi chiedo come gestiscano i civici R non
> rossi: a Genova non è inusuale trovare un 112R dove R non è colore ma
> esponente. Ci sono casi dove si trova ad esempio: 112R, 112 rosso, 122R
> rosso.
> Come si comportano in quei casi?


Secondo me è sbagliato adeguarsi all'esistente (e di conseguenza avere 3
specifiche diverse: una per Genova, una per Savona e l'altra per Firenze).

L'utente finale non può sapere che ci sono 3 regole differenti e che a
seconda di dove vuole fare una ricerca deve immettere i dati in modo
diverso.

Secondo me la specifica usata a Genova è quella migliore perché, come fai
notare tu Alessandro, non ha ambiguità.

Ciao,

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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[r00t]

Ahoj,


> Schránka 2056 má umístnění: Na Vošverku 121, Sedlčánky.
Diky, schranka nalezena a doplnena...

J.


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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[Matthew Darwin]

Pierre,

This is a good idea, and I plan to do it.   My current challenge is to 
know what things people think "need correction".  I'm starting these 
discussions to see if there is any consensus before I go writing 
code.  If you (or anyone else) has ideas, please do post here (or 
email directly).  Obviously I will not re-build tools that already 
exist, but rather focus on Canada-specific issues (eg postal code format).


The checks I made for the City Of Ottawa are here: 
http://matthew.davintech.ca/osm/.  I will be able to re-use some of 
what I have done for Ottawa, but based on the discussion so far on 
talk-CA, the list of things that /might/ need correction is less than 
what the local community in Ottawa might consider as /possible/ issues 
for correction.


My current employer is in Montréal (previous one was in Joliette) and 
I regularly work out of Université du Québec en Outaouais so hopefully 
you'll consider me part of the local community in Quebec, even though 
I live in Ontario.  :-)



On 2018-03-10 03:27 PM, Pierre Béland wrote:


Pour revenir aux suggestions de Matthew, de façon à impliquer / 
motiver les communautés locales, ce serait d'offrir les outils et 
listes d'objets à corriger un peu comme le fait Osmose et autres 
outils de QA.




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

Re: [Diversity-talk] Who Maps The World

[Nick Doty]

On Mar 19, 2018, at 3:18 PM, Philip Barnes  wrote:
> 
> Baby hatch sounds a horrible tag, sounds mechanical uncaring and impersonal. 
> I assume it means a maternity ward?

As described in the tag documentation, a "baby hatch" is not a maternity ward, 
but a very specific service, and often a service that is separate from hospital 
or other health care services (although sometimes it's also included in 
hospitals). The "hatch" term apparently comes from the privacy that is inherent 
in such a system, where a parent may not want to be identified when giving up a 
child.

https://en.wikipedia.org/wiki/Baby_hatch 


These are important things to map as standalone items on OSM, I think. It 
doesn't look like the tag is frequently used at this point, and I don't know if 
there are other sources to find these particular venues. But they do exist, 
under different names in different countries and cultures.

—Nick


signature.asc
Description: Message signed with OpenPGP
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Diversity-talk] Who Maps The World

[Marc Gemis]

> Baby hatch sounds a horrible tag, sounds mechanical uncaring and impersonal.
> I assume it means a maternity ward?

It's called "vondelingenschuif" or "vondelingenluik" in Dutch, and the
exist nowadays: http://www.vondelingenluik.be/
It can be used by women that want to give away their babies and want
to stay anonymous.

regards

m.

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Talk-it] import numeri civici Regione Toscana

[Alessandro]

Il 14/03/2018 16:51, Andrea Musuruane ha scritto:

Ciao Alessandro,
  non sono un esperto di wiki ma credo che il nome della pagina 
dovrebbe essere cambiato. Il prefisso IT: mi sembra indichi pagine 
scritte in lingua italiana.


Il discorso di fondo è che l'import è italiano e andrebbe discusso 
principalmente nella lista e in lingua italiana, semmai traducendo 
alcune parti in inglese. Quando in Italia ci siamo messi d'accordo poi 
si passa alla lista import dove chiedono siano verificate le condizioni 
necessarie ma di certo non vengono a sindacare su come abbiamo deciso di 
indicare l'esponente dei civici piuttosto che di altri dettagli.


Discutiamone e cerchiamo di sfruttare questo import per creare uno standard.



La pagina inoltre non è linkata da 
https://wiki.openstreetmap.org/wiki/Import/Catalogue, come richiesto 
dalle import guidelines.


OK fatto, da aggiornare quando i passi andranno avanti.



Dovresti aggiungere il file OSM che hai preparato per l'importazione, 
quello che è risultante dalla trasformazione dei dati (sezione "OSM Data 
Files": Link to your source data files that you have prepared for the 
import - e.g. the .osm files you have derived from the data sources). Se 
non è proponibile mettere il file OSM di tutta la Toscana, sarebbe bene 
mettere almeno quello di un singolo comune che sia abbastanza 
significativo (né troppo piccolo né troppo grande) su cui si possa 
vedere come è stata fatta la traduzione dei dati, che la riproiezione è 
avvenuta in modo corretto, ecc.


Attendiamo processamento dei dati, come ad esempio ha proposto Stefano.



Vorrei far notare che, ad oggi, a differenza di Genova, Savona e Firenze 
non seguono la seguente regola per i numeri civici:
/Nel caso sia presente la specificità "rosso" (a Genova, Savona e 
Firenze), questa si inserisce in lettere minuscole e con uno spazio di 
separazione dal numero civico (es: addr:housenumber 
=9 rosso 
). 
La specificità "nero" non si deve inserire.


/
A Firenze oggi viene usata la lettera R maiuscola per indicare i numeri 
rossi, con uno spazio di separazione dal numero civico.


Nel tagging plan andrebbe quindi specificato meglio come viene composto 
il valore di *addr:housenumber*.


Ho notato la notazione che stanno usando a Firenze. Ovviamente ci si 
adeguerà all'esistente, anche se mi chiedo come gestiscano i civici R 
non rossi: a Genova non è inusuale trovare un 112R dove R non è colore 
ma esponente. Ci sono casi dove si trova ad esempio: 112R, 112 rosso, 
122R rosso.

Come si comportano in quei casi?


Per il resto discutiamone pure sabato, ma questa dei civici rossi sarei 
curioso di capirla.


Alessandro

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

Re: [Talk-ca] Cleanup of addr:country, addr:province, addr:state

[Matthew Darwin]

Searching on "110 Laurier Avenue West, on" in Nominatim already works 
(it finds Ottawa City hall) even though the address has no 
addr:province tag for City Halle.  So I don't think this is a good 
reason to be adding addr:province/addr:province:short_name tags. IMO.  
Unless there is another use case I am missing.  Similarly your example 
of searching for "Toronto, ON" works fine.


I'm guessing this works because the Ontario admin relation has 
ISO3166-2 tag of CA-ON




On 2018-03-10 04:51 PM, Pierre Béland wrote:

Non, inutile si relations. Dans relation province d'Ontario
- ajouter short_name='ON'.

De cette façon, Recherche Toronto, ON
devrait fonctionner. A essayer :)


Pierre


Le samedi 10 mars 2018 15:39:53 HNE, john whelan 
 a écrit :



So you're suggesting adding short_name='ON' to ones that have 
addr:province=Ontario


How would that work?

addr:province=Ontario
addr:province:short_name=ON ?

Merci John



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

Re: [Talk-cz] Schránky - statistiky (aka progress meter ;) )

[Miroslav Suchý]

Dne 24.2.2018 v 08:18 Marián Kyral napsal(a):
> Dvě možnosti:
> 1) Mirek poprosí poštu o upřesnění polohy
> 2) Uděláš si výlet do Sedlčánek a zeptáš se někoho místního, kde tam
> mají schránku :-D
> Sedlčánky patří pod Čelákovice a vypadají, že by si schránku zasložily.


Středník v datech ČP odstraněn.

Schránka 2056 má umístnění: Na Vošverku 121, Sedlčánky.

Mirek
-- 
,,,
   (o o)
  =oOO==(_)==OOo===
 )  mailto:miros...@suchy.cz  tel:+420-603-775737
(   One picture is worth 128K words.
 )Oooo.
 .oooO   (   )
 (   )) /
  \ ((_/
   \_)


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

Re: [Diversity-talk] Who Maps The World

[Philip Barnes]

The health care functions you mentioned there are things that would not be 
mapped as standalone functions in my experience.

They are functions that exist as part of the general healthcare, most will 
exist within the local hospital although some will be provided locally in the 
local surgery (amenity=doctors).

A midwife is not a standalone function, it is a person who works through the 
normal health care system. Births outside hospital are heavily discouraged.

Baby hatch sounds a horrible tag, sounds mechanical uncaring and impersonal. I 
assume it means a maternity ward?

Phil (trigpoint) 

On 19 March 2018 14:46:16 GMT+00:00, Selene Yang  wrote:
>Here are so many examples about tagging for women related things:
>
>https://wiki.openstreetmap.org/wiki/Tagging_in_Support_of_Women_and_Girls,
>I don't know if you've seen this before.
>
>best,
>
>S.
>
>2018-03-19 8:42 GMT-06:00 Marc Gemis :
>
>> >
>> > So do we want to propose switching from amenity=kindergarten as a
>> > general pre-school childcare tag to the more descriptive and
>general
>> > case amenity=childcare tag? Or improve the description of the
>existing
>> > tag and promote subtags, for example to distinguish the general
>case from
>> > the US case and or use age's.
>>
>> Currently,  the wiki page on kindergarten [1] has already several
>> hints to the use for different situations:
>>
>> * "This tag is also currently used for establishments where parents
>> can leave their young children but which provide no formal
>education."
>> * reference to min_age and max_age.
>> * In the section for Germany, Switserland, Austria: "Recently it was
>> proposed to add sub-tags for the three age categories, nursery=yes,
>> preschool=yes and after_school=yes."
>>
>> so it seems that people are already extending the
>kindergarten-related
>> tags to be used for childcare as well.
>>
>>
>> This is a type of discussion that has popped up in other areas as
>> well: do we add additional tags to a more general concept to describe
>> the different variants, or do we use a specific tag for each variant
>?
>> Defining whether something is a variant or a a different "beast", has
>> lead to many mails on the tagging mailing list. People use the
>> expression duck-tagging vs. structured tagging in those discussions.
>>
>> regards
>>
>> m.
>>
>>
>>
>> [1] https://wiki.openstreetmap.org/wiki/Tag:amenity=kindergarten
>>
>> ___
>> Diversity-talk mailing list
>> Code of Conduct: https://wiki.openstreetmap.org/wiki/Diversity/
>> MailingList/CodeOfConduct
>> Contact the mods (private): diversity-talk-ow...@openstreetmap.org
>>
>
>
>
>-- 
>
>Selene Yang Rappaccioli
>Candidata Doctoral en Comunicación
>Universidad Nacional de La Plata
>@SeleneYang

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [Talk-ca] Poorly drawn buildings #GEOG231-W18; #BC2020; #UCalgary-GEOG231; #BC2020-UCalgary

[john whelan]

I think Pierre has already identified the problem some time ago and it has
been raised with Stat Can and others who are involved with BC2020 not that
anyone admits to being responsible for BC2020 and Geoweek. So hopefully we
won't be adding more low quality buildings.

Cheerio John

On 19 March 2018 at 10:42, Matthew Darwin  wrote:

> Hi all,
>
> I noticed some poorly drawn (not-square) buildings in Calgary tagged with
> the hashags #GEOG231-W18;#BC2020;#UCalgary-GEOG231;#BC2020-UCalgary.  If
> you are involved in this project, you might want to review the quality. I
> added a "fixme" tag to the problems I happen to notice.
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-lv] jāņasēta mūs izaicina

[Jānis Skudra]

Tā ir pontonu laipa, sezonāls objekts. Pilnīgi noteikti, ka šobrīd viņa nav
jo ir ledus.. OSM atribūtos ir pareizi ierakstīts: seasonal - summer.

Cieņā
Jānis Skudra

2018. gada 19. marts 10:00 Rihards  rakstīja:

> On 2018.03.18. 21:39, pec...@gmail.com wrote:
> > Es nākamnedēļ došos uz Ogri, nostaigāšu gar tiltiem.
>
> Super, paldies. Lai sanāk jauka pastaiga :)
>
> > Pēteris.
> >
> > 2018. gada 18. marts 14:03 Rihards  > > rakstīja:
> >
> > varbūt kādam sanāk apciemot ogres tiltus - ideāli būtu svaigas
> mapillary
> > bildes :)
> >
> > https://twitter.com/kartes_lv/status/968457959243206656
> > 
> > --
> >  Rihards
> >
> > ___
> > Talk-lv mailing list
> > Talk-lv@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-lv
> > 
> > --
> > mortigi tempo
> > Pēteris Krišjānis--
>  Rihards
>
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lv
>
___
Talk-lv mailing list
Talk-lv@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lv

Re: [Talk-dk] De sidste 30 km af NCN 3 (Hærvejsruten, cykel) mangler?

[Jørgen Elgaard Larsen]

Hov, jeg glemte:


Andreas Hammershøj skrev:

Er der nogen som kan:

-  hjælpe mig med at finde ud af hvad der er sket?


Hvis du har et eksempel på et vej-id, der er faldet ud, kan jeg godt 
kigge efter, hvornår, det er sket.



- rulle ændringerne tilbage, så jeg ikke skal tegne det ind én gang til?


Det kommer an på, hvordan og hvornår det er sket, og hvad der er sket 
siden da.



- give et bud på hvordan den slags fejl undgås i fremtiden?


Med OSM's frie struktur er den bedste metode nok at gøre præcis, hvad du 
har gjort: Hold øje med kortet.


Man kunne nok lave et stykke software, som holdt øje med ændringer og 
alarmerede nogen, når der skete tilpas store ændringer.


Der findes allerede noget i den retning, f.x. https://osmcha.mapbox.com/


- Jørgen


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

Re: [Diversity-talk] Who Maps The World

[Selene Yang]

Here are so many examples about tagging for women related things:

https://wiki.openstreetmap.org/wiki/Tagging_in_Support_of_Women_and_Girls,
I don't know if you've seen this before.

best,

S.

2018-03-19 8:42 GMT-06:00 Marc Gemis :

> >
> > So do we want to propose switching from amenity=kindergarten as a
> > general pre-school childcare tag to the more descriptive and general
> > case amenity=childcare tag? Or improve the description of the existing
> > tag and promote subtags, for example to distinguish the general case from
> > the US case and or use age's.
>
> Currently,  the wiki page on kindergarten [1] has already several
> hints to the use for different situations:
>
> * "This tag is also currently used for establishments where parents
> can leave their young children but which provide no formal education."
> * reference to min_age and max_age.
> * In the section for Germany, Switserland, Austria: "Recently it was
> proposed to add sub-tags for the three age categories, nursery=yes,
> preschool=yes and after_school=yes."
>
> so it seems that people are already extending the kindergarten-related
> tags to be used for childcare as well.
>
>
> This is a type of discussion that has popped up in other areas as
> well: do we add additional tags to a more general concept to describe
> the different variants, or do we use a specific tag for each variant ?
> Defining whether something is a variant or a a different "beast", has
> lead to many mails on the tagging mailing list. People use the
> expression duck-tagging vs. structured tagging in those discussions.
>
> regards
>
> m.
>
>
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:amenity=kindergarten
>
> ___
> Diversity-talk mailing list
> Code of Conduct: https://wiki.openstreetmap.org/wiki/Diversity/
> MailingList/CodeOfConduct
> Contact the mods (private): diversity-talk-ow...@openstreetmap.org
>



-- 

Selene Yang Rappaccioli
Candidata Doctoral en Comunicación
Universidad Nacional de La Plata
@SeleneYang
___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

[Talk-ca] Poorly drawn buildings #GEOG231-W18; #BC2020; #UCalgary-GEOG231; #BC2020-UCalgary

[Matthew Darwin]

Hi all,

I noticed some poorly drawn (not-square) buildings in Calgary tagged 
with the hashags 
#GEOG231-W18;#BC2020;#UCalgary-GEOG231;#BC2020-UCalgary.  If you are 
involved in this project, you might want to review the quality. I 
added a "fixme" tag to the problems I happen to notice.


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

Re: [Talk-it] import numeri civici Regione Toscana

[stefano campus]

mi offro volontario per convertire massivamente il dataset da 3003 a quello
che volete, utilizzando il software convergo coi grigliati dell'IGM
embedded.

@andrea: ne parliamo a merge?

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-dk] De sidste 30 km af NCN 3 (Hærvejsruten, cykel) mangler?

[Jørgen Elgaard Larsen]

JOSM kan fint vise historikken, og har også en revert-plugin, der kan 
tilbageføre ændringer.




Siden din seneste ændring af relationen d. 27/1 2017, er der følgende 
ændringssæt på den:


https://www.openstreetmap.org/changeset/45606901
https://www.openstreetmap.org/changeset/45606901
https://www.openstreetmap.org/changeset/46217011
https://www.openstreetmap.org/changeset/47135749
https://www.openstreetmap.org/changeset/47171745
https://www.openstreetmap.org/changeset/47174019
https://www.openstreetmap.org/changeset/47253886
https://www.openstreetmap.org/changeset/47973968
https://www.openstreetmap.org/changeset/48083933
https://www.openstreetmap.org/changeset/48261215
https://www.openstreetmap.org/changeset/48611991
https://www.openstreetmap.org/changeset/48881149
https://www.openstreetmap.org/changeset/48881794
https://www.openstreetmap.org/changeset/48887979
https://www.openstreetmap.org/changeset/48941394
https://www.openstreetmap.org/changeset/48977072
https://www.openstreetmap.org/changeset/49000760
https://www.openstreetmap.org/changeset/49001863
https://www.openstreetmap.org/changeset/49001863
https://www.openstreetmap.org/changeset/49017028
https://www.openstreetmap.org/changeset/49032049
https://www.openstreetmap.org/changeset/49087842
https://www.openstreetmap.org/changeset/49092412
https://www.openstreetmap.org/changeset/49271640
https://www.openstreetmap.org/changeset/49790350
https://www.openstreetmap.org/changeset/49806610
https://www.openstreetmap.org/changeset/50125398
https://www.openstreetmap.org/changeset/51691195
https://www.openstreetmap.org/changeset/52289544
https://www.openstreetmap.org/changeset/52290539
https://www.openstreetmap.org/changeset/53202753
https://www.openstreetmap.org/changeset/53485383
https://www.openstreetmap.org/changeset/53611533
https://www.openstreetmap.org/changeset/54241848
https://www.openstreetmap.org/changeset/54403539
https://www.openstreetmap.org/changeset/54455403
https://www.openstreetmap.org/changeset/54633521
https://www.openstreetmap.org/changeset/55239414
https://www.openstreetmap.org/changeset/5564
https://www.openstreetmap.org/changeset/55709568
https://www.openstreetmap.org/changeset/55798716
https://www.openstreetmap.org/changeset/56638790
https://www.openstreetmap.org/changeset/56723478
https://www.openstreetmap.org/changeset/56762401
https://www.openstreetmap.org/changeset/56766795
https://www.openstreetmap.org/changeset/56914702
https://www.openstreetmap.org/changeset/56983380


Det er nemmest at se forskellene i JOSM.

- Jørgen

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

Re: [Talk-it] tagging per un ostacolo sull'attraversamento ciclopedonale

[Volker Schmidt]

su un highway farei un nodo bollard e width,


Ho messo un nodo
barrier=bollard
bicycle=yes
foot=yes
maxwidth=1

Preferisco maxwidth per indicare la larghezza massima del  veicolo che può
passare.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Diversity-talk] Who Maps The World

[Rory McCann]

Hi Charlotte,

What about amenity=childcare? There are ~12,000 of them mapped in OSM. 
Or are you thinking of something else? (I think) it's been part of

iD's presets for about 5 years[1]. It's not (yet) in JOSM's presets I
think.

I initially wondered if "kindergarten" in Germany was the same as a
childcare or creche, but apparently a German kindergarten is more like a
playschool (or kindergarden in USA).

Rory

[1] 
https://github.com/openstreetmap/iD/commit/26cab408e8050ec0eacefe9cfca15db95ce423b2


On 18/03/18 23:23, Charlotte Wolter wrote:

Paul,

A kindergarten is a school, not a child-care center. They are two 
fundamentally different things. Also, child-care centers serve a range 
of ages, not just 5-year-olds. I, too, tried to find a real child-care 
tag a few months ago. There is none, and "kindergarten" doesn't cut it.


Charlotte


At 04:40 PM 3/15/2018, you wrote:

Content-type: multipart/alternative;
 boundary=E05DE6A0022FF7C5FF3B1F54
Content-language: en-US

On 3/14/2018 6:47 PM, alyssa wright wrote:

Hi all,

City Lab article below on gender disparity in OSM. I actually think 
things have evolved and are more nuanced then ever before. Wondering 
if I am being naive. 


Yes. Part of the thesis of the article is based around the claims of 
what gets mapped. The claims in the article do not reflect reality.


OSM has more child-care centers (amenity=kindergarten) mapped than 
sports arenas or sports arenas, the examples from the article. I 
couldn't figure out what tags Levine was talking about for strip clubs.


For healthcare, the claims are vaguer, but as a general rule, 
"primary" information like something being a doctor's office, clinic, 
or other healthcare facility gets mapped faster than "subtag" 
information like what type of specialty the doctor's has. This is 
normal - when I'm out mapping, noting where there's a doctor's or 
clinic is more important than what type it is. You see the same in 
other subtags.


 Looking at what healthcare facilities is tagged with that additional 
information, and ignoring "general", the five most popular are 
"Obstetrics and gynaecology", "Ophthalmology", "General (internal) 
medicine", "Paediatrics", and "Trauma and orthopaedic surgery". (UK 
terms).


The gender percentages are interesting, and if accurate, put a much 
lower value on percentage of mapping that HOT does than I've seen in 
the past. I suspect there are some problems with different sources of 
numbers, and the numbers cited not being accurate.


[1]: 
https://taginfo.openstreetmap.org/keys/healthcare%3Aspeciality#values



___ Diversity-talk mailing 
list Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct Contact 
the mods (private): diversity-talk-ow...@openstreetmap.org 


Charlotte Wolter
927 18th Street Suite A
Santa Monica, California
90403
+1-310-597-4040
Mobile: 310-663-3699
techl...@techlady.com
Skype: thetechlady



___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org



___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk-fr] Présentation

[Guillaume Largeau]

Bonjour,

Merci pour vos messages.

Pour le moment je decrouvre et complète/rectifie la carte sur mon secteur.



Le lun. 19 mars 2018 à 11:19, Jérôme Seigneuret 
a écrit :

> Salut,
> Et bienvenu. Pas mal de travail de ton coté sur la frange littoral avec
> des sujets qui ont été abordé. Sur quelle thématique souhaites as tu
> commencé à travailller?
>
> Le 17 mars 2018 à 12:25, marc marc  a écrit :
>
>> Le 17. 03. 18 à 08:35, Guillaume Largeau a écrit :
>> > Je me présente Guillaume, jeune contributeur OSM .
>>
>> Bienvenu, si tu as des questions, n'hésites pas.
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
> ___
> 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] De BD Carthage à BD TOPO Hydrographie ?

[marc marc]

Le 19. 03. 18 à 10:13, Rpnpif a écrit :
> Le 17 mars 2018, deuzeffe a écrit :
> 
>> Mmmhhh ??? On peut utiliser QGis pour mettre à jour JOSM qui mettra à
>> jour osm ? C'est plus intéressant que JOSM seul ?
> 
> Oui puisque chez moi JOSM est trop lent et bloque avec autant de
> données.
> 
> Bien sûr, le but est de sélectionner une petite zone (communale au
> plus).
> Mais je vais peut-être me rabattre sur la couche rapatriée sur Id.

Il ne faut pas télécharger la France entière.
Josm rame à cause de la quantité démesurée de données.

A noter que josm permet lui aussi d'afficher BD Carthage comme une 
couche limité à la zone visible de ton écran au lieu de tous le pays.
c'est dans menu imagerie, BD Carthage :)

Mais c'est 2 choses assez différente.
l'un sont les données pour intégrer un à un les rivières.
l'autre est de l'affichage pour des retouches ponctuelles

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

Re: [OSM-talk-fr] Places PMR ?

[Philippe Verdy]

Heureusement qu'on ne fait pas une traduction littérale sinon "disabled
person" désignerait un "incapable", ce qui est vu comme insultant, les
anglais veulent juste dire "personne souffrant d'une incapacité (physique
ou psychique)", mais en français le mot "handicapé" (pourtant issu de
l'anglais "handicap"...) est bien plus heureux. On peut se demander
pourquoi OSM a choisi ce raccourci "disabled", mais cela se comprend par le
fait qu'un "handicap" (mot anglais adopté en français) est encore traduit
souvent (même sur le wiki) par "disabilities" (au sens en français de
"incapacités", donc "handicaps").

On note aussi en forme longue et formelle en France aussi l'usage des
expressions "incapacités physiques" au lieu de "handicaps physiques", parce
que pour certains le mot "handicapé" les heurte. Pourtant les handicaps
sont monnaie courante et peuvent survenir au cours de la vie de plein de
gens (en fait on ne cesse en vieillissant d'en acquérir, mais les handicaps
liés au vieillissement sont rarement pris en compte, contrairement aux
handicaps de naissance ou des enfants, ou ceux survenant suite à un
accident ou une maladie grave à l'age adulte, quand ça touche une personne
de plus de 50 ans, on se dit encore "c'est normal", même si la personne en
souffre réellement et pourrait être mieux aidée ou un peu favorisée dans
ses déplacements et sa vie quotidienne; les difficultés motrices des plus
de 50 ans sont totalement ignorées, on protège avant tout les enfants et
jeunes adultes parce qu'ils sont "économiquement intéressants", comme si
c'était juste des investissements financiers et comme si l'aspect humain et
social et n'avant pas autant de valeur à tout âge, et que la société
devrait alors choisir qui mérite d'être un peu aidé).

C'est un peu paradoxal, car en Angleterre c'est le contraire: on favorise
très nettement les personnes âgées (et les animaux domestiques), mais on ne
fait pas grand chose pour les enfants qu'on nourrit mal, qu'on ne soigne
pas, qu'on ne protège pas par la signalisation devant les écoles (refus un
peu partout d'installer des passages protégés même aux carrefours):

Une campagne vient de se lancer au Royaume-Uni pour demander que les
municipalités installent les passages zébrés: réponse: trop cher, car
évidemment les municipalités n'ont pas l'habitude et confie ça a des
sociétés privées qui facturent des prix exorbitants : ça coûte là bas plus
de 100 000 livres sterling par passage zébré, là où en France c'est une
demi-journée de travail pour le personnel technique municipal et un pot de
peinture, soit en gros 1000 euros maximum, et un peu de matériel à
renouveler de temps en temps pour les équipes d'entretien des voiries).
L'Angleterre n'a donc pas de passages zébrés, juste à certains endroits des
poteaux noirs et blanc avec un globe lumineux orange, et ça coûte un peu
partout des vies et ça coûte une fortune aux assurances ou ça ruine des
familles pour les frais médicaux et la prise en charge ensuite des
handicaps.

Là on se dit que certaines sociétés de travaux publics qui travaillent pour
les collectivités abusent aussi du côté des prix et font payer trop cher
les collectivités (d'où aussi un état catastrophique des routes et des rues
en Angleterre, et aussi des accidents nombreux, les Anglais ayant la
réputation de conduire vite même en zone urbaine dans les zones limitées à
20 ou 30 ou l'approche des écoles!)

Des démonstrations ont été faites par des assos de quartier à qui on a
refusé l'installation de passages zébrés : c'est très clair qu'ils sont
efficaces et beaucoup plus que le vieux système des globes oranges qui date
du temps des voitures à cheval et à une époque où nombre de routes
n'étaient pas encore goudronnées ou étaient seulement pavées ! Pourtant
maintenant même en zone urbaine, on sait préserver les pavés, les drainer,
on n'a plus autant de flaues de boues, les rues sont nettoyées, et on sait
poser des marquages au sol (et les Anglais sans en faire pour les traits de
délimitation des voies). Ces assos ont été poursuivies et condamnées pour
"mise en danger" par leurs démonstrations, pourtant faites sous
surveillance puisque ces démos utilisaient des signalisations "non
réglementaires".

Là on atteint des résistances liées à la préservation de vieilles habitudes
et des freins liés au mode de fonctionnement des collectivités avec leurs
prestataires, et là encore une législation en retard sur la réalité des
choses et beaucoup trop influencée par quelques gros lobbies économiques,
contre la volonté de la majorité des citoyens et même le bon sens.

Le 19 mars 2018 à 11:15, Jérôme Seigneuret  a
écrit :

> En effet j'ai fait une traduction littérale... Merci pour cette précision
>
> Le 19 mars 2018 à 11:09, Philippe Verdy  a écrit :
>
>> Juste une note de traduction "disabled" (raccourci OSM pour "disabled
>> people") signifie ici : "(personne) handicapée", et non pas "désactivé".
>>
>

Re: [Talk-us] Help fight advertising

[Frederik Ramm]

Hi,

On 19.03.2018 01:08, Jordan Brod wrote:
> I went looking for any information printed in guidelines or code of
> conduct about advertising in the attributes of a feature and I couldn't
> find where it is approved/prohibited or even mentioned.  Does anybody
> know where the rule against this is?

Firstly, many rules in OSM are not written down. Just because there's no
policy that says "don't do X" doesn't mean that X is welcome in OSM, or
that someone who got their X deleted has a legitimate basis for a complaint.

The current situation with written rules is that
http://wiki.openstreetmap.org/wiki/Key:description
says "Never use description=* to add advertising messages.", and
more generally our "How We Map" rules
(http://wiki.openstreetmap.org/wiki/How_We_Map) say that what you add
must be truthful and verifiable, both of which is rarely the case for
advertising.

Bye
Frederik

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

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

[Talk-dk] De sidste 30 km af NCN 3 (Hærvejsruten, cykel) mangler?

[Andreas Hammershøj]

Hej OSM'ere,
Vejdirektoratet er i gang med deres forårsopdatering af cykelrutekortet på
trafikken.dk. De bruger OSM som kilde til nationalruterne, men har opdaget
at de sidste ca. 30 km mellem Gersholt og Frederikshavn mangler. Jeg er ret
overbevist om at de var der sidste år, i det jeg lavede kvalitetssikring på
den.

Relation:
https://www.openstreetmap.org/relation/61491#map=11/57.4053/10.4142=C

Osm.org vil ikke lade mig loade historikken, da den er for lang.


Er der nogen som kan:

-  hjælpe mig med at finde ud af hvad der er sket?

- rulle ændringerne tilbage, så jeg ikke skal tegne det ind én gang til?

- give et bud på hvordan den slags fejl undgås i fremtiden?

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

Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?

[Philippe Verdy]

Je pensais qur tu étais sous Windows mais sous Linux le problème est le
même : tu peux avoir deux installations de Java en 32 bits ou 64 bits.
Et dans les deux cas tu peux régler la taille de VM à lancer pour JOSM
(paramètre -Xmx=256M par défaut, tu peux facilement monter à -Xmx=1G).
La taille de VM par défaut suffit pour la plupart des applis Java mais pour
JOSM il est hautement recommandé de l'augmenter su tu veux avoir plusieurs
fournisseurs d'imagerie, et gérer beaucoup plus de données.
Je pense malgré tout que JOSM pourrait facilement utiliser beaucoup moins
de mémoire en utilisant un cache sur disque et devrait pouvoir fonctionner
et gérer beaucoup de données même avec une VM de 256Mo (au prix d'un swap
avec le cache sur disque, comme il le fait déjà pour le cache des tuiles
des fournisseurs d'imagerie car il n'a pas besoin de les afficher toutes en
même temps)

Le 19 mars 2018 à 11:26, Rpnpif  a écrit :

> Le 19 mars 2018, Philippe Verdy a écrit :
>
> > JOSM est rapide et ne bloque pas du tout si tu l'utilises avec Java en 64
> > -bits qui ne souffre pas de la limite de taille mémoire trop basse par
> > défaut.
> > JOSM documente comment augmenter la taille de la VM par défaut (même en
> 32
> > bits seulement on peut le faire même si on ne peut pas aller aussi haut
> > qu'en 64-bits).
>
>
> Bizarre dans ce cas. Je suis normalement en 64 bits (Debian). Je vais
> creuser la question.
> Merci.
>
> --
> Alain Rpnpif
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?

[Philippe Verdy]

Le gestionnaire Java dans Windows lance par défaut la VM 32 bits si tu as
installé la version 32 bits de Java, même si tu as aussi installé la
version 64 bits. Si tu n'as pas installé du tout la version 32 bits, ce
gestionnaire se lance en 64 bits. Bref désinstalle cette fichue version 32
bits de Java si ton OS est 64 bits (plus personne n'a besoin d'exécuter des
applets Java dans un navigateur 32 bits).
Note aussi que le gestionnaire 64 bits met aussi à jour automatiquement la
version 64 bits.
Si tu désinstalles la version 32 bits de Java la version 64 bits sera
encvore là mais tu n'auras plus de gestionnaire dans le panneau de
configuration: réinstalle la version 64 bits pour installer le gestionnaire
64 bits.

Il se trouve que la page d'Oracle proposant d'installer Java te proposes la
version 32 bits si ton navigateur est 32 bits même si ton OS est 64 bits,
car le site web ne sait pas détecter correctement que ton OS peut faire
autre chose. En cause ici:

Les navigateurs qui sont encore trop nombreux à ne s'intaller eux-même
qu'en 32 bits (dont Chrome dont la version 64 bits existe mais n'est pas
proposée car pas encore officiellement supportée: Chrome est en 32 bits car
il n'a pas besoin du 64-bits pour créer des processus pour ses moiteurs de
rendus et onglets et il utilise alors un peu moins de mémoire par
processus; IE 11+ et Edge sont en 64 bits et ne créent pas de processus
séparés mais des threads, avec cependant moins de sécurité qu'avec
l'isolation en processus séparés: si le processus plante tout le navigateur
plante, alors qu'avec des processus séparés pour un moteur de rendu, ou
pour un seul onglet, ou un une seule extension, les processus parents
restent fonctionnels et ne sont pas attaquables aussi facilement par les
processus enfants plantés...) Le pari de Chrome est plus de sécurité pour
l'isolation avec des processus et non des threads, et comme chaque
processus en fait moins, il n'a pas besoin d'autant de mémoire et chacun
peut tourner en 32 bits. Cependant rien n'interdit à Chrome de créer des
processus enfants 64 bits (ce qu'il fait dans sa version 64 bits non encore
supportée). Chrome devra réfléchir à exécuter ses processus enfants selon
leurs besoins en 32 bits ou 64 bits.

Du fait de l'isolation des processus de Chrome, un site web tiers ne peut
pas savoir si ton OS supporte ou pas le 64 bits. Mais le site officiel de
Java t'avertit et te propose un lien alternatif pour les OS 64 bits si tu
visites le site avec un navigateur 32 bits. Il te prévient aussi que la
version 64 bits de Java ne prend pas en charge l'intégration des anciennes
"applets" pour les navigateurs 32 bits.

Le 19 mars 2018 à 11:07, Jérôme Seigneuret  a
écrit :

> On a pas sur le wiki un procces pour l'install et la mise à jour de java
> sur les différentes plateforme? après on a piour certains une contrainte de
> taille, (le gestionnaire du SI qui n'installe que les 32Bit et non les 64)
> je suis pas admin de mon poste donc... dans le c** lulu
>
> Le 19 mars 2018 à 10:25, Philippe Verdy  a écrit :
>
>> JOSM est rapide et ne bloque pas du tout si tu l'utilises avec Java en 64
>> -bits qui ne souffre pas de la limite de taille mémoire trop basse par
>> défaut.
>> JOSM documente comment augmenter la taille de la VM par défaut (même en
>> 32 bits seulement on peut le faire même si on ne peut pas aller aussi haut
>> qu'en 64-bits).
>>
>> Personnellement je n'utilise plus du tout l'installation de Java en 32
>> bits (qui ne servait encore que pour les "plugins" et "applets" au sein
>> d'un navigateur 32-bits) et qui n'est même pas installé du tout, je
>> n'utilise que la version 64 bits, donc sans aucune intégration aux
>> navigateurs 32 bits. Je ne comprend pas d'ailleurs pourquoi le site Java
>> continue de proposer par défaut la version 32-bits même sur un OS 64 bits:
>> la double installation est totalement inutile, et cela fait longtemps que
>> Java aurait du prendre en charge l'intégration des anciennes applets dans
>> un navigateur 32 bits via un proxy où la VM Java ne serait installée qu'en
>> 64 bits. Ce qui est parfaitement possible (et même documenté dans le JDK
>> sur la façon de le faire!)
>>
>> L'ennui c'est le composant d'intégration au navigateur qui n'a jamais
>> évolué et continue d'utiliser la vielle méthode NPAPI héritée de Netscape
>> et que même Firefox a abandonné (après déjà IE, Edge, Chrome, Safari,
>> Opera...), et qu'il aurait du être réécrit depuis longtemps pour profiter
>> des évolutions (y compris des améliorations de sécurité au sein des
>> navigateurs comme au sein de la VM Java elle-même: NAPI est totalement
>> obsolète, remplacé sur tous les principaux navigateurs).
>>
>>
>> Le 19 mars 2018 à 10:13, Rpnpif  a écrit :
>>
>>> Le 17 mars 2018, deuzeffe a écrit :
>>>
>>> > Mmmhhh ??? On peut utiliser QGis pour mettre à jour JOSM qui mettra à
>>> > jour osm ? C'est plus intéressant que JOSM seul ?
>>>
>>> Oui puisque chez 

Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?

[Rpnpif]

Le 19 mars 2018, Philippe Verdy a écrit :

> JOSM est rapide et ne bloque pas du tout si tu l'utilises avec Java en 64
> -bits qui ne souffre pas de la limite de taille mémoire trop basse par
> défaut.
> JOSM documente comment augmenter la taille de la VM par défaut (même en 32
> bits seulement on peut le faire même si on ne peut pas aller aussi haut
> qu'en 64-bits).


Bizarre dans ce cas. Je suis normalement en 64 bits (Debian). Je vais
creuser la question.
Merci.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Présentation

[Jérôme Seigneuret]

Salut,
Et bienvenu. Pas mal de travail de ton coté sur la frange littoral avec des
sujets qui ont été abordé. Sur quelle thématique souhaites as tu commencé à
travailller?

Le 17 mars 2018 à 12:25, marc marc  a écrit :

> Le 17. 03. 18 à 08:35, Guillaume Largeau a écrit :
> > Je me présente Guillaume, jeune contributeur OSM .
>
> Bienvenu, si tu as des questions, n'hésites pas.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Places PMR ?

[Jérôme Seigneuret]

En effet j'ai fait une traduction littérale... Merci pour cette précision

Le 19 mars 2018 à 11:09, Philippe Verdy  a écrit :

> Juste une note de traduction "disabled" (raccourci OSM pour "disabled
> people") signifie ici : "(personne) handicapée", et non pas "désactivé".
>
> Le 19 mars 2018 à 10:51, Jérôme Seigneuret 
> a écrit :
>
>> Pour le reste ça se base sur des tags générique dont le schéma est ici
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/parkin
>> g#General_tags
>>
>>
>>- *disabled
>>=* (holders of blue
>>badge, UK, or other such disabled persons' permit. Used on traffic signs 
>> to
>>exempt said group from access restrictions; not just regarding parking)*
>>
>>
>> * Traduction : désactivé = * (détenteur d'un badge bleu, Royaume-Uni, ou
>> autre permis pour personnes handicapées.) Utilisé sur les panneaux de
>> signalisation pour exclure ce groupe des restrictions d'accès, pas
>> seulement pour le stationnement. *
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Places PMR ?

[Philippe Verdy]

Juste une note de traduction "disabled" (raccourci OSM pour "disabled
people") signifie ici : "(personne) handicapée", et non pas "désactivé".

Le 19 mars 2018 à 10:51, Jérôme Seigneuret  a
écrit :

> Pour le reste ça se base sur des tags générique dont le schéma est ici
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/parking#General_tags
>
>
>- *disabled
>=* (holders of blue
>badge, UK, or other such disabled persons' permit. Used on traffic signs to
>exempt said group from access restrictions; not just regarding parking)*
>
>
> * Traduction : désactivé = * (détenteur d'un badge bleu, Royaume-Uni, ou
> autre permis pour personnes handicapées.) Utilisé sur les panneaux de
> signalisation pour exclure ce groupe des restrictions d'accès, pas
> seulement pour le stationnement. *
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?

[Jérôme Seigneuret]

On a pas sur le wiki un procces pour l'install et la mise à jour de java
sur les différentes plateforme? après on a piour certains une contrainte de
taille, (le gestionnaire du SI qui n'installe que les 32Bit et non les 64)
je suis pas admin de mon poste donc... dans le c** lulu

Le 19 mars 2018 à 10:25, Philippe Verdy  a écrit :

> JOSM est rapide et ne bloque pas du tout si tu l'utilises avec Java en 64
> -bits qui ne souffre pas de la limite de taille mémoire trop basse par
> défaut.
> JOSM documente comment augmenter la taille de la VM par défaut (même en 32
> bits seulement on peut le faire même si on ne peut pas aller aussi haut
> qu'en 64-bits).
>
> Personnellement je n'utilise plus du tout l'installation de Java en 32
> bits (qui ne servait encore que pour les "plugins" et "applets" au sein
> d'un navigateur 32-bits) et qui n'est même pas installé du tout, je
> n'utilise que la version 64 bits, donc sans aucune intégration aux
> navigateurs 32 bits. Je ne comprend pas d'ailleurs pourquoi le site Java
> continue de proposer par défaut la version 32-bits même sur un OS 64 bits:
> la double installation est totalement inutile, et cela fait longtemps que
> Java aurait du prendre en charge l'intégration des anciennes applets dans
> un navigateur 32 bits via un proxy où la VM Java ne serait installée qu'en
> 64 bits. Ce qui est parfaitement possible (et même documenté dans le JDK
> sur la façon de le faire!)
>
> L'ennui c'est le composant d'intégration au navigateur qui n'a jamais
> évolué et continue d'utiliser la vielle méthode NPAPI héritée de Netscape
> et que même Firefox a abandonné (après déjà IE, Edge, Chrome, Safari,
> Opera...), et qu'il aurait du être réécrit depuis longtemps pour profiter
> des évolutions (y compris des améliorations de sécurité au sein des
> navigateurs comme au sein de la VM Java elle-même: NAPI est totalement
> obsolète, remplacé sur tous les principaux navigateurs).
>
>
> Le 19 mars 2018 à 10:13, Rpnpif  a écrit :
>
>> Le 17 mars 2018, deuzeffe a écrit :
>>
>> > Mmmhhh ??? On peut utiliser QGis pour mettre à jour JOSM qui mettra à
>> > jour osm ? C'est plus intéressant que JOSM seul ?
>>
>> Oui puisque chez moi JOSM est trop lent et bloque avec autant de
>> données.
>>
>> Bien sûr, le but est de sélectionner une petite zone (communale au
>> plus).
>> Mais je vais peut-être me rabattre sur la couche rapatriée sur Id.
>>
>> Merci.
>>
>> --
>> Alain Rpnpif
>>
>> ___
>> 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
>
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Places PMR ?

[PanierAvide]

Bonjour Marc et Jérôme,

Merci pour vos deux réponses, ça montre bien une divergence des 
pratiques :-) Effectivement l'ambiguïté de la représentation porte sur 
les places individuelles, le cas du décompte sur un parking global est 
pour le coup explicite avec capacity:disabled=*.


Malgré la confusion, de ce que je comprends, il y a quand même consensus 
sur les points suivants :


- wheelchair=yes indique l'accessibilité réelle sur le terrain de la place
- Il vaudrait mieux se baser des tags orientés access=*

Après je vois qu'il y a pléthore de valeurs possibles si on part sur la 
logique access. Pourquoi un combo amenity=parking_space + access=no + 
disabled=yes/designated ne serait-il pas suffisant (en ajoutant 
éventuellement du capacity:disabled pour un groupe de places) ?


Cordialement,

Adrien.


Le 19/03/2018 à 10:51, Jérôme Seigneuret a écrit :

salut,

En clair on utilise capacity:disabled=1 sur la zone de parking ou un 
espace.  Le truc c'est que si tu englobes les capacités sur la zone et 
sur la place c'est une double info et un double comptage. En clair,
si tu mixes les deux il faut enlever les espaces dans la zone général 
et les décompter. parking_space utilise la relation site pour 
regrouper les places d'un parking. C'est du micro mapping


Pour info, le stationnement avec la CMI n'est pas Franco-Français et 
les règles à établir sont Européenne. Donc si le sujet coince il 
faudra le remonter sur  osm-talk


Pour le reste ça se base sur des tags générique dont le schéma est ici

https://wiki.openstreetmap.org/wiki/Proposed_features/parking#General_tags

  * /disabled
=* (*holders of
blue badge*, UK, or other such disabled persons' permit. Used on
traffic signs to exempt said group from access restrictions; not
just regarding parking)/

/
*Traduction :*désactivé = * (détenteur d'un badge bleu, Royaume-Uni, 
ou autre permis pour personnes handicapées.) Utilisé sur les panneaux 
de signalisation pour exclure ce groupe des restrictions d'accès, pas 
seulement pour le stationnement.

/
/
/
Ça me parait clair. Mais doit être utilisé avec access:* comme préfixe
https://wiki.openstreetmap.org/wiki/Key:disabled demande d'utiliser 
wheelchair=yes (et pourquoi pas wheelchair=designated qui est plus 
cohérent en terme de correspondance)


De plus comme dis @marc marc parking_space=disabled n'est pas décrit 
et n'a pas vraiment de sens car ne rentre pas dans le schéma global.


amenity=parking + capacity=100capacity:disabled=1 (100 places dont 1 
pour détenteur de la CMI) >>> pas le choix il me semble sur ce cas. Je 
vois mal mettre wheelchair=yes et donc dire qu'on à une capacité de 
100 places pour les PMR.


amenity=parking_space + capacity:disabled=1 + wheelchair=yes (1 place 
dont 1 pour détenteur de la CMI)
(de base capacity=1) mais le schéma permet de mapper un ensemble de 
place et même d'ajouter le nom de la place (limite quand c'est le nom 
de gens. Je ne pense pas que la CNIL l’admette)


pourquoi capacity:disabled=1 + wheelchair=yes

On peut aussi mettre wheelchair=designated mais j'ai un peu du mal 
avec cette valeur de clé car elle n'est pas interprétée pas tous les 
outils et de base ils utilisent yes ou limited. Pour faire simple 
certains outils ne permettent d'afficher les résultat que pour 
wheelchair=yes. Pas de consensus donc on a une double information.


Bref si l'on veut aller plus loin, vu que ce sont des places réservées 
avec un panneau spécial, tu peux ajouter un point pour le panneau de 
signalisation traffic_sign=FR:B6d,M6h (pour plus d'info voir article 
L. 241-3-2 du code de l'action sociale et des familles)


access:disabled=designated pourquoi pas

access:conditional=designated @ disabled
Si tu mets ça il faut déjà mettre un type d'accès générique
access=no + access:conditional=designated @ disabled (sinon par défaut 
access=yes, access:conditional est une surcharge pour remplacer des 
valeurs)




Ma préférence à moi ;-)

amenity=parking_space +capacity:disabled=2+ wheelchair=yes (cas d'un 
groupe de places car le schéma le permet)
amenity=parking_space +access:disabled=designated+ wheelchair=yes (si 
une seule place mais correspond à la première proposition avec la 
valeur de capacité = 1)


Vous remarquerez que je conserve wheelchair=yes car pour certains site 
c'est une clé indispensable et je pense qu'on va avoir des problème si 
l'on vire cette clé



pour info voici quelques liens utiles:

  * http://ec.europa.eu/social/BlobServlet?docId=3170=fr
  * 
https://www.ecologique-solidaire.gouv.fr/laccessibilite-du-stationnement-et-carte-mobilite-inclusion-cmi
  * 
http://www.handicap-info.fr/carte/carte-europeenne-de-stationnement-ex-gic-gig/

A+ Jérôme

Le 18 mars 2018 à 19:55, marc marc > a écrit :


Bonjour,

Le 18. 03. 18 à 19:39, PanierAvide a écrit :
> En ce qui concerne les places PMR, j'ai pour habitude de 

Re: [Diversity-talk] Who Maps the World

[Marc Gemis]

Rory,

I did not want to say that some objects are not gendered in some
countries, I'm sorry for not making that clear.
I wanted to point out is that "because object X is gendered in a
country, it is gendered in every country" is wrong.
So any statistics that count the number of objects X on a global level
to point out gender inequality is wrong.


regards

m.





On Mon, Mar 19, 2018 at 10:35 AM, Rory McCann  wrote:
> Hi Marc,
>
> Unfortunately a lot of things are gendered, and often it's not logical. So
> when someone say "In my home ($COUNTRY), $THING is gendered for $GENDER",
> you basically have to just take their word for it, even if it doesn't make
> logical sense for you. So people can't really answer "Why?" It is because it
> is (in $COUNTRY).
>
> On 16/03/18 07:00, Marc Gemis wrote:
>>
>> - Why is a bar considered a men-only place ? Can't it be a trendy
>> place for all kinds young people to enjoy a good night out ?
>>I have seen pubs mentioned in previous articles as well. Where I
>> live we map "taverns" as pubs. Many taverns are places where families
>> go on a sunday afternoon to meet, let the children play in the
>> playground, have an ice-creme, pancake or even full dinner together.
>
>
> Traditionally (in IE & UK) women weren't allowed in pubs, and not supposed
> to drink pints. Ergo there's still an overhang of that.
>
>> - Why is a toilet without gender tag considered men-only ? Where I
>> live public toilets have separate sections for women and men, that is
>> why we do not bother to map gender.
>
>
> Apparently in some countries that's not true! At SotM 2016 Srravya C
> explained that this isn't the case in India.
>
> --
> Rory

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk-fr] Places PMR ?

[Jérôme Seigneuret]

salut,

En clair on utilise  capacity:disabled=1 sur la zone de parking ou un
espace.  Le truc c'est que si tu englobes les capacités sur la zone et sur
la place c'est une double info et un double comptage. En clair,
si tu mixes les deux il faut enlever les espaces dans la zone général et
les décompter. parking_space utilise la relation site pour regrouper les
places d'un parking. C'est du micro mapping

Pour info, le stationnement avec la CMI n'est pas Franco-Français et les
règles à établir sont Européenne. Donc si le sujet coince il faudra le
remonter sur  osm-talk

Pour le reste ça se base sur des tags générique dont le schéma est ici

https://wiki.openstreetmap.org/wiki/Proposed_features/parking#General_tags


   - *disabled
   =* (holders of blue
   badge, UK, or other such disabled persons' permit. Used on traffic signs to
   exempt said group from access restrictions; not just regarding parking)*



* Traduction : désactivé = * (détenteur d'un badge bleu, Royaume-Uni, ou
autre permis pour personnes handicapées.) Utilisé sur les panneaux de
signalisation pour exclure ce groupe des restrictions d'accès, pas
seulement pour le stationnement. *

Ça me parait clair. Mais doit être utilisé avec access:* comme préfixe
https://wiki.openstreetmap.org/wiki/Key:disabled demande d'utiliser
wheelchair=yes
(et pourquoi pas  wheelchair=designated qui est plus cohérent en terme de
correspondance)

De plus comme dis @marc marc  parking_space=disabled n'est pas décrit et
n'a pas vraiment de sens car ne rentre pas dans le schéma global.

amenity=parking + capacity=100 capacity:disabled=1 (100 places dont 1 pour
détenteur de la CMI) >>> pas le choix il me semble sur ce cas. Je vois mal
mettre wheelchair=yes et donc dire qu'on à une capacité de 100 places pour
les PMR.

amenity=parking_space + capacity:disabled=1 + wheelchair=yes (1 place dont
1 pour détenteur de la CMI)
(de base capacity=1) mais le schéma permet de mapper un ensemble de place
et même d'ajouter le nom de la place (limite quand c'est le nom de gens. Je
ne pense pas que la CNIL l’admette)

pourquoi capacity:disabled=1 + wheelchair=yes

On peut aussi mettre  wheelchair=designated mais j'ai un peu du mal avec
cette valeur de clé car elle n'est pas interprétée pas tous les outils et
de base ils utilisent yes ou limited. Pour faire simple certains outils ne
permettent d'afficher les résultat que pour wheelchair=yes. Pas de
consensus donc on a une double information.

Bref si l'on veut aller plus loin, vu que ce sont des places réservées avec
un panneau spécial, tu peux ajouter un point pour le panneau de
signalisation traffic_sign=FR:B6d,M6h (pour plus d'info voir article L.
241-3-2 du code de l'action sociale et des familles)

access:disabled=designated pourquoi pas

access:conditional=designated @ disabled
Si tu mets ça il faut déjà mettre un type d'accès générique
access=no +  access:conditional=designated @ disabled (sinon par défaut
access=yes, access:conditional est une surcharge pour remplacer des valeurs)



Ma préférence à moi ;-)

amenity=parking_space + capacity:disabled=2 + wheelchair=yes  (cas d'un
groupe de places car le schéma le permet)
amenity=parking_space +  access:disabled=designated + wheelchair=yes   (si
une seule place mais correspond à la première proposition avec la valeur de
capacité = 1)

Vous remarquerez que je conserve  wheelchair=yes  car pour certains site
c'est une clé indispensable et je pense qu'on va avoir des problème si l'on
vire cette clé


pour info voici quelques liens utiles:

   - http://ec.europa.eu/social/BlobServlet?docId=3170=fr
   -
   
https://www.ecologique-solidaire.gouv.fr/laccessibilite-du-stationnement-et-carte-mobilite-inclusion-cmi
   -
   
http://www.handicap-info.fr/carte/carte-europeenne-de-stationnement-ex-gic-gig/

A+ Jérôme

Le 18 mars 2018 à 19:55, marc marc  a écrit :

> Bonjour,
>
> Le 18. 03. 18 à 19:39, PanierAvide a écrit :
> > En ce qui concerne les places PMR, j'ai pour habitude de renseigner un
> > combo amenity=parking_space + capacity:disabled=1 + wheelchair=yes (si
> > la place est vraiment accessible, ce qui n'est pas toujours le cas).
> > J'ai cru comprendre qu'il y avait aussi possibilité d'utiliser
> > parking_space=disabled.
> >
> > Ma question est la suivante : quelle est donc la bonne pratique sur la
> > question des places PMR ? Car ça vaudrait le coup de s'accorder et de
> > l'expliciter sur le wiki :-)
>
> Je me suis posé la même question le mois passé et je n'ai pas trouvé
> de réponse satisfaisante.
>
> parking_space=disabled a l'air d'être une spécificité franco-française
> ~7000 en France sur les ~8000 dans le monde
> c'est pas très cohérent avec parking= (en surface ou souterrain)
>
> à côté de cela, il y a :
> disabled=designated pour désigner que l'objet a été fait pour une
> personne à mobilité réduite (à combiner souvent avec access=no)
>
> ou
> access:disabled=designated
> access:role=no
>
> 

Re: [Diversity-talk] Who Maps the World

[Rory McCann]

Hi Marc,

Unfortunately a lot of things are gendered, and often it's not logical. 
So when someone say "In my home ($COUNTRY), $THING is gendered for 
$GENDER", you basically have to just take their word for it, even if it 
doesn't make logical sense for you. So people can't really answer "Why?" 
It is because it is (in $COUNTRY).


On 16/03/18 07:00, Marc Gemis wrote:

- Why is a bar considered a men-only place ? Can't it be a trendy
place for all kinds young people to enjoy a good night out ?
   I have seen pubs mentioned in previous articles as well. Where I
live we map "taverns" as pubs. Many taverns are places where families
go on a sunday afternoon to meet, let the children play in the
playground, have an ice-creme, pancake or even full dinner together.


Traditionally (in IE & UK) women weren't allowed in pubs, and not 
supposed to drink pints. Ergo there's still an overhang of that.



- Why is a toilet without gender tag considered men-only ? Where I
live public toilets have separate sections for women and men, that is
why we do not bother to map gender.


Apparently in some countries that's not true! At SotM 2016 Srravya C 
explained that this isn't the case in India.


--
Rory

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?

[Philippe Verdy]

JOSM est rapide et ne bloque pas du tout si tu l'utilises avec Java en 64
-bits qui ne souffre pas de la limite de taille mémoire trop basse par
défaut.
JOSM documente comment augmenter la taille de la VM par défaut (même en 32
bits seulement on peut le faire même si on ne peut pas aller aussi haut
qu'en 64-bits).

Personnellement je n'utilise plus du tout l'installation de Java en 32 bits
(qui ne servait encore que pour les "plugins" et "applets" au sein d'un
navigateur 32-bits) et qui n'est même pas installé du tout, je n'utilise
que la version 64 bits, donc sans aucune intégration aux navigateurs 32
bits. Je ne comprend pas d'ailleurs pourquoi le site Java continue de
proposer par défaut la version 32-bits même sur un OS 64 bits: la double
installation est totalement inutile, et cela fait longtemps que Java aurait
du prendre en charge l'intégration des anciennes applets dans un navigateur
32 bits via un proxy où la VM Java ne serait installée qu'en 64 bits. Ce
qui est parfaitement possible (et même documenté dans le JDK sur la façon
de le faire!)

L'ennui c'est le composant d'intégration au navigateur qui n'a jamais
évolué et continue d'utiliser la vielle méthode NPAPI héritée de Netscape
et que même Firefox a abandonné (après déjà IE, Edge, Chrome, Safari,
Opera...), et qu'il aurait du être réécrit depuis longtemps pour profiter
des évolutions (y compris des améliorations de sécurité au sein des
navigateurs comme au sein de la VM Java elle-même: NAPI est totalement
obsolète, remplacé sur tous les principaux navigateurs).


Le 19 mars 2018 à 10:13, Rpnpif  a écrit :

> Le 17 mars 2018, deuzeffe a écrit :
>
> > Mmmhhh ??? On peut utiliser QGis pour mettre à jour JOSM qui mettra à
> > jour osm ? C'est plus intéressant que JOSM seul ?
>
> Oui puisque chez moi JOSM est trop lent et bloque avec autant de
> données.
>
> Bien sûr, le but est de sélectionner une petite zone (communale au
> plus).
> Mais je vais peut-être me rabattre sur la couche rapatriée sur Id.
>
> Merci.
>
> --
> Alain Rpnpif
>
> ___
> 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: [Diversity-talk] Who Maps The World

[Rory McCann]

Hi all,

There's a lot to be said about those in power choosing the map. This
article points out a lot of the good work HOT is doing to get women
involved, but this article has the same false sound bites about how OSM
works.


That gender imbalance provokes serious debate among mapmakers—one of
the more contentious battles in OSM history was in 2011, when editors
 rejected an appeal to tag “childcare” at all. (It’s since been
added.)


 This again! That didn't happen. Pretty sure that isn't the "more
contentious battles in OSM history".

The article links to QueeringTheMap.com, which I hadn't heard of yet,
but it looks like conservatives spammed it off the internet. 

There's a long history of forcing the human rights of marginalized
people to be put up for popular vote, and it's harmful to marginalized
people, so we shouldn't be telling people that OSM requires a democratic
vote.

--
Rory

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?

[Rpnpif]

Le 17 mars 2018, deuzeffe a écrit :

> Mmmhhh ??? On peut utiliser QGis pour mettre à jour JOSM qui mettra à 
> jour osm ? C'est plus intéressant que JOSM seul ?

Oui puisque chez moi JOSM est trop lent et bloque avec autant de
données.

Bien sûr, le but est de sélectionner une petite zone (communale au
plus).
Mais je vais peut-être me rabattre sur la couche rapatriée sur Id.

Merci.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] De BD Carthage à BD TOPO Hydrographie ?

[Rpnpif]

Le 17 mars 2018, marc marc a écrit :

> Bonjour,
> 
> Le 17. 03. 18 à 10:19, Rpnpif a écrit :
> > (trop grosse pour JOSM).  
> 
> Que veux-tu dire ?
> C'est une couche, tu ne télécharges que la zone que tu vois.
> c'est donc ni + lourd ni - lourd que d'afficher une couche satellite.

Bonjour,
En réalité je l'ai pris sur le site IGN pour la France entière.

> 
> > Est-elle utilisable avec Id ?  
> 
> Oui. menu de droite, un peu + bas tu as "calques : BD Carthage"

OK. Merci.

-- 
Alain Rpnpif

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

Re: [Talk-es] Importación CDAU

[Javier Sánchez Portero]

No. No tenía ni idea. Lo haré, gracias por la sugerencia.

El 19 de marzo de 2018, 8:01, Paloma Maria Lopez Lara <
paloma.lopez.l...@juntadeandalucia.es> escribió:

> buen dia Javier
>
> Respecto a la importación de CDAU ¿Has hablado con Moisés de GeoInquietos
> Sevilla?
>
> saludos!
>
> paloma
>
>
>
>
>
> El 18/03/2018 a las 13:01, talk-es-requ...@openstreetmap.org escribió:
>
>> Envíe los mensajes para la lista Talk-es a
>> talk-es@openstreetmap.org
>>
>> Para subscribirse o anular su subscripción a través de la WEB
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>> O por correo electrónico, enviando un mensaje con el texto "help" en
>> el asunto (subject) o en el cuerpo a:
>> talk-es-requ...@openstreetmap.org
>>
>> Puede contactar con el responsable de la lista escribiendo a:
>> talk-es-ow...@openstreetmap.org
>>
>> Si responde a algún contenido de este mensaje, por favor, edite la
>> linea del asunto (subject) para que el texto sea mas especifico que:
>> "Re: Contents of Talk-es digest...". Además, por favor, incluya en la
>> respuesta sólo aquellas partes del mensaje a las que está
>> respondiendo.
>>
>>
>> Asuntos del día:
>>
>> 1. Re: [Catastro] Geolocalización (Javier Sánchez Portero)
>> 2. Re: Importación CDAU (Javier Sánchez Portero)
>> 3. semanarioOSM Nº 399 2018-03-06-2018-03-12 (weeklyteam)
>>
>>
>> --
>>
>> Message: 1
>> Date: Sat, 17 Mar 2018 19:47:49 +
>> From: Javier Sánchez Portero 
>> To: Discusión en Español de OpenStreetMap
>> 
>> Subject: Re: [Talk-es] [Catastro] Geolocalización
>> Message-ID:
>> > ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hola
>>
>> Los geolocalizadores buscarán la entidad de población más cercana. En este
>> ejemplo está cogiendo el pueblo de Vera de Erques, dentro del municipio de
>> Guía de Isora
>>
>> https://nominatim.openstreetmap.org/details.php?place_id=48822488
>>
>> El nodo no tiene ninguna etiqueta de ayuda que lo vincule.
>>
>> https://www.openstreetmap.org/node/3639979162
>>
>> En este otro caso está cogiendo un barrio dentro del pueblo, La Somada (
>> https://www.openstreetmap.org/node/1701806636)
>>
>> https://nominatim.openstreetmap.org/details.php?place_id=48371961
>>
>> Pero no es el correcto, debería ser La Era (
>> https://www.openstreetmap.org/node/1701806613)
>>
>> Tienes razón en que poner una etiqueta que dirija hacia la localidad a la
>> que pertenece la dirección ayudaría. Lo que yo digo es que debería ser
>> suficiente con una etiqueta hacia la localidad de menor nivel. La relación
>> de niveles debería sacarse de las etiquetas existentes en los nodos de
>> cada
>> núcleo de población.
>>
>> Saludos
>>
>> El 16 de marzo de 2018, 18:41, Jesús Gómez Fernández <
>> jesus.gomez.f...@gmail.com> escribió:
>>
>> No me refería tanto a las etiquetas que definen límites administrativos
>>> como municipio, provincia, y entidades geográficas superiores.
>>> El problema lo encuentro en edificios fuera del núcleo urbano (es decir,
>>> fuera del way etiquetado como landuse=residential). Si no se indica a qué
>>> población pertenecen no veo forma (o a mí se me escapa) de que el
>>> geolocalizador la conozca.
>>> Con respecto al ejemplo que puse, indudablemente es un error que existan
>>> dos edificios con la misma dirección y quizás no fuera el más idóneo pero
>>> era para mostrar cómo el polígono que define el área residencial está
>>> bastante alejado del edificio y aún así este pertenece a esa localidad.
>>> Corregiré también la duplicación de elementos place.
>>>
>>> Un saludo
>>> Jesús Gómez
>>>
>>>
>>> El 12 de marzo de 2018, 12:48, dcapillae  escribió:
>>>
>>> Opino igual que Javier, no debemos mapear para las herramientas, sino
 para
 mejorar el rendimiento de la base de datos. Teniendo los límites
 administrativos bien definidos (boundary=*), cualquier información
 adicional
 sobre dónde se encuentran ciertas características resulta redundante e
 innecesaria.



 -
 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
>>>
>>>
>>>  próxima parte 
>> Se ha borrado un adjunto en formato HTML...
>> URL: > s/20180317/83337a05/attachment-0001.html>
>>
>> --
>>
>> Message: 2
>> Date: Sat, 17 Mar 2018 19:50:24 +
>> 

[Talk-es] Importación CDAU

[Paloma Maria Lopez Lara]

buen dia Javier

Respecto a la importación de CDAU ¿Has hablado con Moisés de 
GeoInquietos Sevilla?


saludos!

paloma





El 18/03/2018 a las 13:01, talk-es-requ...@openstreetmap.org escribió:

Envíe los mensajes para la lista Talk-es a
talk-es@openstreetmap.org

Para subscribirse o anular su subscripción a través de la WEB
https://lists.openstreetmap.org/listinfo/talk-es

O por correo electrónico, enviando un mensaje con el texto "help" en
el asunto (subject) o en el cuerpo a:
talk-es-requ...@openstreetmap.org

Puede contactar con el responsable de la lista escribiendo a:
talk-es-ow...@openstreetmap.org

Si responde a algún contenido de este mensaje, por favor, edite la
linea del asunto (subject) para que el texto sea mas especifico que:
"Re: Contents of Talk-es digest...". Además, por favor, incluya en la
respuesta sólo aquellas partes del mensaje a las que está
respondiendo.


Asuntos del día:

1. Re: [Catastro] Geolocalización (Javier Sánchez Portero)
2. Re: Importación CDAU (Javier Sánchez Portero)
3. semanarioOSM Nº 399 2018-03-06-2018-03-12 (weeklyteam)


--

Message: 1
Date: Sat, 17 Mar 2018 19:47:49 +
From: Javier Sánchez Portero 
To: Discusión en Español de OpenStreetMap

Subject: Re: [Talk-es] [Catastro] Geolocalización
Message-ID:

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

Hola

Los geolocalizadores buscarán la entidad de población más cercana. En este
ejemplo está cogiendo el pueblo de Vera de Erques, dentro del municipio de
Guía de Isora

https://nominatim.openstreetmap.org/details.php?place_id=48822488

El nodo no tiene ninguna etiqueta de ayuda que lo vincule.

https://www.openstreetmap.org/node/3639979162

En este otro caso está cogiendo un barrio dentro del pueblo, La Somada (
https://www.openstreetmap.org/node/1701806636)

https://nominatim.openstreetmap.org/details.php?place_id=48371961

Pero no es el correcto, debería ser La Era (
https://www.openstreetmap.org/node/1701806613)

Tienes razón en que poner una etiqueta que dirija hacia la localidad a la
que pertenece la dirección ayudaría. Lo que yo digo es que debería ser
suficiente con una etiqueta hacia la localidad de menor nivel. La relación
de niveles debería sacarse de las etiquetas existentes en los nodos de cada
núcleo de población.

Saludos

El 16 de marzo de 2018, 18:41, Jesús Gómez Fernández <
jesus.gomez.f...@gmail.com> escribió:


No me refería tanto a las etiquetas que definen límites administrativos
como municipio, provincia, y entidades geográficas superiores.
El problema lo encuentro en edificios fuera del núcleo urbano (es decir,
fuera del way etiquetado como landuse=residential). Si no se indica a qué
población pertenecen no veo forma (o a mí se me escapa) de que el
geolocalizador la conozca.
Con respecto al ejemplo que puse, indudablemente es un error que existan
dos edificios con la misma dirección y quizás no fuera el más idóneo pero
era para mostrar cómo el polígono que define el área residencial está
bastante alejado del edificio y aún así este pertenece a esa localidad.
Corregiré también la duplicación de elementos place.

Un saludo
Jesús Gómez


El 12 de marzo de 2018, 12:48, dcapillae  escribió:


Opino igual que Javier, no debemos mapear para las herramientas, sino para
mejorar el rendimiento de la base de datos. Teniendo los límites
administrativos bien definidos (boundary=*), cualquier información
adicional
sobre dónde se encuentran ciertas características resulta redundante e
innecesaria.



-
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



 próxima parte 
Se ha borrado un adjunto en formato HTML...
URL: 


--

Message: 2
Date: Sat, 17 Mar 2018 19:50:24 +
From: Javier Sánchez Portero 
To: "Discusi, n en Espa, ol de OpenStreetMap"

Subject: Re: [Talk-es] Importación CDAU
Message-ID:

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

Ya está traducida a inglés la propuesta

https://wiki.openstreetmap.org/wiki/Import_CDAU

El 28 de febrero de 2018, 22:34, Javier Sánchez Portero <
javiers...@gmail.com> escribió:


Hola

Creo que con unas pocas modificaciones el programa para importar Catastro
puede descargar los datos 

Re: [Talk-lv] jāņasēta mūs izaicina

[Rihards]

On 2018.03.18. 21:39, pec...@gmail.com wrote:
> Es nākamnedēļ došos uz Ogri, nostaigāšu gar tiltiem.

Super, paldies. Lai sanāk jauka pastaiga :)

> Pēteris.
> 
> 2018. gada 18. marts 14:03 Rihards  > rakstīja:
> 
> varbūt kādam sanāk apciemot ogres tiltus - ideāli būtu svaigas mapillary
> bildes :)
> 
> https://twitter.com/kartes_lv/status/968457959243206656
> 
> --
>  Rihards
> 
> ___
> Talk-lv mailing list
> Talk-lv@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-lv
> 
> -- 
> mortigi tempo
> Pēteris Krišjānis-- 
 Rihards

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

Re: [Diversity-talk] Who Maps The World

[Charlotte Wolter]

Paul,

A kindergarten is a school, not a child-care center. They 
are two fundamentally different things. Also, child-care centers 
serve a range of ages, not just 5-year-olds. I, too, tried to find a 
real child-care tag a few months ago. There is none, and 
"kindergarten" doesn't cut it.


Charlotte


At 04:40 PM 3/15/2018, you wrote:

Content-type: multipart/alternative;
 boundary=E05DE6A0022FF7C5FF3B1F54
Content-language: en-US

On 3/14/2018 6:47 PM, alyssa wright wrote:

Hi all,

City Lab article below on gender disparity in OSM. I actually think 
things have evolved and are more nuanced then ever before. 
Wondering if I am being naive.


Yes. Part of the thesis of the article is based around the claims of 
what gets mapped. The claims in the article do not reflect reality.


OSM has more child-care centers (amenity=kindergarten) mapped than 
sports arenas or sports arenas, the examples from the article. I 
couldn't figure out what tags Levine was talking about for strip clubs.


For healthcare, the claims are vaguer, but as a general rule, 
"primary" information like something being a doctor's office, 
clinic, or other healthcare facility gets mapped faster than 
"subtag" information like what type of specialty the doctor's has. 
This is normal - when I'm out mapping, noting where there's a 
doctor's or clinic is more important than what type it is. You see 
the same in other subtags.


 Looking at what healthcare facilities is tagged with that 
additional information, and ignoring "general", the five most 
popular are "Obstetrics and gynaecology", "Ophthalmology", "General 
(internal) medicine", "Paediatrics", and "Trauma and orthopaedic 
surgery". (UK terms).


The gender percentages are interesting, and if accurate, put a much 
lower value on percentage of mapping that HOT does than I've seen in 
the past. I suspect there are some problems with different sources 
of numbers, and the numbers cited not being accurate.


[1]: 
https://taginfo.openstreetmap.org/keys/healthcare%3Aspeciality#values



___ Diversity-talk 
mailing list Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct 
Contact the mods (private): diversity-talk-ow...@openstreetmap.org


Charlotte Wolter
927 18th Street Suite A
Santa Monica, California
90403
+1-310-597-4040
Mobile: 310-663-3699
techl...@techlady.com
Skype: thetechlady

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk] Unify Mapping and wiki accounts? -- WAS: Vote cheating?

[Andrew Hain]

You could say that every existing edit is by an “old” account and new ones 
going forwards are by main site accounts which occasionally have the same name. 
Perhaps you could link some of the old wiki accounts to the OSM user names 
where they are known to be the same person.


--

Andrew



From: Nicolás Alvarez 
Sent: 19 March 2018 04:51
To: osm-talk
Subject: Re: [OSM-talk] Unify Mapping and wiki accounts? -- WAS: Vote cheating?

El 18 mar. 2018, a la(s) 20:50, François Lacombe 
> escribió:


2018-03-19 0:38 GMT+01:00 Michael Kugelmann 
>:
Am 18.03.2018 um 20:45 schrieb Richard:
fundamental decission - maybe osm and osm-wiki accounts should be the same?
This had been independent in the very old history. And now you have conflicts 
=> will not work w/o huge effort...
There had been requests like this 5 years ago or so w/o success. Not because 
nobody wanted to implement but because it was not possible.

This is a great idea.

Can you sum up what are the technical issues which make it not possible please ?

Suppose user 'John' currently has a wiki account called 'JohnW'. That's 
currently possible, since the accounts are independent. What do you do if you 
unify the accounts? Does OSM user John get a new wiki account called John? What 
if that wiki account already exists? Or does he have to manually connect the 
OSM and Wiki accounts?

What if an OSM user called JohnW also exists (but never used the wiki yet), 
what wiki account do you create for him if the name JohnW is already taken on 
the wiki?

Users can rename OSM accounts. What happens if a user has accounts on both OSM 
and the wiki, with the same name, but changes his user name to "Javiersanp"? 
That name isn't taken in OSM, but it's taken in the wiki. Does the rename get 
rejected?

There are different OSM users "nicolas" and "Nicolas". Wiki usernames always 
have a uppercase first letter, so if accounts get unified, those two different 
OSM users can't get different wiki accounts. There is a similar problem with 
the wiki considering " " (space) and "_" (underscore) equivalent, while OSM 
doesn't.


I would love it if wiki accounts and OSM accounts were unified, but that would 
need to be done since the start. Now it seems too hard to do it; too many 
conflicts with existing accounts.

--
Nicolás
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-es] Hemos hablado del proyecto del importar el catastro en el podcast de Birras

[Javier Sánchez Portero]

¡Gracias por la difusión!

El dom., 18 mar. 2018 22:33, Miguel de Dios Matias 
escribió:

> Buenas.
>
> En el último podcast de Birras en la sección de noticias sobre el
> proyecto de importación del catastro que esta tan vivo en la comunidad
> española de OSM.
>
>
> https://birrasybits.wordpress.com/2018/03/18/byb-2x08-los-testigos-de-godot/
>
> Si hay alguna errata o queréis aportar algo mas de información, no lo
> dudéis y hacemos un especial sobre OSM.
>
> Saludos.
> ___
> 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] Rendering "cliff"

[demon.box]

Io sò e confermo che questo scherzo lo fanno i gps Garmin ma in MapSource e
BaseCamp esce correttamente.

--enrico




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

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

hebdoOSM Nº 399 2018-03-06-2018-03-12sch[A

[weeklyteam]

Bonjour,

Le résumé hebdomadaire n° 399 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10131/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca