This is an archive of past discussions about Module:Location map. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Is there any way that the 4 positions for the label can be tweaked? I've noticed a problem on a number of UK articles, for instance Lambroughton; if the default right positioning is used the label goes outside the map, and this also occurs with top and bottom positioning. If left positioning is used, the last letter of the place name overlaps the locator pushpin.
Is there anyway to force the label to be further left, or to allow a manual positioning of the label for those cases where default positions fail?--Nilfanion (talk) 10:48, 17 September 2010 (UTC)
I brought this up in the thread above. I had thought about adding a "farleft" option or something, or a nudge factor or something. It would be fairly easy to add an additional keyword that would result in pushing twice as far to the left, if there was some consensus for what to call it (e.g., left2, farleft, wideleft, leftx2, ...). Or, we could make it so if the label position is a number, then this is the value used for the offset. Or, we could add yet another parameter which would allow for either adding to, or overriding the default value for the label offset. Comments? Plastikspork―Œ(talk)22:44, 25 September 2010 (UTC)
Extra two pixels
I've noticed that the first div block adds two pixels to the width of the output. Both pixels end up on the right side. Kind of like a right hand margin for an image that floats right. Does anyone know why this is done. Also, could we have a parameter that would prevent the extra pixels from being being added. It would be useful in Infoboxes. –droll[chat]00:15, 13 October 2010 (UTC)
Isn't it something to do with Internet Explorer not following the W3C standards for borders, padding etc., so that we need to compensate? --Redrose64 (talk) 17:46, 13 October 2010 (UTC)
Thanks for the reply. I don't know that its needed for IE. [[Image|...]] doesn't generate anything like this. I haven't checked to see if it has something to do with the way captions are handled though. It just seems a bit daft. I'll think about it. –droll[chat]20:28, 13 October 2010 (UTC)
P.S. I'm only concerned about the case with no caption and no boarder. The extra pixels might well be required when a border is used. –droll[chat]20:39, 13 October 2010 (UTC)
I worked on a version in the sandbox and reached the conclusion that the 2px only needed if there is a boarder. I checked the testcases in Foxfire, Chrome, Opera, Safari, IE 7 and IE 8 on windows, and Firefox and Epiphany on Linux. I want to think about the code in the sandbox for a bit unless Plastikspork thinks its good to go. –droll[chat]22:23, 13 October 2010 (UTC)
OK! The reason the 2px are added is because the inner block adds a 1px border around the image in addition to the outer border. So the code in the sandbox is good and the change should be transparent. –droll[chat]23:35, 13 October 2010 (UTC)
I have noticed this a few days ago and this seems to be a bug which didn't occur before. Despite the default label position should be right, all dots that have longitude more than (approx) 30 degrees have caption on the left (see three most right dots on the example). I made an example with location map start template and multiple dots just to illustrate, but this is reproducable with single dot location map template too. -NineInchRuiner (talk) 10:05, 27 October 2010 (UTC)
In the default case the template is designed to move the label to the left if the marker is near the right side of the page. This is to avoid labels that run past the right side of the map. The position can be forced by setting position=right. I haven't looked at {{Location map start}} but the default behavior is probably the same as this template. –droll[chat]17:05, 27 October 2010 (UTC)
As I mentioned, this wasn't this way until a few days ago (ok, may be a little more) so it has to be some recent change. If it works like you said, than the criteria isn't clearly understood to me. It isn't starting at the middle at the map but rather smth like 1/4 from the right side, and it is not taking the caption length in the account. Clearly none of the labels on the example would run past the border. I believe that wikipeadians in general are smart enough to change caption position manually if needed. -NineInchRuiner (talk) 18:51, 27 October 2010 (UTC)
I did some more checking and {{Location map marker}} was modified on October 13 and October 14. The behavior of that template was synchronized with this one. I totally support the changes because the default cases are handled without errors. As I mentioned the label position can be forced by setting position=right. I took the liberty of modifying your example to demonstrate this alternative. –droll[chat]00:27, 28 October 2010 (UTC)
Hi, I'm quite excited to have used the various template:location map to place markers on maps. The next step for me would be to be able to connect these vertices / graph edges into routes, so that travelers routes, or lines can be overlaid onto these maps.
OK, I've worked up a nice and simple solution to this problem of route or path overlays. I've sandboxed it and I'm very happy with a first cut testing. I'll move on to cross-browser testing tomorrow. Can somebody with a LOT more experience with templates than me, give me some guidance on the following questions:
Should I cut a new template for my changes or roll them into Location map+ (I really don't want to fork unnecessarily, but I don't want to mess up anybody elses use of that template...)
Is there any sort of process for "approving" this template for use, or do I just throw it up and start dropping it on pages??
That sounds phantastic! Can you give an example, e.g. in your user space? If it's good there will be a lot of articles where we can use it and I'll start an PR campaign in ruwiki and dewiki for that project. --Obersachse (talk) 17:54, 25 November 2010 (UTC)
Add a classname to DIV-container
Hi, I want to suggest to add a specific classname to the maps div container (something like "locmap", "locationmap", ...). This would make the HTML more semantic and allows to hide the maps by user css. --Arch2all (talk) 09:37, 5 November 2010 (UTC)
Caspian Sea
Could anyone create a template location map for Caspian Sea? It is needed for the oil field infoboxes for the Caspian Sea oil fields articles. Thank you in advance. Beagel (talk) 19:58, 23 November 2010 (UTC)
At the FAC for Thistle, Utah, the request has been made to have the location map support an inset. The idea being that many people may not recognize a simple map of Utah, and it may be helpful to have an inset map that shows the USA with Utah highlighted. I asked around at a few venues, most people agree this should be an option, as this is likely to occur with several jurisdictions in the world, not just Utah. After digging in the template coding, it appears the easiest way to support inset maps would be by modifying this template. There is some precedent, Template:Infobox Indian jurisdiction does this. Anybody have objections, thoughts, etc? Dave (talk) 17:34, 5 January 2011 (UTC)
I think the way to go about this is to add an inset map parameter to the {{Location map foo}} pages (e.g., {{Location map USA Utah}}), then modify this template to use that parameter if it exists. I will try to code it up if I can find some time today, and if someone else doesn't do it first. Thanks for the great suggestion. Plastikspork―Œ(talk)02:04, 6 January 2011 (UTC)
I was debating between doing as you suggest (at the district level template), or having it at the Location map level (i.e. this template), with parameters for the inset map file and a location (upperleft, lowerright, etc.). I was planning to work on this. However, I've never attempted anything this complicated. As such, if you do want to take this on, I would more than welcome the help, but would appreciate to be kept in the loop for the learning. Dave (talk) 02:52, 6 January 2011 (UTC)
Okay, here is how I would see it working for say Utah. This template is called as {{Location map|Utah|lat= ...|long= ...}} This template then calls {{Location map USA Utah}} to get the name of the map image, the coordinates of the edges of the map, etc. This template then displays the image, overlays that image with an image of a pin in the correct location, overlays the image with the label text, adds the caption at the bottom, etc. Basically, adding an inset map is not fundamentally different than adding a pin. Hence, my proposal is to have this template then ask {{Location map USA Utah}} for the name of the inset image, if there is one. If so, it will then overlay that image on the map. It will also probably need to know the dimensions of that inset image. We could allow for {{Location map USA Utah}} to suggest a default location for the inset, but have the default be the upper left. We could have the inset automatically move to another corner if the pin is too close to the upper left. We will also want the user to be able to pass a parameter to this template to override the location of the inset as well. Can you see any problems here? Plastikspork―Œ(talk)03:23, 6 January 2011 (UTC)
In the case of Utah, it's pretty obvious that the inset map should go in the upper-right corner. However, for other jurisdictions it may be less so. How the Indian jurisdiction template does it is with a switch statement, based on the entry for the jurisdiction parameter, that selects the image file to be inset and the float coordinates. Dave (talk) 03:33, 6 January 2011 (UTC)
Okay, I have something that appears to work coded in the sandbox. It still needs some work, but the basic idea is there. The positioning is fairly straightforward, since you can use "top: 0px; left: 0px;" for upper left, "top: 0px; right: 0px;" for top right, ... However, the div also needs to know the width for top positioning, and the height for bottom positioning. The trick is that the location map can be resized as well. There might be a clever way to do this without knowing the dimensions of the inset image, and doing some calculations, but I haven't found one yet. Plastikspork―Œ(talk)03:22, 7 January 2011 (UTC)
Thanks for throwing that together. I'm still playing with my sandbox version also. In my sandbox, I'm trying to figure out the height of the base map by the fact that the map width is known (it's either specified or defaults to 240px) and then figuring out the image ratio from the co-ordinates of latitude and longitude for the extremes of the map (stored in Template:Location map <state name>). However, I've never messed with positioning of images before, so I'm still on the uphill side of the learning curve and having limited success with it. Tripping over rakes is how I learn the fastest, so I have no doubt I'll figure it out. Just need a few more profanity laced rants and more caffeine. =-) Dave (talk) 04:59, 7 January 2011 (UTC)
Okay, I got some help from RexxS who helped figured it out. The "top: 0px; right: 0px;" works if you simply omit the dimensions. See the comments on Jack Merridew's page. I am currently using NW for upper left, NE for upper right, SE for lower right, ..., but I am open to other suggestions. Plastikspork―Œ(talk)05:33, 7 January 2011 (UTC)
Here are some positioning tests
Thistleish
Thistleish (Utah)
Thistleish
Thistleish (Utah)
Thistleish
Thistleish (Utah)
Thistleish
Thistleish (Utah)
and width tests
Thistleish
Thistleish (Utah)
Thistleish
Thistleish (Utah)
Thistleish
Thistleish (Utah)
Thistleish
Thistleish (Utah)
Currently, I have the inset_map_width parameter as the percentage of the overall width. I suppose a better name would be "inset_map_width_percent" or something. But, it looks like the positioning works. Plastikspork―Œ(talk)05:43, 7 January 2011 (UTC)
I'm going to take the liberty of adding some comments to the sandbox code. This is if we decide to implement this change, it will be a little more readable. That was about half the problem that was preventing me from getting my attempt working, an improper reverse-engineering of the existing code that could have been avoided with better code comments. Dave (talk) 19:00, 7 January 2011 (UTC)
Great. I simplified it a bit more by creating a subtemplate which just does the pin/label placement. This cut down on some redundancy in the code, where the positioning was being computed more than one. I will admit it's still not the easiest to read. It took me awhile when I first started working on it. I may move some more stuff to subtemplates to try to make it a bit more readable, and add some more comments. I will see if I can get some more feedback as well, and try to implement the inset maps within the next couple days. Plastikspork―Œ(talk)05:33, 8 January 2011 (UTC)
Thanks for all your help in this, is the new template ready to be copied over from the sandbox, or do you think more tweaking is required. Dave (talk) 05:06, 10 January 2011 (UTC)
I think we are very close, but a few more minor points. (1) Do we need alternative text for the inset? (2) A method may be needed to turn off the inset map, perhaps if the one passes "inset_map = none" or something. (3) I am assuming we will have the inset map turned on by default, if the map is given in by the Location map template. (4) Do we need code to move the inset from its default location to a new location, if the pin is close to the corner with the inset? (4) Is the syntax for specifying the location of the inset what we want? I just want to make sure these issues are somewhat settled before a large scale roll out. I will ping a few other users. Plastikspork―Œ(talk)05:32, 10 January 2011 (UTC)
I will raise this on the New Zealand wikiproject talk page. Will it look good with long skinny countries like New Zealand, Japan, etc.? Kahuroa (talk) 08:02, 10 January 2011 (UTC)
I definitely agree that the Template Location map many, as proposed below, is an option. It would still require template changes to Infobox settlement to allow the change in sub-template. However, I do think what Plasticspork has coded in the sandbox is more elegant, namely as it will auto-place the inset in the corner, without the need of figuring out the co-ordinates and image sizes for any but the upper-right corner.
The point brought up below is a good one, for most states the shape leaves at least one corner where an inset should be placed, for about 4 or 5 there is no place to put an inset without obstructing the map. IMO, in those cases no inset should be used, and a 2nd map should be used if a context map for the location is required. Dave (talk) 17:29, 10 January 2011 (UTC)
As to the point of getting alt text working, this is trivially easy, my sandbox version has the alt text working, passed as a parameter stored in Template:Location Map <state name>.Dave (talk) 21:19, 10 January 2011 (UTC)
FYI, the immediate concern is over, as in the case of Thistle, I temporarily added a 2nd map to the infobox and the FAC has since closed. However, I still think this is a good idea. Given the most recent feedback in the sections below, here is what I propose as changes to plasticsporks attempt:
- Inset maps will not be automatic, must be invoked by a parameter (such as inset=yes or inset_map=filename)
- Documentation will state that inset maps are only available in some jurisdictions and are not practical for states that have a nearly perfectly rectangular outline (such as Colorado), where a 2nd map should be used.
- the defaults for the inset map to use and location can reside in Template:location map foo as proposed by plastikspork
Any objections? Using Plastiksporks test as a base, I can code these changes up myself, and I see this as low risk, as unless an article is changed to invoke an inset map, no inset map will be placed, no articles will be automatically changed. Please advise if there are still any concerns. Dave (talk) 01:23, 18 January 2011 (UTC)
Using Template:Location_map_many for inset images
Having special parameters for an inset map, can be a cumbersome special case, especially since, Template:Location_map_many solves the problem for the general case of several inset maps (or other images), overlaid onto a base map.
In the example above, note how the use of indentation helps to visually separate the parameters related to each of the 4 markers on the map. I would spend time optimizing {Location map many} to be very efficient, then emphasize how any inset map, or other overlaid image, is merely another marker placed on the map, with mark2size=50 or mark3size=80, etc.
Meanwhile, widely-used inset maps are best "hard-coded" into a general map image, rather than crank-up a complex template every time a page is reformatted. However, for less frequent pages, using {Location map many} seems to be quite rapid for placing the inset map, plus other large towns in Utah on the same map. The website city-data.com was awesome about showing town-among-major-cities to give readers a better idea which major towns are near the "Sundance Film Festival" or other sites on a map. It has been years since I worked with these mapper templates, but they should be optimized to be as efficient as possible: we want people to place 3 or 5 or 8 markers (or insets) on a map without fear of "slowing" an article. To remind others about displaying multiple inset images, perhaps we should add a special section to Template:Location_map/doc about using {Location map many}. They need to know how to add any combination of inset maps, landmark images, and numerous other towns onto a map image. -Wikid77 (talk) 08:08, 10 January 2011 (UTC)
This solution violates the license of the inset maps (and markers), if they are not PD, but CC-BY-SA. The page with the license must be only 1 click away... Uwe Dedering (talk) 20:15, 10 January 2011 (UTC)
In cases of multiple images, it is the writer's responsibility to link license details, such as by adding simple caption text "(inset map: details)" where common sense governs the method of reaching the license. However, new users might not realize the license issues, so those issues should be added to the doc-page text about using overlaid images. Thanks for noting that concern. -Wikid7701:06, 12 January 2011 (UTC)
It also requires manual coordinates and will break for even a 1px change in the dimensions of the inset map image. Case in point is the inset in the upper right corner is mis-positioned. My attempt at User:Moabdave/sandbox2 will also break for an image size change. That's why I like Plasticspork's version the best so far, automatically placed in the corner regardless of the relative sizes of the images. Dave (talk) 21:16, 10 January 2011 (UTC)
The pin-marker for each town or region marked on a map also requires manual coordinates in most cases, so the multiple inset maps at nearby coordinates are an easy extension of the first coordinates. On the other hand, when users ask for 2 inset maps (such as "Bavaria in Germany" and "Germany in Europe"), then the {Location map many} will handle all those concerns as well. -Wikid7701:06, 12 January 2011 (UTC)
Show inset map as outset with city seal
Because half of the U.S. states are "square" there is no room to show an inset United States map without overlaying part of a state. Look at just 12 24 of the crowded U.S. state maps below.
Iowa
Colorado
Wyoming
Kansas
North Dakota
Ohio
Connecticut
Montana
Arkansas
Oregon
South Dakota
New Mexico
Washington
Pennsylvania
Nebraska
Arizona
Alabama
Mississippi
Tennessee
Wisconsin
Missouri
Massachusetts
Illinois
Rhode Island
When a pin-marker for a town gets near the inset edge, then the inset map would have to in-your-face block another corner of the map. Instead, I would move the inset U.S.A. map as outset, perhaps alongside a state-flower image, or a town coat-of-arms seal:
Utah flower
Utah in USA
With an outset U.S.A. map, all 50 states would appear similar in format, while allowing space beside the outset map for an image such as a flower, city seal, town skyline (etc.) to add to an article, rather than subtract by obscuring the state's map with an annoying, overlaid U.S.A. map which could be shown nearby, instead. If 25 of the U.S. states were not "square" then having 25 special inset maps would not be the complex problem it is. Simplify: put the U.S.A. map nearby, but as outset not inset. -Wikid77 14:00, 10 January 2011, revised 01:06, 12 January 2011 (UTC)
A couple of thoughts. First, the situation is not as bad as described, nobody is forcing an inset where one would not be helpful. Second, "half the states are square" is an exaggeration. Even with the examples given above, insets will easily fit in the lower right corner of Connecticut, Arkansas, Ohio and Montana. In cases where it would truly be impossible to fit without clipping state boundaries, such as Colorado, Wyoming and the Dakotas, an inset map would probably not make sense, unless the inset had an location override parameter. I would prefer to have at least the option of doing this as an inset for two reasons 1- doing it as an outset can be done now with existing templates. 2nd- many infoboxes are big enough as it is, no point in making them even larger to support a 2nd map as a second image. IMO, weather the map should be inset or outset is a case by case situation. Dave (talk) 16:31, 10 January 2011 (UTC)
I am not saying that insets cannot be forced everywhere, but half of the U.S. states are indeed "square" (or rectangular), so the space around the state depends on the specific map borders: note how Tennessee (above) has been drawn in a taller map, 3x times the height of the state, but several other states are mapped closer to their square state lines. Connecticut is mainly square but drawn as a smaller central box in its map. The issue is re-drawing the states as a minor part of their maps to justify allowing an inset map to also fit inside the state map. On the flip side, we could have a large US map as the main focus, with each specific state as just a minor inset near Florida. That would be another way to use inset maps, but I don't see the need to put a small U.S.A. inset overlapping a state, when a tiny outset map would be fine beside some other small image. Instead, I think an infobox for location should allow a small regional, outset map to show the general area, as a more general solution, with click-on image for licensing, and no worries about trying to shove an inset map onto Iowa, Colorado, Wyoming, Kansas, North Dakota, Oregon, South Dakota, New Mexico, Washington, Pennsylvania, Nebraska, Arizona, etc. -Wikid7701:06, 12 January 2011 (UTC)
Noobish question
Hello all!
I would like to make location maps for other administrative divisions. The thing that I do not understand is where do you take the border and map center coordinates from. Can you give me a model (with an Open Street Map)?
Most of the maps I am familiar with were created using QGIS or another GIS software package. I am not aware of any that were made using Open Street Map, however, I'm sure it is possible. At WP:USRD/MTF (Wikiproject US Roads, Map Task Force), there is a tutorial on how to make a location map from GIS data, which is easily available for places in the United States. If you can find GIS data for your area of interest, that tutorial should still work. Dave (talk) 23:08, 12 January 2011 (UTC)
Northern England
Hull
Hull (Northern England)
Would someone please be able to make a template from this file: File:Northern_England_location_map.PNG ? Or at least tell me where I'm going wrong in trying to copy/paste file names and coordinates into existing example templates.
Wow, thanks very much! It's really helped stop all the team locations cluttering up the place like they did on the old England map. NPL Premier Division and NPL Division One North.
Float = center
I noticed someone else addressed this as well, but it was secondary to another problem, and the question was never addressed: Why doesn't float = center work as expected? If it's a CSS issue, you must know the "margin:3px auto" trick, which could be used to force the template to act the way most users would expect.
The lack of a centering option restricts the usefulness of this template in certain infoboxes and other circumstances. It would be nice to have this addressed. Wilford Nusser (talk) 12:00, 20 February 2011 (UTC)
I am using the very impressive Location Map+ to show ancient woodland sites in English counties, to accompany a list of the woods. Using the full names as labels rapidly becomes illegible, so I thought I could label them with a reference number and use alt= and link= to bring up a full name when you point at a dot. This works fine in ME8 but both Firefox and Chrome just repeat the label= number. You can see it at List_of_Ancient_Woods_in_England#Oxfordshire. Is this something that can be resolved? or is there a better way of mapping the information. (A further problem is that link= is needed to bring up the name, but not all the woods have pages to link to (as yet...). Is that an acceptable use of the feature?) Any help or suggestions would be very appreciated. Thanks, RobinLeicester (talk) 21:41, 20 April 2011 (UTC)
The problem is nothing to do with this template. Mainly, it's the way that different browsers interpret the alt= attribute of the <img /> tag when you mouseover the image. If you examine the page source you'll find code something like this:
<img alt="Ancient Woods in Oxfordshire" src="http://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Oxfordshire_UK_location_map.svg/250px-Oxfordshire_UK_location_map.svg.png" width="250" height="294" />
It's got four attributes (alt= src= width= height=), but crucially, no title= attribute. According to this page, the mouseover text should be taken from the title= attribute, not from the alt= attribute. Therefore, Firefox is being compliant in displaying nothing, whereas IE is non-compliant. The fix required here is a change to the MediaWiki software so that the title= attribute is set for the <img /> tag.
Alternatively, you could try raising a bugzilla ticket requesting that Firefox be brought in line with IE - but they'll probably reject your suggestion on the grounds that (as is so often the case) it's Mozilla who are following the W3C standards, and Microsoft who are bending them. You can't get Microsoft to fix anything, they just carry on their own sweet way ignoring the heck out of us users, whilst trying to think of new ways to make it worse for us. --Redrose64 (talk) 22:33, 20 April 2011 (UTC)
Alt text is really intended to aid the vision impaired. People have firmly held positions about how it should be used. You might look at Image map but it would involve a lot more work. –droll[chat]23:10, 20 April 2011 (UTC)
Lots of good suggestions, but a) it would be quite a loss if the page and its content can't be edited by non-specialist users. b) the elegant piped link solution, produces links on the text (rather than the dot) with lots of red links with the words 'page does not exist' added to the mouseover boxes. Looking further at my original problem, the Location Map+ section works correctly on all browsers (blank areas of map show the alt text). It is the Location Map~ entries, with the alt text to the red dot image that gets lost. (I would think that correct alt text would help both sighted and vision impaired readers, if it could work.) Thanks, RobinLeicester (talk) 23:31, 20 April 2011 (UTC)
White space
If you look at the left-justified location map here, you can see the text on the right is jammed against the map. Can location maps be made to default, as thumbnails do, to provide an appropriate amount of white space? --Epipelagic (talk) 08:02, 22 April 2011 (UTC)
It seems like a good idea but backward compatibility is always a concern. If I have time I'll check to see what problems a wider margin might create. Someone else will have to code it. –droll[chat]08:41, 22 April 2011 (UTC)
I've fixed this in the sandbox. The code now uses the image thumbnail classes if a caption is provided, so it should automatically get the right styling to sit properly next to text when floated (and otherwise looks just like an image thumbnail as well). The test cases page shows that the floating isn't exactly right, but it's much better than it was before. If there are no bugs I'll get this synced in a few days. Chris Cunningham (user:thumperward: not at work) - talk09:07, 22 April 2011 (UTC)
After a bit of looking around, I found that {{Bristol mapbox}} uses float right. I think it can be substituted. However my search was not exhaustive and there might be other places where a location map is in a table or div block that is going to be affected. I like the change but there might be some collateral damage. I have another idea I'm going to check into. I hope someone else can look at this. –droll[chat]20:21, 22 April 2011 (UTC)
Sorry, there were two Scotland sections on the testcases page. See Scotland2. So now there are three samples. In the second case, using the sandbox, the 1px margin disappeared. I think it has something to due with border being defined in the class and in a conditional but I'm not sure. Also, there is something wrong about the right margin. Good luck with this. –droll[chat]10:17, 23 April 2011 (UTC)
Ah, yes. It looks like the problem is that we can't manually specify class="thumbimage" in the image code, which is how images get a border. I've gone back to manually hacking in an inner border. The only remaining problem is that the margins don't exactly match that of image thumbnails, but I'm not sure we can do anything about that. Chris Cunningham (user:thumperward: not at work) - talk10:56, 23 April 2011 (UTC)
I think I can fix this but I'm going to have to fit the time to do it into other things. You have a great idea here. I'll work in my user space and get back here when I have something to show you. It might be a day or more. –droll[chat]02:03, 24 April 2011 (UTC)
I move a modified version into the sandbox. Although the code generated is does not exactly match that generated by a thumb image, the output is darn close. Basically, I moved the width def for the framed version into the div that uses case thumbinner. I also spend some time on code beatification but it's still a rat's nest. I think it's clean but I tend to miss stuff so please take a good look at it. –droll[chat]08:47, 24 April 2011 (UTC)
Wouldn't we be better just doing away with the composite templates? A look at the transclusions indicates that the only articles using them are a series of Football League season summaries which could presumably be migrated to {{location map many}} or the like. The next step would be to make {{location map many}} the master template and have this subclassed there instead. Chris Cunningham (user:thumperward: not at work) - talk10:54, 25 April 2011 (UTC)
I agree that currently the family of templates is not easy to maintain. Here is a list of templates I know of that have related functionality:
I think the easiest way forward is to modify Location map+ and then use it as a backend for the others and that it would be fairly strait forward to use it write Location map and Location map many as using Location map+ as a core template. I going to try this using sandboxes in my user area but I'm going need some time to do it. –droll[chat]21:54, 25 April 2011 (UTC)
I have an example using {{Location map+}} as a backend for {{Location map}} in my user space. You can see it here and the testcases here. It does not implement the modification we have been discussing. The links are to archived versions so please don't change them. –droll[chat]23:38, 25 April 2011 (UTC)
There is a new version of {{Location map+}} in that templates sandbox which implements all the changes Chris Cunningham and I have been working on. I am confident that it's ready for prime time. I also wrote a front end for this template and it is in this template's sandbox. Currently it transcludes the sandbox version of {{Location map+}} so it should not go live until after that template is updated. There are so many articles that transclude this template that I think it would be a good idea to implement {{Location map+}} and then see if any bugs show up. {{Location map many}} transcludes {{Location map+}} so articles that transclude it will also be affected by the change. I'm not going to request an edit on the location map+ discussion page as I think either Chris or Plastikspork ought to do it. P.S. I added 3px padding above the default caption. –droll[chat]01:08, 27 April 2011 (UTC)
The latest edit seems to cause problems with Internet Explorer 6. I have no problems at home with IE8 or Firefox 3.6, but at work I have no choice but to use IE6. (Don't tell me to upgrade my browser, that option is not available at my workplace.) What goes wrong in IE6 is that the spots are drawn too far south. It looks as though they are being plotted relative to the outer frame (i.e. including the text caption below the map) instead of the map. If I use a long, multi-line caption, the problem gets worse. This problem seems to have arisen only within the last few weeks and it affects only {{Location map+}}, not {{Location map}}. -- Dr Greg talk 00:38, 6 May 2011 (UTC)
I know this is probably a dumb question but did you have this problem with {{Location map+}} before the upgrade. –droll[chat]06:02, 6 May 2011 (UTC)
I don't have access to IE6 but I've been hacking anyway. I would appreciate it if you you could check and see of the version now in the sandbox works for you. There are test cases in my user space. Feel free to use that page. The Four Corners marker is a good test for accuracy. Thanks. –droll[chat]21:53, 6 May 2011 (UTC)
Not even Microsoft websites support IE6 anymore, so we can safely call it a former browser for all practical purposes. And good riddance. Zocky | picture popups20:32, 9 May 2011 (UTC)
Opera has the majority market share in several countries, IE6 doesn't. The development of Opera continues, and its long-term trend is stable. Meanwhile, IE6 has been out of date for 10 years, and has lost half its market share in the last 6 months and is expected to fall under 1% in the next 6 months. And crucially, Opera is largely standard-compliant and doesn't require special handling, like IE6 does.
I worked on Template:Location map Europe2 and it should work now. You might still have a problem fitting all the captions. I used the (currently undocumented) position parameter to move Kronberg to above the marker. The documentation for this template is not that great. If you need more help just ask. –droll[chat]23:10, 8 May 2011 (UTC)
I've looked everywhere, and the only place I can find similar code is our Nodyn:Location map/marker. Can someone offer some help? Thank you. -- Xxglennxx (talk • cont.) 01:08, 24 May 2011 (UTC)
Is there a way we (someone) can make a more concentrated version of the Colombia and Buenos Aires maps. I think they cover too much of the surrounding geography and could work better if they were more narrowly focused. Thanks. Digirami (talk) 21:30, 31 May 2011 (UTC)
Think it would be nice if the default is not any float, but the map breaking in the text. This is useful for cases where the map is large and squeezes the text, especially on smaller screens. JMK (talk) 09:28, 22 June 2011 (UTC)
I think Chris Cunningham's fix at Location map+ will solve the problem but I'd like to go slow. I going to see if I can check for any problems with unexpected output.
JMK, I guess you mean using using "float:none" as the default. I think we are, sort of bound by what has become expected behavior. I think there has been an attempt to mirror the behavior of image files. Consistency is important here, IMHO. –droll[chat]15:13, 22 June 2011 (UTC)
Indeed. Changing the default at this point isn't an option. Too many existing transclusions rely on a certain default (i.e. right). I haven't exhaustively tested the fix I put in place but it is logically correct and seems to work where I need it to (testcases and in the {{location map}} sandbox). Chris Cunningham (user:thumperward) - talk15:23, 22 June 2011 (UTC)
I've done fairly good check of the articles and templates that transclude Location map+, and I fixed a few things. There was nothing really bad. So, I think, the modification of that templates is OK. I looked for any other differences in default behavior and did not find anything of significance. –droll[chat]23:14, 22 June 2011 (UTC)
Did you chec {{location map}}, which now trancludes this? It was {{location map}}'s omission of a default float which brought this bug to light in the first place. And if it comes down to either having to modify {{location map}} or keeping the default as it is, I'd rather the default were kept as it is, simply because people are used to it. Chris Cunningham (user:thumperward) - talk12:41, 25 June 2011 (UTC)
Everything seems to be fine. The float is to the right, by default, as it has been, for and Location map. I believe it is the way we want it to be. Files (thumbs) have the same default float. Everything is good it seems to me. What might need to be modified? –droll[chat]14:37, 25 June 2011 (UTC)
Once things settle down a bit, I'd like to talk about some minor modifications.
I think error handling could be improved. The obscure default error messages generated by the parsing functions are inadequate.
I also think the markup should be more readable so that it will be easier to maintain.
The position of labels gets messed up if large marks are used. I think their position should be relative to the size of the mark.
Of course the documentation needs to be updated to reflect the options that Location map+ has that Location map did not have. I'll work on these one at a time unless others would care to take on a task. Are there tweaks that others would like to see? –droll[chat]15:25, 25 June 2011 (UTC)
Bug fix
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Can the documentation be updated to indicate how this new parameter is used exactly? It appears you set it to 1 to use the relief map? How does one associate a relief map with the location map template if there isn't one currently set up? RedWolf (talk) 17:07, 30 June 2011 (UTC)
Setting any value for the "relief" parameter (at least in {{Infobox protected area}}) will result in the use of the relief map. In order to utilize a carefully created relief map (that already matches the coordinates of the existing map), all you need to do is add the file under an "image1" parameter in the location map template. See this diff for an example. – VisionHolder « talk »19:29, 30 June 2011 (UTC)
I'll get to the documentation as soon as I can. In general there are three methods that can be used to display a relief map.
Use the AlternativeMap parameter to specify any image that has the same geological edge coordinates and projection as the the default image used by the map template.
Assign any value to the relief parameter if the map template shows an alternate map image below the default image.
Sometimes another template exists that uses a relief map. See {{Location map USA2}} and {{Location map USA relief}}. Using the first template with relief=yes displays the same map as the second.
Your second question more difficult and I tried to come up with something but I do not know enough to formulate a general answer. The major problem is finding a map image that has the same geological edge coordinates and projection as the the default image. You might ask at Wikipedia:WikiProject Maps. –droll[chat]20:25, 30 June 2011 (UTC)
Locations clickable to access geohack mapping
Apologies if this an old chestnut, but I have searched for information without success. It would be useful, at the List of castles in England page, to have each location on a map clickable to access geohack mapping facilities. All that would be necessary is to have the small location image linked to the required href, in the same way that the whole map image is currently linked to the map source page. Is this facility available, has it been requested, if not can it please be implemented? Paravane (talk) 17:51, 17 July 2011 (UTC)
If I'm not mistaken, at {{Location map+}} the link is only to a wiki page, a similar facility but it would be useful to be able to link instead to geohack, and it could be done via the location image spot. It might also be helpful if it could be done by opening a new browser window, to avoid leaving the wiki page. Paravane (talk) 19:19, 17 July 2011 (UTC)
{{Location map+ |Berkshire
|width=300 |float=right |AlternativeMap = Berkshire UK district map (blank).svg |caption=Castles of Berkshire
| places =
{{Location map~ |Berkshire |lat=51.483889 |long=-0.604444|label='''Windsor''' |position=bottom |mark=Green pog.svg
|link=http://toolserver.org/~geohack/geohack.php?pagename=Windsor_Castle¶ms=51_29_02_N_0_36_16_W_type:landmark}}
}}
This works for Windsor. I strip the others for simplicity. I do not recommend the use of {{Location map start}} because it currently receives little support. P.S. I got the URL by going to the Windsor Castle page and clinking on the coordinates link. I have a another idea and if it works I'll get back to you on your talk page. –droll[chat]20:15, 17 July 2011 (UTC)
Just the job! If the link could be generated automatically by the location map templates, for the given coordinates, that would make life easier for the editor! In that case the template could perhaps be assigned a parameter, clickable=yes/no. I wonder also about an option to suppress the link to the map source, that would make the geohack link more noticeable, and avoid the need to look where you're going before you click. Paravane (talk) 20:57, 17 July 2011 (UTC)
The edge coordinates used by {{Location map Scotland mainland}} are way off. I'm not an expert at this but I try to fix it. –droll[chat]18:45, 22 July 2011 (UTC)
I gave a good go but the map seems to be distorted. I put a warning message on the template. In my humble opinion it is not worth any more time. –droll[chat]20:06, 22 July 2011 (UTC)
Fix for mobile version
Hi. In mobile view there is a bug in German Wikipedia's copy of "Location map". As you can see here, the horizontal position of the marker is wrong, as it varies with browser window width. The English version works just fine.
The red dots on the maps for Cheetham Close and Rivington services are in the wrong place, but when clicking of the coordinates and selecting one of the maps at GeoHack they are in the correct place. Could someone please look into the problem and fix it. Thanks HLE (talk) 18:25, 4 August 2011 (UTC)
Using Firefox, they look good to me too. It might be your web browser. If you see a problem, it would be interesting to know what browser and version you use. –droll[chat]19:55, 4 August 2011 (UTC)
This seems to be exactly the same problem that I reported earlier on this page at #Problem in IE6. I am getting the same symptoms (when I use my employer's archaic IE6) with Cheetham Close and Rivington services, just like the symptoms I reported in May. But I don't get the symptoms with {{Infobox UK place}}, which I believe does not make use of Location map's caption but supplies its own caption (outside of Location map). The good news for me is that my employer's IT department has announced an upgrade from IE6. The bad news is that the rollout has been postponed due to compatibility issues. -- Dr Greg talk 20:08, 5 August 2011 (UTC)
Probably link it back to Google maps to satisfy their terms of use and you are all set.
Of course if Google goes down so do you, but they wouldn't be so rude as to do that. Jidanni (talk) 22:53, 20 August 2011 (UTC)
That's what their images are there for, to be hotlinked to. Provided you also make the image itself a link back to Google Maps, as their Terms of Service intends. Which in fact would also be a convenience to the user, compared to what happens if they are so unfortunate as to click on your current images... the just end up seeing the image file, without the red dot. "Great". Jidanni (talk) 23:47, 20 August 2011 (UTC)
(h) No Use of Static Maps API(s) outside a Web-Based Application (Except with a Link to Google Maps). You must not use the Static Maps API(s) outside of a web-based application unless...
So maybe you can even hotlink them... but why when you can just link them to the corresponding maps.google.com link the user would expect... There, I recommend http://mapki.com/wiki/Google_Map_Parameters to get you started. In particular the q=loc: would allow you to fashion a link to maps.google.com that looks almost identical to the red pin on the static map... Jidanni (talk) 00:35, 21 August 2011 (UTC)
How about because they are not free? ro.wp and de.wp already gave up the static maps in favor of OSM, which is free and quite good in most countries (certainly better than the static maps). If you want to test it, just go to the German and Romanian interwiki from Bucharest and click on "Karte" and the globe, respectively. You should see a very nice map with related articles on top.--Strainu (talk) 00:56, 21 August 2011 (UTC)
I personally always trust OSM, since people I know and trust have designed/imported most of the map of Romania :) I can assure that for areas covered only by Google mapper (the crowdsource service which somewhat resembles wp) and not by Google itself, OSM coverage is comparable if not better.
But the main argument for OSM is still it's licence (CCBYSA, but moving to ODBL nowadays). It's bad enough the Foundation gave up the free software excusivity, we should not do the same--Strainu (talk) 17:11, 21 August 2011 (UTC)
CSS
Also the red dot (now a pushpin) would finally stay on the map even in when viewed devices without CSS. Where currently your maps all lose their red dots. Jidanni (talk) 23:47, 20 August 2011 (UTC)
That's right, tons of placenames on the map for free too.
Why reinvent the wheel? Sure it is corporate lock-in... but doesn't
Google just love Wikipedia too? Save your duplicated effort for
something ... that at least looks as good.
(Yes, I recommend still hardwiring the coordinates into the markers= instead of relying on the luck of the name match.) Jidanni (talk) 00:03, 21 August 2011 (UTC)
Oops, there go the aforementioned tons of placenames. Errg... Yuck. Well, its all about choice. You be the judge.
So I do believe we have a deal. Sign on the dotted line.......☻ Jidanni (talk) 00:21, 21 August 2011 (UTC)
One major complication: Wikipedia is a free resource, Google maps isn't. I'm not even sure if we could hotlink Google maps without at all without violating copyright (static images from Google maps are routinely deleted as copyright violations). Content on Wikipedia has to be available under a free license, not least because of consequences for downstream users.
We could integrate other maps such as that produced by {{coord}}, but that isn't there yet IMO. I don't think the quality is good enough yet.--Nilfanion (talk) 00:24, 21 August 2011 (UTC)
Nah, I put Google's TOS above. Now all you have to do is tell Google that if they don't give you a free license, you'll be featuring them in your robots.txt ! That ought to teach 'em. Now all that is left is for you to hijack the innards of this template to point to Google... Jidanni (talk) 00:41, 21 August 2011 (UTC)
Not doable, I'm afraid. Google won't be releasing their content under a free license (not least because its not entirely theirs, but their partners such as Tele Atlas) any time soon. And their current TOS doesn't allow usage by Wikipedia - pretty much every part of section 10 is an unacceptable restriction for us. We can link to their content, and possibly make it easier for our users to get there (by eliminating choice: taking them straight to Google, instead of giving them the choice of Google, Bing, Openstreetmap etc). We cannot hotlink their content.--Nilfanion (talk) 00:46, 21 August 2011 (UTC)
Now how am I going to get out of here and save face at the same time? Ah, a preference... allow the user to set a preference for Google maps in his Preferences, then we haul in the Google maps as I proposed above. Of course we should give him a mind numbing plethora of those other inferior map choice checkboxes to choose from so it is clear that he was the one who picked Google maps, not us. And of course we should include the current original flavor (I like the little map) choice too. Of course I could be wrong, however my time is up.Jidanni (talk) 01:08, 21 August 2011 (UTC)
The reason that it's not being used doesn't have to do a lot with Google's Terms as Use as much as with our own (Wikimedia Foundation) Privacy Policy. Hotlinking to a third-party service violates that policy by sending data about the readers to Google without their consent. Krinkle (talk) 20:46, 24 August 2011 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I believe that on the Location Map included in the article, the locations of where Alan Canfora and William Schoeder were shot have been switched: I believe that Canfora was relatively close to the National Guard and was wounded in the hand; Schroeder was shot at a great distance and killed. If the Location Map cannot be edited, perhaps a note could be added to the text noting the discrepancy.
Which article would that be? At a guess I would say that an incorrect latitude and/or longitude has been used, and if so, it should be a case if making a simple edit to the article concerned. This is the discussion page for improvements to the general {{location map}} template, and does not deal with specifics. --Redrose64 (talk) 20:54, 4 September 2011 (UTC)
Disabling link to file page
I've seen a few comments that when readers click on the map, they (reasonably) expect it to link to a higher resolution version of the locator map. Instead, they end up with version of the underlying blank map - which isn't what they expect, and is entirely useless for that reader. The ideal behaviour would be for it to give what the reader expects, but that is probably hard to do.
However, disabling the link entirely (by use of link=, as {{flag}} does) should be easy to do. Some benefits include removal of the link to an "irrelevant" file and also in cases where the label has a defined link, it means if the reader misses the label, they won't get the wrong link. The biggest complication is that this might break the file's attribution path. Thoughts?--Nilfanion (talk) 00:45, 5 September 2011 (UTC)
Disabling the default link to the image description page is problematic. Many images, including images of maps, are not in the public domain. For example the image used by {{Location map USA}} is licensed under both the the Creative CommonsAttribution-Share Alike 3.0 Unported license (CC BY-SA 3.0) and the GNU Free Documentation License (GFDL). Its my understanding that the link to the image description page satisfies the attribution requirement of the CC BY-SA 3.0 license, and the requirement that of the text of the GFDL be included with licensed document. I'm not an expert on this, so I might be wrong. One way around this is to include a link to the description page by using something like in the map to the left. The , at the bottom left of a thumbnail image, serves the same purpose. P.S. Images commonly used as a mark, such as , are in the public domain. –droll[chat]04:24, 5 September 2011 (UTC)
Yep, that's about my understanding of the situation too - some sort of link being required for copyright purposes. I do think it would be helpful be to present that file link in a different way - for instance tagging it onto the map's caption. That makes links from the locator dot/link more practical as it removes the risk of the user missing it and getting the wrong thing.
As {{location map}} is called by other templates, that would mean {{location map}} itself would have to allow a no-link image, and editors would then have to add the alternative link on a subtemplate. If a was used in the corner, there would need to be a parameter to specify which corner, for those cases where insets could be obscured.--Nilfanion (talk) 23:20, 5 September 2011 (UTC)
I'm, sorry, my original request was probably not clear. The "Map workshop" where you link to is the place where I would request creation of the map. The map already exists, but I would like it to be able to be used in {{Location map}}. --EdgeNavidad (Talk · Contribs) 17:18, 27 September 2011 (UTC)
So do you want to request the creation of a location map template? I don't know a special place for such requests. So let's discuss your request right here. If I should create a template for you I would ask about the purpose of the template, the existence of a map, do you know the coordinates of the map borders (geographic limits of the map) and the kind of the projection. The mor answers you can give the easier it is to create such a location map template. --Obersachse (talk) 19:15, 27 September 2011 (UTC)
the purpose of the template: the first use is to show the playing locations during the 1934 FIFA World Cup. The article now uses a map of current Italy, but the borders are wrong. As I said before, it also suits articles about Italy between 1919 and 1947, for example Serie A articles for that time.
coordinates of the map borders (geographic limits of the map): The user that made the map did not indicate this...
the kind of the projection: Equirectangular, I'm 99.9% confident, but the user did also not indicate this.
I understand that the map borders coordinates are important. Would it be possible to use 35.3°-47.4° N, 6.2°-19.0° E as a first approximation, and show me where these numbers are, such that I can do the finetuning myself?
In the examples given, a certain USA map is called / sourced by {{Location+|USA2..., but how does one know that name beforehand? It may have been USA3 for all I know. Where does one see the name? - as the file name happens to be "File:Usa edcp relief location map.png". JMK (talk) 19:33, 15 November 2011 (UTC)
Thanks, that is what I wanted to know. But what about File:Guernsey location map.svg. Can it be used as a pushpin map, and which name should be used? Not a country, so I'm stuck again. JMK (talk) 20:19, 15 November 2011 (UTC)
And could someone perhaps prepare an Alaskan location map with the islands and peninsulas excluded? That would be useful as one can focus on the mainland, with a more useful scale. JMK (talk) 19:49, 15 November 2011 (UTC)
Ugh, that map is awful. Could someone make a new one entirely (something like this), now that this template supports polar coordinates? The skew on that map is so ridiculous, it makes my state almost unrecognizable. No opinion on whether the Aleutians should be cropped (not totally unreasonable considering how huge they are, but I'm leaning towards no). Calliopejen1 (talk) 20:15, 15 November 2011 (UTC)
regional and provincial maps of Italy
I have begun to create regional maps of Italy to illustrate the Italian Army unit disposition over the last fifty years. The first template I created is for the province of South Tyrol: Template:Location map South Tyrol relief. However when I tried to create a map+ map for the Alpine Brigade Tridentina I get the following error message: Alpine Brigade Tridentina#unit dispositions 1989. Could someone please point out the error to me? I can't find it! Also I would like to create maps for the Italian regions: namely relief maps for each of the following:
Veneto & Friuli-Venezia Giulia regions
Trentino and South Tyrol region
Piedmont, Liguria, Lombardy and Aosta region
Emilia Romagna region
Tuscany, Umbria, Marche regions
Lazio, Abruzzo, Molise regions
Campania, Apulia, Calabria, Basilicata regions
a map of Northern Italy (from around the Southern tip of Tuscany up to Austria)
a map of Central Italy (from around Bologna south to Naples, with Rome in the maps center)
a map of Southern Italy from Rome southwards (with only some part of Sicily)
Maps for Sicily and Sardinia already exits. Can anyone help? What's the best way to create this maps. Thanks in advance for any help, noclador (talk) 09:22, 18 November 2011 (UTC)
label width
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
For whatever reason, a person might want to increase label width but not increase label font size. Right now, the only way to increase the width of the label is to change the font of the label (the width is a static 6em's). Open up the source, search for: width: 6em; (emphasis added -- it only occurs once) and change that to width: {{{label_width|6}}}em; (emphasis added). Then add something in the documentation about a label width value and that it should be given as a straight number but that it'll be parsed in em rather than px, so as to scale with an increased font size if the font is changed by a screen reader. Banaticus (talk) 04:27, 26 November 2011 (UTC)
Can someone please help me find the correct border coordinates for this map: Location map Northern Italy relief? I have been trying for an hour to figure out how to find the correct border coordinates, but whatever I tried the result (when adding cities like: Verona, Turin, Udine, etc.) was that they were either to far in the East, to high in the North, off to the right or off the map!. If anyone has the ability to figure out the coordinates - please be so kind add them to the template. Thanks very much in advance!!! noclador (talk) 08:39, 28 November 2011 (UTC)
The location map templates assume an equirectangular projection - which means lines of latitude evenly spaced horizontally and lines of longitude evenly spaced vertically. But the map description at File:Northern Italy topographic map-blank.png states that it is using a "Lambert conformal conic projection". A template would need very complicated formulas to know where to position overlay points (such as the formulas at {{Location map USA2}}). So, unless someone can work out what formulas would be needed, or recreate the map with an equirectangular projection, your map which will not be accurate as a location map. — Richardguk (talk) 12:48, 30 November 2011 (UTC)
:-( oh, thanks for the answer! that explains while some points are wide of the mark, while others almost on the correct spot,... I did not know about the projection and just took a relief map of Italy. Thanks a lot for the help Richardguk. noclador (talk) 15:06, 30 November 2011 (UTC)
.svg)
