20,741
edits
Canvas tile element: Difference between revisions
Jump to navigation
Jump to search
m
→Problem: https://forum.flightgear.org/viewtopic.php?f=71&t=41271&p=410094#p410094
m (Johan G moved page Canvas Tile Element to Canvas tile element: Sentence case title) |
m (→Problem: https://forum.flightgear.org/viewtopic.php?f=71&t=41271&p=410094#p410094) |
||
| Line 93: | Line 93: | ||
More and more Airports that have different airport data on the FG Map & Route Manager. Route Manager data seems to agree with other map sources like Sky Vector. Does FG Map get updated from independent sources like Sky Vector & others.<ref>https://forum.flightgear.org/viewtopic.php?f=25&t=37589&p=369707#p369705</ref> | More and more Airports that have different airport data on the FG Map & Route Manager. Route Manager data seems to agree with other map sources like Sky Vector. Does FG Map get updated from independent sources like Sky Vector & others.<ref>https://forum.flightgear.org/viewtopic.php?f=25&t=37589&p=369707#p369705</ref> | ||
== Discussion == | |||
Also, relying on external data hasn't always served the project too well - many data sources have disappeared over time, and that even applies to web services | |||
an "offline" layer would be better, in the sense that it will also work for people without having to be online, i.e. it is procedurally created via Nasal/Canvas, and isn't just downloading/displaying external data that may sooner or later get out of date, or become unavailable altogether. | |||
and the fact remains, over the years, many FG related web services and web pages have disappeared on us - thus, adding self-contained functionality that can be used without requiring on external services and without requiring an internet connection, is definitely desirable - as a matter of fact, the FG project has faced more than one crisis due to its reliance an external services for critical infrastructure. | |||
Right now, we are in witnessing another iteration of this, as more and more functionality is added in a manner that basically hard-codes the assumptions that fgfs users always are online, and that it's okay for FG to access web services - this is problematic for a variety of reasons, such as security. The other issue is, FlightGear is getting less and less self-contained that way, because features like Phi or the FG1000 depend on external data sources, that may seize working - even if the underlying web service/API does not go out of business, even just a change in the underlying API/service will cripple older fgfs binaries - so that it's no longer in the hands of the project to determine if a certain binary/set of features is going to work 5 years from now or not. All of which is to say, you certainly didn't "waste" any time here - because your addon will remain available and accessible, and useful, even 5+ years from now - when many current web services (or users) may have "expired" (or moved on...) | |||
Even as we're speaking, there's another discussion taking place on the devel list, about exactly this topic: integration of Navigraph charts and navdb in flight gear. This increasing reliance on external APIs and services means that fgfs binaries shipped now, may no longer be functional in the future - and as a matter of fact, we may be integrating proprietary/commercial services that way, or at least services that may one day become proprietary/commercial | |||
The FG1000 has come a long way already, but I think it is particularly important to also keep the offline use-case in mind (like Thorsten repeatedly mentioned on the devel list and the forum), i.e. offline is equivalent to people behind a low-bandwidth connection, and here relying on TerraSync, package managers, catalog systems and online chart services/web APIs is rather problematic, and it will cripple such fgfs versions for people downloading them years from now, because there are too many hard-coded assumptions about external services that may no longer be available. | |||
Besides, depending on external web-services makes future fgfs releases much less self-contained obviously, just like Thorsten stated originally (imagine downloading fgfs 2018.1 5 years from now - these features won't work at all). | |||
That being said, unless I am missing something (e.g. because there is an explicit exception granting us the corresponding rights), the way we (that is, Phi/fgfs) is making access to their API, also seems very likely to be a violation of their terms of use. Given the legal turmoil surrounding fgmembers, the Honda jet and other controversial developments, I find it a little surprising that we're seeing such features added without clarifying whether a corresponding exemption exists or not (as in, linking to it, and adding it to the commit logs). | |||
Primarily, it's a matter of agreeing that there's a problem and that people need to find a solution, to help determine what's viable - heck, some folks even suggested adding ads to the FlightGear installer/about box to "thank" companies who are sponsoring FlightGear in one way or another. But again, that's been a recurring topic - to some it's acceptable to run google ads on the website, others would rather accept paypal donations, or run crowd funding campaigns. | |||
Either way, the more the FlightGear project is depending on 3rd party services that it itself cannot provide, it will need to figure out how to "scale" (or not ...) | |||
All that being said, I am myself not a huge fan of the increasing reliance on external web services, I consider it hugely problematic, because FlightGear as a project tends to rely on 3rd party resources/services that are no longer under its control. I don't know if you are familiar with the "mapserver debacle", but that was a rather disturbing incident at the time, and it threw back the project considerably, with tons of discussions (for details, refer to the archives). | |||
Thus, I am not overly interested in seeing more web services "embedded" into FlightGear, because I've seen how FlightGear ends up being crippled by such additions, the very instant they disappear (or even just "update"). Some folks have been downloading rather old/outdated FG versions for that reason - since these days, you can no longer assume that a binary/installer downloaded last week will continue to work next month, because we're adding more and more "online functionality". ThorstenR and others also have been sharing their concerns about the whole "being expected to be online" dilemma. | |||
Then again, the osgEarth patches (which still work), do make the same assumption and do fetch the corresponding imagery on demand - which goes to show it can be done, if people care about such functionality. | |||
As others said elsewhere over the years: for the project, the safest option at this point for our charting needs, is taking the atlas/map source code and modernizing that to turn it into a GIS/WMTS plugin - at that point, we can process our own scenery/terrain and create charts, obviously that doesn't fix the photo scenery issue though | |||
Speaking in general, this would be a rather worthwhile direction for the project to take, because we're seeing an increasing reliance on external services/web APIs, so that fgfs versions in the future may use hard-coded dependencies for certain internal functionality - in other words, you may no longer be able to run a 2022.1 binary in 3+ years from now, due to this circumstance. | |||
That also applies already to fgfs instances running on computers that don't have any internet connectivity. | |||
Using the aforementioned approach would make fgfs more self-contained again, and optionally address this external dependency, while also fixing the issue of most charts/maps not really matching fgfs scenery/terrain at all, whereas procedurally generated maps would obviously always be in sync with fgfs scenery. | |||
<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=41271&p=410094#p410094</ref> | |||
== About setPixel() == | == About setPixel() == | ||