Misplaced Pages

Template talk:Infobox lighthouse: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editNext edit →Content deleted Content addedVisualWikitext
Revision as of 20:49, 29 October 2018 editCabayi (talk | contribs)Edit filter managers, Autopatrolled, Checkusers, Oversighters, Administrators142,282 edits Template-protected edit request on 29 October 2018: r← Previous edit Revision as of 02:19, 30 October 2018 edit undoLowercase sigmabot III (talk | contribs)Bots, Template editors2,305,781 editsm Archiving 5 discussion(s) to Template talk:Infobox lighthouse/Archive 1) (botNext edit →
Line 11: Line 11:
}} }}
{{Archives |age=730}} {{Archives |age=730}}

== Merged ==
This template's history was merged with a very similar one. Edits from 8 January 2006 by Rport are from that duplicate, and I've encorporated those elements into the older one. -- ] ] 07:40, 14 January 2006 (UTC)

==Possible Modification==
I modified the template to include thumb instead of 250px. I also included ]. See the example code here:]. See sample implementation here:], compare with ] and let me know what you think. I'd like to incorporate the changes to this infobox. If the thumb portion doesn't look right, then how about the Geolink section? --] 04:07, 15 January 2006 (UTC)

:Looks good to me. ]<sup>]</sup> 04:09, 15 January 2006 (UTC)

Using a "template within a template" is a practice that should be ]. Copy the code from the Geolinks template directly into this template, if that is desirable. Personally, I think you should have just one link, to the kvaleberg.com site, because it looks too cluttered. As for the image, I don't like the thumb fram around the image. Are you using that just to limit the vertical size of the image? -- ] ] 04:55, 15 January 2006 (UTC)

: OK, I was unaware of the template within a template rule, I've updated my version with the code from the Geolinks template. I was inspired by the ] and I thought that since this infobox already has lat and long info in the infobox, why not add a link to some images like topos and aerial photos. As for the number of links, some times an area doesn't have all types of imagery available so having only one line might exclude some areas. I thought it would save the effort of adding the geolinks template to the external links section of each lighthouse. As for the thumb issue, yes I was trying to limit the height. I'm open to other suggestions. --] 05:37, 15 January 2006 (UTC)

:: I made another attempt, using ] as inspiration. I replaced Lat and long with Coordinates and a single link to the kvaleberg.com site. I still don't know what to do about the image height, but I would like to implement the coordinate part of it. --] 15:02, 15 January 2006 (UTC)

::: Unfortunately, the hemispheres and location of the link is hard-coded for the US only. Perhaps you can use the {{] ] 18:36, 15 January 2006 (UTC)

:::: I'd like to maintain the usage of latitude and longitude so that all the other pages that use this template will not be greatly affected. I thought of the hemisphere issue, but I wasn't sure what percentage of lighthouses linking this template would be west hem vs east hem. I assumed, probably incorrectly, that most of the lighthouses linking the template would be in the west hem. I was planning to add lat and longs from USCG light lists, so the ones I enter will all be west hem. Is it better to keep the lat long or change all the rest linking here to 'coor d' or 'coor dms'? --] 19:57, 15 January 2006 (UTC)

::::: "coor dms" is a good choice. I'm not a fan of how the decimal coordinates look. -- ] ] 03:31, 16 January 2006 (UTC)

Since there were no negative comments, I decided to implement the changes to the template. I've added the coordinante and characteristic elements. I think those are important for the lighthouse infobox. I also added a sample coor dms to the top of the talk page. I hope I'm not stepping on any toes here, we're supposed to 'Be Bold' right?. --] 02:45, 16 January 2006 (UTC)


Why is there no field for the engineer responsible?--] 19:30, 12 August 2006 (UTC)


== USCG Light lists number==
To uniquely identify lighthouses in the United States, would it make sense to add another row with the number? --- ] 15:16, 26 August 2006 (UTC)
:Added USCG number to infobox. ] (]) 23:22, 11 September 2008 (UTC)

== Year Built and Current lens ==
Quite often, especially for older lighthouses, the year it was first lit may be quite different from when it was first built. Also, the current lens may be very different from the original lens. I have added both the fields to the template. --- ] 00:40, 29 August 2006 (UTC)

== Markings ==
I have added a field for markings/pattern --- ] 23:51, 30 September 2006 (UTC)

==Tower height vs. Focal height==
After noticing discrepancies amongst the ], I suggest that the "Height" input be broken up into "Focal Height" and "Tower Height" to represent the height at which the lens is situated and the total height of the entire structure, respectively. --<b><span style="color:#00A86B;">]</span></b> (<small>] • ] • ]</small>) 22:20, 14 August 2007 (UTC)

:Well, looking at the NPS website on the Cape Hatteras Light, they claim that the tower is 193 ft. tall ''from the ground to the top of the lantern''. Looking at the various USCG lists of lights, they do not in general say which figure they are reporting. I think it's going to be hard to make this distinction, frankly. ] 00:37, 15 August 2007 (UTC)
:I agree, for completeness we should be listing both. While some lights are located on the beach and the difference is minor, many lights are located on a high bluff and the differences between the numbers can be major.] 14:51, 15 August 2007 (UTC)
::This is a completeness that cannot be achieved. I recently went over every article for lighthouses in Maryland (and wrote half of them myself). In most cases the only "height" I could find was in the USCG list, and they do not in general specify which number they're giving. The lighthousefriends articles are scattershot, and de Gast never gives that datum. I think we're better off just giving a "height" and trying to resolve inconsistencies as best we can (and in the case of Hatteras, trying to give both numbers doesn't appear to do that). ] 14:06, 16 August 2007 (UTC)
:::In many of the Michigan lighthouse articles I have been working on, we have access to tower height and focal plane. I started putting the focal plane info under "elevation" but I would prefer that the infobox say "Focal Height" and "Tower Height". Also, there seems to be a problem using the template within an article not specifically about the lighthouse. The infobox takes on the name of the article, which is not accurate. As an example, see ] and ]----] (]) 04:55, 23 May 2008 (UTC)
::::Not much activity here.] (]) 05:01, 10 June 2008 (UTC)
I noticed that the designations for "Height" and "Focal Plane" have been changed. That is fine, and an improvement. Although I still think that "tower height" might be more exact for the former. I have seen editors put in the elevation (above sea level), and there is the problem of where do you start the measurement (the base of the tower, not the base of the foundation, etc.) and where do you end it (the tip of the ventilator ball). FWIW, in the Michigan lighthouse articles that I have worked on, we have previously put into the infobox "foscal plane" and "tower". See, e.g., ]. My observation is that "height" is to some extent ambiguous. Focal height is measured from the mean high water mark to the center of the lens. A good discussion is available at Terry Pepper Seeing the Light.
A problem is that changing these templates effectively messes with existing articles, and they will now all have to be changed. ] (]) 19:39, 29 October 2008 (UTC) Stan
:For backwards compatibility the template should contain both fields as accepted variables; but only document the use of the prefered term. FYI: The from using "elevation" to instead use "focalheight" was only made in the template, not in the documentation for the template, which causes even more confusion. --- ] <small>(] • ])</small> - 19:49, 29 October 2008 (UTC)
Barek: I'm confused. My detractors might say 'easily confused.' I could not make ] work, for example. ] (]) 19:54, 29 October 2008 (UTC) Stan
:I updated the article; I'll also update the documentation for the template. And, for backwards compatibility, I'll re-enable the "elevation" field - so that field should be removed if you add the "focalheight" field. --- ] <small>(] • ])</small> - 20:14, 29 October 2008 (UTC)
::Thank you. ] (]) 20:20, 29 October 2008 (UTC) Stan

==Request for Locator Map Support==
It would be nice if this template supported locator maps that would place the dot based on the coordinates. Thanks! ] (]) 09:16, 18 November 2007 (UTC)

== Registry numbers ==

I count several registry numbers for lighthouses that should be accomodated in the template, namely:
* ARLHS
* NF (Norwegian specific; like US NGA and other national registers)
* Admiralty numbers

Unless there are objections, within the next few days I'll add ARLHS and Admiralty - which appear to be international - as optional; and then a separate field or two for national registry numbers. --] (]) 20:37, 12 December 2007 (UTC)
:Personally, I would rather see a generic "Registry numbers" or similarly named fields ... when filling in the template, it could show both the registry type and the number, adding a <nowiki><br/></nowiki> to list multiple ones (if applicable). --15:49, 10 June 2008 (UTC)

::Another useful field could be "ownership", to help differentiate between publicly owned and privately owned lights - for privately owned, the same field could show the owning foundation or business. --- ] <small>(] • ])</small> - 16:38, 10 June 2008 (UTC)

=={{{name}}}==
Can't someone include an optional naming/titling function for the box? Especially with disambiguation pages like "Blahblah Island (lighthouse)" you'll get those nasty brackets into the title bar. ] (]) 00:23, 20 July 2008 (UTC)

:I was going to do if for you, but it turns out it already exists, but was undocumented - see ] for an example. ] (]) 03:27, 20 July 2008 (UTC)

::I have gone though, and I think I haver fixed up all articles with brackets in them. ] (]) 04:04, 20 July 2008 (UTC)
:::Now if we could just change "elevation" to "focal height".....] (]) 05:21, 20 July 2008 (UTC)

:::Excellent. Thank you. ] (]) 10:28, 20 July 2008 (UTC)

== Fog signal ==
I added a row for fog signals. It should be interesting for offshore facilities. ] (]) 10:28, 20 July 2008 (UTC)
:On the Michigan lights, I have been putting it under characteristic. See e.g., ]. ] (]) 19:59, 12 September 2008 (UTC) Stan
::Yeah, but "Characteristic" links to ], hence my new row and wikilink. ] (]) 20:47, 12 September 2008 (UTC)
:::OK. You are right. I'll try it. It worked! See ]] (]) 21:01, 12 September 2008 (UTC) Stan
::::What about ]? See ]. ] (]) 23:22, 12 September 2008 (UTC) Stan

== Name Field Problem ==

While adding a number of stubs for Maine, I noticed a problem in the name field. If I attach a ref tag there, it makes the field too high in IE6 (it's OK in Firefox), conflicting with the next item in the list (see ]). This is true whether there is an image or not. Is there an easy way to make the field taller or should we just work around?

I should add that in most cases I put the ref tag or tags at the bottom of the infobox (see ]), but where the light no longer exists that's a problem -- I delete the four registry number fields because there can't be any, but leave the descriptive fields blank in case someone in the future is moved to fill in more of them than I can. The ref tag at the end then causes the Fog Signal field to show, even though it's blank. So I've been attaching the ref tag to the date built, but that's not completely satisfactory because the ref usually covers all the fields in the box (see ]).... ] (]) 21:44, 7 August 2009 (UTC)

==A great resource==
Historical Coast Guard light Lists, many books that are new to me, etc. Worth the look. An article on how to preserve a lighthouse.
] (]) 12:49, 8 August 2009 (UTC) Stan

== Should "Admiralty" be ]? ==

We link each of ], ], and ], but not Admiralty. Unless there's objection, I'm going to change the 4th from the last line in the output to ] number:
Jim . . . . ] (] • ]) 13:19, 7 September 2009 (UTC)

Seeing no comment, I've done it. I've also added Canada. Jim . . . . ] (] • ]) 13:39, 10 September 2009 (UTC)

== New map ==

The new map is great, thank you very much. However, I'd like to eliminate the name from the map or at least make it optional, and at least have the option to have a red pushpin rather than the lighthouse icon.

My reason is simple -- 75% of USA lighthouses are NRHP and will therefore have an NRHP infobox. When that's the case, I, at least, will put the image in the lighthouse box and the map in the NRHP infobox -- I think that looks better. Therefore, I'd like the maps in the non-NRHP lighthouses to have the same look as the NRHP ones. Thanks, . . . . <strong>Jim</strong> . . . . ] (] • ]) 16:35, 14 December 2009 (UTC)

: Thanks for the feedback. I too noticed the redundancy with the NRHP box. I will make some adjustments. ] ] 16:54, 14 December 2009 (UTC)
:: Okay, I have updated the template and the code. The default is now the standard red pin with no label. The lighthouse pin can be enabled using the <code>pushpin = lighthouse</code> option. Other options are listed in the doc. Thanks! ] ] 17:51, 14 December 2009 (UTC)

:::That's quick, many thanks. It looks good at ]. May I suggest you post a summary of all the changes you made to the template here, with a note at ]? Thanks again, . . . . <strong>Jim</strong> . . . . ] (] • ]) 22:27, 14 December 2009 (UTC)

I tried the lighthouse pin and it turned out that the icon is put centered onto the exact location in the map. I think it would look much less confusing and would be more precise if the lighthouse would "stand" on the location, i.e. its baseline being put on the coordinates, not the centre. This might be achieved by coding a standard offset into the lat parameter when using this pin or simply by using a shifted icon file. ] (]) 19:19, 1 May 2010 (UTC)

: Interesting. I think a shifted icon file would be the best solution, since we want something that is robust to rescaling. ] ] 19:30, 1 May 2010 (UTC)

:: Okay, how is that? ] ] 19:46, 1 May 2010 (UTC)

:::That works great now. Thanks a lot :) ] (]) 22:43, 1 May 2010 (UTC)

===Need some smaller scale maps===
I tried out a Virginia light and discovered that the dot is pretty useless, since the scale of the map is so large. Can we get smaller scale maps of some areas (e.g. VA portion of the bay)? ] (]) 22:32, 1 May 2010 (UTC)
:I think this should better be asked on the talk page of {{t|Location map}} since that template is nested in our infobox. ] (]) 22:50, 1 May 2010 (UTC)

== Small Bug ==

If you have two lighthouse infoboxes in the same article and call out
*coordinates_display =title,inline ''in the first infobox''
*coordinates_display =inline ''in the second infbox''
then both sets of coords display in the title, on top of each other.

There's an easy work around, just use:
*coordinates_display =title,inline
*coordinates_display =

. . . . <strong>Jim</strong> . . . . ] (] • ]) 18:50, 26 December 2009 (UTC)

: I agree that "inline" should mean "inline" and not title. I will see if there is an easy work around. Thanks! ] ] 22:56, 30 December 2009 (UTC)
:: Okay, it should now work with coordinates_display = inline. Thanks! ] ] 23:03, 30 December 2009 (UTC)
:::Yes. Tested at ], where I noticed the problem. It's now fine, thanks. . . . . <strong>Jim</strong> . . . . ] (] • ]) 23:40, 30 December 2009 (UTC)

== Coordinates: decimal vs. DMS ==

Can the map be made to work with decimal lat/long? Right now it only works with DMS. ] (]) 03:05, 2 May 2010 (UTC)
:Use latd= and longd= with decimals but without the min and sec and direction NS/EW parameters. Southern latitudes and western longitudes are denoted by a negative sign, i.e. latd=-45.5 would be 45.5°S. ] (]) 18:02, 2 May 2010 (UTC)

== References field ==

Since some valid concerns have been raised about usage of references for the entire infobox, and the cost to amend this was minimal, I added a references field, as used in many other infoboxes (e.g. {{tl|Infobox mineral}}). For example, see ]. This is not mandatory, and one can still tag every single field if necessary. In fact, if a source is relevant to only one field one SHOULD tag it. --] (]) 06:09, 21 July 2010 (UTC)
:I don't think we need that at all. General references should be placed in the article's section as a bullet list, there's no need to create footnotes in an infobox. ] (]) 13:24, 21 July 2010 (UTC)
::I'm not sure we need it, but I think you misunderstand -- it doesn't create a new place for a reflist, just a place to collect the references used throughout the infobox -- compare ], without the Reference line, to ], with it. . . <strong>Jim</strong> - ] (] • ]) 14:09, 21 July 2010 (UTC)
::: What Jim said. I think one case in which it is crucial is if one uses the same source for all items in the infobox, but does not have an ARLHS number. Compare ] and (funny name that light has), and also note that one of the facts is from a different source so I tagged it separately. Anyway, it isn't a must, but in some cases I think it looks better, so I see no harm. It is also not unprecedented, and used in several cases where it is common to use one reference for the entire box. If you still oppose I'll revert. --] (]) 16:36, 21 July 2010 (UTC)
::::I didn't think it would create a new refliust. But my problem with all that is that footnotes have generally become overrated imho. For an infobox that is just a mere factsheet I think it is totally sufficient to put the references in a bullet list outside the infobox, we don't need to source everything inline. And I think the box at ] looks quite strange with a "References" line and the second ref just above that. I'm sure sooner or later someone would think it needs cleaning up and move the extra ref down "where it belongs". On another note to avoid more confusion, I'd say we should use "characteristic" in the box only for active lights, not for retired ones like Reading. ] (]) 19:51, 21 July 2010 (UTC)
:::::I don't really have a position one way or the other on the reference question. I do, however, on the characteristic -- if the light is clearly shown as inactive, why not show its former characteristic, particularly as at ] which showed a Morse "A", common on buoys but not lighthouses? Where we know it we often show the historical characteristics of lights, which gives a pattern to their change over the years.. . <strong>Jim</strong> - ] (] • ]) 22:42, 21 July 2010 (UTC)
::::: As 'the new guy' I'm not the one to say if reference tags belong in the infobox at all or not, which seems to be what De728631 argument is about (though I do have a clear opinion on that). This is not the issue I added this field for. The issue is that ''if'' one decides to use references, as many editors do, there is no good place for it. The previous solution was to put a <nowiki><br></nowiki> or a newline on the last data point, followed by a list of references. This, IMHO, is not a good way to do it, so I added the references field for it. As this is clearly a problem with all infoboxes I looked around and the solutions I see are either tag everything, or add a field. --] (]) 07:34, 22 July 2010 (UTC)
::::::My problem with a "References" parameter in an infobox is that the infobox should be representative of the entire article. So if we put a list of References in the infobox only for the refs used in the box, we leave out the rest of the article, so to speak. So if you really need to source facts in the box, why not do it the traditional way with a footnote that appears in the main References section? I find it disturbing rather than helpful to have an "extra" References in the box. ] (]) 10:34, 22 July 2010 (UTC)

::::::I've now removed the References parameter from the template and also edited the Israel lighthouses accordingly. As I said, I don't see any need at all for a separate "References" entry in the infobox. General references of the box can go directly into the article's section without footnotes. ] (]) 12:17, 22 July 2010 (UTC)

::::::: I guess you do feel strongly about this. Thanks for taking care of my pages. --] (]) 18:53, 22 July 2010 (UTC)

== Other number ==

What do you think about adding another number? Many countries have their own numbering systems. It can work with two fields. "additional_number" and "additional_number_type". For example "additional_number=0986", "<nowiki>additional_number_type=Netherlands<ref>{{Cite web
|url= http://www.vuurtorens.net/
|title=Vuurtorens in Nederland
|work=vuurtorens.net
|accessdate=11 August 2010
}}</ref>".</nowiki>--] (]) 09:53, 11 August 2010 (UTC)

:Good idea, but I would have it a two-variable parameter:
::| Countrynumber = 12345
::| Country = Netherlands
:Which would display as:
::'''Netherlands''' = 12345
. . <strong>Jim</strong> - ] (] • ]) 10:58, 11 August 2010 (UTC)
:: Yup, that was the idea, sorry if I wasn't clear. --] (]) 12:47, 11 August 2010 (UTC)

{{done}} I also added "countrylink" to enable linking to the list. --] (]) 13:12, 13 August 2010 (UTC)

== Light characteristic standardization ==

I noticed some of us use shorthand to list the light characteristic, while others use prose. I propose we standardize on the shorthand to save space. Interested parties probably know what it means, and otherwise can follow the link. --] (]) 10:31, 2 September 2010 (UTC)

:Could you cite some examples? ] (]) 18:39, 2 September 2010 (UTC)

::See ]. Examples, just on the two articles I created, ] uses "Fl.(2+1) W. 20s." A bit shorter than "group of two flashes, then one flash, white, cycle 20 seconds". ] on the other hand uses "green light, occulting every 3s", where I'd prefer "Oc. G. 3s". The reason I myself use both is that I usually don't start with nothing so I continue with what was there before. I propose to standardize on the shorthand when used in the template, as people in the area know what it is about, and we supply a link to ] very near for those who don't. --] (]) 21:33, 2 September 2010 (UTC)
:::I don't have a prefernce. However. . .
:::Whatever you decide to do, I think that there should be appropriate wiki links for ] and Flashing]] (or to their abbreviated equivalent), so that the terms are explicated somewhere. We are writing article that can be accessed by readers of varied expertise, and should take this into account and try to make it at lest accessible to users with the lowest common denominator of expertise. ] (]) 23:56, 2 September 2010 (UTC) Stan
::::That's why such things should always be explained in full prose in the text. The infobox shall provide a quick-look overview on facts and statistics. It's surely good practice to link the abbreviations too, but a light characteristic should not be restricted to the infobox in the first place. After all one point why we write about lighthouses is to explain how their light works. But I'm all for using abbreviations for the characteristic in the box; it saves space and introduces the reader to nautical customs. I suggest writing it out in the text with additional abbreviations in parentheses and then repeat the abbreviated characteristic in the box. ] (]) 20:57, 3 September 2010 (UTC)

:::::I agree that abbreviated is better. Note that the USCG Light List does not use periods -- it would be "Oc G 3s" -- I propose we use the USCG Light List description for US lights. For non-US lights, use the local light list abbreviations, if it is referenced, otherwise the USCG abbreviations. Note that we have used the NIMA light list for a number of foreign lights -- in my case, because it is on line and the Admiralty Light List, for example, is not. The NIMA system is different -- "Oc. G. period 3s", which I propose we do not use. . . <strong>Jim</strong> - ] (] • ]) 22:06, 3 September 2010 (UTC)

Since there seems to be a consensus about using shorthand, I added a note to the documentation. I don't feel strongly about the exact format, as long as it's clear what was meant. Personally, as I use ''List of Lights'' almost exclusively, I use their format, dropping "period" which is quite redundant. If/when I find the time I'll start going over the infoboxes and move then to shorthand. --] (]) 18:21, 4 September 2010 (UTC)

== Change in header size ==

We either need the prior larger font for the title, or some sort of distinguishing background or border for it. Small and bold isn't enough, particularly for the ones without a picture. ] (]) 12:01, 10 September 2010 (UTC)

: I've left a note to the editor who changed it, he might have just made a mistake. --] (]) 12:37, 12 September 2010 (UTC)

Here we go again. For now I've set it to 125% which seems like the ] standard used by {{tl:infobox}}. --] (]) 06:59, 9 November 2010 (UTC)

== Caption doesn't work ==

I notice that "caption" doesn't work, as shown in ]. Would someone fix it, please? - ] (]) 19:51, 21 June 2011 (UTC)
: Someone has been messing with the code. It seemed harmless so I did not comment, but that seems to be one outcome. I corrected it. --] (]) 20:03, 21 June 2011 (UTC)
::Thank you muchly. I suppose I should learn how. - ] (]) 20:15, 21 June 2011 (UTC)

== pushpin=lighthouse - can the contrast be improved? ==

A number of lighthouse articles on my watchlist have recently had "pushpin=lighthouse" added. Now I am fine with the idea of marking the lighthouse with a lighthouse icon, but unfortunately many of them are almost impossible to see on my screen as the icon is white, black and yellow and being put on a map with yellow background and black regional borders, e.g. ]. The with red dot had much better contrast and was much more evident where the lighthouse was. Is there any chance to make this icon a bit more high-contrast? Could it be a red lighthouse? ] (]) 00:49, 18 October 2015 (UTC)
:The icon has been ] since {{diff|Template:Infobox lighthouse|prev|359498638|this edit}} in May 2010, and has not changed since. --] (]) 09:15, 18 October 2015 (UTC)


==lighthouse pushpin misplaced== ==lighthouse pushpin misplaced==

Revision as of 02:19, 30 October 2018

This is the talk page for discussing improvements to the Infobox lighthouse template.
Archives: 1Auto-archiving period: 2 years 
WikiProject iconLighthouses Template‑class
WikiProject iconThis template is within the scope of WikiProject Lighthouses, a collaborative effort to improve the coverage of lighthouses and other water navigational aids on Misplaced Pages. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.LighthousesWikipedia:WikiProject LighthousesTemplate:WikiProject LighthousesLighthouses
TemplateThis template does not require a rating on Misplaced Pages's content assessment scale.

Archiving icon
Archives
Archive 1


This page has archives. Sections older than 730 days may be automatically archived by Lowercase sigmabot III when more than 3 sections are present.

lighthouse pushpin misplaced

Thank y'all for your work on the technical side, but there's a UI problem.

It's fine if a viewer already knows the correct placement of the lighthouse and therefore understands that the icon is marking its bottom-right corner, but that's non-intuitive. Is it impossible to correctly position the icon so that the GPS point being marked is at the intuitive location at the center of its base? If that's impossible, the icon is cute but so misleading it should really be removed and replaced with one of the accurately-placed dots.

See, e.g., the difference between these two revisions of an article on a North Korean headland whose original GPS image was replaced by this template. The "lighthouse" pushpin not only makes it appear that the lighthouse is located miles inland but that the cape being referenced is an entirely different one from the truth. The "dot" pushpin, however, is completely accurate. — LlywelynII 23:16, 10 May 2017 (UTC)

Llywelyn, I centered the base of the lighthouse in a derivative version of the icon on commons. so, the base should be correctly centered now. Frietjes (talk) 15:10, 8 June 2017 (UTC)

Inappropriate Wikidata junk

The article Smith Island Light contains two instances of Infobox lighthouse—one for the eponymous lighthouse and one for the Skunk Bay Memorial Lighthouse, to which part of the Smith Island Light was moved before its destruction (and about which we lack an article). The latter one is, however, picking up from Wikidata an image and some information that applies not to the Skunk Bay Memorial Lighthouse but to the Smith Island Light. Is there some way of getting this template to ignore the stuff on Wikidata when it's inapplicable? Or is the only solution to just delete the second template? Deor (talk) 09:40, 19 August 2017 (UTC)

@Deor: I've tried solving this by adding |fetchwikidata= (no value) and removing the Wikidata link in the template if the aforementioned parameter is empty. The template documentation should mention this. Jc86035 (talk) 10:12, 19 August 2017 (UTC)
Thanks for your help, Jc86035. Deor (talk) 14:09, 19 August 2017 (UTC)

Infobox not rendering properly, hiding entered data.

Would someone please have a look at this article for me to see why the Infobox Lighthouse is not rendering properly, and so is hiding some of the entered data. The image won't display either. I think most of this was rendering properly earlier today, at least the image was: Grandique Point Lighthouse

In comparison, this lighthouse article I did a few years ago is displaying the Infobox Lighthouse correctly.: Low Point Lighthouse I may be doing something wrong but I can't see what it is. Thank you. Ken Heaton (talk) 00:31, 14 June 2018 (UTC)

Okay, that's weird, the infobox for Grandique Point Lighthouse displays correctly today.Ken Heaton (talk) 09:14, 14 June 2018 (UTC)

Mapframe maps?

{{Infobox building}} and {{Infobox shopping mall}} have both recently been updated to automatically show dynamic mapframe maps by default. I am proposing to similarly show such maps by default for this template, with the same optional parameters to adjust the size, frame center point, initial zoom level, and marker icon; and to similarly allow the mapframe map to be turned off using |mapframe=no. See Template:Infobox building#Mapframe maps and Template talk:Infobox building#Change to the map parameter so Kartographer works for further information. (FYI: I'm making similar proposal for other buildings infobox templates) - Evad37  15:36, 31 August 2018 (UTC)

Support, I agree about this update. angys (Talk Talk) 11:42, 1 September 2018 (UTC)
 Done - Evad37  01:49, 13 September 2018 (UTC)

Remove deprecated parameter; adjust labeltext

1. Parameter |elevation= is deprecated (since 2008). Per October 1st, 173 articles used it . I have replaced all instances |elevation= with the appropriate |focusheight=, with an extra visual check on whether the "elevation" actually meant focal height (check with tower height). Parameter |elevation= is no more needed. I propose removing it from the template (into "non existing parameter", i.e. reported unkown when used). When present, I removed parameter input text "Focal plane: ..." from these, as this is clear from lefthand labeltext so don't repeat in righthand side.

2. Parameter |height= is intended for construction height (tower height). To avoid confusion, I propose to make change the label (lefthand text) fror thid parameter: from "Height" into "Tower height". Did remove "Tower: .." text from input parameter (should not be in righthand side).

Both changes are in {{Infobox lighthouse/sandbox}} diff, as proposal. Comments? - DePiep (talk) 18:29, 11 October 2018 (UTC)

Template-protected edit request on 29 October 2018

It is requested that an edit be made to the extended-confirmed-protected template at Template:Infobox lighthouse.
(edit · history · last · links · sandbox · edit sandbox · sandbox history · sandbox last edit · sandbox diff · test cases · transclusion count · protection log)

This template must be followed by a complete and specific description of the request, that is, specify what text should be removed and a verbatim copy of the text that should replace it. "Please change X" is not acceptable and will be rejected; the request must be of the form "please change X to Y".

The edit may be made by any extended confirmed user. Remember to change the |answered=no parameter to "yes" when the request has been accepted, rejected or on hold awaiting user input. This is so that inactive or completed requests don't needlessly fill up the edit requests category. You may also wish to use the {{EEp}} template in the response. Consider making changes first to the template's sandbox and test them thoroughly here before submitting an edit request. To request that a page be protected or unprotected, make a protection request.

Please replace all code with the code from {{Infobox lighthouse/sandbox}}. Changes: 1. Parameter |elevation= removed (was deprecated for 10 years, not used in articles). 2. Write lefthand label "Tower height" to disambiguatie from "elevation height". Proposed here 2 weeks ago, with no comments. DePiep (talk) 13:36, 29 October 2018 (UTC)

 Partly done: I've removed elevation from the list of known parameters as a first step. I'd rather wait 'til the report you referenced above refreshes in a couple of days before going the whole way. Which isn't to say there aren't folks who may feel bolder than I do, and who feel like doing the whole request right now. Cabayi (talk) 17:45, 29 October 2018 (UTC)
..or wait a few hours for any changes to show up in Category:Pages using infobox lighthouse with unknown parameters of course. Cabayi (talk) 17:47, 29 October 2018 (UTC)
(ec) No, that was not what is requested, and incorrect at that. Had you done the full edit as requested, any offending articles would show up in the maintenance category for correction -- no problem. And you omitted the second part completely, even not mentioning here. -DePiep (talk) 17:52, 29 October 2018 (UTC)
"that was not what is requested"? Reverted myself. Cabayi (talk) 18:29, 29 October 2018 (UTC)
re: wait a few hours: yes, that is the process anyway. -DePiep (talk) 17:52, 29 October 2018 (UTC)
Cabayi Anything wrong with the request? What are you trying to say? Is asked for an update, and you cannot think about rewarding that request as is? -DePiep (talk) 20:19, 29 October 2018 (UTC)
DePiep I'm not inclined to remove a parameter without first checking that it's not in use. You objected and said that it wasn't what you'd requested, so I reinstated the previous version. Cabayi (talk) 20:49, 29 October 2018 (UTC)
Categories: