Greetings,
I see a problem where the evt.coordinate is ignored by Modify. This does not play well with the Snap interaction.
I have this condition where I want to have the Modify interaction modify a set of features, most specifically, Point and LineString geometries. I want to SNAP to the point geometries with a rather large pixel tolerance, but I do not want to
preclude modifying an underlying LineString, if need be. So, therefore the SNAP interaction only contains an ol.Collection of the Point geometries, but Modify contains an ol.Collection of all the geometries.
My problem. The Snap works fine in that it modifies the 'evt.pixel' and 'evt.coordinate' to the appropriate snap. However, Modify ignores 'evt.coordinate' in this case, using instead map.getCoordinateFromPixel(evt.pixel).
Unless I'm missing something more fundamental, I don't see a good reason for ignoring the evt.coordinate in this case. Using map.getCoordinateFromPixel causes an error because depending on the resolution, the pixel can represent a
large area. And unfortunately, it returns a different coordinate than evt.coordinate. This condition subsequently finds a vertex underneath and in my LineString geometries and modifies that instead, ignoring the snap.
This action leads to a rather annoying user experience with the mouse.
There are two parts of the code in which this situation is caused.
ol.interaction.Modify.handleDownEvent_(event)
ol.interaction.Modify.handlePointerAtPixel(pixel, map)
I have changed handlePointAtPixel to this signature
ol.interaction.Modify.handlePointerAtPixel = function (pixel, pixelCoordinate, map) {}
and got rid of
var pixelCoordinate = map.getCoordinateFromPixel(pixel);
and I've changed its calls appropriately.
I have changed handleDownEvent_ to use the evt.coordinate directly instead of
calling map.getCoordinateFromPixel.
This all seems to work as to my intent.
I can contribute a Pull Request for this change, if so wanted.
Cheers,
-Polar