2022 Workshop Q&A: Responses to “Arrow GNSS and ArcGIS Field Maps” Questions (Part 1)

Questions and Answers from “Arrow GNSS with Esri ArcGIS Field Maps,” an Eos workshop with special guest Doug Morgenthaler from Esri

On October 18, 2022, Eos hosted a workshop, “Eos Arrow GNSS and Esri ArcGIS^® Field Maps (2022 Live Training),” with Esri. The workshop included an overview of GNSS, a history and roadmap of ArcGIS Field Maps from Esri guest Doug Morgenthaler, indoor and outdoor demonstrations, and a Q&A wrap-up.

Below is part one of the Q&A. These questions were answered live during the workshop. For part two, which includes questions that were answered in writing following the workshop, click here.

(Please use a work-domain email address, or there might be a delay or issue with providing you the recording.)

Below is a copy of the questions asked and answered live. In some cases, questions that required further clarification are not included.

Q&A (Part 1 of 2)

1. Eos GNSS Questions

1.1 CARLOS: How can I find out about the RTK services that are available in my region?

SARAH (Eos Positioning Systems): Carlos, since RTK varies by region, we recommend contacting Eos so that we can connect you to a local representative who knows all the options that are available in your area. I will put a link in the chat to our contact form.

1.2 BERKLEY: How close is estimated accuracy to the real accuracy?

JEAN-YVES (Eos): Providing estimated accuracy relies on many factors. For example, you have the factor of multipath—multipath is when part of the sky is obstructed, meaning signals bounce off buildings, trees, and other obstructions. So, the signal is not coming in a direct line from the satellite. You also have the factor of the differential corrections. The receiver is computing a lot of math and statistics, it’s filtering errors, and so on. When you’re using RTK, you have a third factor of your baseline level. So, your receiver is trying its best to deal with all of these, and other, factors in real time.

In general, you can assume that your estimated accuracy is very indicative of your real accuracy, but real accuracy will always be impacted by these types of factors introducing some error in the field.

1.3 BOGDAN: Jean-Yves, are all of the Arrow receivers dual-frequency receivers?

JEAN-YVES: No. For example, the Arrow 100^® is a single-frequency receiver, with worldwide constellations including GPS, GLONASS, Galileo, and BeiDou. So, all these constellations use one signal. You could technically do carrier-phase with single-frequency RTK, but this is not productive compared to when you have multiple frequencies.

By contrast, the Arrow Gold^® uses three frequencies. So when you’re doing RTK, your RTK solution is almost instantaneous. Additionally, the Arrow Gold+^™ is what we call a “full-band” receiver. It supports all the possible signals that those satellites are sending, and it’s also ready for a new Galileo High-Accuracy Service (HAS) that will be broadcast in a couple of years over the E-6 frequency.

In a nutshell, the single-frequency receivers are intended mainly for submeter work. The multi-frequency receivers, like the triple-frequency Arrow Gold and full-band Arrow Gold+, are really intended for high-accuracy and high-productivity RTK. So, all our Arrow receivers are different, and we would recommend talking with one of our representatives to really understand the number of frequencies that would best support the work you’re trying to do and the differential correction sources you might be interested in using.

1.4 TODD: When using RTK, do you need to average your positions?

TYLER: Averaging positions is up to your personal preference, with some considerations.

The first is time. I prefer not to average just because I’m more interested in productivity than squeezing out the extra few millimeters of accuracy that you might get from averaging. In the interest of saving time—not having to sit there for an extra five to 30 seconds while waiting for each point to average—adds up when you’re capturing hundreds of points per day. But if you are trying to get the absolute highest accuracy possible, then, yes, you can enable averaging. Sometimes people enable averaging because they’re concerned about an anomaly, such as a point that jumps out further than normal. I personally haven’t come across that, so it hasn’t been a big issue.

The other thing to keep in mind is that when you average, you will give up some of the GNSS attributes. What I mean is that there are specific GNSS attribute fields that will be populated when you turn on GPS averaging, but you’ll lose out on some of the others; you won’t be able to capture the number of satellites, for instance. Off the top of my head, I can’t remember the rest, but it’s quite a few that you might want. So those are all things to consider when you’re deciding whether to use averaging.

JEAN-YVES: To Tyler’s point about squeezing those extra millimeters of accuracy out of each point, I think the more important consideration for accuracy is not GPS averaging, but rather making sure your field worker takes the time to level his range pole on the bubble, and to make sure it’s level before they capture the point.

There are only a couple of instances where you really should toggle on GPS averaging. One is when it’s very windy outside, so it’s difficult to maintain the position of the range pole. In that instance, I would recommend averaging for two to five seconds. Going beyond five seconds wouldn’t help.

TYLER: That’s a good point. I would add to that that enabling GPS averaging will give you more bang for your buck if you’re doing submeter data collection. You’ll gain more accuracy from spending the extra time averaging those positions, because a submeter position is already bouncing around relatively more than it would be with RTK.

1.5 STAN: What is the number of positions you would recommend to average? Would you go up to ten?

JEAN-YVES: I would recommend one or two seconds for RTK. As Tyler said, productivity is extremely important. The receiver is already accurate within a centimeter, so going beyond a couple seconds really isn’t going to give you more value for your time.

When you’re dealing with submeter data collection, on the other hand, I would agree with Tyler in theory. However, I would say that GPS averaging is not needed unless you go under canopy. But to be honest with you, the best point you can take under canopy is going to occur if you just walk up to the tree and immediately store a point. Don’t wait there for too long.

If you do decide to stand there and do point averaging, there’s no reason to spend more than 30 to 60 seconds. Because theoretically, you could stay 2 hours, and you’d gain some accuracy, but that workflow is not realistic or practical. The most I’ve seen our customers do under the canopy is sometimes about 30 seconds to one minute.

TYLER: Yeah. I don’t think I’ve seen anybody do over 60 seconds unless they’re doing real, quality testing or trying to set a control point or something like that. I think anything over 60 seconds is definitely a waste of most people’s time. For submeter data collection, I might personally do about 10 seconds, but kind of just depends on my intention.

1.6 LINDA: Sometimes, I am able to collect the X and Y coordinates, but the Z coordinate does not show up in the collection. Any ideas what might be going on?

DOUG: One thing we do occasionally see, and this isn’t with high-accuracy GNSS receivers like the Arrow, is that this happens when using other sources that might be coming from a phone. For example. I know that Apple^® or Android^™ uses a variety of different sources of GPS, but they also use cell towers, Wi-Fi, and even Wi-Fi hotspots to determine a position. In some of these cases, if your position is coming from Wi-Fi or a cell tower, you might not get a Z value. In those cases, you might get only X and Y. But I’ve not seen that scenario with an external GNSS receiver.

TYLER: Yeah. If you’re using an external GNSS receiver, you should be getting elevations every single time. It would be more bizarre if you were getting some features with Z-values and others without. But if you’re just getting X and Y and no Z-value at all, then you should start looking at your layer. First, make sure it is Z-enabled. I’ve come across times where people have sworn that they published a Z-enabled layer, and when I get in there it isn’t Z-enabled.

There is actually an easy way to check that. If you go to the service URL endpoint, there’s a “has z” property. Just double check to make sure that’s set to “true.” Often, that solves this issue. Occasionally, I get a weird case that’s tough to figure out, but it comes down to just having to look through the data. The GNSS metadata fields are invaluable in this case, because we can put ourselves in the shoes of the user when they collected that point and evaluate what might have gone wrong.

But yeah, if you’re not getting them at all, then check the basics first. Check how the layer was set up and how the map was set up. If you’re getting spotty results and you’re not using an external GNSS receiver, then what Doug said would be a good place to look.

1.7 MICHAEL: Tyler, how were you able to get RTK float into the template for ArcGIS Field Maps?

TYLER: That’s a part of the GNSS attribute field. When you use either the ArcGIS Pro tool or the ArcGIS Online tool to add those fields, it adds the domain as well. So, your data is being stored in that field as an integer, as received by the Arrow receiver and ranging from zero to five. Each status is represented in the data field by one of these integers. Those are mapped to names such as “RTK float” (value of 5) and “RTK fixed” (value of 4). So, in this case, when we see “RTK float” in the popup, it just tells us that our data is stored as five. Any time you were in RTK float, your data is stored as a five, and it’ll just display “RTK float” for display-only purposes. I think that answers what’s being asked.

1.8 SCOTT: I created a hosted feature layer to collect ground control points (GCPs) in the field. I used a template from Esri that included all the GNSS metadata fields.  After collecting several points, I downloaded the table as a .csv file from ArcGIS Online. The table contains fields named “Latitude” and “Longitude” but also includes fields called “Lat” and “Lon.” There’s yet another set of fields with the headings “X” and “Y.” These fields all contain slightly different coordinate data. What is the difference between these fields?

TYLER: Keep in mind there are field names, and then there are field aliases, too. So, when you export your file, depending on how you export it, you might see the field alias. The actual name of the GNSS metadata latitude and longitude fields are “ESRIGNSS_LATITUDE” and “ESRIGNSS_LONGITUDE.” Those fields will be there regardless of your export selections. (These are the raw coordinates that come from your receiver.) Now, when you export a layer from ArcGIS Online, it’ll also export the feature geometry in its own column. That’s your X and Y, and your Z if your layer is Z-enabled. These are the actual coordinates that are plotted on the map (note: this will depend on what coordinate system the layer is set to). So those are the two sets of positions or coordinates that I would expect to see.

If there’s another set of lat and long, what that tells me is that probably somebody ran a processing tool on the data to either modify or pull out the X and Y coordinates from the geometry, and then put an attribute table. Otherwise, I can’t think of a reason why there would be three sets of coordinates. Doug, anything to add?

DOUG: No, I think that I think that’s right. And obviously, while that feature service is published, of course as Tyler showed, you can add fields from the attribute table in the map viewer for example, you can run an Arcade or a Python expression to populate that information. So, yes, it could have been that somewhere along the way, someone’s done a that resulted in additional fields.

In fact, something that I have run into quite a bit is when people mix running post-processing tools on an active, published feature layer. For example, back when we would often use the “add X/Y coordinates” on a layer to populate the Z value in the table, they would run the tool on the actual live feature layer—instead of exporting that and then running the tool on it. You can do this, but if you run the tool, then go out in the field and collect more data, those fields will be empty for the new data collected. So, it’s important to kind of keep that straight as well. That may be something that happened in this case. I’m not sure, though.

1.9 STEVE: I have point features in ArcGIS Collector which contain attributes for PDOP, HDOP, fixed time, correction age, satellite numbers, and fixed type. But the attribute fields are not filled with data. Other fields, such as average horizontal accuracy, average position, and standard deviation, are getting filled in. Is there a setting I’m missing in ArcGIS Online or Eos Tools Pro for that missing data to be populated?

TYLER: It sounds like averaging is enabled. And so, as I’ve mentioned earlier, you’re going to lose out on some of the GNSS metadata fields when you’re using averaging. This is because these fields don’t really make sense to average, you know, like the number of satellites. If you’re averaging five positions, you could end up with something like 20.3 satellites, which doesn’t really make a whole lot of sense. The point is that there are some values that don’t jive with an average position, so that’s why they aren’t populated. Also worth noting is that when you do perform averaging, now your points are going to have another set fields, specific to averaging, that aren’t populated when averaging is off. So, it’s just kind of a tradeoff between which GNSS attributes are captured based on whether you are averaging.

1.10 JOHN: I have a project where I am being asked to connect to an NTRIP, but there’s spotty cell coverage, so I fall back on an Atlas^® subscription when cell coverage is dropped. My base map is a tile package in NAD83 (2011), and all of this goes into ArcGIS Field Maps. I do have a time-based correction set up already for ITRF to NAD83 (2011) in the app. Is there anything else that I need to be aware of?

JEAN-YVES: There are two scenarios here. In the case you’re using SBAS, it’s a no brainer, because ArcGIS Field Maps works offline. The Arrow doesn’t need any cell-phone connectivity to get the data from the SBAS satellites, so losing cellular coverage is never an issue for SBAS.

If we’re talking about doing RTK then, assuming you’re using an Arrow Gold, the SafeRTK^® feature will kick in when you are no longer getting RTK corrections via cell service. Now, SafeRTK relies on Atlas^®, which is a satellite-based differential correction service referenced to ITRF datum. So back to our example: You’re receiving RTK corrections in NAD83 when suddenly you lose cell coverage and Atlas kicks in, as SafeRTK engages for up to 20 minutes for free to preserve your accuracy. For these 20 minutes, SafeRTK will maintain the same datum as your RTK, after which point it will fall back to an ITRF datum. If this happens, then suddenly your location profile is no longer the same. This is a problem, so re-establishing connection during that 20-minute window is important. In addition, one thing that we want to build eventually in Eos Tools Pro is the ability to detect a change in the differential correction source being used, to allow the user to account for the change. We hope to have this in the course of 2023.

There’s also a third, less-common scenario. Let’s say you’re using RTK and, again, you lose cellular coverage in a disconnected environment. But, in this scenario, you also happen to have paid for an Atlas H10 subscription. Once you lose cellular coverage, SafeRTK will kick in; for the rest of the day, if you do not power off your receiver, you will not switch datums. Your incoming positioning data will maintain the same NAD83 datum with which you started.

TYLER: My only other input is for the user to consider if they have set up ArcGIS Field Maps to work offline. In this example, it sounds like the person asking the question has a tile package sideloaded onto the device. But to go fully offline, you still need to set up your map for syncing. So, that’s my only other input on that.

JEAN-YVES: I think the problem is mainly the receiver, the coordinates coming in, the locational profile switches.

1.11 MICHAEL: Does RTK rely on satellite constellations or just the base-station signal for positioning?

TYLER: The base station and your rover are both observing satellites in the sky. So, the base station is going to use mostly the same satellites that your rover is using. The difference is that the base station knows precisely where its antenna is. And so, because it knows its antenna location as it’s observing the satellites, it’s able to come up with a correction—the difference between its known location and the location it’s calculating in real time based on atmospheric conditions at its antenna location—which can then be broadcast to the rover and applied as a correctional shift. So RTK is tracking the same GNSS satellites as your rover, calculating a shift, and sending this to your rover. Therefore, your baseline (distance from the rover to the base station) is so important, because the base station is calculating a correction based on the atmospheric conditions around its antenna. In theory, the closer your rover is to your base station, the more similar those atmospheric conditions will be.

1.12 STEVE: When you talked about submeter- and centimeter-level accuracies, are you referring to horizontal positions, vertical positions, or both?

TYLER: We’re usually talking about horizontal. The rule of thumb, in general, is that your vertical accuracy is going to be double your horizontal accuracy. So, if you’re getting one-meter horizontal accuracy, you can expect about two-meter vertical accuracy. It’s not a hard rule, but that’s the rule of thumb. So, in that slide when we categorized receivers by accuracy level, we were referring mostly to horizontal accuracy, but you can derive the vertical accuracy from that.

1.13 CARLOS: Can I use this to improve my client’s location accuracy? For example, if my client provides me location data that is not very accurate, can I use this to update their locations during my team’s inspections?

DOUG: If you have permissions to update the geometry of that layer, then yes, you absolutely can. We see people improving the position of an existing asset as part of a common workflow.

1.14 XIUXIA: Would a cloudy sky affect GPS accuracy? We have a base station on our roof, and we notice differences in accuracy during cloudy days.

JEAN-YVES: Cloudy days will not affect accuracy that much. At different times of the day, you will have different satellites available. But if you have a clear sky today and cloudy skies tomorrow, this atmospheric change will not really disturb the accuracy of your receiver.

What will cause an issue is if you are under light foliage, and the foliage is wet. This creates a blockage of the signals coming in. So that will be the only reason why you’d see differences. Atmospheric conditions are very insignificant unless you have water accumulation somewhere.

TYLER: I agree. If you’re having significant accuracy variations, it’s not due to weather. There is something else to look at.

1.15 CHRIS: Tyler, during your presentation, you stated that higher accuracy could be more expensive. Could you elaborate?

TYLER: In general, when you talk about consumer-grade GPS, you’re talking about hundreds of dollars for a receiver. When you move from that recreational-grade GPS to the submeter level, you’re generally going to have entered the thousands-of-dollars range. That’s because the hardware being used is much better, the algorithms being used and the R&D time that was invested, and the effort it took to come up with that—you know, it costs money.

Now again, when you jump to the centimeter-level-accurate (survey-grade) receivers—the ones that support RTK and so on—you’re going to do another significant jump. In general, we’re talking around the $10,000 level. Now, there’s a lot of “cheap” RTK receivers out there, but there are some things you need to look out for. Jean-Yves talked a little bit earlier about the difference between single-frequency, dual-frequency, triple-frequency, and full-band receivers. There are single-frequency RTK receivers out there selling for hundreds of dollars, probably closer to a thousand, that are enticing because they’re cheap. And, you know, the spec sheet looks good, and it says it does RTK and it gets you centimeter accuracy. Now, that isn’t wrong, but it just can’t get you that level of accuracy reliably and efficiently. For example, when you are out in the field with trees and buildings—things you can’t avoid—you’re probably not going to get RTK in the way you’d like to. Also, the fix times are going to be longer. So be careful looking at the spec sheet, when thinking about what’s possible versus what’s practical for collecting data in the field.

But cost-wise, you’re talking hundreds of dollars for consumer/recreational grade, a thousand to a few thousand for submeter grade, and then approaching closer to $10,000 and even above for RTK-level receivers.

JEAN-YVES: That’s a good explanation. I’ll give just one more interesting example and consideration. In the automotive industry, they are using an RTK chipset, but these are not meant for constant, high-accuracy mapping that people would require for GIS field work.

And sometimes, to make these chipsets even less expensive, they’ll limit the constellations and signals they can use. Going from four to one GNSS constellation, such as just GPS or GLONASS, and to just two signals, such as just L1 and L2 signals, for instance can give you a very cheap price—but at the expense of productivity. So, a lot of what you need to pay depends on your use case. Our colleagues did a study that found productivity goes up by 50% when you go from one GNSS constellation, such as GPS, to two, such as GPS and GLONASS. They found you go up another 50% when you add the Galileo and Beidou constellations. And also, the reliability—for example, you take an Arrow Gold that uses three signals from GPS and three from GLONASS. That’s six signals. You got seven from BeiDou, so that’s 13. And then you add an additional five from Galileo. Now you have 18 different signals to use in the field, which improves both the integrity of your data and your productivity.

So, there are consumer-grade, automotive-grade, and professional-grade levels of GNSS to consider, each with their pros, cons, and price points. The price for Eos receivers, which are all professional grade, varies as you dig in and will range depending on what you want for a receiver. But again, productivity and quality are there.

1.16 WENDY: Going back to that question, Tyler, about the horizontal and vertical precision, would it be safe to say then that we shouldn’t trust the elevation data? The reason I am asking is because we are collecting manhole inverts, and collecting the correct elevation is critical in considering the development of land.

TYLER: I mean, if you know what the situation was when you collected the data—meaning that you know you were connected to an RTK base, you had a good baseline distance, and you had high-quality positions coming from that field effort—then I think you can absolutely trust the elevations. When we’re talking about RTK, your horizontal accuracy can be one or two centimeters, then your vertical accuracy will be two to four centimeters, and that’s in the worst case. So, if that vertical accuracy threshold is within your tolerance, then I think that’s totally okay to trust your elevation data. I would recommend it, in fact.

If you’re doing SBAS, that’s another story. With SBAS, your vertical can be quite a bit further off than half a meter.

1.17 CHRIS: How does the cost of a differential correction source factor into the total cost of GNSS workflows?

TYLER: That’s a good question. The receiver is one cost, and the differential correction source might or might not add an additional cost. Some correction sources are free, like SBAS. But RTK subscriptions could be a separate cost; it totally varies depending on where you’re working. Some state and local governments have free RTK networks in the United States, where I am. For instance, I’m in Oregon, and all I must do to gain access to my local RTK network is simple: I go to a website, sign up, and they send me credentials and information to connect to the network. So, I instantly have free access to hundreds of base stations around the state that I can utilize for centimeter-level accuracy at no extra cost. Other states don’t have a network at all. Some states have a network that’s not available to the public. And others have private networks that you pay pretty good money, sometimes $2,000 a year per user, to access. So that cost can vary a lot.

JEAN-YVES: What Tyler said is correct for how it works in the U.S., and we also see that variation is replicated when you go outside the U.S. internationally. In all cases, the Arrow GNSS receivers will support any SBAS, RTK, or base station correctional source, but the real cost of that will depend on where you’re doing your field work.

Of course, the very first place you should go when you’re looking for RTK-level accuracy for a receiver is a free service. If you look at New York, Florida, and so on—these states have a free RTK network, as Tyler said. And don’t forget that the type of technology these services themselves use can have different GNSS constellation and signal support. The states I just named support more than GPS and GLONASS. Florida and New York, for example, have already implemented Galileo and BeiDou into their state RTK networks, if I’m not mistaken. So, yes, you have productivity as well as zero-cost RTK services there.

We also have a lot of customers that are in regions where they have free RTK networks supporting just the GPS and GLONASS constellations, which was good in the past and will still get the job done; free is a cost you can’t beat, after all. But if the RTK network is free, sometimes the cost of installing your own base station will still make sense. This is typically true in a couple of settings. First of all, if you work in a condition where you’d require more satellites, then installing your own base station that supports four constellations and multiple frequencies and signals could offer a productivity gain, or time savings in the field, that can significantly compensate for the one-time base station expense. Another consideration is the number of receivers you’re trying to connect to a network. Paying $2,000 per year for a single RTK subscription might make the most sense for certain organizations’ budgets. But now if you have three, ten, or even a hundred field workers each with their own receivers that need to be concurrently connected, then installing your own base station makes the most sense, because the annual subscription cost savings could be astronomical. We start to see organizations make this choice as soon as they have more than one receiver in the field, because the cost comparison is something that is very easy to mathematically perform and justify.

There’s always an evaluation to be made, and it depends really on the needs of the customer. That’s why we offer anyone to contact our team, and regardless of whether you purchase an Arrow GNSS receiver, we will be happy to walk you through the differential correction services available in your area, what they cost, and what we would recommend based on the type of work you want to perform.

2. ArcGIS Field Maps Questions

2.1 SAMUEL: Doug, is the setup process in ArcGIS Field Maps any different on an iPad versus an iPhone?

DOUG (Esri): In terms of setting up the location provider, the user experience is the same across iOS. The variance is the same on an Android device, too. And just a reminder, in terms of location profile, those are things you can now set up through the mobile device management (MDM).

2.2 BRIAN: Which MDM software is supported?

DOUG: For ArcGIS Field Maps we’re adhering to what’s termed the “AppConfig” standard community. All of the major MDM vendors support that standard. So, there’s Microsoft Intune, MobileIron, Airwatch—there’s a number of them that we support. I think the most important question is, what is your organization already using? Rather than trying to pair up and match an MDM solution to take advantage of this.

2.3 MELODY: Tyler, you had shown the Arcade expression. Is it necessary to use an Arcade expression if someone specifically adds that field into their attribute table?

TYLER (Eos): Without using any Arcade expressions—assuming that your layer is Z-enabled—ArcGIS Field Maps will store the elevation value in the Z field of your feature, and then it will also store the ellipsoidal elevation value in the ESRIGNSS_ALTITUDE metadata field. Now, if you want the value that’s stored in the Z-value attribute field, you’ll need to use the Arcade expression to do that in real time. You could also do it after the fact, since the data is being stored either way. It’s just that without the Arcade expression, this value won’t be displayed in the pop up by default. That’s the point of the Arcade expressions.

2.4 MATTHEW: Tyler, would you be able to explain again the difference between entering the same Arcade expression in a pop up versus the ArcGIS Field Maps form?

TYLER: Yeah. So, Arcade is just a scripting language that is used to interact with your GIS data. We can use it in in lots of different ways. You can use it in a pop up, for example. You can also use it to change the symbology of your features. You could also use it for field calculations. I’m sure Doug could probably provide other examples, too. But that’s the point of Arcade.

The difference between the two—entering the Arcade expression in a popup versus the form—that I showed is this: The first one we used is simply going to add an attribute expression to the pop up. So, in this case, we pulled the Z-value out of our attribute fields, and we simply displayed it. But say you have two fields or attributes that you’re capturing, and you wanted to add them together or perhaps average them. What you want to see is the calculated result. You could do that in real time by using an Arcade expression in the pop up, but you wouldn’t do this in the stored data. Arcade in this instance is used simply for visualizing this information.

On the other hand, what we did the second time within the ArcGIS Field Maps form builder was different. This time, we used the same Arcade language to do a field calculation in the ArcGIS Field Maps form builder itself. That’s also using Arcade, but it’s using it in a different way—whereas this time we’re querying the GIS data, and we’re storing that resultant value in an existing attribute field. So, using this method, that information gets saved.

The takeaway is that Arcade is a powerful language that can be used in a variety of ways. But where you use it matters, especially when it comes to whether you want to just visualize or store your calculations.

2.5 CHARLES: Everything that was shown today in ArcGIS Online—can that also apply for ArcGIS Enterprise or ArcGIS Portal?

DOUG: Good question. So, yes, it does. I think often people who are using ArcGIS Enterprise with an on-premises deployment find that the current version of ArcGIS Online has capabilities that aren’t yet available in ArcGIS Enterprise, or they aren’t available in the version that they are currently using. So, for example, the calculated expressions that we were just discussing is a capability that’s available in ArcGIS Enterprise 11.

With regards to the ArcGIS Field Maps web application, the capabilities we roll out typically launch first on ArcGIS Online, and then they get picked up in the next ArcGIS Enterprise release. So often, you’re looking at one release behind, which is generally three to six months, before those capabilities come to ArcGIS Enterprise. But taking advantage of these does mean that you will need to keep your Enterprise version updated.

2.6 BILL: Doug, does ArcGIS Field Maps support augmented reality (AR), virtual reality (VR), or 360-viewing?

DOUG: Currently, no, we don’t support any type of viewing like this. Augmented reality is, as you might recall, on our long-term roadmap. We have been doing some research on that area, but it certainly hasn’t made it into the product yet.

I do think that for any future with augmented reality, it is going to be important for the data being used to be accurate, so that the AR can be truly useful. The groundwork being laid now is the initiative we’re seeing to capture accurate, 3D positions. This will really pay off for organizations when we do support AR or VR within ArcGIS Field Maps.

2.7 LINDSAY: Related to that ArcGIS Field Maps roadmap, is a disconnected ArcGIS Utility Network workflow capability on the schedule?

DOUG: It is. Support for the ArcGIS Utility Network, as we mentioned earlier, is currently primarily for a connected workflow. This is for viewing data, tracing, viewing associations, and more. We do have a plan to bring those capabilities to an offline environment, and we are working with other development teams within Esri to do that. I would estimate that that will be coming sometime next year, probably in the second half. It is definitely on our roadmap.

2.8 GERRY: Can ArcGIS Field Maps populate data (about a point) from a related table? For instance, let’s say you’re taking a shot of an existing asset, to update its location.

JEAN-YVES: I think if the GNSS metadata fields were populated, then yes, the coordinates would be populating. But if you need that metadata, you need to have added your GNSS metadata fields.

DOUG: I think you’re right. Ultimately, within ArcGIS Field Maps, every time you’re using the GPS-updated location, or updating GNSS metadata, if there’s a related table involved where you have feature relationships, all that metadata is still tied to that particular feature you’re editing. So, whether that’s a parent or child in the relationship, since you’re updating the geometry within the GPS (or even if you manually update that point), it will clear the metadata attributes. So, it will reflect within Field Maps what was the last position that was used to compute that.

2.9 CHRIS: There is a valve layer in ArcGIS Online which is used to capture valves during our water main replacements. This is the only layer that is not in WGS84 / Web Mercator. When we pull it in through portal from ArcGIS Online to ArcGIS Pro, it says the source coordinate system / plane system is State Plane 5/NAD83, and it re-projects it to WGS84 / Web Mercator—in which all other data and the web map is. We usually re-project all the data to State Plane 5 when everything is complete and constructed, and after lines are built out. Are you saying this shouldn’t affect anything in terms of accuracy and precision?

TYLER: Well, I mean, any transformation is going to have some error, as we’ve discussed earlier. You probably won’t be able to see any error unless you were comparing it at the millimeter level. But yeah, that’s kind of bizarre that there’s just one layer that’s different. Something must have happened there with the workflow, I think.

DOUG: I agree, very odd. But to your point, Tyler, I think it’s also important to recognize that there are transformations between the source data that’s stored in your geo database and this feature service that you publish in the web map. That is also another potential source of transformation that you should be aware of, in addition to the transformation that might happen as data comes in from the GNSS receiver to Field Maps, through a location profile, to the web map, to the feature layer. So, there are a few places just to be mindful of. But that does seem a little bit strange in terms of only having one layer defined as that state plane system.

2.10 PAIGE: Doug, does the ArcGIS Field Maps smart form capabilities have the ability for repeat lines of data to be held within a single point or polygon? For example, I want to do a survey of animals occupying an area. But I’ve got multiple individuals per species occupying my area.

DOUG: Good question. Without knowing all the details here, I do think that yes, you can. What I would imagine is that you would have a related table, and related feature layer if you’re interested in recording the locations of each of those animal observations. You’d have the apparent feature, such as species, and then any feature you would want to collect for the animal observations would be something that you could associate with that apparent feature. You could collect as many of those as is necessary.

TYLER: That’s why I was thinking too. That sounds more like a database design, a schema design issue, than trying to force a smart form to hold all that information, right?

DOUG: We do have just that. As I mentioned earlier, we are continuing to push forward our smart form capabilities. One of the things we are looking at is being able to have an integrated view of parent and child information within the same form, even though they’re going to different tables or different layers. In this case, that’s work that will be coming on the scene next year sometime.

2.11 DUANE: How can I get ArcGIS Collector layers into ArcGIS Field Maps? Is there a configuration that they need to do?

DOUG: So, the good news is you don’t have to do anything. When we first built ArcGIS Field Maps, it was effectively built off Collector’s DNA. So, the code base of Field Maps was effectively that of Collector. That’s where we started. Obviously, we’ve added lots of new capabilities since then. But in effect, if you have a web map and feature layers that you’ve been using successfully in Collector for any period, all you must do is download Field Maps, open Field Maps, and open that same web map in the Field Maps application. You should have all of the same capabilities that you had in Collector. Obviously, at that point, as you add to your web map, you can start taking advantage of some of the newer capabilities Field Maps has that Collector didn’t, like smart forms and geofences. But as is, your web map should work just fine in Field Maps with no changes.

2.12 FRANK: Doug, if someone is using the ArcGIS Field Maps smart forms, is there a way to auto-update an attribute in one point feature from another one based on proximity? For instance, I want to add address information from an address point to an address field in an asset record?

DOUG: So, what smart form and calculated expressions could allow you to do, as you’re updating an asset, is also update its location. What you can do is define an expression that queries those address points to find the nearest address point. And that can change, of course, as you move your location of that asset that you’re updating. And that will update each time that the geometry changes—so it is dynamic, auto-populated, and you don’t have to do anything for that to take effect. But what the smart form calculated expressions can’t do is update a feature that you’re not actively editing or collecting. So, if you’re trying to update a feature that’s nearby with information that you’re capturing now, that isn’t something that’s important. There are other techniques within the ArcGIS system, like attribute rules, that can offer that. Web hooks in particular might be more useful for that scenario.

2.13 MADHU: Is there a navigation feature available in ArcGIS Field Maps?

DOUG: Yes, there are navigation capabilities within Field Maps. So, your workflow would be first to search for a particular asset. When you tap on it, you will get its pop up with a set of actions you can take. If you tap on the compass tool, for instance, it’s going to give you straight-line directions and distance to that asset.

3. Datum Questions

3.1 JIM: Tyler, you had shown a datum transformation. Is the datum transformation exact? Meaning, is there any loss of accuracy with the coordinates from the receiver that are transformed and stored in the layer, or are they as precise?

TYLER: Well, it depends on the transformation. There’s always going to be some amount of error when transforming the coordinates, and it really depends on which transformation you use, or which datum you’re going to and from.

The transformation that I showed today went from NAD83 (2011) to WGS84. Now, while you could probably measure the difference introduced during this transformation, it’s not very noticeable, even at the centimeter level. I don’t have an exact number, but I believe the loss in accuracy is well under a centimeter. But importantly, that’s not going to be the case for all transformations. In fact, there are some transformations where there’s virtually no mathematically accurate way to perform the transformation. That’s a whole subject in itself.

DOUG: To add to that, we (Esri) do publish stated horizontal accuracies for each of the transformations we support. It is something you should be factoring into your thinking as it pertains to your total project requirements, in terms of the absolute accuracy that you’re targeting.

There are some ways to minimize these inaccuracies. When we talked earlier about custom base maps, this is one of the ways you can reduce error from a transformation. For example, if you’re using RTK, then those coordinates are coming in on NAD83 (2011). By publishing a coordinate base map that uses NAD83 (2011), you eliminate the need for a transformation to an Esri base map.

Similarly, when you publish your feature layers, think about what coordinate system they use. Tyler had some good examples earlier. If you can maintain the same coordinate system from the GNSS receiver to the base map to the feature layer storing that data, then you won’t have to worry about accuracy lost from a transformation. It will be verbatim.

JEAN-YVES: One thing also to remember is that when you’re using an Arrow GNSS receiver, the data it provides will match that of your differential correction source. So, for instance, if you’re connected to an RTK network in the United States, most of them will be using NAD83 (2011). On the other hand, if you’re using the Wide Area Augmentation System (WAAS) differential correction source in North America, then the data will come in as ITRF (2014).

But don’t forget that the Esri GNSS attributes you enable (like ESRIGNSS_LATITUDE, ESRIGNSS_LONGITUDE, ESRIGNSS_ALTITUDE) will store the original coordinates that you get from the receiver (compared to what is in the point geometry). So, you have that source of truth saved in your attributes, and this is one of the reasons why capturing those GNSS metadata fields is so important.

As a final thought, I do believe all of this is going to get even better in the U.S. with the new datum coming. We’ll see if we get questions on this.

3.2 CHRISTOPHER: What impact will the new National Geodetic Survey (NGS) datum, soon to be released, have on these settings? Please demystify the upcoming NAD83 upgrade to ITRF.

JEAN-YVES: Recall that a datum is simply a mathematical model that represents an ellipsoid. ITRF is a global datum, whereas NAD83 is a local datum. In the United States, you have NAD83 (2011); in Canada, we have our own local datum, which is called the NAD83 CSRS98 (CSRS stands for Canadian Reference System); and so on. Basically, these datums are all simply mathematical models of an ellipsoid representing the shape of the earth.

The problem with the original datums, like NAD83 (Original) and WGS84 (Original), is that they failed to consider that the earth moves. But, we have tectonic plates, and the crust is constantly moving. So, the powers that be decided to create a datum that considers tectonic plate movements.

Now, the problem with the local datums is that they were not geocentrically defined. The centers of their ellipsoids do not coincide with the center of the earth. This is true for most countries’ local datums, and this creates different instances of the same problem.

So, what the NGS is doing now is attempting to fix this problem with NAD83 by creating a local datum that follows the center of the earth, which I think is a correct solution. I think the entire planet should have one universal datum. The problem is that you need to consider the tectonic plate movements based on your area, because the velocity of movement will be different depending on where you are on the face of the planet.

For example, the North American plates move a certain way. You have the Pacific Plate, you have the Mariana Plate, the Caribbean Plate, and others. All these tectonic plates move in different directions—and at different velocities. Within a single tectonic plate, your coordinates will be changing at a particular velocity and direction. Right now, as I am talking, we are all moving. But you and I are probably moving in different directions and at different speeds, depending which plate you’re on and where on that plate you are located. The upcoming NGS datum attempts to account for all of this, and of course their solution will work for North American plates, because it will be the new U.S. datum.

A few other things we know for sure is that this new horizontal datum will also come with a new vertical datum different than NAVD88. It should be more accurate because it will also be time dependent, and it will consider the vertical component of the velocities of the tectonic plates. There will be a lot to learn about datums when this happens. It is not an easy topic, and unfortunately it is easily overlooked.

I don’t know when the NGS is going to release an official name for this datum, but we do know it is expected to be released within the next several years. It’s worth noting that its release has been delayed already by years, due at least in part to COVID-19. You can learn more about the NGS’s plans for new datums here.

4. Advanced Workflow & Miscellaneous Questions

4.1 BILL: Would this workflow support LiDAR data collection?

DOUG: We don’t currently support LiDAR collection directly in ArcGIS Field Maps. Some of the newer smartphones do support LiDAR, including the latest models of iPhones, for example. We have done some research on that, but nothing is on the roadmap now.

4.2 BILL: Would Arrow and ArcGIS support underground asset data collection?

JEAN-YVES: A couple of years ago, we worked very closely with Doug’s team to develop a solution for underground mapping. A lot of our customers wanted to map underground assets without having to send separate teams to the field to first locate, then map their buried assets. Instead, they wanted to have their locator team be able to map directly into their GIS in a single trip. As a result, we came out with a solution called Eos Locate™ for ArcGIS. It is a free solution for our joint customers with Esri that allows you to capture your X, Y, and Z coordinates of buried assets directly into ArcGIS Field Maps.

There is also a workshop that we did last year that covers Eos Locate. On our website, you can request the recording for the full training. Request the Eos Locate workshop here.

4.3 CHRISTINE: When using ArcGIS Field Maps and Arrow to collect a line, would you be able to automatically also collect the vertices, based on distance traveled? For instance, when GPS collecting a trail.

TYLER: Yeah, definitely. I didn’t show that in the field today, but yeah, you can use the streaming feature in ArcGIS Field Maps. Just go into the collection settings of ArcGIS Field Maps, and there’s a streaming option set by distance or time. So, you can set it to drop a new vertex either every “X” distance units, for instance when you’re mapping a road and want it to drop a point every ten feet from your last point. Or you can set it to drop a vertex at “X” number of time units, for instance if you’re on an ATV and want to drop a point every second.

4.4 MICHAEL: Both Android and iOS have a feature where they stop or slow the collection of your location when the internal accelerometers sense you aren’t moving. I have noticed this happening when using ArcGIS Field Maps with the internal GPS of my iOS device. If I use an Arrow GNSS receiver, is there a way around that limitation?

JEAN-YVES: I don’t think it should be an issue for the Arrow because of how streaming is configured. When you’re collecting high-accuracy data within ArcGIS Field Maps, it’s important to set your streaming interval to one second. Once this is set up, your iOS device does not rely on motion anymore. It is strictly, as a rule, consuming data from the Arrow for its location. So, there should be no issue at all.

DOUG: I agree with you. If you’re connected via location provider to an Arrow, then the GPS, or iOS, settings won’t have any impact on that.

4.5 MIKE: What would you recommend in terms of mobile devices? Do you have any specific recommendations if someone wants to use an Android tablet?

TYLER: Well, first I prefer iOS. I’m not trying to be a fanboy or anything, but their advantage is that they have control over every aspect of the experience. They control their hardware. They have a limited set of devices, and they develop their operating system specifically for that hardware. So immediately, they’re going to have an advantage over Android, and even Windows, whose operating systems are designed to run on a large variety of hardware built by lots of different manufacturers. In the case of Android and Windows, those operating systems have been forked and modified to run better on various devices, but you could have an almost infinite number of combinations of, say, Bluetooth^® chips, Wi-Fi chips, processors, screens—everything. On top of that, you’ve got different versions of the Android operating system itself.

So, iOS is just going to be a little bit more consistent, in my experience, with things like Bluetooth and overall UX. So, I would lean towards iOS. Now, iOS definitely has its downfalls. It’s not built to be a rugged device. It overheats easily, so you must come up with solutions to mitigate that. But if I had to choose, I would go with iOS.

Now, if I’m going to go with Android, I would go with one of the well-known flagship models from the big companies, like the Samsung Galaxy Tab Active models. These devices are popular, and they also tend to be the models that those companies focus on developing. If you go with a cheap Android tablet, you really don’t know what hardware is coming along with it. You don’t know which exact operating system it is running. And a lot of times, they’ll limit the devices to a certain Android version, so it’s got a limited lifespan because you won’t be able to update after, say, Android 10. On some older devices, you couldn’t update past Android 7. And things move quickly nowadays, so I wouldn’t want to be stuck in that setup.

As far as what I notice on the software side, if you’re using Esri, then it’s worth thinking about the way that Esri is consistently taking feedback from users and adding new features based on that feedback. A lot of the time, those features won’t be backwards compatible, because it’s not practical. They must keep moving forward. So, if you don’t, or can’t, update your mobile devices, then you’re going be limited to what you can do capability-wise.

JEAN-YVES: I totally agree. I would add that of course, the workflow we showed today is built for you to bring your own device. So, if your tablet breaks, or becomes outdated, or a new employee wants something else, you can always purchase a different mobile device. Or they can pull out their cell phone and keep on working. So, you can always select and re-evaluate later.

I do totally agree with Tyler in terms of the stability and consistency of iOS, though. Android is changing things constantly, and we must update our software at Eos constantly to keep up. As for the ruggedness, I would say that no matter what device you go with, it’s going to be critically important to protect it. Use a protective case. The OtterBox has performed well for our customers. Also make sure you use a tempered glass to protect your screen.

Tyler also mentioned the iOS devices overheating. There are cooling devices and cases available. That could greatly help also.

DOUG: You know, I’ll just chime in here too. There are several factors to consider if you are going to go the Android route. Thinking about things like the dots per inch (DPI), do you want the device to behave as a tablet or a phone? There are a lot of 7-to-8-inch tablets on the market, and if they have a good display, they’ll show up as a tablet if that’s what you’re looking for. Otherwise, if they’re low DPI like a phone would, you need to consider that for your user’s experience. This might or might not be what you’re looking for in terms of the way Field Maps behaves, which changes when it’s on a tablet or phone.

Another consideration is battery life. Some ruggedized Android devices are meant to deal with extreme temperatures and last longer. Some devices have swappable batteries. So, there are other factors there that may influence which Android device you specifically choose. But I agree with Tyler’s recommendation to stick to a major Android manufacturer and vendor, because the popular models typically get better support than we see with some of the less popular vendors.

To Jean-Yves’ point about cooling, I know someone commented about that on the iPad side. There is a company called X-naut that offers cooling cases for iPads and iPad minis, which will keep those working in a much better condition for those hot environments, like summer days where you’re getting a lot of sunlight.