tilblechschmidt / elsa Goto Github PK

Currently, the page does not work in ~50% of page loads because the rendered component attempts to render localised text even though the locale has not been loaded yet.

Maybe by giving the closest locations range under the cursor an outline stroke.

*sigh*

When clearing the localStorage and then going through the guide, the riskFactors page crashes because it attempts to display the default/current preferences. However, as a new user, the localStorage contains null until you open up the map.

Ideally, the default values should be extracted from the Rust side of things and put into JS together with a lot of other "magic values". That way, the localStorage can be initialised with the default values from the get-go.

Here is the list of languages we would like to support at this stage:

• English
• German

Put a conclusion page at the end of the guide. Along the lines of "hope you enjoyed the guide and make good use of the tool — you can reach out here"

It should be disabled until the user completed the guide once.

Currently, every location is at 42ft 😆

Either collect data by looking at publicly available height data (see #1) or by visiting each field with a calibrated altimeter (ehr, nope). Its your choice really ^^

Currently, the guide does not mention that the aircraft landing performance numbers include a 50ft obstacle at the approach end (as per POH). It is debatable whether this should be mentioned as it provides some unknown safety headroom (which is always useful to have in an emergency) and telling the user might lead to under-estimation of the risk involved along the lines of "pah, it calculates with 50ft headroom but that tree is only 5ft tall so I totally don't need that much runway and can get away with -30% landing headroom". On the other hand, we kinda cheat the user by providing "wrong"/unclear numbers which might reduce trust into the tool.

Thoughts, @AndreV93 ?

The guide currently explains the data source and simulation limitations. However, it does not explain the tools/views available and how data is displayed. Ideally, at the end of the guide there should be one page for each view explaining the details, how it presents data, and what it should be used for.

Its a big epic one! Split the damn thing up and plan the scope.

Users should have read the guide before being able to access the tool. Additionally, when opening a link and getting redirected to the guide, the original location should be restored.

When filtering reachable locations, the field elevation is not taken into consideration at all. While the error is reasonably small at less than 100ft in the HH region, it is a critical error which causes wrong indications!

This page provides a lot of valuable insights for conducting water landings. However, it is served over an insecure connection, displays advertisements, has a pretty illegible font-size, and uses some ugly styles. While I generally advocate sending people to the original source, I'd consider this an exception and would recommend integrating their text or at least the information from it into E.L.S.A.

The content should be linked to from the Risk factors page of the guide. It should reference the original source.

http://www.pilotfriend.com/safe/safety/ditching.htm

At the end of the guide there should be a page referencing additional "good to know" pages like the content from #5 and external resources. These should open in a new tab and have their own TOC section.

It should redirect to the feature added by #9 😉

The location cards currently only indicate the risk level. However, they do not indicate which factors contributed to this result. Ideally, all relevant values and their respective risk classification should be indicated e.g. by changing the font color of the value.

Discussion from #1. As it currently takes in the order of milliseconds to calculate the full profile, it might actually be viable to take the field elevation into account.

Check how much of a practical performance penalty the field elevation would produce (theoretically it is pretty high).

There is currently no way for users to reach us or even discover who built this grandios tool. Change that!

Maybe add a general red, dashed overlay within the critical area in the non-covered areas. Although lower opacity so it is distinguishable from the red location areas.

Most locations currently on the map have been chosen based on well known characteristics or based on satellite pictures. Not really reliable and safe if you ask me. Go to each location, review its viability and take some pictures (preferable aerial ones!) 🙂

When e.g. trying to interact with the altitude slider on the iPad the page starts scrolling thanks to the vertical bounce. This should be prevented so the sliders are easier to use.

When using a bogus link (anything where the locationID is non-existent) the tool gets stuck. Instead it should smoothly fall back and just redirect to /map/location

When sending someone new a direct-link to the guide, that user then reads that one page, and finally clicks on the map icon, he gets redirected to the map which shows the safety info modal. When completing that, a redirect to the guide happens. However, the user might have already seen/read the full guide. We just don't know.

Question arises: Is this intended behaviour or should the user not be redirected in that case?

The easiest one is ForeFlight where you can import ContentPacks containing shapes and such.

The following content comes to mind:

• Ditching in water #2
• Steeper turns are more efficient
  • Tradeoff between increased stall speed / chance of stall and turn efficiency — see this StackExchange answer
• Startle factor and imperfect technique is highly relevant
  • Maybe provide some direct examples where this had an effect?
• Impossible turn and crossing runways

While the LGV satellite imagery is normalised and looks pretty good, it does not provide information for regions outside the HH jurisdiction. Ideally, we should fall-back to some other source that provides global data.

Duh.

Something based on these pictures/prototypes comes to mind:

Basically a map that covers the whole country but adds ranges around each airport. For high-altitude (relatively speaking) cross-country planning 🙂

Problem with this is the sheer amount of data that would need to be processed.