Estimated values for height

classic Classic list List threaded Threaded
33 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Estimated values for height

cascafico
I'm going to import a small dataset of trees. Some tree heights are defined as "measured", some as "estimated".

About estimated values, I've found a wiki definition only for width [1]: shall I
derive an est_height tag,
go for most popular taginfo solutions,
simply assign an estimated value to height tag?




_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

--
cascafico.altervista.org
twitter.com/cascafico
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

AlaskaDave
There is already an est_width tag (Taginfo 77,000). I see no reason why you couldn't use est_height, which has over 1000 instances in Taginfo.

Dave

On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni <[hidden email]> wrote:
I'm going to import a small dataset of trees. Some tree heights are defined as "measured", some as "estimated".

About estimated values, I've found a wiki definition only for width [1]: shall I
derive an est_height tag,
go for most popular taginfo solutions,
simply assign an estimated value to height tag?



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Lionel Giard
You can also use height=* for both and add a "souce:height=estimated / measured" tag with that to have a value that is usable by the apps and tools but still keeping the information that it was only estimated ! ;-) 


Lionel



Le ven. 9 nov. 2018 à 10:19, Dave Swarthout <[hidden email]> a écrit :
There is already an est_width tag (Taginfo 77,000). I see no reason why you couldn't use est_height, which has over 1000 instances in Taginfo.

Dave

On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni <[hidden email]> wrote:
I'm going to import a small dataset of trees. Some tree heights are defined as "measured", some as "estimated".

About estimated values, I've found a wiki definition only for width [1]: shall I
derive an est_height tag,
go for most popular taginfo solutions,
simply assign an estimated value to height tag?



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

marc marc
look at the current values in height, you understand from their
round values that they are massively estimated.

my preference is therefore to use height and make 2 changset
to put a changeset tag related to the source
of the measurement: measured <> estimated

Le 09. 11. 18 à 10:57, Lionel Giard a écrit :

> You can also use height=* for both and add a "souce:height=estimated /
> measured" tag with that to have a value that is usable by the apps and
> tools but still keeping the information that it was only estimated ! ;-)
>
>
> Lionel
>
>
>
> Le ven. 9 nov. 2018 à 10:19, Dave Swarthout <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     There is already an est_width tag (Taginfo 77,000). I see no reason
>     why you couldn't use est_height, which has over 1000 instances in
>     Taginfo.
>
>     Dave
>
>     On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         I'm going to import a small dataset of trees. Some tree heights
>         are defined as "measured", some as "estimated".
>
>         About estimated values, I've found a wiki definition only for
>         width [1]: shall I
>         derive an est_height tag,
>         go for most popular taginfo solutions,
>         simply assign an estimated value to height tag?
>
>
>
>         [1] https://wiki.openstreetmap.org/wiki/Key:est_width
>         _______________________________________________
>         Tagging mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>     --
>     Dave Swarthout
>     Homer, Alaska
>     Chiang Mai, Thailand
>     Travel Blog at http://dswarthout.blogspot.com
>     _______________________________________________
>     Tagging mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

AlaskaDave
You can also use height=* for both and add a "source:height=estimated / measured" tag with that to have a value that is usable by the apps and tools but still keeping the information that it was only estimated ! ;-)

An excellent solution, Lionel

On Fri, Nov 9, 2018 at 5:06 PM marc marc <[hidden email]> wrote:
look at the current values in height, you understand from their
round values that they are massively estimated.

my preference is therefore to use height and make 2 changset
to put a changeset tag related to the source
of the measurement: measured <> estimated

Le 09. 11. 18 à 10:57, Lionel Giard a écrit :
> You can also use height=* for both and add a "souce:height=estimated /
> measured" tag with that to have a value that is usable by the apps and
> tools but still keeping the information that it was only estimated ! ;-)
>
>
> Lionel
>
>
>
> Le ven. 9 nov. 2018 à 10:19, Dave Swarthout <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     There is already an est_width tag (Taginfo 77,000). I see no reason
>     why you couldn't use est_height, which has over 1000 instances in
>     Taginfo.
>
>     Dave
>
>     On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         I'm going to import a small dataset of trees. Some tree heights
>         are defined as "measured", some as "estimated".
>
>         About estimated values, I've found a wiki definition only for
>         width [1]: shall I
>         derive an est_height tag,
>         go for most popular taginfo solutions,
>         simply assign an estimated value to height tag?
>
>
>
>         [1] https://wiki.openstreetmap.org/wiki/Key:est_width
>         _______________________________________________
>         Tagging mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>     --
>     Dave Swarthout
>     Homer, Alaska
>     Chiang Mai, Thailand
>     Travel Blog at http://dswarthout.blogspot.com
>     _______________________________________________
>     Tagging mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

bkil
Yes, that sounds reasonable. Also there's height:accuracy if you know your error.

On Fri, Nov 9, 2018 at 11:42 AM Dave Swarthout <[hidden email]> wrote:
You can also use height=* for both and add a "source:height=estimated / measured" tag with that to have a value that is usable by the apps and tools but still keeping the information that it was only estimated ! ;-)

An excellent solution, Lionel

On Fri, Nov 9, 2018 at 5:06 PM marc marc <[hidden email]> wrote:
look at the current values in height, you understand from their
round values that they are massively estimated.

my preference is therefore to use height and make 2 changset
to put a changeset tag related to the source
of the measurement: measured <> estimated

Le 09. 11. 18 à 10:57, Lionel Giard a écrit :
> You can also use height=* for both and add a "souce:height=estimated /
> measured" tag with that to have a value that is usable by the apps and
> tools but still keeping the information that it was only estimated ! ;-)
>
>
> Lionel
>
>
>
> Le ven. 9 nov. 2018 à 10:19, Dave Swarthout <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     There is already an est_width tag (Taginfo 77,000). I see no reason
>     why you couldn't use est_height, which has over 1000 instances in
>     Taginfo.
>
>     Dave
>
>     On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         I'm going to import a small dataset of trees. Some tree heights
>         are defined as "measured", some as "estimated".
>
>         About estimated values, I've found a wiki definition only for
>         width [1]: shall I
>         derive an est_height tag,
>         go for most popular taginfo solutions,
>         simply assign an estimated value to height tag?
>
>
>
>         [1] https://wiki.openstreetmap.org/wiki/Key:est_width
>         _______________________________________________
>         Tagging mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>     --
>     Dave Swarthout
>     Homer, Alaska
>     Chiang Mai, Thailand
>     Travel Blog at http://dswarthout.blogspot.com
>     _______________________________________________
>     Tagging mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Sergio Manzi

Hello everybody,

I'm the one who, in the Italian mailing list, first brought out the issue about how to tag estimated heights (in our context it was about trees height).

My first proposal has been to use a new sub-key in which to store estimated values, as in "height:estimated=10".

Then I saw, here, the proposal of using "source:height=estimated", which is in use (1543 entries, mostly applied to ways: see: [1]), which I thought was a better solution then the one I originally conceived.

Now I see that there is a different solution in use, "height:source=estimated", which is less used (149 entries, mostly applied to ways: see: [2]), but makes even more sense to me, from a syntactical point of view.

Someone also proposed to use "height:accuracy=*" if the accuracy is known, but I think this could be used for an estimated value too (height:accuracy=estimated). On the other hand this doesn't seems to be in use anywhere even though it might be considered an even better solution both syntactically and semantically (I think "source" should be used to identify "who" is the originator of the information).

In any case I think the various est_(width|length|height|whatever) keys should be deprecated and a new universal solution to identify estimated values  should be adopted, taken from the ones described above (or a new one I'm not thinking of at this time).

Regards,

Sergio

[1] https://taginfo.openstreetmap.org/tags/source%3Aheight=estimated
[2] https://taginfo.openstreetmap.org/tags/height%3Asource=estimated


On 2018-11-11 10:07, bkil wrote:
Yes, that sounds reasonable. Also there's height:accuracy if you know your error.

On Fri, Nov 9, 2018 at 11:42 AM Dave Swarthout <[hidden email]> wrote:
You can also use height=* for both and add a "source:height=estimated / measured" tag with that to have a value that is usable by the apps and tools but still keeping the information that it was only estimated ! ;-)

An excellent solution, Lionel

On Fri, Nov 9, 2018 at 5:06 PM marc marc <[hidden email]> wrote:
look at the current values in height, you understand from their
round values that they are massively estimated.

my preference is therefore to use height and make 2 changset
to put a changeset tag related to the source
of the measurement: measured <> estimated

Le 09. 11. 18 à 10:57, Lionel Giard a écrit :
> You can also use height=* for both and add a "souce:height=estimated /
> measured" tag with that to have a value that is usable by the apps and
> tools but still keeping the information that it was only estimated ! ;-)
>
>
> Lionel
>
>
>
> Le ven. 9 nov. 2018 à 10:19, Dave Swarthout <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
>     There is already an est_width tag (Taginfo 77,000). I see no reason
>     why you couldn't use est_height, which has over 1000 instances in
>     Taginfo.
>
>     Dave
>
>     On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         I'm going to import a small dataset of trees. Some tree heights
>         are defined as "measured", some as "estimated".
>
>         About estimated values, I've found a wiki definition only for
>         width [1]: shall I
>         derive an est_height tag,
>         go for most popular taginfo solutions,
>         simply assign an estimated value to height tag?
>
>
>
>         [1] https://wiki.openstreetmap.org/wiki/Key:est_width
>         _______________________________________________
>         Tagging mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>     --
>     Dave Swarthout
>     Homer, Alaska
>     Chiang Mai, Thailand
>     Travel Blog at http://dswarthout.blogspot.com
>     _______________________________________________
>     Tagging mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

marc marc
taginfo only count the old/ugly schema with the source
on objects in stead of changest. for a source tag,
it's a count a bad pratice :)

don't forget that :
- tree is growing, so next year, the information that the measurement
was made by a laser with the accuracy of the device will all be out
of date.
- they are also outdated as soon as a mapper changes the tag height
without changing the other x tags, which is the case for most contributors.

so putting these tags on the source, the accuracy of the source, etc. on
the object are useless, they are also searchable via the history on the
changeset, and at least they are no longer modifiable after closing the
changeset, which allows to have a real source instead of having a
"source without any certainty because you still have to read the history
of the object to see if the last modification of the height was made at
the same time as the addition of the source tag


Le 11. 11. 18 à 12:15, Sergio Manzi a écrit :

> Hello everybody,
>
> I'm the one who, in the Italian mailing list, first brought out the
> issue about how to tag estimated heights (/in our context it was about
> trees height/).
>
> My first proposal has been to use a new sub-key in which to store
> estimated values, as in "height:estimated=10".
>
> Then I saw, here, the proposal of using "source:height=estimated", which
> is in use (/1543 entries, mostly applied to ways: see: /[1]), which I
> thought was a better solution then the one I originally conceived.
>
> Now I see that there is a different solution in use,
> "height:source=estimated", which is less used (/149 entries, mostly
> applied to ways: see: /[2]), but *makes even more sense to me, from a
> syntactical point of view*.
>
> Someone also proposed to use "height:accuracy=*" if the accuracy is
> known, but I think this could be used for an estimated value too
> (height:accuracy=estimated). On the other hand this doesn't seems to be
> in use anywhere even though it might be considered an even better
> solution both syntactically and semantically (/I think "source" should
> be used to identify "who" is the originator of the information/).
>
> In any case I think the various est_(width|length|height|whatever) keys
> should be deprecated and a new universal solution to identify estimated
> values  should be adopted, taken from the ones described above (/or a
> new one I'm not thinking of//at this time/)/./
>
> Regards,
>
> Sergio
>
> [1] https://taginfo.openstreetmap.org/tags/source%3Aheight=estimated
> [2] https://taginfo.openstreetmap.org/tags/height%3Asource=estimated
>
>
> On 2018-11-11 10:07, bkil wrote:
>> Yes, that sounds reasonable. Also there's height:accuracy if you know
>> your error.
>>
>> On Fri, Nov 9, 2018 at 11:42 AM Dave Swarthout
>> <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>     You can also use height=* for both and add a
>>     "source:height=estimated / measured" tag with that to have a value
>>     that is usable by the apps and tools but still keeping the
>>     information that it was only estimated ! ;-)
>>
>>     An excellent solution, Lionel
>>
>>     On Fri, Nov 9, 2018 at 5:06 PM marc marc
>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>         look at the current values in height, you understand from their
>>         round values that they are massively estimated.
>>
>>         my preference is therefore to use height and make 2 changset
>>         to put a changeset tag related to the source
>>         of the measurement: measured <> estimated
>>
>>         Le 09. 11. 18 à 10:57, Lionel Giard a écrit :
>>         > You can also use height=* for both and add a
>>         "souce:height=estimated /
>>         > measured" tag with that to have a value that is usable by
>>         the apps and
>>         > tools but still keeping the information that it was only
>>         estimated ! ;-)
>>         >
>>         >
>>         > Lionel
>>         >
>>         >
>>         >
>>         > Le ven. 9 nov. 2018 à 10:19, Dave Swarthout
>>         <[hidden email] <mailto:[hidden email]>
>>         > <mailto:[hidden email]
>>         <mailto:[hidden email]>>> a écrit :
>>         >
>>         >     There is already an est_width tag (Taginfo 77,000). I
>>         see no reason
>>         >     why you couldn't use est_height, which has over 1000
>>         instances in
>>         >     Taginfo.
>>         >
>>         >     Dave
>>         >
>>         >     On Fri, Nov 9, 2018 at 3:58 PM Cascafico Giovanni
>>         >     <[hidden email] <mailto:[hidden email]>
>>         <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>         >
>>         >         I'm going to import a small dataset of trees. Some
>>         tree heights
>>         >         are defined as "measured", some as "estimated".
>>         >
>>         >         About estimated values, I've found a wiki definition
>>         only for
>>         >         width [1]: shall I
>>         >         derive an est_height tag,
>>         >         go for most popular taginfo solutions,
>>         >         simply assign an estimated value to height tag?
>>         >
>>         >
>>         >
>>         >         [1] https://wiki.openstreetmap.org/wiki/Key:est_width
>>         >  _______________________________________________
>>         >         Tagging mailing list
>>         > [hidden email] <mailto:[hidden email]>
>>         <mailto:[hidden email]
>>         <mailto:[hidden email]>>
>>         > https://lists.openstreetmap.org/listinfo/tagging
>>         >
>>         >
>>         >
>>         >     --
>>         >     Dave Swarthout
>>         >     Homer, Alaska
>>         >     Chiang Mai, Thailand
>>         >     Travel Blog at http://dswarthout.blogspot.com
>>         >     _______________________________________________
>>         >     Tagging mailing list
>>         > [hidden email] <mailto:[hidden email]>
>>         <mailto:[hidden email]
>>         <mailto:[hidden email]>>
>>         > https://lists.openstreetmap.org/listinfo/tagging
>>         >
>>         >
>>         >
>>         > _______________________________________________
>>         > Tagging mailing list
>>         > [hidden email] <mailto:[hidden email]>
>>         > https://lists.openstreetmap.org/listinfo/tagging
>>         >
>>
>>         _______________________________________________
>>         Tagging mailing list
>>         [hidden email] <mailto:[hidden email]>
>>         https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>>     --
>>     Dave Swarthout
>>     Homer, Alaska
>>     Chiang Mai, Thailand
>>     Travel Blog at http://dswarthout.blogspot.com
>>     _______________________________________________
>>     Tagging mailing list
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> _______________________________________________
>> Tagging mailing list
>> [hidden email]
>> https://lists.openstreetmap.org/listinfo/tagging
>
>
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Andy Townsend
On 11/11/2018 15:12, marc marc wrote:
> taginfo only count the old/ugly schema with the source
> on objects in stead of changest. for a source tag,
> it's a count a bad pratice :)


No, putting a source on an object is not "bad practice".  If the source
for all of the objects in a changeset is the same then of course it
makes sense to use a changeset tag for the source rather than repeating
the same object tag many times, but if different objects in the
changeset have different sources then it is extremely helpful to other
mappers to include them.  It's not compulsory (almost nothing is in OSM)
but it can be helpful.

Best Regards,

Andy



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Sergio Manzi
In reply to this post by marc marc

Yes, agreed, but in our user case we are importing official government data about historical/monumental/landmark trees and one of the fields that will be imported is the survey date (survey:date).

If, at a second time, someone will update info about the tree height I hope he/she will have the good sense of updating the survey date as well or, probably better, leave a note about the height datum having being updated (will that be height:survey:date=* ?)

On 2018-11-11 16:12, marc marc wrote:
don't forget that :
- tree is growing, so next year, the information that the measurement 
was made by a laser with the accuracy of the device will all be out

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

dieterdreist
In reply to this post by Sergio Manzi
Am So., 11. Nov. 2018 um 12:17 Uhr schrieb Sergio Manzi <[hidden email]>:

Hello everybody,

I'm the one who, in the Italian mailing list, first brought out the issue about how to tag estimated heights (in our context it was about trees height).

My first proposal has been to use a new sub-key in which to store estimated values, as in "height:estimated=10".

Then I saw, here, the proposal of using "source:height=estimated", which is in use (1543 entries, mostly applied to ways: see: [1]), which I thought was a better solution then the one I originally conceived.

Now I see that there is a different solution in use, "height:source=estimated", which is less used (149 entries, mostly applied to ways: see: [2]), but makes even more sense to me, from a syntactical point of view.

Someone also proposed to use "height:accuracy=*" if the accuracy is known, but I think this could be used for an estimated value too (height:accuracy=estimated). On the other hand this doesn't seems to be in use anywhere even though it might be considered an even better solution both syntactically and semantically (I think "source" should be used to identify "who" is the originator of the information).

In any case I think the various est_(width|length|height|whatever) keys should be deprecated and a new universal solution to identify estimated values  should be adopted, taken from the ones described above (or a new one I'm not thinking of at this time).




I believe there is way too much fuzz about this, almost every number in OSM is estimated, the height of a tree cannot be measured to the mm even with the most precise instruments (and even if you could, it would be outdated within the same day). Just add the height.

Cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

dieterdreist
In reply to this post by Andy Townsend
Am So., 11. Nov. 2018 um 17:11 Uhr schrieb Andy Townsend <[hidden email]>:
No, putting a source on an object is not "bad practice".  If the source
for all of the objects in a changeset is the same then of course it
makes sense to use a changeset tag for the source rather than repeating
the same object tag many times, but if different objects in the
changeset have different sources then it is extremely helpful to other
mappers to include them.  It's not compulsory (almost nothing is in OSM)
but it can be helpful.



it is also good practice to divide/structure your changesets according to the sources, so that it doesn't happen you have different sources within the same changeset, at least not deliberately (by adding source tags to the objects).

I see lots of (for example) "source=bing" which likely imply traced by a mapper as seen on aerial imagery from Bing (but it could also mean she imported the object from data released by Bing, or based on a website found through bing, etc.), and his tag is completely worthless if I don't look at the history to see which things have been modified or added or deleted in the changeset that introduced the tag, and I must also verify that all edits that came later didn't change these things (and the mapper simply kept the source tag without updating it).

Cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Sergio Manzi
In reply to this post by dieterdreist

Please, just forget about trees (and the fact that they obviously grow...): trees have only been the "casus belli", the case for which we asked ourselves how "Estimated values for height" (the topic of this thread...) should be tagged.

The real question, I think, is if it is correct to have all those est_* keys or there could be a better way to indicate the accuracy of a measure.

Cheers,

Sergio


On 2018-11-12 11:01, Martin Koppenhoefer wrote:

I believe there is way too much fuzz about this, almost every number in OSM is estimated, the height of a tree cannot be measured to the mm even with the most precise instruments (and even if you could, it would be outdated within the same day). Just add the height.

Cheers,
Martin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Warin
In reply to this post by dieterdreist
On 12/11/18 21:01, Martin Koppenhoefer wrote:
> Just add the height.
>

+1.

Some mappers are reluctant to change previous entries because they think
the previous mapper might object or have better data.
I sometimes include a comment about how rough my entry is, thinking that
someone can improve it.



_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Warin
In reply to this post by Sergio Manzi
On 12/11/18 21:23, Sergio Manzi wrote:

Please, just forget about trees (and the fact that they obviously grow...): trees have only been the "casus belli", the case for which we asked ourselves how "Estimated values for height" (the topic of this thread...) should be tagged.

The real question, I think, is if it is correct to have all those est_* keys or there could be a better way to indicate the accuracy of a measure.


I think the only people who are going to see those indications of accuracy are other mappers.
In which case .. why not use a note, a comment ...human to human.
There is no need to complicate it with rigid computer organised tags.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Sergio Manzi

... because, as you correctly point out, comments are just a human-to-human thing (let's put AI aside for the moment...), while a structured information for accuracy could open the way to an automated method to "update this information only if the accuracy of this new measure is better than the old one".

On 2018-11-12 11:30, Warin wrote:
I think the only people who are going to see those indications of accuracy are other mappers.
In which case .. why not use a note, a comment ...human to human.
There is no need to complicate it with rigid computer organised tags.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

bkil
Actually, accuracy=* is used quite a few times by itself:


It is common to combine tokens in such a way in the key grammar of OSM.

When I map objects that may be worthy as a navigation aid, like a survey point or a milestone, I usually specify a large value if I've only taken measurements with an imprecise smartphone, so others with millimeter GPS can improve it later on if they will.

I only add this tag for objects that matter, ie., not on every bush or waste basket. I assume by default that everything is imprecise unless tagged with accuracy<1.

If you don't know the accuracy, (and you wouldn't prefer to estimate the accuracy of the estimate itself...), I think some kind of source tag may work. However, I can see how changeset metadata is more efficient and I usually prefer that when possible. 

Although, it would be nice if we had better tools to show such metadata while editing. For example, Josm could offer to download a given area with history as well. It could then annotate each tag in the properties window with the last modification date, source and comment. That would help finding deleted objects as well, along with attribution and history tracking for objects that went through various steps of merging or splitting.

On Mon, Nov 12, 2018 at 11:38 AM Sergio Manzi <[hidden email]> wrote:

... because, as you correctly point out, comments are just a human-to-human thing (let's put AI aside for the moment...), while a structured information for accuracy could open the way to an automated method to "update this information only if the accuracy of this new measure is better than the old one".

On 2018-11-12 11:30, Warin wrote:
I think the only people who are going to see those indications of accuracy are other mappers.
In which case .. why not use a note, a comment ...human to human.
There is no need to complicate it with rigid computer organised tags.
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

cascafico
In source dataset there is no field for accuracy. I'd go for the simplest solution, 
height=*
note="height is estimated, please improve"

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

--
cascafico.altervista.org
twitter.com/cascafico
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

Peter Elderson
Isn’t every measurement an estimation?

Mvg Peter Elderson

> Op 13 nov. 2018 om 09:46 heeft Cascafico Giovanni <[hidden email]> het volgende geschreven:
>
> In source dataset there is no field for accuracy. I'd go for the simplest solution,
> height=*
> note="height is estimated, please improve"
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Estimated values for height

OSMDoudou
In reply to this post by cascafico
In hopefully simple words, an estimate would be a measure which doesn't meet your precision need or doesn't meet your trust criteria of the measure or of the measuring person.

So, they way it was measured is factual information the mapper should share, so that the data consumer can determine for itself if it's good enough for him.

Without telling how it was measured, one cannot assess accuracy. And "site survey" wouldn't be a good explanation because it says nothing about the accuracy of the tool used nor about the qualification of the measuring person to use the tool adequately.


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12