Re: [OSM-talk] Proposed Relations
Frederik Ramm wrote: 2. I want relations to become ordered and will try to sneak this into API 0.6; there will be no noticeable change for any API client, just that it so happens that things are returned in the order you put them in, rather than in any order. There is one noticeable change here to clients: if they download such an ordered relation, and upload a newer version, they should have kept the ordering intact. The current unordered relations mean that a client can store it locally however it likes, and upload it in a completely different order, and it won't make one iota of difference to anyone. That assumption would become invalid. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
Hi, 2. I want relations to become ordered and will try to sneak this into API 0.6; there will be no noticeable change for any API client, just that it so happens that things are returned in the order you put them in, rather than in any order. There is one noticeable change here to clients: if they download such an ordered relation, and upload a newer version, they should have kept the ordering intact. The current unordered relations mean that a client can store it locally however it likes, and upload it in a completely different order, and it won't make one iota of difference to anyone. That assumption would become invalid. True but this only applies as soon as ordering is actually used. Currently everyone has to assume that they get the data back shuffled, and whether that shuffling was done by the API (as it is now) or by an order-unaware client doesn't make a difference. Of course, as soon as we use that new feature, clients will be expected to respect ordering. 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
Re: [OSM-talk] Proposed Relations
Frederik Ramm wrote: True but this only applies as soon as ordering is actually used. That's why I said it would _become_ invalid. It is not an issue right now. Currently everyone has to assume that they get the data back shuffled, and whether that shuffling was done by the API (as it is now) or by an order-unaware client doesn't make a difference. Of course, as soon as we use that new feature, clients will be expected to respect ordering. How would you detect order-unaware clients uploading such an ordered relation? There is no capability exchange between client and server, so you can't know if the client is order-aware. Or would you propose that any client using API 0.6 is order-aware at the moment of the official migration to 0.6? Next to the mainstream editors, you'd also still have the issue of broken clients, scripts, bots. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
Hi, Ldp wrote: How would you detect order-unaware clients uploading such an ordered relation? I wouldn't bother. My timeline: 1. Build the feature into API 0.6 and tell nobody about it. Nobody will notice, nobody has to change what he does. 2. Make sure the big three editors support ordering. Nobody will notice, nobody has to change what he does. Also, try and get Osmosis and the various mirror services (ROMA, XAPI) to support ordered relations. 3. Once this is working to a sufficient degree, announce that ordered relations are now possible (if required, issue some caveats like but doesn't work in XYZ yet), and would anyone using their own client or a niche editor please make sure to respect this. 4. If someone messes things up, the human beings involved can sort that out. It is not the API's responsibility to make sure that clients work correctly. I'm not in the mood for a complex capability exchange between server and client although if we should make the creation of a changeset mandatory in 0.6 then the create changeset request would be an ideal place to add such things. 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
Re: [OSM-talk] Proposed Relations
On Wed, Nov 5, 2008 at 3:38 PM, Frederik Ramm [EMAIL PROTECTED] wrote: 2. Make sure the big three editors support ordering. Nobody will notice, nobody has to change what he does. Also, try and get Osmosis and the various mirror services (ROMA, XAPI) to support ordered relations. I can confirm that Osmosis already maintains the order of relations. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
Hi, Karl Newman wrote: 2. Make sure the big three editors support ordering. Nobody will notice, nobody has to change what he does. Also, try and get Osmosis and the various mirror services (ROMA, XAPI) to support ordered relations. I can confirm that Osmosis already maintains the order of relations. That's good but in order to allow Osmosis-based database thingies like ROMA (at least I believe it uses Osmosis?), one would probably have to amend the database input/output code to populate/use a sequence number field in the relation_members table! But don't jump ahead and do something, my idea might still be shot down and/or shown to be flawed or useless in some way, I haven't discussed it with the others working on 0.6 yet. 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
Re: [OSM-talk] Proposed Relations
On Thu, Nov 6, 2008 at 11:10 AM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, Karl Newman wrote: 2. Make sure the big three editors support ordering. Nobody will notice, nobody has to change what he does. Also, try and get Osmosis and the various mirror services (ROMA, XAPI) to support ordered relations. I can confirm that Osmosis already maintains the order of relations. That's good but in order to allow Osmosis-based database thingies like ROMA (at least I believe it uses Osmosis?), one would probably have to amend the database input/output code to populate/use a sequence number field in the relation_members table! Yep, the main change from an osmosis point of view would be supporting database schema changes. The pipeline structures stores members as a java.util.List so will preserve the order once it is loaded. Currently osmosis supports 3 schemas, the API MySQL schema, a PostGIS schema I refer to as pgsql (used as the basis of ROMA), and a custom file-based db which isn't used by anybody to the best of my knowledge which I might delete anyway to make life simpler. But don't jump ahead and do something, my idea might still be shot down and/or shown to be flawed or useless in some way, I haven't discussed it with the others working on 0.6 yet. No problem, I do lazy very well :-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
On Mon, Nov 3, 2008 at 12:31 PM, David Groom [EMAIL PROTECTED] wrote: The page http://wiki.openstreetmap.org/index.php/Relations#Proposed_uses_of_Relations has a large number of proposed uses of relations, but there never seems to be any forward movement on these. However flawed the voting system for proposed tags is, at least there is a recognised procedure, and eventually proposed tags either make it into the mainstream of OSM or they don't. It's a matter of debate as to causation/correlation between the voting procedures and mainstream OSM :-) But this doesn't seem to be the case with proposed relations. I suspect the reason for this might be twofold. Firstly there is no recognised procedure for moving these forward. Secondly, and perhaps more importantly, many of the proposed uses of relations require some degree of knowledge of what the main renderers / other users of OSM data can actually cope with. So for instance there would be no point in me trying to move a particular proposal forward as I don't know if in practice the aim of the proposal can be achieved. I'm afraid I don't have a solution to the problem, but just wanted to flag it up as an issue. I would suggest concentrating on documenting the ones that are in use, such as multipolygons, cycle route relations. Even better is to concentrate on the ones that are in the db and widely consumed (by e.g. a renderer), then on the ones in the db but not widely consumed (e.g. turn restrictions) and pretty much ignore the fanciful I-think-it-would-be-great-if suggestions. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
On Mon, Nov 3, 2008 at 2:15 PM, David Groom I'm also surprised that the relation type=boundary is still considered as a proposal in the wiki. Having a quick look on the european statistics about relations in tagwatch ([1]), the most popular relation is type=boundary (10297), most of them for admin_level=8 (municipalities). This is an example of approved relation which does not require a vote because it's already widely used. On the other side, the fifth most popular relation in tagwatch is the type=- (1107) where most of the linked objects have the role=empty ! Pieren [1] http://tagwatch.stoecker.eu/Europe/En/relationslist.html ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
On Mon, Nov 3, 2008 at 1:15 PM, David Groom [EMAIL PROTECTED] wrote: I would suggest concentrating on documenting the ones that are in use, such as multipolygons, cycle route relations. Even better is to concentrate on the ones that are in the db and widely consumed by e.g. a renderer), Is there any easy way to find what relations fit into the above category? e.g. a renderer), then on the ones in the db but not widely consumed (e.g. turn restrictions) I there any easy way to find what relations fit into the above category? It's reasonably easy to find out what ones are in use in the db, but harder to find out which are consumed. Yet still fairly straightforward detective work for someone with a good knowledge of OSM. Frederik, next time we have a discussion group like the one on relations at SOTM, remind me to video and/or transcribe it :-) Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
On Mon, November 3, 2008 14:49, Pieren wrote: On Mon, Nov 3, 2008 at 2:15 PM, David Groom I'm also surprised that the relation type=boundary is still considered as a proposal in the wiki. Having a quick look on the european statistics about relations in tagwatch ([1]), the most popular relation is type=boundary (10297), most of them for admin_level=8 (municipalities). This is an example of approved relation which does not require a vote because it's already widely used. By the way, are relations guaranteed to be ordered? If not, how could one be sure to stitch all parts of a long border? Do we need a rule like the border has to be a unbroken set of ways like for the coast lines? Regards, Hakan -- The key to immortality is first living a life worth remembering... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
On 3 Nov 2008, at 15:08, Hakan Tandogan wrote: On Mon, November 3, 2008 14:49, Pieren wrote: On Mon, Nov 3, 2008 at 2:15 PM, David Groom I'm also surprised that the relation type=boundary is still considered as a proposal in the wiki. Having a quick look on the european statistics about relations in tagwatch ([1]), the most popular relation is type=boundary (10297), most of them for admin_level=8 (municipalities). This is an example of approved relation which does not require a vote because it's already widely used. By the way, are relations guaranteed to be ordered? If not, how could one be sure to stitch all parts of a long border? Do we need a rule like the border has to be a unbroken set of ways like for the coast lines? Relations are unordered. You could load the relation and all the ways referenced by it, then check to see if each way has another way that has the same start and end nodes, through a process of stitching. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
- Original Message - From: Andy Allan [EMAIL PROTECTED] To: David Groom [EMAIL PROTECTED] Cc: Talk Openstreetmap talk@openstreetmap.org Sent: Monday, November 03, 2008 12:40 PM Subject: Re: [OSM-talk] Proposed Relations On Mon, Nov 3, 2008 at 12:31 PM, David Groom [EMAIL PROTECTED] wrote: The page http://wiki.openstreetmap.org/index.php/Relations#Proposed_uses_of_Relations has a large number of proposed uses of relations, but there never seems to be any forward movement on these. However flawed the voting system for proposed tags is, at least there is a recognised procedure, and eventually proposed tags either make it into the mainstream of OSM or they don't. It's a matter of debate as to causation/correlation between the voting procedures and mainstream OSM :-) But this doesn't seem to be the case with proposed relations. I suspect the reason for this might be twofold. Firstly there is no recognised procedure for moving these forward. Secondly, and perhaps more importantly, many of the proposed uses of relations require some degree of knowledge of what the main renderers / other users of OSM data can actually cope with. So for instance there would be no point in me trying to move a particular proposal forward as I don't know if in practice the aim of the proposal can be achieved. I'm afraid I don't have a solution to the problem, but just wanted to flag it up as an issue. I would suggest concentrating on documenting the ones that are in use, such as multipolygons, cycle route relations. Even better is to concentrate on the ones that are in the db and widely consumed by e.g. a renderer), Is there any easy way to find what relations fit into the above category? e.g. a renderer), then on the ones in the db but not widely consumed (e.g. turn restrictions) I there any easy way to find what relations fit into the above category? and pretty much ignore the fanciful I-think-it-would-be-great-if suggestions. Well I'm never a fan of fanciful I-think-it-would-be-great-if suggestions. :) But I do see, for instance, great advantages to the http://wiki.openstreetmap.org/index.php/Relations/Proposed/Collected_Ways and http://wiki.openstreetmap.org/index.php/Relations/Proposed/Dual_carriageways proposals. David Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Proposed Relations
The page http://wiki.openstreetmap.org/index.php/Relations#Proposed_uses_of_Relations has a large number of proposed uses of relations, but there never seems to be any forward movement on these. However flawed the voting system for proposed tags is, at least there is a recognised procedure, and eventually proposed tags either make it into the mainstream of OSM or they don't. But this doesn't seem to be the case with proposed relations. I suspect the reason for this might be twofold. Firstly there is no recognised procedure for moving these forward. Secondly, and perhaps more importantly, many of the proposed uses of relations require some degree of knowledge of what the main renderers / other users of OSM data can actually cope with. So for instance there would be no point in me trying to move a particular proposal forward as I don't know if in practice the aim of the proposal can be achieved. I'm afraid I don't have a solution to the problem, but just wanted to flag it up as an issue. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Relations
Hi, Shaun McDonald wrote: Relations are unordered. You could load the relation and all the ways referenced by it, then check to see if each way has another way that has the same start and end nodes, through a process of stitching. 1. Shaun is right BUT 2. I want relations to become ordered and will try to sneak this into API 0.6; there will be no noticeable change for any API client, just that it so happens that things are returned in the order you put them in, rather than in any order. The rationale behind that is that people start (ab)using the role attribute for that (e.g. a bus route with nodes that have the roles stop1, stop2, stop3 etc.), which of course is a pain to modify. 3. No matter wheter API 0.6 will have ordered relations or not, I suggest to never rely on ordering in cases where it can be derived from the contents, i.e. if you have a border relation then by all means look at the first/last nodes of the ways and connect them rather than just assuming the elements are in the correct order. 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
Re: [OSM-talk] Proposed Relations
Hi, Pieren wrote: I'm also surprised that the relation type=boundary is still considered as a proposal in the wiki. [...] This is an example of approved relation which does not require a vote because it's already widely used. There are no approved relations; there are those that are proposed and those that are established. A relation becomes established once it er, establishes itself ;-) The formal process to move a relation from proposed to established is to use your favourite editor and create lots of instances of the relation where it makes sense, ideally in a way that annoys as few others as possible. I believe the boundary relation should be clearly flagged as established. I wanted to move it up on the Relations page but I find that the Proposed section is much better structured, plus we have a naming convention problem (Relation:restriction vs. Relations/Proposed/Boundaries). Should we rename Relations/Proposed/Boundaries to Relation:bondary? 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
Re: [OSM-talk] Proposed Relations
On Mon, Nov 3, 2008 at 4:34 PM, Frederik Ramm [EMAIL PROTECTED] wrote: Hi, Shaun McDonald wrote: Relations are unordered. You could load the relation and all the ways referenced by it, then check to see if each way has another way that has the same start and end nodes, through a process of stitching. 1. Shaun is right BUT 2. I want relations to become ordered and will try to sneak this into API 0.6; there will be no noticeable change for any API client, just that it so happens that things are returned in the order you put them in, rather than in any order. The rationale behind that is that people start (ab)using the role attribute for that (e.g. a bus route with nodes that have the roles stop1, stop2, stop3 etc.), which of course is a pain to modify. If you're sneaking relation changes into the API, could you also allow a member to be repeated? This would be useful in describing a prohibited U-turn on a single carriageway. The same way would need to be in both the from and to roles, which I believe is currently prohibited. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
