You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, when a "modify" comes in we draw out the new way geometry as if the mapper had added it. I'm thinking that it would be more interesting and useful to show the old geometry and then (if there was a geometry change), animate the geometry modification one node at a time. The idea being that it would "move" the linestring from the old state to the new state one node at a time (like a mapper actually does in the editor).
A second idea is to show tag modifications somehow. My initial thought is to show the old tags and then somehow animate the change to the new tags. That would be quite a bit busier on the UI than it is now, but it would also prominently feature the tag-based nature of OSM, which is where a lot of the depth in OSM comes from.
Thoughts?
The text was updated successfully, but these errors were encountered:
I definitely like the modify geometry visualization suggestion. Sounds a lot more dynamic than the current method.
With the tag option, maybe a toggle on/off switch to show this on the interface? Sometimes it's nice to have the simple, clean setup currently just running like a Screensaver. But the concept of animating tag changes is great.
Currently, when a "modify" comes in we draw out the new way geometry as if the mapper had added it. I'm thinking that it would be more interesting and useful to show the old geometry and then (if there was a geometry change), animate the geometry modification one node at a time. The idea being that it would "move" the linestring from the old state to the new state one node at a time (like a mapper actually does in the editor).
A second idea is to show tag modifications somehow. My initial thought is to show the old tags and then somehow animate the change to the new tags. That would be quite a bit busier on the UI than it is now, but it would also prominently feature the tag-based nature of OSM, which is where a lot of the depth in OSM comes from.
Thoughts?
The text was updated successfully, but these errors were encountered: