Thank you for Adding this hiking route to the map and for noticing that there is a naming convention.
I hope that you have enjoyed it.

Obrigado pela sua resposta.
Concordo que a tag não esteja obsoleta. Existem pelo mundo áreas protegidas que estão mapeadas como polígonos etiquetados simplesmente com leisure=nature_reserve e outras etiquetas mas sem osm.wiki/Tag:boundary=.
Porém discordo quando afirma que "[...] Assim, as áreas protegidas renderizadas no mapnik serão apenas aquelas que têm categoria da IUCN" seja trabalhar para a renderização.
O ponto aqui é o critério que é utilizado para caracterizar através das etiquetas aquilo que é uma área protegida. No meu entender o esquema boundary= dispensa completamente o recurso a leisure=nature_reserve.
Entendo serem duas maneiras possíveis para resolver o mesmo problema.
Então não considera que, neste caso em concreto, a introdução da leisure=nature_reserve não contribuiu para acrescentar informações ou propriedades que já não estivessem anteriormente definidas para esta área?

Cumprimentos

Olá Reino Batista,
Obrigado pelos seus esforços de mapeamento.
Gostaria de saber qual foi concretamente o seu raciocínio para esta edição considerando que por norma as Áreas protegidas da Rede Natura 2000 não surgem renderizadas no mapnik.
Parece-me que a renderização foi forçada com o recurso à etiqueta leisure=nature_reserve. Esta etiqueta tornou-se obsoleta e redudante assim que o esquema de etiquetagem com boundary=protected_area + protect_class= + protection_title= foi aceite pela comunidade como uma forma capaz de mapear qualquer tipo de proteção que uma determinada área possa ter.
De qualquer forma, as relações com protect_class=97 são visíveis em https://www.osmap.pt/ por exemplo.
Penso que seria melhor se deixássemos a etiqueta leisure=nature_reserve para Áreas exclusivamente destinadas a fins de lazer. Assim, as áreas protegidas renderizadas no mapnik serão apenas aquelas que têm categoria da IUCN.

Hi mueschel. Thanks a lot for pointing this out.
The line was a stub and was mistrakenly added by pasting twice.
I'v fixed the issue though changeset/162444922. changeset/162444922

Hello!
Thanks a lot for your comment on this changeset.
I corrected all addresses from "Canada da Inês" to "Canada do Inês.

Hello.
You have deleted this protected area boundary with this changeset. relation/8013244/history
I am going to fix it. Don't worry.
Be careful while editing so that you don't hit the delete button accidentally.
Good mapping!

Hello
I made these edits because all relations on OSM need to have a type= tag. That's mandatory by design. That's why the disused:type tag needed to be replaced by type=something.
Thanks

Hello Baloo
Thank you for your constructive criticism. My main goal with this edit was dealing with a relation without members or tags.
The lane separation is visible on Bing imagery. I'm not used to do turn lane tagging, but maybe you can help out with that or instead add a note on osm.org so that a mapper can have a look into that.
---

Published using OSMCha: https://osmcha.org/changesets/157853615

source is Bing; Azores Trails

You're welcome!

Hello mapatite and Thank you for noticing this.
I've decided to change those highways to what they were before. These roads are classified as CF (Caminho Florestal en: Forestry road) and are managed by a government entity.
The forestry roads generally are wide enough and smooth enought for regular traffic.
In this instance they are even an option if one would want to go from Fajãzinha to Ponta Delgada.
The thing is that this type of forestry road with a regional classification and a clear interest for routing doesn't quite fit within the portuguese mapping standards as the road network is managed very differently in the Azores compared to Portugal mainland.
A proposal for mapping standards regarding highways in the Azores, and subsequent discussion and approval has to happen before a more systematic edit is made to the forestry roads and agricultural roads.

Hello Casper,

Thank you for your seeing that these areas aren't used by tractors. They're used by a motorized plow at most.
I did what I believed was best.
The definition of an Allotment on the wiki seems to be quite ambiguous. The portuguese wiki is more suggestive of the tag applying on urban vegetable gardens as it describes the scope as "hortas urbanas" which translates as urban vegetable gardens.
I guess the tag documentation should be further developed and clarified in my opinion. There can also be different portuguese standards at play. I will inquiry the Portuguese telegram group about this.
The allotment description seems to include the scenario where a family owns or rents the plot to grow their food, which seems to be the case of these plots adjacent to the houses. On the other hand it seems to fail to embrace the access tag that should be used to define if the allotment is for private use or communal. But again, an allotment doesn't seem to include the case for private land use.
It's confusing and in my opinion it would make sense to propose a landuse=vegetable_garden which encompasses both realities to coexist.
I'm okay with adopting leisure=garden as suggested but keep in mind these areas aren't used as leisure and I'll also hear what the portuguese community has to say.

Take care
Emanuel

Hello Casper,

I will change my mapping style according to your suggestions.
My intent is to map according to the best practices.
Feel free to help, I will do what I can as well but it will take time to rearrange everything as there's a lot of data to manipulate and not so much free time.
Thanks

Hello Friendly_Ghost,
Thanks for commenting this changeset.
I've been mapping Faial island over the last 9 years as a leisure activity on free time. At such a scale, you can see that at some point some growing pains are going to occur and consequently, a mapping style had to be implemented in order to make the database more maintainable and scalable. This is a continuous process.
Individual areas are effective and simple to implement, but much less scalable and maintainable. Imagine that you have a forest next to a meadow. There's now a duplicate line, sharing the same geometry. Add a wall or fence between the two, now it's a triple line. Now imagine that somewhere in the future someone build a house that occupies part of the meadow next to said forest. That'd be a big challenge to unglue things and then map the house's residential area. That's a situation where multipolygons can be very powerful. You can easily map at scale. You set a forest tag scheme for a eucalyptus forest for instance, and you just need to add the corresponding loops to the multipolygon. No need to tag every tag to every area every time.
The multipolygons became bigger over time as mapping naturally progressed. What's a big multipolygon to you? These follow the complex combination of features as described in
osm.wiki/Relation:multipolygon#Members
There doesn't seem to be a limit to the number of members, but I can see that doing multipolygon geometry validation on some computers would be very slow.
I'm currently transitioning into one multipolygon per parish in Faial island. This process is happening as I map, but feel free to help! But please don't split a multipolygon with thousands of rings into thousands of multipolygons, as It'd make editing in JOSM close to impossible, as the user would have to endlessly scroll on the relations panel.
Good mapping
Thanks

Hello Friendly_ghost
Thanks for commenting this changeset.
The way you refered is indeed part of someone's backyard. The thing is, how should a backyard be mapped when the house owner sets a certain area aside in order to grow fruits or vegetables?
I tend to map what's on the gound, and so I would assign landuse=residential whenever someone's backyard is made of grass with ornamental trees or shrubs and the area if preferencially used by the residents to "reside".
I see that when the land is plowed or is occupied by fruit trees the main objective is to grow food and not to reside.
Good mapping!
Thanks

Hello Endres,
Thanks for your insights. In fact, the multipolygons have been growing in members over time.
I already started implementing a multipolygon separation workflow, in order to make the multipolygons smaller.
For now, the idea is to have a multipolygon per parish. That's going to make things better.
Thank you