[OSM-talk] City routing grid for Australia and the US

Sun Jul 22 11:28:27 BST 2012

On 22/07/12 03:49, Kai Krueger wrote:
> On 07/21/2012 04:56 PM, Svavar Kjarrval wrote:
>>
>> On 21/07/12 21:21, Kai Krueger wrote:
>>> On 07/21/2012 01:05 PM, Simone Cortesi wrote:
>>>> Yes please,
>>>> I would like to do the same too...
>>>>
>>>> -S
>>>>
>>>> On Sat, Jul 21, 2012 at 8:56 PM, Svavar Kjarrval <svavar at kjarrval.is> wrote:
>>>>> I want to make a similar routing table file for my country. Any chance
>>>>> of giving us instructions on how to generate such routing grids of our own?
>>>>>
>>>>> - Svavar Kjarrval
>>>
>>> I have now pushed the code I used to generate those tables to
>>> github. ( https://github.com/apmon/RoutingGrid )
>>>
>>> It is a little java program that takes in a list of coordinates and
>>> city names and generates the html file for the routing grid.
>>>
>>> You can easily run it on your own list of coordinates / cities.
>>>
>>> Dennis, who is responsible for the OSRM server, was OK with me
>>> running the code against his server, and I suspect he wouldn't mind
>>> if others do the same.
>>>
>>> It uses Google's directions API as a reference, so it is subject to
>>> their terms. Currently they seem to allow 2500 requests per day,
>>> which would correspond to a maximum sized grid of 50 cities. It can
>>> cache the results from Google in a reference list, so you only need
>>> to query google once per city list.
>>>
>>> Kai
>>
>> Thanks a lot! I had an idea of a larger list of co-ordinates and
>> could use this code to make a databased version. I'd probably have to
>> host my own OSRM instance so I wouldn't bombard the main one with so
>> many queries in a short time interval.
> OSRM really is amazingly fast (assuming you have a server with
> sufficient ram to convert the data into a routing db in the first
> place), so I don't see too much issue in principle in significantly
> expanding the routing grid. Calculating a route from New York to Los
> Angeles takes 500ms and that includes network round trip time across
> the Atlantic (ping time to the server from here is 150 ms). Depending
> on how far you want to expand it, you might even still be able to use
> the current instance, although you would have to ask Dennis about that.
>

I was thinking about expanding the grid to every town in Iceland, which
are at least 75. With Google's limit of 2500 queries a day, I'd have to
make a program which makes regular queries and is careful about not
going over that limit. And this is only the towns. This does not take
into account addresses within them. Surely, I won't do this for every
town as most of them are only a few streets but nontheless, it would
generate a big queue of queries against Google. I don't know how the
OSRM will react to such a large number of queries on a regular basis as
I need to refresh the OSRM distances.

>
> If there is interest, I will try and expand the routing grid my self
> over the next couple of days, either to new countries or to more
> cities in a country.
>
> With the current code, the bigger short term issue is that it uses
> Google as a reference source and its limited allowance. However, once
> the routing problems are fixed again in OSM, there is no reason to not
> use a known good snapshot of OSM data as a reference in future and use
> it in quality assurance to check for any new broken routes. You could
> also use a snapshot from before the bot ran if you have access to it.
> Overall, this is really only a very small "script" that I hacked
> together in a couple of hours yesterday of which most of the time was
> spend in getting the coordinates for the cities list. So if you are
> planning to make too many changes, you might be better of writing it
> from scratch.

It does give me ideas and I'll probably convert it anyway to another
programming language. The command flow will give me neat ideas.

>>
>> It would be a kind of a quality assurance checker where I'd not only
>> check links between cities/towns, but also links between some of the
>> addresses inside them. Maybe add important POIs in the country as
>> well. I really want the map to be of superior quality.
>
> You would likely need to go about it a bit different than to display
> routes in a grid (so the current code probably isn't a great basis),
> but the idea of automated quality control by generating a large set of
> routes between cities/towns/POIs has been floating around for quite a
> while. It is one of the reasons why there is still a debate about
> getting OSMF to operate a routing server itself to support these kind
> of QA checks.
>
> Personally, however, I suspect that an automated system will only
> every be able to check a fraction of the most prominent (and
> important) routes / roads and it will be more important to expose as
> many mappers as possible to the routing interface for them to try
> their own local routes for which they know the optimal solution.
>
> Kai
>
>>
>> - Svavar Kjarrval
>>
>>>
>>>>> On 21/07/12 18:32, Kai Krueger wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> Inspired by the US 250 cities routing grid[1] used in the original TIGER
>>>>>> cleanup in 2009, I have now created a similar routing grid for the USA
>>>>>> and Australia.
>>>>>>
>>>>>> Australia: http://apmon.dev.openstreetmap.org/aus_routing_grid.html
>>>>>> USA: http://apmon.dev.openstreetmap.org/us_routing_grid.html
>>>>>>
>>>>>> It takes the top cities of the country and calculates the routing
>>>>>> distances between them and displays the result in a routing grid. It
>>>>>> allows to check the top tear inter city road network. Unusually long
>>>>>> routes are likely caused by broken data and indicates where things need
>>>>>> fixing.
>>>>>>
>>>>>> In the grid, all routes that are more than 5% longer or slower than
>>>>>> expected* are show in red, otherwise they are considered as
>>>>>> superficially OK. The reference values are in brackets. If you click on
>>>>>> the link, you will be sent to the detailed routing information.
>>>>>>
>>>>>> Unfortunately the situation, particularly in Australia, is pretty bad.
>>>>>> In Australlia currently non of the routes between the top ten cities
>>>>>> pass this criterion and in fact most of the routes can't be calculated
>>>>>> at all any more due to disconnectedness of the road network.
>>>>>>
>>>>>> So for all those who are finished remapping their own area and are
>>>>>> looking to help with a bit of armchair mapping, trying to get more of
>>>>>> these routes green could be a good idea for arm chair mappers. Let's see
>>>>>> how quickly we can get all of them green!
>>>>>>
>>>>>> The routing information is calculated using the Open Source Routing
>>>>>> Machine ( http://map.project-osrm.org/ ) and if I am not mistaken,
>>>>>> updates its data once a day. I will equally try and recreate those grids
>>>>>> on a daily basis to help track progress on the remapping.
>>>>>>
>>>>>> Happy remapping,
>>>>>>
>>>>>> Kai
>>>>>>
>>>>>> * The time and distance that is expected is currently determined using
>>>>>> google's directions API. Although not perfect by any means, it is
>>>>>> probably the most reliable source for now as a reference.
>>>>>>
>>>>>>
>>>>>>
>>>>>> [1] http://wiki.openstreetmap.org/wiki/TIGER_fixup/250_cities/routing_grid
>>>>>>
>>>>>> _______________________________________________
>>>>>> talk mailing list
>>>>>> talk at openstreetmap.org
>>>>>> http://lists.openstreetmap.org/listinfo/talk
>>>>> _______________________________________________
>>>>> talk mailing list
>>>>> talk at openstreetmap.org
>>>>> http://lists.openstreetmap.org/listinfo/talk
>>>>>
>>>
>>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20120722/51899b38/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20120722/51899b38/attachment-0001.pgp>