Re: [Tagging] [Talk-GB] Fords and how to provide information to help with routing apps

[Matija Nalis]

On Wed, 5 Jul 2023 18:00:26 +1000, Warin <61sundow...@gmail.com> wrote:
> On 5/7/23 03:38, Mateusz Konieczny via Tagging wrote:
>> ford=impassable makes no sense
>> ford is by definition a passable place across waterway, if
>> something is impassable then it is not a ford

Agreed... and when not passable by anyone, I wouldn't draw it on OSM as any 
highway=* way nor related points like ford=*.

However, if some traffic is NOT POSSIBLE but other traffic is, I'd probably 
still use access tags like foot=*,
bicycle=* etc. even if those are primarily for LEGAL restrictions.

E.g. if it is suicidal to try to cross such ford with bicycle there, I'd 
probably add bicycle=no.
I should point out that it works out here, where attempted suicide is illegal 
(and you'll get fined for it :-)
Otherwise tag purists would dislike it.

> Many 'fords' in Australia are normally dry.
>
> When the river runs high those fords can become impassable for quite 
> some time .. weeks..

Relatedly, there are:

https://wiki.openstreetmap.org/wiki/Key:intermittent
https://wiki.openstreetmap.org/wiki/Key:flood_prone
https://wiki.openstreetmap.org/wiki/Key:seasonal


which might be useful for such cases.

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] amenity=bbq without grill/grate ?

[Matija Nalis]

On Thu, 23 Feb 2023 18:50:21 -0500, Kevin Broderick  
wrote:
> It makes sense to me if the feature is clearly intended to be a
> BBQ/grilling one, but the grill is missing. One such example that comes to
> mind is a state park with picnic tables and grill boxes where 1/3 of the
> latter are missing the grills.

I think in such vandalized case it would be better tagged as
disused:amenity=bbq or abandoned:amenity=bbq 

(in much the same way as amenity=drinking_water which has been
broken/vandalized and no longer provides drinking water would be
disused:amenity=drinking_water instead of 
amenity=drinking_water + drinking_water=no)

-- 
Opinions above are GNU-copylefted.


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

[Tagging] [Voting] Deprecate maxspeed:seasonal:winter

[Matija Nalis]

Voting has started on the proposal to deprecate maxspeed:seasonal:winter.

Please vote on the wiki page 
https://wiki.openstreetmap.org/wiki/Proposal:Deprecate_maxspeed:seasonal:winter

(posted here by request of arrival-spring in 
https://community.openstreetmap.org/t/voting-deprecate-maxspeedwinter/99863)


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Matija Nalis]

On Thu, 20 Apr 2023 00:47:21 +0200, Marc_marc  wrote:
> Le 19.04.23 à 14:19, Matija Nalis a écrit :
>> I think that my point remains that:
>> - one method is clear and unambiguous ("fuel:lpg=no")
>> - one method is not clear / is ambiguous ("fuel=octane_98;diesel").
>> 
>> So the first one should be preferred. Does that make sense?
>
> - one is a nightmare for datause
> - one isn't a nightmare for datause
> So the 2nd one should be preferred. Does that make sense?

Hmm, no, not at all (if ordering of your sentences is same as mine at the top 
quote)? 

I'll assume that by "datause" you mean something like computer storing
data in some kind of database for purpose of retrieving / searching /
updating those values and operating on them (i.e. using them)?
(Or did you have some fundamentally different definition from that one in mind?)

Databases which I am familiar with (mostly relational SQL-based and other
databases which should be most relevant here for OSM uses, but also others
like non-relational key-value datastores) are MUCH happier with first
("fuel:lpg=no") than with second ("fuel=octane_98;diesel") case.


- in "fuel:lpg=no" case it is VERY efficient and fast (using const lookup
  on composite index [key,value]) to look for e.g.

  SELECT * from t where key = "fuel:lpg" and value = "yes";

- however, trying to do that lookup for second example
  ("fuel=octane_98;diesel"), you would have to use:

  SELECT * from t where key = "fuel" and value like "%lpg%";
  
  which is much more inefficient (would need to do fulltext column scan
  instead of using index, because of leading wildcard in that "%lpg%".
  
  Also, it would need either post-processing filter outside of database
  server (or alternative using even more expensive multi-condition or even
  regex match!) to get rid of false positives matches like (hypothetical)
  "fuel=diesel;motolpgane" e.g. you'd actually need extra 2 conditions:

  SELECT * from t where key = "fuel" and (value like "lpg;%" or value like 
"%;lpg;%" or value like "%;lpg")
  
  Not to mention that if you wanted to look for more than one fuel type,
  you'd have to have even more kludges (like postprocessing outside of
  database server), instead of simple `where key like "fuel:%"` in first
  case (which would also still be able to use your composite index!)

  Relational database design theory explain why storing multiple values in
  one column (like in "fuel=octane_98;diesel" case) is a very bad idea
  (e.g. that way of tagging breaks 1NF, see for example
  https://en.wikipedia.org/wiki/Database_normalization#Satisfying_1NF)

So, I'm totally confused why would you think that "fuel:lpg=no" +
"fuel:diesel=yes" method would be a "nightmare" for datause, or that
"fuel=octane_98;diesel" would be a good idea from datause perspective?


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Proposed automated edit of some barrier=kerb kerb=raised nodes (forum crosspost)

[Matija Nalis]

On Wed, 19 Apr 2023 09:23:42 +0200, Marc_marc  wrote:
> Le 19.04.23 à 03:04, Matija Nalis a écrit :
>> following the automated edit code of conduct?
> following it mean to use the correct place for that : the talk ml :)

Oops, sorry, wrong OSM ML starting with "ta". :)
Now posted at correct place 
https://lists.openstreetmap.org/pipermail/talk/2023-April/088184.html

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Matija Nalis]

On Wed, 19 Apr 2023 13:17:41 +0200, Niels Elgaard Larsen  
wrote:
> Matija Nalis:
>> e.g. if "fuel=octane_98;diesel" was tagged, it would be ambiguous - does
>> it mean that there there is no LPG, or that the mapper didn't care to survey
>> that separated area of fuel station where LPG is being held?
>
> I do not believe that is how most of us are using it.

Hm, I do, but as it would be rather hard to prove (and such proof is not
paramount here), lets us just agree that it is how certain amount of
mappers use it (without trying to quantify it with subjective guesses).

I think that my point remains that:
- one method is clear and unambiguous ("fuel:lpg=no")
- one method is not clear / is ambiguous ("fuel=octane_98;diesel").

So the first one should be preferred. Does that make sense?

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Matija Nalis]

On Wed, 19 Apr 2023 13:17:41 +0200, Niels Elgaard Larsen  
wrote:
> Matija Nalis:
>> e.g. if "fuel=octane_98;diesel" was tagged, it would be ambiguous - does
>> it mean that there there is no LPG, or that the mapper didn't care to survey
>> that separated area of fuel station where LPG is being held?
>
> I do not believe that is how most of us are using it.

Hm, I do, but as it would be rather hard to prove (and such proof is not
paramount here), lets us just agree that it is how certain amount of
mappers use it (without trying to quantify it with subjective guesses).

I think that my point remains that:
- one method is clear and unambiguous ("fuel:lpg=no")
- one method is not clear / is ambiguous ("fuel=octane_98;diesel").

So the first one should be preferred. Does that make sense?

-- 
Opinions above are GNU-copylefted.


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

[Tagging] Proposed automated edit of some barrier=kerb kerb=raised nodes (forum crosspost)

[Matija Nalis]

In 
https://community.openstreetmap.org/t/proposed-edit-of-some-barrier-kerb-kerb-raised-nodes/98038
user @osmuser63783 proposes proposed automated edit:

--
If you’ve been reading my posts about kerb tagging (1, 2), then you already 
know that StreetComplete places kerb=raised by itself on a node where a footway 
meets a road to mean “you might expect a crossing and lowered kerb here but 
there isn’t one”. Whether there are better ways of tagging this is currently 
being discussed here. The problem is that iD users have added barrier=kerb to 
such nodes because the validator in iD told them to. This leads to issues, 
because it’s interpreted as a raised kerb across the road. For example it stops 
OSRM from routing cars along the road.

The good news is that new nodes like this will no longer be created because of 
a recent change in iD, disabling the suggestion to add barrier=kerb to such 
nodes. I’m grateful to everyone involved that this has been fixed so soon after 
I spotted it.

The bad news is that there are now about 1,500 nodes tagged barrier=kerb 
kerb=raised that really shouldn’t have the barrier=kerb tag.

How would people feel about editing them all in one go, following the automated 
edit code of conduct?

I propose doing something like this

use Overpass (query) to get all barrier=kerb kerb=raised nodes on roads 
(i.e. highway ~ 
trunk|trunk_link|primary|primary_link|secondary|secondary_link|tertiary|tertiary_link|unclassified|residential),
 there are 1495 of them
check a few dozen manually and only proceed if they are clear tagging 
mistakes
for each suspicious node, retrieve the history (example API call)
find the changeset that added barrier=kerb; retrieve the changeset metadata 
(example API call) and see if it was created_by iD with 
resolved:outdated_tags:incomplete_tags >= 1
if yes, go back further in the changeset history to find the changeset that 
added kerb=raised; retrieve the changeset metadata (example API call) to see if 
it was created_by StreetComplete with comment “Add whether there is a crossing” 
or “Specify whether there are crossings at intersections of paths and roads”
generate a couple of OSC files, e.g. one for each grid square (which 
resolution is appropriate? in other words, how many changesets should there be 
vs. how big should they be?)
upload here for scrutiny and check manually, then after people have had a 
chance to check it, commit using JOSM, with a changeset comment linking to the 
discussion, etc.

Importantly, this excludes all situations where barrier=kerb was added before 
or at the same time as kerb=raised, or where they used a different editor than 
iD, or where kerb=raised wasn’t added by StreetComplete. We don’t want to retag 
anything where a human set the barrier=kerb tag on purpose.

It would require a few read-only API calls (no more than 4500) that could be 
spread out over a few hours to make sure that service levels are not affected.

Why not create a Maproulette challenge?

I don’t have any experience with Maproulette, but from what I can see, I think 
it works best when some human intervention is required. Using the steps above 
we should be able rule out that someone added the barrier=kerb on purpose to 
mean that there is a kerb across the road, so checking each one manually would 
not be a good use of anyone’s time.

Any thoughts on this?

[1] https://community.openstreetmap.org/t/tagging-kerbs-on-crossings/9290/
[2] 
https://community.openstreetmap.org/t/improving-the-wiki-documentation-of-barrier-kerb-and-kerb/97042
--


(posted for more visibility in tagging ML on @osmuser63783 request so people 
wouldn't get surprised. Go to top URL for better formating with all the links)

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Is tagging of fuel: assumed to be exhaustive?

[Matija Nalis]

On Tue, 18 Apr 2023 17:08:39 +0200, Marc_marc  wrote:
> Le 18.04.23 à 16:53, Mateusz Konieczny via Tagging a écrit :
>> Is tagging of fuel: assumed to be exhaustive?
>
> no, some contributors will fill in what they are interested in,
> others will fill in everything that is visible (and may not
> be able to see the blue additive pump not visible from the car pumps), 
> others will do an exaustive survey

Agreed.

IMHO basically the main reason why multi-tag standard (e.g. fuel:octane_98=yes,
fuel:diesel=yes, fuel:lpg=no) was invented is precisely because in
multi-value system it would have been impossible to mark the difference
between "this fuel is not present" and "it is unknown/unsurveyed if this fuel
is present here", i.e. it would make a pressure on mapper to either:
- invest a lot of time to map EVERYTHING, or
- better map NOTHING if they didn't have that time (in order not to create more
  confusion / false data)

e.g. if "fuel=octane_98;diesel" was tagged, it would be ambiguous - does
it mean that there there is no LPG, or that the mapper didn't care to survey
that separated area of fuel station where LPG is being held?

With multi-tag standard it is unambiguous, and users may map as much or as
little as they want, and other people can iteratively improve later according
to their preferences. 

E.g. if I just tanked diesel into my HGV on some fuel station, I can add tag
"fuel:HGV_diesel=yes" and go on my way (or mark "fuel:HGV_diesel=no" if I see
that this fuel station is useless for me), knowing that next time I need it
the map would be more useful to me and other HGV drivers, and *without*
having to take a walk and map every other type of fuel available to regular
car drivers (unless I want to and have time to kill)...

So, if it is tagged "fuel:lpg=no", it means there is no LPG there, if it is
tagged "fuel:lpg=yes" it means there is LPG there, and if "fuel:lpg=*" is
missing completely, it means it is (currently) unsurveyed (and should be
surveyed if one cares about LPG availability).

As a sidenote, another (much less important in practice, but potentially
problematic as number of values grew) advantage of multi-tag standard was
that the limit of max. 255 chars per tag is avoided)


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Difference between graffiti and mural

[Matija Nalis]

On Sat, 15 Apr 2023 20:51:57 +0200 (CEST), Mateusz Konieczny via Tagging 
 wrote:
> why only "notable"?

I guess it might be because otherwise one might encourage putting 
"tourism=artwork" + "artwork_type=graffiti"
every few meters on any random piece of street furniture, bridge, walls, 
subways, etc.

e.g. I personally would not map things like this:
https://commons.wikimedia.org/wiki/File:Graffiti_on_a_mailbox.jpg
as "tourism=artwork" + "artwork_type=graffiti"


and that does not seem very useful or desirable (IOW, while I would call that 
type of vandalism "graffiti", I would not call it "artwork" of any type)

While there are other (more artistic) types of graffiti that might be useful to 
map, e.g.:
https://commons.wikimedia.org/wiki/File:Graffiti_protesting_violence_in_Medell%C3%ADn.jpg


-- 
Opinions above are GNU-copylefted.


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

[Tagging] [RFC] Feature Proposal - Public Transport: Auditory Information

[Matija Nalis]

This proposal aims to establish multiple tags to gather different types of
auditory information that may be provided at a public transport stop and/or
platforms.

It is being discussed at:
https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport:_Auditory_Information

[forwarding on Tagging ML for original author who is having list issues]

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] tactile_paving=* on highway=steps ?

[Matija Nalis]

On Thu, 23 Feb 2023 12:46:07 +0100, Matija Nalis 
 wrote:
> Triggered by this StreetComplete quest suggestion:
> https://github.com/streetcomplete/StreetComplete/issues/3534

FYI, it is also being discussed at:

  
https://wiki.openstreetmap.org/wiki/Talk:Key:tactile_paving#how_to_mark_on_steps%3F
  https://community.openstreetmap.org/t/tactile-paving-on-highway-steps/9215


-- 
Opinions above are GNU-copylefted.


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

[Tagging] amenity=bbq without grill/grate ?

[Matija Nalis]

Recently, https://wiki.openstreetmap.org/wiki/Key:grate has been documented
with some 232 uses, to map whether `leisure=firepit` and `amenity=bbq` have a
grate (AKA cooking grate / grill / cooking grid).

While it might be useful for `leisure=firepit`, I do not think it makes sense
for `amenity=bbq` at all. 

BBQ grill is a place that has some way to contain a fire and a grill/grate/grid
on which food is cooked. If it misses that grill, then it in my opinion can
hardly be classified as `amenity=bbq`, but is instead fire ring / fire pit
(see https://en.wikipedia.org/wiki/Fire_ring) which is according to wiki to be
tagged as `leisure=firepit` instead.

Who do others think? does `amenity=bbq` + `grate=no` make any sense to you, or
should it be documented as discouraged?

-- 
Opinions above are GNU-copylefted.


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

[Tagging] tactile_paving=* on highway=steps ?

[Matija Nalis]

Triggered by this StreetComplete quest suggestion:
https://github.com/streetcomplete/StreetComplete/issues/3534

I was wondering how people would prefer to tag tactile paving which is often 
present 
at bottom and top of the `highway=steps` (pictures in link above)?

It seems to me `tactile_paving=*` would be best added at a start and end
node of that `highway=steps` way (i.e. similar to how it is mapped on `kerb=*`
for crossings) as it is most precise, but there seems to be some 28k+ uses
(according to https://taginfo.openstreetmap.org/tags/highway=steps#combinations)
of marking `tactile_paving=*` at the `highway=steps` *way* itself. 

I can se how that would be easier, but seems somewhat incorrect (as the tactile
paving does not follow that way, as it often does `highway=footway`).

So, which people prefer?

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] [RFC] Feature Proposal - Replace `*:signed` suffix key with `signed:*` prefix key

[Matija Nalis]

On Fri, 17 Feb 2023 03:10:31 +0100, Marc_marc  wrote:
> Le 17.02.23 à 01:38, Matija Nalis a écrit :
>> Cross-posting from the forum:
>
> thanks... we see the community split :
> no reply from the other to the previous message
> due to the fragmentation of several unconnected
> interface
>

Yes, that is unfortunate. :-(
Hopefully at some time in the future ML and forum will be automagically merged, 
so it might heal.

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] dry swamps

[Matija Nalis]

On Fri, 17 Feb 2023 21:08:17 +1100, Warin <61sundow...@gmail.com> wrote:
> On 17/2/23 12:13, Matija Nalis wrote:
>> I see few options. If it happens more regularly, map as:
>>
>> - If it happens more regularly, map as: natural=wetland + intermittent=yes
>> - if they very rarely (if ever) become waterlogged, mark them whatever they 
>> are currently (or most of the time).
>> - see what other similar features in the region use, and copy/paste that.
>
>
> In one part I have previously tagged one of them, thinking it was a rare 
> thing I used a square peg in a round hole... but 4,000 of them in one 

So, were any of that 4000 tagged in OSM, and if so, how?

> state of Australia, with more of them in other parts of Australia and 
> yet more in other parts of the world I think that means there should be 
> suitable tags for them not some stop gap tagging.

In OSM, things get mapped when someone care about them.
It is quite possible nobody cared enough about the distiction between "dry 
swamp" and 
for example "natural=wetland" + "intemittent=yes" to map that differetly.

If you do care about those for whatever reason (most often people map things
because they already have or at least envision an usecase of using that data),
I'd suggest proposing the solution you would prefer. 
Instructions on doing so, if you are interested, can be found here:

https://wiki.openstreetmap.org/wiki/Proposal_process


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] dry swamps

[Matija Nalis]

On Sat, 11 Feb 2023 21:07:22 +1100, Warin <61sundow...@gmail.com> wrote:
> The ‘dry swamp’ has no apparent way to tag it. These will not be found 
> in Europe, just as you don’t find deserts there.
>
> They have occasional water, not seasonal, not yearly but, say, between 5 
> to 20 years they have water. As such they do not satisfy the OSM swamp 
> definitions at all.

I see few options. If it happens more regularly, map as:

- If it happens more regularly, map as: natural=wetland + intermittent=yes
  there even exist few cases of "wetland=dry", so you may add that (or 
something similar) too.
  
  Yes, I know that "natural=wetland" tag talks about "seasonal", but note the 
"intermittent=yes" changes the meaning of
  the main tag significantly. There are even things which are normally (without 
intermittent tag) ALWAYS full of water
  (like rivers and lakes), but intermittent=yes changes what they are:
  
  https://wiki.openstreetmap.org/wiki/Key:intermittent
  
- if they very rarely (if ever) become waterlogged, mark them whatever they are 
currently (or most of the time).

  After all, you wouldn't mark say Fukushima as wetland, because due to its 
location and climate it is prone
  to tsunami and flood disasters.
  
  So, if there are trees, mark as natural=forest. If grass, landcover=grass. If 
no vegetation then natural=desert. etc.
  Add human readable description=* mentioning the rare floods when it becomes 
swamp.
  
- see what other similar features in the region use, and copy/paste that.
  Even if it is slightly wrong (or with time better solution becomes 
available), 
  someone writing a bot to autocorrect will need to fix those other features too
  so will fix yours too.



-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] [RFC] Feature Proposal - Replace `*:signed` suffix key with `signed:*` prefix key

[Matija Nalis]

Cross-posting from the forum:
https://community.openstreetmap.org/t/rfc-feature-proposal-replace-signed-suffix-key-with-is-signed-prefix-key/8459/45

Voting on 
https://wiki.openstreetmap.org/wiki/Proposed_features/Replace_*:signed_with_is_signed:*
 
has now started.


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] tagging the diameter of a mini-roundabout

[Matija Nalis]

If the actual issue is that HGV cannot pass some road, why not simply mark it 
as 
`hgv=no`? Besides being simple, it has the additional advantage that routers
will actually already use it and direct HGVs somewhere where they can actually 
pass.

Or if some lenghts of HGVs can pass, but others not, then maxlength=* 
or maxlength:hgv=* or some of the other alternatives from 
https://wiki.openstreetmap.org/wiki/Key:maxlength ?

On Wed, 25 Jan 2023 21:25:32 +0100, Volker Schmidt  wrote:
> I see that I was not precise with my question: I am after a way to tag the
> overall diameter of the round surface composed of the mini-roundabout road
> surface plus the traversable central part. This is an important measure for
> trucks. I happen to live near one of these with an outer diameter of 12 m,
> and that attracts regularly articulated lorries like the cheese attracts
> flies. This triggered the question.
>
> Il giorno mer 25 gen 2023 alle ore 19:10 Peter Neale via Tagging <
> tagging@openstreetmap.org> ha scritto:
>
>> According to the Wiki (with which I happen to agree), a mini-roundabout is
>> defined as:
> >
>> "...a special type of roundabout in which the middle can be traversed
>>  by vehicles, and is
>> typically used where there is only limited space available. Road traffic
>> flows in one direction around a point in the middle and the traffic in the
>> roundabout has right-of-way. The middle of a mini-roundabout is usually
>> only a painted circle, but there might also be a low, fully traversable
>> (mountable) dome or island."
> >
>> As it is traversable, does it really have a diameter?  Or, if there is a
>> painted circle (are traversable domed area) on the ground, perhaps that has
>> a diameter, but does it matter to any prospective map user?
> >
>> Regards,
>> Peter
> >
>> Peter Neale
>> t: 01908 309666
>> m: 07968 341930
> >
> >
>> On Wednesday, 25 January 2023 at 17:53:55 GMT, Volker Schmidt <
>> vosc...@gmail.com> wrote:
> >
> >
>> Is there an established way to tag the diameter of a mini-roundabout?
> >
>> We have the tag diameter, but I could not find it applied to
>> mini-roundabouts.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> >


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Sat, 19 Nov 2022 17:54:42 -0800, Minh Nguyen  
wrote:
> Vào lúc 17:24 2022-11-19, Matija Nalis đã viết:
>> Because, someone has to do that summarizing work for extra channels to make 
>> sense, and it is IMHO only fair that would
>> be proposal author (expecting that EVERYBODY will do that SAME task is both 
>> extremely wasteful, hugely unrealistic,
>> and likely to lead to few participating members willing to do that becoming 
>> burned out prematurely).
>
> Practically speaking, no one can fully understand the discussion in 
> every community. That's a much higher bar than just announcing something.

That is true. But if not even the proponent is equipped/willing to do that,
what are the chances that majority of wiki commenters/voters will be
able/willing to do that? Surely even lower.

> For example, I think it would be perfectly reasonable to alert OSM Japan 
> Slack about my next proposal, but my nonexistent Japanese skills would 
> be catastrophically inadequate to capture the sentiment there. It would 
> be better to candidly state upfront that I'm unable to respond to 
> individual comments there and direct interested mappers to the wiki talk 
> page, where hopefully others can engage as necessary.

That is OK, when it is just read-only announcement, and interested people
are pointed to go to wiki talk page and comment there.

Problem arises when there is discussion on that extra channel and not on wiki
talk page, and nobody forwards it to the proposal wiki talk page, so majority
of people never know that there even was such a discussion, much less what was
suggested.

> All too often, a proposal announcement on this list ends with an 
> exhortation to comment on the wiki talk page, inevitably leading to a 
> long thread here instead. Where is the requirement to summarize the 
> tagging list thread, for the benefit of ordinary mappers who will be 
> voting but can't easily follow Mailman's deeply nested threads split 
> across monthly archives? 

I would recommend that proponent summarize mailing list discussion too, yes.

(although it is arguably somewhat less important when it is only official 
 communication channel, but it would become much more important if other
 official channel were added, as then there would be 50-50 [or whichever]
 chance that the voter did not follow "the other" channel)

Related: I actually find rudimentary mailman web interface more usable 
than Discord for reading tagging proposals. It has nice and easy visual 
threading, and web browser automatically indicate read vs. unread articles 
(even if you did read them in logical, instead of chronological way!), and I 
can much easily open interesting messages in extra tab for later perusing
(without them being mixed up). 
Also, I personally did not find the fact that every month I have to click few
extra times to continue following thread that big an issue (especially
considering all the work that *actual reading* of those dozens of messages 
each month pose by itself!)
(of course, I still prefer news.gmane.io NNTP interface to mailman archive, 
but as mentioned previously, that is likely too arcane suggestion for new
users born into wait-whatdoyoumean-internet-is-more-than-just-www generation :-)

> After all, the proposal guidelines have never required _voters_ to subscribe
> to the tagging list.

And those who didn't follow ML suggestions (and when it wasn't summarized in
wiki), invariably produced less useful input. 

Note that I find voting part of proposal actually unimportant in itself; that
is, important only as it:

- forces proponent to actually pay atention to the suggestions made earlier in 
the RFC
- provides a final date for closure (i.e. discussion not dragging on endlessly)
- weeds out proposals for things that nobody actually care enough even to come 
to vote yes

> Maybe a better model would be for each community to take some of the 
> burden off the proposal and have one or more self-appointed liaisons 
> handle announcements and communicate the most salient ideas back to a 
> single source of truth (the wiki, or wherever we decide to hold votes in 
> the future). This would apply to the tagging list as well as the 
> community forum.

That is a good idea! I've tried to suggest something similar with my
co-proponent comments. The main issue there IMHO is that of "Bystander effect"
https://en.wikipedia.org/wiki/Bystander_effect

I.e. unless someone is explicitely mentioned by name in the proposal as
liason for some group (and of course accepts such responsibility!), 
it is quite likely that nobody would actually do it.

