date:20190508

I don't read Japanese, but the parts that I can understand seem to
follow the generally-accepted ways of tagging roads.

I appreciate that the Japanese community is discussing these things in
public and developing a consensus before making changes to the wiki
pages.

I wish I could do this with other mappers in Indonesia!

On 5/9/19, 石野貴之  wrote:
> Hello.
>
> 2019年5月9日(木) 7:57 Graeme Fitzpatrick :
>
>> On Thu, 9 May 2019 at 06:15, marc marc  wrote:
>>
>>> Some use the status to check propal with the status=Voting
>>>
>>> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
>>
>>
>> When I had a look at that page, I noticed
>> https://wiki.openstreetmap.org/wiki/Proposed_Japan_tagging/Road_types,
>> which I hadn't seen discussed previously.
>>
>> This feature has been proposed by our fellow, Yuu Hayashi. You may think
> this hasn't been discussed previously, but it's totally wrong. He has been
> working on Japanese road tagging for more than four years.
>
> I am also involved in the discussion. If you read Japanese, see the
> following pages about cycleway and living_street.
> https://wiki.openstreetmap.org/wiki/Proposed_Japan_tagging/Road_types_2/cycleway
> *https://wiki.openstreetmap.org/wiki/Proposed_Japan_tagging/Road_types_2/living_street*
> 
>
>
>> I think it may be for changing road details in Japan only, but also seems
>> to refer to general highway classifications under the "What pages are
>> affected" heading?
>>
>> Is it possible to change details for only one country, or would this
>> proposal change all highway details, worldwide?
>>
> If so, shouldn't that be discussed much more widely?
>>
>> This discussion is aimed for deciding local rules in Japan only and will
> not affect highway details all over the world.
>
> Thank you.
>
> Takayuki Ishino
> yumean1...@gmail.com
>
>>
>

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

Re: [Tagging] Japan road tagging (Was "what todo if the status of a propal isn't set to Voting")

2019-05-08 Thread 石野貴之

Hello.

2019年5月9日(木) 7:57 Graeme Fitzpatrick :

> On Thu, 9 May 2019 at 06:15, marc marc  wrote:
>
>> Some use the status to check propal with the status=Voting
>>
>> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
>
>
> When I had a look at that page, I noticed
> https://wiki.openstreetmap.org/wiki/Proposed_Japan_tagging/Road_types,
> which I hadn't seen discussed previously.
>
> This feature has been proposed by our fellow, Yuu Hayashi. You may think
this hasn't been discussed previously, but it's totally wrong. He has been
working on Japanese road tagging for more than four years.

I am also involved in the discussion. If you read Japanese, see the
following pages about cycleway and living_street.
https://wiki.openstreetmap.org/wiki/Proposed_Japan_tagging/Road_types_2/cycleway
*https://wiki.openstreetmap.org/wiki/Proposed_Japan_tagging/Road_types_2/living_street*



> I think it may be for changing road details in Japan only, but also seems
> to refer to general highway classifications under the "What pages are
> affected" heading?
>
> Is it possible to change details for only one country, or would this
> proposal change all highway details, worldwide?
>
If so, shouldn't that be discussed much more widely?
>
> This discussion is aimed for deciding local rules in Japan only and will
not affect highway details all over the world.

Thank you.

Takayuki Ishino
yumean1...@gmail.com

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

[Tagging] Feature proposal - RFC - Telecom distribution points

2019-05-08 Thread François Lacombe

Hi all,

Here is a proposal regarding telecom distribution points boxes
https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points

Since several concepts already exist, it is proposed to extend telecom=*
key with a new value : distribution_point.

As a very particular and ubiquitous feature, you may not be interested to
get involved in this mapping topic. Nevertheless, this RFC will be useful
to get comments and additional international examples as I only had
pictures of French networks. Feel free to propose any relevant picture for
that.
I aim to provide a consistent way of tagging about features everyone can
see and be tempted to add to database one of those days.


Thanks in advance for your time, all the best

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

Re: [Tagging] Feature Proposal - Voting - tag:Police

2019-05-08 Thread Jan S

Well, I share the impression that the tag will be accepted this time. I'll let 
the voting open during the usual 14 days period however. You never know if 
someone will have another opinion on this.

Best, Jan

Am 5. Mai 2019 22:49:57 GMT-05:00 schrieb Mateusz Konieczny 
:
>Just wait for the end of voting schedule.
>
>
>5 May 2019, 20:53 by bkil.hu...@gmail.com:
>
>> We're now at 20 unanimous approval votes. Do we still need more?
>>
>> On Sun, Apr 28, 2019 at 11:51 PM Graeme Fitzpatrick <>
>graemefi...@gmail.com > > wrote:
>>
>>>
>>>
>>> On Mon, 29 Apr 2019 at 04:18, Jan S <>> grimpeu...@gmail.com
>>> > wrote:
>>>

 So, I'm looking forward to your votes

>>>
>>> Done! Good luck :-)
>>>
>>> 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

Re: [Tagging] Feature Proposal - crossing=marked

2019-05-08 Thread Clifford Snow

On Wed, May 8, 2019 at 2:48 PM Graeme Fitzpatrick 
wrote:

>
> Now we may (yet again!) be getting caught up in the
> one-word-different-meanings-worldwide saga, but, in Australia at least,
> "zebra" crossings (parallel alternating black & white stripes crossing the
> road) are controlled - they signify a pedestrian crossing & drivers must
> stop & give way to any pedestrians on or approaching the crossing.
>
> So are there different rules elsewhere, so that you can say "zebra is
> marked but uncontrolled"?
>

Where I live in the US, Washington State, a pedestrian has the right of way
at any intersection unless otherwise indicated. Other places the pedestrian
only has the right of way in marked crossings.  But a marked crossing
doesn't necessarily mean controlled. To me that means some sort of signal.
Similar to the way we tag supervised crossings  highway=crossing +
crossing=* as appropriate + supervised=yes

