Is there a useful test data set?

[Jeffrey Friedl]

Is there a data set for encoding and decoding that's actually useful for testing? The one on the project's GitHub barely scratches the surface of what needs to be tested when a library is created or updated.

[Zongwei Li]

Hey Jeffrey,

What test cases do you feel are missing from the data set? We would rather improve the existing data set than have another one floating around :).

[Jeffrey Friedl]

On Saturday, May 26, 2018 at 6:42:26 AM UTC+9, Zongwei Li wrote:

What test cases do you feel are missing from the data set? We would rather improve the existing data set than have another one floating around :).

The most minimal test set would, for each quadrant of the globe, have a code of every valid length (from 2 up to, say, 15), and include all the edge cases, and also include a bunch of known-invalid codes that should not be recognized as valid.

[Doug Rinckes]

The existing test set (encodingTests.csv) already includes codes where one or both coordinates are negative. There is also a set of tests for validity (validityTests.csv).

We're not aware of any uncovered edge cases (the main edge cases are at 90 degrees latitude and -180/180 degrees longitude), but if you feel there are additional test cases you are welcome to add them to the test sets in github (https://github.com/google/open-location-code). 

Ngā mihi,

Doug Rinckes, Technical Program Manager, Google Switzerland GmbH; 9GHJ+P88 Zürich

--
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 "Plus Codes Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-location-c...@googlegroups.com.
To post to this group, send email to open-loca...@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/08f664ce-21a7-46db-91d2-97b0bed0a58b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex]

Is the code length strictly defined? I would expect that as long as the string contains a "+" anywhere in the code, then any length (including odd) should be acceptable (provided the "text location context" such as "Hawaii" or "Honolulu" makes the code unambiguous). Maybe a degree symbol (°) could be optional after the first four digits.

Odd length is particularly useful closer to the poles, where cells are dramatically stretched N-S (longitude is substantially "taller" than latitude is "wide"). For example the Trivett weather station in Alert, Canada can be precisely pinpointed with 9 "digits" (C7JV FF2V+8) or 5 with local context ("FF2V+8 Alert, Canada"). You can pinpoint a hospital at "39+7 McMurdo, Antarctica"

If there is no "+" should the code imply the largest area (first "digits") or the local (fifth and subsequent "digits)? Does "85FQ Colorado" refer to Denver and a hundred kilometers SE or just a tiny section of empty road? I would think that Continents, Oceans, Countries, and maybe States would imply the largest area, whereas Cities and Mountain Peaks imply the local area.

Maybe a degree symbol could be optional such as "6G8V°W9M4+" or "8V°W9 Tanzania". After all, the four "digit" prefix does represent a square degree of area.

[Andreas B]

It might be more useful to have this discussion in a separate thread, not tagged on to a discussion about test data sets.

That being said, OLC is defined here: https://github.com/google/open-location-code/blob/master/docs/olc_definition.adoc

Codes with odd length <11:

Surprisingly, the definition doesn't contain any clear statement about codes with an even length <11 being considered invalid, although that seems to be the intention (and should probably be added to the definition). There might be some edge cases where codes of length 9 lead to a sensible location, like the examples near the poles you bring up - but in the general case, having an area with a 20:1 aspect ratio in degrees doesn't seem to be worth the small reduction in code length.

Additional '°' character:

I don't think that having an additional character is really useful. What are your reasons for suggesting it?

'+' character optional?:

If there is no '+' character, then the string should not be considered a valid OLC. One reason for this is exactly the ambiguity you bring up. There's a big difference between "85FQ0000+ Location" and "85FQ+ Location". Another reason is that strings missing a '+' character can't really be identified as plus codes by humans.