Track longitudes > 180

[nkiesel]

Hi,

while working on my "track overlay window" pull request I noticed that my test tracks from San Francisco to Monteray had longitude values of around 238 instead of -122. I compensated for this in my pull request in one place (by substracting 360), but that really is a band-aid at best.

This track was produced from weather routing, and I don't have other tracks right now to play around with. So perhaps the problem is in weather routing? Or does OCPN allow these "unusual" longitudes (in which case I have to fix the code that did not like these values)?

[seandepagnier]

The weather routing plugin uses such longitudes internally, but it doesn't bother to normalize them for export. Maybe it should?

These longitudes are allowed by opencpn, and not automatically normalized.. maybe the core program should normalize the longitudes as well.

[rgleason]

The weather routing plugin uses such longitudes internally, but it doesn't bother to normalize them for export. Maybe it should?

These longitudes are allowed by opencpn, and not automatically normalized.. maybe the core program should normalize the longitudes as well.

Yes, agreed here.

There are some of the same kinds of issues with Dashboard Instruments.

See https://opencpn.org/flyspray/index.p...ktype&sort=asc

[nkiesel]

The place my code tripped over was Select::IsSegmentSelected which does simple numeric comparison. I could easily see that there are more such places.

Solution could be to always enforce "normalized" values for coordinates or have some central "is this coordinate in this range" helper and use that everywhere. My guess is that enforcing "normalized" values is the simpler approach because most places already produce them normalized.