Richard has commented on the following diary entries
|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||about 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||about 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||about 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||about 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?
|New road style for the Default map style - highway=path is evil||over 1 year ago||
highway=path is most certainly not "a British thing". It was invented by a mapper from Germany (Cbm) and one from America (Hawke) in 2007. Most active British mappers have had the sense to steer well clear of this disaster of a tag, and continue to use highway=footway, =cycleway and =bridleway. (Taginfo reports that, in Britain, highway=footway is used 400% more often than highway=path; elsewhere, highway=footway is used only 25% more frequently. In other words, don't blame the British.)
There is one sensible way of dealing with highway=path, and that's to use Lua processing (available in osm2pgsql as well as other tools such as OSRM and tilemaker) to rationalise it into other, more meaningful values. For example, if you have highway=path, foot=yes, bicycle=no, horse=no, then you can recast it as highway=footway - and so on. This is what cycle.travel does for both rendering and routing.
This would require a database reload, of course, but I believe that'll be needed sooner rather than later anyway.
Of the other changes, there's some good stuff here but there's too much 'zing' to the new highway colours at z10/z11. Looking bright may be a worthwhile aim; looking luminous probably isn't. But given that changes to the current osm-carto style are a bit "deckchairs on the Titanic", and we should really be thinking about moving to in-browser rendering of vector tiles - which opens up all sorts of stylesheet and interactivity possibilities - I won't press the point.
|Potlatch without Flash||over 1 year ago||
I'd anticipate that Shumway (JS Flash interpreter) performance will become tolerable by the time that Flash Player finally disappears from desktop browsers. There's also the option of distributing as a desktop app using Adobe AIR.
|New road style for the Default map style - the first version||over 1 year ago||
Please - don't get confused into thinking that the current OSM colour scheme is Ordnance Survey-derived. It isn't. It's the British cartographic standard, no matter what mapmaker. In actual fact, Ordnance Survey were the laggards in switching to green trunk roads on many of their maps.
Blue is a common colour worldwide for motorway signage, hence the use in maps.