Frankly, I don't give a flying F about the license of my edits, as long as anyone can use them.

(I DO care about the fact that a lot of existing data from others may be removed in the future, which is by itself reason enough to consider a license change plain dumb.)

I know there was an option to grant your contributions public domain status, which I selected, but that was no more than a poll. What was missing was an option to explicitly license contributions under both new and old license.

This way, in case of an OSM fork, my new edits can still be used for both.

Keepright was showing a whole bunch of streets in a residential area as unconnected. One junction point was missing, easy to fix, right?

But looking at the aerials, the real streets didn't quite match up with reality. TIGER...

Anyway, they matched up close enough to make the usual educated guesses, but since this area is really close to the Shoreline theatre, why not do a quick drive-by on my way to a movie?

Turns out: there's nothing left! What must have been cheap army housing is gone. Roads, houses, everything completely leveled!

After making all the fixes to OSM, I couldn't help checking out if the others got it right too. Bing still shows the old ways, Yahoo and Mapquest too.

But Google surely has to be up to date on that one, right? After all, the Google campus is less than half a mile away. Well, no, they too still show the old neighborhood in all its bygone glory.

I wonder how long it will take for them to catch up. (Do they read these diaries?)

If you don't want to go though the many hoops that I've described earlier to get USGS topo's as background in Potlatch or Merkaartor and you don't want to use the slow and sometimes inaccurate terraserver WMS service (which doesn't work with Potlatch anyway), there's another option:

There is at least one website with free online USGS topo maps with a Google Maps interface and tiles that are TMS compatible.

Just surf to this site, enable FireBug (on Firefox) or Web Inspector (on Safari) to analyze the resources and you'll be able to see the URL's for individual tiles.

Replace zoom/x/y.png by !/!/!.png in Potlatch as a custom background and, voila, fast and high quality USGS topo backgrounds.

keepright ( http://keepright.ipax.at ) is the single most important tool in the bag of open street map tricks, and pretty much the only reason I'm starting to believe that OSM may one day have a modest shot at being useful for routing (the lack of house numbers rules out a top-notch experience, IMHO). And now it's available for the US too. Woohoo!

The starting point of the keepright checking algorithm was in Philadelphia, so that's what popping up for first time keepright USA users.

If you ever needed proof that OSM is currently NOT ready for general routing use, look no further.

What A Mess...

US Interstates are often the first ways to be corrected (largest ! for $), but somehow Philadelphia didn't receive its share of TLC. It has interstates going straight through the city center, either on elevated structures over the local streets or in these huge ditches with local streets crossing above, but pretty much all of them have a junction as if they were intersection. You know: speed down on I-76 at 75 mph, next take a sharp turn right onto 21st St. Fun, fun, fun.

It's obviously no easy to have so many over- and underground highways, but you'd think that a city this size has at least some OSM fanatics to clean thing up?

Anyway, I've fixed up a large section of the downtown I-76 intersections, but some are too obscure to get a decent insight (like the one this post is linking to.) Let's get to work!

(And, please, whenever something is fixed, mark it as such on keepright.)

My question last week on how to use your own tiles in OSM didn't get an answer, so I had to figure out something myself. (@wallclimber21/diary/8019 )

This took a bit more effort than I expected:

Prologue: USGS topographical maps are a great source to map places that are otherwise difficult to map.
- They often contain features that are not available anywhere else (e.g. power lines)
- They are great for area's that are not visible on Yahoo Aerial tiles (e.g. too low resolution or because places where streets are covered by trees / forest).
- They often have feature names that can't be found anywhere else.
- They're in the public domain

(They're also very much outdated, so this won't work for areas with new construction etc.)

I've described here (@wallclimber21/diary/7750 ) how you can use those topo maps with Qgis.

Unfortunately, OSM support in Qgis is very basic. You really want to be able to use your tiles as a background in a real OSM tool.

The tiles generated by gdal2tiles.py follow the Tile Maps Service specification (TMS). But while they align perfectly with the tiles of Yahoo, Google, Virtual Earth etc, they don't follow the same standard in how to select a tile at a particular location. Google uses a zoom/y/x format, where (0,0) is at the top left of a flat world. Virtual Earth uses a recursive quadtree structure and TMS uses a structure similar to Google, but with (0,0) at the bottom left of the same flat world. Yahoo uses yet another slightly different convention...

The standard tiles of OSM are using the Google convention.

In addition, there are limitations to the way OSM tools can access custom background tiles: Potlatch only supports the Google convention (I believe), JOSM only supports the WMS standard, not the TMS. And Merkaartor supports both WMS and TMS, but with TMS only the Google convention.

… See full entry

I've created my own map tiles from USGS topo maps and created Google maps-like tiles for them with gdal2tiles.

Now I want to use them as an overlay in JOSM with the WMS plugin, but I can't get this to work.

I've looked at TileCache, but without success...

Has anyone tried this?

After adding a bunch of Yosemite trails to OSM, I've run out of my own GPX files to add more, yet there are so many more trails to add. Doing more hikes One way to get more is to go hike more, but that will only get me so far. Another is to get the trails from USGS Topo's (which are released in the public domain).

The USGS Topo data is often decades old, but for National Parks that's usually not an issue: nobody is their right mind is going to reroute the Mist trail, or the John Muir trail, or build a whole new trail from scratch in a National Park, so the topo maps are still very much up to date.

The accuracy of the topo's is usually spot on for POI's. Trails are not as good. A good example is a hike I did two weeks ago at Kings Canyon, where the trail on the USGS Topo is sometimes off quite a bit from a GPS recorded trail. At first, I thought this was due to the GPS unfriendly environment, but Yahoo imagery proved that the GPS was correct whereas the Topo trail was not.

That's said, there are good arguments to be made to use the topo trails:
* For generations, the topo's have been all that was available for those whohad to endure life without GPS.
* The accuracy is still good enough for hiking purposes. Sufficient to get guidance about the trail distance and where it goes and very accurate for trail intersections, which is really what counts.
* Google Maps: it turns out that the Yosemite hiking trails in Google maps are an *exact* copy from those of USGS topo's (* see below). If it's good enough for Google, it should be good enough for OSM until someone gets hold of real GPS data.
* The choice between no data at all or data that's entirely useable for practical purposes is a no brainer.

With that said, how to go about it?

… See full entry

I already filed a request for this with CloudMade about a month ago, but I just want to stress the importance of rendering ways that are marked as 'path' in full.

Right now, in the best case, tiles render the path but they don't render the path name. (OpenCycleMap renders the path name, but not the path itself, go figure.) In the worst case, unfortunately the default CloudMade tiles, paths are not rendered at all.

This makes the Cloudmade tiles very much unusable for all the mobile apps that are targetting hikers and bikers.

The goal of OSM is to create an all encompassing free maps database, but, let's be honest, when I'm in an urban environment, I'll use Google Maps, because that's what's all iPhone apps use and because it's information is complete enough. In my opinion, the real practical value for OSM is for those roads/trails/paths that are not covered by Google Maps. When I started with OSM in november last year, pretty much all open space preserve parks in the SF Bay Area were empty. I've added many hunderds of fire roads and single track trails everywhere and other have done the same. When you go there now to very popular parks for mountain bikers and hikers, a lot of them are now trail complete. It's exhilarating and something where Google Maps (and it's competitors) are absolutely nowhere.

For a mountain biker and a hiker, it's important to know if a trail is a single track or a fire road. We love the first and loath the latter. A single track is marked as 'path', a fire road is marked 'track'. I spend a lot of time annotating them correctly.

… See full entry

It looks like all US national parks are being converted from leisure=park to leisure=nature_preserve.

The wiki doesn't give clear instructions about whether or not that's not the official way to do it. In official US NPS parlance, a nature preserve is not quite the same as a national park, but I understand that's not really the point. However, whereas the park region used to be rendered in this nice, understated transparent light green (very similar to official NPS maps actually), the nature_preserve has this butt ugly high saturation green with, at higher zoom level, an equally ugly 'NR' grid rendered onto it.

I know, I know, don't tag with the renderer in mind, but won't someone please think about esthetic sensibilities and all that?

When I looked at OSM for trip planning in Namibia, I simply assumed that the empty spaces on the slippy map meant that the data just wasn't there.

Now, as I try to upload some data, it turns out that it's actually very complete: pretty much all major roads in the country are there!

It's just that they are marked as "highway:tertiary" and "surface:unpaved". Except for a handful of main arteries, all roads in that country are, indeed, unpaved gravel roads, but since you can often drive over 100km/h on them (that's actually the official speed limit, even if it's definitely not always a smart thing to do) and since they're the only way in which cities (by Namibian standards) are interconnected, it's hardly fair to call them tertiary roads...

A nice example is here: osm.org/?lat=-24.426&lon=16.1727&zoom=12&layers=B000FTF

No matter now deep you zoom in, you'll never be able the discover that you're actually looking at the intersection of roads D854 and D850... The labels are never rendered.

In all honesty, those roads don't even show up on Google Maps, but at least it shows the C roads (highest standard gravel roads) in all its glory and some cities.

Also, so other D-roads are tagged as secondary and will show up if you zoom in very closely.

It's probably pretty hard to implement, but a possible solution would be to render detail density adaptive: when there's little or no roads in the area, label roads and mark cities even if they normally wouldn't show up in densly populated area.

As similar example is here: osm.org/?lat=-23.8931&lon=16.0022&zoom=13&layers=B000FTF

Solitaire is a hamlet (as tagged on the map), probably of no more than 100 inhabitants, if that much. But when it's the only place with a shop and gas in an area of, say, a hundred kilometers, it probably makes sense to make it a very prominent hamlet indeed, as is the case on Google Maps:

http://maps.google.com/?ie=UTF8&ll=-24.557116,15.869751&spn=2.792765,4.839478&z=8

… See full entry

In a previous version of Potlatch, setting CapsLock to ON resulted in roads etc to be come semi-transparant, which made it really easy to check if OSM data correlated with Yahoo Map data.

That doesn't seem to work anymore?

Henry Coe, 40 miles south of San Jose, is *huge* and there's a million small and not so small trails going everywhere. I had already spent quite a bit of time adding trails the last few weeks but today, I spent my sick day tracing my whole inventory of Coe GPX files. This park used to be pretty much empty when I discovered OSM about a month ago. Now you don't know where to look first.

Unfortunately, I don't have the names of many trails. Will need to take better notes the next time...

*dupe*

Added a whole bunch of trails to Alamden Quicksilver park. Purisima Creek Open Preserve is now almost completed (except for some hiking-only trails). I've also added a trail on South Mountain, Phoenix and aligned a bunch of TIGER data in the surrounding streets.

Has anyone thought about importing the GIS data from the US National Park Service? It's weird that the outline of parks such as even Yosemite are approximations at best, but often completely non-existent (e.g. Golden Gate Park). I'm not 100% sure, but since this is data provided by the federal government, this should be free to use.

Speaking of which: pretty much all map providers (e.g. AAA) will display National Parks prominently on their maps, but Mapnik only does so at fairly detailed zoom levels. Am I the only one who uses National Parks are a way to orient myself on a map?

Today, we mountain biked all trails of St. Joseph Hill's Open Space Preserve in Los Gatos. I've added them to the map. One more local park that's been fully mapped for hiking and biking.
I also added a couple of trails in the nearby Almaden Quicksilver park (and deleted some ridiculous TIGER segments in the process.)

Spent the whole evening correcting streets in Cupertino and Saratoga. Sometime the TIGER data is 100% accurate and then suddenly the streets right next to it are seriously off...

I just correct points based on the Yahoo photos and don't touch any of the TIGER tags. I hope it's not necessary to touch the 'reviewed' flag to avoid changes to be undone with a later import? There's an edit history after all, right?