Hi Torsten,

How about a little more general approach? I would propose the following:

If a way has a note with an access restriction, the segments of the way that connect to the node have the access restrictions from the node placed on them.

This would have the following advantages: - With such an a feature, you would not only handle bollards, but also gates and other obstacles.

Well, the existing code can handle other barriers if it's told about them.

- You need not to use a default access restrictions, but you can rely on the restriction in the data base. If no access restriction is defined in the data, you can still imply one via the style file. (I don't know, whether such a style rule would be applied in time before you place the restrictions on the way?)

- The maps would be still usable, if it is run with with false vehicle settings. (Only the car setting seems to provide a real good routing, so to get good a bicycle routing, you need a specially generated map run in the car-mode).

What do you think about such a modification?

I think your suggestion is a good idea. In fact, while working on this it occurred to me that the same technique could be used to apply other attributes to the way, such as width and speed limitations. So a general approach is probably best. I shall work on it. Cheers, Mark

Hi Dermot,

I like what you're doing here, but won't that have negative impact if the adjoining way segments are fairly long? Might it prevent you from being routed to within, say, 200m of the bollard? Or will an only-viable-route logic kick in here?

My testing indicates the later. If there is no other route, mapsource at least, ignores the restriction. Cheers, Mark

Hi Dermot,

Yes but...

2009/7/7 Mark Burton <markb@ordern.com>:

...

My testing indicates the later. If there is no other route, mapsource at least, ignores the restriction.

Consider a case where you have a very simple configuration which I shall try to draw in ASCII:

| | | +---------------x-------------o----------- | | |

Let "o" be the bollard and x your destination. For badness, let's also assume that there is only a single way segment between o and the junction at "+".

So now the entire piece of road from junction to x is access=no. Do you think the restriction will be ignored in this case?

Yes, mapsource ignores the restriction.

(maybe this won't matter in the real world, I'm just saying it now in case it could be. I suppose the harder and more correct solution would be to carve off 5m either side of the bollard into separate restricted segments)

I had already considered doing that but it's not worth it unless the real GPS units behave differently from mapsource. Cheers, Mark

Hi Apollinaris,

...

I had already considered doing that but it's not worth it unless the real GPS units behave differently from mapsource.

yes they behave different. don't ask how. couldn't figure out a pattern yet.

Well, if necessary, I can add the stub segments either side of the POI. Cheers, Mark

Hi Martin,

But what about using turn restrictions instead of manipulating the nearest segments of the ways?

See recent posts.

The reason is: if my destination is on side "A" of the bollard on the restricted segment, garmin would still send me via the bollard whe it's shorter because it ignores all restrictions if the destination is within a restricted zone, right?

My testing with mapsource did not do that. It took the long way around even though the destination was close to the other side of the bollard. Cheers, Mark