Latest Contributions by NathanHeickLACSD

Using the methods setMaxAllowableOffset or setAutoGeneralize did the trick.  The selected features update now on scale changes towards the end of the redraw.  You can see them move from where they were before to where they should be.  The performance hit was not significant. ... View more

Thanks Rene!  I'm actually querying the features directly from the server to load them into the graphics layer without any generalization.  If I stopped generalizing the feature layer, that might not be necessary though.  The main problem seems to be that the selected features in the feature layer don't update on scale changes like they do when there is no selection.  Do you understand why that happens?   My main concern with the solution you provided is that when have a large flow trace, the selections can take a long time to perform so it would be slow if you had to redo them every time you changed scale.  I will delve into the generalization settings on the feature layer, see if I can get them to work, and see what the performance impact is. ... View more

Hi David, What we're doing is a bit complicated, but we're doing it for the sake of better symbology.  In that complication may lie the problem. We have a feature layer and we set the selection symbol to a null symbol.  We then have an event handler that copies the selected features to two graphics layers.  One graphics layer uses the same renderer and scale dependencies as the parent layer.  It basically draws the selected features exactly as they are normally.  The second graphics layer is a highlight layer and is always visible.  It lets us see the selection at all scales.  That's important when we do flow traces across our system. What is happening is that the graphics layers work as designed, but the selected feature in the feature layer appears to be generalized.  We sometimes make selections when zoomed out using various widgets.  Then, when we zoom in, the selected feature is not where it is supposed to be.  For point features, the location is off.  For line features, the vertices are off.  It's almost like the coordinates are imprecise when zoomed out but good enough for that zoom level.  Then, when we zoom in, they are not adequate. The end result is that the features we selected are invisible per the design and not where they are supposed to be.  So, if you click on the graphics layers which are at the correct location, you can't get a popup.  You have to go hunt for the invisible point or line feature to get the popup.  Since the graphics layers are correct, you would never think to click off in space randomly. My intuition says that when you select the features, the implementation of the selected features in the JavaScript 3.X API is such that the graphic for the selected feature is static and does not get updated each time the zoom level changes.  Normally, the feature layer keeps requerying the features at each zoom level and generalizes them adequately for each zoom level.  It's like the requerying gets shut off while the feature is selected.  I think it's either in the design of the JavaScript API or because I'm using null symbology.  I tried reading the API code but I haven't found where generalization occurs.  I've just found mentions of the feature layer mode. In the 4.X API, you can just set a selection renderer, which is what I would like to have.  Still, I think it has more do with how selected features are symbolized than my graphics layers. Thanks David! Hi @Anonymous User, do you have any thoughts on this issue? ... View more

Hi Kerri, We have two vendors deploying flow meters.  We have two types of flow monitoring locations.  First, we have manholes where we measure depth only in the middle of the manhole.  Second, we have flow meters installed in pipes at manholes.  The location is really a combination of a pipe and a manhole. My question is just one part of the whole problem.  Before they go out in the field, we know the pipes and manholes where we want them to monitor.  Depending on field conditions, they may need to deploy the meter at a different location.  One purpose of the field map is to provide data on the sewer system through popups.  Another purpose is to ensure the flow meters are deployed where they are supposed to.  That could be a read-only activity if it weren't for the fact that sometimes the meters have to be moved. So, we need to record the locations where the meters were deployed and we would like to always record the GPS coordinates if possible.  The problem is that they aren't so accurate that you can identify the manhole accurately just from the coordinates, but we wanted the data as a backup just in case there were any questions.  I'm working on the app right now and snapping to the manhole works well.  I can even pull the manhole attributes using Arcade once snapped.  However, it would be nice if I could also log the GPS coordinates at the same time.  This is a softer requirement. The next requirement is to pick the pipe connected to the manhole.  I should stop and say that the idea is that the map shows the proposed pipes and manholes and the actual pipes and manholes on top of them.  That way we can track progress in the field and in a dashboard.  So, I looked into contingent values and that seemed like a no go for 30,000 manhole pipe combinations.  It would be great if I could use the manhole to query the connected pipes and create a pick list out of them.  I would be so happy.  Without that, it seems like I would have to use Survey123, which seems like too much complexity, or labels and manual data entry. The last requirement is to display the pipe diameter from GIS and enter the field measured pipe diameter to do additional verification of the monitoring location and the field measurements. The whole thing was an idea I had after we had about 10% issues the last time we did this with 100 sites.  Now, we are doing 600 sites.  So, I am trying to make a workflow that isn't too complicated but accomplishes the goal of producing good data.  Everything we're trying to do is based on a lesson from the last time around. In summary, we want to identify the manhole where the meter is deployed, the pipe where the meter is deployed, capture the actual GPS coordinates of the user even if they are approximate, and record the pipe diameter measured in the field.  Secondarily, we want to provide the sewer system as a reference in locating the proposed deployment locations or finding better ones. I'm trying to make this concept of picking the manhole and pipe as simple as possible.  Snapping to the manhole works well but I can't find a way to pick a pipe.  Maybe setup relationships and enter the measured diameter on the related pipe? Thanks Kerri! ... View more

The problem was that I was editing the wrong config file.  I was editing the template in the widget folder, not the one in the config folder. ... View more