[Tagging] Extremely complicated conditional values

[Paul Johnson]

Is there a condition value calculator that can help me come up with sane
tagging for this?

https://openstreetcam.org/details/955279/18672/track-info

This is a chart of advised speeds in MPH for HGVs on a motorway in Oregon
based on weight in pounds.  I'm at a complete loss of how to tag for this
save for conditional values but I am banging my head on coming up anything
cogent reading through
https://wiki.openstreetmap.org/wiki/Conditional_restrictions short of
maxspeed:advisory:hgv=18
mph (which technically fits the most stringent value but a little hamfisted
given that sign).

Can I get a hint on this?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] RFC - livestock_dip

[Warin]

Hi,

I have made some changes and advanced

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


to status proposed.


2 Problems I have with it ..


Type of dip


Rather than use livestock_dip 
=immersion/sprinkler 
, 
it might be best to use dip 
=immersion/spray 
? 
This stays away from the animal, concentrating on the 'dip' and 
identifies the process rather than the equipment.



Conflicting access tags


access =private 
 with horse 
=yes 
 
says, for OSM, it is private access but public for horses ... for us 
humans it is private for the use of horses.


A way around that is to not use horse=yes but something like 
animal/livestock=horse.


I prefer animal, as that can be used for pets, zoos etc, livestock is 
restrictive.



Livestock is used some 3,000 times .. no documentation that I could see, 
but it looks consistant.


Animal is used some 10,000 time .. poorly documented and used not only 
to specify the animal but facilities like school, wellness, swimming .. 
a very confused key!


I think the key animal needs a good clean!



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

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

[Paul Allen]

On Wed, 24 Apr 2019 at 23:07, Warin <61sundow...@gmail.com> wrote:

>
> The same can be said for a pub, restaurant, etc.
>   They are all  commercial enterprises, if they did not make money they
> would not exist.
>   There 'service' to the community is there to help them make money.
>

Mostly, but not always true of pubs.  In my area village pubs close and
never re-open.  Except,
in a few cases, the local community chips in and buys the pub to run it for
the benefit of the
community..  Here's an article for an attempt to make a pub a couple of
miles from me into a
community pub:
https://www.tivysideadvertiser.co.uk/news/17500848.st-dogmaels-residents-looking-to-run-white-hart-inn-as-a-community-pub/

Then there are (in the UK) Miners' Welfares and Working Men's Clubs which
are more amenity
than commercial organization selling alcohol.  Many pubs have some form of
gaming available
(snooker, pool, or darts).

In any case, a pub is an amenity in the way that a supermarket is not.  You
don't go to a
supermarket to spend hours chatting with your friends (unless you're one of
the several
idiots who use the same supermarket I do), but you do use a pub for that
place, making it
a place of leisure.

I'd argue that  pubs are better placed under amenity than shop.
Restaurants are a tougher call,
because they are often used for social occasions rather than just feeding
stations.

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

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

[Warin]

On 25/04/19 04:39, Dave F wrote:



On 21/04/2019 01:12, Warin wrote:



I am all for the introduction of the key education=*


It makes sense, adds detail - improves the map data base.


True.

The one that irks me is amenity=cafe. It isn't there for the benefit 
of the community; it is a commercial enterprise & should be tagged as 
a shop.


+1

The same can be said for a pub, restaurant, etc.
 They are all  commercial enterprises, if they did not make money they 
would not exist.

 There 'service' to the community is there to help them make money.

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

Re: [Tagging] Comments on documenting winter speed limits tagging

[Tobias Knerr]

On 04.04.19 13:33, Jyri-Petteri Paloposki wrote:
> The feedback was quite limited and you or anyone else expressed no
> definite stance against documenting the current practice.

At least in my case, that's because I expected my mail to be a
contribution to a discussion that would (hopefully) end with a
consensus. I did not interpret your original mail as a "call for vetos".

As it stands, there was no response to the criticism in the original
thread. Rather, a wiki page suddenly (from my point of view) came into
existence, and had I not pre-emptively added that page name to my wiki
watchlist, I wouldn't even know.

But enough about past misunderstandings, and thanks for summarizing the
discussion on #osm-fi. I can at least understand the reluctance to go
with conditional restrictions in that case. I do still wonder about the
reasons for ruling out the other alternatives, though. As I said before:

> On 3.4.2019 19.40, Tobias Knerr wrote:
>> Even if we keep "winter" in the key, the
>> ":seasonal" should definitely be dropped. After all, we use
>> maxspeed:forward (not maxspeed:directional:forward) and maxspeed:hgv
>> (not maxspeed:vehicular:hgv).

The pros and cons of conditions are more complex, but maxspeed:winter
seems like a straightforward improvement:

* It's shorter and simpler.
* It follows the same format as firmly established keys like
maxspeed:hgv or maxspeed:forward.
* It's a bit easier for data consumers because keys like
maxspeed:winter:forward are often handled by splitting at every ':'
character, which would also break apart the "seasonal:maxspeed".

So far, I believe, no one on this list has argued that
maxspeed:seasonal:winter is actually better (as opposed to more common)
than maxspeed:winter.

Yours,
Tobias

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

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

[François Lacombe]

Hi Dave

I'm happy to tag as canal the man_made space between two lock gates.
This is often concrete lined and sized accordingly to allow boats to pass
through.

The main difference with rivers going through cities is it's often the
original natural course.
A canal is built by man, Thames river wasn't built by man I think,
Locks usually does.

To me it's more confusing to tag lock gates and dams in waterway key
instead of man_made but it's another topic

All the best

François

