Re: [OSM-talk] Units convention (Was: Mapping canals)

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Trautmann wrote:
|> There is really no point using a thousands separator in figures which are
|> supposed to be machine-readable.

And there is every point not doing so.

| The storage format should be machine-readable. That's why ft and mph
| would be converted to metric numbers.

I've just realised that I haven't made my position clear - I think that
if it is something we have measured, it should be in metric units. If it
is a rule we have recorded, like a legal limit, then it should be kept
in the units as supplied, because 50km/h is not the same as 30mph.

In the case of canal heights and widths, I'm not sure what are rules
from the canal authorities, and should therefore be kept in the units in
which they originate, and what are things that Richard and Co are
estimating or measuring with their GPSs and other tools.

Robert (Jamie) Munro

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmgX1z+aYVHdncI0RAqyvAKCw1YXSim+pnoe/4k9QfHxoIEF9MACeJ+FU
kO23WTK4vWNoeZLVvOEV2Ts=
=IGCZ
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Units convention (Was: Mapping canals)

[bvh]

On Thu, Jan 24, 2008 at 05:18:21PM +0100, Martin Trautmann wrote:
> US: 1,000.00 m = 1 km
> DE: 1.000,00 m = 1 km
> 1 000.00 m = 1 km ... my recommendation

That's locale specific. Just put it in the form that's easiest for
a computer (ie without seperator) and let renderers/editors render
it as desired by the user. 

cu bart

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Units convention (Was: Mapping canals)

[Greg]

I hope I'm not missing the point here but surely the maps should use a unit 
convention for each type of measure. Say metric for distance (be it from 
place to place or contour heights or sea depth) and then the user can choose 
to render it as they prefer?

Without intimate knowledge of this project and as a new visitor, I guess I had 
some preconceptions about it. I thought in these days of XML and model-view 
separation, the map would be merely a tag hierarchy for a geographical 
taxonomy and just describe the positioning of things in a spherical 
coordinate space and some meta info about each element (name, classification, 
type, description, Dublin Core data* )? The rendering or view of that space 
should be a completely separate process. If that's true, then the distances 
and all other measures will be expressed inside the notation in a 
self-consistent way (e.g. metric...)  and the user can choose to render them 
in whichever way they require at the time: colour intensity, miles, multiples 
of the distance between their ears, whetever they like. Perhaps the default 
for an application rendering the map should be to convert the units according 
to the locale settings of the host operating system?

The same principle surely would also apply to other aspects of the rendering, 
such as the icon set for road signs or the fill pattern for orchards or even 
the projection type (if any) used**. That way, the map could be rendered via 
some XSLT as a graph or filtered down to an element set of particular 
interest. Perhaps, the user prefers to store and manipulate vector on the 
server, and convert it on the fly  to their own style of bitmap on the 
client? Or use VRML instead of SVG or SVG instead of Flash or Flash instead 
of JPG. etc...

Another advantage would be the ability to search a graphical space by not just 
the pre-canned names but all the available metadata or its derived data.

I have the feeling that I'm about to kick off a storm of protest that 
everything I've described is already in place but just in case it's not, I'm 
going to post this anyway

I look forward to an interesting chat. Flame away, I'm feeling toasty 
already ;o)

Cheers,

Greg 

*http://en.wikipedia.org/wiki/Dublin_Core
**http://en.wikipedia.org/wiki/Map_projection
-- 
This e-mail address is the one I use for
companies who incorrectly presume promoting products
to me is a right. Any e-mails sent to this address are
aggressively spam checked and most are discarded, unread.

If you're one of those companies you'll find customers
are more responsive if they've actively opted in to
receive specific information - rather than passively
opted in or, worse, just spammed.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Units convention (Was: Mapping canals)

[David James]

On Thu, January 24, 2008 4:18 pm, Martin Trautmann wrote:
>> The complete list of allowed units for speed is:
>>
>
> Where did you find this? Is it
> 
>
>
>> * kph (assumed if there is none specified)
>> * mph
>>
>
> please do NOT call it kph. The derived SI units are km/h
>
>> That's it. The fact is that the UK and USA use mph, and they
>> are 2 of the most important countries in OSM.
>
> Does UK still use mph?

Since no-one seems to have yet answered this direct question ... Yes, the
UK does still use mph.

-- 
David James



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Units convention (Was: Mapping canals)

[Martin Trautmann]

> There is really no point using a thousands separator in figures which are 
> supposed to be machine-readable. 


The storage format should be machine-readable. That's why ft and mph would be 
converted to metric numbers.

User's output should be best for reading - and input could be flexible e.g. for 
copy/paste to accept spaces within input fields, but delete them for storage.
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Units convention (Was: Mapping canals)

[Martin Trautmann]

> Indeed, the exact conversion is to multiply/divide by 0.3058 
> which produces 2.1336m or 2.134m if you round to the nearest 
> millimetre.
> 
> 7ft or 7' is so much simpler in this instance :-)

1 ft is EXACTLY 0.3048 m,
7 ft are EXACTLY 2.1336 m (7*12*25.4/1000)

I guess your choices are:
* 7 ft   (four digits, no direct calculations possible due to "text")
* 2.1336 (six digits, no unit "m" required, exact match)
* 2.14   (4 digits, rough conversion, may use exact back conversion by matching 
rounding)

Since there are many other definitions of foot, apart of this international 
foot (ranging from 0.25 m up to 0.3... m), I do not see a problem 
by rounding to two decimal digits.

AFAIK any numbers with units "ft" and "mph" will be converted to metric units.
-- 
GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS.
Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Units convention (Was: Mapping canals)

[Martin Trautmann]

> A few days ago I was blissfully ignorant of the fact that 
> there were any unit suffixes at all in these fields, having 
> assumed that all mappers were storing metric units as implied 
> by Mapfeatures. We now have a messy set of proposals from 
> which we need to find the best outcome.
> 
> So _please_ don't let's end up also introducing thousands 
> separators where we don't need them.

The database should not use any thousands separators at all. But for 
international purposes the output may be formatted to better numbers for 
reading -  such as "population=12 345 678". 

I wanted to point out especially the decimal units where you MUST NOT use 
decimal commas, even if they are the default within your country.
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Units convention (Was: Mapping canals)

[Abigail Brady]

On Jan 24, 2008 4:18 PM, Martin Trautmann <[EMAIL PROTECTED]> wrote:

> US: 1,000.00 m = 1 km
> DE: 1.000,00 m = 1 km
>1 000.00 m = 1 km ... my recommendation
>

There is really no point using a thousands separator in figures which are
supposed to be machine-readable.

-- 
Abi
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Units convention (Was: Mapping canals)

[Dermot McNally]

On 24/01/2008, Martin Trautmann <[EMAIL PROTECTED]> wrote:

> m would be the default - and I assume it's a decimal POINT here (since many 
> countries do use decimal commas). Since some distances might be above 1 000 
> metres, I do recommend a space as thousands separator:

A few days ago I was blissfully ignorant of the fact that there were
any unit suffixes at all in these fields, having assumed that all
mappers were storing metric units as implied by Mapfeatures. We now
have a messy set of proposals from which we need to find the best
outcome.

So _please_ don't let's end up also introducing thousands separators
where we don't need them.

Dermot

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Units convention (Was: Mapping canals)

[Richard Fairhurst]

Martin Trautmann wrote:

> Speaking about canals - do they use nautical speeds? Is the proper   
> unit km/h, mph or knots, are these land or sea miles? Distances here  
>  are given in km, using km plates besides the canal.

In the UK they use mph and miles.* Sometimes on river navigations  
there's maxspeed_upstream and maxspeed_downstream, too. :)

cheers
Richard

* anoraks may pick me up on this but that's _way_ too involved to get  
into here


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Units convention (Was: Mapping canals)

[Martin Trautmann]

> The complete list of allowed units for speed is:

Where did you find this? Is it


> * kph (assumed if there is none specified)
> * mph

please do NOT call it kph. The derived SI units are km/h

> That's it. The fact is that the UK and USA use mph, and they 
> are 2 of the most important countries in OSM.

Does UK still use mph?

Speaking about canals - do they use nautical speeds? Is the proper unit km/h, 
mph or knots, are these land or sea miles? Distances here are given in km, 
using km plates besides the canal.

> For heights and widths etc, the list is:
> * ft
> * m

m would be the default - and I assume it's a decimal POINT here (since many 
countries do use decimal commas). Since some distances might be above 1 000 
metres, I do recommend a space as thousands separator:

US: 1,000.00 m = 1 km
DE: 1.000,00 m = 1 km
1 000.00 m = 1 km ... my recommendation
-- 
Pt! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Units convention (Was: Mapping canals)

[Stephen Gower]

  CHANGE THE SUBJECT LINE, GUYS!

On Thu, Jan 24, 2008 at 04:08:21PM +0100, Michael Collinson wrote:
> 
> maxheight= 3 ft  - original-easy-to enter "folksomomic" key (defaults 
> either to metric or local usage, there are arguments for both)
> 
> maxheight:metric = 0.912  - added either by power users or by post-processing

  "I heartily endorse this event or product."
  
  Seriously, this feels like the OSM way, and therefore is right. 

  1) Existing tags are already "dirty" with respect to units - they
  can, and *do* contain mixed units.
  2) This is analogous to the language keyspace - the unspecified key
  contains the local "what's on the ground" data, but specific
  languages are in the approriate key.
  
  So as Michael says, maxheight could be anything, but
  maxheight:metric would be in metres.
  
  
  And maxspeed:metric would be in metres per second.
  
  
  
  s
  

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk