Richard has commented on the following diary entries

Post When Comment
How to find Missing Roads in OSM with GPS data 8 months ago

Looks good. Could you remove the 'editor=id#' from the first edit button, and change the text to "Edit on", so that it chooses the user's default editor (usually iD, but may be P2 in case of user's choice or IE)?

Editing 9 months ago

The King is dead, long live the King!

Editing 9 months ago

People who revise my work really don't know what they are doing

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 10 months ago

imagico's idea of a grained fill pattern is interesting.

I generally favour dashed casing for unpaved roads (for example, ) - 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 10 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 11 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 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 11 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 11 months ago

I hope that red - orange - white color scheme will be more universal that UK Ordnance styling.

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 11 months ago

Genuinely sorry to see you go.

For those not aware of the background, some of the discussion at may be relevant.

Don't know what to think of it of this research 11 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? 12 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 12 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 about 1 year 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 about 1 year 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) about 1 year 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.

US County Roads (from residential to track) about 1 year ago

Great to see someone else joining in the Herculean task of rural TIGER fixup.

I tend to take the attitude that guessing surfaces remotely is difficult, and that it's more important to get broad-brush coverage sooner (so that we might one day have a usable map) rather than very detailed coverage of particular areas. So I usually choose one of:

  • highway=track - unpaved and ungraded
  • highway=unclassified, surface=unpaved - unpaved but graded
  • highway=unclassified, surface=gravel - if the surface is apparent from the imagery
  • highway=unclassified - paved
  • highway=tertiary - good quality paved with centreline

highway=track implies unpaved so I don't usually add surface/tracktype tags when working from imagery.

How to find and analyse traffic ? about 1 year ago

It's certainly not something that's stored in OpenStreetMap. Some countries release traffic data openly but not many that I've found.

Fixing the rural US about 1 year ago

Yes, =residential is still a good value for that sort of road. I think the key there is to take the tiger:reviewed tag off (so it's clear it's not raw TIGER) and to make sure there's a surface tag if the road is unpaved.

It's not because you have accurate data that you have to upload all of them in OSM about 1 year ago

Splendid. Ok. Here's your challenge.

Write some polyline simplification code that reduces [1,0],[2,0],[3,0],[4,0],[5,0],[6,0] to [1,0],[6,0], yet is completely lossless.

Any programming language of your choosing. It's very doable.

Second task, since you ask for "challenges" (plural): adapt that simplification algorithm to permit minimal loss of geometry within the bounds of feature width and GPS accuracy. You may choose to implement an adjustable threshold as part of this.

It's not because you have accurate data that you have to upload all of them in OSM about 1 year ago

"All simplifying algorithms lose information"


If you have a polyline [1,0],[2,0],[3,0],[4,0],[5,0],[6,0], you can simplify that without any loss of geometry to [1,0],[6,0].

If you have a polyline [1,0],[2,0.0000000001],[3,-0.0000000001],[4,0],[5,0.0000000001],[6,0], you can simplify that (units permitting) with minimal loss of geometry to [1,0],[6,0].

"Minimal" is in the eye of the beholder, but given the width of the features we survey in polyline form in OSM and the positional accuracy of GPS units, it's clearly >0.

Still, as both Vincent and I are only editor coders, what the hell do we know about how these things actually work, eh, Rovastar?