Re: [Tagging] sleepable:physical=yes/no | Re: Benches and hostile architecture

[Martin Koppenhoefer]

sent from a phone

> On 15. Sep 2020, at 19:27, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Is it maybe more universal to map
> strictly objective parameters instead?
> 
> It seems for me that mapping
> length, armrest in the middle and width
> would be both far more objective and
> potentially useful also for other purposes


while these are useful, we could also start adding subtypes for specific 
models. It is very common that a few models are used throughout the city or 
village, with individual types often being the exception. 
Also uploading pictures of individual benches to wikimedia (or elsewhere) and 
linking them from OpenStreetMap is very helpful.

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

Re: [Tagging] "width" on streets: Time for a recommendation

[Martin Koppenhoefer]

sent from a phone

> On 15. Sep 2020, at 21:39, Mark Wagner  wrote:
> 
> Which one is "the" width of the road?


not only from year to year but also with the seasons...

Cheers Martin 

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

Re: [Tagging] "width" on streets: Time for a recommendation

[Mark Wagner]

On Tue, 15 Sep 2020 10:09:17 +0200
Martin Koppenhoefer  wrote:

> on unpaved
> roads, measure the extent of the maximum width that vehicles actually
> use, on a medium to narrow part of the highway (i.e. do not add the
> smallest width to a long stretch of highway if it only occurs for a
> short part, rather split the highway in this case of tag the narrow
> exceptions explicitly while using a medium value for longer
> stretches).

In my experience, unpaved roads don't have a well-defined width.
Typically, you've got the following options, roughly from widest to
narrowest:

1) Obstacle-free width: the distance that's clear of fences, trees,
ditches, brush, boulders, and other obstacles.  Not well-defined for
roads in farm country, which may be obstacle-free all the way
to the next road, and misleading in ranch country, where the nearest
obstacle is usually the fence marking the edge of the right-of-way.

2) Vegetation-free width: the distance clear of any vegetation.
Usually the easiest to spot and measure, but may include things such as
spoil from road maintenance which are unsuitable for driving on.

3) Maintained width: the distance that's kept smooth, level, and firm
through regular maintenance.  This is probably the closest to the
"curb-to-curb" or "edge-to-edge" width of a paved road.  This has the
problem that it can change from year to year as graders take different
routes eg. around curves, and is difficult to tell apart from the
vegetation-free width. It also has the problem that many roads are not
maintained except for removal of fallen trees and other obstacles.

4) Driven path: the portion of the road regularly used by drivers.
Unpaved roads frequently develop a well-defined set of ruts that are
easy to measure.  However, this width varies rapidly with road
conditions.

Which one is "the" width of the road?
-- 
Mark

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

Re: [Tagging] sleepable:physical=yes/no | Re: Benches and hostile architecture

[Mateusz Konieczny via Tagging]

Is it maybe more universal to map
strictly objective parameters instead?

It seems for me that mapping
length, armrest in the middle and width
would be both far more objective and
potentially useful also for other purposes

10 Sep 2020, 20:10 by r...@technomancy.org:

