Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

[Warin]

On 19/05/18 13:06, osm.tagg...@thorsten.engler.id.au wrote:


-Original Message-
From: Warin <61sundow...@gmail.com>
Sent: Saturday, 19 May 2018 12:33
To: Tag discussion, strategy and related tools

Think I have raised this before but not come to any firm conclusion
myself.

I think that tagging

seasonal=summer

intermittent= yes


leads to confusion. Is the summer flow intermittent? Or is ther
regular
summer flow with intermittent flow at other times of year?

It may be better to tag

seasonal:intermittent=summer


or

seasonal=summer

seasonal:intermittent=winter;autumn;spring

I'm not sure if the two tags need to or should be mixed like that.

It might be better to just allow time frames (seasons as well as month ranges) 
in addition to yes/no values for both seasonal and intermittent.

So:

seasonal=summer
intermittent=summer

means it's only flowing in the summer (from seasonal), and then only 
intermittent.

or

seasonal=summer
intermittent=autumn-spring or autumn;winter;spring or march-november (maybe 
mar-nov ?)


I like that. Month ranges I have not thought of .. seasons can vary from year 
to year so I like that vagueness.



means it's always flowing in the summer, and intermittent the rest of the year.

The concept of seasons becomes less meaningful the closer you get to the equator, so allowing month based 
time frames would make sense. Maybe also the concept of tropical "wet" or "dry" season. 
Perhaps "monsoon" season as well in areas where that is a prominent weather pattern.


"Monsoon" does not say if it is the wet part or dry part of the monsoon. "Wet" and 
"dry are seasonal values in use and can be used for monsoonal areas.



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

Re: [Tagging] tagging arbiters (gone OT)

[Kevin Kenny]

On Fri, May 18, 2018 at 10:38 PM,  wrote:

> It’s not an carto-osm bug, it’s a level lower:
>
>
>
> https://github.com/openstreetmap/osm2pgsql/issues/230
>
>
>
> If that ever gets implemented properly, then carto-osm and other data
> users can make use of it…
>
>
>
> *From:* Paul Johnson 
> *Sent:* Saturday, 19 May 2018 12:12
> *To:* Tag discussion, strategy and related tools <
> tagging@openstreetmap.org>
> *Subject:* Re: [Tagging] tagging arbiters (gone OT)
>
>
>
> On Mon, May 14, 2018 at 8:03 AM, Dave F 
> wrote:
>
> On 13/05/2018 22:34, Kevin Kenny wrote:
>
> I've long said that the final arbiters of tagging should be... the people
> who implement the routers, renderers, navigation systems,. search engines,
> and so on
>
>
> No.
>
> We already have the case where Carto-OSM are requesting duplicated tags on
> ways that are already in relations as they're unwilling/unable to right
> code that manipulates relation data.
>
>
>
> Is that a bug in the carto-osm github right now?  Even the Linux kernel
> killed the ext filesystem dinosaur once ext4 became a thing, and by then it
> already overstayed it's welcome once ext2 was widespread.  Killing the
> route-refs-on-ways dinosaur is long overdue.
>

Paul: I agree with you that in the specific instance you cite, the request
from the downstream data consumers is wrongheaded.  (I include a more
technical description of my understanding of the problem below.)

In any case, I intended my remark to address the "what" rather than the
"how" - not the highly technical aspect of how relations interact with ways
and nodes, but rather "should objects of this type be distinguished from
objects of that type, and if so, how?" I've seen that go wrong on both
sides of the fence.

On the one hand, I have cases like the (still unsolved) "public land,
permit required to enter", which I wish to distinguish and render
differently on my maps from both "public land, open without prior
arrangement", and "private land". Whenever I've brought that up on this
list, I've been shouted down by people who insist that those three
categories should be only two. When I reply that I perceive three
categories, and wish to render them on maps that I produce, I've even been
accused of wishing to "tag for the renderer." I'm not trying to tell lies
in the tagging in order to have things render correctly in Carto. No
conceivable renderer can show as being different two objects that are not
tagged differently in some way!

On the other hand, I see endless discussions here in which people geek out
about whether 'gravel' means actual gravel, or railway ballast, what the
difference is between a draw bridge and a bascule bridge, and similar
niggling details where I can barely imagine any router, navigator, or map
renderer ever being able to make use of those fine details, much less how
the community could maintain that level of detail for an entire planet.

So - if YOU have a use for tagging that's not in our shared understanding,
well, "any tag you like", but I'd really appreciate it if, for instance,
the Wiki pages that discuss particular tags also were to discuss what the
use cases are! Right now we leap both to dismiss actual use cases "I'm
rendering a map that wishes to show ..." and invent useless tagging
"Someone, someday may care about the difference between ..."

That's where I insist that the data consumers rule!

Now, some technical details about route relations:

Right now, tagging route refs in Mapnik, when routes can be coincident, is
an unmitigated disaster. I know: I render my own maps from time to time.

The data model with the ref=* tags on route relations only is fine. What
isn't fine is that osm2pgsql and osmosis leave us with a schema that leaves
Mapnik no easy way to execute the query that it needs to render the highway
shields: "What are the the strings of ways that have identical sets of
routes?"

It's bad enough that what I've resorted to is to create an auxiliary,
intentionally denormalized, SQL table that has columns:

idx (an arbitrary integer to serve as primary key)
way (the geometry)
highway (copied from the highway=* tag on the underlying way)
route=1 (the value of the "route=*" key on the first containing relation)
network_1 (the value of the "network" key on the first containing relation)
ref_1 (the value of the "ref" key on the first containing relation)
.
.
.
route_8
network_8
ref_8

I've never seen more than eight routes overlaid, and that appears to be the
maximum that mapnik can handle in a shield cluster.

For each of the "route, network, ref" tuples, I use external scripts to
create an SVG file with the highway shield - derived at some remove from
Phil! Gold's 'osm-shields' project. I don't use Phil!'s clustering - I use
Mapnik's shield renderer instead. Phil!'s stored procedures are
incompatible with the read-only database connection used in current Mapnik,
so I avoid those as 

Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

[Tod Fitch]

> On May 18, 2018, at 7:33 PM, Warin <61sundow...@gmail.com> wrote:
> 
> Hi,
> 
> I seek comments and thoughts on
> 
> -
> 
> Seasonal:
> 
> The seasonal tag in well established. I don't think there is much confusion 
> with it.
> 
> 
> ---
> 
> Intermittent:
> 
> The intermittent tag continues to be confused with seasonal.
> 
> Possibly this is because some want to use it to indicate that a follow is 
> both seasonal and intermittent?
> 
> 
> -
> 
> Ephemeral:
> 
> There is also ephemeral being used with stream=ephemeral. This cannot be used 
> with other water features e.g. lakes.
> 
> I think the tag ephemeral=yes could be used, other ideas for tagging are 
> flow=ephemeral, water=ephemeral ...
> 
> 
> ---
> 
> Combinations with seasonal?
> 
> Think I have raised this before but not come to any firm conclusion myself.
> 
> I think that tagging
> 
> seasonal=summer
> 
> intermittent= yes
> 
> 
> leads to confusion. Is the summer flow intermittent? Or is ther regular 
> summer flow with intermittent flow at other times of year?
> 
> It may be better to tag
> 
> seasonal:intermittent=summer
> 
> 
> or
> 
> seasonal=summer
> 
> seasonal:intermittent=winter;autumn;spring
> 

In the semi-arid areas I’ve lived in there are “waterways” that, if they carry 
water, only have water in them during the rainy season. But, they may not carry 
water throughout the rainy season. Or even carry water at all every rainy 
season. So I can see some merit to indicating the seasonality of intermittent 
water flow.

If I recall correctly, there was some discussion a while back about using 
ephemeral as either a key or as a value to the intermittent key to cover the 
case where even during a rainy season it would be rare to encounter water and 
if you did the water was likely to be present for only a few hours. But looking 
at the wiki and taginfo I don’t see it being used as a value for intermittent. 
There are only 82 instances of it being used as a key all with the value “yes". 
And I don’t recall the final “bike shedded” result of the mail list discussion. 
Apparently it did not take hold. I personally thing “ephemeral” should be a 
accepted value for the intermittent tag but apparently I am alone in that 
opinion.

In any case, your “seasonal:intermittent=summer” tag could also be confusing. 
Does that mean that the only time you are likely to encounter water is in 
summer but it is only intermittent then? Or does it mean that there is likely 
to be water in it during fall, winter and spring but it becomes intermittent in 
summer? Basically has the same issue as the current tagging you are noting as 
being confusing.

In reading the current wiki, I think the tagging should be a logical and 
operation. If there is a seasonal tag, it indicates the season water may be 
present. Then if there is a intermittent tag it indicates that even during the 
season water is present it is intermittent.



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

Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

[osm.tagging]

> -Original Message-
> From: Warin <61sundow...@gmail.com>
> Sent: Saturday, 19 May 2018 12:33
> To: Tag discussion, strategy and related tools
> 
> Think I have raised this before but not come to any firm conclusion
> myself.
> 
> I think that tagging
> 
> seasonal=summer
> 
> intermittent= yes
> 
> 
> leads to confusion. Is the summer flow intermittent? Or is ther
> regular
> summer flow with intermittent flow at other times of year?
> 
> It may be better to tag
> 
> seasonal:intermittent=summer
> 
> 
> or
> 
> seasonal=summer
> 
> seasonal:intermittent=winter;autumn;spring

I'm not sure if the two tags need to or should be mixed like that.

It might be better to just allow time frames (seasons as well as month ranges) 
in addition to yes/no values for both seasonal and intermittent.

So:

seasonal=summer
intermittent=summer

means it's only flowing in the summer (from seasonal), and then only 
intermittent.

or

seasonal=summer
intermittent=autumn-spring or autumn;winter;spring or march-november (maybe 
mar-nov ?)

means it's always flowing in the summer, and intermittent the rest of the year.

The concept of seasons becomes less meaningful the closer you get to the 
equator, so allowing month based time frames would make sense. Maybe also the 
concept of tropical "wet" or "dry" season. Perhaps "monsoon" season as well in 
areas where that is a prominent weather pattern.














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

Re: [Tagging] tagging arbiters (gone OT)

[osm.tagging]

It’s not an carto-osm bug, it’s a level lower:

 

https://github.com/openstreetmap/osm2pgsql/issues/230

 

If that ever gets implemented properly, then carto-osm and other data users can 
make use of it…

 

From: Paul Johnson  
Sent: Saturday, 19 May 2018 12:12
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] tagging arbiters (gone OT)

 

On Mon, May 14, 2018 at 8:03 AM, Dave F  wrote:

On 13/05/2018 22:34, Kevin Kenny wrote:



I've long said that the final arbiters of tagging should be... the people who 
implement the routers, renderers, navigation systems,. search engines, and so on


No.

We already have the case where Carto-OSM are requesting duplicated tags on ways 
that are already in relations as they're unwilling/unable to right code that 
manipulates relation data.

 

Is that a bug in the carto-osm github right now?  Even the Linux kernel killed 
the ext filesystem dinosaur once ext4 became a thing, and by then it already 
overstayed it's welcome once ext2 was widespread.  Killing the 
route-refs-on-ways dinosaur is long overdue. 

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

[Tagging] Seasonal, intermittent, and ephemeral water tags

[Warin]

Hi,

I seek comments and thoughts on

-

Seasonal:

The seasonal tag in well established. I don't think there is much 
confusion with it.



---

Intermittent:

The intermittent tag continues to be confused with seasonal.

Possibly this is because some want to use it to indicate that a follow 
is both seasonal and intermittent?



-

Ephemeral:

There is also ephemeral being used with stream=ephemeral. This cannot be 
used with other water features e.g. lakes.


I think the tag ephemeral=yes could be used, other ideas for tagging are 
flow=ephemeral, water=ephemeral ...



---

Combinations with seasonal?

Think I have raised this before but not come to any firm conclusion myself.

I think that tagging

seasonal=summer

intermittent= yes


leads to confusion. Is the summer flow intermittent? Or is ther regular 
summer flow with intermittent flow at other times of year?


It may be better to tag

seasonal:intermittent=summer


or

seasonal=summer

seasonal:intermittent=winter;autumn;spring











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

Re: [Tagging] tagging arbiters (gone OT)

[Paul Johnson]

On Mon, May 14, 2018 at 8:03 AM, Dave F  wrote:

> On 13/05/2018 22:34, Kevin Kenny wrote:
>
> I've long said that the final arbiters of tagging should be... the people
> who implement the routers, renderers, navigation systems,. search engines,
> and so on
>
>
> No.
>
> We already have the case where Carto-OSM are requesting duplicated tags on
> ways that are already in relations as they're unwilling/unable to right
> code that manipulates relation data.
>

Is that a bug in the carto-osm github right now?  Even the Linux kernel
killed the ext filesystem dinosaur once ext4 became a thing, and by then it
already overstayed it's welcome once ext2 was widespread.  Killing the
route-refs-on-ways dinosaur is long overdue.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

[osm.tagging]

As I said, it has poles, areas people wait, a fixed route, a repeating 
timetable, there is a "driver" and it's purpose is specifically to transport 
people from one location to another. The fact that you have to put in personal 
effort (walking) during the transportation within this framework doesn't make 
it less of a "transport" in my opinion.

And if the "guided walking tours" have all the same features, and their primary 
purpose is to movement from one location to another, then, yes. If it's a hike 
that's primarily about the activity of walking or looking at things, and you 
end up in the same location again, then no.

> -Original Message-
> From: Andrew Davidson 
> Sent: Saturday, 19 May 2018 10:41
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop
> 
> On 19/05/18 09:47, osm.tagg...@thorsten.engler.id.au wrote:
> > I agree that it definitely is "transport" and that it has all the
> features (pole, waiting area, timetable, fixed route) that make it
> very suitable to map as public_transport.
> >
> 
> Huh? I would have thought that a key requirement would be some form
> of transport. What's the next thing we're going to be calling
> public transport? Guided walking tours?
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

[Andrew Davidson]

On 19/05/18 09:47, osm.tagg...@thorsten.engler.id.au wrote:

I agree that it definitely is "transport" and that it has all the features 
(pole, waiting area, timetable, fixed route) that make it very suitable to map as 
public_transport.



Huh? I would have thought that a key requirement would be some form of 
transport. What's the next thing we're going to be calling public 
transport? Guided walking tours?


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

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

[osm.tagging]

I agree that it definitely is "transport" and that it has all the features 
(pole, waiting area, timetable, fixed route) that make it very suitable to map 
as public_transport.

The only thing we have to decide upon is how "public" a public_transport must 
be.

Does it have to be available to all members of the public that are willing to 
pay for it? Or is it acceptable to map something as public_transport if there 
is an additional requirement (being a student at a particular school in this 
case)? Are there any other things mapped as public_transport already that have 
additional conditions for usage?

Personally, I'm fine with still considering this as public_transport, and hence 
map a walking bus as such. We might just have to come up with a tag that allows 
specifying what additional restrictions apply for potential passengers.

> -Original Message-
> From: marc marc 
> Sent: Saturday, 19 May 2018 08:19
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop
> 
> Le 18. 05. 18 à 17:14, Jo a écrit :
> >
> > 2018-05-18 17:11 GMT+02:00 Lorenzo Stucchi
> >
> > After the discussion about that a walking school bus is not a
> > public transport, so the proposal is to change the tag to
> amenity,
> > like for taxi rank.
> >
> >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Walkingbus_st
> op
> >
>  top
> > >
> >
> > Do I understand correctly that you are not planning to map the
> itineraries?
> >
> 
> I don't understand why it's not a PT.
> Of course no vehicule is used.
> but with some stop (including a pole and "people waiting there"),
> timetable, itinery, and a "walk driver", imho it's the same as if
> was a bus route.
> Some use the word "pédibus" (pédi = by foot)
> 
> wiki said :
> https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
> Use public_transport=platform to identify the places where
> passengers wait for public transport of any type
> 
> imho I don't see why the place where 20 childeren waiting the "walk
> driver" to travel with him is not a public_transport=platform but
> the same passengers waiting at the same place for the same driver
> with a bus is a valid public_transport=platform the same apply to
> the route where a relation type=route route=foot and all other PTv2
> tag look like good imho.
> 
> Lorenzo wait more than one reply before changing the propal :)
> 
> Regards,
> MArc
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Tagging] marking missing opening hours signs

[Mateusz Konieczny]

18. May 2018 21:56 by pla16...@gmail.com :

> These days, wouldn't opening_hours:sign=no be the preferred way to go? 

 This is my favorite at this moment. I plan to modify proposal to use this one.





> it's possible that the hours are on the site's Farcebook page but there is no 
> physical
> sign.

 Yes, it is possible but it is not changing that it is easily checkable during 
survey 

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

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

[marc marc]

Le 18. 05. 18 à 17:14, Jo a écrit :
> 
> 2018-05-18 17:11 GMT+02:00 Lorenzo Stucchi 
> 
> After the discussion about that a walking school bus is not a 
> public transport, so the proposal is to change the tag to amenity,
> like for taxi rank.
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Walkingbus_stop 
> 
> 
> Do I understand correctly that you are not planning to map the itineraries?
> 

I don't understand why it's not a PT.
Of course no vehicule is used.
but with some stop (including a pole and "people waiting there"), 
timetable, itinery, and a "walk driver", imho it's the same as if was a 
bus route.
Some use the word "pédibus" (pédi = by foot)

