[OSM-talk-fr] utilisation d'osrm pour signaler un itinéraire alternatif

[didier2020]

j'ai réussi a caser un itinéraire alternatif en utilisant osrm :
http://www.sytadin.fr/sys/alert_reseau.jsp.html#379962

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

Re: [OSM-talk-fr] Calendrier des rencontres

[Christian Quest]

Il n'y a pas de formulaire actuellement.

Il me semble que j'ai paramétré Drupal pour permettre de créer un contenu
(un évènement dans ce cas) et il suffit qu'un administrateur du site le
valide pour publication. Indique-moi quel est ton compte sur
openstreetmap.fr


Le 18 septembre 2014 22:26, Gwen  a écrit :

> bonjour
>
> suite à la mise en ligne de la carte des rencontres des groupes locaux
> (Merci Frédéric !), je me demandais quelle était la procédure pour
> annoncer un événement dans le calendrier dispo sur opentreetmap.fr.
>
> A défaut de formulaire de saisie, à qui peut-on envoyer les infos ?
>
> d'avance merci
>
> Gwen
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] utilisation d'osrm pour signaler un itinéraire alternatif

[Christian Quest]

\o/ !!

Doucement on grignote, on grignote ;)


2014-09-19 13:47 GMT+02:00 :

> j'ai réussi a caser un itinéraire alternatif en utilisant osrm :
> http://www.sytadin.fr/sys/alert_reseau.jsp.html#379962
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

[OSM-talk-fr] pendant qu'on parle d'OSRM

[Pierre-Yves Berrard]

Quelqu'un d'autre a-t-il remarqué qu'OSRM semble limiter la vitesse à
90km/h sur autoroute ?
osrm.at/9vt
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] pendant qu'on parle d'OSRM

[Frédéric Rodrigo]

C'est bien ce qu'il y a dans la configuration :
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua

speed_profile = {
["motorway"] = 90,
["motorway_link"] = 75,
["trunk"] = 85,
["trunk_link"] = 70,
["primary"] = 65,
["primary_link"] = 60,
["secondary"] = 55,
["secondary_link"] = 50,
["tertiary"] = 40,
["tertiary_link"] = 30,
["unclassified"] = 25,
["residential"] = 25,
["living_street"] = 10,
["service"] = 15,
-- ["track"] = 5,
["ferry"] = 5,
["shuttle_train"] = 10,
["default"] = 10

Le 19/09/2014 14:33, Pierre-Yves Berrard a écrit :

Quelqu'un d'autre a-t-il remarqué qu'OSRM semble limiter la vitesse à
90km/h sur autoroute ?
osrm.at/9vt 


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




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

[OSM-talk-fr] Re : Re: pendant qu'on parle d'OSRM

[didier2020]

un peu plus bas dans le code .lua
"""
 if way.speed == -1 then
local highway_speed = speed_profile[highway]
local max_speed = parse_maxspeed( way.tags:Find("maxspeed") )
-- Set the avg speed on the way if it is accessible by road class
if highway_speed then
if max_speed > highway_speed then
 way.speed = max_speed
"""

a prioris, il tient compte des vitesses saisie sur les ways 
puis y applique un coef de 0.8 (truc pour simuler la vitesse reélle et non pas 
la vitesse max)

Bref, les temps de trajets en Ile de France sont totalement faux aux heures de 
pointes 


- Mail d'origine -
De: Frédéric Rodrigo 
À: Discussions sur OSM en français 
Envoyé: Fri, 19 Sep 2014 14:39:08 +0200 (CEST)
Objet: Re: [OSM-talk-fr] pendant qu'on parle d'OSRM

C'est bien ce qu'il y a dans la configuration :
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua

speed_profile = {
["motorway"] = 90,
["motorway_link"] = 75,
["trunk"] = 85,
["trunk_link"] = 70,
["primary"] = 65,
["primary_link"] = 60,
["secondary"] = 55,
["secondary_link"] = 50,
["tertiary"] = 40,
["tertiary_link"] = 30,
["unclassified"] = 25,
["residential"] = 25,
["living_street"] = 10,
["service"] = 15,
-- ["track"] = 5,
["ferry"] = 5,
["shuttle_train"] = 10,
["default"] = 10

Le 19/09/2014 14:33, Pierre-Yves Berrard a écrit :
> Quelqu'un d'autre a-t-il remarqué qu'OSRM semble limiter la vitesse à
> 90km/h sur autoroute ?
> osrm.at/9vt 
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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


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

Re: [OSM-talk-fr] pendant qu'on parle d'OSRM

[Pierre-Yves Berrard]

Ok, merci pour vos réponses.

PY

Le 19 septembre 2014 15:25,  a écrit :

> un peu plus bas dans le code .lua
> """
>  if way.speed == -1 then
> local highway_speed = speed_profile[highway]
> local max_speed = parse_maxspeed( way.tags:Find("maxspeed") )
> -- Set the avg speed on the way if it is accessible by road class
> if highway_speed then
> if max_speed > highway_speed then
>  way.speed = max_speed
> """
>
> a prioris, il tient compte des vitesses saisie sur les ways
> puis y applique un coef de 0.8 (truc pour simuler la vitesse reélle et non
> pas la vitesse max)
>
> Bref, les temps de trajets en Ile de France sont totalement faux aux
> heures de pointes
>
>
> - Mail d'origine -
> De: Frédéric Rodrigo 
> À: Discussions sur OSM en français 
> Envoyé: Fri, 19 Sep 2014 14:39:08 +0200 (CEST)
> Objet: Re: [OSM-talk-fr] pendant qu'on parle d'OSRM
>
> C'est bien ce qu'il y a dans la configuration :
> https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua
>
> speed_profile = {
> ["motorway"] = 90,
> ["motorway_link"] = 75,
> ["trunk"] = 85,
> ["trunk_link"] = 70,
> ["primary"] = 65,
> ["primary_link"] = 60,
> ["secondary"] = 55,
> ["secondary_link"] = 50,
> ["tertiary"] = 40,
> ["tertiary_link"] = 30,
> ["unclassified"] = 25,
> ["residential"] = 25,
> ["living_street"] = 10,
> ["service"] = 15,
> -- ["track"] = 5,
> ["ferry"] = 5,
> ["shuttle_train"] = 10,
> ["default"] = 10
>
> Le 19/09/2014 14:33, Pierre-Yves Berrard a écrit :
> > Quelqu'un d'autre a-t-il remarqué qu'OSRM semble limiter la vitesse à
> > 90km/h sur autoroute ?
> > osrm.at/9vt 
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Hyperactivité d'un utilisateur

[Pieren]

2014-09-18 21:37 GMT+02:00  :

> pour les revert:
> si on veut faire un revert de plusieurs changesets, on commence par faire le 
> revert du plus récent

Attention, même en faisant le revert dans l'ordre inverse, on ne
retrouvera pas les données antécédentes sans conflits. En effet, si le
vandale a créé deux versions d'un élément (par ex, v1 -> v2 puis v2 ->
v3), le premier revert crée une nouvelle version en revenant à T-1 (v3
-> v4 avec les attributs de v2). Mais quand on tente d'annuler le
deuxième changeset (le premier chronologiquement), JOSM va avoir un
conflit puisque la version de l'élément a évolué depuis (le changeset
parle d'un v1 -> v2 qui n'est plus v2 mais v4 maintenant).
Il faudrait en fait que le reverter prenne en charge des groupes de
changesets au lieu de les faire un par un. Bien sûr, ça n'éviterait
pas les problèmes si un deuxième contributeur interfère dans
l'historique des changements mais ça faciliterait quand même les
retours en arrière lorsque quelqu'un modifie plusieurs fois un objet.

Pieren

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

Re: [OSM-talk-fr] Hyperactivité d'un utilisateur

[didier2020]

+1 pour l'explication

Le vendredi 19 septembre 2014 à 17:46 +0200, Pieren a écrit : 
> 2014-09-18 21:37 GMT+02:00  :
> 
> > pour les revert:
> > si on veut faire un revert de plusieurs changesets, on commence par faire 
> > le revert du plus récent
> 
> Attention, même en faisant le revert dans l'ordre inverse, on ne
> retrouvera pas les données antécédentes sans conflits. En effet, si le
> vandale a créé deux versions d'un élément (par ex, v1 -> v2 puis v2 ->
> v3), le premier revert crée une nouvelle version en revenant à T-1 (v3
> -> v4 avec les attributs de v2). Mais quand on tente d'annuler le
> deuxième changeset (le premier chronologiquement), JOSM va avoir un
> conflit puisque la version de l'élément a évolué depuis (le changeset
> parle d'un v1 -> v2 qui n'est plus v2 mais v4 maintenant).
> Il faudrait en fait que le reverter prenne en charge des groupes de
> changesets au lieu de les faire un par un. Bien sûr, ça n'éviterait
> pas les problèmes si un deuxième contributeur interfère dans
> l'historique des changements mais ça faciliterait quand même les
> retours en arrière lorsque quelqu'un modifie plusieurs fois un objet.
> 
> Pieren
> 
> ___
> 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] BANO/FANTOIR : deux orthographes pour une voie

[Jérôme Seigneuret]

Bonjour,
Il me semble plus pertinent de mettre une balise   alt_name
 sur la rue en question
et de faire une vérification par le code du soft en cas de non
correspondance cette balise si cela n'est pas déjà le cas.

Il y a une priorité sur les noms à prendre en compte il me semble:


   1. name
   2. official_name
   3. int_name
   4. nat_name
   5. name:fr
   6. reg_name
   7. loc_name
   8. old_name
   9. alt_name [] (boucle avec séparateur ; si plusieurs nom)
   10. short_name

C'est plus propre et plus compréhensible surtout si dernière on laisse une
note en expliquant que c'est pour faire une correspondance de nom entre
BANO et FANTOIR.

Vous en pensez quoi?


Le 17 septembre 2014 12:11, rainerU  a écrit :

> Am 17.09.2014 11:51, schrieb Christian Quest:
>
>  Il faudrait pour ces cas que les 2 codes FANTOIR soient rattachés à la
>> voie en question.
>>
>> On ne s'est pas encore mis d'accord sur la façon de procéder... donc
>> laisse en l'état et si c'est toujours visible sur le rendu BANO et bien
>> cela ne gêne pas ;)
>>
>
> Ok. Ça me gêne juste un peu pour celui qui passera après moi et doit
> refaire les mêmes vérifications pour savoir si c'est "rue" ou "avenue".
>
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Prix des carburants ?

[Jean-Baptiste Holcroft]

Bonjour, pensez-vous qu'on puisse croiser ce jeu de données avec osm pour
améliorer les tags, les corriger et/ou détecter les stations manquantes/en
trop ?

http://www.data.gouv.fr/fr/dataset/prix-des-carburants-en-france
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] On parle d'OSM-FR et de BANO dans L'Usine Digitale...

[Brice MALLET]

Bravo aux initiateurs et contributeurs de BANO dont le travail a permis 
d'aboutir à cette reconnaissance lors de la conférence de presse du 
17/09 sur la stratégie numérique de l'Etat :


/Par ailleurs, l'Etat a confirmé le soutien apporté cet été à un projet 
de base nationale d'adresses ouvertes initiée par OpenStreetMap France 
et qui devrait intéresser l'ensemble des organisations ou les 
gestionnaires de données localisées, à commencer par les collectivités 
territoriales. La constitution collaborative d'une base d'adresses 
nationale réalisée "à partir des meilleures sources disponibles et 
libres" comprendrait déjà environ 15 millions d'adresses./

(…)

tiré de :
http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250267719845&jid=1250267721082 





Le 17/09/14 21:02, Christian Quest a écrit :
C'est ici: 
http://www.usine-digitale.fr/article/e-gouvernement-la-france-s-engage-a-100-de-services-en-ligne-dans-un-an.N285088 



Pour info, il y a eu une communication de Thierry Mandon sur le 
numérique lors du conseil des ministres de ce mercredi. BANO y a été 
évoqué et fait surtout partie du dossier de presse.


Aujourd'hui a aussi été publié le décret concernant le poste 
d'Administrateur Général des Données (Chief Data Officer en anglais). 
C'est un décret très novateur pour les données en France et pour 
l'opendata. Il n'y a plus qu'à attendre la nomination de celui ou 
celle qui va tenir pour la première fois ce rôle.


