Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

2020-10-28 Thread Supaplex
Better use the key "description" instead of "name". Apart from that in
my opinion you can do it like this.

More problematic is the access road (apparently not mapped by you): On
some sections it is drawn twice over the footways/path and "name" is
used here as well. As I already mentioned in a mail from yesterday, it
would probably be better to assign an access value like "motor_vehicle =
emergency" to the footways/path instead?


Am 28.10.20 um 06:51 schrieb Nüssli Christian (SRZ):
> Hello Supaplex
>
> Thank you very much for your explanation for others. It's exactly what I 
> meant. It's areas especially designed for emergency vehicles, e.g a ladder 
> which will reach most of the areas from a bulding. I think parking would be 
> the wrong approach, because it's not really a parking, more a working are. I 
> like emergency=service_area or better emergency=rescue_area.
>
> I made the mentioned military area to the real situation with your taggings: 
> https://www.openstreetmap.org/way/860308598
> What do you think about?
>
> Kind regards
>
> Christian
>
> Freundliche Grüsse
> Christian Nüssli
> Applikationsverantwortlicher ELZ
>
> Stadt Zürich
> Schutz & Rettung
> Direktwahl +41 44 411 22 85
>
> Schutz & Rettung Zürich ist Top Employer 2020!
> Weitere Infos: 
> www.stadt-zuerich.ch/srz-top-employer<https://www.stadt-zuerich.ch/pd/de/index/schutz_u_rettung_zuerich/medien/medienmitteilungen_-berichte/2020/februar/srz_erneut_als_einzigeverwaltungmittopemployerlabelausgezeic.html>
> Von: Supaplex 
> Gesendet: Mittwoch, 28. Oktober 2020 00:40
> An: tagging@openstreetmap.org
> Betreff: Re: [Tagging] Tagging from fire_service_areas - landuse:emergency
>
>
> We (or Christian) are talking about areas that must be kept free, especially 
> near buildings, so that fire brigade vehicles can stand and work there in 
> case of an emergency. For example, it is not allowed to park there, no 
> objects may be placed there etc. In German-speaking countries it is very 
> common to find areas that are specially designated for this use (I don't know 
> what the situation is like in other countries). These areas can be e.g. paved 
> areas or just grass, sometimes with surface=grass_paver (these areas must be 
> able to carry vehicles weighing up to 16 tons). I think tagging of these 
> areas is very useful for use by rescue services, as Christian apparently 
> intends to do, or for micro mapping purposes.
>
> How about "emergency = rescue_area" (very rarely in use)? I agree that 
> landuse should not be used in this case, but we have "emergency" for this. 
> For fire fighters access ways there is already "highway = service" + "service 
> = emergency access" in use (see 
> https://wiki.openstreetmap.org/wiki/Tag:service%3Demergency_access).
>
> (Another question I ask myself in this context: How do you mark footways/path 
> that serve as fire fighter access - i.e. are designated, suitable and wide 
> enough for this purpose? I have already used "highway = footway" + 
> "motor_vehicle = emergency" in these cases.)
>
> Am 28.10.20 um 00:05 schrieb Robert Delmenico:
>
> I'm not sure what you're referring to but I'll put some options here to
>
> discuss:
>
>
>
> Fire districts: used for declaring total for bans in Australia
>
> https://www.cfa.vic.gov.au/warnings-restrictions/find-your-fire-district
>
>
>
>
>
> Neighbourhood safer places in Victoria - where you can go as a last resort
>
> in a bushfire situation
>
> https://www.cfa.vic.gov.au/plan-prepare/neighbourhood-safer-places
>
>
>
>
>
> There are also administrative fire service regions/districts in Victoria
>
> but there would be minimal value in mapping these.
>
> https://www.cfa.vic.gov.au/about/where-we-are
>
>
>
>
>
> There are training grounds used solely for training emergency service
>
> personnel
>
> https://www.cfa.vic.gov.au/about/victorian-emergency-management-training-centres
>
>
>
>
>
>
>
>  There is land which the fire stations sit on
>
> amenity=fire_station
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfire_station
>
>
>
>
>
> Then there is the fire stations
>
> building=fire_station
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dfire_station
>
>
>
> Kind regards,
>
>
>
> Rob
>
>
>
>
>
> On Wed, 28 Oct 2020, 9:20 am Graeme Fitzpatrick, 
> <mailto:graemefi...@gmail.com>
>
> wrote:
>
>
>
>
>
>
>
> Hi Christian
>
>
>
> On Tue, 27 Oct 2020 at 18:35, Nüssli Christian (SRZ) <
>
> christi

Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