> I asked about this ~1½ years ago too (  
> https://lists.openstreetmap.org/pipermail/tagging/2019-February/thread.html#43244
>  ). In the end I thought `sleepable:physical=yes/no` is an accurate tag, and 
> fits the OSM philosophy well (* 
> https://lists.openstreetmap.org/pipermail/tagging/2019-February/043270.html ) 
> (though I've only added <10 tags for that 
> https://taginfo.openstreetmap.org/keys/sleepable%3Aphysical )
>
>
> I created a simple pic4review misson, which you can duplicate if you want. ( 
> https://pic4review.pavie.info/#/mission/1313 ). You could also suggest a 
> StreetComplete quest
>
> There was some reddit threads:
> • 
> https://www.reddit.com/r/openstreetmap/comments/avbmsb/is_there_a_preferred_way_of_mapping_possible/
> • 
> https://www.reddit.com/r/openstreetmap/comments/8rs7zf/how_to_map_antihomeless_bench/
>
> On Sun, 23 Aug 2020, at 6:28 PM, Vucod via Tagging wrote:
>
>> Hello,
>>
>> 1) I wish to tag benches that were designed to avoid that someone lie 
>> on it. There has been some related discussions in the past 
>> (https://www.reddit.com/r/openstreetmap/comments/avbmsb/is_there_a_preferred_way_of_mapping_possible/
>>  and 
>> https://www.reddit.com/r/openstreetmap/comments/8rs7zf/how_to_map_antihomeless_bench/
>>  )
>> but with no conclusion. It is possible that it has retained people to 
>> map that kind of objects. Today, there is nearly no such information in 
>> OSM. Maybe it is because it is not its place? Nobody expressed that 
>> clearly. 
>>
>> So, I started to use the tag *lying_hindrance=yes* on some benches. In 
>> case of doubts, this can be verified when doing surveys, by lying on 
>> the bench. This could also be determined most of the time by looking at 
>> a few things. The length of the bench, the presence of a slope, the 
>> presence of separation between the seats of the bench, and by checking 
>> if it is a standing bench. Note that length was refused as an official 
>> key for bench and that the key for the separation doesn't exist 
>> (armrest does not specifically concern the inner part of the bench). 
>> The tag could be extended by specifying the hindrance type: armrest, 
>> standing_bench, short_length, slope, ...
>>
>> What do you think about this tag? Do you have alternative ideas?
>>
>> 2) Also, I wish to map something else related to hostile architecture 
>> . I wish to map 
>> devices that are placed near the entrance of shops to prevent people to 
>> sit there (https://www.youtube.com/watch?v=TGdHfvsCP7A, 
>> https://twitter.com/ArticuleE/status/1222197697333145603, 
>> https://twitter.com/ArticuleE/status/1215931276944924672). I was going 
>> to add a combination of tags on the building where the shop is located:
>>
>> sitting_hindrance=yes 
>> sitting_hindrance:location=street_side
>>
>> It can also be verified quite easily. A general tag like 
>> hostile_architecture={sitting_hindrance|lying_hindrance} would also be 
>> quite useful for mappers to rapidly understand the purpose of these 
>> tags.
>>
>> What do you think about it?
>>
>> Thanks for your time
>>
>> Vucod
>> ___
>> 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] "width" on streets: Time for a recommendation

[Jan Michel]

On 15.09.20 10:52, Martin Koppenhoefer wrote:

Looking at width tag variants:
https://taginfo.openstreetmap.org/search?q=width

here are those with more than 1K uses


Please be careful with such a list. E.g. width:shoulder stems
from a user in Finland and from something that looks like an old
(un-)organized edit in Nepal that used several other uncommon tags as 
well. The documented tag is 'shoulder:width'



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

Re: [Tagging] "width" on streets: Time for a recommendation

[Jan Michel]

I expect the "width" of a way to be the actual width of the object it 
represents.

This obviously changes depending on the mapping style applied, e.g.

- if it's a highway with sidewalk and cycleway tags, it's the width of 
all of it


- if it's just a road with footways mapped as separate ways next to it, 
then it's the width of just the road.


If you want to tag how much space there is for some kind of vehicle 
moving in some direction, there are the specific width tags like 
width:lanes, sidewalk:width, cycleway:width, shoulder:width, verge:width

and so on.

Jan


On 14.09.20 20:34, Supaplex wrote:

1) Width of the actual carriageway, without parking lanes and sidewalks
2) Width between curbs / edges of the road without sidewalks, but with 
parked cars when they are on street

3) Width including sidewalks / roadside paths



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

Re: [Tagging] "width" on streets: Time for a recommendation

[Mateusz Konieczny via Tagging]

Sep 14, 2020, 20:34 by supap...@riseup.net:

