Thanks - that’s certainly my current experience with Firefox. I have it working with ID on Chrome(ium) though, which is a big step forwards. I’d prefer to use JOSM, but this is better than nothing.

Thanks UrbanRoaming - I’m having a go with ID, but failing at the moment. And Strava seems to get grumpy and refuse to log in a second time. I’ll keep trying - this is irritating.

Hello - I’m a regular user of Strava heatmap data for much the same purposes as you describe. At the moment I’m completely failing to get access to the heatmap on the JOSM editor. It’s clear that recent changes at Strava have upset some of what’s needed to see the heatmap on OSM editors, and that some of the instructions on the setup page you link to are no longer correct. What editor are you using, and how are you setting up the heatmap?

I’d like to get this working again and to update the instructions!

Just a thought. When looking at how ‘clustered’ points are, have you remembered that you may need to change the map projection before comparing two images at what is the same ‘zoom level’. On looking at your Canadian image (above) I was immediately struck by the fact that you’d stuck with the standard ‘Pseudo Mercator’ coordinate reference system / projection - which will have wildly distorted this map in comparison to clusters in other geographical locations. This wouldn’t have mattered necessarily, except that the maps sit in a sequence, appearing as comparisons.

Don’t gloat too loudly… we lost Little Cumbrae, at least on the current rendering of Opencyclemap (at June 2015). I hope the issue will be fixed sometime soon - the ‘natural=coastline’ tag had gone missing (I put it back). way/4496238

Joost Schouppe - thanks - I’m glad to know that other people are continuing to think about this. While you’ll be able to tell that I think I may have come up with a workable system (as proposed) I’m actually less worried about the detail and more about making sure that this gets sorted in a workable way one way or another. So long as people start worrying about this and testing ideas we ought to be able to sort it.

There’s been one key thought knocking about in the front of my mind for the last week; we get away without having to worry about a categorisation of roads for one reason and one reason only. Someone else has done the categorisation for us.

There are all sorts of real issues with categorisation of roads, but the whole reason that any(many) of our maps make sense is because they are categorised. The categorisation always has flaws, and is always based to some degree on relatively arbitrary decisions… but we get away without having to worry about these arbitrary decisions because some official body has done this.

So we get to map lovely comfortable ‘facts’ and to pretend that opinions don’t belong on OSM.

(I should say that I’ve come across a limited amount of discussion about the issues with road classification - but 99% of people seem quite happy that road classifications are used as a way to understand/draw maps and to influence routing algorithms.)

I was out again mapping recently - and once again found myself being absolutely forced to map my opinions rather than facts. Some paths had to be missed off the data because adding them would lead to confusion. In an effort to support clarity in mapping I had to decide what deserved to be mapped and what not… an arbitrary decision at the highest level - all because there is no way to categorise.

I now have a favourite path in mind as proof that we can’t just map facts and leave categorisation to those rendering maps. On my local hills there’s a path… it’s about 8 metres wide at one point, is usually about 4 metres, and occasionally narrows to 1-2 metre. This happens over about 800m of path length. It’s surface is primarily grass in terms of proportion of surface material. For much of its length what actually defines its use and appearance is that short but significant sections are very muddy. The muddy sections dry up for some short but relatively significant (but variable) periods in summer. The path is clearly not used ever for vehicles, but in other respects could be called a track (it’s certainly wide enough). Early on the path is consistently grass, wide, and because the grass is firm it’s not particularly obvious (being defined really by a line of new trees). Later the worn parts become gradually separate narrower paths which are too close together and too complex and too numerous to map individually, but the grass is no longer used for walking on.

The key question is: how do we tell potential path users something useful about this path?

We cannot map the facts (using a human mapper and working at the scale that OSM recognises at least). This is entirely an impractical idea. There are not even any average facts which help.

I can put things into simple words which define it well though…. this is a wide key path, created by wear by walkers, cyclists and horses, initially on smooth firm grass, later with significant usually muddy sections, and later deeply rutted with surrounding rough grass.

Surely we can’t continue on OSM to simply call this ‘a path’ and be happy with this?

I was surveying some paths today and wondering about this proposal while I did so. One thought was whether some kind of numbered score would allow for the creation of a hierarchy. So 2 points for an obvious path, 1 for indistinct, 0 for an invisible one. 2 for a wide path, 1 for a narrow path. 2 for a flat path, 1 for a gentle angle, 0 for a steep angle…. but then I started thinking that my original proposal brings in these things, but also surface quality and smoothness. Now it starts to seem far to complex: 2 points for good tarmac, 1 for a bit rough, and 0 for very rough (BUT we already know from the smoothness tag proposal that this is difficult to define). 2 for a bound surface, 1 for something loose or slippery, 0 for ??

Far too complex. Not memorable.

And one other thought - related to yesterdays comments. I was following woodland paths for a while. They were all woodland paths, but all very different paths. What was the main path and what was the informal hidden path was really obvious - but I can’t currently tag enough data for anyone to easily see this on OSM. What strikes me is that in any one place a change in only one feature makes the difference - in this case the real issue was just something about how well packed the surface material was. Width stayed the same. The basic surface material stayed the same. As things stand if I map these paths nobody will be able to tell that some are key good paths and some little used.

Hi Joost Schouppe. (Please forgive the length of this reply and poor grammar- it’s been a long day but I’m interested in your thoughts and want to comment this evening)

Route relations are good… I’ve used them a lot… but they serve a particular purpose I think. I can imagine that for a defined park it might be possible to use this system to say something useful - but I suspect that this starts to do something which is discouraged for relations (using them to categorise things rather than to map something definite which just happens to involve more than one feature). I also struggle to think how things would work once outside a defined area. Nice idea though - feel free to try to convince me/others further here if you like.

The proposal to name a set of path types as Sanderd17 suggests also appeals as I said earlier. But after thinking more I can’t think of a way to make this work in a sensible way. What we think would be a small set of path types I think would quickly mushroom into a very wide range of path types.

Unless someone can come up with around 6-8 categories (no more!!) which capture the kind of hierarchy that I’m aiming at. I don’t think that ideas like ‘forest path’ and ‘urban path’ will work - they raise far too many questions I think. Scanning in my head through the areas I’ve mapped I don’t see that I’d be much wiser… for instance I mapped a large park area on the West of Scotland which is on the edge of a small town but under woodland. You could call all of this urban path or forest path or formal path - some of it informal path or desire line or whatever. Fundamentally none of the sets of words i can think of would allow me to show you what the main paths are and what the faint desire lines are. Give me a bit of paper and I’ll draw you what is the main path, what’s secondary path, and what’s fairly faint desire line… but I can’t give you any sensible set of words to say the same thing (beyond what I just did).

Something like this would appear to work at first… primary path, secondary path, desire line, but it gives absolutely no information about path quality (so a primary path in one place would be a tertiary or secondary path elsewhere). And what happens when what is a primary path in one place becomes a tertiary path as it enters an area where it’s not changed but it’s no longer the primary path. I would like to think that something like ‘formal_prepared_wide_flat_path’ and ‘informal_narrow_steep_path’ would work (or simpler words to mean this), but I really can’t find a way to do what I think is necessary.

Can someone come up with the necessary categories? If the categories are to be simple they ought to be simple to conceive of and fairly easy to agree on.

You’re right that my system is intentionally hierarchical… so as you identify it asks us to accept that the ‘unobvious’ nature of a path takes precedence over everything else (whether it’s walkable or usable by wheelchair becomes irrelevant in the system). I concluded that this is an inevitable feature of creating a hierarchy. I do wonder if the hierarchy in my head is just the one in my head… would a competing system put walkability above obviousness for instance?

You raise an interesting issue… I’ve been reflecting on this kind of thing quite a lot recently. I’ve been discussing the advantages and disadvantages of different mapping systems (maps, data, open data, etc) - often in conversation with people who aren’t converted to see why OSM is useful. I’m now very much in the habit of saying that OSM is “just another tool”. I want to make clear that sometimes we should look to OSM, and other times we should look to another data/map source (Ordnance Survey being the obvious one discussed in the UK). The point is that these are different data sources… each with their advantages and disadvantages. When I want to know the precise location of something at street level, then (if the data is up to date) I go to the most precise Ordnance Survey data. When I want to know what paths and cycle paths are considered important in a town I start with OSM.

My point… OSM is what it is precisely because of how it works. This means that some things will be imperfect and potentially really really irritating. But it is what it is because of how it works. So we should do our best to improve the irritating stuff, but if it can’t be fixed then we need to learn to live with it. I have a list of really really big irritations with OSM, but I also use OSM mapping as my preferred navigation tool when on a bike because it’s the best source of information.

The beauty (and pain) of crowdsourced data and open source (etc)….

That’s a really interesting line of thought Scruss. I tried to write the proposal so that it would work internationally, but I’m painfully aware of having little or no proper awareness of worldwide differences in OSM tagging. I’m not thinking of English speaking nations really when I say that - I’m thinking that very different things could be going on in non-English speaking countries without me being aware. I did ponder looking through other language versions of the wiki documentation armed with Google Translate… but haven’t tried yet. Could it be that elsewhere people have been developing good ways to tackle the issues I’ve raised?

Thank you :-)