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 

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

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

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

[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

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

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-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr