Hi, > Reoccurring problem 1: Way splitting.
True, problem exists. However the opposite (having ONE way for the whole of a country-spanning motorway) is also undesirable. > not splitting the ways and giving parts of them > different properties with relations is not much better---there is no > support for including parts of a way in a relation, so the relations > will contain one way and (hopefully) two nodes You could also have a relation encapsulating a part of the way (way, from, to) and make THAT a member of another relation. > Reoccurring problem 2: Two side of a coin, oops, a way. Most ways have > two sides, often they are the same, but also often they are not. True, problem exists (and I have a bad feeling about all those "left/right" things). Two further recurring problems are (3) areas and how to split them into parts that can be handled (and how to know whether you're inside or outside), and (4) related ways like "a footway runs in parallel to this road, 25 metres from the left hand side". > So far for the problems. Please discuss my view on the problems (above) > independently from my ideas on solving them (below). Mixing discussions > on problem and solution usually lead to nothing. I find it slightly arrogant on your part to tell us in what way you would like us to discuss your ideas and which kind of discussion you believe leads to something and which doesn't. But I'll gloss over that for now. > Let's see how it changes with some additions: > > <way id="35" ...> > <nd ref="1"/> > <nd ref="22" p="P1"/> > <nd ref="333" p="P2"/> > <nd ref="4444"/> I still don't see why you would need P1 and P2. You could have <tag k="foo" v="bar" from="22" to="333" /> and it would work just as well. Your whole proposal is surely one valid way to go. But I think the data model is burdened enough as it is. Why ram ever more functionality into the data model? We are already at the point where you need editors to help you work with the data. Why should the user care whether segmented tags as you describe them are actually stored as part of the way (which will, by the way, incur a change to the whole way object whenever something is changed even for a small part), or whether a new relation object is created for every single segmented tag? We're all too technical-thinking here I believe. The question is not how we put things in the data model. The introduction of relations was necessary to preserve integrity but now any complex constructs can be built using relations, if one so desires. (I'm not saying we must not change the data model at all, I'm just saying it is not the focus.) The important question is not how we stuff things into XML or SQL. The important question is how do we make these concepts available to the user of the editor. And we're only starting. JOSM's user interface requires too much knowledge about intricate details, and creating segmented tags using relations is really impractical. But once we have a good user interface, creating the necessary relations behind the scenes would be easy. And for renderers and other users it would also be no different in complexity whether we do one or the other. > Q: Implementation or we're not interested. > > A: Sure, give me a SVN account and I'll change the server software. I'd > also need an admin account for the main server. And YOU'LL take the > blame that starting next week not a single client will be able to talk > to the server, won't you? This, again, is a bit harsh, as people *have* actually taken the server and editor code in the past, created a working system on their own machines, and presented it to OSM users to play with. You don't have use the live system to build a proof of concept. But as I said, I believe the problem is not the data model but the user interface. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk