Property talk:P1281

Documentation

• Start a query
• Current uses
• Statistics by class
• String length
• List of qualifiers
• Count

WOEID
identifier for a location on Yahoo! GeoPlanet and Flickr

Description	unique geographic location ID used by Yahoo! GeoPlanet
Data type	External identifier
Domain	According to this template: geographic location (Q2221906) According to statements in the property: geographic location (Q2221906) or geographic region (Q82794) When possible, data should only be stored as statements
Allowed values	According to this template: 32-bit value as a plain decimal integer: i.e. presumably a whole number between 1 and 4294967295 According to statements in the property: [1-9][0-9]{0,9} When possible, data should only be stored as statements
Example	According to this template: New York City (Q60) => 2459115 (Flickr search) Russia (Q159) => 23424936 (Flickr search) Mount Everest (Q513) => 23509198 (strangely, no results for Flickr search) Matterhorn (Q1374) => 2347591 (Flickr search) Pacitan (Q11111) => 1048038 (Flickr search) O'Hare International Airport (Q213717) => 12521200 (Flickr search) Ash Priors (Q2573097) => 11111 (Flickr search) Pool's Cove (Q7228550) => 1234 (Flickr search) According to statements in the property: Montevideo (Q1335) → 2459115 Brora (Q990677) → 14200 Faversham (Q1000115) → 19991 When possible, data should only be stored as statements
Source	https://www.flickr.com/places/info/1 http://zourbuth.com/tools/woeid/ https://www.findmecity.com/
Formatter URL	https://www.flickr.com/places/info/$1
Robot and gadget jobs	No current bots or gadgets as far as I know. Someone could do data collection: The Yahoo GeoPlanet API already contains support for English Wikipedia page ID concordance as value "wiki" (as well as several other cross-reference values) in the /concordance data. Where the en.wiki page ID doesn't exist in the Yahoo data, a bot could be designed to add the WOEID to Wikidata items when there is high confidence: for example, if there is a located in the administrative territorial entity (P131) of type second-level administrative division (Q13220204) for the Wikidata item, and that matches exactly one name in Yahoo GeoPlanet with the same Admin2, and the name is not ambiguous on the native language Wikipedia (i.e. needs unusual qualifiers in the title), then the item on Wikidata would have a high-confidence match to that WOEID. Or a gadget could allow user-assisted matching.
Tracking: usage	Category:Pages using Wikidata property P1281 (Q27918947)
Related to country	Germany (Q183) (See 346 others)
Lists	Items with the most statements of this property Count of items by number of statements (chart) Items with the most statements Items with the fewest statements Count of items by number of sitelinks (chart) Items with the most sitelinks Items with the most sitelinks, but no link to one Wikipedia (sample: Welsh Wikipedia, cywiki) Items with the fewest sitelinks Most linked wikis Items with the most identifier properties Items with no other external identifier Items with no other statements Most recently created items Items with novalue claims Items with unknown value claims Usage history (total) Usage history (main statement) Chart by item creation date Database reports/Constraint violations/P1281 Map Random list
Proposal discussion	Proposal discussion
Current uses	Total 31,639 Main statement 31,632 >99.9% of uses Qualifier 3 <0.1% of uses Reference 4 <0.1% of uses
Search for values

[create Create a translatable help page (preferably in English) for this property to be included here]

Single value: this property generally contains a single value. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Duberger–Les Saules (Q3040507)
List of violations of this constraint: Database reports/Constraint violations/P1281#Single value, SPARQL

Distinct values: this property likely contains a value that is different from all other items. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1281#Unique value, SPARQL (every item), SPARQL (by value)

Format “[1-9][0-9]{0,9}”: value must be formatted using this pattern (PCRE syntax). (Help)

List of violations of this constraint: Database reports/Constraint violations/P1281#Format, hourly updated report, SPARQL

Type “geographic location (Q2221906), geographic region (Q82794)”: item must contain property “instance of (P31)” with classes “geographic location (Q2221906), geographic region (Q82794)” or their subclasses (defined using subclass of (P279)). (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1281#Type Q2221906, Q82794, SPARQL

Item “coordinate location (P625)”: Items with this property should also have “coordinate location (P625)”. (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303). Known exceptions: Earth (Q2)
List of violations of this constraint: Database reports/Constraint violations/P1281#Item P625, SPARQL

Allowed entity types are Wikibase item (Q29934200): the property may only be used on a certain entity type (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1281#Entity types

Scope is as main value (Q54828448), as reference (Q54828450): the property must be used by specified way only (Help)

Exceptions are possible as rare values may exist. Exceptions can be specified using exception to constraint (P2303).
List of violations of this constraint: Database reports/Constraint violations/P1281#Scope, SPARQL

Warning about geo.concordance table errors

I (who just proposed this property) just now discovered that the geo.concordance table in Yahoo GeoPlanet seems to have some erroneous information, so beware. It does not appear to be directly linked to the other geo.* tables, so maybe it has different sources. So, when matching Wikidata to Yahoo GeoPlanet data, it's probably best to use comparisons with the other, more authoritative geo.* tables rather than relying on geo.concordance to be authoritative concordance itself. --Closeapple (talk) 07:50, 3 May 2014 (UTC)

New York City

As an example of bad concordance data, the following YQL queries:

select * from geo.places where text="New York City"

returns woeid="2459115", name "New York", placeTypeName "Town", and admin1 (state) woeid="2347591", and bounding box 40.477421,-74.258904 to 40.917622,-73.700378. So we know this (WOEID 2459115) is really New York City. But

select * from geo.concordance where namespace="woeid" and text="2459115"

returns the following:

fips = 3651000

That's correct: it matches http://quickfacts.census.gov/qfd/states/36/3651000.html

iata = ZFZ

That's wrong: IATA code ZFZ is a rare code used for the railway station Buffalo–Depew station (Q800595), on the opposite side of New York State from New York City. If there is any IATA code that would be New York City (as a town in general), it would be NYC.

locode = USNYC

That's correct: the UN/LOCODE for New York City is US NYC

geonames = 5128581

That's correct: it matches http://www.geonames.org/5128581/new-york-city.html

wiki = 358019

That's wrong: /concordance/{namespace}/{id} defines wiki as "Page IDs for places in the US from en.wikipedia.org". https://en.wikipedia.org/w/api.php?action=query&prop=info&inprop=url&pageids=358019 returns the page en:WNYC, which is WNYC (Q1551068), a radio station. The concordance value should instead be 645042 as shown in https://en.wikipedia.org/w/api.php?action=query&prop=info&inprop=url&titles=New+York+City but, unfortunately, so far

select * from geo.concordance where namespace="wiki" and text="645042"

from the Yahoo data tables returns a "not found".

I haven't compared other examples yet. --Closeapple (talk) 07:50, 3 May 2014 (UTC)

Chicago

And now an example where the geo.concordance information is correct:

select * from geo.places where text="Chicago"

returns woeid 2379574, name Chicago, admin1 Illinois, admin2 Cook, so we know WOEID 2379574 is really Chicago (Q1297).

select * from geo.concordance where namespace="woeid" and text="2379574"

does not return the "iata" field or "wiki" field, but does have these:

fips = 1714000

Correct: http://quickfacts.census.gov/qfd/states/17/1714000.html

locode = USCHI

Correct: UN/LOCODE for New York City is US CHI

geonames = 4887398

Correct: http://www.geonames.org/4887398/chicago.html

osm = 153388690

Correct: http://www.openstreetmap.org/node/153388690

--Closeapple (talk) 07:50, 3 May 2014 (UTC)

Bot request in progress

I've been working on assigning these to Wikidata items, based on cross-correlating the CC0 Flickr Shapefiles Public Dataset 2.0 (Q24010939) with multiple open/Free datasets, including GNS, GNIS, and Wikidata itself, and using the enwiki category tree to winnow out false positives. I'm now ready to add the first 28,000-odd entries. Please see Wikidata:Requests for permissions/Bot/The Anomebot 3. -- The Anome (talk) 11:19, 6 May 2016 (UTC)