On 12/10/2022 09:34, Martin Koppenhoefer wrote:
we do not need the historic key to be “approved”, it is already there,
any definition we put in the wiki should reflect how the tags are
actually used. Approving a definition that would make current tagging an
“error” if it is completely introd
I agree with Mateusz.
* landuse=retail,residential,industrial, etc. are not bound to the North
American concept of zoning.
* landuse=retail does correctly not encompass the veterinarian, because
a vet mostly sells services, not goods. It is thus correct that the vet
is in a landuse=commercia
d
tagging proposal commenters can and will take the time to look at and
consider with all the negative consequences that has.
Simon
Am 11.10.2022 um 15:15 schrieb martianfreeloader:
Hello.
I’m proposing to approve the historic=* key together with a number of
tags:
https://wiki.openstreetma
I've reduced the proposal to the historic=* key itself. No values
included anymore.
On 11/10/2022 17:03, Marc_marc wrote:
Le 11.10.22 à 16:01, Peter Neale via Tagging a écrit :
Many ruins and memorials are "of historic interest" it is true, but
that could be tagged as a property ("historic=yes
sed
them) from the list and were approved already:
creamery <https://wiki.openstreetmap.org/wiki/Tag:historic%3Dcreamery>
ogham stone <https://wiki.openstreetmap.org/wiki/Tag:historic%3Dogham_stone>
Anne
On 11/10/2022 14:15, martianfreeloader wrote:
Hello.
I’m proposing to approve
On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote:
Also, is "are of historic interest" mismatches how
historic=wayside_shrine
historic=memorial
many historic=wayside_cross
are used.
Do you have a suggestion how to fix this?
___
Tagging mai
On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote:
Maybe there would be value in deapproving historic=battlefield
This is not in the scope of this proposal. Feel free to start a proposal
do deapprove battlefield.
___
Tagging mailing list
Thanks. Do you see a problem with approving a de facto key?
On 11/10/2022 15:25, Mateusz Konieczny via Tagging wrote:
I see no value in approving de facto key.
Maybe there would be value in deapproving historic=battlefield
Also, is "are of historic interest" mismatches how
historic=wayside_s
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 p
Hi Amanda,
No.
What puzzles non-native speakers (including myself) is that English has
a clear distinction between sex and gender (other than, for example,
German). Yet, the term "unisex" (contains the word "sex") is used to
designate a situation in the "gender" category, not sex.
Can you h
Hi Mitja,
I've drafted two opposing proposals on whether capacity/seats should be
tagged on benches without a functional separation into seats or not.
The purpose is to find out if there is a community consensus on this
question.
"Sure, it's fine to tag capacity, even if there is now functi
I agree, this discussion totally seems to be off topic.
Please start a new thread for it and don't spam this one with numerous
and lengthy emails.
Cheers.
On 10/10/2022 09:56, Davidoskky via Tagging wrote:
question: is it legal in the EU not to accept certain types of Euronotes?
Just c
alues for the key historic,
e.g farm, manor, monastery, castle ... all places where people lived. So
historic=crannog would 'work'?
If people say they are archaeological sites then why not the above farm,
manor, monastery, castle etc???
Cheers,
Anne
Good luck. May need a strong drin
Being practical: Just use the settlement_type=crannog tag.
I'm totally fine this.
Being principal would be to approve the settlement_type=crannog.
I'm not fine with this for the reasons laid out.
On 07/10/2022 13:46, Peter Elderson wrote:
I am one of those who didn't bother to look what it's a
I disagree with this:
"people who have only the vaguest idea of what the thing being voted on"
- Yes, most people probably don't know a lot about archeology. I assume
this is the reason why participation was so low.
- However, anybody can judge whether they find it sensible to approve a
tag b
It seems the discussion about this proposal is only starting now.
This is unfortunate. It should have happened earlier and might cause
frustration with the proposal author. Really sorry for that -- this is
not ideal.
But still better to fix some major issues to improve the proposal than
appr
Same opinion as Marc.
On 07/10/2022 12:27, Marc_marc wrote:
Hello,
Le 07.10.22 à 12:11, Martin Koppenhoefer a écrit :
who cares for "in use" or "approved"
me :)
approved that means that the subject has been discussed,
that people have spent time on it, that there has been
an opportunity to
e, I don’t think you meant to “back-door” such “lesser status” tags into
OSM, I don’t attribute any nefariousness on your part, as these are
somewhat-subtle (yet still important) issues.
martianfreeloader, while I’ve never done it and it would be unusual, I believe
we are allowed to change our
I agree, I wouldn't do this. -- But I've just voted before reading
Nathan's mail. Can I revert my vote?
On 07/10/2022 10:47, Nathan Case wrote:
Hi Anne,
I don't have any objections about the tag specifically. But proposals
like this do raise an interesting question.
Your proposal is for a
which has
the same meaning. Currently, gender=mixed is used instead.
On 06/10/2022 00:42, Graeme Fitzpatrick wrote:
gender=any?
Thanks
Graeme
On Wed, 5 Oct 2022 at 21:21, martianfreeloader
mailto:martianfreeloa...@posteo.net>> wrote:
In the discussion of the Gender proposal, I
Hi Volker,
Thanks for your comments.
On 05/10/2022 23:01, Volker Schmidt wrote:
Can we not finish this useless discussion?
1) That's what the proposal is trying to do.
2) You're free to abstain from any discussion you consider useless; but
since you haven't:
The amenity=bench tag was creat
Hi,
after recollecting some courage, here a second attempt.
I've drafted two opposing proposals on whether capacity/seats should be
tagged on benches without a functional separation into seats or not.
The purpose is to find out if there is a community consensus on this
question.
"Sure, it'
In the discussion of the Gender proposal, I noted that I find it strange
to use the term "unisex" for "gender-neutral" or "all-gender" (as sex
and gender are different properties).
Proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Gender
My suggestion was to use gender=mixed inst
There is a broad consensus that the language for OSM tags is British
English. Using a non-BE word for a tag because it is used in Australia
while a synonymous BE word exists, would be the same using a Xhosa,
Portuguese or Korean word, just because it exists.
I know there are a few exceptions l
rom the
"Features" wiki page) uses the OSMF meaning.
It seems that two authors with contradicting interpretation of the term
"feature" have written contradicting documentation.
On 03/10/2022 23:13, Martin Koppenhoefer wrote:
Am Mo., 3. Okt. 2022 um 12:40 Uhr schrieb
I strongly support this.
On 03/10/2022 16:04, Sebastian Martin Dicke wrote:
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Ta
Thank you all for the many insightful replies to my question!
What I've learnt so far:
1) A feature is something in the physical world. This is well documented
in the wiki: https://wiki.openstreetmap.org/wiki/Features
2) There is no such thing as a "primary feature".
3) The terms "main key",
Hi,
I'm unsure if I'm using correct terminology. I have come across these
terms in the OSM ecosystem:
- primary feature [1]
- main key [2]
- primary key [3]
- feature tag [4]
1) Are these synonyms (except for the key/tag distinction)?
2) Is *one* of these terms "official" OSM speek with a cl
just a sketch, let's see if I have time to spell this it out in
the next days.
On 29/09/2022 17:19, Martin Koppenhoefer wrote:
sent from a phone
On 29 Sep 2022, at 14:10, martianfreeloader
wrote:
Facing heavy objections and no support, I have come to the conclusion that my
propos
Facing heavy objections and no support, I have come to the conclusion
that my proposal is not considered useful by the community.
I thus decided to retract it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo
I propose to stop using seats=* on benches. Instead, capacity=* should
be used.
For details, see the proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Bench:_replace_seats_by_capacity
Please discuss this proposal on its Wiki Talk page.
__
Sorry for double-posting.
It has been brought to my attention that I had accidentally written my
original mail within an existing thread.
I hope, this one fixes it.
Original mail:
For consistency's sake, I propose to stop using seats=* on benches.
Instead, capacity=* sh
For consistency's sake, I propose to stop using seats=* on benches.
Instead, capacity=* should be used.
For details, see the proposal:
https://wiki.openstreetmap.org/wiki/Proposed_features/Bench:_replace_seats_by_capacity
Please discuss this proposal on its Wiki Talk page.
__
I support crossing:island=separate.
It is unambiguous and in analogy to a lot of other taggings like sidewalks.
On 27/09/2022 09:49, Mateusz Konieczny via Tagging wrote:
Sep 27, 2022, 08:42 by r...@hubris.org.uk:
Where there is a crossing with traffic islands, but the highways
for
To me, it seems that the root of the problem is that the
mtb:scale:uphill=* key is flawed.
Instead, these keys should be name mtb:scale:forward=* and
mtb:scale:backward=* . This would make everything unambiguous.
And, of course, an additional incline=up/down would be optional but very
helpfu
I agree.
We have loads of tags that only mappers with special knowledge can use
correctly (just dive into the world of railways). This doesn't mean
these tags shouldn't used by those who know what they're doing.
When it comes to trees, I'm a quite "ordinary" mapper. I have no idea
how to use
ut "just"
tens of thousands... :-)
On 20/09/2022 20:23, Yves wrote:
Le 20 septembre 2022 19:04:59 GMT+02:00, martianfreeloader
a écrit :
How about this:
- keep highway=path for everything that can be walked by normal people (this
means we don't need to re-tag millions
eorg wrote:
Dear all,
martianfreeloader, wrote Tue Sep 20 2022 10:52:06 GMT+0200
I think if something is tagged highway=path then data consumers should
be able to expect that regular people can walk on it without having to
look at an ever growing zoo of secondary tags. > ...
I think a new generi
Hi Anne,
Thanks for the proposal. I've left a comment on the wiki talk page.
On 18/09/2022 12:39, Anne-Karoline Distel wrote:
Hello everyone,
I'm proposing to introduce a new sub class of (archaeological) site
types "defensive settlement":
https://wiki.openstreetmap.org/wiki/Proposed_features/
I suggest we first decide whether we find the general concept of
highway=scramble to be useful and want to introduce it at all. In case
we answer this positively, then focus on working out the exact details
like what's the exact sac scale threshold, etc.
Cheers,
martianfreeloader
17/09/2022 01:35, Georg wrote:
Dear martianfreeloader,
you wrote Thu Sep 15 2022 00:27:11 GMT+0200
I am a hiker and a climber, but I made experiences similar to Peter's on
more than one occasion. I have been led along ways by osmand which were
mapped as highway=path; obviously by other
I agree with Patrick, Niels, Sebastian and Anne.
Tag names in other languages only if at least one of these is true:
- it's an *official* translation by the competent authority (e. g. the
municipality)
- or the name is in *common use*
- or it's a *documented historical* name in another language
), that's what I would do.
Peter Elderson
Op 14 sep. 2022 om 23:47 heeft martianfreeloader
het volgende geschreven:
In the real world, you will *always* find borderline cases for *any* property.
I don't think it should be an argument against a good proposal. If it were,
then it c
I agree, let's get photos! :-)
However, I don't really expect the "grey zone" to be very wide. I guess
for the vast majority of cases there won't be disagreement between
different mountaineers on whether you need your hands or not. UIAA for
example doesn't go into any more detail, either:
htt
In the real world, you will *always* find borderline cases for *any*
property.
I don't think it should be an argument against a good proposal. If it
were, then it could be used against literally *any* tag on osm. (and
funnily it reliably does come up with any new proposal)
On 14/09/2022 2
45 matches
Mail list logo
