Steve Hosgood <[email protected]> writes: > Claudius wrote: >> Am 16.04.2009 18:52, Andrew M. Bishop: >> >>> An online demonstration of the router for the UK is available as well: >>> >>> http://www.gedanken.org.uk/mapping/router/router.html
>> The map div of your demo page doesn't show at all in Opera browser. This >> is probably caused by loads of </td> and </tr> missing. Use the W3C HTML >> validator to clean up your HTML source: http://validator.w3.org/ >> >> ...and keep your good work. Looks primising. > Yeah - I'll second that. I see the map display is working now, so > obviously the missing tags are fixed. Thanks for the words of encouragement. It wasn't missing tags (they aren't missing, they are optional in HTML 4.01 - the page validated OK) it was a difference of opinion between browsers on how to interpret the HTML/CSS. Apparently an HTML DIV marked with "height: 100%" inside a table row marked as "height: 100%" inside a table marked as "height: 100%" inside an absolutely positioned DIV that fills the window height is only shown as tall as possible in Firefox v3.x and zero height otherwise. I have reverted the HTML/CSS combination to an earlier one that worked. > Useful effects of this router are being able to spot broken connectivity > - especially in things I've not spotted using mkgmap to create Garmin > routable maps for my in-car GPS unit. For instance: things wrong with > the cycleways. As soon as the OSM -> 0.6 API kerfuffle is over, I've got > a few cycleway edits for Swansea! Yes, I have found several of those while developing it. Also roundabouts not tagged as such (it was routing the wrong way round). I had thought about using it to find roads that are not connected to the highway network. Start somewhere that obviously is connected and try routing to one node on each other road way. I don't know how you would interpret the data though. It also wouldn't find breaks that can be routed round. > May I offer a couple of comments please: > 1) The positioning of the 'start' and 'end' markers for the route are a > bit over-critical. The slippy map provided doesn't let you zoom in > enough to place them accurately enough. Either please add a further > layer of zoom to the zoom-tool, or increase the tolerance for searching > for a road near the 'start' or 'end' markers. Currently it finds the closest highway node of any type. I have been thinking about limiting it to finding only nodes that are connected to highway types that you have selected to use. This should solve your problem. > 2) Would be nice to mark a road type as "avoid if possible". For > instance, when finding a bicycle route you might like to mark primary > roads in that way. I obtained a similar result by setting the speed > limit for a primary as 5kph, then selecting "find fastest" but of course > the estimated arrival time would be skewed by doing that. I'd might > expect to do 20kph on a bike on a primary if I was on such a road, but > would rather not be there in the first place. Sometimes, there's just no > avoiding riding the bike on a primary - or even a trunk. This is already a work in progress - replacing the yes/no selection with a percentage preference. > Other than that - great work, neat GUI, interesting results. > Keep it up, and thanks for what you've done so far. -- Andrew. ---------------------------------------------------------------------- Andrew M. Bishop [email protected] _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
