Re: [Tagging] landform promontory

[Joseph Eisenberg]

>
> >>Where are these features located?
>
> >Inland. Not near the sea.
> >Not all ridges end as a promontory - some have gradual slopes. Not all
> promontory are a peak, they may have a line at about the same height
> leading away from them.
> >They are named as 'point' here but the closest in wikipedia I could find
> is promontory. So I used that term.
>

Interesting. So this is a "node" on a ridge which doesn't qualify as a
summit because it's topographic prominence is zero (it isn't the highest
point, even locally). But it looks kind of like a pointy peak from the low
ground around it, and therefore has a local toponym.

I actually think there are a number of named features currently tagged
natural=peak which are really points or promontories by this definition.
Eg: https://www.opentopomap.org/#map=14/51.82578/10.68691 vs
https://www.openstreetmap.org/#map=14/51.82578/10.68691

It would be nice to have a more precise tag, so that mappers would not
mis-tag named points of hills or ridges as peaks when they are not actually
a summit. Place=locality doesn't give any that it is a geological feature.

I would personally use natural=*, because it fits with all the similar
features: natural=ridge, natural=peak, natural=volcano, natural=cliff,
natural=valley etc.

It would be somewhat ambiguous to use natural=promontory, because as
wikipedia says, this could be a headland or cape, as well as an inland
point or promontory above a valley. Natural=point could also work. However,
if you document the tag with a short wiki page (proposal) that would be
enough to avoid confusion, and we could also put a note on the natural=cape
wiki page warning against mistagging with natural=point or =promontory.

-Joseph

Perhaps 'cape' should be dropped in favour of promontory as that could be
> used for both land and sea? :)
>

PS: ha ha :-)

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

Re: [Tagging] landform promontory

[Andrew Harvey]

On Thu, 4 Oct 2018 at 10:43, Warin <61sundow...@gmail.com> wrote:
> Perhaps 'cape' should be dropped in favour of promontory as that could be 
> used for both land and sea? :)

Water based promontories should stay as natural=cape as per the wiki
they are "prominent, elevated piece of land sticking out into the sea
or large lake", if we want we can add a subtag
cape=point|head|promontory... but to be honest most of the time the
name will give this away already.

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

Re: [Tagging] landform promontory

[Warin]

On 04/10/18 09:40, Joseph Eisenberg wrote:

Where are these features located?


Inland. Not near the sea.

For the same reason you would not tag a cape as a ridge or a peak you 
would not tag a promontory as a ridge or a peak.


Not all ridges end as a promontory - some have gradual slopes. Not all 
promontory are a peak, they may have a line at about the same height 
leading away from them.


They are named as 'point' here but the closest in wikipedia I could find 
is promontory. So I used that term.


Sample?
Node 5946074161 https://www.openstreetmap.org/node/5946074161
node 5950099862 
https://www.openstreetmap.org/node/5950099862#map=19/-33.59309/150.55939 
This does have a named ridge leading to it

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

Perhaps 'cape' should be dropped in favour of promontory as that could 
be used for both land and sea? :)


I haven't seen anything called a "promontory" in the western USA: we 
would call these features ridges or cliffs if they are hills or 
mountains above lower land, or if they are surrounded by water they 
would be a headland, peninsula, cape, or "point".


In OSM, there is already a tag for natural=cape, and the wiki page 
suggests it can be used for all water promontories:
"Cape  - a 
prominent, elevated piece of land sticking out into the sea or large 
lake. Includes capes, heads, headlands, peninsulas and (water) 
promontories."
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcape - used 11,000 
times.


"Natural=*" is perfect in this case, because headlands/capes are 
natural features formed by geological processes and natural erosion.
So if you are tagging "promontories" that project into a lake or sea, 
then use natural=cape on a point.


If you are tagging hills or mountains on land, use natural=ridge as a 
way along the center of the ridge in most cases.
You can also add natural=peak  to a node, if there is a local high 
point that is named.
"Natural=*" is also totally appropriate in this case; ridges and peaks 
are also formed by natural geological and meteorological processes, no?


I've been meaning to ask the folks at OpenStreetMap Carto to start 
rendering the names of ridges as a name label, so that mappers will 
not be tempted to add place=locality or natural=peak when the named 
feature is really a ridge.


Thanks!
Joseph



On Thu, Oct 4, 2018 at 8:20 AM Warin <61sundow...@gmail.com 
> wrote:


Hi,

There is not a tag for the land form 'promontory' meaning a raised
mass
of land projecting into a low land or water body.

See https://en.wikipedia.org/wiki/Promontory

I have come across them as named 'points' and have been tagging a
few of
them as place=locality for lack of something better.


The nearest thing is natural=cape, but that only applies to sea
retaliated things and I don't like the key 'natural' as it applies to
both 'natural' and 'unnatural' thing making a nonsense of the word.


So I think the best tag would be landform=promontory.


Other ideas?



___
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] Default Language Format; language:default or default:language?

[Joseph Eisenberg]

>"in multilingual regions you will typically have a majority and
minorities. Aiming at the majority only would effectively result in a
single name in most multilingual areas "

Sorry, I don't mean "the majority language used in communication" or
anything like that, but "the language used for the majority of named
things"; eg the things we would put in name=*, destination=*, etc.. So in
Brussels, it's still reasonable to put two languages because the local
community uses both languages on street signs. In Morocco, I don't know how
many people actually speak French vs Arabic vs Berber, but the local OSM
community uses all 3 languages in names, so they could also choose to set
that as the default. I'm in favor of letting local communities deciding
what makes sense for their area, rather prescribing what should be done
based on a global rule.

There could also be situations with many languages and no clear majority of
> course, it wouldn’t matter if we say we put “significant” languages,
> according to what the locals think should go there as a default (just like
> the name tag). It is a delicate subject because we should strive to include
> minorities but also beware of trolls, and voting might not help in this
> context.
>

You're right, I'm particularly interested in representing local languages
properly. As a "do-ocracy" without any particular protections for minority
viewpoints, OpenStreetMap is succeptible to the tyranny of the majority.
Unfortunately this isn't something that can be fixed by one new tag.


> What about locally common formats to separate different languages in
>> (multilingual) names, shall we have a different tag for this?
>>
>
> Sorry? Do you mean, should we have a tag that says "use a slash /" or "use
> a dash -" to separate two names?
>
> yes, for example, but also in which order to put them
>

Maybe this would make sense? But I'm not sure how to design such a tag. Any
ideas? For order of display, the order the language codes are entered might
be enough.
My understanding is that it's best to propose just one new tag at a time,
but we could add such a tag next month, if this proposal is approved. I
would also like to add 2 other tags for official languages for other local
languages, but these are all secondary issues.

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

Re: [Tagging] landform promontory

[Joseph Eisenberg]

Where are these features located? I haven't seen anything called a
"promontory" in the western USA: we would call these features ridges or
cliffs if they are hills or mountains above lower land, or if they are
surrounded by water they would be a headland, peninsula, cape, or "point".

In OSM, there is already a tag for natural=cape, and the wiki page suggests
it can be used for all water promontories:
"Cape  - a prominent,
elevated piece of land sticking out into the sea or large lake. Includes
capes, heads, headlands, peninsulas and (water) promontories."
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcape - used 11,000 times.

"Natural=*" is perfect in this case, because headlands/capes are natural
features formed by geological processes and natural erosion.
So if you are tagging "promontories" that project into a lake or sea, then
use natural=cape on a point.

If you are tagging hills or mountains on land, use natural=ridge as a way
along the center of the ridge in most cases.
You can also add natural=peak  to a node, if there is a local high point
that is named.
"Natural=*" is also totally appropriate in this case; ridges and peaks are
also formed by natural geological and meteorological processes, no?

I've been meaning to ask the folks at OpenStreetMap Carto to start
rendering the names of ridges as a name label, so that mappers will not be
tempted to add place=locality or natural=peak when the named feature is
really a ridge.

Thanks!
Joseph



On Thu, Oct 4, 2018 at 8:20 AM Warin <61sundow...@gmail.com> wrote:

> Hi,
>
> There is not a tag for the land form 'promontory' meaning a raised mass
> of land projecting into a low land or water body.
>
> See https://en.wikipedia.org/wiki/Promontory
>
> I have come across them as named 'points' and have been tagging a few of
> them as place=locality for lack of something better.
>
>
> The nearest thing is natural=cape, but that only applies to sea
> retaliated things and I don't like the key 'natural' as it applies to
> both 'natural' and 'unnatural' thing making a nonsense of the word.
>
>
> So I think the best tag would be landform=promontory.
>
>
> Other ideas?
>
>
>
> ___
> 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] landform promontory

[Warin]

Hi,

There is not a tag for the land form 'promontory' meaning a raised mass 
of land projecting into a low land or water body.


See https://en.wikipedia.org/wiki/Promontory

I have come across them as named 'points' and have been tagging a few of 
them as place=locality for lack of something better.



The nearest thing is natural=cape, but that only applies to sea 
retaliated things and I don't like the key 'natural' as it applies to 
both 'natural' and 'unnatural' thing making a nonsense of the word.



So I think the best tag would be landform=promontory.


Other ideas?



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

Re: [Tagging] motorcar definition changed recently

[SelfishSeahorse]

On Wed, 3 Oct 2018 at 11:33, Martin Koppenhoefer  wrote:
>
> I have tried to fix the picture and found, that there are now 2 distinct 
> traffic signs, one is for all 2-tracked motor vehicles, including cars:
> https://en.wikipedia.org/wiki/Road_signs_in_Germany#/media/File:Zeichen_251_-_Verbot_für_Kraftwagen_und_sonstige_mehrspurige_Kraftfahrzeuge,_StVO_1992.svg
>
> The other is explicitly for motorcars (those for the transport of up to 8 
> people, including the driver):
> https://en.wikipedia.org/wiki/Road_signs_in_Germany#/media/File:Zeichen_257-55_-_Verbot_f%C3%BCr_Personenkraftwagen,_StVO_2017.svg

臘

Is anyone aware of other countries where these two traffic signs with
their different meanings are in use?

> How are we going to distinguish these?

We probably cannot avoid defining two new keys, for example car=* and
double_tracked_motor_vehicle=*, and discouraging motorcar=* because of
its ambiguity ¬(motorcar=yes) ≠ (motorcar=no). Then, motorcar=yes can
be converted to car=yes and motorcar=no to
double_tracked_motor_vehicle=no.

In the meantime, i advise everyone to tag 'no entry for any power
driven vehicle except two-wheeled motor cycles without side-car' signs
unambiguously motor_vehicle=no + motorcycle=yes (+ moped=yes/mofa=yes
if not counted as motorcycle).

Regards
Markus

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

Re: [Tagging] hydrants

[Viking]

> How would we verify check date, surely that is a record kept by the fire 
> brigade?
>
> Phil (trigpoint)

Hi Phil,
well, operational_status:date can be inserted directly by firefighters.
I am a firfighter and we are interested in having this information online, 
expecially when we are sent to work in areas out of our jurisdiction.
Alberto


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [Tagging] motorcar definition changed recently

[Allroads]

It is time to give this twofold meaning a split, into two separate keys.
Within openstreetmap it can not have a twofold meaning!

The law in many countries also speaks of double tracked or more then two 
wheels.


It is clear to me the new key must be double_tracked_motor_vehicle or short, 
dt_motor_vehicle, or else, give it a better name.

Allready, fitted in the access hierarchy. With a OSM icon (front car)
As explained here:
https://wiki.openstreetmap.org/wiki/Talk:Key:motorcar
All description and structure already indicate that a split has to be done!


(includes all double-tracked motorised vehicles when used as restriction) 
this must be removed.

It is unworkable. It is a monster. motorcar=no, meaning else.
So many key conditions have to be investigated to find out what is meant by 
motorcar. if and or...is.


I am working on a JOSM  test style to express the access on highway and 
barriers in the road.
For control/check reasons, better to see a icon then watch the written key, 
get the hint, that's why we make maps, make it more understandable.

http://mijndev.openstreetmap.nl/~allroads/JOSM/Styles/Road_extended_JOSM_style_info.html

A key must have one meaning.  If not, it is almost impossible to express the 
access for one type of vehicle. Where can I ride or drive, where not, where 
conditional. Why could I not router there.
Test site: 
http://mijndev.openstreetmap.nl/~allroads/mtmworld/?map=agriculturalways=14=49.79228=6.77223=B0FFTTTF

Also working on a preset. Translating law to tags.
There must be one more hierarchy step, in the lineup to motorcar.
We make it hard for ourselves to deal with this developmental error, 
motorcar two meaning.
Despite, what people give as a meaning to motorcar, Openstreetmap have to 
choose, one meaning, give the others a other key.


Working on this style/site, translating traffic law to keys/value, more keys 
are needed.

single_tracked_vehicle,
non motorized vehicles, what keyname, see disabled vehicles. Small groups, 
maybe they have more benefits than others.

A better hierarchy structure is needed.

So the definition have to be changed once again.

Regards
Allroads




From: SelfishSeahorse
Sent: Wednesday, October 3, 2018 10:03 AM
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] motorcar definition changed recently

On Mon, 3 Sep 2018 at 17:58, Martin Koppenhoefer  
wrote:


Thank you, I have now reverted the change wrt to motorcar.


I've also reverted the change on the page
https://wiki.openstreetmap.org/wiki/Key:motorcar and tried to make the
different meanings of that tag when either used as permission or
restriction clearer.

Regards
Markus

___
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] Default Language Format; language:default or default:language?

[Martin Koppenhoefer]

sent from a phone

> On 2. Oct 2018, at 16:13, Joseph Eisenberg  wrote:
> 
>> On Tue, Oct 2, 2018 at 8:06 PM Martin Koppenhoefer  
>> wrote:
>> 
>> What are the criteria for adding it (e.g. is there a minimum percentage?)?
> 
> I think there should usually be a majority, but that's up to the local 
> community to decide.


in multilingual regions you will typically have a majority and minorities. 
Aiming at the majority only would effectively result in a single name in most 
multilingual areas 


> 
> So for example in Brussels you add both French and Flemish to get to a 
> majority; this is already estabilished. 


according to wikipedia, French is now the defacto language in Brussels with 90% 
of the population speaking it ;-) https://en.m.wikipedia.org/wiki/Brussels
this is from the german wp showing languages spoken at home: 
https://de.m.wikipedia.org/wiki/Brüssel#/media/Datei%3ATaalverdeling_Brussel-DE.png

it is a typical situation with one majority and the other languages in 
minority, but significant.

There could also be situations with many languages and no clear majority of 
course, it wouldn’t matter if we say we put “significant” languages, according 
to what the locals think should go there as a default (just like the name tag). 
It is a delicate subject because we should strive to include minorities but 
also beware of trolls, and voting might not help in this context.


>  
>> What about locally common formats to separate different languages in 
>> (multilingual) names, shall we have a different tag for this?
> 
> Sorry? Do you mean, should we have a tag that says "use a slash /" or "use a 
> dash -" to separate two names?

yes, for example, but also in which order to put them 


> 
> I suppose it could be controversial to change the default language format tag 
> for a particular community.


we’re not tagging communities but the situation at a given location. 
Communities sometimes move, our locations don’t. 

Admin boundaries will move though, so defaults moving around can occur.


> But in practice, would be much easier than changing the content of every 
> single "name=*" tag. 


it would only be easier if you didn’t check them one by one, which would be 
effectively the same as applying an automated edit to every single name tag in 
the area.

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

Re: [Tagging] Default Language Format; language:default or default:language?

[Mateusz Konieczny]

3. Oct 2018 05:06 by graemefi...@gmail.com :
> OK, now I'm getting even more confused?
> Macca's is marked as both name:en & name:th & shows on the map as McDonalds
> But the street just above > https://www.openstreetmap.org/way/77991177 
> > , hotel near by > 
> https://www.openstreetmap.org/way/301472018 
> >  & bank up above > 
> https://www.openstreetmap.org/node/3416994635 
> >  are all marked as both 
> name:en=whatever & name:th, but all display in Thai characters?
> Other shops eg The Scoope > https://www.openstreetmap.org/node/4873971522 
> > , Burger King > 
> https://www.openstreetmap.org/node/907621996 
> >  & Plaza Hair > 
> https://www.openstreetmap.org/node/3417022297 
> >  just say name= & all appear 
> in English. Would I be right in guessing that they've been entered in English 
> so will appear that way?
>
> On Tue, 2 Oct 2018 at 19:07, Martin Koppenhoefer <> dieterdre...@gmail.com 
> > > wrote:
>
>> It is not about language, it rather depends on the local script. Here you 
>> can see someone has added name:en for a McDonald's which I otherwise would 
>> not have found:
>> https://www.openstreetmap.org/way/355033671 
>> 
>
> Similar thing - to me, Macca's appears in squiggles, despite also being 
> listed as name:en=McDonalds, while Giordano's across the road > 
> https://www.openstreetmap.org/node/4620121040 
> >  just has name=Giordano & 
> appears in English?




Default map style[1] on the OSM main page currently displays "name" tag.




[1] https://wiki.openstreetmap.org/wiki/Standard_tile_layer 


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

Re: [Tagging] motorcar definition changed recently

[Martin Koppenhoefer]

I have tried to fix the picture and found, that there are now 2 distinct
traffic signs, one is for all 2-tracked motor vehicles, including cars:
https://en.wikipedia.org/wiki/Road_signs_in_Germany#/media/File:Zeichen_251_-_Verbot_für_Kraftwagen_und_sonstige_mehrspurige_Kraftfahrzeuge,_StVO_1992.svg


The other is explicitly for motorcars (those for the transport of up to 8
people, including the driver):
https://en.wikipedia.org/wiki/Road_signs_in_Germany#/media/File:Zeichen_257-55_-_Verbot_f%C3%BCr_Personenkraftwagen,_StVO_2017.svg

How are we going to distinguish these?

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

Re: [Tagging] relation site <> multipolygon

[Lionel Giard]

My main use for site relation are for historical sites to group the
historical elements of the castle or other historical site including the
wall, moat, buildings (especially the ones touching each other) and various
nodes. An example in the historical commandry of the Hospital order (in
Belgium) here :
https://www.openstreetmap.org/relation/8671447#map=19/50.69111/4.88753 .
The only historical elements are grouped in the relation (we can still see
some of the coat of arms of the order on these buildings...). I couldn't
group all the buildings into a multi-polygon like usual farms as i wanted
to get the distinction between old and new buildings (some of them have
different start_date).
Same thing with an historical farm
https://www.openstreetmap.org/relation/8671752 , i wanted to keep the
information about the different parts of the building (in french here
saying "old stable", "main building", "dovecoat", ...) and once again, the
different parts get different start_date.

For those two examples, i couldn't use the multipolygon due to the
buildings sharing common edge. In those case, the site relation is mostly a
"multi-polygon" whitout its limitations and the possibility to group node
when needed like the old mines where the mineshaft (or the memorial stone
indicating the shaft) are represented as a node. O
Another use of the site relation for historic object is to tag the special
heritage concerning all the site (not only one building or element).

There are also the "multipolygon" for an university dispersed in a city
like in Louvain-la-Neuve (Belgium) :
https://www.openstreetmap.org/relation/8148420#map=16/50.6684/4.6142
If i want to group every part of the university into only 1
amenity=university, i needed a site relation as some part are only "node"
inside a buildings (to indicate the presence of a faculty in a multi
purpose building or one of the underground parking of the university). I
tried with a multi-polygons but i couldn't add the nodes, nor the
"touching" buildings (without creating "pseudo" polygon enveloping both and
without any reality existence). Also, some buildings are multi-polygon
themselft (the "donut-like" buildings) and in at least one case, the inner
ring is not part of the university itself.

I don't find site relation difficult to interpret in those case (as it is
not for rendering !), it is usable by application like gk.historic.place
website that show the site relation objects only (i suppose they only
download the members of the relation).

Le mar. 2 oct. 2018 à 18:03, Marc Gemis  a écrit :

> This relation combines a number of cave entrances the belong to the
> same system that is apparantly protected:
>
> http://gk.historic.place/historische_objekte/translate/en/index-en.html?zoom=16=50.67804=7.22231=BFT=3
> On Tue, Oct 2, 2018 at 5:08 PM Mateusz Konieczny
>  wrote:
> >
> > 2. Październik 2018 12:36 od marc_marc_...@hotmail.com:
> >
> > Le 02. 10. 18 à 11:46, Mateusz Konieczny a écrit :
> > > Can you link this case if that is more complicated?
> > it's a fictional example. ok not the better one.
> >
> > take again the example you cut in the initial message:
> > a wind turbin site with a few turbines represented by a few nodes
> > I hope your solution is not to make a way for each wind turbine
> > to be able to add in into a multipolygon to describe the site.
> > it would not make much sense to make a polygon encompassing all objects
> > between the wind turbines and describe that the whole thing is a wind
> site
> >
> >
> >  I agree that for wind turbines multipolygon may not be feasible.
> >
> >
> > So far it is the only known to me case where site relation maybe is
> useful
> >
> > (I have no experience with features like wind turbine farms so it is hard
> >
> > for me to judge this case - that is why I skipped it).
> >
> > ___
> > 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] motorcar definition changed recently

[SelfishSeahorse]

On Mon, 3 Sep 2018 at 17:58, Martin Koppenhoefer  wrote:
>
> Thank you, I have now reverted the change wrt to motorcar.

I've also reverted the change on the page
https://wiki.openstreetmap.org/wiki/Key:motorcar and tried to make the
different meanings of that tag when either used as permission or
restriction clearer.

Regards
Markus

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