Generalized Merge Tool ("+")

[slhh]

The curent merge function is sometimes quite useful, but not really required very often. Therefore needing one or two additional clicks wouldn't matter. This is offering the possibility to extend the merge tool to do several different kinds of merge by asking the user how to merge the selected objects. A list with all suitable types of merges fitting for the current selection needs to be shown. If required some functions can be made directly accessible by using shift, ctrl, or alt modifiers when invoking the merge tool as a shortcut.

There are many functions which could be intuitively bound to an add/merge tool dependent on the current selection (italic):

1. multiple objects
   • New Site Relation with selected objects as members. This can also be used as a base in order to setup other relations.
2. multiple lines
   • Safe Line Merge as currently implemented, but available only if merge doesn't change the meaning of data.
   • Unifying Line Merge (be careful) as currently implemented, but available only if iD can can handle all associate relations well. Tags which are unified should be shown to the user.
   • Enforced Line Merge (dangerous) Tags and relations which might need subsequent clean-up by the user should be indicated by iD.
   • New Route Relation with selected objects as members. Available in case of suitable features only.
   • New Area leaving selected objects unchanged. Available in case of lines forming a ring.
   • New Multipolygon with selected objects as members. Available in case of lines forming at least one ring.
3. multiple areas (closed way and/or multipolygon)
   • Safe Merge to Multipolygon as currently implemented, but available only if merge doesn't change the meaning of data.
   • Unifying Merge to Multipolygon (be careful) as currently implemented, but available only if iD can can handle all associate relations well. Tags which are unified should be shown to the user.
   • Enforced Merge to Multipolygon (dangerous) resulting in a closed way area. Tags and relations which might need subsequent clean-up by the user should be indicated by iD.
   • New Multipolygon (needs user clean-up) with selected objects as members, leaving tags on selected features.
4. multiple touching areas (closed way and/or multipolygon)
   • Safe Area Merge resulting in a closed way area, but available only if merge doesn't change the meaning of data.
   • Unifying Area Merge (be careful) resulting in a closed way area, but available only if iD can can handle all associate relations well. Tags which are unified should be shown to the user.
   • Enforced Area Merge (dangerous) resulting in a closed way area. Tags and relations which might need subsequent clean-up by the user should be indicated by iD.
5. line/area/multipolygon and point
   • Insert point as vertex This is currently covered by dragging the point on the line/outline, but I believe it is better to make the dragging function selective on feature type (for example not connecting highway to landuse etc.).
   • Merge Tags and Delete Point as currently implemented.
6. area/multipolygon and line (or lines)
   • Extend Area The area is extended along the line. The line needs to touch with both end to the outline of the area. Same applies to outer or inner rings of a multipolygon if the line is touching with its endpoints.
   • Merge Tags and Delete Line
7. single multipolygon
   • Merge Outer Segments resuting in closed way outers. Members are replaced by a closed way, but deleted only if untagged and unused by other relations.
     This can be used in oder to merge touching closed way outers or a single segmented outer ring.
   • __Merge Inner Segments __ Same as above for inners.
   • Merge to Other Features Replace untagged members by other features as far as possible, but don't split the other features.
   • Merge Touching Outers
   • Merge Touching Inners
8. relation (selected first) and other objects
   • Add Members Add other objects as members to relation. Some feature dependent rules might be required for this.

In some case more preconditions may be required in order to make a merge option available.
Unavailable options might be greyed out to make them more discoverable, but of course the full list of not fitting merge options can't be shown.

The list will likely need some edits for completion.

[pnorman]

There are many functions which could be intuitively bound to an add/merge tool dependent on the current selection (italic):

I'd disagree on the intuitive.

[slhh]

I have to admit that the level of intuitivity of these options is quite varying, but I belive that some of the new options are more intuitive than the current merge tool:

• The expected result of merging two touching areas is likely a simple area, but not a multipolygon as currently implemented.
• The expected result of merging an area with a point near to one of its edges is likely the point becoming an vertex of the are outline, but not to transfer tags and delete the point.
• The expected result of merging/adding different types of areas is more likely a grouping, which is made in OSM using a site relation, but not a multipolygon with mixed up tags as currently implemented.

Merge options like merge tags and delete point, which I have included because it is already part of the current merge implementation, are less intuitive. I believe these can still be sufficiently associted with a merge tool making them rememberable.

Some of the listed merge option are intuitive for certain types of selection, which makes them discoverable for other types of selection.

In some cases the level of intuitivity is higher for less experienced OSM users. For example a new user wants to group some areas, so using the merge tool seems to be intuitive. An experienced does already knows, that a new site relation is required, which makes using merge less intuitive.

