Suggestion for Airport Information Pages

[Miguel Albano]

Hi Team,

I had an idea today that I thought I might share, for what it's worth.

How about creating a basic microsite who's single role is to redirect pilots to the respective pages at the regional websites.

Pilot goes to https://airports.vatsim.net/EPWA and it automatically redirects to https://pl-vacc.org.pl/airports/epwa.php

Redirects could be registered and managed by the regional vACC teams.

Why? Helps pilots access useful information sources through direct links (which can later be integrated with other external tools (simbrief, for example) without having them go through different steps.

Just food for thought. Could use some further debating to even understand if a) it could become a relevant tool and b) could be easily implemented (and not just another burden).

 

PS: If this is wrong forum to post, let me know.

[Nestor Perez]

We might be able to integrate that in one of the projects we're working on currently 🤔

[Javier Larroulet]

4 hours ago, Miguel Albano said:

Just food for thought. Could use some further debating to even understand if a) it could become a relevant tool and b) could be easily implemented (and not just another burden).

 

As for ease of implementation, I believe an MVP (minimum viable product) qualifies as very easy...

For instance, I already have a list of approximately 5900 airports, each linked to the FIR code that covers it. That's complemented by a list or nearly 400 FIRs. All it would take would be to go through those 400 FIR codes and add a new "country" parameter for each one, and have a third list with a relation of country->website, which could take a couple of hours to build... after that, you'd input an airport ICAO and would get a country name and local website in response. 

I cannot speak for the development agenda/backlog/priorities Vatsim has, but speaking solely in terms of effort once a task like this got to the top of the to-do list, a basic MVP could be ready within the day.

[Nestor Perez]

All the projects I'm involved in take very long. Not because I'm a bullsh*t dev (which I probably am anyway), but because I don't really support MVPs. Generally I prefer to take longer, but in the end come up with something very complete that makes everyone hyped and happy. 🙃

[Javier Larroulet]

1 hour ago, Nestor Perez said:

All the projects I'm involved in take very long. Not because I'm a bullsh*t dev (which I probably am anyway), but because I don't really support MVPs. Generally I prefer to take longer, but in the end come up with something very complete that makes everyone hyped and happy. 🙃

... which is a valid approach, of course. There's two schools of thought here (not intending to start a holy war over this).. The traditional development approach of analize-estimate-schedule-develop-test-fix-retest-deliver-end and the more modern/agile approach the considers a product as an ever-evolving entity that is never actually finished and that can make everyone hyped lots of times (one per each value-adding delivery)

I personally believe that neither approach is entirely correct or incorrect. But I do believe that some projects (regardless of how big or small they are) benefit from agility and smaller frequent/atomic deliveries and others benefit from a unique delivery

.. but that is a discussion that I'd enjoy much more over beers or coffee

[Nestor Perez]

Haha, indeed! My approach is a mix of both: Analize-estimate-schedule-develop-test-fix-retest-deliver-end, and then, make it open source and leave everyone to contribute at their own will, leaving it as an ever-evolving entity. Couldn't decide on either, so why not take both approaches at once 😛

Edited April 23, 2020 at 12:48 AM by Nestor Perez

[Javier Larroulet]

Haha agreed... open sourcing most of our code should be mandatory (unless there's IP issues). I'm stuck developing proprietary stuff so I cannot release any of it (except non-core stuff that can be used and reused for other purposes such as payment gateway integrations and stuff like that)

that said, no one in his/her right mind would ever clone one of my repos... I really am a s***** dev 😆

[Daniel Lange]

I like this idea. I disagree with Nestor about MVPs. MVPs are a perfect way to create some shit code and test the need and usage of such service. You'd rather use one evening on creating this, and then see how it performs. If it ends up to be scrapped two months later, you still just lost one evening, instead of hyping a whole community, using weeks on the development and then find out you didn't cover any needs and it ends up not being used.

With that being said, I guess a discussion and perhaps just a short survey for existing vACCs would be a place to start, to get an indication if it's needed.

My first question is if this kind of service would be really used. My hypothesis is that people just use this in case of major events to get a recap (if it even exists), otherwise just use Navigraph etc.

[Andreas Fuchs]

First of all we need a central VATSIM database with all airports, ATC-stations, sector-data etc.. so we stop having a biiiiiiiiiig mess of different "display-tools" with outdated airspace and ATC-station information. One insider told me this week that it is being worked on, but not as a MVP 😄

[Miguel Albano]

Oh wow, I was not expecting this to get any feedback soon, but I really appreciate the comments. Seems that some ideas do have some purpose.

Now, I'm not a developer by any means, so I cannot really help in that way. But if there's need on the Project Management side of things, let me know how I can help.

[Javier Larroulet]

5 hours ago, Andreas Fuchs said:

First of all we need a central VATSIM database with all airports, ATC-stations, sector-data etc.. so we stop having a biiiiiiiiiig mess of different "display-tools" with outdated airspace and ATC-station information.

agreed.

For the purposes of Miguel's idea, we wouldn't need ATC stations, sector data, etc... only airports-firs-countries. But even that is a challenge to have as a central database. Building it may not be a huge deal, but maintaining it and keeping it updated is

We could have it as a sort of git repo and base it on pull requests (allowing each country or each division's IT people to submit pull requests to keep the amount of contributors under control), but even then, someone would need to go through all the pull requests and decide which ones get merged and which ones don't.

In the absence of such central repository, my vACC has locally worked on a snapshot of VATSPY's database which we've been updating (locally) when we encounter missing airports or FIRs. This is far from perfect, but it works for our purposes

 

[Miguel Albano]

Allow me to pitch in, but we can actually make it even simpler.

Since what I'm presenting serves, for now, as a simple purpose, to redirect traffic to the regional websites, you don't actually need a centralized database. One could simply argue that the data quality can be relegated to the regions.

Let's say we start with an empty database of FIRs. Allow the regions to populate their side of the database (git seems interesting) with a basic set of ICAO codes and their unique URLs (this even helps ensure that regions keep updated information on their sites).

Sure, one would want to review each of the URLs to ensure that a) they are available) and b) they are actually serving the purpose and presenting the information required. But I wouldn't even set strict rules on this, for now. At end of the day, if pilots use the link redirection tool, they will be the ones pressing for the quality and freshness of content.

Maybe use some sort of redirection script to keep a tool header where pilots can report links, or even add likes, etc... this would be mostly for a later stage, but would present itself as a social mechanism to enhance content quality.

Would this provide for a global ICAO airport database? No. But for those regions that are more active (and where the data is most critical), it would actually help maintain some sort of databse without a huge central admin burden.