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.

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.


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 mailing list

Reply via email to