Wikipedia talk:WikiProject Geographical coordinates/Archive 1

Format for display

Restating things I mentioned on the Manual of Style talk page, and more

Conversion

Q: I was given the following coordinates ( X: 1.019.760, Y: 1.041.109 ) and have no idea how to convert them to Grades, minutes and seconds. Does any body know?

spacing issues

One of your stated goals is more uniformity in the representation—but we need to decide what that uniform representation should be. For example, should there be any spaces at all within the numbers? Both ways are used. NIST, in explaining that this is an exception to the rule that there is a space between a number and its symbol, closes up all the spaces its example "α = 32°22′8″" http://physics.nist.gov/Pubs/SP811/sec07.html

• This rule has the advantage of being nonbreaking on the primes—though as I have seen with temperatures, the degree sign is not nonbreaking. If you do use spaces, it should be nonbreaking spaces between the degrees and minutes and between minutes and seconds.

I prefer the closed-up representation, with spaces between the number and the directional indicators and between latitude and longitude:

• 12°02′36″ S 177°01′42″ W

Gene Nygaard 12:04, 14 Feb 2005 (UTC)

I begun using no spaces, but found that at least on my screen the symbol and the next digit came so close that they were touching. Not pretty. I switched to   which looks better on my screen, FWIW. The ideal thing would be a non-breaking half-space. Is there such an animal? The break point is between the latitude and the longitude, which I think is as it should be. -- Egil 12:14, 14 Feb 2005 (UTC)

PS: My only idea would be to use a small nbsp, as in the 2nd example below:

1. 12° 32′ 06″ S 177° 01′ 22″ W
2. 12° 32′ 06″ S 177° 01′ 22″ W
3. 12°32′06″ S 177°01′22″ W

Did I mention that #3 looks awful with my font. Probably did. -- Egil 13:16, 14 Feb 2005 (UTC)

FYI I've placed a screen shot of how the above section looks in my Firefox here. -- Egil 19:07, 14 Feb 2005 (UTC)

Sorry, but I prefer the unspaced version, too, particularly if the implementation is going to be an underlinked click-through rather than the [n] external link mark: unspaced would be a lot less obtrusive on the page. Thus: 12°02'36" S 177°01'42" W -- maybe using apostrophes and quotation marks instead of proper sloping primes would help your display issues, or is suggesting that heretical?

I've just checked my Chicago Manual of Style, which seems to prefer the unspaced version and, incidentally, includes a comma after the N/S (so: 12°02'36" S, 177°01'42" W) -- something I always put in in coordinates I type manually. Or is that a layman vs. specialist thing? –Hajor 02:53, 15 Feb 2005 (UTC)

The apostrophe and quotation mark suggestion sounds quite reasonable to me, even though I have several times in the past changed them to primes (in conjunction with other editing, not just for the sake of doing so). Gene Nygaard 07:49, 15 Feb 2005 (UTC)

If you see here you'll notice on my screen for #3 the degree and ticks touch the next digit. That I think is outright ugly. Anyway, this is no hurry, and does not need to be decided now, since this policy issue on formatting can be easily enforced in Template:coor dms et al at any point. My suggestion is leaving it as #2 for a while, and try to reach an agreement when we have more experience. -- Egil 09:21, 15 Feb 2005 (UTC)

File:Four-x.png

The above shows how the coordinates of North Cape, Norway and Knivskjellodden are rendered on my screen, magnified 4X, when there are no blanks. Note how the prime is glued to the digits 2 and 6, and is also too close to the 5 (the combination with the 4 looks OK here, but not so good in 1X). I can assure that this is as bad as it looks in 1X also, bordering to the unreadable (as well as being ugly). Note also how the degree sign is closer to the following digit, which also looks unbalanced. For other digits then shown here, the degree sign touches the following digit. -- Egil 16:39, 15 Feb 2005 (UTC)

So show us how the same numbers look, blown up the same way, using Hajor's suggestion (75°10'21" N 25°47'54" E). Then, for comparison purposes, show us how much uglier the extra spaces (using the prime and double prime) look when they are blown up the same way as well. Gene Nygaard 20:45, 15 Feb 2005 (UTC)

File:Four-x-more.png

Done (I have changed the example to make it more worst case). Hajor's suggestion renders exactly like #3. Note how the symbols touch the next character. This is unacceptable. I believe #2 to be the best variation so far, leaving sufficient air around the symbols, while not as wide as the space used between words. (Ideally, that space could have been a pixel narrower) -- Egil 08:04, 16 Feb 2005 (UTC)

But if you make your actual display font larger, rather than these blown-up pictures of a small font, even if it is only half the size of these picture displays

1. the primes and the apostrophes and quotation marks are distinguished (and primes look better)
2. the symbols do not run into the characters, either way

There are lots of other uglinesses associated with the use of small, sans serif fonts as well; I'm not sure if we need to avoid all of them (e.g., ν v for nu and vee, Illinois). Gene Nygaard 13:46, 16 Feb 2005 (UTC)

I notice the issue of spaces and widths thereof is also discussed on Wikipedia_talk:Manual_of_Style_(dates_and_numbers)#20m_or_20_m.2C_etc.

That particular discussion isn't really relevant to the discussion at hand; the rules are separate for these which are actually one number with its first and second sexagesimal fractions. Gene Nygaard 20:45, 15 Feb 2005 (UTC)

It is relevant, because it discusses various ways of achieving narrow, unpaddable spaces. (And yes, I was thought to write 20m, not 20 m. But I've learned to accept the space, as long as it is unpaddable.) -- Egil 06:46, 16 Feb 2005 (UTC)

Yes, that is relevant. I have never worried much about the fact that Wikipedia allows a justified paragraphs option, and don't know for sure how it works. I've never even thought about a non-breaking space as also a "non-padding space". Most good justification algorithms include some spacing within the "words" as well as between words, don't they? But that usually doesn't get to be as extreme as the inter-word spacing can.

One thing that discussion does show is that the options are all work-arounds. Gene Nygaard 13:46, 16 Feb 2005 (UTC)

(Sorry if this has already been concluded) There are a few different spaces available. All shown between a prime and a zero:

1. ′0 - no space at all (yes the prime is there)
2. ′ 0 - an ordinary space
3. ′ 0 - a non-breaking space
4. ′ 0 - en space U+2002 = #8194
5. ′ 0 - em space U+2003 = #8195
6. ′ 0 - thin space U+2009 = #8201

For me, ordinary or non-breaking space are the same, and the narrowest of the spaces, and look better than no space or any other size. --ScottDavis 04:54, 19 Mar 2005 (UTC)

In case anyone cares, below is what it looks like on my Mac, in Safari. As you can see, there's no problem making out all the glyphs. But I dislike the format without any spaces, because it looks like a long random alphanumeric string—you have to stop and think to parse it out.

With even a bit of space, it intuitively reads as words "twelve degrees, thirty-two minutes, six seconds, south...". I would also prefer to have the comma between latitude & longitude. —Michael Z. 2005-03-29 22:37 Z

File:Four-x-mac.png

March 21 revision of Template:Coor dms

Template:Coor dms now includes a &nbsp; between the numbers. In infoboxes and, e.g. on Shorewood-Tower_Hills-Harbert, Michigan this can take up a lot of space. Further, it appears that the &nbsp; isn't rendered if the template is part of a wiki-| table (It works with wiki-<td> tables). To save space, I'd be in favor of returning to the previous format. -- User:Docu

padding with zeros

You, in your examples, padded zeros in your entry for the minutes and seconds. But that is not a feature of the template, at least not yet. You also did not pad a second zero in the longitude degrees. Gene Nygaard 12:04, 14 Feb 2005 (UTC)

As it is now, padding of zeros is accepted (there was a bug which is now gone), and the padding will appear just as in the template arguments. With todays template mechanism, I think there is no other way. -- Egil 12:16, 14 Feb 2005 (UTC)

links page

Forget about the format of the coordinates, let's talk about the link. I clicked on the coordinates at the Winnipeg, Manitoba article, and it took me to a confusing page that gave me a list of unessecary options including finding the location in Norway, United States, and the United Kingdom, despite the fact that Winnipeg is in none of those countries. This page should only have links to global maps... or better: clicking on the coordinates always takes you to the same maps site. --Munchkinguy 23:17, 22 Mar 2005 (UTC)

As the coordinate at Manitoba already has "region:CA" set, you may have the link call a subpage http://kvaleberg.com/wiki/index.php/Wiki:Map_sources/CA which would only give links relevant to Canada. There is already a similar subpage "US" at http://kvaleberg.com/wiki/index.php/Wiki:Map_sources/US -- User:Docu

The US subpage works, but the Canada subpage doesn't. It has links to maps of Norway and Switzerland. I will try to edit this template. --Munchkinguy 15:44, 23 Mar 2005 (UTC)

Error checking on entry

Is there any way the template can do some error checking of range of numbers, as well as convert them from text to numbers to aid in making consistent padding of the numbers?

I'd like to see something like the "Did not parse" errors in TEX entry. Gene Nygaard 12:04, 14 Feb 2005 (UTC)

No error checking yet, this should of course be implemented at some stage. -- Egil 12:21, 14 Feb 2005 (UTC)

Done. -- Egil 16:52, 15 Feb 2005 (UTC)

Error in off-Wikipedia map sources page

You have your minutes and seconds symbols reversed. Gene Nygaard 12:04, 14 Feb 2005 (UTC)

The source text for this is in fact on Wikipedia, so anyone can edit on Wikipedia:Map sources. What is off Wikipedia is the script. -- Egil 12:20, 14 Feb 2005 (UTC)

Comment: In the next PHP off-site implementation now being used, the page is off-site, but still editable. Follow the map sources link. -- Egil 16:48, 15 Feb 2005 (UTC)

Format for markup entry

The current quarter hemisphere thing was simply a hack out of necessity in the inital implementation (with no script, just doing Mapquest). This is no longer required, so we can design a better template. I do believe that the formatting for the article itself should be done via the template alone, though.

Perhaps the following syntax is more suitable:

   {{coord|48|46|36.48|N|121|48|51.84|W|}}

Which becomes: 48°46′36.48″N 121°48′51.84″W

With the current template mechanism, the dms is needed, because there is no conditional mechanism in the templates.

I have allowed for yet another argument, which is an optional map scale. This will of course not appear in the article, but is a useful parameter for many map resources (so that the initial map view shows the entiry country, island or whatever).

Comments invited. -- Egil 13:03, 14 Feb 2005 (UTC)

I think this entry method is preferable, and it'll make converting existing lat&long entries in the articles somewhat easier. I say go for it! (before it's too late and we go too far down the road with the other format.) Scaling, too, will be a great boost to the functionality: either here, or on the linked-to gateway page. Oh -- and please add the missing comma after "N", too, or am I the only one obsessing about that? –Hajor 01:15, 18 Feb 2005 (UTC)

If one wants to add a comma after the N, this should be done in the representation as implemented in the templates, Template:coor dms for instance. That said, use of a comma is not very common. -- Egil 08:41, 18 Feb 2005 (UTC)

{{coord|48|46|36.48|N|121|48|51.84|W|}}

why not {{coord|484636.48N|1214851.84W|}}

or {{coord|N484636.48|W1214851.84|}}

this way everybody can take the precision he wants e.g.

        {{coord|N48|W121}}

adding more numbers, making it more precise, leading Zeros in this concept are partialy necessary then.

BTW, you know: http://geo.sourceforge.net/Atlas/ ? best regards and good luck with the project Tobias Conradi 22:05, 8 Mar 2005 (UTC)

Chinasaur's suggestions

Great to see someone finally scripting this! I really look forward to seeing this incorporated into MW. One thing I wonder is how you envision this working in conjunction with the templates I have been working on (geolinks-US-streetscale etc.). I can imagine your stuff replacing the old system entirely. On the otherhand, geolinks may be a good way to provide more selective "suggested links" that are a little less promiscuous than the link page you are providing. Something to think about.

For the time being, let's try to coordinate (no pun intended). The geolinks templates have been added to RamMan's automatic city updates, so I assume they are pretty well accepted. If/when we ultimately switch over to your style templates we can hopefully get the city bot to help with that too.

There is no reson why these things cannot coexist. I added a small link to other maps in the georef streetscale template to show one way. -- Egil 08:41, 18 Feb 2005 (UTC)

Dealing with scale

I was just going to suggest a scale argument but I see you're working on it. Implementing this is going to be tricky though. Perhaps you would consider the model we have used for geolinks: "cityscale", "buildingscale", etc. The named scales is (I hope) an easier way for editors to remember what size they really want. The tricky part of course is translating this into the right "zoom" arguments for any particular web page; as you know they mostly use their own specific formats (i.e. zoom=5 on mapquest means something totally different from s=5 on terraserver). One thing that I think would work would be to use a "cityscale" style argument to your script as a string for another template name.

I'm not sure if I can explain this clearly off the cuff, but here goes: imagine I pass in "city" as the final argument to one of your templates. This then becomes the value for {{{scale}}} on your special page. You then link to mapquest using (psuedocode):

mapquest.com/?lat={{{lat}}}&lon={{{lon}}}&zoom={{mqscale-{{{scale}}}}} 

and to terraserver using (psuedocode):

terraserver.com/?lat={{{lat}}}&lon={{{lon}}}&zoom={{tsscale-{{{scale}}}}}

I believe this should work and result in the template {{mqscale-city}} and {{tsscale-city}} being loaded in as the scale arguments. My mind gets kind of boggled trying to remember MW's rules for loading templates but for an off-the-cuff trial see User:Chinasaur/Sandbox. Here I've used PAGENAME as a standin for your special variables since I believe they behave in similar ways. As you can see, the code correctly requests a template whose name depends on the value of PAGENAME. This approach will cause a proliferation of templates for all the different scales (city, county, building, street, hood, or whatever you decide on) and for all the different webpages, but I think that's okay, and this way it's transparent to editors and easily tweakable.

The intention was to base everything on a scale, and make the script supply scale factors as required for different URLs. (One thought: It should probably be allowed to enter 1e6 in addition to 1000000) Currently, the following is available:

{{{scale}}} which is the scale as a decimal number

{{{altitude}}} which is the altitude equivalent that MSN uses (143 for 1:1000000)

{{{zoom}}} which is the equivalent zoom factor for Mapquest

{{{span}}} suitable for Google and US Census (needs calibration)

I'm sure there are other quirky ways of defining scale, but hopefully they can be accomodated. Multimap uses a scale, but it has to be from a fixed list of about 10 different ones. A mechanism for that needs to be implemented.

So hopefully the countryscale/cityscale/buildingscale concept can be implemented in form of supplying a default scale? -- Egil 08:41, 18 Feb 2005 (UTC)

A lot of my suggestions were from the mindset of trying not to hard-code things. Your approach of using a single scale in the template and then having that generate a bunch of different scale parameters for different web sites is a natural solution. But what do you do if an editor wants to add a new map page with a new scale parameter? I went through all these template gymnastics with the idea that we wanted a system that is open to multiple editors; it's clearly undesireable to require a system patch to add new variables of these types. You don't want people to have to come to you anytime they want to change things... --Chinasaur 08:04, 4 Mar 2005 (UTC)

Hardcoded parameters for various map sources is defintely something I would want to avoid. If Wikipedia maprkup gets expression evaluation that could fix a lot of things, otherwise I can always make various configurable scaling parameters in the Map sources. In due course. -- Egil 21:04, 5 Mar 2005 (UTC)

Country filtering

My only other suggestion for now is that you could use the script to filter what country is being looked up. Since so many resources only work for US locations, it would be nice if the script first determined if the coordinates were US, then forwards you to an appropriate page within your demo server. For non-US locations, the script forwards you to a similar site without the US links. I'm not sure how the loading between the editable links page and the special page with the variable substitutions works, but I'm guessing that it would be possible to set this up so that all the US links are in a separate template that is just called from the US specific special page. This way it is transparent to editors who want to add US specific links. In fact, this way you could avoid creating more than one special page by having the script initialize the argument {{{country-specific-template-name}}} to the special page according to its parsing of the coordinates and then have the universal special page call that template ({{{{{country-specific-template-name}}}}}). This is assuming that the double substitution discussed above does indeed work. If this mechanism worked, you could use it to generate country specific links for as many countries as you have time to delineate coordinate rules for.

Anyway, as you can see, I'm full of enthusiasm for your work and also full of (hopefully useful) suggestions. I feel like this format is not the easiest way to bounce ideas off each other. If you're open to the idea, maybe we should get in touch by email or phone. Let me know on my talk page if this is cool and we'll work something out. Also I can help out with coding if (AND ONLY IF!) I get a little more time in the next few months. I'm a reasonable php hacker (I assume this is all php?). Nice work! --Chinasaur 00:32, 18 Feb 2005 (UTC)

P.S., you might be interested in my stillborn wikibook Wikibooks:GET--Chinasaur

Cool. You can probably find some material from the current Map sources already. Some sites, like MSN, are in fact helpful enough to supply information about their format. -- Egil 08:41, 18 Feb 2005 (UTC)

P.P.S., what about a variable for labeling markers where appropriate (e.g. for the tigermaps US census sites). You probably don't want to add more baggage to the editor end of the templates. What about adding PAGENAME into the templates though? After parsing with the script (to take off disambiguation in parens, etc.), this would probably work well for a {{{mlabel}}} variable!--Chinasaur

Interesting thougths. My idea was to include some mechanism for filtering based on pure location (range of lat/longitude, range of UTM zone or similar), so that for a location within the US, none of the resources unique to Europe et al would appear. It should also be possible to pipe other type of parameters through the map mechanism too. Of course, the implementation of such a mechansim should not be done purely for the map sources, it should be Wikipedia-wide for conditional inclusion of text — a mechanism sorely needed for the templates also.

An alternative, and simpler, mechanism would be to allow the map source mechanism to specify the name of the map page. So instead of using the default Wikipedia:Map_sources, you could always have Wikipedia:US_Map_sources etc.

Talking of altenatives, it would of couse be an alternative to implement the entire coordinate transformation based on a template instead of a Special page. In practical code development, the nice thing about the Special page is that it is very isolated from anything else. -- Egil 08:41, 18 Feb 2005 (UTC)