[Talk-us] Removing tiger:* tags

[Nathan Edgars II]

On Fri, Jul 30, 2010 at 8:28 PM, andrzej zaborowski <balrogg at gmail.com> wrote:
> On 31 July 2010 02:24, Nathan Edgars II <neroute2 at gmail.com> wrote:
>> On Fri, Jul 30, 2010 at 8:11 PM, andrzej zaborowski <balrogg at gmail.com> wrote:
>>> On 31 July 2010 00:50, Nathan Edgars II <neroute2 at gmail.com> wrote:
>>>> On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski <balrogg at gmail.com> wrote:
>>>>> Also note that once there's a photo on flickr that is tagged with an
>>>>> osm object id and a foursquare.com venue id at the same time, you have
>>>>> a link between OSM and foursquare.com, no need to duplicate this
>>>>> information in either of these databases.  If that osm object contains
>>>>> a tiger tlid, you can tie the foursquare.com venue to a tiger record
>>>>> and so on.
>>>>
>>>> Serious question: why would anyone want to do this? (putting aside the
>>>> fact that foursquare is probably not for streets) Does the TLID have
>>>> any significance outside TIGER?
>>>
>>> Various use cases I can see right now, and there are more.
>>>  * You may just want to display a link to the osm object or tiger
>>> object on a flickr photo page (flickr already does it for photos
>>> tagged with osm:<node|way|relation>= ), the service may even
>>> automatically extract metadata from either of the databases, like
>>> "this is a building", "this is a road", so even the computer can know
>>> what exactly is on the photo, no need to analyse the picture.  Google
>>> could use it to enhance picture search etc.  OSM gives you some
>>> information on the object, TIGER gives you other type of information
>>> (official classification, weird area codes etc), another database
>>> (like foursquare.com? not sure) can tell you the capacity of a bar and
>>> maybe even price level for a restaurant that's a node in OSM.
>>>  * knowing which direction the camera looked, you can actually overlay
>>> the road geometry on it, make it clickable etc., same way Google
>>> Street View shows 3d lines for roads on the panoramas.
>>>  * knowing that road A in TIGER crosses roads B, C and D, you can do
>>> sanity checks if the same ways cross each other in OSM, that may be
>>> helpful both to the tiger maintainers and to OSM.  Same way you can
>>> check if a junction has the right number of roads meeting there.
>>>  * you can provide routing in one area using map A, and seemlessly
>>> switch to map B when you cross some border and based on some other
>>> critera.  In effect you can generate a single route using multiple
>>> maps, you can mix and match in any ways you like.
>>
>> I don't think you understand how the TLIDs are stored in OSM. They
>> were never one TLID per way; the initial import joined a bunch of
>> adjacent ways and concatenated the TLIDs.
>
> I don't see how it changes anything.  If a piece of interstate I-405
> is described by one relation or two ways one for each carriage in osm,
> and 10 segments in TIGER, than that's a way to describe it.

So how would you do any of the applications described above? They all
require either a single TLID or everything to be tagged with a field
that includes the correct TLID (due to joining, splitting, and
redrawing, the latter is not true).