Richard has commented on the following diary entries
|email rejected||15 days 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||24 days 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||28 days 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||29 days 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||about 1 month 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||2 months 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||3 months ago|
|Editing||3 months 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||4 months 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||4 months 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||5 months 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||5 months 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||5 months 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.
|Losing faith in OpenStreetMap||5 months ago||
Genuinely sorry to see you go.
For those not aware of the background, some of the discussion at https://help.openstreetmap.org/questions/41053/prow-tagging-england-wales may be relevant.
|Don't know what to think of it of this research||6 months ago||
Assuming the "research" quoted is academic, I wonder what the ethics committee of their university might make of this...
|"Duck Lanes" on OSM?||6 months ago||
It's a rather lovely stunt though. When I worked at BW (CRT's predecessor) the press office were always on the hunt for quirky stories that would get them in the papers. I'm delighted that they've finally found the answer and that the answer is "ducks".
|Birchville Picnic Area, Upper Hutt, New Zealand||6 months ago||
Welcome - good to see some mapping activity there (I was visiting relatives up the Akatarawa Road just a month ago!).
|map styles: Default OSM vs Humanitarian||7 months ago||
paulbiv - you took the words out of my mouth. Spot on.
The Google Maps style is increasingly designed as a backdrop for location-based search results and for (car) direction polylines - hence the incredibly minimal style. That's fine for them, but it's not something we should seek to emulate.
(Still, I'm really pleased to see Mateusz tackling the wider issue.)
|Details about iD editor users get publicly, permanently and silently logged with every edit – a privacy breach||7 months ago||
I think you're extending own values to other people here.
By definition, people who believe that any piece of identifying information is a "privacy breach" are more likely to use JOSM. That's fine. That's their choice.
For a different userbase this is really helpful information. The language means other users are more likely to be able to assist them via changeset comments, for example.
Please don't assume that everyone shares your beliefs, especially given that you come from a country and culture known to be much more sensitive to these things than the average. For example, my home address is readily viewable by a whois lookup, and a picture of my front window has just been retweeted 40 times. ;)
|US County Roads (from residential to track)||8 months ago||
@Aury88: I'm a European mapper, I'm just helping out in the US! But as maxerickson says, they're not agricultural access roads - they're just rural roads. You or I have every right to drive or cycle along them, and indeed I might consider them a pleasant cycling alternative to the busy main roads.