Re: [Tagging] Feature Proposal - RFC - key:spacing=*

[Peter Elderson]

It's mainly about the naturals tree_row and forest, they are mapped without
specifying individula trees. Of they contain trees that are in themselves
interesting enough, they can be mapped individually, but most trees are
just trees in a forest or row. A useful atrribute of forest or treerow is
density. This can be easily measured and documented as average spacing.
About the numbers: trees in forests, nobody is going to count them, it's
impossible. Short tree_rows can be counted, but in the Netherlands almost
every road, motorway, swinmming pool, parking lot, park, waterway, farm,
...,  and even forests are lined with tree rows. Often double and triple
rows along hundreds of miles of roads water areas and canals. None of the
separate trees are interesting, but the lining tree_rows and the aspect are
significant elements in de landscape. So nobody is going to count those
trees, let alone map those trees individually. And think of the change
rate, you would need lifetimes just to keep up with small changes, whereas
the forest or tree_row as a whole remains the same.


2018-05-06 22:20 GMT+02:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 6. May 2018, at 04:36,  <
> osm.tagg...@thorsten.engler.id.au> wrote:
> >
> > Exactly locating and mapping every single tree along a long tree row can
> take hours. And in the majority of cases, you are probably not going to be
> much more exact than a tree_row with spacing would have been, given the
> usual size of trees and the precision you can get from GPS or not
> ultra-high resolution imagery.
>
>
> I tend to disagree, particularly because it can be most interesting to see
> where there are disturbances in the rhythm. „Multiplying“ trees with
> copy+paste is quite fast, the resulting individual trees can be easily
> refined (e.g. species, diameter, can be „virtually logged“ after they fell,
> etc.). Getting to a reasonable spacing distance requires a lot of counting,
> some measurement and a division, or you will end up with cumulative errors
> that start becoming significant.
> Individual trees are better suited for iterative improvements, they are
> simpler to create and easier to maintain. Trees are big enough you don’t
> need super hires imagery.
>
> I agree there are situations where regular spacing would be best recorded
> as a tag, but I wouldn’t count trees in. For a row of bollards or the
> spacing of fence posts (for example) it could make sense.
>
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

[osm.tagging]

> -Original Message-
> From: Daniel Koć 
> Sent: Monday, 7 May 2018 06:03
> 
> However I think that measuring spacing is worse than just measuring
> the number of trees. It's more mapper friendly and less error prone.

I've you have a long road with trees along it, it's easy and fast to estimate 
the spacing at one location and easy to see that the spacing remains roughly 
the same along the whole road.

But counting the total number of trees is a lot more involved.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

[Martin Koppenhoefer]

sent from a phone

> On 6. May 2018, at 22:03, Daniel Koć  wrote:
> 
> We use address
> interpolation exactly because it's nice to know even if you don't have
> the time to add specific address points.



if you look at taghistory you can see addr:interpolation is almost standing 
still for 2 years while addr:housenumber is still growing linearly. 



> We need more solutions for
> mappers not having exact informations, just something more general.


sounds like a nightmare. I believe demanding exact information is also 
educative: it instructs people to look thoroughly. 

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

[Martin Koppenhoefer]

sent from a phone

> On 6. May 2018, at 04:36,  
>  wrote:
> 
> Exactly locating and mapping every single tree along a long tree row can take 
> hours. And in the majority of cases, you are probably not going to be much 
> more exact than a tree_row with spacing would have been, given the usual size 
> of trees and the precision you can get from GPS or not ultra-high resolution 
> imagery.


I tend to disagree, particularly because it can be most interesting to see 
where there are disturbances in the rhythm. „Multiplying“ trees with copy+paste 
is quite fast, the resulting individual trees can be easily refined (e.g. 
species, diameter, can be „virtually logged“ after they fell, etc.). Getting to 
a reasonable spacing distance requires a lot of counting, some measurement and 
a division, or you will end up with cumulative errors that start becoming 
significant.
Individual trees are better suited for iterative improvements, they are simpler 
to create and easier to maintain. Trees are big enough you don’t need super 
hires imagery. 

I agree there are situations where regular spacing would be best recorded as a 
tag, but I wouldn’t count trees in. For a row of bollards or the spacing of 
fence posts (for example) it could make sense.

Cheers,
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

[Daniel Koć]

W dniu 06.05.2018 o 04:36, osm.tagg...@thorsten.engler.id.au pisze:

> I very much see this as a valid intermediate solution. Getting an
> estimate of the average spacing between trees along a tree row takes
> seconds. 

I also think it's better to have something like this. We use address
interpolation exactly because it's nice to know even if you don't have
the time to add specific address points. We need more solutions for
mappers not having exact informations, just something more general.

However I think that measuring spacing is worse than just measuring the
number of trees. It's more mapper friendly and less error prone.


-- 

"My method is uncertain/ It's a mess but it's working" [F. Apple]



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - key:spacing=*

[osm.tagging]

> -Original Message-
> From: Christoph Hormann <o...@imagico.de>
> Sent: Sunday, 6 May 2018 03:37
> To: Tag discussion, strategy and related tools
> <tagging@openstreetmap.org>
> Subject: Re: [Tagging] Feature Proposal - RFC - key:spacing=*
> 
> 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.

I very much see this as a valid intermediate solution. Getting an estimate of 
the average spacing between trees along a tree row takes seconds. 

Exactly locating and mapping every single tree along a long tree row can take 
hours. And in the majority of cases, you are probably not going to be much more 
exact than a tree_row with spacing would have been, given the usual size of 
trees and the precision you can get from GPS or not ultra-high resolution 
imagery.

Which means that people would probably mostly draw a line, with the estimated 
number of nodes that there are trees, use the "distribute equally" function and 
tag them all as natural=tree. 

Congratulation, you've now used many nodes, and pretend an exactness of the 
data that doesn't exist, for zero additional benefit over a two node tree_row 
way with spacing.



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - key:spacing=*

[Peter Elderson]

 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[bewerken

 | brontekst bewerken

]

*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[bewerken

 | brontekst bewerken

]

   - 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.


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging