[Tagging] Stop the large feature madness (was: Tag for a plateau or tableland?)
osm at imagico.de
Thu Apr 18 21:25:15 UTC 2019
On Thursday 18 April 2019, Kevin Kenny wrote:
> > And how do you verifiably determine if two things are part of the
> > same physical object? For example: [examples snipped]
> I'm all for a rule of, 'if in doubt, split,' possibly paired with
> creating a new relation to carry the grouping. You seem to favour a
> rule of 'never join,' which is perverse for the common case where
> there is broad consensus about object identity.
As mentioned in terms of physical geography the only cases where there
is broad consensus on the identity of large size features and if and
how to represent them in the OSM are lakes and islands. For most other
things mapped mostly with polygons, in particular stuff rendered
typically with a color fill, it is widely accepted that polygons are
split and most mappers prefer small and easy to handle divisions. Many
mapping conventions we have even require this - for example if part of
a forest is needleleaved, part is mixed, you have to split it to
represent this fact in the data.
Even for lakes we have cases where this applies by the way. Lake
Balkhash is a lake of which part is freshwater and part is saltwater
which is mapped separately despite the name applying to both parts:
If you consider this a bad idea that's fine. But it stems from the
fundamental idea of mapping local geographic knowledge. For locals at
the eastern part this is locally Lake Balkhash and it is saltwater.
For locals at the western part this is also Lake Balkhash and it is
freshwater. And that is perfectly fine and nothing should require
these mappers to settle for a uniform but locally inaccurate
representation of the geography.
> > I distinguish between names and labels. Labels are graphical
> > representations of names or other strings in map renderings. The
> > OSM database should not contain labels, it should contain names.
> On this, we agree. To what object should the name, 'Jamaica Bay' be
> assigned? How can such an object be constructed? The locals can
> clearly define its extents, except for very small indefinite
> boundaries over narrow entrances and exits. What should be done to
> give that object, which unquestionably is observable in the field as
> an entity distinct from the ocean, existence in OSM?
I respect your desire to find a consensus for how to represent this
particular feature but this doesn't really have much to do with the
subject here, that is to what extent we can and should map large size
concepts in OSM. Jamaica Bay is beyond any doubt small enough to be
mapped under the rule of thumb i proposed so discussing this is IMO not
a matter of if it should be mapped but only potentially what is the
best way to map it recording all verifiable knowledge of it in an
efficient way. I would like to separate that discussion from the
subject here. IIRC in our previous discussion on this i made a
principal point that creating a polygon is unnecessary even here but i
don't think i really objected to using one.
> We have that at one extreme, a case where almost all the boundaries
> are indefinite. Nevertheless, the Drake Passage has some sort of
Yes. Leaving aside for the moment the question if something like the
Drake Passage should be represented in OSM - the Drake Passage is a
great example for a strait where no geometric information is required
beyond a node to fully represent the feature in its spatial
The Drake Passage is the passage/strait between Cape Horn (the southern
end of South America) and the Antarctic. As a prototype of a strait
between two convex land masses it has no length but only a width. It
is perfectly documented with a node placed half way from Cape Horn to
the closest point in the Antarctic (on the South Shetland Islands).
But as already hinted i am not sure if the Drake Passage is something i
would consider mappable in OSM based on local knowledge. Of course as
long as it was mapped with a simple node it did not really bother
anyone - you could as a mapper or data user simply ignore it.
More information about the Tagging