Re: [Talk-us] Fwd: [OSM-talk] Using 'Kort' outside of Switzerland
Simon, Hello again. Thank you for the info about how Kort works. As a newcomer to OSM I wasn't familiar with keepright. Upon further study I discover that a user has added tags for Portland's Northwest (and Southwest) Naito Parkway in Japanese, and that keepright wants to know the language of the original name. This must be why Kort repeatedly asks me to specify the (English) language of ways on this street. On the bi-lingual questions, I just came back from a trip to Switzerland and had noticed the different approach to language signing than that of (say) Canada. Except in Quebec, much of which is signed only in French, most Canadian streets are named (say) Rue Blackshaw Street on a single name plate, with Rue and Street in smaller text than the core name itself. As you say, this is not the practice in Switzerland. And Kort reflects this. Good! The policy question of whether city streets in Portland should be tagged bilingually in English and Japanese is currently beyond me. It is possible that the city has signed this street in Japanese as well as English. I'll take a look now I know what's going on. Thank you for helping me understand how Kort works, Peter On Fri, Jan 17, 2014 at 1:46 AM, Simon Poole si...@poole.ch wrote: Hi Peter The underlying errors that are used for the challenges in Kort are generated by keepright http://keepright.ipax.at/report_map.php?zoom=12lat=39.95356lon=-75.12364and while the Kort authors select suitable errors for the game itself, they don't influence what keepright considers an error directly (see https://github.com/kort/kort/wiki). That said, perhaps a pointer to one of the roads in question would be helpful, IMHO keepright doesn't actually complain about missing language on street names (it does about the same for other objects). Simon PS: while Switzerland has numerous places that are truly bi-lingual, most aren't and current practice is not to add and extra name:de, name:fr, name:it or name:rm if there is only one name (which, if you think of it might lead to issues in exactly such bi-lingual places). Anyway I definitely don't have a couple of 100 Kort challenges around where I live (mono-lingual German speaking region), so likely you are seeing something different. Am 17.01.2014 00:24, schrieb Peter Davies: Simon, I tried Kort here in Portland, Oregon. It gave me some interesting things to think about. I'd hoped to send them to talk-ch, but it seems I can't without subscribing in the longer term. Maybe you can relay this to your local colleagues? Kort gave me three types of mission. One was to enter the language of some street names here in Portland. The second was to enter some speed limits, and the third was to name a pub. As feedback, and as a suggestion on how the game might need to be modified for countries outside Switzerland, I don't think that specifying the language of a street sign is useful in essentially monolingual countries. In the USA, street signs should always be considered to be in English. There is no reason to tag them with any language in OpenStreetMap. English is the default. There are interesting questions, of course: El Camino Real is a common street name in California, and is obviously Spanish, so what is the correct English name? Is it The Royal Road? No, I don't think so; we would not want to translate this to create an American English name. The correct name in English is El Camino Real. The Spanish name has been adopted into English usage. Local English speakers would all say El Camino Real. These thoughts lead me to the Avenue des Champs-Élysées. Should we write Elysian Fields Avenue in English? No, of course not. Almost everyone has heard of the Champs-Élysées, and no-one would dream of writing the Elysian Fields. So should we be translating street names at all? My conclusion is that only countries with separate, major linguistic communities actually do this. Personally I'd like my map to say Hauptbahnhofstrasse and not Central Station Street, so I could find it on other maps and signs, or try to ask for it correctly in Solothurn. On the other two questions, I knew that the urban speed limits were all 25 mph, because this is the blanket limit in Oregon's urban areas, but when I tried to enter this it was rejected. I was allowed to enter 25, but I worried that Kort might think this was in km/h. Would it enter 25 km/h into OpenStreetMap if someone confirmed my response? Meanwhile I found all of central Portland's residential roads without speed tags in JOSM and set them to 25 mph. Finally the pub: I didn't know it! It still remains to be answered. Thank you for this interesting game, Peter On Tue, Jan 14, 2014 at 4:38 AM, Simon Poole si...@poole.ch wrote: From the talk mailing list (mandatory disclosure: yes I know the authors). Original-Nachricht Hi there, I'm very proud to announce that finally
Re: [Talk-us] Fwd: [OSM-talk] Using 'Kort' outside of Switzerland
Thanks, Paul. I ... err ... think I get your point about the name in lang rather than the name translated into lang. I guess you're saying that the name in lang has to be in common usage, somewhere, and that the goal is not to translate all street names multi-lingually? It turns out that Kort's request for me to specify that Northwest Naito Parkway is in English was caused by a mapper having added its name to OSM in Japanese. I'm curious as to whether or not you think that this should have been added, as a matter of general policy. Would it depend on (say) whether or not the street is actually posted in Japanese as well as in English? Or should another criterion be suggested? (This being Portland, it's perfectly possible that this street is posted in an unusual language as well as in English. I can check.) I also began to become curious about countries that don't use the Latin alphabet. Should English or shall we say Latin alphabet translations be provided for Japanese street names like 伏見通り(Fushimi-dori), do you think? Peter On Thu, Jan 16, 2014 at 5:53 PM, Paul Norman penor...@mac.com wrote: name:lang tags are for the name in lang, not for the name translated to lang. My neighborhood name could be translated into many languages, but that doesn’t mean it has anything other than an English name. It’s also important to remember that English is not a default in OSM names *From:* Peter Davies [mailto:peter.dav...@crc-corp.com] *Sent:* Thursday, January 16, 2014 3:25 PM *To:* Simon Poole *Cc:* OSM US Talk *Subject:* Re: [Talk-us] Fwd: [OSM-talk] Using 'Kort' outside of Switzerland Simon, I tried Kort here in Portland, Oregon. It gave me some interesting things to think about. I'd hoped to send them to talk-ch, but it seems I can't without subscribing in the longer term. Maybe you can relay this to your local colleagues? Kort gave me three types of mission. One was to enter the language of some street names here in Portland. The second was to enter some speed limits, and the third was to name a pub. As feedback, and as a suggestion on how the game might need to be modified for countries outside Switzerland, I don't think that specifying the language of a street sign is useful in essentially monolingual countries. In the USA, street signs should always be considered to be in English. There is no reason to tag them with any language in OpenStreetMap. English is the default. There are interesting questions, of course: El Camino Real is a common street name in California, and is obviously Spanish, so what is the correct English name? Is it The Royal Road? No, I don't think so; we would not want to translate this to create an American English name. The correct name in English is El Camino Real. The Spanish name has been adopted into English usage. Local English speakers would all say El Camino Real. These thoughts lead me to the Avenue des Champs-Élysées. Should we write Elysian Fields Avenue in English? No, of course not. Almost everyone has heard of the Champs-Élysées, and no-one would dream of writing the Elysian Fields. So should we be translating street names at all ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: [OSM-talk] Using 'Kort' outside of Switzerland
Simon, I tried Kort here in Portland, Oregon. It gave me some interesting things to think about. I'd hoped to send them to talk-ch, but it seems I can't without subscribing in the longer term. Maybe you can relay this to your local colleagues? Kort gave me three types of mission. One was to enter the language of some street names here in Portland. The second was to enter some speed limits, and the third was to name a pub. As feedback, and as a suggestion on how the game might need to be modified for countries outside Switzerland, I don't think that specifying the language of a street sign is useful in essentially monolingual countries. In the USA, street signs should always be considered to be in English. There is no reason to tag them with any language in OpenStreetMap. English is the default. There are interesting questions, of course: El Camino Real is a common street name in California, and is obviously Spanish, so what is the correct English name? Is it The Royal Road? No, I don't think so; we would not want to translate this to create an American English name. The correct name in English is El Camino Real. The Spanish name has been adopted into English usage. Local English speakers would all say El Camino Real. These thoughts lead me to the Avenue des Champs-Élysées. Should we write Elysian Fields Avenue in English? No, of course not. Almost everyone has heard of the Champs-Élysées, and no-one would dream of writing the Elysian Fields. So should we be translating street names at all? My conclusion is that only countries with separate, major linguistic communities actually do this. Personally I'd like my map to say Hauptbahnhofstrasse and not Central Station Street, so I could find it on other maps and signs, or try to ask for it correctly in Solothurn. On the other two questions, I knew that the urban speed limits were all 25 mph, because this is the blanket limit in Oregon's urban areas, but when I tried to enter this it was rejected. I was allowed to enter 25, but I worried that Kort might think this was in km/h. Would it enter 25 km/h into OpenStreetMap if someone confirmed my response? Meanwhile I found all of central Portland's residential roads without speed tags in JOSM and set them to 25 mph. Finally the pub: I didn't know it! It still remains to be answered. Thank you for this interesting game, Peter On Tue, Jan 14, 2014 at 4:38 AM, Simon Poole si...@poole.ch wrote: From the talk mailing list (mandatory disclosure: yes I know the authors). Original-Nachricht Hi there, I'm very proud to announce that finally Kort[1] (the OSM game) writes back it's collected solutions to OSM! All changes are made by the OSM user kort-to-osm[2], so it's easy to track them. Our actions were coordinated with the local (Swiss) community and the Data Working Group (DWG). According to the Mechanical Edit Policy[3] all changesets have the tag mechanical=yes and the users profile page contains all relevant information about the project. With all the extra information in the changeset comment, we are able to trace back an edit through Kort and even further to its source. By the way, for most missions KeepRight[4] is the source. Until now we made over 280 changes. All changes were validated by at least 3 users. There are still lots of solved missions that are just waiting to be validated, so that we are able to finally provides them to OSM. The source code for kort-to-osm is available on GitHub[5], you are very welcome to open issues or provide pull requests. The underlying python library to access the OpenStreetMap API is osmapi[6]. ***Apart from this big step, Kort itself has some new features:*** - Upgrade to Sencha Touch 2.3 - now all major browsers are supported (IE, Firefox, Chrome, Safari) - Thanks to our new database server, we can provide missions in the USA as well (no more limits!) - Our homepage kort.ch is available in English, too :) Any remarks, comments, issues etc. are very welcome! Best regards Stefan [1] http://www.kort.ch/index_en.html resp. http://play.kort.ch [2] http://www.openstreetmap.org/user/kort-to-osm [3] http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy [4] http://keepright.at [5] https://github.com/kort/kort-to-osm [6] https://pypi.python.org/pypi/osmapi ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Oklahoma relations spreadsheet
Thanks, Mihh. Actually I'm interested in any road on which significant traffic incidents and slowdowns occur, including county roads and major named urban streets (OSM primary, secondary, and maybe tertiary). I've not heard of anyone planning to go down to those levels with route relations, but we might (one day) be able to generate them automatically in our proposed location database importer, if folks would be interested. If it happened, this would return (export) the assembled bot relations data to the OSM community. Peter On Mon, Jan 13, 2014 at 5:06 PM, Paul Johnson ba...@ursamundi.org wrote: On Mon, Jan 13, 2014 at 3:01 AM, Minh Nguyen m...@nguyen.cincinnati.oh.us wrote: NE2 was a fan of forward/reverse relation roles, so don't expect too many cardinal direction roles. Probably something to do with that's how relations are documented and that's what the tools are designed to work with. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Post cardinal directions using destination_ref=US 20:east on ramps and carriageways?
Paul, Good question. This discussion has become so complex now that we are all in danger of losing the plot. Perhaps a summary of options will help reach a breakthrough, or more likely leave us with all the options in use. :) The goal is to capture cardinal directional posting (N, S, E, W) on Interstates, US routes, other state routes, turnpikes, parkways, etc. Some are dual carriageways, some single carriageway, and some frequently alternate. Three methods have been suggested: 1. Where separate relations exist for each direction, we can tag (say) direction=south (e.g., on I-5 in Oregon) and we are done. One tag handles hundreds of ways. This is very efficient, so long as the carriageway's posted direction never changes, and if there are separate relations for each direction. 2. If only one relation exists for both directions, we can tag role=east or role=west on ways instead of role=forward. Not everyone likes this, but Telenav has been getting this done, and I for one applaud their initiative. Method #2 supports mixed single /dual carriageways, as well as routes that change posted direction at some point, but it's labor-intensive and hard to maintain/check. 3. Yesterday I suggested that we could tag the ways with posted direction using a new tag posted=US 20:west. Single carriageway roads would have posted:forward=US 20:east and we could infer the reverse posting except in very rare cases where it is weird (i.e., orthogonal). This would create many more tags but is simple and comes closer to the latest European use of destination=Berlin; destination_ref=A2. (Roads are not posted N, S, E, W outside of the Americas; destination is used instead.) If we use #1, it is simple and quick for many interstates, but it breaks down on alternating single/dual routes. It also breaks down if the route changes directional posting, as can happen on the corners of beltways. We could get around this by having separate relation pairs for each side of the beltway, 2+2+2+2=8, plus a parent, but mixed-single/dual routes are still a nightmare. The nightmare could all be solved by creating three relations for each mixed route, or more if it has directional posting turns, but these extra relations would take a lot of work. This would also undo recent and ongoing relation work in states that have created a single relation for each alternating single/dual state route. If we use #2, it is labor-intensive and hard to maintain. Also, it's so easy to flip the direction of single carriageway ways in iD , Potlach 2 and JOSM that unless the relation's directional roles auto-correct we would end up with a disintegrating big mess. At one time I liked this approach but having coded various routes I'm not so sure. It's very hard to do it right, and JOSM currently works much better with forward/backward roles. What I like about #3 is that it's actually the simplest way to go. Tag the signing of the ways on the ways, just as we should with signed destination=Los Angeles and destination_ref=1 10. What I especially like about this is that we can do it on the RAMPS, which are missing from relations. Nav and info systems need to know where the ramp goes. From Phoenix, an on-ramp could be posted=I 10:west to destination=Los Angeles. Or we could write destination:ref=I 10:west, destination=Los Angeles, at which point we are almost the same as Germany/The Netherlands. This idea I am now very much liking. Some people have argued that west is not a destination, which is why I'd suggested posted. Others say west is a direction, as in method #1 above, but then mappers would write direction=north for I-10 in Tempe AZ at Warner Road (where the E-W interstate runs due N-S). The UK uses THE NORTH (etc.) as a destination that comes even above super-primary towns on big blue and green signs. When UK comes to follow Germany (if that's possible), a northbound M6 sliproad at Preston might say destination=the north, destination_ref=M6. It's not identical to destination:ref=I 10:west, destination=Los Angeles, but it is at least a close cousin. I think it's time to start posting cardinal directions and destinations on ramps, and neither relations method (methods #1 or #2) can offer this. Currently US ramps are naked. They have no ref, no name, nothing to say what they do. Now the Dutch and Germans have signed off on destination and destination_ref, might it be time for the US to join in and sign its ramps and carriageways similarly? Peter On Mon, Jan 13, 2014 at 5:05 PM, Paul Johnson ba...@ursamundi.org wrote: On Sun, Jan 12, 2014 at 7:18 AM, Peter Davies peter.dav...@crc-corp.comwrote: We would post the cardinal directions using tags for each whole directional relation. However where the Muskogee Turnpike turns from E-W to S-N, or has some even more complex deal such as E +ve and N -ve, the 3-relation method will fail. We could further extend it by breaking the relations at the turns (strictly, at the directional posting
Re: [Talk-us] Relation member order/structure; best effort worth it?
I am very interested to see Paul Johnson's OK relation completion spreadsheet, as I'm trying to make a business decision on whether to use relations when importing OSM data into into our state DOT traffic information applications. These apps are neither navigation nor mapping, but share some characteristics with navigation in that we want to use OSM data to describe incident locations in plain English (or French, Spanish, German, ...) rather than travel directions in plain English, etc. For this we need the signposted cardinal directions in countries that follow AASHTO style route numbering practices with cardinal direction plates (North, South, East, West, or the same in French or Spanish). Mostly I believe these countries are in the Americas, though I'd love to hear from anyone who knows of other national or regional examples. From my viewpoint, a US crash is On OK 165 northbound at Chandler Road. Currently it looks (from the OK spreadsheet and from my own impressions elsewhere) as if state road relations are still too far from completion for use this year in operational public information systems. And on named, un-numbered urban arterials, no-one has even started to talk of creating route relations. Our OSM import algorithms will need to find all the OK 165 ways (or 44th Street, Phoenix ways) and assemble them automatically in an upstream to downstream order. We'd have to do that anyway in Europe and the rest of the world where no highway route relations exist, so it's probably the way we should go here in the Americas. Does anyone know if the Europeans (of which I'm one, oops) have any plans to create route relations? I have found none while in UK, NL, D, A, CH, I and F this past two weeks, but perhaps I didn't look hard enough. It may be possible for my proposed OSM importer to generate automated OSM relations as an output from that downstream sorting process, but perhaps that would spoil a lot of mappers' fun at weekends and evenings? We could also create automated relations for other countries, I suppose, but I'm not sure whether or not we should. I'd like to hear thoughts on this. We are still some months (or longer) away from reaching this capability, by the way, and don't even need to go there if you all hate the idea. We could just ignore OSM route relations and effectively create our own, internally, as we currently would have to in the other 80% of the world. Our relations would be ordered lists of ways, single track, with no branches or loops, in linear reference order. Does anyone want them (or not want them) exported back to OSM? Steve, you talk about manual v. automated sequencing of relations. I've experimented with JOSM ordering, most recently yesterday on Paul's Muskogee Turpike in OK, and previously in other states. The sequencing that emerges has not been particularly easy to understand. Sometimes a tiny branch way has been (in my view, wrongly) labelled with the state route ref, and the JOSM algorithm picks it as the start point for the whole route For me, a better algorithm would probably begin with the most southerly or easterly unconnected way and build a series of linked collections of ways sorted by typical US milepoint positive direction, S to N or E to W. Anyway as long as mappers can adopt any order they like for ways in relations, my OSM importer will have to make its own sort decisions to get the ways in topological (linear reference) sequence from end to end. Would you support rules or guidelines for preferred sequencing of way members of relations? What do we do with breaks, branches, loops, alternating single and dual carriageways, etc, etc.? My starting suggestion is that we use a sequence based on increasing linear references from 0.0 to the top end of the road, but that rule alone would not solve every situation. Paul, you don't like directional roles on the member ways of route relations, and I think your solution is to create three relations per route. I would call these directions positive (increasing linear reference, corresponding loosely with increasing milepoints), negative (the reverse) and both directions (the parent). We would post the cardinal directions using tags for each whole directional relation. However where the Muskogee Turnpike turns from E-W to S-N, or has some even more complex deal such as E +ve and N -ve, the 3-relation method will fail. We could further extend it by breaking the relations at the turns (strictly, at the directional posting changes), having maybe nine relations for a complete rectangular beltway (2 on each of the N, S, W, and E sides, plus a parent) but Martijn and Kristen Kam have wanted to avoid relation proliferation. This is why Martijn's firm (and OSM mappers) have adopted a hybrid system, as I understand it, using posted directions on roles for complex routes, and posted directions on directional relations for simple Interstates like I 5. Right now I don't think Talk-us has been able to solve the
Re: [Talk-us] Relation member order/structure: Why don't we do it in the road?
Andrew, I'm not so keen on route relations either. In my view they are duplicative, complex, confusing and costly to code. As a UK traffic engineer I'd much rather that my US State DOT clients dropped the practice of multi-banding many roads, so that each way would have one and only one definitive ref, as is the case in most other countries. Why? Drivers are not helped by sign clutter. It's a lot like texting. Messy signs are dangerous and distracting. The same is true for nav systems, info systems and maps. Less is more. Keep it simple. This is what the safety research shows. In practice most US states already use the first-posted route designator when fixing milepoints and motorway exit numbers, and I've asked OSM mappers to list this first in the way ref. Then the other signed and unsigned designators already follow for each way, using the infamous ;. Once that's been done, the relation carries almost no additional information. It doesn't even help us to assemble the ways as there is no consensus on the sequencing order of ways in the relation, for complex routes. Is there another way forward? Why don't we do it in the road? (Thank you, John Lennon.) A radical way to solve the ragged discussions of these past 3 months could be to put the posted cardinal direction on the way, as well as the ref(s). An example could be ref=US 202:east;ME 11:north;ME 17:north;ME 100:east replacing a relation at least 100 times longer, full of complex data structures that are highly prone to error. But here we violate the 1 tag, 1 value rule even more than at present. Another way to do it on the road could be ref=US 202 alt_ref:1=ME 11 alt_ref:2=ME 17 alt_ref:3=ME 100 This could satisfy those EU nations who hate the current US practice of packing multiple values into one. A bot could probably be written to unpack every US way ref tag and rewrite it in the form shown above. In many case it would be just ref=I 80 alt_ref=US 6. A major benefit would be to bring the US back into compliance with the rest of the world, for example with the A4 past Amsterdam's Schipol Airport, which has ref=A4 int_ref=E 19. There are already 914 alt_ref tags in use, worldwide. A US bot could swiftly make it millions. The relations labour of love could continue, but without holding up this year's system deployments. If we then took one extra step we could capture the posted cardinal directionality on the way as well: ref=US 202:east alt_ref:1=ME 11:north alt_ref:2=ME 17:north alt_ref:3=ME 100:east Oops, now I've upset all of Germany AND America. So how about ref=US 202 alt_ref:1=ME 11 alt_ref:2=ME 17 alt_ref:3=ME 100 posted:1=US 202:east posted:2=ME 11:north posted:3=ME 17:north posted:4=ME 100:east Posting route confirmation signs and junction signs is really a separate matter from route designation. German autobahns use destination=Berlin in the way that Americans use posted=US 202 east, so why try to combine all these separate functions into a single ref tag? For two-way roads like the Augusta, Maine, case (Western Avenue, off I-95), it *could *become: posted:forward=US 202 east posted:forward=ME 11 north posted:forward=ME 17 north posted:forward=ME 100 east posted:backward=US 202 west posted:backward=ME 11 south posted:backward=ME 17 south posted:backward=ME 100 west OK, so this is long, but very few ways are quad-banded. Also the backward posting can be inferred from forward in 99.9% of cases. It's only really needed if we have: posted:forward=Muskogee Turnpike south posted:backward=Muskogee Turnpike east which is *extremely *rare. I think Paul Johnson will let us know if he can definitely find it in Oklahoma. Time to get it done and just do it in the road? Peter On Sun, Jan 12, 2014 at 4:27 PM, Andrew Hain andrewhain...@hotmail.co.ukwrote: Peter Davies peter.davies@... writes: Does anyone know if the Europeans (of which I'm one, oops) have any plans to create route relations? I have found none while in UK, NL, D, A, CH, I and F this past two weeks, but perhaps I didn't look hard enough. Route relations for roads have occasionally be created in the UK but many mappers are not keen on them. http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.gb/6235 http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.gb/6731 Feel free to argue against from an international or any other viewpoint of course. -- Andrew ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Oklahoma relations spreadsheet
Paul This is really helpful in confirming to me that I can't use relations in my apps, as there are too many unfinished ones. Can anyone tell me if they know of anyone else with such a spreadsheet for any other states? Peter On Sun, Jan 12, 2014 at 5:56 AM, Paul Johnson ba...@ursamundi.org wrote: I'm working on an Oklahoma route relation spreadsheethttps://docs.google.com/spreadsheet/ccc?key=0ApYN6sJDLtUJdC10Qm1zWXVLMHoyanEwc1RULW5FUXcusp=sharingto get a better grip on working status of route relations in Oklahoma. Please let me know if you want edit access on it (ie, you're actively mapping Oklahoma) or if you happen to know the email address of other OK mappers. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
Paul, One of the things that Martijn and I agree needs to be possible is for routes to change directional posting part-way along. This commonly happens on beltways like that around Minneapolis St-Paul, that around Indie, and on AZ Loop 101 and 202 here in Metro Phoenix. For my part, I also feel we need to accommodate strange directional posting like N in one direction and E in the other, as you appear to describe on the Tulsa - Muskogee Turnpike. This is easy on fully divided highways like the Turnpike, as each directional way has its own role, even if both directions are in a single relation as you've coded for your area. I was excited to hear about N one way and E the other, as I've argued that we need to handle this on single carriageway, bi-directional ways, using (say) role=north;east. In this case north would be posted as OSM forward, and east as OSM backwards. If the Muskogee Turnpike actually were a single carriageway it would probably be better to code the ways role=east;north with OSM forward running from Tulsa to Muskogee and to the south beyond, because this is the increasing milepoint direction (according to Wikipedia). Martijn has shown how routes' ways can fairly quickly be reversed and made consistent in terms of OSM forward, and I've done some too (e.g., ID 21). This can simplify directional role posting on long single carriageway roads. Of course the M-TWP is not a single carriageway, so OSM forward actually runs in both directions, one on each carriageway, and the posting is simply role=east or role=north. But single carriageway semi-motorways and toll roads do exist, e.g., between Nara and Kyoto in Japan, or though the Japan Alps near Shirakawago, or around Interlaken in Switzerland, or through the Mont Blanc Tunnel between France and Italy. I've been lucky enough to drive each of these in the past three months in the course of my work, while thinking hard about OSM data structures. With this in mind I have coded three OK relations, one modified from yours for M-TWP northern section, one for the free TWP section posted as OK 165 (also modified from your work?) and a new one for M-TWP southern section (where no relation seemed to exist). I've set them up with increasing milepoint ways first, and reducing milepoint travel second. You will find the directional roles as I think they are actually posted on the ground. JOSM confirms that the ways are now in sequence in the three relations, using its little wiggly line in the relation analyzer. There is one break only in each relation, where we switch from one carriageway to the other. After a little legitimate research on Google's Streetview (not copying, but simply studying, as all good students should), so I concluded that the northern M-TWP section is not posted counter-intuitively, as I thought you'd indicated, but simply changes direction part way along. You may know better, and should of course improve on what I've guessed. My evidence is that the M-TWP on-ramp to Tulsa is posted West (not North) on westbound E Harris Road. So I assume it switches at that point from N-S posting to E-W posting. On eastbound E Harris Road I see the :free TWP on-ramp posted as South. This direction switch is what we might have guessed from the road's alignment. But what say you? Is the west/north posting truly inconsistent on M-TWP? Peter PS. TWP is the abbreviation used for Turnpike on some big green signs in New Jersey. The funny thing is that most English speakers don't include a W in that word, but in New Jersey apparently they do. I believe it should be pronounced Twurnpwike. On Sat, Jan 11, 2014 at 1:36 PM, Paul Johnson ba...@ursamundi.org wrote: I'm curious how this proposal works with roads like the northern section of the Muskogee Turnpike, which officially runs North towards Tulsa, and East towards Muskogee, the road's two terminii. On Fri, Jan 10, 2014 at 4:39 PM, Martijn van Exel marti...@telenav.comwrote: On Thu, Nov 21, 2013 at 1:27 AM, Chris Lawrence lordsu...@gmail.com wrote: For example: way X pointing east is marked in relation Y as east (presumably we could assume that east = forward and the opposite cardinal direction west is backward). User reverses way X. Now the relation role is potentially backward. JOSM seems to understand at least north/south and east/west and offers to fix it (see http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayTagCorrector.java ); no idea if iD or Potlatch do. We'd also need to make the validation tools smarter to recognize lossage (for example, realizing that the route is unbroken only if the chain of role tags once you account for the directions of the underlying ways is monotonic), Picking up on this old thread again. The status is now that iD partially supports the cardinal directions when reversing a way (it does not understand things like north:unsigned, not sure if that is easy to
Re: [Talk-us] Separate relations for each direction of US State highways.
Martijn, When you're dealing with a repeatedly mixed single/dual carriageway road, such as CA 78, the lack of a diagram in JOSM showing single/dual logic once you switch from role=forward to role=east (or west) soon becomes unbearable. In the end I gave up and created separate EB and WB relations so I could keep role=forward/backward on CA 78. You will see backward used in the westbound relation, because I made all the single carriageway ways OSM forward = eastbound. If JOSM can't be fixed, these bears (horribly mixed single/dual routes) will probably defeat us. I'm sorry that I can't offer any programming skills of my own to take on any of the required patches. Peter On Fri, Jan 10, 2014 at 11:39 PM, Martijn van Exel marti...@telenav.comwrote: On Thu, Nov 21, 2013 at 1:27 AM, Chris Lawrence lordsu...@gmail.com wrote: For example: way X pointing east is marked in relation Y as east (presumably we could assume that east = forward and the opposite cardinal direction west is backward). User reverses way X. Now the relation role is potentially backward. JOSM seems to understand at least north/south and east/west and offers to fix it (see http://josm.openstreetmap.de/browser/josm/trunk/src/org/openstreetmap/josm/corrector/ReverseWayTagCorrector.java ); no idea if iD or Potlatch do. We'd also need to make the validation tools smarter to recognize lossage (for example, realizing that the route is unbroken only if the chain of role tags once you account for the directions of the underlying ways is monotonic), Picking up on this old thread again. The status is now that iD partially supports the cardinal directions when reversing a way (it does not understand things like north:unsigned, not sure if that is easy to fix) JOSM understands 'north' as well as 'north:unsigned' (and the other cardinal directions of course) when flipping a way and offers to correctly fix the member role. Relation sorting does not seem to take the member role into account in JOSM, so that bit is not affected (or am I overlooking something?) The relation graph column in the relation editor does not recognize cardinal directions in the same way it recognizes forward / backward (with the dotted line display). The main thing I haven't looked into yet is the validation checks. Who knows which validation checks are run on relations in JOSM and/or iD to ensure 'unbroken-ness' and perhaps other things? -- Martijn van Exel OSM data specialist Telenav http://www.osm.org/user/mvexel http://wiki.openstreetmap.org/wiki/User:Mvexel http://hdyc.neis-one.org/?mvexel ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
Same thing that I did with OSM's I 35;I 80 around Des Moines, Iowa, correcting it to I 80;I 35 a few months ago. The exit numbers and mileposts confirm that this route has always been seen as I 80 by IADOT and Iowa State Patrol, since its first stretches were opened in 1958-59. http://www.iowadot.gov/50thpages/pdf/interstatemap.pdf This is the same 12-month period in which my dad took me for a drive on Britain's first motorway, the M6 Preston Bypass, on the week that it opened in 1959. I was 8 years old and already knew that I would build motorways. Later Sir James Drake (the project engineer) who was knighted for his motorway building, became my top boss at Lancashire County Council and sponsored my application to qualify as a Chartered Engineer. I remember him shaking my hand at the County Surveyor's annual dinner in 1973. Castle Rock has worked continuously with IADOT since 1985. When we first set up Iowa's Condition Acquisition and Reporting System (CARS) in 1998, we had treated the common section as I 35 (assuming a highest system, lowest number rule), and Iowa DOT staff asked us to correct this to I 80. It remains I 80 in Iowa's CARS system to this day. We use it all across the country as an example of a rule exception in discussions with other states. I 80 is the principal (i.e., first posted) Interstate route on the common section of these two roads. James and I seem to agree that such routes should be listed first in OSM's way ref tags in order to show their special significance. I don't think that this needs to be in any way controversial. It seems to me common sense that OSM should accurately reflect the road's signing details. Posting roads with their Highest system, lowest number route first is a good first approximation for armchair mapping, but it cannot be used to overrule facts on the ground. Peter Davies Castle Rock Associates Portland, Oregon On Sat, Dec 21, 2013 at 11:33 PM, James Mast rickmastfa...@hotmail.comwrote: I know awhile back I updated the ref tag on the short segment of I-77 that has I-74 cosigned with it from ref=I 74;I 77 to ref=I 77;I 74 because along that segment, they are using I-77's mile markers. Plus it helps to know that I-77 was there long before the two I-74 signs (one NB and one SB) were added along it. So, at least when it comes to Interstates with 2 or more Interstates posted on a segment, you should always put the one that the mile markers/exit numbers are based off of first in the way ref tag. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
I think it useful to spin off this topic from the long and still unfinished debate about directional roles in relations. I hope it can be agreed more quickly than the cardinal directional roles issue! The question is how to handle US roadway routes that are double, triple or even quad-banded, having multiple route designators. Some OSM mappers call this topic route overlaps. I might call it information overload. On most maps, renderers simply show ALL the shields. But is it helpful to have roads peppered with conflicting information about the route number? Who gains by knowing that Western Avenue, Augusta, Maine is US 202, ME 11, ME 17 and ME 100? Isn't this really confusing and unhelpful for most map users? Now, if it's confusing on a map, just think how confusing it is in a navigation system or a traffic event info system. Look out for a crash on US 202 eastbound / ME 11 northbound / ME 17 northbound / ME 100 eastbound (Western Avenue) in Augusta. We need to know which route designator is the most important one, and to use mainly or only that one when talking to drivers. This is not something that OSM needs to make up. The principal designator should the top shield, left shield or top-left shield on traffic signs. State DOTs and police also face this same problem, and every multi-banded route section in states with which I work already has an official principal designator. We need a way of capturing this in OSM for use in nav systems and info systems, as well as (perhaps) for ridding simple maps of route shield clutter. Martijn van Exel and perhaps others have suggested that we should use only relations to define route designators on ways, and not way ref tags. However I can't see how the relations alone can indicate this hierarchy of route designators on a way. As an example, let's look again at Augusta, ME, where Western Avenue is quad banded as US 202;ME 11;ME 17;ME 100. I've just listed these routes in the logical highest system, lowest number first sequence. I see that the current OSM way ref tag by the Senator Inn (just east of I-95) only says US 202, though I know from visits and from working with MEDOT that all four shields exist on the ground. The OSM relations currently include all four of the routes, but do not help us to prioritize the designators. To check out what MEDOT and the State Police think about Western Avenue's principal designator, I just logged into Maine's state CARS system (Condition Acquisition and Reporting System -- which we build and maintain for MEDOT here at Castle Rock) and it suggests that Western Avenue is top posted for MEDOT users as ME 100, not US 202. Of course I then looked at Google. No, I'm not going to copy it. But this is fair usage, I think, for research on this general problem. Google says Western Avenue is ME 100 or ME 11 on Streetview. But the Google Map shows all four shields. I currently believe that Western Avenue officially has ME 100 as its principal designator, and not the apparently higher classification US 202 route designation. However, the signs have US 202 at the top left of a square of four shields. So I personally I would continue to treat this road as principally US 202 in OSM, replacing the present way ref tags that say US 202 with US 202;ME 11;ME 17;ME 100. But in doing so I'd be adding to map clutter unless we build simple info systems that focus only on the first named (principal) route designator. I guess a more simple solution (always worth considering!) would be to use the way ref to show ONLY the principal (first) signed designator, and to cover the secondary route designations using the relations. This would avoid info info duplication between ways and relations (at least on multi-banded ways), and would automatically clear up map clutter of confusing shields on most OSM based maps. Those who care about all the secondary designations could get them from the relations. We could keep it simple and stupid for drivers. The way ref would convey only the Principal route designator. There are other examples of the idealized highest system, lowest number rule not being used. I 35 and I 80 north and west of Des Moines IA have the principal designator I 80, not I 35. I 80 determines the milemarkers and the exit numbers on this common section. Looking at the milemarkers (and exits, on freeways) is one way in which OSM mappers can determine the state DOT's principal route designator. Finally as an aside, I think the OSM (bad?) habit of missing off the US or I or ME classification in relation (but not the way) refs perhaps means we don't know that Western Avenue is US 202 (as against ME 202) unless we look at the way ref as well as the relation ref. Currently I don't think the relation ref alone can tell us the type of shield on which the route number is written. I believe it would be better if relation refs and way refs were written consistently, as US 202 (etc.) and not just 202 as we currently see in
Re: [Talk-us] Separate relations for each direction of US State highways.
Last night I wrote a long discussion of why I think we need to show the cardinal directions of both OSM forward and OSM backward for 2-way ways that serve both route directions in relation member roles. In particular I argued for the use of two different symbols for two use cases: one where the tag value is compound, like east:unsigned or north:express, and the other where there are two values to convey, e.g., east;west meaning OSM forward on this way is posted east and OSM backward on this way is posted west. On further reflection, I think Martijn's pipe symbol example for an ordered list of lane speeds, e.g., 60|60|40 across Lane 1, Lane 2, and Lane 3, also applies to my wish to show the posted cardinal direction on a 2-way single carriageway. Thus, east|west would mean that the OSM forward direction lanes are posted East and the OSM backward direction lanes are posted West. Combined with the use of the colon for compound values, we would have examples like east:unsigned|west:unsigned north|south:unsigned north|east The two symbols are visually distinctive for human readers, and this also would continue the practice of using the pipe symbol to represent lanes or sets of lanes on a roadway. On the Kennedy Expressway (I 90;I 94) out of Chicago, I think the three carriageway roles might be east reversible:east|west This would indicate that OSM foward serves as east at times, and ODM backward serves at other times as west. west Currently the median express lanes are coded with roles reversable. If the central carriageway ways were to use OSM forward as westbound, I would suggest that they should ideally be swapped around, or otherwise coded as reversible:west|east. Earlier I had conflated the Ike / Eisenhower Expressway (I 290) with the Kennedy Expressway (I 90;I 94). Sorry. Peter On Wed, Dec 18, 2013 at 1:46 PM, Wolfgang Zenker wolfg...@lyxys.ka.sub.orgwrote: Hi, * Martijn van Exel m...@rtijn.org [131218 20:46]: I am having second thoughts on the colon separator for role=north:unsigned. The colon separator seems to be more common in keys, like lanes:forward=2, lanes:backward=2 etc. while the semicolon or pipe seem to be more prevalent to separate values. The pipe character seems to be more widely used when there is an ordered set of elements, like lanes:maxspeed=40|60|60 to indicate speed limits for lanes 1,2,3 respectively, whereas the semicolon seems to be used as a more generic separator like destination=Salt Lake City;Reno. (Even there you could argue that there is an ordering, the first element would appear first on the sign, the second one below that.) So I changed the wiki http://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States to reflect this and propose the semicolon approach: role=north;unsigned. OK? the semicolon is usually the separator that you use if you have several unrelated values that unfortunately share the same key; I would interpret role=north;unsigned as 'this object has both the tags role=north AND role=unsigned'. I recommend staying with the colon approach, because we don't want to express two separate independent roles but the role north which happens to be of the unsigned version in this object. Wolfgang ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
Eric Perhaps it would be ok still to code these few exceptions that are known equally by two route designators as US 1;US 9 in NJ or US 12;US 18 in WI, but to simplify the vast majority of routes where the secondary banding is less important? My aim is to announce traffic problems the way the locals do it. If they call it the 1-9 or the 12-18, that's fine with me. We could also add that as an alias (an OSM name) if it's widespread. As you say, for the INDOT 511 system (another of my concerns), on I 465 we could safely skip US 31, US 36, US 40, US 52, IN 67, US 421, etc. It could go either way on I 465;I 74 across the south side of the Indie Beltway, depending on local practices. The nice thing about this proposal is that the exceptions can still be allowed in the rare cases where they apply. I find that listening to radio station traffic messages is a great way to discover how people name roads. Here in Portland, OR, I 84 between I 5 and I 205 is invariably called the Banfield or Banfield Expressway by OPB, etc. It is never, ever called US 30 or I 84;US 30 (Banfield Expressway) Peter On Sat, Dec 21, 2013 at 12:52 PM, Eric Fischer e...@pobox.com wrote: This would match how people usually talk about things like I-465 around Indianapolis, ignoring all the other routes that are also routed along it, but it doesn't work quite so well when there are co-signed routes that persist for long distances where people refer to the paired name. I think Highway 1-9 in New Jersey, which is both US 1 and US 9, is the main example, but Highway 12-18 in Madison, WI (US 12 and US 18) also comes to mind. Eric On Sat, Dec 21, 2013 at 12:21 PM, Peter Davies peter.dav...@crc-corp.comwrote: A further thought in favor of using the way ref tag simply to indicate the principal route designator, leaving any multi-banded secondary routes that share the way to be defined only in the relations, is that we would be making the US more consistent with road numbering and mapping practices in other countries. In the UK, for example, multi-banding does not occur because the Department of Transport allows numbered roads to have breaks (gaps) where they follow other routes. For example, the M62 from Liverpool to Leeds and Hull no longer exists across the Manchester M60 Ring Motorway section. Drivers follow M62 from Liverpool, then take the Manchester Ring Road M60, and then pick up the M62 again across the Pennines to Leeds and Hull. In a similar example on the primary route system, the A49 joins with the A5 around the Shrewsbury bypass, and then separates and strikes off north again after a few miles. This approach is universal in the UK, and is also standard practice in many other countries. In the UK and elsewhere, the shared section is identified by a single principal route designator. Important secondary UK designations can be shown on green primary route signs, e.g., Oswestry A5; Leominster (A49). This is interpreted as A5 changing to A49 for Leominster. On UK maps of all kinds, only A5 is marked on the common section. Thus, OSM currently tags ways on the common section simply with ref A5. We could do the same here in the US if we swapped out US 202;ME 11;ME 17;ME 100 for just US 202 in the way ref. (As it happens, only US 202 IS currently coded on Western Avenue in Augusta, and perhaps we should leave it that way?) I believe that US state DOT practices of multi-banding might be made more user friendly if we could focus on the principal designated route in the way ref tag. It doesn't really help many drivers to know that I 80 in parts of Wyoming is also US 30. My thoughts are that the Interstate system rightly swamps out noise from older transcontinental routes that have little travel significance in the 21st century. It could be that these secondary sign shields are an unwarranted expense that may gradually fade away. But those who still want to show secondary banding would be able to do so using the route relations. We would also be eliminating the practice of cramming multiple data elements into a single tag. Personally I'm not a purist about such things, but I've seen some people shudder at the current U.S. way ref tag practices of listing route refs one after another in a single data field. Peter On Sat, Dec 21, 2013 at 10:46 AM, Peter Davies peter.dav...@crc-corp.com wrote: I think it useful to spin off this topic from the long and still unfinished debate about directional roles in relations. I hope it can be agreed more quickly than the cardinal directional roles issue! The question is how to handle US roadway routes that are double, triple or even quad-banded, having multiple route designators. Some OSM mappers call this topic route overlaps. I might call it information overload. On most maps, renderers simply show ALL the shields. But is it helpful to have roads peppered with conflicting information about the route number
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
Kerry You are right, of course, and those of us who make our living out of building such systems have to compromise continually between the needs of locals and the needs of visitors. Now that Apps are gradually replacing 511 web sites and phone systems we are personalizing traffic reports more and more. Users who share their current locations as well as their home and office locations can theoretically be given tailored location descriptions that emphasize local names and cross-streets (near to home) or what I call fuzzy locations such as on ID 21, 20 miles north of Idaho City when they are far away. Handling that, though, is mainly our problem, and that of our competitors. We typically like to have route numbers and aliases like I 290 (Eisenhower Expressway) to serve both user groups. But we typically need one key route number, and not many. No-one wants to hear that I 465 is also US 31, US 36, US 40, US 52, IN 67, US 421, etc. Perhaps some people want to know that part of it is also I 74. My proposal doesn't take away any ref information (as it's all in the relations); it just helps us know what is the most important route designator (say, I 465). It's also perfectly fine if we want to keep all of the secondary designators in the ways' ref tags, as long as the most important one is presented first. We can easily ignore the less important numbers. But without a way ref (i.e., using only relation refs, as has been suggested) we have no way of knowing what is the most common route designator for that specific way. Peter On Sat, Dec 21, 2013 at 2:00 PM, Kerry Irons irons54vor...@gmail.comwrote: There is a problem with this approach in that the locals might describe it one way and visitors, with no local knowledge, will stick with route numbers. When I visit Chicago I get confused by traffic radio because I don't know the freeway names but I have no trouble navigating by map as long as the route numbers are shown on the map. Highway signage leans much more heavily toward route numbers than names, and often show the multiple route numbers. This is particularly key when someone is following a route number to some more distant destination. When a map doesn't indicate that there are multiple routes on the same piece of pavement it can be confusing to outsiders trying to navigate through an area. Kerry Irons -Original Message- From: Peter Davies [mailto:peter.dav...@crc-corp.com] Sent: Saturday, December 21, 2013 4:45 PM To: Eric Fischer Cc: Martijn van Exel; Richard Welty; OSM US Talk Subject: Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept Eric Perhaps it would be ok still to code these few exceptions that are known equally by two route designators as US 1;US 9 in NJ or US 12;US 18 in WI, but to simplify the vast majority of routes where the secondary banding is less important? My aim is to announce traffic problems the way the locals do it. If they call it the 1-9 or the 12-18, that's fine with me. We could also add that as an alias (an OSM name) if it's widespread. As you say, for the INDOT 511 system (another of my concerns), on I 465 we could safely skip US 31, US 36, US 40, US 52, IN 67, US 421, etc. It could go either way on I 465;I 74 across the south side of the Indie Beltway, depending on local practices. The nice thing about this proposal is that the exceptions can still be allowed in the rare cases where they apply. I find that listening to radio station traffic messages is a great way to discover how people name roads. Here in Portland, OR, I 84 between I 5 and I 205 is invariably called the Banfield or Banfield Expressway by OPB, etc. It is never, ever called US 30 or I 84;US 30 (Banfield Expressway) Peter On Sat, Dec 21, 2013 at 12:52 PM, Eric Fischer e...@pobox.com wrote: This would match how people usually talk about things like I-465 around Indianapolis, ignoring all the other routes that are also routed along it, but it doesn't work quite so well when there are co-signed routes that persist for long distances where people refer to the paired name. I think Highway 1-9 in New Jersey, which is both US 1 and US 9, is the main example, but Highway 12-18 in Madison, WI (US 12 and US 18) also comes to mind. Eric On Sat, Dec 21, 2013 at 12:21 PM, Peter Davies peter.dav...@crc-corp.com wrote: A further thought in favor of using the way ref tag simply to indicate the principal route designator, leaving any multi-banded secondary routes that share the way to be defined only in the relations, is that we would be making the US more consistent with road numbering and mapping practices in other countries. In the UK, for example, multi-banding does not occur because the Department of Transport allows numbered roads to have breaks (gaps) where they follow other routes. For example, the M62 from Liverpool to Leeds and Hull
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
Tod, I found a common stretch of CA 108 and CA 120 between Oakdale and Yosemite Junction in Tuolumne County. I'm not sure if that's the double-banded section you mention. As Eric Fischer said, there are some ways that carry two approximately equal routes, and my suggestion was that they would both still feature in the way ref tags, in this case CA 108;CA 120 (which is in fact what OSM currently has for these ways). I agree that there is no obvious precedence order in this case other than highest system, lowest number (which is again what OSM has at present). My suggestion was (and is) that if we need to have multiple refs, because two or more routes are about equal, the way refs be listed in shield posting order, starting with the top or left-most shield. Without going there, we won't know if that is CA 108 or CA 120, or whether it varies. Since both are about equal it probably doesn't matter, because (as you say) both should probably be mentioned. My interest was more in what Shawn Quinn calls rubbish numbers, such as US and state route refs multi-banded on an interstate. I think he argues that we need them all. I don't think that's in doubt, either. But do we need them all to be listed in every way ref, or would it be sufficient to have them in the relation refs, with the first listed shield(s) emphasized in the way refs? I think the answer is already emerging. Way ref tags with complete lists of overlapping secondary route designators are here to stay. Personally I'm happy about this so long as the first signed route number(s), starting from the top and/or left of the direction signs and route confirmation signs, come first in the way ref lists (as they usually do in OSM already). So, I 465 should be listed before US 31, or IN 67, say, as it's given greater precedence in the signing. In other words, most people probably think that Interstate 465 is Interstate 465, and not US 31 or IN 67. So we should list it first (as we almost always do). Sound fair? Peter On Sat, Dec 21, 2013 at 4:37 PM, Tod Fitch t...@fitchdesign.com wrote: On Dec 21, 2013, at 2:35 PM, Peter Davies wrote: Kerry snip It's also perfectly fine if we want to keep all of the secondary designators in the ways' ref tags, as long as the most important one is presented first. We can easily ignore the less important numbers. But without a way ref (i.e., using only relation refs, as has been suggested) we have no way of knowing what is the most common route designator for that specific way. Peter There may be no most common route designator. A semi-local example: If I am directing you east over Sonora Pass I'll tell you to go east on CA 108. If I direct you to Yosemite I'll tell you to go east on CA 120. But for a number of miles they are the same road with dual signage with no obvious method of tell which one is the most common designator. (You can probably tell what the road officially is by looking at the very cryptic and hard to read version of a mile/information posts that CalTrans uses but most motorists never notice them and if they do they are very difficult to read or decipher without stopping.) Some of your examples are in areas I am not familiar with. But in both the San Francisco Bay Area and Los Angeles there are named freeways. I notice that in the Bay Area the name is almost never used whereas in LA it seems both are used with the name being more common. In either case I'd expect the name key to specify the name and the ref to specify the route number. How you decide that a local would be more likely to use the name (LA) or the ref (SF) I haven't the fainted idea. Tod ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept
Kerry I'm not sure that I follow your drift here, Kerry. Can you elaborate about the Miracle Mile? Peter :) On Sat, Dec 21, 2013 at 6:45 PM, Kerry Irons irons54vor...@gmail.comwrote: All, If you look at the guidance in the US from FHWA and the MUTCD, all route numbers are to used in signage. You never know who is using a given piece of pavement by following which route number. Just because the locals might call it “the Miracle Mile” doesn’t mean that is the appropriate choice for shield priority. Kerry *From:* Peter Davies [mailto:peter.dav...@crc-corp.com] *Sent:* Saturday, December 21, 2013 8:53 PM *To:* Tod Fitch *Cc:* Kerry Irons; Martijn van Exel; OSM US Talk; Richard Welty; Eric Fischer *Subject:* Re: [Talk-us] Prioritizing multi-banded route designators (multiple overlaps) on ways: the Principal route designator concept Tod, I found a common stretch of CA 108 and CA 120 between Oakdale and Yosemite Junction in Tuolumne County. I'm not sure if that's the double-banded section you mention. As Eric Fischer said, there are some ways that carry two approximately equal routes, and my suggestion was that they would both still feature in the way ref tags, in this case CA 108;CA 120 (which is in fact what OSM currently has for these ways). I agree that there is no obvious precedence order in this case other than highest system, lowest number (which is again what OSM has at present). My suggestion was (and is) that if we need to have multiple refs, because two or more routes are about equal, the way refs be listed in shield posting order, starting with the top or left-most shield. Without going there, we won't know if that is CA 108 or CA 120, or whether it varies. Since both are about equal it probably doesn't matter, because (as you say) both should probably be mentioned. My interest was more in what Shawn Quinn calls rubbish numbers, such as US and state route refs multi-banded on an interstate. I think he argues that we need them all. I don't think that's in doubt, either. But do we need them all to be listed in every way ref, or would it be sufficient to have them in the relation refs, with the first listed shield(s) emphasized in the way refs? I think the answer is already emerging. Way ref tags with complete lists of overlapping secondary route designators are here to stay. Personally I'm happy about this so long as the first signed route number(s), starting from the top and/or left of the direction signs and route confirmation signs, come first in the way ref lists (as they usually do in OSM already). So, I 465 should be listed before US 31, or IN 67, say, as it's given greater precedence in the signing. In other words, most people probably think that Interstate 465 is Interstate 465, and not US 31 or IN 67. So we should list it first (as we almost always do). Sound fair? Peter On Sat, Dec 21, 2013 at 4:37 PM, Tod Fitch t...@fitchdesign.com wrote: On Dec 21, 2013, at 2:35 PM, Peter Davies wrote: Kerry snip It's also perfectly fine if we want to keep all of the secondary designators in the ways' ref tags, as long as the most important one is presented first. We can easily ignore the less important numbers. But without a way ref (i.e., using only relation refs, as has been suggested) we have no way of knowing what is the most common route designator for that specific way. Peter There may be no most common route designator. A semi-local example: If I am directing you east over Sonora Pass I'll tell you to go east on CA 108. If I direct you to Yosemite I'll tell you to go east on CA 120. But for a number of miles they are the same road with dual signage with no obvious method of tell which one is the most common designator. (You can probably tell what the road officially is by looking at the very cryptic and hard to read version of a mile/information posts that CalTrans uses but most motorists never notice them and if they do they are very difficult to read or decipher without stopping.) Some of your examples are in areas I am not familiar with. But in both the San Francisco Bay Area and Los Angeles there are named freeways. I notice that in the Bay Area the name is almost never used whereas in LA it seems both are used with the name being more common. In either case I'd expect the name key to specify the name and the ref to specify the route number. How you decide that a local would be more likely to use the name (LA) or the ref (SF) I haven't the fainted idea. Tod ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
carriageway bypasses / ring roads / beltways in the US, and even more so in other parts of the Americas (Canada; Central and South America) where I believe that AASHTO signing practices are widely emulated. I was in Argentina three years ago at the end of the Pan American Highway in Tierra del Fuego and I'm pretty sure that I saw RN 3 plated with norte (there is no sur until Buenos Aires extends RN 3 onto the Antarctic Peninsula). Its not hard to find pictures of the sign nearby that says Alaska 17,848 kilometers. When I lived in Leesburg, VA, in the late 1980s, the US 15 and VA 7 bypass was single carriageway, and (though now dual) still run in a square around 3 sides of the town. I believe that even the US must still have single carriageway bypasses and ring roads in deeply rural areas, and that somewhere on a single carraigeway, east-west must switch to north-south in a way that isn't neat and tidy. Too unusual to worry about? Perhaps. But for those of you who who care about east|unsigned, can you imagine a state posting east|unsigned;west or north|unsigned;south on a single carriageway rural state highway? I sure can. State maintenance folks are human, and consistency is a goal never wholly achieved. I also advocate using roles of north;south on single carriageway roads because mixed single/dual roads are common in rural America, and they are very hard to understand (humans again) if you post the dual ways north and south and the single carriageway ways just north or south depending on the orientation of the ways' OSM forward. It is hell to check when you do this, especially in iD or Potlach. JOSM makes relations visual (or at least it will when cardinal directions are treated like forward and backward) and after a JOSM sort I can now fill in north, south, north;south and south;north just by staring intently at the JOSM line and arrow diagram (at least I can in the armchair sense; finding what the road crew actually signed would take a great deal longer). If you use north;south on single carriageways, the single carriageways leap out at you when you check the relation manually. If you use north and south to mean very different things on single carriageway ways than on dual carriageway ways, it is very hard to see whether it makes any sense or not. Not all mappers can use JOSM (I couldn't until I spent the last 3 weeks coding various mixed single/dual carriageways in ID, MN and San Diego County instead of arguing this from common sense alone) and in iD/Potlach it's a whole lot easier to see what is happening if you code single carriageways to reflect each of the two travel directions that they carry. Here I rest my case for the use of the pipe character for east|unsigned and the semi colon for east;west or east|unsigned;west|unsigned on single carriageways. Martijn, can I be allowed to change the wiki page once again while overeating this Christmas, should I have the time? It could be my present to myself ... Peter Davies Castle Rock Associates, Portland, OR S On Thu, Dec 19, 2013 at 10:16 PM, Saikrishna Arcot saiarcot...@gmail.comwrote: I, personally, am in favor of using the colon rather than the semicolon, for the reasons Martijn outlined a few emails back. Saikrishna Arcot On Thu 19 Dec 2013 03:23:53 AM IST, James Mast wrote: I have no problems going with either : or ; for the separator for unsigned segments of highways in the role area. What does everybody else think? As this shouldn't be decided by just two people. We do still need the consensuses of [talk-us] before any mass changing of relations happen. Later tonight if I have time I'll do up an example route for this (US-19 Truck here in Pittsburgh) so everybody can see this in action at least and then we can link an example to the wiki page. The reason I selected the route above is because not only is it a short route, it does have it's middle segment hidden while on Interstates. Plus I have tons of experience with it having traveled it a lot in my life. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
Martijn I just wrote a short novel on why I think we should use obviously different cardinal direction roles on single carriageway roads than on dual carriageway ways, and so I'll not repeat myself here. Peter On Sun, Dec 15, 2013 at 10:27 PM, Martijn van Exel m...@rtijn.org wrote: James, all, Work on JOSM is underway, and should be finished by the end of this week. I don't think I fully understand what you're trying to convey about the local/express lanes, but I think we should ensure that both JOSM and iD support cardinal directions with any :extension. I did make significant edits to the wiki page to capture the discussion and move ambiguous parts out of the way, but the north;south bit is not mine and I actually don't think it's a great idea - can't we just have role=north being concurrent with the OSM way direction? Or is that an oversimplification? Martijn On Sat, Dec 14, 2013 at 4:41 AM, James Mast rickmastfa...@hotmail.com wrote: Looks good to me Martin. I'm game with the role = north:unsigned tagging for unsigned segments. Now all we would need to do is get JOSM to show the cardinal directions the same way in the relation editor like forward/backward so that you can verify a route is all there and there are no gaps (unless there is one for real like I-49 currently has in LA since they are extending it). And on this subject it brings up an interesting problem. What to do when a highway has C/D lanes that are part of the main highway (like the 401 in Toronto, Ontario, Canada). I know a few Interstates have these, like I-80 I-95 in NJ. There should be a way to have something like role = east:express role = east:local in a directional relation (I fully support Interstates to have separate relations for each direction on 2di's; but on 3di's they should stay one relation unless it's like a 30+ mile route like I-476/I-376 here in PA) and have JOSM's relation editor show a split in the highway so you can verify there are no gaps in those areas for the relation. Also, I have noticed you've been doing some editing for the Highway Directions In The United States wiki page [1] and mention the role = north;south idea for single carriageways so that the routes could tell people which direction the way goes. I think that might still need a little more discussion here on [talk-us] before we attempt to implement it and mention it on that page (maybe have a vote for that part on the talk page??). I personally think it could work, but we would need all of the editors (JOSM, iD, Potlatch2) to have support to be able to reverse those roles correctly if somebody reverses the way. Can't allow those to get messed up once added. (On a side note, iD doesn't alert you if you delete a way that's part of a relation yet, which isn't good at all.) -James From: m...@rtijn.org Date: Tue, 10 Dec 2013 18:16:54 -0800 To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Separate relations for each direction of US State highways. Hmm yes, on second thought, a second key on role members may not be so straightforward ;) How silly of me to suggest such a thing. Let's keep things pragmatic then and let me suggest we go with role=north:unsigned for unsigned sections. I don't particularly like the ; because it suggests a list of things that are of similar nature (like apple;pear;mango) whereas a colon to me suggests a further scoping which is what this is. So role=north / role=west / role=south / role=east for relation members to indicate cardinal directions, and role=north:unsigned / role=west:unsigned / role=south:unsigned / role=east:unsigned for unsigned segments, unless the entire numbered route is unsigned, in which case unsigned_ref would do the job. Any more insights and comments? Thanks Martijn On Fri, Dec 6, 2013 at 5:31 PM, James Mast rickmastfa...@hotmail.com wrote: Well, to add a second role to an item in a relation would require an entire overhaul of relations, the editors, and even the OSM database I would think to do it. That's why I suggested doing the ; or | because data consumers already know how to deal with the ; at least in the ref tags on normal ways (look @ Mapquest Open and their rendering of highway shields based off the ref tags on ways). Heck, maybe even a : might work (role = north:unsigned). -James From: m...@rtijn.org Date: Thu, 5 Dec 2013 23:01:09 -0700 Subject: Re: [Talk-us] Separate relations for each direction of US State highways. To: rickmastfa...@hotmail.com On Thu, Dec 5, 2013 at 6:17 PM, James Mast rickmastfa...@hotmail.com wrote: Martijn, How would you suggest using the role:signed = yes/no (or is this just for completely unsigned highways like I-124 in TN where we can add this info
Re: [Talk-us] Separate relations for each direction of US State highways.
Martijn, Roads like I 394 west of downtown Minneapolis have several miles of collector-distributor lanes (separate carriageways running parallel to the main motorway carriageways) in each direction whose purpose is to handle slower entering and leaving traffic without creating dangerous short weaving sections between closley spaced intersections The Highway Capacity Manual is the world's bible on this subject. Sorry if I'm teaching my grandma how to suck eggs, as we say in one country or other that I sometimes inhabit. In OSM we show these are motorway_link, like ramps. Therefore they do not have route designators (ref tags on the ways). Roads like the New Jersey Twp approaching NYC and (on a less dramatic scale) parts of the Ike in Chicago (Eisenhower freeway, I 90;I 94) have entire carriageways or sets of physically separated lanes running parallel to one another, each of the four carriageways perhaps (last time I was in NJ) having 3 directional lanes and one or two shoulders. So there could be two northbound motorway carriageways and two southbound. The outer carriageways are designated Local and the inner carriageways (with fewer exits) are designated Express. I 5 through downtown Seattle also has elevated carriageways designed Express as I recall. The surface level lanes (or in deep cuttings) are Local. The Autoroute A6 entering Paris has the same thing after A6 and A10 merge until A6 (and implicitly A10) reaches the Boulevard Peripherique. These parallel roadways are called A6a and A6b. In the States, they are termed nearly always Express and Local (though I think I've seen other naming too, but I'm not sure where). Sorry if you knew all of this already. I guess the idea would be that the directional roles will be north|express or north|local, etc. I hope that this was helpful ... oops. :$ Peter On Sun, Dec 15, 2013 at 10:27 PM, Martijn van Exel m...@rtijn.org wrote: James, all, Work on JOSM is underway, and should be finished by the end of this week. I don't think I fully understand what you're trying to convey about the local/express lanes, but I think we should ensure that both JOSM and iD support cardinal directions with any :extension. I did make significant edits to the wiki page to capture the discussion and move ambiguous parts out of the way, but the north;south bit is not mine and I actually don't think it's a great idea - can't we just have role=north being concurrent with the OSM way direction? Or is that an oversimplification? Martijn On Sat, Dec 14, 2013 at 4:41 AM, James Mast rickmastfa...@hotmail.com wrote: Looks good to me Martin. I'm game with the role = north:unsigned tagging for unsigned segments. Now all we would need to do is get JOSM to show the cardinal directions the same way in the relation editor like forward/backward so that you can verify a route is all there and there are no gaps (unless there is one for real like I-49 currently has in LA since they are extending it). And on this subject it brings up an interesting problem. What to do when a highway has C/D lanes that are part of the main highway (like the 401 in Toronto, Ontario, Canada). I know a few Interstates have these, like I-80 I-95 in NJ. There should be a way to have something like role = east:express role = east:local in a directional relation (I fully support Interstates to have separate relations for each direction on 2di's; but on 3di's they should stay one relation unless it's like a 30+ mile route like I-476/I-376 here in PA) and have JOSM's relation editor show a split in the highway so you can verify there are no gaps in those areas for the relation. Also, I have noticed you've been doing some editing for the Highway Directions In The United States wiki page [1] and mention the role = north;south idea for single carriageways so that the routes could tell people which direction the way goes. I think that might still need a little more discussion here on [talk-us] before we attempt to implement it and mention it on that page (maybe have a vote for that part on the talk page??). I personally think it could work, but we would need all of the editors (JOSM, iD, Potlatch2) to have support to be able to reverse those roles correctly if somebody reverses the way. Can't allow those to get messed up once added. (On a side note, iD doesn't alert you if you delete a way that's part of a relation yet, which isn't good at all.) -James From: m...@rtijn.org Date: Tue, 10 Dec 2013 18:16:54 -0800 To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Separate relations for each direction of US State highways. Hmm yes, on second thought, a second key on role members may not be so straightforward ;) How silly of me to suggest such a thing. Let's keep things pragmatic then and let me suggest we go with role=north:unsigned for unsigned sections. I
Re: [Talk-us] Separate relations for each direction of US State highways.
Martijn, While spending the last three weeks comparing different methods of defining cardinal directions in member roles, I noticed that iD makes it hard to see which direction on a way is currently OSM forward. Potlach makes it easy, once you grasp what the arrow shows. JOSM does it less intuitively, but only if you have very sharp eyesight for tiny line and arrow diagrams. When in iD I found myself turning on oneway=yes just so I could easily see which way was forward, and then turning it off again. It's ok as long as you remember to do it (turn it off with two clicks); otherwise it's very bad news. In the end I avoided iD and used Potlach to reduce this risk. iD is an accident waiting to happen for people (like me) who are tempted to play this questionable game. I've no clue how to change iD, sorry, or even to ask that a change be made, but if there were a way of making the symbol rotate so that it showed the user OSM forward, as does Potlach 2, it would be awesome. Potlach 2 is of course easier to mess up in other ways, so an enhanced iD would be safer when people like me try to implement your idea that all the single carriageway ways on a route should be fixed so that they have OSM forward pointing in the same direction. (In my world, that direction should be the positive direction in which milepoints ought to increase, i.e., eastbound or northbound.) I fixed several routes in ID, MN and San Diego County as you suggested, and it's tidier when done and directional roles are assigned. However, I realized that occasionally it's impossible to do, at least in my world where OSM forward should also be route designator positive (increasing) milepoint direction. A two-way way can be eastbound and southbound on two different routes; or it can be northbound and westbound. One route requires it to point one direction, and the other, the opposite. So the rule can never be absolute. Nevertheless I like your scheme of aligning all the ways of a route so that the single carriageways' OSM forward all align with (hopefully) the route's eastbound or northbound direction. In most cases it can be done and it certainly makes it easier to see if a relation has all its cardinal roles correctly defined. Of course it's easier still to check mixed routes when single carriageways can be clearly distinguished from dual carriageway ways; but you've heard me on that topic already. Peter On Thu, Dec 5, 2013 at 10:06 PM, Martijn van Exel m...@rtijn.org wrote: Another update on this: following James's earlier suggestion that we needed editor support for the n/s/e/w roles with way direction reversal and (in the case of JOSM) the relation editor, I got some dev time at Telenav to get the necessary JOSM patches done. I already submitted the iD patch myself (which should be live by now). On Thu, Dec 5, 2013 at 11:04 PM, Martijn van Exel m...@rtijn.org wrote: Ways are objects in their own right, so they can have tags, but members only exist as a reference on a relation, so there is not really a model for tags on members. On Thu, Dec 5, 2013 at 6:44 PM, Kam, Kristen -(p) krist...@telenav.com wrote: Hi All: I have a question: Why can’t there be member tag values? There are tag values for ways, so why not members? Just a thought. Best, Kristen --- OSM Profile à http://www.openstreetmap.org/user/KristenK From: James Mast [mailto:rickmastfa...@hotmail.com] Sent: Thursday, December 05, 2013 5:18 PM To: Martijn van Exel Cc: talk-us@openstreetmap.org Subject: Re: [Talk-us] Separate relations for each direction of US State highways. Martijn, How would you suggest using the role:signed = yes/no (or is this just for completely unsigned highways like I-124 in TN where we can add this info into the main tags of the relation)? We would still need a way to keep the direction for the unsigned segment of the route in the role so that the relation editor in JOSM (and other analyzers) would be able to know that the route is still going North/East or South/West, especially on a dual-carriageway (like what happens with US-52 on I-94 in MN and US-19 Trunk on I-279/I-376 here in Pittsburgh, PA) and would let you know it's still in one piece. If you don't like the | separating the role = north|unsigned, maybe use the ; or , instead? I could see the ; working just as good as the |. I just want to find a solution to keep the route all in one piece instead of having to have two separate relations for it's signed segment and one covering the entire route with the unsigned_ref tag. Annoying and easily broken by new users who don't know why there are two relations for the exact same route on some segments. -James From: m...@rtijn.org Date: Thu, 5 Dec 2013 09:25:11 -0700 To: rickmastfa...@hotmail.com CC: talk-us@openstreetmap.org Subject: Re: [Talk-us] Separate relations for each
Re: [Talk-us] Separate relations for each direction of US State highways.
James, I have a question about this, though it all sounds good to me in principle. Is your proposal just about the relations? What would we do on the refs of the ways? For example, on I-394 in Minneapolis and western suburbs, a mapper has left off US 12 because it is at least partly unsigned. So we have way ref I 394 instead of I 394;US 12. For my applications I'd prefer it said I 394;US 12, because we need to track the overlaps (which we and our 10 state DOT customers call double banding). But if you also want to suppress shields from maps in such areas, could we enter the way ref as I 394;US 12|unsigned ? Peter On Thu, Nov 28, 2013 at 2:43 PM, James Mast rickmastfa...@hotmail.comwrote: We also have to come up with a way to designate hidden segments of a route so we don't have to have two separate relations for highways that have segments that are hidden. Some of the examples I'm thinking of are like US-52 in MN when it's on I-94 and US-19 Trunk here in Pittsburgh, PA while it's on I-279/I-376. Both states have signs for theses routes telling people to follow said Interstates for those routes and then no more reference to them till when they leave the Interstates. I'm thinking that we could possibly tag the roles for them in the relations this way: role=north|unsigned. This would also help for the renders that use the relations to add the shields. They would be able to use the |unsigned part to know not to add the shields along that way. As for the highways that are completely hidden, the unsigned_ref tag in the relation will work perfectly for them still (US-85 in NM as an example). Anybody else agree with me that this might work better than the two relations for the highways that have segments that are hidden? -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
Martijn I'm good with having a separate discussion of milepoints/*pointes kilometriques, *sure. I'll probably wait a week or two until a consensus emerges on posted directionality, as you suggest. Peter On Thu, Nov 28, 2013 at 10:37 AM, Martijn van Exel m...@rtijn.org wrote: Peter, I think we should separate the discussion related to linear referencing / mileposts from the cardinal direction discussion - these are two different things really, to my mind. The notion of cardinal direction is a relatively straightforward one, and that is already cause for (cultural) confusion. Introducing the GIS concept of linear referencing into this discussion I think adds to the confusion. We should perhaps discuss that separately - I for one don't see the immediate relation between the two, but I am happy to be proven wrong. On Wed, Nov 27, 2013 at 3:08 AM, Peter Davies peter.dav...@crc-corp.com wrote: Martijn I, too, await your clarification for KristenK, as I'm a little confused too. We need to keep in mind that positive and negative GIS Linear Reference directions (which are handy as global solutions applying everywhere in the US at least) beginning at milepoint 0.0, usually on the southern or western state boundary for rectangular states, are not the same as posted DOT miles that sit on green and white pressed steel signs on the shoulder of all Interstates and many state/US routes. DOT miles often jump and can occasionally change directions, as route designators are altered (something that happens quite often) and bypasses are built. The cost of reporting the whole route is usually prohibitive. So GIS LRS positive and (imperfect) posted DOT miles are handy things to keep in mind as long as we realize that there are always a few exceptions to break our defaults. Similarly, posted cardinal directions are fairly rules-bound but certainly not 100%. This is why I think a good OSM solution needs to be explicit rather than implicitly inferred from highway geometry. Examples of state GIS definitive records are built by ESRI Roads and highways (used in Indiana) and by Agile Assets (used in Idaho). Check out http://www.esri.com/software/arcgis/extensions/roads-and-highways Peter On Tue, Nov 26, 2013 at 5:24 PM, Kristen Kam krist...@telenav.com wrote: Martijn, I want to make sure I understand what you're trying to convey to the group. Are you saying that If a way has a member role value of east then east will mean forward and then west (it's opposite) would mean backward? Example logic: ** If member role = east, node direction is eastbound would mean forward and backward would mean 'west' ** If member role = west, node direction is westbound would mean forward and backward would mean 'east' ** If member role = north, node direction is northbound would mean forward and backward would mean 'south' ** If member role = south, node direction is southbound would mean forward and backward would mean 'north' If the logic I stated above successfully captured with your suggestion, then I would like to expand on it. Why not just make the cardinal direction value-forward/backward value relationship a bit more simpler? I would like to cite Peter Davies' discussion on the Highway Directions in the US wiki page. He stated that milepoints increase as highways that trend northward or eastward--say positive direction. So if one is traveling south or west on a highway, the milepoints are decreasing--say negative direction. With this in mind, couldn't we just say that north/east = forward (forward movement is positive!) and west/south=backward (backward movement is negative!)? If we're digitizing our edges, the suggestion would be to set the node direction of two-way, aka single-carriageway roads, into a positive direction and the member roles values to north or east. Basically what you did for http://www.openstreetmap.org/browse/relation/2308411, but setting the single-carriageway/two-way roads to 'east' instead of 'west'. Thoughts Martijn? Others?? Best, Kristen --- OSM Profile → http://www.openstreetmap.org/user/KristenK -Original Message- From: Martijn van Exel [mailto:m...@rtijn.org] Sent: Tuesday, November 26, 2013 2:47 PM To: Ian Dees Cc: Florian Lohoff; OpenStreetMap-Josm MailConf; OSM US Talk Subject: Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward Yes, sorry for not being clearer. As Ian indicates, this is the *signposted cardinal direction* of a numbered road route, which does not change with the actual compass direction of the road. The guiding principle for the United States is that the odd numbered Interstates are north/south, and the even numbered Interstates are east/west. This is independent from the local compass direction. So for example, I-80 is east
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
Other examples of weird route designators include Arizona's Loop 101 and Loop 202 freeways in Maricopa County (Greater Phoenix). They are state highways, 100% freeways (probably), one around metro PHX and the other around the East Valley (Tempe/Mesa etc.). Like James I think that the route designator and the directionality are two completely different things. So I would imagine Loop 101 in the way ref and directionality in the relation role. Sadly although I live there half the time I can't recall how the loops are directionally posted right now, but I can take a look later next week. Peter On Wed, Nov 27, 2013 at 8:44 PM, James Mast rickmastfa...@hotmail.comwrote: However, with the split Interstates (I-35W/I-35E in both TX and MN I-69E/I-69C/I-69W in TX) US Highways (and a few state highways), the letters are part of the route number. So, they wouldn't have any effect on the role part for relations. When given routing info, they'd act just like their non-lettered siblings. Turn left onto Northbound I-35E on-ramp or something similar. Also, I don't know why some people put the letter as a modifier in some of the relations[1]. Maybe we could also remove that line (since the ref line has the proper number still) when we convert everything to the cardinal directions. -James [1] - http://www.openstreetmap.org/browse/relation/416519 Date: Wed, 27 Nov 2013 22:22:47 -0500 From: saiarcot...@gmail.com To: talk-us@openstreetmap.org Subject: Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward The same applies for I-35 in the DFW area; I-35E runs through Dallas while I-35W runs through Fort Worth. Saikrishna Arcot On Wed 27 Nov 2013 03:56:51 PM EST, Richard Welty wrote: On 11/27/13 2:46 PM, John F. Eldredge wrote: You also have compass-point letters used to distinguish between branches of the same route. For example, US 31 runs north/south. A portion of it branches off as US 31W, which runs roughly parallel, some miles westward of US 31, and eventually merges back into it. in the Hudson Valley of NY, we have US 9/US 9W, which behave similarly; 9 is on the east side of the river south of Albany, and 9W is on the west side. (on top of that, NYS has a thicket of state routes which are spurs and loops off of 9/9W, e.g. NY 9A, 9B, ... 9H, 9J... mapping in NY is fun. whee!) richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
We at Castle Rock Associates and our client Mn/DOT agree that I-35W is the route designator (ref on the way in OSM). Peter Davies Sent via BlackBerry from T-Mobile -Original Message- From: James Mast rickmastfa...@hotmail.com Date: Wed, 27 Nov 2013 23:44:09 To: Saikrishna Arcotsaiarcot...@gmail.com; OSM US Talktalk-us@openstreetmap.org Subject: Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
I should add that in OSM, I-35W is written I 35W, without the dash. I-35 splits into I-35W and I-35E in MSP (MN) as well as in DFW (TX). Mn/DOT is the Minnesota Dept of Transportation. Peter Davies Sent via BlackBerry from T-Mobile -Original Message- From: peter.dav...@crc-corp.com Date: Thu, 28 Nov 2013 12:00:55 To: James Mastrickmastfa...@hotmail.com; Saikrishna Arcotsaiarcot...@gmail.com; OSM US Talktalk-us@openstreetmap.org Reply-To: peter.dav...@crc-corp.com Subject: Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward We at Castle Rock Associates and our client Mn/DOT agree that I-35W is the route designator (ref on the way in OSM). Peter Davies Sent via BlackBerry from T-Mobile -Original Message- From: James Mast rickmastfa...@hotmail.com Date: Wed, 27 Nov 2013 23:44:09 To: Saikrishna Arcotsaiarcot...@gmail.com; OSM US Talktalk-us@openstreetmap.org Subject: Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Separate relations for each direction of US State highways.
Martijn, I think it would be conceptually clearest for all the 2-way single carriageway ways to point the same way and would suggest that this should normally in be the direction of increasing milepoints/pointes kilometriques (usually northwards or eastwards). At Castle Rock we call this the positive travel direction (increasing linear reference values) while the decreasing milepoint direction (reducing milepoints/pointes kilometriques) we would call the negative direction. It would be great for us if OSM forward tied in with milepoint increases. Inevitably there is an occasional glitch in states such as Idaho where DOT milepoints actually reverse direction for sections of 2 or 3 state routes statewide, due to legacy signposting and route redesignation, but this is probably less than 1% of routes nationally. More common is minor milepoint jumps (where routes have been shortened by new construction) and minor milepoint repeats (where bypasses are longer than the original through route; a situation that Washington State calls backmiles and Caltrans calls formulas). Despite this, there is almost always a mostly consistent increasing milepoint (OSM potential PK tag) postive travel direction that could become OSM forward on 2-way single carriageways. We plan to begin adding PK consistently across many states in 2014, with our state DOT partners, FYI. It would be nice if this fitted in with the work you are doing at Telenav. Just a thought. Peter On Tue, Nov 26, 2013 at 7:24 PM, Kevin Kenny kken...@nycap.rr.com wrote: On 11/26/2013 01:58 PM, Martijn van Exel wrote: There is some discussion going on over on the wiki page I created on this topic: http://wiki.openstreetmap.org/wiki/Talk:Highway_Directions_ In_The_United_States Mostly dealing with how to prevent redundant relations where the numbered route is a bidirectional road (i.e. there are no separate OSM ways for the opposite travel directions.) One idea I think is perhaps the most promising is to have the ways forming a bidirectional stretch of the route all point in the same direction and tag the member roles so they correspond to the direction of the ways. I have done this here for US 6 in Utah as an example: http://www.openstreetmap.org/browse/changeset/19131911 where I reversed the bidirectional stretches where appropriate so all of them point in the same direction. I then added 'west' as the member role for all these stretches, and added 'east' and 'west' member roles as appropriate for the unidirectional / oneway stretches. Let me know what you think. By the way, doing this for a big relation like this one, really convinced me that we need at least the cardinal support for JOSM that James mentioned. Better, more intuitive relation editing tools in general in the longer run. Martijn On Mon, Nov 25, 2013 at 6:14 AM, James Mast rickmastfa...@hotmail.com wrote: So, nobody has a comment on my idea (from the 22nd) of getting JOSM to show north/south or east/west splits in the relation editor to be displayed the same way as the forward/backward gets shown already? I would try to do some coding to allow that to happen in JOSM, but I don't know how to code in Java. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us Careful with the data model. There is a case near me where I-890 West and NY-7 East are the same road. -- 73 de ke9tv/2, Kevin ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
Martijn I, too, await your clarification for KristenK, as I'm a little confused too. We need to keep in mind that positive and negative GIS Linear Reference directions (which are handy as global solutions applying everywhere in the US at least) beginning at milepoint 0.0, usually on the southern or western state boundary for rectangular states, are not the same as posted DOT miles that sit on green and white pressed steel signs on the shoulder of all Interstates and many state/US routes. DOT miles often jump and can occasionally change directions, as route designators are altered (something that happens quite often) and bypasses are built. The cost of reporting the whole route is usually prohibitive. So GIS LRS positive and (imperfect) posted DOT miles are handy things to keep in mind as long as we realize that there are always a few exceptions to break our defaults. Similarly, posted cardinal directions are fairly rules-bound but certainly not 100%. This is why I think a good OSM solution needs to be explicit rather than implicitly inferred from highway geometry. Examples of state GIS definitive records are built by ESRI Roads and highways (used in Indiana) and by Agile Assets (used in Idaho). Check out http://www.esri.com/software/arcgis/extensions/roads-and-highways Peter On Tue, Nov 26, 2013 at 5:24 PM, Kristen Kam krist...@telenav.com wrote: Martijn, I want to make sure I understand what you're trying to convey to the group. Are you saying that If a way has a member role value of east then east will mean forward and then west (it's opposite) would mean backward? Example logic: ** If member role = east, node direction is eastbound would mean forward and backward would mean 'west' ** If member role = west, node direction is westbound would mean forward and backward would mean 'east' ** If member role = north, node direction is northbound would mean forward and backward would mean 'south' ** If member role = south, node direction is southbound would mean forward and backward would mean 'north' If the logic I stated above successfully captured with your suggestion, then I would like to expand on it. Why not just make the cardinal direction value-forward/backward value relationship a bit more simpler? I would like to cite Peter Davies' discussion on the Highway Directions in the US wiki page. He stated that milepoints increase as highways that trend northward or eastward--say positive direction. So if one is traveling south or west on a highway, the milepoints are decreasing--say negative direction. With this in mind, couldn't we just say that north/east = forward (forward movement is positive!) and west/south=backward (backward movement is negative!)? If we're digitizing our edges, the suggestion would be to set the node direction of two-way, aka single-carriageway roads, into a positive direction and the member roles values to north or east. Basically what you did for http://www.openstreetmap.org/browse/relation/2308411, but setting the single-carriageway/two-way roads to 'east' instead of 'west'. Thoughts Martijn? Others?? Best, Kristen --- OSM Profile → http://www.openstreetmap.org/user/KristenK -Original Message- From: Martijn van Exel [mailto:m...@rtijn.org] Sent: Tuesday, November 26, 2013 2:47 PM To: Ian Dees Cc: Florian Lohoff; OpenStreetMap-Josm MailConf; OSM US Talk Subject: Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward Yes, sorry for not being clearer. As Ian indicates, this is the *signposted cardinal direction* of a numbered road route, which does not change with the actual compass direction of the road. The guiding principle for the United States is that the odd numbered Interstates are north/south, and the even numbered Interstates are east/west. This is independent from the local compass direction. So for example, I-80 is east-west, but runs almost north-south locally (for example here: http://www.openstreetmap.org/browse/way/203317481) but the sign would still say 'I-80 East' (or West as the case may be). So the relation between the east--west and north--south member roles is equivalent to the relation between forward--backward. Because the cardinal direction is commonly included on the road signs (see example http://www.aaroads.com/west/new_mexico010/bl-010_eb_at_i-010.jpg) this information is useful in the U.S. (and Canadian) context as a drop in replacement for the traditional forward / backward role members. Hope this clarifies somewhat! Martijn On Tue, Nov 26, 2013 at 2:57 PM, Ian Dees ian.d...@gmail.com wrote: On Tue, Nov 26, 2013 at 3:51 PM, Florian Lohoff f...@zz.de wrote: On Tue, Nov 26, 2013 at 12:30:25PM -0700, Martijn van Exel wrote: Hi all, I'm new to this list so please bear with me. The relation editor currently only parses 'forward' and 'backward' roles when considering the visual representation
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
When I typed The cost of reporting the whole route is usually prohibitive. below I meant The cost of reposting the whole route is usually prohibitive. By posting I mean signing. Peter Davies, Castle Rock On Wed, Nov 27, 2013 at 2:08 AM, Peter Davies peter.dav...@crc-corp.comwrote: Martijn I, too, await your clarification for KristenK, as I'm a little confused too. We need to keep in mind that positive and negative GIS Linear Reference directions (which are handy as global solutions applying everywhere in the US at least) beginning at milepoint 0.0, usually on the southern or western state boundary for rectangular states, are not the same as posted DOT miles that sit on green and white pressed steel signs on the shoulder of all Interstates and many state/US routes. DOT miles often jump and can occasionally change directions, as route designators are altered (something that happens quite often) and bypasses are built. The cost of reporting the whole route is usually prohibitive. So GIS LRS positive and (imperfect) posted DOT miles are handy things to keep in mind as long as we realize that there are always a few exceptions to break our defaults. Similarly, posted cardinal directions are fairly rules-bound but certainly not 100%. This is why I think a good OSM solution needs to be explicit rather than implicitly inferred from highway geometry. Examples of state GIS definitive records are built by ESRI Roads and highways (used in Indiana) and by Agile Assets (used in Idaho). Check out http://www.esri.com/software/arcgis/extensions/roads-and-highways Peter On Tue, Nov 26, 2013 at 5:24 PM, Kristen Kam krist...@telenav.com wrote: Martijn, I want to make sure I understand what you're trying to convey to the group. Are you saying that If a way has a member role value of east then east will mean forward and then west (it's opposite) would mean backward? Example logic: ** If member role = east, node direction is eastbound would mean forward and backward would mean 'west' ** If member role = west, node direction is westbound would mean forward and backward would mean 'east' ** If member role = north, node direction is northbound would mean forward and backward would mean 'south' ** If member role = south, node direction is southbound would mean forward and backward would mean 'north' If the logic I stated above successfully captured with your suggestion, then I would like to expand on it. Why not just make the cardinal direction value-forward/backward value relationship a bit more simpler? I would like to cite Peter Davies' discussion on the Highway Directions in the US wiki page. He stated that milepoints increase as highways that trend northward or eastward--say positive direction. So if one is traveling south or west on a highway, the milepoints are decreasing--say negative direction. With this in mind, couldn't we just say that north/east = forward (forward movement is positive!) and west/south=backward (backward movement is negative!)? If we're digitizing our edges, the suggestion would be to set the node direction of two-way, aka single-carriageway roads, into a positive direction and the member roles values to north or east. Basically what you did for http://www.openstreetmap.org/browse/relation/2308411, but setting the single-carriageway/two-way roads to 'east' instead of 'west'. Thoughts Martijn? Others?? Best, Kristen --- OSM Profile → http://www.openstreetmap.org/user/KristenK -Original Message- From: Martijn van Exel [mailto:m...@rtijn.org] Sent: Tuesday, November 26, 2013 2:47 PM To: Ian Dees Cc: Florian Lohoff; OpenStreetMap-Josm MailConf; OSM US Talk Subject: Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward Yes, sorry for not being clearer. As Ian indicates, this is the *signposted cardinal direction* of a numbered road route, which does not change with the actual compass direction of the road. The guiding principle for the United States is that the odd numbered Interstates are north/south, and the even numbered Interstates are east/west. This is independent from the local compass direction. So for example, I-80 is east-west, but runs almost north-south locally (for example here: http://www.openstreetmap.org/browse/way/203317481) but the sign would still say 'I-80 East' (or West as the case may be). So the relation between the east--west and north--south member roles is equivalent to the relation between forward--backward. Because the cardinal direction is commonly included on the road signs (see example http://www.aaroads.com/west/new_mexico010/bl-010_eb_at_i-010.jpg) this information is useful in the U.S. (and Canadian) context as a drop in replacement for the traditional forward / backward role members. Hope this clarifies somewhat! Martijn On Tue, Nov 26, 2013 at 2:57 PM, Ian Dees ian.d...@gmail.com wrote: On Tue, Nov
[Talk-us] Fwd: Separate relations for each direction of US State highways.
Trying again ... -- Forwarded message -- From: Peter Davies peter.dav...@crc-corp.com Date: Sun, Nov 24, 2013 at 10:46 AM Subject: Separate relations for each direction of US State highways. To: talk-us@openstreetmap.org Kristen and Martijn, I've not posted here before so I hope I'm doing this adequately well. I saw Kristen's outreach to me on the Talk page of Martijn's http://wiki.openstreetmap.org/wiki/Highway_Directions_In_The_United_States. so I replied to it there. I very much like the approaches that Telenav is taking and wanted to elaborate them on the wiki to see if we are in the same place. For me, it makes sense to post role=east etc. for directional carriageways of dual carriageway roads, as Telenav has been doing. Certainly role=forward doesn't seem to tell me anything, if it's a 1-way carriageway. If traffic can only use a way in one direction then it's obvious that the posted highway route must follow a different way for the other travel direction. Am I missing anything about the uses of role=forward? (It's entirely possible!) What concerns me, though, is this. I'm still not sure if we have a solution to posting cardinal directionality (North, South, etc., with highway number shields) on 2-way single carriageway state roads. I floated an approach on the wiki page but I'm not sure that I really like it. I hope someone has a better solution without having to create thousands of duplicate relations for the opposite travel direction of single carriageway and mixed single/dual carriageway highways. I apologise/apologize if I've upset some OSM community courtesies by floating possible solutions on the wiki. Like Telenav, my company (Castle Rock Associates, Portland, OR) would like to adopt and follow a consistent solution that can work throughout the Americas, or anywhere else on Earth where cardinal directions are posted on highway shields/direction signs/route confirmation signs. Peter Davies, aka Boppet *-- Forwarded message -- From: Kam, Kristen -(p) kristenk at telenav.com https://lists.openstreetmap.org/listinfo/talk-us Date: Wed, Nov 20, 2013 at 3:41 PM Subject: RE: [Talk-us] Separate relations for each direction of US State highways. To: Van Exel, Martijn martijnv at telenav.com https://lists.openstreetmap.org/listinfo/talk-us, James Mast rickmastfan67 at hotmail.com https://lists.openstreetmap.org/listinfo/talk-us Cc: talk-us talk-us at openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us, Zontine, Chris -(p) chrisz at telenav.com https://lists.openstreetmap.org/listinfo/talk-us, Lemberg, Vladimir vladimirl at telenav.com https://lists.openstreetmap.org/listinfo/talk-us, Yu, Haifeng (Chris) haifengy at telenav.com https://lists.openstreetmap.org/listinfo/talk-us, Martijn van Exel (m at rtijn.org https://lists.openstreetmap.org/listinfo/talk-us) m at rtijn.org https://lists.openstreetmap.org/listinfo/talk-us James+Community, I am the editor you called out in your e-mail on Monday. This is my response. Please note although I can receive messages posted on the talk-us mailing list, I cannot post to this list at this time. I am running into technical difficulties and I am working with Ian Dees to resolve them. For now, Martijn will just forward this message to the list. A fellow Telenav OSM editor and I have been making edits as an effort to solve the problem of the lack of cardinal direction information on highway route relations within the United States. Our reasoning is that the lack of cardinal directions for highway routes affects the guidance/routing quality. As you mentioned in your November 17, 2013 message to the talk-us mailing list, you would like routers to properly tell the direction of the highway folks would need to turn onto. It can be safe to say that you and I agree that this is a problem that would need to be solved. We took a look at the attributes of the existing highway route relations within the United States. We found that individuals employed one of the two following methods in adding cardinal direction information: For route relations entirely comprised of ways representing one direction of the highway route, the route relation had a direction=* tag value of north/south/east/west. The case of the values varied, but individuals set cardinal direction values to the direction tag of the relation. For route relations that are comprised of ways representing both directions of a highway (dual carriageway) or bi-directional road segments, individual editors set the member role to a cardinal direction the way represented. We reviewed the OSM wiki page (http://wiki.openstreetmap.org/wiki/Relation:route http://wiki.openstreetmap.org/wiki/Relation:route) on route relations and found these values were consistent with the cardinal direction Member roles values listed on said wiki page. When looking at the data in more detail, we found a preponderance of relations that were edited to use the member role method
