I'm sorry you feel that way.

Please avoid blindly repeating to others what you may have heard about your own approach.

If you lecture people about rules, you should know why you do so.

@GartenStuhl: it's a way Taktaal made their argument (indeed unrelated to my original response) and re-reading it, you are right, what they wrote could be understood as yes. So we can close that point.

To your other point: I don't let AI answer on my behalf. Also, this was not an "automated edit". Both accusations should not be repeated. Can we hear if there was any issue with the content of my original response? If don't want to participate fixing these relations, maybe you are just in the wrong CS.

The edit wasn't automated, but maybe it falls in an OSM category of "automated edits". I will check.

On the side note: I'm still curious: Are you frequently being told that you are rude?

It would be helpful for myself and other readers if you made a substantive argument about this discussion. Are there points in my initial response that you find are not clear? Please do use spellchecker and AI if you can't make it without. I added the list of fixes for stations to osm.wiki/Switzerland/Parcoursvita#Fixes_for_stations . Please help improve it.

@Taktaal: This seems to be unrelated to this changeset or its discussion. Is there anything of substance you want to say about this changeset or its discussion? On a side node: are you frequently being told that you are rude?

For osm.wiki/Tag:name=, the question is how it's actually spelled on the ground.

How it must be spelled in Quebec or Paris doesn't matter. OSMOSE's spelling checks in Geneva are generally problematic, or by its own terminology just "bad". I don't think you should adopt OSMOSE's wording when commenting on other mappers.

I will try to find my survey and update it if needed.

It seems it's the spelling used by the hotel on its website.

You just added a misspelling.

Please be carefully when going through Osmose's "Badly written word". I think its spelling is really bad.

1) House numbers in Geneva tend to be for specific entrances rather than buildings. At this location, the buildings might not even be separately mapped. Worse, some mappers merge them ;)

3) Those databases would show compulsory registration. Some services can be provided without, at least when below a threshold. This type might fall in that category.

2) For businesses, I'd expect at least a name on a mailbox, especially given (3) above. Maybe "Centre Aliotis" is what could be mapped.

With (3.), I was trying to say that I don't think https://www.flixbus.de/track shows the actual route. You could check it by searching for street segments in your area that have temporary restrictions or recent constructional changes.

For (6.), I'd add the description="The start, end, and stop locations have not been verified. This route may be out of service for an extended period and may not match the actual route."

For (7.), it might make sense to handle the ones you follow in detail differently from others. I had contacted the mapper who created some around Geneva. Apparently, he hadn't been maintained them since Covid. In general, OSM seems to prefer not to include historic bus routes.

Not really convinced. I see three issues:

1) It re-uses the node for the address of the building, building with has multiple tenants. If the POI is to be created, it should be separate.

2) It's unclear if the business has a physical presence at the location. A survey didn't find it.

3) It's unclear if the business actually exists (it's not in online databases I checked).

For discussion of Flixbus relation updates: changeset/184128628

@adamos: thanks for the detailed response.

1. What supports "The ways included in the relations represent the actual [...] route the bus takes on public roads"? Is this based solely on what appears most logical on OSM?

2. How do you verify "official Flixbus route (when known)"?

3. I checked routes around Geneva on https://www.flixbus.de/track and some of the streets shown aren't even open for traffic. Perhaps route quality is better in your primary mapping area.

4. In a forum discussion, a mapper observed that his driver used his GPS and did not follow what's on our map.

5. Also, I made a similar observation as @aceman444: stops might no longer be at existing locations even when the route remains active.

6. To clarify data quality for users, we could add a note or description to the relations, for example:

"Start, end and stop locations have not been verified; this route may be out of service and does not necessarily reflect the actual path to be taken."

I can draft a standard note we can reuse.

7. The area you are mapping in detail is that limited to the Czech Republic?

There may be a technical issue with your script: The changeset remains open after the edit. Please make sure it tries to close it.

Further, please find below a revised questionnaire about the 'daily' maintenance routine. Previous version was at changeset/183679206

When you have a moment, could you kindly compile a summary on osm.wiki ? If you can't answer some questions, you can just note that.

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

- Countries covered: Which countries should this cover?

- Route coverage: Is the coverage clearly defined? 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? If several are possible, does it just pick one randomly?

- Alternative modeling: If the ways are not actual routes, what alternatives have been considered instead?

- Types of checks conducted: What specific checks do you (or the program) 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?

- Timing: How frequently is this "daily" routine running? Is it running/updating autonomously?

Given the understanding that these routes are generally considered to have limited utility and may introduce technical challenges due to the addition of numerous ways to relations, a answers to the above can clarify things.

What arguments are there in favor of "Zürcherstrasse" (other than people searching it might type it that way)?

C'est un peu vieux comme changeset.

D'après obstacle=*#General_use on mettrait aujourd'hui obstacle=yes à moins d'indiquer la nature de l'obstacle.

@d_berger so why do you convert from way to node?

Who is "we" in your comment? It appears that local editors disagree with you.

I think so. The above Overpass request doesn't find anything and the following lists just a few by somebody else: https://overpass-turbo.eu/s/2rwf

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