Die Änderung in der Maroltingergasse mit "highway=secondary" auf way/228799257 wird von OSMI zu recht als Fehler angemeckert. Siehe

http://tools.geofabrik.de/osmi/?view=routing&lon=16.30468&lat=48.20871&zoom=18&overlays=unconnected_major1,unconnected_major2,unconnected_major5,duplicate_ways

Der Verlauf der Busroute ist aus Sicht eines Auto Routers nicht sinnvoll, weil die tertiary Strasse auf dem tramway Gleis weiterführt und der higway plötzlich ohne Verbindung dort quasi im Nichts endet.

Ich durchschaue Deine Intentionen mit den überfrachteten PV Relationen nicht, deshalb habe ich keine Idee wie das Problem am besten zu lösen ist. Ich hoffe Du hast eine Idee. Das einfachste wäre wohl das highway tag zus den Wegen zu löschen, aber eigentlich finde ich die ganzen separat gemappten Gleise schrecklich. Hier werde mich aber nicht in die Wiener Angelegenheiten einmischen, ich kenne Edit Wars dazu aus der Vergangenheit.

Nachdem das die erste Änderung eines neuen Benutzer war, gehe ich davon aus, dass maxi321 hier herumexperimentiert hat.

Wir wollen Dich maxi321 nicht gleich wieder vertreiben. Falls es die Absicht dieser Änderung war den Namen auf dem kleinen Stück auf Salzburger Strasse zu ändern, dann nenne uns bitte Deine Quelle dafür und wir werden Deine fehlerhaft Änderung entsprechend verbessern, sodass Du danach nachsehen kannst wie so etwas besser gemacht wird.

Mir scheint, dass diese Änderungen und die Änderungen in 30845724 unabsichtlich hochgeladen worden sind. Oder sind nun wirklich all die eingetragen Fussgängerzonen nun durch lauter namenloser Hauptstrassen plattgemacht worden?

Thank you!

No I'm not sure, therefore I added fixme=yes. On Bing it looks as Linnankatu continues to an underground parking. If you have lokal knowledge please check node/429907226, if this can be marked as noextit=yes in case that may guess with the underground parking is not valid. It is unlikely that the way just ends there. What should vehicles do there? Turn around?

It looks you don't want to understand: Please stop uploading of whole GPS tracks! I already explained you politely the reasons in changeset/30065747. If you continue messing up the data, I'll need to ask the data working group to block your account.

In the meantime I have fixed the indicated errors. I would ask you to take a look onto osm.wiki/Relation:route for the purpose of a route relation. From your description I guess that you haven't yet fully understood the purpose of it. A route relation with just one element usually doesn't make much sense and if the new track overlaps with existing way segments then the is bad editing.
Please take a look onto relation/2766147 for an example how a route relation is supposed to look like usually.

By the way, the waymarkedtrails tool is able to assemble the invidual way segments of a route relation with many elements into one GPX file. Thats actually the main purpose of this tool as far as I understood.

Please refer to osm.wiki/OSM_Inspector/Views/Routing?setlang=en for a description about the purpose of the OSMI routing view.

I was able to reproduce your observation about the missing JOSM upload validation warning. Thank you for reporting. I'm quite sure that this has worked in previous JOSM versions. JOSM also does provide the respective validation check (it is called "crossing way" check), but due to some JOSM bug it doesn't work for the upload check. It works in case that you select the surrounding data and inititiate the JOSM validation manually. I plan to file a JOSM track bug report about your finding tomorrow.

Ist die Eintragung des Spitals in diesem Cnangset in Wien mit Absicht gemacht worden? Es sieht eher nach einem "Unfall" aus, weil ich mir nicht vorstellen kann, dass im Haus der Aphoteke auch ein ganzes Spital untergebracht ist.

You seem to be directly loading GPX hiking data into the OSM database. This results in a lots of OSM data errors, because you created a lot over overlapping ways without connections to the rest of the map.
Such data errors are displayed by the Open Streetmap Inspector tool and via this tool I detected your bogus edits: http://tools.geofabrik.de/osmi/?view=routing&lon=13.98541&lat=47.62452&zoom=8&overlays=unconnected_major1,unconnected_major2,unconnected_major5,duplicate_ways,islands

The correct way of mapping GPX data is to use the GPS traces as background only and draw the individual missing way segments. Usually a lot of the way segments already exist. In case that you are creating a relation you can put all the segments of your route into the relation. I would ask you to rework the edits you made recently and don't uploadunmodified GPS traces again.

Beim Editieren dieser Autobahn dürfte irgendwas ziemlich schief gegangen sein. Bitte überprüfe das Ganze noch einmal. Es kann nicht sein, dass eine Autobahn aus dem nirgendwo beginnt und plötzlich endet, außerdem ist dort laut bing Luftbild überall Wald. Danke!

Der Jagasteig track sieht sehr seltsam aus. Wenn man nach den geoimage und bing Luftbildern, dann kann es den Weg so kaum geben. Was ist Deine Quelle dafür? Warum ist der Weg nicht mit dem Rest verbunden? Danke!

Hello Intemelio,

For routing applications it is important that nodes at crossings are
identical and not just close to each other. Therefore I'm repairing
mapping errors detected by the Open Streetmap Inspector based on Bing or
other satellite images, see
osm.wiki/OSM_Inspector/Views/Routing. From the
changeset I see that it must have been an unconnected node. I remember
the strange layer*, but I didn't touch this. I saw that you fixed this
in the meantime.

Wieso verpasst Du dem Weg 113385744 den Namen "Landesstraße", wenn Du selber sagst, dass es eine namenlose Landesstraße ist? Ich würde Dich bitten das selber auszubessern. Wenn ich den ganzen Changeset revertiere, dann geht auch die "Hauptstraßen" Änderung mit verloren. Diese schaut ja plausibel aus.

This change looks very suspicous. You seem to be a new user. Do you mind if I revert your change? I can't believe that they moved the primary road into the sea.

Ich bezweifle die Richtigkeit der gemachten Änderungen sehr. Bing ist keine Quelle für einen Strassennamen "Landstrasse", viehlmehr dürfte es ein unbeholfenem Versuch einer redundaten Qulifizierung gewesen zu sein, die OSM üblicherweise mittels highway tag vornimmt. Bitte nenne mir daher deine Qelle, andernfalls werde ich deine Änderungen revertieren.

This is impractial. Connecting two nodes is a matter of 1 second, writing the comments would take at least 40 seconds. If you are working on such granuarity, then congratulations from me, but I won't do that.

I don't do this because it spams the displayed amount of changset if one fixes bugs in small areas with many problems. This is the usual case. Every single upload would generate a small changeset, all containing the same comment. My experience is that it is good to perform multiple uploads and not just one big one in order to reduce the probability of getting a conflict in case that somebody else is fixing concurrently.

I slowly increased my action radius and obviously went too far, as I nearly synchrounously got a similar comment for changeset

changeset/28799534

Please look up my answer there.

Yes. OSMI is exactly the tool for which you provided the documentation link above.

The wiki already explains what I'm doing and also includes an answer to your question about deletions in the changes-sets. This is what the wiki says about deletion. It is located in the "What you can do with this view to improve OSM data" section there and says: "Go through the duplicate ways and fix those cases. Sometimes whole ways overlap, sometimes only parts. Look at the tags of both ways, consolidate them and then remove one of the ways."

Here is one example, which is not yet fixed:

Way

way/178257938
was there first. Then user mcheckimport created an overlapping duplicate with tags for a cycleway:

way/275193195

This is a very frequent obvious error.

One possibility to fix it, would be to create a relation for the cycleway, put the first way (ID=178257938) into this new relation and delete the way with way ID 275193195. By doing so also every duplicated node gets deleted.

Deletion of nodes also automatically happens in case that one merges two close nodes, which were not properly connected.

My changesets cover such a big areas now, because the most prominent errors classified as "Unconnected major<1m distance" are getting rare and if I fix some of those, the whole changeset gets visible in a big area. I can't do anything about this. It is an issue of the OSM changeset view as it does not show only the changes within the active bounding box, but rather within the bounding box of the changeset.

If I don't forget I'll try to commit and comment those “Unconnected major” fixes separately in the future. These changesets will still cover a big area, but contain fewer changes.

I hope that this answers your concerns.

Hello,

thanks that you noticed this. I have an idea how and why this happened:
I believe that it was triggered by concurrent fixing the change
triggered by user nickel715 in version 6 and OSMI fixing done by user
"kartler175" uploaded with version 7 at 26.1 at 19:06 and my my OSMI
triggered deletion with version 8 uploaded at 26.1 19:53. I remember
that I got a "conflict" dialog and obviously was not able to manage the
conflict solving corretly.

I reverted the deletion. The object history is remained.