Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 12:24 AM, Alan Millar amillar...@gmail.com wrote: I haven't seen a conclusion on what people want to see in the naming convention (see for example the thread at http://lists.openstreetmap.org/pipermail/talk-us/2010-April/003138.html). Just because the conversation is ongoing, that doesn't mean you need to delete the data in the meantime. No, I don't need to, and I generally only do so when I'm otherwise editing the ways anyway. I've explained my reasons, and I haven't heard anything to change my mind about them. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
At 2010-07-30 07:28, Anthony wrote: On Fri, Jul 30, 2010 at 12:24 AM, Alan Millar amillar...@gmail.com wrote: I haven't seen a conclusion on what people want to see in the naming convention (see for example the thread at http://lists.openstreetmap.org/pipermail/talk-us/2010-April/003138.html). Just because the conversation is ongoing, that doesn't mean you need to delete the data in the meantime. No, I don't need to, and I generally only do so when I'm otherwise editing the ways anyway. I've explained my reasons, and I haven't heard anything to change my mind about them. [ This is long. Sorry. ] I really don't understand your argument. It's the nature of OSM that many people will contribute many types of data, much of which will not be cared about or understood by the majority of consumers. What's wrong with that, and why do you think removing it because you don't understand or like it is acceptable behavior in a crowd-sourced environment? The only reason that makes sense might be it's wrong. In the case of tiger:*, it's not wrong. It's in its own namespace because it indicates the value as it was in another database at the time of import. Not that I believe we need to justify it, but the three (at least) of us arguing to keep the tags in this thread, each for reasons that we've described, should be sufficient to prove that someone needs the data, and you really have no right to stomp on our work, or data that we need for our work. Also, we're not alone - many people recognized the need to fix the way names are stored. Having to go back to history will be adding an order of magnitude to the complexity of that. Have a look at tagwatch and you'll see that tiger:* is just one of many such import namespaces, most of which you are not likely to care about, whether they are doc'd or not. There's another, very important use for the tiger:reviewed tag. It was designed to let you know what ways need to be satellite- or GPS-aligned, since the original data was very poorly aligned. Having these render differently in JOSM is an important workflow tool. After I'm done aligning, I remove that tag, as documented in the wiki. When I've surveyed it in real life, I add source and source_ref tags to cite my source. BTW, someone started stomping on those as well because they saw no need for my picture #s[0], but after discussing it, was convinced to leave them alone. Someone asked a ways back whether the tiger:* tags could be combined into a single value, which leads me to think that there is a hidden reason that at least two people don't want these. Does it have something to do with the editing tools being used? In JOSM, the tags appear in alpha order, which ends up placing them almost always below any of the commonly edited tags. Is the real problem that other editors aren't doing this, resulting in clutter in the editing process? Can't we just solve this in editors, maybe by placing the common import namespaces last in sort order? FWIW, the only time I intentionally *remove* data is when I'm certain (or as close as possible to certain) that it is wrong, almost always replacing it with my own correct data. I believe this is one of the fundamental principles of the community, and would hope that others adhere to it. One recent exception is that, over a large chunk of southern California, a user had entered maxspeed values that were incorrectly converted from mph to kph using a wrong, and sometimes unpredictable, factor. I've moved the ones that I know to be wrong (because they are not integral multiples of 5 mph, are inconsistent with the road type, and were edited by this user) to bad_maxspeed=*. When adding the correct maxspeed from my own survey, I then remove the bad_maxspeed tag. Unfortunately, some remain with maxspeed=40, for which it is not possible to determine accuracy in all cases, but that's not a reason to remove them until I have proof. BTW, the same user also can't spell (English/American/Spanish names mostly), and I've spent a fair amount of time having to research and correct those, too. I don't wipe them out just because I think they're likely wrong, though, until I research them. Notes: [0] Those source_ref=AM909_* values in source_ref are links to the pics I have of the names of the streets. There are other source_ref:*=* values for other attributes that are proved by pics. At some point, they could be links to an online repository of these pics, given interest, and some post-processing to remove faces and license plates. Right now, they allow me to look back at partial surveys of attributes (like speed limits) and combine them with newer surveying to form a complete picture, and are an important part of my workflow. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 2:24 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: There's another, very important use for the tiger:reviewed tag. As I've said above, that's the one tiger tag I don't remove (until I've reviewed the way, of course). You don't seem to have read that message. In it I went through each of the tiger tags individually and explained what was wrong with them. The tiger:tlid key in particular is in horrible shape, to the point where I guess at least 95% of them *are* wrong. Basically, the only tag I can imagine worth keeping would be the name_type, name_base, name_* ones, and those should be removed from the tiger:* namespace. But really before that can be done a standard should be decided on about how to store the names. Once that is done, I'll gladly produce a script to re-add all the name_base/name_types that I've deleted. Anyway, I hear what you're saying about removing things added by others, but when you fill the database with millions upon millions of entries with no apparent usefulness, I think part of the burden is on you to justify why they should stay. TIGER was great for filling up what was a nearly blank map. But gradually we should be moving beyond TIGER. Hopefully one day there will be no TIGER data left. That should be the goal. So I guess we're at an impasse. Because your message above hasn't provided me any new information. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Thu, Jul 29, 2010 at 4:11 PM, Dave Hansen d...@sr71.net wrote: So, the guys that actually went out and were nice enough to collect this TIGER data and share it with us have names for all these things: TLIDs. That's a pretty concrete, real-world meaning to some people. Not in osm context. DB id from an external DB are useless in osm. any can edit them. ways are merged and split over time many of them don't reflect any link to the tiger tlid anymore. it's just filling the planet files. I't is nice to have such a reference on the initial import but there is no use to keep them after edits. If we had changesets at the time it was imported then this is the place to add these tags. there they are readonly and don't fill the planet with useless info ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
Just for that short little bridge? This info should be right (which means *one* tlid) or it shouldn't be there at all. We shouldn't keep this crap around just for the hell of it. By deleting it you're not making it more correct. Never said I was. But deleting incorrect information is better than leaving it around, even if it isn't as good as correcting it. full ack How would I even go about checking? Is this really something we should be doing every time we make a bridge? what a waste of time, let's go mapping instead. this is a wast of time I think we should enhance Josm/Potlatch to remove these tags in the same way as it is done for created_by ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 11:24 AM, Alan Mintz alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net wrote: I really don't understand your argument. It's the nature of OSM that many people will contribute many types of data, much of which will not be cared about or understood by the majority of consumers. What's wrong with that, and why do you think removing it because you don't understand or like it is acceptable behavior in a crowd-sourced environment? importing is not crowd-sourced! we should apply different rules here. what is wrong normally might be a very good thing for imports and the other way round The only reason that makes sense might be it's wrong. In the case of tiger:*, it's not wrong. It's in its own namespace because it indicates the value as it was in another database at the time of import. Not that I believe we need to justify it, but the three (at least) of us arguing to keep the tags in this thread, each for reasons that we've described, should be sufficient to prove that someone needs the data, and you really have no right to stomp on our work, or data that we need for our work. Also, we're not alone - many people recognized the need to fix the way names are stored. Having to go back to history will be adding an order of magnitude to the complexity of that. if you need them use a native tiger DB, working through history is such a pain that it doesn't make sense. GIS experts will know how to do this and can easily compare osm data with another DB. Have a look at tagwatch and you'll see that tiger:* is just one of many such import namespaces, most of which you are not likely to care about, whether they are doc'd or not. other trash doesn't make these tags more useful. We have all learned from early imports and since then changesets have been added to the API0.6 tiger import was done before and we can't blame anyone. but now we can do it better and fix old mistakes ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
At 2010-07-30 12:56, Apollinaris Schoell wrote: How would I even go about checking? Is this really something we should be doing every time we make a bridge? what a waste of time, let's go mapping instead. this is a wast of time I think we should enhance Josm/Potlatch to remove these tags in the same way as it is done for created_by Hopefully, you were talking about this specific case only, and not all tiger:*=* tags? Even still, matching the chain of TLIDs to the ways on either side may still prove to be useful at some point. Do we really need the database space that badly? Shouldn't an analysis be done to understand just how much space that is, what the server load will be, how much it expands the history, etc., as was done with the justified removal of tags from the nodes? -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 1:12 PM, Alan Mintz alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net wrote: At 2010-07-30 12:56, Apollinaris Schoell wrote: How would I even go about checking? Is this really something we should be doing every time we make a bridge? what a waste of time, let's go mapping instead. this is a wast of time I think we should enhance Josm/Potlatch to remove these tags in the same way as it is done for created_by Hopefully, you were talking about this specific case only, and not all tiger:*=* tags? Even still, matching the chain of TLIDs to the ways on either side may still prove to be useful at some point. Do we really need the database space that badly? Shouldn't an analysis be done to understand just how much space that is, what the server load will be, how much it expands the history, etc., as was done with the justified removal of tags from the nodes? personally I think all of them. there is no value after editing. usually I keep tlid, zipcode, county, name_type even that this isn't very useful there can be still some use if an application doen't yet use county polygons or there is no info about zipcode otherwise in osm longterm even these should go away. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 30 July 2010 21:00, Anthony o...@inbox.org wrote: On Fri, Jul 30, 2010 at 2:24 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: There's another, very important use for the tiger:reviewed tag. As I've said above, that's the one tiger tag I don't remove (until I've reviewed the way, of course). You don't seem to have read that message. In it I went through each of the tiger tags individually and explained what was wrong with them. The tiger:tlid key in particular is in horrible shape, to the point where I guess at least 95% of them *are* wrong. How do you come to that figure? My guess would be that 95% are right. The only objects that may contain a TLID that refers to a different real life object and don't contain a TLID that refers to the actual object can be those that (a) underwent very heavy surgery (not simple splitting or joining, but exchanging tags and geometry with another object for example) or (b) were fictitious and shouldn't have been in tiger in the first place. Most objects have not been touched at all, out of those which have been touched by a mapper, most have been changed using common sense to find the shortest path to make the object correct (e.g. change street's name tag and leave geometry mostly alone or change geometry and leave the name alone, splitting, joining, etc) Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 30 July 2010 22:12, Alan Mintz alan_mintz+...@earthlink.net wrote: Do we really need the database space that badly? I've heard arguments on the talk list that this clutters the database and similarly wikipedia= tags should be massively removed and if at all, links should be maintained then in the wikipedia database *to* our objects rather in our database to wikipedia pages. This just sounds like passing on the hot potato. Even if osm comes to be a point where references to ten different databases are kept for objects, it's still valuable information, and I personally don't see how it's inconvenient. If it hurts your eyes how the name= and highway= tags are lost among the other tags in your favourite editor, then perhaps modify the editor. Keep the links in whatever database it makes most sense, for example wikipedia pages are indexed by their title, which is a pretty stable reference, as opposed to OSM id's, that's why it make more sense to keep them here. TIGER data we can't edit, that's why it makes more sense to keep the id's here. Flickr (if treated as a big database where each photo is a record) had the balls to store references to osm objects, as well as dopplr.com IDs and foursquare.com venue IDs in their machine tags for each picture that is a photograph of a given object. There was no fear of cluttering their machine tags space. Why would it be an issue in osm? 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. I'm not asking anyone to go adding these tags, but just saying that they don't hurt, even if they're just a hint (a bridge that contains twenty TLIDs and perhaps only one of them is the right one). Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@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? I'm not asking anyone to go adding these tags, but just saying that they don't hurt, even if they're just a hint (a bridge that contains twenty TLIDs and perhaps only one of them is the right one). What about a bridge that contains forty TLIDs and none is the right one because the right one was the fiftieth and that many TLIDs wouldn't fit in the maximum field size (255 characters, I believe)? The way I see it is that if I were mapping an area from scratch, nobody would go adding the TIGER tags. So if I completely redo an area, whether I use existing ways or draw new ways, there's no reason to keep the TIGER tags. If anyone objects, I can change my workflow to delete the old ways and create new ways rather than redrawing the old ways :) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 5:50 PM, Nathan Edgars II nerou...@gmail.comwrote: The way I see it is that if I were mapping an area from scratch, nobody would go adding the TIGER tags. So if I completely redo an area, whether I use existing ways or draw new ways, there's no reason to keep the TIGER tags. If anyone objects, I can change my workflow to delete the old ways and create new ways rather than redrawing the old ways :) I concur with this. My workflow involves removing TIGER data when I move a node/way using gps traces or satellite imagery. I saw no value in keeping this data. I believe I brought this topic up a while ago and no one ever really gave me a good reason not to do this. If anyone does object, I will delete the old way and draw a new one as Nathan stated as well, I just find more value in moving the ways because a history on the way will show that it originated from a TIGER Import, but no longer references to it because it is in fact, not that way anymore. I really see no need to reference it anymore. I do not however, go deleting TIGER tags off ways I do not touch. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 00:50, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@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. Wikipedia page on Linked Data has more on this, there are endless possibilities. I'm not asking anyone to go adding these tags, but just saying that they don't hurt, even if they're just a hint (a bridge that contains twenty TLIDs and perhaps only one of them is the right one). What about a bridge that contains forty TLIDs and none is the right one because the right one was the fiftieth and that many TLIDs wouldn't fit in the maximum field size (255 characters, I believe)? The way I see it is that if I were mapping an area from scratch, nobody would go adding the TIGER tags. So if I completely redo an area, whether I use existing ways or draw new ways, there's no reason to keep the TIGER tags. If anyone objects, I can change my workflow to delete the old ways and create new ways rather than redrawing the old ways :) What I mean is keep the tags if it doesn't cost you anything. If it would impact your mapping effiency then perhaps it make more sense to skip them, it's a tradeoff. However when you map an area from scratch, what metadata do you add? Perhaps highway= classes and name=, all other other information are pretty boring to survey and it's easier to just copy them over from the tiger ways you delete. I just use ctrl+c + ctrl+shift+v, this copies all the tags in JOSM, and you can then modify the values if anything is wrong in that data. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 8:11 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 00:50, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@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. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 02:24, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:11 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 00:50, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@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. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 8:28 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 02:24, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:11 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 00:50, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 6:36 PM, andrzej zaborowski balr...@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). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 02:33, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:28 PM, andrzej zaborowski balr...@gmail.com wrote: 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). So your program tries to come up with a route, it knows it's driving on road A in osm. A has id=1 and is tagged tiger:tlid=20:21:22:23, and it is connected to road B (id=2, tiger:tlid=24:25:26:27) by node id=3. You also see that tiger way 23 meets 24. That clearly means that from osm road A you can go into tiger way 24 when you reach node id=3, without even looking at the geometry and fuzzy guessing things (remember routing works on huge graphs). Or say that the government releases a database that says how many traffic signals there are on each segment of road. Then you can find the junction nodes on which they should be in OSM, or at least count how many there should be on a given street. And yes, street names are not 100% correct or complete in OSM today.. we don't remove them though. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 03:02, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:44 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 02:33, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 8:28 PM, andrzej zaborowski balr...@gmail.com wrote: 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). So your program tries to come up with a route, it knows it's driving on road A in osm. A has id=1 and is tagged tiger:tlid=20:21:22:23, and it is connected to road B (id=2, tiger:tlid=24:25:26:27) by node id=3. You also see that tiger way 23 meets 24. That clearly means that from osm road A you can go into tiger way 24 when you reach node id=3, without even looking at the geometry and fuzzy guessing things (remember routing works on huge graphs). But road A has been rerouted since the TIGER data was created and now ends at road C, without touching road B. You can't use shortcuts like this. Sure it can be outdated same as any other tag value. Or am I misunderstanding your example? If you already know A and B are joined at node 3, what do the TLIDs tell you? The TLIDs tell you you where you are if you want to switch from OSM routing to TIGER routing at that node for example. And they tell you road A in TIGER has (say) 4 crossings with other roads, so if that's not true in OSM, you know one of the maps needs fixing. If something changes between TIGER2006 and TIGER2009 you can see which osm segments may need fixing too. Or say that the government releases a database that says how many traffic signals there are on each segment of road. Then you can find the junction nodes on which they should be in OSM, or at least count how many there should be on a given street. TLID 24 has two lights and TLID 25 has three. Joined TLID 24;25 might have four or five. Well.. sure, possible, but that's assuming that the database was made in such unfortunate way that each single lights can be counted two or more times. The census data tends to not be that bad (at least in the design) Add one to the possible error for each new segment. Then split out bridges and it becomes unmanageable. Again note about bad data in osm.. Plus if your program sees a non-bridge segment with tiger:tlid=20:21:23 and a next (bridge) segment with the same tiger:tlid, it should really notice that the five traffic lights are somewhere on those two segments, not five on each. And yes, street names are not 100% correct or complete in OSM today.. we don't remove them though. So are you saying you or someone else will be checking all TLIDs against the TIGER data and correcting errors and adding missing ones? So people in Germany are mapping curb heights for streets. There's the openpistemap and special tagging for ski piste types. There's a whole spectrum of informations with different numbers of people who care about it, and it changes in time. (specially when a visualisation becomes available.. who cared about dupe nodes before the dupe nodes map?) Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
So are you saying you or someone else will be checking all TLIDs against the TIGER data and correcting errors and adding missing ones? I can imagine someone making some clever scripts and then manually verifying it where there are doubts as a kind of personal project of the week or something. A couple of months ago Marcus Wolschon has been reporting on the general talk list on his progress in adding the TMC road IDs to OSM in some parts of Germany or Austria. TMC is some kind of radio broadcast current traffic amount estimates, some satnavs can use it to avoid traffic jams automatically. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 9:40 PM, andrzej zaborowski balr...@gmail.com wrote: So are you saying you or someone else will be checking all TLIDs against the TIGER data and correcting errors and adding missing ones? I can imagine someone making some clever scripts and then manually verifying it where there are doubts as a kind of personal project of the week or something. A couple of months ago Marcus Wolschon has been reporting on the general talk list on his progress in adding the TMC road IDs to OSM in some parts of Germany or Austria. TMC is some kind of radio broadcast current traffic amount estimates, some satnavs can use it to avoid traffic jams automatically. Sounds like a useful ID number to map. Unlike TLIDs. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On 31 July 2010 04:06, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 9:40 PM, andrzej zaborowski balr...@gmail.com wrote: So are you saying you or someone else will be checking all TLIDs against the TIGER data and correcting errors and adding missing ones? I can imagine someone making some clever scripts and then manually verifying it where there are doubts as a kind of personal project of the week or something. A couple of months ago Marcus Wolschon has been reporting on the general talk list on his progress in adding the TMC road IDs to OSM in some parts of Germany or Austria. TMC is some kind of radio broadcast current traffic amount estimates, some satnavs can use it to avoid traffic jams automatically. Sounds like a useful ID number to map. Unlike TLIDs. Internet is a *network* of linked databases [1].. if someone has a TMC to TIGER mapping, you get a TMC to OSM mapping for free. Cheers 1. http://en.wikipedia.org/wiki/File:Lod-datasets_2009-07-14_colored.png (see US Census bubble) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Fri, Jul 30, 2010 at 10:15 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 04:06, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Jul 30, 2010 at 9:40 PM, andrzej zaborowski balr...@gmail.com wrote: I can imagine someone making some clever scripts and then manually verifying it where there are doubts as a kind of personal project of the week or something. A couple of months ago Marcus Wolschon has been reporting on the general talk list on his progress in adding the TMC road IDs to OSM in some parts of Germany or Austria. TMC is some kind of radio broadcast current traffic amount estimates, some satnavs can use it to avoid traffic jams automatically. Sounds like a useful ID number to map. Unlike TLIDs. Internet is a *network* of linked databases [1].. if someone has a TMC to TIGER mapping, you get a TMC to OSM mapping for free. Doesn't look like TMC is tied to ways, let alone the exact ways that TIGER uses: http://en.wikipedia.org/wiki/Traffic_Message_Channel#Criticism Have fun with your useless TLIDs. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
