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

[Martin Koppenhoefer]

sent from a phone

> On 5. Mar 2019, at 23:30, Tobias Knerr  wrote:
> 
> Of course, connecting the sidewalk to the highway with a relation would
> likely offer a solution to that issue, too.


there’s a proposal for a relation type=area which lets you add sidewalks, 
kerbs, guard rails and other barriers (all should be more or less parallel) 
together with highways into an  area relation (defines implicitly an area 
between the ways)

Cheers, Martin 




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

> 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  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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Tobias Knerr]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[althio]

Tobias Knerr:

> Can we please first define a solution (e.g. a relation) for connecting
> such separately mapped components of a road to the highway?
>
> Painting lines next to each other fails to express the important
> information that this kerb/sidewalk/cycleway is part of that highway
> over there. Such missing information may be easily guessed by a human
> viewer, but it's currently not available in a machine-readable form.
>

If they are next to each other, you have already some of the information
because we use a geographic database with coordinates of the "painted
lines" (and not a pure relational database).
I would say that 99%+ of cases could be treated automatically once data is
loaded in a geographic tool like a pgsql-PostGIS database.
Advanced PostGIS users, please correct me if I am wrong.

Some points are also made in
https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

> The "relations" [...] are meant to model a close (and usually local)
relation between objects, [...] as in: These fifteen parts together make up
so-and-so road. [...] Our database is a spatial database; this means that
it has intrinsic knowledge about the location of objects. [...] A good
example for a valid and useful grouping is the "route
" relation, where
multiple ways are connected to form a cycle route or a walking route or
something else; a way may be part of any number of routes so this cannot be
solved by tagging the way with "route
=xxx".

Other than that, you already have relation tools existing if you absolutely
need them, you could either pick or extend
https://wiki.openstreetmap.org/wiki/Relation:street or
https://wiki.openstreetmap.org/wiki/Relation:associatedStreet
Although it feels like that are needed for edge cases of addresses only.
I do not think we need relations at the moment to assign a pavement, a
kerb/curb, a lamppost unambiguously to a street. These objects are related
to the nearest highway or the nearest crossing between several highways
(use buffers accordingly in the pre-treatment).

-- althio
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Clifford Snow]

For anyone interested in listening to Lou Huang's talk, I found it on
Youtube. It starts at about 42:00 and ends at 48:00

[1] https://www.youtube.com/watch?v=xOGsy9BFJ5Y

On Mon, Mar 4, 2019 at 4:02 PM Nick Bolten  wrote:

> > Can we please first define a solution (e.g. a relation) for connecting
> such separately mapped components of a road to the highway?
>
> I agree, this is a very important issue and it happens for a lot of
> different situations - a lot of different features that can and are mapped
> separately would benefit from a street <-> separate feature mapping. This
> is the incentive behind mapping streets, auto lanes, bus lanes, bicycle
> lanes, sidewalks, verges, etc. on the street: the relationship query is
> unnecessary, the information is shared in the way.
>
> Stable IDs would help with this problem, but I haven't seen much traction
> behind adding core features to data types. 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?
> Example members (with no particular naming/role conventions in mind):
>
> - The street way(s).
> - Any separate bicycle way(s).
> - Left sidewalk way(s)
> - Right sidewalk way(s)
> - Left curb(s)
> - Right curb(s)
>
> Other info that *might* benefit from either this or a similar relation:
> - Building(s) / addresses (as France does)
> - Greenways (trees / tree lines / verges)
> - Traffic islands (a common use case for barrier=kerb ways
> - Some street signs (some should probably be in a different relation
> involving more than one way)
>
> This is certainly a lot of members, and not all are necessary, but I think
> there's value in traversing between these data in, as you mention, a
> machine-readable way.
>
> > This fundamental limitation really needs to be addressed before we
> consider splitting roads into even more parallel ways.
>
> 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.
>
> Best,
>
> Nick
>
> On Mon, Mar 4, 2019 at 12:05 PM Tobias Knerr  wrote:
>
>> On 03.03.19 20:12, Nick Bolten wrote:
>> > I wanted to get a discussion started to see what people think of
>> > mapping curbs as ways.
>>
>> Can we please first define a solution (e.g. a relation) for connecting
>> such separately mapped components of a road to the highway?
>>
>> Painting lines next to each other fails to express the important
>> information that this kerb/sidewalk/cycleway is part of that highway
>> over there. Such missing information may be easily guessed by a human
>> viewer, but it's currently not available in a machine-readable form.
>>
>> This fundamental limitation really needs to be addressed before we
>> consider splitting roads into even more parallel ways.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

> Can we please first define a solution (e.g. a relation) for connecting
such separately mapped components of a road to the highway?

I agree, this is a very important issue and it happens for a lot of
different situations - a lot of different features that can and are mapped
separately would benefit from a street <-> separate feature mapping. This
is the incentive behind mapping streets, auto lanes, bus lanes, bicycle
lanes, sidewalks, verges, etc. on the street: the relationship query is
unnecessary, the information is shared in the way.

Stable IDs would help with this problem, but I haven't seen much traction
behind adding core features to data types. 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?
Example members (with no particular naming/role conventions in mind):

- The street way(s).
- Any separate bicycle way(s).
- Left sidewalk way(s)
- Right sidewalk way(s)
- Left curb(s)
- Right curb(s)

Other info that *might* benefit from either this or a similar relation:
- Building(s) / addresses (as France does)
- Greenways (trees / tree lines / verges)
- Traffic islands (a common use case for barrier=kerb ways
- Some street signs (some should probably be in a different relation
involving more than one way)

This is certainly a lot of members, and not all are necessary, but I think
there's value in traversing between these data in, as you mention, a
machine-readable way.

> This fundamental limitation really needs to be addressed before we
consider splitting roads into even more parallel ways.

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.

Best,

Nick

On Mon, Mar 4, 2019 at 12:05 PM Tobias Knerr  wrote:

> On 03.03.19 20:12, Nick Bolten wrote:
> > I wanted to get a discussion started to see what people think of
> > mapping curbs as ways.
>
> Can we please first define a solution (e.g. a relation) for connecting
> such separately mapped components of a road to the highway?
>
> Painting lines next to each other fails to express the important
> information that this kerb/sidewalk/cycleway is part of that highway
> over there. Such missing information may be easily guessed by a human
> viewer, but it's currently not available in a machine-readable form.
>
> This fundamental limitation really needs to be addressed before we
> consider splitting roads into even more parallel ways.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Clifford Snow]

I recall seeing a lightning talk at the 2016 State of the Map US in Seattle
about mapping curb lines. Lou Huang gave a talk "Representing streets in
OSM with Curblines" [1] which proposed mapping streets from curb to curb as
polygons if I recall correctly. (Unfortunately I couldn't find a video of
his talk.)  His proposal overcomes some of the problems of mapping curb
lines as a separate way. But the level of detail required to map as a
polygon seems to be a real barrier to acceptance.

When I originally mapped sidewalks and footways in my small town, I added
the sidewalk=left/right/both/no tag to the street. Having just gone back to
actually map each sidewalk, having the information was helpful. But keeping
two sets of basically identical sets of information doesn't make sense. If
we add in a third linestring for the curb line, do we end up with three
sets of similar info?

Adding curb info to streets to me doesn't make much sense because streets
are longer than the curb. Adding curb info to sidewalks won't help vehicle
traffic  where it's nice to know if there is a curb.

The only logical option is to map curbs as independent ways even if it
means we might have three sets of similar information. To develop a
proposal on how to map sidewalks, curbs, and streets should be done before
we jump in to import the data. Much like Nick and UW did with the proposal
to map sidewalks as independent ways.

I know cities collect curb information. Even my small town does. The data
is there and if it's properly licensed, it could be useful in OSM.

[1] https://2016.stateofthemap.us/project-lead/

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

I'm also a fan of the dedicated line, my primary interest being pedestrian
accessibility + QA-ability of such data.

I keep thinking, "hey, I'll go map a curb line!" and run into a related
issue: I can definitely map barrier=kerb and kerb=raised when one of those
exists along a path - could be near a sidewalk, could be a traffic island,
etc. But would it be an oxymoron to map barrier=kerb and kerb=flush (or
kerb=lowered)? I don't think I would call that a barrier. However, it is
definitely what happens to the curb along most city blocks - transitions
from raised to lowered to flush to rolled. I would find it much more useful
to know the curb state along a continuing line (set of ways) than to see a
bunch of disconnected kerb=raised lines or a kerb=raised line with kerb=*
nodes indicating a change (particularly since direction is ambiguous for a
node).

All of this is to say, what would you think of a way that only had
kerb=lowered? Should there be a barrier=kerb tag there? Or *=kerb?

Best,

Nick

On Mon, Mar 4, 2019 at 8:44 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 4. Mar 2019, at 17:28, Nick Bolten  wrote:
> >
> > 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?
>
>
> I would prefer a dedicated way for the kerb, and would not tag it on the
> road highway. Also using a node at the intersection of the kerb with the
> crossing footway/cycleway (at crossings) seems safe.
> Eventually it could be considered adding kerb information on a sidewalk
> way (as the lesser evil).
> On a road way the resulting fragmentation would be undesirable and the
> kerb information belongs more to the sidewalk than to the road way (IMHO).
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Tobias Knerr]

On 03.03.19 20:12, Nick Bolten wrote:
> I wanted to get a discussion started to see what people think of
> mapping curbs as ways.

Can we please first define a solution (e.g. a relation) for connecting
such separately mapped components of a road to the highway?

Painting lines next to each other fails to express the important
information that this kerb/sidewalk/cycleway is part of that highway
over there. Such missing information may be easily guessed by a human
viewer, but it's currently not available in a machine-readable form.

This fundamental limitation really needs to be addressed before we
consider splitting roads into even more parallel ways.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 4. Mar 2019, at 17:28, Nick Bolten  wrote:
> 
> 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?


I would prefer a dedicated way for the kerb, and would not tag it on the road 
highway. Also using a node at the intersection of the kerb with the crossing 
footway/cycleway (at crossings) seems safe. 
Eventually it could be considered adding kerb information on a sidewalk way (as 
the lesser evil). 
On a road way the resulting fragmentation would be undesirable and the kerb 
information belongs more to the sidewalk than to the road way (IMHO).

Cheers, Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

More detail means more information and barrier=kerb on ways has existed for
about a decade. I'm interested in hearing pros and cons of different
strategies, if anyone is interested.

On Mon, Mar 4, 2019 at 6:32 AM yo paseopor  wrote:

> 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
> enough
> -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
> https://wiki.openstreetmap.org/wiki/Key:kerb
> https://taginfo.openstreetmap.org/search?q=kerb#keys
>
> 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
> yopaseopor
>
> On Sun, Mar 3, 2019 at 8:13 PM 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?
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [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 <61sundow...@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@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[yo paseopor]

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
enough
-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
https://wiki.openstreetmap.org/wiki/Key:kerb
https://taginfo.openstreetmap.org/search?q=kerb#keys

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
yopaseopor

On Sun, Mar 3, 2019 at 8:13 PM 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?
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Warin]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Nick Bolten]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging