Template talk:Location/2012

Propose some changes

There are a few things I do not like in the current template:

• The code is really hard to read. Beside the use of the location -> location/lang -> location/layout makes synchronization difficult. For instance the parameter needed for {{Globe location}} was not added resulting in info loss for some languages. I would suggest to use a {{Location/i18n}}. It would at the very least provide some fall back in when a translation is missing (for instance "Location on Mars" displayed for Germans as "Location on Mars" rather than simply "Location")
• The "This and other images at their locations on" sounds unncessarily lengthy. Using icons like {{Institution/coordinates}} would be simpler and would not require any translation.
• There is no specific place to provide a name of a place either here or in {{Information}}. Of course we can provide geograpgical info in the description field of information but this is really not optimal: Either we put it inside a description in a particular language (ex "{{en|A bird flying in Los Angeles}}{{fr|Oiseau volant à Los Angeles}}", which is not well internationalized and not machine readable. Or we put it separetely "{{en|Bird flying in Los Angeles}}{{fr|Oiseau en vol}}{{city|Los Angeles"}}. But this is neither nice nor intuitive. Adding a "place" parameter to {{Location}} may be better.

I have created {{Location/sandbox}} and used it in File:A-Bomb Dome.jpg as a proof of concept. Thoughts ? --Zolo (talk) 14:41, 8 May 2012 (UTC)

I did not have time to study the new proposed template in detail, but I tested replacing {{Location}} with {{Location/sandbox}} in a regular configuration used on 472502 pages and the {{Location/sandbox}} version does not look right: box is broken and Google Earth and OSM links are missing. We will need to do much more testing of all 5 templates from the {{Location}} family since all of them rely on the same set of language templates (like {{Location/en}}) and {{Location/layout}}.

• Template:Location/ExternalLink probably needs an update. I did not look at it in last 3 years and nobody else did either. Links should be checked if they still work and if they have the optimal form. I liked proposed change to named parameters.
• Purpose of "This and other images at their locations on" was to spell out which links to other map websites can be included: only those that show other nearby images instead only this one image. As I recall it some people wanted links to many other map websites (like MapQuest, etc.), others only to "open source" websites like OSM, others to anything that does not have word "Google" in it (which they considered as free advertising for them), etc. I like the idea of switching to icons instead of text like we did in {{Institution/coordinates}}, but we would need more of a consensus before making such a big change and we would need to come up with icons for Google Earth and proximityrama (used for example here).
• User:Kaldari pointed out to me that use of {{Information field}} template without "other_field" parameter (as done in File:A-Bomb Dome.jpg) does not produce valid table HTML code. Firefox and possibly other browsers seems to display it properly, but not all browsers can display it. He demonstrated that we should not use {{Information field}} template without "other_field" parameter.
• Although I like the look of File:A-Bomb Dome.jpg I think we should try to accomplish it some other way, without adding a "place" parameter to {{Location}}. Expansion of {{Information}}? (probably too controversial) Expansion of alternative templates like {{Information2}}?

--Jarekt (talk) 04:52, 10 May 2012 (UTC)

One additional thing that makes it logically wobbly is that {{Location}} refers by default to the camera location while the place that should be mentionned is mostly the photographed place. And they can be several kilometer apart (think of the photograph of a mountain). I have added new parameters to {{Information2}} and used it on File:A-Bomb Dome.jpg. While I think the output is clear, I am not sure about how contributors will use it. Another concern is that location templates are apparently harvested by external websites, and adopting a new method in some files may be disruptive. --Zolo (talk) 13:06, 10 May 2012 (UTC)

I don't think the template should include the location in text.

The placement of {{Location}} by DschwenBot seems to be the standard location. I'm not sure though where this was discussed. --  Docu  at 06:53, 24 June 2012 (UTC)

Links

As pointed out by Jarekt in the previous thread {{Location/ExternalLink}} needs some refreshing. A few questions:

• In {{Location/doc}}, {{Object location dec|34.02427|-116.15830|region:DE-NI_scale:10000}} adds a link to Proximityrama, but not {{Location dec|34.02427|-116.15830|region:DE-NI_scale:10000_heading:SW}}. Is there a reason for that ?
• I think we can get rid of the language parameter for Google Maps and OSM. The language seems to be adjusted automatically to the browser setting / user's browsing history.
• Google Earth uses a link from the toolserver. It takes me to the right location but adds a "The GeoCommons database is currently unavailable" error message.
• {{Location/ExternalLink}} contains links to "Google Mars" and "Google Moon" but they are not used by {{Globe location}}. Are they used somewhere else ?--Zolo (talk) 07:39, 10 May 2012 (UTC)

Google mars and Moon are supposedly being discontinued, but the WikiMiniAtlas covers them (and further planetary bodies like Venus, Mercury, and the moon Io. The Proximityrama lists pictures looking at a location. If added to the Location template it would display images looking at the camera position. Not very useful. --Dschwen (talk) 14:33, 10 May 2012 (UTC)

Ok thanks. Is Proximityrama supposed to work ? As of now, I have only had error messages ("User 'para' has exceeded the 'max_user_connections' resource (current value: 15)~Wikimedia Commons images towards coordinates 34.02427, -116.15830").--Zolo (talk) 07:55, 11 May 2012 (UTC)

As most go through para's ts account, it might be that when you tested, you connected too many times ..

Proximityrama is only on "object location" as it displays images pointing to a given location. As a sample, you may want to try the one on this category. --  Docu  at 06:59, 24 June 2012 (UTC)

Ah ok it works nicely this time thanks.--Zolo (talk) 07:37, 24 June 2012 (UTC)

I was looking lately at improving {{Location/ExternalLink}}, as well. See {{Location/ExternalLink/sandbox1}} and {{Location/testcases}}. It seems like many country specific links were no longer needed, and others did not work correctly, like Chinese. I also like to use named parameters. I was also looking into small changes to {{Location/layout}}, see {{Location/layout/sandbox1}}. Mostly using new version of {{Location/ExternalLink}}, but also retiring calls to "if exists" function in the information section. I am not happy with the changes yet, so I will play with it some more. --Jarekt (talk) 17:40, 24 June 2012 (UTC)

Confused by the way we deal with altitude

I notice that for images that have been uploaded without a location but do have a location in their EXIF data, DschwenBot will add a "Location" template and encode the altitude using an alt:n style optional parameter clause. At least in the case of the EXIF data provided by my camera, the altitude will be in meters and have a single digit precision (eg. alt:901.1). Here is an image of mine with location provided by DschwenBot in this way: File:Monte Brè funicular 02.jpg.

If, on the other hand, I upload an image using the default upload wizard, it will attempt to add a location from the image's EXIF to the upload form. At least with my camera's EXIF data, in doing this it will set the altitude data on the form to something like "9095/10" (my quotes), which the next phase of the upload will error as an invalid altitude value. By a process of deduction, I've worked out that "9095/10" is really a way of representing "909.5". If I change the value to that format, the upload works. And the upload wizard adds a "Location dec" template with the altitude as the third parameter (ie just the numeric value 909.5, not as alt:909.5). Here is another image uploaded this way: File:Monte Brè funicular 12.jpg.

So we have two different ways of representing altitude. Neither is explicitly allowed by the template doc, but the first seems in line with other similar x:n_ clauses. The second seems, to my reading, to conflict with the doc. So which is correct. And is the behaviour of the upload wizard with regard to "9095/10" a bug?. -- Chris j wood (talk) 09:04, 5 July 2012 (UTC)

For the wrong number like "9095/10" Bugzilla:32608 is filed already. Raymond 11:39, 5 July 2012 (UTC)

Display error

There is some error in the template. Coordinates 49|17|1.796|N|16|34|2.695|E displays as 49.283833333333° 17.03′ 1.7999999999884.80″ N, 16.567413888889° 34.044833333333′ 2.6900000000023.69″ E at the image page. --ŠJů (talk) 11:30, 13 December 2012 (UTC)

Fixed. Should be fixed now. It seems like definition of MOD parser function changed so expressions like {{#expr:30.7mod7}} can return fractional numbers. I do not think that was the case before. So although template code did not changed, the template stopped working properly. Use "purge" to see the changes to the pages. --Jarekt (talk) 13:34, 13 December 2012 (UTC)