Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Richard Fairhurst]

Volker Schmidt wrote:
> Going back to the original example, I would say, not only the lock but 
> the entire cut, in particular way
> https://www.openstreetmap.org/way/24335
> should be tagged as waterway=canal. This scheme applies to most river-lock
> arrangements, the "cuts" are nearly almost artificial canals.

Yes.

There's a very big difference from a boating point of view. Taking my home
river as an example, the River Severn, a lock cut such as the one upstream
of Holt Lock makes the approach very easy:
https://www.openstreetmap.org/#map=17/52.26849/-2.26653

Boating on this is exactly like boating on a canal. There is no discernible
current and you can simply hover in midchannel while the lock is prepared
for you (all locks on the Severn are keeper-operated).

Compare this to Gloucester Lock:
https://www.openstreetmap.org/#map=18/51.86538/-2.25197

Here there is no canal approach from upstream - you're straight off the
river into the lock. If you try to hover in midchannel then you will get
swept over Llanthony Weir and River Canal Rescue will have to come and
Tirfor your boat off, which happens two or three times a year to the great
embarrassment of the boat-owner. Consequently you are asked to phone the
lock-keeper in advance so that he can prepare the lock for you and you can
motor straight in. There are lots of warnings about this both off and
online, and rightly so
(https://canalrivertrust.org.uk/refresh/media/thumbnail/27339-new-river-severn-navigation-guide-april-2016.pdf,
https://www.canalworld.net/forums/index.php?/topic/95567-ship-lock-gloucester/&tab=comments#comment-2121288,
http://www.severn-boating.co.uk/sharp.htm etc.).

On some of the larger American river navigations the lock structures are
built right within the main river channel - such as this new $3bn (!) lock
on the Ohio River: https://en.wikipedia.org/wiki/Olmsted_Locks_and_Dam - so
similar caution to Gloucester would apply, particularly in times of high
flow. On a major navigation like that you'd be expected to use VHF to keep
in contact with the lock-keepers, of course.

So there is a very big difference between locks with a canal approach and no
canal approach, and that should be reflected in the tagging.

Richard
(boat-owner, regular contributor and former editor of Waterways World,
former editor of British Waterways' website, founder of Melton Mowbray
Navigation restoration project yadda yadda yadda)




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[pbnoxious]

I think the whole problem cannot be solved in general as it depends from
case to case.

A nice example of where the clear distinction between "natural river"
and "artificial canal" is hard to tell is the river Altmühl: Its most
downstream part has been built into a canal, which later leaves the
"natural" bed and continues to connect it to the river Main. Still it is
often named "Main-Donau-Kanal" even where the old river bed is.
See for example this way [1], which is a part tagged as river but has
the name "Kanal". Is this a river or a canal? Additionally it is in the
middle of sections that are tagged as "Altmühl", so the river "ceases to
exist" in our mapping for some range.

I guess one always has to decide this on a local level and acknowledge
that rivers in many parts of the world are not "natural" anymore.


[1] https://www.openstreetmap.org/way/599254030




On 25/04/2019 23.54, Paul Allen wrote:
> On Thu, 25 Apr 2019 at 22:16, Graeme Fitzpatrick 
> wrote:
> 
>> Getting away from the discussion of river v canal & back to the original
>> problem pictured
>> https://www.openstreetmap.org/way/347369154 , why is it "River Wey
>> Navigation" while the river itself is just "Wey"
>>
> 
> Canals, when used for boats, are often known as navigation canals.  And
> sometimes
> referred to as just navigations.
> 
> It looks to me like the River Wey Navigation might be a canal to shorten
> the route for river traffic
> (or maybe because the river at that point wasn't deep enough and it was
> cheaper to construct
> a canal than dredge the river).  Which would make sense.  Which is why I'm
> probably wrong,
> because things rarely make sense.
> 
> & is the unnamed river to the South
>> https://www.openstreetmap.org/way/23216681, the natural Wey?
>>
> 
> It could be the curd. :)
> 
> Actually, it may not be the natural Wey.  Not going by the OS 1:25k
> historic layer.  Which is
> incomplete.   But the same layer is available from NLS (easy to select with
> JOSM, but if you're
> using iD then use https://geo.nls.uk/mapdata2/os/25000/{zoom}/{x}/{-y}.png
> as your custom
> layer (I have asked iD to use the NLS version instead but the iD team just
> respond by
> saying they don't want that historic layer there anyway because they think
> it confuses people).
> It looks like the natural river got diverted at some point after the canal
> was built in order to
> make room for roads.  But that is a wild guess on my part.
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tag:natural=mesa and Tag:natural=butte

[Christoph Hormann]

On Friday 26 April 2019, Joseph Eisenberg wrote:
> I have created 2 proposal pages for natural=mesa and natural=butte
>
> A mesa is defined as "A flat-topped elevated landform surrounded by
> cliffs". A mesa may also be known as a table or tableland, potrero or
> tepui. See http://en.wikipedia.org/wiki/en:mesa
>
> A butte is defined as "a hill with a flat top surrounded by cliffs."
> The width of the flat top is less than the relative height of the
> hill. See http://en.wikipedia.org/wiki/en:butte
>
> [...]

As i understand it a butte is not generally assumed to be flat topped in 
common language use, the key elements here are height larger than width 
and cliffs on all sides.

For mesas i already mentioned the fairly precise criterion that the 
elevation variance along the top (or more precisely the derivation from 
flatness - some amount of tilt in geology is fairly common) needs to be 
significantly smaller than the overall height of the structure.  
Combined with a firm requirement for cliffs on all sides this would 
make a fairly precise definition.

In general for a successful tag explaining precisely and in detail how 
the mapper can distinguish features the tag should be used for from 
ones it should not be used for is key.  Referring vaguely to Wikipedia 
for details is not going to work, the actual meaning of the tag will 
deviate from the Wikipedia description.

It should also be mentioned that these tags are not meant to be a 
substitute for locally mapping the actual cliffs - which while by 
definition surrounding the whole structure can be staggered of course.

For natural=plateau i don't see a chance of this becoming a meaningful 
tag.  Too much inherent vagueness in the very idea.  If you'd try to 
define it more precisely it would almost certainly be advisable to use 
a different tag that is not misleading the mapper to have a much 
broader scope.

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

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

Re: [Tagging] Feature Proposal - RFC - Tag:natural=mesa and Tag:natural=butte

[Martin Koppenhoefer]

sent from a phone

> On 26. Apr 2019, at 07:06, Warin <61sundow...@gmail.com> wrote:
> 
> Flat topped area with sudden elevation, wider or longer than it is high
> but horizontal dimension less than 1.6 km.


or maybe 1.609344 kilometers? Seriously, if we use a definition based on 
imperial units I would use these units in the definition.

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

Re: [Tagging] Why should we avoid overusage of amenity=* tag?

[Mateusz Konieczny]

25 Apr 2019, 23:49 by 61sundow...@gmail.com:

>
> Communities have drawn together to keep a bank, a supermarket and a garage 
> going locally. They have also drawn together to keep a doctor.
> They don't draw together for a church.
>
Depends on a community. The last one
 certainly is not true for many places.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Michael Brandtner via Tagging]

I’m against the tag baby_changing_table. As I have already written, 
changing_table is unambiguous and the most common word for this thing. No need 
for such a long key.

Am Donnerstag, April 25, 2019, 10:52 PM schrieb Martin Koppenhoefer 
:



sent from a phone

> On 22. Apr 2019, at 01:49, marc marc  wrote:
> 
> I know the tag description, thanks :)
> the question is "can we expect to have changing tables on a regular 
> basis that are different from what we can expect with other tags,
> which would justify encouraging people to put a description ?


I don’t mind encouraging or not a description, as long as it is in the wiki 
alone it won’t change anything, you can add description tags to anything where 
you feel it is appropriate and generally we should use it mainly for exceptions 
where structured tagging doesn’t seem appropriate.
As I understand it this wouldn’t often be a description of the table object but 
more likely a description of the context or circumstances, e.g. if you’d have 
to ask the staff, or get the table in one place and use it in the next room, 
etc.

What about changing tables as a feature property? For example in Germany there 
are chain shops (drugstores) which offer changing tables as a free service to 
their clients (including napkins). You might not want to position it in the 
shop (the shop might be mapped as a node) but just give the information that 
they offer the service. changing_table=* would seem to be the right tag for 
this property, what about the table as a feature/osm object?
The proposal lacks a definition at the moment, a sentence what the tag should 
mean.

I would prefer “baby_changing_table” as it makes it clearer what it is about 
(think about it, you also gave the proposal this title, and not just changing 
table).

Ciao, 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] Feature Proposal - RFC - Camp_site=camp_pitch

[Martin Koppenhoefer]

sent from a phone

> On 26. Apr 2019, at 04:08, Joseph Eisenberg  
> wrote:
> 
> Then we would need to retag all of the other "camp_site=camp_pitch"
> objects


yes, my suggestion would be to retag all* 7000 camp_site=camp_pitch to a pitch 
tag and keep the camp_site values that refer to camp_site types (like basic, 
spontaneous_camp, serviced, standard, deluxe, primitive etc.) as it is more 
consistent with the general system of a=b b=c...
where c is a subtype of a=b

Wrt the number on camping pitches on earth, and to the number of camp sites 
mapped, 7000 seems a minor number.


* if you like, those camp_site=camp_pitch (very few) that describe a single 
pitch camp site could keep the tagging, but it will probably create friction 
with people still using the same tag for individual pitches, so my suggestion 
would be camp_site=single_pitch for these 


Cheers, Martin 



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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Martin Koppenhoefer]

sent from a phone

> On 26. Apr 2019, at 11:52, Michael Brandtner via Tagging 
>  wrote:
> 
> I’m against the tag baby_changing_table. As I have already written, 
> changing_table is unambiguous and the most common word for this thing. No 
> need for such a long key.


I’m not insisting, but I believe for non-natives the prefix would help. E.g. it 
could be confused with exchange tables ;-)

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

Re: [Tagging] Feature Proposal - RFC - Baby changing table

[Valor Naram]

I now splited the table into two parts so you can see how the wiki will look like (not equal)Seehttps://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables#Tagging Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: Valor Naram To: "Tag discussion, strategy and related tools" CC: I've already made a suggestion to split the wiki pages into two parts:The first one describes the key "changing_table" as a replacement for "diaper". This section will compare the old tagging with the new tagging without introducing new subkeys.The second one describes the extensions (adding of more information which are fully optional to provide) Original Message Subject: Re: [Tagging] Feature Proposal - RFC - Baby changing tableFrom: marc marc To: tagging@openstreetmap.orgCC: no:) (or more exactly: it has been said but I say it againin case you missed it)I notice that the page has almost doubled in size :(I wonder if you shouldn't split the proposal into two:a minimalist proposal that takes the rela data from the diaper=* tagand provides a better schema to encode it, an idea that I fully support.another proposal to promote all other information (fee: there are really paid changing tables in the free toilets ? presence of straps ora pillow: there is really a parent who will base his choice on this criterion ? changing_table:wheelchair:description:xx : there is reallya utility that a contributor describe in his own language that the changing table is inaccessible like all those I have seen ?maybe my experience is not diversified enoughfurthermore the proposal was based on the principle of harmonizing tags with what is done for other objects, but now it introduces inconsistencies (features=bench <> bench=yes for example)Le 25.04.19 à 19:16, Valor Naram a écrit :> There's no discussion concerning the proposal of "baby changing table" > anymore. What's happening? Should I start the voting process? Are all > words said?> > Answer "no" (with or without any reason) and I won't start the voting.> > > Cheers> > Sören alias Valor Naram> > >  Original Message > Subject: [Tagging] Feature Proposal - RFC - Baby changing table> From: Valor Naram> To: tagging@openstreetmap.org> CC:> > > *Definition:* A tag to mark the possibility to change the baby's nappy> *Proposal page:*> https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables> > Please join the discussion and I will spend time to make changes.> > Cheerio> > Sören alias Valor Naram> > > ___> Tagging mailing list> Tagging@openstreetmap.org> https://lists.openstreetmap.org/listinfo/tagging> ___Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Why should we avoid overusage of amenity=* tag?

[Kevin Kenny]

On Fri, Apr 26, 2019 at 5:47 AM Mateusz Konieczny
 wrote:
> 25 Apr 2019, 23:49 by 61sundow...@gmail.com:
>> Communities have drawn together to keep a bank, a supermarket and a garage 
>> going locally. They have also drawn together to keep a doctor.
>> They don't draw together for a church.
>
> Depends on a community. The last one
> certainly is not true for many places.

Certainly near me, there is hardly a village without a church. By the
time the church is boarded up or repurposed, the village is well on
the way to being a ghost town. They certainly outlast the schools -
most kids in the rural villages are bused to central schools nowadays;
and the supermarkets - many villages have never had more than a
general store. (Often, the shopkeeper is also the postmaster.)

In many cases, the church lent its name to the community. Not too far
north of me, there are places named Saint-Henri, Saint-Huberts, ...
that share their names with the parishes. (Anecdotally, around here,
the French settlers did that in their naming; the Dutch and English
generally did not.)

As I think I mentioned earlier, the defunct 18th-century village that
lends its name to the township where my brother lives is a ghost town
- nothing remains but stone foundations, a fine bridge to nowhere, a
few stone walls separating what once were kitchen gardens, and ... the
church, rebuilt several times after fires, and still in occasional use
on special occasions. (There's no longer a community to support it.)
The church was maintained long after the smithy (the village was
abandoned before the rise of the automobile), the store, and the
schoolhouse were all gone. The church needed major repairs a few years
ago, and the scattered inhabitants of the township raised a
subscription to do the work.

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

Re: [Tagging] Incorrectly tagging locks on rivers as canals

[Kevin Kenny]

On Fri, Apr 26, 2019 at 3:44 AM Richard Fairhurst  wrote:
> On some of the larger American river navigations the lock structures are
> built right within the main river channel - such as this new $3bn (!) lock
> on the Ohio River: https://en.wikipedia.org/wiki/Olmsted_Locks_and_Dam - so
> similar caution to Gloucester would apply, particularly in times of high
> flow. On a major navigation like that you'd be expected to use VHF to keep
> in contact with the lock-keepers, of course.

Yes, indeed! For the one by me, the highest flow is in the spring snow
melt, and the river isn't opened to navigation until that's past, but
the approaches to the locks would be entirely unmanageable at that
time. Obviously, the river is closed to navigation all winter long,
because it freezes over!

The modern Erie Canal is the river itself - the whole length of the
river has been dammed and artificially raised, drowning the old canal
in many places. Before that engineering work, much of its length was
whitewater, and it still plunges over Cohoes Falls.

For the lock nearest me, I tagged only the lock chamber
https://www.openstreetmap.org/relation/7464654 as being separate from
what is now the 'main stem' of the river, in deference to the
sensibilities of the vocal contingent on this list who assert that no
object should ever have an indefinite boundary. (Otherwise, there's a
clearly defined lock channel, and I'd have separated it.) Another
minor complication is that the lock channel is actually the river's
natural channel. Even downstream of the dam, the water is artificially
raised by the next dam downstream. The Thalweg still runs through the
lock, so that winds up being the linear way labelled, 'Mohawk River'.

One thing that I've not yet tried to duplicate in OSM that I see in
NHD there is that NHD has the concept of 'artificial shoreline'. You
can see in 
https://kbk.is-a-geek.net/catskills/test4.html?la=42.8039&lo=-73.8466&z=15
how much of the lock channel is rimmed in black instead of blue,
indicating the 'artificial shoreline' from NHD. I also haven't tried
to tag the structure that delimits the upstream anchorage. I'm
gathering from the Wiki that OSM wants it to be a groyne, or perhaps a
breakwater. It serves multiple purposes - it does reduce ice jamming
at the lock, and stabilize the shoreline against drift, but it also
creates an area of calm water for barges to anchor off (it used to be
that strings of barges that couldn't fit in the lock all at once were
routinely broken up and locked through one or two at a time.) The Wiki
descriptions of both of those structures are kind of salt-water
oriented.

You'll see on the north bank how the historic Erie Canal disappears at
the power house. Above the dam, it's under about eight metres of water
and doesn't resurface until Rexford
https://www.openstreetmap.org/way/164420515. Historically, it crossed
the river there on a stone aqueduct and continued on the south side.

The locks here are ... interesting. Vischer Ferry is 66 metres above
the Hudson, and that whole elevation change happens in only seven
locks. For locks 2-6, vessels must lock through the entire flight of
locks continuously, because there's no place to berth or anchor that
wouldn't obstruct traffic.

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

[Tagging] Feature Proposal - Voting - Landcover barren (second time)

[Lorenzo Stucchi]

Hi everyone,

after some comments in which we found that there was a misunderstanding in the 
definition, we rewrote partially it to be more clear, also with some images. So 
we start a new vote phase, here the new link 
https://wiki.openstreetmap.org/wiki/Proposed_features/Landcover_Barren#Second_Voting.
 Thanks to all the people that vote before, we would like to know now your 
opinion.

Best Regards,
Stucchi Lorenzo

Il giorno 24 apr 2019, alle ore 10:57, Lorenzo Stucchi 
mailto:lorenzostucch...@outlook.it>> ha scritto:

Hi everyone,

Since there is no more open discussion around this tag, we decide to pass to 
the voting phase. We are waiting for your opinions. This is inside the project 
about mapping 
deforestation
 from PoliMappers and researcher from Politecnico di Milano.

Vote here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Landcover_Barren

Best Regards,
Stucchi Lorenzo
___
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] Extremely complicated conditional values

[Richard]

On Thu, Apr 25, 2019 at 02:06:27PM +0200, Tobias Zwick wrote:
> Even shorter, because if there are conflicting rules in the conditional, the 
> last one is taken, says the wiki. (Not sure if this is really implemented in 
> applications that work with that data though):

just wondering, does anyone have an idea how far the software support for 
conditional goes?

Richard

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

[Tagging] unused tags and properties

[Martin Koppenhoefer]

A few people continue to add unused tags and properties to feature
definitions, e.g. looking at the page for tourism=guesthouse, which is
quite long in the meantime, you can find "proposed" values with names like
"fridge"
"stove"
"drying:room"
"dinner"
which all hardly reach a 2 digit number of usage.

https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dguest_house

For the "view" tag there isn't even a definition.

I believe treating the wiki like this will generally lead to a decline in
quality of our documentation, because immature tags are pushed that haven't
undergone any kind of peer review (aparently).

Am I the only one with these concerns?

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

Re: [Tagging] unused tags and properties

[Jean-Marc Liotier]

I agree. The wiki is a point of entry for inexperienced contributors and 
should therefore document established practices rather than serve as a 
way to make marginal ideas appear established.


That said, the subjectivity of what constitutes "established practices" 
guarantees controversy...



On 4/27/19 1:54 AM, Martin Koppenhoefer wrote:
A few people continue to add unused tags and properties to feature 
definitions, e.g. looking at the page for tourism=guesthouse, which is 
quite long in the meantime, you can find "proposed" values with names like

"fridge"
"stove"
"drying:room"
"dinner"
which all hardly reach a 2 digit number of usage.

https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dguest_house

For the "view" tag there isn't even a definition.

I believe treating the wiki like this will generally lead to a decline 
in quality of our documentation, because immature tags are pushed that 
haven't undergone any kind of peer review (aparently).


Am I the only one with these concerns?



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

Re: [Tagging] unused tags and properties

[Mateusz Konieczny]

27 Apr 2019, 01:54 by dieterdre...@gmail.com:

> A few people continue to add unused tags and properties to feature 
> definitions, e.g. looking at the page for tourism=guesthouse, which is quite 
> long in the meantime, you can find "proposed" values with names like
> "fridge"
> "stove"
> "drying:room"
> "dinner"
> which all hardly reach a 2 digit number of usage.
>
>
> https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dguest_house 
> 
>
> For the "view" tag there isn't even a definition.
>
> I believe treating the wiki like this will generally lead to a decline in 
> quality of our documentation, because immature tags are pushed that haven't 
> undergone any kind of peer review (aparently).
>
> Am I the only one with these concerns?
>
No, you are not the only one. In case of such barely used tags added in the 
form of 
an unreadable table I think that immediate revert of such edit is the best 
solution.

Inventing new tags is OK, using new tags is OK, documenting new tags is OK and 
desirable.

But linking your tag that is barely used everywhere is an unwelcome spam.

In such situation I revert edit as soon as I spot it, especially for users who 
did it already
many times and have aggressive usernames that claim to not be experts rather 
than newbies.

example of previous spam wave (mass spamming of broken shop=street_vendor tag):

https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Dvending_machine&diff=prev&oldid=1835047
 

https://wiki.openstreetmap.org/w/index.php?title=ES:Tag:amenity%3Dvending_machine&diff=prev&oldid=1835048
 

https://wiki.openstreetmap.org/w/index.php?title=FR:Tag:amenity%3Dvending_machine&diff=prev&oldid=1835049
 

https://wiki.openstreetmap.org/w/index.php?title=NL:Tag:amenity%3Dvending_machine&diff=prev&oldid=1835051
 

and in many other languages, also for other shop types
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging