Re: [OSM-talk] Mapping Canals

[Steven te Brinke]

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 about feet is that my 6.5 meter boat is 22 feet). So I 
really don't like it to specify units in feet and hope it will at least 
be possible to use meters.


Steven


Dermot McNally schreef:

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've quoted, and I
can't find it under the links you've provided. But is anybody
suggesting that canals (worldwide) _must_ be measured in feet and
inches? The closest we had come to this in the earlier discussions was
that many felt that it should be _permissible_ to do so, and even then
it was looking like many of the options available were going to be
very messy.

Dermot

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

Re: [OSM-talk] Mapping Canals

[Gervase Markham]

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 
abbreviation, a space, and then optionally a number and "in".

(This is as opposed to <5"4'>, <5 foot 4 inches> or any other of the 
many possible variations.)

Gerv


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

Re: [OSM-talk] Mapping Canals

[Dermot McNally]

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've quoted, and I
can't find it under the links you've provided. But is anybody
suggesting that canals (worldwide) _must_ be measured in feet and
inches? The closest we had come to this in the earlier discussions was
that many felt that it should be _permissible_ to do so, and even then
it was looking like many of the options available were going to be
very messy.

Dermot

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

[OSM-talk] Mapping Canals

[Gervase Markham]

Based on the discussion from a few weeks ago, I've made a number of new 
proposals relating to canals which are now listed on the Proposed 
Features page at the bottom of various categories:

http://wiki.openstreetmap.org/index.php/Proposed_features#Proposed_Features_-_Waterway
http://wiki.openstreetmap.org/index.php/Proposed_features#Proposed_Features_-_Amenities
http://wiki.openstreetmap.org/index.php/Proposed_features#Keys
http://wiki.openstreetmap.org/index.php/Proposed_features/Potable_Water
http://wiki.openstreetmap.org/index.php/Proposed_features/Lock
[David Earl: do shout if you think I've butchered your Lock proposal.]

My own draft Right Way of Doing Things, which incorporates the 
proposals, is below for your reference.

Gerv



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".

Canals
--

Canals are denoted by a single way (rather than two banks), whose 
direction is irrelevant except in the case of locks or significant water 
flow.

The entire section of canal (between two junctions) is tagged with 
maxlength and maxwidth, representing the largest boat which can travel 
along that section of the canal.

Narrow sections are denoted by "narrows=yes". Bridge holes are implied 
narrow, and don't need explicit marking.

Cuttings and embankments are shown only when they apply to both sides of 
the canal, in which case the relevant part of the way has "cutting=yes" 
or "embankment=yes". (This is a slight simplification compared to 
existing maps.)

Winding holes are marked as nodes in the canal with 
"waterway=turning_point"; the max length of boat which can be winded is 
denoted using "maxlength" on the node, even though this is a small 
stretch of the meaning.

"access=private" is used for "private" parts of the canal (that is, 
parts which are not accessible to all licensed boaters). "boat=private" 
is deprecated.

Canals are, by default, level=0 (i.e. no level tag).

If not operated by BW, indicate operator using "operator=Foo Corp".

Locks
-

(See wiki page: 
http://wiki.openstreetmap.org/index.php/Proposed_features/Lock)

The wiki page makes some good points, but I suggest we have *both* 
"waterway=lock_gate" on nodes (useful for large locks, optional for 
small ones) and "lock=yes" on canal/river ways (compulsory, easy to render).

The "lock=yes" way(s) points from the higher to the lower end of the 
lock, i.e. in the direction of water flow. So the lock "arrow" symbol 
would point in the opposite direction.

The "lock=yes" way(s) takes various lock-related information, including:

- the lock name, if it has one, with "name=".
   XXX clash with waterway name?
- the maxwidth, with "maxwidth=Xft Yin".- the maxlength, with 
"maxlength=Xft Yin".
- the rise, with new tag "rise=Xft Yin".

A flight of locks with a unifying name (e.g. "Hatton Locks") is denoted 
by a relation. XXX need more detail

Moorings


Mooring info should be attached to the relevant stretch of towpath, or 
to a new dedicated way on the opposite side, for the rare offside 
moorings. "mooring=yes/private/no" should be used, applied to ways 
rather than nodes. Only explicitly marked mooring conditions should be 
shown. Renderers may choose to render the way as an icon placed at the 
centre of the length.

"waterway=mooring" is deprecated, to be replaced with the above, as it's 
not an actual waterway receiving the tag. (We couldn't tag the canal 
itself this way anyway, as it's already "waterway=canal".)

New tag: maxstay=. Overnight is "1". This is applied to all of the 
way(s) tagged with "mooring=yes".

If the mooring must be paid for, add "cost=paid"
http://wiki.openstreetmap.org/index.php/Proposed_features/Price_tags

Aqueducts
-

waterway=aqueduct is replaced with aqueduct=yes (and we probably should 
make the same change for viaducts), and should be used just like a 
bridge tag.

Bridges
---

New tag: ref_bridge= for bridge numbers.

New tag: bridge_type=manual_swing, powered_swing, 

Towpaths


The towpath is shown as another way alongside the canal, on the 
appropriate side, with new tag "towpath=yes". It is continuous as long 
as the towpath is; if the towpath switches sides, the way connects into 
the relevant bridge, which also has "towpath=yes".

Nodes which are part of the path can take info like water_point, etc. 
Like any path, it can take quality and access tags.

Mile markers are denoted as towpath nodes with new tag value: 
"distance_marker=/yes".
http://wiki.openstreetmap.org/index.php/Proposed_features/Distance_Marker

Amenities
-

Some changes for consistency:
Change: waterway=waste_disposal -> amenity=waste_disposal
Change: waterway=water_point -> amenity=drinking_water
http://wiki.openstreetmap.org/index.php/Proposed_features/Potable_Water

Make sure amenity=waste_disposal is clearly defined as a refuse point.

New tag value: amen

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 to allow all of <15'0">, <15ft 
0in>, <15 feet 0 inches> and so on. The info in the database is not and 
should not be designed to be rendered directly, either on maps or in 
routing software, and so does not have to correspond to what's written 
on the sign. If the database says "30mph", that might be rendered as 
"30", or as a white circle with a red border with a "30" in it, or even 
as the same with a "50" in it, if the person using the software or map 
wants km/h.

> We need for the UK to keep imperial measurements in the DB.  Now, I 
> abhor imperial measurements and want to see us completely metricated, so 
> please don't mistake me for some kind of rabid anti-metric person.  But 
> the signs say things in feet and inches and that is a fact.  This 
> discussion should not be about a bunch of non-UK people declaring that 
> UK people aren't allowed to use the unit system the UK (regrettably) 
> uses in the database, 

I'm a UK person, and (at least up to now) I've been declaring that UK 
people shouldn't be allowed to use the unit system the UK uses. :-)

> There are many options.  I think defining a very small set of allowed 
> units and formats thereof, and then sample code in many languages to 
> convert these to metres/kilograms, might be the solution.

That might work. But then, don't you lose some of the flexibility that 
the "put the units into the DB" crowd are asking for? As has been shown, 
there's no loss of precision in going all-metric, at least with lengths, 
because 1 inch is exactly 2.54cm.

Gerv


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

Re: [OSM-talk] Mapping canals

[Andy Robinson (blackadder)]

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 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 many decades)
>

Of course! Clearly a moment of dickey finger followed by a lack of QC/QA!

Thanks for spotting.

Cheers

Andy

>
>I vote for what Stephen Gower (etc) said, keep the user-edited tags
>"dirty".  Friendly active mappers are the limiting resource.
>
>The thousand separator sounds daft to me, but if we're calling the user-
>edit field "dirty" and putting it in there, it's not actually a problem,
>even if it is daft.
>
>Tom
>
>
>
>___
>talk mailing list
>talk@openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk


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

Re: [OSM-talk] Mapping canals

[Tom Evans]

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 many decades)


I vote for what Stephen Gower (etc) said, keep the user-edited tags "dirty".  
Friendly active mappers are the limiting resource.  

The thousand separator sounds daft to me, but if we're calling the user-edit 
field "dirty" and putting it in there, it's not actually a problem, even if it 
is daft.

Tom



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

Re: [OSM-talk] Mapping canals

[Andy Robinson (blackadder)]

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
>>   * 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 which the measurement is displayed in the real world
>> (i.e. the evidence, signs etc)
>
>And a third, which might sound obscure but is actually a big issue
>when we get back to canals:
>
> * The specification of the measurement
>
>A UK narrow lock is 7ft wide. It isn't 2.14m wide.
>
>It sounds like nit-picking, but I've just typed "2.14" in because I'd
>memorised that as narrowboat-width-in-metres and that's what some of
>the brokers put in their ads.
>
>If you quote 7ft to 2 significant figures, it's 7ft. If you quote
>2.14m to 2 significant figures, it's 2.1m. There are narrowboats out
>there which will get through a 2.14m lock but not a 2.1m lock. There
>are locks (on the Chesterfield Canal) which have actually been
>built/restored too narrow because of measurement-cluelessness on the
>part of the contractors. It does happen.
>
>(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 which produces
2.1336m or 2.134m if you round to the nearest millimetre.

7ft or 7' is so much simpler in this instance :-)

>Whether or not the maxwidth tag accepts measurements in feet is
>probably something that'll eventually be decided by renderer, routing
>app and editor authors, but there is certainly a need for the "7ft" to
>be recordable in the db.
>


Cheers

Andy


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

Re: [OSM-talk] Mapping canals

[Richard Fairhurst]

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 which the measurement is displayed in the real world
> (i.e. the evidence, signs etc)

And a third, which might sound obscure but is actually a big issue  
when we get back to canals:

 * The specification of the measurement

A UK narrow lock is 7ft wide. It isn't 2.14m wide.

It sounds like nit-picking, but I've just typed "2.14" in because I'd  
memorised that as narrowboat-width-in-metres and that's what some of  
the brokers put in their ads.

If you quote 7ft to 2 significant figures, it's 7ft. If you quote  
2.14m to 2 significant figures, it's 2.1m. There are narrowboats out  
there which will get through a 2.14m lock but not a 2.1m lock. There  
are locks (on the Chesterfield Canal) which have actually been  
built/restored too narrow because of measurement-cluelessness on the  
part of the contractors. It does happen.

(Actually, on checking with a calculator, 7*12*2.54=213.36. So I'm  
doing a bit of unconscious rounding already.)

Whether or not the maxwidth tag accepts measurements in feet is  
probably something that'll eventually be decided by renderer, routing  
app and editor authors, but there is certainly a need for the "7ft" to  
be recordable in the db.

cheers
Richard


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

Re: [OSM-talk] Mapping canals

[Robert (Jamie) Munro]

-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 need to understand the units they want to
| render on the map, and are capable of converting values in a single
| standard unit into that rendered unit and rounding appropriately:
| 48.28 -> 29.999mph -> "30mph"
|
| 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"
| 73000furlongsperfortnight -> 27.16kph -> "28kph"

The complete list of allowed units for speed is:

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

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

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

km and miles might turn up somewhere, but I can't think where - normally
measures of that scale will be directly in the data by calculating great
circle distances or whatever.

It's really not that much to consider, and it's not that much that
actually has to consider it - as others have said, most renderers can
just print the information as is to the user, and don't need to convert it.

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

iD8DBQFHmKy1z+aYVHdncI0RAtSFAKC/ST9Cyx82MeofkvyNRkX4bB06uACg7bth
BxtM0ITj+TU63vhBHG0AhOg=
=HIqG
-END PGP SIGNATURE-

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

Re: [OSM-talk] Mapping canals

[Jo]

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 the normalised
>>> equivalent.
>>>
>>>   
>> This is what I was thinking all along. On the one hand you want the info
>> as it is indicated in situ. On the other hand you want to be able to
>> parse it efficiently. A second field seems like the most obvious
>> solution. Maybe name spaced: maxheight:imperial = 3 ft.
>>
>> Polyglot
>> 
>
> Or
>
> 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
>
> That is the sort of conclusion I've been coming to with the is_in 
> tag.  It is useful to have an easy to remember but fairly free-form 
> tag to capture mass observations and then gain extra value from it by 
> by post-processing and name-spacing for more systematic/rigorous 
> catagorisation.
>   
The problem with that approach is that all values need maxheight:metric 
values, the ones that already were metric included. The way I proposed 
it all values will end up being metric and where needed an extra value 
would be present with the imperial, klingon, etc units

Polyglot

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

Re: [OSM-talk] Mapping canals

[Jo]

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 existing key) or for the normalised
>>> equivalent.
>>>
>>>   
>> This is what I was thinking all along. On the one hand you want the info
>> as it is indicated in situ. On the other hand you want to be able to
>> parse it efficiently. A second field seems like the most obvious
>> solution. Maybe name spaced: maxheight:imperial = 3 ft.
>> 
>
> I'll make two comments on this whole thing:
>
> 1) Processing power should be considered infinite, and contributor
> time not so. Make it as easy as possible for the contributor, so long
> as we can deterministically post-process it somehow.
>
> 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 which the measurement is displayed in the real world
> (i.e. the evidence, signs etc)
>
> So for the first, 30mph and 48 kph are the same thing. For the second,
> they are completely different. You can divide everyone who is
> discussing this issue by which of those two facets they deem more
> important.
>
> Some people only want to record the former (the folks doing routing,
> mainly). Some people want the latter stored too. The latter means that
> 5'6" and 5.5ft are two completely different things, but to someone
> dealing with the former will think they are the same (and probably
> argue for metric too).
>
> I don't care. I've yet to tag either, nor use either for rendering,
> but people should bear these two things in mind when discussing them
> and proposing ideas.
>
> Cheers,
> Andy
>   
I agree that the mappers can enter whatever they want. Then post 
processing can locate non-SI units and create the separate field with 
this entry and a calculated field with the unit converted to the SI 
unit. In a real DB like PostgreSQL this could be done on the fly in a 
stored procedure triggered upon insertion or update.