Best,
Clifford
-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Japan road tagging (Was "what todo if the status of a propal isn't set to Voting")

2019-05-08 Thread Graeme Fitzpatrick

On Thu, 9 May 2019 at 06:15, marc marc  wrote:

> Some use the status to check propal with the status=Voting
>
> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status

When I had a look at that page, I noticed
https://wiki.openstreetmap.org/wiki/Proposed_Japan_tagging/Road_types,
which I hadn't seen discussed previously.

I think it may be for changing road details in Japan only, but also seems
to refer to general highway classifications under the "What pages are
affected" heading?

Is it possible to change details for only one country, or would this
proposal change all highway details, worldwide?

If so, shouldn't that be discussed much more widely?

Thanks

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

Re: [Tagging] what todo if the status of a propal isn't set to Voting ?

Oops, thanks for catching that.

It would be nice if this could all be set with one click in the wiki

Joseph

On Thu, May 9, 2019 at 6:05 AM marc marc  wrote:

> Le 08.05.19 à 22:45, Michael Reichert a écrit :
> > Hi,
> >
> > Am 08.05.19 um 22:14 schrieb marc marc:
> >> Some use the status to check propal with the status=Voting
> >>
> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
> >> but some propal fail to have it, currently
> >> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
> >>
> >> what todo in this case ? only fix the status or also extend the voting
> >> period to allow ppl to have enought time to see it ?
> >
> > The voting is invalid and has to be repeated.
>
> repeated from scratch or extended with voteEndDate=  ?
> imho extended fit the need but I prefer to ask.
> ___
> 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 - crossing=marked

2019-05-08 Thread Graeme Fitzpatrick

On Thu, 9 May 2019 at 03:38, yo paseopor  wrote:

> zebra is marked but uncontrolled
>

Maybe (quite possibly!) I'm getting confused over the whole controlled /
uncontrolled concept?

I thought that controlled means that their is signage / indication of some
form that says a driver has to stop to allow pedestrians to cross; while
uncontrolled basically equals unmarked - there is provision made (gutter
ramps etc) to allow people to easily cross the road, but there are no
crossing markings of any sort eg
https://www.google.com/maps/@-28.070894,153.4363207,3a,75y,302.12h,81.73t/data=!3m5!1e1!3m3!1s9ZbzIxzGlFkj8GrFmiQ38Q!2e0!6s%2F%2Fgeo0.ggpht.com%2Fcbk%3Fpanoid%3D9ZbzIxzGlFkj8GrFmiQ38Q%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D336.35266%26pitch%3D0%26thumbfov%3D100
,
however a driver must still stop to allow pedestrians to cross?

Now we may (yet again!) be getting caught up in the
one-word-different-meanings-worldwide saga, but, in Australia at least,
"zebra" crossings (parallel alternating black & white stripes crossing the
road) are controlled - they signify a pedestrian crossing & drivers must
stop & give way to any pedestrians on or approaching the crossing.

So are there different rules elsewhere, so that you can say "zebra is
marked but uncontrolled"?

Thanks

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

Re: [Tagging] what todo if the status of a propal isn't set to Voting ?

Le 08.05.19 à 22:45, Michael Reichert a écrit :
> Hi,
> 
> Am 08.05.19 um 22:14 schrieb marc marc:
>> Some use the status to check propal with the status=Voting
>> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
>> but some propal fail to have it, currently
>> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
>>
>> what todo in this case ? only fix the status or also extend the voting
>> period to allow ppl to have enought time to see it ?
> 
> The voting is invalid and has to be repeated.

repeated from scratch or extended with voteEndDate=  ?
imho extended fit the need but I prefer to ask.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] what todo if the status of a propal isn't set to Voting ?

2019-05-08 Thread Michael Reichert

Hi,

Am 08.05.19 um 22:14 schrieb marc marc:
> Some use the status to check propal with the status=Voting
> https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
> but some propal fail to have it, currently
> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
> 
> what todo in this case ? only fix the status or also extend the voting 
> period to allow ppl to have enought time to see it ?

The voting is invalid and has to be repeated.
https://wiki.openstreetmap.org/wiki/Proposal_process#Voting is quite
clear (emphasis as given on the wiki page in bold font)
> Set the *status=Voting, voteStartDate=* and *voteEndDate= +14>* (-MM-DD).

I added an ambox (type=info) to the voting section of the proposal.

Best regards

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] what todo if the status of a propal isn't set to Voting ?

Hello,

Some use the status to check propal with the status=Voting
https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Voting%22_status
but some propal fail to have it, currently
https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch

what todo in this case ? only fix the status or also extend the voting 
period to allow ppl to have enought time to see it ?

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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

sent from a phone

On 8. May 2019, at 11:18, marc marc  wrote:

>> Le 08.05.19 à 10:30, Martin Koppenhoefer a écrit :
>> „uncontrolled“, as it is a misnomer.
> 
> indeed, but what could be a better value ?
> crossing=not_controlled_by_a_traffic_signal is a little long

I’m using crossing=zebra and highway=crossing on zebra crossings (I don’t care 
for the difference of traffic light controlled crossings with or without zebra 
markings, the physical presence of road markings is quite ephemeral, I am not 
yet thinking of keeping track of road marking maintenance) 

The only places I am a bit unsure are those with zebra road markings but not in 
proximity of a road intersection and without vertical signs. Legally these 
aren’t zebra crossings around here, but from a practical point of view, drivers 
will try to not run over crossing pedestrians at these spots as well.

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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

sent from a phone

On 8. May 2019, at 11:15, marc marc  wrote:

>> Unmarked crossings are abstract "fictions"
> 
> beware of caricature :
> - unmarked pedestrian crossings with lowered kerb for wheelchairs
> - unmarked pedestrian crossing that connects a sidewalk on each side of 
> the crossing
> 
> just because you've never seen one before doesn't mean it's a fiction

indeed, when a footway crosses the street without any markings you could still 
expect footway traffic crossing there. 
You would not add the tag literally anywhere but only when there are 
indications it is a kind of crossing.

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

Re: [Tagging] Feature Proposal - RFC - toll

On Wed, 8 May 2019 at 19:22, marc marc  wrote:

> .
> osm is a community project, the social is not to be neglected. that
> being said, everyone has read that you will ignore them here, maybe the
> proposal would deserve to be led by someone who has more time to read
> people's opinions on both main channels used for proposals.
>

Only one person (that we know of) wants the new scheme.  Others, like
myself, haven't
mapped a toll, may never map a toll, and comment on the proposal in order
to try to
improve it even though they may never use it.  Because we all benefit from
a rational mapping
scheme and all suffer from a badly-conceived one.

Question: which of those people should be prepared to do the most work by
dealing with
a method of communication they do not prefer?  Those who didn't see a need
for
the change in the first place or the person wanting the change?

What the proposer is implying (whether intentionally or not) is that
his/her/its time is more
valuable than ours.  His/her/its time is more valuable than the time of all
of us who find it
easier to respond on the list than on the wiki, put together.  I doubt very
much that this is
the case.  And even if it were the case, that would just be pointing out
how inferior the rest
of us are, and nobody likes to be made to feel inferior.

In addition, his/her/its attitude isn't helping his/her/its case.
He/she/it doesn't want to do
the work necessary, work that most other proposers accept as part of the
task, and insists
that any of us who prefer responding here must inconvenience ourselves for
his/her/its
benefit.  And then he/she/it accuses me of being childish when I point out
how some
people are likely to respond.  How to make friends and influence people...

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

Re: [Tagging] Feature Proposal - RFC - toll

Le 08.05.19 à 20:05, wiki_openstreetmap_org.5.k...@spamgourmet.com a écrit :
> As said

please quote in an usefull way :)

you could say the same thing with a little more consideration, such as 
"I don't have time to read the mailing list regularly because my 
PERSONAL preference is the wiki, do not hesitate to prefer the wiki for 
your comments"
.
osm is a community project, the social is not to be neglected. that 
being said, everyone has read that you will ignore them here, maybe the 
proposal would deserve to be led by someone who has more time to read 
people's opinions on both main channels used for proposals.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Marking temporary traffic organisation change




8 May 2019, 19:35 by marc_marc_...@hotmail.com:

> Le 08.05.19 à 17:00, Mateusz Konieczny a écrit :
>
>> sometimes change is applied for months
>>
>> How one may mark that such change is temporary?
>>
>> It would be useful for at least two reasons:
>> - it would easier to catch roads for retagging after road recontruction 
>> completes
>>
>
> use > https://wiki.openstreetmap.org/wiki/Key:opening_date 
> 
> with an estimated completion date of the work.
>
opening_date works well for road under construction, it is not fitting for road
that is not closed but some things like oneway status, lanes are modified

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

Re: [Tagging] Feature Proposal - crossing=marked

Le 08.05.19 à 19:37, yo paseopor a écrit :
> zebra is marked but uncontrolled (if it is controlled you can use other 
> value)

but if you see a zebra with satellite image, you often have no idea if a 
the crossing have a traffic light or not in a lot of country (like in 
Belgium/France/Luxembourg/Switzerland)

that's why I proposed that iD change its preset: if someone sees a zebra 
on a satellite image, the only thing that can be added is 
crossing_ref=zebra. crossing=zebra does not allow incremential mapping 
(= one user add info from sat, another user add info from survey)
that's why it doesn't make sense to have the type of marking in the same 
tag as the one that talks about the presence of a light.
unfortunately both the previous preset and the current one lead to the 
destruction (voluntary since the author has been warned for a long time) 
of the crossing=traffic_signals sometimes already present.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - toll

2019-05-08 Thread wiki_openstreetmap_org . 5 . kuru

You have pretty much guaranteed that those who find it easier to respond here will vote against your proposal because it ignored their suggestions.

There are probably some here who will vote against your proposal even if they agree with it 100% because of your attitude.

I'm not attempting to dictate what you do. I'm just informing you that actions can have unwanted consequences. Your choice as to what you do.

--
Paul

- One has made clear that he has no time to process the mails here. Should I write it where I know he will read it? No! I will write them here and be angry about it that he didn't read them. So angry that I will vote against his proposal no matter what because he didn't read the mails I wrote knowing that he will have no time to read them.

Sorry, but this is just childish. If somebody is angry about not beeing heard when he chooses a way of communication for which it was made clear right from the start that there is no time to maintain it, I have no idea what would not make them angry.

If people want to vote from trump because "Hillary is bad" they don't argue, they search for an excuse.

As said, the wiki is much easier to use, has a much better layout, everything is in one place, the vote is held over there and I have no time to maintain two things at the same time.

Cutting off something that is not essential at the moment because of a lack of time is not an 'attitude' it's called time management.

If people vote against a proposal of which they think it's useful just because they are not fine with using an already established comment system they are not interested in constructive work.

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

Re: [Tagging] Feature Proposal - crossing=marked

2019-05-08 Thread yo paseopor

I don't know why we need a new tag scheme.

I remember my explanation of the question and the adaptation of the
possibilities. I repeat them here:

crossing=no (prohibited)
crossing=yes (most generic)

crossing=traffic_light is with traffic lights. So implies
crossing=controlled.
crossing=controlled is with traffic signs or with police people or similar
(it does not matter the marks because of the laws. Traffic signs are more
important than road marks, and, in conflict you have to obey the traffic
sign not the road mark.)
crossing=uncontrolled but with marks. So one of them implies
crossing=uncontrolled
crossing=unmarked with no marks, with no control, but crossing

If there is a traffic island in the crossing you can tag
traffic_calming=island (you can read in the wiki crossing=island is a  broken
tagging scheme .

And then there are the crossing_ref

zebra is marked but uncontrolled (if it is controlled you can use other
value)
pelican,panda,tigger,toucan,pegasus are controlled with traffic lights
pelican and panda is only with traffic lights .Pelican is the evolution of
panda
tigger means bicycle=designated and toucan means bicycle=yes.
pegasus means horse=designated
 (all of these are from U.K.)

But there is no crossing=zebra or crossing=marked.
I know some editor software and renders are very important for OSM, but
doing whatever you want avoiding community consensus can generate these
problems.
Are you sure we need a new tagging scheme for crossings? Are you sure there
is not other existing way to map whatever you want with the present tagging
scheme?

I don't think so
Health and maps (Salut i mapes)
yopaseopor

On Wed, May 8, 2019 at 10:51 AM marc marc  wrote:

> Le 07.05.19 à 22:57, Nick Bolten a écrit :
> > - crossing=* values are not truly orthogonal and this needs to be
> > addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are
> > not truly orthogonal descriptors.
>
> I suggest that you read the discussion I started in December about
> crossing=zebra because it is the main cause of the current situation.
> Bryan replaced crossing=zebra with crossing=marked in iD but as the
> crossing=zebra problems were not understood, the alternative has exactly
> the same problems as the replaced solution.
> the crossing key is however simple to use except for badly chosen values
> does the passage have a fire? crossing=traffic_signals
> otherwise, does the passage have a marking on the ground?
> crossing=uncontrolled (the work is not perfect because a marking a kind
> of controll)
> otherwise crossing=unmarked
>
> >- There is fragmentation in tag usage for marked crossings between
> > "zebra" and "uncontrolled".
>
> Last year, I have review ~1k crossing=zebra,
> the fragmentation is mainly due to iD
>
> >- crossing=marked is direct and clear about its meaning and use cases.
>
> for now, the "new" iD preset destroys perfectly valid data
> at a frightening rate!
> if someone modifies a pedestrian crossing with a light, iD replaces it
> with crossing=marked, which disrupts the information of the presence of
> the light.
> There is already a tag for the reference of a crossing.
> if the reference is not known, it would be easy to use crossing_ref=yes
> as it is done with many keys.
>
> > - crossing=marked is already in use and supported by various editors,
> > including being the default in iD
>
> a bad preset is not a good usage
>
> Regards,
> Marc
> ___
> 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] Marking temporary traffic organisation change

Le 08.05.19 à 17:00, Mateusz Konieczny a écrit :
> sometimes change is applied for months

> How one may mark that such change is temporary?
> 
> It would be useful for at least two reasons:
> - it would easier to catch roads for retagging after road recontruction 
> completes

use https://wiki.openstreetmap.org/wiki/Key:opening_date
with an estimated completion date of the work.
some qa-tools inform about outdated dates.
however, some mappers confuse this tag with start_date, which would 
probably require additional analysis (quickly correct or better alert 
before uploading when start_date contains a future date instead of 
opening_date)

> - it would be possible to skip such roads in some QA checks -  

I disagree. if change take long enough to be filled in in osm, then it 
is probably very useful that routing inconsistencies are corrected. 
because it is in the case of tmp change that there is most often a need 
for reliable routing instead of using outdated information
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - toll

On Wed, 8 May 2019 at 18:08, 
wrote:

> I have seen that some people already started to reply to this main.
>
> AGAIN: Mails here will not be processed (by me)!!
>

You have pretty much guaranteed that those who find it easier to respond
here will vote
against your proposal because it ignored their suggestions.

There are probably some here who will vote against your proposal even if
they agree with
it 100% because of your attitude.

I'm not attempting to dictate what you do. I'm just informing you that
actions can have
unwanted consequences.  Your choice as to what you do.

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

Re: [Tagging] Feature Proposal - RFC - toll

2019-05-08 Thread Andy Mabbett

On Wed, 8 May 2019 at 17:34, Martin Koppenhoefer  wrote:

>> >  NOTE: All comments attached to this mail WILL NOT BE PROCESSED!
>> > Only comments on the wiki page will be answered and worked on!
>> You do realise that the wiki is supposed to document current best
>> practice, and can not dictate it?

> You did notice she has linked to a proposal page, which is a space in the 
> wiki explicitly set up to discuss new ideas?

Yes, I did. My point stands.

Or did we change things, and agree that the Wiki is now the de jure
record of authority?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - toll

2019-05-08 Thread Andy Mabbett

On Wed, 8 May 2019 at 17:26, marc marc  wrote:
>
> Le 08.05.19 à 18:00, Andy Mabbett a écrit :
> > On Wed, 8 May 2019 at 14:50,
> >  wrote:
> >>
> >> I
> >
> > Who is "I"? is "wiki_openstreetmap_org.5.kuru" really your name?

> the author of the wiki page :TBKMrt

If the OP wishes to be known (only) as TBKMrt, then that is now they
should sign their email.

> it certainly doesn't matter because the important thing is talk
> about the idea and not the person nor his nickname

I didn't say anything about wanting to discuss the person; but I do
not think it unreasonable to wan't to know /with whom/ I am discussing
the idea.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - Top_up (fifth revision)

Le 08.05.19 à 18:25, egil a écrit :
> https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up

your proposal seems to be affected by a community division on 2 topics:

- osm should it contain everything that a store sells ? probably not, 
but the limit is difficult to establish (we add the type of fuel sell at 
petrol stations)

- how to fill in a yes/no list. in recent proposals, we see some who 
refuse a collection of value in one tag and promote several tags with 
yes/no and some others who refuse a tag list with yes/no and want to use 
one key with a lot of ";" but for which no schema is currently provided 
to list a no (on the namespace page, some have mentioned the prefixes 
"un" (like unmarked) the -, the no- ! but there is a general logic 
missing... this is perhaps an opportunity to launch a discussion on this 
subject to avoid that many proposals are polluted by the same problem.

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

[Tagging] Feature Proposal - RFC - toll

2019-05-08 Thread wiki_openstreetmap_org . 5 . kuru

I have seen that some people already started to reply to this main.

 

AGAIN: Mails here will not be processed (by me)!!

 

It's not about dictating something or cutting people off, but about my lack of time to maintain the wiki and the mailing list.

In my opinion the mailing list is everything but well-aranged, has no easy to use layout, no logic line-up of comments, etc. Because I HAVE to drop one, I'll drop the mailing list.

 

If you want to add a comment, you are more than welcome to add it to the OSM wiki.

If you want to maintain the mailing list and copy information, do it! I'm more than happy for any helping hand.

All comments and new ideas are welcome. I just don't have the time to go out to grab all of them from different places.

 

If you want to leave a comment directly, please do that here: https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/toll

 

 


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

Re: [Tagging] Feature Proposal - RFC - toll

Am Mi., 8. Mai 2019 um 18:02 Uhr schrieb Andy Mabbett <
a...@pigsonthewing.org.uk>:

> On Wed, 8 May 2019 at 14:50,
>  wrote:
> >
> > I
>
> Who is "I"? is "wiki_openstreetmap_org.5.kuru" really your name?
>

There is no requirement to tell your name in order to contribute to a
discussion here.
I agree it looks more human if the person signs their post with a name, but
if they don't it shouldn't be a reason for publicly raising your eyebrows.
Or do you suspect  "wiki_openstreetmap_org.5.kuru" is not a person?

> >  NOTE: All comments attached to this mail WILL NOT BE PROCESSED!
> > Only comments on the wiki page will be answered and worked on!
> You do realise that the wiki is supposed to document current best
> practice, and can not dictate it?

You did notice she has linked to a proposal page, which is a space in the
wiki explicitly set up to discuss new ideas?

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

Re: [Tagging] Feature Proposal - RFC - toll

Le 08.05.19 à 18:00, Andy Mabbett a écrit :
> On Wed, 8 May 2019 at 14:50,
>  wrote:
>>
>> I
> 
> Who is "I"? is "wiki_openstreetmap_org.5.kuru" really your name?

spamgourmet is anti-spam feature that allow you to add keyword prefix. 
you can deduce that the account is kuru (but there is nothing to prevent 
you from creating several accounts). the best way is to look at the 
author of the wiki page : TBKMrt
it certainly doesn't matter because the important thing is talk
about the idea and not the person nor his nickname
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - Top_up (fifth revision)

2019-05-08 Thread egil

https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up

Cheers

pangoSE


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

Re: [Tagging] Feature Proposal - RFC - toll

2019-05-08 Thread Andy Mabbett

On Wed, 8 May 2019 at 14:50,
 wrote:
>
> I

Who is "I"? is "wiki_openstreetmap_org.5.kuru" really your name?

>  NOTE: All comments attached to this mail WILL NOT BE PROCESSED!
> Only comments on the wiki page will be answered and worked on!

You do realise that the wiki is supposed to document current best
practice, and can not dictate it?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Feature Proposal - RFC - toll

Le 08.05.19 à 15:50, wiki_openstreetmap_org.5.k...@spamgourmet.com a écrit :
> I would like to hear your thoughts and comments here: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/toll

- I see no need to specify that a country's roads are in that country.
- I have always considered strange a vignette is considered as a toll.
- the toll detail would better be added on the highest entity containing 
the type of toll concerned (e.g. on the Swiss relationship for the Swiss 
vignette or on a Brittany relationship to say that there is no payment 
in Brittany) rather than duplicate the same information many times.
- if you want to add details of the fee, use the fee key
- to inform if it is with a ticket or rfid, used a dedicated key, 
especially since in France, both are possible on the same routes.
it also allow to use this key for other feature (like paking fee)
- type in toll:type is a no meaning key. it's better to use a key with a 
"self-meaning" (like calculation_basis) but from your examples, it seems 
that all vignettes are based on a duration, so what's the added value to 
duplicate vignette with time ? and to say that the payment of a tunnel 
is based on distance seems wrong (it's a fixed price for the tunnel,
you can't paid less or more than the fixed price for a kind of vehicule)
- toll:type=time gives me the impression that the payment is made 
according to the time you use the road (if you drive fast, you pay less 
than the one who drives slowly). out of the description speaks of a 
subscription for a certain duration. it is not intuitive.
again a lot of roads have one-shoot and subscription payement.

> NOTE: All comments attached to this mail WILL NOT BE PROCESSED!

so nice ! all not-processed comments may result in a vote=no
or worse in difficulties of use in the future because a detected
problem has not been solved
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Marking temporary traffic organisation change

Sometimes traffic organization changes for some time - road becomes temporarily 
oneway,
or oneway road becomes accessible in both direction.

Obviously short term traffic organisation changes (for hours/days) are 
generally not
worth mapping, though one may use oneway:conditional / access:conditional for 
that.

But sometimes change is applied for months or longer, as it is related to 
closure of road.

For example road around
https://www.openstreetmap.org/?mlat=50.04484=19.94562#map=19/50.04484/19.94562
 

are closed for reconstruction, what is covered by highway=construction.

But there are also other changes
https://www.openstreetmap.org/way/25029841#map=19/50.04537/19.94788 

become oneway=no.

How one may mark that such change is temporary?

It would be useful for at least two reasons:
- it would easier to catch roads for retagging after road recontruction 
completes
- it would be possible to skip such roads in some QA checks - for example that 
road has
cycleway=opposie_lane, oneway:bicycle=no with oneway=no what would usually 
indicate
some mistake - but here it is a result of temporary change so validators should 
not complain

Is there some existing tag for that? If not - what would be a good name for 
that?
temporary_traffic_organisation=yes is awful
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - toll


8 May 2019, 15:50 by wiki_openstreetmap_org.5.k...@spamgourmet.com:

> I would like to hear your thoughts and comments here: > 
> https://wiki.openstreetmap.org/wiki/Proposed_features/toll 
> >  
>
I see no good reason to turn simple boolean tag (toll=yes/ toll=no are 98,98% 
of all values[1]) into something
highly complicated. It would work better as a new tag

 Also, what is the point of tagging that road located in Italy is an Italian 
toll road?

[1] https://taginfo.openstreetmap.org/keys/toll#values 


>  NOTE: All comments attached to this mail WILL NOT BE PROCESSED! Only 
> comments on the wiki page will be answered and worked on!
>
It is your choice but it means that you are likely to miss some comments, and 
encounter
them as explanation of "no" votes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

Reminder: voting is underway to approve the tag  camp_site=camp_pitch
since May 1st so it  will continue for the next week till May 14th
https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch

Please check out the proposal page and add your comments or votes:
https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting

On 5/1/19, Joseph Eisenberg  wrote:
> I believe the discussion about the tag camp_site=camp_pitch is now
> complete here. Also see the talk page:
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/camp_site_pitch
>
> You can now vote to approve or reject this tag. See:
> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
>
> Description of camp_site=camp_pitch:
> "An tent or caravan pitch location within a camp site"
>
> This proposal provides a way to tag individual pitches within a
> campground or caravan site. A "camp pitch" in this context is the free
> space used to place a tent or or caravan within a tourism=camp_site or
> tourism=caravan_site area. Usually only one caravan is permitted in an
> individual pitch, but more than 1 tent may be allowed on a single
> pitch in some cases."
>
> Please read the proposal and vote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch#Voting
>

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

[Tagging] Feature Proposal - RFC - toll

2019-05-08 Thread wiki_openstreetmap_org . 5 . kuru

I would like to hear your thoughts and comments here: https://wiki.openstreetmap.org/wiki/Proposed_features/toll

 

 NOTE: All comments attached to this mail WILL NOT BE PROCESSED! Only comments on the wiki page will be answered and worked on!


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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

Le 08.05.19 à 15:09, Paul Allen a écrit :
> On Wed, 8 May 2019 at 13:44, marc marc wrote:
> 
> Le 08.05.19 à 13:51, Paul Allen a écrit :
>  > pelican crossings <...> didn't render (no traffic lights shown)
> 
> you get it with crossing=traffic_lights crossing_ref=pelican
> 
> I had those, together with a few other things.  At the time I did it, 
> that wasn't how the wiki said to
> do it, but other parts of the wiki implied those were also acceptable.
> 
> I also had (and still have) highway=traffic_signals

the main (render) issue is that both are different things (one 
represents a traffic lights, which may or may not be associated with a 
pedestrian crossing, the other represents a pedestrian crossing managed 
by a traffic_lights that may be in the same place or several metres 
before) but whose rendering is identical.
but that's a bug/improvement needed in the render's style,
not a tagging issue.

> Dunno if that's right or wrong

it's not true or wrong, it's a historic shortcut that it's probably time 
to depreciate in order to focus each tag on a specific meaning

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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

On Wed, 8 May 2019 at 13:44, marc marc  wrote:

> Le 08.05.19 à 13:51, Paul Allen a écrit :
> > pelican crossings
> > it didn't render (no traffic lights shown)
>
> you get it with crossing=traffic_lights crossing_ref=pelican
>

I had those, together with a few other things.  At the time I did it, that
wasn't how the wiki said to
do it, but other parts of the wiki implied those were also acceptable.

I also had (and still have) highway=traffic_signals and
traffic_signals=pedestrian_crossing.  Dunno
if that's right or wrong - I went through many tries before I hit a
combination that worked, and didn't
want to go through even more tries to find out if any of those were
unnecessary.

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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

Le 08.05.19 à 13:51, Paul Allen a écrit :
> pelican crossings
> it didn't render (no traffic lights shown)

you get it with crossing=traffic_lights crossing_ref=pelican
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

On Wed, 8 May 2019 at 10:42, Philip Barnes  wrote:

>
> Uncontrolled crossings are by far the most common. They are wherever there
> are drop kerbs, which in my town just about every road junction.
>

Same around here.  Most of them have tactile paving too.  Which I suppose
could be considered as
marking, because it's a different colour to the ordinary paving (but
sometimes the difference is
subtle).  For the pedestrian it's obviously marked (even if there's no
colour change you can see
the drop kerb and feel the bumps) but around here most motorists seem
blissfully unaware that
it's there.

