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

[Colin Smale]

Graeme, 

Baseline is not the same as coastline, so the definition you refer to is
not what we are looking for. 

Coastline is a geographic feature, and is normally based on high water. 

Baseline is a political feature, based on the low water mark, and
simplified around bays, inlets and islands. This is the baseline from
which the 12nm territorial limit is measured, and also the 200nm EEZ and
median lines if applicable. Water on the landward side of the baseline
(e.g. lakes, inlets, estuaries) is referred to as internal waters, i.e.
belonging to the land mass itself for the purposes of maritime law.

On 2018-09-03 23:58, Graeme Fitzpatrick wrote:

> This has recently been discussed on the Australian list, with reference being 
> made to 
> http://www.ga.gov.au/scientific-topics/marine/jurisdiction/maritime-boundary-definitions,
>  which is based on the UN Convention on the Law of the Sea 
> http://www.un.org/Depts/los/convention_agreements/convention_overview_convention.htm.
>  
> 
> For our discussion now: 
> 
> "TERRITORIAL SEA BASELINE
> 
> The term Territorial Sea Baseline (TSB) refers to the line from which the 
> seaward limits of Australia's Maritime Zones are measured. These include the 
> breadth of the territorial sea; the seaward limits of the contiguous zone, 
> the exclusive economic zone and, in some cases, the continental shelf. 
> 
> The territorial sea baseline may be of various types depending upon the shape 
> of the coastline in any given locality: 
> 
> * The Normal baseline corresponds with the low water line along the coast, 
> including the coasts of islands. Under the Convention, normal baseline can be 
> drawn around low tide elevations which are defined as naturally formed areas 
> of land surrounded by and above water at low tide but submerged at high tide, 
> provided they are wholly or partly within 12 nautical miles of the coast. For 
> Australian purposes, normal baseline corresponds to the level of Lowest 
> Astronomical Tide (LAT) [1].
> * Straight baselines are a system of straight lines joining specified or 
> discrete points on the low-water line, usually known as straight baseline end 
> points. These may be used in localities where the coastline is deeply 
> indented and cut into, or where there is a fringe of islands along the coast 
> in its immediate vicinity.
> * Bay or river closing lines are straight lines drawn between the respective 
> low-water marks of the natural entrance points of bays or rivers.
> 
> Waters on the landward side of the baseline are internal waters for the 
> purposes of international law." 
> 
> & NB that they say that the Normal baseline is the low water line! 
> 
> The UN's definitions: 
> 
> Straight baselines 
> 
> 1. In localities where the coastline is deeply indented and cut into, or if 
> there is a fringe of islands along the coast in its immediate vicinity, the 
> method of straight baselines joining appropriate points may be employed in 
> drawing the baseline from which the breadth of the territorial sea is 
> measured. 
> 
> 2. Where because of the presence of a delta and other natural conditions the 
> coastline is highly unstable, the appropriate points may be selected along 
> the furthest seaward extent of the low-water line and, notwithstanding 
> subsequent regression of the low-water line, the straight baselines shall 
> remain effective until changed by the coastal State in accordance with this 
> Convention. 
> 
> 3. The drawing of straight baselines must not depart to any appreciable 
> extent from the general direction of the coast, and the sea areas lying 
> within the lines must be sufficiently closely linked to the land domain to be 
> subject to the regime of internal waters. 
> 
> 4. Straight baselines shall not be drawn to and from low-tide elevations, 
> unless lighthouses or similar installations which are permanently above sea 
> level have been built on them or except in instances where the drawing of 
> baselines to and from such elevations has received general international 
> recognition. 
> 
> 5. Where the method of straight baselines is applicable under paragraph 1, 
> account may be taken, in determining particular baselines, of economic 
> interests peculiar to the region concerned, the reality and the importance of 
> which are clearly evidenced by long usage. 
> 
> 6. The system of straight baselines may not be applied by a State in such a 
> manner as to cut off the territorial sea of another State from the high seas 
> or an exclusive economic zone. 
> 
> Article9 
> 
> Mouths of rivers 
> 
> If a river flows directly into the sea, the baseline shall be a straight line 
> across the mouth of the river between points on the low-water line of its 
> banks.
> 
> So, unless any of us want to argue with the UN, or suggest that they change 
> their definitions to suit OSM! :-), I think that they could be counted as the 
> final word? 
> 
> Thanks 
> 
> Graeme 
> 

Re: [Tagging] Slow vehicle turnouts

[Graeme Fitzpatrick]

On Tue, 4 Sep 2018 at 07:38, Dave Swarthout  wrote:

> @Graeme wrote:
> I see the phrase overtaking lane as more like an extra lane for climbing
> hills, or a lane dedicated to passing, but such lanes are not "separate"
> like the turnouts in my examples.
>

Ahh, yes, of course - the old international definitions again, hey! :-)

You are correct - our "overtaking lanes" are like this:
https://www.google.com/maps/@-28.0015042,153.2212579,3a,75y,152.34h,102.31t/data=!3m6!1e1!3m4!1svJ1u7K8Ak12ihvEzmRVWvQ!2e0!7i13312!8i6656
so obviously a bit different to your's.

Thanks

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

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

[Graeme Fitzpatrick]

This has recently been discussed on the Australian list, with reference
being made to
http://www.ga.gov.au/scientific-topics/marine/jurisdiction/maritime-boundary-definitions,
which is based on the UN Convention on the Law of the Sea
http://www.un.org/Depts/los/convention_agreements/convention_overview_convention.htm
.

For our discussion now:
"Territorial Sea Baseline

The term Territorial Sea Baseline (TSB) refers to the line from which the
seaward limits of Australia's Maritime Zones are measured. These include
the breadth of the territorial sea; the seaward limits of the contiguous
zone, the exclusive economic zone and, in some cases, the continental shelf.

The territorial sea baseline may be of various types depending upon the
shape of the coastline in any given locality:

   - The Normal baseline corresponds with the low water line along the
   coast, including the coasts of islands. Under the Convention, normal
   baseline can be drawn around low tide elevations which are defined as
   naturally formed areas of land surrounded by and above water at low tide
   but submerged at high tide, provided they are wholly or partly within 12
   nautical miles of the coast. For Australian purposes, normal baseline
   corresponds to the level of Lowest Astronomical Tide (LAT)
   

   .
   - Straight baselines are a system of straight lines joining specified or
   discrete points on the low-water line, usually known as straight baseline
   end points. These may be used in localities where the coastline is deeply
   indented and cut into, or where there is a fringe of islands along the
   coast in its immediate vicinity.
   - Bay or river closing lines are straight lines drawn between the
   respective low-water marks of the natural entrance points of bays or rivers.

Waters on the landward side of the baseline are internal waters for the
purposes of international law."

& NB that they say that the Normal baseline is the low water line!


The UN's definitions:

Straight baselines

1. In localities where the coastline is deeply indented and cut into, or if
there is a fringe of islands along the coast in its immediate vicinity, the
method of straight baselines joining appropriate points may be employed in
drawing the baseline from which the breadth of the territorial sea is
measured.

2. Where because of the presence of a delta and other natural conditions
the coastline is highly unstable, the appropriate points may be selected
along the furthest seaward extent of the low-water line and,
notwithstanding subsequent regression of the low-water line, the straight
baselines shall remain effective until changed by the coastal State in
accordance with this Convention.

3. The drawing of straight baselines must not depart to any appreciable
extent from the general direction of the coast, and the sea areas lying
within the lines must be sufficiently closely linked to the land domain to
be subject to the regime of internal waters.

4. Straight baselines shall not be drawn to and from low-tide elevations,
unless lighthouses or similar installations which are permanently above sea
level have been built on them or except in instances where the drawing of
baselines to and from such elevations has received general international
recognition.

5. Where the method of straight baselines is applicable under paragraph 1,
account may be taken, in determining particular baselines, of economic
interests peculiar to the region concerned, the reality and the importance
of which are clearly evidenced by long usage.

6. The system of straight baselines may not be applied by a State in such a
manner as to cut off the territorial sea of another State from the high
seas or an exclusive economic zone.

Article9

Mouths of rivers

If a river flows directly into the sea, the baseline shall be a straight
line across the mouth of the river between points on the low-water line of
its banks.
So, unless any of us want to argue with the UN, or suggest that they change
their definitions to suit OSM! :-), I think that they could be counted as
the final word?

Thanks

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

Re: [Tagging] Tagging suggestions for electricity

[Warin]

On 04/09/18 00:04, Martin Koppenhoefer wrote:





What is your reasoning for rejecting the idea that unused tags (or 
lowest usage stuff) get documented as a proposed thing, rather than an 
established convention?




First you have not put it forward as an idea, but put it forward as a 
compulsion, a dictate.

OSM has never dictated this method as compulsory.

While it is good to encourage the discussion of a tag on the tagging 
list, trying to make a mapper do a proposal page is a discouragement to 
enter into discussions on the tagging list - the last thing 'we' want!


If dictated it could lead to many undocumented tags remaining 
undocumented as it becomes yet more difficult to document a new tag.
There then would have to be 2 wiki pages created. And if the proposal is 
only in draft form there is not compulsion to mention it on the tagging 
list.
If a watch is set on making any new proposal page .. why not set a watch 
on making any new wiki page at all - same effect but less work for the 
person doing the documentation.






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

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

[Colin Smale]

On 2018-09-03 23:08, Christoph Hormann wrote:

> On Monday 03 September 2018, Colin Smale wrote: This is essentially the 
> situation we have right now.  Judgement of
> local mappers is usually fine (with the exception of political
> cases like the Rio de la Plata).  Most problems occur because
> armchair mappers misinterpret the local situation or when
> inexperienced mappers are unaware of the significance of
> distinguishing between ocean and riverbank mapping. 
> What guidance do we give to the local mappers?

What is currently written on the wiki which includes the proposal which 
is linked to from the coastline documentation.

> Given a properly formulated rule-of-thumb, why should remote armchair
> mappers come to a different conclusion to local mappers in this case?

As said this is mostly due to misinterpreting imagery. 

That can account for a few metres either way (perpendicular to the
shoreline), but not for the difference between tidal limit and a
"convenient crossing point near the sea". That is purely a personal
judgement, not misaligning imagery. After all, we are not disputing here
the location of the sides of the river, but where we draw the line from
one side of the river to the other.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Slow vehicle turnouts

[Dave Swarthout]

@Graeme wrote:
 "overtaking_lane" perhaps?

I see the phrase overtaking lane as more like an extra lane for climbing
hills, or a lane dedicated to passing, but such lanes are not "separate"
like the turnouts in my examples. These slow vehicle turnouts are a
short-length "extra" lane on the right side. It's not so much a "passing
lane" as it is a lane where one can be intentionally passed.

Thanks for the feedback.

Dave

On Tue, Sep 4, 2018 at 3:39 AM Graeme Fitzpatrick 
wrote:

>
>
>
> On Mon, 3 Sep 2018 at 20:31, Dave Swarthout 
> wrote:
>
>> Because the turnouts use a separate lane, are very short in length, and
>> are not really thoroughfares in the usual sense, might it be logical to tag
>> them as service roads? As an example:
>> highway=service
>> service=slow_vehicle_turnout (or slow_vehicle_lane)
>> lanes=1
>> oneway=yes
>>
>
> That would certainly work Dave
>
> "overtaking_lane" perhaps?
>
> I know they don't have one posted (at least not out here) but would
> tagging this lane with a max_speed say 10 kph lower than the "main road"
> help?
>
> Thanks
>
> Graeme
> ___
> 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

Re: [Tagging] namespace for shop subtags - genaral format

[Warin]

On 04/09/18 00:24, Thilo Haug wrote:


Forwarding this with a new subject
as otherwise we discuss again "small" things instead of the whole 
principle
(shouldn't just be defined for horse:rental, but one namespace for all 
offered services/goods)


Example :
*:sales=*


No ... not sales .. but sells! *:sells=*


*:parts=*
*:rental=*


*:repair=*



 Weitergeleitete Nachricht 
Betreff:Re: [Tagging] horse rental
Datum:  Mon, 3 Sep 2018 16:18:47 +0200
Von:Thilo Haug OSM 
Antwort an: th...@gmx.de
Organisation:   OSM
An: tagging@openstreetmap.org



Such as in the bicycle shop example ?
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys

This one has been discussed :
https://wiki.openstreetmap.org/wiki/Proposed_features/service:bicycle

And it's totally different to the car version :
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar#Tags_used_in_combination

That's why I think the (namespace) principle / "grammar" should be 
discussed

instead of inventing the wheel from scratch for every shop
(and having endless discussions about differences between slightly 
different shops
instead of letting people express the details with an easy "grammar" / 
"subkeys").


Am 03.09.2018 um 15:49 schrieb Martin Koppenhoefer:



2018-09-03 15:18 GMT+02:00 Thilo Haug OSM >:


The principle should be described in general (not only for rental and
not only for one shop),
as there's currently a mess with different formats (compare car /
bicycle / motorcycle shops).




speaking about "mess"; it is the result of people creating new 
webpages for unexisting features without discussion or notice, so 
that the result is often similar to what you created on the 
skateboarding page: board:type for skateboards where all existing 
values are actually typos for board_type of information boards.


Discussing with other mappers prior to writing new stuff into the 
wiki, using the established procedures (proposal process), searching 
the wiki and taginfo before inventing tags, all this can help to 
avoid the mess.


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] wiki modification landuse=meadow definition

[Warin]

On 04/09/18 01:58, Mateusz Konieczny wrote:

3. Wrzesień 2018 13:16 od pla16...@gmail.com :

In favour of "for a": landuse=forestry (except it ended up being
named landuse=forest).  The land is used FOR
forestry.


You area may be very unusual, in general landuse=forest is used for 
"this area is a forest" or


sometimes "this area is covered by trees".



It appears that it depends on where you are as to what is 'usual'.

Here in general an area of trees is tagged natural=wood. Note that the 
key natural accepts human intervention.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Christoph Hormann]

On Monday 03 September 2018, Colin Smale wrote:
> > This is essentially the situation we have right now.  Judgement of
> > local mappers is usually fine (with the exception of political
> > cases like the Rio de la Plata).  Most problems occur because
> > armchair mappers misinterpret the local situation or when
> > inexperienced mappers are unaware of the significance of
> > distinguishing between ocean and riverbank mapping.
>
> What guidance do we give to the local mappers?

What is currently written on the wiki which includes the proposal which 
is linked to from the coastline documentation.

> Given a properly formulated rule-of-thumb, why should remote armchair
> mappers come to a different conclusion to local mappers in this case?

As said this is mostly due to misinterpreting imagery.

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

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

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

