On 25 January 2011 02:54, Alan Mintz <alan_mintz+...@earthlink.net> wrote: > At 2011-01-24 16:55, andrzej zaborowski wrote: >> >> On 25 January 2011 00:57, Alan Mintz <alan_mintz+...@earthlink.net> wrote: >> > At 2011-01-24 15:37, Toby Murray wrote: >> >> >> >> On Mon, Jan 24, 2011 at 5:18 PM, Andrew Ayre <a...@britishideas.com> >> >> wrote: >> >> > Sorry, the village of Summerhaven, which I totally reworked in Sep >> >> > 2009 >> >> > is >> >> > still shown in red: >> >> > >> >> > >> >> > >> >> > http://open.mapquestapi.com/tigerviewer/index.html?zoom=12&lat=32.438&lon=-110.75635&layers=B >> >> >> >> I haven't checked every way in the area but it looks like most of >> >> these aren't TIGER roads to begin with. You created them  (version 1) >> >> then balrog-kun renamed expanded all the street name abbreviations >> >> (version 2) so they are in version 2 and last touched by balrog-kun >> >> which is why they are being rendered as red. The TIGER edited map >> >> isn't really intended for these ways since they aren't originally >> >> TIGER data. >> >> >> >> I guess it would be nice to turn ways that weren't imported from TIGER >> >> green, regardless of last editor and version number. But only the >> >> current version of the way is available for inspection while rendering >> >> so this is kind of hard to do... >> > >> > Only objects with tiger:* tags should be candidates for being red. I'd >> > suggest looking for the tiger:county or tiger:name_base tags, since some >> > have removed other tiger:* tags but left ones like tiger:cfcc or >> > tiger:zip_* >> > for reference. >> > >> > However, I find another problem. When I split a TIGER-imported way and >> > keep >> > the tiger:* tags on it, I end up with what looks like a TIGER way, but >> > isn't. It has tiger:*=* and v=1 (or v=2 if I edited it again). However, >> > the >> > UID is mine, not balrog-kun or DaveHansenTiger, so filtering for this >> > would >> > solve the problem as well. >> > >> > In summary, I propose to add the following requirements to the existing >> > filter for turning a feature red: >> > - Must have tiger:name_base tag >> >> I'd suggest tiger:reviewed=no which is kind of what the tag was for. > > ...except that some (many?) people don't know (or don't care) to remove the > tag after they edit/confirm the feature. There are many edited TIGER ways > out there with this tag.
Right, but at this point we just want to determine if the way comes from TIGER... so if either tiger:reviewed=no or tiger:base_name *is* set, it's an indication that it may be from TIGER. I can imagine someone adding a tiger:base_name to a non-TIGER name for consistency, but I can't imagine someone reasonably adding tiger:reviewed=no. > > >> Also I (balrog-kun) have edited a good amount of data manually, from >> survey or imagery, at the same time there are a portion of roads where >> I changed the name twice, generating v=2 and then v=3 because after >> the first run I found that some more patterns needed manual review >> because it was impossible to automatically Do The Right Thing in more >> situations than expected. On the TIGER scale they're both small >> groups though. >> >> It's a pity that the full history dump can't be used easily because >> that's often the assumption when processing OSM data and it's often >> recommended on the mailing lists to use changeset tags instead of tags >> on features. You could for example filter out changesets with bot=yes >> which would skip all of my road name expanding and possibly more stuff >> skewing the results. > > How about changing: > - UID must be balrog_kun or DaveHansenTiger > to: > - (UID=balrog_kun and changeset in list_of_changesets) or > UID=DaveHansenTiger > > where list_of_changesets is the list of changeset IDs that were used for the > name expansion. That would work I guess but still not for 100% cases, so I think the difference isn't worth the effort. Cheers _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us