[Talk-ca] Bodies of seawater in Canada - area definitions
Nate Wessel
bike756 at gmail.com
Thu Oct 21 00:23:12 UTC 2021
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.
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.
Again, I say go for it.
Best,
Nate Wessel
Cartographer, Planner, Transport Nerd
NateWessel.com <https://www.natewessel.com>
On 2021-10-20 7:36 p.m., John Whelan wrote:
> I worked with large databases for a number of years so my perspective
> might be slightly different to your own.
>
> 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.
>
> 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.
>
> 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.
>
> Cheerio John
>
> Nate Wessel wrote on 10/20/2021 6:29 PM:
>>
>> 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.
>>
>> 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!
>>
>> I say go for it.
>>
>> Cheers,
>>
>> Nate Wessel
>> Cartographer, Planner, Transport Nerd
>> NateWessel.com <https://www.natewessel.com>
>>
>> On 2021-10-20 6:14 p.m., john whelan wrote:
>>> 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.
>>>
>>> Thanks John
>>>
>>> On Wed, Oct 20, 2021, 17:56 David E. Nelson via Talk-ca
>>> <talk-ca at openstreetmap.org <mailto:talk-ca at openstreetmap.org>> wrote:
>>>
>>> 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.
>>>
>>> - David E. Nelson
>>> OSM user "DENelson83"
>>> Courtenay, BC, Canada
>>>
>>> On Oct. 20, 2021 14:13, Frederik Ramm <frederik at remote.org
>>> <mailto: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
>>> <mailto:frederik at remote.org> ## N49°00'09" E008°23'33"
>>>
>>> _______________________________________________
>>> Talk-ca mailing list
>>> Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>> <https://lists.openstreetmap.org/listinfo/talk-ca>
>>>
>>>
>>> _______________________________________________
>>> Talk-ca mailing list
>>> Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>> <https://lists.openstreetmap.org/listinfo/talk-ca>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> --
> Sent from Postbox <https://www.postbox-inc.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20211020/2944a769/attachment.htm>
More information about the Talk-ca
mailing list