Re: [Tagging] Kerbs

[Shu Higashi]

I think we can at least add an image tag as a raw data for someone
such as wheelchair users or mapillary that may estimate the height
automatically in the future :)
lowered:
https://www.openstreetmap.org/node/4294717996
raised:
https://www.openstreetmap.org/node/4293918233

Shu Higashi

2018-01-08 18:00 GMT+09:00, Selfish Seahorse :
>> Maybe there's a good middle ground: a kerb height ranking, in lieu of
>> taking out a ruler and/or guessing a true kerb:height value.
>> kerb:height=low/medium/high, with corresponding ranges in cm (0-3, 3-10,
>> 10+).
>
> That's actually very similar to mountable/semi-mountable/non-mountable
> or wheelchair=yes/limited/no and would lead to the same problems you
> described further above. If we want to prevent putting wheelchair
> users in categories, I think it's better to give the actual heights.
>
>
> On 7 January 2018 at 21:38, Nick Bolten  wrote:
>>> Even if only three out of four wheelchair users were satisfied with
>> `mountable`, `semi-mountable` and `non-mountable` this would be a step
>> forward, in my opinion.
>>
>> I would wager that the fraction of wheelchair users covered would be a
>> minority - there's a lot of diversity that tends to get lumped into just
>> 'wheelchair accessible' and it's really not one-size-fits-all in any way.
>> In
>> order for two wheelchair users to have the same requirements and
>> preferences, they'll need to sync up on all of these things: short-burst
>> athleticism, endurance, average speed, age-related compounding factors,
>> manual vs. electric chair, wheel traction, wheel width, wheel radius,
>> chair
>> width, side-to-side stability, comfort level with using streets and
>> driveways, etc. Now think of any two random users: how likely are they to
>> match on all of those categorizations?
>>
>> I'm going on a bit too long, but you get the idea. Most of those needs can
>> be directly handled with just a few neutral, measurable, on-the-ground
>> tags:
>> kerb shape + height + width, footpath width + incline, surface tags, etc.
>> And all users benefit from those tags - bicyclists will also appreciate
>> surface and kerb tags, as will parents using strollers or people hauling
>> luggage. And most of these tags are useful in an additive way: one is
>> good,
>> two is better, etc, etc, and can be queried to figure out where
>> information
>> is missing and turn it into quests like maproulette.
>>
>> Let's consider just one common situation: manual wheelchairs tend to have
>> larger radius wheels than electric wheelchairs do, which, just due to
>> physics, impacts how they handle displacements like curbs. The
>> higher-radius
>> wheels have an easier time of it due to the angle of approach + extra
>> leverage (though the user can become tired doing curb after curb), and
>> there
>> are a lot of curbs right on the cusp of being doable by electric
>> wheelchair
>> users. Even just for this one common situation, we have to ignore
>> wheelchair=yes, and probably a mountable/semi-mountable/unmountable tag,
>> because what's actually dictating access is variation in the curb shape +
>> height.
>>
>> Maybe there's a good middle ground: a kerb height ranking, in lieu of
>> taking
>> out a ruler and/or guessing a true kerb:height value.
>> kerb:height=low/medium/high, with corresponding ranges in cm (0-3, 3-10,
>> 10+).
>>
>>> Besides, I didn't think of these values to be a replacement for
>>> kerb:shape, but an addition.
>>
>> Ah, well I initially misunderstood. But I still think it's better to
>> completely drop the idea of overarching 'wheelchair access' tags for
>> pedestrian tagging, due to the concerns above. Wheelchair users need
>> unambiguous information and we already have ambiguous info in
>> wheelchair=yes
>> and access=*.
>>
>> Fundamentally, everyone is trying to answer the question, 'can a
>> wheelchair
>> user traverse this line/point/area?', and while it's tempting to say 'yes'
>> or 'no', the true answer representing the majority of users is, 'it
>> depends', which is why we need tags that reflected neutral, measurable
>> on-the-ground conditions.
>>
>>> However, if we want to make the current scheme more usable, it is
>>> necessary to also specify the angle of inclination for sloped kerbs (and
>>> maybe kerb ramps too). Compare the following two kerbs, which have the
>>> same
>>> shape, but a different level of accessibility (...)
>>
>> You're completely right. And while we have the incline=* tag, there's no
>> standard for where or how to apply it to a curb interface. Do we tag the
>> node itself, and what does it mean of kerb=raised has an incline value? If
>> tagging a node with incline=*, how do we figure out the direction of the
>> incline, and how much does it matter? Does a kerb=* node imply that a
>> footway should be split, and the two ways it connects to should (ideally)
>> have separate incline=* tags? I prefer that last option, personally. Plus,
>> it would benefit 

Re: [Tagging] Kerbs

[Selfish Seahorse]

> Maybe there's a good middle ground: a kerb height ranking, in lieu of taking 
> out a ruler and/or guessing a true kerb:height value. 
> kerb:height=low/medium/high, with corresponding ranges in cm (0-3, 3-10, 10+).

That's actually very similar to mountable/semi-mountable/non-mountable
or wheelchair=yes/limited/no and would lead to the same problems you
described further above. If we want to prevent putting wheelchair
users in categories, I think it's better to give the actual heights.


On 7 January 2018 at 21:38, Nick Bolten  wrote:
>> Even if only three out of four wheelchair users were satisfied with
> `mountable`, `semi-mountable` and `non-mountable` this would be a step
> forward, in my opinion.
>
> I would wager that the fraction of wheelchair users covered would be a
> minority - there's a lot of diversity that tends to get lumped into just
> 'wheelchair accessible' and it's really not one-size-fits-all in any way. In
> order for two wheelchair users to have the same requirements and
> preferences, they'll need to sync up on all of these things: short-burst
> athleticism, endurance, average speed, age-related compounding factors,
> manual vs. electric chair, wheel traction, wheel width, wheel radius, chair
> width, side-to-side stability, comfort level with using streets and
> driveways, etc. Now think of any two random users: how likely are they to
> match on all of those categorizations?
>
> I'm going on a bit too long, but you get the idea. Most of those needs can
> be directly handled with just a few neutral, measurable, on-the-ground tags:
> kerb shape + height + width, footpath width + incline, surface tags, etc.
> And all users benefit from those tags - bicyclists will also appreciate
> surface and kerb tags, as will parents using strollers or people hauling
> luggage. And most of these tags are useful in an additive way: one is good,
> two is better, etc, etc, and can be queried to figure out where information
> is missing and turn it into quests like maproulette.
>
> Let's consider just one common situation: manual wheelchairs tend to have
> larger radius wheels than electric wheelchairs do, which, just due to
> physics, impacts how they handle displacements like curbs. The higher-radius
> wheels have an easier time of it due to the angle of approach + extra
> leverage (though the user can become tired doing curb after curb), and there
> are a lot of curbs right on the cusp of being doable by electric wheelchair
> users. Even just for this one common situation, we have to ignore
> wheelchair=yes, and probably a mountable/semi-mountable/unmountable tag,
> because what's actually dictating access is variation in the curb shape +
> height.
>
> Maybe there's a good middle ground: a kerb height ranking, in lieu of taking
> out a ruler and/or guessing a true kerb:height value.
> kerb:height=low/medium/high, with corresponding ranges in cm (0-3, 3-10,
> 10+).
>
>> Besides, I didn't think of these values to be a replacement for
>> kerb:shape, but an addition.
>
> Ah, well I initially misunderstood. But I still think it's better to
> completely drop the idea of overarching 'wheelchair access' tags for
> pedestrian tagging, due to the concerns above. Wheelchair users need
> unambiguous information and we already have ambiguous info in wheelchair=yes
> and access=*.
>
> Fundamentally, everyone is trying to answer the question, 'can a wheelchair
> user traverse this line/point/area?', and while it's tempting to say 'yes'
> or 'no', the true answer representing the majority of users is, 'it
> depends', which is why we need tags that reflected neutral, measurable
> on-the-ground conditions.
>
>> However, if we want to make the current scheme more usable, it is
>> necessary to also specify the angle of inclination for sloped kerbs (and
>> maybe kerb ramps too). Compare the following two kerbs, which have the same
>> shape, but a different level of accessibility (...)
>
> You're completely right. And while we have the incline=* tag, there's no
> standard for where or how to apply it to a curb interface. Do we tag the
> node itself, and what does it mean of kerb=raised has an incline value? If
> tagging a node with incline=*, how do we figure out the direction of the
> incline, and how much does it matter? Does a kerb=* node imply that a
> footway should be split, and the two ways it connects to should (ideally)
> have separate incline=* tags? I prefer that last option, personally. Plus,
> it would benefit from adding a separate curb ramp tag for a way: all of them
> should, ideally, have an incline=* value.
>
> Best,
>
> Nick
>
> On Sun, Jan 7, 2018 at 11:13 AM Selfish Seahorse 
> wrote:
>>
>> Not, it's not ideal, you are right. It's just an idea to create some
>> order, because the current kerb scheme isn't ideal either. Even if
>> only three out of four wheelchair users were satisfied with
>> `mountable`, `semi-mountable` and `non-mountable` this would 

Re: [Tagging] Kerbs

[Nick Bolten]

