[Talk-ca] Bodies of seawater in Canada - area definitions
John Whelan
jwhelan0112 at gmail.com
Wed Oct 20 23:36:43 UTC 2021
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
>>
>>
>> _______________________________________________
>> Talk-ca mailing list
>> Talk-ca at openstreetmap.org <mailto: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
>
>
> _______________________________________________
> 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/0888775c/attachment-0001.htm>
More information about the Talk-ca
mailing list