Re: [Talk-us] National Forest boundaries

[Bradley White]

> A relation for all would be ok too, as long as the private inholdings are
> not removed from the NF (which I think has been done in some cases).

I've argued for this in the past on this mailing list, but have since
come around to disagreeing with this position over tagging semantics.
Most NF boundaries are now tagged with 'boundary=protected_area', in
which case the boundary should represent physical land that the NF
actually owns and manages, and not the congressionally-declared
boundary. In my area, half of the city of Reno and nearly all of
Truckee fall within an congress-declared/administrative NF boundary -
these areas are certainly not protected.

IMO, a tagging scheme that better represents the meaning of these two
boundaries would be:
1. 'boundary=protected_area' around fee simple NF land ownership,
since this describes the actual protected areas of land
2. 'boundary=administrative' (with a not-yet-existing 'admin_level')
around declared NF boundaries, since this is an administrative
boundary for the NF and doesn't necessarily show what land is actually
managed by the NF.

We should even consider not including congressionally-declared
boundaries, since they aren't even theoretically verifiable on the
ground, and really don't necessarily indicate any kind of protection
of the land within the boundary. Fee simple ownership is at least
usually ground-verifiable with small yellow "NF boundary" placards.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling county roads (Idaho)

[Mark Wagner]

On Sun, 21 Jun 2020 21:45:19 +0900
tj-osmw...@lowsnr.net wrote:

> Newby here.
> 
> Started mapping an area of the Idaho panhandle around the Kootenai
> river. I notice that currently minor roads have a "County Road nn"
> name but TIGER2019 data also has names such as "Acacia Avenue". I
> think most map users would want to use the "Acacia Avenue" name as it
> what would be listed in postal addresses and they'd want to search it
> in applications such as OSMand. Question is how to handle this. Also,
> what to set the "ref" to for county roads.
> 
> There's not much information on the roads tagging page:
> 
> https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Individual_states_2
> 
> Proposal: use alt_name for "County Road nn" and name for "Acacia
> Avenue" where a name is given. (I've seen name_1 used but this is not
> really a "standard" OSM tag, AFAIK.)
> 
> For ref: set the ref to the county road number until someone can come
> up with a better proposal...
> 
> Any Idahoans have any information?

Not an Idahoan, but I've driven in the area from time to time.  The
roads I'm familiar with don't have a "County Road" designation on the
sign, just the road name.

-- 
Mark

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries (Mike Thompson)

[stevea]

On Jun 21, 2020, at 5:58 PM, Mike Thompson  wrote:
> 1) Not all "inholdings" are completely surrounded by the National Forest, 
> they are "bites" off the edge in some cases.  I don't think one can have an 
> inner ring and an outer ring which are at all coincident (they can't share an 
> edge) and still have a valid multipolygon.

I don't wish to sound dismissive as it seems we largely agree, but this is 
merely quibbling over constructing an outer edge.  If truly a "bite off the 
edge," then it seems the outer polygon should shrink to accommodate, no need 
for edge mumbo-jumbo (though sometimes these edge memberships take on a tagging 
life of their own and it gets to be a high-wire act as to how "loaded with 
tags" each one might become).  There are a lot of methods to capture semantics 
using syntax that is crisp and unambiguous, I believe some methods are smarter 
(less or even no ambiguity about the semantics that are "meant") and cleaner 
(fewer data) than others.  There is what might be characterized as "a wide zoo 
of tagging in these realms" (nationally at the enormous polygon scope).  Thank 
you (again) to Kevin for the word "menagerie" here.  This also enters what some 
have dubbed "higher math" (multipolygon edge tagging in a relational database 
and how deep these semantics can be relied upon are a "topology of deep genus").

> 2) Holes (inner rings) are not part of the polygon.  Thus if one did an 
> analysis of (for example) a series of points, any points that fall in one of 
> the holes would not register as being inside the multipolygon, even though 
> they are inside the outer ring.

That sounds right.

And a snappy-efficient way to achieve what is "truly excluded as PRIVATE" as an 
inner member of an "outer polygon that describes geographic extents of this 
PUBLIC forest" is by simply tagging what IS the inner member with "what it is." 
 That might seem fancy word salad, so I want to break down what we say as 
understandable to both of us.

We're using the double-duty that in a public forest (with a large, enclosing 
geography, but no larger than necessary or truly) which is tagged as outer 
role, anything we tag inner role is EXCLUDED from the public forest.  That 
"inholding," in every sense I've ever seen it, is private, hence, it's an inner 
to the outer, as private isn't public and vice versa.  The logic of opposites, 
the power of roles (inner and outer) in a relational database and the geography 
(in 2-space) of what we "mean" (quite intentionally) by inner and outer become 
powerful.  Let's simply tag the "thing inside, different from its enclosing 
polygon and so excluded from that polygon" for what it is, then include it as 
an inner member of the relation.  We do this, the logic of "nodes registering 
or not" is already built into "the space."  Think of a grassland in 
otherwise-land-filled-with-trees, it's a (mathematical) "hole" (of the 2-space, 
lat-long of nodes OSM lives in).  It simply works, like math, geography, 
software.

(Um, "well written" software!)

Meet you off list?

Steve
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries (Mike Thompson)

[Mike Thompson]

Steve,

Perhaps I am not understanding what you are saying, but:

1) Not all "inholdings" are completely surrounded by the National Forest,
they are "bites" off the edge in some cases.  I don't think one can have an
inner ring and an outer ring which are at all coincident (they can't share
an edge) and still have a valid multipolygon.
2) Holes (inner rings) are not part of the polygon.  Thus if one did an
analysis of (for example) a series of points, any points that fall in one
of the holes would not register as being inside the multipolygon, even
though they are inside the outer ring.

Mike

On Sun, Jun 21, 2020 at 6:39 PM stevea  wrote:

> Continuing from my previous post, we even have an especially data-compact
> (efficient) way of representing that:  the member of the forest relation
> which is an inholding (tagged with role inner) IS the polygon of, say, a
> private residence "inside of" the forest.
>
> For example (I'm making this up), say we have a national forest with a
> small shopping area (for food, supplies...) near its center for
> convenience.  I could see one polygon (tagged landuse=retail, name=ABC
> Forest Shopping Center) both BEING exactly that, AND being included in the
> (enclosing) forest multipolygon as a member tagged "inner."  Voilà,
> double-duty and done.
>
> SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries (Mike Thompson)

[stevea]

Continuing from my previous post, we even have an especially data-compact 
(efficient) way of representing that:  the member of the forest relation which 
is an inholding (tagged with role inner) IS the polygon of, say, a private 
residence "inside of" the forest.

For example (I'm making this up), say we have a national forest with a small 
shopping area (for food, supplies...) near its center for convenience.  I could 
see one polygon (tagged landuse=retail, name=ABC Forest Shopping Center) both 
BEING exactly that, AND being included in the (enclosing) forest multipolygon 
as a member tagged "inner."  Voilà, double-duty and done.

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries (Mike Thompson)

[stevea]

Mike Thompson  wrote:
> One polygon for the administrative boundary of the NF which was established 
> by Congress.
> Zero or more polygons describing limitations on access (no need for polygons 
> to for access=yes, we can assume that in a NF generally), whether they be due 
> to private ownership, or other reasons.  
> The above are two separate concepts, so it is ok to have two separate OSM 
> elements, in my opinion.   
> A relation for all would be ok too, as long as the private inholdings are not 
> removed from the NF (which I think has been done in some cases).

If I'm not mistaken, we already have the machinery to do that with how we build 
multipolygons.  To wit, a single multipolygon (well tagged as to name of 
national forest, protect_class=6, ownership=national...representing the forest) 
has one or more polygons with role "outer" where all those tags apply and one 
or more polygons with role "inner" where there are inholdings and "something 
else, not national forest" are, and the tags on this multipolygon do NOT apply. 
 (These appear as "holes" in the usual way inner members do in a multipolygon).

There is nothing stopping us (and sometimes we do) from adding additional 
polygons that are "coincident with the holes" which represent "what that 
particular inholding is."  It seems to me THOSE are the places where any access 
tagging (if necessary) might apply, should your fancy run to tagging those 
specificities.

We've been tagging "large public areas with inholdings" like this (using 
multipolygons with inner members) for as long as OSM has had multipolygons.  
Why might we (re-)establish "two separate concepts" in two separate data 
structures when we already achieve this with one data structure (and possibly 
others, by that I mean "one multipolygon representing the forest, which might 
have inner members," while noting that ADDITIONAL polygons can describe what 
the inholdings ARE and superimpose on top of the holes represented by the inner 
members?  Am I missing something?

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Mike Thompson]

On Sun, Jun 21, 2020 at 5:45 PM stevea  wrote:
>
> A large thank-you to Kevin for that deeply informative post.
>
> > brad  wrote:
> > I think its simpler and better to just create an inner boundary as was
done with the Coconino NF
>
> The Coconio NF (relation/10956348) hasn't "an" inner boundary, it has
hundreds of them.  I'm not sure I understand what Brad is saying is
"simpler and better" here, as a well-constructed multipolygon in OSM is "a
well-constructed multipolygon in OSM."  We already know how to do that so I
don't think we want to develop something else to represent the same thing.
>
> Is Brad or Mike proposing something else, like two multipolygons to
describe one national forest?
One polygon for the administrative boundary of the NF which was established
by Congress.
Zero or more polygons describing limitations on access (no need for
polygons to for access=yes, we can assume that in a NF generally), whether
they be due to private ownership, or other reasons.
The above are two separate concepts, so it is ok to have two separate OSM
elements, in my opinion.
A relation for all would be ok too, as long as the private inholdings are
not removed from the NF (which I think has been done in some cases).

Mike
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[stevea]

A large thank-you to Kevin for that deeply informative post.

> brad  wrote:
> I think its simpler and better to just create an inner boundary as was done 
> with the Coconino NF

The Coconio NF (relation/10956348) hasn't "an" inner boundary, it has hundreds 
of them.  I'm not sure I understand what Brad is saying is "simpler and better" 
here, as a well-constructed multipolygon in OSM is "a well-constructed 
multipolygon in OSM."  We already know how to do that so I don't think we want 
to develop something else to represent the same thing.

Is Brad or Mike proposing something else, like two multipolygons to describe 
one national forest?  I'd be against that (unless I hear and understand more).  
Perhaps Brad can tell the list what he thinks is "simpler and better" in the 
context of a well-defined multipolygon with one or more outer members, one or 
more inner members (as we've established) and then what he might propose?  
There is something intriguing with how Mike worded it ("separate polygons for 
inholdings, tagged with access=private and possibly ownership=private") which 
is certainly novel, and I'm willing to listen to that, but I don't quite 
understand what he means.  Two relations for one forest?  Our wider tagging 
practices don't (currently) understand this (two relations, one entity), nor do 
any renderers (that I know of), but this sort of access/ownership tagging on a 
separate polygon is an idea that might allow us to pack semantics into a 
relation (or two relations?) in a way I haven't thought of before.  Kind of 
pie-in-the-sky, but I'll listen, provided I fully understand what is being 
proposed.

We've established there are "more simply described" national forests where 
more-or-less "only" (or substantially only) the outer polygon is a member of 
the relation, and "very well described" national forests with highly complex 
memberships (perhaps multiple outer polygons, and numbering into the hundreds 
of inner elements, like Coconio).  OSM (in my opinion) has room to accept both, 
knowing that while the latter is much more complete, the former might be either 
a case of "very few if any inholdings, so essentially 'done'" or it might be "a 
rough sketch of (only) the outer polygon member to get the relation started, 
more inner polygon memberships need to be added to this relation."  And that's 
OK, but if / as we do so, let's make note of it (perhaps a FIXME tag in the 
relation with value "Incomplete; needs more inner members to describe the full 
gamut of all inholdings in this forest.")

SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Mike Thompson]

On Sat, Jun 20, 2020 at 6:31 PM Joseph Eisenberg 
wrote:
>
> > I was thinking just create separate polygons for inholdings, tagged
with access=private and possibly ownership=private
>
> While many Americans like to put "no trespassing" signs on their private
property, a privately owned parcel is not access=private unless there are
signs on the roads and paths leading into it which say so.
I don't know enough to know whether you can be prosecuted for trespassing
if it isn't posted, but if the owner shows up and asks you to leave, you
are compelled to leave.  Not too big of a deal if you are just passing
through, but if you have set up camp, it could be a hassle (particularly if
late). In any event, I don't want an encounter with a landowner due to my
trespassing, posted or not.


> Many privately-owned parcels in the national forests are used for forestry
> only, and there is no issue with crossing through on a road or trail in
> many cases.
>
Not true here in northern Colorado.  There are lots of small inholdings,
some with year round residences, some with seasonal cabins, and some that
people use for their RVs.  There is probably not an issue with passing
through on an established trail or road, but if one is travelling cross
country, aka bushwacking, it could be an issue. I also did recently
encounter private property while on an established trail  (the owner had
posted no trespassing signs). I wish I had known that ahead of time.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] National Forest boundaries

[Paul White]

*Sorry, forgot to send this to the mailing list...*

Thanks for the input. However, doesn't that violate "one feature, one OSM
element" ?
 I
believe we should stick with the inholding method, because separating
national forests into different relations complicates search features,
rendering, etc.

For most users, the proclamation boundary would be pretty useless if
ownership is already there. As Kevin noted, the proclamation boundary shows
an area that the government has been authorized to acquire land, and has
little impact on actual protection and land cover.

I'm glad to hear everyone's opinions and insight on this issue!

On Sun, Jun 21, 2020 at 2:15 PM Paul White  wrote:

> Thanks for the input. However, doesn't that violate "one feature, one OSM
> element" ?
>  I
> believe we should stick with the inholding method, because separating
> national forests into different relations complicates search features,
> rendering, etc.
>
> For most users, the proclamation boundary would be pretty useless if
> ownership is already there. As Kevin noted, the proclamation boundary shows
> an area that the government has been authorized to acquire land, and has
> little impact on actual protection and land cover.
>
> I'm glad to hear everyone's opinions and insight on this issue!
>
> On Sun, Jun 21, 2020 at 1:43 PM Adam Franco  wrote:
>
>> Three years ago I updated the tagging and relations
>>  of the Green Mountain
>> National Forest  in
>> Vermont after some discussion in the Tagging list (start
>> ,
>> after
>> 
>> some comments from Kevin).  What I ended up doing is setting the outer
>> "proclamation boundary" as one relation
>>  tagged with 
>> boundary=national_park +
>> boundary_type=protected_area + protect_class=6 and the actual parcels
>> are a separate relation 
>> tagged with boundary=protected_area + protect_class=6 (and
>> leisure=nature_reserve for rendering -- not sure if that is still
>> needed). Wilderness and recreation areas within the National Forest are not
>> members of the main parcel relation, but instead are their own
>> ways/relations with tagging that indicates the higher level of protection
>> in them such as protect_class=1b for wilderness areas (examples: Joseph
>> Battell Wilderness ,  Big
>> Branch Wilderness ) and
>> protect_class=5 for recreation areas (example: Moosalamoo National
>> Recreation Area ).
>>
>> I can't say that this tagging is necessarily correct, but it has proven
>> to be pretty useful in a few ways:
>>
>>1. The "proclamation boundary" is a big area that provides an
>>appropriate name on low-zoom maps.
>>2. Having the parcel relation (with cut-outs for in-holdings) is
>>super useful when exploring the forest and wanting to be aware of the
>>potential for no-trespassing signage.
>>
>> I haven't looked at other National Forests in depth, but some in CO (like 
>> Roosevelt
>> National Forest  and Pike
>> National Forest ) are
>> just one big relation with boundary=national_park +
>> boundary_type=protected_area + protect_class=6  and no separate parcel
>> relations. If the actual outer "proclamation boundary" matches the main
>> extent of the parcels that is probably much simpler. In the case of the
>> Green Mountain National Forest the "proclamation boundary" almost never
>> matches the outer edge of the parcels, but covers a much wider area --
>> hence mapping both.
>>
>> Hope this helps!
>> Adam
>>
>> On Sat, Jun 20, 2020 at 11:08 PM brad  wrote:
>>
>>>
>>> On 6/20/20 6:19 PM, Mike Thompson wrote:
>>>
>>>
>>>
>>> On Sat, Jun 20, 2020 at 5:45 PM stevea 
>>> wrote:
>>> >
>>> > I think we need both as well.  I've been doing this while watching the
>>> evolution of how we best do this as I participate in a "do our best, always
>>> better" efforts to accomplish this.  Even now!
>>> >
>>> > The idea of the first kind is simply a relation with a focus on the /
>>> a polygon with the outer (-most) membership.  The idea of the second kind
>>> is one of these plus a carefully crafted inner membership, often made up of
>>> a complex inholding distribution containing many sometimes complex
>>> themselves inner polygons.
>>> Thanks Steve for your insightful comments.
>>>
>>> I was thinking just create separate polygons for inholdings, tagged with
>>> 

Re: [Talk-us] National Forest boundaries

[Adam Franco]

Three years ago I updated the tagging and relations
 of the Green Mountain
National Forest  in Vermont
after some discussion in the Tagging list (start
,
after

some comments from Kevin).  What I ended up doing is setting the outer
"proclamation boundary" as one relation
 tagged with
boundary=national_park +
boundary_type=protected_area + protect_class=6 and the actual parcels are a
separate relation  tagged
with boundary=protected_area + protect_class=6 (and leisure=nature_reserve
for rendering -- not sure if that is still needed). Wilderness and
recreation areas within the National Forest are not members of the main
parcel relation, but instead are their own ways/relations with tagging that
indicates the higher level of protection in them such as protect_class=1b
for wilderness areas (examples: Joseph Battell Wilderness
,  Big Branch Wilderness
) and protect_class=5 for
recreation areas (example: Moosalamoo National Recreation Area
).

I can't say that this tagging is necessarily correct, but it has proven to
be pretty useful in a few ways:

   1. The "proclamation boundary" is a big area that provides an
   appropriate name on low-zoom maps.
   2. Having the parcel relation (with cut-outs for in-holdings) is super
   useful when exploring the forest and wanting to be aware of the potential
   for no-trespassing signage.

I haven't looked at other National Forests in depth, but some in CO
(like Roosevelt
National Forest  and Pike
National Forest ) are just
one big relation with boundary=national_park + boundary_type=protected_area
+ protect_class=6  and no separate parcel relations. If the actual outer
"proclamation boundary" matches the main extent of the parcels that is
probably much simpler. In the case of the Green Mountain National Forest
the "proclamation boundary" almost never matches the outer edge of the
parcels, but covers a much wider area -- hence mapping both.

Hope this helps!
Adam

On Sat, Jun 20, 2020 at 11:08 PM brad  wrote:

>
> On 6/20/20 6:19 PM, Mike Thompson wrote:
>
>
>
> On Sat, Jun 20, 2020 at 5:45 PM stevea  wrote:
> >
> > I think we need both as well.  I've been doing this while watching the
> evolution of how we best do this as I participate in a "do our best, always
> better" efforts to accomplish this.  Even now!
> >
> > The idea of the first kind is simply a relation with a focus on the / a
> polygon with the outer (-most) membership.  The idea of the second kind is
> one of these plus a carefully crafted inner membership, often made up of a
> complex inholding distribution containing many sometimes complex themselves
> inner polygons.
> Thanks Steve for your insightful comments.
>
> I was thinking just create separate polygons for inholdings, tagged with
> access=private and possibly ownership=private
>
> Mike
>
> I think its simpler and better to just create an inner boundary as was
> done with the Coconino NF
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling county roads (Idaho)

[Kevin Kenny]

On Sun, Jun 21, 2020 at 9:31 AM  wrote:
> Started mapping an area of the Idaho panhandle around the Kootenai
> river. I notice that currently minor roads have a "County Road nn" name
> but TIGER2019 data also has names such as "Acacia Avenue". I think most
> map users would want to use the "Acacia Avenue" name as it what would be
> listed in postal addresses and they'd want to search it in applications
> such as OSMand. Question is how to handle this. Also, what to set the
> "ref" to for county roads.

