Re: [Tagging] Rio de la Plata edit war

[Frederik Ramm]

Hi,

On 03.08.20 22:41, Joseph Eisenberg wrote:
> I have previously proposed that estuaries should be mapped by extending
> the coastline upstream to the limit of the estuary, and also mapping the
> area of the estuary as water with water=estuary

I wonder if we're not becoming too theoretical by thinking about
scientific definitions. I know that we strive to have something
"verifiable" but at the same time I have a bad feeling about there being
a "coastline" in OSM where there is definitely no "coast" within dozens
of kilometers.

Sure, I can say "don't be too literal, natural=coastline doesn't mean
there has to be a coast, it's just for closing ocean polygons" but that
doesn't make it better really.

Sure, with current ocean drawing technology we need a "coastline" across
every river estuary at some point... but perhaps we should think beyond
that?

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

[Tagging] Have our tagging voting rules changed recently?

[Frederik Ramm]

Hi,

looking at the "bare_soil" proposal I was surprised to read:

"Any opposition vote without reason or suggestion will not be counted in
the voting process."

Is that something that we have added by consensus?

It sounds like a somewhat sneaky measure to ignore opposition votes, or
discourage those who cannot properly express their opposition in English
from voting in the first place. It also raises the question of what
requirements there are for a "reason or suggestion". If I vote no with a
reason "it stinks", will there then be someone who says "ah, this is not
a valid reason" and strips me of my vote? Who will that person be?

Has this been used in other votes in the past? I'm tempted to say it
would invalidate any vote but maybe it *is* indeed based on consensus
and I missed that.

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] Have our tagging voting rules changed recently?

[Andrew Harvey]

I'd suggest that if you vote no, it will be helpful for the community if
you could elaborate on why you're voting no, without enforcing a reason as
mandatory. Is it because this feature shouldn't be mapped, is it because
there is an alternative tag. So if the vote fails all this feedback can be
taken onboard for a revisal of the proposal and second round of voting.

On Tue, 4 Aug 2020 at 17:59, Frederik Ramm  wrote:

> Hi,
>
> looking at the "bare_soil" proposal I was surprised to read:
>
> "Any opposition vote without reason or suggestion will not be counted in
> the voting process."
>
> Is that something that we have added by consensus?
>
> It sounds like a somewhat sneaky measure to ignore opposition votes, or
> discourage those who cannot properly express their opposition in English
> from voting in the first place. It also raises the question of what
> requirements there are for a "reason or suggestion". If I vote no with a
> reason "it stinks", will there then be someone who says "ah, this is not
> a valid reason" and strips me of my vote? Who will that person be?
>
> Has this been used in other votes in the past? I'm tempted to say it
> would invalidate any vote but maybe it *is* indeed based on consensus
> and I missed that.
>
> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Have our tagging voting rules changed recently?

[Andy Mabbett]

On Tue, 4 Aug 2020 at 08:57, Frederik Ramm  wrote:

> Have our tagging voting rules changed recently?

Which rules?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Mateusz Konieczny via Tagging]

I partially reverted 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Ground&diff=prev&oldid=2014966
and followed
https://wiki.openstreetmap.org/wiki/Proposal_process#Voting

Note that 
"People should not just vote "oppose", they should give a reason for their 
proposal, and/or (preferably) suggestions."

is suggested at https://wiki.openstreetmap.org/wiki/Proposal_process#Voting
and that it is not a new addition, but still pure "no"
vote are valid ones.


Aug 4, 2020, 09:57 by frede...@remote.org:

> Hi,
>
> looking at the "bare_soil" proposal I was surprised to read:
>
> "Any opposition vote without reason or suggestion will not be counted in
> the voting process."
>
> Is that something that we have added by consensus?
>
> It sounds like a somewhat sneaky measure to ignore opposition votes, or
> discourage those who cannot properly express their opposition in English
> from voting in the first place. It also raises the question of what
> requirements there are for a "reason or suggestion". If I vote no with a
> reason "it stinks", will there then be someone who says "ah, this is not
> a valid reason" and strips me of my vote? Who will that person be?
>
> Has this been used in other votes in the past? I'm tempted to say it
> would invalidate any vote but maybe it *is* indeed based on consensus
> and I missed that.
>
> 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
>

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Mateusz Konieczny via Tagging]

To be more clear:
in 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Ground&diff=2018441&oldid=2018440

I removed 
"Any opposition vote without reason or suggestion will not be counted in the 
voting process."as it is an undiscussed modification of a proposal voting and a 
refusal to follow instructions
on https://wiki.openstreetmap.org/wiki/Proposal_process#Voting
Opposition votes without reason or suggestion are still valid and will be 
counted.

Though asking such voters for feedback/explanation is OK and it is
preferable to explain your vote.

Aug 4, 2020, 10:10 by tagging@openstreetmap.org:

> I partially reverted 
> https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Ground&diff=prev&oldid=2014966
> and followed
> https://wiki.openstreetmap.org/wiki/Proposal_process#Voting
>
> Note that 
> "People should not just vote "oppose", they should give a reason for their 
> proposal, and/or (preferably) suggestions."
>
> is suggested at > https://wiki.openstreetmap.org/wiki/Proposal_process#Voting
> and that it is not a new addition, but still pure "no"
> vote are valid ones.
>
>
> Aug 4, 2020, 09:57 by frede...@remote.org:
>
>> Hi,
>>
>> looking at the "bare_soil" proposal I was surprised to read:
>>
>> "Any opposition vote without reason or suggestion will not be counted in
>> the voting process."
>>
>> Is that something that we have added by consensus?
>>
>> It sounds like a somewhat sneaky measure to ignore opposition votes, or
>> discourage those who cannot properly express their opposition in English
>> from voting in the first place. It also raises the question of what
>> requirements there are for a "reason or suggestion". If I vote no with a
>> reason "it stinks", will there then be someone who says "ah, this is not
>> a valid reason" and strips me of my vote? Who will that person be?
>>
>> Has this been used in other votes in the past? I'm tempted to say it
>> would invalidate any vote but maybe it *is* indeed based on consensus
>> and I missed that.
>>
>> 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
>>
>
>

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 09:59, Frederik Ramm  wrote:
> 
> Has this been used in other votes in the past?



the instructions have always stated that opposing votes should explain why they 
are against it. In practice this is not a significant hurdle, because many 
reasons go like „for the same reasons as stated by Jane“.

IMHO it makes sense to ask for reasons, although not providing them shouldn’t 
allow for not counting the vote.

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Frederik Ramm]

Hi,

On 04.08.20 10:06, Andy Mabbett wrote:
>> Have our tagging voting rules changed recently?

> Which rules?

Should I have written "was our voting process changed recently", or what
exactly are you asking? I meant the established way of proposing and
voting for tags as outlined in
https://wiki.openstreetmap.org/wiki/Proposal_process.

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] addr:street for routes

[Sarah Hoffmann]

On Mon, Aug 03, 2020 at 04:28:43PM -0400, Jmapb wrote:
> On 8/3/2020 6:07 AM, Sarah Hoffmann wrote:
> 
> > There is some fuzzy matching, you can expect to work, for example
> > abbreviations like street -> st or even New York -> NY. But going from
> > ref=NY-214 to 'State Highway 214' is already a long stretch that requires
> > special local knowledge.
> 
> Understood. And this is a little out of scope for the tagging list but I
> suspect this kind of long-stretch fuzzy matching for numbered routes
> will be necessary to return decent search results for a large portion of
> the rural USA -- and I'd guess similar problems will be found in other
> countries.
> 
> At least for the New York State routes, Google, Apple, Microsoft, and
> HERE seem to get this right. I don't know of any OSM-centric maps that
> do, and I'm not savvy enough to know which are using Nominatim and which
> aren't.
> 
> (Offhand, AI seems like overkill for this! The variations are pretty
> formulaic.)

It has already been done before: https://github.com/openvenues/libpostal

The problem is that there are 200+ countries, each with their own strange
name variation the locals claim to be 'perfectly obvious why wouldn't a
geocoder...'. ;)

Long-term I'd like to see emerge some kind of community-curated alias
database, where mappers can contribute the local variations. But that is
still far off.

> For now I've had a go with verbose explicit tagging using  _name tags as
> you've suggested (ignoring JOSM's "alternative name without name" warnings):
> 
> ref=NY 214
> official_name=State Route 214
> alt_name=Route 214;Highway 214;State Highway 214;New
> York 214;New York State Route 214
> 
> I've used the USPS-rectified format for the `official_name`, which isn't
> exactly right (`postal_name` might be a better tag) but seems close enough.
> 
> It's unclear to me how useful it is to cram in all those
> semicolon-separated values under `alt_name`. Since this update,
> Nominatim is now giving decent (one block away) results for "58 State
> Route 214, Phoenicia NY" but nothing for "58 State Highway 214,
> Phoenicia NY" so maybe I just have to pick a single `alt_name` and maybe
> throw in a `local_name`? (Must confess, this sort of shoehorning starts
> to feel a little odd.)

Now Nominatim screws up the search (ironically because it does shorten
'State Highway' to 'sh') but that is really an implementation
issue. Your house has now picked up the right street:
https://nominatim.openstreetmap.org/details.php?osmtype=W&osmid=304812543&class=amenity

>  * Q) How should `addr:street` be tagged for an address along an
> unnamed way which is part of a numbered road-type route relation?

Follow-up question on that: are all route relation names/refs mapped as
route=highway in the US usable as an address part or is that restricted to
certain routes and/or regions (for example, rural only)?

Sarah

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Christoph Hormann]

On Tuesday 04 August 2020, Frederik Ramm wrote:
> Hi,
>
> looking at the "bare_soil" proposal I was surprised to read:
>
> "Any opposition vote without reason or suggestion will not be counted
> in the voting process."
>
> Is that something that we have added by consensus?

I don't think so - but i also think the question is a bit besides the 
point here.

The thing is the whole idea of proposal voting was originally meant as a 
standardized way to gauge if consensus has been achieved on a tagging 
question. Consensus does not require unanimity but it requires 
dissenting voices not being ignored and being integrated into to 
consensus position, to find the position that enjoys broadest possible 
support.  For that it is of course needed that dissenting voices do not 
just express their dislike per se but explain why they oppose the idea.

Unfortunately the proposal process is often used these days as a mere 
supermajority vote where the majority can push their uncompromising 
position against critique - no matter how well founded and well argued 
that critique might be.

That is one of the main reasons why i typically do not vote in tagging 
proposals.  If i criticize a tagging idea i usually have well founded 
reasons for that.  I require these to be either addressed or being 
convinced with arguments to change my opinion.  If that does not happen 
and a supermajority of voters can decide to ignore objections without 
engaging in a discussion on the merits and convincing me and other 
critical voices i am not going to legitimize the process with my 
participation.

It might actually be better to introduce the opposite rule - that 
yes-votes need to explain why they are willing to dismiss sustained 
critical voices in the discussion.  That would at least avoid people 
voting yes out of group-think, political allegiance or as a personal 
favor without having contemplated the merit of the proposal and of 
voices opposing it.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Colin Smale]

On 2020-08-04 10:06, Andrew Harvey wrote:

> I'd suggest that if you vote no, it will be helpful for the community if you 
> could elaborate on why you're voting no, without enforcing a reason as 
> mandatory. Is it because this feature shouldn't be mapped, is it because 
> there is an alternative tag. So if the vote fails all this feedback can be 
> taken onboard for a revisal of the proposal and second round of voting.

The explanation should possibly have been given earlier, during the
consultancy phase? In a vote, the only thing that should count towards
the outcome is how you vote, not why you voted that way. All votes have
equal weight, irrespective of their motivation. 

However, in the ensuing inquest it is obviously useful to understand why
a proposal was not supported by many people.. For that matter, it is
also useful to know what made people support it as well. 

Putting a proposal to the vote should IMHO not be done unless the
discussions are clearly pointing towards approval. A vote is not a
substitute for the discussion, it should be a confirmation that
consensus has been achieved.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Have our tagging voting rules changed recently?

[Andy Mabbett]

On Tue, 4 Aug 2020 at 10:26, Colin Smale  wrote:

> Putting a proposal to the vote should IMHO not be done unless the
> discussions are clearly pointing towards approval. A vote is not a
> substitute for the discussion, it should be a confirmation that
> consensus has been achieved.

With all the usual "we are not Wikipedia" caveats, this page might
make useful reading:

   
https://en.wikipedia.org/wiki/Wikipedia:Polling_is_not_a_substitute_for_discussion

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Andy Mabbett]

On Tue, 4 Aug 2020 at 09:46, Frederik Ramm  wrote:

> On 04.08.20 10:06, Andy Mabbett wrote:
> >> Have our tagging voting rules changed recently?
>
> > Which rules?
>
> Should I have written "was our voting process changed recently", or what
> exactly are you asking? I meant the established way of proposing and
> voting for tags as outlined in
> https://wiki.openstreetmap.org/wiki/Proposal_process.

What I was asking - exactly - was which were the rules to which you
referred, explicitly, both in your question and in the subject heading
of your email.

Now that you have provided a URL, I see that they are not rules at
all, and that the page includes in its introduction the caveat:

  This page is designed to assist anyone considering putting forward a tag
   proposal, with the aim of speeding the tag proposing process. It is not
   meant as a set of absolute rules, but as a guide.

and indeed that this is, as that introduction also says, merely:

   one of multiple ways to introduce and discuss new tags for features
   and properties

I'm glad we've cleared that up.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Jez Nicholson]

Frederik asks, "was our voting process changed recently", to which I
believe the answer is, "yes, abstentions are no longer included in the
count"

Please correct me if I'm mistaken. I don't at first glance see anything in
the process rules, but I'm outside in the sun using a phone...

On Tue, 4 Aug 2020, 10:28 Colin Smale,  wrote:

> On 2020-08-04 10:06, Andrew Harvey wrote:
>
> I'd suggest that if you vote no, it will be helpful for the community if
> you could elaborate on why you're voting no, without enforcing a reason as
> mandatory. Is it because this feature shouldn't be mapped, is it because
> there is an alternative tag. So if the vote fails all this feedback can be
> taken onboard for a revisal of the proposal and second round of voting.
>
>
> The explanation should possibly have been given earlier, during the
> consultancy phase? In a vote, the only thing that should count towards the
> outcome is how you vote, not why you voted that way. All votes have equal
> weight, irrespective of their motivation.
>
> However, in the ensuing inquest it is obviously useful to understand why a
> proposal was not supported by many people.. For that matter, it is also
> useful to know what made people support it as well.
>
> Putting a proposal to the vote should IMHO not be done unless the
> discussions are clearly pointing towards approval. A vote is not a
> substitute for the discussion, it should be a confirmation that consensus
> has been achieved.
>
>
> ___
> 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] Feature Proposal - Voting - (Ground: natural=bare_soil)

[pangoSE]

Thanks for the heads up Joseph. I also read what Imagico wrote1 and voted no.
I recommend others to do the same.

Cheers 
pangoSE
1 
https://wiki.openstreetmap.org/w/index.php?title=Talk:Proposed_features/Ground&curid=253931&diff=2016970&oldid=2016363

Joseph Eisenberg  skrev: (3 augusti 2020 23:17:18 
CEST)
>Everyone, the voting period for natural=bare_ground is still open for 4
>more days.
>
>I would recommend voting "no" on the current definition, unfortunately.
>
>As mentioned above, the current definition is far too broad, and could
>easily be construed to include areas under construction, areas of bare
>soil
>due to use by people as a pathway or road area, and many sorts of arid
>and
>semi-natural areas, including those that are partially covered by
>shrubs,
>heath, grass or other sparse vegetation, or even areas of farmland that
>are
>currently fallow.
>
>Please see the discussion and objections on
>https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Ground
>
>I think it is a good idea to have a way to tag bare soil which is not
>sand
>(natural=sand) or mostly stones (natural=shingle/scree) or mud, but we
>need
>a clear, limited definition which does not fit with human-use areas
>like
>roads, dirt parking lots, construction sites, abandoned quarries etc,
>and
>there needs to be more consideration about when the tag should be used
>instead of natural=heath and natural=scrub in arid regions where there
>are
>scattered bushes.
>
>For the proposal author, I would suggest mapping some local features in
>your area which would fit the proposed definition, and then come back
>with
>photos plus aerial imagery of the areas which ought to be mapped with
>this
>tag. So far it has been mostly hypothetical, which makes it hard to
>understand which sorts of landscapes would qualify for this tag.
>
>- Joseph Eisenberg
>
>On Mon, Jul 27, 2020 at 5:58 AM Martin Koppenhoefer
>
>wrote:
>
>>
>>
>> sent from a phone
>>
>> > On 27. Jul 2020, at 13:41, Michael Montani 
>> wrote:
>> >
>> > I eventually found on-the-ground images of the feature I would like
>to
>> propose / map.
>>
>>
>> are these suggested to be represented as polygons? How would the
>border be
>> determined? I looks from the imagery as if there is a smooth
>transition of
>> these „features“ and neighbouring land which isn’t completely bare.
>Did you
>> try to map some of these and if yes, could you please post a link to
>an
>> area where a few are mapped?
>>
>> Cheers Martin
>> ___
>> 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] Rio de la Plata edit war

[Christoph Hormann]

On Monday 03 August 2020, mural...@montevideo.com.uy wrote:
>
> i will try.
>
>
> in my last mail i'm questioning the coastline placement in several
> rivers. so,
> -what are we mapping the coastline for?
> -what we want from the "coastline"?
> -what questions are we going to answer, or could we answer, with that
> modeling of the coastline/world? (or we just draw it for the
> renderer)

In general in OSM

* we are not mapping for a specific purpose, we are documenting local 
knowledge about the verifiable geography of the world.
* what individual tags mean and how they are to be used is decided by 
the mappers using them - but not individually on a case-by-case basis 
but collectively by all the mappers of OSM together.

The problem we have here is that there seems to be a fairly massive 
discrepancy between what some local mappers in the region seem to view 
natural=coastline to mean and what mappers in other parts of the world 
have in mind there.  My request for you to formulate a universal rule 
is meant to gauge that difference and evaluate options for a consensus.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Matthew Woehlke]

On 03/08/2020 19.56, Graeme Fitzpatrick wrote:

On Tue, 4 Aug 2020 at 01:10, Matthew Woehlke wrote:

Parking lot access roads are a common example; I don't really feel that
these are "driveways", but I also prefer to reserve "parking_aisle" for
ways that actually *have* parking spaces along them.


Main through road across the front of the shopping centre, with
parking_aisles opening off it, put with a dozen or so specialised parking
spaces (disabled, ambulance, reserved, electric vehicle charging) on it -
does that change it from "access" to another parking aisle?


Maybe. It's possible I'd tag that as a parking_aisle. The point was more 
though that I wouldn't use parking_aisle for something that *doesn't* 
have parking spaces.



service=driveway/drive-through -> Service way for access to a fuel station

IMHO, a drive-through is a very specific type of way which involves a
service window. *Maybe* you could argue for that in case of a
full-service fuel station, but I wouldn't use it otherwise. (Note:
"drive through" implies that the vehicle will engage in stopping but no
standing or parking.)


No, driveway/-through is good for a fuel station, as well as anywhere else
that you don't get out of your car to be served eg take-away, car wash,
bottle shop (liquor store)


"Anywhere else that you don't get out of your car to be served" is 
effectively what I proposed, but (at least in the US, nearly all) fuel 
stations do *not* meet that criteria.


--
Matthew

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

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

Almost all of the arguments you bring up here are cultural or political 
in nature.  Discussing those will lead us nowhere.  Hence my suggestion 
to you in the other mail to consider this exclusively from the physical 
geographic perspective.

The only point i could identify in your writing that is not 
cultural/political in nature is the claim that the Rio de la Plata was 
first mapped 6 years ago when the riverbank polygon was created.  That 
is not true.  The Rio de la Plata was mapped long before - first 
significant parts started in 2011 already, by end 2012 the mapping was 
complete:

https://overpass-turbo.eu/s/WK9

and it stayed tagged as natural=coastline until you changed that in:

https://www.openstreetmap.org/changeset/20290034

After that there were countless attempts to move up the coastline 
closure again - all of which however were soon reverted.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Rio de la Plata edit war

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 14:16, Christoph Hormann  wrote:
> 
> Almost all of the arguments you bring up here are cultural or political 
> in nature.  


Christoph, I guess it could be seen from looking at the email headers or when 
reading in a threaded view, but for the convenience of everybody I’d ask you to 
add a bit of context to your contributions here (in particular to whom you 
reply)

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

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

On Tuesday 04 August 2020, Martin Koppenhoefer wrote:
>
> Christoph, I guess it could be seen from looking at the email headers
> or when reading in a threaded view, but for the convenience of
> everybody I’d ask you to add a bit of context to your contributions
> here (in particular to whom you reply)

Sorry - i sometimes forget that there are people who seriously read 
mailing lists in a non-threaded view.

That mail was in reply to muralito's detailed comments in reply to 
Frederik:

> As with any terms in OSM context, we should'nt literaly translate the
> terms betwen languages because we can incurr in errors. Sometimes
> also between dialects of the same language the same word have
> different meanings. In this case, "coastline" should'nt be translated
> to spanish as "costa". Acording to RAE.es (official institution for
> the spanish language), it defines "costa" as "Orilla del mar, de un
> río, de un lago, etc., y tierra que está cerca de ella". Translated,
> in spanish "costa" does not mean only seashore ("Orilla de mar"), it
> could be a river bank ("Orilla de río"), lake shore ("Orilla de
> lago". So that any city or comunity defines itself as "costa" or
> "costera", or "SHORE" or any other term, is not related to the OSM
> coastline definition. It is also different from the definition of
> "coast" from Oxford Dictionary (6th edition that i have in hand),
> which refers to the land besides the ocean or the sea.
>
> In some cases, like this, the wikipedia article lacks the accuracy to
> define river. The river starts in Paralelo Hito Punta Gorda and ends
> in the line between Punta del Este and Punta Rasa.
>
> Here in Uruguay we have two "coast", the oceanic coast
> (natural=coastline) which begins in Punta del Este and goes to the
> border with Brazil. The other "coast" is the river, which is why
> Montevideo, Buenos Aires, etc, are known as "ciudad ribereña"
> (riverside city). The oceanic coast in the Argentina side, also
> starts in Punta Rasa. Those two different coast are very different
> All this facts are clearly visible and verifiable being here. Just
> like other thing they are not visible in aerial imagery [3].
>
> The motivation to not map as coastline are not political, but
> technical. The political issues were solved at least 60 years ago,
> with scientific consensus. [1][2] There is no other place where the
> coastline could be placed. There has been, and there is wide
> consensus in both local communities (i cannot say absolute consensus
> without checking). The limit of Rio de la Plata is historically
> recognized by politics and scientists. The legal, or official
> definition is settled at least 60 years ago, by political means
> (binational protocols, UN international treaty, IHO definitions), y
> scientific studies. Also newer/modern scientific studies and papers,
> based on salinity, batimetry, water flows, sediments, mathematical
> models, etc. confirms what the old scientific studies and political
> have agreed that the limit of the ocean is between Punta del Este and
> Punta Rasa, so there should be no discussion here. Besides this, in
> 2016 the UN extended the sovereignty rights of Uruguay in the
> continental platform for 350 nautical miles [11], but this is another
> issue and is not mapped yet. And speaking about politics, both navies
> pursues industrial fishing pirates, mostly from Asia.
>
> This is just a very width river, with a basin size like India, or 10
> times Germany, it obviously brings a very large amount o fresh water,
> which influences the salinity of the ocean waters several tenths of
> km inner into the ocean from Punta Rasa or Punta del Este.
>
> According to some people, mapping the coastline where I think where
> it should be, and where it was since the river was mapped at least 6
> years ago, that kind of mapping, maybe some renders create artifacts
> because they consider this as inner water and not ocean. I see no
> problem in that, because in the aerial photo [3] the colour of the
> river is like any other river, and not like an ocean. For example, i
> linked two videos showing the clearly the difference between Rio de
> la Plata and Atlantic Ocean [9][10]
>
> If you choose to map this riverbank as coastline, is just mapping for
> convenience (for convenience of the renderer), to see the world map
> as you prefer to see it, but it is not modelling the world as it is.
>
> By the way, the problem in january 2020 with the rendering toolchain
> fails were not caused for moving the coastline to the ocean/river
> limit, as it was there for several years, but were caused by a
> changeset which changed the tagging of the riverbank as coastline.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 11:16, Christoph Hormann  wrote:
> 
> It might actually be better to introduce the opposite rule - that 
> yes-votes need to explain why they are willing to dismiss sustained 
> critical voices in the discussion.


This is a good point, and it is also already happening frequently: people who 
are not the proponent are commenting on dissenting arguments. Maybe this should 
be added explicitly as a suggestion to the process.

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

Re: [Tagging] Have our tagging voting rules changed recently?

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 11:44, Jez Nicholson  wrote:
> 
> Frederik asks, "was our voting process changed recently", to which I believe 
> the answer is, "yes, abstentions are no longer included in the count"


The “new” process is also flawed, as a no vote can bring a proposal to approval 
which might fail otherwise.
In particular if 8 people have voted yes and 1 no, it will fail but another no 
will let it pass. 

Cheers 
Martin



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

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Christoph Hormann" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Martes, 4 de Agosto 2020 9:14:32
> Asunto: Re: [Tagging] Rio de la Plata edit war

> Almost all of the arguments you bring up here are cultural or political
> in nature.  Discussing those will lead us nowhere.  Hence my suggestion
> to you in the other mail to consider this exclusively from the physical
> geographic perspective.
> 
> The only point i could identify in your writing that is not
> cultural/political in nature is the claim that the Rio de la Plata was
> first mapped 6 years ago when the riverbank polygon was created.  That
> is not true.  The Rio de la Plata was mapped long before - first
> significant parts started in 2011 already, by end 2012 the mapping was
> complete:
> 
> https://overpass-turbo.eu/s/WK9
> 
> and it stayed tagged as natural=coastline until you changed that in:
> 
> https://www.openstreetmap.org/changeset/20290034
> 
> After that there were countless attempts to move up the coastline
> closure again - all of which however were soon reverted.
> https://overpass-turbo.eu/s/WKi
> --
> Christoph Hormann
> http://www.imagico.de/
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

I linked several scientific studies that clearly shows and are verifiable 
geographic evidence that this is not an oceanic coast, its a riverbank and 
should not be tagged as coastline. Not cultural, not politics. I just linked 
the treaties to show that there are no political motivations in my thinking, 
because the political issues were already solved many years ago. Anyway, most 
limits, including natural ones are political facts, agreement between nations, 
also including defacto limits because war is also politics.
It's only physical geographic perspective, its a riverbank, not an ocean, its 
inner fresh water.

You are mixing things. The coastline is not the river. The waterway=river for 
Rio de la Plata was not mapped until i mapped it in 
https://www.openstreetmap.org/changeset/19137685 in November 2013. That is 6 
years, and will be 7 years in 3 months. Modify your query to search for 
waterway=river and you will see.
https://overpass-turbo.eu/s/WKi . And no mapping is ever complete, at less here 
where e.g. new sediment islands keeps appearing, old islands increase it size, 
and nearby islands joins toghether.

I changed the tagging because it was and it is wrong to tag this as coastline, 
it's a riverbank, as i have been saying for years. The coastline should be in 
the line because to the west there are inner waters and to the east the ocean.

Regards,
M.



---

Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin costo.

Informate si aplicás aquí.

mvdfactura.uy

---



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

Re: [Tagging] Rio de la Plata edit war

[Adam Franco]

It seems to me that the main underlying conflict is that (at least in the
default Carto rendering on openstreetmap.org a few years ago) the Rio Plata
was getting rendered as land at low-zooms and South America simply looks
wrong when such a large water area is rendered as land.

https://github.com/gravitystorm/openstreetmap-carto/issues/1604 is a very
long issue thread that addresses this land/water rendering problem,
starting first with some of the Great Lakes not rendering, then expanding
to cover other water areas. I'm not familiar enough with the Carto code to
know the current state of things, but would this rendering issue still be
present today if the coastline was drawn from Punta del Este to Punta Rasa
as muralito suggests? If this rendering issue has been addressed then it
feels to me like the stakes of the "coastline" tagging placement become
much lower.

My impression is that low-zoom renderers seem to often interpret
"coastline" as "the junction between land and 'big water'" whereas people
standing on land looking at water might often interpret "coastline" as
solely "the junction between land and ocean/sea" and may not want to
include rivers, estuaries, canals, navigation channels, salt-marshes,
protected bays, and other features that sit a little bit away from where
ocean waves are crashing on the beach. While usually these features are
small enough to ignore at low-zoom, Rio Plata, the Saint Lawrence estuary
, Long
Island Sound,
 Pamlico
Sound ,
and others are big enough to be visible at low-zooms qualify as "big water"
connected to the ocean even if they aren't fully ocean themselves.
Similarly does the "coast" shift out to include barrier islands and enclose
the protected waters behind them? Looking at current mapping it does
sometimes and doesn't other times.

All that said, there are probably many other data consumers who aren't able
to leverage the techniques used by Carto and would like to make their own
decisions about how to render the distinctions between land, fresh water,
and big salty water. Being able to tag an estuarine environment with its
own tags could allow data consumers to make their own choices about
rendering and placement. Some potential use cases:

   - A general purpose renderer like Carto would probably want to display
   estuaries as water to make the land shape more closely match low-zoom
   satellite imagery. Most traditional general-purpose maps care more about
   the distinction between land and water rather than what the properties of
   the water are

   - A marine ecology map might wish to render oceans and estuaries, but
   hide rivers and land-based features from display.

   - A map focused on rivers might want to highlight the distinction
   between purely fresh-water rivers and estuaries in a more pronounced way
   than a general-purpose map would want to.

Joseph previously suggested dedicated estuary tagging:

On Tue, 4 Aug 2020 at 06:43, Joseph Eisenberg 
wrote:

>
> I have previously proposed that estuaries should be mapped by extending
> the coastline upstream to the limit of the estuary, and also mapping the
> area of the estuary as water with water=estuary
>

Unfortunately, only a waterfall or dam is going to provide the kind of
hard-lined transition point between ocean and river that would allow a
"coastline" way to cut across the water without ambiguity as to its
placement. All other transitions points on every river-mouth (estuary or
otherwise) are going to be ever changing with rainfall and tides and at
best will only ever be an agreed-upon average or culturally defined
placement. It is simply impossible to verifiably map an ever-shifting
gradient with a single line across the water.

I'd suggest that estuaries get their own tagging as areas (maybe with
sub-sections covering differing properties like tidal influence, salinity
thresholds, etc) and let the "coastline" cross it wherever local mappers
agree a good average threshold is met. The estuary areas should have their
extent based on physically defined thresholds like "average annual salinity
greater than x%" or "average current dominated by ocean-flow vs
river-flow".  Data consumers can then be free to use the mapped "coastline"
line or ignore it where it crosses an estuary, including the greatest
extent of the estuary in their interpretation of "coast" or the most
minimal.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

On Tuesday 04 August 2020, mural...@montevideo.com.uy wrote:
>
> I linked several scientific studies that clearly shows and are
> verifiable geographic evidence that this is not an oceanic coast, its
> a riverbank [...]

I am not going to start a discussion here on the semantics of terms 
like 'ocean', 'riverbank', 'coast' or similar which are inherently 
culture specific and political.

So i repeat my request:

could you formulate a generic rule for coastline placement similar to 
what i formulated in

https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

that 

(a) allows for the coastline placement you favor in case of the Rio de 
la Plata
(b) is based on verifiable physical geography criteria that can 
practically be checked by mappers and
(c) that is compatible to most of the current coastline placements at 
river mouths around the world?

If you can do that we can try to have a productive discussion without 
delving into the swamp of politics and cultural differences and maybe 
can find a consensus position that everyone can be satisfied with.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[David Dean]

Once again, thanks for everyone's great comments, but I'm not entirely sure
what, if any, consensus we can draw from our discussions here.

To my mind, we are all in agreement that we should have values for the
service tag for 'main parking access' and 'main property/campus access',
although some of us believe that the same tagging could be used for both.


# Parking Access

There are already 2K examples of service=parking in use around the world (
https://taginfo.openstreetmap.org/tags/service=parking), and while I can't
claim to have done an exhaustive study, it appears that it is used for the
purpose of the main driveways through a parking lot.

However, I am certainly open to the idea that it could be confusing as
there often may not be parking explicitly on the serice=parking way itself.

So, it's a trade-off between reflecting what seems to be established usage,
or to come up with a better tagging that we hope to become the new
established usage.

*If* we want to push for a new established usage, how about
service=parking_access ?


# Other Property/Facility/Campus Access

There are already 800 examples of service=access in use around the world (
https://taginfo.openstreetmap.org/tags/service=access), and while I also
can't claim to have done an exhaustive study, it does appear to be used for
the purpose that we have been discussing in this thread.

In this case, I certainly understand the objection that this doesn't
actually mean a lot - as all highway=service ways are for accessing
something.

Once again, it's a trade-off between reflecting what seems to be a minor
level of established usage, or to come up with a better tagging that we
hope to become the new established usage.

*If* we want to push for a new established usage, how about
service=main_access ?


Happy to hear everyone's thoughts here, and I hope to get something we can
vote on on the wiki soon.

- David

On Tue, 4 Aug 2020 at 21:43, Matthew Woehlke 
wrote:

> On 03/08/2020 19.56, Graeme Fitzpatrick wrote:
> > On Tue, 4 Aug 2020 at 01:10, Matthew Woehlke wrote:
> >> Parking lot access roads are a common example; I don't really feel that
> >> these are "driveways", but I also prefer to reserve "parking_aisle" for
> >> ways that actually *have* parking spaces along them.
> >
> > Main through road across the front of the shopping centre, with
> > parking_aisles opening off it, put with a dozen or so specialised parking
> > spaces (disabled, ambulance, reserved, electric vehicle charging) on it -
> > does that change it from "access" to another parking aisle?
>
> Maybe. It's possible I'd tag that as a parking_aisle. The point was more
> though that I wouldn't use parking_aisle for something that *doesn't*
> have parking spaces.
>
> >> service=driveway/drive-through -> Service way for access to a fuel
> station
> >>
> >> IMHO, a drive-through is a very specific type of way which involves a
> >> service window. *Maybe* you could argue for that in case of a
> >> full-service fuel station, but I wouldn't use it otherwise. (Note:
> >> "drive through" implies that the vehicle will engage in stopping but no
> >> standing or parking.)
> >
> > No, driveway/-through is good for a fuel station, as well as anywhere
> else
> > that you don't get out of your car to be served eg take-away, car wash,
> > bottle shop (liquor store)
>
> "Anywhere else that you don't get out of your car to be served" is
> effectively what I proposed, but (at least in the US, nearly all) fuel
> stations do *not* meet that criteria.
>
> --
> Matthew
>
> ___
> 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] Rio de la Plata edit war

[Alan Mackie]

On Tue, 4 Aug 2020, 14:19 ,  wrote:

> - Mensaje original -
> > De: "Christoph Hormann" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Martes, 4 de Agosto 2020 9:14:32
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > Almost all of the arguments you bring up here are cultural or political
> > in nature.  Discussing those will lead us nowhere.  Hence my suggestion
> > to you in the other mail to consider this exclusively from the physical
> > geographic perspective.
> >
> > The only point i could identify in your writing that is not
> > cultural/political in nature is the claim that the Rio de la Plata was
> > first mapped 6 years ago when the riverbank polygon was created.  That
> > is not true.  The Rio de la Plata was mapped long before - first
> > significant parts started in 2011 already, by end 2012 the mapping was
> > complete:
> >
> > https://overpass-turbo.eu/s/WK9
> >
> > and it stayed tagged as natural=coastline until you changed that in:
> >
> > https://www.openstreetmap.org/changeset/20290034
> >
> > After that there were countless attempts to move up the coastline
> > closure again - all of which however were soon reverted.
> > https://overpass-turbo.eu/s/WKi
> > --
> > Christoph Hormann
> > http://www.imagico.de/
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> I linked several scientific studies that clearly shows and are verifiable
> geographic evidence that this is not an oceanic coast, its a riverbank and
> should not be tagged as coastline. Not cultural, not politics. I just
> linked the treaties to show that there are no political motivations in my
> thinking, because the political issues were already solved many years ago.
> Anyway, most limits, including natural ones are political facts, agreement
> between nations, also including defacto limits because war is also politics.
> It's only physical geographic perspective, its a riverbank, not an ocean,
> its inner fresh water.
>
> You are mixing things. The coastline is not the river. The waterway=river
> for Rio de la Plata was not mapped until i mapped it in
> https://www.openstreetmap.org/changeset/19137685 in November 2013. That
> is 6 years, and will be 7 years in 3 months. Modify your query to search
> for waterway=river and you will see.
> https://overpass-turbo.eu/s/WKi . And no mapping is ever complete, at
> less here where e.g. new sediment islands keeps appearing, old islands
> increase it size, and nearby islands joins toghether.
>
> I changed the tagging because it was and it is wrong to tag this as
> coastline, it's a riverbank, as i have been saying for years. The coastline
> should be in the line because to the west there are inner waters and to the
> east the ocean.
>
> Regards,
> M.
>
>
>
>
> ---
>
> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin
> costo.
>
> Informate si aplicás aquí.
>
> mvdfactura.uy
>
>
> ---
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


There seems to be confusion here between mapping a feature and having it
named. I suspect too much weight is being given to names generally in this
discussion even if this is not explicitly stated. Something OSM considers a
bay may be called a cove in the name, named tidal "creeks" are mapped as
tidal_channel etc. The name can't be the final arbiter of tagging else in
the extreme case we would be rendering Rio de Janeiro in blue along with a
whole chain of coffeeshops.

In this case it is the physical feature that is in question not the extent
of the area that holds that name. The name can easily be tagged separately
on the agreed political boundary.

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

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

On Tuesday 04 August 2020, Adam Franco wrote:
> It seems to me that the main underlying conflict is that (at least in
> the default Carto rendering on openstreetmap.org a few years ago) the
> Rio Plata was getting rendered as land at low-zooms and South America
> simply looks wrong when such a large water area is rendered as land.
>
> https://github.com/gravitystorm/openstreetmap-carto/issues/1604 is a
> very long issue thread [...]

That is old history.

OSM-Carto does not distinguish between rendering of riverbank polygons 
and rendering of the water polygons created from the coastline data.  
The only difference at the moment is that a (cartographically 
counterproductive) way_area filtering is applied to the riverbank and 
natural=water polygons.  That has been reduced significantly earlier 
this year in

https://github.com/gravitystorm/openstreetmap-carto/pull/4060

but still distorts rendering to some extent.  It however is not relevant 
for large riverbank polygons like we discuss here.

As i have said earlier in this discussion it would be highly desirable 
for consistent mapping if we would actually distinguish different 
waterbody classes in rendering.  A change for that has been suggested 
last October:

https://github.com/gravitystorm/openstreetmap-carto/pull/3930

was already merged but then reverted due to opposition from one of the 
maintainers.  There is a new suggestion to implement this:

https://github.com/gravitystorm/openstreetmap-carto/pull/4128

but it seems still contested.  Getting this change merged and released 
would go a long way towards mappers developing consensus on coastline 
placement since it would provide feedback on the coastline position 
without favoring a particular placement.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Christoph Hormann" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Martes, 4 de Agosto 2020 8:04:55
> Asunto: Re: [Tagging] Rio de la Plata edit war

> On Monday 03 August 2020, mural...@montevideo.com.uy wrote:
>>
>> i will try.
>>
>>
>> in my last mail i'm questioning the coastline placement in several
>> rivers. so,
>> -what are we mapping the coastline for?
>> -what we want from the "coastline"?
>> -what questions are we going to answer, or could we answer, with that
>> modeling of the coastline/world? (or we just draw it for the
>> renderer)
> 
> In general in OSM
> 
> * we are not mapping for a specific purpose, we are documenting local
> knowledge about the verifiable geography of the world.
> * what individual tags mean and how they are to be used is decided by
> the mappers using them - but not individually on a case-by-case basis
> but collectively by all the mappers of OSM together.
> 
> The problem we have here is that there seems to be a fairly massive
> discrepancy between what some local mappers in the region seem to view
> natural=coastline to mean and what mappers in other parts of the world
> have in mind there.  My request for you to formulate a universal rule
> is meant to gauge that difference and evaluate options for a consensus.
> 

Sure, there seems to be huge discrepancy with the meanings of the coastline, 
and as you said, all discrepancy is from armchair mappers. There is wide 
consensus in both local communities.

That is what my questions were trying to clarify, and your answers do not go in 
that direction, I do not ask in general in OSM, I specifically ask about the 
coastline. On that we have to agree. Once is it clear what we need or want the 
coastline to model we could determine where to place it.

It seems that is like the Great Lakes, that were initially mapped as 
natural=coastline for the renderer, and later corrected to natural=water. The 
same is here.

What it seems to be the problem most mappers see is in the "map", that the 
natural=coastline and the natural=water are rendered at different zooms, so 
it's a rendering problem. Seems that people interested on how it renders are 
trying to force the data so the render fulfills they expectations. Based on 
size Rio de la Plata  should appear in a rendering, sure yes, should be 
rendered as ocean, no, it should be rendered as other rivers, but also in low 
zooms. It's simply, just say that people want to force the coastline.

Going back to an example, for us it doesn't make sense that the coastline is 
drawed 70 km inland in Elbe river.

Regards,
M.



---

Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin costo.

Informate si aplicás aquí.

mvdfactura.uy

---



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

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Christoph Hormann" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Martes, 4 de Agosto 2020 11:17:32
> Asunto: Re: [Tagging] Rio de la Plata edit war

> On Tuesday 04 August 2020, mural...@montevideo.com.uy wrote:
>>
>> I linked several scientific studies that clearly shows and are
>> verifiable geographic evidence that this is not an oceanic coast, its
>> a riverbank [...]
> 
> I am not going to start a discussion here on the semantics of terms
> like 'ocean', 'riverbank', 'coast' or similar which are inherently
> culture specific and political.
> 
> So i repeat my request:
> 
> could you formulate a generic rule for coastline placement similar to
> what i formulated in
> 
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
> 
> that
> 
> (a) allows for the coastline placement you favor in case of the Rio de
> la Plata
> (b) is based on verifiable physical geography criteria that can
> practically be checked by mappers and
> (c) that is compatible to most of the current coastline placements at
> river mouths around the world?
> 
> If you can do that we can try to have a productive discussion without
> delving into the swamp of politics and cultural differences and maybe
> can find a consensus position that everyone can be satisfied with.
> 

It's all about semantics.

How could I answer your question if you are not able to define what you mean by 
natural=coastline?
We must first agree on what features we call it coastline, and then I can 
explain where I think it should be drawn.

Regards,
M.



---

Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin costo.

Informate si aplicás aquí.

mvdfactura.uy

---



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

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Alan Mackie" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Martes, 4 de Agosto 2020 11:35:29
> Asunto: Re: [Tagging] Rio de la Plata edit war

> On Tue, 4 Aug 2020, 14:19 , < mural...@montevideo.com.uy > wrote:

>> - Mensaje original -
>> > De: "Christoph Hormann" < o...@imagico.de >
>> > Para: "Tag discussion, strategy and related tools" < 
>> > tagging@openstreetmap.org >
>> > Enviados: Martes, 4 de Agosto 2020 9:14:32
>> > Asunto: Re: [Tagging] Rio de la Plata edit war

>> > Almost all of the arguments you bring up here are cultural or political
>> > in nature. Discussing those will lead us nowhere. Hence my suggestion
>> > to you in the other mail to consider this exclusively from the physical
>> > geographic perspective.

>> > The only point i could identify in your writing that is not
>> > cultural/political in nature is the claim that the Rio de la Plata was
>> > first mapped 6 years ago when the riverbank polygon was created. That
>> > is not true. The Rio de la Plata was mapped long before - first
>> > significant parts started in 2011 already, by end 2012 the mapping was
>> > complete:

>> > https://overpass-turbo.eu/s/WK9

>> > and it stayed tagged as natural=coastline until you changed that in:

>> > https://www.openstreetmap.org/changeset/20290034

>> > After that there were countless attempts to move up the coastline
>> > closure again - all of which however were soon reverted.
>> > https://overpass-turbo.eu/s/WKi
>> > --
>> > Christoph Hormann
>> > http://www.imagico.de/

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

>> I linked several scientific studies that clearly shows and are verifiable
>> geographic evidence that this is not an oceanic coast, its a riverbank and
>> should not be tagged as coastline. Not cultural, not politics. I just linked
>> the treaties to show that there are no political motivations in my thinking,
>> because the political issues were already solved many years ago. Anyway, most
>> limits, including natural ones are political facts, agreement between 
>> nations,
>> also including defacto limits because war is also politics.
>> It's only physical geographic perspective, its a riverbank, not an ocean, its
>> inner fresh water.

>> You are mixing things. The coastline is not the river. The waterway=river for
>> Rio de la Plata was not mapped until i mapped it in
>> https://www.openstreetmap.org/changeset/19137685 in November 2013. That is 6
>> years, and will be 7 years in 3 months. Modify your query to search for
>> waterway=river and you will see.
>> https://overpass-turbo.eu/s/WKi . And no mapping is ever complete, at less 
>> here
>> where e.g. new sediment islands keeps appearing, old islands increase it 
>> size,
>> and nearby islands joins toghether.

>> I changed the tagging because it was and it is wrong to tag this as 
>> coastline,
>> it's a riverbank, as i have been saying for years. The coastline should be in
>> the line because to the west there are inner waters and to the east the 
>> ocean.

>> Regards,
>> M.

>> ---

>> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin 
>> costo.

>> Informate si aplicás aquí.

>> mvdfactura.uy

>> ---

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

> There seems to be confusion here between mapping a feature and having it 
> named.
> I suspect too much weight is being given to names generally in this discussion
> even if this is not explicitly stated. Something OSM considers a bay may be
> called a cove in the name, named tidal "creeks" are mapped as tidal_channel
> etc. The name can't be the final arbiter of tagging else in the extreme case 
> we
> would be rendering Rio de Janeiro in blue along with a whole chain of
> coffeeshops.

> In this case it is the physical feature that is in question not the extent of
> the area that holds that name. The name can easily be tagged separately on the
> agreed political boundary.


In this case I think the problem is that some mappers wants a riverbank to be 
tagged as natural=coastline just for the render at lower zooms, but fail to 
recognize that fact. The fact is that is it is a river, very large river.

But the coastline problem is much larger than this case, like Elbe River.

Regards,
M.



---

Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin cos

Re: [Tagging] addr:street for routes

[Kevin Kenny]

On Tue, Aug 4, 2020 at 4:57 AM Sarah Hoffmann  wrote:

> Follow-up question on that: are all route relation names/refs mapped as
> route=highway in the US usable as an address part or is that restricted to
> certain routes and/or regions (for example, rural only)?
>
>
It's case-by-case.  Near me, New York State Route 146 (which was used as an
example elsewhere) wanders.

There's a stretch of a few blocks
(https://www.openstreetmap.org/way/5640056 and
neighbouring ways) near a shopping mall where it's 'Clifton Park
Boulevard', but nobody knows that name because there are big overhead
direction signs that carry only the route number.  On either side, it's
called just 'State Route 146' and has no other name. The post office
prefers '806 [State] Route 146' as a building address, but '806 Clifton
Park Boulevard' is deliverable.

Farther south/west (146 does not have consistent cardinal directions!) 146
is co-aligned with city streets.  Balltown Road (
https://www.openstreetmap.org/way/338036383 etc.) is signed 146, but nobody
calls it anything other than Balltown Road.  Addressing mail to '1617 Route
146' would likely face delays and misdeliveries because it woiuld be
ambiguous: 1617 Balltown Road
https://www.openstreetmap.org/way/689572012 fronts
on Route 146, but so does 1617 [Upper] Union Street
https://www.openstreetmap.org/node/804483895 , and I haven't done the
address points but there's likely a 1617 on Brandywine Avenue
https://www.openstreetmap.org/way/5646367, Hamburg Street
https://www.openstreetmap.org/way/53306647 , or Carman Road
https://www.openstreetmap.org/way/135620106

Beyond Western Avenue, there's a brief stretch
https://www.openstreetmap.org/way/159115284 where 146 has no other name.
For a few blocks, it follows Main Street, Maple Avenue, and Township Road
through the village of Altamont. It retains the 'Township Road' name west
to the county line, but the situation is fuzzier. Mail will be addressed to
'1234 Township Road' but a local directing you to a house will tell you to
follow 'Route 146' because there isn't much signage with the formal name
(There is some, so 'unsigned_name' isn't appropriate.) From the county line
to the terminus at Route 443, 146 goes back to having no other name.

In these cases, I don't expect a geocoder to associate a building
automatically with a nearby street, and place the full set of address
fields on every building, entrance or other address point. My preference
would be to put 'New York State Route 146' as the 'name' of the route where
it has no other name, or as 'alt_name' if it has another name but the
locals favor the highway name over the formal name. I think that pairing
'ref=NY 146' with 'State Route 146' is too much to ask of a geocoder, while
asking it to match a partial string ('New York 146', 'State Route 146',
'Route 146' or even just '146') is pretty much all in a day's work for
full-text search engines.

Nevertheless, the last time that I raised this issue, there was an
overwhelming consensus that 'Route 146', in the stretches where that is the
only name, is an unnamed way. For that reason, and quite against my better
judgment, I've been sporadically deleting `name="New York State Highway
146"` when it appears and replacing it with `noname=yes`.  I've been doing
this only when I happen to be working on a segment of the way, and only
when I happen to think of it, rather than systematically. This
lackadaisical approach is probably in part because I still don't agree with
the consensus, merely defer to it.


Some side notes to remember:

It's worthy of note that the US has multiple route networks overlaid, with
reuse of numbers. Where this happens, generally speaking, the signs have
distinctive colors and shapes, but it is necessary to keep the authority as
well as the route number. There are crossings (e.g.
https://www.openstreetmap.org/#map=15/43.0047/-76.7002) where that's
significant - note the two routes numbered 90. It's uncommon - for
instance, counties often simply skip over the numbers of state routes that
traverse the county when assigning county route numbers - but it happens.

It also is worth noting that the jurisdiction cannot always be deduced from
boundaries.  https://www.openstreetmap.org/way/666565376 is signed 'NY
120A' even though it is in Connecticut.
https://www.openstreetmap.org/way/46691563 is signed 'Vermont 279' in New
York, although the small reference markers on the shoulder (these are
unreadable at speed, and where mapped in New York are unsigned_ref) show
'915G'.

Finally, 'State Highway', as far as I know, is not an official designation
of any road in New York: the state DOT uses 'State Route' consistently for
its numbered routes. Pedantically, there's also 'State Reference Route' for
various numbered routes that are not prominently signed but are
state-maintained. Most of these are either named (e.g., 'Taconic State
Parkway') or connector routes that often bear signs like 'TO NY 5'
-- 
73 de ke9tv/2, Kevin
__

Re: [Tagging] Rio de la Plata edit war

[Joseph Eisenberg]

We are not talking about a concept like "the coastline", we are talking
about the tag "natural=coastline", which in OpenStreetMap has been defined
(for over 12 years) as "The mean high water (springs) line between the sea
and land (with the water on the right side of the way) ".

"The natural =coastline tag
is used to mark the *mean high water springs
* line"

https://wiki.openstreetmap.org/wiki/Tag:natural=coastline

Mean high water springs is " the highest line the water reaches in normal
circumstances".

The problem is that we did not have a clear definition of where this line
should cross a river or estuary.

However, it is widely agreed that the highest tide line is the feature that
should be mapped on the edge of marine water bodies which have tides,
including bays, fjords, lagoons and so on.

This means that the line tagged with natural=coastline is on the inland
side of all marine water, including mangroves, salt marshes, and tidal
channels, as far as possible. It makes sense that in estuaries, the route
of the ways tagged natural=coastline should also extend up to the limit of
marine influence. In some cases this has been taken to mean the limit of
the tides, in others it is the limit of mixing of salt and fresh water.

We are not mapping the low tide line or political baseline with
natural=coastline: the baseline is often far out to sea. Looking at the
Phillipines and Indonesia, the baseline has very little relation to the
physical geographical tide lines, since it merely connects the outer edges
of islands in the archipelago.

Similarly, in Uruguay and Argentina, the local governments have defined the
baseline as far out to sea as possible, so that they can claim a larger
area of ocean as an exclusive economic zone. This should not influence
tagging in OpenStreetMap, which needs to be based on real, verifiable,
physical characteristics.

– Joseph Eisenberg

On Tue, Aug 4, 2020 at 7:57 AM  wrote:

> - Mensaje original -
> > De: "Christoph Hormann" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Martes, 4 de Agosto 2020 11:17:32
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > On Tuesday 04 August 2020, mural...@montevideo.com.uy wrote:
> >>
> >> I linked several scientific studies that clearly shows and are
> >> verifiable geographic evidence that this is not an oceanic coast, its
> >> a riverbank [...]
> >
> > I am not going to start a discussion here on the semantics of terms
> > like 'ocean', 'riverbank', 'coast' or similar which are inherently
> > culture specific and political.
> >
> > So i repeat my request:
> >
> > could you formulate a generic rule for coastline placement similar to
> > what i formulated in
> >
> >
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement
> >
> > that
> >
> > (a) allows for the coastline placement you favor in case of the Rio de
> > la Plata
> > (b) is based on verifiable physical geography criteria that can
> > practically be checked by mappers and
> > (c) that is compatible to most of the current coastline placements at
> > river mouths around the world?
> >
> > If you can do that we can try to have a productive discussion without
> > delving into the swamp of politics and cultural differences and maybe
> > can find a consensus position that everyone can be satisfied with.
> >
>
> It's all about semantics.
>
> How could I answer your question if you are not able to define what you
> mean by natural=coastline?
> We must first agree on what features we call it coastline, and then I can
> explain where I think it should be drawn.
>
> Regards,
> M.
>
>
>
>
> ---
>
> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin
> costo.
>
> Informate si aplicás aquí.
>
> mvdfactura.uy
>
>
> ---
>
>
>
> ___
> 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] Rio de la Plata edit war

[Christoph Hormann]

On Tuesday 04 August 2020, mural...@montevideo.com.uy wrote:
>
> It's all about semantics.

No, physical geography is not.

> How could I answer your question if you are not able to define what
> you mean by natural=coastline?

I am able to explain how i would define natural=coastline and i have 
already done so.  What i am interested in is how you define 
natural=coastline based on verifiable physical geography criteria.

> We must first agree on what features 
> we call it coastline, and then I can explain where I think it should
> be drawn.

But you already explained where you think the coastline should be 
drawn - what i would like to understand is why, in generic terms and 
based on verifiable physical geography criteria.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Have our tagging voting rules changed recently?

[pangoSE]

I agree.

Colin Smale  skrev: (4 augusti 2020 11:26:30 CEST)
>On 2020-08-04 10:06, Andrew Harvey wrote:
>
>> I'd suggest that if you vote no, it will be helpful for the community
>if you could elaborate on why you're voting no, without enforcing a
>reason as mandatory. Is it because this feature shouldn't be mapped, is
>it because there is an alternative tag. So if the vote fails all this
>feedback can be taken onboard for a revisal of the proposal and second
>round of voting.
>
>The explanation should possibly have been given earlier, during the
>consultancy phase? In a vote, the only thing that should count towards
>the outcome is how you vote, not why you voted that way. All votes have
>equal weight, irrespective of their motivation. 
>
>However, in the ensuing inquest it is obviously useful to understand
>why
>a proposal was not supported by many people.. For that matter, it is
>also useful to know what made people support it as well. 
>
>Putting a proposal to the vote should IMHO not be done unless the
>discussions are clearly pointing towards approval. A vote is not a
>substitute for the discussion, it should be a confirmation that
>consensus has been achieved.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 17:24, Joseph Eisenberg  wrote:
> 
> Looking at the Phillipines and Indonesia, the baseline has very little 
> relation to the physical geographical tide lines, since it merely connects 
> the outer edges of islands in the archipelago.
> 
> Similarly, in Uruguay and Argentina, the local governments have defined the 
> baseline as far out to sea as possible, so that they can claim a larger area 
> of ocean as an exclusive economic zone. This should not influence tagging in 
> OpenStreetMap, which needs to be based on real, verifiable, physical 
> characteristics.


+1, similarly in Italy, the baseline is defined through (relatively few) 
coordinates in a law, which is located always on the most outer points of the 
land or on islands, it has few to do with the coastline. For example the Gulf 
of Taranto is completely included.

https://www.openstreetmap.org/#map=7/39.813/17.595

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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Volker Schmidt]

On Tue, 4 Aug 2020 at 16:27, David Dean  wrote:

The main problem with this is the retrofitting of the missing service=* tags
Unless we start a mega campaign to add service=* to all highway=service, we
will have to live with the actual situation for ever.
Some roads are "service" only and other roads are special "service" roads.
OSM is full of other examples of this tagging scheme. Adding afterwards
more specific tagging does not help at all, it only adds additional work fr
routers and renderers.
If we had started out with a clean scheme, yes, it would have been useful,
but now it is completely useless.

>
> # Parking Access
>
> There are already 2K examples of service=parking in use around the world (
> https://taginfo.openstreetmap.org/tags/service=parking), and while I
> can't claim to have done an exhaustive study, it appears that it is used
> for the purpose of the main driveways through a parking lot.
>

This is peanuts in comparison with the number of "naked" service roads that
connect parking lots.
Just to give you an idea:
Only in the city of Berlin, Germany, there are more than 8k parking lots
(and each should have a service=parking entry road) and there are 25k
"naked" service  roads.

Volker


Virus-free.
www.avast.com

<#m_-5835600118117805121_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[muralito]

Right. With the current wiki meaning, the natural=coastline should be placed in 
the line between Punta del Este and Punta Rasa.
These are verifiable physical facts. The limit has to be put in some place, and 
it is clear to all local mappers that the best option to put the limit is 
there. It is like an average of where the river stops the ocean. 
Here you can see the very different physical characteristics of both coasts, 
wind, currents, salinity, waves, tides, etc, as one is an ocean shore and the 
other a riverbank.

This is not a problem of the data, is about how the render look in low zooms.

The coastline problem is in other rivers, like Elbe River, that it is placed 70 
km inland, but as that does not bother the render seems that nobody cares.

Regards,
M.

- Mensaje original -
> De: "Joseph Eisenberg" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Martes, 4 de Agosto 2020 12:21:48
> Asunto: Re: [Tagging] Rio de la Plata edit war

> We are not talking about a concept like "the coastline", we are talking about
> the tag "natural=coastline", which in OpenStreetMap has been defined (for over
> 12 years) as " The mean high water (springs) line between the sea and land
> (with the water on the right side of the way) ".

> "The natural = coastline tag is used to mark the mean high water springs line"

> https://wiki.openstreetmap.org/wiki/Tag:natural=coastline

> Mean high water springs is " the highest line the water reaches in normal
> circumstances".

> The problem is that we did not have a clear definition of where this line 
> should
> cross a river or estuary.

> However, it is widely agreed 
> thahttps://wiki.openstreetmap.org/wiki/Tag:natural=coastlinet the highest 
> tide line is the feature that
> should be mapped on the edge of marine water bodies which have tides, 
> including
> bays, fjords, lagoons and so on.

> This means that the line tagged with natural=coastline is on the inland side 
> of
> all marine water, including mangroves, salt marshes, and tidal channels, as 
> far
> as possible. It makes sense that in estuaries, the route of the ways tagged
> natural=coastline should also extend up to the limit of marine influence. In
> some cases this has been taken to mean the limit of the tides, in others it is
> the limit of mixing of salt and fresh water.

> We are not mapping the low tide line or political baseline with
> natural=coastline: the baseline is often far out to sea. Looking at the
> Phillipines and Indonesia, the baseline has very little relation to the
> physical geographical tide lines, since it merely connects the outer edges of
> islands in the archipelago.

> Similarly, in Uruguay and Argentina, the local governments have defined the
> baseline as far out to sea as possible, so that they can claim a larger area 
> of
> ocean as an exclusive economic zone. This should not influence tagging in
> OpenStreetMap, which needs to be based on real, verifiable, physical
> characteristics.

> – Joseph Eisenberg

> On Tue, Aug 4, 2020 at 7:57 AM < mural...@montevideo.com.uy > wrote:

>> - Mensaje original -
>> > De: "Christoph Hormann" < o...@imagico.de >
>> > Para: "Tag discussion, strategy and related tools" < 
>> > tagging@openstreetmap.org >
>> > Enviados: Martes, 4 de Agosto 2020 11:17:32
>> > Asunto: Re: [Tagging] Rio de la Plata edit war

>> > On Tuesday 04 August 2020, mural...@montevideo.com.uy wrote:

>> >> I linked several scientific studies that clearly shows and are
>> >> verifiable geographic evidence that this is not an oceanic coast, its
>> >> a riverbank [...]

>> > I am not going to start a discussion here on the semantics of terms
>> > like 'ocean', 'riverbank', 'coast' or similar which are inherently
>> > culture specific and political.

>> > So i repeat my request:

>> > could you formulate a generic rule for coastline placement similar to
>> > what i formulated in

>> > https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

>> > that

>> > (a) allows for the coastline placement you favor in case of the Rio de
>> > la Plata
>> > (b) is based on verifiable physical geography criteria that can
>> > practically be checked by mappers and
>> > (c) that is compatible to most of the current coastline placements at
>> > river mouths around the world?

>> > If you can do that we can try to have a productive discussion without
>> > delving into the swamp of politics and cultural differences and maybe
>> > can find a consensus position that everyone can be satisfied with.


>> It's all about semantics.

>> How could I answer your question if you are not able to define what you mean 
>> by
>> natural=coastline?
>> We must first agree on what features we call it coastline, and then I can
>> explain where I think it should be drawn.

>> Regards,
>> M.

>> ---

>> Con el nuevo 

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 11:24 AM Joseph Eisenberg 
wrote:

> This means that the line tagged with natural=coastline is on the inland
> side of all marine water, including mangroves, salt marshes, and tidal
> channels, as far as possible. It makes sense that in estuaries, the route
> of the ways tagged natural=coastline should also extend up to the limit of
> marine influence. In some cases this has been taken to mean the limit of
> the tides, in others it is the limit of mixing of salt and fresh water.
>

I agree that's what the Wiki says. The Wiki says a lot of things.

In actual practice, in the estuaries of rivers, the 'coastline' is very
seldom tagged that far upstream.

I return to the example of the Hudson River. The tidal influence extends
upstream to Lock and Dam Number One - 248 km from the river mouth. The salt
front varies strongly with the season. There can be fresh water in New York
Harbor during the spring snowmelt, or salt water at Poughkeepsie (122 km
upriver) in a dry summer. (It's also defined somewhat arbitrarily as a
conductivity of 510 microsiemens/metre at the surface - but surface
salinity is, in most seasons, higher than the salinity at depth because the
cold, fresh river water underlies the relatively warm, brackish surface
water.) Needless to say, the biome is very different between Albany (always
fresh water) and Yonkers (always salt, except for snowmelt events).
Oceangoing vessels of up to 9 m draft can ply the river as far as Albany.
(In less xenophobic times, vessels of friendly nations could clear customs
at Albany.)

For pretty much all the rivers in eastern North America, the tidal
influence extends to the first dam or waterfall. This usually coincides
with what would be the head of navigation if it were not for modern
improvements such as locks. Riverports from Augusta, Maine to Macon,
Georgia would become 'coastal' cities. That's surely no more the local
understanding on the Kennebec or the Ocmulgee than it is on the Elbe!

For the Amazon, the situation is even more extreme - the river is tidal for
a thousand kilometres from what would be conventionally recognized as the
'coast'.

It appears that for most of the world, this rule, if actually implemented -
and it is important to stress that it is NOT the way things are mapped at
present - would extend the 'coastline' for tens or hundreds of km upstream
on most of the first-order rivers of the world.

Given the fact that even with today's definition, we frequently go for
months without a consistent coastline to give to the renderer, do we want
to add tens of thousands more kilometres of 'natural=coastline'? We'd never
see a coastline update again! (For this reason, I'm inclined to push the
'coastline' as far toward the sea as sensibly possible, to have as little
'coastline' as possible to get broken, rather than going for months without
updates or worse, seeing rendering accidents flood whole continents.)

Moreover, I'm somewhat puzzled at Christoph's insistence that
'natural=coastline' have a strict physical definition, and dismiss local
understanding as merely political and cultural. In almost all other aspects
of OSM, the understanding of the locals is what governs. That understanding
is, ipso facto, cultural - but we dismiss it at our peril. Ignoring local
understanding is a path to irrelevance. (In another OSM domain, I've seen
this sort of nonsense before; I've actually seen someone seriously suggest
that a peak should not have its name in OSM unless someone can find a sign
with the name on it, because asking locals and consulting reference works
is not 'verifiability in the field.')

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Colin Smale]

On 2020-08-04 17:40, Martin Koppenhoefer wrote:

> +1, similarly in Italy, the baseline is defined through (relatively few) 
> coordinates in a law, which is located always on the most outer points of the 
> land or on islands, it has few to do with the coastline. For example the Gulf 
> of Taranto is completely included.

The status of the Gulf of Taranto is disputable as it appears to have no
basis in international law.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

On Tuesday 04 August 2020, Kevin Kenny wrote:
>
> Moreover, I'm somewhat puzzled at Christoph's insistence that
> 'natural=coastline' have a strict physical definition, and dismiss
> local understanding as merely political and cultural. In almost all
> other aspects of OSM, the understanding of the locals is what
> governs. That understanding is, ipso facto, cultural - but we dismiss
> it at our peril. Ignoring local understanding is a path to
> irrelevance.

I am not saying that OSM should only record physical geography.  I am 
saying that natural=coastline is a physical geography tag and should be 
defined based on physical geography criteria.  If there is no consensus 
about this we can end the discussion because if we cannot even agree on 
basic conceptual separation on that level (i.e. that we separate the 
mapping of the physical extent of surface water cover on this planet 
from culturally defined elements of the geography) we can close up shop 
right away.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] RFC: service=? for all highway=service (service=parking needed, primarily, I think)

[Tobias Zwick]

Two more types came to my mind:

1. Courtyard area (Дворовая территория)


Another type of service road that is currently probably not tagged with
any subtag came to my mind right now: Something like a multi-use
courtyard area bounded by buildings around the perimeter with
playgrounds, recreation and green spaces, driveways etc. It may
additionally be tagged with living_street=yes.

I recently read up on the default speed limits (if no sign is posted) of
the Russian road regulations. It mentioned "20 km/h in courtyard areas"
(Дворовая территория). I asked about what can be understood by that in
the Russian forum:
https://forum.openstreetmap.org/viewtopic.php?id=70178

I have no clear picture of it, maybe someone from Russia can post an
example Google StreetView picture or something.
But if the description given in the Russian forum fits, then these
service roads would be neither alley, nor driveway, nor parking.

2. Medieval alleys (Gasse) / South-East-Asian very-small residentials


Usually and/or in English, service=alley is defined as a road that
provides access to the rear or back of a building or home, alternatively
as a narrow road between properties.

However, (at least) in the German Wiki, it is also documented as a "very
small medieval (residential) road, often broad enough for a car but no
space for sidewalks or parking", see the pictures in
https://wiki.openstreetmap.org/wiki/DE:Tag:service%3Dalley

Whether the wiki entry there is in the wrong or not is quite irrelevant
at this point because it has been documented like that a long time, so
many such roads will be tagged like that and we are dealing with a
status quo.

When looking at the map internationally, one can see that oftentimes for
very small residential roads, the highway=service tag is used (sometimes
with service=alley, sometimes not), sometimes highway=living_street
(even though it is documented that living street should only be used if
it is explicitly signed) and sometimes highway=residential.

Example of such a very small residential in Thailand:
https://goo.gl/maps/aSNb38BNiqDJ3t8Q7 where one can't be sure whether it
is tagged as highway=service, highway=living_street or highway=residential.

Which tag is used and which tag should be used is somewhat subject to
continued disagreement amongst mappers, I consider it an open problem.

So if we are about to define the subtags for highway=service through and
through, then we come to the point where we'd need to decide if this is
a legitimate usage of the highway=service tag and if not, what should be
used instead.

Tobias

On 02/08/2020 02:40, David Dean wrote:
> Hi everyone,
> 
> I'm interested in proposing and/or documenting existing tagging
> approaches of the wiki to ensure that all highway=service ways can have
> a service=? associated tag. Having done, so I'm planning on
> resurrecting https://github.com/westnordost/StreetComplete/issues/808 to
> help people get all service roads appropriately tagged in their area.
> 
> At the moment, service=? can be (according to the wiki
> at https://wiki.openstreetmap.org/wiki/Key:service):
> 
> * service=parking_aisle
> * service=driveway
> * service=alley
> * service=emergency_access
> * service=drive-through
> 
> But service roads are also used for the 'main ways on a parking lot',
> and there is also an indication of access to multiple businesses (like
> in an industrial estate etc), and it looks like the documented way is to
> not to provide a service=? tag in this case.
> 
> This seems problematic to me from a map maintenance purpose, as how do
> we know if a highway=service just hasn't had a service=? tag applied
> yet, or if it is one of the exceptions that does not get a service=? tag
> (and which one is it?)
> 
> I would like to try to understand the highway=service usages that don't
> have a current documented service=? tag and either propose an
> appropriate tag or find examples of existing tagging to document.
> 
> At this stage I think appropriate tagging for some of the missing
> service=? tagging indicated in the documentation would be:
> 
> service=parking -> main way in a parking lot, for connecting
> service=parking_isles (used almost 2K times
> already: https://taginfo.openstreetmap.org/keys/service#values)
> 
> service=driveway -> also used for access to multiple businesses
> (like in an industrial estate, etc)
> 
> service=driveway/drive-through -> Service way for access to a fuel
> station
> 
> 
> Are there any other main understood uses of no service=? tag that would
> need an appropriate service=? tag to fill this gap?
> 
> Once I've got some good starting feedback from this forum, I plan on
> revising 
> https://wiki.openstreetmap.org/wiki/Proposed_features/service%3Dparking to
> include any new appropriate service=? (not just service=parking) tagging
> and start the formal RFC process.
> 
> Thanks for your fe

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 12:59 PM Christoph Hormann  wrote:

> I am not saying that OSM should only record physical geography.  I am
> saying that natural=coastline is a physical geography tag and should be
> defined based on physical geography criteria.  If there is no consensus
> about this we can end the discussion because if we cannot even agree on
> basic conceptual separation on that level (i.e. that we separate the
> mapping of the physical extent of surface water cover on this planet
> from culturally defined elements of the geography) we can close up shop
> right away.
>

Your straw man looks to be quite flammable.

A water polygon remains a water polygon whether its boundary is
`natural=coastilne`, `waterway=river`, `natural=water` or whatever. Nobody
is arguing over the physical extent of surface water coverage.

The precise line at which a river becomes a lake or the ocean is and will
always be indefinite. We are arguing about how broadly or narrowly to draw
it. Your argument is that the first dam or waterfall is the only
'objective' way to place it. That may be true: it's the first bright line.
Nevertheless, in practice, it gives a much broader definition of the World
Ocean than seems reasonable - placing the line hundreds of km from the
commonly understood river mouth in many cases.

I'm arguing that both cultural considerations (generally speaking, people
do not call tidal inland riverbanks 'the coastline') and practical
considerations (a much longer coastline further complicates the already
horrible situation for coastline rendering) both militate in favor of
putting the coastline as far downstream in the estuarine environment as is
practicable. Nothing in my argument changes the physical extent of the
mapped water surface by one centimetre. It's simply saying that for any
indefinite boundary, there is no single right answer. Deference to the
local cultural definitions, provided that they don't warp the indefinite
boundary beyond any reasonable physical interpretation, is most likely
warranted.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Joseph Eisenberg]

It's perfectly possible to make a physical definition of an estuary which
allows the line of the natural=coastline to be placed across the lower
Hudson, rather than at Troy or Albany, if we look at salinity and currents
rather than just tides: and we must, because some parts of the coast in the
tropics have nearly 0 tidal variation (including the region around the Rio
de la Plata).

But the current position of the natural=coastline ways between Argentina
and Uruguay is like if all of Lower New York Bay were outside of the
natural=coastline, and a line was instead drawn from Long Beach NY to Long
Branch NJ.

This is quite serious when it comes to the Saint Lawrence river (Fleuve
Saint-Laurent), which can extend as far west into the Golf of Saint
Lawrence as you want, if we take the current placement of the
natural=coastline along the eastern edge of the Rio de la Plata as a guide.
I would suggest that the natural=coastline should cross no farther
downstream than Quebec City, where the river widens into the huge lower
estuary.

Similarly, should Puget Sound and San Francisco Bay be mapped as
natural=water + water=river? These are also estuaries.

-- Joseph Eisenberg

On Tue, Aug 4, 2020 at 9:30 AM Kevin Kenny  wrote:

> On Tue, Aug 4, 2020 at 11:24 AM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> This means that the line tagged with natural=coastline is on the inland
>> side of all marine water, including mangroves, salt marshes, and tidal
>> channels, as far as possible. It makes sense that in estuaries, the route
>> of the ways tagged natural=coastline should also extend up to the limit of
>> marine influence. In some cases this has been taken to mean the limit of
>> the tides, in others it is the limit of mixing of salt and fresh water.
>>
>
> I agree that's what the Wiki says. The Wiki says a lot of things.
>
> In actual practice, in the estuaries of rivers, the 'coastline' is very
> seldom tagged that far upstream.
>
> I return to the example of the Hudson River. The tidal influence extends
> upstream to Lock and Dam Number One - 248 km from the river mouth. The salt
> front varies strongly with the season. There can be fresh water in New York
> Harbor during the spring snowmelt, or salt water at Poughkeepsie (122 km
> upriver) in a dry summer. (It's also defined somewhat arbitrarily as a
> conductivity of 510 microsiemens/metre at the surface - but surface
> salinity is, in most seasons, higher than the salinity at depth because the
> cold, fresh river water underlies the relatively warm, brackish surface
> water.) Needless to say, the biome is very different between Albany (always
> fresh water) and Yonkers (always salt, except for snowmelt events).
> Oceangoing vessels of up to 9 m draft can ply the river as far as Albany.
> (In less xenophobic times, vessels of friendly nations could clear customs
> at Albany.)
>
> For pretty much all the rivers in eastern North America, the tidal
> influence extends to the first dam or waterfall. This usually coincides
> with what would be the head of navigation if it were not for modern
> improvements such as locks. Riverports from Augusta, Maine to Macon,
> Georgia would become 'coastal' cities. That's surely no more the local
> understanding on the Kennebec or the Ocmulgee than it is on the Elbe!
>
> For the Amazon, the situation is even more extreme - the river is tidal
> for a thousand kilometres from what would be conventionally recognized as
> the 'coast'.
>
> It appears that for most of the world, this rule, if actually implemented
> - and it is important to stress that it is NOT the way things are mapped at
> present - would extend the 'coastline' for tens or hundreds of km upstream
> on most of the first-order rivers of the world.
>
> Given the fact that even with today's definition, we frequently go for
> months without a consistent coastline to give to the renderer, do we want
> to add tens of thousands more kilometres of 'natural=coastline'? We'd never
> see a coastline update again! (For this reason, I'm inclined to push the
> 'coastline' as far toward the sea as sensibly possible, to have as little
> 'coastline' as possible to get broken, rather than going for months without
> updates or worse, seeing rendering accidents flood whole continents.)
>
> Moreover, I'm somewhat puzzled at Christoph's insistence that
> 'natural=coastline' have a strict physical definition, and dismiss local
> understanding as merely political and cultural. In almost all other aspects
> of OSM, the understanding of the locals is what governs. That understanding
> is, ipso facto, cultural - but we dismiss it at our peril. Ignoring local
> understanding is a path to irrelevance. (In another OSM domain, I've seen
> this sort of nonsense before; I've actually seen someone seriously suggest
> that a peak should not have its name in OSM unless someone can find a sign
> with the name on it, because asking locals and consulting reference works
> is not 'verifiability 

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

On Tuesday 04 August 2020, Kevin Kenny wrote:
>
> A water polygon remains a water polygon whether its boundary is
> `natural=coastilne`, `waterway=river`, `natural=water` or whatever.
> Nobody is arguing over the physical extent of surface water coverage.

I am sorry that i cannot make you see my point.  That however does not 
affect its validity.  Just for clarity i will repeat the core argument:

Basic conceptual separation between different fields of mapping is 
absolutely essential for OpenStreetMap to function.  We therefore 
cannot seriously consider mixing the mapping of physical extent of 
surface water cover on this planet (predominantly done with ways tagged 
natural=coastline) with culturally defined elements of the geography 
(that is using the same tag on ways to represent something not defined 
by physical geography criteria).

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Rio de la Plata edit war

[Frederik Ramm]

Hi,

On 8/4/20 18:28, Kevin Kenny wrote:
> In actual practice, in the estuaries of rivers, the 'coastline' is very
> seldom tagged that far upstream.

From my Chesapeake Bay example, in OSM, Havre de Grace (290km inland) is
a "coastal"city

https://www.openstreetmap.org/?mlat=39.5443&mlon=-76.0961#map=10/39.5443/-76.0961

though Baltimore (260km inland) is not, due to Patapsco River having its
own polygon:

https://www.openstreetmap.org/?mlat=39.2461&mlon=-76.6523#map=10/39.2461/-76.6523

Of course my "xxx km inland" depends on where you define the bay to
begin, I used the US13 crossing at Norfolk.

Not saying that is the measuring stick, and perhaps as a result of this
discussion it needs to be tagged differently, or maybe the physical
geography is different there.

Or maybe we conclude that physical geography doesn't count and what
counts is whether it "feels like" a coastal city ;)

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] Rio de la Plata edit war

