Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Host our own surface data #459

Open
nwagenbrenner opened this issue Jul 5, 2022 · 6 comments
Open

Host our own surface data #459

nwagenbrenner opened this issue Jul 5, 2022 · 6 comments

Comments

@nwagenbrenner
Copy link
Member

We should host our own GMTED, SRTM, and LCP data. We do this already for WindNinja Mobile. We should serve this data up for the desktop app too, at least as a duplicate source. This would help with issues like #451, #395, and #452. We have a few different options for where we could host these data.

@wmjolly
Copy link

wmjolly commented Jul 5, 2022 via email

@nwagenbrenner
Copy link
Member Author

@wmjolly Yes! Are you free to talk sometime this week? Or you can forward instructions for accessing the data and I'll take a look. Thanks.

@wmjolly
Copy link

wmjolly commented Jul 5, 2022 via email

@bnordgren
Copy link

So...spitballing...The obsession with cloud services has driven the Fire Enterprise to pretty much assume there's ubiquitous internet access, which has led most down in the trenches to not even have a Plan B. While this only represents irritating laziness for fire response prep, it makes for irresponsibly inadequate "all-hazards" prep. Behold! Plan B:

I'm looking at uses for TrueNAS Scale on-incident. It's essentially a NAS-centric Linux OS distribution which allows for an "app-store" deployment model, like Synology does. In this case, though, TrueNAS is running a full Kubernetes cluster and apps are deployed by a modified helm chart from a potentially self-hosted (firelab-hosted) repository. Regardless of the "brand" though, an on-site NAS with "app-smarts" provides a means to parse and disseminate data over the LAN with (hopefully) a minimum of setup.

An on-incident NAS running a geoserver instance with access to a metric ton of static data, the ability to serve it over the LAN to ESRI aficionados and an ability to fabricate a landscape file on the fly might support both FBANs/LTANs as well as GISS folk. Maybe couple it with a lightweight web portal that composes the WPS call from clicky-pointy goodness and presents the landscape file download.

Any chance that https://aws.wfas.net/geoserver instance could be containerized or is it pretty deeply "bespoke"? Does it make sense to factor out all the static inputs to our Firelab Family of Apps into something we host at the firelab, but in a way that the ITSS's on various teams can replicate on site easily? Throw in a layer of Topofire and a sprinkle of FSTOPO raters for good measure?

...You know, stage 2 would be to compile Windninja-Mobile-server and deploy it as a NAS app...which could be accessed over the LAN by the smartphone clients...regardless of whether the internet connection has arrived.

D'oh. Scope creep. :) Humblest apologies...

@nwagenbrenner
Copy link
Member Author

@bnordgren Thanks for sharing this. Sounds like an interesting idea and certainly could be useful in some situations. Regarding WindNinja Mobile -- there are non-static inputs too, the primary one being the weather forecast that drives the WindNinja simulation. We pull this from NOMADS, so we can't get totally away from the internet. I'm glad somebody is thinking about these kinds of things though! I'm all for having a store of firelab static products that could be easily replicated/used elsewhere.

@bnordgren
Copy link

Stage 2 was a result of having my typing outpace my well-considered notions. :) Even so, I suspect there would be value in affording the future smartphone client user the opportunity to input domain-averaged or point winds in the no-internet case of a reduced-capacity local server fielding requests in a pinch. Particularly if the local server carried with it all the data it could possibly need (sans the ephemeral-and-fat met data). I'm all about using full-throttle high bandwidth system solutions which can fail gracefully from a multigigabit pipe all the way down to a lookout with an anemometer and a radio, with limited impact to the end user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants