Acces to ArcGIS Online Resources in Emergency Situations

[deleted-user-t3dSviijg-m9]

Hello... I am quite familiar with the majority of ESRI's software, but now am venturing into a somewhat unfamiliar territory that is Emergency Operations. My biggest question I suppose is, how are other municipalities that utilize ArcGIS Online and Emergency Response Solutions accessing the resources provided by ESRI during a major natural disaster, such as a hurricane. 

We are in Florida, and hurricanes are unfortunately a regular occurrence between July-October. If we lose internet capabilities, our internal network will be fine and operational; But if we are utilizing some of the solutions provided, we rely on access to ArcGIS Online, as well as the Javascript API that the applications are constructed upon, which is hosted by ESRI. If we go "black" so to speak, and are disconnected from the outside world, wouldn't that render a lot of these solutions useless, unless you have a contingency plan such as cellular data or possible satellite data as a back-up mode of communication to ESRI's servers?

I know you can host your ArcGIS Online apps locally, but those HTML/Javascript/and CSS3 files will still be referencing ArcGIS Online web maps, and the Javascript API's used to construct those apps. Does anyone have any suggestions or remarks on how their organization handles this situation?

Thanks!

[deleted-user-t3dSviijg-m9]

Okay, so you guys have Portal within your internal network. It has web maps, web apps, and all of it is referencing a local, downloaded copy of the Javascript API? 

Was it a big pain in the butt after creating all the web maps and apps, to go into their javascript files and change the CDN from ESRI's site, to your local copy? Or when configuring Portal, before creation of any layers, maps, or apps, you can specify for your internal Portal to reference a local copy of the API stored on either your internal web server, or some other web server/fileshare?

[GISSupport3]

Have Portal / IIS / ArcServer / Data Store / SDE (or whatever it is called today) / tile caches etc all in-house.

All the Portal content 'just works' ... Portal includes a local copy of Javascript

Custom maps only require setting two lines Build your first application | Guide | ArcGIS API for JavaScript 3.19 

Change the path to wherever you install the Javascript API

[deleted-user-t3dSviijg-m9]

I didn't realize Portal came with a local copy of Javascript. We essentially have everything we need already to run an install of Portal (IIS, ArcServer, Data Store, Local Cache of aerial imagery for basemaps, and SDE). Just no one has gone down the Portal route before me, and no one has really looked at our EOC, the demands it has on GIS, and the situations we could possibly be in if we lose various amounts of connectivity. Apparantley, the person before me didn't look into the underlying sources and dependencies on outside internet connection that AGOL has.

I will still probably go with a lightweight viewer that has editing capabilities for when we have lost all outside connectivity (we will still have ArcServer, data sources, cache, our domain controllers, active directory, etc). Then when connectivity comes back up, migrate users to ArcGIS Online web apps. 

Then eventually down the road do a full Portal install specifically for our EOC center, once they see the added benefit of giving our GIS dept (which is just me) funds and letting me set up a system the can function in all situations. 

[GISSupport3]

Get the ArcGIS API for JavaScript | Guide | ArcGIS API for JavaScript 3.19 

[deleted-user-t3dSviijg-m9]

I plan to download the API and reference it in a lightweight viewer with editing capabilities for when we have intermitten to sever internet connectivity issues. I might go the full Portal route referencing the API internally further down the road, but I don't know if I have the time or man-power to push out a full Portal install and configuration right now.

At least using a lightweight html viewer for intermittent connectivity, then once connectivity is restored, migrating to our applications that reference web maps in our ArcGIS Online account.

Then maybe for next year in-between hurricane seasons we can put together a plan for migrating to a full Portal initiative for our EOC. 

[GISSupport3]

You would need to purchase all the software, hardware, and named users to run it, and then someone to look after it.

Before that you would need to decide on the architecture:

https://www.esri.com/~/media/Files/Pdfs/products/arcgis-platform/architecting-the-arcgis-platform 

Deployment scenarios—Installation Guides (10.5) | ArcGIS Enterprise 

And before that, just what are the requirements of the organisation.

And that's just the beginning

[deleted-user-t3dSviijg-m9]

We already have 30 AGOL usernames being used by Field Users. An install of ArcGIS Server connected to a Web Server configured with Web Adaptor in our DMZ, secured with our Windows Domain, but using GIS Server authentication. 

I would just install Portal on a second machine inside our network. More than likely pulling from the same ArcGIS Server. Maybe eventually installing a couple more ArcServers for clustering our map services, geoprocessing, and cache... once I assess how much of a load/demand is being put on the system. 

We essentially have all the hardware and software we need to run it currently, and I would be the poor bastard that has to look after everything haha

[SteveCole]

I think you're touching the dark, dirty secret of ESRI's world. They want you to live by the web map but it's soooooo easy to die by it as well. Portal is a locally hosted version of AGOL but, yes, it would still draw upon ESRI's various basemap options for any web maps/apps. Your organization can always look into developing your own basemaps using your local data. This is *A LOT* of work (primarily labelling) but you then have a local basemap that you can still use as long as you have network connectivity within your organization.

My organization is trying to also have local RAID drives of our various datasets & orthos so we can still function should we lose total network connectivity.  I guess a take home would be yes- go ahead and utilize ESRI's tools/apps for Emergency Management but also have a backup in the way of offline local copies of your data along with MXD map templates that address what concerns you may face,

Steve

[deleted-user-t3dSviijg-m9]

We use all of our own basemaps, namely a simple basemap like the the open streets basemap, as well as several image services that are cached aerials that we host internally and serve up through our ArcGIS Server. So if we lost connectivity to the outside world, we still could consume aerial basemaps through our ArcGIS Server. 

I'm wondering if, when Portal is installed.... underneath the web maps and web apps, isn't the driving factor still ESRI's javascript API? Yes Portal is an internal AGOL, but because it is internal, doesn't mean it isn't accessing and consuming ESRI resources such as the API used to construct the internal applications. I don't know if I'm explaining my thought process clearly or not. 

Basically, if I have Portal, and everything is from my ArcGIS Server. If we lose complete internet connectivity to the outside world, would all of those maps and apps fail to work because they need a connection to the Javascript API on ESRI's servers that was used to build/configure them? Or does Portal somehow come with a local copy of the API and all maps and apps reference that API, which gets updated automatically, so when internet connectivity gets lost, the maps and apps are still being driven by an internal API, and are thus.... fully functional.

[SteveCole]

I'm afraid that I don't know the answer to those questions. I'm on the end user side of the equation so I don't know the details of what's happening under the hood. We haven't really quite jumped in with AGOL or Portal just yet. I've never been much of a fan of AGOL since we pay for an enterprise license of Server so why pay more for something we can (technically) host ourselves with Portal?

I've also become quite jaded about webmaps because the Flood Warning Application I developed using the Javascript API has been a failure when it's been needed most. The problem has not been with the code; it's been the hardware & infrastructure we have around it. We simply cannot support a high demand application and I don't have much hope that we will make the changes that are needed. From the perspective of failure, I'm now much more an advocate of being prepared to work in an offline environment.