Isn't this premature? Possibly it can work with planned:=**

What are the details of your Swisstopo and RegBL sources? This way somebody can contact them to correct it there as well.

Interesting addition. A description=* here is meant to be in French. As it's in another language, please add its language code (like description:en=* ). I couldn't load the url. Feel free to add a description in French too.

Thanks for the heads-up!

I got the impression we generally wouldn't have multiple relations with identical borders (admin_level=3 lacks TI and ZH) or I haven't encountered them in this area. It's possible that other websites (like the ones you mention) handle this differently or have a historic focus. I doubt there is another feature that could have this old_name.

From boundary=*#Boundary_types it looks like "place" is the better value for this key. I should change it to that.

so how's the beach this week? ;)

your cs is large

Doing 5 by country changesets is frequently a bad idea: at least when the bounding boxes end up overlapping anyways .. So neighbors just end up getting 5 cs and not 1.

Is it really redundant? There is also the Lullin site.

int_name=* = Schweiz ?

I'd remove this or change it to name:la

Question is answered in changeset/181729105

I'm ok with that.

default_language is mostly set in regions, but still needs work around CH-GR.

> As far as I can tell, @imagoiq is looking at data of cooperatives owning buildings, and updating these. They explained that several times already, and I think explained it well.

So can you summarize the sources for this changeset?

To solve this in your direction, I guess there several solutions:

- remove the tag entirely
- add multiple values as in name (so it aligns therewith). The wiki mentions that this isn't preferred, but used that way.
- align name with name:la
- define default_language for all subregions (so "la" is only applied where relevant).

> **"default_language=de" for the whole country is also questionable

That seems wrong to me. The agreed upon common country-name for Switzerland is in Latin. This is found everywhere in the country (check next time) and has been stable since the 19th century (see article).

It's possible that the linguistic compromise isn't the same in other countries. I read in Germany, it's illegal to edit maps in anything but "de".

Neither Latin nor German are commonly spoken ("loquitur" as you wrote) in the country, but this isn't relevant.

default_language=de might have lead to "de" poping up in odd places in Switzerland. Problems I started fixing.

> Latin is not used for place names, street names, or any other on-the-ground naming.

This isn't relevant either, as the tag will only apply to the country-level as cantons, districts, etc. have different defaults.

Samples:

for relation/1687730 it's "it",

for relation/1684782 it's "fr",

for relation/1686703 it's "de",

etc.

> “Always use just one language code per region”

I don't think the key ever had several values. You might be confusing it with other places. The value here shouldn't have any adverse effects. Is there something you think could go "clearly wrong"?

> Could you clarify what data consumer benefit you expect from setting "default_language=la"?

The default <language> allows users to select the name:<language> for the country (name:la that is), if they choose not to use the current value in "name" directly.

> What was the basis for this edit?
Add owner to a single feature instead of three just describes the edit it doesn't explain what it was based on. This could be a survey, gchg.ch .. etc.

> I honestly think that this issue is not solvable country-wide.
Seems obvious.

I got the same impression from @imagoiq .. even more so in the forum. Maybe I should report their conduct there.

The roof issue is relatively easy to do, but I haven't noticed imagoiq editing roofs, so it might as well be a rhetorical question, one I don't want to volunteer time for.

Oh, I see trivial issue. ID of the relation was applied to a node instead. (I sometimes do that too)

What's the connection between node/19630033/history/1 and version 2 of the node ?

Can you answer my questions?

The question appears to be irrelevant to that thread.

I note that you don't want to provide a clear answer about the basis for your edit.

Once answered, I will try.

I think for this changeset, we would still want a clear answer on the initial question.