Re: [Talk-us] [Tagging] Smooth shoulder intended for cycling
Hmmm. Apparently Thunderbird's 'reply to list' fails when there are multiple lists. Sending again: On 4/17/2012 11:47 PM, Steve Bennett wrote: I quite like "cycleway=shoulder". It describes exactly what's going on: the cycling infrastructure at this point isn't a marked lane (cycleway=lane), nor a segregated lane (cycleway=track), it's a sealed road shoulder. Could you elaborate on your objections? It implies that the shoulder is an official cycleway, when in reality it may be full of debris (or worse: http://flbikelaw.org/2012/03/paved-shoulder/ ). Would you use a cycleway tag on any sidewalk that one can ride on (here that would be any outside city limits), or just those that have been specially designated as such? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] Smooth shoulder intended for cycling
On 4/17/2012 11:47 PM, Steve Bennett wrote: I quite like "cycleway=shoulder". It describes exactly what's going on: the cycling infrastructure at this point isn't a marked lane (cycleway=lane), nor a segregated lane (cycleway=track), it's a sealed road shoulder. Could you elaborate on your objections? It implies that the shoulder is an official cycleway, when in reality it may be full of debris (or worse: http://flbikelaw.org/2012/03/paved-shoulder/ ). Would you use a cycleway tag on any sidewalk that one can ride on (here that would be any outside city limits), or just those that have been specially designated as such? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] Smooth shoulder intended for cycling
On Wed, Apr 18, 2012 at 11:15 AM, Nathan Edgars II wrote: > One regional mapper uses cycleway=shoulder for this, but I see that as > sub-optimal, since it's primarily a shoulder, not a cycleway. It would be > like putting cycleway=sidewalk whenever there's a smooth paved sidewalk. I quite like "cycleway=shoulder". It describes exactly what's going on: the cycling infrastructure at this point isn't a marked lane (cycleway=lane), nor a segregated lane (cycleway=track), it's a sealed road shoulder. Could you elaborate on your objections? The real complication arises when there are shoulders of varying quality that are assessed (by cyclists) as being more or less suitable for cycling - leading to issues of subjectivity. At least the situation you describe appears objective: the surface was intended for cycling on. Steve ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Smooth shoulder intended for cycling
On 4/17/2012 9:43 PM, Kristian M Zoerhoff wrote: Alternatively, maybe cycleway needs an "unmarked lane" setting for these situations, though that would imply the local authorities are intending for cyclists to use the shoulder, rather than just tolerating their presence (the usual situation). I use cycleway=unmarked_lane for FDOT's "undesignated bike lane", which has a white line on the right side but no bike markings. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On 4/17/2012 9:23 PM, Serge Wroclawski wrote: On Tue, Apr 17, 2012 at 8:52 PM, Nathan Edgars II wrote: When I joined OSM I went through photos and notes I had taken since the late 1990s. There's no guarantee of timeliness here either. Certainly not as much as an import of city boundary data that has each annexation marked through the current year. Don't worry, I wasn't counting you NE2- according to your own profile, you use a made up name, and according to your editing patterns, you're a bot, so you're more of an import than a user. Ah, the old ad hominem. When you can't reply, be a dick. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Smooth shoulder intended for cycling
On Tue, Apr 17, 2012 at 09:15:49PM -0400, Nathan Edgars II wrote: > I'm wondering what the best way would be to tag a good-quality > shoulder that acts essentially as an undesignated bike lane, in that > you can use it but it is not required. Current Florida DOT policy is > to use these on rural roads, with marked bike lanes only when there > is a lane to the right. For example here: > http://maps.google.com/maps?hl=en&ll=30.605358,-86.950672&spn=0.008255,0.016512&gl=us&t=m&z=17&layer=c&cbll=30.605241,-86.950558&panoid=X4-X3CdhvVO_ptMWbvB8SA&cbp=12,330.83,,0,9.24 > One can choose to ride either in the right lane or on the shoulder > beyond the intersection. > > One regional mapper uses cycleway=shoulder for this, but I see that > as sub-optimal, since it's primarily a shoulder, not a cycleway. It > would be like putting cycleway=sidewalk whenever there's a smooth > paved sidewalk. > > On the other hand, shoulder=yes or shoulder=paved says nothing about > the quality of the shoulder. Should there be a minimum width for a > shoulder (FDOT's standard is 4 feet)? cycleway=shoulder doesn't seem right to me, either, and I'm a fairly frequent cyclist (or was, before kids). *If* we are going to mark shoulders, I think we need a series of tags, such as: shoulder:surface=paved/unpaved shoulder:width=4 ft shoulder:rumble_strips:yes/no/aashto (this is very important for cyclists, as continuous strips render the shoulder useless for cycling, and yes, there is an AASHTO standard) Has anyone run this by the OpenCycleMap folks? They're the only likely data consumer for this information at present. Alternatively, maybe cycleway needs an "unmarked lane" setting for these situations, though that would imply the local authorities are intending for cyclists to use the shoulder, rather than just tolerating their presence (the usual situation). -- Kristian M Zoerhoff pgpzAtbN0C49i.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On Tue, Apr 17, 2012 at 8:52 PM, Nathan Edgars II wrote: > When I joined OSM I went through photos and notes I had taken since the late > 1990s. There's no guarantee of timeliness here either. Certainly not as much > as an import of city boundary data that has each annexation marked through > the current year. Don't worry, I wasn't counting you NE2- according to your own profile, you use a made up name, and according to your editing patterns, you're a bot, so you're more of an import than a user. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Smooth shoulder intended for cycling
I'm wondering what the best way would be to tag a good-quality shoulder that acts essentially as an undesignated bike lane, in that you can use it but it is not required. Current Florida DOT policy is to use these on rural roads, with marked bike lanes only when there is a lane to the right. For example here: http://maps.google.com/maps?hl=en&ll=30.605358,-86.950672&spn=0.008255,0.016512&gl=us&t=m&z=17&layer=c&cbll=30.605241,-86.950558&panoid=X4-X3CdhvVO_ptMWbvB8SA&cbp=12,330.83,,0,9.24 One can choose to ride either in the right lane or on the shoulder beyond the intersection. One regional mapper uses cycleway=shoulder for this, but I see that as sub-optimal, since it's primarily a shoulder, not a cycleway. It would be like putting cycleway=sidewalk whenever there's a smooth paved sidewalk. On the other hand, shoulder=yes or shoulder=paved says nothing about the quality of the shoulder. Should there be a minimum width for a shoulder (FDOT's standard is 4 feet)? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On 4/17/2012 8:18 PM, Serge Wroclawski wrote: If a user manually surveys data, there is an assumption of timeliness and accuracy of that survey. That's not the case with imported data, despite oftentimes being stamped "official". When I joined OSM I went through photos and notes I had taken since the late 1990s. There's no guarantee of timeliness here either. Certainly not as much as an import of city boundary data that has each annexation marked through the current year. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On Tue, Apr 17, 2012 at 7:51 PM, Dale Puch wrote: >> I think this point is controversial, so let's stick with some points >> that aren't: >> >> 1. In our history of imports, a very small percentage have been good. > > Compare a users early imports to their early mapping They aren't nearly comparable in my experience. In all my mapping, I see tons of bad imported data, but I see very few errors due to newbie mappers. Sometimes I'll find a mistagged feature, or an unclosed way, but overall I find users to be fairly careful, and when they're not, the mistakes they make are small and confined. Imports, on the other hand, are widespread, pervasive and are often hard to detect. I see features which are hard to verify without surveying, and I find odd OSM features, like ways that share the same geometry (even the same nodes), or duplicated features close to each other, but from different sources. Your argument that the problems are similar don't bear out in my experience mapping with OSM, the problems are neither similar in type nor scale. Nonetheless I've personally taken steps to address both. For new mappers I am very involved in helping the community. I've run mapping parties, I've made a video tutorial series, I'm active on the newbies list and (less) active on help.osm.org, and can often be found helping users on our IRC channel. Importers, sadly, rarely ask as many questions as new mappers. >> 2. We have no current technology to keep an import synced with another >> data source, so the data goes stale quickly. > > Also true for manual edits. Why is this considered just an import issue? For imports, this is often touted as a benefit- that's why the lack of an actual implementation is important to point out. >> 3. Many imports are of datasets we don't want in OSM and we have >> little/no mechanism outside community vetting to discover that until >> it's too late. > > Any user can decide that they want to include "X" into the dataset imported > or manually mapped. If a user manually surveys data, there is an assumption of timeliness and accuracy of that survey. That's not the case with imported data, despite oftentimes being stamped "official". >> 4. Most imports are bad, and most imports are left in OSM, which means >> we have tons of garbage in OSM. Garbage in OSM makes the map harder to >> work with for mappers, for tool-makers and for users. > > see all above I've spent certainly well over a hundred hours cleaning up imported data in OSM. I've never spent close to that dealing with new user problems. - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
Regarding Frederik's 4 points, plus the element duplication issue as reasons imports are bad: ALL are potentially true for any mapper especially new ones. It is just that a bad import can generate a lot more good/bad data at once. So yes, imports need more effort to insure good quality. Regarding dupe items, this is both import related and upload related. The import side is obvious, but failed uploads of any source have generated lots of duplicates as well. This is admittedly more prone with imported data, I would guess fewer users doing manual edits tried to make large uploads. See the notes below for the rest. On Mon, Apr 16, 2012 at 8:30 PM, Serge Wroclawski wrote: > > On Mon, Apr 16, 2012 at 6:46 PM, Frederik Ramm > wrote: > > > I think this point is controversial, so let's stick with some points > that aren't: > > 1. In our history of imports, a very small percentage have been good. > Compare a users early imports to their early mapping > 2. We have no current technology to keep an import synced with another > data source, so the data goes stale quickly. > Also true for manual edits. Why is this considered just an import issue? > 3. Many imports are of datasets we don't want in OSM and we have > little/no mechanism outside community vetting to discover that until > it's too late. > Any user can decide that they want to include "X" into the dataset imported or manually mapped. 4. Most imports are bad, and most imports are left in OSM, which means > we have tons of garbage in OSM. Garbage in OSM makes the map harder to > work with for mappers, for tool-makers and for users. > see all above > > - Serge > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us > -- Dale Puch ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
Sure, Alan. I'll try to help by explaining a core of my process, and you and others can take it from there. Great job - thanks for this. I'm sure it helps. Appreciate the kudos. We might all share like this when asked. This is called a "workflow" and workflows with specific numbered steps are valuable/crucial nuggets of knowledge when somebody needs one to solve a specific problem AND a workflow HAS BEEN SHARED. So, ask, and, if you KNOW, share WHEN asked! 7) For ways (I'm not going to explain points), here is what I do: ... So, we're basically duplicating the existing way and then "blessing" it. Is this really sufficient - to verify the "tainted" geometry instead of re-drawing it? If so, why is it not sufficient that, in many, many cases, the original creator of the way has not accepted CT, but many other accepting mappers have afterwards aligned (i.e. moved nodes) and tagged (in my case, with sources of sat imagery, local photo survey, county records, and/or even GPS survey) it? Haven't I already "blessed" it? Can't the redaction bot look at the source tag and see this? Another point, at least in SoCal, is that many of our "tainted" ways are created by "blars", who has not accepted the CT. However, these are TIGER-imported ways. They carry the TIGER tags. I'm sure they could be verified as having come from the TIGER import. They were no-doubt the result of having split an existing TIGER way. In this case, why is it not sufficient to see the TIGER tags on the way to consider it "blessed" along with all the other TIGER ways? Especially when tagged afterwards by accepting mappers with sources as above? 8) Repeat step 7 for all bad ways (or points) in the list of "data loss" that License Problems displays. I'd like to suggest step 8.5: Run the OSM validator. It will find all the intersections that were missed, and probably a bunch of other problems that may or may not have pre-existed. 9) Upload your re-mapping efforts. I agree that a step 8.5 to run JOSM Validator is well-indicated here. Thank you for that excellent suggestion. So, can someone from the redaction squad comment on the logic being used and the questions above? I don't know that they reply to this list. I believe they read it, but I have no proof of that. Finally, it is true that my suggested workflow "duplicates an existing (tainted) way and then blesses it." Yes. The additional step of visually verifying with Bing Sat allows this to crystallize into a "solidly legal" footing: "I can see it in Bing, therefore the duplication of something which was unlicensable is now licensable." In other words, "re-drawing" is not necessary (it is sufficient), but it is overkill (unless points are also tainted). Duplication + visual inspection via Bing seems sufficient to me, but it would be really, really good to get the redaction squad to directly address that point. Right here (talk-us) would be just fine. OSM's wiki would, too. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On 4/17/2012 4:26 AM, Frederik Ramm wrote: And now assume there's a third city of equal size where *nothing* has been mapped at all... maybe I shouldn't speak for everyone but for me (and virtually every mapper I know) surely the city with data-but-no-mappers would be least appealing, far below that with no data. You definitely shouldn't speak for other people. I would much prefer imported street data to nothing at all, and James indicated that he would too. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
On Tue, Apr 17, 2012 at 2:22 AM, Alan Mintz wrote: > At 2012-04-16 20:41, Toby Murray wrote: >> >> On Mon, Apr 16, 2012 at 8:37 PM, Nathan Edgars II >> wrote: >> > On 4/16/2012 9:18 PM, Alan Mintz wrote: >> >> At 2012-04-16 14:06, Nathan Edgars II wrote: >> >>> Or you can simply add odbl=clean if there's nothing ungood about the >> >>> object (e.g. it was split from a TIGER way and the splitting is >> >>> something you would have done anyway). >> >> Is this really sufficient? Can someone from the redaction squad >> >> comment? >> >> Can I protect/"bless" a way or node and prevent its redaction simply by >> >> (in good faith) adding this tag? >> > We have no idea what rules the OSMF will use. >> >> Well I won't claim that communication has been great but this >> statement is a little over dramatic. >> >> First of all: odbl=clean *will* be honored. >> ... > > > On nodes as well as ways? As I wrote earlier, if I have tagged a way with a > source that includes imagery, and removed the tiger:reviewed=no tag, it > means I have aligned it to that imagery, including leaving nodes that are in > the correct place alone (sometimes). Can I bless the nodes in the same way? Yes. odbl=clean immediately removes any object from further processing by the bot. See comments on the first function: https://github.com/zerebubuth/openstreetmap-license-change/blob/master/tags.rb >> Also there is this: >> http://wiki.openstreetmap.org/wiki/Open_Data_License/What_is_clean%3F > > > A nice empty page. Tough to argue with :) Works for me. You can search for "what is clean?" and it should be the first result. >> And of course the code is available for anyone to view... although I'm >> not going to claim that this is really good documentation on the >> matter: >> https://github.com/zerebubuth/openstreetmap-license-change > > Nor can you reasonably expect people to use this as a guideline. And I'm a > programmer. Agreed >> There has been talk of the "v0 rule" which I believe is being >> implemented in the code. This means that the act of creating an object >> by a decliner doesn't automatically make it dirty. So if a way was >> created by a decliner with the tag name=Fred and then someone else >> added the tag highway=footway then after the bot gets done with it, >> the way will still exist but only have the highway=footway tag. If an >> accepting user changes the value of the name=* tag then it will be >> clean... except, see the next paragraph. However if all of the way's >> nodes are dirty and get removed then the way itself will have to go >> too since you can't have a zero-node way. > > > I contend, though, that you should not have to change a node to make it > clean. If one has tagged a source with an imagery (or GPS) value, they are > saying that they vouch for the position of the way, including its nodes. > Same applies to removing tiger:reviewed=no (or gnis:reviewed=no). The user > is specifically claiming to have reviewed the position and tagging and > approved it. Should that not be sufficient? I don't disagree with your points although things get complicated in practice. I've seen people mass removing tiger:reviewed tags on any way that they happened to load into JOSM while mapping when they obviously didn't even look at it. Also, what if a user only reviewed/improved the geometry of a dirty way in one spot but the way is several miles long? This may not be the case for things you have touched but there are a lot of people who have done a lot of edits that are less rigorous. >> Unfortunately neither badmap nor OSMI fully implement all of these >> rules so yes there is still far too much uncertainty. But there are >> some facts to be had. > > Why, then, is it acceptable for us to be sitting here with a dagger hanging > over our heads, uncertain as to when and how it will fall? Shouldn't all of > this be nailed down, followed by a reasonable notice period? Why is there a > deadline other than "we need to get it done for the long-term benefit of > OSM?" Won't disagree with this either. Ideally the bot code would have been developed over the past year instead of the past month and then been available to make tools like OSMI and badmap that use the actual code to show what will happen. But that's now how things happened. I'm not trying to lay blame. I've been mostly a spectator to the process myself so I'm certainly not going to throw stones. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
Hi, On 04/17/12 01:05, James Umbanhowar wrote: Being a reformed importer, I generally agree with the don't import rule. However, I have often heard this nugget and in my experience it is based on either anecdote or one set of simulations that assumed that individuals stop joining because they view the map as complete. Is there any good evidence that this is the case? We haven't done a questionnaire for turned-off-mappers really, and I wouldn't know how to even reach out to those who have looked at OSM and decided not to contribute. But personally, I think it's a total no-brainer. Take two equally sized cities which are mapped to an acceptable but not great standard. Assume that in one city there's a group of 20 active mappers who have, in between them, mapped that city, are busy improving it, and where a few of those meet one a month in a pub. Assume that in the other city there are no mappers, and the data is only there because someone from 500 miles away has imported government data. In both cities, some data will be missing, some wrong, some stale. So. Which city would you prefer to be a mapper in - and which city would rather have you despair and give up? And now assume there's a third city of equal size where *nothing* has been mapped at all... maybe I shouldn't speak for everyone but for me (and virtually every mapper I know) surely the city with data-but-no-mappers would be least appealing, far below that with no data. Imports may work if there is a community already large enough to assimilate the imported data, to make it their own. But data imported to places where there is no community, or the community that is there is totally overwhelmed by the data, that's not OpenStreetMap. That's some other project. OpenImportMap, or EditYourGovernmentData or so. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
Nathan Edgars II wrote: On 4/17/2012 3:29 AM, Werner Poppele wrote: I totally agree with Frederik. Yes - imported data turns down new mappers. Have you ever seen those monster multipolygons ? I am sure a new mapper says: Forget that I personally tend to stop my contribution to OSM because of the very bad stuff I see when mapping: Triple contours at the same position, double / triple nodes, unconnected, tiny streams / rivers with a bunch tags. You seem to be arguing against *bad* imports, not imports in general. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Dear Nathan, thats right. I am not totally against any import, but we need a way to prevent *bad imports* with huge consequences for all of us. Nobody is able to fix the most data which were imported during the last years. You, by the way, do a very good job. Thank you very much for any of your contributions. But what about others ? Mapping for example all highways with all related stuff by hand is probably impossible ! The question is not importing data yes or no, the question is in my oppinion how can we cope with the consequences of *bad imports*. We should have a way to make imports as easyly as possible to help new mappers contributing to OSM but we need also a way to keep the database clean. WernerP ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
On 4/17/2012 3:29 AM, Werner Poppele wrote: I totally agree with Frederik. Yes - imported data turns down new mappers. Have you ever seen those monster multipolygons ? I am sure a new mapper says: Forget that I personally tend to stop my contribution to OSM because of the very bad stuff I see when mapping: Triple contours at the same position, double / triple nodes, unconnected, tiny streams / rivers with a bunch tags. You seem to be arguing against *bad* imports, not imports in general. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] tiff, dwg and nad83
Gregory Arenius wrote: Hi, "Imported data turns down potential new mappers." I really disagree with this statement. I think the mappers would be turned off if we didn't import it when available. "So you have all 250,000 address points for the city but instead of using them you'd rather us go collect all of them a second time?!?" Nobody is going to do that. Same with building outlines. It might be true for some data but I think its a largely inaccurate statement. There have also been some really well done imports such as the MassGIS one in MA. Not using that data isn't going to get us any further than using it. It makes our data much more useful, so it gets used, which brings in more contributors which Maybe it would be different if there were no open data to import at all, then people would be more motivated to gather it so it would exist. However, if it does exist, weather or not we use it, that motivation is no longer there. I also think that in the US if government agencies are updating their data that we can use that we should look at that as part of the community. They're producing free data and so are weI just wish they could use our data they way we use theirs. -Greg ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us Dear Gregory I totally agree with Frederik. Yes - imported data turns down new mappers. Have you ever seen those monster multipolygons ? I am sure a new mapper says: Forget that I personally tend to stop my contribution to OSM because of the very bad stuff I see when mapping: Triple contours at the same position, double / triple nodes, unconnected, tiny streams / rivers with a bunch tags. In Albuquerque I - sorry - deleted 43 churches imported from geonames all at the same spot. I have dozens of examples like that. Tell us, how to fix this stuff. By hand ? Waiting for better data ? Writing better software ? Who merges old with new data ? There is a philosophy of Importing and forgetting. For me most kind of imports are some kind of vandalism. Here are some examples: Double contours http://www.openstreetmap.org/?lat=46.1499579&lon=-89.0375386&zoom=16 http://www.openstreetmap.org/?lat=46.127073&lon=-89.0544339&zoom=16 http://www.openstreetmap.org/?lat=46.12705&lon=-89.05509&zoom=16 http://www.openstreetmap.org/?lat=46.18554&lon=-86.03864&zoom=16 Multiple streams / rivers http://www.openstreetmap.org/?lat=46.117362&lon=-88.9222917&zoom=16 http://www.openstreetmap.org/?lat=46.1631804&lon=-89.0104308&zoom=16 Nodes tagged waterway=river http://www.openstreetmap.org/?lat=46.2965&lon=-86.1032&zoom=14 Unconnected streams / rivers http://www.openstreetmap.org/?lat=46.723&lon=-88.568&zoom=14 Ten thousands of omported single trees in Europe http://www.openstreetmap.org/?lat=41.98688&lon=2.81672&zoom=17&layers=M WernerP ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Excellent progress, u.s.
At 2012-04-16 20:41, Toby Murray wrote: On Mon, Apr 16, 2012 at 8:37 PM, Nathan Edgars II wrote: > On 4/16/2012 9:18 PM, Alan Mintz wrote: >> At 2012-04-16 14:06, Nathan Edgars II wrote: >>> Or you can simply add odbl=clean if there's nothing ungood about the >>> object (e.g. it was split from a TIGER way and the splitting is >>> something you would have done anyway). >> Is this really sufficient? Can someone from the redaction squad comment? >> Can I protect/"bless" a way or node and prevent its redaction simply by >> (in good faith) adding this tag? > We have no idea what rules the OSMF will use. Well I won't claim that communication has been great but this statement is a little over dramatic. First of all: odbl=clean *will* be honored. ... On nodes as well as ways? As I wrote earlier, if I have tagged a way with a source that includes imagery, and removed the tiger:reviewed=no tag, it means I have aligned it to that imagery, including leaving nodes that are in the correct place alone (sometimes). Can I bless the nodes in the same way? Also there is this: http://wiki.openstreetmap.org/wiki/Open_Data_License/What_is_clean%3F A nice empty page. Tough to argue with :) And of course the code is available for anyone to view... although I'm not going to claim that this is really good documentation on the matter: https://github.com/zerebubuth/openstreetmap-license-change Nor can you reasonably expect people to use this as a guideline. And I'm a programmer. There has been talk of the "v0 rule" which I believe is being implemented in the code. This means that the act of creating an object by a decliner doesn't automatically make it dirty. So if a way was created by a decliner with the tag name=Fred and then someone else added the tag highway=footway then after the bot gets done with it, the way will still exist but only have the highway=footway tag. If an accepting user changes the value of the name=* tag then it will be clean... except, see the next paragraph. However if all of the way's nodes are dirty and get removed then the way itself will have to go too since you can't have a zero-node way. I contend, though, that you should not have to change a node to make it clean. If one has tagged a source with an imagery (or GPS) value, they are saying that they vouch for the position of the way, including its nodes. Same applies to removing tiger:reviewed=no (or gnis:reviewed=no). The user is specifically claiming to have reviewed the position and tagging and approved it. Should that not be sufficient? Unfortunately neither badmap nor OSMI fully implement all of these rules so yes there is still far too much uncertainty. But there are some facts to be had. Why, then, is it acceptable for us to be sitting here with a dagger hanging over our heads, uncertain as to when and how it will fall? Shouldn't all of this be nailed down, followed by a reasonable notice period? Why is there a deadline other than "we need to get it done for the long-term benefit of OSM?" -- Alan Mintz ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
