[OSM-talk] Canals

[Andy Robinson]

Ben Robbins wrote:
>Sent: 07 November 2006 12:40 AM
>To: david at frankieandshadow.com; talk at openstreetmap.org
>Subject: Re: [OSM-talk] Canals
>
>
>Its double the width if not more, but its more inportant that the thin bit
>is thin, than the wide bit is wide.  I was thinking of doing exactly that
>(natural-water) but that would then mean having the defautl canal thin, and
>haveing the additonal area where wider.  But 90% of the canal is wider.  So
>a lot of effert.
>
>I had an idea:  What about having tags stating the width specifically to
>canals.  so Canal_width=xyz will then render additonally to the canal.  If
>the outlines of waterway=canal and the additonal area are rendered
>togehter,
>and then the water is rendereed ontop, then the wider bits will blend.
>This leaves the problem of 1.  Having 'laybye' style sections, although the
>rarety of these may mean areas are enough, and 2.  The outline going
>between
>the 2 thicknesses may be incorrect.  I.e. the canal I'm currently mapping
>when from thin to thick with a 45'degree angle.  This would require it to
>render to a spike.  If its 90' or rounded, then then thats not a problem.
>
>" is it really necessary?"  Well, I think so.  Why be less acurate than
>posible?.  Even if one person choices not to add this, its inportant with
>all options to allow people to do more acurate maps if they want.
>
>Ben
>

These difficulties are one of the reasons why conventional GIS uses edges
rather than the centreline of the feature as we do now. Having said that,
our method is a lot simpler and works most of the time. Using the "width"
tag gets over a lot of the problems and for canals its also possible to
think of using a "narrow_guage" or "broad_gauge" tagging to distinguish the
relative generic size of the canal (lock widths vary too of course).
The lay-by arrangement is perhaps dealt with by adding an additional bit of
way that when rendered overlaps with the main way. This is not strictly a
physical truth but since route navigation for canals is unlikely to be a big
need I guess it's not that important ;-)
For larger bodies of water (basins, stilling & retention ponds etc) then the
area approach is clearly the best. The issue about the casing can be
resolved by turning the casing off over the section you do not want it. That
would require an additional osmarender rule but its no big deal to
implement.

Cheers,

Andy

>
>
>
>From: "David Earl" <david at frankieandshadow.com>
>To: "Ben Robbins" <ben_robbins_ at hotmail.com>
>Subject: RE: [OSM-talk] Canals
>Date: Mon, 6 Nov 2006 19:36:47 -0000
>
>Unless it is very much wider, is it really necessary?
>
>But one thing I did where our river had a weir which spills in to a pond
>before resuming the river course again is make a 'natural=water' area to
>represent the wider pond bit. It renders pretty well - it looks obviously
>part of the water course.
>
>David
>
> > -----Original Message-----
> > From: talk-bounces at openstreetmap.org
> > [mailto:talk-bounces at openstreetmap.org]On Behalf Of Ben Robbins
> > Sent: 06 November 2006 19:27
> > To: talk at openstreetmap.org
> > Subject: [OSM-talk] Canals
> >
> >
> > The width of Canals varies around locks, (and also in other
> > places I would
> > imagin), but around locks in particular.  It gets thinner by
> > about half the
> > size.   How should I go about makeing this?   If i have the way
> > as a canal,
> > and then use areas to make the wider bits wider, then 90% of the
> > canal will
> > be area, as the average section is widest.  On the other hand, if
> > I make 2
> > tags, for the 2 thicknesses, or have an additonal canal_width
> > tag, then this
> > would render symetrically and get wider and thinner in steps.  Commonly
> > canals do do this, although usually the steps are diagonal, and commenly
> > they are not symetrical.
>[snip]
>
>_________________________________________________________________
>The new Windows Live Toolbar helps you guard against viruses
>http://toolbar.live.com/?mkt=en-gb
>
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk