|Status:||Draft (under way)|
|Definition:||a means of defining smaller sections of a large homogeneous area (car parks, cemeteries, forests)|
|Rendered as:||label only at node or centre of area|
It is often difficult to locate oneself in a large homogeneous area, such as a forest, airport or mall car park or large cemetery. Additionally, it may be important for accurate navigation to ones goal, for instance: finding one's car, or a specific grave. In many of these places signs are placed using a combination of numbers and letters to uniquely identify part of the area. This proposal tentatively proposes a tagging scheme to provide for these identified use cases.
- Cemeteries. Individual plots are often numbered, and also have described the place (addr:place=<East>) and the row (addr:row=<14>) in the sector (addr:sector=<XXVI>).
- Car Parks.
- Forests. The specific example in mind is the Forest of Fontainebleau, where intersections of paths have metal plates with a number identifying each sector of the forest. These numbers are included on the relevant Top25 maps of the IGN. (German names for such sections are: Forstabteilungsnummer, Jagenzahl, Jagennummer, Forstliches Abteilungsnetz)
- Allotment Gardens. Individual plots are often numbered, and maps are often shown at the entrance to such places.
One reasonable alternative option is to use place=locality. Another is to create the larger area as multiple individual areas with the appropriate tag (landuse=cemetery, landuse=forest, amenity=parking. However this is considerably more labour intensive and loses the ability to name the entire feature without using relations.
The suggested minimum rendering would be the name tag at the point of the node or centroid of the area. Rendering should be similar to that for landuse areas, but disambiguated in some way, for instance smaller size or italic font. Optionally the bounds of the area could also be shown, although in general it is expected that these will be already existing features, typically paths or roads for the three described use cases.
- Node, Ways or Relations. In most cases the section will be delineated by other mapped features (roads, paths, waterways, or forest breaks), in which case the logical way would be to use a relation (e.g., multipolygon). Relations would avoid introducing new top level tags to ways as well. So this is probably preferable. Easiest to implement in the short term is to use single nodes to effectively provide a label.
- Tag Names. Various alternatives to section can be imagined, such as sector, zone.
- Key Name. Ideally this would be a value in some existing key name, but which one might be appropriate eludes me for now. Options might be place=section, forest=section, parking=section or cemetery=section.