Geometrie-Fehler bei Straßen-Multipolygonen?

Hallo,

ich stolpere aktuell über Geomtriefehler in meiner osm2pgsql-DB, die durch Straßen Multipolygone auftreten:

  • in Werne [1] verursachen die beiden inner-Objekte Hauptkirche und Sakristei das Problem, weil sie an mehr als nur einer Stelle verbunden sind

  • in Kuppenheim [2] sind es die inner-Objekte parallel verlaufend zur Grasfläche, also die jeweils 3 Gebäude (Turm - überdachter Gang - Turm), die in mehr als nur einer Stelle verbunden sind.

Diese Geometrien werden in Josm nicht als Fehler angegeben, sind es im OSM-Sinn Fehler und sollten sie korrigiert werden oder sollten sie so bleiben?

Wenn ändern: die einzige Idee, die ich hätte, wäre das ändern von eigenständigen building=yes Objekten zu building:part=yes und Erstellung einen neuen Objekts building=yes, das die Geometrien zusammenfasst, aber das wäre ja sinngemäß nicht das gleiche.

Halb off-topic: weiß jemand, warum die Geometrien sauber gerendert werden, ich verwende ja die normale mapnik render DB und ich erhalte GEOS-Fehler, wenn ich die Geometrien haben will.

viele Grüße Dietmar

[1] https://www.openstreetmap.org/relation/4445096
[2] https://www.openstreetmap.org/relation/387060

[1] Ist im OSM-Sinne kein Fehler sondern eine Warnung (touching inner rings)
[2] ditto

Eine zweite Möglichkeit ohne jede Änderung an den inneren Objekten:
Eine neue Linie für den inneren Rand des MP anlegen unter Benutzung der vorhandenen Punkte. Die Linie kann man dann als “inner” statt der aneinandergrenzenden mehreren “inner” verwenden. Mit “f” unterstützt josm sowas sehr gut. (“f”: neuen Punkt der neuen Linie wie in der schon vorhandenen Linie machen)

und beide Ideen zusammengefasst:
building=yes ==> building:part=yes (diese evtl. in eine Gebäuderelation als part)
neues Objekt um beide Gebäudeteile als building=yes (dieses evtl. in eine Gebäuderelation als outline)
das neue Gebäude dann als neuen inneren Ring ins MP, die alten inneren Ringe aus MP entfernen.

Hallo, in diesem Zusammenhang hätte ich zwei Fragen:

a) Dieses Multipolygongewusel ist doch nur notwendig,
weil Mapnick eine Fußgängerzone grundsätzlich ÜBER Gebäude rendert,
obwohl einem der gesunde Menschnverstand sagt, dass dies die suboptimale Reihenfolge ist, oder?

b) Wenn man sich dann multipolygonal bemüht es dem Mapnick recht zu machen,
welchen Sinn hat es dann eigentlich AUF einer derartigen Fußgängerzone (highway pedestrian) NOCHMALS
Fußwege (highway footway) zu zeichen, wie in Kuppenheim [2] geschehen und von mir auch schon andernorts gesehen?

a) Ja die Reihenfolge ist suboptimal, semantisch ist es allerdings richtig Hindernisse wie Kirchen aus der Fußgängergehfläche auszustanzen.

Denk mal nicht nur an Karten … wir haben eine Datenbank.

Wenn man die Größe der Fußgängerzone wissen will, dann muss die Fläche realistisch sein.

Wenn man in der Datenbank alle Flächen für ein Kinderkarussel sucht, dann müssen die Flächen realistisch sein.

usw. usw.

Wenn ichs richtig in Erinnerung hab, war der Gesunde Menschenverstand im Zwiespalt: Er wollte Strassenflächen über den Strassenlinien, weil es sonst Hässlichkeiten bei Anschlusspunkten gibt und bei Linien, die diese Flächen überqueren. Ausserdem wollte der Verstand, dass Strassen über Häusern liegen, weil die übernatürlich dick gezeichneten Strassen sonst gelegentlich unter den masstäblich dicken Häusern verschwinden.

Vermutlich gibts noch mehr Abhängigkeiten …

Nein, neuerdings eben UNTER, davor hat man die gesehen und das war nicht schön :wink:

Das machen die Leute wegen der Router, oder weil die Beschriftung dann hübscher entlang der Hauptverkehrslinie liegt, oder …

Grüße, Max

Vermutlich zum Routing, da Router im allgemeinen über Linien und nicht über Flächen routen (können).

Die Allgemeinheit weiß das ein Gebäude auf der Fußgängerfläche steht.
(Der See im Wald auf einer Wiese in einer Lichtung im Wald …)

Wenn auch die Render es so betrachten, ist das mappen “einfach” (ohne eine / mehrere Relation/en zu erstellen).

Wenn jemand die Waldfläche ausrechnen möchte, muss er die “inner” liegenden Flächen “abziehen”.

Warum schon in den einfachen Daten festlegen, was was ist.

Überall wird “Stadtgrün” eingefügt, weil es auch zum residential gehört. Warum dann eine Relation? Dann müssten auch die Häuser und Straßenflächen aus dem residential …

zu b, der Hinweis zu Routen über Flächen :wink:

Naja, Deine Prämisse ist aber, dass Du eine Bodenfläche und keine Deckenfläche ermitteln willst.
(Geh mal gedanklich in dein Badezimmer,
einmal willst Du Bodenfliesen verlegen,
ein anderes Mal die Decke streichen.
Welche Fläche ist “realistisch”?)

Und dein Kinderkarrusell-Beispiel: Straßen und Bäume innerhalb dessen Aufstellfläche scheinen in der osmanischen Fußgängerzone kein Problem zu sein,
denn diese werden durchaus auf die pedestrian-Fläche gerendert, resp. diese müssen - anders als Gebäude - nicht ausgeschnitten werden.

Da ich beruflich mit Mengenermittlungen zu tun habe (und die haltlosen IT-Versprechen kenne):
Wo und von wem werden denn OSM-Daten ernsthaft und inder Praxis zur Mengenermittlung eingesetzt?