[Tagging] coastline v. water

Paul Allen pla16021 at gmail.com
Wed Nov 25 13:20:22 UTC 2020


On Wed, 25 Nov 2020 at 08:45, Ture PĂ„lsson via Tagging <
tagging at openstreetmap.org> wrote:

>
> (And I agree with Kevin about reconstructing an area from a point +
> surrounding coastline. I'd like to see at least an outline of an
> algorithm for that! Having said that, I also recognise that
> gazillion-point polygons to outline Skagerrak, Kattegatt, the North Sea
> and what-have-you may not be the prettiest state of things either...)
>

I'm not convinced that point + coastline will give a reasonable result
enough of the time.  But I could be wrong about that.

Polygons that are contiguous with the coastline are a pain to add, even with
generalized coastline (and even worse if Slartibartfast has added crinkly
bits to
the coastline).  It's a lot of work.  If the polygon is crude and not
contiguous
with the coastline that can give bogus results when trying to determine
if a given co-ordinate is in a named bay or not.

However, it is often the case that the ends of bays are known (local
knowledge that village X is in Y bay) or are obvious from inspection.
Since at least one person is confident that a single point is enough
to create a workable algorithm, two points should be twice as good!
Yeah, I was joking, but a lot less code and a lot less algorithmic
guesswork would be involved in marking two points on a coastline
that define the extent of the bay.  An algorithm can generate a bounding
polygon from those two points, the coastline between them, and a straight
line connecting them.  The hardest part would be ensuring that the
algorithm takes the shortest segment of coastline between the two
points and not the longest segment.

Better than two points would be a way joining those two points.
In the absence of further knowledge, map a simple straight line.
A straight line is an approximation because currents and water
depths might mean hydrographers and/or mariners regard the
seaward extent of the bay to be wibbly-wobbly (one of the
examples posted on the list showed a convex seaward extent
of a bay).  So use a way rather than two points to allow for
curvy seaward extents, where known.

Using a way rather than a polygon avoids the problems of
nested bays.  There are many small bays within Cardigan
Bay (mapped by somebody as a polygon):
https://www.openstreetmap.org/way/651881240
It would also deal with the potential problem of
overlapping bays (imperfect nesting), should that
ever be necessary, without mappers having to
jump through hoops constructed of multipolygons.

As far as I can see we can use a point, placed by visual inspection,
and add a tag for importance which determines (in cartos that
make use of it) the size of the label and at what zooms the
label appears.  Or we use a way to determine closure of the bay
and let an algorithm handle placement and importance of the
label.  An algorithm would give greater consistency than mappers
using their best guess at how important the label should be.

Yes, the way could be abused by people wanting to control
placement of the label.  As could the point.  As could any other
way of mapping bays that we come up with.  I don't think
we should reject solutions because somebody could abuse
them, otherwise we wouldn't have any tags at all.

-- 
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201125/ffc39430/attachment.htm>


More information about the Tagging mailing list