From OpenStreetMap Wiki
Jump to navigation Jump to search

ref & nat_ref

Does it make sense to have both tags (ref and nat_ref) defined? At the moment I see a lot of use of nat_ref, where it is used for the street reference number of that country, for example in Germany:

  • key="name" value="A123"
  • key="highway" value="motorway"
  • key="oneway" value="true"
  • key="nat_ref" value="A123"

So, does it make sense to have both tags, ref and nat_ref? Or in the case above, should one use "ref" instead of "nat_ref"?
RalfZ 13:08, 19 September 2006 (BST)

Multiple tags

I can't see either way if it's allowed or not to use more than one ref for a way. There are places where two ways run on the same stretch of road for a while - the E6 and E20, for instance, is the same road between Helsingborg and Malmö in Sweden. --KristianThy 13:54, 10 December 2006 (UTC)


in Germany, all street references have spaces between the letters and the numbers in the official version -- even the international street references; e.g. the motorway A 61 with the international reference E 31; what about official notation in other countries; the notation privat enterprises use in their maps is not meant here--privat companies often don't care about these things; there also seem to be dashes as a possibilty ... and of course we have some different writing systems in the world - any thoughts about this? -- Schusch 22:40, 5 May 2008 (UTC)

Standard for the US

How should these be used in the US? Should it be a unified scheme with the state abbreviation for state routes (e.g. IN-XX, MI-XX) and I-XX for interstate, US-XX for US highways? Or should we vary by state (Michigan state routes would use M-XX, Interstates would use IH-XX in Texas, many states use something like SR or SH for state routes) Random832 16:33, 18 September 2008 (UTC)

  • I follow the scheme outlined in United_States_roads_tagging. So Michigan state route would be ref="US:MI XX" Alexrudd 21:47, 21 December 2008 (UTC)
    • That leads to some rather clumsy labeling in the current Mapnik and Osmarender renderers. If these renderers are reconfigured to display this information more elegantly, maybe more people would follow the "US:XX ##" convention. Vid the Kid 16:56, 24 December 2008 (UTC)

For that matter, how should county road numbers be marked? There are some places where the county road number is displayed just as prominently as a state or US route marker. The "conventional" approach of "name=CR ##" works in places where that really is the road's only name, but what about counties that have actual names for roads, in addition to well-signed county road numbers? Vid the Kid 16:56, 24 December 2008 (UTC)

  • If there's no ref=, there's no ref=. There's a few state highways in Oregon that don't have a name or a ref! Paul Johnson 20:38, 31 May 2009 (UTC)

Roads signed as leading to a particular ref

Likely in other countries some major but unnumbered roads have signposts guiding to a numbered road, i.e. the other roads number surrounded by a dashed line vs. solid line. I've now tagged these as leads_to_ref=*, in part just to discourage others from tagging these with a wrong ref=*. Mostly this happens where an arterial road leading out of a city center isn't a numbered road for the first kilometers. Any better suggestions? Alv 10:18, 20 September 2008 (UTC)

  • I wouldn't think this is appropriate information for OSM. It's not really needed for routing applications, and this kind of information is typically not explicitly shown on maps, as it can be pretty easily seen from the map that such roads lead to such other highways already. If it were actually to be tagged, however, I would suggest something like ref:to=* or ref=TO *. Vid the Kid 17:01, 24 December 2008 (UTC)

Names and References

Many highways can be tagged with a matching name and reference. For example, name="United States Highway xx", ref="US xx". This is redundant, and I think the name tag can be removed. Is it strictly necessary to include the name tag in this case? --Elyk 02:30, 30 September 2008 (UTC)

  • I think this particular phenomenon of redundancy comes not from someone deciding it should be that way, but from the TIGER database. It would seem that the name was carried over unchanged, and the ref was (for US and Interstate highways) derived from the name. It would have been extra work in the import process to then delete the longer name information, had anyone thought of it. I say, feel free to remove the "name" of such highways if they only duplicate/expand the information in the "ref" tag. Check and see if the road has an actual local name that you can put in the "name" tag, though. Vid the Kid 17:07, 24 December 2008 (UTC)

ref for roles

how can we state that a ref is only valid in a certain role?

