logo separator

[mkgmap-dev] POI barrier/access restriction

From Gerd Petermann gpetermann_muenchen at hotmail.com on Wed Apr 15 09:13:53 BST 2020

Hi Ticker,

I think the patch looks good, I hoped for some samples where a correctly mapped barrier on a correctly mapped way shows problems with the existing rules ,e.g. "failure to route by car through a gate".

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Mittwoch, 15. April 2020 10:07
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] POI barrier/access restriction

Hi Gerd

I agree that OSM mappers don't always put the correct access rights on
barriers, but often they do, and if wrong it can be corrected. I'm not
sure what you mean by "hard to say what defaults should be used"?

I consider that this patch corrects flaws as I listed in the interpreta
tion of OSM data relating to barriers and handles some more common
barrier types.

A couple of the fixes relate to transport modes I don't use (goods/psv)
but the error and fix is textually obvious.

Others relate to combinations like [barrier=gate, vehicle=no], because
vehicle is not expanded to bicycle, motorcar, etc.

A common problems I had was failure to route by car through a gate.

Another problem is [barrier={"bollard" etc}, access={anything but "no"
or "private"], that would fail to impose a restriction on car, or,
indeed, any motor_vehicle

Ticker

On Tue, 2020-04-14 at 13:07 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> it is difficult to find good rules for barriers Many people don't map
> the access rights and thus it is hard to say what defaults should be
> used.
> At least that was the case when I changed the rules in 2013 ;)
>
> In what situations do you see improvements with your patch?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Montag, 13. April 2020 15:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] POI barrier/access restriction
>
> Hi Gerd
>
> The only common bit is filling in the mode hierarchy. It could be
> moved
> into an include and shared, but it is only 15 lines.
>
> Ticker
>
> On Mon, 2020-04-13 at 11:31 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > did not check the details yet but the patch seems to duplicate a
> > lot
> > of stuff coded in inc/access. Is that needed?
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Montag, 13. April 2020 13:21
> > An: mkgmap development
> > Betreff: [mkgmap-dev] POI barrier/access restriction
> >
> > Hi Gerd and others interested in routing issues
> >
> > default style "points" has code that, when option --link-pois-to
> > -ways
> > is in effect, sets highway access and speed restrictions that
> > mkgmap
> > then imposes on the highway that the point is on.
> >
> > These rules had various errors:
> > - didn't expand the access mode hierarchy, see
> >   https://wiki.openstreetmap.org/wiki/Key:access
> > - tested the wrong tag for mkgmap:bus and mkgmap:delivery
> > - if the "access" tag was set, apply this to all modes before
> >   processing allowances and restrictions imposed by the
> >   barrier; but these actions would have no effect because the
> >   the specified mode tags are now all set
> > - assumed that a gate stops motor_vehicle access
> > - didn't handle other common forms of gate
> > - allowed bicycle through kissing_gate and stile
> >
> > This patch fixes these problems and also adds a speed restriction
> > for
> > all barriers.
> >
> > The general principle is that barrier rules add specific "no"
> > restrictions that the barrier prevents, but must not add "yes".
> > The "access" tag is a default for all modes not implicitly or
> > explicit
> > handled; there could be, say, osm tags [barrier=stile,
> > access=destination] and this should not imply there is unrestricted
> > foot access.
> >
> > Ticker
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list