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

[Dave Swarthout]

I do quite a bit of mapping in Thailand and generally speaking, mappers in
our community of OSMers don't tagThai names for brands like McDonalds, KFC,
Burger King, 7-Elevens, Starbucks, and simlilar outfits. Occasionally,
someone will add a name in Thai characters to one of these but the venues
mostly do not display any Thai characters in their signage. I don't
frequent any of them so cannot say that the menus inside use Thai or not
but I doubt they do.

It has been our practice to include all three variants of the names of
roads and shops, that is, name=(Thai script), name:th (also in Thai script)
and name:en. The idea here was that renderers who looked for either name or
name:th but not both would be able to properly display those names in the
Thai language. It's redundant, I know, but that's what we've been doing. We
do similar tagging for banks, fuel stations, and many other shops. Not
everyone who maps in Thailand is using our guidelines so you're likely to
see some variation in the resulting maps.

Not sure if I helped this thread. I haven't been following it but when I
saw this post about Thailand wanted to throw in what I know.

Dave

On Wed, Oct 3, 2018 at 10:07 AM Graeme Fitzpatrick 
wrote:

>
> On Tue, 2 Oct 2018 at 19:54, Joseph Eisenberg 
> wrote:
>
>> There are much better food options than McDonald’s in Thailand!
>>
>
> I'd be astounded if there weren't! - I don't even eat the stuff here :-)
> Just picked the name as something that's found world-wide.
>
> Actually I believe use the original, English brand name on the signs
>> there.
>> https://www.openstreetmap.org/search?query=
>> แมคโดนัลด์%20chang%20mai#map=19/18.78375/99.00043
>>
>> Fortunately, Nominatum will find you things in Thailand even if you
>> search in English, as long as people have added a name:en or an
>> international name in Latin script.
>> Eg name:th=แมคโดนัลด์ and name:en=McDonald’s for the examples above.
>>
>
> 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 
> 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?
>
> Sorry about the questions :-(
>
> Thanks
>
> Graeme
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Graeme Fitzpatrick]

On Tue, 2 Oct 2018 at 19:54, Joseph Eisenberg 
wrote:

> There are much better food options than McDonald’s in Thailand!
>

I'd be astounded if there weren't! - I don't even eat the stuff here :-)
Just picked the name as something that's found world-wide.

Actually I believe use the original, English brand name on the signs there.
> https://www.openstreetmap.org/search?query=
> แมคโดนัลด์%20chang%20mai#map=19/18.78375/99.00043
>
> Fortunately, Nominatum will find you things in Thailand even if you search
> in English, as long as people have added a name:en or an international name
> in Latin script.
> Eg name:th=แมคโดนัลด์ and name:en=McDonald’s for the examples above.
>

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 
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?

Sorry about the questions :-(

Thanks

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

Re: [Tagging] Feature Proposal - RFC - Default Language Format

[Joseph Eisenberg]

Thank you for bringing up this local example. I had wondered about Ireland.

How are the Gaeltacht legally defined?

Is there a public domain source for the boundaries, beyond the street signs?

Do the boundary lines correspond with village or municipal boundaries? I
see that Wiki page Ireland/Boundaries has defined all the way to
Admin_level=9 and 10, for electoral divisions and “townlands”

Here in Indonesia I think it will usually be possible to define the
language for each “kecematan”, admin_level=8, but sometime we will have to
go  to admin_level=9, which are village or neighborhood boundaries.

The nice thing about this proposal (Chrisoph’s Isea originally) is that
tagging countries and provinces (admin_level 2 and 4) will be easy, and
should work for many places. But countries with more complex linguistic
situations can go to admin_level 6, 8, or even more 10.

If that’s total impossible (eg for Canadian First Nations / Native American
Reservations etc, which don’t have an admin level), it will usually fit
with a boundary=aboriginal_lands, or the alternative tagging
boundary=protected_area, class 24 (cultural protection).

But it’s best to use the administrative boundaries with admin_level when
possible, so that database users can compare the admin_level to decide
which tag is locally valid.

Eg, if the Irish county council admin_level=7 is tagged =en, but a
 municipal district (admin_level=8) within that county is tagged =ga, then
use Gaelic for that district. But use English for any other municipal
districts in the council area which are not specifically tagged. Basically
the database application checks the boundaries in descending order from 11
 to 10 to 9... to 2, till it finds a default language format tag.

Joseph

On Tue, Oct 2, 2018 at 11:58 PM Rory McCann  wrote:

> On 24/09/18 14:36, Joseph Eisenberg wrote:
> > "The key language:default=* with a 2 or 3 letter ISO language code
> > should be tagged on administrative boundary relations, such as
> > countries, provinces and aboriginal communities.
>
> In Ireland, there are legally defined areas, collectively "The
> Gaeltacht"[1], where Irish is more common. There are signs when you
> enter, tax breaks, and the place name signs will all be in Irish (rather
> than Irish + English)[2]. I don't think we have them mapped yet, and if
> we did, we could use this format.
>
> *But* there isn't any administrative boundaries that define them. They
> are small and inside other admin boundaries. They aren't "aboriginal
> areas", or "protected areas".
>
> So if you're implementing this, I suggest looking at more than just
> enclosing boundary=administrative area(s).
>
> --
> Rory
>
> [1] https://en.wikipedia.org/wiki/Gaeltacht
> [2] Which can cause problems for tourist towns which use the English
> name: https://en.wikipedia.org/wiki/Dingle#Name
>
>
> ___
> 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] Traffic sign direction tagging..

[yo paseopor]

>
> There's no reason to reinvent the wheel here. Plus, as far as I can tell,
> the suffix (:2) solution doesn't  work when there's more than one "main"
> traffic sign.
>

I dont reinvent anything. Multivalues are hard to manage but also you don't
have more than one "main" traffic signs. European conventions recommends no
more than three values at the same pole, and no more than three
destinations in a sign so a multivalue does not the best solution. Every
sign has its meaning and the combination of the second position for a
traffic sign says you the limit of the first traffic sign, so it is
important to remark the position of the traffic sign. As Finnish people
demonstrate traffic sign second position can be managed without problems.
For example, in the style or the recreation of Kendzi3Ds plugin of JOSM you
can have two or three positions of every traffic sign without problem.

yopaseopor

On Tue, Oct 2, 2018 at 5:55 PM Tobias Knerr  wrote:

> On 02.10.2018 16:44, yo paseopor wrote:
> > Also it is not the best call "undersigns" . There are signs too, with
> > their code, and you can put in on second place or third place , like
> > traffic_sign:2 as Finnish people does.
>
> Or put them in a comma-separated list, which is the international
> standard tagging that's documented on
> https://wiki.osm.org/Key:traffic_sign
>
> There's no reason to reinvent the wheel here. Plus, as far as I can
> tell, the suffix (:2) solution doesn't  work when there's more than one
> "main" traffic sign.
>
> ___
> 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] My "weirdly unnatural aversion to relations"

[Richard]

On Tue, Oct 02, 2018 at 09:32:59PM +0200, Mateusz Konieczny wrote:
> 2. Oct 2018 21:21 by ricoz@gmail.com :
> 
> 
> > On Tue, Oct 02, 2018 at 09:05:53PM +0200, Mateusz Konieczny wrote:
> >
> >>
> >> why abuse? Sole reason for multipolygon relations is to tag 
> >> disjointed areas or areas with holes in them. 
> >
> > you name it. AREAS. A university is not an area.
> 
> 
> 
> 
> Technically it is true.  But area of university is an area.

the problem arises when the university is a sum of diverse and distinct 
features possibly overlapping with other features. Those are not required 
to be areas and if you mix nodes/ways/areas you must use something different.. 
Does the area of the university include the roads and paths there? Country 
specific. How do you exclude them from an area of the university if they 
don't belong to the university?

My feeling is that multipolygons have enough problems if applied to 
true areas.