> Even if only three out of four wheelchair users were satisfied with
`mountable`, `semi-mountable` and `non-mountable` this would be a step
forward, in my opinion.

I would wager that the fraction of wheelchair users covered would be a
minority - there's a lot of diversity that tends to get lumped into just
'wheelchair accessible' and it's really not one-size-fits-all in any way.
In order for two wheelchair users to have the same requirements and
preferences, they'll need to sync up on all of these things: short-burst
athleticism, endurance, average speed, age-related compounding factors,
manual vs. electric chair, wheel traction, wheel width, wheel radius, chair
width, side-to-side stability, comfort level with using streets and
driveways, etc. Now think of any two random users: how likely are they to
match on all of those categorizations?

I'm going on a bit too long, but you get the idea. Most of those needs can
be directly handled with just a few neutral, measurable, on-the-ground
tags: kerb shape + height + width, footpath width + incline, surface tags,
etc. And all users benefit from those tags - bicyclists will also
appreciate surface and kerb tags, as will parents using strollers or people
hauling luggage. And most of these tags are useful in an additive way: one
is good, two is better, etc, etc, and can be queried to figure out where
information is missing and turn it into quests like maproulette.

Let's consider just one common situation: manual wheelchairs tend to have
larger radius wheels than electric wheelchairs do, which, just due to
physics, impacts how they handle displacements like curbs. The
higher-radius wheels have an easier time of it due to the angle of approach
+ extra leverage (though the user can become tired doing curb after curb),
and there are a lot of curbs right on the cusp of being doable by electric
wheelchair users. Even just for this one common situation, we have to
ignore wheelchair=yes, and probably a mountable/semi-mountable/unmountable
tag, because what's actually dictating access is variation in the curb
shape + height.

Maybe there's a good middle ground: a kerb height ranking, in lieu of
taking out a ruler and/or guessing a true kerb:height value.
kerb:height=low/medium/high, with corresponding ranges in cm (0-3, 3-10,
10+).

> Besides, I didn't think of these values to be a replacement for
kerb:shape, but an addition.

Ah, well I initially misunderstood. But I still think it's better to
completely drop the idea of overarching 'wheelchair access' tags for
pedestrian tagging, due to the concerns above. Wheelchair users need
unambiguous information and we already have ambiguous info in
wheelchair=yes and access=*.

Fundamentally, everyone is trying to answer the question, 'can a wheelchair
user traverse this line/point/area?', and while it's tempting to say 'yes'
or 'no', the true answer representing the majority of users is, 'it
depends', which is why we need tags that reflected neutral, measurable
on-the-ground conditions.

> However, if we want to make the current scheme more usable, it is
necessary to also specify the angle of inclination for sloped kerbs (and
maybe kerb ramps too). Compare the following two kerbs, which have the same
shape, but a different level of accessibility (...)

You're completely right. And while we have the incline=* tag, there's no
standard for where or how to apply it to a curb interface. Do we tag the
node itself, and what does it mean of kerb=raised has an incline value? If
tagging a node with incline=*, how do we figure out the direction of the
incline, and how much does it matter? Does a kerb=* node imply that a
footway should be split, and the two ways it connects to should (ideally)
have separate incline=* tags? I prefer that last option, personally. Plus,
it would benefit from adding a separate curb ramp tag for a way: all of
them should, ideally, have an incline=* value.

Best,

Nick

On Sun, Jan 7, 2018 at 11:13 AM Selfish Seahorse 
wrote:

> Not, it's not ideal, you are right. It's just an idea to create some
> order, because the current kerb scheme isn't ideal either. Even if
> only three out of four wheelchair users were satisfied with
> `mountable`, `semi-mountable` and `non-mountable` this would be a step
> forward, in my opinion. Besides, I didn't think of these values to be
> a replacement for kerb:shape, but an addition.
>
> However, if we want to make the current scheme more usable, it is
> necessary to also specify the angle of inclination for sloped kerbs
> (and maybe kerb ramps too). Compare the following two kerbs, which
> have the same shape, but a different level of accessibility:
>
> 
> 
>
> Regards
>
> On 7 January 2018 at 19:15, Nick Bolten  wrote:
> >> * `mountable`: mountable for wheelchairs and vehicles (...)
> >
> > While this may seem easier to 

Re: [Tagging] Kerbs

[Matej Lieskovský]

I'd say the first picture is a flush kerb followed by a ramp.

On 7 January 2018 at 20:12, Selfish Seahorse 
wrote:

> Not, it's not ideal, you are right. It's just an idea to create some
> order, because the current kerb scheme isn't ideal either. Even if
> only three out of four wheelchair users were satisfied with
> `mountable`, `semi-mountable` and `non-mountable` this would be a step
> forward, in my opinion. Besides, I didn't think of these values to be
> a replacement for kerb:shape, but an addition.
>
> However, if we want to make the current scheme more usable, it is
> necessary to also specify the angle of inclination for sloped kerbs
> (and maybe kerb ramps too). Compare the following two kerbs, which
> have the same shape, but a different level of accessibility:
>
> 
> 
>
> Regards
>
> On 7 January 2018 at 19:15, Nick Bolten  wrote:
> >> * `mountable`: mountable for wheelchairs and vehicles (...)
> >
> > While this may seem easier to tag on a first pass, it's not ideal, as
> it's
> > making a broad-brush executive decision about accessibility on behalf of
> > others. I'm also not sure how it's different from wheelchair=yes/no
> combined
> > with access=* tags. Describing neutral on-the-ground conditions is
> better,
> > both for accessibility and general use by all mappers/data consumers.
> > Examples:
> >
> > - Athletic manual wheelchair users can mount moderate-height raised
> curbs.
> > - Adventurous manual wheelchair users may want to use driveways as well,
> > where it may not be intuitive to always map accessibility, but does make
> > sense for a curb interface.
> > - Most electric wheelchairs can't handle moderate-height raised curbs.
> > - Souped-up electric wheelchairs can handle even fairly high curbs.
> > - People with impaired stability may strongly prefer moderate-height
> curbs,
> > but don't care about the shape.
> > - A white cane user may want to know whether to expect a certain curb
> shape
> > for navigational purposes.
> > - What about `semi-mountable version 2`, curbs mountable by souped-up
> > electric wheelchairs but not other vehicles?
> >
> > These users can all be accommodated by curb shape and height tags, and
> most
> > can be mostly-accommodated just with curb shape. This is also one of the
> > reasons very few wheelchair maps exist: if you state 'here's the places
> all
> > wheelchairs can go' you'll get a lot of very different complaints, both
> > about not having enough possible routes ('I don't care about curb ramps,
> > just tell me where big displacements and driveways are') and also too
> many
> > ('I can't handle 8 cm displacements, and this rolled curb kept me from
> > making my trip').
> >
> > Best,
> >
> > Nick
> >
> > On Sun, Jan 7, 2018 at 9:15 AM Selfish Seahorse <
> selfishseaho...@gmail.com>
> > wrote:
> >>
> >> On 29 December 2017 at 01:41, Warin <61sundow...@gmail.com> wrote:
> >> > kerb:shape=* would be better as it suggests what is to be tagged.
> >>
> >> Thus, `kerb=*` values could be replaced with:
> >>
> >> * `mountable`: mountable for wheelchairs and vehicles
> >> * `semi-mountable`: not mountable for wheelchairs but mountable for
> >> vehicles
> >> * `non-mountable`: neither mountable for wheelchairs nor vehicles
> >>
> >> ___
> >> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Kerbs

[Selfish Seahorse]

Not, it's not ideal, you are right. It's just an idea to create some
order, because the current kerb scheme isn't ideal either. Even if
only three out of four wheelchair users were satisfied with
`mountable`, `semi-mountable` and `non-mountable` this would be a step
forward, in my opinion. Besides, I didn't think of these values to be
a replacement for kerb:shape, but an addition.

However, if we want to make the current scheme more usable, it is
necessary to also specify the angle of inclination for sloped kerbs
(and maybe kerb ramps too). Compare the following two kerbs, which
have the same shape, but a different level of accessibility:




Regards

On 7 January 2018 at 19:15, Nick Bolten  wrote:
>> * `mountable`: mountable for wheelchairs and vehicles (...)
>
> While this may seem easier to tag on a first pass, it's not ideal, as it's
> making a broad-brush executive decision about accessibility on behalf of
> others. I'm also not sure how it's different from wheelchair=yes/no combined
> with access=* tags. Describing neutral on-the-ground conditions is better,
> both for accessibility and general use by all mappers/data consumers.
> Examples:
>
> - Athletic manual wheelchair users can mount moderate-height raised curbs.
> - Adventurous manual wheelchair users may want to use driveways as well,
> where it may not be intuitive to always map accessibility, but does make
> sense for a curb interface.
> - Most electric wheelchairs can't handle moderate-height raised curbs.
> - Souped-up electric wheelchairs can handle even fairly high curbs.
> - People with impaired stability may strongly prefer moderate-height curbs,
> but don't care about the shape.
> - A white cane user may want to know whether to expect a certain curb shape
> for navigational purposes.
> - What about `semi-mountable version 2`, curbs mountable by souped-up
> electric wheelchairs but not other vehicles?
>
> These users can all be accommodated by curb shape and height tags, and most
> can be mostly-accommodated just with curb shape. This is also one of the
> reasons very few wheelchair maps exist: if you state 'here's the places all
> wheelchairs can go' you'll get a lot of very different complaints, both
> about not having enough possible routes ('I don't care about curb ramps,
> just tell me where big displacements and driveways are') and also too many
> ('I can't handle 8 cm displacements, and this rolled curb kept me from
> making my trip').
>
> Best,
>
> Nick
>
> On Sun, Jan 7, 2018 at 9:15 AM Selfish Seahorse 
> wrote:
>>
>> On 29 December 2017 at 01:41, Warin <61sundow...@gmail.com> wrote:
>> > kerb:shape=* would be better as it suggests what is to be tagged.
>>
>> Thus, `kerb=*` values could be replaced with:
>>
>> * `mountable`: mountable for wheelchairs and vehicles
>> * `semi-mountable`: not mountable for wheelchairs but mountable for
>> vehicles
>> * `non-mountable`: neither mountable for wheelchairs nor vehicles
>>
>> ___
>> 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] Kerbs

[Nick Bolten]

I like the idea of explicitly indicating the presence of a ramp, as they're
specialized infrastructure that isn't exactly the same as just having a
sloped curb interface. Though I would argue that it makes sense for them to
be a linear feature separate from the `kerb` key, as they have non-trivial
length.

On Sun, Dec 31, 2017 at 10:43 AM Selfish Seahorse 
wrote:

> On 29 December 2017 at 00:32, Nick Bolten  wrote:
> > That's a really great example of how it may make sense to separate out
> the
> > idea of a 'curb ramp' from the curb interface. I might have to steal it!
>
> Maybe `kerb=ramp`, leaving `kerb=lowered` for kerbs of low height?
>
> @Warin: Thanks for the links.
>
> Wishing everyone a happy new year!
>
> ___
> 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] Kerbs

[Nick Bolten]

If the road and sidewalk have no curb interface, then `kerb=flush` seems
appropriate.

On Sun, Dec 31, 2017 at 1:15 PM Matej Lieskovský 
wrote:

> How does this work with roads raised to the level of the sidewalk?
>
> On 31 Dec 2017 19:43, "Selfish Seahorse" 
> wrote:
>
> On 29 December 2017 at 00:32, Nick Bolten  wrote:
> > That's a really great example of how it may make sense to separate out
> the
> > idea of a 'curb ramp' from the curb interface. I might have to steal it!
>
> Maybe `kerb=ramp`, leaving `kerb=lowered` for kerbs of low height?
>
> @Warin: Thanks for the links.
>
> Wishing everyone a happy new year!
>
> ___
> 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] Kerbs

[Nick Bolten]

> * `mountable`: mountable for wheelchairs and vehicles (...)

While this may seem easier to tag on a first pass, it's not ideal, as it's
making a broad-brush executive decision about accessibility on behalf of
others. I'm also not sure how it's different from wheelchair=yes/no
combined with access=* tags. Describing neutral on-the-ground conditions is
better, both for accessibility and general use by all mappers/data
consumers. Examples:

- Athletic manual wheelchair users can mount moderate-height raised curbs.
- Adventurous manual wheelchair users may want to use driveways as well,
where it may not be intuitive to always map accessibility, but does make
sense for a curb interface.
- Most electric wheelchairs can't handle moderate-height raised curbs.
- Souped-up electric wheelchairs can handle even fairly high curbs.
- People with impaired stability may strongly prefer moderate-height curbs,
but don't care about the shape.
- A white cane user may want to know whether to expect a certain curb shape
for navigational purposes.
- What about `semi-mountable version 2`, curbs mountable by souped-up
electric wheelchairs but not other vehicles?

These users can all be accommodated by curb shape and height tags, and most
can be mostly-accommodated just with curb shape. This is also one of the
reasons very few wheelchair maps exist: if you state 'here's the places all
wheelchairs can go' you'll get a lot of very different complaints, both
about not having enough possible routes ('I don't care about curb ramps,
just tell me where big displacements and driveways are') and also too many
('I can't handle 8 cm displacements, and this rolled curb kept me from
making my trip').

Best,

Nick

On Sun, Jan 7, 2018 at 9:15 AM Selfish Seahorse 
wrote:

> On 29 December 2017 at 01:41, Warin <61sundow...@gmail.com> wrote:
> > kerb:shape=* would be better as it suggests what is to be tagged.
>
> Thus, `kerb=*` values could be replaced with:
>
> * `mountable`: mountable for wheelchairs and vehicles
> * `semi-mountable`: not mountable for wheelchairs but mountable for
> vehicles
> * `non-mountable`: neither mountable for wheelchairs nor vehicles
>
> ___
> 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] Kerbs

[Selfish Seahorse]

On 29 December 2017 at 01:41, Warin <61sundow...@gmail.com> wrote:
> kerb:shape=* would be better as it suggests what is to be tagged.

Thus, `kerb=*` values could be replaced with:

* `mountable`: mountable for wheelchairs and vehicles
* `semi-mountable`: not mountable for wheelchairs but mountable for vehicles
* `non-mountable`: neither mountable for wheelchairs nor vehicles

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

Re: [Tagging] Kerbs

[Nick Bolten]

If I understand you right, that would be a case for `kerb=flush`, where the
interface between the road and footways has no significant vertical
displacement.

On Sun, Dec 31, 2017, 1:15 PM Matej Lieskovský 
wrote:

> How does this work with roads raised to the level of the sidewalk?
>
> On 31 Dec 2017 19:43, "Selfish Seahorse" 
> wrote:
>
> On 29 December 2017 at 00:32, Nick Bolten  wrote:
> > That's a really great example of how it may make sense to separate out
> the
> > idea of a 'curb ramp' from the curb interface. I might have to steal it!
>
> Maybe `kerb=ramp`, leaving `kerb=lowered` for kerbs of low height?
>
> @Warin: Thanks for the links.
>
> Wishing everyone a happy new year!
>
> ___
> 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] Kerbs

[Matej Lieskovský]

How does this work with roads raised to the level of the sidewalk?

On 31 Dec 2017 19:43, "Selfish Seahorse"  wrote:

On 29 December 2017 at 00:32, Nick Bolten  wrote:
> That's a really great example of how it may make sense to separate out the
> idea of a 'curb ramp' from the curb interface. I might have to steal it!

Maybe `kerb=ramp`, leaving `kerb=lowered` for kerbs of low height?

@Warin: Thanks for the links.

Wishing everyone a happy new year!

___
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] Kerbs

[Selfish Seahorse]

On 29 December 2017 at 00:32, Nick Bolten  wrote:
> That's a really great example of how it may make sense to separate out the
> idea of a 'curb ramp' from the curb interface. I might have to steal it!

Maybe `kerb=ramp`, leaving `kerb=lowered` for kerbs of low height?

@Warin: Thanks for the links.

Wishing everyone a happy new year!

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

Re: [Tagging] Kerbs

[marc marc]

a 2mm kerb (the last picture) is imho a lowered.
I don't see what value added would bring the fact that the angle of 
these 2mm is square. for me it is necessary to remember the purpose of 
the tag: accessibility. if all profiles pass this kerb without a 
problem, it's lowered.

the problem is for other profiles (the accessibility of a curved kerb is 
very difficult to evaluate).

It is it's disappointing to see that in 2017, we are still new crosing 
that does not have kerb=lowered.

Le 29. 12. 17 à 01:41, Warin a écrit :
> There are many different kerb shapes
> http://www.playford.sa.gov.au/webdata/resources/files/SD%20100%20TYPICAL%20RESIDENTIAL%20KERB%20PROFILES.pdf
> https://en.wikipedia.org/wiki/Curb#Types_of_curb
> 
> 
> kerb:shape=* would be better as it suggests what is to be tagged*. *
> kerb=* is open to any use, kerb=raised might be a shape to one person, 
> height to another. *
> 
> *On 29-Dec-17 10:32 AM, Nick Bolten wrote:
>> That's a really great example of how it may make sense to separate out 
>> the idea of a 'curb ramp' from the curb interface. I might have to 
>> steal it!
>>
>> On Thu, Dec 28, 2017 at 3:12 PM Selfish Seahorse 
>> > wrote:
>>
>> On 28 December 2017 at 23:50, Nick Bolten > > wrote:
>> > With that said, I agree that there are opportunities for
>> improving `kerb`
>> > tags. Here are some ideas to toss around:
>> >
>> > - `kerb=square` would seem to be as descriptive as
>> `kerb=raised`, but more
>> > clear.
>> >
>> > - `barrier=kerb` is sometimes used in combination with
>> `kerb=raised`, which
>> > seems redundant to me.
>> >
>> > - `kerb=raised|rolled|flush` describes a curb interface with
>> very little
>> > horizontal component (a few centimeters at most), while
>> `kerb=lowered` is
>> > used for describing curb/kerb ramps, which can be 1-2 meters
>> long and have
>> > surface properties.
>>
>> Note that there are also square lowered kerbs:
>>
>> 
>>
>> ___
>> 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
> 

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

