Re: [OSM-talk-fr] josm : utiliser une image aérienne

[Hélène PETIT]

Merci à Panier, Thibaud et Jean-Marc : ça a très bien marché, cool, 
tranquille ; ce josm, quand même, qu'est ce qu'il est chouette.


à plus,
Hélène

Le 16/02/2017 à 16:55, Jean-Marc Liotier a écrit :

On Thu, 16 Feb 2017 09:04:26 +0100
Hélène PETIT  wrote:


je n'ai pas trouvé comment mettre dans un calque de josm une image
jpeg, non géoréférencée ; il s'agit du plan d'un tout petit
lotissement pas encore au cadastre, mais en construction presque
finie.


Si tu as le moindre doute sur la rectitude de l'image (par exemple s'il
s'agit d'une photo aérienne pas tout à fait verticale ou d'un plan pris
en photo pas tout à fait en face) tu peux la traiter avec
http://mapwarper.net qui te fournira en sortie non seulement une image
rectifiée mais aussi un WMS de cette dernière, ce qui est plus léger à
manipuler par JOSM qu'une image locale en un seul bloc.

___
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] Tarif des péages

[Philippe Verdy]

Je pense aussi que c'est le genre d'appli qu'il faudrait demander aux
sociétés d'autoroute qui utiliseront leurs propres bases tarifaires, se les
échangeront pour les besoin d'interconnexion, et tiendront compte aussi des
différentes options tarifaires (pas que la classe des véhicules, mais aussi
les modulations horaires/calendaires, ou les formules d'abonnement, tarifs
de gros pour les professionnels, ou de paiement échelonné s'il y en a), les
sections rendues gratuites par décision administrative temporaire ou
sections temporairement fermées passant par le réseau public ouvert), et
qui indiqueront aussi des temps de parcours, des restrictions
supplémentaires de vitesse (alertes pollution). Ces tarifs varient
régulièrement (certains changement étant imposés ou refusés par
l'administration concessionnaire).

C'est impossible à mettre sur une carte (cependant on peut toujours leur
proposer nos fonds de cartes et leur proposer et les aider à monter les
serveurs de tuiles éventuels. Dans les faits ces sociétés développeront
leurs surcouches vectorielles (leur schéma de réseau est plus "simple" que
notre fond global), mais nos fonds de carte et données communes peuvent
aussi les aider à promouvoir des parcours avec des sites à visiter autour
de leur réseau (ces sociétés peuvent aussi faire des partenariats locaux
avec d'autres sociétés ou collectivités dans le domaine du tourisme, le
sport, la culture, le développement économique local, et les
interconnexions avec d'autres moyens de transport). par cette collaboration
on pourrait avoir en échange des données ouvertes supplémentaires. Par
exemple les équipements de sécurité, la signalisation fixe, les aires de
service et des listes de leurs exploitants, des horaires d'ouverture,
l'accessiblité, les services divers aux usagers: toilettes, douches, aires
de camping, télésurveillance, éclairage, et même données de travaux en
cours ou prévus (réfection, extensions ou fermetures) avec des indications
sur les nouveaux tracés à prévoir, la capacité des voies, les dangers
divers.

Avec nous elles pourraient avoir des points de contacts et d'échange avec
les autres producteurs de données géolocalisées, et elles pourraient aussi
participer aux travaux de développement d'outils ouverts, ou améliorer
l'harmonisation des normes et de nos règles de balisage (d'autant plus
qu'elles peuvent manquer d'éléments de comparaison au plan international et
que d'autres pays, même hors d'Europe, ont d'autres besoins et d'autres
règles et usages.

On peut aussi leur montrer comment des administrations françaises (avec qui
elles travaillent déjà, comme les collectivités et EPCI, les agences de
gestion de parcs naturels, la sécurité civile ou encore la gendarmerie et
les agences en charge des fréquences) utilisent déjà OSM (en plus de l'IGN
qui ne couvre pas tout ou peut avoir un service cher et pas nécessairement
très approprié pour l'information des usagers, avec un ROI plus faible) au
moins pour tout ce qu'elles ne produisent pas déjà elles-mêmes et qu'elles
ne sont pas en mesure de maintenir ailleurs et où les données ouvertes par
d'autres sociétés peuvent être insuffisantes : OSM permet de collecter des
données de tout le monde, à égalité et de façon neutre, et collecte aussi
des tas de données ou corrections que les exploitants eux-mêmes ont omis de
maintenir, OSM peut être pour elles un outil de recherche, au moins à titre
de comparaison, qui peut aussi les aider à maintenir leur référentiel et
trouver des zones qui demanderaient des relevés actualisés par elles sur
place).

On ne leur demande pas d'abandonner leur modèle et on ne leur interdit pas
non plus d'exploiter d'autres sources (ou même de les acheter ou les louer
à des fournisseurs commerciaux comme Google), juste de faire preuve
d'ouverture. Elles auront de toute façon aussi à produire des données
réglementaires qu'OSM ne peut pas leur garantir (et continueront à utiliser
les services du cadastre, de l'IGN ou des géomètres et experts publics ou
privés, notamment en géologie et en météorologie qu'OSM ne gère pas du
tout, pas plus non plus que la gestion des coûts et la logistique, ni leurs
plans de travail au jour le jour ni la gestion de leur investissement ou
les relations avec leurs actionnaires et investisseurs, bien que la
collaboration en données ouvertes est aussi un outil de communication, où
OSM et les donénes ouvertes peuvent être performants pour leur image et
générer aussi des économies d'échelle par plus de coopérations et l'usage
de schémas de données mieux harmonisés entre producteurs).

D'ailleurs on devrait les inviter à se joindre aux rencontres publiques
OSM, comme State of the Map, ou autres réunions FOSS, et faire part de
leurs propres remarques. Elles peuvent aussi devenir contributeurs OSM
directs, en laissant certains de leurs collaborateurs s'inscrire et les
autorisant à intégrer leur données (avec une licence claire qu'elles
peuvent aussi référencer sur un catalogue OpenData national ou européen

Re: [OSM-talk-fr] base VLA (vitesse limite autorisé)

[Florian_G]

Hello,

Le 19/02/2017 à 21:21, Eric SIBERT a écrit :
> http://product.itoworld.com/map/124?lon=5.73304=45.17881=13_sidebar=share_menu
Très bien ce site , mais il ne tient compte que des maxspeed explicites et non 
des maxspeed implicites, notamment ceux définis pour la France (je ne me 
souviens plus du terme exact).

++

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

Re: [OSM-talk-fr] Tarif des péages

[Yannick]

Le 19/02/2017 à 20:01, Rogelio Canedo a écrit :

Bonjour à tous,
Je voulais discuter avec vous de la possibilité d'intégrer les tarifs
des péages à OSM.
Après avoir regardé, il ne semble pas y avoir de modèle pour le moment.
Pensez-vous qu'un modèle basé sur des relations soit possible?

Exemple de relation:
-> type: toll_fee
-> class1: 
-> class2: 
-> class3: 
-> class4: 
-> class5: 
-> name: 

1- prise de ticket à une barrière de péage -> paiement à la barrière de
sortie
Ajouter deux membres:
liste des barrières de péage d'entrée avec le rôle *from*
liste des barrières de péage de sortie avec le rôle *to*

Exemple sur A1 entre Pont Sainte Maxence et Compiègne Ouest:
Tag
*type*: toll_fee
*class1*: 0.7
*class2*: 1.0
*class3*: 1.2
*class4*: 1.6
*class5*: 0.3
*name*: Pont Sainte Maxence / Compiègne Ouest
Membres
*from*: Gare de Péage de Pont Sainte Maxence
*to*: Gare de Péage de Compiègne Ouest

2 - pas de prise de ticket, on paye un droit de passage
On trouve ce type de péage pour les ponts, les tunnels...
Ici, il n'est pas nécessaire de renseigner le membre to

Exemple sur le pont de l'île de ré
*type*: toll_fee
*class1*: 8
*class2*: 8
*class3*: 18
*class4*: 40
*class5*: 3
*name*: Pont de l'île de ré
Membres
*from*: Gare de Péage de l'île de ré

3 - le tarif change en fonction la date
C'est le cas, du pont de l'île de ré qui a une période de tarification
estivale.
le tunnel du duplex en idf qui a des tarifs différents en fonction de la
période de la journée.

Exemple:
*type*: toll_fee
*class1*: 16
*class2*: 16
*class3*: 18
*class4*: 40
*class5*: 3
*name*: Pont de l'île de ré - Tarif été
*fee*: <*opening_hours>*
Membres
*from*: Gare de Péage de l'île de ré

Exemple:
*type*: toll_fee
*class1*: 8
*class2*: 8
*class3*: 18
*class4*: 40
*class5*: 3
*name*: Pont de l'île de ré - Tarif hiver
*fee*: <*opening_hours>*
Membres
*from*: Gare de Péage de l'île de ré

Il doit y avoir autant de relation que de combinaisons possible.

Est-ce que ce modèle vous semble viable ou existe-t-il d'autres uses cases?

Merci

Rogelio Canedo


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



Bonsoir,

Je pense que là nous sommes dans une problématique à long terme 
ingérable. En effet il faudrait que la source soit les sociétés 
d'autoroutes elles mêmes!
Pourquoi c'est simple la multiplicité des couples entrée-sortie. Par 
contre des péages sur des ouvrages d'art est possible et en soit 
pertinent car aisément modifiable.


Sachant, par exemple, que de Vintimille à Lille je peux faire tout mon 
trajet par autoroute, il devient vite clair que le nombre de solutions 
de sorties est très élevées donc autant de tarifs possibles mais avec 
plusieurs sociétés différentes donc plusieurs tarifs différents. Le 
tarif serait fixe partout au km je ne dis pas impossible bien au 
contraire mais là c'est impossible car cela implique toutes une séries 
d'informations ingérables par un humain. Les ratés sont d'avance certains.


C'est mon avis

Amitiés

--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris http://www.ancestris.org

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

Re: [OSM-talk-fr] base VLA (vitesse limite autorisé)

[Eric SIBERT]

y'aura du lourd à prévoir comme projet pour aller modifier les ways


http://product.itoworld.com/map/124?lon=5.73304=45.17881=13_sidebar=share_menu

 ;-)

Eric


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

[OSM-talk-fr] Tarif des péages

[Rogelio Canedo]

Bonjour à tous,
Je voulais discuter avec vous de la possibilité d'intégrer les tarifs des
péages à OSM.
Après avoir regardé, il ne semble pas y avoir de modèle pour le moment.
Pensez-vous qu'un modèle basé sur des relations soit possible?

Exemple de relation:
-> type: toll_fee
-> class1: 
-> class2: 
-> class3: 
-> class4: 
-> class5: 
-> name: 

1- prise de ticket à une barrière de péage -> paiement à la barrière de
sortie
Ajouter deux membres:
liste des barrières de péage d'entrée avec le rôle *from*
liste des barrières de péage de sortie avec le rôle *to*

Exemple sur A1 entre Pont Sainte Maxence et Compiègne Ouest:
Tag
*type*: toll_fee
*class1*: 0.7
*class2*: 1.0
*class3*: 1.2
*class4*: 1.6
*class5*: 0.3
*name*: Pont Sainte Maxence / Compiègne Ouest
Membres
*from*: Gare de Péage de Pont Sainte Maxence
*to*: Gare de Péage de Compiègne Ouest

2 - pas de prise de ticket, on paye un droit de passage
On trouve ce type de péage pour les ponts, les tunnels...
Ici, il n'est pas nécessaire de renseigner le membre to

Exemple sur le pont de l'île de ré
*type*: toll_fee
*class1*: 8
*class2*: 8
*class3*: 18
*class4*: 40
*class5*: 3
*name*: Pont de l'île de ré
Membres
*from*: Gare de Péage de l'île de ré

3 - le tarif change en fonction la date
C'est le cas, du pont de l'île de ré qui a une période de tarification
estivale.
le tunnel du duplex en idf qui a des tarifs différents en fonction de la
période de la journée.

Exemple:
*type*: toll_fee
*class1*: 16
*class2*: 16
*class3*: 18
*class4*: 40
*class5*: 3
*name*: Pont de l'île de ré - Tarif été
*fee*: <*opening_hours>*
Membres
*from*: Gare de Péage de l'île de ré

Exemple:
*type*: toll_fee
*class1*: 8
*class2*: 8
*class3*: 18
*class4*: 40
*class5*: 3
*name*: Pont de l'île de ré - Tarif hiver
*fee*: <*opening_hours>*
Membres
*from*: Gare de Péage de l'île de ré

Il doit y avoir autant de relation que de combinaisons possible.

Est-ce que ce modèle vous semble viable ou existe-t-il d'autres uses cases?

Merci

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

hebdoOSM Nº 343 07/02/2017-13/02/2017

[weeklyteam]

Bonjour,

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

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

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

Re: [OSM-talk-fr] HebdoOSM

[David Crochet]

Bonjour


Le 19/02/2017 à 14:57, Philippe Verdy a écrit :
mais là je critiquait surtout ceux qui traduisent à l'aveugle et ne 
font aucune relecture et ne se demandent même pas pourquoi ça ne veut 
rien dire au final en français 


Et au lieu de critiquer, tu aides ou pas ?

Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] base VLA (vitesse limite autorisé)

