> on the object it-self height=3 group all objet with this source, and put
on the changeset :
source=survey source:height=estimated or eyeball
Yes, but this makes it far harder for a standard mapper to do QA - they now
need to create the convoluted set of requests and filters I mentioned in
the
Le 13. 11. 18 à 23:30, Nick Bolten a écrit :
> My primary concern is in being able to distinguish estimated values that
> are "guesstimates" of different types from something where someone took
> the effort to use something more precise. Examples:
>
> (1) Jessica is walking along the street and
On 13/11/18 22:41, Peter Elderson wrote:
Isn’t every measurement an estimation?
No.
A measurement traceable to national standards will not be estimated.
That measurement should be in the form of a report, the report will contain an
uncertainty of the measurement.
The uncertainty may contain
You raise many good points!
My primary concern is in being able to distinguish estimated values that
are "guesstimates" of different types from something where someone took the
effort to use something more precise. Examples:
(1) Jessica is walking along the street and is prompted to estimate a
On Wed, 14 Nov 2018 at 06:21, OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>
> I wonder if it’s not.better to accept that *any* measure is an estimate,
> and let mappers improve the accuracy, just like the drawing of a highway
> can be a poor or a great estimate, which
... but on the other hand your estimation *can *be seen as "/the instrument
used/", so I'm in no way against using /metric/:source=estimate.
The only gotcha could happen when you have to import a measure from on official
source (/and you want to indicate it/) and... the official source has
I missed the existence of "/metric/:source".
At first sight (my /guesstimate/...) it is not much used (/46 times it is
associated to "width", 0 times with "length", and 413 times with "heigth"/),
but it is actually used with that meaning (/the most used value is
"estimated"/), and it could be
I like the ideas using height:source or height:accuracy, but want to point
out that they could imply different things.
I think we're mostly talking about situations where we're eyeballing some
measurement - like the height of a building or the width of something (e.g.
I'd really like something
What’s the fundamental difference (and thus main benefit ?) between
measure:accuracy, accuracy:measure or est_height ? They’re all telling that the
given height is an estimate within an undisclosed interval of confidence?
I wonder if it’s not.better to accept that *any* measure is an estimate,
On Tue, Nov 13, 2018 at 10:09 AM Sergio Manzi wrote:
> Yeah, agreed. And I think in our context "*estimate*" should be more
> taken as "*quesstimate*", i.e. "*a first rough approximation pending a
> more accurate estimate, or it may be an educated guess at something for
> which no better
Grunt: *g*uesstimate, not *q*uesstimate
On 2018-11-13 16:16, Sergio Manzi wrote:
>
> Sorry, typo: *g*uestimate, not *q*uestimate!!
>
> On 2018-11-13 16:07, Sergio Manzi wrote:
>>
>> Yeah, agreed. And I think in our context "/estimate/" should be more taken
>> as "/quesstimate/", i.e. "/a first
Sorry, typo: *g*uestimate, not *q*uestimate!!
On 2018-11-13 16:07, Sergio Manzi wrote:
>
> Yeah, agreed. And I think in our context "/estimate/" should be more taken as
> "/quesstimate/", i.e. "/a first rough approximation pending a more accurate
> estimate, or it may be an educated guess at
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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Actually, accuracy=* is used quite a few times by itself:
https://taginfo.openstreetmap.org/search?q=accuracy
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
... 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
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
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
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
Am So., 11. Nov. 2018 um 17:11 Uhr schrieb Andy Townsend :
> 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
Am So., 11. Nov. 2018 um 12:17 Uhr schrieb 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
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
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
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
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
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
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
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 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
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 a
écrit :
> There is
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
wrote:
> I'm going to import a small dataset of trees. Some tree heights are
> defined as
29 matches
Mail list logo
