[Talk-ca] Bodies of seawater in Canada - area definitions

[stevea]

I agree that I did not have all of the background that Frederik has kindly presented here to (very likely) explain why David might be doing this.  I am interested to hear David answer(s) to Frederik's excellent questions.

Thanks for adding to the thread, John.  Thanks for your summarized history and questions to David, Frederik.  And I look forward to simply methodologies for having (sea)water bodies named simply (likely with a node centered) so they are both easy to create (and maintain), as well as display well (are you listening, render authors?)

> On Oct 20, 2021, at 2:32 PM, john whelan <jwhelan0112 at gmail.com> wrote:
> 
> Fredrick you're talking sense again and probably cutting through to the essential points.  The problem is that not everyone has your framework to start from.
> 
> So it sounds as if we need someway to add names that will display on the tiles rather than anything else.
> 
> Note to David has Fredrick missed something vital in his summation?
> 
> If not then my background in databases and performance would suggest the least amount of data in the database the faster the performance, the quicker it downloads etc.  so my thoughts tend towards the minimum in the database that is consistent with the end user requirements.  An idle thought would be we never really consider end user requirements though in OSM.
> 
> My thoughts would lie along not doing this.
> 
> Cheerio John
> 
> 
> On Wed, Oct 20, 2021, 17:17 Frederik Ramm <frederik at remote.org> wrote:
> Hi there,
> 
> On 10/20/21 11:04, David Nelson via Talk-ca wrote:
> > I recently posted a diary entry detailing my intent to put into OSM area 
> > definitions, implemented as multipolygon relations, for all named bodies 
> > of seawater in Canada, and I was just informed that there was a 
> > consensus in place that this should not be done,
> 
> I'm unsure if there is a consensus. You will note that *my* critical 
> remarks in your diary were carefully worded to express *my* opinion.
> 
> Personally I think that drawing such water bodies is a hack for getting 
> them shown on the map.
> 
> Tell me you're doing this for any other reason than having nice blue 
> labels? Would you be doing this work if it would not result in visible 
> names on the map? Probably not, right?
> 
> So the makers of the map style have a generic rule that will draw names 
> of water bodies, with a prominence somewhat proportional to the size of 
> the water body. They could also have decided to render labels based on 
> points but they haven't; there's plenty discussion (and dispute) about 
> that over on the openstreetmap-carto issue tracker.
> 
> So now, as a consequence of that decision, we have people draw large 
> polygons (so that they get nice and prominent labels). These polygons 
> definitely make editing easier - anyone who splits up a coastline way 
> that is part of such a polygon will upload a new version of the 
> multipolygon which likely has hundreds or even thousands of members. 
> Look at some of the older polygons of that kind and you will find they 
> have amassed hundreds of versions, and the web site times out when you 
> wnat to view their history.
> 
> What's more, these waterbodies do not have an observable or even well 
> defined outer boundary, forcing waterbody mappers to invent random 
> straight lines on the far side of some gulf or bay or whatever. This 
> runs counter to our maxim of mapping what is verifiable on the ground.
> 
> A node label would be easier to maintain, less wrong, and put less of a 
> burden on both mappers and data consumers. The *only* reason people go 
> to absurd lengths to draw these giant polygons (often they are even 
> nested, with one bay being part of a larger bay being part of a gulf or 
> so - where will it end, will someone map the Atlantic just to get a nice 
> label in the middle...) is that they want to see a blue label.
> 
> That's what I object to. It is unnecessary, and in my view, abusing a 
> mechanism not intended for this purpose, abusing our data model to map 
> made-up boundaries, and all for cosmetics. It's an ugly hack that will, 
> I hope, go away as soon as we find a good way to make labels based on 
> label points.
> 
> Bye
> Frederik
> 
> -- 
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
> 
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca