Re: [OSM-talk-fr] OSRM n'aime pas les pistes cyclables ?

[Julien Coupey]

> Peut-être qu'OSRM considère la non-séparation des voies vélo / piéton
> pour calculer une moyenne de 8 km/h.

Non, 8 km/h est la vitesse par défaut pour highway=path (cf mon 2e lien 
vers les valeurs du profil). Avec highway=cycleway, on serait à 16 km/h.


On 18/05/2022 17:37, Arnaud Champollion wrote:

Le 18/05/2022 à 10:01, Julien Coupey a écrit :

Quand à savoir d'où vient le choix de la vitesse sur la piste cyclable 
(peut-être sous-estimée ici),


En effet car il n'y a aucune raison qu'on roule moins vite sur la piste 
cyclable que sur la route. C'est même l'inverse.


En tout cas 8km/h c'est quand même très bas, c'est la vitesse d'un 
échauffement de petit footing.


Est-ce qu'OSRM prend en compte aussi les feux rouges et autres 
intersections qui impactent inévitablement la vitesse moyenne sur la 
route ?



 là il faut rentrer dans le détail du profil pour comprendre. Par 
défaut, une piste taggée explicitement en highway=cycleway aura une 
bien plus grande vitesse[2] qu'un highway=path (il semble qu'OSRM ne 
tienne pas spécialement compte du bicycle=designated).


Dans le cas présent c'est une piste mixte vélo / piétons :

higway=path
foot=designated
bicycle=designated

sans séparation

segregated=yes

Peut-être qu'OSRM considère la non-séparation des voies vélo / piéton 
pour calculer une moyenne de 8 km/h.


En effet selon les villes et en cas de très forte affluence aux belles 
heures de la journée, en zone touristique, c'est une vitesse moyenne qui 
peut savoir une certaine réalité.


___
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] OSRM n'aime pas les pistes cyclables ?

[Julien Coupey]

Bonjour

Ce n'est jamais évident de débugger des choix d'itinéraires car ça met 
en jeu le profil de calcul d'itinéraire qui décide l'affectation des 
vitesses et pénalités sur les chemins OSM.


L'avantage d'OSRM (et de l'instance de démo hébergée par FOSSGIS), c'est 
qu'on peut avoir une visualisation du graphe sous-jacent[1] après 
traitement via le profil.


Sur cet exemple, on voit que la piste cyclable est bien « routable » 
mais que la vitesse estimée dessus est à 8 km/h tandis qu'on roule à 15 
km/h sur l'avenue du Maréchal Juin, ce qui explique le choix d'itinéraire.


Quand à savoir d'où vient le choix de la vitesse sur la piste cyclable 
(peut-être sous-estimée ici), là il faut rentrer dans le détail du 
profil pour comprendre. Par défaut, une piste taggée explicitement en 
highway=cycleway aura une bien plus grande vitesse[2] qu'un highway=path 
(il semble qu'OSRM ne tienne pas spécialement compte du bicycle=designated).


Sinon comme outil basé également sur OSRM mais très orienté vélo il y a 
cycle.travel[3] développé par Richard Fairhurst.


[1] http://routing.openstreetmap.de/debug/bike.html#16.73/44.08383/6.22476
[2] 
https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/16453fa5ded78671560dba15e124ea5bac6d52d3/bike.lua#L126-L144

[3] https://cycle.travel/

À +
--
Julien

On 18/05/2022 07:55, Arnaud Champollion wrote:

Bonjour,

Je me demande si c'est OSRM qui n'aime pas les pistes cyclables, ou s'il 
y a quelque-chose qui cloche dans les données sur mon itinéraire.


Trajet vélo avec GraphHopper, 3 km

https://www.openstreetmap.org/directions?engine=graphhopper_bicycle=44.0810%2C6.2204%3B44.1007%2C6.2341#map=14/44.0912/6.2392 



Même trajet avec OSRM, 3.1 km, et la piste cyclable est tout à fait 
ignorée.


https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=44.0810%2C6.2204%3B44.1007%2C6.2341#map=14/44.0909/6.2280 



Je me demande si OSRM n'a pas un paramétrage par défaut qui lui fait 
éviter certains passages s'il rencontre tel ou tel attribut, mais je 
n'arrive pas à voir quoi;


Merci

___
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: [OSRM-talk] New v5.23.0 release

[Julien Coupey]

Thanks a lot Daniel, Denis and Michael for your answers.

Michael, I did not go through the details of your changes in PR #5860, 
but I gave a go at building and installing. I can confirm that the 
dowstream compilation problem reported in #5741 is gone with your changes.


Regards
Julien

On 18/10/2020 07:34, Michael Bell wrote:

I've had a go at reverting the breaking change:
https://github.com/Project-OSRM/osrm-backend/pull/5860
I was able to compile libosrmc against it.

Michael

On Thu, 15 Oct 2020 at 17:14, Denis Chapligin  wrote:


IIRC you had some idea of hiding that change and unbreaking the API by 
templating ResultT type. If you can explain your idea I can probably implement 
it.

чт, 15 окт. 2020 г. в 17:43, Daniel Patterson via OSRM-talk 
:


Dammit, sorry Julien, I'd forgotten about that issue - I'm not using the 
libosrm bindings directly, so this change slipped my mind.

If someone has time to fix the interface, we can release 5.24.0 to address it, 
and mark 5.23.0 as a dud.  The interface change clearly breaks semver rules as 
it's not backward compatible.  The alternative would be to release OSRM 6.0.0, 
but this feels like much too small a change to justify doing that.

While I managed to find time to work through the release process, I do not have 
time to do any significant refactoring work :-/

daniel

On Thu, Oct 15, 2020 at 12:38 AM Julien Coupey  wrote:


Hi Daniel and all

Thanks for your work on this release, and all the various recent
contributions that made it possible. It's great to see a new OSRM
version, first one in a long time!

I'd like to ask for a clarification though, if possible, on the status
of libosrm regarding this new version and possible future ones. There
are a couple of reports about the API breaking changes ([1] and [2]). It
means that projects relying on libosrm v5.* no longer compile with
v5.22, and now v5.23. This is a major problem for downstream users and
maintainers, especially since the OSRM release process has long been
adhering to the semver scheme. I only see two ways out:

1. The new v5.23 release somehow endorses the API change (after all a
fix now would also be a new change from the last two releases). In which
case downstream users will have to fiddle with adjustments based on
libosrm minor version.

2. This is considered as something that must be fixed at some point in
the future. Then no action is required downstream, except stating that
current libosrm versions are no longer compatible until a patch or new
minor version is released.

Knowing which option is the most likely would definitely help.

[1] https://github.com/Project-OSRM/osrm-backend/issues/5548
[2] https://github.com/Project-OSRM/osrm-backend/issues/5741

Regards
Julien

On 14/10/2020 23:14, Daniel Patterson via OSRM-talk wrote:

Hello all,

Well, after a long hiatus, I've finally had time to cut a new
release.  I've bundled up a bunch of the changes that have been
submitted over the last couple of years, and tagged 5.23.0, and cleaned
up the changelog/master branch which had been left dangling in an
unclear state for a while.  Build/publish of the various binaries is
underway and should be complete soon.  Here's what's changed - mostly
bugfixes, but a few small features as well.

- Changes from 5.22.0
  - Build:
- FIXED: pessimistic calls to std::move
[#5560](https://github.com/Project-OSRM/osrm-backend/pull/5561)
  - Features:
- ADDED: new API parameter - `snapping=any|default` to allow
snapping to previously unsnappable edges
[#5361](https://github.com/Project-OSRM/osrm-backend/pull/5361)
- ADDED: keepalive support to the osrm-routed HTTP server
[#5518](https://github.com/Project-OSRM/osrm-backend/pull/5518)
- ADDED: flatbuffers output format support
[#5513](https://github.com/Project-OSRM/osrm-backend/pull/5513)
- ADDED: Global 'skip_waypoints' option
[#5556](https://github.com/Project-OSRM/osrm-backend/pull/5556)
- FIXED: Install the libosrm_guidance library correctly
[#5604](https://github.com/Project-OSRM/osrm-backend/pull/5604)
- FIXED: Http Handler can now deal witch optional whitespace
between header-key and -value
[#5606](https://github.com/Project-OSRM/osrm-backend/issues/5606)
  - Routing:
- CHANGED: allow routing past `barrier=arch`
[#5352](https://github.com/Project-OSRM/osrm-backend/pull/5352)
- CHANGED: default car weight was reduced to 2000 kg.
[#5371](https://github.com/Project-OSRM/osrm-backend/pull/5371)
- CHANGED: default car height was reduced to 2 meters.
[#5389](https://github.com/Project-OSRM/osrm-backend/pull/5389)
- FIXED: treat `bicycle=use_sidepath` as no access on the tagged
way. [#5622](https://github.com/Project-OSRM/osrm-backend/pull/5622)
- FIXED: fix table result when source and destination on same
one-way segment.
[#5828](https://github.com/Project-OSRM/osrm-backend/pull/5828)
- FIXED: fix occasional segfault when

Re: [OSRM-talk] Blocking zones in OSM

[Julien Coupey]

Hi Alex

There is probably no easy approach for this in OSRM, because the whole 
speedup-through-precomputation pipeline is at the opposite of dynamic 
adjustments.


Removing the regions on the fly *per request* does not seem realistic 
because you'd have to go through the data treatment pipeline again. On 
the other hand, if the excluded regions are not decided per request but 
based on the overall situation throughout the day, then you might want 
to try the MLD pipeline that allow for fast updates to the graph.


Another option may be worth a try if the area is small enough **and** 
the excluded regions can be grouped into a small subset of classes. Then 
the `exclude` parameter[1] would be a way to turn off some region 
classes at query-time. Note that having multiple exclude classes will 
highly impact memory requirements.


HTH
Julien

[1] 
https://github.com/Project-OSRM/osrm-backend/blob/master/docs/http.md#general-options


On 26/08/2020 03:29, Alex Valencia wrote:

Hi All!.

   I'm using OSRM V5 in my company and we are currently thinking how we 
can work with OSRM ignoring zones in a map in some sort of dynamic way.


   For example I want my travel time matrix to be calculated without 
considering some zones in the map modeled as polylines regions. 
Currently the only way we can think of is to remove those regions 
directly from OSM, but this is clearly not a very scalable way 
(especially if the underlying OSM is big).


   So I was thinking if there is a proper way to achieve this goal. We 
are considering separating the matrix calculation over the map in a 
separate function and feeding it with a decorated version of the 
original map where we can remove these regions on the fly prior to the 
calculation. But I'm also not sure if this is a realistic way either.


   Our requirement is to solve VRP instances usually over regions no 
bigger than a city, for example Mexico City,


   Your advice would be much appreciated. Thanks.

   Alex Valencia

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



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

Re: [OSM-talk-fr] CaResteOuvert.fr - 1 km

[Julien Coupey]

Bonjour Jean-Yvon

> Alors un•e volontaire pour nous coder un parcours par les POI
> potentiellement ouverts n'ayant pas des horaires explicites covid19 dans
> un rayon de 1 km ?

C'est déjà codé. S'il y a moyen de récupérer la liste de ces POI 
(Overpass ou autre), il suffit de la donner à manger ici[1].


Par contre je ne suis pas certain que cartographier les horaires (même 
dans un rayon de 1 km) soit une raison valable de sortie...


[1] http://map.vroom-project.org/

À +
Julien

On 29/03/2020 13:27, osm.sanspourr...@spamgourmet.com wrote:

Bonjour,

une idée en mode yaka fokon (mais pas tout à fait).

Comme George l'a remarqué alors que certaines fois on a comme
information "restreint" ou "ouvert"(mais pas les horaires complets) au
lieu de mettre "restricted" ou "open" certains mettent "same".

Alors on peut-être améliorer les choses.

Quand on sort pour une raison autorisée, on n'a pas forcément le
temps/le droit de s'arrêter pour noter les nouveaux horaires.

Déjà si on voit que c'est ouvert en passant on peut mettre "open" à
défaut de mieux.

Alors une photo qu'on garde pour soi ou qu'on dépose sur le net
(Mapillary, OpenStreetCam, Framapic...) pour que d'autres ou soi-même
puissent faire ça depuis chez soi.

@GarenKreis, ton parcours ressemble à celui de la mouche qui se tape
contre les vitres. Il n'y pas de chemin près de chez toi ?

 > si on ajoute en gros deux kilomètres pour l'atteindre
Le point de départ, c'est de chez toi. C'est un disque et non un cercle
qui t'est autorisé. "rayon maximum de 1 km" pas "rayon de 1 km" ;-).

Alors un•e volontaire pour nous coder un parcours par les POI
potentiellement ouverts n'ayant pas des horaires explicites covid19 dans
un rayon de 1 km ?

Peut aussi servir quand on fait par exemple des course : tant qu'on
n'est pas loin d'où on va/vient, peu de risques de se faire verbaliser,
d'autant qu'on permet d'optimiser les déplacements futurs.

Jean-Yvon



___
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] Limite numérique des identifiants de noeuds/ways OSRM

[Julien Coupey]

> Sais-tu si l'équipe les traite encore?

Le problème est qu'à l'heure actuelle il n'y a plus vraiment d' « équipe 
» sur OSRM, tout juste danpat qui fait un peu de SAV en commentant les 
nouveaux tickets ouverts.


S'il s'agit vraiment d'un bug facilement reproductible, il y a toutefois 
des chances que tu aies un retour. Il y a quand même pas mal de gens qui 
continuent à utiliser OSRM et tout ce petit monde a intérêt à ce que ça 
fonctionne. ;-)


Bonne soirée
Julien

On 08/01/2020 18:06, François Lacombe wrote:
Merci Julien, je vais essayer de fournir un fichier de ce style là pour 
une issue

Effectivement je pense que c'est un bug aussi

Sais-tu si l'équipe les traite encore?
Les derniers essais que j'ai fait n'ont pas obtenus de réponse.

Bonne soirée :)

François

Le mer. 8 janv. 2020 à 16:06, Julien Coupey <mailto:o...@coupey.fr>> a écrit :


Re

Si tu récupères en sortie (dans l'objet `annotation.nodes` d'une route)
des ids de nœuds qui ne sont pas dans les données d'entrée, alors c'est
un bug, même si ça n'a apparemment pas de lien avec le fait que les
valeurs soient supérieures à 2^32.

Ça vaudrait certainement le coup d'ouvrir un ticket avec un exemple
minimal pour reproduire. C'est peut-être ça le plus compliqué dans ton
cas car tu sembles utiliser des nœuds renumérotés à la main. Peut-être
réduire l'extrait OSM à un simple way composé de nœuds problématiques
pour pouvoir le fournir ?

À +
Julien

On 08/01/2020 12:29, François Lacombe wrote:
 > Bonjour Julien,
 >
 > Merci pour ta réponse, ça me rassure tout de même.
 > Pour les identifiants de ways, c'est moins problématique pour moi.
 >
 > Ce qui ne passe pas, c'est que j'injecte un XML qui comporte des
noeuds
 > identifiés avec
 > 91220288029161
 > 91220288025445
 > 91220288026438
 >
 > Et qui ressortent avec des identifiants tronqués à 10 digits (ce
ne sont
 > pas les mêmes noeuds). En tout cas ces identifiants là ne sont pas
 > présents dans le .osm d'entrée.
 > 1885473760
 > 246430160
 > 5846804688
 > 737485280
 > 8063904192
 >
 > 8063904192 étant déjà supérieur à la limite 32 bits, j'ai pensé à
une
 > limitation à 10 digits
 >
 > Une idée du problème ?
 >
 > François
 >
 > Le mer. 8 janv. 2020 à 11:41, Julien Coupey mailto:o...@coupey.fr>
 > <mailto:o...@coupey.fr <mailto:o...@coupey.fr>>> a écrit :
 >
 >     Bonjour François
 >
 >     OSRM supporte normalement sans problème les ids OSM sur 64
bits pour
 >     les
 >     nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids
 >     toujours sur 32 bits) mais a priori il y a de la marge si tu
utilises
 >     les données OSM telles quelles.
 >
 >       > ca ne passe pas.
 >
 >     Si tu peux développer un peu sur ce qui coince, peut-être que ça
 >     vaut le
 >     coup d'ouvrir un ticket ?
 >
 >     [1] https://github.com/Project-OSRM/osrm-backend/pull/1793
 >
 >     À +
 >     Julien
 >
 >     On 08/01/2020 11:19, François Lacombe wrote:
 >      > Bonjour la liste
 >      >
 >      > Est-ce que quelqu'un familier avec OSRM saurait me dire quelle
 >     est la
 >      > limite exacte pour les identifiants de nœuds et de chemins
OSM?
 >      >
 >      > Je remarque que ces identifiants ne dépassent pas 10
digits dans les
 >      > réponses fournies par l'API route.
 >      > On en est à 5700014039 de nœuds dans la base, le plafond va
 >     bientôt être
 >      > atteint.
 >      > La maintenance de ces derniers mois est au ralenti, fort à
parier
 >     que ce
 >      > ne sera bientôt plus utilisable?
 >      >
 >      > Perso je régénère des fichiers xml osm avec des
identifiants 64
 >     bits et
 >      > ca ne passe pas.
 >      >
 >      > Preneur de vos commentaires, merci par avance
 >      >
 >      > François
 >      >
 >      > ___
 >      > Talk-fr mailing list
 >      > Talk-fr@openstreetmap.org
<mailto:Talk-fr@openstreetmap.org> <mailto:Talk-fr@openstreetmap.org
<mailto:Talk-fr@openstreetmap.org>>
 >      > https://lists.openstreetmap.org/listinfo/talk-fr
 >      >
 >
 >     ___
 >     Talk-fr mailing list
 > Talk-fr@openstreetmap.org <mailto:Talk-

Re: [OSM-talk-fr] Limite numérique des identifiants de noeuds/ways OSRM

[Julien Coupey]

Re

Si tu récupères en sortie (dans l'objet `annotation.nodes` d'une route) 
des ids de nœuds qui ne sont pas dans les données d'entrée, alors c'est 
un bug, même si ça n'a apparemment pas de lien avec le fait que les 
valeurs soient supérieures à 2^32.


Ça vaudrait certainement le coup d'ouvrir un ticket avec un exemple 
minimal pour reproduire. C'est peut-être ça le plus compliqué dans ton 
cas car tu sembles utiliser des nœuds renumérotés à la main. Peut-être 
réduire l'extrait OSM à un simple way composé de nœuds problématiques 
pour pouvoir le fournir ?


À +
Julien

On 08/01/2020 12:29, François Lacombe wrote:

Bonjour Julien,

Merci pour ta réponse, ça me rassure tout de même.
Pour les identifiants de ways, c'est moins problématique pour moi.

Ce qui ne passe pas, c'est que j'injecte un XML qui comporte des noeuds 
identifiés avec

91220288029161
91220288025445
91220288026438

Et qui ressortent avec des identifiants tronqués à 10 digits (ce ne sont 
pas les mêmes noeuds). En tout cas ces identifiants là ne sont pas 
présents dans le .osm d'entrée.

1885473760
246430160
5846804688
737485280
8063904192

8063904192 étant déjà supérieur à la limite 32 bits, j'ai pensé à une 
limitation à 10 digits


Une idée du problème ?

François

Le mer. 8 janv. 2020 à 11:41, Julien Coupey <mailto:o...@coupey.fr>> a écrit :


Bonjour François

OSRM supporte normalement sans problème les ids OSM sur 64 bits pour
les
nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids
toujours sur 32 bits) mais a priori il y a de la marge si tu utilises
les données OSM telles quelles.

  > ca ne passe pas.

Si tu peux développer un peu sur ce qui coince, peut-être que ça
vaut le
coup d'ouvrir un ticket ?

[1] https://github.com/Project-OSRM/osrm-backend/pull/1793

À +
Julien

On 08/01/2020 11:19, François Lacombe wrote:
 > Bonjour la liste
 >
 > Est-ce que quelqu'un familier avec OSRM saurait me dire quelle
est la
 > limite exacte pour les identifiants de nœuds et de chemins OSM?
 >
 > Je remarque que ces identifiants ne dépassent pas 10 digits dans les
 > réponses fournies par l'API route.
 > On en est à 5700014039 de nœuds dans la base, le plafond va
bientôt être
 > atteint.
 > La maintenance de ces derniers mois est au ralenti, fort à parier
que ce
 > ne sera bientôt plus utilisable?
 >
 > Perso je régénère des fichiers xml osm avec des identifiants 64
bits et
 > ca ne passe pas.
 >
 > Preneur de vos commentaires, merci par avance
 >
 > François
 >
 > ___
 > Talk-fr mailing list
 > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
 > https://lists.openstreetmap.org/listinfo/talk-fr
 >

___
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto: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] Limite numérique des identifiants de noeuds/ways OSRM

[Julien Coupey]

Bonjour François

OSRM supporte normalement sans problème les ids OSM sur 64 bits pour les 
nœuds depuis un moment[1]. Ce n'est pas le cas pour les ways (ids 
toujours sur 32 bits) mais a priori il y a de la marge si tu utilises 
les données OSM telles quelles.


> ca ne passe pas.

Si tu peux développer un peu sur ce qui coince, peut-être que ça vaut le 
coup d'ouvrir un ticket ?


[1] https://github.com/Project-OSRM/osrm-backend/pull/1793

À +
Julien

On 08/01/2020 11:19, François Lacombe wrote:

Bonjour la liste

Est-ce que quelqu'un familier avec OSRM saurait me dire quelle est la 
limite exacte pour les identifiants de nœuds et de chemins OSM?


Je remarque que ces identifiants ne dépassent pas 10 digits dans les 
réponses fournies par l'API route.
On en est à 5700014039 de nœuds dans la base, le plafond va bientôt être 
atteint.
La maintenance de ces derniers mois est au ralenti, fort à parier que ce 
ne sera bientôt plus utilisable?


Perso je régénère des fichiers xml osm avec des identifiants 64 bits et 
ca ne passe pas.


Preneur de vos commentaires, merci par avance

François

___
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] Cartes les plus avancées

[Julien Coupey]

Bonjour

Vu les échanges lors du dernier State of the Map France, il semblerait 
que la ville de Montrouge occupe à elle toute seule les 10 premières 
places du classement. ;-)


À +
Julien (déjà sorti)

On 04/12/2019 19:31, Xavier BIZOT wrote:

Bonjour à toutes et à tous

Quelles sont selon vous les villes dont la carte est le plus avancée une 
sorte de TOP 10 ?


Je vous remercie

Amicalement

Xavier

___
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: [OSRM-talk] what(): Could not find any metrics for MLD in the data. Did you load the right dataset?

[Julien Coupey]

Hi,

The osrm-contract command is used to create the hierarchy for the CH 
algorithm. You need to use the MLD pipeline[1] to preprocess the data.


Alternatively, you can change the algorithm used in example.cpp here[2].

HTH,
Julien

[1] 
https://github.com/Project-OSRM/osrm-backend/wiki/Running-OSRM#quickstart
[2] 
https://github.com/Project-OSRM/osrm-backend/blob/master/example/example.cpp#L42


On 29/11/2019 14:27, Nana Li via OSRM-talk wrote:
Hi, when I was trying to run the example.cpp using Cmake, I got this 
strange message, saying that could not find any metrics for MLD in the 
data. Did you load the right dataset?


|$ ./osrm-example ~/Desktop/my_osrm_learning/myMap.osrm terminate called 
after throwing an instance of 'osrm::util::exception' what(): Could not 
find any metrics for MLD in the data. Did you load the right dataset? 
Aborted (core dumped) |


I figured that the data have to be pre-processed to fit the algorithm 
MLD. I was wondering how to do that? What I did is building from the 
source to get this osrm-* binaries, and then using osrm-extract and 
osem-contract commands to preprocess the .osm.pbf file. After building 
osrm-example using Cmake, run the command ./osrm-example. Did I miss 
something?


Any comments are greatly appreciated.



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



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

Re: [OSM-talk-fr] hebdoOSM Nº 474 2019-08-13-2019-08-19

[Julien Coupey]

Bonjour,

Merci pour cette précision sémantique.

> Les pièges de la traduction automatique ;)

En l'espèce, pas du tout. En effet, la traduction via DeepL de la 
version anglaise de l'article en question[1] fait bel et bien apparaître 
l'expression « réseau électrique » suggérée, et non « grille électrique 
» comme dans l'édition 474.


C'est bien la preuve que le weekly est rédigé par des contributeurs 
humains, qui se posent plein de questions sur la bonne façon de formuler 
les choses mais n'ont pas la prétention d'être au fait des terminologies 
les plus adaptées dans tous les domaines.


Et c'est aussi une nouvelle preuve du fait que nous avons besoin de 
davantage de contributeurs pour collecter, rédiger... ou tout simplement 
relire les éditions ! ;-)


[1] http://weeklyosm.eu/archives/12335#wn474_20654

À +
Julien

On 06/09/2019 15:43, Rpnpif via Talk-fr wrote:

Le 29 août 2019, theweekly@gmail.com a écrit :


Bonjour,

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

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

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm


Bonjour,

...

Le nouveau projet du trimestre britannique consiste à cartographier les 
panneaux solaires sur les toits. Cela aidera à prévoir le comportement de la 
grille électrique


grille-pain ?
Les pièges de la traduction automatique ;).

electrical grid = réseau électrique.



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

[OSM-talk-fr] Cherche intervenant pour présenter OSM

[Julien Coupey]

Bonjour à tous,

J'ai relayé il y a quelques temps l'info[1] sur une rencontre thématique 
GéoStat-Santé du 20 au 24 mai 2019 en Alsace.


Les organisateurs aimeraient proposer une présentation généraliste 
d'OpenStreetMap. Est-qu'un contributeur local (ou pas) serait partant et 
disponible pour aller présenter les grandes lignes du projet ?


D'après ce que j'ai compris, il y aurait encore de la souplesse pour le 
choix du jour précis et du moment de l'intervention, mais il ne faudrait 
pas trop traîner du point de vue de l'organisation. Il y a des 
possibilités de prise en charge des frais associés, n'hésitez pas à 
contacter Anne Quesnel (en copie) pour plus d'infos.


J'espère que quelqu'un pourra se rendre disponible, ça me semble 
vraiment intéressant de pouvoir faire connaître le projet (et ses 
valeurs) dans ce genre de contexte !


[1] https://lists.openstreetmap.org/pipermail/talk-fr/2019-April/092412.html

À +
Julien

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

[OSM-talk-fr] École thématique GéoStat-Santé

[Julien Coupey]

Bonjour,

En marge d'une intervention pour présenter OSM à un colloque de 
géographes, j'avais croisé une personne qui organise une école 
thématique en Alsace dont l'objet est de réunir différentes communautés 
(géographes, géomaticiens, chercheurs et monde de la santé).


Il y avait un intérêt pour OpenStreetMap, donc j'ai proposé de faire 
suivre l'info. En rentrant en contact il y aurait sûrement moyen de 
participer et d'intervenir pour une personne de la communauté intéressée 
par ce domaine.


Le site : https://geostat-sante.sciencesconf.org/
Contact direct : aques...@univ-lille.fr

À +
Julien

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

Re: [OSM-talk-fr] carte OSM sur Facebook

[Julien Coupey]

Bonjour,

J'ai l'impression qu'il n'y a pas de jurisprudence si précise que ça sur 
cette question, et que l'appréciation se fait surtout sur la bonne 
volonté de l'affichage de la source.


Par exemple MAPS.ME affiche systématiquement une mention pendant un 
certain temps à l'ouverture, puis la masque ce qui peut se comprendre 
pour des raisons de lisibilité sur petit écran.


À la présentation d'Apple au State of the Map à Milan, quelqu'un a 
demandé - certes un peu en mode troll - quand est-ce que la mention 
OpenStreetMap apparaîtrait directement sur l'écran des utilisateurs 
d'Apple Maps... La réponse un peu convenue a été que les contributeurs 
OpenStreetMap sont bien crédités, à un ou deux clics de là (au milieu 
d'une liste de sources de données longue comme un grand bras).


À plus
Julien

On 13/02/2019 09:57, Jozeph via Talk-fr wrote:

Bonjour,

Sur la page Facebook de ma commune, une mini carte apparaît sur la page 
d'accueil à droite.


Il faut cliquer une première fois dessus pour voir apparaître une carte 
OSM avec un petit i (comme information) en bas à droite.


Puis cliquer une seconde fois pour accéder à la proposition "mentions 
légales du mappage des données".


Et enfin cliquer une dernière fois pour voir apparaître les mentions 
légales.


Pour une carte électronique OSM navigable, le crédit ne devrait-il 
apparaître dans le coin de la carte dès la page d'accueil ?


Qu'en pensez-vous ?

Cordialement

Joseph

___
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] Besançon / Invitation pour communication plénière lors des 14èmes rencontres de Théo Quant - Nouvelles approches en géographie théorique et quantitative - 6 au 8 février 2019 - Besan

[Julien Coupey]

Bonjour Vincent,

Je suis basé à Dijon, mais très souvent à Besançon pour mon boulot. Si 
personne de plus « local » ne se sent d'intervenir, je veux bien 
représenter OSM à ces rencontres.


À +
Julien

On 02/11/2018 15:11, Vincent Bergeot wrote:

Petit up,

Personne du coté de Besançon ?

Le 24/10/2018 à 10:52, Vincent Bergeot a écrit :


Bonjour,

Une demande est arrivée par plusieurs canaux (liste sotm-fr, 
université et réseau pro) et je suis donc à la recherche de 
contributeurs OSM proche de la recherche et/ou de chercheurs proches 
de OSM, si possible du coté de Besançon.


En voici les éléments clés :

  * En février prochain à Besançon les 14èmes rencontres de Théo Quant
- Nouvelles approches en géographie théorique et quantitative.
  * Cette conférence regroupe la communauté des chercheurs géographes
et issus d'autres disciplines ayant une dimension spatiale.
  * L'organisation souhaite qu'une des 3 conférences plénières porte
sur OSM et ses applications.
  o Donc un intervenant qui pourrait faire une intervention en
séance plénière avec si possible une attention particulière
donnée aux articulations entre OSM et la recherche.
  o La thématique est large et vous aurez toute latitude pour
définir le cadre qui vous convient pour votre intervention.
  * Nous pourrions aussi envisager de monter un atelier participatif
de type mapathon pour les participants du colloque.
  * les organisateurs prennent en charge les frais de déplacement,
d'hébergement et de restauration liés à votre venue

Si cela vous intéresse ou si vous pensez à quelqu'un dites moi je fais 
la mise en lien.


Bonne journée

--

Vincent Bergeot

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



--
Vincent Bergeot


___
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] Calcul d'itinéraire prenant en compte les travaux

[Julien Coupey]

Re,

> Idéalement, il faudrait éviter de modifier OSM pour y déclarer des
> événement ponctuels

Oui bien sûr, c'est pour cela que j'ai précisé « pour peu que la durée 
des travaux le justifie ». Dans les exemples indiqués initialement, on 
est sur du 3 à 4 mois de fermeture, donc ça me semble tout à fait 
pertinent de tagger en « construction » le temps des travaux.


> Et, bien évidemment, il faudrait en parallèle, que les sites de
> calculs d'itinéraires tiennent compte d'EOD

Sans rentrer dans le débat de ce qu'il faudrait idéalement, ce n'est pas 
le cas pour les principaux outils libres existants (OSRM, GraphHopper, 
Valhalla). D'une part car une telle intégration n'a jamais été faite. 
D'autre part comme indiqué par Christian parce que certains algos ont 
besoin d'une vision statique du graphe à un instant donné et, une fois 
un certain nombre de pré-calculs faits, ne pourront de toute façon pas 
réagir de manière dynamique à d'autres sources d'informations.


À mon avis, le premier pas le plus pragmatique est de faire la part de 
ce qui vaut le coup d'être indiqué en dur comme inaccessible pendant une 
durée significative.


À +
Julien

On 24/10/2018 16:21, Francescu GAROBY wrote:

Bonjour,
Idéalement, il faudrait éviter de modifier OSM pour y déclarer des 
événement ponctuels (ou à courte durée), car ce serait augmenter les 
risques de casser quelque chose.
Il vaudrait mieux renseigner tout cela dans OpenEventDatabase : 
http://live.openeventdatabase.org/
Et, bien évidemment, il faudrait en parallèle, que les sites de calculs 
d'itinéraires tiennent compte d'EOD. est-ce le cas ? Je l'ignore 
totalement...


Francescu

Le mer. 24 oct. 2018 à 16:13, Julien Coupey <mailto:o...@coupey.fr>> a écrit :


Bonjour Sébastien,

Le meilleur moyen pour que **tous** les calculateurs d'itinéraires
basés
sur OSM prennent en compte une rue barrée est de l'indiquer comme telle
directement dans OSM pour peu que la durée des travaux le justifie. En
tout cas c'est ce que je fais dans ce cas autour de chez moi en
utilisant highway=construction (pourquoi pas ajouter la date de fin des
travaux si elle est connue).

La question me semble du coup être de savoir comment exploiter
efficacement les données fournies par la ville pour assurer des mises à
jour dans les deux sens (fermeture et ré-ouverture).

À +
Julien

On 24/10/2018 15:53, Sébastien Dinot wrote:
 > Bonjour à tous,
 >
 > On vient de me montrer que la communauté urbaine « Toulouse
Métropole »
 > publie sur son site Open Data une API permettant de connaitre les
 > chantiers en cours
 >

<https://data.toulouse-metropole.fr/explore/dataset/chantiers-en-cours/information/>

 > sur la voirie.
 >
 > La ville de Toulouse publie elle-même ces informations sur son
site Plan
 > DPI <https://www.plan.toulouse.fr/> (qui utilise au passage un
fond de
 > carte OSM qui commence à dater).
 >
 > Voici par exemple les travaux en cours dans mon quartier
 >

<https://www.plan.toulouse.fr/?=PDI=osm=1.4870595932006836,43.57095873068479=num,layer_294=18>.
 >
 > Ces informations sont des plus utiles : les travaux visibles sur le
 > dernier lien entrainent la fermeture de deux rues, ce qui modifie
 > copieusement le flux de circulation dans mon quartier. Or,
l'impact des
 > travaux sur l'axe routier est indiqué dans la description (ici «
Route
 > barrée »).
 >
 > Du coup, il est pertinent de prendre en compte ces informations
dans le
 > calcul d'itinéraire. Connaissez-vous des sites susceptibles de le
faire
 > sur une base OSM auxquels nous pourrions signaler l'existence de
cette
 > donnée ?
 >
 > Sébastien
 >
 > --
 > Sébastien Dinot, sebastien.di...@free.fr
<mailto:sebastien.di...@free.fr>
 > http://sebastien.dinot.free.fr/
 > Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en
passer !
 >
 >
 > ___
 > Talk-fr mailing list
 > Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
 > https://lists.openstreetmap.org/listinfo/talk-fr
 >

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



--
Francescu

___
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] Calcul d'itinéraire prenant en compte les travaux

[Julien Coupey]

Bonjour Sébastien,

Le meilleur moyen pour que **tous** les calculateurs d'itinéraires basés 
sur OSM prennent en compte une rue barrée est de l'indiquer comme telle 
directement dans OSM pour peu que la durée des travaux le justifie. En 
tout cas c'est ce que je fais dans ce cas autour de chez moi en 
utilisant highway=construction (pourquoi pas ajouter la date de fin des 
travaux si elle est connue).


La question me semble du coup être de savoir comment exploiter 
efficacement les données fournies par la ville pour assurer des mises à 
jour dans les deux sens (fermeture et ré-ouverture).


À +
Julien

On 24/10/2018 15:53, Sébastien Dinot wrote:

Bonjour à tous,

On vient de me montrer que la communauté urbaine « Toulouse Métropole » 
publie sur son site Open Data une API permettant de connaitre les 
chantiers en cours 
 
sur la voirie.


La ville de Toulouse publie elle-même ces informations sur son site Plan 
DPI  (qui utilise au passage un fond de 
carte OSM qui commence à dater).


Voici par exemple les travaux en cours dans mon quartier 
.


Ces informations sont des plus utiles : les travaux visibles sur le 
dernier lien entrainent la fermeture de deux rues, ce qui modifie 
copieusement le flux de circulation dans mon quartier. Or, l'impact des 
travaux sur l'axe routier est indiqué dans la description (ici « Route 
barrée »).


Du coup, il est pertinent de prendre en compte ces informations dans le 
calcul d'itinéraire. Connaissez-vous des sites susceptibles de le faire 
sur une base OSM auxquels nous pourrions signaler l'existence de cette 
donnée ?


Sébastien

--
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !


___
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] nouveau champ takeaway:lunchbox

[Julien Coupey]

Bonjour,

Je ne sais pas si c'est exactement ce que tu souhaites décrire, mais il 
y a déjà bulk_purchase[1] qui semble approprié.


Il est déjà utilisé pour les épiceries « en vrac » qui fleurissent 
ici[2] ou là[3].


À +
Julien

[1] : https://wiki.openstreetmap.org/wiki/Key:bulk_purchase
[2] : https://www.openstreetmap.org/node/5618249615
[3] : https://www.openstreetmap.org/node/5867522816

On 18/09/2018 11:20, Vivien MICHON wrote:

Bonjour,

Je propose la possibilité d’indiquer les commerces acceptant que le 
client vienne avec son propre contenant (de type boîte fermable et 
réutilisable).


Cette pratique est de plus en plus courante, afin d’éviter l’utilisation 
de boîtes ou papiers jetables (zéro déchet).


Elle est possible en vente à emporter dans un nombre croissant de 
restaurants, traiteurs, boucheries, fromageries…


Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en YES 
ou NO.


Le terme « lunchbox » fait référence à la boîte contenant le déjeuner, 
qui peut être utilisée à toute heure, pour tout type d’achat. Le terme 
indique également qu’il s’agit de nourriture.


exemple : https://www.openstreetmap.org/node/5130551429

Merci d’avance pour vos commentaires.



___
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: [OSRM-talk] Updating a map

[Julien Coupey]

Hi Didier,

The exclude flag feature introduced a while back in OSRM might explain a 
change in RAM requirements for the same OSM file. If you don't need that 
feature, you can disable the associated extra work/memory usage by 
setting an empty "excludable" list in the profile at:


https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L122-L126

Hope that helps
Julien

On 10/08/2018 09:34, Didier Doumerc wrote:
I have only 12 GB of RAM but when I installed the previous file version, 
it was ok with only 4 GB or RAM.


Is there anyway way to successfully prepare the files ? Perhaps by 
downloading them ready yet ?


Thanks for your answer.

Didier

Le jeu.09/08/18 à 18:15, Sayer, Bryan a écrit :

When I had that problem it was due to lack of memory. For the United 
States, I had to have 64 GB of memory prepare, though I was doing it 
through a Stata interface, not directly.


*From:*Didier Doumerc mailto:doumer...@adimep.com>>
*Sent:*Thursday, August 9, 2018 11:53:39 AM
*To:*osrm-talk@openstreetmap.org 
*Subject:*[OSRM-talk] Updating a map
Hi,

I need help for updating the map file. Here is what I get when I run 
osrm-prepare france-latest.osrm. It stops at 90%


[info] Input file: france-latest.osrm
[info] Profile: profile.lua
[info] Threads: 8
[info] Loading edge-expanded graph representation
[info] Opening france-latest.osrm.ebg
[info] Reading 25874228 edges from the edge based graph
[info] Done reading edges
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0

merged 51783408 edges out of 103496912
contractor finished initalization
initializing elimination PQ ...ok
preprocessing 13952773 nodes  10% . 20% . 30% . 40% . 50% . 60% . 
[flush 9336408 nodes]  70% . 80% . 90% .




Before, I run osrm-extract france-latest/osm.pbf


[info] Input file: france-latest.osm.pbf
[info] Profile: profile.lua
[info] Threads: 8
[info] Using script profile.lua
[STXXL-MSG] STXXL v1.4.1 (prerelease/Release)
[STXXL-ERRMSG] Warning: no config file found.
[STXXL-ERRMSG] Using default disk configuration.
[STXXL-MSG] Disk '/var/tmp/stxxl' is allocated, space: 1000 MiB, I/O 
implementation: syscall autogrow delete_on_exit queue=0 devid=0

[info] Parsing in progress..
[info] input file generated by osmium/1.8.0
[info] timestamp: 2018-08-05T20:00:03Z
[info] Using turn restrictions
[info] Found 3 exceptions to turn restrictions:
[info]   motorcar
[info]   motor_vehicle
[info]   vehicle
[info] Parsing finished after 914.304 seconds
[info] Raw input contains 387758183 nodes, 57191546 ways, and 521319 
relations, and 0 unknown entities

[extractor] Sorting used nodes        ... ok, after 8.97724s
[extractor] Erasing duplicate nodes   ... ok, after 5.16838s
[extractor] Sorting all nodes         ... ok, after 270.95s
[extractor] Building node id map      ... ok, after 146.325s
[extractor] setting number of nodes   ... ok
[extractor] Confirming/Writing used nodes     ... ok, after 84.6342s
[info] Processed 36442184 nodes
[extractor] Sorting edges by start    ... ok, after 46.7546s
[extractor] Setting start coords      ... ok, after 188.624s
[extractor] Sorting edges by target   ... ok, after 47.2029s
[extractor] Computing edge weights    ... ok, after 201.467s
[extractor] Sorting edges by renumbered start ... ok, after 47.6069s
[extractor] Writing used egdes       ... ok, after 33.4863s
[extractor] setting number of edges   ... ok
[info] Processed 37971544 edges
[extractor] Sorting used ways         ... ok, after 3.42604s
[extractor] Sorting 34351 restriction. by from... ok, after 0.078667s
[extractor] Fixing restriction starts ... ok, after 1.32651s
[extractor] Sorting restrictions. by to  ... ok, after 0.048604s
[extractor] Fixing restriction ends   ... ok, after 1.28459s
[info] usable restrictions: 31935
[extractor] writing street name index ... ok, after 0.159635s
[info] extraction finished after 2046.13s
[info] Generating edge-expanded graph representation
[info]  - 31935 restrictions.
[info] Importing n = 36442184 nodes
[info]  - 17000 bollard nodes, 41647 traffic lights
[info]  and 37971544 edges
[info] Graph loaded ok and has 37971544 edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Node compression ratio: 0.166043
[info] Edge compression ratio: 0.19941
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 nodes in edge-expanded graph
[info] generating edge-expanded edges
. 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
[info] Generated 37961020 edge based nodes
[info] Node-based graph contains 13952773 edges
[info] Edge-expanded graph ...
[info]   contains 25874228 edges
[info]   skips 26910 turns, defined by 

Re: [OSRM-talk] points order

[Julien Coupey]

Hi Valerio,

In your example, if the 3 ordered points need to be visited in a row, 
then you can easily transform your problem into a TSP by treating them 
as a single "job". You'd just have to adjust the matrix by ensuring that 
from any other place, the cost to that job is the cost to the first 
point, and the cost from that job is the cost from the third point.


HTH
Julien

On 02/08/2018 15:12, Valerio Paruscio wrote:

Hi,
i'm wandering if its possible to set the order of some points in the 
routing service.
I mean, I need to keep 3 out of 10 points in a certain order, while the 
remaining 7 can be in whatever order.

Is that possible

Thank you very much

Valerio


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



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

Re: [OSRM-talk] osrm-datastore error code 21

[Julien Coupey]

Hi,

Not sure if you're hitting the same problem here, but I recall a related 
discussion happening a while back at:


https://github.com/Project-OSRM/osrm-backend/issues/1724

At least it provides a few hints on permissions and shared memory.

Julien

Le 26/01/2018 à 18:31, Daniel Patterson a écrit :

Kieran,

   Hmm, we could probably improve the error handling here and make the 
message a bit more useful.


   The problem is probably one of:

     1) Permission problems accessing /tmp/osrm.lock
     2) Permission problems creating shared memory

   Code 21 is:

$ errno 21
EISDIR 21 Is a directory

   So I'd suspect some bad filesystem permissions somewhere.  You can 
try running the `osrm-datastore` command under `strace` and see if you 
can spot the syscal that's failing with - that might give a hint as to 
what's going wrong.


daniel

On Fri, Jan 26, 2018 at 8:57 AM, Kieran Caplice 
> wrote:


Hello,

I'm wondering if anyone can help out with this error I'm getting
when running osrm-datastore under a non-root user:

root@htzh /opt/osrm # su - osrm -c "osrm-datastore
/opt/osrm/data/planet-latest/planet-latest.osrm"
[info] Loading data into REGION_1
[info] load names from:
"/opt/osrm/data/planet-latest/planet-latest.osrm.names"
[info] Allocating shared memory of 96772768369 bytes
[error] Error while attempting to allocate shared memory: Invalid
argument, code 21
terminate called after throwing an instance of 'osrm::util::exception'
   what():  Invalid argumentinclude/storage/shared_memory.hpp:308
root@htzh /opt/osrm # su - osrm -c "ulimit -a | grep max"
max locked memory   (kbytes, -l) 128849018880
max memory size (kbytes, -m) unlimited
max user processes  (-u) 1031189

Available shared memory for the user has been increased in
/etc/security/limits.conf as per the wiki page, as shown above.

The server has 256GB of RAM, with at least 200GB available most of
the time. I successfully ran osrm-datastore and osrm-routed as the
root user earlier, but we would ideally run it under a separate user.

Thanks in advance.

Kind regards,
Kieran Caplice


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





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



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

Re: [OSM-talk-fr] Atelier de lutherie

[Julien Coupey]

Effectivement, le mieux semble au final être :

- shop + craft + repair pour les luthiers
- shop + repair pour les « simples » ateliers de réparation (souvent 
plutôt instruments à vent)


Dans les deux cas, musical_instrument comme clé pour préciser le type 
d'instruments.


Merci !
Julien

Le 16/01/2018 à 23:44, osm.sanspourr...@spamgourmet.com a écrit :

Si, la clé craft indique que c'est de la fabrication :

https://wiki.openstreetmap.org/wiki/Key:craft

A minima de l'artisanat.
Tu peux éventuellement ajouter qu'elle fait aussi de la réparation :
https://wiki.openstreetmap.org/wiki/Key:repair

Le 16/01/2018 à 21:11, Julien Coupey - o...@coupey.fr a écrit :

Bonsoir,

Merci pour vos réponses. Je suis parti sur la combinaison :

shop=musical_instrument
craft=musical_instrument
musical_instrument=strings (ou wind)

La seule chose qui n'est pas vraiment décrite est le fait de fabriquer 
en plus de faire de la réparation (le cas des luthiers des instruments 
du quatuor). J'ai précisé ça avec le tag description qui est 
finalement le seul où apparaît le mot luthier le cas échéant.


À+
Julien




___
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] Atelier de lutherie

[Julien Coupey]

Bonsoir,

Merci pour vos réponses. Je suis parti sur la combinaison :

shop=musical_instrument
craft=musical_instrument
musical_instrument=strings (ou wind)

La seule chose qui n'est pas vraiment décrite est le fait de fabriquer 
en plus de faire de la réparation (le cas des luthiers des instruments 
du quatuor). J'ai précisé ça avec le tag description qui est finalement 
le seul où apparaît le mot luthier le cas échéant.


À+
Julien

Le 15/01/2018 à 09:53, Thibaud B a écrit :

Bonjour,


Je suis d'accord avec l'utilisation de craft=musical_instrument + 
musical_instrument=* et/ou éventuellement un tag description=* pour 
préciser l'activité de l'artisan, car ils peuvent parfois 
réparer/fabriquer plusieurs type d'instruments.


Voir exemple ici : https://www.openstreetmap.org/node/5025952922

Ici l'artisan répare tout type d'instrument à vent, j'ai préférer le 
mettre dans description , mais pourquoi pas un musical_instrument=wind


Cordialement,


*De :* marc marc <marc_marc_...@hotmail.com>
*Envoyé :* dimanche 14 janvier 2018 01:10
*À :* talk-fr@openstreetmap.org
*Objet :* Re: [OSM-talk-fr] Atelier de lutherie
Bonjour,

Le 13. 01. 18 à 22:48, Julien Coupey a écrit :
C'est shop=musical_instrument[2] qui semble s'approcher le plus sur le 
wiki, mais sans évoquer l'aspect de création artisanale.
Taginfo trouve seulement 22 occurences de craft=luthier, est-ce que vous 
conseilleriez de l'utiliser ? D'autres idées ?


si shop=musical_instrument semble une bonne idée,
par analogie, tu peux mettre craft=musical_instrument 36 occurrences
https://taginfo.openstreetmap.org/tags/?key=craft=musical_instrument

Si la précision que c'est un luthier te semble nécessaire,
pour ma part je privilégiais un sous-tag genre
craft=musical_instrument + musical_instrument=luthier

Cordialement,
Marc
___
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

[OSM-talk-fr] Atelier de lutherie

[Julien Coupey]

Bonjour,

Je me pose la question de la façon de décrire un atelier/boutique de 
lutherie qui a pignon sur rue avec une vitrine.


En cherchant « luthier » sur le wiki, je suis tombé sur la page de 
craft=carpenter[1] qui mentionne un fumeux carpenter=luthier tout en 
précisant bien qu'il est absurde de décrire la construction 
d'instruments de musique comme une sous-catégorie du travail des 
charpentes...


C'est shop=musical_instrument[2] qui semble s'approcher le plus sur le 
wiki, mais sans évoquer l'aspect de création artisanale.


Taginfo trouve seulement 22 occurences de craft=luthier, est-ce que vous 
conseilleriez de l'utiliser ? D'autres idées ?


Merci !
--
Julien


[1] https://wiki.openstreetmap.org/wiki/Tag%3Acraft%3Dcarpenter
[2] https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmusical_instrument

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

[OSM-talk-fr] Dates du SotM-fr ?

[Julien Coupey]

Bonjour à tous,

Je relaie la question posée par tuxayo sur IRC de savoir si les dates du 
State of the map France 2018 sont fixées ?


On doit être plusieurs à avoir envie d'anticiper sur notre organisation 
pour ne pas manquer ce rendez-vous. À défaut, peut-être une date à 
laquelle la date sera connue ? ;-)


Merci !
Julien

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

Re: [OSRM-talk] OSRM trip service (TSP) limitation

[Julien Coupey]

Oops sorry, forgot links in previous message:

[1]: https://github.com/Project-OSRM/osrm-backend/issues/1623
[2]: http://map.vroom-project.org/

Le 07/10/2017 à 14:49, Julien Coupey a écrit :

Hi Sasha,

For the record, you can read the ticket[1] where fixed start/end 
implementation has been discussed.


TL;DR: the same kind of approach should allow to serve your use-case 
(fix start but end at any location that is preferable for optimization). 
This is how I did it myself anyway, see link in the ticket or this demo[2].


Hope that helps,
Julien

Le 06/10/2017 à 16:17, Sasha Khapyorsky a écrit :

Hi Guys,

I've tried to use OSRM recently. Great stuff!

When using OSRM trip service, I've figured out that this call is
limited by option combintions:

rountrip=true&* or roundtrip=false=first=last

And rest combinations (such as
roundtrip=false=first=any , which I'm looking for)
marked as not implemented.

Do you have any idea about when such implementation is planned?

I'm very new with osrm-backend code (yet), but after commenting out
this limitation and using roundtrip=false=first=any
options OSRM provides the similar and valid paths (at least in couple
of tests, didn't check it in deep yet).

Any ideas, suggestions?

Many Thanks,
Sasha

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



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


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

Re: [OSRM-talk] OSRM trip service (TSP) limitation

[Julien Coupey]

Hi Sasha,

For the record, you can read the ticket[1] where fixed start/end 
implementation has been discussed.


TL;DR: the same kind of approach should allow to serve your use-case 
(fix start but end at any location that is preferable for optimization). 
This is how I did it myself anyway, see link in the ticket or this demo[2].


Hope that helps,
Julien

Le 06/10/2017 à 16:17, Sasha Khapyorsky a écrit :

Hi Guys,

I've tried to use OSRM recently. Great stuff!

When using OSRM trip service, I've figured out that this call is
limited by option combintions:

rountrip=true&* or roundtrip=false=first=last

And rest combinations (such as
roundtrip=false=first=any , which I'm looking for)
marked as not implemented.

Do you have any idea about when such implementation is planned?

I'm very new with osrm-backend code (yet), but after commenting out
this limitation and using roundtrip=false=first=any
options OSRM provides the similar and valid paths (at least in couple
of tests, didn't check it in deep yet).

Any ideas, suggestions?

Many Thanks,
Sasha

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



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

Re: [OSM-talk-fr] HebdoOSM biulding=conservatory

[Julien Coupey]

Bonjour

Deux petites précisions.

1. l'article sur la conf resistance GIS est dans la catégorie « 
événements », et il n'est pas fait mention directe de l'utilisation 
d'OSM mais des SIG et données ouvertes. Du coup je ne vois pas le 
problème si ce n'est effectivement que le mentionner relève d'un choix 
éditorial. En l'espèce c'est donc subjectif mais à mon sens ne pas en 
parler parce qu'il y a une carte g**gle sur la page me semble dommage, 
il vaut mieux au contraire que les personnes de la communauté OSM soient 
au courant de cet évènement. Ne serait-ce que pour signaler cette 
incohérence directement aux intéressés via la page de contact du site. ;-)


2. sur le tag building=conservatory, tu discutes de la pertinence de la 
proposition ce qui sort à mon avis de l'objet d'un article du weekly, 
qui est simplement de rapporter qu'une discussion, débat ou proposition 
est en cours quelque part (liste, wiki, forum, article de journal etc.). 
Voire si c'est pertinent de rapporter les grandes lignes des arguments. 
Aux gens intéressés ensuite de discuter sur le fond s'il y a lieu (comme 
tu le fais finalement en réagissant sur la liste française).


Ce qui m'amène à ma conclusion habituelle : tous ceux qui veulent 
participer un peu, beaucoup, ou passionnément à ces choix et à la 
rédaction au sens large sont les bienvenus, il y en a vraiment besoin !


À +
Julien

Le 18/04/2017 à 03:20, osm.sanspourr...@spamgourmet.com a écrit :

Tu parles de la traduction, pas du contenu je suppose.
Alors on est d'accord.

Par contre sur le choix des thèmes :
https://resistancegis.wordpress.com/ avec un lien en bas sur la carte
Google, c'est assez gaguesque (oui je parle de la présentation pas du fond).

biulding=conservatory. Référencé une fois dans le wiki : sa propre page
.
C'est bien de se faire plaisir. Si vous tombez sur cet attribut vous
vavez ce qu'a voulu dire l'auteur.
Là ce n'est pas la forme mais le fond qui me pause soucis, qu'il veuille
distinguer les serres agricoles/horticoles des autes pourquoi pas. Mais
il mélange les vérandas et bow-windows d'un côté et les vraies verrières
/ serres tropicales de l'autre.
L'article WP conservatory
 ne parle
que des jardin d'hivers et serres tropicales.
Certes en anglais conservatory peut vouloir dire les deux mais pourquoi
mélanger les deux. De plus ce sont bel et bien des serres, donc une
précision à apporter et non un tag complètement différent
Ici ce qu'il ajoute c'est simplement que ce n'est pas une serre de
production donc plutôt produce=no. Je sais ça n'existe pas actulleement.
En fait je suis peut-être un peu négatif puisqu'une vérenda ce serait
building:part
=conservatory
mais ça me semble associer des choses assez différentes.

Jean-Yvon


*Gesendet:* Sonntag, 16. April 2017 um 08:27 Uhr
*Von:* "Stéphane Péneau - stephane.pen...@wanadoo.fr"
*An:* talk-fr@openstreetmap.org
*Betreff:* Re: [OSM-talk-fr] HebdoOSM
Il y a une nette amélioration de l'HebdoOSM depuis quelques semaines.
Dorénavant, je lis la version anglaise et la version française.

Un lien depuis le site osm.fr me semble tout indiqué.

Bravo et merci à ceux qui se sont impliqués !!

Stf

Le 19/02/2017 à 16:03, David Crochet a écrit :

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




___
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] HebdoOSM

[Julien Coupey]

Bonjour

Merci pour vos retours et avis, et merci à ceux qui se sont proposés 
pour donner un coup de main !


Je tente une rapide synthèse :

* la remontée d'infos francophones est cruciale (aspect objectivement 
sous-estimé pour l'instant par rapport à la traduction pure). Il faut 
essayer de mettre l'accent là-dessus, et voir par la suite comment 
mutualiser davantage les choses.


* la version française a une utilité en soit malgré ses imperfections 
(même si on ne peut pas facilement évaluer son audience), et le côté « 
on fait ce qu'on peut » est bien compréhensible pendant le rodage de la 
formule.


Faire une version mensuelle serait sûrement moins lourd mais poserait 
d'autres problèmes techniques vis-à-vis de l'outil existant. Je pense 
qu'il faut dans un premier temps être simplement plus modestes dans les 
objectifs (nombre d'articles dépendant des ressources dispos plutôt que 
chercher à tout traduire). Comme ça a été dit, il vaut mieux une version 
française limitée que pas de version du tout.


Encore une fois, tous ceux qui veulent participer (même peu, même à un 
seul type de tâche), sont les bienvenus ! N'hésitez pas à vous manifester !


À +
Julien

Le 16/02/2017 à 18:24, Manfred A. Reiter a écrit :

Bonjour Julien,

Excusez mon mauvais français, mais je manque de la pratique.
- et non, celui ci n'est pas une traduction automatique ;-)

Note préliminaire:
Contrairement à ce que Philippe Verdy a dit
 hebdo/weeekly/seamanario...OSM n'a rien à voir avec une hégémonie
germanophone! Oui, l'idée fut crée en Allemange, mais cést tout! Ainsi,
le construit par Ph. V. d'un problème linguistique n'existe pas, quand
vous parler un peux de l'anglais.

La communication entre les membres des équipes entre eux est l'anglais.
Bien sûr, les membres de chaque équipe communiquent dans leur propre
langue! ;-)

Pour la production de l'hebdomadaire:
OSMBC [1]est un outil dans lequel de recueillir tous les membres de
l'équipe au cours d'un message de la semaine.

Quand quelqu'un écrit un message dans sa propre langue, il est
souhaitable qu'il écrit ce message en anglais afin qu'ils puissent être
traduits par les autres équipes dans leur langue maternelle. Pour les
liens nous utilison Markdown.

Il est ainsi simple.

Je vous invite à continuer notre conversation dans Slack avec moi et les
autres membres de l'équipe. Vous verrez, pas de personne ne parle un mot
en allemand. ;-)

semanalOSM se comprise comme OSM comme une équipe international.

Donc, - pas de soucis


[1] https://github.com/TheFive/osmbc


2017-02-16 17:29 GMT+01:00 Julien Lepiller >:

Le 2017-02-16 16:27, Jérôme Amagat a écrit :

Bonjour,

Pour moi, comme David Crochet, en anglais ou dans une autre
langue que
le français, je ne le lirais pas, alors que je le lis depuis qu'il
est envoyé sur cette liste.
Et si un sujet m’intéresse mais que le lien est en anglais alors je
fais un effort (ou je regarde les images si c'est autre chose que du
français ou de l'anglais :) )


Hello,

je ne comprends pas du tout comment fonctionne la traduction, qui
traduit et comment, mais si on m'explique quels sont les outils
utilisés et qui contacter, je suis partant pour faire de la
relecture et aider à améliorer la traduction.


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





--
## Manfred Reiter - -
## N49° 25' 11.028" E6° 50' 47.328"
## www.weeklyOSM.eu 


___
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] HebdoOSM

[Julien Coupey]

Bonjour

Merci pour ta réponse. Je suis persuadé également que la version 
française actuelle n'a aucune valeur ajoutée pour quelqu'un qui peut 
lire la version anglaise. En fait il faut se reposer la question des 
objectifs et c'est là-dessus qu'il serait intéressant d'avoir d'autres 
avis pour prioriser les choses puisqu'on n'arrive pas à tout faire dans 
l'immédiat.


Il y a à mon sens deux objectifs différents :

1. Mieux refléter l'actualité des communautés francophones (même si 
l'info passe in fine en anglais).


2. Rendre l'info accessible à des francophones pour qui l'anglais ou les 
autres langues ne sont pas une option.


Peut-être que le point 2 n'a d'intérêt que lorsqu'on arrive à déjà 
adresser le 1 (une édition en français qui ne renvoie que vers des 
articles en anglais présente de toute façon peu d'intérêt en terme 
d'accessibilité pour les non-anglophones).


Qu'en dites-vous ?

Julien


Le 15/02/2017 à 20:22, Frédéric Rodrigo a écrit :

Bonsoir.

Ce qui suit n'est que mon avis et pourrait heurter la sensibilité de
certains.

Personnellement je ne lis que la version anglaise. La version française
arrive plus tard et n'apporte pas grand chose de plus (voir de moins)
Encore une fois à mon avis, si des efforts sont peut être à fournir ils
devraient être sur la remonté d'info francophone vers la version anglaise.

My 2cents.
Frédéric.


Le 15/02/2017 à 15:52, Julien Coupey a écrit :

Bonjour à tous

Suite aux derniers échanges ici[1] et là[2], je lance un fil
spécifique pour donner quelques éléments de contexte et demander vos
avis !

À l'automne dernier, quelques volontaires de la communauté
française/francophone (dans mon cas suite au SotM à Bruxelles) ont
proposé de s'atteler à une version française du WeeklyOSM[3].

La rédaction de cette lettre d'info se fait à l'aide de l'outil OSMBC
qui permet via une interface de diviser les différentes tâches à
réaliser :

- collecter des sujets d'articles
- gérer leur pertinence et les répartir en catégories
- rédiger les articles
- traduire des articles depuis/vers d'autres langues
- effectuer des relectures/validations

Le constat à l'heure actuelle est que les ressources dont nous
disposons ne permettent pas de faire ce travail correctement. Je ne
vais pas refaire les discussions précédentes mais juste donner deux
exemples : en l'absence de relecture, la qualité rédactionnelle est
mauvaise ; sans un effort de collecte, l'édition est une traduction
d'articles en d'autres langues qui reflète peu l'actualité de la
communauté francophone.

C'est là que je pense qu'il est important que d'autres puissent donner
leur avis. Quel place et importance voyez-vous pour ce moyen de
diffuser de l'info sur OSM en français ? Quelles pistes pour améliorer
la situation ?
Peut-être d'autres contributeurs seraient-ils intéressés pour
participer (les tâches ne sont pas toutes chronophages), ou peut-être
y a-t-il d'autres moyens de mutualiser ce genre de travail (Philippe
mentionnait les réflexions en cours autour de la refonte du site).

Bref on est dans une situation où ça ne fonctionne pas et continuer
sans pouvoir assurer la qualité dessert la crédibilité de la version
française. Tous les avis et propositions constructives sont donc
bienvenues !

Merci
Julien

[1]
https://lists.openstreetmap.org/pipermail/talk-fr/2017-January/083451.html

[2]
https://lists.openstreetmap.org/pipermail/talk-fr/2017-February/083570.html

[3] http://www.weeklyosm.eu/

___
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

[OSM-talk-fr] HebdoOSM

[Julien Coupey]

Bonjour à tous

Suite aux derniers échanges ici[1] et là[2], je lance un fil spécifique 
pour donner quelques éléments de contexte et demander vos avis !


À l'automne dernier, quelques volontaires de la communauté 
française/francophone (dans mon cas suite au SotM à Bruxelles) ont 
proposé de s'atteler à une version française du WeeklyOSM[3].


La rédaction de cette lettre d'info se fait à l'aide de l'outil OSMBC 
qui permet via une interface de diviser les différentes tâches à réaliser :


- collecter des sujets d'articles
- gérer leur pertinence et les répartir en catégories
- rédiger les articles
- traduire des articles depuis/vers d'autres langues
- effectuer des relectures/validations

Le constat à l'heure actuelle est que les ressources dont nous disposons 
ne permettent pas de faire ce travail correctement. Je ne vais pas 
refaire les discussions précédentes mais juste donner deux exemples : en 
l'absence de relecture, la qualité rédactionnelle est mauvaise ; sans un 
effort de collecte, l'édition est une traduction d'articles en d'autres 
langues qui reflète peu l'actualité de la communauté francophone.


C'est là que je pense qu'il est important que d'autres puissent donner 
leur avis. Quel place et importance voyez-vous pour ce moyen de diffuser 
de l'info sur OSM en français ? Quelles pistes pour améliorer la situation ?
Peut-être d'autres contributeurs seraient-ils intéressés pour participer 
(les tâches ne sont pas toutes chronophages), ou peut-être y a-t-il 
d'autres moyens de mutualiser ce genre de travail (Philippe mentionnait 
les réflexions en cours autour de la refonte du site).


Bref on est dans une situation où ça ne fonctionne pas et continuer sans 
pouvoir assurer la qualité dessert la crédibilité de la version 
française. Tous les avis et propositions constructives sont donc 
bienvenues !


Merci
Julien

[1] 
https://lists.openstreetmap.org/pipermail/talk-fr/2017-January/083451.html
[2] 
https://lists.openstreetmap.org/pipermail/talk-fr/2017-February/083570.html

[3] http://www.weeklyosm.eu/

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

Re: [OSM-talk-fr] hebdoOSM Nº 340 17/01/2017-23/01/2017

[Julien Coupey]

Re

Au-delà de la question de ce lien précis dont la validité a changé entre 
rédaction et parution, tu soulèves des points importants :


> la version française est élaborée
> uniquement comme une traduction de la version anglaise

> Au passage a encore une traduction française trop automatique

La question du contenu éditorial adapté à la régionalisation de 
l'édition est pertinente, mais demande des gens qui ont l'envie et le 
temps de s'en occuper. À noter également que dans la même logique la 
version anglaise est essentiellement élaborée comme une traduction de la 
version allemande. ;-)


Il me semble que pour l'édition en question (340), la qualité de la 
langue et la compréhension sont correctes. Mais la qualité de la 
traduction et de la rédaction en général est directement liée à la 
disponibilité des ressources, d'où une variabilité très grande (que je 
déplore également).


Conclusion : si vous pensez qu'un tel bulletin est important pour la 
communauté francophone (surtout pour ceux qui ne peuvent pas lire 
l'édition anglaise) et qu'il devrait être de meilleure qualité, alors 
n'hésitez pas à vous proposer pour participer à la rédaction !

Les tâches possibles incluent :
- la remontée de sujets d'articles potentiels ;
- la traduction/rédaction d'articles sur des sujets proposés ;
- le travail de relecture, correction de typos, reformulations etc.

À +
Julien

Le 30/01/2017 à 11:09, Philippe Verdy a écrit :

Si ça se trouve la carte utilisait un serveur de tuiles limité en
capacité et ils se sont fait bloquer pour usage excessif et n'ont pas
prévu autre chose ou sont en train de négocier et en attendant de
déterminer le fournisseur (et le framework Javascript associé pour que
ça fonctionne et que ça passe les autorisations nécessaires) ils ont
désactivé la carte.

Raison de plus pour attendre une communication de la part de l'auteur du
site (ou au moins lui demander) pour voir si c'est stable ou juste une
pré-démo ou un coup d'essai. Cependant la version française est élaborée
uniquement comme une traduction de la version anglaise. Ce genre
d'anomalie devrait donc être relayé aux auteurs de la newsletter pour
leur demander de faire attention avant de faire publicité de
quelquechose qui n'est pas encore abouti ou réellement maintenu.

Je pense que pour la pérénité ou le sérieux de ce bulletin il vaut mieux
se concentrer sur ce qui est stable (ou vers les discussions actives
dans notre communauté) avant de proposer des liens aléatoires vers des
sites tiers, sinon ça ne sert pas le projet et peut limiter même
l'intérêt de lire ce bulletin

--

Au passage a encore une traduction française trop automatique,
visiblement faite par un robot et pas relue: ça n'a pas toujours un sens
ce qu'on lit en français et je me demande même si la version anglaise a
réellement été lue et comprise avant. Je veux bien qu'on utilise un
robot pour accélérer le travail, mais ne pas oublier cette relecture
pour les contresens (l'anglais est souvent très ambigu avec les
juxtapositions de mots dont on ne sait pas toujours la fonction
grammaticale ou la logique qui les relie, alors qu'en français on
distingue mieux les noms, les verbes, les adjectifs et participes, et on
a des prépositions et accords qui clarifient tout, trop souvent dans le
langage abrégé anglophone de telles expressions apparaissent, que ce
soit dans le domaine tehcnique ou les actus en général qui en abusent et
un robot a du mal à traduire, d'autant plus quand on y ajoute des
néologismes et abréviations d'un jargon local). Bref une fois encore ce
n'est pas en français que j'ai lu ce bulletin mais en anglais pour le
comprendre réellement.


Le 30 janvier 2017 à 09:19, Julien Coupey <jul...@coupey.fr
<mailto:jul...@coupey.fr>> a écrit :

Bonjour Philippe

Effectivement, au-delà du lien lui-même, il n'y a plus de carte
accessible sur ce site. Il y en avait pourtant une il y a 5 jours
durant la rédaction mais j'imagine que l'ensemble est toujours en
cours de construction.
Pas grand chose à faire, si ce n'est attendre et en reparler plus
tard...

Julien

Le 30/01/2017 à 00:18, Philippe Verdy a écrit :

Il y a juste un gros problème pour le lien diffusé concernant la
carte
http://opendataday.org/ (le lien "Map of events") pour la carte ne
fonctionne pas (ou pas encore), visiblement il n'existe même pas
sur le
site ou une ébauche initiale ne fonctionne pas et a été supprimée en
attendant une autre solution, je n'ai pas trouvé de solution
autre sur
le site en question qui semble juste en cours de démarrage).



Le 29 janvier 2017 à 13:47, weeklyteam <theweekly@gmail.com
<mailto:theweekly@gmail.com>
<mailto:theweekly@gmail.com
<mailto:theweekly@gmail.com>>> a écrit :

Bonjour,

Le résumé hebdomadaire n° 340 de l'actualité OpenStre

Re: [OSM-talk-fr] hebdoOSM Nº 340 17/01/2017-23/01/2017

[Julien Coupey]

Bonjour Philippe

Effectivement, au-delà du lien lui-même, il n'y a plus de carte 
accessible sur ce site. Il y en avait pourtant une il y a 5 jours durant 
la rédaction mais j'imagine que l'ensemble est toujours en cours de 
construction.

Pas grand chose à faire, si ce n'est attendre et en reparler plus tard...

Julien

Le 30/01/2017 à 00:18, Philippe Verdy a écrit :

Il y a juste un gros problème pour le lien diffusé concernant la carte
http://opendataday.org/ (le lien "Map of events") pour la carte ne
fonctionne pas (ou pas encore), visiblement il n'existe même pas sur le
site ou une ébauche initiale ne fonctionne pas et a été supprimée en
attendant une autre solution, je n'ai pas trouvé de solution autre sur
le site en question qui semble juste en cours de démarrage).



Le 29 janvier 2017 à 13:47, weeklyteam > a écrit :

Bonjour,

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

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


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





___
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] Nouvelles bornes Trilib'

[Julien Coupey]

Re,

Si je comprends ton usage, le respect des sens uniques est important 
(vélo, voiture) mais pas forcément le sens de parcours des chemins pour 
lesquels il y a le choix ? En particulier tu n'a pas forcément besoin de 
passer dans les deux sens sur les chemins qui le permettent ?


Si c'est bien le cas, il y a peut-être un bricolage à tenter pour faire 
quelque chose sans rien développer. Mettons que tu veuilles prendre une 
photo tous les x mètres. Tu transformes alors ton problème en TSP en 
disant que tu souhaites visiter un paquet de nœuds par chemin (voire 
peut-être tous les nœuds de chaque chemin). On peut penser qu'une 
solution raisonnable à ce problème te fera parcourir les chemins en une 
seule fois dans la plupart des cas. Limitations :


- sans garantie d'absence de demi-tour au milieu en fonction de 
l'espacement des nœuds OSM)

- explosion de la taille du TSP (peut-être gérable quand même)
- c'est clairement une façon un peu moche de chercher quelque chose 
d'utilisable sans résoudre le problème initial ;-)


Si tu veux tenter quelque chose dans ce goût-là, n'hésite pas à me 
contacter en direct, je serais curieux de voir si ça peut donner quelque 
chose d'exploitable.


À+
Julien

Le 12/01/2017 à 14:05, Stéphane Péneau a écrit :

Le 11/01/2017 à 17:14, Julien Coupey a écrit :

Salut

Les problèmes de tournées consistent à passer par tous les nœuds d'un
certain graphe (avec éventuellement des contraintes additionnelles).
La nature du problème du postier chinois est différente puisqu'il
s'agit de visiter tous les arcs d'un graphe, donc malheureusement la
réponse à ta question est non. ;-)

Concrètement, si le sens de visite des chemins n'a pas d'importance et
s'il n'y a pas à tenir compte de sens uniques (par exemple à pied),
alors le graphe est non orienté et il existe des méthodes
réalistes/efficaces en temps de calcul pour trouver la solution optimale.
Par contre, si tu dois tenir compte des sens uniques et/ou si le sens
de visite a de l'importance (par exemple tu veux passer dans les rues
une fois dans chaque sens), alors là le problème se complique nettement !

À +
Julien


C'est dommage, et mon usage potentiel (passer partout, à vélo ou en
voiture pour prendre des photos) rentre dans le cas des situations qui
sont plus compliquées. (gestion des sens unique, gros gros malus sur les
demi-tour, etc..)

Stf

___
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] Nouvelles bornes Trilib'

[Julien Coupey]

Salut

Les problèmes de tournées consistent à passer par tous les nœuds d'un 
certain graphe (avec éventuellement des contraintes additionnelles). La 
nature du problème du postier chinois est différente puisqu'il s'agit de 
visiter tous les arcs d'un graphe, donc malheureusement la réponse à ta 
question est non. ;-)


Concrètement, si le sens de visite des chemins n'a pas d'importance et 
s'il n'y a pas à tenir compte de sens uniques (par exemple à pied), 
alors le graphe est non orienté et il existe des méthodes 
réalistes/efficaces en temps de calcul pour trouver la solution optimale.
Par contre, si tu dois tenir compte des sens uniques et/ou si le sens de 
visite a de l'importance (par exemple tu veux passer dans les rues une 
fois dans chaque sens), alors là le problème se complique nettement !


À +
Julien

Le 09/01/2017 à 21:58, Stéphane Péneau a écrit :

Intéressant tout ça, et à tout hasard, est-ce que ça pourrait aider pour
le problème du postier chinois dont j'ai parlé en octobre ?
https://lists.openstreetmap.org/pipermail/talk-fr/2016-October/082202.html

Stf

Le 09/01/2017 à 21:38, Julien Coupey a écrit :

Salut

Je me permets de compléter la réponse de Frédéric en précisant que
l'appli en cours de développement par Mapotempo utilise osrm pour le
routage (comme Maps.me) et vroom[1] pour l'optimisation.

Disclaimer : je suis concerné par un des projets cités ci-dessus. ;-)

À +
Julien

[1] http://vroom-project.org/

Le 09/01/2017 à 20:20, Frédéric Rodrigo a écrit :

Salut,

Florian à utilisé l'application mobile de Mapotempo (basé sur Maps.me).
L'application est toujours en cours de développement et n'est pas encore
publié sur les stores. Néanmoins le code source est déjà disponible sur
github.
L'application mobile, comme l'application web est libre et tous les
codes sont en ligne.

https://github.com/Mapotempo/omim

Si vous voulez tester l'une ou l'autre sans l'installer/compiler vous
même vous pouvez m'envoyer un email en privé. Elles permettent de
préparer et d'aider à effectuer des tournées.

Frédéric.


Le 08/01/2017 à 20:31, Stéphane Péneau a écrit :

Par contre, tu pourrais nous en dire plus sur ce que tu as fait avec
mapotempo ? Je n'ai pas trop bien compris où s'arrêtaient les limites
de la version gratuite.

Stf

Le 08/01/2017 à 19:38, Guillaume AMAT a écrit :

Salut,

Je n'ai pas trouvé ça trop sérieux et c'était même très plaisant de
voir la combinaison parfaite des outils libres :)

Merci pour ton article c'était très agréable à lire,
Guillaume

8 janvier 2017 16:02 "Stéphane Péneau" <stephane.pen...@wanadoo.fr
<mailto:%22st%c3%a9phane%20p%c3%a9neau%22%20%3cstephane.pen...@wanadoo.fr%3E>>

a écrit:

Le 08/01/2017 à 13:09, Florian LAINEZ a écrit :

Je crois que j'ai pris le sujet beaucoup trop au sérieux !
J'en ai fait un article de blog
http://florian.lainez.fr/le-jour-ou-jai-fait-les-poubelles/


Pas besoin que ça soit sérieux pour en faire un article, qui est
très sympa à lire :-)

Stf



Le 31 décembre 2016 à 18:00, Florian LAINEZ <winner...@free.fr
<mailto:winner...@free.fr>> a écrit :

En gros, la majorité (si ce n'est tous) des
recycling:glass=yes qu'on trouve en France, sont faux.

ah ça c'est dommage ;)
De mon point de vue, le fait de notifier que l'on recycle du
verre n'est PAS faux. C'est simplement un premier niveau de
détail qui mérite éventuellement d'être précisé.
En effet recycling:glass_bottles=yes apporte une précision à
recycling:glass=yes
En fait si on pousse la logique jusqu'au bout, les tags
adéquats ne seraient-ils pas les suivants ?
- recycling:glass=yes si la borne permet de collecter du
verre
- recycling:glass=bottles si la borne ne permet de collecter
que des bouteilles de verre
Le 24 décembre 2016 à 22:13,
<osm.sanspourr...@spamgourmet.com
<mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

Actuellement le wiki

<https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Drecycling>
en parle clairement :
Bouteilles de verre et bocaux uniquement.
Le wiki allemand aussi (contenants en verre).

Jean-Yvon
Le 24/12/2016 à 18:16, Stéphane Péneau -
stephane.pen...@wanadoo.fr
<mailto:stephane.pen...@wanadoo.fr> a écrit :

Sauf que ces bornes n'acceptent pas le verre tel que
les verres de table, les plats, etc...
On en a discuté ici :

https://lists.openstreetmap.org/pipermail/talk-fr/2016-July/081636.html



<https://lists.openstreetmap.org/pipermail/talk-fr/2016-July/081636.html>



En gros, la majorité (si ce n'est tous) des
recycling:glass=yes qu'on trouve en France, sont faux.

Stf





___
Talk-fr mailing list
Talk-fr@op

Re: [OSM-talk-fr] Nouvelles bornes Trilib'

[Julien Coupey]

Salut

Je me permets de compléter la réponse de Frédéric en précisant que 
l'appli en cours de développement par Mapotempo utilise osrm pour le 
routage (comme Maps.me) et vroom[1] pour l'optimisation.


Disclaimer : je suis concerné par un des projets cités ci-dessus. ;-)

À +
Julien

[1] http://vroom-project.org/

Le 09/01/2017 à 20:20, Frédéric Rodrigo a écrit :

Salut,

Florian à utilisé l'application mobile de Mapotempo (basé sur Maps.me).
L'application est toujours en cours de développement et n'est pas encore
publié sur les stores. Néanmoins le code source est déjà disponible sur
github.
L'application mobile, comme l'application web est libre et tous les
codes sont en ligne.

https://github.com/Mapotempo/omim

Si vous voulez tester l'une ou l'autre sans l'installer/compiler vous
même vous pouvez m'envoyer un email en privé. Elles permettent de
préparer et d'aider à effectuer des tournées.

Frédéric.


Le 08/01/2017 à 20:31, Stéphane Péneau a écrit :

Par contre, tu pourrais nous en dire plus sur ce que tu as fait avec
mapotempo ? Je n'ai pas trop bien compris où s'arrêtaient les limites
de la version gratuite.

Stf

Le 08/01/2017 à 19:38, Guillaume AMAT a écrit :

Salut,

Je n'ai pas trouvé ça trop sérieux et c'était même très plaisant de
voir la combinaison parfaite des outils libres :)

Merci pour ton article c'était très agréable à lire,
Guillaume

8 janvier 2017 16:02 "Stéphane Péneau" >
a écrit:

Le 08/01/2017 à 13:09, Florian LAINEZ a écrit :

Je crois que j'ai pris le sujet beaucoup trop au sérieux !
J'en ai fait un article de blog
http://florian.lainez.fr/le-jour-ou-jai-fait-les-poubelles/


Pas besoin que ça soit sérieux pour en faire un article, qui est
très sympa à lire :-)

Stf



Le 31 décembre 2016 à 18:00, Florian LAINEZ > a écrit :

En gros, la majorité (si ce n'est tous) des
recycling:glass=yes qu'on trouve en France, sont faux.

ah ça c'est dommage ;)
De mon point de vue, le fait de notifier que l'on recycle du
verre n'est PAS faux. C'est simplement un premier niveau de
détail qui mérite éventuellement d'être précisé.
En effet recycling:glass_bottles=yes apporte une précision à
recycling:glass=yes
En fait si on pousse la logique jusqu'au bout, les tags
adéquats ne seraient-ils pas les suivants ?
- recycling:glass=yes si la borne permet de collecter du verre
- recycling:glass=bottles si la borne ne permet de collecter
que des bouteilles de verre
Le 24 décembre 2016 à 22:13,
> a écrit :

Actuellement le wiki


en parle clairement :
Bouteilles de verre et bocaux uniquement.
Le wiki allemand aussi (contenants en verre).

Jean-Yvon
Le 24/12/2016 à 18:16, Stéphane Péneau -
stephane.pen...@wanadoo.fr
 a écrit :

Sauf que ces bornes n'acceptent pas le verre tel que
les verres de table, les plats, etc...
On en a discuté ici :

https://lists.openstreetmap.org/pipermail/talk-fr/2016-July/081636.html





En gros, la majorité (si ce n'est tous) des
recycling:glass=yes qu'on trouve en France, sont faux.

Stf





___
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] OSRM données prêtes en téléchargement

[Julien Coupey]

Salut

Tu peux utiliser osmfilter pour ne garder que ce qui est intéressant 
pour le routage.


Ça aura un impact sur le temps d'extraction (moins de travail de parsing 
pour OSRM) mais ne devrait pas changer significativement les besoins en 
RAM, car ces éléments « inutiles » sont de toute façon déjà écartés dans 
la construction du graphe.


La solution pour travailler avec OSRM sur de grosses données, c'est de 
la RAM (beaucoup), de la swap et un gros fichier alloué à la librairie 
stxxl.
En pratique, pas mal de gens font faire ces calculs dans des instances 
de machines AWS pour cette raison.


À +
Julien

Le 11/11/2016 à 10:39, damien a écrit :

Merci pour l'info Jean-Yvon, mais je ne crois pas que ça ne conviendra pas.
Par contre, comme les données de base sont en XML, il doit y avoir un
moyen de les filtrer pour en éliminer ce qui ne sert pas au routing (par
exemple les chemins de fer, les restaurants, etc.) afin d'obtenir un
fichier plus léger a ensuite faire parser par OSRM.
Il existe un tel outil ou il faut le faire soit-même ?
Damien



Message: 4
Date: Wed, 9 Nov 2016 20:18:47 +0100
From: osm.sanspourr...@spamgourmet.com
<mailto:osm.sanspourr...@spamgourmet.com>
To: talk-fr@openstreetmap.org <mailto:talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] OSRM données prêtes en téléchargement
Message-ID: <52bcbbd0-d972-97a0-e630-03c50b24b...@gmx.net
<mailto:52bcbbd0-d972-97a0-e630-03c50b24b...@gmx.net>>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Regarde peut-être du côté d'OSMAND qui permet de faire du routage sur le
mobile (sans connexion). Avec par exemple brouter spécialisé vélo
(brouter comme bike router) sachant que le moteur voiture est embarqué.

Pas forcément la réponse à ta question mais à ton problème.

Grosso modo on a besoin des données OSM sous forme de graphe valorisé
par un coût, souvent proportionnel à la durée d'un endroit à l'autre
avec le mode de calcul.

Là ce sera par tuile pour brouter.

Attention, je ne sais si le serveur accepte un téléchargement massif.
Peut-être ont-ils des moyens de production de ces tuiles suffisamment
efficaces.

Jean-Yvon


Le 09/11/2016 à 18:35, damien - dawa...@gmail.com
<mailto:dawa...@gmail.com> a écrit :
> Merci Julien pour la réponse,
> C'est bien dommage que l'extraction ne permette pas un export en XML
> par exemple.
> Je vais devoir trouver un moyen de faire tourner un programme trop
> gourmand en ressources sur un serveur trop petit.
> Damien
>
>
    >
> Date: Wed, 9 Nov 2016 10:51:23 +0100
> From: Julien Coupey <jul...@coupey.fr
<mailto:jul...@coupey.fr> <mailto:jul...@coupey.fr
<mailto:jul...@coupey.fr>>>
> To: talk-fr@openstreetmap.org
<mailto:talk-fr@openstreetmap.org> <mailto:talk-fr@openstreetmap.org
<mailto:talk-fr@openstreetmap.org>>
> Subject: Re: [OSM-talk-fr] OSRM données prêtes en téléchargement
> Message-ID: <ef3a75bf-29ee-6012-f6eb-70599f3a0...@coupey.fr
<mailto:ef3a75bf-29ee-6012-f6eb-70599f3a0...@coupey.fr>
> <mailto:ef3a75bf-29ee-6012-f6eb-70599f3a0...@coupey.fr
<mailto:ef3a75bf-29ee-6012-f6eb-70599f3a0...@coupey.fr>>>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Bonjour
>
> Le problème est que le format actuel des fichiers extraits ne
présente
> aucune garantie de portabilité. La façon dont les données sont
> "dumpées"
> dans ces fichiers peut dépendre de l'OS, des versions des
librairies
> utilisées et change également largement à chaque version d'OSRM.
>
> Conclusion : ça *peut* fonctionner en pratique pour une
version donnée
> d'OSRM de faire l'extraction/contraction sur une machine et le
routage
> sur une autre, mais rien n'est certain...
>
> Plus d'infos sur les travaux en cours à ce sujet :
>
> https://github.com/Project-OSRM/osrm-backend/issues/2242
<https://github.com/Project-OSRM/osrm-backend/issues/2242>
> <https://github.com/Project-OSRM/osrm-backend/issues/2242
<https://github.com/Project-OSRM/osrm-backend/issues/2242>>
>
> À +
> Julien
>
> Le 09/11/2016 à 10:41, damien a écrit :
> > Bonjour,
> > Je me demandais s'il existait des données prêtes à l'emploi pour
> OSRM,
> > c'est à dire déjà extraites.
> > En effet, après un test d'extraction sur un serveur de puissance
> > moyenne, le parsing à pris environ 6h et l'extraction a plantée
> > rapidement après pour ca

Re: [OSM-talk-fr] OSRM données prêtes en téléchargement

[Julien Coupey]

Bonjour

Le problème est que le format actuel des fichiers extraits ne présente 
aucune garantie de portabilité. La façon dont les données sont "dumpées" 
dans ces fichiers peut dépendre de l'OS, des versions des librairies 
utilisées et change également largement à chaque version d'OSRM.


Conclusion : ça *peut* fonctionner en pratique pour une version donnée 
d'OSRM de faire l'extraction/contraction sur une machine et le routage 
sur une autre, mais rien n'est certain...


Plus d'infos sur les travaux en cours à ce sujet :

https://github.com/Project-OSRM/osrm-backend/issues/2242

À +
Julien

Le 09/11/2016 à 10:41, damien a écrit :

Bonjour,
Je me demandais s'il existait des données prêtes à l'emploi pour OSRM,
c'est à dire déjà extraites.
En effet, après un test d'extraction sur un serveur de puissance
moyenne, le parsing à pris environ 6h et l'extraction a plantée
rapidement après pour cause de limite de mémoire RAM.
Ce serait tellement pratique que les données extraites soient mises à
disposition en téléchargement.
Merci de vos réponses
Damien


___
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

[OSRM-talk] Release VROOM v1.0.0

[Julien Coupey]

Hey

A quick note to let you know that a project I've been working on for 
quite some time just reached v1.0.0. VROOM is an optimization engine for 
vehicle routing problems heavily based on OSRM for all table and route 
computations.


If you have your own OSRM instance and want to give it a try, then 
you're all set to go from source[1]. If you just want to test without 
any compiling, you can query the demo server[2] or click around on the 
demo frontend[3]. Check out the project repos if you wish to install 
your own frontend locally.


Features under development include the ability to use libosrm rather 
than osrm-routed.


Hope this can be of interest to some of you. Feel free to get in touch 
or open issues.


Cheers,
Julien

[1]: https://github.com/VROOM-Project/vroom
[2]: https://github.com/VROOM-Project/vroom/wiki/Demo-server
[3]: http://map.vroom-project.org/

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

Re: [OSRM-talk] One request, 2 answers

[Julien Coupey]

Hi Didier,

I'm getting the same kind of result of about 503 km on a custom server 
set-up with *only* the french road network. But if you look closely at 
the 379 km route you get from the demo server, you'll see it goes a long 
way through Switzerland.


My guess would be the second option (data mismatch), with the additional 
bias of a missing country! ;-)


Best,
Julien

Le 21/03/2016 11:59, Daniel Hofmann a écrit :

There are two problems I can see:

1/ the demo server runs from the develop branch, and you are probably
running osrm-backend's latest stable release. It certainly could be that
we fixed a few issues in develop that you don't yet have locally.

2/ the demo server re-runs the toolchain on a fresh planet on a daily
basis, and you're local extract may be outdated (or even a few hour newer).

As you can see there's both the possibility for 1/ code mismatch and 2/
data mismatch between the demo server and your local setup.

Cheers,
Daniel J H

On Mon, Mar 21, 2016 at 11:30 AM, Didier Doumerc > wrote:

Hi,

Here is my first message on this mailinglist.

Some time, I get very different distances, depending of the server
to witch I send the request.

Example : 379 Km vs 503 Km. The right one is 379 km.


router.project-osrm.org/viaroute?loc=48.407126,7.449348=46.117948,6.359105=false=false



Answer : [...]
total_distance":379125,"total_time":14284,"end_point":"Place du
Village","start_point":"Rue Taufflieb (D 35)"},[...]


When I ask my own server :


10.168.221.253:5000/viaroute?loc=48.407126,7.449348=46.117948,6.359105=false=false



Answer : [...]end_point":"Place du Village","start_point":"Rue
Taufflieb (D 35)","total_time":17081,"total_distance":503559}[...]


Can someone tell me how to fix this ?

Thanks

Didier

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




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



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

Re: [OSRM-talk] OSRM - cannot read JSON responce

[Julien Coupey]

Hi,

This seems to be related to your web server policy (and nothing to do 
with OSRM). I had the same situation a while back and solved it by 
adding the following to the relevant apache .conf file:


Header set Access-Control-Allow-Origin "*"

See for example http://enable-cors.org/server_apache.html

Hope that helps,
Julien

Le 28/12/2015 08:16, sergi_jini a écrit :

Dears,

Firstly, thanks to all contributors of OSM!

I have setup OSRM engine on CentOS VM
(https://github.com/Project-OSRM/osrm-backend/wiki) and if I query it
via browser directly it is working fine, returning route.json file.

My problem is that I can't get it working via Javascript. Getting below
error if i query it from my website:

var resultJSON = {};

$.ajax({
 dataType: "json",
 async: false,
 cache: true,
 url:
'http://192.168.137.50:5000/viaroute?geometry=true=42.2585,42.667269338144=42.2695544,42.7017228'
 success: function(data) {
 resultJSON = data;
 }
});

*Error:*
/"Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at
http://192.168.137.50:5000/viaroute?geometry=true=42.2585,42.667269338144=42.2695544,42.7017228.
(Reason: CORS header 'Access-Control-Allow-Origin' missing)."

/
Asstated in APi manual, |jsonp={callback name} must be added to request
URL, which is not helping either. Tried different variations with jsonp,
cache (which is adding extra _ parameter to the URL), getJson method,
crossdomain : true ...Thinking to read the json on server side via
PHP/file_get_contents/ and then send it to front end via json, but can't
get it working either. I believe there must be more smooth way as it is
mentioned in the API manuals.

|
|I would really appreciate if anyone can help me with a working code.
|
//
/

/
Br,
Sergi/
/


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



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

Re: [OSRM-talk] Shortest route given start and end point

[Julien Coupey]

Hi,

I have used a strategy close to what is described in the mentioned 
ticket (see my comment there). It did work for another project to add 
this specific feature to an existing TSP solver.


As for the "computationally expensive" side, it is all a matter of 
trade-off between computing time and solution quality. My experience is 
that 1000's can still be tackled in a matter of seconds with very decent 
results.


Hope this can help,
Julien

Le 09/12/2015 22:32, Patrick Niklaus a écrit :

Hey,

no sadly we don't support this yet. Corresponding ticket is here [1].
Chau suggests a approach in the ticket, but we never investigated if
its actually viable/correct. Let me know if you want to give this a
spin.

Cheers,
Patrick


[1] https://github.com/Project-OSRM/osrm-backend/issues/1623

On Wed, Dec 9, 2015 at 11:38 AM, Kieran Caplice
 wrote:

Hello,

At the moment we're using the MapQuest Optimize Route API
(http://www.mapquestapi.com/directions/#optimized), which given a list of
points, computes the shortest route, using the first point as the start and
the last point as the end. This is the exactly the functionality we're
looking for, but MapQuest is quite expensive, slow, and doesn't support
large batches (we need to support a couple of thousand points).

 From what I've been told, OSRM doesn't support this - it only supports
travelling salesman (trip), using the same start and end point, or viaroute,
which doesn't do any optimisation. I'm wondering how easy/possible would it
be to implement in OSRM, or is there any pre/post processing that we can do
to achieve this?

Thanks in advance.

Kind regards,
Kieran Caplice


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


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



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

Re: [OSRM-talk] How to disable all ferry routes?

[Julien Coupey]

Hi

As I'm curious about this thread, I gave the proposed solution a try. On 
the same osm.pbf data for France, I compared the default car profile 
with the same profile modified with mode_ferry = 0 on line 151.


The modified profile does prevent routing through some ways tagged as 
"route": "ferry" (e.g. http://www.osm.org/way/148185791 and 
http://www.osm.org/way/30154495). But some are still used for routing, 
like for example http://www.osm.org/way/307774731.


Yet, I would expect the same behavior for all above examples in the 
ferries handling part inside way_function in the profile:

https://github.com/Project-OSRM/osrm-backend/blob/develop/profiles/car.lua#L257-L269

Could this be related to other tags, or am I missing something here?

Thanks,
Julien


Le 12/11/2015 04:24, Richard Marsden a écrit :

thanks - I was still at the LUA  stage (and quite a bit can be worked
out from just this level).

The explanation below explains 0 and 1, but I couldn't see any
explanation of the other values - despite some c++ code that set default
TravelMode values of 4 in a couple of places. No documentation in
TravelMode.hpp

The lack of documentation is an issue, and I was planning to write a few
notes about the LUA profiles for others on my blog. They're bound to be
incomplete, but they would be a start and could be updated/corrected as
a living document.

Richard

On Nov 11, 2015, at 6:50 PM, Daniel Hofmann > wrote:


Let me show you how you can find out more about specific variables
like mode_ferry:

your best bet is to search the code base, for example, see this
initial search for mode_ferry:

https://github.com/Project-OSRM/osrm-backend/search?utf8=%E2%9C%93=mode_ferry=Code

you can see how we set result.forward_mode and result.backward_mode to
mode_ferry there, so let's search for forward_mode:

https://github.com/Project-OSRM/osrm-backend/search?utf8=%E2%9C%93=forward_mode=Code

this gives us some lua profiles, which we ignore, since we want to see
how the OSRM implementation uses forward_mode and backward_mode; the
last search hit is scripting_environment.cpp:

https://github.com/Project-OSRM/osrm-backend/blob/8f6fc0146ba76d34d20c5b7a87b75249bbb12b82/extractor/scripting_environment.cpp#L121-L124

this is where we expose the ExtractionWay's set_forward_mode and
set_backward_mode member functions, aliasing them to the lua
properties forward_mode and backward_mode --- so let's go on searching
for the ExtractionWay type:

https://github.com/Project-OSRM/osrm-backend/blob/8f6fc0146ba76d34d20c5b7a87b75249bbb12b82/extractor/extraction_way.hpp#L112-L115

in those member functions, the forward_travel_mode and
backward_travel_mode are set accordingly. If you check their types a
few lines below in the member attribute declarations, you will see
they are of type TravelMode. And here it is:

https://github.com/Project-OSRM/osrm-backend/blob/8f6fc0146ba76d34d20c5b7a87b75249bbb12b82/data_structures/travel_mode.hpp#L34-L35

a quick search for TRAVEL_MODE_INACCESSIBLE reveals the following line
in the extractor:

https://github.com/Project-OSRM/osrm-backend/blob/9ef1f8cba31ec8323b357d233f1c552b1c7c9e09/extractor/extractor_callbacks.cpp#L95-L99

where ways are discarded, if they are inaccessible! Tada!


As you can see, even though it is quite a bit of effort tracing back
specific variables, it can be done in a few minutes with only the most
basic tools (I did this entirely using the Github search functionality
--- of course you can use grep or your code browser of choice, too).

Hope that helps,
Daniel J H

On Wed, Nov 11, 2015 at 7:06 PM, Richard Marsden > wrote:

By coincidence I was working through the lua scripts trying to
understand them.

So what is the significance of the 1,2,3?  Just unique
identifiers. As long as they're non-zero, they will be enabled?

Richard


On Nov 11, 2015, at 9:23 AM, Daniel Hofmann > wrote:


If you take a look at the car profile, you will see a ferry_mode
variable, that sets the travel mode:


https://github.com/Project-OSRM/osrm-backend/blob/8f6fc0146ba76d34d20c5b7a87b75249bbb12b82/profiles/car.lua#L151

If you set this to 0 (i.e. 'inaccessible") as defined here:


https://github.com/Project-OSRM/osrm-backend/blob/8f6fc0146ba76d34d20c5b7a87b75249bbb12b82/data_structures/travel_mode.hpp#L34-L35

then the extractor discards ferry routes because you marked them
inaccessible.

On Wed, Nov 11, 2015 at 9:03 AM, Peter Becker
> wrote:

Hello, i dont want any ferries in my routes. Is this possible?

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

[OSRM-talk] Impact of graph size on table request speed

[Julien Coupey]

Hi,

I need to perform table queries on a few (but not all) european 
countries. Extracting and preparing the whole "europe.osm.pbf" data set 
is an option but I wonder if I should rather try to merge osm files to 
get the smallest required subset.
So I'm wondering if performing the queries on a biggest area impact 
significantly the computing time, compared to the same queries on a 
smaller subset ?


Best
Julien

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