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