[Colin Smale]

On 2018-09-03 22:20, Christoph Hormann wrote:

>> The estuarine situation will always be hard to deal with, and I think
>> we'll simply need to have rough guidelines and then trust the
>> judgment of the locals.
> 
> This is essentially the situation we have right now.  Judgement of local 
> mappers is usually fine (with the exception of political cases like the 
> Rio de la Plata).  Most problems occur because armchair mappers 
> misinterpret the local situation or when inexperienced mappers are 
> unaware of the significance of distinguishing between ocean and 
> riverbank mapping.

What guidance do we give to the local mappers? Coastline up to tidal
limit, or draw a line across wherever you think fit? Coastline and
riverbank are IMHO not mutually exclusive. 

Given a properly formulated rule-of-thumb, why should remote armchair
mappers come to a different conclusion to local mappers in this case? Or
are you proposing such a wide tolerance that basically anything will
fit, thus avoiding the discussion instead of actually tackling it?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] routes with double use hiking and bicycle

[Graeme Fitzpatrick]

On Mon, 3 Sep 2018 at 18:25, Volker Schmidt  wrote:

>
> I am talking abut route relations and not about ways.
>

Thanks Volker.

Sorry, I obviously misunderstood what you were saying :-(

Thanks

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

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

[Colin Smale]

Just a reminder that we need a pragmatic, practical definition for OSM.
It has to be either verifiable in situ, preferably in a single visit and
without specialist equipment, knowledge or access, or it needs to be
derivable from openly accessible (and suitably licensed) sources. A
discussion whereby a hundred people contribute their subjective opinions
is unlikely to lead to a *durable* solution for OSM. In this case I
would suggest it would be impossible for a mapper to survey their own
coastline position; it is best left to hydrographers and/or
cartographers to provide the algorithm by which one can define the
correct "coastline". Then we find an open source of this data for our
regions. If this source does not exist, we approximate (based on the
chosen algorithm) until such time as open data is available. 

The nicest thing about standards is of course the wide choice
available Which standard do we adopt? Is it not possible that there
are multiple possibilities for the definition of "coastline", and which
one is best for a given use case, can vary according to the wishes of
the party consuming the data? I.e. if we preselect a specific
definition, are we implicitly and unintentionally blocking out other
definitions from representation in OSM, possibly leading to accusations
of "tagging for the renderer," being the single use case which uses the
chosen definition? 

One thing I think does have consensus - the coastline is based on the
High Water Mark (and not Low Water or mid-tide or any other point in the
tidal cycle). This in itself is impossible for a "simple mapper" to
define with any accuracy, so we will have to trust external sources. 

What is unclear, is of course where do we "draw the line", literally and
figuratively, in the case of indented coastlines and river estuaries.
Tidal limit has the advantage of being artificial (dam/weir etc) and
therefore uncontroversial, or at least in most cases readily available,
even if it is just from "common knowledge". So which standard/algorithm
would give the pragmatic, practical definition OSM needs?

On 2018-09-03 21:32, Kevin Kenny wrote:

> It would certainly need to be above Haverstraw - the current there
> http://tbone.biol.sc.edu/tide/tideshow.cgi?site=Haverstraw+%28Hudson+River%29%2C+New+York+Current
> shows significant tidal reversal.  I haven't found a gaging station
> farther upriver that reports tidal currents. Croton Point, where the
> river broadens to form the Tappan Zee, would probably be the lower
> limit. Even that seems unreasonably far upriver.
> 
> The tidal range increases as you move upstream from there. The
> greatest tidal range in the entire river is at Troy. One Native
> American name for the river was "Mahicantuck" which means, more or
> less, "the river flows both ways."
> 
> The estuarine situation will always be hard to deal with, and I think
> we'll simply need to have rough guidelines and then trust the judgment
> of the locals.
> On Mon, Sep 3, 2018 at 2:51 PM Christoph Hormann  wrote: 
> On Monday 03 September 2018, Kevin Kenny wrote: Imagico's proposal is perhaps 
> objective, but surely doesn't match
> perception in my part of the world. It seems odd that the 'coastline'
> must extend upward to https://www.openstreetmap.org/way/90929525 -
> but that is, according to Imagico's definitions, simultaneously the
> lowest and highest permissible limit. [...] 
> Then you have misunderstood the proposal.
> 
> With the Hudson river obviously the tidal case applies so you have the
> lower limit as:
> 
> With significant tides the coastline should go upstream at least to a
> point where on waterflow is going downstream for a significantly longer
> part of the tidal cycle than it goes upstream due to raising tide.
> 
> This is evidently always below the upper limit (range of tidal
> influence).
> 
> I can't say for sure where i would place the lower limit in case of the
> Hudson - The Narrows is quite definitely too low - but the current
> closure seems fine.
> 
> For low volume tidal rivers (i.e. without a salt wedge and no
> significant influence of the water volume on the ocean salinity) it
> would also be possible to define the lower limit through salinity (not
> in absolute terms but as a fraction of the open ocean salinity in the
> area).
> 
> --
> 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___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Slow vehicle turnouts

[Graeme Fitzpatrick]

On Mon, 3 Sep 2018 at 20:31, Dave Swarthout  wrote:

> Because the turnouts use a separate lane, are very short in length, and
> are not really thoroughfares in the usual sense, might it be logical to tag
> them as service roads? As an example:
> highway=service
> service=slow_vehicle_turnout (or slow_vehicle_lane)
> lanes=1
> oneway=yes
>

That would certainly work Dave

"overtaking_lane" perhaps?

I know they don't have one posted (at least not out here) but would tagging
this lane with a max_speed say 10 kph lower than the "main road" help?

Thanks

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

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

[Christoph Hormann]

On Monday 03 September 2018, Kevin Kenny wrote:
> It would certainly need to be above Haverstraw - the current there
> http://tbone.biol.sc.edu/tide/tideshow.cgi?site=Haverstraw+%28Hudson+
>River%29%2C+New+York+Current shows significant tidal reversal.  I
> haven't found a gaging station farther upriver that reports tidal
> currents. Croton Point, where the river broadens to form the Tappan
> Zee, would probably be the lower limit. Even that seems unreasonably
> far upriver.
>
> The tidal range increases as you move upstream from there. The
> greatest tidal range in the entire river is at Troy. One Native
> American name for the river was "Mahicantuck" which means, more or
> less, "the river flows both ways."

I am not familiar with the specific situation but tidal reversal is not 
incompatible with the rule i formulated.

And as said for low volume tidal rivers a relative salinity criterion 
might work better - but this does not work with larger volume rivers 
where this could put the lower limit pretty far out into the ocean.

> The estuarine situation will always be hard to deal with, and I think
> we'll simply need to have rough guidelines and then trust the
> judgment of the locals.

This is essentially the situation we have right now.  Judgement of local 
mappers is usually fine (with the exception of political cases like the 
Rio de la Plata).  Most problems occur because armchair mappers 
misinterpret the local situation or when inexperienced mappers are 
unaware of the significance of distinguishing between ocean and 
riverbank mapping.

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

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

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

[Kevin Kenny]

It would certainly need to be above Haverstraw - the current there
http://tbone.biol.sc.edu/tide/tideshow.cgi?site=Haverstraw+%28Hudson+River%29%2C+New+York+Current
shows significant tidal reversal.  I haven't found a gaging station
farther upriver that reports tidal currents. Croton Point, where the
river broadens to form the Tappan Zee, would probably be the lower
limit. Even that seems unreasonably far upriver.

The tidal range increases as you move upstream from there. The
greatest tidal range in the entire river is at Troy. One Native
American name for the river was "Mahicantuck" which means, more or
less, "the river flows both ways."

The estuarine situation will always be hard to deal with, and I think
we'll simply need to have rough guidelines and then trust the judgment
of the locals.
On Mon, Sep 3, 2018 at 2:51 PM Christoph Hormann  wrote:
>
> On Monday 03 September 2018, Kevin Kenny wrote:
> > Imagico's proposal is perhaps objective, but surely doesn't match
> > perception in my part of the world. It seems odd that the 'coastline'
> > must extend upward to https://www.openstreetmap.org/way/90929525 -
> > but that is, according to Imagico's definitions, simultaneously the
> > lowest and highest permissible limit. [...]
>
> Then you have misunderstood the proposal.
>
> With the Hudson river obviously the tidal case applies so you have the
> lower limit as:
>
> With significant tides the coastline should go upstream at least to a
> point where on waterflow is going downstream for a significantly longer
> part of the tidal cycle than it goes upstream due to raising tide.
>
> This is evidently always below the upper limit (range of tidal
> influence).
>
> I can't say for sure where i would place the lower limit in case of the
> Hudson - The Narrows is quite definitely too low - but the current
> closure seems fine.
>
> For low volume tidal rivers (i.e. without a salt wedge and no
> significant influence of the water volume on the ocean salinity) it
> would also be possible to define the lower limit through salinity (not
> in absolute terms but as a fraction of the open ocean salinity in the
> area).
>
> --
> 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] Coastline for rivers, estuaries and mangroves?