for example, for a way that is both a highway=track and piste:type=downhill, the ref in that case only refers to usage as a piste; in this example, we have a "blue piste 10", but the underlying track has no ref (or at least, it's not '10').

can this be resolved without switching everything there to Relations/Routes? --Osm6150856065 09:57, 29 August 2009 (UTC)

Spaces in e-roads

There are some confusion as to whether or not there are spaces in e-road refs or not. Some countries have signes with spaces, some don't. The ref tag have a rule: map what is on the ground. But this can not apply to the int_ref tag as this have differant standards. int_ref needs one standard and in the case of e-roads this is the UNECE witch consistently writes "E ##" or "E ###". So no matter how the way is signed the int_ref is written with a space and two or three digits on e-roads. Other road networks might differ. --Gnonthgol 11:09, 8 March 2010 (UTC)

The discussion was started long ago at Talk:WikiProject_Europe/E-road_network. Alv 11:20, 8 March 2010 (UTC)

ref for branch or franchise reference

In the context of way 86215972, I've used ref=Bear Branch Office to indicate the identity of a bank branch, where name=Artisans' Bank. --Ceyockey 04:20, 8 July 2011 (BST)

GNIS id values

I have used ref=GNIS:* in a few cases to indicate reference id in the United States Geograhical Service Geographic Names Information System resource. Is this a useful item to put under either the main table or "Special uses"? --Ceyockey 18:26, 14 August 2011 (BST)

Maybe ref:GNIS=* would be better. Using ref=GNIS:* prevents using this tag for an other more general purpose. FrViPofm 11:08, 5 June 2012 (BST)
It should be in lower case (ref:gnis=*) and it was added to the table of variations in June 2018. --T99 (talk) 19:13, 24 April 2019 (UTC)

ids from other web services?

can this also be used to map places/features from other web services like facebook or foursquare? like this:


--Shmias 14:09, 4 June 2012 (BST)

nation wide refs

In France, we aim using ref:FR:*=* for references applying to our country. Is it possible to use the principle for the other countries with tags such as ref:DE:*=* ref:UK:*=* and patiently to change the existing tags ? --FrViPofm (talk) 00:34, 20 February 2013 (UTC)

I completely agree with such guideline. It shouldn't only apply to countries but to any extent when refs aren't regarding whole world.
I'm willing to use ref:EU:*=* to references for Europe only.
Nevertheless it may be hard to convert existing references with several thousand of uses (as usual). Fanfouer (talk) 12:52, 7 June 2015 (UTC)
Why it would be useful? If there is some reference code worth adding it may be better to invent a new key (like teryt:simc=*, could be ref:teryt:simc=*) but I see no good reason to use ref:PL=13 on street lamp with reference code 13 just because it is in Poland Mateusz Konieczny (talk) 07:34, 9 June 2021 (UTC)

In Rep South Africa there is an index on schools maintained by the Basic Education Department (DBE). Sites like schools4SA make already use of it. So ref:ZA:emis=* or emis_no=* for the 9-digit "National Education Management Information System Number" might be useful. There's also a 5-digit sagns_id=* for geographical names maintained by the Department of Arts and Culture (DAC). But used as key, NOT ref. --Googlenaut (talk) 07:06, 9 June 2021 (UTC)

reference to an external collection

Speaking about `natural:tree`, I'm participating to the insertion of trees in the Parque Centenario in Cartagena de Indias, Colombia. These trees are being inserted in a botanical database as well, and each of them receives an "Accession number" (consider this a code identifying the plant data).

We were discussing how to add this reference. The accession number has now been added to the OSM objects under the key `ref`, while I had been advocating using `ref` as a namespace prefix, where the tag name would be composed of three parts:

  • the `ref` prefix,
  • the name of the collection,
  • the `accno` suffix.

I generally prefer not to fix things that work, but I foresee conflicts, and I would like to hear other thoughts. --Mariotomo (talk) 14:48, 9 February 2017 (UTC)

On the ground verifiability of ref tags on roads

As routing software uses the ref-tag on roads to give instructions, shouldn't we be more strict that on roads the ref-tag is what is actually signed along the road. It is no use to have the GPS tell you turn into BD8975b when there is no sign that the road has that ref. And I'm not talking about that a particular intersection doesn't happen to be signed, I'm talking of roads that have similar refs entered in OSM where that ref does not occur anywhere along the entire length of the road!

• ref should be the signed ref as seen on signs along the road

• official_ref or unsigned_ref should be used for the official ref used by the road administration but that is not signed along the road

--Cohan (talk) 09:42, 24 August 2017 (UTC)