[Tagging] Mapping curb (kerb) lines as the home of curb, parking, etc information

[Nick Bolten]

Putting aside the preexistence of barrier=kerb + kerb=* on lines, do you
mean we should put kerb=* on a sidewalk line, a road line, or both? Keep in
mind that every time the kerb type changes, this would imply splitting the
way, so city street ways would be split another 2-8 times.

And what about parking information (e.g. hours, duration, type) that is
currently recommended as going on street ways? Should we split streets in
cities into 30 pieces?


On Sun, Mar 3, 2019, 3:06 PM Warin <61sundowner at gmail.com> wrote:

> On 04/03/19 06:12, Nick Bolten wrote:
> > A recent post on the Mapillary blog
> > (
> https://blog.mapillary.com/update/2019/02/12/potential-for-openstreetmap-to-seize-the-curb.html)
>
> > reminded me of my long-running wish to have more curb lines mapped, so
> > I wanted to get a discussion started to see what people think of
> > mapping curbs as ways.
> >
> > The short version is this: if we put kerb=* on a line and call it its
> > own feature, what's the best tagging schema to use and what kind of
> > additional information is appropriate? Personally, I'd like to use
> > (and recommend) the existing kerb=* tags around blocks and potentially
> > add parking information.
> >
> > Potential mapping and data use cases:
> >
> > - Public parking data: curbs are already marked with parking /
> > stopping information, and when motor vehicles stop at a curb they are
> > meant to follow the local regulations regarding access. Curbs seem
> > like a natural place to store this information: you can split the way
> > whenever the parking situation differs or where there are dedicated
> > parking slots. It is attractive to associate streets with parking
> > information, but if one were to split street ways whenever parking
> > information changed, every city block would become an
> > incomprehensible, split-up mess.
> >
> > - Streets as areas: there are a few schemas out there about mapping
> > streets and related features as areas, primarily for rendering
> > purposes. Mapping the curb is fully compatible with, and part of,
> > these proposals, and could provide a means of building up to fully
> > mapping contiguous areas.
> >
> > - Pedestrian crossings. I would be very excited to map out kerb=* ways
> > around every block I see, because it makes QA (and even safe,
> > semi-automated edits) for pedestrian accessibility so easy. All a
> > validator has to do is check that a highway=footway crosses a kerb=*
> > way and lacks its own kerb=* node. This is similar to the validators
> > already used in JOSM and iD that check for things like a footway or
> > street intersecting a building, reminding users to use covered=* or
> > tunnel=*.
> >
> > - Pedestrian islands. These are often just an assembly of raised curbs
> > intended to protect pedestrians that are doing a multi-part crossing
> > of a street or streets.
> >
> > - Opportunity to merge with + simplify micromapped stairs: what are
> > stairs but a series of carefully-raised "curbs"? I've seen various
> > proposals regarding how one might map large, beautiful, public
> > stairways. This is a whole can of worms, but the information in
> > describing a physical curb is essentially the same as describing any
> > 'stuff on the right is higher than stuff on the left' interface.
> >
> > Thoughts?
>
> Err ... no.
> Curbs and guttering are road edges. Detail them as part of the road/foot
> path.
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190304/ab99aecb/attachment.html>