Le mer. 24 avr. 2019 à 20:40, Dave F via Tagging 
a écrit :

> Hi
>
> This maybe UK specific but it's a tagging problem & maybe wider spread.
>
> To allow navigation, rivers occasional have lock gates, usually as a
> separate channel. Some contributors tag these incorrectly as
> waterway=canal for the centre line.
>
> https://www.openstreetmap.org/way/347369154
>
> However, they are still rivers, they just have canalized sections. If
> this logic was applied to all lengths of river every one that passes
> through a city, such as the East River, Seine or Thames would be tagged
> as canal, which is of course, ridiculous.
>
> Canals are man-made channels to allow water to flow where it naturally
> wouldn't
> If the locks were removed from rivers the water would still flow.
>
> Canal is a noun.
> Canalise is a verb.
>
> Cheers
> DaveF
>
>
> ___
> 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] Incorrectly tagging locks on rivers as canals

[Dave F via Tagging]

Hi

This maybe UK specific but it's a tagging problem & maybe wider spread.

To allow navigation, rivers occasional have lock gates, usually as a 
separate channel. Some contributors tag these incorrectly as 
waterway=canal for the centre line.


https://www.openstreetmap.org/way/347369154

However, they are still rivers, they just have canalized sections. If 
this logic was applied to all lengths of river every one that passes 
through a city, such as the East River, Seine or Thames would be tagged 
as canal, which is of course, ridiculous.


Canals are man-made channels to allow water to flow where it naturally 
wouldn't

If the locks were removed from rivers the water would still flow.

Canal is a noun.
Canalise is a verb.

Cheers
DaveF


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

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

[Dave F via Tagging]

On 21/04/2019 01:12, Warin wrote:



I am all for the introduction of the key education=*


It makes sense, adds detail - improves the map data base.


True.

The one that irks me is amenity=cafe. It isn't there for the benefit of 
the community; it is a commercial enterprise & should be tagged as a shop.


DaveF

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

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

[Valor Naram]

To your 4.: We need to get the developers to change their presets beforehand. Original Message Subject: Re: [Tagging] Why should we avoid overusage of amenity=* tag?From: Paul Allen To: "Tag discussion, strategy and related tools" CC: On Wed, 24 Apr 2019 at 10:16, Valor Naram  wrote:Deprecating "amenity" would hurt because it's a very important key. But I have some suggestions:There are cases where amenity is an appropriate tag.  Such as for amenities. 1. Keeping the "amenity" wiki page intact.2. Creating/extending pages for new keys e.g. Key:education3. Suggesting "education=*" instead of "amenity=education" on the "amenity" wiki page.3.5 Persuading developers of editors to prefer education=* to amenity=* when mappersselect "school," "university," etc.  Many mappers rely on editor presets and will only over-ridewhat those presets offer if they disagree with the tags the editor gives them.4. A transition period for changing the database and to aware other mappers of it.4 is feasible ONLY if the new education=* offers are 1-for-1 correspondence withamenity=* for educational facilities.  That is amenity=school can be directly and unambiguously replaced with education=* (possibly with sub-tags).  There can beno "it depends" situations if a bulk edit is to take place.  Otherwise it would have to bedone on a case-by-case basis.-- Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Allen]

On Wed, 24 Apr 2019 at 10:16, Valor Naram  wrote:

>
> Deprecating "amenity" would hurt because it's a very important key. But I
> have some suggestions:
>

There are cases where amenity is an appropriate tag.  Such as for amenities.

1. Keeping the "amenity" wiki page intact.
> 2. Creating/extending pages for new keys e.g. Key:education
> 3. Suggesting "education=*" instead of "amenity=education" on the
> "amenity" wiki page.
>

3.5 Persuading developers of editors to prefer education=* to amenity=*
when mappers
select "school," "university," etc.  Many mappers rely on editor presets
and will only over-ride
what those presets offer if they disagree with the tags the editor gives
them.

4. A transition period for changing the database and to aware other mappers
> of it.
>

4 is feasible ONLY if the new education=* offers are 1-for-1 correspondence
with
amenity=* for educational facilities.  That is amenity=school can be
directly and
unambiguously replaced with education=* (possibly with sub-tags).  There
can be
no "it depends" situations if a bulk edit is to take place.  Otherwise it
would have to be
done on a case-by-case basis.

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

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

[Valor Naram]

Good reasons were given here. I changed also my mind but there's the problem of how to deal with this problem.Deprecating "amenity" would hurt because it's a very important key. But I have some suggestions:1. Keeping the "amenity" wiki page intact.2. Creating/extending pages for new keys e.g. Key:education3. Suggesting "education=*" instead of "amenity=education" on the "amenity" wiki page.4. A transition period for changing the database and to aware other mappers of it. Original Message Subject: Re: [Tagging] Why should we avoid overusage of amenity=* tag?From: 石野貴之 To: "Tag discussion, strategy and related tools" CC: Thank you for the reply.> These difficulties, and opposing ideas on how to deal with existing tags, make it hard to change established tagging schemes. But I am strongly in favour of not establishing new amenity=* for hitherto unmapped facilites, but rather use new tags altogether, whose use can then be expanded into proper tagging schemes.I support your idea using new tags altogether with existing tags.Then, how about the following examples? Do you think them good ideas?   (a) office=educational_institution and education=cram-school for Japanese jukus aimed for entrance examinations.  (b) shop=computer and education=specialty if a computer shop provides a workshop to learn how to use computers.Takayuki Ishinoyumean1...@gmail.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting - Landcover barren

[Lorenzo Stucchi]

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