Richard



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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Tod Fitch]

> On Oct 2, 2018, at 1:22 PM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> sent from a phone
> 
>> On 2. Oct 2018, at 17:01, Mateusz Konieczny  wrote:
>> 
>> Why selecting buildings and tagging them to site relation is easier than 
>> selecting building and adding them to  a multipolygon realation?
> 
> 
> you don’t need polygons for the site relation, you can add nodes…
> 

And on a site relation you can add linear ways.

My thought would be for a ski area. There is may an overall boundary polygon. I 
happen to volunteer at a winter sports area where there is no formal boundary 
but I do see formal boundary markers at alpine/downhill ski areas.

Within the boundary (if it exists), there are likely to be one or more interior 
polygons covering pistes/runs. For a nordic/cross country area the pistes 
themselves are likely to be narrow enough that ways rather than areas would be 
used to map them.

If there is a formal boundary and pistes wide enough to map as areas, how does 
that work? An outer polygon within an outer polygon?

There might be nodes marking locations of emergency equipment cache locations. 
And, for an alpine/downhill ski area there one or more ski lifts/aerial best 
mapped as ways.

So how do you add single nodes or linear ways to a multipolygon?

Using a multipolygon for this sounds a bit like the fellow that only had a 
hammer so everything looks like a nail to them.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Martin Koppenhoefer]

sent from a phone

> On 2. Oct 2018, at 17:01, Mateusz Konieczny  wrote:
> 
> Why selecting buildings and tagging them to site relation is easier than 
> selecting building and adding them to  a multipolygon realation? 


you don’t need polygons for the site relation, you can add nodes...

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Martin Koppenhoefer]

sent from a phone

> On 2. Oct 2018, at 21:05, Mateusz Konieczny  wrote:
> 
> why abuse? Sole reason for multipolygon relations is to tag 
> 
> disjointed areas or areas with holes in them.
> 


it is also useful for “reusing” way geometries to create different logical 
entities (one outer way is the minimum requirement, no holes needed)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Mateusz Konieczny]

2. Oct 2018 21:21 by ricoz@gmail.com :


> On Tue, Oct 02, 2018 at 09:05:53PM +0200, Mateusz Konieczny wrote:
>
>>
>> why abuse? Sole reason for multipolygon relations is to tag 
>> disjointed areas or areas with holes in them. 
>
> you name it. AREAS. A university is not an area.




Technically it is true.  But area of university is an area.




In the same way as building is technically not an area or national park is 


technically not an area.

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Andrew Hain]

The sum total of all of the properties making up a university absolutely is an 
area.

--
Andrew

From: Richard 
Sent: 02 October 2018 20:21:45
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] My "weirdly unnatural aversion to relations"

On Tue, Oct 02, 2018 at 09:05:53PM +0200, Mateusz Konieczny wrote:
>
>
>
> 2. Oct 2018 19:27 by ricoz@gmail.com :
>
>
> > On Tue, Oct 02, 2018 at 05:01:17PM +0200, Mateusz Konieczny wrote:
> >
> >> > I can give you a case that is more complicated.  The University of 
> >> > Edinburgh.  As well as a main>  campus, and a subsidiary mini-campus,  
> >> > it has individual buildings scattered all around the city.> It could be 
> >> > mapped as a multipolygon but it would be a lot of work.  Imagine using a 
> >> > multipolygon>  natural=wood to handle many individual, widely-spaced 
> >> > trees by poking lots ofi rregular, large holes>  in it where trees 
> >> > aren't.
> >> > See > >> https://www.ed.ac.uk/maps/maps 
> >> > >>  <>> https://www.ed.ac.uk/maps/maps 
> >> > >> >>   And note that what you get there 
> >> > is the first of five tabs> covering different agglomerations of 
> >> > buildings.
> >> >
> >> > I think the only feasible way of handling this would be a site relation. 
> >> > Maybe you can think of a better> way of handling it.
> >>
> >>
> >>
> >>
> >> Why selecting buildings and tagging them to site relation is easier than 
> >> selecting building and adding them to  a multipolygon realation?
> >
> > looks like abuse of multipolygon relation to me.
> >
>
>
>
>
> why abuse? Sole reason for multipolygon relations is to tag
> disjointed areas or areas with holes in them.

you name it. AREAS. A university is not an area.

Rcihard

___
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] My "weirdly unnatural aversion to relations"

[Richard]

On Tue, Oct 02, 2018 at 09:05:53PM +0200, Mateusz Konieczny wrote:
> 
> 
> 
> 2. Oct 2018 19:27 by ricoz@gmail.com :
> 
> 
> > On Tue, Oct 02, 2018 at 05:01:17PM +0200, Mateusz Konieczny wrote:
> >
> >> > I can give you a case that is more complicated.  The University of 
> >> > Edinburgh.  As well as a main>  campus, and a subsidiary mini-campus,  
> >> > it has individual buildings scattered all around the city.> It could be 
> >> > mapped as a multipolygon but it would be a lot of work.  Imagine using a 
> >> > multipolygon>  natural=wood to handle many individual, widely-spaced 
> >> > trees by poking lots ofi rregular, large holes>  in it where trees 
> >> > aren't.
> >> > See > >> https://www.ed.ac.uk/maps/maps 
> >> > >>  <>> https://www.ed.ac.uk/maps/maps 
> >> > >> >>   And note that what you get there 
> >> > is the first of five tabs> covering different agglomerations of 
> >> > buildings.
> >> >
> >> > I think the only feasible way of handling this would be a site relation. 
> >> > Maybe you can think of a better> way of handling it.
> >>
> >>
> >>
> >>
> >> Why selecting buildings and tagging them to site relation is easier than 
> >> selecting building and adding them to  a multipolygon realation? 
> >
> > looks like abuse of multipolygon relation to me.
> >
> 
> 
> 
> 
> why abuse? Sole reason for multipolygon relations is to tag 
> disjointed areas or areas with holes in them. 

you name it. AREAS. A university is not an area.

Rcihard

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Mateusz Konieczny]

2. Oct 2018 18:01 by pla16...@gmail.com :


> On Tue, Oct 2, 2018 at 4:39 PM Kevin Kenny <> kevin.b.ke...@gmail.com 
> > > wrote:
>
>> On Tue, Oct 2, 2018 at 11:15 AM Paul Allen <>> pla16...@gmail.com 
>> >> > wrote:
>> >> Why selecting buildings and tagging them to site relation is easier than 
>> >> selecting building and adding them to  a multipolygon realation?
>>
>  
>> Are you labouring under the misapprehension that a multipolygon has to
>> have a single outer ring?
>
> Sorta.  As I read it the outer ring is a polygon.  That polygon might be 
> composed of several> different ways but together they form an continuous 
> outline. 




You may have multiple disjointed outer ways.  See for example 


https://www.openstreetmap.org/relation/61707 


that is a park split by a major road.




Or https://www.openstreetmap.org/relation/2226518 
 - protected area that is not 
continous.


 


> Even if a multipolygon can have many disconnected outers, it seems I'd have 
> to make each university>  building an outer.  And then there are no inners.




Exactly. What you think can be improved to make this misconception less popular?


 

> an abuse of the concept,
>




Not at all. 

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Mateusz Konieczny]

2. Oct 2018 19:27 by ricoz@gmail.com :


> On Tue, Oct 02, 2018 at 05:01:17PM +0200, Mateusz Konieczny wrote:
>
>> > I can give you a case that is more complicated.  The University of 
>> > Edinburgh.  As well as a main>  campus, and a subsidiary mini-campus,  it 
>> > has individual buildings scattered all around the city.> It could be 
>> > mapped as a multipolygon but it would be a lot of work.  Imagine using a 
>> > multipolygon>  natural=wood to handle many individual, widely-spaced trees 
>> > by poking lots ofi rregular, large holes>  in it where trees aren't.
>> > See > >> https://www.ed.ac.uk/maps/maps >> 
>> >  <>> https://www.ed.ac.uk/maps/maps >> >>  
>> >  And note that what you get there is the first of five tabs> covering 
>> > different agglomerations of buildings.
>> >
>> > I think the only feasible way of handling this would be a site relation. 
>> > Maybe you can think of a better> way of handling it.
>>
>>
>>
>>
>> Why selecting buildings and tagging them to site relation is easier than 
>> selecting building and adding them to  a multipolygon realation? 
>
> looks like abuse of multipolygon relation to me.
>




why abuse? Sole reason for multipolygon relations is to tag 


disjointed areas or areas with holes in them. 

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Mark Wagner]

On Tue, 2 Oct 2018 17:01:33 +0100
Paul Allen  wrote:

> Even if a multipolygon can have many disconnected outers, it seems
> I'd have to make each university
> building an outer.  And then there are no inners.  So even if it can
> be done that way, it seems like
> an abuse of the concept, which I thought was to be able to punch
> exclusionary holes in areas.

"Many outers, few if any inners" is a *very* common way to map
complicated geometry.  A quick look at my local area shows a half-dozen
parks, a campground, a school, and a military base, as well as a town
that would be such a multipolygon if the "boundary" type didn't exist.

Punching holes in an area is a common use of multipolygons, because it
can't be done any other way, but it's hardly the only use.

(It's also very common outside of OSM.  My county's land-ownership
database has thousands of these, where a parcel is split by the
right-of-way for a public road.)

-- 
Mark

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

Re: [Tagging] hydrants

[Philip Barnes]

On Mon, 2018-10-01 at 23:29 +0200, Viking wrote:
> > Hi Alberto,
> > Nice to see you back there :)
> > Regarding check_date, I'd go in favor of operational_status:date.
> > working:* is too specific to fully functional hydrants, what about
> > disused or dry ones?
> > Then operational_status is a more complete solution to give state
> > and associated date.
> > All the best
> > François
> 
> Nice to see you too, Francois :)
> Well I proposed working_test:date only because it is already in use
> for hydrants.
> On the other hand, operational_status is used more often, although
> operational_status:date has only 1 occurence.
> Shall we go on discussion page [1]? Even Marc preferred operational
> status, as reported on [1]. 
> 
How would we verify check date, surely that is a record kept by the
fire brigade?

Phil (trigpoint)

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Volker Schmidt]

The description for Edinburgh University applies equally for many of the
older universities all over Europe, including "my" local one, University of
Padova, Italy. It's not present in OSM as a single entity (e.g. site) but
as same fourty separate amenity=university buildings, scattered over the
city. To me a site relation appears the best option OSM offers.

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Richard]

On Tue, Oct 02, 2018 at 05:01:17PM +0200, Mateusz Konieczny wrote:

> > I can give you a case that is more complicated.  The University of 
> > Edinburgh.  As well as a main>  campus, and a subsidiary mini-campus,  it 
> > has individual buildings scattered all around the city.> It could be mapped 
> > as a multipolygon but it would be a lot of work.  Imagine using a 
> > multipolygon>  natural=wood to handle many individual, widely-spaced trees 
> > by poking lots ofi rregular, large holes>  in it where trees aren't.
> > See > https://www.ed.ac.uk/maps/maps >   
> > And note that what you get there is the first of five tabs> covering 
> > different agglomerations of buildings.
> >
> > I think the only feasible way of handling this would be a site relation. 
> > Maybe you can think of a better> way of handling it.
> 
> 
> 
> 
> Why selecting buildings and tagging them to site relation is easier than 
> selecting building and adding them to  a multipolygon realation? 

looks like abuse of multipolygon relation to me.

Richard

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

Re: [Tagging] relation site <> multipolygon

[Marc Gemis]

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Paul Allen]

On Tue, Oct 2, 2018 at 4:39 PM Kevin Kenny  wrote:

> On Tue, Oct 2, 2018 at 11:15 AM Paul Allen  wrote:
> >> Why selecting buildings and tagging them to site relation is easier
> than selecting building and adding them to  a multipolygon realation?
>


> Are you labouring under the misapprehension that a multipolygon has to
> have a single outer ring?


Sorta.  As I read it the outer ring is a polygon.  That polygon might be
composed of several
different ways but together they form an continuous outline.  You appear to
be saying that I can have
several disconnected outer polygons.  Even if I can, it still doesn't
really work well for Edinburgh Uni.


>  That's a single multipolygon, and that's the approach that I'd use for
> the sprawling campus that
>
 you describe.
>

Then I described it badly, and/or you gave the map a very brief glance.  It
is NOT a sprawling
campus.  It is a city with isolated university buildings in it.  So you'd
walk along a public street
and encounter a house, a butcher occupying the ground floor of a house with
flats above,
a bookshop occupying all four floors of a house, a house that is now the
department of music,
a toy shop occupying the ground floor of a house, etc.  Repeat that many
times over.  It's NOT
a campus, it's a city with university buildings scattered here and there.
Well, one tiny part of
the city is a mini-campus to the extent that there are several university
buildings and no
non-university buildings in a small area, but otherwise it's isolated
university buildings in a
sea of non-university buildings.

Even if a multipolygon can have many disconnected outers, it seems I'd have
to make each university
building an outer.  And then there are no inners.  So even if it can be
done that way, it seems like
an abuse of the concept, which I thought was to be able to punch
exclusionary holes in areas.

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

Re: [Tagging] Traffic sign direction tagging..

[Tobias Knerr]

On 02.10.2018 16:44, yo paseopor wrote:
> Also it is not the best call "undersigns" . There are signs too, with
> their code, and you can put in on second place or third place , like
> traffic_sign:2 as Finnish people does.

Or put them in a comma-separated list, which is the international
standard tagging that's documented on
https://wiki.osm.org/Key:traffic_sign

There's no reason to reinvent the wheel here. Plus, as far as I can
tell, the suffix (:2) solution doesn't  work when there's more than one
"main" traffic sign.

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

Re: [Tagging] relation site <> multipolygon

[Yves]

This my pet use case for a site relation:
https://www.openstreetmap.org/relation/3161183#map=7/46.532/6.097

I'm not confortable to draw polygons around the ski pistes to then build a 
landuse=winter_sport multipolygon.
Given the wildlife conservation rules in the area, I also doubt I can include 
the forest between pistes. 
Yves 

Le 2 octobre 2018 17:07:11 GMT+02:00, Mateusz Konieczny 
 a écrit :
>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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Kevin Kenny]

On Tue, Oct 2, 2018 at 11:15 AM Paul Allen  wrote:
>> Why selecting buildings and tagging them to site relation is easier than 
>> selecting building and adding them to  a multipolygon realation?
>
>
> I can't even begin to comprehend how that would possibly work.
>
> Well, maybe I can.  If we make the outer role of the polygon "not university" 
> then we can add the
> individual, scattered buildings as inner role "university."  Seems bizarre to 
> me, but feasible.  It's
> analogous to the way you can use a multipolygon to define a wood with ponds 
> in it.  Except
> "wood" is a concrete term everyone understands but "not university" is not.
>
> If we make the outer role "university" then the inner roles have to be all 
> the places that the
> university buildings are not, with role "not university."  Not only do we 
> have the conceptual
> problem of "not university" but it would be very fiddly to map.
>
> I can't see any way of using multipolygons for this case that makes sense and 
> is easy to do.  If
> you can, then please explain it.
>
> A site relation, however, is simple.  Just add each building to the relation. 
>  Why do you consider
> this to be no easier than the multipolygon approach?

Are you labouring under the misapprehension that a multipolygon has to
have a single outer ring? Otherwise, what you're saying makes no sense
at all to me.

I routinely map state lands that have quite complicated topology, with
holes, islands, disconnected parcels, cutout rights-of-way, just about
everything you can imagine.
https://www.openstreetmap.org/relation/6362702 is an example of how
irregular things can get.  That's a single multipolygon, and that's
the approach that I'd use for the sprawling campus that you describe.

I'm willing to be convinced that site relations are useful, but your
example doesn't convince me.

I agree that relations are underused, but I also agree that PART of
the reason is that only a few types of relation so far (multipolygon,
route, possibly group) are sufficiently well structured that the tools
have something to go on.

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Paul Allen]

On Tue, Oct 2, 2018 at 4:02 PM Mateusz Konieczny 
wrote:

Why selecting buildings and tagging them to site relation is easier than
> selecting building and adding them to  a multipolygon realation?
>

I can't even begin to comprehend how that would possibly work.

Well, maybe I can.  If we make the outer role of the polygon "not
university" then we can add the
individual, scattered buildings as inner role "university."  Seems bizarre
to me, but feasible.  It's
analogous to the way you can use a multipolygon to define a wood with ponds
in it.  Except
"wood" is a concrete term everyone understands but "not university" is not.

If we make the outer role "university" then the inner roles have to be all
the places that the
university buildings are not, with role "not university."  Not only do we
have the conceptual
problem of "not university" but it would be very fiddly to map.

I can't see any way of using multipolygons for this case that makes sense
and is easy to do.  If
you can, then please explain it.

A site relation, however, is simple.  Just add each building to the
relation.  Why do you consider
this to be no easier than the multipolygon approach?

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

Re: [Tagging] relation site <> multipolygon

[Mateusz Konieczny]

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Mateusz Konieczny]

2. Październik 2018 13:30 od pla16...@gmail.com :


> On Tue, Oct 2, 2018 at 10:47 AM Mateusz Konieczny <> matkoni...@tutanota.com 
> > > wrote:
>
>>   >> 2. Oct 2018 11:44 by >> marc_marc_...@hotmail.com 
>> >> :
>>
>>
>>> or a school that has 3 buildings on the same street but with other 
>>> buildings among themselves that do not belong to the school.
>>>
>>
>>
>>
>>
>> Sounds like a simple multipolygon with these 3 buildings as outer ways.
>>
>>
>>
>>
>> Can you link this case if that is more complicated?
>>
>>   
> I can give you a case that is more complicated.  The University of Edinburgh. 
>  As well as a main>  campus, and a subsidiary mini-campus,  it has individual 
> buildings scattered all around the city.> It could be mapped as a 
> multipolygon but it would be a lot of work.  Imagine using a multipolygon>  
> natural=wood to handle many individual, widely-spaced trees by poking lots 
> ofi rregular, large holes>  in it where trees aren't.
> See > https://www.ed.ac.uk/maps/maps >   And 
> note that what you get there is the first of five tabs> covering different 
> agglomerations of buildings.
>
> I think the only feasible way of handling this would be a site relation. 
> Maybe you can think of a better> way of handling it.




Why selecting buildings and tagging them to site relation is easier than 
selecting building and adding them to  a multipolygon realation? 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Default Language Format

[Rory McCann]

On 24/09/18 14:36, Joseph Eisenberg wrote:

"The key language:default=* with a 2 or 3 letter ISO language code
should be tagged on administrative boundary relations, such as
countries, provinces and aboriginal communities.


In Ireland, there are legally defined areas, collectively "The
Gaeltacht"[1], where Irish is more common. There are signs when you
enter, tax breaks, and the place name signs will all be in Irish (rather
than Irish + English)[2]. I don't think we have them mapped yet, and if
we did, we could use this format.

*But* there isn't any administrative boundaries that define them. They
are small and inside other admin boundaries. They aren't "aboriginal
areas", or "protected areas".

So if you're implementing this, I suggest looking at more than just
enclosing boundary=administrative area(s).

--
Rory

[1] https://en.wikipedia.org/wiki/Gaeltacht
[2] Which can cause problems for tourist towns which use the English 
name: https://en.wikipedia.org/wiki/Dingle#Name



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

Re: [Tagging] Traffic sign direction tagging..

[yo paseopor]

It is not the better thing to say " we can't control the tagging of an item
so we can map it".  Why we can't control them? Can we control the trees you
have on the map? Can we control the street lamps of the map?...so we can
control EVERYTHING on the map and its orientation (of course with the
correct technology now we have, like Mapillary's and others). Traffic signs
informs you about something specific of the way, example, the end of the
cycle way, so you can see where the traffic sign is correct to put on.

Also it is not the best call "undersigns" . There are signs too, with their
code, and you can put in on second place or third place , like
traffic_sign:2 as Finnish people does. And as you say second position
traffic sign will be so important as the first position is.

It is difficult to have two traffic signs in both directions with the same
meaning so you don't need traffic_sign:2:direction. If you need so you can
put a node next to or above or beside to the other with all that other
directions' info

Also don't forget the tag side=  and all of their values

yopaseopor

On Tue, Oct 2, 2018 at 4:03 PM Allroads  wrote:

> Traffic_sign is on a node beside of above a road. There where, it is.
> This is the basis, the derivative is tagged on the road, as ...
>
> The direction=* says, the facing direction of the sign/shield. Important:
> indicates the direction in which the law applies. This could be various.
> Depends on sign and undersign.
> A combination of trafficsign and undersign is important, it indicates a
> combined rule, summarized in a value.
> But there could be more trafficsigns on a node even a highway=street_lamp,
> the direction=* can not be used.
> traffic_sign:1:direction=*  facing direction is used.
> traffic_sign:2:direction=*
> street_lamp:direction=*
>
> Then the derivated on the way.
>
> This could be the whole way.
> motor_vehicle:forward=no
>
> But also on a node of a way ( not the first and last node) like give_way.
> The most directly derived tagging is tagging the traffic sign itself.
> First
> degree derived tagging.
> Second degree tagging are the access tags.
> If you have first degree tagging, the second degree could be controlled,
> if
> it is correct.
> In the Netherlands we started to tag the traffic_sign on a cycleway, then
> knowing which vehicle key/value is needed
> Now with overpass we can control if tagging is correct on the cycleway G11
> (mofa designated), G12a (mofa mofa designated), G13.
> This way we get more qualitative data.
>
> http://mijndev.openstreetmap.nl/~peewee32/traffic_sign/traffic_sign.htm?map=cycleways=16=52.13023=5.41893=B000FFTFTFFF
>
> Then on a waynode. like give_way.
> C6 traffic_sign.
>
> https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring
> The working-out of the law, says, that goes into effect when you pass the
> shield at the front. And must be repeated after each crossing.
> This traffic sign can stand on one side of the road.
> If you come from the other side, there is no shield, drive in and you
> visit
> a house, a plot, or you decide to turn around, this is allowed by law.
> This you could do, for example 10 meters from the back of the shield, turn
> around.
>
> This place is a like a give-way construction on a node., with access
> traffic_sign:forward=NL:C6  (first derivated tagging, could used to
> control
> the other tags)
> motor_vehicle:forward=no
> motorcycle:forward=yes
> moped:forward=yes
> mofa:forward=yes
>
> some use a 10 meters way to set the tags.
>
> forward, indicates the direction of operation of the law in relation to
> the
> Openstreetmap drawing direction.
>
> >> `traffic_sign:direction=forward/backward`
> Here direction is facing direction on the sign.
> And can not be used a working-out direction of the law.
> traffic: forward= and traffic_sign:backward is correct.
>
> I do not agree!
>
> In combination with traffic_sign, direction can only be used  on separated
> node besides the road (or above), given the facing direction, there are
> signs with undersign with a left or right arrow, indicating in which
> direction the sign works,
> then the facing direction must be correct, often this is 90 degrees on the
> driving direction, or on other side of a T junction.
>
> If the traffic_sign (first degree derivated) is not tagged it is almost
> impossible to control tagging. With all combinations and undersigns.
>
> Regards.
> Allroads
>
>
>
> -Oorspronkelijk bericht-
> From: Marc Gemis
> Sent: Tuesday, October 2, 2018 2:04 PM
> To: Tag discussion, strategy and related tools
> Subject: Re: [Tagging] Traffic sign direction tagging..
>
> >>
> >> >  To keep things simple, we'll do the same thing for traffic signs:
> >> `traffic_sign:direction=forward/backward`
> >
> >
> > Please , for doing traffic_sign:direction is better to put direction=*
> > tag.
> >
> >> > I still highway=give_way and highway=stop with
> >> direction=forward/backward (which 

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

[Joseph Eisenberg]

On Tue, Oct 2, 2018 at 8:06 PM Martin Koppenhoefer 
wrote:

> I’m interested in the way it works. Are there multiple values allowed?


Yes; you can use "=fr;nl" for Brussels and "=zh;zh_pinyin" for Hong Kong,
because the local communities in those cities have already decided to
display both languages, to represent the situation on the ground (both
language formats are shown in street signs). Hopefully most communities
will only need one language, but a number of places will need up to three
(eg Morocco currently puts French, Berber and Arabic in all default names!)


> Is the order important? If yes, how to deal with rtl and ltr mixed?


I don't think so; database users could interpret "fr;nl" as "put the French
name first or on top", but it is up to the application / renderer.
The idea is that the database user would look for the name:=* tag (or
tags) that match the  in the default language format tag. So in
Brussels, the database application should look for name:fr=* and name:nl=*.
If both are found, the database user can use both names as labels, or for
audio directions, etc.
If neither language-specific name is found, then use the default name=* tag
as before.

For Morocco, where you'll have name:fr=* and name:ara=* (French and
Arabic), you can write the French name left to right, and the Arabic name
right to left; no problem. (I don't know which way Berber script is
written!)


> 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. The wiki page on Multilingual Names already shows the
current situation for a number of places. The same considerations that
currently are used to decide what goes in the default "name=*" tag should
be used to set the defaul language format. But since it won't be such an
ugly hack to support more than one langauge, I think a few places may be
willing to use two languages instead of just one.

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

In Wales, there would probably be some counties where English is the
default langauge format, other counties where Welsh is the majority
language, and maybe a few places where the local community wants to show
both names? I read the long debate about this in the GB mailing list last
year. A number of people disliked the idea of putting two names in the
"name=*" tag, reasonably enough, but were happy to tag both name:en=* and
name:cy=* (Welsh).


> Can we agree that this is orthogonal to official language(s)?


Yes, this isn't about legislation or "official" languages, but about
actually on-the-ground use. In particular, it's the dialect and script used
for the names of places, streets and significant geographic features (and
the names of shops / businesses to a lesser extent, though these are
sometimes not in any particular language). Often this will match the
officially declared language, but not always.


> 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?


> A general problem with codified defaults is that potential changes in the
> future to the default are hard to realize, maybe for local languages this
> is less important though, because a change would imply other big changes
> (peoples moving) that the local mapping community would completely change
> as well.
>

I suppose it could be controversial to change the default language format
tag for a particular community. But in practice, would be much easier than
changing the content of every single "name=*" tag.

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

Re: [Tagging] Traffic sign direction tagging..

[Allroads]

Traffic_sign is on a node beside of above a road. There where, it is.
This is the basis, the derivative is tagged on the road, as ...

The direction=* says, the facing direction of the sign/shield. Important: 
indicates the direction in which the law applies. This could be various. 
Depends on sign and undersign.
A combination of trafficsign and undersign is important, it indicates a 
combined rule, summarized in a value.
But there could be more trafficsigns on a node even a highway=street_lamp, 
the direction=* can not be used.

traffic_sign:1:direction=*  facing direction is used.
traffic_sign:2:direction=*
street_lamp:direction=*

Then the derivated on the way.

This could be the whole way.
motor_vehicle:forward=no

But also on a node of a way ( not the first and last node) like give_way.
The most directly derived tagging is tagging the traffic sign itself. First 
degree derived tagging.

Second degree tagging are the access tags.
If you have first degree tagging, the second degree could be controlled, if 
it is correct.
In the Netherlands we started to tag the traffic_sign on a cycleway, then 
knowing which vehicle key/value is needed
Now with overpass we can control if tagging is correct on the cycleway G11 
(mofa designated), G12a (mofa mofa designated), G13.

This way we get more qualitative data.
http://mijndev.openstreetmap.nl/~peewee32/traffic_sign/traffic_sign.htm?map=cycleways=16=52.13023=5.41893=B000FFTFTFFF

Then on a waynode. like give_way.
C6 traffic_sign. 
https://wiki.openstreetmap.org/wiki/NL:Overzicht_Nederlandse_Verkeersborden#C:_Geslotenverklaring
The working-out of the law, says, that goes into effect when you pass the 
shield at the front. And must be repeated after each crossing.

This traffic sign can stand on one side of the road.
If you come from the other side, there is no shield, drive in and you visit 
a house, a plot, or you decide to turn around, this is allowed by law.
This you could do, for example 10 meters from the back of the shield, turn 
around.


This place is a like a give-way construction on a node., with access
traffic_sign:forward=NL:C6  (first derivated tagging, could used to control 
the other tags)

motor_vehicle:forward=no
motorcycle:forward=yes
moped:forward=yes
mofa:forward=yes

some use a 10 meters way to set the tags.

forward, indicates the direction of operation of the law in relation to the 
Openstreetmap drawing direction.



`traffic_sign:direction=forward/backward`

Here direction is facing direction on the sign.
And can not be used a working-out direction of the law.
traffic: forward= and traffic_sign:backward is correct.

I do not agree!

In combination with traffic_sign, direction can only be used  on separated 
node besides the road (or above), given the facing direction, there are 
signs with undersign with a left or right arrow, indicating in which 
direction the sign works,
then the facing direction must be correct, often this is 90 degrees on the 
driving direction, or on other side of a T junction.


If the traffic_sign (first degree derivated) is not tagged it is almost 
impossible to control tagging. With all combinations and undersigns.


Regards.
Allroads



-Oorspronkelijk bericht- 
From: Marc Gemis

Sent: Tuesday, October 2, 2018 2:04 PM
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Traffic sign direction tagging..



>  To keep things simple, we'll do the same thing for traffic signs:
`traffic_sign:direction=forward/backward`



Please , for doing traffic_sign:direction is better to put direction=* 
tag.



> I still highway=give_way and highway=stop with
direction=forward/backward (which is used by OsmAnd AFAIK).



And what about the other traffic signs. Are they not important? Why don't 
erase it...from the World if they are not important?


I don't map other signs, for most other signs I map the result on the
way (e.g. maxspeed sign, no overtaking). Why would I map the sign
separately ?
Give ways and stop signs are slightly different, because they usually
indicate a single place on the road where one has to stop. The result
of the sign is commonly mapped as a node, not as a tag on the way
(yes, I know there are cases where a relation might be needed).

So yes, for me the position of the other signs is not important. Feel
free to add them if you feel they are important.

regards

m.

___
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] landuse for government offices ?

[Joseph Eisenberg]

Oh, I understand this tag.

I was just concerned that other mappers might misuse the tag if it isn't
clear.

I know that as a new user (just a few months ago!) I would often just try
typing in words in the ID editor,
and picking the tag that looked right. Who has time to follow the link to
the wiki for everything?
So it's a good idea if the tag name is as unambiguous as possible.

On Tue, Oct 2, 2018 at 9:14 PM John Willis  wrote:

>
>
> Javbw
>
> > On Oct 2, 2018, at 8:02 AM, Joseph Eisenberg 
> wrote:
> >
> > 90% of the land in some western American States will be owned and
> managed by some level of government
>
> This is not about who is on the operator=* tag on a hundred square miles
> of grazing lands in Colorado.
>
> It is about mapping the landuse for the *office building* for the land
> administration office in the state capital that handles the applications
> from ranchers wanting to use that land.
>
> National parks, preserves, grazing lands, military bases, and other
> "lands" controlled by the government are simply empty land with a boundary
> (which have very specific tags),  which would be tagged as they normally
> should be now.
>
> "Civic Admin" is about mapping the offices and centers where Civic
> employees do their job and interface with citizens - not where cows
> interface with grass 
>
> Land literally used for Civic administration -or any land for sale would
> be "landuse=retail" ! 
>
> Javbw.
> ___
> 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] Traffic sign direction tagging..

[yo paseopor]

Ok

Are you agree with the tag traffic_sign:direction=forward/backward?

If you are agree please change "automatically" all the
traffic_signs:forward/backward to the new
traffic_sign:direction)=forward/backward
If you do that I would change all the presets, the styles and the kendzi3D
instructions for JOSM, Taginfo projects info and all the maps done with
these codes.

salut i senyals de trànsit (health and traffic signs)
yopaseopor




On Tue, Oct 2, 2018 at 12:45 AM Bryan Housel  wrote:

> On Oct 1, 2018, at 5:23 PM, yo paseopor  wrote:
>
>  > ^ This is the problem.  The wiki says we are supposed to do something
>> like `traffic_sign:forward=US:R1`, and we can't really do that. A preset
>> needs to be based on a "toplevel" tag like `traffic_sign=*` not
>> `traffic_sign:forward=*` or `traffic_sign:backward=*` (remember seamark?
>> many of their tags have this issue too, where they put a value in the key
>> part, and so we can’t turn it into a preset).
>>
>
>  JOSM can do this change (when you change a way) as you can see on
> https://i.imgur.com/NnLpKWR.jpg
>
>
> iD will also do this change when reversing a way.  That’s not what my
> email is about.
>
>
>  If you read taginfo you can find for forward subtags
> https://taginfo.openstreetmap.org/search?q=%3Aforward more than 80
> nodes. If you read taginfo for backward
> https://taginfo.openstreetmap.org/search?q=%3Abackward you can find more
> than 80 nodes. Are you saying iD doesn't recognise all these tags with
> forward and backward subtags?
>
>
> Nope, not saying that at all.
>
>
>  I give you a solution: make two presets: one for traffic_sign:backward
> and other with the same values for traffic_sign:forward.
>
>
> That’s a bad solution, so instead we’re going to solve the problem of
> indicating traffic sign direction the same way it’s already solved for
> traffic signals.  `traffic_sign:direction=forward/backward` - simple.  I
> will even convert all the existing traffic signs tagged with
> `traffic_sign:forward` or `traffic_sign:backward` to work this way if you
> want.  It’s an unambiguous tag change.
>
> I wouldn't know how to explain to mappers when to use a “Traffic Sign” vs
> a “Forward Facing Traffic Sign” vs a “Backward Facing Traffic Sign” much
> less translating these concepts to dozens of different languages.
>
>
> Thanks, Bryan
>
> ___
> 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] landuse for government offices ?

[John Willis]

Javbw

> On Oct 2, 2018, at 8:02 AM, Joseph Eisenberg  
> wrote:
> 
> 90% of the land in some western American States will be owned and managed by 
> some level of government

This is not about who is on the operator=* tag on a hundred square miles of 
grazing lands in Colorado. 

It is about mapping the landuse for the *office building* for the land 
administration office in the state capital that handles the applications from 
ranchers wanting to use that land. 

National parks, preserves, grazing lands, military bases, and other "lands" 
controlled by the government are simply empty land with a boundary (which have 
very specific tags),  which would be tagged as they normally should be now. 

"Civic Admin" is about mapping the offices and centers where Civic employees do 
their job and interface with citizens - not where cows interface with grass 

Land literally used for Civic administration -or any land for sale would be 
"landuse=retail" ! 

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

Re: [Tagging] Traffic sign direction tagging..

[Marc Gemis]

>>
>> >  To keep things simple, we'll do the same thing for traffic signs:
>> `traffic_sign:direction=forward/backward`
>
>
> Please , for doing traffic_sign:direction is better to put direction=* tag.
>
>> > I still highway=give_way and highway=stop with
>> direction=forward/backward (which is used by OsmAnd AFAIK).
>
>
> And what about the other traffic signs. Are they not important? Why don't 
> erase it...from the World if they are not important?

I don't map other signs, for most other signs I map the result on the
way (e.g. maxspeed sign, no overtaking). Why would I map the sign
separately ?
Give ways and stop signs are slightly different, because they usually
indicate a single place on the road where one has to stop. The result
of the sign is commonly mapped as a node, not as a tag on the way
(yes, I know there are cases where a relation might be needed).

So yes, for me the position of the other signs is not important. Feel
free to add them if you feel they are important.

regards

m.

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

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

[Marc Gemis]

But what if the pronunciation of a known brand is different ?  e.g. VW
is pronounced differently in Dutch and German. IKEA is different in
Dutch and English, Opel in French and German, etc. I know that they
are brands, but do you expect those "common" names to be pronounced in
the local language of in your own language, e.g. when used in
combination with a town (as mentioned elsewhere) ?
On Tue, Oct 2, 2018 at 12:02 PM Martin Koppenhoefer
 wrote:
>
>
>
> Am Di., 2. Okt. 2018 um 11:40 Uhr schrieb Joseph Eisenberg 
> :
>>
>> If it’s in Germany, it would be perfectly fine to use name:de=Spazio Italian 
>> Bistrot, if most local people will be pronouncing it like a German name. But 
>> it might make the most sense to just use name=* or brand=* without 
>> attempting to pick a language.
>
>
>
> indeed, pronounciation is key for me, too. A navigation app which names this 
> place should ideally pronounce it "correctly" as would a local (someone in 
> the language that is set in the app) do. My guess is that most Germans would 
> pronounce "spazio" with a German accent but would recognize it as an Italian 
> word and German being here similar in pronounciation to Italian, would be 
> easily understandable for an Italian. Most Germans  would probably try to 
> pronounce "Italian" as English (63% declared to be able to speak English) and 
> all but the most educationally challenged would pronounce "Bistrot" in French 
> (which is the common pronounciation in German 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] My "weirdly unnatural aversion to relations"

[Paul Allen]

On Tue, Oct 2, 2018 at 10:47 AM Mateusz Konieczny 
wrote:

> 2. Oct 2018 11:44 by marc_marc_...@hotmail.com:
>
> or a school that has 3 buildings on the same street but with other
> buildings among themselves that do not belong to the school.
>
>
> Sounds like a simple multipolygon with these 3 buildings as outer ways.
>
>
> Can you link this case if that is more complicated?
>
I can give you a case that is more complicated.  The University of
Edinburgh.  As well as a main
campus, and a subsidiary mini-campus,  it has individual buildings
scattered all around the city.
It could be mapped as a multipolygon but it would be a lot of work.
Imagine using a multipolygon
natural=wood to handle many individual, widely-spaced trees by poking lots
ofi rregular, large holes
in it where trees aren't.

See https://www.ed.ac.uk/maps/maps  And note that what you get there is the
first of five tabs
covering different agglomerations of buildings.

I think the only feasible way of handling this would be a site relation.
Maybe you can think of a better
way of handling it.

-- 
Paul
___
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 12:09, Joseph Eisenberg  wrote:
> 
> Should the tag be default:language=* rather than language:default=*?


it is just names, it doesn’t matter for me which one is first. Or 
default_language. 

I’m interested in the way it works. Are there multiple values allowed? Is the 
order important? If yes, how to deal with rtl and ltr mixed? What are the 
criteria for adding it (e.g. is there a minimum percentage?)? Can we agree that 
this is orthogonal to official language(s)? What about locally common formats 
to separate different languages in (multilingual) names, shall we have a 
different tag for this?

A general problem with codified defaults is that potential changes in the 
future to the default are hard to realize, maybe for local languages this is 
less important though, because a change would imply other big changes (peoples 
moving) that the local mapping community would completely change as well.

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Martin Koppenhoefer]

sent from a phone

> On 2. Oct 2018, at 12:11, Yves  wrote:
> 
> It's interesting and it would be godd to keep in the archives. 


for the archives it would be best to put summaries of the discussion in the 
wiki, e.g. on the talk pages, and or link the ML thread from there. I’ve been 
doing this occasionally, but admittedly more often have not.


Cheers,
Martin 



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

[Tagging] relation site <> multipolygon

[marc marc]

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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Dave F]

Hi

Please be aware OSM is geospatially aware. Your example should have a 
boundary from which any amenity within can be determined.


I've noticed an increase in the unnecessary use relations in the belief 
they're the only way to 'collect things together'. The 'site' type is 
just one example. It appears the public transport schema is a major 
contributor to this misuse.


Even the wiki for 'site' gives a fake example.
https://wiki.openstreetmap.org/wiki/Types_of_relation#Established_relations

Cheers
DaveF



On 02/10/2018 04:15, Paul Johnson wrote:

Care to expand?

- this data is basically not usable.

Sure it is.  Say I want to know what amenities an RV park has in 
another city...


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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Yves]

Let's start another thread site VS multipolygons.
It's interesting and it would be godd to keep in the archives. 

Le 2 octobre 2018 12:00:15 GMT+02:00, Mateusz Konieczny 
 a écrit :
>2. Oct 2018 05:15 by ba...@ursamundi.org :
>
>
>>>
>>>
>>>
>>>  - this data is basically not usable. 
>>>
>> Sure it is.  Say I want to know what amenities an RV park has in
>another city...you could go  "hey, what does Somewhereville RV Park
>have?" or just throw Somewhereville RV Park and get a list of
>everything that belongs to the same site.  Dump station, fuel pump,
>convenience store, information stand, mailboxes, laundry, showers,
>toilets...regardless of whether or not these things are named or not,
>or even share the same name as the RV park itself.  Like, say, "Old
>Faceful Geyser" (actually a splashpad) in the "Jellystone Park" RV park
>at Lake Eufaula (to use something I might try if I was taking my
>boyfriend and niece truck camping and wasn't actually familiar with
>this being a delightfully furry, yet corny, and relatively comfortable
>for cheap truck-tent camping).
>
> 
>I am not sure how it requires a site relation. Mapping feature as a
>polygon is sufficient tomark objects inside this polygon as, well,
>inside the polygon.
>In rare cases of holes/disjointed areas multipolygon is needed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Joseph Eisenberg]

BTW, do you have an opinion about the subject of this thread?

Should the tag be default:language=* rather than language:default=*?

It will be some work to edit the proposal to change the order of the tag,
but I'll be happy to do it if a few more people agree.

On Tue, Oct 2, 2018 at 7:02 PM Martin Koppenhoefer 
wrote:

>
>
> Am Di., 2. Okt. 2018 um 11:40 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> If it’s in Germany, it would be perfectly fine to use name:de=Spazio
>> Italian Bistrot, if most local people will be pronouncing it like a German
>> name. But it might make the most sense to just use name=* or brand=*
>> without attempting to pick a language.
>>
>
>
> indeed, pronounciation is key for me, too. A navigation app which names
> this place should ideally pronounce it "correctly" as would a local
> (someone in the language that is set in the app) do. My guess is that most
> Germans would pronounce "spazio" with a German accent but would recognize
> it as an Italian word and German being here similar in pronounciation to
> Italian, would be easily understandable for an Italian. Most Germans  would
> probably try to pronounce "Italian" as English (63% declared to be able to
> speak English) and all but the most educationally challenged would
> pronounce "Bistrot" in French (which is the common pronounciation in German
> 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] Default Language Format; language:default or default:language?

[Martin Koppenhoefer]

Am Di., 2. Okt. 2018 um 11:54 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> There are much better food options than McDonald’s in Thailand!
>


Food? It could be interesting for the toilets.

Looking at Dubai, they seem to double post fast food brand names, but the
place is clearly more international than the typical situation:
https://c8.alamy.com/comp/AER3G9/kfc-und-mcdonalds-in-dubai-AER3G9.jpg

In Casablanca I've found pictures with only arabic script, but also others
with latin script as well:
http://www.viepratique.ma/media_external/entreprises_pictures/3030330/10603152200739627546.PNG
same as in Cairo:
https://farm9.static.flickr.com/8437/7877723944_e4a2254187_b.jpg


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

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

[Martin Koppenhoefer]

Am Di., 2. Okt. 2018 um 11:40 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> If it’s in Germany, it would be perfectly fine to use name:de=Spazio
> Italian Bistrot, if most local people will be pronouncing it like a German
> name. But it might make the most sense to just use name=* or brand=*
> without attempting to pick a language.
>


indeed, pronounciation is key for me, too. A navigation app which names
this place should ideally pronounce it "correctly" as would a local
(someone in the language that is set in the app) do. My guess is that most
Germans would pronounce "spazio" with a German accent but would recognize
it as an Italian word and German being here similar in pronounciation to
Italian, would be easily understandable for an Italian. Most Germans  would
probably try to pronounce "Italian" as English (63% declared to be able to
speak English) and all but the most educationally challenged would
pronounce "Bistrot" in French (which is the common pronounciation in German
as well).

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[Mateusz Konieczny]

2. Oct 2018 05:15 by ba...@ursamundi.org :


>>
>>
>>
>>  - this data is basically not usable. 
>>
> Sure it is.  Say I want to know what amenities an RV park has in another 
> city...you could go  "hey, what does Somewhereville RV Park have?" or just 
> throw Somewhereville RV Park and get a list of everything that belongs to the 
> same site.  Dump station, fuel pump, convenience store, information stand, 
> mailboxes, laundry, showers, toilets...regardless of whether or not these 
> things are named or not, or even share the same name as the RV park itself.  
> Like, say, "Old Faceful Geyser" (actually a splashpad) in the "Jellystone 
> Park" RV park at Lake Eufaula (to use something I might try if I was taking 
> my boyfriend and niece truck camping and wasn't actually familiar with this 
> being a delightfully furry, yet corny, and relatively comfortable for cheap 
> truck-tent camping).

 
I am not sure how it requires a site relation. Mapping feature as a polygon is 
sufficient tomark objects inside this polygon as, well, inside the polygon.
In rare cases of holes/disjointed areas multipolygon is needed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Joseph Eisenberg]

There are much better food options than McDonald’s in Thailand!
Actually I believe use the original, English brand name on the signs there.
https://www.openstreetmap.org/search?query=
แมคโดนัลด์%20chang%20mai#map=19/18.78375/99.00043

Fortunately, Nominatum will find you things in Thailand even if you search
in English, as long as people have added a name:en or an international name
in Latin script.
Eg name:th=แมคโดนัลด์ and name:en=McDonald’s for the examples above. The
local operator=McThai ! www.mcthai.co.th :-)

Joseph

On Tue, Oct 2, 2018 at 2:00 PM Graeme Fitzpatrick 
wrote:

>
>
> On Tue, 2 Oct 2018 at 11:17, Joseph Eisenberg 
> wrote:
>
>>
>> *TL:DR -* the language of a Brand names cannot always be determined (but
>> in this case it's English).
>> Usualy the most common language in the region will be used for invented
>> shop & restaurant brand names,
>>
>
> That's something that I've been wondering about during this discussion of
> how names would appear & so on.
>
> As a real common example, you have McDonalds all (or virtually) over the
> world, so how does the name appear on OSM maps in non-English speaking
> countries?
>
> I know that if I use OSM from Australia & go to other countries, then
> their map appears in the local language. So if I go to eg Thailand or
> Cambodia, https://www.openstreetmap.org/#map=7/16.810/97.405, can I still
> search OSM for "McDonalds", or do I have to search for some squiggly
> hieroglyphics? (With no offence intended to any Thais or Cambodians!)
>
> 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] My "weirdly unnatural aversion to relations"

[Mateusz Konieczny]

2. Oct 2018 11:44 by marc_marc_...@hotmail.com 
:


> or a school that has 3 buildings on the same street but with other 
> buildings among themselves that do not belong to the school.
>




Sounds like a simple multipolygon with these 3 buildings as outer ways.




Can you link this case if that is more complicated?

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

Re: [Tagging] My "weirdly unnatural aversion to relations"

[marc marc]

Le 02. 10. 18 à 11:27, Martin Koppenhoefer a écrit :
> Am Di., 2. Okt. 2018 um 06:32 Uhr schrieb Joseph Eisenberg 
>  
> You are supposed to be able to get all that information by using a
> closed way

exept for distributed site like wind turbine site
or a school that has 3 buildings on the same street but with other 
buildings among themselves that do not belong to the school.
it's the difference between site and polygon relationship:
if it's possible to put everything in a polygon, it's better.
but if not, how do detractors of the site relationship do it ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Joseph Eisenberg]

Oops, I should have checked the map! I assumed it was in England for some
reason. My internet connection is terrible and I avoid following links.

If it’s in Germany, it would be perfectly fine to use name:de=Spazio
Italian Bistrot, if most local people will be pronouncing it like a German
name. But it might make the most sense to just use name=* or brand=*
without attempting to pick a language.

On Tue, Oct 2, 2018 at 6:04 PM Martin Koppenhoefer 
wrote:

> Am Di., 2. Okt. 2018 um 03:17 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> It's not always necessary or possible to interpret the language of a
>> brand name.
>>
>
>
> +1
>
>
>
>>
>> But in this case I think we can say it's clearly an English brand name.
>> "Spazio Italian Bistrot" isn't a real name, but a brand name, like KFC,
>> IKEA, etc.
>>
>
>
> with the difference that it is just the name of a single restaurant in
> Germany and not of a worldwide operating multinational company with
> hundreds of shops.
>
>
>
>> I suspect the less-common spelling of "Bistrot" is meant to make the
>> brand more copyright-worthy
>>
>
>
> it is the prevailing spelling in French. Being a French word I would say
> it is safe to assume that this part of the name is French.
>
>
>
>
>> The placement of the adjective "Italian" is clearly English; An Italian
>> or French speaker would have written "Bistro Italiano" or "Bistrot Italien".
>>
>
> yes, it is an English adjective, something that is not completely uncommon
> for German and Italian business names though (it makes the place look more
> international).
>
>
>
>> So I would add "name:en=Spazio Italian Bistrot" and "brand=Spazio Italian
>> Bistrot" if there is more than one location.
>>
>
>
> I believe there is no doubt that "Spazio" is an italian noun, the word
> does not exist in either French, German or English. I would probably not
> add "Spazio Italian Bistrot" as an English name (at least not solely).
> Being in Germany and having a word used in German (Bistrot) as
> self-declaring feature-type I would rather see it as a German name with an
> anglicism in the name, or alternatively as an Italian name (Spazio and
> Bistrot are Italian). For me, this is a name and not a brand (may be
> additionally a brand, but it is clearly the name of the restaurant).
> The spelling "Bistrot" is used much more often in Italy and France than
> "Bistro", it is used sometimes in Germany and England and it is hardly ever
> used in the US and the rest of the UK (according to Google trends).
>
>
>
>>
>> For something like "IKEA" or "KFC", I would use "brand" as well:
>> https://wiki.openstreetmap.org/wiki/Key:brand
>>
>
>
> yes, clearly.
>
> 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] My "weirdly unnatural aversion to relations"

[Martin Koppenhoefer]

Am Di., 2. Okt. 2018 um 06:32 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> You are supposed to be able to get all that information by using a closed
> way for the boundary of the RV park. Then all the other features are
> contained within that boundary.
>



yes, and from my understanding, in these cases where the site can be
represented with a polygon, it would be better not to use a site relation
(but for many actual site relations it has been done anyway).

1. What the site relation promises to offer is adding things that are
outside a perimeter and are not polygons, to the site, i.e. nodes, linear
ways and other relations.

2. Or places, where a perimeter cannot be used, because not everything
inside it is part of the feature. You cannot "subtract" POI nodes from a
multipolygon relation (but you can not add them to a site relation).

3. It also possibly offers special roles for the members (this is the
parking for the staff of this feature, this is the ticket office for this
feature, this is the toilet for visitors of this place, ...). (But there
are no established semantical conventions how to do it).


As there is no support in osm-carto/mapnik since ever, which would probably
have channeled/unified actual usage, there are now a lot of things mapped
as site relations, that work differently. Everybody has dreamt her/his own
"jack of all trades relation" into the site relation, and quite a few of
them could be represented by a polygon without loosing semantics. That's
why I can partly agree that these relations are not "usable" (you can still
try o make some sense of them, and you will probably get more information
out of OSM if you do not ignore them).

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

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

[Martin Koppenhoefer]

Am Di., 2. Okt. 2018 um 07:00 Uhr schrieb Graeme Fitzpatrick <
graemefi...@gmail.com>:

> As a real common example, you have McDonalds all (or virtually) over the
> world, so how does the name appear on OSM maps in non-English speaking
> countries?
>


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

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

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

[Martin Koppenhoefer]

Am Di., 2. Okt. 2018 um 03:17 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> It's not always necessary or possible to interpret the language of a brand
> name.
>


+1



>
> But in this case I think we can say it's clearly an English brand name.
> "Spazio Italian Bistrot" isn't a real name, but a brand name, like KFC,
> IKEA, etc.
>


with the difference that it is just the name of a single restaurant in
Germany and not of a worldwide operating multinational company with
hundreds of shops.



> I suspect the less-common spelling of "Bistrot" is meant to make the brand
> more copyright-worthy
>


it is the prevailing spelling in French. Being a French word I would say it
is safe to assume that this part of the name is French.




> The placement of the adjective "Italian" is clearly English; An Italian or
> French speaker would have written "Bistro Italiano" or "Bistrot Italien".
>

yes, it is an English adjective, something that is not completely uncommon
for German and Italian business names though (it makes the place look more
international).



> So I would add "name:en=Spazio Italian Bistrot" and "brand=Spazio Italian
> Bistrot" if there is more than one location.
>


I believe there is no doubt that "Spazio" is an italian noun, the word does
not exist in either French, German or English. I would probably not add
"Spazio Italian Bistrot" as an English name (at least not solely). Being in
Germany and having a word used in German (Bistrot) as self-declaring
feature-type I would rather see it as a German name with an anglicism in
the name, or alternatively as an Italian name (Spazio and Bistrot are
Italian). For me, this is a name and not a brand (may be additionally a
brand, but it is clearly the name of the restaurant).
The spelling "Bistrot" is used much more often in Italy and France than
"Bistro", it is used sometimes in Germany and England and it is hardly ever
used in the US and the rest of the UK (according to Google trends).



>
> For something like "IKEA" or "KFC", I would use "brand" as well:
> https://wiki.openstreetmap.org/wiki/Key:brand
>


yes, clearly.

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

Re: [Tagging] Traffic sign direction tagging..

[Robert Skedgell]

On 01/10/18 22:23, yo paseopor wrote:
> Technically markings painted on the road are...traffic signs itself (in
> some countries there are specific codes to this items) and also they
> have their importance , you cannot ignore them

This is certainly the case in the UK. A highway=give_way is generally
indicated by the transverse line marking (= = = =) on the carriageway,
traffic_sign=GB:1003A. There is also the upright inverted red triangle
traffic_sign=GB:602, which does not need to be present. Failure to
comply with either is an offence.

-- 
Robert Skedgell (rskedgell)


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