Turbo roundabouts are relatively new. They first appeared in Nederland, but are now starting to appear in many countries, including the US. I have tried my hand at mapping one, guided by a few front runners, then did a second one on my own. This diary entry details what I learned. As I go on, I will add things learned to this diary entry!

See [roundabout=turbo] (https://wiki.openstreetmap.org/wiki/Tag:roundabout%3Dturbo)

Variations: It’s hard to find two turbo roundabouts that are exactly the same. This is what I learned: Take care to start with an easy one, and never blindly apply the prescriptions. You have to know what it’s for. That’s why this diary entry contains a lot of explanation: those are the things I learned from the experts! Too bad the three-lane rotor roundabout in Rosmalen has already been mapped.

Mapping a turbo roundabout with JOSM

Tools used

JOSM with a detailed aerial photo background layer and style Lane and Road attributes active. This job would be near impossible with Id.

Skills required

Basic OSM editing: drawing and tagging nodes, ways, areas and relations. Cutting ways (P). Link ways to existing nodes and ways (Esc-drop, M, N). Unkink ways. Extend ways. Combining ways (C). Reverse ways (R). Copy and paste elements (Control-C and Control-V).

Skilled editing: Adjusting lines with O (round) and Q (straight). Create turn restriction relations: tag, add elements and assign roles to, via from. Use existing turn restriction to duplicate and adapt for a new restriction. Route relations: download members, identify ordering problems and membership problems, and correct sorting errors.

What?

I used an existing roundabout junction, and assumed (after verification) the correct tagging of the roads involved. So no worries about names, refs, lit, speed, access, and what have you. As often is the case, I dealt with a primary road crossed by a smaller road at about right angles. The primary road splits before the roundabout, then gets pre-sorting lanes connecting to specific lanes on the roundabout, and rejoins behind it. The smaller road only has small triangle splits just before the roundabout. The junction already was a regular (two-lane) roundabout, tagged according to the roundabout wiki.

Why?

The basic goal is: a. Support realistic and accurate rendering of the roundabout; b. optimal routing for navigation; c. find this type of roundabout using e.g. overpass, supporting tools for maintenance, validation and quality assurance.

Work plan

Step 0. Download everything needed

You will need the roundabout and the area around it, to including the approaching roads up to the points where the lanes and the driving directions split/merge. Also, look which relations use the roundabout and download all members. This may seem overkill, but it reduces errors due to cuts and recombines of member ways, known to occur when the relations are not fully downloaded.

Step 1. Ground plan.

(This step is not absolutely necessary, but it does help!) Draw the centre island, other islands and separation elements according to the aerial photography and other available geo-layers. Draw the kerbs as barrier=kerb (right side is low side so draw islands counterclockwise). I also drew the truck apron as barrier=kerb + kerb=truck_apron, and used barrier=kerb + two_sided=yes for separation kerbs.
I always make sure the landuse around the roundabout is accurate. This always takes more time than I had calculated, using viewers, detailed aerial photography and such, but it’s worth it, e.g. when you look at a 3D rendering of the result.

Step 2. Draw the ways for road, road halves, and lanes.

Draw (or arrange/cut/copy-paste) all the road parts on the roundabout and the connecting ways, like you see on the aerial layer. Everything is drawn in driving direction. Alle road parts on the roundabout should be separate, single lane sections. Then draw all the connection lanes, split when necessary to make sure all presort lanes connect to the designated roundabout lanes.

I started rough, and after I got the connections in place, I smoothened out all the round parts (O) and straightened all the straight parts (Q). I didn’t know you could select a series of nodes then use O to round them or Q to straighten them!

I cut (P) and copied (Ctrl-C and Ctrl_V) sections of the roundabout and of the primary road to add sections, so most of the tags would be correct right away. One time, I extended a pre-sort lane from the primary road over the roundabout, then cut it at the point where it entered the roundabout. When adapting a regular two-lane roundabout, I learned that it helps to put cuts (P) in the roads on all places where you expect a split/duplication to be necessary, for an exit or an entrance lane, for a turn restriction, for a road relation or for a bus route, right after drawing the ground plan.

The first couple of roundabouts I lost my way in the multitude of connections and sections on and around the roundabout. After that, I worked more methodically. I started duplicating sections at one of the roads, then worked my way through all the roads around the roundabout, then did all the duplications and connections on the roundabout.

When I once discovered there was a bus route, I used these route sections for the path over the roundabout that the bus would have to follow. Later that was helpful in adjusting the bus route relations. I learned that buses going straigh over the roundabout, if they have a choice, they will follow the outside lane. That’s not a law, but a common rule in Nederland.

Conventions regarding geometry for lane splits.

• Road halves (for different driving directions) split “last moment”, that is short before the physical split.
• Lanes for the same driving direction split at the last moment where a motorist can decide.
• Lanes merge at the merge opportunity.
• Road halves merge right after the physical barrier stops.
• Lanes leaving the roundabout: split at the point where the rounding changes form left to right or the other way around.

Step 3. Geometry grooming

Position the connecting nodes for smooth lines. Use many nodes. The best way to round or straighten a section is to cut the section loose (P) and use O or Q on the object, which will also distribute the nodes evenly along the section, then recombine (C) sections as needed. Or click a series of nodes and use O or Q to smoothen it without the redistributing nodes.

PS Some entrances or exits actually are designed to be a real turn, not a smooth move. Turns lower the speed when approaching and entering the roundabout, which may be desirable. Other entrances and exits may be designed for higher speed and throughput on the main through route. Use your best judgement to catch reality in your model!

Step 4. Tagging, see below

Step 5. Turn restriction relations, see below

Step 6. Route relations: Road relations and bus route relations, See below

Step 7. Give_way nodes, see below

Tagging

When adapting an existing roundabout, most of this is checking and adapting existing tagging

Principles - checklist for tagging

Highway and junction

Road sections on the roundabout get the highway value of the most important road going through over the roundabout (not: ending on the roundabout!). Except the two pieces of the lower class road connecting the two lanes on the roundabout; these get the class of the side way. behalve de stukjes zijweg die op de rotonde de twee banen verbinden; die krijgen de klasse van de zijweg. See the roundabout wiki.

All ways on the roundabout get junction=roundabout, and (recommended) roundabout=turbo.

Oneway

oneway=yes on all sections connecting to the roundabout. De sections on the roundabout have junction=roundabout (sometimes junction=circular) making them oneway implicitly.

Lanes

Connecting sections with 2 or more non-separated lanes get lanes=2. All sections on the roundabout get lanes=1, because they are all drawn as separate ways. Accessing road sections with lanes=2 get turn:lanes=…|…, according to the arrows on the road and/or signs, read from left to right. E.g. left;through|through;left for s left lane with arrows for left and through, combined with a right lane for through and right. There are values for unmarked, slight right, sharp right, and the same for left.

Name

The roundabout ways, including the short link sections, do not get a name tag.

Ref

Alle delen van de rotonde krijgen de ref van de grootste weg, behalve de stukjes zijweg die op de rotonde de twee banen verbinden; die krijgen de ref van de zijweg.

Turn restrictions - to map non-allowed movements.

The road halves merge point usually gets turn restriction reation no_u_turn. This prevents the router from routing back over the roundabout. All sections with junction=roundabout are implicitly oneway; so no restriction are necessary to prevent routing the wrong way on the roundabout.

If there are two pre-sort lanes, the left one will first cross the outer circular lane, then connect to the inner circle. This inside junction gets no_right_turn or only_straight_on, because traffic is not supposed to change lanes there. On the same junction, coming from the outside ring, a no_left_turn or also only_straight_on.

It is recommended to tag implicit=yes on the restriction relations, because there usually are no actual markings or signs on the roundabout itself.

turn:lanes - to indicate which lane leads to which direction over the roundabout.

The intended directions have to be verifiable bij arrows or signs on the approach lanes. I.e. the sections with pre-sort lanes.

Turbo roundabouts require the motorist to pre-choose the lane to where they want to go, because once on the roundabout it is not possible or not allowed to change lanes. So this has to be indicates clearly on the approaches. These are the section of road with lanes=2 (or more) to allow the motorist to choose.

Because on the major highway there always are multiple pre-sort lanes, we use turn:lanes=|, not turn=*. Read the lanes from left to right exactly how it is indicated/verifiable. Record this as turn:lanes=||... where the vaues for b1, b2 and … can be semicolon-separated lists. On turbo roundabouts, the most used values are left, right, through. Other possible values are sharp_right, slight_right, sharp_left, slight_left and reverse (u-bocht). And none, or leave empty. Examples: turn:lanes=left;through|through;right and turn:lanes=left;reverse|through;right or (in case of a turn-right bypass) turn:lanes=left;through|through|right After the roundabout there often is a lanes=2 section for merging. The values none, merge_to_left and merge_to_left ar often appropriate there.

Once the lanes are separated, if there are more arrows on them, turn=* can be tagged on the separate ways.

Practical tagging

1. Select all the roundabout sections using Control-click

• no name tag
• no oneway tag
• no change:lanes tag
• no lanes:backward and lanes:forward tags
• lanes=1
• ref= (excepting the small connecting pieces of the minor roads having no pre-sort lanes)
• junction=roundabout
• roundabout=turbo

2. Select all connecting road sections approaching or leaving the roundabout.

• no turn:lanes
• no lanes:backward and lanes:forward tags
• oneway=yes
• lanes=1

3. Select, one by one, the approaching sections on the major road, having multiple lanes.

• lanes=2 (sometimes 3 if right, left and through are separated)

• turn:lanes=left;through

  through;right (most used example in Nederland)

• Check the other tags for this section. If you worked with copy-paste the tags usually are right.

4. Select, one by one, the separate connecting exits and init lanes. These already have lanes=1.

• add turn=* according to the arrows on the lane. Merge lanes get merge_to_left of merge_to_right.
• Check the other tags for this section. If you worked with copy-paste the tags usually are right.

5. Create Turn restriction relations.

• Look at the nodes where road halves join. Usually there is a continuous line, which is ground truth for a no_u_turn restriction. Create a relation (possibly by duplicating/adapting an existing relation). Tags should be type=restriction en restricion=no_u_turn. Tag implicit=yes is recommended. Members are: from section, junction node, to section, seen from the driver’s position.

• Look at the connecting sections on the roundabout between inner and outer rings. Traffic already on the roundabout is not allowed to change lanes there. Use only_straight_on restrictions there. A regular turbo roundabout has 4 of these link sections, so 4 turn restriction relations are needed. Tag implicit=yes is recommended.

• Look at the nodes on the roundabout where a lane from the appoaching road passes through to the inner lane of the roundabout. Traffic is not allowed to turn sharp to the outer lane. Create only_straight_on restriction relations there. A regular turbo roundabout has 2 of these nodes, so another 2 turn restriction relations are needed. Tag implicit=yes is recommended.

PS1. The restrictions on the roundabout could just as well be tagged as no_left_turn or no_right_turn restrictions. Other restrictions follow from the oneway or the junction=roundabout tags on the ways, so you don’t need to tag those. Only straight on has the advantage of being simple and straightforward, conform the driver’s instruction: don’t change lanes (no maneuvering) on the roundabout. The corresponding rendering in JOSM shows the idea very clear.

6. Add / tag give_way nodes

In Nederland, there is no general right-of-way on a roundabout. At the roundabout entrances there are always give_way signs and lane markings (shark’s teeth), or sharks’s teeth only which is legally the same. If not, it’s not a roundabout. A famous ‘roundabout’ in Nijmegen actually lacks any give_way or preference signs, meaning it’s a rotary, not a roundabout, let alone a turbo roundabout. We recommend to add give_way nodes to the ways (lanes) entering the roundabout, at exacty the spot where the way crosses the markings. This conveys the exact stop location to routers and renderers. Because (and if) all entering lanes are oneway and drawn in the driving direction, no direction tag is necessary.

Route Relations

1. Road relations Only enter the ways into the relation that give a direct car route over the roundabout. The road relation has both directions, so forward and backward roles are necessary. If you copy-and-pasted and cut-and-combined, you probably only need to remove a few sections.
   PS Road relations in NL should contain only a main route carrying the identifying ref. Side tracks, approaches, parallel ways with the same ref, etc, are all left out. The roads in the relation may carry different names, though, as long as the ref is the same.

2. Public Transport Route relations Bus routes have a separate relation per driving direction (and a routemaster relation combining the two). Both bus relations should be adapted, for each bus line passing through the roundabout. Just walk through the members, and see where sections need to be added or removed to make a continuous route.
   Buses, if they have a choice, tend to use the outside lane. This choice usually only appears for straight-on going routes.

Issues

1. JOSM issue - JOSM may complain about suspicious directions on the roundabout. Just check all drawing directions again (should be drawn in the driving direction), then ignore the warning.

2. Router issue - navigation instructions vary between routers; they all have trouble announcing which lane to choose, announcing the correct exit count, and announcing the overall direction change. The information is in the mapping, but it is technically complex to use it effectively.

3. Sometimes a possible turn is legally not allowed, but that can not be seen on the ground. In Nederland, this may even be a turn that is allowed or disallowed, depending on the lane you used to enter the roundabout. I chose not to map this, because ground truth is lacking. It could be mapped using a turn restriction with one or more via ways, i.e. way members with the role via. The use case is that a road has 2 lanes entering the (continental) roundabout and has a two-lane exit to the right. The left approach lane is marked for left;through and goes to the inner ring, and the right lane is marked right and goes to the outer ring. A car C using the left approach lane enters the roundabout, then (surprise!) the first exit is to the right. The exit is meant for traffic that was already on the inner ring on the roundabout. Legally, our car C is not allowed to use the exit, even though it has exactly the same position an movement as a car that was already on the roundabout, which is legally allowed to use the same exit. So we could create a turn restriction with the left approach lane as from, the section of the inner ring as via, and the exit as to.

This diary entry contains a wrap-up of discussions on the osm forum, (dutch section and general section). I’ve tried to capture all that has been said into a logical narrative and solution proposal.

Improved mapping of embankments

Objective

Establish improved mapping of embankments. This includes small embankments and large embankments; one-sided, two-sided and irregular embankments; embankments to contain and to protect against water, embankments to support roads and railways, and embankments serving as a traffic barrier, visual barrier or sound barrier. The aim is mainly to enable fuller rendering on maps, including at least the extent of the slopes. It is NOT the intention to establish full mapping of all aspects of embankments. However, it also should not exclude richer mapping of embankments in the future.

Starting point

Embankments can currently be mapped as:

embankment=yes on a way on the crest of the embankment.
This is especially useful if there is a road, track or path on top of the embankment. Some renderers also handle a single way tagged only with embankment=yes, without a main tag. The tag can modify the rendering of the way, to suggest it is supported by an embankment. Comparable to how a way can be altered by the tag bridge=yes. Other non-approved values are sometimes used, e.g. embankment=dyke for a way on a dyke/dike/levee. There is no established way to indicate further details of the embankment itself, e.g. left/right differences, landcover or surface, steepness, width. Theoretically one could add details like embankment=right and embankment:right:width=5 but this currently is not done. We don’t propose or oppose that.

man_made=embankment on a way tracing the crest edge/edges of the embankment.
Though some mappers use this tag also to trace the bottom edge (toe) of an embankment, the predominant (and so documented) use of man_made=embankment is to trace the crest edge (the upper edge of the slope or slopes). The mapping instruction that the righthand side of the way should indicate the lower side of the embankment is not compatible with the use as a toe edge line. This tag enables renderers to show where the upper edge is or where the upper edges are, and it allows mapping the crest shape (varying width; curves, cuts, corners and crossings; platforms on the crest eg for buildings, terraces).

This is established mapping and the intention is to keep this as it is. The proposal (beneath) enables improved rendering, but if a renderer does not do anything, that particular map wil not change. It’s a non-breaking extension proposal. The same is true for mappers who have used man_made=embankment for the lower edge of embankment slopes. To profit, some retagging will be necessary. If the ways are not retagged, the rendering wil not change.

That said, an embankment is more than a crest edge or mid-crest line. I will make an effort to support more systematic naming of the most visibly important parts of embankments.

What is missing and how to go about it?

Mainly for large embankments, what is missing is information about the slope(s). We know the top (crest) edge, but we don’t know the lower (toe) edge. We don’t know any specifics about the slope: steepness, type of reinforcement, extent, material/surface, berm. What you don’t know, you can’t use or render. So we want to map more information, somehow.

Most wanted: the extent of the embankment at both sides. Since the extent can differ on both sides, and the slopes at both sides are often not connected, the mapping must be able to handle one slope. If the two sides of a levee do connect, they can simply be treated as one curved slope. Because the slopes of elongated embankments are often interrupted by coupures, buildings, roads and other landuse, the mapping must also be able to handle sections which together form the embankment. And let’s not forget one-sided embankments to support sections of mountain roads.

Mapping the toe edge with man_made=embankment is sometimes done. It results in the slopes looking (on the map, no matter which renderer) like pits in the ground. Or, when drawn in the other direction, like two embankments on top of each other. With steep embankments where the toe and the edge are close together, the two line renderings tend to merge and look like a railway or a very thick wall.

Conclusion is that we need a different method (and a different tag) to map the extent of the slope of the embankment. One that enables data users to handle the upper edge different than the lower edge.

Options

A. Add a polygon for the slope area
The first thing that comes to mind is: it’s an area, so why not use a polygon representing the slope. The problem is: how do you know, as a data user, which side is up and which side is down, and if you knew, could you render the lower edge different from the upper edge? Maybe you could associate a portion of the polygon with the man_made=embankment crest line, but is that going to happen for real? And isn’t that a bit overdone, mapping a crest-edge line AND a polygon which also has partly the same line?
Doesn’t sound good… but wait, hold that thought!

B. Add a stand-alone toe line
Another option is to simply draw a way tracing the embankment toe line, i.e., if it is visible/verifiable by survey, and tag it as the toe of an embankment. Anything between crest and toe is regarded as the slope of the embankment. The toe line can get a rendering suggesting a kink in the landscape, where the embankment slope hits a level piece of land.
This enables rendering the extent, but it does not enable area-rendering, at least not in the way that areas are normally rendered. Just a visual impression.

C. Create an area incorporating the crest edge line AND optionally a toe line
As it happens, there is an approved and operational method to create an area from multiple different ways. And this solves the problem of tagging crest and toe lines in their own right AND the slope area in between!
Simply connect the two tagged ways (or sections thereof) using untagged ways to delimit the area. Then put the ways forming the outline of the area in a multipolygon as outers, add a main tag, and there is your area. The tagged ways will be rendered as usual, the untagged lines are invisible area delimiters, and the MP is an area and can have its own tags and rendering, even a name.

So what do we need to accommodate all options at once?

• A crest edge line, we have that.
• A toe edge line, that’s new.
• A multipolygon to form the area, that’s already possible, but the main tag is new.

You could e.g. map an embankment slope covered by scrub as an MP tagged natural=scrub, defined by (a section of) the way tagged man_made=embankment as outer, and an untagged way forming the rest of the outline of the embankment slope. This actually works and is not bad visually, if e.g. at the toe line the scrub changes in grass or wood. If a toe line is present and separately rendered, you can simply incorporate that as outer in the MP representing the slope area. To get additional rendering of the slope area itself, the area would need a new main tag to let data users know what it represents.

So, one new tag for a way, and one new tag for an area, and no forced changes to the installed base. Not bad! I think it’s not a big enough subject to warrant a new main key. Let’s see if we can do it with a couple of new values for an existing main key.

One thing: the crest edge is tagged man_made=embankment, but the embankment is much more than a crest. That’s why a synonym is suggested for the tags of embankment parts, and the other values reflect the parts of an embankment that stand out in the landscape.

Tags, proposed

• man_made=embankment:crest as a synonym of man_made=embankment
• man_made=embankment:toe as tag for a way tracing the toe line (bottom edge of an embankment slope)
• man_made=embankment:slope as tag for an area covering an embankment slope from upper edge (crest edge line) to bottom edge (toe line).

More generally worded alternative could be:
- man_made=embankment:upper
- man_made=embankment:lower
- man_made=embankment:slope
It’s just that man_made=embankment:upper could be understood as “the upper embankment”, embankment:lower as “the lower embankment”. As large dykes often looking like embankments on top of each other, I think this would create confusion and considerable mistagging.

What about man_made=embankment, embankment=crest|toe|slope ? This kind of sequence is generally used for typology. It would imply that crest, toe and slope are types of embankments. I would rather support e.g. embankment=dyke|railway_bank|road_bank|sound_barrier|river_bank|… to indicate the type of embankment by function. This would be tagged on the most defining element: the crest. This is not part of this proposal, but this proposal should not stand in the way of a regular breakdown scheme for embankments types.

How to map

First, let’s establish a standard mapping scheme, in 3 levels/stages of detail.

Level 1: Always consider simple mapping first (existing mapping: just embankment=* on a way on the crest; or man_made=embankment or embankment:crest on the crest edge)

Level 2: Then consider if the extent of the embankment should be mapped: if so add a toe line or toe lines

Level 3: Then consider if area attributes are required for the slope(s); if so add a multipolygon area tagged man_made=embankment:slope containing the upper way, lower way, and connecting ways as outers.

• Level 1 already accommodates many embankments.

• Level 2 mapping is expected be widely applied, if not for the whole of every embankment then for sure for more complicated sections.

• Level 3 mapping accommodates large dykes, think 50m or more toe2toe, found in substantial numbers in Nederland. E.g. ‘polder’ dykes, where each side can have a different name, form and surface, can be accommodated (name=, surface= on the MP’s). Or sea dykes with one side built of special surf-resistant concrete blocks (surface=? on the slope area).

Rendering

I think rendering of the toe line should be subtle, no shark’s teeth or comb lines. It should suggest a kink in the landscape. I have tried to create a shade effect, using inkscape, then upload it to imgur as svg. Crude, I know, but it’s about the idea.

Suggested rendering for man_made=embankment:toe (dark grey side=high side)

or

Only thinner and more transparent. I wish I was better at this!

Use cases

a. One-sided embankment against a hill or mountain slope, carrying a road or railway.

• Standard mapping scheme
• If the upper part of the slope is more like a retaining wall, consider using barrier=retaining_wall instead of embankment:crest. This has no consequence for Level 2 and Level 3.

b. Two-sided embankment to carry a road or railway above ground level

• Standard mapping scheme for each side separately.
• For long embankments use suitable consecutive sections. Coupures/floodgates and major turns are natural places to start a new section.

c. Dyke/levee: One- or two-sided embankment for flood protection along the coast, along a river, around a “polder” or between “polders”.

• Standard mapping scheme of each side separately.
  If the sides of a dyke differ, so can the mapping. There is no obligation to map both sides with equal detail.

d. Two-sided earth wall as a noise barrier along roads or railroads

• If there are no other intersections,the standard mapping scheme may be done for the two sides in one go.
• • Level 1. Trace the crest edge line as a closed way tagged man_made=embankment:crest (or its synonym man_made=embankment);
• • Level 2. trace the lower edge line as a closed way tagged man_made=embankment:toe;
• • Level 3. Create the multipolygon with the toe-line as outer and the crest as inner, and tag it man_made=embankment:slope.
• • • Note that this is the only case where an inner is used. If you don’t want the exception, just map the two sides separately, as two multipolygons with just outers.

e. Large embankment slope with a “berm” or “banquet”

• Tag the higher slope and the lower slope separately, using the Standard Mapping scheme.
• If there is a road on the banquet, consider if that in itself is enough to indicate the extent of the higher slope.

f. Complex crossings involving embankments

• Divide the complex into separately mappable edges and slopes.
• Use the standard mapping scheme on each section

g. Reinforced_slope as a part of an embankment (water-side)

• No preferred mapping (yet?)! The reinforced slope can be the complete slope, or just the lower part, or in the middle; it can be usually exposed or tidally exposed; it could coincide with a banquet or not; it could stretch along the whole dyke or just some vulnerable parts. It’s up to the mapper to decide whether or not to incorporate or overlay embankment mapping with reinforced_slope mapping.

h. Coupure / floodgate

• Basic mapping. Let the ways and, if used, the area stop at the coupure/gate. The mapping of the coupure gate is separate from the embankment(s) involved.

i. Irregular shaped crest/slope/toe

• Basic mapping.
• If it gets complicated, divide the complex into separately mappable edges and slopes. Think of how elaborate water areas are broken down into manageable sections.

j. Other features (buildings, landuse/natural/man_made/leisure) on crest/slope/toe

• Basic Mapping. If it gets complicated, divide the complex into separately mappable edges and slopes. Think of the way elaborate water areas are broken down into manageable sections.
• Let the edge ways stop if they are interrupted by another feature. Note that landcover usually does not interrupt a crest or a toe.
• When mapping the slope as an area (multipolygon), it’s possible to cut out other areas on the slope as inners of the multipolygon. Whether this is useful or not depends on the tagging of the slope area. If we agree that an embankment:slope area can have a surface tag or landcover tag, the use of inners is appropriate. An embankment usually has its own operator, which might be different from what’s on the slope. Etc.
• Note that this additional tagging and handling is not proposed here. Just the mechanism of indicating an embankment slope with an optional toe line tagged man_made=embankment:toe and optional multipolygon area tagged man_made=embankment:slope.

I tried using a GoPro Hero on foot to assist in mapping foot routes, with mixed results. For foot route recording, you need to keep the “blind circle” as small as possible, because you want to record the surface, kerbs and the usually small poles carrying the signs. If you mount the camera say on a stick in a backpack, the forward view always is largely your own head. Second requirement: you want to capture the usually small signs, often with even smaller lettering, and the text under regular signs, which give hikers details about access and rules, e.g. dog access and breeding season closure.

1. Fixing the camera high enough for acceptable images is not easy, and carrying the gear for hours at a time is no pleasure. I ended up using a bicycle helmet with a vented helmet strap, and on top of that a 20 cm gooseneck, then the camera on top of that. I had to use tiewraps to fix the strap, to hold it in position and because it kept getting loose. I had to ask others to get the camera position (tilt) good. I had to wear a cap inside the helmet, and then strap the helmet uncomfortably tight to keep the helmet from falling to a side all the time. With some practice, the end result was ok for say 2 hours recording. I can’t see myself walking a long hiking trail with bushes and low trees, let alone scrambles, windy crests and muddy hills. Without any company, because a. noone wants to bee seen with you wearing this contraption, and b. no-one wants to be on every picture, and c. company blocks the view!

2. You really need some guidance to learn how to operate the camera. I used the Quik app to do the settings, check if it works, and to start the recording on the road. After that, you don’t need the app. To stop recording, I could reach the camera and push the button. Practice in front of the mirror!

3. After several trials, I settled on 5 seconds interval images, walking fast on straight sections and slow where more turns and details were needed. Of course, the sections where I had to take the gear off because I had to climb, duck or crawl, yield some ‘interesting’ pictures. I never edited the series, though.

4. One battery gives you about an hour of recording (1200 images), for longer sessions you need the extra batteries and probably an extra memory card.

5. The 360 images are fine for general geometry and objects, also surface, lit or not, and traffic signs. The image series are really nice to watch, it’s great to look around on mapillary. But the resolution is not great, in particular you can’t read or effectively zoom into texts under traffic signs, let alone walking symbols with numbers (for the walking node networks) or texts (names of long distance trails).

Conclusion:

It’s fine for say mapping a nature area where you can walk the entire area in a limited amount of time. This will give you good results to map the details of the area.

A roundtrip trail for one day, yes, possible, but you’ll need extra batteries and memory cards.

Longer hiking trails and walking node networks, no, not suitable. Especially because you want details of symbols, small shields and stickers, and the resolution just is not good enough to capture that. For trails, I had better results simply with the Mapillary app (set to Manual), then taking pictures of turns, markings and details I wanted to record.