GliderGeek
commented
5 years ago interesting thought. as i am super annoyed by all the GUI problems, i was already thinking about converting pysoar to a web application. this also enables to apply caching on previously analyzed competition days. will keep this in mind.
with respect to pysoar as a REST API: i am not so sure if opensoar (foundation of pysoar) is the right code for the job. python is inherently slow and i never spent effort on making it fast. furthermore there are projects for igc parsing which are written in rust and thus a lot more performant. maybe those are interesting for you?
implementing the pysoar logic in your own application should be quite easy. the bulk of the functionality is lifted out into the opensoar package, which is available on pypi. pysoar mainly adds the gui and some simple performance sums.
anyhow: nice plans, i am interested to hear more if you start developing on this.
jvanakker
Not sure if this the right place to post, but anyway: Last night I was thinking, it would be nice if the PySoar analysis would run as a public JSON/Rest webservice that you can feed with a soaringspot link (or an individual IGC), where it returns the data (which is now in the spreadsheet) in JSON format. Maybe different endpoints for different analysis data.
I'm working on a way to quickly compare multiple flights on a map, with IGC's from soaring spot, as an iOS (and macOS) application. So for something like this, the addition of analysis obtained through a webservice would be great of course. This way, any other application could use PySoar while you can optimize/change the analysis it without the applications needing to change.
Just a quick idea, haven't considered yet how feasible this would be in terms of server load, etc. Or of course if it's more efficient to just integrate the analysis into the application itself instead of using a webservice.