Recent diary entries
It looks like someone (ODOT?) has changed some of the exit signs on I5 in Portland, OR. The signs used to name the city or area for the exit (for example, Tualatin). Now they just list the road name (Nyberg Street).
I suppose this could be a plus, as it's not always clear which city should be listed. I can remember seeing signs from I84 to I205 south that said "Salem". To get to Salem, you'd first pass though Gladstone, Oregon City, Wilsonville and Woodburn. Even worse, it wouldn't help if you wanted to head south of Salem to Eugene.
I've been plugging away at improving the roads in Vancouver Washington. First, I'm surprised at how big that area is. Second, I find a lot of the TIGER data is "off by one" or shifted/compressed compared to the aerial imagery.
I've found the combination of NAIP imagery and JOSM works quite well for this. JOSM lets me select several point for moving which is way more efficient than Potlatch. The detailed Yahoo! imagery is the best, but it's old and the level of detail drops off a lot outside the big cities.
(weak humor for Oregon folks)
I've been trying to correct the TIGER data around Eugene Oregon, particularly the southern areas of the city. I've come to the conclusion that TIGER is not a fan of the Ducks.
I am developing mixed feelings about how to map for OSM.
I've made traces of roads that don't appear in Yahoo! imagery with my GPS and uploaded them. However, the mailing lists have provided WMS imagery that can be used in JOSM to achieve the same result. Heck, it's usually better than the GPS track. It is also much less work to trace an area in JOSM than it is to go out there, traverse the roads, upload the track and trace an image from it.
There's a feel good component to "beating" Google/Bing/Yahoo with a new road. But it starts to feel like wasted effort when I can find imagery that is new enough.
Worse, manual effort seems like a waste when bulk data can be uploaded. For example, if Portland OR has data on which roads have bike lanes, it could probably be part of a bulk upload. Meanwhile, I'm pinging away tagging bike lanes as I find them. Ditto for hiking trails: why bother to add them by hand when someone might do a bulk upload from US Forest Service data?
Does anyone else have this feeling? Imagery rules over GPS? Freeing data for bulk upload or adding little bits by hand?
Mappers in the US should take a look at the NAIP (National Agriculture Imagery Program) imagery. Amazing detail and coverage. And it's pretty quick to load.
Here's a Point of Interest I almost never map: banks. Let's face it, everyone belongs to one or two banks and ignores the rest.
What are some obvious POI you forget?
I have a memory of OSM copying the Wikipedia motto "be bold". However, I've noticed the USA mailing list errs on the side of "be accurate". In particular, it seems like proposals to automate the correcting data are typically declined in favor of human review. Now, I'm not suggesting we turn OSM into "bots gone wild", but is it realistic to expect all problems to be fixed by hand?
What does being bold mean to you?
I've been spending a lot of time fixing problems reported by this web site in Minneapolis, of all places. I'd say the most common TIGER import problem is unconnected ways, which no doubt makes routing problematic. I'd also say the most common human introduced problem is unconnected ways, particularly when splitting a single way into two oneway streets.
You owe it to yourself to take a look at where you've been editing from this site. You'd be surprised how many little mistakes might appear.
I've been cleaning up a bunch of maplint reported by Keepright, http://keepright.ipax.at/, which rocks!
(All comments based on USA data.)
Unfortunately, I'm starting to get to the conclusion that routing OSM data just won't work for any road smaller than highway=tertiary. It seems that the TIGER import didn't connect a bunch of roads near county lines that are away from the cities. That's not too hard to fix if mappers spend some effort.
There is also a fair amount of bad data due to edits. For example, streets are split into parallel one-way roads, but the new road doesn't get an intersection at every road it crosses. Or the new driveway almost touches the main road.
The trouble is things look good in the web. Intersections are rendered the same as non-intersecting roads. Visually, the map is good enough. However, from a routing perspective, the roads never meet, so you'll never get to make that right turn. This is going to be a serious problem for anyone who wants to use OSM data for routing. Without going to external websites, the map appears just fine, possibly leading to more incomplete edits.
Until this data gets beat into submission, I think OSM maps are going to be good for printing and viewing but risky for door-to-door routing.
So how important is routing?
One of the great things about using a wiki is you can make corrections. Unfortunately, I feel like I'm seeing more corrections for corrections sake. For example, Portland has two stadiums, the Memorial Coliseum and its replacement the Rose Garden Arena. Someone decided the latter needed a building=yes tag and now it looks like any other building:
Plus we can't seem to agree whether walkways in a park are tagged as
These ways keep getting tagged and tagged again. Meanwhile, we have neighborhoods without street names
and retail areas with no POI
Maybe this has to do with the fast-and-loose approach to tagging. I mean, there is a valid a case that a sidewalk is a path, paved/unpaved, a footway and a cycleway. The problem as I see it is these changes don't make the map better, just different. Perhaps when tagging stabilizes we can make a bulk edit.
It seems like there are enough TIGER fixes, new roads, trails without traces, missing bridges, POI and other details that changing tags of existing features is perhaps not the best use of time.
What I'm really trying to say is that instead of changing the tags on something that's already mapped, add new data instead.
The leisure=stadium tag implies building=yes/stadium/multi_storey/.... Otherwise, the thing is a pitch.
Don't believe me? The Memorial Coliseum and the Rose Garden Arena are both stadiums. As of 12-mar-2010, someone has decided that the Rose Garden Arena also needs an explicit building= tag. See the difference yourself.
Interestingly, there are some facilities that need the building= tag to render. For example, a bus station renders but a train station won't. Compare Union Station to Grayhound. (Well, or you could but the railway=station tag has been removed from Union Station, sigh.)
Why have all of the secondary roads been disappearing in Portland, Oregon? It looks like someone has decided that only highways (e.g. roads that have a ref=) get to be secondary roads.
It seems like there should be a distinction between two and four lane roads. Looking at the current map, you have to guess the major streets. What's the point in that?
I can assure you that SE Hawthorne is more busy than SE Harrison. http://www.openstreetmap.org/?lat=45.5108&lon=-122.63488&zoom=16&layers=B000FTF
I've taken to skiing and have been trying to map the runs at beautiful Timberline Lodge on Mt. Hood, Oregon. You can view the results on openpistemap.org or OSM, with the osmarender.
It would be nice if openpistemap actually rendered the recommended piste:name tag.
It would be real nice if it was smart enough to give the runs the colors we use in the USA (green, blue, black).
It would be nice if osmarender put the chairlift names (and chairs) consistently. Why is Molly's the only lift with a different orientation?
I've been spending perhaps too much time fixing problems identified by http://keepright.ipax.at/. For reasons I don't understand, the USA TIGER import seems to have more problems of certain types in certain areas. For example, a lot of roads in Washington state seem to have layer tags for no apparent reason.
It would be nice if there was a way to correct more than one problem at a time, as loading Potlatch for each change is slow. I'm using a G5 Mac, so I can't use its JOSM option...right? This would be particularly useful for making changes like joining roads that are split across county lines.
I've spent a lot of time adding bridges to the map.
Bridges are important map features since
* They help with routing because it's clear that roads don't intersect.
* They give an idea of how the land appears.
* They explain why there aren't more connections between roads.
That said, I've learned a few things about bridges in OSM.
They are somewhat unusual in they take two tags, bridge=yes and layer=N, where N is 1-5. At first, I thought this was redundant, going as far as to remove layer=1 tags. After all, a bridge implies a higher layer. However, that's not how OSM works.
The layer tag isn't always important for Mapnik to render a good looking map. It seems to understand that a bridge goes above other ways. However, Osmarender needs that layer=1 tag because it gives a priority to each highway= tag. So, for example, a highway=tertiary,bridge=yes way is overwritten by a highway=motorway way. Adding the layer=1 tag to the bridge makes it render properly in both renderers.
So view your favorite area with Osmarender and look for bogus bridges.
There are a bunch of symbols that are now rendered but don't appear on the Map Features page, for example, cave entrance. I see they reference image files but it's not clear to me where those files are and how they got there. If you can give me a pointer I'll update a bunch of them.
There has been some buzz about Google now supplying their own data for Google Maps. Maybe now we see why they were doing all of the "Street View" stuff.
Anyway, this brings a big opportunity for OSM. New neighborhoods (that I am familiar with) seem to have a ton of mistakes: alleys are streets, names are wrong, etc. It sounds like Google is more responsive about getting these things fixed. Maybe if I'd started mapping about now, I'd have been content letting them know about their mistakes. But the opportunity is to get people making the changes to OSM instead of the GOOG. Why get their approval when you know you're correct? And who benefits anyway?
Ditto with their Map Maker tool (which doesn't work in the USA). Why are people spending time creating data where they relinquish the rights? Maybe Google Maps is the big thing, but what else is gained other than advertising all over your map? I mean, if there is no data in, say, Mozambique (and I have no idea whether there is or not), why give it away to a proprietary provider?
Plus, OSM allows for a much richer view of the world, particularly if you're not in a car.
The consensus is Google won search because they have the best results. Look at your favorite area and ask yourself whether that is true for maps.
I've added a lot of highway=turning_circle (originally this said traffic_circle, oops),source=Yahoo tags with Potlatch. The r (repeat) key is a real timesaver here (except there seems to be a bug where sometimes every tag from a node is repeated, not good if it has TIGER data).
That said, I just realized there was a better way to do this with JOSM. Shift-select all of the turning circles, and add the tag just once.
Now if only the JOSM imagery was as good as Potlatch....
When I started contributing to OSM, my favorite uploads were new roads that did not appear on the map and adding bike lanes. Then I started fixing mistakes in the TIGER import and adding POIs. However, there must be something about doing this over time that makes one want to add more and more details. While I first thought tagging traffic signals and speed bumps were too much detail, I'm now inclined to do it as time allows. Anyone else fall victim to this behavior?
Who knew there would be so many ways to park a car? The renderers are finally catching up. We have the basic amenity=parking and the exciting additional key parking=multi_storey for parking garages. Osmrenderer is also adding a special icon when you tag with fee=yes.
I'm not totally sure how to map a mixed use structure, for example, one that has storefronts on ground level and parking up above. Maybe buildings aren't the best for simple tags.