Re: [Talk-us] Removing tiger:* tags
On Sat, 07 Aug 2010 17:55:17 -0700, Alan Mintz wrote: If it's fatiguing for you, I'll accept that, even though I don't see that myself when using Potlatch or JOSM. Let's modify whatever editor you use to hide those tags for you if you want. OK, fix JOSM then. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Thu, 29 Jul 2010 15:52:31 -0700, Dave Hansen wrote: Please keep them. They're not hurting anything. Mapper fatigue. I don't really see how anything beyond tiger:reviewed=no and tiger:tlid= tags are useful at this point, save to make tags more difficult to sift through by human editors. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
At the risk of being accused of letting a good argument die... At 2010-08-07 13:28, Paul Johnson wrote: On Thu, 29 Jul 2010 15:52:31 -0700, Dave Hansen wrote: Please keep them. They're not hurting anything. Mapper fatigue. I don't really see how anything beyond tiger:reviewed=no and tiger:tlid= tags are useful at this point, save to make tags more difficult to sift through by human editors. Except that a number of people have made cases for wanting to have this data remain, at least for now. It is not in the spirit of the project to step on data that others create and/or want, regardless of whether you agree with their need or not, unless it is dead wrong and misleading. TIGER:* (and many other import something:*) tags are in their own namespace to make it clear that they are the raw values from an import. Until those values serve no purpose to anyone (and a few have said that they still do), they should remain. If it's fatiguing for you, I'll accept that, even though I don't see that myself when using Potlatch or JOSM. Let's modify whatever editor you use to hide those tags for you if you want. I am also seeing instances of gnis:* tags getting removed in the process of creating closed ways for those features, instead of those tags being copied to the new closed ways. -- 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, 2010-07-30 at 15:00 -0400, Anthony wrote: 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. Good luck on this idea. This is the fourth time that it has been brought up since I've been on this mailing list (less than a year). There is much discussion but no decision is made. The topic gets dropped, then the topic comes up a few months later. - Val - ___ 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:25 PM, andrzej zaborowski balr...@gmail.com wrote: On 31 July 2010 03:02, Nathan Edgars II nerou...@gmail.com wrote: 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. The difference is that no one is keeping it up to date. ___ 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 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
Re: [Talk-us] Removing tiger:* tags
As a general concept this is bad but in many cases a very good idea. many tiger roads are completely wrong and there is absolute no value to keep any of the tags. if a mapper does a significant change and is essentially just keeping some nodes and the name tag then it's better to remove any reference to a bad source. a lot of tags for tiger uploads have no benefit and can be removed too without loosing any valuable info. examples are tiger:source tiger:upload_uuid and probably also tiger:separated tiger:county, with county borders available this is no longer useful On Thu, Jul 29, 2010 at 10:12 AM, Alan Mintz alan_mintz+...@earthlink.netalan_mintz%2b...@earthlink.net wrote: A couple of different users have recently been removing all the tiger:*=* tags from roads in the process of other edits to them. One responded that it was because they were sometimes wrong (which is, of course, true, for those roads that we've corrected) and that they did not seem to provide any useful data. However, they also contain the original breakdown of the prefix, root, and suffix before they got combined into the name and then expanded by the balrog-kun bot - information which will be useful in the majority of cases if we ever get back to splitting/standardizing. AFAIK, we haven't (yet) agreed that these tags should be removed, right? -- 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 29 July 2010 19:12, Alan Mintz alan_mintz+...@earthlink.net wrote: One responded that it was because they were sometimes wrong (which is, of course, true, for those roads that we've corrected) and that they did not seem to provide any useful data. However, they also contain the original breakdown of the prefix, root, and suffix before they got combined into the name and then expanded by the balrog-kun bot - information which will be useful in the majority of cases if we ever get back to splitting/standardizing. The only tiger tag that is important to keep (to me) is the tiger:tlid, all the other values can be pulled from the original TIGER database provided the TLID. I can also see the argument for keeping the name segments as they are now largely used as generic tags, in the absence of some agreed non tiger: -prefixed tags. For the record I (balrog-kun) removed the tiger:upload_uuid on any ways that I touched back when I was expanding the names. This tag has no value whatsoever now that API 0.6 supports changesets (and even without it), but other ways still have the upload_uuid. The uuid is a quite long, random string so it occupied a very big part of the planet snapshots and made it very hard to for example build a search index of all the tag values including substrings (for example using suffix trees). I would recommend that sequential, integer ids are always used in databases like OSM, instead of UUIDs. Cheers ___ 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 1:12 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: A couple of different users have recently been removing all the tiger:*=* tags from roads in the process of other edits to them. I'm among them. Mostly because they are not documented in the wiki. However, they also contain the original breakdown of the prefix, root, and suffix before they got combined into the name and then expanded by the balrog-kun bot - information which will be useful in the majority of cases if we ever get back to splitting/standardizing. If you want to do that, just go back to the original database. AFAIK, we haven't (yet) agreed that these tags should be removed, right? Dunno. ___ 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 3:33 PM, andrzej zaborowski balr...@gmail.com wrote: The only tiger tag that is important to keep (to me) is the tiger:tlid, all the other values can be pulled from the original TIGER database provided the TLID. Unfortunately, that's also one of the hardest ones to keep, because it doesn't have any real world meaning. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Thu, 2010-07-29 at 18:44 -0400, Anthony wrote: On Thu, Jul 29, 2010 at 1:12 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: A couple of different users have recently been removing all the tiger:*=* tags from roads in the process of other edits to them. I'm among them. Mostly because they are not documented in the wiki. Heh. OK, let's go deleting all of the tags that don't show up in the wiki. That should pretty significantly reduce the size of the database. :) However, they also contain the original breakdown of the prefix, root, and suffix before they got combined into the name and then expanded by the balrog-kun bot - information which will be useful in the majority of cases if we ever get back to splitting/standardizing. If you want to do that, just go back to the original database. Sometimes, since people removed things and moved them around, it's very difficult to _go_ back to the original database. Every one of these tags make that more feasible. AFAIK, we haven't (yet) agreed that these tags should be removed, right? Dunno. Please keep them. They're not hurting anything. -- Dave ___ 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 6:52 PM, Dave Hansen d...@sr71.net wrote: On Thu, 2010-07-29 at 18:44 -0400, Anthony wrote: On Thu, Jul 29, 2010 at 1:12 PM, Alan Mintz alan_mintz+...@earthlink.net wrote: A couple of different users have recently been removing all the tiger:*=* tags from roads in the process of other edits to them. I'm among them. Mostly because they are not documented in the wiki. Heh. OK, let's go deleting all of the tags that don't show up in the wiki. That should pretty significantly reduce the size of the database. :) Will it? I can't think of many that I've run across. However, they also contain the original breakdown of the prefix, root, and suffix before they got combined into the name and then expanded by the balrog-kun bot - information which will be useful in the majority of cases if we ever get back to splitting/standardizing. If you want to do that, just go back to the original database. Sometimes, since people removed things and moved them around, it's very difficult to _go_ back to the original database. Every one of these tags make that more feasible. Just look in the history for when the way was originally added. AFAIK, we haven't (yet) agreed that these tags should be removed, right? Dunno. Please keep them. They're not hurting anything. Please define them in the wiki, and I'll keep them. Unless I have a definition, I have no way of determining if they're correct or not. Furthermore, don't store redundant data in the OSM database. There's absolutely no excuse for having 200 ways which all say name=Cain Rd, name_base=Cain, name_type=Rd. It's absolutely terrible design. So come up with a better design, define it in the wiki, and I'll keep it. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Thu, 2010-07-29 at 18:58 -0400, Anthony wrote: However, they also contain the original breakdown of the prefix, root, and suffix before they got combined into the name and then expanded by the balrog-kun bot - information which will be useful in the majority of cases if we ever get back to splitting/standardizing. If you want to do that, just go back to the original database. Sometimes, since people removed things and moved them around, it's very difficult to _go_ back to the original database. Every one of these tags make that more feasible. Just look in the history for when the way was originally added. With way combination and splitting, _this_ isn't feasible, either. TIGER didn't have any bridges, and so doing this for a road with bridges since inserted can be a real pain. AFAIK, we haven't (yet) agreed that these tags should be removed, right? Dunno. Please keep them. They're not hurting anything. Please define them in the wiki, and I'll keep them. Unless I have a definition, I have no way of determining if they're correct or not. They're defined very precisely in the ruby code that imported them. That's publicly available in SVN. If someone is interested in sticking them on the wiki, I'll be happy to point you to it. Furthermore, don't store redundant data in the OSM database. There's absolutely no excuse for having 200 ways which all say name=Cain Rd, name_base=Cain, name_type=Rd. It's absolutely terrible design. So come up with a better design, define it in the wiki, and I'll keep it. Heh. I actually like the concept of separating out the different parts of the name. I think that's a nice design on the part of the TIGER folks. OSM itself is designed around the single name concept, and I believe that these help bridge the gap. We can't change the design now. It got imported, what, 3 years ago? I guess we could have a robot crawl them like we did the node tags, but what's the gain? -- Dave ___ 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. rant Geez, OSM means lots of different things to different people. Tagging truly is open, and people are encouraged to add tags that help _them_, not that the rest of the rest of the world agrees on and loves. Leave the hard work of the people that laid the groundwork before you *alone*. Go map. Please. /rant is there any way that all these tiger tags can be grouped into a mass tiger tag? somewhat like the relations tag which itself contains more tags? ___ 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 7:06 PM, Dave Hansen d...@sr71.net wrote: On Thu, 2010-07-29 at 18:58 -0400, Anthony wrote: Just look in the history for when the way was originally added. With way combination and splitting, _this_ isn't feasible, either. TIGER didn't have any bridges, and so doing this for a road with bridges since inserted can be a real pain. What is the tlid supposed to be for an added bridge? It doesn't make any sense. The tlid is an internal TIGER id. Way combination and splitting is exactly the reason I've chosen *not* to keep tlids. Because tlids don't make any sense once you start changing the ways from the original data. They're defined very precisely in the ruby code that imported them. That's publicly available in SVN. If someone is interested in sticking them on the wiki, I'll be happy to point you to it. Yeah, put in the wiki how the tags represent objective information about the world we're mapping, and I'll be happy to keep them in OSM. Furthermore, don't store redundant data in the OSM database. There's absolutely no excuse for having 200 ways which all say name=Cain Rd, name_base=Cain, name_type=Rd. It's absolutely terrible design. So come up with a better design, define it in the wiki, and I'll keep it. Heh. I actually like the concept of separating out the different parts of the name. I think that's a nice design on the part of the TIGER folks. Me too. But not 200 times for the same name. And not in a special tiger namespace. We can't change the design now. It got imported, what, 3 years ago? I guess we could have a robot crawl them like we did the node tags, but what's the gain? I don't know. I'm not the one who insists on keeping them. If you've got data in OSM which is imported and can never be changed, it shouldn't have been imported in the first place. ___ 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 00:58, Anthony o...@inbox.org wrote: Please define them in the wiki, and I'll keep them. Unless I have a definition, I have no way of determining if they're correct or not. So you're going to delete anything you can't verify? Well good luck. Cheers ___ 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 7:11 PM, Dave Hansen d...@sr71.net wrote: Leave the hard work of the people that laid the groundwork before you *alone*. Let's look at an example of what it means to leave that work alone. http://www.openstreetmap.org/browse/way/44945783 A bridge split from the Florida Turnpike. tiger:tlid = 86486485:86486486:86486387; 86507262:86489492:86507324:86490164:86489590:86489573:86490037:86489467:86490875:86490202:86499582:86497723:86486483:86486384:86486386:86520528:86520529:86489713:86489637:86489612:86489601 24 tlids for a single bridge. Yeah, that's really useful and accurate. ___ 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 7:40 PM, andrzej zaborowski balr...@gmail.com wrote: On 30 July 2010 00:58, Anthony o...@inbox.org wrote: Please define them in the wiki, and I'll keep them. Unless I have a definition, I have no way of determining if they're correct or not. So you're going to delete anything you can't verify? No, only things that are unverifiable. ___ 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 7:49 PM, Alan Millar amillar...@gmail.com wrote: Furthermore, don't store redundant data in the OSM database. There's absolutely no excuse for having 200 ways which all say name=Cain Rd, name_base=Cain, name_type=Rd. It's absolutely terrible design. Patches welcome. Please contribute a fix. I've been fixing it. The fact that Cain Rd has a base of Cain and a type Rd is already in the database over and over and over again. I've been taking out the redundant copies of that information (which should have been in a separate lookup table from the beginning anyway). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
A couple of different users have recently been removing all the tiger:*=* tags from roads in the process of other edits to them. I'm among them. Mostly because they are not documented in the wiki. Better start putting them all back. They are documented in the wiki. http://wiki.openstreetmap.org/wiki/TIGER_to_OSM_Attribute_Map ___ 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 7:55 PM, Anthony o...@inbox.org wrote: On Thu, Jul 29, 2010 at 7:49 PM, Alan Millar amillar...@gmail.com wrote: Furthermore, don't store redundant data in the OSM database. There's absolutely no excuse for having 200 ways which all say name=Cain Rd, name_base=Cain, name_type=Rd. It's absolutely terrible design. Patches welcome. Please contribute a fix. I've been fixing it. The fact that Cain Rd has a base of Cain and a type Rd is already in the database over and over and over again. I've been taking out the redundant copies of that information (which should have been in a separate lookup table from the beginning anyway). I was never a fan of splitting a way, duplicating its tags, for something like a small bridge over a creek It would be great if attributes could be assigned to a number of ways, at least from a normalization standpoint. From a UI standpoint, I don't really know how it would be done, but it could be possible. Modifying all the existing OSM data would be a challenge though. ___ 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 7:41 PM, Anthony o...@inbox.org wrote: On Thu, Jul 29, 2010 at 7:11 PM, Dave Hansen d...@sr71.net wrote: Leave the hard work of the people that laid the groundwork before you *alone*. Let's look at an example of what it means to leave that work alone. http://www.openstreetmap.org/browse/way/44945783 A bridge split from the Florida Turnpike. tiger:tlid = 86486485:86486486:86486387; 86507262:86489492:86507324:86490164:86489590:86489573:86490037:86489467:86490875:86490202:86499582:86497723:86486483:86486384:86486386:86520528:86520529:86489713:86489637:86489612:86489601 24 tlids for a single bridge. Yeah, that's really useful and accurate. Let's look at the other tags: tiger:cfcc = A41; A25 CFCC might be useful. It's described at http://www.proximityone.com/tgrcfcc.htm However, by leaving things alone, it's inaccurate. A25 is Primary road without limited access, US highways, separated. Great. But A41 is Local, neighborhood, and rural road, city street, unseparated. WTF? tiger:county = Sumter, FL Obsolete due to boundary relations. tiger:name_base = Florida's I'm not even sure that's correct. tiger:name_base_1 = State Highway 91 Is it? In my experience these names are wrong as often as they are right. And they should be on ref tags or in relations anyway. The people maintaining the state highways refs in my state have done a much better job than TIGER. Might as well remove the TIGER crap. tiger:name_type = Tpke Doesn't even match the current name. Should I change it to spell it out? Or is this supposed to be saying that the name_type *used to be* Tpke? If it's what it used to be, that should be in the history. If it's what TIGER says, you should check TIGER. tiger:reviewed = no This is actually the only tag I generally leave, if I have not reviewed the road. tiger:separated = no; yes No, yes! Ah, now I get it. tiger:source = tiger_import_dch_v0.6_20070809 tiger:upload_uuid = bulk_upload.pl-178dac49-0bad-45ee-a1bd-085ddec65183 Should be in the changeset. ___ 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 8:09 PM, Alan Millar amillar...@gmail.com wrote: Specifically, RIGHT NOW, you are screwing with my ability to improve mkgmap. Stop deleting them until you provide a better replacement functionality. What is it that you are using this info for in mkgmap? Or is this theoretical? Let me know, and maybe I can help you. ___ 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 8:09 PM, Jim McAndrew j...@loc8.us wrote: It would be great if attributes could be assigned to a number of ways, at least from a normalization standpoint. From a UI standpoint, I don't really know how it would be done, but it could be possible. Modifying all the existing OSM data would be a challenge though. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Street ___ 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 8:04 PM, Mike N. nice...@att.net wrote: Better start putting them all back. They are documented in the wiki. http://wiki.openstreetmap.org/wiki/TIGER_to_OSM_Attribute_Map That's an explanation of how to convert the tiger fields into OSM keys. The only preserved data is: The Tiger Line ID (tlid) as well as the TIGER start and end zero-cell fields, and maybe the raw CFCC should be preserved, just for the hell of it. Oh, okay, just for the hell of it. But as I've shown (http://www.openstreetmap.org/browse/way/44945783) the tlids don't even make sense. tiger:tlid = 86486485:86486486:86486387; 86507262:86489492:86507324:86490164:86489590:86489573:86490037:86489467:86490875:86490202:86499582:86497723:86486483:86486384:86486386:86520528:86520529:86489713:86489637:86489612:86489601? 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. ___ 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 02:26, Anthony o...@inbox.org wrote: But as I've shown (http://www.openstreetmap.org/browse/way/44945783) the tlids don't even make sense. tiger:tlid = 86486485:86486486:86486387; 86507262:86489492:86507324:86490164:86489590:86489573:86490037:86489467:86490875:86490202:86499582:86497723:86486483:86486384:86486386:86520528:86520529:86489713:86489637:86489612:86489601? 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. Probably the bridge just corresponds to one TLID (if you can't be bothered checking which, a good rule is leave it alone for someone to fix), but there are other situations where one way will correspond to two or more TLIDs. Cheers ___ 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 8:30 PM, andrzej zaborowski balr...@gmail.com wrote: On 30 July 2010 02:26, Anthony o...@inbox.org wrote: But as I've shown (http://www.openstreetmap.org/browse/way/44945783) the tlids don't even make sense. tiger:tlid = 86486485:86486486:86486387; 86507262:86489492:86507324:86490164:86489590:86489573:86490037:86489467:86490875:86490202:86499582:86497723:86486483:86486384:86486386:86520528:86520529:86489713:86489637:86489612:86489601? 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. Probably the bridge just corresponds to one TLID (if you can't be bothered checking which, a good rule is leave it alone for someone to fix), but there are other situations where one way will correspond to two or more TLIDs. How would I even go about checking? Is this really something we should be doing every time we make a bridge? Yes, there are situations where one way will correspond to two or more TLIDs. But probably 95% or more of the times I deal with TIGER ways I am splitting ways, not combining them. In any case, I disagree that it's better to leave information you know to be wrong in rather than deleting it. Perhaps that's our fundamental disagreement. If I see something that's wrong, I'd rather delete it than just leave it. If there were a relatively easy way for me to fix then I'd do that, but with tlids I don't know of any remotely easy way to look up the right information. As for tiger:name_base, tiger:name_type, etc., if there's someone that's using that information, we definitely should take it out of the tiger namespace. I'd be happy to move it from tiger:name_base=* to name_base=* instead of deleting it, if someone is using it and would take 5 minutes to put something up on the wiki announcing it. If it's useful, then it's useful for non-tiger ways as well as tiger ways. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Thu, 2010-07-29 at 20:26 -0400, Anthony wrote: But as I've shown (http://www.openstreetmap.org/browse/way/44945783) the tlids don't even make sense. tiger:tlid = 86486485:86486486:86486387; 86507262:86489492:86507324:86490164:86489590:86489573:86490037:86489467:86490875:86490202:86499582:86497723:86486483:86486384:86486386:86520528:86520529:86489713:86489637:86489612:86489601? Just for that short little bridge? In reality, the bridge was probably only a portion of one of those tlids. During the import, we joined all of the neighboring tlids with the same name to form ways. After the import, someone came along and split that way back up to form the bridge. The tlids represent the original set of data from which the bridge might have come. I hope that makes it more clear at least how we got here. -- Dave ___ 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 03:04, Anthony o...@inbox.org wrote: On Thu, Jul 29, 2010 at 8:46 PM, Anthony o...@inbox.org wrote: If the tlids represent the original set of data from which the bridge might have come, then it's best off in the history. And sticking with the theme of creating a general solution rather than maintaining kludgy tiger-specific hacks, maybe we could It's not tiger specific to be specific. If anybody wants to find correspondences between OSM objects and USGS objects and store in the db then I really believe it's useful information. We can't help having many databases on the internet referring to / describing the same real objects, so let's at least order the mess. That's also why it's not best stored in the object's history -- the same osm object may come to describe a different real world object after some edits. Cheers ___ 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 6:51 PM, Anthony o...@inbox.org wrote: On Thu, Jul 29, 2010 at 3:33 PM, andrzej zaborowski balr...@gmail.com wrote: The only tiger tag that is important to keep (to me) is the tiger:tlid, all the other values can be pulled from the original TIGER database provided the TLID. Unfortunately, that's also one of the hardest ones to keep, because it doesn't have any real world meaning. It also sometimes gets truncated when long ways are combined, since the long list of TLIDs becomes longer than the maximum field size. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Removing tiger:* tags
On Jul 29, 2010, at 5:41 PM, Anthony wrote: In any case, I disagree that it's better to leave information you know to be wrong in rather than deleting it. Perhaps that's our fundamental disagreement. For my part in the conversation, I *agree* with you that people should delete (or fix when possible) information that they know is wrong. But that is not the (or my) fundamental disagreement. My disagreement is on the deletion of *all* tiger: tags, because you don't see a need for them or you don't like the namespace or they don't fit your view of what/where/how they should be documented. As for tiger:name_base, tiger:name_type, etc., if there's someone that's using that information, we definitely should take it out of the tiger namespace. I'd be happy to move it from tiger:name_base=* to name_base=* instead of deleting it, if someone is using it and would take 5 minutes to put something up on the wiki announcing it. If it's useful, then it's useful for non-tiger ways as well as tiger ways. Yes, it is useful for non-tiger ways as well. And I will bet it will be useful for other countries besides the U.S. also. 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. - Alan ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
