Re: [Tagging] How to tag entire group of rentable holiday cottages?

[John Sturdy]

How about "holiday park"?  A google search for that brings up some caravan
parks but also some with chalets / "lodges".


On Tue, Dec 15, 2020 at 8:53 AM Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

>
>
>
> Dec 15, 2020, 03:33 by graemefi...@gmail.com:
>
> On Mon, 14 Dec 2020 at 21:28, Paul Allen  wrote:
>
>
> I can't think of an English term, other than "holiday cottages."  These
> places
> generally call themselves "Foo Holiday Cottages" or "Foo Holidays" or
> "Foo Farm Cottages" or things like that.
>
>
> I'm with Paul for Holiday Cottages.
>
> How about tagging the whole area as tourism=chalet + name=Foo Cottages +
> capacity=25
> then tagging each individual cottage / cabin as either
> building=cabin / bungalow + name=xxx?
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dcabin
>
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dbungalow
>
>
> I am fine with that and I plan to restore this tagging recommendation
> unless someone will proposed a better one.
> ___
> 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] OHV greater than 50 inches (wide)

[John Willis via Tagging]

I would say that is a “motor_vehecle”

https://wiki.openstreetmap.org/wiki/Key:motor_vehicle

Javbw

> On Sep 2, 2020, at 5:33 AM, Mike Thompson  wrote:
> 
> 
> 
> In specifying access constraints for the roads it manages, the US Forest 
> service makes a distinction between ATVs, highway vehicles, and "OHVs > 50"."
> The first two categories correspond to the tags motorcar=* and atv=* I think, 
> but I have not been able to find an existing tag that corresponds to "OHVs > 
> 50"."  There is an ohv=* tag, but it seems to apply to all OHVs regardless of 
> width as well as motorcycles.
> 
> What do you recommend?
> 
> 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

[Tagging] Intermittent highways?

[John Sturdy]

I've been adding some detail to a site that is used annually for a festival
(not happening this year because of Covid-19), where there are paths in the
same place year after year, but the paths are not there when the festival
is not happening, although increased wear on the ground around them is
probably visible much of the time.

Does it make sense to map such paths, perhaps borrowing the "intermittent"
tag from waterway tagging?

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

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[John Willis via Tagging]

Javbw

> On May 25, 2020, at 1:28 PM, Andrew Harvey  wrote:
> 
>> We do have that: `sac_scale=hiking`

And that is a good example of bad tagging I want to correct. 

There are more people walking local wilderness trails with their dog in a 
single day than all “backpackers” on earth in a year. Few-to-none of these are 
“day-hike” or “trekking” routes, yet they are most definitely “trails”. I do 
not need to know the sac scale to tag it as a trail. 

And How are those routes “hiking”? There are plenty of trails not meant for 
hiking. Hiking is a leisure pastime. A trail is type of way. 

I can tag a track without defining it’s tracktype=* it’s a track - _and then_ 
further defined by tracktype=* .

Do I have to know the width to tag a road? Do I need to know the number of 
stairs or the incline of the steps to tag it as steps? 

No. 

It’s a residential road. Steps. A cycleway. A trail. 

The attributes of the way do not define it as that type of way - a named tag 
anyone can use does, including someone who can’t define its sac scale - or has 
no idea what the heck that is. 

Trails should Have _never_ been lumped in with path. It was a _horrible_ 
decision, like motorways and driveways sharing a main tag because cars use 
both. 

At least sub-tagging them to be able to easily separate them _and then_, when 
possible define further characteristics __when possible__ with more specific 
tags, like sac scale. 

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

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[John Willis via Tagging]

> "Path (is) a trail for the use of, or worn by, pedestrians". 
> So path=trail does not work semantically anyway.

Path: tied to man-made landuses& amenities in general. 

Trail: tied to natural landuses, in general. 



A path is tied to urban/suburban/rural landuses: an urban route for 
pedestrians, or part of regular man-made infrastructure: a sidewalk, a walkway, 
or other man-made route between urban and suburban features  A sidewalk, a path 
in a park, or other another route that is supplementary to the road 
infrastructure/man-made amenity. 

A trail is tied to a natural landuse: a rural or wilderness route through 
terrain that is not supplementary of the existing road network. It is a route 
that is meant for pedestrians to cross wilderness or geologic features on 
trails that may have walking hazards or other impediments to walking (grade, 
surface, Maintenance, smoothness). What those are or their severity can be left 
to other tags. Why they cross those features may be out of necessity - the only 
way to reach a remote shrine or hilltop; recreation - a walking route around a 
mountain or swamp to see nature; or transportation, connecting remote outposts. 
They may be remote and barely maintained or immensely busy, but the 
surface+Area it traverses denotes weather it is a path or a trail, extremely 
similar to “track or esidential/service” 

A person may have a gravel driveway, but because it is a urban/suburban/rural 
driveway, we tag it as highway surface. 

A gravel track up the side of a mountain may be easy enough to drive a minivan 
on, but it is a fire break road and tagged as highway=track and 
tracktype=grade2.

The road itself may be identical. The usage and location set the purpose. 

Under track is the bottom catch-all for 2wheeled vehicles - rutted fire roads 
passable only by tracked vehicles. 

Trail has rocky, steep, difficult - almost impassable - routes used by 
mountaineers. 

Yet both track and trail contain a vast amount of easily passable ways - it’s 
just they are farming tracks or routes through a nature preserve. 

Treating trail as we do track is easy and essential for path-trail separation. 

Occasionally, trails exist in an urban environment which are informal or 
purposefully designed to be trails, and if their surface and usage fits, then 
tag it at a trail. 


> Creating a new path=trail tag will not do any good, as it will be practically 
> impossible to re-tag all the existing "highwa=path"
> 
It is possible for all major hiking routes to be properly tagged in a year 
globally. 

The point is to staunch the bleeding! People are mapping new trails everyday - 
lets stop mismapping them ASAP! 

People who love trails and use OSM for trails will chew on it. 

I work on mapping cycleways in my area where few mappers do - it is possible 
for a single mapper to make a big difference. Trail mappers can handle existing 
trails in a large city pretty easily. A place like Yosemite or John Muir 
wilderness would take a while, but Mt Fuji or another “single mountain” (Cowles 
Mtn in San Diego, Golden Gate Park, point Rayes) can be done in an an hour or 
two in a single sitting by one mapper.

Mapping “where the sidewalk ends” and the trails begin is vital to keep people 
from being routes where grandma could have a heart attack Climbing a difficult 
route or break her leg crossing a stream because we routed her on a trail down 
a ravine rather than on the longer, yet safer sidewalks down along the roads or 
paths through a local park because there is no way to say “THIS IS A TRAIL, not 
a walkway through a playground” in OSM. 

JAVBW. 

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

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[John Willis via Tagging]

The sac=scale is a attribute of trails. 

Yet we do not explicitly state “this is a trail” 

We should have a path=trail subtag. 

The presence or absence of a sac_scale Tag shouldn’t mean it is a trail. 

Imagine we had no highway=track. That we dumped all tracks into 
highway=service. That is what we are doing now with trails. 

Would you want to depend on the tracktype=* tag for denoting that it is, in 
fact, a track? At least track type has “track” in the key name.
If someone didn’t set it, it would map like the parking lots and alleyways in 
cities. Madness. 

Sac_scale is an arcane attribute for hiking nerds - it is great to have, but 
shouldn’t be the tag that differentiates a hiking trail from a sidewalk in OSM. 
That should have been a separate tag from day one, but we are now stuck with 
the monstrosity that is path=.

At least subkey it. 


Javbw

> On May 24, 2020, at 10:03 AM, Andrew Harvey  wrote:
> 
> 
> 
> 
>> On Sun, 24 May 2020 at 07:42, John Willis via Tagging 
>>  wrote:
>> =path is such a horrible catch-all tag and one that is extremely entrenched 
>> - I am surprised no one has implemented a path=trail subtag, similar to 
>> sidewalk, so we can separate all the hiking trails and other “hiking” paths, 
>> and then apply different hiking limitations you wouldn’t expect to find on a 
>> sidewalk or playground way. 
> 
> Right now you can use 
> sac_scale=hiking,mountain_hiking,demanding_mountain_hiking to indicate if a 
> path is a hiking trail. Though you can't really currently say something is 
> not a hiking trail. 
> 
>> On Sun, 24 May 2020 at 10:01, Kevin Kenny  wrote:
>> On Sat, May 23, 2020 at 5:42 PM John Willis via Tagging
>>  wrote:
>> >
>> > =path is such a horrible catch-all tag and one that is extremely 
>> > entrenched - I am surprised no one has implemented a path=trail subtag, 
>> > similar to sidewalk, so we can separate all the hiking trails and other 
>> > “hiking” paths, and then apply different hiking limitations you wouldn’t 
>> > expect to find on a sidewalk or playground way.
>> >
>> > Mixing trails and sidewalks in the path key is as horrible as mixing up 
>> > runways and train tracks in a “highway=not_car” way.
>> 
>> Yeah. But it's so entrenched that trolltags are probably the only way
>> out of the mess. And sac_scale is _surely_ not the right trolltag! The
>> problem with sac_scale is that it's an impossible scale. I'm told that
>> https://youtu.be/VKsD1qBpVYc?t=533 is still only a 2 out of 6 on that
>> scale, and that https://www.youtube.com/watch?v=3y5_lbQZJwQ is still
>> only a 3. Note that one misstep on either of those trails can easily
>> mean death.
> 
>  https://youtu.be/VKsD1qBpVYc?t=533 I would tag as 
> sac_scale=demanding_mountain_hiking, my rule of thumb is anything where the 
> average person would need to use their hands to get over an obstacle is 
> demanding_mountain_hiking. This is what the wiki says too "exposed sites may 
> be secured with ropes or chains, possible need to use hands for balance".
> 
> Anything that doesn't need hands, but has a fall hazard/is exposed would be 
> sac_scale=mountain_hiking (assuming it's not alpine).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[John Willis via Tagging]

=path is such a horrible catch-all tag and one that is extremely entrenched - I 
am surprised no one has implemented a path=trail subtag, similar to sidewalk, 
so we can separate all the hiking trails and other “hiking” paths, and then 
apply different hiking limitations you wouldn’t expect to find on a sidewalk or 
playground way. 

Mixing trails and sidewalks in the path key is as horrible as mixing up runways 
and train tracks in a “highway=not_car” way. 

Javbw

> On May 21, 2020, at 9:47 PM, Andrew Harvey  wrote:
> 
> 
>> On Thu, 21 May 2020 at 17:25, Daniel Westergren  wrote:
> 
>> Expanding on the discussion about attributes for trails. What's the current 
>> status of the highway=path mess? OSM is increasingly becoming more useful 
>> for forest trails than for car roads (for which other sources are usually 
>> more up-to-date, to be honest). But the default rendering doesn't 
>> differentiate between a forest or mountain path and a paved, combined foot- 
>> and cycleway in an urban environment.
> 
> There are plenty of apps/maps out there which do differentiate this, so 
> that's not a tagging issue.
>  
>> Obviously we're not tagging for the renderer and the default OSM rendering 
>> is discussed elsewhere. But has there been any fruitful discussing on this 
>> topic that will help users to tag these clearly extremely different kinds of 
>> "paths" in a way that make them more useful for data consumers, as well as 
>> easier to differentiate for renderers?
>> 
>> Sure, tags like surface, width, trail_visibility can be used. But in most 
>> cases, highway=path is used with no additional tag. The JOSM presets for 
>> foot- and cycleways use foot|bicycle=designated, but that doesn't 
>> necessarily tell anything about the surface or size of the path, or even its 
>> importance in terms of usage by pedestrians, hikers and cyclists.
> 
> Those are very useful tags, plus smoothness and sac_scale.
> 
> You can also use foot=designated to indicated its signposted for walking or 
> foot=yes to indicate you are allowed to walk but not signed for walkers.
> 
> There are tags for ladders, rungs, ropes which are useful so less able people 
> can be informed if a trail features these obstacles.
> 
> The lifecycle prefix is good for tagging abandoned paths that have 
> significant regrowth and authorities have closed off and trying to regenerate.
> 
> You're right a highway=path without any other tags covers a wide range of 
> possibilities, that's why it's great if you can add other tags.
>  
>> When highway=path was introduced, forest trails were not widely mapped and 
>> not the main consideration when introducing the tag as a way to deal with 
>> cases when footway or cycleway could not be used.
> 
> The highway value describes what the path was built for, the other tags 
> mentioned tell you a lot more about the suitability of it.
>  
>> I realize this topic has been discussed extensively over the years. But  now 
>> more than ever OSM is becoming increasingly important for hikers, trail 
>> runners and MTB cyclists for whom a forest or mountain path is something 
>> completely different to an urban foot- or cycleway.
> 
> If you have any material suggestions, I'd be very keen to hear.
> 
> Disclaimer: I build a website and map for hiking using OSM 
> (beyondtracks.com/map) data and yes I do take into account sac_scale (path is 
> red when it's technical), trail visibility (sparser dot when the trail is 
> less visible), ladders, ropes and rungs.
> ___
> 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] With leisure=common deprecated, Senegal & Mali need a replacement

[John Willis via Tagging]

> On May 1, 2020, at 8:00 PM, Florimond Berthoux  
> wrote:
> 
> +1 for highway=pedestrian + area=yes
> That how we map a town square in France (and every where else I guess ?)’


+1 for plaza mapping and any other predominantly foot-dominated expanse in any 
usage like a plaza or wherever people are usually walking around. 

The commons to me seem more like a “park” - I wouldn’t tag it like a park, but 
a commons area where people sit on the grass and eat lunch certianly isn’t like 
a plaza. there may be a path through these areas like this as well. 

lots of urban areas have commons around buildings that are not mere landscaping 
- are those parks? landuse=grass? highway=ped? 

 hmm…

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

Re: [Tagging] natural=water inside natural=wetland

[John Willis via Tagging]

If you are talking about a simple wetland you may find in a small pond or lake, 
It’s easy, but natural formations are often very messy and complicated - 
especially when a wetland covers an area larger than most villages. 

There is often overlap where I am where a wetland lives permanently in the 
bottom of a basin, and the surrounding area is a park or sports field. When 
there is a storm the basin fills up and wetland, pitch, and parking lot end up 
under 3m of water for a day or so. 

The wetland is not exclusively part of that structure. The basin or 
intermittent reservoir consumes everything inside of it. 

I have 3 basins In my area that are 5KM wide that 363 days a year are wetland, 
sports complexes, airstrips, parks, etc. then a typhoon hits and fills it with 
3m of water for a day or so. 

The structure of the surrounding area still influences the smaller area, like a 
river way going through a giant wetland. 

In a lake, some corner of the lake is often a wetland - yet that wetland is 
100% the part of the lake. It should be layered IMO. That could happen for a 
wetland too, right? 

Maybe I am looking at it in a wrong way. 

A multipolygon might be a good solution for some of these pond in wetland 
situations (like an island in a lake), but won’t there also be some cases with 
water features where the they truly are 2 things in the same space? 

Can it always be validated as “wrong?”  

Javbw

> On May 1, 2020, at 3:36 AM, Andy Townsend  wrote:
> 
> 
>> On 30/04/2020 19:09, Paul Allen wrote:
>> On Thu, 30 Apr 2020 at 18:45, Andy Townsend via Tagging 
>>  wrote:
>> 
>>> There are always going to be edge cases that aren't easy to categorise.  
>>> There's an area just up the road from where I am currently that started out 
>>> as https://www.openstreetmap.org/way/13866095
>> 
>> That's coming up as deleted 6 years ago by Yorvik Prestigitator.  Typo?
>> 
> No - follow the history forward and you'll get to 
> https://www.openstreetmap.org/way/796675406 .  I was doing some tidying up of 
> the fence, woodland and ditches at 
> https://www.openstreetmap.org/changeset/84161134#map=19/54.02644/-0.99852 a 
> few days ago and the object "moved" to a new ID.  For convenience it would 
> have made sense to link to that as well, obviously :)
> 
> Best Regards,
> 
> Andy
> 
> 
> 
> ___
> 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] Points vs Polygons

[John Willis via Tagging]

> On Apr 22, 2020, at 8:38 PM, Martin Koppenhoefer  > wrote:
> 
> but the building is also a thing, it has its own properties, e.g. start_date, 
> wikipedia reference, architect, operator, name, height, etc 
> 
> yes, often you can understand which tag belongs to which object, when several 
> objects are represented by one OpenStreetMap object (and that’s why we 
> tolerate this kind of representation), but strictly, you can’t even know 
> whether the name belongs to the building or to the occupant (it “works” 
> because you assume that buildings mostly don’t have names).


Yep, I do this because I assume the buildings have names and attributes that 
need to be labeled beyond the encompassing landuse. 

every building at the mall is not named “the mall”. 

the landuse=retail area is all “ the shopping mall”  - the named parking lots, 
the access roads, the hedges along the fence, etc.

Everything inside this area is "the mall”. 

a retail building here is 3 levels, named “south Mall”. it is part of “the 
mall”.

this other retail building is a deptartment store. it is a giant named anchor 
store. it has 2 levels. it has the shop tagging on it. 

This pin over her is a small shop the south building. that pin is “in the mall” 
and “in the south building” and has all the tagging for this small shop. 

It completely baffles me that the way to tag one collection of buildings and 
amenities sitting on a named area/landuse is fine for one type, yet somehow a 
contentious issue when it comes to tagging another set of buildings and 
amenities that sit on an area. 

there are many retail establishments that are the area (malls, shopping 
centers, big-box stores), many that take the building (many supermarkets or 
similar), and then a myriad of pins that may be on any of these objects to 
represent smaller shops inside.

 Shopping centers in particular have usually unknown official names (“parkway 
shopping” printed on the top of the sign) and then a collection of road-facing 
retail buildings that people see. having the shopping center 
(shop=shopping_centre) labeled as a pin in the middle of the parking lot is not 
great mapping IMO. 

A large supermarket tagged onto building may sit on a differently named landuse 
(a shopping center), and have a pin inside the building to represent the small 
coffee shop or bank or similar tiny shop “inside” the supermarket as well, 

Very similar to a Hospital which is a giant named area, a named individual 
hospital building, and pin for a convenience store in the basement. 

keeping this flexibility better represents reality. 

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

Re: [Tagging] Points vs Polygons

[John Willis via Tagging]

> On Apr 20, 2020, at 7:22 AM, Joseph Eisenberg  
> wrote:
> 
>> we end up with most POIs [e.g. shops] added as nodes, as it appears to be 
>> currently the best compromise in terms of mapping efficiency, accuracy, 
>> complexity and editability.
> 
> +1

+1 as well, but I do not want this to become a standard way to map all POIs 
that resemble businesses. 



> 
>> I know there are lots of building=yes with POI data added, but I would 
>> discourage this because there really is no way to tell which of the 
>> properties (e.g. name) belongs to the building and which to the business.
> 
> +1

-1  I really like tagging info onto landuses and buildings because that is 
*exactly* what I’m trying to convey - everything in this area or building is 
*this thing*


It should be said to use the *proper* method, which may be pins most of the 
time, but for more complicated mappings, all might be used. 

This is especially true with modern indoor malls - where you are going to see a 
lot of shop mapping. This nesting becomes vitally important. 

The “mall” is the retail landuse. the named parking lots, the access roads, the 
mall buildings, the satellite buildings - that is “the mall”. 

The mall is often times a collection of many buildings. Anchor stores often 
take a whole building with additional small shops inside, or the buildings 
themselves have names (center mall, south mall) stuffed with many small shops. 

https://www.openstreetmap.org/#map=17/36.29322/139.39888 



In my example, Aeon Mall Ota is the entire place. There is an anchor department 
store - Aeon - on the north end. the mall is then two adjoined buildings - the 
center mall and south mall. (the mall was lengthened and the segments named 
differently). 

then, inside those buildings, are all the POI’s of the different shops, 
restaurants, amenities, and so forth. 

In this case, the info for the mall is on the landuse (it is the whole landuse).

the info for Aeon shop is on the building. (it is the entire building, and 
named for it). 

The info of the general mall shops are on pins (as they take up suites) 


This is a MASSIVELY USEFUL ability to nest different POIs on top of each other. 
Similar to other situations, being able to specify points for shops inside a 
larger land area is useful. 

Javbw


 

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

Re: [Tagging] Feature Proposal - RFC - traffic_signals=crossing_on_demand

[John Willis via Tagging]

> On Apr 15, 2020, at 8:34 PM, Paul Allen  wrote:
> 
> The traffic lights control the junction

We have a lot of traffic light controlled crossings in Japan that are just for 
a crosswalk, while the smaller intersecting road is stop-sign controlled for 
cars. Only the crosswalk is controlled by a signal that stops traffic on the 
larger road - only when pressed. There are many of these. 

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

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


- crosswalks for traffic signal controlled intersections where the light is 
_only_ sensor triggered - magnet loop in the road and a push-button for 
pedestrians. there are very few of these. a little sign says “push button” - 
and if you don’t press it, you will wait until a car comes.

both of these are “on demand” to me . 

this is beyond normal signal controlled crosswalks in the middle of larger 
roads (like in front of a hospital, etc), 


Javbw


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

Re: [Tagging] tagging the landuse of resevoirs & basins.

[John Willis via Tagging]

> On Apr 15, 2020, at 10:40 AM, Joseph Eisenberg  
> wrote:
> 
>> I suggest landuse=industrial + industrial=water
> 
> Perhaps industrial=water_management or =flood_control or something
> elsemore specific would be better?

 good values, water_management might be good. Some of these are for purely 
storm surge control (to prevent short term flooding), but canals and aqueducts 
often have controlled land in certain places and are not related to storms. 

https://www.openstreetmap.org/#map=19/36.28920/137.88271 


Here is a place where an aqueduct crosses a river. the office next to it is the 
local “drainage” office that handles the aqueduct. 

the land around the crossing has two overflow drains that lead to the river. 

I could merely map the grass and riverbank areas, letting the fences and water 
features imply the usage, but I could also try to show that this junction is:

- a man-made feature
-for management of the water features inside the area
- has no other uses beyond water management. (no parks, etc).
- an area people normally don’t enter except for maintenance. 
- this one also has access control (fencing, gates, etc)

To me, this is another use of this landuse. 

> 
> I would mainly do this for areas covered in concrete, asphal, stones,
> roads, levees and other obvious man-made features, surrounded by a
> fence or wall probably? And map the fence with barrier=fence lines if
> known.

They often have fences or other barrier= features along with access ways. 

Smaller ones are defined by the bordering boundaries (farmland, residential 
walls, road guardrails, etc).  

All my examples were chosen because they basically have this.  One doesn’t - 
but still is a man-made structure.

> (You can also map the vegetation of the area (grass, scrub, woodland)
> if it's present, especially if this covers a large area.

I often do, but most of these are totally surrounded by concrete/asphalt (and 
often times fences to keep people from drowning).

> That would
> make more sense than describing a large are of woods as
> industrial=flood_control if it is outside of the levees/dykes and
> wouldn't actually be flooded.)

I’m not interested (for this tag) to map any natural features - just the land 
altered and/or fenced that surrounds the basin/reservoir.

it’s to map the constructed objects that surround the water feature. 

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

[Tagging] tagging the landuse of resevoirs & basins.

[John Willis via Tagging]

When mapping stormwater reservoirs and basins here in Japan, they often have a 
mappable landuse around them - the land around the basin is controlled, often 
with an access road and and fence of some type. 

Mapping the water feature is easy, but what is the landuse of the entire 
facility? it is 10% larger than the basin itself.


Here is a good example - the small amount of land around this basin “belongs” 
to the basin. the access road belongs to it. It is not a park nor are the 
access roads for private property. they are just there to access the basin in 
an emergency (a breach, cleaning etc). 

https://www.openstreetmap.org/way/791956035 
  <-mapped landuse example

other examples that could be mapped in a similar fashion:
https://www.openstreetmap.org/#map=17/36.28832/139.42927 

https://www.openstreetmap.org/#map=18/36.27943/139.43071 

https://www.openstreetmap.org/#map=18/36.29622/139.39674 

https://www.openstreetmap.org/#map=18/36.34744/139.32669 

https://www.openstreetmap.org/#map=17/36.05560/139.60083 




In many instances, emergency stormwater basins are in parks or large factories 
- making them a feature of that larger landuse.
I'm not talking about these. 

Examples of what I’m not talking about:
https://www.openstreetmap.org/#map=16/36.2707/139.4148 

https://www.openstreetmap.org/#map=17/36.22028/139.64998 

https://www.openstreetmap.org/#map=16/36.1037/139.6329 



I’m talking about the dedicated land only used for the man-made basins and no 
other usage, controlled via barriers, and mappable via imagery. 

I suggest landuse=industrial + industrial=water  or similar for all man-made 
water related features that isn’t a plant of some kind (ones dedicated to 
filtering, treating, or pumping the water). 

similar to landuse=railway, there is more land dedicated to these features than 
just the mappable feature itself. 

https://taginfo.openstreetmap.org/keys/?key=industrial#values 


taginfo says this combination currently has 60 uses (#2 for all “water” 
values), and “water_storage” has 1. 

thoughts?

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

Re: [Tagging] Add man_made=goods_conveyor to Map Features or vote on the proposal first?

[John Willis via Tagging]

+1

Javbw

> On Mar 12, 2020, at 8:22 AM, Martin Koppenhoefer  
> wrote:
> 
> I am in favor of adding it right away.

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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

> 
> Given that iD still seems to scramble sorted routes in some circumstances, 
> one should not assume that editors will correctly handle any changes we make. 
> I might be being unfair to iD here, I didn't check the route was still sorted 
> before I added a spur, so maybe somebody else doing something that didn't 
> directly affect the route using another editor scrambled it.
> 


Could you please try to replicate that and report it to the iD developers? 
Sounds like a pretty serious bug, if it is that.

> 
> Given recent comments on the proposal's talk page, I doubt it will better 
> represent reality because it's the router that determines the fine details.
> 
> I want to see exact routes, not close approximations.
> 


While many others have, in the process of this proposal, questioned the need to 
map exact routes at all (given the presence of platforms), I have always wanted 
to map canonical routes as closely as I can.

> A new housing estate with two connections to the existing road system could 
> cause the bus to be re-routed.

Sounds a little odd - would a router really route a bus on a 
highway=residential or highway=service?

But, be that as it may, your response helped me see two things -
1. It will be helpful to have a route visualizer in editors that can preempt 
ambiguities.
2. Hail and ride routes longer than last-mile services really do suffer under 
this schema.

> Which is fine if they're alternative ways of mapping bus routes. But the 
> proposers seem to want to make this the one and only way of doing things.

I reiterate that I initially wanted it to be just that - an additional way to 
map. But I also don't want to see it go the way of PTv2, where some consumers 
still don't support the new schema even after 8 years of being asked to. And I 
definitely don't want ways in routes where there's no need for them, but 
someone decides to add them 'for completeness' (for instance, so many appear to 
have difficulty in comprehending that stop positions in PTv2 are optional 臘♀️), 
oblivious to the maintenance issues.

Which gives me the following idea - would it help you if only routes with 
hail_and_ride=yes were permitted to have ways? For selective hail and ride, we 
can use the via roles as currently written in the proposal. That lets you use 
ways where they are most important (longer, completely hail and ride routes), 
and keeps them out of where they're a nuisance.

(Routes with hail_and_ride=yes could still opt to omit ways and use points, 
which would be better for shorter routes.)

Tangential comments -
1. "long-distance [interstate?], few official stops, only stops at official 
stops" - this proposal doesn't merely 'work' for them, it is absolutely 
essential for them - one only has to try creating a route relation for a 
national train to know why  I agree with you that passengers in those 
situations don't care about the intricacies of the route as long as the stops 
are being served and the ETAs are more or less accurate.
2. This also works well for "intra-city, many official stops, only stop at 
official stops". The stops are so frequent that you probably won't need to add 
any via points in most cases.


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

> 
> I suggest again: Make the route a separate route relation and include it as 
> an optional member of the PTv3 routing relation as proposed. Everybody happy 
> (routing lobby AND route lobby), all bases covered including backward 
> compatibility.
> 
> 


Thank you for that suggestion, apologies for not being able to talk about it 
before.

I like that it tries to let mappers who like ways to use them, without stepping 
on the toes of (i.e. without creating maintenance problems for) those who don't.

> Data users, renderers and tools can make up their mind what best serves their 
> purpose.

But that's where I feel confused.

If e.g. OsmAnd decides to only use the route relation, mappers would be 
discouraged from using the routing relation. There would be no maintenance 
benefits.

There's also the fact that it creates two sets of data to describe the same 
thing (the route)...it means having to keep them in sync. That would _increase_ 
maintenance work, instead of decreasing it. 



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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

This is quite off-topic, but I can't bear to read more completely unfounded 
criticism of PTv2.

I hereby declare that I find the old tags to be a complete abomination (Is it 
on the way? Is it beside the way? Is it a stop, a platform, a halt, a station? 
Why is a platform or a bus stop a railway or a highway?), and PTv2 tags to be 
very consistent and comprehensible in comparison. Indeed, this thread has 
motivated me to stop using legacy tags entirely - to hell with Carto and other 
legacy consumers.

If tram stops (as described on the wiki) are accessible from both sides and it 
makes sense to put them on the way, then PTv2 is very much justified in 
creating an umbrella tag for stops which are placed on the way. I don't 
understand why the critics of PTv2 seem to think stop positions are such a big 
deal - they are optional!

Platforms are where passengers wait.
Stations are places with many platforms.
Stop positions are where vehicles stop - an optional alternative to using 
platforms, included for backward-compatibility.
And the feature is not confounded with the vehicle that serves it, nor the 
infrastructure provided. A platform is a platform regardless of shelter, bench, 
or tactile paving.

It remains an elusive mystery as to how I, a mere mortal, managed to map >70 
services using this arcane, Baroque schema. /s

https://wiki.openstreetmap.org/wiki/Delhi/Buses#Routes_surveyed_by_traveling

https://wiki.openstreetmap.org/wiki/Noida/Buses#Routes_surveyed_by_traveling

https://wiki.openstreetmap.org/wiki/Delhi/Share_autos

09-Mar-2020 13:46:42 Alan Mackie :

> 
> 
> On Sun, 8 Mar 2020, 13:48 Dave F via Tagging, < tagging@openstreetmap.org 
> [mailto:tagging@openstreetmap.org] > wrote:
> 
> > This proposal by Stereo is nothing really new. Just a alternative to
> > routing which has been around since relations were introduced.
> > Definitely not 'PTv3'. The 'via' option appears almost as difficult to
> > maintain as including ways.
> > 
> > 
> > On 08/03/2020 01:41, John Doe wrote:
> > 
> > 
> > >
> > > That would be tempting, because it would mean a lot less work for us in 
> > > the short term. However, I'm afraid of ending up like PTv2 -
> > > 1. It 'does not deprecate the old tags', use of the new tags is 
> > > 'recommended but not mandatory'...whatever that means.
> > It means PTv2 tags aren't required as there are existing tags performing
> > the same job.
> > > 2. People with a preference for the old tags see that as an excuse to 
> > > keep using them
> > 
> > No. They are preferred because they simple to comprehend, accurate &
> > abundant.
> > > 3. Consumers see that as an excuse to not support the new schema, even 
> > > after 8 years of people requesting it - 
> > > https://github.com/gravitystorm/openstreetmap-carto/issues/311
> > PTv2 [https://github.com/gravitystorm/openstreetmap-carto/issues/311PTv2] 
> > isn't supported because it's not abundant (people get bored of
> > adding them after a couple weeks)
> > 
> > > 4. People who want to use the new tags have to use _both_ sets of tags 臘♀️
> > No they don't. They can use just the original tags. PTv2 tags are pure
> > duplication.
> > > 5. Both sets of tags have to be documented, making the documentation more 
> > > verbose than it might be.
> > > They should coexist...for a transitional phase. But it has to be just 
> > > that - a _transition_, not a permanent inconsistent mess.
> > 
> > The original tags are here to stay because they work. PTv2 is a
> > *separate*, *independent* scarcer schema running in parallel that adds
> > nothing over existing tags.
> > 
> > It is only PTv2 which is the mess. Even those who conceived it are
> > confused by it.
> > 
> > DaveF
> > 
> 
> Whenever I have considered adding things in a ptv2 compatible way I have 
> ended up confused and reverted to a simple highway=bus_stop. Ptv2 seems to 
> want imaginary unverifiable stop points and for you to add signs on poles as 
> "platforms" for reasons I could never fathom. Then of course even the 
> simplest route actually has to be two or more routes for some reason. All of 
> these seemed to have documentation spread across several different wiki pages 
> with no clear relationship to each other.  
> The new proposal seems to be an attempt to get back to the clarity of the 
> original system while throwing the baby away with the bathwater. In theory a 
> router could reconstruct a route from points, if it's simple enough, but if 
> we are going to do that then we may as well drop the route relation 
> completely and just put the list of services on the stop nodes where m

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

Hey, thanks for sharing your views 

07-Mar-2020 03:01:41 Phake Nick :

> [...] for such renderer to work, access restriction for public transit 
> vehicle need to be complete, which is rather difficult not just because of 
> the work it take or the current incompleteness of the amount of keys in OSM 
> that can be used to represent multiple localized types of transportation, but 
> also because of things like mechanical restrictions of bus models that would 
> not be available in any public document and cannot be verified outside of the 
> public transit company.

I feel that this information can largely be approximated from road 
classifications. PT Assistant already complains if a bus route is using a road 
lower than a certain classification. As and when turn restriction data is 
added, routers can adapt the route automatically.

> [...] how can editors know when it is necessary to add a waypoint to show a 
> route correctly?

I think it will always need mapper testing, as it already does. But PTv3 does 
remove a lot of moving parts, and makes creation and maintenance of routes 
easier.

> If a new road is being built next to existing road which doesn't affect 
> existing public transit routes, how to preemptively make sure routing engines 
> won't automatically redirected a route to the new road?

In this case, since the platforms being served haven't changed, I think you'll 
find that
1. The likelihood of the route changing is very low. Even hail and ride routes 
shouldn't be likely to change much, since the via points used to define them 
would probably keep the routers on track.
2. Even if it does change, the platforms are the same and the router is still 
preferring the fastest path between them - users are unlikely to be greatly 
affected. At worst, accuracy of ETAs could be affected.

What I have in mind is the case of Delhi's NH9, in which a road was changed 
from two to four carriageways. In such a situation, with the constraint of the 
existing stops, routers would have to ignore the new inner carriageways and 
stick to the outer carriageways, which is exactly what happened on the ground  
If you have some other examples in mind, it would help us all to discuss their 
specifics.

> Third, way points are more transient than ways. It's more easy for a node to 
> be deleted or replaced when editing geometry than ways. How to maintain 
> integrity of a route geometry when others edit road geometry?

To verify this, I tried deleting a stop position which was part of a route 
relation. Both JOSM and Vespucci warn you about the relation, and ask for 
confirmation. iD does not, but fortunately someone's already made an issue 
about it and they're considering it - 
https://github.com/openstreetmap/iD/issues/5846

I've added FAQ entries for all these, thanks for the feedback! I hope I'm able 
to address your concerns about our proposal.


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

08-Mar-2020 03:56:45 Joseph Eisenberg :

>
> > routes without fixed stops can easily be represented using only via points 
> > and stop positions
> >
>
> I think you mean "bus stops" (or railway platforms), not
> "public_transport=stop_position", since those nodes are usually
> unnecessary, and are not added by most mappers for bus routes. Routing
> apps can easily calculate the location where the bus stops based on
> the location of the "highway=bus_stop" next to the way.
>
> Creating "via points" seems more cumbersome than adding the highway
> ways to the relation when the route is "hail-and-ride", especially
> since a via point would not represent a real-world feature in that
> case.

For such relations, I already have to create stop positions at the start and 
end of the route. Indeed, the PT Assistant validator pesters me to  From 
there, it's just a question of adding a few via points - still less work and 
more maintainable than adding all the ways of the route.

> I understand why user Stereo would like a clean, simple solution. But
> realistically, both mapping methods are going to co-exist (this is
> already the case).
>
> It is most likely to be accepted if the proposal does not attempt to
> call anything "deprecated" or force anyone to use the new mapping
> style.

That would be tempting, because it would mean a lot less work for us in the 
short term. However, I'm afraid of ending up like PTv2 -
1. It 'does not deprecate the old tags', use of the new tags is 'recommended 
but not mandatory'...whatever that means.
2. People with a preference for the old tags see that as an excuse to keep 
using them
3. Consumers see that as an excuse to not support the new schema, even after 8 
years of people requesting it - 
https://github.com/gravitystorm/openstreetmap-carto/issues/311
4. People who want to use the new tags have to use _both_ sets of tags 臘♀️
5. Both sets of tags have to be documented, making the documentation more 
verbose than it might be.
They should coexist...for a transitional phase. But it has to be just that - a 
_transition_, not a permanent inconsistent mess.

Note that the manifestation of #4 here would be that ways would be included, 
whereas I'm trying to avoid mappers dealing with them at all - to deal with 
them would mean losing important maintainability benefits.


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

As mentioned in the Caveats section of the proposal, hail and ride _has_ been 
in our thoughts. 

(Buses operated by NMRTC in Noida are all hail and ride, and so are all share 
autos in Delhi, making it quite important for me personally.)

My idea, initially, was to have this proposal serve as an extension to PTv2, 
falling back to PTv2 (way-based relations) for hail and ride routes. However, 
Stereo leans towards it replacing PTv2 [1] - routes without fixed stops can 
easily be represented using only via points and stop positions. A single tag 
(say, hail_and_ride=yes) on the relation can establish it as such. Nice and 
simple - hail and ride with no icky way segments 

Now that might suffice for most situations, but I for one liked the flexibility 
of marking specific sections of a route as hail and ride - I like to mark 
intersections, for instance, as places where hail and ride vehicles won't stop 
under normal conditions. To cater to this - _if_ the community considers it 
worth catering to, because I wouldn't be surprised if some consider it 
unnecessary micromapping - Stereo suggested making new roles for via points, 
e.g. begin_hail_and_ride and end_hail_and_ride. This I find somewhat inelegant.

What do you think?

[1] I'm personally quite undecided on this. There are numerous upsides and 
downsides to both approaches.

07-Mar-2020 19:44:34 Paul Allen :

> On Sat, 7 Mar 2020 at 02:30, Joseph Eisenberg < joseph.eisenb...@gmail.com 
> [mailto:joseph.eisenb...@gmail.com] > wrote:  
> 
> > However, there are also public transit services where the bus can stop 
> > anywhere along the route. This is the most common type of bus here in 
> > Indonesia. In this case there are no fixed stops except for the 2 end 
> > points, but the minibus follows the same streets and passengers can wave 
> > their hand or request a stop anywhere along the route.
> 
> Rural routes in the UK are often similar, except there are designated stops  
> (sometimes with a shelter, sometimes just a sign, sometimes unmarked)  along 
> the way. Most (sometimes all) of the route is "hail and ride." This  can even 
> happen in small towns (well, at least one town I know of) where  much of the 
> route is also "hail and ride." In that particular town, some  of the new 
> timetabled stops lack shelter and sign (but that's OK because  that part of 
> the route operates as "hail and ride" anyway).
> 
> > 
> > So, I support the idea of allowing mappers to just add the bus stops to the 
> > relation when this is the most verifiable and easiest to maintain, but 
> > there are some cases where this will not work, so it should still be 
> > permitted to map the ways for non-fixed-stop services. 
> 
> +1  
> Not just permitted, but the documentation should explicitly state this. Not 
> just  for legacy routes (I don't see a mass upgrade happening) but also for 
> new routes.  This must be an alternative, for use where the mapper feels it 
> is easier and/or  gives better results. Maybe even a preferred alternative, 
> but still just an  alternative.
> 
> --
> Paul  
> 


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

06-Mar-2020 20:39:30 Peter Elderson :

> > [...] Is it a significant burden to include a router with a renderer?
> I wouldn't know. It seems strange to me that established routes have to be 
> re-routed to display or use them. How can you be sure the re-created route is 
> the one that is defined by the operator? Keeping as an example the city PT 
> map.

That is something that mappers/maintainers would have to test, as they already 
do. The difference is that the time and effort required to create and maintain 
the relation is greatly reduced.

Tangentially, something that might help would be a validator for editors that 
checks if a route (whether defined by ways or as deduced by a router as we 
propose) matches user-specified GPS traces.


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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

06-Mar-2020 18:08:22 Peter Elderson :

> If I understand this correctly, your proposal turns route relations into 
> routing relations.

That's a clever way to put it 

> Wouldn't that imply that a chart of PT lines in, say, a city, region or 
> country would need to route everything first, then render instead of just 
> render the route from OSM?

Seems so. Is it a significant burden to include a router with a renderer?

> Vr gr Peter Elderson
>
> Op vr 6 mrt. 2020 om 11:08 schreef John Doe < music.kash...@gmail.com 
> [mailto:music.kash...@gmail.com] >:
>
> >
> > Stereo and I have been working on a schema that makes it easier to create 
> > and maintain public transport route relations. We would like to invite 
> > feedback, questions, and suggestions, so it can mature and hopefully gain 
> > widespread use.
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations
> >  
> > [https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations]
> >
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org [mailto:Tagging@openstreetmap.org]
> > https://lists.openstreetmap.org/listinfo/tagging 
> > [https://lists.openstreetmap.org/listinfo/tagging]
> >
>



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

Re: [Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

Thank you for sharing your thoughts 

06-Mar-2020 17:40:23 Andrew Harvey :

> I think including the actual route is useful and makes life easier for 
> downstream users (they don't need a routing engine to show the route), could 
> this be optional so you can create a public transport route relation via 
> waypoints only if you prefer as a starting point, but then still allow it to 
> be completed via the way members.
> A bit like how most things can be initially mapped as a node but then are 
> usually expanded out into an area.

I'm afraid I'm against that idea, personally. I've mapped nearly 70 bus routes 
in my city (and counting); I'm still their lone maintainer; I have also dabbled 
with mapping railway routes. So many relations with so many ways - especially 
highways, which are the first things newbies edit and thus are the most likely 
to break a relation - are an enormous maintenance bomb waiting to go off. (And 
sometimes it does go off, and the fallout goes on for months.)

Besides - while I have never written a router or a renderer - I imagine that 
having to support both types of relations (PTv3 as well as v2) would create 
additional technical debt for routers and renderers.

> Secondly I don't quite understand the no way member rule of your proposal, 
> since railways platforms should be a way 
> https://wiki.openstreetmap.org/wiki/Tag:railway=platform 
> [https://wiki.openstreetmap.org/wiki/Tag:railway=platform] then including the 
> platform in the relation means you need to include ways as relation members.

Thank you for pointing that out. The ways it referred to were highways and 
railways - it has, of course, no objection to platforms as ways or areas. I 
have reworded the section, hopefully it is clearer.

> On Fri, 6 Mar 2020 at 21:08, John Doe < music.kash...@gmail.com 
> [mailto:music.kash...@gmail.com] > wrote:
>
> >
> > Stereo and I have been working on a schema that makes it easier to create 
> > and maintain public transport route relations. We would like to invite 
> > feedback, questions, and suggestions, so it can mature and hopefully gain 
> > widespread use.
> >
> > https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations
> >  
> > [https://wiki.openstreetmap.org/wiki/Proposed_features/Simpler_public_transport_route_relations]
> >
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org [mailto:Tagging@openstreetmap.org]
> > https://lists.openstreetmap.org/listinfo/tagging 
> > [https://lists.openstreetmap.org/listinfo/tagging]
> >
>



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

[Tagging] Feature Proposal - RFC - Public Transport v3

[John Doe]

Stereo and I have been working on a schema that makes it easier to create and 
maintain public transport route relations. We would like to invite feedback, 
questions, and suggestions, so it can mature and hopefully gain widespread use.

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



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

Re: [Tagging] Annual Shows

[John Sturdy]

I'd call such a place a "fairground" or "showground", but I'm not sure
whether it would come under "tourism", "leisure", or "amenity".  I'm not so
keen on "landuse" for it, as the land may also be used for something else.
A particular example is the Cappamore Agricultural Show in Ireland; its
location is given as "Showgrounds, Ballyvoreen, Cappamore, Co. Limerick"
but it looks like for most of the year it is normal farmland.

On Tue, Feb 25, 2020 at 2:37 PM Jarek Piórkowski 
wrote:

> On Tue, 25 Feb 2020 at 05:01, Warin <61sundow...@gmail.com> wrote:
> > These shows do take place at a permanent site.
> >
> > They take place annually, floods, fire, droughts and wars excepted.
> >
> > The dates may vary depending on various things, but usually around the
> same time each year.
> >
> > They are part of Australian culture, and it would seem British culture.
>
> I also wish for a settled tag for a regular, locally important event
> that is repeatedly or always held at a given site.
>
> I have tagged location of one such in Canada with landuse=fairground
> but this doesn't seem perfect and landuse key doesn't logically lend
> itself well to specifying details about the events that might be
> taking place there. A lot of fairgrounds in Canada end up being tagged
> as a park for lack of a better description.
>
> See also related discussion in
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/leisure%3Devents
>
> --Jarek
>
> ___
> 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] Annual Shows

[John Willis via Tagging]

> On Feb 28, 2020, at 12:58 PM, Warin <61sundow...@gmail.com> wrote:
> 
>> this would interfere the least with existing mapping. 
> I think existing mapping would ignore the tagging completely.

If people are tagging for the renderer by naming Landuse features or amenities 
the name of the festival or event, then they are interfering with proper 
mapping. 

If I draw a big sand polygon out in the desert and name it “Burning Man” - it 
really isn’t a sandy area named that. There isn’t a park named “Summer 
Festival” A scheme that integrates with existing mapping would cause the least 
mapping for the renderer. 

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

Re: [Tagging] Annual Shows

[John Willis via Tagging]

> On Feb 28, 2020, at 12:58 PM, Warin <61sundow...@gmail.com> wrote:
> 
> Why limited to outdoor only?

Because then we would just be mapping events held inside event halls. 

They are not worth mapping because they do not alter the OSM data. 

If a farmland becomes a parking lot, if a road becomes a pedestrian road, if a 
stage suddenly is built in a park - well, those are mappable. 

Mapping a convention center’s schedule requires no change in the map. 

ComicCon in San Diego is probably the biggest event of the year there - yet 
there are no real changes to the map. The San Diego Marathon (?)  closes a 
section of freeway, and several major roads. 

One requires mapping changes, one doesn’t. 

If the point is to map just event locations, then my idea is wrong. If the 
point is to map seasonal changes to OSM, then “outdoor” events seem to be the 
only ones that could alter the map - from Sunday’s farmer’s markets to 
marathons to Burning Man. 

Otherwise every event venue is going to be covered with 40 pins mapping a 
schedule.

My work, a private High school, holds an annual entrance test where 3000 
students come to take the entrance exam. It is a big disruption in traffic on 
the day and the nearby park is full of students. It’s well known in our city. 

Yet it requires no changes to OSM. Is that something we should map?  

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

Re: [Tagging] Annual Shows

[John Willis via Tagging]

I can’t see why we can’t create a simple tourism=outdoor_event pin at the 
location of the event and list it’s time in something like
event=seasonal/ date / existing time mapping, and could use admin_level for 
scale - and use additional tags ina relation for larger events or micromapping. 

we have huge city / regional summer festivals in Japan that are held in the 
same place on the same day every year (some on the same calandar date "august 
1-3" or on the same “first friday-sunday in August”. It would be easy to map 
the boundary and location of amenities and the extent of closures of the roads 
for the events, as they haven’t changed in decades.  

A simple pin might be just fine for small seasonal outdoor events , mapping the 
extended details of the event should be expanded into a relation, such as a 
boarder of the known area (role=boundary), especially since for many outdoor 
events the areas and roads are “normal” most of the year. 

normally mapped Ways & areas could be tagged with 
outdoor_event:highway=pedestrian or outdoor_event:amenity=parking (or whatever 
it is during the event) to show their role during the event - yet be mapped 
normally the rest of the time -  and added as regular members of the relation. 
this would interfere the least with existing mapping. 

the tag scheme outdoor_event:foo=bar could be used on new pins/ways/areas to 
map any other “permanent” items of the event (stages, pavillions, parking, 
toilets, paths, etc) that are normally not present. 

this would keep the “event” pobjects out of the regular map data until the 
event date could trigger the changed rendering if they wanted to support it. If 
renderers ignored that extended data, they could still render the tourism=event 
pin with the name of the event easily (and the boundary as well) - which would 
probably be enough for most events. 


Javbw


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

Re: [Tagging] Tagging the presence or absence of signs for surveillance cameras

[John Sturdy]

On the ones I've noticed in Cambridge, they are either on the lower part of
the pole supporting the camera, or, for building-mounted cameras, on the
wall below the camera.  (The cameras are well above head height, and
notices on them would not be readable unless very large.)

On Wed, Feb 19, 2020 at 11:48 AM Jez Nicholson 
wrote:

> In general, are these signs physically on the camera, or are they in the
> vicinity? If so, should they be tagged objects in their own account?
>
> On Wed, 19 Feb 2020, 10:54 John Sturdy,  wrote:
>
>> Whatever the concensus in another discussion was, I think that double
>> negatives will risk confusion, and that *:signed=yes and *:signed=no seems
>> to be a reasonable proposal.
>>
>> I have noticed that some but not all of the surveillance cameras (city
>> council, I believe) in Cambridge (UK) have signs.
>>
>> __John
>>
>> On Wed, Feb 19, 2020 at 10:13 AM marc marc 
>> wrote:
>>
>>> Le 19.02.20 à 04:29, Victor/tuxayo a écrit :
>>> > Coincidentally there was a recent discussion[2] about these signs in
>>> the
>>> > french mailing list (talk-fr) which lead to adding the following
>>> section
>>> > in the page
>>> > https://wiki.openstreetmap.org/wiki/Tag:man_made=surveillance
>>>
>>> I warn that this addition does not reflect the discussion that took
>>> place on talk-fr, but is "self-declared as consensus"
>>> more than half of the opinions are that a regulatory sign of this kind
>>> is not tourist information (imho I think it is closer to a sign that
>>> announces a pedestrian crossing or a maxspeed zone)
>>> ___
>>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging the presence or absence of signs for surveillance cameras

[John Sturdy]

Whatever the concensus in another discussion was, I think that double
negatives will risk confusion, and that *:signed=yes and *:signed=no seems
to be a reasonable proposal.

I have noticed that some but not all of the surveillance cameras (city
council, I believe) in Cambridge (UK) have signs.

__John

On Wed, Feb 19, 2020 at 10:13 AM marc marc 
wrote:

> Le 19.02.20 à 04:29, Victor/tuxayo a écrit :
> > Coincidentally there was a recent discussion[2] about these signs in the
> > french mailing list (talk-fr) which lead to adding the following section
> > in the page
> > https://wiki.openstreetmap.org/wiki/Tag:man_made=surveillance
>
> I warn that this addition does not reflect the discussion that took
> place on talk-fr, but is "self-declared as consensus"
> more than half of the opinions are that a regulatory sign of this kind
> is not tourist information (imho I think it is closer to a sign that
> announces a pedestrian crossing or a maxspeed zone)
> ___
> 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] Unremovable bollards

[John Sturdy]

I think that by default bollards are not removable, and that if a bollard
is not tagged as removable, it is reasonable to assume it's not removable.

On Sat, Feb 15, 2020 at 6:54 PM Hauke Stieler  wrote:

> Hi all,
>
> there's the "bollard" key with documented value "rising" and "removable"
> [0] but I often encounter also bollards which cannot be removed easily.
> I would love to see the "unremovable" value in the documentation. Should
> I open a proposal page for this one value? That sounds a bit of an
> overkill to me.
>
> My suggestion is the value "unremovable":
> A bollard which cannot be removed without destroying it or at least
> cause severe damage to it. A bollard which can only be removed by
> authorized people with some sort of key is still "removable".
>
> I would not use the value "fixed" or "irremovable" for two reasons: The
> "unremovable" value is used more often [1] and would be a good
> counter-value for "removable".
>
> Hauke
>
> [0] https://wiki.openstreetmap.org/wiki/Key:bollard
> [1] https://taginfo.openstreetmap.org/keys/?key=bollard#values
>
> ___
> 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] Tagging small areas of bushes, flowers, non-woody perennials, succulents, etc

[John Willis via Tagging]

> On Feb 9, 2020, at 5:09 PM, Martin Koppenhoefer  
> wrote:
> 
>> and not
>> everyone is happy about using natural=scrub for this case.


+1

When I go to a garden, there is not natural=scrub growing in manicured rows 
along the garden paths, separating the flower beds.

that’s like using natural=scree for a pedestrian area.  


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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[John Willis via Tagging]

> On Feb 7, 2020, at 7:48 PM, Peter Elderson  wrote:
> 
> If area=yes is added to say a leisure area surrounded by a hedge, that is a 
> mapping mistake. If that results in the area displaying as a hedge area, the 
> mapper has to correct that, not the renderer.


exactly!

If I want a hedge around a tennis court, I draw a hedge around a tennis court. 

if a traffic island has a large triangle shaped hedge, then I draw a large 
triangle shaped hedge with area=yes. 

Mappers can’t mix area and way tags on the same object if they depend on 
area=yes to define what they are. 


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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[John Willis via Tagging]

> On Feb 6, 2020, at 5:14 AM, Jeroen Hoek  wrote:
> 
> Keeping the rendering for `barrier=hedge` plus `area=yes` for the time
> being seems sensible and in keeping with the general use of those two
> tags in combination.


+1

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

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[John Willis via Tagging]

> On Feb 3, 2020, at 10:09 PM, Paul Allen  wrote:
> 
> It isn't wrong to use barrier=hedge, since it does provide a visual
> barrier


It also provides a physical barrier. Try riding a bike through one, or sleeping 
on one, or taking a shortcut through one!

Hedges are physical barriers made of plants. people put them for decoration 
*and* to keep people out of many areas.

a hedge is any bushes that have been pruned into an ornamental barrier. they 
may be singular or plural. 

people, such as myself, micromap hedges in some areas. I don’t use them for 
trees or flowerbeds, but you will find plenty of hedges in a rose garden 
keeping people from taking shortcuts through the flowers. 

removing the rendering for area=yes on the hedge is a very poorly thought out 
decision. 

it should be reversed. 

Javbw


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

Re: [Tagging] change bicycle_parking=floor to surface

[John Willis via Tagging]

> On Feb 4, 2020, at 3:29 AM, Florimond Berthoux  
> wrote:
> 
> I agree that buildings/sheds should not be used for this key, since we cannot 
> precise the type of "rack" inside the shed/building.



I agree that “=shed” should not be a value.

building=shed
amenity=bicycle_parking
bicycle_parking=foobar (whatever method secures the bike inside). 

I would tag this using the alternative method mentioned above, but there are 
3,700 uses of =shed already. 

Perhaps discouraging this value is a good idea. 

Javbw








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

Re: [Tagging] change bicycle_parking=floor to surface

[John Willis via Tagging]

Okay, a lot of notes: 

Javbw

> On Feb 3, 2020, at 4:06 PM, Warin <61sundow...@gmail.com>
> 
> I
> surface=paved says nothing about if the bicycle can be secured and what too.

Surface= tag is different from =surface value. 

Amenity=parking 
Parking=surface 
Surface=asphalt

For cars.

Amenity=bicycle_parking
Bicycle_parking=surface
Surface=asphalt 

For bikes says the same thing. 

But for bikes, there are a myriad of options for the parking. The most common 
are racks (63 percent) and then various others. 

Most of those are covered=yes or covered=no (with a simple roof or overhang. 

> The bicycle_parking key is used for lots of things...
> 
> buildings/sheds
> 
> stands/racks
> 
> A very poor key!

I think the bike parking key is **primarily concerned with how the bicycle is 
restrained**. Every value but =floor is about that. Everything else is 
secondary. 

By combining it with a structure (or as an encompassing area of many 
structures, such as individual rows of sheds) or as a tag on other structures 
(multilevel car parking or building=yes) it is very flexible in how it is used. 

> I think the key should be replaced.

For the 150,000 uses.of most of the racks, it is *perfect*. It just needs the 
rough edges take care of. 
> 
> 
> Buildings and sheds already have a key building=* so those values can be 
> depreciated.

They want to use it in conjunction with building=yes. 

Tagging the type of restraints (such as individual sheds) makes sense.

> 
> 
> Stands/racks are all indications of how the bike is held while parked.
> 
> bicycle_holding=stand/rack/bollard/post/* ?

This is the heart of bicycle_parking already 

> Then the issue of securing the bicycle?
> 
> bicycle_secure=lock,supervised,provided_lock,*

Supervised=*  already exists it doesn’t speak to how the bike is physically 
secured. 

Provided automatic locks are not for you, but for the payment operators (afaik) 
- I could break any bike out of the tethers or tire hooks in less time than it 
takes to tie your shoes. Securing the bike is something your own lock should 
do. 

But the most necessary option is “no” option to secure, because the others are 
all implicitly securable with your own equipment - yet 2 documented ones do not 
inherently give you the option to secure it to something.

As far as these automatic or supplied locking mechanisms are, is there some key 
for parking lots that tag the specific car parking fee enforcement, such as the 
retractable flap, bollard, or tire block? Perhaps that would be a good model 
for tagging these type of payment enforcement locks. 

In summary, I am only worried about =floors and some way to say there is some 
explicit tag for no way to secure the bike to another object. 






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

Re: [Tagging] change bicycle_parking=floor to surface

[John Willis via Tagging]

https://wiki.openstreetmap.org/wiki/Talk:Key:bicycle_parking 


looking over the discussion page, they added =floor in sept 2017 (in response 
to various questions) to not only be a =surface substitute, but for it to be 
combined with building=yes to tag fully enclosed bicycle parking buildings (not 
sheds, nor covered=yes roofs, but full buildings). I understand the reason - so 
the type of stands can be tagged onto an existing building=yes polygon (rather 
than using something like parking=multilevel). 

Currently, =floor makes up 0.15% of usage (256 uses), the lowest of all the 
documented values (compared to stands at 109,000 / 63%). 

https://taginfo.openstreetmap.org/keys/bicycle_parking#values 


this may seem like a little thing, but there will thousands more if just Japan 
is properly mapped. 

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

Re: [Tagging] change bicycle_parking=floor to surface

[John Willis via Tagging]

> On Feb 3, 2020, at 8:02 AM, Warin <61sundow...@gmail.com> wrote:
> 
> But it will not be replaced by the surface key as the tag represents 2 things.


I think trying to represent the two ideas is too difficult. 

https://wiki.openstreetmap.org/wiki/Key:bicycle_parking 


All of the other bicycle_parking values *imply an ability to lock your bike to 
some object*, but =ground_slots and =floor (and =surface) imply *do not*, 
because it is assumed that cyclists know about this already. The wiki has a 
note: “no security” , but the security level is not represented in any of the 
values for this tag. it is all assumed.

In places with high numbers of “surface” parking lots, this is well known -  
but might be unexpected in places outside Asia. it should be explicitly tagged. 
  
So I think it is too much to ask of these two existing tag definitions (or 
=surface) to do double-duty in this manner, as none of the other tags do either.

the implication for these two tags should become an explicit “no” via a new tag.

We should change =floor to =surface 

and 

create a bicycle_parking:lock_point=no tag and add it to both =ground_slots and 
=surface in the wiki (or “lockable” or some other similar value). 

It should be easy to add an iD preset to include it.

There may be incidental poles (such as shelter supports for covered=yes) that 
would allow a few to be locked informally, but that’s not available to all 
users. When there is no rack/stand meant to hold bikes in position in any way 
(=surface) and when there is no formal affordance for securing the bike 
(:lock_point=no), both of these tags should be used. 

That should cover the situation.

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

Re: [Tagging] change bicycle_parking=floor to surface

[John Willis via Tagging]

On the OSM wiki for bicycle_parking=, there are ~10 different values for 
racks/stands/trees/bollards of various types. Our cup runneth over. 

we are talking about one value, =floor, which would be called =surface if it 
was car parking. 

I want to change that value to =surface before =floor becomes more widespread, 
so “parking” tagging is more uniform, 
besides the fact that “floor” is a bad value for what it represents. 

Javbw  

> On Feb 3, 2020, at 8:42 AM, Kevin Kenny  wrote:
> 
> A possibility: bicycle_rack=yes/no?

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

Re: [Tagging] change bicycle_parking=floor to surface

[John Willis via Tagging]

Bicycle parking is full of different kinds of stands. 

“Floor” is Currently the the lack of anything - just an open area to park. 

But 

A) “floor” doesn’t mean “lockable” or not. All the others describe stands and 
poles and whatnot, but  ** “Floor” doesn't explicitly mean “no locking 
affordance” -  It’s implied.** The same is true for =surface or =ground or 
=flat.

B)  A designated painted square of outdoor asphalt with a bicycle painted on 
the ground is the same thing as the well established parking=surface - but 
somehow requires a Different word for bikes? **that is inconsistent.**

A large majority of bike parking in Japan/Asia is this type of parking. 
Stands/two-tier are common in urban paid parking/schools/apartments, but ~80% 
or more are just designated flat ground with a sign - just like a parking lot. 
The bike parking I map most often is this type - formal, painted, designated 
flat ground for bike parking with no stands, loops, rails, or anything else for 
all the bikes to be chained to, covered=yes or not. 

C) “floor” is used for indoor building location descriptions. (layer is for 
separating logically overlapping data features, not for this). “Floor” implies 
indoors to me. Outside doesn't have a floor. the “ground slots” value isn’t 
called “floor slots”. 

These 3 reasons make it a poor choice over The well established parking value 
=surface, and since they are basically the same, I think we should use the same 
tag value for both. 


Javbw

> On Feb 1, 2020, at 11:07 PM, Florimond Berthoux 
>  wrote:
> 
> I think it's not exactly the same feature, one thing interesting in the 
> bicycle_parking for cyclist it to know if you can secure your bike.


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

Re: [Tagging] Active volcanoes

[John Willis via Tagging]

> On Jan 30, 2020, at 8:36 AM, Andy Townsend  wrote:
> 
> the things that we tag in OSM won't necessarily map 1 to 1 onto wikipedia 
> pages.


Generally this is true, but I think most active volcanoes - especially ones OSM 
mappers would be mapping - have wiki pages. 

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

[Tagging] change bicycle_parking=floor to surface

[John Willis via Tagging]

https://wiki.openstreetmap.org/wiki/Key:bicycle_parking 


It lists “floor” as the value for a wide open outdoor space with no stands or 
other affordances designated for parking bicycles. 

this seems weird to me. the ground / asphalt area next to a supermarket is not 
a “floor”.

we use “surface” in car parking lots, and there are many of other types of 
indoor tags for tagging when a bike is in a building or shed (similar to 
parking=multilevel). 

I think that the values be standardized and the wiki changed. 

there is 60 uses of (undocumented) =surface and ~260 uses of (documented) 
=floor. 

we should standardize how we tag parking lots for any vehicle if it is just a 
flat outdoor surface. 

Javbw 


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

Re: [Tagging] Active volcanoes

[John Willis via Tagging]

I agree with you that this is the scale that volcanologists use, but people 
want to draw a distinction between something that erupted recently compared 
sometime in the last 200 years

Perhaps it is easier to just apply the “active” and “Frequently active” tags 
via this third-party data source, but it would completely remove mapper’s 
ability to add a mountain to this list via tagging. 

Inventing a separate schema seems like a bad idea, but I don’t think people 
understand “active” could mean an eruption before the industrial revolution, 
and people seem to want to add more granularity to this data. Maybe that is a 
bad idea, but should be considered. 

Javbw

> On Jan 27, 2020, at 3:14 PM, Graeme Fitzpatrick  wrote:
> 
> 
> 
> 
> 
>> On Mon, 27 Jan 2020 at 14:57, Graeme Fitzpatrick  
>> wrote:
>> I saw reference to this site a little while back (ironically, the morning of 
>> the White Island eruption in New Zealand :-()
>> https://volcano.si.edu/faq/index.cfm?question=activevolcanoes
>> 
>> So what do we say: 43 / 70 / 565 / 871 or 1428? :-)
>> 
>> https://volcano.si.edu/faq/index.cfm?question=eov_noteworthy  
>> 
>> Or possibly the 71 "Frequently Active" listed here?
>> 
>> As they say, it's hard to point at a volcano & say it's active or not!
> 
> Responding to my own post after looking at the site a bit more
> 
> How about using the common terms that everyone recognises, together with OSM 
> definitions of:
> 
> Active - Known to have had major / multiple / fatal eruptions; frequently 
> active; significant lava flows - the 186 volcanoes that are listed as 
> "Noteworthy"
> 
> Dormant - probably the 1428 "Historically Active" - confirmed & likely 
> historical eruptions (mixing historical & Holocene together)
> 
> Extinct - ain't nothing happening no more! :-)
> 
> This does, of course, relate to using info from that list. Do any of our US 
> friends know how helpful the Smithsonian is when it comes to sharing data? 
> https://www.si.edu/termsofuse/
> 
>   Thanks
> 
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Active volcanoes

[John Willis via Tagging]

Yep - I live at the base of Mt Akagi in Japan.

Locals know the volcanoes. Some of that is historical, some is local knowledge. 

I have been hiking on many volcanoes around me. Kusatsu-Shirane was closed in 
2014 after a small steam eruption killed/injured some skiers. The hiking, 
skiing and sulphuric lakes are closed now, but the road over the mountain 
(through the sulphur vents) and the famous tourist town of Kusatsu remain open. 

 Akagi last had a small steam eruption in the 700s. It really hasn’t done 
anything since

I live 70 KM from the most active volcano on the main island - Mt Asama. Some 
day it will Erupt and in the future violently explode. It smokes and burps and 
makes earthquakes regularly. 

There was a major eruption on mt Fuji in 1707 which made a giant crater on the 
flank (Hoei crater). The 2011 Earthquake(s) triggered a 6.0 below Fuji, so it 
is still “active”, yet hasn’t really done anything since the hoei eruption. 

I think there is a way to make a very simple subtag, such as 

Volcano:active= 
No= Considered dead / collapsed
Dormant = 500+ years since last eruption
Quiet = 100
Recent = 20
Current = smokes, ash burps, eruptions, or other visible Signs of activity In 
the last 20 years. 

20 years is nothing to the volcano nor those who live near it. 

Some scheme like that. Whatever names you want, I think that is a good time 
scale.  Make it a year/date if known *in addition*. So many volcanoes will have 
a last eruption date & status that will stay the same for the foreseeable 
lifetime of all humans currently on earth (Akagi), some that will probably not 
change in 50 years (Mt Fuji) and even more that will probably also not have 
data change in decades (Kusastu-shirane). 

Active volcanoes will get their tags updated when they erupt because locals 
take notice *and* if we make some easy schemes for them to tag the info. No 
need to keep updating the status of Asama - it is “current”. Make it easy and 
the worry about data currency is not an issue. 

Javbw

PS - tagging calderas is impossible currently - no way to tie the name of the 
giant famous  Caldera (Akagi) to the numerous little named (and largely 
obscure) peaks that make up the rim. People get all in a tizzy worrying about 
“Prominence“, whereas the internationally famous tag for Mt fuji is drowned out 
by the several “mountains” that make up the named bumps on the crater rim. Mt 
Fuji should be rendered at z6 and Akagi at z8, and the little obscure “peaks” 
at z14. 

Handwringing over prominence be dammed: the map is worse for not having the 
same level of detail we give to roads and cities - or even railroad rail! - to 
mountains. 

Without a tag schema, there is no way to get it rendered properly. 

Same goes for all of this useful data. 

Javbw. 

> On Jan 25, 2020, at 4:29 AM, Clifford Snow  wrote:
> 
> As a person living 50km from an "active"  but dormant volcano, Mount Baker 
> [1], I definitely know its status.


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

Re: [Tagging] How to tag Landscaping tarpaper / weedblocking paper

[John Willis via Tagging]

> On Jan 21, 2020, at 12:04 AM, Martin Koppenhoefer  
> wrote:
> 
> if the sheets are the topmost thing before the air of the atmosphere, surface 
> would be fine


as an FYI, I am only interested in mapping any of these types of things if they 
are clearly visible all the time and installed permanently (present year to 
year), as they are a visible. somethign that would go in the surface= tag. 

Most farming plastic (like the ones used to grow vegetables) is not mappable, 
as it is only present 3 months of the year and is constantly changing location 
in a farm field year to year. 

Similarly, if a soil stabilizer / sheeting / plastic  is permanently visible on 
the surface it should be mapped as a surface, but if it is buried and not 
visible - like most landscaping paper buried in the ground -  then it should 
rightly be ignored. 

if someone wants to come up with an embankment:stabilized=mesh (or whatever) 
tag for known stabilized slopes, thats fine with me, but I am not pursuing 
that. 

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

Re: [Tagging] How to tag Landscaping tarpaper / weedblocking paper

[John Willis via Tagging]

I am familiar with all of those materials. I agree that they are all different 
(landscaping paper, farming plastic, weedblocker, tyvek house moisture 
barrier). I use all of them at my house. 

This is something different. Something very very thick (2-3mm!) , made with tar 
or other marital that is fairly stiff yet rollable, and has a opaque, coated, 
impermeable surface - very similar to the tarpaper I use as a moisture 
barrier/underlay on roofing - yet is commonly used as a kind of functional 
landscaping cover in industrial / transportation places (traffic islands, etc) 
where weeds would be bothersome. 

And as far as I can tell, it is manufactured for this exact purpose (with 
accessories and standardized installation techniques) for it, not simply 
repurposed roofing tarpaper used in a different manner - so it must have a 
unique name of some kind. 

Javbw

> On Jan 17, 2020, at 5:23 AM, Kevin Kenny  wrote:
> 
> These materials are typically not paper, nor plastic film, but rather
> some sort of woven or felted material


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

Re: [Tagging] How to tag Landscaping tarpaper / weedblocking paper

[John Willis via Tagging]

- yea, a lot of the erosion control searching online I have seen is open mesh 
or open squared checkerboard. 

- yea, a lot of weed paper is root-blocking /light blocking sheeting, usually 
.5mm thick or so 

- the farming plastic is a weed barrier, and also a wind erosion barrier. (The 
dust can be amazing in early spring) There are hundreds of KM of 1m wide .1mm 
plastic with holes in it for various vegetable fields around my home here. It 
is temporary and reusable. 

- the “heavy” sheeting i am talking about that I see for erosion control (not 
necessarily slope stabilization) is thick - like 3-4mm thick roofing material,  
like felt tarpaper, with a hard green-gray outer coating (not tar). It is held 
in place with large stakes/staples and those holes are “taped”shut, and all 
seams “taped” as well. It is used gap filler and small embankment cover around 
roadway landscaping and between buildings to totally stop all the kudzu and 2m 
tall sticker-covered weeds from getting a foothold and/or torrential downpour 
erosion protection for many years. 

There is a small amount near my home, I’ll snap a picture of it. It is not a 
“mappable” amount, but should give you an idea of what it is. 

It is somewhere between weed blocker and the soil stabilizing meshes - but 
unlinke the meshes (which often get overgrown) or the farming sheeting (which 
is temporary and used in fields), this is permanent (decade or so) and always 
the top surface. 

So what would be a good surface=* be for it? Tarpaper sounds too close to the 
roofing material, which could cause confusion. 

We should think of some surface=* values for the stabilization meshes 
(metal/plastic) as well. 

Javbw

> On Jan 16, 2020, at 10:47 AM, Joseph Eisenberg  
> wrote:
> 
> This sound like a surface=* feature, since it isn't a landuse or
> natural vegetation type.
> 
> Plastic sheeting is also used on some types of farmland, for example
> strawberry fields, for weed prevention.
> 
> So map the area's function with landuse=railway/industrial/farmland or
> natural=scree/sand/etc. or area:highway=, or whatever is relevant, and
> then add surface=plastic_sheeting, surface=tar_paper, etc.
> 
> If you don't know the landuse or function, and there is no natural
> vegetation, I would use surface=* alone.
> 
>> On 1/16/20, Warin <61sundow...@gmail.com> wrote:
>>> On 16/1/20 11:59 am, John Willis via Tagging wrote:
>>> here in Japan and other places where unwanted vegetation grows very
>>> quickly and/or has heavy rain, heavy tar paper / plastic or metal mesh /
>>> or plastic “weedblocking” sheeting is commonly used on embankments,
>>> traffic islands, and other places where people want to stop weeds from
>>> growing and to prevent erosion from heavy rain. Stakes or landscaping
>>> staples hold it in place, and sometimes seams are sealed with additional
>>> material (if the barrier is for weedblocking).  It is commonly seen in
>>> industrial settings (areas around factories), and in public areas around
>>> roads and other transportation infrastructure where people don’t walk.
>>> this is a permanent landcover, not temporary covering for construction,
>>> etc.
>>> 
>>> While I admit it is rare to tag a lot of this, when mapping public areas
>>> around some roads, I have found more and more of it.
>>> 
>>> looking in surface= and landcover= , I cant find anything that matches.
>>> “tar paper” as a roofing material is on the wiki, but noting else about
>>> “landscaping” or “weedblocking” is found.
>>> 
>>> What do people suggest is a good name to add to “surface” or “landcover”
>>> for such a surface?
>>> 
>>> Looking around the internet, there is a large variety of “erosion control”
>>> sheeting and materials (this tar paper, plastic & metal mesh, and other
>>> landcovers meant to control erosion on slopes), so perhaps a tag for all
>>> of them is appropriate.
>>> 
>>> Perhaps landcover=erosion_control is a good tag for all of these types of
>>> sheeting applied to the ground. if a further refinement is needed (and
>>> someone knows the proper names for these things, then a subtag can be
>>> added later  (erosion_control=foo_bar).
>> 
>> 
>> Different things ;
>> 
>> erosion control,
>> 
>> weed block.
>> 
>> The weed block plastic here is called 'weed mat', it is designed so as not
>> to allow sunlight through, well not enough for a plant to grow.
>> 
>> On a steep slope it will do nothing for erosion control as it sits above the
>> soil. I have a few square meters of it at home.
>> 
>> Erosion control may well allow enough sunlight through to enable plants to
>> grow .. including weeds.
>> 
>> 
>> 
>> 
> 
> ___
> 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] How to tag Landscaping tarpaper / weedblocking paper

[John Willis via Tagging]

here in Japan and other places where unwanted vegetation grows very quickly 
and/or has heavy rain, heavy tar paper / plastic or metal mesh / or plastic 
“weedblocking” sheeting is commonly used on embankments, traffic islands, and 
other places where people want to stop weeds from growing and to prevent 
erosion from heavy rain. Stakes or landscaping staples hold it in place, and 
sometimes seams are sealed with additional material (if the barrier is for 
weedblocking).  It is commonly seen in industrial settings (areas around 
factories), and in public areas around roads and other transportation 
infrastructure where people don’t walk. this is a permanent landcover, not 
temporary covering for construction, etc. 

While I admit it is rare to tag a lot of this, when mapping public areas around 
some roads, I have found more and more of it. 

looking in surface= and landcover= , I cant find anything that matches. “tar 
paper” as a roofing material is on the wiki, but noting else about 
“landscaping” or “weedblocking” is found. 

What do people suggest is a good name to add to “surface” or “landcover” for 
such a surface? 

Looking around the internet, there is a large variety of “erosion control” 
sheeting and materials (this tar paper, plastic & metal mesh, and other 
landcovers meant to control erosion on slopes), so perhaps a tag for all of 
them is appropriate. 

Perhaps landcover=erosion_control is a good tag for all of these types of 
sheeting applied to the ground. if a further refinement is needed (and someone 
knows the proper names for these things, then a subtag can be added later  
(erosion_control=foo_bar).

Thoughts?

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

Re: [Tagging] amenity=tourist_bus_parking

[John Willis via Tagging]

Thank you for this clarification. I will try to repair the lots I have tagged. 

Javbw

> On Jan 14, 2020, at 5:02 AM, Markus  wrote:
> 
> In order that data understand your example and before we've found a
> solution for parkings for multiple vehicle classes, i would recommend
> to tag it as follows:
> 
> amenity=parking
> access=no
> bus=customers
> hgv=customers
> 
> Regards
> 
> Markus

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

Re: [Tagging] amenity=tourist_bus_parking

[John Willis via Tagging]

To me, there are a few requirements of “designated” parking lots: 

1)  it is signed as such: "Cars go here and HGV go there” , “cars, right” and 
“HGV, left”, directing you to different lots. Lots are labeled on signage 
telling which vehicle types to go where (cars/HGV/motorcycle/ + disabled).

2) it is designed with the vehicle in mind: Spaces are painted for the size of 
expected vehicle. The lanes are wider and turning radius of the turns are meant 
for larger vehicles in HGV lots. This is easily visible on imagery. 

3) It offers Amenities for the specific Vehicles: Very large wheel-stops for 
HGV, or parking spaces where backing out is not necessary for HGV. There might 
also be amenities for bus passengers (since the buses often have to park 
further away from the location), such as additional Toilets & vending machines 
far away from the main location, but adjacent to the bus parking area.

4) It is human enforced: When there is a large amount of traffic, people 
directing traffic enforce these rules. While they may choose to break their own 
rules to manage the spaces in an efficient way, it is not up to the driver to 
do so. People direct the cars & HGVs to the correct lots during busy days. This 
might also mean gate or cone barriers that are moved by employees when they are 
needed (common with disabled & bus lots in busy places in Japan).

5) People are advised to follow thew rules with additional signs & notices 
around the location you are visiting: there are signs saying not to park your 
car in the HGV spaces (or in the disabled spaces or the loading zones). 
Official signage (seen in restrooms and posters all over the service area) from 
the Tollway operator NEXCO regarding parking in the bus parking: 
https://www.driveplaza.com/special/mannerty/library/img/img_001_016.gif 

Of course, this is represented by the “Rude Shark” and the “Mannerty the 
manatee” in the “Heartful Highway” signage all over the tollway here. 
https://www.driveplaza.com/special/mannerty/library/index.html 

check them out, you don’t need to read Japanese to enjoy them. 

6) police enforcement / Legal enforcement: I am not aware of anyone getting 
their car towed or getting a parking ticket in anywhere in Japan *ever*, 
because there is little to no such police enforcement anywhere in Japan for 
parking rules/laws via towing/citations (unlike America). Expecting this to be 
tow-enforced / ticketed is not a reasonable threshold, because there is 
basically no tow-enforcement / ticketing for almost any parking laws anywhere 
in Japan. 

My lots meet 5 of these “requirements", but I would say if you meet the first 2 
(signed + painted for the vehicle type), it is "designated". This is the 
threshold for motorcycle parking and disabled parking as well most everywhere 
else.

Javbw.

> On Jan 6, 2020, at 2:39 AM, Martin Koppenhoefer  
> wrote:
> 
> is “designated” implying that other vehicles cannot (legally or physically?) 
> use the parking, or that there are specific measures so that the designated 
> vehicles fit perfectly into the fixtures?
> 
> Cheers Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] amenity=tourist_bus_parking

[John Willis via Tagging]

https://www.openstreetmap.org/#map=17/36.31737/139.61884

Here is a good example of the kind of situations I have in my area:

- a service area with two different lots, car and HGV (bus/lorry) adjacent to 
each other, with a satellite bathroom for the busses. 
- service area is segregated by motorway direction, and labeled as such. This 
makes duplicates of everything.  They are usually not adjacent, but are in this 
case.
- dedicated separated handicap parking
- separate “permissive” lots for people outside the toll system to park and 
enter on foot. 
- loading zones for deliveries (untagged). 

This one also has a motel with a separate parking lot and a single (separate) 
disabled space. 

I don’t need to worry about nested parking lots - they are easily tagged as 
separate objects (and are signed/painted as such). 

Javbw

> On Jan 9, 2020, at 8:38 AM, Volker Schmidt  wrote:
> 
> 
> It is not unusual to have one parking area with one name with dedicated areas 
> for different vehicle categories. I cannot use amenity=parking for both the 
> entire parking area and the vehicle-type-specific "sub"-areas, at least JOSM 
> does complain when you do that. We could ignore that and use nested 
> amenity=parking tags. 
> 
> .
> 
> 
>> On Wed, 8 Jan 2020, 15:52 John Willis via Tagging, 
>>  wrote:
>> If I have a sign that says all cars go here, and all HGV goes over there, 
>> and one is painted for 1000 car spots and one has 50 giant bus spots, those 
>> are designated lots. 
>> 
>> I have used parking_space when I have found A lone disabled space - but a 
>> group of 50 spots for busses is a bus lot. 
>> 
>> At least being able to say “this is the lot for busses” as an attribute of 
>> amenity=parking should be doable (with a subtag). 
>> 
>> Javbw
>> 
>>>> On Jan 8, 2020, at 7:18 PM, Volker Schmidt  wrote:
>>>> 
>>> make use of the fact that amenity=parking_space can be used for this.
>>> Make separate parking space areas for different vehicle types.
>> ___
>> 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] amenity=tourist_bus_parking

[John Willis via Tagging]

If I have a sign that says all cars go here, and all HGV goes over there, and 
one is painted for 1000 car spots and one has 50 giant bus spots, those are 
designated lots. 

I have used parking_space when I have found A lone disabled space - but a group 
of 50 spots for busses is a bus lot. 

At least being able to say “this is the lot for busses” as an attribute of 
amenity=parking should be doable (with a subtag). 

Javbw

> On Jan 8, 2020, at 7:18 PM, Volker Schmidt  wrote:
> 
> make use of the fact that amenity=parking_space can be used for this.
> Make separate parking space areas for different vehicle types.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=tourist_bus_parking

[John Willis via Tagging]

> On Jan 7, 2020, at 3:37 AM, Martin Koppenhoefer  
> wrote:
> 
> For a municipal tourist bus parking, who is "customers" referring to? 
> Customers of what?

Tollway service area  lots inside the toll area are “customers” of nexco, the 
operators. There are “permissive” lots outside the toll area at service areas 
as well for anyone to access the services (locals going to the shops there, for 
example), but the lots inside the toll are considered access=customers. 

The “road station” network on the regular trunk roads are “permissive” as 
anyone can drive up and use it whenever. 

Sorry if O am using [vehecle]=designated incorrectly, but it seems to fit for 
busses. 

But all the lots are just parking lots, and the ones designed for busses or 
other HGV should be tagged, and instead of making a whole new amenity, I think 
a subtag is a  better solution. 

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

Re: [Tagging] amenity=tourist_bus_parking

[John Willis via Tagging]

> On Jan 6, 2020, at 1:27 AM, Florimond Berthoux  
> wrote:
> 
>> I have just detected the wiki page "amenity=tourist_bus_parking"

Why is this it’s own amenity, instead of 

amenity=parking
bus=designated
access=customers

?

Many Service areas in Japan has an HGV/BUS parking lot with amenities for tour 
buses - should all those parking lots be retagged?

I really want to be able to tag specific uses and types of parking lots, but I 
think it is better left to a subkey (parking=*) to define them better, rather 
than having to make up new amenities for the same thing.

parking=tourism
parking=disabled
parking=loading_dock
parking=taxi
parking=waiting_lot
etc


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

Re: [Tagging] Discourage use of landuse=churchyard?

[John Willis via Tagging]

Landuse=religious. We don’t have mosqueyard or shrineyard or templeyard. 

Wether or not there is a graveyard, a parking lot, a memorial, a statue, a bell 
tower or whatever inside the fence - doesn’t matter -  the land designated to 
the main POW is tagged as landuse=religious. Everything on the grounds, from 
the gift shop to the wayside shrines along walking paths are all on the 
“grounds” of this named location. This is especially useful where the Landuse 
(the complex overall) has a different name than the individual buildings /POWs 
/ other named objects that are on the grounds, which happens a lot in my area. 

This churchyard should be depreciated. 

Javbw

> On Dec 23, 2019, at 2:29 PM, Joseph Eisenberg  
> wrote:
> 
> Used to map the area
> surrounding a christian church or chapel


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

Re: [Tagging] Tag for "tax free shopping"

[John Willis via Tagging]

Almost all department stores in Japan advertise this for travelers, as it is 
part of their standardized signage, so you will see it even in rural or remote 
branches (not just near the airport or In. Tokyo.  While I wouldn’t expect this 
service at small shops, it is a common sight to see “tax free” or “duty free” 
here in Japan. Here is the official signage seen in many places:
https://tax-freeshop.jnto.go.jp/eng/step.php

Yes - This is metadata about the shop. 

However, in airports, there are pointedly “duty free” shops for (all) 
travelers. that have no ability to collect taxes for any purchase, so 
shop=gifts + duty_free=designated might be a good way to do it for these 
specialty shops in international zones, Compared to shop=supermarket + 
duty_free=yes that would be at a normal market that offers that service for 
foreign travelers who happen to shop there. 

Javbw

> On Dec 21, 2019, at 8:16 AM, Joseph Eisenberg  
> wrote:
> 
> Just duty_free=yes would be good for a shop in town which offers tax-free 
> sales for international travelers.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[John Willis via Tagging]

> On Dec 13, 2019, at 2:20 AM, Michael Behrens  wrote:
> 
> I would agree that a 'link' should be tagged as a approach



Then the word "approach" shouldn’t be used - use “link”. Use the same 
vocabulary as other route relations. 

We shouldn't use bespoke words when the standardized synonym word is already 
used in tagging other route relations.

if there is some major difference between an approach and a link, then sure, 
but it really sounds like a link. 


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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[John Willis via Tagging]

Links - as in a relation role value “link” - as in small pieces of trail that 
link some other trail or way to the main route. 

Just thinking of routing Terms we use for other types of routes.

Javbw

> On Dec 12, 2019, at 2:22 PM, Warin <61sundow...@gmail.com> wrote:
> 
> What links? urls? or do you mean ways that connect the route to 
> bus/train/etc? In which case I think those can be role approach ?


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

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[John Willis via Tagging]

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

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

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

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


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

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

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

also - does the relation need intersection/junction nodes? 

also also - links?

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

Re: [Tagging] Foot or foot.cycle crossing

[John Sturdy]

I think of highway=path as referring to a standalone path, such as a hiking
trail, and not part of a set of parallel ways.

__John

On Wed, Nov 27, 2019 at 3:13 PM Volker Schmidt  wrote:

> I do have a topological problem with the mapping of a junction of two
> roads one of which has parallel cycle lanesa and sidewalks
> Both are correctly mapped: the sidewalk as a separate highwy=footway and
> the cycle lanes as cycleway:left|right=lane.
> How to you tag the foot-cycle crossings.
> See this Mapillary photo
>  to make things
> clearer.
> Two possible options:
>
> (1)
> way with:
> crossing=uncontrolled
> footway=crossing
> highway=footway
> plus node with:
> crossing=uncontrolled
> highway=crossing
>
> (2)
> way with:
> bicycle=designated
> foot=designated
> highway=path
> path=crossing
> segregated=yes
> plus node with:
> bicycle=yes
> crossing=uncontrolled
> highway=crossing
>
> Both are "incorrect" in some aspects.
> Which one is less incorrect?
> Is there a better tagging solution?
> ___
> 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] Long term detour routes ?(construction, disaster)

[John Willis via Tagging]

Tagging cycling roads on levees. 

Levees have construction projects that can be years in length (building a new 
sluice gate, enlarging the levee), and the route is detoured around this 
construction. 

https://www.openstreetmap.org/#map=16/36.1327/139.7509

Route=detour exists for *permanent alternate* routes that exist in addition to 
the existing route (per the wiki).

But For these detour segments on the cycling route I am mapping, they are the 
*only option* (the regular route is physically gone), so I’m thinking the route 
relation role=detour onto these ways. 

In this particular example, the detour route was destroyed by the typhoon. I 
mapped a second detour route above. 

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

Re: [Tagging] How to tag earth walls in a shooting ramge

[John Willis via Tagging]

Not yet, but it is an option. 

Similar to bridge is man_made=bridge + whatever ways it has on it, my thinking 
is that the levee is the man_made=dyke way and then additional details of what 
it’s made out of. 

The earthen barriers are man-made, and are barriers, so some kind of barrier= 
tag is in order. Mapping the embankments on the sides would useful if they were 
gigantic. Otherwise some kind of earthen barrier is a barrier way. 

What do they use for barriers around battlefield training courses (tanks, 
infantry, etc?). Perhaps there is a barrier=berm necessary for earthen mounds. 
I don’t see how they work with levees, but they might be useful for this 
situation and places where =hedge and =block would be used. 

Javbw

> On Nov 21, 2019, at 1:11 AM, Marco Predicatori  wrote:
> 
> 
> ...and yet you've already turned embankments into dykes, where there's no 
> water


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

Although they are constructed the same (pile of dirt), they are named and 
mapped differently. The man_made=levee tag exists, and I just want to extend 
it. 

Perhaps the man_made=embankment
Can have a embankment=* to tag different types of berms and other man-made 
slopes, but in this case, the levee is already mapped by the =dyke tag. 

Maybe I missed something (I’ll re-read it), but I am not sure they can be 
shared. 

Thanks for the thought. 

Javbw

> On Nov 20, 2019, at 2:22 PM, Graeme Fitzpatrick  wrote:
> 
> Just wondering if the suggestion I gave Volker this morning about walls 
> around a shooting range may also work for you?


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 19, 2019, at 12:49 PM, Joseph Eisenberg  
> wrote:
> 
> Is there something else that we are expecting could be done by mapping
> this in great detail which cannot be done with a simpler
> representation + a DEM?

I understand that, topographically speaking, we can get information about it 
from another source and see the mound of dirt. In that sense, you are correct. 

But just as we show red diagonal lines through military bases, we should convey 
the extent of this man-made structure beyond inferring it’s existence from the 
road access limitations and other mapped barriers (fences, lack of roads, 
grass, scrub, etc). the height is just one feature of the structure that is 
massive and dominates the surroundings. 

- just as we tag hedges and guardrails and other barriers that are not gates 
and bollards directly on ways,  understanding there is a massive man-made 
barrier nearby is useful. It really limits access. A small levee can be stepped 
over in a few steps. These you have to climb. Both cannot be represented by a 
way (IMO). 

- I like tagging the detail of some things. It is useful to me and others to 
visualize the situation. Roads there are weird and complicated - explained only 
by being on the levee. We have roof:part and bridge:support and =tree other 
details for other objects of interest, and these giant structures seem worthy 
of being rendered differently than just the topo contours like the the side of 
a hill. I will be mapping them *anyways* to set their landcover, so having a 
scheme to map them is “free” mapping detail.  

- everything large should be represented with an area. I have 600m wide rivers. 
I have sluice gates you could drive a bus through. Levees wider than apartment 
complexes. All of them are things people see and navigate around as they 
traverse the levee, and correctly conveying to them “this is that levee” helps 
people orient themselves and properly plan their routes when moving 
in-on-around the levee. Right now, I can map the river, and I can map the 
ground cover, but not the structure - unlike other man-made structures (dams, 
bridges, buildings, parking lots, railway corridors, etc). Infrastructure, even 
giant piles of dirt, should be represented in a base map. 

- levees are a function. They block water. Their construction is of an inter 
and outer embankment. They move separately and branch and move, so representing 
the levee requires (IMO) mapping the embankments and the top - all three are 
“features” of the levee. Mapping the two embankments in a relation gives you 
the “top” for free. 

- Between the raised tollways that sit on 5m high raised road beds across my 
entire region and the hundreds of KM of levees, I have a lot of man-made piles 
of dirt that severely restrict access kris-crossing everything. And the levees 
are often adjacent *many* public amenities - parks, sports grounds, cycling 
roads, and other *heavily used* features. 

- they are very very important during a flood. In some areas, they might be the 
only safe spaces. They are covered with emergency spaces and other areas safe 
in a flood. Understanding you are “inside” the levee Vs “outside” the levee 
might be the difference between life and death. If a levee breaks, the only 
safe space might be on top of it. Mapping and rendering these structures makes 
it obvious to everyone where it is without inferring it from topo information. 

- they are known landmarks.

Javbw. 



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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

On Nov 19, 2019, at 6:53 AM, Richard  wrote:
> 
> Other than that, "dyke_area" or "area:dyke" in analogy to 
> https://wiki.openstreetmap.org/wiki/Key:area:highway ?

I think dykes/levees are made of inner and outer embankments, and pairing them 
might be the only way to do it properly. 

Whatever is decided for embankments (I will work on some examples today) I 
think a levee/dyke will have to be a relation of *some* sort (built on top of 
the existing man_made=dyke tag) - either a relation of this way plus: 
- 4 “levee lines (inner top+bottom)
- 2 embankments+ 2 embankment_area polygons
- 4 embankment lines. 

Mapping them as a total area (lower inner to lower outer) with a single polygon 
with the man_made=dyke as the “top” down the middle is unacceptable to me. The 
“top” is often a mappable area (with large levees worthy of this detail). If it 
big enough to need this detail, it has a pretty large and varying top area as 
well (as examples have shown). 

Also, The ship has sailed on “levee” - the term in OSM is dyke. 

Javbw

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[John Willis via Tagging]

+1

Make the proposal cover all non-road ways (footway, cycleway, path, bridleway, 
etc)

While we may not imagine a use-case for all of them, it is *far better* to have 
it standardized so mapping is similar - and when the issue comes up for a 
mapper in an unexpected situation, it’s there waiting for them. 

Totally on board for this. I have been using unmarked crossing for years - 
better to have a proper tag. 

Javbw

> On Nov 19, 2019, at 7:49 AM, Allroads  wrote:
> 
> When there should be a footway=link
> then there should also be a
> path=link
> cycleway=link


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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[John Willis via Tagging]

I use “unmarked crossing” for all connections of sidewalks where they dead-end 
and have to be connected into the road. 

could be useful there too. there is is no “sideway_link” or similar “footway 
routing link” to use, so unmarked crossing works really well, espcially 
considering it is where peds leave a sidewalk and interact with road traffic 
directly.  

> On Nov 18, 2019, at 6:27 AM, Markus  wrote:
> 
> indicate that these connections aren't sidewalks

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

for straight embankments, cuttings, slopes, if they are done with an area that 
shares nodes, then I don’t think you need a relation. if they are jsut two 
lines that happen to be near each other, and do not share nodes, you might need 
a relation to associate them. 

also, if a levee is made of two separate embankments, with a =dyke way in the 
center, those might need t obe related. 

Javbw

> On Nov 14, 2019, at 6:40 AM, Richard  wrote:
> 
> perhaps as a last step to perfection we might need some relations. Otoh quite 
> pragmatically 
> - what is the use of associating/relating those two lines (base and top)? 
> Do we map them to make it clear if you run there you fall down a cliff or 
> earth bank or run
> into a cliff? No need for relations for that.

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 16, 2019, at 7:50 PM, Andy Townsend  wrote:
> 
>  A complicated scheme dreamt up here isn't going to get taken up by anyone.  

I took these 3 pictures yesterday while out cycling: 
https://imgur.com/gallery/Wqc5Ems 

The largest of the 8 levees I rode on is 140m wide (edge to edge) where I took 
these pictures, according to an online imagery measuring tool. they are about 3 
stories tall. the north side levee is 100M wide. These are all built on flat 
open ground, the levees 100% man-made. the river is 600m wide here during a 
typhoon. 

others were: 

148&60m (both levees total width, near a river junction)
54&30m (smaller river)
40&50m (smaller river)
65&42-70m (they are widening them, a demolished house foundation seen here in 
maxar imagery  https://www.openstreetmap.org/way/746507486 
).

much farther upriver near my town, where the levee on a tributary begins, they 
are a modest 40 & 30m wide where they sprout out of foothills the river has cut.

~~~

I agree that complicated schemes won’t get used, which is why I want the 
smallest usable method necessary **for people who want to add more detail in 
addition to existing schemes** ,  something that scales similar to how we map 
businesses (pin, building, landuse) depending on how much detail you wish to 
add. 

if you don’t feel the need to map an embankment in such detail, don’t. if it is 
too small, don’t.  I don’t want to create a scheme that replaces the current 
embankment/cutting/ levee, but is on top of current schemes, and allows you to 
map their extent **if you wish to**.

When things are huge, you *have to* have the ability to represent *anything* in 
OSM by border or area. If I was living back in San Diego, the cuttings for the 
freeway are the only cuttings I can think of worth mapping as an area. here in 
Japan, embankments / cuttings/ levees are everywhere. One levee bank is wider 
than most railway corridors - and we have an area for those, despite that the 
train tracks already being mapped. We understand that the area of the corridor 
is useful, to represent landuse and as a defacto barrier.

The same is true for large embankments/levees. 

For very large features *of any type* in OSM, they their area needs to be 
represented *somehow* in OSM. 

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

Still looking for feedback on the idea, Specifically: 

- lower base way or area sharing nodes with the top line in embankment / 
cutting, etc? 

- relation or no relation needed?

- map levee with embankment pairs, or map with two pairs of levee specific tags 
in a relation with the =dyke way? 

Javbw

> On Nov 13, 2019, at 8:56 AM, John Willis  wrote:
> 
> I think there is a need for a basic relation, if I understand Martin 
> correctly, to simply associate the two lines, (for example, an =embankment 
> and an =embankment_base pair). When mapped, they are not joined. They are 
> merely adjacent. I am not sure of what “type” of relation to choose in iD, 
> but I assume someone will tell us which type to use.


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

Re: [Tagging] Feature Proposal - RFC - mimics

[John Willis via Tagging]

You can keep “concealed” and use the “theme” extension idea from playgrounds? A 
playground isn’t a pirate ship or an octopus, but it appears to be one. 

Tower:construction=concealed
Tower:theme=palm_tree

There are several towers that are mimicking religious symbols in the US, beyond 
trees and whatnot - but a tower simply painted green in a forest is concealed 
w/o a theme. 

Just an idea. 

Javbw

> On Nov 16, 2019, at 9:47 AM, Eric Theise  wrote:
> 
> tower:construction=concealed


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

The “reply-to” email address might be being secretly changed by some mail 
clients - when I choose “reply” to Peter’s mail, it chooses the tagging group. 
When I choose reply to Martin’s, it chooses Martin. This is Mail.app on MacOS 
10.13.6. I have never really had this issue before. 

I don’t think this is simply a tagging list issue - it might be a combination 
of factors.

> On Nov 14, 2019, at 9:05 PM, Peter Elderson  wrote:
> 
> Messages are sent with Reply-To: "Tag discussion, strategy and related tools" 
> mailto:tagging@openstreetmap.org>>
> So simple reply should be enough, that's what I do and it works.
> 
> Fr gr Peter Elderson
> 
> 
> Op do 14 nov. 2019 om 11:46 schreef Martin Koppenhoefer 
> mailto:dieterdre...@gmail.com>>:
> 
> 
> sent from a phone
> 
> > On 14. Nov 2019, at 04:08, John Willis via Tagging 
> > mailto:tagging@openstreetmap.org>> wrote:
> > 
> > Sorry, I am continuing to have trouble properly replying to the tagging 
> > group, it keeps defaulting to the individual. 
> 
> 
> you have to “reply to all”
> 
> @list-admin maybe this setting could be changed? Replying to the list should 
> be the default for a mailing list 
> 
> Cheers Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging 
> <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] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

Sorry, I am continuing to have trouble properly replying to the tagging group, 
it keeps defaulting to the individual. 


> On Nov 13, 2019, at 4:48 PM, Joseph Eisenberg  
> wrote:
> 
> For a levee it can just go around the whole levee

If I understand your suggestion correctly, this is impossible. The only place 
one can “go around” is the finger of a levee that has ended where two rivers 
merge - but that is a lie too - the inside goes up the small river, and the 
outer folds and goes back upriver with it as well. There are very few places 
where inner becomes outer - because the point of the levee is to protect the 
outer from the inner. There are very few levees that end on the upstream side 
without going into terrain - still no option for the embankment to loop around. 
The levee starts in my town (sprouts out of a hill) and continues for 50KM. The 
river it meets goes for another 100km with full levee protection. They are 
giant structures. At no point does inner get a chance to become outer. 

Every stream, tributary, and minor river has levees here. Some merge with “no” 
flow control. Others merge via culverts with underground sluicegates, others 
merge via gigantic sluice gates the size of an office building. But the gates 
still give no chance for inner to become outer. the flood basins I use have 
extensive weirs and 1Km emergency spillways in the levees - still no place for 
them to u-turn. 

Having it “go around” is not really an option. 

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

(I mis-sent this email)

> On Nov 13, 2019, at 3:44 AM, Richard  wrote:
> 
> We need new tags for the bottom of embankmets, top of cuttings, bottom of 
> cliffs, earth_banks 
> and maybe a few others if we want to map them.

that is very true. 

I think we can cleanly do this with the ways you mentioned. 

We need to chose a scheme for these “base” tags that doesn’t reinvent the 
wheel, isn’t vague, and can easily be interpreted. my mis-reading of embankment 
led to some big problems, simply because I assumed the tag could document 
things it couldn’t.  Your tags look really good to me.

> On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer  
> wrote:
> A relation seems easier to evaluate and explicit, while a spatial query 
> heuristic will inevitably fail in some cases


I think there is a need for a basic relation, if I understand Martin correctly, 
to simply associate the two lines, (for example, an =embankment and an 
=embankment_base pair). When mapped, they are not joined. They are merely 
adjacent. I am not sure of what “type” of relation to choose in iD, but I 
assume someone will tell us which type to use.

When mapping a simple cutting or embankment, you would have only one “base” 
line adjacent - so there is little ambiguity, and the relationship can be 
inferred (IIUC), but in complicated tagging, there could easily be a situation 
where which base belongs to which line is unclear, and lead to problems.

Simply putting them into a relation says “these members are related” and the 
renderer can know for certain that these two ways that don’t share nodes are a 
pair, no inference needed. 

This again raises the question of levees - is the levee worthy of it’s own 
levee relation? do you put all 4 embankment lines into relation with the 
man_made=dyke line? this seems to be the only solution to:

- properly group the embankments with the levee
- not have to use super=relations (putting the embankment relations into a 
levee relation)
- providing the most flexibility to weird situations
- allowing for the extent of the top of the levee to be defined (large levees 
have varying width tops with usable areas, as shown, in which a “way” is 
insufficient ). 

But I am unsure that this is the “only way” and perhaps putting the two 
embankment relations + dyke line into a levee super-relation would allow 
mapping of the embankments to be a uniform process (making mapping the details 
of levees a bit more complicated at the expense of standardized embankment 
mapping). 


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 13, 2019, at 3:44 AM, Richard  wrote:
> 
> We need new tags for the bottom of embankmets, top of cuttings, bottom of 
> cliffs, earth_banks 
> and maybe a few others if we want to map them.

that is very true. 

I think we can cleanly do this with the ways you mentioned. 

We need to chose a scheme for these “base” tags that doesn’t reinvent the 
wheel, isn’t vague, and can easily be interpreted. my mis-reading of embankment 
led to some big problems, simply because I assumed the tag could document 
things it couldn’t.  Your tags look really good to me.

> On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer  
> wrote:
>  A relation seems easier to evaluate and explicit, while a spatial query 
> heuristic will inevitably fail in some cases


I think there is a need for a basic relation, if I understand Martin correctly, 
to simply associate the two lines, (for example, an =embankment and an 
=embankment_base pair). When mapped, they are not joined. They are merely 
adjacent. I am not sure of what “type” of relation to choose in iD, but I 
assume someone will tell us which type to use.

When mapping a simple cutting or embankment, you would have only one “base” 
line adjacent - so there is little ambiguity, and the relationship can be 
inferred (IIUC), but in complicated tagging, there could easily be a situation 
where which base belongs to which line is unclear, and lead to problems.

Simply putting them into a relation says “these members are related” and the 
renderer can know for certain that these two ways that don’t share nodes are a 
pair, no inference needed. 

This again raises the question of levees - is the levee worthy of it’s own 
levee relation? do you put all 4 embankment lines into relation with the 
man_made=dyke line? this seems to be the only solution to:

- properly group the embankments with the levee
- not have to use super=relations (putting the embankment relations into a 
levee relation)
- providing the most flexibility to weird situations
- allowing for the extent of the top of the levee to be defined (large levees 
have varying width tops with usable areas, as shown, in which a “way” is 
insufficient ). 

But I am unsure that this is the “only way” and perhaps putting the two 
embankment relations + dyke line into a levee super-relation would allow 
mapping of the embankments to be a uniform process (making mapping the details 
of levees a bit more complicated at the expense of standardized embankment 
mapping). 


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 12, 2019, at 10:26 AM, Joseph Eisenberg  > wrote:
> 
> If you are mapping an area, as in this case, just use a closed way or 
> multipolygon.

How would a closed way (area polygon) denote “top” and “Bottom”? 

if embankments can be easily expressed as a single simple polygon, how data 
users infer “top” and "bottom” from that is beyond me. 

That is the issue: I don’t understand how a polygon would represent that, and I 
think those two different pieces of mapping need to be explicitly tagged. 

Perhaps it is because while I have 3000+ edits, I rarely use relations or other 
complex mapping data structures, nor understand exactly what data consumers can 
infer from data vs what they need explicitly tagged to be useful (as I am not a 
data user) - but I assume that “top” and "Bottom” are difficult to infer, as 
slope data needs to be explicitly tagged to ways. 

I thought that the way (man_made=embankment [top]) + a polygon to represent the 
bank (area:man_made=embankment) would, together, represent the top and the area 
of the embankment, allowing inference of the direction of the slope. Perhaps an 
additional line for “bottom” would be necessary too. 

Two embankments would represent the slopes of the levee, while the 
man_made=dyke way would represent the path of the protection structure as a 
whole, as the embankments (particularly the outer one) are not continuous - but 
the levee (as a complete structure) is continuous. 


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer  
> wrote:
> 
> I agree we should have a way to map both limits, upper and lower, for all 
> kind of similar features, e.g. embankments, slopes, and similar.


> On Nov 11, 2019, at 7:40 PM, Volker Schmidt  wrote:
> 
> I have stood in front of these large levees that prevent big rivers from 
> flooding the surrounding country side many times her in Italy and did not 
> find a suitable tagging for both the top and the bottom border lines of the 
> object.



I think it is pretty easy to make a  “lower bounds” way or area (or both) that 
compliments the existing man_made=embankment way.  

To me, the problem is levees. After having mapped many KM of levees 
(incorrectly), it is really really nice having the two pairs of embankments 
make up the two halves of the levee, because it is easier and more flexible to 
map the two slopes (which widen and narrow, split & merge, and disappear for 
short sections), rather than trying to assume that the man_made=dyke centerline 
way accurately shows the the “top” of the levee. the top varies by width from 
something easily represented by way to something 50m wide in some places (as 
linked to earlier). The =dyke way should represent the inner-most extent of the 
high point of the levee (if it has a weird bulge in the top). 

I made 2 sections of mapping examples on a simple section of levee along the 
Tone River that has a levee breach repair station on top, so the levee is wider 
here than normal. (for a short time).  


a man_made=dyke (on the cycle path) with:


- two pairs of embankment lines   ( man_made=embankment + 
man_made=embankment_lower ) with a regular grass polygon sandwiched between it.


- Two regular embankment lines along the top with an area:man_made=embankment 
polygon representing the slope (also tagged with grass). 

https://www.openstreetmap.org/edit#map=17/35.9/139.89482 
 


Do you need a relation on them? 

Any suggestions on improvements? 

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 11, 2019, at 12:52 PM, Joseph Eisenberg  
> wrote:
> 
> We use two tags for rivers: `waterway=riverbank` (or natural=water +
> water=river) for the area and waterway=river for the central line of
> the river.



Thanks so much for all of the clear and thoughtful replies. 

I sometimes mess up tagging schemes or tag names during discussions, and it 
leads to confusion, but this was a total misunderstanding of embankments. 

It seems I was (very) confused, possibly by misreading it several different 
times. I have mapped 40km of levees wrong, with an improper lower bounds line. 
I’ll have to fix it. 

I now understand that my embankment lines at the top are the (only) proper way 
to map the edge of the embankment.

I am interested in mapping the extent of the levee/embankments with some kind 
of outer/lower line, either as a single area or as 2 related ways for a levee. 

it is interesting to me that a levee is a way that marks the “centerline", 
while the embankment maps the top edge of the slope - yet there is no 
documented way to map the *area* of the levees nor embankments. my “lower” 
embankment line (which is apparently very bad mapping) makes the extent of the 
embankments that make up a levee. while they sound simple, our levees are 
*covered with* parallel and intersecting roads. some levees will have 5 
parallel ways on them for different kinds of traffic. similar to 
man_made=bridge, showing the area used by a bridge is very useful. 

to me, both man_made=embankment and man_made=dyke need a way to express the 
area they take up, because mapping via a width value varies too much to be 
mappable, especially when they are in very complicated shapes - and very easily 
mapped via imagery.

to me, these levees are not only a major feature worth mapping, but 
considerably helpful to understand the mapping in an area. They are very large 
artificial barriers which greatly restrict access, as well as one of the few 
safe places during a typhoon.

I will think about how area:man_made=embankment & area:man_made:levee would be 
useful compliments to the existing tagging without requiring any changes to the 
existing tags.

There is a big discussion on the tag discussion page ( 
https://wiki.openstreetmap.org/wiki/Talk:Tag:man_made%3Dembankment ) about 
mapping embankments by area using the existing man_made=embankment on a closed 
way (only generating an area when paired with area=yes), but in that case there 
is no way to tell which side of the area is the “top” of the embankment, which 
is the intended data the line is meant to represent.


Your comments have been extremely useful/helpful, thanks. 

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 11, 2019, at 11:16 AM, Joseph Eisenberg  
> wrote:
> 
> "it should be tagged on a way drawn with the lower side on right side
> of way direction" - Tag:man_made=embankment

for some reason, I remember reading documentation about using a pair of 
embankment lines to denote the extent of the embankment, using the direction of 
their ways as an indicator. I didn’t come up with that on my own. this was 
during the embankment=yes => man_made=embankment change. 

 - I really love the top-lines of the embankments, as these embankment tops are 
not uniform in shape - but I will delete them if it is bad tagging. 

- if I delete the “top” lines of the embankments, and use the man_made=dyke as 
the center of the summit of the levee, would there be some advantage to putting 
it and the embankments into a relation for possible better rendering of their 
extent (shading, hashes, etc)?.

- Because the levees vary wildly in shape on the top, sometimes widening for a 
short area to 50-100m wide, would repurposing the top-line embankment ways as 
mapped to tagged with some kind-of “riverbank-style” tag, where the 
man_made=dyke way shows the path, and man_made=dyke on a polygon shows the 
extent, similar to how natural=river is used now? for smaller levees, this 
detail is unnecessary, but for such large features used by so many people, the 
detail would be nice. it is very easy to map their extents, especially since I 
am doing the mapping via ground survey on a bike 70-100km at a time.

examples of the levee top widening for a short space, usually for levee break 
emergency repair stations (large caches of breakwater blocks with 
helicopter/crane hooks, stationed above the flood zone on top of the levee). 

https://www.openstreetmap.org/#map=18/36.30063/139.51192 

https://www.openstreetmap.org/#map=18/36.26097/139.63921 

https://www.openstreetmap.org/#map=17/35.97705/139.89813 


I really want to map the levees in as much detail as I can, as detail often 
helps with map interpretation (at high zoom levels) while travelling along the 
levees by car or bike, but few people seem to be interested in them. 


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

Re: [Tagging] tagging extremely large flood control features.

[John Willis via Tagging]

the government released photos of the water control features I’ve mentioned 
being filled by the recent typhoon. The “flooding” pictured is by design, 
controlled by short inner and large, tall outer levees. 

This should give people a better idea of the scale of the water features I am 
talking about. 

it also gives you an idea of how much stuff that is regularly used is (rarely) 
flooded in these events. it is very irregular. 

~ What it looks like normally, 360+ days a year. the brighter yellow reed grass 
shows the extent of the basins:

http://www.ktr.mlit.go.jp/ktr_content/content/000708028.pdf 



~ 2 years ago, when the rivers and canals filled, but the larger basins were 
not really used:

http://www.ktr.mlit.go.jp/ktr_content/content/000708025.pdf 



~The recent typhoon that completely filled the basins & rivers to become one 
giant lake (as designed) controlled by the outer levees:

http://www.ktr.mlit.go.jp/ktr_content/content/000759027.pdf 



~ Where this river meets the larger river just below (Watarase meets Tone). 
This flood control system is merely meant to delay a surge into this larger 
river. 
Localized flooding (rain that can’t drain away) can be seen as clear shiny 
water in the adjacent fields and villages. it is 1-2m deep. The river is ~9m 
higher than normal.

http://www.ktr.mlit.go.jp/ktr_content/content/000759029.pdf 



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

Re: [Tagging] Service road - Can it be a driveway if serving multiple houses?

[John Sturdy]

I think of a driveway as typically leading to only one house, and would
generally call the shared ones something else, probably "service roads".
I'd make an exception for the access to a pair of houses e.g.
semi-detached, or adjacent but linked by their garages/carports.

__John

On Tue, Nov 5, 2019 at 2:26 PM Philip Barnes  wrote:

> Sections of shared, non-public service road, are certainly a common
> feature of modern housing developments.
>
> I have considered them to be private driveways.
>
> Private does not require a sign, walk down any suburban street in Europe
> or North America and you will see hundreds of driveways, without signs or
> gates and nobody will assume there is a public right of way there.
>
> Phil (trigpoint)
>
> On Tuesday, 5 November 2019, Jez Nicholson wrote:
> > Personally, I would only call the short bits of tarmac that spur off that
> > service road as 'driveways' because they each go to a single house. I'm
> > sure that there are examples of shared driveways in the UK but I would
> > consider them rare.
> >
> > On Tue, Nov 5, 2019 at 1:52 PM Dave F via Tagging <
> tagging@openstreetmap.org>
> > wrote:
> >
> > > Hi
> > >
> > > In the UK, Amazon Logistics are adding useful data from their GPS'd
> > > delivery vehicles. Mainly highway=service as the last part of their
> > > journey to a destination.
> > >
> > > However, one of their contributors removed service=driveway from a
> > > highway=service road. In the changeset comments they said it was
> because
> > > it served multiple residential properties.
> > >
> > >
> https://www.openstreetmap.org/changeset/76576604#map=19/51.33398/-2.27945
> > >
> > >  From memory, it wasn't signed as private, but it appears to be
> > > unadopted by the local authority (There are no raised kerbed pavements,
> > > drainage or lighting). I'm assuming it's shared ownership.
> > >
> > > For indicative purposes only. (The image is ten years old):
> > >
> > >
> https://www.google.co.uk/maps/@51.3343975,-2.278377,3a,60y,185.39h,67.19t/data=!3m6!1e1!3m4!1s5I6ruGYQsgQv4cC0iLM6SA!2e0!7i13312!8i6656
> > >
> > > Personally I see no problem tagging this as a driveway even if it's
> shared.
> > >
> > > Thoughts?
> > >
> > > DaveF
> > >
> > > ___
> > > Tagging mailing list
> > > Tagging@openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/tagging
> > >
> >
>
> --
> Sent from my Sailfish device
> ___
> 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] tagging extremely large flood control features.

[John Willis via Tagging]

> On Oct 26, 2019, at 6:01 AM, marc marc  wrote:
>> 
>> Man_made=flood_mitigation_basin sounds good.
> 
> that look like 2 infos into one key :s
> 
> man_made=basin usage=flood_mitigation ?

Yes, my bad. I think that is a good solution for the basin. 

One big question. Something has been bothering me about the basin: 

So far, we have been discussing discrete structures that are contained. They 
have an inlet weir or spillway, and have an exit drain or giant sluice gate 
Leading to the drain of the system (usually back to the river). A basin seems 
like a good label for this structure.

I am unfamiliar with other countries, but Japan makes extensive use of land 
inside the river levees. The levees are often spaced 20-100m away from an 
internal embankment, which is the normal "riverbank",  where normal storms are 
contained. 1-3m Above this embankment are heavily used sports grounds, parks, 
golf courses driving school grounds, and other very well-maintained facilities 
that are expected To be underwater during a floo-event. No buildings or 
structures are allowed. 

Similar to these basins, the extent of the flooding is known (inside the 
levees) and is otherwise normally usable grounds 360+ days a year. 

Is the long channel formed by the levees, but almost never used except during 
flooding also some version of this? Is mapping the extent of the levee flooding 
already Mappable? If that is the case, then these currently discussed basins 
are *inside* the levee protection system (a large bulge with a narrow 
bottleneck at the spillway connecting it to the river levee - yet "part" of the 
raging river during flooding, just like the Riverside land. 

Would it be better to have a tag that is able to handle this "inside the levee" 
area, or just map the basins as separate objects? Would having a feature like 
"floodbank" be useful? 

Would it cover from levee to levee, or be two separate things, one for each 
side of the river, mapping the space between the levee and the riverbank? Would 
it simply be a way and put in a relation with the waterway that causes it? 


 To a farmer or a baseball player, whether your baseball daimond is along the 
river or in one of the basins makes little difference when a storm is large 
enough to fill the river. 

Javbw. 

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

Re: [Tagging] tagging extremely large flood control features.

[John Willis via Tagging]

> On Oct 25, 2019, at 10:53 AM, Joseph Eisenberg  
> wrote:
> 
> The value should have something that suggests that it will be flooded.
> I would think of "flood_mitigation" as something like a levee or dyke
> which prevents flooding, rather than an area that is supposem to be
> flooded.
> 
> So... maybe man_made=flood_basin and natural=flood_basin?

Man_made=flood_mitigation_basin sounds good. 

> 
> Or something like flood_zone,flood_area, etc?

This is for an area that floods, for whatever reason, but doesn't map the 
feature of the basin. 

Javbw




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

Re: [Tagging] tagging extremely large flood control features.

[John Willis via Tagging]

> On Oct 24, 2019, at 10:22 PM, Joseph Eisenberg  
> wrote:
> 
> rendering for areas that are "subject to inundation".

That is a good idea. 

I think if you have a large area(unrelated to tides) that sometimes floods 
during extreme weather, mapping it as an area would be a good idea. 

I wonder if that would also be useful for these dedicated and planned Control 
basins, which are 100% contained by levees and managed by spillways, as the 
frequency of the flooding is rare, but the extent is pre-determined. they 
purposefully don't allow houses or (private) structures to be built in them - 
only grass fields & and farmland. 

Javbw. 

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

Re: [Tagging] tagging extremely large flood control features.

[John Willis via Tagging]

I am aware of the underground basins that are dedicated to the task, but I am 
wondering how to map above-ground basins that are used as regular land 360+ 
days of the year - something you don't have to deal with when mapping the 
underground tanks.  

~


The rest is not important, but read on if you Want. 


Yea, Thats in Tokyo on the Arakawa/Edo rivers, the the Tokyo metro area. The 
start of the Edo river is a lock-controlled flow from the Tone - as the larger 
Tone goes off to the Pacific 70 Km north of Tokyo (it doesn't discharge into 
Tokyo Bay). 

As I understand it, those tanks manage the water going into the system in Tokyo 
itself, absorbing the flow from the smaller channels/rivers in Tokyo (Tokyo is 
big and flat) and buffering it before it gets discharged into the rivers, 
absorbing what would normally be trapped behind the River levees. The Tokyo 
tank system couldn't handle the river flow directly (it's immense) - The rivers 
channeling water down through the region just use extra-wide and tall 8-10m 
levees to provide ~ 10-15x normal flow volume to the sea. (The river goes from 
1-2m deep to 8-9m deep, and doubles in width) 

Small towns in my area (pictured) were flooded not by a levee breach, but by 
water trapped outside the levee that couldn't get into the river through the 
normal gates.  

The Tokyo system prevents that from happening - though I wonder if it could 
absorb even a quarter of what the Usuichi trapped. The Usuichi is gigantic. 

Javbw

> On Oct 24, 2019, at 9:08 PM, Paul Allen  wrote:
> 
> 
>> On Thu, 24 Oct 2019 at 10:56, John Willis via Tagging 
>>  wrote:
>> 
> 
>> Inside, there are three “retarding basins”  (numbered 1, 2 & 3), with #1 
>> having with a large traditional reservoir, parks, golf course, and sports 
>> grounds inside.  
> 
> There is more to the system than that.  There are also underground holding 
> tanks and
> tunnels: https://www.youtube.com/watch?v=cfJOW2PtrGk
> 
> -- 
> Paul
> 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] tagging extremely large flood control features.

[John Willis via Tagging]

With the recent typhoon in Japan, I was able to see the giant river flood 
control systems used for the first time (since I moved here in 2011). they are 
the size of cities, covering many sq KM. 

There are some photos here, showing a cycling trip I took downriver to see how 
it works.
 https://imgur.com/gallery/9uYHFmt 

a few show the Watarase Usuichi.  https://www.openstreetmap.org/way/482421468 
 

Inside, there are three “retarding basins”  (numbered 1, 2 & 3), with #1 having 
with a large traditional reservoir, parks, golf course, and sports grounds 
inside.  

As the rivers get higher, they flow into the basins via ~6m spillways upriver. 
eventually basins and the rivers fill up,
and the three flood control basins & the rivers merge together to form one 
giant lake (controlled and planned), controlled by 10M levees around the entire 
complex. Exit gates let the water back out into the river in a controlled rate 
to prevent flooding. But during the recent giant typhoon, it filled the system 
and flowed out of the emergency overflow spillway (~8M), seen in the background 
of this picture (the white line) https://i.imgur.com/z1QfYAW.jpg 
 

The entire system worked as planned. 

These features are almost 100% man-made (levees, gates, spillways), that create 
large artificial lakes for very short periods  very infrequently. 

The building seen in the “lake” here https://i.imgur.com/CDU5KfE.jpg 
 is this building. It is designed to be ~1m 
above the flood waters, as it is in the picture. 

https://www.openstreetmap.org/way/537590387#map=16/36.2037/139.6850 


This complex is rarely used, perhaps once or twice every 5 years, and otherwise 
the area is many many square KM of golf courses, parks, sports fields, nature 
preserves and farmland used by people every day. 

mapping the area as an “intermittant reservoir” seems wrong, as they are merely 
for extreme typhoon floodwater management, and the rest of the time is is 
useful area for people to use. They are not “flood prone” (as I understand it), 
as they are *designed* to flood, and flooded in a controlled manner.

While mapping further downriver, I found a “smaller" flood control area. a 
giant spillway 200m across lets the river into this huge area (mostly rice 
fields), and control gates at the bottom of the area slowly let it back out. 

This area is confined on all sides with ~10M levees (and a few natural hills). 

https://www.openstreetmap.org/way/738164911#map=14/35.9038/139.9991 


(I quickly drew this way, but I will delete it). 

How should I go about tagging these kinds of huge areas - an area that is a 
controlled flood reservoir, used only during extreme weather? 


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

Re: [Tagging] How to tag pedestrian lanes?

[John Willis via Tagging]

> On Oct 22, 2019, at 2:18 AM, Jan Michel  wrote:
> 
> foot:lanes = ||designated (allowing foot access to this lane)

Thanks for the tagging example! ^__^
 have never tagged lanes before. 

Is "foot:lanes" An established value? 
Or is that what we are discussing?  

Javbw 

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

Re: [Tagging] Amenity=Gambling & adult_gaming_center tagging conflict

[John Willis via Tagging]

> On Oct 22, 2019, at 3:11 AM, Shawn K. Quinn  wrote:
> 
> leisure=amusement_arcade ?

This is between =gambling and =adult_gaming_center, two established tags that 
both claim to be the proper way to map a Pachinko parlor. A Pachinko machine is 
a type of "gaming machine" in the gambling sense, like a slot machine. It is 
not an arcade game, like pac-man, though it uses steel balls like pinball. 
Pachinko is a luck-based machine, not skil-based like pac-man or pinball.

Arcades are full of skill games (for the most part), and full of kids and teens 
playing Street Fighter, Galaga, claw machines, and such. 

Pachinko Parlors are full of grandpas gambling away their afternoons the nickel 
machines (5yen Pachinko or slot machines). 

Javbw

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

Re: [Tagging] How to tag pedestrian lanes?

[John Willis via Tagging]

> On Oct 21, 2019, at 3:40 PM, Mateusz Konieczny  
> wrote:
> 
> There is no kerb or other barrier at all, but still it's obviously a sidewalk.

I agree with you that this is is a sidewalk. 

I spoke too quickly when I said that all sidewalks have kerbs. There is clear 
delineation that there is a separate, yet adjacent way for people, even though 
there is no kerb. Sidewalks always have some kind of physical barrier (a raised 
kerb or a kerb barrier), a materials change, or **some physical 
representation** that it is "not part of the road".

Lanes always imply that you are "part of the road". That you are "in the road". 
A cycle path and a cycle lane are very distinct, in all their forms, and this 
is the difference. 

We can all imagine a bus lane, a turn lane, a cycle lane, and whatever a 
"pedestrian lane" might be in the road. It's part of the road. It's marked with 
a (painted) line to separate one from the other. The lane feels like part of 
the road. The green lanes I deal with in Japan are clearly part of the road. I 
don't know how to map them as a lane, but it is clearly a lane, and not a 
sidewalk. 

Good luck with working this out. 

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

Re: [Tagging] How to tag pedestrian lanes?

[John Willis via Tagging]

> On Oct 21, 2019, at 2:08 AM, Markus  wrote:
> 
>  * It doesn't make sense: if it doesn't have a kerb (or any other
> physical barrier) it isn't a sidewalk.

This is the most important information. 

it should be tagged as a “footway lane” or “pedestrian lane” or similar. 


Javbw

a "sidewalk lane” implies a regular kerb separated sidewalk. ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag pedestrian lanes?

[John Willis via Tagging]

> On Oct 20, 2019, at 4:44 AM, Markus  wrote:
> 
> However i think that a sidewalk requires a physical separation to the
> roadway


I agree with you, and I tag all separated standard sidewalks as “sidewalks” (iD 
preset).

however, there are a lot of narrow roads in Japan where the side of the road 
(between the white lane border line and the barrier wall along the road) is 
painted with a (thin) green stripe, and is considered a pedestrian path - 
usually around schools where children walk. The infrastructure in the area is 
very old, and they cannot widen the roads to be safer, so they paint the green 
line on to remind drivers to be safe and keep the pedestrians on one side. this 
is only around schools with narrow roads. New roads all have separated 
sidewalks, so no painted area is necessary. 

I tag the green line as a highway=path and add a note=* to the way. 

One example I have seen is much larger, and is a new “lane” created by 
converting a 2-way road to 1-way and giving the margin to pedestrians. 
https://www.openstreetmap.org/way/667338935 
.

I do not think this is ideal, but it does properly map the marking and the 
routing that should be used for pedestrians. usually many roads in the area are 
narrow, and the designated way is best. 

If some method is standardized, I will correct my mapping. 

Note: these are not the blue cycle-lanes or cycle arrows in the road found on 
many narrow high traffic roads. 


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

Re: [Tagging] Amenity=Gambling & adult_gaming_center tagging conflict

[John Willis via Tagging]

Javbw

> On Oct 17, 2019, at 5:45 PM, Martin Koppenhoefer  
> wrote:
> 
> I am not personally familiar with pachinko,

It is a machine that is a slot machine crossed with a pinball machine. It is a 
luck-based machine. 

A Pachinko parlor (often Pachinko, as both machines are present) is a 
building with several rows of these machines, with stools for sitting and loud 
obnoxious music blaring. There are many different types and themes of machines 
(think video arcade machines), but the "currency" is the steel balls used in 
play. You win them and trade them for prizes or something of value.

Only recently (AFAIK) Has Japan approved something like a Las Vegas casino to 
be built. But large chain parlors cover the countryside, covered with lights. 
They are often the brightest thing in the countryside at night. They are as 
common as DIY shops or strip malls. Within 2km of my house, there are 2 and 2 
more dead ones. They are inside malls and along rural roads. 

"adult gaming center" seems appropriate -there are no card or table games, like 
a casino, nor sports betting. Using gambling=* to define the game types 
available sounds good - but both of these things needs to be properly 
documented in the wiki. 

Javbw 



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

[Tagging] Amenity=Gambling & adult_gaming_center tagging conflict

[John Willis via Tagging]

While Tagging Pachinko parlors in Japan, I came across a wiki documentation 
conflict. 

2 different tags say that they are the proper ones to use when tagging pachinko 
parlors:


Amenity=gambling wiki page says:

> A place for gambling, not being a bookmaker, lottery shop, casino, or adult 
> gaming centre.  Games that are covered by this definition include bingo and 
> pachinko.

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dgambling 




Amenity=adult_gaming_centre says:

> This tag is used for venues with gambling machines, such as slot machines.

> Examples: • Pachinko Parlors (Japan)


https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dadult_gaming_centre 



Can someone who knows better clean up this mess? 

IMO, a bingo hall and Pachinko parlor are totally different. “Adult Gaming 
Center” seems to be the correct tag.
A Pachinko machine is basically a slot machine. But Amenity=gambling might be 
the de-facto in-use tag already. I don’t know.  


Also, how do you specify which games are offered? gambling=pachinko is in the 
wiki, but what about adult_gaming_centre? is gambling=* the default way to 
define what games are offered at such facilities? that seems to be vague or 
missing. 

gambling=pachinko has 560 uses (all in Japan) 
https://taginfo.openstreetmap.org/tags/gambling=pachinko#overview 


there are several times more pachinko parlors in Japan, but many have been 
mapped with this tag. 


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

Re: [Tagging] Cycling relation misuse

[John Willis via Tagging]

> On Oct 14, 2019, at 4:31 PM, Peter Elderson  wrote:
> 
> I imagine mtb maps showing all kinds of mtb-trails except The Big One that 
> everybody knows. If I were an MTB'ist, I would probably disxcard OSM as 
> unusable, because it doesn't even give the biggest MTB-route on the planet!

To be clear, this is a grey area that the original post was not discussing.  

If a route is "famous", even if it is unsigned, then I think it deserves being 
in OSM. That "famous" bit crosses into "local knowledge". The route has a name 
everyone knows and uses. It isn't a nameless trace someone mapped for their 
personal use. 

The routes I map are official routes made up mostly of cycleways, with various 
crossings and detours where the cycleways cannot be constructed. The official 
route switches from cycleways on one side of the river to the other to avoid 
upcoming obstacles - the rider is asked to detour onto roads, sidewalks, 
pedestrian crossings, and other ways that are not dedicated cycleways - 
"detours" that are mapped (and usually signed) as the official route.

This collection of ways - cycleways, sidewalks, marked ped crosswalks, unmarked 
cycleway crossings, and roads make up the larger route. 

I am more forgiving of the idea of marking MTB trails Because MTB routes are 
often the only trails through an area passable to bicycles. They probably 
include a lot of double-track "tracks" as well.

But Cycling routes through a city or region for commuting/transportation are 
often chosen because they are designated from the myriad of roads and ways that 
one *could* cycle on, but this route was selected just for them because of 
affordances (dedicated ways, cycle Lanes, curb cuts, etc). Mapping every loop 
route you enjoy cycling for excersize in the mountains is treated as one of 
these transportation routes - deceiving users into thinking there is a route 
that is good for cyclists trying to cross the mountains,  when it is actually a 
Narrow two lane trunk road with no shoulder and no sidewalk - and loops Back to 
where you started. They are not cyclways for transportation. 

I don't want regular cycle routes used for transportation confused with random 
routes made by hobbyists for their weekend training. The MTB route discussed 
sounds like it should at least be be considered in OSM as an MTB route - but 
that is for route=MTB people to discuss. 

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

Re: [Tagging] Cycling relation misuse

[John Willis via Tagging]

On Oct 12, 2019, at 5:10 PM, Richard Fairhurst  wrote:

A new route_type= tag on the relation would be a
good way to go.

Route=
cycle_touring
road_touring
cyclist
road_cyclist
road_cycling

 ?

I think the word “race” should be left out, unless it is for mapping actual 
racing routes. 

Javbw


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

Re: [Tagging] Cycling relation misuse

[John Willis via Tagging]

> On Oct 12, 2019, at 1:28 AM, Phyks  wrote:
> 
> Hi,
> 
> I've found similar issues in France recently. Cycling routes is too
> broad and diverse and covers various realities. From a rendering
> perspective (disclaimer: I'm one of the maintainer of the new CyclOSM
> rendering style, https://cyclosm.org ), it is very 
> often a nightmare to
> try to figure out which one are worth rendering and which ones are just
> "tag to render".


Similar to how bus routes are laid over existing road infrastructure, I think 
there should be a big distinction between the paths/crossings/roads that are 
assembled to make a cycling “road", and some route that people have come up 
with just for exercising that is just some generic road in rural area people go 
touring on. 

- Cycling roads/routes for travel/transportation with some kind of documented 
status with the government. 

- MTB routes, usually using off-road ways & infrastructure - documented by the 
maintainer of the route, whoever that is.

- roads used by cyclists for exercise/racing, with no documentation or signage 
- usually shared via online route-sharing sites.

if you are making a map of the cycling routes available, I would assume the 
first category is the most important, and possibly the only one that should be 
prominently rendered.

similar to how we render roads, the prominence of motorways pales to the 
prominence of lesser roads.  Please include them, but we would need tagging to 
show the purpose of the route, beyond “network” or what super-relation they 
belong to. 

This might be difficult, as the usage probably vary from region to region: MTB 
routes in Japan are negligible, and dedicated cycling roads abound. Whereas in 
San Deigo, there are zero “cycling roads” that are maintained by the 
government, and probably a lot of documented MTB routes in the wilderness parks.

but documenting & rendering any route that a cycle club enjoys cycling on the 
weekend? unneeded. a motorcycle club’s favorite route in the mountains is 
unworthy of a route relation as well.  

OSM is not an online route-sharing site. 

here is a “Nikko Loop” route made by some cyclist who enjoys cycling. 

https://ridewithgps.com/routes/31059198

This is the job of this other private website (ridewithgps.com 
) - document and share routes for cyclist users. But 
Nikko City has no documentation for such a route, and shouldn’t be included in 
OSM. 


Javbw

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

Re: [Tagging] Cycling relation misuse

[John Willis via Tagging]

> On Oct 11, 2019, at 8:52 PM, Mateusz Konieczny  
> wrote:
> 
> Can anyone make a route relation for any Way regardless if it is actually a 
> designated oute by a city, signed, or publically documented?
> Such tagging for rendering happens
> but is incorrect and should be deleted.

This is what my gut told me. I’ll be careful as I go through them in the next 
few months. I research the designated routes by actually cycling them and 
looking up the governmental maps of their routes. so many of them incomplete.

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

Re: [Tagging] Cycling relation misuse

[John Willis via Tagging]

Am I misunderstanding something fundamental?  Mapping cycle route relations 
Sounds a lot like mapping bus routes: mapping the designated routes of existing 
public/private routes seems to be useful - mapping where you like to drive your 
RV around With a bus route relation and inter-mixing that into official bus 
route relations sounds like a disaster. 

I was under the impression cycle route relations (especially with a network=* 
designation) were for mapping designated cycleway routes - not mapping wherever 
bicycle=yes is implicit or implied, or whatever route I happen to enjoy riding 
on weekends.

Of course The the relation can include any way - it might include cycle Lanes 
in large roads or segments of roads used to link cycling roads together - but 
just any random road your cycling club likes to ride on the weekend? A route 
that is 100% trunk road from end-to-end with 0% cycling lanes or paths and no 
official designation as a route for cyclists? Is that part of a "cycling route 
network?" Is my favorite Canoeing path around a lake ferry route relation? 

It reeks of polluting the actual designated cycling routes (which are not even 
half-finished in my area, relation-wise) with relations of random roads which 
are just regular roads, with no designation for cyclists. It's like if I 
designated my daily commute a "cycle route relation, network=local" just so I 
can get a bright blue line in OpenCycleMap, rather than creating/downloading a 
route in my cycling app on my phone for my own private use - mapping for the 
renderer IMO. 

Is there something Im not understanding? Can anyone make a route relation for 
any Way regardless if it is actually a designated oute by a city, signed, or 
publically documented?

Javbw

> On Oct 11, 2019, at 5:58 PM, Warin <61sundow...@gmail.com> wrote:
> 
> On 11/10/19 18:04, John Willis via Tagging wrote:
>> Questions about using cycle relations properly:
>> 
>> I am mapping and repairing cycle roads in the Kanto/Tokyo area. There are a 
>> lot of designated cycling roads that follow a long rivers and other water 
>> features out into the countryside, making up a regional system, and a lot of 
>> smaller local cycling roads (also along small rivers) that connect 
>> neighborhoods and towns together.
>> example: https://www.openstreetmap.org/relation/3218181
>> 
>> I’m working to get all the individual ways of the cycle roads into relations 
>> and to properly classify these (local/regional, etc).
>> 
>> But on the cycling layer of OSM, I find regular roads labeled as cycle 
>> routes: mountain roads where professional cyclists like to exercise labeled 
>> as a “cycling route”, which seems like “mapping for the renderer”.
>> 
>> example: https://www.openstreetmap.org/relation/8066243
>> 
>> - They don’t seem to be cycling roads - all the relation members are trunk 
>> roads or similar - no cycleways whatsoever.
> 
> There is no requirement for a cycle route to use cycleways, even in part.
>> 
>> -they are dangerous routes with no side-paths, sidewalks, or dedicated cycle 
>> lanes - just regular roads.
>> 
>> - they are exercise loops or hill climbs for pro cyclistsand serve no 
>> purpose for travelers or commuters.
> 
> Never the less they could be seen as cycle routes - frequently used by 
> cyclists?
> 
>> 
>> - they are not, AFAIK, part of an official “cycling network”. The 
>> Super-relation someone has added all cycle routes to ( 関東地方サイクリングロード・ネットワーク 
>> ). https://www.openstreetmap.org/relation/8051094 also seems to be made-up 
>> and not official either - the name only returns one result (the OSM data 
>> page) when searched.
>> 
>> 
>> 
>> To me, these non-cycle routes are just garbage relations meant to have the 
>> route show up on the cycling view of OSM for people doing workouts.
> 
> I have had a commuting cyclist map into OSM cycling lanes .. that are not 
> there, shared paths that are not shared.. I would much rather that were 
> mapped as routes showing the actual infrastructure that is there.
> 
>> 
>> I want to delete these fake “mountain workout” relations that should be 
>> mapped in strava or a similar workout app.
> 
> If the route shows that regular roads are used .. possibly use the 
> description key to state the nature of the route?
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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