l. 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 explanati
"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 emerg
p.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 examp
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 comm
k 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 S
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.
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
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
: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
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 Kopp
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 problem
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:s
> 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
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 interpr
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 pr
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
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:
>&g
8.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
>
> __
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
>>
arried 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
&g
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
undocumente
21 matches
Mail list logo
