Talk:Key:ref

From OpenStreetMap Wiki
Jump to navigation Jump to search

Usage of ref and additonal old_ref as namespace for historic boundary_stones (for discussion)

Hi, I'm working as an 'armchair' conservationist in germany with old boundary_stones. We are using OSM as de facto standard for our data collection. Unfortunately is there no default for boundary_stones in different frames of reference. For example one stone, different numbers over time and for every bordering district. So I've adapted the ref and old_ref keys in a for us workable way and want to share this for discussion.

  • key="ref" - current number. If multiple frames of reference exists (i.e border of districts) we use the key as namespace "ref:district" for the current numbers in that context.
  • key="old_ref" - namespace based on district and year.

Example - based on an real stone - for the same historical boundary_stone between the district border of Spingfield and Shelbyville in the same County:

"ref": 75 - current number for the county forest boundary the stone 'marks' today. "old_ref:Spingfield:1769=14" - in old maps from the year 1759 the stone was marked with the number 14 from the Spingfield district "old_ref:Shelbyville:1769=41" - in old maps from the year 1759 the stone was marked with the number 41 from the Shelbyville district ...an so on.

Is this a usable approach for OSM ? Anybody remarks or suggestions ?

--Saarworres 22:09, 02 Feb 2022 (BST)

That seems fine. If there's a sensible name for the whole set of numbers, you could also make up a new prefix and use that. But your approach seems like it will work, too. JesseFW (talk) 03:38, 3 February 2022 (UTC)
I might be inclined to use semi-colon separators and avoid old_ref entirely. To me, old_ref is more a "this official ref has recently changed, but to avoid confusion i will state it here for a short unspecified time"... also, is this the absolute official reference for the stone, used throughout the world? could make it more regional with something like ref:DE:stone=75;Spingfield:1759:14;Shelbyville:1769:41 A more complex tagging scheme would hit the argument that historical information doesn't belong in OSM Jnicho02 (talk) 12:04, 3 February 2022 (UTC)
Okay, thanks for the input. So "old_ref" has a more a temporary usage than historical? Okay. But as I understand it, the "ref" cannot be an absolute nor official reference. There are to many boundary_stones without any "ref" at all because of weathering. And all district were once upon a time self-governed, so there will always be boundary_stone with up to 4 frames of reference (max I know of, maybe more).
Maybe I should adapt JesseFW approach and add an new prefix. I could structure the prefix for "historic_ref"and add the district by its permanent [wikidata ID](https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID) and the year as namespaces i.e : "historic_ref:[WIKIDATA_ID]:1769". In that way I avoid german umlauts and make it more machine readable?
But honestly, I am cautious about "reinventing the wheel". If the OSM isn't the right place for the (more detailed) historical data, where would you put it for open access? Saarworres 14:03, 03 Feb 2022 (UTC)

Are these numbers visible on the stones, or does this info come from other sources? If they are visible, that's a point in favor of putting the info in OSM (maybe just as a straight transcription of what is readable on the stone, in inscription=*, with some guidelines about formatting to facilitate machine readability). If this is coming from other sources, it might be better to just transcribe the other sources, post them somewhere like github and/or the Internet Archive and link to OSM merely by including detailed lat/lon of the stones. JesseFW (talk) 14:38, 3 February 2022 (UTC)

Yes the Numbers are visible on the stones. We have 3 major cases: 1) weathered stone without any engravings left 2)'reused' old stone with additional engravings on top of the old ones 3) 'abandoned' stones with all old engravings. I get the concept: "Minimalize data and therefore upkeep" but you wouldn't you strip the historical context out of the historical boundary_stone with that approach? Its a valid point to make to only depict the today; but why should you put boundary_stones without any inscription into OSM then anyway? But no problem. I will not add namespaces or prefixes. I put the data into the "inscription" field as suggested. I misunderstood the "old_ref" as a special field for such information. Thanks alot for the responses Saarworres 17:03, 03 Feb 2022 (UTC)

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)

Spaces

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: 

ref:facebook=325001280021
ref:foursquare=4adcda7af964a520e84621e3

--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)
I think you misunderstand. This would apply to named network references. Instead of ref:NAME=13 we would use ref:COUNTRY:NAME=13 to prevent overlap and conflict. In your example, you can always use ref=13, but if this was referring to the Polish National Streetlamp reference number, instead of using ref=pns which may conflict or be confused with the Pittsburgh Naval Shipyard reference, the Polish one could be ref:PL=pns and the other is ref:US=pns.
The establish named references should probably be left alone but this convention would be recommended to new named networks. This convention appears to be gaining popularity (de facto) and I support adding text to the page to encourage it's usage. BubbleGuppies (talk) 07:58, 17 July 2022 (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)

Eionet Bathing Water Identifier

About: Identifier for a beach in Europe monitored for swimming/bathing water quality by the European Environment Information and Observation Network (Eionet).

Source: Eionet bathingWaterIdentifier (P9616)

Accepted proposal:

Uniqueness

Say how much uniqueness should Key:ref have.

Well OK, I guess no uniqueness is implied. We are just reporting the ground truth. If some object has the same Key:ref as another nearby object, whether accidental or not, one can only blame the company who painted the number. Jidanni (talk) 19:36, 9 October 2021 (UTC)

Adding reference numbers on portions of power lines

Do I tag a reference number of an existing structure o a structure on a right of way/portions already acquired and designated as start and end point of a portion of a power line? Like if I tag all NGCP-acquired and designated portions of relocated San Simon-Pulilan section of Hermosa-Duhat-Balintawak transmission line as 227-255, 256-266, and 267-314? Ervin11899 (talk) 11:52, 28 March 2023 (UTC)

Tag for no reference number

Resolved: see below

I thought the tag for something without a reference number was no:ref=* but apparently that's wrong. So does anyone know what it actually is? --Adamant1 (talk) 10:16, 23 May 2023 (UTC)

noref=yes -- Something B (talk) 10:38, 23 May 2023 (UTC)
duh. Thanks. --Adamant1 (talk) 19:15, 23 May 2023 (UTC)

National Inventory of Dams ID

The National Inventory of Dams (https://nid.sec.usace.army.mil/#/) is maintained by the U.S. Army Corp of Engineers and has an ID number for each dam they've cataloged in the United States. Examples: TX05562, OH00477. I've been using it to update the locations of some misplaced dams, and I wanted to ask, is there a place it would be worth storing that dam ID here?

They label the id a "NID ID". Their description:

The official NID identification number for the dam, known formerly as the National ID. This is a required field, and must have an entry for each dam included in the NID. The State Dam Safety Offices assign and maintain the NID IDs for all dams, regardless of ownership. The first two characters of the identity are the two-letter state abbreviation, based on the location of the dam. The last five to six characters of the identity are a unique number (AB#####); although States are allowed to use alphanumeric combinations in the characters that follow the state abbreviation.

Wikidata has National Inventory of Dams ID. Maybe something like ref:nidid or ref:us:nid or ref:us:nidid? Should I follow the tag proposal process? I haven't done anything like that before, hence this post.

Thanks! --MattMap (talk) 23:49, 26 September 2023 (UTC)

I think that's a a very reasonable thing to add, and if you want to do so, I think it's reasonable to just go for it, using ref:us:nid=*. Once you've added a dozen or so, you can create the wiki page to document it. I certainly would not bother with the proposal process for this. The alternative, if you want, would be to use Wikidata as an intermediary, and add the wikidata=* IDs to the OSM objects, and add the NID IDs to the Wikidata entities (and create them if necessary). Either one seems fine to me. JesseFW (talk) 00:26, 27 September 2023 (UTC)
Thank you! I will give ref:us:nid=* a go! --MattMap (talk) 00:43, 27 September 2023 (UTC)

Capitalization

Hi, new question. I've now made about 150 instances of the new tag Key:ref:us:nid. Before I do more, should I change the capitalization of it to ref:US:NID? I just noticed on Taginfo that for keys with ":US:" that it would fit with most of what is out there already, like Key:ref:US:EIA. But I wanted to check first. Thank you! --MattMap (talk) 22:25, 28 September 2023 (UTC)

Update - I found a conversation that seems to confirm it - Talk:Key:ref:us:ny:swis. They cite Key:ref:US:MA:SARIS as an example.--MattMap (talk) 02:53, 29 September 2023 (UTC)
Another update - I went and changed the tags to ref:US:NID so as to match ref:US:EIA and others. --MattMap (talk) 12:56, 29 September 2023 (UTC)

None namespaced refs

It would also be nice to list refs that aren't namespaced, specifically I'd like to link Key:fhrs:id, if it was starting today it would likely be ref:GB:fhrs.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:ref&oldid=2671720"