Re: [Tagging] Feature Proposal - RFC - Fire lookouts

2020-11-10 Thread Rob Savoye
On 11/10/20 2:16 PM, Jake Low wrote:

> This proposal suggests introducing two new tag values: building=fire_lookout 
> to indicate that a building is or was originally built to be a fire lookout, 
> and emergency=fire_lookout to indicate that a feature (usually a building=* 
> or man_made=tower) is used for fire spotting.

  Fire lookouts towers are unfortunately being shut down all over the
place these days. But this brings up an interesting point. Many rural
fire departments have "lookout locations", often used for smoke
sightings. We have several in my district that get used heavily, never
though about tagging them as anything but a nice view. Basically these
are high places you can get to easily and get clear compass bearings on
the smoke plume. We get many smoke sightings from illegal campfires, so
use these locations frequently. When you're driving around in the
forest, you can't see anything, so two bearings lets us triangulate a
rough GPS location, and have everyone go there.

  I don't have a suggestion on tagging, sorry, but sometimes these
locations have parking, sometimes it's a short hike uphill. So consider
something more flexible.

- rob -
-- 
Senior Tech Lead
Humanitarian OpenStreetMap Team
https://www.hotosm.org

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


Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

2020-10-28 Thread Rob Savoye
On 10/28/20 8:28 AM, Jonathon Rossi wrote:
> Apologies for bringing dedicated reserved parking into the thread since
> that is the only experience or interpretation I had. I think parking is
> a worthwhile tag and I'd use emergency=parking for that, but let's get
> back to your topic since it sounds more complex.

  Around here there are special parking areas for emergency vehicles but
they're only used at crowded trailheads, or busy commercial shopping
areas. We try to never park next to a burning building. :-) Where we
park a large fire truck is up to the responders, and is based on a
variety of criteria that aren't always obvious until you arrive, like an
ability to turn a big vehicle around... Also areas near buildings often
have other obstacles, like dumpsters, bike racks, etc...

  The cleared areas near buildings we think of as fire-mitigation zones.
ie.. Zone 0 is within 2m of the building, Zone 1 is more like 15m,
etc... While we might park there sometimes, we usually park out on the
main road as it's safer. Running a few hundred meters of hose is common.
I'm not 100% sure on the best tagging other than maybe parking=yes and
access=emergency is appropriate.

- rob -
-- 
Senior Tech Lead
Humanitarian OpenStreetMap Team
https://www.hotosm.org

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


Re: [Tagging] Large fire perimeter tagging?

2020-09-24 Thread Rob Savoye
On 9/24/20 4:07 PM, stevea wrote:
> On Sep 24, 2020, at 2:53 PM, Joseph Eisenberg  
> wrote:
>> Most large wildfires do not burn the canopy (the tallest trees) in forests 
>> with trees over 10 meters in height.

  I'd disagree, and I'm probably the only one on this list who works
active wildland fires. We call these "crown fires", and the fire jumps
from tree top to tree top. The fire I was recently deployed to burned
*everything*, and I have pictures...

>> The perimeter of the wildfire, shown commonly on public maps, does not 
>> determine which areas have been burned. Often there are large areas of 
>> vegetation along canyon bottoms and streambeds which are unburned, within 
>> the perimeter.
> 
> Something I already DID know, also noted, thank you.

  Yes, the "burned area" is patchy. Lots of green parts, as well as spot
fires far from the main perimeter.

>> Database users who need these perimeters should download the latest version 
>> from the official sources. 
> 
> Yes, AND OSM users who map in areas affected by the fire want (likely need) 
> fire perimeter data to delineate where substantial "re-mapping" almost 
> certainly must take place.

  You can get the official real-time data for fire perimeters in the US
from here:
https://data-nifc.opendata.arcgis.com/datasets/wildfire-perimeters

  I have to add these manually and generate my own PBF file for OsmAnd,
but it works. I do agree the perimeter is probably not worth uploading
to OSM, so I don't worry about the tagging.

- rob -
-- 
Senior Tech Lead
Humanitarian OpenStreetMap Team
https://www.hotosm.org

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


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

2020-07-27 Thread Rob Savoye
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

2020-07-27 Thread Rob Savoye
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

2020-07-27 Thread Rob Savoye
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

2020-07-27 Thread Rob Savoye
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

2020-07-27 Thread Rob Savoye
 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


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

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

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

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

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

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

2019-08-21 Thread Rob Savoye
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 ?

2019-08-21 Thread Rob Savoye
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 ?

2019-08-21 Thread Rob Savoye
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 ?

2019-08-21 Thread Rob Savoye
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 ?

2019-08-21 Thread Rob Savoye
  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

2019-08-18 Thread Rob Savoye
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

2019-08-18 Thread Rob Savoye
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

2019-08-18 Thread Rob Savoye
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

2019-08-18 Thread Rob Savoye
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

2019-08-18 Thread Rob Savoye
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

2019-08-18 Thread Rob Savoye
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

2019-08-18 Thread Rob Savoye
  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