wiki said :
https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform
Use public_transport=platform to identify the places where passengers 
wait for public transport of any type

imho I don't see why the place where 20 childeren waiting the "walk 
driver" to travel with him is not a public_transport=platform
but the same passengers waiting at the same place for the same driver
with a bus is a valid public_transport=platform
the same apply to the route where a relation type=route route=foot
and all other PTv2 tag look like good imho.

Lorenzo wait more than one reply before changing the propal :)

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

Re: [Tagging] marking missing opening hours signs

[marc marc]

Le 18. 05. 18 à 21:17, Mateusz Konieczny a écrit :
> 18. May 2018 21:03 by marc_marc_...@hotmail.com 
> 
>> for ex unsigned=opening_hours
> It would be problematic as soon as there is more than one unsigned 
> parameter.

we can use the common ";" separator for that
unsigned=key1;key2;key3
for ex unsigned=housenumber;opening_hours

>> or unsigned:opening_hours=yes (maybe strange due to "one only" value)
> 
> Seems OK, but I still prefer opening_hours_sign=no - it seems simpler.

of course it's simpler.
but if every key have it's own logic, tools like streetcomplete need to 
build a long list of several "logic" in stead of being able to make
one logic for all tag.
unsigned=yes was already in use to said that a feature doesn't have a 
name (>1000 uses)
I myself also use it on building to said that a building that should 
have a housenmber doesn't have an housenumber sign
So it's easy to extend to have one-only schema
for all related sign that faild to be found by survey.

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

Re: [Tagging] marking missing opening hours signs

[Paul Allen]

On Fri, May 18, 2018 at 8:17 PM, Mateusz Konieczny 
wrote:

Seems OK, but I still prefer opening_hours_sign=no - it seems simpler.
>

These days, wouldn't opening_hours:sign=no be the preferred way to go?
Also,
it's possible that the hours are on the site's Farcebook page but there is
no physical
sign.

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

Re: [Tagging] marking missing opening hours signs

[Mateusz Konieczny]

18. May 2018 21:03 by marc_marc_...@hotmail.com 
:


> for ex unsigned=opening_hours




It would be problematic as soon as there is more than one unsigned parameter.


 


> or unsigned:opening_hours=yes (maybe strange due to "one only" value)
>




Seems OK, but I still prefer opening_hours_sign=no - it seems simpler.

But I am quite biased here, so if anyone disagrees - please comment.

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

Re: [Tagging] marking missing opening hours signs

[marc marc]

Le 18. 05. 18 à 20:46, Mateusz Konieczny a écrit :
> record that some objects miss opening hours sign.
> I started using opening_hours_sign=no

use/extend unsigned key and/or into a namespace
https://wiki.openstreetmap.org/wiki/Key:unsigned

for ex unsigned=opening_hours
or unsigned:opening_hours=yes (maybe strange due to "one only" value)

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

[Tagging] marking missing opening hours signs

[Mateusz Konieczny]

One may want to walk along the street and map info from available opening hour 
signs. 
In this situation it may be useful to record that some objects miss opening 
hours sign.

Such tag would allow to prefer objects with completely unknown opening hours 


over ones where opening hours are unknown and more complicated to obtain.




I started using opening_hours_sign=no for this purpose and created

https://wiki.openstreetmap.org/wiki/Proposed_features/opening_hours_sign%3Dno 





Comments are welcomed.

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

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

[Jo]

2018-05-18 17:11 GMT+02:00 Lorenzo Stucchi :

> Hi,
>
> After the discussion about that a walking school bus is not a  public
> transport, so the proposal is to change the tag to amenity, like for taxi
> rank.
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Walkingbus_stop
>
>
Do I understand correctly that you are not planning to map the itineraries?

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

Re: [Tagging] Feature Proposal - RFC - Walkingbus_stop

[Lorenzo Stucchi]

Hi,

After the discussion about that a walking school bus is not a public transport, 
so the proposal is to change the tag to amenity, like for taxi rank.

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

Hi,
Lorenzo Stucchi

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

Re: [Tagging] access=disabled

[Erkin Alp Güney]

access=disabled sounds much like access=disallowed.


18-05-2018 10:03 tarihinde osm.tagg...@thorsten.engler.id.au yazdı:
> With emergency and disabled as part of access restrictions, they central 
> question becomes, are these access tag values (like yes, no, private, 
> destination, delivery, customers, ...) or transport modes (like foot, 
> bicycle, motor_vehicle, ...)
>
> access=no
> emergency=yes
>
> implies that it is a transport mode. 
>
> While:
>
> vehicle=emergency
> foot=yes
>
> an access tag value.
>
> Personally, I feel that disabled and emergency sound more like access tag 
> values (similar to customer, agricultural, forestry) than transport modes.
>
> But I've now noticed that emergency and disabled ARE actually documented 
> under https://wiki.openstreetmap.org/wiki/Key:access but as transport modes.
>
>
>> -Original Message-
>> From: Andrew Davidson 
>> Sent: Friday, 18 May 2018 16:24
>> To: tagging@openstreetmap.org
>> Subject: Re: [Tagging] access=disabled
>>
>> On 18/5/18 16:03, Warin wrote:
>>> On 18/05/18 15:44, osm.tagg...@thorsten.engler.id.au wrote:
 "disabled" is not one of the access types documented on the wiki.
>>> "emergency" is not documented either.
>>> As there are over 400 uses of it .. I am tempted to document it ..
>>> along with emergency - I have used both.
>> Why not:
>>
>> access=no/private/etc
>> emergency=yes
>>
>> there are 28,400 of these, rather than inventing your own?
>>
>>
>> ___
>> 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] access=disabled

[osm.tagging]

With emergency and disabled as part of access restrictions, they central 
question becomes, are these access tag values (like yes, no, private, 
destination, delivery, customers, ...) or transport modes (like foot, bicycle, 
motor_vehicle, ...)

access=no
emergency=yes

implies that it is a transport mode. 

While:

vehicle=emergency
foot=yes

an access tag value.

Personally, I feel that disabled and emergency sound more like access tag 
values (similar to customer, agricultural, forestry) than transport modes.

But I've now noticed that emergency and disabled ARE actually documented under 
https://wiki.openstreetmap.org/wiki/Key:access but as transport modes.


> -Original Message-
> From: Andrew Davidson 
> Sent: Friday, 18 May 2018 16:24
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] access=disabled
> 
> On 18/5/18 16:03, Warin wrote:
> > On 18/05/18 15:44, osm.tagg...@thorsten.engler.id.au wrote:
> >> "disabled" is not one of the access types documented on the wiki.
> >
> > "emergency" is not documented either.
> > As there are over 400 uses of it .. I am tempted to document it ..
> > along with emergency - I have used both.
> 
> Why not:
> 
> access=no/private/etc
> emergency=yes
> 
> there are 28,400 of these, rather than inventing your own?
> 
> 
> ___
> 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] access=disabled

[Andrew Davidson]

On 18/5/18 16:03, Warin wrote:

On 18/05/18 15:44, osm.tagg...@thorsten.engler.id.au wrote:

"disabled" is not one of the access types documented on the wiki.


"emergency" is not documented either.
As there are over 400 uses of it .. I am tempted to document it .. along 
with emergency - I have used both.


Why not:

access=no/private/etc
emergency=yes

there are 28,400 of these, rather than inventing your own?


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

Re: [Tagging] access=disabled

[Warin]

On 18/05/18 15:44, osm.tagg...@thorsten.engler.id.au wrote:

"disabled" is not one of the access types documented on the wiki.


"emergency" is not documented either.
As there are over 400 uses of it .. I am tempted to document it .. along with 
emergency - I have used both.




I would say setting capacity and capacity:disabled to the same value makes it 
clear already that the whole parking lot is only for disabled parking, and it 
follows a documented tagging scheme that relevant data consumers should already 
be processing correctly.


-Original Message-
From: John Willis 
Sent: Friday, 18 May 2018 13:59
To: Tag discussion, strategy and related tools

Subject: Re: [Tagging] access=disabled



Javbw


On May 10, 2018, at 9:19 AM, Warin <61sundow...@gmail.com> wrote:

Hi,

I'm tagging a 'disabled parking area' - these are fairly common

in my country.

I know I am just jumping in - but this is also something I am
interested in.

I know if we have a big parking lot waiting the a few disabled
spots along an isle near the store entrance, than
capacity:disabled=4 added to a normal parking lot is appropriate.

But the instances I am trying to map are large disabled-only lots.
They (sometimes) have a gate that the security guard opens,
allowing anyone with a disabled plackerd to enter. It is a
separately mappable lot near the normal access=customers. Most of
them are physically separated from any other parking by kerbs and
shrubs.

I really think access=disabled is appropriate for this parking lot.
All others are denied.

Having to map space-by-space to just show that this *lot* is
disabled-only seems weird.

Javbw
___
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