Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Martin Koppenhoefer]

sent from a phone

> On 26. Jul 2018, at 21:26, François Lacombe  wrote:
> 
> I don't want to break things but only improve them, all the best


one issue with using only one unit for a tag is that they can’t always be 
transformed without rounding. E.g. maxspeed=55mph cannot be converted to kph 
without losing information 

Also, shorter notations are better readable, hence reduce the likeliness of 
errors not noted. 

On the other hand, I agree in the example of voltage it would make it easier 
for queries to use the same unit. (you still can make queries, but they are 
more complicated if you have to take units into account)


Cheers,
Martin


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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Warin]

On 27/07/18 21:11, Martin Koppenhoefer wrote:


sent from a phone


On 26. Jul 2018, at 21:26, François Lacombe  wrote:

I don't want to break things but only improve them, all the best


one issue with using only one unit for a tag is that they can’t always be 
transformed without rounding. E.g. maxspeed=55mph cannot be converted to kph 
without losing information

Also, shorter notations are better readable, hence reduce the likeliness of 
errors not noted.

On the other hand, I agree in the example of voltage it would make it easier 
for queries to use the same unit. (you still can make queries, but they are 
more complicated if you have to take units into account)




Unfortunately not everyone uses the same units... heights are in meters, feet 
.. depending on where you come from or what activity you follow.

Voltages are in volts so the same units... but multiplies are common for high 
voltages .. no one uses 33000 volts .. they all use 33 kv.
If you stipulate that all voltages have to be in kv then 115 v becomes 0.115 
kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
that is not how people talk about these things.



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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Andrew Hain]

My own preference is to have no (zero) units in the database, decimals where 
wanted (maxwidth=2.2) and unit management support in editors.

--
Andrew

From: Warin <61sundow...@gmail.com>
Sent: 27 July 2018 12:27:04
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Let's get (quite) rid of units and their multiples in 
OSM values

On 27/07/18 21:11, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 26. Jul 2018, at 21:26, François Lacombe  
>> wrote:
>>
>> I don't want to break things but only improve them, all the best
>
> one issue with using only one unit for a tag is that they can’t always be 
> transformed without rounding. E.g. maxspeed=55mph cannot be converted to kph 
> without losing information
>
> Also, shorter notations are better readable, hence reduce the likeliness of 
> errors not noted.
>
> On the other hand, I agree in the example of voltage it would make it easier 
> for queries to use the same unit. (you still can make queries, but they are 
> more complicated if you have to take units into account)
>
>

Unfortunately not everyone uses the same units... heights are in meters, feet 
.. depending on where you come from or what activity you follow.

Voltages are in volts so the same units... but multiplies are common for high 
voltages .. no one uses 33000 volts .. they all use 33 kv.
If you stipulate that all voltages have to be in kv then 115 v becomes 0.115 
kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
that is not how people talk about these things.



___
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] Let's get (quite) rid of units and their multiples in OSM values

[Andy Townsend]

On 27/07/2018 13:19, Andrew Hain wrote:

... and unit management support in editors.


... and presumably also in every data consumer that uses OSM data too?

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[marc marc]

I agree maybe with the exeption of case like maxspeed

François voltage is a good usecase to open an issue to the whised app.

Le 27. 07. 18 à 14:19, Andrew Hain a écrit :
> My own preference is to have no (zero) units in the database, decimals 
> where wanted (maxwidth=2.2) and unit management support in editors.
> 
> --
> Andrew
> 
> *From:* Warin <61sundow...@gmail.com>
> *Sent:* 27 July 2018 12:27:04
> *To:* tagging@openstreetmap.org
> *Subject:* Re: [Tagging] Let's get (quite) rid of units and their 
> multiples in OSM values
> On 27/07/18 21:11, Martin Koppenhoefer wrote:
>>
>> sent from a phone
>>
>>> On 26. Jul 2018, at 21:26, François Lacombe  
>>> wrote:
>>>
>>> I don't want to break things but only improve them, all the best
>>
>> one issue with using only one unit for a tag is that they can’t always be 
>> transformed without rounding. E.g. maxspeed=55mph cannot be converted to kph 
>> without losing information
>>
>> Also, shorter notations are better readable, hence reduce the likeliness of 
>> errors not noted.
>>
>> On the other hand, I agree in the example of voltage it would make it easier 
>> for queries to use the same unit. (you still can make queries, but they are 
>> more complicated if you have to take units into account)
>>
>>
> 
> Unfortunately not everyone uses the same units... heights are in meters, 
> feet .. depending on where you come from or what activity you follow.
> 
> Voltages are in volts so the same units... but multiplies are common for 
> high voltages .. no one uses 33000 volts .. they all use 33 kv.
> If you stipulate that all voltages have to be in kv then 115 v becomes 
> 0.115 kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
> that is not how people talk about these things.
> 
> 
> 
> ___
> 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] Let's get (quite) rid of units and their multiples in OSM values

[Richard Welty]

normalization into SI is the sort of thing that engineers and scientists
go for, and speaking as a (computer) scientist it has some appeal.

but practically it's probably not a good idea in mapping, where i think
we should be using local units in an unambiguous manner.

if i see maxspeed=40 on a road in the US w/o units, i have no idea what
i'm looking at, it could be 40mph or it could be 25mph. the mapper who
entered the data knew what s/he was looking at but i sure don't.

richard

On 7/27/18 11:20 AM, marc marc wrote:
> I agree maybe with the exeption of case like maxspeed
>
> François voltage is a good usecase to open an issue to the whised app.
>
> Le 27. 07. 18 à 14:19, Andrew Hain a écrit :
>> My own preference is to have no (zero) units in the database, decimals 
>> where wanted (maxwidth=2.2) and unit management support in editors.
>>
>> --
>> Andrew
>> 
>> *From:* Warin <61sundow...@gmail.com>
>> *Sent:* 27 July 2018 12:27:04
>> *To:* tagging@openstreetmap.org
>> *Subject:* Re: [Tagging] Let's get (quite) rid of units and their 
>> multiples in OSM values
>> On 27/07/18 21:11, Martin Koppenhoefer wrote:
>>> sent from a phone
>>>
>>>> On 26. Jul 2018, at 21:26, François Lacombe  
>>>> wrote:
>>>>
>>>> I don't want to break things but only improve them, all the best
>>> one issue with using only one unit for a tag is that they can’t always be 
>>> transformed without rounding. E.g. maxspeed=55mph cannot be converted to 
>>> kph without losing information
>>>
>>> Also, shorter notations are better readable, hence reduce the likeliness of 
>>> errors not noted.
>>>
>>> On the other hand, I agree in the example of voltage it would make it 
>>> easier for queries to use the same unit. (you still can make queries, but 
>>> they are more complicated if you have to take units into account)
>>>
>>>
>> Unfortunately not everyone uses the same units... heights are in meters, 
>> feet .. depending on where you come from or what activity you follow.
>>
>> Voltages are in volts so the same units... but multiplies are common for 
>> high voltages .. no one uses 33000 volts .. they all use 33 kv.
>> If you stipulate that all voltages have to be in kv then 115 v becomes 
>> 0.115 kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
>> that is not how people talk about these things.
>>
>>
>>
>> ___
>> 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


-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Philip Barnes]

On 27/07/2018 16:20, marc marc wrote:

I agree maybe with the exeption of case like maxspeed

And maxheight and maxwidth.

Phil (trigpoint)

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Andrew Hain]

Data consumers would convert to units they are interested in, no others.

--
Andrew

From: Andy Townsend 
Sent: 27 July 2018 14:34:41
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Let's get (quite) rid of units and their multiples in 
OSM values

On 27/07/2018 13:19, Andrew Hain wrote:
> ... and unit management support in editors.

... and presumably also in every data consumer that uses OSM data too?

___
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] Let's get (quite) rid of units and their multiples in OSM values

[marc marc]

Le 27. 07. 18 à 18:51, Richard Welty a écrit :
> but practically it's probably not a good idea in mapping, where i think
> we should be using local units in an unambiguous manner.

nothing prevent a editor nor a site to show "volt" next to the textbox 
for voltage value nor to show "km/h or mph" next to the textbox for 
maxspeed depending of the location.
it only needed to have something to tell data user if a tag have only 
one unit or if the unit varies according to location (in this case, we 
need again a schema to store default value (in this case unit) somewhere 
with a link with osm location).

Le 27. 07. 18 à 18:52, Philip Barnes a écrit :
 > On 27/07/2018 16:20, marc marc wrote:
 >> I agree maybe with the exeption of case like maxspeed
 > And maxheight and maxwidth.

I agree that it'll be easy to not include those tag, at least to start.
it's why voltage is a very good usecase to start with it :)