[Joseph Eisenberg]

Re: " Your argument is that the first dam or waterfall is the only
'objective' way to place it. "

That's not what Christoph has proposed. You can read his suggestions at
https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

It provides a great deal of lee-way for mappers to decide on the exact
placement. For the case of the Hudson it could be anywhere from New York
Harbor up to Albany:

"The upper limit

In case of significant tidal influence at the river mouth the coastline
should be closed no further upstream than the range of the tidal influence.

In case of no or insignificant tidal variation the coastline should not
extend significantly above the sea level with the river (*significantly* not
being precisely defined but i'd say at maximum a meter).
"The lower limit

With no or insignificant tides the coastline should go upstream at least to
a point where the river current is clearly the dominating current in the
water under normal weather conditions (i.e. no storm).

With significant tides the coastline should go upstream at least to a point
where on waterflow is going downstream for a significantly longer part of
the tidal cycle than it goes upstream due to rising tide."


These rules would exclude the lower Rio De La Plata and the lower part of
the mouth of the Saint Lawrence river, as well as other wide estuaries
where winds and tides have more influence on surface water flow than does
the discharge of the river. It would not prevent mapping the Hudson mouth
at the southern tip of Manhattan, because the flow is strong all the way to
New York Harbor, if I understand correctly.


- Joseph Eisenberg

On Tue, Aug 4, 2020 at 11:54 AM Kevin Kenny  wrote:

> On Tue, Aug 4, 2020 at 12:59 PM Christoph Hormann  wrote:
>
>> I am not saying that OSM should only record physical geography.  I am
>> saying that natural=coastline is a physical geography tag and should be
>> defined based on physical geography criteria.  If there is no consensus
>> about this we can end the discussion because if we cannot even agree on
>> basic conceptual separation on that level (i.e. that we separate the
>> mapping of the physical extent of surface water cover on this planet
>> from culturally defined elements of the geography) we can close up shop
>> right away.
>>
>
> Your straw man looks to be quite flammable.
>
> A water polygon remains a water polygon whether its boundary is
> `natural=coastilne`, `waterway=river`, `natural=water` or whatever. Nobody
> is arguing over the physical extent of surface water coverage.
>
> The precise line at which a river becomes a lake or the ocean is and will
> always be indefinite. We are arguing about how broadly or narrowly to draw
> it. Your argument is that the first dam or waterfall is the only
> 'objective' way to place it. That may be true: it's the first bright line.
> Nevertheless, in practice, it gives a much broader definition of the World
> Ocean than seems reasonable - placing the line hundreds of km from the
> commonly understood river mouth in many cases.
>
> I'm arguing that both cultural considerations (generally speaking, people
> do not call tidal inland riverbanks 'the coastline') and practical
> considerations (a much longer coastline further complicates the already
> horrible situation for coastline rendering) both militate in favor of
> putting the coastline as far downstream in the estuarine environment as is
> practicable. Nothing in my argument changes the physical extent of the
> mapped water surface by one centimetre. It's simply saying that for any
> indefinite boundary, there is no single right answer. Deference to the
> local cultural definitions, provided that they don't warp the indefinite
> boundary beyond any reasonable physical interpretation, is most likely
> warranted.
>
> --
> 73 de ke9tv/2, Kevin
> ___
> 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] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 2:54 PM Joseph Eisenberg 
wrote:

> It's perfectly possible to make a physical definition of an estuary which
> allows the line of the natural=coastline to be placed across the lower
> Hudson, rather than at Troy or Albany, if we look at salinity and currents
> rather than just tides: and we must, because some parts of the coast in the
> tropics have nearly 0 tidal variation (including the region around the Rio
> de la Plata).
>
> But the current position of the natural=coastline ways between Argentina
> and Uruguay is like if all of Lower New York Bay were outside of the
> natural=coastline, and a line was instead drawn from Long Beach NY to Long
> Branch NJ.
>
> This is quite serious when it comes to the Saint Lawrence river (Fleuve
> Saint-Laurent), which can extend as far west into the Golf of Saint
> Lawrence as you want, if we take the current placement of the
> natural=coastline along the eastern edge of the Rio de la Plata as a guide.
> I would suggest that the natural=coastline should cross no farther
> downstream than Quebec City, where the river widens into the huge lower
> estuary.
>
> Similarly, should Puget Sound and San Francisco Bay be mapped as
> natural=water + water=river? These are also estuaries.
>

Deferring to local cultural understanding is actually a good start for the
other examples.

For the Hudson, if you wanted to draw the line from Rockaway Point to Sandy
Hook (the two lighthouses commonly understood to mark the entrance of New
York Harbor), from the Battery to Liberty Pier (mile 0 of the Hudson as it
appears on the nautical charts) or from Spuyten Duyvil to Englewood Cliffs
(just upstream from the first distributary, the Harlem River), I'd have no
heartburn.

 The lowest point on the river that would be at all defensible by any
argument other than culture (and 'eyeball' geometry - on the map it *looks*
like a river) would probably be between Peekskill and Stony Point. That's
where you'd start to see mean annual salinity start to fall off sharply.
(The seasonal variation is substantial.) That's already getting culturally
and "eyeball geometry" start of dodgy.  Beyond that, I'd have to consult
historical records for the historical maximum retreat of the salt front,
but we're already quite some way upriver.

Similarly, there's a local understanding of "Fleuve Saint-Laurent" vs
"Golfe du Saint-Laurent" - and here I see that the locals have compromised
by creating objects for 'Estuaire fluvial', 'Estuaire moyen' and 'Estuaire
maritime'. Even there, the 'Estuaire fluvial' does not extend nearly to the
tidal limit.

The locals certainly make a distinction between the waters of the
Sacramento and American rivers and those of San Pablo and San Franscisco
Bays, or those of Puget Sound and the many rivers that empty into it. They
also make a distinction between the bays, or the sound, and the ocean.

-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 3:18 PM Joseph Eisenberg 
wrote:

>
> These rules would exclude the lower Rio De La Plata and the lower part of
> the mouth of the Saint Lawrence river, as well as other wide estuaries
> where winds and tides have more influence on surface water flow than does
> the discharge of the river. It would not prevent mapping the Hudson mouth
> at the southern tip of Manhattan, because the flow is strong all the way to
> New York Harbor, if I understand correctly.
>

The Hudson definitely reverses flow. One of its names among the First
Peoples translates to 'the river flows both ways.'  The division in the
flow lies less in the fraction of the tidal cycle than the speed of the
current. It flows 'upstream' for half the time, 'downstream' for half, but
the downstream current is considerably swifter.


-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Joseph Eisenberg]

"The locals certainly make a distinction between the waters of the
Sacramento and American rivers and those of San Pablo and San Franscisco
Bays, or those of Puget Sound and the many rivers that empty into it. They
also make a distinction between the bays, or the sound, and the ocean. "

And so do the locals in Uruguay and Argentina: the Rio de la Plata is the
name of the marine estuary, while the rivers which empty into it have their
own names: Rio Uruguay and Rio Paraná, which are each about 1.5 km (a
little under a mile) wide, open up to the Rio de la Plata which starts out
at ~30 to 50 km (20 to 30 miles) wide till after Buenos Aires, then becomes
almost 100 km wide by the time it opens up at Montevideo and Samborombon
Bay. The people who named the rivers and the estuary recognized a
difference.

- Joseph Eisenberg

On Tue, Aug 4, 2020 at 12:23 PM Kevin Kenny  wrote:

> On Tue, Aug 4, 2020 at 2:54 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
>
>> It's perfectly possible to make a physical definition of an estuary which
>> allows the line of the natural=coastline to be placed across the lower
>> Hudson, rather than at Troy or Albany, if we look at salinity and currents
>> rather than just tides: and we must, because some parts of the coast in the
>> tropics have nearly 0 tidal variation (including the region around the Rio
>> de la Plata).
>>
>> But the current position of the natural=coastline ways between Argentina
>> and Uruguay is like if all of Lower New York Bay were outside of the
>> natural=coastline, and a line was instead drawn from Long Beach NY to Long
>> Branch NJ.
>>
>> This is quite serious when it comes to the Saint Lawrence river (Fleuve
>> Saint-Laurent), which can extend as far west into the Golf of Saint
>> Lawrence as you want, if we take the current placement of the
>> natural=coastline along the eastern edge of the Rio de la Plata as a guide.
>> I would suggest that the natural=coastline should cross no farther
>> downstream than Quebec City, where the river widens into the huge lower
>> estuary.
>>
>> Similarly, should Puget Sound and San Francisco Bay be mapped as
>> natural=water + water=river? These are also estuaries.
>>
>
> Deferring to local cultural understanding is actually a good start for the
> other examples.
>
> For the Hudson, if you wanted to draw the line from Rockaway Point to
> Sandy Hook (the two lighthouses commonly understood to mark the entrance of
> New York Harbor), from the Battery to Liberty Pier (mile 0 of the Hudson as
> it appears on the nautical charts) or from Spuyten Duyvil to Englewood
> Cliffs (just upstream from the first distributary, the Harlem River), I'd
> have no heartburn.
>
>  The lowest point on the river that would be at all defensible by any
> argument other than culture (and 'eyeball' geometry - on the map it *looks*
> like a river) would probably be between Peekskill and Stony Point. That's
> where you'd start to see mean annual salinity start to fall off sharply.
> (The seasonal variation is substantial.) That's already getting culturally
> and "eyeball geometry" start of dodgy.  Beyond that, I'd have to consult
> historical records for the historical maximum retreat of the salt front,
> but we're already quite some way upriver.
>
> Similarly, there's a local understanding of "Fleuve Saint-Laurent" vs
> "Golfe du Saint-Laurent" - and here I see that the locals have compromised
> by creating objects for 'Estuaire fluvial', 'Estuaire moyen' and 'Estuaire
> maritime'. Even there, the 'Estuaire fluvial' does not extend nearly to the
> tidal limit.
>
> The locals certainly make a distinction between the waters of the
> Sacramento and American rivers and those of San Pablo and San Franscisco
> Bays, or those of Puget Sound and the many rivers that empty into it. They
> also make a distinction between the bays, or the sound, and the ocean.
>
> --
> 73 de ke9tv/2, Kevin
> ___
> 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] Rio de la Plata edit war

[Joseph Eisenberg]

On Tue, Aug 4, 2020 at 12:31 PM Kevin Kenny  wrote:

> The Hudson definitely reverses flow. One of its names among the First
> Peoples translates to 'the river flows both ways.'  The division in the
> flow lies less in the fraction of the tidal cycle than the speed of the
> current. It flows 'upstream' for half the time, 'downstream' for half, but
> the downstream current is considerably swifter.
>

As long as the current is significantly faster in the downstream direction,
this qualifies by the standard that "the river current is clearly the
dominating current in the water" - that is, oceanic currents and
wind-driven currents are not the definition characteristic

In contrast, the East River, which is a tidal strait, would need to be
mapped on the marine side of the coastline, since the current flows through
the East River are not related to a fresh-water river current at all.
https://en.wikipedia.org/wiki/East_River

By using the dominant currents as a definition, this allows local mappers
with knowledge of the water to determine the right tagging.

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

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Kevin Kenny" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Martes, 4 de Agosto 2020 16:28:55
> Asunto: Re: [Tagging] Rio de la Plata edit war

> On Tue, Aug 4, 2020 at 3:18 PM Joseph Eisenberg < joseph.eisenb...@gmail.com >
> wrote:

>> These rules would exclude the lower Rio De La Plata and the lower part of the
>> mouth of the Saint Lawrence river, as well as other wide estuaries where 
>> winds
>> and tides have more influence on surface water flow than does the discharge 
>> of
>> the river. It would not prevent mapping the Hudson mouth at the southern tip 
>> of
>> Manhattan, because the flow is strong all the way to New York Harbor, if I
>> understand correctly.

> The Hudson definitely reverses flow. One of its names among the First Peoples
> translates to 'the river flows both ways.' The division in the flow lies less
> in the fraction of the tidal cycle than the speed of the current. It flows
> 'upstream' for half the time, 'downstream' for half, but the downstream 
> current
> is considerably swifter.

Rio de la Plata would not be excluded, as you can read in the document [8] i 
linked in my first mail, for example, see some graphics of the flow of the 
river in page 25.
[8] DINAMA. Salinidad 
https://www.dinama.gub.uy/oan/documentos/uploads/2016/12/patrones_circulacion.pdf

Regaards,
M.



---

Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin costo.

Informate si aplicás aquí.

mvdfactura.uy

---



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

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

On Tuesday 04 August 2020, Kevin Kenny wrote:
>
> The Hudson definitely reverses flow. One of its names among the First
> Peoples translates to 'the river flows both ways.'  The division in
> the flow lies less in the fraction of the tidal cycle than the speed
> of the current. It flows 'upstream' for half the time, 'downstream'
> for half, but the downstream current is considerably swifter.

Note the proposal is a draft and does not necessarily represent the 
ultimate wisdom on everything written there.  I am not an expert on 
tidal dynamics of rivers so it is well possible that some adjustments 
in the details are advisable.  Defining the lower limit in the tidal 
case through water flow volume rather than duration seems prudent (and 
also better matching the logic for the non-tidal case) - i chose 
duration mostly because it is practically easier for the mapper to 
observe.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Rio de la Plata edit war

[Joseph Eisenberg]

The graphics in this document are mainly models of current flow, rather
than actual measurements, but it is mentioned that the average current
flow, neglecting wind, is only 0.1 m/s in the Rio de la Plata. Since winds
of 5 m/s are routine according to the paper, the currents vary strongly
based on winds and tides.

See for example the figura on pages 26 to 37 which show the modeled
variation with different wind direction. I don't see a modeling of the
affect of tides - this appears to be the average current over the tidal
cycle? But I admit I have not visited this area.

My main objection is the inclusion of Bahia Samborombon in the estuary. The
charts and satellite images show very little influence from river water in
that area, as well as in the section of coast east of Montevideo.

– Joseph Eisenberg

On Tue, Aug 4, 2020 at 12:42 PM  wrote:

>
>
> - Mensaje original -
> > De: "Kevin Kenny" 
> > Para: "Tag discussion, strategy and related tools" <
> tagging@openstreetmap.org>
> > Enviados: Martes, 4 de Agosto 2020 16:28:55
> > Asunto: Re: [Tagging] Rio de la Plata edit war
>
> > On Tue, Aug 4, 2020 at 3:18 PM Joseph Eisenberg <
> joseph.eisenb...@gmail.com >
> > wrote:
>
> >> These rules would exclude the lower Rio De La Plata and the lower part
> of the
> >> mouth of the Saint Lawrence river, as well as other wide estuaries
> where winds
> >> and tides have more influence on surface water flow than does the
> discharge of
> >> the river. It would not prevent mapping the Hudson mouth at the
> southern tip of
> >> Manhattan, because the flow is strong all the way to New York Harbor,
> if I
> >> understand correctly.
>
> > The Hudson definitely reverses flow. One of its names among the First
> Peoples
> > translates to 'the river flows both ways.' The division in the flow lies
> less
> > in the fraction of the tidal cycle than the speed of the current. It
> flows
> > 'upstream' for half the time, 'downstream' for half, but the downstream
> current
> > is considerably swifter.
>
> Rio de la Plata would not be excluded, as you can read in the document [8]
> i linked in my first mail, for example, see some graphics of the flow of
> the river in page 25.
> [8] DINAMA. Salinidad
> https://www.dinama.gub.uy/oan/documentos/uploads/2016/12/patrones_circulacion.pdf
>
> Regaards,
> M.
>
>
>
>
> ---
>
> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin
> costo.
>
> Informate si aplicás aquí.
>
> mvdfactura.uy
>
>
> ---
>
>
>
> ___
> 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] Rio de la Plata edit war

[Kevin Kenny]

On Tue, Aug 4, 2020 at 3:16 PM Frederik Ramm  wrote:

> Hi,
>
> On 8/4/20 18:28, Kevin Kenny wrote:
> > In actual practice, in the estuaries of rivers, the 'coastline' is very
> > seldom tagged that far upstream.
>
> From my Chesapeake Bay example, in OSM, Havre de Grace (290km inland) is
> a "coastal"city
>
>
> https://www.openstreetmap.org/?mlat=39.5443&mlon=-76.0961#map=10/39.5443/-76.0961
>
> though Baltimore (260km inland) is not, due to Patapsco River having its
> own polygon:
>
>
> https://www.openstreetmap.org/?mlat=39.2461&mlon=-76.6523#map=10/39.2461/-76.6523
>
> Of course my "xxx km inland" depends on where you define the bay to
> begin, I used the US13 crossing at Norfolk.
>
> Not saying that is the measuring stick, and perhaps as a result of this
> discussion it needs to be tagged differently, or maybe the physical
> geography is different there.
>
>
Chesapeake Bay is commonly understood (not among biologists or
oceanographers, but in everyday speech) to be a marine environment. Even
its name suggests that.  Moreover, the Susquehanna is where the fall line
comes closest to the coast;  and so has the least problem of all the
Eastern US rivers. Nobody sane would place the 'coastline' above the
Conowingo dam, only a few km from Havre de Grace.Were it not for the dam
and lock, Conowingo would be the limit of navigability of the Susquehanna,
and the Potomac would not be navigable beyond Washington without the C&O
Canal infrastructure.

In any case, the number of words we've all exchanged on this topic itself
indicates that what we're trying to do is to fix indefinite boundaries.
Whether a particular land-water border is 'coastline' or not, for most
purposes, is a distinction without a difference. You have land on one side,
and water (of whatever salinity and tidal variation) on the other.  The
water likely belongs to one or more water bodies that have names; the
boundaries among named water bodies are almost always both indefinite and
culturally determined. Rivers are (usually) fresh and (usually) flow in one
direction. The ocean is salt and is (usually) tidal. We use 'estuary' to
describe the whole indefinite continuum between. For the Hudson, a
hydrologist would correctly say that the whole thing from the dam in Troy
to the ocean is estuarine. There are no bright lines separating the pieces.

Since there are no bright lines, there is a weaker technical argument in
favor of making the 'coastline' as small as possible - minimizing the
extent over which trivial mapping mistakes cause continent-wide rendering
gaffes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Paul Allen]

On Tue, 4 Aug 2020 at 19:54, Joseph Eisenberg 
wrote:

Similarly, should Puget Sound and San Francisco Bay be mapped as
> natural=water + water=river? These are also estuaries.
>

I suspect the answer is contained within the question.  We have the words
"ocean" and "estuary" because we consider them to be different things.  We
might bicker a little about where the dividing line is but understand them
as
being different concepts.  Where does the coastline end?  At the start of
the estuary.

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

Re: [Tagging] Rio de la Plata edit war

[Martin Koppenhoefer]

sent from a phone

> On 4. Aug 2020, at 18:30, Colin Smale  wrote:
> 
> The status of the Gulf of Taranto is disputable as it appears to have no 
> basis in international law.


it is indeed disputed by the UK, the US and maybe others, but according to the 
Italian baseline it is completely in Italy, that was my point. AFAIK in the 
border dataset that the EU distributes it is also completely in Italy, even 
when the UK was still in the EU.

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

Re: [Tagging] Rio de la Plata edit war

[Colin Smale]

On 2020-08-04 22:46, Paul Allen wrote:

> On Tue, 4 Aug 2020 at 19:54, Joseph Eisenberg  
> wrote: 
> 
>> Similarly, should Puget Sound and San Francisco Bay be mapped as 
>> natural=water + water=river? These are also estuaries.
> 
> I suspect the answer is contained within the question.  We have the words 
> "ocean" and "estuary" because we consider them to be different things.  We 
> might bicker a little about where the dividing line is but understand them as 
> being different concepts.  Where does the coastline end?  At the start of 
> the estuary.

In my perception they can overlap.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[muralito]

- Mensaje original -
> De: "Joseph Eisenberg" 
> Para: "Tag discussion, strategy and related tools" 
> Enviados: Martes, 4 de Agosto 2020 16:56:31
> Asunto: Re: [Tagging] Rio de la Plata edit war

> The graphics in this document are mainly models of current flow, rather than
> actual measurements, but it is mentioned that the average current flow,
> neglecting wind, is only 0.1 m/s in the Rio de la Plata. Since winds of 5 m/s
> are routine according to the paper, the currents vary strongly based on winds
> and tides.
> See for example the figura on pages 26 to 37 which show the modeled variation
> with different wind direction. I don't see a modeling of the affect of tides -
> this appears to be the average current over the tidal cycle? But I admit I 
> have
> not visited this area.

Sure its a model, but the model is validated by drifting bouys, as you can 
check in page 37.
i just translated here.
"The drift buoy trajectories launched in the summer of 2003 and reported by 
Piola et al (2003) showed, in consistency with the modeled solutions, 
relatively low average speeds (20-30 cm / s) in the middle part of the river 
and higher speeds in the outer sector, mainly towards the Uruguayan coast, 
where they exceeded 60 cm / s (Fig. 33)."

> My main objection is the inclusion of Bahia Samborombon in the estuary. The
> charts and satellite images show very little influence from river water in 
> that
> area, as well as in the section of coast east of Montevideo.

You are misreading the imagery. What generaly available imagery shows in this 
area is a change of colour, which is dark brown to the NW, and more clear to 
the SE. This is caused for the change of turbidity, located near the 5m isobath.

> – Joseph Eisenberg

> On Tue, Aug 4, 2020 at 12:42 PM < mural...@montevideo.com.uy > wrote:

>> - Mensaje original -
>> > De: "Kevin Kenny" < kevin.b.ke...@gmail.com >
>> > Para: "Tag discussion, strategy and related tools" < 
>> > tagging@openstreetmap.org >
>> > Enviados: Martes, 4 de Agosto 2020 16:28:55
>> > Asunto: Re: [Tagging] Rio de la Plata edit war

>> > On Tue, Aug 4, 2020 at 3:18 PM Joseph Eisenberg < 
>> > joseph.eisenb...@gmail.com >
>> > wrote:

>> >> These rules would exclude the lower Rio De La Plata and the lower part of 
>> >> the
>> >> mouth of the Saint Lawrence river, as well as other wide estuaries where 
>> >> winds
>> >> and tides have more influence on surface water flow than does the 
>> >> discharge of
>> >> the river. It would not prevent mapping the Hudson mouth at the southern 
>> >> tip of
>> >> Manhattan, because the flow is strong all the way to New York Harbor, if I
>> >> understand correctly.

>> > The Hudson definitely reverses flow. One of its names among the First 
>> > Peoples
>> > translates to 'the river flows both ways.' The division in the flow lies 
>> > less
>> > in the fraction of the tidal cycle than the speed of the current. It flows
>> > 'upstream' for half the time, 'downstream' for half, but the downstream 
>> > current
>> > is considerably swifter.

>> Rio de la Plata would not be excluded, as you can read in the document [8] i
>> linked in my first mail, for example, see some graphics of the flow of the
>> river in page 25.
>> [8] DINAMA. Salinidad
>> https://www.dinama.gub.uy/oan/documentos/uploads/2016/12/patrones_circulacion.pdf

>> Regaards,
>> M.

>> ---

>> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin 
>> costo.

>> Informate si aplicás aquí.

>> mvdfactura.uy

>> ---

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

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



---

Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin costo.

Informate si aplicás aquí.

mvdfactura.uy

---



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

Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

[Warin]

On 4/8/20 7:17 am, Joseph Eisenberg wrote:
Everyone, the voting period for natural=bare_ground is still open for 
4 more days.


I would recommend voting "no" on the current definition, unfortunately.

As mentioned above, the current definition is far too broad, and could 
easily be construed to include areas under construction, areas of bare 
soil due to use by people as a pathway or road area,
These are 'land use' not 'land cover' and can be tagged separately. They 
are orthogonal.
and many sorts of arid and semi-natural areas, including those that 
are partially covered by shrubs, heath, grass or other sparse vegetation,


The question is, what is dominate? An area of trees that is mostly trees 
should be tagged as trees, if it is mostly bear earth then tagged as 
bare earth...


OSM already has areas of combined trees and shrubs where the general 
guide used is tag what is dominate. No need to single this proposal with 
partial coverings as it applies to all of the present OSM tagging.



or even areas of farmland that are currently fallow.

Again a land use not a land cover.


Please see the discussion and objections on 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Ground


I think it is a good idea to have a way to tag bare soil which is not 
sand (natural=sand) or mostly stones (natural=shingle/scree) or mud, 
but we need a clear, limited definition which does not fit with 
human-use areas like roads, dirt parking lots, construction sites, 
abandoned quarries etc, and there needs to be more consideration about 
when the tag should be used instead of natural=heath and natural=scrub 
in arid regions where there are scattered bushes.


For the proposal author, I would suggest mapping some local features 
in your area which would fit the proposed definition, and then come 
back with photos plus aerial imagery of the areas which ought to be 
mapped with this tag. So far it has been mostly hypothetical, which 
makes it hard to understand which sorts of landscapes would qualify 
for this tag.



I think this is similar to the tags surface=earth and surface=dirt, both 
are poorly defined.


Perhaps these 2 tags would be better as surface=soil???


The proposal sates "An area covered by soil" so it should be natural=soil.

The description could then be "The upper layer of the planet earth being 
a material typically consisting of a mixture of organic remains, clay, 
and rock particles." ???



Of course the usual exclusions apply;

majority is soil

where a more detailed value applies, use it eg natural=clay if the 
majority of the area is covered by clay.






- Joseph Eisenberg

On Mon, Jul 27, 2020 at 5:58 AM Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:




sent from a phone

> On 27. Jul 2020, at 13:41, Michael Montani
mailto:michael.mont...@un.org>> wrote:
>
> I eventually found on-the-ground images of the feature I would
like to propose / map.


are these suggested to be represented as polygons? How would the
border be determined? I looks from the imagery as if there is a
smooth transition of these „features“ and neighbouring land which
isn’t completely bare. Did you try to map some of these and if
yes, could you please post a link to an area where a few are mapped?

Transitions from, say, trees to shrubs also occur. The guide is to map 
what is dominate, when domination changes is where the 'border' is. OSM 
does not have tagging for mixed areas, if you want it .. propose it?



Cheers Martin 



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