http://plus.codes usability issues
103 views
Skip to first unread message
Russell Nelson
Aug 31, 2016, 3:59:35 PM8/31/16
to open-location-code
Perhaps I am missing something, but why does plus.codes not successfully find 87P7 ? If I type those four characters into the search box, it shrugs at me. Same thing if I type 87P70000. It requires the + at the end. Okay, so maybe you can use a shorter code by leaving off the zeroes? Nope, 87P7+ searches within your current zone. And, when a search is successful ("87P70000+"), why does it leave me zoomed out to the highest level?
I speculate (from observing the workings of plus.codes) that the point is the plus sign. When an address parser sees it, BING, it knows that it should look on both sides for [0-9A-Za-z] to create a plus code. And if not, then it never interprets it as a plus code, even if the string has no spaces and consists of only [0-9A-Za-z].
Philip Newton
Aug 31, 2016, 4:25:58 PM8/31/16
to Russell Nelson, open-location-code
On 31 August 2016 at 21:59, Russell Nelson <russn...@gmail.com> wrote:
> I speculate (from observing the workings of plus.codes) that the point is
> the plus sign. When an address parser sees it, BING, it knows that it should
> look on both sides for [0-9A-Za-z] to create a plus code. And if not, then
> it never interprets it as a plus code, even if the string has no spaces and
> consists of only [0-9A-Za-z].
"Chicago" consists only of [0-9A-Za-z], but I expect you wouldn't want
> I speculate (from observing the workings of plus.codes) that the point is
> the plus sign. When an address parser sees it, BING, it knows that it should
> look on both sides for [0-9A-Za-z] to create a plus code. And if not, then
> it never interprets it as a plus code, even if the string has no spaces and
> consists of only [0-9A-Za-z].
that to be interpreted as an Open Location Code.
And even if you stick to the alphabet used in the OLC (without AEIOU,
among others), "Cwm" is a village in Wales, for example.
How should Google's address parser identify a location as an OLC
without the plus, without too many false positives?
Cheers,
Philip
--
Philip Newton <philip...@gmail.com>
Russell Nelson
Aug 31, 2016, 5:57:16 PM8/31/16
to Philip Newton, open-location-code
On Wed, Aug 31, 2016 at 4:25 PM, Philip Newton <philip...@gmail.com> wrote:
On 31 August 2016 at 21:59, Russell Nelson <russn...@gmail.com> wrote:
> I speculate (from observing the workings of plus.codes) that the point is
> the plus sign. When an address parser sees it, BING, it knows that it should
> look on both sides for [0-9A-Za-z] to create a plus code. And if not, then
> it never interprets it as a plus code, even if the string has no spaces and
> consists of only [0-9A-Za-z].
"Chicago" consists only of [0-9A-Za-z], but I expect you wouldn't want
that to be interpreted as an Open Location Code.
"Chicago" is a bad example, because it's not a valid OLC (7 characters), and even if you pad it out with a zero and a plus sign, plus.codes rejects it.
And even if you stick to the alphabet used in the OLC (without AEIOU,
among others), "Cwm" is a village in Wales, for example.
"Cwm" is also a bad example, because it only has 3 characters. But let's assume that you picked examples where had 4, 6, or 8 character and which match placenames, like, say, Newark.
Do you mean Newark, NY, Newark, DE, Newark, OH, Newark, Texas, Newark, WI, Newark CA, Newark England, or NEWARK00+ (except that it, too, is not a valid OLC).
How should Google's address parser identify a location as an OLC
without the plus, without too many false positives?
Well, let's look at false negatives. Right now, any valid OLC without a plus sign is a false negative. It is (by definition) a valid OLC, so to not accept it is a false negative. What if it was a false positive and we could find a place name or road name which matched an OLC, say Newark. We still need to deal with the ambiguity of all the Newarks. It's a given that any random placename will have duplicates, right down to house numbers. There are two buildings in Potsdam, NY which are number one. One of them is "1 Castle Drive". The other is "One Castle Drive". As soon as you don't use OLC, you have to deal with ambiguity. What is incorrect about adding an OLC interpretation to a string as one more ambiguous (if indeed it is ambiguous, which 99.99% won't be, because they have a digit or no vowel). EVEN IF you use a plus, you still cannot say with reliability that you have the location the person intended to specify, because of typos.
When I travel, and people ask me "where are you from", I have to start waving my hands, making the shape of NY in the air, or describing two arcs of length equal to the distance between Ottawa and Montreal. There's only 18 four-digit OLCs in New York. If people were used to using them, four characters would tell them where I live. Massachussetts only has three. Same for Connecticut.
The only time I can see your concern being an actual problem for people is when you have 1) a four, six, or eight character placename, which 2) is the only one anywhere on earth, and 3) is *also* a valid OLC. Interpreting it as an OLC would *increase* ambiguity, and that's bad. In every other instance, it would reduce ambiguity, because an OLC definitely describes a single place on earth, whereas, Newark? Be careful, you might end up in California rather than New Jersey.
When I travel, and people ask me "where are you from", I have to start waving my hands, making the shape of NY in the air, or describing two arcs of length equal to the distance between Ottawa and Montreal. There's only 18 four-digit OLCs in New York. If people were used to using them, four characters would tell them where I live. Massachussetts only has three. Same for Connecticut.
The only time I can see your concern being an actual problem for people is when you have 1) a four, six, or eight character placename, which 2) is the only one anywhere on earth, and 3) is *also* a valid OLC. Interpreting it as an OLC would *increase* ambiguity, and that's bad. In every other instance, it would reduce ambiguity, because an OLC definitely describes a single place on earth, whereas, Newark? Be careful, you might end up in California rather than New Jersey.
Doug Rinckes
Sep 1, 2016, 10:40:47 AM9/1/16
to Russell Nelson, Philip Newton, open-location-code
tl:dr; No "+" sign, it's not a valid OLC.
:-)
"GGGG" is not a valid OLC. "GGGGGGGG" is also not a valid OLC. But "GGGG+" is a valid (short) OLC.
The implementations in github should all enforce this - if they don't please file a bug (even better send a pull request fixing it):
OpenLocationCode.isValid("gg")falseOpenLocationCode.isValid("gggggggg")falseOpenLocationCode.isValid("gggg+")true
Doug Rinckes
Technical Program Manager
Google Switzerland
--
Public site: http://www.openlocationcode.com/
Github project: https://github.com/google/open-location-code
Demo site: http://plus.codes/
---
You received this message because you are subscribed to the Google Groups "open-location-code" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-location-code+unsub...@googlegroups.com.
To post to this group, send email to open-location-code@googlegroups.com.
Visit this group at https://groups.google.com/group/open-location-code.
To view this discussion on the web, visit https://groups.google.com/d/msgid/open-location-code/CA%2BuY%3DMQpS1ULX4trzrZ15s6rgKN%2BBQVKTzSLoSw83VqESk59Xw%40mail.gmail.com.
Russell Nelson
Sep 1, 2016, 11:43:50 AM9/1/16
to Doug Rinckes, Philip Newton, open-location-code
Neither is "Newark" a valid location. If I go to Google (or Bing, or OpenStreetMap) and search for "Newark", I get multiple results. What is the harm in adding the same location to that list which would be more precisely specified by Newark00+ ? Cuz it would also be more precisely specified by "Newark, NY". You're not going to find ANYONE who would say "Google's address service can't locate Newark" is the right thing to do. And indeed, plus.codes agrees with me. It happens to resolve the ambiguity by giving you the most populous (I speculate) Newark, Newark NJ.
Whatever happened to the enwp.org/Robustness_principle ? "Be conservative in what you do, and liberal in what you accept"
BTW, perhaps I should say "unique OLC". I agree with you that something which is parsing an OLC should expect a plus. I hope you agree with me that a string which would be a valid OLC if it had a plus on the end of it is a worthy result to return in a context where multiple search results are expected.
Whatever happened to the enwp.org/Robustness_principle ? "Be conservative in what you do, and liberal in what you accept"
BTW, perhaps I should say "unique OLC". I agree with you that something which is parsing an OLC should expect a plus. I hope you agree with me that a string which would be a valid OLC if it had a plus on the end of it is a worthy result to return in a context where multiple search results are expected.
To unsubscribe from this group and stop receiving emails from it, send an email to open-location-code+unsubscribe@googlegroups.com.
maman St georges
Oct 23, 2016, 4:21:03 PM10/23/16
to open-location-code
ok
Reply all
Reply to author
Forward
0 new messages