> 
> On 7/27/18 11:20 AM, marc marc wrote:
>> I agree maybe with the exeption of case like maxspeed
>>
>> François voltage is a good usecase to open an issue to the whised app.
>>
>> Le 27. 07. 18 à 14:19, Andrew Hain a écrit :
>>> My own preference is to have no (zero) units in the database, decimals
>>> where wanted (maxwidth=2.2) and unit management support in editors.
>>>
>>> --
>>> Andrew
>>> ------------
>>> *From:* Warin <61sundow...@gmail.com>
>>> *Sent:* 27 July 2018 12:27:04
>>> *To:* tagging@openstreetmap.org
>>> *Subject:* Re: [Tagging] Let's get (quite) rid of units and their
>>> multiples in OSM values
>>> On 27/07/18 21:11, Martin Koppenhoefer wrote:
>>>> sent from a phone
>>>>
>>>>> On 26. Jul 2018, at 21:26, François Lacombe  
>>>>> wrote:
>>>>>
>>>>> I don't want to break things but only improve them, all the best
>>>> one issue with using only one unit for a tag is that they can’t always be 
>>>> transformed without rounding. E.g. maxspeed=55mph cannot be converted to 
>>>> kph without losing information
>>>>
>>>> Also, shorter notations are better readable, hence reduce the likeliness 
>>>> of errors not noted.
>>>>
>>>> On the other hand, I agree in the example of voltage it would make it 
>>>> easier for queries to use the same unit. (you still can make queries, but 
>>>> they are more complicated if you have to take units into account)
>>>>
>>>>
>>> Unfortunately not everyone uses the same units... heights are in meters,
>>> feet .. depending on where you come from or what activity you follow.
>>>
>>> Voltages are in volts so the same units... but multiplies are common for
>>> high voltages .. no one uses 33000 volts .. they all use 33 kv.
>>> If you stipulate that all voltages have to be in kv then 115 v becomes
>>> 0.115 kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
>>> that is not how people talk about these things.
>>>
>>>
>>>
>>> ___
>>> 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
> 
> 

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Kevin Kenny]

I'm all for SI units for things like voltages and elevations. I'm
perfectly fine with tagging the elevation of Slide Mountain as 1274
metres and letting a US data consumer convert that to 4180 feet.

Regulatory things like maxspeed=* should have the unit in the tag, and
they should be in the same units that the signs are in. A sign reading
'Speed limit 25 mph' means 25 mph, and entering 40.2336 km/h loses the
information that the regulatory signs are in US customary units.

Data consumers have to deal with that stuff now - and it's not that
difficult,. I've done software that consumes OSM data, and unit
conversion was a much lesser headache than a lot of other tagging
issues.
On Fri, Jul 27, 2018 at 1:31 PM marc marc  wrote:
>
> Le 27. 07. 18 à 18:51, Richard Welty a écrit :
> > but practically it's probably not a good idea in mapping, where i think
> > we should be using local units in an unambiguous manner.
>
> nothing prevent a editor nor a site to show "volt" next to the textbox
> for voltage value nor to show "km/h or mph" next to the textbox for
> maxspeed depending of the location.
> it only needed to have something to tell data user if a tag have only
> one unit or if the unit varies according to location (in this case, we
> need again a schema to store default value (in this case unit) somewhere
> with a link with osm location).
>
> Le 27. 07. 18 à 18:52, Philip Barnes a écrit :
>  > On 27/07/2018 16:20, marc marc wrote:
>  >> I agree maybe with the exeption of case like maxspeed
>  > And maxheight and maxwidth.
>
> I agree that it'll be easy to not include those tag, at least to start.
> it's why voltage is a very good usecase to start with it :)
>
> >
> > On 7/27/18 11:20 AM, marc marc wrote:
> >> I agree maybe with the exeption of case like maxspeed
> >>
> >> François voltage is a good usecase to open an issue to the whised app.
> >>
> >> Le 27. 07. 18 à 14:19, Andrew Hain a écrit :
> >>> My own preference is to have no (zero) units in the database, decimals
> >>> where wanted (maxwidth=2.2) and unit management support in editors.
> >>>
> >>> --
> >>> Andrew
> >>> ----------------
> >>> *From:* Warin <61sundow...@gmail.com>
> >>> *Sent:* 27 July 2018 12:27:04
> >>> *To:* tagging@openstreetmap.org
> >>> *Subject:* Re: [Tagging] Let's get (quite) rid of units and their
> >>> multiples in OSM values
> >>> On 27/07/18 21:11, Martin Koppenhoefer wrote:
> >>>> sent from a phone
> >>>>
> >>>>> On 26. Jul 2018, at 21:26, François Lacombe  
> >>>>> wrote:
> >>>>>
> >>>>> I don't want to break things but only improve them, all the best
> >>>> one issue with using only one unit for a tag is that they can’t always 
> >>>> be transformed without rounding. E.g. maxspeed=55mph cannot be converted 
> >>>> to kph without losing information
> >>>>
> >>>> Also, shorter notations are better readable, hence reduce the likeliness 
> >>>> of errors not noted.
> >>>>
> >>>> On the other hand, I agree in the example of voltage it would make it 
> >>>> easier for queries to use the same unit. (you still can make queries, 
> >>>> but they are more complicated if you have to take units into account)
> >>>>
> >>>>
> >>> Unfortunately not everyone uses the same units... heights are in meters,
> >>> feet .. depending on where you come from or what activity you follow.
> >>>
> >>> Voltages are in volts so the same units... but multiplies are common for
> >>> high voltages .. no one uses 33000 volts .. they all use 33 kv.
> >>> If you stipulate that all voltages have to be in kv then 115 v becomes
> >>> 0.115 kv, 240 v becomes 0.24 kv and 415 v becomes 0.415 kv ..
> >>> that is not how people talk about these things.
> >>>
> >>>
> >>>
> >>> ___
> >>> 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
> >
> >
>
> ___
> 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] Let's get (quite) rid of units and their multiples in OSM values

[Dave Swarthout]

> Regulatory things like maxspeed=* should have the unit in the tag, and
>they should be in the same units that the signs are in. A sign reading
>'Speed limit 25 mph' means 25 mph, and entering 40.2336 km/h loses the
>information that the regulatory signs are in US customary units.

I agree with and use this method when I tag U.S. highways. Many people,
including myself, wish the U.S. wasn't still tied to the ridiculous and
anachronistic Avoirdupois system of weights and measures but in America, a
25 mph speed limit is what we see posted and what Americans see on their
speedometers.

On Fri, Jul 27, 2018 at 9:49 AM Kevin Kenny 
wrote:

> I'm all for SI units for things like voltages and elevations. I'm
> perfectly fine with tagging the elevation of Slide Mountain as 1274
> metres and letting a US data consumer convert that to 4180 feet.
>
> Regulatory things like maxspeed=* should have the unit in the tag, and
> they should be in the same units that the signs are in. A sign reading
> 'Speed limit 25 mph' means 25 mph, and entering 40.2336 km/h loses the
> information that the regulatory signs are in US customary units.
>
> Data consumers have to deal with that stuff now - and it's not that
> difficult,. I've done software that consumes OSM data, and unit
> conversion was a much lesser headache than a lot of other tagging
> issues.
> On Fri, Jul 27, 2018 at 1:31 PM marc marc 
> wrote:
> >
> > Le 27. 07. 18 à 18:51, Richard Welty a écrit :
> > > but practically it's probably not a good idea in mapping, where i think
> > > we should be using local units in an unambiguous manner.
> >
> > nothing prevent a editor nor a site to show "volt" next to the textbox
> > for voltage value nor to show "km/h or mph" next to the textbox for
> > maxspeed depending of the location.
> > it only needed to have something to tell data user if a tag have only
> > one unit or if the unit varies according to location (in this case, we
> > need again a schema to store default value (in this case unit) somewhere
> > with a link with osm location).
> >
> > Le 27. 07. 18 à 18:52, Philip Barnes a écrit :
> >  > On 27/07/2018 16:20, marc marc wrote:
> >  >> I agree maybe with the exeption of case like maxspeed
> >  > And maxheight and maxwidth.
> >
> > I agree that it'll be easy to not include those tag, at least to start.
> > it's why voltage is a very good usecase to start with it :)
> >
> > >
> > > On 7/27/18 11:20 AM, marc marc wrote:
> > >> I agree maybe with the exeption of case like maxspeed
> > >>
> > >> François voltage is a good usecase to open an issue to the whised app.
> > >>
> > >> Le 27. 07. 18 à 14:19, Andrew Hain a écrit :
> > >>> My own preference is to have no (zero) units in the database,
> decimals
> > >>> where wanted (maxwidth=2.2) and unit management support in editors.
> > >>>
> > >>> --
> > >>> Andrew
> > >>>
> 
> > >>> *From:* Warin <61sundow...@gmail.com>
> > >>> *Sent:* 27 July 2018 12:27:04
> > >>> *To:* tagging@openstreetmap.org
> > >>> *Subject:* Re: [Tagging] Let's get (quite) rid of units and their
> > >>> multiples in OSM values
> > >>> On 27/07/18 21:11, Martin Koppenhoefer wrote:
> > >>>> sent from a phone
> > >>>>
> > >>>>> On 26. Jul 2018, at 21:26, François Lacombe <
> fl.infosrese...@gmail.com> wrote:
> > >>>>>
> > >>>>> I don't want to break things but only improve them, all the best
> > >>>> one issue with using only one unit for a tag is that they can’t
> always be transformed without rounding. E.g. maxspeed=55mph cannot be
> converted to kph without losing information
> > >>>>
> > >>>> Also, shorter notations are better readable, hence reduce the
> likeliness of errors not noted.
> > >>>>
> > >>>> On the other hand, I agree in the example of voltage it would make
> it easier for queries to use the same unit. (you still can make queries,
> but they are more complicated if you have to take units into account)
> > >>>>
> > >>>>
> > >>> Unfortunately not everyone uses the same units... heights are in
> meters,
> > >>> feet .. depending on where you come from or what activity you follow.
> > &

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Paul Allen]

On Fri, Jul 27, 2018 at 6:48 PM, Kevin Kenny 
wrote:

> I'm all for SI units for things like voltages and elevations. I'm
> perfectly fine with tagging the elevation of Slide Mountain as 1274
> metres and letting a US data consumer convert that to 4180 feet.
>

I respectfully disagree.  One reason is of rounding errors in conversions,
as somebody said
earlier in the thread.  The other reason is one you imply below.

>
> Regulatory things like maxspeed=* should have the unit in the tag, and
> they should be in the same units that the signs are in. A sign reading
> 'Speed limit 25 mph' means 25 mph, and entering 40.2336 km/h loses the
> information that the regulatory signs are in US customary units.
>

+0.5

Not +1 because this reasoning applies to *everything.*

If you're navigating somewhere unfamiliar to you and GPS isn't giving you an
accurate signal, what you're interested in is what signs actually *say.*
Because
when you're in confusing territory a speed sign, or a bridge clearance, or
whatever
may be a significant clue.  Knowing that the speed limit is 40.2336 km/h
doesn't tell
you to look for a sign saying 25 mph.  You need both (so you don't break
the speed
limit), and I hope advances in rendering will eventually allow both (see
Wikimedia project
to provide multilingual mapping) to be displayable.

Actually, you only need both if you take your own car to a different
country, so your car
speedo is marked in km/h and the signs are mph.  Because if you rent a car
you're
almost certain to get one where the speedo is marked in the appropriate
unit.  Actually,
it's been many decades since I've seen speedos that were not marked in both
mph
and km/h, but it may be different in other countries.

That just leaves bridge clearances which will cause problems.  But even
people
driving in unfamiliar parts of their own country can get that wrong.  See
this youtube
channel for amusing videos about a bridge with 11' 8" clearance and people
who
don't understand their vehicle needs more clearance than that:
https://www.youtube.com/channel/UCXX0RWOIBjt4o3ziHu-6a5A

The alternative is to tag in SI units, accept rounding errors in some
countries, and
then tag US (and other country) speed limits with something like
customary_unit=mph.
Much cleaner to tag in whatever units are actually used and do conversions
on the
display side rather than the data entry side.

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Tobias Knerr]

On 26.07.2018 21:26, François Lacombe wrote:
> Then store voltage=40 is far way better but harder to be read by
> humans also.

I currently prefer explicit units in the database because they document
the mapper's intent and avoid ambiguity.

Defaults aren't always obvious. For example, people mapping pipelines
have documented millimetres as the default for diameter=*, but it seems
tree mappers haven't gotten the memo and (reasonably) assume it's
defaulting to metres like height=*, width=* or circumference=*.

When a value is actually signposted on the ground, it's most likely
preferable to use the original unit and avoid conversions. Apart from
that particular case, I can see some benefits of your suggestion – _if_
you can convince the community to reliably agree on how unit-less values
are interpreted.

> https://wiki.openstreetmap.org/wiki/Map_Features/Units doesn't help
> regarding such issues.

It helps by providing data consumers with information they need to
support both explicit and implicit units. Some have gotten around to
implementing that feature, others haven't yet – but in principle, it
seems entirely possible to support queries like [voltage>20 kV], to use
your example.

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[François Lacombe]

Well okay
Given problem is how can we query maxspeed like :
[Maxspeed>25] ?

It's not possible while units are stored with values.

Then i agree that human display is a matter of tools, not database

François

Le ven. 27 juil. 2018 à 22:21, Tobias Knerr  a écrit :

> On 26.07.2018 21:26, François Lacombe wrote:
> > Then store voltage=40 is far way better but harder to be read by
> > humans also.
>
> I currently prefer explicit units in the database because they document
> the mapper's intent and avoid ambiguity.
>
> Defaults aren't always obvious. For example, people mapping pipelines
> have documented millimetres as the default for diameter=*, but it seems
> tree mappers haven't gotten the memo and (reasonably) assume it's
> defaulting to metres like height=*, width=* or circumference=*.
>
> When a value is actually signposted on the ground, it's most likely
> preferable to use the original unit and avoid conversions. Apart from
> that particular case, I can see some benefits of your suggestion – _if_
> you can convince the community to reliably agree on how unit-less values
> are interpreted.
>
> > https://wiki.openstreetmap.org/wiki/Map_Features/Units doesn't help
> > regarding such issues.
>
> It helps by providing data consumers with information they need to
> support both explicit and implicit units. Some have gotten around to
> implementing that feature, others haven't yet – but in principle, it
> seems entirely possible to support queries like [voltage>20 kV], to use
> your example.
>
> ___
> 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] Let's get (quite) rid of units and their multiples in OSM values

[Nelson A. de Oliveira]

On Fri, Jul 27, 2018 at 5:33 PM, François Lacombe
 wrote:
> Well okay
> Given problem is how can we query maxspeed like :
> [Maxspeed>25] ?

Maybe the query tools could simply implement a function that converts
number+unit to a numeric value only?

[to_number(maxspeed) > 25]

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[marc marc]

Le 27. 07. 18 à 22:44, Nelson A. de Oliveira a écrit :
> On Fri, Jul 27, 2018 at 5:33 PM, François Lacombe
>  wrote:
>> Well okay
>> Given problem is how can we query maxspeed like :
>> [Maxspeed>25] ?
> 
> Maybe the query tools could simply implement a function that converts
> number+unit to a numeric value only?
> 
> [to_number(maxspeed) > 25]
> 

it can be done well and easily (but it must be recoded in every 
language, which is not effective) by a preprocessor for a lot of tools
exept when the tools need to keep the value as in the osm database,
for exemple overpass api

you can't convert all value to SI value with a preprocessor to store 
only SI value in the local database because you also need to beable to 
query or to show the exact value as in osm database.
the wrong way is to request the tool du duplicate all values in 2 :
the as-in-osm value and the SI value

the true way is to put only SI value in the osm database (except
for country with imperial units) without multiples and make tools aware 
of no-SI request or multiples request.
That's what we already do for street name : we put a full name in osm 
and let's Nominatim understand some common short form

So expending voltage=10kV into voltage=1 (with or without v)
is imho a good idea
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[François Lacombe]

2018-07-27 22:44 GMT+02:00 Nelson A. de Oliveira :

> On Fri, Jul 27, 2018 at 5:33 PM, François Lacombe
>  wrote:
> > Well okay
> > Given problem is how can we query maxspeed like :
> > [Maxspeed>25] ?
>
> Maybe the query tools could simply implement a function that converts
> number+unit to a numeric value only?
>
> [to_number(maxspeed) > 25]
>

I don't think ANSI SQL will add such a feature unfortunately.

Overpass and osm2pgsql but what about consumers processing the planet file?

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Eric Gillet]

I agree with François and Marc.

Le ven. 27 juil. 2018 à 13:28, Warin <61sundow...@gmail.com> a écrit :

> Unfortunately not everyone uses the same units... heights are in meters,
> feet .. depending on where you come from or what activity you follow.
>

You're right, but as OSM is an international database, standardizing data
(meaning units too) is a must. Just like phone numbers where although local
residents usually don't use ITU prefixes (+XX), phones numbers should be
entered with those prefixes to ensure valid usage for consumers.

Le ven. 27 juil. 2018 à 21:21, Paul Allen  a écrit :

> If you're navigating somewhere unfamiliar to you and GPS isn't giving you
> an
> accurate signal, what you're interested in is what signs actually *say.*
> Because
> when you're in confusing territory a speed sign, or a bridge clearance, or
> whatever
> may be a significant clue.  Knowing that the speed limit is 40.2336 km/h
> doesn't tell
> you to look for a sign saying 25 mph.
>

Most GPS/routing applications (including OSMAnd, Google maps) already
convert maxspeeds to user's prefered unit. I do not remember ever seeing a
fractional legal speed, so by rounding the value you can obtain the sign
value with good confidence.
Another thought : Even if maxspeed=* on highway=* could be in kph,
traffic_signs could still be mapped with local, explicit or implicit units.
That would solve both problem.

Le ven. 27 juil. 2018 à 22:22, Tobias Knerr  a écrit :

> I currently prefer explicit units in the database because they document
> the mapper's intent and avoid ambiguity.
>
> Defaults aren't always obvious. For example, people mapping pipelines
> have documented millimetres as the default for diameter=*, but it seems
> tree mappers haven't gotten the memo and (reasonably) assume it's
> defaulting to metres like height=*, width=* or circumference=*.
>

An unit selector can be implemented in editors quite easily. StreetComplete
already does work with different units for example.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Mark Wagner]

On Fri, 27 Jul 2018 22:33:10 +0200
François Lacombe  wrote:

> Well okay
> Given problem is how can we query maxspeed like :
> [Maxspeed>25] ?  
>

Which situation do we want to optimize for?  The rare case, or the
common case?

It's common to want to document legal restrictions such as "speed limit
25 miles per hour", "no trucks over 2.5 meters tall", or "maximum
weight 3500 kilograms".  It's rare to want to query ranges of speeds,
heights, or weights, particularly without regard to the units in use in
a given country.

We should make it easy for people to enter and interpret these legal
restrictions, and if it means query software gets a bit more
complicated, so be it.  For every person who wants to find roads
worldwide with speed limits greater than 25 km/h, there are probably
a thousand who don't want to deal with making sure the rounding is
correct when displaying US speed limits in miles per hour.

-- 
Mark

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Javier Sánchez Portero]

To avoid problems when querying, in case of explicitly add units, I would
prefer to use a separate tag like maxspeed:units=mph, for example.

Javier

El sáb., 28 jul. 2018 10:30, Mark Wagner  escribió:

> On Fri, 27 Jul 2018 22:33:10 +0200
> François Lacombe  wrote:
>
> > Well okay
> > Given problem is how can we query maxspeed like :
> > [Maxspeed>25] ?
> >
>
> Which situation do we want to optimize for?  The rare case, or the
> common case?
>
> It's common to want to document legal restrictions such as "speed limit
> 25 miles per hour", "no trucks over 2.5 meters tall", or "maximum
> weight 3500 kilograms".  It's rare to want to query ranges of speeds,
> heights, or weights, particularly without regard to the units in use in
> a given country.
>
> We should make it easy for people to enter and interpret these legal
> restrictions, and if it means query software gets a bit more
> complicated, so be it.  For every person who wants to find roads
> worldwide with speed limits greater than 25 km/h, there are probably
> a thousand who don't want to deal with making sure the rounding is
> correct when displaying US speed limits in miles per hour.
>
> --
> Mark
>
> ___
> 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] Let's get (quite) rid of units and their multiples in OSM values

[Martin Koppenhoefer]

sent from a phone

> On 27. Jul 2018, at 19:48, Kevin Kenny  wrote:
> 
> I'm all for SI units for things like voltages and elevations. I'm
> perfectly fine with tagging the elevation of Slide Mountain as 1274
> metres and letting a US data consumer convert that to 4180 feet.
> 
> Regulatory things like maxspeed=* should have the unit in the tag, and
> they should be in the same units that the signs are in. A sign reading
> 'Speed limit 25 mph' means 25 mph, and entering 40.2336 km/h loses the
> information that the regulatory signs are in US customary units.


+1. In the case of elevation data, even if someone writes in the wiki that 
using SI units is mandatory, and elevations should be with respect to the EGM96 
sea level, you should still expect there will be many mappers copying numbers 
from a sign without any conversion. And it could even make more sense to 
display the elevation in the locally common system, i.e. what is on the sign 
would also be on the (local) map. I agree this could on the other hand be seen 
as inconsistent, but I guess it is what is already happening.

cheers,
Martin 


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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Martin Koppenhoefer]

sent from a phone

> On 29. Jul 2018, at 09:57, Javier Sánchez Portero  
> wrote:
> 
> To avoid problems when querying, in case of explicitly add units, I would 
> prefer to use a separate tag like maxspeed:units=mph, for example.


spreading the information over 2 tags creates another point of possible 
failure: units and tag value getting out of sync.

Moving the unit into the key would work better in some way: height_m=3
maxspeed_mph=25
It would enable differing values in different units, but at least these would 
be evidently wrong (e.g maxspeed_kph=30 and ...mph=25 on the same object), and 
of course you shouldn’t add both anyway (unless they would both be legally 
correct)

cheers,
Martin 


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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Javier Sánchez Portero]

That sounds right but would not be clearer to use spacename instead of
underscore? Like maxspeed:mph=25
That way you have to deal with main keys instead of split them into one key
per unit.

El lun., 30 jul. 2018 0:22, Martin Koppenhoefer 
escribió:

>
>
> sent from a phone
>
> > On 29. Jul 2018, at 09:57, Javier Sánchez Portero 
> wrote:
> >
> > To avoid problems when querying, in case of explicitly add units, I
> would prefer to use a separate tag like maxspeed:units=mph, for example.
>
>
> spreading the information over 2 tags creates another point of possible
> failure: units and tag value getting out of sync.
>
> Moving the unit into the key would work better in some way: height_m=3
> maxspeed_mph=25
> It would enable differing values in different units, but at least these
> would be evidently wrong (e.g maxspeed_kph=30 and ...mph=25 on the same
> object), and of course you shouldn’t add both anyway (unless they would
> both be legally correct)
>
> cheers,
> Martin
>
>
> ___
> 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] Let's get (quite) rid of units and their multiples in OSM values

[Andrew Hain]

I disagree in the specific case of maxheight and maxwidth:

An important use of these tags is to compare the dimension of a vehicle with 
the limits. Also the format maxheight=12'11" imposes a particular cognitive 
load on subsequent mappers and data users who may not be familiar with the 
format.

--
Andrew

From: Philip Barnes 
Sent: 27 July 2018 17:52:31
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Let's get (quite) rid of units and their multiples in 
OSM values



On 27/07/2018 16:20, marc marc wrote:
> I agree maybe with the exeption of case like maxspeed
And maxheight and maxwidth.

Phil (trigpoint)

___
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] Let's get (quite) rid of units and their multiples in OSM values

[Mateusz Konieczny]

30. Lipiec 2018 01:00 od dieterdre...@gmail.com :


>  elevations should be with respect to the EGM96 sea level




Where it is written on Wiki? Nobody is really following that. 

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Jo]

There is a relatively simple solution that could satisfy everybody. (Except
maybe the people paying for the storage, but let's say tags are cheap)

For each tag that describes a measurement, add a counterpart tag with the
values converted to SI units, meter, second, km/h (or even m/s, everybody
equally out of their depth), Volt, Ah, Watt, kg.

Then it becomes trivial to compare them, and if you need them in another
unit, you can convert. It also makes it possible to validate the values.

Of course editors like JOSM and iD would help with adding those tags.

Polyglot

Op ma 30 jul. 2018 om 10:24 schreef Mateusz Konieczny <
matkoni...@tutanota.com>:

> 30. Lipiec 2018 01:00 od dieterdre...@gmail.com:
>
>  elevations should be with respect to the EGM96 sea level
>
>
> Where it is written on Wiki? Nobody is really following that.
> ___
> 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] Let's get (quite) rid of units and their multiples in OSM values

[Martin Koppenhoefer]

sent from a phone

> On 30. Jul 2018, at 10:18, Mateusz Konieczny  wrote:
> 
> Where it is written on Wiki?


ele tag definition 


> Nobody is really following that.


I did not check any numbers, but I would also expect a lot of data not 
following this definition.


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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Kevin Kenny]

On Mon, Jul 30, 2018 at 11:39 AM Martin Koppenhoefer
 wrote:
> I did not check any numbers, but I would also expect a lot of data not 
> following this definition.
[of the ele=* tag meaining EGM96]


Uhm, yeah.  I've been using NAVD88 as orthometric datum. I have the
tables loaded in my
GPS app, and it's what surveyors use locally.  But the difference
between that and EGD96
is far too small for my equipment to measure - I don't have a
survey-grade GPS, or the
patience for the integration time that using one requires.

Entering ellipsoidal height rather than orthometric elevation, though,
is Just Plain Wrong -
and I bet we have a lot of data entered that way that are off by tens of metres.

I further bet that two-thirds of the people reading this thread have
Absolutely No Idea
what we're talking about. (That isn't really a severe criticism. It's
more an indictment
of the sorry state of consumer-grade GPS that ordinary mappers would
be forced to
learn that much geodesy to get it right.)

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

Re: [Tagging] Let's get (quite) rid of units and their multiples in OSM values

[Warin]

On 31/07/18 02:33, Kevin Kenny wrote:

On Mon, Jul 30, 2018 at 11:39 AM Martin Koppenhoefer
 wrote:

I did not check any numbers, but I would also expect a lot of data not 
following this definition.

[of the ele=* tag meaining EGM96]


Uhm, yeah.  I've been using NAVD88 as orthometric datum. I have the
tables loaded in my
GPS app, and it's what surveyors use locally.  But the difference
between that and EGD96
is far too small for my equipment to measure - I don't have a
survey-grade GPS, or the
patience for the integration time that using one requires.

Entering ellipsoidal height rather than orthometric elevation, though,
is Just Plain Wrong -
and I bet we have a lot of data entered that way that are off by tens of metres.

I further bet that two-thirds of the people reading this thread have
Absolutely No Idea
what we're talking about. (That isn't really a severe criticism. It's
more an indictment
of the sorry state of consumer-grade GPS that ordinary mappers would
be forced to
learn that much geodesy to get it right.)


+1 .. who has little idea of what your talking about :)

But then I don't usually play with elevation data, so I am not involved in it.




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