Re: [Tagging] Feature Proposal - RFC - Carport

[markus schnalke]

[2017-02-04 18:56] Joachim 
>
> A carport is distinctive enough from building=garage and building=roof
> so that an own tag should be used. [...]
> The key building=* is used since a carport is a type
> of building=roof.

Funny how you first try to set the carport apart from the roof and
then, when explaining what a carport is, classify it (correctly, as
I'd say) as a type of roof, i.e. a roof plus some specific subtags.
-- You shot yourself in the foot. ;-)


But well, our building=* values aren't structured currently anyways,
e.g. building=residential and building=house have the same tagging
structure although one is the super class of the other. It would
be the same case for building=roof and building=carport. We don't
tag building=residential + residential=house, thus, with this
tradition in mind, I could live with building=carport ... maybe not
happily but well enough.


meillo

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

[Tagging] Feature Proposal - Key:oven - Approved

[markus schnalke]

Hoi,

I like to inform you that the oven proposal was approved with
16 votes (0 opposes, 0 abstains).

https://wiki.openstreetmap.org/wiki/Proposed_features/Key:oven

Many thanks to everyone who voted!


meillo
(on behalf of Giardia)

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

Re: [Tagging] Feature Proposal - Nesting Site - Approved :-)

[markus schnalke]

Hoi,

the voting for the Nesting Site proposal has now been closed.
https://wiki.openstreetmap.org/wiki/Proposed_features/Nesting_Site

It was approved with 26 votes for, 1 vote against and 0 abstentions.


I want to thank anyone who voted or contributed in other ways. It
was great to see this much participation in the voting!


meillo

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

[Tagging] Feature Proposal - Voting - "Key:oven"

[markus schnalke]

Hoi,

closely related to the bakehouse/baking_oven proposal, Yvan
just moved to the voting phase, is the proposal for Key:oven,
which I have to honor to open for voting on behalf of Giardia.

https://wiki.openstreetmap.org/wiki/Proposed_features/Key:oven

Yvan already wrote that we worked well together, on both of the
proposals. Thus we decided to coordinate the voting phases of
both of them.

Now we invite you to make use of your right to vote. :-)


meillo

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

[Tagging] Feature Proposal - Voting - (Nesting Site) ... was Bird Tower

[markus schnalke]

Hoi,

we now have reworked our Bird Tower proposal, trying to incorporate
all comments we have received. The result is located there:

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

(The old URL redirects.)

The old voting state (until the vote was aborted) was moved to the
talk page.


Now we welcome you to vote again, for the better proposal.


Sorry for the inconvenience, which was necessary to achieve the
best result for us all.


meillo, for the OSM group UlmerAlb

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

[Tagging] How to change currently voted on proposal (Bird Tower)?

[markus schnalke]

Hoi community,

we are currently in voting phase for our Bird Tower proposal.

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

It happens that we are currently receiving comments, which we
would have liked to receive during RFC phase. Well, we don't
mind because these comments are definitly worthwhile, no matter
when they drop in. But this leads us to the problem that we
would like to improve our proposal, motivated by those comments.

Our question is how to change a proposal once we are in voting
phase already?


Let me explain the situation:

We proposed to use
man_made=mast + tower:type=nesting_site
to tag artificial nesting aids.

There were two comments that the examples for man_made=tower
would be inappropriate. After closer examining the definitions
of tower and mast, we agree and would like to remove or alter
these examples. That shouldn't be a problem, I think.

Furthermore, however, we received the most valuable comment by
sorcrosc that
man_made=nesting_site + support=pole (or mast, ...)
would be a better tagging. Now that we were pointed to this
tagging, we agree that it is superior, because it not only
allows to distinguish between masts and poles (which was the
topic of the fourth comment we received) but also allows to
tag wall_mounted nesting aids, which are not covered at all
with our currently proposed tagging.

Hence, we would like to generalize the proposal by providing
a more flexible tagging ... but how do we do this?

The change appears to be too large to let the voting continue.
Seems we should abort the vote, change the proposal and start
a new voting phase. (Where do we store the old voting state,
which includes valuable comments?) Unfortunately, the proposal
process wiki page does not seem to give answers for this case.

We would much appreciate to get some advice on how to deal
with this situation.


meillo, for the OSM group UlmerAlb

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

Re: [Tagging] Key:visibility

[markus schnalke]

[2016-11-29 11:10] Martin Koppenhoefer <dieterdre...@gmail.com>
> 2016-11-29 7:02 GMT+01:00 markus schnalke <mei...@marmaro.de>:
> 
> This is just like the smoothness=* case. Instead of having values
> like ``excellent'', ``bad'' or ``horrible'', we now learned that
> it is better to tag for what cases some smoothness is okay. The
> same here: You'll always need the explanations above if you use
> the values ``house'', ``street'' and ``area'', but you can get
> rid of them if you just use the explanations themselves:
> 
>         - visibility=for_walkers
>         - visibility=for_slow_cars
>         - visibility=for_fast_cars
> 
> 
> I tend to disagree, the values you propose are more specific and not
> universally applicable (this is not about speed, but about scale, these new
> values would suggest to take into account other aspects like "visibility from
> within a car on the street", not applicable in many cases).

You are right. It should be about distance, not about position nor
speed.


Maybe that's the aspect that I don't like about the value ``street''
(although my suggested values were no better ;-) ): It indicates
position.

If you talk about scale then a set of ``house_scale'',
``street_scale'', ``district_scale'' or so could become universal
scale specifiers to be used in other situations as well. (Here I
would tend to use ``house_scale'' instead of ``building_scale'',
because buildings can be really large -- as large as streets --
whereas houses are usually within a quite limited size range.)


meillo

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

Re: [Tagging] Key:visibility

[markus schnalke]

[2016-11-28 20:50] Paul Desgranges 
>
> Visibility and readability are not the same, [...]

They also suggest different meanings, at least to me. When I
first read you message about visibility of public clocks, I
thought it would indicate from which directions or places it
would be visible, not the distance from where it is readable.


> -visibility=house : visible from the distance of one house (or
>  building), the device is targeted mostly for pedestrians, or bikers
> -visibility=street : visible from the  distance of one street, the
>  device is targeted up to passers-by into vehicles going slowly
> -visibility=area : visible from all the area, the device is targeted
>  up to passers-by into vehicles going fast
> 
> If somebody wants to make a better wordings, I would be glad

This is just like the smoothness=* case. Instead of having values
like ``excellent'', ``bad'' or ``horrible'', we now learned that
it is better to tag for what cases some smoothness is okay. The
same here: You'll always need the explanations above if you use
the values ``house'', ``street'' and ``area'', but you can get
rid of them if you just use the explanations themselves:

- visibility=for_walkers
- visibility=for_slow_cars
- visibility=for_fast_cars

(I see bikers in the same case as slow cars if they are in
motion. Thus we should better not use the too flexible biker
term.)


I have to come back to my initial statement: The term
``readability'' would be the better one for this meaning,
as ``visible for fast cars'' is really something else as
``readable for fast cars''.

I'm no native English speaker, but I think it has to be
``visible from'' and ``readable for''. Thus, consequently,
the visibility should be specified with a distance and not
with the kind of moving vehicle, which brings us back to
the naming problem. ... These are indicators that there is
something clumsy about the current system. Before we extend
it, we should better double-check its sanity.


meillo

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

[Tagging] Feature Proposal - Voting - Bird Tower

[markus schnalke]

Hoi,

after some last improvements during the RFC phase, we feel that
our Bird Tower proposal now is ready to be voted on.

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


Please participate in the voting to achieve a high turnout.


For the OSM group UlmerAlb,

meillo

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

[Tagging] Feature Proposal - RFC - Bird Tower

[markus schnalke]

Hoi,

in the name of the mapping group UlmerAlb, I welcome you to
discuss our proposal for

tower:type=nesting_site

to tag a man made bird nesting aid mounted on a mast or tower.

In short: A bird tower is a man made mast or tower equipped with
one or multiple birds nests, serving as an artificial nesting aid,
compensating the reduction of traditional nesting opportunities.

http://wiki.openstreetmap.org/wiki/Proposed_features/Bird_Tower


meillo

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

Re: [Tagging] Feature Proposal - RFC - Tag:building=bakehouse

[markus schnalke]

[2016-10-17 13:14] Yvan Masson 
>
> After 4 days as a draft, I switched the "Tag:building=bakehouse"
> proposal to "proposed" status.

Great to see the advancing of the proposal! :-)

> Definition: "Building made especially as a baking oven, usually public"
> URL: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dbaking_oven

Should the page be renamed to match the tagging now proposed?
Is there a policy about how to act in such cases?


meillo

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

Re: [Tagging] Proposal : amenity=baking_oven

[markus schnalke]

[2016-10-13 13:57] Tom Pfeifer <t.pfei...@computer.org>
> On 13.10.2016 13:18, markus schnalke wrote:
> > [2016-10-13 13:05] Yvan Masson <yvan.mas...@openmailbox.org>
> >>
> >> I just proposed the introduction of the "baking_oven" tag on
> >> https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dbaking_oven
> >>
> >> I would be pleased if you could have a look on this draft and give your
> >> comments.
> 
> Isn't that covered by man_made=kiln already?
> The English definition mentions baking, and the German page has a 
> picture of an over for baking.
> 
> https://wiki.openstreetmap.org/wiki/DE:Tag:man_made%3Dkiln

Wikipedia has two separate articles:

https://en.wikipedia.org/wiki/Bakehouse_(building)  (see also in de and fr)
https://en.wikipedia.org/wiki/Kiln

The former means the building, while the latter means the oven
itself, but more important, the former is for baking bread and
such only, while the latter is for all kinds of heating and
smelting purposes.


meillo

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

Re: [Tagging] Proposal : amenity=baking_oven

[markus schnalke]

[2016-10-13 13:05] Yvan Masson 
>
> Hi list,
> 
> I just proposed the introduction of the "baking_oven" tag on
> https://wiki.openstreetmap.org/wiki/Proposed_features/amenity%3Dbaking_oven
> 
> I would be pleased if you could have a look on this draft and give your
> comments.

I much appreciate this proposal.

My local mapping group (UlmerAlb) has missed this tag already.
We'll be happy to provide information about the situation in
south-west Germany.


meillo

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

Re: [Tagging] Casing in values

[markus schnalke]

[2016-08-25 10:51] "Jerry Clough (SK53)" <sk53_...@yahoo.co.uk>
> On 25/08/2016 08:47, markus schnalke wrote:
> > snip
> > Is it the same for genus=Tilia, i.e. should it be genus=tilia?
> >
> > (Recently iD started to tab-complete it in lowercase, even if I
> > started to type it in uppercase.)
> 
> This has just been pointed out to me. I've filed an issue with iD on 
> Github: https://github.com/openstreetmap/iD/issues/3377
> 
> At the moment the bulk of values in Genus are sensible & according with 
> Botanical nomenclature, so let's keep it that way!

Okay, thanks.


> I'm not sure if there is a single good worldwide open source of plant 
> genera. The obvious candidate is The Plant List, but this is
> closed, see Roderic Page's blog post: 
> http://iphylo.blogspot.co.uk/2010/12/plant-list-nice-data-shame-it-not-open.html

I use http://wiki.openstreetmap.org/wiki/Wetter_Baum for tagging trees,
it's in German, however.


meillo

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

Re: [Tagging] Casing in values (was: Multiple values for one key - the cuisine problem.)

[markus schnalke]

[2016-08-25 09:15] Martin Koppenhoefer 
> > Il giorno 25 ago 2016, alle ore 06:18, André Pirard 
> >  ha scritto:
> > 
> > I saw that the OSM people are very picky about correct spelling.
> 
> formal values are without capitalization in osm

Is it the same for genus=Tilia, i.e. should it be genus=tilia?

(Recently iD started to tab-complete it in lowercase, even if I
started to type it in uppercase.)


meillo

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

Re: [Tagging] How to tag high water marks (flood marks)?

[markus schnalke]

[2016-07-20 10:45] Martin Koppenhoefer 
>
> it appears there is already this tag in use, which might cover part of what 
> you
> are after:
> monitoring:water_level

I disagree. As I understood it, monitoring:water_level is for regularily
*monitoring* of the level, whereas the tagging searched for is for markers
of exceptionell historic high water levels. Of course, sometimes the high
water marks are placed at water level monitoring stations, but often they
are placed at buildings that are quite distant from the water, to display
the impact of the high water.

IMO historic=memorial + memorial:type=plaque is the right direction.


meillo

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

[Tagging] Structured approach to the multi-value discussion

[markus schnalke]

Hoi,

I like to suggest the following structured approach to tackle
the multi-value (MV) topic:


Phase 1: Are MV necessary?

First, collect examples of seemingly necessary MVs in a wiki
page. Classify them as ordered and unordered MVs. Discuss
alternative tagging possibilities, which don't need MVs, for
these examples. Try to figure out if MVs are rare or common.
Discuss the variants of name=* separatly because they are most
controversial.

After the situation is clearly laid out, the community should
agree if (ordered, unordered, both, no) MVs are necessary.

If they are considered unnecessary, goto Phase 4.
If they are considered necessary, goto Phase 2.


Phase 2: Implement MV in the key- or in the value-domain?

MVs can be implemented in the key-domain (e.g. _1 suffix) or
in the value-domain (semicolons), or multiple identical keys
could be allowed (only for unordered MVs). Discuss these three
approaches, without discussing concrete implementations (e.g.
whether _1 or %1 or whatever should be used). This discussion
will also have to balance between a user burden (value-domain)
and a programmer burden (key-domain). This might depend on the
assumption if MVs are a rare thing or if they are common.

Without wanting to stress the already questioned voting
procedure even more, but normally, one would want to ask for
agreement of the community here as well.

If multiple identical keys should be allowed, goto Phase 4.
If MV should be implemented in the value-domain, goto Phase 3.
If MV should be implemented in the key-domain, goto Phase 3.


Phase 3: Which separator to use?

Key-domain: Decide how to separate the key's name and the
unique suffix. Furthermore one should discuss what suffixes
should be used.

Value-domain: The semicolon seems to be the accepted separator
in this case, but the whitespace after the separator might
not.

A relevant aspect in this discussion seems to be if these
suffixes or separators are supposed to be presented to the
user or hidden and automatically handled by the interface
software.

Goto Phase 4.


Phase 4: Transition plan

At this point, all decisions were made and the community
agrees if and how MVs should be handled. Now, the transition
from the current situation to the desired situation needs to
be discussed. Depending on the outcome of the above phases,
the transition could include changing editor software, but
as well it could include re-tagging current MVs in a non-MV
way. In any way, the time frame for such changes will be long.



I suggest, that these phases are processed one after each
other, because otherwise we will hardly agree on the ``higher
levels''. Thus, now we should start to focus on phase 1 only.
The different opinions that will likely show up there, will
explain most of the disagreement that makes our current
discussions, which mix all in one, so difficult, I am sure.

It is already valuable if we could agree in phase 1 although
we might not agree in phase 2. Mixing the discussion all in
one prevents us from having this success in such a situation.


I am willing to set up and care for a wiki page for phase 1,
as such a page seems not to exist yet.
(
documents the current state, rather than being a tool to
support discussing the future.)

As I'm relatively new to OSM (started mapping about a year
ago, although my account is older), I don't want to force
my way of thinking onto the community. In my opinion the
approach I proposed could help, but if the OSM community
is successful by doing it differently, I rather stay quiet
and watch things evolve.


Hope to help.


meillo

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

Re: [Tagging] Proposal about suffixed tags has been approved

[markus schnalke]

[2016-02-25 01:37] moltonel 3x Combo 
>
> That is part of the problem with the proposal, and its votes. It
> touched lots of topics, and some people probably got confused about
> the rather focused intent (I certainly did). For example there was
> strong consensus on the list against the behavior of the iD editor,
> even though this was a very tangential (dare I say unrelated ?) topic.
> I am sure this skewed the results (this seems to be the case at least
> for the votes of Meillo and geow, amonst the minority who commented).

As my name is mentioned:

In my opinion, this proposal covers only one minor part of the
whole MV topic, but nontheless, as I think the proposal does more
good than it does harm, I do approve it.

By no means, we should treat the result of this proposal as the
end of the MV discussion, it should rather be seen as the beginning.


meillo

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

Re: [Tagging] Voting rules

[markus schnalke]

[2016-02-23 11:54] Andy Townsend 
> >
> > It was provisionally rejected with 40 votes for, 18 votes against and 
> > 4 abstentions.
> > Approval rate: 68.97%. Less than required 74% so provisional 
> > rejection; proposer to make final call.
> 
> The tricky bit of course is that those percentages are "of the people 
> who voted".
> 
> Taginfo reckons objects with the key "shop" were last edited by 105 030 
> different users, and there are 1,976,690 shops, of which 20,851 are 
> jewelry and 215 jewellery, which suggests (finger in the air) around 
> 1100 individual mappers last edited a jewellery shop. Taking that as the 
> base, the "approval rate" of a little under 4%, based on a "voter 
> turnout" or a little under 6%*.

Numbers can help to see more clear, but they do not so necessarily.

Of those about 1100 mappers: How many cared for the tag names and
how many just clicked on a button to have it semantically tagged
as a jewel(le)ry shop (uninterested of what the exact tagging would
be)? How many implemented what the wiki says and how many want to
sharpen the information that is collected in the wiki?

Aren't the ones who vote those who care for what the actual
tagging is? Because, if the others would care, why don't they
vote? ;-)


meillo

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

Re: [Tagging] Discussion about Multivalued Keys

[markus schnalke]

Hoi,

I'd like to share some thoughts about the ``How to implement MV in
OSM'' question, as opened in:
http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys

I'd prefer to first have explicit agreement that we actually need
MV ... but as the implementation discussion is already rolling ...

Initially, I wanted to add a section to the talk page of the wiki
page but my text now appears to be better suited for an email. Please
feel free to integrate any part of my considerations into the wiki
page.



I see two general ways to solve the problem of MV in OSM:

1) Allow multiple identical keys per object (as is was before API
0.6, I learned). This means tag names of one object need *not* be
unique. When we talk about tag names being unique, we should
distinguish between being unique in the data storage and being
unique at the surface (GUI). It seems ... well, what does it seem?
Are we more concerned about the technical storage level or at the
user experience? Which of them are we discussing?


2) Make multiple identical keys by some *technical* measurement
unique. This is the currently assumed way to go, at least as such
it appears to me.

I (now) think that it is important to keep the value domain free
from logic and thus have it reserved for literal data. This means,
MV need to be implemented in the key domain.

Currently, we mostly discuss with concrete examples. The assumption
is, that the user would have to deal with these suffixes. Maybe he
doesn't have to. It might be possible to abstract the user's view
from the internal storage. Then the actual encoding becomes
irrelevant from the user's perspective. Multiple identical keys
could be presented to him (even grouped) ... and they'd be
translated (e.g.  by appending arbitrary suffixes (e.g. hashes of
the value)) at the interface to the data storage layer. (I focus
on unordered MVs here.)

As a user, I'd never want to have to deal with this MV problem at
all, which means no encoding should be required by me, neither in
the value *nor* in the key domain. If there are two refs, then I'd
want to tag: ref=foo + ref=bar. The internal storage should not be
the user's problem.

Of course, it's not that easy, because raw data is dealt with much
too often. Nonetheless we should kept in mind, that a separation
of the user's view from the data storage can solve colliding wishes.


Concerning the choice, of how to add such a suffix:

We should realize what we try to do here: We're violating the
first normal form for relational databases, by encoding two
separate bits of information in one field (the key's name and some
unique suffix). We already came to the opinion, that encoding
multiple values in one field in the value domain is bad ... but it
is equally bad in the key domain.

And it is even worse if the separator is not (technically)
reserved for that specific purpose. If we would use the underscore
(_) to separate the key's name from the unique suffix, then the
technical separation of name and suffix would be pretty fragile,
because names already contain underscores. The split would be
rather guessing, based on the suffix to be a number.

Hence, if we do encode two separate values in one field, then we
better try hard to make the separator reserved. This not only
spares us escaping, but also allows us to search for exact key
names, because the search engine can then be enabled to know which
is the name to compare and which is the suffix to ignore.

The underscore approach fails in this respect equally as the colon
approach. Of the currently discussed approaches, only the subscript
(bracket) syntax satisfies this need. (Assuming that there are no
brackets in key names, currently.) However, it's closing bracket
is technically superfluous and only motivated by the thinking that
humans have to see these suffixes.


What we need in my opinion is one single character, that must
never be part of any key name and never be part of any suffix.
Using this separator, we encode two separate bits of information
in one field (the key field) ... and thus have effectively three
columns in a two-column table.

At the surface (GUI) we should rather hide the technical suffix
stuff.


meillo


P.S.
Ordered MVs are not considered here. It is not clear if we need
to consider them.

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

Re: [Tagging] Discussion about Multivalued Keys

[markus schnalke]

[2016-01-27 09:40] Tod Fitch 
>
> Or, following the example of turn lanes, use semicolon for unordered
> and vertical bar for ordered. It seems to me that a comma might be too
> common a character in real world values to have a special use. While
> an escape mechanism needs to be defined, it would be nice if it were
> seldom needed.

Please try to avoid discussing implementations when discussing
concepts!

The topic is about the need of an ordering of values, not about
how to implement it. If we constantly fall into the implementation
discussion, then we are constantly forced to deal with the _1 vs. ;
question ... without solving the conceptual question.

It's fully enough to state that one thinks, we need to have both
possibilities -- marking some MV as ordered and some as unordered
-- however that might be represented in the future.

When we agree on the conceptual need, *then* we can and should
discuss implementations.


meillo

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