And if they accept that obligation, they should be hold to their word; so my
suggestion was to name them as co-proponents, even if their work would be
mostly communication and not technical writing about the topic (even it

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Sun, 20 Nov 2022 10:01:23 +0100 (CET), Cartographer10 via Tagging 
 wrote:
>> Question is: did you then collect all the points those extra communities 
>> made (both those you agreed with, and those
>> that you didn't agree with), and summarized them on wiki /talk page, for 
>> extra period of RFC? Because if you didn't
>> (especially if you didn't include things you _disagreed_ with) then you 
>> abused that input to promote your personal view,
>> and disregarded the best parts that such other views could provide.

> The proposal has a section "external discussion". There the largest external 
> discussions are listed. These are all
> publicly accessible sources so people can read what has been discussed there. 
> I have also send updates when I changed
> major things in the proposal. I can image if you announce it on a closed 
> platform like Discord, that a summary on the
> talk page can be useful. 

It has. I'm not implying that you're trying to hide evidence by omitting those 
sources. :-)

I'm pointing out that:

- the proponent will have to scan those external threads anyway

- it is huge waste of everyones time if *each and every other contributor* has 
to scan those 100+ posts threads again
  for themselves to extract 2-3 possibly useful suggestions in order to suggest 
improvements. (for recent examples, see
  "highway=scramble" and related threads). As such requirement of general OSM 
population would hugely reduce number of
  people putting an effort, and thus result in much lower quality of proposal 
changes (people wasting time on asking
  for already explained things, good suggestions being ignored), and finally in 
voting not being based on available
  input (as it was too hard to process in fullness for average wiki voter), or 
even giving up totally on proposal
  process.
  
- thus, it would be much better if proponent (who have already invested time in 
processing those external sources)
  would summarize that 2-3 suggestions on proposal talk page, and invite people 
for extra RFC commenting on those
  suggestions too. 
  Even in cases when they are publically accessible to everyone (and of course 
always when they are not!)

That is my suggestion on proposal process improvement; and it would allow for 
"legalizing" adding extra external
discussions as regular people would not be burdened by being required to follow 
them, as the onus would be put
on proponent to summarize those on proposal wiki talk page.

>> I can imagine quite bad things, but to be fair, here is a most realistic one 
>> instead: On each changing of status quo,
>> some people will leave the process for good, as that will be the straw that 
>> broke the camel's back. If you need to
>> learn from history, see the debate when OSM changed license from CC-BY-SA to 
>> ODbL. And then, if another proposal
>> changes situation back to what it was before, that will NOT cause (majority 
>> of) people that left to come back.
>> It will instead cause some MORE people to leave for good (in revolt).

> There are always people who don't agree with a change. EVERY proposal or 
> changes has that. If more then 75% of the
> people agree you can assume that enough people support it. And of course, 
> taking the status quo into account is

Sure. I'm just explaining why "well we can change it, and then change it back 
if it doesn't work" has a serious
consequences, as the initial suggestion did not seem to consider them (i.e. 
"What is the worst thing that can happen?")

> important. However, if you can't change the status quo, you never move 
> forward.

Agreed. That is why I am (still) offering suggestions how to move forward, 
instead of being silent until voting period
and casting "no" vote without wasting time on participating in discussions.

At the end, related quote by G.B. Shaw for some smiles:

"Reasonable people adapt themselves to the world. Unreasonable people attempt 
to adapt the world to themselves. All
progress, therefore, depends on unreasonable people."

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Sun, 20 Nov 2022 19:10:07 +0100 (CET), Mateusz Konieczny via Tagging 
 wrote:
>> the first and foremost reason for the tagging mailing list to exist was the 
>> desire to offload tagging discussions on a central place, off the other 
>> channels, because people there felt overwhelmed with the discussions needed 
>> to agree on tags to describe the whole world, and it seemed helpful to 
>> reduce the volume on the talk list to a size that can be followed with 
>> significantly less dedication of time. Moving back to discussing tagging 
>> everywhere will make these other channels less useful for some people, I 
>> guess. Maybe this is unfounded because it came out, tagging is relevant all 
>> over OpenStreetMap (i.e. tagging discussions already happen on all channels, 
>> lately even on osmf-talk) and you can hardly ignore it, and because the 
>> structure of the contributors has changed, or something like 
> The new forum may be also more capable of handling large volume of posts - 
> you can
> easily mute threads and entire categories.

"muting categories" is "unsubscribing from that specific mailing list", right 
(e.g. I can decide to unsubscribe from
"Tagging" or from "Talk-hr" or whichever other list)?

I don't particularly like Discourse "you are subscribed to everything by 
default" philosophy either, as I much prefer
"opt-in" methods like in mailing lists. While you can mute a category (and 
repeat that as new categories get created),
it is annoying (and not easy to find about and actually use -so much about it 
being "newbie friendly"). 

While I find some Discourse features useful (liking posts, multi-post-quoting, 
@mention), others are quite bad:

- horribly confusing replying UI (I guess vast majority of users incorrectly 
replies to whole thread istead of the
  message, and never find an option to create subthread / reply in new linked 
topic)
- horrible thread / subthread following (with no multi-layer threading support)
- no *visual* "threading tree" indication (who replied to what), without doing 
manual tree reconstruction by clicking
  on all posts arrows manually. Even (argumably very rudimentary) Tagging 
mailing list archives do it much better
- practically nonexistent scoring (you can bookmark a specific post, and even 
that in almost unusable way) 
  (mail or news clients can do so much much more to make it usable, especially 
if thread continues for *weeks*)
- no message filter (and lacking search)
- only one discussion (with horrible "drafts" implementation which fails in 
painful ways if one has more than one tab
  open. Even old forum was much much better here!)
- inability to treat different categories differently (yes I can track/watch 
the topic, but I can't make watched topics
  in Talk-hr behaving differently than watched topics in Tagging; and I'd very 
much want to -- alternative is falling
  back to lowest common denominator, which doesn't work well)
- javascript requirement (and accessibility issues)
- GUI requirement
- inability to change UI to access same data (as oposed to mailing list, where 
if I don't like one mail user agent, I
  (or anyone else) can easily switch to another one. Discourse is forcing 
"one-size-fits-all", even if it doesn't fit
  you in particular).

to name but a few.

In short, I find Discourse work well for short discussions (up to max. 10-15 
messages), but becomes totally unusable on
bigger threads esp. with subthreads (e.g. highway=scramble discussion with 100+ 
messages). As tagging topics are more 
likely to produce bigger discussions, I find Discourse poor match for that 
specific purpose. It might be quite better
match for very-low-traffic regional mailing lists (like my country own 
Talk-hr). 

> As result massive posting in one thread is easier to ignore in its entirety.
>
> This is in theory achievable with filtering and so on, but much harder to 
> apply in
> practice, with mailing lists.

I guess it might depend on mail user agent being used. It should be very easy, 
e.g.:
https://support.mozilla.org/en-US/kb/ignore-threads

With advantages that one can also ignore certain sub-threads only if one so 
chooses.

(note that I'm using more advanced client than that, but for example choose 
Mozilla Thunderbird as common, free, and
easily available newbie-friendly MUA, which still has that feature implemented 
much better than Discourse)

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] wheel baths for disinfection

[Matija Nalis]

On Mon, 21 Nov 2022 08:58:29 +0800, Timeo Gut  wrote:
> Wheel baths for disinfection are used to prevent the spread of diseases 
> in agricultural areas. They're most often found at roads and tracks that 
> go through plantations or farms but sometimes also at administrative 
> boundaries along major highways.
>
> I'm thinking that highway=wheel_bath might be better suited. Any 
> thoughts on this?

Perhaps.

There were related discussion recently about similar decontaminations used for 
pedestrains
(i.e. 
https://wiki.openstreetmap.org/wiki/Tag:man_made=footwear_decontamination) and 
other 
cleaning facilities that might be accompanied by bigger tag:

https://community.openstreetmap.org/t/what-key-should-be-tagged-for-these-amenities/5598/5

so you may want to look there.

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Power utility office

[Matija Nalis]

On Sat, 19 Nov 2022 08:52:45 +0200, Dimitar  wrote:
> > What evidence do you have that is the case?  What is being provided is 
> > energy, not power.
>
>  From Cambridge dictionary:
> energy - the power from something such as electricity or oil that can do 
> work, such as providing light and heat
>  From Meram-Webster
> energy - usable power (such as heat or electricity)

which both reinforce that "energy" is correct word for, well, different types 
of energy.

> > ...and if we mean electricity, why not use that in the tag?
>
> Because the current value has been documented by someone in 2016 when it 
> had about 100 uses or less.

I think the question was about your proposal, i.e. why "office=power_utility" 
if something like
"office=electrical_utility" or similar would be much clearer. But it does not 
matter IMHO, as I think 
that tag is to narrow

> > There is no subsidiary.
>
> Then using office=utility + utility=gas;power might be a good idea. What 
> do you think?

Yes, such more general tag would cover it.

However 2 important points:

- while office=utility is actually already used (but undocumented), its usage 
is tiny,
  with just 107 uses (compare that to "office=water_utility" with 2500+ uses 
and wiki documentation, 
  and "office=energy_supplier" with 4700+ uses and wiki documentation)
  
  https://taginfo.openstreetmap.org/keys/office#values
  
- while adding tags for things that nobody has yet ever mapped is small and 
adequate for proposal process,
  cost of CHANGING the existing situation is MUCH higher. See
  
https://community.openstreetmap.org/t/changing-rfc-time-for-proposals-including-deprecation/5661/2
  for details.

So it must be calculated if benefits outweigh the costs. 

Given the conversation exchanged so far, I think that the costs are much higher 
than the potential benefits.

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Fri, 18 Nov 2022 19:21:07 -0800, Minh Nguyen  
wrote:
> Vào lúc 17:39 2022-11-18, Matija Nalis đã viết:
>> 1 on twitter and 2 on OSM Diary of proposer. Do you spot the problem here?
>> Because I do.
>
> No one has seriously proposed to make a Twitter announcement part of the
> standard operating procedure for RfCs or votes, whereas someone did seriously
> propose Discourse. Even a slippery slope can have some tactile paving. ;-)

Just wait, it will be suggested soon now that Elon Musk has bought it :-)

>> Like, for example, I'm reading and writing this on NNTP (Usenet News) gateway
>> news.gmane.io, which *is* properly integrated with tagging mailing list.
>> Everything I write here, people will see in their Mail clients, and 
>> everything
>> they reply I will see in my News client.
>
> Yet I recognize that such an arcane configuration cannot possibly get us 
> closer to a goal of ensuring that tagging discussions reach and engage a 
> broad cross section of ordinary mappers and data consumers. That must be 
> our goal; otherwise, the most electorally successful tagging proposal 

Sure. I didn't mean to propose that people should use NNTP to access tagging
proposals (although it does works beautifully for those who are willing to
try!), but to bring up an bright example how external service (like gmane NNTP)
could be seamlessly and correctly integrated with existing Tagging mailing list.

If NNTP server can be integrated with mailing list correctly, so can Discourse.
Although I acknowledge it needs some work (proper message referencing and
standard ">" quoting comes to mind), it is far from impossible, and would IMHO
be a great strategy for bringing two communities together WITHOUT either "side"
screaming "bloody murder!"

> could still fail to gain traction among the audiences that matter most, 
> undermining the proposal process. Any temporary fragmentation ahead of a 
> vote would be secondary to that problem.

Well I'm not that sure about /temporary/ fragmentation...

> As a baby step, I just set up an "abuse filter" on the wiki that will 
> tag any change to the |status=, |draftStartDate=, |rfcStartDate=, 
>|voteStartDate=, or |voteEndDate= parameters on a feature proposal page. 
> Rest assured, editing one of these parameters won't send you to the 
> headmaster's office for abusing any privileges, but you can filter 
> Special:RecentChanges, Special:Watchlist, etc. to show only these changes:
>
> <https://wiki.openstreetmap.org/wiki/Special:RecentChanges?tagfilter=proposal-status-changed>
>
> and you can click the "Atom" link in the sidebar to get a feed to add to 

Wow that's actually quite cool (and something I was looking for just recently)!
Thanks!! That should come handy, especially when proponents forget to notify
mailing list about voting being started.

(Bug report/caveat for others: when removing filters (e.g. "Non-minor"), the RSS
link does not update automatically, one needs to take care to manually refresh
page before clicking on RSS link.)


> This isn't quite what either of us are envisioning, and I personally 
> don't consider RSS feeds to replace that human touch. But it could make 
> it easier for some of us to keep track of proposals. If the feed gets 
> noisy, let me know and I can tighten up the abuse filter's rules.

Another idea, perhaps there could be some (read-only?) Discourse category which
is automatically subscribed to that RSS, so people following that Discourse
category would get automatic announcements of new Proposals / changes?

That might alleviate (at least some) of the concerns of non-technically
inclined persons (who might find RSS as complicated as mailing list)?

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] care services

[Matija Nalis]

On Sat, 19 Nov 2022 13:12:09 +0100, Georges Dutreix via Tagging 
 wrote:
> I don't think that this liste is good. These tags are primary tags. When 
> a restaurant offers different "cuisines" you won't map different POI's 
> with restaurant=chinese and restaurant=japanese, ... You will have only 
> one amenity=restaurant with a subtag cuisine.

Ah, I was confused then. I though each of those were separate. We're more
specialized here in Croatia, it it is about cleaning services it would only
offer cleaning services, it wouldn't have gardening services, and it surely
wouldn't provide assistence for children/elders (which require separate
licensing, extra schools etc.!)

> My question is for a unique company providing different services for 
> assistance at home, but the goal is not healthcare. Probably 
> office=home_aide could be good, I am questionning english native 
> speakers for the right word. In french we call that "service à la 
> personne", and I found for translation "home care".

Interesting, yes. office=* would probaby be good. But not being a native
English speaker, I have no idea what would be a good value either.

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Sat, 19 Nov 2022 12:12:22 +0100 (CET), Cartographer10 via Tagging 
 wrote:
> I always had good discussion on several platforms for my proposal. Each 
> community or person has another view
> which I collect this way.

Nobody (at least I hope) questions that extra communities (or extra persons is 
same community) have extra input to
provide!

Question is: did you then collect all the points those extra communities made 
(both those you agreed with, and those
that you didn't agree with), and summarized them on wiki /talk page, for extra 
period of RFC? Because if you didn't
(especially if you didn't include things you _disagreed_ with) then you abused 
that input to promote your personal view,
and disregarded the best parts that such other views could provide.

And if you did exactly that - I salute you. Could you link to that proposal 
where that was done?

> This proposal makes sure there are 2 required platforms where people have to 
> announce it. That way people have the
> choice to follow one of the two channels of their choice to get updated on 
> proposals. It is up to the proposal author
> to announce it on other channels to increase the reach.

I'd at least put in a requirement that if proposal author announces the 
discussion in X extra channels (i.e. anywhere
more than Tagging ML), that they must follow ALL that X extra channels and 
summarize in Wiki Talk page all points that
have been risen (including those that they think don't matter or disagree with. 
Especially those!) and THEN have extra
RFC period after all those X channels have been summarized, before proceeding 
to the Voting. 

Because, someone has to do that summarizing work for extra channels to make 
sense, and it is IMHO only fair that would
be proposal author (expecting that EVERYBODY will do that SAME task is both 
extremely wasteful, hugely unrealistic,
and likely to lead to few participating members willing to do that becoming 
burned out prematurely).

> And btw, if this proposal really turns out bad (which I doubt), it can always 
> be reverted by someone creating a
> proposal for it. Sometimes you also have to try something. What is the worst 
> thing that can happen?

I can imagine quite bad things, but to be fair, here is a most realistic one 
instead: On each changing of status quo,
some people will leave the process for good, as that will be the straw that 
broke the camel's back. If you need to
learn from history, see the debate when OSM changed license from CC-BY-SA to 
ODbL. And then, if another proposal
changes situation back to what it was before, that will NOT cause (majority of) 
people that left to come back.
It will instead cause some MORE people to leave for good (in revolt).

So it not like in math, when you end with what you started, e.g. "(X + Y) - Y = 
X". It is more like Microsoft windows
(you can tell I'm Debian GNU/Linux user, right?), when you install some random 
.exe file from the internet and you system
breaks. Then you try to install it in hopes your system will came back as it 
was, but instead it breaks some more.

Because, this is how community works.
There is no "undo" on community goodwill.


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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

Have you managed to do it yet? Could you post the URL, if so?

On Mon, 14 Nov 2022 07:06:10 +0100 (CET), Cartographer10 via Tagging 
 wrote:
> Thanks for the reminder. I indeed forgot to update the title after i changed 
> the proposal. Will do that soon.
>
>> But before we get that far, I recommend that the proposal's title be 
>> adjusted slightly. The current title implies that discussions would start 
>> "moving" to the new forums, which implies a loss of activity here. That's no 
>> longer on the table, so "Announce proposals to the new forum" would suffice.


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Start moving proposal announcements to the new forum

[Matija Nalis]

On Mon, 14 Nov 2022 08:49:46 -0500, Brian M. Sperlongano  
wrote:
> On Mon, Nov 14, 2022 at 2:49 AM Marc_marc  wrote:
>> We can see it with the osm-fr experience: the immature forum has split
>> the community, far from federating
>
> Thank you for clearly describing the root cause of your objection.
>
> In my opinion, it is better to let people decide for themselves where they
> wish to communicate.

If it is indeed better (which I personally am not convinced), then why not
change the proposal to ask that, in addition to the tagging mailing list,
proposal might (or should?) be announced at *as many contact channels as
possible* of those listed at 
https://wiki.openstreetmap.org/wiki/Contact_channels
(and the proponents should monitor all of them where they posted, and 
incorporete 
ideas from then on wiki proposal page).

That way, maximum reach will be accomplished, and all "people could decide for
themselves where they wish to communicate". So instead of say 30 messages on
tagging mailing list for some proposal, we can have 5 messages on tagging ML, 2
on Discourse, 4 on telegram (1-2 in each of the groups), 2 on Discord, 3 on
IRC, 3 on Matrix, 2 on Mastodon, 2 on Slack, 2 on Reddit, 2 on facebook,
1 on twitter and 2 on OSM Diary of proposer. Do you spot the problem here? 
Because I do.

So, I still think that the more channels, the less useful the exchange of ideas
will be, due to fragmentation. Even with "only" wiki talk page + tagging
mailing list (current situation), the disconnect is quite bad (and were it not
for few people pulling double-hours on both channels, would be very bad).
Increasing that fragmentation by another 50% does not sound like good idea to
me. We should work toward *reducing* that fragmentation, not encouraging
increasing it.

---

I'd rather that Tagging ML + Discourse Tagging category become properly
integrated (i.e. that one participate using EITHER channel, and see all
comments from BOTH channels) - as I noted in linked github issue on proposal
talk page.

Like, for example, I'm reading and writing this on NNTP (Usenet News) gateway
news.gmane.io, which *is* properly integrated with tagging mailing list.
Everything I write here, people will see in their Mail clients, and everything
they reply I will see in my News client.

That same level of integration could (hopefully will?) be accomplished with
Discourse - so people will see the SAME messages whether there use Discourse
HTTPS, Email SMTP, or News NNTP interface. 

Which solves the whole issue, without raising tensions. Win-win for everyone.

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] care services

[Matija Nalis]

On Thu, 17 Nov 2022 18:39:07 +0100, Georges Dutreix via Tagging 
 wrote:
> How would you tag the office of a company providing personnal services
> or care services at home,

> like gardener,

https://wiki.openstreetmap.org/wiki/Tag:craft=gardener

> cleaning,

https://wiki.openstreetmap.org/wiki/Tag:craft=cleaning

> assistance for children, elders or disabled,

https://wiki.openstreetmap.org/wiki/Tag:amenity=social_facility

> small repairs

https://wiki.openstreetmap.org/wiki/Tag:craft=repair ?

> The tag office=employment_agency is sometimes used, but looks for me not
> really adequate. The goal is not to provide jobs but to sell services.

https://wiki.openstreetmap.org/wiki/Tag:fee=yes


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

Re: [Tagging] Feature Proposal - RFC - Power utility office

[Matija Nalis]

On Fri, 18 Nov 2022 14:31:42 -0700, Mike Thompson  wrote:
> Technically what the electric utility is selling is energy, not power.  One
> gets billed for kilowatt-hours, not kilowatts. 

Well, it depends on the country. Over here in Croatia, you have to pay for 
max power too (by choosing which power consumer category you want to be in;
lower priced ones are limited to lower max power, e.g. 6kW; higher tiers allow 
more power, but cost more)

But yes, most of pricing is based on amount of electrical energy used 
(which is more properly measured in Joules, or if one wants to be SI-pedant 
in kg*m^2*s^-2, but power companies seem to stick to kWh nomenclature which 
actually does make some types of calculations easier)

Also, if being advanced consumer with higher power limits, you ALSO (in 
addition to 
two things above) have to pay for reactive power too, according to cos(phi) 
(beware of those inductive loads like compressors in air conditioners / heat 
pumps!
Cheapest tiers luckily are waiwed from this payment, at least)


> colloquially, the terms power and energy when it comes to electric
> utilities are used interchangeably, although "power company" seems to be
> favored vs. "energy company" in the US where I live.  If we want to be

> A more general issue is that often utilities provide more than one
> service.  Xcel, which operates in parts of the US, provides both
> electricity and natural gas (the latter which is technically energy too).

yes, "power" in that context usually implies "electrical energy".
However, "energy company" is not restricted to electrical energy.
Over here in Croatia, another popular energent is natural gas.

In fact, many of "electrical energy providers" are also 
"natural gas providers" over here, so such narrowly specified tag 
as "office=power_utility"  would make mapping them incorrect. 

So I would find sticking to tag with a wider meaning (like existing 
"office=energy_supplier") 
preferable.

Or if we desparately need a change, then go with even more inclusive tag like 
"office=public_utility",
and then use subtag (like existing 
https://wiki.openstreetmap.org/wiki/Key:utility) to map details
in what business(es) it is exactly.

> In a nearby city to where I live, the city owned utility provides
> electricity, water, sewer, and internet.

Agreed, see suggestion above.
Out of curiosity, do you know how is it mapped currently in OSM?

> On Fri, Nov 18, 2022 at 12:56 PM Dimitar  wrote:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Power_utility_office)
>> to introduce a new tag for power utility offices (office=power_utility)
>> and deprecate the existing one (office=energy_supplier). The rationale
>> behind this idea is that energy_supplier can be confusing to most people.


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Power utility office

[Matija Nalis]

Regarding deprecation of old tags, please follow this Discourse thread too:
https://community.openstreetmap.org/t/changing-rfc-time-for-proposals-including-deprecation/5661


On Fri, 18 Nov 2022 22:04:59 +0200, Dimitar  wrote:
> Link to the community forum thread: 
> https://community.openstreetmap.org/t/feature-proposal-rfc-power-utility-offices/5659


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] RFC - A broad look at fountains

[Matija Nalis]

On Sat, 12 Nov 2022 17:00:42 +0100, Davidoskky via Tagging 
 wrote:
> Is this proposal functionally any different from the water outlet 
> proposal? https://wiki.openstreetmap.org/wiki/Proposed_features/Water_outlet

You mean the one that was cancelled because it was a duplicate of already 
existing 
and hugely popular 
https://wiki.openstreetmap.org/wiki/Tag:amenity=drinking_water ?

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Historic

[Matija Nalis]

Also, 

I'm not sure if it was mentioned by proponents here, but Voting on
https://wiki.openstreetmap.org/wiki/Proposed_features/Historic

has been re-started.
(also note that initial votes have been nullified by proponents; so if you 
voted before, you might have to do it again).

On a personal note, I also find current proposal quite confusing about what is 
actually being proposed in this iteration and why.
I've noted my concerns at 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Historic#intention_of_this_proposal%3F

On Tue, 11 Oct 2022 13:15:05 +, martianfreeloader 
 wrote:
> Hello.
>
> I’m proposing to approve the historic=* key together with a number of tags:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Historic
>
> historic=* is in widespread use and currently documented as de facto.
>
> Please comment wherever you feel most comfortable:
> - Here
> - On the wiki talk page
> - In the forum
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

[Matija Nalis]

On Fri, 28 Oct 2022 10:18:01 +0200, Martin Koppenhoefer 
 wrote:
> The push button fountain variant is horrible, you can hardly drink from it, 
> can not wash your hands, particularly the
> hand that you use to push the button, and even filling a bottle is harder 
> than with the continuous flow. 

I agree completely in the case of valve directly-operated by button. 

There are however (much more useful!) variants in which, when you press the 
button, water begins to flow and a button
slowly depresses, so you get dozen or so seconds of a water flow after pushing 
the button, where you can easily use it,
wash both hands etc. before the flow stops.

> In addition if the thing wasn’t used recently, you’ll have to wait a long 
> time until the water becomes cold and can
> be drunken.

This stands, however in many places on this planet (and growing by the day) 
there is now limited amount of drinking
water, and we often simply cannot afford to waste it - however much we might 
prefer such luxuruios carelessness are
constantly flowing water...



-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

[Matija Nalis]

On Fri, 28 Oct 2022 16:43:07 +1100, Warin <61sundow...@gmail.com> wrote:
> On 28/10/22 06:24, Martin Koppenhoefer wrote:
>> there was a discussion about this, tap was seen as a distinguishing property 
>> that is yet missing. Handle is similar but not the same (handle is the thing 
>> you touch, if it is there, e.g. it could also be sensor based)
>
> Sensors are not handles .. I'm thinking about it having raised the issue 
> on the handle discussion wiki page. I take my time with 'new' ideas 
> trying to get them somewhat right. I think the actuator is more 
> important than the 'tap'/'valve' and would give more information than 
> 'tap=yes/no'.

there is also already existing/documented
https://wiki.openstreetmap.org/wiki/Key:actuator as well as
https://wiki.openstreetmap.org/wiki/Key:valve

and others (use taginfo link from wiki, and click on "combinations" to find 
them)

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps

[Matija Nalis]

On Wed, 26 Oct 2022 23:45:34 +0200, Martin Koppenhoefer 
 wrote:
>> On 26 Oct 2022, at 21:29, Paul Johnson  wrote:
>> Drinking fountains are switch or knob operated and shoot at an angle.
>
> these are assumptions based on your experiences that don’t hold true around 
> here, most drinking fountains have continuous flow.
>
> By the way, I started to add “tap”=yes/no to record whether there is a tap to 
> control the flow 

I think it would be much better to use already existing "handle=*" which is its 
purpose, instead of ad-hoc inventing
new undocumented key without discussion...

https://wiki.openstreetmap.org/wiki/Key:handle

handle=* has several advantages:
- it is already defined on wiki
- it is already used in the wild
- it has capability not only do define if the flow-control device exists or not 
(i.e. yes/no) 
  as does your suggested "tap=*", but also a specific type of it (i.e. 
activated by button or lever or wheel or ...)


-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Feature Proposal - RFC - Bench: replace seats by capacity

[Matija Nalis]

On Wed, 5 Oct 2022 14:20:09 +0200 (CEST), Mateusz Konieczny via Tagging 
 wrote:
> This revert makes sense to me.
>
> BTW, one may count both seats and capacity on benches, why not

One might even decide to tag 
https://wiki.openstreetmap.org/wiki/Key:length

instead (or in addition) to `seats`, as is it actually (reproducably) 
measurable instead of guessable 
(i.e. are we talking about how many thinly 3 years olds _or_ have super-obese 
adults can fit there?)

-- 
Opinions above are GNU-copylefted.


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

Re: [Tagging] Is it man_made=water_tap?

[Matija Nalis]

On Thu, 29 Sep 2022 20:13:00 -0700, stevea  wrote:
> Water "tap" implies at least some (even if crude) control of the flow.


And if one wants to define exactly how that flow is controlled, there is:
https://wiki.openstreetmap.org/wiki/Key:handle

and other tags, like:
https://wiki.openstreetmap.org/wiki/Tag:actuator=manual
https://wiki.openstreetmap.org/wiki/Key:turn_to_close
https://wiki.openstreetmap.org/wiki/Key:mechanical_driver

etc.


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