[Philippe Verdy]

Je crois qu'avant de généraliser les mesures cohercitives et de
surveillance automatisée, il serait bon de penser à déployer en France une
signalisation améliorée, notamment radiodiffusée. Ce sera de toute façon
indispensable pour renforcer la sureté des systèmes de conduite
automatique, tant la signalisation publique est dégradée (et pas toujours
bien visible) et constitue de vrais pièges à contraventions.

Ca passe par des réflexion sur les normes actuelles, et l'adoption de
nouvelles normes (si possibles européennes et basées sur des technologies
ouvertes, permettant de multiplier les offres d'équipement des véhicules ou
outils de navigation et d'en baisser le prix, ou l'intégrer aussi sur les
solutions mobiles). Mais ça passe aussi par l'équipement des collectivités
et leur formation (et des marchés publics suffisamment ouverts pour éviter
des dérives budgétaires, et de vraies enquêtes publiques pour éviter le
coûteux désastre de la taxe poids lourds avec une société obtenant un
contrat abusif dans les compensations de rupture). Cela ne devrait pas se
faire à l'initiative seule d'un ministère imposant ça d'en haut, ou d'une
obscure agence parapublique n'ayant en fait aucun moyen réel de contrôle,
même pendant la réalisation des lots du marché.

Les normes doivent donc être ouvertes (pas comme celles de l'ISO et même
bon nombre de normes dites européennes qui ne font que retranscrire les
normes ISO ou viennent même les imposer là où ce n'est même pas nécessaire
en cassant les offres alternatives libres, et les marchés passés sans
exclusivité sur des périodes longues: tant pis si au départ ça signifie peu
d'offres (ROI plus fiable), mais les coûts réels de mise en oeuvre ne
cessent de baisser si on a des normes ouvertes, permettant même des
fournitures plus locales: c'est l'autorité de controle de mise en oeuvre
des normes qui doit être le plus solidifiée (tout en la gardant ouverte sur
ses décisions et protégée légalement aussi contre l'action de ceux qui
abuseront ou voudront contredire les normes pour imposer les leurs: le
changement des normes doit rester une affaire publique et pas une
initiative commerciale privée couverte par des tas de clauses de propriété
exclusive).

L'information sur l'état de la signalisation en France est franchement
mauvaise (et trop souvent au détriment des usagers qu'on accuse facilement
de faute ou négligence avec des outils de controle automatique et des
décisions lourdes qui ne sont même pas réellement contestables). En
conséquence, elle induit une défiance des usagers contre elle et
l'improvisation voire des comportements dangereux et prises de risques sans
que nécessairement les conducteurs en aient conscience (hors du domaine de
l'alcool au volant qui est le seul faisant l'objet de campagnes, les
limites de vitesse ne s'imposent que par l'expérience de tas
d'automobilistes qui se sont fait piéger et ont payé sans contester, parce
que la contestation est encore plus onéreuse, le conducteur devant payer
immédiatement des amendes majorées qui ne seront jamais restituées même si
elles sont payées très tôt voire immédiatement sans possibilité de
contester!). Certaines collectivités ont aussi tendance à abuser de la
signalisation à tout bout de champ: avec beaucoup trop d'éléments plus ou
moins contradictoires ou impossibles à respecter si ils sont trop denses:
elle distrait le conducteur qui ne regarde plus la route devant lui, omet
les distances de sécurité (puisque la puissance publique l'omet aussi dans
sa signalisation). On observe ça et là des limites de vitesse qui changent
à moins de 50 mètres d'écart, et noyées par d'autres éléments de
signalisation pas nécessairement obligatoires (une signalisation devenue
particulièrement compliquée selon en plus les types d'usagers).

Quand aurons nous une signalisation radiodiffusée (microcellules, émetteurs
sous la chaussée, bandes magnétiques...) ? Et comment la mettre en place
sans une très bonne cartographie publique, réactive aussi aux changements ?


Le 19 février 2017 à 14:31, willemijns  a écrit :

> Hello,
>
> vous en avez sûrement parlé...
>
> http://www.radars-auto.com/actualite/actu-radars-general/
> la-securite-va-analyser-les-donnees-de-trafic-1202
>
> "Tout d'abord, la DSCR souhaite construire une base de données fiable des
> vitesses limites autorisées (VLA)."
>
> DSCR =
> http://www.securite-routiere.gouv.fr/la-securite-routiere/
> qui-sommes-nous/la-delegation-a-la-securite-et-a-la-circulation-routieres
>
> y'aura du lourd à prévoir comme projet pour aller modifier les ways
>
>
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/base-VLA-vitesse-limite-autorise-tp5891611.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing 

Re: [OSM-talk-fr] HebdoOSM

[Philippe Verdy]

Le 19 février 2017 à 14:19,  a écrit :

> Bonjour,
> Je ne parle pas un mot d'anglais et suis très content des pages traduites
> tant bien que mal par des benevoles.
> Malgré ce handicap, il m'arrive souvent de traduire les pages du wiki avec
> Goo... + le dictionnaire + mon bon sens !
>

Go**le fait en général du bon travail, mais il se plante souvent sur les
constructions ambiguës de l'anglais quand il y a des juxtapositions de
termes (parfois sans distinction entre noms, adjectifs et verbes) et sans
aucune préposition pour préciser leurs relations, ou des phrases courtes
avec très peu de contexte : ici le contexte est celui d'OSM et
l'information géographique avec son jargon particulier.

Traduire par exemple les titres des "news feed" est assez désastreux: aucun
robot n'y parvient correctement. Malheureusement le WeeklyOSM utilise des
titres très courts, ce qui ne facilite pas toujours la résolution de sens.

Normalement on devrait aller voir les liens proposés, mais là je critiquait
surtout ceux qui traduisent à l'aveugle et ne font aucune relecture et ne
se demandent même pas pourquoi ça ne veut rien dire au final en français
(probablement parce que ceux qui le font ne comprennent rien au français
non plus, et ne comprennent pas plus la langue originale quand ce n'était
pas l'anglais, ou ont des notions très superficielles de l'anglais en plus,
ce qui ne leur permet pas d'aller réellement chercher les sens voulus,
puisque les liens proposés n'aideront pas toujours).

Traduire normalement nécessite de comprendre les deux langues (et dans le
milieu professionnel, on demande d'avoir une excellente notion de la langue
cible). On ne demande pas ici de maitriser parfaitement l'orthographe (tout
le monde même natif fait des fautes courantes, même les écrivains réputés,
ce n'est pas un drame) ou la grammaire tant qu'on ne crée pas de
contre-sens ou ne copie pas directement les termes issus de l'anglais voire
glannés d'autres langues même pas dans l'original, parce que le robot a
indexé des contenus en se trompant sur l'identification automatisée de la
langue dans son corpus), et en cas de difficulté de demander aux auteurs
originaux une précision sur le sens voulu (donc d'avoir un moyen de le
faire directement dans l'outil de traduction, et que ceux qui y participent
soient informés de ces demandes et réagissent: la durée d'activation de ces
WeeklyOSM est courte, et cela ne nécessite pas de devoir s'investir dessus
non plus pendant des mois ou des années). Il y a des choses qui sautent aux
yeux des lecteurs natifs, mais c'est trop tard et même le plus souvent il
n'y a plus moyen de corriger quoi que ce soit, et ça reste tel quel dans
les archives.

Mais il faudrait aussi moins de précipitation pour publier les traductions
(parce qu'après ça, c'est trop tard, elles ne seront pas diffusées à
nouveau, surtout pas en mailing list).

Conséquence de ça: personne ne les relit ensuite, et WeeklyOSM manque
d'outils pour rechercher les sujets liés dans ses actus et les pointer
correctement en complément sur toutes ses pages: l'utilisation de certains
"hashtags"/mot-clés d'indexation/catégories pourraient aider, tout en
facilitant aussi les relectures ultérieures, en même les nouvelles entrées
à traduire (avec une mémoire de traduction mais pas seulement car le
contenu est nécessairement modifié, c'est surtout utile pour retrouver le
lexique lié à un sujet, et tenter de l'harmoniser pour encore améliorer le
"match" dans les outils de recherche).

Certains sites d'actualités le font très bien (la plupart d'ailleurs ont la
forme d'un blogue, beaucoup trop cependant, même les sites les plus
"réputés", abusent des pavés publicitaires sans aucun rapport ou carrément
trompeurs ou des escroqueries en ligne qu'ils tolèrent car ils ne filtrent
pas du tout le contenu venant du réseau d'annonceurs qui pourtant nous
pistent sans arrêt. avant même de nous présenter des liens de navigation
interne (ou carrément de les mélanger aux contenus tiers non contrôlés,
quand ils ne bloquent pas carrément l'accès au contenu quand les filtres
antihameçonnage/antisuivis sont activés: Il ne faudrait pas en venir là, la
pub ça va tant que c'est clairement identifié et ne compromet pas la
navigation de base par un abus du placement sur toutes les zones "vides" de
la page voire la totalité du fond de page, ou des tas de boutons trompeurs
sur l'action qu'on souhaitait faire, telle que tenter d'imiter le bouton
"télécharger" du site pour aller ailleurs charger autre chose: ces
pratiques pullullent dans le monde du "freeware", rarement libres, et qui
font payer n'importe quoi).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] base VLA (vitesse limite autorisé)

[willemijns]

Hello,

vous en avez sûrement parlé... 

http://www.radars-auto.com/actualite/actu-radars-general/la-securite-va-analyser-les-donnees-de-trafic-1202

"Tout d'abord, la DSCR souhaite construire une base de données fiable des
vitesses limites autorisées (VLA)."

DSCR =
http://www.securite-routiere.gouv.fr/la-securite-routiere/qui-sommes-nous/la-delegation-a-la-securite-et-a-la-circulation-routieres

y'aura du lourd à prévoir comme projet pour aller modifier les ways





--
View this message in context: 
http://gis.19327.n8.nabble.com/base-VLA-vitesse-limite-autorise-tp5891611.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] HebdoOSM

[gnrc]

Bonjour, 
Je ne parle pas un mot d'anglais et suis très content des pages traduites tant 
bien que mal par des benevoles. 
Malgré ce handicap, il m'arrive souvent de traduire les pages du wiki avec 
Goo... + le dictionnaire + mon bon sens ! 
Si ceux qui parlent assez bien l'anglais pouvaient s'investir pour ceux qui ne 
le parlent pas, ce serait super. 
Merci à tous 

gnrc69 - chaque goutte fait l’océan (du libre). 

- Mail original -

De: "JB"  
À: "verdy p" , "Discussions sur OSM en français" 
 
Envoyé: Samedi 18 Février 2017 21:59:33 
Objet: Re: [OSM-talk-fr] HebdoOSM 

Bon ben comme ça, on a un non-lecteur non-traducteur qui n'est pas d'accord 
avec les autres. Il serait non-au-courant, ça arrangerait juste tout le monde. 
C'était mon mauvais esprit du soir, bon week-end, 
JB. 

Le 18/02/2017 à 21:10, Philippe Verdy a écrit : 





Le 18 février 2017 à 15:47, Julien Coupey < jul...@coupey.fr > a écrit : 


Comme ça a été dit, il vaut mieux une version française limitée que pas de 
version du tout. 




Pas d'accord quand ça consiste juste à copier-coller directement le contenu 
d'une traduction automatique SANS la relire et la comprendre. N'improte qui 
fait ça directement avec son navigateur web et les outils divers (avec en plus 
la possibilité de choisir le robot traducteur, ce qu'on perd totalement ici). 

Bref que ceux qui veulent traduire le fassent, mais il faut au minimum 
comprendre ce qu'on lit dans la langue source (l'anglais au minimum, parfois 
comparer à la cible des liens qui ne sont pas toujours en anglais et pour 
lesquels il n'y a pas toujours de traduction anglaise disponible non plus) ET 
comprendre ce qui est écrit en français (pour corriger les contre-sens 
complets). 

C'est la même chose sur la traduction de tous les wikis (OSM ou Wikimedia) ou 
sur tous les projets de traduction (même s'ils incluent une mémoire de 
traduction et eux aussi proposent des robots traducteurs): l'utilisation 
automatique de robots (Google translate) pour insérer ces traductions 
automatique sans les relire est bannie. La relecture intelligente est une étape 
indispensable. Je ne vois pas pourquoi ce ne serait pas non plus le cas pour 
WeeklyOSM, que ces fausses traductions déservent plus le projet qu'elles ne le 
servent : quand un lecteur utilise *lui-même* un robot dans son navigateur il 
sait à quoi s'attendre et sait que la traduction automatique peut être erronée 
et à ne pas prendre au pied de la lettre. 

Et c'est encore plus vrai pour WeeklyOSM quand la source originale n'est en 
fait même pas l'anglais (souvent l'allemand, l'espagnol ou le russe), et où la 
version anglais proposée comme source est en fait une traduction approchante 
qui peut déjà contenir des tas de fautes de sens ou de grammaire non corrigées 
(surtout celles venant en fait du russe et de l'espagnol dont les locuteurs 
maîtrisent souvent plus mal l'anglais que les germanophones...) ce qui "perd" 
encore plus les traducteurs automatiques partant de cette traduction anglaise 
approximative. 

D'ailleur WeeklyOSM se base encore en proposant toujours l'anglais comme 
source, sans nécessairement montrer les autres langues originales (qui peuvent 
pourtant servir à lever des ambiguités, utiles quand un détecte des non-sens 
pour savoir ce quu voulait être rélelement dit et que les robots parviennent 
encore moins à "comprendre") 

Un bon outil de traductions doit permettre de voir les autres langues et pas 
seulement la source proposée par défaut, et contenir un espace de 
discussion/questions pour interroger les auteurs sur les ambiguités ou 
difficultés de traduction ou compréhension de leur texte. On a ça dans le 
moteur de traduction de MediaWiki, mais rarement dans plein d'autres outils 
qu'on trouve sur le web, qui en plus ne disposent pas non plus de mémoire de 
traduction (qui aide à maintenir un lexique homogène, mais qui n'est pas 
infaillible non plus surtout s'il ne propose qu'une seule version et pas 
d'autres adaptées aux autres usages réels). 

Les moteurs de traduction (pour produire et publier ces traductions, ou en 
ligne intégrés dans le navigateur du client) proposent divers outils, c'est 
dommage d'en priver les lecteurs en ne leur offrant plus qu'une version 
pseudo-traduite automatiquement et non relue, juste parce que quelqu'un a fait 
quelques clics rapides dans le moteur pour faire croire qu'il a produit très 
vite 100% d'une traduction. Quand on ne comprend pas ce qu'on lit, on ne 
traduit pas à la place des autres. 


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




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

___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] Réparer un carnage

[Eric SIBERT]

Le 18/02/2017 à 14:19, osm.sanspourr...@spamgourmet.com a écrit :

https://wiki.openstreetmap.org/wiki/FR:Madagascar_tagging_guidelines#R.C3.A9seau_routier

Pour expliquer aux contributeurs comment taguer les routes à Madagascar.


Oui, je suis au courant. C'est moi qui ai rédigé la version initiale de 
cette page.


Mais de toute façon, mettre des morceaux de primary au milieu de nulle 
part, ce n'est pas spécifique à Madagascar.


Entre temps, j'ai contacté le DWG qui m'a répondu (7 février) qu'ils 
allaient regarder ça.


Pour le deuxième contributeur qui avait répondu, son dernier message 
était (3 février):

<
Quand vous me dites" Qui est ce 'on'? " vous pensez que je me suis
levé un bon matin néant rien à faire j'ai décidé de dégrader une Carte
existante. Je pense que je vous ai fait savoir que ce sont des
informations qui nous ont été remis. C'est pas la première fois que je
travail sur OSM cela fait plusieurs années aujourd'hui; chaque fois on
nous remet des informations que nous essayons de suivre; ce n'est pas
de manière délibérer que ces informations ont été mise. Maintenant si
il y 'a des remarques sur le travail qui a été fait je vous ai bien
signifier le pourquoi? Ce n'est pas effectué une classification qui
peut me causer problème?
>>

Je lui ai répondu que les imports étaient un sujet délicat (avec lien 
vers le wiki) et que la communauté locale était surprise de leur 
démarche (avec lien sur les archives de la liste correspondante).


Pour le contributeur qui proposait de faire un revert, pas de nouvelle 
(ni de revert) depuis le 3 février.


Globalement, j'attends.

Eric

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