OpenStreetMap
Kex Gill (humorously named the “Côte de Blubberhouses” for a stage of the 2014 Tour de France) is a road in Yorkshire between Harrogate and Skipton. Part of it is gradually sliding down the valley that it is built half-way up the side of and is being rebuilt; it was the access tags on bridleways there that caught my eye in the first place.
The diameter_crown tag is fairly well used for trees. It’d be nice when showing trees to show larger ones as larger than smaller ones. One challenge is that the values can be a bit hit and miss. There are a couple of sorts of issues there:
One is “obviously silly values from an import gone wrong” like the 289 diameter_crown=width: 2.0; color: green; that have found their way into the database, perhaps by a failed JSON conversion.
Another is “human but not machine readable values” like “4 - 7 m”
Another again is implausible values for certain tree types. For example, this is apparently a London Plane that is 5 times wider than it is high. That’s technically possible with a bit of pruning, but unlikely. Much more likely is that the data was not sanity checked before import, and the “diameter” figure here is actually a “circumference”.
In order to work around these issues, when processing the data prior to display I:
Lots of people use editors such as iD, Potlatch, Vespucci, GoMap!! etc. for editing. There are entirely sensible reasons for this - I’ll always try and edit relations in Potlatch or iD since for me editing relations there is a much saner experience than in Josm. However, one thing that they miss is Josm’s Validator, which can check for relation errors that other editors can’t. Here’s how to use that to detect problems, and then fix them elsewhere.
I’ve created some test data on the dev server for this, so that I can deliberately create and fix errors. If you want to test with that data on the “dev” server, you’ll need to create an account there and tell Josm to login to that server - or you can just look at the screenshots below.
First, you’ll need to download Josm (I just downloaded the latest .jar file) . Josm’s user interface will be familiar to anyone who used CAD software in the 1980s, but may be less so to others.
Then you’ll need to download some data in the area that you were editing (file / download data / download). So that you can see what is where, it helps to have a background layer - “OpenStreetMap Carto (standard)” will work, or you can use an imagery layer if you prefer. Zoom in to your area of interest, select with the mouse and “download”.
Then click “validate” (on the row at the very bottom right of the screen).
I maintain a web map style that shows walking and cycling route names. For the cycle routes, it shows the ref. For some time I’ve massaged some of the names so that e.g. National Byway loops show as “NB (loop)” just like on the signage. However, as can be seen from the example above, some hiking route names are a bit convoluted - they’re more like descriptions than names.
For example, osm.org/relation/3971851 is the England Coast Path. Open up the list of members to see the names, which includes such delights as “King Charles III England Coast Path: Southend-on-Sea to Wallasea Island”. I’m pretty sure that it doesn’t say that on the signs there.
I created this for my own use, but am sharing it here because it might be useful to other people too. This is the style and there’s a brief readme.
It uses different colours to highlight different map layers. It’s not supposed to look nice; just to show you what is there.
I believe that everything described in the schema is included. If a feature does not appear it might be because:
There are lots of features in the first category, and there seem to be a couple in the second. If anyone finds anything in the third category please let me know!
Recently, there’s been quite a lot of discussion about the problems with using the tag “highway=path” in the forum. See for example threads here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here, here and here - and that’s only the last month or so!
On it’s own, “highway=path” doesn’t really say anything other than it’s somehow possible to get from one end to the other. Have a look at the pictures in the wiki - all of those are regularly tagged as “highway=path” in some regions.
There are some really bizarre examples out there. Up the Hillary Step to get to the top of Everest? highway=path. A scuba diving route? highway=path.
While it is possible to add extra tags to say a bit more about the feature being mapped, often this simply isn’t done.
A data consumer (map maker, routing app creator or even just a human deciding whether to go for a walk somewhere) can’t tell what they’re going to find.
The idea is that you can tag a path for pedestrians as “highway=path; foot=designated” and one for cyclists as “highway=path; bicycle=designated”.
The problem here is that “foot” and “bicycle” are “access” tags, and these aren’t always “yes” or “no”. Valid values might be “customers”, “destination”, “permissive” amongst others. If the “foot=designated” on a “highway=path” implies “foot=yes”, what should the tagging be if only customers are allowed?
In countries with some form of allemansrätten (much of Scandinavia, some other places in Europe, including Scotland) this is less of an issue. If you know you can go pretty much anywhere you don’t need to explicitly tag “foot=yes” on everything, and tagging “highway=path; foot=designated” isn’t a problem.
For some time I’ve been looking after a raster map style that’s designed to be a useful “England and Wales rural pedestrian” map, and also to showcase some of the richness of data that might not be obvious from basic “general” map styles such as the ones on OpenStreetMap.Org.
A goal for some time has been an offline version of that map style. At any useful level of detail that requires different technologies to be used, and the first parts of that - a vector map schema and a web map style - are now available (though not yet available offline).
The online version of that map is available here. It’ll take a couple of seconds to appear.
My previous diary entry looked at the UK section of this OSM wiki page. A commenter there noticed that neither the wiki table nor my analysis covered highway=track (covered here) or highway=service (left for later).
We’ll use the same approach as before. Essentially, that’s this urban area (and this when looking at designation), and this rural area.
It’s useful to look at designation because that tells us what some of the access values should be, and also local authority data about public rights of way such such as visible in this overlay. We’ll therefore ignore ways in OSM with designation set but look to see if any of our examples “should” be designated as a public right of way.
After reading this forum topic and commenting that the United Kingdom part wasn’t great because it didn’t consider the different rules in England and Wales, Scotland, and Northern Ireland, I wondered “what should the defaults actually be for England and Wales?”.
Of that table, I think that the rows down to living_street are correct, and of the remaining rows the columns across to moped are also correct. I decided to pick a couple of areas I’m familiar with (one urban, one rural) and look for examples in those areas without explicit access tagging. Based on that it should be possible to suggest some sensible defaults.
The default of no for everything through to moped is correct, which leaves horse, bicycle and foot.
https://overpass-turbo.eu/s/1P4E
https://overpass-turbo.eu/s/1P4G
Mostly these ways are foot=permissive, and there’s no horse signage. In some of the parks horses might be tolerated; elsewhere likely not. This suggests horse=no here.
https://overpass-turbo.eu/s/1P4I
https://overpass-turbo.eu/s/1P4H
Mostly these ways are foot=permissive or =yes, and there’s no horse signage. In some of the parks horse access might be =permissive; in most cases not. This suggests horse=no for these as well.
https://overpass-turbo.eu/s/1P4J
https://overpass-turbo.eu/s/1P4K
Mostly these ways are foot=permissive. In a large number bicycle access is explicitly disallowed.
https://overpass-turbo.eu/s/1P4L
https://overpass-turbo.eu/s/1P4M
Mostly these ways are foot=permissive or =yes, and on some (but not as many as the urban ones) bicycle access is explicitly disallowed. However there are also some designated “public bridleways” which should be tagged bicycle=yes but are not, perhaps because bicycle access is legal but implausible
https://overpass-turbo.eu/s/1P4O
Lots of people have written diary entries and there have been other announcements and demos. You might wonder why we need another?
The idea of this is to provide a “soup to nuts” guide in a similar style to the existing “Switch2osm” Serving Tiles guides for raster tile servers.
There are two major pieces to this. The first piece creates a set of vector tiles that can be served by a web server. The second provides a way for clients to access that data - and clients also decide how to display it.
The code in this example is for web clients, but it’s also possible to create other sorts of clients too (for example, Android or iOS apps).
Let’s imagine that you’re a pizza delivery company, and you’ve got an app that shows where you are, where your customers are and where a delivery person is between the two. Obviously you need some sort of map that shows the three in context. You can’t use Google Maps for cost or other reasons, and whatever framework your using will accept raster tiles in the almost universal format https://server/Z/X/Y.png, so why not use OpenStreetMap’s standard layer? After all, it’s free!
Well:
There’s lots of data stored in OSM about bus stops, but often maps and apps created with OSM data don’t make much use of it (with OsmAnd being the notable exception). For here’s a bus stop as shown by OSM Carto:
You can see that it’s a bus stop, and you’d be able to see the name if you could zoom in a bit more. However, in OSM there’s actually lots more information. For the map styles that I look after (both web-based raster maps and for Garmin devices) I tried to add a bit more detail. Here’s the result:
Although the raster maps at maps.atownsend.org.uk support zoom levels up to 24, until recently I’ve not made much use of that for showing extra data. However, there is a lot of room at these high zoom levels - as the picture above shows, enough for all the directions on this signpost here.
The name is shown as normal at lower zoom levels, then as you zoom in the directions are shown too, as you can see here.
A major rewrite here takes into account tags such as natural, reef, wetland, surface and tidal before deciding how to show wetland areas. See the picture above, which is here, and here in OSM.
The beach between high and low tide can be clearly seen here (in OSM, here). There are blue dots in the sand rather than black. A deliberate decision was taken to show more detail for areas above low tide. See e.g. here between Wales and the Wirral (see here in OSM).
There’s lots of software around to work with OpenStreetMap data - querying it, creating maps from it, using it for navigation. One area that there has historically been less support is analysing OSM changeset data. As an example, here is one of mine.
However, many years ago Toby Murray wrote ChangesetMD. That can be used to maintain a database of changeset information (tags, discussions, etc.). Martijn van Exel updated that to a recent version of Python and I made a couple more changes to support very recent Python versions and made the replication more scriptable.
Over on the planet.osm.org site, there’s a download for all the changeets generated at the same time as the weekly “planet” file is created, and also one for all the changeets and discussions as well. The changesets-only one is just over 6GB (bzipped), and the one with discussions as well is only about 250MB more, because most changesets don’t have discussions.
If you’re not interested in changeset data dating back to 2012 you don’t need to download this file; you can just start replicating from whatever point in the past you are intereted in starting from.
If you’re on Debian or Ubuntu, you’ll likely want to follow these instructions from a non-root user account of your choice (substitute that account for “youruseraccount” in the instructions).
From the virtual account created by the installation, which you can reenter by running
cd /home/${youruseraccount}/src/ChangesetMD
source .venv/bin/activate
Run something like this
python changesetmd.py -d changesets -c -g
The “-g” is optional and initialises the database to story geometric data. “changesets” in the line above is just the database name.
To load the database with changesets and discussions:
python changesetmd.py -d changesets -g -f ~/data/discussions-latest.osm.bz2
For many years I’ve used Garmin devices for both for navigation and for collecting data for OSM. As well as lots of premade maps in different styles it’s actually pretty easy to tinker with the map style yourself, although the OSM wiki makes it seem much more complicated than it actually is. It’s also pretty easy to see what OSM keys map to what values - there’s a file for points, one for lines and one for polygons that shows what OSM key and value corresponds to what Garmin feature.
I also maintain a web map style that tries to be much more inclusive than other web maps in terms of what it shows (have a look around the map legend for that), and thought that it’d be great to do the same for Garmin maps too. The web map style uses a lua script to preprocess OSM data before the CartoCSS code deals with it, which makes the latter much, much simpler. It turns out that exactly the same approach works when creating Garmin maps too, as described on this page.
I’ve added a new page to the switch2osm guide: “Manually building a tile server (Debian 12)”.
Mostly it’s minor changes only from Debian 11 and Ubuntu 22.04 - new versions of software, that sort of thing. Where new manual steps have to be carried out, the guide describes them. Debian 12 itself does have some differences - “syslog” is no longer created by default, so debugging changes slightly.
I’ve also updated a couple of other pages such as the replication ones to reflect that Debian 12 is now a supported operating system.
Separately to that, I’ve moved map.atownsend.org.uk (which uses a related may style) from an Ubuntu 22.04 server to a Debian 12 one. There was nothing wrong with the old one, but the hosting provider I use was offering higher spec ARM servers for essentially the same price as the old AMD one I was using, so it made sense to move.
Most hedges have been added to OpenStreetMap as lines. Most renderers show something like this:
and everyone’s happy.
However, from the beginning of OSM, people have mapped some hedges as areas, so for example something like this:
As there have been lots of updates recently, I’ve made a new release of all of the code behind map.atownsend.org.uk
There are releases for four repositories - the lua code that does all the hard work, the map style that determines what it looks like, the map legend, and the website for the map itself.
Here’s a summary of what’s new:
Rocky features are now shown in more detail: