Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Am 28.06.2015 um 08:34 schrieb Jo: ... As far as the datatypes go, I would be all in favor for the area datatype. I hear a lot of talk about it, and I don't understand why it doesn't materialise. While we're at it, we should 'formalise' a few more of the things we now use relations for. ... Because it is not just a question of hand waving? On the one hand there's the task of finding a way of modelling areas that is net an improvement over what we have today. We have lots of proposals that improve certain aspects of our current model, but at the cost of worse behaviour for other aspects. I yet have to see a proposal that is convincing enough overall*. On the other hand, actually migrating to a new area type is going to be a major undertaking in itself and my gut feeling is that it will be the only dev thing we will be working on for at least a year once we start and there will be a lot of stuff that will never be migrated. And that all without actual gain in what we can model in OSM. Simon * note: for large areas I would consider Zveriks area references a good solution that would generalize and replace the current magic tags (coastline and others) and could be implemented without actually introducing an area type. signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Jo wrote: even more sorry you stopped being the lead developer of iD For the record: the mantle of lead developer of iD passed to Tom and John immediately after SOTM-US Portland because it was wonderfully clear that their JavaScript skills are pretty much on a different planet to mine, and I was delighted to see them take up the torch. My reluctance to continue work on OSM editing software dates from before this, as you can see if you look at the commit graphs of both proto-iD and Potlatch 2. This is why I was so keen in summer 2013 to get iD made the default instead of Potlatch 2: so that the burden of maintaining the default editor could pass to someone else and I wouldn't have to endure the shit flung at the holder of that role any more. I think you, and others, need to consider why it's only those with the thickest skins that are prepared to work on OSM site (and, particularly, online editor) development. I am not the only one to have burned out. You have your own views. That's fine. Your view is that there is a problem. That is not objective truth, that is your view and it may or may not be informed by actual facts. Others may believe that the main challenge for OSM is to be welcoming enough for a million new users to contribute their local knowledge - not to provide more and more detailed methods for a diminishing number of power users to map the locations of angels on a pin, without ever being troubled by thoughts of how new users will interact with those detailed methods. That too is not objective truth, it is a view (it happens to be mine). What is unacceptable is the relentless, harrying, dismissive, abusive manner in which you and others advance the former view over the latter. That is why we cannot retain developers. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Hi Bryce, I'm glad I'm not the only one who is of this opinion. You probably formulated it a lot better than I ever did in the tickets to complain about this behaviour. Anyway Richard, I respect you a lot, but if I notice there is a problem, nobody can expect me/us to remain quiet about it. So I'm sorry for being the bane in your existence and even more sorry you stopped being the lead developer of iD, apparently in part due to these kinds of criticism. As far as the datatypes go, I would be all in favor for the area datatype. I hear a lot of talk about it, and I don't understand why it doesn't materialise. While we're at it, we should 'formalise' a few more of the things we now use relations for. Also it ought to become possible to construct routes from smaller route parts, such that these parts can be reused to construct other routes. When the smaller parts then break, it only takes 1 or 2 repairs instead of 10-100. If the itinerary changes for several bus lines at once, it would also become a lot less effort to update the routes. Kind regards, Polyglot 2015-06-28 7:31 GMT+02:00 Bryce Nesbitt bry...@obviously.com: On Sat, Jun 27, 2015 at 10:49 AM, Tom MacWright t...@macwright.org wrote: Okay, but most relations are invisible. Relations are visible* if the editor makes them visible.* The iD editor introduced an entirely synthetic primitive: the area. Thus, in iD, the area is visible. The iD editor, or an editor like it, could introduce a grouping, and make it visible. Relations are not only possible to visualize, they're interesting, Click on Main Street and see the 12 bus lines that use Main street? Interesting. Click on a line and learn it forms the USA/Canadian Border, 8,891 km long, consisting of 5000 odd line segments? Interesting and instructive. A series of iD plugins for visualizing specific types of relations would rock. And of course in iD style they'd be called something different, like, say, Turn Restrictions or a Public Transit Route or Site or a Level 8 Administrative Boundary between X and Y. The word relation need never come into it. -- By all-but-ignoring relation editing, Potlach and iD only make it easy to ignore or even *damage* relations. It's all downside. That's not what you want for entry level editing. A good experience for a starting user is they made a positive contribution, they saw the results rendered, and they did not mess anything up. When the editor makes messing up an invisible single click (or inadvertent click) operation, it leads to stress all around. Relations are invisible only in editors that* leave them in the shadows.* An editor that ignores or tries to hide a thing is unlikely to be the best way to edit (or preserve) the invisible thing. It's a form of fake simplicity: making a given edit seem to be simpler than it really can be. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
On Sun, Jun 28, 2015 at 4:03 AM, Richard Fairhurst rich...@systemed.net wrote: What is unacceptable is the relentless, harrying, dismissive, abusive manner in which you and others advance the former view over the latter. That is why we cannot retain developers. We really need to be careful to target the philosophical standpoint, not the people. As I said (now countless times), iD is awesome. I don't think I've been criticizing developer talent or code quality. I wouldn't have provided most of its translations into my language if I thought differently. Anyway, should this conversation be about iD? In a way yes, but not only. Other editors (except JOSM) seem to have the same aversion of relations. Relations are valuable and are not going away, several of them (the most critical being route) have been approved long ago by the community (by consensus, by public voting), so I believe fighting them only make things worse. Fighting them is fighting the community. Others, such as boundary, are de facto standards. They have to be properly tamed. One way is to hide them so that only clever people can deal with them. Another is to teach everybody in the simplest possible manner so that they become widely accessible. Cliché quote: Make things as simple as possible, but not simpler, some attribute to Einstein. When people are deleting and combining ways, they are editing invisible data - tags and parent relations. In a world without relations, combining different tags would still be an issue. For instance, the sidewalk tag is not visible. It should be visible. If it ever becomes visible, there is still a huge repository of approved tags that won't be. The current approach - concatenation - is essentially invisible in many situations (the user must pay a lot of attention at the result). I would like to see a scenario where a casual mapper (the target audience of all editors besides JOSM) would prefer not to be notified about a potential mistake. I do mapping sprints very often, I'm knowledgeable, and even so I prefer to get interrupted in my mapping whenever I do something potentially damaging. Without that, even with my experience, I would have broken data multiple times. How is that casual mappers would prefer not to have that? It is a contradiction to design the application for casual mappers and still place fastest mapping at utmost priority. A casual mapper is not aware of the data model, and should not be expected to be so. Back to the problem that motivated me into this discussion: I see that the problem in iD is really easy to solve (much easier than in Potlach). If there is an objection to an interaction-blocking modal window, other non-blocking visual cues can be used, such as a distinctive alert bar at the bottom, an alert icon at the action button, and an alert log on top after an action breaks something. Anything that informs the user is fine. It is not done only due to a philosophical opinion, which I think is negative to OSM as a whole. The opinion is negative, not the people that hold it. Maybe people are also being idealistic: instead of implementing a little workaround, they'd rather wait and see if a cleverer, less intrusive solution emerges. It is clearly not happening, after two years of waiting and wondering by the most involved minds in the project. Getting a simple alert when deleting relation members was a huge struggle. Since combining implies deleting I don't think the current issue should need to be so widely discussed. The only reason I don't set out and try writing my own editor (which is a pretty big undertaking) is that my country's map still needs lots of data, and my country's community still needs lots of support. Potlatch, iD and JOSM have solved that, mostly. All I ask for is a minor refinement, which I believe is good not only here but in the whole world. -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
I see that the problem in iD is really easy to solve (much easier than in Potlach). Please never say this. Estimating that someone else's task, in their domain of experience, is simple, is almost always incorrect, and usually overstepping. This painting looks pretty easy to paint: can you finish it in an afternoon. If something is easy to do, please try doing it yourself and seeing whether it is. Otherwise, don't tell other people that things should be easy for them to do, so they should do what you want. People have been saying for quite a while that it would be pretty easy for us to improve the software that manages and edit OpenStreetMap, but none of them have decided to do it in an afternoon, much less own the responsibility of maintaining and defending the changes. iD has, to date, consumed thousands of hours of developer time, communications, documentation authoring, and design. The same goes for Potlatch and JOSM and the website. Developing these projects is even more time-consuming because every change needs to be discussed to death, everyone must be consulted, and then after release, we have to catch up with all of the people who want to be consulted but don't read the mailing list. In short, if you believe this is easy, do it. Otherwise, don't underestimate other people's tasks. On Sun, Jun 28, 2015 at 2:34 PM, Fernando Trebien fernando.treb...@gmail.com wrote: On Sun, Jun 28, 2015 at 4:03 AM, Richard Fairhurst rich...@systemed.net wrote: What is unacceptable is the relentless, harrying, dismissive, abusive manner in which you and others advance the former view over the latter. That is why we cannot retain developers. We really need to be careful to target the philosophical standpoint, not the people. As I said (now countless times), iD is awesome. I don't think I've been criticizing developer talent or code quality. I wouldn't have provided most of its translations into my language if I thought differently. Anyway, should this conversation be about iD? In a way yes, but not only. Other editors (except JOSM) seem to have the same aversion of relations. Relations are valuable and are not going away, several of them (the most critical being route) have been approved long ago by the community (by consensus, by public voting), so I believe fighting them only make things worse. Fighting them is fighting the community. Others, such as boundary, are de facto standards. They have to be properly tamed. One way is to hide them so that only clever people can deal with them. Another is to teach everybody in the simplest possible manner so that they become widely accessible. Cliché quote: Make things as simple as possible, but not simpler, some attribute to Einstein. When people are deleting and combining ways, they are editing invisible data - tags and parent relations. In a world without relations, combining different tags would still be an issue. For instance, the sidewalk tag is not visible. It should be visible. If it ever becomes visible, there is still a huge repository of approved tags that won't be. The current approach - concatenation - is essentially invisible in many situations (the user must pay a lot of attention at the result). I would like to see a scenario where a casual mapper (the target audience of all editors besides JOSM) would prefer not to be notified about a potential mistake. I do mapping sprints very often, I'm knowledgeable, and even so I prefer to get interrupted in my mapping whenever I do something potentially damaging. Without that, even with my experience, I would have broken data multiple times. How is that casual mappers would prefer not to have that? It is a contradiction to design the application for casual mappers and still place fastest mapping at utmost priority. A casual mapper is not aware of the data model, and should not be expected to be so. Back to the problem that motivated me into this discussion: I see that the problem in iD is really easy to solve (much easier than in Potlach). If there is an objection to an interaction-blocking modal window, other non-blocking visual cues can be used, such as a distinctive alert bar at the bottom, an alert icon at the action button, and an alert log on top after an action breaks something. Anything that informs the user is fine. It is not done only due to a philosophical opinion, which I think is negative to OSM as a whole. The opinion is negative, not the people that hold it. Maybe people are also being idealistic: instead of implementing a little workaround, they'd rather wait and see if a cleverer, less intrusive solution emerges. It is clearly not happening, after two years of waiting and wondering by the most involved minds in the project. Getting a simple alert when deleting relation members was a huge struggle. Since combining implies deleting I don't think the current issue should need to be so widely discussed. The only reason I don't set out
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Perhaps I expressed myself poorly. Previous arguments surrounded exclusively on should this be done or why it shoudln't be done. The easy word refers only to how should user interaction flow be in order to avoid breaking relations, without resorting to non-trivial dependency analysis algorithms (which, definitely, are more complex than adding a message or disabling a button upon a simple check that is mostly already implemented). On Sun, Jun 28, 2015 at 4:07 PM, Tom MacWright t...@macwright.org wrote: I see that the problem in iD is really easy to solve (much easier than in Potlach). Please never say this. Estimating that someone else's task, in their domain of experience, is simple, is almost always incorrect, and usually overstepping. This painting looks pretty easy to paint: can you finish it in an afternoon. If something is easy to do, please try doing it yourself and seeing whether it is. Otherwise, don't tell other people that things should be easy for them to do, so they should do what you want. People have been saying for quite a while that it would be pretty easy for us to improve the software that manages and edit OpenStreetMap, but none of them have decided to do it in an afternoon, much less own the responsibility of maintaining and defending the changes. iD has, to date, consumed thousands of hours of developer time, communications, documentation authoring, and design. The same goes for Potlatch and JOSM and the website. Developing these projects is even more time-consuming because every change needs to be discussed to death, everyone must be consulted, and then after release, we have to catch up with all of the people who want to be consulted but don't read the mailing list. In short, if you believe this is easy, do it. Otherwise, don't underestimate other people's tasks. On Sun, Jun 28, 2015 at 2:34 PM, Fernando Trebien fernando.treb...@gmail.com wrote: On Sun, Jun 28, 2015 at 4:03 AM, Richard Fairhurst rich...@systemed.net wrote: What is unacceptable is the relentless, harrying, dismissive, abusive manner in which you and others advance the former view over the latter. That is why we cannot retain developers. We really need to be careful to target the philosophical standpoint, not the people. As I said (now countless times), iD is awesome. I don't think I've been criticizing developer talent or code quality. I wouldn't have provided most of its translations into my language if I thought differently. Anyway, should this conversation be about iD? In a way yes, but not only. Other editors (except JOSM) seem to have the same aversion of relations. Relations are valuable and are not going away, several of them (the most critical being route) have been approved long ago by the community (by consensus, by public voting), so I believe fighting them only make things worse. Fighting them is fighting the community. Others, such as boundary, are de facto standards. They have to be properly tamed. One way is to hide them so that only clever people can deal with them. Another is to teach everybody in the simplest possible manner so that they become widely accessible. Cliché quote: Make things as simple as possible, but not simpler, some attribute to Einstein. When people are deleting and combining ways, they are editing invisible data - tags and parent relations. In a world without relations, combining different tags would still be an issue. For instance, the sidewalk tag is not visible. It should be visible. If it ever becomes visible, there is still a huge repository of approved tags that won't be. The current approach - concatenation - is essentially invisible in many situations (the user must pay a lot of attention at the result). I would like to see a scenario where a casual mapper (the target audience of all editors besides JOSM) would prefer not to be notified about a potential mistake. I do mapping sprints very often, I'm knowledgeable, and even so I prefer to get interrupted in my mapping whenever I do something potentially damaging. Without that, even with my experience, I would have broken data multiple times. How is that casual mappers would prefer not to have that? It is a contradiction to design the application for casual mappers and still place fastest mapping at utmost priority. A casual mapper is not aware of the data model, and should not be expected to be so. Back to the problem that motivated me into this discussion: I see that the problem in iD is really easy to solve (much easier than in Potlach). If there is an objection to an interaction-blocking modal window, other non-blocking visual cues can be used, such as a distinctive alert bar at the bottom, an alert icon at the action button, and an alert log on top after an action breaks something. Anything that informs the user is fine. It is not done only due to a philosophical opinion, which I think is negative to OSM as a whole. The opinion is
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
2015-06-28 20:34 GMT+02:00 Fernando Trebien fernando.treb...@gmail.com: On Sun, Jun 28, 2015 at 4:03 AM, Richard Fairhurst rich...@systemed.net wrote: When people are deleting and combining ways, they are editing invisible data - tags and parent relations. In a world without relations, combining different tags would still be an issue. For instance, the sidewalk tag is not visible. It should be visible. If it ever becomes visible, there is still a huge repository of approved tags that won't be. The current approach - concatenation - is essentially invisible in many situations (the user must pay a lot of attention at the result). I would like to see a scenario where a casual mapper (the target audience of all editors besides JOSM) would prefer not to be notified about a potential mistake. I do mapping sprints very often, I'm knowledgeable, and even so I prefer to get interrupted in my mapping whenever I do something potentially damaging. Without that, even with my experience, I would have broken data multiple times. How is that casual mappers would prefer not to have that? It is a contradiction to design the application for casual mappers and still place fastest mapping at utmost priority. A casual mapper is not aware of the data model, and should not be expected to be so. Trying to be a bit objective here: I have been teaching someone to edit OSM with iD and he was demotivated by the warnings he got when clicking Save. He then had to try to find out where the errors were, failed to do so and gave up. I told him to just upload it and I fixed it myself. So I believe that thinking you are ready and then having to deal later with mistakes you made earlier is highly demotivating. Eventually I convinced him to take the leap to JOSM. I had to explain how the data is represented and it took him more time to learn (note that JOSM made him eager to learn more about the actual data structures!), but now he is more confident in editing ways. I have not explained relations yet though and he broke some last week, by merging ways (one was in a route relation and the other not). I tried this and JOSM does not give any warning at all when you do that in expert mode, but it does in non-expert mode. Apparently it was not clear enough that data would break. My conclusion is that editors should not try to hide too much, but be didactic. Ideally they should confront mappers with what exactly the consequences are of a certain action (and I realize this is very hard to do, with the freedom of tags and such). In this case, a map with the effect on the relation could have been shown. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
An onboarding guide which explains relations to the extent that a mapper could confidently edit them would be quite a bit more than that. Welcome to OpenStreetMap! This is a visual editor which lets you define things that you see in the world and their spatial component, specifically in a map form. However, the most important part of the map is a non-visible semantic relational attribute of the data. These relations are abstract groups that can contain zero elements, or thousands. They can contain other relations. Maybe they can even contain themselves. Almost all of the time, a relation with zero members is a mistake, except for one case where it isnt.[2] The distinction between relations as a bug in the data and as a legitimate, complex semantic statement is not something we can autodetect, so use your judgment. Cool: let's start editing relations. Well, first, earlier we said that relations aren't spatial. Well, some are, some aren't. Maybe half and half. Some are used to structure multipolygon geometries. Okay, but most relations are invisible. You're editing the map, but the relation is for routing software or maybe a very large polygon which is limited by some technical limits that we'll get into later. Regardless, when you break those kinds of relations, you won't know, because you can't see the breakage on the map, only in some software that you probably aren't using. Great, so relations are groups of things that can be zero or many, for technical reasons, spatial relationships, or abstract relationships. Now we're getting started. Relations, unlike sets in math, are ordered. Unlike ordered sets, they also have special ways in which each element is contained. So they're kind of like ordered, semantic sets of potentially anything. And, typically, invisible. Now that we've discussed the basics of relations, let's cover each of the different kinds, including each kind's stipulations of what is contained, whether order matters, and the role tags that are unique to each use-case. ...You can see where this is going: I haven't started to explain what you use relations for, and we've already seen the sort of mountain of unpredictable complexity they add to the OpenStreetMap data model - one of the fundamental things that makes it both more powerful than most data models and incompatible with all other data models. The problem coming from the building an editor perspective is that relations add a level of complexity to the question of not breaking data that wholly explains why it's such a rarely attempted feat to edit all openstreetmap data. I would love if this problem were fixable with documentation, but unfortunately, this is actually just a deep issue that isn't easy to document, and iD would still be grilled on the regular for not preventing people from doing things. The data model could be improved in a few ways: if it embraced the long-awaited area datatype[1] and stopped using relations as a brittle stopgap around multipolygons and node limits. Or if it specified enforced well-established types of relations in such a way that the validity of an editor's approach was agreed-on rather than constantly argued about. And it's not that I hate relations: they are truly one of the only successful instances of linked data in the entire world of computers. They're also a legitimate reflection of the world's actual complexity. But reconciling their ephemeral, non-visual, intensely-freeform properties with the ideal of a map of the world everyone can edit is not a simple matter. Tom [1]: http://blog.jochentopf.com/2012-11-26-an-area-datatype-for-osm.html [2]: http://wiki.openstreetmap.org/wiki/Empty_relations On Sat, Jun 27, 2015 at 12:58 PM, Fernando Trebien fernando.treb...@gmail.com wrote: This is surely going to spur controversy, but here I go. Imagine a world in which a new mapper opens its (newly-discovered) favourite editor and is presented with the following message the first time they edit anything: You can map using points and relations. Relations are groups of things with specific roles: groups of points make lines, groups of lines can make things like routes bus routes, city boundaries, hollow buildings, turn restrictions, etc., groups of routes can make route networks. Mappers rarely group further, but they could. Because lines are very common, you can draw them by simply adding many points one after another. If you want to make more complex relations such as routes and boundaries, check out the relation editor. Of course, such an editor would have to be designed with that philosophy in mind from the start. Is this a rant? Not really, this a sincere impression I've had for a very long time. Many novice users are confused by relations because they need to build their understanding later, often when someone complains they've made some mistake. When this notion of grouping is presented at the very beginning, I believe people will easily understand it for
[OSM-talk] Mappers and apps should focus on relations at the very start
This is surely going to spur controversy, but here I go. Imagine a world in which a new mapper opens its (newly-discovered) favourite editor and is presented with the following message the first time they edit anything: You can map using points and relations. Relations are groups of things with specific roles: groups of points make lines, groups of lines can make things like routes bus routes, city boundaries, hollow buildings, turn restrictions, etc., groups of routes can make route networks. Mappers rarely group further, but they could. Because lines are very common, you can draw them by simply adding many points one after another. If you want to make more complex relations such as routes and boundaries, check out the relation editor. Of course, such an editor would have to be designed with that philosophy in mind from the start. Is this a rant? Not really, this a sincere impression I've had for a very long time. Many novice users are confused by relations because they need to build their understanding later, often when someone complains they've made some mistake. When this notion of grouping is presented at the very beginning, I believe people will easily understand it for all of the advanced scenarios (the most common being routes and boundaries). It would just be didactic. Some people have even proposed abolishing the way entity from OSM's API and replacing it with a relation type=way with node members. Some logic (such as checking for empty ways/empty relations and checking membership across different entities) would be simplified, which would be good for database maintenance. It would also be good for app development, apps would have to understand relations from the very start and would thus be encouraged to support advanced features. That would be very little extra development overhead compared to just points and lines. I understand that very big relations with lots of nodes and a single role for all of them would be undesirable. Apps like the editor can still make the way entity transparent to the user, so an API change is not really required for a change in editor/mapper mindset. Still, I raise this aspect because, in an abstract sense that mappers do need to develop, ways are simply a type of relation, and they could be concretely so. Relations cannot be abolished (there is no other way to represent bus/car/hiking/boat routes, or hollow polygons). Ways, in theory, can. -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Well, this was not targeted at iD since Potlatch and Merkaator (and probably others) suffer from the same problem. Making the user understand the simple membership logic would be a great first step. The second one would be to develop apps (in particular, editors) that support all the variations you mentioned. Maybe they can even contain themselves. Actually no, the server checks for circular dependencies, and a relation pointing to itself is a cycle. Try it, the server returns a validation error. Almost all of the time, a relation with zero members is a mistake, except for one case where it isnt. That's misleading. The article [4] clearly says that such cases are either mistakes or placeholders (which could be considered mistakes as well). The distinction between relations as a bug in the data and as a legitimate, complex semantic statement is not something we can autodetect, so use your judgment. Not quite. JOSM's relation editor will show you when a route relation is broken and exactly where. It will also show you when the relation is a closed cycle, as expected from boundaries. So multipolygons and boundaries must have closed cycles and routes cannot be broken, this is easy to verify (just check if members are ways and if their start and endpoints match). JOSM also includes an algorithm to automatically sort members. That algorithm could even be used to automatically place a new member at the correct position, or to prevent an unconnected member from being added to the route. That would make sense in a basic editor where people are not expected to do advanced editing. JOSM prefers to let the relation get broken to let you work and issue a warning when validating data before submission in case you forgot something. Cool: let's start editing relations. Well, first, earlier we said that relations aren't spatial. The meaning of the vast majority of relations is spatial. Are lines spatial without their points? Is an empty line spatial? Well, some are, some aren't. Maybe half and half. Some are used to structure multipolygon geometries. Okay, but most relations are invisible. Great, so relations are groups of things that can be zero or many, for technical reasons, spatial relationships, or abstract relationships. Now we're getting started. Relations, unlike sets in math, are ordered. Unlike ordered sets, they also have special ways in which each element is contained. So they're kind of like ordered, semantic sets of potentially anything. And, typically, invisible. Now that we've discussed the basics of relations, let's cover each of the different kinds, including each kind's stipulations of what is contained, whether order matters, and the role tags that are unique to each use-case. ...You can see where this is going: I haven't started to explain what you use relations for, and we've already seen the sort of mountain of unpredictable complexity they add to the OpenStreetMap data model - one of the fundamental things that makes it both more powerful than most data models and incompatible with all other data models. Relations are lists of objects, each with an assigned role. They are used to represent areas with holes (called multipolygons), large boundaries, routes (roads, railroads, buses, trams, ferries, hiking, cycling, and waterways), and turn restrictions. [2][3] Multipolygons, boundaries and routes (including waterways) are all very common relations and they all represent spatial concepts do get rendered - at least by popular renderers like Carto. Restrictions are far less common (1/5th of occurences when compared to multipolygons, surely fewer than routes+boundaries combined). It's hard to say they do not represent a spatial/directional concept since the vast majority have a via point around which the restriction is placed. The remaining common types [1] that are also approved by the community [3] essentially fall in the category of invisible unordered sets: public_transport, route_master. It's hard to say that public_transport is not spatial, since the bounds of its members usually occupy a very narrow area. route_master is seldom broken because users rarely edit its member relations. You're editing the map, but the relation is for routing software or maybe a very large polygon which is limited by some technical limits that we'll get into later. If that's your view, why is that iD (and Potlatch) has a turn restriction editor? Isn't the interest in turn restrictions limited to routing software? Another very practical use of relations is to avoid having to overlap lines that match exactly. Editing areas and lines that overlap is very cumbersome in any editor, even in JOSM. Regardless, when you break those kinds of relations, you won't know, because you can't see the breakage on the map, only in some software that you probably aren't using. Which map are you talking about? The one the editor displays, the one on the main website, or some other apps'
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
On 27.06.2015 18:58, Fernando Trebien wrote: When this notion of grouping is presented at the very beginning, I believe people will easily understand it for all of the advanced scenarios The notion of grouping would at least be more intuitive the common relationship between things, which is very remote from how relations are often used. Still, it isn't really a natural fit for some relation types, e.g. building, bridge, tunnel, ... relations. So if we are discussing to re-frame relations in a more understandable fashion, I wonder if we shouldn't turn relations into *objects*. From the current OSM environment, it seems clear that preset-based user interfaces are popular. Mappers tend to grasp the concept of creating an object, then adding more information to it quite easily. So what if we base the data model around this? Imagine mapping a building. Currently, there is a stark contrast between the outline and the height of the building: One is a tag, and the other is a way, i.e. geometry. Values can be many things - text, distances, speed limits - but they cannot be geometry. If the building was an object, then both the height and the outline could be added as values of tags. Naturally, there could also be multiple keys with geometry values, resulting in the same expressive power as our relations - but in a much less scary wrapping. Of course, behind the scenes this would still look like a relation with tags and members. It's all in the presentation and ubiquity. I believe (a hypothesis that would be interesting to test) that this would make the more complex features of OSM significantly more accessible. So should we target this for API 0.7? Not really. I'm under no illusion that something like this could happen anytime soon. But imo it's an fascinating idea to think about. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
On 6/27/2015 1:14 PM, Fernando Trebien wrote: Actually no, the server checks for circular dependencies, and a relation pointing to itself is a cycle. Try it, the server returns a validation error. Nothing in the OSM data model prohibits a relation that references itself, or relations that form a cycle. As an example, see https://www.openstreetmap.org/relation/1368401 which contains itself twice. Longer cycles are also possible. I can't imagine a case where a cycle is sensible, and they are often difficult to delete, first requiring modifying the relations to remove the cycle, then deleting the relations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
Interesting, I remember long ago trying to upload (by accident) a set of relations with a cyclic dependency and receiving a server error. Maybe the message was phrased in a misleading way but the error was actually generated by JOSM. Will try again. Dependency checking must be aware of cycles, otherwise it may end up running an infinite loop. There are some other scenarios, such as retrieving a relation's incomplete members, where a self-reference can be problematic, but that's not the server's responsibility. I can't imagine right now any scenario where self-references or cyclic references woud be necessary to represent any information. (Not suggesting the the server should implement that check.) On Sat, Jun 27, 2015 at 9:03 PM, Paul Norman penor...@mac.com wrote: On 6/27/2015 1:14 PM, Fernando Trebien wrote: Actually no, the server checks for circular dependencies, and a relation pointing to itself is a cycle. Try it, the server returns a validation error. Nothing in the OSM data model prohibits a relation that references itself, or relations that form a cycle. As an example, see https://www.openstreetmap.org/relation/1368401 which contains itself twice. Longer cycles are also possible. I can't imagine a case where a cycle is sensible, and they are often difficult to delete, first requiring modifying the relations to remove the cycle, then deleting the relations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mappers and apps should focus on relations at the very start
On Sat, Jun 27, 2015 at 10:49 AM, Tom MacWright t...@macwright.org wrote: Okay, but most relations are invisible. Relations are visible* if the editor makes them visible.* The iD editor introduced an entirely synthetic primitive: the area. Thus, in iD, the area is visible. The iD editor, or an editor like it, could introduce a grouping, and make it visible. Relations are not only possible to visualize, they're interesting, Click on Main Street and see the 12 bus lines that use Main street? Interesting. Click on a line and learn it forms the USA/Canadian Border, 8,891 km long, consisting of 5000 odd line segments? Interesting and instructive. A series of iD plugins for visualizing specific types of relations would rock. And of course in iD style they'd be called something different, like, say, Turn Restrictions or a Public Transit Route or Site or a Level 8 Administrative Boundary between X and Y. The word relation need never come into it. -- By all-but-ignoring relation editing, Potlach and iD only make it easy to ignore or even *damage* relations. It's all downside. That's not what you want for entry level editing. A good experience for a starting user is they made a positive contribution, they saw the results rendered, and they did not mess anything up. When the editor makes messing up an invisible single click (or inadvertent click) operation, it leads to stress all around. Relations are invisible only in editors that* leave them in the shadows.* An editor that ignores or tries to hide a thing is unlikely to be the best way to edit (or preserve) the invisible thing. It's a form of fake simplicity: making a given edit seem to be simpler than it really can be. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
