Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Objects cannot be merged if they belong to same relations but in different order #9788

Open
DujaOSM opened this issue Jul 20, 2023 · 1 comment · May be fixed by #10089
Open

Objects cannot be merged if they belong to same relations but in different order #9788

DujaOSM opened this issue Jul 20, 2023 · 1 comment · May be fixed by #10089

Comments

@DujaOSM
Copy link

DujaOSM commented Jul 20, 2023

Here's another one which has irked me for a while: when two adjacent ways are being merged, iD validation would not let me do that if they belong to different relations (so far, so good, although I don't quite like this). However, for the two sets relations to match, iD requires them to be in the same order on the object as well, which is simply wrong: this order is basically arbitrary and should not matter anywhere.

As a simplest example, let's create two consecutive paths and assign them to two hiking route relations: the first one to routes {A, B} and the second one to routes {B, A}. When I select them and try to [C]ombine them, I get:
CantBeMerged
"These features can't be merged since they belong to conflicting relations"

For simple cases it's just annoying (need to reassign relations in the same order), but for highways featuring a high number of e.g. bus route relations this makes merging nigh impossible.

The fix seems to be simple: internally set the relation sets by name or ID, so that they will match when compared. I wouldn't mind having that sorted in the UI as well -- at least it would make the relation order predictable.

@DujaOSM
Copy link
Author

DujaOSM commented Jul 20, 2023

Damn, this is the same as #9502, where I commented already... Perhaps this senior moment of mine would induce someone to finally fix this ;)

bhousel added a commit to facebook/Rapid that referenced this issue Apr 29, 2024
re: #1389
re: openstreetmap/iD#10089
re: openstreetmap/iD#9502
re: openstreetmap/iD#9788

This was tricky to track down, as iD#10089 doesn't actually fix the issue
properly - really we should just not be using utilArrayIdentical with objects.

I wrote some tests to actually cover this issue and ensure that's it is fixed
correctly by comparing relation IDs.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant