<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I can't imagine we're talking about an increase in total database
size of more than a few megabytes here. Remember that a relation
is constructed of references to ways, not the ways and nodes
themselves; those already exist. Not that net data size would be a
terribly valid basis for discouraging anyone's contributions
anyway. <br>
</p>
<p>Data consumers have all kinds of ways of avoiding data they don't
want or need. Anyone not using Overpass or Osmium or a similar
service/tool to filter huge OSM datasets has themselves to blame
at this point. The world is a big place and we can expect the data
representing it to be big as well.<br>
</p>
<p>Again, I say go for it. </p>
<p>Best,<br>
</p>
<div class="moz-signature">
<p> Nate Wessel<br>
<small> Cartographer, Planner, Transport Nerd<br>
<a href="https://www.natewessel.com"
style="text-decoration:none;"> NateWessel.com </a> </small>
</p>
</div>
<div class="moz-cite-prefix">On 2021-10-20 7:36 p.m., John Whelan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c7676441-ca90-d2df-e4a8-22bf7ee7d589@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
I worked with large databases for a number of years so my
perspective might be slightly different to your own.<br>
<br>
Computer databases from a technical point of view means you are
shovelling around data. Whether it is in OSMAND or backing up the
more data in the system influences such things. In extreme cases
it becomes impossible to take a database off line to back it up
within a given time window. This can be important especially when
a new version of the operating system etc comes out. Hot backups
work but talk to a database administrator and I think you'll find
they prefer the occasional cold backup as well. Yes we use
redundant disk drives and hope two don't fail at the same time but
more data does mean increased technical challenges in keeping the
database running.<br>
<br>
It means increased costs as more bandwidth is consumed etc.
Adding buildings to Africa means the off line version of the map
for example has grown in size to such an extent that many people's
smartphones don't have the memory to hold it. They have to use
trimmed versions of the map. Yes it now has lots more buildings
but the cost to the end user is not insignificant even if it means
finding out about maps that omit some details.<br>
<br>
I accept OSM works in a way that many computer professions or
retired professionals such as myself see as less than optimal but
it should be taken into consideration never the less.<br>
<br>
Cheerio John<br>
<br>
<span>Nate Wessel wrote on 10/20/2021 6:29 PM:</span><br>
<blockquote type="cite"
cite="mid:6e36b504-aab9-92fc-7c6a-a07ab667894a@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>I'm not sure I see any real downsides here. Having a polygon
relation doesn't preclude having a label point. I assume the
point would be maintained more or less as-is and then have
role=label for the relation. The relation boundary is a bonus.
<br>
</p>
<p>If people don't want to consider the relation they can just
query the point which will still be there. Literally no harm
done. It's not like the database is running out of space; and
if it is, we have bigger fish to fry!</p>
<p>I say go for it.</p>
<p>Cheers,<br>
</p>
<div class="moz-signature">
<p> Nate Wessel<br>
<small> Cartographer, Planner, Transport Nerd<br>
<a href="https://www.natewessel.com"
style="text-decoration:none;" moz-do-not-send="true">
NateWessel.com </a> </small> </p>
</div>
<div class="moz-cite-prefix">On 2021-10-20 6:14 p.m., john
whelan wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJ-Ex1Fwx9dGWbjKM9W+kYhoJ0wMijCiFZc94ssdY_H_+VOY4Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="auto">I''m not quite sure I follow you on the
benefits. Could you expand a little more in simple terms
remembering not everyone here is a GIS expert.
<div dir="auto"><br>
</div>
<div dir="auto">Thanks John</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021,
17:56 David E. Nelson via Talk-ca <<a
href="mailto:talk-ca@openstreetmap.org"
moz-do-not-send="true">talk-ca@openstreetmap.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>My primary goal was not to get these bodies of
water more visible on the map, as we all know that
"tagging for the renderer" is a bad practice. My
objective was simply to give these bodies of water
area definitions, so that more "points" on the sea
could have names associated with them.
<div dir="auto"><br>
</div>
<div dir="auto">- David E. Nelson</div>
<div dir="auto">OSM user "DENelson83"</div>
<div dir="auto">Courtenay, BC, Canada</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Oct. 20, 2021 14:13,
Frederik Ramm <<a
href="mailto:frederik@remote.org"
target="_blank" rel="noreferrer"
moz-do-not-send="true">frederik@remote.org</a>>
wrote:<br type="attribution">
<blockquote style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<p dir="ltr">Hi there,</p>
<p dir="ltr">On 10/20/21 11:04, David Nelson via
Talk-ca wrote:<br>
> I recently posted a diary entry detailing
my intent to put into OSM area <br>
> definitions, implemented as multipolygon
relations, for all named bodies <br>
> of seawater in Canada, and I was just
informed that there was a <br>
> consensus in place that this should not
be done,</p>
<p dir="ltr">I'm unsure if there is a consensus.
You will note that *my* critical <br>
remarks in your diary were carefully worded to
express *my* opinion.</p>
<p dir="ltr">Personally I think that drawing
such water bodies is a hack for getting <br>
them shown on the map.</p>
<p dir="ltr">Tell me you're doing this for any
other reason than having nice blue <br>
labels? Would you be doing this work if it
would not result in visible <br>
names on the map? Probably not, right?</p>
<p dir="ltr">So the makers of the map style have
a generic rule that will draw names <br>
of water bodies, with a prominence somewhat
proportional to the size of <br>
the water body. They could also have decided
to render labels based on <br>
points but they haven't; there's plenty
discussion (and dispute) about <br>
that over on the openstreetmap-carto issue
tracker.</p>
<p dir="ltr">So now, as a consequence of that
decision, we have people draw large <br>
polygons (so that they get nice and prominent
labels). These polygons <br>
definitely make editing easier - anyone who
splits up a coastline way <br>
that is part of such a polygon will upload a
new version of the <br>
multipolygon which likely has hundreds or even
thousands of members. <br>
Look at some of the older polygons of that
kind and you will find they <br>
have amassed hundreds of versions, and the web
site times out when you <br>
wnat to view their history.</p>
<p dir="ltr">What's more, these waterbodies do
not have an observable or even well <br>
defined outer boundary, forcing waterbody
mappers to invent random <br>
straight lines on the far side of some gulf or
bay or whatever. This <br>
runs counter to our maxim of mapping what is
verifiable on the ground.</p>
<p dir="ltr">A node label would be easier to
maintain, less wrong, and put less of a <br>
burden on both mappers and data consumers. The
*only* reason people go <br>
to absurd lengths to draw these giant polygons
(often they are even <br>
nested, with one bay being part of a larger
bay being part of a gulf or <br>
so - where will it end, will someone map the
Atlantic just to get a nice <br>
label in the middle...) is that they want to
see a blue label.</p>
<p dir="ltr">That's what I object to. It is
unnecessary, and in my view, abusing a <br>
mechanism not intended for this purpose,
abusing our data model to map <br>
made-up boundaries, and all for cosmetics.
It's an ugly hack that will, <br>
I hope, go away as soon as we find a good way
to make labels based on <br>
label points.</p>
<p dir="ltr">Bye<br>
Frederik</p>
<p dir="ltr">-- <br>
Frederik Ramm ## eMail <a
href="mailto:frederik@remote.org"
target="_blank" rel="noreferrer"
moz-do-not-send="true">frederik@remote.org</a>
## N49°00'09" E008°23'33"</p>
<p dir="ltr">_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org"
target="_blank" rel="noreferrer"
moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
<a
href="https://lists.openstreetmap.org/listinfo/talk-ca"
target="_blank" rel="noreferrer"
moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</p>
</blockquote>
</div>
<br>
</div>
</div>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank"
rel="noreferrer" moz-do-not-send="true">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Talk-ca mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org" moz-do-not-send="true">Talk-ca@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a>
</pre>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-ca mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org" moz-do-not-send="true">Talk-ca@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca" moz-do-not-send="true">https://lists.openstreetmap.org/listinfo/talk-ca</a>
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<div>Sent from <a href="https://www.postbox-inc.com"
moz-do-not-send="true"><span style="color: rgb(0, 157,
247);">Postbox</span></a></div>
</div>
</blockquote>
</body>
</html>