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

yo paseopor yopaseopor at gmail.com
Mon Mar 4 14:30:10 UTC 2019

It is the same story again and again.

-First was the node and ways. And some classification . It was not enough
-Second arrived relations. but when you want to specify more..it is not
-Then it was other tags like classification, lanes, sidewalks...  it is not
enough if you want to make all the details.
-Then arrived the area mapping to make it more realistic. But only for some
items as sidewalks.
Congrats , now we need the detail of a kerb drawed as an area.

I think best way at first is using the same tagging we have for kerb

Then...you know you will need more tags...cuz it is not enough ;)
PD: don't map for the render (instead it would be OSM official's one). All
real info is welcomed

Salut i mapes

On Sun, Mar 3, 2019 at 8:13 PM Nick Bolten <nbolten at gmail.com> 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?
> _______________________________________________
> 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/9df6a4a8/attachment.html>

More information about the Tagging mailing list