Better access rights encoding for gosmore

[Philip Homburg]

Currently, gosmore encode access rights to a road using one bit per supported
vehicle type, and two additional bits for oneway and roundabout.

I'd like to propose changing this to two bits per vehicle type, one for the
forward direction and one for the reverse (backwards) direction and
dropping the oneway bit (I'm not sure about what the roundabout bit does).

At the moment, gosmore doesn't seem to support oneway=-1, but that can be
handle with the current encoding scheme by reversing the way internally.
Gosmore 'handles' the various forms of  cycleway=opposite{,_lane,_track} by
simply ignoring oneway for bicycles.

In Amsterdam, many oneway signs have an additional sign to exempts bicycles and
mopeds. Worse are roads that just have a 'no entrence for motorcars' sign on
one side of the street. I'd like to modify gosmore to properly route over
such streets for all vehicle types.

Changing to this encoding is IMHO the easiest way to move forward. An
alternative would be to use access restrictions.

I'd like to make this change, whenever I have time to actually do it. Unless
somebody thinks that this is a really bad thing to do.



_______________________________________________
Routing mailing list
Routing@...
http://lists.openstreetmap.org/listinfo/routing

[Nic Roets-3]

Hello Philip,

I've changed gosmore drastically since you wrote this. I created a function Osm2Gosmore() that does most of the rebuild time handling of tags, like changing the bits you mentioned below.

I haven't dropped the oneway bit, but I gave bicycles their own oneway bit. It is set for all oneways except when cycleway=opposite*

I also added code for the dismounting code. Basically it says that a cyclist can go anywhere a pedestrian does except through barriers, like gates. Barriers are configured with the {foot,bicycle,...}=... tags. There is a penalty for dismounting, but it may need to be fine tuned. Stairs need some though because some people will carry their bicycles up stairs if it's faster.

oneway=-1 are now reversed during rebuild.

I also added penalties for crossing a bit road (e.g. primary) using a small road (e.g. residential) and turning left (right) in right hand drive countries (lhd). The constants may need work. It should help to route vehicles around city centers.

Lambertus, the current cyclenet thing may not work anymore and will become harder and harder to support. I suggest we drop it. From my little experience it feels like cyclists who want to use cyclenetworks aren't too obsessed with finding the fastest and safest route. They have extra contraints that are hard to quantify, like weather or not they have cycled there before and in that case a rendered map is better. Fortunately the new Osm2Gosmore() function will be able to modify parameters when it sees an ncn / rcn or lcn tags.

I haven't tested the CGI interface recently. It may need some work.

Regards,
Nic


_______________________________________________
Routing mailing list
Routing@...
http://lists.openstreetmap.org/listinfo/routing

[Lambertus]

Nic Roets wrote:
> Lambertus, the current cyclenet thing may not work anymore and will
> become harder and harder to support. I suggest we drop it. From my
> little experience it feels like cyclists who want to use cyclenetworks
> aren't too obsessed with finding the fastest and safest route. They have
> extra contraints that are hard to quantify, like weather or not they
> have cycled there before and in that case a rendered map is better.
> Fortunately the new Osm2Gosmore() function will be able to modify
> parameters when it sees an ncn / rcn or lcn tags.
>
If you feel that the cyclenet code is not maintainable then you should
abandon it. I've gotten a lot of critique on the results of those routes
anyway.

There are plans on creating a cyclenode network routing function on
yournavigation.org which would rely heavily on the cyclenet code, but
perhaps it's better to just develop a specialized router for that. It's
in discussion stage so no harm done if the cyclenet code is dropped. But
I do like it's ability to effortlessly route various cycleroutes which
contain gaps (e.g. mapping errors or by design) a lot.

> I haven't tested the CGI interface recently. It may need some work.
>
I've encountered two big problems lately:
- Routing to/from various points in Europe that contain a point
somewhere in Antartica (-180,-85). I cannot find the source for this but
suspect a) an structural import error which adds that coordinate to an
otherwise perfectly defined road according to OSM data or b) some sort
of overflow during routing calculation. Example:
<http://www.yournavigation.org/index.php?flat=52.493005896066&flon=4.9625349044816&tlat=49.969775495096&tlon=6.0129986560561&v=motorcar&fast=1&layer=mapnik>

- Database rebuilding crashes somehow on my CentOS 64bit server and
Ubuntu 64bit laptop (clean svn export, source is Osmosis extract).

- There are a few tickets in the Trac website, of which two are
regarding turn restrictions. With ever more turn-restrictions in the
database it would be great to have better support for those:
<http://trac.openstreetmap.org/query?component=gosmore&order=priority>

- And one other request: can gosmore output the edge cost for each
segment as well? Being able to see the cost will hopefully make it
easier to see why Gosmore chooses a certain route.

_______________________________________________
Routing mailing list
Routing@...
http://lists.openstreetmap.org/listinfo/routing