Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I'd still classify that as crossing=traffic_signals.

Ah, now I'm super confused. I would've sworn that you'd recommend mapping
that as uncontrolled.

> The real world is too messy.  Can we map a fictional world instead?

People actually love doing that:
https://www.pcinvasion.com/wp-content/uploads/2016/03/cities-skylines-canal.jpg

I'd like to harness those people by writing some accessible mapping apps
and get good pedestrian tags, but I don't want to add bad crossing tags...



On Fri, May 10, 2019 at 5:02 PM Paul Allen  wrote:

> On Sat, 11 May 2019 at 00:44, Nick Bolten  wrote:
>
>> Having trouble finding a good picture (I'll keep looking), but there are
>> mid-block crossings where pedestrians can press an APS to turn on traffic
>> warning lights - usually yellow in the US. Some of these crossings do not
>> immediately give you those traffic warnings lights, but instead are tied to
>> nearby traffic and turn on after a delay. When the lights turn on, there is
>> some form of a pedestrian signal: sometimes the APS talks to you, sometimes
>> there's a visual cue: lights turn on or a "walk" sign enables.
>>
>
> Ugh!
>
> I'd still classify that as crossing=traffic_signals.  Because as well as
> controlling pedestrians it
> does signal to traffic.  An advisory signal rather than a controlling
> signal, but still a signal.  That's
> not like the Belisha Beacon on a Zebra that flashes whether or not there
> are any pedestrians
> there.
>
> That's not quite like the flashing amber signal near school crossings
> which are supervised by
> a crossing guard: the guard turns them on at the start of the shift and
> turns them off at the
> end of the shift, there may be nobody crossing from the time the driver
> sees them to the time
> the driver has cleared the crossing.  I can see an argument for including
> those if we include yours,
> but I doubt many people in the UK think of them as traffic lights.
>
> The real world is too messy.  Can we map a fictional world instead?
>
> --
> Paul
>
> ___
> 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

[Paul Allen]

On Sat, 11 May 2019 at 00:44, Nick Bolten  wrote:

> Having trouble finding a good picture (I'll keep looking), but there are
> mid-block crossings where pedestrians can press an APS to turn on traffic
> warning lights - usually yellow in the US. Some of these crossings do not
> immediately give you those traffic warnings lights, but instead are tied to
> nearby traffic and turn on after a delay. When the lights turn on, there is
> some form of a pedestrian signal: sometimes the APS talks to you, sometimes
> there's a visual cue: lights turn on or a "walk" sign enables.
>

Ugh!

I'd still classify that as crossing=traffic_signals.  Because as well as
controlling pedestrians it
does signal to traffic.  An advisory signal rather than a controlling
signal, but still a signal.  That's
not like the Belisha Beacon on a Zebra that flashes whether or not there
are any pedestrians
there.

That's not quite like the flashing amber signal near school crossings which
are supervised by
a crossing guard: the guard turns them on at the start of the shift and
turns them off at the
end of the shift, there may be nobody crossing from the time the driver
sees them to the time
the driver has cleared the crossing.  I can see an argument for including
those if we include yours,
but I doubt many people in the UK think of them as traffic lights.

The real world is too messy.  Can we map a fictional world instead?

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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> I would not expect to see something like that, in any of its regional
variations (green walking person/red stationary person in much of Europe)
without related lights controlling traffic.

So, in the case of a pedestrian warning beacon, which does not control
traffic in the cases you've mentioned, how would you tag the crossing?
crossing=uncontrolled? Even thought it has pedestrian-facing lights *and*
lights intended to warn traffic about pedestrians?

There's another user in this thread who thinks the polar opposite and that
the lights directed at traffic are irrelevant. Who is correct? What does
the tag mean?

This is making me think that my other proposal should be revised so as to
separate out pedestrian signals from street traffic signals entirely.
Something like crossing:pedestrian_signals=yes/no/(type) and
crossing:traffic_signals=yes/no/(type)

> Not necessarily.  Most countries there probably is something, if only
tactile paving for the blind.

I think I miscommunicated - I'm referring to that intersection in the
picture only, where the crossings are marked with the ladder pattern.

>> If we tag that as crossing=traffic_signals, have we correctly and
consistently communicated all of that information?
> Maybe.  People are capable of misinterpreting anything.

Of course, but that's the same regardless of whether a tagging schema is
awful or ideal.

Earlier, the necessary conditions for crossing=traffic_signals were solely
(1) signals that control pedestrians and (2) signals that control street
traffic. But now, at this intersection, crossing=traffic_signals implies
markings? This is a contradiction. It is simply not possible for both to be
true. So you can see my dilemma in trying to use such a tag.

Keep in mind, all I want to describe is whether a crossing has markings and
whether it has pedestrian signals. That seems like something just about any
person on the street should be able to answer, but the schema makes it
difficult to tag.

> I would say that both pedestrians and traffic have to be controlled.
Controlled pedestrians and
uncontrolled traffic is insane.  Controlled traffic and uncontrolled
pedestrians is traffic lights.

Not according to most definitions of "controlled", in terms of traffic
lights. A stop sign is a form of traffic control. Also, someone in the
other thread claimed that dropped curbs were a control. Someone in this
thread says a marked crossing is a control. Nobody agrees on what a control
is in OpenStreetMap, so how can we ever trust data for "uncontrolled"? I'd
guess that almost nobody is using it for anything other than a delay on a
router (car might have to stop) or some generic visualizations of feature
density. They can't, not reliably.

> The pedestrian-facing lights and vehicle-facing lights don't even have to
be on the same pole, but they should be positioned such as to control the
pedestrians and traffic at a crossing and be operated in synchrony by the
same controller.  Together they constitute a single crossing.

I wholeheartedly disagree. A crossing is not the signals. A crossing is
where pedestrians cross the street. A crossing can *have* signalization:
signals are a property of a crossing. This is similar to how a crossing is
not an island and why crossing=island was a bad idea.

> Oh, and you can have two independent crossings within a few yards of each
other which handle one direction of traffic flow on a road with several
lanes (...)

As footways, I would map this as three elements: all are footway=crossing,
the central island is crossing:island=yes, the other two are... well, I
don't know, really. That's what I'm asking questions about. Maybe
crossing=traffic_signals.

On Fri, May 10, 2019 at 4:31 PM Paul Allen  wrote:

> On Fri, 10 May 2019 at 23:59, Nick Bolten  wrote:
>
>> >> - A crossing might be marked on the ground
>>
>> > Are there traffic signals which control BOTH traffic and pedestrians?
>> If so,
>> > crossing=traffic_signals.   If there are JUST road markings, no
>> crossing=traffic_signals.
>>
>> I interpret this to mean: the necessary condition for using
>> crossing=traffic_signals is that there are signals controlling both traffic
>> and pedestrians. If only one or the other, it is not a
>> crossing=traffic_signals.
>>
>
> That's how I intended it.  If it only controls traffic then it's ordinary
> traffic lights (regardless of
> whether people use it as a place to cross).  If it only controls
> pedestrians it's insane: "Yep,
> you can cross now, don't worry about those cars because there's nothing I
> can do to stop
> them."
>
>
> >> - A crossing might have lighted signals for pedestrians to cross
>>
>> > Define what you mean by lighted signals.  If you mean a Belisha Beacon
>> or something else that WARNS motorists that pedestrians cross here but does
>> NOT control traffic and pedestrians then it's not
>> crossing=traffic_signals.  A warning light is not a traffic signal.
>>
>> In this case, I was thinking of a specific "walk/do not 

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

> you have still to show us a crossing with traffic lights only for
pedestrians :)

Having trouble finding a good picture (I'll keep looking), but there are
mid-block crossings where pedestrians can press an APS to turn on traffic
warning lights - usually yellow in the US. Some of these crossings do not
immediately give you those traffic warnings lights, but instead are tied to
nearby traffic and turn on after a delay. When the lights turn on, there is
some form of a pedestrian signal: sometimes the APS talks to you, sometimes
there's a visual cue: lights turn on or a "walk" sign enables.

Whether warning lights count as a "traffic signal" seems to be an issue of
contention. There's a theme!

> Crossing refers to a pedestrian (or bicycle) crossing, when there are
only traffic lights for the traffic on the road, but not for the crossing
traffic then there won’t be a crossing tag.

I think I'm confused. crossing=unmarked and crossing=uncontrolled would
both apply in that situation, right?

On Fri, May 10, 2019 at 4:24 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 11. May 2019, at 00:57, Nick Bolten  wrote:
> >
> > If only one or the other, it is not a crossing=traffic_signals.
>
>
> you have still to show us a crossing with traffic lights only for
> pedestrians :)
>
> Crossing refers to a pedestrian (or bicycle) crossing, when there are only
> traffic lights for the traffic on the road, but not for the crossing
> traffic then there won’t be a crossing tag.
>
>
> 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] Feature Proposal - crossing=marked

[Nick Bolten]

> If you search traffic light you will see the same thing, not any strange
light in relation with traffic itself.
https://www.google.com/search?q=traffic+light=lnms=isch=X=0ahUKEwj3vf-XqJHiAhWhzoUKHYr5D3kQ_AUIDigB=1280=891
> (...)
> There is no ambiguosity: point is where is the feature, where the feature
acts.

Per Paul's explanation, crossing=traffic_signals implies two traffic
lights: one for pedestrians, one for traffic. So it's not actually solely
oriented towards the feature.

If you disagree with Paul's definition, that would not be uncommon: nobody
seems to agree on what crossing=traffic_signals or crossing=uncontrolled
means.

> Why you suppose marked is better than uncontrolled? (...)

I have explained it in the wiki, but am happy to expand on the proposal if
you think it does an inadequate job.

I'm skipping a few of your replies because I believe I can address them in
the other sections. Please remind me if you feel I've ignored something
entirely.

> Tagging schemes with yes/no binary values makes more complex the
scheme... (...)

While this proposal currently states a binary (yes/no), I'm open to having
more values. The goal is for the crossing tag to have values that are all
in the same category, because right now they describe several different
things incompletely. This is in addition to being poorly understood by just
about everyone. Because the vast majority of existing crossing tags are
regarding markings, I thought this would be the natural "primary" value.

Imagine you were writing a software application that asked a pedestrian one
or more questions about a crossing. Behind the scenes, you edit
OpenStreetMap to add a crossing=* tag. Think something like StreetComplete,
which is a very cool app. What questions do you ask? It's a hard problem to
solve because the tag values are *bad*.

> That is a traffic light for pedestrian. Why do you want any mark if you
have a traffic light to control it? In my country...that situation does not
exist.

The situation exists in my country, so how do you map it? What tags?

> That is crossing=uncontrolled, because there is no control about the
footway crossing.

Stop signs are a control, but they're for street traffic.

> Well , it is crossing=unmarked because there is no marks on the corssing
(...)

The stop sign is related to the crossing, as it indicates that traffic has
to stop there. Depending on the country, this has right-of-way implications
- the exact same ones where the term "uncontrolled" comes from.

> Well, it will be a crossing=unmarked, because there is no mark on the
ground (...)

In my area, that is a valid place to cross and pedestrians have the
right-of-way.

> WTF? For what do you need walk/don't walk parameter if there is no
traffic light with???

A mid-block crossing that has pedestrian signals and only warning lights
for cars. Other mappers have told me that warning signals are not traffic
lights, per the definition of crossing=traffic_signals.

> Are you sure an administration will put an only car traffic light...with
a pedestrian crossing in but with no pedestrian traffic light? How bizarre
the world is.

I'm describing a crossing like this:
https://www.colchestervt.gov/ImageRepository/Document?documentID=185. There
are marked crossings on the ground.

> Is there any unsyncronized crossing with the same traffic lights inside
the crossing? Which drunken monkey design these crossings? How many people
die in ?

I'm describing the situation in the picture above but with no ground
markings.

> Error: Pedestrian has ALWAYS the right of way in a crossing with marks of
crossings (crossing=uncontrolled if there is no traffic_signal)

In every country on earth? In all situations that lack a signal?

> No. Control is something that sometimes says you if you are allowed or
not to cross. A dropped curb says you always the same: nothing.

So you disagree with the other mappers who said as much on this mailing
list. That's my point: nobody seems to agree on what these tags mean.

Best,

Nick


On Fri, May 10, 2019 at 2:20 PM yo paseopor  wrote:

> No, don't be innocent
>
> If you search traffic light you will see the same thing, not any strange
> light in relation with traffic itself.
>
> https://www.google.com/search?q=traffic+light=lnms=isch=X=0ahUKEwj3vf-XqJHiAhWhzoUKHYr5D3kQ_AUIDigB=1280=891
> https://en.wikipedia.org/wiki/Traffic_light.
> If you make a specific micromapping you will not have problems. Otherwise
> you can't ask for detailed information if the mapping is not as detailed.
>
> If you see a traffic light in a footway is for the footway, not the
> highway.
> If you see a traffic light in a cycleway is for the cycleway, not the
> highway.
>
> There is no ambiguosity: point is where is the feature, where the feature
> acts.
>
> Why you suppose marked is better than uncontrolled? Do you suppose that
> new mapper doesn't know for which kind of marks are you talk about? Marked
> with? Traffic sign? Traffic light? other lights in 

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Fri, 10 May 2019 at 23:59, Nick Bolten  wrote:

> >> - A crossing might be marked on the ground
>
> > Are there traffic signals which control BOTH traffic and pedestrians?
> If so,
> > crossing=traffic_signals.   If there are JUST road markings, no
> crossing=traffic_signals.
>
> I interpret this to mean: the necessary condition for using
> crossing=traffic_signals is that there are signals controlling both traffic
> and pedestrians. If only one or the other, it is not a
> crossing=traffic_signals.
>

That's how I intended it.  If it only controls traffic then it's ordinary
traffic lights (regardless of
whether people use it as a place to cross).  If it only controls
pedestrians it's insane: "Yep,
you can cross now, don't worry about those cars because there's nothing I
can do to stop
them."


>> - A crossing might have lighted signals for pedestrians to cross
>
> > Define what you mean by lighted signals.  If you mean a Belisha Beacon
> or something else that WARNS motorists that pedestrians cross here but does
> NOT control traffic and pedestrians then it's not
> crossing=traffic_signals.  A warning light is not a traffic signal.
>
> In this case, I was thinking of a specific "walk/do not walk" lighted
> signal.
>

