Es war in der Relation nur einmal drinnen, das zweite Mal war in der relation/9933213.

Gebäude werden ohnehin drübergerendert, so wie es aussieht. Strenggenommen gehören sie aber nicht zum Wald. Also läßt sich darüber wohl diskutieren. (Bei den großen Wienerwaldmultipolygonen lohnt es sich wahrscheinlich nicht, jedes Gebäude als inner einzutragen, wenn es nicht eh schon gemacht ist.) Nur, die ganzen Nebengebäude aus dem Wald rauszuschneiden und das Hauptgebäude nicht, wäre ziemlich inkonsistent.

Deine zweite Frage verstehe ich nicht ganz. Meinst du die Perschling direkt südlich vom Schloß? Die ist durchgegend als Way gemappt, und in dem Bereich, in dem das Flußbett breiter ist, zusätzlich als Area. Das sieht mir OK aus. Und das abrupte Ende der Verbreiterung im Westen ist auch normal, da ist ein Wehr, das auch als solches gemappt ist. Die Area ist also im Grunde ein kleiner schmaler Stausee.

Warum hast du das Schloss als inner aus der Relation herausgenommen? Das hat schon gepasst, das Problem war die relation/9933213.

Ich habe diesen Edit rückgängig gemacht: changeset/73577815

Multipolygon 9933214 war an sich bereits gültig, aber es gab noch ein zweites Multipolygon 9933213 für denselben kleinen Wald, wo weniger inners eingetragen waren. Das ist besonders fies, weil das der OSMI (OSM Inspector – https://tools.geofabrik.de/osmi/ ) auch nicht erkennen kann, im Gegensatz zu den Self-Intersections. Ich habe Multipolygon 9933213 jetzt gelöscht: changeset/73577424

Ich habe auch einen Kommentar unter changeset/73473525 geschrieben, wo der Fehler in Multipolygon 9938221 herkam.

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.