Please report back with the latest v4.8.0 release. As I said, we did some tests internally with down-sizing an OSM extract, with the method I described above.
This works out fine, as long as you are careful about dangling references. On Mon, Sep 21, 2015 at 10:12 PM, Luc Van Linden <[email protected]> wrote: > Hi Daniel > > Thanks for your feedback. We used a new BBquery this time using osmosis. > With JOSM we can check dat this export is actually following the approach > you suggested. > > The extract is ok now. > > It is the prepare that is failing. > > [info] Input file: Oudenaarde_BB.osrm←[0m > [info] Restrictions file: Oudenaarde_BB.osrm.restrictions←[0m > [info] Profile: profile.lua←[0m > [info] Threads: 4←[0m > [info] Generating edge-expanded graph representation←[0m > [info] - 13 restrictions.←[0m > [info] Importing n = 39160 nodes ←[0m > [info] - 3 bollard nodes, 6 traffic lights←[0m > [info] and 40510 edges ←[0m > [info] Graph loaded ok and has 40510 edges←[0m > > Then a windows box says the osrm.prepare has stopped working. > > The JOSM tools mentioned that a couple of relations are incomplete: > > 1 restriction and a series of routes. > > using > > use_turn_restrictions = false > or > use_turn_restrictions = true > > in the profile does not make any difference the extract works in both > cases the prepare fails as described above. > > Now for the time being there is no need to spent to much time on this > subject as the standard profile.lua extract/prepare/run works fine and fast > even on the full Belgian country. > > We ran into this issue as we read a lot to take an extract to test > profiling. > > Btw we tested this on the windows build from july and august. > > We will try the latest. > > Our major concern and issues we currently are facing is to get a better > understanding on the profile.lua config. > As written in our other post, we would like to understand to actually > limit the graph as such, by exmplae performing teh extract/prepare/run work > for only railwaylines as a test case. > > Thanks again. > > Luc > > > > > > > > On Mon, Sep 21, 2015 at 7:18 PM, Daniel Hofmann <[email protected]> > wrote: > >> Down-sizing files with bounding-box queries is dangerous when not >> carefully executed. >> >> We had similar issues a few month ago that went like this: >> >> When you do a simple bounding-box query, you do a hard cut through way >> nodes at the borders, resulting in dangling node references in the OSM file. >> >> What you instead have to do is the following: >> >> - query for all nodes in your bounding-box >> - query for the associated ways for those nodes >> - now run through those ways and return all the way nodes >> >> now your ways no longer have dangling references. >> >> There is a tool to check for dangling references, `osmium check-refs`: >> > >> http://gis.19327.n5.nabble.com/Referential-Integrity-Problem-td5848030.html#a5848890 >> >> Which OSRM version are you on? I thought we made the dangling reference >> issues harder to crash OSRM and instead throwing and error. Could you try >> with the latest 4.8.1 release please? >> >> On Mon, Sep 21, 2015 at 5:06 PM, Luc Van Linden <[email protected]> >> wrote: >> >>> Hi >>> >>> We are currently testing the usage of OSRM (on windows using the >>> published binaries) and the way the profile.lua file needs to be configured >>> to minimise the resulting graph. >>> >>> We would like to understand which part of the lua file will actually >>> "decide" if a specific element/tag/way is included in the graph. >>> >>> We have tested with afull belgian coverage. The standard profile.lua >>> file works for extract/prepare and run. >>> >>> However when we use a small but substantial relevant subset of Belgium, >>> using a BBOX, osrm_extract fails. A windows messagebox pops up, just a >>> message saying the program osrm.extract has stopped working. >>> >>> This is the console output: >>> >>> [info] Input file: belgium-latest.osm.pbf←[0m >>> [info] Profile: profile.lua←[0m >>> [info] Threads: 4←[0m >>> [info] Using script profile.lua←[0m >>> [STXXL-MSG] STXXL v1.4.99 (prerelease/Release) (git >>> f7389c79e946430f5e3f7efc15e5 >>> bcc29183d200) + gnu parallel(__GLIBCXX__) >>> [STXXL-MSG] Disk 'd:\temp\stxxl' is allocated, space: 10000 MiB, I/O >>> implementat >>> ion: wincall queue=0 devid=0 >>> [info] Parsing in progress..←[0m >>> [info] input file generated by Osmium ( >>> http://wiki.openstreetmap.org/wiki/Osmium >>> )←[0m >>> [info] timestamp: 2015-07-13T21:15:02Z←[0m >>> [info] Ignoring turn restrictions←[0m >>> >>> >>> - is there somewhre a log file we can check? >>> - does osrm.extract expect all info to be available? I can image that >>> the BBox rectangle extract might be missing some nodes or other elements in >>> routes/restrictions etc? >>> - more generic, what is the information osrm.extract is expecting in an >>> osm file? >>> >>> thanks >>> >>> Luc >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> > > _______________________________________________ > 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
