<div dir="ltr">Hi François,<div><span style="color:rgb(136,136,136);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><br></span></div><div>Well, it *could* be done. It would all boil down to providing an alternative for `ParseOSMData` here:</div><div><br></div><div> <a href="https://github.com/Project-OSRM/osrm-backend/blob/master/src/extractor/extractor.cpp#L211">https://github.com/Project-OSRM/osrm-backend/blob/master/src/extractor/extractor.cpp#L211</a></div><div><br></div><div>That function is responsible for parsing the OSM file, and copying/converting the OSM fields into a memory structure called `ExtractionContainers`:</div><div><br></div><div><a href="https://github.com/Project-OSRM/osrm-backend/blob/master/include/extractor/extraction_containers.hpp#L23">https://github.com/Project-OSRM/osrm-backend/blob/master/include/extractor/extraction_containers.hpp#L23</a><br></div><div><br></div><div> If you could populate ExtractionContainers from somewhere else, you'd be good to go.</div><div><br></div><div> Happy to give advice on how to do this, but:</div><div><br></div><div> 0) You'll have to implement it - the core team have other priorities.</div><div> 1) I suspect you wouldn't see a huge performance improvement - I suspect the overhead of querying postgis would dominate the extractor time.</div><div> 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.</div><div><br></div><div> 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.</div><div><br></div><div>daniel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 2, 2018 at 3:10 AM, François Lacombe <span dir="ltr"><<a href="mailto:fl.infosreseaux@gmail.com" target="_blank">fl.infosreseaux@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Daniel,<br><br></div>Despite it's a pretty old thread regarding feeding OSRM with postgis geometries, I have new lights to bring up<br><br><div><div><div class="gmail_extra"><div class="gmail_quote"><span class="">2017-11-30 18:09 GMT+01:00 Daniel Hofmann <span dir="ltr"><<a href="mailto:hofmann@mapbox.com" target="_blank">hofmann@mapbox.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>OSRM is a routing engine for OpenStreetMap and the OpenStreetMap extracts usually come in xml or pbf formats.<br></div></div></div></div></blockquote><div><br></div></span><div>I find this a bit restrictive and I wonder why it's valuable to stuck osrm on osm data only.<br></div><div>I work for a company which is interested to use osrm as a router for public works (not cycling nor car or whatever).<br></div><div>We have lot of private data we process into a postgresql db in which osm data is also imported.<br><br></div><div>OSM XML file production at the end of our process generate a lot of overhead as to feed osrm.<br></div><div>This doesn't bring advantage at all.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>We're using <a href="https://github.com/osmcode/libosmium" target="_blank">https://github.com/osmcode/lib<wbr>osmium</a> 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.<br></div></div></div></blockquote></span><div><br>
<div>We think about creating another connector which would enable osrm-extract to get its data directly for pgsql.<br></div><div>Currently we're not aware of how deep the xml/libosmium is linked to osrm-extract binary.<br><br></div><div>Our use cases enlarge the potential and relevance of osrm in industrial/profesionnal use.</div>
We look to be as constructive as possible and it will be a pleasure to share since osrm is great tool.<br></div><div> <br><br></div><div>All the best<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>François<br></div></font></span></div><br></div></div></div></div>
<br>______________________________<wbr>_________________<br>
OSRM-talk mailing list<br>
<a href="mailto:OSRM-talk@openstreetmap.org">OSRM-talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/osrm-talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/osrm-talk</a><br>
<br></blockquote></div><br></div>