Re: [Tagging] Watershed or Drainage Basin relation draft proposal

[Martin Koppenhoefer]

do we really have to map this explicitly with relations? Can’t you already see 
them from the waterway and ridge data? IIRR, people have been rendering maps 
for these in the past by just analyzing existing waterway data, no need for 
explicit watersheds.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Coastline for rivers, estuaries and mangroves?

[Joseph Eisenberg]

Re: "Data consumers have a right to being able to interpret the data as the
mapper intended"

For data users, it would be most useful if the coastline is in a consistent
position in relation to the sea and land, clearly.

In the past, it was decided that the coastline would represent the high
tide line, and the first OSM mappers generally put the coastline up at the
tidal limit of rivers (which were easy to verify for them, because there is
usually a dam or weir at that location in England).

But perhaps we need to start adding second line to represent the average
low tide, to define the intertidal zone. Right now the only way to see if
an area is in the intertidal zone is if a natural area has been tagged
outside of the coastline. This works for shoals, beaches and wetlands, but
it's a little ambiguous. If we start mapping the low tide line, this will
clearly show the interidal zone. This outer line could also be defined to
cut across rivers and estuaries at the mouth, similar to how political
baselines are defined (however, it would not be arbitarily defined like the
baseline). The part of the river between the OSM coastline and the "low
tide line" would represent an estuary.

Thinking about the limits of the intertidal zone would make it clear that
the high tide line (=coastline in OSM) should not be a tangent across the
mouth of an estuary. A brackish estuary is a boundary environment between
marine and fresh water, just like the intertidal zone is transitional
between land and sea.

The high tide line or coastline then would define the largest extent of the
marine environment and the minimum extent of land plus inland waters. The
low tide line could, in contrast, show the smallest extent of the marine
environment and the largest possible definition of inland waters.

In this case, I would think it would make sense to start mapping water
areas for estuaries. Even though the water would be outside the coastline
(and therefore already could be rendered with no problems), mapping the
area of estuaries and intertidal waters would clearly define the size of
estuaries and the extent of this zone.

I know that in the past, others have said that defining estuaries would
just create 2 limit problems: you would have to decide where the estuary
turns into river and where it turns into sea, while setting the coastline
is just one decision. But this would be a compromise that lets everyone get
their preferred data, and allows 3 color of lakes / rivers / sea. In fact,
a renderer could choose to render estuaries the same as river, or the same
as sea, or even as a gradient between the two, because they would be
defined. Right now, with varying locations of the coast it's not feasible
to render rivers and sea differently with OSM data, and it's not possible
to measure the size of estuaries directly.

Would these advantages be worth the extra work of tracing a second line
along the coast?

Joseph Eisenberg

On Tue, Sep 11, 2018 at 4:34 PM Colin Smale  wrote:

> On 2018-09-11 08:27, Graeme Fitzpatrick wrote:
>
> We will need to be a little pragmatic, because OSM mappers are never going
> to be able to do a proper survey of the coastline
> I agree, but we also can't easily say where the tidal limit reaches?
>
>
> In most cases the state mapping or hydrography agency will know. They have
> the gear, the knowledge and the mandate to make that determination.
>
> but that is a separate issue to the COASTLINE discussion.
>>
> Maybe, but personally, I still think that the river banks shouldn't be
> marked as coastline, & that the coastline should cut across the river at
> the coast, so I guess we may agree to continue disagreeing :-)
>
>
> I guess so, but what is at stake here is not getting you or me to change
> our minds, but to define what the word means in an OSM context. Mappers may
> also disagree about the definition of "highway" (including or excluding the
> grassy bits?) but IMHO data consumers have a right to being able to
> interpret the data as the mapper intended. If different mappers use a tag
> in differing ways, how is the consumer to know the intention? Having
> differing conventions for each country is just about doable, but if
> individual mappers all have their own definitions, the data becomes less
> valuable. There is much discussion and debate about selected tagging
> topics, but the only thing that really counts is the result, conclusion,
> consensus etc that should come out of it. Unfortunately it rarely does, and
> that saddens me.  OSM is broadening its reach to more and more parts of the
> world, and that is good, but there needs to be equal effort put in to the
> depth of data and the quality (consistency) of the data.
>
> Cheers,
> Colin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.op

Re: [Tagging] Watershed or Drainage Basin relation draft proposal

[Joseph Eisenberg]

"do we really have to map this explicitly with relations? Can’t you already
see them from the waterway and ridge data?"

1) Ridges are missing in many parts of the world, partially because they
are not rendered, but also because it might not be clear how they can be
useful. The presence of watershed relations, mapped along ridges, would
encourage other mappers to add the missing ridges.

2), while a ridge has to have a certain amount of slope to be called a
ridge (perhaps at least 5 or 10% grade?), watershed boundaries are
sometimes very shallow. If you look at the examples I posted, you can see
that the watershed boundaries in the valley are not obvious without looking
at topographical data or surveying in person (I used opentopomap and
survey). Some of the high watershed on plateaus also have the same problem.
But the watershed or basin divide line is verifiable by finding the highest
between basins.

3) Watersheds may already be available as open source data. Ridges must be
drawn with increasing elevation and cannot meet waterways, so it would be
wrongt to import watershed boundary data directly as a serious of ridges.
But with this relation it would be possible to import a watershed as a way
or ways with the role "outer". Hopefully mappers would later add
natural=ridge tags, after breaking up the ways at saddles and peaks so that
they can be drawn in the correct direction (uphill).

4) In my area, aerial imagery over mountain is poor due to cloud cover, but
the SRTM elevation data is pretty good. So I can easily draw the watershed
boundary line by following topography, but it isn't possible to add every
segement of river and stream in the mountains. I believe this would make it
difficult to calculate the correct watershed boundaries

Many segments of waterways are incomplete (especially outside of Europe).
Sometimes this is incomplete data, but it can also be a real feature. For
example, the Wolo River (https://www.openstreetmap.org/relation/8687500)
goes underground in a limestone area and reappears kilometers laters. There
is even a sharp ridge between the two valleys. There are at least 2 or 3
other big rivers in my area that do the same thing. Analyzing the ridges
and waterways alone would miss this.

I started thinking about this after seeing how Imagico used ridges to help
separate waterways and find bad waterway data, and he mentioned that there
are not enough ridges, and they are also sometimes unreliable (
http://blog.imagico.de/river-generalization/). The existence of a watershed
relation would show that someone took the time to check all the ridges.
Also, the most prominent ridgeline is not always the same as the watershed
boundary. When a mapper is making a watershed as a complete boundary, they
will have to complete the gaps, and will be encouraged to find out the
basin divide line even in flattish areas.

Joseph Eisenberg

PS: Any thought about the name of the key and value, and the type of
relation that is best; boundary or not?


On Thu, Sep 13, 2018 at 4:06 PM Martin Koppenhoefer 
wrote:

> do we really have to map this explicitly with relations? Can’t you already
> see them from the waterway and ridge data? IIRR, people have been rendering
> maps for these in the past by just analyzing existing waterway data, no
> need for explicit watersheds.
> ___
> 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] Watershed or Drainage Basin relation draft proposal

[Christoph Hormann]

On Thursday 13 September 2018, Joseph Eisenberg wrote:
> Relations of type=watershed are currently used over 2000 times and
> there is a descriptive Wiki page but no proposal. (
> https://wiki.openstreetmap.org/wiki/Relation:watershed)
>
> It would be useful to have a relation that showed drainage divides
> (aka watersheds) and drainage basins (the network of streams and
> rivers draining into a water body or waterway)

Watershed divides are an abstract non-physical concept that is generally 
not verifiable in practical mapping - there are cases where they are 
(because they evidently coincide with physical features like ridges) 
but there are huge parts of the world where they are not and you would 
only try to estimate them based on already existing data.

In short: This is not something you can reasonably map in OSM.

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

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

Re: [Tagging] Watershed or Drainage Basin relation draft proposal

[Joseph Eisenberg]

Christoph,
So you believe the ridges are verifiable (and the network of waterways, I
assume), but potentially parts of the watershed would not be verifiable
because eg. terrain is too flat? I was thinking that in fairly flat areas
it is still possbile to see which way water flows in drainage channels, and
it's often possible to find the highest line throught he terrain when
surveying. Also, open topographical map sources and open source elevation
data (eg SRTM) would be the main way to determine this. Would it be ok to
map watersheds where they are verifiable?

Would these examples be verifiable?

Wolo river is 99% surrounded by steep ridges; good example?:
https://www.openstreetmap.org/relation/8687500

 see https://www.opentopomap.org/#map=13/-3.7955/138.9242

The Ibele river may be questionable in the flat valley
https://www.openstreetmap.org/relation/8687462

 see https://www.opentopomap.org/#map=12/-4.0620/138.7477

Uwe river is mainly surrounded by steep ridges. For the part in town
verification depends on seeing which way water flows in open drainage
ditches along streets; https://www.openstreetmap.org/relation/8687464

 see https://www.opentopomap.org/#map=11/-4.2105/138.7910

Tagi river is 95 surrounded by ridges:
https://www.openstreetmap.org/relation/8687463 ;

Lake Habema is 98% surrounded by ridges:
https://www.openstreetmap.org/relation/8688506 ;
https://www.opentopomap.org/#map=13/-4.1419/138.6722

I would be happy to include a warning in the proposal and wiki that not
every watershed can be mapped in OSM. Only those in terrain where the
dividing line is obvious and the direction of water drainage is clear. So
no watersheds should be mapped in wetlands, flat farmland, developed urban
areas, etc.

If the issue is the lines through flatter terrain, we could have the
watershed be a non-closed line which only connected ridges. (Personally I
feel there are places where the watershed is obvious, yet don't qualify as
a "ridge", which could also be included as part of the relation). If there
was no requirement to make a closed way from the segments, this would
remove the temptation to draw non-verifiable lines across flat land.

I value your opinion Christoph, because I hoped this relation might
encourage more complete mapping of ridges, watersheds and drainage basins,
thus making it easier to render good maps, eg
http://www.imagico.de/map/water_generalize_en.php

On Thu, Sep 13, 2018 at 6:14 PM Christoph Hormann  wrote:

> On Thursday 13 September 2018, Joseph Eisenberg wrote:
> > Relations of type=watershed are currently used over 2000 times and
> > there is a descriptive Wiki page but no proposal. (
> > https://wiki.openstreetmap.org/wiki/Relation:watershed)
> >
> > It would be useful to have a relation that showed drainage divides
> > (aka watersheds) and drainage basins (the network of streams and
> > rivers draining into a water body or waterway)
>
> Watershed divides are an abstract non-physical concept that is generally
> not verifiable in practical mapping - there are cases where they are
> (because they evidently coincide with physical features like ridges)
> but there are huge parts of the world where they are not and you would
> only try to estimate them based on already existing data.
>
> In short: This is not something you can reasonably map in OSM.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] Watershed or Drainage Basin relation draft proposal

[Joseph Eisenberg]

(Sorry, Lake Habema is https://www.openstreetmap.org/relation/8688509)

On Thu, Sep 13, 2018 at 7:12 PM Joseph Eisenberg 
wrote:

> Christoph,
> So you believe the ridges are verifiable (and the network of waterways, I
> assume), but potentially parts of the watershed would not be verifiable
> because eg. terrain is too flat? I was thinking that in fairly flat areas
> it is still possbile to see which way water flows in drainage channels, and
> it's often possible to find the highest line throught he terrain when
> surveying. Also, open topographical map sources and open source elevation
> data (eg SRTM) would be the main way to determine this. Would it be ok to
> map watersheds where they are verifiable?
>
> Would these examples be verifiable?
>
> Wolo river is 99% surrounded by steep ridges; good example?:
> https://www.openstreetmap.org/relation/8687500
> 
>  see https://www.opentopomap.org/#map=13/-3.7955/138.9242
>
> The Ibele river may be questionable in the flat valley
> https://www.openstreetmap.org/relation/8687462
> 
>  see https://www.opentopomap.org/#map=12/-4.0620/138.7477
>
> Uwe river is mainly surrounded by steep ridges. For the part in town
> verification depends on seeing which way water flows in open drainage
> ditches along streets; https://www.openstreetmap.org/relation/8687464
> 
>  see https://www.opentopomap.org/#map=11/-4.2105/138.7910
>
> Tagi river is 95 surrounded by ridges:
> https://www.openstreetmap.org/relation/8687463 ;
>
> Lake Habema is 98% surrounded by ridges:
> https://www.openstreetmap.org/relation/8688506 ;
> https://www.opentopomap.org/#map=13/-4.1419/138.6722
>
> I would be happy to include a warning in the proposal and wiki that not
> every watershed can be mapped in OSM. Only those in terrain where the
> dividing line is obvious and the direction of water drainage is clear. So
> no watersheds should be mapped in wetlands, flat farmland, developed urban
> areas, etc.
>
> If the issue is the lines through flatter terrain, we could have the
> watershed be a non-closed line which only connected ridges. (Personally I
> feel there are places where the watershed is obvious, yet don't qualify as
> a "ridge", which could also be included as part of the relation). If there
> was no requirement to make a closed way from the segments, this would
> remove the temptation to draw non-verifiable lines across flat land.
>
> I value your opinion Christoph, because I hoped this relation might
> encourage more complete mapping of ridges, watersheds and drainage basins,
> thus making it easier to render good maps, eg
> http://www.imagico.de/map/water_generalize_en.php
>
> On Thu, Sep 13, 2018 at 6:14 PM Christoph Hormann  wrote:
>
>> On Thursday 13 September 2018, Joseph Eisenberg wrote:
>> > Relations of type=watershed are currently used over 2000 times and
>> > there is a descriptive Wiki page but no proposal. (
>> > https://wiki.openstreetmap.org/wiki/Relation:watershed)
>> >
>> > It would be useful to have a relation that showed drainage divides
>> > (aka watersheds) and drainage basins (the network of streams and
>> > rivers draining into a water body or waterway)
>>
>> Watershed divides are an abstract non-physical concept that is generally
>> not verifiable in practical mapping - there are cases where they are
>> (because they evidently coincide with physical features like ridges)
>> but there are huge parts of the world where they are not and you would
>> only try to estimate them based on already existing data.
>>
>> In short: This is not something you can reasonably map in OSM.
>>
>> --
>> Christoph Hormann
>> http://www.imagico.de/
>>
>> ___
>> 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] Watershed or Drainage Basin relation draft proposal

[Warin]

I believe some waterways in Australia will flow away from wherever the 
rain happens to fall ...
That is a produce not just of the flatness of the terrain but also to 
the quantity of rain - there can be 5 years of rainfall delivered in a 
single day.


Someone has put in the Australian Great Dividing Range... fortunately it 
does not render as it is very rough data. And there is no motivation to 
fix it .. as it does not render most are unaware of it within OSM.


On 13/09/18 20:12, Joseph Eisenberg wrote:

Christoph,
So you believe the ridges are verifiable (and the network of 
waterways, I assume), but potentially parts of the watershed would not 
be verifiable because eg. terrain is too flat? I was thinking that in 
fairly flat areas it is still possbile to see which way water flows in 
drainage channels, and it's often possible to find the highest line 
throught he terrain when surveying. Also, open topographical map 
sources and open source elevation data (eg SRTM) would be the main way 
to determine this. Would it be ok to map watersheds where they are 
verifiable?


Would these examples be verifiable?

Wolo river is 99% surrounded by steep ridges; good example?: 
https://www.openstreetmap.org/relation/8687500 
 see 
https://www.opentopomap.org/#map=13/-3.7955/138.9242


The Ibele river may be questionable in the flat valley 
https://www.openstreetmap.org/relation/8687462 
 see 
https://www.opentopomap.org/#map=12/-4.0620/138.7477


Uwe river is mainly surrounded by steep ridges. For the part in town 
verification depends on seeing which way water flows in open drainage 
ditches along streets; https://www.openstreetmap.org/relation/8687464 
 see 
https://www.opentopomap.org/#map=11/-4.2105/138.7910


Tagi river is 95 surrounded by ridges: 
https://www.openstreetmap.org/relation/8687463 ;


Lake Habema is 98% surrounded by ridges: 
https://www.openstreetmap.org/relation/8688506 ; 
https://www.opentopomap.org/#map=13/-4.1419/138.6722


I would be happy to include a warning in the proposal and wiki that 
not every watershed can be mapped in OSM. Only those in terrain where 
the dividing line is obvious and the direction of water drainage is 
clear. So no watersheds should be mapped in wetlands, flat farmland, 
developed urban areas, etc.


If the issue is the lines through flatter terrain, we could have the 
watershed be a non-closed line which only connected ridges. 
(Personally I feel there are places where the watershed is obvious, 
yet don't qualify as a "ridge", which could also be included as part 
of the relation). If there was no requirement to make a closed way 
from the segments, this would remove the temptation to draw 
non-verifiable lines across flat land.


I value your opinion Christoph, because I hoped this relation might 
encourage more complete mapping of ridges, watersheds and drainage 
basins, thus making it easier to render good maps, eg 
http://www.imagico.de/map/water_generalize_en.php


I note the expatiation the a river will not stop in the middle of nowhere.
In fact this does occur, a river can disappear into the sand!
And some lakes have no outflow.



On Thu, Sep 13, 2018 at 6:14 PM Christoph Hormann > wrote:


On Thursday 13 September 2018, Joseph Eisenberg wrote:
> Relations of type=watershed are currently used over 2000 times and
> there is a descriptive Wiki page but no proposal. (
> https://wiki.openstreetmap.org/wiki/Relation:watershed)
>
> It would be useful to have a relation that showed drainage divides
> (aka watersheds) and drainage basins (the network of streams and
> rivers draining into a water body or waterway)

Watershed divides are an abstract non-physical concept that is
generally
not verifiable in practical mapping - there are cases where they are
(because they evidently coincide with physical features like ridges)
but there are huge parts of the world where they are not and you
would
only try to estimate them based on already existing data.

In short: This is not something you can reasonably map in OSM.

-- 
Christoph Hormann

http://www.imagico.de/



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

Re: [Tagging] Watershed or Drainage Basin relation draft proposal

[Joseph Eisenberg]

"In fact this does occur, a river can disappear into the sand!
And some lakes have no outflow."
Right, these are called an "endorheic basin"; an area where the water flow
does not reach the ocean: https://en.wikipedia.org/wiki/Endorheic_basin
In one of my examples above, the river disappears into limestone sinkholes
but then reappears later. This is one of the reasons that it can be
difficult to automatically calculate stream networks and watersheds, if
there are no waterway relations. The presence of endorheic basins and
vanishing streams in deserts and limestone areas is one of the reasons I
believe a watershed or drainage basin relation would be useful.

On Thu, Sep 13, 2018 at 7:55 PM Warin <61sundow...@gmail.com> wrote:

> I believe some waterways in Australia will flow away from wherever the
> rain happens to fall ...
> That is a produce not just of the flatness of the terrain but also to the
> quantity of rain - there can be 5 years of rainfall delivered in a single
> day.
>
> Someone has put in the Australian Great Dividing Range... fortunately it
> does not render as it is very rough data. And there is no motivation to fix
> it .. as it does not render most are unaware of it within OSM.
>
> On 13/09/18 20:12, Joseph Eisenberg wrote:
>
> Christoph,
> So you believe the ridges are verifiable (and the network of waterways, I
> assume), but potentially parts of the watershed would not be verifiable
> because eg. terrain is too flat? I was thinking that in fairly flat areas
> it is still possbile to see which way water flows in drainage channels, and
> it's often possible to find the highest line throught he terrain when
> surveying. Also, open topographical map sources and open source elevation
> data (eg SRTM) would be the main way to determine this. Would it be ok to
> map watersheds where they are verifiable?
>
> Would these examples be verifiable?
>
> Wolo river is 99% surrounded by steep ridges; good example?:
> https://www.openstreetmap.org/relation/8687500
> 
>  see https://www.opentopomap.org/#map=13/-3.7955/138.9242
>
> The Ibele river may be questionable in the flat valley
> https://www.openstreetmap.org/relation/8687462
> 
>  see https://www.opentopomap.org/#map=12/-4.0620/138.7477
>
> Uwe river is mainly surrounded by steep ridges. For the part in town
> verification depends on seeing which way water flows in open drainage
> ditches along streets; https://www.openstreetmap.org/relation/8687464
> 
>  see https://www.opentopomap.org/#map=11/-4.2105/138.7910
>
> Tagi river is 95 surrounded by ridges:
> https://www.openstreetmap.org/relation/8687463 ;
>
> Lake Habema is 98% surrounded by ridges:
> https://www.openstreetmap.org/relation/8688506 ;
> https://www.opentopomap.org/#map=13/-4.1419/138.6722
>
> I would be happy to include a warning in the proposal and wiki that not
> every watershed can be mapped in OSM. Only those in terrain where the
> dividing line is obvious and the direction of water drainage is clear. So
> no watersheds should be mapped in wetlands, flat farmland, developed urban
> areas, etc.
>
> If the issue is the lines through flatter terrain, we could have the
> watershed be a non-closed line which only connected ridges. (Personally I
> feel there are places where the watershed is obvious, yet don't qualify as
> a "ridge", which could also be included as part of the relation). If there
> was no requirement to make a closed way from the segments, this would
> remove the temptation to draw non-verifiable lines across flat land.
>
> I value your opinion Christoph, because I hoped this relation might
> encourage more complete mapping of ridges, watersheds and drainage basins,
> thus making it easier to render good maps, eg
> http://www.imagico.de/map/water_generalize_en.php
>
>
> I note the expatiation the a river will not stop in the middle of nowhere.
> In fact this does occur, a river can disappear into the sand!
> And some lakes have no outflow.
>
>
> On Thu, Sep 13, 2018 at 6:14 PM Christoph Hormann  wrote:
>
>> On Thursday 13 September 2018, Joseph Eisenberg wrote:
>> > Relations of type=watershed are currently used over 2000 times and
>> > there is a descriptive Wiki page but no proposal. (
>> > https://wiki.openstreetmap.org/wiki/Relation:watershed)
>> >
>> > It would be useful to have a relation that showed drainage divides
>> > (aka watersheds) and drainage basins (the network of streams and
>> > rivers draining into a water body or waterway)
>>
>> Watershed divides are an abstract non-physical concept that is generally
>> not verifiable in practical mapping - there are cases where they are
>> (because they evidently coincide with physical features like ridges)
>> but there are huge parts of the world where they are not and you would
>> only try to estimat

Re: [Tagging] Watershed or Drainage Basin relation draft proposal

[Christoph Hormann]

On Thursday 13 September 2018, Joseph Eisenberg wrote:
> Christoph,
> So you believe the ridges are verifiable (and the network of
> waterways, I assume), but potentially parts of the watershed would
> not be verifiable because eg. terrain is too flat? 

There are many reasons why a the watershed structure can be practically 
non-verifiable on the ground.  Relatively flat topography is only one 
of them.  I would estimate that at least about 40 percent of the Earth 
land surfaces have a drainage structure that is practically 
non-verifiable (in the sense that independent estimates from several 
mappers would not converge to the same geometry).  The percentage would 
be even higher if you want it to be verifiable through remote mapping.

> I was thinking 
> that in fairly flat areas it is still possbile to see which way water
> flows in drainage channels, and it's often possible to find the
> highest line throught he terrain when surveying.

Nothing speaks against mapping physically observable features like 
drainage channels but mapping additional abstract geometries derived 
from them in OSM makes little sense IMO.

Note in flat areas with artificial drainage channels the actual drainage 
structure can be extremely complex.

> Would these examples be verifiable?
>
> [...]

Not having first hand knowledge of these cases means i can't really 
tell.  A waterway is a geometry directly physically observable on the 
ground.  The watershed divide is an abstract geometry OTOH. You see a 
ridge and *assume* that water from one side of the ridge flows into a 
certain drainage system and on the other side it flows into a different 
one.  But you don't observe this.  You might have a simple case where 
this seems obvious but the fundamental problem is still there.  In 
humid climate areas you can make the mapping more reliable by first 
diligently mapping the waterway network in the whole area but then what 
is the point in mapping the watershed divides in addition?

Also note in priciple watersheds form an infinitely deep hierarchy of 
geometries.  To be able to practically map these you would have to 
define a discretization system in this hierarchy which would be an 
arbitrary up-front decision with no basis in the physical world.

> I value your opinion Christoph, because I hoped this relation might
> encourage more complete mapping of ridges, watersheds and drainage
> basins, thus making it easier to render good maps, eg
> http://www.imagico.de/map/water_generalize_en.php

If you want to facilitate better maps w.r.t. hydrography the best way 
would be to put all the time and energy you might put into mapping 
watersheds into mapping the waterway network. Priorities should be:

* correct connectivity
* correct distinction onto artificial and natural
* correct flow direction
* completeness and unifomity in detail of mapping

Where these conditions are fulfilled processing the waterbody data for 
accurate maps is orders of magnitude easier than elsewhere.  Compared 
to that the would-be gain of having watershed geometries available in 
addition would be relatively small.

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

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

Re: [Tagging] Slow vehicle turnouts

[Kevin]

Here in Georgia (USA) I believe we call these types of lanes "passing
lanes".  But that's usually only in reference to the left lane.  You
generally stay to the right except to pass.

https://www.dawsonnews.com/local/gdot-remove-hwy-53-passing-lane/

Kevin

On Wed, Sep 12, 2018 at 6:21 PM, Dave Swarthout 
wrote:

> >You say "turnout".  But physically, is it just an additional lane that
> >appears, and (more or less) one is obligated to move right one lane into
> >it if you're in the way?
>
> Exactly. I explained this several posts ago. It is an additional lane,
> running for perhaps a quarter mile, sometimes longer, that any vehicle
> which is holding back some number of other vehicles is obligated to use so
> that those following vehicles may pass. The reason I used the term
> "turnout" is because the signage erected by the Alaska DOT uses that term,
> as in, "Slow Vehicle Turnout Ahead 1500 feet".
>
> I see polyglot is ready to add some sort of processing to JOSM's
> PT_Assistant plugin if only we can decide what to call such lanes in OSM. I
> think the term slow_vehicle would work just fine.
>
> Dave
>
> On Thu, Sep 13, 2018 at 12:11 AM Jo  wrote:
>
>> A few months ago bus_bay=left|right|both was voted. For me this is
>> similar, albeit over a longer distance.
>>
>> extra_lane_for_slow_moving_traffic_to_compulsory_halt_to_
>> let_other_traffic_pass_by=left|right|both ?
>>
>> If you figure out which tag to use, we'll add it to the double split map
>> mode of JOSM's PT_Assistant plugin.
>>
>> Polyglot
>>
>> Op wo 12 sep. 2018 om 18:49 schreef Greg Troxel :
>>
>>>
>>> > Again, I emphasize, this is not a crawler lane or a hill climbing
>>> lane. It
>>> > is a lane into which one pulls over to allow faster moving traffic to
>>> pass.
>>> > In fact, Alaskan law demands that any vehicle being followed by 5
>>> vehicles
>>> > must, at the first opportunity, allow those vehicles to pass. I doubt
>>> > anyone has ever been ticketed for this offense but nevertheless, the
>>> law
>>> > exists. Alaskan highways also have hill climbing lanes that are signed
>>> > "keep right except to pass". Those lanes are not the same as this one.
>>>
>>> Sorry, didn't get that this is not climbing lane (my fault).   In New
>>> England, extra lanes that one would associate with "slow vehicle" are
>>> 99% on hills.
>>>
>>> > Perhaps "slow_moving" isn't the best term for this sort of highway
>>> turnout
>>> > but it does the job.
>>>
>>> You say "turnout".  But physically, is it just an additional lane that
>>> appears, and (more or less) one is obligated to move right one lane into
>>> it if you're in the way?
>>>
>>> Do any routers do anything?  An example of how the data would be used,
>>> or how you think it would be used in an ideal future might be
>>> illuminaing.   Perhaps one's car computer could notice from forward
>>> radar that there is obstructing traffic and query osmand and give you a
>>> notification that the road becomes multilane in some distance, so you
>>> can get ready to blink to get the obstructor to move over if they stay
>>> left?   In that case, I wonder about the difference between a change to
>>> two lanes (perhaps because the row is wide enough and the long-term plan
>>> is 2) and a specific place like you describe.
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
> ___
> 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] Watershed or Drainage Basin relation draft proposal

[Martin Koppenhoefer]

sent from a phone

> On 13. Sep 2018, at 10:02, Joseph Eisenberg  
> wrote:
> 
> "do we really have to map this explicitly with relations? Can’t you already 
> see them from the waterway and ridge data?"
> 
> 1) Ridges are missing in many parts of the world, partially because they are 
> not rendered, but also because it might not be clear how they can be useful. 
> The presence of watershed relations, mapped along ridges, would encourage 
> other mappers to add the missing ridges. 


you’ll have to put the ridges to map the watersheds anyway, the catchment basin 
is implicit with the waterways, coastlines and ridges. 

If there are names or other properties for the watersheds and catchment basins 
in play, it could make sense to have dedicated objects nonetheless, I agree.



> 
> 2), while a ridge has to have a certain amount of slope to be called a ridge 
> (perhaps at least 5 or 10% grade?), watershed boundaries are sometimes very 
> shallow


how can we observe those sheds in shallow areas? Can it be done on the ground 
or does it require additional elevation data? Maybe in the context of shallow 
land the sheds aren’t stable?


WRT imports, if license is suitable and resolution satisfactory I would not 
generally oppose the idea of an import.


Cheers,
Martin 


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

Re: [Tagging] Slow vehicle turnouts

[Tod Fitch]

In California the narrow mountain roads will have “turn outs”. These are very 
short, basically just enough room for a vehicle to pull over and stop to allow 
others to pass. These are signed in advance with something like “Turn out 500 
ft ahead”.

There are also “passing lane” signs for areas where an extra lane extends long 
enough for slow vehicles to maintain their speed in the new right lane. These 
are generally signed longer in advance, e.g. “passing lane 1 mi”.

And on long grades like on the “grapevine” on I-5 between Bakersfield there are 
slow vehicle lanes marked off with a solid white line that extend for the full 
length of both up and down grades that are too steep for a loaded HGV to handle 
at the normal flat land speed limit. All the ones I can think of have reduced 
HGV speed limits.

Reading through this discussion I have the feeling that some areas have one or 
another of these features but not all three and are somehow assuming that what 
they are familiar with covers all the cases. For myself, I add slow vehicle 
lanes and passing lanes to the roadway along with any other tagging 
(maxspeed:hgv, change:lanes, etc.) And for turn outs, I either ignore them or 
put a node. Problem with a node is that the turn out is for one direction of 
travel and nodes are not good for that.

Cheers,
Tod

> On Sep 13, 2018, at 7:00 AM, Kevin  wrote:
> 
> Here in Georgia (USA) I believe we call these types of lanes "passing lanes". 
>  But that's usually only in reference to the left lane.  You generally stay 
> to the right except to pass.
> 
> https://www.dawsonnews.com/local/gdot-remove-hwy-53-passing-lane/ 
> 
> 
> Kevin
> 
> On Wed, Sep 12, 2018 at 6:21 PM, Dave Swarthout  > wrote:
> >You say "turnout".  But physically, is it just an additional lane that
> >appears, and (more or less) one is obligated to move right one lane into
> >it if you're in the way?
> 
> Exactly. I explained this several posts ago. It is an additional lane, 
> running for perhaps a quarter mile, sometimes longer, that any vehicle which 
> is holding back some number of other vehicles is obligated to use so that 
> those following vehicles may pass. The reason I used the term "turnout" is 
> because the signage erected by the Alaska DOT uses that term, as in, "Slow 
> Vehicle Turnout Ahead 1500 feet".
> 
> I see polyglot is ready to add some sort of processing to JOSM's PT_Assistant 
> plugin if only we can decide what to call such lanes in OSM. I think the term 
> slow_vehicle would work just fine.
> 
> Dave
> 
> On Thu, Sep 13, 2018 at 12:11 AM Jo  > wrote:
> A few months ago bus_bay=left|right|both was voted. For me this is similar, 
> albeit over a longer distance.
> 
> extra_lane_for_slow_moving_traffic_to_compulsory_halt_to_let_other_traffic_pass_by=left|right|both
>  ?
> 
> If you figure out which tag to use, we'll add it to the double split map mode 
> of JOSM's PT_Assistant plugin.
> 
> Polyglot
> 
> Op wo 12 sep. 2018 om 18:49 schreef Greg Troxel  >:
> 
> > Again, I emphasize, this is not a crawler lane or a hill climbing lane. It
> > is a lane into which one pulls over to allow faster moving traffic to pass.
> > In fact, Alaskan law demands that any vehicle being followed by 5 vehicles
> > must, at the first opportunity, allow those vehicles to pass. I doubt
> > anyone has ever been ticketed for this offense but nevertheless, the law
> > exists. Alaskan highways also have hill climbing lanes that are signed
> > "keep right except to pass". Those lanes are not the same as this one.
> 
> Sorry, didn't get that this is not climbing lane (my fault).   In New
> England, extra lanes that one would associate with "slow vehicle" are
> 99% on hills.
> 
> > Perhaps "slow_moving" isn't the best term for this sort of highway turnout
> > but it does the job.
> 
> You say "turnout".  But physically, is it just an additional lane that
> appears, and (more or less) one is obligated to move right one lane into
> it if you're in the way?
> 
> Do any routers do anything?  An example of how the data would be used,
> or how you think it would be used in an ideal future might be
> illuminaing.   Perhaps one's car computer could notice from forward
> radar that there is obstructing traffic and query osmand and give you a
> notification that the road becomes multilane in some distance, so you
> can get ready to blink to get the obstructor to move over if they stay
> left?   In that case, I wonder about the difference between a change to
> two lanes (perhaps because the row is wide enough and the long-term plan
> is 2) and a specific place like you describe.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 

Re: [Tagging] Slow vehicle turnouts

[Dave Swarthout]

Tod writes:
>In California the narrow mountain roads will have “turn outs”. These are
very short, basically just enough room for a >vehicle to pull over and stop
to allow others to pass. These are signed in advance with something like
“Turn out 500 ft >ahead”.

These are tagged in OSM, according to the Wiki, as highway=passing_place
and the use of the tag is restricted to nodes. The restriction is probably
because those places are so short and nodes, except for the problem of
directionality, as you and others point out, do the job well enough. But
that tag won't work in my case because these are actual separate lanes with
a significant length. Clearly, some sort of definitive tagging for ways is
needed.

Consequently, I've been ignoring turnouts in my own work although I've
always felt they should be mapped. I wanted to get things right before
settling on a scenario, writing a short JOSM preset to increase efficiency,
and then proceeding to tag them.

On Thu, Sep 13, 2018 at 9:15 PM Tod Fitch  wrote:

> In California the narrow mountain roads will have “turn outs”. These are
> very short, basically just enough room for a vehicle to pull over and stop
> to allow others to pass. These are signed in advance with something like
> “Turn out 500 ft ahead”.
>
> There are also “passing lane” signs for areas where an extra lane extends
> long enough for slow vehicles to maintain their speed in the new right
> lane. These are generally signed longer in advance, e.g. “passing lane 1
> mi”.
>
> And on long grades like on the “grapevine” on I-5 between Bakersfield
> there are slow vehicle lanes marked off with a solid white line that extend
> for the full length of both up and down grades that are too steep for a
> loaded HGV to handle at the normal flat land speed limit. All the ones I
> can think of have reduced HGV speed limits.
>
> Reading through this discussion I have the feeling that some areas have
> one or another of these features but not all three and are somehow assuming
> that what they are familiar with covers all the cases. For myself, I add
> slow vehicle lanes and passing lanes to the roadway along with any other
> tagging (maxspeed:hgv, change:lanes, etc.) And for turn outs, I either
> ignore them or put a node. Problem with a node is that the turn out is for
> one direction of travel and nodes are not good for that.
>
> Cheers,
> Tod
>
> On Sep 13, 2018, at 7:00 AM, Kevin  wrote:
>
> Here in Georgia (USA) I believe we call these types of lanes "passing
> lanes".  But that's usually only in reference to the left lane.  You
> generally stay to the right except to pass.
>
> https://www.dawsonnews.com/local/gdot-remove-hwy-53-passing-lane/
>
> Kevin
>
> On Wed, Sep 12, 2018 at 6:21 PM, Dave Swarthout 
> wrote:
>
>> >You say "turnout".  But physically, is it just an additional lane that
>> >appears, and (more or less) one is obligated to move right one lane into
>> >it if you're in the way?
>>
>> Exactly. I explained this several posts ago. It is an additional lane,
>> running for perhaps a quarter mile, sometimes longer, that any vehicle
>> which is holding back some number of other vehicles is obligated to use so
>> that those following vehicles may pass. The reason I used the term
>> "turnout" is because the signage erected by the Alaska DOT uses that term,
>> as in, "Slow Vehicle Turnout Ahead 1500 feet".
>>
>> I see polyglot is ready to add some sort of processing to JOSM's
>> PT_Assistant plugin if only we can decide what to call such lanes in OSM. I
>> think the term slow_vehicle would work just fine.
>>
>> Dave
>>
>> On Thu, Sep 13, 2018 at 12:11 AM Jo  wrote:
>>
>>> A few months ago bus_bay=left|right|both was voted. For me this is
>>> similar, albeit over a longer distance.
>>>
>>> extra_lane_for_slow_moving_traffic_to_compulsory_halt_to_let_other_traffic_pass_by=left|right|both
>>> ?
>>>
>>> If you figure out which tag to use, we'll add it to the double split map
>>> mode of JOSM's PT_Assistant plugin.
>>>
>>> Polyglot
>>>
>>> Op wo 12 sep. 2018 om 18:49 schreef Greg Troxel :
>>>

 > Again, I emphasize, this is not a crawler lane or a hill climbing
 lane. It
 > is a lane into which one pulls over to allow faster moving traffic to
 pass.
 > In fact, Alaskan law demands that any vehicle being followed by 5
 vehicles
 > must, at the first opportunity, allow those vehicles to pass. I doubt
 > anyone has ever been ticketed for this offense but nevertheless, the
 law
 > exists. Alaskan highways also have hill climbing lanes that are signed
 > "keep right except to pass". Those lanes are not the same as this one.

 Sorry, didn't get that this is not climbing lane (my fault).   In New
 England, extra lanes that one would associate with "slow vehicle" are
 99% on hills.

 > Perhaps "slow_moving" isn't the best term for this sort of highway
 turnout
 > but it does the job.

 You say "turnout".  But physically, is it j

Re: [Tagging] Slow vehicle turnouts

[Jo]

I have been ignoring bus bays for several years and I'm happy we now have a
way to tag them. These extra lanes are very similar, so I'd say that is the
way to go for mapping them. No need for a preset, you'll find that the
double split map mode in PT_Assistant is a lot more practical to split a
way in 2 places at once.

British English seems to use passing place. So what about?

passing_place=right / left / both

Where both is unlikely, of course.

Polyglot

Op do 13 sep. 2018 om 16:46 schreef Dave Swarthout :

> Tod writes:
> >In California the narrow mountain roads will have “turn outs”. These are
> very short, basically just enough room for a >vehicle to pull over and stop
> to allow others to pass. These are signed in advance with something like
> “Turn out 500 ft >ahead”.
>
> These are tagged in OSM, according to the Wiki, as highway=passing_place
> and the use of the tag is restricted to nodes. The restriction is probably
> because those places are so short and nodes, except for the problem of
> directionality, as you and others point out, do the job well enough. But
> that tag won't work in my case because these are actual separate lanes with
> a significant length. Clearly, some sort of definitive tagging for ways is
> needed.
>
> Consequently, I've been ignoring turnouts in my own work although I've
> always felt they should be mapped. I wanted to get things right before
> settling on a scenario, writing a short JOSM preset to increase efficiency,
> and then proceeding to tag them.
>
> On Thu, Sep 13, 2018 at 9:15 PM Tod Fitch  wrote:
>
>> In California the narrow mountain roads will have “turn outs”. These are
>> very short, basically just enough room for a vehicle to pull over and stop
>> to allow others to pass. These are signed in advance with something like
>> “Turn out 500 ft ahead”.
>>
>> There are also “passing lane” signs for areas where an extra lane extends
>> long enough for slow vehicles to maintain their speed in the new right
>> lane. These are generally signed longer in advance, e.g. “passing lane 1
>> mi”.
>>
>> And on long grades like on the “grapevine” on I-5 between Bakersfield
>> there are slow vehicle lanes marked off with a solid white line that extend
>> for the full length of both up and down grades that are too steep for a
>> loaded HGV to handle at the normal flat land speed limit. All the ones I
>> can think of have reduced HGV speed limits.
>>
>> Reading through this discussion I have the feeling that some areas have
>> one or another of these features but not all three and are somehow assuming
>> that what they are familiar with covers all the cases. For myself, I add
>> slow vehicle lanes and passing lanes to the roadway along with any other
>> tagging (maxspeed:hgv, change:lanes, etc.) And for turn outs, I either
>> ignore them or put a node. Problem with a node is that the turn out is for
>> one direction of travel and nodes are not good for that.
>>
>> Cheers,
>> Tod
>>
>> On Sep 13, 2018, at 7:00 AM, Kevin  wrote:
>>
>> Here in Georgia (USA) I believe we call these types of lanes "passing
>> lanes".  But that's usually only in reference to the left lane.  You
>> generally stay to the right except to pass.
>>
>> https://www.dawsonnews.com/local/gdot-remove-hwy-53-passing-lane/
>>
>> Kevin
>>
>> On Wed, Sep 12, 2018 at 6:21 PM, Dave Swarthout 
>> wrote:
>>
>>> >You say "turnout".  But physically, is it just an additional lane that
>>> >appears, and (more or less) one is obligated to move right one lane into
>>> >it if you're in the way?
>>>
>>> Exactly. I explained this several posts ago. It is an additional lane,
>>> running for perhaps a quarter mile, sometimes longer, that any vehicle
>>> which is holding back some number of other vehicles is obligated to use so
>>> that those following vehicles may pass. The reason I used the term
>>> "turnout" is because the signage erected by the Alaska DOT uses that term,
>>> as in, "Slow Vehicle Turnout Ahead 1500 feet".
>>>
>>> I see polyglot is ready to add some sort of processing to JOSM's
>>> PT_Assistant plugin if only we can decide what to call such lanes in OSM. I
>>> think the term slow_vehicle would work just fine.
>>>
>>> Dave
>>>
>>> On Thu, Sep 13, 2018 at 12:11 AM Jo  wrote:
>>>
 A few months ago bus_bay=left|right|both was voted. For me this is
 similar, albeit over a longer distance.

 extra_lane_for_slow_moving_traffic_to_compulsory_halt_to_let_other_traffic_pass_by=left|right|both
 ?

 If you figure out which tag to use, we'll add it to the double split
 map mode of JOSM's PT_Assistant plugin.

 Polyglot

 Op wo 12 sep. 2018 om 18:49 schreef Greg Troxel :

>
> > Again, I emphasize, this is not a crawler lane or a hill climbing
> lane. It
> > is a lane into which one pulls over to allow faster moving traffic
> to pass.
> > In fact, Alaskan law demands that any vehicle being followed by 5
> vehicles
> > must, at the first oppo

Re: [Tagging] Coastline for rivers, estuaries and mangroves?

[Kevin Kenny]

[Off list, I've had my say on list]

> In the past, it was decided that the coastline would represent the high
tide line, and the first OSM mappers generally put the coastline up at the
tidal limit of rivers (which were easy to verify for them, because there is
usually a dam or weir at that location in England).

That's entirely sensible for Great Britain.

And it matches my local situation, except for where the coastline is drawn
- and for the immense scale of the difference.  The Hudson River (and the
problem repeats itself for rivers such as the Delaware and Susquehanna) has
an extremely long estuary. It's really unclear that the English rule makes
sense for it. That's why I've been arguing for leaving room for a modicum
of judgment on the part of the local mappers.

The Hudson is definitely estuarine, with tidal ranges up to a couple of
metres, for its entire lower reach.  The traditional 'mouth' of the river
is an east-west line from the Battery, the southern tip of Manhattan
Island, and this is labeled as 'mile zero' by the boatmen. The river
continues to be tidal, flowing about six hours onshore and six hours
offshore, all through its lower reach. Even in a dry summer, it's virtually
never 'salt' (defined as 100 mg chloride per litre) in surface water beyond
mile 60 (kilometre 97), although denser salt water persists at depth
farther up. The salt front has not, in living memory, retreated past mile
75 (kilometre 121) - above there, it can be thought of as being perennially
fresh water, although continuing to reverse direction above that point.

As I said, the flow is about equally divided in terms of time, but the flow
rates on ebb and flow vary widely - the river water, after all, does
eventually reach the sea. By Haverstraw (about 60 km from the river mouth)
the ebb runs about twice as fast as the flow, and that's as far upstream as
tidal currents present a navigational hazard. (Canoeists and kayakers had
better be aware of the direction of the tide, since few can make progress
upstream paddling against a Hudson River ebb!)

The river remains navigable by moderately-deep-draught vessels all the way
to Albany. A Super-Panamax or larger ship cannot use Albany as a port of
call, but the Port of Albany does see a fair amount of oceangoing traffic.
It can accommodate a ship 289 metres in length, 33.5 metres in width, and
9.5 metres in draught. Its fixed cranes can lift 225 tonnes, and 1000-tonne
barge-mounted cranes are available. Still, it's unquestionably a riverport
- the draught of a ship has to be de-rated for the fresh water, and it's a
long sail up to there. It's chiefly used for bulk cargo from upstate New
York and neighbouring Canada, and for project cargoes such as heavy
electrical equipment from GE Energy in Schenectady.

Most of the lower reach of the Hudson has very little tidal change to its
spatial extent. It's in a narrow valley between two highlands, and both
banks are cliffy.  (The view across the river from Manhattan is quite
spectacular.) The water moves up and down, but has little room to expand
from side to side.


The tidal limit is the 'Federal Dam' (actually a weir by OSM definitions,
since there's a full-width spillway) in Troy, so just as in the UK, we have
a well defined fall line marking the transition from estuary to true river
- at river mile 153 (246 km).  The locals think that extending the
'coastline' upriver nearly 250 km from what is traditionally regarded as
the river mouth is little short of insane. Even if you were to place the
'mouth' of the Severn somewhere near Cardiff, for instance, a comparable
distance up the river would bring you, at the very least, well past
Shrewsbury and perhaps even to the headwaters. Great Britain simply has no
estuaries of nearly that magnitude.

All this leaves me with no clue, in OSM terms, what to call the thing.
Mostly, I don't call it at all. It might answer. :)


On Thu, Sep 13, 2018 at 3:42 AM Joseph Eisenberg 
wrote:

> Re: "Data consumers have a right to being able to interpret the data as
> the mapper intended"
>
> For data users, it would be most useful if the coastline is in a
> consistent position in relation to the sea and land, clearly.
>
> In the past, it was decided that the coastline would represent the high
> tide line, and the first OSM mappers generally put the coastline up at the
> tidal limit of rivers (which were easy to verify for them, because there is
> usually a dam or weir at that location in England).
>
> But perhaps we need to start adding second line to represent the average
> low tide, to define the intertidal zone. Right now the only way to see if
> an area is in the intertidal zone is if a natural area has been tagged
> outside of the coastline. This works for shoals, beaches and wetlands, but
> it's a little ambiguous. If we start mapping the low tide line, this will
> clearly show the interidal zone. This outer line could also be defined to
> cut across rivers and estuaries at the mouth, similar to

Re: [Tagging] Watershed or Drainage Basin relation draft proposal

[Kevin Kenny]

On Thu, Sep 13, 2018 at 10:02 AM Martin Koppenhoefer
 wrote:

> you’ll have to put the ridges to map the watersheds anyway, the catchment 
> basin is implicit with the waterways, coastlines and ridges.
>
> If there are names or other properties for the watersheds and catchment 
> basins in play, it could make sense to have dedicated objects nonetheless, I 
> agree.

> >
> > 2), while a ridge has to have a certain amount of slope to be called a 
> > ridge (perhaps at least 5 or 10% grade?), watershed boundaries are 
> > sometimes very shallow
>
>
> how can we observe those sheds in shallow areas? Can it be done on the ground 
> or does it require additional elevation data? Maybe in the context of shallow 
> land the sheds aren’t stable?

Definitely there are exorrheic wetlands and ponds in which the
watershed line is entirely indefinite. I know of a number of wet areas
that have distributaries into multiple major river basins; e.g., the
Grand Gorge area in the western Catskills drains into both the
Delaware and the Schoharie (and thence via the Mohawk to the Hudson);
the Preston Ponds area of the Adirondacks drains to both the Hudson
and to the Cold River (thence by the Raquette to the St Lawrence), and
so on.

The nearest the US has to an authoritative source is the National
Hydrography Database (NHD) which does have watershed boundaries, with
a hierarchical reference numbering system identifying them and tying
them to the 'reach codes' of the rivers that drain them. ('Reach code'
is a persistent identifier of up to 16 (?) digits, identifying
branches of a river from mouth to headwaters. (I've never investigated
what reach codes do with distributaries - I simply haven't needed to
know.)

There have been projects in the past to import NHD data in bulk.  I
was tempted to do it in my area once - I have the good fortune of
living in a place where the data quality of NHD is pretty good. While
some bulk imports from NHD have been highly successful, I stumbled on
conflation issues and abandoned the idea. I still occasionally
copy-n-paste a stream from NHD into JOSM, but that's always
onesie-twosies, and compared with data that are already in OSM and
with aerials. (Severe storms in the last decade or so have caused some
fairly major watercourses around here to shift, and NHD still hasn't
caught up.)

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

Re: [Tagging] Coastline for rivers, estuaries and mangroves?

[Kevin]

I've worked extensively with the National Wetlands Inventory (NWI) from
the U.S. Fish & Wildlife Service. I think it may be helpful (maybe) to look
at the way they delineate estuarine and marine habitats. Their
classification methods are described in this document...

https://www.fws.gov/wetlands/documents/Classification-of-Wetlands-and-Deepwater-Habitats-of-the-United-States-2013.pdf

the pertinent Estuarine section...

Limits. The Estuarine System extends (1) upstream and landward to where
ocean-derived
salts measure less than 0.5 ppt during the period of average annual low
flow; (2) seaward
to an imaginary line closing the mouth of a river, bay, or sound; and (3)
to the seaward
limit of wetland emergents, shrubs, or trees where they are not included in
(2). The
Estuarine System also includes offshore areas of continuously diluted sea
water.

the pertinent Marine section...

Definition. The Marine System (Figure 2) consists of the open ocean
overlying the
continental shelf and its associated high-energy coastline. Marine habitats
are exposed to
the waves and currents of the open ocean and the Water Regimes are
determined
primarily by the ebb and flow of oceanic tides. Salinities exceed 30 parts
per thousand
(ppt), with little or no dilution except outside the mouths of estuaries.
Shallow coastal
indentations or bays without appreciable freshwater inflow, and coasts with
exposed
rocky islands that provide the mainland with little or no shelter from wind
and waves, are
also considered part of the Marine System because they generally support
typical marine
biota.

Limits. The Marine System extends from the outer edge of the continental
shelf
shoreward to one of three lines: (1) the landward limit of tidal inundation
(extreme high
water of spring tides), including the splash zone from breaking waves; (2)
the seaward
limit of wetland emergents, trees, or shrubs; or (3) the seaward limit of
the Estuarine
System, where this limit is determined by factors other than vegetation.
Deepwater
habitats lying beyond the seaward limit of the Marine System are outside
the scope of the
WCS.

I think the key idea here is "high-energy" vs "low-energy" which would
allow a mapper to identify exposed coasts subject to wave action, etc,
versus a more protected river or bay.



Kevin

On Thu, Sep 13, 2018 at 2:42 PM, Kevin Kenny 
wrote:

> [Off list, I've had my say on list]
>
> > In the past, it was decided that the coastline would represent the high
> tide line, and the first OSM mappers generally put the coastline up at the
> tidal limit of rivers (which were easy to verify for them, because there is
> usually a dam or weir at that location in England).
>
> That's entirely sensible for Great Britain.
>
> And it matches my local situation, except for where the coastline is drawn
> - and for the immense scale of the difference.  The Hudson River (and the
> problem repeats itself for rivers such as the Delaware and Susquehanna) has
> an extremely long estuary. It's really unclear that the English rule makes
> sense for it. That's why I've been arguing for leaving room for a modicum
> of judgment on the part of the local mappers.
>
> The Hudson is definitely estuarine, with tidal ranges up to a couple of
> metres, for its entire lower reach.  The traditional 'mouth' of the river
> is an east-west line from the Battery, the southern tip of Manhattan
> Island, and this is labeled as 'mile zero' by the boatmen. The river
> continues to be tidal, flowing about six hours onshore and six hours
> offshore, all through its lower reach. Even in a dry summer, it's virtually
> never 'salt' (defined as 100 mg chloride per litre) in surface water beyond
> mile 60 (kilometre 97), although denser salt water persists at depth
> farther up. The salt front has not, in living memory, retreated past mile
> 75 (kilometre 121) - above there, it can be thought of as being perennially
> fresh water, although continuing to reverse direction above that point.
>
> As I said, the flow is about equally divided in terms of time, but the
> flow rates on ebb and flow vary widely - the river water, after all, does
> eventually reach the sea. By Haverstraw (about 60 km from the river mouth)
> the ebb runs about twice as fast as the flow, and that's as far upstream as
> tidal currents present a navigational hazard. (Canoeists and kayakers had
> better be aware of the direction of the tide, since few can make progress
> upstream paddling against a Hudson River ebb!)
>
> The river remains navigable by moderately-deep-draught vessels all the way
> to Albany. A Super-Panamax or larger ship cannot use Albany as a port of
> call, but the Port of Albany does see a fair amount of oceangoing traffic.
> It can accommodate a ship 289 metres in length, 33.5 metres in width, and
> 9.5 metres in draught. Its fixed cranes can lift 225 tonnes, and 1000-tonne
> barge-mounted cranes are available. Still, it's unquestionably a riverport
> - the draught of a ship has to be de-rated f

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

[OSMDoudou]

Thx. Two follow-up questions.

(A)

I had a look at a place to which - if I'm not mistaken - you contributed to [1] 
and I see what you mean.

Still, I'm curious why we wouldn't use the "role" attributes of a relation to 
*explicitly* qualify the outer polygon as the "parent" of the parking spaces 
(and the other possible parking-related objects, if any).

As a was searching more, I saw in JOSM that when I click Presets > Relations > 
Site, it opens a dialog box which I think tries to explain that one can add 
nodes, ways or areas with role label, perimeter, entrance or just member (no 
role).

And indeed, when I start writing in the Role column in the relation editor 
dialog in JOSM, it will autocomplete when I start typing perimeter, label or 
entrance.

But I can't find discussion of that in the wiki. [2]

Although when searching even further the wiki, I found an explanation of role 
"perimeter" and "label". [3] [4]

So, it looks like one should tag the amenity=parking member in the relation 
with role perimeter.

What do you think ?

(B)

By the way, back to [1], I see tags from amenity=parking have been duplicated 
to the relation object.

I would have deleted the tags on amenity=parking to avoid double maintenance 
work.

Is that intended ?

[1] https://www.openstreetmap.org/relation/8448251
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/parking#Site_relation
[3] https://wiki.openstreetmap.org/wiki/Proposed_features/Site_Perimeter
[4] https://wiki.openstreetmap.org/wiki/Relations/Proposed/Label


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

Re: [Tagging] Slow vehicle turnouts

[SelfishSeahorse]

Seems you are confusing passing places [1], i.e. a short widening on a
road, with lanes for slow moving vehicles [2,3], which can have a
length of several kilometres.

[1]: 
https://commons.wikimedia.org/wiki/File:Scotland_Kinlochewe_SingleTrackRoad.jpg
[2]: https://www.openstreetmap.org/edit#map=19/43.80368/3.32584
[3]: https://www.mapillary.com/map/im/_XEbuAglW1MY1l6D-jk9rA
On Thu, 13 Sep 2018 at 18:54, Jo  wrote:
>
> I have been ignoring bus bays for several years and I'm happy we now have a 
> way to tag them. These extra lanes are very similar, so I'd say that is the 
> way to go for mapping them. No need for a preset, you'll find that the double 
> split map mode in PT_Assistant is a lot more practical to split a way in 2 
> places at once.
>
> British English seems to use passing place. So what about?
>
> passing_place=right / left / both
>
> Where both is unlikely, of course.
>
> Polyglot
>
> Op do 13 sep. 2018 om 16:46 schreef Dave Swarthout :
>>
>> Tod writes:
>> >In California the narrow mountain roads will have “turn outs”. These are 
>> >very short, basically just enough room for a >vehicle to pull over and stop 
>> >to allow others to pass. These are signed in advance with something like 
>> >“Turn out 500 ft >ahead”.
>>
>> These are tagged in OSM, according to the Wiki, as highway=passing_place and 
>> the use of the tag is restricted to nodes. The restriction is probably 
>> because those places are so short and nodes, except for the problem of 
>> directionality, as you and others point out, do the job well enough. But 
>> that tag won't work in my case because these are actual separate lanes with 
>> a significant length. Clearly, some sort of definitive tagging for ways is 
>> needed.
>>
>> Consequently, I've been ignoring turnouts in my own work although I've 
>> always felt they should be mapped. I wanted to get things right before 
>> settling on a scenario, writing a short JOSM preset to increase efficiency, 
>> and then proceeding to tag them.
>>
>> On Thu, Sep 13, 2018 at 9:15 PM Tod Fitch  wrote:
>>>
>>> In California the narrow mountain roads will have “turn outs”. These are 
>>> very short, basically just enough room for a vehicle to pull over and stop 
>>> to allow others to pass. These are signed in advance with something like 
>>> “Turn out 500 ft ahead”.
>>>
>>> There are also “passing lane” signs for areas where an extra lane extends 
>>> long enough for slow vehicles to maintain their speed in the new right 
>>> lane. These are generally signed longer in advance, e.g. “passing lane 1 
>>> mi”.
>>>
>>> And on long grades like on the “grapevine” on I-5 between Bakersfield there 
>>> are slow vehicle lanes marked off with a solid white line that extend for 
>>> the full length of both up and down grades that are too steep for a loaded 
>>> HGV to handle at the normal flat land speed limit. All the ones I can think 
>>> of have reduced HGV speed limits.
>>>
>>> Reading through this discussion I have the feeling that some areas have one 
>>> or another of these features but not all three and are somehow assuming 
>>> that what they are familiar with covers all the cases. For myself, I add 
>>> slow vehicle lanes and passing lanes to the roadway along with any other 
>>> tagging (maxspeed:hgv, change:lanes, etc.) And for turn outs, I either 
>>> ignore them or put a node. Problem with a node is that the turn out is for 
>>> one direction of travel and nodes are not good for that.
>>>
>>> Cheers,
>>> Tod
>>>
>>> On Sep 13, 2018, at 7:00 AM, Kevin  wrote:
>>>
>>> Here in Georgia (USA) I believe we call these types of lanes "passing 
>>> lanes".  But that's usually only in reference to the left lane.  You 
>>> generally stay to the right except to pass.
>>>
>>> https://www.dawsonnews.com/local/gdot-remove-hwy-53-passing-lane/
>>>
>>> Kevin
>>>
>>> On Wed, Sep 12, 2018 at 6:21 PM, Dave Swarthout  
>>> wrote:

 >You say "turnout".  But physically, is it just an additional lane that
 >appears, and (more or less) one is obligated to move right one lane into
 >it if you're in the way?

 Exactly. I explained this several posts ago. It is an additional lane, 
 running for perhaps a quarter mile, sometimes longer, that any vehicle 
 which is holding back some number of other vehicles is obligated to use so 
 that those following vehicles may pass. The reason I used the term 
 "turnout" is because the signage erected by the Alaska DOT uses that term, 
 as in, "Slow Vehicle Turnout Ahead 1500 feet".

 I see polyglot is ready to add some sort of processing to JOSM's 
 PT_Assistant plugin if only we can decide what to call such lanes in OSM. 
 I think the term slow_vehicle would work just fine.

 Dave

 On Thu, Sep 13, 2018 at 12:11 AM Jo  wrote:
>
> A few months ago bus_bay=left|right|both was voted. For me this is 
> similar, albeit over a longer distance.
>
> extra_lane_for_slow_moving_traffic_to

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

[Martin Koppenhoefer]

sent from a phone

> On 13. Sep 2018, at 22:35, OSMDoudou 
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> 
> What do you think ?


I’m hardly using the site relation because you can express almost everything 
spatially (a (multi-) polygon for the site, everything inside is automatically 
part of the site), unless you want to employ specific roles or want to add 
lines and nodes outside of enclosing polygons. The roles  you mention do not 
make a lot of sense:

perimeter: this is usually implicit in the geometry 

entrance: this is also implicit in the geometry (a node with entrance=main/yes 
in the perimeter)

label: nobody (AFAIK) uses this. A good label position depends on other factors 
(scale, other things labeled, etc.) which have to be determined individually 
for each map and situation, nothing you should map (it is not geodata).


cheers,
Martin 




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

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

[Lionel Giard]

*@OSMDoudou :*
At the moment, i only used the role entrance for the underground parking
site relation with some parking_entrance, because it was suggested by JOSM.
Roles could be used when the situation is complicated (ex : no clear
perimeter exist -> like for underground parking), it may then be useful to
indicate the entrance role (even if it should be implicit from the tag
amenity=parking_entrance...). For the perimeter role, it may be more useful
when multiple polygons are in the site relation (like for historic castle
where you could have the whole site but also the inner court, ...). In case
of parking site relation, the perimeter role is maybe less useful as the
perimeter should always be the polygon with amenity=parking, but i'm not
really taking position on this old debate about implicit vs explicit values.

I often dupplicate the tags from the site relation to the amenity=parking
polygon (or a node/polygon for other site relation like for
historic=castle). And only to get "useful" data for most apps and services
that don't use site relation at all (i think only http://gk.historic.place/ use
site relation for historical features). For parkings, most of the tags are
duplicated by using the common scheme (polygon with amenity=parking) and
the "advanced scheme" (with site relation like in the proposal), all this
because i maintain compatibility with both scheme (which is good and
bad...).And as the site relation are mostly ignored by most tools and maps,
it doesn't matter at the moment. Finally, i find the site relation very
useful to quickly query the whole group of elements member of a site).

*@Martin*, I tried to use multipolygon relation for this before, but it is
not good in some cases. The site relation allow to group elements where a
multipolygon is not correct : like for university buildings dispersed into
a city (ex:
https://www.openstreetmap.org/relation/8148420#map=18/50.66823/4.62058),
where you can't make a multipolygon to group every elements of the
university (they can be nodes too), and using multiple "amenity=university"
is wrong as there is only one university.
It also allow to group elements like you would with relation=stop_area in
the public transport scheme (i.e. grouping every element at the same
location that are part of the same "site"). It is useful to group
historical elements of a castle for exemple (the moat, the walls, the
towers, the bridge, ...) to distinguish the part that are historic to the
ones that are not historic at all. I also use the relation to put the
"heritage" tag applied to the "Site" as a group (when it fits no other
polygon).

And as described in the site relation proposal, we should not use the site
relation, when everything fit into one area (like an area with tag
"amenity=school" or "amenity=university"). The parking site is an exception
in this to me, as the relation allow easier maintenance/selection of so
many polygons linked to the area (when you tag individual parking_space...)
and it allow to have only one scheme for every parking (the ones that are
only on the surface, the one that are underground AND the ones that are
both at the same time (like this one :
https://www.openstreetmap.org/relation/8431818 where i tagged the
underground part only with the parking_entrance nodes).

Le jeu. 13 sept. 2018 à 23:32, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> > On 13. Sep 2018, at 22:35, OSMDoudou <
> 19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
> >
> > What do you think ?
>
>
> I’m hardly using the site relation because you can express almost
> everything spatially (a (multi-) polygon for the site, everything inside is
> automatically part of the site), unless you want to employ specific roles
> or want to add lines and nodes outside of enclosing polygons. The roles
> you mention do not make a lot of sense:
>
> perimeter: this is usually implicit in the geometry
>
> entrance: this is also implicit in the geometry (a node with
> entrance=main/yes in the perimeter)
>
> label: nobody (AFAIK) uses this. A good label position depends on other
> factors (scale, other things labeled, etc.) which have to be determined
> individually for each map and situation, nothing you should map (it is not
> geodata).
>
>
> 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] Mapping language borders, tagging offical languages?

[Joseph Eisenberg]

Currently the primary language of a place can be guessed by looking at the
name=* tags and comparing to name:= or loc_name, if you can
read the local characters and know the language.

For example, by looking at the map in Pakistan, I can tell that they use
Arabic characters to name places and geographical, but I would have to
learn to read these symbols first to know if the language is Arabic or Urdu
or whatever.

It would be useful to tag the primary language of wider communication in a
place, because this information is already implicit in the names of places
but hard to access.

Christoph (@Imagico) has suggested tagging the official language
information on administrative boundary relations:
http://blog.imagico.de/you-name-it-on-representing-geographic-diversity-in-names/

*"In case of Germany the admin_level 2 boundary relation (51477
) would get something
like language_format=$de – and there would be no need for further format
strings locally except maybe for a few smaller areas with a local language
or individual features with only a foreign language name."*

Rather than "language_format" I would suggest "official_language=de" or
"language:official=de" for administrative boundaries. Canada, for example,
would have "language:official=en;fr" on the admin_level=2 boundary for the
whole country, I believe.

Because not all places have officially designated languages, and places can
have multiple official languages, we can also use "language:primary=**" for
the most common language of trade, education, business and communication.
This could be designated on the administrative boundary relation when this
is verifiable; for example in Quebec the primary language is French, while
in most of the provinces of Canada it would be English.

The most complicated issue would be areas where local languages do not
relate to existing boundaries. For example, Indonesia has about 700
languages, and at least 300 are used as the primary, majority language for
communication within particular regions, while the official language
(Indonesian) is used for education, trade and government. In these areas
often places and geographical features will be named in the local language.
This also is the case in areas of Latin America and most of Africa, where
various indigenous languages are the primary language used in many small
regions.

In this case, there are two options.
1) Map the boundaries between areas. His would take work to verify; in each
place a mapper would need to check signs and interview local residents
about the local language. However, there are already sources of global
language boundary data that could be imported into the OSM database if we
want it, eg from Ethnologue. (I work with SIL and I could ask for this, if
we want). It would be questionable where to draw the line in sparsely
inhabited areas, but this problem already happens when selecting the name=*
tag for places in wildernesses; generally the language of the closest
settlement is used.

2) Tag each inhabited place with a language.
This might be considered more verifiable, because languages are a feature
of human geography, which is best represented by place data in OSM. It is
certainly possible for a local mapper to verify the majority language
spoken in their own community and neighboring settlements, and this would
not require drawing a line through uninhabited areas. However, it would be
more work to add tags to each place=hamlet/village/town/neighborhood than
to tag a single boundary line.

[Also see: https://wiki.openstreetmap.org/wiki/Multilingual_names]

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

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

[Marc Gemis]

I do see why a parking is different from a university. If there is 1
polygon in which everything is placed, there is no need for a site
relation.
The argument of 1 scheme is also strange, because you do make a
difference for a university with 1 campus (you are not using a site
relation there) vs. multiple , but not for parkings ?
Furthermore there are plenty of parkings mapped without parking
spaces, just as nodes or areas. Those are mapped without relation
anyway.

I'm in favour of KISS, don't use a relation when it is not really needed.

So +1 on what Martin wrote.

m.
On Fri, Sep 14, 2018 at 1:30 AM Lionel Giard  wrote:
>
> @OSMDoudou :
> At the moment, i only used the role entrance for the underground parking site 
> relation with some parking_entrance, because it was suggested by JOSM.
> Roles could be used when the situation is complicated (ex : no clear 
> perimeter exist -> like for underground parking), it may then be useful to 
> indicate the entrance role (even if it should be implicit from the tag 
> amenity=parking_entrance...). For the perimeter role, it may be more useful 
> when multiple polygons are in the site relation (like for historic castle 
> where you could have the whole site but also the inner court, ...). In case 
> of parking site relation, the perimeter role is maybe less useful as the 
> perimeter should always be the polygon with amenity=parking, but i'm not 
> really taking position on this old debate about implicit vs explicit values.
>
> I often dupplicate the tags from the site relation to the amenity=parking 
> polygon (or a node/polygon for other site relation like for historic=castle). 
> And only to get "useful" data for most apps and services that don't use site 
> relation at all (i think only http://gk.historic.place/ use site relation for 
> historical features). For parkings, most of the tags are duplicated by using 
> the common scheme (polygon with amenity=parking) and the "advanced scheme" 
> (with site relation like in the proposal), all this because i maintain 
> compatibility with both scheme (which is good and bad...).And as the site 
> relation are mostly ignored by most tools and maps, it doesn't matter at the 
> moment. Finally, i find the site relation very useful to quickly query the 
> whole group of elements member of a site).
>
> @Martin, I tried to use multipolygon relation for this before, but it is not 
> good in some cases. The site relation allow to group elements where a 
> multipolygon is not correct : like for university buildings dispersed into a 
> city (ex: 
> https://www.openstreetmap.org/relation/8148420#map=18/50.66823/4.62058), 
> where you can't make a multipolygon to group every elements of the university 
> (they can be nodes too), and using multiple "amenity=university" is wrong as 
> there is only one university.
> It also allow to group elements like you would with relation=stop_area in the 
> public transport scheme (i.e. grouping every element at the same location 
> that are part of the same "site"). It is useful to group historical elements 
> of a castle for exemple (the moat, the walls, the towers, the bridge, ...) to 
> distinguish the part that are historic to the ones that are not historic at 
> all. I also use the relation to put the "heritage" tag applied to the "Site" 
> as a group (when it fits no other polygon).
>
> And as described in the site relation proposal, we should not use the site 
> relation, when everything fit into one area (like an area with tag 
> "amenity=school" or "amenity=university"). The parking site is an exception 
> in this to me, as the relation allow easier maintenance/selection of so many 
> polygons linked to the area (when you tag individual parking_space...) and it 
> allow to have only one scheme for every parking (the ones that are only on 
> the surface, the one that are underground AND the ones that are both at the 
> same time (like this one : https://www.openstreetmap.org/relation/8431818 
> where i tagged the underground part only with the parking_entrance nodes).
>
> Le jeu. 13 sept. 2018 à 23:32, Martin Koppenhoefer  a 
> écrit :
>>
>>
>>
>> sent from a phone
>>
>> > On 13. Sep 2018, at 22:35, OSMDoudou 
>> > <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>> >
>> > What do you think ?
>>
>>
>> I’m hardly using the site relation because you can express almost everything 
>> spatially (a (multi-) polygon for the site, everything inside is 
>> automatically part of the site), unless you want to employ specific roles or 
>> want to add lines and nodes outside of enclosing polygons. The roles  you 
>> mention do not make a lot of sense:
>>
>> perimeter: this is usually implicit in the geometry
>>
>> entrance: this is also implicit in the geometry (a node with 
>> entrance=main/yes in the perimeter)
>>
>> label: nobody (AFAIK) uses this. A good label position depends on other 
>> factors (scale, other things labeled, etc.) which have to be determined 
>> individually for each

Re: [Tagging] Why isn't the amenity=parking object part of the relation ?

[OSMDoudou]

> I’m hardly using the site relation because you can express almost everything 
> spatially (a (multi-) polygon for the site

Can you give a link to such an example ?
 



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

Re: [Tagging] Mapping language borders, tagging offical languages?

[Frederik Ramm]

Hi,

On 14.09.2018 04:43, Joseph Eisenberg wrote:
> It would be useful to tag the primary language of wider communication in
> a place, because this information is already implicit in the names of
> places but hard to access.

See also a longer thread on this list from April:

https://lists.openstreetmap.org/pipermail/tagging/2018-April/035855.html

> The most complicated issue would be areas where local languages do not
> relate to existing boundaries. 

Yes, and I would like to avoid introducing tons of new hardly-verifiable
boundary relations for that. OSM suffers from being unable to define
fuzzy boundaries and they would be necessary here.

Hence

> 2) Tag each inhabited place with a language.

seems a more sensible idea to me.

I would like to caution against westerners "helpfully" defining the
"primary" language for any place other than where they live though, we
have too much accidental cultural imperialism already. Let people all
over the world be agents of their own map, and define what *they* think
the locally used languages are, rather than "help" them understand their
own culture.

As you rightly say,
> It is certainly possible for a local mapper to verify the majority
> language spoken in their own community and neighboring settlements

where "local mapper" is the important term. (Also, let us not
accidentally roll out the concept of *one* "primary" language, which
will only cause the same kinds of conflict as the "one primary name" we
already have - many languages could share the first rank of importance.)

> However, it would be more work to add tags to each
> place=hamlet/village/town/neighborhood than to tag a single boundary line.

I'd go for a mixed approach - tag the (largest useful) administrative
boundary first, and then allow lower level admin boundaries and finally,
place nodes, to override the default. Requires a little more brains to
evaluate but we can really do without another world-wide mass edit where
someone adds an obvious "primary language" tag to every settlement.

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