Utility Network Editing Web Maps

[Brian_Laws]

We are at the point of our Utility Network migration for our utilities that we have published a utility network service that we can now use to create editing web maps for our field crews to use in Field Maps.  Most of our web maps we only need to make attribute edits (no geometry edits), but we do have a few maps that will require both attribute and geometry edits. 

Is it correct that the only way to control whether geometry edits can be made is on the settings of the published utility network service?  And would we have to publish two utility network services, one with geometry edits enabled and another with them disabled, and pull in the appropriate service to the web map depending on what kind of edits we want allowed?

[RobertKrisher · Accepted solution]

You can control the editing capabilities of each service by adjusting the feature service settings in Portal.

If you need to have separate behaviors for different web maps, then you will need to have different services. Which shouldn't be too big of a deal if you've been applying all your symbology and configuration using web maps and not at the service level (which is a best practice).

This approach makes sense because if we didn't make you publish separate services and instead tried to control it through the web map, a malicious user could directly access the service in the web map and make whatever edits they wanted.

[Brian_Laws]

Thanks @RobertKrisher I thought that was the case but just wanted to make sure I wasn't missing something!

[D_Atkins]

---

@RobertKrisher wrote:

Which shouldn't be too big of a deal if you've been applying all your symbology and configuration using web maps and not at the service level (which is a best practice).

Could you add a bit more on this 'best practice'?  Your statement reads like configuration in the web map is recommended, but those configurations (popups, symbology, etc) are lost when the Service is republished, correct?  Intuitively, it would seem preferable to have pinned down as much of the configuration as possible in the service definition?

[RobertKrisher]

@D_Atkins the best practice is to put the majority of your definitions for symbology, labels, etc in a web map instead of the service. The feature service definition doesn't support the full capabilities of the web map, so you'll always need a web map to create full-features web/mobile applications. Additionally, putting all your configuration in a feature service means you're limiting yourself to only supporting a single user experience. A single feature service supporting multiple web maps uses less server resources and is more scalable than creating a bespoke feature service for each web map.

[D_Atkins]

---

@RobertKrisher wrote:

A single feature service supporting multiple web maps uses less server resources and is more scalable than creating a bespoke feature service for each web map.

This part is obvious, and we strive to do this already, including balancing larger dedicated services while relegating others to the shared pool.

---

@RobertKrisher wrote:

Additionally, putting all your configuration in a feature service means you're limiting yourself to only supporting a single user experience.

---

But just because we carefully craft a service definition with symbology, popups, and labels does not mean we can't also create additional webmaps (with customized symbology and labels), correct?  So, we're not really limiting ourselves with our investment in the Service Definition?

---

@RobertKrisher wrote:

the feature service definition doesn't support the full capabilities of the web map, 

---

Naturally, when we need Web Map customizations beyond what's available in the Service Definition, we build them... 

---

@RobertKrisher wrote:

the best practice is to put the majority of your definitions for symbology, labels, etc in a web map instead of the service. 

---

Our concern (with limited testing to verify), is that custom web map symbology, labels, and popups are 'vulnerable': any time you overwrite a web-service, we receive a warning that the web map configurations may be lost?  (Hence, we've strived to have one map service that is at least reusuable in multiple contexts wherever possible.)  Is our understanding here incorrect?


Why would it not be the "best practice" to craft the most perfect service definition first, then build secondary and tertiary web maps as needed?


Just trying to learn...

[RobertKrisher]

From my previous response: "The feature service definition doesn't support the full capabilities of the web map, so you'll always need a web map to create full-features web/mobile applications". That is why you get that warning when you overwrite a feature service.

There are known issues and limitations with trying to put the full configuration of a web map into your feature service definitions. The most common example is that this can cause subtypes and coded value domains to stop working.