Carnildo has commented on the following diary entries
|Connecting Rivers||about 1 month ago||
OSMI (https://tools.geofabrik.de/osmi/), Osmose (https://osmose.openstreetmap.fr/), and JOSM's validator will all warn if a river segment's downstream node doesn't connect to a suitable point. I think there may also be one that uses elevation data to find wrong-way flows, but I can't find it.
|Take a right on “Too Damn Far Rd”||5 months ago|
|MapRoulette destination challenges: success! (and more to do)||6 months ago||
At least in the US, on-ramps have destinations. For example, the interstate near me has signs indicating "I-90 west to Seattle" or "I-90 east to Spokane". See https://email@example.com,-117.8388722,3a,75y,10.56h,88.38t/data=!3m6!1e1!3m4!1s5EaWcp1m5ZYD5zzcXUtKtA!2e0!7i3328!8i1664 for one such sign.
|OpenStreetCam sign detection code and training data open sourced||7 months ago||
Not only is the sign an exit speed limit, it's the yellow of an advisory speed limit rather than the white of a mandatory speed limit.
|This, That & The Other||8 months ago||
Could be worse. Near me are roads with names like North North Road.
|Releasing Turn Restriction Detections||10 months ago||
I don't know how much use this will be. I checked all 15 detections in Eastern Washington, and only one of them was not already mapped through road geometry or turn restrictions.
|PoGo Initiative: entry 2 xD||about 1 year ago||
Have you tried changing which background imagery you're using? The "Esri World Imagery" option for your area appears to have been taken during the winter, so there are far fewer leaves blocking the view.
(If you don't know how to change it, it's under the "Background settings" tab, the one that looks sort of like three stacked sheets of paper.)
|Specificity vs Readability||over 1 year ago||
Speed limits are pretty useful when finding the fastest route.
|What shall we have for diner tonight?||almost 2 years ago||
There are four types of queries that an end user is likely to perform on a value:
The first two are easy to perform on a semicolon-delimited list: they are a substring search and a string match, respectively. The third and fourth are where semicolons fail: you need to actively parse the list, perform multiple substring matches, or otherwise jump through hoops. Fortunately, most people looking for somewhere to eat are looking for a "One" query, so semicolon lists are fine.
This doesn't apply for other things like auto repair, where an "All" query such as "I want four new tires and an oil change" are reasonably likely.
|(Semi) automating street name expansions||almost 2 years ago||
Which expansion of MT HIGHLAND DR would you recommend? Is it "Mount Highland Drive", or "Montana Highland Drive"? Or just plain "Mt Highland", as Google seems to think?
|What shall we have for diner tonight?||almost 2 years ago||
You should probably tell Taco Bell, Subway, Panda Express, and any number of pizza joints that they're doing it wrong. You might consider "fast food" to be a type of food; I (and probably most other people) consider it a type of food service.
|Are you joking ??||almost 2 years ago||
I'm not seeing the alleged joke.
If you're referring to the grid pattern in the forest, it's real: the Pacific Railroad Acts granted alternating square miles of land extending to the sides of the track to the companies building the transcontinental railroads. In rural areas of the western United States, much of this ownership pattern still exists.
|Learning the OSM Way||over 2 years ago||
The mast/tower problem stems from trying to group three things (roughly: European radio towers, American super-tall antennas, and cell phone antennas) into two categories.
|Why Search and Rescue Organizations Must Map Out Cellular Phone Towers in OpenStreetMap||over 2 years ago||
People who get lost in the woods are almost never abducted. They twist an ankle, or run out of water, or eat the wrong berries, or come off second-best in a struggle with an insane squirrel, but abduction? Almost never happens.
|OpenStreetMap past(s), OpenStreetMap future(s)||over 2 years ago||
There's a confounding factor that I don't think your data accounts for: there's been a trend from mapping points of interest as nodes to mapping them as areas. This will tend to inflate the "nodes created" count (something that, in the beginning, would have been mapped as one node is now four or more), and at the same time, will tend to decrease the "nodes modified" count (if a building changes ownership, the tags on the area will change, but since the building structure is unchanged, the nodes won't be modified).
|Why local assumptions are wrong for an international project||over 2 years ago||
It's not just natural language that's the problem. The thing that's been bothering me lately is "amenity=fuel". According to the wiki, available gasoline grades should be indicated using the European RON system, but American fuels are graded using the AKI system, and you can't mechanically convert between the two. For reasonable hydrocarbon blends, an AKI 87 fuel (the most common grade in the US) could be anywhere between RON 91 and RON 93 -- which means you can't tag correctly.
Since you can reasonably assume that any American gas station will have AKI 87 and AKI 93 (or their elevation-adjusted equivalents), I've given up on trying to map them, and I'm just concentrating on identifying stations with diesel (which you can't blindly assume that any given station will have).
|Welcome to the new Missing Maps||almost 3 years ago||
The problem with gamification, and with metrics in general, is that you get what you measure. If you reward people for the number of widgets produced, you get hastily-made, low-quality widgets. If you reward the QA team per bug report filed, you get backroom deals where the programmers agree to include easy-to-spot bugs.
In the Missing Maps case, the leaderboard rewards people for number of edits (the default sort order) and to a lesser extent, the number of buildings and length of road mapped.
Edit count is easy to game: submit one edit per building or per road segment. This doesn't have any downside to the finished product, but does have an unfortunate impact on the internal workflow: checking recent changes becomes much harder, because of the increased volume of data.
The other two categories are more problematic. Rewarding for length of road biases people towards finding "roads" that are actually dry riverbeds, or animal trails, or field boundaries, or other things that look similar on an aerial photograph. Rewarding for building count means you'll get "buildings" that are actually rock formations, or off-color dirt patches, or the like.
In the worst-case scenario, you could get people sabotaging each others' efforts in order to maximize their own credit. I don't think a simple leaderboard is sufficient incentive to do this, but given some of the things I've seen people do on Wikipedia, I wouldn't be surprised if it was.