Polyglot

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

Re: [OSM-talk] Mapping canals

[Michael Collinson]

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 is what I was thinking all along. On the one hand you want the info
>as it is indicated in situ. On the other hand you want to be able to
>parse it efficiently. A second field seems like the most obvious
>solution. Maybe name spaced: maxheight:imperial = 3 ft.
>
>Polyglot

Or

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

That is the sort of conclusion I've been coming to with the is_in 
tag.  It is useful to have an easy to remember but fairly free-form 
tag to capture mass observations and then gain extra value from it by 
by post-processing and name-spacing for more systematic/rigorous 
catagorisation.

Mike
Stockholm



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

Re: [OSM-talk] Mapping canals

[Andy Allan]

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
> > equivalent.
> >
> This is what I was thinking all along. On the one hand you want the info
> as it is indicated in situ. On the other hand you want to be able to
> parse it efficiently. A second field seems like the most obvious
> solution. Maybe name spaced: maxheight:imperial = 3 ft.

I'll make two comments on this whole thing:

1) Processing power should be considered infinite, and contributor
time not so. Make it as easy as possible for the contributor, so long
as we can deterministically post-process it somehow.

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 which the measurement is displayed in the real world
(i.e. the evidence, signs etc)

So for the first, 30mph and 48 kph are the same thing. For the second,
they are completely different. You can divide everyone who is
discussing this issue by which of those two facets they deem more
important.

Some people only want to record the former (the folks doing routing,
mainly). Some people want the latter stored too. The latter means that
5'6" and 5.5ft are two completely different things, but to someone
dealing with the former will think they are the same (and probably
argue for metric too).

I don't care. I've yet to tag either, nor use either for rendering,
but people should bear these two things in mind when discussing them
and proposing ideas.

Cheers,
Andy

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

Re: [OSM-talk] Mapping canals

[Jo]

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 one hand you want the info 
as it is indicated in situ. On the other hand you want to be able to 
parse it efficiently. A second field seems like the most obvious 
solution. Maybe name spaced: maxheight:imperial = 3 ft.

Polyglot

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

Re: [OSM-talk] Mapping canals

[Dermot McNally]

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 maxheight=15'0" needs to
be interpreted somewhere.

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.

Dermot

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

Re: [OSM-talk] Mapping canals

[Michael Collinson]

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 pre-calculation (that is what a computer is 
for). If that makes the database slightly less elegant or processing 
slightly more complex, that is a sacrifice worth making.


Mike
Stockholm

At 01:00 PM 1/24/2008, Abigail Brady wrote:
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 says, that should be 
represented in the database.


We need for the UK to keep imperial measurements in the DB.  Now, I 
abhor imperial measurements and want to see us completely 
metricated, so please don't mistake me for some kind of rabid 
anti-metric person.  But the signs say things in feet and inches and 
that is a fact.  This discussion should not be about a bunch of 
non-UK people declaring that UK people aren't allowed to use the 
unit system the UK (regrettably) uses in the database, but instead 
it should be how this can be best done in a way that tools don't get 
too confused by.


Please let us have that conversation.  The idea of a cron job is 
slightly absurd but nontheless is a thought in the right 
direction.  There are many options.  I think defining a very small 
set of allowed units and formats thereof, and then sample code in 
many languages to convert these to metres/kilograms, might be the solution.


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

Re: [OSM-talk] Mapping canals

[Abigail Brady]

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 says, that should be represented in the
database.

We need for the UK to keep imperial measurements in the DB.  Now, I abhor
imperial measurements and want to see us completely metricated, so please
don't mistake me for some kind of rabid anti-metric person.  But the signs
say things in feet and inches and that is a fact.  This discussion should
not be about a bunch of non-UK people declaring that UK people aren't
allowed to use the unit system the UK (regrettably) uses in the database,
but instead it should be how this can be best done in a way that tools don't
get too confused by.

Please let us have that conversation.  The idea of a cron job is slightly
absurd but nontheless is a thought in the right direction.  There are many
options.  I think defining a very small set of allowed units and formats
thereof, and then sample code in many languages to convert these to
metres/kilograms, might be the solution.

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

Re: [OSM-talk] Mapping canals

[Martijn van Oosterhout]

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 expected to support it. Google does,
but we shouldn't expect every OSM user to be able to duplicate that
feat. (It's 50km/h in case you're wondering). At the very least can we
agree that it should be one (1) floating point number (no scientific
notation) with one (1) unit. That brings it back to something
feasable.

I'm also worried about people using gauges adding 5ft 5in somewhere,
we should at least require decimals.

Have a nice day,
-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

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

Re: [OSM-talk] Mapping canals

[Nick Dyer]

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 locks, or the depth). If you translate these 
values to metres as they enter the database you are throwing away data. 
In addition, it goes against the idea that the database should represent 
the actual situation on the ground rather than something that makes it 
easy to process.

And as has been mentioned, this isn't a new problem for OSM: the 
maxspeed tag already carries values in mph - see 
http://wiki.openstreetmap.org/index.php/Talk:Map_data_Structure_Modelling 
for a subset of the discussion we are having here.

In case you're worried about all these units making the database bigger, 
it's worth noting that the string "72ft" is still shorter than "21.9456".

Nick


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

Re: [OSM-talk] Mapping canals

[Andy Robinson (blackadder)]

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 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 another example of why allowing people to use any unit
>"as long as they label it" is a bad idea :-)
>

Google and other data users are provided with their data in detailed and
specified formats by external contractors. They know at the outset what the
units for a given data set are. Thus it's relatively easy for them to
provide a response to users with any suitable conversion they wish.

You could decide on a strict set of tags for OSM and use these to define
certain attributes. That’s fine for making it easier to code and deliver
reliable data to users but absolutely useless if this precisely formatted
data doesn’t exist in the database, and that’s the reality we face.

Contributors of data to OSM are not professionals working to a strict code
of practice, so we can never guarantee that general contributions will be in
metric, imperial or wigets. If a group of OSMers wish to set up a strict
standard following process then that’s fine but of course it's going to be
limited to small amounts of data and small geographical areas.

The alternative is to accept the limitations of the model and work out ways
of using what data exists in a flexible way. If the units are given then
it’s a doddle (even if the form varies), if no units are given then it is
most likely the unit implied is the convention for the location (eg miles
for UK, USA or km for rest of Europe etc).

OSM will always need smart and sophisticated processing. 

Cheers

Andy


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

Re: [OSM-talk] Mapping canals

[David Earl]

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&sourceid=navclient&gfns=1&q=30mph+in+kph
> 
> So this is just another example of why allowing people to use any unit 
> "as long as they label it" is a bad idea :-)

'use any unit "as long as they label it" ' seems to be in line with 
(some people's) philosophy of tagging - use any tag you like, and it'll 
eventually converge to some kind of concensus.

Indeed, that being the case, people *will* and probably *have already* 
put units into these kind of tags, so chances are units are defacto part 
of OSM tags.

If CSS can do it, I don't see why OSM can't get to grips with units. 
It's not hard to process a unit string after a number. And there's no 
reason why such processors can't recognise variations either: km/h, 
kmh-1, kph; mph m.p.h. etc. because if there is no syntax check you can 
be sure every variation you can think of and many you can't will arise.

David


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

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 another example of why allowing people to use any unit 
"as long as they label it" is a bad idea :-)

Gerv


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

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 the database in metric units. If you want to 
render a UK map in imperial, you do the following:

maxspeed_mph = round_to_nearest_5mph(maxspeed * 0.6214);

Gerv


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

Re: [OSM-talk] Mapping canals

[Dermot McNally]

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 value in the "normalised" field. But in
the bulk of cases it will work just fine.

Dermot

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

Re: [OSM-talk] Mapping canals

[Robert Vollmert]

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 to Amarillo - and a 30 sign as you
> entered a 30 area (not a 52.12345 sign).

How about an extra key maxspeed:source_value_with_unit=30mph and a  
cron job that updates maxspeed from maxspeed:source_value_with_unit?

Cheers
Rob


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

Re: [OSM-talk] Mapping canals

[Dermot McNally]

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 way to Amarillo - and a 30 sign as you
> entered a 30 area (not a 52.12345 sign).

I agree that we need to be able to show that 30 sign. It seems to me
that we _also_ need to be able to show 50 (or 52, or maybe even
52.12345) to users who've chosen to navigate in km. In the case of the
specific example, you'd need to offer that choice, since most of the
world drives cars with no mph on the speedo scale. So whatever
standard we adopt, we'll need to allow renderers to grok the numbers
well enough to do units conversion, and that's whether or not we
decide that it's valid for the DB to store string-with-unit.

Dermot

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

Re: [OSM-talk] Mapping canals

[matthew-osm]

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 of something else I meant to add, which you've
>   partically gone into here - nto all "sanitary_stations" are equal. 
>   You've mentioned some difference, but even with pumpout there's the
>   question of if it's self-operated or not.

  amenity=sanitary_station
  shovel=provide_your_own

-- 
Matthew

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

Re: [OSM-talk] Mapping canals

[David Earl]

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?

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 to Amarillo - and a 30 sign as you 
entered a 30 area (not a 52.12345 sign).

David


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

Re: [OSM-talk] Mapping canals

[Martijn van Oosterhout]

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 see mountain heights in metres, speeds in km/h and canal
> lock rises in metres (regardless what country they're in) because
> those are the units that make sense to me. Up until now, all such
> units have, by OSM convention, been stored in metric units, which
> obviously suits me just fine.

I think it should also be remembered that metric users outnumber
non-metric users by about 19:1 and between imperial users they can't
agree on everything (when is a pound not a pound). If we are going to
go down this path then we should setup a list of officially permitted
non-SI units with designated unit name (so we don't get confusion
about 1foot or 2feet), whether "10ft 7 7/16in" is allowed (exercise:
write a quick parser for that). Is it case sensetive? Not just
claiming it's "standard" (the nice thing about standards is that
there's so many to choose from).

We could mandate that mph is the only exception, but if we're going to
allow exceptions we should list them, because as you can see from the
foot example, it's not just multiplying by a factor, you need a parser
for some things.

Have a nice day,
-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

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

Re: [OSM-talk] Mapping canals

[Dermot McNally]

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 database.

Divergence from the convention doesn't mean there isn't one. I wasn't
aware of the fact that there are imperial measures in there, but IMO
it's a needless complication and it goes against Mapfeatures.

>
> TBH I don't see the difficulty in those few clients which need to use
> speed/width information adding these three lines of code:
>
> if ($is_measurement{$key} and $tag{$key}=~/(\d+)\s*(.+)/) {
>$tag{$key}=$1*$conversion_factor{$2};
> }

Needless complexity. These are physical quantities that can be and
should be stored as raw numbers using consistent units, just as we
have settled on lat/long and the Gregorian calendar for dates. And
your conversion table is going to get nice and complex when it turns
out that every imperial fan has a different idea of the right unit
notation for each unit. Madness. There's no easier way of making these
fields useless to the consumers of the map data.

> But then, I'm the author of an editor rather than a routing client, so
> I would say that. :)

Right enough - I know that my proposed solution to the problem dumps
it on you guys, but at least that minimises the pain rather than
spreading it widely throughout the database.

Dermot

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

Re: [OSM-talk] Mapping canals

[Richard Fairhurst]

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 need to use  
speed/width information adding these three lines of code:

if ($is_measurement{$key} and $tag{$key}=~/(\d+)\s*(.+)/) {
   $tag{$key}=$1*$conversion_factor{$2};
}

given the already vast amount of processing they'll need to do to OSM  
data for their purposes. (Theoretically this should be in a standard  
OSM library but AFAIK these are at their early stages.)

But then, I'm the author of an editor rather than a routing client, so  
I would say that. :)

cheers
Richard


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

Re: [OSM-talk] Mapping canals

[Dermot McNally]

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 it need to?

Because a render should be trying to portray the value in a manner
useful to the map user, not in the manner favoured by the mapper. If
speed limit data becomes a string whose value can't be compared to all
others then we will have lost functionality.

Dermot

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

Re: [OSM-talk] Mapping canals

[Sven Grüner]

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"
> 73000furlongsperfortnight -> 27.16kph -> "28kph"

Just to mention:
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*.
AFAIK is "kph" an expressession from American English. And since the
folks over there aren't experts on the metric system ;-) you should be
careful joining their terminology.

just my 2ct,
Sven

Ps: KiloPerHour also wouldn't make much sense as well. That could be
thousand grams, volts, rabbits, everything.

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

Re: [OSM-talk] Mapping canals

[Dermot McNally]

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 had to come to terms with the
fact that the same city can be called München, Munich, Monaco etc. OSM
precedent allows us to ensure that our dataset will allow rendering of
whichever version or versions we choose, though the default renderer
currently only uses one of them. This is a clean treatment of data
that works for everyone.

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 see mountain heights in metres, speeds in km/h and canal
lock rises in metres (regardless what country they're in) because
those are the units that make sense to me. Up until now, all such
units have, by OSM convention, been stored in metric units, which
obviously suits me just fine.

This doesn't alter the fact that a bunch of OSM users (and I'm
thinking particularly of those wacky Americans among us :) ) would
prefer to use other units. This option is open to them by taking
repeatable transformations of the data already stored, and we must
assume that there will at some stage be parallel rendering projects to
give these users what they want to see.

IMHO, feet, inches and miles belong no more in OSM data than UK
National Grid references. They can readily be extracted from the
standard units stored, but there should _be_ a standard, and
established OSM practice (as well as common sense) says that the units
to use are metric. Trying to have renderers and other processors grok
unit suffixes which will be mis-spelt half the time (standard notation
not being a strong point of the old units) is just daft. Forcing
mappers to work in non-round figures is also, I admit, not ideal, but
this is something that can readily be fixed at editor level.

On 22/01/2008, Gervase Markham <[EMAIL PROTECTED]> wrote:

> 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 converting values in a single
> standard unit into that rendered unit and rounding appropriately:
> 48.28 -> 29.999mph -> "30mph"

This is inevitable - as long as there are people who'd like to see the
height of the Zugspitze in feet or of Ben Nevis in metres. So even in
a world where we store all data internally in metric units (today's
world, which I'm advocating we not tamper with) there is both the need
and the possibility to render alternative units from the base data.

> 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"
> 73000furlongsperfortnight -> 27.16kph -> "28kph"
>
> I opt for 1). I think it's reasonable to ask renderers to know about
> units they want to render. I don't think it's reasonable to ask them all
> to know about all possible units anyone might want to stick in the database.

I agree. Let's fix this at the data output, not the input.

Dermot

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

Re: [OSM-talk] Mapping canals

[80n]

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 need to understand the units they want to
> render on the map, and are capable of converting values in a single
> standard unit into that rendered unit and rounding appropriately:
> 48.28 -> 29.999mph -> "30mph"
>
> 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"
> 73000furlongsperfortnight -> 27.16kph -> "28kph"
>

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?

Route planners, on the other hand, would need to be able to do some
conversion in order to calculate journey times and find the quickest
routes.  But there again average speeds might be more useful than speed
limits in this case.

Etienne




>
> I opt for 1). I think it's reasonable to ask renderers to know about
> units they want to render. I don't think it's reasonable to ask them all
> to know about all possible units anyone might want to stick in the
> database.
>
> Gerv
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 converting values in a single 
standard unit into that rendered unit and rounding appropriately:
48.28 -> 29.999mph -> "30mph"

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"
73000furlongsperfortnight -> 27.16kph -> "28kph"

I opt for 1). I think it's reasonable to ask renderers to know about 
units they want to render. I don't think it's reasonable to ask them all 
to know about all possible units anyone might want to stick in the database.

Gerv


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

Re: [OSM-talk] Mapping canals

[Stephen Gower]

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), 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 of something else I meant to add, which you've
  partically gone into here - nto all "sanitary_stations" are equal. 
  You've mentioned some difference, but even with pumpout there's the
  question of if it's self-operated or not.
  
  s


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

[OSM-talk] Mapping canals

[Richard Bullock]

>And what is the exact SI equivalent of 30mph?
>I can give you an approximation: 48.28032km/h.
>What happens though if everyone sticks in 48 instead.. close enough isn't
>it?

Nitpicking, but 48.28032 km/h *is* exact.

Although in the usual SI unit, 30 mph would be 13.4112 m/s (exactly).

Richard B


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

Re: [OSM-talk] Mapping canals

[Dave Stubbs]

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; whereas if
> we standardised on metres, then all renderers would render all values.
>


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?

Fixing the renderer is relatively simple.
The problem is that the world hasn't standardised on km, and it probably
won't anytime soon.

So yeah, take your pick, but personally I'd prefer correct data.
We can of course add another tag, either a tag for a km equivalent value, or
a tag for the actual value with units, but I can't imagine many people will
bother to fill this in.

Dave
(last post on this subject)
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Mapping canals

[Dave Stubbs]

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 if everyone sticks in 48 instead.. close enough
> > isn't it?
>
> If the UK Department for Transport ever finally get around to finishing
> the
> metrication project that has been going on since 1862. then 30mph will
> probably become 50km/h, 60 would become 100km/h, 70mph would become either
> 110km/h or 120km/h (it's already been lowered, and has become 100km/h for
> buses, which now need speed limiters set to 100km/h).
>

That's all a pretty good explanation of why we need to be adding mph units
to keep the data sane!

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

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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.

Gerv


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

Re: [OSM-talk] Mapping canals

[Simon Hewison]

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 finally get around to finishing the 
metrication project that has been going on since 1862. then 30mph will 
probably become 50km/h, 60 would become 100km/h, 70mph would become either 
110km/h or 120km/h (it's already been lowered, and has become 100km/h for 
buses, which now need speed limiters set to 100km/h).

-- 
Simon Hewison

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

Re: [OSM-talk] Mapping canals

[Andy Robinson (blackadder)]

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.
>>
>> (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 tolerances. On the UK canals, every
>inch counts in lock length. There are locks that our 71ft 6in boat
>won't get through, but would if it were a few inches shorter. And
>there's no way my OSM skills are l337 enough to be able to draw a way
>precisely 71ft 6in long.
>

Well, we could if we had some basic geometry tools in the editors :-)

Cheers

Andy

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


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

Re: [OSM-talk] Mapping canals

[Richard Fairhurst]

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 tolerances. On the UK canals, every  
inch counts in lock length. There are locks that our 71ft 6in boat  
won't get through, but would if it were a few inches shorter. And  
there's no way my OSM skills are l337 enough to be able to draw a way  
precisely 71ft 6in long.

cheers
Richard


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

Re: [OSM-talk] Mapping canals

[matthew-osm]

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 at the
same time, but it's still a bit close IMO.)
 
Cheers,

-- 
Matthew

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

Re: [OSM-talk] Mapping canals

[Dave Stubbs]

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 this - up till now, these fields were assumed to
> contain pure numbers, with the ease of processing that this implies. I
> know that in an imperial world, it's not so convenient to use a figure
> like 2.14 when you're trying to represent what could be a round
> number. But to introduce the possibility of there being units in these
> fields (and the requirement to arbitrate those units when processing)
> smacks to me of dirty data.
>


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.
If there was no unit you assume metre, and then you convert to whatever unit
you happen to be using.
It's not dirty, it's just correct.



> Is there not a nicer middle ground here? I'm thinking of some kind of
> editor support that would treat units like 'mph', 'ft' or whatever as
> macros that instantly transform any submitted value into the database
> internal SI equivalent before submission?
>

And what is the exact SI equivalent of 30mph?
I can give you an approximation: 48.28032km/h.
What happens though if everyone sticks in 48 instead.. close enough isn't
it?

Does the difference matter? Probably not for a lot of data uses, but if
you're trying to avoid dirty data then you should avoid this kind of forced
approximation.

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

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 maxlength and maxwidth,  
> then, there is no need to tag bridges, and lock nodes, with maxlength  
> and maxwidth: this is implied.

So you are suggesting we tag the entire canal way with these things, 
instead of the individual parts and features? That does make sense. I 
don't particularly want to measure every lock.

> can be). The channel will typically be more than twice this width. So  
> we need a way of tagging the exceptions - places where only one boat  
> can proceed at once. Something simple like "narrows=yes" would work,  
> or maybe "channel_width=7ft".

narrows=yes is normally all that maps show, and any width measurement 
would be a guesstimate anyway. Do you think that would be sufficient?

>> "boat=private" is used for private parts of the canal.
> 
> In Britain, at least, all canals are essentially private. There is no  
> public right of navigation on canals. I see what you're saying, but  
> the terminology will need to be made explicit on the wiki page.

Fair point.

>> The wiki page makes some good points, but I suggest we have *both*  
>> "waterway=lock_gate" on nodes (useful for large locks, optional for  
>> small ones) and "lock=yes" on canal/river ways (compulsory, easy to  
>> render).
> 
> I still strongly recommend that lock=yes is optionally applicable to  
> nodes (and whatever the wiki decides, that's how I'll tag). 

How does that interact with the lock_gate tag? Are you just arguing for 
a minimalist way of tagging locks, with a single node in the waterway 
with "lock=yes" plus any and all ancillary info attached? Or have I 
misunderstood you?

> It will  
> make editing _so_ much easier than tagging up countless little ways up  
> the Tardebigge Flight would, and there is no loss of meaning.

No-one's saying _you_ have to do this if you don't want to. :-)

> (In fact, tagging a lock as a way could be misleading. For a UK 70ft  
> lock, the length of the way will typically not be the length of the  
> lock, unless your GPS is really accurate. Elsewhere, locks are  
> generally bigger, and the way approach makes more sense.)

Any GPS can distinguish two points 70ft apart, can't they?

> The same tags can still apply to the node, and the direction is  
> inherited from that of the canal.

Isn't there an issue with this directional inheritance, as explained on 
the wiki page - the renderer has to have special knowledge about which 
way passing through the "lock" node is actually the canal.

> Mooring is on the water so I'd submit it makes more sense to tag the  
> waterway, not the towpath - not least for routing purposes. The side  
> could be indicated by mooring=offside or mooring=towpath.  

I couldn't work out how to do this well; your solution has promise :-). 
Would problems arise when there was mooring both sides, perhaps with 
different restrictions? How would this work for canals without towpaths?

>> Bridges
>> ---
>> New tag: ref_canal_bridge= for bridge numbers.
> 
> Just ref_bridge. Some river navigations have bridge numbers, and I  
> wouldn't be too surprised if a few railways did.

The reason I went for ref_canal_bridge is that I was concerned about 
what would happen if a particular bridge had two refs - one allocated by 
the thing passing underneath, and one by the thing going over the top! 
For example, all railway bridges (I believe) have a ref; some of them 
even have them written on in case of a bridge strike. There's such a 
bridge near me. If a canal passed underneath instead of a road, such a 
bridge would have two refs.

But perhaps this is rare enough for us not to need to care.

>> Amenities
>> -
>> New tag value: amenity=sanitary_station
> 
> Sanitary station is a really misleading (but sadly widespread) term.  

If it's misleading, then we can pick a better name. If people want maps 
saying "Sanitary Station", the renderer can translate.

> Better to group all the constituent services  
> (amenity=pumpout;water_point), 

BTW, is there a technical limitation which prevents keys having multiple 
values on an object? Or is that entirely possible, and the above is just 
how you write it? Or is the above the workaround for the limitation? Is 
there any agreement on separator character?

> 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.

Elsan's a brand name, so probably best avoided. amenity=excrement_disposal?

> We have a convention that metric units are used unless you explicitly  
> specify otherwise... but you _can_ explicitly specify if you want to.  

How far does this go? Furlongs, firkins and fortnights?

> maxspee

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 boats is 5m. It's not necessary to mark a 
>> two-boat width restriction for bridge holes, which are implied narrow.
> 
>   I don't mind there being an assumption that unspecified units are
>   metres, but the UK canals are done in feet, and if I'm going to put
>   any dimensions in, it'll be in feet, so I'd need a way to specify
>   that's what I'd done.

Richard seems to have chimed in with superior knowledge here, so I'll 
defer to him. Apparently we can use non-metres if we specify.

>> "boat=private" is used for private parts of the canal.
> 
>   I see no reason not to use access=private, myself, since the
>   towpath can have a seperate access tag.

OK... I picked this up because it's defined on the Map Features page. 
But maybe best practice has moved on since then?

>> The "lock=yes" way(s) takes various lock-related information, including:
>>
>> - the lock name, if it has one, with "name=".
> 
>   since this way is also part of the waterway, name= is already in
>   use for the name of the waterway - we need something else for the
>   lock names.

Good point. Does this problem have analogies with other sorts of way? 
How is it dealt with there?

>> A flight of locks with a unifying name (e.g. "Hatton Locks") is denoted 
>> with a node placed in an appropriately central position with new tag 
>> value "place=lock_flight" and "name=".
> 
>   Better to group them with a relation, I'd have thought.

You may be right. I'm not too up on relations. 

>> Mooring info should be attached to the relevant stretch of towpath [...]
> 
>   On UK canals, mooring is generally allowed everywhere, except where
>   explicity signed otherwise 

This is true. But there is also a need to mark places where mooring is 
explicitly provided for or encouraged. (I'm sure you'd agree.)

> - do we need a tag for
>   mooring-not-allowed?

I think we do. Would it be reasonable to have "mooring=yes" meaning 
"there is explicit mooring here", "mooring=no" meaning "you may not 
moor", and nothing being "well, it's the bank, knock yourself out"? Or 
would that be confusing, given that most other yes/no tags are dual 
state rather than tri-state?

Gerv


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

Re: [OSM-talk] Mapping canals

[Dermot McNally]

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 of processing that this implies. I
know that in an imperial world, it's not so convenient to use a figure
like 2.14 when you're trying to represent what could be a round
number. But to introduce the possibility of there being units in these
fields (and the requirement to arbitrate those units when processing)
smacks to me of dirty data.

Is there not a nicer middle ground here? I'm thinking of some kind of
editor support that would treat units like 'mph', 'ft' or whatever as
macros that instantly transform any submitted value into the database
internal SI equivalent before submission?

Dermot

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

Re: [OSM-talk] Mapping canals

[Richard Fairhurst]

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 over 7  
> feet) is given as 2.5m. Two boats is 5m. It's not necessary to mark  
> a two-boat width restriction for bridge holes, which are implied  
> narrow.

So let's start with the trickiest bit of the whole thing. :)

maxwidth and maxlength are the maximum dimensions for the waterway,  
not the physical dimensions of the channel - because generally,  
maximum dimensions are set by locks and bridges, not by channel size.  
(Some long lock-free sections do have a maxlength dictated by bends:  
the Wolverhampton Level and the Bridgewater spring to mind.)

For the Trent & Mersey Canal (Burton-Middlewich), this would be  
maxlength=72ft, maxwidth=7ft. For the River Rhône it would be... a bit  
bigger.

If you have correctly tagged a waterway with maxlength and maxwidth,  
then, there is no need to tag bridges, and lock nodes, with maxlength  
and maxwidth: this is implied.

maxwidth is therefore the maximum width of a boat to pass along this  
canal (just as maxheight on a road is the maximum height that a truck  
can be). The channel will typically be more than twice this width. So  
we need a way of tagging the exceptions - places where only one boat  
can proceed at once. Something simple like "narrows=yes" would work,  
or maybe "channel_width=7ft".

(The rest of the comments are easier!)

> "boat=private" is used for private parts of the canal.

In Britain, at least, all canals are essentially private. There is no  
public right of navigation on canals. I see what you're saying, but  
the terminology will need to be made explicit on the wiki page.

> Locks
> -
> The wiki page makes some good points, but I suggest we have *both*  
> "waterway=lock_gate" on nodes (useful for large locks, optional for  
> small ones) and "lock=yes" on canal/river ways (compulsory, easy to  
> render).

I still strongly recommend that lock=yes is optionally applicable to  
nodes (and whatever the wiki decides, that's how I'll tag). It will  
make editing _so_ much easier than tagging up countless little ways up  
the Tardebigge Flight would, and there is no loss of meaning.

(In fact, tagging a lock as a way could be misleading. For a UK 70ft  
lock, the length of the way will typically not be the length of the  
lock, unless your GPS is really accurate. Elsewhere, locks are  
generally bigger, and the way approach makes more sense.)

The same tags can still apply to the node, and the direction is  
inherited from that of the canal.

> A flight of locks with a unifying name (e.g. "Hatton Locks") is  
> denoted with a node placed in an appropriately central position with  
> new tag value "place=lock_flight" and "name=".

Agree with Socks that a relation would be good for this.

> Moorings
> 
> Mooring info should be attached to the relevant stretch of towpath,  
> or to a new dedicated way on the opposite side, for the rare offside  
> moorings.

Mooring is on the water so I'd submit it makes more sense to tag the  
waterway, not the towpath - not least for routing purposes. The side  
could be indicated by mooring=offside or mooring=towpath.  
mooring_operator and mooring_price tags may be useful. maxstay is a  
good idea.

> Bridges
> ---
> New tag: ref_canal_bridge= for bridge numbers.

Just ref_bridge. Some river navigations have bridge numbers, and I  
wouldn't be too surprised if a few railways did.

> 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), 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.

Stephen Gower wrote:

>   I don't mind there being an assumption that unspecified units are
>   metres, but the UK canals are done in feet, and if I'm going to put
>   any dimensions in, it'll be in feet, so I'd need a way to specify
>   that's what I'd done.

We have a convention that metric units are used unless you explicitly  
specify otherwise... but you _can_ explicitly specify if you want to.  
So:

maxspeed=110   <-- assumed km/h
maxspeed=70mph <-- unit stated
maxwidth=2.14  <-- assumed metres
maxwidht=7ft   <-- unit stated

>   On UK canals, mooring is generally allowed everywhere

(on the towpath side)

>   except where
>   explicity signed otherwise - do we need a tag for
>   mooring-not-allowed?

Good idea.

Final note: suggest we encourage use of the operator tag for the  
navigation authority: operator=British Waterways, operator=VNF, etc.

cheers
Richard


___
talk mailing lis

Re: [OSM-talk] Mapping canals

[Stephen Gower]

  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 to mark a 
> two-boat width restriction for bridge holes, which are implied narrow.

  I don't mind there being an assumption that unspecified units are
  metres, but the UK canals are done in feet, and if I'm going to put
  any dimensions in, it'll be in feet, so I'd need a way to specify
  that's what I'd done.
 
> "boat=private" is used for private parts of the canal.

  I see no reason not to use access=private, myself, since the
  towpath can have a seperate access tag.
 
> The "lock=yes" way(s) takes various lock-related information, including:
> 
> - the lock name, if it has one, with "name=".

  since this way is also part of the waterway, name= is already in
  use for the name of the waterway - we need something else for the
  lock names.

> A flight of locks with a unifying name (e.g. "Hatton Locks") is denoted 
> with a node placed in an appropriately central position with new tag 
> value "place=lock_flight" and "name=".

  Better to group them with a relation, I'd have thought.
 
> Moorings
> 
> 
> Mooring info should be attached to the relevant stretch of towpath [...]

  On UK canals, mooring is generally allowed everywhere, except where
  explicity signed otherwise - do we need a tag for
  mooring-not-allowed?
 
  Thanks for thinking this through!
  
  s

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

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 denoted by a single way (rather than two banks), whose 
direction is irrelevant except in the case of locks or significant water 
flow.

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 to mark a 
two-boat width restriction for bridge holes, which are implied narrow.

Cuttings and embankments are shown only when they apply to both sides of 
the canal, in which case the relevant part of the way has "cutting=yes" 
or "embankment=yes". (This is a slight simplification compared to 
existing maps.)

Winding holes are marked as nodes in the canal with 
"waterway=turning_point"; the max length of boat which can be winded is 
denoted using "maxlength", even though this is a small stretch of the 
meaning.

"boat=private" is used for private parts of the canal.

Locks
-

(See wiki page: 
http://wiki.openstreetmap.org/index.php/Proposed_features/Lock)

The wiki page makes some good points, but I suggest we have *both* 
"waterway=lock_gate" on nodes (useful for large locks, optional for 
small ones) and "lock=yes" on canal/river ways (compulsory, easy to render).

The "lock=yes" way(s) points from the higher to the lower end of the 
lock, i.e. in the direction of water flow. So the lock "arrow" symbol 
would point in the opposite direction.

The "lock=yes" way(s) takes various lock-related information, including:

- the lock name, if it has one, with "name=".
- the maxwidth, with "maxwidth=". A standard single lock is 
2.2m, a standard double lock 4.4m.
- the maxlength, with "maxlength=". 70ft is 22m.
- the rise, with new tag "rise=".

A flight of locks with a unifying name (e.g. "Hatton Locks") is denoted 
with a node placed in an appropriately central position with new tag 
value "place=lock_flight" and "name=".

Moorings


Mooring info should be attached to the relevant stretch of towpath, or 
to a new dedicated way on the opposite side, for the rare offside 
moorings. "waterway=mooring" should be used, applied to ways rather than 
nodes. Only public (free or rentable) moorings should be shown. 
Renderers may choose to render the way as an icon placed at the centre 
of the length.

Alternative: the arrangement should be as in the following diagram, with 
"waterway=mooring" marked on the two vertical sections of way and all of 
the towpath marked with an = sign. This creates a sort of "area" and 
might make it easier for renderers to determine the extent of the mooring.

--towpath--o==o...
|  |
--canalo--o...


New tag: maxstay=. Overnight is "1". This is applied to all of the 
way(s) tagged with "waterway=mooring".

Aqueducts
-

waterway=aqueduct should be applicable to ways as well as nodes. 
Aqueducts should have "bridge=yes" and an appropriate level=.

Bridges
---

New tag: ref_canal_bridge= for bridge numbers.

New tag: bridge_type=manual_swing, powered_swing, 

Towpaths


The towpath is shown as another way alongside the canal, on the 
appropriate side, with new tag "towpath=yes". It is continuous as long 
as the towpath is; if the towpath switches sides, the way connects into 
the relevant bridge, which also has "towpath=yes".

Nodes which are part of the path can take info like water_point, etc. 
Like any path, it can take quality and access tags.

Mile markers are denoted as towpath nodes with new tag value: 
"man_made=milepost". (This could also be used on roads.)

Amenities
-

Some changes for consistency:
Change: waterway=waste_disposal -> amenity=waste_disposal
Change: waterway=water_point -> amenity=water_point

Make sure amenity=waste_disposal is clearly defined as a refuse point.

New tag value: amenity=pumpout
New tag value: amenity=sanitary_station

Gerv


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

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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
> level-difference. If I understand this correctly is absolute height
> (accuracy) of secondary importance.

The important value is the difference, not the absolute height. But we 
can't use ele, because very often the absolute height (which ele 
represents) is not available, or at least not better than GPS height 
accuracy.

>> - Locks have a maximum width and length, universally measured in feet. 
>> It should be possible to indicate what it is, presumably using maxlength 
>> and maxwidth. Is there a danger of these being rendered with symbols 
>> appropriate only for roads?
> 
> Speaking for my own: I don't see why this should cause interference with
> roads. That must be a dumb routing-algorithm sending cars over canals
> because of such a tag :-)

No, I mean if the symbol on a map for a maxwidth restriction is a red 
circle with a white inside (i.e. a road sign), you might get them on canals.

Perhaps not worth worrying about.

> But please keep in mind that distances and height in OSM are generally
> saved in meters, not in feet. If the british boaters are used to feet
> the renderer would need to convert for their charts.

If metres are the standard, we'll have to use metres and canal map 
renderers will convert.

>> - It is useful to denote the rise/fall of a lock (again, universally 
>> measured in feet). There needs to be a tag for this. We could 
>> appropriate "depth", but it's not actually the depth of the canal.
> 
> Is this the same as level-difference? I'm a landlubber...

Yes.

> We have the ref-tag to store all kinds of IDs. There are extensions like
> int_ref, nat_ref and loc_ref or ncn_ref and so on to tell to which
> network the id belongs. Mybe it would make sense to invent something
> like canal_ref or some kind of abreviation.

Great idea. canal_bridge_ref.

> If you make separate ways for each bank that should suffice. 

You don't make separate ways for each side of most roads; so it doesn't 
make sense to me for the standard way to map canals to be one way for 
each side of the canal.

Gerv


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

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 idea :-) If the tag is defined in m, we'll just 
have to use m, and if English canal maps need to be in feet, then the 
renderer will have to convert.

Gerv


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

Re: [OSM-talk] Mapping canals

[Robert (Jamie) Munro]

-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, whatever tags you design: Make them usable in more countries
| than just the UK. France e.g. has an extensive network of narrow canals
| too. They really use meters not feet in most of the world. Either put
| "ft" or "m" in every tag or make per country defaults.

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.

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

iD8DBQFHkLxWz+aYVHdncI0RAkEsAKCFiNo3skQA5hvzy0RiuZPj0sXMGACfX7d0
sHM+kptixSXvv3ButJXzTFA=
=teN2
-END PGP SIGNATURE-

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

Re: [OSM-talk] Mapping canals

[Bruce Cowan]

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, feet are a bit silly, sorry.
-- 
Bruce Cowan <[EMAIL PROTECTED]>


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

Re: [OSM-talk] Mapping canals

[Martijn Verwijmeren]

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 e.g. has an extensive network of narrow canals
too. They really use meters not feet in most of the world. Either put
"ft" or "m" in every tag or make per country defaults.

Cartinus

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

Re: [OSM-talk] Mapping canals

[Sven Grüner]

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)

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

Re: [OSM-talk] Mapping canals

[Sven Grüner]

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.
(I love that phrase since "loose change" :-)

As you said this is still the start, but you should start by picking
only a couple of your points, use them for mapping, try to render them
on maps specialised for baoters and then use the experience from that to
approach the other "problems".

I will try to point out some existing tags which might do a good start
for that.

> Looking at the Map Features section for waterways, it seems that the 
> amount of detail available is insufficient. Here follows a sampling of 
> issues and queries. Should I make proposals for the following changes?

Generally speaking: yes!

> - waterway=lock_gate might be great for the Manchester Ship Canal, 
> doesn't work so well for narrowboat canals. Locks are 70ft long or less, 
> and marking the upper and lower gates individually seems unnecessary and 
> makes them harder to render. Locks also have names (e.g. "Hatton Bottom 
> Lock") which seems to make them better rendered with nodes.

There's an active proposal for that, join the discussion.

> On the other hand, canals have no direction of water flow (with a couple 
> of exceptions) but locks are directional. So one might want to indicate 
> that by using a short directional way. (But should the way point low to 
> high or high to low?) Or perhaps level tags either side of the lock, but 
> that could interact badly with bridges if this persisted along the 
> canal. (I'd expect the entire canal to have "level=-1" to make creating 
> bridges over it easier.) One might also consider "ele" either side, but 
> accurate data is hard to obtain with a GPS. Is there best practice in 
> this area?

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
level-difference. If I understand this correctly is absolute height
(accuracy) of secondary importance.

> - Locks have a maximum width and length, universally measured in feet. 
> It should be possible to indicate what it is, presumably using maxlength 
> and maxwidth. Is there a danger of these being rendered with symbols 
> appropriate only for roads?

Speaking for my own: I don't see why this should cause interference with
roads. That must be a dumb routing-algorithm sending cars over canals
because of such a tag :-)
But please keep in mind that distances and height in OSM are generally
saved in meters, not in feet. If the british boaters are used to feet
the renderer would need to convert for their charts.

> - Sometimes you have a "staircase lock", where the exit of one is the 
> entrance of another. These need denoting.

The discussion in the locks-proposal are aware of that.

> - It is useful to denote the rise/fall of a lock (again, universally 
> measured in feet). There needs to be a tag for this. We could 
> appropriate "depth", but it's not actually the depth of the canal.

Is this the same as level-difference? I'm a landlubber...

> - waterway=aqueduct should surely be applicable to ways rather than nodes?

pheew... maybe that's to be discussed later

> - waterway=mooring should also be applicable to ways, so that the length 
> of the mooring can be seen. It should be possible to indicate what side 
> of the canal the mooring is on (perhaps by reference to the towpath 
> side?), and any conditions attached to mooring there (usually a maxstay, 
> measured in days, or perhaps a fee).
> 
> - Navigation on canals is done by means of bridge numbers. All bridges, 
> including those between two fields (and so with no associated road) have 
> a number. There needs to be a tag to associate a bridge number with the 
> short "bridge=yes" way.

We have the ref-tag to store all kinds of IDs. There are extensions like
int_ref, nat_ref and loc_ref or ncn_ref and so on to tell to which
network the id belongs. Mybe it would make sense to invent something
like canal_ref or some kind of abreviation.

> - Sometimes bridges which no longer exist (but you can see the remains) 
> have numbers. How could this be denoted?

Just set a node with the ref mentioned above. Maybe there will be a way
in the future to tag no-more-structures as well. There's already
historic=ruins...

> - Some bridges are swing bridges, which means they need to be moved out 
> of the way, by one of various means; these need notating. "bridge_type"?

This cries a new proposal :-)

> - All canals have towpaths. These paths are of varying quality, and this 
> information is useful to walkers and cyclists. The towpath can be on 
> either side. How should the towpath be 

Re: [OSM-talk] Mapping canals

[Andy Robinson (blackadder)]

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
>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 gate was
>> actually marked and so this was helpful on those staircase locks that
>> have more than one gate.
>
>Every lock has more than one gate - at minimum, they have a top gate and
>a bottom gate, and some have two of each. A simple staircase lock has
>two chambers and three gates.
>
>> 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.
>
>:-( Maybe they'll pipe up.
>

I'm sure RichardF will pipe up at some point (he's your man with the
narrowboat). I've also tagged a fair few locks so far. Because this area has
evolved somewhat since we started mapping it is time that we came up with an
improved set of tags for all things on the navigable waterways.

I moved to tagging each (top/bottom) gate some time ago but it was a stopgap
measure (since gates within a staircase are both top and bottom), together
with associated lock info on the way between. I still think its right to map
the individual components as it's much easier to control the rendering and
enables a lot more information to be added about the construction of the
lock. This is of interest on a canal map.


There is the partial proposal at
http://wiki.openstreetmap.org/index.php/Proposed_features/Lock and that's
probably the logical location to set out further ideas.

Cheers

Andy


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


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

Re: [OSM-talk] Mapping canals

[Richard Fairhurst]

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 Waterways World magazine, and I've worked for British Waterways  
(their www.waterscape.com website) in the past. And I draw a lot of  
canal maps for the magazine!

Berto d' Sera (who has a userpage on the wiki) has also expressed  
some interest.


Gervase Markham wrote:

...a lot of good stuff, so I'll spare you the "me too"s. A few  
comments that might be helpful:

> - waterway=lock_gate might be great for the Manchester Ship Canal,
> doesn't work so well for narrowboat canals. Locks are 70ft long or  
> less,
> and marking the upper and lower gates individually seems  
> unnecessary and
> makes them harder to render. Locks also have names (e.g. "Hatton  
> Bottom
> Lock") which seems to make them better rendered with nodes.
>
> On the other hand, canals have no direction of water flow (with a  
> couple
> of exceptions) but locks are directional. So one might want to  
> indicate
> that by using a short directional way. (But should the way point  
> low to
> high or high to low?) Or perhaps level tags either side of the  
> lock, but
> that could interact badly with bridges if this persisted along the
> canal. (I'd expect the entire canal to have "level=-1" to make  
> creating
> bridges over it easier.) One might also consider "ele" either side,  
> but
> accurate data is hard to obtain with a GPS. Is there best practice in
> this area?

I agree that there should be the option of mapping a lock with a  
single node.

Direction can be solved simply by making the way of the canal point  
"downstream" (though there's generally no water flow as such, the  
locks are generally all in the same direction either side of the  
summit level). The Trent & Mersey Canal, for example, heads uphill  
west from the Trent as far as Stoke-on-Trent; it then passes under  
Harecastle Hill in a tunnel; and then continues downhill towards the  
Mersey. 73 locks in all, but just two directions.

For bridges: level=-1 could cause problems with aqueducts. Suggest  
bridges are just level=1 as per usual and the canal, without a level  
tag, is therefore an assumed level=0.

> [some good points snipped]
> - It is useful to denote the rise/fall of a lock (again, universally
> measured in feet). There needs to be a tag for this. We could
> appropriate "depth", but it's not actually the depth of the canal.

"rise" is the standard term.

> - waterway=aqueduct should surely be applicable to ways rather than  
> nodes?

Should be both: an aqueduct can be as long as Pontcysyllte, crossing  
an entire river valley, or just a simple culvert-style construction  
over a stream.

> - All canals have towpaths. These paths are of varying quality, and  
> this
> information is useful to walkers and cyclists. The towpath can be on
> either side. How should the towpath be denoted? As a separate way
> parallel to the canal? What tags should be used?
> ("highway=footway,bicycle=yes")? How should quality be denoted?

Towpaths are generally, but not always, permissive paths where the  
landowner is (for a UK canal) British Waterways. Yes, it should be a  
separate way. Cycling is permitted on some, but not others, so this  
too needs to be expressly tagged.

As for quality, this is a wider need - decent tags for expressing the  
surface of a way and what types of bike it's suitable for.

> - Tunnels often have rules about who can enter and when (e.g. transit
> north beginning between :00 and :15; south between 30: and :45). We  
> have
> "hour_on" and "hour_off" - is that enough? How should such tags be
> applied, given that the restrictions are different in each direction?

I think there's a proposed relation on the wiki which might address  
this.

> - There are "mile markers" along the canal which are useful for
> navigation and as points of reference and interest.

Just nodes, for which we need a tag, I guess. Exactly the same as the  
mileposts that you used to find on UK roads, that you've always found  
on French roads, and that are being introduced on UK motorways and  
some principal roads as well.

cheers
Richard

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

Re: [OSM-talk] Mapping canals

[Gervase Markham]

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 gate was 
> actually marked and so this was helpful on those staircase locks that 
> have more than one gate.

Every lock has more than one gate - at minimum, they have a top gate and 
a bottom gate, and some have two of each. A simple staircase lock has 
two chambers and three gates.

> 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.

:-( Maybe they'll pipe up.

Gerv


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

Re: [OSM-talk] Mapping canals

[David Earl]

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-made river/canal runs for several miles).

The canals I was sailing on in the Irish Republic last summer didn't 
have towpaths. Indeed that was a frustration because you couldn't moor 
just anywhere like you can on the English canals.


> I think locks were changed to nodes rather than ways so the gate was 
> actually marked and so this was helpful on those staircase locks that 
> have more than one gate.

See also
http://wiki.openstreetmap.org/index.php/Proposed_features/Lock
which has been around since I first joined but not moved forward mainly 
due to my not pushing it.

David


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

Re: [OSM-talk] Mapping canals

[Gregory]

"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 locks were changed to nodes rather than ways so the gate was
actually marked and so this was helpful on those staircase locks that have
more than one gate.

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.

-- 
Gregory
[EMAIL PROTECTED]
http://www.livingwithdragons.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Mapping canals

[Gervase Markham]

As people may know, the UK has an extensive system of canals.
http://www.barging.co.uk/barging_construction_files/CanalMap.gif

There are also dedicated canal map books, which give some idea of how 
canal boaters like canals to be mapped.
http://astore.amazon.co.uk/ukcan0b/203-6807830-9647906?%5Fencoding=UTF8&node=3

Looking at the Map Features section for waterways, it seems that the 
amount of detail available is insufficient. Here follows a sampling of 
issues and queries. Should I make proposals for the following changes?

- waterway=lock_gate might be great for the Manchester Ship Canal, 
doesn't work so well for narrowboat canals. Locks are 70ft long or less, 
and marking the upper and lower gates individually seems unnecessary and 
makes them harder to render. Locks also have names (e.g. "Hatton Bottom 
Lock") which seems to make them better rendered with nodes.

On the other hand, canals have no direction of water flow (with a couple 
of exceptions) but locks are directional. So one might want to indicate 
that by using a short directional way. (But should the way point low to 
high or high to low?) Or perhaps level tags either side of the lock, but 
that could interact badly with bridges if this persisted along the 
canal. (I'd expect the entire canal to have "level=-1" to make creating 
bridges over it easier.) One might also consider "ele" either side, but 
accurate data is hard to obtain with a GPS. Is there best practice in 
this area?

- Locks have a maximum width and length, universally measured in feet. 
It should be possible to indicate what it is, presumably using maxlength 
and maxwidth. Is there a danger of these being rendered with symbols 
appropriate only for roads?

- Sometimes you have a "staircase lock", where the exit of one is the 
entrance of another. These need denoting.

- It is useful to denote the rise/fall of a lock (again, universally 
measured in feet). There needs to be a tag for this. We could 
appropriate "depth", but it's not actually the depth of the canal.

- waterway=aqueduct should surely be applicable to ways rather than nodes?

- waterway=mooring should also be applicable to ways, so that the length 
of the mooring can be seen. It should be possible to indicate what side 
of the canal the mooring is on (perhaps by reference to the towpath 
side?), and any conditions attached to mooring there (usually a maxstay, 
measured in days, or perhaps a fee).

- Navigation on canals is done by means of bridge numbers. All bridges, 
including those between two fields (and so with no associated road) have 
a number. There needs to be a tag to associate a bridge number with the 
short "bridge=yes" way.

- Sometimes bridges which no longer exist (but you can see the remains) 
have numbers. How could this be denoted?

- Some bridges are swing bridges, which means they need to be moved out 
of the way, by one of various means; these need notating. "bridge_type"?

- All canals have towpaths. These paths are of varying quality, and this 
information is useful to walkers and cyclists. The towpath can be on 
either side. How should the towpath be denoted? As a separate way 
parallel to the canal? What tags should be used? 
("highway=footway,bicycle=yes")? How should quality be denoted?

- There are several sorts of "waste disposal" on canals - rubbish 
points, where bags of refuse can be left, and "sanitary stations" and 
"pumpout" points, where different types of toilet can be emptied. 
waterway=waste_disposal will not do for all three. (In fact, the 
description - "A place to release used water e.g. for caravans" - fits 
neither.) New tags are needed.

- Canals sometimes have narrow sections, perhaps where a bridge used to 
be. These are useful to know about and for navigation. Are these best 
denoted with maxwidth? All you really need is an on/off toggle for a 
section.

- Tunnels often have rules about who can enter and when (e.g. transit 
north beginning between :00 and :15; south between 30: and :45). We have 
"hour_on" and "hour_off" - is that enough? How should such tags be 
applied, given that the restrictions are different in each direction?

- Turning points ("winding holes") have a maximum length; this could be 
done using "maxlength" on the node, but that's confusing, because if the 
node is part of the canal, it implies that only boats below that length 
can pass that part of the canal. Which is wrong. So how should this be 
handled?

- There are "mile markers" along the canal which are useful for 
navigation and as points of reference and interest.

And this is just a start :-)

Gerv


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