nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Drawing Performance: Pressure Subnetwork

MichaelParma

I'm curious about options to improve drawing performance of the subnetworks when the aggregated geometry is saved. As a specific example, a client has a water system with 3 subnetworks in the pressure tier. Using the default template symbology from the solution, draw times in the web map are <2 seconds with all layers turned on excluding the water network/water pressure. Turning on this layer consistently pushes draw times over 30 seconds. This is confirmed in the ArcGIS Server logs that performance is isolated to this layer.

I suspect it is an issue with a complex "spider web" geometry over a wide area that thus lacks a useable spatial index (compared to other features). I suppose a possible workaround is to forgo the water network/water pressure feature and instead symbolize the water lines (mains, services) again based on the pressure subnetwork name. Anyone have suggestions on how to improve the drawing performance of this layer?

Thanks,
Michael Parma

Trouver plus de publications taguées avec

Accepted answers

RobertKrisher

It looks like you are including the services/laterals in your subnetwork line. This is not recommended since it greatly increases the complexity and draw time of the layer. Configure the subnetwork line to only include the mains and you should see draw times improve.

All comments

MichaelParma

Hi Mike,

We restarted the service and even republished the service, but the issue persists.

MikeMillerGIS

The rule should have monikerized the table name, so it should be looking for a guid. Seeing the table name means that the monikerization did not happen. So the SOC could not find the table on start. If you restart the service, does it fix it?

MichaelParma

Hi Robert,

As suggested, we dropped the topology and removed the laterals from the subnetwork line definition. After enabling the topology and restarting the service, that part seems to have worked well. However, now we are receiving an error that appears to be related to attribute rules and an L### prefix in front of the feature class name. This seems odd as the only change we made we the subnetworkline definition.

Let me know if you have ideas or if this warrants a separate post. I'm certain I've seen this before but can't find the resolution again.

Many thanks,
Mike

MichaelParma

Thanks, Robert. I had thought about dropping the laterals from the subnetwork line. In this case, I'm using Esri's base model downloaded from the solutions page. I'm trying to avoid altering the solution configuration to stay as "true" as possible for demonstration purposes.

Given the performance is so slow, I may have to resort to a deviation.

Thanks,
Mike

RobertKrisher

@gis_KIWI4 That sounds like a separate issue. If you're noticing a performance hit when you query the layer using a particular attribute, and that query is something you intend on using a lot, have you considered adding an index to that field? As an example, you could add an index to the tier name field (which is used as the subtype for the layer) and use a subtype group layer to control scale suppression.

GIS_kiwi4

@RobertKrisher - I too have had a similar experience as the OP.
The subnetline layer seems to struggle when added to the webmap and setting a definition query to filter out the LV subnetworks (service lines and LV distribution) makes it much worse.

I have gotten away by setting the symbology for the LV subnetwork to a "blank" so its still within the map but it is not cluttering it.

RobertKrisher

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Se connecter
S'inscrire

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.