[OSRM-talk] OSRM 5.18.0 (and 5.17.0)

[Patrick Niklaus]

Hey,

the brand new OSRM 5.18.0 features exiting new features like being
able to return the distance values in the `table` plugin. There are
also various memory usage improvements for MLD and a completely
rewritten file storage layer. Thanks to all the contributor of this
release!

I noticed we never send a release email for 5.17 so I included the
changelog here as well.

Cheers,
Patrick

Changes from 5.17.0:

- Features:
  - ADDED: `table` plugin now optionally returns `distance` matrix as
part of response #4990
  - ADDED: New optional parameter `annotations` for `table` that
accepts `distance`, `duration`, or both `distance,duration` as values
#4990
- Infrastructure:
   - ADDED: Updated libosmium and added protozero and vtzero libraries #5037
   - CHANGED: Use vtzero library in tile plugin #4686
- Profile:
   - ADDED: Bicycle profile now returns classes for ferry and tunnel
routes. #5054
   - ADDED: Bicycle profile allows to exclude ferry routes (default to
not enabled) #5054

Changes from 5.16.0:

  - Changes from 5.16.0:
- Bugfixes:
  - FIXED: deduplication of route steps when waypoints are used #4909
  - FIXED: Use smaller range for U-turn angles in map-matching #4920
  - FIXED: Remove the last short annotation segment in
`trimShortSegments` #4946
  - FIXED: Properly calculate annotations for speeds, durations
and distances when waypoints are used with mapmatching #4949
  - FIXED: Don't apply unimplemented SH and PH conditions in
OpeningHours and add inversed date ranges #4992
  - FIXED: integer overflow in `DynamicGraph::Renumber` #5021
- Profile:
  - CHANGED: Handle oneways in get_forward_backward_by_key #4929
  - FIXED: Do not route against oneway road if there is a cycleway
in the wrong direction; also review bike profile #4943
  - CHANGED: Make cyclability weighting of the bike profile prefer
safer routes more strongly #5015
- Guidance:
  - CHANGED: Don't use obviousness for links bifurcations #4929
  - FIXED: Adjust Straight direction modifiers of side roads in
driveway handler #4929
  - CHANGED: Added post process logic to collapse segregated turn
instructions #4925
  - ADDED: Maneuver relation now supports `straight` as a direction #4995
  - FIXED: Support spelling maneuver relation with British spelling #4950
- Tools:
  - ADDED: `osrm-routed` accepts a new property `--memory_file` to
store memory in a file on disk. #4881
  - ADDED: `osrm-datastore` accepts a new parameter
`--dataset-name` to select the name of the dataset. #4982
  - ADDED: `osrm-datastore` accepts a new parameter `--list` to
list all datasets loaded into memory. #4982
  - ADDED: `osrm-datastore` accepts a new parameter
`--only-metric` to only reload the data that can be updated by a
weight update (reduces memory for traffic updates). #5002
  - ADDED: `osrm-routed` accepts a new parameter `--dataset-name`
to select the shared-memory dataset to use. #4982
- NodeJS:
  - ADDED: `OSRM` object accepts a new option `memory_file` that
stores the memory in a file on disk. #4881
  - ADDED: `OSRM` object accepts a new option `dataset_name` to
select the shared-memory dataset. #4982
- Internals
  - CHANGED: Updated segregated intersection identification #4845 #4968
  - REMOVED: Remove `.timestamp` file since it was unused #4960
- Documentation:
  - ADDED: Add documentation about OSM node ids in nearest service
response #4436
- Performance
  - FIXED: Speed up response time when lots of legs exist and
geojson is used with `steps=true` #4936
  - FIXED: Return iterators instead of vectors in datafacade_base
functions #4969
- Misc:
  - ADDED: expose name for datasource annotations as metadata #4973

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

Re: [OSRM-talk] Subject: Re: Suggested hardware specs for server under heavy use via Digest

[Patrick Niklaus]

We don't use Stxxl during the query phase, but an SSD is recommended. We
use an external memory storage for the R-Tree that we use for getting the
closed street segment.

For matrix queries on MLD are about 2-3 times slower than on CH.

Best,
Patrick

Baig, Tariq <tariq.b...@ds.mpg.de> schrieb am Do., 29. März 2018, 11:27:

> Thanks for the suggestions Patrick,
>
> how do you think things would change if we needed trafic support? I guess
> MLD is slower than CH,
> could we compensate for that by putting the whole system on an SSD to make
> the stxxl perform better?
>
> Thanks again,
> tariq
>
> --
>
> Tariq Baig-Meininghaus
>
> Researcher
>
> Max Planck Institute for Dynamics and Self-Organization
> Department DCF/EcoBus
>
> Am Faßberg 17
>
> 37077 GÖTTINGEN
> GERMANY
>
>
> Mail: tariq.b...@ds.mpg.de
>
> Web: www.ds.mpg.de, ecobus.fokos.info
>
> 
> From: osrm-talk-requ...@openstreetmap.org [
> osrm-talk-requ...@openstreetmap.org]
> Sent: Wednesday, March 28, 2018 2:00 PM
> To: osrm-talk@openstreetmap.org
> Subject: OSRM-talk Digest, Vol 63, Issue 11
>
> Send OSRM-talk mailing list submissions to
> osrm-talk@openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.openstreetmap.org/listinfo/osrm-talk
> or, via email, send a message with subject or body 'help' to
> osrm-talk-requ...@openstreetmap.org
>
> You can reach the person managing the list at
> osrm-talk-ow...@openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OSRM-talk digest..."
>
>
> Today's Topics:
>
>1. Suggested hardware specs for server under heavy use (Baig, Tariq)
>2. Re: Suggested hardware specs for server under heavy use
>   (Patrick Niklaus)
>3. Re: OSRM 5.14.3 set kilometers long ways as small elements
>   (Daniel Patterson)
>
>
> --
>
> Message: 1
> Date: Tue, 27 Mar 2018 12:49:08 +
> From: "Baig, Tariq" <tariq.b...@ds.mpg.de>
> To: "osrm-talk@openstreetmap.org" <osrm-talk@openstreetmap.org>
> Subject: [OSRM-talk] Suggested hardware specs for server under heavy
> use
> Message-ID:
> <350c9baaf4e5894aa7907627b5508828d532f...@um-excdag-a03.um.gwdg.de
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Dear all,
>
> we are currently working on a research project that uses osrm as a routing
> backend.
> Since we heavily rely on OSRM we would like to migrate it to a more
> appropriate harware setup.
>
> What would be the recommended specs for a server  that provides routing
> for the whole of germany,
> and can service order of 100 - 200 table requests per second?
>
> Greetings and thanks in advance,
>
> tariq
>
>
> --
>
> Tariq Baig-Meininghaus
>
> Researcher
>
> Max Planck Institute for Dynamics and Self-Organization
> Department DCF/EcoBus
>
> Am Faßberg 17
>
> 37077 GÖTTINGEN
> GERMANY
>
>
> Mail: tariq.b...@ds.mpg.de
>
> Web: www.ds.mpg.de, ecobus.fokos.info
>
>
>
> --
>
> Message: 2
> Date: Tue, 27 Mar 2018 14:41:18 +
> From: Patrick Niklaus <patrick.nikl...@student.kit.edu>
> To: Mailing list to discuss Project OSRM <osrm-talk@openstreetmap.org>
> Subject: Re: [OSRM-talk] Suggested hardware specs for server under
> heavy use
> Message-ID:
> <
> cafxp+1p1ofr6_ea6pcviflau8pjqp5f4v4kwadz9gfno-gq...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hey Tariq,
>
> This heavily depends on the settings you use and the kind of requests.
> For the car profile Germany should fit into 16GB of RAM, but I would
> calculate some buffer depending on if you need the option to exclude
> motorways and ferries.
> I'll assume you don't need traffic support? Then using or Contraction
> Hierarchy toolchain might be your best option.
>
> For the CPU requirement to get close to 200 req/sec it entirely
> depends on the kind of request (how many input coordinates).
> For a 100x100 matrix you can expect something like ~100ms on Germany,
> that would put you at 10 req per core per second.
> A 16 core system should probably get you in the right order of magnitude.
>
> Best,
> Patrick
>
>

Re: [OSRM-talk] [Travis CI] Auto Cancellation for pull requests?

[Patrick Niklaus]

There is an issue with Travis CI
https://github.com/travis-ci/travis-ci/issues/4867 about this.

Sadly doesn't look it would be getting solved soon.

Cheers,
Patrick

On Fri, Feb 2, 2018 at 10:58 AM, Mateusz Loskot  wrote:
> I thought that would be the case too.
> Unfortunately, I can not cancel any builds at
> https://travis-ci.org/Project-OSRM/osrm-backend/
> I can cancel builds of projects where I'm a member/developer though.
>
> Mateusz
>
> On 2 February 2018 at 11:44, Johan Uhle  wrote:
>> I think you should be able to cancel builds manually as well, so that might
>> be the way to go in this specific case.
>>
>> Best,
>> Johan
>>
>> On Fri, Feb 2, 2018 at 11:08 AM, Mateusz Loskot  wrote:
>>>
>>> Hi Johan,
>>>
>>> On 2 February 2018 at 10:12, Johan Uhle  wrote:
>>> >
>>> > auto-cancellation on Travis is enabled. It only cancels pending builds
>>> > though, so does not kick in for force pushes if the build is already
>>> > running.
>>>
>>> Yes, it cancels pending only indeed.
>>> I just had an impression that it did not cancel pending build - I git
>>> push forced
>>> my PR 2-3 times within a few minutes. I might got confused though.
>>>
>>> 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
>>
>
>
>
> --
> 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

[OSRM-talk] Released OSRM 5.13

[Patrick Niklaus]

Hey,

This release has some exciting new features: We know have relation
support in the lua profiles, and support using location dependent
data. In addition to that we deprecated CoreCH, since MLD is superior.

  - Changes from 5.12:
- Profile:
  - Append cardinal directions from route relations to ref fields
to improve instructions; off by default see
`profile.cardinal_directions`
  - Support of `distance` weight in foot and bicycle profiles
  - Support of relations processing
  - Added `way:get_location_tag(key)` method to get
location-dependent tags
https://github.com/Project-OSRM/osrm-backend/wiki/Using-location-dependent-data-in-profiles
  - Added `forward_ref` and `backward_ref` support
  - Left-side driving mode is specified by a local Boolean flag
`is_left_hand_driving` in `ExtractionWay` and `ExtractionTurn`
  - Support literal values for maxspeeds in NO, PL and ZA
- Infrastructure:
  - Lua 5.1 support is removed due to lack of support in sol2
https://github.com/ThePhD/sol2/issues/302
  - Fixed pkg-config version of OSRM
  - Removed `.osrm.core` file since CoreCH is deprecated now.
- Tools:
  - Because of boost/program_options#32 with boost 1.65+ we needed
to change the behavior of the following flags to not accept
`={true|false}` anymore:
- `--use-locations-cache=false` becomes `--disable-location-cache`
- `--parse-conditional-restrictions=true` becomes
`--parse-conditional-restrictions`
- The deprecated options `--use-level-cache` and
`--generate-edge-lookup`
- Bugfixes:
  - Fixed #4348: Some cases of sliproads pre-processing were broken
  - Fixed #4331: Correctly compute left/right modifiers of forks
in case the fork is curved.
  - Fixed #4472: Correctly count the number of lanes using the
delimter in `turn:lanes` tag.
  - Fixed #4214: Multiple runs of `osrm-partition` lead to crash.
  - Fixed #4348: Fix assorted problems around slip roads.
  - Fixed #4420: A bug that would result in unnecessary
instructions, due to problems in suffix/prefix detection
- Algorithm
  - Deprecate CoreCH functionality. Usage of CoreCH specific
options will fall back to using CH with core_factor of 1.0
  - MLD uses a unidirectional Dijkstra for 1-to-N and N-to-1
matrices which yields speedup.

Cheers,
Patrick

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

Re: [OSRM-talk] error: undefined reference to 'boost::re_detail::cpp_regex_traits_implementation::transform

[Patrick Niklaus]

Hey,

the primary difference to our build environment on Travis CI is that
we build on Ubuntu 14.04 using boost 1.54:
https://travis-ci.org/Project-OSRM/osrm-backend/jobs/290183596#L1573
It could be that this is a specific issue with boost 1.58 that was
introduced by using a new symbol on `master`.

The error in question looks really weird. A wild guess might be there
are two version of libboost on your system and OSRM picks up the wrong
headers.

Best,
Patrick


On Wed, Oct 18, 2017 at 4:30 PM, Mateusz Loskot  wrote:
> Hi,
>
> I'm building the current master on Ubuntu 16.04 (inside Bash on Windows),
> using GCC 7.2 and 6.3 and Boost 1.58 - all installed from Xenial packages.
> I'm experiencing the linker failure for libosrm_extract.a around 
> libboost_regex.
>
> It has been a while (~6 weeks) since I built OSRM master last time,
> but the OSRM used to build fine in that environment.
>
> I'm puzzled, because I see the Travis CI builds are perfectly green.
>
> I wonder if anyone experienced similar issue.
>
> Below, I paste the g++ command with link error.
> As you can see all of the Boost libraries (and some others) are repeated,
> but that should not be relevant to the issue. In fact, I tried w/o the 
> redundant
> libs to confirm the linking still fails.
>
>
> /usr/bin/g++-6-Wall -Wextra -pedantic -Wuninitialized
> -Wunreachable-code -Wstrict-overflow=1 -U_FORTIFY_SOURCE
> -D_FORTIFY_SOURCE=2 -fdiagnostics-color=auto -fPIC
> -ftemplate-depth=1024 -ffunction-sections -fdata-sections -std=c++14
> -O3 -DNDEBUG   -fuse-ld=gold -Wl,--disable-new-dtags
> -Wl,--gc-sections -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common
> CMakeFiles/osrm-extract.dir/src/tools/extract.cpp.o  -o osrm-extract
> -rdynamic libosrm_extract.a -lboost_program_options -lbz2
> -lboost_regex -lboost_date_time -lboost_chrono -lboost_filesystem
> -lboost_iostreams -lboost_thread -lboost_system -lpthread -lexpat
> -llua5.2 -lm -lz -ltbb -ltbbmalloc -lbz2 -lboost_regex
> -lboost_date_time -lboost_chrono -lboost_filesystem -lboost_iostreams
> -lboost_thread -lboost_system -lpthread -lexpat -llua5.2 -lm -lz -ltbb
> -ltbbmalloc
> libosrm_extract.a(restriction_parser.cpp.o):restriction_parser.cpp:function
> __gnu_cxx::__normal_iterator std::__cxx11::basic_string std::allocator > >
> boost::re_detail::re_is_set_member<__gnu_cxx::__normal_iterator const*, std::__cxx11::basic_string std::allocator > >, char, boost::regex_traits boost::cpp_regex_traits >, unsigned
> int>(__gnu_cxx::__normal_iterator std::__cxx11::basic_string std::allocator > >, __gnu_cxx::__normal_iterator std::__cxx11::basic_string std::allocator > >, boost::re_detail::re_set_long
> const*, boost::re_detail::regex_data boost::cpp_regex_traits > > const&, bool): error: undefined
> reference to 
> 'boost::re_detail::cpp_regex_traits_implementation::transform_primary[abi:cxx11](char
> const*, char const*) const'
> libosrm_extract.a(restriction_parser.cpp.o):restriction_parser.cpp:function
> __gnu_cxx::__normal_iterator std::__cxx11::basic_string std::allocator > >
> boost::re_detail::re_is_set_member<__gnu_cxx::__normal_iterator const*, std::__cxx11::basic_string std::allocator > >, char, boost::regex_traits boost::cpp_regex_traits >, unsigned
> int>(__gnu_cxx::__normal_iterator std::__cxx11::basic_string std::allocator > >, __gnu_cxx::__normal_iterator std::__cxx11::basic_string std::allocator > >, boost::re_detail::re_set_long
> const*, boost::re_detail::regex_data boost::cpp_regex_traits > > const&, bool): g[abi:cxx11](char
> const*, char const*) const'
>
> --
> 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: [Talk-de] Routenplanung mit osrm

