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 <[email protected]> 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 <[email protected]>: > >> 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 > [email protected] > https://lists.openstreetmap.org/listinfo/osrm-talk > >
_______________________________________________ OSRM-talk mailing list [email protected] https://lists.openstreetmap.org/listinfo/osrm-talk
