Re: [Tagging] addr:street for routes

[Shawn K. Quinn]

On 8/1/20 12:02, Paul Johnson wrote:
> For the way:
> 
> name=Humble-Huffman Road
> ref=FM 1960

Oops. I got the name wrong, it's Humble Westfield Road, and it only
exists in OSM data because I haven't yet surveyed to be sure it's not
signed.

I'm pretty sure none of the current signs use this name. The "name" on
the green signs is FM 1960 (not sure if they have "East" on them, but
the addresses do use this directional).

> For the address:
> addr:street=FM 1960 East

That we can agree on.

[my original message:]
>> I'm on the side that name=* should match what's in addr:street=*, even
>> if there's some duplicity, but maybe there should be some other tag to
>> say perhaps the name shouldn't be rendered on (most) visual maps and/or
>> read out separately from the ref in navigation software.

> Problem is, that does not necessarily match the ground truth.  In
> reality, a lot of addresses have a street name that radically departs
> from what the street is signposted as, particularly if the street is
> part of a numbered route.  It's common because there's only so much
> you can cram on an envelope and it's often shorter and easier to
> scrawl out "Hwy 12" instead of the street name than whatever the
> highway department named it.

Drawing from my prior experience as a messenger/courier, there were very
few situations where the address I was expected to deliver to did not
match the name on the sign. There were a couple of oddball situations
such as a couple of addresses off of FM 1960 West (now Cypress Creek
Parkway) where the building itself was far enough from the road to make
finding it difficult if you didn't know where to look (for the curious,
they are 4550 and 4606 among others). The most egregious examples come
where there's a complete lack of signage (county roads in Brazoria
County being the one that sticks out the most), but again, it's more of
there just not being an actual signed name versus a name that doesn't
match the sign.

It may well be different in greater Houston versus Oklahoma, upstate New
York, etc.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

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

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Graeme Fitzpatrick]

On Sun, 2 Aug 2020 at 13:12, Tod Fitch  wrote:

>
> Assuming that NPR is not geo-restricted to the US:
>
>
> https://www.npr.org/2020/07/09/889562040/supreme-court-rules-that-about-half-of-oklahoma-is-indian-land
>

Thanks, Tod!

Going to be interesting to see where this goes in the future.

Graeme
___
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)

[Jmapb]

On 8/1/2020 8:40 PM, 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.


Hi David -- My feeling is that often highway=service, without a
service=* tag, is a useful and valid tagging practice.

The basic rule I follow is that any road that is not part of the general
public road network but is more established than a track should be
highway=service. (There are exceptions of course -- privately operated
residential, unclassified, tertiary etc -- but that's the basic rule.)
If that road isn't obviously a driveway, alley, drive-through, or
parking aisle then I'm usually fine to omit the service=* tag.

Here of some of the situations where I use highway=service without
service=*:
 - Roads through cemeteries
 - Roads through campgrounds
 - Roads through schools
 - Roads through universities
 - Roads through hotels
 - Roads through museums
 - Roads through prisons
 - Roads through military areas
 - Roads through airports
 - Roads through retirement homes
 - Roads through resorts
 - Roads through reservoirs (sometimes over dams)
 - Roads through ski areas
 - Roads that serve privately-owned inholdings surrounded by public land
 - Maintenance roads in parks
 - Private semi-residential roads that serve multiple driveways
 - Non-public roads though industrial areas

This is just off the top of my head. There are probably dozens more in
use across the globe.

My feeling is that these uses do not require and would not much benefit
from a specified service= tag. I don't see the need for service=prison,
service=ski_area, service=campground, etc.

Jason


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

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Graeme Fitzpatrick]

On Sun, 2 Aug 2020 at 12:22, Clifford Snow  wrote:

>
> The agreed upon tag for reservations is boundary=aboriginal_lands. It's
> used extensively in the US, Including the Mohawk Nation and across the
> Saint Lawrence River in Canada. We don't have consensus on how to tag off
> reservation land trusts but that's another topic.
>

Slightly OT question here, please.

I remember reading a US press article ~12 months ago (may have even been
mentioned on here in discussions at the time re = aboriginal_land?) to the
effect that the US Supreme Court was shortly due to rule on whether
historic tribal lands actually now belong to the Indian Nations?

Does that ring any bells with our US members, & are you aware of any
outcome?

Thanks

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

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Clifford Snow]

On Sat, Aug 1, 2020 at 6:09 PM Kevin Kenny  wrote:

>
>
> On Sat, Aug 1, 2020 at 5:29 PM Paul Johnson  wrote:
>
>> On Sat, Aug 1, 2020 at 3:09 PM Clay Smalley 
>> wrote:
>>
>>> Chiming in as another settler. I really wish we had more Natives active
>>> on OSM contributing their cultural knowledge. What could we be doing
>>> different in the future to welcome and engage them in our community?
>>>
>>
>> Outreach to tribal GIS offices where they exist couldn't hurt.  The
>> standard map rendering native areas, particularly when most don't (or in
>> Oklahoma's case, most are *egregiously* incomplete, often only including
>> the Osage Nation) definitely is a nice start and I'm glad we're to that.
>> At least in the north american context, having a separate tag for
>> indigenous lands seems a little strange compared to filing it under the
>> administrative boundary, admin_level system, but I can live with it.
>>
>
> It depends on the jurisdiction.  The non-Federal Schaghticoke reservation
> in Connecticut is simply part of Kent Township; there's a tribal government
> of sorts but it's not recognized by the BIA, and so there isn't really an
> admin_level that would fit.
>
> On the other hand, all of the Indian Reservations in New York are not part
> of either Towns or Cities, and so would slot in nicely at admin_level=7.
> The sole inconsistency that designation would introduce is that the city of
> Salamanca is entirely within the Allegany reservation. (Salamanca, and
> several smaller communities, have significant non-Haudenosaunee populations
> and stand on reservation land that is leased from the Seneca Nation.)
>

The agreed upon tag for reservations is boundary=aboriginal_lands. It's
used extensively in the US, Including the Mohawk Nation and across the
Saint Lawrence River in Canada. We don't have consensus on how to tag off
reservation land trusts but that's another topic.

If you look at eastern Oklahoma, about 90%, Paul - correct me if I'm wrong,
is boundary=aboriginal_lands. Tulsa is pretty much completely inside of two
different reservations.

Best,
Clifford

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] kerb=regular vs. raised

[Warin]

On 31/7/20 12:42 am, Joseph Eisenberg wrote:
In Indonesia, Costa Rica, Peru and Mexico, it is common to find 30cm 
kerbs in older neighborhoods. In Nicaragua there were some that were 
at least 45 cm high, in Leon or Granada.


Tropical countries with heavy rainfall often do this to avoid flooding.



Also occurs near desert areas as they get 5 years rain fall in a day or 
two.


Broken Hill has regular (normal, expected) curb heights of 25 cm, where 
as Sydney has 15 cm .. not only are these in the same country but also 
in the same state.



The word 'regular' is a poor choice for this tagging.

What is being tagged is the wheelchair/stroller/wheelbarrow 
accessibility of the curb. That is what should be implied by the tagging 
used.



Much easier to tag the numerical height of the curb as this avoids the 
confusion of words, particularly with different languages, cultures and 
climates.







On Thu, Jul 30, 2020 at 7:02 AM Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:


Am Do., 30. Juli 2020 um 10:13 Uhr schrieb Philip Barnes
mailto:p...@trigpoint.me.uk>>:

when reading the term raised kerb I’d rather think about
something like 25-40cm, while 4 cm surely wouldn’t be
considered “raised”

At that height even a fit able bodied person would need to
think about crossing them.



that's why it could be interesting to tag it. If we had a
hierarchy lowered, regular, raised, it would make sense.


In built up areas typical raised kerbs are upto 15cm, being a
sad geek I have just measured the kerb outside, 12cm which is
certainly in my experience normal.



ok, then make it regular: 315

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



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

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Kevin Kenny]

On Sat, Aug 1, 2020 at 5:29 PM Paul Johnson  wrote:

> On Sat, Aug 1, 2020 at 3:09 PM Clay Smalley  wrote:
>
>> Chiming in as another settler. I really wish we had more Natives active
>> on OSM contributing their cultural knowledge. What could we be doing
>> different in the future to welcome and engage them in our community?
>>
>
> Outreach to tribal GIS offices where they exist couldn't hurt.  The
> standard map rendering native areas, particularly when most don't (or in
> Oklahoma's case, most are *egregiously* incomplete, often only including
> the Osage Nation) definitely is a nice start and I'm glad we're to that.
> At least in the north american context, having a separate tag for
> indigenous lands seems a little strange compared to filing it under the
> administrative boundary, admin_level system, but I can live with it.
>

It depends on the jurisdiction.  The non-Federal Schaghticoke reservation
in Connecticut is simply part of Kent Township; there's a tribal government
of sorts but it's not recognized by the BIA, and so there isn't really an
admin_level that would fit.

On the other hand, all of the Indian Reservations in New York are not part
of either Towns or Cities, and so would slot in nicely at admin_level=7.
The sole inconsistency that designation would introduce is that the city of
Salamanca is entirely within the Allegany reservation. (Salamanca, and
several smaller communities, have significant non-Haudenosaunee populations
and stand on reservation land that is leased from the Seneca Nation.)
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[David Dean]

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 feedback, everyone.

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

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Clifford Snow]

On Sat, Aug 1, 2020 at 2:28 PM Paul Johnson  wrote:

> On Sat, Aug 1, 2020 at 3:09 PM Clay Smalley  wrote:
>
>>
>> So I think the current tagging makes sense. Though I wonder if places
>> like these qualify as disputed territory. After all, the US and Canada have
>> a nation-to-nation relationship with each tribal government.
>>
>
> I don't believe that it counts as a disputed territory.  I also think
> taking the US and Canada's claim of the tribe having two distinct
> reservations with a shared boundary congruent with the US/Canada
> international boundary is not substantiated by the ground truth.  It's a
> single contiguous area, not two adjoining ones.  It happens to have the
> US/Canada boundary going through it, and AFAICT, nobody's disputing that.
> Just that this single contiguous tribal area happens to straddle that line.
>

Reading The Resolution [1] there does appear to be differences of opinion.
Disputed might seem a bit strong when considering some of the disputed
borders, ie. India and Pakistan, to describe the dispute between the tribe
and the county and state and possibly the federal government.

[1] https://www.srmt-nsn.gov/resolve-the-boundary/?p=resolvetheboundary

For now I'm satisfied to wait until we have the Tribes GIS contact info.

Best,
Clifford

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Paul Norman via Tagging]

On 2020-08-01 9:26 a.m., Alan Mackie wrote:
Perhaps I am an overly literal follower of the wiki, but I had always 
assumed the coastline should continue inland as far as the tide 
continues to be noticeable. Mediterranean mapping might be an issue, 
but elsewhere I think this is fairly clear?


Starting locally, the Fraser River has a strong tidal influence 25km 
upstream of the coastline/riverbank edge. Fishers report a tidal 
influence 90km upstream. Wikipedia says the Columbia has tidal influence 
up to the first dam, which is 120km upstream of the coastline/riverbank 
edge. There are tidal forecasts published for 75km upstream of the edge.


Looking in Europe, the Thames is tidal for 80km upstream of the 
coastline/riverbank edge.


If the water is fresh or the waterway still appears to be a river, 
canal etc, then it seems reasonable that they should also have those 
tags as well. The coastline and riverbank tags aren't fighting for a 
common key, so it's not a direct tagging conflict.


I would consider an area mapped as water both with natural=coastline and 
waterway=riverbank or natural=water in error. I haven't seen any cases 
where this is done.



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

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Paul Johnson]

On Sat, Aug 1, 2020 at 3:09 PM Clay Smalley  wrote:

> Chiming in as another settler. I really wish we had more Natives active on
> OSM contributing their cultural knowledge. What could we be doing different
> in the future to welcome and engage them in our community?
>

Outreach to tribal GIS offices where they exist couldn't hurt.  The
standard map rendering native areas, particularly when most don't (or in
Oklahoma's case, most are *egregiously* incomplete, often only including
the Osage Nation) definitely is a nice start and I'm glad we're to that.
At least in the north american context, having a separate tag for
indigenous lands seems a little strange compared to filing it under the
administrative boundary, admin_level system, but I can live with it.

On Sat, Aug 1, 2020 at 12:28 PM Kevin Kenny  wrote:
>
>> Both the US and Canada consider the river to be the US-Canada boundary,
>> and that the reservations are their separate dependencies. The Canadians
>> recognize the Six Nations as domestic dependent nations, and they enjoy
>> limited sovereignty on their own lands.
>>
>
> I think what you've said here hints at the answer. The US and Canada are
> UN member states with international recognition, each with an autonomous
> region under indigenous governance. The tribal governments themselves may
> dispute this, which is fair. Perhaps one day they might have an
> internationally recognized sovereign state with defined borders. But on the
> ground as of 2020, there are no such states, only subnational autonomous
> regions.
>

Well, there *was* Bolivia until last month, but Elon Musk helped finance a
coup so he could continue using the country as a cheap source of lithium
for car batteries.


> So I think the current tagging makes sense. Though I wonder if places like
> these qualify as disputed territory. After all, the US and Canada have a
> nation-to-nation relationship with each tribal government.
>

I don't believe that it counts as a disputed territory.  I also think
taking the US and Canada's claim of the tribe having two distinct
reservations with a shared boundary congruent with the US/Canada
international boundary is not substantiated by the ground truth.  It's a
single contiguous area, not two adjoining ones.  It happens to have the
US/Canada boundary going through it, and AFAICT, nobody's disputing that.
Just that this single contiguous tribal area happens to straddle that line.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Clay Smalley]

Chiming in as another settler. I really wish we had more Natives active on
OSM contributing their cultural knowledge. What could we be doing different
in the future to welcome and engage them in our community?

On Sat, Aug 1, 2020 at 12:28 PM Kevin Kenny  wrote:

> Both the US and Canada consider the river to be the US-Canada boundary,
> and that the reservations are their separate dependencies. The Canadians
> recognize the Six Nations as domestic dependent nations, and they enjoy
> limited sovereignty on their own lands.
>

I think what you've said here hints at the answer. The US and Canada are UN
member states with international recognition, each with an autonomous
region under indigenous governance. The tribal governments themselves may
dispute this, which is fair. Perhaps one day they might have an
internationally recognized sovereign state with defined borders. But on the
ground as of 2020, there are no such states, only subnational autonomous
regions.

So I think the current tagging makes sense. Though I wonder if places like
these qualify as disputed territory. After all, the US and Canada have a
nation-to-nation relationship with each tribal government.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Clifford Snow]

On Sat, Aug 1, 2020 at 12:27 PM Kevin Kenny  wrote:

>
>
> On Sat, Aug 1, 2020 at 2:25 PM Clifford Snow 
> wrote:
>
>> After some digging, it appears that Saint Regis Mohawk Indian Territory
>> is in OSM. Just across the border, on a Saint Lawrence River island, is the
>> Akwesasne 59 First Nations tribe is also in OSM. According to Wikipedia [1]
>> the Mohawk consider their territory to be a single nation, with no border
>> separating its parts.
>>
>> It seems to me that we should map the tribal areas as one. Possibly as a
>> super relation, though I'm not sure if super relations are used for
>> boundaries. What I find interesting is that the Canadian Border Crossing is
>> located on the North side of the Saint Lawrence River while the US crossing
>> station is located on the South side of the river. It seems to imply that
>> the Akwesasne Nation is not in either country.
>>
>> [1] https://en.wikipedia.org/wiki/St._Regis_Mohawk_Reservation
>>
>
> It's complicated. (When are sovereignty disputes _not_ complicated?)
>
> Both the US and Canada consider the river to be the US-Canada boundary,
> and that the reservations are their separate dependencies. The Canadians
> recognize the Six Nations as domestic dependent nations, and they enjoy
> limited sovereignty on their own lands. The US recognizes certain
> Haudenosaunee lands as dependent nations, but Akwesáhsne is not one of
> them, owing to the fact that they have not adopted a written constitution
> and a representative democracy. (In completely open elections, they
> consistently prefer their semi-hereditary chiefship, and elect the
> traditional chiefs to the political offices. In current practice, the
> traditional chiefs are disqualified from standing for election.)
>
> The Jay Treaty of 1795 recognizes that the Akwesáhsro:non have freedom to
> travel their land on both banks of the river.  The current rule is
> particularly burdensome: an Akwesáhsro:non wishing to return to Cornwall
> Island from Saint Regis must first cross a second bridge into Canada to
> clear customs and pay duty if necessary, and then return to Cornwall
> Island. There have been recurring discussions of placing the Canadian port
> of entry on the US side of the river to avoid this situation.
>
> There was an earlier query in the thread about government web sites: The
> respective tribal governments maintain Web presence at
> http://www.akwesasne.ca/
> and https://www.srmt-nsn.gov/
>
> I've refrained from trying to map the situation, not being qualified. (I'm
> an Old White Guy with a trace of Six Nations ancestry,)
>

I've sent an email to Franklin County GIS asking for current boundaries as
well as any contact he may have with the tribe. Like Paul said, it would be
best if we could get someone from the tribe involved. It will still be
messy but at least someone local is involved.

>From another old white guy - with no trace of any ancestry of any kind

Clifford

-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Jarek Piórkowski]

On Sat, 1 Aug 2020 at 14:24, Clifford Snow  wrote:
> What I find interesting is that the Canadian Border Crossing is located on 
> the North side of the Saint Lawrence River while the US crossing station is 
> located on the South side of the river. It seems to imply that the Akwesasne 
> Nation is not in either country.

Prosaically, many border control points are built a little away from
the actual border, where it's convenient to build them.

Per Wikipedia, the Canadian border control point was moved from the
island in 2009 after a protest against CBSA agents beginning to carry
firearms.

My personal interpretation reading between the lines is that the
current location is a compromise. You won't find the federal
government saying they don't control the land, but neither was there
an appetite to push for an all-out confrontation. That being said, the
notion of being "in a country" like Canada is of course colonial and
seems to increasingly be fraying for some Indigenous areas here.

--Jarek

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

[Tagging] Feature Proposal - RFC - kerb=regular

[Supaplex]

Hey all,

As already mentioned on this list I intend to add the tag kerb=regular
to explicitly distinguish common standard height kerbs/curbs from
kerb=raised. Proposal, information and further discussion can be found
here: https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular

For the formality and documentation I send this again as an official RFC.

I hope for your comments - greets
Alex


Am 01.08.20 um 15:01 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 1. Aug 2020, at 12:36, Supaplex  wrote:
>>
>> I wrote a proposal for it: 
>> https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular
>>
>> How should I proceed - can I already set the status to "Proposed"? Do I have 
>> to write a separate email for RFC or is this thread sufficient?
>>
>> I hope for your comments - greets
>> Alex
>>
>
> I would see this email to be an RFC, although it could have been better to 
> explicitly include the acronym RFC in the subject of your message, as this is 
> what the guidelines state. The procedure for proposal is presented here:
> https://wiki.openstreetmap.org/wiki/Proposal_process
>
> 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] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Kevin Kenny]

On Sat, Aug 1, 2020 at 2:25 PM Clifford Snow 
wrote:

> After some digging, it appears that Saint Regis Mohawk Indian Territory is
> in OSM. Just across the border, on a Saint Lawrence River island, is the
> Akwesasne 59 First Nations tribe is also in OSM. According to Wikipedia [1]
> the Mohawk consider their territory to be a single nation, with no border
> separating its parts.
>
> It seems to me that we should map the tribal areas as one. Possibly as a
> super relation, though I'm not sure if super relations are used for
> boundaries. What I find interesting is that the Canadian Border Crossing is
> located on the North side of the Saint Lawrence River while the US crossing
> station is located on the South side of the river. It seems to imply that
> the Akwesasne Nation is not in either country.
>
> [1] https://en.wikipedia.org/wiki/St._Regis_Mohawk_Reservation
>

It's complicated. (When are sovereignty disputes _not_ complicated?)

Both the US and Canada consider the river to be the US-Canada boundary, and
that the reservations are their separate dependencies. The Canadians
recognize the Six Nations as domestic dependent nations, and they enjoy
limited sovereignty on their own lands. The US recognizes certain
Haudenosaunee lands as dependent nations, but Akwesáhsne is not one of
them, owing to the fact that they have not adopted a written constitution
and a representative democracy. (In completely open elections, they
consistently prefer their semi-hereditary chiefship, and elect the
traditional chiefs to the political offices. In current practice, the
traditional chiefs are disqualified from standing for election.)

The Jay Treaty of 1795 recognizes that the Akwesáhsro:non have freedom to
travel their land on both banks of the river.  The current rule is
particularly burdensome: an Akwesáhsro:non wishing to return to Cornwall
Island from Saint Regis must first cross a second bridge into Canada to
clear customs and pay duty if necessary, and then return to Cornwall
Island. There have been recurring discussions of placing the Canadian port
of entry on the US side of the river to avoid this situation.

There was an earlier query in the thread about government web sites: The
respective tribal governments maintain Web presence at
http://www.akwesasne.ca/
and https://www.srmt-nsn.gov/

I've refrained from trying to map the situation, not being qualified. (I'm
an Old White Guy with a trace of Six Nations ancestry,)
-- 
73 de ke9tv/2, Kevin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Should admin_level=1 tag be applied to EU?

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2020, at 17:20, Alan Mackie  wrote:
> 
> I don't know how I'd map this. Do you have to pass through border checkpoints 
> when you enter or leave the area? 


around here, no, but neither are there border checkpoints at the border of the 
main territory, you just walk there without noticing you are changing country 
(referring to the Vatican City)


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

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Clifford Snow]

After some digging, it appears that Saint Regis Mohawk Indian Territory is
in OSM. Just across the border, on a Saint Lawrence River island, is the
Akwesasne 59 First Nations tribe is also in OSM. According to Wikipedia [1]
the Mohawk consider their territory to be a single nation, with no border
separating its parts.

It seems to me that we should map the tribal areas as one. Possibly as a
super relation, though I'm not sure if super relations are used for
boundaries. What I find interesting is that the Canadian Border Crossing is
located on the North side of the Saint Lawrence River while the US crossing
station is located on the South side of the river. It seems to imply that
the Akwesasne Nation is not in either country.

[1] https://en.wikipedia.org/wiki/St._Regis_Mohawk_Reservation

Clifford

On Fri, Jul 31, 2020 at 8:15 PM Paul Johnson  wrote:

> I do not, which was a big problem with that.  I like mapping
> weird boundaries like that, so I tried to take it on, but it seems there's
> somewhat conflicting information between the tribe, US and Canada on this.
> I strongly suspect we're going to need to find an Ahkwesáhsnean that knows
> the boundaries well to get a solid cut on this and I'm not entirely sure
> how to reach out.
>
> On Fri, Jul 31, 2020 at 9:52 PM Clifford Snow 
> wrote:
>
>> Paul,
>> Do you have any website or contact info for the tribe? There are a number
>> of websites but not sure exactly which one. Although it be nice to get them
>> all added.
>>
>> Clifford
>>
>> On Fri, Jul 31, 2020 at 7:17 PM Paul Johnson  wrote:
>>
>>>
>>>
>>> On Fri, Jul 31, 2020 at 6:59 PM Clifford Snow 
>>> wrote:
>>>


 On Fri, Jul 31, 2020 at 11:54 AM Kevin Kenny 
 wrote:

>
>
> The nearest problem case to me is Ahkwesáhsne, a territory of
> the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy that straddles
> the US-Canadian border, and whose government is recognized by neither
> state. The political situation there has deteriorated into shootings as
> recently as 1990, and sabre-rattling among US, Canadian and Akwesáhsro:non
> persons as recently as 2009. The disputes usually stem from one or the
> other large nation deciding to deny the Kanien'kehá free pratique to 
> travel
> and trade within their own nation, requiring customs and imposts every 
> time
> the US-Canadian border is crossed.
>
> Kevin,
 Has this disputed territory been map in OSM? I went looking for it but
 struck out. Just the name Ahkwesáhsne returned zero results.

>>>
>>> I attempted to do so but was not able to proceed because of conflicting
>>> information relying on dubious sources.
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>>
>> --
>> @osm_washington
>> www.snowandsnow.us
>> OpenStreetMap: Maps with a human touch
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Christoph Hormann]

On Friday 31 July 2020, Andy Townsend wrote:
>
> For what it's worth, neither extreme position looks the best answer
> to me - looking at the salinity change between river to ocean at
> https://www.sciencedirect.com/science/article/pii/S0307904X07000716
> (see
> https://www.sciencedirect.com/science/article/pii/S0307904X07000716
> for the key picture) and looking at
> https://de.wikipedia.org/wiki/Datei:Rio_de_la_Plata_BA_2.JPG suggests
> a location some way between the two.  Despite the NASA photo it looks
> like there isn't a "step change" in salinity - and of course values
> will fluctuate based on winds and tides etc.

Surface salinity is not a good universal measure for the transit between 
the riverine and the maritime domain because

a) depending on the threshold you would exclude large maritime areas 
like the Baltic Sea, Hudson Bay or the Sea of Azov.
b) at the mouth of a river salinity often varies significantly between 
the surface layer and deeper water because saltwater is heavier.

Suspended particles are also often not a good measure because we are 
usually talking about very fine particles that stay suspended for a 
long time and in shallow water currents can re-suspend silt from the 
bottom as well.  The presence of suspended particles is therefore an 
indication of a lack of large volume dilution of the water in the area, 
not of the dominance of river water over sea water in general.  See for 
example

http://maps.imagico.de/#map=7/32.361/122.212=en=sat=10

where strongly visible turbidity reaches up to more than 50km from the 
shore into the open sea.

As i wrote in my old proposal on the transit placement looking at the 
cross section of the river and the resulting average water flow 
velocity due to discharge gives you a relatively good idea about the 
situation.  In case of the Rio de la Plata you have an average 
discharge of 22000m^3/s.  At the claimed baseline you have an average 
water depth of about 20m and a width of more than 200km that is an 
average waterflow velocity of 6mm/s.  At Montevideo with a width of 
about 100km and a depth of about 8m you get an average velocity of 
3cm/s.  That is still smaller than typical coastal currents induced by 
tides and wind (which the paper you cited confirms).  But you are not 
that far off any more and around where the average water depth is about 
5m you will have reached the lower limit my proposal suggests.

I still think the people best qualified to make the assessment where 
exactly the transit is best placed are those with local knowledge, who 
have first hand knowledge of the effects of waves, tides and currents 
on the shore over the course of the year as long as their perspective 
is not dominated by political considerations (i.e. they are able to 
look at this purely from a physical geography perspective).

-- 
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

[Jez Nicholson]

Yes, and no. It gets tricky. Look at the Thames, which is tidal up to
Teddington Lock, but you wouldn't really say that Richmond is "on the
coast" now would you? But for flood risk assessment it is in danger of
tidal/coastal flooding.

On Sat, 1 Aug 2020, 17:27 Alan Mackie,  wrote:

>
>
> On Sat, 1 Aug 2020 at 07:21, Paul Norman via Tagging <
> tagging@openstreetmap.org> wrote:
>
>> On 2020-07-31 8:21 a.m., Andy Townsend wrote:
>>
>> On 26/05/2020 00:20, Alan Mackie wrote:
>>
>> Has this edit war stabilised?
>>
>> Apparently it has been blocking coastline updates across the whole world
>> for *months *now.
>>
>> https://osmdata.openstreetmap.de/data/land-polygons.html
>> https://github.com/fossgis/osmdata/issues/7
>>
>> (picking this thread up again because there still hasn't exactly been a
>> meeting of minds here)
>>
>> land polygons have been generated (see
>> https://osmdata.openstreetmap.de/data/land-polygons.html ) and
>> https://github.com/fossgis/osmdata/issues/7 has been resolved by
>> manually "releasing" the coastline.  The current situation in OSM is
>> https://overpass-turbo.eu/s/WD8 - at the time of writing this the
>> coastline crosses the river north of Buenos Aires.
>>
>> However, edits are continuing (see
>> https://www.openstreetmap.org/changeset/88787419 ).  I'm not convinced
>> that moving to one of two extremes, even a small amount at a time, is a
>> good idea until there's actually been discussion between the proponents of
>> the various positions.
>>
>> For what it's worth, neither extreme position looks the best answer to me
>> - looking at the salinity change between river to ocean at
>> https://www.sciencedirect.com/science/article/pii/S0307904X07000716 (see
>> https://www.sciencedirect.com/science/article/pii/S0307904X07000716 for
>> the key picture) and looking at
>> https://de.wikipedia.org/wiki/Datei:Rio_de_la_Plata_BA_2.JPG suggests a
>> location some way between the two.  Despite the NASA photo it looks like
>> there isn't a "step change" in salinity - and of course values will
>> fluctuate based on winds and tides etc
>>
>>
>> I live near the coast and have done coastline processing, including a
>> great deal worldwide during the redaction.
>>
>> Salinity and territorial control have seldom been considerations in where
>> the break between water mapped as waterway=riverbank and natural=coastline
>> that I have seen. The break is chosen as a convenient place for mappers and
>> a common view of where the coast of the ocean is, not based on scientific
>> salinity criteria. For territorial control, look at all the inlets along
>> the BC or Norwegian coasts.
>>
> Perhaps I am an overly literal follower of the wiki, but I had always
> assumed the coastline should continue inland as far as the tide continues
> to be noticeable. Mediterranean mapping might be an issue, but elsewhere I
> think this is fairly clear?
>
> If the water is fresh or the waterway still appears to be a river, canal
> etc, then it seems reasonable that they should also have those tags as
> well. The coastline and riverbank tags aren't fighting for a common key, so
> it's not a direct tagging conflict.
>
> As for territorial control, there are archipelagic states with territorial
> waters despite large gaps between all their islands. I'm not sure why
> inlets or bays pose a problem?
> ___
> 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] addr:street for routes

[Paul Johnson]

On Sat, Aug 1, 2020 at 12:19 AM Shawn K. Quinn  wrote:

> On 7/31/20 14:29, Paul Johnson wrote:
> > Name is only the name.  Names are not refs.  For the above example,
> > ref=NY 214, noname=yes would be the right way.
>
> How about the stretch of FM 1960 from I-45 or so going east into Humble?
> Addresses on it are " FM 1960 East", though I think it used to be
> signed as "Humble-Huffman Road" even though nobody puts that in the
> addresses anymore. I currently have name=FM 1960 East alongside ref=FM
> 1960 (and maybe an alt_name=* too). (For those outside of Texas, FM or
> RM is like a lower class of state highway called Farm-/Ranch-To-Market
> Roads.)
>

For the way:

name=Humble-Huffman Road
ref=FM 1960

For the address:
addr:street=FM 1960 East

I'm on the side that name=* should match what's in addr:street=*, even
> if there's some duplicity, but maybe there should be some other tag to
> say perhaps the name shouldn't be rendered on (most) visual maps and/or
> read out separately from the ref in navigation software.
>

Problem is, that does not necessarily match the ground truth.  In reality,
a lot of addresses have a street name that radically departs from what the
street is signposted as, particularly if the street is part of a
numbered route.  It's common because there's only so much you can cram on
an envelope and it's often shorter and easier to scrawl out "Hwy 12"
instead of the street name than whatever the highway department named it.

Plus, existing schemes of *not* reproducing the ref in the name already
solves the problem.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rio de la Plata edit war

[Alan Mackie]

On Sat, 1 Aug 2020 at 07:21, Paul Norman via Tagging <
tagging@openstreetmap.org> wrote:

> On 2020-07-31 8:21 a.m., Andy Townsend wrote:
>
> On 26/05/2020 00:20, Alan Mackie wrote:
>
> Has this edit war stabilised?
>
> Apparently it has been blocking coastline updates across the whole world
> for *months *now.
>
> https://osmdata.openstreetmap.de/data/land-polygons.html
> https://github.com/fossgis/osmdata/issues/7
>
> (picking this thread up again because there still hasn't exactly been a
> meeting of minds here)
>
> land polygons have been generated (see
> https://osmdata.openstreetmap.de/data/land-polygons.html ) and
> https://github.com/fossgis/osmdata/issues/7 has been resolved by manually
> "releasing" the coastline.  The current situation in OSM is
> https://overpass-turbo.eu/s/WD8 - at the time of writing this the
> coastline crosses the river north of Buenos Aires.
>
> However, edits are continuing (see
> https://www.openstreetmap.org/changeset/88787419 ).  I'm not convinced
> that moving to one of two extremes, even a small amount at a time, is a
> good idea until there's actually been discussion between the proponents of
> the various positions.
>
> For what it's worth, neither extreme position looks the best answer to me
> - looking at the salinity change between river to ocean at
> https://www.sciencedirect.com/science/article/pii/S0307904X07000716 (see
> https://www.sciencedirect.com/science/article/pii/S0307904X07000716 for
> the key picture) and looking at
> https://de.wikipedia.org/wiki/Datei:Rio_de_la_Plata_BA_2.JPG suggests a
> location some way between the two.  Despite the NASA photo it looks like
> there isn't a "step change" in salinity - and of course values will
> fluctuate based on winds and tides etc
>
>
> I live near the coast and have done coastline processing, including a
> great deal worldwide during the redaction.
>
> Salinity and territorial control have seldom been considerations in where
> the break between water mapped as waterway=riverbank and natural=coastline
> that I have seen. The break is chosen as a convenient place for mappers and
> a common view of where the coast of the ocean is, not based on scientific
> salinity criteria. For territorial control, look at all the inlets along
> the BC or Norwegian coasts.
>
Perhaps I am an overly literal follower of the wiki, but I had always
assumed the coastline should continue inland as far as the tide continues
to be noticeable. Mediterranean mapping might be an issue, but elsewhere I
think this is fairly clear?

If the water is fresh or the waterway still appears to be a river, canal
etc, then it seems reasonable that they should also have those tags as
well. The coastline and riverbank tags aren't fighting for a common key, so
it's not a direct tagging conflict.

As for territorial control, there are archipelagic states with territorial
waters despite large gaps between all their islands. I'm not sure why
inlets or bays pose a problem?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2020, at 16:57, Jan Michel  wrote:
> 
> Sorry for not being more clear: There is no connotation of a "maximum" or 
> "allowable limit" in neither the English nor the German term.
> "gross weight" or "Gesamtgewicht" is just the current total weight, without 
> any statement about how much additional load might be possible.
> An empty truck has a lower gross weight than a full one, although the gross 
> weight rating stays the same


gross weight means the weight of the vehicle including payload, petrol, 
passengers etc., and the gross weight rating therefore implies a maximum 
payload. The rating is about the maximum permissible gross weight. 


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

Re: [Tagging] Should admin_level=1 tag be applied to EU?

[Alan Mackie]

On Fri, 31 Jul 2020 at 19:56, Kevin Kenny  wrote:

> On Thu, Jul 30, 2020 at 5:07 PM Alan Mackie  wrote:
>
>> Many if not most of the entities mentioned in this discussion as being
>> candidates for "admin level above country" do have geographic reach
>> encompassing multiple countries, but are also limited in scope, often
>> severely. To tag such a limited body as fully encompassing a higher admin
>> level seems fundamentally flawed as a concept. If their powers were
>> expanded to have unlimited scope within that geographic area you would
>> effectively have a single larger country. Having an entity grow in scope
>> from "admin levels that includes (largely) independent countries" down to
>> admin level of a country seems counter to the general structure.
>>
>
> The defining test probably has to be the power to engage in foreign
> relations with entities at the same admin_level without deferring to the
> next higher level.
>
> Possibly. My main thrust is that I think the top level, "doesn't formally
have to defer to anyone", should share a common admin_level.

The test as you have stated it fails in federal systems. In the US, at
> least, the plenary power to govern belongs to the States (Or to the People,
> but constitutionally this is enforced only by a requirement that each State
> have a republican form of government.)  The national government has only
> those powers that are delegated to it from the states under the
> Constitution. When it tries to exercise plenary jurisdiction (as, alas,
> we're seeing nowadays!), it tends to unfold as a constitutional crisis.
> The States are above the Federal government, not beneath it.
>
> The reason that this principle is not obvious from abroad is that the
> States have delegated to the Federal government the sole power to engage in
> foreign relations; a State may not engage in diplomacy abroad because the
> States have relinquished that power.  Which is why, when you arrive at JFK,
> you clear US customs and not New York's.
>
> Above/below is often rather fuzzy when talking about systems with
elections. An overwhelming majority of states need to ratify constitutional
amendments for them to become effective, but as states representatives form
the federal legislature that pass them anyway this seems like another path
to the same conclusion (not that requiring multiple paths is a bad thing
when it comes to big decisions). What may be relevant here is that states
that vote against an amendment in congress and refuse to ratify the
amendment when passed would still see powers transferred from them to the
federal government.



> By the way, a 'containment' test fails as well in the US.  While there are
> no municipal governments that cross state lines (there are some
> special-purpose entities that do by the consent of both states and the
> Congress, such as the Port Authority of New York and New Jersey), it's not
> uncommon for a city to lie in more than one county, or a village in more
> than one township.  Having a clean hierarchy of admin_levels just isn't
> important to USAians.
>
> I'm OK with higher admin levels cutting across lower ones or overlapping
when they share jurisdictions. What may be useful is some way of recording
who does what in broad, "visible to the mapper", categories.

And I have Absolutely No Idea what to do with extraterritorial dependencies
> or domestic dependent nations.
>
> Feel free to stop reading here. I'm going off topic.
>
> The nearest problem case to me is Ahkwesáhsne, a territory of
> the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy that straddles
> the US-Canadian border, and whose government is recognized by neither
> state. The political situation there has deteriorated into shootings as
> recently as 1990, and sabre-rattling among US, Canadian and Akwesáhsro:non
> persons as recently as 2009. The disputes usually stem from one or the
> other large nation deciding to deny the Kanien'kehá free pratique to travel
> and trade within their own nation, requiring customs and imposts every time
> the US-Canadian border is crossed.
>
> I don't know how I'd map this. Do you have to pass through border
checkpoints when you enter or leave the area?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[David Marchal via Tagging]

To Jan Michel (I did not have your mail, as I unsubscribed of the list mails to 
avoid cluttering my mailbox): the goal of my request is not to assist routing 
software in finding a route, but to help navigation software to display the 
destination signs as they are on the ground. If a destination is restricted to 
some vehicles, for instance the ones below 12 tons, the navigation software 
should have access to the restriction, to allow it to display the restriction 
on the screen, or to not display the destination if the routed vehicle is not 
concerned, i.e. if the routed vehicle is over 12 tons.

I agree with the fee/toll part, I had the wrong tag in mind.

Concerning weight, french tonnage signs indeed concern weight rating, not 
actual weight, but, as maxweight is often used for such signs, I kept it for my 
question.

Concerning the documentation, I agree it is not well structured and could 
largely be improved. In my case, the proposal is more a way to formalise the 
reasoning and interpretation for the suggested tagging scheme. I am not willing 
to publish a brand new tagging scheme as if I was documenting something already 
well established. That would be confusing: it is something new, currently used 
nowhere, and I feel the proposal process is there for that: to allow 
suggestions to be discussed and approved, thus limiting tagging and wiki 
disorganization.

Regards.
--
Nouvelle adresse mail : penegal...@protonmail.com

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
Le vendredi 31 juillet 2020 15:53, David Marchal  a 
écrit :

> Hello, there.
>
> I'm wondering, there are destination signs which only apply to some kind of 
> vehicles: for HGV, for bicycles, for pedestrians, for vehicles below 12t… How 
> would I tag such destinations? The simple way would be to use, respectively, 
> destination:hgv=*, destination:bicycle=*, destination:foot=*, 
> destination:conditional="* @ weight<12". Am I right to assume these?
>
> If so, some examples:
>
> - in this example (https://www.mapillary.com/map/im/mo0AKf9masIEfpJtySH8fw), 
> the road ahead would be tagged (regardless of direction), 
> destination="Darney;Plombières;Bains-les-B.;Gare S.N.C.F.;Gare" and 
> destination:hgv="Vesoul;Mulhouse;Darney;Plombières;Bains-les-B.;Gare 
> S.N.C.F.;Gare"
> - in this example (https://www.mapillary.com/map/im/Oz3Om7pGbk7LA5wSmYLRew), 
> the link would be tagged destination:fee="Milan;Turin;Aoste;Courmayeur;Tunnel 
> du Mᵗ Blanc"
> - in this example (https://www.mapillary.com/map/im/pNJJG6ST4njXchZDQZ3XPw), 
> the road exiting the turnaround would be tagged 
> destination="Épinal;Bruyères;Remiremont;Quartiers sud;Zones industrielles" 
> and 
> destination:conditional="(Saint-Dié;Raon-l’Étape;Épinal;Bruyères;Remiremont;Quartiers
>  sud;Zones industrielles) @ weight>3.5 AND hgv"
> - in this example (https://www.mapillary.com/map/im/71zRlujmD69aPg35BFO1r6), 
> the road exiting the turnaround would be tagged destination="La Voivre", 
> destination:bicycle="La Voivre;Sᵗ Dié" and destination:ref="C 3"
>
> Is that correct? Can I edit the Wiki destination tag page to give these 
> informations, or maybe should I submit a RFC to formalize this?
>
> Awaiting your answers,
>
> Regards.
> --
> Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Jan Michel]

On 01.08.20 16:23, Martin Koppenhoefer wrote:
No, "gross" refers to the German "Gesamt" as in "total weight of 
vehicle, driver and load". The precise translation of "gross weight" 
is "Bruttogewicht" or "Gesamtgewicht".

that’s what I said, maximum payload included


Sorry for not being more clear: There is no connotation of a "maximum" 
or "allowable limit" in neither the English nor the German term.
"gross weight" or "Gesamtgewicht" is just the current total weight, 
without any statement about how much additional load might be possible.
An empty truck has a lower gross weight than a full one, although the 
gross weight rating stays the same.



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

Re: [Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2020, at 16:21, Jan Michel  wrote:
> 
>> which implies empty mass plus maximum mass of payload.
> 
> 
> No, "gross" refers to the German "Gesamt" as in "total weight of vehicle, 
> driver and load". The precise translation of "gross weight" is 
> "Bruttogewicht" or "Gesamtgewicht".


that’s what I said, maximum payload included___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Jan Michel]

On 01.08.20 15:36, Martin Koppenhoefer wrote:

On 1. Aug 2020, at 15:27, Jan Michel  wrote:
General terminology point of view:
As I understand it, the term 'rating' already refers to the allowed limit. Note 
that it's called 'gross weight rating', but not 'maximum gross weight rating'.

I guess the “gross” part refers to a maximum.
As in “zulässige Gesamtmasse”
which implies empty mass plus maximum mass of payload.


No, "gross" refers to the German "Gesamt" as in "total weight of 
vehicle, driver and load". The precise translation of "gross weight" is 
"Bruttogewicht" or "Gesamtgewicht".



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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[Jan Michel]

Hi,

On 01.08.20 15:48, David Marchal via Tagging wrote:
Hm, it seems a smart way to manage such cases; I could add the 
restrictions on the relation, like hazmat:water=no or maxweight=12. I 
assume that, in such cases, I must create a destination_sign relation 
for unrestricted destinations, and one for each destination restriction 
(if there are several restrictions, one relation for each restriction).


Is it widestream to have several destinations in one single relation, or 
is it necessary to add a relation per destination? Having one relation 
per destination would be a pain in the ass.


I'd say "yes" from my personal experience, but that might be biased. I'm 
inclined to use the destination* tags on a relation in the same way as 
those on ways.


What about application support? Are destination_sign relations widely 
supported, or are they mostly ignored by software like Osmand?


I'm not aware of any users despite of hiking maps (i.e. waymarkedtrails.org)

I would like to add this possibility on the Wiki; do you think it would 
be necessary to fill a proposal, or could I just add it, as it is a 
simple, self-explaining, combination of preexisting tags?


Using a vehicle type (bicycle, foot) is already used several thousand 
times on the relations and even more often on the destination signs 
themselves. So I don't see a problem to just use e.g. hgv as well.

We should add a statement in the Wiki documentation.

On the other hand, I wouldn't use access tags like maxweight without a 
detailed discussion.

(As always, that's just my personal opinion)

Jan


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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[David Marchal via Tagging]

Hm, it seems a smart way to manage such cases; I could add the restrictions on 
the relation, like hazmat:water=no or maxweight=12. I assume that, in such 
cases, I must create a destination_sign relation for unrestricted destinations, 
and one for each destination restriction (if there are several restrictions, 
one relation for each restriction).

Is it widestream to have several destinations in one single relation, or is it 
necessary to add a relation per destination? Having one relation per 
destination would be a pain in the ass.

What about application support? Are destination_sign relations widely 
supported, or are they mostly ignored by software like Osmand?

I would like to add this possibility on the Wiki; do you think it would be 
necessary to fill a proposal, or could I just add it, as it is a simple, 
self-explaining, combination of preexisting tags?

Awaiting your answers,

Regards.
--
Nouvelle adresse mail : penegal...@protonmail.com

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
Le samedi 1 août 2020 11:12, Andrew Harvey  a écrit :

> While you're talking about the destination tag, I think when using a 
> destination_sign relation it's best to apply the mode as eg. 
> bicycle=designated, eg 
> https://www.openstreetmap.org/relation/11345354#map=18/-33.82573/151.21308 
> for https://www.mapillary.com/map/im/VIq-OPTiw0BVI7gqdLR-iA
>
> On Fri, 31 Jul 2020 at 23:55, David Marchal via Tagging 
>  wrote:
>
>> Hello, there.
>>
>> I'm wondering, there are destination signs which only apply to some kind of 
>> vehicles: for HGV, for bicycles, for pedestrians, for vehicles below 12t… 
>> How would I tag such destinations? The simple way would be to use, 
>> respectively, destination:hgv=*, destination:bicycle=*, destination:foot=*, 
>> destination:conditional="* @ weight<12". Am I right to assume these?
>>
>> If so, some examples:
>>
>> - in this example (https://www.mapillary.com/map/im/mo0AKf9masIEfpJtySH8fw), 
>> the road ahead would be tagged (regardless of direction), 
>> destination="Darney;Plombières;Bains-les-B.;Gare S.N.C.F.;Gare" and 
>> destination:hgv="Vesoul;Mulhouse;Darney;Plombières;Bains-les-B.;Gare 
>> S.N.C.F.;Gare"
>> - in this example (https://www.mapillary.com/map/im/Oz3Om7pGbk7LA5wSmYLRew), 
>> the link would be tagged 
>> destination:fee="Milan;Turin;Aoste;Courmayeur;Tunnel du Mᵗ Blanc"
>> - in this example (https://www.mapillary.com/map/im/pNJJG6ST4njXchZDQZ3XPw), 
>> the road exiting the turnaround would be tagged 
>> destination="Épinal;Bruyères;Remiremont;Quartiers sud;Zones industrielles" 
>> and 
>> destination:conditional="(Saint-Dié;Raon-l’Étape;Épinal;Bruyères;Remiremont;Quartiers
>>  sud;Zones industrielles) @ weight>3.5 AND hgv"
>> - in this example (https://www.mapillary.com/map/im/71zRlujmD69aPg35BFO1r6), 
>> the road exiting the turnaround would be tagged destination="La Voivre", 
>> destination:bicycle="La Voivre;Sᵗ Dié" and destination:ref="C 3"
>>
>> Is that correct? Can I edit the Wiki destination tag page to give these 
>> informations, or maybe should I submit a RFC to formalize this?
>>
>> Awaiting your answers,
>>
>> Regards.
>> --
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ___
>> 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] addr:street for routes

[Jmapb]

On 8/1/2020 12:51 AM, Joseph Eisenberg wrote:


Similarly, if you ask someone the name of the road in California with
ref="CA 96",
they will tell you "Highway 96" or perhaps "The river road". They
won't say
"Nah, it doesn't have a name, just a State highway number."


So in that situation, how would you choose what value to use for
`addr:street` on residences and POIs?

J

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

Re: [Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2020, at 15:27, Jan Michel  wrote:
> 
> General terminology point of view:
> As I understand it, the term 'rating' already refers to the allowed limit. 
> Note that it's called 'gross weight rating', but not 'maximum gross weight 
> rating'.


I guess the “gross” part refers to a maximum.
As in “zulässige Gesamtmasse”
which implies empty mass plus maximum mass of payload.

Cheers Martin 



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

[Tagging] maxweightrating [was: Conditional destinations (hgv, bicycle, maxweight…)]

[Jan Michel]

On 01.08.20 15:03, Martin Koppenhoefer wrote:

On 1. Aug 2020, at 11:28, Jan Michel  wrote:
The access tag is 'maxweightrating' like 'maxweight' or 'maxheight'. In the 
value of conditional tags there is no 'max' because there we refer to actual 
values and not limits. We use 'weight', 'height' and hence also 'weightrating' 
there.

the difference is that weight and height are actual weights and heights, while 
the rating is for a maxweight, hence I believe it should be “maxweightrating” 
when it’s about the actual maxweightrating.


Well, this is quite off-topic here, but this interpretation wouldn't be 
consistent. Let me use the term GVWR to refer to the weight rating of a 
vehicle to make it easier to read:


OSM Tagging point of view:
The access tag 'maxweightrating' doesn't refer to a specific GVWR, but 
to all vehicles with a GVWR less than the given number. So, if we use 
the term 'maxweightrating' to refer to the GVWR, the access tag should 
be 'maxmaxweightrating', but can't be 'maxweightrating' because that 
would specify a defined GVWR.


General terminology point of view:
As I understand it, the term 'rating' already refers to the allowed 
limit. Note that it's called 'gross weight rating', but not 'maximum 
gross weight rating'.



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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2020, at 11:28, Jan Michel  wrote:
> 
> The access tag is 'maxweightrating' like 'maxweight' or 'maxheight'. In the 
> value of conditional tags there is no 'max' because there we refer to actual 
> values and not limits. We use 'weight', 'height' and hence also 
> 'weightrating' there.


the difference is that weight and height are actual weights and heights, while 
the rating is for a maxweight, hence I believe it should be “maxweightrating” 
when it’s about the actual maxweightrating.

Cheers Martin 



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

Re: [Tagging] kerb=regular vs. raised - Proposal

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2020, at 12:36, Supaplex  wrote:
> 
> I wrote a proposal for it: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular
> 
> How should I proceed - can I already set the status to "Proposed"? Do I have 
> to write a separate email for RFC or is this thread sufficient?
> 
> I hope for your comments - greets
> Alex
> 


I would see this email to be an RFC, although it could have been better to 
explicitly include the acronym RFC in the subject of your message, as this is 
what the guidelines state. The procedure for proposal is presented here:
https://wiki.openstreetmap.org/wiki/Proposal_process

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

Re: [Tagging] kerb=regular vs. raised - Proposal

[Supaplex]

I wrote a proposal for it:
https://wiki.openstreetmap.org/wiki/Proposed_features/kerb%3Dregular

How should I proceed - can I already set the status to "Proposed"? Do I
have to write a separate email for RFC or is this thread sufficient?

I hope for your comments - greets
Alex


Am 01.08.20 um 09:42 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 1. Aug 2020, at 09:39, Supaplex  wrote:
>>
>> I felt that this list more agreed rather than opposed.
>
> bring it to voting. 
>
>
> 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] Conditional destinations (hgv, bicycle, maxweight…)

[Jan Michel]

On 31.07.20 21:07, Martin Koppenhoefer wrote:

On 31. Jul 2020, at 18:01, Jan Michel  wrote:

I'm not familiar with French rules, but is it the actual weight or the allowed 
total weight of the vehicle that matters? If it's the latter, you can use 
'weightrating' instead of 'weight'.

shouldn’t that be „maxweightrating“?



The access tag is 'maxweightrating' like 'maxweight' or 'maxheight'. In 
the value of conditional tags there is no 'max' because there we refer 
to actual values and not limits. We use 'weight', 'height' and hence 
also 'weightrating' there.



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

Re: [Tagging] Conditional destinations (hgv, bicycle, maxweight…)

[Andrew Harvey]

While you're talking about the destination tag, I think when using a
destination_sign relation it's best to apply the mode as eg.
bicycle=designated, eg
https://www.openstreetmap.org/relation/11345354#map=18/-33.82573/151.21308
 for https://www.mapillary.com/map/im/VIq-OPTiw0BVI7gqdLR-iA

On Fri, 31 Jul 2020 at 23:55, David Marchal via Tagging <
tagging@openstreetmap.org> wrote:

> Hello, there.
>
> I'm wondering, there are destination signs which only apply to some kind
> of vehicles: for HGV, for bicycles, for pedestrians, for vehicles below
> 12t… How would I tag such destinations? The simple way would be to use,
> respectively, destination:hgv=*, destination:bicycle=*, destination:foot=*,
> destination:conditional="* @ weight<12". Am I right to assume these?
>
> If so, some examples:
>
>- in this example (
>https://www.mapillary.com/map/im/mo0AKf9masIEfpJtySH8fw), the road
>ahead would be tagged (regardless of direction),
>destination="Darney;Plombières;Bains-les-B.;Gare S.N.C.F.;Gare" and
>destination:hgv="Vesoul;Mulhouse;Darney;Plombières;Bains-les-B.;Gare
>S.N.C.F.;Gare"
>- in this example (
>https://www.mapillary.com/map/im/Oz3Om7pGbk7LA5wSmYLRew), the link
>would be tagged destination:fee="Milan;Turin;Aoste;Courmayeur;Tunnel du Mᵗ
>Blanc"
>- in this example (
>https://www.mapillary.com/map/im/pNJJG6ST4njXchZDQZ3XPw), the road
>exiting the turnaround would be tagged
>destination="Épinal;Bruyères;Remiremont;Quartiers sud;Zones industrielles"
>and
>
> destination:conditional="(Saint-Dié;Raon-l’Étape;Épinal;Bruyères;Remiremont;Quartiers
>sud;Zones industrielles) @ weight>3.5 AND hgv"
>- in this example (
>https://www.mapillary.com/map/im/71zRlujmD69aPg35BFO1r6), the road
>exiting the turnaround would be tagged destination="La Voivre",
>destination:bicycle="La Voivre;Sᵗ Dié" and destination:ref="C 3"
>
> Is that correct? Can I edit the Wiki destination tag page to give these
> informations, or maybe should I submit a RFC to formalize this?
>
> Awaiting your answers,
>
> Regards.
> --
> Sent with ProtonMail  Secure Email.
>
> ___
> 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] kerb=regular vs. raised

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2020, at 09:39, Supaplex  wrote:
> 
> I felt that this list more agreed rather than opposed.


bring it to voting. 


Cheers Martin 

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

Re: [Tagging] kerb=regular vs. raised

[Supaplex]

There was no change in the OSM database, so the project is not affected.
kerb=regular anyway is already in use but undocumented. Current
wheelchair/mobily projects should anyway consider this existing tagging.
As I described it needs clarity in the differentiation between raised
and regular kerbs and after the discussion here, I felt that this list
more agreed rather than opposed.


Am 01.08.20 um 09:01 schrieb Volker Schmidt:
> Please revert this wiki change.
> The kerb hight values have been used in at least one project documenting
> wheelchair accessibility.
>
> On Sat, 1 Aug 2020, 08:53 Supaplex,  wrote:
>
>> As an result of this diskussion (no strong opposition, some general
>> remarks, some endorsement) I added "kerb=regular" to the tagging example
>> list in the wiki and adjusted hight descriptions (with values discussed
>> here). If there is further need for discussion and changes, it could be
>> carried out in the wiki: https://wiki.openstreetmap.org/wiki/Key:kerb
>>
>> Greets, Alex
>>
>>
>> Am 29.07.20 um 20:56 schrieb Supaplex:
>>
>> Hey all,
>>
>> I started mapping detailed sidewalk information in my area, including
>> crossing and kerb information. It seems that there is a lack of clarity
>> in the differentiation between raised and regular ("normal", neither
>> lowered nor raised) kerbs. "kerb=regular" is already in use but is
>> undocumented and should be explicitly distinguished from "kerb=raised".
>> There is a relevant difference not only for wheelchair users, but also
>> for other mobility groups (cargo bikes, strollers, pedestrians with
>> reduced mobility…).
>>
>> So I propose adding "kerb=regular" to the tagging list in the wiki as
>> well as suitable descriptions for height, use… and an example image. I
>> made a suggestion in the wiki (since there has been no reaction so far I
>> post it 
>> here):https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#kerb.3Dregular_vs._raised_--_add_.22regular.22_example
>>
>> Is there a reason not to add this? Otherwise I’ll do that.
>>
>> Greets, Alex
>>
>>
>>
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] kerb=regular vs. raised

[Martin Koppenhoefer]

sent from a phone

> On 1. Aug 2020, at 09:08, Volker Schmidt  wrote:
> 
> Please revert this wiki change.
> The kerb hight values have been used in at least one project documenting 
> wheelchair accessibility. 


I have reverted the edits now, please create a proposal for edits like this, 
that significantly change established definitions.

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

Re: [Tagging] kerb=regular vs. raised

[Volker Schmidt]

Please revert this wiki change.
The kerb hight values have been used in at least one project documenting
wheelchair accessibility.

On Sat, 1 Aug 2020, 08:53 Supaplex,  wrote:

> As an result of this diskussion (no strong opposition, some general
> remarks, some endorsement) I added "kerb=regular" to the tagging example
> list in the wiki and adjusted hight descriptions (with values discussed
> here). If there is further need for discussion and changes, it could be
> carried out in the wiki: https://wiki.openstreetmap.org/wiki/Key:kerb
>
> Greets, Alex
>
>
> Am 29.07.20 um 20:56 schrieb Supaplex:
>
> Hey all,
>
> I started mapping detailed sidewalk information in my area, including
> crossing and kerb information. It seems that there is a lack of clarity
> in the differentiation between raised and regular ("normal", neither
> lowered nor raised) kerbs. "kerb=regular" is already in use but is
> undocumented and should be explicitly distinguished from "kerb=raised".
> There is a relevant difference not only for wheelchair users, but also
> for other mobility groups (cargo bikes, strollers, pedestrians with
> reduced mobility…).
>
> So I propose adding "kerb=regular" to the tagging list in the wiki as
> well as suitable descriptions for height, use… and an example image. I
> made a suggestion in the wiki (since there has been no reaction so far I
> post it 
> here):https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#kerb.3Dregular_vs._raised_--_add_.22regular.22_example
>
> Is there a reason not to add this? Otherwise I’ll do that.
>
> Greets, Alex
>
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> 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] kerb=regular vs. raised

[Supaplex]

As an result of this diskussion (no strong opposition, some general
remarks, some endorsement) I added "kerb=regular" to the tagging example
list in the wiki and adjusted hight descriptions (with values discussed
here). If there is further need for discussion and changes, it could be
carried out in the wiki: https://wiki.openstreetmap.org/wiki/Key:kerb

Greets, Alex


Am 29.07.20 um 20:56 schrieb Supaplex:
> Hey all,
>
> I started mapping detailed sidewalk information in my area, including
> crossing and kerb information. It seems that there is a lack of clarity
> in the differentiation between raised and regular ("normal", neither
> lowered nor raised) kerbs. "kerb=regular" is already in use but is
> undocumented and should be explicitly distinguished from "kerb=raised".
> There is a relevant difference not only for wheelchair users, but also
> for other mobility groups (cargo bikes, strollers, pedestrians with
> reduced mobility…).
>
> So I propose adding "kerb=regular" to the tagging list in the wiki as
> well as suitable descriptions for height, use… and an example image. I
> made a suggestion in the wiki (since there has been no reaction so far I
> post it here):
> https://wiki.openstreetmap.org/wiki/Talk:Key:kerb#kerb.3Dregular_vs._raised_--_add_.22regular.22_example
>
> Is there a reason not to add this? Otherwise I’ll do that.
>
> Greets, Alex
>
>
>
> ___
> 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

[Paul Norman via Tagging]

On 2020-07-31 8:21 a.m., Andy Townsend wrote:

On 26/05/2020 00:20, Alan Mackie wrote:

Has this edit war stabilised?

Apparently it has been blocking coastline updates across the whole 
world for /months /now.


https://osmdata.openstreetmap.de/data/land-polygons.html
https://github.com/fossgis/osmdata/issues/7


(picking this thread up again because there still hasn't exactly been 
a meeting of minds here)


land polygons have been generated (see 
https://osmdata.openstreetmap.de/data/land-polygons.html ) and 
https://github.com/fossgis/osmdata/issues/7 has been resolved by 
manually "releasing" the coastline.  The current situation in OSM is 
https://overpass-turbo.eu/s/WD8 - at the time of writing this the 
coastline crosses the river north of Buenos Aires.


However, edits are continuing (see 
https://www.openstreetmap.org/changeset/88787419 ).  I'm not convinced 
that moving to one of two extremes, even a small amount at a time, is 
a good idea until there's actually been discussion between the 
proponents of the various positions.


For what it's worth, neither extreme position looks the best answer to 
me - looking at the salinity change between river to ocean at 
https://www.sciencedirect.com/science/article/pii/S0307904X07000716 
(see 
https://www.sciencedirect.com/science/article/pii/S0307904X07000716 
for the key picture) and looking at 
https://de.wikipedia.org/wiki/Datei:Rio_de_la_Plata_BA_2.JPG suggests 
a location some way between the two.  Despite the NASA photo it looks 
like there isn't a "step change" in salinity - and of course values 
will fluctuate based on winds and tides etc




I live near the coast and have done coastline processing, including a 
great deal worldwide during the redaction.


Salinity and territorial control have seldom been considerations in 
where the break between water mapped as waterway=riverbank and 
natural=coastline that I have seen. The break is chosen as a convenient 
place for mappers and a common view of where the coast of the ocean is, 
not based on scientific salinity criteria. For territorial control, look 
at all the inlets along the BC or Norwegian coasts.



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