Re: [OSM-talk] Mapping Canals
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 54', 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
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
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 snip 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=foo. 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=days. 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=number 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=text/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: amenity=pumpout New tag value:
Re: [OSM-talk] Mapping canals
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
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-8oe=UTF-8sourceid=navclientgfns=1q=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 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-8oe=UTF- 8sourceid=navclientgfns=1q=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. Thats fine for making it easier to code and deliver reliable data to users but absolutely useless if this precisely formatted data doesnt exist in the database, and thats 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 thats 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 its 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
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
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
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
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
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 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
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
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
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
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
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=foo. 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=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
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=foo. 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=name. Better to group them with a relation, I'd have thought. You may be right. I'm not too up on relations. reads 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
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=number 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? maxspeed=110 -- assumed km/h maxspeed=70mph -- unit stated maxwidth=2.14 --
Re: [OSM-talk] Mapping canals
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
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
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 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
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
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
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
[OSM-talk] Mapping canals
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
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
Re: [OSM-talk] Mapping canals
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
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
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=foo. - the maxwidth, with maxwidth=metres. A standard single lock is 2.2m, a standard double lock 4.4m. - the maxlength, with maxlength=metres. 70ft is 22m. - the rise, with new tag rise=metres. 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=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=days. 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=number 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
-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
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
Re: [OSM-talk] Mapping canals
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
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
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 denoted? As a separate way parallel to the canal? What tags
Re: [OSM-talk] Mapping canals
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
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
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
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 toos. 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
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
