Re: [OSRM-talk] Left/Right side of the street?

[Daniel Patterson]

Hi Xavier,

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

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

daniel



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

> Dear all,
>
> Being a newcomer in OSRM, my question may sound naive :
>
> When requiring for a route between 3 points A, B, C, in a
> drive-on-the-right country.
>
> Can OSRM take into account the fact that B may be on the left side of the
> way?
>
> Thanks,
>
> regards,
>
> Xavier
>
> --
>
> *Xavier Prudent *
>
> *Data Scientist  - Data Mining - Machine Learning*
>
> Web:* www.xavierprudent.com *
> Tel (Québec)  : (514) 668 76 46
> Skype : xavierprudent
>
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSRM-talk] Left/Right side of the street?

[Xavier Prudent]

Dear all,

Being a newcomer in OSRM, my question may sound naive :

When requiring for a route between 3 points A, B, C, in a
drive-on-the-right country.

Can OSRM take into account the fact that B may be on the left side of the
way?

Thanks,

regards,

Xavier

-- 

*Xavier Prudent *

*Data Scientist  - Data Mining - Machine Learning*

Web:* www.xavierprudent.com *
Tel (Québec)  : (514) 668 76 46
Skype : xavierprudent
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Feed OSRM with Postgis

[Daniel Patterson]

Hi François,

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

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

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

daniel

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

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

Re: [OSRM-talk] Feed OSRM with Postgis

[François Lacombe]

Hi Daniel,

2018-03-02 18:31 GMT+01:00 Daniel Patterson :

> Well, it *could* be done.  It would all boil down to providing an
> alternative for `ParseOSMData` here:
> That function is responsible for parsing the OSM file, and
> copying/converting the OSM fields into a memory structure called
> `ExtractionContainers`:
>

Thank you, this is really useful information


>
> 0) You'll have to implement it - the core team have other priorities.
>

That's fair
I could eventually propose a complete alternative to osrm-extract as to
clearly separate responsibilities.


> 1) I suspect you wouldn't see a huge performance improvement - I
> suspect the overhead of querying postgis would dominate the extractor time.
>

I have about 5M ways and 40M nodes.
Producing xml or pbf takes hours, while querying postgis takes about 3min.
I would probably agree that the process of postgis output isn't well
optimized


> 2) You'll be on the hook for maintaining this code - the core team
> haven't built this into the core tool because we don't need it, and it's a
> big ask for us to maintain something we don't use.
>
>   I'd strongly consider trying to optimize your Postgres->OSM extraction
> process.  Consider using `osmium` libraries to write out the data in PBF
> form directly instead of XML - it's significantly smaller, which makes it
> faster to move around and write to disk, and OSRM will import it more
> quickly.
>

Problem isn't to get data from postgis, but to organize them as to fit in
the xml :
- Creating nodes records, out of Linestrings / polygon geometries
- Search and deduplicate them, especially when 2 or more ways have nodes
located on the same lat/lon point. Currently done with a GROUP BY on nodes
geometry.
- Create numeric and auto incremented ids since we use uuid in postgis (the
easy part)
- Iterate over all of this to produce a xml with Python. Didn't try c++
libosmium for now but I know i should. That's the longer part in the
current process.

This takes hours, and I'll be really happy if I find a way to directly feed
osrm graph without recreating such things.

Simple suppositions:
It would be so nice to not have to produce nodes out of geometries. It's
the key point.
I guess you don't have proper records for each nodes in .osrm files don't
you ?
Once they gone through profile's node_process, we only need their
coordinates and not their tags any more.
Then it would be great to only send tagged nodes (coming from dedicated
postgis tables) to osrm-extract.


Enjoy your weekend,

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

Re: [OSRM-talk] Feed OSRM with Postgis

[Daniel Patterson]

Hi François,

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


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

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

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

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

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

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

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

daniel

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

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

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

[Daniel Patterson]

Hi François,

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

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

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

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

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

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

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

daniel


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

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

Re: [OSRM-talk] Feed OSRM with Postgis

[François Lacombe]

Hi Daniel,

Despite it's a pretty old thread regarding feeding OSRM with postgis
geometries, I have new lights to bring up

2017-11-30 18:09 GMT+01:00 Daniel Hofmann :

> OSRM is a routing engine for OpenStreetMap and the OpenStreetMap extracts
> usually come in xml or pbf formats.
>

I find this a bit restrictive and I wonder why it's valuable to stuck osrm
on osm data only.
I work for a company which is interested to use osrm as a router for public
works (not cycling nor car or whatever).
We have lot of private data we process into a postgresql db in which osm
data is also imported.

OSM XML file production at the end of our process generate a lot of
overhead as to feed osrm.
This doesn't bring advantage at all.


> We're using https://github.com/osmcode/libosmium in the osrm-extract
> binary; you theoretically _could_ switch it out with calls to your database
> but that will be a bigger lift I guess, and we don't want to add arbitrary
> data source drivers to OSRM.
>

We think about creating another connector which would enable osrm-extract
to get its data directly for pgsql.
Currently we're not aware of how deep the xml/libosmium is linked to
osrm-extract binary.

Our use cases enlarge the potential and relevance of osrm in
industrial/profesionnal use.
We look to be as constructive as possible and it will be a pleasure to
share since osrm is great tool.


All the best

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