Re: [OSM-talk] Units convention (Was: Mapping canals)
-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
[OSM-talk] Units convention (Was: Mapping canals)
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. troll And maxspeed:metric would be in metres per second. /troll s ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Units convention (Was: Mapping canals)
The complete list of allowed units for speed is: Where did you find this? Is it http://wiki.openstreetmap.org/index.php/Map_Features#Restrictions * 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
Re: [OSM-talk] Units convention (Was: Mapping canals)
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
Re: [OSM-talk] Units convention (Was: Mapping canals)
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)
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
[OSM-talk] Units convention (Was: Mapping canals)
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
Re: [OSM-talk] Units convention (Was: Mapping canals)
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