I would not expect to see something like that, in any of its regional
variations (green walking
person/red stationary person in much of Europe) without related lights
controlling traffic.

>
> > That's crossing=traffic_signals IF it also controls pedestrians.
> Walk/Don't Walk ot Red/Green figures or whatever.  Otherwise it's just
> traffic lights.  Even if people can cross there, it's still just traffic
> lights because the crossing (by people) Isn't controlled, just the traffic
> is.  Traffic has to stop when the lights tell them, the pedestrians take
> their chances and are uncontrolled.
>
> I take this to mean that the signals do not need to be colocated in order
> to tag crossing=traffic_signals, such as in this scenario:
> https://www.colchestervt.gov/ImageRepository/Document?documentID=185.
>
> - There are markings on the ground
>

Not necessarily.  Most countries there probably is something, if only
tactile paving for the blind.

- There are pedestrian-facing signals
> - There are traffic signals at the intersection controlling traffic
>

Those are the two important bits.  Along with the fact that they are
operated by a single
controller.  No point to them if they operate independently.  The whole
idea is that they stop
traffic to let pedestrians cross and stop pedestrians to let traffic flow.

There may be a button that pedestrians can press to signal their presence.
In some countries,
in some cases, that button is a dummy.  A light comes on to tell you that
you've pressed it but it
has no influence upon the timing cycle.  The timing cycle may be controlled
by road sensors,
or by time of day, or may have a fixed duration.  Presence or absence of a
button is irrelevant.


> If we tag that as crossing=traffic_signals, have we correctly and
> consistently communicated all of that information?
>

Maybe.  People are capable of misinterpreting anything.

>
> As an aside regarding the term "controlled", the OSM wiki doesn't actually
> say any of this about whether it's traffic or pedestrians or both being
> controlled. What it actually states is that crossing=uncontrolled is
> equivalent to a marked crossing or "crosswalk". A marked crossing can have
> or lack all forms of traffic signals that we've discussed.
>

I would say that both pedestrians and traffic have to be controlled.
Controlled pedestrians and
uncontrolled traffic is insane.  Controlled traffic and uncontrolled
pedestrians is traffic lights.

> *Sigh*  Was all this about pedantry?  The same interlocked mechanism
> controls two sets of lights on the same pole, one set controls vehicular
> traffic the other set controls pedestrians.  I didn't mean that both
> pedestrians and motorists stare at exactly the same set of lights.
>
> That's not pedantry, it's the precision that we need to describe
> crossings. Are we mapping based on lights or a connected signal apparatus?
> That's an actually important question. We should be able to say that
> clearly to new mappers and embed it into mapping tools.
>

The pedestrian-facing lights and vehicle-facing lights don't even have to
be on the same pole,
but they should be positioned such as to control the pedestrians and
traffic at a crossing and
be operated in synchrony by the same controller.  Together they constitute
a single crossing.

Yes, you're going to have to spell out all the variants.  Like the image
you linked to where lights are
suspended from cables in the middle of the road and only face traffic, but
they're part of the same
single crossing.  Traffic-facing and pedestrian-facing lights for the same
crossing might be on
different poles.

Oh, and you can have two independent crossings within a few yards of each
other which handle
one direction of traffic flow on a road with 

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 11. May 2019, at 00:57, Nick Bolten  wrote:
> 
> If only one or the other, it is not a crossing=traffic_signals.


you have still to show us a crossing with traffic lights only for pedestrians :)

Crossing refers to a pedestrian (or bicycle) crossing, when there are only 
traffic lights for the traffic on the road, but not for the crossing traffic 
then there won’t be a crossing tag.


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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

>> - A crossing might be marked on the ground

> Are there traffic signals which control BOTH traffic and pedestrians?  If
so,
> crossing=traffic_signals.   If there are JUST road markings, no
crossing=traffic_signals.

I interpret this to mean: the necessary condition for using
crossing=traffic_signals is that there are signals controlling both traffic
and pedestrians. If only one or the other, it is not a
crossing=traffic_signals.

>> - A crossing might have lighted signals for pedestrians to cross

> Define what you mean by lighted signals.  If you mean a Belisha Beacon or
something else that WARNS motorists that pedestrians cross here but does
NOT control traffic and pedestrians then it's not
crossing=traffic_signals.  A warning light is not a traffic signal.

In this case, I was thinking of a specific "walk/do not walk" lighted
signal.

>> - A crossing might be protected by a traffic light that tells traffic to
stop. That light might be at the crossing or at a street intersection.

> That's crossing=traffic_signals IF it also controls pedestrians.
Walk/Don't Walk ot Red/Green figures or whatever.  Otherwise it's just
traffic lights.  Even if people can cross there, it's still just traffic
lights because the crossing (by people) Isn't controlled, just the traffic
is.  Traffic has to stop when the lights tell them, the pedestrians take
their chances and are uncontrolled.

I take this to mean that the signals do not need to be colocated in order
to tag crossing=traffic_signals, such as in this scenario:
https://www.colchestervt.gov/ImageRepository/Document?documentID=185.

- There are markings on the ground
- There are pedestrian-facing signals
- There are traffic signals at the intersection controlling traffic

If we tag that as crossing=traffic_signals, have we correctly and
consistently communicated all of that information?

As an aside regarding the term "controlled", the OSM wiki doesn't actually
say any of this about whether it's traffic or pedestrians or both being
controlled. What it actually states is that crossing=uncontrolled is
equivalent to a marked crossing or "crosswalk". A marked crossing can have
or lack all forms of traffic signals that we've discussed.

>>> In any sane world, lights to control pedestrians also function as
lights to control traffic.

>> Then we live in an insane world! I'm not aware of any lights that
control both pedestrians and traffic - they are oriented in orthogonal
directions.

> *Sigh*  Was all this about pedantry?  The same interlocked mechanism
controls two sets of lights on the same pole, one set controls vehicular
traffic the other set controls pedestrians.  I didn't mean that both
pedestrians and motorists stare at exactly the same set of lights.

That's not pedantry, it's the precision that we need to describe crossings.
Are we mapping based on lights or a connected signal apparatus? That's an
actually important question. We should be able to say that clearly to new
mappers and embed it into mapping tools.

> I don't think we can let occasional errors by novice mappers define tags
for us.  If such errors are widespread then we need to introduce a
replacement scheme, encourage it for new use and manually replace the old
scheme.

Given that I've received a different definition of the term "uncontrolled"
from every response in this and the other proposal thread, I do not suspect
this is an issue that is occasional nor restricted to new mappers.

On Fri, May 10, 2019 at 1:20 PM Paul Allen  wrote:

> On Fri, 10 May 2019 at 21:03, Nick Bolten  wrote:
>
>> I still don't know when you think we should use
>> crossing=traffic_signals...
>>
>> - A crossing might be marked on the ground
>>
>
> Are there traffic signals which control BOTH traffic and pedestrians?  If
> so,
> crossing=traffic_signals.   If there are JUST road markings, no
> crossing=traffic_signals.
>
> - A crossing might have lighted signals for pedestrians to cross
>>
>
> Define what you mean by lighted signals.  If you mean a Belisha Beacon or
> something else that
> WARNS motorists that pedestrians cross here but does NOT control traffic
> and pedestrians
> then it's not crossing=traffic_signals.  A warning light is not a traffic
> signal.
>
> - A crossing might be protected by a traffic light that tells traffic to
>> stop. That light might be at the crossing or at a street intersection.
>>
>
> That's crossing=traffic_signals IF it also controls pedestrians.
> Walk/Don't Walk ot Red/Green
> figures or whatever.  Otherwise it's just traffic lights.  Even if people
> can cross there, it's still
> just traffic lights because the crossing (by people) Isn't controlled,
> just the traffic is.  Traffic has
> to stop when the lights tell them, the pedestrians take their chances and
> are uncontrolled.
>
> - A crossing might be protected by warning lights to raise pedestrian
>> visibility
>>
>
> Not crossing=traffic_lights.  Traffic lights control traffic, at a
> minimum.  If they also control
> pedestrians 

Re: [Tagging] Looking for Existing Proposal/Feature - Firearm Restrictions

[Graeme Fitzpatrick]

On Fri, 10 May 2019 at 12:46, Jane Smith 
wrote:

> Good Evening,
>
> I am considering submitting a proposal for restrictions or allowances on
> carrying firearms in a particular location. I checked through the proposal
> pages and the active features pages and did not see anything related to
> this. The Proposal Process page suggested emailing this list to ensure
> nothing similar is already in use.
>

Hi Jane

(Sorry, tried to send this yesterday but our internet died :-()

That's an interesting one!

As far as I was aware, there's no mention of firearms in OSM, but when I've
just looked, I've found about 20 listings (all in the US - I'm guessing
that's where you are?) for firearms=yes/no, so there's obviously at least
some interest in the idea!. This will hopefully show the TagInfo
https://taginfo.openstreetmap.org/keys/firearms#overview & Overpass map of
them: https://overpass-turbo.eu/s/ITh.


> Examples of these restrictions in my area would be signs on buildings
> prohibiting carrying firearms concealed and/or openly. The signs themselves
> would be nodes, but the allowance or restriction would apply to ways.
>

Because of the mass of conflicting firearm laws in the US between States,
Counties, cities & building owners, I think that you'd have to tie this to
individual buildings, or even shop by shop?

Could possibly be done as a node on the building itself, but also as an
extra tag against the business eg
https://www.openstreetmap.org/way/305658067

Good luck!

Thanks

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

Re: [Tagging] Feature Proposal - RFC - toll

[Warin]

On 09/05/19 03:22, Paul Allen wrote:
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.


+1

No need to separate countries.

toll:type... NO. the values of time and distance indicate the fee paid 
will be related to those quantities ... the time one? The slower you go 
do you pay more or less compared to the faster vehicle???


toll:assessment=time/distance  but not toll:type!

And of course if these comment are ignore I will vote against... Bye.


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

Re: [Tagging] Misuse of name tag for route description

[Warin]

On 11/05/19 07:07, Paul Allen wrote:
On Fri, 10 May 2019 at 21:26, Markus > wrote:



What kind of name are displayed on these buses? Around here, buses,
trains etc. usually only display the route number (or route type) and
their destination (e.g. "701 Le Prese Stazione", "201 Villeneuve", "IR
Chur" or "IC 3 Basel SBB"). Route names (e.g. "Bernina Express",
"MetropolitanLine" or "Marunouchi Line") seem to be quite rare.


Usually destination.  Except for the Cardigan Town Service.  But with 
PTV2 routes split into
two (or more relations), one for each direction, this isn't a 
problem.  The bus from Cardigan
to Aberystwyth says "Aberystwyth" and the bus from Aberystwyth to 
Cardigan says "Cardigan."

Elsewhere I've lived the bus might say XXX to YYY via ZZZ.

I like the idea that the name of the bus, as shown on the map, is the 
same as the name of the
bus, as shown on the bus.  It means I can look at the map and know 
what to look for on an
approaching bus.  Not having the two correspond is unhelpful, if not 
downright perverse.


Route number alone is insufficient.  Not when there can be variant routes.


If the bus/train only shows the route number .. then name = route number ???
Around me most buses show the route number and the destination .. or 
something like the destination depending on the service.




Of course, that all presumes the bus company is sane and rational.  
Unlike my local bus
company.  The 408 is a merger of the 406 Cardigan Town Service and the 
407 Cardigan to
St Dogmaels routes.  It displays "Cardigan Town Service and St 
Dogmaels" for most of its
route around Cardigan.   Then displays "Cardigan Town Service" as it 
sets off for St Dogmaels.
Except when it's on a variant school run, when the drivers decide to 
call it the 405, although it
isn't, because they think 405 means school service (it doesn't).  The 
405 is a school service
between a particular part of Cardigan and the primary school.  WIth 
what should be the 408
parked next to it, you have to ask the driver if it's the real 405 or 
the fake 405.





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

Re: [Tagging] Feature Proposal - crossing=marked

[Martin Koppenhoefer]

sent from a phone

> On 10. May 2019, at 23:17, yo paseopor  wrote:
> 
> A mark is not a control. A sign is not a control (when yes, when no)


signs and markings are commonly considered traffic controls.

Cheers, Martin 



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

Re: [Tagging] Feature Proposal - crossing=marked

[yo paseopor]

No, don't be innocent

If you search traffic light you will see the same thing, not any strange
light in relation with traffic itself.
https://www.google.com/search?q=traffic+light=lnms=isch=X=0ahUKEwj3vf-XqJHiAhWhzoUKHYr5D3kQ_AUIDigB=1280=891
https://en.wikipedia.org/wiki/Traffic_light.
If you make a specific micromapping you will not have problems. Otherwise
you can't ask for detailed information if the mapping is not as detailed.

If you see a traffic light in a footway is for the footway, not the highway.
If you see a traffic light in a cycleway is for the cycleway, not the
highway.

There is no ambiguosity: point is where is the feature, where the feature
acts.

Why you suppose marked is better than uncontrolled? Do you suppose that new
mapper doesn't know for which kind of marks are you talk about? Marked
with? Traffic sign? Traffic light? other lights in the traffic?

Crossing tag scheme is based ...on the marks and other items you will have:
traffic_signals, supervised=yes, uncontrolled (but marked), unmarked, no
(prohibited). If you put a crossing=marked...what do you mean? , which of
them do will you substitute?

Uncontrolled means NO CONTROL. A mark is not a control. A sign is not a
control (when yes, when no). Supervised means with supervision, traffic
signals with traffic light. Unmarked...what do you expect about control if
there is not any mark.

You had said " As someone who has personally mapped thousands of crossings,
the current schema is absolute garbage for reliably collecting accurate
data that can be reliably interpreted by data consumers that aren't solely
focused on car routing."
No, if the crossing is in a footway  you will have info about the footway,
not only for cars. In Openstreetmap there is a lot of tagging schemes who
thinks far away from cars only: kerbs, sidewalks, wheelchair...Use it also,
not only crossings.

> The iD editor never uses crossing=uncontrolled. It actually uses
crossing=marked now.
Well, I think it is a big error, because there is no marked values at the
wiki and you have the same thing with the value uncontrolled in the wiki.

>I anticipate that many US-based communities would be open to converting
crossing=uncontrolled and crossing=zebra to crossing=marked, at a minimum,
given how frequently they've been edited with iD.
I don't why US-based communities would not be open to converting
crossing=zebra (which does not exists, is crossing_ref= if you read the
wiki) to crossing=uncontrolled that is the value you can read in the wiki
instead of mix values and tags to create a new scheme.

>A controlled crossing can have or lack ground markings, and an
uncontrolled can have or lack ground markings.
Yes, but it has no-sense . Why control one thing that you don't indicate by
any way. First make it visible, then control it.

> In your country, how do you map a crossing that has traffic controls but
does not have markings on the ground?
It does not exists and I have to say I don't remember see this in the rest
of Europe I have visited.

Tagging schemes with yes/no binary values makes more complex the
scheme...yes there is only two possible values...but then you have to have
three different tags for the same thing.Yes, the scheme you are proposing
here will have more descriptional tags...but also have three more time tags
than the existing one with the same information.

> Map a crossing that is unmarked and has pedestrian signals ("walk"/"do
not walk").
That is a traffic light for pedestrian. Why do you want any mark if you
have a traffic light to control it? In my country...that situation does not
exist.

> Map a crossing that is marked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
That is crossing=uncontrolled, because there is no control about the
footway crossing.

> Map a crossing that is unmarked and is protected by a stop sign but no
traffic light, then say how you would interpret this as a data consumer.
Well , it is crossing=unmarked because there is no marks on the corssing. A
stop sign is about the highway cross with other way, nothing to have
relation with a pedestrian crossing, otherwise you will have other kind of
traffic sign, not Stop.

> Map a crossing that is unmarked and is protected by its own,
non-street-intersection traffic light, then say how you would interpret
this as a data consumer.
Well, it will be a crossing=unmarked, because there is no mark on the
ground, also I say in my country you have avoided to cross by there except
in residential streets (the one's with the same level on sidewalk and the
road itself )

> Map a crossing that is unmarked, has pedestrian-specific signals
("walk"/"do not walk"), but no traffic signals at all nearby.
WTF? For what do you need walk/don't walk parameter if there is no traffic
light with???

> Map a crossing that has markings and is protected by a traffic light, but
that traffic light is part of the overall highway=traffic_signals

Re: [Tagging] Misuse of name tag for route description

[Paul Allen]

On Fri, 10 May 2019 at 21:26, Markus  wrote:

>
> What kind of name are displayed on these buses? Around here, buses,
> trains etc. usually only display the route number (or route type) and
> their destination (e.g. "701 Le Prese Stazione", "201 Villeneuve", "IR
> Chur" or "IC 3 Basel SBB"). Route names (e.g. "Bernina Express",
> "MetropolitanLine" or "Marunouchi Line") seem to be quite rare.
>

Usually destination.  Except for the Cardigan Town Service.  But with PTV2
routes split into
two (or more relations), one for each direction, this isn't a problem.  The
bus from Cardigan
to Aberystwyth says "Aberystwyth" and the bus from Aberystwyth to Cardigan
says "Cardigan."
Elsewhere I've lived the bus might say XXX to YYY via ZZZ.

I like the idea that the name of the bus, as shown on the map, is the same
as the name of the
bus, as shown on the bus.  It means I can look at the map and know what to
look for on an
approaching bus.  Not having the two correspond is unhelpful, if not
downright perverse.

Route number alone is insufficient.  Not when there can be variant routes.

Of course, that all presumes the bus company is sane and rational.  Unlike
my local bus
company.  The 408 is a merger of the 406 Cardigan Town Service and the 407
Cardigan to
St Dogmaels routes.  It displays "Cardigan Town Service and St Dogmaels"
for most of its
route around Cardigan.   Then displays "Cardigan Town Service" as it sets
off for St Dogmaels.
Except when it's on a variant school run, when the drivers decide to call
it the 405, although it
isn't, because they think 405 means school service (it doesn't).  The 405
is a school service
between a particular part of Cardigan and the primary school.  WIth what
should be the 408
parked next to it, you have to ask the driver if it's the real 405 or the
fake 405.

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

Re: [Tagging] Misuse of name tag for route description

[Martin Koppenhoefer]

sent from a phone

> On 10. May 2019, at 18:16, Markus  wrote:
> 
> If the community (or rather its majority) agree that the name tag
> shouldn't used that way and as soon as the editors display the route's
> description in the relations list [3], i'll fix my mistakes.


I don’t take issue from public transport routes having names that are from-to 
descriptions, and would not be too sure that „these are clearly not names“, 
often they may be seen as names. 
I don’t think that these should be retagged to description, because 
descriptions contain any kind of information which may often not be suitable as 
a name.

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

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

[bkil]

I've read in the previous rejection comments that many opposed to
putting brand details in keys. What do you think about this version:
prepaid_top_up:mobile=yes/. The reason is that around here,
you could top up your mobile phone either at the given carrier, kiosks
over generic online charging or at given supermarket chains
(supporting fixed subsets of carriers). We could easily map such
detail when importing the given supermarket chain's data. We have
already raised this question during previous imports before this
proposal was started.

>
> I suggest we leave this out because it is too much to maintain IMO.--PangoSE 
> (talk) 16:15, 10 May 2019 (UTC)
>
> > Le 08.05.19 à 18:25, egil a écrit :
> > > https://wiki.openstreetmap.org/wiki/Proposed_features/Top_up

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

Re: [Tagging] Misuse of name tag for route description

[Markus]

On Fri, 10 May 2019 at 20:00, Paul Allen  wrote:
>
> My natural inclination would be to put the name of the service, as displayed 
> on the bus
> itself, in the name tag.  But maybe that's just me.

What kind of name are displayed on these buses? Around here, buses,
trains etc. usually only display the route number (or route type) and
their destination (e.g. "701 Le Prese Stazione", "201 Villeneuve", "IR
Chur" or "IC 3 Basel SBB"). Route names (e.g. "Bernina Express",
"MetropolitanLine" or "Marunouchi Line") seem to be quite rare.

Regards

Markus

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

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Fri, 10 May 2019 at 21:03, Nick Bolten  wrote:

> I still don't know when you think we should use crossing=traffic_signals...
>
> - A crossing might be marked on the ground
>

Are there traffic signals which control BOTH traffic and pedestrians?  If
so,
crossing=traffic_signals.   If there are JUST road markings, no
crossing=traffic_signals.

- A crossing might have lighted signals for pedestrians to cross
>

Define what you mean by lighted signals.  If you mean a Belisha Beacon or
something else that
WARNS motorists that pedestrians cross here but does NOT control traffic
and pedestrians
then it's not crossing=traffic_signals.  A warning light is not a traffic
signal.

- A crossing might be protected by a traffic light that tells traffic to
> stop. That light might be at the crossing or at a street intersection.
>

That's crossing=traffic_signals IF it also controls pedestrians.
Walk/Don't Walk ot Red/Green
figures or whatever.  Otherwise it's just traffic lights.  Even if people
can cross there, it's still
just traffic lights because the crossing (by people) Isn't controlled, just
the traffic is.  Traffic has
to stop when the lights tell them, the pedestrians take their chances and
are uncontrolled.

- A crossing might be protected by warning lights to raise pedestrian
> visibility
>

Not crossing=traffic_lights.  Traffic lights control traffic, at a
minimum.  If they also control
pedestrians then they're crossing=traffic_lights.  If they just warn
motorists they're not
traffic lights of any kind.

>
> Which part(s) of that does crossing=traffic_signals describe?
>

See above.  Just my own opinion, of course.

>
> > In any sane world, lights to control pedestrians also function as lights
> to control traffic.
>
> Then we live in an insane world! I'm not aware of any lights that control
> both pedestrians and traffic - they are oriented in orthogonal directions.
>

*Sigh*  Was all this about pedantry?  The same interlocked mechanism
controls two sets of lights
on the same pole, one set controls vehicular traffic the other set controls
pedestrians.  I didn't
mean that both pedestrians and motorists stare at exactly the same set of
lights.

Similar to you, I have yet to find an intersection with a pedestrian signal
> that does not have some form of either warning or explicit traffic control
> (but it could be either one), but I wouldn't rule it out based on my
> experience alone. However, the existence of a traffic light doesn't imply
> any other infrastructure: the crossing might lack pedestrian signals, its
> own dedicated light near the crossing, and even any particular visual
> markings indicating where to cross. Despite this, the
> crossing=traffic_signals tag has been used to describe all of these things,
> somehow.
>

I don't think we can let occasional errors by novice mappers define tags
for us.  If such errors are
widespread then we need to introduce a replacement scheme, encourage it for
new use and
manually replace the old scheme.

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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

I still don't know when you think we should use crossing=traffic_signals...

Imagine you're outside the UK. Pelican signals don't exist. No animal
signals, mythical or real, of any kind. There's just infrastructure:

- A crossing might be marked on the ground
- A crossing might have lighted signals for pedestrians to cross
- A crossing might be protected by a traffic light that tells traffic to
stop. That light might be at the crossing or at a street intersection.
- A crossing might be protected by warning lights to raise pedestrian
visibility

Which part(s) of that does crossing=traffic_signals describe?

> In any sane world, lights to control pedestrians also function as lights
to control traffic.

Then we live in an insane world! I'm not aware of any lights that control
both pedestrians and traffic - they are oriented in orthogonal directions.

> I can't see any sensible use case for lights that tell pedestrians they
can cross that do not also control traffic.  In the UK these usually
(always) look identical to "ordinary" traffic lights with the operational
exception of a protracted flashing amber to let pedestrians finish
crossing. From a motorist's perspective they are indistinguishable (at
first glance) from "ordinary" traffic lights.

Similar to you, I have yet to find an intersection with a pedestrian signal
that does not have some form of either warning or explicit traffic control
(but it could be either one), but I wouldn't rule it out based on my
experience alone. However, the existence of a traffic light doesn't imply
any other infrastructure: the crossing might lack pedestrian signals, its
own dedicated light near the crossing, and even any particular visual
markings indicating where to cross. Despite this, the
crossing=traffic_signals tag has been used to describe all of these things,
somehow.

On Fri, May 10, 2019 at 12:31 PM Paul Allen  wrote:

> On Fri, 10 May 2019 at 19:27, Nick Bolten  wrote:
>
>> This all makes sense, but the question is: what does
>> crossing=traffic_lights mean given these contexts? There are at least 3
>> types of lights and I've seen all of them referred to as "traffic lights",
>> even on UK government websites:
>>
>> - Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to
>> indicate that pedestrians should cross.
>>
>
> In any sane world, lights to control pedestrians also function as lights
> to control traffic.  I can't
> see any sensible use case for lights that tell pedestrians they can cross
> that do not also
> control traffic.  In the UK these usually (always) look identical to
> "ordinary" traffic lights with
> the operational exception of a protracted flashing amber to let
> pedestrians finish crossing.
> From a motorist's perspective they are indistinguishable (at first glance)
> from "ordinary"
> traffic lights.
>
> - The traffic lights for street traffic that are specifically associated
>> with a pedestrian crossing, as in the pelican example - the traffic light
>> pole also has all of these things: a pedestrian signal, a light for street
>> traffic (stop/go/etc), and there is generally an APS to request a crossing
>> signal.
>>
>
> This, rather than your first case, is all I've ever seen in the UK.
>
> - The traffic lights for street traffic that are not explicitly associated
>> with a particular crossing. The crossing is still protected by those
>> lights, there might even be an APS, but the traffic light is located at
>> highway=traffic_signals, i.e. the center of a street intersection.
>>
>
> If they ARE intended as a crossing then, in the UK, they'll be a pelican
> again, even if they're also
> controlling an intersection.  Not to be confused with ordinary traffic
> lights at an intersection which
> may not be intended for use as a crossing but tend to be used that way
> (because the traffic in
> one direction has been stopped, making crossing perhaps a little less
> difficult).
>
> As far as I can tell (at least in the UK) it boils down to either traffic
> lights that have nothing to do
> with pedestrians or traffic lights that also control pedestrians.
>
> --
> Paul
>
> ___
> 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

[Paul Allen]

On Fri, 10 May 2019 at 19:27, Nick Bolten  wrote:

> This all makes sense, but the question is: what does
> crossing=traffic_lights mean given these contexts? There are at least 3
> types of lights and I've seen all of them referred to as "traffic lights",
> even on UK government websites:
>
> - Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to
> indicate that pedestrians should cross.
>

In any sane world, lights to control pedestrians also function as lights to
control traffic.  I can't
see any sensible use case for lights that tell pedestrians they can cross
that do not also
control traffic.  In the UK these usually (always) look identical to
"ordinary" traffic lights with
the operational exception of a protracted flashing amber to let pedestrians
finish crossing.
>From a motorist's perspective they are indistinguishable (at first glance)
from "ordinary"
traffic lights.

- The traffic lights for street traffic that are specifically associated
> with a pedestrian crossing, as in the pelican example - the traffic light
> pole also has all of these things: a pedestrian signal, a light for street
> traffic (stop/go/etc), and there is generally an APS to request a crossing
> signal.
>

This, rather than your first case, is all I've ever seen in the UK.

- The traffic lights for street traffic that are not explicitly associated
> with a particular crossing. The crossing is still protected by those
> lights, there might even be an APS, but the traffic light is located at
> highway=traffic_signals, i.e. the center of a street intersection.
>

If they ARE intended as a crossing then, in the UK, they'll be a pelican
again, even if they're also
controlling an intersection.  Not to be confused with ordinary traffic
lights at an intersection which
may not be intended for use as a crossing but tend to be used that way
(because the traffic in
one direction has been stopped, making crossing perhaps a little less
difficult).

As far as I can tell (at least in the UK) it boils down to either traffic
lights that have nothing to do
with pedestrians or traffic lights that also control pedestrians.

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

Re: [Tagging] Feature Proposal - crossing=marked

[Nick Bolten]

This all makes sense, but the question is: what does
crossing=traffic_lights mean given these contexts? There are at least 3
types of lights and I've seen all of them referred to as "traffic lights",
even on UK government websites:

- Pedestrian signals, i.e. "walk/do not walk" lights of any kind meant to
indicate that pedestrians should cross.
- The traffic lights for street traffic that are specifically associated
with a pedestrian crossing, as in the pelican example - the traffic light
pole also has all of these things: a pedestrian signal, a light for street
traffic (stop/go/etc), and there is generally an APS to request a crossing
signal.
- The traffic lights for street traffic that are not explicitly associated
with a particular crossing. The crossing is still protected by those
lights, there might even be an APS, but the traffic light is located at
highway=traffic_signals, i.e. the center of a street intersection.

The OSM wiki describes crossing=traffic_signals as, "Position this tag
where the crossing-traffic (pedestrian, bicycles) have their own traffic
lights." I still have no idea which of these things that is meant to apply
to. I wouldn't personally consider a intersection-centered traffic light to
be pedestirans' "own" traffic lights, but they have roughly the same
function and impact on pedestrian needs as a pelican crossing, in terms of
traffic. I've been told a few times, on this mailing list, that it does not
apply to pedestrian signals, but that's hard to reconcile with the fact
that pedestrian signals are frequently referred to as "traffic lights" in
many official government documents and guides and trying to understand what
in the world "their own traffic lights" means.

Personally, I think this suggests a need for a separate value or at least
tagging strategy to separate at least these two cases: signals directed at
pedestrians vs. signals directed at street traffic. If there is value in
knowing whether traffic signals are attached to the crossing in some way, I
wouldn't be against that, either.

On Fri, May 10, 2019 at 4:45 AM Paul Allen  wrote:

> On Thu, 9 May 2019 at 23:26, Nick Bolten  wrote:
>
>>
>> Yes, but a traffic light for whom? I've seen mappers who assume it means
>> "walk"/"do not walk" lights like this:
>> https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg.
>> I've seen mappers who assume it means there is a sign *just* to warn
>> traffic about pedestrians, as can be found in the UK. I've seen mappers who
>> assume it means there is a nearby traffic light that means cars sometimes
>> stop at this location, but it doesn't say anything about having a
>> "walk"/"do not walk" sign.
>>
>
> Yes, there are warning lights in the UK.  Zebra crossings on public roads
> have a flashing yellow
> globe on a pole (Belisha Beacon) to highlight that there is a crossing.
> But nobody refers to it as
> a traffic light.  Some crossings by schools have flashing yellow lights
> (in a similar sort of style
> to US railroad crossing lights) but they're not traffic lights either.
> Traffic lights control the flow
> of traffic by telling drives when they must stop and when they can go,
> they're not warnings that
> there is a crossing.
>
> We have crossings with lights that control both pedestrians and traffic,
> the Pelican (PEdestrian
> Light CONtrolled) crossing.  As far as motorists are concerned it looks
> like any other set of
> traffic lights except there's an additional flashing amber phase telling
> cars they can go if there
> are no pedestrians on the crossing.  As far as pedestrians are concerned
> it looks like traffic
> lights for motor vehicles but also has lights for the pedestrians (and a
> button, which may or
> may not do anything) for the pedestrian to let the lights know somebody is
> waiting to cross).
>
> I don't recall seeing (in the UK, in other countries it might be
> different) lights that control
> pedestrians but NOT traffic.  It doesn't seem to be a sensible idea.  A
> signal that tells pedestrians
> it's now OK to cross without telling motorists they should have stopped
> seems like a recipe
> for disaster.
>
> To summarize: in the UK there are traffic lights that control motor
> vehicles and there are traffic lights
> that control both motor vehicles and pedestrians; warning lights are not
> traffic lights.
> --
> Paul
>
> ___
> 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] Looking for Existing Proposal/Feature - Firearm Restrictions

[Jan S]

Hi Jane,

Welcome! I'm currently visiting Texas, so I know that firearm restrictions are 
a fact that may be worthwhile to register in OSM. I suggest you write up a 
proposal following the guidelines in the wiki and taking other proposals as 
examples and put it up for comments here. If you feel that there's sufficient 
support for your proposal, you can pass it on to voting.

Good luck!

Best, Jan

Am 9. Mai 2019 21:44:02 GMT-05:00 schrieb Jane Smith 
:
>Good Evening,
>
>I am considering submitting a proposal for restrictions or allowances
>on
>carrying firearms in a particular location. I checked through the
>proposal
>pages and the active features pages and did not see anything related to
>this. The Proposal Process page suggested emailing this list to ensure
>nothing similar is already in use.
>
>Examples of these restrictions in my area would be signs on buildings
>prohibiting carrying firearms concealed and/or openly. The signs
>themselves
>would be nodes, but the allowance or restriction would apply to ways.
>
>Thank you.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Misuse of name tag for route description

[Paul Allen]

On Fri, 10 May 2019 at 18:40, Mateusz Konieczny 
wrote:

> Currently description of route is recommended to be mapped in name tag.
>

My natural inclination would be to put the name of the service, as
displayed on the bus
itself, in the name tag.  But maybe that's just me.

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

Re: [Tagging] Misuse of name tag for route description

[Mateusz Konieczny]

10 May 2019, 18:16 by selfishseaho...@gmail.com:

> as the editors display the route's
> description in the relations list [3], i'll fix my mistakes.
>
> [3]: > https://josm.openstreetmap.de/wiki/Help/Dialog/RelationList 
> 
>

Is there an opened issue at JOSM bug tracker requesting that change?

I requested something similar once and it was added quickly.

See instructions at https://josm.openstreetmap.de/newticket 
 for how one may create 
a new issie.

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

Re: [Tagging] Misuse of name tag for route description

[Mateusz Konieczny]

Currently description of route is recommended to be mapped in name tag.

It clearly should be placed in description tag, with name tag used for a name 
of the route.

I plan on amending Wiki this way, despite that proposal recommended misuses of 
name tag.

Please comment if such edit would not advisable in your opinion.

10 May 2019, 12:07 by selfishseaho...@gmail.com:

> Regarding the recent changes (from 6 May 2019‎) to the wiki page
> "Public transport" about the misuse of the name tag for route
> descriptions (e.g. name="701: Samedan Bahnhof - Le Prese Stazione").
> [1]
>
> [1]: > 
> https://wiki.openstreetmap.org/w/index.php?title=Public_transport=history
>  
> 
>
> I agree that the route description (from - to) is not its name. By the
> way, the same problem also affects hiking routes. I must admit that
> i've also misued the name=* tag this way. The reason are the editors:
> if a route is only tagged with ref=*, from=*, to=* (and description=*)
> and if more than one route variant or direction uses the same
> highway=*, one loses track of the routes and it becomes almost
> impossible to maintain them because editors only display the ref=*
> value in the relations list (e.g. there were multiple "13").
>
> I think it were be the best if editors would also display from=* and
> to* (or, instead, description=*) if there is no name=tag, in order
> that the name=* tag can be kept for routes that really have a name=*
> (e.g. Via Alpina).
>
> (I'm sending this email to the tagging mailing list as it doesn't only
> concern public transportation routes.)
>

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

Re: [Tagging] Misuse of name tag for route description

[Markus]

On Fri, 10 May 2019 at 13:50, Hufkratzer  wrote:
>
> It would probably better to use description=* than from=* and to=*
> because not all routes have a named starting point or destination point,
> like e.g. a roundtrip route around some village.

That's true. I didn't think about that.

Regards

Markus

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

Re: [Tagging] Misuse of name tag for route description

[Markus]

Hi Kevin,

On Fri, 10 May 2019 at 17:35, Kevin Kenny  wrote:
>
> Please don't assume that every name that looks like a description is
> simply a stopgap. Obviously, if you know you've misused the
> description as the name, fix it, but where the guidebooks and signs
> agree that the description is the name, please leave it alone.

Don't worry, i don't plan to retag such route names you listed! :) The
routes i have in mind are public transport routes and *unnamed* hiking
routes that currently are tagged name="[: ] -
" -- not just by myself. Note that the wiki [1] and the
approved PTv2 scheme [2] recommend using the name tag in this way.

[1]: https://wiki.openstreetmap.org/wiki/Public_transport#Service_routes
[2]: https://wiki.openstreetmap.org/w/index.php?oldid=625726#Route

If the community (or rather its majority) agree that the name tag
shouldn't used that way and as soon as the editors display the route's
description in the relations list [3], i'll fix my mistakes.

[3]: https://josm.openstreetmap.de/wiki/Help/Dialog/RelationList

Regards

Markus

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

Re: [Tagging] Misuse of name tag for route description

[Kevin Kenny]

On Fri, May 10, 2019 at 6:11 AM Markus  wrote:
> I agree that the route description (from - to) is not its name. By the
> way, the same problem also affects hiking routes. I must admit that
> i've also misued the name=* tag this way.

Many of the hiking trails around here have formal names that look like
descriptions. Many are named for endpoints, with possible intermediate
waypoints: "Van Hoevenberg Trail to Mount Marcy", "Elk Lake Trail to
Mount Marcy", :Elk Lake to Lilian Brook Trail" "Giant Ledge-Panther
Mountain-Fox Hollow Trail", "Northville-Placid Trail", "Oliverea to
Mapledale Trail", "Ramapo-Dunderberg Trail", "Suffern-Bear Mountain
Trail"  to name just a handful out of dozens, if not hundreds. There
are also trails that are named for their waymarks: "Red Cross Trail",
"Blue Disc Trail" and "White Bar Trail" are the formal names of the
routes.

The published route descriptions at sites like
https://www.dec.ny.gov/lands/9150.html include these descriptive
names. In the linked page, 'Long Path,' 'Curtiss-Ormsbee Trail' and
'Burroughs Range Trail' are most likely what you'd consider proper
names, but all the other names merely are taken from the endpoints.

Please don't assume that every name that looks like a description is
simply a stopgap. Obviously, if you know you've misused the
description as the name, fix it, but where the guidebooks and signs
agree that the description is the name, please leave it alone.

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

Re: [Tagging] Misuse of name tag for route description

[Hufkratzer]

It would probably better to use description=* than from=* and to=* 
because not all routes have a named starting point or destination point, 
like e.g. a roundtrip route around some village.


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

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Thu, 9 May 2019 at 23:26, Nick Bolten  wrote:

>
> Yes, but a traffic light for whom? I've seen mappers who assume it means
> "walk"/"do not walk" lights like this:
> https://commons.wikimedia.org/wiki/File:Do_Not_Walk_sign,_Great_Neck,_New_York.jpg.
> I've seen mappers who assume it means there is a sign *just* to warn
> traffic about pedestrians, as can be found in the UK. I've seen mappers who
> assume it means there is a nearby traffic light that means cars sometimes
> stop at this location, but it doesn't say anything about having a
> "walk"/"do not walk" sign.
>

Yes, there are warning lights in the UK.  Zebra crossings on public roads
have a flashing yellow
globe on a pole (Belisha Beacon) to highlight that there is a crossing.
But nobody refers to it as
a traffic light.  Some crossings by schools have flashing yellow lights (in
a similar sort of style
to US railroad crossing lights) but they're not traffic lights either.
Traffic lights control the flow
of traffic by telling drives when they must stop and when they can go,
they're not warnings that
there is a crossing.

We have crossings with lights that control both pedestrians and traffic,
the Pelican (PEdestrian
Light CONtrolled) crossing.  As far as motorists are concerned it looks
like any other set of
traffic lights except there's an additional flashing amber phase telling
cars they can go if there
are no pedestrians on the crossing.  As far as pedestrians are concerned it
looks like traffic
lights for motor vehicles but also has lights for the pedestrians (and a
button, which may or
may not do anything) for the pedestrian to let the lights know somebody is
waiting to cross).

I don't recall seeing (in the UK, in other countries it might be different)
lights that control
pedestrians but NOT traffic.  It doesn't seem to be a sensible idea.  A
signal that tells pedestrians
it's now OK to cross without telling motorists they should have stopped
seems like a recipe
for disaster.

To summarize: in the UK there are traffic lights that control motor
vehicles and there are traffic lights
that control both motor vehicles and pedestrians; warning lights are not
traffic lights.
-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - crossing=marked

[Paul Allen]

On Thu, 9 May 2019 at 23:46, Nick Bolten  wrote:

>
> I don't know what it means for a crossing to be supervised,
>

I assume what is meant by "supervised" is
https://en.wikipedia.org/wiki/Crossing_guard

The supervised crossing may have markings or even lights, or possibly
neither.  The lollipop
person is there for specific events (usually school start/finish) to
provide extra safety. for the
little monsters.  Could also apply to a police officer on traffic duty in
countries where traffic
lights are more expensive than police officers.

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

[Tagging] Misuse of name tag for route description

[Markus]

Regarding the recent changes (from 6 May 2019‎) to the wiki page
"Public transport" about the misuse of the name tag for route
descriptions (e.g. name="701: Samedan Bahnhof - Le Prese Stazione").
[1]

[1]: 
https://wiki.openstreetmap.org/w/index.php?title=Public_transport=history

I agree that the route description (from - to) is not its name. By the
way, the same problem also affects hiking routes. I must admit that
i've also misued the name=* tag this way. The reason are the editors:
if a route is only tagged with ref=*, from=*, to=* (and description=*)
and if more than one route variant or direction uses the same
highway=*, one loses track of the routes and it becomes almost
impossible to maintain them because editors only display the ref=*
value in the relations list (e.g. there were multiple "13").

I think it were be the best if editors would also display from=* and
to* (or, instead, description=*) if there is no name=tag, in order
that the name=* tag can be kept for routes that really have a name=*
(e.g. Via Alpina).

(I'm sending this email to the tagging mailing list as it doesn't only
concern public transportation routes.)

Regards

Markus

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

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

[bkil]

1. If I want to find a place where I can have some ice cream,
searching for cuisine="*ice_cream*" is a simple solution. Listing each
individual product is difficult to maintain due to changes in time,
but I usually add general categories that define the shop and for
which people would realistically want to search for.

2. There already exists such a thread:
"Values in namespaces/prefixes/suffixes Considered Harmful - Or: Stop
over-namespacing and prefix-fooling"
https://lists.openstreetmap.org/pipermail/tagging/2018-December/041650.html
https://wiki.openstreetmap.org/wiki/Talk:Namespace#Over-namespacing_and_Prefix-fooling

The verdict up until now seems to be that you shouldn't tag in such a
way that values creep into the key side of tags, especially if the
right side is always yes/no, but do share your view over that thread
if you think otherwise. The version with semicolons is also easier to
type.


On Wed, May 8, 2019 at 7:10 PM marc marc  wrote:
>
> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging