Extension of Observer class

[ebraminio]

Just was wondering will it in the scope of this library to provide more aviation related utilities in its Observer object or goes really out of the scope that's why I've opened this as a discussion:

See for example

https://github.com/persian-calendar/persian-calendar/blob/03e4328/PersianCalendar/src/main/kotlin/com/cepmuvakkit/times/posAlgo/EarthPosition.kt

timezone: Double = round(longitude / 15.0) roughly timezone of the place, not used particularly in my use.

Observer.toEarthHeading(target: Observer): (angle: Double, distanceKm: Double) calculates shortest path between two points which initially was provided by https://web.archive.org/web/20161209044600/http://williams.best.vwh.net/avform.htm

intermediatePoints(target: EarthPosition, pointsCount: Int): List<EarthPosition>: Calculates points between two points, see JavaScript implementation behind ths page https://www.movable-type.co.uk/scripts/latlong.html class LatLonSpherical { and other things it provides.

Just to note the last two makes Observer dependent to earth in particular which I don't if it the already assumption or not.

rectangularBoundsOfRadius: not particularly used in my project but I needed it somewhere OSM related. See also https://github.com/openstreetmap/openstreetmap-website/blob/e72acac/lib/osm.rb#L452

Just to note, my implementation just works fine but I was thinking to move these logics to more related and better maintained place, so. Thanks!

[cosinekitty]

When this project started in 2019, I thought about adding support for time zones, but reading about it, I quickly realized the geographic boundaries and daylight time rules are extremely complicated, and additionally, governments frequently change the rules.

I know what you are asking for is very simple (divide by 15), but I also know what will happen if I add that. People will see "time zone" in the documentation. Then they will use it and they will never stop complaining because it doesn't do what they want! I decided long ago it's better to declare time zones out of scope for Astronomy Engine. Every operating system and programming language has existing functionality for calculating local times, and I don't want this project to get tangled up with that.

The Earth heading stuff is interesting, and I need to think about it more. As you know, I already provide WGS84 geoid calculations: converting Vector to Observer and Observer to Vector. My first feeling is to avoid too many cartographic functions, because it starts to drift away from my main goal.

One note about the link you provided: those functions are assuming spherical Earth, whereas WGS84 calculates the true shape of the Earth's sea level geoid. It would be interesting to create a WGS84 version of that function. A collection of these kind of functions might make a good GitHub repo of its own, not part of Astronomy Engine. (Call it Cartography Engine?) We would need to find reliable test data to verify it.

[ebraminio]

Awesome! Thank you very much :)