Re: [OSM-talk] Id stability
Hi, Am Tue, 02 Aug 2011 11:31:03 +0200 schrieb Frederik Ramm frede...@remote.org: The great thing about such a server would be that the server could indeed *always* know which links are still working and which are broken, and broken links could even be automatically highlighted on something like OpenStreetBugs so anyone who is interested could hunt them down and fix them. How can fix such a broken link today? I think you should create a link tag from the broken ID to the manually determined replacement. But there is no tag scheme at the moment for this I am aware of. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Am Tue, 2 Aug 2011 09:21:49 -0700 (PDT) schrieb Ian ian.d...@gmail.com: On Tuesday, August 2, 2011 10:14:13 AM UTC-5, Gregor Horvath wrote: Now if this node (point on a map) is replaced with another one by a fellow mapper (for whatever reason), I think it would be a progress if ID 1381574156 points to the new node instead of vanishing. Who or what decides that the ID 1381574156 should move rather than disappear? Those that want ID stability should maintain those links. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Hi, Steve Bennett wrote: If your definition of work is guaranteed to work under all circumstances no matter what, then sure. But if it's continue to function subject to a slow rate of linkrot [...] It is even conceivable that, for whatever reason, IDs are changed on a grand scale - for example I expect API 0.7 to introduce some kind of area data type which will likely lead to lots of existing areas being changed in some way and that might include a new ID. Let's avoid that if possible. See, that's exactly my point. Once we allow people to use our internal IDs to link to (and more or less promise them only a slow rate of linkrot), then we drastically reduce our say over our own data. Suddenly certain operations that might totally make sense otherwise fall in the category of aw, but let's not do that, all those people who have hard-coded relation IDs in their applications will fall over. I could even see the discussion of how to model areas in the post-API-0.6 world be influenced by people who say aw, but's let's avoid that if possible, and us choosing the second-best alternative just to placate people who use our internal IDs to link to. OSM IDs are our internal thing and we must keep the freedom to do with them whatever we think makes sense to us, at any time in the future. Vapourware solutions are nice, but when people have a problem today, they need a solution that exists today. Well then let them think of a solution. Using our internal IDs to link to is a vapourvare solution just the same. Anyone who uses them must be aware that they might change at any time, even wholesale. But excuse me now, I'm writing a node renumber script that will keep us in the 32-bit range for half a year longer by re-using the gaps created by deleted nodes ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Andrzej, andrzej zaborowski wrote: Or create an OSM relation containing just the thing you want to link to and reference the relation's Id the editors already support warning when somethign bad happens to a relation member. Under no circumstances should we burden the mapper with keeping up external IDs that someone needs for their application. A relation being edited is not something bad happening, it is something good. We don't want to discourage edits, or make them more complex, just so that someone's linked data store continues to function - that must be *their* job, not the mapper's. Relations are unlikely to be reused for a compeltely new purpose and they can be undeleted and modified to match changes in reality. Just because you cannot think of anything right now doesn't mean that (a) there isn't anything and (b) there won't be anything in the future. If you promise relation ID stability to anyone now, you reduce what *we* can do with *our* data in the future. (One example off the top of my head: Relations for long-distance routes are often created in several places at the same time, then they grow until they meet, and are merged, with one of them being deleted.) Of course you would add a UUID tag only to objects that are actualy referenced. And then you would need some way to enforce uniqueness. Because of the above I'm not sure if you want to enforce uniqueness, you might even want 1 UUIDs per osm entity. I'm not a big fan of UUIDs because, again, it burdens *our* data with stuff that other people want to do with it. We had a lot of discussion about this. Andrzej ist right - if five-star restaurant Chez John is in a listed building, then someone compiling a directory of listed buildings would have to use another UUID than someone compiling a list of good restaurants, because the restaurant could move elsewhere and it would then have to take its UUID with it. Consequently, people have started to use UUID:building and UUID:amenity keys but I really have a very bad feeling about this. Coming back to what Maarten has said above, I would definitely be against adding UUIDs to every single house and garden shed just in case - like the 75.000 uuid:building tags we have. If we were to do UUIDs we would have to have a way of finding out whether something is actually linked, and if it isn't, then don't bother having an UUID. Which brings me back to something I mentioned earlier - I would like to have some kind of link server where you can go and say I want a permanent link to this OSM object, then the server says ok, I have investigated the object you mentioned and I'd say I make the permanent link point to 'a restaurant named Chez John within 500 metres of this location', is that ok, and you go yes, and the server then says your permanent link ID is 1234567890, thank you. At any later time you can query the server for that permanent link ID and you get back either the OSM object, or the current OSM object ID, or nothing if the link is broken. The great thing about such a server would be that the server could indeed *always* know which links are still working and which are broken, and broken links could even be automatically highlighted on something like OpenStreetBugs so anyone who is interested could hunt them down and fix them. The server could also track which links are actually used, and expire them if they aren't used for a year or so. This would make one great project for a student thesis (Claus, are you still reading...?). I don't know if this is compatible with the linked data store idea, maybe explicitly having to register a link is a problem there, but if that's the case then I'd say linked data store is just not for us. And to Steve Bennett (people need a solution now, not vapourware) - sometimes settling for a half-baked solution too early has the risk of entrenching half-bakedness and never getting around to implement a good solution. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
The great thing about such a server would be that the server could indeed *always* know which links are still working and which are broken, and broken links could even be automatically highlighted on something like OpenStreetBugs so anyone who is interested could hunt them down and fix them. The server could also track which links are actually used, and expire them if they aren't used for a year or so. +1 A perfect solution that works over longer periods of time and for any type of data...! ID's in a database are not meant to be linked to and making it harder to edit stuff is not a good option either... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
I'm not sure I understand why having the ability to link to external data through some sort of ID is such a bad thing. This is common in many APIs and datasets. It is an opportunity to mix data in new ways as well. Frederik also this seems odd to me I'm not a big fan of UUIDs because, again, it burdens *our* data with stuff that other people want to do with it. Define other people, do you mean mappers, data users? Why aquiesce to use tags at all, making data more consistent just burdens *our* data with stuff other people want to do with it. I think being able to link between datasets can be beneficial. Maybe versioning on the API makes sense, maybe UUIDs, but I don't think the linking is such a bad thing. -Kate On Tue, Aug 2, 2011 at 5:31 PM, Frederik Ramm frede...@remote.org wrote: Andrzej, andrzej zaborowski wrote: Or create an OSM relation containing just the thing you want to link to and reference the relation's Id the editors already support warning when somethign bad happens to a relation member. Under no circumstances should we burden the mapper with keeping up external IDs that someone needs for their application. A relation being edited is not something bad happening, it is something good. We don't want to discourage edits, or make them more complex, just so that someone's linked data store continues to function - that must be *their* job, not the mapper's. Relations are unlikely to be reused for a compeltely new purpose and they can be undeleted and modified to match changes in reality. Just because you cannot think of anything right now doesn't mean that (a) there isn't anything and (b) there won't be anything in the future. If you promise relation ID stability to anyone now, you reduce what *we* can do with *our* data in the future. (One example off the top of my head: Relations for long-distance routes are often created in several places at the same time, then they grow until they meet, and are merged, with one of them being deleted.) Of course you would add a UUID tag only to objects that are actualy referenced. And then you would need some way to enforce uniqueness. Because of the above I'm not sure if you want to enforce uniqueness, you might even want 1 UUIDs per osm entity. I'm not a big fan of UUIDs because, again, it burdens *our* data with stuff that other people want to do with it. We had a lot of discussion about this. Andrzej ist right - if five-star restaurant Chez John is in a listed building, then someone compiling a directory of listed buildings would have to use another UUID than someone compiling a list of good restaurants, because the restaurant could move elsewhere and it would then have to take its UUID with it. Consequently, people have started to use UUID:building and UUID:amenity keys but I really have a very bad feeling about this. Coming back to what Maarten has said above, I would definitely be against adding UUIDs to every single house and garden shed just in case - like the 75.000 uuid:building tags we have. If we were to do UUIDs we would have to have a way of finding out whether something is actually linked, and if it isn't, then don't bother having an UUID. Which brings me back to something I mentioned earlier - I would like to have some kind of link server where you can go and say I want a permanent link to this OSM object, then the server says ok, I have investigated the object you mentioned and I'd say I make the permanent link point to 'a restaurant named Chez John within 500 metres of this location', is that ok, and you go yes, and the server then says your permanent link ID is 1234567890, thank you. At any later time you can query the server for that permanent link ID and you get back either the OSM object, or the current OSM object ID, or nothing if the link is broken. The great thing about such a server would be that the server could indeed *always* know which links are still working and which are broken, and broken links could even be automatically highlighted on something like OpenStreetBugs so anyone who is interested could hunt them down and fix them. The server could also track which links are actually used, and expire them if they aren't used for a year or so. This would make one great project for a student thesis (Claus, are you still reading...?). I don't know if this is compatible with the linked data store idea, maybe explicitly having to register a link is a problem there, but if that's the case then I'd say linked data store is just not for us. And to Steve Bennett (people need a solution now, not vapourware) - sometimes settling for a half-baked solution too early has the risk of entrenching half-bakedness and never getting around to implement a good solution. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org
Re: [OSM-talk] Id stability
Hi, Kate Chapman wrote: I'm not sure I understand why having the ability to link to external data through some sort of ID is such a bad thing. This is about external data linking to us, not vice versa. This is common in many APIs and datasets. It is an opportunity to mix data in new ways as well. That's why it ought to be done right, in a way that places no additional burden on our project. (And if you need proof that it isn't easy - even Navteq and TeleAtlas do not promise stability of their IDs, and indeed they change often.) Frederik also this seems odd to me I'm not a big fan of UUIDs because, again, it burdens *our* data with stuff that other people want to do with it. Define other people, do you mean mappers, data users? I mean the work of mappers becoming more complicated because people who are not mappers want their demands met. For every mapper there are hundreds who want to use our data (and whereas the mapper never receives any money, many of our data users actually make money or save money by using our data). This means, to me, that if data users want to have it easier, want stable linking to OSM or whatever, they ought to shoulder the burden themselves rather than asking us to shoulder it for them IN ADDITION to what we are already doing. And, as I have explained, it would be a simple matter of programming (plus a little funds to run the service) to do this properly. Why aquiesce to use tags at all, making data more consistent just burdens *our* data with stuff other people want to do with it. Like it or not, most of our mappers are in it for the map. That's why they use tags. If most of our mappers were in it for the general idea of a semantic web and a linked data store that encompasses the planet, things might look different. I think being able to link between datasets can be beneficial. Maybe versioning on the API makes sense, maybe UUIDs, but I don't think the linking is such a bad thing. My main point was that any additional burden caused for us by linking - be that a reuirement for constant IDs, the introduction of additional tags, or warnings that pop up when someone tries to make an otherwise normal edit - is hard to accept for me, and I'd prefer a third-party service that does all this without affecting us negatively. It's technically possible so if someone is really eager to have proper linking then why not just do it. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Frederik Ramm wrote: Which brings me back to something I mentioned earlier - I would like to have some kind of link server where you can go and say I want a permanent link to this OSM object, then the server says ok, I have investigated the object you mentioned and I'd say I make the permanent link point to 'a restaurant named Chez John within 500 metres of this location', is that ok, and you go yes, and the server then says your permanent link ID is 1234567890, thank you. At any later time you can query the server for that permanent link ID and you get back either the OSM object, or the current OSM object ID, or nothing if the link is broken. Yes. Absolutely spot on. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Blatant-case-of-tagging-for-the-renderer-tp6633546p6644269.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Tue, Aug 2, 2011 at 7:31 PM, Frederik Ramm frede...@remote.org wrote: And to Steve Bennett (people need a solution now, not vapourware) - sometimes settling for a half-baked solution too early has the risk of entrenching half-bakedness and never getting around to implement a good solution. Right. With an ever evolving project like OSM we need to find creative ways to support existing usage, but not lock ourselves into a bad long term solution. One way to do this, using your link server idea would be to support a legacy ID query mode, eg /legacyid/xyz which points to whatever object had xyz on a given cutover date. At some future date, we renumber all the IDs, breaking everything, but all the services that point to those IDs could just point to the legacyid/ service instead. It's a break, but it's a trival one to fix. Meanwhile new services would be built around the persistent id service, requesting permanent handles as required. (You do have the problem defining what it is that you want to persistently link to: the way? the relation? the relation with the members that it had when you linked to it?) Just brainstorming... Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Kate Chapman wrote: Why aquiesce to use tags at all, making data more consistent just burdens *our* data with stuff other people want to do with it. It is impossible to create a map that displays buildings if no one adds buildings to the database. Adding buildings requires effort, but it is _necessary_ effort for something that many mappers want our data to be used for. Linking to OSM, however, is entirely possible without placing an additional burden on mappers: Implement a service that resolves queries for OSM objects. Therefore, manually maintaining IDs in the database is an unnecessary waste of mappers' time. Besides the effort required for manual ID maintenance, I think that manual IDs would even turn out to be semantically questionable. They cannot easily represent which aspects of the object are referenced by the ID. If a restaurant moves, should it keep the same ID? If it is renamed? If it goes bankrupt, is sold, renovated, and reopened by a different owner? Setting up a query would ideally encode your intentions - do you e.g. query for restaurant at address or restaurant with name/owner in town? A mapper maintaining a restaurant ID has no chance to know the intentions of people linking to the restaurant, and it is easily possible that different people even use that same ID with incompatible intentions. -- Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On 02/08/2011 11:08, Frederik Ramm wrote: Well then let them think of a solution. Using our internal IDs to link to is a vapourvare solution just the same. Anyone who uses them must be aware that they might change at any time, even wholesale. Exactly. OSM does not cause buildings to be created or roads to be built or restaurants to be opened. Very many real-world objects already have a stable unique identifier. Every time a building is constructed, a new ID is created in the list of all buildings maintained by some governmental organisation. Every time a railway station is built it gets an ID in the list maintained by the railway operator. Every time a company is created it gets a company number in some administration or other. Just add these external IDs to the OSM data, together with an indication of the relevant authority. Example: Victoria Station in London is known by the unique identifier VIC in the list of stations maintained by Network Rail. So it might have tags ref=VIC and source:ref=Network Rail. There's your stable ID: whenever you want to find it, query on these tags. Of course performance would likely be a major issue here, but that is probably not insurmountable and anyway should not be used as an excuse for not doing the Right Thing. Colin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Hi, Am Mon, 01 Aug 2011 09:21:44 +0200 schrieb Frederik Ramm frede...@remote.org: That was me. There are a number of other reasons why IDs could break. One is the expansion of POI nodes into buildings that Toby mentioned. Another is the splitting of ways (old ID would then point to only half) or merging (old ID would become invalid in 50% of cases). Same with the re-structuring of relations or the re-mapping of stuff in the course of the license change. It is a logically inaccurate to delete an ID in such cases. What you actually logically do is replacing an ID, or creating an alias. The problem is there is no semantic in OSM data to express such a move operation. Deleting is the wrong one. Deleting means a destroyed house or physically removed street and in this case it is logically correct that the ID is gone. So my proposal is to describe move operations in OSM data. For example: Instead of deleting, all tags of the object or removed and a alias_for joined_with splitted_to tag(s) which points to the new correct node(s) ID is inserted to the old node . Than external programs can find the proper one with the old id and the OSM data gets richer and more accurate. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Hi, On 08/02/11 15:21, Gregor Horvath wrote: It is a logically inaccurate to delete an ID in such cases. What you actually logically do is replacing an ID, or creating an alias. The problem is there is no semantic in OSM data to express such a move operation. Deleting is the wrong one. Deleting means a destroyed house or physically removed street and in this case it is logically correct that the ID is gone. No. You are entirely mistaken in applying that kind of semantic to OSM. When a mapper maps a street, or a building, or anything, the ID is just a throwaway by-product of that process which allows us to refer to the object internally. The mapper does not willingly say: I hereby assign the following ID to you, house, to remain with you until you are destroyed! Therefore, IDs in OSM can be torn down, changed, even renumbered at will without there being *any* semantic reflecting on the actual physical object. What we have in OSM are models of physical objects, and these models may change, merge, vanish, be duplicated, modified, extended, or reduced without anyone saying oh, this must mean that the physical house now has got an extra feature!. Deleting an object in OSM only becomes logically inaccurate if one makes the semantic connection that you are making (deleted object - demolished house), but in fact it is that connection that is logically baseless. (For example, we would also delete an object if we find out that it was wrongly imported or taken from an unsuitable source, just to mention the most obvious examples.) So my proposal is to describe move operations in OSM data. For example: Instead of deleting, all tags of the object or removed and a alias_for joined_with splitted_to tag(s) which points to the new correct node(s) ID is inserted to the old node . This is an interesting idea that would often make it easier to find out what someone has done in an editing session - has he shortened one way and created another new way, or has he simply split one? But it should not be confused with ID persistence. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Gregor Horvath gre...@ediwo.com wrote: Hi, Am Mon, 01 Aug 2011 09:21:44 +0200 schrieb Frederik Ramm frede...@remote.org: That was me. There are a number of other reasons why IDs could break. One is the expansion of POI nodes into buildings that Toby mentioned. Another is the splitting of ways (old ID would then point to only half) or merging (old ID would become invalid in 50% of cases). Same with the re-structuring of relations or the re-mapping of stuff in the course of the license change. It is a logically inaccurate to delete an ID in such cases. What you actually logically do is replacing an ID, or creating an alias. The problem is there is no semantic in OSM data to express such a move operation. Deleting is the wrong one. Deleting means a destroyed house or physically removed street and in this case it is logically correct that the ID is gone. So my proposal is to describe move operations in OSM data. For example: Instead of deleting, all tags of the object or removed and a alias_for joined_with splitted_to tag(s) which points to the new correct node(s) ID is inserted to the old node . Than external programs can find the proper one with the old id and the OSM data gets richer and more accurate. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Preferably split_to, rather than splitted_to, since there is no such English word as splitted. Otherwise, this sounds like a good idea. Note that there might need to be multiple instances of such a tag, with some form of version information as part of the value. For example, a POI node might later be joined to be part of an area representing a shop; this shop area might later be joined to others to represent an entire building that contains several shops. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Am Tue, 02 Aug 2011 15:43:54 +0200 schrieb Frederik Ramm frede...@remote.org: Hi, On 08/02/11 15:21, Gregor Horvath wrote: It is a logically inaccurate to delete an ID in such cases. What you actually logically do is replacing an ID, or creating an alias. The problem is there is no semantic in OSM data to express such a move operation. Deleting is the wrong one. Deleting means a destroyed house or physically removed street and in this case it is logically correct that the ID is gone. No. You are entirely mistaken in applying that kind of semantic to OSM. When a mapper maps a street, or a building, or anything, the ID is just a throwaway by-product of that process which allows us to refer to the object internally. The mapper does not willingly say: I hereby assign the following ID to you, house, to remain with you until you are destroyed! OSM provides uri's to ID's which are linked to names of physical objects. Example: http://www.openstreetmap.org/browse/node/1381574156 IN HTTP world URI's should be stable and a request for a moved object should return an HTTP Status code of 301 ( Moved Permanently) instead of 404 (Not Found). The same logic should apply to OSM ID's/URI's Deleting an object in OSM only becomes logically inaccurate if one makes the semantic connection that you are making (deleted object - demolished house), but in fact it is that connection that is logically baseless. (For example, we would also delete an object if we find out that it was wrongly imported or taken from an unsuitable source, just to mention the most obvious examples.) These are also valid cases for a not found 404. I am not against deleting at all. There are perfectly valid cases for that. I propose to add the possibility to model a move. (Not a must, like any other tagging in OSM) This is an interesting idea that would often make it easier to find out what someone has done in an editing session - has he shortened one way and created another new way, or has he simply split one? But it should not be confused with ID persistence. Yes, I am not for total ID persistence, because as I said there _are_ valid cases for deleting an ID. But a move, join or rename is not a delete operation. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Tue, Aug 2, 2011 at 6:01 PM, Frederik Ramm frede...@remote.org wrote: Hi, Kate Chapman wrote: I'm not sure I understand why having the ability to link to external data through some sort of ID is such a bad thing. This is about external data linking to us, not vice versa. This is common in many APIs and datasets. It is an opportunity to mix data in new ways as well. That's why it ought to be done right, in a way that places no additional burden on our project. (And if you need proof that it isn't easy - even Navteq and TeleAtlas do not promise stability of their IDs, and indeed they change often.) They don't promise you that they won't change, but I've worked on applications that used their IDs as a helper between updates. I'm not saying we have to make sure all the IDs stay the same. I just think we shouldn't for example swap all of them. If it isn't any extra work at the moment to have 90% stability I don't think that is a bad thing. If all the IDs have to be redone at some point I would hope a look-up would be made at some point. (I realize that someone could do this without putting an additional burden on the community). For every mapper there are hundreds who want to use our data (and whereas the mapper never receives any money, many of our data users actually make money or save money by using our data). This means, to me, that if data users want to have it easier, want stable linking to OSM or whatever, they ought to shoulder the burden themselves rather than asking us to shoulder it for them IN ADDITION to what we are already doing. And, as I have explained, it would be a simple matter of programming (plus a little funds to run the service) to do this properly. Why aquiesce to use tags at all, making data more consistent just burdens *our* data with stuff other people want to do with it. Like it or not, most of our mappers are in it for the map. That's why they use tags. If most of our mappers were in it for the general idea of a semantic web and a linked data store that encompasses the planet, things might look different. I think being able to link between datasets can be beneficial. Maybe versioning on the API makes sense, maybe UUIDs, but I don't think the linking is such a bad thing. My main point was that any additional burden caused for us by linking - be that a reuirement for constant IDs, the introduction of additional tags, or warnings that pop up when someone tries to make an otherwise normal edit - is hard to accept for me, and I'd prefer a third-party service that does all this without affecting us negatively. It's technically possible so if someone is really eager to have proper linking then why not just do it. I'm not advocating for this either. Many of the tools are difficult enough for people to get started on. Though this is certainly getting better. -Kate ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Hi, On 08/02/11 16:06, Gregor Horvath wrote: OSM provides uri's to ID's which are linked to names of physical objects. Example: http://www.openstreetmap.org/browse/node/1381574156 IN HTTP world URI's should be stable Well maybe then we should stop providing URIs if this gives people the wrong impression ;) and a request for a moved object should return an HTTP Status code of 301 ( Moved Permanently) instead of 404 (Not Found). I think you are again making the mistake of mixing various layers of meaning. If someone deletes an object in OSM to trace it anew, from better imagery for example, then he is creating a new model, and the old model ceases to exist. It is perfectly ok for a link to the old model to return 404. (On the other hand, it may be possible for someone to move a model of a house in OSM by 200 metres and the HTTP return code would still not be 301 ;) The same logic should apply to OSM ID's/URI's As I said, if there is a mistake here then it is probably in your expectation, not in what OSM is doing; and it may be our fault to have given you that expectation by using a REST interface. We should take care to make clear on the Wiki that OSM is a database of models of things - models that may vanish at any time - and not a database of things. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Gregor Horvath wrote: OSM provides uri's to ID's which are linked to names of physical objects. Example: http://www.openstreetmap.org/browse/node/1381574156 No. It doesn't. OSM does not provide URIs to anyone. OSM has an _editing_ API. It's here to facilitate edits to the end product, which is a collaborative map. The IDs are an internal convenience for editing - internal, that is to the OSM editing experience. They are not an outward-facing product that is provided to all-comers. The editing API is provided in order to edit the map data, not for read-only purposes or projects. (http://wiki.openstreetmap.org/wiki/API) cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Blatant-case-of-tagging-for-the-renderer-tp6633546p6645068.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
2011/8/2 Gregor Horvath gre...@ediwo.com: OSM provides uri's to ID's which are linked to names of physical objects. Example: http://www.openstreetmap.org/browse/node/1381574156 But these objects often make no sense in the real world! In the real world, there are things like streets, pubs, counties and hospitals, which have geometry (and other properties). In the OSM database, in contrast, there are pieces of geometry, subdivided according to topology into points (nodes), linestrings (ways), and everything else (relations), which have thingyness. The relation between OSM objects and real-world objects is quite hairy and probably depends on what sort of real-world object you are intrested in at the moment (is a hospital a place to get yourself stitched back together after falling of the bike while mapping, or a contender for largest building in a 5km radius from home?). I am beginning to suspect that the only sensible use for the OSM database, is as input data to a processing step that converts it to something more usable for a specific task. Using it as is is a recipe for headaches. I'm not saying this is a bad thing. The database is extremely flexible and can accommodate almost any sort of geographic information one cares to throw at it, it just takes some programming to use it! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Hi, Am Tue, 02 Aug 2011 16:32:29 +0200 schrieb Frederik Ramm frede...@remote.org: I think you are again making the mistake of mixing various layers of meaning. If someone deletes an object in OSM to trace it anew, from better imagery for example, then he is creating a new model, and the old model ceases to exist. It is perfectly ok for a link to the old model to return 404. If someone is doing a web page describing a car (ie a model of a physical car) and he decides to make the description of that car (ie the web page) prettier then what I expect as a user of this web page is that the old URI's are still valid. (HTTP 301 or 200) If he does a complete redesign of his website, then I expect links to be broken. (404) It depends on the case. The problem with OSM is, that a move of an object abstraction (ie the ID) like HTTP 301 is not possible yet. (On the other hand, it may be possible for someone to move a model of a house in OSM by 200 metres and the HTTP return code would still not be 301 ;) The same logic should apply to OSM ID's/URI's As I said, if there is a mistake here then it is probably in your expectation, not in what OSM is doing; and it may be our fault to have given you that expectation by using a REST interface. We should take care to make clear on the Wiki that OSM is a database of models of things - models that may vanish at any time - and not a database of things. All I expect is logic. It is irrelevant if an OSM ID describes an object or a model of an object. Because models can also be moved, therefore there should be a possibility to move the model ID. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Am Tue, 2 Aug 2011 16:55:20 +0200 schrieb Ture Pålsson t...@lysator.liu.se: 2011/8/2 Gregor Horvath gre...@ediwo.com: OSM provides uri's to ID's which are linked to names of physical objects. Example: http://www.openstreetmap.org/browse/node/1381574156 But these objects often make no sense in the real world! Correct. Because all the URI above says is that there is a node with an ID 1381574156. It does not say anything about a physical object at all. And that is a good thing, because actually the node is only a point on a map. Now if this node (point on a map) is replaced with another one by a fellow mapper (for whatever reason), I think it would be a progress if ID 1381574156 points to the new node instead of vanishing. This has absolutely nothing to do with physical objects or OSM to be a database of things. -- Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
For what it's worth Flickr often had a similar conversation with the Y!Geo / WOE kids, especially in the early days when we were just getting to know one another. The short version is that we were simply not going to use their IDs if they couldn't guarantee that they has some measure of permanence and reliability. We were not in a position (time or technology-wise) to run a full geo-stack so we needed to use those IDs as bridges back to the details. Once we all agreed on that the next question became what constituted a significant change in the meaning of an ID. For example, some WOE IDs would be updated to fix a typo in the name but others would change place type (a neighbourhood might become an historical town) which was ... always an issue. Our suggestion was that WOE start to include a pair of properties with each record: supersedes and superseded_by. These were simply meant to be pointers to and from other WOE ID and was predicated on the assumption that numbers (especially 64-bit ints) are cheap. We were fine with needing to do the work to pay attention to the fact that something had been updated and follow the breadcrumbs accordingly. Sadly, it never happened. The corollary to this idea are start/end dates which Frankie Roberto touched on at SOTM 2009. [1] Also a good thing but since this is a thread about UIDs I'll just set that aside for now :-) I'm not going to pretend to understand the guts of the OSM code well enough to suggest that supersedes/superseded_by would be easy to implement or not but it's always seemed like a useful approach to me. Cheers, -- [1] http://www.vimeo.com/5843154 On 8/2/11 7:55 AM, Ture Pålsson wrote: 2011/8/2 Gregor Horvathgre...@ediwo.com: OSM provides uri's to ID's which are linked to names of physical objects. Example: http://www.openstreetmap.org/browse/node/1381574156 But these objects often make no sense in the real world! In the real world, there are things like streets, pubs, counties and hospitals, which have geometry (and other properties). In the OSM database, in contrast, there are pieces of geometry, subdivided according to topology into points (nodes), linestrings (ways), and everything else (relations), which have thingyness. The relation between OSM objects and real-world objects is quite hairy and probably depends on what sort of real-world object you are intrested in at the moment (is a hospital a place to get yourself stitched back together after falling of the bike while mapping, or a contender for largest building in a 5km radius from home?). I am beginning to suspect that the only sensible use for the OSM database, is as input data to a processing step that converts it to something more usable for a specific task. Using it as is is a recipe for headaches. I'm not saying this is a bad thing. The database is extremely flexible and can accommodate almost any sort of geographic information one cares to throw at it, it just takes some programming to use it! ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Tuesday, August 2, 2011 10:14:13 AM UTC-5, Gregor Horvath wrote: Now if this node (point on a map) is replaced with another one by a fellow mapper (for whatever reason), I think it would be a progress if ID 1381574156 points to the new node instead of vanishing. Who or what decides that the ID 1381574156 should move rather than disappear? If it is to be a computer algorithm, who writes it? What happens when a node tagged as a pub turns into a way tagged as the same pub? Maybe it turns into a relation (because it is a multipolygon)? If it is to be a human, who will do it? I agree with Frederik: the mapper shouldn't be burdened with dragging a UUID around everywhere. Maybe the editor could ask the user You just deleted this pub. Did you mean to move it instead? The editors will then become enormously more complex than they already are. This sounds a lot like the conversation we're already having elsewhere in this thread. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
straup str...@gmail.com wrote: I'm not going to pretend to understand the guts of the OSM code well enough to suggest that supersedes/superseded_by would be easy to implement or not but it's always seemed like a useful approach to me. This supersedes / is superseded by approach would work, although there would need to be provision for a database object to supersede multiple objects (a merge operation) or be superseded by several objects (a split operation). -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
2011/8/2 Ian ian.d...@gmail.com: On Tuesday, August 2, 2011 10:14:13 AM UTC-5, Gregor Horvath wrote: Now if this node (point on a map) is replaced with another one by a fellow mapper (for whatever reason), I think it would be a progress if ID 1381574156 points to the new node instead of vanishing. Who or what decides that the ID 1381574156 should move rather than disappear? If it is to be a computer algorithm, who writes it? What happens when a node tagged as a pub turns into a way tagged as the same pub? Maybe it turns into a relation (because it is a multipolygon)? With current semantics it is not possible to decide where to go with an ID if an object gets changed. Many objects have tags like building=yes, amenity=xy on them, and you can't even tell from the data whether name is referring to the building or to the amenity. How would you know whether the ID was used for the building or for the service inside the building? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Wed, Aug 3, 2011 at 12:32 AM, Frederik Ramm frede...@remote.org wrote: I think you are again making the mistake of mixing various layers of meaning. If someone deletes an object in OSM to trace it anew, from better imagery for example, then he is creating a new model, and the old model ceases to exist. It is perfectly ok for a link to the old model to return 404. Presumably you're being facetious, and know full well that what we're talking about is the use case of people using OSM links to link to a surrogate for a real world object, rather than the OSM link itself. When I linked from Wikipedia to an OSM relation describing a bike path, it's because that OSM relation is the most precise description of the bike path available on the web. As I said, if there is a mistake here then it is probably in your expectation, not in what OSM is doing; and it may be our fault to have given you that expectation by using a REST interface. We should take care to make clear on the Wiki that OSM is a database of models of things - models that may vanish at any time - and not a database of things. Is it really the case that we don't want the OSM servers to provide useful read-only services? How come? Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Hi, Steve Bennett wrote: 3) Why people intentionally destroy ids, and whether there are better ways of achieving their goals? (I seem to recall someone explaining that sometimes objects are deleted and recreated in order to discard the change history, particularly for large relations.) That was me. There are a number of other reasons why IDs could break. One is the expansion of POI nodes into buildings that Toby mentioned. Another is the splitting of ways (old ID would then point to only half) or merging (old ID would become invalid in 50% of cases). Same with the re-structuring of relations or the re-mapping of stuff in the course of the license change. Relying on numeric IDs is never going to work, and there is no way how this could be made to work in the future. IDs are OSM internal identifiers and if you use them for anything external then you're lost. It is even conceivable that, for whatever reason, IDs are changed on a grand scale - for example I expect API 0.7 to introduce some kind of area data type which will likely lead to lots of existing areas being changed in some way and that might include a new ID. The generally accepted wisdom - although not fully implemented or extensively used - is that you need to make fuzzy links like a node with amenity=pub and name=The Old Dog in this area. Tim Alder's query to map interface tried to implement that. In the long run there might be proper, external servers where you can set up a stored query like the above Old Dog and record a permanent ID for that query, and then reference that. I don't think it should/will be a core API feature though, or at least that would be phase 2 after a number of competing schemes have been tried out by third parties and the best has been found. (Two or three people have also started tagging OSM objects with UUID tags but I don't think that that's anything more than database bloat. I think that about 99.9% of UUID tags in the database come from a building import where somebody automatically assigned an UUID to every last garden shed. Not useful.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
Hi, Thank you for your response. I believe Richard F has made comments in the past that we shouldn't do this Well, I don't know about the discussion yet, maybe you could give me a hint for which subject to search for? I just want to mention, that for Wikipedia there exists an analysis about the conceptual (=meaning) stability their URLs[1]: 90% of Wikipedia URLs are stable identifiers, and a further ~5% change in meaning only slightly. (Figure 2)[1] So I am eager to know what the counter arguments were :) Anyway, the reason I ask is: if someone did this analysis (and maybe the implementation of a tool for persistent ids) for OpenStreetMap as a part of his master thesis, would he be doing duplicate work (as maybe there are already plans for creating such system)? and if so: where can I find related work? If there are no plans yet, could anyone who is aware of discussions on this topic give me some pointers? Thank you in advance and cheers, Claus [1] Hepp et. al, Harvesting Wiki Consensus - Using Wikipedia Entries as Ontology Elements, ESWC 2006 On 08/01/2011 03:39 AM, Steve Bennett wrote: 3) Why people intentionally destroy ids, and whether there are better ways of achieving their goals? (I seem to recall someone explaining that sometimes objects are deleted and recreated in order to discard the change history, particularly for large relations.) It would definitely be valuable to have the identifiers be more persistent. I've been linking to some from Wikipedia: http://en.wikipedia.org/wiki/O%27Keefe_Rail_Trail . I believe Richard F has made comments in the past that we shouldn't do this, and we should have explicit persistent identifiers instead, but there is no support for that yet. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Mon, 01 Aug 2011 09:21:44 +0200, Frederik Ramm wrote: (Two or three people have also started tagging OSM objects with UUID tags but I don't think that that's anything more than database bloat. I think that about 99.9% of UUID tags in the database come from a building import where somebody automatically assigned an UUID to every last garden shed. Not useful.) Even though, it might be the best solution. The other solution would be that everybody who wants to use the object for their purpose adds their own home-made tag to it. And that certainly would be a database bloat. Of course you would add a UUID tag only to objects that are actualy referenced. And then you would need some way to enforce uniqueness. All reaons why it is fraught with pitfalls. I've got a wiki that links certain localities to the OSM map. I use the addr: fields for that. They are unique (at least for my purpose), but this also does not guarantee 100% continuity. Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
I've got a wiki that links certain localities to the OSM map. I use the addr: fields for that. They are unique (at least for my purpose), but this also does not guarantee 100% continuity. I did a map once with links to local pubs. I found storing their latitude and longitude was good enough for my purpose. While pubs being converted from nodes to ways, or their accuracy of location being improved based on bing imagery means the pub may move slightly, the stored location was still near enough (and much better than calculating based on say OpenData postcode centroids as most web location stuff seems to do). Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Mon, 1 Aug 2011 09:29:41 +0100, Ed Loach wrote: I've got a wiki that links certain localities to the OSM map. I use the addr: fields for that. They are unique (at least for my purpose), but this also does not guarantee 100% continuity. I did a map once with links to local pubs. I found storing their latitude and longitude was good enough for my purpose. While pubs being converted from nodes to ways, or their accuracy of location being improved based on bing imagery means the pub may move slightly, the stored location was still near enough (and much better than calculating based on say OpenData postcode centroids as most web location stuff seems to do). The big advantage for my purpose is that zipcode+housenumber is unique in the Netherlands. This is not so in other countries where even street+zipcode+housenumber may not be unique. So yes, YMMV. Doing it on vicinity of previous known location is also a good thought. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
The stable ID question to me comes down to philosophy: It would be nice if the world was stable but it's not. Asking for stable IDs is like asking for the world not to change. But it does, continuously. Any road changes over time in name, surface, connectivity and it's other attributes. Perhaps you could have 90% stability over some two year or so period but that's about it. Therefore, it seems better to deal with the inherent messiness of the world than try to squeeze it in to a neat structure. Steve On 8/1/2011 12:21 AM, Frederik Ramm wrote: Hi, Steve Bennett wrote: 3) Why people intentionally destroy ids, and whether there are better ways of achieving their goals? (I seem to recall someone explaining that sometimes objects are deleted and recreated in order to discard the change history, particularly for large relations.) That was me. There are a number of other reasons why IDs could break. One is the expansion of POI nodes into buildings that Toby mentioned. Another is the splitting of ways (old ID would then point to only half) or merging (old ID would become invalid in 50% of cases). Same with the re-structuring of relations or the re-mapping of stuff in the course of the license change. Relying on numeric IDs is never going to work, and there is no way how this could be made to work in the future. IDs are OSM internal identifiers and if you use them for anything external then you're lost. It is even conceivable that, for whatever reason, IDs are changed on a grand scale - for example I expect API 0.7 to introduce some kind of area data type which will likely lead to lots of existing areas being changed in some way and that might include a new ID. The generally accepted wisdom - although not fully implemented or extensively used - is that you need to make fuzzy links like a node with amenity=pub and name=The Old Dog in this area. Tim Alder's query to map interface tried to implement that. In the long run there might be proper, external servers where you can set up a stored query like the above Old Dog and record a permanent ID for that query, and then reference that. I don't think it should/will be a core API feature though, or at least that would be phase 2 after a number of competing schemes have been tried out by third parties and the best has been found. (Two or three people have also started tagging OSM objects with UUID tags but I don't think that that's anything more than database bloat. I think that about 99.9% of UUID tags in the database come from a building import where somebody automatically assigned an UUID to every last garden shed. Not useful.) Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
For what it's worth we were aware that IDs were technically considered unstable when we started down the OSM machine tags extras road, at Flickr. It seemed like a reasonable potential gotcha given that most of the IDs are stable most of the time and the risks were outweighed by the benefits of making OSM data and Flickr photos hold hands. Personally, I would prefer permanent identifiers but back in 2009 we were just trying to explore what could be done modulo all the edge cases that exist in any project. Cheers, On 7/31/11 7:52 PM, Toby Murray wrote: On Sun, Jul 31, 2011 at 8:39 PM, Steve Bennettstevag...@gmail.com wrote: It would definitely be valuable to have the identifiers be more persistent. I've been linking to some from Wikipedia: http://en.wikipedia.org/wiki/O%27Keefe_Rail_Trail . I believe Richard F has made comments in the past that we shouldn't do this, and we should have explicit persistent identifiers instead, but there is no support for that yet. Flickr does this too, by the way: http://code.flickr.com/blog/2009/09/28/thats-maybe-a-bit-too-dorky-even-for-us/ Until we come up with a better way of persisting IDs, people WILL use node/way/relation IDs to link to OSM data. When I expand a POI to an area I generally try to use the original node as part of the new closed way to maintain some kind of link but that's not a solution and would still break . And as far as I know, no real work has been done on this. I think it would take an API change and good editor support to implement correctly. Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Mon, Aug 1, 2011 at 7:19 PM, straup str...@gmail.com wrote: For what it's worth we were aware that IDs were technically considered unstable when we started down the OSM machine tags extras road, at Flickr. Do you have an idea of how often OSM machine tags are added to items in Flickr, and how often those tags are followed, consumed or clicked? how is use changing over time? It's pretty cool. I should use those tags more often. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On 8/1/2011 7:40 PM, Richard Weait wrote: It's pretty cool. I should use those tags more often. Here's an example of FLickr tags VS new map data after +1.5 years. Granted, there are only about a dozen underlying POIs where the shop / restaurant has been replaced, but it's largely correct for casual browsing purposes. http://www.openstreetmap.pl/wp/?lat=34.85118lon=-82.39943zoom=17 (Firefox only) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
I don't, no. I do still see people adding osm:* tags to their photos though, via the RSS feeds, but realistically I don't expect its gotten much traction. Like the blog post said it's still pretty a dorky feature and that means it really needs some love and tools and examples to help people (who don't live and breathe this stuff) understand what to do with it. And then I left Flickr and they've had a thousand and one other priorities and and and. I added support for the tags in buildings=yes. For example (you'll need to scroll down to the photos section) : http://buildingequalsyes.spum.org/id/2150341379 http://buildingequalsyes.spum.org/id/2148567270 I'm hoping to have some time to work on b=y again soon and it would be nice to wire in an (Flickr) uploadr or something. Cheers, On 8/1/11 4:40 PM, Richard Weait wrote: On Mon, Aug 1, 2011 at 7:19 PM, straupstr...@gmail.com wrote: For what it's worth we were aware that IDs were technically considered unstable when we started down the OSM machine tags extras road, at Flickr. Do you have an idea of how often OSM machine tags are added to items in Flickr, and how often those tags are followed, consumed or clicked? how is use changing over time? It's pretty cool. I should use those tags more often. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Mon, Aug 1, 2011 at 5:21 PM, Frederik Ramm frede...@remote.org wrote: Relying on numeric IDs is never going to work, and there is no way how this could be made to work in the future. IDs are OSM internal identifiers and if you use them for anything external then you're lost. If your definition of work is guaranteed to work under all circumstances no matter what, then sure. But if it's continue to function subject to a slow rate of linkrot no higher than expected for the data in question, then I don't see a major issue. Most OSM data is very stable. Mapped streets don't change much. Merging is a very rare event. Splitting short ways is uncommon, and the results aren't particularly catastrophic (as you point out, the ID would refer to have the way). It is even conceivable that, for whatever reason, IDs are changed on a grand scale - for example I expect API 0.7 to introduce some kind of area data type which will likely lead to lots of existing areas being changed in some way and that might include a new ID. Let's avoid that if possible. The generally accepted wisdom - although not fully implemented or extensively used - is that you need to make fuzzy links like a node with amenity=pub and name=The Old Dog in this area. Vapourware solutions are nice, but when people have a problem today, they need a solution that exists today. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On 1 August 2011 09:52, Maarten Deen md...@xs4all.nl wrote: On Mon, 01 Aug 2011 09:21:44 +0200, Frederik Ramm wrote: (Two or three people have also started tagging OSM objects with UUID tags but I don't think that that's anything more than database bloat. I think that about 99.9% of UUID tags in the database come from a building import where somebody automatically assigned an UUID to every last garden shed. Not useful.) Even though, it might be the best solution. The other solution would be that everybody who wants to use the object for their purpose adds their own home-made tag to it. And that certainly would be a database bloat. Just throwing some ideas here, but one might consider using the OSM ID + version as the unique id. If the object is later changed in OSM, deleted and recreated, or whatever, it can be tagged with object_id=5764736:v1 to mean that it is still the same object as had been referenced by 5764736:v1 from elsewhere. Or create an OSM relation containing just the thing you want to link to and reference the relation's Id the editors already support warning when somethign bad happens to a relation member. Relations are unlikely to be reused for a compeltely new purpose and they can be undeleted and modified to match changes in reality. Using relations also allows an osm entity to be part of multiple real world objects, or multiple osm entities to form one real world object, both of which may be desired. Of course you would add a UUID tag only to objects that are actualy referenced. And then you would need some way to enforce uniqueness. Because of the above I'm not sure if you want to enforce uniqueness, you might even want 1 UUIDs per osm entity. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Id stability
Hi, Is anyone aware of 1) any analysis/research about the stability of OSM ids? 2) any tool(s) that attempts to figure out whether a) the meaning of an entity (node, way, relation) changed between two versions (e.g. using the id of pub and marking it as a cafe). b) a new id is the same thing as a deleted one. (e.g. someone deletes a batch of things, and later uploads mostly the same things again) The thing is, that I am working on the LinkedGeoData[1] project, where we attempt to bring the OpenStreetMap data into the Semantic Web infrastructure, by publishing the data as RDF. Since we are interlinking - based on the OSM IDs - with other knowledge bases out there (GeoNames[2], DBpedia[3] and FAO[4] so far), it would be good to know about what can be expected about when the links will break ;) And also what tools there are to counter that. Essentially I am asking the same question, as someone asked in a forum post[5] at the beginning of this year. The answer was, that these things do not exist yet. Has this changed in the meantime? Cheers, Claus [1] http://linkedgeodata.org [2] http://www.geonames.org/ [3] http://dbpedia.org [4] http://www.fao.org [5] http://forum.openstreetmap.org/viewtopic.php?id=10737 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
3) Why people intentionally destroy ids, and whether there are better ways of achieving their goals? (I seem to recall someone explaining that sometimes objects are deleted and recreated in order to discard the change history, particularly for large relations.) It would definitely be valuable to have the identifiers be more persistent. I've been linking to some from Wikipedia: http://en.wikipedia.org/wiki/O%27Keefe_Rail_Trail . I believe Richard F has made comments in the past that we shouldn't do this, and we should have explicit persistent identifiers instead, but there is no support for that yet. Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Id stability
On Sun, Jul 31, 2011 at 8:39 PM, Steve Bennett stevag...@gmail.com wrote: It would definitely be valuable to have the identifiers be more persistent. I've been linking to some from Wikipedia: http://en.wikipedia.org/wiki/O%27Keefe_Rail_Trail . I believe Richard F has made comments in the past that we shouldn't do this, and we should have explicit persistent identifiers instead, but there is no support for that yet. Flickr does this too, by the way: http://code.flickr.com/blog/2009/09/28/thats-maybe-a-bit-too-dorky-even-for-us/ Until we come up with a better way of persisting IDs, people WILL use node/way/relation IDs to link to OSM data. When I expand a POI to an area I generally try to use the original node as part of the new closed way to maintain some kind of link but that's not a solution and would still break . And as far as I know, no real work has been done on this. I think it would take an API change and good editor support to implement correctly. Toby ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
