It looks like the server that was providing routing for the America’s has been disabled (I get timeouts trying to login). This was a sponsored server and the server has been provided for far longer then originally agreed upon, so I’m not complaining. I’ve made a change so that all route requests for the America’s is handled by one of the two remaining servers. The routing database for the America’s on that server is quite old though…
Sorry for any inconvenience.
Anyone with a server or VM to spare that has 32 GB ram is more then welcome to contact me.
I’m trying to rebuild the north american database for gosmore on Ubuntu Saucy (using the version from universe repo). How long does it take, and how do I know if it is still working?
I started it around 24 hours ago. Top shows gosmore is using 100% of CPU, but as of right now, it stopped writing to /usr/share/gosmore directory more than 12 hours ago.
The output on the console:
Building gosmore.pak using style elemstyles.xml...
Icon public.png not found
Icon public.png not found
Icon religion/synagogue.png not found
Icon religion/mosque.png not found
Icon rendering/landuse/cemetery.png not found
Icon wlan.png not found
Icon rendering/landuse/cemetery.png not found
1 while (xmlTextReaderRead (xml) == 0
2 while (fread (&nd, sizeof (nd), 1, groupf[i]) == 1)
3 while (fread (s, sizeof (s), 1, groupf[i + NGROUPS]) == 1)
4 while (fread (&nd, sizeof (nd), 1, groupf[i]) == 1)
5 while (fread (s, sizeof (s), 1, groupf[i + NGROUPS]) == 1)
6 while (fread (&nd, sizeof (nd), 1, groupf[i]) == 1)
7 while (fread (s, sizeof (s), 1, groupf[i + NGROUPS]) == 1)
8 while (fread (&nd, sizeof (nd), 1, groupf[i]) == 1)
9 while (fread (s, sizeof (s), 1, groupf[i + NGROUPS]) == 1)
10 while (fread (&nd, sizeof (nd), 1, groupf[i]) == 1)
Public transport (i.e. bus/train/metro routes and time schedules) is not supported on yournavigation.org. The option ‘public service’ is just for routing over ways that allow public service. In OSM mapping speak these are the ways that are labelled: psv=* (and probably emergency=*, but I’m not sure at this moment).
The Gosmore routing engine only performs least-cost routing based on road speeds for each type of transport. It doesn’t support public transport routes or time schedules. Perhaps it’s possible to pre-process the data to make Gosmore work ‘sort-of’ but it will never be good at it. You’d better find a different routing engine that is specifically built to handle this type of transport.
Perhaps a list of all the issues I encountered get YOURS going would help. Many are just differences between the instructions and what I had to do. Other were actual changes I had to make that are bugs.
Setup:
VM with 4 cores, 16GB RAM, 120GB hard disk. Ubuntu Saucy (13.10).
Gosmore:
First I tried to install it on RHEL. Gave up because I could not get required libraries installed.
Moved to Ubuntu, because I saw that gosmore is part of the universe repo.
Tried to build the planet, died on disk space.
Tried to build americas, stuck in infinite loop with 100%CPU
In the YOURS section, I believe a few updates in the doc would save the next installer from having to debug the scripts. In particular, it could state that gosmore executable or link to it must be in the yours directory, and what the names and locations of the .pak files are.
For the xml files, I don’t know what the difference should be. It would be helpful if they were included in the repo with instructions on where to put them.
Regarding the spurious comma in api/1.0/gosmore.php, it is a bug that prevents GeoJSON from working in 1.0.
In any case, the site is up and running. My teammates and managers are really impressed - it works beautifully. I plan to add the eurasia database some time in the future.
Thanks for all your help along the way,
Harold Ship
I know that YOURS isn’t very easy to setup and not everything is consistent, but it’s nice to see that someone else can make it work by fixing (mainly) a few hard-coded paths. Thanks also for the bugreports
Regarding elemstyles.xml: I built the gosmore.pak twice. Once with the default elemstyles and one with only routing related info. The resulting PAK files were identical in size, so it appears not to make a difference when using Gosmore with the compiler option ROUTING_ONLY enabled.
I am running a local copy of YOURS, and my users have noticed that my APIs don’t return ‘traveltime’, although the hosted version at http://www.yournavigation.org does.
Is there something I need to do to get this working?
Also replied by email yesterday, but for completeness my answer:
The Gosmore routing engine provides an estimated time to destination on each node in it’s output. The first node in Gosmore’s output should contain the total trip time (Gosmore outputs the route in reverse order).
I had the same problem and Lambertus was kind enough to send me his version of the gosmore.php file. Note that you will need to update his local path references (shown below) to your settings:
…
// Geographic pak file selection
$pak = '';
if ($flon < -30) {
// American continents (North and South)
$pak = '/home/lambertus/gosmore/america/gosmore.pak';
} else {
// Europe, Asia, Africa and Oceania continents
$pak = '/home/lambertus/gosmore/eurasia/gosmore.pak';
}
if (file_exists($pak)) {
$dir = '/home/lambertus/gosmore/';
…
You will also need another file called geography.class.php which needs to be in the same directory as the gosmore.php file. I’ll send you both files in an email. (i’d post them here but don’t see an option - anyone who can can help me with posting these files here…?)
Thanks packhamster. I’ll add that you don’t really need the geography.class.php file. The gosmore.php file also contains two alternative functions to calculate the distance between nodes, they are currently commented out. To use these simply uncomment the functions (GreatDistance and/or Haversine) and replace the call to geography class with the getDistance() function. These functions are probably a bit less accurate then the geography class although unnoticeable for short trips, but they’re slightly faster especially because the geography provides a vincenty option which is used by default but is requires more calculations. Alternatively use the query option ‘distance’ and set it to ‘gc’ or ‘h’ as documented here.
It’s nice to see how well Gosmore actually scales. While originally intended as a mobile routing engine it powers yournavigation.org with worldwide routing and handled more then 700.000 route requests on january 16th. I expect yournavigation.org will be able to scale way beyond 1 million requests per day with the addition of a new server (Core i7-4770 and 32 GB ram), courtesy of Lobo.at. I plan to show the results of some intense benchmarking shortly.
I’m still very interested in a sponsoring of (temporary) access to a server with 64 GB ram which I’d like to use for experimenting (and hopefully add as routing backend) with the OSRM routing engine.
We use Yournavigation.org in a tourism application to get walking directions from one city attraction to another. In the walking directions, we sometimes see things like below:
Go straight ahead. Follow the road for 0.0 mi.
Turn right. Follow the road for 0.0 mi.
Turn sharp right into Piazza di Trevi. Follow the road for 0.0 mi.
Continue on Via Poli. Follow the road for 0.0 mi.
We think the reason why we see so many “0.0 mi” is that there is the short walking distance between each turn. Since the distance value shows only one digit after the decimal point, the last two digits were left off. Normally one should see “0.034 mi” or “0.045 mi”, etc.
Is there a way for us to get the distance value displayed with three digits after the decimal point in the walking directions?
Also, it seems that the distance metric is always in mile. Is there a setting to change the distance metric to kilometer, meter, or foot?
Unfortunately I have no control over the number of digits in the directions. But you may notice that the metric output changes automatically between meters and kilometers while the imperial output is always in miles, again this is behavior I don’t have control over. A simple and slightly humorous fix in your app replaces ‘0.0 mi’ with ‘a few feet’…
I’ve asked the author of RoutingInstructions to automatically change mi to feet for short distances.
Thank you for the quick reply. We played with the “lang” setting in our queries and saw how the distance unit changed according to the “lang” parameter. However, we notice that the total travel distance value of the route remains the same for en_GB and en_US. So if the travel distance was 1.5 miles in en_US, it will be 1.5 kilometers in en_GB. We can make the km/mile conversion on our side, but how do we know which value is correct, 1.5 mile (based on en_US) or 1.5 km (based on en_GB)?
That’s a good observation! The total distance is calculated by a geography class (I could just take the value from Gosmore but don’t) and is always metric (km).
I’ve updated the documentation of the parameters in the wiki which will hopefully prevent confusion for future new API users.
The RoutingInstructions applications clearly returns metric units for en_GB (and also for en_CA and en_AU).
