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
| en = PROPERTY NAME IN ENGLISH
| 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.)
}}

;Motivation

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

;{{int:Talk}}

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
}}

</table>

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


General[edit]

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).

Motivation

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

Discussion

Maps[edit]

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)
Discussion

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)
Discussion

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


Routes[edit]

OpenStreetMap Way identifier[edit]

   In progress
Description The ID of the way of this place/object in OpenStreetMap (Q936)
Data type String
Domain places
Example ???
Source https://www.openstreetmap.org/way/$1
Proposed by Agamitsudo (talk)
Discussion

Hi,

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 http://www.openstreetmap.org/search?query=Q17 or even introducing more integrated Wikidata support, like having a dedicated page like http://www.openstreetmap.org/wikidata/Q17 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)

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)
Discussion

Motivation:

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)

Unsorted[edit]