What's the name on street signs? GWR is known to include problematic data, like "official names" that are not used locally.

"subarea" was the correct role for most relations. Of the member members only way/1214963541 is a way, so this results in showing the area of Lepontine Alps=Swiss Alps . Beyond reverting this changeset, I'm not sure how to fix this completely.

The street directory seems to be the layer "ch.swisstopo.amtliches-strassenverzeichnis". The OSM tag for the record would be ref:ESID=* =10261270.

If you find a RegBL entry (layer "ch.bfs.gebaeude_wohnungs_register"), please quote the ref:EGID=* or a building entry reference (Not sure if we have a tag for that yet).

Thanks, a good point. Your experience is helpful.

I try to add existing stations to relations, but I don’t always finish every step in one pass. Based on the 2009 model, common tasks fixing stations are:

1. Create missing station nodes

2. Add those nodes to the appropriate relation. Some stations are present, but hard to find given a lack of tags.

3. Set each member’s role to "station" in the relation

4. Fix typos/spelling in names (e.g., “Parcours”)

5. Convert stations mapped as part of a way into standalone nodes where appropriate

6. Ensure basic tags exist (at minimum ref= for the station number)

7. Add a complete, consistent tag set per current tagging guidance

My current practice: I place a fixme when nodes or relation membership are missing, and I typically resolve items 2–4 during follow-up edits.

For everyone who wants to pitch in, here are small, concrete ways to help (no deep knowledge required):

- Create a node for a missing station and add ref=

- Add existing station nodes to the correct relation and set role=station

- Split a station out of a way into a node when appropriate

- Correct names (fix “Parcours”) and add basic tags osm.wiki/Tag:(ref=, etc)

- If unsure, leave a short changeset comment or a fixme tag describing what’s left

If a whole parcours is missing, a good first contribution is a node at the approximate start plus a relation for the parcours.

Tools:

- Overpass examples: network=Vitaparcours if some stations aren’t found with that, please mention them or add them directly to relations. The larger clusters of nodes that only have a name, but aren't marked as fitness_station should be done. https://overpass-turbo.eu/s/2raU focuses on easier ones.

If you’re willing to coordinate: reply with an area or relation id you’re working on and I’ll prioritize that in my next pass.

If useful for newer contributors, I can also paste a minimal tag set to use.

When you have a moment, could you kindly compile a summary of your 'daily' maintenance routine on osm.wiki ? I understand that these routes are generally considered to have limited utility and may introduce technical challenges due to the addition of numerous ways to relations.

In the summary, please include details on the following:

- Objective: What does this routine achieve, and what are its limitations?

- Route coverage: Which Flixbus routes are included, and which are excluded? Are all routes still active, and what happens to routes that are currently not in service?

- Significance of ways: Are the included ways meaningful, or are they merely potential routes between endpoints?

- Types of checks conducted: What specific checks do you perform as part of this routine?

- Support from Flixbus: How is this routine supported by Flixbus, if at all?

- Data verification: Is there a method to cross-verify this data with other sources, such as the Flixbus schedule?

This shows a record from the street directory. With "swisstopo" I guess you mean the website. Any "RegBL" entry you found connected to this?

I added the lifecycle-prefix.

Please share the details of the error you found at Swisstopo and RegBL so that it can be corrected there as well.

Please consider osm.wiki/Changeset#Geographical_size_of_changesets

If it's difficult by country, try to do a changeset by hemisphere. For local features, like Osmose fixes, by city seems reasonable.

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.