[Malcolm Herring]

On 03/09/2018 19:24, Paul Allen wrote:

I expect somebody has a better definition.


Just to muddy the waters (pun intended!):

In its catalogue of chartable objects for electronic charts, the IHO 
originally defined "coastline", "river bank", "canal bank" and "lake 
shore". However, when it came to the implementation, they abandoned 
these distinctions and mapped everything as "coastline"



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

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

[Christoph Hormann]

On Monday 03 September 2018, Kevin Kenny wrote:
> Imagico's proposal is perhaps objective, but surely doesn't match
> perception in my part of the world. It seems odd that the 'coastline'
> must extend upward to https://www.openstreetmap.org/way/90929525 -
> but that is, according to Imagico's definitions, simultaneously the
> lowest and highest permissible limit. [...]

Then you have misunderstood the proposal.

With the Hudson river obviously the tidal case applies so you have the 
lower limit as:

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

This is evidently always below the upper limit (range of tidal 
influence).

I can't say for sure where i would place the lower limit in case of the 
Hudson - The Narrows is quite definitely too low - but the current 
closure seems fine.

For low volume tidal rivers (i.e. without a salt wedge and no 
significant influence of the water volume on the ocean salinity) it 
would also be possible to define the lower limit through salinity (not 
in absolute terms but as a fraction of the open ocean salinity in the 
area).

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

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

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

[Paul Allen]

On Mon, Sep 3, 2018 at 7:08 PM, Kevin Kenny  wrote:

 it reasonable to draw 'coastline' on fresh water?


There is going to be diffusion, although that will be dwarfed by tidal
effects.  And since ocean salinity comes from rivers
washing salt out of the soil to the sea, careful measurements will find
salinity far upstream.

Not being a hydrologer, or a professional cartographer I would have thought
tides had a part to play.  I.e., where a river's
high water mark fluctuates (roughly) twice daily or where flow is reversed
in an estuary because of tidal flow.

I expect somebody has a better definition.

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

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

[Kevin Kenny]

Imagico's proposal is perhaps objective, but surely doesn't match
perception in my part of the world. It seems odd that the 'coastline'
must extend upward to https://www.openstreetmap.org/way/90929525 - but
that is, according to Imagico's definitions, simultaneously the lowest
and highest permissible limit. The locals would be astonished to call
the whole lower Hudson River 'ocean,' even though it is tidal.
Salinity varies; the point at which chloride concentration of 100 mg/l
is observed varies seasonally by over 100 km. There is an observable
salinity gradient through the entire estuary, but anywhere north of,
say, Hyde Park is 'fresh' water by any reasonable definition, even in
a dry summer. Is it reasonable to draw 'coastline' on fresh water?
On Mon, Sep 3, 2018 at 12:05 PM Christoph Hormann  wrote:
>
> On Monday 03 September 2018, Joseph Eisenberg wrote:
> > In my case, I've been debating whether to change the tagging of the
> > coastline in southwestern New Guinea (Papua, Indonesia) where many
> > large tropical rivers meet the Arafura sea among mangroves. The heavy
> > rainfall in this area means that the rivers have a pronounced
> > current. But the water is brackish and certainly tidally-influenced
> > far inland. Right now, it seems odd that many patches of mangroves
> > are made into "islands" by the use of natural=coastline, though
> > locally they would be considered part of the larger landmass of New
> > Guinea.
>
> The sitaution at a mangrove coast is slightly different from elsewhere
> because the mangrove forest is typically mapped as land w.r.t. the
> coastline which makes the tidal channels in between look like wide
> rivers - which is however often misleading.
>
> For example
>
> https://www.openstreetmap.org/relation/3111444
>
> is not a river despite being tagged as a riverbank polygon.
>
> This misunderstanding of the nature of mangrove coasts misinterpreting
> wide tidal channels as large rivers has led for example for some time
> in West Africa to a massive shortening of the coastline and a large
> fraction of virtual closing segments in the total coastline lenth -
> see:
>
> http://www.imagico.de/map/coastline_quality4_en.php
>
> This is now mostly fixed but the lure especially of armchair mappers to
> map this way is still there.
>
> > See: https://www.openstreetmap.org/#map=11/-4.8806/136.9339 ; the
> > coastline is quite noticable because it has also been tagged as the
> > administrative boundary.
>
> The administrative boundaries are generally a bad place to position the
> coastline because they are typically defined very differently from how
> OSM defines the coastline (and are also mostly very inaccurate
> geometrically).
>
> > What will be most helpful for data users and map renderers? Should
> > the coastline extend inland many kilometers, to where the mangroves
> > end? This will create a large number of apparent islands, and small
> > rivers will be entirely part of the "ocean" beyond the coastline.
> > Should it be down the the mouth of the river, to keep the coastline
> > as compact as possible?
>
> The coastline should be (a) a meaningful geometry on its own, i.e. the
> virtual parts of it (closing segments at river mouths) should be short
> and (b) be as easy to verify for the mapper as possible.
>
> Technically it is also important that the range of acceptable coastline
> positions is not too large so mappers do not move around the coastline
> a lot just to scratch their personal itch.
>
> > What about huge estuaries like the Saint Lawrence and the Rio De La
> > Plata? Should there be a vote on Imagico's proposal, or a new
> > proposal?
>
> I would be glad if anyone wants to reactivate the proposal or comes up
> with simpler rules for where to close the coastline.  But IMO a hard
> requirement for this would be that these are physically based rules
> rooted in the observable reality and not based on political or other
> purely abstract considerations.
>
> Some newer examples of problematic closure placements (in addition to
> the ones in the proposal):
>
> https://www.openstreetmap.org/way/463191729
> https://www.openstreetmap.org/way/474230093
>
> --
> 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] Coastline for rivers, estuaries and mangroves?

[Christoph Hormann]

On Monday 03 September 2018, Joseph Eisenberg wrote:
> In my case, I've been debating whether to change the tagging of the
> coastline in southwestern New Guinea (Papua, Indonesia) where many
> large tropical rivers meet the Arafura sea among mangroves. The heavy
> rainfall in this area means that the rivers have a pronounced
> current. But the water is brackish and certainly tidally-influenced
> far inland. Right now, it seems odd that many patches of mangroves
> are made into "islands" by the use of natural=coastline, though
> locally they would be considered part of the larger landmass of New
> Guinea.

The sitaution at a mangrove coast is slightly different from elsewhere 
because the mangrove forest is typically mapped as land w.r.t. the 
coastline which makes the tidal channels in between look like wide 
rivers - which is however often misleading.

For example

https://www.openstreetmap.org/relation/3111444

is not a river despite being tagged as a riverbank polygon.

This misunderstanding of the nature of mangrove coasts misinterpreting 
wide tidal channels as large rivers has led for example for some time 
in West Africa to a massive shortening of the coastline and a large 
fraction of virtual closing segments in the total coastline lenth - 
see:

http://www.imagico.de/map/coastline_quality4_en.php

This is now mostly fixed but the lure especially of armchair mappers to 
map this way is still there.

> See: https://www.openstreetmap.org/#map=11/-4.8806/136.9339 ; the
> coastline is quite noticable because it has also been tagged as the
> administrative boundary.

The administrative boundaries are generally a bad place to position the 
coastline because they are typically defined very differently from how 
OSM defines the coastline (and are also mostly very inaccurate 
geometrically).

> What will be most helpful for data users and map renderers? Should
> the coastline extend inland many kilometers, to where the mangroves
> end? This will create a large number of apparent islands, and small
> rivers will be entirely part of the "ocean" beyond the coastline.
> Should it be down the the mouth of the river, to keep the coastline
> as compact as possible?

The coastline should be (a) a meaningful geometry on its own, i.e. the 
virtual parts of it (closing segments at river mouths) should be short 
and (b) be as easy to verify for the mapper as possible.

Technically it is also important that the range of acceptable coastline 
positions is not too large so mappers do not move around the coastline 
a lot just to scratch their personal itch.

> What about huge estuaries like the Saint Lawrence and the Rio De La
> Plata? Should there be a vote on Imagico's proposal, or a new
> proposal?

I would be glad if anyone wants to reactivate the proposal or comes up 
with simpler rules for where to close the coastline.  But IMO a hard 
requirement for this would be that these are physically based rules 
rooted in the observable reality and not based on political or other 
purely abstract considerations.

Some newer examples of problematic closure placements (in addition to 
the ones in the proposal):

https://www.openstreetmap.org/way/463191729
https://www.openstreetmap.org/way/474230093

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

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

Re: [Tagging] wiki modification landuse=meadow definition

[Mateusz Konieczny]

3. Wrzesień 2018 13:16 od pla16...@gmail.com :


> In favour of "for a": landuse=forestry (except it ended up being named 
> landuse=forest).  The land is used FOR> forestry.




You area may be very unusual, in general landuse=forest is used for "this area 
is a forest" or

sometimes "this area is covered by trees".

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

Re: [Tagging] motorcar definition changed recently

[Martin Koppenhoefer]

2018-09-03 9:36 GMT+02:00 SelfishSeahorse :

> The meaning of the motorcar key has been discussed some time ago with the
> conclusion that motorcar=no means 'no entry for any power driven vehicle
> except two-wheeled motor cycles without side-car', while motorcar=yes only
> means that motorcars are allowed. (Unfortunately i couldn't find the
> discussion yet.)
>
> So yes, i think the change should be reverted.
>


Thank you, I have now reverted the change wrt to motorcar. At second
thought, I added a short sentence about motorcar implications for other
double tracked motorized vehicles in restrictions, feel free to improve
this.

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

Re: [Tagging] wiki modification landuse=meadow definition

[Paul Allen]

On Mon, Sep 3, 2018 at 4:29 PM, Martin Koppenhoefer 
wrote:

>
> I don't see any tags in favour of "for a",
>

I didn't either.  But I didn't look very hard.


> the common tag is landuse=forest not forestry,
>

You have introduced the perennial [groan] problem with landuse=forest.  The
wiki made clear it was
intended to mean land used for forestry, instead most people interpreted it
as meaning land with a
forest on it, which is better tagged as landcover=trees or natural=wood.
Going by the intended meaning,
landuse=forest was meant to indicate land used for logging.


> other tags include "greenfield", "brownfield", "landfill", village_green,
> farmland, farmyard.
>

Yeah, I think the "is a" relationship wins by a large margin, and
landuse=meadow fits those semantics.

Now we can have a long (and not very productive) argument about whether
landuse ought to mean "for
a" relationships.

This list constantly reminds me of the aphorism by Frederick P Brooks when
writing about the design of
operating systems and business applications: "[...] plan to throw one away;
you will; anyhow."  Your
first attempt will be sub-optimal, but you'll learn how to do it right the
next time.

