@Rovastar: visibility is of low importance when you have a map, and of even lower importance when you have a GPS device. As you can use the map or GPS device to locate you. That’s the reason why not many maps render it. Contrary to sac_scale though, since that determines whether you’ll be able to use the path at all.

@laridae, ok, but now you have some comments to convince your club ;)

As to finding a better renderer, if the area isn’t too big, maybe you can display the tracks using Overpass API and the Overpass turbo styling ( osm.wiki/Overpass_turbo/MapCSS ). See http://overpass-turbo.eu/s/dpx for an example (shows the paths mapped with surface=asphalt in black), you can use color codes, widths, dash patterns and opacity. Though it’s currently not possible to stack different renderings with Overpass Turbo (which would be useful to get an outline color).

For the winter roads, see osm.wiki/Key:winter_road (or ice_road=*), these tags should also apply for paths, but I really doubt if any current renderer displays it.

1. OSM is a data provider, not a service provider. So search isn’t a service OSM should provide to the public, but providing it to help the mappers is enough.
2. Google is a competitor, so it’s normal they don’t show our results anymore (they used to do in the past). When you look f.e. on DDG, you see that OSM appears on the firs page, while Google Maps doesn’t: https://duckduckgo.com/?q=Millennium+Oakwood

Of course there are other search methods. My preference is the !osm bang of DDG (which is my default search engine). Note that I don’t always like the search results from DDG, but it’s so much easier to type !osm for OSM, !w for Wikipedia, !g for Google, !i for Google images, … than having to go via links or selecting an alternative search engine.

The most important difference between JOSM and other editors is that JOSM works with modes (by default).

So if you’re in “add” mode (by pressing the ‘a’ hotkey), every click will add a point to a line (double-click to stop the line). If you are in selection mode (with the ‘s’ hotkey), clicks will only select features (and allow you to tag them).

Then you have a lot of specialised modes (some need a plugin to use them), like building mode to draw rectangular buildings, or way-alignment mode where a click will move the points of a way.

Once you know that, learning JOSM gets easier.

@laridae, yes, the default renderer is not a specific renderer. When I mean a specialised renderer, I mean something like this: http://www.wanderreitkarte.de/index.php?lon=8.3677&lat=47.4782&zoom=16&lang=en (see osm.wiki/Hiking#Mapping_Projects for alternatives)

Though that one also doesn’t render the trail_visibility key, but does render the surface and sac_scale (it’s limited to Europe because of server resources though).

The main map is not specialised at hiking, and users of the main map style should never expect something that renders as a path to be passable with sandals (though trail_visibility says nothing about the needed footwear, a path through a big grass field can also be more or less invisible, you should use sac_scale to show users what footwear they need to ware).

And it’s true you would be giving the path data away. The whole point of OSM is about giving data away. I’ve worked many hours and days, just to give away the data I collected. According to recent stats, we’ve worked 61 labour years on the data, in a small country like Belgium: osm.org/user/joost%20schouppe/diary/37481

But you can change your business model to be a “service” based one. As you see, there’s a lack of good renderers for the data (and most of the good ones are limited to Europe), and even then, it’s not handy to take your computer on a hiking course.

So you can contribute your data to OSM for free, and offer members a good rendering style to view the map (OSM data must be free, rendering styles can be protected by copyright separately and thus can be private). Or you could go even further and offer high-quality printouts to the members.

This tag too: osm.wiki/Key:informal

OSM data is public, if you want private data, you should use your own database (which can be combined with OSM data when you follow the license clausules closely).

But it’s also possible to add those paths to the public database. There are certain tags you can use to mark paths as nearly invisible, or nearly impassable.

See * osm.wiki/Key:trail_visibility * osm.wiki/Key:sac_scale * osm.wiki/Key:smoothness * osm.wiki/Key:surface * osm.wiki/Key:tracktype

When tagged correctly, dedicated maps will render it in a style so it’s obvious for users.

Taking maps from Wikipedia will be best for you. OSM is too precise to download and render all boundary data easily. So it’s better to use a Wikipedia map. You can take this map and update it with data you like (don’t forget to upload it back again when you fixed the map). Updating isn’t hard when you download it as an SVG file and open it in a program like Illustrator or Inkscape.

OSM doesn’t gather data like the usage of voting systems either. So you won’t find more info on that subject here.

Very interesting stats.

But next to the time mapped on the first event, it would probably also be nice to see the amount of work done on the mapathon (number of nodes, number of ways, number of tags, …)

Measuring the number of elements isn’t such a good way to determine the value of the work (it doesn’t matter if all landuse is complete, when even the most important streets aren’t present). But given that mapathons usually focus on a certain job, it should be more comparable than regular mapping I guess.

I agree with Richard that the lack of knowledge on iD is often a very real problem for potentional teachers. And I guess Joost would agree too, as the quest on the talk-be mailing list to find someone who feels comfortable with iD and wants to teach it is still going on.

Great stats Joost, though I’m really scared by that one stat: 44% of nodes coming from one person in Flanders.

It’s almost like having a monopoly on mapping. That’s not really a healthy community. Who will maintain the work when he stops? Does he decide how things are mapped throughout the country?

It really frightens me.

Tbh, it’s better to work locally. The original thought is: of everyone maps his own house, OSM will be a nap with incredible detail.

Now, that’s of course an exaggeration, but I do find that everyone should stick to his own region (with the exception of humanitarian mapping, but that’s just because they don’t have the tools to map yet).

By sticking to your own region or city, you can add a lot more detail (like POI) that aren’t visible on aerial pictures, out in any database. You’re also more responsible of the area, so the data quality is higher and its more up-to-date.

If osm would just be a data dump, it would have been set up differently.

So I wish you all the best, but no, I won’t help (you’re doing great already btw).

Bing doesn’t require a source=* tag. So it’s practically impossible to figure out what impact Bing has.

I just know one thing: I’ve used Bing a lot while mapping, even when my source data was actually a survey. Thanks to Bing, the road network in Belgium was completed (it was impossible to find missing roads without aerial images).

Are those cranes randomly generated on construction area?

OSM is not a shop, we don’t sell maps. OSM is just a volunteer organisation that gathers geographic data.

It is possible (and legal) that some people transform the data into a nice map they can sell. But then you should contact those who make the map, instead of us, who only gather the data.

Just a note: watch out with aligning to bing imagery. Bing doesn’t always have the correct alignment, certainly not on uneven terrain (which is usually the case near riverbanks).

What we speak, or what we read?

I speak almost 100% Dutch, but I normally set all my software to English. Not because Dutch translations are that bad, it’s just easier to communicate with others when using the same terms. I used to look up term after term when submitting a bug report, but now I don’t have to do that anymore.

There’s a conceptual difference between the European refs and the US refs.

In Europe, it’s custom that an official body gives a road one and only one ref. The ref is only used to name the road, but with numbers as they lack some naming inspiration. This means that refs don’t have to be continuous. F.e. a national road can stop when it meets a ring-road (who have their own ref system in many countries), and start again on the other side of that ring road. Expressing this with route relations would be silly: routes are supposed to be continuous, our refs aren’t.

The fact that the EU also gives their own ref to the road doesn’t change that principle. They use their EU ref to name the road, while nations use their national ref to name the road. In most cases, the nation prefers to keep using their refs and their refs only. In other cases (like Belgium), the nation adopts the European reference system, and is phasing out the legacy national refs where EU refs can take over (that means sings get replaced, maps get updated, …).

This is completely different from route refs, where a route is bound to be continuous, thus some roads belong to multiple routes. The route reference system you mention is indeed more similar to PT, bicycle and pedestrian routes than to the European ref system.

The difference is IMO big enough to need two ways of tagging. So I agree with Richard: you can go ahead with the US (though the US community should decide on this), but the schema you propose won’t work very well for Europe.

It’s easy to unify measurements when you get the units. It’s hard to estimate the units when you get the unified measurements. If an editor wants to display the originals, but only gets the SI units, then it will have a tough job (and quite likely show mistakes in some cases).

So in a typical case of being lazy, the easiest method should be implemented.

Also note that it’s not only about the two main editors, there are also numerous other apps that display and allow edits to tags. Think of the general OSM site, vespucci, and even apps like OsmAnd.

I do agree with SK53. It would be nice to have a standardised database (or maybe just a program to create such a DB). It would allow complex things, s.a. having defaults per country. (lit=yes should really be a default for Belgian roads f.e., around 98% of our roads are lit). But this doesn’t belong in the main database.

Nice tool, though I’m seeing certain issues.

First of all, in my area, most of the issues found seem to be very short road pieces, only a few meters long, part of a big road. They’re split up because of route relations, or changes to tags like speed limits. Is there something that makes detecting these small segments easier? See most issues in this area: http://improve-osm.org/trafficFlowDirection/#11/51.0008/3.0933

Secondly, do you take dates into account? Traffic layouts change often, and streets might change their oneway direction. Perhaps it can be detected by seeing that from a certain date on, 90% of traffic rides in one direction (if the sample is big enough).

Bonjour Sylvain,

Je suis aussi Flamand, mais de la coté Belge ;) Excusez moi donc pour mon français, ce n’est pas ma langue maternelle.

Je visite parfois les monts des Flandres, mais je reste à la coté Belge normalement: Kemmelberg, Monteberg, …

Peut-être je peux vous aider avec un link vers le wiki: osm.wiki/Mountain_biking Cette page explique certain tags spécifique pour le VTT.

J’espère que vous vous amusez avec le découvert des chemins nouveaux, et que OSM s’améliore dans le Nord.

Very nice work you’re doing.

Your workflow is ok, but you won’t get anywhere on your own. You should probably try to get it in as many editor and QA apps as possible.

• The JOSM validator (warn that a tag is lacking on those nodes)
• The JOSM and ID main style
• QA sites like keepright and osmose
• …

Also, the style could be improved. AFAIK, it’s possible to rotate icons to the way orientation, in which case you can make the arrow+stop sign rotated in the right direction (then you don’t need to show the way direction). See https://josm.openstreetmap.de/ticket/10217

This should make more mappers use this tagging, and in turn help the routers. I’m looking forward to that.

(note that some types of traffic light tagging could use the same direction tag, so you could apply the rendering there too.)