User talk:EncMstr

From Wikipedia, the free encyclopedia
Jump to: navigation, search
My admin actions
ContribsBlocksProtectsDeletions
Admin links
NoticeboardIncidentsAIV3RR
BacklogProdAfDAutoblocks
Arbitration
ArbitrationNoticeboardEnforcement
Checkuser
RFCUClerks pageCheckuser
Abusive HostsVCN proxycheckippages
Multi-RBL lookupDNSstuff
Wannabe Kate's toolPrefix index

TUSC token 9971e50bd95eab9f57319ec9a0d97086[edit]

I am now proud owner of a TUSC account where I changed my password!


Research stations in Antarctica[edit]

hi EncMstr's, i'm new and yesterday i had problems with editing, sorry ----- I'm updating the list with the site of the Council of Manager of National Antarctic Programs (the excel file is at the end of this page https://www.comnap.aq/Members/SitePages/Home.aspx (updated 13 february 2014). ----- have a nice day N

Wiki Loves Pride[edit]

You are invited! Wiki Loves Pride

You are invited to participate in Wiki Loves Pride, a global campaign to create and improve LGBT-related content at Wikipedia during the month of June, culminating with a multinational edit-a-thon on June 21. The project is being spearheaded by two organizers with roots in the Pacific Northwest. Meetups are being organized in some cities, or you can participate remotely. Wikimedia Commons will also be hosting an LGBT-related photo challenge.

In Portland, there are two ways to contribute. One is a photography campaign called "Pride PDX", for pictures related to LGBT culture and history. The Wiki Loves Pride edit-a-thon will be held on Saturday, June 21 from noon–4pm at Smith Memorial Student Union, Room 236 at Portland State University. Prior Wikipedia editing is not required; assistance will be available the day of the event. Attendees should bring their own laptops and cords.

Feel free to showcase your work here!


If you have any questions, please leave a message here. You can unsubscribe from future notifications for Oregon-related events and projects by removing your name from this list.

June 2014[edit]

Hello, I'm BracketBot. I have automatically detected that your edit to State Protection Group may have broken the syntax by modifying 1 "()"s. If you have, don't worry: just edit the page again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on my operator's talk page.

List of unpaired brackets remaining on the page:
  • Unit is based in [[Alexandria]] (Sydney). Decentralized units are based in the [[Blue Mountains (New South Wales|Blue Mountains]]<ref> https://www.facebook.com/BlueMtnsPoliceRescue</ref>,

It's OK to remove this message. Also, to stop receiving these messages, follow these opt-out instructions. Thanks, BracketBot (talk) 16:06, 15 June 2014 (UTC)

source:S parameter[edit]

Continuation of this

Wow. Something tells me you should have a greater hand in doc pages. For a new editor (< 1 year), assuming he believes in doing things right, they're often more hindrance than help. I know there's a project to improve help pages, but that's no reason not to fix some of the worst problems now.

I see you have an interest in coordinates precision, so I would like ask your opinion of some tables I added to the project page at WP:OPCOORD (scroll down a little from that shortcut). Mandruss (talk) 23:34, 9 July 2014 (UTC)

Thanks, I think. Early in my wikiediting history I ran afoul of following what MOS:IMAGE advised, inspiring a long discussion about what the guideline. I can't find it now, but some long time editors disagreed suggesting the guideline was incorrect.
I saw your posting about the coordinate table when you first posted it. My only suggestion would be to be more explicit about ranges:
Size of object Appropriate DMS precision Appropriate decimal precision
20 km .. 200 km d° m' d.d°
2 km .. 20 km d° m' s" d.dd°
...
Thanks for the table. I think it is an improvement. —EncMstr (talk) 00:28, 10 July 2014 (UTC)
Hmmm. I'm not sure how to go about choosing ranges that would work well, especially when you take the effect of latitude into account. I've about concluded that what I need to do this right is some DIY computer help with the computations. I'll see what I can do in that regard.

Of course the best solution would be some piece of software, readily available to editors, that, given an object size and latitude, would provide the precision that gets closest to a resolution of one-tenth of the object size. Being a mainframe-software dinosaur, I wouldn't begin to know how to do that in this environment. If you know of someone who might, feel free to try to get them interested in such a task, for the betterment of mankind.

Or, even better, the addition of an object-size parameter to the coord template. If object-size were coded, coord would compute the appropriate precision for you. {{coord|37.8483333|N|119.5569444|W|region:US-AL_type:landmark|70km|display=inline}} ---> 37°48′N 119°36′W / 37.8°N 119.6°W / 37.8; -119.6

I have a dream! Mandruss (talk) 01:45, 10 July 2014 (UTC)

@EncMstr: With a considerable amount of effort (I really had trouble getting my head around this), I worked out what the ranges would be for each decimal-degrees format at 0° latitude. I won't put all of them here, but two typical examples are:
60.5 m to 605 m : d.dddd
605 m to 6.05 km : d.ddd
That's not only ugly as sin, it would be pretty hard to work with. Those ranges wouldn't work for the other latitudes, nor would they work for the dms formats. There would have to be a separate table for each combination of latitude and coordinate system, for a total of eight tables. I'd be willing to do the work if I thought the result would be better than the current tables, but I don't. I'm thinking what we have is the best we can do, unless and until one of the aforementioned software solutions happens. Mandruss (talk) 08:45, 10 July 2014 (UTC)

I really like the auto precision display idea. We already have a dim:X parameter where the major size of the object (in meters) can be given. I'll look into that. —EncMstr (talk) 04:34, 11 July 2014 (UTC)
@EncMstr: Glad you like it. Re dim, I'm not sure viewing diameter is exactly the same as object size for computing precision (I don't know how dim is currently used, or may be used in the future).
Ideally, coord would do the math required to produce the perfect answer in every case. That would require both trig functions in the available programming languages, and a programmer who knows trig well enough to apply them to this problem (or can get lots of help with the trig from someone else). If the decision is made to simply implement the tables in coord, it should be made with understanding of the caveat I recently added below the tables:

The tables are not perfect. Some cases will yield a result that is different from what you would get by doing the math (including trigonometry) for that specific case. This is because it is impossible to represent all cases correctly in a usable tabular format. The tables provide the correct answer for a majority of cases. Any error should be limited to one level of precision (e.g., d° m' vs. d° m' s", or d.ddd° vs. d.dddd°), which is acceptable for the purposes of Wikipedia coordinates. Mandruss (talk) 09:54, 11 July 2014 (UTC)