2020-10-28 Thread Supaplex
"parking" should not be used for this, because in many cases these areas
have nothing in common with a parking lot. This meadow, for example, is
explicitly a rescue area, but definitely not a parking lot:
https://www.openstreetmap.org/way/503246160 (and I think, by the way,
that in case of an emergency it's not just about "parking", but also
setting up equipment, turning vehicles around etc.)

In my opinion the key "emergency" is perfect for such cases.

For the use at roads, however, there is "parking:lane: =
fire_lane" if a lane is designated like this.


Am 28.10.20 um 06:21 schrieb Mateusz Konieczny via Tagging:
>
>
> Oct 28, 2020, 03:22 by andrew.harv...@gmail.com:
>
>> On Wed, 28 Oct 2020 at 13:20, Jonathon Rossi <> j...@jonorossi.com> > wrote:
>>
>>> We've got emergency=landing_site for helicopters, maybe just 
>>> emergency=parking?
>>>
>> I like that, areas set aside for parking by emergency vehicles. 
>>
> amenity=parking access=no emergency=yes
> seems a better fit to me
>
>
> ___
> 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] Feature Proposal - RFC - parking=street_side

2020-10-27 Thread Supaplex
In this case you can simply use "parking:lane:right = parallel". Since
it is a simple parking lane, it has nothing to do with street_side as
suggested in the proposal.

(The question is rather how to tag the bike lane - a suggestion is for
example is
https://wiki.openstreetmap.org/wiki/Proposed_features/cycleway:protection)


Am 27.10.20 um 05:09 schrieb Phake Nick:
> See "Parking-Protected Bike Lanes | The City of Portland, Oregon":
> https://www.portlandoregon.gov/transportation/77882
>
> 在 2020年10月27日週二 01:45,Supaplex  寫道:
>
>> Do you have an example picture/mapillary or similar of such a street? You
>> call this case yourself "parking lane" and the way you describe it, it
>> sounds like a typical case for parking:lane:* =
>> parallel/diagonal/perpendicular, but not for
>> parking:lane:*/parking=street_side. "street_side" is intended for cases
>> where the parking spaces are structurally (especially structured by curbs)
>> located on one side of the carriageway. (That means, if - hypothetically -
>> no vehicles were parked there, you could still not drive there because curb
>> extensions or street furniture would block a continuous drive.)
>>
>> A cycleway located behind this parking area is no longer part of the
>> roadway and would therefore not be "lane" but "track". But maybe I
>> misinterpreted the case you meant?
>>
>>
>> Am 26.10.20 um 15:49 schrieb Paul Johnson:
>>
>> On Sat, Oct 24, 2020 at 6:40 AM Supaplex  
>>  wrote:
>>
>>
>> Hey all,
>>
>> I would like to invite you to discuss a proposal for "parking =
>> street_side" for areas suitable or designated for parking, which are
>> directly adjacent to the carriageway of a road and can be reached directly
>> from the roadway without having to use an access 
>> way:https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side
>>
>> The proposed tagging can be used on separate parking areas as well as with
>> the parking:lane-scheme. It aims not only to differentiate such
>> street-accompanying parking areas from others, especially
>> "parking=surface", but also addresses a contradiction in the current use of
>> the amenity=parking and parking:lane-scheme, which I would like to mention
>> briefly at this point: the use of "layby"/"lay_by".
>>
>> The value "layby" was originally intended for forms of resting places, as
>> they seem to be especially common in rural areas of Great Britain, Ireland
>> or the US: short-stop rest-areas along through-traffic roads intended for
>> breaks during a car-trip (see Wikipedia for a 
>> definition:https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with
>> "amenity=parking" this key is also used in this sense (and mostly in Great
>> Britain).
>>
>> Within the parking:lane-schema, however, the value "lay_by" (written with
>> an underscore) has gained acceptance. According to the Wiki, this value is
>> defined identically to the layby's mentioned above. Its actual use,
>> however, differs from this and includes mainly street-side parking, as we
>> address them in our proposal.
>>
>>
>> How does this work out when the parking lane is not the curb lane?  This
>> arrangement is increasingly common in North America, where the parking
>> isn't at the side of the road, one or more bicycle lanes are.
>>
>>
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://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] Tagging from fire_service_areas - landuse:emergency

2020-10-27 Thread Supaplex
We (or Christian) are talking about areas that must be kept free,
especially near buildings, so that fire brigade vehicles can stand and
work there in case of an emergency. For example, it is not allowed to
park there, no objects may be placed there etc. In German-speaking
countries it is very common to find areas that are specially designated
for this use (I don't know what the situation is like in other
countries). These areas can be e.g. paved areas or just grass, sometimes
with surface=grass_paver (these areas must be able to carry vehicles
weighing up to 16 tons). I think tagging of these areas is very useful
for use by rescue services, as Christian apparently intends to do, or
for micro mapping purposes.

How about *"emergency = rescue_area"* (very rarely in use)? I agree that
landuse should not be used in this case, but we have "emergency" for
this. For fire fighters access ways there is already "highway = service"
+ "service = emergency access" in use (see
https://wiki.openstreetmap.org/wiki/Tag:service%3Demergency_access).

(Another question I ask myself in this context: How do you mark
footways/path that serve as fire fighter access - i.e. are designated,
suitable and wide enough for this purpose? I have already used "highway
= footway" + "motor_vehicle = emergency" in these cases.)


Am 28.10.20 um 00:05 schrieb Robert Delmenico:
> I'm not sure what you're referring to but I'll put some options here to
> discuss:
>
> Fire districts: used for declaring total for bans in Australia
> https://www.cfa.vic.gov.au/warnings-restrictions/find-your-fire-district
>
>
> Neighbourhood safer places in Victoria - where you can go as a last resort
> in a bushfire situation
> https://www.cfa.vic.gov.au/plan-prepare/neighbourhood-safer-places
>
>
> There are also administrative fire service regions/districts in Victoria
> but there would be minimal value in mapping these.
> https://www.cfa.vic.gov.au/about/where-we-are
>
>
> There are training grounds used solely for training emergency service
> personnel
> https://www.cfa.vic.gov.au/about/victorian-emergency-management-training-centres
>
>
>
>  There is land which the fire stations sit on
> amenity=fire_station
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfire_station
>
>
> Then there is the fire stations
> building=fire_station
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dfire_station
>
> Kind regards,
>
> Rob
>
>
> On Wed, 28 Oct 2020, 9:20 am Graeme Fitzpatrick, 
> wrote:
>
>>
>> Hi Christian
>>
>> On Tue, 27 Oct 2020 at 18:35, Nüssli Christian (SRZ) <
>> christian.nues...@zuerich.ch> wrote:
>>
>>> I wanted to ask you if there's a correct mapping of fire service areas.
>>> That's areas in fire protection guidelines that will be reserved for
>>> emergency vehicles.
>>>
>> Sorry, but what do you mean by "fire service areas", & "reserved for
>> emergency vehicles"?
>>
>> Are you referring to fire stations & emergency lanes?
>>
>> I found quite a few that are tagged as landuse=military which is in my
>>> opinion – the incorrect way.
>>>
>> No, not even knowing for sure what we're talking about, but I can see that
>> would be wrong!
>>
>> Thanks
>>
>> Graeme
>>
>> ___
>> 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] Feature Proposal - RFC - parking=street_side

2020-10-26 Thread Supaplex
Do you have an example picture/mapillary or similar of such a street?
You call this case yourself "parking lane" and the way you describe it,
it sounds like a typical case for parking:lane:* =
parallel/diagonal/perpendicular, but not for
parking:lane:*/parking=street_side. "street_side" is intended for cases
where the parking spaces are structurally (especially structured by
curbs) located on one side of the carriageway. (That means, if -
hypothetically - no vehicles were parked there, you could still not
drive there because curb extensions or street furniture would block a
continuous drive.)

A cycleway located behind this parking area is no longer part of the
roadway and would therefore not be "lane" but "track". But maybe I
misinterpreted the case you meant?


Am 26.10.20 um 15:49 schrieb Paul Johnson:
> On Sat, Oct 24, 2020 at 6:40 AM Supaplex  wrote:
>
>> Hey all,
>>
>> I would like to invite you to discuss a proposal for "parking =
>> street_side" for areas suitable or designated for parking, which are
>> directly adjacent to the carriageway of a road and can be reached directly
>> from the roadway without having to use an access way:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side
>>
>> The proposed tagging can be used on separate parking areas as well as with
>> the parking:lane-scheme. It aims not only to differentiate such
>> street-accompanying parking areas from others, especially
>> "parking=surface", but also addresses a contradiction in the current use of
>> the amenity=parking and parking:lane-scheme, which I would like to mention
>> briefly at this point: the use of "layby"/"lay_by".
>>
>> The value "layby" was originally intended for forms of resting places, as
>> they seem to be especially common in rural areas of Great Britain, Ireland
>> or the US: short-stop rest-areas along through-traffic roads intended for
>> breaks during a car-trip (see Wikipedia for a definition:
>> https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with
>> "amenity=parking" this key is also used in this sense (and mostly in Great
>> Britain).
>>
>> Within the parking:lane-schema, however, the value "lay_by" (written with
>> an underscore) has gained acceptance. According to the Wiki, this value is
>> defined identically to the layby's mentioned above. Its actual use,
>> however, differs from this and includes mainly street-side parking, as we
>> address them in our proposal.
>>
> How does this work out when the parking lane is not the curb lane?  This
> arrangement is increasingly common in North America, where the parking
> isn't at the side of the road, one or more bicycle lanes are.
>
>
> ___
> 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] Feature Proposal - RFC - parking=street_side

2020-10-24 Thread Supaplex
Hey all,

I would like to invite you to discuss a proposal for "parking =
street_side" for areas suitable or designated for parking, which are
directly adjacent to the carriageway of a road and can be reached
directly from the roadway without having to use an access way:
https://wiki.openstreetmap.org/wiki/Proposed_features/parking%3Dstreet_side

The proposed tagging can be used on separate parking areas as well as
with the parking:lane-scheme. It aims not only to differentiate such
street-accompanying parking areas from others, especially
"parking=surface", but also addresses a contradiction in the current use
of the amenity=parking and parking:lane-scheme, which I would like to
mention briefly at this point: the use of "layby"/"lay_by".

The value "layby" was originally intended for forms of resting places,
as they seem to be especially common in rural areas of Great Britain,
Ireland or the US: short-stop rest-areas along through-traffic roads
intended for breaks during a car-trip (see Wikipedia for a definition:
https://en.wikipedia.org/wiki/Rest_area#Lay-bys). On areas with
"amenity=parking" this key is also used in this sense (and mostly in
Great Britain).

Within the parking:lane-schema, however, the value "lay_by" (written
with an underscore) has gained acceptance. According to the Wiki, this
value is defined identically to the layby's mentioned above. Its actual
use, however, differs from this and includes mainly street-side parking,
as we address them in our proposal.

With our proposal, we also want to resolve this contradiction. Above
all, however, we would like to create more clarity about different types
of parking in order to be able to distinguish between them.

looking forward to your opinions and discussions,
- Alex - (and Jeroen Hoek, another author of this proposal)

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


Re: [Tagging] How do you map traffic signals where right or left turns are allowed or not allowed on a red light?

2020-10-11 Thread Supaplex
Isn't it sufficient to use this red_turn-tagging at the traffic light
(instead of a turn relation), since it restricts to whom the traffic
light applies? General turning rules remain unaffected.

This tagging obviously comes from the German-speaking area (see also
TagInfo map), because there is the "green arrow" sign on some traffic
lights (originally invented in the GDR, later adopted in other countries
all over the world): It allows to turn right at red light. In China, the
same regulation applies as in the USA (turning at red light always
allowed unless other signing).

Alex

Am 11.10.20 um 18:11 schrieb Joseph Eisenberg:
> In North America (since we hate pedestrians) usually it is legal to turn
> right at a red light (we drive on the right side of the road, so a right
> turn only involves crossing into one lane).
>
> At some intersections where there are many pedestrians, there are signs
> that say "no turn on red", or sometimes "no turn on red except bicycles".
>
> Should this be mapped as a Relation:restriction? For example, a relation
> with "restriction=no_turn_on_red" + "except=bicycle"?
>
> Alternatively, I see there is a tag used in Europe in the form
> "red_turn:right:bicycle=yes" + "red_turn:right=no" - this would mean that
> bicycles may turn red at a traffic signal but other vehicles may not turn.
> This is documented at https://wiki.openstreetmap.org/wiki/Red_turn
>
> That tag is also used when right turns are allowed, e.g.
> "red_turn:left=yes", when this would not always be expected. It's most
> often used in Dresden.
>
> Oddly, it is proposed on the page that you could also use
> "red_turn:straight:bicycle=yes" to say that "bicycles are allowed to go
> straight at this traffic light when it is red", but this sounds very
> strange to me.
>
> I wonder if "red turn" is a translation from German or another language?
>
> -- Joseph Eisenberg
>
>
> ___
> 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

2020-09-29 Thread Supaplex
Now I am a little confused.

As I understand Pieter, you used "width:carriageway" in Bruges in a way
that includes parking:lanes (although you can estimate later how much is
effectively not available for flowing traffic if using parking:lanes).

My initiative for a clarification of the tagging was motivated among
other things to find a distinction between width /with/ and /without/
parking lanes in order to not only indirectly estimate the effective
width but to measure it directly. Personally, I had understood
"width:carriageway" to mean only the effective width available for
flowing traffic. But maybe this is exactly the right term for the
measurement from curb to curb and we still need a new term for the
effective width ("width:traffic_area")? Or is it anyway illusory to
specify the effective width of a roadway, because it has no "fixed
limit" (parking cars are changeable) and you can only estimate it anyway
by a combination with "parking:lane"...?

I think it would be helpful to be able to specify an effective width if
needed. After all, this is the most interesting parameter for assessing
the quality/usability of a street. Even with a full parking:lane-tagging
the estimation is worse than simply measuring it directly. For example,
in the case of "half_on_kerb" parking it is not clear to assume that
exactly half the average vehicle width is "lost" on the carriageway -
sometimes there is only one tire on the sidewalk and two thirds of the
vehicle occupies the roadway. Also global assumptions for the loss of
width when parking "diagonal" or "perpendicular" seem unrealistic to me.
De facto, parking lanes almost always occupy a constant area, and the
effective width of the carriageway can be specified to within a few
decimeters on site or on aerial photographs.

What do we do now? My (new) suggestion: "width:carriageway" means the
total road width from curb to curb or from edge to edge of the road
surface. "width:traffic_area" (or another suitable term; so far nothing
comparable is in use as far as I see) could be used to indicate the
effective width available for flowing traffic.

Alex


Am 27.09.20 um 22:47 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 27. Sep 2020, at 13:45, Pieter Vander Vennet  
>> wrote:
>> This width was tagged with 'width:carriageway'. 
>>
>
> I think this is a good tagging decision, being explicit about which width you 
> have measured seems the way to avoid ambiguity. (and it still leaves room for 
> the next project which could measure sidewalk widths ;-) ).
>
> 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] "width" on streets: Time for a recommendation

2020-09-21 Thread Supaplex
As a result of this discussion I would like to add a clarifying
paragraph on the corresponding wiki page. The core statement is: "To
avoid these ambiguities, some tags are in use to specify the width of
different elements: ..." See the Talk Page:
https://wiki.openstreetmap.org/wiki/Talk:Key:width#.22width.22_on_streets.2Fhighway

Maybe someone has time and motivation to make a proposal(?) to directly
define "width" in these cases. Since there are different opinions on
this, I would leave it at a clarifying paragraph for now.

- Alex -


Am 14.09.20 um 20:34 schrieb Supaplex:
> 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] Linking Sidewalks to Highways

2020-09-21 Thread Supaplex
It's centered on motorists‘ point of view as long as cars are granted
the central role as user group of streets in the traffic planning
discourse - for the time after that we already have
highway=living_street, highway=pedestrian and bicycle_road=yes.

;)



Am 21.09.20 um 12:42 schrieb Martin Koppenhoefer:
> isn’t this all centered on motorists‘ point of view? 
> What do people think about seeing it from other perspectives, e.g. 
> highway=cycleway and adding tags like primary=track (means there is an 
> implied primary road, physically separated, which is running along this 
> cycleway).
> Can also be done for sidewalks:
> highway=footway
> footway=sidewalk
> name=Highstreet
> has_road=primary
>
> is there interest in developing such complementary tagging ?
>
> 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] Linking Sidewalks to Highways

2020-09-21 Thread Supaplex
This leads to another topic where there is just as much need for action.
You can find the is_sidepath-scheme here:
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:is_sidepath

It looks like a stub (note also the talk page), because the idea is very
simple but still solves some big problems with separate paths:

  * Separate paths are thus tagged with "is_sidepath=yes" (or simple
"sidepath=yes", need to be discussed). "footway=sidewalk" is already
in use to solve this issue on sidewalks, but there is nothing for
e.g. separate bike paths.
  * The associated highway is still tagged with
"cycleway/sidewalk=separate" (as well as the access tag
"use_sidepath" if using the sidepath is compulsory).
  * The main categories of the highway, "name" and its classification
like "primary/secondary", can be assigned to the separate way with
Keys like "sidepath:of" or "sidepath:of:name". Other values like
"lit" should anyway be tagged directly on the separate way.

What is achieved with this? Routers recognize very easily whether a
separate path is associated with a road. For example, if you want to
avoid main roads in routing, you can do so with this scheme. Routers
can, without misusing "name" on the separate way, provide a street name
("Turn right on XY street"). This variant also has advantages for
rendering. For example, at smaller zoom levels, renderers could display
"cycleway=separate" as "cycleway=track" while skipping separate paths
for better clarity.

The problem remains that physically non-existent road crossings ("wildly
crossing the street"), which in reality represent a crossing possibility
for many users, are still not available for routing. In my opinion, this
problem is not very relevant if separate ways are well mapped (which
they often are unfortunately not!) and all essential routable
connections are in the database. At the beginning and at the end of the
route, people can use their brains ("destination across the street") if
their routers do not solve this task for them. If there are major
detours on the way, routable connections or suitable access tags (e.g.
"foot=yes, wheelchair=no") are missing. Or it is a crossing possibility
which I do not want to get from a router because of its dangers. In this
context it might be more important to find a way to distinguish between
physical/formal and "wild"/informal connections and to raise awareness
for the use of access tags for different user groups (like wheelchair,
bicycle with trailer).

- Alex -


Am 19.09.20 um 00:54 schrieb Alan Mackie:
> On Fri, 18 Sep 2020 at 21:35, Tobias Knerr  wrote:
>
>> On 17.09.20 02:35, Taskar Center wrote:
>>> This is yet another example why "sticking" the sidewalks onto the
>>> highway (as a tag) rather than mapping them as separate ways is
>>> appearing to be less and less practical. Please see our sidewalk schema
>>> proposal
>>> 
>>> from several years ago.
>> Your sidewalk proposal unfortunately doesn't really address the crucial
>> shortcoming of separately mapped sidewalks: The lack of a reliable
>> mechanism for figuring out which section of road a given sidewalk way
>> belongs to.
>>
>> I agree that we should be able to give sidewalks their own geometry, but
>> we _also_ need the relationship between sidewalk and road. So far, all
>> the proposals attempting to support the former end up sacrificing the
>> latter.
>>
> Was this meant to be one of the purposes of associated street relations?
>
>> There have been some promising discussions recently around the
>> sidepath_of idea, but that's still just brainstorming. Until a practical
>> solution is found and actually used in the database, sidewalk mapping
>> will remain a choice between two options that are broken in different ways.
>>
> I hadn't heard this one. Do you have a link to the discussion? I would
> personally prefer sidewalk_of or walkway_of if we were to go this route
> though. Sidepath sounds like something that's branching to me.
>
> Both associated street and sidepath_of still have the issue of when you're
> allowed to jump from one to the other, kerbs can be stepped over by most,
> railing less so (they're often to keep pedestrians out of blindspots). It
> must be difficult to tell if a sidewalk is separated specifically because
> the transition from one to the other is more thoroughly blocked and not
> simply as an added level of detail  with no more than the normal impediment
> to foot traffic.  The only thing I've seen discussed that might work for
> this was in a talk about way and street areas.
>
>> As for the main issue of the thread: I would welcome a clear definition
>> for the meaning of width. In my own mapping and when writing the
>> relevant code in OSM2World, I have counted sidewalks etc. as part of the
>> road's width if they are mapped as tags on the main way. But I would of
>> course change that if there finally was a 

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

2020-09-16 Thread Supaplex
I would appreciate using crossing=zebra! (instead of crossing=marked +
crossing_ref=zebra, so I have tagged it so far.) But I can't imagine
that people use or change "marked" instead of "traffic_signals". Or have
you observed this somewhere? For me "marked" would be something like
"paved" for Key:surface: a value which could be specified more exactly
in most cases (especially using "zebra" instead).

Do you have examples where "zebra" is changed automatically? Where and
who and why?

In rare cases, however, there are still crossings with special
structural forms, where "marked" could be a useful value for greater
generalisation, e.g. in this case:
https://wiki.openstreetmap.org/wiki/File:%C3%9Cberwegmarkierung_B%C3%BCrgerstra%C3%9Fe.jpg
(because of the surface, not the markings - and it's not a traffic calming)

In Berlin we are experimenting with a few extensions, by the way, see
[de]:
https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Fu%C3%9Fwege#Gehweg.C3.BCberg.C3.A4nge

Alex


Am 16.09.20 um 11:57 schrieb Martin Koppenhoefer:
> I noticed that crossing=zebra tag usage is drastically shrinking while the
> very generic crossing=marked, which was quite unpopular before (2013-2018
> below 6000 uses) now went through the roof and is leading the tagstats with
> more than 1 million uses. What do you think about it, shouldn't we be
> encouraging people to use more specific tags like crossing=zebra or
> crossing=traffic_signals instead?
>
>
> ___
> 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

2020-09-16 Thread Supaplex
> I expect the "width" of a way to be the actual width of the object it
> represents. 
It depends on how we define "highway" in the OSM sense. You could also
assume that sidewalks etc. are "sticking" on the highway merely for
pragmatic reasons. Depending on the point of view, sidewalks and
highways represent different entities. (There is no law definition here,
I only find a German court decision that deals with street widths and
thus means the distance between the curbs, with carriageway and parked
vehicles, so as definition 2 above.)

But I agree that it would be better to always specify which width is
meant exactly when mapping widths on streets (especially to use
"width:carriageway" for the rating of traffic suitability).
Nevertheless, a default, which meaning of "width" is meant without a
prefix/suffix, would still be helpful. Fun Fact: On the wiki highway
page - in contrast to what is discussed here - it says since 2012 that
"width" means the width of the carriageway (but it does not look like
this paragraph has ever been discussed):
https://wiki.openstreetmap.org/wiki/Highways#Surface.2C_width_and_lighting

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


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

2020-09-14 Thread Supaplex
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


Re: [Tagging] Feature Proposal - Voting - kerb=regular

2020-08-21 Thread Supaplex
I see that I have probably chosen an unfavorable solution to solve the
problem described. Many seem to accept the basic problem: There is only
one qualitative category for all kerbs with a height of over ~3 cm,
although in reality there is a significant difference.

I see two alternatives to the proposed solution:

a) (as suggested in the vote section) Deprecate the category "raised"
and introduce two /new/ values ​​to differentiate it (eg "heightened"
vs. "regular" or "medium" if there is sematic criticism of "regular")
b) Keep the existing categories, accept that the term "raised" has so
far included both normal and raised kerbs and merely introduce an
explicit tag to distinguish /actually/ raised kerbs (e.g. "heightened").

What do you think? Any other or further suggestions?

Alex


P.S. The advice to specify the height precisely in cm instead does not
lead any further - as discussed in several places -, since precise
height information cannot be collected on a large scale and remains
optional. It is not without reason that there are qualitative curb
categories - just one too few. A typical intersection has about 8 curbs,
which I can assess qualitatively with my eyes within some seconds while
passing, but I need a few minutes to measure them all with a ruler...


Am 21.08.20 um 01:19 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 21. Aug 2020, at 01:05, Clifford Snow  wrote:
>>
>> Martin - does that suggest that over 12,000 existing raised kerbs will need 
>> to be resurveyed?
>
> that’s how I read it, and there are actually 28.4K raised kerbs affected 
> (because you have to look at the ways as well).
>
> 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


[Tagging] Feature Proposal - Voting - kerb=regular

2020-08-20 Thread Supaplex
Voting is now open for the tag kerb=regular:

https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular

I intend to add the tag /kerb=regular/ to explicitly distinguish
kerbs/curbs with "normal" standard height from /kerb=raised/ to solve a
lack of clarity in the differentiation between raised and regular
("normal", neither lowered nor raised) kerbs. There is a relevant
difference not only for wheelchair users, but also for other mobility
groups and routing purposes that should be reflected in the categories
of the key. Read more on the proposal page.

Thanks for your previous comments and your future votes.

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


[Tagging] Feature Proposal - RFC - kerb=regular

2020-08-01 Thread Supaplex
Hey all,

As already mentioned on this list I intend to add the tag kerb=regular
to explicitly distinguish common standard height kerbs/curbs from
kerb=raised. Proposal, information and further discussion can be found
here: https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular

For the formality and documentation I send this again as an official RFC.

I hope for your comments - greets
Alex


Am 01.08.20 um 15:01 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 1. Aug 2020, at 12:36, Supaplex  wrote:
>>
>> I wrote a proposal for it: 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular
>>
>> How should I proceed - can I already set the status to "Proposed"? Do I have 
>> to write a separate email for RFC or is this thread sufficient?
>>
>> I hope for your comments - greets
>> Alex
>>
>
> I would see this email to be an RFC, although it could have been better to 
> explicitly include the acronym RFC in the subject of your message, as this is 
> what the guidelines state. The procedure for proposal is presented here:
> https://wiki.openstreetmap.org/wiki/Proposal_process
>
> 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] kerb=regular vs. raised - Proposal

2020-08-01 Thread Supaplex
I wrote a proposal for it:
https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular

How should I proceed - can I already set the status to "Proposed"? Do I
have to write a separate email for RFC or is this thread sufficient?

I hope for your comments - greets
Alex


Am 01.08.20 um 09:42 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 1. Aug 2020, at 09:39, Supaplex  wrote:
>>
>> I felt that this list more agreed rather than opposed.
>
> bring it to voting. 
>
>
> 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] kerb=regular vs. raised

2020-08-01 Thread Supaplex
There was no change in the OSM database, so the project is not affected.
kerb=regular anyway is already in use but undocumented. Current
wheelchair/mobily projects should anyway consider this existing tagging.
As I described it needs clarity in the differentiation between raised
and regular kerbs and after the discussion here, I felt that this list
more agreed rather than opposed.


Am 01.08.20 um 09:01 schrieb Volker Schmidt:
> Please revert this wiki change.
> The kerb hight values have been used in at least one project documenting
> wheelchair accessibility.
>
> On Sat, 1 Aug 2020, 08:53 Supaplex,  wrote:
>
>> As an result of this diskussion (no strong opposition, some general
>> remarks, some endorsement) I added "kerb=regular" to the tagging example
>> list in the wiki and adjusted hight descriptions (with values discussed
>> here). If there is further need for discussion and changes, it could be
>> carried out in the wiki: https://wiki.openstreetmap.org/wiki/Key:kerb
>>
>> Greets, Alex
>>
>>
>> Am 29.07.20 um 20:56 schrieb Supaplex:
>>
>> Hey all,
>>
>> I started mapping detailed sidewalk information in my area, including
>> crossing and kerb information. It seems that there is a lack of clarity
>> in the differentiation between raised and regular ("normal", neither
>> lowered nor raised) kerbs. "kerb=regular" is already in use but is
>> undocumented and should be explicitly distinguished from "kerb=raised".
>> There is a relevant difference not only for wheelchair users, but also
>> for other mobility groups (cargo bikes, strollers, pedestrians with
>> reduced mobility…).
>>
>> So I propose adding "kerb=regular" to the tagging list in the wiki as
>> well as suitable descriptions for height, use… and an example image. I
>> made a suggestion in the wiki (since there has been no reaction so far I
>> post it 
>> here):https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#kerb.3Dregular_vs._raised_--_add_.22regular.22_example
>>
>> Is there a reason not to add this? Otherwise I’ll do that.
>>
>> Greets, Alex
>>
>>
>>
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://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] kerb=regular vs. raised

