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; } } }

Editing - moving an edit (point) not working

SpencerWilliams

I have a feature service that was working in the initial beta (Feb. I think) for 2.0 - I disabled the ability to use the feature service (ie editing) due to some issues with the data form in the initial beta. After about 200 code check-in's - something is preventing it from working fully. As far as I can tell, everything works except when you try and reposition an edit. It looks like it trys to move it, but then it "sticks". I am able to click and drag multiple times and move the edit over a landmark after around 10 click+drags - when I revisit the application after closing it (to check to see if the edit "took") I find that the edit never moved at all - or at least wasn't saved as such.

I have also tried using the service in the example to see if it was a problem with my featureservice on the arcGIS server, but it has the same behavior there as well.

Has anyone from esri seen this behavior using the new edit features? I removed all click events from the map and page, but that didnt seem to help.

Thanks,

Spencer

Find more posts tagged with

Accepted answers

All comments

BrooksShannon

Editing the geometry in layers that are clustered is currently not a supported scenario. If you need to do edit a layer, please disable clustering.

Thanks for letting me know, Morten. I appreciate it.

SomeGISGuy

Editing the geometry in layers that are clustered is currently not a supported scenario. If you need to do edit a layer, please disable clustering.

BrooksShannon

You aren't going to like my workaround - and to be fair, I did not choose this based on the clusterer not working with edit layers. I am using MapIT's SDS to serve up the data, my own code to do the storage (writes) to the DB, and a heavily modified version of morten's "edit" code (in the gallery) to handle the on screen editing. It was the right thing to do in our situation.

Spencer

Cool. While we might not have to go to as great of lengths as you have 😉 (as our editing solution is basic enough that most everything else out of the box will cut it) this is kind of a weird issue to deal with that presents some problems. The performance of drawing an OnDemand FeatureLayer with clustering is so much better than without clustering (in my limited testing) that it seems almost necessary to use a clusterer of some kind (even if it's a custom one). However, the ability to move features is just as important in the application I'm designing.

Maybe I can try implementing my own Move command, similar to what you did when you implemented your on-screen editing functionality. If this is a bug in the ESRI implementation of the Move command, that might do the trick. Or perhaps they're aware of the issue and it will be resolved at 2.0 release, which would make life easier.

Morten and/or Dominique - are you aware of this issue? I can't immediately conceive of a good workaround, but if you have any ideas for me to chew on, I wouldn't likely turn them down. 🙂

Thanks!
Brooks

SpencerWilliams

I'm seeing this behavior too. Has anyone else noticed it? Or, Spencer, if you were able to figure out a workaround, would you be willing to share what you came up with?

Thanks!
Brooks

You aren't going to like my workaround - and to be fair, I did not choose this based on the clusterer not working with edit layers. I am using MapIT's SDS to serve up the data, my own code to do the storage (writes) to the DB, and a heavily modified version of morten's "edit" code (in the gallery) to handle the on screen editing. It was the right thing to do in our situation.

Spencer

BrooksShannon

after some testing i have determined the following - if a flare clusterer is utilized on the featurelayer where edits are present, you cannot reposition items. Please let me know if this is by design or a bug.

I'm seeing this behavior too. Has anyone else noticed it? Or, Spencer, if you were able to figure out a workaround, would you be willing to share what you came up with?

Thanks!
Brooks

SpencerWilliams

after some testing i have determined the following - if a flare clusterer is utilized on the featurelayer where edits are present, you cannot reposition items. Please let me know if this is by design or a bug.

Thanks,

Spencer

SpencerWilliams

ok, so I figured it out - the 2.0 version that was released in May broke on FeatureDataForm.GraphicsSource as it changed from GraphicsCollection to Graphic - when I changed it to (sender as featurelayer).Graphics[0], it worked because I have an edit already created in the layer. This breaks however, when there are no graphics in the feature layer. How are you supposed to set graphicsSource without graphics? Do you wait until there are graphics in the featureservice, and then set the graphicsSource to a graphic in the featureService? That seems odd.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

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