Documentation

OpenStreetMap tag or key
OpenStreetMap tagging schema (a Key:key, Tag:key=value, Relation:type, or Role:role) for classes, properties, and values

Represents

OpenStreetMap (Q936), OpenStreetMap Wiki (Q18635431)

Has quality

MediaWiki page title (Q83336425)

Data type

String

Domain

e.g. lighthouse (Q39715) (classes of geographical objects in Wikidata) (note: this should be moved to the property statements)

Allowed values

Key:.{1,255}|Tag:.{1,255}=.{1,255}|Relation:.{1,255}|Role:.{1,255}

Usage notes

用於連結開放街圖的屬性及其說明文件

Example

lighthouse (Q39715) → Tag:man_made=lighthouse
World Heritage Site (Q9259) → Key:ref:whc

Source

Map Features

Formatter URL

https://wiki.openstreetmap.org/wiki/$1

Discussion[edit]

Conflicts with instance of (P31); To be used with subclass of (P279) only?[edit]

Please use this property not for single objects, it's a property for classes of objects. So if the item has a coordinate to use this property is wrong. --Kolossos (talk) 08:57, 12 May 2014 (UTC)[reply]

I always thought, that classes of objects should not have instance of (P31) set, but instead subclass of (P279). But it seems as if many classes have instance of (P31) set. Should the classes be corrected (move instance of (P31)-attributes to subclass of (P279)) or should the "Conflicts with instance of (P31)"-constraint be dropped? --Floscher (talk) 15:40, 29 December 2014 (UTC)[reply]

It is not the case that classes on Wikidata do not have instance of (P31), so I suggest to drop this constraint. We have many meta-classes in Wikidata which have other classes as their instances. A better way to recognise classes is to require that there is a subclass of (P279) statement. The best way to recognise classes is to check if they are the value of some other item's instance of (P31) or subclass of (P279) statement, but I don't think we can express this in constraint templates. --Markus Krötzsch (talk) 07:29, 16 July 2015 (UTC)[reply]

Info Added missing section headline —MisterSynergy (talk) 10:11, 26 May 2017 (UTC)[reply]

Taginfo[edit]

Taginfo supports different external projects. The usage of this property is transfered by a little script that use Wikidata-Query in the background. --Kolossos (talk) 19:05, 11 October 2014 (UTC)[reply]

You can find all Wikidata-links in Taginfo. --Kolossos (talk) 17:43, 13 November 2014 (UTC)[reply]

How to tag multiple OSM keys?[edit]

In OpenStreetMap, it is very common for an object to be represented by a combination of keys. This can be that two keys are used to describe an object, like e.g. a community garden, which has "leisure=garden" and "garden:type=community". Or there exists (for historical reasons) more than one key to describe an object, e.g. for a bridge, which can be "man_made=bridge" if one wants to tag the outline or an unspecified bridge, or "bridge=yes" on the part of a highway or railway.

So the question is how to handle AND-conditions, where more than one OSM tag is used on an object, and OR-conditions, where different OSM-Tags exist for the same object? - SpeciesATosm (talk) 20:06, 31 October 2015 (UTC)[reply]