[Patrick Niklaus]

Hey,

sorry eigentlich haben wir nichts vom Netz genommen, wir werden nur
regelmäßig von Leuten DDOSed und dann geht der Server halt down.
OSM.org wollen wir nur wechseln weil es relativ viel Arbeit ist zwei
Server zu betreuen und die meisten nicht wirklich Lust haben sich da
Sonntag Nachmittag darum zu kümmern.
Ich habe es mal neu gestartet, sollte wieder gehen.

Cheers,
Patrick

2017-10-08 13:37 GMT+00:00 chris66 :
> Am 08.10.2017 um 15:22 schrieb Peter Pointner:
>
>> derzeit nicht verfügbar ist, da der bislang dafür verwendete
>> OSRM-Demoserver ohne
>> Vorwarnung vom Netz genommen wurde."
>
>
> Ja, daran liegt es wohl. Andere Frage ist, wieso der Link dann auf
> openstreetmap.org nicht temporär entfernt wird oder zumindest ein
> passender Hinweis eingeblendet wird.
>
> Chris
>
>
>
>
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [OSRM-talk] (no subject)

[Patrick Niklaus]

Hey Jason,

our routing is fully customizable using profile written in Lua. For an
example see here:
https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua
You should be able to base your custom profile on the ones that already
ship with OSRM.

Cheers,
Patrick

On Tue, Aug 29, 2017 at 8: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] MLD algorithm

[Patrick Niklaus]

Hey,

Nope it finds optimal paths. The heuristic part of it only determines how
you would devide the road network. This has no impact on correctness, it
only has an impact on speed/memory usage.

Cheers,
Patrick

Am 30.07.2017 01:31 schrieb "Frederik Ramm" :

> Hi,
>
>I'm working on a presentation about different routing engines I want
> to give at this year's SOTM in Tokyo and I want to feature OSRM's new
> MLD there too.
>
> I'm a bit confused by the word "heuristic" that often pops up when you
> read papers about MLD. Is MLD in principle guaranteed to find an optimal
> solution, or could there be freak cases where a sub-optimal solution is
> returned?
>
> 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

[OSRM-talk] Released OSRM 5.7.0

[Patrick Niklaus]

Hey!

this release features some exiting new improvements: A new routing algorithm.

= Core =

After months of work this release is the first to feature an
additional routing algorithm next to Contraction Hierarchies.
It's based on a Multi-Level Dijkstra approach, partitioning the road
network and allowing for incredible fast weight updates. This is a
trade-off between processing time and query speed: MLD based queries
are about a factor two to three slower then queries on a full CH.

The new algorithm is still experimental and we are working on feature
parity with Contraction Hierarchies: so far the `route` and `match`
plugins are supported.

For a continental sized network we expect partitioning to take in the
order of minutes and fully updating weights under a minute.

Quickstart:

osrm-extract data.osm.pbf
osrm-partition data.osrm
osrm-customize data.osrm
osrm-routed --algorithm=MLD data.osrm

=  Node.js Bindings =

We merged the Node.js bindings `node-osrm` into the `osrm-backend`
repository, with the hopes of an easier development workflow.

You can build them using cmake via

cmake .. -DCMAKE_BUILD_TYPE=Release -DENABLE_NODE_BINDINGS=On
-DENABLE_MASON=On

or just use `npm install osrm` for pre-built packages.

= Map Matching =

New option `gaps=split|ignore` to enable / disbale track splitting.

