Re: [Tagging] OHV greater than 50 inches (wide)

2020-09-01 Thread 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


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

2020-05-25 Thread 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

2020-05-24 Thread 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

2020-05-24 Thread 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

2020-05-23 Thread 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

2020-05-01 Thread 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

2020-05-01 Thread 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

2020-04-23 Thread 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

2020-04-21 Thread 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

2020-04-15 Thread 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.

2020-04-14 Thread 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.

2020-04-14 Thread 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?

2020-03-14 Thread 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] Annual Shows

2020-02-28 Thread 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

2020-02-28 Thread 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

2020-02-27 Thread 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 small areas of bushes, flowers, non-woody perennials, succulents, etc

2020-02-09 Thread 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

2020-02-09 Thread 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

2020-02-05 Thread 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

2020-02-05 Thread 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

2020-02-03 Thread 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

2020-02-03 Thread 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

2020-02-02 Thread 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

2020-02-02 Thread 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

2020-02-02 Thread 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

2020-02-02 Thread 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

2020-01-30 Thread 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

2020-01-30 Thread 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

2020-01-26 Thread 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

2020-01-26 Thread 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

2020-01-21 Thread 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

2020-01-20 Thread 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

2020-01-16 Thread 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

2020-01-15 Thread 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

2020-01-13 Thread 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

2020-01-13 Thread 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

2020-01-09 Thread 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

2020-01-08 Thread 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

2020-01-08 Thread 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

2020-01-05 Thread 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?

2019-12-28 Thread 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"

2019-12-25 Thread 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

2019-12-13 Thread 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

2019-12-12 Thread 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

2019-12-11 Thread 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


[Tagging] Long term detour routes ?(construction, disaster)

2019-11-23 Thread 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

2019-11-20 Thread 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

2019-11-20 Thread 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

2019-11-19 Thread 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

2019-11-18 Thread 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

2019-11-18 Thread 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

2019-11-17 Thread 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

2019-11-17 Thread 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

2019-11-17 Thread 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

2019-11-16 Thread 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

2019-11-16 Thread 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

2019-11-14 Thread 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

2019-11-13 Thread 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

2019-11-13 Thread 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

2019-11-12 Thread 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

2019-11-11 Thread 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

2019-11-11 Thread 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

2019-11-10 Thread 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

2019-11-10 Thread 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


[Tagging] Additional detail of Levee mapping via embankments

2019-11-10 Thread John Willis via Tagging
As related to my other posts, I am mapping large water containment features.

When I began mapping, I often mapped embankments & retaining walls used for 
roads and infrastructure, and during that time, the embankment tag evolved to 
support two embankment lines that would denote the top and bottom of the extent 
of the embankments. This was perfect for me, as there are many tollways that 
sit on a large man-made embankments as they cut trough the countryside. Most 
tollways in Japan are elevated on fill to make crossings (via tunnels) much 
easier, as they cross so many existing small roads. mapping the extent of the 
embankments clearly shows the footprint of the tollways through the countryside 
- much greater than any trunk road. 

https://www.openstreetmap.org/#map=17/36.33635/139.40197 
 - Kita-Kanto 
expressway near Ota-Kiryu IC & Watarase River


As I mapped the embankments, I started mapping the levee embankments as well, 
as they are not uniform in shape, with natural and man-made features making 
their shape highly irregular on both the top and bottom, the two sets of 
embankments easily outlining these huge features (usually between 6-12m tall 
and 20-60m wide). They usually have a 2-10m wide “top” on the levee. They 
similarly have a huge footprint compared to other features. 

Recently, I realized there is a man_made=dyke tag that is supposed to map the 
“top” of the levee, but there is no documented way to map the *extent* of these 
large flood control features, which feels incorrect.

https://www.openstreetmap.org/#map=17/36.23909/139.68483 
 - the extent of 
these levees is much greater than the cycling roads on top. 

I am going to continue to map the extent of these large man-made levee 
embankments as 2 pairs of embankment lines, and I'll now go back and map the 
levee top with a man_made=dyke line, denoting the “levee route”. I’m guessing 
there are 500km of these large levees in the greater Tokyo area alone, with 
more than a thousand km of somewhat smaller ones. 

The levees follow the river through open plains, but their route often is 
constrained occasionally by natural features, where the outer-side of the levee 
is a natural rise for a short distance, but the inner-side is still a 
continuous man-made embankment. being able to separate the almost always 
continuous levee from the extent of it’s two embankments (which merge, 
separate, appear, and disappear) is very useful. 

https://www.openstreetmap.org/#map=17/36.23164/139.31544 
 - levees meet and 
end as one river joins another. Their size varies greatly, denoted by the 
embankment lines. 

I feel this should be accepted mapping for extremely large levees, such as the 
ones I am dealing with, where the =dyke way cannot properly express the extent 
of the levee’s breadth and complexity, and the “Top” of the levee is not always 
the center of the structure. 

Is it useful to turn this into a relation? with levee embankment members being 
inner-bottom, inner-top, outer-bottom, outer-top and the man_made=dyke member  
being the “route" of the levee? Maybe it isn’t important to relate them. I 
don’t know.

Thoughts? 

Javbw 

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


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

2019-11-06 Thread 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] tagging extremely large flood control features.

2019-10-27 Thread 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.

2019-10-25 Thread 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.

2019-10-24 Thread 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.

2019-10-24 Thread 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.

2019-10-24 Thread 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?

2019-10-21 Thread 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

2019-10-21 Thread 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?

2019-10-21 Thread 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?

2019-10-20 Thread 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?

2019-10-20 Thread 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

2019-10-17 Thread 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

2019-10-16 Thread 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

2019-10-14 Thread 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

2019-10-12 Thread 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

2019-10-11 Thread 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

2019-10-11 Thread 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

2019-10-11 Thread 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


Re: [Tagging] railway crossings with cycleways

2019-10-11 Thread John Willis via Tagging
I think it depends on the country - most cycling roads in Japan “end” and dump 
you into a sidewalk to cross rail crossings - otherwise they either avoid the 
grade crossing or end and put you into regular road traffic to use the road’s 
grade crossing. they are basically 1-2km long sections of cycleway that 
constantly “end" and you either join the road traffic (as a car) or use 
pedestrian routes (crosswalks, sidewalks) to get around obstacles (like 
railways or crossing a road with an island or similar). 

The official documentation for this cycling road details the “detour” on the 
regular roads to use the car’s grade crossing because they don’t want a cycle 
grade crossing. 

https://www.openstreetmap.org/#map=18/36.29001/139.36018=C

you can see the detour in blue on the map
http://www.kendoseibi.pref.gunma.jp/section/dourokikaku/hp/download/05hebi1.pdf 



I’m sure there is a dedicated “cycleway grade crossing” somewhere in Japan, but 
in the few hundred KM of cycleways I have ridden, I have never seen one. most 
non-motorcar grade crossings are for peds or for tractors. 

But I’m also sure there are countries with hundreds of dedicated cycleway 
crossings.  

Perhaps a separate “cycleway grade crossing” is appropriate  - iD recently 
started supporting cycleway crossings. Perhaps this tag is also needed.

But please remember that the basic premise that a cyclist is a variant of 
pedestrian is the idea for a lot of cycling infrastructure around the world, 
and making a cycleway crossing a “road” crossing rather than a “path” crossing 
would be considered bad mapping in a lot of places. 

Please consider this when coming up with a solution to this problem. 

Javbw


> On Oct 9, 2019, at 11:07 PM, Vɑdɪm  wrote:
> 
> On the other hand the Vienna Convention on Road Traffic mentions crossings
> for cyclists separately
> (https://www.unece.org/fileadmin/DAM/trans/conventn/Conv_road_traffic_EN.pdf):
> 
>> 3. (a) The standing or parking of a vehicle on the carriageway shall be
>> prohibited:
>> (i) On pedestrian crossings, on *crossings for cyclists*, and on
>> level-crossings;
> 
> 
> 
> 
> 
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> 
> ___
> 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] Cycling relation misuse

2019-10-11 Thread John Willis via Tagging
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. 

-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.

- 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 want to delete these fake “mountain workout” relations that should be mapped 
in strava or a similar workout app. 

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


Re: [Tagging] Designated spots for dogs to wait

2019-08-22 Thread John Willis via Tagging


> On Aug 21, 2019, at 12:16 PM, Andrew Davidson  > wrote:
> 
> hitching posts

> Hitch just means fasten to

yes, that is the verb. we're talking nouns. 

a “hitch” could be a class of knot (Bowline, etc), or a part of a trailer. 

a “hitching post”  (operative word “post” ) is a type of anchored horizontal 
bar for strapping the reins of a transportation animal to while doing something 
else. 

“hitching post” is a common description of the things used to hold a horse 
while parking in front of a location because you HITCH (that verb) the horse to 
the post with a binding HITCH KNOT. 

> You can get hitching posts for bicycles, boats, caravans, horses, dogs.


No you can’t. that is the point.

 - Boats use cleats at a dock. the knots they use when tying the rope are 
called hitches. Knots are not mappable.

- Bicycles use racks or stands. the one that looks like hitching post, but is 
often not anchored into the ground is a sawhorse rack or a bike hangar. The 
thing you pass your lock through that is anchored into the ground is a stand of 
some type. there are manytypes of stands. Stands are mappable already.

 - A hitch on a caravan is part of a vehicle, so it is not mappable, so it is 
not part of the discussion.

The feature we are mapping is the ALTERNATIVE to someone HITCHING their dog to 
a stop sign.

It is a hook for leads, not a horizontal bar where the lead (leash) or reins 
are lashed to a horizontal pole. 

Some sort of… Hook… for pet leads...  a Lead hook! 

> Camel hitches are different 

no, they use hitching posts too.

Your link about camels in a truck doesn’t illustrate any object that can be 
called a hitch (besides maybe the knot on their harness), let alone a mappable 
item. 

here is a camel at a hitching post.
https://www.alamy.com/stock-photo-a-young-kyrgyz-boy-leads-a-camel-at-the-kyrchyn-jailoo-at-the-world-116460759.html
 


the dog hook in your house isn't a mappable item. 


since the nouns - "hitching post" and “hook” are different, used for different 
purposes in different locations for different classes of animals, I think they 
should be mapped with different tags. 

These word games are not fun if you don’t use the actual names of the other the 
items. 

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


Re: [Tagging] Designated spots for dogs to wait

2019-08-20 Thread John Willis via Tagging


Javbw

> On Aug 21, 2019, at 12:15 AM, Jmapb via Tagging  
> wrote:
> 
> hitching_post

I still dislike this, as it defines parking for a horse or camel or something 
found in the equestrian=* tag. 

I really like lead_hook - as it implies: 

- it's a hook for a leashed pet
- it's a hook for a rope, not something that can anchor a 2 ton animal
- it's a feature found in urban areas, usually not in places where you could 
safely park a horse. 

Using animal=* to differentiate this is bad. 

Having to define it as "dog" means you get into the argument about if cats or 
iguanas or tortoises or baby pigs or whatever are okay (I have seen all on a 
leash) - avoid that by differentiating it at the tag level - hitching post for 
transportation animals, lead Hook for pets you walk on a leash. 

Owners decide if it is right for their pet - two dogs may not be able to share 
the same post based on tempriment, and I don't think we should define the 
number of dogs that can safely handle one hook. 

They are two different things in two different kinds of environments with two 
intended purposes. Differentiating that with an additional tag which itslef is 
ambiguous and hard to define is Very Bad™. 

Javbw. 

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


Re: [Tagging] Designated spots for dogs to wait

2019-08-20 Thread John Willis via Tagging
> 
> 
> On 6/18/2019 10:14 AM, Paul Allen wrote:
>> 
>>  So let's standardize on a tag:


Thanks for working on this.

Here are two pictures I took for a common type of lead hook I see here in 
Japan. I can upload a better one to the wiki when there is a page for this tag.

https://imgur.com/gallery/N8C15t0  

The largest chain of convenience stores have added these lead hooks to all of 
their stores as they remodel them. 

They are called “lead hooks” made by a company called SunPole. they make wall 
mounts and the more common hook on a pole. 

You can see different variants of them here. 
https://item.rakuten.co.jp/ouchimawari/031250004/ 
  

Interestingly, one of the items they sell is a green 30x30cm marker to go on 
the sidewalk in front of the pole - literally a sign for the designated spot 
for dogs to wait. 

https://item.rakuten.co.jp/ouchimawari/031250010/ 
 

Javbw


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


Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

2019-07-16 Thread John Willis via Tagging


> On Jul 6, 2019, at 10:17 PM, Joseph Eisenberg  
> wrote:
> 
> In January, Javbw  mentioned amenity=cram_school for these "juku" cram
> schools, e.g. brand Komon

Yep - "cram school" is the English translation commonly given to these kinds of 
"after-school, multi-subject, class-based schools". They have books, teachers, 
and follow an in-house curriculum to teach students. Komon is a popular one.

There are roughly 10 of these schools in a 2KM radius of my city. 

Here is a class course list webpage from a juku in Japan. This is the middle 
school courses offered. Use a translation service to read it. 
https://www.wasedazemi.com/jrhighschool


Additional comments: 

A tutor is often one-on-one. This is (primarily) not. 

A language school might have many different types of classes for different age 
ranges (toddlers through seniors), but still stays on one language. They don't 
offer total STEM classes.

A prepatory school could have the students there for 10 hours a day for a 
year-long course  - which is a true school. They basically are an additional 
year of high school focused on helping students pass the entrance exam of the 
college they wish to attend (and failed the first time).  

Cram Schools are *supplemental* to "regular school", usually as an after-school 
program  aimed at k-12 students,  Who attend on a daily or weekly schedule for 
a set period of time.

source: my children have gone to a cram_school to help with their studies on 
occaision, I currently teach at a Middle School and many students attend a 
cram_school currently, I have worked at a language school, and I know people 
who offer tutoring.  My Son attended a year-long prepatory course at a college 
prepatory school to study to enter University (not a cram school). 

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


Re: [Tagging] product of a landuse=vineyard

2019-06-20 Thread John Willis via Tagging

> On Jun 20, 2019, at 2:44 AM, marc marc  wrote:
> 
> "here grapes are produced
> for xyz wine"

Keep the produces=tag working and extend it. (Or what is proper for a vinyard):

Produces=grapes
Produces:product=xyz foobar blue wine
Produces:pdo=foobar blue grapes
Operator=xyz vinyards LLC
Brand=XYZ Booze
Genus: fooicus Barius. 

Javbw



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


Re: [Tagging] Designated spots for dogs to wait

2019-06-18 Thread John Willis via Tagging
Javbw

> On Jun 18, 2019, at 7:37 PM, Warin <61sundow...@gmail.com> wrote:
> 
> You have not seen large dogs then. A relatives dog would pull my arm off 
> running up hill .. and it was not large...

I'll have to snap a pic of one of the common pet anchor points I have seen (one 
company makes all of them around here) tomorrow.

I have dealt with large dogs. A dog would have a tough time yanking a hook 
(properly) anchored into the wall with screws or bolted to a pole, whereas a 
horse could bend the same hook open or rip it off the wall with the jerk of his 
head. They are not meant to handle that much force. 

Thinking of cats and other anamals that would use a leash, I think 
pet_hitching_point covers the expected usage and separates it from riding 
animals. These are impractical  to anchor a horse, beyond their lack of 
strength - a horse would be standing in the smoking area in front of the store 
and could kick a car or a glass display window if he used one of these pet 
points. These points simply do different jobs. You can't fit a car in a bicycle 
parking rack either. 

Although I wouldn't leave him in front of a convenience store, I have had a cat 
on a leash before - he wanted to follow us on a walk, and I didn't want him 
getting spooked and run over. 

Javbw. 

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


Re: [Tagging] Designated spots for dogs to wait

2019-06-18 Thread John Willis via Tagging

> On Jun 18, 2019, at 9:46 AM, Warin <61sundow...@gmail.com> wrote:
> 
> Are there any objections to man_made=hitching_point? I think it will be a 
> little used item.

If you search for "dog leash hitching post" you find a lot of different kinds 
of things - and all of them look like something a horse could accidently 
destroy - and would never keep them in such a spot if they yank if spooked. 

Just like we have "bridleway" distinct from footway, I don't think we should 
use "Hitching post", as it implies something to be used by hoses. 

Man_made=pet_hitching_point would be my suggestion. 

All the new Lawson convenience stores in Japan have one mounted outside, and 
many pet parks also have them as well. 

I will look up their brand name to provide more info. I have dejavu about this, 
as I think I did this before for OSM. 

I also assume there is little overlap between these two features - one meant 
for horses near a stable and one found at a suburban dog park or busy shop. 

I agree that it might not get used very much at all, but I would separate 
something meant to secure a dangerous animal the size of a car and and 
something you walk on a leash and could carry in your arms. 

Javbw

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


Re: [Tagging] Marking legal BBQ locations

2019-06-15 Thread John Willis via Tagging


> On Jun 16, 2019, at 10:33 AM, Graeme Fitzpatrick  
> wrote:
> 
> leisure=firepit perhaps?

A fire pit is a physical object, often at beaches, where open fire is allowed 
inside a very large 1x1 or 2x2 m concrete box. They are usually not used for 
cooking, but rather sitting around at night for warmth and light. 
You could use them for cooking, I guess, but that is not a firepit's purpose. 

Now let's say you are at a suburban park. Grass, playgrounds, etc. There are 
some parks with permanent grill boxes on poles. 
You can't use your own grill, only these few public grills. You might even have 
to reserve one online or buy a permit to use it, but the physical grills exist. 

https://www.smgov.net/uploadedImages/Departments/CCS/Permits_Rentals/Reserve/clover_park(1).jpg

But what about a park with a designated BBQ area, but no provided BBQs? 

https://c8.alamy.com/comp/FAT4K4/thorndon-country-park-sign-bbq-place-essex-uk-FAT4K4.jpg


It *does* has picnic shelters and benches and a solid concrete "trashcan" for 
disposing of hot charcoal Ash(a separate park amenity). A sign says "cooking 
fires in grills only". This is a "bring your own BBQ" situation, where you 
bring your hibachi and cook and (rather than dumping the coals in the bushes or 
the grass and starting a forest fire) you dump your coals/ash in the special 
can when you are finished. This way, you can rinse your BBQ and put it back in 
your car without melting your car interior. 

So this park is "BYOBBQ" - you have permission to have a controlled charcoal 
fire ONLY in a grill that you bring. No ground fires allowed. No firepits 
exist. No grills are provided - but you can bring your own and you can use it. 
Some parks do not allow this. This park does. How do we tag that *permission*?

The question of "how do you tag that you are permitted to use a grill?" Is not 
answered with man_made=firepit.

These kind of grill rules do not exist in Japan (for most suburban 
Srecreational areas), however fire prone areas (like California) have very 
strict rules about using open flame almost anywhere. Parks have a myriad of 
rules. The city provided grills suck, and are often unclean or damaged, so the 
city provided a coal can and gives you permission to operate your own,  so a 
park ranger/policeman doesn't write you a ticket. 

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


Re: [Tagging] Landuse=farmyard vs residential

2019-06-13 Thread John Willis via Tagging


> On Jun 13, 2019, at 4:22 PM, Paul Allen  wrote:
> 
> Conversion of farm buildings to residential buildings is not only possible, 
> it's frequent in
> some parts of the world.

Very true, but even a house or cottage inside a working farmyard would still be 
on a landuse mapped as a farmyard. The building may no longer be =shed or 
farm_auxiliary, but unless the activity of the farm ceases (and becomes merely 
a residential living area or a commercial resort), I think it would still be on 
a landuse=farmyard. 

Not many people want to stay in the mud and bamboo walled house with a 
collapsed roof and broken windows next to the garbage burn pile here in Japan. 
The tiny private farmyards I am mapping have their charms, but they are not 
picture postcard material. 



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


Re: [Tagging] Tunnel rock fall protector

2019-06-13 Thread John Willis via Tagging
AFAIK, these are functionally similar to avalanche protection tunnels. Most of 
the "open" sided tunnels I see in Japan are dual purpose - if it's steep enough 
for an avalanche, it's steep enough for rocks falling on cars to be an issue. 

I would use the avalanche protection tag, as it properly describes the basic 
design of the structure and basic protection offered (from rocks rather than 
snow), unless you think there are enough dedicated landslide protection tunnels 
(that are not regular tunnels) to warrant a new tag. 

Javbw

> On Jun 13, 2019, at 7:17 PM, Nuno Caldeira  
> wrote:
> 
> 
> 
> I noticed after checking these photos that i should add those tunnels to OSM.
> 
> https://www.dnoticias.pt/madeira/obra-brutal-pronta-antes-das-eleicoes-XL4872088
> 
> https://funchalnoticias.net/2019/06/07/veja-como-esta-a-ficar-o-falso-tunel-da-pestana-junior-arquiteto-paulo-david-colaborou-na-solucao-estetica-da-estrutura/
> 
> However i only found this to be similar and it's regarding snow 
> https://wiki.openstreetmap.org/wiki/Key:tunnel#tunnel.3Davalanche_protector
> 
> Do we have any specific key for those rockfall tunnel protector?
> 
> ___
> 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] Landuse=farmyard vs residential

2019-06-12 Thread John Willis via Tagging
I'm trying to map rural farming hamlets, and because land is at a premium in 
Japan, a single farmers "family" will have a small area with a very old 
abandoned collapsing house filled with old farming junk, an old house, a new 
house, a old stone storehouse or barn, several tractor garages/toolsheds, and 
piles and piles of farming garbage and stuff. larger ones have tiny cowsheds or 
additional crop processing equipment. Most of the buildings are adjacent or 
touching inside this single farmers walled/fenced area, around a small 
driveway. These are *separate* from the land they actually farm. These 
traditional farmyards are often clustered tighlty together to form a small 
hamlet which have been overgrown by modern residential suburban sprawl with 
proper roads if they are near a modern city. 

To me, these areas seem to be landuse=farmyard. 

The fields these farmers operate are being sold off (as they age and stop 
farming the land) and being turned into straight landuse=residential areas, and 
eventually these modern rectangular-grid residential areas (full of 
non-farmers) end up living around these old hamlet-style multi-generational 
farming complexes.

Am I right to consider these old-style family farm complexes landuse=farmyard? 

Javbw

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


Re: [Tagging] Irrigation: usage=irrigation vs irrigation=yes [Was Irrigation: ditches, canals and drains]

2019-06-09 Thread John Willis via Tagging


> On Jun 5, 2019, at 10:54 AM, Joseph Eisenberg  
> wrote:
> 
> 75% of waterway=drain are 2m wide or less, so most mappers do not use
> this tag for wide, canal-sized drainage waterways.


I tried repairing the mapping for an irrigation drain in my area to see how to 
map it. 

Similar to how streams and rivers often have weirs to control flow and overflow 
when they meet or split, small drains, especially irrigation, use “flash 
boards” to control flow. they fit into the body of drain channel and block the 
flow to raise the water level in the drain to supply water to additional ways.

Larger drains have small structures (1-3m) that hold multiple sets of flash 
boards to control water level and flow to branching drains and ditches, and 
inadvertently act as a garbage trap. 

https://www.openstreetmap.org/way/696049197#map=19/36.42661/139.25801 


This is a ~2x3m box of this nature. 

similar to flow_control=sluice_gate, I think I am going to use 
flow_control=flash_boards on drains/ditches with flash_boards controlling water 
flow and flow_control=flash_board_box on areas for the larger mappable 
enclosures visible in imagery for irrigation. 

Similar to the mapping the logical control of roads (stop signs, lights, 
barriers, etc), I imagine if people want to map the logical flow of this water, 
the restriction and flow features need to be defined beyond the flow. even if 
mapping them (for the most part) is not necessary for most people. we have dams 
and weirs for larger objects, and the flow_control key proposal for more 
man_made water controlling objects. 

Javbw


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


Re: [Tagging] Irrigation: ditches, canals and drains

2019-06-05 Thread John Willis via Tagging
I believe all are drains. None have width tagged, as I just researched it for 
the pictures. Tagging width from imagery is difficult, as even a small amount 
of weeds/grass can obscure their true size. The resivoir box just happens to be 
our residential area's garbage transfer point (you can see the cage in the 
photo), so I see the area often. Adding width to the 100KM I have tagged is 
very difficult. 

There is a canal + irrigation "aqueduct" nearby. It brings water 10KM to a 
small holding lake near the newer drain pictures. The dam feeds an existing 
stream that is the headwaters for a 30KM river, providing irrigation to 
farmers. and these drains & small resivoir are the first to pull water from 
that stream (and return to it 1.5km later). 

The older drains are in an urban system farther away, mostly handling rain 
runoff - but eventually supply water to farmers downstream outside of town. 

The canals (aqueducts) are rare very easy to spot, as they are constructed 
quite differently. The rest of the drain-ditch-stream-river system is 
dual-purpose irrigation+storm water management. A separate sewer system (or 
cistern tanks) handles household wastewater. 

Javbw

> On Jun 4, 2019, at 5:59 AM, marc marc  wrote:
> 
> having 2 key with the same meaning is not a good thing.
> I'm in favor of deprecing service=irrigation in favor of 
> usage=irrigation, more consistent with other usage=* values
> used on other waterways.
> 
>> Le 03.06.19 à 22:19, François Lacombe a écrit :
>> Hi all
>> 
>> Regarding the particular situation of service vs usage keys, JOSM team 
>> wonders if service may be moved to usage
>> https://josm.openstreetmap.de/ticket/17770
>> 
>> Don't blame them on "deprecate" word, which should be understood as 
>> "discouraged".
>> Question is "Should we keep service in use for destination of water 
>> leading in man made waterways?"
>> 
>> All the best
>> 
>> François
>> 
>> Le ven. 31 mai 2019 à 22:41, François Lacombe > > a écrit :
>> 
>>Hi
>> 
>>I agree with aqueduct as a system composed of bridges, tunnels,
>>pipes and canal (not only a bridge crossing a valley).
>> 
>>Le ven. 31 mai 2019 à 16:10, Mateusz Konieczny
>>mailto:matkoni...@tutanota.com>> a écrit :
>> 
>>I think that in this case, with only
>> 
>>usage=headrace
>>waterway=canal
>> 
>>tags even a perfect renderer would have a trouble.
>> 
>> 
>>That's right
>>It misses a structure
>>Tunnel and bridge can eventually help respectively for underground
>>and overhead situations.
>>Another key or value have to be determined to describe overground
>>lining (and other possibilities)
>> 
>>If the canal have a constant width, it can be added with width=*
>>referring to water width at its surface
>> 
>> 
>> ___
>> 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] Irrigation: usage=irrigation vs irrigation=yes [Was Irrigation: ditches, canals and drains]

2019-06-05 Thread John Willis via Tagging


> On May 30, 2019, at 9:03 AM, Joseph Eisenberg  > wrote:
> 
> Thank you for the information about Japan.
> 
> How are the small drainage/irrigation channels tagged currently in Japan?


I uploaded some pictures of drains I see in Japan.

a vast majority are between 20-50CM wide precast concrete segments. 
https://wiki.openstreetmap.org/wiki/File:Drain_50cm.jpg 


old ones are made out of concrete and river stones.  
https://wiki.openstreetmap.org/wiki/File:Drain_old_40cm.jpg 

https://wiki.openstreetmap.org/wiki/File:Drain_old_180cm.jpg 
 
 

Larger ones are usually 90cm that provide (upstream) and collect water 
(downstream) from the smaller ones. they often serve multiple sets of fields 
before returning to the river or stream the water was diverted from. 
https://wiki.openstreetmap.org/wiki/File:Drain_90cm.jpg 

https://wiki.openstreetmap.org/wiki/File:Drain_90cm_covered.jpg 



plastic pipes and earthen ditches are used to provide water from the drain to 
the fields. 
flow is controlled via movable doors, rocks, or small sluice gates the size of 
a sheet of paper (or smaller). 
https://wiki.openstreetmap.org/wiki/File:Drain_large_and_small.jpg 




small concrete weir boxes (40x40cm up to 2x4M) control flow and overflow from 
supply into irrigation channels. 
https://wiki.openstreetmap.org/wiki/File:Drain_weir_box.jpg 


There are also very small reservoirs used to water specific sets of fields. 
https://wiki.openstreetmap.org/wiki/File:Resivoir_box.jpg 



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


Re: [Tagging] A modest proposal to increase the usefulness of the tagging list

2019-06-04 Thread John Willis via Tagging


> On Jun 4, 2019, at 2:40 PM, Mateusz Konieczny  wrote:
> 
> Or you will use. 


Thanks for handling man_made bridge. I use it a lot. 

The only comment to this idea of “make tags for you to use” is that if you 
invent a tagging method for a particular type of object, that you include 
similar objects that people would like to map to avoid tag fragmentation.

If you propose amenity=foobar, I expect you to consider a subtag like foobar=* 
or foobar:type=* to be able to define different types of the foobar people 
encounter. 

if you are proposing a new tag foo_bar=* to handle x, y, & z, I expect you to 
consider l,m,n,o & p as well - even if you don't use them -  because trying to 
get them “approved” later is very difficult, and people will use incorrect tags 
on objects just to complete mapping if that is the case. 

the Tagging mailing list extends the **tagging system**, It’s not just for 
solving a single particular mapping issue for an individual. 

Tags can be extended later, but it means convincing people to support a sinlge 
tag value they don't care about individually or don't understand the usefulness 
of, when it probably would have easily been approved without objection if it 
was included in the original proposal. the golf=cart_path recently comes to 
mind. 

Javbw





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


  1   2   3   4   5   6   7   8   >