For the AND case, it is simple (in apparence), just add multiple instances of this property for the same object, specifying in value the "Key:k" or "Tag:k=v" (but note that in OSM, keys are just a part of a tag.

For the OR case, we could eventually have derived properties.

For now this property has only been defined using a scheme based on the OSM wiki page names (which are not always coherent... sometimes they refer to key parts, sometimes they will redirect instead to a feature page, listing the keys and values and their related conditions)

However it would be simpler to have in value a OSM QL selector (See OverPass Turbo for the details) for the and case, also because it can support Regexps (for OSM tag values and even for OSM tag keys).

Note however that an OSM QL selector only supports the AND-combinations; but in we could use then multiple occurences of this Wikidata property to give OR-combinations.

Also this property does not allow specifying the OSM object type (node/way/relation). This is not a problem when using a QL selector.

Adding a few simple examples of mapping between Wikidata items and OSM tags:

human settlement Q486972 ~= place=*
- city Q515 ~= place=city
place of worship Q1370598 ~= amenity=place_of_worship
- church Q16970 ~= amenity=place_of_worship + religion=christian + building=church
tower Q12518 ~= man_made=tower
railroad line Q728937 ~= shape:linear railway=rail,light_rail,narrow_gauge,subway,tram
- track gauge Q214519 ~= shape:linear railway=rail,light_rail,narrow_gauge,subway,tram + gauge=*
  - broad gauge track Q906942 ~= shape:linear railway=rail + gauge=1676

Most tags might have simple 1:1 mapping, but we see in the case of railroad, we cannot simply map it to the Key:railway as that OSM key is also used for platforms, stations and various other railway related infrastructure. How do we specify the allowable values for a particular key? --Planemad (talk) 05:21, 23 February 2017 (UTC)[reply]

Key:place, not Tag:place=*

For multiple distinct tags we can enter several values (see covered/shelter in shelter (Q7493941))

For tag1+tag2 = 1 WD item I suggest to use OpenStreetMap tag or key (P1282) as qualifiers or a more specific property for the same purpose. One chain should correspond to one value in WD. d1g (talk) 20:22, 11 May 2017 (UTC)[reply]

Although it appears that multiple occurrences of this property mean that they both have to be present for the mapping to hold, this is not a requirement of the setup. If it is meant to be true then there should be a very strong indication that it is so in the description of the property. Peter F. Patel-Schneider (talk) 17:06, 15 October 2017 (UTC)[reply]

subjects that are not classes of geographical objects[edit]

The domain of this property is supposed to be classes of geographical objects. However, I count 1142 subjects of triples for this property and 686 of them are not subclasses of geographical object (Q618123). Some of these, e.g., pedestrian crossing (Q8010), could perhaps be made subclasses, but many others, e.g., Q27349 dentist, are not geographical objects at all. What should be done? Right now the property is not useful. Peter F. Patel-Schneider (talk) 18:36, 17 October 2017 (UTC)[reply]

Hi again Peter F. Patel-Schneider,

First, are all - or even most - OSM tag about geographical objects? (OSM obviously is but not sure if it is true for OSM tag) I'm not sure but

⟨ beer (Q44)  

 ⟩ OpenStreetMap tag or key (P1282) ⟨ Key:drink:beer ⟩

seems ok to me even thought beer (Q44) is clearly not geographical. Same thing for others like

⟨ water skiing (Q472827)  

 ⟩ OpenStreetMap tag or key (P1282) ⟨ Tag:sport=water_ski ⟩

Then, you corrected pedestrian crossing (Q8010) (strangely but at least now it's a subclass of geographical feature (Q618123)) so this is ok now.

For dentist (Q27349) and 58 other occupations, here correction are still needed. The tag should be moved to a better matching item (items that should be creted if needed). I'll try to look into it this week-end.

Cdlt, VIGNERON (talk) 10:59, 18 October 2017 (UTC)[reply]

VIGNERON OSM is a database so you have to look at intended meaning. But the intent seems quite clear - points, lines, regions, etc. in OSM are geographical locations and the tags are about that location or the object located there. So maybe some OSM tags are about a pure location, but as far as I can tell the vast majority are about the object at the location.

So Tag:craft=watchmaker is not saying that the object at a location is a watchmaker but that the object at the location provides watchmaking services. Wikidata isn't very good at including these sorts of classes. Maybe it's not that a new Wikidata class should be created, but that there should be a property on commercial locations indicating the service provided.

There are many tags that work like this, such as denomination, which isn't saying that there is an instance of a particular religious denomination but that the religious establishment at the location adheres to that denomination.

Then there are the tags that map to objects, like Tag:amenity=waste_basket. Waste baskets aren't generally geographical objects, as most of them are moveable. However, it seems reasonable to say that OSM items with this tag are both waste baskets and geographical objects, i.e., waste baskets that are fixed in one place.

Yet other OSM tags have other behaviour. I've gone through and categorized many of them.

My view is that a fix to this property needs a complete examination of the property and its values to determine what to do. Point fixes aren't going to be nearly as effective. Peter F. Patel-Schneider (talk) 16:26, 18 October 2017 (UTC)[reply]

We seems to be more or less on the same page, what do you propose if you don't want to fix point? And why not create new items? (it wouldn't be useful only for OSM tag, but also for other items in Wikidata, for I just discovered that dental clinic (Q2979300) has no data yet). Cdlt, VIGNERON (talk) 16:47, 18 October 2017 (UTC)[reply]

It's not that I don't want to fix point it's that I don't want to just make point fixes, i.e., fixes to individual values of the property. Instead I want to do an examination of the property values as a whole and figure out a general scheme to make the fixes.

New Wikidata classes like watchmakerstore are not as useful as they seem at first glance unless they are linked to existing classes in Wikidata. Even then they are less useful than they could be because Wikidata doesn't allow for definitions of classes. Ideally it should be possible to *define* watchmakerstore as a store that provides the services of a watchmaker (or something like this). If instead watchmakerstore is just defined as a subclass of store then there isn't much that can be determined about it. A kind of store should have at least the amount of information that is present for bakery (Q274393). Peter F. Patel-Schneider (talk) 17:39, 18 October 2017 (UTC)[reply]

I did a quick analysis of the values of this property. I have suggestions for most of the values. Where is a good place to put this file? It's over 1200 lines long, so here may not be the best place. Peter F. Patel-Schneider (talk) 22:38, 18 October 2017 (UTC)[reply]

bakery (Q274393) is not a perfect example as there is a lot of junk/redundant data and constraints violations. But I get the idea and it would take only few minutes to make a 'watchmakerstore' item linked with other classes.

You can put some of you suggestions right here for example and put the complete list on a subpage of your userpage.

For more points of view, I'm notifying the top-10 user of this property: @Kolossos, Reclus, Edward, D1gggg, PanierAvide: @Planemad, JLZIMMERMANN, Wiki-Wuzzy, Hufkratzer, Avatar6:.

Cdlt, VIGNERON (talk) 17:52, 21 October 2017 (UTC)[reply]

Consider bank (Q22687) and bank building (Q18761864), both are tagged with Tag:amenity=bank. I guess we should remove the OSM tag from bank (Q22687). Edward (talk) 07:22, 22 October 2017 (UTC)[reply]

I don't think that this is the right way to go. Not all things in OSM are buidings. So something that is tagged with amenity bank could be part of a mall or other larger building. What is really needed is some sense of inference in Wikidata, i.e., something that is both a bank and a building is a bank building. For now, perhaps, it would be sufficient that the bank amenity tag just gives bank (Q22687) but together with a building tag it gives bank building (Q18761864). (Maybe this already happens?) Peter F. Patel-Schneider (talk) 06:35, 26 October 2017 (UTC)[reply]

I started a new section as the problems are not just that the subjects are not objects. Peter F. Patel-Schneider (talk) 06:30, 26 October 2017 (UTC)[reply]

fixing the values of this property[edit]

I put my analysis of the problems with the values of this property in a Google sheet https://docs.google.com/spreadsheets/d/18IHYtJNZOyAK2-DS_UH_HPn1uOF509ZuIJmxCMZaDOc/edit?usp=sharing When I get a chance, I'll work on some of the easiest changes. There are quite a number of holes in the analysis and quite a few cases showing that the mapping description is insufficient. Peter F. Patel-Schneider (talk) 06:29, 26 October 2017 (UTC)[reply]

I've started fixing some of the easy problems, adding superclasses and changing a few values. Peter F. Patel-Schneider (talk) 23:34, 6 November 2017 (UTC)[reply]

What do you think of values like this?
--- Jura 13:30, 7 November 2017 (UTC)[reply]

It's wrong and needs to be removed. Peter F. Patel-Schneider (talk) 15:52, 7 November 2017 (UTC)[reply]

Removed or moved? I think it's useful information in general, but I'm not sure what would be a good way to include it.
--- Jura 18:31, 7 November 2017 (UTC)[reply]

It's definitely in the wrong place. If there is a good place to put it, then fine, but I don't know if there is one. The same problem occurs for the highway levels - Wikidata just doesn't have good classes for them, and putting them on, for example, classes of English roads, is incorrect. My view is that it is better to miss some minor parts of OSM than to get them wrong. That said, it is possible to just create Wikidata classes for some OSM tags, which I have done, but to put an entire new overlay on an area doesn't seem reasonable. Peter F. Patel-Schneider (talk) 19:13, 7 November 2017 (UTC)[reply]

Applying to one item per country might work out. Another approach could be Wikidata:Property_proposal/admin_level.
--- Jura 19:21, 7 November 2017 (UTC)[reply]

I've made a major pass through the values, and fixed up a lot of them. I've also started a bit on how this property should be used, which I will clean up and put on this talk page. I've also updated the spreadsheet with a record of my changes. Peter F. Patel-Schneider (talk) 15:53, 7 November 2017 (UTC)[reply]

I've done a complete pass and all the non-deprecated values should match the characterization below. Peter F. Patel-Schneider (talk) 23:59, 7 November 2017 (UTC)[reply]

Fascinating mapping. It seems that these are either features (e.g. lighthouse, tennis venue with Tag:sport=tennis), attributes of features (tennis also with Tag:sport=tennis)), or properties at OSM (not sure how they name them there). Maybe criterion used (P1013) could be added to specify which it is (QuickStatements should make this fairly easy). Somehow it's sub-optimal, that some sports are added to sports venues others to sports types. The same goes probably for other tags as well. Maybe one should tag both when possible, but add P1013. Obviously, I'm not entirely sure how people would make use of them (here, at OSM, or elsewhere). Personally, I'd be mainly interested in the admin level thing here.
--- Jura 08:35, 8 November 2017 (UTC)[reply]

Hmm. That's an interesting way to go. The idea would be to embed the characterization below into criterion used (P1013) qualifications on the statements. I don't know whether criterion used (P1013) is used for this purpose, but if so then it should work well. There would have to be several Wikidata items added to be values for the qualification. Let me think about this for a bit. Peter F. Patel-Schneider (talk) 11:55, 8 November 2017 (UTC)[reply]

characterization of OpenStreetMap tag or key (P1282)[edit]

This property serves to connect OpenStreetMap keys and tags to Wikidata items and properties. A set of values for this property on a Wikidata item or property means that OpenStreetMap elements with all the values either belong to the item, have the item as a value for some property, or have a value for the property. If none of these are the case then this property should not be used.

There are two special OpenStreetMap keys that need to be handled specially:

wikidata: The value is the Wikidata item itself
wikipedia: The value is a Wikipedia link for the item.

Items that have a value for OpenStreetMap tag or key (P1282) should be one of the following:

a class that is a subclass of one of geographic region (Q82794), geographical feature (Q618123), geographic location (Q2221906), or physical location (Q17334923). (It would be better to have fewer of these, but there appears to be fluidity in this part of Wikidata so for safety they are all mentioned.): This is the normal case. It signals that any OpenStreetMap element with all the values of OpenStreetMap tag or key for the item is an instance of this item.
a class that is some other subclass of physical object (Q223557), e.g., barbecue (Q1546788): This signals that any OpenStreetMap element with all the values of OpenStreetMap tag or key (P1282) for the item is an instance of the item with the location of the element. This handles classes of physical objects that are not generally considered to be fixed in space.
a class that is an instance of profession (Q28640), e.g., dentist (Q27349).: This signals that the OpenStreetMap element with this value is a facility that provides the services of people with that profession. If there is a class for facilities that provide this service, then that class should have this value for OpenStreetMap tag or key instead (or maybe as well).
a class that is a subclass or instance of organization (Q43229): This signals that the OpenStreetMap element with this value is a facility that provides the services that the organization or organization class provides.
a class that is a subclass (or instance?) of religion (Q9174), e.g., Buddhism (Q748): This signals that the element has this as a value for religion or worldview (P140).
a class that is an instance (or subclass?) of cuisine (Q1778821), e.g., Australian cuisine (Q783010): This signals that the element has this as a value for cuisine (P2012).
a class that is a subclass (or instance?) of sport (Q349), e.g., badminton (Q7291): This signals that the element has this as a value for flag image (P41).
an item that is an instance of track gauge (Q214519), e.g., 1000 mm track gauge (Q24609): This signals that the element has this as a value for track gauge (P1064).
an item that is an instance of payment system (Q986008), e.g., Troika card (Q15145883): This signals that the element has this as a value for payment types accepted (P2851).
an item that is an instance of currency (Q8142), e.g., Euro (Q4916): This signals that the element has this as a value for currency (P38).
a property, e.g., house number (P670): This is only used for keys and only for properties that have String or Quantity or URL or External Identifier or Monolingual text or Point in time as datatype. It signals that the OpenStreetMap element's value for this key is the value of the property.

Not all items with a value for OpenStreetMap tag or key (P1282) currently correctly fit into this characterization. Most values that do not do so have been marked as deprecated. The plan is to augment the above characterization so that all non-deprecated values fit correctly into it.

Peter F. Patel-Schneider (talk) 16:46, 7 November 2017 (UTC)[reply]

Maybe this could be described with complex constraints? See sample above.
--- Jura 19:11, 7 November 2017 (UTC)[reply]

That's definitely a good idea if it works. Peter F. Patel-Schneider (talk) 19:17, 7 November 2017 (UTC)[reply]

conjunctive vs disjunctive for multiple values[edit]

@VIGNERON, D1gggg, Edward, Jura1: I took a look at all the multiple values for OpenStreetMap tag or key (P1282). After fixing a few, 46 remain. Of these, 42 are disjunctive, such as Tag:building=bell_tower and Tag:tower:type=bell_tower on bell tower (Q200334). There are four that are conjunctive, for church building (Q16970), Hindu temple (Q842402), bicycle bridge (Q2502622), and toll bridge (Q7814330). Given the preponderance of disjunctive uses, I propose to eliminate the conjunctive ones and fix up places where the conjunctive reading is implied. Peter F. Patel-Schneider (talk) 14:13, 8 November 2017 (UTC)[reply]

Sounds reasonable unless OSM gives some special meaning to the second group. For church building (Q16970) one might argue that it's part of the first group.
--- Jura 16:38, 8 November 2017 (UTC)[reply]

OK. I left church building (Q16970) in the group out of an excess of caution. I'll fix it, but defer the others for a little bit. Peter F. Patel-Schneider (talk) 17:29, 8 November 2017 (UTC)[reply]

Using criterion used (P1013) for characterizing the different meanings of values for OpenStreetMap tag or key (P1282)[edit]

Jura suggested that criterion used (P1013) could be used to characterize the different meanings of values for OpenStreetMap tag or key (P1282). I think that this could work something like the following.

If a value of OpenStreetMap tag or key (P1282) doesn't have a qualification using criterion used (P1013) it doesn't participate in the mapping.

Create a subclass of Wikidata-specific criterion (Q27949687) for criteria specific to the OSM to Wikidata mapping and the following instances of this class, to be used as values of criterion used (P1013)

Wikidata class for OSM tag

OSM entries that have this tag are instances of the Wikidata item

e.g., windsock (Q216346) Tag:aeroway=windsock

e.g., heliport (Q502074) Tag:aeroway=heliport

e.g., bakery (Q274393) Tag:craft=bakery

Wikidata class for OSM key

OSM entries that have this key with any value are instances of the Wikidata item

e.g., tunnel (Q44377) Key:tunnel

e.g., military facility (Q18691599) Key:military

Wikidata property for OSM key

The statement provides a property for uses of the key.

If the property doesn't have items as values then for OSM entries that have a tag using this key a value of the property for the entry is the tag value, suitably transformed.

Otherwise this is used with Wikidata property value for OSM tag below

e.g., house number (P670) Key:addr:housenumber

e.g., population (P1082) Key:population

e.g., religion or worldview (P140) Key:religion

e.g., religion or worldview (P140) Key:denomination

e.g., cuisine (P2012) Key:cuisine

e.g., sport (P641) Key:sport

This has problems with crafts and amenities because there doesn't appear to be a suitable Wikidata property.

e.g., ?? service provided Key:craft

e.g., ?? service provided Key:amenity

Wikidata property for OSM tag

The statement provides a property for uses of the tag

e.g., sport (P641) Tag:leisure=miniature_golf

Wikidata property value for OSM tag

The statement provides a value for the tag.

If there is a Wikidata property for OSM tag on the tag then use that property

Otherwise if there is a Wikidata property for OSM key on the key then use that property for OSM entries that have this tag,

The Wikidata item is a value of the property for the entry

e.g., beekeeper (Q852389) Tag:craft=beekeeper

e.g., bicycle-sharing system (Q1358919) Tag:amenity=bicycle_rental

Does this seem like a reasonable way to go? Has anything like this been done before? Note that there has to be some solution for crafts and amenities whose values are professions for this all to work well. Peter F. Patel-Schneider (talk) 17:49, 8 November 2017 (UTC)[reply]

I'm not entirely sure how to read it. I think around minature golf there is some slip. Where would tennis be? A sample use for P1013 at Q10082670#P461, a more basic one at Q4925477#P1889.
--- Jura 19:16, 8 November 2017 (UTC)[reply]
- Tennis and miniature golf would work like

sport (P641) OpenStreetMap tag or key (P1282) "Key:sport" qualifier criterion used (P1013) Wikidata property for OSM key

{P|641}} OpenStreetMap tag or key (P1282) "Tag:leisure=miniaure_golf" qualifier criterion used (P1013) Wikidata property for OSM tag

miniature golf (Q754796) OpenStreetMap tag or key (P1282) "Tag:leisure=miniature_golf" qualifier criterion used (P1013) Wikidata property value for OSM tag

tennis (Q847) OpenStreetMap tag or key (P1282) "Tag:sport=tennis" qualifier criterion used (P1013) Wikidata property value for OSM tag

I did another thought and came up with a possibly better method. I'll put that in shortly. Peter F. Patel-Schneider (talk) 19:37, 8 November 2017 (UTC)[reply]

As for amenity, it's probably either "use" or P31. Craft might be industry, but I don't think we have that many individual shops with items. This is likely to change with further Wikivoyage integration.
--- Jura 19:26, 8 November 2017 (UTC)[reply]
- I don't think that instance can be used here. What is really needed is the relationship between a bakery and the profession of baker. I don't think that this exists in Wikidata at the moment. Peter F. Patel-Schneider (talk) 19:48, 8 November 2017 (UTC)[reply]

Not using criterion used (P1013) for characterizing the different meanings of values for OpenStreetMap tag or key (P1282)[edit]

I think that there is a simpler way to characterize the different meanings of values for OpenStreetMap tag or key (P1282). The basic idea is to pick up the property to use via a uses property (P3176) qualifier on the statement for the tag if there is one, otherwise using a OpenStreetMap tag or key (P1282) statement for the key if there is one, otherwise using instance of (P31). This has the advantage of not needing criterion used (P1013) qualifiers. OpenStreetMap tag or key (P1282) statements that don't have a Wikidata meaning would have a uses property (P3176) qualifier with an unknown or no value.

Here is the pseudo-code to go from OSM tags to Wikidata properties and values:

 for any OSM entry with tag for key k and value v (="Tag:k=v")
 if there are any Wikidata entities with statement {{P|1282}}="Tag:k=v"
   where entity is not a property (=item)
   then for each of them 
       if there is a qualifier {{P|3176}}=p then p is the property
       else if there is a Wikidata statement p:{{P|1282}}="Key:k"
       	    with p being a property, then p is the property
       else the property is {{P|31}}
       the entry has item for the property,
       unless the property has special values unknown or no value
 else for each Wikidata statements p {{P|1282}} "Key:key"
     where p is a Wikidata property whose values are not items (=external identifier, string, etc., e.g. key:phone)
         if there is a qualifier {{P|3176}} p2 then p2 is the property
         else p is the property
         the entry has value v, suitably transformed, for the property
 	 unless the property has special values unknown or no value
     for each Wikidata entity with statement {{P|1282}} "Key:key"
     where entity is not a property (e.g. Q1267889 with Key:waterway)
 	  if there is a qualifier {{P|3176}} p2 then p2 is the property
          else {{P|31}} is the property
          the entry has the item as value for the property
 	  unless the property has special values unknown or no value

This scheme can handle conjunctive values by putting OpenStreetMap tag or key (P1282) qualifiers on the satements and conditioning every use of a statement above by checking that for every qualifier OpenStreetMap tag or key (P1282) "Tag:k2=v2" then the entry also has a tag for k2 and v2 and for every qualifier OpenStreetMap tag or key (P1282) "Key:k2" then the entry also has a tag for k2 with any value.

Example statements

sport (P641) OpenStreetMap tag or key (P1282) "Key:sport"
miniature golf (Q754796) OpenStreetMap tag or key (P1282) "Tag:leisure=miniature_golf" qualifier uses property (P3176) sport (P641)
tennis (Q847) OpenStreetMap tag or key (P1282) "Tag:sport=tennis"
bell tower (Q200334) OpenStreetMap tag or key (P1282) "Tag:building=bell_tower"
cable transport (Q1054650) OpenStreetMap tag or key (P1282) "Key:aerialway"
Hindu temple (Q842402) OpenStreetMap tag or key (P1282) "Tag:amenity=place_of_worship" qualifier OpenStreetMap tag or key (P1282) "Tag:religion=hindu"

Comments? Peter F. Patel-Schneider (talk) 21:40, 8 November 2017 (UTC)[reply]

Interesting helps me discover OSM keys and tags.
Trying to read the pseudo-code, I made a couple of edits diff. It might no longer be pseudo-code, but easier for me. Please revert if you mind. It might gain by adding a sample for every part. "entity" is the Wikidata term for a property or an item.
BTW, P3176 is generally used to describe the use by a specific paper of a property. If it's merely to describe a mapping, personally I use Property:P1659, constraints use Property:P2306.
So if the OSM relation linked from Q5434135 had "Tag:leisure=miniature_golf" then, the item should have sport (P641)=miniature golf (Q754796). Inversely, if the item had that statement, one might need to add to the description to resolve it.
BTW, OSM describes "Tag:sport=tennis" as a feature that is a tennis court.
--- Jura 08:02, 9 November 2017 (UTC)[reply]
- I'm not wed to using "uses property" but it sounds good. see also doesn't work for me.
- The tennis thing is a bit weird. It could be handled, but is it really true that everything with this tag is a tennis court? Some of them may be stadiums or stores. I would be cautious without evidence to the actual usage of the tag. Peter F. Patel-Schneider (talk) 15:53, 9 November 2017 (UTC)[reply]
  - The description mentions Roland Garos which has several courts with the main situated in a stadium.
    --- Jura 09:21, 10 November 2017 (UTC)[reply]
    - This is actually a good example where reality does not conform with documentation. The stadium is tagged with sport=tennis but it is not a tennis court. The court in it is tagged as leisure=pitch but it is not mostly open. So it is not the case that sport=tennis implies by itself that the element is a tennis court.
    - So it looks as if leisure=pitch, sport=tennis is a tennis court (Q741118) and leisure=stadium, sport=tennis is a tennis venue (Q13380226). This needs conjunctive tagging as above. I've put this information on both of these.
    - I also have some (crappy) python code that implements the mapping described above. Peter F. Patel-Schneider (talk) 14:16, 10 November 2017 (UTC)[reply]

I think that this all works well, with the exception of the missing property. What is the best way to get larger coverage for it? Peter F. Patel-Schneider (talk) 19:55, 10 November 2017 (UTC)[reply]
- It seems. Obviously it involves some uncertainty as the use of the tags at OSM seems to be a moving target. As for the qualifier, maybe P2306 is more suitable. I'm just curious what would end up on the "unknown"/"no value" parts of the decision trees. Would you add more samples in the pseudocode? --
  --- Jura 20:21, 10 November 2017 (UTC)[reply]
  - I'll put together some more examples. Peter F. Patel-Schneider (talk) 21:11, 10 November 2017 (UTC)[reply]
    - If you don't mind, would you switch to P2306?
      --- Jura 05:23, 15 November 2017 (UTC)[reply]

Sample values for OpenStreetMap tag or key (P1282)[edit]

Entries that have tag "aerialway=gondola" become instances of gondola lift (gondola lift (Q1576693))

gondola lift (Q1576693) OpenStreetMap tag or key (P1282) "Tag:aerialway=gondola"

Entries that have any value for key "tunnel" become instances of tunnel (tunnel (Q44377))

tunnel (Q44377) OpenStreetMap tag or key (P1282) "Key:tunnel"

Entries with tag values for the key "sport" become values for sport (sport (P641))

sport (P641) OpenStreetMap tag or key (P1282) "Key:sport"

tennis (Q847) OpenStreetMap tag or key (P1282) "Tag:sport=tennis"

badminton (Q7291) OpenStreetMap tag or key (P1282) "Tag:sport=badminton"

Tag values for the key "cuisine" become values for the property cuisine (cuisine (P2012)), and don't produce any direct relationship to the item cuisine (cuisine (Q1778821))

cuisine (P2012) OpenStreetMap tag or key (P1282) "Key:cuisine"

cuisine (Q1778821) OpenStreetMap tag or key (P1282) "Key:cuisine"

qualifier uses property (P3176) unknown value

Greek cuisine (Q744027) OpenStreetMap tag or key (P1282) "Tag:cuisine=greek"

Entries that have tag "leisure=miniature_golf" have value Miniature golf (miniature golf (Q754796)) for sport (sport (P641))

miniature golf (Q754796) OpenStreetMap tag or key (P1282) "Tag:leisure=miniature_golf"

qualifier uses property (P3176) sport (P641)

Entries that have both tags "leisure=pitch" and "sport=tennis" become instances of tennis court (tennis court (Q741118))

tennis court tennis court (Q741118) OpenStreetMap tag or key (P1282) "Tag:leisure=pitch"

qualifier OpenStreetMap tag or key (P1282) "Tag:sport=tennis"

Entries that have tag "sport=chess" don't get any sport (sport (P641)) value even though "sport=chess" in OSM is about chess (because chess isn't really a sport}}

NB: Not done, just given here for illustrative purposes

chess OpenStreetMap tag or key (P1282) "Tag:sport=chess"

qualifier use property unknown

Entries that have key "internet_access" do not produce any statements even though internet_access is related to internet access (internet access (Q1472399))

internet access (Q1472399) OpenStreetMap tag or key (P1282) "Key:internet_access"

qualiifier use property unknown

Peter F. Patel-Schneider (talk) 15:01, 12 November 2017 (UTC)[reply]

For items that currently don't have any statements, this could bring a good basis (when added). I'm not sure if it would work out for existing ones (when added), but it could work for consistency checks (when querying, not adding).
BTW, for Wikivoyage, we once made Wi-Fi access (P2848).
--- Jura 13:05, 14 November 2017 (UTC)[reply]

Wikidata properties for results of OSM query ( node(48.8467, 2.2488, 48.8470, 2.2491); way(48.8466, 2.2488, 48.8470, 2.2491); rel(48.8466, 2.2488, 48.8468, 2.2491); ); out;[edit]

Element {u'building': u'yes', u'wikidata': u'Q3026397', u'wikipedia': u'fr:Court Philippe-Chatrier', u'type': u'multipolygon', u'name': u'Court Philippe Chatrier'}

RESULT (key): instance of (P31) building (Q41176)

RESULT (special): (WIKIDATA ENTITY) http://www.wikidata.org/entity/Q3026397

RESULT (special): (WIKIPEDIA LINK) https://fr.wikipedia.org/wiki/Court Philippe-Chatrier

Element {u'name': u'All\xe9e Marcel Bernard', u'highway': u'pedestrian'}

RESULT (tag): instance of (P31) pedestrian zone (Q369730)

Element {u'building': u'yes', u'source': u'cadastre-dgi-fr source : Direction G\xe9n\xe9rale des Imp\xf4ts - Cadastre. Mise \xe0 jour : 2010', u'wall': u'no'}

RESULT (key): instance of (P31) building (Q41176)

Element {u'source': u'cadastre-dgi-fr source : Direction G\xe9n\xe9rale des Imp\xf4ts - Cadastre. Mise \xe0 jour : 2010', u'sport': u'tennis', u'name': u'Court Philippe Chatrier', u'leisure': u'stadium'}

RESULT (tag): sport (P641) tennis (Q847)

RESULT (tag): instance of (P31) stadium (Q483110)

RESULT (tag): instance of (P31) tennis venue (Q13380226)

Element {u'source': u'cadastre-dgi-fr source : Direction G\xe9n\xe9rale des Imp\xf4ts - Cadastre. Mise \xe0 jour : 2010'}

Element {u'source': u'bing 2011', u'highway': u'pedestrian'}

RESULT (tag): instance of (P31) pedestrian zone (Q369730)

Element {u'source': u'bing 2011', u'amenity': u'parking', u'parking': u'surface'}

RESULT (tag): instance of (P31) parking lot (Q6501349)

Element {u'website': u'http://fft.fr/', u'wikipedia': u'fr:F\xe9d\xe9ration Fran\xe7aise de Tennis', u'wikidata': u'Q1349946', u'name': u'F\xe9d\xe9ration Fran\xe7aise de Tennis', u'office': u'association'}

RESULT (key): official website (P856) http://fft.fr/

RESULT (special): (WIKIPEDIA LINK) https://fr.wikipedia.org/wiki/Fédération Française de Tennis

RESULT (special): (WIKIDATA ENTITY) http://www.wikidata.org/entity/Q1349946

Peter F. Patel-Schneider (talk) 15:01, 12 November 2017 (UTC)[reply]

Wikidata properties for synthetic OSM tag sets[edit]

Element {u'building': u'terrace'}

RESULT (tag): instance of (P31) terraced house (Q875016)

Element {u'building': u'temple'}

RESULT (tag): instance of (P31) temple (Q44539)

Element {u'sport': u'tennis'}

RESULT (tag): sport (P641) tennis (Q847)

Element {u'leisure': u'pitch'}

RESULT (tag): instance of (P31) pitch (Q2310214)

Element {u'sport': u'tennis', u'leisure': u'pitch'}

RESULT (tag): sport (P641) tennis (Q847)

RESULT (tag): instance of (P31) tennis court (Q741118)

RESULT (tag): instance of (P31) pitch (Q2310214)

Element {u'leisure': u'stadium'}

RESULT (tag): instance of (P31) stadium (Q483110)

Element {u'sport': u'tennis', u'leisure': u'stadium'}

RESULT (tag): sport (P641) tennis (Q847)

RESULT (tag): instance of (P31) stadium (Q483110)

RESULT (tag): instance of (P31) tennis venue (Q13380226)

Element {u'cuisine': u'greek'}

RESULT (tag): cuisine (P2012) Callums cuisine (Q744027)

Element {u'leisure': u'miniature_golf;bandstand'}

RESULT (tag): sport (P641) miniature golf (Q754796)

RESULT (tag): instance of (P31) bandstand (Q3126170)

Element {u'tunnel': u'yes'}

RESULT (key): instance of (P31) tunnel (Q44377)

Element {u'operator': u'KQED'}

Element {u'start_date': u'55'}

RESULT (key): start time (P580) 55

Element {u'building': u'temple', u'religion': u'hindu', u'sport': u'tennis;golf', u'start_date': u'55', u'leisure': u'miniature_golf;bandstand'}

RESULT (tag): instance of (P31) Hindu temple (Q842402)

RESULT (tag): instance of (P31) temple (Q44539)

RESULT (tag): religion (P140) Hinduism (Q9089)

RESULT (tag): sport (P641) tennis (Q847)

RESULT (tag): sport (P641) golf (Q5377)

RESULT (key): start time (P580) 55

RESULT (tag): sport (P641) miniature golf (Q754796)

RESULT (tag): instance of (P31) bandstand (Q3126170)

Peter F. Patel-Schneider (talk) 15:01, 12 November 2017 (UTC)[reply]

how to relate a bakery to baker[edit]

The main missing piece required to complete the mapping from OSM tags to Wikidata statments is a property that relates a facility to the service or craft that the facility utilizes. Does anyone have any suggestions for this property, or should a new property be created? – The preceding unsigned comment was added by Peter F. Patel-Schneider (talk • contribs).

Maybe "baker" "uses" "bakery" qualified with "object has role" and some item ("workplace"?).
--- Jura 20:27, 10 November 2017 (UTC)[reply]
- I don't know if that does the right thing. What is needed is a property that relates a particular bakery (like the one around the corner from my house) to baker (Q160131). I don't think that baker (Q160131) uses that particular bakery. However, it just might be that "uses" is vague enough to relate a bakery to baker (Q160131). Peter F. Patel-Schneider (talk) 21:09, 10 November 2017 (UTC)[reply]
  - The reverse would be "bakery" "used by" "baker" "subject has role" "workplace". Specific instances of bakery wouldn't have a direct link.
    --- Jura 21:18, 10 November 2017 (UTC)[reply]

craft=brewery ; craft=carpenter ; craft=plasterer ; craft=shoemaker ; craft=plumber ; craft=bakery ; craft=chimney_sweeper ; craft=roofer ; craft=gardener ; craft=tiler ; craft=upholsterer ; craft=blacksmith ; craft=turner ; craft=confectionery ; craft=glaziery ; craft=builder ; craft=distillery ; craft=sawmill ; craft=photographic_laboratory ; craft=tinsmith ; craft=floorer ; craft=bookbinder ; craft=saddler ; craft=stand_builder ; craft=electrician ; craft=stonemason ; craft=sailmaker ; craft=painter ; craft=boatbuilder ; craft=beekeeper ; craft=basket_maker ; craft=sculptor ; craft=dressmaker ; craft=photographer ; craft=winery ; craft=clockmaker ; craft=watchmaker ; craft=piano_tuner ; craft=scaffolder ; craft=optician ; craft=pottery ; craft=handicraft ; craft=locksmith ; craft=metal_construction ; craft=rigger ; craft=caterer

Maybe "bakery" or "brewery" aren't particularly relevant, as the craft tags are "bakery" or "brewery". Others might work less well: carpenter, plasterer, shoemaker, plumber, etc. Probably items about specific instances of any of these are rare (shops, not people with these professions). Possibly we have some businesses with a "headquarter location".
--- Jura 09:25, 11 November 2017 (UTC)[reply]
- I agree that particular plumbing stores are rather rare in Wikidata. But there are (presumably) lots of plumbing stores in OpenStreetMap and the question is what to do about them, and all the other stores there, so that information about them can be viewed in a Wikidata context. This would arise, for example, for those plumbing stores that are notable or when someone wants to augment Wikidata with the non-notable information from OpenStreetMap. I was hoping that Wikidata already had an appropriate property. In the absence of that, I guess that the best way forward is to go ahead and create the appropriate subclasses of store. Peter F. Patel-Schneider (talk) 13:03, 11 November 2017 (UTC)[reply]
  - It should be possible to find listings for many crafts in Wikivoyage. Eventually these should get items at Wikidata so the question is fairly practical in nature.
    --- Jura 16:13, 11 November 2017 (UTC)[reply]

I was looking around for a Wikidata property that could be used to relate a place to a craft. It appears that there is one - field of work (P101), which provides "specialization of a person or organization". Peter F. Patel-Schneider (talk) 18:17, 13 November 2017 (UTC)[reply]

I'm not entirely sure what type of place you'd be looking at. In general, I'd think it's industry (P452) or "use", e.g. for factory buildings. For stores, maybe this would be in P31. Not sure if much beyond P31 would be needed for entries in voy:Jakarta/Central#Buy.
--- Jura 20:04, 13 November 2017 (UTC)[reply]
- This is for things tagged with, e.g., "craft=basket_weaver" or "healthcare=dentist:, where the tag is currently associated with a profession. industry (P452) seems very wrong, and "use" doesn't seem any better. It may be that to make field of work (P101) work best the associations would have to be changed from the occupation to the field, e.g., from dentist to dentistry, although I hope that that is not needed. By the way, according to the OSM documentation, craft is not usually for stores but for any (or maybe another) place where the occupation is practised. Peter F. Patel-Schneider (talk) 22:57, 13 November 2017 (UTC)[reply]
  - Maybe it would be good to look at a couple of items or Wikivoyage listings to which this would apply. I suppose "field of work" of a baker would be "baking".
    --- Jura 08:00, 14 November 2017 (UTC)[reply]

Here are the occupations that currently have OSM tags, and their field of work. Quite a few either have no field of work or have incorrect fields of work. I'll try to fix some of the incorrect ones, particularly for baker.

brewer : : brewing

caterer : catering

midwife : midwifery

cobbler : shoemaking

plumber : plumbing

boat builder : boat building

blacksmith : forging

dressmaker : dressmaking

basket weaver : basketry

carpenter : carpentry

physician : medicine

audiologist : audiology

photographer : photography

gardener : gardening

sculptor : art of sculpture

piano tuner : piano tuning

winegrower : winemaking

optometrist : optometry

tailor : : tailoring

stonemason : stonemasonry

beekeeper : bee-keeping

dentist : dentistry

locksmith : locksmithing

veterinarian : veterinary medicine

metalsmith : forging

tinsmith : tinsmithing3

tapestry weaver : tapestry weaving

psychotherapist : psychotherapy

occupational therapist : occupational therapy

speech and language therapist : speech-language pathology

house painter : interior architecture

scaffolder : scaffold

baker : : pastry

baker : : cake

handicrafter : handicraft

hairdresser : hair

plasterer : gypsum

potter : : pottery

distiller : distillery

stationer : retail

chimney sweep :

roofer :

sailmaker :

Floorer :

turner :

electrician :

watchmaker :

Rigger :

exhibition stand builder :

optician :

saddler :

funeral director :

tiler :

The need is to determine what claim is true of an OpenStreetMap entry that has a tag that needs one of these values, such as craft=carpenter.

Option one is to use the occupation carpenter directly, but that needs a Wikidata property relating a carpenter's craft location to carpenter. The wikidata property occupation is reasonable except that it is supposed to be only used for people. I currently prefer liberalizing this property to allow it to be used for more things than people.

Option two is to use the field of work. The Wikidata property field of work seems fine. The problem here is that many occupations don't have a good field of work.

Option three is to use the industry. I don't think that this can work as it is not specific enough. For example, the industry for most medical occupations would be medicine.

Peter F. Patel-Schneider (talk) 16:22, 14 November 2017 (UTC)[reply]

I'm still curious to see which actual Wikidata items (or Wikivoyage listing entries) would have this need.
--- Jura 19:15, 14 November 2017 (UTC)[reply]
- I was thinking that there are very few items in Wikidata that are analogous, but I quickly found one. Roof Commander, Inc. (Q28753801) is a roofing contractor (and not a human) but has an occupation (P106) value of roofing contractor (Q27057193). This is precisely what I think is needed, a link from an organization to the occupation whose services it provides. (PS: I changed the incorrrect human type to business enterprise.) Peter F. Patel-Schneider (talk) 22:07, 14 November 2017 (UTC)[reply]
  - I don't think it should be using P106. Looks like Wikidata:WikiProject_Companies/Properties hasn't gotten there yet. How would you add an OSM relation statement to Q28753801 ? Within "headquarter location"?
    --- Jura 05:22, 15 November 2017 (UTC)[reply]
    - I don't think that Roof Commander, Inc. (Q28753801) needs any OSM-related property on it. Instead it needs a property saying what service it provides. Is there a good way of saying this in Wikidata? If so, then it can be used by an OSM mapping. Peter F. Patel-Schneider (talk) 16:00, 20 November 2017 (UTC)[reply]

Add to properties if possible?[edit]

Should keys be added to properties (if possible) or to both items and properties?

Yesterday I tried to find a place to add "Key:cuisine". I found an item and added it there. Then I noticed we have property for that so I moved it over. Looks reasonable.
Another key was "Key:denomination". We have an item for that as well, but the property that is used to add a statement about the denomination to an item is "religion". Should it go there? The property already have "Key:religion".
--- Jura 09:11, 11 November 2017 (UTC)[reply]

The question in my mind here is just what the full meaning of OpenStreetMap tag or key (P1282) is. The original meaning appears to have been that OpenStreetMap tag or key (P1282) related OpenStreetMap keys and tags to Wikidata classes, and that OpenStreetMap entries with the key or tag represented real-world entities that belonged to the class. This doesn't work well, because lots of OpenStreetMap tags don't invoke this idea. For example, sport=tennis doesn't mean that the entity is an instance of tennis, unless the Wikidata meaning of tennis as a class is something like any entity that is somehow related to tennis. My recent work here has been to try to get a Wikidata meaning for qualified values of OpenStreetMap tag or key (P1282) that can be automatically applied to the entities represented in OpenStreetMap.

So what about applying OpenStreetMap tag or key (P1282) to properties, specifically associating both a property and an item to the same key. I am of two minds here. Associating to just the property says that the OpenStreetMap key "cuisine" represents the Wikidata cuisine property, i.e., that its appearance is not just about a cuisine but is about the relationship (cuisine (P2012)) between something (often a restaurant) and a cuisine that that thing (restaurant) provides (serves). Adding a relationship to the item (here a class) muddies the waters a bit. That said, there is nothing particularly bad about also having the item associated as well, provided that there is no implication that the association implies that OpenStreetMap entries with the key belong to the item. My augmented interpretation of OpenStreetMap tag or key (P1282) allows for this by using a uses property (P3176) qualifier with unknown value, here roughly saying that there is some relationship between OpenStreetMap entries with key "cuisine" and cuisine (Q1778821) but that there isn't necessarily a good way of stating this in Wikidata. I've added the OpenStreetMap tag or key (P1282) information back to cuisine (Q1778821) and added the qualifier. So an OpenStreetMap entry with tag "cuisine=greek" is interpreted as an entity with cuisine (P2012) value Greek cuisine (Q744027) but with no direct Wikidata relationship to cuisine (Q1778821). I've run "cuisine=greek" through my prototype code and the desired result is produced - a cuisine (P2012) claim with value Greek cuisine (Q744027) and nothing for cuisine (Q1778821). Peter F. Patel-Schneider (talk) 13:36, 11 November 2017 (UTC)[reply]

Sounds ok. Somehow the English label of Q744027 is currently the name of a restaurant, so it's slightly confusing ;). We should have instances of restaurants that have P3176 set to a specific cuisine.
--- Jura 16:16, 11 November 2017 (UTC)[reply]

"_" or " " as value[edit]

There was a question if the values should be normalized to "_" or include " ". The regex allows " " for values ("water well" or "water_well"), but not the tag ("Tag:man_made=", not "Tag:man made="). The proposal for the property in 2014 already included that last part. Currently values entered with " " are normalized to "_".

Should we keep using "Tag:man_made=water_well" or use "Tag:man_made=water well"? There are 380 values currently using "_".
--- Jura 11:32, 22 March 2018 (UTC)[reply]

Maybe I didn't understand the question. AFAIK in OSM we don't use blanks in tags. "man_made=water_well" currently occurs 88776 times in the OSM database and "man_made=water well" (with blank) only once. --Hufkratzer (talk) 16:03, 8 May 2018 (UTC)[reply]

We had some user complain about the autofix. --- Jura 14:57, 31 October 2018 (UTC)[reply]
Although in Taginfo "␣" is seen, the space is always used for the values of the key "species". Davileci (talk) 00:56, 9 September 2023 (UTC)[reply]

Spaces might be used. But lets think first. Usage both "_" and " " is not good idea. Because "Unique value" constraint will not detect some duplicate items. Usage space for species and "_" for all other types is looked as redundant complexity of data model. Spaces also might be not good because there are several space types: usual space, non-breaking space and etc. All these types have the same look. Mistakes with space type are invisible. So we may migrate to spaces in all values, but I prefer to keep current data model with "_". — Ivan A. Krestinin (talk) 00:08, 13 November 2023 (UTC)[reply]

We use spaces in several tags in OSM. Most notably in name=* and other name-like like say species=*. There are also freeform tags like fixme, note, description. opening_hours has own syntax. snake_case is used for symbolic codes, say highway=bus_stop. And note that in general I would advise against editing OSM Wiki based on Wikidata claims. Especially when done without checking actual use of tags in OSM. I would expect that basically all or all OSM tags with wikidata entries will have _ rather than spaces. Mateusz Konieczny (talk) 17:39, 1 April 2024 (UTC)[reply]

Use wikidata items as values[edit]

Why not create items for every OSM tag and use them as values of this property?--Malore (talk) 21:32, 5 April 2018 (UTC)[reply]

Confusion with P402[edit]

Please explain here, to public, how to avoid confusion with Property:P402.
--Krauss (talk) 11:47, 6 July 2018 (UTC)[reply]

Here are labels and descriptions of the two:

OpenStreetMap relation ID (P402): identifier for a relation in OpenStreetMap
OpenStreetMap tag or key (P1282): OpenStreetMap tagging schema (a Key:key, Tag:key=value, Relation:type, or Role:role) for classes, properties, and values

OSM people generally know the difference between the two. Are there parts of the OSM website where these two are confused? --- Jura 14:55, 31 October 2018 (UTC)[reply]

Split keys and tags ?[edit]

If keys and tags are split in 2 wikidata properties, there will be 2 benefits:

It's easy to edit it
- use man_made=lighthouse instead of Tag:man_made=lighthouse
- use ref instead of Key:ref
It's possible to add an formatter URL that work with TagInfo
- https://taginfo.openstreetmap.org/keys/ref
- https://taginfo.openstreetmap.org/tags/man_made=lighthouse

Pyrog (talk) 09:23, 11 October 2019 (UTC)[reply]

Regex[edit]

@Mxn: I noticed you added the regex for this property. I'm not sure why, but it complains when the value is, e.g. Tag:opening_hours:covid19=closed. See closed to the public (Q55570340). What could be the issue? NMaia (talk) 10:35, 22 September 2020 (UTC)[reply]

@NMaia: I think the issue was that this change caused the key portion of the "Tag:" branch of the regular expression to disallow digits. I've corrected the regex and also added an allowance for "Relation:" values. – Minh Nguyễn ^💬 18:27, 3 January 2021 (UTC)[reply]

Use data items from OSM-Wiki instead of the Article names?[edit]

There are Wikibase items in the OpenStreetMap wiki for the key and tag pages, so I think it would make sense to use the ID of the item instead of the title of the article about that tag or key. Example: Instead of Tag:amenity=parking, Q4904 would be used. --Floscher (talk) 13:41, 22 January 2021 (UTC)[reply]

This was proposed at Wikidata:Property proposal/OpenStreetMap wiki ID. --- Jura 14:47, 22 January 2021 (UTC)[reply]

Proposal in OSM wiki to remove Wikidata links from OSM wiki pages[edit]

This is just to inform you (in case you don't already know) that there is currently an active proposal discussed in the OSM wiki and on the corresponding mailing list to "remove alphanumeric code visible in infoboxes at OSM Wiki linking to Wikidata", see [1] and [2] --Hufkratzer (talk) 12:38, 27 January 2021 (UTC)[reply]

Just to clarify, that proposal is just for removing the link to Wikidata from the infobox in wiki articles. There are still links to wikidata in the data items of the OSM wiki. They would just not be displayed as prominently in the interface as before, because for mappers for OSM that information is not that useful to have. People who need that information can still get it from data items in the OSM wiki. --Floscher (talk) 13:02, 27 January 2021 (UTC)[reply]

Thanks for the info. It seems to be an internal question at OSM. It does seem odd that OSM's QID on OSM pages is less prominent than Wikidata's QID. I think the assessment of the "proposed feature" probably underestimates the usefulness of Wikidata (my POV), but maybe the items linked from tags are not that complete. --- Jura 13:10, 27 January 2021 (UTC)[reply]

Property talk:P1282

Contents

Documentation

Discussion[edit]

Conflicts with instance of (P31); To be used with subclass of (P279) only?[edit]

Taginfo[edit]

How to tag multiple OSM keys?[edit]

subjects that are not classes of geographical objects[edit]

fixing the values of this property[edit]

characterization of OpenStreetMap tag or key (P1282)[edit]

conjunctive vs disjunctive for multiple values[edit]

Using criterion used (P1013) for characterizing the different meanings of values for OpenStreetMap tag or key (P1282)[edit]

Not using criterion used (P1013) for characterizing the different meanings of values for OpenStreetMap tag or key (P1282)[edit]

Sample values for OpenStreetMap tag or key (P1282)[edit]

Wikidata properties for results of OSM query ( node(48.8467, 2.2488, 48.8470, 2.2491); way(48.8466, 2.2488, 48.8470, 2.2491); rel(48.8466, 2.2488, 48.8468, 2.2491); ); out;[edit]

Wikidata properties for synthetic OSM tag sets[edit]

how to relate a bakery to baker[edit]

Add to properties if possible?[edit]

"_" or " " as value[edit]

Use wikidata items as values[edit]

Confusion with P402[edit]

Split keys and tags ?[edit]

Regex[edit]

Use data items from OSM-Wiki instead of the Article names?[edit]

Proposal in OSM wiki to remove Wikidata links from OSM wiki pages[edit]

Navigation menu

Property talk:P1282

Documentation

Discussion[edit]

Conflicts with instance of (P31); To be used with subclass of (P279) only?[edit]

Taginfo[edit]

How to tag multiple OSM keys?[edit]

subjects that are not classes of geographical objects[edit]

fixing the values of this property[edit]

characterization of OpenStreetMap tag or key (P1282)[edit]

conjunctive vs disjunctive for multiple values[edit]

Using criterion used (P1013) for characterizing the different meanings of values for OpenStreetMap tag or key (P1282)[edit]

Not using criterion used (P1013) for characterizing the different meanings of values for OpenStreetMap tag or key (P1282)[edit]

Sample values for OpenStreetMap tag or key (P1282)[edit]

Wikidata properties for results of OSM query ( node(48.8467, 2.2488, 48.8470, 2.2491); way(48.8466, 2.2488, 48.8470, 2.2491); rel(48.8466, 2.2488, 48.8468, 2.2491); ); out;[edit]

Wikidata properties for synthetic OSM tag sets[edit]

how to relate a bakery to baker[edit]

Add to properties if possible?[edit]

"_" or " " as value[edit]

Use wikidata items as values[edit]

Confusion with P402[edit]

Split keys and tags ?[edit]

Regex[edit]

Use data items from OSM-Wiki instead of the Article names?[edit]

Proposal in OSM wiki to remove Wikidata links from OSM wiki pages[edit]

Navigation menu

Search