Property talk:P590

As was mentioned in the proposal discussion, it's common to have a multiple GNIS features for a single Wikipedia topic. The main example is with the Populated Place & Civil feature classes, but Wikipedia has a lot of articles logically covering multiple features like the lake and its park or the island and its community, or possibly aggregations like a mountain with several peaks. Thus I have removed the single value constraint. Mrwojo (talk) 19:49, 3 June 2013 (UTC)Reply

Even if there are a few false positives, I think it's a good thing to see what it generates. --  Docu  at 19:53, 3 June 2013 (UTC)Reply

It's not a few: 28,683 census places with multiple, non-historical GNIS IDs in the fed codes extract. What's a true positive, then? Mrwojo (talk) 22:12, 3 June 2013 (UTC)Reply

Well, the report runs just on the 5 items with GNIS here at Wikidata. Currently there is no match whatsoever. For a sample with P:P396, see Q358147 (before my edit). --  Docu  at 00:46, 4 June 2013 (UTC)Reply

Are all the constraints here thus purposeless because those 5 items have no violations? No, we're talking about what will be added because this property was literally created yesterday. What will be reported is more than just a "few false positives" of the single-value constraint. That's misleading. The ICCU database doesn't normally have multiple entries for single items, right? That's a single-value constraint. GNIS is not like that. Same goes for this constraint on P:P364. Mrwojo (talk) 03:41, 4 June 2013 (UTC)Reply

The constraint checks are here to do quality control on Wikidata. They are needed to run the reports and don't necessarily describe the property accurately.

I don't know about ICCU, maybe it shouldn't have multiple entries, but sometimes has. This is similar to a few other identifiers we have. At least for one identifier, I noticed they deleted one dup after Wikidata had listed both.

Last time I looked at the results for P:P364, I was under impression that many are errors that need to be fixed. As such, it might be a good point of comparison. --  Docu  at 05:59, 4 June 2013 (UTC)Reply

It's not merely reports, though. It claims to be a constraint, it claims "this property must contain single value". For every needle pulled from the haystack, how many others editors would expect the constraint to be at least normally accurate? Can you quantify "many" P364 violations? Again, the report looks like it has a significant ratio of false positives. Mrwojo (talk) 02:06, 5 June 2013 (UTC)Reply

So if I remove the constraint... ? Mrwojo (talk) 03:50, 7 June 2013 (UTC)Reply

For now there is just one. Let's see how it evolves. I restored the note about false positives on the constraint templates. --  Docu  at 19:34, 7 June 2013 (UTC)Reply

It'll evolve from the current violation that's a false positive to many violations that are false positives. Or, perhaps worse, there'll be misguided deletions of accurate IDs merely to suppress these reports. How about we let the property evolve without this inaccurate constraint? Mrwojo (talk) 20:34, 7 June 2013 (UTC)Reply

Don't worry about it. Please read the notice on top of the report. --  Docu  at 05:45, 8 June 2013 (UTC)Reply

I'd be less worried if there wasn't a banner at the top of this page claiming "this property must contain single value". Mrwojo (talk) 07:16, 8 June 2013 (UTC)Reply

I don't like "must" either. I reworded it slightly. --  Docu  at 07:18, 8 June 2013 (UTC)Reply

  Oppose Where we have a wikipedia page which deals with multiple items (the Bonnie and Clyde (Q219937) problem) then the wikidata page for this multi-item WP page should have links to separate wikidata pages for each individual item (using property has part(s) (P527)) and those separate pages are where the GNIS codes should be recorded. If multiple GNIS codes are put on the wikidata page for the WP multi-item page then that is an error which this constraint will highlight and that is a good thing. Filceolaire (talk) 14:26, 8 June 2013 (UTC)Reply

That doesn't address the main issue with populated places. One place, two IDs. Mrwojo (talk) 19:07, 8 June 2013 (UTC)Reply

The leading zeros are sometimes added in the GNIS ID, even in some official statistics I have seen them. What is for example the right way to add the GNIS ID for Agua Sal Creek (Q14680258)? The ID is "399", but I can also entered it as "000399" or "0000399". The ID is treated as a number and therefore leading zeros are also okay for the query form https://geonames.usgs.gov/pls/gnispublic/ . But in order to fulfill the single value constraint, we should force the format to begin with a nonzero digit, i.e., format constraint = "[123456789]\d*". Okay? --Zuphilip (talk) 17:37, 27 December 2013 (UTC)Reply

I added the new constraint as a test and everything looks fine (some small errors are corrected). I asked at GNIS directly and they told me the the GNIS ID is indeed a number and not a string. Thus, our constraints here should be fine. Ivan A. Krestinin, thank you for simplifying the constraints further. --Zuphilip (talk) 23:06, 3 January 2014 (UTC)Reply

Does anyone have suggestions on what qualifiers should be used (if any) to distinguish the multiple GNIS IDs for a Wikidata item, when a settlement has received an additional ID with a U.S. Census-focused "census" or "civil" class, in addition to the settlement's traditional ID for its "populated place" ("ppl")? I am assuming that almost every item of type municipality (Q15284) or census-designated place in the United States (Q498162) in the U.S. now has two GNIS IDs.

Background: As mentioned in Wikidata:Property proposal/Archive/8#P590 and above in #Removed single value constraint: Traditionally, years before Wikidata existed, USGS GNIS entries ("GNIS ID") and the United States Census statistical areas ("census codes") were separate. In the last decade, however, there was a movement to merge United States Census areas into the USGS GNIS instead, and deprecating the old "census codes". (Wikidata doesn't even have a property for the old code.) This has resulted in separate GNIS IDs used for the same place in different contexts: If a settlement is also a municipality, then, in addition to the traditional "populated place" ("ppl") entry for the place in the USGS GNIS, that place also has an additional "civil" entry with the legal name of the municipality that, culturally, is the same place: for example Chillicothe (Q575467) was traditionally GNIS ID 406065 but now is also "City of Chillicothe" GNIS ID 2393515. Even if a settlement is not a municipality, but is delineated by the Census just for statistical convenience, it now has both its traditional "populated place" ("ppl") entry and a new "census" entry with the words "Census Designated Place" (or related phrases) in the name: for example the settlement Rome (Q575847) now has its traditional "ppl" GNIS ID 416896 but also its "census" entry "Rome Census Designated Place" GNIS ID 2393211. There are not multiple GNIS entries of the same class for the same Wikidata item, however. (Or if there are, it's an error in the GNIS.)

Note that "census" is a relatively new feature class for the GNIS, but I think "civil" has an older history: Things that are more administrative divisions than individual settlements have been "civil" class for a while, and often do not have a separate "ppl" entry. See, for example, Chillicothe Township (Q5099060), which has always had a single entry, "civil" class, "Township of Chillicothe" GNIS ID 428806.

Lately, when there is both a "ppl" and a "census"/"civil" that refer to the same Wikidata item, and the same place culturally, I...

• ...add the "ppl" ID with no qualifier, mostly because I can't figure out what property qualifier to assign the value human settlement (Q486972) (also known as "populated place") to, since it's not an administrative division, just an amorphous place on a map.
• ...add the "civil" ID with the qualifier P132 (P132) = municipality (Q15284) for entries that refer to the municipal aspect of the place.
• ...add the "census" ID with a qualifier such as P132 (P132) = census-designated place in the United States (Q498162); there could be other types besides this; also, I should note that this type of place is "administrative" only in that it is created as a statistical convenience by a higher administration because it has no corporate existence or boundary otherwise.

With townships and the like, which only have one entry ("civil" class), I add the GNIS ID with no qualifier, because it doesn't appear that it will have separate IDs for separate contexts.

Any suggestions on what the "ppl" entries (or the others) should have as qualifiers to distinguish them among multiple GNIS ID entries? --Closeapple (talk) 01:55, 4 May 2014 (UTC)Reply

I've removed the constraint saying that items with this property should also have a Freebase ID (at least for now) because it's not directly related to this property and the violations are flooding the constraint report: There are currently 14728 violations for it, which is nearly half of all the uses of this property.

If items with GNIS IDs are really supposed to all have Freebase IDs, could someone more familiar with Freebase figure out how we can match the two? (preferably automatically, it would take a long time to do 14 thousand matches by hand)

- Nikki (talk) 12:33, 3 April 2016 (UTC)Reply

Good idea as Freebase imports seem to have come to an end. I removed it from a series of other properties as well.
--- Jura 06:28, 9 April 2016 (UTC)Reply

  Notified participants of WikiProject Datasets

  Notified participants of WikiProject Open Government Data

  Notified participants of WikiProject Roads

  Notified participants of WikiProject Protected areas

Is there a data dump available?

• https://geonames.usgs.gov/apex/f?p=gnispq:1:::NO::: is a search page that allows CSV download of partial info
• Individual place pages eg https://geonames.usgs.gov/apex/f?p=gnispq:3:::NO::P3_FID:1022456 include more info but have no CSV or JSON download

All the download links I could find are dead-ends:

• https://data.usgs.gov/datacatalog/: 22k in-depth datasets
  • "GNIS gazetteer" finds https://data.usgs.gov/datacatalog/full.html#https://usgs.ornl.gov/metadata/SDCCollections/xml/USGS_Geographic_Names_Information_System_GNIS/USGS_GNIS_Collection.xml
  • It's a description of GNIS with a lot of metadata and a bunch of links. Dated 20141218.
  • Seems to be the same as https://geonames.usgs.gov/docs/metadata/gnis.txt (one of the few file son that domain that doesn't redurect to the BGN home page)
  • But none of the links works
• These redirect to https://www.usgs.gov/core-science-systems/ngp/board-on-geographic-names (BGN home page), which has info but no data:
  • http://geonames.usgs.gov/
  • http://geonames.usgs.gov/pls/gnispublic
  • http://geonames.usgs.gov/domestic/download_data.htm
  • http://geonames.usgs.gov/pls/gnis/x?fname=&state=&cnty=&cell=&ftype=
• https://www.usgs.gov/core-science-systems/ngp/board-on-geographic-names/resources: docs but no data
• https://services.nationalmap.gov/arcgis/services/geonames/MapServer/WMSServer : Error while processing request
• http://www.census.gov/geo/maps-data/data/gazetteer2010.html : moved or no longer available on this server
• https://thor-f5.er.usgs.gov/ngtoc/metadata/waf/geographic_names/gnis/ : not updated since 2013

--Vladimir Alexiev (talk) 19:51, 3 December 2020 (UTC)Reply

@Vladimir Alexiev: Is this what you are looking for (last updated: November 1, 2020)? https://www.usgs.gov/core-science-systems/ngp/board-on-geographic-names/download-gnis-data --Bamyers99 (talk) 02:30, 5 December 2020 (UTC)Reply

• @Bamyers99: <tvar|></>Thanks! --Vladimir Alexiev (talk) 07:49, 7 December 2020 (UTC)Reply

The GNIS site is being redesigned and a number of the feature classes are being archived and removed from the GNIS database.

Removed feature classes

Airport, bridge, building, cemetery, church, dam, forest, harbor, hospital, mine, oilfield, park, post office, reserve, school, tower, trail, tunnel, well

Kept feature classes

Natural features, populated places, canals, reservoirs, civil, census, military

Source

"User Notice". www.usgs.gov. U.S. Board on Geographic Names. 2021-08-25. Archived from the original on 2021-08-31. Retrieved 2021-08-31. --Bamyers99 (talk) 15:20, 31 August 2021 (UTC)Reply

The new website is live at https://edits.nationalmap.gov/apps/gaz-domestic/public/search/names --Bamyers99 (talk) 21:50, 30 October 2021 (UTC)Reply

I understand why the USGS archived these feature classes, but unfortunately there isn't another place to get them that's nearly as accessible/searchable. [1] I think it would be useful to import the rest of the feature classes into Wikidata based on the data dumps, including the archived feature classes. The airports etc. could be instance of (P31) a "GNIS airport" that's a subclass of "archived GNIS feature class" to make it clear that this is historical data, not necessarily bad data. Minh Nguyễn ^💬 22:15, 15 November 2021 (UTC)Reply

I have found the buildings that are no longer in GNIS are still in GeoNames, so there is another source that is easily accessible and searchable. I am wondering what should be done with GNIS IDs in items that now link to nothing. For example on Mary Gates Hall (Q99017318) if you click on the GNIS ID (https://edits.nationalmap.gov/apps/gaz-domestic/public/summary/2461252) you get taken to a useless page that has no information. Should these GNIS ID be deprecated or deleted? UWashPrincipalCataloger (talk) 22:11, 26 March 2022 (UTC)Reply

@UWashPrincipalCataloger: The feature IDs are still valid, and some even get updated via The National Map Corps, despite being archived. Here's Mary Gates Hall in GNIS-LD. I've changed the property to link to GNIS-LD instead. This is the official complete distribution of GNIS entries in RDF. It's a bit less user-friendly than the search tool on The National Map, but completeness probably matters more for Wikidata. – Minh Nguyễn ^💬 01:48, 12 September 2023 (UTC)Reply

"Less user-friendly" is an understatement, and I changed the property to link directly to the GNIS, as it had before. The GNIS-LD ("KnowWhereGraph") record contains significantly less information than the GNIS record (for instance, the GNIS record lists all of the counties a river flows through, while GNIS-LD does not). It would be great if something could be devised to address the IDs that were removed from GNIS, but I don't think it should come at this expense. Thanks --TimK MSI (talk) 11:52, 12 September 2023 (UTC)Reply

This needs to link to the official site, not some clone. --Bamyers99 (talk) 13:25, 12 September 2023 (UTC)Reply

@Bamyers99: GNIS-LD is the official distribution of the complete set of records in GNIS (not a clone), whereas The National Map is the official search engine for the feature classes that are still maintained (but only those classes). Unfortunately, neither of the tools contains all the metadata that the old GNIS search engine used to, like links to scanned copies of USBGN decision slips. GNIS-LD doesn’t contain any decisions, while The National Map claims to but many are missing for some reason. As @TimK MSI points out, it would be wonderful if there were a site that could pull together everything – even if it were unofficial. My primary concern is that people now frequently think The National Map is comprehensive, in that a “not found” error there means the feature ID is no longer valid or has never existed. This has already led to the deletion or near-deletion of features from OpenStreetMap, and I wouldn’t be surprised if the same were to happen under the radar on Wikidata.

I wonder if the concern about these missing counties could be addressed by citing the extra located in the administrative territorial entity (P131) statements to The National Maps search engine more specifically. (Technically these statements are inaccurate anyhow; only partially coincident with (P1382) could be so specific if it flows through multiple counties.) As it is, GNIS Feature ID (P590) statements on instances of archived classes need to be qualified by URL (P2699) to avoid misleading users.

 – Minh Nguyễn ^💬 17:08, 3 December 2023 (UTC)Reply