Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Warin]

On 18/08/19 16:39, Joseph Eisenberg wrote:

"Crop is a produce"

What does that mean?

The word "crop" in British English means " a cultivated plant that is
grown on a large scale commercially, especially a cereal, fruit, or
vegetable. (Oxford); or "a plant such as a grain, fruit, or vegetable
grown in large amounts" (Cambridge).

Plants are not produce, "produce" is the thing that a plant produces,
in OSM: "Describes a feature's agricultural output..." - so the word
"crop" is not appropriate, because "crop" is not the agricultural
output of an area of farmland, but a category.


'Crop' Look at the values used for crop crop=coconut, crop=wheat, 
crop=hay etc. All of the reasonable ones are also 'produce'. 
 (Unreasonable ones such as 'market gardening are not crops so fail as 
produce too.) Look at the OSM description: Crop: "The crop produced by 
cultivated land." That would not be the plant but the output? And it 
does not match the BE definition? 'Produce'  Englishdictionary as nounis 
defined by the Oxford English Dictionary as "Agricultural and other 
natural products collectively." In OSM description: Describes a 
feature's agricultural output produced though a natural process of 
growing or breeding. The BE and OSM meanings are a much closer match for 
'produce' where as they differ for 'crop'.




But I see that there is some desire for a tag for generic cropland, or
farmland used to grow unspecified crops. For this I would suggest the
key "farmland=cropland" or "crop=field_cropland", rather than crop=yes
(less specific) or produce=crop (unclear).

https://taginfo.openstreetmap.org/keys/farmland
https://taginfo.openstreetmap.org/tags/crop=field_cropland

Warin, if you do decide to use any of these tags, please document them
at a Tag: page or in your userspace or a proposal, if you have the
time.


There are many values for the key crop that lack documentation. 
crop=field_cropland being one, I think that describes the landuse not the 
output.

Another one that looks to me to be very bad is 'market_gardening'.

As these are 'common' yet lack documentation there is a need for them to be 
documented by those that support them. Joseph?





Joseph

On 8/18/19, Warin <61sundow...@gmail.com> wrote:

Cannot farm land can be used for crops for some time, and then milk
cattle for some other period of time?
IIRC that is what one of my relatives did.


? Anyone care to comment?




On 18/08/19 11:20, Leif Rasmussen wrote:

But isn't that the definition of farmland in OSM? I would map meadows,
farmyards, and orchards with their respective tags, not with
landuse=farmland.
Leif R

On Sat, Aug 17, 2019 at 7:18 PM Joseph Eisenberg
mailto:joseph.eisenb...@gmail.com>> wrote:

 Produce=crop would be worse, because “crop” is not a type of
 produce, and produce= is only very rarely used for crop land (
 crop= is the established key for types of crops like rice,
 sugarcane, wheat, etc)


The rate of present usage does not limit the use of a tag.
colour=#93006B 
is only used once in the data base ..
height=16 metres is only used once in the data base...

Crop is a produce.
produce=crop has 2 uses .. presently.
I have been mapping a small area where my family farmed for several
generations ... tomorrow there will be a lot more produce=crop.
If the judgement is simply on frequency of use the result may well be
wrong.




 As I mentioned on the Talk:Key:crop page, I suspect that this tag
 crop=yes is sometimes used to say “this area of farmland is used
 as crop land”, that is, to grow row crops like
 grains/sugarcane/other annuals. So at least we know it probably
 isn’t a meadow or a farmyard or an orchard?


Vineyards have their own tag, should the tag crop=grapes be removed?


 Joseph

 On Sun, Aug 18, 2019 at 7:44 AM Warin <61sundow...@gmail.com
 > wrote:


 Would produce=crop be better?
 As produce could be fish, cattle, sheep, wool, or crops.
 produce=crop would say that only crops are produced here.



 On 18/08/19 01:27, Martin Koppenhoefer wrote:
 >
 > sent from a phone
 >
 >> On 17. Aug 2019, at 17:09, Mateusz Konieczny
 mailto:matkoni...@tutanota.com>> wrote:
 >>
 >> 9326 of 9657 crop=yes is on landuse=farmland - it seems to
 me that it is
 >> not adding any information whatsoever.
 >
 > certainly removing them would be even less useful? You could
 read it as a way of stating that something is purposefully
 grown there. Someone else might refine it later ...
 >
 > Cheers Martin
 > __



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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Sarah Hoffmann]

On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote:
> Peter Elderson wrote:
> > I would like to see this software in operation! Could you give me the 
> > links of some applications 
> 
> I use my code in the backend of cycle.travel. It's not open source. I've
> seen code used by one other OSM-based site and there's a further one that's
> clearly using something similar. There are at least two really obvious
> strategies for dealing with relations like this.
> 
> > The point is, as it is it's not good enough for data use besides 
> > rendering. you can't rely on route relations for anything but rendering
> 
> Once again: pretty much every OSM-based bike router uses route relations to
> influence routing. (That might give you a clue to one of the strategies.)

But this is a task which is essentially the same rendering. You only need
to know what routes are on a certain way segment and use that information
to adjust the weights for the road. Even if you do something fancy like
ensuring that you remain of the same cycling route, it still comes down to
using the relation information as a property of the ways. Our route relations
are well suited for that.

The problems come in if you want to go the other way. When you start with the
relation, want to determine where the route goes along. That information is
simply not contained in the route relations as long as you don't impose a
couple of restrictions. Sure, you can apply a couple of heuristics and get
a reasonably good result for most of the routes. But it remains guess-work.

I have no issue if relations require reasonable processing to get to a result
but I would like to see enough information encoded in the route relation that
the processing invariably gets me to the result that the mapper intended.
I consider sorting and the use of roles essential for that.

Sarah

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[ael]

On Sat, Aug 17, 2019 at 10:46:45PM +0200, Martin Koppenhoefer wrote:
> 
> > On 17. Aug 2019, at 22:36, ael  wrote:
> > 
> > But do we have any generic terms already? Unless
> > you just mean office.
> 
> 
> businesses can already be found in amenity (e.g. food and drink, pharmacies, 
> post offices, prisons (US), etc.), tourism, leisure, shop, craft, office, 
> healthcare and probably more.

I think those are "species" of businesses, rather than generic. I guess
a slight mismatch with our understanding of semantics.

Of course, the more specific tagging is right where there is a good
match. 

ael


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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 11:53, ael  wrote:
> 
> Of course, the more specific tagging is right where there is a good
> match.


+1, and where there isn’t yet a good match I’d prefer to invent one.


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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 08:39, Joseph Eisenberg  
> wrote:
> 
> For this I would suggest the
> key "farmland=cropland" or


ok


> "crop=field_cropland",


not ok IMHO, field cropland is a kind if field, not a kind of crop


> rather than crop=yes


to me this isn’t perfect (yes isn’t a crop), but it is in line with 
building=yes (yes isn’t a building typology either)



> (less specific) or produce=crop (unclear).


+1, produce=crop doesn’t seem reasonable


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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Paul Allen]

On Sun, 18 Aug 2019 at 07:40, Joseph Eisenberg 
wrote:

>
> But I see that there is some desire for a tag for generic cropland, or
> farmland used to grow unspecified crops. For this I would suggest the
> key "farmland=cropland" or "crop=field_cropland", rather than crop=yes
> (less specific) or produce=crop (unclear).
>

Before we get to the details of how we're going to tag it, we need to be
clear on what
"it" is.

Modern agricultural techniques (mainly the use of fertilizers, whether
natural or
artificial) permit monoculture, where a single type of crop is grown in the
same
field, year after year.  This we can map with crop=* (or crop=yes or
whatever
replaces it when we know a monoculture crop is grown but we don't know
what it is, although that seems unlikely).

However, it is still fairly common to use crop rotation where different
crops are grown
in different years, or even two different crops in the same year.
See https://en.wikipedia.org/wiki/Crop_rotation  One crop in the rotation
may be
grass, harvested for silage to later be fed to animals.  In some cases a
field
in a crop rotation may be used as pasture for a year to directly feed
animals.
Land in crop rotation may be left fallow for a year, with no crop.  OTOH,
where the land is very uneven then it might be used for nothing but pasture
(sheep or goats are the usual "crop" on land like that).

Maybe we need crop=rotation rather than crop=yes.  I suspect we need both.
Not
necessarily as the tag crop=yes if everyone thinks there's a better tag,
but we need to
cover "this is used to grow crops in some sort of rotation" and "this is
used to grow
crops but I can't figure out what type from this distance and I don't know
if it's
monoculture or rotation."

Or maybe we should restrict ourself to mapping it as farmland because, in
general,
we don't know what a farmer is going to do with a given field from year to
year.  There
are specific cases where we're fairly sure a field is used for monoculture
and we
have specific tags for those: orchard, vineyard, etc.  But, in general,
just because I
see oilseed rape in a field this year that doesn't mean it's going to be
oilseed
rape next year (it usually isn't, around here).

I should also point out that many farms around here devote some or all of
their land
to tourism.  Is that crop=tourist?  Where the tourists pitch their tents or
park their
caravans is a camp site, but some of the farmland may be left for tourists
to
use recreationally (aka the farmer having given up on farming completely
because it's no longer economic).

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Paul Allen]

On Sun, 18 Aug 2019 at 10:01, Sarah Hoffmann  wrote:

>
> I have no issue if relations require reasonable processing to get to a
> result
> but I would like to see enough information encoded in the route relation
> that
> the processing invariably gets me to the result that the mapper intended.
> I consider sorting and the use of roles essential for that.
>

So far we've only been talking of hiking/walking routes where some feel
sorting is
beneficial and others feel it is unnecessary.  At the risk of derailing the
thread,
there are other types of route relation.

Take bus routes.  I know of a very complicated bus route.  At three times
along the
route it drives into a cul-de-sac, reverses into a side-road of that
cul-de-sac, then
goes back the way it came.  Those three places are not termini, they are
merely
points along the route where most of the passengers remain on board.  In
one part of the route it does a loop-the-loop, going around four sides of a
square.
It traverses other segments of the route twice, in the same direction,
approximately
30 minutes apart.  Oh, and it does the reversing-turn trick in another
place that
isn't a cul-de-sac, it just doesn't go any further along that road.

It is perfectly possible to render the route.  Trying to figure out the
steps in the route
from the rendered route is pretty much impossible, although detailed
inspection of
the one-way markings eliminates several possibilities.  We don't (as far as
I know)
have any tool comparable to uMap that would allow ordinary users to step
through
the route so they can comprehend the details, although splitting the route
into sub-relations would allow uMap to give a crude approximation of that
capability.  But one day such a tool might appear, at which point having
the route
sorted would be beneficial.

Here is the route:
https://www.openstreetmap.org/relation/8592409#map=14/52.0860/-4.6643
Good luck figuring out where it goes, even though the list of ways is (I
think) correctly
sorted.  On the public transport layer you wouldn't even get the list of
ways unless you
queried the route.

So maybe sorting isn't absolutely necessary, but it can make life easier.
Maybe
we shouldn't ever insist that mappers sort the routes they add, but I don't
think
we should discourage them if they want to put in that effort.  Especially
if, one day,
somebody comes up with a step-by-step tool for displaying routes.

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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 14:10, Paul Allen  wrote:
> 
> Land in crop rotation may be left fallow for a year, with no crop.  OTOH,
> where the land is very uneven then it might be used for nothing but pasture
> (sheep or goats are the usual "crop" on land like that).


+1, also where the soil is very meager (?) it may not be worth to plant crops 
and will be only used for extensive pasture



> 
> Maybe we need crop=rotation rather than crop=yes.  I suspect we need both. 



I’d prefer a new property crop_rotation=yes rather than using the crop key for 
something that isn’t a crop type.



> Not
> necessarily as the tag crop=yes if everyone thinks there's a better tag, but 
> we need to
> cover "this is used to grow crops in some sort of rotation" and "this is used 
> to grow
> crops but I can't figure out what type from this distance and I don't know if 
> it's
> monoculture or rotation."


+1

By the way, maybe fields used for “organic” agriculture could get another new 
property as well?



> 
> Or maybe we should restrict ourself to mapping it as farmland because, in 
> general,
> we don't know what a farmer is going to do with a given field from year to 
> year. 


this is what you can always do, and what you should do if you don’t know the 
specifics, although from a survey (or even from detailed aerial imagery) even a 
city dweller would usually be able to distinguish at least pasture from crops 
(if she passes there at the right time).


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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 14:43, Paul Allen  wrote:
> 
> Maybe
> we shouldn't ever insist that mappers sort the routes they add, but I don't 
> think
> we should discourage them if they want to put in that effort. 


+1, this is my opinion as well. Sorted routes make it usually easier for other 
mappers to do modifications and to see if the route has gaps


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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Paul Allen]

On Sun, 18 Aug 2019 at 14:13, Martin Koppenhoefer 
wrote:

this is what you can always do, and what you should do if you don’t know
> the specifics, although from a survey (or even from detailed aerial
> imagery) even a city dweller would usually be able to distinguish at least
> pasture from crops (if she passes there at the right time).
>

It is often possible to see a random speckle of white blobs and infer those
are sheep.  The
problem is that farmers move sheep from one field to another after they've
eaten all
the grass in one field.  So absence of white blobs does not mean the field
is not used
for pasture.  And, as I already mentioned, that field may be used for
pasture only one
year in four as part of crop rotation.

Thinking about it, maybe we should reactivate landuse=pasture and add
landuse=arable.  See https://en.wikipedia.org/wiki/Arable_land which makes
the
distinction between pasture, arable land, and land for permanent woody crops
(orchard, vineyards, rubber plantation, nut trees, etc.)  We already have
tags for
many of the woody crops, so adding pasture and arable would fit in well and
wouldn't require us to change the crop=* every year because of crop
rotation.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Kevin,

The proposal looks pretty good.

When you've finished editing, please make a clear list off all the
new, proposed tags, in one place. Also please clarify what pages are
being edited and if protect_class=* is being deprecated by this
proposal.

It might make sense to deprecate all values of protect_class other
than 1 to 6, since those numbers at least correspond to the IUCN
numbers and most are fairly commonly used, while the higher numbers
are rare and confusing. Over time, if protection_class becomes much
more popular, the protect_class:1 to 6 might also become obsolete, but
for the short term it might be difficult to change them all right
away.

One thing is that you write in one place that
protection_class=condition should maybe just be
protection_class=hazard, to replace the current protect_class=15 and
16, "Location Condition" and "Longtime Hazard Area". I think this
makes sense.

Re: protect_class=24, "Political protection", you might need to talk
to the folks in Brazil who are using this tag. Not all of them were
happy with using boundary=aborignal_lands instead, if I recall
correctly, but perhaps this could change.

Thanks for working on this. I think it's worth doing, since most of
the protect_class values have never really become used, and their
meaning is not very clear.

On 8/18/19, Kevin Kenny  wrote:
> .As has already been discussed at some length in the thread on tagging
> of State Parks in the US, I've been working on a proposal for a
> 'protection_class=*' key to replace 'protect_class=*'. It replaces the
> seven numeric codes from IUCN (plus a zoo of codes that OSM appears to
> have cut out of whole cloth) with 'protection_object=*', whose values
> are drawn from a group of word-oriented codes that, it is hoped, will
> be more mnemonic. (The proposal to describe State Parks as protected
> areas was reasonably well received except for the issue that it
> depended on the numeric 'protect_class=*' to describe the protection.)
>
> The proposal has now reached a state where I think it can be opened
> for a formal RFC, and can be found at
> https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas
> .
>
> Of course, I'll monitor both this list and the talk page for the Wiki
> page for comments, and try to address whatever comes up.
> --
> 73 de ke9tv/2, Kevin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Joseph Eisenberg]

landuse=meadow is also used for pasture, as mentioned on it's wiki
page and description. Since it's not always obvious if grass is going
to be grazed or cut for hay, it would often be difficult to tell the
difference.

I normally only use landuse=farmland for cropland, since the other
times of agricultural land have more specific tags: landuse=farmyard
for animal pens, barns, paddocks etc, landuse=orchard for orchards and
plantations, landuse=vineyard for grape vines, landuse=meadow for
pasture and meadow, landuse=aquaculture. Those tags cover everything
except cropland, and fallow farmland, I think.

On 8/18/19, Paul Allen  wrote:
> On Sun, 18 Aug 2019 at 14:13, Martin Koppenhoefer 
> wrote:
>
> this is what you can always do, and what you should do if you don’t know
>> the specifics, although from a survey (or even from detailed aerial
>> imagery) even a city dweller would usually be able to distinguish at
>> least
>> pasture from crops (if she passes there at the right time).
>>
>
> It is often possible to see a random speckle of white blobs and infer those
> are sheep.  The
> problem is that farmers move sheep from one field to another after they've
> eaten all
> the grass in one field.  So absence of white blobs does not mean the field
> is not used
> for pasture.  And, as I already mentioned, that field may be used for
> pasture only one
> year in four as part of crop rotation.
>
> Thinking about it, maybe we should reactivate landuse=pasture and add
> landuse=arable.  See https://en.wikipedia.org/wiki/Arable_land which makes
> the
> distinction between pasture, arable land, and land for permanent woody
> crops
> (orchard, vineyards, rubber plantation, nut trees, etc.)  We already have
> tags for
> many of the woody crops, so adding pasture and arable would fit in well and
> wouldn't require us to change the crop=* every year because of crop
> rotation.
>
> --
> Paul
>

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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Paul Allen]

On Sun, 18 Aug 2019 at 14:52, Joseph Eisenberg 
wrote:

> landuse=meadow is also used for pasture, as mentioned on it's wiki
> page and description. Since it's not always obvious if grass is going
> to be grazed or cut for hay, it would often be difficult to tell the
> difference.
>

I didn't spot meadow.  Sure, that's fine.

I normally only use landuse=farmland for cropland, since the other
> times of agricultural land have more specific tags: landuse=farmyard
> for animal pens, barns, paddocks etc, landuse=orchard for orchards and
> plantations, landuse=vineyard for grape vines, landuse=meadow for
> pasture and meadow, landuse=aquaculture. Those tags cover everything
> except cropland, and fallow farmland, I think.
>

So how about landuse=arable for cropland and only have crop=* where the
mapper is certain it's monoculture and what the crop is?  Maybe
landuse=fallow
too, although I'm not certain that is useful.  That leaves landuse=farmland
for the situation where you're sure it's used for farming but can't tell
from
aerial imagery if it's meadow or arable or strawberries or...

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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 15:41, Paul Allen  wrote:
> 
> Thinking about it, maybe we should reactivate landuse=pasture and add
> landuse=arable.  See https://en.wikipedia.org/wiki/Arable_land which makes the
> distinction between pasture, arable land, and land for permanent woody crops
> (orchard, vineyards, rubber plantation, nut trees, etc.)  We already have 
> tags for
> many of the woody crops, so adding pasture and arable would fit in well and
> wouldn't require us to change the crop=* every year because of crop rotation.



rather than retagging everything we could have farmland=pasture and 
farmland=crops (or “arable”, but crops might be easier to understand)


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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Joseph Eisenberg]

It's unlikely that a synonym of landuse=farmland will be accepted by
most mappers. That's why I suggested using something like
landuse=farmland + farmland=cropland - the key farmland=* is already
used (though not in a very consistent or helpful way). Or cropland=yes
would also work fine.

For fallow fields, there is already a tag fallow=yes which has been
used in a few places. I'm thinking of starting to use this for fields
in my area that have been left fallow for more than 1 year, but still
are clearly areas of farmland and not yet overgrown with scrub.

On 8/18/19, Paul Allen  wrote:
> On Sun, 18 Aug 2019 at 14:52, Joseph Eisenberg 
> wrote:
>
>> landuse=meadow is also used for pasture, as mentioned on it's wiki
>> page and description. Since it's not always obvious if grass is going
>> to be grazed or cut for hay, it would often be difficult to tell the
>> difference.
>>
>
> I didn't spot meadow.  Sure, that's fine.
>
> I normally only use landuse=farmland for cropland, since the other
>> times of agricultural land have more specific tags: landuse=farmyard
>> for animal pens, barns, paddocks etc, landuse=orchard for orchards and
>> plantations, landuse=vineyard for grape vines, landuse=meadow for
>> pasture and meadow, landuse=aquaculture. Those tags cover everything
>> except cropland, and fallow farmland, I think.
>>
>
> So how about landuse=arable for cropland and only have crop=* where the
> mapper is certain it's monoculture and what the crop is?  Maybe
> landuse=fallow
> too, although I'm not certain that is useful.  That leaves landuse=farmland
> for the situation where you're sure it's used for farming but can't tell
> from
> aerial imagery if it's meadow or arable or strawberries or...
>
> --
> Paul
>

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

[Tagging] roads with many names

[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

Re: [Tagging] roads with many names

[Paul Allen]

On Sun, 18 Aug 2019 at 16:17, Rob Savoye  wrote:

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

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

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

Ugly and probably breaks many explicit and implicit rules.  You'll no doubt
find out
all the ways it is a bad idea very shortly.

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

Re: [Tagging] roads with many names

[Julien djakk]

Hello Rob !

If you have several name or several ref, you can use the “;” separator

Julien “djakk”


Le dim. 18 août 2019 à 17:17, Rob Savoye  a écrit :

>   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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Richard Fairhurst]

Sarah Hoffman wrote:
> On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote:
> > Peter Elderson wrote:
> > > The point is, as it is it's not good enough for data use besides 
> > > rendering. you can't rely on route relations for anything but
> rendering
> > 
> > Once again: pretty much every OSM-based bike router uses route relations
> to
> > influence routing. (That might give you a clue to one of the
> strategies.)
> 
> But this is a task which is essentially the same rendering. 

I was addressing Peter's point that route relations can only be used for
rendering, which is demonstrably false - they're used for influencing
weighting in routing.

> The problems come in if you want to go the other way. When you start with 
> the relation, want to determine where the route goes along. That
> information 
> is simply not contained in the route relations as long as you don't impose
> a
> couple of restrictions. [...]
> I consider sorting and the use of roles essential for that.

I'd fully agree on roles. The use of 'alternate' and 'forward'/'reverse'
roles for bike route relations dates back to the earliest days of bike route
mapping in OSM and is well established by now.

But just as long established in OSM is the principle that - since mappers
are our most precious resource - we optimise for the mapper, not for ease of
consumption. Allowing relations to be unsorted is an example of that. If a
relation represents a linear route, it's a SMOP to put the ways in the right
order. 

There are two obvious strategies. 1 is: create an empty polyline P with
endpoints P1 and P2; iterate through the relation members; every time you
encounter a way with an endpoint P1 or P2, add it to the polyline
(potentially in reverse order) and remove it from consideration; repeat
until there are no ways left. This is broadly the approach I've used until
now.

2 is more involved but more fault-tolerant and flexible; create a routing
graph, then route from the relation's startpoint to its endpoint using a
very heavy uplift for members of this relation. This is a useful approach
where the route actually _is_ non-contiguous but you nonetheless want to
include connecting routes between the sections. (Quite a lot of American
rail-trails are like this, as are several UK National Cycle Network routes.)
This is an approach I'm investigating at present.

Approach 1 does of course fail if the relation doesn't represent a single
linear route. That would, however, still be true if the route was ordered.
There's probably a little more that editing software can do here, but unless
you want to require people to have 12 months of OSM experience before they
can map a change to their local cycle route, ultimately the solution is to
have better QA tools. Something like OSM Relation Analyser is faultless
algorithmically but the UI is less than immediate. If we were to have an OSM
Inspector-like view of lacunae, spurs and other relation issues, it would be
a whole lot easier to fix them. I occasionally wonder about coding this but
I'd love it if someone were to beat me to it.

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] roads with many names

[Joseph Eisenberg]

It looks like "CR 2" is a "ref" rather than a name, and so is FS
729.2B. A ref=, short for "reference number" (or more properly
"reference alphanumeric string") is a set of letters and numbers that
identifies a feature.

While it's best to have the common name in the tag name=, like
name=Corkscrew Gulch Road, it's okay to have more than one ref in the
tag ref, separated by semicolons. Many database users can handle this.
Eg:

name=Corkscrew Gulch Road
ref=CR 2;FS 729.2B

If there are other, less common actual names, consider using
alt_name=* or loc_name=* (local, informal names), but in this case it
looks like there is just one name, but multiple reference numbers.

Joseph

On 8/19/19, Rob Savoye  wrote:
> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[Richard Fairhurst]

Rob Savoye wrote:
> 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". 

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

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.

Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] roads with many names

[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

[Johnparis]

Normally it would be "ref:usfs" rather than "usfs:ref".

I frequently use tags like "ref:FR:STIF" where STIF is an agreed tag within
FR (France).

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.





On Sun, Aug 18, 2019, 18:53 Rob Savoye  wrote:

> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[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

[Paul Allen]

On Sun, 18 Aug 2019 at 18:29, Rob Savoye  wrote:

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

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.

OTOH, if you want to make sure mappers know it's not the name of the road
no matter
what that guy says, then not:name=*.

Having it as both a loc_name and a not:name feels wrong, but a loc_name
with a note
saying only one guy on the entire planet calls it that would work.

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

Re: [Tagging] roads with many names

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 17:41, Paul Allen  wrote:
> 
> Ugly and probably breaks many explicit and implicit rules.  You'll no doubt 
> find out
> all the ways it is a bad idea very shortly.



for several names it is common to use variations of the name tag, like alt_name 
reg_name etc.

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

Re: [Tagging] roads with many names

[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

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 20:36, Rob Savoye  wrote:
> 
> 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.


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.


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

Re: [Tagging] roads with many names

[Paul Allen]

On Sun, 18 Aug 2019 at 19:33, Martin Koppenhoefer 
wrote:

>
>
> for several names it is common to use variations of the name tag, like
> alt_name reg_name etc.
>

Yep.  And in many cases those, along with loc_name, may be the best way to
handle it.  But
only name (and ref, if used) get rendered by some carto systems.  In the
situation described,
it might be useful to abuse/misuse name a little.  Technically, name=A;B is
valid, but
semi-colons can be hard to make out, so name = A / B might be preferred by
some (and
castigated by others).  Repeating those names with alt_name=A;B means that
some
search facilities will be able to locate both names.

I think I have a comparable situation in my town.  I've yet to investigate
more fully, but it
appears there are a couple of residential roads where the official address
for houses
on one side is A Street and for houses on the other side is B Avenue.  Yes,
I know about
name:left and name:right, but they don't help somebody scanning the map for
B Avenue
if it's rendered as A Street.  I'm hoping I've misunderstood the situation
and further
investigation will show that isn't the case, but I'm not hopeful.

Real life is messy. :(

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

Re: [Tagging] roads with many names

[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

[Paul Allen]

On Sun, 18 Aug 2019 at 19:55, Rob Savoye  wrote:

>   So no space ? USFS roads use "FS " with a space, at least that seems
> to be common. So should those be "FS739.1A' ?
>

My opinion is "paint the label."  Others disagree.  Make up your own mind
which
is better.

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Peter Elderson]

Richard Fairhurst :

> Sarah Hoffman wrote:
> > On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote:
> > > Peter Elderson wrote:
> > > > The point is, as it is it's not good enough for data use besides
> > > > rendering. you can't rely on route relations for anything but
> > rendering
> > >
> > > Once again: pretty much every OSM-based bike router uses route
> relations
> > to
> > > influence routing. (That might give you a clue to one of the
> > strategies.)
> >
> > But this is a task which is essentially the same rendering.
>
> I was addressing Peter's point that route relations can only be used for
> rendering, which is demonstrably false - they're used for influencing
> weighting in routing.
>

Ok, I agree you can use membership of a route relation as a weight factor,
while you do routing. You don't use the relation as a route. The idea of
walking routes is that they are the route and you follow the route, partly
or with own adaptions, but not for rerouting.

I did not mean that they can only be used for rendering. The point I made
is that if there are interruptions, branches, duplicates, stray nodes,
nested relations, etc in a route relation, it can still be used for
rendering (or, for granting weight to individal ways when routing), but you
cannot use it as a route that you follow from A to B by the ways it
contains.

>
> > The problems come in if you want to go the other way. When you start
> with
> > the relation, want to determine where the route goes along. That
> > information
> > is simply not contained in the route relations as long as you don't
> impose
> > a
> > couple of restrictions. [...]
> > I consider sorting and the use of roles essential for that.
>
> I'd fully agree on roles. The use of 'alternate' and 'forward'/'reverse'
> roles for bike route relations dates back to the earliest days of bike
> route mapping in OSM and is well established by now.
>

How then do I get it in OsmAnd and have it guide me forward the entire
route, then backward the entire route? Or in a Garmin device? Mine does not
have the option, as far as I know. I can do a lot, but it requires getting
the OSM data organized exactly as required, and involves gpx transfer and
route editing software, and in the end, Garmin reroutes the whole thing
again, to arrive at exectly the chain of ways I started with in OSM. The
main point is, as you say, data quality. QA tools can find problems, but
the fixing is still up to the mapper. RA does things, but can simply not
handle complex walking route relations.

JOSM does a decent job in detecting problems and it provides decent fixing
tools. E.g. sorting. But that often fails when the route is broken. Just
like overpass turbo export has a sorting routine, which works for simple
ordering tasks but just gives up if it gets complicated. Sam with
waymarkedtrails: its fine when simple ordering problems are there, it also
handles hierarchies quite nicely, but if it doesn't work out completely it
gives up and gives the relation as is.

I would sure like a better QA tool. I also would like a sorting routine in
JOSM that can handle all the complexities that prevent the full sort. If
anyone has goed code for that and knows how to make that available as a
plugin, that would be a great asset in maintaining OSM walking routes. I'm
often sorry I am no good at programming.


> But just as long established in OSM is the principle that - since mappers
> are our most precious resource - we optimise for the mapper, not for ease
> of
> consumption. Allowing relations to be unsorted is an example of that. If a
> relation represents a linear route, it's a SMOP to put the ways in the
> right
> order.
>
> Sure. The problem is that walking relations often do not add up to a
linear route when sorted. If they do, that doesn't last very long. So you
can't presume that they are, so it's up to the mapper to do it.

There are two obvious strategies. 1 is: create an empty polyline P with
> endpoints P1 and P2; iterate through the relation members; every time you
> encounter a way with an endpoint P1 or P2, add it to the polyline
> (potentially in reverse order) and remove it from consideration; repeat
> until there are no ways left. This is broadly the approach I've used until
> now.
>
> 2 is more involved but more fault-tolerant and flexible; create a routing
> graph, then route from the relation's startpoint to its endpoint using a
> very heavy uplift for members of this relation. This is a useful approach
> where the route actually _is_ non-contiguous but you nonetheless want to
> include connecting routes between the sections. (Quite a lot of American
> rail-trails are like this, as are several UK National Cycle Network
> routes.)
> This is an approach I'm investigating at present.
>
> Approach 1 does of course fail if the relation doesn't represent a single
> linear route. That would, however, still be true if the route was ordered.
>

The problem is, the route relation is often meant to be 

Re: [Tagging] roads with many names

[Kevin Kenny]

On Sun, Aug 18, 2019 at 12:28 PM Richard Fairhurst  wrote:
> Rob Savoye wrote:
> > 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".
>
> name=Corkscrew Gulch Road
> ref=CR 2
> usfs:ref=FS 729.2B
>
> 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.

If there are overlaid refs (and even if there aren't) it's better
North American practice to create route relations for the numbered
routes. That also lets the 'ref' be associated with a 'network', so
that a more sophisticated renderer can get the shields right.  Note
that 'CR' is NOT enough information for a shield - if you look at
https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14,
you'll see that Bergen County 3/89 have a style of shield distinct
from Passaic County 677.

Simple examples of concurrencies at
https://kbk.is-a-geek.net/catskills/test4.html?la=44.2134&lo=-73.5966&z=15,
where Court Street is US 9 and NY 9N through the village, or
https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
where I-890 is concurrent with NY 7 for a couple of exits.

Obviouisly, arbitrary combinations of network are possible, as at
https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
where NY 206 shares its roadway with first Sullivan County 179, then
Sullivan County 91, then Delaware County 7, or
https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14,
where US 202 is concurrent with US 1A and Maine 9 on Main Street, and
then concurrent with I-395 and Maine 15 on the freeway.

It's best to avoid CR as the network in favour of a string like
US:NY:Delaware. It's a bad assumption to guess that a renderer could
deduce this from the borders of the administrative regions.  Nearly
the whole of NY 120A is in Connecticut
https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14.

Having the route available also helps sort out the directions in the
signage, as where the eastbound direction of the bridge at
https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
is NY 30 North and NY 145 South.

The recommended network for USFS numbered routes is US:NFSR:(name of
the forest):NFH for a National Forest Highway, or US:NFSR:(name of the
forest):NFR for a National Forest Road. If the renderer that I've been
linking to in this message gets one of those (or just USFS for the
network, but the same numbers can be reused many times, so it's better
to have the forest included), it'll produce a shield that looks like
https://kbk.is-a-geek.net/attachments/20190818/nfsr2336.png.

If a road has no name other than its ref, practices differ between
putting in noname=yes, just leaving the name off, and giving it a name
like 'State Highway 9'. I tend to prefer the last of these, since a
renderer that doesn't have any fallback for ways without a name will
still at least render something. I also don't disturb 'ref=*' on the
way when I'm creating a route relation, but when doing rendering of
shaped shields, I ignore 'ref=*' entirely on ways that participate in
route relations.

If possible, (borrowing from another thread), keep the ways in a route
relation sorted. (If you or your editor can't do that, I'll cope, but
it makes matters easier for data consumers.)

These practices are seldom necessary in Europe, where route
concurrencies are rare, and pictorial markers are not important. They
are controversial for the rendering of the main map, because the
requirement is specific to a single locale, and because it is foreseen
to have an adverse impact on server operations when scaled up to
planetary size with minutely updates. I work on the issue of route
rendering off and on, but it's a hobby task so my progress is
agonizingly slow.

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Kevin Kenny]

On Sun, Aug 18, 2019 at 3:31 PM Peter Elderson  wrote:
> I'm afraid testing is all I can offer. I could list problems to detect, but I 
> think I would not be telling you news. Very important: handle nested 
> relations (hierarchies). RA currently does not.

Uhm, yeah, that's a problem. For what it's worth, Waymarked Trails
seems to have a much better route assembler. It copes with
https://hiking.waymarkedtrails.org/#route?id=919642, which definitely
has lacunae (because I never seem to have time to get to Schoharie
County to get the data to close the gaps).

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Peter Elderson]

Kevin Kenny :
> 
>> On Sun, Aug 18, 2019 at 3:31 PM Peter Elderson  wrote:
>> I'm afraid testing is all I can offer. I could list problems to detect, but 
>> I think I would not be telling you news. Very important: handle nested 
>> relations (hierarchies). RA currently does not.
> 
> Uhm, yeah, that's a problem. For what it's worth, Waymarked Trails
> seems to have a much better route assembler. It copes with
> https://hiking.waymarkedtrails.org/#route?id=919642, which definitely
> has lacunae (because I never seem to have time to get to Schoharie
> County to get the data to close the gaps).
> 

It is quite clever! Its explained here: 
https://hiking.waymarkedtrails.org/help/rendering/hierarchies

It’s easy to spot if a route is broken: the map usually will be not that bad, 
but the elevation profile will tell you and show you. If it’s badly broken, it 
usually requires lots of JOSM before you can use it for export to a gps app or 
device, or import into a route editor or trip planner for waymarked/signposted 
routes.

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

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc

[Morten Lange via Tagging]

Hello,
I am skeptical as that makes finding them less straightforward, if you are 
looking for   [ a place where I can get my bicycle repaired or receive some 
help].Many potential users will not know about bicycle kitchens or that other 
community centres offer bicycle repairs.But I think they should be searchable 
also as somethings separate form the ordinary bicycle shop. Additional tags can 
do the trick.
For bicycle kitchens I guess 
      service:bicycle:diy:yes     might cover it. 


Here follow some new ideas that just popped out:

Perhaps add something like     shop:bicycle:type=bicycle_kitchen

Other values for that tag could be     with_pub    with_cafe    job_training    
in_community_centre
?

-- Regards / Kveðja / Hilsen Morten Lange 

On Sunday, 18 August 2019, 00:50:04 CEST, Martin Koppenhoefer 
 wrote:  
 
 There haven’t been more replies here, but the discussion didn’t seem 
conclusive either. Is everyone fine with the established tagging  shop=bicycle 
and several subtags for the details? 

IMHO the mentioned subtags are fine, but I believe we should have a dedicated 
main tag, these really aren’t bicycle shops, or at least so different that it 
seems confusing to tag them like this.

The established term in English is probably bicycle kitchen (as of the title of 
this thread), so it seems a no-brainer to tag

amenity=bicycle_kitchen

the established subtags would be kept, but shop=bicycle would be removed.

Would this have your support? 


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

Re: [Tagging] Bicycle kitchens, community centres that offer bicycle repairs etc

[Martin Koppenhoefer]

sent from a phone

> On 18. Aug 2019, at 23:06, Morten Lange via Tagging 
>  wrote:
> 
> I am skeptical as that makes finding them less straightforward, if you are 
> looking for   [ a place where I can get my bicycle repaired or receive some 
> help].


it will require you look for them explicitly or the app you are using would 
take them into account. On the other hand from my experience these aren’t 
places “to get your bicycle repaired”, they are rather places you can go to and 
hang out with other bicycle enthusiasts of a certain political orientation and 
repair your bike yourself.



> Many potential users will not know about bicycle kitchens or that other 
> community centres offer bicycle repairs.


again, these places around here don’t “offer bicycle repairs”, they offer 
enabling you to do the repairs yourself 


> But I think they should be searchable also as somethings separate form the 
> ordinary bicycle shop. Additional tags can do the trick.
> 
> For bicycle kitchens I guess 
>   service:bicycle:diy:yes 
> might cover it. 


while it isn’t factually wrong, it isn’t useful as a distinction from forprofit 
places where you pay to use a space to adjust your bike



> Here follow some new ideas that just popped out:
> 
> 
> Perhaps add something like 
> shop:bicycle:type=bicycle_kitchen


yes, if it _is_ a kind of bicycle shop. An idea that is not universally shared.


> 
> 
> Other values for that tag could be 
> with_pub
> with_cafe
> job_training
> in_community_centre


IMHO no. We do not need tags of an is_in fashion for this, we can model this 
universally by making use of implicit spatial relationships (i.e. put the bike 
kitchen inside the community centre or pub, or the other way round, according 
to our interpretation of the situation)


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

Re: [Tagging] roads with many names

[Joseph Eisenberg]

Slightly off-topic: one of the posts mentioned that this road is tagged
highway=track.

However, if the road is the main access to a house, it should be
highway=unclassified. Or it could even be highway=tertiary since it is a
country road, if it connects to a number of houses or a hamlet or
place=village along the way.

But please add surface=unpaved or a more specific value.

Joseph

On Mon, Aug 19, 2019 at 4:49 AM Kevin Kenny  wrote:

> On Sun, Aug 18, 2019 at 12:28 PM Richard Fairhurst 
> wrote:
> > Rob Savoye wrote:
> > > 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".
> >
> > name=Corkscrew Gulch Road
> > ref=CR 2
> > usfs:ref=FS 729.2B
> >
> > 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.
>
> If there are overlaid refs (and even if there aren't) it's better
> North American practice to create route relations for the numbered
> routes. That also lets the 'ref' be associated with a 'network', so
> that a more sophisticated renderer can get the shields right.  Note
> that 'CR' is NOT enough information for a shield - if you look at
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
> ,
> you'll see that Bergen County 3/89 have a style of shield distinct
> from Passaic County 677.
>
> Simple examples of concurrencies at
> https://kbk.is-a-geek.net/catskills/test4.html?la=44.2134&lo=-73.5966&z=15
> ,
> where Court Street is US 9 and NY 9N through the village, or
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
> where I-890 is concurrent with NY 7 for a couple of exits.
>
> Obviouisly, arbitrary combinations of network are possible, as at
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
> where NY 206 shares its roadway with first Sullivan County 179, then
> Sullivan County 91, then Delaware County 7, or
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
> ,
> where US 202 is concurrent with US 1A and Maine 9 on Main Street, and
> then concurrent with I-395 and Maine 15 on the freeway.
>
> It's best to avoid CR as the network in favour of a string like
> US:NY:Delaware. It's a bad assumption to guess that a renderer could
> deduce this from the borders of the administrative regions.  Nearly
> the whole of NY 120A is in Connecticut
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
> .
>
> Having the route available also helps sort out the directions in the
> signage, as where the eastbound direction of the bridge at
> https://kbk.is-a-geek.net/catskills/test4.html?la=41.9474&lo=-74.9127&z=14
> is NY 30 North and NY 145 South.
>
> The recommended network for USFS numbered routes is US:NFSR:(name of
> the forest):NFH for a National Forest Highway, or US:NFSR:(name of the
> forest):NFR for a National Forest Road. If the renderer that I've been
> linking to in this message gets one of those (or just USFS for the
> network, but the same numbers can be reused many times, so it's better
> to have the forest included), it'll produce a shield that looks like
> https://kbk.is-a-geek.net/attachments/20190818/nfsr2336.png.
>
> If a road has no name other than its ref, practices differ between
> putting in noname=yes, just leaving the name off, and giving it a name
> like 'State Highway 9'. I tend to prefer the last of these, since a
> renderer that doesn't have any fallback for ways without a name will
> still at least render something. I also don't disturb 'ref=*' on the
> way when I'm creating a route relation, but when doing rendering of
> shaped shields, I ignore 'ref=*' entirely on ways that participate in
> route relations.
>
> If possible, (borrowing from another thread), keep the ways in a route
> relation sorted. (If you or your editor can't do that, I'll cope, but
> it makes matters easier for data consumers.)
>
> These practices are seldom necessary in Europe, where route
> concurrencies are rare, and pictorial markers are not important. They
> are controversial for the rendering of the main map, because the
> requirement is specific to a single locale, and because it is foreseen
> to have an adverse impact on server operations when scaled up to
> planetary size with minutely updates. I work on the issue of route
> rendering off and on, but it's a hobby task so my progress is
> agonizingly slow.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[Warin]

On 19/08/19 05:16, Paul Allen wrote:
On Sun, 18 Aug 2019 at 19:55, Rob Savoye > wrote:


  So no space ? USFS roads use "FS " with a space, at least that seems
to be common. So should those be "FS739.1A' ?


My opinion is "paint the label."  Others disagree.  Make up your own 
mind which

is better.


+1.

The mapper is in charge of what goes into OSM. They should map what they 
see, not conform to some 'rule' of 'no spaces' etc etc. Map the truth.



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

Re: [Tagging] Is crop=yes tag completely and utterly useless?

[Warin]

On 18/08/19 22:10, Paul Allen wrote:
On Sun, 18 Aug 2019 at 07:40, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:



But I see that there is some desire for a tag for generic cropland, or
farmland used to grow unspecified crops. For this I would suggest the
key "farmland=cropland" or "crop=field_cropland", rather than crop=yes
(less specific) or produce=crop (unclear).


Before we get to the details of how we're going to tag it, we need to 
be clear on what

"it" is.

Modern agricultural techniques (mainly the use of fertilizers, whether 
natural or
artificial) permit monoculture, where a single type of crop is grown 
in the same
field, year after year.  This we can map with crop=* (or crop=yes or 
whatever

replaces it when we know a monoculture crop is grown but we don't know
what it is, although that seems unlikely).

However, it is still fairly common to use crop rotation where 
different crops are grown

in different years, or even two different crops in the same year.
See https://en.wikipedia.org/wiki/Crop_rotation One crop in the 
rotation may be
grass, harvested for silage to later be fed to animals. In some cases 
a field
in a crop rotation may be used as pasture for a year to directly feed 
animals.

Land in crop rotation may be left fallow for a year, with no crop.  OTOH,
where the land is very uneven then it might be used for nothing but 
pasture

(sheep or goats are the usual "crop" on land like that).


Sheep. goats, cattle, kangaroos or camels are not 'crops' but 'produce'.



Maybe we need crop=rotation rather than crop=yes.  I suspect we need 
both.  Not
necessarily as the tag crop=yes if everyone thinks there's a better 
tag, but we need to
cover "this is used to grow crops in some sort of rotation" and "this 
is used to grow
crops but I can't figure out what type from this distance and I don't 
know if it's

monoculture or rotation."


And where part of that rotation includes animals the tag should be 
produce=rotation?

Possibly the mapper will not know if the rotation is only plants.



Or maybe we should restrict ourself to mapping it as farmland because, 
in general,
we don't know what a farmer is going to do with a given field from 
year to year.  There
are specific cases where we're fairly sure a field is used for 
monoculture and we
have specific tags for those: orchard, vineyard, etc. But, in general, 
just because I
see oilseed rape in a field this year that doesn't mean it's going to 
be oilseed

rape next year (it usually isn't, around here).


In some parts only cattle are run, in other parts sheep, in other parts 
plants, and in some parts a combination.
Where that is this single use it is easy to tag e.g. produce=cattle, 
where there is variation from time to time then it gets complicated.




I should also point out that many farms around here devote some or all 
of their land
to tourism.  Is that crop=tourist?  Where the tourists pitch their 
tents or park their
caravans is a camp site, but some of the farmland may be left for 
tourists to

use recreationally (aka the farmer having given up on farming completely
because it's no longer economic).


If it has totally gone from farm use then it needs to be re-tagged. '
Occasional use I don't think should be tagged.
Regular use can be tagged using the conditional attribute.

A problem maybe seen with 'fallow'. While this seems to be 'weeds' to 
the casual observer, growing weeds by a farm will be seen as destructive 
to their other activities and any weeds will be discouraged. Usually 
'fallow' land will be planted out with some cheap coverage that can be 
usefully turned back it to the soils. So 'fallow' to me is a 'produce' 
of 'fertiliser' that does not leave the paddock.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Graeme Fitzpatrick]

This:
https://lists.openstreetmap.org/pipermail/tagging/2019-March/044160.html
was the original discussion that I had been going to expand on, with the
possibility of trade= for places like a plumber's workshop / shed etc.

There was also discussion about craft= being more used for "one-off"
hand-made handicrafts (wood turning, artists [as opposed to house painters]
etc)

What's the preference of trade= against business= plumbers, electricians,
builders etc who don't work out of an "office"?

Thanks

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Joseph Eisenberg]

Re “What's the preference of trade= against business= plumbers,
electricians, builders etc who don't work out of an "office"?”

Some of those do have offices, especially if it’s a company that employed
several plumbers.

But trade= is better than generic business= for the workshop of an
individual tradesperson.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Warin]

On 19/08/19 10:20, Graeme Fitzpatrick wrote:
This: 
https://lists.openstreetmap.org/pipermail/tagging/2019-March/044160.html 
was the original discussion that I had been going to expand on, with 
the possibility of trade= for places like a plumber's workshop / shed 
etc.


There was also discussion about craft= being more used for "one-off" 
hand-made handicrafts (wood turning, artists [as opposed to house 
painters] etc)


What's the preference of trade= against business= plumbers, 
electricians, builders etc who don't work out of an "office"?




Where do they 'work from'???

Every plumber, electrician and builder I know are mobile, they work on 
site. Smaller ones have an 'office' at home.
Here they form a legal 'business' and have a 'registered address' with 
signage.
To satisfy the relation the sign is usually on the back door to avoid 
the local council becoming concerned. As it is not public I would not 
map them.


The larger firms of plumbers, electricians and builders have an office 
.. so I'd tag them as offices - they sell a service so fit the OSM 
description.


As regards 'business' tagging .. the keys amenity, office, shop all 
contain businesses so generic tagging has been lost for business.


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

Re: [Tagging] roads with many names

[Paul Johnson]

On Sun, Aug 18, 2019 at 10:16 AM Rob Savoye  wrote:

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

refs aren't names, they're refs.  ref=CR 2 and ref=FS 729.2B are
appropriate.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[Johnparis]

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 normally a
local consensus on space-versus-no space, and as others have mentioned,
it's up to you.

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, and
the tagging consensus will be documented (hopefully) on the wiki or the
local mailing list (as is the case for the national routes I cited). "Paint
the label" is fine in general but there can be other considerations (signs,
as you know, aren't always correct).

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

You can see the tagging on the Court Street example he cites here:
https://www.openstreetmap.org/way/45759030

Here's a Colorado national forest highway with a nearby CR:
https://www.openstreetmap.org/way/17062214#map=14/38.8684/-107.1015

The tags look reasonable to me:

highway=unclassified
name=Lake Irwin Road 826
ref=FS-826
source=Gunnison County GIS data, USFS, Bing
surface=gravel
tracktype=grade1

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






On Mon, Aug 19, 2019 at 12:28 AM Warin <61sundow...@gmail.com> wrote:

> On 19/08/19 05:16, Paul Allen wrote:
>
> On Sun, 18 Aug 2019 at 19:55, Rob Savoye  wrote:
>
>>   So no space ? USFS roads use "FS " with a space, at least that seems
>> to be common. So should those be "FS739.1A' ?
>>
>
> My opinion is "paint the label."  Others disagree.  Make up your own mind
> which
> is better.
>
>
> +1.
>
> The mapper is in charge of what goes into OSM. They should map what they
> see, not conform to some 'rule' of 'no spaces' etc etc. Map the truth.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[brad]

So is F street, or 1st street a name or a ref?

On 8/18/19 10:27 AM, Joseph Eisenberg wrote:

It looks like "CR 2" is a "ref" rather than a name, and so is FS
729.2B. A ref=, short for "reference number" (or more properly
"reference alphanumeric string") is a set of letters and numbers that
identifies a feature.

While it's best to have the common name in the tag name=, like
name=Corkscrew Gulch Road, it's okay to have more than one ref in the
tag ref, separated by semicolons. Many database users can handle this.
Eg:

name=Corkscrew Gulch Road
ref=CR 2;FS 729.2B

If there are other, less common actual names, consider using
alt_name=* or loc_name=* (local, informal names), but in this case it
looks like there is just one name, but multiple reference numbers.

Joseph

On 8/19/19, Rob Savoye  wrote:

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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Tagging] roads with many names

[Joseph Eisenberg]

F Street and 1st Street (usually written out as First Street, though
this depends on the local standards) are a common name, which goes in
the name field.

1st Street might also be part of County Road (CR) #312, which would be
ref=CR 312 or =CR312 or similar. The idea is that most people locally
would refer to their address as on "F Street" or "First Street" in
conversation, but the ref is still useful for navigation if it's
placed on signs in addition to the local name.

Some roads only have a name like (California) State Highway 99, which
is used by the locals as their house or business street address, so in
that case you can use both name=Highway 99 (or whatever the most
common signs and addresses say) in addition to ref=CA 99 or similar.

On 8/19/19, brad  wrote:
> So is F street, or 1st street a name or a ref?
>
> On 8/18/19 10:27 AM, Joseph Eisenberg wrote:
>> It looks like "CR 2" is a "ref" rather than a name, and so is FS
>> 729.2B. A ref=, short for "reference number" (or more properly
>> "reference alphanumeric string") is a set of letters and numbers that
>> identifies a feature.
>>
>> While it's best to have the common name in the tag name=, like
>> name=Corkscrew Gulch Road, it's okay to have more than one ref in the
>> tag ref, separated by semicolons. Many database users can handle this.
>> Eg:
>>
>> name=Corkscrew Gulch Road
>> ref=CR 2;FS 729.2B
>>
>> If there are other, less common actual names, consider using
>> alt_name=* or loc_name=* (local, informal names), but in this case it
>> looks like there is just one name, but multiple reference numbers.
>>
>> Joseph
>>
>> On 8/19/19, Rob Savoye  wrote:
>>> 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 mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] roads with many names

[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

[Paul Johnson]

On Sun, Aug 18, 2019 at 10:24 PM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> F Street and 1st Street (usually written out as First Street, though
> this depends on the local standards) are a common name, which goes in
> the name field.
>

It can also be regionally dependent.  Oklahoma got a lot of "East 820 Road"
type names, but in reality it should be ref=CR E820 instead.   TIGER is the
most notorious source for this bogosity, and the counties themselves aren't
super consistent themselves, so you'll see some with the five point blue
county signs, some that use standard street blades and list the road
numbers, and some that literally paint the route numbers on the pavement at
each intersection, regional knowledge is required to get the context right,
especially since you'll get some that TIGER imported with like:

name=East 820 Road
name_1=Cemetery Road
name_2=River Road.

Rearrange the multiple values randomly.  It's pretty obvious to tell which
is going to be the county road number.  Which name it is gets a little
tricker; sometimes it was originally one then it changed to another,
sometimes it's none of those besides the county road number, sometimes it's
the county road number and another, fourth value for the name from a more
recent renaming.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[Kevin Kenny]

On Sun, Aug 18, 2019 at 11:30 PM Rob Savoye  wrote:
> > 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.

No, I was talking about the network name in a route=road relation.

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

https://www.openstreetmap.org/relation/3109478 is an example that I
was just editing this evening.  It has a lot of individual roadways,
and the presence of the relation allows them to be worked on as a
group, listed end to end, have mileage tables produced, and so on.

On the route relation the reference is just '159'.  The 'network' is 'US:NY'.

The 'ref' appears on the individual ways as 'NY 159'.

A county road needs to identify the county as well as the state in its
'network', so with https://www.openstreetmap.org/relation/3122269
you'll see that the 'ref' is still just '88' but the 'network' is
'US:NY:Schenectady'.  Since different counties use different shields,
'CR' wouldn't be enough to determine what shield to use in rendering.
The 'ref' on the way is still 'CR 88'.

For USFS roads, the numbers can be reused between forests, or so I
understand, so the complex string for the 'network' is used to make
sure that there's something unique about the route.  'FS 12345' wouid
be a perfectly good 'ref' on the way,  but doesn't give you the other
advantages of route relations.

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.

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

Re: [Tagging] roads with many names

[Joseph Eisenberg]

I would have expected tracktype=grade2 for a gravel road. Is it common to
use grade1 in that area for very well built, quality gravel roads?

Joseph

On Mon, Aug 19, 2019 at 12:11 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 normally a
> local consensus on space-versus-no space, and as others have mentioned,
> it's up to you.
>
> 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, and
> the tagging consensus will be documented (hopefully) on the wiki or the
> local mailing list (as is the case for the national routes I cited). "Paint
> the label" is fine in general but there can be other considerations (signs,
> as you know, aren't always correct).
>
> 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 ...
>
> You can see the tagging on the Court Street example he cites here:
> https://www.openstreetmap.org/way/45759030
>
> Here's a Colorado national forest highway with a nearby CR:
> https://www.openstreetmap.org/way/17062214#map=14/38.8684/-107.1015
>
> The tags look reasonable to me:
>
> highway=unclassified
> name=Lake Irwin Road 826
> ref=FS-826
> source=Gunnison County GIS data, USFS, Bing
> surface=gravel
> tracktype=grade1
>
> ... 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.
>
>
>
>
>
>
> On Mon, Aug 19, 2019 at 12:28 AM Warin <61sundow...@gmail.com> wrote:
>
>> On 19/08/19 05:16, Paul Allen wrote:
>>
>> On Sun, 18 Aug 2019 at 19:55, Rob Savoye  wrote:
>>
>>>   So no space ? USFS roads use "FS " with a space, at least that seems
>>> to be common. So should those be "FS739.1A' ?
>>>
>>
>> My opinion is "paint the label."  Others disagree.  Make up your own mind
>> which
>> is better.
>>
>>
>> +1.
>>
>> The mapper is in charge of what goes into OSM. They should map what they
>> see, not conform to some 'rule' of 'no spaces' etc etc. Map the truth.
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[Andrew Davidson]

On Mon, Aug 19, 2019 at 1:45 AM Julien djakk 
wrote:

>
> If you have several name or several ref, you can use the “;” separator
>
>
Name tags with ";" in them get flagged as a problem to fix by validators.

If there are more than one alternative names for something I use alt_name=*
alt_name:1=* etc.  Nominatim will consume names in the alt_name:* space so
they'll be searchable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging