Re: [OSM-talk-fr] Hyperactivité d'un utilisateur
Donc on doit prendre le dernier objet du dernier changeset l'importer dans JOSM avec les objet liés et faire les modifications au fur et à mesure des versions (ou successions de versions) des éléments dans ce cas?! Ça va être sacrément long... sachant qu'en plus à chaque sauvegarde, comme le disait @Pieren, Crée une nouvelle version de l'objet... Est ce qu'on pourrait avoir des exemples concrets afin de mieux comprendre les différents problèmes que l'on risque de rencontrer et comment les résoudre? Merci Peut-on aussi considérer un retour à une date donnée si il n'y a pas eu d'autre modification d'utilisateur pendant un certains délais sur un ensemble de relation? Ces histoires de revert c'est vraiment pas simple. Jérôme Le 20 septembre 2014 00:51, Philippe Verdy verd...@wanadoo.fr a écrit : Le 19 septembre 2014 17:46, Pieren pier...@gmail.com a écrit : 2014-09-18 21:37 GMT+02:00 didier2...@free.fr: 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 ___ 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
Le Fri, Sep 19, 2014 at 02:39:08PM +0200, Frédéric Rodrigo
[fred.rodr...@gmail.com] a écrit:
C'est bien ce qu'il y a dans la configuration :
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua
Ce sont bien des km/h et c'est la vitesse moyenne estimée ?
Ou alors c'est une autre unité ?
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 http://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
--
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27
A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent. -- Mahatma Gandhi
___
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...
Beaucoup de couverture presse où l'on parle d'OSM et de BANO ces derniers jours suite à cette série d'évènements liés au numérique. C'est en partie dû à 2 pages au sujet d'OSM et BANO que l'on trouve dans le dossier remis à la presse. Voici le lien vers ce dossier de presse complet: https://owncloud.data.gouv.fr/public.php?service=filest=ae968e423a1de378ca8955dcf55a7892 Un autre article... http://www.lagazettedescommunes.com/270157/letat-entrepreneur-ouvert-nouvel-avatar-du-numerique-au-service-de-la-modernisation/ J'avais aussi été interviewé par The Economist cet été suite à une conférence openaddresses qui avait eu lieu à Londres et l'article est sorti cette semaine: http://www.economist.com/node/21618822/print Le 19 septembre 2014 22:21, Vincent de Château-Thierry osm.v...@free.fr a écrit : 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/ ArticleActualitecid=1250267719845jid=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 -- Christian Quest - OpenStreetMap 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
Ajouter un nom clairement erroné (cas de nos flamands roses) dans un des multiples tags name me semble une mauvaise idée. Laisser du rouge sur le calque BANO ne pose pas de problème, on pourra y revenir plus tard. Comme le dit Vincent, une note permet de ne pas refaire les même recherches (infructueuses) pour tenter de résoudre le problème. Il ne faut pas perdre de vue l'objectif initial: améliorer et compléter les données OSM. Ajouter des infos plus ou moins erronées juste pour dégommer du rouge dans le rendu BANO ne va pas dans ce sens et c'est donc à éviter. Le 19 septembre 2014 22:51, Jérôme Seigneuret jseigneuret-...@yahoo.fr a écrit : 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 osm.v...@free.fr 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 http://wiki.openstreetmap.org/wiki/FR:Key: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 -- Christian Quest - OpenStreetMap 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...
Tant qu'on y est; puisqu'on par le de BANO et des adresses; ce serait bien aussi d'impliquer la partie publique restante de l'administration postale, autrement dit l'ARCEP. L'ARCEP pourtant a des données cartographiques à gérer (avec aussi l'ANF pour l'allocation des fréquences et la couverture, très influencée par la puissance des émissions et par le relief physique ou la densité des constructions, et en liaison aussi avec les opérateurs de réseaux mobiles et fixes et le plan de déploiement numérique national : les collectivités sont intéressées puisqu'elles sont chargées aussi de suivre les engagements des opérateurs en terme de couverture puisque l'Etat a choisi de subventionner les collectivités au lieu de négocier nationalement avec les opérateurs). Bref aller plus loin pour que la Poste transfère ses données à l'ARCEP et que l'ARCEP les coordonne avec la BANO. Que fait l'ARCEP ? S'il lui manque des moyens, le gouvernement doit pouvoir y répondre et au besoin avec des adaptations réglementaires ou législatives (dans le cadre aussi de l'ouverture à la concurrence des services postaux). L'ARCEP aussi n'exploite pas encore beaucoup les possibilités de l'Open Data... Elle publie presque toutes ses cartes encore sur fond Google, sans doute parce que ses tuiles sont fluides et servies rapidement: -- un problème qu'on pourrait régler en utilisant un gros cache dont la mises à jour sera peut-être moins rapide mais permettant de répondre immédiatement à une demande). Le cache de base devrait être capable de fournir toutes les tuiles de la France (et un peu autour) au moins jusqu'au niveau de zoom 15 (même si pour les numéros d'adresse il faut monter au niveau 17 et alors utiliser un cache dynamique LIFO mais là il faut aussi des serveurs pour calculer les tuiles hors cache à la demande) et la carte du monde entier pour tous les niveaux jusquà 12, 13 en Europe. -- On aimerait bien voir des moyens publics permettant de mettre en place un gros serveur de tuiles OSM pour tous les services publics français, et même au delà (en débordant un peu des frontières, et en acceptant des utlisations commerciales pour réaliser d'autres cartes sur un fond de base commun en version light). Avec de la capacité en bande passante, et en calcul. Le projet BANO devrait justifier la mise en place d'une plateforme nationale commune à grande échelle pour le rendu français (même si pour ce fond commun on doit en éliminer toutes les marques commerciales de commerces et ne laisser peut-être que des symboles ou les sociétés qui gèrent des concessions publiques). On parlait aussi ces jours-ci beaucoup des professions réglementées ou contingentées. Là aussi il y a des interlocuteurs et ce sont leurs ordres, conseils supérieurs ou régulateurs actuels qui eux aussi pourraient participer dans le cadre des missions publiques dont ils assurent la charge. Le 20 septembre 2014 10:04, Christian Quest cqu...@openstreetmap.fr a écrit : Beaucoup de couverture presse où l'on parle d'OSM et de BANO ces derniers jours suite à cette série d'évènements liés au numérique. C'est en partie dû à 2 pages au sujet d'OSM et BANO que l'on trouve dans le dossier remis à la presse. Voici le lien vers ce dossier de presse complet: https://owncloud.data.gouv.fr/public.php?service=filest=ae968e423a1de378ca8955dcf55a7892 Un autre article... http://www.lagazettedescommunes.com/270157/letat-entrepreneur-ouvert-nouvel-avatar-du-numerique-au-service-de-la-modernisation/ J'avais aussi été interviewé par The Economist cet été suite à une conférence openaddresses qui avait eu lieu à Londres et l'article est sorti cette semaine: http://www.economist.com/node/21618822/print Le 19 septembre 2014 22:21, Vincent de Château-Thierry osm.v...@free.fr a écrit : 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/ ArticleActualitecid=1250267719845jid=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 -- Christian Quest - OpenStreetMap France
[OSM-talk-fr] Re : Re: pendant qu'on parle d'OSRM
les vitesses prises en comptes sont en Km/h
- les vitesses par défaut par type de voies sont celles qu'a montré frederic
- si un way a un tag maxspeed en miles/h,
if string.match(source, mph) or string.match(source, mp/h) then
n = (n*1609)/1000;
end
c'est converti en km/h
- si un way a un tag maxspeed ET que sa valeur est inferieure a la vitesse par
defaut, la vitesse du tag est retenue
if highway_speed then
if max_speed highway_speed then
way.speed = max_speed
-- max_speed = math.huge
else
way.speed = highway_speed
end
=
pour faire simple, on peu faire un lua a sa sauce ... le tout est de
décripter le language;)
( j'ai testé baisse de la vitesse en fonction du cout du peage pour les
sections a peage)
- Mail d'origine -
De: Dominique Rousseau d...@lee-loo.net
À: talk-fr@openstreetmap.org
Envoyé: Sat, 20 Sep 2014 09:54:36 +0200 (CEST)
Objet: Re: [OSM-talk-fr] pendant qu'on parle d'OSRM
Le Fri, Sep 19, 2014 at 02:39:08PM +0200, Frédéric Rodrigo
[fred.rodr...@gmail.com] a écrit:
C'est bien ce qu'il y a dans la configuration :
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua
Ce sont bien des km/h et c'est la vitesse moyenne estimée ?
Ou alors c'est une autre unité ?
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 http://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
--
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27
A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent. -- Mahatma Gandhi
___
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] Re : Re: pendant qu'on parle d'OSRM
La question que je me pose, c'est « est-ce qu'on peut modifier les
paramètres lors d'une requête ? », et « par quel moyen » ?
Il avait été question sur cette liste d'un calcul d'itinéraire par les
bus, aussi, je ne retrouve pas le message.
Le 20/09/2014 11:51, didier2...@free.fr a écrit :
les vitesses prises en comptes sont en Km/h
- les vitesses par défaut par type de voies sont celles qu'a montré frederic
- si un way a un tag maxspeed en miles/h,
if string.match(source, mph) or string.match(source, mp/h) then
n = (n*1609)/1000;
end
c'est converti en km/h
- si un way a un tag maxspeed ET que sa valeur est inferieure a la vitesse
par defaut, la vitesse du tag est retenue
if highway_speed then
if max_speed highway_speed then
way.speed = max_speed
-- max_speed = math.huge
else
way.speed = highway_speed
end
=
pour faire simple, on peu faire un lua a sa sauce ... le tout est de
décripter le language;)
( j'ai testé baisse de la vitesse en fonction du cout du peage pour les
sections a peage)
- Mail d'origine -
De: Dominique Rousseau d...@lee-loo.net
À: talk-fr@openstreetmap.org
Envoyé: Sat, 20 Sep 2014 09:54:36 +0200 (CEST)
Objet: Re: [OSM-talk-fr] pendant qu'on parle d'OSRM
Le Fri, Sep 19, 2014 at 02:39:08PM +0200, Frédéric Rodrigo
[fred.rodr...@gmail.com] a écrit:
C'est bien ce qu'il y a dans la configuration :
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua
Ce sont bien des km/h et c'est la vitesse moyenne estimée ?
Ou alors c'est une autre unité ?
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 http://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] Prix des carburants ?
Salut Frédéric et à tous, Je viens d'en faire un CSV tout neuf ;-) https://www.data.gouv.fr/fr/datasets/stations-services-en-france/ Brice Le 19/09/2014 22:36, Frédéric Rodrigo a écrit : 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 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re: pendant qu'on parle d'OSRM
Le 20/09/2014 14:11, Muselaar a écrit :
La question que je me pose, c'est « est-ce qu'on peut modifier les
paramètres lors d'une requête ? », et « par quel moyen » ?
Il avait été question sur cette liste d'un calcul d'itinéraire par les
bus, aussi, je ne retrouve pas le message.
Non les valeurs sont calculées et stocker en dur dans la base de OSRM.
Ce n'est pas possible de paramétrer le script à chaque requête. La
grande rapidité de calcul de OSRM à un revers.
Pour les bus tu peux regarder
http://navitia.io/
ou
http://www.opentripplanner.org/
Frédéric.
Le 20/09/2014 11:51, didier2...@free.fr a écrit :
les vitesses prises en comptes sont en Km/h
- les vitesses par défaut par type de voies sont celles qu'a montré
frederic
- si un way a un tag maxspeed en miles/h,
if string.match(source, mph) or string.match(source, mp/h) then
n = (n*1609)/1000;
end
c'est converti en km/h
- si un way a un tag maxspeed ET que sa valeur est inferieure a la
vitesse par defaut, la vitesse du tag est retenue
if highway_speed then
if max_speed highway_speed then
way.speed = max_speed
-- max_speed = math.huge
else
way.speed = highway_speed
end
=
pour faire simple, on peu faire un lua a sa sauce ... le tout est
de décripter le language;)
( j'ai testé baisse de la vitesse en fonction du cout du peage pour
les sections a peage)
- Mail d'origine -
De: Dominique Rousseau d...@lee-loo.net
À: talk-fr@openstreetmap.org
Envoyé: Sat, 20 Sep 2014 09:54:36 +0200 (CEST)
Objet: Re: [OSM-talk-fr] pendant qu'on parle d'OSRM
Le Fri, Sep 19, 2014 at 02:39:08PM +0200, Frédéric Rodrigo
[fred.rodr...@gmail.com] a écrit:
C'est bien ce qu'il y a dans la configuration :
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua
Ce sont bien des km/h et c'est la vitesse moyenne estimée ?
Ou alors c'est une autre unité ?
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 http://osrm.at/9vt
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Ajout de POI pas très bien géocodés par une agence de com
Il y a une agence de com [1], qui rajoute des POIs dont la qualité du géocodage me parait discutable (cad équivalente à celui de Google) [2] Les ajouts sont faits un par un, mais 1+1+1+... ça finit par faire un import de masse. Vous en pensez quoi ? [1] https://www.openstreetmap.org/user/SeFaireConnaitre [2] https://www.openstreetmap.org/node/3084157533 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Ajout de POI pas très bien géocodés par une agence de com
Premier problème: la licence liée au géocodage qui est fait. Il y a de fortes chances que ce géocodage passe par un service dont les CGU sont incompatibles avec leur upload vers OSM. - poubelle Deuxième problème: si les positions sont très mauvaises, ça mérite sûrement aussi d'être supprimé. Autant je pense qu'il faut être cool avec des contributions individuelles pas très qualitatives et contacter le contributeur pour le remettre dans le droit chemin, autant avec une entreprise qui est payée pour faire ces contributions la médiocrité n'est pas acceptable. Il faut donc les contacter (ce que je vais faire) et leur faire comprendre que soit ils font du bon boulot et qu'il peuvent continuer à référencer leurs clients, soit il font de l'ajout médiocre et que les contributeurs OSM ne sont pas là pour finir leur travail, que ça se terminera en revert purement et simplement. Je vois que SeFaireconnaitre est en fait la société Ubiflow que j'ai déjà contacté pour des problèmes similaires. Je leur repasse donc une deuxième couche... Le 20 septembre 2014 15:59, Tyndare tynd...@wanadoo.fr a écrit : Il y a une agence de com [1], qui rajoute des POIs dont la qualité du géocodage me parait discutable (cad équivalente à celui de Google) [2] Les ajouts sont faits un par un, mais 1+1+1+... ça finit par faire un import de masse. Vous en pensez quoi ? [1] https://www.openstreetmap.org/user/SeFaireConnaitre [2] https://www.openstreetmap.org/node/3084157533 ___ 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] Ajout de POI pas très bien géocodés par une agence de com
( C'est mon premier message ici, mais je vous lis quotidiennement depuis des années, vous êtes mes héros ) Il est vraiment pas mal celui là https://www.openstreetmap.org/node/3084158033 , Yoopala Rennes situé a Espéraza !! -- View this message in context: http://gis.19327.n5.nabble.com/Ajout-de-POI-pas-tres-bien-geocodes-par-une-agence-de-com-tp5817969p5817983.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] Ajout de POI pas très bien géocodés par une agence de com
Si c'est vraiment n'importe quoi, je pense qu'il ne faut pas hésiter à supprimer. Le 20 septembre 2014 19:25, Rinaldum rinal...@altern.org a écrit : ( C'est mon premier message ici, mais je vous lis quotidiennement depuis des années, vous êtes mes héros ) Il est vraiment pas mal celui là https://www.openstreetmap.org/node/3084158033 , Yoopala Rennes situé a Espéraza !! -- View this message in context: http://gis.19327.n5.nabble.com/Ajout-de-POI-pas-tres-bien-geocodes-par-une-agence-de-com-tp5817969p5817983.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 -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] pont ferroviaire, pont routier, tunnel
@François je pense que cela dépend du corps de métier. On pourrait présenter des cas afin de mieux cartographier cela et ainsi ne pas avoir 10 version d'un tronçon car l'interprétation est trop aisé. Sinon pour compléter l'information: Il y a normalement une base de données appelé Réseau chez SNCF-INFRA (pour y avoir bossé). Il y a une couche avec l'ensemble des ponts ferroviaires et routiers, passage à niveau, tunnel, les lignes avec la tension sur le réseau et pleins d'autre choses qui pourrait être super à intégrer RFF dispose de cette base. A voir si RFF accepte de nous fournir ce référentiel (à la SNCF on appelait ça le Référentiel Géographique Infrastructure ou R.G.I. pour les intimes) Il existe en version light (avec les informations à risque pour la sécurité enlevés) Jérôme Le 18 septembre 2014 00:11, François Lacombe francois.laco...@telecom-bretagne.eu a écrit : Un tunnel pourrait-il correspondre à un passage couvert plus long que large ? Ce qui permettrait de définir une limite entre pont et tunnel/tranchée couverte (tunnel=* vient qualifier le type de passage couvert). C'est ce que le wiki évoque, dans des termes peu clairs. Dans le cas donné en exemple au sud de Tavel, c'est clairement un pont de la ligne TGV qui passe sur la route. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com Le 16 septembre 2014 16:54, HELFER Denis denis.hel...@rff.fr a écrit : *De :* Jérôme Seigneuret [mailto:jseigneuret-...@yahoo.fr] *Envoyé :* mardi 16 septembre 2014 16:39 *À :* Discussions sur OSM en français *Objet :* [OSM-talk-fr] pont ferroviaire, pont routier, tunnel Bonjour, Je viens de rencontrer un problème sur la ligne LGV. http://www.openstreetmap.org/edit#map=18/43.99921/4.73571 Celle-ci est surélevé et je pense que les croisements avec la route sont pour la plupart erronés. En effet la route et cours d'eau sont considérés comme passant en tunnel... Hors c'est complètement faux. Ce sont les tronçons de ligne ferroviaire qui doivent être découpé (a mon avis) pour définir des pont (sauf les buses servant au passage des ruisseaux car c'est encore un autre type d'ouvrage) Il me semble que par définition, dans les ouvrages d'art, un tunnel n'est pas un élément aérien contrairement au pont. Je pense que la précision mérite d'être mise dans le wiki vu le nombre d'erreurs la dessus. Il n’y a pas que les LGV qui sont concernées, mais aussi les autres lignes ferroviaires et autres autoroutes. J’ai déjà (et continuerai à ) dégommé de ces faux tunnels. ___ 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