Re: [Tagging] Kerbs

[Warin]

There are many different kerb shapes
http://www.playford.sa.gov.au/webdata/resources/files/SD%20100%20TYPICAL%20RESIDENTIAL%20KERB%20PROFILES.pdf
https://en.wikipedia.org/wiki/Curb#Types_of_curb


kerb:shape=* would be better as it suggests what is to be tagged*. *
kerb=* is open to any use, kerb=raised might be a shape to one person, 
height to another. *


*On 29-Dec-17 10:32 AM, Nick Bolten wrote:
That's a really great example of how it may make sense to separate out 
the idea of a 'curb ramp' from the curb interface. I might have to 
steal it!


On Thu, Dec 28, 2017 at 3:12 PM Selfish Seahorse 
> wrote:


On 28 December 2017 at 23:50, Nick Bolten > wrote:
> With that said, I agree that there are opportunities for
improving `kerb`
> tags. Here are some ideas to toss around:
>
> - `kerb=square` would seem to be as descriptive as
`kerb=raised`, but more
> clear.
>
> - `barrier=kerb` is sometimes used in combination with
`kerb=raised`, which
> seems redundant to me.
>
> - `kerb=raised|rolled|flush` describes a curb interface with
very little
> horizontal component (a few centimeters at most), while
`kerb=lowered` is
> used for describing curb/kerb ramps, which can be 1-2 meters
long and have
> surface properties.

Note that there are also square lowered kerbs:



___
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] Kerbs

[Selfish Seahorse]

On 28 December 2017 at 23:50, Nick Bolten  wrote:
> With that said, I agree that there are opportunities for improving `kerb`
> tags. Here are some ideas to toss around:
>
> - `kerb=square` would seem to be as descriptive as `kerb=raised`, but more
> clear.
>
> - `barrier=kerb` is sometimes used in combination with `kerb=raised`, which
> seems redundant to me.
>
> - `kerb=raised|rolled|flush` describes a curb interface with very little
> horizontal component (a few centimeters at most), while `kerb=lowered` is
> used for describing curb/kerb ramps, which can be 1-2 meters long and have
> surface properties.

Note that there are also square lowered kerbs:



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

Re: [Tagging] Kerbs

[Nick Bolten]

> The question is: does it make sense to introduce another `kerb` value in
order to differentiate between standard high kerbs and very high kerbs at
public transport stops?

If I understand the question right, it really comes down to what you
consider to be a curb. Some transit stops have raised platforms, and there
is no expectation that an individual would ever traverse that displacement.
But if it could be reasonably expected that someone would walk across that
displacement, I think `kerb=raised` combined with `kerb:height` would
satisfactorily describe the situation, because I've always interpreted
`raised` to mean `square corner`. That seems to be how all the examples
are, and the iconography used in various presets all show a square corner.
Also, a `rolled` curb also has a significant change in height, so it would
be odd if `kerb=raised` just meant that the curb implied a displacement.

Regarding Matej's suggestion: I think that `kerb=normal` has the
disadvantage of being ambiguous, or at least geographically varying. A
normal curb in many American suburbs would be `rolled`, or rounded, while a
normal curb in many dense areas of cities would be flush (with bollards
protecting pedestrians from traffic).

With that said, I agree that there are opportunities for improving `kerb`
tags. Here are some ideas to toss around:

- `kerb=square` would seem to be as descriptive as `kerb=raised`, but more
clear.

- `barrier=kerb` is sometimes used in combination with `kerb=raised`, which
seems redundant to me.

- `kerb=raised|rolled|flush` describes a curb interface with very little
horizontal component (a few centimeters at most), while `kerb=lowered` is
used for describing curb/kerb ramps, which can be 1-2 meters long and have
surface properties.

That last point brings up another issue, which is the meaning of `kerb` in
different tagging situations: as an attribute of a node on a street (such
as in conjunction with `highway=crossing`), as an attribute of a node on a
footway (such as in conjunction with `footway=sidewalk`), and as an
attribute of the way itself (the curb along a sidewalk). `kerb` means
different something slightly different in each of those cases,
respectively: the crossing *has* curbs on each side, of certain forms,
there *is* a curb interface along the footway, and the footway *has* a curb
of some form on one side.

If you have the time, I'd also like to invite anyone to provide
`kerb`-focused feedback on the Talk page of the (draft) pedestrian network
schema page:
http://wiki.openstreetmap.org/wiki/Proposed_features/sidewalk_schema. Its
purpose is to help organize a set of tags to best describe the pedestrian
network, and the concerns that have already been raised would be very
useful in the "Proposals to be worked into separate RFCs" section.

On Thu, Dec 28, 2017 at 1:54 PM Selfish Seahorse 
wrote:

> I agree that `kerb:height` is more useful than `kerb`. However, `kerb`
> seems to be a good starting point when mapping many kerbs and you
> can't measure them all yet, as it gives a rough information whether
> most wheelchair users can cross the street there or not.
>
> The question is: does it make sense to introduce another `kerb` value
> in order to differentiate between standard high kerbs and very high
> kerbs at public transport stops? Or should common high kerbs be tagged
> `kerb=raised` as well? The explanations on the wiki are contradictory
> in that regard (e.g. 'older kerbs' vs 'raised above the norm').
>
> ___
> 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] Kerbs

[Selfish Seahorse]

I agree that `kerb:height` is more useful than `kerb`. However, `kerb`
seems to be a good starting point when mapping many kerbs and you
can't measure them all yet, as it gives a rough information whether
most wheelchair users can cross the street there or not.

The question is: does it make sense to introduce another `kerb` value
in order to differentiate between standard high kerbs and very high
kerbs at public transport stops? Or should common high kerbs be tagged
`kerb=raised` as well? The explanations on the wiki are contradictory
in that regard (e.g. 'older kerbs' vs 'raised above the norm').

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

Re: [Tagging] Kerbs

[Matej Lieskovský]

I'd use "normal" or "regular", leaving "raised" for "above the norm". Both
values are quite rare, but I guess that is because most will simply not tag
it. Or (as the wiki discussion suggests) use kerb:height in cm.

Looks like that wiki page could use updating...

Matej Lieskovský

On 28 December 2017 at 22:25, Nick Bolten  wrote:

> This kind of info is actually very relevant to all kinds of different
> pedestrians. There are manual wheelchair users with serious athleticism who
> are happy with moderate curbs, but can't do tall ones (due to physics -
> they'd tip before getting over), people with limited mobility who use
> walkers/canes and can't do large displacements, people using very fancy
> (and expensive) electric wheelchairs that can handle relatively high curbs,
> etc. If you add kerb:height info, it could be very useful to someone,
> eventually!
>
> On Thu, Dec 28, 2017 at 1:07 PM Selfish Seahorse <
> selfishseaho...@gmail.com> wrote:
>
>> On 28 December 2017 at 20:29, Martin Koppenhoefer
>>  wrote:
>>
>> > I think it makes a difference to many wheelchair users or cyclists or
>> automobilists or most other vehicles and pedestrians whether the kerb is 12
>> or 30 centimeters (assuming that meters was a typo, right?).
>> >
>> > Regarding the tag raised kerb seems ok for both types of kerbs though.
>>
>> Yes, centimetres. Sorry, this was a mistake.
>>
>> And I was thinking of pedestrian crossings and that it doesn't make a
>> difference there (though, actually, I've never seen a pedestrian
>> crossing with a kerb of 30 cm height).
>>
>> ___
>> 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] Kerbs

[Selfish Seahorse]

On 28 December 2017 at 20:29, Martin Koppenhoefer
 wrote:

> I think it makes a difference to many wheelchair users or cyclists or 
> automobilists or most other vehicles and pedestrians whether the kerb is 12 
> or 30 centimeters (assuming that meters was a typo, right?).
>
> Regarding the tag raised kerb seems ok for both types of kerbs though.

Yes, centimetres. Sorry, this was a mistake.

And I was thinking of pedestrian crossings and that it doesn't make a
difference there (though, actually, I've never seen a pedestrian
crossing with a kerb of 30 cm height).

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

Re: [Tagging] Kerbs

[Graeme Fitzpatrick]

On 29 December 2017 at 05:05, Selfish Seahorse 
wrote:

it doesn't make a difference for wheelchair users if the kerb is 12 or
> 30 metres high.
>

I think it would make a difference to everybody if the kerb is 30 metres
high! :-)

Thanks

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

Re: [Tagging] Kerbs

[Nick Bolten]

kerb=raised is a bit subjective, but you can always add kerb:height when in
doubt. Another way to look at it is as the shape at the interface: flush =
straight on, lowered = approaching linearly at an angle, rolled = rounded,
raised = square edge.

On Thu, Dec 28, 2017, 12:15 PM Selfish Seahorse 
wrote:

> Hi
>
> There are conflicting informations on the wiki[^1] whether common high
> kerbs (example[^2]) can be tagged `kerb=raised` or if this tag is
> reserved for very high kerbs at public transport stops.
>
> [^1]: 
> [^2]: 
>
> I think it makes sense to tag common high kerbs `kerb=raised` too, as
> it doesn't make a difference for wheelchair users if the kerb is 12 or
> 30 metres high.
>
> What is your opinion?
>
> There are also some other open issues with this wiki page. I've made
> some suggestions for solving them here[^3]. Thanks for your comments.
>
> [^3]: <
> https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#Open_issues_and_suggestions_how_to_solve_them
> >
>
> Regards
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging