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.
I tried it in IE 8, Firefox 11.0 and Opera 11.11 and Chrome 17.0.963.79 portable. The label text is displayed as the tool tip in these four browsers. I don't believe there is any way to change that behavior using wiki markup. Richardguk is correct that the link from the marker is to Rayyis –droll[chat]03:13, 18 March 2012 (UTC)
this seems to be a bug, as the temp page says that the link=x value will say x on mouseover. can the coding be changed to fix this bug?--Misconceptions2 (talk) 05:05, 18 March 2012 (UTC)
One problem is that mouseover text varies between browsers. What you see when using Firefox will not be the same as that seen in Internet Explorer. --Redrose64 (talk) 17:03, 18 March 2012 (UTC)
Map templates in two series
Hello. I saw, that there are map templates in an other series too: the location templates of {{geobox}}. Why exist such duplicates of the map templates from {{Location map}}? I tested code in the Esperanto Wikipedia, that make it possible to use the map templates of Location map only. Do you like to test it here, too? Greetings --Tlustulimu (talk) 15:11, 22 March 2012 (UTC)
Location map of Buenos Aires
Dear co-wikipedians!
After this edit you should consider making a revert or reparing dozens of pages that use this template (or maybe install two different location maps). Before this edit, the map showed the Greater Buenos Aires region, now it just shows the official territory of the Argentine capital (Autonomous City of Buenos Aires). Using the template as it is right now for places that are some 60 km (40 miles) away (La Plata Airport for example) does not look good ;)
This could be another option. There is the Autonomous City, there is the Metropolitan Area (Greater Buenos Aires) and there is the (huge) province of the same name. I do not want to decide how the current errors should be solved, however, I wanted to point to them so they get solved somehow. For some articles I would say that the Greater Buenos Aires map is the most helpful, but not for all, of course. → «« Man77 »»11:36, 21 April 2012 (UTC)
Suppressing alt text for the marker
I've been working on improving the accessibility of {{Infobox UK feature}} which uses File:Red pog.svg as a marker. I've been able to suppress the link and alt text where it is defined in {{Infobox UK feature}}, but this template is fully-protected and is called from {{Infobox UK feature}} where it is used to put a marker on a location map. The problem which remains is that the marker on the location map produces an alt text equal to "{{{alt}}}", which is undesirable for multiple reasons.
It seems that this template uses a passed value of 'alt' in two places:
line 4 where it passes an alt parameter to {{location map+}} like this:
| alt = {{{alt|}}}
line 20 where it passes an alt parameter to {{Location map~}} like this:
| alt = {{{alt}}}
Obviously the same named passed value is not correct for both, and the second assignment seems to me to go wrong when 'alt' is not defined.
The effect is easily seen if you have 'Web Developer Toolbar' addon installed in Firefox; look at the first example (Yellowstone) in the documentation for this template, and you'll see that the map marker has an alt attribute of "{{{alt}}}".
I think that the second parameter needs to be renamed to something like 'mark_alt' and use the {{{mark_alt|}}} syntax to pass an empty value if undefined. Unfortunately, I can't test this out here and my attempts to sandbox it in my userspace needed too many transclusions to be renamed for me to get my head around. So if anybody has any bright ideas on how to get rid of the "{{{alt}}}" alt text, I'd be most grateful. --RexxS (talk) 16:15, 4 May 2012 (UTC)
I'm not an admin but I've worked on this template before. I'll write up what I think the markup should be and then you can see if it does what you want. Clearly the current situation is not good. It might take a day or so. –droll[chat]
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I would find it useful if there is an option that allows a border even though no caption is used. Is this feasible? Having a map without a border looks unfinished and there is insufficient padding making the result look rather "ugly". -- Alan Liefting (talk - contribs) 01:49, 18 April 2012 (UTC)
I agree and I have a revision in mind. See {{location mark}} that I wrote the markup for some time ago. Its not a very popular template but I think it has some good features that I would like to see impediment here. The problem is that it would take a major migration. I need to think on it some more. For the time being just using some caption might be better than nothing. –droll[chat]02:55, 18 April 2012 (UTC)
Thanks; but I realise now that I missed an adjacent error: the closing attribute quote on the following line needs to be moved inside the previous #if block line (i.e. moved from line 18 to line 16).
The locations are west of the Greenwich meridian, so you either need to make the longitude negative or add |lon_dir=W. Assuming that the coordinates are correct in other respects, I've edited the article to add |lon_dir=W and |lat_dir=N to both of the {{Location map~}} transclusions. The markers now display on the map. — Richardguk (talk) 05:38, 16 May 2012 (UTC)
"This template uses a helper template"
I first took this to mean that the template *calls* its helper template. Perhaps this would be better as "This template is used with a helper template". --92.27.34.75 (talk) 15:17, 30 May 2012 (UTC)
location map many - markers being cropped
From the talk page for Template_talk:Location_map_many it seems that we should raise issues with that template here. I think this is a really useful set of templates but there's a couple of things that I don't think work quite right.
I think markers are being cut off at the bottom or sides. I don't get this effect if I make the pog bigger and I'm not sure what's going on. Adding a frame to the top map made the effect go from the right side to the bottom. I'm using the current Firefox on OSX.
In the two maps below - in the top one Baranavichy is missing the right side of its pog, as is Irkutsk, and in the bottom one Gabala is missing its pog bottom.
Text for markers is cropped at the map edges if I have a caption as captions bring frames. Can text overlay frames? I don't have room for all my labels! Secretlondon (talk) 05:18, 21 June 2012 (UTC)
When using location map+ and location map~ with the label position as left or right, sometimes the label text appears to overlap the markers. See the example on the right.
This can be fixed by using a label_x parameter for {{location map~}}.
Sorry for the late response. Can you please put the required code on /sandbox and then test it thoroughly and reactivate the request? — Martin (MSGJ · talk) 18:22, 27 June 2012 (UTC)
Smaller default width for vertical maps
Would it be a good idea to add an optional defaultwidth parameter for each {{Location map country}} which has a rather tall vertical layout, so that a default width smaller than 240 may be specified in {{Location map+}}? It's really inconvenient to have to manually change the map width for every locality in Chile, Finland, Thailand, etc. Take a look at Mathiveri (Alif Alif Atoll) for an extreme case where this is a problem.
I'm not familiar with these templates, and haven't tested this yet—please check and make any necessary corrections. --Paul_012 (talk) 12:29, 28 June 2012 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
There was a spurious <table> tag at the end of the Location map template text. I've removed that and fixed some of the other formatting, though the text in the air bases table is still a bit wide to fit within the screen width. Does it look acceptable now? — Richardguk (talk) 01:23, 8 September 2012 (UTC)
thank you very much for your help Richardguk!! There is even more text in the German version of the table (I copied and translated it from there), but to me it now looks fine :-), cheers and many thanks again. noclador (talk) 02:31, 8 September 2012 (UTC)
Edit request on 9 September 2012
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The location of Marycrest College is Davenport, Iowa, not Toledo, Ohio. Please make this correction. Thank you.
so, the {{location map+}} template depends uses {{{label}}}, which is not documented. the reason for this is probably that when {{location map}} was refactored into a weak frontend, this was a way to preserve the logic of the old {{location map}}. I think we should move the logic for the {{{label}}} parameter out of {{location map+}} and into {{location map}}. I will try to code something soon. does anyone see a problem with this? Frietjes (talk) 15:12, 31 October 2012 (UTC)
Add default_width to allow calling templates to specify width without overriding map-specific values
As a follow-up to #Smaller default width for vertical maps above, many templates which transclude {{Location map}} currently specify a different width from the default 240 used by this template. I propose to add another parameter, default_width, to be passed from the calling template to {{Location map+}}. This would allow templates such as {{Infobox settlement}} to request a uniform width without overriding the value for each individual map added in the last edit. My suggested edit is to replace
The use of width remains unchanged, and may be specified by the final call, overriding any default value. If width is not specified, defaultwidth (intended for tall maps) is pulled from the individual map template if it exists, and if not, default_width, which is passed from the calling template, is used.
I'm wondering if this is the right approach. when a location map reports a default width of say 150, it really means that it should be 63% of the default width. it's almost like we want a default scale parameter, which would scale the defaults by a percentage. a template like say {{infobox settlement}}, could set this scale factor to 1.04, and whenever a defaultwidth is used, it is scaled by this factor. Frietjes (talk) 15:08, 31 October 2012 (UTC)
The defaultwidth parameter isn't really used yet, so changing the modifying value for vertical maps to a percentage should be rather simple. The same could be done for template defaults such as in Infobox settlement, though it may be rather unintuitive to use a relative rather than absolute value. The width parameter would still need to be retained as an absolute value for compatibility, though. What do you suggest? --Paul_012 (talk) 17:38, 31 October 2012 (UTC)
how many of the location map "map templates" have been modified to add the "defaultwidth" option? if it's not too late to go back, I would say we change those to "defaultscale", and simply multiply instead, when a value of "width" is not set. clearly we need to keep the absolute width parameter, as you indicated. Frietjes (talk) 18:02, 31 October 2012 (UTC)
Not too late, since I've only added it to Thailand and the Maldives for testing. I've changed the sandbox to use defaultscale per your suggestion.[3] It now specifies the width as:
I think a separate width parameter is still needed to differentiate between end-user values which shouldn't be modified and default values e.g. the 250px used Infobox settlement which will need to be multiplied with defaultscale. It's still named default_width but if someone suggests a better name that can be changed. --Paul_012 (talk) 12:05, 1 November 2012 (UTC)
I think the ordering of the expressions should be flipped a bit to the following
if I got it right, this would use the value of "width" if it is specified, if not then multiplies 240 by either {{Location map {{{1}}}|defaultscale}} or 1, depending on if {{Location map {{{1}}}|defaultscale}} is defined. we would then change templates like {{infobox settlement}} to pass |default_width=250. does this look correct? Frietjes (talk) 18:48, 1 November 2012 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Done, plus I made some fixes and improvements. First, I made a new subtemplate to house the width-generating code, as it was getting quite complicated and it is called five times by {{Location map+}}. The subtemplate is at {{Location map+/width}}. Second, I fixed a couple of potentially serious bugs. The first bug made the template throw out an error if the first parameter of Location map {{Location map+}} wasn't a valid template, or if the template was malformatted in some way. The second made the template shrink to the default thumbnail size if the number generated from the defaultscale wasn't a whole number of pixels. I've fixed this by making the subtemplate round the result of default_width*defaultscale to the nearest whole number. The resulting code has worked in all my tests so far, so I went ahead and implemented it. However, this is quite a complex series of templates, so I recommend going slowly when rolling out the new code to the various daughter templates and articles in case there are any issues. Regards — Mr. Stradivarius(have a chat)14:01, 4 November 2012 (UTC)
I have created Template:Location map Bantayan exactly using the model of Belgium, Padang, Spain etc. But I can't get thhe parameters to work. In fact only one parameter - marksize - even shows on the page. I have included these parameters:
marksize
marker
float
default_width
But nothing works. I can specify pushpin_mapwidth in its invocation, and that works. It also seems that the pushpin size and text are actually reduced from normal.
I would really like the width available as a percentage (of client window) rather than a fixed width. And I would like to change font color because it's not very obvious on my map, or maybe that's just because it's so small. Johnmperry (talk) 07:41, 13 November 2012 (UTC)
Well it's not documented. And it doesn't seem to me like Location map Bantayan is working properly - for a start off, the only parameter displayed (below the map) is marksize. None of the parameters work, for instance I wanted a yellow pushpin. :Are you saying I can prefix with pushpin_ (all) location map parameters within the infobox:settlement invocation? Or just offer style changes within available parameters, using curly braces?
{{Location map}} calls the {{Location map~}} subtemplate with |label_size={{{label_size|}}}. So, if label_size is not specified when calling the main template, it is passed by default as a zero-length string. But this overrides the intended default of "90" in {{Location map~}}.
Consequently, instead of outputting the styling as "font-size:90%;", the templates combine to output "font-size: %;" (because a parameter passed to a subtemplate with a zero-length string is not treated like a missing parameter, so there is only a space before the percentage sign instead of "90"; HTML Tidy then converts the invalid space to the HTML decimal numeric entity for a non-breaking space).
This error is reproduced in all the samples on the documentation page (except for the second Rimini example, where the default label_size percentage is explicitly set to 150, as expected).
The simple solution would be to edit {{Location map~}} to replace:
Map with label_size at 90% (new default since 2 Jan 2013)
Although the intended default for label_size was 90 since {{Location map~}} was created in 2007, the actual default for the affected location maps has been 100 due to the bug described above. Therefore, location maps which have displayed the label with a font-size of 100% for years just started displaying it at 90% a few days ago, when the prior edit request was implemented. The difference is quite noticeable and that was what led me here to see what had changed in the template. I request that this be fixed by making that the default label_size 100.
Not done: I wouldn't be averse to making this change, but it's hard to say which font size is "right" in this situation. I think we need to open this request to wider discussion to find out which size would be better. Maybe you could notify relevant WikiProjects and/or start an RfC? Best — Mr. Stradivarius(have a chat)16:14, 5 January 2013 (UTC)
Personally, I would oppose changing the size to 100%, for the following reasons:
enwiki is a relatively mature wiki, so most important articles using the location map template probably first did so prior to June 2011. In other words, the "100%" error period is a relatively short time compared to the overall lifetime of the template.
Larger-than-expected text is more likely to cause problems than smaller-than-expected text, because larger text can overlap or spill into the margins.
Legibility at 90% should not be an issue, because the captions have always been at 90% (as shown in both the above examples). Though small text should be avoided to prevent articles from becoming inaccessible, 90% is within the range of accepted sizes, and location maps generally include visual mapping detail that presumes at least a moderate level of visual acuity (the size will not affect screenreaders).
The increase to 100% was never intentional and therefore did not reflect any previous demand for such a change or the outcome of any discussion.
More subjectively, I think the larger label text looks a little uglier, looming slightly larger than the caption text and other sidebar elements.
I agree with Richardguk, and would support reducing the default to 88%, since this is the default size for {{infobox}} and related templates. there is a reason for the 88% in that it is the next smaller size from 100% that is universally recognized by browsers. many browsers round 90% up to 100%, but 88% is always smaller. Frietjes (talk) 17:37, 6 January 2013 (UTC)
'Real' source?
I would like the real source for this template; it is broken on the Arabic Wikipedia (in two ways that I have noticed - firstly it doesn't acknowledge places 'west' of Greenwich, secondly it only reads degrees and completely ignored minutes and seconds). If you could copy the original code into the Arabic page via the interwiki link, I would be very grateful. --عبد المؤمن (talk) 16:41, 22 January 2013 (UTC)
These errors were not present a few months ago. Their effect is visible on the documentation page itself; Algiers is in the wrong place! --عبد المؤمن (talk) 16:42, 22 January 2013 (UTC)
An anonymous editor posted on the talk page of Istanbul that the location map in the infobox shows the city in the wrong page. I requested that he post a screenshot, since it is showing up in the correct place for me and he did. This is what he sees. For comparison, this is where it's supposed to be (and that is what I see). Might anyone have any insight into the issue? -- tariqabjotu18:48, 30 March 2013 (UTC)
from the discussion on that talk page, it appears to be Windows 8, Firefox 19.0.2. I don't have windows 8, yet, but I will see if I see the same thing on any other OS/browser combinations. Frietjes (talk) 15:57, 31 March 2013 (UTC)
Link to geohack
Hello! When we use this template, isn't there any option where the coordinates can be shown as text inline and at title? Like how Template:Coord does it. That way there is also a link to geohack where the location from google maps, wikimapia and such can be reached. §§Dharmadhyaksha§§ {T/C} 06:49, 3 April 2013 (UTC)
which article? normally this sort of thing is embedded in the infobox, which takes care of displaying the coordinates in the title. Frietjes (talk) 18:03, 3 April 2013 (UTC)
I was trying it on Cotton Green railway station which uses the Template:Infobox station. It has a field of coordinates. (It actually doesnt have. It just asks us to use Template:Coord over there. Which is not really helpful but fairly adjustable.) But it doesn't have any field of showing the location on a map. Hence i was wondering if the coordinates can be made visible through this template also as an option. I know that it's not always needed to show the coordinates when this template is used, for example in a larger article where the location is not the subject itself or where more than one locations are shown. §§Dharmadhyaksha§§ {T/C} 03:40, 4 April 2013 (UTC)
Someone has just changed the image_map on Bantayan, Cebu. However this is wider than previous, so the infobox becomes wider too. The parameter 'mapsize' doesn't seem to have any effect. I'm sure I went round this loop in November before giving up. Has anything changed, am I doing something wrong, etc etc? John of Cromer in Philippines (talk) mytime= Fri 11:23, wikitime= 03:23, 5 April 2013 (UTC)
I think the idea is to use short abbreviations for each label, then explain each abbreviation in the caption. for example replace |label=Barrington Court with |label=1, then put (1) Barrington Court in the caption. another idea would be to replace |label=Barrington Court with |label={{abbr|1|Barrington Court}}, which would allow you to hover over the 1 and see Barrington Court under your mouse (try hovering over the 1 here). Frietjes (talk) 19:33, 22 April 2013 (UTC)
There appears to be an error in the code which causes double line-feeds to push map symbols south, as described on the below map label. Benjamin Trovato (talk) 11:00, 24 April 2013 (UTC)
Errors: A. Moscow should be north in the circular Moscow Oblast; B. Blank at bottom of map. Clues: 1. Removing line=dummy solves the problem. 2. Removing blank lines 2,4 or 6 raises, removing all 3 fixes. 3. Duplicating the 7 blank lines pushes down. 4. Adding blank lines with the enter key pushes down, so its the line-feed character, not an embedded hidden character, but 5. Adding blank lines below 'dummy' has no effect unless a second 'dummy' line is added below them. 6. Ukraine location map~ has the same problem, so it is probably the code for all loc maps.
I don't think this is fixable, without adding some complicated string parser functions to strip out the blank lines. the wikimedia software is going to turn those blank lines into br tags, and the {{location map+}} template is going to parse those as if they were intentional. Frietjes (talk) 16:13, 24 April 2013 (UTC)
1. I have never heard of a language where blank lines in the source changed the output. Few people would expect it and it took me about 3 hours to find. 2. The error is hard to spot unless the location should line up with a shoreline or other landmark. I deliberately chose Moscow because the circular oblast makes it obvious. 3. Why should linefeeds cause the location to move or make a blank at the bottom? Looks like a bug to me. 4. I don't see anything in the syntax that would need to recognize a break/line feed. Seems like the parser should ignore them (although I have put <*/br> inside caption= which is useful). What does the parser do with line feeds? Seems like you could convert "}}br" to "}}" in all, but of corse I don't know your code.Benjamin Trovato (talk) 21:31, 24 April 2013 (UTC)
What are <*/br> and }}br intended to be? These are neither HTML nor Wikicode. A forced linebreak is <br /> in XHTML and HTML4+, or <br> in HTML (but not XHTML). --Redrose64 (talk) 21:39, 24 April 2013 (UTC)
welcome to Wikipedia where blank lines are actually functional and are turned into <p><br></p>. as for other languages where whitespace is functional there is forced indentation of Fortran 77, and less useful languages like whitespace. that said, it is possible we could do something about stripping out the whitespace, but it would definitely have some cost. Frietjes (talk) 22:31, 24 April 2013 (UTC)
Since I don't know the language my opinion may not be worth much, but: I don't see why anyone would want to move a locator symbol below its indicated lat/long and make a blank space at the bottom of the map. Is this a bug or feature? I think few people would guess that a blank line would change anything. If this bug or feature should not be removed it should probably be documented on the template discription. Otherwise it will continue to cause trouble. Benjamin Trovato (talk) 23:13, 25 April 2013 (UTC)
Fix for Location map+/width
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
please change the code for {{location map+/width}} to use this version of the sandbox or this version of the sandbox, which will allow |width= to be either purely numeric, or have px units. note that I have supplied two possible fixes, depending on if you want to call the lua module directly.
Hi, an editor posted at WP:EAR about Sorpe Dam, which uses this template via {{infobox dam}}. The editor has noted that the dot on the map appears to be in the incorrect location, but that the coordinates are correct. Checking mapping sites for the coordinates verifies that they are correct, but indeed, the dot appears to be somewhat too far west on our map. I don't see any problems in how the infobox implements this template, nor in how the article implements the infobox. I'm not sure where else the problem could be, however. —/Mendaliv/2¢/Δ's/ 22:10, 23 May 2013 (UTC)
That did fix it and thank you. I thought that the template used the value in the name parameter, but I guess that's not how it works, since I created a redirect for the Benton County, Washington template when I set it up many months ago. - MrX17:28, 25 July 2013 (UTC)
Found the problem. I was using '-' (dash) not '~' (tilde). At the size of the edit text scrunched up against 'map', or in the preformatted text in the documentation, they are hard to distinguish, and dash seems more natural. Surprised it worked at all and didn't give me an error.--JohnBlackburnewordsdeeds22:15, 2 September 2013 (UTC)
Former countries' maps
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please revert and discuss, it is better to have overflowing text than hidden text. If the problem is solely due to the map pushpin label overflowing the right-hand edge of the map, the solution is simple - reposition the label. In the case of pages using {{infobox UK place}}, such as Oxted, you would do this. --Redrose64 (talk) 10:52, 2 December 2013 (UTC)
It's anyway a bad idea to have relatively positioned block elements floating around the page, as those can cause strange rendering issues. Setting overflow:hidden on the container gets rid of those. I would first like to see a concrete example where this causes any issues, other than making editors aware that there are labels in the location map that should be maybe aligned differently. --hydrox (talk) 22:06, 2 December 2013 (UTC)
No, I've not disappeared. I've already indicated that the problem may be overcome using existing methods - the |label_position= parameter; you yourself have used them. I'm waiting for other people to demonstrate that overflow:hidden; is a good idea, per WP:BRD and WP:CON. --Redrose64 (talk) 17:40, 5 December 2013 (UTC)
Well, there can not be consensus for introducing something entirely novel (there are zero hits in this page's archives for "overflow"). And people will not know to come discuss here if there's nothing broken. But I am okay with holding this change at least until I am next time annoyed by randomly appearing scroll bars in the page. --hydrox (talk) 18:01, 5 December 2013 (UTC)
It looks to me like the real problem isn't this template, but {{Infobox UK place}}. That template specifies a default |label_position=right if one isn't explicitly specified, when really it shouldn't specify a default at all and allow this template to supply its own default. I believe this template automatically puts labels on the east side of the map on the left instead of the right, if not overridden. -- Dr Greg talk 19:21, 5 December 2013 (UTC)
Note to all page-watchers. This template has been converted to Lua, and so its code can no longer be understood. I shall therefore cease offering assistance in the use of this template, and will unwatch this page: consequently, my comment "I've not disappeared" of 17:40, 5 December 2013 no longer holds true. --Redrose64 (talk) 21:17, 13 March 2014 (UTC)
As the original author of the horrible wiki code, I must say that this lua rewrite hasn't improved it. 400 lines of code for a simple pushpin map seems quite bloated, and the produced HTML is now impossible to edit for a non-programmer. I haven't done any lua programming on mediawiki yet, so I'm not sure how feasible this is, buu IMHO, it would make much more sense if only the projection calculations were farmed out to lua, and the html was still produced by a (hopefully more readable) wiki template. Zocky | picture popups01:57, 2 May 2014 (UTC)
The reason that isn't feasible is performance. Parsing wikitext is a lot slower than running Lua, and it sends the post-expand include size through the roof. There's several pages right now that would fail to parse if any of the work were done in wikitext, because they would exceed the allowable limits for parsing. Jackmcbarn (talk) 02:18, 2 May 2014 (UTC)
Can anyone help with creating a location map for the Southeast of the United States. I've been trying to find a map of the Southeast US and have been unable to. The map would include: Washington DC, Virginia, West Virginia, Kentucky, Arkansas, Tennessee, North Carolina, South Carolina, Georgia, Florida, Alabama, Mississippi and Louisiana. It can include parts of other states obviously but the idea would be for it to be about the bottom quarter of the normal USA Location Map. I've tried creating one but have failed. Thanks. Mak888 (talk) 02:57, 12 January 2014 (UTC)
I wasn't sure if that would make it more difficult since you wouldn't have the original dimensions. If you took literally split the USA location map in 4 parts and took the bottom right hand corner that should work or be close, may needs to be a little farther north. I only have paint on my computer so can't do much. Mak888 (talk) 22:18, 14 January 2014 (UTC)
if you can have someone help you make cropped versions of the two maps in Template:Location map USA and upload them, I can relatively easily make the new location map. whoever crops the images should keep track of exactly how many pixels were cropped off each side of the image. I can do it, but I will need to install inkscape to do it properly. you might be able to find someone to help you faster at Wikipedia talk:Graphics Lab/Map workshop. Frietjes (talk) 14:24, 7 February 2014 (UTC)