Re: [Tagging] Estimated values for height

[Cascafico Giovanni]

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

Re: [Tagging] 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  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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Add some tag to identify disputed borders

[Paul Allen]

On Tue, Nov 13, 2018 at 7:07 AM Graeme Fitzpatrick 
wrote:

How about marking the disputed area (dashed lines) as a new level, say
> boundary=administrative + admin_level=15?
>

Please, not this.  From the first two sentences of the first paragraph of
the wiki:

The admin_level key describes the administrative level of an object within
a government hierarchy. A lower level means higher in the hierarchy.

Your suggestion breaks this, which is reason enough not to do it.  It means
special-casing in
editors and renderers, which complicates the code a little.  It also means
special-casing in
humans, who are notoriously bad at getting things wrong.

In programming, this sort of trick is considered a very bad thing.  In the
past it was quite common,
but these days programmers try to avoid putting special-case values into an
otherwise hierarchical
or quantitative field (some programmers might accept negative numbers as
having special meaning,
but many would not).

It would also require more effort to reverse if a dispute is resolved.
Having something like
admin_level=2 + disputed=yes can be reversed easily, but admin_level=15
requires extra
effort (not much, but some) in order to figure out what the admin_level
should change to.
Even admin_level=-2 meaning that when resolved it changes to admin_level=2
would be
better than this.

To complicate matters further, has anyone considered what to do with
condominia like
Pheasant Island ?  It's not
disputed, but it belongs to France for 6 months of the year and to
Spain for the other six months of the year.  There are other condominia
where sovereignty
is joint but continuous rather than time-shared.

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

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Paul Allen]

On Tue, Nov 13, 2018 at 2:37 AM Warin <61sundow...@gmail.com> wrote:

>
> That way each vote is on one issue only not the lot bundled together.
>

And then some people will vote against the initial proposal because it does
not adequately
address known issues and is therefore incomplete.  They would fear that as
soon as it is
approved people will start using it and resort to ad-hockery to fill in the
gaps, resulting in a
mish-mash of inconsistent tagging before the next step is approved.
Remember that this
proposal went forward because people want it and they want it now.  They
WILL fill any
gaps with ad-hoc tagging as soon as it is approved.

I'd prefer a fully-formed proposal which addresses all conceivable future
complications.  As this
one has.  I agree that a complex proposal might contain some good stuff and
some bad stuff,
but this one has been very well-thought out by an expert in the field and
then subject to all the
nit-picking this list can throw at it.

I'd vote for it because it is a thing of craftsmanship and beauty.  Well,
maybe not for that
reason exactly, but because I cannot conceive of anything better or see any
serious flaws
in it.

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

[Tagging] Petroleum extraction

[Daniel Koć]

Hi,

We are trying to make rendering for petroleum wells in OSM Carto, but it
seems to be twisted:

https://github.com/gravitystorm/openstreetmap-carto/issues/3494


There are two different, probably overlapping tags for that, and both
have some problems:

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpumping_rig

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpetroleum_well


For pumping rig it's clear that there's a rig on the ground and you can
even add what is being extracted, but it's not clear if this should be
substance=oil or content=oil.

For petroleum well it's not clear whether there is a rig or not (there
are some sealed petroleum wells with no other equipment). Tagging both
is impossible in a simple way, since both use man_made key.

My idea is to simply move all the petroleum wells with a rig into
man_made=pumping_rig + substance/content=oil.

What do you think about it?


-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



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

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Sergio Manzi]

Colin,

I subscribe to every single word of your post... bravo!

Regards,

Sergio


On 2018-11-12 22:37, Colin Smale wrote:
> At moments like this I like to invoke one of my heroes: Albert Einstein. One 
> famous saying attributed to him is: As simple as possible, but no simpler.
>
> If you simplify complex realities too much, you lose valuable detail. If it's 
> complex, it's complex. If you want to leave out a level of detail, such as 
> being able to distinguish between the different types of services provided on 
> behalf of multiple "tenant" countries in a diplomatic mission, then so be it, 
> but let's discuss whether it is desirable to leave that out, and whether the 
> resultant ambiguity is acceptable. Data modelling means constructing an 
> approximation to reality, and is all about what details to keep in and what 
> to leave out. Once it is left out, it cannot be reconstructed from the rest 
> of the data. (If it can, your data model is not properly normalised.)
>
> If OSM is being limited to being suboptimal because of politics and the 
> inability to reach consensus, I would rather the system was fixed instead of 
> condemning the whole business to eternal mediocrity.
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Sergio Manzi]

Me too. I let my "/namespacing/" modification proposal die: this is not the 
time and the place.

BTW, can you quickly explain, to a newbie like me, who has voting rights and 
what the voting process will be? Can you point me to any documents about that?

Regards,

Sergio


On 2018-11-13 12:54, Paul Allen wrote:
> ...
>
> I'd vote for it because it is a thing of craftsmanship and beauty.  Well, 
> maybe not for that
> reason exactly, but because I cannot conceive of anything better or see any 
> serious flaws
> in it.
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Paul Allen]

On Tue, Nov 13, 2018 at 2:13 PM Sergio Manzi  wrote:

> BTW, can you quickly explain, to a newbie like me, who has voting rights
> and what the voting process will be? Can you point me to any documents
> about that?
>

Voting is by editing the voting section of the proposal.  Anyone who has
registered to be able to
edit the wiki can vote.

The wiki page https://wiki.openstreetmap.org/wiki/Proposal_process#Voting
explains how the
author of the proposal can set up a vote and can be used to figure out how
to vote.  You edit
the wiki.

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

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Sergio Manzi]

Thanks!

... but I don't see a voting section in 
https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic

Is this because voting is not open yet?

Sergio


On 2018-11-13 15:26, Paul Allen wrote:
>
>
> On Tue, Nov 13, 2018 at 2:13 PM Sergio Manzi  > wrote:
>
> BTW, can you quickly explain, to a newbie like me, who has voting rights 
> and what the voting process will be? Can you point me to any documents about 
> that?
>
>
> Voting is by editing the voting section of the proposal.  Anyone who has 
> registered to be able to
> edit the wiki can vote.
>
> The wiki page https://wiki.openstreetmap.org/wiki/Proposal_process#Voting 
> explains how the
> author of the proposal can set up a vote and can be used to figure out how to 
> vote.  You edit
> the wiki.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[OSMDoudou]

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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Petroleum extraction

[Dave Swarthout]

The big oil fields in Alaska have no pumping rigs. There are hundreds of
wellheads littering the landscape but none are what I would think of as a
pumping rig. I don't really know much about the oil industry but I have
mapped a bunch of wells in Prudhoe Bay and was surprised to learn just how
numerous those wells are in a big field like Prudhoe. I'm presuming that
the oil in Prudhoe is under enough pressure to push it to the surface,
unlike in Texas or Pennsylvania where the pumping rigs that lift the oil to
the surface, shown in the first reference, are in common use.

Also, FYI, the tag used for the Trans-Alaska Pipeline to indicate what is
being carried is substance=oil. I chose that over content=oil because it
seemed to me that content was more commonly applied to tanks. There is no
clear guideline for choosing one over the other AFAIK.

Download and take a look at this with JOSM and DigitalGlobe-Premium imagery
if you're interested. Most of the BP waypoints are in the Prudhoe Bay area.
(See Bp Exploration (Alaska) Inc1004, for example). I'm not sure now where
I obtained it or how current the data is but it's interesting nonetheless.
It contains coordinates for all the oil wells in Alaska.

https://www.dropbox.com/s/shohs21a7us3pvc/All%20Alaska%20Oil%20Well%20WPs.gpx?dl=0

Cheers,

Dave

On Tue, Nov 13, 2018 at 9:00 PM Daniel Koć  wrote:

> Hi,
>
> We are trying to make rendering for petroleum wells in OSM Carto, but it
> seems to be twisted:
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/3494
>
>
> There are two different, probably overlapping tags for that, and both
> have some problems:
>
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpumping_rig
>
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpetroleum_well
>
>
> For pumping rig it's clear that there's a rig on the ground and you can
> even add what is being extracted, but it's not clear if this should be
> substance=oil or content=oil.
>
> For petroleum well it's not clear whether there is a rig or not (there
> are some sealed petroleum wells with no other equipment). Tagging both
> is impossible in a simple way, since both use man_made key.
>
> My idea is to simply move all the petroleum wells with a rig into
> man_made=pumping_rig + substance/content=oil.
>
> What do you think about it?
>
>
> --
> "Excuse me, I have some growing up to do" [P. Gabriel]
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Paul Allen]

On Tue, Nov 13, 2018 at 2:42 PM Sergio Manzi  wrote:

> ... but I don't see a voting section in
> https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic
>
> Is this because voting is not open yet?
>

Correct.  Once things have settled down enough on the list (I think we're
already there) then
it will be opened for voting and that fact will be announced here.

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

Re: [Tagging] Estimated values for height

[Sergio Manzi]

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 
information will become available/" [1].

Now... how do we tag this... "/thing/"?  :-)

My personal idea is that it should be:

*either*

/measure/:accuracy=estimate (e.g.: height=10 + "height:accuracy=estimate")

*or*

accuracy:/measure/=estimate (e.g.: height=10 + "accuracy:height=estimate")

*and*

get rid of all the est_* tags (e.g.: est_height=10)


Cheers!

Sergio


[1] https://en.wikipedia.org/wiki/Guesstimate

On 2018-11-13 15:47, OSMDoudou wrote:
> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Sergio Manzi]

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 something for which no better 
> information will become available/" [1].
>
> Now... how do we tag this... "/thing/"?  :-)
>
> My personal idea is that it should be:
>
> *either*
>
> /measure/:accuracy=estimate (e.g.: height=10 + "height:accuracy=estimate")
>
> *or*
>
> accuracy:/measure/=estimate (e.g.: height=10 + "accuracy:height=estimate")
>
> *and*
>
> get rid of all the est_* tags (e.g.: est_height=10)
>
>
> Cheers!
>
> Sergio
>
>
> [1] https://en.wikipedia.org/wiki/Guesstimate
>
> On 2018-11-13 15:47, OSMDoudou wrote:
>> 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
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Sergio Manzi]

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 rough approximation pending a more 
>> accurate estimate, or it may be an educated guess at something for which no 
>> better information will become available/" [1].
>>
>> Now... how do we tag this... "/thing/"?  :-)
>>
>> My personal idea is that it should be:
>>
>> *either*
>>
>> /measure/:accuracy=estimate (e.g.: height=10 + 
>> "height:accuracy=estimate")
>>
>> *or*
>>
>> accuracy:/measure/=estimate (e.g.: height=10 + 
>> "accuracy:height=estimate")
>>
>> *and*
>>
>> get rid of all the est_* tags (e.g.: est_height=10)
>>
>>
>> Cheers!
>>
>> Sergio
>>
>>
>> [1] https://en.wikipedia.org/wiki/Guesstimate
>>
>> On 2018-11-13 15:47, OSMDoudou wrote:
>>> 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
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

[Allan Mustard]

Voting is not yet open.  Warin asked that the comment period be extended
for another week, so I am acceding to his request. 

apm-wa

On 11/13/2018 7:41 PM, Sergio Manzi wrote:
>
> Thanks!
>
> ... but I don't see a voting section in
> https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic
>
> Is this because voting is not open yet?
>
> Sergio
>
>
> On 2018-11-13 15:26, Paul Allen wrote:
>>
>>
>> On Tue, Nov 13, 2018 at 2:13 PM Sergio Manzi > > wrote:
>>
>> BTW, can you quickly explain, to a newbie like me, who has voting
>> rights and what the voting process will be? Can you point me to
>> any documents about that?
>>
>>
>> Voting is by editing the voting section of the proposal.В  Anyone who
>> has registered to be able to
>> edit the wiki can vote.
>>
>> The wiki page
>> https://wiki.openstreetmap.org/wiki/Proposal_process#Voting explains
>> how the
>> author of the proposal can set up a vote and can be used to figure
>> out how to vote.В  You edit
>> the wiki.
>>
>> -- 
>> Paul
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Kevin Kenny]

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 information will become available*" [1].
>
> Now... how do we tag this... "*thing*"?  :-)
>
> My personal idea is that it should be:
>
> *either*
>
> *measure*:accuracy=estimate (e.g.: height=10 + "height:accuracy=estimate")
>
> *or*
>
> accuracy:*measure*=estimate (e.g.: height=10 + "accuracy:height=estimate")
>
> *and*
>
> get rid of all the est_* tags (e.g.: est_height=10)
>
>
 I'd mostly agree. When this gets wikified, let's make it clear, though,
that the ruleis "map what you know" rather than "don't map until you have
all the detail." (Too many discussions here come up with schemes where
mappers have to do additional research beyond what they can see in the
field before they can map in a conformant way. We don't want that.)

Now, as to the height of a tree. I've been tempted to map a few locally
spectacular examples, particularly of _Tsuga canadensis_ (and decided to
refrain: https://8thlnt.wordpress.com/). I had been thinking in terms of
just putting in the number of metres - but if I were to map such a thing,
ought I to distinguish:

- step back and simply visually estimate how many copies of my six-foot
hiking partner it would take to make the height of the tree.
- pace back a known distance (with the usual inaccuracy of pacing off a
distance) and use a clinometer to measure the angle subtended by the tree.
- frame the tree with stadia marks in a transit and tape off the distance
to the tree
- (I've never done this!) Climb the tree and drop a weighted tape.

The accuracy of these techniques varies by 4-5 orders of magnitude. The
simple visual method is probably going to have a standard error of a few
metres on a big tree (because I'm reasonably skilled at such things), which
can be reduced to tens of cm with the clinometer, a few cm with a transit
and tape, and sub-cm using direct measurement with a tape.  With the
specific example of a tree, nobody cares about a few cm, because trees
flex, and grow, and measurements aren't going to be repeatable to that
level (With a tower, it might become significant.)

At that point, for a tree, the only significant difference becomes "are
measurement errors of the same order of magnitude as the natural variation
in the measured quantity?" With a visual estimate, the answer is most
likely "no", with a clinometer and pace count, it becomes "yes," and
everything more sophisticated is mostly "wasted precision". So for a tree,
"measured" and "estimated" really are the only two categories that matter.
(And perhaps the date of the measurement. Trees grow, and the big ones all
eventually take storm damage and die back.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[OSMDoudou]

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, and 
let mappers improve the accuracy, just like the drawing of a highway can be a 
poor or a great estimate, which improves over time as imagery or traces permit 
improvement.

Even if the imagery is of great precision, it’s not a guarantee of.accuracy, as 
the mapper might be in a hurry or might not particularly care for accuracy, and 
leave to its successors to improve it.

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

Re: [Tagging] Add some tag to identify disputed borders

[Andy Townsend]

On 12/11/2018 13:21, Noémie Lehuby wrote:


Should we consider the disputed=yes tag on boundary ways as a /de 
facto/ standard and uniformize a few borders ?




Can you give examples of where you'd use it?  There are many, many 
examples of disputed borders in OSM and they have been mapped in 
different ways.  Each dispute is different - sometimes theren't no 
dispute about where the border is, just about the status.  Sometimes 
there are oddities (like Bir Tawil) where there are both different 
overlapping claims and completely unclaimed territory.


You gave a couple of examples of "different ways of mapping" in OSM in 
an earlier post, saying that some examples in OSM don't match 
https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf 
.  You also gave a couple of examples where there are overlapping 
borders in OSM.  I can think of a couple of places (Somalia / Somaliland 
is one example, various maritime disputes are others) where this may 
actually be the best way of mapping reality.  I'm not convinced a simple 
"disputed=yes" tag would help much.



Should we create a proposal about this tag ?



Without a bit more discussion about what the problem that you're trying 
to solve here actually is I'm not convinced that that will help



The borders data do not fit the doc...



Just to be clear, which documentation are you actually talking about?  
There are lots of bits and pieces in the OSM wiki, and lots of them 
contradict one another.


...and the statement from the Foundation and are not really usable 
right now...


Can you give an example of a border that you can't apply the examples in 
DisputedTerritoriesInformation.pdf to?  What problem are you actually 
trying to solve?  are you:


 * Trying to find a graphical representation showing that "there is a
   dispute here"?
 * Trying to parcel up the world into best-fit single territories (to
   avoid double counting) for non-graphical processing?
 * Trying to display actual territorial control?
 * Trying to show what type of dispute exists somewhere?


All of these are somewhat different problems...  I'm not saying that 
there isn't a problem to be solved here (in fact there are many 
different ones).


Best Regards,

Andy


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

Re: [Tagging] Estimated values for height

[Sergio Manzi]

Hello!

On 2018-11-13 21:19, OSMDoudou wrote:
> 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?

The difference is purely grammatical (/in the context of 
"programming/data-definition linguistic"/) and only one of the two should be 
adopted. Personally I lean towards the first form (/measure/:accuracy=*)

> 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 improves over time as imagery or traces 
> permit improvement.

About this, please read my previous post about "/guesstimating/".

It is anyway obvious that mappers have, in the past, felt the need to have a 
way to indicate measures only roughly taken. They did it by introducing the 
various est_* tags (e.g. see: [1] and [2]) and have been instructed to do that 
in the wiki (e.g.: see "Estimated values" in [3]).

> Even if the imagery is of great precision, it’s not a guarantee of.accuracy, 
> as the mapper might be in a hurry or might not particularly care for 
> accuracy, and leave to its successors to improve it.

This is by far beyond the scope of the current discussion/proposal and, I 
think, strongly related to Murphy's law [4].

Cheers!

Sergio


[1] https://taginfo.openstreetmap.org/keys/est_width
[2] https://taginfo.openstreetmap.org/keys/est_height
[3] https://wiki.openstreetmap.org/wiki/Key:width
[4] https://en.wikipedia.org/wiki/Murphy's_law



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Nick Bolten]

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 like width=3 and width:source=eyeballed for a
sidewalk). For this, I'm using height:source because, to me, 'accuracy' is
about knowing the error range, which is something we probably can't
reasonably get from users. I have no idea what my personal accuracy would
be - maybe I'm off by 1 meter and you're off by 0.5, but I wouldn't know
off-hand. But I do know what 'eyeballing' it means (or some similar common
speech term).

Measurement accuracy seems like a tag to use when you have a real accuracy
estimate to write down, like when using surveyor's tools and maybe even
multiple measurements from which to derive statistics, and would hopefully
have some real mathematical meaning, like a += a 95% confidence interval
according to company Z in the same units as the measurement.

Finally, I really like using metric:source for QA purposes, as it's much
easier to look up (en masse) tags associated with nodes/ways/relations than
it is to look up changeset info. Let's take an example where I want to find
all 'eyeballed' building heights, because I have a great new surveying tool
to get more accurate numbers. If the source info for the width is only in
changesets, I need to: (1) retrieve all buildings in the AOI, (2) Request
the full changeset histories from OSM for each one, (3) Filter to the most
recent changeset that changed the height value, (4) check its source tag,
cross my fingers that they knew the right values to add. In contrast, if
one used width:source, all I'd need to do is run a single OverPass Turbo
query (one API call) or download buildings and check their tags. Both of
these options are mostly data-equivalent (assuming mappers remember to use
the right source=* tag on changsets), but the changeset-based one restricts
who can QA the data to programmers. The changeset-based one would also be
amenable to on-the-ground tasking apps like StreetComplete.

tl;dr: I really like metric:source=*.

Best,

Nick

On Tue, Nov 13, 2018 at 8:37 AM Kevin Kenny  wrote:

> 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 information will become available*" [1].
>>
>> Now... how do we tag this... "*thing*"?  :-)
>>
>> My personal idea is that it should be:
>>
>> *either*
>>
>> *measure*:accuracy=estimate (e.g.: height=10 +
>> "height:accuracy=estimate")
>>
>> *or*
>>
>> accuracy:*measure*=estimate (e.g.: height=10 +
>> "accuracy:height=estimate")
>>
>> *and*
>>
>> get rid of all the est_* tags (e.g.: est_height=10)
>>
>>
>  I'd mostly agree. When this gets wikified, let's make it clear, though,
> that the ruleis "map what you know" rather than "don't map until you have
> all the detail." (Too many discussions here come up with schemes where
> mappers have to do additional research beyond what they can see in the
> field before they can map in a conformant way. We don't want that.)
>
> Now, as to the height of a tree. I've been tempted to map a few locally
> spectacular examples, particularly of _Tsuga canadensis_ (and decided to
> refrain: https://8thlnt.wordpress.com/). I had been thinking in terms of
> just putting in the number of metres - but if I were to map such a thing,
> ought I to distinguish:
>
> - step back and simply visually estimate how many copies of my six-foot
> hiking partner it would take to make the height of the tree.
> - pace back a known distance (with the usual inaccuracy of pacing off a
> distance) and use a clinometer to measure the angle subtended by the tree.
> - frame the tree with stadia marks in a transit and tape off the distance
> to the tree
> - (I've never done this!) Climb the tree and drop a weighted tape.
>
> The accuracy of these techniques varies by 4-5 orders of magnitude. The
> simple visual method is probably going to have a standard error of a few
> metres on a big tree (because I'm reasonably skilled at such things), which
> can be reduced to tens of cm with the clinometer, a few cm with a transit
> and tape, and sub-cm using direct measurement with a tape.  With the
> specific example of a tree, nobody cares about a few cm, because trees
> flex, and grow, and measurements aren't going to be repeatable to that
> level (With a tower, it might become significant.)
>
> At that point, for a tree, the only significant difference becomes "are
> measurement errors of the same order of magnitude as the natural variation
> in the measured quantity?" With a visual estimate, the answer is most
> likely "no", with a clinometer and pace count, it becomes "ye

Re: [Tagging] Estimated values for height

[Sergio Manzi]

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 a viable solution.

On the other hand I think that "source" is not the first thing (/word/) you 
think of (/I didn't.../) when you think of something to indicate the accuracy 
(/or lack thereof.../) of a measurement.

Even more, if you happen to know the accuracy of a measurement (/e.g: having 
taken into account the precision/bias of your instrument, mediated on "n" 
measurements and computed the standard deviation/), with metric:accuracy=* you 
can indicate its actual accuracy. If you "/eyeballed/" or, as we say in Italy, 
"/measured by spans/", you could instead indicate metric:accuracy=estimated.

"metric:source", I think, should be more used to indicate the instrument used 
(e.g. length:source= Bosch GLM 50 C) or the official source of a measurement 
(e.g.: height:source=ESA).

Cheers!


On 2018-11-13 21:58, Nick Bolten wrote:
> I like the ideas using height:source or height:accuracy, but want to point 
> out that they could imply different things.
>
> ...
>
> tl;dr: I really like metric:source=*.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Sergio Manzi]

... 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 stated 
that the measurement is an estimation. It can happen. It's actually happening...


On 2018-11-13 22:31, Sergio Manzi wrote:
>
> 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 a viable solution.
>
> On the other hand I think that "source" is not the first thing (/word/) you 
> think of (/I didn't.../) when you think of something to indicate the accuracy 
> (/or lack thereof.../) of a measurement.
>
> Even more, if you happen to know the accuracy of a measurement (/e.g: having 
> taken into account the precision/bias of your instrument, mediated on "n" 
> measurements and computed the standard deviation/), with metric:accuracy=* 
> you can indicate its actual accuracy. If you "/eyeballed/" or, as we say in 
> Italy, "/measured by spans/", you could instead indicate 
> metric:accuracy=estimated.
>
> "metric:source", I think, should be more used to indicate the instrument used 
> (e.g. length:source= Bosch GLM 50 C) or the official source of a measurement 
> (e.g.: height:source=ESA).
>
> Cheers!
>
>
> On 2018-11-13 21:58, Nick Bolten wrote:
>> I like the ideas using height:source or height:accuracy, but want to point 
>> out that they could imply different things.
>>
>> ...
>>
>> tl;dr: I really like metric:source=*.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Graeme Fitzpatrick]

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 improves over time as imagery or
> traces permit improvement.
>
> Even if the imagery is of great precision, it’s not a guarantee
> of.accuracy, as the mapper might be in a hurry or might not particularly
> care for accuracy, and leave to its successors to improve it.


To a certain extent, isn't the height figure that's been entered going to
show it's perceived level of accuracy?

eg this tree has been entered with a height of 20m, that one over there has
been entered as 32.5m. To me at least, that would indicate that 20m is a
(calculated?) guess, while 32.5m was a (relatively?) precise measurement.

&, do we really need to worry about millimetric precision? As has been
stated many times, trees are constantly changing heights; buildings
(especially skyscrapers) often have a published height, but does that
include the TV antenna on the roof?; there is even on-going disagreement
over the height of Mt Everest
https://www.nytimes.com/2018/02/03/world/asia/mount-everest-how-tall-nepal.html
 !

So we, as a bunch of enthusiastic, amateur mappers, are going to be pushing
things uphill trying to be "exact"! :-)

Thanks

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

Re: [Tagging] Add some tag to identify disputed borders

[Graeme Fitzpatrick]

On Tue, 13 Nov 2018 at 21:46, Paul Allen  wrote:

>
> Please, not this.  From the first two sentences of the first paragraph of
> the wiki:
>
> The admin_level key describes the administrative level of an object within
> a government hierarchy. A lower level means higher in the hierarchy.
>
> Your suggestion breaks this, which is reason enough not to do it.
>
> Even admin_level=-2 meaning that when resolved it changes to admin_level=2
> would be
> better than this.
>

I had originally though about calling it 2.0 or 2.5, but thought that may
create issues!

So, would aminn_level=2.5 work?

Thanks

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

Re: [Tagging] Estimated values for height

[Nick Bolten]

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
nearby building's height in meters. They eyeball it and says it's about 3
meters wide and we record it. What's the best way to make a note that this
was acquired through visual inspection so that it can be 'flagged' in later
efforts for measurement with a ruler or laser or offset satellite imagery,
etc?

(2) Bartholomew is armchair mapping an area they are personally familiar
with and wants to estimate the width using JOSM's built-in distance
calculation tool. The tool tells them that it is 3.465839124 meters wide,
and they write that down in the tag. Of course, their error range probably
only justifies writing down "3.7 meters" at best, but we can't ask Bart to
know that for sure. How do we know that Bart's width estimate is only from
aerial imagery + a tool, and temper expectations?

(3) Katie is high tech and uses fancy laser and computer vision to get
centimeter-precision readings. How does she know which places are in need
of more accurate measurements, and how do we know her measurements should
be given the appropriating weighting vs. guessed numbers? i.e., how do we
know which height/width/etc values need accuracy improvements?

On Tue, Nov 13, 2018 at 2:18 PM Graeme Fitzpatrick 
wrote:

>
>
> 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 improves over time as imagery or
>> traces permit improvement.
>>
>> Even if the imagery is of great precision, it’s not a guarantee
>> of.accuracy, as the mapper might be in a hurry or might not particularly
>> care for accuracy, and leave to its successors to improve it.
>
>
> To a certain extent, isn't the height figure that's been entered going to
> show it's perceived level of accuracy?
>
> eg this tree has been entered with a height of 20m, that one over there
> has been entered as 32.5m. To me at least, that would indicate that 20m is
> a (calculated?) guess, while 32.5m was a (relatively?) precise measurement.
>
> &, do we really need to worry about millimetric precision? As has been
> stated many times, trees are constantly changing heights; buildings
> (especially skyscrapers) often have a published height, but does that
> include the TV antenna on the roof?; there is even on-going disagreement
> over the height of Mt Everest
> https://www.nytimes.com/2018/02/03/world/asia/mount-everest-how-tall-nepal.html
>  !
>
> So we, as a bunch of enthusiastic, amateur mappers, are going to be
> pushing things uphill trying to be "exact"! :-)
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Estimated values for height

[Warin]

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 estimates, but the measured value would have no 
estimates.



Mvg Peter Elderson


Op 13 nov. 2018 om 09:46 heeft Cascafico Giovanni  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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




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

Re: [Tagging] Add some tag to identify disputed borders

[Paul Allen]

On Tue, Nov 13, 2018 at 10:24 PM Graeme Fitzpatrick 
wrote:

>
> I had originally though about calling it 2.0 or 2.5, but thought that may
> create issues!
>
> So, would aminn_level=2.5 work?
>

Depends if the database schema holds it as an integer or not.  That problem
also applies to
admin_level=-2 depending on whether the schema uses signed or insigned
integers for it.
Or it may be held as a string, in which case you could have
admin_level=2.717828 to deal with
disputes over the bridges in Königsberg.  And admin_level=3.14169265358979
for disputes
over pie.

But look at what you're trying to achieve with special values meaning
disputed.  So 2.5 (or -2) is the
same as 2 but disputed, 3.5 (or -3) is the same as 3 but disputed.  It's
cleaner for code in the
renderer and for code in editors (and wetware in humans) to just have
admin_level:disputed=yes (or some such) rather than give special meanings
to special values
of a number.

The days are long gone (thankfully) when programmers had to resort to
trickery like this to
squeeze, for example, a complete typesetting system into 64K of RAM.  These
days they go for
comprehensibility and maintainability over saving a few bytes here and
there.

And that's assuming a disputed flag doesn't cause more problems than it
solves: "No, that border
isn't disputed, we're absolutely certain it's right." says one of the
countries involved.  So now we
need a flag pointing out that one country disputes that it's a disputed
border...

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

Re: [Tagging] Estimated values for height

[marc marc]

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 is prompted to estimate a 
> nearby building's height in meters. They eyeball it and says it's about 
> 3 meters wide and we record it. What's the best way to make a note that 
> this was acquired through visual inspection so that it can be 'flagged' 
> in later efforts for measurement with a ruler or laser or offset 
> satellite imagery, etc?

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

> (2) Bartholomew is armchair mapping an area they are personally familiar 
> with and wants to estimate the width using JOSM's built-in distance 
> calculation tool. The tool tells them that it is 3.465839124 meters 
> wide, and they write that down in the tag. Of course, their error range 
> probably only justifies writing down "3.7 meters" at best, but we can't 
> ask Bart to know that for sure. How do we know that Bart's width 
> estimate is only from aerial imagery + a tool, and temper expectations?

let's assume that Bart is naive enough to believe that he has such accuracy
On the object it-self height=3.465839124
group all objet with this source, and put on the changeset : 
source=imagery imagery_used=the_name_of_this_aerial_imagery
but Bart being an osm contributor, we can hope he doesn't be so stupid 
and so he can round his own measure.
one day editors may be more advanced and will automatically
add a changeset tag like imagery_used:resolution=10cm/pixel
one day also one can expect that editors + evolved automatically shows 
next to each tag the changeset and the source of the changes and who 
last modified it

> (3) Katie is high tech and uses fancy laser and computer vision to get 
> centimeter-precision readings. How does she know which places are in 
> need of more accurate measurements, and how do we know her measurements 
> should be given the appropriating weighting vs. guessed numbers? i.e., 
> how do we know which height/width/etc values need accuracy improvements?

it's currently impossible given the lack of quality tags on the 
changeset (we still see too often changeset without even a source tag). 
but if the contributors added them, we could easily analyze them, a bit 
like geocropping to determine the poi that probably need to be confirmed.
but if tags are missing for this analysis, please don't try to solve 
this by encouraging source tags on objects that are in no way the 
guarantor of the current source of the object. Neither do you invent
a new tag to describe exactly the same thing as what exists like 
source:=thesource

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

Re: [Tagging] Add some tag to identify disputed borders

[Graeme Fitzpatrick]

On Wed, 14 Nov 2018 at 08:46, Paul Allen  wrote:

>
>
> But look at what you're trying to achieve with special values meaning
> disputed.  So 2.5 (or -2) is the
> same as 2 but disputed, 3.5 (or -3) is the same as 3 but disputed.  It's
> cleaner for code in the
> renderer and for code in editors (and wetware in humans) to just have
> admin_level:disputed=yes (or some such) rather than give special meanings
> to special values
> of a number.
>

Fair enough thanks Paul. I won't even pretend to know anything about
programming, coding & so on, so I certainly won't argue with you!

I'd just had a thought about Marc's question earlier ^ as to "how" to tag
it & thought that may have worked?

And that's assuming a disputed flag doesn't cause more problems than it
> solves: "No, that border
> isn't disputed, we're absolutely certain it's right." says one of the
> countries involved.  So now we
> need a flag pointing out that one country disputes that it's a disputed
> border...
>

You're probably quite right there as well :-(

Thanks

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