Feature Proposal - RFC - key:spacing=* gestart

Peter_Elderson · 2018-05-05T17:18:18.000Z

Dit voorstel heb ik in diskussie gebracht op de tagging list, als vervolg op de diskussie hier over tree_row: https://forum.openstreetmap.org/viewtopic.php?id=61887

Het voorstel gaat niet meer specifiek over tree_row maar over spacing=* als algemeen bruikbare dimensiekenmerk vgl lengte, breedte, hoogte, diepte, elevatie. Daarom even een nieuw onderwerp gestart.

Kommentaar is welkom!

*Feature Proposal - RFC - key:spacing=
**
https://wiki.openstreetmap.org/wiki/Proposed_features/Key:spacing%3D*

According to Proposal Process:
Please discuss each proposed feature on its own discussion page.

Proposed feauture is a new key:spacing=* to indicate estimated average spacing (or it’s counterpart: density), of objects along a way or on an area.

The key is proposed as part of a rendering proposal for natural=tree_row, but it’s easy to see how it can be applied to any case where objects are more or less grouped or arranged together with a kind of regularity. In that respect spacing=* is a general purpose dimension tag like height, width, length and ele.

However, the proposed usage is explicitly non-exact: think of the spacing of trees in a tree_row or in a forest, or a barrier consisting of lengths of fence between poles. These objects are often described verbally as “very dense”, “a tree every 10 feet” or “widely spaced, about 50 meters apart”.

So the goal is to give an indication of the spatial distribution along the way or over the area, rather than an exact measurement of distances between separate actual objects. If exact positions are required for all or some of the trees in a row, these trees should be individually mapped and tagged as natural=tree. (The individual nodes may be attached to the tree_row way, which provides an easy method for aligning tree nodes within a row, but you need to tag them separately.)

That way you don’t need to worry about the dimension or shape of single objects, or that in fact some are 9 m apart and others are 11 m apart. Measurement is simple: take a sample length of the way divided by the number of sections (= #objects minus one). For people who think exact: picture a grid where every point is N m apart from it’s neighbours, then objects are placed on or near the grid points.

Tagging
spacing=N where N is average space between points representing objects (e.g. average heart-to-heart distance between trees)

units are in m unless otherwise specified (N u).

Use with natural=tree_row, natural=wood, landuse=forest, landuse=orchard, natural=scrub, barrier=hedge, or any other way or surface with more or less regularly spaced objects.

Note that the key gives spacing for the whole way or area. It is not an attribute of the objects themselves and does not imply exact placement of the objects.

Applies to
linear ways representing a loosely or densely spaced row of objects, exemplified by a tree_row. Other examples: a row of bollards, a row of stepping stones to cross a waterway, a row of street lights.
areas representing a surface loosely or densely covered with objects, exemplified by a forest or an orchard.

JeroenHoek · 2018-05-05T18:01:17.000Z

Klinkt logisch en goed doordacht.

Bij het rendervoorbeeld toon je nu ook streepjes tussen de objecten (bomen), maar eigenlijk kun je die ook wel weglaten. Dat de bomen op een rij staan zie je zonder ook (en less is more qua design), en mappers zien in hun editor wel dat het een treerow (etc.) is in plaats van een losse reeks bomen (etc.).

Wat misschien nog goed is om te omschrijven is hoe een render om zou moeten gaan met lijnen met spacings die niet heel deelbaar zijn, en hoe er met segmenten omgegaan moet worden.

Als je bijvoorbeeld een way hebt die 15m lang is, en je zet de spacing op 4, dan kun je drie soorten gedrag verwachten:

Uitrekken tot het past: de renderer plaatst objecten op 0m, 5m, 10m, en 15m.

Invullen vanaf het startpunt van de lijn: de renderer plaatst objecten op 0m, 4m, 8m, en 12m.

Invullen vanuit het midden: de renderer plaatst objecten op 1,5m, 5,5m, 9,5m, en 13,5m.

Wat doe je bij een lijn die uit meerdere segmenten bestaat? Krijg je in ieder geval op de nodes een object en vul je de rest zo goed als mogelijk in? Of begin je ook van de start en houdt je strikt de spacing aan?

Peter_Elderson · 2018-05-05T18:32:25.000Z

Bedankt voor de aanvulling. Ik neem dat mee naar het rendervoorstel. Wat ik geprobeerd heb duidelijk te maken is dat elke suggetsie dat het om exacte positonering van bomen gaat, niet de bedoeling is. Dus geen punten in de groene bollen, want dan denk je gelijk aan een boom per bolletje. Het gaat om een symbolische weergave, afhankelijk van een gemiddelde/geschatte afstand.

Bij een bos zou je de boomikoontjes dichter bij elkaar kunnen zetten, of een iets donkerder kleur groen gebruiken. Niemand gaat daar denken dat elk ikoontje een boom is. Zo zou het in een tree_row ook moeten werken. Maar ik wil dus de renderoverwegingen voeren op het moment dat dat op github aan de orde komt. Ik vertrouw erop dat ze daar met oplossingen komen!

Aanvulling: nodes zijn in dit geval geen objecten, dus ik zou het liefst de groene bolletjes (of andere symbolen, het hoeft niet perse een groen bolletje te zijn) over de hele lengte van de way verdelen, overbodige nodes negeren, en dan de lijn knikken waar een hoeknode staat.