Access to snapped location from GeometryEditor

FelicityRhone

I'm using the GeometryEditor for feature editing (in version 200.8.1 of the Maps SDK right now). I am trying to extend the capabilities of the GeometryEditor somewhat, e.g. adding labels/constraints to the geometry as it's being drawn.

[This earlier post](https://community.esri.com/t5/net-maps-sdk-questions/geometryeditor-feedbackline-access/m-p/1543335/... has someone asking for access to the feedback line, which would also be extremely helpful for me. But perhaps more importantly (because I could use this info to calculate the feedback line myself) I would like to have access to the MapPoint where the geometry is intermediately being snapped to, before the user finishes placing the point.

The GeometryEditor has a SnapChanged event which sounds promising, but the event args only tell you whether it is snapped or not, and not where the snap has landed.

Can I make a feature suggestion for this, or is there any suggested workaround (even using Reflection or something) where I can get the snap point/feedback point in the current version?

Thanks

ShellyGill1

Hi Felicity - thanks for posting.

I'm afraid there's no simple way to find the info you're after currently. I think it would be a matter of performing a query on the underlying layers in the map which are valid snap sources, applying a similar tolerance to that which we use internally, and using similar criteria to that which we do internally if there are multiple snap candidates to decide the best snap location. If snapping to utility networks with rules, there'd be extra rules to consider. Effectively this would be recreating the snap in your own code and I'm not suggesting it's a great way to go, because it would be pretty complex and possibly out of sync with the internal events - however if you have an urgent need for this then please send me a direct message and we could discuss this in more detail to see if it would be feasible for your case.

If it's a longer-term aspiration, it's certainly an enhancement that we can consider adding more info to the snap event. We'd originally considered what information we should best put in the event when we added it, and went with the minimal approach initially. Other information we could consider exposing would be the details of the feature or features snapped to, or other candidates considered. However it sounds like just the snapped-to Point information would suit what you've described above. If you could again direct message me with any details of your scenario I'd really appreciate that (for example your user story, or use case, who your users are), as I can take this in to account when we're discussing this potential enhancement.

View solution in original post

ShellyGill1

Hi Felicity - thanks for posting.

I'm afraid there's no simple way to find the info you're after currently. I think it would be a matter of performing a query on the underlying layers in the map which are valid snap sources, applying a similar tolerance to that which we use internally, and using similar criteria to that which we do internally if there are multiple snap candidates to decide the best snap location. If snapping to utility networks with rules, there'd be extra rules to consider. Effectively this would be recreating the snap in your own code and I'm not suggesting it's a great way to go, because it would be pretty complex and possibly out of sync with the internal events - however if you have an urgent need for this then please send me a direct message and we could discuss this in more detail to see if it would be feasible for your case.

If it's a longer-term aspiration, it's certainly an enhancement that we can consider adding more info to the snap event. We'd originally considered what information we should best put in the event when we added it, and went with the minimal approach initially. Other information we could consider exposing would be the details of the feature or features snapped to, or other candidates considered. However it sounds like just the snapped-to Point information would suit what you've described above. If you could again direct message me with any details of your scenario I'd really appreciate that (for example your user story, or use case, who your users are), as I can take this in to account when we're discussing this potential enhancement.

FelicityRhone

Thanks! Sent you a message 🙂