This park and the towns leading up to it have been, quite possibly, the most difficult bit of work I’ve done in a long time, in preparation and collaboration with the Missouri Exotic Species Arts Association (MESA) to help get survey from the major points, and with public data (under the Oklahoma Records Act or already published on the state’s GIS systems) from Oklahoma State University, Oklahoma Department of Transportation, Oklahoma Department of Recreation and Tourism, Oklahoma Department of Wildlife Conservation, and good ole US Census TIGER. This was done in an effort for MESA to help give back to the community after hosting Wild Nights, an outdoor furry convention hosted at that park every April, and to help attendees find their way into the convention and find amenities once on site. There’s wide space coverage of speed limits and traffic control for, at a minimum, a few dozen miles around.

Personal surveys also included finding as many amenities attendees might need during their weeklong stay as daylight, gasoline and the sanity of my boyfriend would allow in the towns of Stigler, Quinton, Wilburton, and at least one more I can’t remember offhand, across two different on-the-ground surveys comprising over 500 miles, and two previous, less intensive surveys from previous attendance (before we decided as a group we needed better maps than the state highway map and a badly xeroxed state park map the rangers hand out to work with last year).

ref=* on ways has become an unmitigated hot mess for maintainability, and now that relations have been around for a considerable amount of time. Let’s kill this dinosaur like Linux killed ext filesystem support already. It’s so long in the tooth it’s starting to go from egregious to just sad.

Background: Prior to 2007 and the 0.5 API, OpenStreetMap had no “relation” data type, just nodes and ways. A stopgap measure to deal with routes was to tag them on ways. However, this quickly developed into a major issue as routes with their own refs for different modes and memberships cropped up as OSM developed past being merely a traditional street map. Relations were introduced, and quickly adopted as the standard tagging for routes of all kinds, with tags for most networks moving off the member ways to the relations. Presets for creating road routes with relations exist in (at least) JOSM and have for years now (I’d consider it a glaring, almost egregious, omission for any general purpose or highway-oriented editor at this point).

The problem: It’s now been 8 years since the introduction of relations, and only route=road seems to be the sticking point for consistent route tagging, with qualities that should be part of the relation are instead still getting legacy-tagged on ways. This ends up being a major maintainability nightmare in places where multiple routes share the same way, especially whenever a new route is introduced or an old route is later deleted, and only gets worse the more routes share the same way (Illinois being an extreme example with some highways carrying as many as 9 signed routes), or the more road networks in play (Texas being an extreme example with 7 state level networks).

There’s also the situation where ways themselves have their own refs often disconnected from the route (Oregon for sure for any highway with no route, all highways prior to 1928 and most highways 1928-2007, which is to say all but ~20-30 highways statewide) and possibly Pennsylvania (with the four-digit state highways) has this situation, but PA’s case might just be a borderline case of routes with unsigned-ref).

Even in European cases, thanks to “E” routes in the EU, this is decidedly not a strictly North American situation.

In any case, adding or removing members and checking the relation’s consistency is far easier, and easier to validate, than juggling multiple ref values in any sort of coherent fashion. And this is before even getting into issues of which order the refs go in…

The fix: I propose a goal of December 31, 2016 to eliminate ref=* as a method to describe an overlying route; this should be more than ample time for existing data consumers to catch up on doing a move and ensure data consistency for routes. Kill the dinosaur: Deprecate ref=* on ways from having anything to do with the routes they run over, use relations instead and phase out the use of route-describing refs on ways (be it removal of the tag or replacement of the key’s value with a ref that actually applies to the way instead of the route).
Stop rendering this key and instead render the relations in opencarto and other featured layers.

Vandalism on the map at http://www.openstreetmap.org/changeset/33587233

-

Looks like address quality in Oklahoma is going to continue to suffer, at least for a while. Some good news and bad news from the OKGIS community: First, the good news: Addresses are available under a license compatible with OSM. The bad news: $50 per county, and Oklahoma’s got 77 counties, and only centroids. So, it’s going to cost more than my truck did to be able to import a complete set of Oklahoma addresses. Damn!

I’m trying to add lane detail and relations to every US, Interstate, Turnpike and State highway in Oklahoma. My previous strategy seemed a bit too resource intensive (start at one end of a highway, work to the other, across the state). So I’ve basically restarted, and I’m going to focus one county at a time, in order of population. This should have the advantage of being “more right” for more people sooner than the relative scattergun approach of doing it by numerical order. That said, next up: Oklahoma County.

Please see https://plus.google.com/u/0/events/c3ohfbgso96b1ahm1li1hba5auc for more information.

http://help.openstreetmap.org/questions/14040/whats-the-easiest-way-to-generate-ref-tags-for-ways-from-relations

Looks like software that supports Mapdust is making it more difficult to create an invalid bug, the result being the number of bugs open has been steadily declining since August. Now's a good time to start using the Mapdust plugin in JOSM so you can spot and close bugs in the areas you're editing in realtime.

This one seems odd...just noticed it in my RSS feeds. http://www.mapdust.com/detail/233220/1/viewcomm

Something tells me that 90 isn't the actual speed limit for Lake Shore Drive in Chicago.

http://www.mapdust.com/?zoom=3&lat=5464534.39742&lon=-10889524.83784&layers=B0

If you're in North America, I'm going over Mapdust cleaning out obviously invalid bugs and fixing what I can as I go along trying to get Mapdust back to something actually usable for the US and CA crowds...so if folks could start following the georss feed of open bugs for their usual area, that would really help for future bugs.

http://fastlane.dot.gov/2011/06/us-bike-route-growing.html

OklaDOT moved I 44 again, I'm sure of it, between OK 51 and the Arkansas River. also, there's a new detour between Red Forks and the LL Tisdale Parkway ramp on the MLK Expressway...does anybody have the latest GPS traces for these two locations? If so, I'll be happy to do the edit if you can drive through the construction detours both directions.

I know there's a few folks at TriMet working on geometry and access issues, however I do have a couple friendly requests:

Don't squash "name=" without double-checking it first. Most glaring example: The Robert Baldock Freeway is not "I5 Freeway (North|South)bound." Nor is the Boone Bridge.

Don't squash "highway=" without looking. At least make an honest attempt at figuring out why something is tagged the way it is before arbitrarily changing paths to footways, cycleways to paths, etc, especially if they're already part of an lcn relation.

Don't squash "cycleway=*" without looking or ground knowledge. I've noticed several instances of opposite_lane being cleared or set lane when the lane is only on one side.

I feel vaguely mournful when I map a cemetery, particularly if it's in a very small town or if it's a very large cemetery. Oddly, though, when I read the obituaries on some of the gravestones, such as when I hiked the Memorial Park Cemetery in Tulsa, I feel a bit less bad about how things will turn out. Then again, Tulsans tend to have a lot more noble deaths than Portlanders...

Ugh, I miss Tulsa. After getting let go from my driving job for poor job performance (out of 10 runs, I had six trucks break down on me requiring a tow, four automatic transmission failures, a broken tommy lift, and a truck with bad brakes that left me navigating a runaway through city streets(!), due to poor vehicle maintenance beyond my control), I more or less went nuts and drove back to Portland. I really miss Oklahoma...

http://maps.google.com/?ie=UTF8&ll=45.525111,-122.78183&spn=0.123633,0.308647&z=12

Knowing that while Sunset Highway is technically Northwest and Southwest by Portland standards (so it's not absolutely incorrect), yet, ODOT doesn't call Sunset Highway by either quadrant where no addresses front Sunset Highway, nor does any commercially available data or ODOT data set, I added "Northwest" and "Southwest" to that highway, after long suspecting Google was wholesale copying OSM based on prior, more subtle, detail edits I had made to OSM in the western Oregon and eastern Oklahoma areas (and thus, all of OSM) for months going on years. Since Google picked up the "NW/SW" gotcha on Sunset Highway, to me, this removes all doubt.

Does OSM actually enforce it's license and copyright? If so, how do we get this ball rolling? I'm /not/ going to work for Google for free if they're not going to provide attribution.

Dallas/Fort Worth area could use some serious help, as reported by data consumers.

http://www.mapdust.com/?zoom=9&lat=3882313.40546&lon=-10764531.94495&layers=B0T

I'm going to start adding bugs to Mapdust as I find them while on the road trucking. Given the generally good availability of aerial maps and GPS traces in the areas I'm driving in, these should be fairly easy to locate for an armchair mapper. Most of the locations will be in eastern Oklahoma, with some locations in adjacent parts of Arkansas, Missouri, Kansas and Texas. See http://www.mapdust.com/?zoom=8&lat=4164934.6421&lon=-10808329.62579&layers=B0T for current bugs in this region.

OSM is being actively consumed by truck drivers in this region, and there's a *lot* of TIGER data needing review, so your efforts will definitely be appreciated.

I'm starting to upload traces taken from driving a goods van around Oklahoma and Arkansas. Using this to compare and contrast with aerial imagery will really help some pros on the road, since I'm sharing OSM with the other drivers at my company.

...anybody need a GIS tech?