Re: [OSRM-talk] Allowing trunk roads for foot and bicycle directions in the British Isles.

[Daniel Patterson via OSRM-talk]

The missing piece is OSRM following the guidelines outlined here:
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions

Practically, here's what needs to happen:

  1. Someone needs to make a GeoJSON file with these country boundaries,
and set properties on them that describe the access defaults.
  2. Use the `--location-dependent-data` flag to `osrm-extract` so the
properties are available to the Lua scripts setting access rules
  3. Update the Lua scripts to know what to do when the location-dependent
properties are present.

I have enough time to write this down as a guideline for someone, but not
enough spare time to actually go ahead and do it :-/

daniel

On Sat, Apr 24, 2021 at 1:15 PM ika-chan!  wrote:

> Hello,
>
> Last week, VictorIE and I came into conflict about the use of
> "access=yes" on trunk roads ("highway=trunk" and "highway=trunk_link")
> in the Republic of Ireland
> (https://www.openstreetmap.org/changeset/93624048).
>
> In the Republic of Ireland, Greece, and the United Kingdom, trunk roads
> are all-purpose roads that all users can legally use, unless
> specifically prohibited (with the use of the tags "motorroad=yes" or
> "foot=no", etc.): in Greece, "highway=trunk" means an all-purpose
> National Road on an E-Road network
> (https://wiki.openstreetmap.org/wiki/Greece#Highways_in_Greece).
>
> VictorIE believes that it is currently necessary to use "access=yes" on
> trunk roads, because your router does not allow pedestrian and bicycle
> journeys to use trunk roads, even though it is legal to do so
> (
> https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot=51.98803%2C-7.74369%3B51.98943%2C-7.74110).
>
> My belief is that using "access=yes" on trunk roads in IE, GR and GB is
> redundant, and my belief appears to be backed by Osmose
> (
> http://osmose.openstreetmap.fr/en/map/#zoom=12=53.2952=-6.4592=3220=1%2C2%2C3).
>
>
>
> Therefore, I have to write to ask you if you can find a way to update
> the router so that pedestrian and bicycle journeys can use trunk roads
> in Republic of Ireland, Greece and the United Kingdom. If OSRM can
> already recognise left- and right-hand traffic, I do not think that the
> updates will be too hard.
>
> Best,
>
> -- ika-chan!
>
> ___
> 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 set speed values back to lua after using speed updates

[Daniel Patterson via OSRM-talk]

The way to do this is to keep a copy of the original files - when you run
`osrm-customize`, do it on a *copy* of the originals, then load that
modified copy with `osrm-datastore`.

daniel

On Thu, Nov 19, 2020 at 9:09 AM S O  wrote:

>
> Dear all:
>
> I am using the osrm-datastore and osrm-routed -s to update the speeds
> without restarting the server and route with different traffic scenarios
> (MLD routing).
>
> Is there a way to restore/reset the speeds back to default values within
> the same instance after I updated the speeds of some segments with a CSV
> file?
>
> Once again, thank you for the help!!
>
> --
> Silvia O.
> ___
> 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] Comparing OSRM with the car routing by OpenTripPlanner

[Daniel Patterson via OSRM-talk]

I would verify that OSRM considers the highway routable at all - if OSRM
has excluded it for some reason (e.g. HOV-only, under construction, etc),
then it'll be forced to find the next best thing.

Also remember - OSRM is just guessing on the travel speeds based on the
tags present on ways in OSM - these guesses may not always be accurate.
OTP is making the same guesses, but has different opinions on how to
interpret the OSM tags.  Google generates a travel speed model from other
sources which is more realistic than OSM+OSRM out of the box.

Try moving the start/end coordinates around and see if you can confirm that
the desired highway is even routable with OSRM.  The osrm-frontend project (
https://github.com/Project-OSRM/osrm-frontend/) is handy for doing this.
You can also visualize OSRM's view of the routing graph using the debug
viewer: https://github.com/Project-OSRM/osrm-frontend/tree/gh-pages/debug
(modify index.html to point to your own OSRM server) - if the highways have
no coloring, then they're not routable.

daniel

On Tue, Nov 3, 2020 at 12:48 PM Xavier Prudent 
wrote:

> Dear all,
>
> I am comparing two routing machines: openTriplanner and OSRM on the OSM
> map of Québec city (Canada) when looking for the best route by car.
>
> I get very puzzling differences, just running the default versions and
> configurations of OSRM and OTP for these coordinates:
>
> origin
> 46.793187,-71.183014
> destination
> 46.770641,-71.285499
> at 8am, mode car.
>
> The best route by OSRM is a 16km (18min) long, while the OTP
> recommandation is a 20km (24min) one.
> Google map recommends the 20km one (21min), the 16km road having a
> duration of 25 min.
>
> The 20km route goes along a highway, while the 16km one uses a primary
> road, I don't get why OSRM thinks this road is faster, while OTP points the
> opposite.
>
> Are you able to reproduce this discrepancy? Does that make sense to you?
>
> Thanks,
>
> Xavier
>
> --
>
> *Xavier Prudent *
>
> *Data Scientist  - Data Mining - Machine Learning*
>
> Web:* www.xavierprudent.com *
> Tel (Québec)  : (514) 668 76 46
> Skype : xavierprudent
>
>
>
>
> ___
> 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] pont de Québec not in the routing steps of OSRM

[Daniel Patterson via OSRM-talk]

The "steps" that OSRM emits are roughly intended to be human consumable
instructions.  We often collapse "obvious" maneuvers where it'd be annoying
to receive a visual/verbal prompt.  For this reason, "steps" aren't great
objects to use for data analysis, unless you're specifically interested in
the heuristics of ideal navigation instructions.

The alternative I'd suggest would be to find a couple of OSM node IDs that
are on the way you're interested in, and use the `annotations=nodes`
parameter to return the list of nodes along the path - search that list for
your well-known-nodes and you should have confirmation that a path
traversed the geometry you care about.

daniel

On Mon, Nov 2, 2020 at 2:12 PM Xavier Prudent 
wrote:

> Dear OSRMers,
>
> I use OSRM to determine through which bridge a car would cross the river
> St Laurent in Quebec city (Canada).
> When running on the default OSM map, and using steps=true in the API call,
>
> curl -s
> http://127.0.0.1:4040/route/v1/driving/-71.2429112,46.7469116;-71.3315801,46.7701873?steps=true=true=full
>
> I get all steps and street names for the itinerary, except for the Pont of
> Québec. When doing the same with openTripPlanner I find its name in the
> steps sequence.
>
> Why cannot I see this bridge in the OSRM routing steps?
>
> Thank you,
>
> regards,
>
> Xavier Prudent
>
>
> --
>
> *Xavier Prudent *
>
> *Data Scientist  - Data Mining - Machine Learning*
>
> Web:* www.xavierprudent.com *
> Tel (Québec)  : (514) 668 76 46
> Skype : xavierprudent
>
>
> ___
> 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] New v5.23.0 release

[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 swapping data with
> > osrm-datastore and using `exclude=`
> > [#5844](https://github.com/Project-OSRM/osrm-backend/pull/5844)
> >- FIXED: fix crash in MLD alternative search if source or 

[OSRM-talk] New v5.23.0 release

[Daniel Patterson via OSRM-talk]

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 swapping data with
osrm-datastore and using `exclude=` [#5844](
https://github.com/Project-OSRM/osrm-backend/pull/5844)
  - FIXED: fix crash in MLD alternative search if source or target are
invalid [#5851](https://github.com/Project-OSRM/osrm-backend/pull/5851)
- Misc:
  - CHANGED: Reduce memory usage for raster source handling. [#5572](
https://github.com/Project-OSRM/osrm-backend/pull/5572)
  - CHANGED: Add cmake option `ENABLE_DEBUG_LOGGING` to control whether
output debug logging. [#3427](
https://github.com/Project-OSRM/osrm-backend/issues/3427)
  - CHANGED: updated extent of Hong Kong as left hand drive country.
[#5535](https://github.com/Project-OSRM/osrm-backend/issues/5535)
  - FIXED: corrected error message when failing to snap input
coordinates [#5846](https://github.com/Project-OSRM/osrm-backend/pull/5846)
- Infrastructure
  - REMOVED: STXXL support removed as STXXL became abandonware. [#5760](
https://github.com/Project-OSRM/osrm-backend/pull/5760)

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

Re: [OSRM-talk] OSRM does not use date restrictions in conditional access?

[Daniel Patterson via OSRM-talk]

Michael,

  You can pass the `--parse-conditionals-from-now` option to
`osrm-contract`, and it will enable/disable access to `access:conditional`
ways according to the timestamp you type in.  Not so useful for time-of-day
restrictions, but for longer time spanning restrictions, it should do the
trick.

daniel

On Tue, Oct 13, 2020 at 12:39 AM michael spreng 
wrote:

> Hi Maarten
>
> It currently does not. There is an update cycle of about 4 days. I think
> such date ranges would make sense to use at the time of generation
> (however day time ranges would still be ignored). But that is not yet
> implemented as far as I know. It could be implemented in the lua
> profile, so probably no deeper knowledge of osrm is necessary to
> implement this.
>
> Michael
>
> On 13.10.20 08:20, Maarten Deen wrote:
> > Conditional access rules for time and date restrictions follow the same
> > syntax as opening hours rules, see
> > https://wiki.openstreetmap.org/wiki/Conditional_restrictions#Condition
> >
> > I have way https://www.openstreetmap.org/way/96440420 with
> > highway=cycleway+access:conditional=no @ (2019 Okt 07-2021 Apr 29)
> > This cycleway is inaccessible from october 7th 2019 until april 29th
> > 2021, so currently it should not be routed over.
> > But OSRM cycle routing does use this road:
> >
> https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=51.9792%2C4.2676%3B51.9835%2C4.2554#map=17/51.98019/4.26387
> >
> >
> > Does OSRM not use conditional restrictions?
> >
> > Regards,
> > Maarten
> >
> > ___
> > 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] Recreating the same route in another dataset

[Daniel Patterson via OSRM-talk]

Take the route geometry you obtained from your 2020 dataset, and use the
`/matching`  service to match that to your older dataset.

If it's impossible to match (e.g. because roads disappeared), well, then
it's impossible to match.  The `/matching` service allows for some
coordinate imprecision, so it should take care of roads that were moved a
bit.

daniel

On Thu, Oct 8, 2020 at 8:11 AM Martin Schmidl  wrote:

> Hi,
>
> I am calculating a route with OSRM on my dataset of a city in 2020. I want
> to try if I can do exactly the same route on an older dataset of the same
> city (e.g in 2014). At the moment I am computing the route in 2020 and
> extracting the nodes of the fastest route. I check which of the nodes did
> not exist back in 2014 with Overpass and delete those from the list of
> nodes which i have to visit. Now the list of nodes gets converted to their
> respective coordinates in 2014. However, when I want to route over all the
> segments in order (by iteratively routing segments between those nodes in
> OSRM), I sometimes get loops, which I can't seem to prevent because a node
> in 2020 and 2014 might exist, but might not be exactly on a road in 2014
> (screenshot of an example attached).
>
> Maybe someone worked on something similar before and got an idea how to
> solve this, i'd appreciate it!
>
>
> Best regards
> Martin
> ___
> 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] Table request still running even though requesting server has already timed-out the request

[Daniel Patterson via OSRM-talk]

No - OSRM doesn't have any code to interrupt a thread that's working on a
calculation.  We'd need to add code that periodically checks if it should
cancel a long-running algorithm.

daniel

On Mon, Jul 6, 2020 at 9:50 AM ryan.bis...@etruckbiz.com <
ryan.bis...@etruckbiz.com> wrote:

> So I have a server that request a table of 100+ locations this can take a
> bit of time so when the server gets overloaded it times out on waiting for
> the response, but as far as I’m aware that doesn’t stop the table from
> continuing to process or from being removed from the queue. Is there a way
> I can do this?
> ___
> 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] Kilometers in /table route

[Daniel Patterson via OSRM-talk]

You need to add `?annotations=duration,distance` to your API call - then
you'll get metres back as well.

daniel

On Tue, Jun 9, 2020 at 7:24 AM Aurélien   wrote:

> Hi,
>
> Can someone explain me why there is no kilometers in the /table route ?
>
> Is it a technical problem or a functional non sense ?
>
> Thank you very much,
>
> Kin
> ___
> 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] Need help: Customizing weights in Profile shows inconsistent results with Dijsktra

[Daniel Patterson via OSRM-talk]

I would say that the first thing to do to diagnose the problem is to find
the shortest possible path (fewest edges) that exhibit this problem for you.

At first glance, I'd say that your BPR values aren't what you think they
are somewhere along your route, but it's impossible to say exactly where
they might be incorrect.

daniel

On Tue, Apr 14, 2020 at 2:39 AM Niharika Shrivastava <
chunnushrivast...@gmail.com> wrote:

> Hello, I'm new to OSRM and I went through previous issues and couldn't
> find much related to this, hence posting it here.
>
> I had used a python library OSMnx to extract Singapore's data and changed
> certain edge attributes for it. I calculated an edge attribute `"BPR"`
> (float) and stored it in the graph (This is travel time in case of real
> traffic data). I then converted this modified graph into a shapefile and
> then converted the shapefile into OSM XML using JOSM. I fed this to OSRM in
> order to use CH. I want to find the shortest route between two points
> wherein my weights (or cost) are the BPR value I had calculated. I
> understand I have to specify that in the car profile. This is how I
> specified it:
>
> ```
> function setup()
>   return {
> properties = {
>   ...
>   weight_name = 'congestion',
>   ...
> },
>   ...
> }
>
>
> function process_way(profile, way, result, relations)
>   local data = {
> -- prefetch tags
> ...
> BPR = way:get_value_by_key('BPR')
>   }
>
>   result.weight = data.BPR
>   ...
> }
> ```
>
> This is the JSON response I get for a certain query:
> ```
> {'code': 'Ok',
>  'routes': [{'geometry': 's}gG{ijyReEnNdm@|Wpl@~}@b\\lfAw\\twAbFjt@wM
> `ZwSpAGnNgN|Dvm@fWwHhb@bErz@qFxeAzVfkAfr@b{Ak_@rr@ocA~dAgCda@ji@dz@`j@di
> @`Sfi@PfQcRpc@ySyCgw@~XjEx]dHDkEl\\ju@lf@ii@n}@oVqEiKlR_Elw@bJd[lc@wFdKf
> [',
>'legs': [{'steps': [],
>  'distance': 32298.2,
>  'duration': 2308.4,
>  'summary': '',
>  'weight': 2179.6}],
>'distance': 32298.2,
>'duration': 2308.4,
>'weight_name': 'congestion',
>'weight': 2179.6}],
>  'waypoints': [{'hint':
> 'YwYBgG8GAYALAQAAHN-XQWpx4j0AAA0BAAAJyOIxBiSzFADI4jEGJLMUzwFqJcKJ',
>'distance': 0,
>'name': 'Tampines Avenue 8',
>'location': [103.932616, 1.35658]},
>   {'hint':
> 'EAYBgBcGAYAUPzfZQQAAABkJ6oIuBlR3FADqgi4GVHcULwpqJcKJ',
>'distance': 0,
>'name': 'Boon Lay Drive',
>'location': [103.711466, 1.341268]}]}
> ```
>
> Looking at this part from the JSON:
>  ```
>  'duration': 2308.4,
>   'weight': 2179.6}],
> ```
> As I understand, weight is the summation of BPR values for each edge.
> Duration is estimated free flow time:` length/max_speed for each edge`. The
> `value of weight should be >= duration` which is true when I use Dijkstra
> for routing using edge weights as BPR value (`3155.27`). But over here,
> thats not the case.
>
> BPR = duration*(some delay based on traffic) >= duration in case of no
> traffic
>
> Can someone please point out if my Profile is wrongly written or if I've
> missed any steps?
> ___
> 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] Nondeterminism in OSRM response

[Daniel Patterson via OSRM-talk]

Yeah - osrm-routed uses the SO_REUSEPORT socket option (see
https://lwn.net/Articles/542629/), which means you can run two copies of
osrm-routed, and the operating system will round-robin incoming connections
between the two processes.
Handy if you want to do lossless handover from one process to another, but
can cause some confusion if you forget you've already got osrm-routed
running.

daniel

On Mon, Apr 6, 2020 at 2:52 PM Rohit Sivakumar  wrote:

> Please ignore the previous email.
>
> It appears an older osrm server on my machine had not terminated properly,
> causing the nondeterminism.
>
> On Mon, Apr 6, 2020 at 10:34 AM Rohit Sivakumar  wrote:
>
>> Hi,
>>
>> I've been trying to build a profile for large vehicles on osrm. Since I
>> couldn't find out-of-the-box solutions to disable all the via-way u-turns
>> using just the vehicle profiles, I wrote a script last week to detect and
>> add u-turn restrictions wherever possible to an .osm file passed as input.
>>
>> The problem is, osrm respects these restrictions sometimes, but not
>> always. What's even odd is that the same Distance API call (same endpoint
>> and input parameters, same profile) sometimes returns a route with u-turns
>> and at other times it without the u-turns.
>>
>> Has anyone encountered nondeterminism in osrm before ? I can provide more
>> information if this would help.
>>
>> Here's an osrm-frontend screenshot of one such instance where the exact
>> same api-call is made to my local server, but returns two different routes:
>> https://pasteboard.co/J2yZmbX.png
>>
> ___
> 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] OSRM Demoserver - call for hosting volunteers

[Daniel Patterson via OSRM-talk]

Hi all,

On Mar 09, 2020, the TLS certificate for router.project-osrm.org is going
to expire.  At the same time, Mapbox is going to shutdown our hosting of
that service.  As many of you have probably noticed, our investment in the
OSRM codebase has greatly decreased over the last year.

This is a call to the community to see if someone else is willing to take
up the mantle for running the demo server.  If nobody steps up, then the
service will stop working on Mar 09, 2020.

The demoserver currently hovers at around 10k requests/minute with peaks up
to about 50k.

I've also posted a ticket about this at
https://github.com/Project-OSRM/osrm-backend/issues/5655

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

Re: [OSRM-talk] Bicycle routing, crossing large roads: how to get information on the roads crossed

[Daniel Patterson via OSRM-talk]

There are a few old tickets that discuss this:

  https://github.com/Project-OSRM/osrm-backend/issues/96
https://github.com/Project-OSRM/osrm-backend/issues/477
https://github.com/Project-OSRM/osrm-backend/issues/592

Ultimately, what needs to happen is we need to make the `turn_function`
smarter - it needs to grow new parameters when called that allow you to
explore more of the maneuver (i.e. discover other attached roads that are
being crossed, etc), so you can appropriately penalize things like crossing
large roads.

Currently, no information about intersecting roads are included in the
parameters to the turn function.  A while back, properties of the incoming,
and outgoing roads at a turn were added, which was a big improvement, but
further work needs to be done to expose other intersecting parts of the
graph.

daniel

On Mon, Dec 23, 2019 at 8:17 AM Michal Palenik 
wrote:

> I've tried it as well. no success...
>
> similar case is for pedestrian (crossing a major, unroatable road; or
> a railway; or a river with no bridge)
> wheelchair users, strollers
> or nordic skiing users crossing a car road
>
> a next step would be to have a custom penalty on a node, toll booth,
> stop sign, kerb (or any semi accessible barrier, stile),..
> https://github.com/Project-OSRM/osrm-backend/issues/3862
>
>
> michal
> On Mon, Dec 23, 2019 at 07:42:44AM -0800, Spencer Gardner wrote:
> > Unfortunately, I don't have a good solution to offer, but I wanted to add
> > my two cents. I did a ton of research on this exact problem a couple of
> > years ago and virtually none of the open source routing platforms I came
> > across were properly equipped to handle it. It seems to be an issue that
> > only bicycle-oriented folks think about. The solution for my problem was
> to
> > implement in pgRouting where I can do additional processing to assign
> costs
> > as you've described. It's not the way I'd prefer to do it but until
> bicycle
> > routing becomes more sophisticated on other routing platforms that's what
> > I've settled on.
> >
> > I don't have the technical expertise to contribute code to OSRM but I'd
> be
> > more than happy to share my experience with bicycle network planning with
> > anyone looking to improve OSRM's handling of bicycles on this and other
> > questions.
> >
> > Spencer
> >
> > On Mon, Dec 23, 2019 at 6:35 AM Richard Fairhurst 
> > wrote:
> >
> > > Jeroen Hook wrote:
> > >
> > > Is there another way to find out what type of road(s) I am crossing?
> > >
> > >
> > > I think the easiest solution would be to allow bicycles on your
> > > highway=primary, but set it to be a restricted access road (or just to
> have
> > > a really high cost). That way you’d still call process_turn, but in
> reality
> > > the primary road wouldn't be used for routing.
> > >
> > > My private cycle.travel fork does something like this in its
> equivalent
> > > of process_turn (e.g.
> > > https://cycle.travel/map?from=51.7546,-1.2612=51.7554,-1.2616),
> though
> > > it’s a (pretty extensive) fork of 4.9.x so not directly comparable.
> > >
> > > Alternatively, you could do some preprocessing to mark intersections,
> > > depending on the size of your source data. For a different project I
> wrote
> > > https://github.com/systemed/intersector which identifies junctions in
> an
> > > .osm.pbf. If you were to patch it to output node IDs, then look up
> those
> > > node IDs in process_node, you could assign crossing penalties that way.
> > >
> > > Richard
> > > ___
> > > 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
>
>
> --
> michal palenik
> www.freemap.sk
> www.oma.sk
>
> ___
> 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] Map matching for live data-streams, one point at a time

[Daniel Patterson via OSRM-talk]

1.  Supply the coordinates in the order travelled:
/match/v1/oldest;second-oldest;second-newest;newest

2.  Hints aren't quite so helpful for the /matching API - reading the code
I actually think there might be a bug here.  If you pass in a hint, it'll
only use the first snapped candidate from the previous response, instead of
many candidates within range.  Much of the time this will work fine, but
won't if your GPS data is inaccurate and you're closer to an incorrect
road.  Don't pass in hints at all to avoid this bug.

daniel

On Fri, Dec 6, 2019 at 4:52 PM Alex R  wrote:

> Thank you for the fast, detailed and reassuring response.
>
> I have some additional questions:
> 1. In what order must the list of coordinates be given? (i.e.,
>
> http://127.0.0.1:5000/match/v1/driving/most-recent;second-most-recent;third-most-recent
> OR is it the other way around, and the "most-recent" coordinates are in the
> end?)
>
> 2. If I provide a "hint" value (taking it from a previous request), would
> that simplify OSRM's calculations? (or is the "hint" only useful when
> querying different endpoints?)
>
>
> Alex
>
> ___
> 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] Map matching for live data-streams, one point at a time

[Daniel Patterson via OSRM-talk]

Hi Alex,

  If you simply want to find the nearest road to a GPS coordinate, the
/nearest service is simpler.  The /match service is specifically designed
to match a sequence of GPS coordinates *with error* to the most likely path.

  The problem with using /nearest is that it has no context - if your GPS
position has a large error value (10+ metres), then it may snap you to some
nearby road that's not actually where the vehicle is.

  The /match service fixes this - if you supply, say, the last 60 seconds
of coordinates, it will use the prior coordinates to select the most likely
path, and snap the final coordinate to what is probably the right location,
even if there is some error in the GPS value.

  For your specific case - the "NoSegment" error means there was no road to
snap to within 15m of the coordinates - either the OSM map is bad, or your
GPS coordinates have quite a large error in them.  Adding `radiuses=15m`
increases the search range out to 45m (the 15m value is 1 standard
deviation of expected error, we search out to 3 standard deviations).

  1.  Yes, OSRM is suitable for this, if you use the /match service as I
suggested (provide several previous points for context).
  2.  No, but see description above.  Supply a trace to /match, and look at
the last value in the result for the "current" point.
  3.  You'll have to test - I'd guess based on your description that the
last 6 samples would work pretty well.
  4.  It could handle 50 req/sec as long as you:
  1. Give it sufficient CPUs to work with
  2. Don't supply *too* many coordinate to /matching, and keep the
`radiuses=` parameter to the smallest value that works
  3. Test it to determine throughput.
  50 req/sec is not out of the question at all.
  5. See above
  6. If you can be confident about the routes, then you can reduce the size
of your map data (and increase matching performance) by giving OSRM a very
limited road network to work with (just your bus routes).  You'd need to
figure out how to construct that yourself however, and ensure that all
roads are properly connected.  The advantage to using the whole city is
that it will properly follow any deviations from the normal route.
  If you can come up with a road network of just your bus routes, you
can increase the `radiuses=` parameter significantly so things would still
properly snap even in the case where a bus deviates from a route.

Hope that helps.


daniel



On Fri, Dec 6, 2019 at 3:16 PM Alex R  wrote:

> Hi,
>
> I ask for advice in using OSRM with a live stream of data. The examples
> I've seen relate to tracks that can be passed into OSRM and it will apply
> "map matching" to snap all points to the roads, in one move.
>
>  My scenario is different, I am trying to understand whether it is
> feasible with in circumstances:
>  - a fleet of 500 public transport vehicles
>  - each vehicle sends telemetry every 10s
>  - all of this is happening within a 120 km^2 city
>  - the vehicles move on fixed routes that I know in advance
>
> I followed the Docker guide instructions and downloaded the map data for
> my country, then I sent a HTTP request to the matching API, with one
> data-point (note, in the examples below, the order is lon/lat, as mentioned
> in the FAQ):
> curl 'http://127.0.0.1:5000/match/v1/driving/28.8260977,47.0231816'
> OSRM replied with "Number of coordinates needs to be at least two."
>
> So I did: curl '
> http://127.0.0.1:5000/match/v1/driving/28.8260977,47.0231816;28.8260977,47.0231816
> '
> and got {"message":"Could not find a matching segment for any
> coordinate.","code":"NoSegment"}
>
> What worked out in the end was:
> curl '
> http://127.0.0.1:5000/match/v1/driving/28.8260977,47.0231816;28.8260977,47.0231816?radiuses=15;15
> '
>
>
>  My questions are:
>  1. Is OSRM's matching suitable for such scenarios?
>  2. Did I correctly understand and apply the matching API?
>  3. What is the recommended number of points for a match query?
>  4. In what circumstances would it be able to handle a rate of 50
> requests/s?
>  5. What techniques can I apply to increase throughput?
>  6. Instead of using the map of an entire country, or even a city - can I
> tell OSRM to match to a specific route that I know for sure the vehicle is
> on?
>
>
>  I look forward to your to your feedback,
> Alex
> ___
> 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] Reasonable use of public server

[Daniel Patterson via OSRM-talk]

The public server is rate limited to 5000 requests/minute.  If you flood it
with requests, likely many of yours won't work, and you'll block other
people from using it.

For this volume of work, you should investigate running a local server.  We
provide Docker images to run OSRM locally - these should be usable on
Windows (although I have not personally tested it).

daniel

On Sun, Nov 3, 2019 at 6:19 PM Taylor Moseley 
wrote:

> HI My name is Taylor, and I'm exploring orsmr. I was wondering how many
> viaroute requests would be considered too many, as I have quite a lot of
> data to process, on the order of 15-17 million trips. Not all at once,
> maybe a million at a time. I imagine that's too much for the public server,
> but my options as far as non-windows machines are likely to be very limited
> as I work for the state on a small grant.
> I may be able to cut this down my limiting the maximum distance via
> geosphere or other packages
>
> A windows backend would be ideal but that's apparently not supported
> anymore.
> ___
> 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] Compiling OSRM Code

[Daniel Patterson via OSRM-talk]

Looking through the repo history, the function `AddCoordinate` only
appeared for a brief time between the 4.9.1 and the 5.0.0 release.  It was
never part of a tagged version.

Bateesh - you have three options:

  1) Downgrade your OSRM version to 4.9.1, and use `addCoordinate` instead
of `AddCoordinate`
  2) Find the exact gitsha that you previously used to build against OSRM.
I'm guessing you just grabbed the latest code at the time.  That function
was removed in f3e72623e9ec9764c6be1f2aa81a4523f9647077, so somewhere
before that, but after the 4.9.1 tag would be close.
  3) Do as Mateusz suggest, and upgrade to the latest version.  Check the
`examples/` directory for how to hit the current API interface.

daniel

Bateesh


On Tue, Jul 30, 2019 at 3:07 AM Mateusz Loskot  wrote:

> On Tue, 30 Jul 2019 at 10:43, BATEESH .  wrote:
> >
> > I am trying to compile project which uses osrm libraries and was written
> in 2017.
>
> Likely, you will have to update your application to catch it up with any
> changes
> that happened in the OSRM C++ API (which, AFAIK, gives no promise on
> stability/compatibility).
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
> ___
> 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] Docker pre-processing from a python script

[Daniel Patterson via OSRM-talk]

It'd be something like this (untested):

subprocess.run(["docker","run","-t","-v", "%s:/data" % os.getcwd(),
"osrm/osrm-backend", "osrm-extract -p /opt/car.lua
/data/berlin-latest.osm.pbf"])

daniel

On Wed, Jul 10, 2019 at 7:22 AM Silvia Oviedo  wrote:

>
> Hi all,
>
> I would like to run the pre-process of the car profile from a python
> script. I have checked the documentation of subprocess library and  docker
> SDK for python but I don´t know how to properly make the request. For
> example, how could I transform the sh request:
>
> docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-extract -p 
> /opt/car.lua /data/berlin-latest.osm.pbf
>
> So it can be done from python. Is that possible?
>
>
> Thank you in advance
>
> ___
> 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 docker error

[Daniel Patterson via OSRM-talk]

Very likely you ran out of memory - I'd check your system logs to see if
the Linux kernel OOM killer terminated your process.  The process suddenly
stopping like this with no error is typical of that scenario.

Check that your docker install doesn't have some hard memory limits in
place - if so, you will probably need to increase them.

daniel

On Thu, Jun 6, 2019 at 10:42 AM Fabio Fraga Machado  wrote:

> Hi, folks.
>
> I'm trying to change from osrm VM to osrm docker, but i cant go to next
> step after extract my pbf file.
>
> # docker run -ti -v "${PWD}:/data" osrm/osrm-backend osrm-extract  -p
> /opt/car.lua /data/brazil-latest.osm.pbf
> [info] Parsed 0 location-dependent features with 0 GeoJSON polygons
> [info] Using script /opt/car.lua
> [info] Input file: brazil-latest.osm.pbf
> [info] Profile: car.lua
> [info] Threads: 2
> [info] Parsing in progress..
> [info] input file generated by osmium/1.8.0
> [info] timestamp: 2019-06-05T20:14:02Z
> [info] Using profile api version 4
> [info] Found 3 turn restriction tags:
> [info]   motorcar
> [info]   motor_vehicle
> [info]   vehicle
> [info] Parse relations ...
> [info] Parse ways and nodes ...
> [info] Using profile api version 4
> [info] Parsing finished after 438.765 seconds
> [info] Raw input contains 102476783 nodes, 9400271 ways, and 6367
> relations, 53330 restrictions
> [info] Sorting used nodes... ok, after 5.26049s
> [info] Erasing duplicate nodes   ... ok, after 0.097733s
> [info] Sorting all nodes ... ok, after 24.2996s
> [info] Building node id map  ... ok, after 34.9726s
> [info] Confirming/Writing used nodes ... ok, after 36.7284s
> [info] Writing barrier nodes ... ok, after 0s
> [info] Writing traffic light nodes ... ok, after 0s
> [info] Processed 26706858 nodes
> [info] Sorting edges by start... ok, after 107.493s
> [info] Setting start coords  ... ok, after 129.864s
> [info] Sorting edges by target   ... ok, after 170.663s
> [info] Computing edge weights... ok, after 194.645s
> [info] Sorting edges by renumbered start ... ok, after 194.499s
> [info] Writing used edges   ... ok, after 116.735s -- Processed
> 29423534 edges
> [info] Writing way meta-data ... ok, after 1.72054s -- Metadata
> contains << 3446120 entries.
> [info] Sorting used ways ... ok, after 3.74104s
> [info] Collecting start/end information on 0 maneuver overrides...ok,
> after 0.040274s
> [info] Collecting start/end information on 0 maneuver overrides...ok,
> after 0s
> [info] Collecting start/end information on 53330 restrictions...ok, after
> 1.82737s
> [info] Collecting start/end information on 53330 restrictions...ok, after
> 10.3571s
> [info] writing street name index ... ok, after 1.52269s
> [info] extraction finished after 1553.41s
> [info] Generating edge-expanded graph representation
> [info] . 10% . 20% . 30% . 40% . 50% . 60% . 70% . 80% . 90% . 100%
> [info] Node compression ratio: 0.230783
> [info] Edge compression ratio: 0.301608
>
> When i run partition, I receive this message:
> # docker run -t -v "${PWD}:/data" osrm/osrm-backend osrm-partition
> /data/brazil-latest.osrm
> [error] Input file "/data/brazil-latest.osrm.ebg" not found!
>
> And i cant go on. What i did wrong?
> The files created after the extract is:
>
> # ls -la
> total 2090112
> drwxr-xr-x  2 root root166 Jun  6 14:00 .
> dr-xr-x---. 7 root root268 Jun  4 14:54 ..
> -rw-r--r--  1 root root  726801691 Jun  6 13:33 brazil-latest.osm.pbf
> -rw-r--r--  1 root root 1396580352 Jun  6 14:00 brazil-latest.osrm
> -rw-r--r--  1 root root   16878080 Jun  6 14:00 brazil-latest.osrm.names
> -rw-r--r--  1 root root   6144 Jun  6 14:00
> brazil-latest.osrm.properties
> -rw-r--r--  1 root root   3584 Jun  6 13:35
> brazil-latest.osrm.timestamp
>
>
> My docker version is:
> # docker version
> Client:
>  Version:   18.09.6
>  API version:   1.39
>  Go version:go1.10.8
>  Git commit:481bc77156
>  Built: Sat May  4 02:34:58 2019
>  OS/Arch:   linux/amd64
>  Experimental:  false
>
> Server: Docker Engine - Community
>  Engine:
>   Version:  18.09.6
>   API version:  1.39 (minimum version 1.12)
>   Go version:   go1.10.8
>   Git commit:   481bc77
>   Built:Sat May  4 02:02:43 2019
>   OS/Arch:  linux/amd64
>   Experimental: false
>
>
> My OS is: CentOS 7
> Fabio Fraga Machado
> *SRE / DevOPs* @ iTER IOT Solutions
> 48  991862005 • www.iter.net.br
> Av. Josué di Bernardi, 23 - Campinas, São José - SC
> CEP 88101-200
> ___
> 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 enter multiple stops with mouse click

[Daniel Patterson via OSRM-talk]

Click two times to make your start and end points.  Once you have a route,
you can divide it up by clicking on the routeline to add additional
waypoints that you can then move around.

daniel

On Wed, Mar 6, 2019 at 3:48 PM Aykut Ucar  wrote:

> Hi,
> in the demo
> http://map.project-osrm.org/
> How do you drop multiple stops with mouse click?
> I tried right click, holding ctrl and alt keys.
> Any help would be appreciated.
> Thanks.
> ___
> 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] Install OSRM on MacOs

[Daniel Patterson]

Hi Didier,

  Looks like you're using the correct profile file.

  As a next step, I'd take a look at using the debug mapping tool at:

https://github.com/Project-OSRM/osrm-frontend/tree/gh-pages/debug

  Install a copy of this locally and modify this line:


https://github.com/Project-OSRM/osrm-frontend/blob/gh-pages/debug/index.html#L128

  to point at your local `osrm-routed` process (usually `
http://localhost:5000/tile/v1/car/tile({x},{y},{z}).mvt`)

  This will let you see the final speeds assigned to all roads in your
routing graph.

daniel

On Mon, Jan 14, 2019 at 5:48 AM Didier Doumerc  wrote:

> Hi Daniel,
>
> Here are the cammands I run :
>
> Serveur-CMR:osrm-backend informatique$ ./build/osrm-extract
> ./build/france-latest.osm.pbf -p profiles/car.lua
> Serveur-CMR:build informatique$ osrm-partition france-latest.osrm
> Serveur-CMR:build informatique$ osrm-customize france-latest.osrm
> Serveur-CMR:build informatique$ osrm-contract france-latest.osrm
>
>
> Serveur-CMR:build informatique$ osrm-routed --algorithm=MLD
> france-latest.osrm
>
> I looked for another car.lua on the disk. There is none.
>
> Thanks for all.
>
> Didier
>
>
> Le sam.12/01/19 à 00:36, Daniel Patterson a écrit :
>
> Hi Didier,
>
>   I mean, can you include the *full command* you ran?  At a minimum, I'd
> expect `osrm-extract somemap.osm`.
>
>   By default, `osrm-extract` will look for a file called
> `profiles/car.lua` relative to the directory in which you invoke it.
>
>   I would verify a few things:
>
> 1. Are you somehow accidentally using a different version of
> `osrm-extract` from somewhere else on your system PATH (like /usr/local/bin
> ?)
> 2. Are you passing a `-p profiles/car.lua` parameter explicitly, or
> are you depending on the default.
>
>   Also note that modifying the `maxspeed_table_default` and `fr:urban`
> values will only affect those road types.  This will only affect roads that
> have `maxspeed=fr:urban` - other road types will not be affected (
> https://wiki.openstreetmap.org/wiki/Key:maxspeed#Values).
>
>   If the area you're testing routes in doesn't have those tags, then there
> will be no effect.
>
> daniel
>
> On Fri, Jan 11, 2019 at 3:14 PM Didier Doumerc 
> wrote:
>
>> I tried :
>>
>> osrm-extract
>>>
>>
>> osrm-partition
>>>
>>
>> osrm-customize
>>>
>>
>> osrm-contract
>>>
>>
>> That does not work.
>>
>> And I tried
>>
>> osrm-extract
>>>
>>
>> osrm-contract
>>>
>>
>> That does not work too.
>>
>>
>> (iP) Didier
>>
>> Le 11 janv. 2019 à 18:45, Daniel Patterson  a écrit :
>>
>> What were the *exact* commands you ran?
>>
>> daniel
>>
>> On Fri, Jan 11, 2019 at 6:06 AM Didier Doumerc 
>> wrote:
>>
>>> So I have modified car.lua file : maxspeed_table_default (all values
>>> fixed to 50) and maxspeed_table ["fr:urban"] = 10 etc...
>>>
>>> I have
>>> re-runned `osrm-extract/osrm-partition/osrm-customize/osrm-contract` and it
>>> changes nothing. I get the same result.
>>>
>>> I must do something wrong...
>>>
>>> Didier
>>>
>>> Le mer.09/01/19 à 18:18, Daniel Patterson a écrit :
>>>
>>> Hi Didier,
>>>
>>>   The `car.lua` file are all the rules for deciding which OSM ways to
>>> import, and what speeds to assign to them.  If you modify the Lua script,
>>> you need to re-run `osrm-extract/osrm-contract`.
>>>
>>>   The OSRM demoserver at `router.project-osrm.org` *also* has traffic
>>> data imported (using this mechanism:
>>> https://github.com/Project-OSRM/osrm-backend/wiki/Traffic), supplied by
>>> Mapbox, so travel times and routes may differ from datasets you generate
>>> yourself just using the `car.lua` profile locally.
>>>
>>> daniel
>>>
>>> On Tue, Jan 8, 2019 at 7:47 AM Didier Doumerc 
>>> wrote:
>>>
>>>> Thanks for your answer Daniel. It works fine !
>>>>
>>>> I'm not sure to understand exactly the reason of "-p profiles/car.lua".
>>>> Does the file car.lua contain speed limits ?
>>>>
>>>> Then, if I change a speed, I must run another osrm-extract ?
>>>>
>>>> In my exemple, the following request  :
>>>>
>>>>
>>>> 10.168.221.144:5000/route/v1/driving/2.590291,44.360367;2.627096,44.980478?overview=false
>>>>
>>>> returns :
>>>> 1:45 a

Re: [OSRM-talk] Install OSRM on MacOs

[Daniel Patterson]

Hi Didier,

  I mean, can you include the *full command* you ran?  At a minimum, I'd
expect `osrm-extract somemap.osm`.

  By default, `osrm-extract` will look for a file called `profiles/car.lua`
relative to the directory in which you invoke it.

  I would verify a few things:

1. Are you somehow accidentally using a different version of
`osrm-extract` from somewhere else on your system PATH (like /usr/local/bin
?)
2. Are you passing a `-p profiles/car.lua` parameter explicitly, or are
you depending on the default.

  Also note that modifying the `maxspeed_table_default` and `fr:urban`
values will only affect those road types.  This will only affect roads that
have `maxspeed=fr:urban` - other road types will not be affected (
https://wiki.openstreetmap.org/wiki/Key:maxspeed#Values).

  If the area you're testing routes in doesn't have those tags, then there
will be no effect.

daniel

On Fri, Jan 11, 2019 at 3:14 PM Didier Doumerc  wrote:

> I tried :
>
> osrm-extract
>>
>
> osrm-partition
>>
>
> osrm-customize
>>
>
> osrm-contract
>>
>
> That does not work.
>
> And I tried
>
> osrm-extract
>>
>
> osrm-contract
>>
>
> That does not work too.
>
>
> (iP) Didier
>
> Le 11 janv. 2019 à 18:45, Daniel Patterson  a écrit :
>
> What were the *exact* commands you ran?
>
> daniel
>
> On Fri, Jan 11, 2019 at 6:06 AM Didier Doumerc 
> wrote:
>
>> So I have modified car.lua file : maxspeed_table_default (all values
>> fixed to 50) and maxspeed_table ["fr:urban"] = 10 etc...
>>
>> I have
>> re-runned `osrm-extract/osrm-partition/osrm-customize/osrm-contract` and it
>> changes nothing. I get the same result.
>>
>> I must do something wrong...
>>
>> Didier
>>
>> Le mer.09/01/19 à 18:18, Daniel Patterson a écrit :
>>
>> Hi Didier,
>>
>>   The `car.lua` file are all the rules for deciding which OSM ways to
>> import, and what speeds to assign to them.  If you modify the Lua script,
>> you need to re-run `osrm-extract/osrm-contract`.
>>
>>   The OSRM demoserver at `router.project-osrm.org` *also* has traffic
>> data imported (using this mechanism:
>> https://github.com/Project-OSRM/osrm-backend/wiki/Traffic), supplied by
>> Mapbox, so travel times and routes may differ from datasets you generate
>> yourself just using the `car.lua` profile locally.
>>
>> daniel
>>
>> On Tue, Jan 8, 2019 at 7:47 AM Didier Doumerc 
>> wrote:
>>
>>> Thanks for your answer Daniel. It works fine !
>>>
>>> I'm not sure to understand exactly the reason of "-p profiles/car.lua".
>>> Does the file car.lua contain speed limits ?
>>>
>>> Then, if I change a speed, I must run another osrm-extract ?
>>>
>>> In my exemple, the following request  :
>>>
>>>
>>> 10.168.221.144:5000/route/v1/driving/2.590291,44.360367;2.627096,44.980478?overview=false
>>>
>>> returns :
>>> 1:45 and 100,6 km
>>>
>>> The same request on
>>> https://www.openstreetmap.org/directions?engine=osrm_car=44.3604%2C2.5903%3B44.9805%2C2.6271#map=10/44.6713/2.4894
>>> <https://www.openstreetmap.org/directions?engine=osrm_car=44.3604,2.5903;44.9805,2.6271#map=10/44.6713/2.4894>
>>>
>>> returns :
>>> 1:50 and 103 km
>>>
>>> The second result is better than the first. Is it because of the car.lua
>>> file ?
>>>
>>>
>>> Thanks+++
>>>
>>> Didier
>>>
>>> Le ven.04/01/19 à 18:52, Daniel Patterson a écrit :
>>>
>>> Check out the Wiki page at:
>>> https://github.com/Project-OSRM/osrm-backend/wiki/Running-OSRM
>>>
>>> With OSRM 5.x, the names of some of the tools changed.  You will now
>>> want to run `osrm-extract -p profiles/car.lua yourmap.osm` then
>>> `osrm-contract yourmap.osrm`
>>>
>>> daniel
>>>
>>> On Fri, Jan 4, 2019 at 9:33 AM Didier Doumerc 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Since I can't upgrade whith a new map (crash when running
>>>> osrm-prepare), I try to reinstall OSRM.
>>>>
>>>> Once I have reinstalled ORSM, I can extract the new map, but I don't
>>>> find osrm-prepare anymore. I don't know what to do before running
>>>> osrm-routed.
>>>>
>>>> Is someone can give me a link please to a clear and complete install
>>>> method ?
>>>>
>>>> Thanks an

Re: [OSRM-talk] Install OSRM on MacOs

[Daniel Patterson]

What were the *exact* commands you ran?

daniel

On Fri, Jan 11, 2019 at 6:06 AM Didier Doumerc  wrote:

> So I have modified car.lua file : maxspeed_table_default (all values fixed
> to 50) and maxspeed_table ["fr:urban"] = 10 etc...
>
> I have
> re-runned `osrm-extract/osrm-partition/osrm-customize/osrm-contract` and it
> changes nothing. I get the same result.
>
> I must do something wrong...
>
> Didier
>
> Le mer.09/01/19 à 18:18, Daniel Patterson a écrit :
>
> Hi Didier,
>
>   The `car.lua` file are all the rules for deciding which OSM ways to
> import, and what speeds to assign to them.  If you modify the Lua script,
> you need to re-run `osrm-extract/osrm-contract`.
>
>   The OSRM demoserver at `router.project-osrm.org` *also* has traffic
> data imported (using this mechanism:
> https://github.com/Project-OSRM/osrm-backend/wiki/Traffic), supplied by
> Mapbox, so travel times and routes may differ from datasets you generate
> yourself just using the `car.lua` profile locally.
>
> daniel
>
> On Tue, Jan 8, 2019 at 7:47 AM Didier Doumerc 
> wrote:
>
>> Thanks for your answer Daniel. It works fine !
>>
>> I'm not sure to understand exactly the reason of "-p profiles/car.lua".
>> Does the file car.lua contain speed limits ?
>>
>> Then, if I change a speed, I must run another osrm-extract ?
>>
>> In my exemple, the following request  :
>>
>>
>> 10.168.221.144:5000/route/v1/driving/2.590291,44.360367;2.627096,44.980478?overview=false
>>
>> returns :
>> 1:45 and 100,6 km
>>
>> The same request on
>> https://www.openstreetmap.org/directions?engine=osrm_car=44.3604%2C2.5903%3B44.9805%2C2.6271#map=10/44.6713/2.4894
>> <https://www.openstreetmap.org/directions?engine=osrm_car=44.3604,2.5903;44.9805,2.6271#map=10/44.6713/2.4894>
>>
>> returns :
>> 1:50 and 103 km
>>
>> The second result is better than the first. Is it because of the car.lua
>> file ?
>>
>>
>> Thanks+++
>>
>> Didier
>>
>> Le ven.04/01/19 à 18:52, Daniel Patterson a écrit :
>>
>> Check out the Wiki page at:
>> https://github.com/Project-OSRM/osrm-backend/wiki/Running-OSRM
>>
>> With OSRM 5.x, the names of some of the tools changed.  You will now want
>> to run `osrm-extract -p profiles/car.lua yourmap.osm` then `osrm-contract
>> yourmap.osrm`
>>
>> daniel
>>
>> On Fri, Jan 4, 2019 at 9:33 AM Didier Doumerc 
>> wrote:
>>
>>> Hi,
>>>
>>> Since I can't upgrade whith a new map (crash when running osrm-prepare),
>>> I try to reinstall OSRM.
>>>
>>> Once I have reinstalled ORSM, I can extract the new map, but I don't
>>> find osrm-prepare anymore. I don't know what to do before running
>>> osrm-routed.
>>>
>>> Is someone can give me a link please to a clear and complete install
>>> method ?
>>>
>>> Thanks and happy new year...
>>>
>>> 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
>>
> ___
> 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] Install OSRM on MacOs

[Daniel Patterson]

Check out the Wiki page at:
https://github.com/Project-OSRM/osrm-backend/wiki/Running-OSRM

With OSRM 5.x, the names of some of the tools changed.  You will now want
to run `osrm-extract -p profiles/car.lua yourmap.osm` then `osrm-contract
yourmap.osrm`

daniel

On Fri, Jan 4, 2019 at 9:33 AM Didier Doumerc  wrote:

> Hi,
>
> Since I can't upgrade whith a new map (crash when running osrm-prepare), I
> try to reinstall OSRM.
>
> Once I have reinstalled ORSM, I can extract the new map, but I don't find
> osrm-prepare anymore. I don't know what to do before running osrm-routed.
>
> Is someone can give me a link please to a clear and complete install
> method ?
>
> Thanks and happy new year...
>
> 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

Re: [OSRM-talk] points order

[Daniel Patterson]

Hi Valerio,

  What you're describing falls under the title of "Vehicle Routing Problem"
(https://en.wikipedia.org/wiki/Vehicle_routing_problem).  OSRM includes a
basic solver for the Travelling Salesman Problem solver with the `/trip`
API, but it doesn't have a lot of options - it will re-order all points to
the best order it can find, you can't set any constraints.

  The usual way this type of problem gets solved is in 3 steps:

1. Generate a travel time matrix with the `/table` plugin.
2. Feed that matrix, along with your additional constraints, into a
constraint solver, like https://github.com/VROOM-Project,
https://github.com/google/or-tools, or one of several commercial constraint
solvers that support VRP.  Whichever one has parameters for your particular
problem constraints.
3. Use the returned coordinate order from the solver to request the
full route from `/route` using the final order of points as route waypoints.

  Implementing a fully-featured constraint solver for Vehicle Routing
Problems is a huge undertaking, and so far, we've considered it mostly
outside OSRM's responsibilities.

daniel


On Thu, Aug 2, 2018 at 6:14 AM 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] how to block subway routes to foot profile?

[Daniel Patterson]

Hi Patrick,

  In order to exclude them from matching, you'll need a way to identify
them via the OSM tags.  If you can figure out the tags that are on these
ways and not others, you can add some logic to `profiles/foot.lua` to
remove them from the routing graph.  If they're removed, then won't be
matched on.

daniel

On Mon, Jun 18, 2018 at 7:55 AM Patrick Agin  wrote:

> Hi,
> I noticed that some routes returned by match service (for foot profile)
> are subway routes. How to prohibit these solutions?
> Thanks
> Patrick
> ___
> 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] map matching service for a huge number of requests

[Daniel Patterson]

Some folks have written Python wrappers around libosrm, like here:

  https://github.com/ustroetz/python-osrm

but I've never tried them, so I don't know how up-to-date they are, or how
easy they will be to get working.

If you're comfortable in NodeJS, then OSRM supports Node bindings as a
first-class citizen.

daniel

On Fri, May 11, 2018 at 11:46 AM, Sasha Khapyorsky <sash...@gmail.com>
wrote:

> Technically it is possible (for example
> https://stackoverflow.com/questions/145270/calling-c-c-from-python),
> but I'm pretty sure that you will need to create sort of c++ envelop,
> shared lib, etc.. It would be easier just to do what you need in c++
> instead of python.
>
> Sasha
>
> On Fri, May 11, 2018 at 9:37 PM, Patrick Agin <agin.patr...@gmail.com>
> wrote:
> > thanks Sasha. And do you know if it's possible to do calls to libosrm
> > functions directly from Python?
> >
> > 2018-05-11 14:33 GMT-04:00 Sasha Khapyorsky <sash...@gmail.com>:
> >>
> >> Hi again, Patrick,
> >>
> >> On Fri, May 11, 2018 at 9:22 PM, Patrick Agin <agin.patr...@gmail.com>
> >> wrote:
> >> >
> >> > And are you aware of some python code that would do the calls to
> >> > osrm-routed
> >> > in parallel threads?
> >>
> >> There are lot of examples of how to make python things in parallel
> >> threads. For example:
> >> https://stackoverflow.com/questions/2846653/how-to-use-
> threading-in-python
> >>
> >> Sasha
> >>
> >> > Regards,
> >> > Patrick
> >> >
> >> > 2018-05-11 14:07 GMT-04:00 Daniel Patterson <dan...@mapbox.com>:
> >> >>
> >> >> Patrick,
> >> >>
> >> >>   There are about a million possible paths you could take here, a lot
> >> >> of
> >> >> it will depend on what skills you have available.  Off the top of my
> >> >> head:
> >> >>
> >> >> 1) Speed things up by avoiding HTTP overhead and calling the
> >> >> libosrm.a
> >> >> functions directly instead of hitting `osrm-routed` over HTTP
> >> >> 2) Modify the OSRM C++ source code and strip out the parts of the
> >> >> map-matching response you don't need
> >> >> 3) Simplify your trace geometries to speed up map-matching
> >> >> 4) Break your trace list into sets and run these on multiple
> >> >> machines
> >> >> in parallel (make copies of the OSRM data onto multiple machines)
> >> >> 5) Just wait 10 hours, and get a good nights sleep
> >> >>
> >> >>   libosrm.a is thread-safe, so if you're calling functions from
> threads
> >> >> you can do many at once.
> >> >>
> >> >>   osrm-routed is multi-threaded, so you can run many queries in
> >> >> parallel -
> >> >> how many will depend on how many CPUs your machine has.  Profiling
> >> >> multi-threaded server performance is kind of beyond the scope of OSRM
> >> >> itself, there is lots of literature on it.
> >> >>
> >> >> daniel
> >> >>
> >> >> On Fri, May 11, 2018 at 10:57 AM, Patrick Agin <
> agin.patr...@gmail.com>
> >> >> wrote:
> >> >>>
> >> >>> Sorry for the newbie question but what's the difference between
> >> >>> osrm-routed and libosrm? Is it mandatory to use the latter for a
> >> >>> parallel
> >> >>> usage? And do you have an example of code that does the calls in
> >> >>> parallel
> >> >>> threads? Thanks Sasha for your help.
> >> >>> Patrick
> >> >>>
> >> >>> 2018-05-11 13:50 GMT-04:00 Sasha Khapyorsky <sash...@gmail.com>:
> >> >>>>
> >> >>>> Hi Patrick,
> >> >>>>
> >> >>>> If you are using libosrm (which reported to be thread safe:
> >> >>>> https://github.com/Project-OSRM/osrm-backend/issues/4966) you can
> >> >>>> just
> >> >>>> split your list and run its parts in different parallel threads.
> >> >>>>
> >> >>>> Sasha
> >> >>>>
> >> >>>> On Fri, May 11, 2018 at 8:14 PM, Patrick Agin
> >> >>>> <agin.patr...@gmail.com>
> >> >>>> wrote:
> >> >>>> 

Re: [OSRM-talk] Snapping preferences

[Daniel Patterson]

Hi François,

  Currently, no - snapping for coordinates is strictly whichever is nearest
(with one exception:
https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8
).

  I can think of two things:

1.  Try using the `/match` API.  This API snaps to *many* nearest
points (usually within 15m), and tries routes between all combinations, and
returns the most likely.  As long as your coordinates are reasonably close
(<2km), it should be almost usable as a replacement for the `/route` API.

2.  You can use the `/nearest` API to return more than one possible
snap point within range, then pick one, then request `/route` with the
snapped coordinates you have chosen.  This is only viable if `/nearest`
returns enough information for you to decide which snapping point is best.

daniel


On Fri, May 4, 2018 at 8:37 AM, François Lacombe 
wrote:

> Hi all,
>
> I'm wondering if osrm can weight its snapping choices for start location ?
> Especially for footwalk mode.
>
> There are situations where farer ways can lead to shorter routes.
> Currently osrm always snap start location to nearest way but doesn't give
> me the shortest route according to my knowledge.
>
> Is there any trick in the profile to make some ways preferable to snap to?
> Should I open an issue regarding this?
>
> All the best
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> ___
> 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 force match service to return public transport routes only?

[Daniel Patterson]

Hi Patrick,

  Train ways are typically tagged directly with `train=`.  Bus
routes are typically not tagged directly on a way itself (because busses
run on roads shared with other traffic), but rather, the way is a member of
a bus route relation.

daniel

On Tue, May 1, 2018 at 8:05 AM, Patrick Agin <agin.patr...@gmail.com> wrote:

> I understand but my question was (sorry if it was unclear), why is it
> different between train and bus?
>
> 2018-05-01 10:02 GMT-04:00 Michal Palenik <michal.pale...@freemap.sk>:
>
>> On Tue, May 01, 2018 at 09:30:36AM -0400, Patrick Agin wrote:
>> > Thanks Michal and Daniel for your help, I defined my subway profile and
>> it
>> > works well.
>> >
>> > Michal, can I ask you why you use this kind of code for the train
>> profile:
>> > train = way:get_value_by_key('train');
>> > if ( not data. train or data. train =='') then return false;
>>
>> this checks way's tags
>>
>> >
>> > and this kind of code for the bus:
>> > bus = get_from_rel(relations, way, "route", "bus", "route");
>> > if ( not data.bus =='') then return false;
>>
>> this one checks relations' tags (of relations that the way is a member
>> of)
>>
>> > Aren't they defined the same way in osm data?
>> > Patrick
>> >
>> > 2018-04-30 13:26 GMT-04:00 Patrick Agin <agin.patr...@gmail.com>:
>> >
>> > > Thanks again Michal I'll try it soon with subway instead of bus. Out
>> of
>> > > curiosity, why do you define highway in process_way function? It does
>> not
>> > > seem to be used elsewhere.
>> > >
>> > > 2018-04-30 13:03 GMT-04:00 Michal Palenik <michal.pale...@freemap.sk
>> >:
>> > >
>> > >> On Mon, Apr 30, 2018 at 12:57:42PM -0400, Patrick Agin wrote:
>> > >> > Thanks a lot to both of you. Michal, can I ask you two things:
>> > >> > what's the purpose of adding tram and train to excludable?
>> > >>
>> > >> generally to ignore trains when they do not have a common ticketing
>> > >> scheme.
>> > >>
>> > >> > and about get_from_rel(relations, way, "route", 'bus', "route")
>> line, is
>> > >> > 'bus' a reserved OSM word or is it defined by you?
>> > >>
>> > >> function get_from_rel(relations, way, "route", 'bus', "network")
>> > >> will find first/random relation of route=bus which the way is a
>> member
>> > >> of, and then returns tag "network".
>> > >>
>> > >> see also
>> > >> https://github.com/Project-OSRM/osrm-backend/issues/5032
>> > >>
>> > >> > I ask the question
>> > >> > because I would like to manage subway routes.
>> > >> > Patrick
>> > >> >
>> > >> > 2018-04-30 12:48 GMT-04:00 Michal Palenik <
>> michal.pale...@freemap.sk>:
>> > >> >
>> > >> > > hi, I have it working
>> > >> > > https://github.com/FreemapSlovakia/freemap-routing/blob/
>> > >> master/oma-bus.lua
>> > >> > > (and train profile below)
>> > >> > >
>> > >> > > michal
>> > >> > >
>> > >> > > On Mon, Apr 30, 2018 at 09:26:22AM -0700, Daniel Patterson wrote:
>> > >> > > > Hi Patrick,
>> > >> > > >
>> > >> > > >   Nobody has written a "How to make a public transport profile"
>> > >> document
>> > >> > > > for OSRM, you'll have to piece it together from examples and
>> reading
>> > >> > > code.
>> > >> > > >
>> > >> > > >   That said, the "testbot" profile here:
>> > >> > > > https://github.com/Project-OSRM/osrm-backend/blob/master/
>> > >> > > profiles/testbot.lua
>> > >> > > >
>> > >> > > >   is fairly simple.  There are 3 functions: `process_node`,
>> > >> > > `process_way`,
>> > >> > > > and `process_turn`.  The `process_way` function is run for
>> every
>> > >> way in
>> > >> > > the
>> > >> > > > OSM file you input, and it decides whether to include it in the
>> > >> routi

Re: [OSRM-talk] Limit particular points in a route at runtime

[Daniel Patterson]

Hi François,

  There are basically 3 ways to go about this:

1. If you only have toll-booth nodes, then you can cheat and use the
`result.traffic_lights = true` flag on those nodes, and adjust the traffic
light penalty.  This isn't perfect though, you'll probably want to remove
traffic light tags from elsewhere, and that might mess up some routing,
although I suspect not much.

2. If you have `toll=yes` on the toll roads, you can simply adjust the
speed/rate down for those roads.  This has the downside that the routing
engine will tend to route you *off* those roads as quickly as possible,
which isn't always what you want.

3.  You can use the restricted access tags to add a penalty for
*turning onto a toll road* - this will mostly avoid toll roads, and will
not unnecessarily route you off them.  Take a look at how "access=private"
is implemented currently (and how `turn.source_restricted` and
`turn.target_restricted` are used) in the `process_turn` function.  Again,
you may need to sacrifice other access=private/destination features to get
what you need here.

  Also take a look at Chau's work in
https://github.com/Project-OSRM/osrm-backend/pull/4858 - there may be other
ways you can use the `process_turn` function to add penalties for accessing
tolled roads.

daniel

On Wed, Mar 28, 2018 at 9:13 AM, François Lacombe <fl.infosrese...@gmail.com
> wrote:

> Thank you for this input,
>
> Understood the lack of dynamic costing in OSRM. I'll adapat my profile
> Would it be preferable to lower the rate or the speed of specific way I
> want to limit ? Maybe both ?
> I'm not sure to be able to set a rate on a given node isn't it ?
>
> This have to be necessarily relative to rest of my graph
>
> All the best
>
> Francois
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>
> 2018-03-28 17:59 GMT+02:00 Daniel Patterson <dan...@mapbox.com>:
>
>> Hey François,
>>
>>   The only way to achieve this with OSRM would be to apply large
>> penalties to barriers/tolls.  You'll have to pick a penalty value that's
>> *just right* - enough that 0 or 1 will be acceptable, but 2 would force the
>> engine to find another route.
>>
>>   Because OSRM doesn't have dynamic costing options, you can't do
>> something like "penalize the first toll with 0, penalize the second toll
>> with 1000" - for that, you'd need to be able to run a more customizable
>> routing algorithm.
>>
>>   We have muttered about implementing A* on the edge-based-graph which
>> would make this possible, but so far, nobody has put the time in to
>> implement it.
>>
>> daniel
>>
>> On Wed, Mar 28, 2018 at 8:31 AM, François Lacombe <
>> fl.infosrese...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> Another question I have while I continue to build a routing system
>>> dedicated to industrial networks in parallel of roads we get from osm.
>>>
>>> I'd be interested to get osrm result with a limited amount of particular
>>> ways or nodes in the route.
>>> Something like "Get me from A to B with only 0 or 1 toll barrier on the
>>> route", is this possible ?
>>>
>>> I know the exclude URL parameter to exclude some pre-processed classes
>>> of object, but don't know if we can actually limit them.
>>>
>>> Thanks in advance for any hint, all the best
>>>
>>> François
>>>
>>> ___
>>> 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
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Limit particular points in a route at runtime

[Daniel Patterson]

Hey François,

  The only way to achieve this with OSRM would be to apply large penalties
to barriers/tolls.  You'll have to pick a penalty value that's *just right*
- enough that 0 or 1 will be acceptable, but 2 would force the engine to
find another route.

  Because OSRM doesn't have dynamic costing options, you can't do something
like "penalize the first toll with 0, penalize the second toll with 1000" -
for that, you'd need to be able to run a more customizable routing
algorithm.

  We have muttered about implementing A* on the edge-based-graph which
would make this possible, but so far, nobody has put the time in to
implement it.

daniel

On Wed, Mar 28, 2018 at 8:31 AM, François Lacombe  wrote:

> Hi all,
>
> Another question I have while I continue to build a routing system
> dedicated to industrial networks in parallel of roads we get from osm.
>
> I'd be interested to get osrm result with a limited amount of particular
> ways or nodes in the route.
> Something like "Get me from A to B with only 0 or 1 toll barrier on the
> route", is this possible ?
>
> I know the exclude URL parameter to exclude some pre-processed classes of
> object, but don't know if we can actually limit them.
>
> Thanks in advance for any hint, all the best
>
> François
>
> ___
> 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] Pre-procesing planet.pbf with 128Gb RAM

[Daniel Patterson]

Hi Jose,

  That's correct, the published node binaries aren't built with STXXL
support.

  You can always use swap, but due to the memory access patterns that OSRM
uses, it tends to be *incredibly* slow (what takes hours in RAM can take
days or weeks with swap, depending on the amount).  STXXL is greatly
preferred when you're constrained for RAM.

  The more RAM you can supply, the faster things will go.

  These numbers are a bit out of date, but will give you a sense of what
you'll need:
https://github.com/Project-OSRM/osrm-backend/wiki/Disk-and-Memory-Requirements

  I haven't run the whole planet for a while (here at Mapbox, we divide it
up into the large disconnected geographic regions), so I don't have any
more up-to-date numbers than that wiki page.

danie

On Mon, Mar 5, 2018 at 7:28 PM, Jose Florido <joseflor...@gmail.com> wrote:

> Thanks!  So that means we cannot use the provided node binaries, right?
>
> Do you think that 192 gb of RAM + swap would be enough to be able to do
> preparation without STXXL enabled?
>
> Thanks!
> Jose
>
>
> On Mon, Mar 5, 2018, 19:09 Daniel Patterson <dan...@mapbox.com> wrote:
>
>> Hi Jose,
>>
>>   128GB is not enough to do *everything* in RAM - over 300GB of data is
>> generated during some phases.
>>
>>   You'll probably want to do a custom build of OSRM and enable STXXL with
>> `cmake -DENABLE_STXXL=ON ..`.  This will build OSRM with the ability to do
>> optimized data-to-disk swapping using the "libstxxl" library, which is
>> faster than just using regular swap space.
>>
>> daniel
>>
>> On Mon, Mar 5, 2018 at 11:44 AM, Jose Florido <joseflor...@gmail.com>
>> wrote:
>>
>>> Hi!
>>>
>>> Is it possible to pre-process the planet file with OSRM 5.16.2 and
>>> only 128Gb ram? We do have a large SSD disk and pre processing doesn’t
>>> need to be super fast.
>>>
>>> Thanks!
>>> Jose
>>>
>>> ___
>>> 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
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Pre-procesing planet.pbf with 128Gb RAM

[Daniel Patterson]

Hi Jose,

  128GB is not enough to do *everything* in RAM - over 300GB of data is
generated during some phases.

  You'll probably want to do a custom build of OSRM and enable STXXL with
`cmake -DENABLE_STXXL=ON ..`.  This will build OSRM with the ability to do
optimized data-to-disk swapping using the "libstxxl" library, which is
faster than just using regular swap space.

daniel

On Mon, Mar 5, 2018 at 11:44 AM, Jose Florido  wrote:

> Hi!
>
> Is it possible to pre-process the planet file with OSRM 5.16.2 and
> only 128Gb ram? We do have a large SSD disk and pre processing doesn’t
> need to be super fast.
>
> Thanks!
> Jose
>
> ___
> 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] Left/Right side of the street?

[Daniel Patterson]

Hi Xavier,

  Yes.  Take a look at the "approaches=curb" parameter - this will force
the routing engine to approach the waypoint on the curb side of the road.
By default, the curb side is the right, but you can modify that in the Lua
profile by changing the "driving_side" property, or if you need to set up
routing data for countries with both, use the `--location-dependent-data
data/driving_side.geojson` parameter to `osrm-extract` to set the
driving-side on a country-by-country basis.

  See the "Request Options" section of the API documentation for details on
how to use the `approaches=` parameter:
http://project-osrm.org/docs/v5.15.2/api/#requests

daniel



On Fri, Mar 2, 2018 at 1:59 PM, Xavier Prudent 
wrote:

> Dear all,
>
> Being a newcomer in OSRM, my question may sound naive :
>
> When requiring for a route between 3 points A, B, C, in a
> drive-on-the-right country.
>
> Can OSRM take into account the fact that B may be on the left side of the
> way?
>
> Thanks,
>
> regards,
>
> Xavier
>
> --
>
> *Xavier Prudent *
>
> *Data Scientist  - Data Mining - Machine Learning*
>
> Web:* www.xavierprudent.com *
> Tel (Québec)  : (514) 668 76 46
> Skype : xavierprudent
>
>
>
> ___
> 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] Feed OSRM with Postgis

[Daniel Patterson]

Hi François,

  Ah.  Well, the step of deduplicating and finding connected nodes will not
go away - OSRM requires a *graph*, not disconnected geometry, so you won't
be able to get away from the problem of turning your LineStrings into
connected data.

  OSM's data structure (ways & nodes) has this structure built in, so OSRM
doesn't contain any of this kind of logic already.

  You might want to look at how pgRouting does this bit (they call it
"building the topology") -
http://docs.pgrouting.org/latest/en/pgRouting-concepts.html#build-a-routing-topology,
there might be some performance tips you can get from their approach.

daniel

On Fri, Mar 2, 2018 at 10:13 AM, François Lacombe <fl.infosrese...@gmail.com
> wrote:

> Hi Daniel,
>
> 2018-03-02 18:31 GMT+01:00 Daniel Patterson <dan...@mapbox.com>:
>
>> Well, it *could* be done.  It would all boil down to providing an
>> alternative for `ParseOSMData` here:
>> That function is responsible for parsing the OSM file, and
>> copying/converting the OSM fields into a memory structure called
>> `ExtractionContainers`:
>>
>
> Thank you, this is really useful information
>
>
>>
>> 0) You'll have to implement it - the core team have other priorities.
>>
>
> That's fair
> I could eventually propose a complete alternative to osrm-extract as to
> clearly separate responsibilities.
>
>
>> 1) I suspect you wouldn't see a huge performance improvement - I
>> suspect the overhead of querying postgis would dominate the extractor time.
>>
>
> I have about 5M ways and 40M nodes.
> Producing xml or pbf takes hours, while querying postgis takes about 3min.
> I would probably agree that the process of postgis output isn't well
> optimized
>
>
>> 2) You'll be on the hook for maintaining this code - the core team
>> haven't built this into the core tool because we don't need it, and it's a
>> big ask for us to maintain something we don't use.
>>
>>   I'd strongly consider trying to optimize your Postgres->OSM extraction
>> process.  Consider using `osmium` libraries to write out the data in PBF
>> form directly instead of XML - it's significantly smaller, which makes it
>> faster to move around and write to disk, and OSRM will import it more
>> quickly.
>>
>
> Problem isn't to get data from postgis, but to organize them as to fit in
> the xml :
> - Creating nodes records, out of Linestrings / polygon geometries
> - Search and deduplicate them, especially when 2 or more ways have nodes
> located on the same lat/lon point. Currently done with a GROUP BY on nodes
> geometry.
> - Create numeric and auto incremented ids since we use uuid in postgis
> (the easy part)
> - Iterate over all of this to produce a xml with Python. Didn't try c++
> libosmium for now but I know i should. That's the longer part in the
> current process.
>
> This takes hours, and I'll be really happy if I find a way to directly
> feed osrm graph without recreating such things.
>
> Simple suppositions:
> It would be so nice to not have to produce nodes out of geometries. It's
> the key point.
> I guess you don't have proper records for each nodes in .osrm files don't
> you ?
> Once they gone through profile's node_process, we only need their
> coordinates and not their tags any more.
> Then it would be great to only send tagged nodes (coming from dedicated
> postgis tables) to osrm-extract.
>
>
> Enjoy your weekend,
>
> François
>
> ___
> 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] Feed OSRM with Postgis

[Daniel Patterson]

Hi François,

Well, it *could* be done.  It would all boil down to providing an
alternative for `ParseOSMData` here:


https://github.com/Project-OSRM/osrm-backend/blob/master/src/extractor/extractor.cpp#L211

That function is responsible for parsing the OSM file, and
copying/converting the OSM fields into a memory structure called
`ExtractionContainers`:

https://github.com/Project-OSRM/osrm-backend/blob/master/include/extractor/extraction_containers.hpp#L23

  If you could populate ExtractionContainers from somewhere else, you'd be
good to go.

  Happy to give advice on how to do this, but:

0) You'll have to implement it - the core team have other priorities.
1) I suspect you wouldn't see a huge performance improvement - I
suspect the overhead of querying postgis would dominate the extractor time.
2) You'll be on the hook for maintaining this code - the core team
haven't built this into the core tool because we don't need it, and it's a
big ask for us to maintain something we don't use.

  I'd strongly consider trying to optimize your Postgres->OSM extraction
process.  Consider using `osmium` libraries to write out the data in PBF
form directly instead of XML - it's significantly smaller, which makes it
faster to move around and write to disk, and OSRM will import it more
quickly.

daniel

On Fri, Mar 2, 2018 at 3:10 AM, François Lacombe 
wrote:

> Hi Daniel,
>
> Despite it's a pretty old thread regarding feeding OSRM with postgis
> geometries, I have new lights to bring up
>
> 2017-11-30 18:09 GMT+01:00 Daniel Hofmann :
>
>> OSRM is a routing engine for OpenStreetMap and the OpenStreetMap extracts
>> usually come in xml or pbf formats.
>>
>
> I find this a bit restrictive and I wonder why it's valuable to stuck osrm
> on osm data only.
> I work for a company which is interested to use osrm as a router for
> public works (not cycling nor car or whatever).
> We have lot of private data we process into a postgresql db in which osm
> data is also imported.
>
> OSM XML file production at the end of our process generate a lot of
> overhead as to feed osrm.
> This doesn't bring advantage at all.
>
>
>> We're using https://github.com/osmcode/libosmium in the osrm-extract
>> binary; you theoretically _could_ switch it out with calls to your database
>> but that will be a bigger lift I guess, and we don't want to add arbitrary
>> data source drivers to OSRM.
>>
>
> We think about creating another connector which would enable osrm-extract
> to get its data directly for pgsql.
> Currently we're not aware of how deep the xml/libosmium is linked to
> osrm-extract binary.
>
> Our use cases enlarge the potential and relevance of osrm in
> industrial/profesionnal use.
> We look to be as constructive as possible and it will be a pleasure to
> share since osrm is great tool.
>
>
> All the best
>
> François
>
>
> ___
> 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] Small ways get small speeds

[Daniel Patterson]

Hi François,

  No, we likely won't change the storage precision any time soon.
OpenStreetMap itself only stores

Here is the constant that OSRM uses to store lon/lat decimal values in
integer format:
https://github.com/Project-OSRM/osrm-backend/blob/master/include/util/coordinate.hpp#L44

We multiply the lon/lat decimal by 1e6 (100), then store just the
integer part. This is equivalent to about 10cm precision at the equator.

*HOWEVER* you can't just change this without also updating the coordinate
vector packing.  It's not a simple change.

OpenStreetmap stores 1 additional decimal place, in the same way (database
stores integers).  Here are the code references.

https://github.com/openstreetmap/openstreetmap-website/blob/master/db/structure.sql#L353-L354
https://github.com/openstreetmap/openstreetmap-website/blob/396f2e28dd27d514f7882c3918103b12764038de/lib/geo_record.rb#L17-L20

Increasing OSRM's storage to match OSM would require more memory usage, and
little obvious gain.

daniel


On Fri, Mar 2, 2018 at 2:57 AM, François Lacombe <fl.infosrese...@gmail.com>
wrote:

> Hi Daniel,
>
> Thank you for answer
> I understand well the issue here
>
> Would it be acceptable to specify coordinates storage precision in a next
> release ?
>
> Nevertheless, I got that it won't impact a lot my routing results.
>
> All the best
>
> François
>
> 2018-02-28 20:37 GMT+01:00 Daniel Patterson <dan...@mapbox.com>:
>
>> Hi François,
>>
>>   What you are seeing is rounding error.
>>
>>   Internally, OSRM only stores the "duration" of each segment, with a
>> resolution of 0.1 seconds.  On the map, the speed is calculated by taking
>> the length of the segment, and dividing it by the "duration" value.
>>
>>   We store longitude/latitude to 6 decimal places, so they have
>> approximately 10cm precision (https://en.wikipedia.org/wiki
>> /Decimal_degrees) depending on your latitude.  This precision means that
>> calculating the length of a segment is limited to +/- approx 10cm precision
>> as well.
>>
>>   Both of these precision limits compound for short segments when
>> displayed on the map, and sometimes the speed values look weird.
>>
>>   However, they do not affect route selection very much, because routing
>> is done by accumulating time, and short segments generally only add small
>> amounts of time to the routing decision.
>>
>> daniel
>>
>>
>>
>> On Wed, Feb 28, 2018 at 10:41 AM, François Lacombe <
>> fl.infosrese...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> While investigating for flaws in a custom profile I'm trying to write, I
>>> discovered that arbitrary small ways got strange speed regarding the rules
>>> I used.
>>>
>>> Here is an extract from osrm-frontend debug
>>> https://imgur.com/a/L8coz
>>>
>>> All segments on the red line have the same attributes.
>>> I don't understand why the small parts in the middle got really slower
>>> speed than the longer ones.
>>> Do you have any idea?
>>>
>>> The purple road with 0km/h speed is normal and expected.
>>>
>>>
>>> Thank you for any hint
>>>
>>> Thanks in advance
>>>
>>> François
>>>
>>> ___
>>> 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
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Small ways get small speeds

[Daniel Patterson]

Hi François,

  What you are seeing is rounding error.

  Internally, OSRM only stores the "duration" of each segment, with a
resolution of 0.1 seconds.  On the map, the speed is calculated by taking
the length of the segment, and dividing it by the "duration" value.

  We store longitude/latitude to 6 decimal places, so they have
approximately 10cm precision (https://en.wikipedia.org/wiki/Decimal_degrees)
depending on your latitude.  This precision means that calculating the
length of a segment is limited to +/- approx 10cm precision as well.

  Both of these precision limits compound for short segments when displayed
on the map, and sometimes the speed values look weird.

  However, they do not affect route selection very much, because routing is
done by accumulating time, and short segments generally only add small
amounts of time to the routing decision.

daniel



On Wed, Feb 28, 2018 at 10:41 AM, François Lacombe <
fl.infosrese...@gmail.com> wrote:

> Hi,
>
> While investigating for flaws in a custom profile I'm trying to write, I
> discovered that arbitrary small ways got strange speed regarding the rules
> I used.
>
> Here is an extract from osrm-frontend debug
> https://imgur.com/a/L8coz
>
> All segments on the red line have the same attributes.
> I don't understand why the small parts in the middle got really slower
> speed than the longer ones.
> Do you have any idea?
>
> The purple road with 0km/h speed is normal and expected.
>
>
> Thank you for any hint
>
> Thanks in advance
>
> François
>
> ___
> 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

[Daniel Patterson]

Hey Kieran,

 Thanks for the update.  I'll try simulating this condition locally and see
if we can get a better error message out of the code here - it'll save
folks time in the future if we don't have to repeat this exercise :-)

daniel

On Fri, Feb 2, 2018 at 4:25 AM, Kieran Caplice <kieran.capl...@temetra.com>
wrote:

> Hi Daniel,
>
> Many thanks for the reply again. An update: turns out when I rebooted the
> machine to fix the issue with running osrm-datastore across different
> users, I had forgotten that changes to /etc/sysctl.conf are not persisted
> after rebooting, so all is working fine now after adding the kernel.shmall
> and kernel.shmmax properties again.
>
> Kind regards,
> Kieran Caplice
>
> On 29/01/18 18:07, Daniel Patterson wrote:
>
> Hi Kieran,
>
>   The problem is definitely occurring when trying to allocate the shared
> memory block.  This line from your strace output shows the error happening:
>
> shmget(0x10001b9, 96772768369, IPC_CREAT|0644) = -1 EINVAL (Invalid
> argument)
>
>   I suspect the "code 21 (EISDIR)" message we're printing out here is
> wrong or misleading, maybe.
>
>   Can you try playing with the constants in this test program?
>
>
> ---BEGIN test.c---
> #include 
> #include 
> #include 
> #include 
> #include 
>
> //#define MEMORY_SIZE 96772768369
> #define MEMORY_SIZE 1024*1024
> #define KEY_PATH "/tmp/osrm.lock"
>
> int main(void) {
>
>   key_t tok = ftok(KEY_PATH, 0);
>
>   // Original that was being called
>   //int result = shmget(0x10001b9, 96772768369, IPC_CREAT|0644);
>
>   int result = shmget(tok, MEMORY_SIZE, IPC_CREAT|0644);
>
>   if (result == -1) {
> printf("shmget returned -1: errno is %d: %s\n", errno,
> strerror(errno));
>   } else {
> printf("shmget worked - cleaning up\n");
> shmctl(result, IPC_RMID, NULL);
>   }
>
> }
> --END test.c-
>
>   Try different values of "MEMORY_SIZE", and also try uncommenting the
> original shmget line that I've included, see if that works standalone, and
> see what messages you get.
>
>   Compiling the test program should be a simple "gcc test.c"
>
> daniel
>
> On Mon, Jan 29, 2018 at 1:48 AM, Kieran Caplice <
> kieran.capl...@temetra.com> wrote:
>
>> Hi Julien/Daniel,
>>
>> Thanks for the replies. I had read that github issue prior to emailing
>> the list, and it did solve the initial error I was having, which was due to
>> running osrm-datastore as root and later as user "osrm". Rebooting the
>> machine solved this as it did for you, Julien. But after that I'm faced
>> with this issue.
>>
>> @Daniel: /tmp contains the two files:
>> -rw-rw-r-- 1 osrm  osrm 0 Jan 26 16:34 osrm-datastore.lock
>> -rw-rw-r-- 1 osrm  osrm 0 Jan 26 16:34 osrm.lock
>>
>> Output of the strace:
>>
>> root@htzh /opt/osrm # su - osrm -c "strace osrm-datastore
>> /opt/osrm/data/planet-latest/planet-latest.osrm"
>> ...
>> open("/opt/osrm/data/planet-latest/planet-latest.osrm.tld", O_RDONLY) = 5
>> read(5, "OSRN\5\17\0M\25\17\0\0\0\0\0\0\1\0\3\0\1\1\3\0\1\0\v\0\1\1\v\0"...,
>> 8191) = 8191
>> close(5)= 0
>> stat("/opt/osrm/data/planet-latest/planet-latest.osrm.partition",
>> 0x7ffcde3c8d20) = -1 ENOENT (No such file or directory)
>> stat("/opt/osrm/data/planet-latest/planet-latest.osrm.cells",
>> 0x7ffcde3c8d20) = -1 ENOENT (No such file or directory)
>> stat("/opt/osrm/data/planet-latest/planet-latest.osrm.cell_metrics",
>> 0x7ffcde3c8d20) = -1 ENOENT (No such file or directory)
>> stat("/opt/osrm/data/planet-latest/planet-latest.osrm.mldgr",
>> 0x7ffcde3c8d20) = -1 ENOENT (No such file or directory)
>> ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
>> ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
>> write(1, "[info] Allocating shared memory "..., 57[info] Allocating
>> shared memory of 96772768369 bytes
>> ) = 57
>> stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
>> stat("/tmp/osrm.lock", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
>> stat("/tmp", {st_mode=S_IFDIR|S_ISVTX|0777, st_size=4096, ...}) = 0
>> stat("/tmp/osrm.lock", {st_mode=S_IFREG|0664, st_size=0, ...}) = 0
>> shmget(0x10001b9, 96772768369, IPC_CREAT|0644) = -1 EINVAL (Invalid
>> argument)
>> ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
>> ioctl(1, TCGETS, {

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

[Daniel Patterson]

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

Re: [OSRM-talk] Released OSRM 5.14.3

[Daniel Patterson]

Hi Mazen,

 Check out https://github.com/Project-OSRM/osrm-text-instructions which
knows how to generate sentences in various languages from the JSON data.

daniel

On Wed, Jan 3, 2018 at 11:30 AM, Mazen Mrad <mkm...@gmail.com> wrote:

> Thanks a lot, now steps are returned, one more request, anyone have a
> javascript code to generate full route instructions  from the steps objects
>
> Mazen
>
> On Wed, Jan 3, 2018 at 7:42 PM, Daniel Patterson <dan...@mapbox.com>
> wrote:
>
>> Hi Mazen,
>>
>>   Please go to http://project-osrm.org/ and click the "Documentation"
>> link on the main page.  This explains how to make requests, what parameters
>> you can supply, and how to interpret the response.
>>
>>   My guess is that you need to add `?steps=true` parameter to your
>> requests - turn-by-turn instructions are not included by default.  Also
>> consider the `overview=full` and `geometries=geojson` options to further
>> expand the response and simplify parsing.
>>
>> daniel
>>
>> On Wed, Jan 3, 2018 at 9:36 AM, Mazen Mrad <mkm...@gmail.com> wrote:
>>
>>> So how to get the direction istructions.. please help
>>>
>>> On 3 Jan 2018 6:37 p.m., "Daniel Patterson" <dan...@mapbox.com> wrote:
>>>
>>>> Hi Mazen,
>>>>
>>>>   You can ignore the hint object, it contains no user-visible data, and
>>>> is not usable on the demoserver.
>>>>
>>>> daniel
>>>>
>>>> On Wed, Jan 3, 2018 at 8:08 AM, Mazen Mrad <mkm...@gmail.com> wrote:
>>>>
>>>>> Greetings;
>>>>>
>>>>> I am performing a route task using OSRM http api, it is working
>>>>> perfectly, but i need to extract the directions instructions and am not
>>>>> able to do it using javascript, the hint object in waypoint array is
>>>>> encrypted.
>>>>>
>>>>> Any idea please it is urgent.
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk <
>>>>> michael.kras...@gmail.com> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> Happy New Year 2018!
>>>>>>
>>>>>> OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
>>>>>> `max_radiuses_map_matching`, change default speed values in Belarus and
>>>>>> Ukraine and fix some bugs. The full list of changes is:
>>>>>>
>>>>>> # 5.14.3
>>>>>>  - Changes from 5.14.2:
>>>>>>- Bugfixes:
>>>>>>   - FIXED #4754: U-Turn penalties are applied to straight turns.
>>>>>>   - FIXED #4756: Removed too restrictive road name check in the
>>>>>> sliproad handler
>>>>>>   - FIXED #4731: Use correct weights for edge-based graph
>>>>>> duplicated via nodes.
>>>>>> - Profile:
>>>>>>   - CHANGED: added Belarus speed limits
>>>>>>   - CHANGED: set default urban speed in Ukraine to 50kmh
>>>>>>
>>>>>> # 5.14.2
>>>>>>  - Changes from 5.14.1:
>>>>>>- Bugfixes:
>>>>>>   - FIXED #4727: Erroring when a old .core file is present.
>>>>>>   - FIXED #4642: Update checks for EMPTY_NAMEID to check for
>>>>>> empty name strings
>>>>>>   - FIXED #4738: Fix potential segmentation fault
>>>>>> - Node.js Bindings:
>>>>>>   - ADDED: Exposed new `max_radiuses_map_matching` option from
>>>>>> `EngingConfig` options
>>>>>> - Tools:
>>>>>>   - ADDED: New osrm-routed `max_radiuses_map_matching` command
>>>>>> line flag to optionally set a maximum radius for map matching
>>>>>>
>>>>>> Regards,
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> 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
>>>>
>>>>
>>> ___
>>> 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
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Released OSRM 5.14.3

[Daniel Patterson]

Hi Mazen,

  Please go to http://project-osrm.org/ and click the "Documentation" link
on the main page.  This explains how to make requests, what parameters you
can supply, and how to interpret the response.

  My guess is that you need to add `?steps=true` parameter to your requests
- turn-by-turn instructions are not included by default.  Also consider the
`overview=full` and `geometries=geojson` options to further expand the
response and simplify parsing.

daniel

On Wed, Jan 3, 2018 at 9:36 AM, Mazen Mrad <mkm...@gmail.com> wrote:

> So how to get the direction istructions.. please help
>
> On 3 Jan 2018 6:37 p.m., "Daniel Patterson" <dan...@mapbox.com> wrote:
>
>> Hi Mazen,
>>
>>   You can ignore the hint object, it contains no user-visible data, and
>> is not usable on the demoserver.
>>
>> daniel
>>
>> On Wed, Jan 3, 2018 at 8:08 AM, Mazen Mrad <mkm...@gmail.com> wrote:
>>
>>> Greetings;
>>>
>>> I am performing a route task using OSRM http api, it is working
>>> perfectly, but i need to extract the directions instructions and am not
>>> able to do it using javascript, the hint object in waypoint array is
>>> encrypted.
>>>
>>> Any idea please it is urgent.
>>>
>>> Thanks
>>>
>>> On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk <
>>> michael.kras...@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Happy New Year 2018!
>>>>
>>>> OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
>>>> `max_radiuses_map_matching`, change default speed values in Belarus and
>>>> Ukraine and fix some bugs. The full list of changes is:
>>>>
>>>> # 5.14.3
>>>>  - Changes from 5.14.2:
>>>>- Bugfixes:
>>>>   - FIXED #4754: U-Turn penalties are applied to straight turns.
>>>>   - FIXED #4756: Removed too restrictive road name check in the
>>>> sliproad handler
>>>>   - FIXED #4731: Use correct weights for edge-based graph
>>>> duplicated via nodes.
>>>> - Profile:
>>>>   - CHANGED: added Belarus speed limits
>>>>   - CHANGED: set default urban speed in Ukraine to 50kmh
>>>>
>>>> # 5.14.2
>>>>  - Changes from 5.14.1:
>>>>- Bugfixes:
>>>>   - FIXED #4727: Erroring when a old .core file is present.
>>>>   - FIXED #4642: Update checks for EMPTY_NAMEID to check for empty
>>>> name strings
>>>>   - FIXED #4738: Fix potential segmentation fault
>>>> - Node.js Bindings:
>>>>   - ADDED: Exposed new `max_radiuses_map_matching` option from
>>>> `EngingConfig` options
>>>> - Tools:
>>>>   - ADDED: New osrm-routed `max_radiuses_map_matching` command line
>>>> flag to optionally set a maximum radius for map matching
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>>
>>>> ___
>>>> 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
>>
>>
> ___
> 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] Released OSRM 5.14.3

[Daniel Patterson]

Hi Mazen,

  You can ignore the hint object, it contains no user-visible data, and is
not usable on the demoserver.

daniel

On Wed, Jan 3, 2018 at 8:08 AM, Mazen Mrad  wrote:

> Greetings;
>
> I am performing a route task using OSRM http api, it is working perfectly,
> but i need to extract the directions instructions and am not able to do it
> using javascript, the hint object in waypoint array is encrypted.
>
> Any idea please it is urgent.
>
> Thanks
>
> On Tue, Jan 2, 2018 at 8:18 PM, Michael Krasnyk  > wrote:
>
>> Hello,
>>
>> Happy New Year 2018!
>>
>> OSRM patch releases 5.14.2 and 5.14.3 add a new parameter
>> `max_radiuses_map_matching`, change default speed values in Belarus and
>> Ukraine and fix some bugs. The full list of changes is:
>>
>> # 5.14.3
>>  - Changes from 5.14.2:
>>- Bugfixes:
>>   - FIXED #4754: U-Turn penalties are applied to straight turns.
>>   - FIXED #4756: Removed too restrictive road name check in the
>> sliproad handler
>>   - FIXED #4731: Use correct weights for edge-based graph duplicated
>> via nodes.
>> - Profile:
>>   - CHANGED: added Belarus speed limits
>>   - CHANGED: set default urban speed in Ukraine to 50kmh
>>
>> # 5.14.2
>>  - Changes from 5.14.1:
>>- Bugfixes:
>>   - FIXED #4727: Erroring when a old .core file is present.
>>   - FIXED #4642: Update checks for EMPTY_NAMEID to check for empty
>> name strings
>>   - FIXED #4738: Fix potential segmentation fault
>> - Node.js Bindings:
>>   - ADDED: Exposed new `max_radiuses_map_matching` option from
>> `EngingConfig` options
>> - Tools:
>>   - ADDED: New osrm-routed `max_radiuses_map_matching` command line
>> flag to optionally set a maximum radius for map matching
>>
>> Regards,
>> Michael
>>
>>
>> ___
>> 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

[OSRM-talk] Fwd: Help

[Daniel Patterson]

Hi Mohamed,

  The OSRM demo server sits behind a CloudFront (https://aws.amazon.com/
cloudfront/) CDN - Cloudfront has a limit of 8192 bytes for HTTP GET
requests (complete HTTP header size, including GET line).  The "Bad
Request" is coming from CloudFront, not OSRM.

  You should round down the coordinates you're passing in - your longitude
value of 2.416965099703

Re: [OSRM-talk] Help

[Daniel Patterson]

Hello Mohamed,

  Can you give an example of the request you're trying?  It's not clear
whether you're doing this against the OSRM demo server, or against your own
installation.

daniel

On Thu, Dec 7, 2017 at 8:16 AM, Mohamed ELHADAD 
wrote:

> Dear sir,
>
> I need to calculate the matrix of distances between 100 GPS.
>
> I tried to use OSRM to dot that, but my request can not be staified when
> the number of GPS coordinates is greater than 12.
> ERRORThe request could not be satisfied.
> --
> Bad request.
>
>
> I would be very grateful if you could help me
>
> Thank you in advance.
>
>
> Best regards
> ᐧ
>
> ___
> 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] Determining which concrete version of OSRM 5.x deployed

[Daniel Patterson]

Hi Kirill,

  No, there is no OSRM HTTP API that will return the version number - your
client will need to tell you what they installed.

daniel

On Thu, Nov 30, 2017 at 12:46 AM, Кирилл Луценко 
wrote:

> Hello everyone!
>
> Our client deployed OSRM 5.x on its production server and now we are
> creating demo-server for test purposes where we would like to have the same
> versions of all software. The problem is that we can't determine which
> concrete version of OSRM deployed (client doesn't remember too). Is there
> any way to find it out? May be OSRM have some undocumented API endpoint
> which return current version or some config file in installation folder
> (Windows) contains version number?
>
> Thanks in advance for any help!
>
> Best regards,
> Kirill
>
> ___
> 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 exactly is "duration" in route service calculated?

[Daniel Patterson]

Hi Gunther,

  You've got the start/end points opposite for those two queries - the
routes aren't the same (and thus, are very different in duration..  If you
swap the start/end points on the OSRM route, you'll get 6.7 minutes as the
result, and the path matches what Google is returning.

  Make sure you zoom in in the UI and make sure the coordinates have
snapped to the same location for both routing engines if you're doing a
comparison.

  To answer the rest of your question, OSRM uses:

1) Tag information available in OpenStreetMap to decide on road speeds.
2) The OSRM demo server *also* has Mapbox traffic data loaded on top

  If you run your own OSRM server, you will just get (1).

  You can read through the script that decides on OSM-based speeds here:
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua
This script looks at tags on OSM ways and decides on a basic speed for
every road.

daniel

On Mon, Nov 27, 2017 at 9:41 AM, Günther S  wrote:

> Hi there,
>
> I would like to know how the "duration" is calculated exactly.
> What is the data basis for this calculation?
> - predefined speed per segment (where to get that speed)?
> - is real traffic information somehow considered?
>
> For instance:
> this request returns 1037.9sec = 17.3 min
> http://router.project-osrm.org/route/v1/driving/5.39952890748535,52.
> 1960411446193;5.4446426827156,52.1682341727178?overview=false
>
>
> on the other hand, google calculates 7min for the fastest route:
> https://www.google.at/maps/dir/52.1682341727178+5.
> 4446426827156/52.1960411,5.3995289/@52.1889039,5.387444,
> 14z/data=!3m1!4b1!4m7!4m6!1m3!2m2!1d5.4446427!2d52.1682342!1m0!3e0?hl=en
>
> thanks,
> Guenther
>
> ___
> 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] Some questions

[Daniel Patterson]

Hi Gandalf,

  1) If you edit `car.lua`, you can turn off the "exclusions",
  which will save some memory (perhaps 20%).  Other than that,
  not really.  If you pre-process using `car.lua`, you'll only get
  datafiles that are useful for car driving, it doesn't care about
  truck/walk/other restrictions.  In theory yes, much of the data
  isn't needed, but OSRM currently doesn't support *not* loading
  everything.

  2) There is no built-in isochrone service.  I assume you're looking
   for GeoJSON polygons that contour away from the start point?
  There are some WIP pull requests for isochrones (take a look
  at the active pull requests), but nothing in the main codeline yet.
  You can also generate them client-side using an approach like this:

https://blog.mapbox.com/add-isochrones-to-your-next-application-e9e84a62345f
  which uses the `table` plugin, instead of the route plugin.

  In general though, consider simply requesting the actual routes from
OSRM -
  they're generated pretty fast, even for interactive use.

3) The simplest way is to pre-merge the OSM datafiles using something
like
http://docs.osmcode.org/osmium/latest/osmium-merge.html

The only alternative would be to run several OSRM servers on
different
HTTP ports, and create a proxy in front that looks at the request
coordinates
and directs each request to the appropriate map.  No such thing
comes
with OSRM however, you'll need to build it yourself.

4) The osrm-routed memory usage depends on the size of your map.  For
the planet,
 with the car profile, it's in the order of 60-70GB.

5) Yes, `osrm-routed` supports seamless dataswaps.  Use `osrm-datastore
`
to load your data into shared memory, then run `osrm-routed -s` to
tell `osrm-routed`
to look in shared memory instead of loading files itself.
You can then replace the shared memory data with another invocation
of
`osrm-datastore `, and `osrm-routed` will seamlessly
swap to the
new dataset.
Note that you will need sufficient RAM to hold both sets of data in
memory during
the swapover.

daniel

On Wed, Nov 22, 2017 at 11:09 AM, Gandalf Corvotempesta <
gandalf.corvotempe...@gmail.com> wrote:

> Hi to all
> for a project, I have to calculate distance and travel time between 2
> points.
> I've tried, with success, OSRM. Some questions:
>
> 1) can I strip down as much as possible to keep the memory usage low ?
> I don't need any restricted turns for trucks and so on,
> the only needed profile is "car" and I only need to fetch distance and
> time, even directions are not needed.
>
> 2) would be possible to return a GeoJSON (or any other format) with
> isochrones from a defined point ? I would use this to pre-calculate an
> estimated travel time between points.
>
> 3) how can I load multiple maps with osrm-routed ?
>
> 4) which is the memory usage for osrm-routed ? I've pre-processed the
> maps on a huge computer and then i'm running osrm-routed on a server.
> Is that the sum of all *.osrm.* files ?
>
> 5) in case of map updates, can I "reload" osrm-routed without restarting
> it ?
>
> Thank you in advange.
>
> ___
> 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 demoserver update

[Daniel Patterson]

The swapover has been completed.  Please open tickets if you see any
server-move problems crop up.

daniel

On Fri, Oct 27, 2017 at 5:14 PM, Daniel Patterson <dan...@mapbox.com> wrote:

> Hi everyone,
>
>   As most of you have probably noticed, the OSRM demoserver has been
> pretty unreliable over the last few months.
>
>   This weekend, I'm going to migrate it to live alongside our production
> infrastructure here at Mapbox.  This means it'll get redundancy and
> monitoring!
>
>   I'm hoping the transition is mostly seamless, but there will be a few
> changes you may notice:
>
> 1. We'll be switching from `osrm.routed`, to `osrm-routed.js` (
> https://github.com/Project-OSRM/osrm-backend/pull/4604).  I've tried my
> best to make it fully compatible, but, well, there are always bugs.
> 2. The demoserver will only run stable releases, it will no longer run
> from master.
> 3. The dataset is a slightly modified car.lua, *plus* Mapbox's
> freeflow traffic data over the top - this should give more accurate ETAs in
> areas where Mapbox has traffic coverage than plain car.lua.
> 4. Hints are disabled on the new setup - the hint= parameter is
> accepted but ignored.  This is because we're cycling the dataset every few
> hours behind the scenes, hints get invalidated quickly.
> 5. The demoserver will have a service-wide rate limit of 5000
> req/minute.  Looking at past logs, it stays below this about 98% of the
> time, but be prepared for HTTP 429 responses, and be aware that heavy usage
> may cause rate limiting for everyone else if you flood the server.
> 6. Some error messages will change - this is mostly the result of the
> switch from osrm-routed to osrm-routed.js and using a different URL parsing
> library.
>
>   I plan on doing the switchover starting now - there may be some DNS
> outage required while I do the reconfiguration.  Once the swapover is done,
> the hope is that we'll have a much more reliable service that costs us less
> money to operate.
>
>   If you notice any weirdness that seem the result of the switchover,
> please open tickets in the osrm-backend project.
>
> daniel
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSRM-talk] OSRM demoserver update

[Daniel Patterson]

Hi everyone,

  As most of you have probably noticed, the OSRM demoserver has been pretty
unreliable over the last few months.

  This weekend, I'm going to migrate it to live alongside our production
infrastructure here at Mapbox.  This means it'll get redundancy and
monitoring!

  I'm hoping the transition is mostly seamless, but there will be a few
changes you may notice:

1. We'll be switching from `osrm.routed`, to `osrm-routed.js` (
https://github.com/Project-OSRM/osrm-backend/pull/4604).  I've tried my
best to make it fully compatible, but, well, there are always bugs.
2. The demoserver will only run stable releases, it will no longer run
from master.
3. The dataset is a slightly modified car.lua, *plus* Mapbox's freeflow
traffic data over the top - this should give more accurate ETAs in areas
where Mapbox has traffic coverage than plain car.lua.
4. Hints are disabled on the new setup - the hint= parameter is
accepted but ignored.  This is because we're cycling the dataset every few
hours behind the scenes, hints get invalidated quickly.
5. The demoserver will have a service-wide rate limit of 5000
req/minute.  Looking at past logs, it stays below this about 98% of the
time, but be prepared for HTTP 429 responses, and be aware that heavy usage
may cause rate limiting for everyone else if you flood the server.
6. Some error messages will change - this is mostly the result of the
switch from osrm-routed to osrm-routed.js and using a different URL parsing
library.

  I plan on doing the switchover starting now - there may be some DNS
outage required while I do the reconfiguration.  Once the swapover is done,
the hope is that we'll have a much more reliable service that costs us less
money to operate.

  If you notice any weirdness that seem the result of the switchover,
please open tickets in the osrm-backend project.

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

Re: [OSRM-talk] Expecting time for osrm-contract for planet

[Daniel Patterson]

OSRM pre-processing is kind of worst-case for disk swapping - it does a lot
of random access, so if you run out of RAM, pages will get continuously
swapped in/out.  The slowdown between RAM-only and swap-on-SSD can be 50x
or more.  The difference between swap on a spinning disk and an SSD is a
good 10x on top of that.

If you can, avoid letting OSRM pre-processing touch swap at all costs -
it's worth renting a big machine on AWS/Google/Azure for a short time to
pre-process the data.

daniel

On Fri, Sep 22, 2017 at 7:14 AM, Sayer, Bryan <bsa...@s-3.com> wrote:

> Just as a point of reference, you mention that avoiding swapping and just
> using RAM will be much faster. If the swap space is an SSD drive, how much
> does using only RAM speed up contract? That is, what is the difference
> between using say a 7200 rpm SATA drive versus an SSD drive make?
> ------
> *From:* Daniel Patterson <dan...@mapbox.com>
> *Sent:* Friday, September 22, 2017 8:05:56 AM
> *To:* Mailing list to discuss Project OSRM
> *Subject:* Re: [OSRM-talk] Expecting time for osrm-contract for planet
>
> Hi Kieran,
>
>   We don't, but I've done some profiling in the past, Docker itself should
> have negligible impact.
>
>   The two things that might be slowing things down:
>
> 1) The docker images don't bundle jemalloc (http://jemalloc.net/),
> which can speed things up by 10-15%
> 2) osrm-contract is very CPU intensive - the more threads you give it,
> the faster it will run.  Give it more if you can.
>
>  256GB of RAM should be more than enough to avoid swapping, but you might
> want to disable swap to be sure - if it's being used, it will have a huge
> impact on speed.
>
> daniel
>
> On Fri, Sep 22, 2017 at 2:30 AM, Kieran Caplice <
> kieran.capl...@temetra.com> wrote:
>
>> Hi Daniel,
>> Can you clarify if you use Docker at Mapbox? What kind of server do you
>> guys have (if not the one described on the wiki page)?
>>
>> Over night, the process has gone to just 75% complete from 65% yesterday
>> - 41 hours in total now, and back to maxing CPU again.
>>
>> Kind regards,
>> Kieran Caplice
>>
>> On 21/09/17 17:17, Daniel Patterson wrote:
>>
>> OSRM supports *two* core routing algorithms - CH and MLD.  The
>> `osrm-contract` tool generates the CH dataset, but you can use the MLD
>> pipeline instead with:
>>
>> osrm-extract -p profiles/bicycle.lua yourmap.osm.pbf
>> osrm-partition yourmap.osrm
>> osrm-customize yourmap.osrm
>> osrm-routed -a MLD yourmap.osrm
>>
>> This sequence of tools should be significantly quicker than osrm-contract
>> - the price you pay is that routing requests are about 5x slower (still
>> pretty fast though!).  The reason that MLD exists is for the
>> `osrm-customize` step - it allows you to import traffic data very quickly
>> and update the routing graph (~1 minute for North America).
>>
>> It's hard to say exactly what's going wrong with osrm-contract here -
>> here at Mapbox, we daily run `osrm-contract` over the latest planet with
>> the bicycle profile without a problem, however, Alex and others have
>> reported issues with what seem like hangs on much smaller datasets that
>> we've been unable to reproduce so far.
>>
>> The runtime of osrm-contract is affected by how much hierarchy exists in
>> the data - the more similar the edge speeds (like in foot) and the more
>> edges there are, the slower it gets, often in a non-linear fashion.  The
>> car profile has a very hierarchical structure (many different road speeds),
>> so it fits well into the CH, the construction algorithm  doesn't need to
>> compare as many options.
>>
>> daniel
>>
>> On Thu, Sep 21, 2017 at 9:03 AM, Kieran Caplice <
>> kieran.capl...@temetra.com> wrote:
>>
>>> We're actually looking for the best of both car and foot, so in my head,
>>> bicycle would be the happy medium (though I could be completely wrong on
>>> this).
>>> Kind regards,
>>> Kieran Caplice
>>>
>>> On 21/09/17 16:53, Alex Farioletti wrote:
>>>
>>> i've run into the same issues, and now i just use metroextracts of the
>>> areas that i need for the bike stuff i do and it reduces the time
>>> significantly
>>>
>>> *Alex Farioletti*
>>> *415.312.1674*
>>> *tcbcourier.com <http://tcbcourier.com> *
>>>
>>> On Thu, Sep 21, 2017 at 8:49 AM, Kieran Caplice <
>>> kieran.capl...@temetra.com> wrote:
>>>
>>>> Thanks Daniel.
>>>>
>>>> I'm using the bicycle p

Re: [OSRM-talk] Expecting time for osrm-contract for planet

[Daniel Patterson]

Hi Kieran,

  We don't, but I've done some profiling in the past, Docker itself should
have negligible impact.

  The two things that might be slowing things down:

1) The docker images don't bundle jemalloc (http://jemalloc.net/),
which can speed things up by 10-15%
2) osrm-contract is very CPU intensive - the more threads you give it,
the faster it will run.  Give it more if you can.

 256GB of RAM should be more than enough to avoid swapping, but you might
want to disable swap to be sure - if it's being used, it will have a huge
impact on speed.

daniel

On Fri, Sep 22, 2017 at 2:30 AM, Kieran Caplice <kieran.capl...@temetra.com>
wrote:

> Hi Daniel,
> Can you clarify if you use Docker at Mapbox? What kind of server do you
> guys have (if not the one described on the wiki page)?
>
> Over night, the process has gone to just 75% complete from 65% yesterday -
> 41 hours in total now, and back to maxing CPU again.
>
> Kind regards,
> Kieran Caplice
>
> On 21/09/17 17:17, Daniel Patterson wrote:
>
> OSRM supports *two* core routing algorithms - CH and MLD.  The
> `osrm-contract` tool generates the CH dataset, but you can use the MLD
> pipeline instead with:
>
> osrm-extract -p profiles/bicycle.lua yourmap.osm.pbf
> osrm-partition yourmap.osrm
> osrm-customize yourmap.osrm
> osrm-routed -a MLD yourmap.osrm
>
> This sequence of tools should be significantly quicker than osrm-contract
> - the price you pay is that routing requests are about 5x slower (still
> pretty fast though!).  The reason that MLD exists is for the
> `osrm-customize` step - it allows you to import traffic data very quickly
> and update the routing graph (~1 minute for North America).
>
> It's hard to say exactly what's going wrong with osrm-contract here - here
> at Mapbox, we daily run `osrm-contract` over the latest planet with the
> bicycle profile without a problem, however, Alex and others have reported
> issues with what seem like hangs on much smaller datasets that we've been
> unable to reproduce so far.
>
> The runtime of osrm-contract is affected by how much hierarchy exists in
> the data - the more similar the edge speeds (like in foot) and the more
> edges there are, the slower it gets, often in a non-linear fashion.  The
> car profile has a very hierarchical structure (many different road speeds),
> so it fits well into the CH, the construction algorithm  doesn't need to
> compare as many options.
>
> daniel
>
> On Thu, Sep 21, 2017 at 9:03 AM, Kieran Caplice <
> kieran.capl...@temetra.com> wrote:
>
>> We're actually looking for the best of both car and foot, so in my head,
>> bicycle would be the happy medium (though I could be completely wrong on
>> this).
>> Kind regards,
>> Kieran Caplice
>>
>> On 21/09/17 16:53, Alex Farioletti wrote:
>>
>> i've run into the same issues, and now i just use metroextracts of the
>> areas that i need for the bike stuff i do and it reduces the time
>> significantly
>>
>> *Alex Farioletti*
>> *415.312.1674*
>> *tcbcourier.com <http://tcbcourier.com> *
>>
>> On Thu, Sep 21, 2017 at 8:49 AM, Kieran Caplice <
>> kieran.capl...@temetra.com> wrote:
>>
>>> Thanks Daniel.
>>>
>>> I'm using the bicycle profile, so I would expect based on what you've
>>> said that somewhere up to 36 hours would be likely. However, this is the
>>> current output, after 25h40m:
>>> [info] Input file: /data/1505492056/planet-latest.osrm
>>> [info] Threads: 12
>>> [info] Reading node weights.
>>> [info] Done reading node weights.
>>> [info] Loading edge-expanded graph representation
>>> [info] merged 2379332 edges out of 1777752432
>>> [info] initializing node priorities... ok.
>>> [info] preprocessing 389797971 (90%) nodes...
>>> [info] . 10% . 20% . 30% . 40% . 50% . 60%
>>>
>>> It hasn't advanced past 60% in the last 2-3 hours. It is however maxing
>>> CPU and using approximately the same amount of RAM since it started.
>>>
>>> Kind regards,
>>> Kieran Caplice
>>>
>>> On 21/09/17 16:39, Daniel Patterson wrote:
>>>
>>> Hi Kieran,
>>>
>>>   The contraction time will be slow - many, many hours for the whole
>>> planet.  *Typically* for the car profile it's about 12 hours, but if you
>>> use bike or foot, or your own profile, it can get a lot bigger.
>>>
>>>   If you've messed with the travel speeds, that can have a big effect
>>> too.  24 hours is not unheard of, but whether it's legit will depend a lot
>>> on the details.
>>>
>>> daniel
>&g

Re: [OSRM-talk] Routing on HOV lanes

[Daniel Patterson]

Yes, this behaviour is baked into the dataset during the "pre-processing"
step - you can't currently modify it at query time on the demo server.

If you need this behaviour, you have two options:

  1) Remove HOV lanes from the avoid list here:
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L119
and process your own dataset

  2) With a bit of work, you could possibly make this query-time selectable
by adding support for a new "hov-only" road class here:
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/lib/guidance.lua#L63,
then adding an exclude capability for that class here:
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L107

Both of these options require you to generate your own datasets and run
your own server.

daniel

On Thu, Sep 21, 2017 at 9:04 AM, Jason Dalton 
wrote:

>
> the OSRM demos all avoid I66E during the HOV period.   Is that how the
> demo is specifically set up, and is there a config that allows HOV travel?
>
> https://www.mapbox.com/get-directions/#12.18/38.8522/-77.
> 1488?coordinates=-77.26192144623029,38.86860868389613;-77.05189,38.848834
>
> http://map.project-osrm.org/?z=15=38.876150%2C-77.
> 219124=38.871690%2C-77.261438=38.848625%2C-77.051612=en=0
>
>
>
> ___
> 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] Expecting time for osrm-contract for planet

[Daniel Patterson]

OSRM supports *two* core routing algorithms - CH and MLD.  The
`osrm-contract` tool generates the CH dataset, but you can use the MLD
pipeline instead with:

osrm-extract -p profiles/bicycle.lua yourmap.osm.pbf
osrm-partition yourmap.osrm
osrm-customize yourmap.osrm
osrm-routed -a MLD yourmap.osrm

This sequence of tools should be significantly quicker than osrm-contract -
the price you pay is that routing requests are about 5x slower (still
pretty fast though!).  The reason that MLD exists is for the
`osrm-customize` step - it allows you to import traffic data very quickly
and update the routing graph (~1 minute for North America).

It's hard to say exactly what's going wrong with osrm-contract here - here
at Mapbox, we daily run `osrm-contract` over the latest planet with the
bicycle profile without a problem, however, Alex and others have reported
issues with what seem like hangs on much smaller datasets that we've been
unable to reproduce so far.

The runtime of osrm-contract is affected by how much hierarchy exists in
the data - the more similar the edge speeds (like in foot) and the more
edges there are, the slower it gets, often in a non-linear fashion.  The
car profile has a very hierarchical structure (many different road speeds),
so it fits well into the CH, the construction algorithm  doesn't need to
compare as many options.

daniel

On Thu, Sep 21, 2017 at 9:03 AM, Kieran Caplice <kieran.capl...@temetra.com>
wrote:

> We're actually looking for the best of both car and foot, so in my head,
> bicycle would be the happy medium (though I could be completely wrong on
> this).
> Kind regards,
> Kieran Caplice
>
> On 21/09/17 16:53, Alex Farioletti wrote:
>
> i've run into the same issues, and now i just use metroextracts of the
> areas that i need for the bike stuff i do and it reduces the time
> significantly
>
> *Alex Farioletti*
> *415.312.1674*
> *tcbcourier.com <http://tcbcourier.com> *
>
> On Thu, Sep 21, 2017 at 8:49 AM, Kieran Caplice <
> kieran.capl...@temetra.com> wrote:
>
>> Thanks Daniel.
>>
>> I'm using the bicycle profile, so I would expect based on what you've
>> said that somewhere up to 36 hours would be likely. However, this is the
>> current output, after 25h40m:
>> [info] Input file: /data/1505492056/planet-latest.osrm
>> [info] Threads: 12
>> [info] Reading node weights.
>> [info] Done reading node weights.
>> [info] Loading edge-expanded graph representation
>> [info] merged 2379332 edges out of 152432
>> [info] initializing node priorities... ok.
>> [info] preprocessing 389797971 (90%) nodes...
>> [info] . 10% . 20% . 30% . 40% . 50% . 60%
>>
>> It hasn't advanced past 60% in the last 2-3 hours. It is however maxing
>> CPU and using approximately the same amount of RAM since it started.
>>
>> Kind regards,
>> Kieran Caplice
>>
>> On 21/09/17 16:39, Daniel Patterson wrote:
>>
>> Hi Kieran,
>>
>>   The contraction time will be slow - many, many hours for the whole
>> planet.  *Typically* for the car profile it's about 12 hours, but if you
>> use bike or foot, or your own profile, it can get a lot bigger.
>>
>>   If you've messed with the travel speeds, that can have a big effect
>> too.  24 hours is not unheard of, but whether it's legit will depend a lot
>> on the details.
>>
>> daniel
>>
>> On Thu, Sep 21, 2017 at 7:00 AM, Kieran Caplice <
>> kieran.capl...@temetra.com> wrote:
>>
>>> Hi all,
>>>
>>> Could anyone give an approx estimate for the time required to run the
>>> osrm-contract on planet data on a 12 thread, 256 GB RAM, SSD machine?
>>>
>>> The osrm-extract process finished in 232 minutes, but the contract has
>>> now been running solid for 24 hours, and appears to be stuck at 60% on
>>> "preprocessing nodes". All 12 cores are generally maxed out, and the
>>> process is using nearly 90 GB of RAM.
>>>
>>> This is the second time I've run the contract process, as my SSH
>>> connection to the server dropped the first time and the process wasn't
>>> running in a screen etc, so I assumed after the 40-odd hours it was running
>>> for, the connection drop caused it to hang, but now I'm not so sure. Were
>>> there any files I should maybe have cleared before trying to run it again?
>>>
>>> I'm using the docker image to run the command (using
>>> osrm/osrm-backend:latest): time docker run -t -v /opt/osrm/data:/data
>>> osrm/osrm-backend osrm-contract /data/1505492056/planet-latest.osrm
>>>
>>> Kind regards,
>>> Kieran Caplic

Re: [OSRM-talk] Expecting time for osrm-contract for planet

[Daniel Patterson]

Hi Kieran,

  The contraction time will be slow - many, many hours for the whole
planet.  *Typically* for the car profile it's about 12 hours, but if you
use bike or foot, or your own profile, it can get a lot bigger.

  If you've messed with the travel speeds, that can have a big effect too.
 24 hours is not unheard of, but whether it's legit will depend a lot on
the details.

daniel

On Thu, Sep 21, 2017 at 7:00 AM, Kieran Caplice 
wrote:

> Hi all,
>
> Could anyone give an approx estimate for the time required to run the
> osrm-contract on planet data on a 12 thread, 256 GB RAM, SSD machine?
>
> The osrm-extract process finished in 232 minutes, but the contract has now
> been running solid for 24 hours, and appears to be stuck at 60% on
> "preprocessing nodes". All 12 cores are generally maxed out, and the
> process is using nearly 90 GB of RAM.
>
> This is the second time I've run the contract process, as my SSH
> connection to the server dropped the first time and the process wasn't
> running in a screen etc, so I assumed after the 40-odd hours it was running
> for, the connection drop caused it to hang, but now I'm not so sure. Were
> there any files I should maybe have cleared before trying to run it again?
>
> I'm using the docker image to run the command (using
> osrm/osrm-backend:latest): time docker run -t -v /opt/osrm/data:/data
> osrm/osrm-backend osrm-contract /data/1505492056/planet-latest.osrm
>
> 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

Re: [OSRM-talk] OSRM 5.11 Profile

[Daniel Patterson]

Hi Frank,

  That's the only thing you need to change in the car profile - it triggers
setting the `rate` to 1, which means routing becomes distance based.

  I believe the same applies to the foot profile, they share much of the
same Lua code.

daniel

On Thu, Aug 31, 2017 at 8:34 AM, Frank Durstewitz 
wrote:

> Hello list,
>
> I want to know what to change in car/foot profile to get shortest route,
> not fastest.
>
>
> From
>
> https://github.com/Project-OSRM/osrm-backend/blob/bc8617a9f4
> 4dd194467bd924fbfbaa9840f462a9/docs/profiles.md#understandin
> g-speed-weight-and-rate
>
> i understand i have to change properties.weight_name from 'routability' to
> 'distance' in car.lua and foot.lua (for OSRM 5.11).
>
> Is this the only required change? If not, what else i have to change?
>
> Kindly regards,
>
> Frank
>
> ___
> 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] (no subject)

[Daniel Patterson]

Hi Jason,

  Depends on what you want to achieve.  Travel modes are used for a couple
of things:

1) For car routing, we primarily use two modes - normal, and ferry
mode.  This affects how the routing costs are calculated.
2) For the bike profile, the modes end up in the instructions -
sometimes we suggest that you walk your bike.

  Do you need to actually announce mode changes to the user, or do you just
need to identify different modes in order to calculate routing costs?

daniel

On Tue, Aug 29, 2017 at 1:50 PM, Jason Dalton 
wrote:

> Hi,
>
> I’m working on a custom routing app and need to apply some custom routing
> rules in OSRM.  Is there a mechanism to add a mode of travel?  or would I
> need to ‘reuse’ one of the existing modes?   For instance, if I wanted to
> create routing rules for ATVs, could I create an “ATV" mode of travel in
>  OSRM or would I need to use the normal vehicle routing and modify the
> source data on my own instance?
>
> Thanks,
> Jason
>
>
>
> ___
> 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] Use OSRM on rivers, railways, power lines

[Daniel Patterson]

Hi François,

  Currently, OSRM doesn't know anything about route relations (although
some work has started on it here:
https://github.com/Project-OSRM/osrm-backend/pull/4438).

  For now, you'd need to convert them to separate ways, or copy the
relation tags onto the relevant ways so that the `process_way` Lua function
will be able to see the tags.  Flattening relations like this can be
complicated, I don't know if there's an easy-to-use tool that can already
do it.

daniel

On Sun, Aug 27, 2017 at 10:59 PM, François Lacombe <
fl.infosrese...@gmail.com> wrote:

> Hi Daniel,
>
> This is indeed an interesting point.
>
> In substations, every incoming line is often connected to busbars, which
> allow to switch power from lines to another.
> They are supposed to be in OSM when outdoor and visible on aerial imagery
> like this one : http://www.openstreetmap.org/way/170169821
>
> Then I'd better to propagate substation attributes on its busbars and then
> define them as is_starting=true
> If I don't find them in OSM data, it's pretty easy to create a virtual one
> by linking every incoming line end point.
>
>
> Once the is_starting problem solved, can osrm understand directly route
> relation like the one given in my first mail :
> http://www.openstreetmap.org/relation/6694740
> Or should I convert them in separate ways before building osrm network ?
>
>
> All the best
>
> François
>
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>
> 2017-08-25 18:04 GMT+02:00 Daniel Patterson <dan...@mapbox.com>:
>
>> Hi François,
>>
>>   The only problem I can see is that OSRM only snaps to *edges*, not
>> nodes, and the `is_startpoint` property is only available for ways, not
>> nodes.
>>
>>   If you insert new artificial ways that connect the centroid to each
>> line and have different tags and can be marked as `is_startpoint=true`,
>> then it will work fine.  If you simply extend the powerlines by adding an
>> additional noderef to the powerline ways, then you'll still have the
>> nothing-to-snap-to problem.
>>
>> daniel
>>
>> On Thu, Aug 24, 2017 at 11:58 PM, François Lacombe <
>> fl.infosrese...@gmail.com> wrote:
>>
>>> Hi Daniel,
>>>
>>> Ok,
>>>
>>> Or I can take the centroid of each substation area and connect each line
>>> to it.
>>> Then, drop the area and only keep substations nodes which get the
>>> is_startpoint in the profile.
>>>
>>> On render side, I will surely be able to match substation nodes given by
>>> osrm and actual areas with ref tags.
>>>
>>> I'll be testing it for some times and will share it if interested
>>> Thank you for your time
>>>
>>>
>>> All the best
>>>
>>>
>>> 2017-08-25 0:04 GMT+02:00 Daniel Patterson <dan...@mapbox.com>:
>>>
>>>> Yes, connectivity will be a problem in that example.  If you make the
>>>> lines `is_startpoint=false` and they're not connected to something else,
>>>> then you won't be able to route over them.
>>>>
>>>> You will need to do some pre-processing here - create artificial nodes
>>>> at the points where the substation boundaries cross the lines and connect
>>>> both ways to those artificial nodes.
>>>>
>>>> daniel
>>>>
>>>> On Thu, Aug 24, 2017 at 2:33 PM, François Lacombe <
>>>> fl.infosrese...@gmail.com> wrote:
>>>>
>>>>>
>>>>> 2017-08-24 23:18 GMT+02:00 Daniel Patterson <dan...@mapbox.com>:
>>>>>
>>>>>> Franccois,
>>>>>>
>>>>>>   In the lua profiles, you can set the `result.is_startpoint`
>>>>>> property in `process_way` (used to be `way_function`) to determine 
>>>>>> whether
>>>>>> you can snap to them.  We currently use this for ferry routes - paths can
>>>>>> use them, but can't start/end on them.
>>>>>>
>>>>>>   Set `is_startpoint` to true for your substations way areas, and
>>>>>> `is_startpoint` to false for the transmission lines.
>>>>>>
>>>>>
>>>>> That's exactly what I need, thank you
>>>>>
>>>>>
>>>>>>   The route will start by following the outside edge of the
>>>>>> substations area polygon, but it sounds like that doesn't matter too much
>

Re: [OSRM-talk] Access private roads in routing

[Daniel Patterson]

Hi,

  Unfortunately no - OSRM is designed to perform very fast route
calculation, at the expense of flexibility.  Whether private roads are
allowed is decided during the "pre-processing" step, and you cannot alter
that decision when you query a route.

  You would need to run your own OSRM server and modify the `car.lua`
profile to include the road classes you want.  The demo server at
router.project-osrm.org uses the default car.lua profile (which you can
find in the GitHub repository).

daniel

On Mon, Aug 28, 2017 at 7:03 AM, Chuan Li (C)  wrote:

> Hello all,
>
>
>
> Is there a parameter that I can specify to allow OSRM to route through
> private (proprietary) roads?  I wish to use this URL to send request for
> test purpose. (http://router.project-osrm.org/route/v1/driving/)
>
>
>
> Best regards,
>
> Chuan Li
>
>
>
>
> Nothing in this message is intended to constitute an electronic signature
> unless a specific statement to the contrary is included in this message.
>
> Confidentiality Note: This message is intended only for the person or
> entity to which it is addressed. It may contain confidential and/or
> privileged material. Any review, transmission, dissemination or other use,
> or taking of any action in reliance upon this message by persons or
> entities other than the intended recipient is prohibited and may be
> unlawful. If you received this message in error, please contact the sender
> and delete it from your computer.
>
> ___
> 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] Use OSRM on rivers, railways, power lines

[Daniel Patterson]

Franccois,

  In the lua profiles, you can set the `result.is_startpoint` property in
`process_way` (used to be `way_function`) to determine whether you can snap
to them.  We currently use this for ferry routes - paths can use them, but
can't start/end on them.

  Set `is_startpoint` to true for your substations way areas, and
`is_startpoint` to false for the transmission lines.

  The route will start by following the outside edge of the substations
area polygon, but it sounds like that doesn't matter too much to you.

daniel


On Thu, Aug 24, 2017 at 1:40 PM, François Lacombe  wrote:

> Hi Daniel, Ricardo,
>
> Thank you for your answers.
>
> I completely agree on necessity of perfect connectivity between features.
> It has been a concern for me regarding power networks for years of
> contribution now.
>
> The challenge is currently to adapt car profile to power lines
> Voltage may act as the maxspeed key, and transformers as toll
>
> As you may see in the relation example I gave, there is two substations at
> the ends of line members.
> Differently from roads or rivers, you can't connect to power lines or
> pipelines anywhere. Start and end into substations is mandatory
> (power=substation or pipeline=substation, they are both areas)
> How can I told osrm to look for the nearest substation before starting
> routing in the graph exclusively composed of power lines or pipelines ?
>
> Guidance information isn't so relevant in such networks, then I will only
> focus on osrm path answer
>
> François
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux 
>
> 2017-08-24 18:52 GMT+02:00 Ricardo Pereira :
>
>> We use OSRM to route within water only (Oceans and Rivers). It makes
>> absolute no difference what you are routing through as long as you can
>> provide a mesh with your topology.
>> Our Lua script therefore matches the tags that we create for own data,
>> nothing to do with OSM.
>>
>> Cheers
>>
>> On Thu, 24 Aug 2017 at 16:15 François Lacombe 
>> wrote:
>>
>>> Hi all,
>>>
>>> Since there is not only roads but many other topological networks mapped
>>> on OSM, I'm wondering how osrm may be usable on them.
>>>
>>> Example : a power route used to establish a link between two substations
>>> http://www.openstreetmap.org/relation/6694740
>>>
>>> I know pretty well how lua profiles are built, for cars, bike,
>>> pedestrian... but is there any profile available for power or gas pipelines?
>>> Let's say we have proper data, is the profile the only thing to change
>>> to use osrm on pipelines or rivers exclusively ?
>>>
>>> Many thanks for any answer regarding this question
>>>
>>>
>>> François
>>> ___
>>> 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
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Use OSRM on rivers, railways, power lines

[Daniel Patterson]

Hi Francois,

  In theory, yes, you could route on powerlines, gas lines, or any other
linear feature.  Ensuring connectivity could be problematic - often rivers
are not connected to paths in OSM.

  Waterways are a bit problematic as they're often modeled as areas - if
you modify the Lua script to include them in the routing graph, OSRM will
route around the edges of the polygon.

  Getting proper connectivity between all the elements you want to route
between can be problematic as well - very often, rivers/rail are not
connected to roads or paths inside OSM.

  The turn-by-turn instructions might also be a bit weird if you don't
route on roads/paths - the guidance code has been mostly focused on
sensible instructions for drivers.

daniel

On Thu, Aug 24, 2017 at 6:27 AM, François Lacombe  wrote:

> Hi all,
>
> Since there is not only roads but many other topological networks mapped
> on OSM, I'm wondering how osrm may be usable on them.
>
> Example : a power route used to establish a link between two substations
> http://www.openstreetmap.org/relation/6694740
>
> I know pretty well how lua profiles are built, for cars, bike,
> pedestrian... but is there any profile available for power or gas pipelines?
> Let's say we have proper data, is the profile the only thing to change to
> use osrm on pipelines or rivers exclusively ?
>
> Many thanks for any answer regarding this question
>
>
> François
>
> ___
> 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] start/goal link exclude or include ?

[Daniel Patterson]

Currently no.  The coordinate snapping only considers distance and
direction, you cannot select a subset of snapping candidates.

How do you imagine it would work?

daniel


On Wed, Aug 23, 2017 at 7:38 AM,  wrote:

> Hi
>
> Can I only include or exclude start/goal link candidates ?
> If osrm can, I easily apply indoor routing by setting link cadidates in
> building, floor.
>
> thanks.
>
> ___
> 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] Current server requirements for planet

[Daniel Patterson]

For preprocessing:

The demoserver uses about 175GB of RAM to preprocess the planet, and around
280GB of STXXL disk space (you'll also need 35GB for the planet file, and
40-50GB for the generated datafiles).

For the foot profile, the latest number I have is about 248GB of RAM.
Everything else is proportionally larger.

The profile you choose has a big impact on size - the foot profile includes
a lot more ways/roads/paths than the car profile, so it needs more
resources.  The cycling profile sits somewhere in between.

For runtime:

You should be able to route on the planet with 64GB of RAM - we basically
just load all the files into memory, so whatever the output file size from
preprocessing - that's roughly how much RAM you'll need (minus the size of
the `.fileIndex` file, which is `mmap()`-ed and read on-demand).

On Wed, Jul 5, 2017 at 7:45 AM, Artur Bialecki 
wrote:

> In my case the disk space used is 102 GB and about 64 GB of RAM while
> running with 30 threads. I run a non-standard profile though that returns
> additional data. Not sure if that affects the foot prints.
>
> Artur...
>
> -Original Message-
> From: Kieran Caplice [mailto:kieran.capl...@temetra.com]
> Sent: Wednesday, July 05, 2017 7:48 AM
> To: osrm-talk@openstreetmap.org
> Subject: [OSRM-talk] Current server requirements for planet
>
> Hello,
>
> What are the current recommended RAM+disk requirements for running an OSRM
> planet server?
>
> Thanks in advance.
>
> Kind regards,
> Kieran Caplice
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
> This e-mail message is confidential, may be privileged and is intended for
> the exclusive use of the addressee. Any other person is strictly prohibited
> from disclosing, distributing or reproducing it. If the addressee cannot be
> reached or is unknown to you, please inform us immediately and delete this
> e-mail message and destroy all copies. Thank you.
> ___
> 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] MLD for multiple routing graphs?

[Daniel Patterson]

Hi Frederick,

  Keep your eye on this issue:
https://github.com/Project-OSRM/osrm-backend/issues/4007

  We're working on something that could be used like this.  It's mostly
targeted at supporting "avoid X" behaviour, but eventually, it will
probably support the use-case you're describing.

  There are a few complications (like different instruction types issued by
different modes) that walk+bike+car would create, but the ticket above is
the first steps in the direction you're thinking of.


daniel

On Fri, Jun 16, 2017 at 2:53 PM, Frederik Ramm  wrote:

> Hi,
>
>in a scenario where I run three OSRM instances - one with a bicyle
> routing graph, one for cars, and one for pedestrians - and where it
> currently takes me two days to update them all, is there a potential for
> speedup if I were to generate one single MLD graph, make three copies of
> it and then use osrm-customize to change the weightings for each of the
> travel modes?
>
> I'm aware that this would be a bit of a hack and lead to wildly
> sub-optimal routing times on the car graph (which would now have tons of
> "dead weight" edges), but if faster updates of all three routing graphs
> were more important for me than fast routing times...?
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> 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] Newbie question : alternative modes

[Daniel Patterson]

Hi Ricardo,

  There is currently no built-in method for this.  OSRM supports ferry
routes, but only when they're drawn explicitly in OpenStreetMap, and
tagged with route=ferry.

  To do this correctly, you would probably need to draw your own ways
down the rivers that you want to support, and connect those to the
rest of the network.  It may or may not be OK to add this data to OSM
itself, I suspect you will need to maintain your own data, and merge
it into an OSM extract (using a tool like osmosis).  It might be
difficult to keep the connectivity correct if you update your base
map.

  I don't think using the outlines of the river polygons for routing
will be practical - I can imagine a lot of cases where the shape might
be very bad for routing, we would route you along the edge of the
river, rather than down the center.  It might get very strange when
rivers hit lakes.  I also don't know if all the necessary roads/paths
would be properly connected to the edges of the river at the points
you want.

  TL;DR - there's no easy way to do it.

daniel

> On Jun 13, 2017, at 08:41, Ricardo Pereira  wrote:
>
> Good morning.
> I'm new to OSRM and would be thankful if someone could direct me to the right 
> approach/documentation to achieve the following:
>
> On top of the normal OSM data supporting "road" traffic, I'd like to also 
> include waterway graphs, that would allow OSRM to also calculate routes for 
> another type of vehicle (e.g. boat).
> I would expect to provide a "waterway" graph with the same type of variables 
> as a road, just as maximum speed, etc, but would expected that it was 
> reserved vehicles of the "boat" type, so that those ways would be used only 
> with the right profile.
>
> Please notice also, that my preference would be to add the rivers to normal 
> road data, not have a separate instance "pretending rivers to be roads".
>
> Thanks in advance,
> Ricardo
> ___
> 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] Problem with route road

[Daniel Patterson]

Hello Wojciech,

What is the problem?

Daniel

> On May 6, 2017, at 16:54, Wojciech Tomczak  wrote:
> 
> Wojciech

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

Re: [OSRM-talk] [API] Role of profile

[Daniel Patterson]

Hi Mateusz,

  The  in the URL is an unused string.  It's there for future 
compatibility if we ever add multiple-profile support to OSRM, but osrm-routed 
does not look at it currently, other than to ensure that it's there.

  Quite a few people use it as a reverse-proxy filtering token - run a reverse 
proxy with multiple osrm-routed instances behind it, and forward requests to 
the appropriate backend based on the contents of the "profile" field.  It works 
quite well.

daniel

> On Apr 25, 2017, at 12:37 PM, Mateusz Loskot  wrote:
> 
> Hi,
> 
> I'm familiar with role of profile in the OSRM processing flow
> as well as descriptions regarding profile and {profile} parameter
> in the HTTP API docs.
> 
> Still. I'm not entirely clear about the profile role in the HTTP API URLs.
> 
> My current understanding is this:
> 
> 1. profile is actively used during extraction phase of data processing
> 2. user can feed extraction with any custom profile as long as it is
> valid for OSRM
> 3. generated .osrm package corresponds to single profile used during 
> processign
> 3. once data extracted and contracted, and complete multi-file .osrm package
> is ready, profile is not used
> 4. osrm-routed serves routing per single .osrm package, so single profile too.
> 
> When requesting osrm-route, I noticed
> * custom profile is not referenced anywhere
> * actually, profile seems not used
> 
> For example, I have simplistic .osrm package sample
> extracted using custom xxx profile and osrm-routed at
> http://localhost:5000, and both requests
> return the same response valid for the sample data
> 
> route/v1/car/30,20;30,15
> route/v1/xxx/30,20;30,15
> 
> in fact, any {profile} parameter works
> 
> /route/v1/nosuchprofile/30,20;30,15
> 
> Now, if I use libosrm API, neither engine config nor any of *Parameters
> require specification of profile.
> 
> These observations as well as the fact that osrm-routed
> serves single .osrm package, so no profile ambiguity is actually
> possible, make me think the {profile} parameter in URLs is unused and 
> redundant.
> 
> Is that correct?
> 
> Best regards
> -- 
> Mateusz Loskot, http://mateusz.loskot.net
> 
> ___
> 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] getting into Oxford Street

[Daniel Patterson]

Hi Alan,

  Hmm, the best way to figure this out is going to be to use the OSRM debug map:

http://map.project-osrm.org/debug/#15.79/51.5140/-0.1515 


  This shows roads that are routable (colored), and roads that are isolated 
from the rest of the network (highlighted in pink).

  I can see that there are some missing roads as well - this means that OSRM 
has removed these from the routing network,
  usually because of access restrictions (i.e. no cars allowed).

  This node:

http://www.openstreetmap.org/node/2198870645 


  indicates that you can't continue straight along Oxford Street there - you're 
only allowed to turn left.  I don't know if this is real or not.
  There are also no turns allowed from Regent St onto Oxford St here - this is 
preventing access to the section of Oxford St just to the
  west here.

  The OSRM demo server updates with new data every couple of days.  If you make 
changes to OSM, you can check:

http://router.project-osrm.org/status 


  to see what data the OSRM demo server is using, and whether any changes 
you've made have taken effect yet.

daniel

> On Mar 16, 2017, at 7:21 AM, Alan Bell  wrote:
> 
> Hi all
> 
> there is a segment of Oxford Street in London from about the Park 
> Street/Portman Street crossing to Regent Street where the turn restrictions 
> prevent you from going straight on into it, or turning left or right from any 
> of the crossing roads.
> 
> http://map.project-osrm.org/?z=15=51.514218%2C-0.130098=51.515313%2C-0.140419=51.514525%2C-0.147876=en=0
> 
> so without any one way street issues, this is an area of perfectly good road 
> from which you can exit but never enter.
> 
> I am not entirely sure what the facts on the ground are (it isn't a very 
> sensible place to be driving) but is there something that can be done in the 
> profile or by editing the map to avoid that bit of road if it has actually 
> been pedestrianised or something?
> 
> Alan.
> 
> 
> ___
> 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] Oneway sample: No route found vs Impossible route

[Daniel Patterson]

Mateusz,

  The difference is in the small component snapping.

"Impossible route between points" indicates that the two snapping points 
are on different small-sized Strongly Connected Components (SCC) (i.e. on two 
separate islands)
"No route between points" indicates that the two snap points are on the 
same component, but there is no route between them.

  OSRM identifies every road edge as either belonging to a particular "small 
component" (an SCC with fewer than 1000 nodes, e.g. an island), or "the large 
component" (there is only one of these globally).

  During initial route finding, we snap coordinates to the nearest edge.

  If both the start and end snap to the same SCC, we attempt to route.  If the 
route fails, you'll get "No route between points".  This can happen if you 
route between two locations on the global "large component", i.e. between 
Europe and the USA.

  If both coordinates snap to the same small component, then by definition, you 
will get a route (this is what an SCC is).

  If one coordinate snaps to a small component, and one to the large component, 
the first point will be searched to find the nearest point on the large 
component.  Then we attempt to route.

  The only time "impossible route between points" can really happen is during 
test cases or if you fiddle with settings.  Because the threshold for "small 
component" is 1000 nodes, there is no "large component" created during test 
cases.

  This leads us to the situation where you can snap points to two separate 
small components, and leads to the error "Impossible route between points".  
That's what's happening in your test example - the one-way roads are creating 
separate SCC islands.

  There's a blog post here that gives an overview for the reasoning behind this 
somewhat complicated logic:

https://www.mapbox.com/blog/smart-neighbor/ 


daniel

> On Feb 20, 2017, at 9:42 AM, Mateusz Loskot  wrote:
> 
> On 20 February 2017 at 13:51, Mateusz Loskot  wrote:
>> [...]
>> I run the OSRM processing and service:
>> 
>> osrm-extract.exe -p C:\apps\osrm-5.5.0\profiles\car.lua
>> 89_car_two_consecutive_oneways.osm
>> osrm-contract.exe 89_car_two_consecutive_oneways.osrm
>> osrm-routed.exe 89_car_two_consecutive_oneways.osrm
> 
> 
> FYI, I've tested those queries using build based on the latest master
> and I'm getting the same results as on Windows with OSRM 5.5.0.
> 
> Best regards,
> -- 
> Mateusz Loskot, http://mateusz.loskot.net
> 
> ___
> 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] hov_ways matching

[Daniel Patterson]

Mikey,

  ignore_hov_ways=true completely removes HOV-only roads from the routing graph 
- if the value is true, you won't match or route on HOV-only roads because they 
get dropped.

  Can you share your GPS trace?  If the matching result seems wrong, can you 
open a ticket at https://github.com/Project-OSRM/osrm-backend 
 please?

daniel

> On Jan 18, 2017, at 11:06 AM, Mikey Alexander 
>  wrote:
> 
> What does the ignore_hov_ways = false do, exactly?  I processed my maps with 
> this flag, expecting match to give routes on HOV ways
>  
> I’ve got sets of points that are clearly moving along 
> http://www.openstreetmap.org/way/141387707#map=15/38.5359/-77.3567 
> 
> The match algorithm matches it to one of the non-HOV segments of I-95.
>  
> Thanks,
> 
> Mikey
> ___
> 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] OSRM 5.4.3 released

[Daniel Patterson]

Hi folks,

  OSRM 5.4.3 has been tagged and released.  This is a bug fix build only.  From 
the CHANGELOG:

  - #3254 Fixed a bug that could end up hiding roundabout instructions
  - #3260 fixed a bug that provided the wrong location in the arrival 
instruction

  Node modules are building as I write this, and I've also published a Docker 
image at osrm/osrm-backend:v5.4.3.
  See https://hub.docker.com/r/osrm/osrm-backend/ 
 for usage instructions.

Happy routing!

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

Re: [OSRM-talk] OSRM-talk Digest, Vol 46, Issue 18

[Daniel Patterson]

Hi Mark,

  The unfortunate answer is that the Windows build is fairly unmaintained.  
Every now and again it gets broken, and sometimes someone nice sends us a patch 
that fixes it.  There is nobody actively working on the Windows version, 
packaging or documentation.

daniel

> On Nov 1, 2016, at 10:03 AM, Mark Hagers <m...@marksman-do.nl> wrote:
> 
> Hi Daniel,
> 
>> On 1 nov. 2016, at 16:48, Daniel Patterson <dan...@mapbox.com 
>> <mailto:dan...@mapbox.com>> wrote:
>> 
>>  That sounds like a bug, the behavior should be the same.  Can you open a 
>> ticket on GitHub with lots of details (what file you're processing, what 
>> version of OSRM, what requests, etc)?
> 
> 
> I'll have to research this a bit more. My initial assessment seems to be 
> wrong, the server on windows seems to return a lot less data with the same 
> requests as the server on OSX, regardless of whether the points are snapped 
> to the network or not.
> Currently the only service that seems to return any actual data is the 
> nearest service (on windows) the other services return empty data (json 
> structures without any actual content) or the "NoRoute" response.
> 
> I've noticed that the directory structure on windows is different from that 
> on OSX. The profiles are in the same dir as the binaries, whereas on OSX the 
> profiles are not included at all in the default homebrew install (I've 
> downloaded the source separately and used the profiles from that in the 
> extract/contract steps)
> 
> I'll gladly open a ticket, but I want to make sure I'm not working with an 
> incorrect setup before I do that.
> 
> Is there any document describing how to set things up on Windows or is my 
> approach (just unpack the Release zipfile into a directory) the correct 
> procedure? 
> 
> best regards,
>  
> Mark Hagers <m...@marksman-do.nl <mailto:m...@marksman-do.nl>>
> 
> ___
> 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-talk Digest, Vol 46, Issue 18

[Daniel Patterson]

Mark,

  That sounds like a bug, the behavior should be the same.  Can you open a 
ticket on GitHub with lots of details (what file you're processing, what 
version of OSRM, what requests, etc)?

daniel

> On Nov 1, 2016, at 8:29 AM, Mark Hagers  wrote:
> 
> Hi all,
> 
>> On 1 nov. 2016, at 13:18, Mark Hagers > > wrote:
>> 
>> I expect this to take quite a bit of time if everything works as planned.
>> I'll update when it's done.
> 
> 
> After a few trials I got this to work. I can run the osrm-routed server and 
> get data from it.
> Many thanks for the help.
> 
> Now I'm confronted with a new issue:
> 
> On OSX I can enter coordinates and the route service snaps them tot the road 
> network if necessary and respond with a route from the snapped coordinates.
> On windows it responds with "No route found between points" if the 
> coordinates aren't already snapped to the network.
> Of course I can use the nearest service to first snap my coordinates to the 
> network, before sending them to the route service, but that means an extra 
> call for every coordinate to the service.
> Is there some setting or profile I can use to force the same behavior on 
> Windows as on OSX? and why is the default behavior apparently different on 
> both platforms
> 
> best regards,
>  
> Mark Hagers >
> 
> ___
> 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] Building OSRM undefined reference to 'tbb::empty_task::~empty_task()

[Daniel Patterson]

Jim,

  Looks like GCC Link-Time-Optimization isn't working on Jessie's GCC 4.9.2.  
Try re-building with:

cd build
make clean
cmake -DENABLE_LTO=OFF ..
make

  and see if that fixes it for you. I get a clean compile on my Docker image.  
If that corrects the issue, then we can add the instructions to the Wiki.  We 
already detect broken LTO support in GCC < 4.9.0, but maybe 4.9.2 is also 
broken.

daniel

> On Sep 7, 2016, at 1:51 PM, Daniel Patterson <dan...@mapbox.com> wrote:
> 
> Hi Jim,
> 
>   Welp, the good news is that I can reproduce this with a Docker image from 
> Jessie.  I'll see if I can track down the problem.
> 
> daniel
> 
>> On Sep 7, 2016, at 1:22 PM, Jim LeBeau <j...@ladsnet.com 
>> <mailto:j...@ladsnet.com>> wrote:
>> 
>> Daniel,
>> 
>> I am running on a debian linux box, jessie a new install and everything up 
>> to date. 
>> 
>> I downloaded the latest code from github and followed the directions at 
>> https://github.com/Project-OSRM/osrm-backend/wiki/Building-OSRM 
>> <https://github.com/Project-OSRM/osrm-backend/wiki/Building-OSRM>
>> 
>> I saw a reference to linker issues from some years ago, and the command that 
>> is failing seems ugly to me with -ltbb repeated more than once.
>> 
>> /usr/bin/c++-flto=2 -Wall -Wextra -pedantic -Wuninitialized 
>> -Wunreachable-code -Wstrict-overflow=1 -D_FORTIFY_SOURCE=2 
>> -fdiagnostics-color=auto -fPIC -ffunction-sections -fdata-sections 
>> -std=c++1y -fopenmp -O3 -DNDEBUG-fuse-ld=gold -Wl,--disable-new-dtags  
>> -Wl,--gc-sections -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common 
>> CMakeFiles/osrm-contract.dir/src/tools/contract.cpp.o  -o osrm-contract 
>> -rdynamic -lboost_date_time -lboost_filesystem -lboost_iostreams 
>> -lboost_program_options -lboost_regex -lboost_system -lboost_thread 
>> -lpthread -ltbb -ltbbmalloc libosrm_contract.a -lboost_date_time 
>> -lboost_filesystem -lboost_iostreams -lboost_program_options -lboost_regex 
>> -lboost_system -lboost_thread -lpthread -lpthread -lluabind -llua5.2 -lstxxl 
>> -ltbb -ltbbmalloc -lrt
>> 
>> 
>> Thanks,
>> 
>> Jim
> 

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

[OSRM-talk] ANNOUNCEMENT: V4 demo server deprecation - for real this time

[Daniel Patterson]

Hi all,

  After many announcements, coordination with other project and allowing a lot 
more time than we originally promised, the shutdown of the 4.x OSRM demo server 
going to happen this week.

  If you have not yet migrated to the 5.x API at router.project-osrm.org 
, please do so immediately.  Within the next 
few days, 4.x API calls (/viaroute, /nearest, etc) will begin permanently 
returning error messages.

  We've hopefully coordinated updates with all the major open source projects 
that depend on OSRM (main OSM website, OSMBonusPack, Leaflet Routing Machine, 
and a few others), but it's impossible to reach everybody.  If you've got an 
app/website/use case that begins failing in the next few days, please check 
that you're using the 5.x API.

  The OSRM demo server will be running the `master` branch from GitHub, updated 
daily.  The API documentation for this code can be found at 
https://github.com/Project-OSRM/osrm-backend/blob/master/docs/http.md#http-api 


  If you're migrating from the 4.x API, please note that in addition to the 
altered URL format, all requests now use , coordinate order.  If you 
find yourself routing to places very unexpected, check your lon/lat order.

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

Re: [OSRM-talk] Question About OSRM

[Daniel Patterson]

Antonio,

  The OSRM demo server runs the latest "in development" code - so sometimes it 
breaks.  It's not intended for production use.  We make reasonable efforts to 
keep it up and running, but, well, you get what you pay for.

  If you run your own server, then the maximum request rate will depend on the 
capacity of your server.  You should be able to achieve 100's of requests per 
second with little effort.

  As a reference point, I've been meaning to post some statistics of the demo 
servers.  I'll do that now.

http://imgur.com/a/VdGwt 

  Summary: 4.9.x demo server is doing around 600,000 hits/hour and CPU usage is 
<10%.  5.x server is doing ~10k hits/hour and CPU usage is under 1%.

daniel

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

Re: [OSRM-talk] Question About OSRM

[Daniel Patterson]

Hello Antonio,

  OSRM an open source project with no direct commercial option.  There is a 
"demo" server for non-commercial use.

  Many people run their own OSRM server to do custom routing (bicycle, 
logistics, single-city configurations, etc).

  I work for Mapbox, and we offer paid-for routing services backed by OSRM (see 
https://www.mapbox.com/directions/ ).  
There may be others who do the same.

daniel

> On Aug 19, 2016, at 6:26 PM, Antonio Gonzalez 
>  wrote:
> 
> Hello Goodnight,
> 
> I want to ask if OSRM currently has a paid account, for the service provided.
> 
> I'll look forward for your answer.
> 
> Thank you very much.
> 
> ___
> 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] File Portability

[Daniel Patterson]

Dylan,

  That's roughly right.

  The main problem is that we're simply dumping C++ in-memory data structures 
to disk.  This means that
  word alignment, byte ordering and data-type sizes need to be the same between 
machines.  Assuming you
  have that, then it should work fine.

  We also don't do any data load validation (there is some stale CRC code, but 
I don't believe it's currently
  used).  This means that data format problems usually only manifest as weird 
routing problems later on.

  It's something everyone would really like to fix, but hasn't been a high 
enough priority for anyone to spend
  time on.  It's important that file-off-disk loading is fast, so any 
cross-platform file compatibility layer needs
  to be carefully designed to not add too much of a performance hit.  Ideally, 
we can `mmap` to most of the
  data files, which could unlock low-memory/low-performance usage scenarios.

daniel

> On Aug 11, 2016, at 7:51 AM, Dylan Adams  wrote:
> 
> Hi,
> 
> I'm aware that there are some limits on the portability of OSRM files,
> as documented on issues #2242 and #1685. I've also seen evidence of
> workflows that extract/contract on one machine, and distribute the
> results to other hosts
> (https://lists.openstreetmap.org/pipermail/osrm-talk/2016-March/001141.html).
> 
> To what extent are OSRM files portable?
> 
> My assumption is that OSRM files are portable as long as the OSRM
> binaries, dependencies, processor architecture, and OS are the same.
> Is that correct?
> 
> Thanks,
> Dylan
> 
> ___
> 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] Questions about internals

[Daniel Patterson]

You got it, the level is implicit in the ordering.  You'll see this behavior in 
a few spots in the codebase - IDs are implied by positions in lists, rather 
than explicitly stored.

daniel

> On Jul 12, 2016, at 8:35 AM, Francis Giraldeau <francis.girald...@gmail.com> 
> wrote:
> 
> Le mar. 12 juil. 2016 à 09:02, Daniel Patterson <dan...@mapbox.com 
> <mailto:dan...@mapbox.com>> a écrit :
> Francis,
> 
>   Yes, it's a bidirectional Dijkstra search.  The Wikipedia page for CH 
> describes it, so I won't repeat it here:  
> https://en.wikipedia.org/wiki/Contraction_hierarchies#Querying 
> <https://en.wikipedia.org/wiki/Contraction_hierarchies#Querying>
> 
> 
> OK, I think I get it. In the graph preprocessing, shortcut edges are added to 
> the edges representing the streets. The relaxation selects edges (including 
> shorcuts) that converges to the goal, such as A*. Of course, the largest 
> shortcut is taken first. However, I was expecting that EdgeData contains a 
> "level" field or a reference to the children, but it is not (i guess to 
> reduce memory usage). I will have a second look at UnpackPath and the 
> Contractor to understand the implicit hierarchy (shortcuts edges at a given 
> level have greater ids than their child level?).
> 
>   "Core nodes" are uncontracted nodes.  `osrm-contract` has the option to not 
> fully contract the edge-based graph (using the `--core` command-line 
> parameter).  In this case, the search needs to be modified when it comes 
> across nodes that are uncontracted.  The purpose of this feature is to allow 
> faster pre-processing, at the expense of query-time performance.
> 
>   If you don't use the `--core` parameter, everything gets contracted, and 
> there are no core nodes.
> 
> Thanks Daniel for this enlightenment.
> 
> Francis
> -- 
> Francis Giraldeau
> ___
> 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] Questions about internals

[Daniel Patterson]

Francis,

  Yes, it's a bidirectional Dijkstra search.  The Wikipedia page for CH 
describes it, so I won't repeat it here:  
https://en.wikipedia.org/wiki/Contraction_hierarchies#Querying 


  "Core nodes" are uncontracted nodes.  `osrm-contract` has the option to not 
fully contract the edge-based graph (using the `--core` command-line 
parameter).  In this case, the search needs to be modified when it comes across 
nodes that are uncontracted.  The purpose of this feature is to allow faster 
pre-processing, at the expense of query-time performance.

  If you don't use the `--core` parameter, everything gets contracted, and 
there are no core nodes.

daniel


> On Jul 12, 2016, at 6:51 AM, Francis Giraldeau  
> wrote:
> 
> Hello!
> 
> I'm digging into the internals of OSRM. The Processing Flow wiki page is 
> quite informative, here are few additional questions. I can edit the wiki 
> with the answers.  
> 
> About the routing algorithm: when inspecting RoutingStep, there are forward 
> and backward heap, so it looks like bidirectional Dijkstra, but the 
> documentation states that the algorithm is based on contraction hierarchies. 
> What's the trick?
> 
> In the code, we see that some nodes are "core nodes". What does that mean?
> 
> Thanks for your help!
> 
> Francis
> -- 
> Francis Giraldeau
> ___
> 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] Accuracy of distance matrix calculation

[Daniel Patterson]

Milton,

  OSRM depends on the tags in OpenStreetmap to estimate travel speeds, and it 
is not always right.  For this particular route, it looks like we think the 
speed is about 60km/h based on the road tags.
  You can see what OSRM thinks of the underlying road network on the debug map:

http://map.project-osrm.org/debug/#17.65/8.51453/76.97262 
<http://map.project-osrm.org/debug/#17.65/8.51453/76.97262>

  The road is unnamed, and has a `maxspeed=60` tag on it.  We assume cars will 
drive at approximately the speed limit.

  I do not know where TravelMath gets their routing results from, but there's a 
good chance they are using Google behind the scenes.  Google uses data from 
mobile phones to get better estimates for travel speeds on roads, this leads to 
more realistic ETA calculation.  Unfortunately, that kind of data is all 
private, so OSRM does not have access to it.  The best we can do is estimate 
based on the metadata we have in OpenStreetmap.

  If you have your own source of improved driving-speed data, you can set up 
your own OSRM server and import it using the "traffic data features" (see the 
OSRM Wiki).

  To answer your other questions:

- Do you want shortest distance routes, or do you want shortest time 
routes, and return the distances for those?  You can do the former by setting 
all speeds in the `car.lua` profile to 3.6km/h, routes will then be calculated 
as shortest distance, and returned "duration" values will be in meters.

- If you run your own OSRM server, you can set the maximum car speed in the 
`car.lua` profile before pre-processing the data.  You cannot set it on a 
per-query basis.

  Note that the API can return an `annotations` element, which tells you the 
specific duration and distance of every segment of the returned route.  If you 
want to cap the speed, you could use this data to adjust the ETA in the 
returned response using your speed limit to fix the returned durations.  This 
would be somewhat complex, but doable.  Note that it would not *route* using a 
maximum speed, but you could somewhat correct your ETA with this approach.

daniel

> On Jun 30, 2016, at 10:10 AM, Milton Garcia Borroto <milton.gar...@gmail.com> 
> wrote:
> 
> Dear Daniel,
> Thank you very much for your promptly reply. We are using osrm for building a 
> large distance matrix. Take a look for example to this calculation: 
> Source: 8.512421667,76.97160333
> Destination: 8.538019178,76.96748103
> OSRM returns 3min 30 sec. If you check in travelmath, they return 10 minutes, 
> which is more logical answer for a 5 km distance.
> Then I have some other questions:
> - Is there a way to get the distances instead of time?
> - Is there a way to select maximum car speed?
> Regards,
> Milton
> 
> 2016-06-30 11:55 GMT-05:00 Daniel Patterson <dan...@mapbox.com 
> <mailto:dan...@mapbox.com>>:
> Milton,
> 
>   What's the exact route in question?  Start/end coordinates, or a link to 
> map.project-osrm.org <http://map.project-osrm.org/> would help us figure out 
> why it's marked as being so fast.
> 
> daniel
> 
>> On Jun 30, 2016, at 9:30 AM, Milton Garcia Borroto <milton.gar...@gmail.com 
>> <mailto:milton.gar...@gmail.com>> wrote:
>> 
>> Hi everybody,
>> I started using osrm few weeks ago, first the demo and now I am running it 
>> in my own server. When using the distance matrix, I am obtaining very 
>> different results from other services like TravelMath (www.travelmath.com 
>> <http://www.travelmath.com/>). Taken a deeper look at the osrm results, I 
>> note that you need to move really fast to attain the resultant times. For 
>> example, a ride of 3.3 km is reported to be done in 3 minutes 30 seconds. Am 
>> I doing or understanding something wront? Can I change the maximum speed?
>> Regards,
>> Milton
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org <mailto:OSRM-talk@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/osrm-talk 
>> <https://lists.openstreetmap.org/listinfo/osrm-talk>
> 
> 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org <mailto:OSRM-talk@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/osrm-talk 
> <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] Accuracy of distance matrix calculation

[Daniel Patterson]

Milton,

  What's the exact route in question?  Start/end coordinates, or a link to 
map.project-osrm.org  would help us figure out 
why it's marked as being so fast.

daniel

> On Jun 30, 2016, at 9:30 AM, Milton Garcia Borroto  
> wrote:
> 
> Hi everybody,
> I started using osrm few weeks ago, first the demo and now I am running it in 
> my own server. When using the distance matrix, I am obtaining very different 
> results from other services like TravelMath (www.travelmath.com 
> ). Taken a deeper look at the osrm results, I 
> note that you need to move really fast to attain the resultant times. For 
> example, a ride of 3.3 km is reported to be done in 3 minutes 30 seconds. Am 
> I doing or understanding something wront? Can I change the maximum speed?
> Regards,
> Milton
> ___
> 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] GPS Accuracy for match service

[Daniel Patterson]

Artur,

  The meaning is the same in both versions, "gps_precision" and "radiuses" are 
"the size of 1 standard deviation of accuracy".

  However, between 4.x and 5.x, the range that we check is a lot narrower.  It 
turns out that in 4.x, the default was about 10x too large, which makes 
map-matching very slow because of the increased number of candidates that it 
needed to check.  The smaller the radius you can use, the faster map-matching 
will be.

  There's no way to change the setting globally on the URL.  You can change the 
code and re-compile OSRM if you want to modify the default.  Not the best way 
to do it, but all we've got at the moment.

daniel


> On Jun 20, 2016, at 11:24 AM, Artur Bialecki <abiale...@intellimec.com> wrote:
> 
> Hello,
>  
> Thank you for the answer.
>  
> Did the match algorithm change between V4.8.1 and V5.2.2? Given the default 
> settings for GPS accuracy (5), V4 seems to match roads in larger radius then 
> version V5. 
>  
> Also, is there a way to globally change the default GPS accuracy instead of 
> having to specify it for every point?
>  
> Thanks you,
>  
> Artur…
>  
>  
> From: Daniel Patterson [mailto:dan...@mapbox.com] 
> Sent: Friday, June 17, 2016 12:13 PM
> To: Mailing list to discuss Project OSRM <osrm-talk@openstreetmap.org>
> Subject: Re: [OSRM-talk] GPS Accuracy for match service
>  
> Hi Artur,
>  
>   TL;DR - there's no direct conversion from HDOP to radius, that's not what 
> HDOP is.
>  
>   Just knowing HDOP isn't enough.  HDOP is based on satellite position and 
> basically tells you "if you had perfect reception right now, the best 
> accuracy you could achieve would be X".  Less-than-perfect reception will 
> also affect accuracy, and isn't part of the HDOP calculation.  Number of 
> satellites in view, multi-path-error, etc, all contribute to inaccuracy and 
> aren't part of HDOP.
>  
>   Things like iPhones can give a reasonable estimate because they have a 
> known GPS device with known characteristics, and they're possibly monitoring 
> satellite count, signal-to-noise ratio, etc and doing a fancier calculation 
> than you get from simple NMEA sentences.
>  
>   Cheap GPS devices sometimes do something naive like 3-5m * HDOP ~= 95% 
> radius (2 standard deviations).  It's not really correct, but if that's all 
> you've got, run with it.
>   
> daniel
>  
> On Jun 17, 2016, at 8:36 AM, Artur Bialecki <abiale...@intellimec.com 
> <mailto:abiale...@intellimec.com>> wrote:
>  
>  
> Hello,
>  
> In the documentation of the V5 match service it states that radiuses are 
> “Standard deviation of GPS precision used for map matching. If applicable use 
> GPS accuracy”. If I have HDOP, how would I convert it to the radius value.
>  
> Thank you.
>  
> Artur…
> This e-mail message is confidential, may be privileged and is intended for 
> the exclusive use of the addressee. Any other person is strictly prohibited 
> from disclosing, distributing or reproducing it. If the addressee cannot be 
> reached or is unknown to you, please inform us immediately and delete this 
> e-mail message and destroy all copies. Thank you. 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org <mailto:OSRM-talk@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/osrm-talk 
> <https://lists.openstreetmap.org/listinfo/osrm-talk>
>  
> This e-mail message is confidential, may be privileged and is intended for 
> the exclusive use of the addressee. Any other person is strictly prohibited 
> from disclosing, distributing or reproducing it. If the addressee cannot be 
> reached or is unknown to you, please inform us immediately and delete this 
> e-mail message and destroy all copies. Thank you. 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org <mailto:OSRM-talk@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/osrm-talk 
> <https://lists.openstreetmap.org/listinfo/osrm-talk>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSRM-talk] Released OSRM 5.2.3

[Daniel Patterson]

Hey all,

I've just tagged and released a minor bug fix to the 5.2 series.

This build fixes a bug that was causing invalid memory allocation when 
routes encountered certain roundabout configurations (name changes within 
roundabout objects),
resulting in server crashes for certain requests.

Thanks to Moritz for the quick patch once the problem was identified.

If you're experiencing this problem, you'll need to re-process your data files 
with the
new versions of the tools (some of the error is baked into the data structure), 
and use
the new libraries/osrm-routed to serve requests.

As always this coincides with a node-osrm release of the same version:

npm install osrm@5.2.3

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

Re: [OSRM-talk] OSRM useable for blind and visually impaired people?

[Daniel Patterson]

Hi Simon,

  OSRM is a back-end service - you give it a couple of coordinates, and it will 
give you the route from A->B as a blob of structured data in JSON format.

  We provide a demo server and web interface for testing, but both are for 
testing/integration purposes only - we don't guarantee that they'll be up and 
working, and we test our latest code on the server constantly, so it might 
suddenly change.

  OSRM certainly could be integrated with an app or web-site that's 
specifically designed for visually impaired folks, but that's a bit beyond the 
scope of OSRM itself.

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

Re: [OSRM-talk] Turn types

[Daniel Patterson]

Hi Pedro,

  "Go Straight" is a direction modifier, "No Turn" is a turn type.

  See:
https://github.com/Project-OSRM/osrm-backend/blob/master/docs/http.md#properties-3

daniel


On Wed, May 11, 2016 at 10:55 AM, Sotorrio, Pedro 
wrote:

> Hi all,
>
> Really basic question; but what are the differences between Go-Straight
> and No-Turn in OSM language?
>
> Thanks!
>
> —Pedro S.
>
> ___
> 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] new api table and geometry

[Daniel Patterson]

Michal,

  Strangely enough, we don't actually have the geometry.  We find a path across 
the Contraction Heirachy
  routing graph, this may only have a small handful of edges.  We can sum these 
edges to get the route
  duration, but to get the actual geometry or distance, we then have to 
"unpack" those edges.

  The table plugin doesn't do this unpacking step.  It gets the durations 
easily, but would be significantly slower
  if we also had to report back the route geometries.  The API response would 
probably also be huge (10s or 100's of MB?) for any
  non-trivial number of route pairs in the table.  To support that, we would 
need a way to stream the response
  asynchronously to the HTTP client, otherwise a couple of requests could use 
up all the RAM on the server.

  Things are never as simple as they seem :-(

daniel

> On Apr 15, 2016, at 12:45 PM, Michal Palenik  
> wrote:
> 
> that is what I already do, but it means a lot of (unnecessary)
> connections. I assume the geometries are already available when
> computing the duration. 
> 
> I was hoping for a "documentation lacking behind development"
> scenario... 
> 
> 
> cheers, 
> michal
> 
> On Fri, Apr 15, 2016 at 04:09:49PM +0200, Daniel Hofmann wrote:
>> If you check the v5 spec you linked, you will see only Route, Trip and
>> Match providing a "geometries" option.
>> 
>> What you can do is this:
>> - do a Table request from your position against all Bus / Tram stops in the
>> area / in a buffer of a few kilometers
>> - pick n shortest routes from the Table response and temporarily store
>> their destination coordinates
>> - do n Route request from your position against the n destination
>> coordinates and extract the geometry
>> 
>> Cheers,
>> Daniel J H
>> 
>> On Fri, Apr 15, 2016 at 3:49 PM, Michal Palenik 
>> wrote:
>> 
>>> hi,
>>> 
>>> within the new api, I am trying to find how to get geometry (together
>>> with perfect duration). is it possible?
>>> 
>>> or do I have to make N*M queries for all the possible combinations?
>>> 
>>> 
>>> https://github.com/Project-OSRM/osrm-backend/wiki/New-Server-api#service-table
>>> 
>>> I am trying to make a service like "show me the routes to the closest
>>> bus/tram stops" : http://epsilon.sk/mhd/
>>> 
>>> thanks
>>> 
>>> michal
>>> 
>>> --
>>> michal palenik
>>> www.freemap.sk
>>> www.oma.sk
>>> 
>>> 
>>> ___
>>> 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
> 
> 
> -- 
> michal palenik
> www.freemap.sk
> www.oma.sk
> 
> 
> ___
> 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] routing with GPUs or mapD

[Daniel Patterson]

Bjorn,

  This paper outlines one approach that is very fast:

  http://www.cs.princeton.edu/~rwerneck/papers/DKW14-crp-gpu.pdf 
  

  and there are others:

  
https://pdfs.semanticscholar.org/0c17/805ab324006d40a8dd37d3550815824498fb.pdf 

  http://research.ijcaonline.org/volume72/number18/pxc3889386.pdf 

  http://public.lanl.gov/sunil/pubs/ipdps14.pdf 


  The Contraction Heirachy approach that OSRM uses is not all that amenable to 
GPU acceleration unfortunately.

daniel

> On Mar 31, 2016, at 2:50 PM, Bjorn Madsen  
> wrote:
> 
> Brief introduction:
> The difference between (1) routing + overlaying congestion data and (2) 
> routing with congestion data is that the former simply provides a route which 
> is extended with the delay given by the reduced travel speed inferred from 
> the congestion (option 1). We can do that easily today.
> 
> Routing with congestion data (option 2) requires that the quickest path is 
> computed based on the congestion currently and the predicted congestion in 
> the near future. This results in completely different routes as the road 
> network velocity drops, whereby the fastest route (often) ends up being the 
> shortest, though junctions with accidents can generate minor detours. The 
> shift between the two modes of computation, is not linear, so walking the 
> graph is necessary in most cases. However as the walks could be performed in 
> concurrent lock-steps, it seems feasible to push such kind of workload onto 
> GPUs.
> 
> Question:
> I've been looking at mapD for a while and wondered whether it would be the 
> better alternative solution for routing that may include dynamic congestion 
> data into the routing process. Is anyone out there working with similar 
> thoughts - or, on using GPUs in the process?
> 
> Kind regards
> 
> -- 
> Bjorn Madsen
> 
> ___
> 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] Debugging map

[Daniel Patterson]

I've just updated the color scale, hopefully the separations are a bit clearer 
now.  It should be a bit more colorblind friendly as well.

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

Re: [OSRM-talk] Debugging map

[Daniel Patterson]

> On Mar 16, 2016, at 3:03 PM, Frédéric Rodrigo  wrote:
> 
> I think there is an issues with blue and green in scale.

Ah, good catch, fixed!

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

Re: [OSRM-talk] About Indoor Routing

[Daniel Patterson]

Hi C.C.Tang,

  You will almost certainly need to modify the foot.lua profile.  I have not 
really looked at the indoor tagging before, but it seems like there are lots of 
tags that will be used that the current foot profile does not know about.

  For (1), I mean that there is no support for indoor-specific words in the 
instructions returned in the "viaroute" response.  It knows about things like 
"turn left on X street", but it does not know about indoor instructions like 
"take the third door on your left", or "take the elevator to the 3rd floor".

  For (2), you are correct - the current nearest-neighbor match is 2D only, it 
does not know about elevation.  Support for this would need to be added if you 
wanted to match to certain levels.

  In addition, routing on OSM areas is currently limited to routing around the 
edges - see https://github.com/Project-OSRM/osrm-backend/issues/64 
<https://github.com/Project-OSRM/osrm-backend/issues/64>

  Overall, I'm sure you can make it work, but I think OSRM is currently missing 
a few important features for it to work really well.

daniel

> On Feb 15, 2016, at 9:10 PM, C.C.Tang <hiyorin+...@gmail.com> wrote:
> 
> Hi Daniel,
> 
> Many thanks for your reply.
> 
> I am going to try and see if it works.
> But I come up with several new questions after reading your response:
> 
> 1.
> >> like "take the stairs" and "take the elevator to the Nth floor".
> Do you mean I need to work around it by tagging staris and elevator 
> differently in order to route between levels?
> Or a custom profile is needed?
> 
> 2.
> While the indoor data will very likely to have several overlapping area 
> defined on different level, will OSRM have difficulties determining the 
> correct source/destination node when a query is being processed?
> 
> Many thanks,
> C.C.Tang
> 
> 
> On Tue, Feb 16, 2016 at 11:57 AM Daniel Patterson <dan...@mapbox.com 
> <mailto:dan...@mapbox.com>> wrote:
> Hi,
> 
>   While it can work in theory, OSRM is missing some of the indoor-specific 
> guidance that you will need for changing levels, like "take the stairs" and 
> "take the elevator to the Nth floor".  We are working on a big refactor at 
> the moment that might improve this, but I don't know if anyone has put a lot 
> of thought into it at the moment.
> 
>   The first thing to do would be to give it a go and see if the results are 
> acceptable.  Add the ways you need to OSM, then use the foot.lua profile and 
> make sure the indoor tags are included in the routing graph.
> 
> daniel
> 
> 
>> On Feb 15, 2016, at 7:27 PM, C.C.Tang <hiyorin+...@gmail.com 
>> <mailto:hiyorin+...@gmail.com>> wrote:
>> 
> 
>> Dear List Moderator,
>> 
>> Please kindly ignore my previous post having the same mail subject. I sent 
>> it with wrong From address.
>> 
>> Hi all,
>> 
>> I am doing a project that require (multi floor/level) indoor routing 
>> capability. 
>> I was wondering if OSRM supports processing indoor related tags and suggest 
>> route according to those data?
>> Assuming I follow the proposal in 
>> http://wiki.openstreetmap.org/wiki/Indoor_Mapping 
>> <http://wiki.openstreetmap.org/wiki/Indoor_Mapping>
>> and 
>> http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging 
>> <http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging>
>> 
>> Any suggestion and advice would be grateful.
>> 
>> Thanks in advance,
>> C.C.Tang
> 
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org <mailto:OSRM-talk@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/osrm-talk 
>> <https://lists.openstreetmap.org/listinfo/osrm-talk>
> 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org <mailto:OSRM-talk@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/osrm-talk 
> <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] About Indoor Routing

[Daniel Patterson]

Hi,

  While it can work in theory, OSRM is missing some of the indoor-specific 
guidance that you will need for changing levels, like "take the stairs" and 
"take the elevator to the Nth floor".  We are working on a big refactor at the 
moment that might improve this, but I don't know if anyone has put a lot of 
thought into it at the moment.

  The first thing to do would be to give it a go and see if the results are 
acceptable.  Add the ways you need to OSM, then use the foot.lua profile and 
make sure the indoor tags are included in the routing graph.

daniel

> On Feb 15, 2016, at 7:27 PM, C.C.Tang  wrote:
> 
> Dear List Moderator,
> 
> Please kindly ignore my previous post having the same mail subject. I sent it 
> with wrong From address.
> 
> Hi all,
> 
> I am doing a project that require (multi floor/level) indoor routing 
> capability. 
> I was wondering if OSRM supports processing indoor related tags and suggest 
> route according to those data?
> Assuming I follow the proposal in 
> http://wiki.openstreetmap.org/wiki/Indoor_Mapping 
> 
> and 
> http://wiki.openstreetmap.org/wiki/Simple_Indoor_Tagging 
> 
> 
> Any suggestion and advice would be grateful.
> 
> Thanks in advance,
> C.C.Tang
> ___
> 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] RunQuery Output

[Daniel Patterson]

James,

  There's an updated example client here:

https://github.com/Project-OSRM/osrm-backend/blob/develop/example/ 


  If you look inside the "route_summary" member of the JSON response, you'll 
find both the "total_time" and "total_distance" sub members, which sound like 
the values you want.  The new example shows how to easily access these.

daniel

> On Feb 15, 2016, at 1:52 PM, James Grant  wrote:
> 
> Hi there.
> 
> I'm building some code based heavily around the "simpleclient.cpp" example in 
> the tools section of the source code. I'm trying to simply extract the 
> driving distance and time from the returned JSON object. 
> 
> This could be achieved by taking the object returned and manipulating it 
> which seems wasteful, or I could amend the code such that is purely returned 
> the required information. If the latter isn't realistic, then using the 
> existing JSON handler, how could I extract information from the JSON object?
> 
> Cheers
> ___
> 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] Getting OSMNodeIDs in OSRM

[Daniel Patterson]

Kerrick,

  The node ids you have refer to nodes in the edge-based graph.  That's a level 
removed from what you want, so you'll need to work your way backwards.

  This shows how to unpack the edge-based-node ids into a sequence of node ids 
in the node-based graph (that you can then convert to OSMNodeIDS):

https://github.com/Project-OSRM/osrm-backend/blob/fefe5e241a7ec62c7ca102f93834308411dfe58c/include/engine/routing_algorithms/routing_base.hpp#L295-L326

  The GetUncompressedGeometry call returns an array of node-based-node ids that 
represents a road section between two intersections.

   The PhantomNode's fwd_segment_position attribute is the position in that 
array that the PhantomNode was nearest.  The PhantomNode is probably between two
   nodeIDs, so you'll have to figure out which one you want.  You can duplicate 
this logic to figure out which one is closer:

https://github.com/Project-OSRM/osrm-backend/blob/fefe5e241a7ec62c7ca102f93834308411dfe58c/include/engine/geospatial_query.hpp#L141-L145

daniel


> On Feb 1, 2016, at 3:51 PM, Kerrick Staley <ksta...@lyft.com> wrote:
> 
> It doesn't look like PhantomNode's forward_node_id and reverse_node_id are 
> indexes into InternalDataFacade's m_coordinate_list (and hence the 
> m_osmnodeid_list I created). When I look up forward_node_id/reverse_node_id I 
> get OSM nodes that are far away from the query point. (PhantomNode.name_id 
> and PhantomNode.location *are* set correctly however).
> 
> So I should probably follow Patrick's suggestion and have a separate loop 
> that reads the .nodes file? Does the .nodes file contain ExternalMemoryNodes 
> or QueryNodes? (graph_loader.hpp reads one and internal_datafacade.hpp reads 
> the other, although it won't matter if the two structs have the same size due 
> to padding).
> 
> On Mon, Feb 1, 2016 at 9:25 AM, Daniel Patterson <dan...@mapbox.com> wrote:
> Hi Kerrick,
> 
>   Yup, the node ids are renumbered to pack them more densely and ensure that 
> values fit inside an unsigned int (32 bits).
> 
>   The mapping *is* written to the `.nodes` file though, here:
> 
> https://github.com/Project-OSRM/osrm-backend/blob/d189339495e223a6ceea21a73bb7e434775172fa/src/extractor/extractor.cpp#L550-L561
> 
>   when this file is later read, we only load the coordinates from it, so the 
> OSM values are there, but not used:
> 
> https://github.com/Project-OSRM/osrm-backend/blob/d189339495e223a6ceea21a73bb7e434775172fa/include/engine/datafacade/internal_datafacade.hpp#L116-L129
> 
>   here, you could add the OSM node values to a new array, then you'd have the 
> lookup table you need to map the NodeIDs you have to the original OSM values.
> 
>   This will require extra RAM, which may or may not be a problem for you.
> 
> daniel
>   
> 
>> On Feb 1, 2016, at 9:03 AM, Kerrick Staley <ksta...@lyft.com> wrote:
>> 
>> I want to create a binary that will take an input lat/long and give the two 
>> OSMNodeIDs representing the nearest road segment. I was able to hack 
>> something together using NearestPhantomNodes in the OSRM codebase, but I 
>> can't figure out how to go from the NodeIDs in the PhantomNode to OSMNodeIDs.
>> 
>> It looks like the NodeID -> OSMNodeID mapping is dropped in 
>> osrm-extract/osrm-prepare. Is this the case? Can I use the .osrm or 
>> .osrm.nodes file to re-build the mapping?
>> 
>> Thanks,
>> Kerrick
>> 
>> ___
>> 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
> 
> 
> 
> 
> -- 
> - Kerrick
> ___
> 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] Getting OSMNodeIDs in OSRM

[Daniel Patterson]

Hi Kerrick,

  Yup, the node ids are renumbered to pack them more densely and ensure that 
values fit inside an unsigned int (32 bits).

  The mapping *is* written to the `.nodes` file though, here:

https://github.com/Project-OSRM/osrm-backend/blob/d189339495e223a6ceea21a73bb7e434775172fa/src/extractor/extractor.cpp#L550-L561
 


  when this file is later read, we only load the coordinates from it, so the 
OSM values are there, but not used:

https://github.com/Project-OSRM/osrm-backend/blob/d189339495e223a6ceea21a73bb7e434775172fa/include/engine/datafacade/internal_datafacade.hpp#L116-L129
 


  here, you could add the OSM node values to a new array, then you'd have the 
lookup table you need to map the NodeIDs you have to the original OSM values.

  This will require extra RAM, which may or may not be a problem for you.

daniel
  

> On Feb 1, 2016, at 9:03 AM, Kerrick Staley  wrote:
> 
> I want to create a binary that will take an input lat/long and give the two 
> OSMNodeIDs representing the nearest road segment. I was able to hack 
> something together using NearestPhantomNodes in the OSRM codebase, but I 
> can't figure out how to go from the NodeIDs in the PhantomNode to OSMNodeIDs.
> 
> It looks like the NodeID -> OSMNodeID mapping is dropped in 
> osrm-extract/osrm-prepare. Is this the case? Can I use the .osrm or 
> .osrm.nodes file to re-build the mapping?
> 
> Thanks,
> Kerrick
> 
> ___
> 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] Avoid highways

[Daniel Patterson]

Hi Lorenzo,

  Currently, that would require a separate "profile"; a completely separate 
database with the road network processed differently.  Our demo server only has 
the capacity to run one profile, and it takes many hours to generate a new one.

  There is a long-standing ticket here:

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


  that talks about modifying the weighting algorithm so that we can maintain 
correct time estimates, but modify weighting so that certain road types are 
avoided.  The reason this hasn't been implemented is that it will probably 
require additional memory, and we are very hesitant to increase that.

daniel

  

> On Jan 21, 2016, at 6:43 AM, lorenzo  wrote:
> 
> Hi Everybody,
>  
> Is it possible with OSRM to create an option which permits to avoid highways 
> once we have generated the main route?
> Like in google maps in which we have a check-box.
>  
> Thanks in advance and best regards,
> Lorenzo Bonora  
> ___
> 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] Multi-threaded calls to the C++ library interface

[Daniel Patterson]

Hi Richard,

  Yes, it works, this is what osrm-routed does, there is only a single
instance of the OSRM object shared between multiple threads:

https://github.com/Project-OSRM/osrm-backend/blob/develop/src/tools/routed.cpp#L105

  It works either with the internal facade, or the shared memory option.

Daniel
On Jan 20, 2016 8:25 PM, "Richard Marsden"  wrote:

> Is it possible to have multi-threaded (i.e. multiple simultaneous)
> calls using the C++ library interface?
>
> E.g. with one "OSRM" object shared between the threads; or with
> multiple OSRM objects, one per thread?
>
> Presumably the latter case would be memory hungry, but enabling
> shared_memory in the libosrm_config would help...?
>
> The scenario I'm looking at would use the same road/graph files.
>
>
>
> Richard Marsden
>
> ___
> 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] Demo server stability - an update

[Daniel Patterson]

Hi all,

  Over the last few months, there have been some stability issues with the demo 
server.  Hopefully from today, things should be a bit more stable.

  Late last year, the original demo server hosted by KIT had become 
unmaintained.  As a stop-gap measure, an alternative server was configured, and 
a reverse proxy installed on the existing server.  This worked reasonably well, 
except when it didn't.

  Today, we've swapped the DNS records over to point directly to the 
alternative server, and set up a standalone SSL certificate so we can serve 
requests over HTTPS.

  The canonical URL remains:

https://router.project-osrm.org/ 

  for requests.  There may be a few remaining problems while DNS entries expire 
in people's caches, but they should disappear.

  Any problems in the future should be a bit easier to resolve, as we now have 
several people with access to all the parts of the puzzle.  If you experience 
problems, please file a ticket on GitHub.

  A big thanks to DennisL and KIT for hosting the demo server all these years, 
and here's to many more to come!

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

Re: [OSRM-talk] OSRM 4.9.0 released

[Daniel Patterson]

Hi Kin,

  The "from_osm_id" and "to_osm_id" must be two directly connected OSM node 
IDs.  The wiki page:

https://github.com/Project-OSRM/osrm-backend/wiki/Traffic 
<https://github.com/Project-OSRM/osrm-backend/wiki/Traffic>

  has some more details on the values, and some usage examples.

daniel

> On Dec 30, 2015, at 9:41 AM, Aurélien  <kinj...@gmail.com> wrote:
> 
> Hi,
> 
> When you define the CSV file structure "from_osm_id;to_osm_id;edge_value", 
> what means the "osm_id" ? Two vertex of an edge or a set of connected edges ?
> 
> For example, e is an edge and n a vertex :
> 
> n1 ---(e1)--- n2 ---(e2)--- n3 ---(e3)--- n4 
> ---(e4)--- n5
> 
> Should we make a CSV file with 4 lines (n1-n2, n2-n3, n3-n4, n4-n5) or one 
> line (e1-e4) ?
> 
> Thank you very much for your work, and happy new year in advance !
> 
> Kin
> 
> On Thu, Dec 24, 2015 at 12:42 PM, Patrick Niklaus 
> <patrick.nikl...@student.kit.edu <mailto:patrick.nikl...@student.kit.edu>> 
> wrote:
> # Overview
> 
> `4.9.0` is a massive release with 198 files being touched, 8501 lines
> added, and 6308 deleted.
> This release features experimental support for traffic updates based on CH.
> It is an experimental feature and will most likely be subject to
> change. Some instructions
> to get traffic updates running can be found int the wiki
> [here](https://github.com/Project-OSRM/osrm-backend/wiki/Traffic 
> <https://github.com/Project-OSRM/osrm-backend/wiki/Traffic>).
> This release also features support for 64 bit OSM node ids. This
> drastically increases the disk space needed for pre-processing. Server
> memory usage is not affected. In preparation for the upcoming API
> re-write in `5.0` some smaller API breakges were introduced in this
> release. Leaflet-Routing-Machien 2.6.1 is compatible with the new API.
> As always this node-osrm 4.9.0 can be found on npm as well.
> 
> # Changelog
> 
> ## API changes:
> - BREAKING: Changed response code for ok to `200`
> - BREAKING: Fix off-by-one in via_indices (was one index too high)
> - BREAKING: Removed `osrm/server_path.hpp`
> - Add max value for viaroute and trip to osrm-routed. Default: 500 for
> viaroute and 100 for trip
> - Allow POST request without POST data
> - Add response code 208 for no segment found (important for bearing filter)
> - New temporary file `.level` created by osrm-prepare (see level caching)
> - New temporary file `.edge_segment_lookup` and `.edge_penalties`
> created by `osrm-extract` if passing the `--generate-edge-lookup`
> options.
> - API grammar got more strict to discard invalid requests faster.
> Options like `hint`, `u` and `b` now need to follow directly after a
> `loc` (or `src` and `dst`). Example:
> `=..=true=0,10=...=false=...`. The following is
> illegal: `=..=..=...=0,10=true=false`.
> - Pre-turn bearing is now available in the `route_instructions` array
> as last field
> - Remove short option name `-m` from `osrm-routed` as it conflicted
> - New option `--segment-speed-file` for `osrm-prepare`. CSV file using
> `from_osm_id;to_osm_id;edge_value`.
> 
> ## Bug fixes:
> - Support 64bit OSM node ids
> - Fixed u-turn penalty, value from lua profiles was not used
> - Fix street name corruption for large datasets
> - Properly initialize UUID used in Fingerprint class.  Fixes #1721
> 
> ## Maintenance:
> - Rewrite nearest neighbor search code
> - Rewrite via-route search and fix multiple related bugs
> - Add test for small component snapping
> - Update variant library which fixes GCC 5.1.2 compile errors
> - Silence warnings with GCC, LTO does not yet respect the -isystem switch
> - Use ccache by default if available and a suitable compiler is used.
> - Switch Travis builds over to trusty for Linux
> - Fix pkgconfig cmake template
> 
> ## Features:
> - Support general nxm queries to table query (thanks to @fab-girard)
> `loc`, `dst`, `src` parameters
> - Add edge update step to `osrm-prepare`. Enables fast edge weight updates
> - Add level caching `--level-cache` for `osrm-prepare`. This allows to
> speed up consecutive runs of `osrm-prepare` **on the same dataset**
> (only edge weights updates allowed).
> - Small component size is now configurable over parameter for `osrm-routed`
> - Support adding bearing filtering. Use `b=BEARING,RANGE`
> - Add support for advisory speed limits
> - Add duration and distance fields to `match` response
> - Human-readable error messages for out of memory
> - Include (road) name of matched nodes in addition to coordinate.
> - Add `is_startpoint` property to `result` ways in the lua profiles.
> Determines if a wa