from:"rob"

On 7/27/20 1:04 PM, Martin Koppenhoefer wrote:
>> highway=track appears to be incorrect here (but maybe still correct
>> if it is leading to only vacation huts)
>> these would be highway=service not track.

  I assume if the highway has no name, it'd be highway=service, but if
it has a county name, like "Lost Gulch Road" too, wouldn't it then be
highway=residential? Is there a difference if it's vacation cabins, or
seasonal or full-time houses ?

- rob -

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

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

On 7/27/20 11:00 AM, Paul Johnson wrote:
> I'd go with highway=track and tracktype=*, surface=* and smoothness=*
> tags as necessary.  Given how inconsistent the 3 and especially 4 digit
> US forest service roads tend to be, I'd expect tracktype and smoothness
> are underutilized despite their relative importance on those roads.

  That's roughly what I've been doing, Drive or hike there, and decide
on the values for those tags while standing there. I'm still curious
about "narrow" though. :-) I don't think smoothness gets rendered
though, and everything is usually a grade2, so somewhat meaningless.

> itself.  If the placard has a horizontal orientation (read from left to
> right), then it's intended to be passable by most vehicles but may or
> may not be paved.  If the placard has a vertical orientation (read from
> top down), then don't count on your car being able to make it, you'll
> probably need something with ground clearance and 4WD if it's
> traversable at all with a motor vehicle.

  Yep, we teach our trainees that, and since we use current USGS topo
maps as basemaps in OsmAnd, you get that and the OSM data. Best of both.
Sure beats the days we used a thick paper map book, and a bag of topo maps.

  Personally though, what the USFS uses to determine that difference
doesn't seem consistent, and over many years, the road conditions change
drastically due to erosion. I prefer to go there in a high-clearance
vehicle or UTV and decide after driving it.

- rob -

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

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

On 7/27/20 10:10 AM, Paul Johnson wrote:

> 3 and 4 digit forest service roads?  They're there exclusively there for
> the benefit of forestry (namely logging, replanting and fire
> suppression).  If they happen to help someone else get where they're
> going, great, but that's not what they're built and maintained for. 

  Actually around here, almost all roads have a 3-4 digit reference
because we're in a national forest. They apply to most every "highway",
residential, ATV tracks, hiking trails, and driveways, and aren't
exclusive at all. Even the county maintained roads have a ref:usfs. The
ref:usfs often changes at intersections, and the ref for the county road
may not. Much of the map data (Tiger, etc...) is really out of date and
wildly wrong, so I go there and see what the sign says it is.

  The only roads exclusively for forestry or emergency access have a
locked gate with a USFS lock. Non USFS locks are for private driveways.
Some gates have two locks, one for forestry access, the other for
home-owners. Both are usually posted as well. Fire fighter officers
carry special master keys for these, or occasionally resort to
bolt-cutters or chainsaws.

  Most of these roads weren't built by the forest service, they are
left-over from the mining era in the 1800s, and pre-date the formation
of the forest service. They just adopted them, and stuck reference
numbers on them. Lately many are being closed off, so I've been doing a
lot of field trips to update things based on reality.

- rob -

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

Re: [Tagging] FWD: Re: narrow=yes, vs lanes=1, vs width

On 7/27/20 9:18 AM, Mateusz Konieczny via Tagging wrote:

> highway=track appears to be incorrect here (but may be still correct if
> it is leading to only vacation huts)

  It's a residential "track" to the vacation houses, often usually only
used in the summer or for ski trips. After the last building it
degenerates into a worse track. While changing
highway/smoothness/tracktype/surface at that transition spot helps, they
also often get much narrower.

- rob -

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

[Tagging] narrow=yes, vs lanes=1, vs width

 My entire county is contained within a national forest, and most of the
roads through residential areas are a single lane dirt road maintained
(sort-of) by the homeowners themselves. Often at the last house the road
becomes an unmaintained jeep trail, usually gated, and goes a really
long way into the forest. We use these for wildland fires and rescues
frequently.

  The question is how to tag the change in the road. Usually it becomes
"smoothness=very_bad", etc... The question is since it's now more of a
track used by jeeps, should it be narrow=yes, still lanes=1, or should I
use width=2m ? To me, lanes= seems to apply more to non 4wd_only tracks.
They're also usually narrower than the single lane highway too. The
width of the "highway" is important if you're trying to figure out what
size fire truck to bring to the wildland fire...

- rob -

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

[Tagging] Feature Proposal - RFC - UPRN & USRN

2020-07-26 Thread Rob Nickerson

Hi all,

Mappers in the United Kingdom are looking to agree two tags for mapping
'Unique Property Reference Numbers' and 'Unique Street Reference Numbers'.
To support this effort I volunteered to create the relevant proposal pages
on the wiki.

To view and comment on these please see:

https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn
https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn

These pages have already been posted to talk-gb and talk-ie (for Northern
Ireland) a few days ago. As long as there are no major blockers here, we
will move to the voting stage shortly.

Thank you,
*Rob*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Path or track with many fallen trees

2020-06-26 Thread Rob Savoye

On 6/26/20 8:13 AM, Martin Koppenhoefer wrote:

> it’s up to your judgement, in my area if blocked with a mound this
> would not be a track anymore. You can decide whether keeping it for
> hikers (if legally and physically possible, i.e. highway=path) or

 A week or so ago I fixed a bunch of residential roads that map data
claimed continued out of the small developments and into national forest
land. They now have a dirt berm, (some have a gate) and the remaining
part of "road" is now closed for cars. Most were used as ATV trails by
locals, so I assumed a track. A few were obviously foot traffic only, so
now a path. Most of these were closed in only the last few years, I
talked to some of the locals. Access is still public, although the
neighbors wish otherwise...

- rob -

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

Re: [Tagging] Path or track with many fallen trees

2020-06-25 Thread Rob Savoye

On 6/25/20 5:44 PM, Mike Thompson wrote:

> How would you recommend tagging a path or track that has many fallen
> trees across it? There are too many to map each one with a node tagged
> barrier=log.  Foot travel is legal, but physically difficult.  Horse and
> bicycle travel are legal but probably physically impossible.  Motorized
> travel is prohibited, and would probably be physically impossible anyway.

  I do know a trail to Kit Carson Peak like that, but around here the
downed trees don't last long, so I'm not sure if I'd map them.

- rob -


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

Re: [Tagging] How are protected_area (and national_park) boundaries determined?

2020-06-23 Thread Rob Savoye

On 6/23/20 4:45 PM, Mike Thompson wrote:

> Interesting.  I had always assumed that the land that a mining claim
> covered continued to be owned by the Federal Government, but that the
> claim holder had the right to extract minerals and hopefully an
> obligation to pay the Federal Government some royalties if they were
> successful.  

  What happened is some mining claims were mostly exploratory, and often
didn't find anything worth extracting. There was a process to convert
public land to private land. My documents are from 1903, and signed by
President William Harrison. I also have to pay annual rent for my access
road from the Forest Service, and do all the road maintainance. This is
very common around here in the Rockies.

  I totally agree about camping issue, but I make personal data files
from the USFS landowner data, or County parcel data. I've been climbing
in Wyoming, where people greet you with guns if you're in the wrong place...

> I know exactly what you are talking about, but apparently it is some
> international standard that national forest like areas are called
> protected areas and assigned a certain level of protection, even if in
> reality they are less protected than if they were privately owned.

  Something I learned many years ago when I was caretaker of a very
large cattle ranch is that unless your no trespassing signs are every
430ft, you can't enforce anything. A jeep club once had a rally in our
summer pasture, and destroyed a wetland at 10,000ft in the process, and
there was nothing we could do about it. It was on land leased from the
Forest Service for grazing. The only protected areas around here are the
wilderness areas.

- rob -

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

Re: [Tagging] How are protected_area (and national_park) boundaries determined?

2020-06-23 Thread Rob Savoye

On 6/23/20 9:18 AM, Joseph Eisenberg wrote:

> The argument in favor of the second is that the privately-owned land
> within the boundary has no actual protection against development. For
> example, I lived in a village which was within the declared boundaries
> of the Klamath National Forest, but the development rules were
> determined by the County government and they were mostly the same as if
> we were not in the boundary (I think?)

  The rural area I live in is full of old mining claims, which are
private property surrounded by public land. There's often zero fencing,
signs, etc... to delineate the boundary at all. Many of the mining
claims are only 50x200ft, often with an old cabin. While I do use parcel
maps on fire calls, adding all these boundaries to OSM would be silly. I
agree that mapping the outer boundary is all that's needed.

> In other countries, how are National Park and other protected_area
> boundaries determined? If there are villages or towns within the
> boundary, are they actually protected? Are they excluded from the area?

  My nearby hamlet of <200 people is also surrounded by national forest.
The forest is not "protected" at all, it's full of trails and jeep
roads. A few of the larger ranchers have fencing, but it's a bit of a
free for all elsewhere... There are few county development rules at all,
course that's partly why I like it here.

- rob -

___
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-30 Thread Rob Savoye

> Date: Sat, 30 May 2020 15:46:31 +0200
> From: Daniel Westergren 

> *An additional issue:*
> 6. sac_scale is currently the only tag (possibly together with mtb:scale)
> to denote the difficulty of a hiking trail (that is, the way, not the
> route). But it's very geared towards alpine trails and there is not enough
> nuance in the lowest levels. Could the Yosemite Decimal System (YDS),
> Australian Walking Track Grading System and others complement or expand on
> sac_scale?

  As a climber, I don't think we'd want to apply YDS to hiking trails.
To me, YDS should only used for technical routes requiring equipment
(usually). I think "mountain_hiking" is what you can do without
equipment, even if occasionally using your hands for balance.
"alpine_hiking" is when I'm up near or above treeline, often in snow or
large scree fields. A fuzzier category are climber access trails that
most hikers shouldn't use. We have many of those around here.

> Would this be a fair summary? What have I missed? Who is interested in
> continuing this work in a smaller group? Or should we continue to spam this
> mailing list?

  I'd be interested in a working group on this, as my map data and maps
are used by multiple rural fire departments and SAR groups. You wouldn't
be surprised by how many people we rescue that misjudged the trail
difficulty... For us though, looking at the subtags helps determine the
type of response and equipment. sac_scale is a bit open to
interpretation based on one's experience, but better than nothing.

- rob -

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

Re: [Tagging] road names and refs