With the benefit of hindsight, we could come up with a far better (more
consistent, more comprehensible)
system of tagging based upon what we've learned.  But we won't (can't) do
that because it would essentially
mean mapping EVERYTHING again (a major percentage of objects will not be
directly translatable).  So all
we can do is try not to make it worse by adding even more tags that are
inconsistent, incomprehensible,
and have a natural interpretation that contradicts how they're meant to be
used (forest/forestry).

Then again, according to Ralph Waldo Emerson "A foolish consistency is the
hobgoblin of little minds."

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

Re: [Tagging] motorcar definition changed recently

[SelfishSeahorse]

Here's the weblink to Simon's explanation of motorcar=yes vs motorcar=no
from the past discussion:

https://lists.openstreetmap.org/pipermail/tagging/2017-November/034208.html

(The corresponding thread about a special road barrier started here:
https://lists.openstreetmap.org/pipermail/tagging/2017-November/thread.html#34194
)

On Mon, 3 Sep 2018 09:36 SelfishSeahorse,  wrote:

> The meaning of the motorcar key has been discussed some time ago with the
> conclusion that motorcar=no means 'no entry for any power driven vehicle
> except two-wheeled motor cycles without side-car', while motorcar=yes only
> means that motorcars are allowed. (Unfortunately i couldn't find the
> discussion yet.)
>
> So yes, i think the change should be reverted.
>
> Regards
> Markus
>
> On Sun, 2 Sep 2018 23:14 Martin Koppenhoefer, 
> wrote:
>
>> OMG the Germans have overtaken the wiki. I just noticed this change to
>> the motorcar access definition:
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=revision=1601167=1598869
>>
>>
>> https://wiki.openstreetmap.org/w/index.php?title=Key:motorcar=next=1532406
>>
>>
>> I used motorcar to mean automobile in the past, although most of the time
>> the restrictions were more general. motorcar=no meant probably also hgv=no,
>> but in access=no & motorcar=yes I don’t think that hgv=yes is implied.
>>
>> Cheers,
>> Martin
>>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wiki modification landuse=meadow definition

[Martin Koppenhoefer]

2018-09-03 13:16 GMT+02:00 Paul Allen :

> On Mon, Sep 3, 2018 at 1:31 AM, Warin <61sundow...@gmail.com> wrote:
>
> The land is not used by/for  'meadow'.
>> It is used to produce animal_fodder .. so landuse=animal_fodder would be
>> a better term.
>>
>
> That depends if you view landuse as specifying a "for a" relationship or
> an "is a" relationship or can specify either.
>
> In favour of "for a": landuse=forestry (except it ended up being named
> landuse=forest).  The land is used FOR
> forestry.
>
> In favour of "is a": landuse=quarry.  The land IS a quarry.
>
>


I don't see any tags in favour of "for a", the common tag is landuse=forest
not forestry, other tags include "greenfield", "brownfield", "landfill",
village_green, farmland, farmyard.


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

Re: [Tagging] wiki modification landuse=meadow definition

[Martin Koppenhoefer]

sent from a phone

> On 3. Sep 2018, at 02:50, Tod Fitch  wrote:
> 
> What is the “use” of a meadow that makes it a meadow rather than, say and 
> area of un-mowed, un-grazed herbaceous flowers and grasses?


the areas I am familiar with for the latter you describe are either 
natural=heath or they become forests after some years of neither mowing nor 
grazing.
Or they are above the tree line. Or maybe more (temperature in general, other 
conditions that don’t let grow trees), I agree a meadow does not have to be 
mown, but if it’s used for grazing (not after cutting a meadow for hay) it is a 
pasture.

When speaking of “use” it seems logical to assume agricultural use, which would 
mean a meadow is used for the production of hay.


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

[Tagging] namespace for shop subtags - genaral format

[Thilo Haug]

Forwarding this with a new subject
as otherwise we discuss again "small" things instead of the whole principle
(shouldn't just be defined for horse:rental, but one namespace for all
offered services/goods)

Example :
*:sales=*
*:parts=*
*:rental=*

 Weitergeleitete Nachricht 
Betreff:Re: [Tagging] horse rental
Datum:  Mon, 3 Sep 2018 16:18:47 +0200
Von:Thilo Haug OSM 
Antwort an: th...@gmx.de
Organisation:   OSM
An: tagging@openstreetmap.org



Such as in the bicycle shop example ?
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys

This one has been discussed :
https://wiki.openstreetmap.org/wiki/Proposed_features/service:bicycle

And it's totally different to the car version :
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar#Tags_used_in_combination

That's why I think the (namespace) principle / "grammar" should be discussed
instead of inventing the wheel from scratch for every shop
(and having endless discussions about differences between slightly
different shops
instead of letting people express the details with an easy "grammar" /
"subkeys").

Am 03.09.2018 um 15:49 schrieb Martin Koppenhoefer:
>
>
> 2018-09-03 15:18 GMT+02:00 Thilo Haug OSM  >:
>
> The principle should be described in general (not only for rental and
> not only for one shop),
> as there's currently a mess with different formats (compare car /
> bicycle / motorcycle shops).
>
>
>
>
> speaking about "mess"; it is the result of people creating new
> webpages for unexisting features without discussion or notice, so that
> the result is often similar to what you created on the skateboarding
> page: board:type for skateboards where all existing values are
> actually typos for board_type of information boards.
>
> Discussing with other mappers prior to writing new stuff into the
> wiki, using the established procedures (proposal process), searching
> the wiki and taginfo before inventing tags, all this can help to avoid
> the mess.
>
> 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] horse rental

[Thilo Haug OSM]

Such as in the bicycle shop example ?
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys

This one has been discussed :
https://wiki.openstreetmap.org/wiki/Proposed_features/service:bicycle

And it's totally different to the car version :
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar#Tags_used_in_combination

That's why I think the (namespace) principle / "grammar" should be discussed
instead of inventing the wheel from scratch for every shop
(and having endless discussions about differences between slightly
different shops
instead of letting people express the details with an easy "grammar" /
"subkeys").

Am 03.09.2018 um 15:49 schrieb Martin Koppenhoefer:
>
>
> 2018-09-03 15:18 GMT+02:00 Thilo Haug OSM  >:
>
> The principle should be described in general (not only for rental and
> not only for one shop),
> as there's currently a mess with different formats (compare car /
> bicycle / motorcycle shops).
>
>
>
>
> speaking about "mess"; it is the result of people creating new
> webpages for unexisting features without discussion or notice, so that
> the result is often similar to what you created on the skateboarding
> page: board:type for skateboards where all existing values are
> actually typos for board_type of information boards.
>
> Discussing with other mappers prior to writing new stuff into the
> wiki, using the established procedures (proposal process), searching
> the wiki and taginfo before inventing tags, all this can help to avoid
> the mess.
>
> 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] Tagging suggestions for electricity

[Martin Koppenhoefer]

2018-09-03 9:38 GMT+02:00 Javier Sánchez Portero :

> That was in the past, but now there is a visual editor very easy to use.
>


easiest and quickest is copy pasting the proposal template (or a good
existing proposal) and filling in the info.

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

Re: [Tagging] horse rental

[Martin Koppenhoefer]

2018-09-03 15:18 GMT+02:00 Thilo Haug OSM :

> The principle should be described in general (not only for rental and
> not only for one shop),
> as there's currently a mess with different formats (compare car /
> bicycle / motorcycle shops).




speaking about "mess"; it is the result of people creating new webpages for
unexisting features without discussion or notice, so that the result is
often similar to what you created on the skateboarding page: board:type for
skateboards where all existing values are actually typos for board_type of
information boards.

Discussing with other mappers prior to writing new stuff into the wiki,
using the established procedures (proposal process), searching the wiki and
taginfo before inventing tags, all this can help to avoid the mess.

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

Re: [Tagging] horse rental

[Warin]

On 03/09/18 23:18, Thilo Haug OSM wrote:


The principle should be described in general (not only for rental and
not only for one shop),
as there's currently a mess with different formats (compare car /
bicycle / motorcycle shops).



+1


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

Re: [Tagging] horse rental

[Thilo Haug OSM]

Hi,

"Doesn't need a semicolon, only the main activity gets amenity=*, see
examples"
is fine.

The principle should be described in general (not only for rental and
not only for one shop),
as there's currently a mess with different formats (compare car /
bicycle / motorcycle shops).

I think namespaces with : are more usual,
but technically it makes no difference.

And the question is whether the "main amenity" makes sense in this case.
Let's say I search a service which is usually already part of something
else (main key shop=* or similar)
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcar_rental
--> then you'd need to search for several values, amenity=car_rental and
car_rental=*
shop=car
or
shop=rental
with
car:rental=yes
would IMHO be more stuctured.

I also don't understand what the prefix "service" in bicycle is good for
(to distinguish it from which other key "without service" ?)
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys

Cheers,
Thilo

Am 03.09.2018 um 12:19 schrieb Hufkratzer:
> On 2.9.2018 22:06 Thilo Haug OSM wrote:
>> {...]
>> The current namespace article doesn't mention underscores :
>> https://wiki.openstreetmap.org/wiki/Namespace#Example_namespace_uses
>
> I think it doesn't have to, the underscore can just be a part of a key
> or a value like any letter [a-z] can.
>
>> The amenity=* version is IMHO the worst possibility (in case of several
>> "amenities")
>> as you could just work with semicolon separator,
>> which isn't recommended : [...]
>
> Doesn't need a semicolon, only the main activity gets amenity=*, see
> examples:
>
> https://www.openstreetmap.org/node/3880444689 :
> amenity=restaurant
> horse_rental=yes
>
> https://www.openstreetmap.org/node/1563976033 :
> amenity=fuel
> car_rental=yes
>
> https://www.openstreetmap.org/node/2356973972 :
> amenity=boat_rental
> bicycle_rental=yes
> dinghi_rental=yes
> motorboat_rental=yes
> pedalboat_rental=yes
>
> If you want to search for all car_rental's you have to search for
> amenity=car_rental (main activity) and for car_rental=yes (secondary
> activity). This is uncomfortable, but the  rendering
> depends on the main activity, therefore the distinction is necessary.
> Isn't it?
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Feature Proposal - RFC: Via ferrata simplified

[Richard]

On Mon, Sep 03, 2018 at 01:25:45PM +0200, egil wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Via_ferrata_simplified

please not a completely new utterly incompatible with everything else
proposal.

Many elements of the old proposal are in use and rendered by several
maps.

While the old proposal is controversial, the plan has been to overcome
much of the controversy by adding the possibility to tag ferratas as 
relation of type route=ferrata (added a few days ago).

Why would you want to use route=hiking for ferrata if you can use 
route=ferrata? Do you want to deprecate via_ferrata_scale as well?

Richard

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

Re: [Tagging] Tagging suggestions for electricity

[François Lacombe]

Hi

Le lun. 3 sept. 2018 à 02:59, Warin <61sundow...@gmail.com> a écrit :

>
> No it does not, "any tags you like' - documenting them simply helps people
> understand their use.
>

With all due respect, I disagree, unless any understanding mistake.
It's really hard to change, refine or even consistently aggregate tags once
they get widely used. Usage volume is the most raised argument against
further refinement.

Documentation is the least we can expect from a promoter (only
expectations).
Usage isn't a guarantee of consistency, there is no matter of good vs bad
too.

Then discussing a proposal prior a tag get used isn't just a bureaucracy
issue but a chance to make things way better together despite many think
it's irrelevant.
If not, we should stop arguing on how popular some keys may be to refine
them sometimes.


> Show me the proposals for shop, office, crop, produce ..
> New tags start out with little use.. but they should be documented ..
> and if they don't go through the proposal process than they  don't need a
> proposal page ..
> they just get put on the OSM wiki .. sink or swim. They get used over time
> .. or they fadeout.
>

We can't but I wish I could show you some proposals for such important keys.
Some de facto keys are pretty messy due to lack of semantic design.

To come back in the utilities topic, I'm really in favor of a proposal to
discuss on.

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

[Tagging] Feature Proposal - RFC: Via ferrata simplified

[egil]

https://wiki.openstreetmap.org/wiki/Proposed_features/Via_ferrata_simplified

Cheers

Egil / pangoSE


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

Re: [Tagging] wiki modification landuse=meadow definition

[Paul Allen]

On Mon, Sep 3, 2018 at 1:31 AM, Warin <61sundow...@gmail.com> wrote:

The land is not used by/for  'meadow'.
> It is used to produce animal_fodder .. so landuse=animal_fodder would be a
> better term.
>

That depends if you view landuse as specifying a "for a" relationship or an
"is a" relationship or can specify either.

In favour of "for a": landuse=forestry (except it ended up being named
landuse=forest).  The land is used FOR
forestry.

In favour of "is a": landuse=quarry.  The land IS a quarry.

It seems to me that enforcing "for a" relationships would mean deprecating
landuse=quarry for landuse=roof
(when the quarry was for slate, and the primary use of that slate was
roofing), landuse=doorstep (slate quarry
used for doorsteps - common in parts of Wales), landuse=roof;doorstep,
etc.  Then landuse=road when it's
a quarry for aggregate.  And landuse=fire when it's an opencast coal mine.
Doesn't seem to work very well if
we enforce "for a" relationships for all landuse.

Maybe quarry was a bad example.  How about landuse=allotments?  That would
have to be landuse=gardening,
because it's not land that has allotments on it but land that is used for
gardening.  Landuse=cemetary has to
become landuse=dead_bodies, because it is for dead bodies.  Landuse=garages
- the land isn't used by
garages, it's used by people parking cars, so landuse=cars or
landuse=people.

I conclude that your 'the land is not used by/for "meadow"', if applied
generally, would be unworkable.  I am
therefore happy that landuse=meadow means that the land IS a meadow in the
same way that landuse=quarry
means that the land IS a quarry.

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

Re: [Tagging] Slow vehicle turnouts

[Dave Swarthout]

I'm still trying to cook up a scheme where those pullouts can be added as a
way and then tagged in a manner that reveals their purpose and function.
The use of lanes may indeed be the most correct approach but to my way of
thinking, it doesn't communicate the purpose of the "extra" lane very well.
Because the turnouts use a separate lane, are very short in length, and are
not really thoroughfares in the usual sense, might it be logical to tag
them as service roads? As an example:
highway=service
service=slow_vehicle_turnout (or slow_vehicle_lane)
lanes=1
oneway=yes

Opinions? Observations?

On Mon, Aug 27, 2018 at 4:16 AM Kevin Kenny  wrote:

> On Sun, Aug 26, 2018 at 4:11 PM Dave Swarthout 
> wrote:
> > >We also have the occasional spot like
> > >
> https://orthos.dhses.ny.gov/?Extent=-8283718.624472891,5242597.149663145,-8283317.927238801,5242833.029555047=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
> > >There, we have an extra lane on the northbound side for the purpose of
> > >getting by when the way is blocked by left-turning traffic
> >
> > My case is almost identical to the above illustration, except to
> substitute the words "slow moving vehicles" for "left turning traffic". I
> reckon I could use the lanes tagging but like Kevin, I have many "other
> fish to fry" which is why I'm still looking for a simple one-tag-fixes-all
> solution.
>
> My guess is that the slow-moving traffic is supposed to pull over into
> the outer lane, allowing the parade behind to pass on the inside,
> rather than the through traffic passing on the outer lane?  That's
> like my first case, except that in that particular case, the climbing
> lane goes on for several km (the highway is gaining a few hundred
> metres of elevation up the Helderberg escarpment). We do have ones
> that are more like pullouts rather than long lanes. There's a shorter
> one on the westbound carriageway in
>
> https://orthos.dhses.ny.gov/?Extent=-8267325.730037971,5268580.377261018,-8265722.941101252,5269523.896828834=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
>
> By contrast, although the section is short, the outer westbound lane
> in
> https://orthos.dhses.ny.gov/?Extent=-8244541.671667748,5187738.535180551,-8244140.974433658,5187974.415072453=2017_cache,2016_cache,2015_cache,2014_cache,2013_cache
> is NOT a climbing lane. It's set off by a single broken line, and
> traffic is expected to keep to the right except to pass.
>


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

Re: [Tagging] horse rental

[Hufkratzer]

On 2.9.2018 22:06 Thilo Haug OSM wrote:

{...]
The current namespace article doesn't mention underscores :
https://wiki.openstreetmap.org/wiki/Namespace#Example_namespace_uses


I think it doesn't have to, the underscore can just be a part of a key 
or a value like any letter [a-z] can.



The amenity=* version is IMHO the worst possibility (in case of several
"amenities")
as you could just work with semicolon separator,
which isn't recommended : [...]


Doesn't need a semicolon, only the main activity gets amenity=*, see 
examples:


https://www.openstreetmap.org/node/3880444689 :
amenity=restaurant
horse_rental=yes

https://www.openstreetmap.org/node/1563976033 :
amenity=fuel
car_rental=yes

https://www.openstreetmap.org/node/2356973972 :
amenity=boat_rental
bicycle_rental=yes
dinghi_rental=yes
motorboat_rental=yes
pedalboat_rental=yes

If you want to search for all car_rental's you have to search for 
amenity=car_rental (main activity) and for car_rental=yes (secondary 
activity). This is uncomfortable, but the  rendering
depends on the main activity, therefore the distinction is necessary. 
Isn't it?



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

Re: [Tagging] routes with double use hiking and bicycle

[Volker Schmidt]

(retransmission without photo)

> How many routes are ciclopedonale in Italy? I have seen one in 8 days of
>> cycling though Northern Italia, and it was a way or connection rather than
>> a marked/named  route.
>>
>> Mvg Peter Elderson 
>>
>
> Good question. This is a bit difficult because even the institutions that
> create/finance/manage these things are confusing the definitions and the
> names under which the routes are presented.
>
> Also, I can only talk for the Veneto Region.
>
> Some examples I know of:
>
> *Pista Ciclabile Treviso Ostiglia*
> is officially called ciclpedonale and most of its componten ways are
> condivided foot-cycle-ways:
>
> (OSM relation 2375471 )
>
> Muson dei Sassi - Cammino di Sant'Antonio
>
> http://osm.org/go/0IBuUag--?layers=CD=301630148
>
> Sui sentieri degli Ezzelini
>
> http://osm.org/go/0IEqTNK--?layers=C=2247688
> http://www.sentieroezzelini.it/
>
> *Lungo Cammino di Sant'Antonio*
>
> several relations (in permanent evolution).
>
> One of these is: OSM relation 5504854
> 
>
> Cammino Fogazzaro-RoiOSM relation 6048999
>  hiking and
> MTB
> (this is the one that triggered my post)
>
> There is also at least one that is both a car route and a cycle route:
> Meraviglie della Pianura Berica
>
> two OSM relations:
>
> 5371514  Meraviglie della
> Pianura Berica 47km
>
> 5380453  Meraviglie della
> Pianura Berica – varianti 20km
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wiki modification landuse=meadow definition

[SelfishSeahorse]

I remember it has been discussed, but maybe not on this list.

The problem was that different wiki pages had different definitions of
landuse=meadow (used to tag land used for hay and for grazing animals),
natural=grassland (mainly used to tag natural grassland/meadows) and
landuse=farmland (used to tag land used for tillage and for grazing
animals). The edit was an attempt to solve that issue.

Regards
Markus

On Mon, 3 Sep 2018 00:00 Martin Koppenhoefer, 
wrote:

> Another change I noticed which wasn’t discussed AFAIR:
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Tag:landuse%3Dmeadow=prev=1515853
>
>
> Comments?
>
>
> Cheers,
> Martin
>
> sent from a phone
> ___
> 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] routes with double use hiking and bicycle

[Volker Schmidt]

> Just for interests sake, if a route is tagged as both foot & bike, what
> would it render as? In OSM, cycle paths are blue, while foot paths are red.
> In OSMAND, cycle paths are blue dashes, foot paths are black dots.
>

I am talking abut route relations and not about ways.
Bicycle and hiking routes are not rendered by the Standard OSM rendering
(don't know about OSMAnd)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] wiki modification landuse=meadow definition

[Peter Elderson]

I am city. To me a meadow is a storage area for farm animals.

Op ma 3 sep. 2018 om 02:52 schreef Tod Fitch :

>
> > On Sep 2, 2018, at 5:41 PM, Martin Koppenhoefer 
> wrote:
> >
> >
> >
> > sent from a phone
> >
> >> On 3. Sep 2018, at 02:31, Warin <61sundow...@gmail.com> wrote:
> >>
> >> The land is not used by/for  'meadow'.
> >
> >
> > it is used as a meadow
> >
>
> There are natural meadows within the forested areas in the mountains near
> me. At least they look like the typical images I see of meadows and the
> locals call them meadows. The use is exactly the same as the use of the
> surrounding forest: Recreation, wild life management, etc. What is the
> “use” of a meadow that makes it a meadow rather than, say and area of
> un-mowed, un-grazed herbaceous flowers and grasses?
>
> For what its worth, I’ve been tagging them with landcover=grass though
> that is not exactly correct and it is not purely grass as there are usually
> a bunch of flowing plants intermixed.
>
> Cheers!
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Vr gr Peter Elderson
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging suggestions for electricity

[Javier Sánchez Portero]

That was in the past, but now there is a visual editor very easy to use.

El lun., 3 sept. 2018 a las 1:52, Dave Swarthout ()
escribió:

> One of the biggest problems with "creating a proposal" is that the Wiki
> markup language is so painfully tedious I've taken pains to avoid it.
> People always say, "write it up in the Wiki" as though it's similar to
> writing a letter in a word processor. It is not. It's a process I've
> criticized in the past as being very difficult— it's one reason why many
> proposals aren't written up but simply acted upon.
>
> My 2 cents
>
> Dave
>
> On Mon, Sep 3, 2018 at 7:38 AM Warin <61sundow...@gmail.com> wrote:
>
>> On 03/09/18 10:05, Martin Koppenhoefer wrote:
>>
>>
>>
>> sent from a phone
>>
>> On 3. Sep 2018, at 01:42, Warin <61sundow...@gmail.com> wrote:
>>
>> Just one question though: for the wiki page of this do I put "draft" or
>> "proposed" or "de facto" or "in use" for the status?
>>
>>
>> I would not put a status on it.
>>
>> It is not a draft, proposed nor approved.
>> It has no use at the moment, and it is certainly not de facto.
>>
>>
>>
>> if you want to introduce an (also almost) unused tag to the wiki you
>> should create a proposal, it is the established way. You can set the status
>> to draft while you work on it, then formally ask for comments here, it
>> should be all explained there:
>>
>> https://wiki.openstreetmap.org/wiki/Proposal_process
>>
>>
>> That is one way.
>> It is not compulsory to do that.
>> You can simply start to use the tag AND document its use.
>> The problem with tags that have some use but no documentation is that no
>> one really knows what was intended. e.g. landuse=clearing.
>> I have tried to contact the people that used this tag -- no response.
>>
>> Things like the key shop have been introduced without going through a
>> proposal process.
>> If you don't want to go through the proposal process .. then don't.
>>
>> ___
>> 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] motorcar definition changed recently

[SelfishSeahorse]

The meaning of the motorcar key has been discussed some time ago with the
conclusion that motorcar=no means 'no entry for any power driven vehicle
except two-wheeled motor cycles without side-car', while motorcar=yes only
means that motorcars are allowed. (Unfortunately i couldn't find the
discussion yet.)

So yes, i think the change should be reverted.

Regards
Markus

On Sun, 2 Sep 2018 23:14 Martin Koppenhoefer, 
wrote:

> OMG the Germans have overtaken the wiki. I just noticed this change to the
> motorcar access definition:
>
> https://wiki.openstreetmap.org/w/index.php?title=Key%3Aaccess=revision=1601167=1598869
>
>
> https://wiki.openstreetmap.org/w/index.php?title=Key:motorcar=next=1532406
>
>
> I used motorcar to mean automobile in the past, although most of the time
> the restrictions were more general. motorcar=no meant probably also hgv=no,
> but in access=no & motorcar=yes I don’t think that hgv=yes is implied.
>
> Cheers,
> Martin
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging