On 15/10/2008 00:17, Karl Newman wrote:
What about just using the maxspeed tag with just a number and having a
separate tag for the units. i.e., maxspeed=30; maxspeed_units=mph
Because it takes twice as long to enter.
Because it is non-obvious and unnecessary.
Because it separates two
Tristan Scott [EMAIL PROTECTED] writes:
If this catches on not only do we have a well-defined and easily-processed
value for
speed to use in all manner of things, we also have a template for defining
other
data types (bridge height? maxweight?) which might (or might not) make the
job of
Given that SI units are standard across OSM could be define a speed value
in addition to Numeric String etc like so:
(default to kmh as specified before (also means not adding millions of
pointless kmh strings to the db)
Factor means multiply by this to convert to SI - interpreters would either
Tristan Scott [EMAIL PROTECTED] writes:
Given that SI units are standard across OSM could be define a speed value
in addition to Numeric String etc like so:
(default to kmh as specified before (also means not adding millions of
pointless kmh strings to the db)
Factor means multiply by this
On 14/10/2008 18:26, Tristan Scott wrote:
Given that SI units are standard across OSM could be define a speed
value in addition to Numeric String etc like so:
(default to kmh as specified before (also means not adding millions of
pointless kmh strings to the db)
Factor means multiply by
If this catches on not only do we have a well-defined and easily-processed
value for speed to use in all manner of things, we also have a template
for defining other data types (bridge height? maxweight?) which might (or
might not) make the job of the data processor for an map consuming
Tristan wrote:
I am happy to use 30mph not 48 (which conflicts
with map features which specify kmh and not units..)
as it seems a widely-used value and hence /ought/ to
be interpreted by renderers (is it? are any of them?)
I don't think I know of any renderers that render maxspeed,
I've been reading this discussion since it started...
So far I've seen that there's a problem with conflicting values. It seems
that not only is maxspeed=??mph widely used, it's also handily in exactly
the same place as maxspeed=48 (which is what map features told me to do
(..ish, it didn't
Tristan Scott [EMAIL PROTECTED] writes:
If it were up to me (dicatorships are so much swifter to deal with
things...)
* maxspeed should be the only tag. Therefore you can't contradict
yourself/others (or update one to 40mph, or not catching because it's not
normal, maxspeed:mph is still 30
On Tue, Oct 14, 2008 at 11:05 AM, Tristan Scott [EMAIL PROTECTED] wrote:
If this catches on not only do we have a well-defined and easily-processed
value for speed to use in all manner of things, we also have a template
for defining other data types (bridge height? maxweight?) which might (or
Shaun McDonald [EMAIL PROTECTED] writes:
On 11 Oct 2008, at 08:09, Ed Loach wrote:
[..]
As Matthias writes:
From the
programmer's point of view I don't think it makes much of a
difference
whether the unit is stored in the key or in the value.
hrm with ruby if you are expecting a number
On Fri, Oct 10, 2008 at 11:36 AM, Shaun McDonald
[EMAIL PROTECTED] wrote:
It is
much simpler to parse maxspeed:mph=30 than to parse maxspeed=30mph.
It's much simpler to parse maxspeed=30mph than it is to work out which
one is correct when there's multiple maxspeed:[kph|mph]=30 tags, I'd
say.
Andy wrote:
It's much simpler to parse maxspeed=30mph than it is to work
out which
one is correct when there's multiple maxspeed:[kph|mph]=30
tags, I'd
say. I'd try to avoid having two potentially conflicting ways
of
tagging the same property.
Oh, and changing documentation on the wiki
Dermot McNally [EMAIL PROTECTED] writes:
Consider your word-processing package. Most will allow you to set
margins and positions in a number of units: millimetres, centimetres,
ems, points, possibly variable concepts like lines and even really
wacky units like inches. But the representation
It doesn't help anybody trying to use the data on the terms
implied in
the docs. Furthermore, you're deciding that your opinion (that
the
requirement to process units isn't onerous) is more valid that
the
opinion of the person who first documented maxspeed (that the
tag was
most valuable
On 11 Oct 2008, at 08:09, Ed Loach wrote:
[..]
As Matthias writes:
From the
programmer's point of view I don't think it makes much of a
difference
whether the unit is stored in the key or in the value.
hrm with ruby if you are expecting a number in that field and try to
parse it, the units
On Fri, Oct 10, 2008 at 02:35:59PM +0100, Dermot McNally wrote:
Seriously, though, we're currently in a situation where we have a
documented truth
Are you referring to Map features here? Is it a documented truth just because
it's in there? So how often have you used the one true tag
Ed Loach wrote:
Sent: 05 October 2008 1:46 PM
To: talk@openstreetmap.org
Subject: [OSM-talk] Map Features, maxspeed and maplint
(restore metrics text, although it should be discussed). I don't know
where to find the versions pre 2008 to find out what it said on older
versions.
Map Features
Dermot McNally wrote:
2008/10/10 Chris Hill [EMAIL PROTECTED]:
Conversions to 0dp is inaccurate, accurate conversions are a mess,
namespacing allows for conflicting values so only an optional suffix really
makes sense, so this why I use.
Well, maxspeed:mph would also work for your
2008/10/10 Chris Hill [EMAIL PROTECTED]:
maxspeed:mph only conforms to map features because Shaun amended it earlier
today!
[listens for the sound of the voting request email to arrive - hears
nothing]
Well, two wrongs and all that. Though its worse, IMHO, to do a poo in
another man's
On 10 Oct 2008, at 14:27, Chris Hill wrote:
Dermot McNally wrote:
2008/10/10 Chris Hill [EMAIL PROTECTED]:
Conversions to 0dp is inaccurate, accurate conversions are a mess,
namespacing allows for conflicting values so only an optional
suffix really
makes sense, so this why I use.
maxspeed:mph only conforms to map features because Shaun
amended it
earlier today!
And the way it has been amended with two keys in one table row means
that if the perl script is run that rebuilds the xml that is used to
generate the maplint not-in-mapfeatures validation rules, then
2008/10/8 Simon Ward [EMAIL PROTECTED]:
en is a language code, not a country code. Not all English-speaking
countries use imperial units on road signs. I think Australia uses
metric, for example.
So does the Republic of Ireland. In fact, I believe the only
English-speakers that don't are in
Dermot McNally wrote:
It makes more
sense to have maxspeed=numberoptional units; assume km/h if none
specified to avoid the chance of that happening.
Doing so prevents simple numerical analysis of the field contents.
Nothing can be analysed without pre-processing, and you are very
Shaun McDonald wrote:
(I'm wondering if there is a station out there that has all the
railway=platforms mapped, rather than just placing a footpath to the
railway=station node.)
Guildford station is pretty close, thanks to TimSC.
--
Jonathan (Jonobennett)
2008/10/10 Chris Hill [EMAIL PROTECTED]:
Conversions to 0dp is inaccurate, accurate conversions are a mess,
namespacing allows for conflicting values so only an optional suffix really
makes sense, so this why I use.
Well, maxspeed:mph would also work for your purposes. The only
difference is
I added the conversion table to maxspeed, as I do a lot of maxspeed tagging
in my area. I read the maxspeed definition as needing a numeric value in
km/h. While km/h doesn't mean a lot to me, I does to whatever app I use to
draw speed limit signs (or, more likely, whatever app runs a satnav system
2008/10/8 Ed Loach [EMAIL PROTECTED]:
I'd argue that it doesn't make sense, in that if you allow both
maxspeed:mph and maxspeed as valid tags, a way may end up tagged
with both showing contradictory speed information.
This would require either 2 mappers not heeding each other's work or
one
Hi,
Chris Hill wrote:
[listens for the sound of the voting request email to arrive - hears
nothing]
Voting is optional. We could do with a lot less if you ask me. If more
people would just go ahead and tag something... I have the impression
that many newcomers seem to view this as some kind
yay, you're a real mapper.
Those five seconds of happiness create an emotional link between the newcomer
and OSM, which I think is a great triumph for the latter.
cheers,
Lucas
=
Hi,
Chris Hill wrote:
[listens for the sound of the voting request email to arrive - hears
Hi,
In my opinion the voting process is broken, as it can potentially vote
in proposals that will break backwards compatibility and require
extensively more complex processing of the data.
Maybe we should make sure that the voting pages carry a disclaimer
saying: You are voting for a
Frederik Ramm wrote:
Hi,
Chris Hill wrote:
[listens for the sound of the voting request email to arrive - hears
nothing]
Voting is optional. We could do with a lot less if you ask me. If more
people would just go ahead and tag something... I have the impression
that many newcomers seem
Chris wrote:
My comment was more to point out that changing the Map features
by
adding the editor's favourite option as though it was an
accepted norm
while the discussion about the options was still taking place
seemed a
bit premature to me.
And perhaps as this discussion is limited to
On Wed, Oct 08, 2008 at 12:38:01AM +0100, Mark Williams wrote:
+1 on the namespace; I'm not generally keen on it, but here it makes
sense. Either the way mentioned, or maxspeed:en as per name:en for
consistency?
“en” is a language code, not a country code. Not all English-speaking
countries
On Wed, Oct 08, 2008 at 07:32:36AM +0100, I wrote:
On Wed, Oct 08, 2008 at 12:38:01AM +0100, Mark Williams wrote:
Either the way mentioned, or maxspeed:en as per name:en for
consistency?
“en” is a language code
“metric” and “imperial” might be better, although I feel that specifying
the
Mark wrote:
Maybe grin this is calling out for a 'bot approach, to take
maxspeed:mph add a numeric maxspeed, to check out
maxspeed=30's mark
them in some way (restricted to UK, obviously), and to check
for entries
of both=30 fix them?
snip
+1 on the namespace; I'm not generally keen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dermot McNally wrote:
2008/10/5 Ed Loach [EMAIL PROTECTED]:
30mph. If we had stayed with assumed country-specific units then the tagging
would have been more consistent, easier for the user to tag, and not require
a conversion to a random number
Simon wrote:
This is my method too. I have converted before, but always
included
both maxspeed=* (~km/h) and maxspeed:mph=* (mph)
OK, I can see having (or allowing for) both of these makes some sort of sense,
although it does lead to the situation where you might have two maxspeed tags
for
I've not done much maxspeed tagging to date, for various reasons, but the main
one is that Map Features says that maxspeed should be in km/h. Or more
accurately looking at the history for the template for that section [1], the
original conversion stated:
{{{maxspeed:desc|Maximum speed,
All units in osm should be the metric value, unless the units have
been name spaced. Whenever I enter mph units, I use the tag
maxspeed:mph=30 etc as this is the most accurate way of representing
the data. I'm not going to spend time converting between mph and kph,
when entering the data,
2008/10/5 Ed Loach [EMAIL PROTECTED]:
30mph. If we had stayed with assumed country-specific units then the tagging
would have been more consistent, easier for the user to tag, and not require
a conversion to a random number of decimal places.
I'm not a fan of the options that include suffixes
On Sun, Oct 05, 2008 at 02:09:26PM +0100, Shaun McDonald wrote:
All units in osm should be the metric value, unless the units have been
name spaced. Whenever I enter mph units, I use the tag maxspeed:mph=30
etc as this is the most accurate way of representing the data.
This is my method too.
42 matches
Mail list logo
