IMO it should be possible to specify any of these things in meters too.
Because I'm a Dutch sailor and I use meters (heights and widths),
decimeters (depth) and nautical miles (distances). That's also the way
it's on my maps. I really have no idea how long an inch is (and the only
thing I know
Dermot McNally wrote:
> I can't tell if this is your words or something you've quoted,
My words; and, in hindsight, loose ones. Let's try something like:
Note: Any canal measurements which are in feet and inches are given as
"\d+ft( \d+in)?". That is, a number, followed by "ft" as an
abbreviat
On 04/02/2008, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Note: canal measurements are given in feet and inches, as "\d+ft(
> \d+in)?". That is, a number, followed by "ft" as an abbreviation, a
> space, and then optionally a number and "in".
I can't tell if this is your words or something you'v
Abigail Brady wrote:
> I've tagged low bridges in Leicester with maxheight=15'0", for example.
> That's what the sign on the bridge says, that should be represented in
> the database.
I definitely think that's wrong. Even if we decide to have units in the
database, that does not mean we need t
Tom Evans wrote:
>Sent: 24 January 2008 4:44 PM
>To: talk@openstreetmap.org
>Subject: Re: [OSM-talk] Mapping canals
>
>Andy Robinson (blackadder) wrote:
>> >(Actually, on checking with a calculator, 7*12*2.54=213.36. So I'm
>> >doing a bit of unconscious roun
Andy Robinson (blackadder) wrote:
> >(Actually, on checking with a calculator, 7*12*2.54=213.36. So I'm
> >doing a bit of unconscious rounding already.)
>
> Indeed, the exact conversion is to multiply/divide by 0.3058
Er, you mean 0.3048, right?
(one inch is _defined as_ 25.4mm, and has been for
Richard Fairhurst wrote:
>Sent: 24 January 2008 3:52 PM
>To: talk@openstreetmap.org
>Subject: Re: [OSM-talk] Mapping canals
>
>Andy Allan wrote:
>
>> 2) There are two different things that everyone is talking about, and
>> keep getting them confused
>> *
Andy Allan wrote:
> 2) There are two different things that everyone is talking about, and
> keep getting them confused
> * The distance, or speed, that you are recording (i.e. the physical
> property). Units are interchangable, can be converted etc to your
> heart's content.
> * The manner in
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gervase Markham wrote:
| Dave Stubbs wrote:
|> But some of them will be incorrect. And how do I now make a renderer
|> that gives the speed limit in the unit it's actually specified?
|
| We seem to have a choice between:
|
| 1) Making renderers which n
Michael Collinson wrote:
> At 03:34 PM 1/24/2008, Jo wrote:
>
>> Dermot McNally wrote:
>>
>>> My favourite suggestion so far is that a second key be introduced -
>>> either for the "original" measurement (my favourite, since it retains
>>> the traditional meaning of the existing key) or for
Andy Allan wrote:
> On Jan 24, 2008 2:34 PM, Jo <[EMAIL PROTECTED]> wrote:
>
>> Dermot McNally wrote:
>>
>>> My favourite suggestion so far is that a second key be introduced -
>>> either for the "original" measurement (my favourite, since it retains
>>> the traditional meaning of the exist
At 03:34 PM 1/24/2008, Jo wrote:
>Dermot McNally wrote:
> > My favourite suggestion so far is that a second key be introduced -
> > either for the "original" measurement (my favourite, since it retains
> > the traditional meaning of the existing key) or for the normalised
> > equivalent.
> >
>This
On Jan 24, 2008 2:34 PM, Jo <[EMAIL PROTECTED]> wrote:
> Dermot McNally wrote:
> > My favourite suggestion so far is that a second key be introduced -
> > either for the "original" measurement (my favourite, since it retains
> > the traditional meaning of the existing key) or for the normalised
> >
Dermot McNally wrote:
> My favourite suggestion so far is that a second key be introduced -
> either for the "original" measurement (my favourite, since it retains
> the traditional meaning of the existing key) or for the normalised
> equivalent.
>
This is what I was thinking all along. On the o
On 24/01/2008, Abigail Brady <[EMAIL PROTECTED]> wrote:
> We need for the UK to keep imperial measurements in the DB.
Our challenge is to manage to do this while also keeping the data
interpretable. If an in-truck navigation system knows that this
particular truck needs a clearance of 5m then max
I am rabidly anti-imperial :-) yet whole-heartedly concur with Abi's
sentiments and approach. OSM is a "folksonomy" and one of the most
important things to me is to lower the bar for folks to enter data
without reading a detailed specification and without having to
perform pre-processing or p
On Jan 24, 2008 11:26 AM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> I'm also worried about people using gauges adding 5ft 5in somewhere,
> we should at least require decimals.
>
I've tagged low bridges in Leicester with maxheight=15'0", for example.
That's what the sign on the bridge sa
On Jan 24, 2008 12:12 PM, Andy Robinson (blackadder)
<[EMAIL PROTECTED]> wrote:
> OSM will always need smart and sophisticated processing.
But need should draw a line somewhere. I think we should declare
anyone trying to add:
speed=45ft 6 13/16in per second
as insane and we should not be expecte
Gervase Markham wrote:
> So this is just another example of why allowing people to use any unit
> "as long as they label it" is a bad idea :-)
I am afraid that is a bit of a straw man argument.
The canals in the UK are specified in feet (for example, maximum width a
boat can be, the length of l
Gervase Markham wrote:
>Sent: 24 January 2008 10:34 AM
>To: talk@openstreetmap.org
>Subject: Re: [OSM-talk] Mapping canals
>
>Sven Grüner wrote:
>> I don't know of any country using the metric system that is familiar
>> with the term "kph". The unit s
On 24/01/2008 10:34, Gervase Markham wrote:
> Sven Grüner wrote:
>> I don't know of any country using the metric system that is familiar
>> with the term "kph". The unit symbol is "km/h" and so everbody uses *kmh*.
>
> Google understands kph:
> http://www.google.com/search?ie=UTF-8&oe=UTF-8&source
Sven Grüner wrote:
> I don't know of any country using the metric system that is familiar
> with the term "kph". The unit symbol is "km/h" and so everbody uses *kmh*.
Google understands kph:
http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=30mph+in+kph
So this is just an
Robert Vollmert wrote:
> How about an extra key maxspeed:source_value_with_unit=30mph and a
> cron job that updates maxspeed from maxspeed:source_value_with_unit?
Why does this data need to be in the database, if the conversion from
one to the other is purely mechanical?
Let's have all data in
On 23/01/2008, Robert Vollmert <[EMAIL PROTECTED]> wrote:
> How about an extra key maxspeed:source_value_with_unit=30mph and a
> cron job that updates maxspeed from maxspeed:source_value_with_unit?
I can't see a downside to that. At worst (cron job can't grok the
input) it just won't enter a valu
On Jan 23, 2008, at 11:44, David Earl wrote:
> I had in mind (and it'll probably stay in mind!) a renderer which
> showed
> you a ground level view of the street you were "moving" along with
> upcoming turnings and so on, like a satnav display, which showed
> signposts - no right turn, this way
On 23/01/2008, David Earl <[EMAIL PROTECTED]> wrote:
> I had in mind (and it'll probably stay in mind!) a renderer which showed
> you a ground level view of the street you were "moving" along with
> upcoming turnings and so on, like a satnav display, which showed
> signposts - no right turn, this
On Tue, Jan 22, 2008 at 09:44:32PM +, Stephen Gower wrote:
> > (amenity=pumpout;water_point), and to come up with a separate tag for
> > what we refer to as "Elsan disposal" (a drain where you can empty your
> > Porta-Potti!). amenity=poo_hole could be misconstrued.
>
> That reminds me o
On 22/01/2008 22:53, 80n wrote:
> I don't think *renderers* really need to know much about speed limits.
> If a road is tagged with 73000furlongsperfortnight then a renderer might
> show that on a map, but it's probably not going to try to convert it to
> any other units - why would it need to?
On Jan 23, 2008 12:12 AM, Dermot McNally <[EMAIL PROTECTED]> wrote:
> So now let's consider items like distances, depths, heights and other
> items that can be rendered in either metric or imperial (and for all I
> know, maybe other) units. I happen to be a user of metric measures, so
> I want to s
On 22/01/2008, Richard Fairhurst <[EMAIL PROTECTED]> wrote:
> Dermot McNally wrote:
>
> > Up until now, all such units have, by OSM convention, been stored in
> > metric units, which obviously suits me just fine.
>
> That's just not true - there are plenty of maxspeed=something imperial
> in the da
Dermot McNally wrote:
> Up until now, all such units have, by OSM convention, been stored in
> metric units, which obviously suits me just fine.
That's just not true - there are plenty of maxspeed=something imperial
in the database.
TBH I don't see the difficulty in those few clients which n
On 22/01/2008, 80n <[EMAIL PROTECTED]> wrote:
> I don't think *renderers* really need to know much about speed limits. If a
> road is tagged with 73000furlongsperfortnight then a renderer might show
> that on a map, but it's probably not going to try to convert it to any other
> units - why would
Gervase Markham schrieb:
> 2) Making renderers which need to understand all possible units anyone
> might use, and how to convert them into the units they want to render on
> the map (which may or may not be the units encoded).
> 50kph -> 31.07mph -> "30mph"
> 45mph -> 45mph -> "45mph"
> 73000fur
This is going rapidly off-topic, but I think that this is an important
precedent we are at risk of setting here. One that shouldn't be made
in private by those of us who care about canals.
I think that the matter of unit encoding and presentation is a little
like that of language. We've already ha
On Jan 22, 2008 10:35 PM, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Dave Stubbs wrote:
> > But some of them will be incorrect. And how do I now make a renderer
> > that gives the speed limit in the unit it's actually specified?
>
> We seem to have a choice between:
>
> 1) Making renderers which
Dave Stubbs wrote:
> But some of them will be incorrect. And how do I now make a renderer
> that gives the speed limit in the unit it's actually specified?
We seem to have a choice between:
1) Making renderers which need to understand the units they want to
render on the map, and are capable of
On Tue, Jan 22, 2008 at 11:43:25AM +, Richard Fairhurst wrote:
> > Amenities
> > -
> > New tag value: amenity=sanitary_station
>
> Sanitary station is a really misleading (but sadly widespread) term.
> Better to group all the constituent services
> (amenity=pumpout;water_point), an
On Jan 22, 2008 5:39 PM, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Dave Stubbs wrote:
> > This is really not difficult to handle.
> > You check for a unit, if you don't understand the unit you pretend the
> > tag didn't exist.
>
> So this means that some renderers won't render some values; wher
On Jan 22, 2008 5:02 PM, Simon Hewison <[EMAIL PROTECTED]> wrote:
> Dave Stubbs wrote:
> > And what is the exact SI equivalent of 30mph?
>
> According to the current UK Highway Code, 30mph = 48km/h.
It's wrong ;-)
>
>
> > I can give you an approximation: 48.28032km/h.
> > What happens though
Dave Stubbs wrote:
> This is really not difficult to handle.
> You check for a unit, if you don't understand the unit you pretend the
> tag didn't exist.
So this means that some renderers won't render some values; whereas if
we standardised on metres, then all renderers would render all values.
Dave Stubbs wrote:
> And what is the exact SI equivalent of 30mph?
According to the current UK Highway Code, 30mph = 48km/h.
> I can give you an approximation: 48.28032km/h.
> What happens though if everyone sticks in 48 instead.. close enough
> isn't it?
If the UK Department for Transport ever
Richard Fairhurst wrote:
>Sent: 22 January 2008 4:07 PM
>To: talk@openstreetmap.org
>Subject: Re: [OSM-talk] Mapping canals
>
>matthew-osm wrote:
>
>> With up to about a 20m error (which in practice seems to be about right),
>you
>> might be out by ~65ft.
>>
matthew-osm wrote:
> With up to about a 20m error (which in practice seems to be about right), you
> might be out by ~65ft.
>
> (Granted, both points are likely to be out by the same amount if taken at the
> same time, but it's still a bit close IMO.)
Yup.
Actually the real issue is mapping tole
On Tue, Jan 22, 2008 at 02:25:57PM +, Gervase Markham wrote:
> Any GPS can distinguish two points 70ft apart, can't they?
With up to about a 20m error (which in practice seems to be about right), you
might be out by ~65ft.
(Granted, both points are likely to be out by the same amount if taken
On Jan 22, 2008 2:17 PM, Dermot McNally <[EMAIL PROTECTED]> wrote:
> On 22/01/2008, Richard Fairhurst <[EMAIL PROTECTED]> wrote:
>
> > maxspeed=110 <-- assumed km/h
> > maxspeed=70mph <-- unit stated
> > maxwidth=2.14 <-- assumed metres
> > maxwidht=7ft <-- unit stated
>
> I'm uneasy about th
Richard Fairhurst wrote:
> A few more comments, and like Stephen, I've not commented on those
> where I agree. Generally we should make sure that tags are applicable
> to all navigable waterways, so river navigations as well as canals.
Sure.
> If you have correctly tagged a waterway with maxl
Stephen Gower wrote:
> Hi Gerv - I've snipped lots below - if I haven't commented on any
> part, I pretty much agree.
>
> On Mon, Jan 21, 2008 at 06:36:48PM +, Gervase Markham wrote:
>> Narrow sections are denoted by maxwidth. One narrowboat (just over 7
>> feet) is given as 2.5m. Two b
On 22/01/2008, Richard Fairhurst <[EMAIL PROTECTED]> wrote:
> maxspeed=110 <-- assumed km/h
> maxspeed=70mph <-- unit stated
> maxwidth=2.14 <-- assumed metres
> maxwidht=7ft <-- unit stated
I'm uneasy about this - up till now, these fields were assumed to
contain pure numbers, with the ease
A few more comments, and like Stephen, I've not commented on those
where I agree. Generally we should make sure that tags are applicable
to all navigable waterways, so river navigations as well as canals.
Gervase Markham wrote:
> Narrow sections are denoted by maxwidth. One narrowboat (just ov
Hi Gerv - I've snipped lots below - if I haven't commented on any
part, I pretty much agree.
On Mon, Jan 21, 2008 at 06:36:48PM +, Gervase Markham wrote:
>
> Narrow sections are denoted by maxwidth. One narrowboat (just over 7
> feet) is given as 2.5m. Two boats is 5m. It's not necessary
Gervase Markham wrote:
> As people may know, the UK has an extensive system of canals.
OK. So here's a load of proposals rather than questions :-) There are
quite a few, so it seems sensible to me to bat them around here as a
unified set before taking them to the wiki.
Canals
--
Canals are
Sven Grüner wrote:
> Many sluices I know from France, Germany and Scotland have small tags
> (or even carved stone) stating the height above sealevel or at least
> their level-difference. You can then go and tag the nodes in the
> waterway right next to the lock and give them ele-tags, according to
Robert (Jamie) Munro wrote:
> Per country defaults sounds like a nightmare to me any software designed
> to do anything with any of the data would have to know the list of
> defaults and the borders of all the countries in order to be useful.
> Please put ft or m in every tag.
That's an even worse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Verwijmeren wrote:
| On Thu, 17 Jan 2008 18:39:19 +
| Gervase Markham <[EMAIL PROTECTED]> wrote:
|
|> - Locks have a maximum width and length, universally measured in
|> feet.
|
| Do you brits really live in a different universe?
|
| Please
On Fri, 2008-01-18 at 01:24 +0100, Martijn Verwijmeren wrote:
> On Thu, 17 Jan 2008 18:39:19 +
> Gervase Markham <[EMAIL PROTECTED]> wrote:
>
> > - Locks have a maximum width and length, universally measured in
> > feet.
>
> Do you brits really live in a different universe?
Not all of us, f
On Thu, 17 Jan 2008 18:39:19 +
Gervase Markham <[EMAIL PROTECTED]> wrote:
> - Locks have a maximum width and length, universally measured in
> feet.
Do you brits really live in a different universe?
Please, whatever tags you design: Make them usable in more countries
than just the UK. France
Sven Grüner schrieb:
> Tag them seperately! Depending on their condition and usage it could be
> footway, bridleway, track or even residential. The tracktype-tag might
> not be the best way to tag quality
...but is still widely used.
(I meant to say)
__
Hi Gervase,
first of all: OSM evolves (as steve is saying). Take on step after the
other and apply everything you've learned from the previous one to the
next. So it's not smart to do everything in the first step because then
there's nothing left to make better for the next, if you catch my drift.
Gervase Markham wrote
>Sent: 17 January 2008 10:43 PM
>To: talk@openstreetmap.org
>Subject: Re: [OSM-talk] Mapping canals
>
>Gregory wrote:
>> "All canals have towpaths"
>> No.
>
>OK, yes, that was a generalisation. Almost all canals on the used
>sect
Gregory wrote:
> I think there is someone on OSM who lives on a canal boat, or does
> quite a bit of canal boating. I seem to remember them providing
> some input into discussions, but can't remember who they are.
That'd be me. :) I live on a boat half the week, my day-job is editor
of Wate
Gregory wrote:
> "All canals have towpaths"
> No.
OK, yes, that was a generalisation. Almost all canals on the used
sections of recreational canal on the map I gave a link to have
towpaths. The vast majority of canals have towpaths.
> I think locks were changed to nodes rather than ways so the
On 17/01/2008 20:51, Gregory wrote:
>
> "All canals have towpaths"
> No. Some canals are now disused so sections of the towpath are gone (now
> private land/buildings etc.), some canals aren't for navigation/boats (I
> know of one used to supply a fountain by Hampton Court Palace and the
> man-
"All canals have towpaths"
No. Some canals are now disused so sections of the towpath are gone (now
private land/buildings etc.), some canals aren't for navigation/boats (I
know of one used to supply a fountain by Hampton Court Palace and the
man-made river/canal runs for several miles).
I think l
63 matches
Mail list logo
