<div dir="ltr"><div dir="ltr">On Wed, 25 Nov 2020 at 08:45, Ture Pålsson via Tagging <<a href="mailto:tagging@openstreetmap.org">tagging@openstreetmap.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
(And I agree with Kevin about reconstructing an area from a point + <br>
surrounding coastline. I'd like to see at least an outline of an <br>
algorithm for that! Having said that, I also recognise that <br>
gazillion-point polygons to outline Skagerrak, Kattegatt, the North Sea <br>
and what-have-you may not be the prettiest state of things either...)<br></blockquote><div><br></div><div>I'm not convinced that point + coastline will give a reasonable result</div><div>enough of the time.  But I could be wrong about that.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Polygons that are contiguous with the coastline are a pain to add, even with</div><div class="gmail_quote"> generalized coastline (and even worse if Slartibartfast has added crinkly bits to</div><div class="gmail_quote"> the coastline).  It's a lot of work.  If the polygon is crude and not contiguous</div><div class="gmail_quote">with the coastline that can give bogus results when trying to determine</div><div class="gmail_quote">if a given co-ordinate is in a named bay or not.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">However, it is often the case that the ends of bays are known (local</div><div class="gmail_quote">knowledge that village X is in Y bay) or are obvious from inspection.</div><div class="gmail_quote">Since at least one person is confident that a single point is enough</div><div class="gmail_quote">to create a workable algorithm, two points should be twice as good!</div><div class="gmail_quote">Yeah, I was joking, but a lot less code and a lot less algorithmic <br></div><div class="gmail_quote">guesswork would be involved in marking two points on a coastline</div><div class="gmail_quote"> that define the extent of the bay.  An algorithm can generate a bounding</div><div class="gmail_quote"> polygon from those two points, the coastline between them, and a straight</div><div class="gmail_quote"> line connecting them.  The hardest part would be ensuring that the</div><div class="gmail_quote">algorithm takes the shortest segment of coastline between the two</div><div class="gmail_quote">points and not the longest segment.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Better than two points would be a way joining those two points.</div><div class="gmail_quote">In the absence of further knowledge, map a simple straight line.</div><div class="gmail_quote">A straight line is an approximation because currents and water</div><div class="gmail_quote">depths might mean hydrographers and/or mariners regard the</div><div class="gmail_quote">seaward extent of the bay to be wibbly-wobbly (one of the</div><div class="gmail_quote">examples posted on the list showed a convex seaward extent</div><div class="gmail_quote">of a bay).  So use a way rather than two points to allow for</div><div class="gmail_quote">curvy seaward extents, where known.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Using a way rather than a polygon avoids the problems of</div><div class="gmail_quote">nested bays.  There are many small bays within Cardigan</div><div class="gmail_quote">Bay (mapped by somebody as a polygon):</div><div class="gmail_quote"><a href="https://www.openstreetmap.org/way/651881240">https://www.openstreetmap.org/way/651881240</a></div><div class="gmail_quote">It would also deal with the potential problem of</div><div class="gmail_quote">overlapping bays (imperfect nesting), should that</div><div class="gmail_quote">ever be necessary, without mappers having to</div><div class="gmail_quote">jump through hoops constructed of multipolygons.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">As far as I can see we can use a point, placed by visual inspection,</div><div class="gmail_quote">and add a tag for importance which determines (in cartos that</div><div class="gmail_quote">make use of it) the size of the label and at what zooms the</div><div class="gmail_quote">label appears.  Or we use a way to determine closure of the bay</div><div class="gmail_quote">and let an algorithm handle placement and importance of the</div><div class="gmail_quote">label.  An algorithm would give greater consistency than mappers</div><div class="gmail_quote">using their best guess at how important the label should be.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Yes, the way could be abused by people wanting to control</div><div class="gmail_quote">placement of the label.  As could the point.  As could any other</div><div class="gmail_quote">way of mapping bays that we come up with.  I don't think</div><div class="gmail_quote">we should reject solutions because somebody could abuse</div><div class="gmail_quote">them, otherwise we wouldn't have any tags at all.</div><div class="gmail_quote"><br></div><div class="gmail_quote">-- <br></div><div class="gmail_quote">Paul</div><div class="gmail_quote"><br></div></div>