Template talk:Decdeg

This template was considered for deletion on 2016 August 31. The result of the discussion was "keep".

Blank parameter error

The template throws an error (Expression error: Missing operand for round) if the |rnd= parameter is specified but is left blank. I think that the following will fix it:

Present code:

 )  round {{{rnd|{{{5|6}}}}}}

My suggestion:

 )  round {{#if: {{{rnd|{{{5|}}}}}}
            | {{{rnd|{{{5|6}}}}}}
            | 6
          }}

--Redrose64 (talk) 18:48, 21 January 2010 (UTC)[reply]

Bug fixed. –droll [chat] 18:12, 23 January 2010 (UTC)[reply]

Document usage with unnamed params?

Decdeg supports numbered parameters, and one of the examples shows how to use it that way, but that usage is not formally explained except by the example. Using numbered parameters seems like a natural way to use this template, and so I propose that we add an explanation or figure to the Usage section that explains using numbered parameters. Any reason not to do that? — John Cardinal (talk) 14:59, 25 February 2010 (UTC)[reply]

Edit request from Droll, 17 May 2010

{{editprotected}} The version in the sandbox fixes an "undocumented feature" that caused negative decimal values less than ±1 degree to be handled incorrectly. I also simplified the logic a bit. See the testcases page for output from the active template and the sandbox version. The last example demonstrates the bug. I was the creator of this template and have maintained it. –droll [chat] 21:48, 17 May 2010 (UTC)[reply]

Done, thanks. PeterSymonds (talk) 22:26, 17 May 2010 (UTC)[reply]

Requested modification

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

The modified version is in the sandbox and the test cases are here. I was cleaning up some articles that transclude {{Location map}} and discovered that some editors entered values like -118°-17′-31″ in place of 118°17′31″W. That template generates the output the editor expected. This template currently does not. This change will allow values like -118°-17′-31″ and the template will return the decimal equivalent of 118°17′31″W. I do no mean to imply that -118°-17′-31″ is a valid syntax. This change will, IMHO, result in more predictable output when input is malformed, which is better than letting unexpected results go unnoticed. –droll [chat] 19:31, 1 May 2012 (UTC)[reply]

Done Cheers, --joe decker ^{talk to me} 04:24, 13 May 2012 (UTC)[reply]

bug in rounding code

A recent edits to Black Hills (San Bernardino County) exposed a bug in this template: it will round 59.873 seconds of arc up to 60. The correct way to round such an angle would be to set the seconds to zero and add one to the minutes of arc. —Stepheng3 (talk) 18:22, 7 June 2012 (UTC)[reply]

I don't think it is this template that is to blame. {{Infobox coord}} is used to "populate" the {{Coord}} template. I think {{Coord}} might be responsible since {{Infobox coord}} does no rounding. I'll spend some time on it and report back. –droll [chat] 19:07, 7 June 2012 (UTC)[reply]

I was coming to the same conclusion: it's definitely inside {{Infobox coord}}: {{Infobox coord | lat_d = 35 | lat_m = 23 | lat_s = {{#expr:59.873 round 0}} | lat_NS = N | long_d = 117 | long_m = 18 | long_s = {{#expr:43.179 round 0}} | long_EW = W | type = mountain | region = | dim = | scale = 300000 | source = | format =  | display = inline | name =  }} --Redrose64 (talk) 19:25, 7 June 2012 (UTC)[reply]

I'd say that the bug is in {{Infobox mountain range}}. Passing an invalid value to {{Infobox coord}} causes {{Coord}} to report and error.

{{coord|35|23|60|N|117|18|43.179|W}} → 35°23′60″N 117°18′43.179″W / 35.40000°N 117.31199417°W Coordinates: latitude seconds >= 60
{{#coordinates:}}: invalid latitude

{{Infobox coord}} nearly exceeds the depth limit already. It does not attempt error checking. If a template editor wants to round seconds then it seems to me that it is their responsibility to get it right. If an article editor inputs an invalid value then allowing coord to return and error message is valid, –droll [chat] 19:54, 7 June 2012 (UTC)[reply]

Thanks. I think Droll is correct. The rounding code is in {{Infobox mountain range}}. I'm moving the discussion to Template talk:Infobox mountain range. Sorry for the confusion. —Stepheng3 (talk) 20:13, 7 June 2012 (UTC)[reply]

Call Lua code directly?

In the sandbox, I've written a new simple version of this template that calls into the Coordinate method written in Lua. An argument in favor of the sandbox version: we should only have one efficient dms2dec converter in WP, not two. Another argument in favor: this should reduce code complexity and template recursion depth. <updated> A possible argument against: the Lua code provides the number of significant figures that are equivalent to the input, rather than always giving 7 digits. I think this is a feature, rather than a bug.</updated>

I propose moving the sandbox version to the main template. Comments? Questions? Suggestions? —hike395 (talk) 15:44, 23 April 2013 (UTC)[reply]

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

No discussion, adding {{editprotected}}. Admin: please copy {{Decdeg/sandbox}} to {{Decdeg}}. Thanks! —hike395 (talk) 23:01, 26 April 2013 (UTC)[reply]

Happy to in principle, but I'm a bit reluctant to make a comprehensive change I don't understand to a template used on 13000 pages! I've pinged Wikipedia talk:WikiProject Geographical coordinates for someone more experienced to have a quick look. Andrew Gray (talk) 22:50, 29 April 2013 (UTC)[reply]

The Lua module has a problem with hemisphere detection, uses a slightly different formula and does not respect user-defined rounding. Examples are in the testcases. Looking for lowercase directions and negative degrees when no hemisphere is given are easy fixes, and the rounding issue is more of a style decision I guess. The formula difference needs to be resolved though. The template uses the absolute values of all input and multiplies the entire expression by one or negative one depending on hemisphere. The Lua module does not use absolute values and still multiplies the entire expression by one or negative one. — Bility (talk) 17:32, 8 May 2013 (UTC)[reply]

Request disabled until the above concerns are addressed. Hike395, thank you for working on this: can you respond? — Martin (MSGJ · talk) 09:03, 9 May 2013 (UTC)[reply]

Thanks, Bility, for finding these cases. I will ask for some changes at Module talk:Coordinates. —hike395 (talk) 10:56, 9 May 2013 (UTC)[reply]

Heh, everything on this site is protected. For non-admin you have to make a sandbox version of a Lua module and open an edit request so you can make a sandbox version of a template so you can open another edit request. Maybe one of the people who voted not to unbundle wants to come work on this request.

Anyway, I came to say that as far as the formula goes, I think the template is doing it right per the principle of least astonishment. Although technically you can think of a negative coordinate as distributing -1 over each part, i.e. -4°27′32″ = -(4° + 27′ + 32″) = -(4°) - (27′) - (32″), from an editor's perspective they're just splitting up -4°27′32″ into a template, pushing the separate numbers into parameters, i.e. -4° = |deg=-4; 27′ = |min=27; 32″ = |sec=32. In that sense it's not expected that you would have to put in negative values for minutes and seconds, since that's not how it's written out. So I think the Lua version should use absolute values as well after correctly determining the direction. — Bility (talk) 06:52, 10 May 2013 (UTC)[reply]

As of October 2013, the problem that Bility mentioned with hemisphere detection has been addressed. The absolute value problem has not yet been addressed (AFAIK). —hike395 (talk) 15:42, 31 August 2016 (UTC)[reply]