date:20200723

/OFF-topic

>  I wouldn't presume I could push my car along a motor_vehicle=no way, or 
> dismount my horse and lead it along a horse=no way.
>

I think the last few messages are pointing us in the right direction,
but let me share some entertaining insights to answer your question.

Under our jurisdiction, a person pushing a bicycle or a moped (mofa)
are specifically mentioned at various key points in the law.
https://net.jogtar.hu/jogszabaly?docid=9751.KPM

The law legally regards you as a pedestrian when you (Appendix 1, II/a):
* push a bicycle,
* push a moped,
* ride a (slow enough) wheelchair,
* push a wheelbarrow,
* push a stroller.

The following road users are regarded as drivers (Appendix 1, III/a):
* person driving a vehicle (except person pushing bicycle or moped),
* person riding/driving/leading an animal.

Pushing a cart seems to be a mixed bag:
* you don't need to hold a driver's license,
* you are not considered a pedestrian, hence can not use the sidewalk
and must abstain from alcohol consumption.

Pushing any other vehicle (e.g., motorcycle, automobile) is considered
dangerous and not recommended, except for moving them to safety until
it can be towed. The pusher in this case is legally considered a
driver, the act itself is legally considered driving the given vehicle
and hence must hold a valid license and must also abstain from
alcohol.

So to sum it up, when you are pushing your car, the same OSM car
access restrictions apply to you as if you were sitting inside and
using the engine. When you are leading your horse, the same horse
restrictions apply to you as if you were riding it (i.e., you should
not lead a horse on public roads when you are drunk because you may
not be cautious enough to protect the animal from causing an
accident).

On Thu, Jul 23, 2020 at 9:36 PM Jmapb  wrote:
>
> On 7/22/2020 12:05 PM, bkil wrote:
>>
>> My guess is that the adoption of a dismounted_bicycle=* tag or similar
>> would require significantly *less* work than re-examining all current
>> bicycle=no ways.
>>
>
> Yes, I think that would be workable.
>
>>
>> Nonetheless, I completely agree with you, =no should mean =no! But I
>> fear we're in the minority, and that the sloppy tagging of the past has
>> a formidable inertia.
>>
>
> I disagree, see my other answer relating to agriculture.
>
> Also, it contradicts the principle of least surprise that most countries do 
> not have such restrictions, hence regardless of how you would like to 
> redefine `bicycle=no`, half of the world would still keep tagging it 
> incorrectly.
>
> As I see it, having bicycle=no imply permission to push a dismounted bicycle 
> violates the principle of least surprise because it's inconsistent with other 
> *=no access tags. I wouldn't presume I could push my car along a 
> motor_vehicle=no way, or dismount my horse and lead it along a horse=no way.
>
> I'm not asking for a stricter redefinition of bicycle=no because I suspect 
> it's simply not feasible at this point, especially given the continued 
> popular support for the interpretation that allows dismounted travel. But 
> it's clear why there's confusion here. Precisely because of this 
> inconsistency in the meaning of *=no, the strictest documented bicycle tag 
> value does not correctly describe the strictest real-world cases (which are 
> not rare.) And I guarantee that many mappers do not know that they're 
> implicitly permitting dismounted bicycle travel when they tag bicycle=no, 
> especially if they're aware of the bicycle=dismount tag.
>
> At the same time, I fear that defining a new value, stricter than =no (eg 
> =prohibited, =banned, etc) would probably cause more problems than it would 
> solve, given the number of data consumers that would need to adapt to this 
> change. This is why I reluctantly suggested adding a second tag 
> (dismounted_bicycle=no) alongside bicycle=no, even though it feels like an 
> ugly hack. Other possibilities might be prohibited=bicycle, 
> bicycle:prohibited=yes. foot:pushing_bicycle=no, foot:conditional=no @ 
> (pushing_bicycle)... all pretty hard to love.
>
> Maybe I'm wrong and a stricter-than-no value could be adopted without too 
> much pain? There is already limited use of bicycle=prohibited. (OSRM 
> currently appears to ignore it, see 
> https://www.openstreetmap.org/way/244518832 and 
> https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=45.61895%2C13.86592%3B45.61999%2C13.86804
>  .)
>
> Jason
>
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?


On 23/07/2020 17.30, Mike Thompson wrote:

On Thu, Jul 23, 2020 at 2:34 PM Matthew Woehlke wrote:

...but then your horse is a passenger in a vehicle. Otherwise that would
be like saying a human can't ride in a vehicle if foot=no.


Exactly, foot=no doesn't mean that feet are not allowed, it means that
using a mode of transportation that primarily uses feet  ("foot
travel"/walking/running/hiking) isn't allowed.
bicycle=no is consistent with this, it doesn't mean that bicycles are
prohibited, it means that a mode of transportation, (bicycle riding) is
prohibited.
horse=no is apparently a  little different as you point out.  It seems to
refer not just to a mode of transportation, but to the possession of the
animal in general.


I disagree. In both cases, what is prohibited is the horse/bicycle 
touching the ground.


Based on that, you could argue that bicycle=no means you can *carry*, 
but not *walk* (push) your bicycle. I would be *tentatively* sympathetic 
to such an argument... depending on how obnoxious it is for you to be 
dragging around a bicycle. For something like a foldable, or if is 
dismantled enough to not be a large, ungainly object, then I would lean 
toward that being okay (which is where we get into prohibited=bicycle or 
whatever spelling).



It is similar to dog=no. dog=no doesn't refer to
whether you can use a dog as a mode of transportation, it means you can't
possess a dog at all on the given way (even if you carry it).


*This* is where things become inconsistent :-). Although, as we've 
noted, in some instances you *can* carry your dog.


--
Matthew

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

Re: [Tagging] Two side-of-road parking questions


On 23/07/2020 17.26, Paul Allen wrote:

On Thu, 23 Jul 2020 at 21:00, Matthew Woehlke wrote:

Interesting. By that criteria, I would think that
https://www.openstreetmap.org/way/826561593 has on-street parking,


Tough call.  In isolation it looks like a parking lane, but it has markings
for car parking.  On-street parking (at least where I am) doesn't usually
have that.  However, when I switch to Virginia imagery (much clearer)
I see the parking extends around the corner.


The Virginia Ortho isn't bad, and I sometimes use it as a secondary 
reference, but MapBox is even better. (That doesn't seem to be the case 
everywhere; in some places, MapBox is apparently quite bad, but for much 
of the US east coast it seems to be the highest-resolution imagery 
available. NAIP is the *newest*, but it's lower resolution than many 
other sources.)



From the geometry, I'd say that was a parking lot.


Currently, I have the non-parallel spots marked as a lot. To my mind, 
parallel parking and on-street parking are nearly synonymous. That said, 
I can see your argument, especially if I look at JOSM's lane rendering 
as a gauge for whether normal traffic flow would be occluded by parked 
vehicles. In that sense, there are a lot of folks parking on e.g. 3rd 
and 4th Avenues (where there are additionally not marked spaces) that I 
would definitely call "on street parking". (I'm also not at all inclined 
to tag that.)



but would you argue that all of Potomac Avenue
(https://www.openstreetmap.org/way/686513005


From the fact that parking spaces are marked, it's not a parking
lane, in my opinion.


Well it's certainly not a parking *lane*; you clearly are not meant to 
possibly drive through it. I was thinking that the fact the parking 
spaces are arranged so as to not occlude traffic was what was inclining 
me to model it as a "lot".


Really, it's the notion of a parking lot for which the aisle is also a 
main road that's throwing me... Maybe I should look at what's been done 
somewhere like Manhattan...



Actually, I did mean the six spaces on the west side of Broadway. I
recommend looking at e.g.
https://www.openstreetmap.org/edit#map=22/38.52057/-77.29185 for all of
those, it will be easier to tell what's centered.


That's a parking lot rather than on-street parking.  At least, that's how
I'd map it.  If no cars were parked you couldn't drive along it without
some turns.  If you mapped the highway itself as an area, that
parking would be a pregnant bulge.


Yeah, that line of thinking is similar in effect to asking if it 
occludes normal traffic flow. Different questions, but likely to have 
the same answer.



This is how I handled a similar one:
https://www.openstreetmap.org/?mlat=52.08562=-4.65829#map=19/52.08562/-4.65829

Somebody objected that whilst that looked right when rendered, when
you examined it in the editor it misleadingly implied that you could
park with one end of your car blocking half of the street.
Well, there's an easy solution to that; map the spaces, also ;-). That 
said, I find that attitude slightly asinine; it's normal for a parking 
lot area to include at least parts of the aisles.



I did one car park which attempted to deal with that complaint:
https://www.openstreetmap.org/?mlat=52.10572=-4.37367#map=19/52.10572/-4.37367
but it looks so ugly that I doubt I'll do that again.


Agreed (on the 'looking ugly'). I also tend to line up edges of lots 
along ways (example: https://www.openstreetmap.org/way/826298876). 
However, part of that was from an effort to make the lot only cover the 
area where you can actually park, without disconnecting it from the ways 
that serve it (the aforementioned lot is a good example of my 'older' 
technique). However, now that I am drawing the spaces also (thank you 
gridify!), I'm generally mapping the entire surface, up to some 
semi-arbitrary cutoff representing the entrances. I suppose if the roads 
were also mapped as areas, I would probably connect those rather than 
mapping them as separate driveways, although I'm on the fence there 
also. For example, with https://www.openstreetmap.org/way/826239218 I've 
connected the parking aisle directly to the main road, but in other 
places (e.g. https://www.openstreetmap.org/way/829371430) I've modeled a 
separate driveway first.


Anyway, your example would be much more sane if the entire road had a 
mapped area, rather than just the little piece by the parking lot.



In the end, do what works for you and hope nobody else who comes across it
thinks it so egregiously wrong that they change it.  At least not until
you've finished your project.


As long as they don't *remove* information, I don't mind people 
fiddling. That said, I'm not going to hold my breath, there doesn't seem 
to have been much activity on the base until I started working on it.


...and to be honest, another argument for modeling as lots is that the 
parking_lane tagging is rather more obtuse...


Anyway, thanks very much for

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Alan Mackie

On Thu, 23 Jul 2020 at 21:18, Mike Thompson  wrote:

>
>
> On Thu, Jul 23, 2020 at 1:36 PM Jmapb  wrote:
> > As I see it, having bicycle=no imply permission to push a dismounted
> bicycle violates the principle of least surprise because it's inconsistent
> with other *=no access tags. I wouldn't presume I could push my car along a
> motor_vehicle=no way, or dismount my horse and lead it along a horse=no way.
> bicycle=no is a strict "no", it is just that it means "no bicycling" or
> "no bicycle riding."
>



> Perhaps it is unfortunate that for modes of transportation we picked nouns
> rather than verbs (e.g. foot vs. walking), but that is what it is by long
> tradition.  A similar thing applies to horse=no.  There are roads (some of
> the US Interstates) where you can not ride your horse, but you can load
> your horse into a trailer, hook the trailer up to your truck, and drive
> with your horse on those same roads.
>

And now I have the perverse desire to suggest that if bicycle=no prevent
(bi)cycling we should use bicycling=no to prohibit the bicycle itself. But
that would be as terrible as I am currently finding it funny.

I suggest that if what is prohibited is pushing the bicycle, then we make
> an explicit tag for that bicycle_pushing=no. The same with regards to
> carrying the bicycle. If possession is prohibited all together, then
> bicycle_possession=no.
>
> This sounds wordy but reasonable. Keep the mode prohibition on a separate
tag to the item prohibition.  Yes it is another tag for routers to deal
with, but it doesn't break the one they already look at.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Peter Elderson

bicycle=leave

Vr gr Peter Elderson


Op do 23 jul. 2020 om 23:32 schreef Mike Thompson :

>
>
> On Thu, Jul 23, 2020 at 2:34 PM Matthew Woehlke 
> wrote:
> >
>
> >
> > ...but then your horse is a passenger in a vehicle. Otherwise that would
> > be like saying a human can't ride in a vehicle if foot=no.
> Exactly, foot=no doesn't mean that feet are not allowed, it means that
> using a mode of transportation that primarily uses feet  ("foot
> travel"/walking/running/hiking) isn't allowed.
> bicycle=no is consistent with this, it doesn't mean that bicycles are
> prohibited, it means that a mode of transportation, (bicycle riding) is
> prohibited.
> horse=no is apparently a  little different as you point out.  It seems to
> refer not just to a mode of transportation, but to the possession of the
> animal in general.  It is similar to dog=no. dog=no doesn't refer to
> whether you can use a dog as a mode of transportation, it means you can't
> possess a dog at all on the given way (even if you carry it).
>
>
> >
> > For similar reasons, I would assume that a way that allows vehicles but
> > not pushed bicycles allows a bicycle *in* a vehicle.
> Right, because it is no longer the mode of transportation.
>
> > FWIW, I'm sympathetic to the "no means no" camp and just declaring that
> > if you really meant "dismount", *fix it*.
> well, "no does mean no", it means "no bicycle riding", it means, no using
> a bicycle as a mode of transportation. It doesn't say anything about
> possessing a bicycle in general, or using it in another manner (pushing,
> carrying)
> "dismount" is not the complete solution, because, as the original question
> implied, sometimes it is also illegal to carry a bicycle (although I have
> never seen that), and as someone else pointed out, sometimes it is illegal
> to even possess a bicycle at all, such as in a US Wilderness Area.
>
> Mike
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Mike Thompson

On Thu, Jul 23, 2020 at 2:34 PM Matthew Woehlke 
wrote:
>

>
> ...but then your horse is a passenger in a vehicle. Otherwise that would
> be like saying a human can't ride in a vehicle if foot=no.
Exactly, foot=no doesn't mean that feet are not allowed, it means that
using a mode of transportation that primarily uses feet  ("foot
travel"/walking/running/hiking) isn't allowed.
bicycle=no is consistent with this, it doesn't mean that bicycles are
prohibited, it means that a mode of transportation, (bicycle riding) is
prohibited.
horse=no is apparently a  little different as you point out.  It seems to
refer not just to a mode of transportation, but to the possession of the
animal in general.  It is similar to dog=no. dog=no doesn't refer to
whether you can use a dog as a mode of transportation, it means you can't
possess a dog at all on the given way (even if you carry it).


>
> For similar reasons, I would assume that a way that allows vehicles but
> not pushed bicycles allows a bicycle *in* a vehicle.
Right, because it is no longer the mode of transportation.

> FWIW, I'm sympathetic to the "no means no" camp and just declaring that
> if you really meant "dismount", *fix it*.
well, "no does mean no", it means "no bicycle riding", it means, no using a
bicycle as a mode of transportation. It doesn't say anything about
possessing a bicycle in general, or using it in another manner (pushing,
carrying)
"dismount" is not the complete solution, because, as the original question
implied, sometimes it is also illegal to carry a bicycle (although I have
never seen that), and as someone else pointed out, sometimes it is illegal
to even possess a bicycle at all, such as in a US Wilderness Area.

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

Re: [Tagging] Two side-of-road parking questions

On Thu, 23 Jul 2020 at 21:00, Matthew Woehlke 
wrote:

>
> Interesting. By that criteria, I would think that
> https://www.openstreetmap.org/way/826561593 has on-street parking,

Tough call.  In isolation it looks like a parking lane, but it has markings
for car parking.  On-street parking (at least where I am) doesn't usually
have that.  However, when I switch to Virginia imagery (much clearer)
I see the parking extends around the corner.  From the geometry,
I'd say that was a parking lot.

> but
> would you argue that all of Potomac Avenue
> (https://www.openstreetmap.org/way/686513005

>From the fact that parking spaces are marked, it's not a parking
lane, in my opinion.  But this is OSM, opinions are divided on
everything, and this one is a judgement call.  If there were no
cars parked there, you could drive over those empty
parking spaces (whether it would be legal or not is another
matter), but I wouldn't call it a parking lane.

> >
> > Pretend they don't exist.  Map something else instead.
>
> Alas, my end goal isn't just to map for the sake of mapping, but to have
> a map that is usable for another project :-). Right now, having as much
> parking mapped as possible is relevant to that objective.
>

Ah.  That makes life difficult for you.

>
> Actually, I did mean the six spaces on the west side of Broadway. I
> recommend looking at e.g.
> https://www.openstreetmap.org/edit#map=22/38.52057/-77.29185 for all of
> those, it will be easier to tell what's centered.
>

That's a parking lot rather than on-street parking.  At least, that's how
I'd map it.  If no cars were parked you couldn't drive along it without
some turns.  If you mapped the highway itself as an area, that
parking would be a pregnant bulge.  This is how I handled a
similar one:
https://www.openstreetmap.org/?mlat=52.08562=-4.65829#map=19/52.08562/-4.65829

Somebody objected that whilst that looked right when rendered, when you
examined it
in the editor it misleadingly implied that you could park with one end of
your car blocking half
of the street.  I did one car park which attempted to deal with that
complaint:
https://www.openstreetmap.org/?mlat=52.10572=-4.37367#map=19/52.10572/-4.37367
but it looks so ugly that I doubt I'll do that again.

In the end, do what works for you and hope nobody else who comes across it
thinks it so egregiously wrong that they change it.  At least not until
you've
finished your project.

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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

On Thu, 23 Jul 2020 at 21:00, Kevin Kenny  wrote:

> On Thu, Jul 23, 2020 at 12:59 PM Paul Allen  wrote:
>
>> Different cultural expectations.  You're looking for information about a
>> trail and don't care what form it takes.
>>
>
> I suppose that you therefore consider that the principal tag for these
> objects, `tourism=information` is somewhat misleading, since it suggests
> that the informative function rather than the shape is the important
> attribute?
>

I'm happy with it being tourist information.  Well, sorta.  Essentially it's
just information.  But if you lived there you'd know anyway.  So it's
information
for tourists.

But it's not only for walkers and hikers.  Not when it's on a public road.
In the middle of a set of trails, it's for walkers and hikers, travelling at
walking speed, and with time to investigate.  It's also a waypoint for
motorists when it's on a public highway.

Now explain why you feel the need to differentiate a blaze from a
guidepost.  It's all just information about a route.  We could condense
everything into information=route.  In fact, we don't even need that.
Just tourism=information is sufficient because if it's in a wilderness
area next to a trail it's information about the route.  Problem
solved.  It's all just tourism=information.

-- 
Paul

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?


On 23/07/2020 16.16, Mike Thompson wrote:

Perhaps it is unfortunate that for modes of transportation we picked
nouns rather than verbs (e.g. foot vs. walking), but that is what it
is by long tradition.  A similar thing applies to horse=no.  There
are roads (some of the US Interstates) where you can not ride your
horse, but you can load your horse into a trailer, hook the trailer
up to your truck, and drive with your horse on those same roads.


...but then your horse is a passenger in a vehicle. Otherwise that would 
be like saying a human can't ride in a vehicle if foot=no. Besides, 
those restrictions are generally because slow-moving traffic is a 
hazard; in a trailer, your horse (camel, elephant, ...) is no longer 
slow-moving.


For similar reasons, I would assume that a way that allows vehicles but 
not pushed bicycles allows a bicycle *in* a vehicle.


FWIW, I'm sympathetic to the "no means no" camp and just declaring that 
if you really meant "dismount", *fix it*.


I don't think bicycle=no and horse=no should mean something different. 
If horse=no means "no horses allowed", not "horses allowed as long as no 
one is riding them" (which I would expect to be the case), then 
bicycle=no should mean the same thing with "bicycle" substituted for 
"horse". And in both cases, we're talking about the horse/bicycle being 
*directly* on the way, not being inside a vehicle.


--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Mike Thompson

On Thu, Jul 23, 2020 at 1:36 PM Jmapb  wrote:
> As I see it, having bicycle=no imply permission to push a dismounted
bicycle violates the principle of least surprise because it's inconsistent
with other *=no access tags. I wouldn't presume I could push my car along a
motor_vehicle=no way, or dismount my horse and lead it along a horse=no way.
bicycle=no is a strict "no", it is just that it means "no bicycling" or "no
bicycle riding."  Perhaps it is unfortunate that for modes of
transportation we picked nouns rather than verbs (e.g. foot vs. walking),
but that is what it is by long tradition.  A similar thing applies to
horse=no.  There are roads (some of the US Interstates) where you can not
ride your horse, but you can load your horse into a trailer, hook the
trailer up to your truck, and drive with your horse on those same roads.

I suggest that if what is prohibited is pushing the bicycle, then we make
an explicit tag for that bicycle_pushing=no. The same with regards to
carrying the bicycle. If possession is prohibited all together, then
bicycle_possession=no.

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?


On 23/07/2020 15.34, Jmapb wrote:

As I see it, having bicycle=no imply permission to push a dismounted
bicycle violates the principle of least surprise because it's
inconsistent with other *=no access tags. I wouldn't presume I could
push my car along a motor_vehicle=no way,


While I would generally agree, I *have* seen someone "dismount" their 
car¹ and drag it along sidewalks. Mind, they also drove it onto an 
elevator and into a library², so...


(OTOH, they may have had permission to do this; "someone" *was* Jeremy 
Clarkson... If you saw it, you knew this thread wasn't going to be 
"complete" until it got mentioned ;-). Yes, you *can* "dismount" and 
push/pull a road-legal petrol vehicle. Depending on the vehicle.)


(¹ https://en.wikipedia.org/wiki/Peel_P50)

(² ...or was that the "P45"? I forget...)


or dismount my horse and lead it along a horse=no way.


Definitely.

--
Matthew

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

Re: [Tagging] Two side-of-road parking questions


On 23/07/2020 15.20, Paul Allen wrote:

On Thu, 23 Jul 2020 at 19:43, Matthew Woehlke 
wrote:


I'm trying to tag a whole bunch of side-of-road parking, and I have two
questions.

First, what is the correct way to tag marked parking spaces? There is
parking:lane:*=marked which would seem to apply, but then it isn't clear
how to indicate the direction (parallel vs. diagonal vs. perpendicular)?
It's also not entirely clear when I am or am not supposed to use
'marked'...



In a parking lot, amenity=parking_space.  It doesn't render on standard
carto, so you may not feel it worth the effort.  If it's not obvious from
the dimensions (parallel vs perpendicular should be) people will
see when they get there.  You've given the capacity but can't
map how many spaces are currently free - some things have to be
left to inspection.


Second, at what point does "on street parking" become a parking lot?


When it's not part of the street.


Interesting. By that criteria, I would think that 
https://www.openstreetmap.org/way/826561593 has on-street parking, but 
would you argue that all of Potomac Avenue 
(https://www.openstreetmap.org/way/686513005 and 
https://www.openstreetmap.org/way/20453853 *is* or *is not* on-street 
parking? What about https://www.openstreetmap.org/way/686513006?



I am particularly struggling to decide what to do at places such as:

38.52057/-77.29185
38.52181/-77.29611
38.52125/-77.29711


Pretend they don't exist.  Map something else instead.


Alas, my end goal isn't just to map for the sake of mapping, but to have 
a map that is usable for another project :-). Right now, having as much 
parking mapped as possible is relevant to that objective.



That first one is tricky.  I assume you're talking about the
ordinary parking lot with the off-street parking adjoining rather
than the separate 6-place parking next to the building.
Actually, I did mean the six spaces on the west side of Broadway. I 
recommend looking at e.g. 
https://www.openstreetmap.org/edit#map=22/38.52057/-77.29185 for all of 
those, it will be easier to tell what's centered.


That said...


I'd map it as a large parking lot (as you have) and then the
side-of-street but as a separate off-street parking of the type you
did for https://www.openstreetmap.org/way/829371451 then combine the
two in a multipolygon.
...I was wondering about this also, so thanks for the thoughts! To be 
clear, you are suggesting to *not* use parking_lane stuff for this?



Actually, that#s three separate bits of off-street-parking because they're
interrupted by the access roads into the larger parking area.


Meh, parking aisles and even driveways pass through lots all the time, I 
think modeling them as three separate lots may be overkill :-).


--
Matthew

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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-23 Thread Kevin Kenny

On Thu, Jul 23, 2020 at 12:59 PM Paul Allen  wrote:

> Different cultural expectations.  You're looking for information about a
> trail and don't care what form it takes.
>

I suppose that you therefore consider that the principal tag for these
objects, `tourism=information` is somewhat misleading, since it suggests
that the informative function rather than the shape is the important
attribute?

And I guess I had better go back and get a better picture of
https://www.flickr.com/photos/ke9tv/9438767603 because in the photo I can't
really tell whether that's a poorly-set post made from a fallen tree trunk,
or a sign nailed to a tree that fell over and had its top cropped because
it was likely obstructing the trail. (Which would be fine; I haven't
climbed Indian Head in a few years, and it's got a nice view. It'll have to
wait, though, until the local authorities give me a less ambiguous 'green
light' that it's OK to travel there.)

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Jmapb

On 7/22/2020 12:05 PM, bkil wrote:

My guess is that the adoption of a dismounted_bicycle=* tag or similar
would require significantly *less* work than re-examining all current
bicycle=no ways.

Yes, I think that would be workable.

Nonetheless, I completely agree with you, =no should mean =no! But I
fear we're in the minority, and that the sloppy tagging of the
past has
a formidable inertia.

I disagree, see my other answer relating to agriculture.

Also, it contradicts the principle of least surprise that most
countries do not have such restrictions, hence regardless of how you
would like to redefine `bicycle=no`, half of the world would still
keep tagging it incorrectly.

As I see it, having bicycle=no imply permission to push a dismounted
bicycle violates the principle of least surprise because it's
inconsistent with other *=no access tags. I wouldn't presume I could
push my car along a motor_vehicle=no way, or dismount my horse and lead
it along a horse=no way.

I'm not asking for a stricter redefinition of bicycle=no because I
suspect it's simply not feasible at this point, especially given the
continued popular support for the interpretation that allows dismounted
travel. But it's clear why there's confusion here. Precisely because of
this inconsistency in the meaning of *=no, the strictest documented
bicycle tag value does not correctly describe the strictest real-world
cases (which are not rare.) And I guarantee that many mappers do not
know that they're implicitly permitting dismounted bicycle travel when
they tag bicycle=no, especially if they're aware of the bicycle=dismount
tag.

At the same time, I fear that defining a new value, stricter than =no
(eg =prohibited, =banned, etc) would probably cause more problems than
it would solve, given the number of data consumers that would need to
adapt to this change. This is why I reluctantly suggested adding a
second tag (dismounted_bicycle=no) alongside bicycle=no, even though it
feels like an ugly hack. Other possibilities might be
prohibited=bicycle, bicycle:prohibited=yes. foot:pushing_bicycle=no,
foot:conditional=no @ (pushing_bicycle)... all pretty hard to love.

Maybe I'm wrong and a stricter-than-no value could be adopted without
too much pain? There is already limited use of bicycle=prohibited. (OSRM
currently appears to ignore it, see
https://www.openstreetmap.org/way/244518832 and
https://www.openstreetmap.org/directions?engine=fossgis_osrm_bike=45.61895%2C13.86592%3B45.61999%2C13.86804
.)

Jason

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

Re: [Tagging] Tagging motorcycle parking


On 22/07/2020 20.49, Warin wrote:

You asked for 'better' without defining what better means to you.
To me it is 'better' to know where these things are (requires more work 
by the mapper) rather than that they are somewhere inside some area 
(requires less work by the mapper).


Disabled parking to me is 'better' mapped as a separate thing, as is 
truck parking etc.


While a motorcycle may legal park where a car parking space is the same 
cannot be said of a motorcycle parking space given  the usual sized of 
the things.


Tags may be available for those who cannot be bothered with the detail, 
similar observations may be made for surface=paved vs surface=concrete etc.


...and what if we're mapping spaces? I'm not sure I'm on board with 
dividing things which are logically "one parking lot" into multiple 
areas for... questionable benefit at that point. (If the spaces are also 
mapped, the "where is the parking for X?" doesn't hold.)


I think I want parking:capacity:motorcycle, and, while we're on the 
subject, parking:capacity:carry_out :-).


(And also parking_space=motorcycle and parking_space=carry_out, naturally.)

--
Matthew

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

Re: [Tagging] Two side-of-road parking questions

On Thu, 23 Jul 2020 at 19:43, Matthew Woehlke 
wrote:

> I'm trying to tag a whole bunch of side-of-road parking, and I have two
> questions.
>
> First, what is the correct way to tag marked parking spaces? There is
> parking:lane:*=marked which would seem to apply, but then it isn't clear
> how to indicate the direction (parallel vs. diagonal vs. perpendicular)?
> It's also not entirely clear when I am or am not supposed to use
> 'marked'...
>

In a parking lot, amenity=parking_space.  It doesn't render on standard
carto, so you may not feel it worth the effort.  If it's not obvious from
the dimensions (parallel vs perpendicular should be) people will
see when they get there.  You've given the capacity but can't
map how many spaces are currently free - some things have to be
left to inspection.

>
> Second, at what point does "on street parking" become a parking lot?
>

When it's not part of the street.  The example image for
https://wiki.openstreetmap.org/wiki/Key:parking:lane is on-street
parking.  If the parking doesn't restrict the width of the road,
it's not on-street parking (my opinion).  I would class
https://goo.gl/maps/fwTzLdfKS3MTzhvA8 as being a (very
small) parking lot rather than on-street parking.  With on-street
parking, if nobody is parked there then traffic can flow there.

There are examples of the first *all* over Quantico (at least the
> "downtown" part). For examples of the second, consider:
>
>https://www.openstreetmap.org/way/829371448
>https://www.openstreetmap.org/way/829371451
>https://www.openstreetmap.org/way/826561586
>

I looked at the second of those.  It's how I'd do it.

I am particularly struggling to decide what to do at places such as:
>
>38.52057/-77.29185
>38.52181/-77.29611
>38.52125/-77.29711
>

Pretend they don't exist.  Map something else instead.

That first one is tricky.  I assume you're talking about the ordinary
parking
lot with the off-street parking adjoining rather than the separate 6-place
parking next to the building.  I'd map it as a large parking lot (as you
have)
and then the side-of-street but as a separate off-street parking of the
type you did for https://www.openstreetmap.org/way/829371451
then combine the two in a multipolygon.  i have no idea how well
that works or how it will be rendered, but it's probably as close as you
can get.
Actually, that#s three separate bits of off-street-parking because they're
interrupted by the access roads into the larger parking area.

I think I'd go with my first suggestion - pretend they don't exist. :)

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

[Tagging] Two side-of-road parking questions

I'm trying to tag a whole bunch of side-of-road parking, and I have two 
questions.


First, what is the correct way to tag marked parking spaces? There is 
parking:lane:*=marked which would seem to apply, but then it isn't clear 
how to indicate the direction (parallel vs. diagonal vs. perpendicular)? 
It's also not entirely clear when I am or am not supposed to use 'marked'...


Second, at what point does "on street parking" become a parking lot?

There are examples of the first *all* over Quantico (at least the 
"downtown" part). For examples of the second, consider:


  https://www.openstreetmap.org/way/829371448
  https://www.openstreetmap.org/way/829371451
  https://www.openstreetmap.org/way/826561586

I am particularly struggling to decide what to do at places such as:

  38.52057/-77.29185
  38.52181/-77.29611
  38.52125/-77.29711

(There are likely more examples...)

--
Matthew

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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-23 Thread Jan Michel


On 23.07.20 18:57, Paul Allen wrote:

Here's an example I used to travel past regularly.  But that was years ago,
and the last time I saw it was a couple of years before I started mapping.
https://goo.gl/maps/fWvzsKneyMtSAFuW6  I remember roughly where it was,
but not well enough to map it, so I haven't added it. If I did map it, standard 
carto
would show it as a stylized fingerpost.



Interesting. I would classify this as a trailblaze, but not as a 
guidepost. A guidepost is something that shows me which destinations a 
way leads to. A trailblaze is a small sign that shows where the way is 
I'm already following.


To me a guidepost is a guidepost, no matter whether it has fingers and a 
post or not. That's minor details that can be handled by minor tags.
I think this matches very well the style many other tagging rules are 
using. E.g. a "highway" is any kind of way, no matter the size and its 
intended use and how it relates to the common use of the term "highway".





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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

On Thu, 23 Jul 2020 at 17:34, Kevin Kenny  wrote:

> On Thu, Jul 23, 2020 at 10:23 AM Paul Allen  wrote:
>
> Sometimes 'expectations' turn out, on examination, to be 'cultural
> assumptions'. I tend to prefer, where possible, to interpret tags _sensu
> lato,_ because otherwise there's a tagging quandary any time something
> doesn't fit the definition _sensu stricto_.
>
> In the strict sense that you are advocating. I suspect that my area has
> absolutely nothing that you would call a 'guidepost',.
>

That may well be true.  And so you see that your square peg is small
enough to fit into the round hole without force being required.  It serves
the same function, as far as you are concerned, so it's the same thing:
information about a trail.

>
> https://www.flickr.com/photos/ke9tv/14276154341 is probably the closest,
> since the signs are outboard from the support, but even there, they aren't
> finger- or blade-shaped; they are rectangular signs hanging from a
> cantilevered arm.
>

I gave fingerpost examples in my previous post because that's what's common
in my country.  The tag is for guideposts rather than fingerposts, and many
of the wiki examples don't have blades or fingers either.  But they DO
have posts.

You got your square peg through the first round hole, but there's another
round hole, a smaller one, that your square peg also has to fit through.  A
different cultural expectation from the one I think you're assuming.

Here's an example I used to travel past regularly.  But that was years ago,
and the last time I saw it was a couple of years before I started mapping.
https://goo.gl/maps/fWvzsKneyMtSAFuW6  I remember roughly where it was,
but not well enough to map it, so I haven't added it. If I did map it,
standard carto
would show it as a stylized fingerpost.  If you were driving along this
long road,
you might note that the house you want to visit is the first one on the
left after
the fingerpost.  So you'd be looking for a fingerpost.  You might not notice
a rock on the ground daubed with some graffiti.  If you did notice the rock
you might not realize it was the "sign post" you were looking for.  At
typical
driving speeds you probably wouldn't have time to read the graffiti, and
even
if you did read it you might not realize that it was marking the trail you
expected to see a fingerpost for.  You probably wouldn't have looked
where the trail went anyway, as you were just concerned with seeing
a sign post.

Different cultural expectations.  You're looking for information about a
trail and don't care what form it takes.  I'm looking for a sign post and
don't care (unless there's another one close by) what it says or where
the trail leads.

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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-23 Thread Kevin Kenny

On Thu, Jul 23, 2020 at 10:23 AM Paul Allen  wrote:

>
> Good question.  But it more closely resembles a guidepost than a blaze.
> Whereas the things being shoe-horned into guidepost in this thread more
> closely resemble blazes.  Elaborate blazes with text.  Not that I'm
> arguing we should abuse either tag by using for other things that
> go against expectations.
>
>
Sometimes 'expectations' turn out, on examination, to be 'cultural
assumptions'. I tend to prefer, where possible, to interpret tags _sensu
lato,_ because otherwise there's a tagging quandary any time something
doesn't fit the definition _sensu stricto_.

In the strict sense that you are advocating. I suspect that my area has
absolutely nothing that you would call a 'guidepost',.

https://www.flickr.com/photos/ke9tv/14276154341 is probably the closest,
since the signs are outboard from the support, but even there, they aren't
finger- or blade-shaped; they are rectangular signs hanging from a
cantilevered arm.

Cantilevered arms are unusual. Commoner practice around here is just to
nail the signs to the support as with
https://www.flickr.com/photos/ke9tv/15541120652 and
https://www.flickr.com/photos/ke9tv/7881561738

Using a post is also uncommon. It's much more usual for the signs to be
placed on whatever is available. Most commonly, that's a tree:
https://www.flickr.com/photos/ke9tv/14276103771
https://www.flickr.com/photos/ke9tv/14092717700 but it can be a utility
pole https://www.flickr.com/photos/ke9tv/6936695538 a building
https://www.flickr.com/photos/ke9tv/14190539728 or some other convenient
surface. (I've seen them on cliff faces, boulders, cairns and bridge
railings, but I don't have photos to hand.)

The common thread in all cases is that there's an enumeration of
destinations, with directions identifying the ways that go to them, and
(usually) the distances to the destinations. I distinguish a guidepost from
a trail blaze in that a trail blaze ordinarily identifies only the trail
you're on - or even just that you're on a trail - and sometimes (more
often, just by implication) the direction to follow.

Depending on the land manager's practice, around me a blaze could be a
simple splash of paint https://www.flickr.com/photos/ke9tv/14018094576, a
generic marker in tin or plastic
https://www.flickr.com/photos/ke9tv/14018066876, a slightly less generic
marker showing a trail purpose such as a spur leading to a campsite
https://www.flickr.com/photos/ke9tv/10282365273, a sign with a route number
(here also augmented with a generic blaze for a snowmobile trail)
https://www.flickr.com/photos/ke9tv/14318057029, or the logo of a
particular trail. For example, in
https://www.flickr.com/photos/ke9tv/7881583380 the stylized AT is the
symbol for the Appalachian Trail, which goes through the crawlway as
indicated by the arrow. The white rectangle (about 5 x 15 cm, long axis
vertical) is the AT's usual blaze. On the sign already shown at
https://www.flickr.com/photos/ke9tv/14092717700, there's a Long Path marker
at upper left, with that particular trail's logo on it. (Its customary
blaze is a 5 x 10 cm rectangle in aquamarine, already seen at
https://www.flickr.com/photos/ke9tv/14018094576.

Usually the only directional indication with a trail blaze will be an
arrow, and it's commoner to indicate the direction by conventional
placement of the markers. In https://www.flickr.com/photos/ke9tv/4988268609,
there are two markers on the tree at right, with the top one offset to the
right, indicating a right turn.

I don't ordinarily map trail blazes unless they're otherwise interesting
for some reason. I make route relations for them.

Sometimes, where a trail crosses open country (farmland or marshy ground)
where there are no stones to build a cairn or natural surfaces to paint a
blaze, a trail will be marked using posts with the blazes marked on them.
Confusingly, the word 'guidepost' is also used in common speech for these,
but I wouldn't use the 'guidepost' tag for them!

I don't think I've ever seen a UK-style finger post on a trail or road
around here.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?


On 23/07/2020 12.09, bkil wrote:

Alright, I didn't know you were only asking for the entertainment
value, but then I accept your challenge.


I wasn't asking for entertainment. I was asking because, while 
*logically* it seems like such a combination doesn't make sense, the 
refrain around here seems to be "don't assume".



Actually I could indeed think of a place where you are only allowed to
be present in case you are pushing a bicycle. Imagine a bicycle
adventure park that only contains bicycle roads. Let's say that the
terms of service declares that visitors must not leave their bikes
unattended (i.e., no parking).

Now let's pretend that there's a small bridge in the middle of the
park that includes a small stretch of stairs that has bicycle pushing
rails (or substitute with just a single wooden bridge in a bad shape
that has a bunch of long cracks that could easily lock your wheels if
you ride over it - true story, we had a bridge just like that). A sign
would be posted here that disallows bicycle riders from accessing it,
but pushing through would be possible.

How could you be walking on to this bridge if you were not in
possession of a bicycle in the first place?


Interesting. I suppose the question becomes, if there were such a way, 
would you tag it foot=no + bicycle=dismount?


--
Matthew

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

Re: [Tagging] Map maintenance with StreetComplete - Preferred tagging

This should be more applicable in case the person walked by the said
object in person: https://wiki.openstreetmap.org/wiki/Key:survey:date

Also, I'd like to stay neutral in this question as of now, but I think
it would be possible to implement heuristic algorithms to reconstruct
the history of a way even if it was split and to walk backwards on
changesets to check where "survey" was also mentioned as a "source".
We had a talk about just this on our local list some years ago.

A little preprocessing could go a long way, and such data structures
could be generated weekly or even less often - as the issue itself is
that a long time has already passed since the said objects were
updated. There's no need to extend the API just for this.

On Thu, Jul 23, 2020 at 6:08 PM Tobias Zwick  wrote:
>
> Hello everyone
>
> As you may or may not know, my microgrant proposal "Map maintenance with
> StreetComplete" [1] was selected to be funded by the OSMF. So, I am
> happy to have the oppurtunity to invest the time  extending the app,
> hoping that it will help to keep the map up-to-date and unburden people
> and communities invested in that topic.
>
> I am pitching this here because there are three details on which I would
> like to hear your input. Two of these are about tagging.
>
> But first, how will it work?
> 
>
> So, what StreetComplete will do is to scan the map for whether certain
> properties (tags) of map features haven't been surveyed for a certain
> time. If this is the case, users will be prompted to answer the question
> for that property again. For example, if the app ascertained that the
> smoothness of a road hasn't been changed for 5 years, it would ask users
> again about the smoothness of the road.
>
> Challenges
> --
>
> Now, you might imagine that this is not so straightforward to implement,
> and you would be right, for several reasons:
>
> Firstly, the OSM API has no notion about when a particular property of
> an element has last been changed, only for when the whole element has
> last been changed. But elements are changed all the time for various
> reasons. Roads for example tend to be changed especially often, splitted
> up to accomodate bus routes, turn restrictions, when detailing
> intersections, etc.
>
> Secondly, there is only the date of the last change, but that doesn't
> mean that is the date of the last survey. Even though that would be the
> information we are interested in: when has the element last been checked
> on-site?
>
> Thirdly, the OSM API does not offer users to record solely that they
> checked something and that it is still up to date. Any new record in OSM
> must always come with a tagging change.
>
> Solutions
> -
>
> In the absence of direct API support, fortunately the community came up
> with a solution: Add the check_date tag to the element that has been
> checked on a survey - or with the namespace if it concerns only a
> certain tag of a map feature.
>
> This works well and is actually already used by Streetcomplete in the
> "Is this construction site finished?"-quest:
> If the element as a whole hasn't been changed for 6 months *or* the
> check_date key is present and its value is older than 6 months, the
> quest is eligible to be asked again. When the user answers the question,
> the check_date is set to current date.
>
> Your input
> ==
>
> Now here is where I would like your input:
>
> 1. Use check_date:smoothness or smoothness:check_date?
> --
> check_date with a namespace isn't used all that often yet, both variants
> are used and thus there is no real winner yet. What variant do you
> prefer and why? And most importantly, which variant would be most
> consistent with existing tagging practices?
>
> 2. Always record check_date or avoid tagging it where not absolutely
> necessary?
> ---
> If something is resurveyed and it is acknowledged that nothing changed,
> it is absolutely necessary to tag check_date. If something changed, it
> is not strictly necessary because that the element changed as a whole is
> itself also recorded.
> But as already mentioned, elements can and do change all the time. One
> can not assume that if an element has been changed that it has been
> checked on-site. And even if one could, maybe not all the things were
> checked but for example only the bus route relation, or maybe only the
> presence of a sidewalk, or someone made the way a little more detailed etc.
>
> The topic whether StreetComplete should only tag the minimum of what is
> necessary to ensure functionality or always tag check_date (at least for
> properties that are eligible for re-survey) was already subject to
> discussion in the issue tracker here:
> https://github.com/westnordost/StreetComplete/issues/1836
>
> Maybe it is obvious that my opinion is that StreetComplete should always
> tag

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

Alright, I didn't know you were only asking for the entertainment
value, but then I accept your challenge.

Actually I could indeed think of a place where you are only allowed to
be present in case you are pushing a bicycle. Imagine a bicycle
adventure park that only contains bicycle roads. Let's say that the
terms of service declares that visitors must not leave their bikes
unattended (i.e., no parking).

Now let's pretend that there's a small bridge in the middle of the
park that includes a small stretch of stairs that has bicycle pushing
rails (or substitute with just a single wooden bridge in a bad shape
that has a bunch of long cracks that could easily lock your wheels if
you ride over it - true story, we had a bridge just like that). A sign
would be posted here that disallows bicycle riders from accessing it,
but pushing through would be possible.

How could you be walking on to this bridge if you were not in
possession of a bicycle in the first place?

/OFF: Yep, the included whip antenna of an RTL SDR can receive these
beacons from an impressive range.

On Thu, Jul 23, 2020 at 5:33 PM Matthew Woehlke
 wrote:
>
> On 23/07/2020 09.59, Philip Barnes wrote:
> > On Thu, 2020-07-23 at 09:35 -0400, Matthew Woehlke wrote:
> >> I'm trying (and failing) to imagine a road/path/whatever that you
> >> are allowed to walk on *iff* you are pushing a bicycle (or moped
> >> or...). Do you know of any examples?
> >
> > I cannot think of many roads where you can walk but not cycle, other
> > than pedestrianised streets in town centres but you can walk on lots of
> > footpaths where you can push a bicycle. Some are too long and totally
> > unsuitable.
> >
> > A few of examples from my local big town
> > https://www.mapillary.com/map/im/HW9qSNB-1JlkQAC3SH_gZQ
> > https://www.openstreetmap.org/way/23896048
> >
> > https://www.openstreetmap.org/way/350458507
> >
> > https://www.openstreetmap.org/way/318709194
>
> All of those examples appear to allow regular pedestrians (foot=yes),
> which is common. I am asking if there are any places where walking is
> allowed *only* if you are pushing a bicycle, i.e. "no bicycle, no
> access". IOW, where your joke about dogs isn't a joke.
>
> (OT: Airline transponders may be IFF — note the capitalization —
> although I wonder about that because I always think of IFF as more a
> military thing. I'm not sure if civilian transponders are really meant
> to *identify friend or foe*, or if they're more just "transponders".)
>
> On 23/07/2020 09.59, bkil wrote:
> > For example, bicycle=dismount should be understood that bicycle
> > access is only allowed if a rider dismounts. However, if we had to
> > write bicycle=dismount + foot=no, then the meaning basically becomes:
> > neither riding your bicycle nor walking is allowed here, which is
> > quite the opposite compared to what bicycle=dismount would mean if it
> > were placed alone on the POI. Hence the correct way to tag this
> > should be bicycle=no + foot=no.
>
> Right, that's what I was suggesting, because the only plausible
> interpretation I can come up with for foot=no + bicycle=dismount is that
> you may traverse the way [on foot] iff you are pushing a bicycle. The
> question was, does that ever actually happen? I'm not *quite* willing to
> rule it out...
>
> --
> Matthew

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

[Tagging] Map maintenance with StreetComplete - Preferred tagging

2020-07-23 Thread Tobias Zwick

Hello everyone

As you may or may not know, my microgrant proposal "Map maintenance with
StreetComplete" [1] was selected to be funded by the OSMF. So, I am
happy to have the oppurtunity to invest the time  extending the app,
hoping that it will help to keep the map up-to-date and unburden people
and communities invested in that topic.

I am pitching this here because there are three details on which I would
like to hear your input. Two of these are about tagging.

But first, how will it work?


So, what StreetComplete will do is to scan the map for whether certain
properties (tags) of map features haven't been surveyed for a certain
time. If this is the case, users will be prompted to answer the question
for that property again. For example, if the app ascertained that the
smoothness of a road hasn't been changed for 5 years, it would ask users
again about the smoothness of the road.

Challenges
--

Now, you might imagine that this is not so straightforward to implement,
and you would be right, for several reasons:

Firstly, the OSM API has no notion about when a particular property of
an element has last been changed, only for when the whole element has
last been changed. But elements are changed all the time for various
reasons. Roads for example tend to be changed especially often, splitted
up to accomodate bus routes, turn restrictions, when detailing
intersections, etc.

Secondly, there is only the date of the last change, but that doesn't
mean that is the date of the last survey. Even though that would be the
information we are interested in: when has the element last been checked
on-site?

Thirdly, the OSM API does not offer users to record solely that they
checked something and that it is still up to date. Any new record in OSM
must always come with a tagging change.

Solutions
-

In the absence of direct API support, fortunately the community came up
with a solution: Add the check_date tag to the element that has been
checked on a survey - or with the namespace if it concerns only a
certain tag of a map feature.

This works well and is actually already used by Streetcomplete in the
"Is this construction site finished?"-quest:
If the element as a whole hasn't been changed for 6 months *or* the
check_date key is present and its value is older than 6 months, the
quest is eligible to be asked again. When the user answers the question,
the check_date is set to current date.

Your input
==

Now here is where I would like your input:

1. Use check_date:smoothness or smoothness:check_date?
--
check_date with a namespace isn't used all that often yet, both variants
are used and thus there is no real winner yet. What variant do you
prefer and why? And most importantly, which variant would be most
consistent with existing tagging practices?

2. Always record check_date or avoid tagging it where not absolutely
necessary?
---
If something is resurveyed and it is acknowledged that nothing changed,
it is absolutely necessary to tag check_date. If something changed, it
is not strictly necessary because that the element changed as a whole is
itself also recorded.
But as already mentioned, elements can and do change all the time. One
can not assume that if an element has been changed that it has been
checked on-site. And even if one could, maybe not all the things were
checked but for example only the bus route relation, or maybe only the
presence of a sidewalk, or someone made the way a little more detailed etc.

The topic whether StreetComplete should only tag the minimum of what is
necessary to ensure functionality or always tag check_date (at least for
properties that are eligible for re-survey) was already subject to
discussion in the issue tracker here:
https://github.com/westnordost/StreetComplete/issues/1836

Maybe it is obvious that my opinion is that StreetComplete should always
tag check_date as it also adds valuable information for other surveyors
that do not use StreetComplete. Nevertheless, in the GitHub ticket
linked above, I played a bit of a devils advocate for the other point of
view - for being frugal with such meta-tags.

So, I'd like to collect what are the advantages and drawabacks of adding
check_date to all the tags surveyed on-site, with your help.

3. At what intervals should questions be asked?
---
Certain properties can be expected to usually not change in tangible
amount of time. For example, properties such as the structure of a
bridge, the levels and roof shape of buildings, street names and
housenumbers don't or change so infrequently that it is not worth
sending users every once in a blue moon to re-check the data. Others
will change more frequently, such as the smoothness of roads and ways or
anything related to businesses as they close and other shops open in

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

On Thu, 23 Jul 2020 at 16:35, Matthew Woehlke 
wrote:

Well off-topic now.

(OT: Airline transponders may be IFF — note the capitalization —
> although I wonder about that because I always think of IFF as more a
> military thing. I'm not sure if civilian transponders are really meant
> to *identify friend or foe*, or if they're more just "transponders".)
>

Transponders on civil aircraft implement a subset of the military
Mark XII IFF system.  This is no coincidence: military aircraft
should treat civilian aircraft as friendly...  Mode S (civilian)
and mode 5 (encrypted version of mode S for the military)
are used by TCAS to avoid collisions.  So civilian
transponders are IFF systems with restricted capabilities.

This is probably not a suitable place to discuss this further.

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?


On 23/07/2020 09.59, Philip Barnes wrote:

On Thu, 2020-07-23 at 09:35 -0400, Matthew Woehlke wrote:
I'm trying (and failing) to imagine a road/path/whatever that you 
are allowed to walk on *iff* you are pushing a bicycle (or moped

or...). Do you know of any examples?


I cannot think of many roads where you can walk but not cycle, other
than pedestrianised streets in town centres but you can walk on lots of
footpaths where you can push a bicycle. Some are too long and totally
unsuitable.

A few of examples from my local big town
https://www.mapillary.com/map/im/HW9qSNB-1JlkQAC3SH_gZQ
https://www.openstreetmap.org/way/23896048

https://www.openstreetmap.org/way/350458507

https://www.openstreetmap.org/way/318709194


All of those examples appear to allow regular pedestrians (foot=yes), 
which is common. I am asking if there are any places where walking is 
allowed *only* if you are pushing a bicycle, i.e. "no bicycle, no 
access". IOW, where your joke about dogs isn't a joke.


(OT: Airline transponders may be IFF — note the capitalization — 
although I wonder about that because I always think of IFF as more a 
military thing. I'm not sure if civilian transponders are really meant 
to *identify friend or foe*, or if they're more just "transponders".)


On 23/07/2020 09.59, bkil wrote:

For example, bicycle=dismount should be understood that bicycle
access is only allowed if a rider dismounts. However, if we had to
write bicycle=dismount + foot=no, then the meaning basically becomes:
neither riding your bicycle nor walking is allowed here, which is
quite the opposite compared to what bicycle=dismount would mean if it
were placed alone on the POI. Hence the correct way to tag this
should be bicycle=no + foot=no.


Right, that's what I was suggesting, because the only plausible 
interpretation I can come up with for foot=no + bicycle=dismount is that 
you may traverse the way [on foot] iff you are pushing a bicycle. The 
question was, does that ever actually happen? I'm not *quite* willing to 
rule it out...


--
Matthew

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

On Thu, 23 Jul 2020 at 15:27, bkil  wrote:

> Thank you, I do have a degree related to mathematics
>

That's something I didn't know.

and I do understand what *iff* means.
>

I would hope so.

However, that message didn't make sense with this interpretation,
>

It didn't make much sense to me with either interpretation, but I assumed
that if I could be bothered to read back in the thread then it might make
sense.  Or not.  That's why I asked if it made sense to you (or anyone
else) knowing what "iff" means.  Then again, maybe he was talking
about aircraft transponders (still makes no sense, but at least the
mental image of bikes having identify friend or foe transponders
is mildly amusing).

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

Thank you, I do have a degree related to mathematics and I do understand
what *iff* means. However, that message didn't make sense with this
interpretation, this is why I've clarified my answer and I hope I've
cleared up any misunderstanding.

On Thu, Jul 23, 2020 at 4:17 PM Paul Allen  wrote:

> On Thu, 23 Jul 2020 at 15:01, bkil  wrote:
>
>>
>>> I'm trying (and failing) to imagine a road/path/whatever that you are
>>> allowed to walk on *iff* you are pushing a bicycle (or moped or...). Do
>>> you know of any examples?
>>>
>>>
>> I don't quite understand what you are trying to get at with the question,
>>
>
> That "iff" was not a typo.  It's mathematical short-hand for "if and ONLY
> if."
> Does the question make sense now?
>
> --
> 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] Hiking "guideposts" painted on rocks, trees etc.

On Thu, 23 Jul 2020 at 14:51, Volker Schmidt  wrote:

> ... and if the fingers are nailed on a shed, a common practice in the
> mountains around here?
> No post? Or the building is the post?
>

Good question.  But it more closely resembles a guidepost than a blaze.
Whereas the things being shoe-horned into guidepost in this thread more
closely resemble blazes.  Elaborate blazes with text.  Not that I'm
arguing we should abuse either tag by using for other things that
go against expectations.

Since we already have blazes and guideposts, the argument that
we need to ram all the square pegs into a single round hole doesn't
fly.  We've already breached that barrier.  Virgin no longer.

So the question is do we want meaningful tags or misleading tags?

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

On Thu, 23 Jul 2020 at 15:01, bkil  wrote:

>
>> I'm trying (and failing) to imagine a road/path/whatever that you are
>> allowed to walk on *iff* you are pushing a bicycle (or moped or...). Do
>> you know of any examples?
>>
>>
> I don't quite understand what you are trying to get at with the question,
>

That "iff" was not a typo.  It's mathematical short-hand for "if and ONLY
if."
Does the question make sense now?

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

Re: [Tagging] amenity=customer_service RFC

Within the way drawn for the office building, you should place a separate
node for the office POI. This node should be one having the given access=*
tag. Although, I think if I can visit a public office, that usually implies
that I have access to the given building as well, we usually do not add
access=* to buildings.

On Thu, Jul 23, 2020 at 3:53 PM Volker Schmidt  wrote:

> Careful with "access".
> access=customers on an office building would imply you can drive into this
> building with any means of transport, provided you are a customer.
>
> On Thu, 23 Jul 2020 at 15:46, bkil  wrote:
>
>> On Thu, Jul 23, 2020 at 3:39 PM Volker Schmidt  wrote:
>>
>>> So it would have to be customer_service=yes|no at least.
>>> That would also permit to check which offices have been evaluated by
>>> mappers for the presence or less of customer_service.
>>>
>>>
>> access=customers/private would also solve this without having to invent a
>> new top level tag.
>> ___
>> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

> > I.e., bicycle=dismount means that you can proceed after you dismount,
> > however if a certain combination of other tags are also present
> (foot=no),
> > a data user would need to ignore this, making this more confusing than
> > necessary (bicycle=no).
>
> I'm trying (and failing) to imagine a road/path/whatever that you are
> allowed to walk on *iff* you are pushing a bicycle (or moped or...). Do
> you know of any examples?
>
>
I don't quite understand what you are trying to get at with the question,
but let me list a few places where I think bicycle=dismount is implicitly
encoded:
* footways;
* "road closed" (unless certain extensions are added below)
https://commons.wikimedia.org/wiki/File:Estonia_road_sign_311a.svg
* within buildings (train stations, subway stations - you are free to carry
your portable bike around here);
* one way streets from the wrong way (should push either on the sidewalk if
it exists or on the road).

Maybe I didn't make myself clear in that sentence. I referenced a statement
from a different tagging thread a few weeks ago.

The gist is that if a mapper encounters a given tag (like
bicycle=dismount), a given definite meaning should be understood. This may
be _refined_ by further tags on the same POI, especially subtags, like
highway=service + service=driveway. Meaning shall not be redefined, rather
made more specific in these cases. However, I can't say that
highway=service + not_really_service=yes, i.e., a certain combination of
independent tags may not carry a meaning that greatly contradicts with any
subset of the said tags.

For example, bicycle=dismount should be understood that bicycle access is
only allowed if a rider dismounts. However, if we had to write
bicycle=dismount + foot=no, then the meaning basically becomes: neither
riding your bicycle nor walking is allowed here, which is quite the
opposite compared to what bicycle=dismount would mean if it were placed
alone on the POI. Hence the correct way to tag this should be bicycle=no +
foot=no.

I really enjoyed Phil's joke and I recommend that you think about it as
well.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Philip Barnes

On Thu, 2020-07-23 at 09:35 -0400, Matthew Woehlke wrote:
> On 22/07/2020 19.05, bkil wrote:
> > But also consider that it wouldn't make sense to tag a motorway as
> > foot=no + bicycle=dismount (+ moped=dismount + mofa=dismount +
> > auto_rickshaw=no + agricultural=no), because the combination of
> > tags would
> > create a completely new meaning, and that is not a preferred
> > tagging
> > practice in OSM.
> > 
> > I.e., bicycle=dismount means that you can proceed after you
> > dismount,
> > however if a certain combination of other tags are also present
> > (foot=no),
> > a data user would need to ignore this, making this more confusing
> > than
> > necessary (bicycle=no).
> 
> I'm trying (and failing) to imagine a road/path/whatever that you
> are 
> allowed to walk on *iff* you are pushing a bicycle (or moped or...).
> Do 
> you know of any examples?
> 

I cannot think of many roads where you can walk but not cycle, other
than pedestrianised streets in town centres but you can walk on lots of
footpaths where you can push a bicycle. Some are too long and totally
unsuitable.


A few of examples from my local big town
https://www.mapillary.com/map/im/HW9qSNB-1JlkQAC3SH_gZQ
https://www.openstreetmap.org/way/23896048

https://www.openstreetmap.org/way/350458507

https://www.openstreetmap.org/way/318709194

Phil (trigpoint)


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

Re: [Tagging] amenity=customer_service RFC

2020-07-23 Thread Volker Schmidt

Careful with "access".
access=customers on an office building would imply you can drive into this
building with any means of transport, provided you are a customer.

On Thu, 23 Jul 2020 at 15:46, bkil  wrote:

> On Thu, Jul 23, 2020 at 3:39 PM Volker Schmidt  wrote:
>
>> So it would have to be customer_service=yes|no at least.
>> That would also permit to check which offices have been evaluated by
>> mappers for the presence or less of customer_service.
>>
>>
> access=customers/private would also solve this without having to invent a
> new top level tag.
> ___
> 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] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-23 Thread Mike Thompson

On Thu, Jul 23, 2020 at 3:31 AM Alan Mackie  wrote:
>
> Do we have any tagging for areas where e.g. open alcohol containers are
prohibited,  where firearms are specially prohibited* or disallows
possession of a recording device or camera? A separate 'specific item
banned' tag is starting to sound like it would avoid further muddying the
transport mode tags.
These are a very similar situation to the one regarding bicycles that we
are discussing because we have to differentiate between possession of the
item (and how exactly it is possessed - e.g. open vs. concealed carry, vs.
locked in trunk of vehicle of a firearm), and using the item (discharging
the firearm, consuming the alcohol).  For example, it is legal in many US
National Parks to carry a loaded firearm, but in most cases it is illegal
to discharge it while in the park.

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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

2020-07-23 Thread Volker Schmidt

... and if the fingers are nailed on a shed, a common practice in the
mountains around here?
No post? Or the building is the post?


On Thu, 23 Jul 2020 at 14:07, Paul Allen  wrote:

> On Thu, 23 Jul 2020 at 02:03, Warin <61sundow...@gmail.com> wrote:
>
>>
>> No. The material the guidepost is made from is of lesser importance to
>> the fact that it is a 'guidepost'.
>>
>
> That is one viewpoint.  It is something indicating the path of a route.
> Collect them all under one tag because they all specify that kind
> of information, no matter what they look like.  It makes overpass
> queries easier, etc.  That's why trail blazes are
> information=trail_blaze and not guidepost.  Ooops!
>
> Another viewpoint is that these things LOOK different even though they
> may convey the same information.  As waypoints, if you're looking for
> a signpost you may discount what looks like graffiti on a distant rock.
>
> These are signposts.  They are signs.  On posts.
> https://www.geograph.org.uk/photo/5901641
> https://www.geograph.org.uk/photo/4006975
> https://www.geograph.org.uk/photo/6191138
> https://www.geograph.org.uk/photo/6324438
> https://www.geograph.org.uk/photo/3507964
>
> What you are describing is not a signpost.  It's more of a blaze
> with text.  If I were insistent upon ramming a square peg into
> a round hole, I'd abuse trail_blaze rather than guidepost.
> Because THERE IS NO POST.
>
> --
> 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] amenity=customer_service RFC

On Thu, Jul 23, 2020 at 3:39 PM Volker Schmidt  wrote:

> So it would have to be customer_service=yes|no at least.
> That would also permit to check which offices have been evaluated by
> mappers for the presence or less of customer_service.
>
>
access=customers/private would also solve this without having to invent a
new top level tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=customer_service RFC

2020-07-23 Thread Volker Schmidt

You are trying to address a reaIly (numerically) big problem.
I would have thought anything with office=* may need an indication of the
presence or less of customer service.
Most likely anything that is shop=* would implicitly offer customer service.
So for the 700k office=* we need to retrofit an indication, whether they
offer or not customer service.
As I said above, this looks to me like a gigantic task to start with, but I
also see a problem with the proposed tag:
If an office offers customer service I add amenity=customer_service, but
how do I indicate that they don't?
So it would have to be customer_service=yes|no at least.
That would also permit to check which offices have been evaluated by
mappers for the presence or less of customer_service.

On Thu, 23 Jul 2020 at 15:10, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Yes, and in such cases shop should be used.
>
> But in some cases where office=* is used
> there is no known to me tagging scheme
> covering this, such as car of energy
> company customer service location.
>
> It is place where you may handle overdue
> bill payment plans or attaching new property
> to power network or dispute bill.
>
> Is there shop tag for that?
> At least in my region people always tag
> it work office, and it seems to not be
> really fitting for shop key.
>
>
> 23 Jul 2020, 14:06 by si...@poole.ch:
>
> Wouldn't most, if not all, cases where this would be used already be
> covered by the corresponding (and likely already in use) shop=* value?
> Am 23.07.2020 um 12:49 schrieb Mateusz Konieczny via Tagging:
>
> See https://wiki.openstreetmap.org/wiki/Proposed_features/Customer_service
>
> Feedback, complaints, edits to the page (especially concerning grammar,
> typos and clarity)
> are highly welcomed
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?


On 22/07/2020 19.05, bkil wrote:

But also consider that it wouldn't make sense to tag a motorway as
foot=no + bicycle=dismount (+ moped=dismount + mofa=dismount +
auto_rickshaw=no + agricultural=no), because the combination of tags would
create a completely new meaning, and that is not a preferred tagging
practice in OSM.

I.e., bicycle=dismount means that you can proceed after you dismount,
however if a certain combination of other tags are also present (foot=no),
a data user would need to ignore this, making this more confusing than
necessary (bicycle=no).


I'm trying (and failing) to imagine a road/path/whatever that you are 
allowed to walk on *iff* you are pushing a bicycle (or moped or...). Do 
you know of any examples?


--
Matthew

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

Re: [Tagging] amenity=customer_service RFC

On Thu, 23 Jul 2020 at 13:09, Simon Poole  wrote:

> Wouldn't most, if not all, cases where this would be used already be
> covered by the corresponding (and likely already in use) shop=* value?
>
One use that comes to mind, where shop is inappropriate, is my county
council.  It has small (one- or two-person) offices in major towns that
deal with queries, complaints, accept rent payment and council
tax payment, hand out rolls of recycling bags, etc.  It also has
a headquarters with many buildings housing various departments,
most of which do not accept walk-ins (but may invite people to
attend in special circumstances).

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

Re: [Tagging] amenity=customer_service RFC

2020-07-23 Thread Mateusz Konieczny via Tagging

Yes, and in such cases shop should be used.

But in some cases where office=* is used
there is no known to me tagging scheme 
covering this, such as car of energy 
company customer service location.

It is place where you may handle overdue
bill payment plans or attaching new property
to power network or dispute bill.

Is there shop tag for that?
At least in my region people always tag
it work office, and it seems to not be
really fitting for shop key.

23 Jul 2020, 14:06 by si...@poole.ch:

>
> Wouldn't most, if not all, cases where this would be used already  be 
> covered by the corresponding (and likely already in use) shop=*  value?
>
> Am 23.07.2020 um 12:49 schrieb Mateusz  Konieczny via Tagging:
>
>> See >> https://wiki.openstreetmap.org/wiki/Proposed_features/Customer_service
>>
>> Feedback, complaints, edits to the page (especiallyconcerning 
>> grammar, typos and clarity) 
>> are highly welcomed
>>
>> ___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] amenity=customer_service RFC

Could you perhaps use existing tags instead of this?
office=company + access=customers
vs.
office=company + access=private

On Thu, Jul 23, 2020 at 2:44 PM Philip Barnes  wrote:

> On Thu, 2020-07-23 at 14:06 +0200, Simon Poole wrote:
>
> Wouldn't most, if not all, cases where this would be used already be
> covered by the corresponding (and likely already in use) shop=* value?
>
> It is also a confusing term to have chosen as prior to reading your page I
> had a Customer Services desk in my mind. Typically this is where you go to
> exchange purchases, get refunds.
>
> Phil (trigpoint)
> ___
> 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] amenity=customer_service RFC

2020-07-23 Thread Philip Barnes

On Thu, 2020-07-23 at 14:06 +0200, Simon Poole wrote:
> Wouldn't most, if not all, cases where this would be used already
>   be covered by the corresponding (and likely already in use)
> shop=*
>   value?
> 
> 
> 
It is also a confusing term to have chosen as prior to reading your
page I had a Customer Services desk in my mind. Typically this is where
you go to exchange purchases, get refunds.

Phil (trigpoint)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=customer_service RFC

2020-07-23 Thread Simon Poole

Wouldn't most, if not all, cases where this would be used already be
covered by the corresponding (and likely already in use) shop=* value?

Am 23.07.2020 um 12:49 schrieb Mateusz Konieczny via Tagging:
> See https://wiki.openstreetmap.org/wiki/Proposed_features/Customer_service
>
> Feedback, complaints, edits to the page (especially concerning
> grammar, typos and clarity)
> are highly welcomed
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.