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] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
Hi Florian, It's more like a designation than a destination, so I think the destination tag would not be very appropriate for this. An Interstate has a cardinal direction, and when giving directions you would say for example 'enter Interstate 80 west'. On Wed, Nov 27, 2013 at 12:12 AM, Florian Lohoff f...@zz.de wrote: On Tue, Nov 26, 2013 at 03:46:47PM -0700, Martijn van Exel wrote: 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. I still dont get it - Which relation would need this as a role? If this is a signposted destination i would expect it in the destination or destination:lane tag on the road as west e.g. destination:lanes=West;Los Angeles|East;Boston For example Mapfactor Navigator will use this to show destinations. backward/forward as role are in relation to the ways direction. A tag can either have a meaning in forward or backward or both directions on a way. There is no way a tag has a meaning in 56° left of the way. Flo -- Florian Lohoff f...@zz.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIVAwUBUpWbWZDdQSDLCfIvAQhY8w/9FskAH+at4ET9dCpGAxZ6pIAfRUre9LmV q95AMRW+s83yMrm4ztIDAxsvpc/VaMagly+b6XnoLFFkv7x6KH546Babw/RphFbw uspFpY+JSkEbY2BGmz4DAH7jAhmYWPDpLvoHXf9oCMUWoWUONygMqppXFdGgkBbL 4/YZSmKleIbVhoCtQsfzCDhHCsvV2NaM9JjCUClGAMgZF2TNmqY7jhEiqA8AQxNV 5skaECB08Ay/3kO22+T6Zk6mV3uTYIq7v+nbG++MCeS0XcHz1AHrTvXo5bYtIKRU qBDXkhvlLtrSICW1W4ML6+jWSv8s4d1Rvkx5GesAIB9+o6GAE2NMpcZCopl6pe9F GrXLk+rAqUMMVLEBp6rV4zq2cpaQ3ZUwLKaSmS9hWbfijpxT2hKLYcXLeYOVm0GC EEtRxziPQPM4J1a2g1SMqEwPL40XFnj/O21hCzNAMoRMyRwRwkHB8p+WxssP8tAu YpzJuWosMX3ZVdDehVb4PSqSNSUH2KXk6uS7vQzIPNQp52s1gCl9HplzC9pUqbQ3 BAOKmPmoJJVMSziNRMhAnnHT7NwxgQg3dDDC8QXkZ58h8n6WCBTcSLgMhW7Ctd3f 7SJ3Zbp6BQHU4oV/bN6MSh/JsQshuvosnPzsDvaBxYChQjmRuxfSmPMDmgtRC91z fbRRKUaWVIo= =51kM -END PGP SIGNATURE- -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.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
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-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
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
On Wed, Nov 27, 2013 at 4:24 AM, SomeoneElse li...@mail.atownsend.org.uk wrote: For example, imagine I'm near 2 ways that are both part of the I-80[1]. For simplicity let's assume that the way that I would take to get to eastbound destinations actually goes in an eastbound direction at my location. If it's important to recognise that there are two signed I-80 routes, one eastbound and one westbound, shouldn't there actually be two I-80 relations? The eastboundness is really a property of the route, rather than the individual way. -josm-dev, adding talk-us That's a great point, Andy. We have considered this and it's an elegant solution. Just off the top of my head there's three considerations that make this a less desirable option: 1) Some routes actually change signposted cardinal directions (examples are some beltways) which would make for convoluted relation hierarchies. 2) You would need to duplicate relations for single-carriageway numbered routes. 3) The member role approach is already widely established in the U.S. Point 2) could be taken care of if we would make sure the member ways all point in the same direction and just assign the signposted cardinal direction to match the way direction, and infer the opposite cardinal direction. -- Martijn van Exel http://oegeo.wordpress.com/ http://openstreetmap.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.
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
