Revision as of 23:08, 2 April 2007 editPigsonthewing (talk | contribs)Autopatrolled, Event coordinators, Extended confirmed users, Page movers, File movers, IP block exemptions, New page reviewers, Pending changes reviewers, Rollbackers, Template editors266,141 edits →New template replaces "coor" family← Previous edit | Latest revision as of 02:57, 20 December 2024 edit undoИованъ (talk | contribs)Extended confirmed users2,349 edits →Lunar coordinate error message: new sectionTag: New topic | ||
Line 1: | Line 1: | ||
{{Misplaced Pages:Misplaced Pages Signpost/Templates/Signpost article link for WikiProjects|link=Misplaced Pages:Misplaced Pages Signpost/2013-05-27/WikiProject report|writer= ]| ||day =27|month=May|year=2013}} | |||
{{flatlist}} | |||
<!-- Automatic archiving | |||
*] | |||
-->{{User:MiszaBot/config | |||
*] | |||
| algo = old(270d) | |||
*] | |||
| archive = Misplaced Pages talk:WikiProject Geographical coordinates/Archive %(counter)d | |||
*] | |||
| counter = 30 | |||
*] | |||
| maxarchivesize = 200K | |||
*] | |||
| archiveheader = {{Automatic archive navigator}} | |||
*] | |||
| minthreadstoarchive = 2 | |||
*] | |||
| minthreadsleft = 6 | |||
*] | |||
}}<!-- | |||
*] | |||
--> | |||
{{endflatlist}} | |||
{{User:HBC Archive Indexerbot/OptIn | |||
|target=/Archive index |mask=/Archive <#> |leading_zeros=0 |indexhere=yes | |||
}} | |||
{{WikiProject banner shell| | |||
{{WikiProject Geographical coordinates}} | |||
{{WikiProject Microformats}} | |||
}} | |||
{{archive box|auto=yes|index=/Archive_index|search=yes|bot=lowercase sigmabot III|age=270}} | |||
==To do== | |||
{{to do (Misplaced Pages)}} | |||
<!-- ] 14:58, 20 October 2063 (UTC) --> | |||
{{to do}} | |||
==Feedback requested for innovation made== | |||
==How should coordinates be formatted?== | |||
Hello. There is a discussion that might be of your interest and it would be great if you can provide your feedback at ]. Sincerely, <span style="border-radius:8em;padding:0 7px;background:orange">]</span> ] 01:14, 16 March 2024 (UTC) | |||
Please help with the discussion at ]; thank you. --] 01:04, 20 March 2007 (UTC) | |||
== Improving geodata accuracy on OSM and Wikidata == | |||
== Reference geo coordinates from an article == | |||
I have captured my experience about improving geodata accuracy on OSM and Wikidata and shared it through and also ]. Let me know your feedback or your questions. ] (]) 11:04, 10 April 2024 (UTC) | |||
With some wonderful code, wikipedia now churns out clickable location maps of | |||
countries which add a new degree of interactability to the wiki ex: ] . But the process of | |||
marking each point using coordinates is tiring and cumbersome especially if | |||
something like a clickable road map is to be made.<br> | |||
It would be very useful if one could reference the coordinates from an article, | |||
like geo:London would return the geographical coordinates of London and mark it | |||
on the map. This can really unleash the power of location maps. Also posted on bugzilla --<sup> ]|]</sup> 16:40, 31 March 2007 (UTC) | |||
== |
== Global Entity Reference System == | ||
I see that the ] (https://overturemaps.org/) have created a new identifier, the ]. GERS identifiers are opaque 128-bit handles intended to identify unique entities at any level within the hierarchy of a geographic data system, but don't seem to be UUIDs. (See https://docs.overturemaps.org/guides/gers/). There seems to be some structure within them to be used to ease allocation (and perhaps as a sanity check), but that structure is not supposed to be used as data by end users. (See https://github.com/OvertureMaps/schema/discussions/27) | |||
They also define more structured metadata types, such as places: https://docs.overturemaps.org/schema/reference/places/place/ | |||
I've created ]. Should it go on their talk pages (as in the few examples currently tagged) or on the articles themselves (like other clean-up tags, such as clean-up itself, or "uncited" and so on? For now, please start using it (and advocating its use) if appropriate - just type '''<nowiki>{{LocateMe|April 2007}}</nowiki>''' (or whatever month we're in after this one)) on talk pages. ] 23:33, 31 March 2007 (UTC) | |||
We should probably follow this iniatiative and work out whether we should link our data with theirs. — ] (]) 10:17, 17 April 2024 (UTC) | |||
== FAQs? == | |||
== "coord restricted"? == | |||
As a newcomer to this project, might I suggest that the following questions go on the project page (or in a FAQ linked from it), with better answers than these "starters": | |||
I suggest a new coord family tag, {{tl|coord restricted}}. This would indicate that the article describes somewhere with known coordinates, but that those coordinates are restricted from public view with good reasons, and Wikipedians should not attempt to add coordinates to those articles. The primary use would be for archeological sites, whose locations are restricted to thwart vandals and grave robbers. — ] (]) 09:46, 4 May 2024 (UTC) | |||
:Is that consistent with the ]. Misplaced Pages is not ]: we are here to supply information. One productive way (that came from the discussion at ]) is to supply approximate coordinates, and highlight the fact that the coordinates are approximate. Barring coordinates entirely from an article seems excessive. — ] (]) 18:56, 4 May 2024 (UTC) | |||
:An approximation (e.g., d° m') followed by a hidden comment would suffice. If an editor disregards the hidden comment, they would likely disregard this proposed tag. ―] ] 19:06, 4 May 2024 (UTC) | |||
:Re U.S. locations: I've seen cases in which an ]-listed house's location was restricted at the owner's request but our article gave the house's street address, and I've also seen ones in which a historic district's location was restricted but the NHRP nomination form gave the district's exact boundaries. Figuring that the cat was out of the bag, so to speak, in those cases, I went ahead and added coordinates. I've also seen cases in which the NHRP restricts an archaeological site's location and I declined to add coordinates, even though I knew where the place is. Re archaeological sites elsewhere: If the site is labeled on Google Maps or OpenStreetMap, I think it would be overscrupulous to avoid giving coordinates in our article. I think your suggested tag might be a good idea, especially to replace {{tlc|coord missing}} tags in articles about places whose "coordinates are restricted from public view with good reasons", but I fear that it might be applied indiscriminately. I also think that approximate coordinates could be useful in some cases, as hike395 and Mandruss have suggested. ] (]) 22:08, 4 May 2024 (UTC) | |||
::I agree with {{u|hike395}} that Misplaced Pages is ], but we do not, for example, routinely publish people's home addresses, because there are sensible reasons not to do so. Approximate locations may be the right way to go in some circumstances; I did this recently for an archaeological site, where the exact location is restricted, but it is publicly described as being near a particular locality, by geolocating the article with that of the locality. For other cases, there might not be any locality to use in this way, and perhaps the use of very approximate coordinates might be a good idea for these cases. In any case, if we do have that tag, it should not be applied too widely, and just kept for edge cases like sensitive archological sites whose location is not already well-known. — ] (]) 11:08, 5 May 2024 (UTC) | |||
== Coordinates policy == | |||
*Q: How precise should the coordinates be? | |||
**A: Only as precise as needed for the size of place or structure; for a city, for instance, two or three decimal places or the nearest whole minutes - no need for seconds. | |||
Is it general WP policy that all articles on neighbourhoods, villages, towns, etc., should include their coordinates? ] (]) 04:33, 4 August 2024 (UTC) | |||
*Q: The place is very big - what coordinates should I give? | |||
:Policy, no; recommendation, yes. If it's a fixed point, it has coords. --] 🌹 (]) 08:43, 4 August 2024 (UTC) | |||
**A: For a building, the main entrance; for a city, the nominated centre point (e.g from which road distances are measured), if there is one, or the location of the main administration building (Town or City Hall, etc.); for a park or open space, the approximate centre. | |||
== What the fuck? == | |||
Though the points are currently covered, they're not immediately apparent; and a "FAQ" format is more easily absorbed by first-time visitors. | |||
The article ] currently shows coordinates are displayed to a precision of 0.1 second of arc. This is ridiculous overprecision, and entirely inappropriate to an article about such a serious subject; coordinates exist to show location, not to identify a particular doorknob. I've added format descriptors to the coord templates, which are only specified as decimals to 4 dp, to no avail; is this something being done by the infobox? If so, it's grotesque. — ] (]) 22:40, 6 August 2024 (UTC) | |||
:The infobox was using {{tl|Wikidatacoord}} to pull the overprecise coordinates from Wikidata. I've replaced that with coordinates given to four decimal places (copied from the {{tlc|OSM Location map}} template in the infobox, since I myself have no idea exactly where the event occurred). ] (]) 23:06, 6 August 2024 (UTC) | |||
== The Anomebot2 downtime == | |||
:Comments? Additions? Brickbats? ] 23:45, 31 March 2007 (UTC) | |||
Just to let you know, {{u|The Anomebot2}}, which geocodes articles and adds {{tl|coord missing}} tags, will be on hiatus for a bit, due to hardware failure and lack of time to restore it to operation. Everything is backed up, so nothing is lost, and I will be bringing the service back up in due course, probably running on a cloud instance. — ] (]) 20:58, 26 August 2024 (UTC) | |||
==]== | |||
:{{ping|The Anome}} Since it's been more than three months since the bot has added {{tlc|coord missing}} tags, can you give any information about when it will be running again? ] (]) 00:30, 17 October 2024 (UTC) | |||
If we were to implement coordinates into the roads articles, how would we do it? --''']''' (] - ]) 01:15, 1 April 2007 (UTC) | |||
:See ]. ] 14:24, 2 April 2007 (UTC) | |||
== Parallel and meridian articles == | |||
==request for a bot to apply "LocateMe"== | |||
Please note my ] to articles about places, in need of coordinates. ] 09:54, 2 April 2007 (UTC) | |||
I have two suggestions regarding to them. | |||
== Suggestion: Add Coordinate Display Format into User Preferences == | |||
# Parallel articles should have lists starting at 180th meridian, nor Prime meridian, to avoid splitting of Europe and Africa. | |||
# French overseas deps should have their own flags used. --] (]) 06:13, 2 September 2024 (UTC) | |||
== New script == | |||
Did anything ever come of the May 2005 ]? I'd be strongly in favour. ] 12:47, 2 April 2007 (UTC) | |||
Just letting anyone interested know that ] is now a thing - it helps with adding coordinates to pages in ]. ], it/he (]/]) 23:03, 4 September 2024 (UTC) | |||
== New template replaces "coor" family == | |||
== Seeking guidance for a feature in coordInserter == | |||
<big style="color:red;font-weight:bold;">Important!</big> Please note that {{]}} has just been made available. It replaces the existing "coor" family of templates (which now redirect to it); simplifies data entry; standardises display; and deploys a ]. {{]}} will follow shortly. Please advise fellow editors, and update documentation, accordingly. Please also notify this project of any coordinate-listing templates which do not include '''''coord'''''. Thank you. ] 13:48, 2 April 2007 (UTC) | |||
Hi. As Suntooooth and I ], the script mentioned in the thread above can add a template (probably should be created) to indicate that the article with restricted address (such as ], see the associated Wikidata item) can not have a coord template. The proposed template can prevent people from adding {{tl|coord missing}} again through a ] or an Editnotice. | |||
:Greetings. Please be aware that when you make changes like this you break machine readability for other tools (like google earth). I'm not opposed to making changes, but our changes should be in the direction of consolidation, and I'm not sure that this change is going far enough in that direction. --] 14:06, 2 April 2007 (UTC) | |||
The actual question is, when coordinates are not present at Wikidata like for the article mentioned above, is it always the case that the address is restricted? In other words, when the item ''has'' a {{property|P625}} property, but the property doesn't have coordinates data, should we place a template to indicate that there can't be a {{tlc|coord}} template on the page? ] ] 05:04, 7 September 2024 (UTC) | |||
::Google Earth - or anyone else - can now read the ], regardless of what current or future template generates it; no need for it to try to parse numerous templates - and that's a great step towards "consolidation". This has been discussed for sometime; there have been plenty of chances for such issues to be raised. ] 14:37, 2 April 2007 (UTC) | |||
: I would say "definitely not". There is no reason to believe that a missing datum at wikidata means that it has to be missing. Also, it's hard to believe that the number of sites with confidential locations is too many for manual intervention. ]<sup><small>]</small></sup> 12:47, 7 September 2024 (UTC) | |||
== bot to add the coordinates from wikidata to enwiki article == | |||
:::If google spidered our webpages any faster we'd probably have to block them. ;) The microformats don't help people working off dumps, which is the preferred way to work with all of the data. I raised this issue months ago when we first setup google earth's import, and I really don't appreciate your dismissive response. --] 17:04, 2 April 2007 (UTC) | |||
A few weeks ago, there was a request at ] for a bot to go through ], add the coordinates from wikidata to enwiki article, and remove the {{tl|coord missing}} template I had created a program to do that but I was notified that there was no clear consensus for the automation of the task. So here I am, trying the gauge the waters: would it be okay to automate the process? If yes, then what should be avoided, be careful of, and what format of the coordinates should be used? I believe if planned properly, this task could be safely automated. Courtesy ping {{ping|Deor|Dawnseeker2000|Suntooooth}} —usernamekiran ] 02:59, 31 October 2024 (UTC) | |||
:I've previously expressed an opposition to the indiscriminate importation of coordinates from Wikidata, and my opinion has not changed. A bot's doing it is by definition indiscriminate. ] (]) 16:07, 31 October 2024 (UTC) | |||
::Pinging {{ping|The Anome}}, who I believe has proposed bot importation of coords before. ] (]) 16:11, 31 October 2024 (UTC) | |||
:::@Deor I am neutral about the bot run. But I think we should discuss what should be, and shouldn't be done by the bot, and what are the risks. Maybe we can find solution for problematic cases, or skip such cases. I am currently running a very simpler similar task, of removing wikidata QID from enwiki infobox, if it matches with wikidata, in case any doubt, the bot skips the removal and adds such doubtful cases to ]. Maybe we can approach the coords task similarly? —usernamekiran ] 12:40, 1 November 2024 (UTC) | |||
== Article titles including co-ords as a disambiguator <span class="anchor" id="Article titles including co-ords as a disambiguator should be strongly, strongly discouraged unless it really is the only way of disambiguating (and even then...)"></span> == | |||
::::I didn't say anything about working faster - it's just working "smarter". Surely WP is primarily for people working off pages, not data dumps? ] 17:12, 2 April 2007 (UTC) | |||
{{small|Original heading: "Article titles including co-ords as a disambiguator should be strongly, strongly discouraged unless it really is the only way of disambiguating (and even then...)" ―] ] 16:05, 5 December 2024 (UTC)}} | |||
I've going through some articles and, sheesh, those locations are very often just wrong, and not only that, almost always, if it's a real place, there's at least ''something'' that can be used to disambiguate other than the co-ords. | |||
:::::We have millions of pages, it is not reasonable for someone to have to make millions of http requests just to extract the locations of all our pages. We provide dumps for this purpose but the vast number of possible geocoding templates makes extraction from the page data unreliable. The addition of this template as yet another way to code coordinates in articles just makes the problem worse, when with a few minor additions to the templates we could solve the issue completely. --] 18:02, 2 April 2007 (UTC) | |||
I think we should give some advice somewhere that we should always disambiguate a location with anything but co-ords if there's a better way of doing (e.g., county, district, province, etc.), and that if you find a map with two places with the same name close together, please consider that there may have been a mistake made somewhere because people aren't normally dumb enough to give their village the same name as one 5 minutes drive away. ] (]) 14:53, 5 December 2024 (UTC) | |||
::::::Other issues aside, it seems that the way you want things to work prioritises the convenience of data manipulators like Google over and above the convenience of editors and the convenience of individual end users. It strikes me that that's a bad thing, so I hope I've misunderstood you. I'd be grateful for clarification, please. (Also, is there a better place of all of these issues to be discussed, which will involve more of the people involved?) ] 22:07, 2 April 2007 (UTC) | |||
Yes, it isn't a good look. The only time coordinates should be used if there is several places of the same name within the same municipality and there is no way to distinguish them.♦ ] 15:07, 5 December 2024 (UTC) | |||
::::::: ... Can you please spell out your concern in detal? I don't follow, so hopefully more detail would help me understand. I haven't intentionally suggested anything that would cause difficulty for editors and, in fact, I think having fewer geocoding templates should make life easier on all of us. Google was invoked because I've spoken to them directly on this exact issue and people here seem to care about them.... But our internal data extracts are in the same boat, things like also need a straightforward way to extract our geodata. Scanning every article via HTTP is completely unreasonable. --] 22:47, 2 April 2007 (UTC) | |||
== Lunar coordinate error message == | |||
(outdent) | |||
The ] currently displays an error when the longitude exceeds 180°, as one might expect for the ]. In lunar science, however, that is not the only coordinate system in popular use. The ] in the sense of easting-only longitude values has overtaken the conventional +180°E/-180°W, thanks to becoming the standard for lunar datasets in 2006.<ref>{{cite web |date=2008-05-14 |orig-date=2006-08-23 |author=National Aeronautics and Space Administration |title=A Standardized Lunar Coordinate System for the Lunar Reconnaissance Orbiter and Lunar Datasets |version=5 |url=https://lunar.gsfc.nasa.gov/library/LunCoordWhitePaper-10-08.pdf |website=NASA |archive-date=2009-03-20 |archive-url=https://web.archive.org/web/20090320114848/https://lunar.gsfc.nasa.gov/library/LunCoordWhitePaper-10-08.pdf}}</ref> | |||
The new template is intended to be easier for editors to use; and provides more standardised output for the benefit of end users. It also provides a Geo microformat, again for the benefit of end users (I trust that we agree that these are all good things?). It replaces three other templates (and eventually six, or nine; I'd proposed bot-replacing all the coor family with "coord"), which satisfies your "''fewer geocoding templates should make life easier on all of us''" comment, with which I wholeheartedly agree. Doesn't that also make things easier for wikicode parsers? Don't Google scan our HTML anyway? I'm not clear why the new template is less satisfactory for the internal uses you mention. I suppose the issue is: are you arguing that the philosophy behind the changes is bad; or are you unhappy because they came as a surprise to you (ad, I can now see, have some hopefully-correctable flaws)? ] 23:04, 2 April 2007 (UTC) | |||
For example, the coordinate <nowiki>{{coord|23.7537|312.2210|globe:moon}}</nowiki> displays the message <nowiki>"{{#coordinates:}}: invalid longitude"</nowiki>. But the longitude is not invalid, and is understood perfectly by GeoHack. Conversion is easy (subtraction from 360°), but converting entire tables of planetocentric coordinates is tedious when all that has to be done to accommodate what is now the standard practice is to remove an error message carried over from geographic (Earth) standards in the case of globe:moon. | |||
:Can we '''please''' capture the coord title functionality into this template? For example <nowiki>{{</nowiki>coord|latitude|longitude|display=title<nowiki>}}</nowiki>. The proliferation of geotemplates is making machine reading of wikitext very very hard to do well.--] 14:28, 2 April 2007 (UTC) | |||
Can anyone with an understanding of the template/module system responsible for producing these error warnings point me to the proper channel for making the desired change? Thank you. ] (]) 02:57, 20 December 2024 (UTC) | |||
::I suggest you raise the specific changes you request with ]. Again, ]s will greatly increase the machine-readability of articles; see ] ] 14:37, 2 April 2007 (UTC) | |||
{{reflist-talk}} ] (]) 02:57, 20 December 2024 (UTC) | |||
:::Speaking from experience, *nothing* which comes in via transclusion is useful for machine readability of the Wikitext. If someone is working from the dumps they need a complete copy of the templates as well as a full Wikitext parser (um which means our horribly slow PHP one, since there is no other parser with complete template support) in order to use anything that comes out of templates. This is an unreasonable requirement. | |||
:::I am reverting your changes to the instruction pages, we don't need yet another widespread uncoordinated breakage of machine readability unless it's going to actually solve some problems. --] 17:04, 2 April 2007 (UTC) | |||
::::It *is * solving problems; and it is not "uncoordinated" - you have had plenty of opportunity to comment, while this was being discussed, on numerous talk and project pages. I've restored the changes. Please discuss as resolution before reverting again. ] 17:12, 2 April 2007 (UTC) | |||
:::::How am I supposted to know about discussion on a page whos existance I could not have known about? The changes were not discussed here as far as I know. Please don't make us look like idiots. I've spend a lot of time wearing the Wikimedia hat coordinating with reusers and researchers and making a part-way change to our wikitext format will just make our readability problems worse. I think the changes are a good step but we should make sure they address all the important issues and then mass push them across the project rather than making a part-way transisition which will leave yet another syntax that people have to support. --] 17:53, 2 April 2007 (UTC) | |||
::::::You may wish to ]. --] 18:02, 2 April 2007 (UTC) | |||
:::::::To which ]. ] 21:37, 2 April 2007 (UTC) | |||
::::::::Sure enough, I missed it. :) Um, except they don't at all solve it for us. I realize that microformats are the current ultimate in buzzword compliance, but if implemented via templates they don't do anything to make our actual pages more machine readable. For example, how does coord's use of microformats help me write a bot that goes removes locations which are known to be incorrect or which adjusts the scale for georefs inside a given bounding box? .. We tell people who want to work with our data (including our own users) to use the dumps, but microformats transcluded via n-deep indirection are not helpful there. | |||
:::::::::Please note, I do strongly support us having microformats. My objections are that (1) we shouldn't change the project wide syntax without also addressing the other machine readability issues, and (2) we shouldn't break existing features (i.e. adjustable scale). Adding some simple modes to the coord template (one to adjust the title, one to output the lat, long in dec. deg. for use in other templates) would get us a lot of the way there. --] 22:06, 2 April 2007 (UTC) | |||
::::::"''How am I supposted to know about discussion on a page whos existance I could not have known about?''" - The issue was flagged up on '''''this talk page''''', on '''''this project's''''' main page, on ] and on ]. ] 21:33, 2 April 2007 (UTC) | |||
:::::::Where was it discussed here, I can't find it. I only look at VP once a week or so, the SNR is terrible. ::shrugs:: --] 22:06, 2 April 2007 (UTC) | |||
:What happened to the Parameters variable? - I think that the change to ] should be reverted ASAP until the parameters can be included. The lack of the parameters variable means that the ''scale'' parameter is completely ignored, and maps are always requested at 1:300000. Theother parameters are not currently used by the geo-hack interface, but they probably will be used in the near future. Now users have no way of tagging what type of item is listed, what country it is in, or, most importantly, what scale it is. --] 18:07, 2 April 2007 (UTC) | |||
::Sure enough it doesn't pass scale. Blah! I was hoping we could get away without reverting the rest of the changes. *sigh* --] 18:09, 2 April 2007 (UTC) | |||
:::I have reverted the redirects to ] until we can fix the parameter issue. - ] 18:46, 2 April 2007 (UTC) | |||
::::I've referred the matter to ], who edited the templates (at my request). Hopefuly, we can find a speedy remedy that will satisfy everybody, and meet everybody's needs. ] 21:29, 2 April 2007 (UTC) | |||
===Templates with coordinates, but not using {{tl:coord}}=== | |||
*{{]}} | |||
*{{]}} | |||
*{{]}} |
Latest revision as of 02:57, 20 December 2024
WikiProject Geographical coordinates was featured in a WikiProject Report in the Signpost on 27 May 2013. |
This project page does not require a rating on Misplaced Pages's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||
|
Archives |
Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 |
This page has archives. Sections older than 270 days may be automatically archived by Lowercase sigmabot III when more than 6 sections are present. |
To do
To-do list for Misplaced Pages:WikiProject Geographical coordinates: edit · history · watch · refresh · Updated 2022-04-18
Find coordinates for
Use Maybe-Checker: verify and/or add coordinates to articles in categories likely to need coordinates. Articles are also listed on WolterBot's cleanup listings (User:WolterBot/Cleanup statistics) See also: Misplaced Pages:Obtaining geographic coordinates Tag articles needing coordinates
FixAs of December 28, 2024 01:24 (UTC) Refresh
Formatting errors:
More
|
Feedback requested for innovation made
Hello. There is a discussion that might be of your interest and it would be great if you can provide your feedback at Misplaced Pages talk:WikiProject Maps#Feedback requested for innovation made. Sincerely, Thinker78 (talk) 01:14, 16 March 2024 (UTC)
Improving geodata accuracy on OSM and Wikidata
I have captured my experience about improving geodata accuracy on OSM and Wikidata and shared it through a short OSM user diary and also a long form article on OSM wiki. Let me know your feedback or your questions. Arjunaraoc (talk) 11:04, 10 April 2024 (UTC)
Global Entity Reference System
I see that the Overture Maps Foundation (https://overturemaps.org/) have created a new identifier, the Global Entity Reference System. GERS identifiers are opaque 128-bit handles intended to identify unique entities at any level within the hierarchy of a geographic data system, but don't seem to be UUIDs. (See https://docs.overturemaps.org/guides/gers/). There seems to be some structure within them to be used to ease allocation (and perhaps as a sanity check), but that structure is not supposed to be used as data by end users. (See https://github.com/OvertureMaps/schema/discussions/27)
They also define more structured metadata types, such as places: https://docs.overturemaps.org/schema/reference/places/place/
We should probably follow this iniatiative and work out whether we should link our data with theirs. — The Anome (talk) 10:17, 17 April 2024 (UTC)
"coord restricted"?
I suggest a new coord family tag, {{coord restricted}}. This would indicate that the article describes somewhere with known coordinates, but that those coordinates are restricted from public view with good reasons, and Wikipedians should not attempt to add coordinates to those articles. The primary use would be for archeological sites, whose locations are restricted to thwart vandals and grave robbers. — The Anome (talk) 09:46, 4 May 2024 (UTC)
- Is that consistent with the purpose of Misplaced Pages?. Misplaced Pages is not censored: we are here to supply information. One productive way (that came from the discussion at Talk:Hyperion (tree)) is to supply approximate coordinates, and highlight the fact that the coordinates are approximate. Barring coordinates entirely from an article seems excessive. — hike395 (talk) 18:56, 4 May 2024 (UTC)
- An approximation (e.g., d° m') followed by a hidden comment would suffice. If an editor disregards the hidden comment, they would likely disregard this proposed tag. ―Mandruss ☎ 19:06, 4 May 2024 (UTC)
- Re U.S. locations: I've seen cases in which an NRHP-listed house's location was restricted at the owner's request but our article gave the house's street address, and I've also seen ones in which a historic district's location was restricted but the NHRP nomination form gave the district's exact boundaries. Figuring that the cat was out of the bag, so to speak, in those cases, I went ahead and added coordinates. I've also seen cases in which the NHRP restricts an archaeological site's location and I declined to add coordinates, even though I knew where the place is. Re archaeological sites elsewhere: If the site is labeled on Google Maps or OpenStreetMap, I think it would be overscrupulous to avoid giving coordinates in our article. I think your suggested tag might be a good idea, especially to replace
{{coord missing}}
tags in articles about places whose "coordinates are restricted from public view with good reasons", but I fear that it might be applied indiscriminately. I also think that approximate coordinates could be useful in some cases, as hike395 and Mandruss have suggested. Deor (talk) 22:08, 4 May 2024 (UTC)- I agree with hike395 that Misplaced Pages is WP:NOTCENSORED, but we do not, for example, routinely publish people's home addresses, because there are sensible reasons not to do so. Approximate locations may be the right way to go in some circumstances; I did this recently for an archaeological site, where the exact location is restricted, but it is publicly described as being near a particular locality, by geolocating the article with that of the locality. For other cases, there might not be any locality to use in this way, and perhaps the use of very approximate coordinates might be a good idea for these cases. In any case, if we do have that tag, it should not be applied too widely, and just kept for edge cases like sensitive archological sites whose location is not already well-known. — The Anome (talk) 11:08, 5 May 2024 (UTC)
Coordinates policy
Is it general WP policy that all articles on neighbourhoods, villages, towns, etc., should include their coordinates? Mcljlm (talk) 04:33, 4 August 2024 (UTC)
- Policy, no; recommendation, yes. If it's a fixed point, it has coords. --Redrose64 🌹 (talk) 08:43, 4 August 2024 (UTC)
What the fuck?
The article 2024 Southport stabbing currently shows coordinates are displayed to a precision of 0.1 second of arc. This is ridiculous overprecision, and entirely inappropriate to an article about such a serious subject; coordinates exist to show location, not to identify a particular doorknob. I've added format descriptors to the coord templates, which are only specified as decimals to 4 dp, to no avail; is this something being done by the infobox? If so, it's grotesque. — The Anome (talk) 22:40, 6 August 2024 (UTC)
- The infobox was using {{Wikidatacoord}} to pull the overprecise coordinates from Wikidata. I've replaced that with coordinates given to four decimal places (copied from the
{{OSM Location map}}
template in the infobox, since I myself have no idea exactly where the event occurred). Deor (talk) 23:06, 6 August 2024 (UTC)
The Anomebot2 downtime
Just to let you know, The Anomebot2, which geocodes articles and adds {{coord missing}} tags, will be on hiatus for a bit, due to hardware failure and lack of time to restore it to operation. Everything is backed up, so nothing is lost, and I will be bringing the service back up in due course, probably running on a cloud instance. — The Anome (talk) 20:58, 26 August 2024 (UTC)
- @The Anome: Since it's been more than three months since the bot has added
{{coord missing}}
tags, can you give any information about when it will be running again? Deor (talk) 00:30, 17 October 2024 (UTC)
Parallel and meridian articles
I have two suggestions regarding to them.
- Parallel articles should have lists starting at 180th meridian, nor Prime meridian, to avoid splitting of Europe and Africa.
- French overseas deps should have their own flags used. --40bus (talk) 06:13, 2 September 2024 (UTC)
New script
Just letting anyone interested know that User:Jeeputer/coordInserter is now a thing - it helps with adding coordinates to pages in Category:Articles missing coordinates with coordinates on Wikidata. Suntooooth, it/he (talk/contribs) 23:03, 4 September 2024 (UTC)
Seeking guidance for a feature in coordInserter
Hi. As Suntooooth and I discussed on my talk page, the script mentioned in the thread above can add a template (probably should be created) to indicate that the article with restricted address (such as Anderson Site (Franklin, Tennessee), see the associated Wikidata item) can not have a coord template. The proposed template can prevent people from adding {{coord missing}} again through a Preview warning or an Editnotice.
The actual question is, when coordinates are not present at Wikidata like for the article mentioned above, is it always the case that the address is restricted? In other words, when the item has a coordinate location (P625) property, but the property doesn't have coordinates data, should we place a template to indicate that there can't be a {{coord}}
template on the page? Jeeputer 05:04, 7 September 2024 (UTC)
- I would say "definitely not". There is no reason to believe that a missing datum at wikidata means that it has to be missing. Also, it's hard to believe that the number of sites with confidential locations is too many for manual intervention. Zero 12:47, 7 September 2024 (UTC)
bot to add the coordinates from wikidata to enwiki article
A few weeks ago, there was a request at WP:BOTREQ for a bot to go through Category:Articles missing coordinates with coordinates on Wikidata, add the coordinates from wikidata to enwiki article, and remove the {{coord missing}} template permalink. I had created a program to do that but I was notified that there was no clear consensus for the automation of the task. So here I am, trying the gauge the waters: would it be okay to automate the process? If yes, then what should be avoided, be careful of, and what format of the coordinates should be used? I believe if planned properly, this task could be safely automated. Courtesy ping @Deor, Dawnseeker2000, and Suntooooth: —usernamekiran (talk) 02:59, 31 October 2024 (UTC)
- I've previously expressed an opposition to the indiscriminate importation of coordinates from Wikidata, and my opinion has not changed. A bot's doing it is by definition indiscriminate. Deor (talk) 16:07, 31 October 2024 (UTC)
- Pinging @The Anome:, who I believe has proposed bot importation of coords before. Deor (talk) 16:11, 31 October 2024 (UTC)
- @Deor I am neutral about the bot run. But I think we should discuss what should be, and shouldn't be done by the bot, and what are the risks. Maybe we can find solution for problematic cases, or skip such cases. I am currently running a very simpler similar task, of removing wikidata QID from enwiki infobox, if it matches with wikidata, in case any doubt, the bot skips the removal and adds such doubtful cases to User:KiranBOT/List of mismatched QID. Maybe we can approach the coords task similarly? —usernamekiran (talk) 12:40, 1 November 2024 (UTC)
- Pinging @The Anome:, who I believe has proposed bot importation of coords before. Deor (talk) 16:11, 31 October 2024 (UTC)
Article titles including co-ords as a disambiguator
Original heading: "Article titles including co-ords as a disambiguator should be strongly, strongly discouraged unless it really is the only way of disambiguating (and even then...)" ―Mandruss ☎ 16:05, 5 December 2024 (UTC)
I've going through some articles and, sheesh, those locations are very often just wrong, and not only that, almost always, if it's a real place, there's at least something that can be used to disambiguate other than the co-ords.
I think we should give some advice somewhere that we should always disambiguate a location with anything but co-ords if there's a better way of doing (e.g., county, district, province, etc.), and that if you find a map with two places with the same name close together, please consider that there may have been a mistake made somewhere because people aren't normally dumb enough to give their village the same name as one 5 minutes drive away. FOARP (talk) 14:53, 5 December 2024 (UTC)
Yes, it isn't a good look. The only time coordinates should be used if there is several places of the same name within the same municipality and there is no way to distinguish them.♦ Dr. Blofeld 15:07, 5 December 2024 (UTC)
Lunar coordinate error message
The coord template currently displays an error when the longitude exceeds 180°, as one might expect for the selenographic coordinate system. In lunar science, however, that is not the only coordinate system in popular use. The selenocentric coordinate system in the sense of easting-only longitude values has overtaken the conventional +180°E/-180°W, thanks to becoming the standard for lunar datasets in 2006.
For example, the coordinate {{coord|23.7537|312.2210|globe:moon}} displays the message "{{#coordinates:}}: invalid longitude". But the longitude is not invalid, and is understood perfectly by GeoHack. Conversion is easy (subtraction from 360°), but converting entire tables of planetocentric coordinates is tedious when all that has to be done to accommodate what is now the standard practice is to remove an error message carried over from geographic (Earth) standards in the case of globe:moon.
Can anyone with an understanding of the template/module system responsible for producing these error warnings point me to the proper channel for making the desired change? Thank you. Ivan (talk) 02:57, 20 December 2024 (UTC)
References
- National Aeronautics and Space Administration (2008-05-14) . "A Standardized Lunar Coordinate System for the Lunar Reconnaissance Orbiter and Lunar Datasets" (PDF). NASA. 5. Archived from the original (PDF) on 2009-03-20.
Ivan (talk) 02:57, 20 December 2024 (UTC)
Categories: