I’ve been working on adding details to my local rural areas, focusing on farmland, farms, and local businesses. While doing this, I noticed two different approaches to mapping farmland:
Marking hedgerows as scrub, where each hedgerow is mapped individually as scrub, with the farmland as the areas between them (screenshots below).
Mapping entire fields as farmland, marking each field as a single farmland polygon.
I’ve been using the second method, as it seems more common and preserves the renderer’s automatic LOD system, where field boundaries only appear when zoomed in. The inconsistency between these methods is frustrating, and I’m not a fan of how the first method disrupts the LOD behavior.
Which of these methods is generally preferred in the OSM community? Also, is there an easy way to convert existing data from the first method to the second?
Thanks
The first method maps hedgerow (field barriers) as natural=scrub. This is simply wrong.
The second method you show is the one commonly used in the UK.
Mapping individual fields up to the boundary is the most common (preferred) method. Where there is a physical boundary between fields, then the barrier=* is used (eg barrier=hedge)
The field hedge barriers we have in north western Europe are usually significantly wide. They have their own name in British English. They’re called hedgerows, but OSM has no agreed way of mapping hedgerows. How we should map to show hedgerow is for another post.
The first method you showed, involves mapping the these wide hedgerows as scrub. It is simply wrong. Hedgerow is not scrub, and the scrub tag does not include barrier information.
The wiki implies where the hedge habitat(?) starts to sprawl out, usually at corners, then map this area by overlapping with the scrub key.
So I’d suggest mapping each field to the boundary. Then using the barrier=hedge along the boundary. Be careful to break up the hedge lines to avoid creating an area.
We do not map for a specific “renderer’s automatic LOD system”, there is huge amount of renderer’s and other users of data. Different maps will choose to display the boundary and barriers at different zoom levels. eg look at this comparison side-by-side map. It shows “Useful Map” (link), next to default OSM map carto Link to side-by-side
Looking at your examples brings up what I think is one of the major issues for mapping UK land cover. The landuse=farmland tag, is meant for land producing crops. And landuse=meadow + meadow=pasture tags are meant for land used for grazing. In practice many mappers in the UK just use landuse=farmland for rural fields. But, that is subject for another post.
Can you explain why natural=scrub could not apply to a scrub that grows between 2 fields? I do not question that barrier=hedge can also apply, especially if it was planted on purpose.
I think you’ve have misunderstood what I meant in the first line of my post?
natural=scrub can apply for scrub between two fields. What should not do is map hedgerow as natural=scrub. Hedgerow is a fairly specific thing. It can not be scrub, or even a type of scrub.
It used to be accepted that hedges could be mapped as either linear or area features, and that’s how people mapped them. A renderer could choose to show it as an area if it was an area or a line if it was a line. A challenge to doing this is that sometimes mappers add barrier=hedge tags to other area features, such as landuse=farmland, and in that situation “what the mapper meant” is probably a linear hedge around an area. Faced with that difficulty at least one renderer (OSM Carto) chose to ignore area hedges altogether. I explained in a diary entry how it could work around that issue, and that’s what I do myself; it works with both raster and vector implementations of the same map.
However, in order to keep things straightforward, when adding a hedge to OSM (whether area or linear) I’d always add use a separate object for it, even if it shares nodes with an adjacent feature such as landuse=farmland.
Also, FWIW, I tend to draw most hedges as just linear, but that’s arguably just laziness on my part.
