latlong2 expectations

[ThexXTURBOXx]

What do you want implemented?

Sorry for hijacking this issue thread like this, but it's probably best to ask about this publicly.
I have taken over maintenance of the latlong2 package today and would like your opinion on whether you need something changed or whether something does not work correctly and needs fixing in that package.
flutter_map is by far the most popular package depending on it and, thus, it made sense to me to somehow involve you in the process of finalising a stable 1.0.0 release.
jifalops has published version 0.10.0 yesterday (the first update since 2 years) and I pushed a "hotfix" 0.10.1 just a few minutes ago.

TL;DR: Please let me know if you have any wishes/feature requests for latlong2 :)

What other alternatives are available?

No response

Can you provide any other information?

No response

[monsieurtanuki]

Hi @ThexXTURBOXx!

While we're talking about latlong2 and version 0.10.1, I've just realized (flutter/flutter#185676 (comment)) that below 1.0.0, "minor" changes are considered "major", and therefore "breaking". For instance, 0.10.1 doesn't match ^0.9.1.

If I had to answer your initial question quickly, I'd say that we have troubles with "latlong segments" and their direction.
If we go from -179 to 179, does it mean 2 degrees west or 358 degrees east? Should it be latlong2's problem?

I'll have another look at the code and I'll get back to you.

[ThexXTURBOXx]

While we're talking about latlong2 and version 0.10.1, I've just realized (flutter/flutter#185676 (comment)) that below 1.0.0, "minor" changes are considered "major", and therefore "breaking". For instance, 0.10.1 doesn't match ^0.9.1.

I thought that this was common knowledge! But yes, indeed, I personally would have labelled version 0.10.0 rather 0.9.2 as it did not really break anything. Well, the new hashCode could theoretically break stuff, but I doubt it, personally.
"The old maintainer" published version 0.10.0 quickly before they transferred the repo over to my profile.
So - sorry for the troubles here. This will be a lot better when 1.0.0 would eventually be published.

If I had to answer your initial question quickly, I'd say that we have troubles with "latlong segments" and their direction.
If we go from -179 to 179, does it mean 2 degrees west or 358 degrees east? Should it be latlong2's problem?

Thanks for the comment! I see... I will think about whether there is something I could change in latlong2 for this or whether it is only worth some documentation.

I'll have another look at the code and I'll get back to you.

No worries and take your time, please!

Besides: 1.0.0-dev.0 is already published over at pub.dev. It contains a major revamp of the entire codebase with quite a lot of (most likely) breaking changes.
All of them should be fixable through renames, though.
This is just to warn you beforehand already!

[monsieurtanuki]

Thanks for the comment! I see... I will think about whether there is something I could change in latlong2 for this or whether it is only worth some documentation.

It's not a matter of documentation - unless you just mean to say "btw we only support trips from Tokyo to Los Angeles via Europe".

Obviously the problem is not with coordinates, but with list of coordinates.

One way to solve it would be to add an "int worldNumber" field in LatLng. Would start with 0, then - if relevant - would be set to 1 or -1 for the next coordinate (if beyond 180, respectively -180). But that would take extra space for all LatLng objects. Not good.

Another way would be to accept values beyond -180, 180: it wouldn't take more space as there wouldn't be an extra field.

Or create a new LatLngList object, that would help manage that "which world are we talking about?" feature. That wouldn't be a breaking change.

The goal being something like: "I want to list of LatLng without confusion, e.g. to support round the world yacht races".

[JaffaKetchup]

Hey, thanks for opening this, glad to see its still in safe hands!

I would say that I don't think it's for LatLng to care about what 'world' it's in. LatLng is a mathematical library for representation of coordinates that can also do some geographic maths based on coordinates - I don't know how the distance calculations handle 'worlds', but I'm making the probably inaccurate assumption that they assume the shortest path where no heading is provided, and if a heading is provided to get an offset then it should work as expected.
The 'world' is a very flutter_map construct and I don't think we should 'force' down our requirements onto external libraries - we already have LatLngBounds for example.

I could get behind something like LatLngList and a reworked LatLngBounds in the flutter_map core.

[ibrierley]

I guess the ability to have a latlng outside the normal bounds may be within the remit of LatLng2 though ? i.e if its -95,-185 or something, which could give a hint, although maybe a bit hacky ? Also I think previously we've thought it would be useful for different crs's (eg pixel flat game world crs, was it CrsSimple ?) to be able to reuse this in flutter_map (could there be a BoundlessLatLng method that skips the min/max checks?) . I'm a bit out of touch if that's still the case though, or if it would break other stuff!

[monsieurtanuki]

@JaffaKetchup I see things differently, as there are already classes in latlng2, like Path, that definitely would need the concept of world:

class Path<T extends LatLng> {class Path<T extends LatLng> {
 /// Coordinates managed by this class
 final List<T> _coordinates;

 /// For [Distance] calculations
 final Distance _distance = const Distance();

And distances are computed "in a single world":

  double distance(final LatLng p1, final LatLng p2) {
    var a = equatorRadius,
        b = polarRadius,
        f = flattening; // WGS-84 ellipsoid params

    var l = p2.longitudeInRad - p1.longitudeInRad; // <======= here, it's problematic
    var u1 = math.atan((1 - f) * math.tan(p1.latitudeInRad));
    var u2 = math.atan((1 - f) * math.tan(p2.latitudeInRad));

As a "minor breaking change", I would consider a new method called double distanceWestEast(final LatLng west, final LatLng east), where the longitude difference would be computed correctly. Perhaps deprecating distance too.

Perhaps also the concept of addWest and addEast for Path.

To be continued...

That said, the process could be: let's improve things in flutter_map first, then see how relevant that would be in latlong2 too.

[ThexXTURBOXx]

The 'world' is a very flutter_map construct and I don't think we should 'force' down our requirements onto external libraries

Understandable. On the other hand, I also believe that this is something most dependents are somewhat "expecting" from the package.
This is, however, where this (previous) comment kicks in:

One way to solve it would be to add an "int worldNumber" field in LatLng. Would start with 0, then - if relevant - would be set to 1 or -1 for the next coordinate (if beyond 180, respectively -180). But that would take extra space for all LatLng objects. Not good.

Indeed, this was the first thing I was thinking about when thinking through this.
Of course, there could be a subclass for LatLng, which does have that field. But this is not only sub-optimal, but also somehow weird to think about, I believe...

I already thought about improving the current distance function before - by adding a third (optional named) parameter that could be an enum like this:

enum SegmentDirection {
  /// Always picks the shortest angular path. May cross the antimeridian.
  shortestPath,
  /// Always travels eastward (increasing longitude, wrapping at 180).
  eastward,
  /// Always travels westward (decreasing longitude, wrapping at -180).
  westward,
}

Does this make sense? Is there something crucial I am missing?
I should also test how the current approach works with distances that cross either pole and whether something like the enum above would also be needed/useful for those edge cases.

I guess the ability to have a latlng outside the normal bounds may be within the remit of LatLng2 though ?

Yes, version 0.10.0 added a getter LatLng#isValid, which does exactly this. Although, it is not quite correct (IMHO) as it happily accepts both latitude -90 and 90 as valid as well as both longitude -180 and 180.
Hence, there is still some ambiguity for some "evil" inputs.

could there be a BoundlessLatLng method that skips the min/max checks?

0.9.1 should have already removed the assertions two years ago - if there is something which still does not work, please let me know and I will fix it in another interim 0.10.2 release.

[monsieurtanuki]

@ThexXTURBOXx Quickly said: regarding SegmentDirection, you forgot the current behavior, that may be called "lazy" or "greenwich".

[monsieurtanuki]

@ThexXTURBOXx Regarding distances, make sure that limit cases can be asked and do work, like the size of the equator [(0,-180),(0,180)].
Would it make sense to also maintain "strictlyEastward" and "strictlyWestward", in case you want to compute the size of equator with [(0,0),(0,0))?
Instead of numerous "switch", a solution may be to implement just one method in SegmentDirection, called getLongitudeDelta(LatLng latLng1, LatLng latLng2).
Could even be in an abstract class, implemented by SegmentDirection: we'd have the added value of enum and the flexibility of abstract classes. That's only if we want to give developers more flexibility that they probably need, in case they find a new typical case to implement.

[ThexXTURBOXx]

Quickly said: regarding SegmentDirection, you forgot the current behavior, that may be called "lazy" or "greenwich".

True, thank you! Even though, I really like "greenwich", I feel like I should call it "lazy" instead in order to not confuse new users too much...

Regarding distances, make sure that limit cases can be asked and do work, like the size of the equator [(0,-180),(0,180)].

Will do - all of such edge cases will go into the test suite.

Would it make sense to also maintain "strictlyEastward" and "strictlyWestward", in case you want to compute the size of equator with [(0,0),(0,0))?

Also a good idea. I am guessing this indeed makes sense and there is an issue, which is about something similar: ThexXTURBOXx/dart-latlong#17
Even though, it is not really about latlong2, it shows nonetheless that something like this would be nice to have.

Instead of numerous "switch", a solution may be to implement just one method in SegmentDirection, called getLongitudeDelta(LatLng latLng1, LatLng latLng2).
Could even be in an abstract class, implemented by SegmentDirection: we'd have the added value of enum and the flexibility of abstract classes. That's only if we want to give developers more flexibility that they probably need, in case they find a new typical case to implement.

Exactly my thinking. Even though, I will need to also add getLatitudeDelta and some more SegmentDirections since we may also want to support calculating distances from one of the poles around the world to itself again.
This would call for strictlySouthward and strictlyNorthward as well - leading to two additional parameters for the distance function (one for lat, one for lng).