|
Map Features, maxspeed and maplint
Some parts of this message have been removed.
Learn more about Nabble's security policy.
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, country-specific
units}}"
And the revision 3 minutes later changed it to
"{{{maxspeed:desc|Maximum speed in km/h}}}"
With a description for the edit (from Pieren) of
"(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.
I noticed that “should be discussed” note, but don’t know
where to look for that discussion. However, the decision to put in km/h has
made a mess of the maxspeed tagging on UK roads, especially as there is both a
conversion table in the wiki quoting whole numbers, and a multiplication factor
to use. See for example Tagwatch [2] where the most common maxspeed is 48,
followed by 30mph (the format I’ve been using), and lower down come 48.28,
48.28032, 48.27808 and 48.3. I’d also guess that the ways tagged as maxspeed=30
mean 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.
The maplint mention in the message subject is because Map
Features defines the value for the maxspeed key as being a number, so any way I’ve
tagged as =30mph, 20mph, 10mph, national or 40mph (as I did for the first time
yesterday) gets highlighted in the maplint information, rendering it (no pun
intended) next to useless for checking other mistakes I may have made in the
tagging.
I have no suggestion what to do about either of these
situations though. I wouldn’t have been bothered at all if maplint hadn’t
suddenly started highlighting lots of ways in the area… I realise that that is
down to the word number in the wiki page causing the validation to fail with
the mph in the value.
Thinking about it I have a similar issue with maxheight.
Most of the signs these days I think quote in metres, but I tagged one the
other day as so many feet and inches (possibly 13’9” – I forget), as I tag what
is on the sign and not what a metric conversion is (to the centimetre, metre,
decimetre, millimetre?). It seems I’m not the only one [3].
I suspect what I’d like most would be for maplint to recognise
that if the value contains valid units for whatever the key is (optional
units), then it wouldn’t highlight the way as in need of checking. I believe
maplint is common to both Mapnik and Osmarender (as it’s highlighting ways on
Mapnik which don’t yet show as I only added them yesterday), and I know how to
rebuild the not-in-map_features information as I did it recently to add some
keys that *were* in Map Features but not being recognised by the T@H
client when it generated the maplint tiles, but it would probably need the perl
code that creates the XML tweaking to cope with optional units in some way (a
bit like it currently doesn’t like * in the value column, IIRC, or “User
Defined”).
It’s raining here incidentally, which is why I thought I’d
rant on email instead of going out mapping a bit more of the area.
Ed
[1] http://wiki.openstreetmap.org/index.php?title=Template%3AMap_Features%3Arestrictions&diff=73032&oldid=73031
[2] http://tagwatch.stoecker.eu/Great_britain/En/keystats_maxspeed.html
[3] http://tagwatch.stoecker.eu/Great_britain/En/keystats_maxheight.html
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
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, that is for whoever uses the data to do. In my opinion, it is far better to use the local units, but always have it clear as to the units, when they are not metric/most common.
Shaun On 5 Oct 2008, at 13:45, Ed Loach wrote: 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, country-specific units}}" And the revision 3 minutes later changed it to "{{{maxspeed:desc|Maximum speed in km/h}}}" With a description for the edit (from Pieren) of "(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. I noticed that “should be discussed” note, but don’t know where to look for that discussion. However, the decision to put in km/h has made a mess of the maxspeed tagging on UK roads, especially as there is both a conversion table in the wiki quoting whole numbers, and a multiplication factor to use. See for example Tagwatch [2] where the most common maxspeed is 48, followed by 30mph (the format I’ve been using), and lower down come 48.28, 48.28032, 48.27808 and 48.3. I’d also guess that the ways tagged as maxspeed=30 mean 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. The maplint mention in the message subject is because Map Features defines the value for the maxspeed key as being a number, so any way I’ve tagged as =30mph, 20mph, 10mph, national or 40mph (as I did for the first time yesterday) gets highlighted in the maplint information, rendering it (no pun intended) next to useless for checking other mistakes I may have made in the tagging. I have no suggestion what to do about either of these situations though. I wouldn’t have been bothered at all if maplint hadn’t suddenly started highlighting lots of ways in the area… I realise that that is down to the word number in the wiki page causing the validation to fail with the mph in the value. Thinking about it I have a similar issue with maxheight. Most of the signs these days I think quote in metres, but I tagged one the other day as so many feet and inches (possibly 13’9” – I forget), as I tag what is on the sign and not what a metric conversion is (to the centimetre, metre, decimetre, millimetre?). It seems I’m not the only one [3]. I suspect what I’d like most would be for maplint to recognise that if the value contains valid units for whatever the key is (optional units), then it wouldn’t highlight the way as in need of checking. I believe maplint is common to both Mapnik and Osmarender (as it’s highlighting ways on Mapnik which don’t yet show as I only added them yesterday), and I know how to rebuild the not-in-map_features information as I did it recently to add some keys that *were* in Map Features but not being recognised by the T@H client when it generated the maplint tiles, but it would probably need the perl code that creates the XML tweaking to cope with optional units in some way (a bit like it currently doesn’t like * in the value column, IIRC, or “User Defined”). It’s raining here incidentally, which is why I thought I’d rant on email instead of going out mapping a bit more of the area. Ed _______________________________________________ talk mailing list talk@...http://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
2008/10/5 Ed Loach < ed@...>:
> 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 or other tricks to
imply units. That said, even that approach is better than using
country-specific units, because it's a huge burden on applications to
work out what country a restriction falls within (twofold, since the
border data is often imprecise too). Consider the Irish border, which
is also an imperial/metric border. Yuck!
A further drawback with the approach is the assumption that units stay
uniform within a particular country. But in the UK, it's getting
common for height restrictions to be stated in dual units. So for
transitional cases like that, the country-specific model breaks down.
I'm with Shaun on the namespacing thing. Allowing fields like maxspeed
to contain normalised, pure numeric data is beneficial for fast data
extraction, and the namespaced approach allows for automatic updating
of the "real|" numeric field.
Dermot
--
--------------------------------------
Iren sind menschlich
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
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. I have converted before, but always included
both maxspeed=* (~km/h) and maxspeed:mph=* (mph)
Simon
--
A complex system that works is invariably found to have evolved from a
simple system that works.—John Gall
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talkA complex system that works is invariably found to have evolved from a simple system that works.—John Gall
|
|
Re: Map Features, maxspeed and maplint
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 a way which might not even be close to agreeing (say if one user adds maxspeed:mph=30 at one time and someone later adds maxspeed=30 without specifying units anywhere). Users of the data would then need some sort of algorithm to try and determine which is most likely to be accurate, and I would suggest that may need to perhaps use knowledge of individual countries to know whether their limits are in mph or km/h anyway, so that would suggest country specific units wouldn't have been any extra issue in the first place. Certainly with the UK maxspeed data as it currently stands, it will need some sort of algorithm to try and work out what the maxspeed value represents.
However, having changed my maxspeed=30mph tags to maxspeed:mph=30 and got the tiles rerendered, this still doesn't seem to help with the maplint not-in-map_features highlighting, and even if it did then it still probably wouldn't like maxspeed(with or without :mph)=national to mark roads that are at the national speed limit (I've not checked to see whether it copes with maxspeed=none as is recommended for relevant German autobahns, but I'd guess not, and I can see despite the suggestion to use it on the maxspeed wiki page [1], the proposal to formalise it currently seems to be being generally opposed [2]).
Also, checking Tagwatch [0], maxspeed:mph=30 seems much less common than maxspeed=30mph so this does seem to be a minority choice for tagging, although could be added to Map Features easily enough as a numeric value and so not highlighted by Maplint. I guess this then means any other maxspeed:units should also be added. Does anyone use maxspeed:knots for example?
I'm almost tempted to add maxspeed=30mph and maxspeed:mph=30 - just to be clear what the speed limit actually is <g>.
I can see no point at all in putting a km/h speed limit value on a tag unless the sign is in km/h (and I believe I have read of a few in the UK). Surely it should be down to the users of the data to do the conversion of maxspeed at whatever accuracy they want, rather than making the people collecting the data calculate something other than that which is physically denoted on the signs, resulting in differing degrees of rounding which the user of the data would then have to guess means 30mph, effectively converting from estimate to accurate and back to desired accuracy. As long as the units are clearly expressed if they are not the default then this shouldn't be a problem (and I'm assuming no-one would read mph as metres per hour, except perhaps snails).
Looking at the comments about maxspeed on the wiki at present, perhaps some consideration should be put towards some proposal, such as:
maxspeed=number (optional units from predefined list, default km/h)
maxspeed:opposite=number (optional units from predefined list, default km/h)
maxspeed:psv=number (optional units etc)
maxspeed:psv:opposite=number (optional etc)
which would allow for where single ways have different speeds in opposite directions (I can't think of any examples, but someone asked about it on maxspeed discussion page), and where different vehicle types (I use psv only as one example) have different limits - I think it more common on things like the French toll routes than in the UK; in the UK some vehicle types have different limit, but that is a feature of the vehicle therefore and not something that needs mapping). I have suggested the optional units here be with the value as that avoids having multiple contradictory maxspeeds that differ only in the units specified; it is for this reason I was using maxspeed=30mph originally (rather than maxspeed:mph=30, as I had seen mention of both alternatives previously.
I note though maxspeed=walk seems to be looking like it might get voted through [3], which wouldn't fit very well with the above.
Ed
[0] http://tagwatch.stoecker.eu/Great_britain/En/tags.html[1] http://wiki.openstreetmap.org/index.php/Key:maxspeed[2] http://wiki.openstreetmap.org/index.php/Proposed_features/maxspeed_none[3] http://wiki.openstreetmap.org/index.php/Proposed_features/maxspeed_walk_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dermot McNally wrote:
> 2008/10/5 Ed Loach < ed@...>:
>
>> 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 or other tricks to
> imply units. That said, even that approach is better than using
> country-specific units, because it's a huge burden on applications to
> work out what country a restriction falls within (twofold, since the
> border data is often imprecise too). Consider the Irish border, which
> is also an imperial/metric border. Yuck!
>
> A further drawback with the approach is the assumption that units stay
> uniform within a particular country. But in the UK, it's getting
> common for height restrictions to be stated in dual units. So for
> transitional cases like that, the country-specific model breaks down.
>
> I'm with Shaun on the namespacing thing. Allowing fields like maxspeed
> to contain normalised, pure numeric data is beneficial for fast data
> extraction, and the namespaced approach allows for automatic updating
> of the "real|" numeric field.
>
> Dermot
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?
Note: I haven't said "I'll do it" because I know I'd be shot...
I think a lot of people have refrained from using these tags where the
speed limit is what you'd expect, so residential defaults to 30mph,
trunk to 70, etc & tagging it is not required - so any bot approach
should respect that.
+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?
Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.orgiD8DBQFI6/LZJfMmcSPNh94RAijGAJ9M/dxPTjuPkCsUNgkbMhs9sFLupwCePQsZ
oQltkcfxNEHS9tLSEfMxtfI=
=JYyp
-----END PGP SIGNATURE-----
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
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 use imperial units on road signs. I think Australia uses
metric, for example.
Simon
--
A complex system that works is invariably found to have evolved from a
simple system that works.—John Gall
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talkA complex system that works is invariably found to have evolved from a simple system that works.—John Gall
|
|
Re: Map Features, maxspeed and maplint
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 units somehow (by key suffix or otherwise) is much more clear.
Simon
--
A complex system that works is invariably found to have evolved from a
simple system that works.—John Gall
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talkA complex system that works is invariably found to have evolved from a simple system that works.—John Gall
|
|
Re: Map Features, maxspeed and maplint
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 on it, but here it
> makes
> sense.
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. It makes more
sense to have maxspeed=<number><optional units; assume km/h if none
specified> to avoid the chance of that happening. It does make sense
for other situations, such as if opposite directions have different
limits (e.g. maxspeed:opposite=<number><optional units>), or if
different vehicle types have different limits (e.g.
maxspeed:psv=<number><optional units>) as these clearly can't lead
to contradictory information (assuming that if a vehicle type is
specified it overrides any other maxspeed tags).
Ed
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
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 and informs the user when they're over the stated
maxspeed for the way they're on)
The maxspeed needs to be computer-readable, so people tagging
maxspeed=30 when the wiki states km/h is misleading, to my mind. People
tagging as 30mph is fine, as that can be parsed to a consistent value
anyway. I think it should be in the database as rounded numeric km/h for the following reasons:
1) 30 mph/30mph/30 all meaning 48 is difficult to parse (or at least, more coding) 2)
tagging in floating point is more accurate, but rounding the result to
0 dp seems sensible (I also did that because I didn't know if
floating-points were approved in the database)
3) The conversion table is an accurate table to 0dp - some people
according to the tags-in-use pages seem to have converted the value
inaccurately, so I thought it'd save people doing bad math... (30mph !=
50km/h, though if we get converted by europe it might change to that)
4) the wiki says km/h, as as previous suggested it's sometimes (often)
unclear which unit was meant by mapper, and which unit is in use where
the tag in (international waters/boundaries/ways crossing borders/etc
And I'd welcome a sed-like change to the database to "fix" (imho) the
maxspeed=30mph tags (I'd like them consistent. I not too bothered if we
store millions of "mph" strings instead of just using km/h, as long as
I can easily parse the data)
Oh, and I tend to only tag ways with non-national speed limits on -
I assume there's a country-wide default maxspeed per road type (though
again the border problem raises it's head) Tristan 2008/10/8 Ed Loach <ed@...>
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 on it, but here it
> makes
> sense.
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. It makes more
sense to have maxspeed=<number><optional units; assume km/h if none
specified> to avoid the chance of that happening. It does make sense
for other situations, such as if opposite directions have different
limits (e.g. maxspeed:opposite=<number><optional units>), or if
different vehicle types have different limits (e.g.
maxspeed:psv=<number><optional units>) as these clearly can't lead
to contradictory information (assuming that if a vehicle type is
specified it overrides any other maxspeed tags).
Ed
-- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk07837 205829
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
2008/10/8 Simon Ward < simon@...>:
> "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 UK and USA.
--
--------------------------------------
Iren sind menschlich
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
On 10 Oct 2008, at 10:24, Tristan Scott wrote: 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 and informs the user when they're over the stated maxspeed for the way they're on)
The maxspeed needs to be computer-readable, so people tagging maxspeed=30 when the wiki states km/h is misleading, to my mind. People tagging as 30mph is fine, as that can be parsed to a consistent value anyway.
I think it should be in the database as rounded numeric km/h for the following reasons:
1) 30 mph/30mph/30 all meaning 48 is difficult to parse (or at least, more coding)
2) tagging in floating point is more accurate, but rounding the result to 0 dp seems sensible (I also did that because I didn't know if floating-points were approved in the database)
3) The conversion table is an accurate table to 0dp - some people according to the tags-in-use pages seem to have converted the value inaccurately, so I thought it'd save people doing bad math... (30mph != 50km/h, though if we get converted by europe it might change to that)
4) the wiki says km/h, as as previous suggested it's sometimes (often) unclear which unit was meant by mapper, and which unit is in use where the tag in (international waters/boundaries/ways crossing borders/etc
You should use maxspeed:mph=nn for speeds in miles per hour, not convert it to km/h, which gives an inexact value and more importantly doesn't map what is on the ground. I don't expect to have to look up a value every time I enter a speed into the database. And I'd welcome a sed-like change to the database to "fix" (imho) the maxspeed=30mph tags (I'd like them consistent. I not too bothered if we store millions of "mph" strings instead of just using km/h, as long as I can easily parse the data)
Don't run bots on osm! It is much better to correct things with local knowledge, as there is often other things that need to be fixed too. It is much simpler to parse maxspeed:mph=30 than to parse maxspeed=30mph.
Shaun Oh, and I tend to only tag ways with non-national speed limits on - I assume there's a country-wide default maxspeed per road type (though again the border problem raises it's head) Tristan 2008/10/8 Ed Loach <ed@...> 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 on it, but here it
> makes
> sense.
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. It makes more
sense to have maxspeed=<number><optional units; assume km/h if none
specified> to avoid the chance of that happening. It does make sense
for other situations, such as if opposite directions have different
limits (e.g. maxspeed:opposite=<number><optional units>), or if
different vehicle types have different limits (e.g.
maxspeed:psv=<number><optional units>) as these clearly can't lead
to contradictory information (assuming that if a vehicle type is
specified it overrides any other maxspeed tags).
Ed
-- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk07837 205829
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
2008/10/8 Ed Loach < ed@...>:
> 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 very disorganised mapper.
> It makes more
> sense to have maxspeed=<number><optional 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 prone
to dodgy units (how many ways can you right Miles Per Hour?)
Dermot
--
--------------------------------------
Iren sind menschlich
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
Dermot McNally wrote:
>
>> It makes more
>> sense to have maxspeed=<number><optional 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 prone
> to dodgy units (how many ways can you right Miles Per Hour?)
>
>
>
Any analysis requires the data to be preprocessed to extract it from the
XML storage format, so a little extra to account for the suffix is a
small overhead.
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.
Cheers, Chris
(living on a street where maxspeed=30mph)
_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk
|
|
Re: Map Features, maxspeed and maplint
2008/10/10 Chris Hill < chillly809@...>:
> 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 that you have chosen to silently ignore the behaviour
docu |
signature.asc (204 bytes)