New option `tidy=true|false` to simplify traces automatically and remove blobs.
Use this option or tidy your noisy traces (e.g. with
[geojson-tidy](https://github.com/mapbox/geojson-tidy)) can increase
the Map Matching's quality.

= Profiles =

Important in case you're using the segment function: we added a
`force_split_edges` flag to the global properties which - when set to
true - guarantees that the segment function will be called for all
segments, but also doubles memory consumption in the worst case.

= Full changelog =

  - Changes from 5.6
- Bug fixes:
  - Fixed 505: Invalid distance value for distance as routing weight.
  - Fixed 3958: Fix traffic light penalties for non-turns
  - Fixed 3933: crash when collapsing instructions
- Algorithm:
  - OSRM object has new option `algorithm` that allows the
selection of a routing algorithm.
  - New experimental algorithm: Multi-Level Dijkstra with new toolchain:
- Allows for fast metric updates in below a minute on
continental sized networks (osrm-customize)
- Plugins supported: `match` and `route`
- Quickstart: `osrm-extract data.osm.pbf`, `osrm-partition
data.osrm`, `osrm-customize data.osrm`, `osrm-routed --algorithm=MLD
data.osrm`
- NodeJs Bindings
  - Merged https://github.com/Project-OSRM/node-osrm into
repository. Build via `cmake .. -DCMAKE_BUILD_TYPE=Release
-DENABLE_NODE_BINDINGS=On -DENABLE_MASON=On`.
  - `OSRM` object has new option `algorihtm="CH","CoreCH","MLD"`
- Internals
  - Shared memory notification via conditional variables on Linux
or semaphore queue on OS X and Windows with a limit of 128 OSRM Engine
instances
- Files
  - .osrm.datasource_index file was removed. Data is now part of
.osrm.geometries.
  - .osrm.edge_lookup was removed. The option
`--generate-edge-lookup` does nothing now.
  - `osrm-contract` does not depend on the `.osrm.fileIndex` file anymore
  - `osrm-extract` creates new file `.osrm.cnbg` and `.cnbg_to_ebg`
  - `osrm-partition` creates new file `.osrm.partition` and `.osrm.cells`
  - `osrm-customize` creates new file `.osrm.mldgr`
- Profiles
  - Added `force_split_edges` flag to global properties. True
value guarantees that segment_function will be called for all
segments, but also could double memory consumption
- Map Matching:
  - new option `gaps=split|ignore` to enable/disbale track splitting
  - new option `tidy=true|false` to simplify traces automatically

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

[OSRM-talk] Released OSRM 5.6.0

[Patrick Niklaus]

Hey,

The 5.6.0 release features some great new features. Most importantly
we now support the infamous issue
[#77](https://github.com/Project-OSRM/osrm-backend/issues/77): Routing
on generic weights, not only the duration. This increased our resource
usage quite a bit, so if you are running global deployments make sure
you have enough headroom before upgrading. The car profile makes use
of this new feature by penalizing turns onto restricted streets
(hov-only, `access=destination`) heavily. This makes sure we don't
route through them but still support starting/stopping from them. We
also dropped our dependency on luabind and replaced it with the
awesome sol2 that we can bundle as header-only library.
The trip plugin also saw some improvements with regard to allowing you
to do non-roundtrips and explicitly selecting the first/last node as
start and end-points.

---

 Tags
- Never route over `highway=steps` in the car profile even if access
tags allow it. This is a case of Wiki vs real-data where we pick the
sensible solution for users. See
[#3435](https://github.com/Project-OSRM/osrm-backend/issues/3435) and
[#3668](https://github.com/Project-OSRM/osrm-backend/pull/3668).
- Support `destination:street` tag. See
[#3543](https://github.com/Project-OSRM/osrm-backend/pull/3543).
- Support `surface=sett` for the bike profile. See
[#3657](https://github.com/Project-OSRM/osrm-backend/pull/3657).
- We now respect `access=destination` and only route there when the
start/destination is on that road.
- We now route over hov-only roads, when the start point is already on one.

 API
- Added an option `generate_hints` (`true` by default) which allows to
prevent the engine to generate hints. If there is no need for hints
use this to make the response considerably smaller. See
[#3456](https://github.com/Project-OSRM/osrm-backend/pull/3456).
- `annotations` now also supports a list of specific values like
`distances,nodes,speeds` to only include data selectively.
- The trip plugin supports two new parameters
`round_trip={true,false}` and `source={first,any}` and
`destination={first,any}`.

 Infrastructure
- We disabled Link-Time Optimization by default when building from
source as it lead to complications with old compilers and binutils. If
your system is recent enough and you know what you are doing pass
`-DENABLE_LTO=ON` to CMake. See
[#3524](https://github.com/Project-OSRM/osrm-backend/pull/3524).
- Updated to the latest libosmium version which allows us to skip PBF
metadata improving parsing speed up by 10-20%. If you need metadata on
OSM Objects (think: a way object's version) use `osrm-extract
--with-osm-metadata`. See
[#3373](https://github.com/Project-OSRM/osrm-backend/pull/3373).
- Luabind is no longer required. We removed Luabind completely and
vendor sol2 for bindings now. See
[#3382](https://github.com/Project-OSRM/osrm-backend/pull/3382).
- We refactored the
[car](https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua)
/ 
[bike](https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/bicycle.lua)
and 
[foot](https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/foot.lua)
profile. They should be more readable and easier to get into now.
Thanks Emil Tin for your efforts here.

 Tools
- We re-wrote the `osrm-components` tool: it generates a GeoJSON small
components layer now. See
[#3570](https://github.com/Project-OSRM/osrm-backend/pull/3570).
- There is a new tool `osrm-extract-conditionals` for processing
conditional tags (opening hour grammar). See
[#3414](https://github.com/Project-OSRM/osrm-backend/issues/3414) and
[#3415](https://github.com/Project-OSRM/osrm-backend/pull/3415).

---

[Full 
Changelog](https://github.com/Project-OSRM/osrm-backend/blob/master/CHANGELOG.md#560)

Cheers,
Patrick

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

Re: [OSRM-talk] Newbie question: routing for pedestrians, wheelchair, DEM data?

[Patrick Niklaus]

Hey,

unfortunately we don't have an official wheelchair profile. I think
the nice people from OpenRouteService have a great one though:

http://www.openrouteservice.org/

That said you can probably get a naive version if you modify our
foot.lua profile by excluding obstacles like steps (tread them like
barriers). Though even for walking that profile is not that great so
use with care.

Cheers,
Patrick



On Thu, Feb 2, 2017 at 9:21 AM,   wrote:
> hi,
>
> we are currently evaluating routing frameworks for offline routing. We are
> interrested in routings for pedestrians and wheelchair mode.
> So I have some questions, I didn't get answered in the docu.
>
> I followed the steps described in the wiki. Routing for pedestrian was
> running out of the box.
> Unfortunately not so for wheelchair. I tested the profile:
> (https://github.com/species/osrm-wheelchair-profiles), but the setup throws
> errors.
>
> So my questions:
> - Does OSRM support wheelchair routing?
> - What about elevation data?
>
> TIA
> gve
> __
>
>
>
> IDV AG Individuelle Softwarelösungen
>
>
>
> Vorstand : Robert Strassmeir
>
> Vors. des Aufsichtsrates : Dr. Brigitte Holler
>
> Sitz der Gesellschaft : München
>
> Amtsgericht München HRB 122 701
>
>
>
> ___
> 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 Release 5.4.1

[Patrick Niklaus]

Hey,

we just release OSRM 5.4.1 containing a bug fix for issue #3016. This
fixes data updates when using shared memory and requests are being
executed at the time of processing.

As always there is a corresponding node-osrm release as well.

Best,
Patrick

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

Re: [OSRM-talk] Ferries dot gone?

[Patrick Niklaus]

Hey Jürgen,

I think you are hitting a change in behavior that occurred between the
4.9 and 5.0 versions. It is not possible to start on ferries anymore.
That means if a route over a ferry is not the fastest route, it will
not get taken. Combine that with the fact that most ferries don't have
a `duration` tag (hence defaulting to a speed of 5 km/h), you will
only see them used if there is absolutely no way.

However in the case above, I think you are hitting a different
problem: The island is not reachable because the paths on the ferry
are not accessible by cars:

http://map.project-osrm.org/?z=18=38.013485%2C12.512650=38.013535%2C12.513288=38.012737%2C12.511910=en=0

http://map.project-osrm.org/?z=18=37.933299%2C12.325405=37.933282%2C12.325196=37.933227%2C12.325501=en=0

I'm not sure if these ferries are generally accessible by car, but the
tagging would need to be fixed for that.

Best,
Patrick

On Thu, Aug 11, 2016 at 3:42 PM, Jürgen Barthel  wrote:
> Hi, we had some trouble lately with OSRM, where both
> openstreetmap.org/directions/ and http://map.project-osrm.org/ where our
> mapping expert found that the demo-server was to be fixed.
>
> Now on openstreetmap.org/directions/ a lot of routes don't work any more,
> which I have seen before I opened error notes on OSM, i.e.
> http://www.openstreetmap.org/directions?engine=osrm_car=37.9313%2C12.3274%3B38.1765%2C13.0917
> (Saint Malo-Cherbourg to Dorchester,
> http://www.openstreetmap.org/note/617142). See also
> http://www.openstreetmap.org/note/599194 where it seems the mistake got
> solved but OSRM doesn't compute it.
>
> Something wrong on OSRM side? I tried several (20+) ferries (Scotland,
> Channel Islands, Mediterranean, Baltic Sea) but could not find a single
> working any more.
>
> Thanks for feedback - Juergen
>
> ___
> 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] Released OSRM 5.3.1 and 5.2.8

[Patrick Niklaus]

Hey,

we released OSRM 5.3.1 and 5.2.8 that fixes some problems that were
caused by a data import in Egypt and some lane guidance edge cases
that cause problems.


Changelog 5.2.8:
  - Bugfixes:
- Handle an edge case that cause the turn instruction code to
segfault during osrm-extract on Egypt.

Changelog 5.3.1:
  - Bugfixes:
 - Disabled broken lane handling for complex uturn/oneway
combinations for now (190 intersections affected on the planet)
 - Fixed a bug with overlaping geometries, which broke OSRM on
recent Egypt extracts with data-modelling issues

As always both come with node-osrm binaries.

Cheers,
Patrick

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

[OSRM-talk] Shutdown of the OSRM 4.9 demo server Friday August 12th

[Patrick Niklaus]

Hey,

OpensStreetMap.org just switched to our new OSRM 5.x endpoint[1], that
means we will shutdown the 4.9 demo server on August 12th 2016. Please
migrate all or legacy services to the new 5.x API.

Thanks,
Patrick

[1] https://github.com/openstreetmap/openstreetmap-website/pull/1261

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

[OSRM-talk] OSRM 5.3.0

[Patrick Niklaus]

Hey,

we just released OSRM 5.3.0. This releases brings some exiting changes
with regard to the 5.2 series. Most importantly we now have support
for turn lanes. Thanks to all contributors of this release. Our
special thanks goes to Michael Krasnyk for contributing various bug
fixes and ARM support.

See the changelog below:

  Changes form 5.2.7
- API
  - Introduces new `TurnType` in the form of `use lane`. The type
indicates that you have to stick to a lane without turning
  - Introduces `lanes` to the `Intersection` object. The lane data
contains both the markings at the intersection and a flag indicating
if they can be chosen for the next turn
  - Removed unused `-s` from `osrm-datastore`
- Guidance
  - Only announce `use lane` on required turns (not using all
lanes to go straight)
  - Improved detection of obvious turns
  - Improved turn lane detection
  - Reduce the number of end-of-road instructions in obvious cases
- Profile:
  - bicycle.lua: Surface speeds never increase the actual speed
- Infrastructure
  - Add 32bit support
  - Add ARM NEON/VFP support
  - Fix Windows builds
  - Optimize speed file updates using mmap
  - Add option to disable LTO for older compilers
  - BREAKING: The new turn type changes the turn-type order. This
breaks the **data format**.
  - BREAKING: Turn lane data introduces two new files
(osrm.tld,osrm.tls). This breaks the fileformat for older versions.
- Bugfixes:
  - Fix devide by zero on updating speed data using osrm-contract

As always there is a corresponding node-osrm release.

Best,
Patrick

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

[OSRM-talk] OSRM 5.2 Release

[Patrick Niklaus]

Hey,

we just released OSRM 5.2.2 (yeah 2nd bug fix release..) This release
brings a number of big features like route annotation (we expose OSM
IDs of the traversed segments when passing `annotations=true`),
intersection information for detailed display of turn icons, support
for destination signs and way-name pronunciations.

You find the detailed changelog below:

# 5.2.2
  Changes from 5.2.1
  - Bugfixes:
- Buffer overrun in tile plugin response handling

# 5.2.1
  Changes from 5.2.0
  - Bugfixes:
- Removed debug statement that was spamming the console

# 5.2.0
   Changes from 5.1.0
   - API:
 - new parameter `annotations` for `route`, `trip` and `match`
requests.  Returns additional data about each
   coordinate along the selected/matched route line per `RouteLeg`:
 - duration of each segment
 - distance of each segment
 - OSM node ids of all segment endpoints
 - Introducing Intersections for Route Steps. This changes the API
format in multiple ways.
 - `bearing_before`/`bearing_after` of `StepManeuver` are now
deprecated and will be removed in the next major release
 - `location` of `StepManeuvers` is now deprecated and will be
removed in the next major release
 - every `RouteStep` now has property `intersections`
containing a list of `Intersection` objects.
 - Support for destination signs. New member `destinations` in
`RouteStep`, based on `destination` and `destination:ref`
 - Support for name pronunciations. New member `pronunciation` in
`RouteStep`, based on `name:pronunciation`

   - Profile changes:
 - duration parser now accepts P[n]DT[n]H[n]M[n]S, P[n]W, PTHHMMSS
and PTHH:MM:SS ISO8601 formats.
 - `result.destinations` allows you to set a way's destinations
 - `result.pronunciation` allows you to set way name pronunciations
 - `highway=motorway_link` no longer implies `oneway` as per the OSM Wiki

   - Infrastructure:
 - BREAKING: Changed the on-disk encoding of the StaticRTree to
reduce ramIndex file size. This breaks the **data format**
 - BREAKING: Intersection Classification adds a new file to the
mix (osrm.icd). This breaks the fileformat for older versions.
 - Better support for osrm-routed binary upgrade on the fly [UNIX specific]:
   - Open sockets with SO_REUSEPORT to allow multiple osrm-routed
processes serving requests from the same port.
   - Add SIGNAL_PARENT_WHEN_READY environment variable to enable
osrm-routed signal its parent with USR1 when it's running and waiting
for requests.
 - Disable http access logging via DISABLE_ACCESS_LOGGING
environment variable.

   - Guidance:
 - BREAKING: modifies the file format with new internal identifiers
 - improved detection of turning streets, not reporting new-name
in wrong situations
 - improved handling of sliproads (emit turns instead of 'take the ramp')
 - improved collapsing of instructions. Some 'new name'
instructions will be suppressed if they are without alternative and
the segment is short

   - Bugfixes
 - fixed broken summaries for very short routes

To install this release using `node-osrm` please do:

```
npm install osrm@5.2.2`
```

To fetch the source of the C++ backend download it at
https://github.com/Project-OSRM/osrm-backend/archive/v5.2.2.tar.gz

Cheers,
Patrick

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

[OSRM-talk] Released OSRM 5.1.0

[Patrick Niklaus]

Hey,

we just released OSRM 5.1.0. This release brings a lot of bug fixes
from `5.0.2` and features that didn't make it into 5.0.0 before the
release such as three new maneuver types for better handling ramps and
roundabouts and instruction post-processing. We now utilize
destination sign information for better instructions when navigating
highways.

My special thanks goes to Michael Krasnyk who has contributed multiple
bug fixes and a great speed improvement for the coordinate snapping.
Together with some speed improvements this yields radically faster map
matching. Check it out!

Changes with regard to 5.0.0

   - API:
 - added StepManeuver type `roundabout turn`. The type indicates a
small roundabout that is treated as an intersection
(turn right at the roundabout for first exit, go straight at
the roundabout...)
 - added StepManeuver type `on ramp` and `off ramp` to distinguish
between ramps that enter and exit a highway.
 - reduced new name instructions for trivial changes
 - combined multiple turns into a single instruction at segregated roads

   - Profile Changes:
- introduced a suffix_list / get_name_suffix_list to specify name
suffices to be suppressed in name change announcements
- street names are now consistently assembled for the car, bike
and walk profile as: "Name (Ref)" as in "Berlin (A5)"
- new `car.lua` dependency `lib/destination.lua`
- register a way's .nodes() function for use in the profile's way_function.

   - Infrastructure
- BREAKING: reordered internal instruction types. This breaks the
**data format**
- BREAKING: Changed the on-disk encoding of the StaticRTree for
better performance. This breaks the **data format**

   - Fixes:
- Issue #2310: post-processing for local paths, fixes #2310
- Issue #2309: local path looping, fixes #2309
- Issue #2356: Make hint values optional
- Issue #2349: Segmentation fault in some requests
- Issue #2335: map matching was using shortest path with uturns disabled
- Issue #2193: Fix syntax error position indicators in parameters queries
- Fix search with u-turn
- PhantomNode packing in MSVC now the same on other platforms
- Summary is now not malformed when including unnamed roads
- Emit new-name on when changing from unnamed road to named road

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

npm install osrm@5.1.0

Cheers,
Patrick

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

[OSRM-talk] OSRM 5.0.0 Relaese Candidate 2

[Patrick Niklaus]

Hey,

We just tagged `v5.0.0-rc.2`. This RC includes the following changes since RC1:

- API changes:
   - Removed summary from legs property
   - Disable steps and alternatives by default
   - Fix `code` field: 'ok' -> 'Ok'
   - Allow 4.json and 4.3.json format
   - Conform to v5 spec and support "unlimited" as radiuses value.
- Features:
   - Report progress for gennerating edge expanded edges in the edge
based graph factory
   - Add maxspeed=none tag to car profile.
   - Optimize StaticRTree code: speedup 2x (to RC1)
   - Optimize DouglasPeucker code: speedup 10x (to RC1)
   - Optimize WebMercator projection: speedup 2x (to RC1)
- Bug fixes:
   - #2195: Resolves issues with multiple includedirs in pkg-config file
   - #2219: Internal server error when using the match plugin
   - #2027: basename -> filename
   - #2168: Report correct position where parsing failed
   - #2036: Add license to storage and storage config exposed in public API
   - Fix uturn detection in match plugin
   - Add missing -lz to fix linking of server-tests

This release is again in conjunction with a `node-osrm` release `v5.0.0-rc.2`.
Thanks to everyone who helped with this release!

If you want to try it out, the usual `http://router.project-osrm.org`
domain now also supports requests in the V5 API scheme.

Cheers,
Patrick

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

Re: [OSRM-talk] osrm-extract taking hours to complete

[Patrick Niklaus]

Hey Kieran,


there have been a lot of structural changes (e.g. moving code from
osrm-prepare into osrm-extract) that probably invalidate that numbers.
Also we support 64bit OSM ids now, which sadly uses a lot more disk
space. I think stxxl need like 200GB. I think on our setup we have a
turn-around of 6 hours for the planet dataset on an SSD setup (car
profile, any other profile needs significantly longer). You should
probably think about updating your hard drives as this is IO bound. At
your current read/write speed it will already take more than an hour
to just write 200GB of data once. We scan it at least twice just for
pre-processing.

Cheers,
Patrick


On Wed, Mar 2, 2016 at 5:51 PM, Kieran Caplice
 wrote:
> Hello,
>
> I'm currently extracting the planet PBF (~31 GB), and it's been running for
> hours. I notice in the "Running OSRM" wiki page, it says " On a Core i7 with
> 8GB RAM and (slow) 5400 RPM Samsung SATA hard disks it took about 65 minutes
> to do so from a PBF formatted planet", which is making me wonder why it's
> taking so long on our server. Below are some example output messages:
>
> [info] Parsing finished after 3584.35 seconds
> [extractor] Erasing duplicate nodes   ... ok, after 319.091s
> [extractor] Sorting all nodes   ... ok, after 3632.87s
> [extractor] Building node id map  ... ok, after 2025.29s
> [extractor] Confirming/Writing used nodes ... ok, after 1096.24s
> [extractor] Sorting edges by start... ok, after 2000.08s
>
> Some stxxl errors were outputted as I set the disk size to 100GB thinking it
> was enough - but I didn't think it would cause such slowdowns as this,
> considering extracting the Europe PBF takes hours also without the stxxl
> errors.
>
> Server specs:
> Ubuntu 14.04
> Intel Xeon CPU E5-1650 v3 @ 3.50GHz  (hex-core with HT)
> 64 GB RAM @ 2133 MHz
> 2 TB Western Digital Enterprise 7200 RPM hard drive
>
> At the moment, disk IO is averaging around 35-40 MB/s R/W (~90%).
>
> Anyone have any ideas as to what might be going on? Or is it normal to take
> this long without an SSD?
>
> 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] Feature broken down

[Patrick Niklaus]

Hey Jack,

we no longer support GPX. I would suggest you try to generate a
GeoJSON from the response geometry with polyline.decode [1] and togpx
[2].

Best of luck,
Patrick

[1] https://github.com/mapbox/polyline
[2] https://github.com/tyrasd/togpx

On Sun, Feb 28, 2016 at 10:45 PM, Jack Rabbit
 wrote:
> A few months ago, I was using the feature to create a route between two
> latitudes/longitudes and exporting them in a GPX format.  That way I could
> plan a route and download it to my GPS before doing a ride.  This no longer
> works, it just creates an empty GPX file, without any track:
>
>
> http://router.project-osrm.org/viaroute?loc=44.129,-79.3206=43.99257,-79.04079=gpx
>
>
> Is this a bug or it is because this feature is no longer supported?
>
>
> Jack
>
>
> ___
> 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] Breaking server API changes

[Patrick Niklaus]

Hey!

We are currently working on a new API that will follow the spec
specified at [1]. You can find the discussion about that here [2] (yes
that ticket is really 4 years old).

This means as soon as we merge the pull request into our develop
branch the demo server API will break. There is **no fallback** to the
old API. If you rely on the demo server for your service, implement
the new API spec NOW.

As you can see the API got a significant clean up, text identifiers
instead of implicit addressing and a consistent response structure for
all plugins.

We will work with upstream providers to get the new API format into
LRM before we do the switch.

Cheers,
Patrick

[1] https://github.com/Project-OSRM/osrm-backend/wiki/New-Server-api
[2] hhttps://github.com/Project-OSRM/osrm-backend/issues/519

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

Re: [OSRM-talk] Getting OSMNodeIDs in OSRM

[Patrick Niklaus]

Hey Kerrick,

the data is not available in the server anymore, but you can load it
to memory if you like (which will increase the memory consumption
quite a bit on large datasets). The idea is to adapt this [1] function
to load a exteractor::ExternalMemoryNode vector to array that can
translate from NodeID (the index to that array) to the OSM id (the id
property of the struct).

[1] 
https://github.com/Project-OSRM/osrm-backend/blob/f5c12ec4330c0c835fc09dc349878e4fc670b861/include/util/graph_loader.hpp#L65-L105

Hope this helps!

Cheers,
Patrick

On Mon, Feb 1, 2016 at 6:03 PM, 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

[OSRM-talk] Released OSRM v4.9.1

[Patrick Niklaus]

Hey,

I just pushed out OSRM v4.9.1 [1] that contains fixes for the following bugs:

- #1850: Crash in trip service when specifing two coodinates
- #1908: Inconsistent instructions format in last instruction
- #1888: Race condition when running `osrm-datastore`
- #1896: U-Turn error in one-way streets

As always node-osrm binaries are available as well.

Cheers,
Patrick

[1] https://github.com/Project-OSRM/osrm-backend/releases/tag/v4.9.1

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

[OSRM-talk] OSRM 4.9.0 released

[Patrick Niklaus]

# 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).
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 way can be a start point for a route (e.g. is set to
`false` for ferry ways).

# Thanks

Thanks to all the contributers of this release:

- Arne Kaiser
- Daniel J. Hofmann
- Daniel Patterson
- Fabien Girard
- Johan Uhle
- Jordan Markov
- Kal Conley
- Lauren Budorick
- Moritz Kobitzsch
- Rohan Paranjpe

Cheers,
Patrick

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

[OSRM-talk] Server API change

[Patrick Niklaus]

Hey!

in preparation to the OSRM v4.9.0 release we merged a few pull
requests to our development branch. These changes are now reflected on
the demo server:

- The status code for `ok` was changed from `status: 0` to `status: 200`
- There is an additional status code `208` for no segment found (with
regard to failed coordinate snapping)
- `viaroute` has a maximum limit of 500 coordinates
- `trip` has a maximum limit of 100 coordinates
- `locate` service gone, use `nearest` instead

You can expect the official 4.9.0 release soon, as we sort out the last bugs.

Cheers,
Patrick

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

Re: [OSRM-talk] Navteq (esri .map) to osrm problems

[Patrick Niklaus]

From the output I would guess the data is not tagged correctly. There
are ways but they don't adhere the OSM tagging conventions. In general
this is not an easy task and you can expect to spend multiple
man-months on this project. There is no easy way to "convert". You
need to figure out the exact features you want to map and how to
translate that into something that looks like OSM. In general I would
question your choice of using NAVTEQ data instead of OSM to begin
with. For the US both will be mostly based on TIGER anyway.

You can try to use this project as base:

https://github.com/knowname/morituri

I know of several pipelines that do exactly this, but all proprietary
because of licensing issues (sometimes even the specification is
confidential).

Good luck,
Patrick

On Wed, Dec 16, 2015 at 9:31 PM, Alan Grover  wrote:
> (Rather than start with a plea for help, I'd _really_ thank you for osrm.)
>
> I'm using osrm for time/distance matrices, and geometry (and
> turn-by-turn in the near future). I've been running it with the
> berlin-latest data from openstreetmap for testing/development. That's
> been working well, and impressively.
>
> Of course, I need to use Navteq U.S. and Canada for production. But, I
> can't figure out how to get the data into osrm (yea, I know this will
> take a gazillion cpu cycles, and a lot of ram to do the conversion.)
>
> The first question is: is this too much of a task for someone (me) who
> is not a gis expert? Do you know who I can hire to help me with this.
>
> The second question is: can you help me figure out the steps to get
> navteq data into osrm?
>
> I have only a spotty understanding of the data/concepts for esri & osrm,
> so I can't figure out what is wrong:
>
> 1. The navteq data was being used in esri. Our gis specialist (doesn't
> know openstreetmap) exported it in ".map" format. Here's the cut-down
> files I start with (just Delaware):
>
> ls -l map-data/Delaware.map
> -rw-rw 1 me me 36617162 Jan 19  2015 Streets.DAT
> -rw-rw 1 me me   349536 Jan 19  2015 Streets.ID
> -rw-rw 1 me me 21741056 Jan 19  2015 Streets.IND
> -rw-rw 1 me me  7585280 Jan 19  2015 Streets.MAP
> -rw-rw 1 me me 3086 Jan 19  2015 Streets.TAB
> -rw-rw 1 me me 10654217 Jan 19  2015 Zlevels.DAT
> -rw-rw 1 me me  1469516 Jan 19  2015 Zlevels.ID
> -rw-rw 1 me me  9404416 Jan 19  2015 Zlevels.IND
> -rw-rw 1 me me  6843904 Jan 19  2015 Zlevels.MAP
> -rw-rw 1 me me  305 Jan 19  2015 Zlevels.TAB
>
> 2. I choose ogr2osm.py (https://github.com/pnorman/ogr2osm.git) to do
> the conversion to osm. I choose that because it seemed to be relatively
> up-to-date, and one-step (compared to -> gml -> osm). Maybe I should
> have used a different process?
>
> python map-data/ogr2osm.py -d -o map-data/Delaware.map.osm/Delaware.osm
> map-data/Delaware.map/
>
> running with lxml.etree
> Preparing to convert 'map-data/Delaware.map/' to
> 'map-data/Delaware.map.osm/Delaware.osm'.
> Will try to detect projection from source metadata, or fall back to
> EPSG:4326
> Using default translations
> Using default filterLayer
> Using default filterFeature
> Using default filterTags
> Using default filterFeaturePost
> Using default preOutputTransform
> Parsing data
> Detected projection metadata:
> GEOGCS["unnamed",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563],
> TOWGS84[0,0,0,0,0,0,0]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433]]
> Detected projection metadata:
> GEOGCS["unnamed",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563],
> TOWGS84[0,0,0,0,0,0,0]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433]]
> Merging points
> Making list
> Checking list
> Merging duplicate points in ways
> Outputting XML
>
> -rw-rw 1 me me 325449558 Dec 16 12:09 Delaware.osm
>
> 3. It seems like osrm-extract will accept .osm files, so I used that.
>
> The profile.lua is osrm-backend/profiles/car.lua.
>
> osrm-backend is https://github.com/Project-OSRM/osrm-backend.git,
> branch develop
> last commit: Date:   Fri Nov 20 19:52:22 2015 +0100
> compiled on ubuntu 14.04 as per instructions.
> (nb, the osrm stuff worked fine "extracting" and "preparing" the
> berlin-latest data).
>
> I was using the develop branch because it seemed to have more recent
> fixes. Perhaps I should be on master for stability? (yes, this will be
> used for production processes, periodically).
>
> So, the obvious problem happens here:
>
> osrm-extract map-data/Delaware.map.osm/Delaware.osm
>
> [info] Input file: Delaware.osm
> [info] Profile: profile.lua
> [info] Threads: 4
> [info] Using script profile.lua
> [STXXL-MSG] STXXL v1.3.1 (release)
> [STXXL-ERRMSG] Warning: no config file found.
> [STXXL-ERRMSG] Using default disk configuration.
> [STXXL-MSG] 1 disks are allocated, total space: 1000 MiB
> [info] Parsing in progress..
> [info] input file generated 

Re: [OSRM-talk] Shortest path post-processing

[Patrick Niklaus]

Hey Franics!


the naming is a little bit unfortunate in that code path. I started
refactoring this a little bit but got caught up in other tasks. What
UnpackPath() actually does it to unpack (remove shortcut edges) _and_
decompress (translate it to a geometry). That means the node ids you
get back don't fit into the edge-based-graph that is used in facade.

What I would suggest in this case is to take a look at the
alternative_path.hpp file. The alternative search needs to to
something similar (unpack paths to do post-processing).[1] You can
basically copy that code and unpack the path yourself. The resulting
path will work for `facade` (as you can see a few lines lower)

[1] 
https://github.com/Project-OSRM/osrm-backend/blob/5a9bee052753ab6c978e60ac2ca331f2ed378aa8/routing_algorithms/alternative_path.hpp#L433
[2] 
https://github.com/Project-OSRM/osrm-backend/blob/5a9bee052753ab6c978e60ac2ca331f2ed378aa8/routing_algorithms/alternative_path.hpp#L469

Hope this helps.

Cheers,
Patrick

On Sun, Dec 13, 2015 at 10:05 PM, Francis Giraldeau
 wrote:
> Hello!
>
> I would like to do some post-processing on the resulting shortest path using
> edges from the graph. In ViaRoutePlugin, I tried to iterate on the
> raw_route.unpacked_path_segments, but the BeginEdges(node) and
> EndEdges(node) returns an empty range as if the a segment is not connected
> to the next.
>
> for (std::vector data: raw_route.unpacked_path_segments) {
>
> std::cout << "DEBUG FOR EACH NODE:" << std::endl;
>
> for (int i = 0; i < data.size(); i++) {
>
> PathData path = data[i];
>
> std::cout << "[" << facade->BeginEdges(path.node) << ", " <<
>
>  facade->EndEdges(path.node) << "]" << std::endl;
>
> for (const auto edge : facade->GetAdjacentEdgeRange(path.node)) {
>
> std::cout << edge << std::endl;
>
> }
>
> }
>
> }
>
>
> What would be the right way to iterate on segments and access the EdgeData?
>
>
> Thanks!
>
>
> 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] Demo server down time

[Patrick Niklaus]

The problem was fixed and we are back up. We are running the server in
debug mode for now, to catch assertions and have faster turn-a-rounds
on bugs like this. That means queries will be somewhat slower. The
load on the server is pretty low however, so I don't expect any
serious performance implications for most users.

Best,
Patrick

On Thu, Dec 10, 2015 at 5:42 PM, Patrick Niklaus
<patrick.nikl...@student.kit.edu> wrote:
> Hey!
>
> looks like a PR that was merged into develop is currently causing
> segmentation faults from time to time. I'm currently investigating and
> as such the server will have some mixed uptime today.
>
> Cheers,
> Patrick

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

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

[Patrick Niklaus]

Hey,

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

Cheers,
Patrick


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

On Wed, Dec 9, 2015 at 11:38 AM, Kieran Caplice
 wrote:
> Hello,
>
> At the moment we're using the MapQuest Optimize Route API
> (http://www.mapquestapi.com/directions/#optimized), which given a list of
> points, computes the shortest route, using the first point as the start and
> the last point as the end. This is the exactly the functionality we're
> looking for, but MapQuest is quite expensive, slow, and doesn't support
> large batches (we need to support a couple of thousand points).
>
> From what I've been told, OSRM doesn't support this - it only supports
> travelling salesman (trip), using the same start and end point, or viaroute,
> which doesn't do any optimisation. I'm wondering how easy/possible would it
> be to implement in OSRM, or is there any pre/post processing that we can do
> to achieve this?
>
> Thanks in advance.
>
> Kind regards,
> Kieran Caplice
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk

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

Re: [OSRM-talk] osrm performance with multiple threads is confusing me

[Patrick Niklaus]

Query performance is also limited by disk performance as part of the
RTree that is used for the nearest neighbor lookup is on disk. You
might want to check your IO stats as well.

On Thu, Nov 12, 2015 at 3:55 PM, Daniel Patterson  wrote:
> Hi Peter,
>
>   How are you performing the tests?  From the same machine, or from another 
> machine over the network?
>
>   OSRM responses are usually around 5-20ms.  If you're doing some analysis of 
> the results, on the same machine,
>   it's possible that your tests themselves are CPU limited.  Can you give 
> more info on your testing setup?
>
> daniel
>
>> On Nov 12, 2015, at 5:59 AM, Peter Becker  wrote:
>>
>> I'm a little bit confused.
>>
>> i have load the map in memory with osrm-datastore und run one instance with
>>
>> "osrm-route --shared-memory=yes -t 1 -p 5000"
>>
>> with only one thread, one cpu-core raise up tzo 90% and i get ~500
>> routes per second
>>
>> if i set thread count to more then 2 or more
>>
>> "osrm-route --shared-memory=yes -t 2 -p 5000"
>>
>> 3 cpu-cores are raise up to 30-50% usage and i only get ~333 routes per 
>> second.
>>
>> so i also try run 2 instances with one core:
>>
>> "osrm-route --shared-memory=yes -t 1 -p 5000"
>> "osrm-route --shared-memory=yes -t 1 -p 5001"
>>
>> and use ngnix as load-balancer .. it dosn't make a difference to one
>> instance with 2 or more threads
>>
>> what is wrong? with "-t 2" or 2 instances i expect that 2 cpu-cores
>> are at 100% and i get more routes per second as with "-t 1".
>>
>> ___
>> 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] URL parameters for

[Patrick Niklaus]

Mapsmarker.com seems to be a commercial service. We only offer access
to the demo server for non-commercial services. Please remove OSRM
from your commercial service and refrain from linking
`map.project-osrm.org` or using `router.project-osrm.org`.

Thank you,
Patrick

On Wed, Nov 11, 2015 at 7:07 PM, MapsMarker.com  wrote:
> Thanks for the prompt reply Daniel! I added support for map.project-osrm.org
> when I created my plugins back in 2012 - havent changed the implementation
> in the meantime, just got notified by users that it is not working anymore,
> so I am trying to fix this.
>
>
>
> Regarding LRM: I am aware of that plugin & have been playing around with it
> for a while - anyway it will still take some time, until I can offer
> directions directly within my plugin - until this is possible, I want to
> give my users the possibility to link to third-party directions provider.
> See demo settings panel at
> https://demo.mapsmarker.com/wp-admin/admin.php?page=leafletmapsmarker_settings#lmm-directions
>
> best,
>
>
>
> Robert
>
>
>
>
>
> Message: 6
> Date: Wed, 11 Nov 2015 12:54:10 -0500
> From: Daniel Patterson 
> To: Mailing list to discuss Project OSRM 
> Subject: Re: [OSRM-talk] URL parameters for
> http://map.project-osrm.org -   supporting end point only?
> Message-ID: <89d7a253-49df-4edb-8e76-7b536d8d6...@mapbox.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Robert,
>
>   http://map.project-orsm.org/  isn't really
> intended for linking to like your'e describing.  It's more of a demo
> interface to OSRM itself.
>
>   Have you explored using LRM (Leaflet Routing Machine)
> http://www.liedman.net/leaflet-routing-machine/
>  and drawing routes on your
> own Leaflet  ?
>
> daniel
>
>
> ___
> 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] Demo server up again with current data

[Patrick Niklaus]

Yes I had to reboot the server. Should be up and running in a few hours
once a fresh dataset has been processed.
Am 06.11.2015 2:15 nachm. schrieb "Guillaume Barreau" <g.barr...@gmail.com>:

> Hi,
>
> I am not sure what the problem is but I am not able to get any response
> from the demo server.
>
> Thanks,
>
> Guillaume
>
> On 3 November 2015 at 13:15, Patrick Niklaus <
> patrick.nikl...@student.kit.edu> wrote:
>
>> Hey,
>>
>> The demo server should be fully functional again and serve current
>> data. I'm still not sure what went wrong, but deleting all cached
>> files worked. Probably a bug in the update script/caching routines we
>> use on the server and not related to any actual problems in our code
>> base. Will investigate further, but for the time being all is back to
>> normal.
>>
>> Cheers,
>> 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
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Demo Server Down

[Patrick Niklaus]

What version are you running? Our production servers are definitely
working with the current OSM extracts.

On Sun, Nov 1, 2015 at 9:53 PM, Lester Caine <les...@lsces.co.uk> wrote:
> On 01/11/15 20:42, Patrick Niklaus wrote:
>> The data on the demo server seems to have gotten corrupted. We are
>> currently reverting back to an older dataset, while we investigate
>> what went wrong. Should be all up and running in a few hours.
>
> My own service seems to have broken so was there anything in particular
> to explain the problem? A later data update gone wrong perhaps?
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> ___
> 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] Demo Server Down

[Patrick Niklaus]

We are not sure yet what is causing the problems with the current
dataset. I'm currently digging through the changesets.


In the meantime the data on the demo server is frozen to the 30th October.

On Mon, Nov 2, 2015 at 4:34 PM, Lester Caine <les...@lsces.co.uk> wrote:
> On 02/11/15 15:14, Patrick Niklaus wrote:
>> What version are you running? Our production servers are definitely
>> working with the current OSM extracts.
>
> My update process had stopped which is why I was asking if your problem
> was related to something similar or a local hardware problem? I do need
> to pull in a new version of software, but the current style change is
> taking all my spare time at the moment.
>
>> On Sun, Nov 1, 2015 at 9:53 PM, Lester Caine <les...@lsces.co.uk> wrote:
>>> > On 01/11/15 20:42, Patrick Niklaus wrote:
>>>> >> The data on the demo server seems to have gotten corrupted. We are
>>>> >> currently reverting back to an older dataset, while we investigate
>>>> >> what went wrong. Should be all up and running in a few hours.
>>> >
>>> > My own service seems to have broken so was there anything in particular
>>> > to explain the problem? A later data update gone wrong perhaps?
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> ___
> 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 demo server down

[Patrick Niklaus]

Oh damn. Thanks. Looking at the logs this might take some time to fix.

On Sun, Nov 1, 2015 at 1:19 PM, Sander Deryckere  wrote:
> Hi,
>
> I just noticed that the demo site, and routes on http://osm.org through ORSM
> are down.
>
> As I didn't see an announcement or mail about it, I thought I should mention
> it.
>
> Regards,
> Sander
>
>
>
> ___
> 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 Down

[Patrick Niklaus]

Hey,

The data on the demo server seems to have gotten corrupted. We are
currently reverting back to an older dataset, while we investigate
what went wrong. Should be all up and running in a few hours.

Best,
Patrick

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

Re: [OSRM-talk] State of the Art - Dynamic Routing

[Patrick Niklaus]

> certain edges in the contracted graph should have to be ignored


If that set of 'dynamic edges' is known in advance you could use a
technique that does not contract nodes adjacent to that edges. This
would mean for those edges you could update the weights without
re-contraction. On the pre-processing side adding support for this is
quite trivial, essentially it is a variation of partial contraction.
However adding an interface for
updating the graph would be new. The main problem there is that you
either add some sort of "override set" to the query graph, or have a
copy for each graph for each thread.
The first implementation will incur high penalties on query time (you
would need an additional check every time you read the edge weight),
the second approach would have a high memory usage.

Currently we don't plan to implement this. But if anyone likes to give
it a try, I will of course help were I can.

Best,
Patrick

On Wed, Oct 14, 2015 at 12:18 PM, Matthias Loeks <matth...@loeks.net> wrote:
> HI Patrick,
>
> many thanks for your extensive answer and your interesting insights into the
> possibilities of achieving dynamic routing with CH.
>
> While partial graph contraction may be an option for adding traffic data
> e.g. every 15 minutes, I'm afraid that it is still not an option if each
> individual request has to deal with e.g. different  avoid areas.
> Each request would then need a differently contracted/pre-processed graph...
> (impossible to pre-process on the fly)
>
> Do you think there is any possibility to add some sort of "dynamic layer" on
> top of the contracted graph? Based on the information in this layer, certain
> edges in the contracted graph should have to be ignored by the routing
> algorithm.
> Is such a thing possible and are there any plans to incorporate this (or
> similar concepts) into OSRM? Or is this just contrary to the CH approach and
> only solveable with a usual (slow) Dijkstra?
>
> Thanks a lot for your help!
>
> Cheers,
> Matthias
>
>
> On 09.10.2015 15:37, Patrick Niklaus wrote:
>
> If you want to ingest dynamic data like traffic information into the
> routing, the main objective is to reduce pre-processing times so that
> the data will not be stale before you can actually serve requests from
> it.
>
> There are several ways you can achieve this:
> 1. Don't do any pre-processing.
>  In that case you just use a normal Dijkstra based search.
> 2. Do pre-processing but don't update it on traffic updates.
> For example if you use something ALT-based you can calculate the
> heuristic using the average value and still yield good performance.
> 3. Re-run pre-processing and make it fast enough for your given update
> cycle.
> The primary knobs you can turn there are:
> - reduce the size of your dataset
> - reduce the quality of the pre-processing
>
> We have been working on supporting 3 in OSRM with CH. We added a
> parameter to now contract the graph completely but only partially.
> This as dire consequences for query times however, depending on which
> quality factor you pick. If you contract the graph only 95% you will
> half your pre-processing time and increase the runtime 100x depending
> on your dataset size. Features like alternative searches, distance
> tables and similar will not work with this approach since it is much
> too slow.
>
> You can try partial contraction with `4.8.1` by using the `-k`
> parameter like `-k 0.95` will contract the graph only to 95%.
>
> Supporting real time traffic updates while still supporting
> continental sized networks is not exactly trivial, even more so if you
> support advanced features like turn restrictions. Consider the fact
> that just reading/writing such a graph from/to disk might take longer
> than your usual update cycle.
>
> We are working on making it easier to support this for smaller
> datasets though (like countries). Of course CH is really not suited
> that well for this task, but it enables you to use the same platform
> and process until CH can be replaced with alternative approaches.
>
> Best,
> Patrick

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

Re: [OSRM-talk] State of the Art - Dynamic Routing

[Patrick Niklaus]

If you want to ingest dynamic data like traffic information into the
routing, the main objective is to reduce pre-processing times so that
the data will not be stale before you can actually serve requests from
it.

There are several ways you can achieve this:
1. Don't do any pre-processing.
 In that case you just use a normal Dijkstra based search.
2. Do pre-processing but don't update it on traffic updates.
For example if you use something ALT-based you can calculate the
heuristic using the average value and still yield good performance.
3. Re-run pre-processing and make it fast enough for your given update cycle.
The primary knobs you can turn there are:
- reduce the size of your dataset
- reduce the quality of the pre-processing

We have been working on supporting 3 in OSRM with CH. We added a
parameter to now contract the graph completely but only partially.
This as dire consequences for query times however, depending on which
quality factor you pick. If you contract the graph only 95% you will
half your pre-processing time and increase the runtime 100x depending
on your dataset size. Features like alternative searches, distance
tables and similar will not work with this approach since it is much
too slow.

You can try partial contraction with `4.8.1` by using the `-k`
parameter like `-k 0.95` will contract the graph only to 95%.

Supporting real time traffic updates while still supporting
continental sized networks is not exactly trivial, even more so if you
support advanced features like turn restrictions. Consider the fact
that just reading/writing such a graph from/to disk might take longer
than your usual update cycle.

We are working on making it easier to support this for smaller
datasets though (like countries). Of course CH is really not suited
that well for this task, but it enables you to use the same platform
and process until CH can be replaced with alternative approaches.

Best,
Patrick

On Fri, Oct 9, 2015 at 3:03 PM, Matthias Loeks  wrote:
> Hi all,
>
> I would love to see the great OSRM framework supporting more dynamic route
> calculations.
> For instance, it would be great to be able to specify individual vehicle
> profiles/parameters and avoid areas (e.g. road closures) on a per-request
> basis.
>
> As I understand, this required flexibility is contrary to the approach of
> contraction hierarchies in general and thus very hard to achieve. The
> routing can only be that fast because all dynamic input information is
> pre-computed in the graph during the pre-processing, right?
>
> However, I noticed that this topic was already discussed from time to time
> on the list [1,2] and on github [3-5]. Plus there are similar CH-based
> projects starting to support dynamic input at least to some extent (e.g.
> GraphHopper Traffic Data Integration [6]). So in the end it *does* seem to
> be possible, at least partly?
>
> All in all, I'd like to know what is the current state of the art of such
> efforts on the roadmap? What *is* possible and what is definitely not? Is
> there anything in this direction being worked on currently or soon?
>
> It would be great to hear any thoughts, updates and/or ideas from you on
> this topic.
>
> Many thanks and all the best,
> Matthias
>
>
> --
> [1] -
> https://lists.openstreetmap.org/pipermail/osrm-talk/2015-August/000898.html
> [2] -
> https://lists.openstreetmap.org/pipermail/osrm-talk/2013-June/000179.html
> [3] - https://github.com/Project-OSRM/osrm-backend/issues/165
> [4] - https://github.com/Project-OSRM/osrm-backend/issues/683
> [5] . https://github.com/Project-OSRM/osrm-backend/issues/892
> [6] - https://github.com/karussell/graphhopper-traffic-data-integration
>
>
>
>
> ___
> 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] Geometry Polyline Coordinates multiplied by 10

[Patrick Niklaus]

> Is it safe for me to simply divide the decoded coordinates by 10?

Yes it is safe to do that. Polyline encodes arbitrary integers.
Multiplication by a factor and rounding is the first step. Dividing by
the factor is the last step.

Sadly the python implementation hard-codes this factor. Might be up
for a rewrite?

Cheers,
Patrick


On Mon, Oct 5, 2015 at 2:24 AM, Daniel Patterson  wrote:
> Hey Bryan,
>
>   The simplest thing to might be to just add "compression=false" to your 
> /viaroute request.  That'll give you back a plain JSON array of coordinates, 
> rather than in encoded form.
>
> daniel
>
>> On Oct 4, 2015, at 4:57 PM, Bryan Coutts  wrote:
>>
>> I'm trying to use OSRM to supply routes as polylines. I've noticed that, 
>> when I use a standard decoder to decode these polylines (i.e. Python's 
>> polyline package), the lat/lon coordinates I get are multiplied by a factor 
>> of 10. Googling around, I found that this is due to OSRM producing 
>> coordinates at a higher precision; is there a way for me to decode these 
>> without writing my own decoder, or digging into an existing one? Is it safe 
>> for me to simply divide the decoded coordinates by 10?
>>
>> Thanks,
>> Bryan
>> ___
>> 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] character length of route geometry

[Patrick Niklaus]

No, but there is simplification applied if you specify the `z` parameter.

On Mon, Sep 21, 2015 at 10:06 PM, Alex Farioletti  wrote:
> is there a max character length of route geometries?
>
>
> Alex Farioletti
> 415.312.1674
> tcbcourier.com
>
> ___
> 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] Road speeds and profile restrictions

[Patrick Niklaus]

W.r.t. the pre-preprocessing you are correct.

> What is that extra power used for?

Including all sorts of external data sources. Also the logic in the
lua profiles is not just replaceable by simple key-value pairs, OSM
requires you to handle a lot of special cases.

> Presumably I could do the same for world preparation & routing? Have, perhaps 
> a 100GB+ swap file, ideally on an SSD.

This will fall apart when you have some actual load pressure on the
system. We need random access to memory, which will create a lot of
page faults (== slow). Even an SSD is not even close to memory speed.

You have two options:
- split the datasets
- get a bigger server

Cheers,
Patrick


On Thu, Sep 17, 2015 at 10:06 PM, Richard Marsden  wrote:
> I've been evaluating OSRM, using it primarily as a library from C++.
>
> I believe I've determined the answer to most of the questions, but I'm
> also looking for confirmation.
> (I understand the reason for these constraints - the trade-off of
> speed vs flexibility)
>
> First, road speeds are set with 'profile.lua' at the osrm-extract
> stage. This filters out unnecessary roads (eg. foot paths for car
> routing), but also applies the road speeds.
> If I wish to change the speed profile, I need to regenerate the road
> network with osrm-extract and osrm-routed.
> Correct?
>
> If I wanted different speeds for the final distance/time calculations,
> I could use the returned route, and apply my own speed table according
> to the road type of each road segment. This would not, of course,
> change the route geometry is calculated.
>
> If I want a shortest route (distance optimized) instead of a quickest
> route (time optimized), I need to set all the road speeds to the same
> speed and regenerate the network. I.e. osrm does not directly support
> the concept of a "shortest route".
>
> The profile is provided with a LUA file. I had to look this one up :-)
> Looks a useful scripting language, but why is this profile a script
> file, and not a simple configuration file of constants (eg. key-value
> pairs)?
> Seems like an unnecessary complexity - I'd like to understand the
> perceived advantages. What is that extra power used for?
>
> Finally, the memory usage... I saw a reference to the server requiring
> 40GB of memory for pan-European routing. Presumably that could be
> offset with a large swap file(?)
> A large swap file has worked well when I was testing the US-South
> region on an 8GB machine.
> Presumably I could do the same for world preparation & routing? Have,
> perhaps a 100GB+ swap file, ideally on an SSD.
>
>
> Cheers,
>
> 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] OSRM v4.8.0

[Patrick Niklaus]

This OSRM release brings loads of new features and bug fixes. I want to
highlights the initial support for raster data in the lua profiles
added by Lauren Budorick and the new `trip` plugin courtesy to Chau
Nyguen. This release also contains loads of small improvements thanks
to Daniel
Hofmann and Daniel Patterson.

This release also brings numerous profile changes thanks to the help of
various OSRM contributors.

Feature highlights:
- Add `trip` plugin for TSP computation
- Implement raster source feature to read data (currently only .asc)
from third-party sources, to be used in lua profiles.
- Instructions are now returned in match plugin (thanks to Andreas Gruß)
- Partial contraction support, new file .core
- Update to libosmium 2.3.0
- Remove protobuf dependencies (libosmium ships with an own minimal decoder)
- Parse specific restriction:* tags based on profile exceptions
- Make an exception for block barriers in bicycle and foot profile.
- Make pedestrian roads marked as destination routable with car profile.
- Make map matching more resilient against low sample rates
- Enable turn penalties on car profile, using values tuned by
comparing real-world sample routes with map-matched routes.

Bug fixes:
- Add rising bollard exception to barriers for car profile.
- Fix processing for data files with incorrect node references
- Fix postgis lua example
- gps_precision and matching_beta can be used as a float value
- Fix typo in foot profile that removed traffic lights
- SCC search is now run on edge-expanded graph
- Fix off-by one error in hint decoder and make padding deterministic.
- Fix race condition in osrm-routed

As always this release is in sync with a new version of `node-osrm` now with
documentation from Morgan Herlocker.

Cheers,
Patrick

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

Re: [OSRM-talk] OSRM / traffic

[Patrick Niklaus]

Our approach to support traffic in the future is two-fold:

1. Make CH pre-processing fast enough so that you can do traffic on
smaller extracts.
2. Change the routing algorithm to a technique that supports fast updates.

1. is currently being worked on. You can try the
`feature/traffic_data` branch. This is very much WIP. For one there is
no documentation of how to use it yet and I doubt you have data in a
suitable format lying around.

2. is a big push. ETA on a first candidate is some time next year.

Hope this helps,
Patrick

On Fri, Aug 28, 2015 at 10:42 AM,  qua...@no-log.org wrote:
 Hello,

 Do you plan to include traffic  in OSRM ?
 I was wondering if it was possible, because of your use of CH algorithm,
 which seems not to be the most suitable for traffic.

 ___
 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-prepare issue

[Patrick Niklaus]

Hey Adrian,

where did you get your data extract from? Did you try the current
version from the `develop` branch?

Best,
Patrick

On Thu, Aug 27, 2015 at 7:14 PM, Adrian Schmid adrian.sch...@fhsg.ch wrote:
 Hi,

 I have an issue with osrm-prepare. osrm-prepare will only run for a few
 seconds and output the following:

 ./osrm-prepare switzerland-exact.osrm
 [info] Input file: switzerland-exact.osrm
 [info] Restrictions file: switzerland-exact.osrm.restrictions
 [info] Profile: profile.lua
 [info] Threads: 4
 [info] Generating edge-expanded graph representation
 [info]  - 2166 restrictions.
 [info] Importing n = 2793814 nodes
 [info]  - 2056 bollard nodes, 2547 traffic lights
 [info]  and 2888574 edges
 [info] Graph loaded ok and has 2888574 edges
 [info] Removing graph geometry while preserving topology
 Segmentation fault: 11


 When trying to run OSRM afterwards with ./osrm-routed
 switzerland-exact.osrm I get:
 [info] starting up engines, v4.7.1-1-g40443d1
 [info] populating base path: switzerland-exact.osrm
 [info] not a regular file
 [warn] exception: .hsgr not found: switzerland-exact.osrm.hsgr


 Why is this? What should I do to overcome this issue?
 I'm on Mac OSX 10.10.3


 Thanks in Advance for any hints

 Adrian




 

 Adrian Schmid
 Projektleiter

 Fon +41 71 226 12 14
 Web http://www.fhsg.ch

 FHS St.Gallen, Hochschule für Angewandte Wissenschaften
 Institut IMS-FHS | Rosenbergstrasse 59 | Postfach | 9001 St.Gallen |
 Switzerland

 FHO Fachhochschule Ostschweiz
 ___
 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] Route flapping / osrm-prepare adds randomness?

[Patrick Niklaus]

Checked the supposedly broken routes, indeed they all have exactly the
same length. So yes this is down to non-deterministic node ordering
caused by parallel sorting/parsing. We can't fix this, it is just a
side-effect of parallel parsing done by osmium and parallel sorting.
It might be desirable to have consistent soriting, but not at the cost
of removing parallelization.
So this isn't a bug after all.

The random JSON ordering is due to using `std::unordered_map` (you
might guess the effect of that from its name).

On Wed, Jul 1, 2015 at 3:19 PM, Florian Lohoff f...@zz.de wrote:
 On Wed, Jul 01, 2015 at 02:37:25PM +0200, Patrick Niklaus wrote:
 Confirmed on current develop branch using the Isle of Man extract.
 Currently bisecting to find out which change caused this. It is
 expected that pre-processing is not 100% deterministic, since we use
 parallel sorting (node IDs will change), so the JSON response will
 always have a different checksum. However the geometry should always
 be the same.

 In theory it could happen that two paths with exactly the same travel
 time get chosen in different files (because of different node ids, so
 the edges are traversed in different order).

 Even with the same travel time it'll be very much appreciated if there
 was a deterministic ordering (which is the route and which the
 alternate) - In the end by highest osm node id or street name or
 whatever.

 And it seems the order of the json result is also random. I know
 that its not specified what order an json dictionary/object gets
 serialized but its interesting to see.

 BTW: I have seen this kind of route flap before 0.3.9 IMHO probably even
 before 0.3.4 - It just got more anoying as i process a lot more routes
 so the noise went way up.

 Flo
 --
 Florian Lohoff f...@zz.de
  We need to self-defense - GnuPG/PGP enable your email today!

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQIVAwUBVZPo2ZDdQSDLCfIvAQpY8w//SKS6FnIKV3agk1TIYKOxMWUqSCFWBv+l
 G8QuZSfQB4PAE4JfuV2PtIF8IOceV7MRSQKo6IoA0XOuAzew7wYAgo1vJDh2rwNQ
 mwLmxUD2JAaYtt1ci9pqghOwym9nPHYNRNYxSJ+EHL4Ijf2TC2JtH33pHQI0nwvH
 djppJPypJ/LxEWCs/AI8TnQ/uetZcXyCB7Y3xSj91PDGcfXkuFpnPQY1fHmBcONW
 MiG9W15X/f4tx+E25xRkSeP8VR1Oge2FrzB9UtvtInr9K251YuCwWnEUWb+xEhpG
 soK07xcMcXLeAB3CYLf/OxnEuQg4mz6HjV/RH1xCus48d3rJSfJ6AajhB4UPRYEB
 0ZpQUURJPlptX5syBhepaXNNPoRW/dH151Ro0L6lpWPtMvfp2rL6xGy3iFH/BlNC
 rZ2oFjMmkrvtTzTtiqvh75YVPG9+XmnGIpFn8adQVcsXW0FloEj7O2lh+LK0qMl7
 rom1/UYTBpHmuWAC/+dwJDjyiZSqWDgrO9yP6x6O1f4jTV1+1/XfeiA8Nu/9JAwX
 Z188GY09iPMBOGKSDPHfUfrLf34YRTgyrfZaatpY9GcDeO7QFqRLtiUTzs73HpIP
 pNKicGgWmtvzrafQX1yCW0Y66+jKoNqsL/6/KAfeUW6OIBfxwEuuf+daHw4s/cc/
 kOvTF934pIg=
 =wRJ5
 -END PGP SIGNATURE-

 ___
 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] Route flapping / osrm-prepare adds randomness?

[Patrick Niklaus]

Confirmed on current develop branch using the Isle of Man extract.
Currently bisecting to find out which change caused this. It is
expected that pre-processing is not 100% deterministic, since we use
parallel sorting (node IDs will change), so the JSON response will
always have a different checksum. However the geometry should always
be the same.

In theory it could happen that two paths with exactly the same travel
time get chosen in different files (because of different node ids, so
the edges are traversed in different order).

On Wed, Jul 1, 2015 at 12:20 PM, Florian Lohoff f...@zz.de wrote:
 On Wed, Jul 01, 2015 at 10:45:36AM +0200, Florian Lohoff wrote:
 On Tue, Jun 30, 2015 at 08:23:30PM +0200, Frederik Ramm wrote:
  Hi,
 
  On 06/30/2015 03:43 PM, Florian Lohoff wrote:
   Okay - i am brute forcing it now with a smaller planet extract and
   find disturbing results.
 
  Can you exclude a RAM defect? If you do 100 iterations of copy large
  file to other large file, compare md5 sums, do you get a consistent value?

 The machine is doing a lot of other stuff - A Postgres, an OSM Task
 Manager etc - Its an Intel Blade in an Modular Server Blade Rack.

 I dont think its memory defect. But i can try running memtest on it ...

 memtest86+ ran for 30 Minutes without an issue. 16GB ECC Memory Intel
 P5000 Chipset with Intel Xeon CPUs.

 dd if=/dev/urandom of=rfile1 bs=1M count=16000
 md5sum rfile1
 2a806948021ffd7ef19c272bc3f88508  rfile1
 while true; do cp rfile1 rfile2; sync; md5sum rfile2; done
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2
 2a806948021ffd7ef19c272bc3f88508  rfile2

 Ja - ich schliesse Speicherprobleme aus.

 Flo
 --
 Florian Lohoff f...@zz.de
  We need to self-defense - GnuPG/PGP enable your email today!

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQIVAwUBVZO+2JDdQSDLCfIvAQrV9g/+PzmGuhs7LVF27IhUmYW/ZrXNbs9/aw35
 ZhzZtDha5BOcks27kr0oXAvvAvXUHiL+9F58tL0X5KNSP0sd7VaqD+bKvRrJzzoy
 Dp5IG73HBXtna8VyBqNm8kBk140Xiqs9q7sxBwhDO8k5YRtpzvjZT0lh1c21rx8r
 TC+9AONcMWEpEmLwgEqJs8t0kTfSsJXBPerZGwboMgu3KyqLVjMxOzHikaxKCcsb
 IpHvo67LyiWG2pMren01p7eONXZQSbO74A1REujSi5Bbt6cpC5hHtPByjJfjw67Q
 ChiADvAmP2pNkBjyYLnEm2IfpnuWXjZwFTRhwpQst6gkV71EZQPQsQiN0SxwGA7N
 0xcmRuNbT8gWmp7tX+szU0IiSIBrVauuWipU+8Xk+1LPAudcPpERuxG68O/rc24K
 XvFZe+zJlJfw6zyDNcFGzQUsNdFpBvRj01h5wJVicZjKTv26XEahsOKGtHcALbC0
 jSX8eep7frswf1q+gzI0HHWJBCm6eWJI+XXcQ+y7qp5KGG4ZrOAiSW1N2uXqkKWP
 oUFaFQXRDhnHtZz/jCv/3l+Di2kcuwAY1dspjdsEyVL5lkUTRZIBR7TLJajwR5en
 hFg/hmtAZTYZ9iNqT5h7OpMc3vGD5orKuqWAmhpJnHlIvwciuyrkU5eTjdSfp+Sh
 sPI4A6ROzcE=
 =nzXf
 -END PGP SIGNATURE-

 ___
 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 Release 4.7.0

[Patrick Niklaus]

4.7.0 mostly brings bug fixes and profile changes. Thanks to all, who have
contributed to this release. Especially Andreas Gruß who added the
ability to send coordinates as polyline and implemented POST requests for
osrm-routed.

Some highlights:

* Fixed filetype checks for input data
* Add penalty if there is only one lane for both directions
* Fix tag misspellings in profiles + tests: forestry, pebblestone
* Server supports POST requests
* Don't remove small segments at start/begin if they are vias
* `locs` parameter added that accepts via coordinates as polyline
* Deduplicate edges in contractor correctly and add better graph validation.
* Add running tracks to foot profile
* Use 'name (ref)' for way names if both are present
* Content Type validation added
* Update bicycle profile to ignore crossing nodes
* Fixed #1424 and all related bugs.
* Fixed Coverity issues
* Refactor ProcessingChain by splitting into sub functions
* Refactor ExtractionContainers by splitting into sub functions
* Return error message when lua error occurs.
* Cleanup the default profiles (formating, style, removed duplicate code)
* Follow symlinks to profiles
* Use distance based search radius for coordinates (limited to 1100m)

As always this is in sync with a release of our node bindings.

Cheers,
Patrick

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

Re: [Talk-de] Tag für Radfahren zwar erlaubt aber nicht wirklich gut gesucht

[Patrick Niklaus]

Ja solche weichen Kriterien sind immer schwer auf OSM abzubilden und
die meisten würden wahrscheinlich auch behaupten sie gehören gar nicht
ins Tagging. Der Fahrradweg hat auch `surface` Tags und die
Kreisstraße ist als `highway=primary` getaggt oder?

Momentan erlauben wir [1] ca. 30% Umweg um auf einen Fahrradweg zu
kommen. Kannst mir ja mal die Route schicken [2] (die Seite ist nur
temporär, wird später ins offizielle Feedback eingebunden) und ich
gucke es mir an.

Schönen Sonntag,
Patrick

[1] https://www.mapbox.com/blog/bicycle-directions/
[2] 
https://www.mapbox.com/bites/00138/directions-feedback/mapbox/#15/-122.4365/37.7794

2015-05-24 18:44 GMT+02:00 Bernhard Kuisle bernhard.kui...@web.de:
 Hallo,
 ich habe folgendes Problem:
 Bei uns in der Nähe befindet sich eine vielbefahrene Kreisstraße (gerader 
 Verlauf, schnelle PKW und auch viele Laster) auf der natürlich Radfahren 
 erlaubt ist, aber auf der kein Einheimischer (auch kein Rennradler) mit dem 
 Fahrrad fährt, da auf beiden Seiten mehr oder weniger parallel kleine Straßen 
 (auch asphatiert) verlaufen.
 Alle mir bekannten Fahrradrouter benutzen die Kreisstraße, da sie natürlich 
 etwas kürzer ist.
 Mit welchen tags könnte ich die Router dazu bringen, eine der beiden 
 Alternativen zu wählen?
 Gruß Bernhard

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

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

Re: [OSRM-talk] Using map matching for guessing travel mode?

[Patrick Niklaus]

 What’s the reason behind the data sample period of 5-10 per minute? Is it a 
 tuning to a specific “zoom level” and average vehicle speed (ie car)?

It's 5-10 seconds between samples. So its 6 to 12 samples per minute.

 Our bike GPS data is sampled every second

You can absolutely down-sample that. 5 seconds between samples is
absolutely fine in my experience (even more so for bikes, which move
slower).

 Would it possible to change the sample rate of the algorithm at either 
 query time or with program options?

You can try change the `map_beta` parameter, but higher sample rates
like in your case should work. The thing is that 60 samples/minute is
pretty wasteful and the request takes much longer than one for 6
samples/minute with gives a similar quality.

One thing you need to watch out for is that the result will contain
multiple sub-matchings. So in case of a bike trace that runs through
some bollards the matching on data prepared by the car profile will
most likely contain two matchings: the trace gets split at the bollard
node because the algorithm fails to find a sensible connecting route.
When you match it on bike data the trace will not get split. In this
case the confidence for each subt-race might be high in both case, the
defining difference is the splitting of the trace for cars but not for
bikes.


On Sat, May 9, 2015 at 6:29 PM, Emil Tin e...@tin.dk wrote:

 Hi Patrick,

 What’s the reason behind the data sample period of 5-10 per minute? Is it a 
 tuning to a specific “zoom level” and average vehicle speed (ie car)?

 Our bike GPS data is sampled every second, which makes more sense for bikes 
 which don’t travel that fast. My guess is we would need this this resolution 
 to capture many of the details that separate car/foot/bike, like how you turn 
 in intersections, etc.

 Would it possible to change the sample rate of the algorithm at either 
 query time or with program options?


 Another challenge could be situations where ways are missing in OSM. But we 
 might be able to recognize these by lookng for low matching matching 
 confidence for all modes.

 The approach would require us to run additional OSRM instances for foto and 
 car - at the moment we only run bike.


 Emil



 On 09 May 2015, at 15:49 , Patrick Niklaus patrick.nikl...@student.kit.edu 
 wrote:

 Hey Emil!

 yes that sounds like a good application for the map matching API. Good
 catch on the missing documentation, I fixed that. :-)
 The only problem I see is that the classification highly depends on a
 sample periods around 5-10s.

 I'm very interested in hearing about the results of this!

 Best,
 Patrick


 On Fri, May 8, 2015 at 8:14 PM, Emil Tin e...@tin.dk wrote:
 Hi,
 I’m wondering if the new map matching feature could be used for guessing
 travel mode?

 We’re currently working on adding a GPS tracking feature to our I BIke CPH
 ap. Both iOS and Android now come with build-in APIs for automatically
 detecting the travel mode, but on iOS the results are surprisingly low
 quliaty. Since we already use OSRM, I’m wondering it it could be used
 improve the detection quality.

 For example, suppose I have a GPS track and need to guess whether the user
 was biking, walking or in a car? Could I use the matching algorithm with
 different profiles (bike/foot/car), and get values expresssing how well the
 track fits each network, ie. the probability that the user was
 biking/walking/driving?

 It might be useful in siutations where the networks differ slighty due to
 things like:

 - Topology. Some ways allow only bikes/walking/cars. Some intersections
 provide different lanes/ways for turning by car/bike/foot.
 - Oneway. Streets might be oneway for cars, but not for bikes.
 - Barriers. You don’t usually pass stairs or bollards by car.


 At https://github.com/Project-OSRM/osrm-backend/wiki/Server-api is written
 that you can pass classify=true to get a confidence value for the matching,
 but it’s not mentioned in the response section?


 Thanks!

 Emil Tin
 CIty of Copenhagen


 ___
 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] Using map matching for guessing travel mode?

[Patrick Niklaus]

Hey Emil!

yes that sounds like a good application for the map matching API. Good
catch on the missing documentation, I fixed that. :-)
The only problem I see is that the classification highly depends on a
sample periods around 5-10s.

I'm very interested in hearing about the results of this!

Best,
Patrick


On Fri, May 8, 2015 at 8:14 PM, Emil Tin e...@tin.dk wrote:
 Hi,
 I’m wondering if the new map matching feature could be used for guessing
 travel mode?

 We’re currently working on adding a GPS tracking feature to our I BIke CPH
 ap. Both iOS and Android now come with build-in APIs for automatically
 detecting the travel mode, but on iOS the results are surprisingly low
 quliaty. Since we already use OSRM, I’m wondering it it could be used
 improve the detection quality.

 For example, suppose I have a GPS track and need to guess whether the user
 was biking, walking or in a car? Could I use the matching algorithm with
 different profiles (bike/foot/car), and get values expresssing how well the
 track fits each network, ie. the probability that the user was
 biking/walking/driving?

 It might be useful in siutations where the networks differ slighty due to
 things like:

 - Topology. Some ways allow only bikes/walking/cars. Some intersections
 provide different lanes/ways for turning by car/bike/foot.
 - Oneway. Streets might be oneway for cars, but not for bikes.
 - Barriers. You don’t usually pass stairs or bollards by car.


 At https://github.com/Project-OSRM/osrm-backend/wiki/Server-api is written
 that you can pass classify=true to get a confidence value for the matching,
 but it’s not mentioned in the response section?


 Thanks!

 Emil Tin
 CIty of Copenhagen


 ___
 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] alter speed profile

[Patrick Niklaus]

If you always want to disregard the maxspeed tag just set:

result.forward_speed = highway _speed
result.backward_speed = highway _speed

On Fri, May 8, 2015 at 11:36 AM, Jorne De Blaere
jorne.debla...@conundra.eu wrote:
 Hey Simon,

 Still no luck here. If I have an answer I let you know.



 Kind regards,

 Jorne



 Van: simone zanda [mailto:zand...@hotmail.it]
 Verzonden: vrijdag 8 mei 2015 11:16


 Aan: Mailing list to discuss Project OSRM
 Onderwerp: Re: [OSRM-talk] alter speed profile



 Hello . I have the same problem .

 If you work , can you help ?



 Il giorno 07/mag/2015, alle ore 14:28, Jorne De Blaere
 jorne.debla...@conundra.eu ha scritto:



 Hey,



 Thanks for the quick reply. I checked it out and changed



 if max_speed and max_speed  highway_speed then

 result.forward_speed = max_speed

 result.backward_speed = max_speed

 else

 result.forward_speed = highway_speed

 result.backward_speed = highway_speed

 end





 To:





 if max_speed and max_speed  highway_speed then

 result.forward_speed = highway _speed

 result.backward_speed = highway _speed

 else

 result.forward_speed = max_speed

 result.backward_speed = max_speed

 end



 But now i have a giant traveling time, any sugestions on this?



 Kind regards,

 Jorne





 Van: Patrick Niklaus [mailto:patrick.nikl...@student.kit.edu]
 Verzonden: donderdag 7 mei 2015 12:44
 Aan: Mailing list to discuss Project OSRM
 Onderwerp: Re: [OSRM-talk] alter speed profile



 Hey,

 if the way has a `max_speed` tag this value is used instead, see here:
 https://github.com/Project-OSRM/osrm-backend/blob/develop/profiles/car.lua#L303

 Best,

 Patrick



 On Thu, May 7, 2015 at 10:00 AM, Jorne De Blaere
 jorne.debla...@conundra.eu wrote:

 Hey guy’s,



 I’m trying to alter the lua file so that I can limit the speed on highways.

 Is there anyone that can point me in the right direction? I tried so by
 altering the speed_profile in the car.lua file from GitHub. ([motorway] =
 45) (line 15) in the car.lua file but that has no effect on the travel time.
 So I guess that there is something else but I don’t know what

 Met vriendelijke groeten



 Jorne De Blaere

 jorne.debla...@conundra.eu



  I

 +32 485 57 02 08

 Guldensporenpark 120



  I

 BE 9820 Merelbeke

 Willem Alexanderlaan 45



  I

 NL-4532 DB Terneuzen

 www.conundra.eu

 Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website

 Ce message est soumis aux conditions disponibles sur notre site web

 This message is subject to the terms and conditions available on our website




 ___
 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] Map Matching Plugin Questions

[Patrick Niklaus]

 - Did you implement all of the described HMM break conditions (route
 localization, low probability routes, GPS outliers)? After reading the
 code in OSRM, I was only able to find the low probability routes
 condition. Did I overlook something?

The localization is implemented by choosing the candidates before we
start the algorithm. For each input point we adaptively chose between
5 and 10 candidates based on the distance to the previous input point.
That part of the algorithm can be found in plugins/match.hpp. The
outliers test is not implemented, I'm not sure it would add much value
over the limited search radius for candidates combined with the
pruning based on transition probability.


 - As far as I understand, MAX_DISTANCE_DELTA corresponds to the delta
 when comparing the route length and great circle distance for the low
 probability routes condition. The paper states a delta of 2000m, the
 implementation uses a delta of 200m. Feature or bug?


I found that 2000m is a little bit on the conservative side. At least
for my data 200m worked pretty well (sampling period was approximately
7s).
Please not that most parameters are tuned for sampling periods of
around 5 to 10 seconds.

 - What exactly does the confidence return value mean?


Since we are dealing with real world data, matching will fail for some
traces. That might be cause the trace is too noisy or the data from
OpenStreetMap has problems like connectivity errors. To get a handle
on that I gathered some empirical data on mismatched traces and tried
to find a good feature to classify matchings are valid or invalid. The
feature that worked best for me was the ratio between trace length and
matching length (the intuition here is that invalid matchings tend to
contain loops where detours are taken). I used that labeled data to
fit a Laplacian distribution and constructed a naive Bayes classifier
based on that.
The confidence is the probability P(x \in valid). The values are
only based on ~800 labeled traces which specific sampling rate, so
take that value with a grain of salt for your data.

What is missing is a good parameter selection based on the sample rate
of the input. Its not clear when I will have time again to do that
(for now massaging the data to fit the current constraints works quite
well).

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

Re: [OSRM-talk] alter speed profile

[Patrick Niklaus]

Hey,

if the way has a `max_speed` tag this value is used instead, see here:
https://github.com/Project-OSRM/osrm-backend/blob/develop/profiles/car.lua#L303

Best,
Patrick

On Thu, May 7, 2015 at 10:00 AM, Jorne De Blaere jorne.debla...@conundra.eu
 wrote:

  Hey guy’s,



 I’m trying to alter the lua file so that I can limit the speed on
 highways.

 Is there anyone that can point me in the right direction? I tried so by
 altering the speed_profile in the car.lua file from GitHub. ([motorway]
 = 45) (line 15) in the car.lua file but that has no effect on the travel
 time. So I guess that there is something else but I don’t know what

 Met vriendelijke groeten



 *Jorne De Blaere*

 jorne.debla...@conundra.eu



 * I*

 +32 485 57 02 08

 Guldensporenpark 120



 * I*

 BE 9820 Merelbeke

 Willem Alexanderlaan 45



 * I*

 NL-4532 DB Terneuzen

 *www.conundra.eu* http://www.conundra.eu/

 [image: http://conundra.eu/doc/logo/conundra.jpg]
 http://www.conundra.eu/

 *Dit bericht is onderworpen aan de voorwaarden beschikbaar op** onze
 website http://www.conundra.eu/doc/ConundraAlgemeneVoorwaardenEmail.pdf*

 *Ce message est soumis aux conditions disponibles sur** notre site web
 http://www.conundra.eu/doc/ConundraConditionsGeneralesEmail.pdf*

 *This message is subject to the terms and conditions available on** our
 website http://www.conundra.eu/doc/ConundraTermsOfUseEmail.pdf*



 ___
 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] Can hints be used to identify a common segment?

[Patrick Niklaus]

You can use DecodeFromBase64 in algorithms/object_encoder.hpp to decode
the hints to a phantom_node_pair.
Phantom nodes contain contain a forward_node_id and backward_node_id
which you can use to determine if its the same segment.

Best,
Patrick

On Tue, Apr 21, 2015 at 3:33 PM, Stephen Woodbridge wood...@swoodbridge.com
 wrote:

 Hi Fernando,

 Thank you that is a useful observation but my problem is a little
 different. I have many positions and I would like to determine those that
 lie on the same segment so that I can group them together.

 If I remember correctly the hint is a base64 encoded pointer to the edge
 plus something like and offset along the edge. I could be useful to take
 advantage of this information to group and order locations along a path.

 I'll see if I can figure it out from the source code.

 -Steve


 On 4/21/2015 8:28 AM, Fernando Pacheco wrote:

 If both points are in the same segment, their position (third element in
 route_instructions) should be consecutive.

 Located on the same street but in different segments (3 and 5):
 [9, General José Esteban Brito del Pino 122,3,14, 121m, S, 193.1]
 [9, General José Esteban Brito del Pino, 57,5,21, 56m, S, 191.1]

 In the same segment (4 and 5):
 [9, General José Esteban Brito del Pino, 35,4,5, 34m, S, 191.1]
 [9, General José Esteban Brito del Pino, 56,5,21, 56m, S, 190.1]

 May be?. Fernando.

 El 21/04/15 a las 00:24, Stephen Woodbridge escribió:

 Hi,

 I have a need to be able to identify if two locations are on the same
 segment. We already have the hints for each location and there seems to
 be some commonality in the hints for location on the same segment.

 I'm wondering if there is a safe way to use the hints to determine if
 they are on the same segment.

 Thanks,
-Steve

 ---
 This email has been checked for viruses by Avast antivirus software.
 http://www.avast.com


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




 ---
 This email has been checked for viruses by Avast antivirus software.
 http://www.avast.com


 ___
 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 with multiple graphs?

[Patrick Niklaus]

Hey Stephen,

no that is not possible. Should be rather simple to hack that functionality
into the engine by adding an id to the data that is loaded into memory and
selecting that with additional server parameters.

Though I don't think we would want that upstream.

Cheers,
Patrick

On Mon, Apr 6, 2015 at 5:40 PM, Stephen Woodbridge wood...@swoodbridge.com
wrote:

 Hi,

 Is it possible to run osrm-datastore to load multiple graphs on a single
 server, then to setup osrm-routed on different ports and to access a
 specific graph in datastore?

 How can this be done?

 Thanks,
   -Steve

 ---
 This email has been checked for viruses by Avast antivirus software.
 http://www.avast.com


 ___
 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: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Patrick Niklaus]

 Ich würde OSRM von der Auswahl entfernen, bis sie z. B. auch
Abbiegerelationen und Anliegerstraßen beachtet, die gehören meiner Meinung
nach zu den Grundfunktionen.

Falls du Abbiegerelationen findest die nicht funktionieren, dann poste das
bitte hier [1]. Momentan nicht unterstützt werden lediglich
Abbiegerelationen bei den via ein Way ist.

 Von daher sehe ich weniger die fehlenden maxspeed-Tags als Problem
 als vielleicht zu grob erfasste Straßenverläufe die den realen
 Verlauf zu sehr begradigen.

Auf Grund der Größe der Daten verwerfen die meisten Router die geometrische
Information schon beim Pre-Processing*. Das worauf der wirkliche
Routing-Algorithmus ausgeführt ist deutlich abstrakter als das
Straßennetzwerk das ein Mensch auf einer Karte wahrnimmt. (* zumindest für
das eigentliche Routing, am Ende braucht man es schon wieder um eine Linie
auf die Karte zeichnen zu können)
Also: Bitte nicht Anfangen unnötig genaue Geometrien zu erfassen. Das führt
nur zu unnötig großen Daten! (ein echtes Problem, zusehen auch bei den
TIGER Imports in den USA)

Um tatsächlich halbwegs verlässliche ETAs zu bekommen braucht es allerdings
wirklich gemessene Daten von echten Fahrzeugen (kann aus hinreichend vielen
GPS Traces berechnet werden). OSM kann einfach Dinge wie Verkehrsaufkommen
u.Ä. nicht erfassen. Wenn man das nicht hat, muss man sich leider auf
Heuristiken verlassen [2]. Hinreichende Abdeckung von maxspeed Tags kann da
sicherlich nicht schaden.

Wer wirklich helfen will die Daten zu verbessern sollte sich auf zwei Dinge
konzentrieren: Konnektivität, Abbiegerelationen, Zugangsberschränkungen.
Natürlich ist fehlende Straßen erfassen auch gut. :-)
map.project-osrm.org hat ein Small Components Layer um das Konnektivität
fixen etwas einfacher zu machen. Pinke Straßen sind nicht mit dem Rest des
Straßennetzwerks verbunden.

[1] https://github.com/Project-OSRM/osrm-backend/issues
[2]
https://github.com/Project-OSRM/osrm-backend/blob/develop/profiles/car.lua

2015-02-19 23:29 GMT+01:00 Florian Lohoff f...@zz.de:

 On Thu, Feb 19, 2015 at 11:04:11PM +0100, Garry wrote:
  80km/beschränkt ist erlaubt in der Regel eine deutlich
  höhere Geschwindigkeit als z.B. eine Passstraße die nicht
  explizit(!) beschränkt ist.
 
  Von daher sehe ich weniger die fehlenden maxspeed-Tags als Problem
  als vielleicht zu grob erfasste Straßenverläufe die den realen
  Verlauf zu sehr begradigen.

 Gibt es stand heute irgendeine Routingengine für OSM die
 Geometrien der Straße (Also ausser länge) auswertet? Ich kenne
 derzeit keine. Man könnte durchaus da ja noch deutlich mehr machen
 so wie viele Gebäude in der nähe in landuse=residential etc
 um via heuristik die Geschwindigkeit zu ermitteln.

 Defakto sind alle router heute total stumpf:

 switch(highway)
 trunk)
 avgspeed=75
 residential)
 avgspeed=10

 So zur Veranschaulichung. Selbst der Maxspeed wird nicht in jedem
 fall zu rate gezogen. Damit lassen sich auch für 90-95% aller
 fälle sehr passable resultate erzielen.

 Flo
 --
 Florian Lohoff f...@zz.de
  We need to self-defense - GnuPG/PGP enable your email today!

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.10 (GNU/Linux)

 iQIVAwUBVOZj5JDdQSDLCfIvAQpVvg/+IGsqusfqgnBGzg1IB2IQ5Oz6Vzp9uf15
 5bgVtL5xXQyfPVsGAISkzaxhhYi5ntMWSWk2PSZ/SRWa81B0kwStn0MdxmFBk5wM
 tChDbZxiI19KyaizxloMlViOdPPCPs5+yo2LOXXmLaMw1MZ0rsQPBFvUn69clNpp
 AYYz9y+9tD0OFsGdOoSWIj0G+dQl8mfiIFeQP9dcUryuWO/dKvKEGmvWCO/UTNnF
 1oXEA7ziT8qaHEVpZ0g2M22KtNxlrmUz25De2UerEwGn2UoEDfB9sE4N0A5N8OXE
 ZJ7YIb759KVYCAy5a3Hrt45x3VkxVPXDDLu8I/s0f838xA2nonFL56DSrz7CwSzA
 UPlabwuH8jIWRtH7/IReSQZB91ZkXrGb4WiFLD7vdEb2rcmQWezR32umLc0bQQwV
 n0d6vTw+rbD1ySLez8WNKjS1CHn7orXZ/I9W5il32IZzp9i9MH0Pc6G6pmX4r5Dw
 7AHX0U4oPANrrPR2NwJNWxGcHt2+KFQf66py+wxZv2B2m+hOeCJRgJk1FXgtHDAk
 8d73nAk/iWAtxak+Lkkyw9LGZvZQBvVxnKu2nuq1W6oU2OsOf/HKnQt706F61ENB
 l9awxRi1XZzmf5OcF8++rQ1snM+el6x4AJlNwQJJLYtyldmRVAYuCjRNonKb/mwU
 24YKOePXwyQ=
 =0rTY
 -END PGP SIGNATURE-

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


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

Re: [OSRM-talk] (no subject)

[Patrick Niklaus]

Hey Romain,

Leaflet-Routing-Machine is a good reference for seeing how to query the
OSRM route with javascript from a browser:

https://github.com/perliedman/leaflet-routing-machine/blob/master/src/L.Routing.OSRM.js

They use corslite [1] to do the json querry.

[1]
https://github.com/perliedman/leaflet-routing-machine/blob/master/src/L.Routing.OSRM.js#L55

Good luck,
Patrick


On Thu, Feb 12, 2015 at 10:46 AM, Romain NKONGO romain.rn...@gmail.com
wrote:

 Hello to all the OSRM community.

 I'm a french student who works on a university project, along with my
 supervisor and uses the open source project OSRM to achieve it.

 At some point, I have to run some tests (like thousands of tests) to
 extract some values from the JSON outputs (e.g. the total time). Now our
 problem is we tried several ways to do this, by sending HTTP GET requests
 to the running server and treat the returned response as JSON. But we tried
 with Javascript, jQuery and AngularJS, with functions like $resource.get,
 jQuery.getJSON $http.get or $http.jsonp and we never managed to get the
 returned response in a way that we could use it for further treatment in
 our script. Actually, we were able to send the requests to the server but
 the response is returned in the fom of an URL link which contains the JSON
 output in its body, not in the form of a variable in our Javascript that we
 could manipulate.

 As a matter of fact, we have two issues for this :
 - some of the functions we used (which are based on jsonp) added a
 callback parameter to the sent URL, so the request became invalid with
 'Query malformed at the position' errors
 - I've seen in the OSRM documentation that the JSON output is encoded with
 the Google polyline algorithm so it could be an invalid JSON for Javascript
 (we also observed errors like SyntaxError: JSON.parse: unexpected end of
 data at line 1 column 1 of the JSON data

 We essentially want to use the viaroute service, so our URL is something
 like that : htttp://localhost:5000/viaroute?loc=a,bloc=c,d with a,b, c
 and d random float numbers.

 Has anyone ever tried to run some customized tests on OSRM, with any Web
 language, and if so can he give me some tricks of how he succeeded to get
 the JSON ouptut where he wanted?

 To be clearer of how I proceeded in AngularJS, here the code of my app.js
 :
 var app = angular.module('clientOSRM', ['ngResource']);

 app.controller('appController', ['$scope','$http', 'appServices', function
 ($scope,$http, appServices) {
 //Initialisation de notre input, sa valeur sera stockée en instantané
 dans cette variable (ng-model)
 $scope.valueInput1 = 47.3654647,0.6822917;
 $scope.valueInput2 = 47.3905003,0.6920979;


 var getItineraryParams = function () {
 return {
 start: $scope.valueInput1,
 end: $scope.valueInput2
 //start: 47.3654647,0.6822917,
 //end: 47.3905003,0.6920979
 //start: a,b,
 //end: c,d
 }
 };

 //Une fonction accessible que dans ce controleur (mot clé var)
 var getItinerary = function () {
 appServices.osrm.get(getItineraryParams(),
 function (itinerary) {
 alert(Succes : +typeof itinerary);
 console.log(itinerary);
 },
 function (error) {
 alert(erreur : +typeof error+; status : +error.status);
 console.log(error);
 }
 );
 /*$http.jsonp(
 http://localhost:5000/viaroute?loc=47.3654647,0.6822917loc=47.3905003,0.6920979alt=falsegeometry=falseoutput=json
 )
 .success(function(data, status, headers, config) {
 console.log(data);
   }).
   error(function(data, status, headers, config) {
 console.log(data);
   });*/

 };

 //Une fonction accessible depuis la vue
 //Fonction appelée à l'envoi du formulaire (balise ng-submit dans
 form)
 $scope.submit = function () {
 //On peut récupérer la valeur de notre input !
 //console.log($scope.valueInput1);
 getItinerary();
 };
 }]);

 app.run(function ($rootScope) {

 $rootScope.safeApply = function (fn) {
 var phase = $rootScope.$$phase;
 if (phase === '$apply' || phase === '$digest') {
 if (fn  (typeof(fn) === 'function')) {
 fn();
 }
 } else {
 this.$apply(fn);
 }
 };

 });

 and also the appServices.js code :
 app.factory('appServices', function ($resource) {

 return {
 osrm: $resource(, {}, {
 'get': {
 method: 'GET',
 params: {start: '@start', end: '@end'},
 isArray:true,
 url: 
 http://localhost:5000/viaroute?loc=:startloc=:endalt=falsegeometry=false
 
 }
 })
 };
 });

 In the getItinerary function in app.js, the error function (the 3rd
 parameter) is always triggered even with a HTTP status code '200 OK' of the
 request.

 

[Talk-de] [Release] alaCarte Renderer 0.3.0

[Patrick Niklaus]

Seit dem ersten Release hat sich viel getan beim alaCarte (MapCSS-)Renderer!

Einige Highlights:
* MapCSS wird fast vollständig unterstützt
* Tiles werden jetzt in 4x4 Blöcken gerendert (= Speedup + bessere
visuelle Qualität)
* Speicherverbrauch wurde reduziert, da für Rechtecksanfragen jetzt
ein STR-Tree eingesetzt wird

Diese Release wäre nicht möglich gewesen ohne unsere zahlreichen Helfer.
Insbesondere möchten wir Dmitry AMDmi3 Marakasov für den Ausbau der
MapCSS-Unterstützung und Mixaill für die MinGW-Unterstützung danken.

Links: http://alacarte-maps.github.io/
Github: https://github.com/alacarte-maps/alacarte
Demo: http://studwww.ira.uni-karlsruhe.de/~s_scheir/alacarte/

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] [Release] alaCarte Tile-Renderer 0.2.1

[Patrick Niklaus]

Was ist alaCarte?
alaCarte ist ein Tile-Renderer (+ Server) für OpenStreetMap
geschrieben in C++11. Für das Rendering wird Cairo benutzt und für das
Parsen von MapCSS-Stylesheets Boost-Spirit.
alaCarte wurde für mittelgroße Datensätze entwickelt. Auf einem
typischen System mit 8GB RAM kann alaCarte z.B. mit einem
ungefilterten Datensatz der Größe von Baden-Württemberg umgehen.

Für mehr Informationen:
https://github.com/TheMarex/alacarte

Da momentan leider eine Datenbankanbindung fehlt, kann alaCarte nur
mit Daten umgehen, die auch in den Arbeitsspeicher passen.

Wir haben einen kleinen Demo-Server aufgesetzt, da dieser allerdings
aus dem Uni-Netz heraus läuft ist es fraglich, wie lange er durchhält.
Wenn jemand von euch also einen Server hat der sich langweilt... ;-)

Demo-Server: http://studwww.ira.uni-karlsruhe.de/~s_scheir/alacarte/

Enwickelt wurde alaCarte im Rahmen eines Uni-Projektes am Karlsruher
Institut für Technologie. [1] Das 0.2.1-Release ist das erste
Open-Source-Release.

Wer fragen zur Technik hat, ask away. Auf der Website des Demo-Servers
ist auch noch eine Präsentation verlinkt, die einen kurzen Überblick
gibt.

[1] http://algo2.iti.kit.edu/

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] [Release] alaCarte Tile-Renderer 0.2.1

[Patrick Niklaus]

2013/4/10 Sven Geggus li...@fuchsschwanzdomain.de:

 Welche Vorteile hat denn das tool im Vergleich zu herkömmlicher Renderer
 Software wie Mapnik oder dem (UMN) Mapserver?

 Gibt es Lösungen für bekannte Probleme herkömmlicher Renderer (Verdrängung,
 Generalisierung, Label-Placement, ...)?


Wir benutzen MapCSS[1] zum erstellen von Stylesheets. MapCSS ist recht
nah an den OpenStreetMap-Daten dran (was man jetzt als Vorteil oder
Nachteil sehen kann, je nach Anwendung), deshalb ist es recht einfach
damit Stylesheets zu basteln. alaCarte lädt die Stylesheets zur
Laufzeit, d.h. von Benutzer-Seite aus sieht man sofort, wenn man etwas
geändert hat. (kein Server-Restart oder so erforderlich) Ein Server
kann auch beliebig viele Stylesheets gleichzeitig anbieten.
(Vorausgesetzt er hat die entsprechenden Resourcen.)

Unser Renderer implementiert auch ein halbwegs gutes Label-Placement:
Abgeschnittene und Überdeckte Labels werden zum einen erkannt und
nicht gerendert, zum anderen wird auch versucht überdeckte Labels ein
wenig zu verschieben um die Überdeckung zu beheben.


 Ich bin ja ein großer Anhänger des Rendering Ansatzes, den Jochen Topf
 unter
 http://blog.jochentopf.com/2011-03-22-new-approaches-for-map-rendering.html
 beschrieben hat.


Unsere Implementierung von MapCSS ist übrigens IMHO nicht Turing
Complete. Allerdings haben wir ein paar einfache Eval-Funktionen
implementiert, was aber auch nicht mehr als ein kleiner Taschenrechner
mit ein paar Sonderfunktionen ist.

Allerdings ist alaCarte kein Rendering-Toolkit wie es in deinem Link
beschrieben wurde, sondern ein Renderer im klassische Sinne: Daten +
Aussehen = Bilder

[1] http://wiki.openstreetmap.org/wiki/MapCSS/0.2

Cheers,
Patrick

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] History Spam

[Patrick Niklaus]

Hallo,

mir ist vor kurzem ein relativ großer Edit in meiner Region
aufgefallen vom User hasse_osm_korinthenkacke (orgineller Name...).
Hier mal die Beispiel History von einem Node aus seinem Changeset:
http://www.openstreetmap.org/api/0.6/node/27593751/history

Täusch ich mich, oder wurde bei den letzten Version Updates nur der
Timestamp geändert? Habe den User mal angeschrieben und gefragt was er
da treibt...

Habt ihr auch schon solchen History Spam beobachtet? Könnte man sowas
vll auf OSM Seite beheben, indem vor dem Updaten eines Nodes erst mal
geprüft wird, ob wirklich was anderes als der Timestamp verändert
wurde?

Mit freundlichen Grüßen,
Patrick

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wasserwege eintragen

[Patrick Niklaus]

 Habe ich mir auch schon überlegt, aber ich würde das Ding
 an einer Schnur festhalten und nicht durch Röhren schwimmen
 lassen, denn in den Röhren hast du wahrscheinlich eh keinen
 Empfang und das Risiko ist zu groß, dass es an einem Gitter
 hängen bleibt. Der unterirdische Verlauf des Baches ist meines
 Erachtens sowieso eher zweitrangig.


Den oberirdischen Teil werde ich auf alle Fälle in nächste Zeit
versuchen so zu vermessen. Bin mir nur noch nicht ganz sicher wie ich
meinen GPSLogger verpacke. Das mit der Schnur ist auf jeden Fall eine
gute Idee.

Beim unteridischen Teil werd ich dann wohl die Bebauungplane zu Rate
ziehen müssen.

Weiss einer von euch wie ich die Bebauungpläne von
http://www.geoportal.rlp.de/ in JOSM oder Merkaartor ansehen kann?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Wasserwege eintragen

[Patrick Niklaus]

Hallo,

ich stehe im Moment vor dem Problem, dass ich einen nahe gelegenen
Bach eintragen will, mir allerdings nicht sicher bin wie ich am besten
anstellen soll.

Satellitenfotos als Quelle fallen schon mal aus, 1) weil man den Bach
darauf sowieso nur sehr schlecht sieht und 2) weil der Bach teilweise
unterirdisch verläuft (durch Röhren).

Meine zweite Idee einfach ein GPSLogger wasserdicht verpacken und
durch den Bach treiben lassen, ist etwas riskant, da ich nicht weiss
wie lange sowas bis zur Mündung brauch und auch nicht ob zwischendrin
Gitter oder so angebracht sind. Gibt es vll Daten vom Vermessungsamt
oder so die man übertragen könnte?

Gruß,
Patrick

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM Einstieg geschafft! :-D

[Patrick Niklaus]

Auf jedenfall müsste die Seitenleiste von JOSM deutlich aufgeräumt
werden. In die Seitenleiste gehörem IMHO keine Dock-Optionen, die
gehören in ein Menu unter View.

Das Select tool müsste mit dem Delete tool zusammengefasst werden.
(Bzw. sollte beim Selector das Drücken der Taste Entf das löschen
des Nodes bewirken und ein Menupunkt unter Edit eingefügt werden)

Was auch fehlt ist ein Kontextmenu, wenn man einen Rechtsklick auf ein
selektiertes Objekt macht. (Auschneiden, Kopieren, Einfügen,
Duplizieren etc.)

Das Presets Menu müsste auch mal aufgeräumt werden, passt bei mir
gar nicht mehr auf den Bildschirm.

BTW. Ist JOSM bei euch auch so langsam beim rendern? Mein armer CPU
wird ganz schön gequält. Bin mir nicht sicher ob das JOSM, der Treiber
(Intel) oder Java ist. Normalerweise ist die 2D Performance mit Intel
aber recht ordentlich.

Gruß,
Patrick
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] JOSM Einstieg geschafft! :-D

[Patrick Niklaus]

 kannst Du mir mal ein Beispiel/einen Screenshot geben?


Klar, siehe Anhang. Ich kann nicht sagen, in wie fern das menu jetzt
auch wiklich alle Elemente anzeigt, aber zumindest sollten die Punkte
vll nach Unterpunkten Sortiert werden, oder das ganze sollte als Dock
umgesetzt werden (mit nem TreeView vll).

Für meinen kleinen Laptop Bildschirm ist das Menu definitiv zu groß.

Grüße,
Patrick
attachment: JOSM Menu.jpg___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de