facebook / Rapid

The OpenStreetMap editor driven by open data, AI, and supercharged features
https://rapideditor.org
ISC License
517 stars 91 forks source link

Unable to create a closed loop line using a single line with RapID V2 (Safari browser) #561

Closed VLD190 closed 2 years ago

VLD190 commented 2 years ago

Description

Unable to create a way and close the loop using a single Way. I click '2' to select 'line,' and attempted to draw a square with four nodes but once I attempt to close the loop, the final result is a 'U' shape with 4 nodes instead of a square, so I have to create another line to close the loop. This issue is noteworthy because it adds extra steps and slows the process of editing the geospatial data using RapID V2.

Version

2.0-alpha

What browser are you seeing the problem on? What version are you running?

Safari v15.6

Steps to reproduce

1) Click '2' to add a line. 2) draw a square with 4 nodes 3) attempt to close the loop by clicking the end-node to the starting-node 4) the final result is U shape with 4 nodes

The browser URL at the time you encountered the bug

https://mapwith.ai/rapid-v2-alpha#background=Maxar-Premium&datasets=fbRoads,msBuildings&disable_features=boundaries&map=21.32/-18.95730/49.10903

bhousel commented 2 years ago

Yea, this is an interesting chicken-and-egg problem where - when the user enters Draw Line mode and is about to start drawing the line, there is nothing to select. Once the user starts drawing the line, the rendering code doesn't realize that the new line should be selected. That's what it needs in order to actually draw the child vertices, including the ones at the beginning/end that you'd need to click on to complete the line.

This worked differently in v1 because the information about "what is selected" lives with the current mode, and the mode would change constantly as the user draws more pieces of the line, and the "selected" state was updated just by css classing the line.

Bonkles commented 2 years ago

I have included a new state in the renderer scene called 'drawing'- if the scene contains ways or nodes that are in the midst of being drawn, we always show their vertices no matter what. This allows for the correct snapping behavior.

Also, we were correctly checking for whether we were clicking on the original node in the way, but then utterly failing to actually update the way with that final node location. This meant that id you drew a box, you'd end up with a 'U' shape instead. :-p

Fixed in f54831dab.