Re: [Tagging] Relations (was directions)
2011/8/10 Serge Wroclawski emac...@gmail.com On Tue, Aug 9, 2011 at 7:13 PM, Simone Saviolo simone.savi...@gmail.com wrote: if we make a system that any newcomer can use completely without even having to dwelve into the details, then we're basically dumbing it down and limiting its potential. I think we're venturing a bit off topic, but you're keying on to a difference in how various people see the project, and while I don't want to venture too far into navel gazing, seeing this difference really helps underly the differences between how we approach tagging, and other aspects of the project. First, I think it's important to remember that I don't think anyone is advocating removing any existing object types or object classifications, but rather providing feedback to the tagging process about how best to represent something in OSM. To this extent and talking about the specific case, I agree with the author of the proposal that his solution is the best available method to represent the direction of an object. Others differ, and I accept that. Others disagree simply because it's not a tag, and I'm not ok with that. In other words, no one's talking about taking relations away, but putting the breaks on a bit where it comes to making new relation types. I agree on this. But, judging from the discussion that ensued, it seems that no new relation should be used because it's hard to edit, and this seems a wrong approach to me. Now onto your concern about dumbing down OSM. Honestly, I don't like that term, because it implies that simple = dumb. That's just not true. I think it is true, in this case. When you make something simpler than it was, there may be two reasons for that. The first is that the current approach is overly complicated, and streamlining it would make it smarter, more stable, less error prone. The second is that you just want to make it less error prone. While this is a noble intent anyway, you have to make sure that you're not removing flexibility, otherwise you're making it simpler AND dumber. Newcomers have a hard time understanding C++ templates (experts make errors too, sometimes). Does this mean that they should be removed from the standard? No, because, as steep their learning curve is, there's a whole lot of stuff that couldn't be done without templates - or that could be done in much more complicated ways. So, what does this mean? That users should be more educated, and while they're not they should limit themselves to easier things. Of course, the advanced features would have to be made somehow transparent to them: if I'm a newbie and am barely able to add a name=* tag, in case I edit an object that is part of a relation then the editor should allow me to do so with the minimum possible interference on the relation. When I first got into Linux, I had to compile a new kernel when I got new hardware, and if I changed monitors, I had to edit the X config myself by hand. Now I don't do that. I'm not any dumber. This doesn't mean that Linux got simpler. I remember having to measure the physical size of my Full-HD monitor in order to set the correct physical resolution into I-can't-remember-which config file. Hopefully, now the process is *easier* because there are better tools, or because someone wrote down the physical size of most monitors. This doesn't mean that the process is *simpler*. I was glad to see an installer tool with a GUI in Kubuntu: dpkg and its options, though commonly used, were not simple at all. But the GUI is probably just offering a visual checkbox and translates that to an option in the command line for dpkg. This is what should be done with OSM too for newcomers: better tools. In his recent talk, Andy Allen presented an excellent case for why we need more mappers, and the value of a simple, clean interface for mappers: http://sotm-eu.org/talk?52 When I've taught mappers, I've come to the conclusion that keeping things simple is the best way to encourage more mappers to map, and more mappers means more accuracy and more detail. I agree to a point. Now of course I'm not going to discuss the policies on recruitment of new mappers, but I'm not sure that lowering the learning curve would be all good. Having to learn how to map what you're interested in may work as a bit of lock-in: it took you one hour to learn about this on the wiki, and you've been trying and getting feedback on your attempts for two weeks, now tell me you're going to give up mapping because you're bored with it! On the other hand, I know people who started mapping by drawing lines and marking the street names, and left after a week, because they lost their shallow interest and felt they were ok with the small contribute they had given. Not that their contribute is to be rejected, but what's the point in having new mappers who abandon the project in a week? But it's not just entirely new mappers that we're talking about, but experienced mappers
Re: [Tagging] Relations (was directions)
Simone Saviolo wrote: Ok, but there are use cases where simple things don't suffice. In the case at hand, for example, using something like direction=forward doesn't work in all the use cases. And using direction=angle in degrees is in no way simpler (can you figure a newcomer trying to work out the angle? What's the reference? Should I use degrees, decimal degrees, radians? Should I use minutes and seconds for the fractional part (the horror)? Should I be content with something like direction=225 or be more precise and use direction=221,32? You know what, nevermind, I'll use Streetview instead). Now, *this* is something that can be abstracted away by tools much more easily than relations. The unit issue has already been neatly solved by editors such as Potlatch 2, and I can imagine how I would design a nice dialog for editing tags with angular values. I have no idea how to even approach a similarly user-friendly editing tool for direction relations. (If you are really into GUIs, you could even build some kind of rotate node feature into the editor that lets you rotate the traffic-sign/bench/... icon, where the rotation represents the direction angle.) A major advantage of tags compared with relations is that they don't affect other objects, which has all sorts of benefits (object history easier to understand, no unexpected side effects when I move a node of the road, ...). Tag-based solutions also cope better with the absence of editor support: If my editor doesn't have the nice visual rotate node feature, I will have somewhat a harder time editing the direction tag, but it does in no way affect my ability to edit any other tag. Editing anything remotely associated with a relation (even if the edit is not related to the purpose of the relation!) is annoying. Relations should therefore be avoided in favor of tags if possible. And I'm far from convinced that relations are necessary in the particular example that started this thread. -- Tobias Knerr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations (was directions)
2011/8/10 Tobias Knerr o...@tobias-knerr.de Simone Saviolo wrote: Ok, but there are use cases where simple things don't suffice. In the case at hand, for example, using something like direction=forward doesn't work in all the use cases. And using direction=angle in degrees is in no way simpler (can you figure a newcomer trying to work out the angle? What's the reference? Should I use degrees, decimal degrees, radians? Should I use minutes and seconds for the fractional part (the horror)? Should I be content with something like direction=225 or be more precise and use direction=221,32? You know what, nevermind, I'll use Streetview instead). Now, *this* is something that can be abstracted away by tools much more easily than relations. The unit issue has already been neatly solved by editors such as Potlatch 2, and I can imagine how I would design a nice dialog for editing tags with angular values. I have no idea how to even approach a similarly user-friendly editing tool for direction relations. Look at the turnrestrictions plugin for JOSM. When you use it, you can even have no idea that there's a relation involved. A major advantage of tags compared with relations is that they don't affect other objects, which has all sorts of benefits (object history easier to understand, no unexpected side effects when I move a node of the road, ...). Yes and no. Relations exist for the exact purpose of binding objects that are supposed to be bound. If I map a speed camera and use the relation, I'll set a node as from and another one as to; if then I get better data and I move those two nodes, the relation is still valid and it is automatically updated. On the other hand, if I had used something like, for example (it's not a real tag, just an example), distance_from_road_margin=2 to specify where the speed camera is, I would have to move the nodes accordingly, or to edit the value of the tag, and if I forget one of the two, or if I do it incorrectly, I have invalid data. As to object history, relations are above objects. A node that represents an intersection is there because it is an intersection; it may be moved or tags may be applied, the road may change its classification, whatever, and all of these changes should be tracked in the history of the node. When that node becomes the member of a turn restriction relation, what happens to the relation should not be recorded in the history of the node. If the node is changed and the turn restriction still applies, the history of the node will have all the relevant information, and the history of the relation will have all the relevant information (relevant to the relation, of course, i.e. no change). Regards, Simone ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Relations (was directions)
On Tue, Aug 9, 2011 at 10:11 AM, Ilya Zverev zve...@textual.ru wrote: Of course. When you get to the road you'll see its surface and lane count, Lane count and surface are useful for many things: For routing, for rendering, for analyzing traffic and capacity. Tell me what direction is useful for other than 3d rendering. OSM offers many perspectives. From the perspective of routing the direction of road sign is important. How? From the perspective of 3D rendering physical attributes and rotation are important. OSM has stopped being just a map the moment someone specified building levels count. OSM isn't a 3d representation of the earth. It's a 2d representation, and a rough one at that. The problem with a direction tag is that then suddenly every object has a direction relation, and we make editing the map far more complex. The problem with a name attribute is that then suddenly every object has a name tag, and we make editing the map far more complex. This is not a proposal's problem, but with relations in general, I guess? YES! Relations are a solution that should only be used as a last resort. They cause many many problems. We have to use them but before we do we should ask ourselves: 1. Is this data representable some other way? Through tagging for example? 2. What is the relationship I'm building my relation on? A relation describes relationships. What are my objects and their role to each other? 3. Is this something people will find useful other than me? 4. How would I code support for this? Since relations are complex, maybe spend some time in the PL2/Josm code and think about how you'd build a UI for it, and maybe think about how a renderer would support it, not just in theory but in practice. Should we reduce their count to mininum, creating alternative ways to map turn restrictions, destination signs, surveillance cameras, public transport routes? Yes!!! Relations are overused in OSM, and it causes a huge amount of difficulty in spreading mapping. I am often editing relations that other people make; they're often broken. They're broken because it's hard to make them correctly, and fixing a relation isn't easy- you have to break the objects apart, check their roles, check their construction, and reassemble the objects. Relations make the map hard to work with. Let's take your example. Let's say I find a road need to be split and fixed because of construction. Now I have to worry about the relations on that road, and check each and every segment that's created. I'll tell you that many mappers won't do that, which means that the relations won't be right. What's left is bad data. It's like an abandoned wiki. The more I fix other's data, the more clear these problems appear. - Serge ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations (was directions)
On Tue, Aug 9, 2011 at 4:44 PM, Serge Wroclawski emac...@gmail.com wrote: A big +1. I'm afraid that people promoting relations (once they understand the concept, they want to use it everywhere) are not the one editing often the map data ... Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations (was directions)
2011/8/9 Pieren pier...@gmail.com On Tue, Aug 9, 2011 at 4:44 PM, Serge Wroclawski emac...@gmail.comwrote: A big +1. I'm afraid that people promoting relations (once they understand the concept, they want to use it everywhere) are not the one editing often the map data ... -1. I use them often, and I would like to see them used more. They're not that difficult to deal with with current editors (I'm thinking JOSM, which automatically adds split ways to the relation and asks what to do when joining multiple ways). Regards, Simone ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations (was directions)
On 8/9/2011 10:44 AM, Serge Wroclawski wrote: Relations are overused in OSM, and it causes a huge amount of difficulty in spreading mapping. I am often editing relations that other people make; they're often broken. They're broken because it's hard to make them correctly, and fixing a relation isn't easy- you have to break the objects apart, check their roles, check their construction, and reassemble the objects. Relations make the map hard to work with. Let's take your example. Let's say I find a road need to be split and fixed because of construction. Now I have to worry about the relations on that road, and check each and every segment that's created. I'll tell you that many mappers won't do that, which means that the relations won't be right. What's left is bad data. It's like an abandoned wiki. The more I fix other's data, the more clear these problems appear. I agree completely with this. Relations need to be used sparingly, redundantly wherever possible (e.g. ref/rcn_ref/etc. tags on ways for route relations), and it should be easy to find and fix errors. It might be useful if the API and editing software treated relations 'transparently' as tags, kind of like Potlatch 1 does. Any request to the API for an object would also return a list of the relation IDs it is a part of, the role it has, and the tags of the relation (but not all the members). (Would this significantly increase processing or downloading time? If so, maybe the tags on the relation could be dropped.) Uploading an object would also require this information, or a conflict would be created. JOSM needs better relation conflict management. I find that most relation breaking is due to splitting or joining ways without updating relation membership for various reasons, such as JOSM not knowing the relation is there or a mapper ignoring a conflict because it's too hard to fix. As for the direction a sign faces, perhaps an alternate plan would be to map the sign as a way (this is, after all, correct in a micromapping sense) and define which side has the text (or if both sides have text, which text is on which side). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations (was directions)
On 8/9/2011 10:44 AM, Serge Wroclawski wrote: Relations make the map hard to work with. Agree - one of the barriers to entry by new mappers is the complexity. We need to do everything possible to keep it simple and usable. And not just by creating ever-more-complex models and updating all the editors to keep pace. 3rd party companies create fancy tools and see that it's a good idea to have it inter-operate with OSM data, until it's time to dive into relations: http://forum.openstreetmap.org/viewtopic.php?id=13377 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Relations (was directions)
2011/8/9 Mike N nice...@att.net On 8/9/2011 10:44 AM, Serge Wroclawski wrote: Relations make the map hard to work with. Agree - one of the barriers to entry by new mappers is the complexity. We need to do everything possible to keep it simple and usable. And not just by creating ever-more-complex models and updating all the editors to keep pace. 3rd party companies create fancy tools and see that it's a good idea to have it inter-operate with OSM data, until it's time to dive into relations: http://forum.openstreetmap.org/viewtopic.php?id=13377 Allow me to disagree. I found it difficult to understand English when I was at the elementary school, but this has never been a reason to remove all those complicated things I didn't get. I learned and I got better, to the point that I can read and write well enough to understand and make me understand. The same goes for OSM: if we make a system that any newcomer can use completely without even having to dwelve into the details, then we're basically dumbing it down and limiting its potential. I'd rather like to see a tagging philosophy that creates a two-layered approach: a simpler model that anyone can easily use, and a more advanced, flexible and detailed one for more experienced users. Regards, Simone ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
