Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
On Wed, Jul 01, 2015 at 04:09:40PM +0200, Patrick Niklaus wrote: > Checked the supposedly broken routes, indeed they all have exactly the > same length. So yes this is down to non-deterministic node ordering > caused by parallel sorting/parsing. We can't fix this, it is just a > side-effect of parallel parsing done by osmium and parallel sorting. > It might be desirable to have consistent soriting, but not at the cost > of removing parallelization. > So this isn't a bug after all. So why does it randomly return an alternate route and sometimes dont? I have all permutations route A + alternate B - route B with alternate A - Route A without alternate and Route B without alternate. It would be okay for me if the route i got last can be found in the alternates but that does not work reliably. > The "random" JSON ordering is due to using `std::unordered_map` (you > might guess the effect of that from its name). Does it really do an "unsort"? I mean even an unordered map returns element always in a deterministic way either be order of adding, reverse, alphabetical, backend storage. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
Hi, On 07/01/2015 04:26 PM, Patrick Niklaus wrote: > Your data is broken, this happens if you run osmium to verify the integrity: > > osmium check-refs -v -r -i germany.osm.pbf > > There are 217165748 nodes, 34578441 ways, and 472363 relations in this file. > Nodes in ways missing: 575586 > Nodes in relations missing: 9665 > Ways in relations missing: 171812 > Relations in relations missing: 0 If it is a Geofabrik extract, then having missing relation members is expected (as relations aren't completed cross-boundary), but having missing nodes in ways surprises me, especially that many. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
Your data is broken, this happens if you run osmium to verify the integrity: osmium check-refs -v -r -i germany.osm.pbf There are 217165748 nodes, 34578441 ways, and 472363 relations in this file. Nodes in ways missing: 575586 Nodes in relations missing: 9665 Ways in relations missing: 171812 Relations in relations missing: 0 On Wed, Jul 1, 2015 at 4:09 PM, Patrick Niklaus wrote: > Checked the supposedly broken routes, indeed they all have exactly the > same length. So yes this is down to non-deterministic node ordering > caused by parallel sorting/parsing. We can't fix this, it is just a > side-effect of parallel parsing done by osmium and parallel sorting. > It might be desirable to have consistent soriting, but not at the cost > of removing parallelization. > So this isn't a bug after all. > > The "random" JSON ordering is due to using `std::unordered_map` (you > might guess the effect of that from its name). > > On Wed, Jul 1, 2015 at 3:19 PM, Florian Lohoff wrote: >> On Wed, Jul 01, 2015 at 02:37:25PM +0200, Patrick Niklaus wrote: >>> Confirmed on current develop branch using the Isle of Man extract. >>> Currently bisecting to find out which change caused this. It is >>> expected that pre-processing is not 100% deterministic, since we use >>> parallel sorting (node IDs will change), so the JSON response will >>> always have a different checksum. However the geometry should always >>> be the same. >>> >>> In theory it could happen that two paths with exactly the same travel >>> time get chosen in different files (because of different node ids, so >>> the edges are traversed in different order). >> >> Even with the same travel time it'll be very much appreciated if there >> was a deterministic ordering (which is the route and which the >> alternate) - In the end by highest osm node id or street name or >> whatever. >> >> And it seems the order of the json result is also "random". I know >> that its not specified what order an json dictionary/object gets >> serialized but its interesting to see. >> >> BTW: I have seen this kind of route flap before 0.3.9 IMHO probably even >> before 0.3.4 - It just got more anoying as i process a lot more routes >> so the noise went way up. >> >> Flo >> -- >> Florian Lohoff f...@zz.de >> We need to self-defense - GnuPG/PGP enable your email today! >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.10 (GNU/Linux) >> >> iQIVAwUBVZPo2ZDdQSDLCfIvAQpY8w//SKS6FnIKV3agk1TIYKOxMWUqSCFWBv+l >> G8QuZSfQB4PAE4JfuV2PtIF8IOceV7MRSQKo6IoA0XOuAzew7wYAgo1vJDh2rwNQ >> mwLmxUD2JAaYtt1ci9pqghOwym9nPHYNRNYxSJ+EHL4Ijf2TC2JtH33pHQI0nwvH >> djppJPypJ/LxEWCs/AI8TnQ/uetZcXyCB7Y3xSj91PDGcfXkuFpnPQY1fHmBcONW >> MiG9W15X/f4tx+E25xRkSeP8VR1Oge2FrzB9UtvtInr9K251YuCwWnEUWb+xEhpG >> soK07xcMcXLeAB3CYLf/OxnEuQg4mz6HjV/RH1xCus48d3rJSfJ6AajhB4UPRYEB >> 0ZpQUURJPlptX5syBhepaXNNPoRW/dH151Ro0L6lpWPtMvfp2rL6xGy3iFH/BlNC >> rZ2oFjMmkrvtTzTtiqvh75YVPG9+XmnGIpFn8adQVcsXW0FloEj7O2lh+LK0qMl7 >> rom1/UYTBpHmuWAC/+dwJDjyiZSqWDgrO9yP6x6O1f4jTV1+1/XfeiA8Nu/9JAwX >> Z188GY09iPMBOGKSDPHfUfrLf34YRTgyrfZaatpY9GcDeO7QFqRLtiUTzs73HpIP >> pNKicGgWmtvzrafQX1yCW0Y66+jKoNqsL/6/KAfeUW6OIBfxwEuuf+daHw4s/cc/ >> kOvTF934pIg= >> =wRJ5 >> -END PGP SIGNATURE- >> >> ___ >> OSRM-talk mailing list >> OSRM-talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/osrm-talk >> ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
Checked the supposedly broken routes, indeed they all have exactly the same length. So yes this is down to non-deterministic node ordering caused by parallel sorting/parsing. We can't fix this, it is just a side-effect of parallel parsing done by osmium and parallel sorting. It might be desirable to have consistent soriting, but not at the cost of removing parallelization. So this isn't a bug after all. The "random" JSON ordering is due to using `std::unordered_map` (you might guess the effect of that from its name). On Wed, Jul 1, 2015 at 3:19 PM, Florian Lohoff wrote: > On Wed, Jul 01, 2015 at 02:37:25PM +0200, Patrick Niklaus wrote: >> Confirmed on current develop branch using the Isle of Man extract. >> Currently bisecting to find out which change caused this. It is >> expected that pre-processing is not 100% deterministic, since we use >> parallel sorting (node IDs will change), so the JSON response will >> always have a different checksum. However the geometry should always >> be the same. >> >> In theory it could happen that two paths with exactly the same travel >> time get chosen in different files (because of different node ids, so >> the edges are traversed in different order). > > Even with the same travel time it'll be very much appreciated if there > was a deterministic ordering (which is the route and which the > alternate) - In the end by highest osm node id or street name or > whatever. > > And it seems the order of the json result is also "random". I know > that its not specified what order an json dictionary/object gets > serialized but its interesting to see. > > BTW: I have seen this kind of route flap before 0.3.9 IMHO probably even > before 0.3.4 - It just got more anoying as i process a lot more routes > so the noise went way up. > > Flo > -- > Florian Lohoff f...@zz.de > We need to self-defense - GnuPG/PGP enable your email today! > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIVAwUBVZPo2ZDdQSDLCfIvAQpY8w//SKS6FnIKV3agk1TIYKOxMWUqSCFWBv+l > G8QuZSfQB4PAE4JfuV2PtIF8IOceV7MRSQKo6IoA0XOuAzew7wYAgo1vJDh2rwNQ > mwLmxUD2JAaYtt1ci9pqghOwym9nPHYNRNYxSJ+EHL4Ijf2TC2JtH33pHQI0nwvH > djppJPypJ/LxEWCs/AI8TnQ/uetZcXyCB7Y3xSj91PDGcfXkuFpnPQY1fHmBcONW > MiG9W15X/f4tx+E25xRkSeP8VR1Oge2FrzB9UtvtInr9K251YuCwWnEUWb+xEhpG > soK07xcMcXLeAB3CYLf/OxnEuQg4mz6HjV/RH1xCus48d3rJSfJ6AajhB4UPRYEB > 0ZpQUURJPlptX5syBhepaXNNPoRW/dH151Ro0L6lpWPtMvfp2rL6xGy3iFH/BlNC > rZ2oFjMmkrvtTzTtiqvh75YVPG9+XmnGIpFn8adQVcsXW0FloEj7O2lh+LK0qMl7 > rom1/UYTBpHmuWAC/+dwJDjyiZSqWDgrO9yP6x6O1f4jTV1+1/XfeiA8Nu/9JAwX > Z188GY09iPMBOGKSDPHfUfrLf34YRTgyrfZaatpY9GcDeO7QFqRLtiUTzs73HpIP > pNKicGgWmtvzrafQX1yCW0Y66+jKoNqsL/6/KAfeUW6OIBfxwEuuf+daHw4s/cc/ > kOvTF934pIg= > =wRJ5 > -END PGP SIGNATURE- > > ___ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
On Wed, Jul 01, 2015 at 02:37:25PM +0200, Patrick Niklaus wrote: > Confirmed on current develop branch using the Isle of Man extract. > Currently bisecting to find out which change caused this. It is > expected that pre-processing is not 100% deterministic, since we use > parallel sorting (node IDs will change), so the JSON response will > always have a different checksum. However the geometry should always > be the same. > > In theory it could happen that two paths with exactly the same travel > time get chosen in different files (because of different node ids, so > the edges are traversed in different order). Even with the same travel time it'll be very much appreciated if there was a deterministic ordering (which is the route and which the alternate) - In the end by highest osm node id or street name or whatever. And it seems the order of the json result is also "random". I know that its not specified what order an json dictionary/object gets serialized but its interesting to see. BTW: I have seen this kind of route flap before 0.3.9 IMHO probably even before 0.3.4 - It just got more anoying as i process a lot more routes so the noise went way up. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
Confirmed on current develop branch using the Isle of Man extract. Currently bisecting to find out which change caused this. It is expected that pre-processing is not 100% deterministic, since we use parallel sorting (node IDs will change), so the JSON response will always have a different checksum. However the geometry should always be the same. In theory it could happen that two paths with exactly the same travel time get chosen in different files (because of different node ids, so the edges are traversed in different order). On Wed, Jul 1, 2015 at 12:20 PM, Florian Lohoff wrote: > On Wed, Jul 01, 2015 at 10:45:36AM +0200, Florian Lohoff wrote: >> On Tue, Jun 30, 2015 at 08:23:30PM +0200, Frederik Ramm wrote: >> > Hi, >> > >> > On 06/30/2015 03:43 PM, Florian Lohoff wrote: >> > > Okay - i am brute forcing it now with a smaller planet extract and >> > > find disturbing results. >> > >> > Can you exclude a RAM defect? If you do 100 iterations of "copy large >> > file to other large file, compare md5 sums", do you get a consistent value? >> >> The machine is doing a lot of other stuff - A Postgres, an OSM Task >> Manager etc - Its an Intel Blade in an Modular Server Blade Rack. >> >> I dont think its memory defect. But i can try running memtest on it ... > > memtest86+ ran for 30 Minutes without an issue. 16GB ECC Memory Intel > P5000 Chipset with Intel Xeon CPUs. > > dd if=/dev/urandom of=rfile1 bs=1M count=16000 > md5sum rfile1 > 2a806948021ffd7ef19c272bc3f88508 rfile1 > while true; do cp rfile1 rfile2; sync; md5sum rfile2; done > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > 2a806948021ffd7ef19c272bc3f88508 rfile2 > > Ja - ich schliesse Speicherprobleme aus. > > Flo > -- > Florian Lohoff f...@zz.de > We need to self-defense - GnuPG/PGP enable your email today! > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIVAwUBVZO+2JDdQSDLCfIvAQrV9g/+PzmGuhs7LVF27IhUmYW/ZrXNbs9/aw35 > ZhzZtDha5BOcks27kr0oXAvvAvXUHiL+9F58tL0X5KNSP0sd7VaqD+bKvRrJzzoy > Dp5IG73HBXtna8VyBqNm8kBk140Xiqs9q7sxBwhDO8k5YRtpzvjZT0lh1c21rx8r > TC+9AONcMWEpEmLwgEqJs8t0kTfSsJXBPerZGwboMgu3KyqLVjMxOzHikaxKCcsb > IpHvo67LyiWG2pMren01p7eONXZQSbO74A1REujSi5Bbt6cpC5hHtPByjJfjw67Q > ChiADvAmP2pNkBjyYLnEm2IfpnuWXjZwFTRhwpQst6gkV71EZQPQsQiN0SxwGA7N > 0xcmRuNbT8gWmp7tX+szU0IiSIBrVauuWipU+8Xk+1LPAudcPpERuxG68O/rc24K > XvFZe+zJlJfw6zyDNcFGzQUsNdFpBvRj01h5wJVicZjKTv26XEahsOKGtHcALbC0 > jSX8eep7frswf1q+gzI0HHWJBCm6eWJI+XXcQ+y7qp5KGG4ZrOAiSW1N2uXqkKWP > oUFaFQXRDhnHtZz/jCv/3l+Di2kcuwAY1dspjdsEyVL5lkUTRZIBR7TLJajwR5en > hFg/hmtAZTYZ9iNqT5h7OpMc3vGD5orKuqWAmhpJnHlIvwciuyrkU5eTjdSfp+Sh > sPI4A6ROzcE= > =nzXf > -END PGP SIGNATURE- > > ___ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk > ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
On Wed, Jul 01, 2015 at 10:45:36AM +0200, Florian Lohoff wrote: > On Tue, Jun 30, 2015 at 08:23:30PM +0200, Frederik Ramm wrote: > > Hi, > > > > On 06/30/2015 03:43 PM, Florian Lohoff wrote: > > > Okay - i am brute forcing it now with a smaller planet extract and > > > find disturbing results. > > > > Can you exclude a RAM defect? If you do 100 iterations of "copy large > > file to other large file, compare md5 sums", do you get a consistent value? > > The machine is doing a lot of other stuff - A Postgres, an OSM Task > Manager etc - Its an Intel Blade in an Modular Server Blade Rack. > > I dont think its memory defect. But i can try running memtest on it ... memtest86+ ran for 30 Minutes without an issue. 16GB ECC Memory Intel P5000 Chipset with Intel Xeon CPUs. dd if=/dev/urandom of=rfile1 bs=1M count=16000 md5sum rfile1 2a806948021ffd7ef19c272bc3f88508 rfile1 while true; do cp rfile1 rfile2; sync; md5sum rfile2; done 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 2a806948021ffd7ef19c272bc3f88508 rfile2 Ja - ich schliesse Speicherprobleme aus. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
On Wed, Jul 01, 2015 at 10:26:29AM +0200, Patrick Niklaus wrote: > Is the dataset you use from Geofabrik? Does it also work for you on > small datasets like Berlin or Lichtenstein for example? I'm going to > run this locally an try to verify this. But seems very odd. There is > definitely some data corruption going on - be it RAM or faulty logic. I tried reproducing it with a 5km² subset of data around the route and i couldnt reproduce it. So i went for NRW and there i could reproduce it. Yes its a Geofabrik NRW export. Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
On Tue, Jun 30, 2015 at 08:23:30PM +0200, Frederik Ramm wrote: > Hi, > > On 06/30/2015 03:43 PM, Florian Lohoff wrote: > > Okay - i am brute forcing it now with a smaller planet extract and > > find disturbing results. > > Can you exclude a RAM defect? If you do 100 iterations of "copy large > file to other large file, compare md5 sums", do you get a consistent value? The machine is doing a lot of other stuff - A Postgres, an OSM Task Manager etc - Its an Intel Blade in an Modular Server Blade Rack. I dont think its memory defect. But i can try running memtest on it ... Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
Is the dataset you use from Geofabrik? Does it also work for you on small datasets like Berlin or Lichtenstein for example? I'm going to run this locally an try to verify this. But seems very odd. There is definitely some data corruption going on - be it RAM or faulty logic. On Tue, Jun 30, 2015 at 8:23 PM, Frederik Ramm wrote: > Hi, > > On 06/30/2015 03:43 PM, Florian Lohoff wrote: >> Okay - i am brute forcing it now with a smaller planet extract and >> find disturbing results. > > Can you exclude a RAM defect? If you do 100 iterations of "copy large > file to other large file, compare md5 sums", do you get a consistent value? > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > ___ > OSRM-talk mailing list > OSRM-talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/osrm-talk ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
Hi, On 06/30/2015 03:43 PM, Florian Lohoff wrote: > Okay - i am brute forcing it now with a smaller planet extract and > find disturbing results. Can you exclude a RAM defect? If you do 100 iterations of "copy large file to other large file, compare md5 sums", do you get a consistent value? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Route flapping / osrm-prepare adds randomness?
Hi,
On Tue, Jun 30, 2015 at 12:45:42PM +0200, Florian Lohoff wrote:
> Hi,
>
> i am doing QA based on calculating routes. For this i have a defined
> set of points (couple hundret) which i calc routes between. On length
> change i get a notification by email that the route has changed.
>
> Now i see routes which regularly flap between 2 different geometries and
> lengths without the OSM data beeing changed so i started investigating.
>
> The route flap happens irregular when osrm-prepare'ing the same
> germany.osm.pbf over an over. I see route flaps on same OSM data input.
>
> What i typically do (pseudo code) every 30-60 Minutes:
>
> while true; do
> update-germany-file-with-osmupdate
> osrm-extract -p car.lua germany.osm.pbf
> osrm-prepare -p car.lua germany.osrm
> restart-osrm-routed
>
> calculate-routes-and-compare-lengths
> done
Okay - i am brute forcing it now with a smaller planet extract and
find disturbing results.
Thats the script i am running - i do not touch the input file
inbetween.
#!/bin/bash
set -x
trap "kill ${ROUTED}" exit
while true; do
[ ! -d run ] || rm -rf run
mkdir run
ln -s ../input/nordrhein-westfalen-latest.osm.pbf \
run/input.pbf
bin/osrm-extract \
-p car.lua \
run/input.pbf
bin/osrm-prepare \
-p car.lua \
run/input.osrm
bin/osrm-routed \
-p 5444 \
-i 127.0.0.1 \
run/input.osrm &
ROUTED=$!
sleep 2
fname=`date +%Y%m%d%H%M%S`
wget -q -O - \
"http://localhost:5444/viaroute?loc=51.8919434301567,8.4548220634405&loc=51.8950384046146,8.46314334319787&instructions=true&compression=false";
\
>output/json.${fname}
perl -MData::Dumper -MJSON -e 'my $g=decode_json(); print Dumper
$g->{route_geometry};' \
output/geom.${fname}
sleep 1
kill ${ROUTED}
sleep 2
done
Thats the output files:
-rw-r--r-- 1 flo flo 1210 Jun 30 12:55 json.20150630125542
-rw-r--r-- 1 flo flo 1210 Jun 30 12:59 json.20150630125950
-rw-r--r-- 1 flo flo 2270 Jun 30 13:03 json.20150630130358
-rw-r--r-- 1 flo flo 1368 Jun 30 13:08 json.20150630130805
-rw-r--r-- 1 flo flo 1368 Jun 30 13:12 json.20150630131215
-rw-r--r-- 1 flo flo 1368 Jun 30 13:16 json.20150630131623
-rw-r--r-- 1 flo flo 2270 Jun 30 13:20 json.20150630132033
-rw-r--r-- 1 flo flo 1210 Jun 30 13:24 json.20150630132442
-rw-r--r-- 1 flo flo 1368 Jun 30 13:28 json.20150630132852
-rw-r--r-- 1 flo flo 1368 Jun 30 13:33 json.20150630133301
As one can see from the sizes - they differe HUGEly ...
flo@osm:~/projects/route-flap/output$ for i in json*; do json_pp <$i | grep
found_alternative; done
"found_alternative" : false,
"found_alternative" : false,
"found_alternative" : true,
"found_alternative" : false,
"found_alternative" : false,
"found_alternative" : false,
"found_alternative" : true,
"found_alternative" : false,
"found_alternative" : false,
"found_alternative" : false,
Although i use the SAME input file - with the SAME coordinates to query for an
route
i get different results.
Its a permutation of route A or route B and with or without alternatives
it seems.
Extracting only the geometry with this perl onelines:
perl -MData::Dumper -MJSON -e 'my $g=decode_json(); print Dumper
$g->{route_geometry};'
returns significantly different geometries.
-rw-r--r-- 1 flo flo 1696 Jun 30 12:55 geom.20150630125542
-rw-r--r-- 1 flo flo 1696 Jun 30 12:59 geom.20150630125950
-rw-r--r-- 1 flo flo 1696 Jun 30 13:03 geom.20150630130358
-rw-r--r-- 1 flo flo 2345 Jun 30 13:08 geom.20150630130805
-rw-r--r-- 1 flo flo 2345 Jun 30 13:12 geom.20150630131215
-rw-r--r-- 1 flo flo 2345 Jun 30 13:16 geom.20150630131623
-rw-r--r-- 1 flo flo 1696 Jun 30 13:20 geom.20150630132033
-rw-r--r-- 1 flo flo 1696 Jun 30 13:24 geom.20150630132442
-rw-r--r-- 1 flo flo 2345 Jun 30 13:28 geom.20150630132852
-rw-r--r-- 1 flo flo 2345 Jun 30 13:33 geom.20150630133301
-rw-r--r-- 1 flo flo 1696 Jun 30 13:37 geom.20150630133714
Flo
--
Florian Lohoff f...@zz.de
We need to self-defense - GnuPG/PGP enable your email today!
signature.asc
Description: Digital signature
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk
[OSRM-talk] Route flapping / osrm-prepare adds randomness?
Hi, i am doing QA based on calculating routes. For this i have a defined set of points (couple hundret) which i calc routes between. On length change i get a notification by email that the route has changed. Now i see routes which regularly flap between 2 different geometries and lengths without the OSM data beeing changed so i started investigating. The route flap happens irregular when osrm-prepare'ing the same germany.osm.pbf over an over. I see route flaps on same OSM data input. What i typically do (pseudo code) every 30-60 Minutes: while true; do update-germany-file-with-osmupdate osrm-extract -p car.lua germany.osm.pbf osrm-prepare -p car.lua germany.osrm restart-osrm-routed calculate-routes-and-compare-lengths done Now i disabled the step of updateing the germany.osm file and i still do see the route flaps. It seems osrm-prepare adds some randomness to graph weights. Here you can see a visual change in route. The route flapped from red to green and back just be re-preparing the very same osm.pbf file: http://osm.zz.de/routeqa/?rid=59464,59492 http://osm.zz.de/routeqa/?rid=59492,59571 Is this a known issue/side effect of the contracted hierarchies or is this expected behaviour e.g. a real bug? Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! signature.asc Description: Digital signature ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
