Shortcut: WD:PP/PLACE

Wikidata:Property proposal/Place

From Wikidata
Jump to: navigation, search

See also:
Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available.
Wikidata:Properties for deletion – proposals for the deletion of properties.

This page is for the proposal of new properties.

Before proposing a property
  1. Check if the property already exists by looking at Wikidata:List of properties (manual list) and Special:ListProperties.
  2. Check if the property is already pending or has been rejected.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically. See WD:WikiProject Infoboxes for suggestions.
  4. Select the right datatype for the Property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Creation can be done after 1 week by a property creator or an administrator.
  2. See steps when creating properties.

Add a request

This page is archived, currently at

To add a request, you should use this form:

=== {{TranslateThis | anchor = en
| de = <!-- PROPERTY NAME IN German (optional) -->
| fr = <!-- PROPERTY NAME IN French (optional) -->
<!-- |xx = property names in some other languages -->
}} ===
{{Property documentation
|status                 = <!--leave this empty-->
|description            = {{TranslateThis
  | en = ...
|subject item           = <!-- <!-- item corresponding to the concept represented by the property, if applicable; example: item ORCID (Q51044) for property ORCID (P496) --> -->
|infobox parameter      = Wikipedia infobox parameters, if any; ex: "population" in [[:en:template:infobox settlement]]
|datatype               = put datatype here (item, string, media, coordinate, monolingual text, multilingual text, time, URL, number)
|domain                 = types of items that may bear this property
|allowed values         = type of linked items (Q template or text), list or range of allowed values, string pattern...
|source                 = external reference, Wikipedia list article, etc.
|example                = {{Q|1}} → {{Q|2}}
|formatter URL          = <!-- for external identifiers, URL pattern where $1 replaces the value -->
|filter                 = (sample: 7 digit number can be validated with edit filter [[Special:AbuseFilter/17]])
|robot and gadget jobs  = Should or are bots or gadgets doing any task with this? (Checking other properties for consistency, collecting data, etc.)


(Add your motivation for this property here.) ~~~~


For a list of infobox parameters, you might want to use table format:

{{List of properties/Header}}

{{List of properties/Row|id=
|title          = audio
|type           = media
|qualifier      =
|description    = Commons sound file
|example-subject= Q187 <!-- Il Canto degli Italiani -->
|example-object = Inno di Mameli instrumental.ogg


For blank forms, see Property documentation and List of properties/Row


M.49 code[edit]

   In progress
Description M.49 code
Represents UN M.49 (Q7865431)
Data type String
Domain geographic region (Q82794)
Allowed values 3 digit numbers
Example South America (Q18) => "005" ; New Zealand (Q664) => "554"
Source w:en:UN M.49, w:en:ISO 3166-1 numeric

See also ISO 3166-1 numeric code (P299).


Could be usefull. Or not. Visite fortuitement prolongée (talk) 21:36, 18 June 2015 (UTC)



northwest coordinate of location map[edit]

   In progress
Description see above. use as qualifier.
Data type Geographic coordinates
Template parameter Template:Location map (Q5625881)
Domain place
Example see above
Robot and gadget jobs Yes
Proposed by GZWDer (talk)

GZWDer (talk) 13:16, 6 January 2015 (UTC)

I would rather have a "northernmost latitude" and a "westernmost longitude" property with type = number (decimal value). Parsing it from a coordinate-type property seems needlessly complicated.--Zolo (talk) 08:04, 9 January 2015 (UTC)
Thinking of it, maybe it is best to wait until there is Wikibase on Commons so that we can store the data directly there. --Zolo (talk) 09:00, 17 January 2015 (UTC)
I think this is a bad decision. Get the value of the coordinates is simple enough, but the coordinates are stored in the designated type. —putnik 18:31, 27 April 2015 (UTC)
We already have coordinate of northernmost point (P1332), coordinate of southernmost point (P1333), coordinate of easternmost point (P1334), and coordinate of westernmost point (P1335). Can't we use those instead (as Zolo asked)? They are not specific to a particular map projection. I'm inclined to oppose unless someone can tell me why we need something else. Filceolaire (talk) 20:02, 19 March 2015 (UTC)
Map not need all four. What a couple of them should we choose? I think it might be a good solution to add these two parameters: "northwest coordinate" and "westernmost coordinate" (not only for location maps, but for future uses too). GA candidate.svg Weak support. —putnik 18:31, 27 April 2015 (UTC)
  • No answer? then I guess I Symbol oppose vote.svg Oppose. Filceolaire (talk) 20:26, 10 April 2015 (UTC)
I guess the idea is to create location maps with marks. If you have the coordinates of a city and a location map you still need to know which sector the location map is showing to put the mark for the city on the right place. --Pasleim (talk) 22:10, 20 May 2015 (UTC)
Such qualifier is useful only for specific kind of map projection (Q186386) (usually small) in which latitude and longitude can be converted to x and y value in the picture of map using Linear function (Q188597). However if you look at Antarctica.svg, the translation to x and y is rather complex. The general solution to the problem is creating function, which test whether the given coordinate is visible on the map, and converts it to pair of (x, y) in the picture. Paweł Ziemian (talk) 11:54, 13 June 2015 (UTC)
@Filceolaire: A statement with coordinate of northernmost point (P1332) d:o 1333, 1334 and 1335 have all both latitude and longitude. Adding all four, therefor gives 4 longitudes + 4 latitudes = 8 numbers. That would give us an unsolvable system of linear equations (Q11203). We need exactly four numbers here to copy the functions of present templates like Template:Location map Andorra (Q12259). That is easiest accomplished by adding coordinates of the most NW and SE points of the map.
@Paweł Ziemian: That also includes nations like Russia and Greenland. They are the exceptions, they cannot be solved in a simple way like most other nations and regions in the world. -- Innocent bystander (talk) 18:05, 6 July 2015 (UTC)
Yes, I know. It was an example, where the problem is easiest to observe (I think). Paweł Ziemian (talk) 18:43, 6 July 2015 (UTC)
Innocent bystander What if we take the 'northernmost' and 'southernmost' points and discard their longitude values and then take the 'easternmost' and 'westernmost' and discard the latitude. Now we have two latitude values and two longitude values and the problem of finding NW and SE coordinates from these is solvable. Greenland shouldn't be a problem nor should Russia since we specify which point is easternmost and which is westernmost. Antartica only has a 'northernmost' point, defining a circular map. Similarly for the Artic sea. Easy peasy.
"Ah" you say "but that means the map of russia and of greenland is not square!" and I say that depends on which projection you are using. These maps are square if you use the Peters equal area projection for instance. This will, however, distort the shape of Russia and Greenland. You would be better to use a polar projection for the maps. The centre of this polar projection should be at a latitude half way between the 'northernmost' and 'southernmost' points and a longitude half way between the east and west extreme points. Not hard to calculate. The north south east and west limits of the maps should be at or beyond the NSEW extreme points. Sounds perfectly possible to me. Google earth does this all the time - draws a polar projection with a centre point wherever the centre of your screen is. I'm still Opposed to creating new properties. Filceolaire (talk) 00:27, 8 July 2015 (UTC)
A map of Russia or Greenland with the same longitude in the left upper and left lower corner are possible to create, but they are aestheticly awkward. Maps with other kind of projections exists in these cases, so it is solvable. The problem is that somebody have to create these maps and templates. We are not flooded with such skilled users on Commons and the Wikipedias. -- Innocent bystander (talk) 05:05, 8 July 2015 (UTC)
This guy got an individual engagement grant to do exactly these maps. You should talk to him. Filceolaire (talk) 22:33, 16 July 2015 (UTC)

southeast coordinate of location map[edit]

   In progress
Description see above. use as qualifier.
Data type Geographic coordinates
Template parameter Template:Location map (Q5625881)
Domain place
Example see above
Robot and gadget jobs Yes
Proposed by GZWDer (talk)

GZWDer (talk) 13:16, 6 January 2015 (UTC)


OpenStreetMap Way identifier[edit]

   Not done
Description The ID of the way of this place/object in OpenStreetMap (Q936)
Data type String
Domain places
Example ???
Proposed by Agamitsudo (talk)


Today there is this OSM property [1] based on "relation". It would be great to have same properties for "node" and "way":

Thank you, --Agamitsudo (talk) 11:44, 22 January 2015 (UTC)

  • Symbol oppose vote.svg Oppose OSM identifiers are not stable. Tag the way in OSM, with the Wikdiata ID (See Key:wikidata), and use coordinate location (P625) to find it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:53, 6 March 2015 (UTC)
    • Andy how does that work? Which coordinate links to a 'way' when the way is an area or a river or a highway? Filceolaire (talk) 18:32, 4 May 2015 (UTC)
      • Coordinates never "link" to ways; find the object or relation within a suitable radius of the coordinates, which has the Wikdiata ID. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:08, 4 May 2015 (UTC)
        • Andy is that really the best we can do? OSM has ways defined for borders, rivers, highways, railways. We really, really want to have properties to link to those 'ways' from the corresponding wikidata items but we can't link to the OSM way. Really? Surely there some way to do this? Using a coordinate and searching won't help - remember that a lot of borders follow other borders - the border of a country is also the border of an adjacent country and of various subdivisions of both of those countries. Is there a chance to ask OSM to think about how this might be done? Filceolaire (talk) 00:39, 8 July 2015 (UTC)
  • I understand the appeal of wanting to link to specific objects in OSM, but I have to agree with Andy here. A way has no stable identity, OSM does not try to preserve IDs or prevent them from changing their meaning, plus the way OSM models things means that many things must be represented by multiple (often large numbers of) ways - an item in Wikidata is very often not represented by a single way (the border of Nordrhein-Westfalen is 502 ways, the Danube is 243 ways, the M25 in London is 527 ways, even the straightforward Jungfraubahn route from Kleine Scheidegg to Jungfraujoch is 12 ways, to list the first examples of borders, rivers, highways and railways that came to mind for me). I think the only good solutions for linking from Wikidata to OSM would have to come from OSM itself, e.g. making it easier to find everything which has a specific Wikidata ID via a search like or even introducing more integrated Wikidata support, like having a dedicated page like with the map highlighting all the objects and the sidebar listing the objects and showing some extra information pulled from Wikidata. - Nikki (talk) 06:55, 8 July 2015 (UTC)

 Not done No support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:01, 15 August 2015 (UTC)

next crossing[edit]

   In progress
Description Next crossing of a river with a qulaifier for "upstream" or "downstream". (Alternatively, have separate properties for each)
Data type Item
Template parameter Succession boxes on en.Wikipedia, for example on en:Westminster Bridge
Domain Bridges, aqueducts, railways, roads, pipelines, powerlines, cable car lines
Example Westminster Bridge (Q456960) => Lambeth Bridge (Q1130666) (upstream); Jubilee line (Q961290) (downstream)


Proposed by: Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:58, 14 March 2015 (UTC)

  • Pictogram voting comment.svg Comment It's needed specify crossing type to eliminate the ambiguity (next automobile bridge, next railway bridge, next powerline and so forth). -- Sergey kudryavtsev (talk) 08:05, 25 March 2015 (UTC)
  • Pictogram voting comment.svg Comment I think it would be better to have a "next crossing [up|down]stream" property for the next crossing of any type, and a "next crossing of type [up|downstream]" with a mandatory qualifier of "bridge", "pedestrian tunnel", etc. to handle the specific types. Thryduulf (talk: local | en.wp | en.wikt) 09:25, 18 April 2015 (UTC)
  • Symbol support vote.svg Support --- Jura 12:11, 30 April 2015 (UTC)

Administrative units[edit]

Properties for specific levels of administrative units[edit]

Currently, items of populated places (villages, towns, cities, city districts etc.) are equiped with located in the administrative territorial entity (P131) which should contain the immediately superior unit. Such a statement can be (hypotetically) supplemented with a qualifier which would define which kind (level) of the administrative unit is linked.

However, the invoke function is not (and will be not in the foreseeable future) able to work with qualifiers, is not able select the requested value by qualifier and is not able to work with a multilevel statement tree structure (imitating the categorization structure) and extract the appropriate value from them using structured conditioning. Said simply: when we have a specific item of any place - we cannot invoke the municipality, the district, the region or the land where the place is. The only level of administrative unit which have its specific property and is widely used for populated places is country (P17).

The new function of Wikidata:Arbitrary access can be very helpful e.g. in monument lists created for Wiki Loves Monuments. They can help to fulfill specifying entries in the list tables as well as prefilled at the file description pages of images uploaded using campaing link to UploadWizard as well as to help with precise automatic categorization of such images. However, the statements need to be specific enough to be usable for practical work.

I propose to create specific properties for specific levels of administrative units. In case of my country (Czechia), we need properties:

  • municipality
  • district
  • region
  • land

Format and usage should be analogous to the existing country (P17):

--ŠJů (talk) 07:25, 24 August 2015 (UTC)

Do you propose to create separate properties for each level of adminunits?--Ahonc (talk) 07:34, 24 August 2015 (UTC)
Yes. As explained above. --ŠJů (talk) 07:42, 24 August 2015 (UTC)
@ŠJů: Can you work with Lua ? It's not really hard to make an equivalent of Invoke in lua using Wikidata API, who can manipulate qualifiers. I'll encourage you to poke the lua developers of the Wikipedia of your language. By knowing the instance of (P31) of a division, you can pretty much know which kind of division is the upper level of that item. Note that the administrative model of division differs from one country to another, which would make a mess of properties ... Other projects are trying to work this "upper division" model, for project consistency sake I'd say it's better that all the administrative division local project stay aligned with this. author  TomT0m / talk page 10:05, 24 August 2015 (UTC)
But why we need qualifiers? We should use P131 for Q12036136, then P131 for Q852457, then P131 for Q188399.--Ahonc (talk) 10:18, 24 August 2015 (UTC)
Another problem with the model ŠJů propose above, is that some administrative divisions maybe have the same "name" in one language, but completly different names in other languages. In Swedish we use different words for a county in US, UK, Denmark, Norway, Sweden and Russia. We would then need one property for each type of administrative level in every present and historical country. We would soon reach 1000 properties only for administrative units. The disadvantage of the other model is that the simple hierarchy is sometimes missing, and in Sweden is it only present in the relation between municipalities and counties. -- Innocent bystander (talk) 11:29, 24 August 2015 (UTC)
Why? We may create universal properties for this, e.g. Level1AD, Level2AD, Level3AD, Leve4AD, Level5AD, Level6AD etc.--Ahonc (talk) 11:36, 24 August 2015 (UTC)
Then I don't get how using specialized properties makes things really for Sweden :) If there is no hierarchy or a flat one, then ... whatever you do things will remains flat. author  TomT0m / talk page 11:37, 24 August 2015 (UTC)
Symbol oppose vote.svg Oppose. We used to have 'type of administrative territorial entity' and we replaced it with instance of (P31) and that is what we can use for this. <instance of (P31):municipality of the Czech Republic ( Q5153359)>. There is a reason we do not put the higher levels on each item and that is because these hierarchies change from time to time. If the info is in one place only then it is much easier to keep it accurate. This does mean that you need to go to a different item to get the links to the higher levels and that is something we live with.
Taxa used to have something similar and the specialised properties for upper levels were deleted so now we only have parent taxon (P171). Just be thankful country (P17) is still around. Joe Filceolaire (talk) 13:56, 24 August 2015 (UTC)
Symbol oppose vote.svg Oppose per Joe. --Pasleim (talk) 15:39, 25 August 2015 (UTC)



   In progress
Description Head of village within municipality.
Data type String
Template parameter староста
Domain place
Example no label (Q4400111) → Фенин Василь Миколайович
Source [2], [3]

According new administrative reform in Ukraine each village will have each head of village - starosta, so we need infobox parameter for it.Ahonc (talk) 14:55, 2 August 2015 (UTC)

  • Why can't we just use head of government (P6) for this? — NickK (talk) 15:01, 2 August 2015 (UTC)
  • Also head of state (P35) can be adapted for universal use for all levels of territorial units (or even for other organizations too). --ŠJů (talk) 07:25, 24 August 2015 (UTC)
  • We need combined item/string datatype which support items but also names which have not their items in Wikidata. --ŠJů (talk) 07:36, 24 August 2015 (UTC)
    And maybe some special mark when head has interim status.--Ahonc (talk) 07:50, 24 August 2015 (UTC)
    For Spain, I think P6 is being used and an item for the person created when not available list (slow). --- Jura 07:58, 24 August 2015 (UTC)
  • Symbol oppose vote.svg Oppose per NickK and Jura. Joe Filceolaire (talk) 14:00, 24 August 2015 (UTC)
  • Symbol oppose vote.svg Oppose per NickK--Pasleim (talk) 15:41, 25 August 2015 (UTC)