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

Nick Bolten nbolten at gmail.com
Tue Mar 5 22:58:47 UTC 2019


> Unlike associatedStreet, which contains all street ways sharing the same
name and can thus contain networks of essentially unbounded complexity,
these relations should probably only span the stretch between two
junctions, though.

Agreed. This was something I had in mind but forgot to say out loud. This
might also help with naming, as it is very similar to the idea of a "block
face". Drawing from that name as inspiration, a potential "blockFace"
relation could be either "left" or "right" and only have to deal with one
set of amenities at a time (on the left or right side of the street). This
would cut down on the amount of features one would have to reference in a
single relation.

Re: kerb lines: you're right about potential duplication of data, but
similar to the sidewalks situation, I'm firmly in the camp that this data
doesn't get mapped with much specificity without its own intuitive home for
detail. The coverage for barrier=kerb / kerb=* on roads is pretty scanty
and definitely doesn't describe the actual curb interfaces for even a
single small town. For example, kerb:right is used 300 times according to
TagInfo, whereas I just looked at mapping kerbs around one block and found
at least 25 kerb changes on kerb:right alone. This tells me that the kerb
tag, when applied to roads, has not been mapped very specifically. tl;dr: I
could beat that tag count in about 30 minutes *and* create a bunch of great
data for pedestrian modeling + parking if I felt confident in the tagging
schema.

Best,

Nick

On Tue, Mar 5, 2019 at 2:32 PM Tobias Knerr <osm at tobias-knerr.de> wrote:

> On 05.03.19 01:01, Nick Bolten wrote:
> > What would you think
> > of a new 'associatedStreet'-style relation that would organize the
> > various features that should be associated between streets and the
> > surrounding environment?
>
> That approach could work, yes – and it's one of the few practical
> options I can think of at the moment. (The other would be drawing an
> area:highway polygon around all the individual ways.)
>
> Unlike associatedStreet, which contains all street ways sharing the same
> name and can thus contain networks of essentially unbounded complexity,
> these relations should probably only span the stretch between two
> junctions, though.
>
> While I would want to cobble together a proof of concept implementation
> to be sure that I'm not overlooking anything, such a relation would
> probably to solve the issue from a data consumer point of view. Of
> course, it would have to actually be used by mappers to be helpful.
>
> > Just to clarify, the road can keep all of its same data as is currently
> > mapped. This would be an additional piece of information that tends to
> > go unmapped.
>
> In theory, the two approaches could peacefully coexist as long as tags
> for kerbs, parking:lane etc. on the street ways themselves (and
> highway=crossing nodes) remained available after drawing the separate
> ways – at the cost of duplication and therefore additional maintenance.
>
> There are some hurdles, though. Even mapping just sidewalks as a
> separate way tends to break stuff. For example, people understandably
> connect incoming footways only to the sidewalk way, not to the street
> way. So an application that filters out these separate ways, hoping to
> instead rely on tags on the street way, will find itself with missing
> connections to the pedestrian network.
>
> Of course, connecting the sidewalk to the highway with a relation would
> likely offer a solution to that issue, too.
>
> Tobias
>
> _______________________________________________
> 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/20190305/257b4e42/attachment.html>


More information about the Tagging mailing list