Heather Roberts

Survey123 has come a long way since it was in Beta last year and they have incorporated a lot of the features we've all been asking for. Survey123 is a form-centric data gathering web and mobile tool. When you create a survey, it will create a feature service to capture data entered into the application. What's new is we can now use already existing feature services, and configure the survey questions against the existing fields. An existing survey can also be pointed to a new service layer without needing to recreate it. We can also now edit existing data from already submitted surveys. Existing surveys can be download to the mobile application to your inbox, where you can make edits to previously gathered data and resubmit. These existing surveys can also be filtered using queries to select a subset of surveys to download. Survey123 can also now perform calculations in the form, which allows the calculations to be conducted and populated on the form as data is entered. Hosted feature layer views, new to ArcGIS Online, can now also be used in Survey123.

Some beneficial features have also been added to Open Data sites. Multiple pages can be added to your site as links or buttons. These can be used for separating your data into themes, departments, or issues your organization may be tackling. Also, available now on your site are brand new dynamic statistic cards and chart cards. They are still working on the ability to host images in ArcGIS Online for Open Data without the tokens timing out, and should be available in a future release.

ArcGIS Pro is advancing with leaps and bounds and this is the year of ArcMap Equivalency where they are bringing the functionality of ArcMap and more to that of Pro, with a few exceptions that will come in 2018. One change I am excited about that's coming at 2.0 is multiple instances of the application. This means you can have more than one project open at a time. Feature linked annotation will also be coming with the new release, and we also got to put on 3D glasses to view the new Stereo and Oblique layers. Some mid-term additions planned are the Utility Network and Real-time streaming with GeoEvent Server, and the long-awaited Parcel Fabric will be coming in 2018.

Joel Brown

For me, day three at the dev summit was all about the ArcGIS for JavaScript API build system. This is not the sexiest topic but it is still an important part of releasing a production ready web application. It doesn’t matter how cool the app is, if your code is not optimized to load quickly to provide a good user experience. I want to give a shout out to both the ESRI JS API development team and the professional services folks for presenting on this topic today.

ESRI provides a CDN hosted version of the JS API which is easy to reference and provides great performance. However, many of us at GISinc work in environments where using the CDN is not allowed (e.g., federal contracts) or does not meet the customer requirements for some reason. In these cases, we are left to build and deploy a local copy of the API. The recommended workflow for this use case is to download the ESRI JS API package via bower and run it through the Dojo build system with your code to create a concatenated, minified, and uglified “bundle” that contains everything you need for your JavaScript application. If your code is structured right, the Dojo build system will traverse your AMD module dependency graph and do dead code removal so that only the code you actually use gets added to your production deployment bundle.

So, the above is all well and good but what happens if you already have an existing build system in place that is not using the Dojo build system and you want to start using the ESRI JS API? If you are working with plain old JavaScript, then the easiest path forward is to just run everything through the Dojo build system. This is usually going to work better than trying to push the ESRI JS API through an alternative build system.

Things get a bit more interesting if you are using TypeScript or ES6 with something like webpack. Webpack does not do a great job of building the ESRI JS API. It chokes on references to Dojo loader plugins that are littered through the ESRI source code. The path of least resistance here is to actually exclude the ESRI JS API from your webpack build and run a separate build task that runs the ESRI JS API through the Dojo build system. In this case, you will end up with a separate bundle just for the ESRI JS API. An alternative approach is to use a custom loader library like esri-loader to wrap ESRI JS API modules imports. This will skirt around the above mentioned Dojo loader plugin issue. The primary downside to this approach is that it can be a bit unnatural to write code that uses a custom loader.

Overall, it was nice to see the ESRI folks dedicate so much thought to this topic. With the explosion of available JS frameworks out there it is nice to get some guidance on how to make all of your code work together. The ESRI JS API 4x documentation even has a section dedicated to this topic, so check it out if you are looking for more info.

Patrick Scanlon

Today ESRI gave us some best practices surrounding GeoEvent server, GeoAnalytics Server, and the spatiotemporal big data store:

  1. The above capitalization was not a typo; ESRI keeps the spatiotemporal big data store in all lowercase to indicate that they consider it a component of ArcGIS Enterprise, therefore you can scale it to as many nodes as you want without incurring additional licensing costs. Keep that in mind as you consider the architecture of your ArcGIS Enterprise deployment.
  2. Each should be installed on a dedicated box, and if possible GeoAnalytics Server and the spatiotemporal big data store should be installed on clusters of three nodes each.
  3. Many have wondered whether it is better to have fewer but more complex GeoEvent servers or a larger number of more simple servers. Unfortunately, the least satisfying answer to any question, "It depends", applies in this case. ESRI recommends trying both and seeing which works better for your particular circumstances.
  4. GeoEvent Server clustering is brittle and difficult to maintain. ESRI recommends that you avoid clustering GeoEvent Server for now; in 10.6 they plan to split out the Connection and Event Hub elements of GeoEvent Server which will make clustering a lot simpler.
  5. Make sure you have the same number of GeoAnalytics Server nodes as spatiotemporal big data store nodes. The GeoAnalytics Server works by breaking up the analysis task into chunks and running them on multiple nodes in parallel and having the same number of nodes is the only way to ensure that there are no idle nodes while a GeoAnalytics job is in progress.

Look for more minimum requirements here.

Earlier this morning, Daniel Fenton showed off Koop, an open source, self-contained Node web application for consuming data from non-geographic third party APIs and making them available as GeoServices. More info here.

Later in the day, Rahit Singh showed off how to use GeoAnalytics server via the ArcGIS Python API, and even mixed in some machine learning to do predictive analysis on the results, courtesy of scikit-learn.

George Bochenek was back, this time with Randy Jones, to demonstrate how to set up a build process for your JSAPI application and optimize for the fastest possible load time. They recommended:

  1. GZipping your application, along with the associated change to your web server, which will save time transmitting it to the client
  2. Minify CSS, JS and HTML
  3. Shrink images to the size you are actually using.
  4. Configure your web server to utilize browser caching.
  5. Only synchronously load the bare minimum resources necessary. Add the “async” attribute to any script tags you know will take a long time to download so the browser can start rendering the page while it waits.
  6. Google Pagespeed can give you some good tips on how to speed up your web page.
  7. Running dojo build from the command line is cumbersome and error-prone. Consider grunt-dojo.
  8. They have a dedicated tool for building a Web AppBuilder application here.

Dan Huber

Today’s sessions were a pretty eclectic mix that covered everything from cloud hosting in Azure, all the cool things you can do with vector tiles, IoT support through GeoEvent and GeoAnalytics Servers coupled with the spatialtemporal data store, meetings with Esri staff on Insights and Big Data, a few ‘Best Practices’, and all capped off with a look at the Road Ahead for ArcGIS Enterprise.

Highlights from the day:

Using the Esri Cloud Builder application, you can easily instantiate new ArcGIS Enterprise servers in the Azure Cloud to support your Development or Production needs. I’m glad I don’t have access to our Azure account because I know I would get in trouble for all the systems I would be spinning up.

Esri has produced a tutorial on how to use Insights for ArcGIS, complete with sample data to help get you going, I now just need to figure out where they are hiding it online.

Setting up the components that make up Esri’s IoT offering can be a resource intensive activity. The spatialtemporal data store provided the biggest sticker show with their 32GB recommended memory requirement. They say you can get away with 16GB, but it’s not recommended.

ArcGIS Enterprise Road Ahead

  • In 10.5.1, Portal will get the Shared Theme for Templates functionality currently available in AGOL, along with the ability to edit related tables from the hosted Web Map.
  • Philip Heede showed off the new Enterprise Builder installer they are working on, which will allow you to create a full stack ArcGIS Enterprise system (portal, web adaptor, server, data store) all through a single install wizard.
  • The team is working to create a new services-based data type to manage all the various types of Utility data.
  • The ArcGIS Python API will gain the ability to manage all components of a traditional stand-alone ArcGIS Server.

Dan Levine

Couple of highlights today for me. I sat in on a demo theatre presentation from the professional services team working on the Virtual Campus tools. They have come a long way in a year and it is pretty exciting. There has been a ton of work in developing best practices, tools, and workflows to support converting CAD and BIM data into usable floor plans in GIS at reasonable scale. They have honed the process for developing navigation networks from the resulting data, so you can fairly easily create navigation routes within a campus. There are some nice standards for styling and publishing campus floor plans and standing them up in some standard Web Viewer Solutions. Esri has clearly invested a great team of time and effort in all this and for those of us in the indoors market it is going to help tremendously.

Another highlight I had today was to get some quality time with Scott Morehouse talking about Virtual Reality and Augmented reality and where we both see it going. I got to show him some of the VR work we have been doing with the Esri ArcGIS for VR Esri Labs prototype tool. I wish I had gotten a picture of him with the VR Goggles on. Opportunity lost. Dang.

Finally, Dodge Ball. We have fielded a team ever since the tournament started 8 years ago. This year was no exception. We made it to the round of 8 for the first time, knocking out a 2 time champion along the way and getting knocked out by another 2 time champion that eventually won the tournament again. It is always a great time to let your competitive juices flow in an athletic competition to break up the brain work we do all week. Very nice touch to have the rest of the party outside, too.

Topics: Tech Blog, Tech Blog, Uncategorized

Posts by Tag

See all

Subscribe Here!