Picture the scenario: You are working with Collector for ArcGIS, but you continue experiencing minor problems with adding points. You give your friendly Esri Support Analyst a call and they begin walking you through some steps to troubleshoot the app. You’re not seeing the options they’re talking about, and it’s getting a little frustrating. If only there was a way to show the Esri Analyst your screen so things could go more smoothly….Well there is! It is possible to share the screen on your iOS and Android devices using Zoom.
Please be aware that iOS 11 or later is required to perform screensharing with Zoom
To screenshare from a Mobile Device with Zoom....
1. Install the Zoom app from the Google or Apple Store on the mobile device
2. Launch the Zoom app > Ignore Sign In/Sign Up and click on "Join a Meeting"
3. You will be prompted for the meeting ID, just as you would on a desktop. Enter the meeting ID provided by the analyst
4. Once you have joined the meeting, things are a little different for beginning the share between Android and iOS
Android: 5a. Tap the black screen once and you will see a toolbar come up from the bottom. Click "Share Content." Click "Allow" if prompted to give the device permissions to share. You are now sharing on an Android device.
iOS (>11 only):
5b. Add Screen Recording to the Control Center > Settings > Control Center > Customize Controls > Add Screen Recording
6. Once Screen Recording is added, swipe up from the bottom of the screen to display the Control Center
7. Tap and HOLD the Screen Record button > A dialogue will pop up to have you switch Screen Recording from Camera Roll to Zoom
8. Start Broadcasting > 3,2,1 countdown will begin and the screenshare will begin after 1.
In a previous blog post, my esteemed colleague and board game nemesis Kelly Gerrow-Wilcox discussed the basics of capturing web traffic in a web browser using the built in browser developer tools. But what about when you’re consuming services in ArcGIS Pro, ArcMap or any other non-browser client? Enter: web traffic capturing tools. There are numerous free tools (such as Fiddler, Wireshark, Charles and others) which allow users to capture web traffic from their computers. This blog will focus on capturing HTTP/HTTPS traffic using Fiddler. I've chosen Fiddler because of its relatively simple interface and broad adoption within Esri Technical Support.
Basics: download, configuration and layout
Fiddler can be downloaded here. After installation, the only critical configuration that needs to occur is to enable it to capture traffic over HTTPS.
With Fiddler open go to Tools > Options
In the pane that opens, check Capture HTTPS CONNTECTs and Decrypt HTTPS traffic. (This allows you to capture any requests sent using HTTPS, which is slowly but inevitably replacing HTTP as the protocol for transferring data across the web).
If it’s necessary to capture network traffic from a mobile device, some extra configuration is required. Both the mobile device and the machine where Fiddler is installed will need to be using the same wifi network. The following documents outline the steps to capture mobile traffic:
The Fiddler application itself is split into two main sections; the Web Sessions list and the…other pane (I couldn’t find an official name so for the purposes of this blog we’ll refer to it as the Details pane).
The Web Sessions pane includes a sequential list of every request sent by the client to a web server. Important information contained here includes:
The type of protocol used (HTTP or HTTPS)
Which server the request was sent to, and the full URL
Note: the columns in the Web Sessions pane can be custom configured by right clicking anywhere in the headers and selecting Customize Columns. Some useful fields to turn on can be:
Overall Elapsed (available under Collection: Session Timers. This is the overall time it takes for the request to be sent and returned)
ClientBeginRequest (available under Collection: Session Timers. This is the time your software first began sending the request, using your computer’s time)
X -HostIP (Select Collection: Session Flags and manually enter in the Header Name. This is the IP address of the server destination of the request)
If you click a single web session, that triggers the Details pane to populate with a wide variety of information for that specific request.
Intermediate: What do these details mean? Do they mean things? Let's find out!
There are numerous tabs in the Details pane. The most useful (for our purposes) are Timeline, Statistics, and Inspectors. The others are all advanced functionality outside of the scope of this blog.
The Statistics and Timeline tabs are both helpful when investigating any performance related issue, for example if a service is taking a long time to load in the Map Viewer. The Timeline tab is useful for identifying which request in a multi-request process is acting as a bottleneck. To utilize the Timeline tab, select multiple requests in the Web Sessions list. The timeline will display the requests in a sequential “cascade” format. Any requests taking an unusually long time will clearly stand out with a significantly longer bar in the timeline.
Statistics displays the exact times every step of the request took, from the client initially making a connection to the last step of the client receiving the response. This breakdown is useful to potentially identifying which step in the process of a single request is acting as a bottleneck. For example, if every step is taking a fraction of a second, but there is a multi-second pause between ServerGotRequest and ServerBeginResponse that would indicate that something on the server side is causing a slowdown.
Lastly, the Inspectors tab is the where the bulk of information is displayed and likely where the vast majority of any troubleshooting will be done. Here is where the curtain is drawn back to reveal the nitty gritty of how applications interact with web services. Inspectors is further divided into two main sections; the Request information (everything related to the request sent by the client) and the Response information (everything related to the response returned by the server). Both divisions have a nearly identical set of subdivisions which display the content of the request/response in different formats. Below are the useful tabs for our purposes:
Headers – A list of additional information that is not part of the main request. This may include information like security/authentication information, the data format of the request or response, the type of client making the request, etc. This is a good place to find an ArcGIS Online token, when relevant.
WebForms (request specific) – Depending on the type of request, this will display a breakdown of each request parameter and the value of that parameter. For example, when submitting a search query this section will display the parameters of the query (like keywords, date ranges, etc).
ImageView (response specific) – If the request is for an image, the ImageView will display the image which is returned. Obviously, this is particularly useful for requests involving tiled services.
Raw – This will display the entire request or response in text format.
JSON – If the request/response includes content in JSON format, this tab displays the content in a more human readable format. This is particularly useful for requests/responses to the REST api of ArcGIS Enterprise servers.
XML – If the request/response includes content in XML format, this tab displays the content in a more human readable format. This is particularly useful for requests/responses to OGC services.
Advanced: That’s great Alan. But what am I supposed to actually do with this information?
How you use network traffic information is going to depend on what you’re trying to learn or solve. Checking network traffic can help identify the where and what of a problem but cannot tell you the solution. This is where your knowledge of your app, your web services and if all else fails, some good old fashioned web searching come into play. Here are a few common examples of ways to isolate the problem you’re facing:
Check the HTTP/HTTPS response code in the Web Sessions pane. Anything that isn’t 200 should be investigated (it might not necessarily be a problem, but it’s worth looking at). Again, here’s a description of what these mean. Even a 200 response could contain error messages or other useful information.
A 304 response from a server will trigger the client (web browser, ArcMap, etc) to use the client’s cache and Fiddler is therefore not actually capturing a complete response from the server. If there is a 304 response on a critically important request, try again either in Incognito mode or clear your client’s cache.
A 401 or 403 response typically mean the server requires some sort of authentication. This would help, for example, identify an unshared feature service in a web map which is shared publicly.
A 504 response typically means something timed out. Use this in conjunction with the Timeline, Statistics and Overall Elapsed column mentioned above to troubleshoot performance issues.
If you can’t find the problematic request, open the Raw, JSON or XML tabs of the response and just scroll through the requests looking for one that returns an error.
Raw, JSON and XML contain the exact same information, just formatted differently.
When errors occur, the error listed in the response may be more detailed than the error provided in the user interface of whichever application was being utilized.
Find a way to ignore irrelevant requests!!
One of the most challenging factors in troubleshooting network traffic is the volume of requests that are sent/and received for even minor actions. Below are strategies to help avoid cluttering your log with unnecessary requests.
Turn off Capture (File > uncheck Capture Traffic) when you know Fiddler’s not capturing relevant information.
Close any browser windows or background processes that don’t need to be running.
If Fiddler is capturing traffic you know is not related to what you’re investigating, Filter it out of the Web Sessions by right clicking a session > Filter > select what session parameter you want to filter.
If you’ve captured a number of requests that you know you don’t need, select and delete them.
Target Fiddler to only capture requests from a single application by clicking the ‘Any Process’ button (next to the small bullseye icon), holding and then releasing your mouse over the application you want to capture from. This would be useful, for example, to capture all traffic coming from ArcMap while ignoring everything that occurs with your browsers.
Once you have isolated the request(s) relevant to the issue you’re investigating, the following tips can help determine what the actual problem is.
If you can isolate the problematic request, consider what is the nature of that request in order to help determine any next steps.
Are ALL requests to the service failing? Perhaps the entire server is down or inaccessible.
It’s possible to resend any requests by right clicking a Web Session > Replay > Reissue and Edit.
This is especially helpful for isolating a specific header or request parameter that might be problematic. Modify the information under WebForms or Headers to see if that fixes the problem you’re encountering or reproduces the problem you’re investigating.
If you have a request that’s succeeding and one that’s failing, copy the headers or WebForms parameters one at a time from the request that’s working to the request that’s failing. Once the request works, you’ve successfully isolated the parameter/header in the requests that’s causing the problem.
It’s possible to send repeated requests by right clicking a Web Session > Replay > Reissue Sequentially.
This is helpful for capturing issues which might be intermittent. Send the request 20 or 30 times automatically and see if hit the issue you’re looking for.
Web service query requests can be viewed in the browser with a user-friendly interface. This allows you to easily tweak and resend requests. To view a query request in the browser:
Right click the query session
Copy > Copy the URL
Paste in a browser window
Change the section in the URL “…f=json…” to “…f=html…”
Click enter to browse to the page
Fiddler and other network capture software are not silver bullets to solve all web traffic related GIS issues, but they are useful tools to help. With a bit of practice, utilizing this type of software can help resolve a wide variety of issues when accessing web services in GIS applications.
Got any good Fiddler (or general network traffic logging) tips? Feel free to leave them in the comments!
Whether you are a new user or a power user of Survey123 for ArcGIS, you know it is an extremely useful and powerful tool for collecting data in a form-based environment. In typical workflows, Survey123 for ArcGIS is used to store a spatial component of your data. In this post, I'll provide a brief introduction for using calculations in Survey123 for ArcGIS to convert decimal degrees (DD) to degrees-minutes-seconds (DMS) and extend the application to better fit all survey requirements.
When we create our surveys in Survey123 Connect, the desktop application, we have the option to choose the display format of the coordinate. We can do this for both the preview map and the detailed map. However, this is solely a display functionality because the data is saved to ArcGIS Online. The default coordinate system for services published by Survey123 is WGS 1984 Web Mercator, meaning all data is saved in DD regardless of how it appears in our map viewer. While DD may look nice and evenly spaced online, we in the GIS world know that this doesn’t always meet every need.
There is no way to change our coordinate system of the data in ArcGIS Online hosted feature services, and the the pulldata(''@geopoint'') function will only capture DD. However, we can take full advantage of the Survey123 for ArcGIS's calculation fields to determine both DMS and decimal minutes (DDM) coordinates for our data. Since we determine DDM and DMS values in our survey, we can create this information on-the-fly and save it into the form response. While this process doesn’t change the coordinate format, you can save valuable time should you need this information.
As these calculations can be quite complex, here's a sample survey that does everything for you! Copy and paste the sections you need to add DDM or DMS values to your survey. On your survey form, a new field depicting the value you want appears. Due to how the application is making these calculations, all our in-between steps appear in the data. Happy survey-ing!Andy S. - Desktop Support Analyst
Interested in deploying a person or crew of workers to edit your authoritative geographic data in the field without needing a connection to the internet? We are too! Collector for ArcGIS is the perfect client for you if your mobile phone or tablet is an iOS, Android, or Windows device.
Collector for ArcGIS is a lightweight native application that makes offline field collection possible with an easy-to-use interface. While usage of the application is simple, there are several deployment options available which can make getting the initial grasp of Collector for ArcGIS somewhat complicated. Below is a list of some helpful tips and tricks to get you offline as quickly and as smoothly as possible.1. Collector for ArcGIS requires a unique identity.
Collector for ArcGIS requires authentication from a 'named user' account within your ArcGIS Online organization or Portal for ArcGIS.. The number of users is determined by the license level of your subscription. Administrators can invite additional users to the organization, or groups can be leveraged to share maps with users from other organizations.
To purchase additional users, contact Esri Customer Services or your Account Manager.Tip: You cannot use a public account to license Collector for ArcGIS.2. Collector for ArcGIS is dependent on a pre-configured web map.
Although you can download the application directly from the App Store, you will not be able to start using the application until a map is authored that contains at least one editing-enabled feature service. If you are the author of the map, it is best to get started by creating a web map in either ArcGIS Online or Portal for ArcGIS.Tip: If it's your first time creating a web map for use with Collector for ArcGIS, familiarize yourself with the following tutorials.3. The web map must be configured for offline use.Services hosted by ArcGIS Online or Portal for ArcGIS:
Tip: To download a web map for offline use, ALL layers in the web map must be confirmed with the sync operation enabled.Trick: In ArcGIS Online or Portal for ArcGIS, you can check your web map for offline use by navigating to the Item Details page of the web map. Additionally, you can check on your device for the option to Download (Android or Windows) or a cloud icon (iOS).4. Synchronize as often as possible. Frequent synchronization reduces the amount of data that gets pushed back to the server at once, which reduces the chance of a synchronization failing.Tip: If you are using ArcGIS for Server and need to synchronize large amounts of data, consider increasing the upload size, which by default is set to 2 GB. You may also need to increase the upload size of your web server to accommodate large synchronizations.5. Use the strongest network connection available. Public WiFi, for example, is not a best practice for synchronizing because you cannot trust the source; the network bandwidth or restrictions may not be capable of processing the request. If possible, synchronize when connected to a trusted source, like the internal WiFi of your organization. Collector for ArcGIS sends 2 MB bundles of data at a time during the synchronization process, so the strength of the network connection becomes more important as the size of the data increases.Tip: If your offline data fails to synchronize successfully the first time, test it again using a different network.Trick: You can configure Collector for ArcGIS to only push edits up to the server when you synchronize, and to not pull down edits made by others while you are offline. This reduces the amount of data transferred, making it faster to share your changes and save on data transfer costs from cellular networks. If the edits being made by others are important to you, leave 'Push Only' synchronization disabled.6. Consider the data. Simply put: the more data, the slower the performance. That being said, sometimes performance decreases are less obvious than just the number of features in the data. For example, the number of fields, relationship classes, the projection, and the visibility scale can all affect performance. If you are looking to improve performance, you can hide fields, ensure the projection of the data matches the basemap, and set a reasonable visibility scale on the data or within the web map.Tip: Keep in mind the number and size of photo attachments that you are collecting. Photo attachments cause the data to expand due to the size of each respective photo. When synchronizing many photos, it is especially important to have a strong network connection.Trick: You can limit the size of photos that you attach to features within Collector for ArcGIS on the Settings page.Tip: The next release of Collector will support new offline settings that authors can adjust in ArcGIS Online on the item properties pages of their web maps. These settings will allow map authors to specify what types of information field workers retrieve from the server for both editable and read-only layers. As a result, workers can sync less data, which can decrease the risk of sync failure.7. Test before deploying to the field! Create a sample web map and try collecting data and synchronizing the edits before taking the map into production. Collector for ArcGIS is supported on iOS, Android, and Windows; you may find that an issue is specific to the hardware or to the operating system of your mobile device. If you are unable to synchronize from your sample map, please contact Esri Technical Support.Related information:
Have you ever wanted to create an empty feature service to use in ArcGIS Online, and found yourself stuck with no easy way to get this done? If you’re asking why in the world anybody would want to do this, this blog may not be for you – but keep reading anyway, because you may find new ways to leverage your ArcGIS Online account!
There are cases where you are planning on going out and collecting data, maybe using the Collector app … the point is, you don’t have any existing features. However, you need to provide the structure and format that field staff, volunteers, or community members use to add data to the feature service.
Since you’re using ArcGIS Online, your natural instinct is to go to the documentation and search for “create empty feature service.” You find a section of documentation called Publish an empty hosted feature layer. Steps 1 and 2 go by quickly - no sweat. But then you get to Step 3 and you can't go forward. You find yourself saying things like, “I don’t have an existing feature layer that is right,” or “this template just doesn’t work at all for what I want to do. It’s going to take way too much time to get this to work. This should be easier. Sigh.”Pssst… Here’s the secret. Every named user for an ArcGIS Online Organization account has access to developers.arcgis.com. Go to the website and sign in from the upper-right corner using your ArcGIS Online Organization username and password. Once signed in, you will see options to the left of your profile. Hover over the options until you see Hosted Data.
My Hosted Data section of developers.arcgis.com
Once in Hosted Data, you will find the answer that you’ve been looking for: a super quick, super simple way to create an empty feature service. Clicking either 'Create a Feature Service' or 'New Feature Service' will launch the same wizard to guide you through the process.
Enter the service’s Title, Description, Geometry Type, and Tags. Also be sure to set the service’s Default Extent.
New Feature Service section of developers.arcgis.com
In Step 2 of the wizard, add the Field Alias, Field Name, and Data Type for each field of the service. Fields can be marked as Required or left as optional.
Create Fields section of developers.arcgis.com
Select the renderer for your new service. Renderers define the visual display of your data when you are using the ArcGIS SDKs as well as how the service will look when initially added to the map viewer. You can override your chosen renderer in the SDKs and map viewer at any time. View this service in the ArcGIS.com map viewer to configure a custom renderer.
Review and publish your service.
Review and Publish service section of developers.arcgis.com
Your service has been published and is ready for data collection. Add it to ArcGIS Online and give it a spin!
Edit empty feature service from developers.arcgis.com in ArcGIS Online
As an ArcGIS Server Support Analyst, I often assist customers with web traffic related incidents. While there are many applications available to monitor and capture web traffic from an internet browser, I have found Fiddler (a popular freeware solution) to be invaluable in troubleshooting web applications that fail to display some or all of a web map.
This works fine on Windows machines where Fiddler can be installed and work with the Windows browsers, but what happens if the web application is being accessed from an iPhone or iPad? Fortunately Fiddler provides an option where it can be installed on another machine and configured as a proxy server to capture the web traffic from these types of mobile devices.
NOTE: This configuration assumes there is a Wi-Fi network available for the connecting mobile device. From this Wi-Fi network, the mobile device needs to be able to communicate with the machine that has Fiddler installed.
To configure Fiddler to capture web traffic from iOS devices, just follow these steps.
Open Fiddler. Click Tools, Fiddler Options...
Select the Connections tab. Fiddler listens on port 88888 by default but can be changed here if needed. Make sure the 'Allow remote computers to connect' option is checked. It is not checked by default.
Click OK. You will need to close and re-open Fiddler for the changes to take effect.
Once Fiddler is re-opened, make sure it is capturing traffic by clicking on File. The Capture Traffic option should have a checkmark next to it. It will also say ‘Capturing’ at the bottom left corner of the Fiddler window.
Now that Fiddler is ready, we need to configure the mobile device to use Fiddler as a proxy server. The following screen-shots are from an iPad but the same concept can be applied to other mobile devices. On the iPad, tap on the Settings icon from the main screen and tap on Wi-Fi. This will display the Wi-Fi network it is currently connected to. Tap on the arrow next to the active Wi-Fi network (as circled below) to get to the details screen.
At the bottom of the network details screen, tap on the 'Manual' button under HTTP Proxy.
Type in the IP address (or hostname) of the machine with Fiddler running and the port number of 8888. This will route all network traffic from the mobile device through Fiddler. Now ArcGIS for iOS can be opened and access to basemaps and map services will be captured.
As an ArcPad Support Analyst, I find myself answering a lot of questions about deploying software to mobile devices. One popular question I often hear is:
"How do I install ArcPad on a mobile device without having to reinstall ArcPad?"
This is usually followed by:
"What elements need to be installed to run ArcPad on a specific mobile device?"
Luckily, there are some simple answers to these frequently asked questions. For the first question, you’re probably familiar with the “Deploy ArcPad on your Mobile Device” option that appears when you’re installing ArcPad on your desktop. This is not the only way to deploy ArcPad to a mobile device. If you already have the ArcPad software installed and registered on your desktop, you can use a tool called the “ArcPad Deployment Manager” to deploy ArcPad to mobile units.
All you have to do is connect your mobile device to a USB port on the computer that has ArcPad installed. This will open communication between the desktop and the mobile device through either Windows ActiveSync (XP) or Windows Mobile Device Center (Win7 & Vista).
Then, all you have to do is activate the “ArcPad Deployment Manager” by navigating to Start > All Programs > ArcGIS > ArcPad (8.0 SP4 or 10.0 SP2) > ArcPad Deployment Manager.
The Deployment Manager will open and this is where you’ll ask yourself “What elements need to be installed to run ArcPad on a specific mobile device?”
After having spent years working with and troubleshooting ArcPad, I have compiled a list (both required and personally recommended) of items that I suggest installing. When making a decision about which items to check off within the ArcPad Deployment Manager, refer to the following illustration:NOTE: If you’re installing a language pack, ArcPad has to be deployed on the device first.