2020-01-30 Thread Rob Savoye

On 1/30/20 2:08 AM, Richard Fairhurst wrote:

> You asked this back in August and the answers still apply:

  That was as slightly different question about multiple names, and yes,
still applies.

> "County Road 12" is a ref. It is not a name. People often refer to roads by
> their ref. That's fine. I will say "I'm taking the A3400 to Stratford"

  I'm wondering if "CR 12" or "County Road 12" (the abbreviation
expanded) was the proper value for a ref. If the abbreviation is fine
for the ref, should it then have a name that is expanded ? The wiki
isn't clear.

- rob -

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

Re: [Tagging] road names and refs

2020-01-29 Thread Rob Savoye

On 1/29/20 3:07 PM, Joseph Eisenberg wrote:

> In my hometown, the main road was California highway 96, so “ref=CA 96”
> but we called it “Highway 96” so “name=Highway 96”.

  That's what I was thinking. Here we have a
"name=highway 550", which is "ref=US 550", and another one is
"name='Camp Bird Road', ref='CR 361', and "ref:usfs='FS 838'".

  I interpret the responses that for a road, (not an address) it should
be "name=County Road 12" and "ref=CR 12". Most the addresses here use
"addr:street='CR 12', but locals call it "Country Road 12", which is
what the sign says. I'm just trying to get this right so I only have to
fix it once. :-)

- rob -
-- 
https://www.senecass.com

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

[Tagging] road names and refs

2020-01-29 Thread Rob Savoye

 I was wondering about tagging roads properly. Previously it was
mentioned to use 'ref' for county roads, ie... "ref='CR 12'", but as the
road sign says "County Road 12", I was wondering about the proper way to
tag this. Should 'CR' be expanded in the 'ref' to "County Road", or
should 'ref' be 'CR 12', and then "name='County Road 12'" ? This also
applies to state Forest Service roads as well that lack a name tag. I'm
working on cleaning up some ancient crap from the TIGER import...

-rob -
-- 
https://www.senecass.com

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

Re: [Tagging] What values of 'emergency=' should be on the, main Map features page?

2020-01-20 Thread Rob Savoye

On 1/20/20 5:00 AM, tagging-requ...@openstreetmap.org wrote:

> Sounds basically reasonable to me.  The page does not make it clear
> if this is just a place you can put a hose in, or if the piping is
> pre-installed.  What I'm talking about is a red 3 or 4" pipe that
> runs from under the middle to the edge with "FD Water Source #6" sign
> or some such.   Maybe that's what

  Some of our raw water sources do have a 3" fitting we use to draft
water. What's more common though in my fire district is "suction_point"
is where I park a fire truck and just drop a 3" hardline into the pond
or creek. Since these locations must be flat, and less than 10ft above
the water source (hard to find in the Rockies), we tag these so newer
responders can find them.

  A water pond or cistern with a 3" connection I'd consider a dry
hydrant, which just means there is no pressure behind it.

- rob -

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

Re: [Tagging] addresses on buildings

2020-01-07 Thread Rob Savoye

On 1/7/20 11:02 AM, Volker Schmidt wrote:
> Nervertheless I admit that there will certainly be cases where we
> need some way of tying together the point where the navigation device
> finds the address and the buidling where the people live whom you
> have come to visit to have a cup of tea. A site relation ?

  My experiments with routing apply mostly to OsmAnd and what's in the
PBF files it uses. I dug pretty deeply into this recently while adding
OSM support to CadPage so we could use it for dispatch. All they need to
start navigation is the current location, and the GPS coordinates of the
destination. There is an option at that time to route on highways marked
private, ie... long driveways. If the footpath to the house is in OSM,
it'll take you all the way there. That's assuming all your highway data
is good, all highways=* actually connect, relations are good, etc...
Good navigation has been critical for our new fire fighters being able
to find anything efficiently. Beats using a 3 inch thick paper mapbook
like we used to... Which hadn't been updated in 17 years either.

  It of course gets the location of the destination by looking it up
using 'addr:street' and addr'housenumber'. Everything else like
'addr:full' is ignored. Sometimes it'll limit the search to the nearest
decent sized boundary, like a city.

- rob -
-- 
https://www.senecass.com

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

Re: [Tagging] addresses on buildings

2020-01-06 Thread Rob Savoye

On 1/6/20 6:04 PM, Paul Allen wrote:
> As I understand it, in some countries the emergency services use
> OSM. Knowing the building they can figure out which gate to use. 
> Knowing the gate may not tell them which of several buildings they
> need to get to.
  We use OSM for emergency response since Google has poor data in my
area. Since the OSM data here is now quite detailed and accurate, it
literally dropped our response time in half. All our fire trucks have a
10" tablet mounted on the dash that works as a dedicated mapping device.
Our district covers several hundred square kilometers of mostly obscure
dirt roads left from the mining era.

> Then again, as long as people don't force me to put addresses at the
> end of driveways, I'm not going to put much effort into arguing the
> point.
  I think there is confusion as to a real building's address sign, which
may be at the end of the driveway, but in an OSM file, the address node
should be on the building. Or part of the building way's tags.

- rob -

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

Re: [Tagging] addresses on buildings

2020-01-06 Thread Rob Savoye

On 1/6/20 4:38 PM, Volker Schmidt wrote:

> the buildings, where he can ring the bell. In many case this is not on
> the building but on the entrance to the property.. I have a real case

  Here that's very common. Physical address signs are on the end of the
driveway where they can be seen. Course many driveways around here are
long, and you can't see the house from the road.

- rob -

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

Re: [Tagging] tagging historic ruins

On 1/5/20 11:55 AM, Tod Fitch wrote:
> The name value almost certainly should not be “Indian Ruin”. If 
> “Indian Ruin” is used for a value at all it should be in the 
> description tag. Probably the more politically correct nowadays
> might be “Native American ruins”.

  That was my thought, "Indian Ruin" is overly generic, and should just
be deleted as file bloat.

> Most of the larger sites have official names. “Montezuma Castle 
> National Monument”, “Casa Grande Ruins National Monument”, “Tuzigoot 
> National Monument”, “Tonto National Monument”, “Walnut Canyon 
> National Monument”, “Palatki Heritage Site” and “Canyon de Chelly 
> National Monument” in Arizona spring to mind. Within those sites the 
> there may be individual buildings/groups of buildings that have
> names as well but those often seem to be descriptive (“Big House” or
> “South Buildings”).

  Correct, but that's when 'name=' should be used. And the name may also
be subject to interpretation based on who you ask. Many official names
have little to do with what the locals call it. OSM can support both.

> peoples (different native American tribes moving in, Spanish or 
> Anglo). So I think the official names, probably found in the GNIS 
> database is the best you are going to do.

  Yep, it's now the Ute reservation. I'm not going to add any names at
this point, just curious about cleaning up some existing data. Mapping
the ruins isn't the purpose of this trip, I just was wondering when
looking at the data, and had the motivation to be a data janitor since I
probably will try to ski/hike to some of these ruins.

> Regarding historic:civilization tag using “Ancestral Pueblo people” 
> vs “Anazazi”, I think I’d go with “Ancestral Pueblo” as I think that 
> is, from current thinking, historically accurate. I believe that 
> “Anazazi” is Navajo for something like “ancient enemy” but could be 
 I
  I'm going to ask in person what's the correct name as the locals think
of it. "Pueblo People" is a catchall for multiple peoples that have
lived there over the centuries and probably the least accidentally
insulting. There's always the old joke about some person who gets a
"ceremonial" native name, and later finds out it means something like
'stupid dog s$%t'...

> Regarding mapping of the individual buildings, my single feeble 
> attempt at one site was foiled by the fact that it was, as is 
> typical, in an overhang under a cliff with limited access. So my GPS 
> had very inaccurate data and the site is not visible on aerial 
> imagery. Best of luck in your mapping.
  Yeah, I'm a climber, and it's quite amazing to see how difficult some
of the climbing to the cliff dwellings is. Some people think it was for
defense, I think it was to keep the rats and other animals out of the
stored food. It's a hard, dry  country to live in...

- rob -



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

Re: [Tagging] addresses on buildings

On 1/5/20 11:45 AM, Shawn K. Quinn wrote:

> In the US it can go either way. I've seen a shopping center where
> multiple buildings had the same address (number and street) but
> different ranges of suite/unit numbers.

  I can see both being appropriate. We have multiple old resorts with
one address, and several dozen cabins. Each cabin though is a building
way. When I got the official cabin names from the homeowners
association, I added that as nodes. I'd just like to do what's
appropriate. Mostly though I was wondering about a standalone rural
building. OsmAnd will dis[play the address either way, so it's a matter
of the metadata syntax.

- rob -

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

[Tagging] addresses on buildings

  I assume the right place for tags like 'addr:housenumber' &
'addr:street' are on the building way, and not a standalone node ?

- rob -
-- 
https://www.senecass.com

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

Re: [Tagging] tagging historic ruins

On 1/5/20 10:56 AM, Martin Koppenhoefer wrote:

> from my point of view, yes, it is usually preferable to tag ruins with
> historic=archaeological_site (unless they are modern/recent). I’ve
> myself used historic=ruins a lot many years ago and have since changed
> most of them to archaeological site.
> I also suggest to add historic:civilization to give more
> context: https://taginfo.openstreetmap.org/keys/historic:civilization#values

  historic:civilization='Ancestral Pueblo people' or 'Anasazi' ? Yeah,
last known inhabitants was 1300AD.

> And site_type of course: https://taginfo.openstreetmap.org/keys/site_type

  I think archeologists still are arguing over the site type. :-) Nobody
