Misplaced Pages

This is an old revision of this page, as edited by Pigsonthewing (talk | contribs) at 12:15, 29 May 2007 (→Decimal-to-DMS conversion template: not needed). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Archives

• Archive 1
• Archive 2
• Archive 3
• Archive 4
• Archive 5
• Archive 6
• Archive 7
• Archive 8
• Archive 9
• Archive 10

To do

How should coordinates be formatted?

Please help with the discussion at Misplaced Pages:Peer review/Ridge Route; thank you. --NE2 01:04, 20 March 2007 (UTC)

Reference geo coordinates from an article

With some wonderful code, wikipedia now churns out clickable location maps of countries which add a new degree of interactability to the wiki ex: Indian_Institutes_of_Management . 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.
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 here-- 16:40, 31 March 2007 (UTC)

Template to request coords

I've created Template:LocateMe. 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 {{LocateMe|April 2007}} (or whatever month we're in after this one)) on talk pages. Andy Mabbett 23:33, 31 March 2007 (UTC)

FAQs?

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":

• 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.

• Q: The place is very big - what coordinates should I give?
  • 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.

Though the points are currently covered, they're not immediately apparent; and a "FAQ" format is more easily absorbed by first-time visitors.

Comments? Additions? Brickbats? Andy Mabbett 23:45, 31 March 2007 (UTC)

U.S. Roads

If we were to implement coordinates into the roads articles, how would we do it? --Rschen7754 (talk - contribs) 01:15, 1 April 2007 (UTC)

See Ridge Route. Andy Mabbett 14:24, 2 April 2007 (UTC)

request for a bot to apply "LocateMe"

Please note my request for a bot to apply "LocateMe" to articles about places, in need of coordinates. Andy Mabbett 09:54, 2 April 2007 (UTC)

It seems like you requested that bot tag the talk pages, which would be fine, but I don't see the point of tagging the article pages with an banner asking for a trivial piece of information to be added. In all probability the tags will stay there for a very long time, detracting from the article without having any benefit. If every wikiproject started pushing their project this way wouldn't all the articles look lovely? Yomangani 15:40, 4 April 2007 (UTC)

I first suggested the talk pages, but was told that using the article pages would be more appropriate. It's also in keeping with {{expand}}, {{ISBN}} and other "cleanup" type tags. Your reference to "trivial" information is unwarranted, and your final question, I presume, rhetorical. Andy Mabbett 20:14, 4 April 2007 (UTC) Andy Mabbett 20:14, 4 April 2007 (UTC)

I'm not suggesting that the coordinates are as trivial as ISBN numbers, but they certainly don't make or break an article, and citing other obtrusive templates that appear on the article page as a precedent for this one doesn't seem a particularly strong argument. Who benefits from the inclusion on the article page rather than the talk page? I'd be interested to know what the reasoning was from whomever suggested you put them on the article page. Yomangani 22:48, 4 April 2007 (UTC)

I add my voice against tagging articles. Tagging the talk page is sufficient to build a category list of articles to be tackled. Tyrenius has also spoken against tagging articles, at User talk:SatyrBot/Current project. So far 525 articles have been tagged. I do not think there is consensus for this action and would ask you to desist & reconsider. --Tagishsimon (talk)

See also Misplaced Pages:Administrators' noticeboard#LocateMe bot --Tagishsimon (talk)

I'm absolutely against this being placed on the article page. It's not something the average editor will respond to. It is a specialist task. Tyrenius 04:44, 5 April 2007 (UTC)

Indeed: as I said at Template talk:LocateMe, this template should appear on the talk page (if anywhere). It is more like {{reqphoto}} than {{copyedit}}. -- ALoan (Talk) 12:33, 5 April 2007 (UTC)

Suggestion: Add Coordinate Display Format into User Preferences

Did anything ever come of the May 2005 suggestion to add Coordinate Display Format into User Preferences? I'd be strongly in favour. Andy Mabbett 12:47, 2 April 2007 (UTC)

New template replaces "coor" family

Important! Please note that {{template:coord}} 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 Geo microformat. {{template:coord title}} 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. Andy Mabbett 13:48, 2 April 2007 (UTC)

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. --Gmaxwell 14:06, 2 April 2007 (UTC)

Google Earth - or anyone else - can now read the Geo microformat, 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. Andy Mabbett 14:37, 2 April 2007 (UTC)

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. --Gmaxwell 17:04, 2 April 2007 (UTC)

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? Andy Mabbett 17:12, 2 April 2007 (UTC)

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. --Gmaxwell 18:02, 2 April 2007 (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?) Andy Mabbett 22:07, 2 April 2007 (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 Wikiminiatlas also need a straightforward way to extract our geodata. Scanning every article via HTTP is completely unreasonable. --Gmaxwell 22:47, 2 April 2007 (UTC)

Outdent 1

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. Andy Mabbett 23:04, 2 April 2007 (UTC)

Can we please capture the coord title functionality into this template? For example {{coord|latitude|longitude|display=title}}. The proliferation of geotemplates is making machine reading of wikitext very very hard to do well.--Gmaxwell 14:28, 2 April 2007 (UTC)

I suggest you raise the specific changes you request with User:Quarl. Again, microformats will greatly increase the machine-readability of articles; see Project Microformats Andy Mabbett 14:37, 2 April 2007 (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. --Gmaxwell 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. Andy Mabbett 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. --Gmaxwell 17:53, 2 April 2007 (UTC)

You may wish to see my prior post on our interface problems]. --Gmaxwell 18:02, 2 April 2007 (UTC)

To which . Andy Mabbett 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. --Gmaxwell 22:06, 2 April 2007 (UTC)

Outdent 2

When I said that they resolved problems, I was referring to machine readability of HTML pages; which they do assist. They won't help the machine readability unless they're added as discrete components in each page's wikicode - which is certainly do-able, but would require a lot of re-engineering elsewhere. I suppose that's a result of an organically-grown, rather than fully-spec'd, system. Still I'm glad that we;re finding at least some common ground. I don't know enough about the way templates are made to understand you last sentence (my understanding is of HTML and microformats); I hope Quarl will be here soon; or perhaps you can make the changes? Andy Mabbett 23:16, 2 April 2007 (UTC)

Gah, it looks like we've just been having a misunderstanding. From the start I was only insisting that:

1. We should replace tags rather that adding more.
2. We can only do this if the new template covers the old features, which this doesn't yet.
3. We can also only do this if we have an active consensus, not simply a failure to object.
4. It might also be wise to contact the authors of some of the existing tools that use our geodata.
5. I'm not aware of any existing browser features that use microformats ... but we have wikiminiatlast *today*. Doesn't mean we shouldn't provide microformats, but it does mean we shouldn't break the tools.
6. We shouldn't make any wide scale geocoding template changes unless they resolve the outstanding issues of machine access.
7. We can resolve these issues by some simple additions to the proposed new template, but these additions might break the proposed syntax, so we shouldn't roll until they are ironed out.

Now that you have my attention, I'd be glad to work with you and everyone else to get a solution which fixes everything. :) —The preceding unsigned comment was added by Gmaxwell (talk • contribs) 23:53, 2 April 2007 (UTC).

Thank you. I've numbered and sub-divided your points, for convenience. I agree them all in principle. I think "coord" satisfies #1. Where and how do you suggest we achieve #3? Do you have a list, for #4 (I have some separate issues I'd like to raise with Google, about microformats (uFs) rather than WP, if you could put me in touch - in confidence of course)? #5 - there are a number of browser tools which use uFs, such as Operator, Tails and WebCards for Firefox. For more, see the "implementations" sections for each uF on the uF wiki. As for #7, like I said, that's beyond me, but I'm happy to learn; and to assist n any way I can, and to do the subsequent work, updating documentation, informing editors, etc. Andy Mabbett 10:08, 3 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 Template talk:Coor dms and on Misplaced Pages:Village pump (proposals). Andy Mabbett 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:: --Gmaxwell 22:06, 2 April 2007 (UTC)

What happened to the Parameters variable? - I think that the change to Template:coord 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. --Ozhiker 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* --Gmaxwell 18:09, 2 April 2007 (UTC)

I have reverted the redirects to Template:Coord until we can fix the parameter issue. - jredmond 18:46, 2 April 2007 (UTC)

I've referred the matter to User:Quarl, who edited the templates (at my request). Hopefuly, we can find a speedy remedy that will satisfy everybody, and meet everybody's needs. Andy Mabbett 21:29, 2 April 2007 (UTC)

The parameter issue seems to have been fixed. See Template:Coord/doc#Usage. --Para 22:06, 11 April 2007 (UTC)

The Misplaced Pages:Manual of Style (dates and numbers)#Geographical coordinates is currently incorrect - it needs to be reverted to show Template:Coor as the primary coordinate system until it is successfully phased out.

Also, the documentation for Template:Coord does not mention Misplaced Pages:Manual of Style (dates and numbers)#Geographical coordinates. I think it should.

I am getting the impression that this new template is being pushed only by User:Pigsonthewing (Andy Mabbett). Is there anyone else in favor of making this change?

So far I cannot see any benefits but there are a lot of potential pitfalls. I don't think that the potential inclusion of geo-microformats are worth us accepting any loss of features of the existing templates, especially since the geo-hack page already has the geo-microformat.

--Ozhiker 00:37, 4 April 2007 (UTC)

I believe that most, of not all, of your concerns have been addressed in the preceding discussion. If you can see "potential pitfalls" which have not been addressed, then please identify them specifically. Thank you. Andy Mabbett 07:49, 4 April 2007 (UTC)

Ok - the pitfalls I can see are mostly compatiblity and functionality concerns due to the enormous number of pages that use the template.

If the final HTML produced is different to the previous template, then:

1. Compatibility with all browsers, when template is in a variety of containers, positions and styles.
2. Compatibility with all templates that currrently use the coor templates
3. Compatibility with external tools, such as the indexer for google earth

Since the template is significantly different to the coor series in operation, the impact on the wikipedia servers should possibly be investigated, to make sure the new template does not create more lookups or other server load.

There is a good chance that functionality might be different in subtle ways that some people will perceive as a loss of functionality.

Functionality that is still missing that needs be implemented and tested before release:

1. Ability for article authors to control how the coordinates are displayed, either by displaying the same format as entered in the template or by specifically choosing a display format.
2. Parameters (eg scale, region etc) with ability for future expansion

New Features which would be useful:

1. Name tag for coordinates, allowing articles which have multiple coordinates on the page (eg Arthur Range) to tag each set of coordinates with a name for external parsers.

--Ozhiker 10:43, 4 April 2007 (UTC)

Thank you. Some of your issues are already resolved; I suggest you see Template:Coord/doc, which is still being updated by Quarl as I type. It may also be more appropriate to use its talk page, for further discussion, and especially for extra feature requests. Of your first set, there should be no significant changes, but I thought Google Earth parsed wikicode, not HTML? I still find some of your suggested pitfalls ("functionality might be different in subtle ways", for example) too vague to address. Andy Mabbett 10:59, 4 April 2007 (UTC)

Update

Quarl is done updating {{coord}} and adding additional backwards compatibility. Please see his summary at Template_talk:Coord#Updates and comment there. We'll now need to look at how this works for wikicode parsers. I think he's done a great job. Andy Mabbett 11:49, 4 April 2007 (UTC)

May I take the chance to ask for another little feature: a title arguments. With lots of inline coordinates (i.e. Ridge Route) external usability of the data would be greatly enhanced. My ideal solution, forget about the display= argument, request a title= for every inline coordinate and put the one coordinate without it in the title. --Dschwen 21:45, 4 April 2007 (UTC)

Please ask on Template_talk:Coord#Updates. Andy Mabbett 21:50, 4 April 2007 (UTC)

Templates with coordinates, but not using {{tl:coord}}

• {{Template:Geolinks-buildingscale}}
• {{Template:Geolinks-cityscale}}
• {{Template:Geolinks-naturalfeature}}

Articles that do not need coordinates

I am concerned at the recent indiscriminate tagging, by a bot, for the addition of coordinates, of articles that do not need them. This project's project page makes it clear that the project is about adding coordinates to articles that are about places (emphasis added). Yet the bot added a {{LocateMe}} to The Proms, which is a concert series, not a place. The bot's author has so far not accepted that this was inappropriate.

I have no affinity with the project, but I bring this matter to the attention of those who do. Such lack of discrimination risks bringing the project into disrepute.

Please can the project team reach a policy consensus on what articles should not have coordinates? Philip Trueman 19:59, 4 April 2007 (UTC)

From The Proms: "held annually in Central London". Andy Mabbett 21:30, 4 April 2007 (UTC)

So what? I count over 20 mainspace articles each about a painting in the National Gallery, London. Which do you think is better: to have a rule that says that each article should have coordinates, or to have a rule that each article should refer to National Gallery, London and that that article should have coordinates and the painting articles shouldn't? What do you think the consensus would be on which rule is better? Philip Trueman 12:27, 12 April 2007 (UTC)

As an enduser of the coordinate data (user:Dschwen/WikiMiniAtlas) I'd like for those paintings not to have coordinates unless they can be given with a precission comparable to the object size (that would be sub-meter). It makes no sense to clutter the map with gazillions of markers all at the exact same coordinates as the National Gallery marker (in this example). For a geospatial search application (show me all articles with 500ft) on the other hand it would make sense to code as many articles as possible. But again let me emphasize, that there must be a sane relation of precission and object size. --Dschwen 13:18, 12 April 2007 (UTC)

I almost agree, but I have two questions. One is: What is the object size of a series of concerts (or a collection of jewellery, or a police force, or an annual military parade)? If there isn't a meaningful answer to the question, then it isn't a meaningful question. The other is: What are the coordinates actually in Misplaced Pages for? I'm not an enduser of the data, and I'm not sure what endusers like you actually do. If your aim is, say, to use your GPS receiver to help you go and look at a painting, then I'd imagine that the coordinates of the front door of the gallery would be more useful than the coordinates of the painting, especially if it is actually on the third floor. In the case of The Proms, perhaps the most useful coordinates for a first-time visitor would those of the back end of the Arena Day Ticket queue - something that doesn't exist for most of the year but can change every few seconds at 90 minutes before the start of a popular concert. Philip Trueman 16:33, 12 April 2007 (UTC)

From the top of my head I'd say if you cannot answer the questions above the articles should not be geocoded. If we added a time stamp or time interval to the coordinates it might make sense (ever loaded a GPS trail into GoogleEarth? You get a timeline widget to select what data to display!). But for now I'd say concentrate on the clear-cut cases, that should be enough work for quite some time. --Dschwen 18:24, 12 April 2007 (UTC)

I agree completely. But what I'm looking for is a policy consensus that will provide me with grounds for removing coordinates (or {{LocateMe}} tags) from articles (and talk pages thereof) that don't need them, such as The Proms (I think that's been done) or Kew Constabulary or Crown Jewels of the United Kingdom. I do not want an edit war with Andy Mabbett, or anyone else. Admittedly the matter is much less urgent now that we don't have tags defacing those articles. But, well, do we really need a LocateMe tag on the talk page of Crystal Palace Dinosaurs (it's the paintings argument again, though I think Nordic churches in London actually passes muster, at least as the article currently stands) or Art in Perpetuity Trust? I think I'll take Maureen Paley to WP:COIN while I'm at it. Philip Trueman 19:29, 12 April 2007 (UTC)

The CP Dinosaurs could either be tagged with the generic coordinates for the park, or section of the park, where they reside, or with individual, in-line coordinates (perhaps by making the existing list into a table) for each one - see Manchester Ship Canal or Crossings of the River Severn for examples, albeit on linear features. Andy Mabbett 19:05, 15 April 2007 (UTC)

As I've said in more detail over on Talk:The Proms#Location coordinates, I see an issue with context. If you simply say x is in London so in the article on X we'll just stick in the coordinates for London, it is not clear to a future reader of the article that those coordinates were chosen merely to represent London, and not something more specific to X, whereas if you don't put any coordinates for X, if the user doesn't know where London is, they can go to London, and it's fairly obvious there that coordinates (and a map scale) have been chosen to give a reasonable overview of London. On the specific example of pictures in the National Gallery, it occurs to me that to fully represent their location, you would also need some representation of height, since the gallery has more than one floor... (edit-conflicted with Philip, hence some overlap in content) David Underdown 16:37, 12 April 2007 (UTC)

One further thought, for a geo-spatial search, it seems to me that really we should be tieing-in with Misplaced Pages's categorisation scheme. To stick to the examples we've been using here, if the search "knows" that the National Gallery is within 500m, there should also be some way of using Category:Collections of the National Gallery, London (a sub-cat of Category:National Gallery, London) to pick up those articles in the search too, rather than having to individually geo-tag each picture article. David Underdown 16:51, 12 April 2007 (UTC)

One more, it seems to me that to a large extent the coordinates are meta-data, and a number of people seem to see them as simply being an unnecessary level of detail for an encyclopaedia article. It occurs to me that you may find less resistance to the introduction of this data if an approach similar to {{persondata}} is used, meaning the data is (are?) hidden from human readers by default, those with an interest can add something to their css to make it visible, or use some sort of template which hides most of the data by default (eg something like the parameter used in {{Province of Canterbury}}. Further, on the idea of geo-spatial search, it seems to me taht particularly for something like London, rather than a single co-ordinate, you need a set of co-ordinates defining a boundary, anything within that boundary should return the article in you search results, as well as anywhere up to x metres from the boundary. Again this would need to be added in an "invisible" form for the most part,a s it would be entirely meaningless and obstructive for most human readers. Otherwise, artilces which take the "London" lcoation wouldn't appear on your geo-spatial search until you approached the "centre" given in the article - making Charing Cross seem even more interesting than it actually is. David Underdown 15:15, 17 April 2007 (UTC)

While I appreciate your taking the time to comment, I have no interest in hiding such data; I view that as harmful (and there are similar issues with Persondata, which are not on-topic here). There is already a facility for users who wish to hide coordinates to do so, with CSS. Andy Mabbett 15:23, 17 April 2007 (UTC)

Um, hang on. I regard anything that detracts from the readability of an article, by a human, as harmful. Misplaced Pages is (IMHO) first and foremost an encyclopedia intended to be consulted and read by humans, not a database to be queried by computer applications. If coordinates are to appear in the text of an article, they should be the coordinates of something meaningful to a human, and should not overpower the rest of the article. So, for example, a table in an article on a motorway giving the coordinates of every junction would certainly be overkill for the purposes of readability. I'm not saying that information isn't meaningful or useful, just that having it in the body of the article would detract from the readability of the article. If the user (and any computer application) is then provided with a means to burrow down into the article and unearth the coordinates than that's fine too. Some data should be hidden to first sight. Philip Trueman 16:13, 17 April 2007 (UTC)

"I regard anything that detracts from the readability of an article, by a human, as harmful." - as do I. I also regard the hiding of useful data as detracting from its readability.

" should not overpower the rest of the article" - I agree.

"a table in an article on a motorway giving the coordinates of every junction would certainly be overkill for the purposes of readability" - not if added to the existing tables of junctions, for example. Andy Mabbett 16:39, 17 April 2007 (UTC)

Andy Mabbett 16:39, 17 April 2007 (UTC)

Umm, yes it can be. I suggest that the six entry full-page-width table that used to appear in Tinsley Viaduct is a good example. It was disproportionate, and detracted from the readability of the article. I wouldn't though, have a problem if tables of junction data, coordinates and all, were hived off into subsidiary articles. Philip Trueman 16:52, 17 April 2007 (UTC)

Misplaced Pages doesn't work by having "rules". Andy Mabbett 16:45, 12 April 2007 (UTC)

Really? Why then so many policies, guidelines, manuals of style etc., etc.. David Underdown 16:51, 12 April 2007 (UTC)

Agreed. You probably misunderstood WP:IAR here... --Dschwen 18:24, 12 April 2007 (UTC)

A quick survey of tagging progress

I just did a very quick survey, by clicking on "random page" a few times -- of the 86 pages I looked at, before getting down to the bottom of the page in my notebook:

• 71 were not candidates for geolocation
• 7 were candidates for geolocation, properly categorized, but not geotagged
• 8 were both categorized and correctly tagged with their geolocation

Applying the ratios above to the roughly 1.7m article pages gives an estimate of about 150,000 for the number of tagged pages, which is reasonably close to the figures in the last Kolossus dump, and also suggests (on a rather small sample, with wide error bars) that roughly half of the articles needing tagging so far have been tagged. -- The Anome 23:50, 4 April 2007 (UTC)

Duplication of title coordinates

It looks as though articles that use {{Geolinks-US-cityscale}} and {{coor title dms}} now produce incompatible overlapping of the title coordinates. I'm not sure how long this has been happening, as I rarely even notice the title coordinates. But I did notice when someone started removing the geolinks templates from articles because of the incompatible duplication. For example, see Port Austin, Michigan. Seems that the geolinks uses decimal coordinates while coor title dms does not. I seem to recall that the geolinks templates did not previously add the coordinates into the title--though I could be mistaken--like I say, I rarely even notice the title coordinates. Personally, while I have no objection to the title coordinates, I find the geolinks presentation much more user-friendly. older ≠ wiser 12:28, 7 April 2007 (UTC)

Please see {{coord}}, which is intended to replace all of the coor template-family. geolinks templates should incorporate coord and this has been raised with the editor who is, I believe, responsible for geolinks. Andy Mabbett 16:17, 7 April 2007 (UTC)

Care should be take to avoid adding {{Geolinks-US-cityscale}} and {{coor title dms}} on the same page. As they are two separate templates, it should be fairly easy to spot collisions. -- User:Docu

Problems with Coord template

The Coord template doesn't appear to work on Great Barr, despite Great Barr being the sample article on Geo (microformat). Does it matter or will the Coord be discontinued? Seems a bit odd that people go around announcing that all articles should be like that. -- User:Docu

What do you mean "doesn't appear to work" ? It's working as expected, from here. No, {{coord}} will not be "discontinued". You appear to have something against it - perhaps you can reassure us that that's not the case? Andy Mabbett 16:22, 9 April 2007 (UTC)

Just wondering, where are the coordinates on Great Barr supposed to be displayed? -- User:Docu

Exactly where they are displayed; coord is being used, there, with the default, in-line setting. But if you don't know that - which is clearly explained in the template's documentation - how were you in a position to criticise? Now that's cleated up, perhaps you'll kindly reverse your recent reversion of the note about it, on the main coordinates meta-template? Andy Mabbett 16:49, 9 April 2007 (UTC)

Hm, not sure if there is much support for your idea.

Once the solution is working, maybe we want to discuss it. In the meantime, please stop changing articles from working templates to this type of mess. -- User:Docu

There is, apart form your bizarre, unsubstantiated and unfounded claims - nothing but support for the idea. It is already working. There is no "mess". I note that you have ignored the points in my previous post, and haven't been able to give the assurance I requested. I repeat: kindly reverse your recent reversion of the note about it, on the main coordinates meta-template. All you are succeeding in doing is stopping interested parties from finding out what's being planned.Andy Mabbett 19:07, 9 April 2007 (UTC)

Two comments: 1) This is a new template and works somewhat differently than other templates, so comments that amount to RTFM are not helpful (nor especially persuasive for engendering support for using the template). 2) The "problem" with Great Barr as it is now, is that the coordinates are in a decidedly unusually location. If that is suppose to be an exemplar of the new template's use, then I quite agree that it is a very poor example. The coordinates are simply hanging at the bottom of the page -- is this recommended by any style guide at present? If you want to use it in-line, the put it into a sentence or a bullet point, not dangling at the end of article. Otherwise, the standard placement for bare coordinates is in the title area. older ≠ wiser 17:13, 9 April 2007 (UTC)

I think it is entirely reasonable to expect someone to "RTFM", as you put it, before they announce that something isn't working; especially when it is. The coordinates in Great Barr are exactly where they were put. If you want to see other examples (of which there are already thousands in Misplaced Pages), then I you do indeed (to again use your own phrase need to "RTFM", since they're right there in the template's documentation. Andy Mabbett 19:07, 9 April 2007 (UTC)

Gee, thanks for more of your counterproductive rhetoric. While it may be completely unfair to the template (and anyone else who participated in developing it), your responses leave me inclined to ignore the template entirely and continue to use all the old familiar templates. older ≠ wiser 19:46, 9 April 2007 (UTC)

I'm glad at least Paradisal read the manual and fixed Pigsonthewig's change on Great Barr. Compared to the initial version by the Anomebot, the number of templates called by the coordinates appears to have increased from 3 to 9:

1. Template:Coord (protected)
2. Template:Coord/input/d
3. Template:Coor/prec dec
4. Template:Coor dec2dms1
5. Template:Coor dms2dec
6. Template:Precision1
7. Template:Coor link
8. Template:Coor URL (protected)
9. Template:Coord/display/title

Are they a problem? -- User:Docu

Sometimes people seem to choose to write long comments of a problem they could fix themselves in less than a minute, so someone had to go around and fix the conversion in that article. I can't comment on the server load of the template, but still don't really agree on introducing an incomplete template or doing the job only partially when converting other templates to it. The disappearance of the parameter variable mentioned above (halfway down) for example doesn't seem to have been fixed yet, and with the Great Barr article Pigsonthewig "fixed" the problem by simply removing the grid information that was in the parameters. When rtfming it myself, I was of two minds whether to revert the conversion altogether or allow it being done partially. --Para 22:44, 10 April 2007 (UTC)

{outdent}

Firstly it would seem far more sensible for any concerns you may still have to be raised on the template's talk page, where the author of the template is more likely to see them. If you look there, you'll also see that the parameter issue is resolved (or, if you think not, you'll need to be more specific about what you think is still missing). The change I made to Great Barr was done deliberately, as I needed an article using that configuration for testing, so chose a relatively low-key page.Andy Mabbett 07:55, 11 April 2007 (UTC)

I expected to see the followup here since the issue was raised here. But I have to admit that I didn't look past the first examples for info on parameters being supported or not, so I now added one there too. I advise you not to use live articles, even if low key, as a testbed for new templates, but instead have a sandbox of your own for that. --Para 22:06, 11 April 2007 (UTC)

Standardisation of co-ordinates in infoboxes

Has anyone seen/done any work on this? Are there any guidelines regarding the preferred formats for coordinates within infobox data entry? I have seen a number of different formats in use:

Anyone any ideas? Ta Frelke 20:45, 9 April 2007 (UTC)

A quick look at the source shows that {{Infobox UK place}} uses {{coor title d}}

Please be aware that the coor family are soon to be replaced by {{coord}}, which has all of their combined functionality, and adds user choice of display an the Geo microformat. Andy Mabbett 21:59, 9 April 2007 (UTC)

Initially it wasn't possible to use {{coor at dm}} as an argument for coordinates in the article, e.g. on Venice, Italy one couldn't use coordinates = {{coor dm|45|26|N|12|19|E}} for {{Infobox CityIT}}.

Back then, the way coordinates are displayed had to be defined in the infobox template. Thus the template was called with several variables, e.g. on Omagh there are: north coord = 54.36 | west coord = 7.19 for {{Infobox Place Ireland}}.

IMHO, in general, it's generally preferable to use to {{coor at dm}} in the article, rather than the infobox template.

However, there is one case where you want to use the variables of the coordinates to display a dot on a locator map in the infobox, in addition to the coordinates themselves: e.g. as Template:Infobox German Location does with "lat_deg = 49 |lat_min = 18 |lon_deg = 10 |lon_min = 35" on Ansbach. This avoids adding the same coordinates several times to the article.

Ideally, if a template needs variables such as lat_deg, lat_min, lon_deg, lon_min, they are always named the same. BTW in the sample, they are always "N"/"E".

The use or non-use of {{coord}} doesn't really change anything to this. -- User:Docu

::When you say that "it's generally preferable to ..." are you discussing your own preferences, or a MOS-issue, or some geo-guideline that I am unaware of? This is something that needs to be written down somewhere. It shouldn't be based on an individual's opinion. Frelke 06:56, 10 April 2007 (UTC)

Standardisation of co-ordinates in infoboxes (2)

Has anyone seen/done any work on this? Are there any guidelines regarding the preferred formats for coordinates within infobox data entry? I have seen a number of different formats in use:

Please can we keep this discussion relevant to the point in question and not include comments about the use of the brand spanking new {{coord}} template Frelke 08:21, 10 April 2007 (UTC)

A quick look at the source shows that {{Infobox UK place}} uses {{coor title d}}

Please be aware that the coor family are soon to be replaced by {{coord}}, which has all of their combined functionality, and adds user choice of display an the Geo microformat. Andy Mabbett 08:32, 10 April 2007 (UTC)

Due to continued trolling I am discontinuing involvement on this page. Frelke 08:53, 10 April 2007 (UTC)

Globe parameter

does the parameter globe work? I try:

{{Coor d|57.3|S|175.2S|E|globe:Moon}}

Coordinates: Longitude could not be parsed as a number:175.2S
{{#coordinates:}}: invalid longitude but it's still on earth. --WISo 09:04, 14 April 2007 (UTC)

Tinsley Viaduct

I recently added some coordinates to Tinsley Viaduct. My work was reverted and there's been some, er, interesting discussion which folks here might want to read. Andy Mabbett 13:03, 15 April 2007 (UTC)

Bit more heat than light in that discussion, I think, not to mention violations of WP:KETTLE. I called (above) for a project consensus on which articles needed coordinates and which didn't. Clearly there's a related question of whether articles need more than one set, and if so, how many, and a perhaps more fundamental question of how coordinates are to be presented. I really, really, do not think I should be the one who suggests what the consensus should be - that should done by someone committed to the project, and I'd prefer to stay outside the project making constructive criticism. FWIW, I'm sure there are articles that unquestionably need to have more than one set, and some already do (e.g. Channel Tunnel). But care should be taken to keep the article space taken up by the coordinates in proportion to their importance. A list of coordinates the full width of the page is likely to be overkill in most cases. Just asking, but in the case where more than one set are needed, could they be presented by, say, mouse rollover tooltips on a map rather than bald textual statements in the main body? Philip Trueman 13:59, 15 April 2007 (UTC)

"where more than one set are needed, could they be presented by, say, mouse rollover tooltips on a map" - that fails to meet basic accessibility criteria. How does a mouse rollover work for someone using a keyboard, or a touch-screen PDA? Andy Mabbett 14:26, 15 April 2007 (UTC)

A poll is now being conducted. Andy Mabbett 20:44, 15 April 2007 (UTC)

Coordinates for linear structures

Further to the above, I'd suggest that, for any linear structure (viaduct, canal, river, railway, wall (e.g. Hadrain's), motorway, etc.) then there are several significant coordinates - each end, the mid-point (for shorter structures, to give a location for the article as a whole: good for Tinsley Viaduct, not good for the M1), and any notable features, crossings or junctions. What constitutes "notable" will depend on the scale. Andy Mabbett 14:51, 15 April 2007 (UTC)

On a motorway, you'd do it in the list of junctions. --NE2 15:22, 15 April 2007 (UTC)

Yes, I've been looking at the tables on a few motorway pages, recently, to see if I could find a way to integrate coordinates without spoiling the presentation. I'd like to include the hCard microformat at the same time (see Crossings of the River Severn for examples). Any ideas? Andy Mabbett 15:28, 15 April 2007 (UTC)

I'd strongly support any way of getting linear coordinate info into articles. For the purpose of creating a layer on a map this information would be invaluable. A mere list of junctions (in the M1 example) on the other hand would merely clutter the map. --Dschwen 17:05, 15 April 2007 (UTC)

I'm not sure I follow you - why would it "clutter up the map"? Andy Mabbett 17:30, 15 April 2007 (UTC)

A slew of map markers of junctions would not be a ideal way of showing the Motorway on a map. They wouldn't standout from other markers and they would all point to the same article. It would be like having a connect the dots. With linear coordinate data I could draw a line on the map much more adequately visualizing the Motorway. --Dschwen 17:56, 15 April 2007 (UTC)

If you're concerned about having multiple markers for one article, than you should only include those {{coord}} with the attribute "display=title" (which may also be "display=inline,title" or "display=title,inline") which implies that the coordinates relate to the whole article, not merely one of may points referred to in it. Andy Mabbett 18:05, 15 April 2007 (UTC)

Sigh. Sure, but that still wouldn't give me polygon data to plot on the map. --Dschwen 18:24, 15 April 2007 (UTC)

I sympathise, but I can't see that we'll ever get to the point where WP has GIS data for roads and the like. Perhaps Wikimapia has something you could use? Andy Mabbett 18:33, 15 April 2007 (UTC)

Wikimapia is not what I'm aiming for. Wikimapia is not looking for encyclopedic relevance. And GoogleMaps is fine as a contemporary background, but I could also imagine generating historic map layers to illustrate wikipedia articles. It just seems as a logigal next step to me to insert not only point but polygon geodata into articles where it is appropriate.--Dschwen 18:53, 15 April 2007 (UTC)

Oh, and one tiny detail. Wikimapia only has lots of rectangular boxes. No linear structures no other polygons at all. --Dschwen 09:26, 24 April 2007 (UTC)

Churches

A potentially useful resource for articles on churches without coordinates isDove's Guide for Church Bell Ringers This contains information including (OS) grid reference or other coordinates for all churches with 3 or more bells hung for change ringing. The majority of these are in England, but it also includes some churches in the rest of British Isles, Australia, New Zealand, Canada, USA, South Africa, Zimbabwe, Kenya, India, Pakistan, St Vincent, Grenada and Spain! David Underdown 14:39, 20 April 2007 (UTC)

Coordinate template for non-terrestrial bodies

I've hacked up a coordinate template for non-terrestrial bodies which uses the USGS astrogeology mapbook and planetocentric latitude with east longitude (which, I believe, is the convention). It's currently parked at User:MER-C/Coord. MER-C 12:33, 22 April 2007 (UTC)

Good work. I think you need to include a property to indicate the schema in use (UK coordinates assume WGS84 - we'll have fun when that eventually changes!). See the discussion of non-Earth Geo on the microformats wiki (and linked pages), which is pertinent. Instead of coor mars I would use coor|mars, allowing for other bodies to be named as an attribute, say coor|venus or coor|moon. Note also that the name {{coord}} is already in use; and that that template has display options (title, inline or both) which you may wish to adopt. Perhaps coorp, with "p" for "planet" would be OK? You could then have, say, {{coorp|mars|IAU2000:49900|-2.1|354.5|Meridiani Planum}}. I hope that the output would be Meridiani Planum (-2.1,354.5), or suchlike, and that the coordinates would not be hidden. Would you be kind enough to use the HTML class names in the "Straw Man" at the aforesaid page, as a test case? Please see also WikiProject Microformats Andy Mabbett 13:00, 22 April 2007 (UTC)

I'd strongly discourage introducing a new template for this purpose.

Either add a parameter to {{coord}} or, even better use an already existing convention: the globe attribute! i.e type:landmark_scale:1000_globe:moon --Dschwen 13:48, 22 April 2007 (UTC)

{{coord}} may not be suitable, because of the different method of giving Westings. globe does not allow for a schema, as discussed above - though if these issues can be resolved, using coord may make sense. Andy Mabbett 14:23, 22 April 2007 (UTC)

I don't quite se/understand the problem, please could you elaborate? --Dschwen 16:16, 22 April 2007 (UTC)

Terrestrial coordinates range from 0 to 180 (Eastings) and 0 to -180 (Westings). AIUI, other bodies use 0 to 360. In each case, respectively. 10 west of the meridian would be -10 and 350 (all figures in degrees). A schema needs to be stated, because there is more than one way of measuring coordinates on the Moon, and on Mars. Again, see the linked discussion for more. Andy Mabbett 18:30, 22 April 2007 (UTC)

Isn't this a complete non-issue?! There is no ambiguity between the two schemes. Just use a modulo and both schemes are the same. --Dschwen 20:03, 22 April 2007 (UTC)

The Mars ones aren't quite the same. See, for example, . Notice the difference in latitude between the coordinate systems. MER-C 10:41, 23 April 2007 (UTC)

Yeah, the difference between Planetocentric and -graphic (explained here). But why is that an issue? We have to decide upone one system to use and the ensuing coordinate transformations to adapt to the various(?) map sources can be performed server-side. There are different coordinate systems on eath as well, still we are currently establishing a single template and have long decided to go with WGS84 as the coordinate system. --Dschwen 11:47, 23 April 2007 (UTC)

Also, {{coord}} links to http://tools.wikimedia.de/~magnus/geo/geohack.php?params= , which is very useless for stuff outside of Earth. And the naming was something I haven't decided - it was originally designed only for Mars but due to the inability of the USGS mapbook to produce meaningful output for a given location I changed the implementation. The new implementation has the additional bonus of working on every planet. MER-C 05:55, 23 April 2007 (UTC)

That can be changed easily. I'd volunteer to adapt the maphack. The code to adapt the westings could be included sever-side. --Dschwen 08:33, 23 April 2007 (UTC)

Nice job MER-C. I agree that the Eastings/Westings issue looks like a difference in signedness that's easily resolved by use of modulo. Integrating it in the same php script and templates would keep syntax and presentation uniform (though I can see arguments against it as well). —Quarl 2007-04-23 10:20Z

Title coordinates gone wrong?

Has something gone wrong with the template for title coordinates? For example, Shoreham-by-Sea's cooordinates at the top right are touching the line below the article title. (I'm using Internet Explorer 6, if that helps.) --A bit iffy 08:33, 26 April 2007 (UTC)

I'd also previously noted this problem, which seems to happen with certain infoboxes that set a smaller font size. I had suggested that the low-level template be modified to use a constant font size in the title area rather than inheriting it from the infobox. It could probably also be fixed in the infobox template but that would just fix that particular infobox. --GregU 13:50, 26 April 2007 (UTC)

Thanks Greg. I'll leave another request at Template talk:Coor at d.--A bit iffy 09:29, 29 April 2007 (UTC)

You should be able to fix the problem on Shoreham-by-Sea by placing Template:Coor title d on Template:Infobox UK place before <table class="infobox geography vcard" style="width: 23em;">. It works on Template:Infobox Swiss town. -- User:Docu

Please don't issue such advice without considering the ramifications - in this case, removing the coordinates from the hCard microformat. Andy Mabbett 21:52, 29 April 2007 (UTC)

Pigonthewing, what's your suggestion to fix your contribution? -- User:Docu

As already explained you you elsewhere, the bug is not in "my contribution". Andy Mabbett 10:21, 30 April 2007 (UTC)

Pigsonthewing, please check the additions on http://en.wikipedia.org/search/?title=Template:Infobox_UK_place&action=history -- User:Docu

My name is Andy Mabbett. If you think there's a problem, please identify it more specifically. Andy Mabbett 10:56, 30 April 2007 (UTC)

Pigsonthewing, GregU explained it above, do you understand it? -- User:Docu

Changed location of Barents Sea from (71°55′49″N, 41°20′49″E) to (71°56′N, 41°21′E)

The logic is that: ±½' of latitude (±½ Nautical Miles exactly) is approx ±1013 yards (exactly ±926m ≈ ±1km)

Traditionally Ship/Aircraft navigators used their divider's distance between the latitude lines as their unit of measure, i.e. 1 Nautical Mile.

Given the size of Barents Sea, ±1km seems reasonable. :-)

Could we also have a note somewhere extolling the virtues of using the Degree/Minute format (d°m′N d°m′W) for anything bigger then a ship? (This - as a consequence - becomes a great aid in mentally estimating distances between two objects.)

Is there a best (unintrusive) location for such a guideline?

(OT: another useful conversion is: 2 knots ≈ 1.03m/s, esp for estimating wind speed)

NevilleDNZ 06:08, 29 April 2007 (UTC)

Are you looking for WikiProject Geographical coordinates#Precision ? -- User:Docu

Even minutes were overkill for something this big. I changed them to simply (75°N, 40°E), which is better centered anyway. --GregU 06:36, 1 May 2007 (UTC)

Excellent, Greg. It may seem only a small thing, but any reduction in unnecessary detail is to be welcomed.--A bit iffy 07:31, 1 May 2007 (UTC)

Coord region parameter question

What is the region:GB part of region:GB_type:city giving us in the coord template? I've read the advice at Misplaced Pages:WikiProject_Geographical_coordinates#region:R but I'm just not getting it. I've experimented with & without the parameter & have not spotted a difference. --Tagishsimon (talk)

Try Meta:Gis_geo_tag#region:R. -- User:Docu

Thanks. That sheds some more light, but I come to the conclusion that the parameter is for a feature (the delivery of a set of maps located in the namespace Misplaced Pages:Map sources/RR where RR is the ISO code for the region) which has not been implemented. --Tagishsimon (talk)

...yet ;-) Andy Mabbett 10:17, 18 May 2007 (UTC)

It was implemented on egil's server that run the gis extension (later replaced by the current "geohack")

and is used on kolossos (see de:Misplaced Pages:WikiProjekt_Georeferenzierung/Wikipedia-World/en#Expert_mode). -- User:Docu

Decimal-to-DMS conversion template

I have created a template {{Coords dec to dms}} that will convert coordinates in decimal format to DMS format. I am not quite sure where this template can be used, but at least the functionality is available. ●DanMS • Talk 23:55, 28 May 2007 (UTC)

Thank you, but this functionality - and much more - is already provided by {{coord}}. Andy Mabbett 12:15, 29 May 2007 (UTC)

• Misplaced Pages pages with to-do lists