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
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
On Fri, Mar 2, 2018 at 3:10 AM, François Lacombe <fl.infosrese...@gmail.com>
> 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 <hofm...@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
> OSRM-talk mailing list
OSRM-talk mailing list