Re: [Talk-us] Importing Virginia road centerlines
Richard Weait rich...@weait.com writes: On Mon, Feb 21, 2011 at 12:04 PM, Peter Budny pet...@gatech.edu wrote: Josh, this sounds great! Unfortunately, you're headed in to really new territory. As far as I can tell, OSM doesn't have any methods in place for merging data in any meaningful sense, which sounds like what you need to do. (In other words, Take X, Y and Z from this data, and Q and P from this data, and put them together.) I can't help you much, but I wish you lots of luck. I've had my share of disagreements with people about how OSM should deal with imports and automated edits, so I wanted you to know that there are people out here who encourage this kind of work. Tell us what you really think, Pete! ;-) http://twitter.com/bigpeteb/status/39685277882646528 http://lists.openstreetmap.org/pipermail/dev/2010-October/020738.html Your point? Back in October when I started working on my project, I almost got so tired with people attacking me for trying to help in a way they disagreed with, I nearly gave up the idea. But then a couple of people stepped up and asked why everyone was beating me up for trying to use my skills and expertise to contribute. I wanted to return the favor, and let Josh know that regardless of any other vitriolic responses he may get about contributing data that wasn't painstakingly generated by hand (in the finest tradition of pencils and paper and abacuses, or whatever surface street mappers are using these days), some people support this kind of work. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relations, cycle routes, shapefiles
Craig Hinners cr...@hinnerspace.com writes: Want to render the Oregon cycleway shield? Do so if the tag.key==cycleway:oregon and put the tag.value in the shield. It was as if millions of programmers cried out in horror, and were then silenced... This is the problem with keys... it quickly adds lots of special-purpose code to any application that wants to interpret the data. Instead of saying Render a shield for every relation of route=cycleway, we have to say Render a shield for every tag whose key matches 'cycleway:*', but not if the key is 'cycleway:backwards', and not if the value is 'yes', and... Tagwatch currently shows 41 keys that match cycleway:* and are NOT of the form cycleway:locality name. That's a lot of special cases to encode in the renderer... special cases which aren't a problem when using relations. -- Peter Budny \ Georgia Tech \ CS MS student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Relations, cycle routes, shapefiles
I'm sorry that you don't seem to see the value in using relations. You are definitely correct... there are many ways to represent the same set of data, with no loss of integrity. Computer programmers often have to make choices over how complex the data model should be. Some very large and efficient systems have been built with nothing but key-value stores. (Google and Amazon have both used this model for some of their highly-distributed storage systems.) This doesn't mean, though, that it's the right solution for everything. A major advantage of using relations is that there is a single entity which unambiguously represents a highway like US-26. Without relations, the only representation is a mathematical set of ways. This causes a lot of problems, because there's no obvious place to put information that belongs to the whole road, like the official_name. Does it go on one way? On all of them? What if two ways have official_name tags that don't match? Even if your tags are correct, it could cause users to have to look through a LOT of data to find a piece of information. This is the reason behind the common database concept of normalization. The idea is that you specify things in ONE place, and then reference the data indirectly elsewhere. Using key/value tags as you suggest is a highly denormalized system, and would be a bad solution for the kind of data OSM is trying to represent. Relations are also easier for computers to parse, because it's very easy to write a pattern that recognizes type=route, route=road and handles it appropriately. With keys, you have to perform text matching on the keys, and this is a serious pain for programmers. Any time you ask a computer to interpret a string as being something other than a literal bunch of characters, there is the possibility for things to get screwed up. Strings are the ultimate vehicle for hiding information. ~ Peter Budny Craig Hinners cr...@hinnerspace.com writes: The only thing that relations add (in terms of tagging) is an order of magnitude of complexity. There is no technical reason why direct application of tags to ways can't work. However, this requires the use of highly-specific tag keys, such as a unique key for interstate highways, a unique key for U.S. highways, a unique key for [insert your state here] highways, a unique key for [insert your state here] bikeways, etc. For whatever reason, though, the de-facto practice became cramming everything under the sun into the values of tags having non-unique keys, such as ref, to the point where said tags mean everything while at the same time mean nothing. The concept of key/value pairs is common in computing, where the key describes a unique concept in the dataset: interstate, U.S. hwy., etc. However, now that ref has taken on thousands of different meanings depending on context, it can hardly be considered a key any more, to where it has zero utility outside of rendering (i.e., displaying its value in a shield). Which is quite ironic, if you think about it, given how we're constantly berated to not tag for the renderer. Hence the reason why everything breaks down when, god forbid, there is a way that belongs to two classes of networks (say, interstate and U.S. hwy.), because you now have to somehow convey multiple concepts in a single tag (ref ). Which is why the operative workaround is to resort to another layer of abstraction (and complexity) in the form of highly-specific relations, when everything could have been taken care of in the first place with directly-applied tags having conceptually-unique keys. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- Peter Budny \ Georgia Tech \ CS MS student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-dev] Super-relations or not
Marcus Wolschon mar...@wolschon.biz writes: I'm using routes in way-simplification to generate simplified maps for realtime rendering of larger areas when zooming out. It's quite a lot of work with LOTS of cases to try to sort route-relations that are randomly sorted with parts being other relations instead of ways, parts being contained twice, parts missing in the relation but having a ref= -tag or a ref_nat= -tag or ... , parts having a ref= -tag with the wrong road-number that should NOT be made a part of this simplified way,... In fairness, much of that sounds like errors. A route relation ought to contain exactly the things that are part of it, no more no less. The ref=* tag on ways is irrelevant for a route relation. What would you prefer to see the structure of the relation be, given your druthers? Should both directions of a road be in one relation, tagged with roles? Should a oneway=no way have a role? Should it be in the relation twice with different roles? Should there be separate relations for each direction with a super-relation to hold them both? If super-relations are used, does it still make sense to use forward/backward tags as appropriate? As far as I'm concerned, the difference in what's required to tag things is minimal between these concerns. Therefore, wouldn't it make the most sense to choose whichever is programmatically the easiest and most flexible to deal with? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [OSM-dev] Super-relations or not
Andy Allan gravityst...@gmail.com writes: On Fri, Oct 29, 2010 at 2:45 AM, Peter Budny pet...@gatech.edu wrote: That doesn't work; there are cases where it's ambiguous. If you look at [1], US-278 runs along North Avenue (bottom) and Ponce de Leon Avenue (top), connected by Monroe Drive (left) and Piedmont Avenue (right). The problem is that North Ave and Ponce de Leon are both oneway=no, while Monroe and Piedmont are oneway=yes. So unless you run a routing algorithm over the relation, you can't figure out just from the oneway tags that US-278 westbound doesn't include North Avenue (which you would otherwise assume from it being oneway=no). Someone, somewhere, has messed this up good an proper. I can't find the origins of this discussion to figure out where it's arisen from though. The situation you describe is easily dealt with using Route Relation roles forward and backward as per cycle routes, or bus routes, or every other route relation. See for example http://www.openstreetmap.org/?lat=51.8lon=0.89395zoom=17layers=00B0FTF It's clearly documented here: http://wiki.openstreetmap.org/wiki/Relation:route#Members and rendered on multiple maps. However, I see from elsewhere that people are making route relations in the US and filling the memberships with west and south and suchlike and then finding this causes problems. My advice is to stick to the route relation member roles that work for every other type of route, and if people ray want to have separate routes for I5 East and I5 West then feel free (something that hasn't seemed necessary elsewhere) - but don't put the words east or west in the ref, add an additional tag to the relation for overall direction or something. But please, stick with the forward/backward stuff for route relations roles, it works well. Okay, let's presume for a minute that blank/forward/backward is the correct method. I'll grant that it does have its advantages, such as for the scenario I described. However, when I look at http://ra.osmsurround.org/analyze.jsp?relationId=78041 (in Belarus) or http://ra.osmsurround.org/analyze.jsp?relationId=93920 (in Canada), the display is meaningless. It hasn't bothered to connect the forward/backward ways to the ways with no role, so it's totally unclear what's going on. If you want this to be the standard way of tagging things, then we NEED to get the tools up to spec. I also noticed that Potlatch doesn't change the role from forward to backward when you reverse a way. (JOSM does the right thing, though.) My argument for super-relations is that they pretty much work NOW. You don't have to look at the roles... one relation contains one direction, end-to-end. P.S. I don't know why people haven't complained about this more. Maybe because most of the route relations are on motorways, which are almost universally dual-carriageway. In the US where lots of minor roads are signed as routes, and routes are sometimes discontiguous, I think the issues [will] stand out a little more. P.P.S. Why do I see so many route relations where a way has been added more than once, sometimes up to 5 times, with the same role? What is that supposed to mean? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Super-relations or not (was: Relation member_roles from Osmosis import)
(sorry for the crossposting, but this really applies globally, as well as for recent discussions on the talk-us list) Ian Dees ian.d...@gmail.com writes: On Thu, Oct 28, 2010 at 9:14 AM, Peter Budny pet...@gatech.edu wrote: Jochen Topf joc...@remote.org writes: On Wed, Oct 27, 2010 at 10:39:38AM +0200, Frank Broniewski wrote: Thats a left-over from the time when relation members were not ordered. Someone in another thread just told me relation members /aren't/ ordered, and that the ordering that, say, JOSM displays is just as a tool to aid the user... not for any semantic purpose. Which is it? http://wiki.openstreetmap.org/wiki/Elements#Relation says The ordering of elements within a relation is persistent. The members are returned in the order specified at upload. Duplicate elements will retain their specified order. Aha. Now that's interesting. To me, this says we really ought to be using super-relations for route relations, rather than a single relation with roles tagged, for 2 reasons: 1) The common way, up to now, for storing routes that alternate between single- and dual-carriageway has been to leave the single-carriageway parts without a role, or with the role north/south. This makes the order of the members of the relation meaningless, since you can't traverse the ways end-to-end in the specified order. This could be solved by adding the single-carriageway sections twice (once with north and once with south), but at that point, why not take the extra 5 seconds and do super-relations? 2) If the direction of a road (e.g. north/south) is indicated by roles, how do you refer to it elsewhere? For example, if you have a destination sign that says it goes to I-75 Northbound, and all of I-75 is in one relation with roles for north and south, how do you refer to just one direction of the road? You can't refer to the whole relation (because that doesn't reflect what the sign says), and there's no clear way to refer to a role of a relation. With super-relations, this isn't a problem... there would be a subrelation that unambiguously refers to just the northbound or southbound part of the road. I really think that super-relations for routes are the way to go... all the methods are really equivalent, but super-relations are easier to deal with programmatically, preserve a little more information, and are not really any more difficult for users/mappers. If anyone has a compelling argument against super-relations, or for single relations, I'd like to hear it. Supporting both seems really pointless, and I think it's about time we picked one or the other so we can develop proper support for route relations and tools to support them moving forward. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route Tagging Consensus
Toby Murray toby.mur...@gmail.com writes: On Tue, Oct 26, 2010 at 12:43 AM, Paul Johnson ba...@ursamundi.org wrote: On 10/25/2010 08:43 AM, Zeke Farwell wrote: For Michigan route 12: ref=12 network=state state=michigan For Bennington County route 16 in Vermont: ref=16 network=county state=vermont county=bennington I like it, though it should be pointed out that this is more difficult unless we're talking about route relations. I kind of like this system as well. It is clear and easy to understand. The only problem (as pointed out before) is that it breaks the network tag compared to the rest of the world. Can we use it anyway? :) What about making it network=US:state or network=US:county? That way it's easy to tell US states apart from states in other countries. Does that ruin its simplicity and elegance? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Route Tagging Consensus
Andrew S. J. Sawyer assaw...@gmail.com writes: Is there a reason to have the network tag with networkUS:state:county instead of three separate tags for network:country network:state and network:county in the case of county roads and two in the case of state, etc. Having a network:country= tag will clear up any confusion in which country the route is in. I don't think a simple US:state:county tag will suffice as people have complained about parsing. Such a tag would likely have to be tagged network:location=US:state:county as you would have to differentiate between interstates, highways, etc. easily. By having a network and location tags you could know the location and type of road. Additionally this would allow for rendering of shields or determining the type route for other rendering differentiation purposes. I think because other tags break out location based on country, state, county, etc it would be wise to also do so with network tagging. There are many counties that have the same name that are in different locations. Other OSM users have expressed issues with relying on pre-possessing to gather location data. I may not have been very clear... if that's the case I apologize. What I meant was, is there a way to include just a little more information so that we can distinguish between, say, US states and Mexican states. If the tags only say network=state and state=* we lose some information. My proposal was to have network=US:state (literally, not putting the state name there) and state=*. However, I think your idea may be a better one. It would give us network=state network:country=US network:state=California or network=county network:country=US network:state=California network:county=Orange I support something like this because it gives us enough information that we can pretty easily convert to another format (relations, or some other tag representation) later with automated tools. And it makes querying easier, since you don't have to do polygon searches to figure out whether e.g. the route it part of a US state or a Mexican state. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Possible method for identifying major US cities
Phil! Gold phi...@pobox.com writes: * Nathan Edgars II nerou...@gmail.com [2010-10-25 21:39 -0400]: I've done it in Florida. Here's the algorithm I used: principal city of a Metropolitan Statistical Area: city principal city of a Micropolitan Statistical Area: town other incorporated municipality with population over 10,000: suburb (these are all inside statistical areas) other incorporated municipality with population under 10,000: village, hamlet, or (in the case of Islandia) locality (according to the cutoffs on http://wiki.openstreetmap.org/wiki/Key:place) other unincorporated places: left alone for now I mostly like this, but I feel somewhat constrained by the place= values for some of this. I went over the classifications that this would make in Maryland and agreed with most of it, except that I'd really like another value above place=city. This algorithm would mark Arlington, VA; Alexandria, VA; Reston, VA; Bethesda, MD; Rockville, MD; Frederick MD; and Gaithersburg, MD as cities, in addition to Washington, DC. That's pretty fair, considering those places' populations and economic importance, but DC should be ranked a step higher than the rest. Likewise, it would make Baltimore and Towson both cities and, while making Towson a city is not unfair, Baltimore is far more important a place than Towson is. (For one thing, people from other states are much more likely to have heard of Baltimore.) I've been thinking a lot about city importance since I read http://www.41latitude.com/post/1178194590/jaywalking and http://www.41latitude.com/post/400972984/most-important-cities-united-states . I think I'm mostly of the mind that OSM's basically four-tier system (city, town, village, hamlet) system isn't granular enough for properly indicating cities' importance relative to each other. I think some of the general importance tagging ideas that have been floated might help with this. If I have time, I might see about getting them on the proposal track actively, rather than languishing. Martin and I had a discussion (was it on this list?) about this, and I think we agreed that the place=* tag isn't really very helpful. It's just too coarse-grained, and it can't be tuned for producing different types of maps. The idea we started thinking about is to have tags (on the city node, or way, or relation) that give a whole bunch of statistics that might be relevant for determining how important a city is, which would determine at what zoom level it shows up and how big its label should be. Not to say that the place=* tag should go away, but I'd like to see it relegated to being nothing more than a 'suggestion' for less featureful renderers. Any serious map rendering ought to be more flexible than just 4 arbitrary sizes of cities/towns assigned manually. (My sole complaint about the idea, really, was that having tags in OSM for information like population which could theoretically be culled from other sources automatically is kind of redundant and thus troublesome... except that we'd have to have so many data sources (one per country, roughly) that it would be impossible to maintain. So just sticking it in tags and updating it manually/semi-automatically is probably okay.) -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
Nathan Edgars II nerou...@gmail.com writes: On Tue, Oct 26, 2010 at 12:45 AM, Val Kartchner val...@gmail.com wrote: Second, let's decide if we should render the route numbers in route-type specific shields. I think that we should do so. Let's not let Google, MapQuest and Bing be a ceiling, but instead a floor. No for state roads in general. Some shields are poorly-designed for display in a limited number of pixels. For example http://commons.wikimedia.org/wiki/File:Colorado_7.svg is four times the size a simple rectangle would be. I have to agree... most state road shields with the outline of the state have too much detail to be legible when they're small, which is why I almost always see them rendered as a circle/oval. I'd say that's pretty standard across the US. Maybe at the very highest zoom levels we could switch to the state-specific shields? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] how to tag US townships?
Anthony o...@inbox.org writes: On Wed, Oct 20, 2010 at 1:21 PM, Jim McAndrew j...@loc8.us wrote: There are townships in other states that are managed differently, but in PA and NJ, they are just county subdivisions, and are not points to put on a map. I think you're right here, though I probably would indicate the township boundaries on most maps in a similar (though somewhat less prominent) manner to county boundaries - at least at certain zoom levels. It sounds like you may have just found a use for the missing admin_level=7 in the US. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] how to tag US townships?
Anthony o...@inbox.org writes: On Wed, Oct 20, 2010 at 4:47 PM, Anthony o...@inbox.org wrote: At the very least it would be nice to have a table outlining exactly what municipality or minor civil division means for each state. Is there one somewhere already? Should I start one? http://wiki.openstreetmap.org/wiki/United_States_municipalities Looks like a good start. Why don't we work on filling this in and see where we end up? It would be nice to have some kind of tree-like layout indicating for each state which entities are strict subsets of another, which are on the same level as another, and which have an unclear relationship. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
Toby Murray toby.mur...@gmail.com writes: For example, Kansas highway 18: type = route route = road network = US:KS ref = 18 (optional?) symbol=* tag Also an optional wikipedia link. There does seem to be some debate about county roads. I would probably throw my vote in with something like network=US:KS:Riley +1 The county name needs to be in there, otherwise you can't tell two county roads apart which use the same number. (Analogously, you wouldn't put US:STATE... how would you know which state?) I don't see any advantage to abbreviating the county name... that just seems like more effort for mappers, with no real payback. (I certainly don't know abbreviations for all 159 counties in Georgia.) I do have one question: Is it acceptable/proper to have a name=* tag on a relation? I have seen it on some and have actually used it a couple of times - for example name=KS 18 The only advantage I see is that it makes things easier to read in editors and when browsing data since the name tag is used when displaying relations in lists or listing what relations a way is part of instead of just showing the numeric ID. But this is a case of tagging for tools so I could see reasonable objections to it. Well, the question is, does the name apply to the whole route? For basic cases, you might have name=Interstate 75 or name=U.S. Route 41. For KY-555 you might have name=Kentucky Route 555 and loc_name=Triple 5 Highway. However, there are many stretches of road that are designated Col. John Q Public Memorial Highway or something like that. It only applies to part of the route (the whole route through a state, or maybe just a bridge or an intersection). In that case, it belongs on the ways, not the route. So, there seems to be utility for both. The question is, what happens when both a way and a relation have name= set, and they don't match? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
Ian Dees ian.d...@gmail.com writes: On Mon, Oct 18, 2010 at 3:22 PM, Alex Mauer ha...@hawkesnest.net wrote: On 10/15/2010 09:44 PM, Richard Welty wrote: I don't think we should be storing any prefix as part of the network=* or ref=* tags (thus my suggestion for network=us_route/state_route/county_route or similar). For example the I-x denotation shouldn't show up anywhere in our tags. If it's an interstate it should be tagged as such (I suggest network= interstate but I think there's a precedent on the wiki) and the renderer can add the I- if it wants to. i agree, it's a rendering prefix for a ref tag value and deserves its own, separate tag. For relations I agree, but for ways this doesn’t work. And as renderers can only handle ways for now… This is a data project, not a renderer project. If the renderers aren't doing the right thing then we need to make them do the right thing. +1 Continuing to use ref= tags at all when we have relations that represent a much cleaner way to tag roads is a terrible case of tagging for the renderer. I think it's premature to remove ref tags, but I don't see any point in adding them to new ways, rather than just creating a relation. If the relations keep getting broken, we ought to fix the tools people are using so it isn't as easy to break them. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State Route relations (was: Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns))
Nathan Edgars II nerou...@gmail.com writes: On Sat, Oct 16, 2010 at 6:05 PM, Peter Budny pet...@gatech.edu wrote: Nathan Edgars II nerou...@gmail.com writes: It's certainly a bad idea to add the auto-created relations to the database You're not the first person to say this. You're also not the first person to fail to give a reason why it would be so terrible. It would be, quite literally, vandalism: adding information that you know to be incorrect. Is incomplete information incorrect? If so, we've got an awful lot of human vandals. What makes you think human mappers get everything right all the time? I believe you're the one who added all the Florida state route relations... did you actually drive over every mile of road to verify it before adding it to the relation? Or did you look at the data on the map (name=, tiger:base_name=, ref=, etc) and create relations from that? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State Route relations (was: Highway Tagging ConsensustoImprove OSM (and address some of 41 latitude's concerns))
Mike N. nice...@att.net writes: One thing I /haven't/ seen addressed yet is whether single relations are preferred, or one relation for each way with a super-relation. Currently both are in use, but I think it would be a lot easier for future code if we pick one and move towards it from now on. I don't see any advantage for a relation per way; a single relation with roles for each direction has all the information needed by a relation-user, and it's one less thing to keep track of when editing or updating. The potential problem I see is when you have a road that alternates frequently between single- and dual-carriageways (which many state routes do, and even a lot of US highways). How do you represent this in a single relation? 1) Put single-carriageways in once, with no role. Or, with role=north/south. Either way, this is difficult to recognize and parse automatically. And aren't members of a relation ordered inside the relation? (I know JOSM shows icons for whether a way is connected to the ways before and after it in a relation.) The ordering loses any meaning under this method. 2) Put single-carriageways in twice, once with role=north and once with role=south. This is allowed, and fixes the problem, but don't most editors complain when the same object appears more than once in a relation? In my view, having separate relations for each direction, and a super-relation to hold them solves this problem. But maybe there's some argument against them that I've missed. Thoughts? -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State Route relations (was: Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns))
Nathan Edgars II nerou...@gmail.com writes: On Sat, Oct 16, 2010 at 1:41 AM, Peter Budny pet...@gatech.edu wrote: This seems relevant to this thread, although it's not in reply to any particular part of it: As part of a school project, I'm creating a robot that will use the TIGER metadata to automatically attempt to create route relations for State Roads. (The Interstates and US Highways are mostly finished, it seems, but there are tens of thousands of state routes that haven't been touched.) TIGER's state highway data is pretty horrible. For example, in Florida, there are many so-called state roads that were given to the counties in the 1980s. It seems most have been fixed, but here's an example: http://www.openstreetmap.org/?lat=30.4537lon=-85.2118zoom=14layers=M I'm planning on using the tiger:base_name tag, since that seems to be pretty consistently applied (except that TIGER couldn't decide whether to use State Highway or State Route or SR... but I can just search for all known combinations of names). The area you linked seems to have these tags intact for FL 20, FL 73, FL 287, and FL 287A. Did I overlook something? You also have major problems in towns, where a route doesn't make a turn like it should. The generated relations will have to be checked by hand, because of problems exactly like this. However, 80-90% of the tedious work will be done, and (I hope) users will be able to walk the relation end-to-end and fix up the problem spots pretty easily. Checking all 6000+ of Kentucky's state routes by hand seems easier than having to actually *find* all 6000 of them by staring at the map. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State Route relations (was: Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns))
Nathan Edgars II nerou...@gmail.com writes: On Sat, Oct 16, 2010 at 11:46 AM, Peter Budny pet...@gatech.edu wrote: Nathan Edgars II nerou...@gmail.com writes: TIGER's state highway data is pretty horrible. For example, in Florida, there are many so-called state roads that were given to the counties in the 1980s. It seems most have been fixed, but here's an example: http://www.openstreetmap.org/?lat=30.4537lon=-85.2118zoom=14layers=M I'm planning on using the tiger:base_name tag, since that seems to be pretty consistently applied (except that TIGER couldn't decide whether to use State Highway or State Route or SR... but I can just search for all known combinations of names). The area you linked seems to have these tags intact for FL 20, FL 73, FL 287, and FL 287A. Did I overlook something? 287 and 287A have been county roads for the last 20-30 years. You also have major problems in towns, where a route doesn't make a turn like it should. The generated relations will have to be checked by hand, because of problems exactly like this. However, 80-90% of the tedious work will be done, and (I hope) users will be able to walk the relation end-to-end and fix up the problem spots pretty easily. I just hope people don't take a shortcut and accept the TIGER data. I recently had to clean up after someone doing this in north Florida: http://www.openstreetmap.org/browse/way/11057836/history http://www.openstreetmap.org/browse/way/10991196/history I'm not sure whether you're saying it's a good idea or a bad idea. It seems to me that once you have all the relations in the db, it's easy to get a list of all network=US:FL route relations, compare it to a current list of state-maintained roads, and find the ones that need to be edited. Without the relations, there's no particularly easy way to find this data so it can be corrected. And, if people keep mistakenly tagging these as state roads when they're actually county roads, maybe there should be a note=Not a state highway; this has been a county road since 19xx. See url -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State Route relations (was: Highway TaggingConsensustoImprove OSM (and address some of 41 latitude's concerns))
Mike N. nice...@att.net writes: The potential problem I see is when you have a road that alternates frequently between single- and dual-carriageways (which many state routes do, and even a lot of US highways). How do you represent this in a single relation? 1) Put single-carriageways in once, with no role. Or, with role=north/south. Either way, this is difficult to recognize and parse automatically. And aren't members of a relation ordered inside the relation? (I know JOSM shows icons for whether a way is connected to the ways before and after it in a relation.) The ordering loses any meaning under this method. The way I've done this, and seen it done, is to put single carriageways in once with no role. I'm not sure I understand the difficulty of parsing it automatically - please elaborate. Here's one instance where this doesn't work as well as I'd like: http://ra.osmsurround.org/analyze.jsp?relationId=271830 Michigan 3 (which I picked randomly off a list) alternates between single- and dual-carriageway. Because the analyzer doesn't understand that the unlabeled roles actually belong with both north /and/ south, it shows a bunch of gaps that aren't actually there. If this is the tagging format we're going to use, we need to fix the tools to handle this correctly. Adding a single-carriageway to the relation twice, once for each role, would solve this problem instantly, as would using two separate relations. Neither requires much (if any) code changes to support it. But in any case, I'm much more in favor of consistency, even if the format we choose isn't the one I would prefer. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] State Route relations (was: Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns))
Nathan Edgars II nerou...@gmail.com writes: It's certainly a bad idea to add the auto-created relations to the database You're not the first person to say this. You're also not the first person to fail to give a reason why it would be so terrible. Florida already has a full set of relations: http://wiki.openstreetmap.org/wiki/Florida/State_road_relations But if this weren't so, your tool would create a large number of incorrect relations. I'm told Michigan is also complete. That's 2 states out of 50, and I know some of the rest aren't finished, or even really started. Having a robot group roads into relations is no different from what's being done now, where people do bits and pieces at a time, possibly incorrectly. See http://wiki.openstreetmap.org/wiki/Georgia_(U.S._state)/State_Highway_Relations#State_Highways Since there's been so much opposition, I'm not currently planning to upload directly to the database; as a compromise I'm planning to publish changesets and let people integrate them manually. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
Ian Dees ian.d...@gmail.com writes: On Fri, Oct 15, 2010 at 2:22 PM, Nathan Edgars II nerou...@gmail.com wrote: On Fri, Oct 15, 2010 at 3:07 PM, Ian Dees ian.d...@gmail.com wrote: ...discussions on the mailing list tend to wander all over the place and lead to no conclusions or decisions being made. If we meet in a phone conference call or even in a chat room then we can get more done. E-mails are by design non-comittal and standoffish while real time chats can have a bit more impact. OK, but then you're only forming a consensus of the people who are there, rather than all interested parties. Surely we're missing plenty of people by only having a discussion on the mailing list? SoTM.US proved to me that there are orders of magnitude more people interested in OSM in the US than are signed up for talk-us. +1 I only got on the mailing lists 2 weeks ago because I wanted to ask a question to dev. If you come in to OSM by reading the wiki, it appears as though all the discussion happens on talk pages. There's nothing at all indicating that the mailing list is where it's at. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
Mike N. nice...@att.net writes: If you want to mention among other places frequented by US mappers, feel free Some people detest the mailing list signup grind, and thus choose the web forum at http://forum.openstreetmap.org/viewforum.php?id=20 . There's a forum? I don't have a problem with have lots of different modes of communication, but it really needs to be made clear which one is THE preferred way to talk to People Who Know Things and seek out community agreement. It seems like that's the mailing lists (at the moment), possibly followed by the wiki as a repository of information, but that's not obvious from reading http://wiki.openstreetmap.org/wiki/Contact -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns)
Nathan Edgars II nerou...@gmail.com writes: On Fri, Oct 15, 2010 at 12:08 PM, Phil! Gold phi...@pobox.com wrote: == Some Interstates Show Exits—Others Don't == This is really just a problem with map coverage, not tagging convention, but I'd like to ask about consensus on name= and ref= tags for motorway_junctions. ref= is pretty obviously the exit number, but although some wiki pages (Interstate Highways, in particular) say or imply that everything on the exit sign should go into the name= tag (including the junction road but also further destinations like towns and distant roads). I think it makes more sense to just have the junctioned road (or really significant destination road, like when the junctioned road is almost always just a means to get to another major road) in the name= tag and use the destination sign relation for the other information. Thoughts? I believe exit_to is for the text on the sign, and name is for an actual name *if one exists*. Often a toll road will have named interchanges, but this is rare otherwise. Wouldn't it be a lot nicer to use destination relations to tag this? A motorway_junction node could be referred to in multiple destination relations, one for each thing on the sign (for example: US 78, US 278, Main Street, Wharf District). The relations could refer to the route relations, so we could get nicely drawn shield for Interstates and US Highways. Along these lines, maybe we should talk about junction relations. They would be really useful for indicating which map features (traffic signals, motorway junctions, etc) are really one logical entity, and should be represented as such on the map at higher zoom levels. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] State Route relations (was: Highway Tagging Consensus to Improve OSM (and address some of 41 latitude's concerns))
This seems relevant to this thread, although it's not in reply to any particular part of it: As part of a school project, I'm creating a robot that will use the TIGER metadata to automatically attempt to create route relations for State Roads. (The Interstates and US Highways are mostly finished, it seems, but there are tens of thousands of state routes that haven't been touched.) I'd love to see a consensus on how to tag these roads come pretty quickly, as I'll need to have something finished in less than 2 months (school schedules are rough, man!). So far, it seems to be something like type=route route=road network=US:NY - state abbreviation ref=87 - number only symbol=* or for county roads, network=US:NY:Albany - full county name One thing I /haven't/ seen addressed yet is whether single relations are preferred, or one relation for each way with a super-relation. Currently both are in use, but I think it would be a lot easier for future code if we pick one and move towards it from now on. ~ Peter Budny P.S. Before you write to tell me bots aren't welcome... stop. We already had this discussion out on dev. I'm going to be developing against a sandbox database, and not uploading any changes (yet). I'll start by sharing changeset files with the lists to give everyone a chance to nitpick and find mistakes. And when the robot is ready, I may still run it by publishing changeset files and letting people integrate them manually. So please don't write to say I don't know what I'm doing and my contributions aren't welcome. -- Peter Budny \ Georgia Tech \ CS PhD student \ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
