Proposal talk:Key:spacing=*
--- 2018-04-23 osm.tagging@thorsten.engler.id.au via openstreetmap.org:
This looks very useful. If the better rendering for tree_row gets anywhere, I would very much like to see the same applied to ways tagged as barrier=bollard (representing a row of bollards) as well (which are currently unfortunately not rendered at all).
spacing=* sounds like a good key for that.
Tobias Knerr osm@tobias-knerr.de via openstreetmap.org 18 apr. I like the idea. Way back, during the the tree row proposal, it was suggested that either this key or a "number of trees" key should be documented, and it makes a lot of sense in my opinion.
Mentioned that for individual trees natural=tree should be used. --Peter Elderson (talk) 09:06, 24 April 2018 (UTC)
As a general rule a good tag or tagging proposal should be mapper oriented, it should be designed to allow mappers to document verifiable aspects of the observable geography in an efficient, precise and non-ambiguous way.
--Peter Elderson (talk) 21:37, 5 May 2018 (UTC) Agreed. And I think that is what de spacing=* key does, when applied to the object "tree_row". The mapper can be as precise in measuring and documenting the average spacing as (s)he wishes. It is non-exact in the sense that it does not indicate the exact location of individual trees - that's precisely why there is a tree_row object. I do not see any ambiguity there, could you explain?
Why don't we tag spacing=* on a power=line instead of tagging every pole with power=pole? Because if we have the information and the time as a mapper to verifiably determine this we can normally also go ahead and map the poles anyway which makes the data much more meaningful and valuable in general. And because actually measuring the spacing between the poles, in particular if it varies, is practically harder than just mapping the positions of the poles.
--Peter Elderson (talk) 21:37, 5 May 2018 (UTC) Again, I see your point. That's why there is no pole_row object for power poles: the row of poles is not that interesting, the powerline is, and that a real line whereas a tree_row is not a line. But the exact position of the power poles can be valuable. It is an object/destination in itself. However, in a tree_row, the exact position of every tree is not that important, the individual tree is not a destination. It's the length, trajectory and aspect of the tree_row that's valuable. If any one of the trees in a tree_row is a destination or a functional element in itself, it should of course be tagged as an individual tree. In Nederland, a tree_row often runs for many Kilometers, some are double or triple rows. A stretch of road or a canal can easily be lined with many thousands of trees, none of which is in itself interesting or a destination of its own. But the tree_row is very much a real feature and the aspect is important in the landscape.
If i try to ignore the rendering related aspects of your proposal it
boils down to being deliberately non-exact. Why would a mapper want to
do that? If i want to map a tree row in a quick and dirty way i draw a
way and tag it natural=tree_row. If i want to map it in more detail i
map and tag the individual trees. I don't see tagging spacing=* as an
intermediate solution here.
--Peter Elderson (talk) 21:37, 5 May 2018 (UTC) I will rephrase, to clarify that it's not about the locations of individual trees, but about a measurable aspect of the entire tree_row, forest area or orchard.
If as a style developer you want to render tree rows styled depending on
the tree density the way to go would IMO be to encourage mappers to map
individual trees (which current documentation of natural=tree_row
considers valid when done in addition) and determine the spacing from
these.
--Peter Elderson (talk) 21:37, 5 May 2018 (UTC) The sheer number of trees in tree_rows make this impossible. Almost every street, road, motorway, waterway, water area, recreational area, golf course, farm, swimming pool, allotment area, even forest, is lined with a tree_row. You could do this maybe for a part of one city, but nobody is going to map every individual tree in all the tree_rows, even in a small country as the Netherlands. More importantly, the exact location of the individual trees is of no interest for people or applications, but the density (measurable as average spacing of the row) is.
- You say you agree to my general rule in the introduction but you then contradict this by defending your proposal by stating that mapping certain things is more important/valuable than others - which is obviously not mapping oriented but data use oriented (for a certain specific data use you have in mind). If you want to write a good proposal you would have make yourself free of the specific perceived requirements and preferences of the data use that motivates you (which i suppose is difficult since you seem to be very focused on this). --Imagico (talk) 09:07, 6 May 2018 (UTC)
- The proposal template requires me to go into uses and rendering. I get that, because information that is not used or rendered is not useful. If you say spacing is not useful for powerlines, I believe you; I have no specific knowledge of that. But I think the spacing actually does allow mappers to document verifiable aspects of the observable geography in an efficient, precise and non-ambiguous way. If you look at a forest, the spacing attribute is an efficient way to document the observable density. The measurement can be as precise as you want it to be. It does not aim to indicate the exact location of trees, it is a dimensional attribute of that piece of forest. Same with tree_row. Spacing (average distance between elements) indicates the density of the whole thing, and that is an observable and verifiable attribute. At the same time it is useful and renderable. There is no ambiguity there: it serves both mappers and users. --Peter Elderson (talk) 07:22, 7 May 2018 (UTC)
Number
> number=* has been suggested. Divide the length of the way by the number of objects minus one gives the average spacing. This would work for small ways, maybe an orchard, but for a row of trees stretching 10 Km along a regional road estimating the number is a problem in itself.
- No, of course not. If you have the length, and you should have the length, you divide the length by the spacing to get the number.
- But spacing is slightly easier for rendering (no computation needed) and more stable (if you split a tree row into two due to a new road, the spacing is kept.
--Nospam2005 (talk) 12:36, 13 May 2018 (UTC)
- --Peter Elderson (talk) 13:11, 13 May 2018 (UTC) The idea was to record the counted total number of trees, which would then enable calculating the spacing/density of the tree_row. But that's no option for very long tree_rows. For a forest, it is even more impossible. That's why it's turned around: measure the spacing as accuretely as you want from a managable stretch or area, then determine how long the tree_row stayss that way. If anyone is interested in the total number of trees for any purpose, it can be calculated. I had not thought about the effect of splitting the tree_row or dividing the forest into multiple areas. Thanks for pointing that out.
- Counting is generally easier and more precise than measuring. For example, we usually count the number of steps (step_count=*) instead of measuring the steps' length. Of course, for very long tree rows spacing is likely the better choice. So maybe both options can make sense depending on the circumstances. --Tordanik 22:00, 15 May 2018 (UTC)
- --Peter Elderson (talk) 07:43, 16 May 2018 (UTC) Average spacing (as a measure of density) is meant to be a dimension of the way or area. For a short row of objects, counting all of them is the most precise way to determine the average spacing. For a forest, who's going to count the trees? Who wants to know the numer of trees? Same for a long tree_row: here in Nederland tree_rows easily extend 5-10 or more Kilometers, and almost every road, canal, lake and area is lined by rows of trees. The exact positions of individual trees and the exact total numbers are not the characteristics that people want to see on a map or application, I think. Going back to counting: the more you count, the more precise the measurement of density/spacing is. If you can count them all, you have maximum precision for the density/spacing dimension.