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)
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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,
41 matches
Mail list logo
