Re: [OSM-talk] immutable=yes Fwd: DEC Lands
I believe back on the 10th of March Russ said in three seporate emails that he would upload the data, monitor the changes (dealing with associated conflicts) and report back here with his findings. I am fairly certain in another email shortly after he said he's now done it. Doug On Mar 18, 2009 12:20 AM, "Matt Amos" wrote: On Tue, Mar 17, 2009 at 10:46 PM, Russ Nelson wrote: > On Mar 16, 2009, at 7:09... potlatch, JOSM and merkaartor already support several external data sources (yahoo! imagery, gpx points, WMS, etc...) if your data source is useful to a significant number of people then they (or you) will add support to the editors. in my opinion your arguments for a unified interface to GIS data are not compelling. on the other hand, i don't see any disadvantage to adding DEC lands data to OSM. in the end it reduces to: do you want to import and maintain this data, including the responsibility of resolving mistakes and disputes with other community members, or would you prefer to just debate the point endlessly on this list? cheers, matt ___ talk mailing list talk@openstreetmap.org http://lis... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Tue, Mar 17, 2009 at 10:46 PM, Russ Nelson wrote: > On Mar 16, 2009, at 7:09 PM, Richard Fairhurst wrote: >> People can then access it using exactly the same language/currency/ >> interface >> that they're used to with OSM. > > This only works if Potlatch, JOSM, Merkaartor, Chris Schmidt's editor, > and however many other editors that exist all add this URL to their > editors. > > Can you see how this doesn't really work when there are twenty or > thirty editors, and twenty or thirty external data sources? potlatch, JOSM and merkaartor already support several external data sources (yahoo! imagery, gpx points, WMS, etc...) if your data source is useful to a significant number of people then they (or you) will add support to the editors. in my opinion your arguments for a unified interface to GIS data are not compelling. on the other hand, i don't see any disadvantage to adding DEC lands data to OSM. in the end it reduces to: do you want to import and maintain this data, including the responsibility of resolving mistakes and disputes with other community members, or would you prefer to just debate the point endlessly on this list? cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 7:39 PM, Lars Aronsson wrote: > Russ Nelson wrote: >> As far as I can see, there is no reputation mechanism whereby >> experienced editors stand out from the noob editors, and the >> latter are reluctant to change the former's edits. And by >> definition if I don't know about it, it doesn't exist. > > This sounds pretty much like somebody who grew up with Britannica > and learned about Wikipedia yesterday. Welcome to the Internet! http://en.wikipedia.org/wiki/Special:Contributions/RussNelson -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 7:09 PM, Richard Fairhurst wrote: > People can then access it using exactly the same language/currency/ > interface > that they're used to with OSM. This only works if Potlatch, JOSM, Merkaartor, Chris Schmidt's editor, and however many other editors that exist all add this URL to their editors. Can you see how this doesn't really work when there are twenty or thirty editors, and twenty or thirty external data sources? -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 6:21 PM, Frederik Ramm wrote: > Rather than somehow > setting up a toolchain that draws OSM data from OSM and immutable > extra > data from other sources, you'd prefer to dump everything into OSM > because it is more convenient for you. More convenient for everyone. I think your "somehow" speaks volumes. And anyway, you're arguing against an idea I've already given up on. The position data is, by OSM principles, uneditable, because you can't see legal boundaries on the ground. On the other hand, if you go out into the field, and you see that the parcel is actually a combination of pastureland and forestland, then YOU SHOULD EDIT the parcel so it's split up into pastureland and forestland. Oh, my god, I can't believe that I just said that you should edit the data. The horror! -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 16, 2009 at 5:23 PM, Russ Nelson wrote: > Okay, taking you somewhat more seriously now, the ideology that Ted is > driving is that everything in OSM should be editable by everyone, and > nobody has any better edits to make than anyone else, and everybody > gets an equal vote, and if you change something and I change it back, > well, those are just two votes and who are you to override me or me > override you, and when somebody moves a way five miles long over by > one hundred feet and screws up hundreds of roads, well, that was just > an edit, and how can an edit be wrong? > I never said that everyone's edits were equal, just that all the data should be equal in the eyes of the database. I have no problem with you importing this data, monitoring it, and reverting edits that look incorrect, the same way that I pay attention to my local area and would revert vandalism or misguided edits. But yes, I do believe that *everyone* should have that same right. Nobody gets a special privilege just because they brought a certain data import to the party. As others have said, the wikiness of OSM is the central concept here. Even if I never have reason to edit your data, I object on principle that we should have data in OSM that is not editable, as I feel it violates the spirit of OSM. I have spent countless hours mapping my area, and a lot of that data is arguably the best it's going to get. Any edits by a random user (ban potlatch etc) are more likely to make the data worse, yet I would never argue that it should be uneditable or locked down in some way. The wiki model means you have to take the bad with the good. Clearly we will need to get better tools for change monitoring and easy rollback, but people are working on these things, and it's just a software problem. -Ted ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Tue, Mar 17, 2009 at 1:30 AM, Frederik Ramm wrote: > Hi, > > Lars Aronsson wrote: >> Here's an idea: Let's make OpenStreetMap the free wiki world map. > > It's never going to work. How can you expect people to trust a map that > can be edited by anyone? It's all right, when we find enough other immutable datasets to cover the remaining parts of the world, the entire community can give up and go home. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Hi, Lars Aronsson wrote: > Here's an idea: Let's make OpenStreetMap the free wiki world map. It's never going to work. How can you expect people to trust a map that can be edited by anyone? 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] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: > Okay, taking you somewhat more seriously now, the ideology that > Ted is driving is that everything in OSM should be editable by > everyone, This part sounds like the very core of the wiki idea, and not at all extremist. > and nobody has any better edits to make than anyone else, and > everybody gets an equal vote, and if you change something and I > change it back, well, those are just two votes and who are you > to override me or me override you, and when somebody moves a way > five miles long over by one hundred feet and screws up hundreds > of roads, well, that was just an edit, and how can an edit be > wrong? I don't think anybody suggested this. > I exaggerate to make a point, obviously. It's obvious that you do, but it's not obvious what your point is. > As far as I can see, there is no reputation mechanism whereby > experienced editors stand out from the noob editors, and the > latter are reluctant to change the former's edits. And by > definition if I don't know about it, it doesn't exist. This sounds pretty much like somebody who grew up with Britannica and learned about Wikipedia yesterday. Welcome to the Internet! > In hindsight, I think that I proposed "immutable=yes" as a > primitive and binary reputation mechanism. If anybody has any > better ideas, I'd love to hear them. Here's an idea: Let's make OpenStreetMap the free wiki world map. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 16, 2009 at 11:22 PM, Frederik Ramm wrote: > Richard Fairhurst wrote: >> Hell, if you think having to call two URLs is >> too much like hard work, you can augment your data with minutely-updated OSM >> dumps, and make everything available from that one place. > > What id range would he use for nodes, ways, and relations of his > immutable dataset? whatever range he likes, if he's writing the implementation ;-) cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Hi, Richard Fairhurst wrote: > Hell, if you think having to call two URLs is > too much like hard work, you can augment your data with minutely-updated OSM > dumps, and make everything available from that one place. What id range would he use for nodes, ways, and relations of his immutable dataset? 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] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: > There's a reason why people create generalized interfaces and > standard metadata and a common currency and a shared language We do have all that, of course. It's called, for OSM-historical reasons, the Rails port. You can get yourself a server (I can probably think of people who will lend you one); install the Rails port on it; and upload this funky DEC stuff to it. People can then access it using exactly the same language/currency/interface that they're used to with OSM. Hell, if you think having to call two URLs is too much like hard work, you can augment your data with minutely-updated OSM dumps, and make everything available from that one place. Given that (AIUI) you don't think people should edit the DEC data, there won't be any syncing problems between your server and OSM. cheers Richard -- View this message in context: http://www.nabble.com/immutable%3Dyes-Fwd%3A-DEC-Lands-tp22419231p22549420.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On 16 Mar 2009, at 20:40, Russ Nelson wrote: > > On Mar 16, 2009, at 2:18 PM, Andy Allan wrote: >> No he's not, and plenty of other people are in agreement here. It's a >> question of the point of having a community in OSM (vs a large >> collection of uneditable datasets), and you're arguing about >> technical >> stuff. Technical comes second, community first. > > And when the community is wrong about stuff, I'm gonna say so. > There's a reason why people create generalized interfaces and standard > metadata and a common currency and a shared language and a > marketplace. There's a reason why traders invented the rule of law > before governments ever saw the necessity. Having a "thing" where > everybody knows that when you do that "thing", you get to play with > the big boys is what prevents centralization; what distributes power; > what destroys monopolies. > > If freedom is important to you, then you also should understand the > wisdom of voluntarily giving up some of that freedom in order to > cooperate with other people. > > Sorry if I wax too philosophic here, but I'm a combiner, not a > splitter. To my mind there is one and exactly one reason why > something should or should not be included in OSM: whether it's > copyright-compatible and whether some body wants to add it. Yes, > there could be stuff in OSM which is marked edit=fuck-no-you-moron. > Could they edit it? Yes. Should they? Only if they want to make > enemies. Cooperation is a two-way street. Russ, you are wrong. It is not just the license, but also whether the data is able to be collected and edited by the average mapper. You MUST remember the editable bit of wiki in the slogan "The Free Wiki World Map"!!! The DEC is able to use the OSM software to store their data, thus making it easier to integrate into other OSM data if require. That would be a far better option than stuffing the data into osm and marking it that you should not edit it. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Hi, Russ Nelson wrote: > Sorry if I wax too philosophic here, but I'm a combiner, not a > splitter. I think you are first and foremost lazy ;-). You want un-editable data in OSM not because it benefits OSM in some way but because you are used to working with the OSM toolchain and you would like your extra data in OSM because this makes things easier for you. Rather than somehow setting up a toolchain that draws OSM data from OSM and immutable extra data from other sources, you'd prefer to dump everything into OSM because it is more convenient for you. While such laziness often drives great inventions, I think in this case your idea is detrimental to OSM. OSM is not a protocol, a hull, a container for stuff that people pour in; nothing in OSM has the right to remain separate from the rest. What you want to have is OSM as a transport medium: Pour in you data and get it out conveniently mixed with other stuff. But OSM doesn't do that; if you pour in data, it gets assimilated into the system; people build on it, modify it, or delete it. What you really need is a Mapnik (or other) setup where you can conveniently tick various sources - roads and POIs from OSM, immutable borders from government agency X, landuse areas from government agency Y - and merge them into one map rendering setup. Just because such a comfortable solution does not yet exist should not be an excuse to dump everything into OSM in a "please don't work with this data, just transport it for me" kind of way. 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] immutable=yes Fwd: DEC Lands
> > I exaggerate to make a point, obviously. As far as I can see, there > is no reputation mechanism whereby experienced editors stand out from > the noob editors, and the latter are reluctant to change the former's > edits. And by definition if I don't know about it, it doesn't exist. > In hindsight, I think that I proposed "immutable=yes" as a primitive > and binary reputation mechanism. If anybody has any better ideas, I'd > love to hear them. > It was mentioned before, and I think that it is a possible way forward: tag some kind of quality mark with the data. This could be made up of HDOP, VDOP, PDOP, TDOP and Number of satellites. This could be automatic tags if the gpx data allowed it (some GPX specs do allow for quality) but AFAIK most gps loggers don't save this data. http://en.wikipedia.org/wiki/PDOP The vehicle tracking application that I manage simply uses the number of satellites as a rough indication of the health of the position, where <4 bad, 5/6 ok 6+ is good. People understand 'number of satellites' where DOP confuses, and ±100m makes it look really bad. A bit like the 'fuzzy' tag with translation using gettext tools, if there is high quality data it could me marked as fuzzy=nope_this_is_spot_on Or simply some kind of quality tag, which could be the max distortion of the point in meters. That way, when the whole world is mapped and we all have nothing left to do, we can filter out all the nodes where quality > 10m and go and make them better :-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 3:05 PM, Lars Aronsson wrote: > Russ Nelson wrote: > >> Sorry, Ted, but you're being driven by ideology here, not by >> good programming practise. Ideology is for ideots. > > Really? So can we copy coordinates from Google Maps now? Okay, taking you somewhat more seriously now, the ideology that Ted is driving is that everything in OSM should be editable by everyone, and nobody has any better edits to make than anyone else, and everybody gets an equal vote, and if you change something and I change it back, well, those are just two votes and who are you to override me or me override you, and when somebody moves a way five miles long over by one hundred feet and screws up hundreds of roads, well, that was just an edit, and how can an edit be wrong? I exaggerate to make a point, obviously. As far as I can see, there is no reputation mechanism whereby experienced editors stand out from the noob editors, and the latter are reluctant to change the former's edits. And by definition if I don't know about it, it doesn't exist. In hindsight, I think that I proposed "immutable=yes" as a primitive and binary reputation mechanism. If anybody has any better ideas, I'd love to hear them. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 3:05 PM, Lars Aronsson wrote: > Russ Nelson wrote: > >> Sorry, Ted, but you're being driven by ideology here, not by >> good programming practise. Ideology is for ideots. > > Really? So can we copy coordinates from Google Maps now? Only on Blartdays, and today isn't Blartday (one foolish reply deserves another.) -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: > Sorry, Ted, but you're being driven by ideology here, not by > good programming practise. Ideology is for ideots. Really? So can we copy coordinates from Google Maps now? -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 2:45 PM, Gerald A wrote: > > Why not just do a trial import, and see how it goes? See what > changes and why, rather then crushing changes with instant reversions? Maybe I haven't been obvious enough here? It's much more interesting to see what kinds of edits people would make to (positional) data which is already more correct than anybody here could make it. On the other hand, there's plenty of room for metadata edits. So, I'm not going to do any reverting, but will instead look at the edits that have been made to the data (already imported) when it comes time to update it. And I'll report back here on the nature of those edits. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 2:18 PM, Andy Allan wrote: > No he's not, and plenty of other people are in agreement here. It's a > question of the point of having a community in OSM (vs a large > collection of uneditable datasets), and you're arguing about technical > stuff. Technical comes second, community first. And when the community is wrong about stuff, I'm gonna say so. There's a reason why people create generalized interfaces and standard metadata and a common currency and a shared language and a marketplace. There's a reason why traders invented the rule of law before governments ever saw the necessity. Having a "thing" where everybody knows that when you do that "thing", you get to play with the big boys is what prevents centralization; what distributes power; what destroys monopolies. If freedom is important to you, then you also should understand the wisdom of voluntarily giving up some of that freedom in order to cooperate with other people. Sorry if I wax too philosophic here, but I'm a combiner, not a splitter. To my mind there is one and exactly one reason why something should or should not be included in OSM: whether it's copyright-compatible and whether some body wants to add it. Yes, there could be stuff in OSM which is marked edit=fuck-no-you-moron. Could they edit it? Yes. Should they? Only if they want to make enemies. Cooperation is a two-way street. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 1:35 PM, Andy Deakin wrote: > Would it be ok to edit the data without moving it? i.e. add extra tags > to the data. Well, yes, that's why the DEC Lands data has been imported without an immutable=yes tag. Because, for example, we have metadata for forest=deciduous and forest=coniferous. You could quite reasonably draw a line between two nodes (without moving them) because you noticed that part of the land parcel is distinctly more odiferous oops I mean coniferous than the rest of the parcel. This would clearly meet the surveyor's concern that people running around with GPS receivers not move his accurately-surveyed lines. It's all about the metadata, baby. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 16, 2009 at 5:24 PM, Russ Nelson wrote: > > On Mar 16, 2009, at 12:57 PM, Ted Mielczarek wrote: >> If you can't edit it it shouldn't be in the OSM db. It's easy enough >> to set up your own map render with any external data you want. > > Bzzzr, wrong. There is substantial value to renderers to only have to > work off one API for map data. If the data is in OSM, then > immediately every map renderer has access to it. If, say, someone > finds a new data source but declines to dd it to OSM, then EVERY > RENDERER needs to add support for that file format and metadata in > order to use it. Umm, no. You're wrong on this case, and I speak from running one of the main OSM renderers. Ted is correct. > Sorry, Ted, but you're being driven by ideology here, not by good > programming practise. Ideology is for ideots. No he's not, and plenty of other people are in agreement here. It's a question of the point of having a community in OSM (vs a large collection of uneditable datasets), and you're arguing about technical stuff. Technical comes second, community first. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, 2009-03-16 at 17:35 +, Andy Deakin wrote: > Would it be ok to edit the data without moving it? i.e. add extra tags > to the data. Of course it is okay to add tags. It's okay to move it too, like anything else in OSM. The source = "DEC is a source with good tools and a high opinion of their data" tag is enough to suggest that a person be pretty sure before moving it. Adding a note = "No, really, we know this data is perfect and you should never mess with our preciouss" tag should help get the message across to those convinced that they know better than the source. Of course uploading / importing with a purpose-built user for the dataset would also tip off the unwary. How about user = omniscient DEC import v1.0? Users working in the area should have enough clues from these existing tags to understand the matter and then decide based on their good judgement to edit or not. The idea that some additional tag should be or would be used to lockout editors seems silly to me. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Ted Mielczarek gmail.com> writes: > > On Sat, Mar 14, 2009 at 7:33 AM, Jukka Rahkonen wrote: > Why not to store this kind of datasets as own layers in the database? DEC > data > could be on its own, non-editable layer, but if there's something that people > would like to edit those features could be copied or lifted to anothet, OSM > layer. That would make DEC updates easier as well, they would just update the > DEC layer. The same approach would suit other data of similar nature as well, > like TIGER or cadastrial data. > > > If you can't edit it it shouldn't be in the OSM db. It's easy enough to set up your own map render with any external data you want.-Ted Hi, I meant non-editable layer, not non-editable data. In addition to user contributions OSM is already a massive collection of bulk data imports and more is to come. Big external datasets are usually also maintained by some organisations and updates are available every now and then. It should be as easy as possible to update the imported data without a need to do the whole import again. And updates are necessary, otherwise the data start soon to rotten. Workflow might be like: - Import of external data, each imported feature gets an unique ID. - If imported feature needs to be edited, it will be lifted on another layer (main OSM database perhaps) with imported ID as a key. - For rendering and data exports the edited feature, the OSM version, would be used. - When external data is updated those features which have never been lifted into OSM layer can be updated automatically. - If some feature has been lifted to OSM layer it would get a note "New version of this feature has received from the original data provider. Please check which version is correct for OSM". TIGER data is actually not a very good example because it must be noded together with native OSM data in order to make routing to work. That makes it hard to update automatically. Cadastrial data and various POI collections are more what I was thinking about. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Would it be ok to edit the data without moving it? i.e. add extra tags to the data. If so, I think that it makes sense to import it - as there would be no reason to move a node that is already correct. If no extra tags can be added and the data can not be edited in any way, then perhaps this is better in separate shape file. When setting up mapnik there are some shapefiles anyway (e.g. world boundaries) so would it make much difference if there were are few more? >> If you can't edit it it shouldn't be in the OSM db. It's easy enough >> to set up your own map render with any external data you want. >> > > Bzzzr, wrong. There is substantial value to renderers to only have to > work off one API for map data. If the data is in OSM, then > immediately every map renderer has access to it. If, say, someone > finds a new data source but declines to dd it to OSM, then EVERY > RENDERER needs to add support for that file format and metadata in > order to use it. > > Sorry, Ted, but you're being driven by ideology here, not by good > programming practise. Ideology is for ideots. > > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 16, 2009, at 12:57 PM, Ted Mielczarek wrote: > If you can't edit it it shouldn't be in the OSM db. It's easy enough > to set up your own map render with any external data you want. Bzzzr, wrong. There is substantial value to renderers to only have to work off one API for map data. If the data is in OSM, then immediately every map renderer has access to it. If, say, someone finds a new data source but declines to dd it to OSM, then EVERY RENDERER needs to add support for that file format and metadata in order to use it. Sorry, Ted, but you're being driven by ideology here, not by good programming practise. Ideology is for ideots. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
> If you can't edit it it shouldn't be in the OSM db. Agreed. OSM doesn't looks to me like a repository of any map with any conditions of the world. What's next ? some layer with copyrighted data, some with geolocalized photos ? Better make this import available somewhere else as shapefiles, or whatever format and create a combined map of both. > It's easy enough to set > up your own map render with any external data you want. Wether it's easy or hard is irrelevant to me. -- sly Sylvain Letuffe li...@letuffe.org qui suis-je : http://slyserv.dyndns.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Sat, Mar 14, 2009 at 7:33 AM, Jukka Rahkonen wrote: > Why not to store this kind of datasets as own layers in the database? DEC > data > could be on its own, non-editable layer, but if there's something that > people > would like to edit those features could be copied or lifted to anothet, OSM > layer. That would make DEC updates easier as well, they would just update > the > DEC layer. The same approach would suit other data of similar nature as > well, > like TIGER or cadastrial data. > If you can't edit it it shouldn't be in the OSM db. It's easy enough to set up your own map render with any external data you want. -Ted ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Sat, Mar 14, 2009 at 7:33 PM, Jukka Rahkonen wrote: > Why not to store this kind of datasets as own layers in the database? DEC > data > could be on its own, non-editable layer, but if there's something that > people > would like to edit those features could be copied or lifted to anothet, OSM > layer. That would make DEC updates easier as well, they would just update > the > DEC layer. The same approach would suit other data of similar nature as > well, > like TIGER or cadastrial data. > > +1 Having multiple separate "layers" in OSM would be good for various purposes. The GPS traces "layer" is already one we use. Eugene / seav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Simon Ward bleah.co.uk> writes: > > On Mon, Mar 09, 2009 at 02:25:24PM -0400, Russ Nelson wrote: > > Earlier, I proposed that certain datasets should be immutable; whether > > by policy or mechanism as needed. I propose importing the NYS DEC > > Lands as an immutable set of data. If you read this exchange with > > Robert Morrell, you can see why they feel that NO changes AT ALL are > > appropriate. I agree with them. This dataset constitutes a legal > > description of the property managed by the NYS Department of > > Environmental Conservation, and changes by any OSM editor are not > > consistent with the nature of the data. > > > > How do people feel about me importing this data (with all of their > > metadata), adding an immutable=yes tag, with the intent of tracking > > their dataset, and deleting --outright-- any changes made by OSM > > editors. > > -1 > > It’s a sign of success for OSM when people want all sorts of data to be > “in” it, but an immutable dataset just isn’t in the spirit of the > project, not to mention that it would violate any sharealike licence > placed on it (adds restrictions, like invariant sections in the GFDL). > > Simon Why not to store this kind of datasets as own layers in the database? DEC data could be on its own, non-editable layer, but if there's something that people would like to edit those features could be copied or lifted to anothet, OSM layer. That would make DEC updates easier as well, they would just update the DEC layer. The same approach would suit other data of similar nature as well, like TIGER or cadastrial data. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 09, 2009 at 02:25:24PM -0400, Russ Nelson wrote: > Earlier, I proposed that certain datasets should be immutable; whether > by policy or mechanism as needed. I propose importing the NYS DEC > Lands as an immutable set of data. If you read this exchange with > Robert Morrell, you can see why they feel that NO changes AT ALL are > appropriate. I agree with them. This dataset constitutes a legal > description of the property managed by the NYS Department of > Environmental Conservation, and changes by any OSM editor are not > consistent with the nature of the data. > > How do people feel about me importing this data (with all of their > metadata), adding an immutable=yes tag, with the intent of tracking > their dataset, and deleting --outright-- any changes made by OSM > editors. -1 It’s a sign of success for OSM when people want all sorts of data to be “in” it, but an immutable dataset just isn’t in the spirit of the project, not to mention that it would violate any sharealike licence placed on it (adds restrictions, like invariant sections in the GFDL). Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On 09/03/09 18:25, Russ Nelson wrote: > Earlier, I proposed that certain datasets should be immutable; whether > by policy or mechanism as needed. I propose importing the NYS DEC > Lands as an immutable set of data. If you read this exchange with > Robert Morrell, you can see why they feel that NO changes AT ALL are > appropriate. I agree with them. This dataset constitutes a legal > description of the property managed by the NYS Department of > Environmental Conservation, and changes by any OSM editor are not > consistent with the nature of the data. > > How do people feel about me importing this data (with all of their > metadata), adding an immutable=yes tag, with the intent of tracking > their dataset, and deleting --outright-- any changes made by OSM > editors. -1 What wouldn't be immutable? If I map a road. I might think "I know where this road is, it doesn't make sense for someone else to change this, I'll just make it immutable" OSM is a wiki. Everything is editable. Rory signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
At 06:36 PM 12/03/2009, Russ Nelson wrote: >On Mar 12, 2009, at 7:43 AM, Ted Mielczarek wrote: >> . However, I reject the idea that there is any data that belongs in >> OSM that "makes no sense to edit". If you can't edit it, then by >> definition it shouldn't be in a wiki-style map. > >No one has been able to refute my claim that if someone would enter it >by hand, it belongs in OSM regardless of its source. And if it comes >from surveyed data, then it makes no sense to edit its position. >Metadata, perhaps. But unless you've been out in the field with a >theolodite, you have no business changing the location of the NYS DEC >Lands position. Watching the discussion, I'd conclude as follows: The primary OSM database is a collection of, by definition, mutable data. That is the "wiki" principle. Whether it actually makes sense to edit parts of it is therefore not relevant. Provided that the original licensor's terms permit, anyone is free to put a *copy* of reference data into the OSM database. The original immutable reference source still stands. The copied data can be tagged with a source and a request or suggestion made that it should not be altered ... but that suggestion cannot be mandatory. So immutable=yes is confusing but by all means place immutable=recommended. I used the term "primary OSM database". At the moment, the primary OSM database is the only database that serves data according to the OSM API and XML schema (?). I foresee that will change although personally I would drag my feet on it until the primary OSM database has even more clearly established itself as The Source. Optional datasets will however emerge and maturing editors and renderers will adapt. Sets of coastlines at different resolutions and sources, scientific datasets, school projects, where I went on my holidays ... and reference datasets at higher resolution and authority than general contributions. That, I suspect, is the true long term solution to Russ' dilemma. Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Thu, Mar 12, 2009 at 9:49 PM, David Lynch wrote: > On Thu, Mar 12, 2009 at 12:36, Russ Nelson wrote: >> No one has been able to refute my claim that if someone would enter it >> by hand, it belongs in OSM regardless of its source. And if it comes >> from surveyed data, then it makes no sense to edit its position. >> Metadata, perhaps. It may make no sense now, but it may be in 10 years when the data will be changed, and the official source may or may not be available for updates > That's because we don't have a problem with data coming from > government sources that we could go out and collect ourselves. I don't > think most in the group disagree with the assertion that it's more > accurate than anything that we're likely to collect. We do have a > problem with the insistence that it can never be changed. (Even if > there's no need to change it.) exactly my position -- Elena ``of Valhalla'' homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Thu, Mar 12, 2009 at 12:36, Russ Nelson wrote: > No one has been able to refute my claim that if someone would enter it > by hand, it belongs in OSM regardless of its source. And if it comes > from surveyed data, then it makes no sense to edit its position. > Metadata, perhaps. But unless you've been out in the field with a > theolodite, you have no business changing the location of the NYS DEC > Lands position. That's because we don't have a problem with data coming from government sources that we could go out and collect ourselves. I don't think most in the group disagree with the assertion that it's more accurate than anything that we're likely to collect. We do have a problem with the insistence that it can never be changed. (Even if there's no need to change it.) It's like agreeing to let someone put their translation of a book onto a wiki but only under the condition that nobody changes it. It may be technically flawless, but if you're not going to allow edits, there are read-only ways of putting it out there. -- David J. Lynch djly...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 12, 2009, at 2:19 PM, Matt Amos wrote: > i would expect that a very small number of people, possibly zero, will > try and edit this data. Yeah, that's my conclusion as well. For some reason, people are objecting to being told not to do something they have no reason or interest in doing. Time will tell if it's a problem. It's not like somebody can be making secret edits here. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Thu, Mar 12, 2009 at 5:36 PM, Russ Nelson wrote: > On Mar 12, 2009, at 7:43 AM, Ted Mielczarek wrote: >> . However, I reject the idea that there is any data that belongs in >> OSM that "makes no sense to edit". If you can't edit it, then by >> definition it shouldn't be in a wiki-style map. > > No one has been able to refute my claim that if someone would enter it > by hand, it belongs in OSM regardless of its source. And if it comes > from surveyed data, then it makes no sense to edit its position. > Metadata, perhaps. But unless you've been out in the field with a > theolodite, you have no business changing the location of the NYS DEC > Lands position. i would argue that it does "make sense to edit" the NYS DEC data - you'll be editing it every time they give you an updated dataset. of course, its up to you how you deal with other people editing this data. i would recommend treating it like any other edit conflict - message the user, talk and hopefully you can sort it out between yourselves. (very) roughly 15% of data (nodes) in OSM have never been edited. i would expect that a very small number of people, possibly zero, will try and edit this data. cheers, matt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: >Sent: 09 March 2009 6:25 PM >To: Talk Openstreetmap >Subject: [OSM-talk] immutable=yes Fwd: DEC Lands > >Earlier, I proposed that certain datasets should be immutable; whether >by policy or mechanism as needed. I propose importing the NYS DEC >Lands as an immutable set of data. If you read this exchange with >Robert Morrell, you can see why they feel that NO changes AT ALL are >appropriate. I agree with them. This dataset constitutes a legal >description of the property managed by the NYS Department of >Environmental Conservation, and changes by any OSM editor are not >consistent with the nature of the data. > >How do people feel about me importing this data (with all of their >metadata), adding an immutable=yes tag, with the intent of tracking >their dataset, and deleting --outright-- any changes made by OSM >editors. -1 Cheers Andy > >Begin forwarded message: > >> From: Robert Morrell >> Date: March 9, 2009 2:06:13 PM EDT >> To: Russ Nelson >> Cc: Kurt Swartz , Larry Alber >> > >> Subject: Re: DEC Lands >> >> Russ, >> There is no "creativity" in mapping or displaying of Public >> owned land. This isn't art, it's legal land rights that impact >> private land owners. >> >> On what bases would someone with no formal training, no legal deed >> description, or survey map have to determine if a State boundary is >> correct or incorrect. Simply holding a GPS receiver does not give >> someone authority. >> >> Have you read the metadata on the clearinghouse? Read it. If you >> have any questions, get back to me. >> >> Robert Morrell >> Senior Land Surveyor >> Bureau of Real Property >> Division of Lands and Forests >> NYS Dept. Environmental Conservation >> 625 Broadway >> Albany NY 12233-4256 >> 518-402-9442 >> > "Russ Nelson" 3/9/2009 1:47 PM >>> >> So to the best of your ability, the DEC Lands dataset reflects a fact >> about the world, and there is zero room for creativity? (I understand >> why you might feel this way, so if you do, no explanation is needed, >> just a simple "yes" -- to save you the effort of convincing someone >> who agrees with you!!) >> -russ >> >> On Mar 9, 2009, at 10:10 AM, Robert Morrell wrote: >> >>> Russ, >>>For anyone to edit this DEC spatial data other than DEC >>> staff is absolutely inappropriate. This data layer is built using >>> trained staff using survey maps and deed. If this is your intention >>> I am asking you not to use our data. There are a whole host of >>> issues here. For one, non-survey grade GPS accuracies very widely >>> and can be hundreds of feet wrong. Secondly, sign location is in no >>> way a indicator of the correct boundary location. Third, sometime >>> the Department may transfer in or transfer out land that may not be >>> reflected in a timely manner on the clearing house data or new land >>> have been purchased. I can go on and on. >>> >>> If you would like to discuss this further you are welcome to call me. >>> >>> Rob >>> >>> Robert Morrell >>> Senior Land Surveyor >>> Bureau of Real Property >>> Division of Lands and Forests >>> NYS Dept. Environmental Conservation >>> 625 Broadway >>> Albany NY 12233-4256 >>> 518-402-9442 >>> >> "Russ Nelson" 3/9/2009 9:37 AM >>> >>> I realize that it's not appropriate to edit the data, and in fact we >>> can keep track of any changes, and either revert them if they are >>> obviously incorrect, or submit them back to you if they seem to be >>> legitimate. Why would someone make a purposeful edit? Perhaps they >>> were out in the field with a GPS, and noticed that the signage >>> disagrees with the map? Of course, it may be the signage that's >>> wrong, but either way it's an issue worthy of resolution. >>> >>> OpenStreetMap is a combination of imported data and user-generated >>> data. If you're familiar with Wikipedia, OpenStreetMap is very >>> similar in concept, only for geodata. Imported data goes into the >>> map >>> under its own userid, and all of your metadata is preserved. If >>> someone edits anything, it's recorded under their username, so we >>> know >>> who made the edit. >>> >>> The reason that I ask for permission is that data in OpenStreetMap >>> may >>> be further downloaded by users. We have an API. Anyone can make API >>> queries for, say, a bounding box, and received a download of >>> everything inside that box. That would include the DEC Lands data. >>> We try very hard not to infringe anyone's copyright. No copyright is >>> claimed in your metadata, but of course under the Berne Convention a >>> copyright exists nonetheless, and we need your permission to be able >>> to redistribute the data. >>> >>> On Mar 9, 2009, at 8:48 AM, Robert Morrell wrote: >>> Any data the Department puts on the clearing house is open to the Public to download. I see below you discuss "Anybody who makes additions or corrections to the data must share them with others." It would not be appropriate to edit this data in
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Thu, Mar 12, 2009 at 5:36 PM, Russ Nelson wrote: > > On Mar 12, 2009, at 7:43 AM, Ted Mielczarek wrote: >> . However, I reject the idea that there is any data that belongs in >> OSM that "makes no sense to edit". If you can't edit it, then by >> definition it shouldn't be in a wiki-style map. > > No one has been able to refute my claim that if someone would enter it > by hand, it belongs in OSM regardless of its source. And if it comes > from surveyed data, then it makes no sense to edit its position. > Metadata, perhaps. But unless you've been out in the field with a > theolodite, you have no business changing the location of the NYS DEC > Lands position. So my point of view is that there's no place for data in OSM that can't be collected and/or maintained by the community. Data imports of things that we can otherwise collect are useful bootstraps. But if we don't have the ability to verify/improve/dispute/resolve problems about it, whether through technical means or issues of authoritiveness, then there's not much point in it being there. So I think there's absolutely no point in this boundary data being put into OSM, since you have described how it's logically impossible for us to either maintain it or collect it or dispute it. It's not that it's technically impossible. We have trained surveyors amongst the community, and I'm sure we could rustle up a theodolite if needs be. But if we collect evidence of boundaries that disagree with the dataset, and therefore by definition it's our evidence that's incorrect, then we've lost already. OSM isn't a dumping ground for unmaintainable datasets, they can be kept elsewhere and combined at another point in the toolchain. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 12, 2009, at 7:43 AM, Ted Mielczarek wrote: > . However, I reject the idea that there is any data that belongs in > OSM that "makes no sense to edit". If you can't edit it, then by > definition it shouldn't be in a wiki-style map. No one has been able to refute my claim that if someone would enter it by hand, it belongs in OSM regardless of its source. And if it comes from surveyed data, then it makes no sense to edit its position. Metadata, perhaps. But unless you've been out in the field with a theolodite, you have no business changing the location of the NYS DEC Lands position. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Tue, Mar 10, 2009 at 1:56 PM, Russ Nelson wrote: > If it's "This is what NYS DEC says it manages", then no, it doesn't make > ANY sense > to change it. Then this data clearly doesn't belong in OSM. > If the data is "These are NYS's State Forests", then > there's plenty of reason to change them. Perhaps there's a typo, or > some piece of data which simply doesn't make sense. Data is produced > by people, and can have mistakes it. This data is fine for OSM. Someone imported the PA state forests from some government source a while back without any discussion, and they're doing just fine. Perhaps you just need to shift your perception of what you're importing? The canonical source of official government boundaries is not going to be the OSM data, and should never be. However, the presence of a state forest is useful data that belongs in OSM. This does not mean that the latter has to imply the former, even if that's the original source. We've also imported state and county borders from the TIGER data set. These may be quasi-official, but they've still been edited in multiple ways (as mentioned by others). What makes NY state forests so special? In short, I think you have every right to monitor data you've edited/imported and revert incorrect edits (within reason). However, I reject the idea that there is any data that belongs in OSM that "makes no sense to edit". If you can't edit it, then by definition it shouldn't be in a wiki-style map. -Ted ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 9, 2009, at 6:32 PM, 80n wrote: > The best guideline we have at the moment is to map what is on the > ground. Surveyed property lines beat GPS tracks pretty much every time. Now, if you're talking about metadata -- description of what's there rather than where it is -- then yes, I agree with you 100%. Changing the metadata to "highway=underwater;beaverdam=yes" is not something that DEC is likely to have correct in every place at every time. I'll do the import and we'll see what happens. It's not worse than expecting people to track USGS topo maps, or follow property lines through the woods with a GPS receiver. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 10, 2009, at 10:40 AM, Greg Troxel wrote: > > 1. > a. Have a way to have a separate database with such data. The problem with the "separate database" idea is that if someone was to enter the data by hand into OSM, everyone agrees that it belongs there ... but would be incompete and less accurate. So why would a more accurate representation NOT belong in OSM? Another way of saying that is "if it sucks, put it into OSM, but if it's really good, then it belongs in a separate database" --- which I think NO ONE here believes. I think we need to try it, and see what kind of edits people make. Too much speculation on what might happen Data! Must ... Have ... Data! -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 10, 2009, at 1:03 PM, Dirk-Lüder Kreie wrote: > > I propose a social solution instead of a technical one. > > i.e. "please don't change, because..." instead of > "you cannot change this, period". I've not proposed a technical solution. The question here is: should there be data in OSM which it doesn't make sense for anyone to change? It's a question of how you interpret the data. If it's "This is what NYS DEC says it manages", then no, it doesn't make ANY sense to change it. If the data is "These are NYS's State Forests", then there's plenty of reason to change them. Perhaps there's a typo, or some piece of data which simply doesn't make sense. Data is produced by people, and can have mistakes it. I'm tending towards doing the import, track the edits made to it, and report back here on exactly how the data gets changed. I think we need more information. I'll do the import under a special-purpose userid, so we can withdraw the import if necessary. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Iván Sánchez Ortega schrieb: > El Lunes, 9 de Marzo de 2009, Russ Nelson escribió: >> Earlier, I proposed that certain datasets should be immutable; whether >> by policy or mechanism as needed.[...] >> >> How do people feel about me importing this data (with all of their >> metadata), adding an immutable=yes tag, with the intent of tracking >> their dataset, and deleting --outright-- any changes made by OSM >> editors. > > I agree that an "immutable" tag is a good idea, and I'd certainly enjoy > seeing > it implemented (two words: geodetic pillars). Even those will not be permanent. I propose a social solution instead of a technical one. i.e. "please don't change, because..." instead of "you cannot change this, period". -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
I share the discomfort of others about truly non-editable imported data. I have found a number of errors in MassGIS data, although the vast majority of it seems very good. Two approaches come to mind: 1. a. Have a way to have a separate database with such data. b. Have a way to have whiteout objects in the main database signifying a virtual delete of an object in the previous layer. c. Let editors see the previous data as read-only, but support deleting it. 2. as above, but instead of separate databases, use tags in the main db. So the data is immutable in some sense, but we could decide not to include some object. pgpvOiZxOAF71.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 9, 2009 at 10:22 PM, Frederik Ramm wrote:
> Hi,
>
> Russ Nelson wrote:
>> On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
>>> If we can't change the data, what's the point of having it in OSM?
>>
>> Having consistent metadata and a consistent single-source API.
>
> That's exactly what I said in my first reply:
>
> Once OSM and its tool chain are established, everyone is going to want
> to have their data in OSM. ("Because then I only have to change my style
> file and the data is there on my map, instead of having to think about
> how to download it from elsewhere.")
>
> Which is ok, even desired, as long as the data is relevant and unless
> you consider the data your property that nobody must change.
>
> The power of OSM is not the API but the people. If you don't want the
> people then don't misuse our API to store your data just because it
> makes it easier for you to generate nice maps.
>
> By all means, set up another server with the OSM API running on it where
> you hand out accounts only to those who are privileged enough to change
> immutable data and adapt your toolchain to query both servers. (Or
> generally adapt the OSM toolchain to work with multiple servers.)
>
> I am absolutely sure that the dataset in question will, like any other
> dataset on the planet, contain errors. And if we find erroneous data in
> OSM, and know better, we will fix it in OSM, rather than asking some
> authority to please correct their data and then have a fixed update half
> a year later.
>
> There are a number of things one could do when working with such
> official data. As 80n has suggested, the data could be tagged and
> editors could make the user aware of the fact that someone was of the
> opinion that this data should not be changed and whether he's sure of
> what he's doing. It would also be possible to write software that works
> in a web-of-trust kind of way: "Extract these boundaries from OSM but
> only accept changes from users I trust; if other users have changed the
> data then go back in history until you find a change done by a trusted
> user". So anyone who is keen on extracting the "official" view rather
> than what OSM mappers made of it could do so.
>
> The cool thing about this is that it would follow OSM's mantra of
> filtering on the output side, not on the input side. The output you get
> would depend on which people you trust; whereas what you had been
> suggesting would be to just discard, in the database, everything done by
> people you don't trust.
>
> I maintain that it would be totally inacceptable to OSM to automatically
> revert changes to objects that are deemed "immutable".
+1
Reminds me a lot of the discussions about SRTM data. There's no point
in importing it into OSM since it's not community-editable (and it's
authoritative in its own context), but we've written tools to convert
it into OSM format for easier use. But we don't confuse the
on-the-wire-format with which db / project it should be sourced from.
Cheers,
Andy
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
2009/3/10 Russ Nelson > > On Mar 9, 2009, at 4:11 PM, Ulf Lamping wrote: > > > > OSM is about to have a *free* database. Saying "your not allowed to > > change the data" is *not* a free database as I understand it. > > For this particular case, it's not that you're not "allowed" to change > the data -- it's that it makes no sense to change the data. The data > is an assertion by the DEC of what lands it manages. By definition > nobody can change that data -- because then it wouldn't have the same > meaning. I'm not entirely convinced that there would never be a reason where it would make sense to change the data... While I admit, that a lack of sense could be argued for moving boundaries if the data is being kept up to date from an external source, I'm assuming that this dataset consist of more than just polygons with a DEC reference number on them representing areas of land, and I would guess that it doesn't contain all information that could ever possibly be recorded... > And as the fellow points out, there's nothing you can > determine from examining the site which would give you reason or > information necessary to change the data. You could find a sign not > on the boundary -- but that would mean that the sign was wrong -- not > that the boundary should be moved. > Should you examine the site and find additional information, not necessarily a change in the information, but, extra information, would it also be wrong to edit the data to reflect this? As an example, you find that an area of land is surrounded by a razorwire topped electric fence, would it be wrong to add the tags fence=electric, razorwire=true to the existing data? I don't think so... If you find that the area is an area of construction, would it be wrong to modify it with the tag landuse=construction? Again, I don't think so... etc... So, in short, I think immutable data would be wrong, modification in OSM aren't just about moving things around... But, I can see a reason why someone would want to take responsibility for making sure positional information doesn't change independantly of the datasource in such a way that the data can no longer accurately represent what was imported... But... I see this as more of an issue of someone taking responsibility of monitoring and maintaining the data rather than making it impossible for people to change... d ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 9, 2009, at 6:22 PM, Frederik Ramm wrote: > I am absolutely sure that the dataset in question will, like any other > dataset on the planet, contain errors. I agree. But how to convince someone who doesn't agree? I don't think words will convince; it will take data. They need to have that "Oh, yeah, that was wrong, wasn't it?" moment. > I maintain that it would be totally inacceptable to OSM to > automatically > revert changes to objects that are deemed "immutable". What about objects which were created_by=Potlatch? :-) -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Ulf Lamping wrote:
>> What's needed here is not an immutable=yes tag but rather a couple of
>> tags source=DEC and accuracy=definitive which will give GPS toting
>> mappers the information they need to know that the data in OSM is likely
>> to be more accurate that their GPS. They can then take an informed view
>> about whether or not to mess with it.
>
> Sounds like a good approach. Having something like "You are about to
> edit data that is probably more accurate ( with common GPS equipment. Are you really sure you want to change this?"
+1 from me too. With a positive, non-zero floating-point {number of
metres | dilution of precision} as an allowed value, perhaps.
Perhaps it should decay automatically to less accurate measurements if
people edit it with less accurate equipment. Quite how you assess how
accurate a given device, trace or vector is is left as an exercise for
the reader, naturally. And could be difficult since the OSMdb doesn't
appear to record any of that stuff...
--
Andrew Chadwick
signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Hi,
Russ Nelson wrote:
> Obviously the potential
> exists for a revert war, but given that I have a reasonable claim for
> my authority (e.g. http://rutlandtrail.org/list.cgi), why would
> someone else edit data that I am more expert in?
Your mistake, if you allow me to say to bluntly, lies in claiming
absolute authority. You assume that your authority is paramount and
nobody in their right mind - whether they have ever heard of you and
your credentials or not - would have to believe you over Joe Mapper.
Assumptions of this kind don't work well with a project like
OpenStreetMap because we generally don't have, and don't want to impose,
such a structure.
("For the avoidance of doubt", the following is a long-term vision, not
an idea we should implement tomorrow.)
However if you could turn the thing around and use your authority to
create something like a "seal of approval" and establish processes
around that, then instead of threatening to delete other people's data
you would simply say: "Edit all you want but I will only give my seal of
approval to data I consider correct." - and those who have reason to
believe that you are an authority on the matter would then indeed prefer
to use your approved version of objects and disregard edits made by
other people. There might even be cool tools that allow you to see which
ones of your approved objects have been changed, and then contemplate
whether to approve the changed version as well ("approving" would simply
mean to upload the object with your user id, making you the last person
to touch it).
That way, those who believe in your claim to authority (or maybe,
web-of-trust like, those who believe someone else who believes in your
claim and so on) will see your approved version of things, and those who
don't will see the latest edits.
If such a structure is established, and it surely will take time until
the proper tools are developed and so on, then maybe in certain areas we
will see a kind of quality control boards developing, and maybe some
large tile providers will choose e.g. not to render anything in North
America unless it is approved by someone who is in the list of members
of the quality control board. Whatever.
The core idea to all of this is that everything is voluntary. There
could be a number of rival quality control boards and everyone could
choose whom he trusts, or you could ignore all those crazy people and
just look at the current version of the data.
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] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: > How do people feel about me importing this data (with all of their > metadata), adding an immutable=yes tag, with the intent of tracking > their dataset, and deleting --outright-- any changes made by OSM > editors. Let me get this straight - this would be the same sort of idea as an invariant section in a DFSG document? If so, there is a particular case that may be of note: incorporation of OSM data into large projects such as Debian. See http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines#Non-software_content and thence http://www.debian.org/vote/2006/vote_001 . I would like to see OSM data incorporated as readily as possible, as needed, into projects like Debian. Right now, I don't support this. If changes are considered inappropriate at any point by the originators of the data, then OSM, which is by definition and tradition a ShareAlike, not-NoDerivs community is not the place to store such data. I would consider this sort of upload to be in direct contravention of our license, and delete it on sight. -- Andrew Chadwick signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 9, 2009 at 10:22 PM, Russ Nelson wrote: > > On Mar 9, 2009, at 4:11 PM, Ulf Lamping wrote: > > > > OSM is about to have a *free* database. Saying "your not allowed to > > change the data" is *not* a free database as I understand it. > > For this particular case, it's not that you're not "allowed" to change > the data -- it's that it makes no sense to change the data. The data > is an assertion by the DEC of what lands it manages. By definition > nobody can change that data -- because then it wouldn't have the same > meaning. And as the fellow points out, there's nothing you can > determine from examining the site which would give you reason or > information necessary to change the data. You could find a sign not > on the boundary -- but that would mean that the sign was wrong -- not > that the boundary should be moved. > > But this raises a larger question. I have some reason to assert a > claim of authority for railroad data for New York State. How would > you react to me staking a claim on NYS railroad data in OSM, saying > "fair warning: if you edit any railroad data in NYS, I will revert > your changes unless I approve of them." Obviously the potential > exists for a revert war, but given that I have a reasonable claim for > my authority (e.g. http://rutlandtrail.org/list.cgi), why would > someone else edit data that I am more expert in? > > Yes, this is a very high-level topic; much higher than any import. > Is there room in OSM for people to make more authoritative edits than > other people? On what basis are we to evaluate the quality of edits? > How do we know if a particular edit improves or degrades the accuracy > of the map? > The best guideline we have at the moment is to map what is on the ground. If someone is there on the ground and makes an observation then they have the ultimate right. The fact that you were there yesterday is just history ;) > > -- > Russ Nelson - http://community.cloudmade.com/blog - > http://wiki.openstreetmap.org/wiki/User:RussNelson > r...@cloudmade.com - http://openstreetmap.org/user/RussNelson > > > ___ > 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] immutable=yes Fwd: DEC Lands
On Mar 9, 2009, at 4:36 PM, Richard Fairhurst wrote: > > ActionScript or Ruby whatever to say "get all geodata within this > bbox from > openstreetmap.org, and also freesurveyorsstuff.org, and return it in > one > object", that would fulfil the need - without bending OSM to do > something it > was never intended to do. And then an editor would say "Gee, this State Forest isn't in OSM. That's wrong. I'll add it." So then why should his data be in OSM but not the DEC's data? My feeling is that if an editor would add it, and we have it, then we should head them off at the pass. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 9, 2009, at 4:11 PM, Ulf Lamping wrote: > > OSM is about to have a *free* database. Saying "your not allowed to > change the data" is *not* a free database as I understand it. For this particular case, it's not that you're not "allowed" to change the data -- it's that it makes no sense to change the data. The data is an assertion by the DEC of what lands it manages. By definition nobody can change that data -- because then it wouldn't have the same meaning. And as the fellow points out, there's nothing you can determine from examining the site which would give you reason or information necessary to change the data. You could find a sign not on the boundary -- but that would mean that the sign was wrong -- not that the boundary should be moved. But this raises a larger question. I have some reason to assert a claim of authority for railroad data for New York State. How would you react to me staking a claim on NYS railroad data in OSM, saying "fair warning: if you edit any railroad data in NYS, I will revert your changes unless I approve of them." Obviously the potential exists for a revert war, but given that I have a reasonable claim for my authority (e.g. http://rutlandtrail.org/list.cgi), why would someone else edit data that I am more expert in? Yes, this is a very high-level topic; much higher than any import. Is there room in OSM for people to make more authoritative edits than other people? On what basis are we to evaluate the quality of edits? How do we know if a particular edit improves or degrades the accuracy of the map? -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Hi,
Russ Nelson wrote:
> On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote:
>> If we can't change the data, what's the point of having it in OSM?
>
> Having consistent metadata and a consistent single-source API.
That's exactly what I said in my first reply:
Once OSM and its tool chain are established, everyone is going to want
to have their data in OSM. ("Because then I only have to change my style
file and the data is there on my map, instead of having to think about
how to download it from elsewhere.")
Which is ok, even desired, as long as the data is relevant and unless
you consider the data your property that nobody must change.
The power of OSM is not the API but the people. If you don't want the
people then don't misuse our API to store your data just because it
makes it easier for you to generate nice maps.
By all means, set up another server with the OSM API running on it where
you hand out accounts only to those who are privileged enough to change
immutable data and adapt your toolchain to query both servers. (Or
generally adapt the OSM toolchain to work with multiple servers.)
I am absolutely sure that the dataset in question will, like any other
dataset on the planet, contain errors. And if we find erroneous data in
OSM, and know better, we will fix it in OSM, rather than asking some
authority to please correct their data and then have a fixed update half
a year later.
There are a number of things one could do when working with such
official data. As 80n has suggested, the data could be tagged and
editors could make the user aware of the fact that someone was of the
opinion that this data should not be changed and whether he's sure of
what he's doing. It would also be possible to write software that works
in a web-of-trust kind of way: "Extract these boundaries from OSM but
only accept changes from users I trust; if other users have changed the
data then go back in history until you find a change done by a trusted
user". So anyone who is keen on extracting the "official" view rather
than what OSM mappers made of it could do so.
The cool thing about this is that it would follow OSM's mantra of
filtering on the output side, not on the input side. The output you get
would depend on which people you trust; whereas what you had been
suggesting would be to just discard, in the database, everything done by
people you don't trust.
I maintain that it would be totally inacceptable to OSM to automatically
revert changes to objects that are deemed "immutable".
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] immutable=yes Fwd: DEC Lands
On Mon, Mar 9, 2009 at 9:24 PM, 80n <80n...@gmail.com> wrote: > What's needed here is not an immutable=yes tag but rather a couple of tags > source=DEC and accuracy=definitive which will give GPS toting mappers the > information they need to know that the data in OSM is likely to be more > accurate that their GPS. They can then take an informed view about whether > or not to mess with it. > This is how it is done for the NOFI border: http://www.openstreetmap.org/browse/way/29505551/history http://www.openstreetmap.org/browse/node/325229872/history - Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
80n schrieb: > > The problem with GPS toting mappers is that they will often believe > their GPS tracks are at least as accurate as those used for all the > other data in OSM, so there's a strong temptation to move things around > a bit based on the information they have to hand - I know, I've done it. ;-) A bit of a skeptical view about your own GPS data accuracy is *always* a good idea, no doubt about that :-) > What's needed here is not an immutable=yes tag but rather a couple of > tags source=DEC and accuracy=definitive which will give GPS toting > mappers the information they need to know that the data in OSM is likely > to be more accurate that their GPS. They can then take an informed view > about whether or not to mess with it. Sounds like a good approach. Having something like "You are about to edit data that is probably more accurate (http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
El Lunes, 9 de Marzo de 2009, 80n escribió: > What's needed here is not an immutable=yes tag but rather a couple of tags > source=DEC and accuracy=definitive [...] +1. Current tools (ITO OSM mapper, for instance) will be able to deal with changes applied to a set of ways tagged a certain way. I don't think that coding an "immutable flag" in the API is neccesary at all. -- -- Iván Sánchez Ortega Proudly running Debian Linux with 2.6.26-1-amd64 kernel, KDE 3.5.10, and PHP 5.2.6-3 generating this signature. Uptime: 21:37:59 up 3 days, 23:11, 1 user, load average: 1.46, 1.94, 2.08 signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: > How do people feel about me importing this data (with all of > their metadata), adding an immutable=yes tag, with the intent > of tracking their dataset, and deleting --outright-- any changes > made by OSM editors. If it can't be edited, there's no point sending it to the editor. It would only mean more bandwidth => slower editing. Therefore I would alter amf_controller so that anything with immutable=yes wasn't sent to Potlatch. (At which point most of Germany would tag their towns immutable=yes... but I digress. :) ) So what's the point of having it there? I presume so that people can get it via the OSM API and via planet dumps (you've said as much in another post: "consistent metadata and a consistent single-source API"). To me, this is another argument for good libraries in popular scripting languages, not for putting it in OSM. If I could do a call from Perl or ActionScript or Ruby whatever to say "get all geodata within this bbox from openstreetmap.org, and also freesurveyorsstuff.org, and return it in one object", that would fulfil the need - without bending OSM to do something it was never intended to do. cheers Richard -- View this message in context: http://www.nabble.com/immutable%3Dyes-Fwd%3A-DEC-Lands-tp22419231p22419570.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 9, 2009 at 8:11 PM, Ulf Lamping wrote: > Russ Nelson schrieb: > > On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote: > >> If we can't change the data, what's the point of having it in OSM? > > > > Having consistent metadata and a consistent single-source API. > > > On what bases would someone with no formal training, no legal deed > description, or survey map have to determine if a State boundary is > correct or incorrect. Simply holding a GPS receiver does not give > someone authority. > >> This sounds like many arguments against wikipedia -- of *course* only > >> highly trained professionals should be allowed to edit an > >> encyclopedia! > > > > Note his title: Surveyors get VERY VERY grumpy whenever they hear that > > people with a GPS receiver are using it for positional recording. > > VERY grumpy. > > > > Hmmm, maybe surveyors are not compatible with OSM then :-) > > > "Simply holding a GPS receiver does not give someone authority." That's > perfectly true. But we're not searching for authorative reference. If > they want to have an "authoritive database", OSM is probably the wrong > place to look at! > The problem with GPS toting mappers is that they will often believe their GPS tracks are at least as accurate as those used for all the other data in OSM, so there's a strong temptation to move things around a bit based on the information they have to hand - I know, I've done it. What's needed here is not an immutable=yes tag but rather a couple of tags source=DEC and accuracy=definitive which will give GPS toting mappers the information they need to know that the data in OSM is likely to be more accurate that their GPS. They can then take an informed view about whether or not to mess with it. 80n > > OSM is about to have a *free* database. Saying "your not allowed to > change the data" is *not* a free database as I understand it. > > > I would like to see that data included, but if this sacrifies the > principles of OSM, I'd say thanks, but no thanks! > > Regards, ULFL > > ___ > 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] immutable=yes Fwd: DEC Lands
Russ Nelson schrieb: > On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote: >> If we can't change the data, what's the point of having it in OSM? > > Having consistent metadata and a consistent single-source API. > On what bases would someone with no formal training, no legal deed description, or survey map have to determine if a State boundary is correct or incorrect. Simply holding a GPS receiver does not give someone authority. >> This sounds like many arguments against wikipedia -- of *course* only >> highly trained professionals should be allowed to edit an >> encyclopedia! > > Note his title: Surveyors get VERY VERY grumpy whenever they hear that > people with a GPS receiver are using it for positional recording. > VERY grumpy. > Hmmm, maybe surveyors are not compatible with OSM then :-) "Simply holding a GPS receiver does not give someone authority." That's perfectly true. But we're not searching for authorative reference. If they want to have an "authoritive database", OSM is probably the wrong place to look at! OSM is about to have a *free* database. Saying "your not allowed to change the data" is *not* a free database as I understand it. I would like to see that data included, but if this sacrifies the principles of OSM, I'd say thanks, but no thanks! Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: > On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote: >> If we can't change the data, what's the point of having it in OSM? > > Having consistent metadata and a consistent single-source API. Interesting reasons, not exactly what motivates me the most about OSM, but I can see how that might be of interest. You didn't answer the first part of my question -- Why? Is the reason this data should not be editable because Robert Morrell says so? On what bases would someone with no formal training, no legal deed description, or survey map have to determine if a State boundary is correct or incorrect. Simply holding a GPS receiver does not give someone authority. >> This sounds like many arguments against wikipedia -- of *course* only >> highly trained professionals should be allowed to edit an >> encyclopedia! > > Note his title: Surveyors get VERY VERY grumpy whenever they hear that > people with a GPS receiver are using it for positional recording. > VERY grumpy. Yes, I see. So should OSM take the "wiki" out of "The Free Wiki World Map" because it makes certain people grumpy? I'm not sure why I should care so much about what these people think. >> We can't change what OSM is all about just because somebody else (who >> happens to have some geodata we might want to import) doesn't like it! > > You're arguing that we shouldn't change OSM because we can change OSM?? That sounds clever and ironic, but of course is not what I'm saying. Changing tags is one thing, yes of course that happens all the time. But you are talking about making it so that nobody other than you can edit this data, and I am saying that conflicts with what I think OSM is all about. I'm arguing that making OSM data immutable because these people from DEC think it ought to be is a bad reason to break an important property of OSM. Now, if data needs to be immutable to deal with abuse or vandalism, that could be a much better reason, but that's not what we're talking about is it? -- Matthew Toups, OpenStreetMap.org Regional Community Ambassador matt...@cloudmade.com || 504-684-4OSM (4676) || Skype: MatthewToupsCloudMade ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 9, 2009, at 3:07 PM, Matthew Toups wrote: > If we can't change the data, what's the point of having it in OSM? Having consistent metadata and a consistent single-source API. >>> On what bases would someone with no formal training, no legal deed >>> description, or survey map have to determine if a State boundary is >>> correct or incorrect. Simply holding a GPS receiver does not give >>> someone authority. > > This sounds like many arguments against wikipedia -- of *course* only > highly trained professionals should be allowed to edit an > encyclopedia! Note his title: Surveyors get VERY VERY grumpy whenever they hear that people with a GPS receiver are using it for positional recording. VERY grumpy. > We can't change what OSM is all about just because somebody else (who > happens to have some geodata we might want to import) doesn't like it! You're arguing that we shouldn't change OSM because we can change OSM?? -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 9, 2009 at 13:54, Russ Nelson wrote: > > On Mar 9, 2009, at 2:39 PM, Frederik Ramm wrote: > >> if someone has data that must not be modified >> (because of course it is 100% error free...?) then don't put that data >> in OSM! > > > *I* see OSM as an API for all possible geodata: everything that > doesn't move, and a few things that do. There are arguably many > things currently in OSM which should not be edited. For example, > political boundaries at every level. That assumes that they're correct in the first place and not going to change. In a few spots (the Texas-Mexico border, for instance,) we have three different sets of borders from three different imports for three different administrative levels, none of which line up very will with each other or with the river they're nominally running down the middle of (as far as I know here, the de facto border here is the Rio Grande/Rio Bravo's channel, not where it was running when it was first/last surveyed.) -- David J. Lynch djly...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mon, Mar 9, 2009 at 7:54 PM, Russ Nelson wrote: > *I* see OSM as an API for all possible geodata: everything that > doesn't move, and a few things that do. There are arguably many > things currently in OSM which should not be edited. For example, > political boundaries at every level. Well... Many of the boundaries could very well do with some editing. I have worked with the Norwegian-Russian and Norwegian-Finnish borders. First of all, the CIA data are very inaccurate (150 meters or more in some cases). Then you have borders that are not static (the Norwegian-Russian border follows the actual thalweg in some places, and most international borders are officially surveyed every 25 years or so). Even when you have a surveyed border and access to the official documents there are inaccuracies (Norway-Finland is accurate to a few millimeters, but the conversion to WGS84 for Norway-Russia is maybe as uch as a few meters inaccurate). And finally you have OSM tagging changing. Some objects needs a lot more care when editing than others, but that is not to say that someone with the right knowledge and sources available should be unable to edit them. - Gustav ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: > Earlier, I proposed that certain datasets should be immutable; whether > by policy or mechanism as needed. I propose importing the NYS DEC > Lands as an immutable set of data. If you read this exchange with > Robert Morrell, you can see why they feel that NO changes AT ALL are > appropriate. I agree with them. This dataset constitutes a legal > description of the property managed by the NYS Department of > Environmental Conservation, and changes by any OSM editor are not > consistent with the nature of the data. > > How do people feel about me importing this data (with all of their > metadata), adding an immutable=yes tag, with the intent of tracking > their dataset, and deleting --outright-- any changes made by OSM > editors. Why? Because someone outside of OSM thinks changes to the data would be bad? If we can't change the data, what's the point of having it in OSM? Maybe this could be cleared up by an explanation that any edits to the data after an import to OSM would be an edit to OSM, not an edit to *their* data -- so their data would remain "pristine." It seems like, reading the forwarded message below, that these folks seem worried that something horrible is going to happen to their data if we allow people to edit it. I think that is incorrect. >> From: Robert Morrell >> Date: March 9, 2009 2:06:13 PM EDT >> To: Russ Nelson >> Cc: Kurt Swartz , Larry Alber >> > Subject: Re: DEC Lands >> >> Russ, >> There is no "creativity" in mapping or displaying of Public >> owned land. This isn't art, it's legal land rights that impact >> private land owners. Sure, which is why this agency should continue to maintain a set of data that people outside of their department cannot edit. I don't think we're proposing that OSM become the primary source for information about land rights; we just want to make a free map (including data from a variety of free sources) which anyone can edit. >> On what bases would someone with no formal training, no legal deed >> description, or survey map have to determine if a State boundary is >> correct or incorrect. Simply holding a GPS receiver does not give >> someone authority. This sounds like many arguments against wikipedia -- of *course* only highly trained professionals should be allowed to edit an encyclopedia! I think that the main thing to tell these people is that just because we're using a different model, where anyone *can* edit the map data, doesn't mean that they cannot continue to maintain their dataset the way they see fit. We can't change what OSM is all about just because somebody else (who happens to have some geodata we might want to import) doesn't like it! -- Matthew Toups, OpenStreetMap.org Regional Community Ambassador matt...@cloudmade.com || 504-684-4OSM (4676) || Skype: MatthewToupsCloudMade ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Russ Nelson wrote: > > *I* see OSM as an API for all possible geodata: everything that > doesn't move, and a few things that do. There are arguably many > things currently in OSM which should not be edited. For example, > political boundaries at every level. > > Hmmm, political boundaries change from time to time, parish, city and county boundaries are changed over time, even countries come and go. OSM is a wiki - *nothing* on this planet is immutable. The coastline near me is being eaten away by metres every year. The only automatic process I would like to see is the removal of immutable=yes ;-) Cheers, Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 9, 2009, at 2:38 PM, Iván Sánchez Ortega wrote: > However, land use *is* mutable... I'd agree on marking this dataset as > immutable *only* *if* the NYS DEC agrees to regularly pass on OSM > any updates > to the dataset. Otherwise, we would end up with obsolete data, which > is a Bad > Thing™. NYS DEC regularly publishes updated shapefiles. *I* would be the person keeping it up to date. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
> In that case, the data should not be in OSM but should instead be pulled > in on another level - for example, create transparent tiles to show on > top of OSM tiles, or make a shapefile and pull that in through Mapnik. Well, if the data won't be in OSM (neither in dumps or in things received from API), how would people see them? Slippy map is not all we have. Plus, this would make harder to make data derived from it (if appropriate). >> How do people feel about me importing this data (with all of their >> metadata), adding an immutable=yes tag, with the intent of tracking >> their dataset, and deleting --outright-- any changes made by OSM >> editors. While the data may be very accurate and usually they shouldn't be edited, I don't think they should be really immutale - someone may still want to correct tags or names (even "100% correct" data from authorities often have at least few mispelling in them). The data could be watched for changes, but I don't think forbidding any changes or automatically reverting them without examining the change is the way to go. Maybe the immutable tag could get some support in editor that will show some big warning when you (probably accidentally) try to edit these data (so it would be more of a hint that the data should not be changed), but I won't forbid it in general. Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
On Mar 9, 2009, at 2:39 PM, Frederik Ramm wrote: > if someone has data that must not be modified > (because of course it is 100% error free...?) then don't put that data > in OSM! *I* see OSM as an API for all possible geodata: everything that doesn't move, and a few things that do. There are arguably many things currently in OSM which should not be edited. For example, political boundaries at every level. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] immutable=yes Fwd: DEC Lands
Hi, Russ Nelson wrote: > and changes by any OSM editor are not > consistent with the nature of the data. In that case, the data should not be in OSM but should instead be pulled in on another level - for example, create transparent tiles to show on top of OSM tiles, or make a shapefile and pull that in through Mapnik. I assume that with OSM becoming more popular and OSM tools becoming more widely used, there will be some pressure on OSM to import various kinds of data that is alien to the concept of OSM just to make it easier for the users - but we must resist that pressure. OSM data is data made by and for the people, and if someone has data that must not be modified (because of course it is 100% error free...?) then don't put that data in OSM! > How do people feel about me importing this data (with all of their > metadata), adding an immutable=yes tag, with the intent of tracking > their dataset, and deleting --outright-- any changes made by OSM > editors. Absolutely impossible if you ask me. 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] immutable=yes Fwd: DEC Lands
El Lunes, 9 de Marzo de 2009, Russ Nelson escribió: > Earlier, I proposed that certain datasets should be immutable; whether > by policy or mechanism as needed.[...] > > How do people feel about me importing this data (with all of their > metadata), adding an immutable=yes tag, with the intent of tracking > their dataset, and deleting --outright-- any changes made by OSM > editors. I agree that an "immutable" tag is a good idea, and I'd certainly enjoy seeing it implemented (two words: geodetic pillars). However, land use *is* mutable... I'd agree on marking this dataset as immutable *only* *if* the NYS DEC agrees to regularly pass on OSM any updates to the dataset. Otherwise, we would end up with obsolete data, which is a Bad Thing™. Cheers, -- -- Iván Sánchez Ortega Alex Schenck: "Raise your hand here if you have edited Wikipedia" Larry Pieniazek: "Does that include vandalizing?" signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
