<div dir="ltr">Hi Daniel,<br><br><div><div class="gmail_extra"><div class="gmail_quote">2018-03-02 18:31 GMT+01:00 Daniel Patterson <span dir="ltr"><<a href="mailto:daniel@mapbox.com" target="_blank">daniel@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>Well, it *could* be done.  It would all boil down to providing an alternative for `ParseOSMData` here:</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></blockquote><div><br></div><div>Thank you, this is really useful information<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div>    0) You'll have to implement it - the core team have other priorities.</div></div></blockquote><div><br></div><div>That's fair<br></div><div>I could eventually propose a complete alternative to osrm-extract as to clearly separate responsibilities.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>I have about 5M ways and 40M nodes.<br></div><div>Producing xml or pbf takes hours, while querying postgis takes about 3min.<br></div><div>I would probably agree that the process of postgis output isn't well optimized<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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></blockquote><div><br></div><div>Problem isn't to get data from postgis, but to organize them as to fit in the xml :<br></div><div>- Creating nodes records, out of Linestrings / polygon geometries<br></div><div>- 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.<br></div><div>- Create numeric and auto incremented ids since we use uuid in postgis (the easy part)<br></div><div>- 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.<br></div><div><br></div><div>This takes hours, and I'll be really happy if I find a way to directly feed osrm graph without recreating such things.<br></div><div><br></div><div>Simple suppositions:<br></div><div>It would be so nice to not have to produce nodes out of geometries. It's the key point.<br></div><div>I guess you don't have proper records for each nodes in .osrm files don't you ?<br></div><div>Once they gone through profile's node_process, we only need their coordinates and not their tags any more.<br></div><div>Then it would be great to only send tagged nodes (coming from dedicated postgis tables) to osrm-extract.<br><br><br></div><div>Enjoy your weekend,<br><br></div><div>François<br></div></div></div></div></div>