Wiki evaluation - MLS

[n1vux]

In the Evaluation doc in wiki, it incorrectly says Maidenhead (mls) can form words. Since MLS alternates pairs of letters and pairs numerals, it could only form EL33tt haxor words, and at least for the experienced user, or with a syntax checking interface, no letter/number ambiguity.

(MLS does have seams between fields and between squares so that adjacent places may be disimilar, but even OLC has that for towns straddling a one degret square?)

[RiverMersey]

MLS - are we referring to: https://en.m.wikipedia.org/wiki/Multiple_listing_service as proprietary used by USA realty groups?

[n1vux]

No, the MLS footnote and abbreviation on evaluation wiki page is the Maidenhead Locator System, an open standard.

https://github.com/google/open-location-code/wiki/Evaluation-of-Location-Encoding-Systems#maidenhead-locator-system-mls

[RiverMersey]

Yes, I've just read that reference stating that MLS (Maidenhead Locator System) can form words. Effectively, QRA / QTH / MLS / OLC / PlusCodes are the sequential evolution of the same system.

MLS & OLC (pluscodes) are effectively the same but take their starting datum point from different places and their notation is different from each other. Pluscodes - in my opinion - are the best option so far.

Directly supported in Google searches Adjacent squares will be alphanumerically similar, therefore can be "sorted" Distances between raw pluscodes can be calculated Granular accuracy is directly proportionate to the length of the raw code Granular accuracy can range from 2200 km blocks right down to millimetre sized blocks A deliberate choice was made to use 20 specific symbols to aid error detection Pluscodes can be used raw or can be augmented with the use of adding the closest major town Open source

Original pluscode proposers suggested it would be of most use to places in the world without existing defined postcodes/zipcodes. When in fact, we find it is equally useful in specifying locations of railway track junctions, road markings, pipeline access points, cemetery plots, locations at sea, etc. Pluscodes could in theory be applied to any shaped object - the granular accuracy varying dependant on the area being mapped. So we could equally apply pluscodes to human bodies or other heavenly bodies!

Pluscode's major disadvantage is that while they can be manually calculated, they are more reliable when algorithmically calculated - which in turn means they kind of rely on the presence of electricity.

[n1vux]

My request is to remove the alleged disadvantage of "forming words" from the section on Maidenhead/MLS. AFAIK it is unsubstantiated and wrong.

Please note, I am not evangelizing for MLS/QTH; I was evaluating adding pluscode/OLC support to systems I use with MLS/QTH and LAT-LON, and noticed the minor factual error above in the evaluation page wrto MLS/QTH.

Maidenhead (MLS/QTH) in modern usage is incapable of forming words, as worlds do not alternate graphemes letter letter number number as AB34ef78. If any (hypothetical) prior form of Maidenhead could form words asBArn, it is unknown to me, it would (if it exitsts) be a historical dead-end, and I don't see it in the wikipedia article which was archived as the citation for the MLS/OLC wiki descripion under footnote mls.

To your comments -

I recognize OLC/pluscode as being in the same class of algorithm as MLS/QTH, but they differ in more than "datum" (i'll accept that as used metaphorically for origin of grid irrespective of classical geodesy usage) and "notation" -- MLS/QTH alternating the degree of subdivision of cells at even and odd subdivisions is a structural difference not just a notational difference (which results in 1 x 2 degree cell instead of 1 x 1 degree cell at equivalent level; 1x2 is vaguely a feature at mid-latitudes, less so at the equator).

FWIW, MLS/QTH is also more reliable when algorithmicaly calculated; most things are. I have translated the algorithm from one language to another, and have server code en/decoding them on the fly. (I think i want to encode the posits as pluscode/OLC also to benefit anyone having to manually copy from one screen or printout into a different a separate Gmaps w/o clipboard. For another use, I might want to use the truncated pluscode to represent a bounding-box around civic entities; i could do that with MLS/QTH almost as easily, but API looks easier with OLC and of course Gmaps has native support, winning!, and that application doesn't have any natural affinity for MLS. )

Perhaps you're trying to say MLS/QTH has an irrelevant/obsolete advantage in pencil-and-slide-rule off-line calculation?

( As to the evangelical paragraphs in reply -- Near as i can tell the major advantages of pluscode/OLC is it's an open standard and supported by Google maps, a major commercial entity. The other claimed advantages are hardly unique advantages; on the evaluation page, only LAT-LON fails to share them. The other Commercial entities are touting their proprietary systems having the same goal of being usable for post & food delivery, taxi, sat-nav entry for their systems - and additionally that 3words can be dictated over the phone easier than random alphanumberics. They of course lack open standards, free-to-use, and one resumes Gmaps support. I don't recall if the 3words people have sold a national post office on their system; one hopes their potential clients check this wiki first and avoid lock-in! )

(Also FWIW, my Garmin GPS lets me enter and read out MLS/QTH posits as one of its Setup modes, along with dms, dm.mm, d.dd, but not pluscode/OLC. But few enough people have SATNAV gear that is that configurable so that's not much advantage.)

[RiverMersey]

Many thanks for your reply. Regarding the incorrect ascertaination on Wikipedia about MLS codes forming words, perhaps edits to that could be submitted to Wikipedia as it isn't possible to change anything there via this discussion here.

My own investigations into plus codes lead me to writing the msaccess VBA script at: https://github.com/google/open-location-code/issues/364 . As I mentioned in that post, overall the VBA works well and is fast but I couldn't understand the process of generating the finer graduations of the plus code.

Sorry, my intention was not to evangelize the use of plus codes over other systems, mearly to try to summarise the benefits of the system to any new or future readers.

Yes, dedicated sat nav systems don't support further processing of the raw data to present it in the form of MLS, what 3 words, olc, etc. However, many smart phones do have that potential to have app software installed that could display any and all of those possiblities - heck, they could even display maps stating "here be dragons"! (And actually have displayed augmented reality of pokimon!)

Unfortunately, W3W seems to have encouraged some parts of the UK emergency services to urge the public to use their system - personally, I believe this is ill-advised.

My reference to plus codes reliability requiring electricity was in reference to the idea that there is a navigational idiom of trying to reduce reliance on various equipment, instead trying to carry knowledge in your head and take ques from the environment around you. I remember being taught how to determine North using the hands of an analogue wrist watch!😁

[StephenBrown2]

Regarding the incorrect ascertaination on Wikipedia about MLS codes forming words, perhaps edits to that could be submitted to Wikipedia as it isn't possible to change anything there via this discussion here.

The doc being referenced is not Wikipedia, it's the wiki associated with this repo: https://github.com/google/open-location-code/wiki/Evaluation-of-Location-Encoding-Systems#maidenhead-locator-system-mls which can only be edited by those with permissions on this repo.

[n1vux]

Yes indeed, I am reporting an error on this Repo's attached github wiki.

I cited that section's #mls footnote's reference to a correct Wikipedia article in support of my assertion that the OLC github wiki statement that Maidenhead/QTH locators can form words was in general false, as words do not have numerals, which are always included in any MLS/QTH posit longer than 2 char. (The largest blocks of MLS/QTH, 20° x 10° "Fields", will form 2-letter words, but this isn't a source of confusion, (a) the Field is standardized as upper case, only OK and corporate identity GE are even vaguely correct as uppercase "words"; (b) 20° x 10° isn't a very useful boundingbox , it's too small for most countries and too large for everything else; the coarsest MLS/QTH generally used is AA99 format ("Squares" 1° x 2°) with AA99aa subsquares (and smaller) being more common.

[zongweil]

Hey @n1vux, thanks for bringing this up. I understand the point that you're making.

It looks like the line in question is "The accuracy and length of the codes is similar, but Maidenhead Locator System codes include vowels and so the generated codes include words [mls]."

@drinckes: Did you mean that MLS could inadvertently form words with numerals that looked like letters? Should we rephrase this section?

[n1vux]

Thank you @zongweil .

While fe11ow could be misread, if reading quickly or in an unfortunate choice of font, if one follows the recommended MH/QTH/MLS convention of UPPER CASE for Field letters and lower case for subsquare letters (and perhaps pick a suitable font?), the danger of seeing words in e.g. FE11ow RA99ed PO57al is rather reduced. While possible for comedic purposes,† it's not a serious danger.

Any remaining danger is further reduced since the numeral-confusable letters are invalid in the positions of numerals in MLS/QTH, as letter vs number positions are uniform as a matter of syntax, not derived from a specific encoding. So even if someone did miscopy FE11ow as FELLOW, decoding the latter as Maidenhead will fail to give an incorrect posit, giving no posit at all but rather will disclose the error quickly,* at which point the obvious (usually unique) confusable numerals can be reinserted.

Anyway, point of this correction is to make your OLC comparisons page more reliable. Other seekers like myself may well come to this page knowing one of the alternatives better than they know OLC, and if the comparison is blatantly wrong about the one they know, their estimate of the veracity and objectiveness of the rest must suffer. (Thus I hope others with specialized knowledge of the other alternative geo-codes are likewise proof-reading those critiques for accuracy too.)

(Despite the above, I do like the look of pluscode/OLC, and will find uses for it, so thank you for doing this. The advantages of being an open standard (advantage shared with QTH), perhaps better API for bounding boxes than QTH, and supported by G-maps (not) are good enough for me. While I won't be removing QTH from an app that caters to QTH's established userbase, I can and likely add OLC to the multiple translations for convenience, and use it in other mapping projects.)

• (unless a software implementation is very poor, which is of course hardly impossible, but if that poor, i wouldn't trust it's maths either!).

†(And alas for comedy there seems to be no Russian Post Office in subsquare PO57al and possibly not in all of PO57; most comedic 1337ish "word" subsquares are ocean, mountains, rain-forest, or the Antarctic continent, between roads and settlements, as of course would be expected for random selections on this only locally densely populated orb.)

[drinckes]

Thanks @n1vux - I suggest changing the section:

The accuracy and length of the codes is similar, but Maidenhead Locator System codes include vowels and so the generated codes include words [mls].

to

The accuracy and length of the codes is similar. MLS cannot generate words, but it can generate sequences that may appear to be words (e.g. reading "1" as "l").

Would that be ok?

[n1vux]

Yes, thank you @drinckes , that's fine.

[fulldecent]

First, I can't find any authoritative specification for Maidenhead Locator System (no, Wikipedia articles are not authoritative for anything). So every criticism of MLS is valid.

I define that MLS shall define all locations to "Beer". Beer is a word. Checkmate.

Second, the thing we are debating is the validity of this statement:

The accuracy and length of the codes is similar, but Maidenhead Locator System codes include vowels and so the generated codes include words [mls].

And the raised argument is:

Since MLS alternates pairs of letters and pairs numerals, it could only form EL33tt haxor words...

The argument assumes all words (in all languages) are greater than two letters. This is false.

---

Because this issue is based on a false argument and no other substantiating argument has been raised, I recommend this issue be closed as "invalid issue".

[bilst]

Updated wiki with drinckes'suggestion.