Form fields lack description text and examples.

Webapp should fail if airspace class is encountered. Current behavior is to set "null" as airspace class and omit it.

Webapp should fail if airspace class is encountered. Current behavior is to set "null" as airspace class and omit it.

my account was supposedly no longer.
So I created a new account and activated it. A login is not possible.
Please fix it.

I tested the different endpoints.
I noticed that all requests are answered with error 500 or 503.
After several attempts you may get a correct answer.
For 71 airport-requests, only one result was returned with a FeatureList,
the other responses were Error 500 or 503.

This is my Request (The ApiKey was cut off and filled with X):
https://staging.api.openaip.net/api/v2/airports?apiKey=2NaCL8jtkvqdIDlXXXXXXXXXXXXXXXXXXXXXXXX&country=DE&page=1.

In the past (beginning of the year) it worked as expected.
What am I doing wrong?

API Docs missing part that says that API is camelcase and case-sensitiv. Additionally, country codes doc section should be updated that also country codes must be lowercase like 'de'.

Add new airspace types:

• TIZ (Traffic Information Zone)
• TIA (Traffic Information Area)

Both types can be handled like RMZ type.

Add possibility to import a complete airspace dataset from openair text definition.

Move list filter fields into own modal. This makes for a cleaner look and the modal can be made scrollable so that a big amount of filter form fields can be added without cluttering the UI.

I just had a look at the schema definition for Airports and I was a bit astonished to see that Airport\Runway\TrafficCircuit\Type only offers a distinction between glider and powered. At least in germany it is very common that airfields also have distinct traffic circuits for motorized and ultralight traffic, which can be substantially different. It would be nice if such a ultralight category could be added. As an example see attached screen shot. Guess which one is the the ultralight circuit :-)

I would like to check the available countries and then load the data for these countries.
At the moment every country has to be requested and then the error code has to be evaluated.

As an an example:
An endpoint for existing countries would enough:
/countries

Optimal would be 1 endpoint per data basis:
/airports/countries
/airspaces/countries
/navaids/countries

and so on ..

Merge service-providers and core-utils pkgs.

Waypoint title search in list view is broken. Wildcard search with single char working, multiple char searches do not return a result.

Don't inject authenticated user into context. Instead create from metadata stored in Vuex store which will assure that authUser will always have the correct metadata and tokens set.

Clicking a link in the list view pager will show the paginated list but will drop the currently set filters.

Supported formats:

• GeoJSON
• OpenAIR

API requests like

https://staging.openaip.net/api/airports?version=1.0&country=us
https://staging.openaip.net/api/airports?version=1.0&country=de
https://staging.openaip.net/api/airports?version=1.0&country=fr

which will return a big dataset may respond with a 500 error.

Waypoints should be divided into two main types:

• VFR
• IFR

For first implementation, only VFR waypoints should be allowed since IFR waypoints will implicitly require IFR routes to be linked to the specific IFR waypoints.