really knows whether they were forts, food, storage, lodging, or all of
the above.
(https://www.smithsonianmag.com/history/riddles-of-the-anasazi-85274508/)

> I’d see historic=ruins as a very generic fallback when you have no clue
> what you are looking at, but which should ideally be retagged if you do
> have an idea what it is.

  I'll fix the tag. When I get down that way, I plan to collect more
information from the locals. Most of it is reservation land and poorly
mapped. It's about a remote a place you can get to in the continental US.

  Oh, most of these have 'name="Indian Ruin", not sure if that's
necessary as it's redundant.

- rob -

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

[Tagging] tagging historic ruins

  I noticed today while planning a camping/mapping trip to southwest
Colorado many nodes all tagged with 'historic=ruins', and that's about
all. Most of these are stone buildings, some cliff dwellings in various
states of decay. I was wondering if they should also be tagged as
'building=yes' or anything else, or does that just add unnecessary bloat ?

  Digging around the internet, I see a variety of ways to tag sites like
this, and a few old unapproved proposals. Since these structures are
thousands of years old, shouldn't they be 'historic=archaeological_site'
instead ? Or 'historic=cliff_dwelling, ruins=yes' ?

 I'll be there in few weeks and plan to collect & validate more metadata
for that area, but was curious about the proper tagging for these sites.

- rob -
-- 
https://www.senecass.com

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

Re: [Tagging] place or border_type ?

2019-10-28 Thread Rob Savoye

On 10/28/19 2:59 AM, Sarah Hoffmann wrote:

>> +1, I have never understood why some people are double tagging 
>> administrative entities not only with admin_level and boundary but also with 
>> place tags.
> 
> It is one possibility to tag such administrational oddities
> as German "kreisfreie Städte" where an admin_level=6 may be
> a county or a city.

  I don't see much if any of this double tagging, but place=* seems more
accurate, which is why I asked. I do see border_type used as well.
Anyway, I can now fix this appropriately when I find it.

- rob -

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

Re: [Tagging] swimming=* access tag

2019-10-24 Thread rob

Hi Martin,I would agree that water transportation is a very poor description of 
it, however that seems to be the least inappropriate place to put it in the 
hierarchical list on the wiki page for access=*. The list also includes 
canoe=*, which isn't really transportation for  e.g. a recreational canoeist in 
a lake or the docks.I certainly wouldn't describe it as transportation on a 
wiki page for the swimming=* tag, should it progress to a successful 
proposal.-- Robert Skedgell (rskedgell)
 Original message From: Martin Koppenhoefer 
 Date: 24/10/2019  09:23  (GMT+00:00) To: "Tag 
discussion, strategy and related tools"  Subject: 
Re: [Tagging] swimming=* access tag Am Mi., 23. Okt. 2019 um 12:03 Uhr schrieb 
Robert Skedgell :I wonder whether it would be worth adding 
a swimming=* access tag to the
wiki and the list under "Water-based transportation" section of the page
for access=* (alongside boat=*/canoe=*)? I am not opposed to the term 
"swimming", or using it as an access value (there are ~400 uses of it, and 
although "natural" is the second most used value, it isn't significant in 
absolute numbers),but putting it under "water based transportation" seems odd. 
Is swimming a kind of "transportation"?Cheers,Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging camping

2019-09-08 Thread Rob Savoye

On 9/8/19 1:09 PM, Paul Allen wrote:

> Also, cellular connectivity changes as operators add towers or 
> reconfigure existing ones.  There's also the consideration of whether
> there's 2G,  3G, 4G or 5G.  Probably best left to one of the
> dedicated cellular mapping apps such as cellmapper because that info
> is a little more likely to be updated more frequently.

  Ah, hadn't thought of that. I'm not hung up on using this tag, I was
just trying to make a complete list... but a different database might be
better maintained.

> In the UK if a campground stated they offer WiFi and some pitches didn't
> get it there would be complaints.  Grounds for prosecution about misleading
> advertising, even.

  Interesting. That isn't the case in the western US, or other countries
I've been in. Some even tell you were to stay if you want better
connectivity from your camp. They're usually honest about spotty
coverage, so not really a problem. Often the only wifi router is in the
main office/lodge, so it's pretty easy be out of range.

  Note the entire purpose of camping should not be making sure you have
a data connection. :-) I work in the field for prolonged periods, so
sometimes drop into a real campground to sync up data. (and a shower)

> With wired ethernet you have a point.  I've not seen any campgrounds
> here offer anything other than WiFI, though.

  Chaos Camp. :-) And a few other Hacker camp-outs I've attended. These
are temporary, so of course not worth mapping.

- rob -

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

Re: [Tagging] tagging camping

2019-09-08 Thread Rob Savoye

On 9/8/19 12:46 PM, Paul Allen wrote:

> So a campground owner is going to put Faraday cages around certain
> pitches to ensure
> they cannot receive WiFi?  Or is going to put very restricted-range WiFi
> points on certain
> pitches?  Or is going to run ethernet cables to some pitches but not others?
> 
> I don't see this of being much use in real-life situations.

  I agree it's trivial data, and probably the wrong tag. I was trying to
cover cases were an individual camp_pitch may have a cell connection.
Especially in widely distributed camp spots in the more remote parts of
the western US, I occasionally find a camping spot with cell
connectivity, and others may find that useful.

  Also note that in the US, most KOA and other commercial campgrounds
have wifi. That coverage doesn't get to every camp_pitch though.

  And yes, I have definitely camped where there were ethernet and power
cables running to many locations. :-)

-rob -

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

[Tagging] tagging camping

2019-09-08 Thread Rob Savoye

  I've been wondering about the proper way to tag camp_pitches and
camp_sites to avoid bloat and duplication. It seems to me that within
most campgrounds, there are global tags that don't need to be applied to
each individual camp_pitch. And that each camp_pitch within that
camp_site should only have the tag if it differs from the global value;

 I think that the camp node/way/relation should have tags like:

For camp_site:
 toilets=yes/no
 openfire=yes/no
 drinking_water=yes/no
 fee=yes/no
 barbeque_grill=yes/no
 picnic_table=yes/no
 bear_box=yes/no
 tents=yes/no
 caravans=yes/no
 group_only=yes/no
 internet_access=yes/no
 power=yes/no

For camp_pitch:
 openfire=yes/no
 barbeque_grill=yes/no
 picnic_table=yes/no
 bear_box=yes/no
 tents=yes/no
 caravans=yes/no
 group_only=yes/no
 access=handicap
 internet_access=yes/no
 power=yes/no
 drinking_water=yes/no

  The wiki doesn't say much about this topic. Many camp_sites within OSM
are sparsely tagged (at least around here), so that wasn't much of a
guide either.

- rob -

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

Re: [Tagging] bear box in campground ?

On 8/21/19 7:27 PM, Paul Johnson wrote:

> For someone who is not familiar with the term 'bear box' it may
> sound like bears are stored in there.
> "Food storage box" might be better?

  Actually something like that is probably a better term. I think 'bear
box' only because that's the term I'm familiar with. 'Big Metal Box'
would be accurate too, but confusing.

  There's also bear proof trash cans, but I don't think that needs a tag.

- rob -

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

Re: [Tagging] bear box in campground ?

On 8/21/19 6:52 PM, Warin wrote:

> If they team together they can form a pyramid for the reach, only 
> need to figure out the handle then. Can they do zippers? Raiding 
> tents and backpacks then becomes possible.

  Around here the bears have learned to open car doors, hours doors, and
yes, tent zippers too. Course with tents they usually just go in through
the nylon where ever they want.

> a more common mapping method would be individual objects for 
> eachfeature (a node for each feature, inside a tourism=camp_site 
> polygon) or properties (bbq=yes bear_box=yes etc.) on a “main” 
> feature (camp siteobject). We usually don’t do amenity =foo;bar

  With several hundred camp sites spread out over several hundred square
miles, and many are backcountry ones, I doubt I'll ever get around to
mapping each site to that level of detail. I like the idea though, maybe
when I get done the current TODO list...

- rob -

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

Re: [Tagging] bear box in campground ?

On 8/21/19 5:17 PM, Joseph Eisenberg wrote:
> I agree with Martin. It's not good practice to use semicolons in the
> value of the main feature tag, like amenity=bbq;bear_box, because this
> is hard for database users to interpret with a simple algorithm.

  Actually I've found the opposite. Importing into Postgresql doesn't
support multiple tags of the same name. At least not when importing
using ogr. I do produce maps from Postgresql, and have no problem with
semi-colons. Course I'm using my own software for SQL queries. I'd be
curious what OsmAnd does when displaying 'tourism' POIs.

> At the proposal
> (https://wiki.openstreetmap.org/wiki/Proposed_features/Campsite_properties)
> there are a list of property tags which are already approved or "de
> facto" in common use on camp_site (and camp_pitch) features, like
> this:

  I saw that, but they're proposed, so I've been trying to stick to
what's approved. I already do use many of the existing properties.

> Note that there are also feature tags for almost all of these, like:
> amenity=drinking_water
> amenity=recycling
> amenity=sanitary_dump_station
> amenity=toilets

  Using properties works fine for my purpose, and if it's ok to create a
new property 'bear_box=(yes,no)', I can do it that way. I'm not in a
hurry, so can also wait for the proposal to hopefully get approved.

> Hence: amenity=bear_box on it's own node, right at the location of the
> box. Or if you don't have that info or just want to say that "there is
> a bear box at this campground", you can add bear_box=yes/no to the
> tourism=camp_site

  So now it seems it'd be "bbq=yes', 'picnic_table=yes', 'bear_box'yes'.

- rob -

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

Re: [Tagging] bear box in campground ?

On 8/21/19 4:16 PM, Graeme Fitzpatrick wrote:

> We don't have that problem!, but are the bear boxes at each individual
> site / pitch, or is there one / "x" for the entire campground?

  Bear boxes are in every campsite, and hold about a week's worth of
food. They're big enough you can put in a decent size cooler plus
supplies A campground sized one would be huge!

- rob -

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

Re: [Tagging] bear box in campground ?

On 8/21/19 3:54 PM, Joseph Eisenberg wrote:
> This suggests that you could also use bear_box=yes/no with a 
> tourism=camp_site or tourism=camp_pitch feature to specify whether
> or not their is a bear box somewhere at the location.

  Yeah, I'd add this to a 'tourism=camp_pitch' node. Where I was
yesterday works out to something like 'amenity=bbq;bear_box;parking'
plus 'leisure=firepit'.

> We should probably add both of these to the proposed list of
> campsite property tags at

  That's be a good idea, as bear boxes are becoming more and more common
in western US campgrounds.

- rob -

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

[Tagging] bear box in campground ?

  Many western state campgrounds have metal bear proof food storage
boxes in each campsite, but not all of them. At certain times of the
year this can be important. :-) Around here the bears will destroy your
car if there is food left inside. I see zero instances of this type of
data, at least not in Colorado. My guess would 'amenity='bear_box' ?
(looking at amenity=bbq as an example)

- rob -

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

Re: [Tagging] roads with many names

2019-08-19 Thread Rob Savoye

On 8/18/19 10:05 PM, Kevin Kenny wrote:

> route=road relations provide a way to group all the individual
> segments of a numbered route into a coherent whole, and allow for
> better handling of things like the choice of highway shield and the
> handling of concurrencies (where two numbered routes run along the
> same roadway).

  Interesting, this answers something I've wondered about. Sometimes I
see ways in data that you can tell the GPS signal dropped, those I just
connect. I'm mapping locally, so have a sense of when that's
appropriate, and can drive there to validate. When the metadata changes
sometimes in the segments, those have to be separate to preserve that.
For us that's often where you park the fire truck and get the UTV
going... Anyway, as a long term solution, route=road seems the way to go
after I get all the data cleaned up.

> For your example, the 'ref' on the way would be 'CR2;FS 729.2B'. The
> way would be a member of two route relations, one for the county road
> and one for the Forest Service route.

 If I ever got around to adding all these relations, it might improve
search. A big task unfortunately. There are other issues with how search
works in OsmAnd, that's a different email list. :-)

- rob -

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

Re: [Tagging] roads with many names

On 8/18/19 9:09 PM, Johnparis wrote:
> Don't know how you deduced "no space?" from Martin's comment. A space
> is an alphanumeric character. In any case, as I mentioned, there is

  I just read too much into example of 'CR2'... I'm just trying to get
it right, so routing works better. I prefer the space as it's easier to
read...

> The problem with space-vs-no space arises particularly with refs,
> which are searchable. If you include the space for refs of national
> routes in Morocco, someone will remove it; if you omit it in Algeria,
> someone will add it. There are some advantages to consistency within
> a given area,

  Many of the existing USFS roads in OSM in this area use 'alt_name',
which doesn't seem to get used for routing, while the ref* ones do. I'm
a huge fan of consistency, since it makes it easier to parse data and
render when I'm making maps.

> Tag *names*, by contrast, use an underscore instead of a space.
> Kevin Kenny's comment above indicates what appears to be the
> consensus on the tag name(s) in the USA. So in theory you might have 
> ref:US:NFSR:Raggeds_Wilderness:NFH=FS 826. That seems to me to be a
> bit much to swallow ...

  Yeah, maybe too verbose. :-) I can tell which forest it's in by
checking the boundary. I haven't seen that long tag actually used, at
least not here in Colorado. I think 'ref:usfs' works fine.

> ... except that, again, you might want to use a space instead of a 
> hyphen in the "ref" tag in this case, and normally you'd use
> semicolons (not commas) as a separator in the "source" tag.

  I'm noticing many of the existing roads in OSM in the area I'm working
on do use the hyphen. As I add and validate the metadata, I am changing
that to a space. The boring janitor work is worth is in the long run.

- rob -

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

Re: [Tagging] roads with many names

On 8/18/19 12:42 PM, Martin Koppenhoefer wrote:

> names in OSM are usually in natural language, CR2 is probably what
> OpenStreetMap calls a ref, which is for numbers and alphanumeric
> codes. The other name is also looking like a code, I agree with
> Richard’s suggestion to use one name and 2 refs for your example.
  So no space ? USFS roads use "FS " with a space, at least that seems
to be common. So should those be "FS739.1A' ? I agree on one name and 2
refs. County road names in 'ref' and USFS names in 'ref:usfs'. I can see
I have a long editing session coming up...

  Another fun one is you can buy road signs on ebay, so another road in
that area was 'Aspen Road' according to the county, but the sign says
'Aspen Lane', cause it was in stock. :-) I made that an 'alt_name'.
After the fire was out, I had fun talking to the neighbors to try to
make sense of it all. My fire department would be so screwed without our
ability to improve our own maps.

- rob -

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

Re: [Tagging] roads with many names

On 8/18/19 12:24 PM, Paul Allen wrote:

> If the owner calls in a fire at his house, he's going to use his own
> wrong name for the road.  So you'd probably be best to have it as a loc_name, 
> then
> there's a chance of somebody other than you finding it.

  Luckily a neighbor called it in, he wasn't home. using 'loc_name' or
'alt_name' makes sense. This entire area doesn't even exist in Google
Maps, so people not using OSM couldn't find it till we gave directions
on the radio.

> with a note saying only one guy on the entire planet calls it that would work.

  Him and UPS. :-)

- rob -

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

Re: [Tagging] roads with many names

On 8/18/19 11:09 AM, Johnparis wrote:
> Normally it would be "ref:usfs" rather than "usfs:ref".

  Thanks, I just found the ref=* page. Also noticed 'loc_name' and
'nat_name', and it looks like those plus ref* are used for routing.
Anyway, I like the ref:usfs tag, and will use that, and ref= for the
county designation.

> And yes, the main ref for the cited road would be "ref=CR 2". Included
> spaces in a ref tag vary by local consensus. Some places might use
> "ref=CR2". If there are signs and they are consistent I'd use that.

  Since I usually validate by truck, I use whatever the street sign
says, since that's what the driver uses. A few weeks ago we were at a
structure fire and a local had put up his own road sign, but with the
wrong name! We decided to trust our map, which worked great. I had used
used the actual common name, and put the bad sign in a 'note'. Note
really sure how to handle that...

- rob -

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

Re: [Tagging] roads with many names

On 8/18/19 10:27 AM, Richard Fairhurst wrote:

> name=Corkscrew Gulch Road
> ref=CR 2
> usfs:ref=FS 729.2B

  Interesting, I didn't realize "usfs:ref" is a tag. I have used ref for
camp site numbers, didn't know it supported alphanumerics. I dug around,
and don't see usfs:ref being used, at least not anywhere in Colorado.

  I was wondering if using "alt_name" with ';' was a good idea. I guess
the issue for me is how it appears when searching in OsmAnd, which has
been the major gripe. I guess I can change a few obscure roads, and just
see how OsmAnd handles it.

  Where it gets interesting is for an incident on Corkscrew Gulch Road,
Dispatch often uses the USFS designation, cause the call may come from
the forest service. What name gets used depends on who you work for...
Not your problem, many thanks for the input.

> I think this holds even if the "county-designated name" is CR 2. The "name
> everyone uses" tallies with OSM standard practice; the official reference is
> what we have the ref tag for.

  Plus 'name' is usually what any mapping app will put on the display.
OSM has most all these roads already, they just have no tags beyond
"highway=track".

   Minor note to other mappers, we're big into 'smoothness', 'surface',
'tracktype', as we use those to help determine what type of apparatus to
respond in. I usually have to validate that by driving the road,
although the difference between 'bad' and 'very_bad' is very open to a
difference of opinion... (high clearance only is what I use for
very_bad) But anyway, thank you all for good metadata!

- rob -

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

Re: [Tagging] roads with many names

On 8/18/19 9:41 AM, Paul Allen wrote:

> Assuming that "CR 2" is a name and not a ref, one possibility that 
> springs to mind, and which will no doubt be highly controversial is

  Yes, it's county designated name. It's gets messier than that, as
sometimes "CR 2" might include multiple other road segments, all with
different names common and USFS names. We prefer the common name or the
USFS name, but I have no control over what Dispatch gives us.

> name=CR 2 / Corkscrew Gulch Road / FS 729.2B alt_name=CR 2; Corkscrew
> Gulch Road; FS 729.2B

> If you have several name or several ref, you can use the “;”
> separator
  Ah, I've used that elsewhere, didn't think about it for road names.
The problem though is since the name gets displayed, too many long road
names obscures the map. I've had similar problems with house addresses
in the more densely populated areas. When I produce a KML file from OSM
data, I put all the names in the description popup. That works in GPS
map apps, but not in OsmAnd. Plus I wonder if that would break routing...

- rob -

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

[Tagging] roads with many names

  Where I live in rural Colorado, many of the roads have 3 names. The
county designated one like "CR 2", but often have an alternate name
everyone uses like "Corkscrew Gulch Road", and then many have a US
Forest Service designation like "FS 729.2B". I usually use the common
name as the 'name' tag, and the USFS designation as the 'alt_name' tag.
I kindof would like to include the county name as well. I do see a lot
of roads use 'name_1', but that gets flagged often by validation. So my
question is, how to I tag all three road names appropriately ?

  As a fire-fighter, all 3 names get used all depending on there the
incident report comes from, so we need to know them all. Us old
responders of course know everywhere, but I'm trying to help the new
generation in our department be effective in our huge remote district,
cause we're all retiring...

  Minor note. All of our fire apparatus have a 10" Android tablet
mounted to the dash that runs OsmAnd (of course), and we use offline
navigation heavily, which is where the road names become important.
Using Open Data has decreased our response time, and on occasion, saved
somebody's life.

- rob -

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

Re: [Tagging] Route relations - Forward & Backward

2014-09-05 Thread Rob Nickerson

Dave,

My understanding is the same as yours. That is, I map them according to the
wiki guidelines:

> "Forward" means the route follows this way only in the direction of the
way, and "backward" means the route runs only against the direction of the
way.

Adding these roles to the members that make up the relation allow you to
have circular bus routes and know the direction of travel. It also allows
you to deal with splits in the road (e.g. a dual carriageway mapped as two
separate ways in OSM) or where the "out" and "in" just differ.

Having said that, the other mappers method also has all the information in
to figure out the route, just not sure if existing tools will cope with
that (I actually like including the way twice as this allows you to have
all the ways linking in JOSMs relation editor, but not sure if this is
frowned upon).

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

[Tagging] The "not-shops": industrial, industry, or business

2014-09-03 Thread Rob Nickerson

Thanks for the responses so far.

I'm not suggesting a business=tag_what_ever_you_like tag. In fact I only
really care about having a suitable key. I like business=* as this covers
everything, but you could say that business is used as a level 1 tag and
then level 2 tags would be shop=, craft=, office= plus the addition of
industrial= and commercial= for everything else.

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

[Tagging] The "not-shops": industrial, industry, or business

2014-09-02 Thread Rob Nickerson

Hi all,

Sometimes shop=*, office=* and craft=* do not adequately cover all business
types. For example, I have mapped an industrial area that includes the
following businesses:

1. A fork lift truck hire company (business to business sales).
2. A commercial bakery selling to business producing goods in their
premises and delivering them to the customer.
3. A audio equipment company selling and hiring equipment to professional
broadcast companies.

In all three cases shop=* doesn't seem right as these are business to
business sales (b2b) and are often delivered rather than picked up by the
customer.

I have found 3 alternate tags in use. Does anyone have a preference for me
to formalise as a proposal?

http://taginfo.openstreetmap.org/keys/industrial
http://taginfo.openstreetmap.org/keys/industry
http://taginfo.openstreetmap.org/keys/business

I quite like business as it captures everything from conference suites to
fork lift truck hire. Having said that, the industrial tag is most used and
has an existing proposal page (but this suggests the tag is used as a
refinement to the landuse=industrial tag):

http://wiki.openstreetmap.org/wiki/Proposed_features/industrial

Any preferences before I spend time to write a proposal page?

Regards,
Rob

p.s. The ultimate aim is to be able to add a tag so that we have clear data
in OSM (rather than just a name and address) and then file a request to get
the business name rendered as currently addr:housenumber is rendered in
preference to name (unless there is a tag such as craft/shop/office). This
is not a tagging for the render issue - we are missing a valuable tag to
describe the type of business.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forest vs Wood

2014-08-20 Thread Rob Nickerson

On 20 August 2014 18:45, Rob Nickerson  wrote:

>
> Wood: Woodland with no forestry
> Forest: Managed woodland or woodland plantation.
>
>
I think for me the wording isn't quite right. For me landuse=forest is
something that has been planted for the purpose of harvesting trees.
Therefore planting trees to prevent landslides, or to block road noise, or
to provide leisure is not a case of landuse=forest. Similarly simply
managing trees (even if by a national "Forestry Commission") for the
purpose of keeping an area safe to the public is not a case of
landuse=forest.

Perhaps a crop=tree tag would have made more sense than landuse=forest??

I quite like Imagico's idea (below). I think we should implement that and
then if in a year or so there is still a mess between landuse=forest and
natural=wood we should introduce a new tag (crop=trees which now provides
the overlay pattern) and treat landuse=forest and natural=wood as the same
thing.

"The orthogonality of natural=wood and landuse=forest SK53
<https://github.com/SK53> pointed out could be emphasized in rendering by
drawing only natural=wood as a solid color area and distinguish
landuse=forest with a different overlay pattern indicating the use for
forestry (some trees+piles of logs symbolism maybe)"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Forest vs Wood

2014-08-20 Thread Rob Nickerson

Hi,

Sorry to raise this issue again but it really does need resolving:

* for ensuring good data; and
* to prevent forest and wood being rendered as the same thing [1]

Currently the descriptions in the green box on the right of the wiki page
(and thus those that get picked up by taginfo and other software) are:

Wood: Woodland with no forestry
Forest: Managed woodland or woodland plantation.

In my eyes this is pretty clear. What am I missing / why does there seem to
be so much confusion?

Regards,
Rob

[1]
https://github.com/gravitystorm/openstreetmap-carto/issues/647#issuecomment-52756701
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] man_made=pipeline - is onewayness implied?

2014-06-20 Thread Rob Nickerson

There's no "onewayness" for natural gas pipelines. They may have a
prevailing direction, but the direction of flow is not determined by the
pipe. It's determined by the pressure differential (gas will flow from high
to low pressure) and this can be changed via use of compressor stations.

A natural gas pipeline should not be tagged as oneway.

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

Re: [Tagging] highway=track access

2014-05-30 Thread Rob Nickerson

Well highway=byway is a very UK specific thing so global renders and
routing won't pick it up. Its also not a legal thing in itself. The council
can provide the actual status. Where are these?

Also there is the suspected:designation=* tag if you're not sure.

R

On 30 May 2014 08:28, "Dave F."  wrote:

On 21/05/2014 23:28, Rob Nickerson wrote:
>
> >
> >Going slightly off topic, I notice the UK listing...
Hi Rob

I believe byway shouldn't be deprecated. In my area most of them are signed
as just 'byway' on the ground. There is no indication of their legal status
(BOATs etc), & AFAIA, there is no non copyrighted source for these. I think
many that have been tagged with designation=* have been sourced from OS
data.

Cheers
Dave F.

---
This email is free from viruses and malware because avast! Antivirus
protection is active.
http://www.avast.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=track access

2014-05-21 Thread Rob Nickerson

>
>Going slightly off topic, I notice the UK listing is missing byway, a
>recognised highway classification.
>
>Dave F.


Hi Dave,

The highway=byway tag is deprcated:
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbyway

The legal status of UK Rights of Way now belong in the "designation" tag,
and the highway is tagged with an appropriate value (mostly track, but
could be service if part of the route is now a paved road (e.g. an access
driveway to a property along the right of way):

http://wiki.openstreetmap.org/wiki/Public_rights_of_way_in_England_and_Wales#Byways

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

Re: [Tagging] Gritting routes

2014-03-25 Thread Rob Nickerson

> Craig said:
>
>What is the point in mapping roads where the gritter drives, if it is
>not gritting there? How is that useful for anyone?
>

In the UK any government data based on a map tends to be derived from the
national mapping agency and as such creates licence issues. We therefore
opt to use the gritting "route schedules". These are literally a list of
instructions in the form:

* Leave depot, turn Right
* GRIT to end of road, turn left
* TRAVEL to main street, turn left
* GRIT to ...

and so on...

I'm in two minds about whether to map the route as a relation, but I have
to follow the route on the map just to work out which roads are gritted and
which are not, so I may add it at the same time. Also if I add them to OSM
then I can demonstrate a benefit to the local council - they could use the
OSM data in a navigation device in the gritting trucks (thus ensuring that
the correct route is followed every time and that excess grit is not
wasted).

Regards,
Rob

p.s. For some context, whether a road is gritted or not is quite important
in the UK as we are lazy and don't tend to bother with winter tyres/chains
etc.. There is a fine balance between gritting more so that the roads are
kept moving (economic and safety benefit) and gritting less to reduce
direct costs and the corrosion/environmental cost of excess salt/grit.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Gritting routes

2014-03-23 Thread Rob Nickerson

Thanks,

Happy to ignore JOSMs error, but don't want to have someone else change my
route relation if it flags as a QA bug (hence posting here to gather
people's thoughts & ideas).

They're as stable as bus routes in my area as the local authority has to
ensure the correct roads are gritted and the best way to do this is to have
prearranged routes.

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

Re: [Tagging] Gritting routes

2014-03-23 Thread Rob Nickerson

In fact if I'm going to allow roads to appear twice in the relation then I
can just build a continous route with no gaps and do away with the forward:
and backward: bits altogether (just keeping 'grit' and 'travel' as my two
roles).

Rob

On 23 Mar 2014 22:07, "Rob Nickerson"  wrote:

Hi All,

I have some winter gritting/salting routes that I am trying to work out how
best to tag them. I was thinking of creating a route relation, but I may
need to add some new roles:

* "forward:grit" implies the gritting truck grits this road whilst
travelling in the direction of the way.
* "forward:travel" implies the gritting truck drives along the direction of
the way but does NOT grit it.

Is this ok?

I also have a concern that JOSM warns me if I try to add the same road way
to the route twice. For gritting routes this is necessary - for example,
grit Road A to roundabout, u-turn and travel back on Road A (but do not
grit). In this example Road A would have to be added to the relation twice
first as forward:grit and then as backward:travel.

Is it okay if I ignore JOSMs error in this case?

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

[Tagging] Gritting routes

2014-03-23 Thread Rob Nickerson

Hi All,

I have some winter gritting/salting routes that I am trying to work out how
best to tag them. I was thinking of creating a route relation, but I may
need to add some new roles:

* "forward:grit" implies the gritting truck grits this road whilst
travelling in the direction of the way.
* "forward:travel" implies the gritting truck drives along the direction of
the way but does NOT grit it.

Is this ok?

I also have a concern that JOSM warns me if I try to add the same road way
to the route twice. For gritting routes this is necessary - for example,
grit Road A to roundabout, u-turn and travel back on Road A (but do not
grit). In this example Road A would have to be added to the relation twice
first as forward:grit and then as backward:travel.

Is it okay if I ignore JOSMs error in this case?

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

[Tagging] Visual editor for the wiki (WAS: How to overcome lack of consensus)

2013-09-22 Thread Rob Nickerson

Quote:

I'm not sure I'd rush into
it, anyway. Even granted
that en.wikipedia
probably uses more complex
markup and templates than we
do, uptake of the
visual editor (among new
editors and otherwise)
doesn't seem very high, and
no one outside of the WMF
seems very impressed by its
current state of
development.

- End quote -

Well we are a little way off as this requires the next version of mediawiki
to be marked as stable (and then rolled out on our site) so plenty of time
to fix any bugs.

In regards to its usefullness it is worth considering the aim of our wiki.
Is it to help the community share knowledge or is it for something else? In
my opinion as long as the VisualEditor does not have show stopper bugs we
should aim to adopt it as soon as possible. The benefit to our community
(of many non wiki markup users) is substantial.

As always statistics on use welcome.

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

[Tagging] Visual editor for the wiki (WAS: How to overcome lack of consensus)

2013-09-17 Thread Rob Nickerson

Daniel wrote:

> - Make it easier to edit the wiki.


Hi Daniel,

I agree - the wiki can be hard to edit if you have never done this before.
This is why I requested a visual editor (that is now used by Wikipedia) to
be added. Unfortunately this requires an update to the version of MediaWiki
that we use so is not a simple case of installing a plug-in. Hopefully it
will be picked up sooner rather than later but in a volunteer based project
patience is essential :-)

https://trac.openstreetmap.org/ticket/4920

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

Re: [Tagging] Feature proposal - RFC - gross weight

2013-06-20 Thread Rob Nickerson

Hi,

I agree that the meaning is correct (legally), but I think we need to try
and simplify the jargon in the one line summary section. How about:

maxgross_weight: All vehicles have a registered upper limit on their
allowable mass (when fully loaded). This is often known as the "Gross
Weight", and it is found in the vehicle documentation. This tag indicates
the maximum value that can use the way irrespective of whether the vehicle
is fully loaded or not.

Obviously, keep the legal meaning, but add this (or similar) for people who
just want a quick answer.

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

Re: [Tagging] Through_route next steps

2013-06-16 Thread Rob Nickerson

>@Rob:
>Did you ever try to describe the junction with the Lane and Road
>Attributes?

No, I didn't. And as I've been busy with organising SOTM I didn't even
fully read the tag proposal (hence I didn't vote). I hope you agree that my
general comment about reading through and attempting to address the
critical points on the through_route proposal is the right way forward.
Yes, this may mean dropping the tag proposal altogether and working with a
different tag instead.

In my opinion, what the through_route tag was aiming to do is still a good
idea. I see it as more important for small unclassified country roads,
rather than multi-lane highways. Here in the UK many small historic rural
roads can have tight bends and often, if there is a connecting road, a
satnav will give an instruction to turn right/left when one is not in fact
needed (or not give an instruction when one is needed).

Best,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Through_route next steps

2013-06-15 Thread Rob Nickerson

Hi,

The next steps with any tag proposal that reaches a hung jury is to read
through the comments and update the proposal to address the issues raised.

In this case I think the wiki page needs to be clearer about what this tag
is for (a few photo/aerial image examples would help), and how it differs
from other tags.

Let me know if you want a helping hand.

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

Re: [Tagging] Clean up =milestone (WAS: pk vs kp on =milestone and default unit?)

2013-05-17 Thread Rob Nickerson

Hi,

I hadn't looked at the "milestone" wiki page before, assuming it referred
to (the now historic) actual stone distance markers. Looking at the page,
it seems to be used for modern signs. In the UK we have distance markers
along motorways (Driver Location Signs). An example can be seen here:

http://wiki.openstreetmap.org/wiki/Key:carriageway_ref

In the picture:

* M27 is the road reference (i.e. ref=M27)
* B indicates that you are travelling on the main carriageway _towards_ the
starting reference point of 0.0km (i.e. carriageway_ref=B)
* 2.8 is the distance from the starting reference point in km (this is
surely the "milestone" tag??)

Yes, that's in km despite being in the UK. I believe that's called EU
harmonisation :-)

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

Re: [Tagging] Feature Proposal - RFC - Tree Shrine

2013-03-29 Thread Rob Nickerson

I would like to see a tagging proposal that covers more general cases such
as trees planted in memory of someone (for example see
http://www.thenma.org.uk/ ). For this we would need tags describing when
the tree was panted, who it was planted by (if planted by a well known
person or charity), and who it is planted in memory of.

Regards,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Grades for obstacle=vegetation

2013-02-09 Thread Rob Nickerson

I'm not a fan of "garde1" ... "grade5". I always, always, always have to
look up the meanings when using it for track type (even though JOSM has a
drop down list, the meaning are not given within JOSM).

How about something like "light" (push back with hands, walk around),
"medium" (as with light but may require a little bit of climbing/stepping
over, and "heavy" (requires chopping tools to cut). Personally I think
anything requiring a saw or more time consuming tools should be separated
out in its own tag. However if you want to include it I suggest
"densely_overgrown".

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

Re: [Tagging] Feature Proposal - RFC - roller_coaster key

2013-01-10 Thread Rob Nickerson

Good start :-)

One point that jumps to mind: I would imagine that you will find the
"layer=*" tag to be better than "level=*".

All the best,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Restrictions based on the weight of a trailer

2012-12-04 Thread Rob Nickerson

How about:

overtaking:trailer:conditional=no @ (05:00-22:00 AND weight>0.75 )


The "access" wiki page lists "trailer=* (needs to be towed by another
vehicle which has its own restrictions)", which suggests that trailer
should be seen as a separate identity, thus "weight" applies to the trailer
only. Had the weight been the combination of vehicle plus trailer then we
may have needed to come up with something to describe this. One possibility
would be to borrow from [1], however this is a weight rating (set by the
manufacturer), rather than an actual weight.

Rob

http://en.wikipedia.org/wiki/Gross_combined_weight_rating
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of maxspeed:wet

2012-12-04 Thread Rob Nickerson

Quiet often if such a change is made ("does not deprecate" -> "recommend to
stop using") it is by someone other than the original proposal author.
Irrespective of this the proposal procedure is a RFC - Request For Change -
process. What it does is to say "hey guys, I think we should change this,
if you agree vote for it and update any systems you have that may be
effected". In this regard, I was pleased to see a proposal specifically for
changing tag recommendations:

http://wiki.openstreetmap.org/wiki/Proposed_features/drop_recommendation_for_place_name

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

Re: [Tagging] Status of maxspeed:wet

2012-12-03 Thread Rob Nickerson

The conditional access restrictions proposal did not specify that this :wet
tag suffix would be deprecated (in fact it stated quite the opposite). From
a developers point of view however, it is beneficial if we use a consistent
tagging scheme, which is what the conditional tag was designed to
introduce. I would therefore suggest switching to the new tagging scheme,
however I'll leave you to decide for yourself. As always the "anything is
better than nothing" rule applies in this situation.

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

[Tagging] Fwd: Door to door routing to buildings with multiple occupants

2012-11-30 Thread Rob Nickerson

-- Forwarding message from talk as more appropriate to tagging list
--

Hi,

A mapper who is new to my area is interested in mapping disabled access at
a micro level. Specifically he would like to achieve door-to-door mapping
for key shops and amenities, and has made a good start by adding entrance
doors to several buildings.

My Question:

Where should amenity=* and addr:*=* be tagged? One suggestion was to add
all the detail to the entrance node, but this seems odd to me. For single
occupancy buildings I suggested tagging the building as amenity=*, etc as
the entrance node on the building can be easily matched with these.

But what about a building with multiple occupants and entrances. For
example 2 shops in one building. One option is to tag the building with
building=yes and then add the amenity tags to individual nodes, but then
how would door to door routing work? An alternative is to just split the
building in to 2 areas (but technically its 1 building). Can we use some
form of indoor mapping (e.g. room=yes, amenity=*)?

Is there a better solution? All ideas welcome.

Regards,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating

2012-11-27 Thread Rob Nickerson

Hi martinq,

Good summary. We must have been working on it at the same time as I have
just copied the wiki discussion to [1] (and liberally edited it to break it
into sections and make it easier to follow). I suggest we keep discussions
to this mailing list and the maxweight talk page (where it is most
applicable).

The wiki definition, in my opinion, does not specify either way.

Rob

[1] http://wiki.openstreetmap.org/wiki/Talk:Key:maxweight
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating

2012-11-27 Thread Rob Nickerson

>Hi Rob,
>
>Am Montag, 26. November 2012, 20:33:08 schrieb Rob Nickerson:
>>* Conclusion - in the UK all weight limits are Gross Vehicle Weight 
>>Rating*>>* limits and thus maxweight=* and hgv:maxweight=* would be enough.*>
>except that maxweight does *not* limit the Gross Vehicle Weight Rating, but 
>the actual weight.
>
>Eckhart
>

If that was the case then all tags in the UK would be wrong. On the
wiki page (which is unedited since Nov 2010), there is no reference to
"actual" or "rating" weight. It does however state "a legal weight
limit" which in the UK is always a weight rating (as per the previous
emails).

If you genuinely have a need for distinguishing between actual weight
and manufacturers weight rating then could you use
"maxweight:type=GVWR" or similar?

Rob

[1] http://wiki.openstreetmap.org/wiki/Key:maxweight
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating

2012-11-26 Thread Rob Nickerson

I've just checked the UK road sign guidance too [1].

Section 5.15 (page 35 describes the sign with the image of a HGV and a
weight restriction number. It clearly states that this is a restriction for
"environmental reasons" (e.g. where roads are narrow and unsuitable for
large vehicles, or to protect residents from the nuisance caused by lorries
in residential streets) and is not used for "structural limits". It appears
that this is a Gross Vehicle Weight Rating (GVWR) from the sentence stating
that the limit applies even if unladen and below the weight.

Section 5.31 to 5.33 gives the other sign (the one with a weight limit that
applies to all vehicles). Again this is a maximum weight rating:
"Specifying gross vehicle weights makes enforcement simpler as it is
necessary only to check the vehicle’s plated weight against that on the
sign, eliminating the need for a vehicle to be taken to a weighbridge for
checking." Annoyingly this is complicated by the possible additional of a
bottom panel reading "Except empty vehicles".

Conclusion - in the UK all weight limits are Gross Vehicle Weight Rating
limits and thus maxweight=* and hgv:maxweight=* would be enough. The
"Except empty vehicles" is an interesting condition and could be tagged as
maxweight=18 + maxweight:conditional= no @ empty vehicle (or something
similar).

How does this compare to other countries?

Rob

[1]
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/4460/traffic-signs-manual-chapter-03.pdf
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating

2012-11-26 Thread Rob Nickerson

Thanks Eckhart,

I've just had a bit more time to have a look at different weights and found
the following terms:

1. *gross vehicle weight rating* (also *gross vehicle mass*, *GVWR*, *GVM*)
- This appears to be a maximum operating weight specified by the
manufacturer (hence a "rating") and includes the vehicle weight, cargo
weight and others (driver, passenger, fuel, etc..)

2. *gross combination weight rating* (also *Gross Combination Mass*
and *maximum
authorised mass*) - Same as the above plus the weight of a trailer.

3. gross weight - taking the literal meaning of both words, I interpret
this to mean weight before any deductions. To me this includes all the same
components of GVWR, but is an actual measurement, rather than a
manufacturers rating). To find this out you would have to drive onto a
weighbridge.

The question is, do the road signs mean actual weight or "weight rating"?
Given that example for the UK it is hard to say for sure. I will see if I
can find out. Does Germany's road signs specifically mean manufacturers
weight rating?

Rob


[1] http://en.wikipedia.org/wiki/Gross_vehicle_weight_rating
[2] http://en.wikipedia.org/wiki/Gross_combined_weight_rating
[3] http://www.answers.com/topic/gross-weight
http://en.wikipedia.org/wiki/Truck_scale
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating

2012-11-25 Thread Rob Nickerson

Hi,

In the UK I've spotted that some maximum weight road signs have just the
weight limit on the sign, whilst others also include a picture of a HGV.
I've only realised this difference recently and have not had time to
research the legal side of things but the brief description on the
Department for Transports website suggests the sign with the HGV only
applies to that type of vehicle. If this is indeed the case, can we simply
use the following (as appropriate):

* maxweight:hgv = *
* maxweight = *

Rob

p.s. These discussions don't seem specific to the conditional restrictions
tag scheme. Have you had a look on the talk page for maxweight, there are
some other interesting comments there!!
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?

On 16 October 2012 23:38, Eckhart Wörner  wrote:

> Hi Rob,
>
> (Putting tagging ML back in To since this might be of interest to other
> people as well, I hope you don't mind.)
>
> > On topic: In your suggestion you proposed "applies = *". What would you
> do
> > with the following:
> >
> > * day_on, etc...
> > * restriction:hgv, etc
> > * except
> >
> > Would you suggest deprecating them? Thus a restriction that applies to
> only
> > hgv's becomes:
> >
> > restriction = no_u_turn
> > applies = no (to switch it off for all transportation modes)
> > applies:hgv = yes (to switch it back on for HGVs)
>
> yeah, that's the idea. The implied default would be something like
> "applies=yes, applies:foot=no" so that by default, turn restrictions apply
> to everyone but pedestrians.
>
> The big advantage of using "applies" is that from a language POV it is
> immediately clear what is meant, and that the syntax will be *exactly* the
> same as in Conditional Restrictions.
>
> day_on, … should definitely get deprecated, those tags are an unholy mess:
> people mess up off and on; people interpret them them as both "from day A
> time B to day C time D" and "from time B to time D each day between day A
> and day C".
> except can probably stay, it can easily be translated (except=bus
> translates to applies:bus = no)
> restriction:hgv should get deprecated / reverted, someone recently sneaked
> this into the wiki page without any discussion.
>
> Eckhart
>

Hi,

No problem with you moving this back online (I wanted to check that I
wasn't putting words in your mouth first).

Thanks for the clarification. I spotted you had reverted some recent
changes (thanks) but wasn't aware that restriction:hgv was also a recent
addition. I think deprecating these would be step in the right direction
and removes many of the concerns I had with using a new tag (namely you end
up with "applies" type data within both "restriction:hgv = " and
"applies="/"condition="/whatever the new tag is called).

I suggest we write up a wiki page proposing the changes. That way we can
better track the discussion :-)

Rob

p.s The talk page for Turn Restrictions is stupidly long. Will take a while
to work through it to see if there are any helpful tips in there!
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?

I'm still not convinced that you need to introduce a new tag (be that
"applies" or "condition").

1. Although it is difficult to calculate how many turn restrictions have
some form of "condition", the numbers can't be that many in comparison to
normal restrictions that apply at all times. Adding the condition data to
the "restriction=*" tag therefore will not break the majority of
restrictions (they stay unchanged). Similarly adding the information in a
new tag will not break the majority of restrictions.
2. For those restrictions that do have conditional details, if:
  a) you add the details in "restriction = " you break the current tagging
and routing software will not know how to interpret it. The routing then
does not include the turn restriction (i.e. no restriction when you want
one), or if
  b) you add the condition to a new tag then the routing software does not
see it (i.e. you have a restriction when you don't want one).
Both cases need the routing software to be updated...
3. ...and that is exactly what a Request For Change (RFC) is for. It is as
the name suggests a communication with your users : "Hey guys, we want to
change this to make it better. What do you think? Great, can you update
your systems so that you are ready for the new tags"

As you see all proposed ideas will need the end users to change something.
And, in fact, as we currently don't have a way of including conditions, we
may already have incorrect turn restriction in OSM.

_Conclusion_: Whatever we do should keep the tagging as simple and easy to
understand as possible. As we already have some "applies" type information
in "restriction:hgv = no-u_turn", my gut instinct is to include all the
"applies" type info in this tag. Hence the example "*restriction:hgv =
no_u_turn @ (length > 6)*".

Regards,
Rob

p.s. Any change to day on, day off, hour on, hour off, will also break the
existing scheme (but is in my opinion worthwhile).
p.p.s. All my previous examples are fictional. More real world photos fully
appreciated.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?

> To draw the comparison with "Conditional Restrictions" the above tags
> cover of ,  and the tag value.
> There is no need to specify  as this is already captured in
> the relation (from, via, to).
I am not sure you can say this. It should work where the junction angles
are close to 90 degrees, but for a shallow "Y" junction things might
need a hint as to whether it is a curve to the right with a junction to
the left, or a curve to the left with a junction to the right...

Colin

- - -

Hi Colin,

Sorry, we're talking about 2 different things. I was making the comparison
with Conditional Restrictions which includes direction (forward or
backward). These values are not needed. Can I suggest that if you with to
discuss such values as no_slight_right_turn (or whatever), then you start a
new thread. It may also be worth looking back through the original proposal
for turn restrictions to see if any comments were made then.

Cheers,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Conditional restrictions accepted – turn restrictions ahead?

Hi Eckhart,

Your right, voting has come to an end for the Conditional Restrictions
proposal, which was approved. A statement was not made on this list as Ole
and I are working on how best to write the feature page so that some of the
concerns raised (about complexity / difficulty to understand) are reduced
as much as possible.

Like Martin, I'm not hugely convinced about the need for complicated turn
restrictions (most of the restrictions will be on the road and the detail
on the turn sign will simply be advanced warning for the driver). Having
said that, you have provided a few examples so I have looked into it:

  1. Currently we tag a no left turn restriction using "restriction =
no_left_turn".
  2. If we want this to apply only to HGVs then the key is changed so that
it become "restriction:hgv =no_left_turn".

To draw the comparison with "Conditional Restrictions" the above tags cover
of ,  and the tag value. There is no
need to specify  as this is already captured in the relation
(from, via, to). Therefore the only part left to add is the condition. At
the moment there are 2 ways to do this

  3. Using "except = *" (where * is a vehicle type). e.g. except = bicycle
  4. Using day on, day off, hour on, hour off

In summary we already have both "applies" type tags (1, 2 and 4) and
"except" type tags (3, and the inverse of 4!). My gut instinct is that
adding an "applies = *" tag would further complicate the issue.

In conclusion I would be in favour of adding the conditions directly to the
restriction or except tag (depending on how the road sign is written). Yes
this breaks backward compatibility but there are a lot less turn
restrictions in OSM than the other restrictions and if the conditions are
not met then the restrictions does not apply so it shouldn't really be
tagged anyway!

== Some Examples ==

 * Example 1: "no u-turn" restriction for HGVs longer than 6 metres:
 * restriction:hgv = no_u_turn @ (length > 6)

 * Example 2: no right turn Monday to Friday 8am to 4 pm:
 * restriction = no_right_turn @ (Mo-Fi 08:00-16:00)

 * Example 3: no left turn except PSV's on Monday to Friday 8am to 4 pm:
 * restriction = no_left_turn
 * except = psv @ (Mo-Fi 08:00-16:00)

This then depreciates the need for day on, etc... tags which I'm not a fan
of - I think it is better to tag what is on the sign e.g. (Mo-Fr
08:00-19:00).

Happy to hear your thoughts.

Rob

p.s. I think it would be nice to see a few more real world examples if
anyone has any photographs (or can remember the conditions).
p.p.s It would be nice to know how many routing software apps are using
these turn restriction relations.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Seasonnal roads

2012-10-10 Thread Rob Nickerson

>* For more details see [1]*>* and [2]. Essentially there is a hierarchy of 
>subcategories for*>* transportation modes.*>* [2] 
>http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png*
This scheme should be more wildly used. It seems to be use only in the
German wiki.

Eric

---

Hi Eric,

The scheme exists on all language pages of the access key, but the
German version includes the image that makes things a lot easier to
understand. I am including improving the key:access page as part of my
work on the conditional restrictions page. To anyone else who is
reading this and is now concerned, please rest assured that I will
consult on any chnages on this mailing list before making any changes.

Regards,
Rob

p.s. Feel free to add a comment to the seasonal=* wiki page. Something
of the form "you may also like to use" rather than "you should also
add this tag...". If you have any questions on how to edit the wiki,
let me know and I'll try to help out.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Seasonnal roads

*>One of the main mountain highways here is closed to licensed
vehicles*>during the winter months, but snowmobiles are permitted.
Would
>vehicle:conditional apply to snowmobiles?
>
>--
>Clifford


Hi Clifford,

"vehicle" does include snowmobiles. Essentially there is a hierarchy of
transportation modes that are explained at [1]. On the German language
version of this page there is a nice image explaining it [2]. So
"snowmobile" is in the "motor_vehicle" class, which itself is in the
"vehicle" class. Using vehicle:conditional would apply to everything within
the vehicle class (including all motor_vehicles and snowmobiles). You would
need to use:

* vehicle:conditional = no @ 
* snowmobile = yes

Here "snowmobile" is a more specific transportation mode than "vehicle" and
therefore overrules the conditional restriction. Replace  by those
winter months in which the restriction applies.

Regards,
Rob

[1] http://wiki.openstreetmap.org/wiki/Access#Transport_mode_restrictions
[2] http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Seasonnal roads

-- Éric wrote: --

For mountain pass in Alps, this could be just

access:conditional = no @ Nov-Apr

For African tracks, something like

smoothness:conditional = horrible @ May-Oct
smoothness:conditional = very_horrible @ Nov-Apr

or

smoothness = horrible
smoothness:conditional = very_horrible @ Nov-Apr


All with seasonal=yes to indicate the random aspect of the time condition.

Do you agree?

-- End --


That seems logical to me. One word on using "access:conditional" though -
this would indicate no access, including on foot. For more details see [1]
and [2]. Essentially there is a hierarchy of subcategories for
transportation modes.

Rob

[1] http://wiki.openstreetmap.org/wiki/Access#Transport_mode_restrictions
[2] http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Difficult passability

As noted some of these things change very quickly (I know some of the other
things you mentioned can and do change, but the frequency is a lot less).
The issue of then using these tags in a routing app / software is one a
staleness. Perhaps the router should not use them when deciding the best
route but should present them as route comments instead. As such the
notes=* tag or perhaps obstacle=* & danger=* would work well. These values
can then be any text rather than a set list of values.

Regards,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Seasonnal roads

 >Hi,
>
>I'm looking how to tag a road with seasonal opening or closing. ...
>Up to now, I was using "opening_hours=*" with "Nov-Apr off".

Hi Éric,

Have you tried: http://wiki.openstreetmap.org/wiki/Conditional_restrictions
Work is under way to help make the page clearer, but essentially your tag
would be:

* vehicle:conditional = no @ Nov-Apr

This would restrict bicycles as well so replace vehicle with motor_vehicle
is this is more appropriate.

Regards,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional Restrictions vs. Extended Conditions

2012-09-19 Thread Rob Nickerson

>Hi everybody,
>
>it probably comes as no surprise that I am against the Conditional 
>Restrictions proposal and in favor of the Extended Conditions proposal.
>My main reason is that I believe the Conditional Restrictions proposal is so 
>complicated it will kill mapping of those conditions almost completely, while 
>its benefits are only dubious.

== The following responses are not specific to this proposal only ==
I disagree that it will kill mapping of these features. I expect some
people are holding off mapping these until there is an accepted tag
schema (otherwise they may have to go back and waste time correcting
anything they do add once a schema is decided upon). As for the
complexity, I feel that the wiki page can be improved to help explain
the proposal better (for example by using colours like seen on an
alternate proposal [1], and adding some image examples).

Regards,
Rob

[1] http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_values
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

2012-09-19 Thread Rob Nickerson

-- Eckhart wrote --

Hi Rob,

Am Mittwoch, 19. September 2012, 18:08:30 schrieb Rob Nickerson:
>* Despite some of the perceived benefits of this proposal being challenged*>* 
>(mainly in regards to their relevance),*
Except for one claimed benefit, I did not question the relevance of
the claims, but their validity. Maybe you should read mails before
summarizing them?
-- End --

Hi Eckhart,

Please accept my apologies that my English was not clear. I did read
your mails and my wording should be seen as it was intended - that is,
the perceived benefits may not be "relevant" due to the "invalidity"
of the thing they are trying to fix. I will try to be more exact next
time.

Kindest regards,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

2012-09-19 Thread Rob Nickerson

Hi All,

Despite some of the perceived benefits of this proposal being challenged
(mainly in regards to their relevance), the overwhelming thing that was
clear was that this proposal was well thought out. Ole looked carefully at
the feedback that was given during previous proposals and worked to find
solutions for many of them.

There will never be a 100% perfect solution due to the fact that, in the
absence of a tag scheme, many alternate tags have crept into use. Despite
this I feel it is important to push ahead with a conditional restrictions
tagging scheme as it provides some form of standardisation and therefore
simplifies the task of downstream users (which ultimately will lead to more
use of OSM's fantastic data). To put this into some context, recall that
there was a discussion recently (on talk list I think), where it was made
clear that the German auto industry had asked OSM how we intend to "close
the gap" between us and commercial navigation.

As noted by Andy, I do however agree that this proposal (like many others)
could slip under the radar of many people. Due to it's potential reach, I
would have liked to have seen something posted to the Developer mailing
list during the Draft & RFC stages.

Kind Regards,
Rob

p.s. I know voting isn't popular, but it is one part of communications
(i.e. giving feedback) and I encourage you to reconsider it if you have so
far opted not to vote.

http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

2012-09-18 Thread Rob Nickerson

Dear List,

{This is a cross post - please reply to the tagging mailing list or the
proposals [2] talk page }

- - - Announcement - - -
Several attempts have in the past been made to develop a tagging scheme
that is capable of handling the more complex access restrictions (e.g. No
motor vehicles between 10am and 6pm except vehicles less than 5 meters
[1]). Voting has started on the latest proposal [2]. Due to the wide reach
of this proposal, I am announcing it here and encouraging users to
carefully consider the proposal and vote.

To help, I have summarised the alternate proposals (in alphabetic order and
including this one) [3]. Note that not all of these are in active
development. I have also attempted to write the case for and case against
this proposal.

As a reminder of terminology, a Tag consists of 'Key' and a 'Value' pair
(key=value). For example "maxspeed=80".


- - - Case "For" - - -
Extract by the proposal author from the proposal's wiki page [2]:

//start quote// This proposal overcomes some objections to previous
attempts at tagging conditional restrictions.

* No variable parts in the key. This is essential as keys are used to
search for data in the OSM database. If a key comprises a variable part it
can no longer be retrieved during search unless you know the exact
condition you are looking for (database searches do not allow wildcards in
search keys). Variable parts in keys will also lead to an undesired
proliferation of unique keys.

* Avoids the requirement for problematic characters in the key such as "<"
or ">"

* Clear distinction between scope (transportation mode, vehicle class) and
condition.

* Possibility to combine conditions using operators.

* The conditional restriction can be defined as a single tag. Some prior
proposals required multiple tags such as hour_on and hour_off tags. For
objects having multiple restrictions this could lead to problems (which
tags belong to which restriction?)

* The syntax of the key is essentially identical to the established access
key syntax with an additional qualifier ":conditional".

* Backward compatible. Doesn't break any established tagging schemes.
//end quote//


- - - Case "Against" - - -
Extracts from those who have currently (18/09/2012)  voted against the
proposal:

//start quotes//
* Breaks a lot of tags which came "natural" to the mappers, e.g.
maxspeed:wet=80 becomes maxspeed:conditional=80 @ wet, access:disabled=yes
becomes access:conditional=yes @ disabled, …

* Creates arbitrary distinctions: depending on whether something is defined
to be a transportation mode or a condition, it belongs either in the key or
in the value, e.g. "hgv" is a transportation mode, but "hazmat" is a
condition

* Has bad editor support: adding a conditional restriction like "speed
limited to 80 when wet" to a set of ways is quite complicated if there are
already different restrictions on those ways; merging :conditional tags in
JOSM by default produces a value that is completely wrong, yet cannot be
identified as wrong.

* It's to difficult for users, not intuitive. There are too many subkeys
and subvalues. I think value with logic instruction (AND) (and maybe
special/new signs (@)) are not good tagging rules.
//end quotes//


- - - How to Vote - - -
0. Take a moment to conside the pros/cons and their relative importance /
how would you do it differently?
1. Log-in to OSM wiki (as far as I know this is not your usual OSM
username/password.
2. Navigate to the proposal page [2]
3. Click edit (to the right of the "Voting" heading
4. Add "{{vote|yes}} --" or "{{vote|no}} --" after the existing
votes.



Kind Regards,
RobJN

[1] Example Signpost:
http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg
[2] The Proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions
[3] Summary of alternate proposals:
http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_access_tags
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Clarify tag access doc

2012-09-11 Thread Rob Nickerson

Although I don't know the history of the access tag, I would expect that
"designated" and "permissive" might have something to do with Public Rights
of Way in the UK:

* If a path is designated as a "Public Footpath" then you have a legal
right to walk on it and there is a legal structure protecting these and
dictating how the local government should keep a record of them.

* The public has a right to request a path be added to the list of "Public
Footpaths" if they can prove prior use (pre some date I can't remember). To
prevent this happening a landowner can optionally decide to make a
"Permissive Footpath". Again this has some legal consequences but to the
landowner it may be more appealing to have a permissive path over his land
rather than risk someone challenging him on the grounds that the path be
added as a "Public Footpath".

* Having said all this the UK guidelines are now to use
"designation=public_footpath" and no need for an 'access' tag. For
permissive paths I have seen both "foot=permissive" and
"designation=permissive_footpath"

Regards,
Rob

p.s. If it helps, I don't understand the access tag either!!
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extended tagging schema - my thoughts

 -- Tobias wrote: --

Have you seen the "Conditional restrictions" proposal that was linked
here yesterday?

http://wiki.osm.org/Proposed_features/Conditional_restrictions

It is basically the same idea. The most important difference is that it
uses a ":conditional" suffix. This makes it backwards compatible, unlike
your solution which would put things like "120; wet 80" into the
established maxspeed tag.

>  * maxspeed=120
>  * maxspeed:hgv=80

These would look the same with "Conditional restrictions".

>  * maxspeed=120; wet 80

This would become
maxspeed = 120
maxspeed:conditional = 80:wet

---

Thanks Tobias,

I had skim read it but must have missed the point as it is almost exactly
what I ended up with!! Credit to Ole and apologies - I really need to slow
down and read things properly.

Ole,

I wrote up my proposal [1] and it turned out almost exactly the same as
yours (if you include my point 2 in the "But Wait..." section). Feel free
to take any ideas you want. For example my syntax uses a whitespace to
separate condition from value, so "(Mo-Fr 07:00-17:00)" in your proposal
becomes a combined condition of "Mo-Fr&07:00-17:00" in mine.

One of the things I struggled with was the maxwight / length conditions. So
where you suggest "motor_vehicle:conditional=no:(10:00-18:00 AND
length>5)", I would have used "maxlength:motor_vehicle:e=unset; 10:00-18:00
5" - meaning no restriction is set except when between 10am and 6pm, in
which case a maxlength of 5m applies. I went for this as it didn't require
the > character.

As noted, feel free to take any parts of my proposal, or drop me an email
if you would like to discuss anything. For now my proposal is on hold, and
my support with you.

[1]
http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_access_tags
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extended tagging schema - my thoughts

Thanks both,

I will look into options for better maintaining compatibility. One possible
solution would be to prefix extended tag keys with "e:" for a transitional
period. I'm not a big fan of this as it is messy. The problem is sometimes
you just have to make big changes even if this breaks compatibility. The
better OSM data users will take steps to adapt their software. Cruel but
things do change.

I decided to throw some ides out there after the earlier proposal failed to
gain approval in its first vote. I think it is key to get this sorted out -
only just the other day it was confirmed on the osmf mailing list that the
auto industry has asked how OSM plans to "close the gap" between OSM and
commercial navigation mapping.

Regards,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extended tagging schema - my thoughts

Eckhart wrote:

>* > - you lose backward compatibility*>* *>* The proposal falls back to 
>existing tag schemas therefore providing*>* backwards compatability.*
No, it doesn't. If you set maxspeed=120; wet 80, then none of the
existing routing programs can use this tag anymore. The Extended
Conditions proposal uses the tagging maxspeed=120, maxspeed:wet=80,
which allows existing routing programs to still use the maxspeed key.

>* > - you run into the (real) risk of exceeding the 255 byte limit imposed on 
>values*>* *>* That would have to be one hell of a complicated access rule!!*
Oh, you haven't seen anything. German inner city pedestrian zones are
infamous for complex access restrictions (taking into account
bicycles, delivery traffic, destination traffic, taxis, all of them
depending on the day of week and the time of the day, and sometimes
even on the direction).

Eckhart

-

Apologies. What was meant was that software need only cut off the
extended values to return to existing systems (and thus
compatibility). For example "maxspeed=120; wet 80" is chopped down to
"maxspeed=120
". As there are lots of tags in use, it will be tricky to find a
schema that is both liked and does not break a single thing.

As for 255 bytes. All vehicles have their own tag, so would be tricky
to hit 255 bytes.

Regards,
Rob

p.s. I am trying to suggest an alternative that does not put all the
conditions in the tag key (as this was one of the big criticisms).
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Extended tagging schema - my thoughts