Aujourd'hui aussi... nouvelle version du site http://data.gouv.fr/ qui 
intègre (parmi un grand nombre de nouveautés) désormais des minicarte 
OSM (fond mapquest) pour localiser la couverture géographique des jeux 
de données.


Grosse journée au boulot ;)

--
Christian Quest - OpenStreetMap France


___
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] BANO/FANTOIR : deux orthographes pour une voie

[Vincent de Château-Thierry]

Bonsoir,

Le 19/09/2014 20:12, Jérôme Seigneuret a écrit :


Il me semble plus pertinent de mettre une balise alt_name
 sur la rue en
question et de faire une vérification par le code du soft en cas de non
correspondance cette balise si cela n'est pas déjà le cas.

Il y a une priorité sur les noms à prendre en compte il me semble:

 1. name
 2. official_name
 3. int_name
 4. nat_name
 5. name:fr
 6. reg_name
 7. loc_name
 8. old_name
 9. alt_name [] (boucle avec séparateur ; si plusieurs nom)
10. short_name

C'est plus propre et plus compréhensible surtout si dernière on laisse
une note en expliquant que c'est pour faire une correspondance de nom
entre BANO et FANTOIR.

Vous en pensez quoi?


Actuellement les traitements de rapprochement des noms ne considèrent 
que le tag name=*, il y a donc une marge de progression de ce côté là. 
Mais à l'inverse, ajouter un alt_name uniquement sur la foi de Fantoir, 
pour moi c'est se tromper d'objectif. Le alt_name devrait être issu 
d'une observation de terrain. Si rien ne le justifie sur place, je ne 
rajoute pas de alt_name. C'est dit ici régulièrement, le fait de laisser 
du rouge sur le calque BANO n'est pas problématique.
Après, laisser une note sur des objets OSM pour éviter une perte de 
temps par d'autres contributeurs, ça pourquoi pas.


vincent

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

Re: [OSM-talk-fr] On parle d'OSM-FR et de BANO dans L'Usine Digitale...

[Vincent de Château-Thierry]

Le 19/09/2014 21:58, Brice MALLET a écrit :

Bravo aux initiateurs et contributeurs de BANO dont le travail a permis
d'aboutir à cette reconnaissance lors de la conférence de presse du
17/09 sur la stratégie numérique de l'Etat :

/Par ailleurs, l'Etat a confirmé le soutien apporté cet été à un projet
de base nationale d'adresses ouvertes initiée par OpenStreetMap France
et qui devrait intéresser l'ensemble des organisations ou les
gestionnaires de données localisées, à commencer par les collectivités
territoriales. La constitution collaborative d'une base d'adresses
nationale réalisée "à partir des meilleures sources disponibles et
libres" comprendrait déjà environ 15 millions d'adresses./
(…)

tiré de :
http://www.localtis.info/cs/ContentServer?pagename=Localtis/LOCActu/ArticleActualite&cid=1250267719845&jid=1250267721082


Z'ai cru voir un RatZillaS :
http://data.blog.lemonde.fr/2014/09/19/henri-verdier-chief-data-officer-de-la-france/

;)

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

Re: [OSM-talk-fr] Prix des carburants ?

[Frédéric Rodrigo]

Oui bien sûr, j'ai prévu de l'ajouter à Osmose. On peut même avoir le 
type de carburant.

Je suis preneur de toute aides.

Frédéric.


Le 19/09/2014 20:58, Jean-Baptiste Holcroft a écrit :

Bonjour, pensez-vous qu'on puisse croiser ce jeu de données avec osm
pour améliorer les tags, les corriger et/ou détecter les stations
manquantes/en trop ?

http://www.data.gouv.fr/fr/dataset/prix-des-carburants-en-france



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

Re: [OSM-talk-fr] BANO/FANTOIR : deux orthographes pour une voie

[Jérôme Seigneuret]

Ok j'en prends bonne note!

Dans ce cas pouvons nous formaliser une méthode pour que les contributeurs
puissent faire une requête sur la base du note ou d'un fixme?

Quelle serait la règle à appliquer?

Le 19 septembre 2014 22:14, Vincent de Château-Thierry  a
écrit :

> Bonsoir,
>
> Le 19/09/2014 20:12, Jérôme Seigneuret a écrit :
>
>  Il me semble plus pertinent de mettre une balise alt_name
>>  sur la rue en
>> question et de faire une vérification par le code du soft en cas de non
>> correspondance cette balise si cela n'est pas déjà le cas.
>>
>> Il y a une priorité sur les noms à prendre en compte il me semble:
>>
>>  1. name
>>  2. official_name
>>  3. int_name
>>  4. nat_name
>>  5. name:fr
>>  6. reg_name
>>  7. loc_name
>>  8. old_name
>>  9. alt_name [] (boucle avec séparateur ; si plusieurs nom)
>> 10. short_name
>>
>> C'est plus propre et plus compréhensible surtout si dernière on laisse
>> une note en expliquant que c'est pour faire une correspondance de nom
>> entre BANO et FANTOIR.
>>
>> Vous en pensez quoi?
>>
>
> Actuellement les traitements de rapprochement des noms ne considèrent que
> le tag name=*, il y a donc une marge de progression de ce côté là. Mais à
> l'inverse, ajouter un alt_name uniquement sur la foi de Fantoir, pour moi
> c'est se tromper d'objectif. Le alt_name devrait être issu d'une
> observation de terrain. Si rien ne le justifie sur place, je ne rajoute pas
> de alt_name. C'est dit ici régulièrement, le fait de laisser du rouge sur
> le calque BANO n'est pas problématique.
> Après, laisser une note sur des objets OSM pour éviter une perte de temps
> par d'autres contributeurs, ça pourquoi pas.
>
> vincent
>
>
> ___
> 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] Hyperactivité d'un utilisateur

[Philippe Verdy]

Le 19 septembre 2014 17:46, Pieren  a écrit :

> 2014-09-18 21:37 GMT+02:00  :
>
> > pour les revert:
> > si on veut faire un revert de plusieurs changesets, on commence par
> faire le revert du plus récent
>
> Attention, même en faisant le revert dans l'ordre inverse, on ne
> retrouvera pas les données antécédentes sans conflits. En effet, si le
> vandale a créé deux versions d'un élément (par ex, v1 -> v2 puis v2 ->
> v3), le premier revert crée une nouvelle version en revenant à T-1 (v3
> -> v4 avec les attributs de v2). Mais quand on tente d'annuler le
> deuxième changeset (le premier chronologiquement), JOSM va avoir un
> conflit puisque la version de l'élément a évolué depuis (le changeset
> parle d'un v1 -> v2 qui n'est plus v2 mais v4 maintenant).
> Il faudrait en fait que le reverter prenne en charge des groupes de
> changesets au lieu de les faire un par un.
>
> Pour compléter; c'est plus compliqué que ça car un même changeset peut
contenir plusieurs versions successives d'un objet.

Et lors d'une résolution de conflits entre deux changesets, ils vont chacun
créer des versions sur des objets séparés mais entremêlés (et assez souvent
pour les résoudre on est amené à modifier un même objet une seconde fois
dans le changeset). L'autre cas c'est le changeset resté ouvert pour
plusieurs modifs en séries.

La granularité n'est donc pas le changeset mais uniquement objet par objet
avec des version séparées; réparties dans un nombre variable de changesets.
Noter aussi qu'il peut y avoir pluseurs changesets ouverts simultanément
par le même utilisateur et quel leurs modifs peuvent aussi s'entre mêler
(amais avec des conflits de versions possibles entre eux et à résoudre pour
chacun).

Bref, faire un revert d'un ou plusieurs changesets c'est aussi compliqué!
Il faut lister toutes les versions de chaque objet modifié dans le(s)
changet(s) et repérer les versions initiales. Si on veut éviter de
compliquer avec des listes d'objets compliquées, on a intéret à faire les
reverts non pas en groupant selon leur changset d'origine mais selon leur
dépendances (objets liés : noeuds référencés par ways ou relations, ways et
relations référencées par relations) et travailler sur ces jeux assez
petits pour pouvoir traiter ces petits groupes séparément : ceci fait on
peut alors les déversionner étape par étape en parcourant les versions en
sens inverse
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr