Options for improving precision

[mattjohnsonpint]

In #10 we talked about ways to improve precision algorithmically. However, one of the easiest ways we could improve precision is to build the data at a higher geohash precision.

Reference:

• https://en.wikipedia.org/wiki/Geohash#Digits_and_precision_in_km
• https://docs.quadrant.io/quadrant-geohash-algorithm

For this library, the practical options would be:

Level	Grid Area	Error	Data Size
5	≤ 4.89km X 4.89km	±2.4 km	3 MB
6	≤ 1.22km X 0.61km	±0.61 km	18 MB
7	≤ 153m X 153m	±76 m	108 MB

Currently we're using level 5.

[jnyrup]

I really like the idea of having multiple precisions to pick from, as the precision needed is context specific, both in terms of domain and available machine resources.

I guess having multiple nuget packages could create a diamond dependency problem?

Having the data in separate files also let's you dynamically pick one.

[jnyrup]

Another (minor) matter with respect to file size is that as the data is embedded in the dll, i.e. once per TFM, the nuget packages grows by a factor of four.
So increasing the data from 3mb to 18mb, would approximately increase the size of the nuget package by 60 mb (minus some amount of compression).

[mattjohnsonpint]

Sure, but does the package size really matter? The resulting compiled project will only use the ones it targets.

[jnyrup]

It only affects restore time when the package is not in any available nuget cache. And even there it might be insignificant for 60mb.

But a 4*108 mb large nuget package seems very large, at least to me.

[mattjohnsonpint]

True. But that gives me another idea... #56 (comment)

[benberlin7]

I think there should be an easy-to-go setup which does not demand users to think about the geohash precision issue in the first place, so level 5 in the standard procedure is completely fine IMHO. However, it'd be nice to enable experienced users to optionally upgrade the precision of the data if needed.

[mattjohnsonpint]

Another approach I just thought of, would be to put all three data files into a separate folder within the NuGet package. Then a custom MSBuild target could be included in the package that would embed one of the three files into the target assembly at build time. One would control the precision in their csproj, for example:

<PropertyGroup>
    <GeoTimeZonePrecision>7</GeoTimeZonePrecision>
</PropertyGroup>

[jnyrup]

I see some scenarios, where delaying the downloading to build time is not desirable.
E.g. if the files are not cached somewhere, you cannot build if you're offline or if GitHub has an outage.

[AdrianoAE]

Is there any update to this? Having the option to go with the highest precision would be very useful

[mattjohnsonpint]

Sorry, I haven't had time to work on this yet.

[jnyrup]

Anything the community can help with Matt, or do you prefer to play around with it yourself when you find the time?

[Rajesh-Patel-SH]

Seems like a great solution for this problem!