I have just created a new relation and want to add a bunch of items to this relation, but when I select another item I can’t find the relation I have just created.
first item: Way History: PA-CR3 de Houffalize (638467174)
New relation: Centre de Résistance de Houffalize (15819056, v1)
next item: Way: PA-CR1 de Houffalize (1135664015)
and some more…
Thank you for your help
I see you are using the iD editor.
The ordinary method is to select the object you want to add (in this case, the “PA-CR1”), look for the “Relations (0)” block, hit the “+” button and scroll down the list until you see “Centre de Résistance de Houffalize”.
The drop-down list only shows a limited number of relations close to the object. It might not work if the object you want to add is far away from the existing relation.
Should this happen, here’s a magic trick. The key is to know that the list of relations in the drop-down list is relative to the center of the map when you press the “+” button. So, first select your PA-CR1 object, then drag the map with your mouse to get close to the existing object (PA-CR3). Be sure not to click on any object while you do this (you should only click on empty spaces to move the map). Try the “+” button and it should show the desired relation. 
That’s a useful trick, @bxl-forever. I might sound like a curmudgeon as I say this but I say forgo iD altogether as a relation editor. Use JOSM instead. If you insist on iD to edit relations, best wishes.
Yes, I find the relation-editing aspects of iD to be “that poor.” It may be I have learned on JOSM, it may be that JOSM’s relation editor window is simply much better. Mmm…both, as I think about the answer.
With iD, it’s easy to either be confused (especially during human learning of its edit relations processes) or to botch up the map. Neither is something OSM wants to do. Personally, I use JOSM to edit relations and I am a very happy relation editor using JOSM’s relation editor. In fact, I recommend using JOSM to edit relations.
I beg to differ. As a maintainer of hiking route relations, I see nearly as many relations broken with JOSM as with ID. And as someone who has to introduce total beginners to route edition (without going through way or node editing before), I would not dream of doing it with JOSM: too many things can go wrong. I start mentioning JOSM only when we get to sorting relation members in large numbers.
Said quite plainly: if someone is either or (worse) both of a “total beginner” (editing in OSM) AND they haven’t gone “through way or node editing before,” they simply have no business editing OSM relations. I am certain I am not alone in that conclusion.
I’m all for people learning how to edit our map, we couldn’t crawl, walk, run and eventually fly as a project unless individuals as volunteers go through (learning) the steps of editing. Start small, work on nodes (first), with their tags, then work on ways (with their tags) and after a fair bit of that sort of editing (over time, editing a substantial number of these…), then “graduate” to relations. And I’ll say it again for emphasis: while editing relations using iD is technically possible, it is error prone, difficult, relies upon “tricks” to do it right and often results in it being quite easy to introduce bad data into our map database. Why would anybody choose to do that? JOSM, while it does have its own “learning curve” (which some people call steep) is worth the investment in time to learn it. ESPECIALLY for editing relations, which has a “dream” interface (quite intuitive, well-placed controls, works well, has features like the sort button showing breaks in route connectivity and “red if member is included more than once” sorts of helpful feedback in its user interface…). Why wouldn’t you use JOSM for editing relations? “Too many things can go wrong?” That’s not because the editor is poorly-designed (it isn’t poorly-designed, in fact it is quite well-designed). So, why would it be?
would “because iD” be enough for an answer?
JOSM has so many requirements both from a technical point of view (hello proxy to manually configure, hello virtual machine) and an end-user perspective (hello cannot pane the map with the keyboard, hello cannot make characters bigger simply using CTRL+).
Managing complex relations in iD may be hard (like for bus public transportation), but managing easy relations in iD (like hiking routes or street addresses) is easy, provided the mentoring is done correctly.
You may feel that it is criminal for someone to intentionally teach relations in iD to a newbie, I beg to differ, unless you can find one recent example of a ruined location because of that.
When someone asks for help about iD in a help section, answering “use JOSM, I’m the living proof it’s easier” is usually off-topic, and a bit of the lazy way from someone who does not practice iD enough.
It certainly is an answer, however I’m not sure it is a good answer.
We agree that iD is difficult, even foolish, for “managing” (let’s say “editing”) complex relations. We MIGHT agree that iD is “sufficient” (with you saying that is a weak choice of word and me saying that is a generous choice of word) for editing short, simple relations. A PTv2 relation is not simple, though we might quibble about what is. (We might agree a short-distance hiking relation qualifies).
I wouldn’t say “criminal,” so we disagree there (as that’s too strong a word to characterize my usage of iD for relations under any circumstances). However, there are many, many examples of relations which are ruined by iD: I myself “almost” created quite a number of these myself — until I became so frustrated with iD’s poor ability to edit relations I simply don’t (won’t) use it for that purpose any longer.
BTW, you’ll notice I didn’t disagree with @Bxl-forever’s suggestion. I merely added my own perspective that I don’t find the chosen tool for the task to be appropriate. Sometimes you reach for a certain type of wrench to move a certain kind of nut, and “there’s no accounting for taste.” But when the wrong wrench clumsily (and frequently) strips the nut or injures your knuckles as you use it, you learn to reach for “the right tool.”
If Jean-Louis wants to continue to use iD for relations and has a satisfactory answer to a question asked in this forum, that’s great. But asking here does open up a possibility that someone (like me) might (and does) say “that might not be the best tool OSM has to offer you to do what you are trying to do; consider using another tool and you might find things much more intuitive, helpful and less error-prone.”
That’s what happened here.
And I have thousands of edits in iD and tens of thousands of edits in JOSM, so I’m neither lazy nor “not practiced enough.”
so a reader here just told me that this example is not true in all cases. There is a shortcut CTRL-Up / CTRL-Left and so on which is configured by default. It works for me, but not for everybody, but at least it can be changed to another keypress.
Managing complex relations in iD may be hard (like for bus public transportation), but managing easy relations in iD (like hiking routes or street addresses) is easy, provided the mentoring is done correctly.
You may feel that it is criminal for someone to intentionally teach relations in iD to a newbie, I beg to differ, unless you can find one recent example of a ruined location because of that.
there was a case some days ago on the italian list, a new mapper wanted to remove part of a way from a hiking route relation in iD and ended up with the relation not in the correct order, what is obvious to see and a one-button-click to fix in josm but last time I looked at iD wasn’t even visible there.
one could argue that as long as the order can be automatically determined it doesn’t matter much, but it is not completely true because there might be “from” “to” properties which define start and end in a specific way and should not be inverted.
Stated briefly: a “first try to edit a relation” is no small topic. There is a lot actually going or potentially going on. We did have a specific question and an answer to it specifically. We also had a bit of a “peek behind the curtain” at how very much else is going on (about editing relations in OSM).
I like to see OSM be careful as we explore and offer multiple options to complete editing tasks, sometimes with a tool chosen (by a beginner), sometimes with a tool suggested (by seasoned editors).
Yes, it really “doesn’t matter much” (what editor is used) as long as the results are good. Though, let’s assure the results are good. Part of that is being careful. Part of that is tool selection. Part of that is “good mentoring” (of best instruction on the use of a tool). Part of that is “there is no accounting for taste” (of which tool one might choose to use), although I’d like to insist upon not maligning data as an important consideration. If data destruction is “likely” (or “more likely”) to happen because of the choice of a beginner using a tool which I (and others) consider to be ill-suited to its chosen purpose, I (and the community) might say something about that. Sure, we recognize that there may be differences of opinion happening but I think it’s a “you choose that, I choose this” sort of discussion that isn’t nastily rancorous.
Yes, it would be great to avoid being nastily rancorous or judgmental. Maybe we need another thread to compare experiences and even share solid data on relation management.
I believe we can safely advise our original poster that relation management needs much care (think about other relations around, about not breaking continuity or ordering) and that it would even be better to learn using QA tools, or even monitoring tools.
In my own experience of managing hiking routes, the worst situations we encounter are not related to a specific tool but to contributors who do not care about their surroundings, do not reply to comments, or do it in opinionated ways while many of us are convinced that there is still a lot to learn for everybody in that field.
However, to repair these situations, with JOSM you can, with Id you simply can’t. Id has its strong points, but this isn’t one of them.
When I was last keeping track of such things (a very long time ago, and not just route relation breakage) the problem was mostly associated with new users, not any particular editor. New JOSM users tended to break more things than new iD users, but given that overall more new users use iD, more relations are broken by iD users.
One huge advantage that JOSM has over iD is the inbuilt validator - even if I’m actually editing relations in another editor (which I always will, because I find JOSM’s relation editor cumbersome and horrible to use) where relevant I’ll still check in JOSM with the validator.
See, Andy is already “off and running” (a good thing) in the direction of what @Stc suggests we might need (he mentions “another thread”): “comparable experiences” and even shared solid data on relation management.
(At long last?) we get another opinion from someone who finds JOSM’s relation editor “cumbersome and horrible,” thanks for the opposing view, Andy! And we see that despite that, he uses JOSM’s excellent Validator plug-in to check-against-rules the relations (and all else it checks before uploading data). We also get Andy’s (and others’) perspectives that regardless of the editor — an important point — it is inexperience editing relations that is a frequent cause of relations getting broken or entered with errors in the first place. It is important to note that for more-complex (and larger) relations, it is frequently the case that they are (especially initially) entered with incomplete tags and/or incomplete members and/or especially out-of-order members and/or members which have incorrect role tags (in the case of bidirectional route relations, especially).
These topics are seldom spoken about, and I like @StC’s suggestion we start a new thread to discuss them. Better relations (especially by newer, beginner editors) await our efforts. Relations should be presented and taught in OSM as the relatively advanced topic they are. We can do better.
That’s a lot to chew on; this thread has popped into a full puffy blob from a small initial kernel, but that does happen here.
So how to sort out the “full puffy blob” into smaller bits? So far I find several topics:
I can find problematic changes but as a I “grew up” with JOSM and as I do not use any other editor software I can only instruct JOSM users well. E.g. I have no glue how to check connectivity and the proper use of roles in iD but
I would like to know what Andy’s problems with JOSM’s relation editor are.
You seem to be on the right track with that nice bullet list. Next, how about someone start a new topic / thread and transfer this list as a new jumping-off point?
There are existing relation tutorials (various editors, various media, I think some wiki, some video-tutorials…) but I’m obviously not making a comprehensive list here. That might be a good chunk of stuff to toss into a new topic bucket, too.
I think an important couple of points that have emerged here are the two items of “beginner / novice relation editors should also have included in their instruction that it can be quite easy to mess up relations (so be careful, be aware of these specific issues…)” and “relations are at least an intermediate- if not more-advanced-level topic in OSM.” In other words, it’s good to know nodes, ways, tags and have some practice using these more primitive data structure elements before “graduating” to learning relations.
We might start with the type=* key in a relation really driving all else, as the 15 or 20 or so (I don’t know the current count of ones we consider “official”) values this can include (route, boundary, site…) sends each flavor of relation into particularly different directions. Emphasizing this at the beginning of relation tutorials underscores both the abstract power of “relation” (and the inherent power of a relational database being the human interpretation of what the relation’s semantics are meant to be) and how for any given type, there must be fairly strict rules (syntax) for how it must be tagged and constructed.
Various salt-and-butter options can be added…enjoy your popcorn!
Edit: In this context (OSM relations), I have found it useful to make distinctions between “editors” so this word is not ambiguous. My chosen method is to choose “human editor” to denote a person who is making changes to OSM’s database and “software editor” to denote a software (like iD or JOSM) which facilitates a human making changes to OSM’s database.