[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