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.
On Thu, Sep 1, 2016 at 10:40 AM, Doug Rinckes <drinc...@google.com> wrote:
> 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")
> false
> OpenLocationCode.isValid("gggggggg")
> false
> OpenLocationCode.isValid("gggg+")
> true
>
>
>
>
> Doug Rinckes
> Technical Program Manager
> Google Switzerland
>
> On Wed, Aug 31, 2016 at 11:57 PM, Russell Nelson <russnel...@gmail.com>
> wrote:
>
>> On Wed, Aug 31, 2016 at 4:25 PM, Philip Newton <philip.new...@gmail.com>
>> wrote:
>>
>>> On 31 August 2016 at 21:59, Russell Nelson <russnel...@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.
>>
>>
>>
>> --
>> 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+unsubscr...@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/ms
>> gid/open-location-code/CA%2BuY%3DMQpS1ULX4trzrZ15s6rgKN%2BBQ
>> VKTzSLoSw83VqESk59Xw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/open-location-code/CA%2BuY%3DMQpS1ULX4trzrZ15s6rgKN%2BBQVKTzSLoSw83VqESk59Xw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
--
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+unsubscr...@googlegroups.com.
To post to this group, send an 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%3DMTB7hvCg0%2B9Ja%3Dx_5n0VUku_w-7%2Bn9Fep5Jv5prQfktQA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
