Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Warin]

On 12/12/19 16:00, John Willis via Tagging wrote:



On Dec 9, 2019, at 6:36 AM, Warin <61sundow...@gmail.com 
> wrote:


individual ways that have the direction, not the entire relation.


some routes (made of many overlapping pieces of trail) are considered 
ascents and decents. the named “trail" is made of the ascent route and 
descent route.


tagging Mt fuji is the opposite of a trail hundreds or thousands of Km 
long - it’s a few routes less than 10 KM long used by thousands of 
people every day of the season.


http://www.fujisan-climb.jp/en/m8bimq001afw-img/Fuji_Climbing_Map_L.jpg

The colors are the different trails. the dashed lines are the descent 
routes. there are overlapping ascent and decent routes from different 
trails (subashiri &  Yoshida between the summit and 8th station) and 
shared paths/tracks as well.


it would be nice to be able to tag the ascent/descent/both.


If the route is considered to be a return then I would map it like a 
public transport version 2 route

from the start/finish
way 1 role forward
way 2 (assent) role forward
way3  role forward
(top)
way 3 role backwards
way 4 (decent) role forward
way 1 role backwards


The elevation profile will give you assent/decent info. Are ways 2 & 4 
one way? If so you could use the description key on those ways to say 
assent/decent?

But ways 1&3 are 2 way.

Problem with the above .. you could not easily split one route at the 
top to use another route to descend. If the accent and decent were 
different relations then it would be easier, and each relation can have 
the assent.decent description. Of course both these routes could be 
included into a relation to combine them with the name etc.

???



I mentioned this in the comments, but the answer didn’t seem to 
address the issue directly.


also - does the relation need intersection/junction nodes?


I don't think so.


also also - links?


What links? urls? or do you mean ways that connect the route to 
bus/train/etc? In which case I think those can be role approach ?




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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[John Willis via Tagging]

> On Dec 9, 2019, at 6:36 AM, Warin <61sundow...@gmail.com> wrote:
> 
> individual ways that have the direction, not the entire relation. 

some routes (made of many overlapping pieces of trail) are considered ascents 
and decents. the named “trail" is made of the ascent route and descent route. 

tagging Mt fuji is the opposite of a trail hundreds or thousands of Km long - 
it’s a few routes less than 10 KM long used by thousands of people every day of 
the season. 

http://www.fujisan-climb.jp/en/m8bimq001afw-img/Fuji_Climbing_Map_L.jpg 


The colors are the different trails. the dashed lines are the descent routes. 
there are overlapping ascent and decent routes from different trails (subashiri 
&  Yoshida between the summit and 8th station) and shared paths/tracks as well. 

it would be nice to be able to tag the ascent/descent/both. 

I mentioned this in the comments, but the answer didn’t seem to address the 
issue directly. 

also - does the relation need intersection/junction nodes? 

also also - links?

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

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Martin Koppenhoefer]

Am Mi., 11. Dez. 2019 um 13:29 Uhr schrieb Allroads :

>
> Lately I wrote down for myself some thoughts.
> 1. A traffic sign (combination) should preferably be tagged with as few
> tags as possible.
> 2. A traffic sign should preferably be tagged as directly as possible with
> tags.
> 3. Neutralizing, opposite tagging should be avoided as much as possible.
>


completely agree, could be copied to the access documentation page.



> 4. The diagram access hierarchy is not complete, missing keys.
>


yes


5. When developing key value, the decision hierarchy must be considered.
>


yes



> 6. Every way of transport must have equal opportunities to achieve good
> routing.
>


I do not understand what you intend with "equal opportunities", the
possible transport modes are infinite, so we should focus on the common
transport modes IMHO. This does not imply we should ignore the others, but
we must not invent tags for hypothetical transport modes unless they are
needed somewhere. At this point, the specific case should be discussed.



> 7. Possible conflicting keys/value must be solved. (Dual explanation).
>


sure



> 8. A traffic signs wiki is very important. (Also combination signs on
> pages.) Carefully selected, customized for possibility of use in presets.
>


traffic signs are per country, with ~200 countries this will become quite
big. It certainly is doable for standardized signs, but many jurisdictions
allow for free form signs (text), so this can never become "complete". See
6.), lets discuss and invent new tags when needed.
I've suffered myself from unclear textual traffic signs, at the via Appia
Antica in Rome (ancient road with paving that doesn't make it generally
useful as a shortcut), vehicular traffic is generally excluded (in
theory/by signage), but there's a textual exception: "except local traffic"
(it:eccetto traffico locale). I've asked on the Italian mailing list and
checked in the traffic law, but the term doesn't seem to be defined. A
websearch only found other people with the same problem of not
understanding the meaning. Here's an official example of the police
ordering such an exception for a day (but there are also permanent signs):
https://www.comune.roma.it/web-resources/cms/documents/disciplina_bianchi.pdf
(you can see that they first added "except residents" and then changed it
to "local traffic").



>
> multi_tracked_motor_vehicle, the possibility of use, used in presets, (it
> is a correct key) maybe over 10-15 years, we see, it is a established key,
> more important then motorcar. ;-) The life of a key. Mission accomplished.
> Give it a try?
>


can you give a real world example where it would be needed? Is there a
traffic sign for a multi-tracked motor vehicle somewhere that is different
from a motorcar icon / where there are specific distinct signs for both?



>
> or is a key needed that gives which type of motor is used.
>
> moped=no  and moped:electric=yes
>


I am not sure speed pedelecs are a subclass of moped. In some countries at
least, mopeds are defined through the engine displacement (50ccm), this
obviously can not apply to an electric motor.



>
> In the Nedertherlands on a G13 traffic_sign “not mandatory cycleway” a
> mofa can use it, BUT, ..
> “Bestuurders van snorfietsen uitgerust met een verbrandingsmotor mogen
> het onverplichte fietspad slechts gebruiken met uitgeschakelde motor.”
> “Drivers of light mopeds equipped with an internal combustion engine may
> only use the non-mandatory cycle path with the engine switched off.”
>


IMHO this is a case for "do not map your local legislation", IMHO it means
your legislation says that mofas with the combustion motor turned off are
considered bicycles. The mofa driver must know this rule and can interpret
the bicycle restrictions in this case.




>
> *:electric=* is lower in hierarchy  not used yet,
> https://taginfo.openstreetmap.org/keys/mofa:electric
> Is this better to appoint electric use?
>


mofa:electric has the same comment then moped:electric: I'd rather use a
new specific key for both. Something like "pedelec" and "speed_pedelec".
It's probably only a question of time when the legislators will start to
cater specifically for this kind of vehicle (own symbols etc.). We're
supposedly in a transition phase where things have not settled yet. It
seems also to be better according to your list (points 1-4).

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

Re: [Tagging] Feature Proposal - RFC - Small electric vehicles

[Allroads]

>.>they? Why didn’t you do something about it? 
> (or are you asking for bicycles with sidecars?)
>generally I agree, exceptions apply. In the motorcar example they are grounded 
>in real life particularities (best reason I’d say).
>...

I am a part of the they, then it was not within my area of focus, scope, in the 
given time range when it originated and was implemented, now after a while we 
all have more knowledge, then the question is how we can solve it in a way that 
does justice to, where the tagged does not be destroyed in such a way, that it 
remains applicable. That is my approach now.
So leave motorcar as it is, people who want to use it, because it is used so 
much. 
Don't let us stop implementing the following.
Give people the opportunity, to tag more correctly, this means for me the 
introduction of multi_tracked_motor_vehicle, /mt_motor_vehicle. This does 
justice to the principle “generally I agree”. 

Where I am working on: 
Traffic_sign translation. I miss keys for transportation, to make a tag 
combination. So I am interested in the access diagram.
https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden
Ended up to make a style, to see and control the tags. Get hints in Josm 
window. 
http://mijndev.openstreetmap.nl/~allroads/JOSM/Styles/Road_extended_JOSM_style_info.html
Far from ready. Under construction. I must totally rewrite it, because of new 
insights, new wishes, things are not possible in mapcss and still learning, 
time as stumbling block.
https://forum.openstreetmap.org/viewtopic.php?id=58694
Focus on road tagging.

When it comes to a voting about a key/value.
Give people the opportunity, to tag more correctly, at a voting, which 
arguments are more important. Saying “no” “yes”, the why is more important.
When I make a proposal, multi_tracked_motor_vehicle. Many are fine with 
motorcar, If they do not see the need for others and there vote is “no”, this 
“no” has for me a lesser value.
This could have a negative effect on the development of OSM.
Which interest is greater than the others, what to decide.

Lately I wrote down for myself some thoughts. 
1. A traffic sign (combination) should preferably be tagged with as few tags as 
possible.
2. A traffic sign should preferably be tagged as directly as possible with tags.
3. Neutralizing, opposite tagging should be avoided as much as possible.
4. The diagram access hierarchy is not complete, missing keys.
5. When developing key value, the decision hierarchy must be considered.
6. Every way of transport must have equal opportunities to achieve good routing.
7. Possible conflicting keys/value must be solved. (Dual explanation).
8. A traffic signs wiki is very important. (Also combination signs on pages.) 
Carefully selected, customized for possibility of use in presets.

multi_tracked_motor_vehicle, the possibility of use, used in presets, (it is a 
correct key) maybe over 10-15 years, we see, it is a established key, more 
important then motorcar. ;-) The life of a key. Mission accomplished.
Give it a try?

So I must make a icon for speedpedelec, for use my style.
This is needed because, government write speedpedelec with text on traffic_sign 
(undersigns). Even estate owners could make signs with ..

small electric vehicles, as a group, which vehicles, where is it placed in the 
hierachy, which icon should I use.
hydrogen, ...must these vehicle have also their own group? (future)

or is a key needed that gives which type of motor is used.

moped=no  and moped:electric=yes

In the Nedertherlands on a G13 traffic_sign “not mandatory cycleway” a mofa can 
use it, BUT, ..
“Bestuurders van snorfietsen uitgerust met een verbrandingsmotor mogen het 
onverplichte fietspad slechts gebruiken met uitgeschakelde motor.”
“Drivers of light mopeds equipped with an internal combustion engine may only 
use the non-mandatory cycle path with the engine switched off.”
https://wetten.overheid.nl/BWBR0004825/2019-07-01#HoofdstukII_Paragraaf1_Artikel5
This means that you can use it with a electric motor or bicycle pedals (if on 
it), manually.
Then the access is mofa=no mofa:electric=yes mofa:manual=yes.
This is a translation of a traffic_sign and law rules.

*:electric=* is lower in hierarchy  not used yet, 
https://taginfo.openstreetmap.org/keys/mofa:electric

Is this better to appoint electric use?

I think so it could also be used for all type of vehicles.

See the practise of emission zones and rules, what we see translated on 
traffic_signs.
https://forum.openstreetmap.org/viewtopic.php?id=60186 even the age of a 
vehicle is now used.




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