Re: [Tagging] coastline v. water

[Frederik Ramm]

Hi,

On 23.11.20 15:10, David Groom wrote:
> Using this logic the Mediterranean Sea, the Red Sea, and the Persian
> Gulf should all have the coastline tags removed from their defining ways
> and converted to water areas!   Italy, Greece, Libya, Egypt and a large
> group of other counties would find they had no coastline, which might
> come as a surprise to anyone lining there.

I'll probably have to inform the tourism guys in Annapolis too and tell
them to stop calling themselves a "coastal place"
https://patch.com/maryland/annapolis/annapolis-among-20-best-coastal-places-live-magazine
;) sorry folks, you're on an inland waterway. Bit like Richmond really!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[David Groom]

See comments below:

David
-- Original Message --
From: "Eric H. Christensen via Tagging" 
To: "tagging@openstreetmap.org" 
Cc: "Eric H. Christensen" 
Sent: 18/11/2020 20:19:51
Subject: [Tagging] coastline v. water


After a few days of much work, a recent collaborative project to turn the 
Chesapeake Bay from a nothing space outlined by natural=coastline to what we 
considered to be a more accurate relation of natural=water, we've received some 
negative feedback.

The difference of opinion seems to lie in the definition of what we're mapping.  The use of 
coastline is for "seas"[0] while the use of water is for "inland areas of 
water"[1].  Even though the Chesapeake Bay is tidal, there is no question that it is an inland 
waterway (it is completely surrounded by land except for the mouth at its southeast side).
Using this logic the Mediterranean Sea, the Red Sea, and the Persian 
Gulf should all have the coastline tags removed from their defining ways 
and converted to water areas!   Italy, Greece, Libya, Egypt and a large 
group of other counties would find they had no coastline, which might 
come as a surprise to anyone lining there.



The idea of using coastlines for basically creating an edge between the land 
and the nothingness of the ocean makes sense when, as far as the eye can see 
it's only water.

Now, some of the feedback that has been presented[2] is that because it is 
tidal it is part of the sea.  I have pointed out that many rivers and streams 
(and ditches!) are tidal; does that make them part of the sea?  I would not 
think so.  In fact, there are named seas on this planet that are not even 
connected to other water formations (the tiniest, according to the National 
Geographic, is the Sea of Marmara which has an area just less than 12,950 sq 
km, larger than the Chesapeake Bay).

But, tagging the Chesapeake Bay, and its tributaries, as "water" brings several 
benefits to the map and the users.  First, it helps identify the sections of water that 
exist in these areas (this can't really be done with node points as there is no way to 
define start and end points of an area).  There are many defined bays, rivers, and 
streams that make up the greater Chesapeake Bay area.  What one may see as one large mass 
of water is actually many smaller defined segments each with their own history.
This is irrelevant to the question of whether the ways should be tagged 
as natural = coastline.  You have had to create a multipolygon 
containing the ways which form the "sections of water", its perfectly 
possible to add the "name" tag to this multipolygon without removing the 
coastline tag from the ways



 Second, we can speed up any updates (fixes) to outlines of the polygons that 
happen in these water areas without having to wait for the entire Earth's 
coastlines to be re-rendered.
Changes to tagging should not be done to facilitate easier rendering on 
one particular map.



 I suspect having less coastline to render would also speed up the rendering of 
coastlines as well?

Very unlikely.


I would like for the tagging community to clarify the different between "water" and 
"coastline" and when to use each.  The definition on water seems to say to use it on inland water 
but there seems to be, at least, and open interpretation of the word "sea" for coastline that is 
dragging many inland waters into that category.

Thanks,
Eric "Sparks" Christensen

[0] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline
[1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater
[2] https://www.openstreetmap.org/changeset/94093155#map=10/37.1620/-76.1581

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Segregated foot-cycle path with different surfaces

[Volker Schmidt]

How do I correctly tag this way: OSM way 434742113
,  Mapillary image

It's a segregated bidirectional foot-cycleway:
highway=path
bicycle=designated
foot=designated
segregated=yes
onewy=no
Its overall width is
width=4
It's illuminated
lit=yes
Its surface is ok:
smoothness=good
I want to indicate the relative position of foot and cycle lanes:
lanes=2
bicycle:lanes=no|yes
foot:lanes=yes|no
I'm tempted to extend this approach  to the surface and width as well:
surface:lanes=asphalt|fine_gravel
width:lanes=1.5|2.5

Is this tagging correct? Are there (better) alternatives?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Brian M. Sperlongano]

I've spent a significant amount of time painstakingly re-mapping the
crudely-drawn PGS coastal boundaries of Rhode Island to conform to the wiki
definition of natural=coastline, having it traverse all the little bays,
coves, inlets, etc.  I've also been adding named bodies of water as
polygons outside of the coastline ways as these two techniques can coexist
just fine.

I would be quite upset if another mapper came along and undid all that work
because they didn't like the documented definition and chose to arbitrarily
apply a different one.

On Sun, Nov 22, 2020, 3:41 AM Sarah Hoffmann  wrote:

> Hi,
>
> On Sat, Nov 21, 2020 at 07:09:45PM +, Eric H. Christensen via Tagging
> wrote:
> > You cannot point to other area that may, in fact, be improperly mapped
> as an example when they are like that because locals have been shouted down
> for doing it correctly. The fact that this keeps coming back up literally
> means that there is not universal agreement that "marginal seas", whatever
> that means, are to be mapped with natural=coastline.
> >
> > The Chesapeake Bay is an estuary that, by definition, opens to the sea.
> It can't be a sea and open to a sea at the same time. In this environment,
> it is different from the ocean in which it opens into and is also different
> from the tributaries that feed it. These are protected waters for ships.
> You won't find any high seas forecasts for the Bay unlike the ocean. The
> Bay is also brackish and not defined as salt water, unlike the ocean.
>
> There is a very fundamental misunderstanding on how OpenStreetMap works
> in here. The definition of a tag comes from the agreed-on understanding
> of the OpenStreetMap community as a whole of what that tag should be. This
> may or may not agree with defintion of the same word in other contexts.
> That's just the way it is with defintions. They may differ. You cannot just
> uniterally apply a definition of coastline that you think is more
> appropriate, or scientifically correct or whatever and change the map.
> It is OSM's definition that counts, and OSM's defintion only.
>
> That doesn't mean that definitions can't evolve over time but that needs
> to be discussed when it has a larger impact. natural=coastline
> is a particular touchy tag here because it is one of the few tags where
> we rely on a agreed-on definition that works on a planet-scale. Even if
> you change something relatively locally, it has an effect on how the
> planet map as a whole is rendered. You can't just apply a new definition
> to one bay. We must agree on a new definition globally here and apply it
> globally or the tagging becomes a worthless mess.
>
> So please, by all means, start a discussion about a new definition of
> coastline, make a wiki page, put it up for voting. But all this should
> be done **before** making any larger changes. For now, please, put
> the Chesapeake Bay back into its original state.
>
> Kind regards
>
> Sarah
>
> > ‐‐‐ Original Message ‐‐‐
> > On Saturday, November 21, 2020 1:14 PM, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
> >
> > > Eric,
> > > I don't think the previous discussion is quite as inconclusive as your
> evaluation.
> > >
> > > While it is true that there is not widespread agreement on where the
> natural=coatline ways should transect a river mouth or river estuary, there
> is nearly universal agreement that marginal seas, including bays, are
> mapped with the natural=coastline.
> > >
> > > Using the rendering at https://www.openstreetmap.de/karte.html -
> which differentiates the marine water polygons outside of the coastline
> from lakes and rivers, by using slightly different colors, we can see how
> bays are mapped in other parts of North America and the world.
> > >
> > > For example, check out Delaware Bay, just up the coast from your area:
> https://www.openstreetmap.de/karte.html?zoom=10=39.14649=-75.07302=B000
> - it is mapped as a natural=bay with natural=coastline around it, not
> natural=water
> > >
> > > Upper and Lower New York Bay are mapped as bays outside of the
> natural=coastline - you can see the line where the waterway=riverbank area
> starts just at the north end of Manhattan island (though this placement is
> somewhat controversial) -
> https://www.openstreetmap.de/karte.html?zoom=10=40.63628=-73.93525=B000
> > >
> > > Tampa Bay:
> https://www.openstreetmap.de/karte.html?zoom=10=27.80801=-82.63368=B000
> - outside of the natural=coastline
> > >
> > > Galveston Bay:
> https://www.openstreetmap.de/karte.html?zoom=10=29.49869=-94.94249=B000TT
> - outside of the natural=coastline
> > >
> > > San Francisco Bay and connected bays:
> https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT
> - outside of the coastline
> > >
> > > Puget Sound - while Lake Washington on the east side of Seattle is
> natural=water, also most of the ship canal connecting them:
> https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000
> > >
> > > I 

Re: [Tagging] coastline v. water

[Frederik Ramm]

Hi,

I would like to make one point that has been touched on but not said
clearly, I think.

Some proponents of the recent changes to Chesapeake bay have used
reasoning like: "Only by mapping the bay as a polygon can $SOFTWARE
properly determine that a given location is in the bay, as opposed to in
some undfined part of the sea."

To this, Jochen has even replied along the lines of "create a polygon if
you want but additionally use the natural=coastline tag".

I want to issue a stern warning here: This line of thinking will not
stop with Chesapeake bay. People are already creating giant
multipolygons for the Strait of X and the Gulf of Y all over OSM. Before
too long, a desire to have $SOFTWARE properly decide that a given
location is, say, in the Atlantic Ocean, will give rise to demands that
the Atlantic Ocean be mapped as a giant, named water polygon.

Our current tooling makes this impractical (that's the very reason why
we handle the coastline like we do). Even the 2000+ member "gulfs" and
"bays" and "straits" that some people seem to derive endless pleasure
from plastering the map with - often using questionable third-party
sources or guesswork to define where exactly you leave the ocean and
enter the gulf - already complicate the delicate community processes of
editing and quality assurance. Splitting a single piece of coastline
anywhere along Chesapeake bay now will, for example, give your changeset
a bounding box that encompasses the whole bay. Anyone monitoring local
edits gets swamped with false positives like that. It will also require
uploading a complete new version of the giant bay polygon, vastly
increasing the likelihood of edit conflicts that might well lead a
hapless novice to abandoning their work, rather than trying to solve the
conflict.

Now, you might smirk and say "let's fix the tools then", but until the
tools are fixed - which might take years -, you've made life a hell of a
lot harder for anyone editing or quality monitoring in the whole area.

And all for what - a nice blue label in the bay?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Segregated foot-cycle path with different surfaces

[Hubert87 via Tagging]

Hi Volker,

this looks like a valid solution to me.
Slight additions/corrections:

don't use "lanes=2" as this is for fully fledged carrigeways.

Also, you might want to use:
bicycle:lanes=no|designated
foot:lanes=designated|no

and maybe add a general "overall" tag

surface=paved


Yours

Hubert87

Am 23.11.2020 um 15:39 schrieb Volker Schmidt:

How do I correctly tag this way: OSM way 434742113
, Mapillary image

It's a segregated bidirectional foot-cycleway:
highway=path
bicycle=designated
foot=designated
segregated=yes
onewy=no
Its overall width is
width=4
It's illuminated
lit=yes
Its surface is ok:
smoothness=good
I want to indicate the relative position of foot and cycle lanes:
lanes=2
bicycle:lanes=no|yes
foot:lanes=yes|no
I'm tempted to extend this approach  to the surface and width as well:
surface:lanes=asphalt|fine_gravel
width:lanes=1.5|2.5

Is this tagging correct? Are there (better) alternatives?





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] surface=rock

[Matthew Woehlke]

On 21/11/2020 15.07, Joseph Eisenberg wrote:

My understanding about this is that there is a difference between British
English usage and American usage - especially in the western USA.

The English seem to have an idea that "rock" is for mostly solid, 
immobile "bedrock", while a "stone" is a mobile, separate piece of 
mineral which you might pick up if you are strong enough, or at least

move with a piece of heavy machinery. [...] But American English and
perhaps other dialects do not always maintain this distinction, in my
experience.

"I picked up one of the rocks from my stone driveway."

"Look at all these stones I pulled out of the river; sure is rocky in 
there!"


--
Matthew

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Dave F via Tagging]

On 22/11/2020 22:27, Christoph Hormann wrote:
Exactly. It also shows how we in OSM traditionally make decisions 
about tagging. An idea to change tagging practice was suggested - on 
an open channel for everyone to read and comment on without hurdles 
and with an archive that allows us now to read up on things years 
later. It was discussed and arguments and reasoning were provided both 
for and against the idea and based on that we reached consensus that 
it was a bad idea and it was abandoned.


Yes, but the demand was still made & the solution of writing competent 
code to enable the proposal was never implemented, so your point is?


DaveF


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Kevin Kenny]

On Mon, Nov 23, 2020 at 2:57 PM Frederik Ramm  wrote:

> Now, you might smirk and say "let's fix the tools then", but until the
> tools are fixed - which might take years -, you've made life a hell of a
> lot harder for anyone editing or quality monitoring in the whole area.
>
> And all for what - a nice blue label in the bay?
>

TL;DR: I understand the technical problems. Don't let the technical
problems block the discussion for people who might be able to develop
technical solutions.



Back when this discussion started, it started because you deleted a
relation for the Gulf of Bothnia, entirely without warning, without
discussion, and without mentioning it in public even afterward until it was
noticed and you were called on it in public. Generally speaking, it was
accepted, ex post facto, as an emergency measure needed to rescue the
servers from a performance trap, and most of us were willing to accept a
temporary moratorium on creating large area relations because of the
technical complications.

That issue became complicated because others chimed in and started to argue
that, rather than being a measure to rescue the servers from trouble, it
was actually a reflection of a universally accepted policy that every
millimetre of an area feature's boundary must be unambiguously defined and
visible on the ground, and the discussion rapidly deteriorated because that
definition, taken to its logical extreme, would exclude virtually all
rivers, lakes and streams from being distinct bodies of water, would
entirely exclude features such as bays, isthmi, peninsulae, and so on from
ever being mapped regardless of size or obvious closure, and in general
would dismiss topology as being entirely unimportant. The arguments went as
far as to have one user advance the claim that a number of counties and
townships north of me should not be mapped, despite having well-defined
borders in the inhabited regions, because portions of their boundaries have
never been successfully surveyed.

But somehow, those voices never gained entirely the upper hand.  If so,
features like `bay`, `peninsula`, `strait`, `isthmus`, `ridge`, `valley`
and so on would all bear prominent warnings on the Wiki that it is
inappropriate to map them. Somehow, the people who loudly proclaim that
objectivity and observability require that every feature be bright-line
observable in the field cannot bring themselves to do that, or know that
the community would reject it.

For myself, I've deferred to you on the matter - including refraining from
mapping even small features like Jamaica Bay (
https://www.openstreetmap.org/#map=12/40.6125/-73.8082) - despite the fact
that the specific feature is reasonably sized, local, quite different from
the Atlantic Ocean (calm water, much lower salinity, much greater tidal
range, and a very different ecosystem) and that I would very much like at
some point to produce a detailed paper map of my boyhood home town (
https://www.openstreetmap.org/relation/174930) including, of course,
labeling the waterways that lie only partially within its neatline. I'm
willing to accept for now that OSM cannot cope with that requirement and
I'll have to develop another system alongside OSM and manage multiple map
layers to produce such a thing.

That sort of desire - wishing to include some information about long routes
or about area features that are large, diffuse, imprecisely defined, or
otherwise difficult - appears to be fairly commonplace, given the number of
words that have been expended on the subject here and elsewhere. Those of
us to whom the topology of area features is important - for instance,
because we produce paper maps and wish to produce normal rendering,
including labeling, of area features that extend outside the neatline -
rapidly grew frustrated, and eventually the discussion died from
exhaustion, as discussions on this list usually do. Meanwhile, there's no
indication to mappers (for example, warnings in the popular editors) that
creating enormous area features is inappropriate because of inability of
the tools to deal with them.

Moreover, those who actually have the technical expertise to experiment
with solutions to the problem feel stymied at every turn by the gatekeepers
- who may also have the technical expertise, but have a different opinion
of the problem's importance. I've talked off-list with several skilled
programmers and data analysts who definitely believe that even if a
solution were to be developed, it would be rejected. There is certainly
zero interest from the gatekeepers in maintaining a discussion of the
requirements for such a thing - it turns into 'I haven't seen a good enough
solution yet, and I'll know it when I see it,' without an answer to, 'in
what way is a given proposal unsatisfactory and how might it improve?'
There's a natural temptation to transform, 'this problem is too hard for me
to solve in the time I have available' into 'this problem is too hard in
relation to its importance',