-
Notifications
You must be signed in to change notification settings - Fork 44
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
Comments
I have an option for you that is already done and available. We should talk
soon. Can give DEM and LCP data through WCS/WPS request.
…On Tue, Jul 5, 2022, 13:10 Natalie Wagenbrenner ***@***.***> wrote:
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
<#451>, #395
<#395>, and #452
<#452>. We have a few
different options for where we could host these data.
—
Reply to this email directly, view it on GitHub
<#459>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4G3D6A5DFJV6B54CH2NSTVSSCA5ANCNFSM52XGB6CA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
@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. |
Here is a Wiki for the LandscapeExport service. We can add other layers
that you all need. We need to update the most recent LANDFIRE data but
this should get you started.
https://github.com/alexander-petkov/wfas/wiki/Landscape-export
…On Tue, Jul 5, 2022 at 1:45 PM Natalie Wagenbrenner < ***@***.***> wrote:
@wmjolly <https://github.com/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.
—
Reply to this email directly, view it on GitHub
<#459 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4G3D2ZL7R2DSGW53NTWLTVSSGGHANCNFSM52XGB6CA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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... |
@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. |
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. |
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.
The text was updated successfully, but these errors were encountered: