Wikidata:Property proposal/Landgate Object ID

From Wikidata
Jump to navigation Jump to search

Landgate Object ID[edit]

Originally proposed at Wikidata:Property proposal/Place

   Withdrawn
DescriptionLandgate (Western Australian Land Information Authority)
Data typeExternal identifier
Domainelectoral district of Western Australia (Q5356189), local government area of Western Australia (Q55557858), regional park (Q6063204), locality (Q3257686), town (Q3957), suburb (Q188509), suburb/locality (Q7632426)
Example 1Landsdale (Q85758876)20/1
Example 2Shire of Wiluna (Q2051063)14/1
Example 3Wooroloo Regional Park (Q21972405)4/1
Example 4Rocklea (Q55448888)16/1
Example 5Marble Bar (Q1025115)15/1
External linksUse in sister projects: [ar][de][en][es][fr][he][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][commons][species][wd][en.wikt][fr.wikt].
Planned useIdentify State electorates, LGAs, regional parks, localities, towns and suburbs
Number of IDs in sourceThere is currently 137 Local government areas of Western Australia, 59 Electoral districts of Western Australia, 14 Regional Parks and an undetermined number of localities, suburbs and towns in Western Australia
Expected completenesseventually complete (Q21873974)
Implied notabilityLandgate (Q6484527)
Formatter URLhttps://services.slip.wa.gov.au/public/rest/services/SLIP_Public_Services/Boundaries/MapServer/$1

Motivation[edit]

A recent discussion on the English Wikipedia highlighted the problem that Electoral districts LGAs, towns and localities in Western Australia often share a common name. Especially with the latter two, identification of what an item on Wikidata is about can sometimes be ambiguous. As an added benefit, where applicable, this identifier also provides a reference for land area covered. As can be seen in this list, further uses past the examples above is possible. Calistemon (talk) 08:07, 9 January 2023 (UTC)[reply]

Discussion[edit]

  •  Oppose I see that boundary_id and feature_number fields are also present--are these more stable than using the ObjectID field built into ArcGIS and should one of these fields be used instead? If Landgate were to switch from ArcGIS products to an alternative, the ObjectID field would seemingly be lost. If keeping with layerid/objectid, this would be generic for all ArcGIS geodatabases and thus this property proposal should instead be made generic too? The property name would be "Geodatabase ObjectID" (integer quantity) with a new qualifier property of "Geodatabase Layer Name" (monolingual text) and perhaps another "URL" qualifier or "Geodatabase" qualifier to denote where the geodatabase resides. ArcGIS state that layer IDs constantly change based on default drawing order unless a user has specifically changed a setting to allow manual assignment of static identifiers to each layer. Behind the scenes, a feature layer is generally a table in a database, and it therefore seems likely the table has a string identifier rather than an integer identifier. I'm not sure however if a layer name and table name correspond with each other. --Dhx1 (talk) 23:37, 9 January 2023 (UTC)[reply]
  • I’m going to see if I can get Andrew Owens to respond. He is hugely involved in Commons but has only just really found out about Wikidata but he is an extremely active participant in WA and knows all the ins-and-outs of WA and has an incredible knowledge of electoral and LGA boundaries. - Chris.sherlock3 (talk) 10:36, 10 January 2023 (UTC)[reply]
    Actually, just spoke to Andrew, he was at (and helped organise) the inaugural 2016 Wiki conference where Wikidata was explained in detail. Apologies to Andrew! - Chris.sherlock3 (talk) 10:52, 10 January 2023 (UTC)[reply]
  •  Comment Unfortunately the discussion above is far too technical for my understanding and I, as the nominator, can't provide any clarification whatsoever. Thanks for the opinions offered however as it is clearly preferable to kill off the proposal now rather than make all the effort of adding identifiers that may become dead links in the near future. Calistemon (talk) 14:51, 11 January 2023 (UTC)[reply]