Re: [Talk-us] United States Roadway Classification Guidelines
Can you show me an area of the US that's tagged completely objectively? For example: Interstate 99 near Altoona, PA is coded (AFAIK appropriately) a motorway. Over the entire length of the Interstate, it looks like it serves a max average daily traffic of 37,000 vehicles per day (http://www.interstate-guide.com/i-099.html), which is equivalent to many primary roads. Given this volume, it is reasonable to imagine Interstate 99 was never built. Instead there is a four lane, at-grade highway. The road would still serve the same interregional travel purpose in the area network. It could have the same traffic volume. But it wouldn't be a motorway. Interstate 99 doesn't share other qualities of Interstates (traffic volume, Interstate Travel, connecting large cities) Therefore, the current classification of motorway is based on the physical quality of the road. I've also been on ridiculously under-designed two lane roads in the Philadelphia and other Northeastern suburbs that carry large loads of commuter traffic. They function as primary or secondary roads, but they aren't built like the ones in my area and should not be classified the same way. If they code it as such, it will only serve to alienate visitors. This is the North Bethlehem Pike north of Philadelphia. http://www.openstreetmap.org/?way=12336821 It is coded as a primary road. This is Bass Lake Road west of Minneapolis. http://www.openstreetmap.org/?way=41442915 It is coded as secondary. I'll let you dig up what the roads look like with whatever tools you're comfortable with. But the way it looks to me is that functionally, they are probably both accurate. Physically, the secondary road is a much more robust road. These differences are reflective of regional differences, and I did not need to spend much time looking for them. If they are all coded by relative local function, we whitewash regional differences - the interesting (useful, if that's a requirement) bits to me. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Roadway Classification Guidelines
On Thu, Jul 29, 2010 at 9:40 AM, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: Can you show me an area of the US that's tagged completely objectively? For example: Interstate 99 near Altoona, PA is coded (AFAIK appropriately) a motorway. Over the entire length of the Interstate, it looks like it serves a max average daily traffic of 37,000 vehicles per day (http://www.interstate-guide.com/i-099.html), which is equivalent to many primary roads. Given this volume, it is reasonable to imagine Interstate 99 was never built. Instead there is a four lane, at-grade highway. The road would still serve the same interregional travel purpose in the area network. It could have the same traffic volume. But it wouldn't be a motorway. Interstate 99 doesn't share other qualities of Interstates (traffic volume, Interstate Travel, connecting large cities) Therefore, the current classification of motorway is based on the physical quality of the road. I know that motorway is based on physical characteristics. I'm asking for an area where every road is tagged objectively. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Roadway Classification Guidelines
Regarding Matthew's earlier point (Agreed. There is no observation that will tell you whether a road is more important than another road that is not where you are. But you can identify physical characteristics. A lot of these observations will lead to a coherent whole.): it seems like if you take this to its logical conclusion, you're saying highways should just be tagged by physically observable characteristics, and rendering should go off that and drop the primary/secondary/tertiary etc? But I think *maybe* we can all agree that primary/secondary/tertiary are--or more accurately, could be :)--a convenient shorthand for entering/viewing roads data and for rendering. It's a matter of what that shorthand is pointing to. (plus, I personally have no interest in tagging lanes or speed limit on roads, but maybe others do?) Which brings us to the objective v. subjective question. Does our shorthand point to an objective system that is always applied exactly the same way in all situations? The more I've worked with OSM and data in general (especially at a statewide or national scale), the more I've come to the conclusion that it is hard to get one size to fit all. I think if we could agree on a solution that is 95% perfect, 5% do-what-you-need-to-do-for-it-to-make-sense-in-your-area, that'd be good enough for now, and far better than the confusion engendered by conflicting schemes spread across the wiki. Kevin's proposal seems to be headed in that direction. Cheers, Brad On Thu, Jul 29, 2010 at 8:40 AM, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: Can you show me an area of the US that's tagged completely objectively? For example: Interstate 99 near Altoona, PA is coded (AFAIK appropriately) a motorway. Over the entire length of the Interstate, it looks like it serves a max average daily traffic of 37,000 vehicles per day (http://www.interstate-guide.com/i-099.html), which is equivalent to many primary roads. Given this volume, it is reasonable to imagine Interstate 99 was never built. Instead there is a four lane, at-grade highway. The road would still serve the same interregional travel purpose in the area network. It could have the same traffic volume. But it wouldn't be a motorway. Interstate 99 doesn't share other qualities of Interstates (traffic volume, Interstate Travel, connecting large cities) Therefore, the current classification of motorway is based on the physical quality of the road. I've also been on ridiculously under-designed two lane roads in the Philadelphia and other Northeastern suburbs that carry large loads of commuter traffic. They function as primary or secondary roads, but they aren't built like the ones in my area and should not be classified the same way. If they code it as such, it will only serve to alienate visitors. This is the North Bethlehem Pike north of Philadelphia. http://www.openstreetmap.org/?way=12336821 It is coded as a primary road. This is Bass Lake Road west of Minneapolis. http://www.openstreetmap.org/?way=41442915 It is coded as secondary. I'll let you dig up what the roads look like with whatever tools you're comfortable with. But the way it looks to me is that functionally, they are probably both accurate. Physically, the secondary road is a much more robust road. These differences are reflective of regional differences, and I did not need to spend much time looking for them. If they are all coded by relative local function, we whitewash regional differences - the interesting (useful, if that's a requirement) bits to me. ___ 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] United States Roadway Classification Guidelines
WRT US Highway classifications You may want to take a look at the National Highway Planning Network. http://www.bts.gov/publications/national_transportation_atlas_database/2010/zip/nhpn.zip It contains the state designated functional classifications for some roads classified as a Minor Collector and almost all roads with a Major collector or higher classifications. As a planning product it does include roads that are still in the planning stages. Overall it is very helpful to see how the States view the classification of their roads. Functional classification differs from physical classification in that functional represents how a roadway participates in a local transportation network and physical represents the number of lanes, speed limit, daily traffic volume. Fields of interest may be FCLASS is the functional classification AADT is the Average Annualized Daily Traffic (Traffic volume) THRULANES is the number of lanes The functional classifications are defined in the Metadata as this: Attribute: Attribute_Label: FCLASS Attribute_Definition: Identifies the assigned functional class of each arc. Attribute_Definition_Source: Original functional classification codes came from data sources submitted as part of 1992 Functional Reclassification by State agencies. For segments on the National Highway System this attribute has been quality controlled against the 2002 HPMS. Attribute_Domain_Values: Enumerated_Domain: Enumerated_Domain_Value: 01 Enumerated_Domain_Value_Definition: Rural Principal Arterial - Interstate Enumerated_Domain_Value_Definition_Source: FHWA Enumerated_Domain: Enumerated_Domain_Value: 02 Enumerated_Domain_Value_Definition: Rural Principal Arterial - Other Enumerated_Domain: Enumerated_Domain_Value: 06 Enumerated_Domain_Value_Definition: Rural Minor Arterial Enumerated_Domain: Enumerated_Domain_Value: 07 Enumerated_Domain_Value_Definition: Rural Major Collector Enumerated_Domain: Enumerated_Domain_Value: 08 Enumerated_Domain_Value_Definition: Rural Minor Collector Enumerated_Domain: Enumerated_Domain_Value: 09 Enumerated_Domain_Value_Definition: Rural Local Enumerated_Domain: Enumerated_Domain_Value: 11 Enumerated_Domain_Value_Definition: Urban Principal Arterial - Interstate Enumerated_Domain: Enumerated_Domain_Value: 12 Enumerated_Domain_Value_Definition: Urban Principal Arterial-Other Freeways Expressways Enumerated_Domain: Enumerated_Domain_Value: 14 Enumerated_Domain_Value_Definition: Urban Principal Arterial - Other Enumerated_Domain: Enumerated_Domain_Value: 16 Enumerated_Domain_Value_Definition: Urban Minor Arterial Enumerated_Domain: Enumerated_Domain_Value: 17 Enumerated_Domain_Value_Definition: Urban Collector Enumerated_Domain: Enumerated_Domain_Value: 19 Enumerated_Domain_Value_Definition: Urban Local C. Carl Anderson On Thu, Jul 29, 2010 at 11:04 AM, Jim McAndrew j...@loc8.us wrote: As someone who has driven on these routes quite a number of times, I can say that PA roads are not up to the same standards as roads pretty much anywhere else in the country. When roads come into the state from NJ, they all go from 3-4 lanes down to two. Which is fine for a rural highway, but not I-76 going through Philadelphia. I think that as far as people living in those areas, they would believe their road to be a primary road, even if it is only a two lane road with a lot of stoplights. The terms primary and secondary are relative terms and they should be labeled as relative. It would be interesting to add the traffic count data to the ways and possibly use that to display the width of the road. As for the two Pennsylvania roads mentioned, there are my local perceptions on them: I-99 is a special case where a congressman wanted a road to go from the PA turnpike to I-80, he threw a bunch of money at it, and made up a new number to assign to it. The road never really was meant to be an interstate, and I think the state reluctantly accepted it being called an interstate only after the I-99 signs were put up. It doesn't follow interstate conventions or anything. It is a limited access highway though, and the speed limit is 65 the whole way. As a driver on the road, I wouldn't notice a difference between it and I-80. As far as Bethlehem Pike, the road was largely replace by Route 309 and 378. It is a very old road and follows Native American trails. In some areas, it still exists as an arterial road. The road is not used for any long distance travel, because people traveling further would be using route 309. Route 309 and Bethlehem Pike are concurrent for much of the way
Re: [Talk-us] United States Roadway Classification Guidelines
I think that's pretty much covered here: http://wiki.openstreetmap.org/wiki/Highway_Functional_Classification_System On Thu, Jul 29, 2010 at 10:35 AM, Carl Anderson carl.ander...@vadose.org wrote: WRT US Highway classifications You may want to take a look at the National Highway Planning Network. http://www.bts.gov/publications/national_transportation_atlas_database/2010/zip/nhpn.zip ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Talk-us Digest, Vol 32, Issue 32
as a primary road through that region. On Thu, Jul 29, 2010 at 9:40 AM, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: Can you show me an area of the US that's tagged completely objectively? For example: Interstate 99 near Altoona, PA is coded (AFAIK appropriately) a motorway. Over the entire length of the Interstate, it looks like it serves a max average daily traffic of 37,000 vehicles per day ( http://www.interstate-guide.com/i-099.html), which is equivalent to many primary roads. Given this volume, it is reasonable to imagine Interstate 99 was never built. Instead there is a four lane, at-grade highway. The road would still serve the same interregional travel purpose in the area network. It could have the same traffic volume. But it wouldn't be a motorway. Interstate 99 doesn't share other qualities of Interstates (traffic volume, Interstate Travel, connecting large cities) Therefore, the current classification of motorway is based on the physical quality of the road. I've also been on ridiculously under-designed two lane roads in the Philadelphia and other Northeastern suburbs that carry large loads of commuter traffic. They function as primary or secondary roads, but they aren't built like the ones in my area and should not be classified the same way. If they code it as such, it will only serve to alienate visitors. This is the North Bethlehem Pike north of Philadelphia. http://www.openstreetmap.org/?way=12336821 It is coded as a primary road. This is Bass Lake Road west of Minneapolis. http://www.openstreetmap.org/?way=41442915 It is coded as secondary. I'll let you dig up what the roads look like with whatever tools you're comfortable with. But the way it looks to me is that functionally, they are probably both accurate. Physically, the secondary road is a much more robust road. These differences are reflective of regional differences, and I did not need to spend much time looking for them. If they are all coded by relative local function, we whitewash regional differences - the interesting (useful, if that's a requirement) bits to me. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-us/attachments/20100729/80f226a2/attachment-0001.html -- Message: 4 Date: Thu, 29 Jul 2010 10:29:54 -0500 From: Brad Neuhauser brad.neuhau...@gmail.com To: McGuire, Matthew matt.mcgu...@metc.state.mn.us Cc: Nathan Edgars II nerou...@gmail.com, Anthony o...@inbox.org, Kevin Atkinson ke...@atkinson.dhs.org, Ian Dees ian.d...@gmail.com, talk-us@openstreetmap.org talk-us@openstreetmap.org Subject: Re: [Talk-us] United States Roadway Classification Guidelines Message-ID: aanlkti=ulmrg_t=xpoue+ljtclavzxmz_fjonpkwm...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Regarding Matthew's earlier point (Agreed. There is no observation that will tell you whether a road is more important than another road that is not where you are. But you can identify physical characteristics. A lot of these observations will lead to a coherent whole.): it seems like if you take this to its logical conclusion, you're saying highways should just be tagged by physically observable characteristics, and rendering should go off that and drop the primary/secondary/tertiary etc? But I think *maybe* we can all agree that primary/secondary/tertiary are--or more accurately, could be :)--a convenient shorthand for entering/viewing roads data and for rendering. It's a matter of what that shorthand is pointing to. (plus, I personally have no interest in tagging lanes or speed limit on roads, but maybe others do?) Which brings us to the objective v. subjective question. Does our shorthand point to an objective system that is always applied exactly the same way in all situations? The more I've worked with OSM and data in general (especially at a statewide or national scale), the more I've come to the conclusion that it is hard to get one size to fit all. I think if we could agree on a solution that is 95% perfect, 5% do-what-you-need-to-do-for-it-to-make-sense-in-your-area, that'd be good enough for now, and far better than the confusion engendered by conflicting schemes spread across the wiki. Kevin's proposal seems to be headed in that direction. Cheers, Brad On Thu, Jul 29, 2010 at 8:40 AM, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: Can you show me an area of the US that's tagged completely objectively? For example: Interstate 99 near Altoona, PA is coded (AFAIK appropriately) a motorway. Over the entire length of the Interstate, it looks like it serves a max average daily traffic of 37,000 vehicles per day (http://www.interstate-guide.com/i-099.html), which is equivalent
Re: [Talk-us] United States Roadway Classification Guidelines
Thanks Brad. It may be useful to add data links to the NHPN and HPMS as they provide data in places where no active state data source link is referenced. Such as Colorado, Maryland, Texas and others. C. Carl Anderson cander...@spatialfocus.com carl.ander...@vadose.org (sent from my phone) On Jul 29, 2010 11:46 AM, Brad Neuhauser brad.neuhau...@gmail.com wrote: I think that's pretty much covered here: http://wiki.openstreetmap.org/wiki/Highway_Functional_Classification_System On Thu, Jul 29, 2010 at 10:35 AM, Carl Anderson carl.ander...@vadose.org wrote: WRT US Highway ... ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Roadway Classification Guidelines
On Thu, Jul 29, 2010 at 8:29 AM, Brad Neuhauser brad.neuhau...@gmail.comwrote: Regarding Matthew's earlier point (Agreed. There is no observation that will tell you whether a road is more important than another road that is not where you are. But you can identify physical characteristics. this is not true. There is plenty of observation to tell the importance. But this can't be done by armchair mapping. You have to know your area and it will be crystal clear which roads are more or less important. local knowledge is key for a good map. OSM is crowd sourcing and not let's draw some maps from aerial pictures or create a copy of tiger or other free data. there is no benefit if we use osm just as a container for freely available data. google is much better in doing so with their massive capacity and money. So let's make a better map not a me too map and not try to resolve a problem which can't be resolved by discussion or an algorithmic approach. road tagging is never objective. Not in US and not in Europe, and even much worse in many asian countries. it's a bit more consistent in Europe, but even there are many exceptions. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[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. 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
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] United States Roadway Classification Guidelines
On Thu, Jul 29, 2010 at 11:04 AM, Jim McAndrew j...@loc8.us wrote: I-99 is a special case where a congressman wanted a road to go from the PA turnpike to I-80, he threw a bunch of money at it, and made up a new number to assign to it. The road never really was meant to be an interstate, and I think the state reluctantly accepted it being called an interstate only after the I-99 signs were put up. It doesn't follow interstate conventions or anything. It is a limited access highway though, and the speed limit is 65 the whole way. As a driver on the road, I wouldn't notice a difference between it and I-80. Not quite - it's an Appalachian Regional Commission corridor, so were it not for Mr. Shuster it might have at-grade intersections, but it would still be a high-speed four-lane road. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] United States Roadway Classification Guidelines
On Thu, Jul 29, 2010 at 11:46 AM, Brad Neuhauser brad.neuhau...@gmail.com wrote: I think that's pretty much covered here: http://wiki.openstreetmap.org/wiki/Highway_Functional_Classification_System And it's not polished enough in many areas (the individual states or even the local metropolitan planning organizations set the classifications) for a final product. ___ 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
