Is it a bug in a tool you are using? There seem to be many more since: way/1117198988/history/3

This street name likely originates from the Swisstopo's (or is it OFAS') street directory (with ESID). Entries from ESID are often replicated in other sources (map.geo.admin.ch, GWR, qa.poole.ch, etc.). ESID can include several entries for the same street, without them being the official or actually signed locally. If the name is the official name, it should be tagged as official_name on the street feature. Being tagged official_name does not make it ground truth for OSM.

For buildings, different tools may match their addr:street to nearby streets in different ways. A fix that resolves one tool's matching may create mismatches in another.

Nominatim primarily uses name or alt_name. Osmose checks a defined set of tags. qa.poole.ch appears to prioritize the name tag. An advantage of aligning with Nominatim or Osmose is that both accept feedback and periodically update their matching algorithms. Osmose supports marking false positives. Nominatim is important because OSM's default search uses it.

Recommendation: Avoid changing names solely to satisfy a single validation tool.

check relation/20172352/history/9

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.