Proposal talk:Boundary=forest( compartment) relations (v3)
leisure=nature_reserve
I understand leisure=nature_reserve as a protected area which is not "Use if the area allows human visitation to enjoy nature." Whether humans are allowed to access the forest should be indicated by access tags on the ways in the forest. --Lkw (talk) 21:39, 24 January 2022 (UTC)
Compartments without boundary=forest
In the section "Forest compartments" is says:
It may happen that the compartment materialization signs only show the compartment ref, and don't allow to know to which forest the compartment belongs. It is thus accepted to map the boundary=forest_compartment without mapping the boundary=forest to which it belongs, but this situation should be considered temporary, and should be solved whenever possible by mapping the enclosing boundary=forest entity.
The concept of a named well marked forest doesn't seem to exist in Hesse (Germany), but compartments are well marked. There are named forest but the boundaries are rather fuzzy and not marked. I also could not find a map that contains forest boundaries. Examples: It is locally known that the forest between Steinbach and Annerod (https://www.openstreetmap.org/#map=14/50.5690/8.7473) is called Fernewald and the forest around Kloster Schiffenberg is called Schiffenberger Wald but there is no marked boundary between them nor a map I could find that shows this boundary. Similarly there (https://www.openstreetmap.org/#map=15/50.6279/8.7130) are Badenburger Wäldchen and Hangelstein (The nature reserve Hangelstein is only a part of the larger Hangelstein area.) but I was unable to determine a boundary between these two forests.
There are maps of well defined (but unmarked) boundaries of "Flur"s ("Flur"=collection of plots, a term from the cadaster). I do not think that "Flur"s should be used as boundary=forest, because they are from the cadaster and also cover non-forest areas. Therefore only having the compartments is not always a temporary situation.
Therefore I think that above paragraph should be rephrased. Eg.:
It may happen that the compartment materialization signs only show the compartment ref, and don't allow to know to which forest the compartment belongs. It is also possible that delineated named forests do not exist in a region and therefore boundary=forest is not applicable. It is thus accepted to map the boundary=forest_compartment without mapping the boundary=forest to which it belongs. The enclosing boundary=forest entity should be mapped if this information is available.
This change might reduce no-votes from regions where boundary=forest does not work well. --Lkw (talk) 15:59, 25 January 2022 (UTC)
compartment_ref really necessary?
I'm not convinced that introducing a new kind of ref is necessary. ref=* is used on many different things and it seems odd no to use it for forest compartments. The distinction between the marked ref and the longer official ref could also be made using ref=* and official_ref=*, which are already established keys. This makes it easier for mappers and data users. Most of the existing forest_compartment are in Poland and not marked at all and should not be mapped according to this proposal. Therefore a distinction from the non-standardized refs in existing forest_compartment does not seem to be important enough for a new key. --Lkw (talk) 16:19, 25 January 2022 (UTC)
- @Lkw: I totally agree that I should not propose a new ref key, but a quick search shows that 10,172 existing boundary=forestry_compartment or boundary=forest_compartment entities already have a ref key, which do not necessarily represent what this proposal means by compartment_ref. I proposed this new tag because creating it on existing entities allows mappers to assume that the entity's compartment_ref tag indeed represents the compartment ref as the proposal defines it.
- If the proposal keeps ref for this use and is approved, and a mapper encounters a boundary=forest_compartment entity, how can (s)he tell if ref has been checked and represents the compartment ref as approved, or if the entity's ref has an arbitrary value which doesn't necessarily reflect the compartment ref as approved?
- Among the existing values are some like "8-й квартал", "Виш_кв_50" or "Uf_Nizhn_uf_207" which most likely don't match the proposed compartment_ref key, so I think I can't simply let this transition issue apart. What I propose is clearly somewhat ugly, but eases the transition between the present arbitrary compartment ref and the proposed uniform definition of it. I'm willing to propose a better solution, as long as it avoids to manage this transition, but was unable to find one, so I would welcome any relevant idea! --Penegal (talk) 17:50, 25 January 2022 (UTC)
- Naive idea: if the proposal is approved, I could launch a MapRoulette challenge per country where boundary=forest_compartment+ref are used, and invite the local users to check the existing entities; once the challenges are completed, the migration would be assumed completed. What do you think? --Penegal (talk) 18:58, 25 January 2022 (UTC)
- Yes, but in remote areas it will take a long time. Checking the existing boundary=forest_compartment is necessary regardless of the ref issue. Around this village https://www.openstreetmap.org/#map=15/53.6586/17.2223 there are fields and meadows tagged as boundary=forest_compartment even including ref. Probably there are other issues like this. --Lkw (talk) 20:21, 25 January 2022 (UTC)
- @Lkw: some situations may arise in OSM because they exist in reality. One of the forests I manage have a compartment which is partly rented to a local peasant as a meadow. It is nevertheless treated as a non-wooded section of the compartement: it is part of the compartment, is taxed by the forestry administration as such… but is considered out of sylviculture, and there are no forestry operations in it. This situation may happen when the compartment/delimited forest includes features which are not wooded: disused quarries, arboretums, ponds… This situation is one of the reasons that motivated the proposal: it may be a mapping error, but also be perfectly legitimate; only local knowledge may tell. --Penegal (talk) 18:08, 30 January 2022 (UTC)
- Yes, but in remote areas it will take a long time. Checking the existing boundary=forest_compartment is necessary regardless of the ref issue. Around this village https://www.openstreetmap.org/#map=15/53.6586/17.2223 there are fields and meadows tagged as boundary=forest_compartment even including ref. Probably there are other issues like this. --Lkw (talk) 20:21, 25 January 2022 (UTC)
- Naive idea: if the proposal is approved, I could launch a MapRoulette challenge per country where boundary=forest_compartment+ref are used, and invite the local users to check the existing entities; once the challenges are completed, the migration would be assumed completed. What do you think? --Penegal (talk) 18:58, 25 January 2022 (UTC)
What do you think about the unmarked compartments in Poland? Should they be removed after approval because they are not covered by the proposal? Should they be tagged as not visible on the ground or move ref to official_ref? Stay as they are? Probably this should be decided by the local community. --Lkw (talk) 20:20, 25 January 2022 (UTC)
- @Lkw: Theoretically, all current instances of boundary=forest_compartment or boundary=forestry_compartment and their tags should be reviewed accordingly to the approved definition; if they don't match them, they should be refactored or deleted, according to whether they effectively represent a compartment under the approved definition, or they represent another kind of non-materialized compartment. The choice and verification process would be up to the local communities; I didn't talk about it in the proposal because it seemed out of scope of a proposal, but should I still talk about this transition? Now that you evoked it, it seems rather essential to mention this verification/migration… --Penegal (talk) 06:07, 26 January 2022 (UTC)
One problem I have with compartment_ref=* is that there will be many people who add ref=* to new compartments because they forget that there is compartment_ref. Therefore the difference of these tags will blur.--Lkw (talk) 12:56, 26 January 2022 (UTC)
As alot of the existing compartments are in Poland and Russia, the Polish and Russian communities should be invited. Their forums are alive. Im confused: The proposal page states that compartments in Poland exist only in GIS (and should not be mapped as boundary=forest_compartment according to the proposal) but https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dforest_compartment states that a short ref=* is found on the ground and a longer ref is tagged as adr_les=*. Maybe someone from Poland can explain what statement is closer to the truth. --Lkw (talk) 12:56, 26 January 2022 (UTC)
- I don't say that it is so, but that it may be so. I recall of a comment on one of the past proposals, which was written by @Mateusz Konieczny: his warning seemed to imply that some boundary=forest_compartment or boundary=forestry_compartment entities are actually cadastral parcels. I may have misinterpreted his comment, though. --Penegal (talk) 15:53, 26 January 2022 (UTC)
- Besides, when I look at Overpass Turbo, the existing entities look more like cadastral parcels than compartments. --Penegal (talk) 15:58, 26 January 2022 (UTC)
- (1) ref may be used for orientation (usually only by specialized groups like firefighters and foresters) and in rare cases signed. (2) At the same time boundary of parcels is rarely signed and are plots of land owned by Lasy Państwowe (National Forests). In particular, may include residential areas, roads and non-forest areas - and exclude private forests. Attempting to import them as forests resulted in barcode forests where thin strips of land (5-20m) owned by state were interrupted by equally thin privately hold forest. In forest itself it would not be noticeable (at most some boundary stones) with no chance to guess which forest is state owned and which private Mateusz Konieczny (talk) 15:59, 26 January 2022 (UTC)
- @Mateusz Konieczny: do you mean that the current boundary=forest_compartment or boundary=forestry_compartment entities in Poland are anyway in need of a cleaning? If so, could this proposal be an opportunity to clean this up, or would it have adverse effect in its current state? Please note that the proposal no longer cares about distinguishing private-owned and public-owned forests. --Penegal (talk) 17:13, 26 January 2022 (UTC)
Combining boundary_forest and protected_area
boundary=national_park and leisure=nature_reserve were (at least partly) replaced by the more general boundary=protected_area with protect_class=2 respectively 4. Even though the older tags are still in use, my impression is that there is a tendency to unification under boundary=protected_area. (protect_class=2 increases and boundary=national_park decreases on taginfo) Combining boundary=forest with protected areas is against this unification trend. It is also inconsistent because protect_class=6 areas are tagged with boundary=forest, if they are delimited forests and with boundary=protected_area if they are another ecosystem. boundary=forest;protected_area is technically allowed but might surprise data users.
Maybe it is better to use separate areas that share the same nodes or (for more complex geometry) separate relations that share the same members. On the other hand if the forest and protected_area have not only the same area but are identical because they were defined by the same law they are the same thing and should represented by one thing. --Lkw (talk) 19:21, 29 January 2022 (UTC)
- @Lkw: What I had in mind about this issue is some forests I know, which are also protected area as a whole (what we call a Réserve Biologique Intégrale or Réserve Biologique Dirigée). Following your logic, it seems that they should be mapped as two different entities encompassing the same area, but there is a problem: this kind of protected area only exist because the area is a delimited forest. If the area wasn't a forest, it couldn't be protected under this law. To accurately map such areas, man should be able to state that the same entity is a delimited forest and a protected area; this is the meaning of what I propose. I know that it is an exception with the current tagging practices for protected areas, but could not find a better way to accurately map such areas. If someone have a better idea, I would gladly hear it.
- I agree that boundary=forest;protected_area could be problematic and should be avoided, though; that's why I didn't keep this possibility. --Penegal (talk) 12:36, 30 January 2022 (UTC)
- You have convinced me that these areas are one thing (One feature, one OSM element https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element). The only alternative I can see is using boundary=protected_area without boundary=forest but because it is also a forest this is also not perfect. Adding Réserve Biologique Intégrale or Réserve Biologique Dirigée to the table might clarify what you had in mind. --Lkw (talk) 14:45, 30 January 2022 (UTC)
Images
I think that the proposal is lacking some images. I have uploades some images that might be useful. https://wiki.openstreetmap.org/wiki/File:Abteilung_Sch%C3%BCtzenacker_1.jpg https://wiki.openstreetmap.org/wiki/File:Abteilung_Sch%C3%BCtzenacker_2.jpg https://wiki.openstreetmap.org/wiki/File:Example_forest_compartment.png --Lkw (talk) 14:01, 6 February 2022 (UTC)
- @Lkw: Vielen Dank für die Bilder! But I must apologize for not using the ones you kindly uploaded: mines have the advantage of showing the forest names, signs displaying it, paint markings showing the forest/compartment borders… I can't ask you to provide these, and I think it's better to provide crystal-clear examples; otherwise a voter may vote no, based on the fact, for instance, that "you don't provide a clear example for Germany; how do I tell the compartment/forest limits if they are not linear between two signs? This sounds unverifiable…". This proposal failed twice, partly because I leaved such blurs and left some persons think of unverifiability, so I'm afraid leaving examples which are not clear enough would simply give no votes. Sorry for the efforts you made. --Penegal (talk) 17:22, 8 February 2022 (UTC)
Complex valley situations
We should pay attention to valleys in mountain areas. Sometimes, a delimited forest can rely on both banks of the valley. However, a river will cut in half any landuse=* geometry in two parts at least (one on each bank).
See 1021236376 1021236376 and 5208157 5208157, divided by Arly river between them.
As I understand this proposal, another area(s) will be created over the two banks to represent the delimited forest(s). This cause a 99% duplicated geometry, at least on the edges shared between the landuse=* and the boundary. Since boundary and landuse geometries will only intersect most of the time, it's not possible to reuse landuse areas on banks to make a multipolygon for boundary.
Landuse adjustments are time consuming in mountain areas, creating another geometries for boundaries will be too Fanfouer (talk) 16:02, 13 February 2022 (UTC)
Awkward geometry in example
Geometry used as illustration in the Tagging chapter is awkward: yellow area should be multipolygon relation with pond area as inner member, shouldn't you?
You may use a river splitting the forest in two parts that can't be part of a single multipolygon to be more accurate. Fanfouer (talk) 16:06, 13 February 2022 (UTC)
- @Fanfouer:: note that the right side and the left side have different leaf_type values; in this case, describing the pond as an inner member of a multipolygon is not enough. Multipolygons are designed for an uniform area, but tree stands vary across forests and compartments.
- Besides, it is common that the inner area is nevertheless considered part and parcel of the forest/compartment, in such case, the pond is considered part and parcel of the forest compartment, as is this scree near Gérardmer; in that case, the non-wooded area is still considered part of the forest and is subject to forest-related laws (in French public forests, it would be subject to the "régime forestier" as a "hors sylviculture" area). --Penegal (talk) 16:39, 13 February 2022 (UTC)
Reply to Dieterdreist's vote comment
@Dieterdreist: the first and second proposal were designed to allow this possibility, but it raised many objections due to the unverifiability of name/limits of such forests; the archetype was the Black Forest: where does it begin? What are the limits? und so weiter. I agree that these forests should also be mapped in OSM, but I had to drop their support in order to reach a consensus for the proposal. I hope someone will propose a way to map such situations in a consensual way; personally, I failed, but I would happily support such a proposal. --Penegal (talk) 11:31, 14 February 2022 (UTC)
- thank you for replying. The Black Forest may indeed be an edge case, because it is so far from actually being a forest (it is a geographic region with lots of forest), but if you start from the lower ends (small patches of wood) and continue to climb up, maybe you can come to a conclusion. I agree that generally such large regions are not suitable to be represented in a 1:1 scale, as any precise boundary point could be contested. Maybe it is interesting in this context, WP has an article about the structure a public german agency has defined: https://de.wikipedia.org/wiki/Naturr%C3%A4umliche_Gliederung_des_Schwarzwaldes, looking at natural spaces ("Naturraum") which comprise flora and fauna, geography and geology. Anyway, in this case it is probably not helpful to describe the whole of Schwarzwald as kind of forest, I agree with this, because it would mean declaring all the settlements and towns as well as situations like this as "forest". --Dieterdreist (talk) 11:50, 14 February 2022 (UTC)
- @Dieterdreist: this look likes a bit like place=region. There again, I agree that such areas should be mapped, as it matches the reality of the area, how its inhabitants see and know it and so on, but I don't see how to make the community accept that. Sometimes, I wonder about the verificability requirements: when the inhabitants of an area say that some area is a forest which is named a way, IMO we should simply trust them, and not wait for a given official authority to confirm the reality; besides, because the government is too poor for that or simply doesn't care, there are many such entities which OSM currently can't include.
- For instance, the region named Saintois in France is known of many of its inhabitants, which know this region for living there; for them and bordering villages, this region exists, but I can't map it in OSM because no precise boundary was ever given by an authority, and the inhabitants were never polled to give it precise boundaries, but the region exists nevertheless (just ask its inhabitants). Current OSM rules prevent to map reality in such cases… --Penegal (talk) 15:17, 14 February 2022 (UTC)
- You could use a node (which is not satisfactory). Actually we’d need a different data type / concept for these, fuzzy borders could be represented, but not with what we have so far.—Dieterdreist (talk) 23:31, 14 February 2022 (UTC)