>
> Hey all,
>
>
> again and again there are discussions about which parts of a  street 
> (sidewalks and cycle paths, parking lanes, carriageway)  should be 
> considered when determining the width of a street. There  does not seem 
> to be a consensus and therefore information on  street widths is 
> difficult to interpret or is not even mapped. The  following variants are 
> common/are discussed:
>
>
>
> 1) Width of the actual carriageway, without parking lanes and  sidewalks
>  2) Width between curbs / edges of the road without sidewalks, but  with 
> parked cars when they are on street
>  3) Width including sidewalks / roadside paths
>
>
>
>
> I tend to option 2):
>  - The width can be clearly defined and measured
>  - The width of the actual carriageway can be determined by using  
> "parking:lane" scheme correctly (or alternatively/supplementarily  by 
> specifying the width of parking lanes). "width:carriageway" (or  
> "width:lanes", if there are marked lanes) also could be used to  map this 
> width directly.
>  - The width of roadside paths can optionally be specified with  
> "sidewalk:width" etc.
>
>
>
> Wouldn't it be time to document a recommendation in the Wiki to  reduce 
> further ambiguities? Which variant is the most  recommendable? Anyway, 
> the width of a street is a significant  value to evaluate its suitability 
> or safety for certain modes of  transport or to determine the speed that 
> can be expected there.
>
>
>
> Thanks for your comments,
>  Alex
>
>
>
I would also expect (2)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "width" on streets: Time for a recommendation

[Volker Schmidt]

On Tue, 15 Sep 2020 at 10:34, Tobias Zwick  wrote:

> I plan to soon implement a "What is the width of this road" quest in
> StreetComplete where the user can measure the width of the road using his
> or her smartphone (similar to the app Measure from Google [1]). The app
> will need to instruct the user very clearly what should be measured.
>

With the satellite photos that OSM can legally use, we usually have a
resolution problem. In most cases it will be tricky to get to a precision
better than one metre, which in my view is not enough.
Alternative: use est_width=  or width= plus source.width=estimated
Another problem are the contrast enhancement filters that most satellite
images are subject to. They oftenwiden the roads to some extent or create
an artificial limiting line, depending on the filtering algorithm.
In case there are Mapillary Mapillary photos you can, in many countries,
count the stripes of zebra crossings (in Italy they are 0.5m wide) to
measure the width of urban roads.



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "width" on streets: Time for a recommendation

[Martin Koppenhoefer]

Am Di., 15. Sept. 2020 um 10:34 Uhr schrieb Tobias Zwick :

> I was under the impression that the wiki already defined it like 2).
>


If it were like this it would be fortunate, because we already have nearly
1,9 million highways tagged with "width", and if we could reasonably expect
that these are following the definition, we would maybe not have to resort
to yet another key like width:carriageway

Looking at width tag variants:
https://taginfo.openstreetmap.org/search?q=width

here are those with more than 1K uses (ignoring yh:WIDTH which is leading
even before the main tag, but clearly not a recommendable format for tags,
as it isn't self explaining and has uppercase letters, and ignoring those
that do not seem to refer to roads):

cycling_width
cycleway:est_width
shoulder:width
width:lanes
width:street
sidewalk:width
sidewalk:right:width
width:lanes:forward and backward
cycleway:width
crossing:width
cycleway:left:width
sidewalk:left:width
width:shoulder
sidewalk:both:width
width:average

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

Re: [Tagging] "width" on streets: Time for a recommendation

[Tobias Zwick]

Absolutely high time! Thank you for bringing this up.

I was under the impression that the wiki already defined it like 2). 1) 
is not practical because parking lanes can be informal or can change 
quickly, 3) is also not practical because sidewalks + additional 
greenery/space between road and sidewalk can vary a lot.


I plan to soon implement a "What is the width of this road" quest in 
StreetComplete where the user can measure the width of the road using 
his or her smartphone (similar to the app Measure from Google [1]). The 
app will need to instruct the user very clearly what should be measured.


The instruction "curb to curb" is pretty clear. However, there is one 
more problem to solve, what about if there are no curbs? For example, 
track-like roads that just consist of either one strip of asphalt 
surface or are not paved at all? I see two possible definitions:


1. Width of the paved surface (if paved)
2. Usable width of the road

1 has the advantage that there is no room for interpretation, but falls 
short of what to do with unpaved roads. 2 leaves some room for 
interpretation but also covers cases where the usable width of the road 
is much different from the width of the paved part of the road.


Tobias

[1] https://play.google.com/store/apps/details?id=com.google.tango.measure

On 14.09.20 20:34, Supaplex wrote:


Hey all,

again and again there are discussions about which parts of a street 
(sidewalks and cycle paths, parking lanes, carriageway) should be 
considered when determining the width of a street. There does not seem 
to be a consensus and therefore information on street widths is 
difficult to interpret or is not even mapped. The following variants 
are common/are discussed:


1) Width of the actual carriageway, without parking lanes and sidewalks
2) Width between curbs / edges of the road without sidewalks, but with 
parked cars when they are on street

3) Width including sidewalks / roadside paths

I tend to option 2):
- The width can be clearly defined and measured
- The width of the actual carriageway can be determined by using 
"parking:lane" scheme correctly (or alternatively/supplementarily by 
specifying the width of parking lanes). "width:carriageway" (or 
"width:lanes", if there are marked lanes) also could be used to map 
this width directly.
- The width of roadside paths can optionally be specified with 
"sidewalk:width" etc.


Wouldn't it be time to document a recommendation in the Wiki to reduce 
further ambiguities? Which variant is the most recommendable? Anyway, 
the width of a street is a significant value to evaluate its 
suitability or safety for certain modes of transport or to determine 
the speed that can be expected there.


Thanks for your comments,
Alex


___
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] "width" on streets: Time for a recommendation

[Martin Koppenhoefer]

Am Mo., 14. Sept. 2020 um 20:37 Uhr schrieb Supaplex :

> again and again there are discussions about which parts of a street
> (sidewalks and cycle paths, parking lanes, carriageway) should be
> considered when determining the width of a street. There does not seem to
> be a consensus and therefore information on street widths is difficult to
> interpret or is not even mapped.
>


indeed, mapping the width generally requires measuring the width, and it is
often not practical (unless you are willing to spend a lot of time or have
very good aerial imagery at hand).



> The following variants are common/are discussed:
>
> 1) Width of the actual carriageway, without parking lanes and sidewalks
> 2) Width between curbs / edges of the road without sidewalks, but with
> parked cars when they are on street
> 3) Width including sidewalks / roadside paths
>
> I tend to option 2):
> - The width can be clearly defined and measured
> - The width of the actual carriageway can be determined by using
> "parking:lane" scheme correctly (or alternatively/supplementarily by
> specifying the width of parking lanes). "width:carriageway" (or
> "width:lanes", if there are marked lanes) also could be used to map this
> width directly.
> - The width of roadside paths can optionally be specified with
> "sidewalk:width" etc.
>



I agree that 2 could be a reasonable definition for urban areas, what I can
see could be brought up against it:
the tags should generally apply to the mapped object. As we see a highway=*
to include the sidewalks, it would be somehow odd to not include them in
width. But I agree, through definition, we could define it to mean only the
road (including parking alongside), and we are already pursuing a similar
approach with regard to lanes (only car lanes, no bike lanes or sidewalks
counted).

when there aren't kerb stones, how would you suggest to proceed? (my
suggestion: measure from the middle of the wide lateral boundary lines if
there are, otherwise measure the paved width, on unpaved roads, measure the
extent of the maximum width that vehicles actually use, on a medium to
narrow part of the highway (i.e. do not add the smallest width to a long
stretch of highway if it only occurs for a short part, rather split the
highway in this case of tag the narrow exceptions explicitly while using a
medium value for longer stretches).

I would definitely not include widths of separated ways (e.g.
cycleway=track) in the highway width on the main way. For these, properties
like cycleway:width or footway:width could be added (or map the separately,
avoiding too many splits of the main highway)

Wouldn't it be time to document a recommendation in the Wiki to reduce
> further ambiguities?
>


yes

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

[Tagging] Addition of highway=emergency_bay and priority_road=yes to Map Features?

[Joseph Eisenberg]

Two tags were just added to the list of approved and de-facto highway
=* tags on Map features:
highway =emergency_bay
 and
priority_road =yes
.
Both have mainly been used in Germany and nearby areas of central Europe.

https://wiki.openstreetmap.org/wiki/Key:priority_road
https://wiki.openstreetmap.org/wiki/Tag:highway%3Demergency_bay

I question whether these tags are established enough to merit inclusion on
the Highway map features page and the main Map Features list. Thoughts?

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