[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 <fl.infosreseaux at gmail.com>
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 <hofmann at mapbox.com>:
>
>> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20180302/2f3bac90/attachment.html>