Richard has commented on the following diary entries
|It is not safe to cycle in Britain (a rant).||about 1 year ago||
"Not safe at all"? Don't be daft.
Are you at risk on a bike? Of course you are. The risk varies from place to place, from road to road. But extrapolating the bad shit that happens - and I wouldn't deny it does - to the one-in-six lethal odds of Russian Roulette is utterly disproportionate.
Yes, things need to get better. But try driving across London instead and watch what that does to your blood pressure and general life expectancy. The bike is still the best choice for sub-5 mile journeys, most places, most of the time - especially if you're canny about your route choices, which is where OSM comes in.
And if you'll now excuse me I have an awesome cargo bike project to build up.
|Cygnus Field Report||about 1 year ago||
This looks really good. I like Mike's mention (in your other diary entry comments) that "I populated my reference data (from latest county GIS) with a surface attribute, as well as an updated review against current imagery to identify roads that have deteriorated into tracks". If we could use this to add surface=unpaved to unpaved rural TIGER roads, then hallelujah.
|personal mapping links||about 1 year ago||
They weren't. I coded the 'all diary entries' view on May 4 2007, one day before the Rails port went live for the first time.
The user diaries were intended for mappers to write about their mapping activities.
|10.000 broken Turn_Restriction in the OSM Planet File||about 1 year ago||
@Amaroussi: would you like to provide a citation for your blanket statement? iD's turn restriction editor is excellent IMO.
|Geolocations of Wikipedia articles on the OSM map||about 1 year ago||
That's very cool. Did you parse the full Wikipedia dump yourself or is there a dump of just coordinates and article IDs/titles?
|Potlatch editing||about 1 year ago||
A handful of things, all in my obviously highly biased opinion:
Broadly speaking, for me P2 offers all the power I need but without a complex interface. When you say "I don't see much advantage to it compared with the other two", I'd say the same but the other way round - I don't see much, or indeed any, advantage to JOSM compared with the lighter and simpler P2. That's for my type of editing, of course, which is principally roads/cycleways/etc. rather than buildings, and principally rural rather than cities; and I'm sure that many people have editing requirements that P2 doesn't fulfil. P2 is really bad at fast worldwide tagfiddling, for example - JOSM is the unchallenged champion there. ;)
|OpenStreetMap Power Mapper Survey||about 1 year ago||
Oh, that sort of "power mapper"...
|Potlatch editing||about 1 year ago||
The changeset error has been fixed - an upgrade to the server software unexpectedly affected Potlatch. Sorry for the hassle.
Vincent: why not?
|UK NCN 44 rerouted||about 1 year ago||
That's definitely good news. Previous route was quite the hilly trek...
|Should we teach JOSM to first-time mapathon attendees?||about 1 year ago||
There's two variables which need to be taken into account. One, obviously, is the background of the learner: if you're a GIS professional you'll feel right at home with JOSM, whereas if you're a human being (ok, I jest, but a less experienced user) you'll probably take to iD better.
But the other is the background of the instructor. A lot of experienced OSMers have lots of practice in JOSM and very little in any other editor. This results (and I've seen it) in the instructor trying to use the online editor as they would JOSM, then getting frustrated when it doesn't work the same. On average, a JOSM-native instructor is less likely to give good tuition in iD than in JOSM.
|email rejected||over 1 year ago||
OpenStreetMap doesn't sell anything. Whatever "shop" you're dealing with, it isn't OpenStreetMap! Perhaps if you tell us the web address of the shop, someone can help.
|Proposal: Sunset ref=* on ways in favor of relations||over 1 year ago||
You're welcome to do it in the US (indeed, I'd encourage you to do so), but that's no reason why other countries need to adopt hard-to-edit, hard-to-parse relations for the sake of another country and the 0.1% E road edge case.
|Units in OpenStreetMap||over 1 year ago||
I'm not meaning to be harsh; I did read the blog post (and it's a little "harsh" of you to accuse me of not doing so!); and it's got nothing to do with parsing string values in Java.
The point is that OSM data is sufficiently complex that to do anything other than basic cartography, you have to parse the data programmatically - tags included. It's the only way to fully parse the complex path tagging schemes, for example, never mind crazy stuff like opening hours.
You do obviously accept this in some areas - for example, Graphhopper builds a routing graph rather than assume that OSM ways will always be split at junctions for the convenience of routers. Tags are no different. You should expect to have to work with them, rather than just parsing them straight out of a format designed for one particular consumer.
I asked you on Twitter yesterday whether Graphhopper could do this and your answer was "wait for the blog post". Subsequently someone on #osm-gb pointed me to https://github.com/graphhopper/graphhopper/issues/193, which explains that there is no scripting language support yet.
Scripting language support is how OSRM, osm2pgsql and tilemaker cope with instances like this, and I would commend this approach to you. Yes, I guess you could put it in your core Java app, but that seems a very heavyweight solution and mandates one way of parsing the tags for all your users. Right now I could parse maxweight tags trivially using one of those programs, without having to submit a pull request, and without having to use a heavy-duty language such as C++ or Java. It would be nice if Graphhopper offered the same flexibility.
I think you're overestimating how many editor developers we have!
|Units in OpenStreetMap||over 1 year ago||
On the other hand, if (say) you normalise speed limits from maxspeed=30mph to maxspeed=48.28km/h, that makes it marginally easier to calculate likely vehicle speeds, but breaks visualisations of what the signs actually say. You win some, you lose some.
So rather than adding the complexity to the editor software, where we're not blessed with a surfeit of developers anyway, add it to the client software.
osm2pgsql, OSRM, and Tilemaker can all solve this sort of problem with Lua tag transformations, and there's no reason there shouldn't be a common library between them. (Indeed, a common library would be very useful for hard-to-parse tags such as opening hours.) Maybe it's time for Graphhopper to catch up?
|Audio Mapping first steps||over 1 year ago||
I'm convinced that in this age of Siri, Cortana etc. we should be able to do automatic voice recognition for mapping. I've experimented a little with an iOS app and Simon added some interesting-looking (sounding?) functionality to Vespucci.
|How to find Missing Roads in OSM with GPS data||over 1 year ago||
Looks good. Could you remove the 'editor=id#' from the first edit button, and change the text to "Edit on osm.org", so that it chooses the user's default editor (usually iD, but may be P2 in case of user's choice or IE)?
|Editing||over 1 year ago|
|Editing||over 1 year ago||
This is a collaborative project. Collaborating - i.e. building on each others' work - is exactly what people are meant to be doing.
|About problems with [surface=unpaved; access=destination] roads||over 1 year ago||
imagico's idea of a grained fill pattern is interesting.
I generally favour dashed casing for unpaved roads (for example, http://cycle.travel/map?lat=44.1224&lon=-124.1114&zoom=15 ) - it's widely understood, doesn't conflict with other styling on the stroke, and means you can show unpaved roads on uncased strokes when you zoom out. As you say, though, it does leave open the question of what to do about tunnels.
One commonly used trick is to use dashed casing for tunnels while removing the stroke entirely. Removing the stroke entirely is one option (which, in Mapnik, I think would mean you'd end up drawing the casing as two dashed lines at +/- offset, and no 'stroke' at all) and can look good.
Another one is to use a translucent stroke for tunnels - probably entirely uncased, though you could try it with a dashed casing. I do this for my Illustrator canal maps.
One final option is a lighter stroke, with a solid casing in the normal colour of the road: for example, for current highway=trunk, 'normal' green casing with a lighter green stroke.
Your choice, but to my mind, the clarity of dashed lines for unpaved roads makes it worth investigating alternative solutions for tunnels.
|Potlatch 2: bookmarks||over 1 year ago||
You can jump to a lat-long by clicking the little 'search' icon (the magnifying glass beneath the +/- zoom icons) and then typing a comma-separated lat-long - does that help?