Re: [Talk-us] Marking of turn:lanes in the cases of an implied right turn
When tagging turn lanes I was taking my cue from the actual painted markings on the pavement. For your example where the right lane can go either straight or turn right but there are no markings, I've been tagging as left||| I haven't used "none" as the examples I took for my guide did not use that and the turn lane plug-in for JOSM id not complain. but looking at the wiki it seems I ought to go back and fix those to be like left|none|none|none For routing and guidance I think that turn restriction relations are probably easier to program for on the consumer side. But given how many issues there are with relations in other areas for many mappers I suspect that more intersections will be code with turn:lanes that with relations. But if all you did was use the information to indicate on the top bar which lane one want to be in on upcoming turns then it might be easier to use turn:lanes information. I look forward to having OsmAnd support this, so thank you very much! -Tod On Jun 24, 2014, at 6:28 PM, Saikrishna Arcot wrote: > Hi all, > > I'm working on adding turn:lanes to roads at traffic lights, and am also > working on adding support for reading turn:lanes in OsmAnd (Android). I'm > wondering on how to mark turn:lanes in the case of an implied right turn. For > example, let's say that you're approaching a traffic light and there are four > lanes heading in your direction. The left-most (1st) lane is indicated as a > left-only lane. The second, third, and fourth lanes are unmarked (therefore, > it would be none for these lanes). This would mean that the second and third > lanes are straight-only, and the fourth lane is straight and right (let's > assume a right-turn is allowed here). > > In this scenario, would this be marked as left|none|none|none or > left|none|none|through;right, and if it's the former, would data consumers > have to infer from the turn restrictions and see that a right turn is allowed > there? > > -- > Saikrishna Arcot > ___ > 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] Marking of turn:lanes in the cases of an implied right turn
Hi all, I'm working on adding turn:lanes to roads at traffic lights, and am also working on adding support for reading turn:lanes in OsmAnd (Android). I'm wondering on how to mark turn:lanes in the case of an implied right turn. For example, let's say that you're approaching a traffic light and there are four lanes heading in your direction. The left-most (1st) lane is indicated as a left-only lane. The second, third, and fourth lanes are unmarked (therefore, it would be none for these lanes). This would mean that the second and third lanes are straight-only, and the fourth lane is straight and right (let's assume a right-turn is allowed here). In this scenario, would this be marked as left|none|none|none or left|none|none|through;right, and if it's the former, would data consumers have to infer from the turn restrictions and see that a right turn is allowed there? -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] End of an Era, data collection to slow in Oklahoma, project announcement
Paul Johnson writes: NCN and RCN pages would be handy as well. I agree, however Paul, as you know from being a contributor to this WikiProject, in the USA, we might consider that there already is what effectively amounts to an "NCN" (national cycleway network) page: https://wiki.openstreetmap.org/wiki/WikiProject_U.S._Bicycle_Route_System This lists both Approved and Proposed USBRs in table format (respectively) along with BrowseRelation entries for each of them: roughly speaking, a couple dozen of "these" and a couple of dozen of "those." Furthermore, this wiki endeavors to keep the status of changes in the USBRS itself exactly updated with these tables, making this wiki not only a comprehensive listing, but a "status report" of how well OSM tracks its "absorption" of the USBRS as a national network (of route relations). Now, "RCN" (regional/state cycleway networks) as an organized table in OSM? Well, there are several such statewide tables (like https://wiki.openstreetmap.org/wiki/Ohio/Route_relations/Bicycle_routes, https://wiki.openstreetmap.org/wiki/North_Carolina/Bike_Routes, https://wiki.openstreetmap.org/wiki/New_York/Bike_Routes and https://wiki.openstreetmap.org/wiki/Illinois/Bike_Routes) but I do not believe there is a comprehensive table that lists these for each state. I believe that each state which has statewide bicycle routes (as these four do) having its own wiki, with its own table, listing its own rcn relations is a good model to continue to follow. Although I DO wish that more states which have rcns would create/have their own pages (are you listening, Georgia and Delaware, for example)?! Also, Paul, thanks for all the OSM editing you have done over the years. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] (no subject)
On Tue, Jun 24, 2014 at 12:10 AM, Paul Norman wrote: > > On 2014-06-23 8:41 PM, Paul Johnson wrote: > > Supreme Court rules for a second time that indian nations are domestic > dependent nations with inherent sovereign authority. This affirms that > indian reservations are higher than the state level, lower than the federal > level. > > This sounds like the SCOTUS just reaffirmed a case for indian reservations > being tagged as admin_level=3, if we're tagging for accurate status and not > for the renderer. Thoughts? > > > http://www2.bloomberglaw.com/public/desktop/document/Mich_v_Bay_Mills_Indian_Cmty_No_12515_US_May_27_2014_Court_Opinio > > > Having read through the decision, it's about tribal immunity for acts > outside Indian* territory. > It is, but both Bay Mills and Kiowa came to this conclusion because of the domestic dependent nation status. Similar situations overseas that I can think of that weren't initially just slapped on a map pretty much wherever in an effort to divide, conquer and exterminate populations systematically include Scotland, Wales, Guam, Puerto Rico, the Virgin Islands, etc. > Do you propose cutting the areas out of the states, i.e. so that IRs are > not in any admin_level=4 relations? That's what you have to do if you're > fitting IRs into the admin_level hierarchy. > No, since the states often have agreements for limited jurisdiction over things like continuing state highways and providing some services, particularly in less fortunate nations that struggle to provide basic services themselves. They're overlapping jurisdictions, typically. * The term used in the legal case > That's fine, most people who get offended by that term aren't indian themselves. Or they're Indian and frustrated with the confusion (which I get). ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] End of an Era, data collection to slow in Oklahoma, project announcement
I love the relation pages, but the state ones don't catch anything but the primary networks, which is very problematic in this region: Oklahoma and it's turnpikes (US:OK:Turnpike), Missouri and it's supplemental highways (US:MO:Supplemental), and Texas with it's Toll, Loop, Spur, Farm to Market, Recreational Roads, and exactly one each of Ranch Road (really! The Ranch to Market highways are part of the Farm to Market network) and NASA Road network. Heck, even Oregon and it's bannered auto trails (like the Oregon Outback Scenic Loop). Catching some of the more obscure national networks would be useful, too, like US Historic (US:US:Historic, kind of A Thing in areas I map given Historic US 30 on the south side of the Columbia River Gorge National Scenic Area being the best way to view the scenery and often the only way through in the winter when ODOT closes the Interstate; and Historic US 66 in Oklahoma, which has the most drivable miles of that route of any state), national autotrails (Lewis & Clark, Applegate, Oregon, though I don't think anybody's made a serious attempt at mapping the current routes of these). NCN and RCN pages would be handy as well. On Tue, Jun 24, 2014 at 8:23 AM, Martijn van Exel wrote: > Wow, Paul, that is a lot of distance you covered. > I do hope you manage to stay involved. > Let me know if there's anything you want improved to the relation > pages (if you use them). > > On Mon, Jun 23, 2014 at 11:24 PM, Paul Johnson > wrote: > > Alright, after nearly 110,000 miles, 4000 notes, 2000 trips, 2 years, > and an > > epic road trip from Portland, Oregon to Long Beach, California to Tulsa, > > Oklahoma via Historic Route 66, I'm leaving my current position as a > leading > > field service engineer in Northeast Oklahoma to take a job as a support > > engineer with a local internet hosting company. What does this mean? My > > GPX uploads and creation of OSM notes is going to become more sporadic, > and > > someone in Oklahoma's going to have the opportunity to out-edit me > (maybe, I > > still have a massive backlog, plus ongoing projects inspired by my > current, > > coming-to-an-end job). As a result, I'm also going to be pulling back on > > watching out for and maintaining construction zones outside the Tulsa > > City-County network and OklaDOT's Tulsa zone (I don't think I have any > > mapped construction zones outside this area at this time). > > > > I'm not leaving the OpenStreetMap project, though out of a want to > continue > > mapping and an understanding on how OSM in Oklahoma is used actively, I'm > > going to become more project oriented (especially once I'm done > inspecting > > the vicinity of the traces I collected over the last two years). Knowing > > the limitations and challenges of every other major mapping provider in > the > > region in practice has left me with a unique perspective on how a map > should > > work, and I plan on continuing my efforts to help support travelers and > > mobile professionals in the region until I, somehow, manage to find OSM > is > > Complete™ (yeah, don't count on that ever happening). I'm just not > going to > > be actively monitoring, on average, 240 highway miles per day like I have > > been. > > > > I've yet to properly name my current project for OSM, which has recently > > gotten underway and is going to take a LOT of time to complete assuming I > > don't get help. The basic jist of it is that I'm moving from county to > > county, in order of 2010 population, to complete route relations for > State > > Highways, State Turnpikes, US Highways, and Interstate Highways in > Oklahoma, > > with a special emphasis on ensuring route relations, lane counts, turn > > lanes, and placement=* tags are accurate relative to the most recent > Mapbox > > data (or personal recollection, whichever is more recent). > > > > My ultimate goal is to make OpenStreetMap, far and away, the most useful > map > > for navigation in Oklahoma, something I already believe we've no doubt > > achieved with apps like Osmand capable of inferring address lookups > through > > Nominatim as a supplement to the physically mapped data, > > > > ___ > > Talk-us mailing list > > Talk-us@openstreetmap.org > > https://lists.openstreetmap.org/listinfo/talk-us > > > > > > -- > Martijn van Exel > President, US Chapter > OpenStreetMap > http://openstreetmap.us/ > http://osm.org/ > ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] End of an Era, data collection to slow in Oklahoma, project announcement
Wow, Paul, that is a lot of distance you covered. I do hope you manage to stay involved. Let me know if there's anything you want improved to the relation pages (if you use them). On Mon, Jun 23, 2014 at 11:24 PM, Paul Johnson wrote: > Alright, after nearly 110,000 miles, 4000 notes, 2000 trips, 2 years, and an > epic road trip from Portland, Oregon to Long Beach, California to Tulsa, > Oklahoma via Historic Route 66, I'm leaving my current position as a leading > field service engineer in Northeast Oklahoma to take a job as a support > engineer with a local internet hosting company. What does this mean? My > GPX uploads and creation of OSM notes is going to become more sporadic, and > someone in Oklahoma's going to have the opportunity to out-edit me (maybe, I > still have a massive backlog, plus ongoing projects inspired by my current, > coming-to-an-end job). As a result, I'm also going to be pulling back on > watching out for and maintaining construction zones outside the Tulsa > City-County network and OklaDOT's Tulsa zone (I don't think I have any > mapped construction zones outside this area at this time). > > I'm not leaving the OpenStreetMap project, though out of a want to continue > mapping and an understanding on how OSM in Oklahoma is used actively, I'm > going to become more project oriented (especially once I'm done inspecting > the vicinity of the traces I collected over the last two years). Knowing > the limitations and challenges of every other major mapping provider in the > region in practice has left me with a unique perspective on how a map should > work, and I plan on continuing my efforts to help support travelers and > mobile professionals in the region until I, somehow, manage to find OSM is > Complete™ (yeah, don't count on that ever happening). I'm just not going to > be actively monitoring, on average, 240 highway miles per day like I have > been. > > I've yet to properly name my current project for OSM, which has recently > gotten underway and is going to take a LOT of time to complete assuming I > don't get help. The basic jist of it is that I'm moving from county to > county, in order of 2010 population, to complete route relations for State > Highways, State Turnpikes, US Highways, and Interstate Highways in Oklahoma, > with a special emphasis on ensuring route relations, lane counts, turn > lanes, and placement=* tags are accurate relative to the most recent Mapbox > data (or personal recollection, whichever is more recent). > > My ultimate goal is to make OpenStreetMap, far and away, the most useful map > for navigation in Oklahoma, something I already believe we've no doubt > achieved with apps like Osmand capable of inferring address lookups through > Nominatim as a supplement to the physically mapped data, > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us > -- Martijn van Exel President, US Chapter OpenStreetMap http://openstreetmap.us/ http://osm.org/ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Nominatim in CDP
Hi, So from my point of view as a nominatim developer the issue is that there are (at least?) 2 types of city in the USA. There are administrative cities and there are postal cities. There are also census areas, which may or may not be their own category of thing. At the moment all of these are tagged in exactly the same way: boundary=administrative type=boundary plus an admin_level There is nothing that lets us tell them apart so we are left to pick the 'best' city. Adding individual 'city' tags to houses doesn't help much. Do you mean admin city or postal city? Same issue. In most cases we actually want to find and link to both. So - my suggestion would be to introduce tagging that makes the distinction. Ideally to create boundary=postal or something like that rather than tagging every road or house with duplicate information. Thoughts? -- Brian On 24 June 2014 01:24, Clifford Snow wrote: > I reported this as a bug in trac. See > https://trac.openstreetmap.org/ticket/5190 > > Clifford > > > -- > @osm_seattle > osm_seattle.snowandsnow.us > OpenStreetMap: Maps with a human touch > > ___ > 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