Not an Idahoan, so take this with a grain of salt.  Does Idaho
actually have numbered county highways other than the grid streets?
(Many Western states do not.)

Most states' practice will set the 'ref' to something like 'CR 23',

It's unnecessary to have a name like 'County Road 23'. In fact, if you
do have such a name, a lot of routing software will announce, 'turn
right on CR 23, County Road 23'. If the road has no other name, add
the tag `noname=yes` to silence warnings about a tertiary highway
without a name.

Please, create a route relation for each road with a reference.
Include in the relation all the road segments that make up the route.
Minimal attributes for the relation would be `type=route route=road
network=US:ID:Boundary ref=29A` for Boundary County Road 29A. The
corresponding street segment would have `highway=tertiary
name="Chokecherry Drive" ref="CR 29A"`, and it would ideally have
attributes like surface, maxspeed, lanes,  Having the relation
provides the data model with a way to group all the way segments;
roads get split all the time when people decide to map small bridges,
or when speed limits or lane counts changed, and so on.



-- 
73 de ke9tv/2, Kevin

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Labeling county roads (Idaho)

[Clifford Snow]

Be cautious using TIGER data in rural areas. I suspect many of the small
counties don't have the resources to send updates to Census. I'd recommend
looking at county and state data sources for accurate road names.

Best,
Clifford

On Sun, Jun 21, 2020 at 6:29 AM  wrote:

>
> Newby here.
>
> Started mapping an area of the Idaho panhandle around the Kootenai
> river. I notice that currently minor roads have a "County Road nn" name
> but TIGER2019 data also has names such as "Acacia Avenue". I think most
> map users would want to use the "Acacia Avenue" name as it what would be
> listed in postal addresses and they'd want to search it in applications
> such as OSMand. Question is how to handle this. Also, what to set the
> "ref" to for county roads.
>
> There's not much information on the roads tagging page:
>
>
> https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Individual_states_2
>
> Proposal: use alt_name for "County Road nn" and name for "Acacia Avenue"
> where a name is given. (I've seen name_1 used but this is not really a
> "standard" OSM tag, AFAIK.)
>
> For ref: set the ref to the county road number until someone can come up
> with a better proposal...
>
> Any Idahoans have any information?
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Labeling county roads (Idaho)

[tj-osmwiki]

Newby here.

Started mapping an area of the Idaho panhandle around the Kootenai
river. I notice that currently minor roads have a "County Road nn" name
but TIGER2019 data also has names such as "Acacia Avenue". I think most
map users would want to use the "Acacia Avenue" name as it what would be
listed in postal addresses and they'd want to search it in applications
such as OSMand. Question is how to handle this. Also, what to set the
"ref" to for county roads.

There's not much information on the roads tagging page:

https://wiki.openstreetmap.org/wiki/United_States_roads_tagging#Individual_states_2

Proposal: use alt_name for "County Road nn" and name for "Acacia Avenue"
where a name is given. (I've seen name_1 used but this is not really a
"standard" OSM tag, AFAIK.)

For ref: set the ref to the county road number until someone can come up
with a better proposal...

Any Idahoans have any information?

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] weeklyOSM #517 2020-06-09-2020-06-15

[weeklyteam]

The weekly round-up of OSM news, issue # 517,
is now available online in English, giving as always a summary of a lot of 
things happening in the openstreetmap world:

 https://www.weeklyosm.eu/en/archives/13289/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us