Property talk:P1281
Documentation
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:
When possible, data should only be stored as statementsgeographic location (Q2221906) or geographic region (Q82794) | ||||||||||||
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:
When possible, data should only be stored as statements[1-9][0-9]{0,9} | ||||||||||||
Example | According to this template:
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 358 others) | ||||||||||||
See also | Mapcarta ID (P12966) | ||||||||||||
Lists |
| ||||||||||||
Proposal discussion | Proposal discussion | ||||||||||||
Current uses |
| ||||||||||||
Search for values |
List of violations of this constraint: Database reports/Constraint violations/P1281#Single value, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1281#Unique value, SPARQL (every item), 1) ORDER BY DESC(?ct) LIMIT 100 } ?item wdt:P1281 ?value . SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . ?item rdfs:label ?itemLabel . ?value rdfs:label ?valueLabel . } } GROUP BY ?value ORDER BY DESC(?ct)">SPARQL (by value)
List of violations of this constraint: Database reports/Constraint violations/P1281#Type Q2221906, Q82794, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1281#Item P625, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1281#Entity types
List of violations of this constraint: Database reports/Constraint violations/P1281#Scope, SPARQL
Warning about geo.concordance table errors
[edit]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
[edit]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 from the Yahoo data tables returns a "not found".
select * from geo.concordance where namespace="wiki" and text="645042"
I haven't compared other examples yet. --Closeapple (talk) 07:50, 3 May 2014 (UTC)
Chicago
[edit]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
[edit]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)
- Germany-related properties
- All Properties
- Properties with external-id-datatype
- Properties used on 10000+ items
- Properties with single value constraints
- Properties with unique value constraints
- Properties with format constraints
- Properties with constraints on type
- Properties with constraints on items using them
- Properties with entity type constraints
- Properties with scope constraints