[Tagging] Using multipolygons to map bays in Alaska
daveswarthout at gmail.com
Thu Nov 15 14:21:28 UTC 2018
Thanks for the feedback and the references to the previous discussions
about this topic. The first reference to an earlier discussion on this list
was particularly useful. From your email and that thread, I gather that you
are opposed to mapping bays and straits as multipolygons. That comes
through loud and clear. But there are others who disagree. I think both
sides make valid arguments and I tend to agree with those who say go ahead
and use multipolygons. It seems to me a better choice but that choice is
not without its drawbacks. One I've already mentioned, and it was touched
on in the thread as well, that of adding complexity to the map. You say
that should be left to renderers to deal with, even imperfectly, in ways
that are difficult for the non-specialist to understand. Okay, I'm fine
with that. It's a ton of work to create multipolygons in order to force OSM
to represent bays the way I would like to see them, so I'm not going to
continue my practice of converting them to multipolygons. Nor will I try to
"simulate" the Cook Inlet with an approximate area. a "labeling polygon",
as you described it. I reckon I'll have to leave that to better future
But the thread was interesting and I would like to make a few observations
while I have your attention. Some have argued that defining the outside of
a bay is difficult. I think that is not a big problem in my part of the
world because I can access a very reliable source of geographic information
via the USGS Topo map overlay. Most bays are fairly easy to outline with
coastline and a simple way connecting the two extremes. Straits too are
usually fairly easy to define spatially with the help of those maps.
Straits are important geographic features and I think the use of
multipolygons to define them is a useful methodology. Absolute accuracy is
hard to attain but it doesn't matter all that much. What someone piloting a
fishing boat in heavy weather wants to know is, am I in this bay or am I in
the Shelikof Strait? If the Shelikof Strait (240 km long and 40-48 km
wide), is represented by a mere node, I doubt that it would be possible to
know one way or the other.
However, because of its size and importance to Alaskans, I used the trick
you advised against. I used segments of the Kodiak Borough boundary to
define the north and south edges of the strait and then simply closed the
area with straight way segments to create an area rather than adding
hundreds of small sections of coastline to a large multipolygon created for
the purpose. Not very accurate but better IMO than a node.
I might go back and change that someday but at the moment I'm prepared to
leave it as it is. There are so many other mapping chores to do in Alaska
it boggles the mind.
On Thu, Nov 15, 2018 at 6:11 PM Christoph Hormann <osm at imagico.de> wrote:
> On Thursday 15 November 2018, Dave Swarthout wrote:
> > [...]
> > I was thinking it would be much easier and perhaps even better to
> > just draw an approximate shape consisting of maybe 20 or 30 nodes,
> > big enough to define the area and cause it to render, but easy to
> > draw and without involving any multipolygons. The issue here is
> > admittedly one I am pursuing to get these water bodies to render in a
> > manner proportional to their size and I suspect that many will be
> > against it on that basis alone. Still, I thought it worthwhile to
> > mention my idea here and see what you think about it as a "shorthand"
> > solution.
> I think it is good you bring this up because many mappers have been
> doing exactly that without asking - See for example:
> To put it right upfront: This is a bad idea. As you say the main
> motivation for doing this is to make a bay show up in the map.
> OSM-Carto has made the decision to incentivize this kind of mapping -
> and as i like to point out to derivate from its self declared goal to
> support mappers in consistent mapping towards steering mappers to map
> in a way that is convenient for style developers.
> The 'polygons is universally the preferred way of mapping no matter if
> verifiable or not' and 'way_area equals cartographic importance'
> concepts have been meanwhile extended to natural=strait in OSM-Carto -
> thereby not only incentivizing against mapping with nodes but also
> against mapping with linear ways.
> To be fair: There are other map styles that do essentially the same so
> it is not appropriate to exclusively blame OSM-Carto for this but it is
> the only style that due to being rendered on OSMF infrastructure has a
> true obligation not to do this.
> Mapping bays with polygons is always non-verifiable to a large extent.
> Mapping bays with polygons as you describe it above is always
> completely non-verifiable and amounts to pure (low quality) label
> painting which should not be done and should not be incentivized by
> maps with a mapper feedback goal.
> If you want to generate high quality labeling for bays in maps what you
> need is the geometry of the waterbody the bay is part of (usually the
> coastline) and the location of the bay - which can easily be specified
> with a node in the way described on the wiki. This allows for much
> higher quality labeling than a pretend-exact geometry either based on
> coastlines or not. So the first thing you do with bay polygons for
> generating quality labeling is to derive a node location from the
> polygon and start from that - which makes the polygon drawing really
> kind of insane.
> Long story short: My suggestion is and has always been to map bays with
> nodes in those cases where this - together with the coastline -
> perfectly documents the verifiable information available on the
> geometry of the bay. In other situations (which exist but are
> relatively rare) other verifiable modeling concepts can be considered.
> Drawing a coarse labeling polygon is not one of them.
> Links to previous discussion on the matter:
> Christoph Hormann
> Tagging mailing list
> Tagging at openstreetmap.org
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging