Bei T-förmigen Schnittpunkten bitte den Schnittpunkt immer in BEIDE Polygone eintragen, auch in das, das geradeaus weitergeht. Sonst schneiden bzw. überschneiden sich die Polygone in der Regel, was besonders die Multipolygon-Algorithmen verwirrt (wenn beide betroffenen Polygone als "inner" in einem Multipolygon sind). Das führt dann meistens dazu, daß das GESAMTE Multipolygon im Rendering unsichtbar wird. In diesem Fall betroffen war das Multipolygon 9938221 im Punkt 6720010778. Es wurde bereits von teschlg ausgebessert, siehe: changeset/73572196

In diesem Fall war zum Glück nur ein kleines Multipolygon betroffen, aber dadurch können mitunter ganze Wälder verschwinden (vgl. die Diskussion unter changeset/73470419 ).

Ja, genau so geht es richtig, danke. :-)

Überprüfen kannst du es übrigens, leider mit mehreren Stunden Zeitverzögerung, mit dem OSMI-Validator:
https://tools.geofabrik.de/osmi/?view=areas&lon=16.12422&lat=48.17264&zoom=10

Besonders böse sind die roten Self-Intersections, die verwirren die Algorithmen meiner Erfahrung nach am Meisten. Derzeit haben wir übrigens eine in einem kleinen Multipolygon im Tullnerfeld (9938221), das dürfte wieder die T-Schnittpunkt-Problematik (siehe meinen vorigen Kommentar) sein.

Genau. Aufpassen mußt du übrigens auch, wenn du bestehende Polygone als inner hinzufügst, daß sie sich nicht mit den anderen inners überschneiden. Es genügt leider bereits, daß ein T-Schnittpunkt nur in einem Polygon als Ecke drinnen ist und im anderen (das an der Stelle gerade weitergeht) vergessen wurde, um den Algorithmus zu verwirren. (Siehe auch mein Changeset hier, da habe ich meine neuen 2 Punkte zu BEIDEN Polygonen hinzugefügt.) So etwas habe ich auch unlängst ausgebessert, da waren die Schnittpunkte von einem anderen Mapper vergessen worden, was so lange niemandem aufgefallen ist, bis du das Polygon als inner in den Wald eingetragen hast. Die Multipolygon-Algorithmen sind leider alles andere als Mapper-freundlich.

Hallo,
kannst du bitte, wenn du ein riesiges Multipolygon wie hier Relation 4625 änderst, darauf achten, daß das Resultat auch gültig ist? In diesem Changeset hat sich way/715147176 mit einem bestehenden inner im Multipolygon überschnitten, was leider nicht nur dem OSMI-Validator, sondern auch dem Mapnik-Renderer mißfällt. Dadurch verschwindet jedes Mal der ganze Wald von der Landkarte, und auch, wenn ich es ausbessere (vgl. changeset/73558250), dauert es immer Tage, bis alle Tiles neu gerendert wurden und den Wald wieder zeigen. Und leider ist es nicht das erste Mal, daß ich nach deinen Edits dieses Multipolygon ausbessern mußte.

Das mit dem verschwundenen building=yes Tag war anscheinend ein Bug in iD 2.15.1, der inzwischen (iD 2.15.2) behoben ist:
osm.wiki/ID/Controversial_Decisions#building.3D.2A_removed_by_validation_rules

Also sollte es in Zukunft hoffentlich nicht mehr passieren. (Wie gesagt, für das Forstamt habe ich es eh schon ausgebessert.)

Hallo,

beim (Wiener) Forstamt (way/123933517) hast du den building=yes Tag ersatzlos gelöscht. Damit weiß keine Software (auch nicht der Default-Mapnik-Renderer), daß das ein Gebäude ist, office=* reicht dafür leider nicht aus. War das ein Versehen? Ich habe jetzt building=office gesetzt. Bitte schaue in Zukunft besser darauf, nicht versehentlich ein Gebäude ohne building=* Tag da stehen zu lassen.

Sorry, but this changeset cannot possibly make sense. This house is on the even-numbered side of the street, so it cannot have house number 15. According to the OGD, this is number 16, which is what was tagged before your edit and what fits in the number sequence. Therefore, I reverted your change, see: changeset/66319512 – sorry!

Sorry, this cannot be right:

* On the Facebook site of Restaurant Bombay, not only is there no mention of it being closed, but there is a post: https://www.facebook.com/157567080971854/photos/a.1292882920773592.1073741828.157567080971854/1672967206098493/?type=3 which is more recent than your change and which contradicts it.

* There are several reviews for Restaurant Bombay on Facebook, Google and TripAdvisor that are also more recent than your edit.

* The Schilling website that you linked to also knows nothing about a restaurant at this address. Both the website and the phone number that you gave are for the Burggasse 103 (corner with Halbgasse) location.

Therefore, I had to revert your change:
changeset/57521386

Also, wenn das wirklich vor Ort wo angeschrieben steht, wie in der Note angegeben, dann wird es wohl so stimmen. Der Stadtplan der Stadt Wien selbst kennt die Bezeichnung allerdings nicht, da steht alles nur als "Stadtpark", ebenso in den OGD und auf basemap.at.

Hallo Stefan,

Was bitte ist die offizielle Quelle und/oder das Hinweiszeichen vor Ort für den Namen "Stadtpark-Kinderpark"? Soweit ich weiß, ist das Ganze der Stadtpark und sollte als ein gemeinsames Polygon oder notfalls ein Multipolygon gemappt sein.

Liebe Grüße,
Kevin

For the "Sankt" issue, the consensus on the talk-at mailing list was actually to use "Sankt" if the official name says "Sankt" and to use "St." if the official name says "St.". In this case, the official name for the suburbs is given by the City of Vienna, the official name for the public transport stops is given by the city-owned public transport company Wiener Linien. Both use "St.", so that spelling should also be followed here.

This is a case where the mapping practice, at least locally in Vienna, differs from what the wiki says. I'm not sure how to best deal with this. I have seen many POIs with repeated addresses and I usually also tag them that way. One reason to do that is that houses in Vienna often have more than one house number, so it is not always obvious which of the addresses actually applies to the POI. In those cases, the building is mapped without a house number, then every entrance is tagged with its address (which can apply to more than just the POI, e.g., there can be apartments above it), and then every POI in the building (there can be several) is tagged with repeated address, somewhere behind the entrance.

That said, in this case, where the address is on the building and the POI is within the building polygon, it is probably less important to repeat the address. I would probably not have complained if you had tagged the POI without an address, but it was removing the address on the existing POI that I was unhappy with.

Uh, it is common practice to tag the address on a shop POI in addition to tagging it on the building, the idea being that tagging it on the building identifies the building and gets the address drawn on the map, but tagging it on the POI is part of the contact information of the POI. It is unfortunate that both those practices use the same tag namespace because they really serve different purposes. However, I consider it unhelpful to remove the address on the POI.

Tut mir leid, aber, daß da auf einmal 7 Häuser abgerissen wurden und ein neuer Park errichtet (direkt neben dem bestehenden Wielandpark), ohne, daß der angebliche Name (Herndlpark) auch nur an einer einzigen Stelle im Internet auftaucht (Google hat nichts gefunden!), und obwohl der Flächenwidmungs- und Bebauungsplan der Stadt Wien (vgl. wien.at OGD) diese Flächen für Gebäude vorsieht, das kann ich dir leider nicht glauben.

Ich mußte diese Bearbeitung daher leider umkehren (reverten), vgl. Änderungssatz 54288799.

Bitte mißbrauche die OpenStreetMap nicht als Spielwiese.

Tut mir leid, aber, daß da auf einmal 7 Häuser abgerissen wurden und ein neuer Park errichtet (direkt neben dem bestehenden Wielandpark), ohne, daß der angebliche Name (Herndlpark) auch nur an einer einzigen Stelle im Internet auftaucht (Google hat nichts gefunden!), und obwohl der Flächenwidmungs- und Bebauungsplan der Stadt Wien (vgl. wien.at OGD) diese Flächen für Gebäude vorsieht, das kann ich dir leider nicht glauben.

Ich mußte diese Bearbeitung daher leider umkehren (reverten), vgl. Änderungssatz 54288799.

Bitte mißbrauche die OpenStreetMap nicht als Spielwiese.

Even the official map of the city of Vienna: https://www.wien.gv.at/stadtplan/ still uses the spelling with spaces, and also the ones with 'ß' that you changed. I think all these changes should be reverted, unless you actually see the changed spellings on relevant street signs, public transport stop names, etc. (And especially the name= tag on the public transport stop name should match how the stop is actually spelled on the signs, in the schedules, etc.)

See e.g. http://www.wienerlinien.at/itip/ – just look for the stops you edited, they all use the original spelling, not the one you changed it to.

Die Wiener Linien verwenden aber in allen ihren Dokumenten und auf den Stationsschildern (sofern sie nicht in Blockbuchstaben sind) nach wie vor die Schreibweisen mit 'ß'. Daher halte ich die Änderungen an den Haltestellennamen für schlicht falsch.

But the Wiener Linien themselves still use the spelling with 'ß' in all their documents and even on the signs on the stations or stops themselves (unless they are in all caps). Therefore, I consider the edits to the stop names to be just plain incorrect.

Also zum Einen hat ein name= unter Hochkommata überhaupt keinen Sinn. WENN das wirklich der umgangssprachlich gebräuchliche Name (oder zumindest ein gebräuchlicher Name) WÄRE, dann wäre loc_name=Peter-Paul-Berg die richtige Art, das zu taggen. (Damit würde der Name jedenfalls von Nominatim gefunden werden.)

Zum Anderen sehe ich aber immer noch keinen befriedigenden Nachweis für die Behauptung, "die Wiener" würden diesen Gipfel unter dem behaupteten Namen kennen. Ich würde mich jedenfalls als Wiener bezeichnen (lebe praktisch seit meiner Geburt vor bald 34 Jahren hier in Wien) und habe außerhalb von OSM noch nie von einem "Peter-Paul-Berg" gehört. Auch im Internet lassen sich die wenigen Quellen mit hoher Wahrscheinlichkeit auf den einige Zeit lange bestehenden OSM-Eintrag zurückführen.

Die Tatsache, daß du unter dem Benutzer "Fotoalben" genau diesen einen Edit hast, läßt mich jedenfalls stark vermuten, daß es sich hierbei um eine Tarnidentität (realistischerweise von "peterpp") handelt.

Der name=-Tag sollte entweder Handleinsberg bleiben oder ganz entfernt werden.