The required level of intuitive of the generalized merge tool is much lower than that of the current merge tool because the user is made aware what will happen before commiting the operation.
For the generalized merge tool an option being discoverable and rememberable seems to be sufficient.

Unfortunately, the current merge tool doesn't have that higher level of intuitivity and is producing unexpected results.

[bhousel]

Thanks, I do appreciate the time you spent on this..

We do have a few existing issues that cover some of this:

1. Polygon (area-area) merge is covered by Operations: merge #435. I'm planning to use Turf.js for this, but there is an upstream blocking issue in that library.
2. Point-area merge action is not discoverable point-area merge action is not discoverable #815. You mention this above that it is not intuitive and I agree. I think we can separate the merge operations and give them better icons on the radial menu. Just having a '+' is ok, but better would be pictures that show what happens to the points/lines/areas when they merge.

There are a lot more ideas presented above, but some of them we will probably not get to anytime soon. e.g. an operation to create site relations, or operations to do more complex things involving multipolygons are probably out of scope for iD. You should probably switch to JOSM if you find yourself needing these features.

[slhh]

I have tried to make the list of operations as complete as possible. An operation, which is out of scope of iD, may still be indicating that there is another potentially expected result of merging a specific selection.

Some unsafe operations, like the enforced merge variants, may be considered to be out of scope of iD.
I'd appreciate that, bu such unsafe operations are provided, the user must be made aware of the risk.
We should not mark safe operations as risky; therefore, I have proposed the three levels safe, unifying, and enforced.
The current merge is pseudo-simple; checking, if the operation can be performed safely, is difficult.

Assigning a name etc. to a group of features seems to be a quite natural operation. Therefore, I disagree on creating site relations being out of scope of iD. Such operations should not be limited to a minority of mappers using JOSM.

We should not have data structures which are not editable well by iD users; thus, a powerful set of multipolygon operations is required, but I'm not sure which operations are essential yet.
Maybe some operations, like merging touching outer and inner rings, can be performed automatically instead of being accessible from the user interface.

I have already started using JOSM before iD has appeared, and I'm fine with it. My only interest in iD is to improve it for the less experienced or less technically skilled users, and to protect the database against destructive changes made by iD users accidentally.

[jfirebaugh]

Thanks for your feedback @slhh!

I agree with @bhousel and @pnorman: I don't think it would be intuitive or discoverable to put this amount of functionality behind one operation. We already have indications that the amount of functionality behind the existing merge operation is hard to discover.

We already have support for, or have issues filed, for most of the items you listed:

• Merge protects tags: already implemented
• Merge protects relations: disable merges that would damage relations #1512
• Switch between line and area: Switch between closed line and area #1828
• Merge to multipolygon: already implemented
• Union overlapping areas: Operations: merge #435
• Selective auto-snapping: Add logic for feature snapping #2302
• Extend area: Allow to continue drawing of area #2272, Add point to line/area feature #1711
• Merge multipolygons: already implemented
• Merge multipolygon member ways: already implemented
• Add members: Allow making multiple selected items members of a relation all at once #2152, How do I add a way to an existing, but not adjacent, relation? #1906
• Create route relation: already implemented. Select the member you want to start with and click + in the relations section in the sidebar.

I've opened issues for the items in your list that weren't already covered:

• Site relations. We should add a preset for them: Add preset for site relation #2930
• Forcing operations. This should be possible for power users: Allow modifier key to force normally-disabled operations #2929

[slhh]

I think we can separate the merge operations and give them better icons on the radial menu. Just having a '+' is ok, but better would be pictures that show what happens to the points/lines/areas when they merge.

@bhousel, I believe small icons describing the different merge operations well are impossible, and you should not waste valueable space of the radial menu for the less frequently used operations, which can be combined behind a single radial menu tool. iD is far away from beeing complete, you will likely need the space in the radial menu some day.

I suggest to keep the single "+" , show the list of available and unavailable merge operations in the inspector frame. Each item should be a large button invoking the merge operation; the button should consist of a large icon and the name of the operation.Icon and Name together can likely describe the Operation well. Mouse over the button should show more information for the operation, in addition it should show a preview of the operation in the map window if the specific merge operation is available. A help button should be next to the operation button. Due to the inspector the complete list of merge operations can be shown, or at least all operations for similar types of data. This makes even the unavailable one discoverable. The available ones needs to be arrangged somewhere on top of the list in order to avoid scrolling for the normal operations.

@jfirebaugh , I can't understand why this should not be discoverable. It's similar to an traditional drop-down menu, just improved with some additional information like the preview. The user will likely use one of the intuitive operations soon, and can discover all other operations then.

We already have indications that the amount of functionality behind the existing merge operation is hard to discover.

I agree. This is due to not showing/listing the operation somewere, but just performing it. In addition, some of the current operations nearly don't change anything visible.