And we don’t have good elevation maps so it’s even harder… 
Since you are only in Netherlands you should be able to convert your OSM nodes to your local orto-grid and just use simple geometry…
Found this to calculate distances in PHP If you want to copy and paste. I haven’t tested this, and there are notes saying that the original algorithm didn’t converge for all cases, and the PDF you linked seems to be the original 1975 paper.
So again untested code:
function distInvVincenty($lat1, $lon1, $lat2, $lon2) {
/* WGS84 stuff */
$a = 6378137;
$b = 6356752.3142;
$f = 1/298.257223563;
/* end of WGS84 stuff */
$L = deg2rad($lon2-$lon1);
$U1 = atan((1-$f) * tan(deg2rad($lat1)));
$U2 = atan((1-$f) * tan(deg2rad($lat2)));
$sinU1 = sin($U1);
$cosU1 = cos($U1);
$sinU2 = sin($U2);
$cosU2 = cos($U2);
$lambda = $L;
$lambdaP = 2*pi();
$iterLimit = 20;
while ((abs($lambda-$lambdaP) > pow(10, -12)) && ($iterLimit-- > 0)) {
$sinLambda = sin($lambda);
$cosLambda = cos($lambda);
$sinSigma = sqrt(($cosU2*$sinLambda) * ($cosU2*$sinLambda) + ($cosU1*$sinU2-$sinU1*$cosU2*$cosLambda) * ($cosU1*$sinU2-$sinU1*$cosU2*$cosLambda));
if ($sinSigma==0) {return 0;}
$cosSigma = $sinU1*$sinU2 + $cosU1*$cosU2*$cosLambda;
$sigma = atan2($sinSigma, $cosSigma);
$sinAlpha = $cosU1 * $cosU2 * $sinLambda / $sinSigma;
$cosSqAlpha = 1 - $sinAlpha*$sinAlpha;
$cos2SigmaM = $cosSigma - 2*$sinU1*$sinU2/$cosSqAlpha;
if (is_nan($cos2SigmaM)) {$cos2SigmaM = 0;}
$C = $f/16*$cosSqAlpha*(4+$f*(4-3*$cosSqAlpha));
$lambdaP = $lambda;
$lambda = $L + (1-$C) * $f * $sinAlpha *($sigma + $C*$sinSigma*($cos2SigmaM+$C*$cosSigma*(-1+2*$cos2SigmaM*$cos2SigmaM)));
}
if ($iterLimit==0) {return NaN;} // formula failed to converge
$uSq = $cosSqAlpha * ($a*$a - $b*$b) / ($b*$b);
$A = 1 + $uSq/16384*(4096+$uSq*(-768+$uSq*(320-175*$uSq)));
$B = $uSq/1024 * (256+$uSq*(-128+$uSq*(74-47*$uSq)));
$deltaSigma = $B*$sinSigma*($cos2SigmaM+$B/4*($cosSigma*(-1+2*$cos2SigmaM*$cos2SigmaM)- $B/6*$cos2SigmaM*(-3+4*$sinSigma*$sinSigma)*(-3+4*$cos2SigmaM*$cos2SigmaM)));
$s = $b*$A*($sigma-$deltaSigma);
return "Distance: ".$s;
}
I would be disappointed if we implement Netherlands-specific code. gosmore is ready to be used on the whole planet file : It takes 3 hours to import it on a dual core 64 bit machine with 2 GB RAM and generates a 6.5 GB file.
Predicting the travel distance with OSM will always be inaccurate, because we don’t have height data (as mentioned), DGPS wasn’t used, people don’t drive, cycle or walk down the middle of the road, OSM is out of date and the users don’t always connect the ways. And people want travel time…
I can make gosmore output the names of the ways (1 per segment). So then it will be helpful if we know weather each turn is left or right (e.g. by calculating bearing), because then we can generate simple driving instructions.
I tried that yesterday but Gosmore choked on our sponsored 32 bit machine while processing a planet file from April 16th. The person that maintains the system claims that 32 bit in theory doesn’t mean that it won’t be able to process the planet. I assume Gosmore uses architecture specific variable types like ‘int’?
Yeah ppl always want more but, before we venture into the advanced routing areas, I want to get basic routing functional and available. Let’s worry about exact traveltimes determined by combining the measured speeds of mobile phones, wifi networks and historic gpx logs later.
That would be my next request for Gosmore. It would be great if you could implement that 
I promise to put it to good use on the website 
If you convert to your local NL grid, or .se grid, or like OS grid in uk, the code will still be the same for all countries. Since one unit equals one meter. This has several benefits, but is most probably too hard to do since there are too little information on how you use these grids. And there is no server available that can use multiple grids
Yes incomplete data in OSM is a problem, but if you can you should try to find these inconsistencies. This is something that should be easier todo when we can see what happens with routes, this would make it easier to fix topology.
Are you sure these will add much to the time?
- DGPS wasn’t used
- People don’t drive, cycle or walk down the middle of the road
Then how do we add it? I’m guessing you can’t do that with current OSM data. At least it must be very hard to do for cars.
We need:
- crossing=lights/uncontrolled
- speed
- traffic_jammy
Anything else?
emj, perhaps it’s nice to know that our server is currently crunching away on the planet file to allow worldwide routing 
I’ve tried to accomplish that using a single Gosmore .pak file for the whole world, but that won’t work since our server is 32bit currently. So instead I’ve split the routing backend into two (America and Eurasia) in an attempt to limit the .pak file size.
The only backside of this approach is that you won’t be able to get the routing engine to produce a route that would require you to swim from Boston to London across the Atlantic ocean 
This worldwide service will be available as long as our sponsor allows us to and as long as it doesn’t interfere with it’s main function: serve slippy maps for the Netherlands. I think it will be able to process about 10-20 route requests per second (about 0.03 seconds per request) under optimal circumstances (estimate, the service isn’t up and running yet). Under worst conditions it will be able to only produce about 8 requests per minute as Gosmore sometimes seems to choke on the data causing it tor run for minutes on end, but limited with ulimit).
Update: Gosmore choked on the Tiger data in North America, so routing only works for Europe, Asia, Africa and Polynesia: http://tile.openstreetmap.nl/~lambertus/routing-world.
Nic Roets, you might find it interesting that a first attempt to route from Camps Bay Cape Town to Graaff Reinet (which I drove once) was calculated in about 41 seconds and returned almost 2000 nodes
Works nicely, as you say a little on the slow side.
Hey don’t bite the hand that feeds you!
Hi Lambertus, it works nice. In Germany too!
Ok, i know the German Language is a little specialy…
The routing works not with the Caracter like “ß” it meens “ss” but in many Street Names there is a “ß”.
Georg
I think looking up a street, city combination for the ‘to’ and ‘from’ coordinates doesn’t work? If so, can you tell me if the namefinder service works properly with “ß” characters?
The namefinder service works with “ß” no Problem
But the Routing Demo dosen’t. Test this please “from: Friedenstraße, Aßlar” “to: Bergstraße, Wetzlar”…
It’s not a big Problem, it’s a great work from you! And when the Software will finished it will work very well, i think.
Georg
The routing site uses the namefinder service lookups to translate street/city names to coordinates through a proxy. This is what namefinder responds:
<searchresults
find='Friedenstra�e, A�lar'
sourcedate='2008-06-06'
date='2008-06-06 20:28:13'
distancesearch='no'
findname='Friedenstra�e'
findplace='A�lar'
error='place not found'
>
Probably has something to do with URL encoding. It’s on the todo list now.
Late update: this has been fixed a long time ago.
I added route altitude profile image feature for routes less then 400 nodes. The image is generated using Sjors Provoost’ GSOC code/service.
Still looking for a way to be able to add support for North and South America…
Thanks a lot for this service, tested one route on foot and immediately found an error in the data
Regards, Florian.
That’s great
The routing works well but I find that when I try to zoom in on part of the route, the blue line showing the route disappears. Maybe this is another IE bug?
Oliver
Afaik this only happens on the highest zoom level and when you zoom out one level the route appears again. Is this the same behaviour that you are seeing? If so, it has been this way since the start of this project and I’m not sure why…
Edit: I changed the number of zoomlevels from 19 to 20 and now you can zoom in all the way and still see the route vector.
PS. I must say that I develop this service using FF 2 and FF 3 with the occasional check in IE. I know that the site looks odd in IE but my CSS skills to fix that have yet to be developed 
It works good in Opera. I already found many bugs in OSM-Data, using your tool…
Just the map is too small … can you make the width variable?
How often is the database behind the routing application updated? (in the Help it says that is updated once a week after the new planet dump is finished, but I made some modifications and this week I haven’t seen any update). It will be available pretty soon or it will take another 2-3 days?
Btw, great tool, it really helps us findinf errors in the database.
Things like updates have stalled because of my holiday… I will get to it asap.
I will try to but my CSS skills are next to 0 and I’m glad that it works in FF and Opera as it does now…