How to tag markers of forest compartments?

I want to map markers of forest compartments. In my region they show a number and name.
I’d map them according to Key:marker - OpenStreetMap Wiki as
marker=plate
ref=NUMBER
name=NAME
operator=OPERATOR (if indicated)

But how can I tag that it is a marker of a forest compartment? I am aware of Tag:boundary=forest_compartment - OpenStreetMap Wiki but this is only for the area and not the marker itself.
The utility key (https://wiki.openstreetmap.org/wiki/Key:utility) is close but does not seem to fit perfectly.

If I understand your post correctly then this is probably better mapped as boundary=marker with associated tags according to this page.

1 Like

I am not sure. boundary=marker seems to be used mostly for administrative boundaries. On the other hand boundary=forest_compartment uses the boundary key.

Any other opinions? I think that marker=plate fits as marker is also used for milestones and property lines. But utility=forestry feels a little off.

A forest compartment is an administrative boundary, isn’t it?

No, or at least not always? It’s certainly not normally the case in England - managed forests and their subdivisions are a separate thing altogether to admin boundaries and if they do correspond, it’s likely historical coincidence.

(partial quoting to work around Discourse bug mentioned at https://community.openstreetmap.org/t/automatically-removed-quote-of-whole-previous-post-how-do-i-turn-that-off/1444/3).

If the compartments are defined by the state they are some kind of administrative boundary but depending on the region they could also be defined by a private owner. Certainly they are different from a boundary_administrative with admin_level.
But I am still looking for a good way to say “this marker is for a forest compartment”.

That seems to be “in use” boundary | Keys | OpenStreetMap Taginfo - I consider that quite telling: the marker marks a boundary, the marked boundary is a forest_compartment. Very much in line with how the combination “marker=* + utility=*” works.

Do understand you correctly: marker=plate and boundary=forest_compartment for the marker?

indeed there is no general reason why forest management boundaries should coincide with administrative divisions, while it can happen, it is not necessarily the case globally. In some countries (maybe all?) parcels are aligned with administrative boundaries, so in these cases there is a reason why both boundaries would coincide (unless the forest boundaries can consist of several, arbitrary parcels, so that you might have a piece of forest stretching beyond admin boundaries contained in them)

@lkw Yes, that is what I’d do, in your place. The utility mappers (gas, power, etc.) do just the same, if I fully understand.

PS: Sorry for the noise, I messed up twice today: 1) With administrative, I did not mean the strict definition used in OSM, but the colloquial one. 2) There may be other nodes with “boundary=forest_compartment” besides markers, in fact, there are only two of those, overpass turbo - if you take out the filter for “marker”, you can inspect the 1497 others.

Update: include/quote solution in the solution.

Dear all,

I’ve been noticed of this discussion by an edit notification on marker=* wikipage by @lkw (very useful to do so thank you).

To me, it’s a kind of a problem to encourage boundary=forest_compartment on marker=* nodes: boundary=* key only got affinity with ways.
It’s been a strong point i intend to make with markers refinement: they don’t impersonate the feature they mark. A marker is not a pipeline, not a boundary, not a highway so we shouldn’t mix those keys with them.

In tagging mailing list Marc_marc proposes to use subject=* on markers to describe what they refer to.
https://lists.openstreetmap.org/pipermail/tagging/2022-August/065146.html
So I would propose to use subject=forest_compartment instead.

Please revert the modification on marker=* page please as to not encourage to use a feature on nodes which affinity hasn’t been discussed further.

Your criticism is valid. I have reverted the wiki changes. There needs to be a solution that works for all boundary=*

1 Like

Thank you @lkw

No offense, your question is valid and deserves to find the best answer.
Does subject=* sound good or need further investigation?

subject= has been criticized in [Tagging] fix the suggestion for replacement for pipeline=marker into marker=* + subject=pipeline ?. So won’t go with it immediately. But “what it is about” fit nicely.

And there is another problem if one wants to be strict: The number on the compartment markers is not the ref of the marker but the ref of the compartment. So using the usual ref is like using name=Germany on a boundary marker of an international boundary.
For highway milestones Tag:highway=milestone - OpenStreetMap Wiki this distinction is made.

Maybe a formal proposal is needed as it should cover all boundaries and not only the niche topic forest compartments.

Something like subject:ref=305, subject:name=Nonnenberg in case of the example picture. Or anything else instead if subject.

In an ideal scheme, data should be self-explanatory at a level, that software can make use of information, even what it has not been explicitly told, how to handle. Openstreetmap is full of data, that humans can make sense of, by intuition, but software will fail.

boundary=marker or pipeline=marker are particularly bad examples. If read as an assignment, the left-hand-side gets the value of the right-hand-side, it says, this boundary or pipeline is a marker.

What I see missing in the boundary=forest_compartment on a marker is a key, that allows chaining. subject would be a good name, perhaps there is an even better one for “what this marker marks”. Would “marking” do it?

“marker=plate; marking=boundary; boundary=forest_compartment”
“marker=plate; marking=utility; utility=power”
“marker=pole; marking=pipeline; pipeline=*”

I’ve seen that in surface tagging. You could go on and add “forest_compartment:name|ref|*” in this manner. In order for letting software parse that into a tree structure, homonyms are a nuisance, that can be worked around by namespacing. Keys with lots of colons “:” will give humans a hard time though.

I have created a proposal page: Proposed features/Boundary markers proposal - OpenStreetMap Wiki
Mostly by copying the Utility markers proposal. I am very open to change how to name the tags and to structure the tags.
Further discussion can be held there.

I wrote the original wiki material on forest compartment markers & found the illustrations (one of which I took), but reading my text there wasn’t a common tagging scheme at the time (e.g., very specific use of the adr_les tag in Poland). Therefore I’d be interested in further suggestions.

With regard to use of the ref tag I think it is best to keep things simple. The one I photographed near Topiło has 600A on one face and 600B on the adjacent face referring to 2 compartments. I’d suggest that it’s best to keep the ref tag & not worry too much that in practice it is an indirect reference to the compartment (technically amenity=post_box ref, at least in the UK, refers to the postal collection service & not the physical post box, so such situations exist already).