[mkgmap-dev] POI barrier/access restriction

Wed Apr 15 10:15:59 BST 2020

Hi Ticker,

OK, thanks, committed with r4482. Seems the gate only exists to keep cattle inside an area? I think in Germany and Austria a cattle grid would be used.

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:53
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] POI barrier/access restriction

Hi Gerd

For gate/lift_gate/swing_gate the new rules don't make any access
assumptions, but any access/mode tags will be respected.

eg [barrier=gate, foot=yes, access=private] will set mkgmap:foot=yes
and all the others to "no"

[barrier=swing_gate] would just imposes the speed penalty.

Ticker

On Wed, 2020-04-15 at 08:39 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> what are your assumptions reg. default access for a barrier=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:35
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] POI barrier/access restriction
>
> Hi Gerd
>
> Here is one, [barrier=gate] on [highway=unclassified]
>
> https://www.openstreetmap.org/node/1394202186
>
> Ticker
>
> On Wed, 2020-04-15 at 08:13 +0000, Gerd Petermann wrote:
> > 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
> > _______________________________________________
> > 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