A problem I found way, way back when I looked at how somebody had mapped
the few pelican
crossings around here is that, if you did it according to the wiki, it
didn't render (no traffic lights
shown). Yes, from the perspective of the pedestrian it's a crossing but
from the perspective of
the motorist it's a set of traffic lights.That may havechanged, but I
found a combination of tags
that sort of made sense (and could be interpreted as complying with the
wiki, maybe) and
actually rendered as traffic lights.

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

Re: [Tagging] Status of oneway=cw oneway=ccw

2019-05-08 Thread Peter Elderson

I don't think that oneway=yes on a hiking route causes confusion. It
doesn't in real life, so why should it in OSM? Even if there were ways that
a pedestrian cannot legally walk against the direction, routers/navigators
always check all individual ways , so there is no risk of steering
pedestrians over a legal restriction.

I'm perfectly fine with oneway=yes, and determining the direction from the
order of ways in the relation.
Remains the problem that the order in the relations is unreliable, many are
unsortable, so in many cases the direction cannot be determined.

Vr gr Peter Elderson


Op wo 8 mei 2019 om 12:04 schreef s8evq :

> Hopeful to come to a conclusion, I would like to propose to edit the Wiki
> with the following:
>
>
> Current text on page route=hiking:
> oneway  yes/no/cw/ccw   (optional) Use oneway=yes to indicate that the
> route is to be walked in only one direction, according to the signposts on
> the ground
> proposal: It might be useful to indicate if the route is marked in the
> clockwise or counterclockwise direction, i.e. oneway=cw or oneway=ccw.
>
> Changing to:
> signed_direction=yes (optional) Use signed_direction=yes to indicate that
> the route is to be walked in only one direction, according to the signposts
> on the ground. The ways within the relation should be ordered, as they are
> used to determine the direction of the signposts. It's prefered to not use
> oneway=yes anymore, as it could cause confusion with oneway=* as a legal
> restriction. (as discussed on the tagging mailing list (insert link))
>
> This changes could also be applied on route=foot and route=bicycle
>
> Comments?
>
>
> On Sun, 5 May 2019 12:44:10 +0100, ael via Tagging <
> tagging@openstreetmap.org> wrote:
>
> > On Sun, May 05, 2019 at 07:38:45AM +0200, s8evq wrote:
> > > Another attempt at summarizing the current situation:
> > >
> > > How should we included the direction?
> > >
> > > - Andy Townsend suggested "Explicit start and/or finish nodes?", but
> I'm afraid that's not enough to deduce the direction of complex hiking
> routes like this one: https://www.openstreetmap.org/relation/9535700
> > >
> > > - Using the sorted order of the relation? A lot of criticism on this
> method. It's fragile and could easily break when newbies edit. On the other
> hand, it's the only solution we have. Sarah remarked: "An unsorted route is
> not wrong, it's only less precise. Maps can show it without issues
> including waymarkedtrails. It just can't give you some advanced features."
> >
> > Just a thought, but with minimal background knowledge:-
> >
> > Why not add a boolean tag, something like "sorted=yes" which editors
> > will always turn off unless the editor (or user) can verify that the
> > sorting has been maintained? Provided that there is a well defined order
> > relation, that should be something that editor could automate?
> >
> > ael
> >
> >
> > ___
> > 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 (etc) for crossing:signals

In the United States an unmarked crosswalk is usually legally identical to
a crosswalk marked with painted stripes. Vehicle drivers and bike riders
must stop for a pedestrian in a crosswalk whether there is paint or not. In
general, all places where there is a sidewalk on both sides of an
intersection are an unmarked crosswalk, even if there is not a dropped kerb
(curb). I believe this is a general rule, but it is certainly true in  the
western States.

On Wed, May 8, 2019 at 6:37 PM Mateusz Konieczny 
wrote:

> 8 May 2019, 01:30 by nbol...@gmail.com:
>
> - Unmarked crossings are abstract "fictions" representing where an
> individual might cross the street, marked crossings are identifiable from
> imagery.
> - Because unmarked crossings are "fictions", they are only suggested
> places to cross, according to the mapper. In contrast, marked crossings are
> "official".
>
> Just because mapping something requires real survey rather than mapping
> from aerial imagery is
> not making it fictional or unofficial.
>
> - Marked crossings are one of the few pedestrian spaces that can be
> straightforwardly considered as a linear feature: it connects spaces across
> a street.
>
> Typical footway is also linear.
>
> - Marked crossings tend to have legal implications, as you note.
>
> Unmarked crossings may also have legal implications (for example in
> Poland).
>
> ___
> 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] Status of oneway=cw oneway=ccw

2019-05-08 Thread s8evq

Hopeful to come to a conclusion, I would like to propose to edit the Wiki with 
the following:

Current text on page route=hiking:
oneway  yes/no/cw/ccw   (optional) Use oneway=yes to indicate that the route is 
to be walked in only one direction, according to the signposts on the ground
proposal: It might be useful to indicate if the route is marked in the 
clockwise or counterclockwise direction, i.e. oneway=cw or oneway=ccw. 

Changing to:
signed_direction=yes (optional) Use signed_direction=yes to indicate that the 
route is to be walked in only one direction, according to the signposts on the 
ground. The ways within the relation should be ordered, as they are used to 
determine the direction of the signposts. It's prefered to not use oneway=yes 
anymore, as it could cause confusion with oneway=* as a legal restriction. (as 
discussed on the tagging mailing list (insert link))

This changes could also be applied on route=foot and route=bicycle

Comments?

On Sun, 5 May 2019 12:44:10 +0100, ael via Tagging  
wrote:

> On Sun, May 05, 2019 at 07:38:45AM +0200, s8evq wrote:
> > Another attempt at summarizing the current situation:
> > 
> > How should we included the direction?
> > 
> > - Andy Townsend suggested "Explicit start and/or finish nodes?", but I'm 
> > afraid that's not enough to deduce the direction of complex hiking routes 
> > like this one: https://www.openstreetmap.org/relation/9535700
> > 
> > - Using the sorted order of the relation? A lot of criticism on this 
> > method. It's fragile and could easily break when newbies edit. On the other 
> > hand, it's the only solution we have. Sarah remarked: "An unsorted route is 
> > not wrong, it's only less precise. Maps can show it without issues 
> > including waymarkedtrails. It just can't give you some advanced features."
> 
> Just a thought, but with minimal background knowledge:-
> 
> Why not add a boolean tag, something like "sorted=yes" which editors
> will always turn off unless the editor (or user) can verify that the
> sorting has been maintained? Provided that there is a well defined order
> relation, that should be something that editor could automate?
> 
> ael
> 
> 
> ___
> 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 (etc) for crossing:signals

2019-05-08 Thread Philip Barnes

On Wednesday, 8 May 2019, marc marc wrote:
> Le 08.05.19 à 01:30, Nick Bolten a écrit :
> > Unmarked crossings are abstract "fictions"
> 
> beware of caricature :
> - unmarked pedestrian crossings with lowered kerb for wheelchairs
> - unmarked pedestrian crossing that connects a sidewalk on each side of 
> the crossing
> 
> just because you've never seen one before doesn't mean it's a fiction.
>
Absolutely Marc.

Uncontrolled crossings are by far the most common. They are wherever there are 
drop kerbs, which in my town just about every road junction. 

Needed for wheelchairs, pushchairs, people with limited mobility and me 
occasionally when I need to get my wheeled suitcase to the station.

It would be pointless to provide traffic lights in residential areas with 
minimal traffic.

Phil (trigpoint) 

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

8 May 2019, 01:30 by nbol...@gmail.com:

> - Unmarked crossings are abstract "fictions" representing where an individual 
> might cross the street, marked crossings are identifiable from imagery.
> - Because unmarked crossings are "fictions", they are only suggested places 
> to cross, according to the mapper. In contrast, marked crossings are 
> "official".
>
Just because mapping something requires real survey rather than mapping from 
aerial imagery is
not making it fictional or unofficial.

> - Marked crossings are one of the few pedestrian spaces that can be 
> straightforwardly considered as a linear feature: it connects spaces across a 
> street.
>
Typical footway is also linear.

> - Marked crossings tend to have legal implications, as you note.
>
Unmarked crossings may also have legal implications (for example in Poland).

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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

Le 08.05.19 à 10:30, Martin Koppenhoefer a écrit :
> „uncontrolled“, as it is a misnomer.

indeed, but what could be a better value ?
crossing=not_controlled_by_a_traffic_signal is a little long
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

Le 08.05.19 à 01:30, Nick Bolten a écrit :
> Unmarked crossings are abstract "fictions"

beware of caricature :
- unmarked pedestrian crossings with lowered kerb for wheelchairs
- unmarked pedestrian crossing that connects a sidewalk on each side of 
the crossing

just because you've never seen one before doesn't mean it's a fiction.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

Le 08.05.19 à 00:06, Tobias Knerr a écrit :
> We need a tag for the_type_  of the markings anyway
>  (as different patterns for marked crossings can have
> entirely different legal meanings in some jurisdictions), and we can use
> that same tag for presence/absence by also allowing yes/no values.

and we already have it : crossing_ref
and indeed i agree that adding yes/no to current value is a good idea.
the name of the key is not perfect, but it has the advantage of 
existing. changing all the keys and value at once seems unrealistic. it 
seems preferable to me to take out the type of marking of the crossing 
key in favour of the crossing_ref key, it is not a perfect change, but 
it was already a huge step forward. we discussed it on the talk-fr list 
last year, no one opposed the mecanical edit. on the contrary only one 
contributor would have wanted us to go further and change all at once.
to big to success.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals

Le 07.05.19 à 23:08, Nick Bolten a écrit :
> What do crossing=uncontrolled/unmarked/traffic_signals say about these 
> scenarios?

> crossing=uncontrolled:

ground marking but not traffic signal

>    - signalization for pedestrians is undefined

sorry I didn't understand what you mean.
crossing describe the crossing.
if you want to describe a traffic sign, check traffic_sign key

>    - markings are implied

I didn't see where you see this "implied"

> crossing=unmarked:
>    - signalization for pedestrians is undefined

the color of the nearest building is not indicated either,
fortunately because it is not the role of this key.
if you want a traffic sign info, check traffic_sign key

>    - signalization for traffic is undefined

again...


> crossing=traffic_signals
>    - markings are undefined

again... (check crossing_ref)

> So, you can see the problem: the values are describing completely 
> different things and the rest is ambiguous.

the current situation is far from perfect, but either you have not 
understood the current tags, or you are blackening the current situation 
to promote your proposal to change everything, which seems unrealistic.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

Le 07.05.19 à 22:57, Nick Bolten a écrit :
> - crossing=* values are not truly orthogonal and this needs to be 
> addressed. e.g., "uncontrolled", "traffic_signals", and "unmarked" are 
> not truly orthogonal descriptors.

I suggest that you read the discussion I started in December about 
crossing=zebra because it is the main cause of the current situation.
Bryan replaced crossing=zebra with crossing=marked in iD but as the 
crossing=zebra problems were not understood, the alternative has exactly 
the same problems as the replaced solution.
the crossing key is however simple to use except for badly chosen values
does the passage have a fire? crossing=traffic_signals
otherwise, does the passage have a marking on the ground? 
crossing=uncontrolled (the work is not perfect because a marking a kind 
of controll)
otherwise crossing=unmarked

>    - There is fragmentation in tag usage for marked crossings between 
> "zebra" and "uncontrolled".

Last year, I have review ~1k crossing=zebra,
the fragmentation is mainly due to iD

>    - crossing=marked is direct and clear about its meaning and use cases.

for now, the "new" iD preset destroys perfectly valid data
at a frightening rate!
if someone modifies a pedestrian crossing with a light, iD replaces it 
with crossing=marked, which disrupts the information of the presence of 
the light.
There is already a tag for the reference of a crossing.
if the reference is not known, it would be easy to use crossing_ref=yes 
as it is done with many keys.

> - crossing=marked is already in use and supported by various editors, 
> including being the default in iD

a bad preset is not a good usage

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

Re: [Tagging] Feature Proposal - RFC (etc) for crossing:signals