Re: [Tagging] Estimated values for height

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

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" > ___

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

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 ad

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

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

[Tagging] Petroleum extraction

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:ma

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

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 simplif

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

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, Pau

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

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 registe

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

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

Re: [Tagging] Estimated values for height

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 i

Re: [Tagging] Petroleum extraction

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 numer

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

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 alread

Re: [Tagging] Estimated values for height

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.

Re: [Tagging] Estimated values for height

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 som

Re: [Tagging] Estimated values for height

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 ro

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

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%3Dd

Re: [Tagging] Estimated values for height

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 informat

Re: [Tagging] Estimated values for height

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, a

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

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 di

Re: [Tagging] Estimated values for height

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 pure

Re: [Tagging] Estimated values for height

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 lik

Re: [Tagging] Estimated values for height

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

Re: [Tagging] Estimated values for height

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

Re: [Tagging] Estimated values for height

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

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

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

Re: [Tagging] Estimated values for height

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 ne

Re: [Tagging] Estimated values for height

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 e

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

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=

Re: [Tagging] Estimated values for height

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

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

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 (a