jonmcpherson / open-location-code Goto Github PK

Hello!

Would you mind adding an internal max length to your implementation, as per google/open-location-code#190?

Specifically, the following changes will be made:

• If you ask the library to encode a lat/long with more than 15 digits, the library will return a plus code with 15 digits.
• If you ask the library to decode a plus code with more than 15 digits, the library will only take the first 15 digits into account with the returned code area.
• Plus codes with more than 15 digits will be treated as valid if all the other validity constraints are satisfied. If the plus code has an invalid character after the 15th digit, it will be treated as invalid.

You can follow the example of the Java implementation here: google/open-location-code#209

Let me know if you have time to do this in the next couple weeks.

Calling C# OpenLocationCode.Encode with length 2 fails with 'System.ArgumentException: Illegal code length 2.'.
I am using NuGet package OpenLocationCode by Jon McPherson, v2.1.0
This is for both GeoPoint and lat/long.
A length of 2 should be valid (https://github.com/google/open-location-code/blob/master/docs/specification.md) giving a 'box' 20 degrees across.
My test code is

    [TestMethod]
    public void UT_HD0099_Encode_LL()
    {
        string res;
        res = Google.OpenLocationCode.OpenLocationCode.Encode(12.123456789, 123.123456789, 11);
        Assert.AreEqual("7Q4544FF+99P", res);
        res = Google.OpenLocationCode.OpenLocationCode.Encode(12.123, 123.123, 4);
        Assert.AreEqual("7Q450000+", res);
        res = Google.OpenLocationCode.OpenLocationCode.Encode(12.123, 123.123, 2);
        Assert.AreEqual("7Q000000+", res);
    }

Is there a way to include the Locality with this solution.

The implementation works excellent with proper Plus Codes, ie: "5G3CQ877+X8", converts beautifully to a workable location.
However, when I try to process another Plus Code like this: "Q877+X8 Bethlehem" (Which translates to the same location), I receive an Exception Error, which I understand happens and why it happens.

How does one convert the "Bethlehem" to the pre-code of "5G3C" in this example?

Regards
Borriez

It appears the NuGet package has debug dll in the release folder.

In order to improve consumption of the library by .NET developers, I'd suggest that a few methods should be converted to properties. This is a breaking change and should be undertaken before the OLC library gets a too wide use.

Hello from the main Open Location Code repo!

We're currently working on fixing floating point precision issues with the various implementations (see here). For the implementations not directly in the main repo, we're asking for the owners to update their code accordingly. Would you be able to do the following when you get a chance?

1. Run the new test cases in test_data/encoding.csv.
2. If they fail, fix your implementation to properly handle the floating point precision issues. I'll post again when we have a commit that you can use for reference.

How should the coordinates be represented? Either stick to decimal or to double...

• The public API of OpenLocationCode is based on double for the coordinates, yet
  some computations are based on decimal.
• The CodeArea constructor expects decimal as its input arguments, yet all its properties
  are of type double.

As the precision of the encoded coordinates is limited, I don't feel that using the more
precise decimal representation useful in this library. I'd stick to double.