2020-08-01 Thread Supaplex
As an result of this diskussion (no strong opposition, some general
remarks, some endorsement) I added "kerb=regular" to the tagging example
list in the wiki and adjusted hight descriptions (with values discussed
here). If there is further need for discussion and changes, it could be
carried out in the wiki: https://wiki.openstreetmap.org/wiki/Key:kerb

Greets, Alex


Am 29.07.20 um 20:56 schrieb Supaplex:
> Hey all,
>
> I started mapping detailed sidewalk information in my area, including
> crossing and kerb information. It seems that there is a lack of clarity
> in the differentiation between raised and regular ("normal", neither
> lowered nor raised) kerbs. "kerb=regular" is already in use but is
> undocumented and should be explicitly distinguished from "kerb=raised".
> There is a relevant difference not only for wheelchair users, but also
> for other mobility groups (cargo bikes, strollers, pedestrians with
> reduced mobility…).
>
> So I propose adding "kerb=regular" to the tagging list in the wiki as
> well as suitable descriptions for height, use… and an example image. I
> made a suggestion in the wiki (since there has been no reaction so far I
> post it here):
> https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#kerb.3Dregular_vs._raised_--_add_.22regular.22_example
>
> Is there a reason not to add this? Otherwise I’ll do that.
>
> Greets, 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


[Tagging] kerb=regular vs. raised

2020-07-29 Thread Supaplex
Hey all,

I started mapping detailed sidewalk information in my area, including
crossing and kerb information. It seems that there is a lack of clarity
in the differentiation between raised and regular ("normal", neither
lowered nor raised) kerbs. "kerb=regular" is already in use but is
undocumented and should be explicitly distinguished from "kerb=raised".
There is a relevant difference not only for wheelchair users, but also
for other mobility groups (cargo bikes, strollers, pedestrians with
reduced mobility…).

So I propose adding "kerb=regular" to the tagging list in the wiki as
well as suitable descriptions for height, use… and an example image. I
made a suggestion in the wiki (since there has been no reaction so far I
post it here):
https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#kerb.3Dregular_vs._raised_--_add_.22regular.22_example

Is there a reason not to add this? Otherwise I’ll do that.

Greets, Alex

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