[OSRM-talk] osrm extract on a osm file created using a using BBox query

Wed Sep 23 14:25:53 UTC 2015

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 <luc.vanlinden at gmail.com>
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 <hofmann at mapbox.com>
> 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 <luc.vanlinden at gmail.com>
>> 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
>>> OSRM-talk at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>>
>>>
>>
>> _______________________________________________
>> OSRM-talk mailing list
>> OSRM-talk at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> _______________________________________________
> OSRM-talk mailing list
> OSRM-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osrm-talk/attachments/20150923/7e232d18/attachment.html>