Re: [Tagging] Do we map pedestrian crossings twice?

[António Madeira]

I agree that the wiki should be consistent on the use of these two ways
of mapping a highway crossing.

Personally, I always use highway=crossing on nodes and only
footway=crossing when I can connect the point to a pedestrian feature
for routing purposes.


Às 12:44 de 10/06/2020, Jack Armstrong escreveu:

Thank you, Andrew,

According to the "Sidewalk as a separate way" proposal, which was
approved in 2011,

When a highway=crossing node is present on the main road, a way
connecting the sidewalks on the two sides of the road should be
mapped. Not to override the well-established meaning of
highway=crossing, this way should be tagged as follows:
highway=footway
footway=crossing

However, the OSM wiki “tag:highway=crossing” directly contradicts this;

To map a pedestrian crossing, place a node within the way representing
the road, and set this highway=crossing tag on the node…
footway=crossing and cycleway=crossing are sometimes used on ways
which lead from a sidewalk to the crossing node (the node which has
this highway=crossing tag). *This is not the preferred way of tagging.*

Is this a simple case of information not being transferred from the
approved proposal to the wiki?

I have no preference on how a pedestrian crossing is mapped, but I am
keen for the wiki to reflect accurate information. If we are following
the approved proposal "Sidewalk as a separate way”, does anyone have
objection to the wiki being changed to reflect this?

Cheers




-Original Message-
From: Jack Armstrong
Sent: Jun 9, 2020 8:03 PM
To: tagging@openstreetmap.org
Subject: Do we map pedestrian crossings twice?

Apologies if this has already been discussed. I searched the
tagging list, but couldn’t find it.


Users have been adding pedestrian crossing tags on ways in
addition to the street connecting nodes. In effect, a single
pedestrian crossing is tagged twice. To me, this would seem
contrary not only to the OSM wiki page, “Tag:highway=crossing”,
but also contrary to, “One feature, one OSM element”.


Example:


https://www.openstreetmap.org/edit?changeset=86290585#map=20/39.63167/-104.89726


I’ve been told by a user, anecdotally, there’s a Slack group that
decided this is correct. To my knowledge Slack groups do not
supersede the OSM wiki. I assume mapping a crossing twice is
incorrect?


OSM wiki: tag:highway=crossing

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dcrossing



- Jack Armstrong




www.theaveragenomad.com



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


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

Re: [Tagging] Help explain the difference between path and track

[António Madeira]

Às 06:03 de 10/06/2020, Martin Koppenhoefer escreveu:


sent from a phone


On 10. Jun 2020, at 02:31, Kevin Kenny  wrote:

In terms of function, 'track' and 'service' (with or without
'driveway') are practically interchangeable - at least in terms of
what they provide to the road network. They're both distinguished by
the fact that they don't 'go anywhere'. They typically serve only a
single establishment - public roads that serve multiple establishments
are typically at least 'unclassified'.


+1 for service, while tracks may actually “go somewhere”, they might be usable 
as through ways, but they are not considered “roads“ in some jurisdictions at 
least.

service roads are for accessing something (are not part of the connection 
grid), while tracks may (according to the regional situation) form a kind of 
„second grid“ (for agricultural purposes, but eventually open to cyclists, 
hikers, etc. as well).

Cheers Martin



I agree with Martin here. I rarely map a track that goes nowhere, but I
always map a track that connects to another track or to the main grid.
On the other hand, a service road almost always goes nowhere. Either
ends on a private estate or is just used as an access link to a company,
industry or amenity.
If a motor vehicle can and uses the way, it's a track. If not, it's a
path, which only people and bicycles can use in an normal manner. Maybe
this is not as straightforward in other countries, but in Portugal
there's rarely any doubt about this.

Regards,
António.

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

Re: [Tagging] Do we map pedestrian crossings twice?

[António Madeira]

Às 17:16 de 10/06/2020, Jack Armstrong escreveu:


From: Clifford Snow
To help me understand, below are three schemes for crossings.
Which one(s) best describe your suggested way of mapping.

1. Tagging both the crossing and a node on the highway.
https://mycloud.snowandsnow.us/index.php/s/YEFoYcTgR2gtW3j
2. With no crossing ways, just a node on the highway to mark the
type of crossing
https://mycloud.snowandsnow.us/index.php/s/4ad5wLzMNcE3sNo
3. With just crossing ways and no node at the intersection of the
crossing and highway.
https://mycloud.snowandsnow.us/index.php/s/tHF62pH5txPEX55


Well, since you asked, as to my own personal preference,

#1 is not my preference. Crossing tags are placed on the way and on a
node for a single pedestrian crosswalk. I feel this violates OSM's
"one feature, one OSM element" rule.
#2 seems acceptable, but it's not my personal preference. (Again, I
started this thread not in order to express my preferences, simply to
have the wiki compliant with approved OSM canon)
#3 has no connecting node between the two ways represented by the red
dot? This would not be correct. There should be a connecting node.

This is an example of how I prefer to map pedestrian crossings (this
is common throughout downtown Denver):
https://www.openstreetmap.org/edit#map=21/39.72565/-104.98501

Here are two methods I mapped as a demonstration of mapping that I
feel is correct, as well. Mapped here are two different methods that
seem reasonable, tagging either the connecting node or tagging the
way; but not tagging both the node and the way. Tagging both the node
and the way would seem to violate the  "one feature, one OSM element"
rule.
https://www.openstreetmap.org/edit#map=21/39.71293/-104.98038

Cheers
Jack Armstrong
(chachafish)



Using footway=sidewalk on a highway crossing is not a legit way of
mapping this. You can not substitute something that seems wrong for a
certainly wrong tag.
I understand your issue, as I always had the same problem about
footway=crossing, and that's why I only use it when creating routable
ways for pedestrians, but unless you can convince routing software to
recognize a highway=crossing point as a crossover to pedestrians (with
out a line) I don't see how this can be undone.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Do we map pedestrian crossings twice?

[António Madeira]

Às 19:29 de 10/06/2020, Graeme Fitzpatrick escreveu:




On Thu, 11 Jun 2020 at 06:30, Clifford Snow mailto:cliff...@snowandsnow.us>> wrote:



Sorry - I should have been clearer on #3. The red dot is a
validation warning that the two ways intersect, but it isn't
marked as a crossing.


(Not having a go at you, Clifford, just using your comment as an
example! :-))

"Recently" (2019?), iD has also started pointing out / suggesting /
demanding that all crossings (be they road - footway, driveway -
footway, footway - footway / cycleway, road - road etc) eg
https://www.openstreetmap.org/edit#map=19/-28.08457/153.44892 (if the
"error" doesn't show, please click on either side of Second Avenue),
also be marked as a crossing.

When you go ahead & "fix" it, it inserts a highway=crossing at that
point: https://www.openstreetmap.org/edit#map=21/-28.07834/153.44686.

Good luck with telling them they're "wrong"!

Thanks

Graeme



That's an obvious error.
The ways must cross somewhere (that's what the warning states) , but it
doesn't tell you to add a crossing.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Compliments and thanks to the "iD people"!

[António Madeira]

Unfortunately, it's still possible to break relations when merging ways.


Às 08:35 de 12/06/2020, Peter Elderson escreveu:

(Not directly a tagging issue, but very often mentioned here, and
rarely in a positive way!)

I would like to thank the iD developers for their work on keeping
route relations right when changes are made to the ways.

I was very negative about that because I spent a lot of time repairing
the damage caused by iD-users who just didn't know what was going on
with route relations. I remained sceptic when I heard work had been
done: see first, then believe. And I was not the only one.

At this point, when I check a long distance hiking route for errors, I
hardly find any errors caused by mappers. The ones I find are not
typically caused by iD-use; JOSM appears just as often the cause. So
it's really down to mapper error now.

I am finally convinced. My compliments and thanks again!

(I still have a lot of wishes when it comes to managing relations
online, but that's another chapter!)

Best, Peter Elderson

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


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

[Tagging] How to tag a graffiti?

[António Madeira]

What is the criteria to tag a graffiti?
Since there's no wiki for this type of artwork, the only information
that exists is "A notable graffiti work", here:
https://wiki.openstreetmap.org/wiki/Key:artwork_type

So, what is a notable graffiti? A signed one? A big one? An authorized one?
There are all kind of graffitis around cities nowadays, many of them
mere vandalism or simple drawings in abandoned or ruined places.
Wouldn't it be helpful to clarify and build an useful wiki for this?

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

Re: [Tagging] How to tag a graffiti?

[António Madeira]

Yes, these are the two main issues regarding this tag: subjectiveness
and permanence.

Maybe a wiki could help and clarify what is a "notable" one.
This question arose in the Portuguese Telegram channel, where someone
was tagging pokemon paintings he himself did around his city. Some of
them are small, one of them is a bit bigger, covering an entire electric
distribution box.

Notable could be considered a "lasting" graffiti, recognisable as part
of the urban landscape and not just a drawing somewhere in the back of
lamp post or over a manhole.


Às 20:24 de 01/07/2020, Paul Allen escreveu:

On Thu, 2 Jul 2020 at 00:05, António Madeira mailto:antoniomade...@gmx.com>> wrote:


So, what is a notable graffiti? A signed one? A big one? An
authorized one?


Notable graffiti is graffiti that people take note of. It's as simple
as that.

It's subjective.  Do you think it ought to be mapped, for whatever reason?
Then it might be notable.

I'd be more worried about permanence.  Most graffiti is unauthorized and
could be removed at some time in the future.

--
Paul




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


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

Re: [Tagging] How to tag a graffiti?

[António Madeira]

Well, depends on what you consider a mural to be. The distinction
between a mural and a graffiti should also be better defined.
A mural can be any painting or artwork apllied on a wall, indoors or
outdoors.
I would say that an outdoor mural is always a graffiti if it is painted.




Às 21:21 de 01/07/2020, Paul Allen escreveu:

On Thu, 2 Jul 2020 at 01:02, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:


it’s a qualifier that is highly subjective as noted by Paul. The
criterion is *you*. If you believe it should be mapped, then do it.

Add an image= tag if you like, and if you are going to add further
detail


And it's also, like many other things, blurry.  Is this graffiti, or a
mural,
or a memorial?https://www.bbc.co.uk/news/uk-wales-53247629

I'd say it's not a mural but is graffiti.  It's also a memorial. 
Somebody,
not me, mapped it as a monument although I don't think monument
applies:https://www.openstreetmap.org/node/6211918213


BTW, that looks like a milk churn stand to the right of the memorial.
I should get around to asking if that needs a proposal or if there was
insufficient objection to a value already in use (one time!) that it can
just be documented without a formal vote.

And then there's this: https://www.bbc.co.uk/news/uk-wales-46634242
Mural or graffiti?  Given the way it was painted, it could be classed as
graffiti.  Very notable, even though unsigned.

--
Paul


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


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

Re: [Tagging] How to tag correct number of lanes for freeway on/off ramps?

[António Madeira]

I believe the correct way is mapping it with 4 lanes where the 4th lane
begins (with turn=|||slight_right) and put the motorway_junction where
it splits. Then, the ramp gets 2 lanes and the main road 3.


Às 17:38 de 03/07/2020, Matthew Woehlke escreveu:

On 03/07/2020 16.28, Martin Koppenhoefer wrote:

On 3. Jul 2020, at 22:20, Matthew Woehlke wrote:
Accordingly, there are actually four lanes for these stretches.

What is the correct way to model this?


split the highway so that each way had the same number of lanes, then
fix the lanes (4 rather than 3) where it applies


I'm not sure what the first half of that is saying. Are you agreeing
with my proposed mechanism?




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

Re: [Tagging] How to tag a graffiti?

[António Madeira]

Here in Portugal, is very common for Town Halls to promote graffiti
festivals, with buildings and public spaces assigning spaces where urban
artists can do their artworks.
There are world renowned Portuguese graffiters thanks to this subculture
that it's present in almost every Portuguese city. (Vhils is just one of
them -> https://en.wikipedia.org/wiki/Vhils)

So, we could suggest that a notable graffiti should be a recognizable
and authorized painting, because that would imply that it's both notable
and durable. It should also be a work of art that it's "naturally"
inserted in the urban landscape, without being mere vandalism or
something that could disappear in days.



Às 13:24 de 02/07/2020, Martin Koppenhoefer escreveu:



sent from a phone


On 2. Jul 2020, at 16:12, Jarek Piórkowski  wrote:

If this was a monument, what would we consider a much taller sculpture



yes, I’ve also some examples
https://commons.m.wikimedia.org/wiki/File:Treptower_Ehrenmal,_Tag_des_Sieges_2015,_01.jpg#mw-jump-to-license

https://commons.m.wikimedia.org/wiki/File:Holocaust_Memorial_Berlin.JPG#mw-jump-to-license

https://commons.m.wikimedia.org/wiki/File:Barbarossa_Turm.jpg

https://commons.m.wikimedia.org/wiki/File:Laboe-1936-HWI01.jpg#mw-jump-to-license

https://upload.wikimedia.org/wikipedia/commons/thumb/a/ad/ArcoCostantinoRoma.jpg/400px-ArcoCostantinoRoma.jpg

not sure if this qualifies as well:

https://commons.m.wikimedia.org/wiki/File:Kheops-Pyramid.jpg#mw-jump-to-license

Cheers Martin

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


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

Re: [Tagging] kerb=regular vs. raised

[António Madeira]

Às 20:45 de 29/07/2020, Martin Koppenhoefer escreveu:


eg this is pretty raised
http://i.dailymail.co.uk/i/pix/2013/07/29/article-2380778-1B0CC26E05DC-458_634x386.jpg

Cheers Martin




lol

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

[Tagging] How to tag a social vacation centre?

[António Madeira]

Hi there.

How should I tag an area dedicated to vacations, which is not a resort,
only for members of an institution? Those centres are very common near
the sea, and they range from kids camps (sons of government workers), to
bank or police pensioners/workers.
I was about to tag that as amenity=social_facility but I can't find any
suitable subtag that conveys the idea of vacations.

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

Re: [Tagging] How to tag a social vacation centre?

[António Madeira]

Às 20:20 de 11/09/2020, Graeme Fitzpatrick escreveu:




On Sat, 12 Sep 2020 at 07:01, António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

I ended choosing leisure=resort.
There is an ill documented key for this tag, which seems to
address the problem of defining the type of resort:
https://wiki.openstreetmap.org/wiki/Key:resort

Maybe we could expand and better the type of resort, based on this
key.


Not well documented at all, & as far as I can see, never discussed or
voted on either?

I've got to say that, personally, I don't like leisure=resort - I
would think it should be tourism=resort (despite that being deprecated)?

To me, leisure is something that you do for fun / relaxation in your
home town, while tourism is what you do when you go away on holidays.

https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dresort even says "
attracting visitors for vacations, tourism"!

Thanks

Graeme



I agree that a resort should be with tourism, but I really don't know
the reasons that made tourism=resort to be deprecated (couldn't find any
discussion about it).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a social vacation centre?

[António Madeira]

Unless it was discussed here in the tagging list, I couldn't find any
discussion on the wikis.
It really doesn't make sense, since a resort is always first and
foremost a hotel or accommodation of some sort aimed at tourists.
Although it has a leisure component, that's not the main element,
otherwise it would be a theme park.


Using the Google translator, in the discussion page it reads:
"In at least 3 European countries such aerea are referred to as a resort
and the proposed alternatives are definitely wrong or misleading. So an
XXX resort on the map is a resort and not an amusement park. This notice
should go away."



Às 22:34 de 11/09/2020, Graeme Fitzpatrick escreveu:




On Sat, 12 Sep 2020 at 09:54, António Madeira mailto:antoniomade...@gmx.com>> wrote:


I agree that a resort should be with tourism, but I really don't
know the reasons that made tourism=resort to be deprecated
(couldn't find any discussion about it).


Only "reason" that I can see mentioned is that leisure= is used more
than tourism=, but it doesn't appear to have been discussed anywhere?

Thanks

Graeme


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


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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[António Madeira]

I do believe that uncontrolled should be deprecated in favour of marked,
which iD already did. I also agree that marked/unmarked was a good
improved in the crossing scheme, but it should be cleared on the wiki
page, which seems to favour the uncontrolled tag.
About your considerations:

1 - That depends on the country. For example, in Portugal, all crossings
have right of way over vehicles. So, marking a crossing is the same
whatever the type you map (besides unmarked, of course)

2 - I think there area already tags for all that. You can check them
here under "Additional tags":
https://wiki.openstreetmap.org/wiki/Key:crossing

3 - Same as previous point.

4 - In the same page, under "Mode of transport"

5 - There's also reference to that in the page, but I agree this is not
very clear and is scattered in several wikis, like this:
https://wiki.openstreetmap.org/wiki/Tag:footway%3Dcrossing

Regards,
António


Às 21:40 de 16/09/2020, Taskar Center escreveu:

Hi,

crossing has been a very poor tag because it seems to be the kitchen
sink for all the questions pertaining to crossings...
Many of the attributes that get values in "crossing" are potentially
overlapping and not mutually exclusive, causing a lot of confusion and
poorly tagged crossings. Nevertheless, specifying crossings is very
important because it's a highly contested street region.

The crossing tag has held many values that may overlap, and we should
once and for all split out all these different tags so we can be
mapping what we mean and mean what we map.
Questions we should be answering when mapping a crossing:
1) How is this shared space controlled? A crossing is a high risk
environment where traversal is shared between cars and pedestrians
(they are of unequal footing). So the type of 'control' and 'right of
way' in that space is important to specify. 'uncontrolled' is a very
bad tag in this direction because it has an actual legal,
non-intuitive meaning and many mappers mistakenly think a crossing
that has no traffic signal is uncontrolled- so that's a really bad tag.
crossing_control= ?

2) How is the space demarcated? A crossing may be demarcated by a
number of different ground markers, it may also be physically
demarcated from other street environments by raised footway, tactile
paving or reflectors.
crossing_ref=? (for visual demarcation)
additional tag for physical demarcation?
(I'm in disagreement with those saying it's superfluous or hard to tag
this way)

3) How can a pedestrian call up the signal and how can they sense
whose right of way is currently allowed?
Is there a call button? Does it chirp, speak out, vibrate?

4) who is sharing the way (also a bicycle crossing, animal crossing, etc)?

5) How is the space connected to the rest of the transportation layer?
to the pedestrian layer? Crossings should really only extend from curb
to curb, so that the kerb could be properly tagged for its physical
characteristics. The habit of extending crossings all the way into and
overlapping with sidewalk spaces is a pretty bad idea considering
those are protected pedestrian spaces and have very semantic meaning
to pedestrians than the high risk crossing environment.

I think crossing=marked/unmarked was a really good step in the
direction of getting resolution and refinement on at least one of
these questions above. We should now move together to refine the
definitions and values for these other questions...

Best,
Anat



Sent from my mobile. Please excuse brevity and typos.
On Wed, Sep 16, 2020 at 4:41 PM Clifford Snow mailto:cliff...@snowandsnow.us>> wrote:



On Wed, Sep 16, 2020 at 2:46 PM Graeme Fitzpatrick
mailto:graemefi...@gmail.com>> wrote:




I must admit that I only do crossings as =traffic_signals;
=marked (by itself) for zebra crossings; & =unmarked where
there is provision to cross the road but no signage or roadway
markings on any sort.


I do crossings as crossing=marked/unmarked. I believe software
should be able to identify if the crossing has a stop sign or
traffic signal. Pedestrian walk/don't walk are low on my radar
right now.

I stopped using zebra since they seemed more appropriate for a
crossing in England than where I live in the US.
Crossing=marked/unmarked the only thing I see where I map them.

BTW - I believe in the US hitting a pedestrian in a marked
crossing is illegal most everywhere. In some cities, drivers seem
to believe they have the right of way over pedestrians, even if
they are in a marked crossing.

In another country I've spent some time in, cars definitely have
the right of way over pedestrians.
--
@osm_washington
www.snowandsnow.us 
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - RFC - wait

[António Madeira]

Greetings.

As discussed here in the mailing list, me and L___I have created a
proposal for the key "wait":
https://wiki.openstreetmap.org/wiki/Proposed_features/wait

Please, comment here in the list or in the wiki talk page.


Previous discussions:
https://lists.openstreetmap.org/pipermail/tagging/2020-May/052321.html
https://forum.openstreetmap.org/viewtopic.php?id=69011


Regards,
António.

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

Re: [Tagging] amentiy=donation_centre?

[António Madeira]

There's office=charity and shop=charity.
I think the second one corresponds to what you're looking for.

Regards,
António.

Às 19:26 de 12/11/2022, Timothy Noname escreveu:

I think people already use
Amenity=recycling
Recycling_type=container or centre
And then specify whether it takes clothes and shoes etc
Recycling:clothes=yes

On Sat, 12 Nov 2022, 16:35 Evan Carroll,  wrote:

I don't see anything that would satisfy a donation_centre, a place
where you can donate clothes and other items for resale. Goodwill is a
local chain that operates donation centers, and stores. Things donated
at the donation center are distributed at nearby stores.

If nothing exists, any commentary on amenity=donation_centre?
--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011

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


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

Re: [Tagging] amentiy=donation_centre?

[António Madeira]

I don't know of any charity which buys items to then resell or 
distribute them, although that can happen in some obscure situation.

This, of course, assuming we're talking about a charity in the first place.
If indeed it's a charity, then it's possible to refine it further to 
specify its type of activity.




Às 23:51 de 12/11/2022, Minh Nguyen escreveu:

Vào lúc 12:06 2022-11-12, António Madeira đã viết:

There's office=charity and shop=charity.
I think the second one corresponds to what you're looking for.


Maybe, but only if there's some tag to clarify that the shop=charity 
only accepts items as opposed to selling them. Apparently we avoided 
overloading some other similar tags in that manner: for example, "cash 
for gold" shops are often tagged shop=collector or shop=gold_buyer 
rather than shop=pawnbroker.





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

Re: [Tagging] amentiy=donation_centre?

[António Madeira]

It seems good.
It even has a subtag social_facility 
=clothing_bank 




Às 11:41 de 14/11/2022, Martin Koppenhoefer escreveu:

maybe these can be seen as
amenity=social_facility?

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

[Tagging] key covered=* applied to storage tanks

[António Madeira]

Greetings.

There are closed and open storage tanks, and I think is important to 
differentiate them, specially those used by firefighters and rural 
communities to fight wild fires.
The approved proposal for the key covered=* states "C. denote an area 
such as an underground parking lot, a covered reservoir/cistern or even 
such things as an aquarium (e.g., Kelly Tarlton's, Auckland, NZ), when 
the covering is not a man-made structure that would allow layer 
differentiation."


I would like to know what the community thinks about elaborate that line 
a bit more, to include emergency storage tanks so that people know it's 
ok to add covered=* to those structures.


Regards,
António.

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

Re: [Tagging] key covered=* applied to storage tanks

[António Madeira]

Open tanks are common in wild fires territories, like in Portugal, and 
I'm probably in Spain and Greece.
They're used by helicopters and firefighters, who depend on them in 
heavy mountainous regions, where it's impossible or very difficult to 
get water.
We're talking about water tanks of all sizes and formats, some of them 
are really huge, which are only used for fight forest fires, so it 
doesn't matter if they're contaminated.
For helicopters, they're marked with white and red stripes, so that they 
can be easily spotted from the air.
Some of them rely on rain water to be filled, but most are refilled by 
firefighters with river water or other sources.



Às 05:54 de 11/01/2023, Warin escreveu:


On 10/1/23 03:49, António Madeira wrote:

Greetings.

There are closed and open storage tanks, and I think is important to 
differentiate them, specially those used by firefighters and rural 
communities to fight wild fires.
The approved proposal for the key covered=* states "C. denote an area 
such as an underground parking lot, a covered reservoir/cistern or 
even such things as an aquarium (e.g., Kelly Tarlton's, Auckland, 
NZ), when the covering is not a man-made structure that would allow 
layer differentiation."


I would like to know what the community thinks about elaborate that 
line a bit more, to include emergency storage tanks so that people 
know it's ok to add covered=* to those structures.





Storage tanks around me are all covered, at least all the one I 
remember are. This includes ones used or emergency fire fighting. 
Uncovered ones would be very rare in my country due to the possibility 
of contamination by drowned animals, dirt, dust, tree leaves and tree 
limbs. There are probably regulations about them being covered to 
prevent the breading of mosquitos! So would think covered is part of 
being a storage tank at least here.



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



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

Re: [Tagging] key covered=* applied to storage tanks

[António Madeira]

The main issue is not closed water tanks. That can be a default in OSM.
The issue here is how to inform that a storage_tank is open.
Mind you that there is an infinitude of storage tanks types, but for 
firefighting, those are almost exclusively made in concrete and are open 
for the reasons I stated before.


In my opinion, the cover=* key is the most adequate in these situations, 
because there's no way to define what the roof/coverage of these storage 
tanks would be if they had one.
Stating that a an emergency storage tank is covered=no informs that it 
can be accessible from above.
If, for example, we state that it has a roof=no, you're defining a 
specific kind of covering, when it has none and you have no way to know 
if that would be a roof, a tarp, a shed, etc.




Às 07:22 de 12/01/2023, Volker Schmidt escreveu:
I would say that storage tanks, as default, are closed. So a 
man_made=storage_tank in OSM is closed.
Secondly if a tank is closed (at the top), this is called a roof. 
There are fixed roofs and floating roofs.
See as an example this manufacturer's web site: 
https://www.wermac.org/equipment/storage_tanks_vessels_general.html
So this would translate to roof=yes/no/floating/fixed in OSM speak to 
indicate that a tank is closed-
covered=yes would be correct to indicate an open or closed storage 
tank under some separate kind of covering structure.


Il giorno gio 12 gen 2023 alle ore 09:28 Warin <61sundow...@gmail.com> 
ha scritto:



    On 12/1/23 08:28, António Madeira wrote:
> Open tanks are common in wild fires territories, like in
Portugal, and
> I'm probably in Spain and Greece.
Not in Australia.
> They're used by helicopters and firefighters, who depend on them in
> heavy mountainous regions, where it's impossible or very
difficult to
> get water.

Helicopters here use rivers, dams, not tank water.

Firefighting trucks here use tank water, and they have to pump it out
thought a hose to a nozzle, so contaminates can be a problem.

> We're talking about water tanks of all sizes and formats, some
of them
> are really huge, which are only used for fight forest fires, so it
> doesn't matter if they're contaminated.
> For helicopters, they're marked with white and red stripes, so that
> they can be easily spotted from the air.
> Some of them rely on rain water to be filled, but most are
refilled by
> firefighters with river water or other sources.


Tanks here as a first option take rainwater. If necessary then water
would be trucked in. In remote areas with no population there are no
tanks so trucks would have to suck water from anywhere. In rugged
remote
areas there are probably no roads!

Remote areas here with populations have extremely large tanks for
drinking water... that can be used for fire fighting. Extremely
large =
at least a years water supply with no rain fall.

>
>
> Às 05:54 de 11/01/2023, Warin escreveu:
>>
>> On 10/1/23 03:49, António Madeira wrote:
>>> Greetings.
>>>
>>> There are closed and open storage tanks, and I think is
important to
>>> differentiate them, specially those used by firefighters and
rural
>>> communities to fight wild fires.
>>> The approved proposal for the key covered=* states "C. denote an
>>> area such as an underground parking lot, a covered
reservoir/cistern
>>> or even such things as an aquarium (e.g., Kelly Tarlton's,
Auckland,
>>> NZ), when the covering is not a man-made structure that would
allow
>>> layer differentiation."
>>>
>>> I would like to know what the community thinks about elaborate
that
>>> line a bit more, to include emergency storage tanks so that
people
>>> know it's ok to add covered=* to those structures.
>>>
>>>
>>
>> Storage tanks around me are all covered, at least all the one I
>> remember are. This includes ones used or emergency fire fighting.
>> Uncovered ones would be very rare in my country due to the
>> possibility of contamination by drowned animals, dirt, dust, tree
>> leaves and tree limbs. There are probably regulations about them
>> being covered to prevent the breading of mosquitos! So would think
>> covered is part of being a storage tank at least here.
>>
>>

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


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

Re: [Tagging] key covered=* applied to storage tanks

[António Madeira]

I agree with you, Marc, when you say the use of covered=* is kind of a 
distortion of the tag.

That's why I opened this discussion, because I also had that doubt.

Às 14:02 de 12/01/2023, Marc_marc escreveu:

roof=* is indeed maybe too specific.
but closed or not tank and tank covered by another object
are 2 different things and therefore require 2 keys :
a tank can be closed or open and be under another object or not,
let's not distort the covered key by saying that unlike objects,
when used on tank, it does not describe anymore the presence
of another object that covers the first. 



My problem with storage_tank=open is that it still has ambiguity. Open 
where? On the top, on the side? Which side? This is very important in 
the case of storage tanks destined to firefighters.
My question is: how to convey the critical information that a 
storage_tank (or whatever element we consider) is open on the top?


Às 18:35 de 12/01/2023, Graeme Fitzpatrick escreveu:




On Fri, 13 Jan 2023 at 02:44, Illia Marchenko 
 wrote:



Maybe /storage_tank=open /or similar.


I think this one may be the simplest solution.

Thanks

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

Re: [Tagging] key covered=* applied to storage tanks

[António Madeira]

Às 07:59 de 03/02/2023, Warin escreveu:
In my opinion, the cover=* key is the most adequate in these 
situations, because there's no way to define what the roof/coverage of 
these storage tanks would be if they had one.
Stating that a an emergency storage tank is covered=no informs that 
it can be accessible from above.
If, for example, we state that it has a roof=no, you're defining a 
specific kind of covering, when it has none and you have no way to 
know if that would be a roof, a tarp, a shed, etc.



All the tanks on the OSM wijki page for man_made=storage_tank are 
covered ..


https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstorage_tank



That's probably because this conversation never happened in the OSM 
community, or maybe because open storage tanks are not common and were 
not considered to be included in this tag.
Anyway, that shouldn't impede us to try and come up with an acceptable 
solution to this problem.


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

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

[António Madeira]

I was about to list some points by which I think this proposal has great 
advantages, but I'll stick to these three, where Vincent sums it up much 
more elegantly than I could have written.
As it happened before and it's still happening with other schemes, we 
should always try to improve the overall tagging structure whenever 
possible.
Yes, we have to evaluate if a change like this would give any benefit 
given the amount of work necessary, but I have no doubt that the map 
would be better in terms of data structure, easier to read, easier to 
map and with less ambiguities.


Regards,
António.


Às 16:33 de 13/02/2023, Cartographer10 via Tagging escreveu:


Though also explained in the proposal, let me answer these:

1) New mappers often have trouble learning how to map 
landuse/natural/landcover. It is not always clear when to use the 
different tags and when not. However, assessing the physical landcover 
is much easier. You can say, this area is covered with grass, no 
matter the function of that area. And even experienced mappers like me 
sometimes struggle to find the correct tag why the physical landcover 
is clear. Therefore, the landcover tag will make mapping much easier 
for new mappers.
2) I personally often face that I can't properly access the function 
of a piece of land. Instead of possible incorrectly tagging with with 
e.g. a landuse tag, tagging it with landcover instead is much better 
because you can describe the physical coverage. Somebody with more 
knowledge can then maybe add the function of tag with another tag.
3.1) First of all, it makes rendering easier because the values are 
much better separated. For example, you no longer have a physical tag 
(landuse=grass/flowerbed) in the same key as a functional tag (e.g. 
landuse=residential).
3.2) The tagging system and thus the data is easier to understand for 
a data consumer. Now they have to learn all the strangeness of the 
current landuse/natural/landcover tagging system.


So it is not just "satisfying the data normalisation urges of people 
familiar with working with databases". Using landcover will result in 
long term improvements for the tagging scheme. Even we now have to 
make some hard choices on some existing tags.


Regards,

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

Re: [Tagging] Difference between graffiti and mural

[António Madeira]

I believe it has to do with its longevity and legality. Normally, 
notable art works in the streets are allowed by the city authorities and 
thus last longer. Minor graffiti tends to disappear, either by removal 
or overlapped by other graffiti/paint/whatever.


Regards,
António.

Às 19:51 de 15/04/2023, Mateusz Konieczny via Tagging escreveu:

why only "notable"?


Apr 15, 2023, 19:17 by dcapil...@gmail.com:

Hi,

I would like to properly document the use of
'artwork_type=graffiti', a previously undocumented but widely used
tag, to clarify the difference (if any) between a graffiti and a
mural ('artwork_type=mural').[1]

Any suggestions? Any comments would be appreciated.[2]

Regards,

Daniel Capilla


[1] https://wiki.openstreetmap.org/wiki/Tag:artwork_type%3Dgraffiti

[2]

https://community.openstreetmap.org/t/difference-between-graffiti-and-mural/98056


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



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

Re: [Tagging] Difference between graffiti and mural

[António Madeira]

I'm mainly focusing on one of the "rules" of OpenStreetMap:
https://wiki.openstreetmap.org/wiki/Good_practice#Don't_map_temporary_events_and_temporary_features

A scratching or other kind of paintings on walls or public equipments 
tend to be temporary. A notable graffiti tends to:

- originate from a recognizable artist
- have considerable proportions
- be legally authorized by local authorities
- (thus) last longer and are more easily verifiable

Of course, that doesn't mean that "minor" graffiti can not and should 
not be mapped. The question is: is it relevant?


Regards,
António.

Às 16:06 de 16/04/2023, Daniel Capilla escreveu:

On 4/15/23 at 20:51, Mateusz Konieczny via Tagging wrote:


why only "notable"?


 On 4/16/23 at 15:59,  António Madeira via Tagging wrote:

I believe it has to do with its longevity and legality. Normally, 
notable art works in the streets are allowed by the city authorities 
and thus last longer. Minor graffiti tends to disappear, either by 
removal or overlapped by other graffiti/paint/whatever.


I don't know if "notable" means "not ephemeral". My impression is that 
it refers to "notable artistic quality". Anyway, this is a good point 
(thanks!).


I would like to include something on that in the wiki, on legality or 
longevity. It seems to me that they could be significant in this type 
of work.



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



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

Re: [Tagging] Difference between graffiti and mural

[António Madeira]

That's also important, of course, but not everything that exists is or 
should be mapped.


Do you know why circus tents are not mapped, although they exist? 
Because they are not permanent or, at least, durable enough to be 
considered a mappable element.
Existence is important, if (and this is is also one of OSM's good 
practices) it's relevant enough to be present in the map in one, three, 
six months from now.


Regards,
António.


Às 08:37 de 17/04/2023, Martin Koppenhoefer escreveu:


sent from a phone


On 17 Apr 2023, at 01:08, António Madeira  wrote:

The question is: is it relevant?



no, it is not the question, the requirement is: does it exist?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Tagging] How to revive a tag proposal?

[António Madeira]

Sorry, I didn't get your point, Andy.
The tag was used 32 times, that doesn't seem a "relatively popular" use
of the tag.
Someone using iD (newbie or not) doesn't have any idea on how to map
this structure.

I would like to make a proper wiki and add that feature to iD, but I
never done that and I would like to have more information on how to do
that first step and use what already was started with the previous proposal.


Às 14:45 de 14/01/2020, Andy Townsend escreveu:

On 14/01/2020 17:33, António Madeira via Tagging wrote:

What can I do to revive this proposal and implement this tag?


Just use the tag?

You can see existing values for "man_made" at
https://taginfo.openstreetmap.org/keys/man_made#values , and you can
search in there for "mill" or "olive". "man_made=olive_oil_mill" is
actually relatively popular among "mill" values.

This won't get it automatically included on any map rendering, but if
I was doing one for Southern Europe I'd definitely consider including
something.

Best Regards,

Andy



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



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

Re: [Tagging] How to revive a tag proposal?

[António Madeira]

Às 06:29 de 15/01/2020, Martin Koppenhoefer escreveu:



I would like to make a proper wiki and add that feature to iD


these are 2 completely unrelated actions, for inclusion in iD you do not need a 
wiki entry nor does it influence the decision to add it or not (according to 
one of the maintainers).
You could add a ticket to iD github asking for inclusion in iD.



I am aware of that, but I wouldn't propose something to github without
knowing the correct way of tagging it.




Às 16:23 de 14/01/2020, Markus escreveu:

I'm unsure whether taking over the proposal is a good idea, but you
could write a new proposal (see [1]).

However, note that there is already craft=oil_mill (although not
approved), which could be used together with product=olive_oil. [2]
For big industrial oil mills you may rather want to use man_made=works
+ product=olive_oil.

[1]:https://wiki.openstreetmap.org/wiki/Proposal_process
[2]:https://wiki.openstreetmap.org/wiki/Tag%3Acraft%3Doil_mill

Regards

Markus



I wasn't aware of this proposal, but I like it more than the olive-oil-mill.
Anyway, I can't find any proposal page for it. What would be the correct
way to try and advance with the proposal process? Or should I just
propose it at github's with craft=oil_mill + product=olive_oil?


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

[Tagging] How to tag an utilitarian fountain?

[António Madeira]

Hi there.

In Portugal and most Mediterranean countries, there are literally
thousands of fountains that are not decorative like those examples at
the bottom of the wiki page:
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfountain

I'm talking about fountains that exist in every small village or even at
the side of the road, like these:
https://commons.wikimedia.org/wiki/File:Loriga_-_Fontan%C3%A1rio.JPG
https://commons.wikimedia.org/wiki/File:S%C3%A3o_Jo%C3%A3o_das_Lampas_Fontan%C3%A1rio.jpg

What's the best way of tagging these fountains? They're not decorative,
they're utilitarian architectonic structures made to deliver drinking water.
amenity=fountain doesn't seem to fit here, neither amenity=drinking_water.
I know that we can use fountain=* in both tags, but which one?

Regards.

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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira]

The thing with this tag is that it doesn't encapsulate the historic,
architectonic and cultural meaning of the place. It's difficult to tag a
village central fountain, with it's structure, colours, design etc. and
just tag them with drinking_water.
This creates a lot of ambiguity in Portugal, since these features are
way more important than those found with lights and statues in
roundabouts and alike, due to their historic importance. We even call
them literally "fountains". Tagging them with just
amenity=drinking_water doesn't make them justice. Like I said, maybe
this could be solved with the key fountain=*, I don't know.
Nevertheless, this raises another question: what's the criteria to
consider that the water is drinkable? An official mention on the
fountain or just knowing that people drink the water?



Às 18:57 de 02/02/2020, European Water Project escreveu:

Hi Antonio,

 amenity=drinking_water seems like the right way to go for a
utilitarian drinking fountain.

Best regards,

Stuart



Às 18:57 de 02/02/2020, Joseph Eisenberg escreveu:

The first is designed like a Roman or Medieval drinking fountain, so
amenity=drinking_water is appropriate. The second example does not
have water running in the picture, but if it can be used (perhaps
there is a handle which turns on the water?), the same tag would work.

I would generally use amenity=fountain for decorative water features
which are not designed for drinking.

Joseph E



On Sun, Feb 2, 2020, 22:30 António Madeira mailto:antoniomade...@gmx.com>> wrote:

Hi there.

In Portugal and most Mediterranean countries, there are literally
thousands of fountains that are not decorative like those examples at
the bottom of the wiki page:
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfountain

I'm talking about fountains that exist in every small village or
even at
the side of the road, like these:
https://commons.wikimedia.org/wiki/File:Loriga_-_Fontan%C3%A1rio.JPG

https://commons.wikimedia.org/wiki/File:S%C3%A3o_Jo%C3%A3o_das_Lampas_Fontan%C3%A1rio.jpg

What's the best way of tagging these fountains? They're not
decorative,
they're utilitarian architectonic structures made to deliver
drinking water.
amenity=fountain doesn't seem to fit here, neither
amenity=drinking_water.
I know that we can use fountain=* in both tags, but which one?

Regards.

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


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


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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira]

The problem I see here is that the amenity=fountain wiki description is
too restrictive.
Saying that "A fountain for cultural / decorational / recreational
purposes. (...) This might range from the usual fountain that you'll
find in lots of city centers, up to large fountains like the Trevi
Fountain in Rome (...) The water of those fountains is often not
suitable for drinking."

leaves these kinds of fountain in a limbo.
To me amenity=drinking_water should only be used to map simple water
points where people can drink clearly potable water, like bubblers in
parks or free water dispensers in public areas.
Maybe the wiki could be more clear on that, to allow better mapping of
these features.

Às 19:21 de 02/02/2020, Martin Koppenhoefer escreveu:



sent from a phone


Il giorno 2 feb 2020, alle ore 22:58, Joseph Eisenberg
 ha scritto:

The first is designed like a Roman or Medieval drinking fountain, so
amenity=drinking_water is appropriate. The second example does not
have water running in the picture, but if it can be used (perhaps
there is a handle which turns on the water?), the same tag would work.



I would also use amenity=drinking_water for the first although if it
wasn’t drinking water I would probably tag it amenity=fountain
(clearly there are decorative elements present, and there isn’t a hard
distinction between fountain and drinking fountain). The second
example seems to be designed for animals as well.

If you have recurring types of fountains you could add a new specific
type to the key fountain page:

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

Cheers Martin

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


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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira]

Because almost all these fountains are drinking fountains (we're talking
about many thousands in a minuscule country like Portugal), which it's
their main purpose.
So, stating that "The water of those fountains is often not suitable for
drinking" leaves mappers unnecessarily in doubt.


Às 19:42 de 02/02/2020, Martin Koppenhoefer escreveu:


sent from a phone


Il giorno 2 feb 2020, alle ore 23:33, António Madeira  
ha scritto:

Saying that "A fountain for cultural / decorational / recreational purposes. (...) 
This might range from the usual fountain that you'll find in lots of city centers, up to 
large fountains like the Trevi Fountain in Rome (...) The water of those fountains is 
often not suitable for drinking."

leaves these kinds of fountain in a limbo.


why? IMHO they are not left out from cultural/decorational purposes. 
Decorational purpose does not imply they are decorated themselves. If their 
purpose is not the provision of drinking water they will likely fall under 
“cultural” as well.

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



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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira]

Exactly my point.
That's why I say the wiki is too ambiguous and restrictive.

A practical example (more simple, but still historic and cultural one):
https://www.diariocoimbra.pt/files/news/5d8411800e7e4.png

If I map this with amenity=drinking_water any Portuguese who uses OSM
for searching waypoints is going to search for "fountain", not
"drinking_water". But if I'm a newbie, I go to the amenity=fountain's
wiki and I read "The water of those fountains is often not suitable for
drinking" and I only see examples of decorative fountains there.
That's the main issue I'm struggling with.

But I agree with the amenity=fountain + drinking_water=yes for these
cases, adding the historic and heritage tags wherever possible.


Às 07:25 de 03/02/2020, Martin Koppenhoefer escreveu:

Am Mo., 3. Feb. 2020 um 09:59 Uhr schrieb Warin <61sundow...@gmail.com
>:

The request is for a fountain of utilitarian purpose, not
historic, artistic or cultural.



How could we deny there is cultural or historic background for this
fountain?
https://commons.wikimedia.org/wiki/File:Loriga_-_Fontan%C3%A1rio.JPG

A purely utilitarian purpose water source in the city would look like
this: https://commons.wikimedia.org/wiki/File:Water_tap_brass.JPG

Cheers
Martin

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


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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira]

Thank you for your input and collaboration in clarifying this important
issue regarding fountains.
I agree with your changes and I'll adapt it also in the Portuguese wiki.

I also thank to everyone who participated and helped discuss this.

Regards,
António.

Às 12:21 de 04/02/2020, European Water Project escreveu:


Dear All,


I have made the following changes to the wiki page - which I think
makes it clearer that amenity=fountain && drinking_water=yes is an
acceptable tag pair for fountains of historic or cultural significance
which serve potable water.

Feel free to amend or reverse them if you feel they are inconsistent.

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfountain

Best regards,

Stuart



OLD SENTENCE

The water of those fountains is often not suitable for drinking.

OLD SENTENCE

The water of fountains tagged as amenity=fountain is often not
drinkable – especially the large ornamental ones.

OLD SENTENCE

If providing drinking water is not the primary use of a fountain but
the water is drinkable nonetheless use drinking_water
=yes (see the
tag page for more detailed tagging).

OLD SENTENCE

Please tag a drinking fountain which does not meet the tag criteria,
such as a modern metal fountain in a train station as
amenity=drinking_water. If the fountain provides drinking
water and meets the requisites for being tagged as a fountain, add an
additional tag drinking_water
=yes (see the
tag page for more detailed tagging).

Also :

I have added pictures of three fountains meeting the above criteria
which dispense drinking water. 1)  Paris,France 2) Trento, Italy, 3)
Lorigo, Portugal


On Tue, 4 Feb 2020 at 14:15, European Water Project
mailto:europeanwaterproj...@gmail.com>> wrote:

Thank you Martin,

I will make some limited changes, which I believe are consistent
with the recent discussions, to make it clearer that a fountain -
which deserves that name - can also have a utilitarian function of
delivering drinking water.  I will also add a couple more photos
of historic fountains which serve potable water.

After making these changes, I will send out a summary note to this
list just to be on the safe side.
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfountain

Best regards,

Stuart

On Tue, 4 Feb 2020 at 14:02, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

Am Di., 4. Feb. 2020 um 09:15 Uhr schrieb European Water
Project mailto:europeanwaterproj...@gmail.com>>:

Dear All,

I agree with Antonio that the wiki is too ambiguous and
needs a bit of clean up, including more image examples of
drinking fountains which merit to be tagged as

amenity=fountain
drinking_water=yes

What is the best practice process for making controlled
contributions to the wiki pages ?



there are no controlled contributions to the wiki ;-)
If you feel the page needs clarification or other improvement,
you can either discuss them beforehand, for example here (or
maybe on the talk-page in the wiki, but that may be a longer
process), or you just perform them an see what happens :)
It really depends how much your edit is consistent with the
views of the other "contributors" (particularily those who
guard the wiki), how much you are going to change, in which
domain (userpages, tag pages, organisational pages, summary
pages, pages for beginners, etc.) of the wiki you are editing,
etc.
There is no clear answer to your question.

From my point of view, any fountain where you are starting to
think that it might get the amenity=fountain tag probably
should get this tag.

Cheers
Martin



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


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


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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira]

That is exactly my opinion on this matter.


Às 19:06 de 05/02/2020, Mateusz Konieczny via Tagging escreveu:




5 Feb 2020, 21:06 by selfishseaho...@gmail.com:

On Mon, 3 Feb 2020 at 00:35, Warin <61sundow...@gmail.com> wrote:


amenity=drinking_water is used for;

streams that people drink from

wells that people drink from

taps that people drink from

blubbers that people drink from

fountains that people drink from


As such it is very non descriptive! More of a property key like
drinking_water=yes.


In my opinion, amenity=drinking_water should be abandoned. There are
more descriptive tags for the features amenity=drinking_water is used
for:

* man_made=drinking_fountain
* amenity=fountain
* man_made=water_well
* man_made=water_tap
* natural=spring

And amenity=drinking_water may be
combined with them (except of unfortunate
case of fountain).

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


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

[Tagging] Crosses and how to tag them

[António Madeira]

Hi there.

I was searching a suitable tag to map this kinds of crosses, which are
always religious and most of the time historic:
https://commons.wikimedia.org/wiki/File:Cruzeiro_no_Largo_da_Rep%C3%BAblica_Agualva.jpg
https://commons.wikimedia.org/wiki/File:Cruzeiro_da_Independ%C3%AAncia.jpg
https://commons.wikimedia.org/wiki/File:Igreja_Paroquial_e_Cruzeiro_Colares.jpg

They can be found in church yards, squares, streets, etc.

Now, according to the wiki, I have two options:
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcross  -> which seems
to be used only for summit crosses
https://wiki.openstreetmap.org/wiki/Tag:historic%3Dwayside_cross ->
which seems to be used for a specific kind of cross that doesn't exist
in most countries (not in Portugal, for example).

So, how can I map the other more ubiquitous kind of cross?

Regards.

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

Re: [Tagging] Crosses and how to tag them

[António Madeira]

Yes, both wikis are (were)poorly exemplified, especially when comparing
between them.
As a 900 years catholic country, Portugal has thousands of crosses
everywhere and it would be nice to clearly differentiate them.
The man_made=cross wiki is now much more explicit and not so restrict
with that summit cross thing.

Thanks, Mateusz!

Às 09:12 de 05/03/2020, Martin Koppenhoefer escreveu:


sent from a phone


On 5. Mar 2020, at 02:06, Joseph Eisenberg  wrote:

So if the crosses which you want to map are "always religious and most
of the time historic", probably this tag is more appropriate for most
of them, certainly for all 3 examples which you linked above.



I would see it similarly, for sure the first example. The independence cross, 
second example, typologically would not fall into the “wayside” class IMHO. It 
is kind of those monumental crosses raised at elevated positions, more similar 
to a summit cross.
The cross on the square (3rd example) also isn’t the typical “wayside” type, 
but could be an edge case which is still in. These interpretations are based on 
the assumption that wayside cross actually means wayside cross, and not any 
kind of cross.

I would tag any wayside cross with the historic=wayside_cross tags, not just 
those that are “historic” (what ever this means, it isn’t clear in any way).



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



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

Re: [Tagging] Please fix unnamed square tagging / was: ... description of place=square

[António Madeira]

I agree that the place=square needs some kind of polishing, specially
regarding name tag, which should be mandatory.
In Portugal, the definition of square can have three meanings, depending
on its size and region, but it's easy to map them because they all have
name.

The problem with iD can be its translation/localization. The Portuguese
community had to discuss what was the best translation so that newbies
could get it right more often via iD.
Maybe this must be done also in Germany.


Às 10:46 de 22/03/2020, Tom Pfeifer escreveu:

Yes there is inconsistent use of place=square, in particular for
_unnamed_ objects.
As the place=* key is used to indicate that a particular location is
known by a particular name,
a place=* tag without a name is fundamentally wrong.

(As the world is not black and white, there might be exceptions.)

In Germany alone I found >600 such taggings, and all I probed were:

1. not squares as in the definition, but small and insignificant paved
surfaces, like a round piece of footway in a park, the service yard of
a fire station, or similar.

2. they were all added by the iD editor, typically since 2018.

Thus my assumption is that place=square is suggested in an iD preset
to unsuitable features.
Could somebody with sufficient iD insight check what that preset
suggests, and why it does not ask for names?

Further I recommend that everybody checks their area for place=square
_without a name_, evaluate what it is and adjust the tagging. This can
not (!) be done mechanically, besides the issues with mechanical
edits, because the correct tagging will differ (e.g. highway=service +
area=yes; or highway=footway + area=yes), or the tag was correct
indeed and the name has been forgotten.

Query for unnamed square in a bounding box:
https://overpass-turbo.eu/s/ROw

I also suggest to update wiki descriptions of place=* tags, upgrading
the "name=*" from "useful combination" to "required", and add that to
validators.

tom

On 21.03.2020 01:32, Joseph Eisenberg wrote:

A few of us have been updating the Tag:place=square page, and Square:



Unfortunately, this tag has been used rather inconsistently around the
world, often for any feature that includes the word "square" or a
translation of that word, or which might be considered similar in the
local language.

Some poorly mapped examples are shown on github:

*https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593045858

*
https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593046473
*
https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593046673

Check if any of the place=square features in your area should instead
be junction=yes (for a named street intersection or road junction) or
leisure=park or place=neighborhood.


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



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

Re: [Tagging] Please fix unnamed square tagging / was: ... description of place=square

[António Madeira]

In Portuguese it's "Praça", similar to Piazza, which comes from the
Latin "platea".
Depending on its size and location, it can be named officially as
"Praça", "Largo"or "Praceta".

The English description of place=square in iD is empty.

https://i.imgur.com/AIqEuuC.png



Às 21:41 de 22/03/2020, Joseph Eisenberg escreveu:

Curious: what is the translation used in Portuguese?

Do you also know the English description of place=square used in iD?

On 3/23/20, António Madeira  wrote:

I agree that the place=square needs some kind of polishing, specially
regarding name tag, which should be mandatory.
In Portugal, the definition of square can have three meanings, depending
on its size and region, but it's easy to map them because they all have
name.

The problem with iD can be its translation/localization. The Portuguese
community had to discuss what was the best translation so that newbies
could get it right more often via iD.
Maybe this must be done also in Germany.


Às 10:46 de 22/03/2020, Tom Pfeifer escreveu:

Yes there is inconsistent use of place=square, in particular for
_unnamed_ objects.
As the place=* key is used to indicate that a particular location is
known by a particular name,
a place=* tag without a name is fundamentally wrong.

(As the world is not black and white, there might be exceptions.)

In Germany alone I found >600 such taggings, and all I probed were:

1. not squares as in the definition, but small and insignificant paved
surfaces, like a round piece of footway in a park, the service yard of
a fire station, or similar.

2. they were all added by the iD editor, typically since 2018.

Thus my assumption is that place=square is suggested in an iD preset
to unsuitable features.
Could somebody with sufficient iD insight check what that preset
suggests, and why it does not ask for names?

Further I recommend that everybody checks their area for place=square
_without a name_, evaluate what it is and adjust the tagging. This can
not (!) be done mechanically, besides the issues with mechanical
edits, because the correct tagging will differ (e.g. highway=service +
area=yes; or highway=footway + area=yes), or the tag was correct
indeed and the name has been forgotten.

Query for unnamed square in a bounding box:
https://overpass-turbo.eu/s/ROw

I also suggest to update wiki descriptions of place=* tags, upgrading
the "name=*" from "useful combination" to "required", and add that to
validators.

tom

On 21.03.2020 01:32, Joseph Eisenberg wrote:

A few of us have been updating the Tag:place=square page, and Square:
Unfortunately, this tag has been used rather inconsistently around the
world, often for any feature that includes the word "square" or a
translation of that word, or which might be considered similar in the
local language.

Some poorly mapped examples are shown on github:

*https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593045858

*
https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593046473
*
https://github.com/gravitystorm/openstreetmap-carto/issues/4043#issuecomment-593046673

Check if any of the place=square features in your area should instead
be junction=yes (for a named street intersection or road junction) or
leisure=park or place=neighborhood.

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


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


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



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

Re: [Tagging] Updating definition and description of place=square

[António Madeira]

Às 05:08 de 30/03/2020, Martin Koppenhoefer escreveu:

Am Mo., 30. März 2020 um 01:11 Uhr schrieb Kevin Kenny
mailto:kevin.b.ke...@gmail.com>>:

One example: Berkeley Square in London.  In form, it's a public
garden, but even the English designate it a town square. As I
understand it, an Englishman would not raise eyebrows at a
sentence: "Winston Churchill, as a child, lived in Berkeley
Square.  The Churchills' house, № 48, is the one entirely
residential building remaining there; the rest of the buildings
are all offices of financial concerns, much like the rest of
Mayfair."



The thing is that squares often also serve as addresses and can be
somehow seen very similar to streets, so the same as you can live in a
street (meaning you live in a house on this street), you could also
live on a square (a house bordering this square). At least it works
like this in some languages I am aware of.

Cheers
Martin



Like in Portugal, for example. In most cases, the name of the square is
the address of the adjacent buildings.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] city limit sign end

[António Madeira]

That's not correct. This tag is used all over the world, as you can
check at taginfo:
https://taginfo.openstreetmap.org/tags/traffic_sign=city_limit#map

Às 10:55 de 12/04/2020, Volker Schmidt escreveu:

Looking closer it turns out that the city_limit=* key is exclusively
used in Germany, but nowhere else. But Germany is not the only country
that use end-of-city-limit signs. Are there other alternatives?

Volker



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

Re: [Tagging] city limit sign end

[António Madeira]

Sorry, my bad.

Às 19:45 de 12/04/2020, Volker Schmidt escreveu:

My statement about the limitation to Germany regarded the tag
city_limit=* , not the tag traffic_sign=city_limit.

On Sun, 12 Apr 2020, 20:07 António Madeira, mailto:antoniomade...@gmx.com>> wrote:

That's not correct. This tag is used all over the world, as you can
check at taginfo:
https://taginfo.openstreetmap.org/tags/traffic_sign=city_limit#map

Às 10:55 de 12/04/2020, Volker Schmidt escreveu:
> Looking closer it turns out that the city_limit=* key is exclusively
> used in Germany, but nowhere else. But Germany is not the only
country
> that use end-of-city-limit signs. Are there other alternatives?
>
> Volker


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


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


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

Re: [Tagging] Refining heritage tag

[António Madeira]

Às 10:15 de 14/04/2020, Paul Allen escreveu:

On Tue, 14 Apr 2020 at 04:33, António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

- is ref:xxx=* a good solution to add the official reference
code/number?


No.  But that's what we have.  With hindsight we'd have done it
differently.  But
it's now been used so often it would be very difficult to fix all the
existing uses.

More importantly, heritage/historic tagging was started by the
Historic Place
project and they're the only ones (that I know of) that make use of
those tags.
They're the ones you'd have to convince to alter their code to handle your
proposed change.


You mean this?
https://wiki.openstreetmap.org/wiki/Open_Historical_Map



- we've adopted the tag protection_title=* to define the
protection category of the heritage, although the German wiki
clearly states this is used for natural areas only. Would it be
better to create another tag or is OK to adapt this one, since
this is also a protected feature?

It's a protected feature but not a protected natural area.  The wiki page
for it says it requires boundary=national_park or
boundary=protected_area so
it shouldn't be used this way.  That said, other people have used it
that way.
Would xxx:criteria fit your usage?


The "problem" with criteria is that it seems to be used with numbers or
abbreviations, like a list that corresponds to some longer definitions.
For example: we could create a criteria list with 1, 2, 3, 4 which would
correspond to the 4 levels of heritage existing in Portugal, but how
would data consumers know what those numbers mean? Or if you use
abbreviations, like MN, IIP, etc. we would have the same problem.
The protection_title=* seemed to solve that, but it's not 100% accurate.
I don't want to use it if it's not correct, so maybe we could create
something like heritage:designation=* which would go in line with the
heritage scheme.



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

Re: [Tagging] insurance health

[António Madeira]

I agree that a logical breakdown of the insurance field should be
preferred rather than creating several type of insurance offices.
I would rather use office=insurance + insurance="type" than
office=health_insurance;car_insurance;house_insurance;etc.


Às 21:16 de 14/04/2020, Greg Troxel escreveu:

Agustin Rissoli  writes:


In Argentina we want to correctly tagging offices of companies dedicated to
what we call prepaid medicine, by paying a monthly fee you access a series
of medical benefits.
We are hesitating between these tags:

office=health_insurance
It has no wiki, it has 185 uses, the majority in Belgium since it was
created in 2013, they even have a preset in JOSM.

office=insurance + insurance=health
It has a wiki, curiously created by a Belgian user in 2018, it has 66 uses.
It is the only documented insurance=* key.

While I see Joseph's point about what is normal, I think that's an
artifact of some, perhaps many societies.

I think if this is an office selling insurance of any kind, it should
have office=insurance and then a subtag.  I don't think it helps map
data users to make a second top-level tag.  Basically I think tags
should follow semantics as much as possible, when that's reasonable.

For what it's worth, around me, also in the US, my impression is that
most "insurance offices" are really "property and casualty insurance
offices".  This is for your car, and your house.  But typically not life
insurance so much, and not health.  (I am not sure about professional
liability and business interruption insurance.)

As always, we should step back and ask "when we add these tags, who will
use them, and why".  I see two points:

   some kind of overall statistics of types of businesses

   wanting to find a particular thing

In the case of office=insurance insurance=health, if that's what you
want, you can find it by searching for that just as well as searching
for office=health_insurance.

But if you  want to  ask "how many insurance offices are there and what
is the breakdown by type", it's much more natural to search one key and
switch on subtag, then to consult some information -- which we don't
really have a way to maintain -- that says office=insurance,
office=health_insurance and office=foo_insurance are all types of
insurance offices.

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



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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[António Madeira]

Maybe I missed something on this long thread but I don't understand why
we need to divide large refugee site from small refugee site. Why create
ambiguities if all of them are refugee sites?
Do we divide big schools from small schools? Or small theatres from big
theatres?
Why don't we just create the amenity=refugee_site tag and populate it
with basic keys like name, operator, population, etc. and then map
whatever exists inside that area, be it buildings, social facilities,
etc. There are refugee_sites which are de facto towns and villages, so
those would be mapped as a normal place.

Às 16:29 de 16/04/2020, Manon Viou escreveu:

Hello,
According to Martin and Warin, the difference between large and small
refugee site is not clear enough,
Martin suggested to use population capacity, for instance less than
200 people fro small refugee site,
Warin suggested to use number of square meters,
For what I have observed, small facilities sheltering refugee (for
instance: refugee centers, accommodation center, care and hosting
center, church) are not exactly what we can call refugee site. the
difference, beyond the number of building, number of population or
square meter, is quite obvious. Is it really necessary to set a
precise rule ? I would rather suggest to share some example (like the
ones mentioned above) in order to help contributors to decide if it
rather an amenity=refugee_site or a social_facility=shelter.
Regards,
Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com> a écrit :

On 16/4/20 1:23 am, Manon Viou wrote:

Thanks Martin, yes, refugee sites should always be temporary even
if, as you said, some turn to be very long term places. That's why
we do not suggest to add temporary/permanent options.
Manon



In which case the description for amenity=social_facility +
social_facility=shelter is not correct.


If it is to be done on area then specify the number of square meters
rather than the number of buildings???

Buildings can be a of different sizes and capacities. An area could
be more consistent as to the number of people.

Imagery may not be up to date so counting buildings may not be possible.



Le 15 avril 2020 à 11:36, Martin Koppenhoefer <
dieterdre...@gmail.com > a écrit :

sent from a phone


On 15. Apr 2020, at 01:13, Warin < 61sundow...@gmail.com
> wrote:

I would think amenity=refugee_site is an area set aside for the
non-temporary residential use of refugees


maybe I’m a dreamer, but I would expect all refugee related
features to be “temporary”, even if we are talking about relatively
long periods of time

Cheers Martin


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



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


CartONG- Humanitarian mapping and information management


Manon Viou

*Coordinatrice projet Missing Maps*

Email: m_v...@cartong.org  | Skype: manon.viou
Phone: +33 (0)4 79 26 28 82 | Mobile: +33 (0)7 83889839

Address: Chambéry, France - Lon: 05°55'24''N | Lat: 45°30'20''E


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


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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[António Madeira]

If a refugee site has a well established name (and, unfortunately, there
are many examples all over the world), I don't see why it can't have a
"place" tag.

Às 18:24 de 17/04/2020, lukas-...@web.de escreveu:

Hi,
my question is whether this then rather would be something for the
"place" tag? Or did we maybe have that discussion already?
--Lukas
*Gesendet:* Freitag, 17. April 2020 um 18:28 Uhr
*Von:* "Manon Viou" 
*An:* "Tag discussion, strategy and related tools"

*Betreff:* Re: [Tagging] Feature Proposal - RFC - Refugee Site Location
Hello everyone,
It seems I haven't been very clear in my explanations; I sometimes
have a bit of trouble choosing the right word (especially in English).
And I think the “small”/”large” discussion is going the wrong direction…
The new tag we want to propose is to map refugee camps or as it’s
seems better to say in English now : refugee sites. So we want to map
*human settlement*.
The social_facility=shelter tag is very suitable to map single or
individual building or a small group of buildings like a refugee
center, an accommodation center or a care and hosting center for refugees.
But (according to many people now)  the social_facility=shelter tag is
not suitable to map  refugee camps that are human settlements,
populated places where hundreds or  thousands people live.
That’s why we propose to create a new value for the amenity tag :
amenity=refugee_site, to map human settlement where refugees can find
protection.
kind regards,
Manon

Le 17 avril 2020 à 13:03, Warin <61sundow...@gmail.com> a écrit :
On 17/4/20 5:29 am, Manon Viou wrote:

Hello,
According to Martin and Warin, the difference between large
and small refugee site is not clear enough,
Martin suggested to use population capacity, for instance less
than 200 people fro small refugee site,
Warin suggested to use number of square meters,
For what I have observed, small facilities sheltering refugee
(for instance: refugee centers, accommodation center, care and
hosting center, church) are not exactly what we can call
refugee site. the difference, beyond the number of building,
number of population or square meter, is quite obvious.

?? How is it 'obvious'???

I have no idea of what that 'obvious' thing is!

Is it really necessary to set a precise rule ?

At the moment there is nothing that can be used to distinguish
between the two.

Suggestion have been made on the number of buildings, number of
people and the area.

Please tell us how you distinguish between them.

I would rather suggest to share some example (like the ones
mentioned above) in order to help contributors to decide if it
rather an amenity=refugee_site or a social_facility=shelter.

Examples are fine. But there must be a statement in words of the
difference between them.

Regards,
Manon

Le 16 avril 2020 à 02:16, Warin <61sundow...@gmail.com>
 a écrit :
On 16/4/20 1:23 am, Manon Viou wrote:

Thanks Martin, yes, refugee sites should always be
temporary even if, as you said, some turn to be very
long term places. That's why we do not suggest to add
temporary/permanent options.
Manon

In which case the description for amenity=social_facility
+ social_facility=shelter is not correct.

If it is to be done on area then specify the number of
square meters rather than the number of buildings???

Buildings can be a of different sizes and capacities. An
area could be more consistent as to the number of people.

Imagery may not be up to date so counting buildings may
not be possible.

Le 15 avril 2020 à 11:36, Martin Koppenhoefer <
dieterdre...@gmail.com
> a écrit :
sent from a phone

On 15. Apr 2020, at 01:13, Warin <
61sundow...@gmail.com
> wrote:
I would think amenity=refugee_site is an area
set aside for the non-temporary residential
use of refugees

maybe I’m a dreamer, but I would expect all
refugee related features to be “temporary”, even
if we are talking about relatively long periods of
time
Cheers Martin

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

__

Re: [Tagging] Refining heritage tag

[António Madeira]

Hi, Martin.
Thank you for your input.



Às 06:38 de 17/04/2020, Martin Koppenhoefer escreveu:

Am Fr., 17. Apr. 2020 um 04:27 Uhr schrieb António Madeira via Tagging
mailto:tagging@openstreetmap.org>>:

After communicating with lutz from Historic.Place, he told me they
didn't create this heritage scheme, they just adopted it.
I took the opportunity to present him my proposal of refining this
scheme and I got his support to go ahead with it, so I'm
presenting it here in order to make the necessary adjustments with
a new proposal.

heritage=* - This is the main tag, which uses the admin_level [not
changed].


currently 147558 instances


heritage:operator=xxx - This is the tag for the official operator.
I propose using separators [;] in those cases where an heritage
has an international and a national operator.



currently 122076 instances, of which around 150 already have semicolon
separated multivalues. There are not many multivalues, but I would see
it as the already standard method (based on values of other tags), and
believe it would be ok to add this to the wiki without further voting.

heritage:ref:xxx=* - This tag is for the code/number reference of
the operator(s) above. It changes the previous ref:xxx=*



there are already some heritage:ref tags (and subtags like
heritage:ref:vie)
name 12188 heritage:ref, and 500+ heritage:ref:xxx
It would be more complicated to count "ref:xxx" combined with heritage.
I am more reluctant to welcome this idea. What would be the benefit?
Generally, standard tags (like "ref" and derived tags like ref:mhd)
would seem the usual way, no? We do not add highway:ref=* tags for
example, because the tags refer to the object they are put on.
Prefixing them with "heritage" would only invite people to mix up
objects of different nature into the same OSM object.



The benefit would be exactly that, to be able to count references which
we know for certain that are related to the heritage scheme.
I know there are many ref tags that don't follow this procedure, but if
this is useful why not starting to adopt it for some schemes like this one?
It would turn the entire scheme more tight and organized, with a more
logical structured "tree".
Anyway, this will obviously have some resistance, but I think it is well
worth to debate about it.




heritage:xxx:criteria=* - This tag is for the classification
criteria used by the xxx operator. It changes the previous
xxx:criteria=*
heritage:xxx:inscription_date=* - This tag is used for the date
the heritage was officially registered by xxx operator. It changes
the previous xxx:inscription_date=*



same comment as above for ref.


heritage:xxx:designation_title=* - This tag is used for the
heritage title (international or national). This is new and is an
attempt to circumvent the use of protection_title=* which is wrong
in this context.



why is protection title "wrong"?


As discussed in this thread before, the protection title tag was created
for natural areas. Unless an heritage site coincides with a natural
protected area, it's not correct to use that tag. Unless we extend its
scope for this scheme.




heritage:xxx:website=* - Used for the heritage official website 
(international or national).



same comment as above for ref. I would even suggest to use a plain
"website" rather than an xxx:website, as long as there is only one
operator (very common situation).
Current use is 15772 heritage:website and 11258 website, plus 949
heritage:website:sipa (looks like an import), 713 contact:website, 225
heritage:website:arqueologia and 39 heritage:operator:website (IMHO to
deprecate, we're not a general web directory)

In general, let's use standard tags as long as there aren't good
reasons for creating specific derivative tags.


I agree with your observations here, but we need to consider that the
website of the building (or whatever) has its own website, and the
official operator has its proper webpage related to the heritage
classification. This is very frequent and it would be important to
differentiate between the normal website and the operator's website.


Regards,
António.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Refining heritage tag

[António Madeira]

Now that I've read the German wiki more carefully, I realized that they
consider World Heritage not only as natural areas but also for
buildings, although they clearly state "Always with *boundary
=protected_area
*"
which makes this somewhat confuse... I don't mind at all to use
"protection_title", but I prefer not to create unnecessary conflicts.


Às 20:43 de 17/04/2020, Martin Koppenhoefer escreveu:


sent from a phone


On 18. Apr 2020, at 01:04, Paul Allen  wrote:

The fraction of heritage POIs which are
protected areas is less than 1%.


I still don’t see why we would need a new tag heritage_title rather than the 
established protection_title
Maybe protected “area” is a strange tag for a building, but this doesn’t extend 
to protection_title, or are there objects where we would need both tags?

Cheers Martin


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

Re: [Tagging] Refining heritage tag

[António Madeira]

So, I would like to know what would be the technical pros and cons
regarding heritage:ref:operator=* vs ref:operator=* , i.e. the database
use, rendering, consulting, exporting etc.


Às 21:04 de 17/04/2020, Paul Allen escreveu:

On Sat, 18 Apr 2020 at 00:43, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

I still don’t see why we would need a new tag heritage_title
rather than the established protection_title##


From https://wiki.openstreetmap.org/wiki/Key:protection_title

    Requires
    boundary=national_park
    boundary=protected_area

So not applicable to heritage=*.

Admittedly, the wiki page for protected_area states that it can be used
on heritage sites, but when you read through the rest of the page it's
not talking about buildings.  Or even a castle complex. It's talking about
things like "registered historic landscapes" (a UK term), which are
historic and therefor e have heritage value, but aren't covered by the
existing heritage=* key.  Instead they're covered by
boundary=protected_area (I think).

The heritage=* and boundary=protected_area are pretty much orthogonal
in what they cover.  There might be cases where both tags apply but they
are going to be exceptions rather than the rule.

--
Paul




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

Re: [Tagging] Refining heritage tag

[António Madeira]

As I already wrote before in this thread, lutz already agreed with and
supported my proposal.
My problem with the actual ref tag is that there are many ref tags for
other schemes and elements, but I don't know if this concern is
pointless or not.
I would like to see this scheme more organized and not so ambiguous data
wise, but I don't know if that's technically better or if there are
actual problems with ref tag being "all over the place".


Às 19:56 de 20/04/2020, Paul Allen escreveu:

On Mon, 20 Apr 2020 at 16:47, António Madeira mailto:antoniomade...@gmx.com>> wrote:

So, I would like to know what would be the technical pros and cons
regarding heritage:ref:operator=* vs ref:operator=* , i.e. the
database use, rendering, consulting, exporting etc.


AFAIK, only one map makes use of heritage*.  So if you can persuade
lutz that
your scheme is a good one, it will be dealt with accordingly.

--
Paul



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

Re: [Tagging] Refining heritage tag

[António Madeira]

This is the main reason why I came up with this refinement.
For example, if I search for "ref:" at taginfo, there are *millions* of
results. I believe this has implications in data management, although
I'm by no means an expert on that matter.


Às 20:57 de 20/04/2020, Paul Allen escreveu:

As it stands, there is a possibility for namespace collision. That is
theoretically
a problem.  An object might have two references, but we've made heritage
references take the form ref:xxx=* so if the other ref is of the form
ref=*
there won't be a collision.  But it's also possible that both schemes want
to use ref:xxx.  So adding heritage to the ref key fixes that remote
possibility.

As it stands, overpass queries would not be able to distinguish the
right ref
if an object has a heritage ref:xxx=yyy and a non-heritage ref:aaa=bbb.  A
remote possibility.  Adding heritage to the ref key fixes it.




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

Re: [Tagging] Refining heritage tag

[António Madeira]

So, what's the rationale for using heritage:operator and not heritage:ref?
It's these inconsistencies that breaks my logic...


Às 22:19 de 20/04/2020, Paul Allen escreveu:

On Tue, 21 Apr 2020 at 02:10, António Madeira mailto:antoniomade...@gmx.com>> wrote:

This is the main reason why I came up with this refinement.
For example, if I search for "ref:" at taginfo, there are
*millions* of results. I believe this has implications in data
management, although I'm by no means an expert on that matter.


Most of the heritage stuff I've mapped has been in Wales, so I search for
ref:cadw not ref:.  If you know the heritage operator you can get
reasonably
sensible results.  If you were after a count of heritage sites over the
whole  worlds then search for heritage:operator at taginfo.

--
Paul



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

Re: [Tagging] Refining heritage tag

[António Madeira]

Yes, I know that Joseph, but the problem is not in the scheme itself, is
between the tags of this scheme and the tags of other schemes.
If you have millions of tags like ref:"whatever", how are you going to
distinguish between them if you make a query or some kind of data reading?

Since we're going on circles around the same issue, I'll leave it as it is.
Regarding "protection_title=", I'll keep using it, as stated here:
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Social-protected-area

Regards and thank you all for your considerations.
António.


Às 07:59 de 21/04/2020, Joseph Eisenberg escreveu:

The heritage:operator tag is needed because “operator=“ is the
operator of the feature, not the operator of the heritage status.

If you have an old residential building which is still in active use,
the operator= is whoever manages the building now, but it might also
have a heritage:operator= which will be a different value.

This isn’t necessary with the ref, since the operator is in the key in
the format ref:

—Joseph

On Tue, Apr 21, 2020 at 7:24 PM Paul Allen mailto:pla16...@gmail.com>> wrote:

    On Tue, 21 Apr 2020 at 02:37, António Madeira
mailto:antoniomade...@gmx.com>> wrote:

So, what's the rationale for using heritage:operator and not
heritage:ref?
It's these inconsistencies that breaks my logic...


Why are the eyes of tetrapods (fish, reptiles, birds, mammals) wired
backwards?  Why does the recurrent laryngeal nerve from the brain
to the larynx go down into the chest and around the aorta?  Why do
baleen whales develop teeth in embryo that are resorbed before they
are born?

Same answer.  The heritage tags evolved.  If somebody had sat down and
thought everything through, it might have turned out differently.

The endless bickering here is to try to ensure we think things through
and don't end up with schemes that, in hindsight, are sub-optimal.

--
Paul

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


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


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

Re: [Tagging] Refining heritage tag

[António Madeira]

Thanks, that's all I needed to know.


Às 20:43 de 21/04/2020, Martin Koppenhoefer escreveu:

by looking at the combination: you query for heritage AND ref tags in 
combination. No need to change the tags for this.



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

[Tagging] How to tag way with two traffic signs affecting different directions?

[António Madeira]

Hi there.
Following this topic, I would like to extend the discussion to the mail
list, because I think this is an important issue that should have a
broad solution.
https://forum.openstreetmap.org/viewtopic.php?id=69011


Several months ago, I stumbled upon a problem which I found no solution
to. At the time, I searched for help in the Telegram channel and someone
gave me a solution that I've been using since then.
Meanwhile, another mapper contacted me in private and told me about
another kind of solution to this problem.
I would like to know if these are both valid and/or which one is more
useful for routing.

I'm showing here illustrations of the problem and the two solutions given.


*Problem #1:*
https://i.imgur.com/8MiiKFH.png

The selected way has a STOP at the end for those who turn left and a
give way sign for those who turn right.
The "problem" is: how to map those two signs correctly and make them
useful for routing software?

*Problem #2:*
https://i.imgur.com/cLFRtLG.png

There are no painted islands and no physical divisions. The middle lane
as a STOP sign to turn left.

If you have
lanes=3;
lanes:forward=1;
lanes:backward=2;
turn:lanes:backward=left|through

how do you indicate that there's a STOP on one of them?




*Solution #1:*
https://i.imgur.com/HDmvZiB.png

Use both traffic signs on the way and create one enforcement relation
for each of them. A "from" enforcement on the STOP and a "to" on the
left segment of "Rua Paulo VI" and a "from" enforcement on the give way
and a "to" on the right segment of "Rua Paulo VI".


*Solution #2:*
Just use the following tags:
highway=secondary
lanes=2
oneway=yes
name=Rua da Quinta
ref=EN 350
surface=asphalt
traffic_sign:lanes=stop|give_way
turn:lanes:forward=left|right

I never used traffic_sign:lanes tag, but it seems legit, although
Taginfo only shows 20 uses for this:
https://taginfo.openstreetmap.org/search?q=traffic_sign%3Alanes


Any considerations would be much appreciated.

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

Re: [Tagging] How to tag way with two traffic signs affecting different directions?

[António Madeira]

Às 15:36 de 02/05/2020, Philip Barnes escreveu:

Hi António
Normally I would add direction:forward or direction:backward to a stop
or give_way to indicate which direction it applies in.

Where speed limits are different you can use maxspeed:backward and
maxspeed:forward.

Phil (trigpoint)


Phil, you need to read more carefully what's this about, because it's
way more complex than that.



Às 16:47 de 02/05/2020, Jarek Piórkowski escreveu:

António, interesting question. In my interpretation, relation
type=enforcement seems to be intended for recording or punishing
violations of rules (wiki "devices that measure and document traffic
violations") - not for the restrictive rules themselves.

Instead, maybe type=restriction + restriction=stop, with
from-to-via-position? It's not widely used, but it does have a couple
of mappers: https://taginfo.openstreetmap.org/tags/restriction=stop

Possible examples:
https://www.openstreetmap.org/relation/3884744 except with "to" as a
way rather than node
https://www.openstreetmap.org/relation/2966044 except probably with
the to-way split at the intersection

traffic_sign:lanes looks like it would also work, and the existing
examples seem a bit more fleshed out than for restriction=stop -
depends if you prefer :lanes tags or relations, I suppose.


This is an open issue for several years, without a seamless solution,
but I see this popping up many times when mapping.
I'm not very knowledgable about relations, and I'm sorry if I'm a bit
confused here, but doesn't a restriction relation means the exact
opposite of what's intended here?
I mean, I want to apply a STOP sign to a given lane (in a way with two
lanes, for example) and force its action to a given direction on the new
road ahead.
The wiki page for this type of relation doesn't mention STOP nor GIVEWAY
signs, but in the discussion page there this:
https://wiki.openstreetmap.org/wiki/Talk:Relation:restriction#Incorporate_.27give_way.2Fyield.27_and_.27stop.27_as_possible_restrictions

If neither relation scheme (enforcement or restriction) can be applied
here (for complexity or incompatibility reasons), why not use the
existing lanes scheme?
Like this:

|highway=stop stop:lanes=yes|no stop:turn:lanes=left |




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

Re: [Tagging] Help explain the difference between path and track

[António Madeira via Tagging]

I mean physically. If a vehicle can't use it legally, the access key
must be activated, like in any other feature.
I believe that the legality of circulation shouldn't interfere with the
tagging of a track. For example: a dirt highway in a Natural Reserve
should be always a track, regardless of who can use it. If it's only for
rangers or emergency vehicles, there are tags to reflect that. If only
bikes or hikers can use it, then it's a path.


Às 13:56 de 10/06/2020, Mike Thompson escreveu:



On Wed, Jun 10, 2020 at 10:26 AM António Madeira
mailto:antoniomade...@gmx.com>> wrote:
> If a motor vehicle can and uses the way, it's a track.

When you say "can use" do you mean both legally and physically, or
only physically?. If legally, do you mean just the general public? As
someone pointed out, law enforcement has access to almost everything
via motor vehicle.  Also, the land manager (e.g. parks and recreation
department) has access to almost all of their properties via motor
vehicle.

Does this only apply to unpaved ways?

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


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

Re: [Tagging] oneway=yes on motorways

[António Madeira via Tagging]

So, should this contradiction be eliminated from the wiki or not?


Às 09:32 de 26/05/2020, Mateusz Konieczny via Tagging escreveu:

Based on my experience it is usually better to write something, even
not ideal and
ask for a review.

"Someone should write/expand it" is typically ignored.

May 26, 2020, 10:58 by vosc...@gmail.com:

Please come back to my original question: /I would like to
eliminate the contradiction in the wiki. What wording do you propose?/

On Tue, 26 May 2020 at 10:23, Jean-Marc Liotier mailto:j...@liotier.org>> wrote:

On 5/26/20 5:44 AM, Paul Johnson wrote:


It can't hurt to specify oneway=yes. I have noticed that
the JOSM style
that shows lane counts and lane use will sometimes not
show ways
properly if oneway=yes isn't there, but that's probably a
bug in the
style more than an indictment of implying oneway=yes.


I'm on the side of "team tag explicitly" on this.  If
anything, it gives validators more to work with if you start
doing something weird.


Isn't that what oneway=no is for ?

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



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


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

Re: [Tagging] oneway=yes on motorways

[António Madeira via Tagging]

In this

section, I suggest changing the text:
"These ways should all point direction of travel and be tagged with
oneway=yes."

to

"These ways should all point direction of travel and imply oneway=yes
(like junction=roundabout), therefore the oneway tag is redundant and
should be avoided."



Às 17:09 de 14/08/2020, Mateusz Konieczny via Tagging escreveu:

It is nicer to avoid contradictions, but I am not planning to work on
this specific case.

If you want you may propose specific edit and post it here for review
(or make it and discuss if someone disagrees).

"Someone should write/expand it" is typically ignored.

Aug 14, 2020, 20:35 by tagging@openstreetmap.org:

So, should this contradiction be eliminated from the wiki or not?



Às 09:32 de 26/05/2020, Mateusz Konieczny via Tagging escreveu:

Based on my experience it is usually better to write something,
even not ideal and
ask for a review.

"Someone should write/expand it" is typically ignored.

May 26, 2020, 10:58 by vosc...@gmail.com :

Please come back to my original question: /I would like to
eliminate the contradiction in the wiki. What wording do you
propose?/

On Tue, 26 May 2020 at 10:23, Jean-Marc Liotier
mailto:j...@liotier.org>> wrote:

On 5/26/20 5:44 AM, Paul Johnson wrote:


It can't hurt to specify oneway=yes. I have noticed
that the JOSM style
that shows lane counts and lane use will sometimes
not show ways
properly if oneway=yes isn't there, but that's
probably a bug in the
style more than an indictment of implying oneway=yes.


I'm on the side of "team tag explicitly" on this.  If
anything, it gives validators more to work with if you
start doing something weird.


Isn't that what oneway=no is for ?

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



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




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


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

Re: [Tagging] oneway=yes on motorways

[António Madeira via Tagging]

iD already adds oneway=yes automatically, so no problem there. I don't
know about JOSM, but that can be added as a warning/alert if there isn't
one already.


Às 22:04 de 14/08/2020, Graeme Fitzpatrick escreveu:




On Sat, 15 Aug 2020 at 07:59, António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

In this
<https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway#How_to_map>
section, I suggest changing the text:
"These ways should all point direction of travel and be tagged
with oneway=yes."

to

"These ways should all point direction of travel and imply
oneway=yes (like junction=roundabout), therefore the oneway tag is
redundant and should be avoided."


While I agree with you that the oneway tag is probably redundant, if
we remove them are we possibly opening ourselves / OSM to criticism
"But my GPS didn't say it was one-way only" (& yes, I have that little
faith in any number of drivers! :-()

Thanks

Graeme


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


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

Re: [Tagging] oneway=yes on motorways

[António Madeira via Tagging]

I just want wikis to be in accordance between them. As they are now, the
induce mappers with doubt.

Mind you that "These ways should all point direction of travel and imply
oneway=yes (like junction=roundabout), therefore the oneway tag is
redundant and should be avoided." is not telling that it's forbidden to
use oneway=yes, only it should be avoided.



Às 11:25 de 18/08/2020, Steve Doerr escreveu:

On 17/08/2020 15:02, Matthew Woehlke wrote:


FWIW, I am also in favor of preferring explicit tagging;
oneway={yes,no} says that someone paid enough attention to
intentionally annotate the way thusly. An implicit tag is impossible
to tell apart from an oversight. IMHO we should never, *ever*
discourage adding explicit tags even if they are "superfluous".


Important to remember that yes and no are not the only values. There
is also -1.




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

Re: [Tagging] How to tag a social vacation centre?

[António Madeira via Tagging]

I ended choosing leisure=resort.
There is an ill documented key for this tag, which seems to address the
problem of defining the type of resort:
https://wiki.openstreetmap.org/wiki/Key:resort

Maybe we could expand and better the type of resort, based on this key.


Às 21:12 de 10/09/2020, Graeme Fitzpatrick escreveu:




On Fri, 11 Sep 2020 at 09:40, António Madeira mailto:antoniomade...@gmx.com>> wrote:

Hi there.

How should I tag an area dedicated to vacations, which is not a
resort,
only for members of an institution? Those centres are very common near
the sea, and they range from kids camps (sons of government
workers), to
bank or police pensioners/workers.
I was about to tag that as amenity=social_facility but I can't
find any
suitable subtag that conveys the idea of vacations.


I think I would just go with tourism=hotel (or campsite, chalet,
hostel as applicable) https://wiki.openstreetmap.org/wiki/Key:tourism

That page makes reference to including group_only=yes
https://wiki.openstreetmap.org/wiki/Key:group_only and also
access=private if it's only open to members of a particular group.

You could also include a description "Only open to members of the
Retired Police Officers Association"

Thanks

Graeme


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


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

Re: [Tagging] automated edits seem to remove crossing=zebra drastically

[António Madeira via Tagging]

The problem, I believe is with iD's presets.
When I started mapping some years ago I always marked crossings as
zebras, then iD changed the preset to crossing =marked and I believe
that's what you're seeing with the increasing number of this tag.
Although iD presents the type selector within that element, with
"uncontrolled", "traffic_signs", "unmarked", "zebra", "no", "toucan",
"pelican" and others, most mappers just leave the first value, which is
"marked".


Às 11:33 de 16/09/2020, Martin Koppenhoefer escreveu:



Am Mi., 16. Sept. 2020 um 16:27 Uhr schrieb Dave F via Tagging
mailto:tagging@openstreetmap.org>>:

I thought the correct tag for this was crossing_ref. Have you
cross checked to see if they've been swapped instead of removed?



crossing_ref is a different kind of beast, as some people use it to
tell whether there are zebra markings (can also apply to traffic light
controlled crossings).

Frankly, I do not like the tag for zebra crossings, because this
approach requires me to set 3 tags (one of crossing=zebra / marked /
uncontrolled(?)  +, crossing_ref=zebra + highway=crossing, on every
zebra crossing while I could use 2 and be done (highway=crossing with
crossing=zebra).


Cheers
Martin

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


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

[Tagging] Tagging a government job centre

[António Madeira via Tagging]

Hi there.

I was searching for a way of tagging a government job centre and I found
there's no suitable way of doing this.
There's office=employment_agency which doesn't seem to fit here, cause
it seems to correspond to private companies who work with this kind of
services.

I thought about using the office=government scheme, with the subtag
government=job_centre.
You think this is ok or is there a better way?

Regards.


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

Re: [Tagging] Tagging a government job centre

[António Madeira via Tagging]

You can not duplicate tags on the same feature...


Às 20:29 de 09/10/2020, Graeme Fitzpatrick escreveu:




On Sat, 10 Oct 2020 at 09:12, António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

There's office=employment_agency which doesn't seem to fit here, cause
it seems to correspond to private companies who work with this kind of
services.

I thought about using the office=government scheme,


How about simply double it up to
office=government + office=employment_agency ?

The name of "Federal Employment Service" or whatever should then be
enough to dispel any doubts!

Thanks

Graeme


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


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

Re: [Tagging] Tagging a government job centre

[António Madeira via Tagging]

I've seen that on the taginfo website, but I don't think there's need
for another amenity, with such good scheme already in hand.
The office=government has these explicit subtags in the wiki:
    government=ministry
    government=prosecutor
    government=tax
    government=register_office
    government=data_protection

I think it's just a matter of thinking about the correct value here.



Às 20:30 de 09/10/2020, Jeremy Harris escreveu:

On 10/10/2020 00:09, António Madeira via Tagging wrote:

I was searching for a way of tagging a government job centre and I found
there's no suitable way of doing this.
There's office=employment_agency which doesn't seem to fit here, cause
it seems to correspond to private companies who work with this kind of
services.

I thought about using the office=government scheme, with the subtag
government=job_centre.
You think this is ok or is there a better way?

My local one has amenity=job_centre - for which there is no doc...



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

Re: [Tagging] Tagging a government job centre

[António Madeira via Tagging]

Seen by that perspective, I have to agree.
Anyway, maybe the wiki could be updated to reflect the entire scope of
the office=employment_agency

Thanks.


Às 06:32 de 10/10/2020, Tom Pfeifer escreveu:

As Volker said, office=employment_agency is the established tag.

office=government is wrong, since the employees in the job centre do
not govern.

The government might be the operator of the job centre, which can be
expressed in the operator tag,
e.g. operator=Government of Example County

tom

On 10.10.2020 09:21, Volker Schmidt wrote:

If you go to the (admittedly, very short) wiki page for
office=employment_agency, you find that the picture illustrating the
tag shows a German "jobcenter" of the Agentur fuer Arbeit, which is a
government agency.
<https://en.wikipedia.org/wiki/Bundesagentur_f%C3%BCr_Arbeit>
So I think your starting assumption is not reflecting the actual tagging
This means also that your idea of creating a new "government" related
tag would be in conflict with the established tagging, at least in
Germany

Volker
(Italy)


     > On 10/10/2020 00:09, António Madeira via Tagging wrote:
 >> I was searching for a way of tagging a government job centre
and I found
 >> there's no suitable way of doing this.
 >> There's office=employment_agency which doesn't seem to fit
here, cause
 >> it seems to correspond to private companies who work with
this kind of
 >> services.


<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>


<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

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




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



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

Re: [Tagging] Tagging a government job centre

[António Madeira via Tagging]

Portugal has a very similar social structure from that of England's , so
I relate to what you wrote.
Although an employment centre is not an office that governs, like Tom
Pfeifer wrote, (nevertheless we could argue they govern/regulate the
unemployed and the work market) it operates very differently from an
employment agency (the difference in the name is not incidental) and I
think that should be stated or even differentiated in the wiki.


Às 09:07 de 11/10/2020, Paul Allen escreveu:

Sigh.  Managed to hit some keystroke combination on this damned
laptop that triggered a send.  Now what I intended to write...

On Sun, 11 Oct 2020 at 02:16, António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

Anyway, maybe the wiki could be updated to reflect the entire scope of
the office=employment_agency

Perhaps.  With qualifications and exceptions.  In the UK there were
differences between Jobcentres and employment agencies. Those
differences became more pronounced when Jobcentres turned
into Jobcentres+ (or is that Jobcentre+s?).

Employment agencies are happy to have you on their books even if you are
currently employed and many will notify you by e-mail if suitable
opportunities
arise; Jobcentres deal with the unemployed who are looking for work.

If you sign up with an employment agency you do not receive any
money for doing so; signing up with a Jobcentre is how you
qualify for unemployment benefit.

[Now the new/fixed stuff]

Jobcentres merged with the Benefits Agency (which handled benefits
other than unemployment benefits) and so pay out money for more
than just unemployment; employment agencies don't pay out any of
those benefits either.

Jobcentres are staffed by civil servants and are part of the
Department of Work and Pensions (a branch of government);
employment agencies are non-governmental.

I'd say UK Jobcentre+s are definitely office=government rather
than office=employment_agency because they ARE government
offices and do things that employment agencies do not.
I'd settle for government=employment_agency even though
they do more than just that.

--
Paul




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

Re: [Tagging] Tagging a government job centre

[António Madeira via Tagging]

In Portugal, the Government's employment centre gets you a job and gives
you professional formation. It has  a list of all the companies seeking
for workers and distribute them based a very specific system.
The money that comes from the Government to people without job is given
via Social Security, it's not handed by the employment centre. The
function of the employment centre is only to get people a job and give
them professional formation if needed.
Given these arguments, I'm getting more inclined to use
office=government + government=employment_centre


Às 18:23 de 11/10/2020, Graeme Fitzpatrick escreveu:

We have a Govt Dept that controls everything, decides whether you will
be paid Unemployment Benefits (under a number of different names), but
does nothing about you actually getting a job. This would be an
office=government.

You then have to register with a private Job Agency that will
supposedly help you find a job, but which don't actually do much :-(,
but which would be mapped as an office=employment_agency. They don't
pay you, but are themselves paid by the Govt for "helping" you.




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

[Tagging] How to tag a threshing floor

[António Madeira via Tagging]

Greetings.

In Portugal and all Mediterranean countries, there are thousands of
thresing floors . Most of
them are not used anymore, of course, but they are still preserved and
are private spaces used for many purposes. I myself have one.
I see there's a reference to this feature in this

wiki page, but wouldn't it fit better in the man_made tag? After all,
this is still an used feature, although not always with the original intent.

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

Re: [Tagging] How to tag a threshing floor

[António Madeira via Tagging]

I didn't get it, Mateusz.
What does historic=wayside_shrine have to do with threshing floor?



On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via Tagging
mailto:tagging@openstreetmap.org>>
wrote:


We also have historic=wayside_shrine that is used for ones
that are not historic at all.




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

Re: [Tagging] religous bias - Feature Proposal - Voting - (Chapel of rest)

[António Madeira via Tagging]

In many modern places near cemeteries there's not a room, but several.
So, I would prefer amenity=place_of_mourning


Às 12:39 de 05/11/2020, Peter Elderson escreveu:


rate the following "favourable", "acceptable" or "unfavourable"?

amenity=mourning


acceptable, though I think an amenity should be a feature, not an
activity

amenity=place_of_mourning


favourable. Secondary tags could add details if necessary

amenity=mourning_room


unfavourable. Too specific.

amenity=viewing_arrangements


unfavourable. I think an amenity should describe a feature, not
arrangements.

amenity=deceased_viewing


unfavourable.

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


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


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

Re: [Tagging] How to tag a threshing floor

[António Madeira via Tagging]

Oh, I see what you mean. I was lost in translation I guess.
As I wrote in my first message, they're still used for their original
purpose in the Mediterranean area, although not as much as before, of
course. Still, they are used for other purposes, like festivals, as you
mentioned, family reunions and many other agricultural purposes.



Às 16:14 de 05/11/2020, Joseph Eisenberg escreveu:

historic=wayside_shrine and some other values of historic=* are
examples which show that the key "historic=" can be used for features
which are still functional.

A threshing floor is probably still usable for beating grain to remove
the chaff and straw, as intended, but with modern machinery available,
these features will no longer be used in countries with access to
capital. They are still used in remote areas where farmers have very
few resources (e.g Afghanistan, according to some photos available
online). But most of those in use in richer countries will be as
historic sites or for special festivals, as shown in the photos in the
wikipedia article: https://en.wikipedia.org/wiki/Threshing_floor

My preference would be for man_made=threshing_floor however.

-- Joseph Eisenberg

On Thu, Nov 5, 2020 at 10:57 AM António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

I didn't get it, Mateusz.
What does historic=wayside_shrine have to do with threshing floor?



On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via
Tagging mailto:tagging@openstreetmap.org>> wrote:


We also have historic=wayside_shrine that is used for
ones that are not historic at all.




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



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

Re: [Tagging] How to tag a threshing floor

[António Madeira via Tagging]

Yes, as I said in the previous message, it was my misunderstanding.
Sorry about that.


Às 20:02 de 05/11/2020, Mateusz Konieczny escreveu:

I was referring to

"
I see there's a reference to this feature in this

wiki page, but wouldn't it fit better in the man_made tag? After all,
this is still an used feature, although not always with the original intent.
"


Nov 5, 2020, 19:55 by tagging@openstreetmap.org:

I didn't get it, Mateusz.
What does historic=wayside_shrine have to do with threshing floor?




On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via
Tagging mailto:tagging@openstreetmap.org>> wrote:


We also have historic=wayside_shrine that is used for
ones that are not historic at all.





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

Re: [Tagging] How to tag a threshing floor

[António Madeira via Tagging]

This is not correct. Threshing floors do not have protected status in
Portugal. There are some that are included in open air museums and maybe
in archaelogical sites, but there are thousands all over the country and
only maybe 10 or 20 are "protected".
As I said, they're still used, although rarely with the original intent.

Here's a proposal on how to map these features, from the Portuguese
mailing list:
*
man_made=threshing_floor*
   (**) "man_made" is mandatory
https://en.wikipedia.org/wiki/Threshing_floor

*historic=threshing_floor
*
   (***) "historic" is optional, but *highly recommended*, if
"historic" is relevant
https://taghistory.raifer.tech/#***/historic/threshing_floor

*surface=paving_stones*|*
   ()  optional, any value admissible for tag "surface"
https://wiki.openstreetmap.org/wiki/Key:surface

*access=yes|no|private*
   (*) optional, any value admissible for tag "access"
https://wiki.openstreetmap.org/wiki/Key:access#List_of_possible_values



Às 05:26 de 06/11/2020, Jez Nicholson escreveu:

I believe that a key point is that these threshing floors have
protected status in Portugal and Spain due to their historical
significance. The suggestion of using 'historic[al]' is to represent
this.

In other parts of the world, where it is in current use and not
ancient/protected then perhaps it is an 'amenity'?

Is there a subtag to distinguish an historical/protected amenity from
a straight/unprotected one?


On Thu, 5 Nov 2020, 23:08 António Madeira via Tagging,
mailto:tagging@openstreetmap.org>> wrote:

Yes, as I said in the previous message, it was my
misunderstanding. Sorry about that.


Às 20:02 de 05/11/2020, Mateusz Konieczny escreveu:

I was referring to

"
I see there's a reference to this feature in this
<https://wiki.openstreetmap.org/wiki/Historical_Objects/Map_Properties>
wiki page, but wouldn't it fit better in the man_made tag? After all,
this is still an used feature, although not always with the original intent.
"


Nov 5, 2020, 19:55 by tagging@openstreetmap.org
<mailto:tagging@openstreetmap.org>:

I didn't get it, Mateusz.
What does historic=wayside_shrine have to do with threshing
floor?




On Thu, 5 Nov 2020 at 11:37, Mateusz Konieczny via
Tagging mailto:tagging@openstreetmap.org>> wrote:


We also have historic=wayside_shrine that is
used for ones that are not historic at all.





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



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

Re: [Tagging] How to tag a threshing floor

[António Madeira via Tagging]

So, given that most of those who commented this thread agreed that
threshing_floor should be in the man_made scheme, should I add it to the
wiki or create a Feature Proposal?


Às 19:27 de 06/11/2020, Paul Allen escreveu:

On Fri, 6 Nov 2020 at 21:53, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen
mailto:pla16...@gmail.com>>:

On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

...

To me it doesn't make sense to draw a line, dividing the
same objects having more or less historic value. If there
is something to distinguish at all, my suggestion would be
to add a qualifier to those objects of exceptional
historical value (if this is verifiable).


We have a way of tagging objects of exceptional historical
value, it's
historic=*.  Objects of unexceptional historical value, or of
no historical
value do not get tagged with historic=*.  That's because
historic is
not a synonym (in the real world or in tagging) for old,
disused or
repurposed.


just that it is not what we are currently doing.

That is not what some of us are currently doing.  Others read the wiki
page
and tag accordingly.

It occurs to me that some of the mis-tagging (as I see it) and some of the
discussions here may revolve around semantics as interpreted by
those who do not have English as a first language.  There is a
difference between "historical" and "historic."

Historians are concerned with historical data.  Old data (about
populations, diseases or whatever) is historical data. The
assassination of a minor archduke, which seemed unimportant
at the time, quickly turned into a historic event.

When somebody says that "historic" applies to everything that
historians do, that is incorrect.  What historians mostly do is
look at historical data, some small fraction of which is
also historic.

See https://www.grammarly.com/blog/historic-historical/
for a better explanation.

So historic=* really should only apply (as the wiki page states) to
the important
things of the past, not everything some random historian might happen
to be looking into.

So the question is, do we accept that because some mappers have misused
the tag we should encourage that misuse or do we discourage it?

--
Paul


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


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

Re: [Tagging] How to tag a threshing floor

[António Madeira via Tagging]

Thank you, Joseph.

If no one opposes, I'll do just that.
Regards.


Às 16:43 de 12/11/2020, Joseph Eisenberg escreveu:

Since the tag man_made=threshing_floor has already been used 7 times
(https://taginfo.openstreetmap.org/search?q=threshing_floor#values)
you can create a page to document this, however, you would also need
to mention that historic=threshing_floor is much more common (actually
landuse=threshing_floor is also equally common), and it would probably
be fair to create a historic=threshing_floor wiki page too, in that case.

If you want to suggest deprecating historic=threshing_floor and
replacing it with man_made=threshing_floor, or otherwise changing
existing common usage, you should make a proposal so that the
community can discuss this.

-- Joseph Eisenberg

On Wed, Nov 11, 2020 at 2:53 PM António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

So, given that most of those who commented this thread agreed that
threshing_floor should be in the man_made scheme, should I add it
to the wiki or create a Feature Proposal?


Às 19:27 de 06/11/2020, Paul Allen escreveu:

On Fri, 6 Nov 2020 at 21:53, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen
mailto:pla16...@gmail.com>>:

On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>>
wrote:

...

To me it doesn't make sense to draw a line, dividing
the same objects having more or less historic value.
If there is something to distinguish at all, my
suggestion would be to add a qualifier to those
objects of exceptional historical value (if this is
verifiable).


We have a way of tagging objects of exceptional
historical value, it's
historic=*.  Objects of unexceptional historical value,
or of no historical
value do not get tagged with historic=*. That's because
historic is
not a synonym (in the real world or in tagging) for old,
disused or
repurposed.


just that it is not what we are currently doing.

That is not what some of us are currently doing. Others read the
wiki page
and tag accordingly.

It occurs to me that some of the mis-tagging (as I see it) and
some of the
discussions here may revolve around semantics as interpreted by
those who do not have English as a first language.  There is a
difference between "historical" and "historic."

Historians are concerned with historical data. Old data (about
populations, diseases or whatever) is historical data.  The
assassination of a minor archduke, which seemed unimportant
at the time, quickly turned into a historic event.

When somebody says that "historic" applies to everything that
historians do, that is incorrect.  What historians mostly do is
look at historical data, some small fraction of which is
also historic.

See https://www.grammarly.com/blog/historic-historical/
for a better explanation.

So historic=* really should only apply (as the wiki page states)
to the important
things of the past, not everything some random historian might happen
to be looking into.

So the question is, do we accept that because some mappers have
misused
the tag we should encourage that misuse or do we discourage it?

--
Paul


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


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


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


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

Re: [Tagging] How to tag a threshing floor

[António Madeira via Tagging]

Wiki created:
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dthreshing_floor

Please comment and/or edit accordingly.


Às 17:53 de 12/11/2020, António Madeira via Tagging escreveu:

Thank you, Joseph.

If no one opposes, I'll do just that.
Regards.


Às 16:43 de 12/11/2020, Joseph Eisenberg escreveu:

Since the tag man_made=threshing_floor has already been used 7 times
(https://taginfo.openstreetmap.org/search?q=threshing_floor#values)
you can create a page to document this, however, you would also need
to mention that historic=threshing_floor is much more common
(actually landuse=threshing_floor is also equally common), and it
would probably be fair to create a historic=threshing_floor wiki page
too, in that case.

If you want to suggest deprecating historic=threshing_floor and
replacing it with man_made=threshing_floor, or otherwise changing
existing common usage, you should make a proposal so that the
community can discuss this.

-- Joseph Eisenberg

On Wed, Nov 11, 2020 at 2:53 PM António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

So, given that most of those who commented this thread agreed
that threshing_floor should be in the man_made scheme, should I
add it to the wiki or create a Feature Proposal?


Às 19:27 de 06/11/2020, Paul Allen escreveu:

On Fri, 6 Nov 2020 at 21:53, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:

Am Fr., 6. Nov. 2020 um 13:56 Uhr schrieb Paul Allen
mailto:pla16...@gmail.com>>:

On Fri, 6 Nov 2020 at 09:09, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>>
wrote:

...

To me it doesn't make sense to draw a line, dividing
the same objects having more or less historic value.
If there is something to distinguish at all, my
suggestion would be to add a qualifier to those
objects of exceptional historical value (if this is
verifiable).


We have a way of tagging objects of exceptional
historical value, it's
historic=*.  Objects of unexceptional historical value,
or of no historical
value do not get tagged with historic=*.  That's because
historic is
not a synonym (in the real world or in tagging) for old,
disused or
repurposed.


just that it is not what we are currently doing.

That is not what some of us are currently doing.  Others read
the wiki page
and tag accordingly.

It occurs to me that some of the mis-tagging (as I see it) and
some of the
discussions here may revolve around semantics as interpreted by
those who do not have English as a first language.  There is a
difference between "historical" and "historic."

Historians are concerned with historical data. Old data (about
populations, diseases or whatever) is historical data.  The
assassination of a minor archduke, which seemed unimportant
at the time, quickly turned into a historic event.

When somebody says that "historic" applies to everything that
historians do, that is incorrect.  What historians mostly do is
look at historical data, some small fraction of which is
also historic.

See https://www.grammarly.com/blog/historic-historical/
for a better explanation.

So historic=* really should only apply (as the wiki page states)
to the important
things of the past, not everything some random historian might
happen
to be looking into.

So the question is, do we accept that because some mappers have
misused
the tag we should encourage that misuse or do we discourage it?

--
Paul


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


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


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



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


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

[Tagging] How to revive a tag proposal?

[António Madeira via Tagging]

Greetings.

In Portugal there are olive oil mills all over the place, as I'm sure
there are in Spain, Italy and Greece. Unfortunately, there's no easy way
to map them on OSM.
I found an ancient proposal for this tag, but it never went forward:
https://wiki.openstreetmap.org/wiki/Proposed_features/olive_oil_mill

I contacted its author one month ago via OSM profile, but received no
answer.
What can I do to revive this proposal and implement this tag?

Regards,
António Madeira.

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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

A fountain should be first and foremost a place where there's water
served to the public. The concept of "sculptural and/or decorational"
should be just a component of the fountain, depending on the
country/culture. As its historical/heritage value.
In Portugal, where there are thousands of fountains, this is the norm.
Decorational fountains without the use of drinking water are just a
subtype of fountain, because the main use/purpose of the vast majority
is to serve water.
So, if we see fountains in this prism, I believe they are clearly a
necessity. In cities they lost some of their importance, but in villages
and rural areas (80% of the territory) they're still one of the main
features, without which many of them wouldn't have a consistent source
of potable water.


Às 07:05 de 06/02/2020, Martin Koppenhoefer escreveu:

Am Do., 6. Feb. 2020 um 10:55 Uhr schrieb Cascafico Giovanni
mailto:cascaf...@gmail.com>>:


Since fountain is intended as "sculptural and/or decorational", IMHO
amenity=fountain is not consistent. AFAIK object belonging to
"amenity" are in someway necessities. So one day, I hope to see
fountain value removed from amenity tag.




I would like to reject the idea that something that is decorational
and cultural is not a "necessity" (along these lines, where do you see
place of worship?). Fountains, seem to fit reasonably well into the
amenity concept. Much more than prisons, grave_yards, hunting stands,
grit bins, private toilets (sic), and many more things to be found in
amenity with some usage:
https://taginfo.openstreetmap.org/keys/amenity#values

Cheers
Martin

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


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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

I'm not going into etymologic discussions, but fountain, be it in
British English or any other language with Latin origins is a source of
drinkable water (a spring). Maybe, just guessing, there were fountains
in Britain and they're not used anymore or were simply abandoned because
they were not needed in the modern age, thus the evolution of the word
to simply mean "ornamental fountain", but that's not the case in
Mediterranean and Eastern countries.
That was the main purpose of this thread, to discuss the "restrictions"
that the wiki imposed on that main feature.

If, in Britain, a fountain is normally a ornamental fountain, that
shouldn't restrict the possibility of widening its meaning to encompass
the reality in other countries, where fountains are, in fact, a potable
source of water and an ornamental fountain (which doesn't allow to drink
water due to the absence of a tap or a pipe) is just an extension of
that or a subtype.
I think that was fairly accomplished with the recent changes in the wiki
and the use of drinking_water=yes on such features.
Drinking fountain could be a good alternative, but it seems reserved to
"a man-made device providing a small jet of water for drinking", which
doesn't include at all the type of fountain I started this thread with.

I just commented that I agreed that amenity=drinking_water should be
abandoned, because you can use drinking_water=yes on all existing
features that provide water (fountains, springs, wells, taps, drinking
fountains, etc.)

Regards.


Às 11:40 de 06/02/2020, Paul Allen escreveu:

On Thu, 6 Feb 2020 at 14:15, António Madeira via Tagging
mailto:tagging@openstreetmap.org>> wrote:

A fountain should be first and foremost a place where there's
water served to the public.


That may be the meaning of the word in some languages, but OSM uses
British
English.  In British English the word "fountain," by itself, usually
means an
ornamental fountain.  In British English, a fountain which supplies
drinking water is
known as a "drinking fountain."

The concept of "sculptural and/or decorational" should be just a
component of the fountain, depending on the country/culture.


Nope.  The concept should be that "fountain" in OSM reflects its
meaning in British
English and not its meaning in another language.

Decorational fountains without the use of drinking water are just
a subtype of fountain, because the main use/purpose of the vast
majority is to serve water.


This is just plain wrong.  There can be ornamental fountains which do
not supply
drinking water (because there are issues which mean it's not
potable).  There
can be utilitarian, ugly drinking fountains such as those in schools. 
And there
can be ornamental fountains that also supply drinking water.  And all
come under
the generic term "fountain" in British English.  That's why there is a
subtag
drinking_water=yes which can be applied to an amenity=fountain (which
means
a decorative fountain) that also supplies drinking water.  If it's an ugly
fountain there is amenity=drinking_water.



--
Paul




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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

Paul, I'm not calling it anything. We all know that OSM uses British
English for tagging. What I'm saying is that it's better to widen the
scope of the tag, than restrict it to a certain reality.
A fountain is a fountain, if in England it doesn't implies
drinking_water=yes, that's fine. In the majority of European countries,
it does imply, so it's just fair and logical that the wiki reflects that.


Às 13:00 de 06/02/2020, Paul Allen escreveu:



On Thu, 6 Feb 2020 at 15:27, António Madeira mailto:antoniomade...@gmx.com>> wrote:


If, in Britain, a fountain is normally a ornamental fountain, that
shouldn't restrict the possibility of widening its meaning to
encompass the reality in other countries,


OSM tag names and values use British English where possible.  There's
a reason
for that: mappers from around the world are exposed to tag names and
values and
they have to know how to interpret them.  This is difficult enough
when they are
in British English, but it becomes impossible if mappers have to guess
that
words that are recognizably English are being used with meanings in
randomly-chosen languages.  It's bad enough having to look up the British
English meaning, it's even harder to guess which language should be used
to interpret the tag.  Are we using the French interpretation of
"fountain" or
the Italian interpretation or...?

Call it cultural imperialism if you wish, but OSM uses British English for
tagging.

--
Paul



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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

It's not arbitrary and you're missing the point by circling around a non
issue.
I'm not saying to change the meaning of fountain, which can have some
subtle differences between countries, I'm saying to let it open to
retain its British meaning and add the possibility to have different
uses depending on the country. A person outside Europe will still find
what she/he wants by searching the tag fountain, either with OR without
drinking_water.


Às 14:24 de 06/02/2020, Paul Allen escreveu:

On Thu, 6 Feb 2020 at 16:48, António Madeira mailto:antoniomade...@gmx.com>> wrote:

Paul, I'm not calling it anything. We all know that OSM uses
British English for tagging. What I'm saying is that it's better
to widen the scope of the tag, than restrict it to a

certain reality.
A fountain is a fountain, if in England it doesn't implies
drinking_water=yes, that's fine. In the majority of European
countries, it does imply, so it's just fair and logical that the
wiki reflects that.


You've just admitted OSM uses British English yet you still want to
expand the
meaning of fountain to have a meaning that is not British English. 
Yes, many
European countries ascribe a different meaning to "fountain."  But
many outside
Europe don't have the word "fountain" in their language. So, knowing that
OSM uses British English, they find out what "fountain" means in
British English
(or already know).  And would then be puzzled if OSM were using it
differently,
because OSM is supposed to use British English, not British English plus
arbitrary additional meanings from elsewhere.

--
Paul



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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

That's what drinking_water=yes is used for, right?

In Britain, you don't use drinking_water=yes, in Portugal (or whatever
country it may be) we use amenity=fountain (which is always
decorative/ornamental/historic, so it fits your conception of fountain)
AND drinking_water=yes.
For me, it's simple. I don't see any issue with that.


Às 14:51 de 06/02/2020, Paul Allen escreveu:


A person outside Europe will still find what she/he wants by
searching the tag fountain, either with OR without drinking_water.


How?  I go to your country looking for drinking water and all I see on
the map
are ornamental fountains because that's what "fountain" means to me. 
You come
to the UK looking for drinking water and drink from an ornamental
fountain that
doesn't doesn't supply drinkable water because that's what "fountain"
means to
you.  This way madness lies.

BTW,
https://commons.wikimedia.org/wiki/File:Contrasting_messages_on_Harford_Fountain,_Harford_Square,_Lampeter_-_geograph.org.uk_-_6178011.jpg

--
Paul



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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

Just to complement.
If you come to Portugal and want to find drinkin water, you should know
that most fountains have drinking water, like I need to know the
opposite when I go to the UK.
Also, if you come here, you need to know that we drive on the opposite
side of the road. That doesn't mean that highway has a different meaning
than in the UK. It's just used in a onother way.

Yes, that example in Portugal that's a fountain (a decorative/historic)

If it says not do drink water from it, we simply use amenity=fountain.
Like you.
Only if it has potable water we could add drinking_water=yes.




Às 14:51 de 06/02/2020, Paul Allen escreveu:


BTW,
https://commons.wikimedia.org/wiki/File:Contrasting_messages_on_Harford_Fountain,_Harford_Square,_Lampeter_-_geograph.org.uk_-_6178011.jpg

--
Paul



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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

I did read the description closely, and what I said still applies: in
Portugal it is a fountain in the way it is described in Britain, an
amenity=fountain with no drinking water.
That's what I'm trying to explain from the beginning: it doesn't matter
if it has drinking water or not, it will always be a fountain. But in
the cases (the majority of them) that they have, we should be allowed to
apply the drinking_water=yes, regardless if in Britain that's not the case.
This way, everyone is happy: you still call it fountain in Britain, and
I still call it fountain in Spain, Italy, France, Portugal or wherever,
with the difference that the chance of them having potable water is higher.


Às 16:02 de 06/02/2020, Paul Allen escreveu:

On Thu, 6 Feb 2020 at 18:10, António Madeira mailto:antoniomade...@gmx.com>> wrote:


If you come to Portugal and want to find drinkin water, you should
know that most fountains have drinking water, like I need to know
the opposite when I go to the UK.


But OSM maps can be viewed from anywhere in the world by people planning
trips.  It's better that tags mean the same thing everywhere. 
Otherwise you
have to check what each country means by each tag.

Yes, that example in Portugal that's a fountain (a
decorative/historic)


If you had read the description closely, you'd have been able to work
out that
it was originally a decorative drinking fountain. Current legislation
means that
the water is no longer considered potable so it is now just a
decorative fountain.

If it says not do drink water from it, we simply use
amenity=fountain. Like you.

Only if it has potable water we could add drinking_water=yes.


That's all I was ever saying: amenity=fountain doesn't imply the water is
drinkable because the tag values are in British English. If it also
supplies
drinking water then add drinking_water=yes.  If there is no drinking_water
tag then the default is that it is not drinkable.  That way we have a
standard
way of tagging things.

You may also need to make use of drinking_water:legal=no on some
fountains.  I wouldn't use it myself because it implies the water is
drinkable but not certified as drinkable and I'd be worried about the
legal consequences of making such a claim.

--
Paul



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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

This also is important. There are fountains (not many) which have an
official document in situ to inform that the water was tested, with the
analysis results and date.
This could go into another key, which would compose even better the
fountain tag. I had never noticed that legal=yes/legal=no keys but I
think it would be a good addition to the fountain wiki, at least on the
countries where they apply.

Às 16:02 de 06/02/2020, Paul Allen escreveu:

You may also need to make use of drinking_water:legal=no on some
fountains.  I wouldn't use it myself because it implies the water is
drinkable but not certified as drinkable and I'd be worried about the
legal consequences of making such a claim.



I think this is a good summary on the issue that could be applied to
other tags. I believe OSM would have much to gain if this was the case.

Às 17:03 de 06/02/2020, Diego Cruz escreveu:

I don't think it's that hard to concede that a fountain, ornamental in
nature, may be used for drinking too in other countries by adding a
simple subtag. We should be a little more respectful of cultural
differences here, since this project intends to map the whole world
and a single language is just but a poor tool to describe everything
we can find in it.

I'm not trying to target English for this inability to describe
things. All languages suffer from that, especially things that are
foreign to one's own culture. We are just using British English as a
convention, not because it is more adequate, so please let us at least
deviate a little to accommodate differences.



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

Re: [Tagging] How to tag an utilitarian fountain?

[António Madeira via Tagging]

Ok, let's stay in the same page then. :)
Regarding schools, I don't know what you mean, because here, schools
dont have fountains, just taps and those of the bubbler type (maybe old
century schools have fountains in their yards or something similar).

Às 18:20 de 06/02/2020, Paul Allen escreveu:

Which is the case in Britain for ornamental/decorative fountains. 
Regardless
of whether or not they supply drinking water, they're fountains.  But
utilitarian
drinking fountains, of the kind found in schools, are not "fountains"
in normal
British English usage.


This was assumed from my side since the beginning. What spurred me to
start this thread was that the element "fountain" in Portuguese iD was
translated as "decoration fountain" and the wiki seemed to support that
distinction.
So, as it is now, there are no decoration fountains, only fountains that
need drinking_water=yes if they provide potable water, which seems a
more encompassing and more close to reality solution.



What I was objecting to was the idea that in some countries
amenity=fountain
is assumed to supply drinking water by default.  It needs an explicit
drinking_water=yes.

--
Paul



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

[Tagging] How to match multiple destinations and destination:ref?

[António Madeira via Tagging]

Hi there.

I've stumbled with a problem for which I couldn't find a satisfactory
answer.
Say I have a destination sign in a motorway junction exit with 4
destinations, but only the second one has a ref. How do we match the
right destination with its ref?

I've noticed that we can use "none" in the destination:symbol tag. Could
this be applied here too?

Regards.

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

Re: [Tagging] How to match multiple destinations and destination:ref?

[António Madeira via Tagging]

Thank you, Jan!
This was exactly what I was searching for.
So, for destination:ref you propose using ";;" for empty values and for
destination:symbol you propose "none"?

How come this is not in the destination tag wiki?



Às 13:30 de 13/02/2020, Jan Michel escreveu:

Hi,
You can just add empty entries to the destination:ref tag, like
destination:ref=;123;;
Some people prefer to use 'none' instead of empty entries, but I would
not recommend that.

I don't know if you have found it, but there is some documentation I
wrote in the Wiki:
https://wiki.openstreetmap.org/wiki/User:Mueschel/DestinationTagging


Jan


On 13.02.20 16:07, António Madeira via Tagging wrote:

Hi there.

I've stumbled with a problem for which I couldn't find a satisfactory
answer.
Say I have a destination sign in a motorway junction exit with 4
destinations, but only the second one has a ref. How do we match the
right destination with its ref?

I've noticed that we can use "none" in the destination:symbol tag. Could
this be applied here too?

Regards.

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




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



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

Re: [Tagging] How to match multiple destinations and destination:ref?

[António Madeira via Tagging]

This was of a great help, Jan. That tool is awesome!

Wouldn't it be the right time to go ahead with this proposal? I mean,
this is used for most of the routing softwares that uses OSM, including
OSMAnd.


Às 14:17 de 13/02/2020, Jan Michel escreveu:

On 13.02.20 18:02, António Madeira via Tagging wrote:

Thank you, Jan!
This was exactly what I was searching for.
So, for destination:ref you propose using ";;" for empty values and for
destination:symbol you propose "none"?


There are different options:
destination:ref = ;123;;
destination:ref = none;123;none;none
destination:ref =  ;123; ;

I personally prefer the first one, but while interpreting tags I treat
all of them the same. In any case I would decide for one style and use
this for all tags. Note that 'none' as a placeholder might be
ambiguous in some cases, because some tags also have 'none' as a valid
value (e.g. maxheight = none) and then there is the case of the
Italian city 'None'.


How come this is not in the destination tag wiki?

This scheme was never officially proposed or discussed, it's just an
extension of the (old but never voted on) proposal for extended
destination:XYZ tags.

At least in Germany it's currently used to quite some extent to
represent more complicated signs properly, e.g.
http://osm.mueschelsoft.de/destinationsign/example/index.htm#way=153364494&include_sgn=1&include_way=1&country=DE



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



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

Re: [Tagging] Please fix unnamed square tagging / was: ... description of place=square

[António Madeira via Tagging]

Although in Portugal squares are very well defined, either from their
physical significance or from their name, this is surely not the case in
every country.
Maybe one of their main common characteristics is that they're open
urban areas, a point of confluence where people can gather for social or
cultural events.
I think it won't be possible to find a better common denominator and
that's why there should be good examples on the English wiki and on
other countries' wiki.


Às 06:42 de 23/03/2020, Martin Koppenhoefer escreveu:



Am Mo., 23. März 2020 um 06:26 Uhr schrieb Joseph Eisenberg
mailto:joseph.eisenb...@gmail.com>>:

"Praça ou largo: Praça, praceta ou largo: espaço numa zona urbana,
normalmente sem edifícios (apenas a volta desta), que constitui um
espaço público aberto"

This translates back to English as (approximately):
"Praça, praceta or largo: space in an urban area, usually without
buildings (except for around it), which constitutes a public open
space"



sounds reasonable (apart that there may be buildings on a square, is
not untypical)


 I'll update this to the new definition from the English page.




Which you keep reverting to your interpretation of square. It
currently reads "A town or village square: a hardscaped open public
space, generally of architectural significance, which is surrounded by
buildings in a built-up area such as a city, town or village."


While I do not object that this is describing a part of all squares, I
do object that these are criteria which are suitable to exclude
objects. For example  "surrounded by buildings" is a typical
situation, but is not a strict requirement. A public square surrounded
by walls would be equally ok, for instance. A square which is not
paved would be ok as well (not usual in many parts of the world, but
quite common in others, where road paving is generally rare). Let me
post some more examples of squares here:


Example for a famous square with buildings on it (Krakov):
https://www.openstreetmap.org/#map=18/50.06164/19.93764

Example for a square that is not mainly hardscaped (although in a
developed country), Strausberger Platz in Berlin (socialist urbanism)
https://www.openstreetmap.org/#map=18/52.51865/13.42866

Two adjacent squares, with significant parts not hardscaped: Platz vor
dem Neuen Tor, and Robert-Koch-Platz in Berlin
https://www.openstreetmap.org/#map=18/52.52851/13.37865

Another example for a socialist square, mostly open / flowing space,
center is a traffic junction: Platz der Vereinten Nationen:
https://www.openstreetmap.org/#map=17/52.52328/13.42999

Square that is not surrounded / delimited by buildings (but by walls):
https://www.openstreetmap.org/way/24534437

Another example for a square that is not at all delimited by buildings:
https://www.openstreetmap.org/relation/2743565

Example for a minor square without a lot of "architectural
significance" (well, this may depend on your definition of
significance, significant compared to what? One could also say thisi
is significant, as it clearly stands out as open space from the road
grid): https://www.openstreetmap.org/way/125988144


I've also created an Indonesian page, which gives a couple examples of
"alun-alun" in Indonesia which fit the definition:

1)

https://upload.wikimedia.org/wikipedia/commons/thumb/a/ac/Alun-alun_Garut.jpg/400px-Alun-alun_Garut.jpg

2)

https://upload.wikimedia.org/wikipedia/commons/thumb/d/d4/Alun_-_Alun_Bandung_Masjid_Raya_Bandung.jpg/400px-Alun_-_Alun_Bandung_Masjid_Raya_Bandung.jpg

But there are many other alun-alun that are grassy urban parks,
not squares:

A)

http://4.bp.blogspot.com/-zpwpVxKz0q0/UXoUmFzUAXI/BpI/brIHP9_dQQY/s400/images.jpg

B)

https://commons.wikimedia.org/wiki/File:Alun-alun_Tugu_-_Bunder_-_panoramio.jpg

C)

https://commons.wikimedia.org/wiki/File:Square_Trenggalek_-_Alun-Alun_Trenggalek_-_panoramio_(10).jpg



From photos it is hard to judge these, because you would usually need
to see the context in order to understand whether these are just parks
or parks on squares. I also notice that these are all huge. Try to
think of small squares as well, e.g. places like this:
https://i.pinimg.com/originals/83/41/da/8341dab9b3f5b929cc136f06b01bb3cb.jpg
http://www.italymoviewalks.com/wp-content/uploads/2017/03/fontana-delle-tartarughe-roma-movie-walks.jpg

Cheers
Martin


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

[Tagging] Refining heritage tag

[António Madeira via Tagging]

Hi there.

In the last few days, the Portuguese community has been trying to create
a national standardization with the heritage tag.
We came up to a possible solution which can be seen at the wiki page
 based on the previous
information on the wiki itself.

Still, I have some questions I would like to raise here:
- is ref:xxx=* a good solution to add the official reference
code/number? Why not heritage:ref:xxx as stated here
?
Doesn't this collide with other ref tags?
- the same for xxx:inscription_date=*. Wouldn't it be more consistent to
use heritage:xxx:inscription_date=* ?
- we've adopted the tag protection_title=* to define the protection
category of the heritage, although the German wiki clearly states this
is used for natural areas only. Would it be better to create another tag
or is OK to adapt this one, since this is also a protected feature?

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

Re: [Tagging] Refining heritage tag

[António Madeira via Tagging]

Thanks, Paul.
I'll contact them then.


Às 17:44 de 14/04/2020, Paul Allen escreveu:

On Tue, 14 Apr 2020 at 21:02, António Madeira mailto:antoniomade...@gmx.com>> wrote:


Às 10:15 de 14/04/2020, Paul Allen escreveu:


They're the ones you'd have to convince to alter their code to
handle your
proposed change.


You mean this?
https://wiki.openstreetmap.org/wiki/Open_Historical_Map


That's where it's documented.  The map is here:gk.historic.place
<http://gk.historic.place>  If
you've not played with it before, here's a place where I've added most
of the heritage info:
http://gk.historic.place/historische_objekte/l/en/index.html?zoom=16&lat=52.03846&lon=-4.46621&detail=3&pid=HaHbHcSaHe

The "problem" with criteria is that it seems to be used with
numbers or abbreviations, like a list that corresponds to some
longer definitions.


That's how others have done it, listing what those abbreviations mean
on the wiki
page.  But there's nothing (I can see) that says you have to restrict
yourself to
abbreviations.

Since heritage=* is largely ruled over by the historical places
people, the best
place to get an opinion is https://www.openstreetmap.org/user/lutz
In the end, he and his team decide how the historical places map interpret
the tags.

--
Paul


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


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

Re: [Tagging] Refining heritage tag

[António Madeira via Tagging]

After communicating with lutz from Historic.Place, he told me they
didn't create this heritage scheme, they just adopted it.
I took the opportunity to present him my proposal of refining this
scheme and I got his support to go ahead with it, so I'm presenting it
here in order to make the necessary adjustments with a new proposal.

heritage=* - This is the main tag, which uses the admin_level [not changed].
heritage:operator=xxx - This is the tag for the official operator. I
propose using separators [;] in those cases where an heritage has an
international and a national operator.
heritage:ref:xxx=* - This tag is for the code/number reference of the
operator(s) above. It changes the previous ref:xxx=*
heritage:xxx:criteria=* - This tag is for the classification criteria
used by the xxx operator. It changes the previous xxx:criteria=*
heritage:xxx:inscription_date=* - This tag is used for the date the
heritage was officially registered by xxx operator. It changes the
previous xxx:inscription_date=*
heritage:xxx:designation_title=* - This tag is used for the heritage
title (international or national). This is new and is an attempt to
circumvent the use of protection_title=* which is wrong in this context.
heritage:xxx:website=* - Used for the heritage official website
(international or national).


Regards,
António.


Às 17:49 de 14/04/2020, António Madeira via Tagging escreveu:

Thanks, Paul.
I'll contact them then.


Às 17:44 de 14/04/2020, Paul Allen escreveu:

On Tue, 14 Apr 2020 at 21:02, António Madeira mailto:antoniomade...@gmx.com>> wrote:


Às 10:15 de 14/04/2020, Paul Allen escreveu:


They're the ones you'd have to convince to alter their code to
handle your
proposed change.


You mean this?
https://wiki.openstreetmap.org/wiki/Open_Historical_Map


That's where it's documented.  The map is here:gk.historic.place
<http://gk.historic.place>  If
you've not played with it before, here's a place where I've added most
of the heritage info:
http://gk.historic.place/historische_objekte/l/en/index.html?zoom=16&lat=52.03846&lon=-4.46621&detail=3&pid=HaHbHcSaHe

The "problem" with criteria is that it seems to be used with
numbers or abbreviations, like a list that corresponds to some
longer definitions.


That's how others have done it, listing what those abbreviations mean
on the wiki
page.  But there's nothing (I can see) that says you have to restrict
yourself to
abbreviations.

Since heritage=* is largely ruled over by the historical places
people, the best
place to get an opinion is https://www.openstreetmap.org/user/lutz
In the end, he and his team decide how the historical places map
interpret
the tags.

--
Paul


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



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


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

[Tagging] [RFC] Proposal: Tagging scheme for windmills and watermills

[António Madeira via Tagging]

Greetings.

I invite everyone to comment on the proposal to remove man made=windmill
from building scheme, thus creating a better scheme for windmills and
watermills.
https://wiki.openstreetmap.org/wiki/Proposal:Tagging_scheme_for_windmills_and_watermills

Please discuss this proposal on the wiki talk page.

Regards,
António.

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

Re: [Tagging] Destination tagging of motorway links

[António Madeira via Tagging]

Hello.

The tag ref=49 shouldn’t trig the GPS to show you "49", because the 
correct tag to show the destination ref is "destination:ref", which is 
present.
If the number of the ramp is considered a value to include in the "ref" 
tag, that is another matter of debate, but your GPS shouldn't have 
fetched that value for the destination.
Is it possible that it was merely showing the ref of the ramp and not 
considering the destination ref?


Regards,
António Madeira

Às 16:58 de 01/06/2025, Dave Swarthout escreveu:


Hi,

I need some help to resolve an impasse I've reached with an OSM mapper 
about the proper tagging of destinations on motorway exit ramps. While 
following a route on my Garmin GPS device, my turn off of the NYS 
Thruway for Exit 49 was displayed as merely "49" (without the quotes). 
There was no other destination shown despite plenty of 
signs indicating the exit was for NY 78, Depew, Lockport, including 
the sign just prior to the exit ramp.


The original mapper tagged the exit ramps, i.e., the ways 
immediately after the exit node (correctly tagged with ref=49, 
highway=motorway_junction) with:

destination:ref=NY 78
destination=Depew;Lockport
highway=motorway_link
junction:ref=49
lanes=1
maxspeed:advisory=40 mph
oneway=yes
ref=49
surface=asphalt

IMO, all of these tags are correct except the ref=49 which I believe 
is what's triggering my GPS to show "49" on its screen. I compile my 
own Garmin-compatible maps and can change the interpretation of 
destination tags if that is the correct tagging for exit ramps but I 
don't think it is correct. That's why I'm raising the topic here. By 
the way, I used OSMAnd on my phone to follow the same route and got 
the same result, the turn from the Thruway at Exit 49 to reach 
Lockport was indicated by the two numbers "49" (without the quotes). 
All the ramps in that intersection were tagged with ref=49 by this mapper.


I don't do much expressway or motorway mapping so I wasn't sure if 
recent changes had been made to the tagging scenarios for exit ramps 
but upon reading the Wiki pages on motorway_junctions and exit ramp 
destination tagging I cannot find any justification for tagging an 
exit with an ordinary ref tag.This ramp does not have any ref 
associated with it and Exit 49 is the only exit of the six or seven 
nearby interchanges I checked that use this scenario.


I contacted the original mapper via a changeset comment but after 
scolding me about tagging for the renderer, he justified his tagging 
and did not offer to change it. IMO, simply removing the incorrect 
ref=49 tag from the ramps in the intersection would solve the problem.


Opinions?


--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog: http://dswarthout.blogspot.com
Flickr: https://www.flickr.com/photos/184600884@N06

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

Re: [Tagging] Destination tagging of motorway links

[António Madeira via Tagging]

What I meant is that even if that "ref=49" is wrongly associated to that 
ramp, the GPS shouldn't have confounded that with the correct one, which 
is "destination:ref=NY 78". After all, there may be the case in some 
country or jurisdiction where ramps do have references.


Regards,
António.

Às 03:10 de 02/06/2025, Dave Swarthout escreveu:

@Antonio
I realize the two destination tags are correct as I stated in my post. 
It's the ref=49 tags on the exit ramps that I object to. Those ways do 
not have any sign indicating a ref and are not typically tagged with a 
ref in my experience. Nor are there any ref tags on any exit ramps in 
the other interchanges I looked at.


@Paul Johnson - thanks, that is my conclusion as well.

On Sun, Jun 1, 2025 at 12:44 PM Paul Johnson  wrote:



On Sun, Jun 1, 2025 at 11:00 AM Dave Swarthout
 wrote:


The original mapper tagged the exit ramps, i.e., the ways
immediately after the exit node (correctly tagged with ref=49,
highway=motorway_junction) with:
destination:ref=NY 78
destination=Depew;Lockport
highway=motorway_link
junction:ref=49
lanes=1
maxspeed:advisory=40 mph
oneway=yes
ref=49
surface=asphalt


Yeah, I'd remove the ref=49 on that, since that's already
correctly reflected in the junction:ref=49 tag and the whole
"using ref=* on ways to make up for route relations not existing
yet" thing's a decade past its prime anyway...



--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog: http://dswarthout.blogspot.com
Flickr: https://www.flickr.com/photos/184600884@N06

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