[Talk-us] TIGER edited map updated with Toby's suggestion

andrzej zaborowski balrogg at gmail.com
Tue Jan 25 02:12:13 GMT 2011


On 25 January 2011 02:54, Alan Mintz <Alan_Mintz+OSM at earthlink.net> wrote:
> At 2011-01-24 16:55, andrzej zaborowski wrote:
>>
>> On 25 January 2011 00:57, Alan Mintz <Alan_Mintz+OSM at earthlink.net> wrote:
>> > At 2011-01-24 15:37, Toby Murray wrote:
>> >>
>> >> On Mon, Jan 24, 2011 at 5:18 PM, Andrew Ayre <andy at 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



More information about the Talk-us mailing list