Moin,
inzwischen habe ich mal ein wenig mit einer aktuellen JOSM-Version mit
ein paar Multipolygonen rumgespielt. In der Erweiterten Version ist das
doch ein ziemlich maechtiges Werkzeug, mit dem man doch die
verschiedensden Flaechen konstruieren kann. Allerdings bin ich noch
nicht so davon
On Thu, 22 Jan 2009, Martin Koppenhoefer wrote:
Du musst mappaint.multipolygon auf true setzen oder eine ganz aktuelle
Version nehmen. Da es ein neues Feature ist, ist wohl letztes besser,
aber das aktuelle JOSM ist leider für die stable Variante noch nicht
stable genug. Andererseits ist sie
Am 23. Januar 2009 09:03 schrieb Dirk Stöcker openstreet...@dstoecker.de:
On Thu, 22 Jan 2009, Martin Koppenhoefer wrote:
Du musst mappaint.multipolygon auf true setzen oder eine ganz aktuelle
Version nehmen. Da es ein neues Feature ist, ist wohl letztes besser, aber
das aktuelle JOSM ist
Dirk Stöcker schrieb:
JOSM kann mit den Multipolygonen mittlerweile umgehen und so kompliziert
ist das nicht.
Naja, kompliziert ist relativ. Ich will versuchen, da noch mal ein
bisschen mehr Klarheit rein zu bringen.
Duerfen die inner-Polygone sich gegenseitig schneiden? Duerfen sie die
Hallo,
Torsten Leistikow schrieb:
Nochmal zu dem Beispiel, was ich neulich angesprochen habe (Ein Wald mit
See, an dessem Rand es einen Strand gibt). Um das zu verdeutlichen,
habe ich mal eine kleine Grafik ins Wiki gestellt:
http://wiki.openstreetmap.org/wiki/Image:Multipolygon_Example.png
Torsten Leistikow schrieb:
Nochmal zu dem Beispiel, was ich neulich angesprochen habe (Ein Wald mit
See, an dessem Rand es einen Strand gibt). Um das zu verdeutlichen,
habe ich mal eine kleine Grafik ins Wiki gestellt:
http://wiki.openstreetmap.org/wiki/Image:Multipolygon_Example.png
On Thu, 22 Jan 2009, Torsten Leistikow wrote:
Duerfen die inner-Polygone sich gegenseitig schneiden? Duerfen sie die
outer-Polygone schneiden?
Nein. Das wäre ein Fehler. Wenn die Polygone sich schneiden, dann ist
die Geometrie falsch und muss korrigiert werden. Bei einer ebenen Fläche
können
Du musst mappaint.multipolygon auf true setzen oder eine ganz aktuelle
Version nehmen. Da es ein neues Feature ist, ist wohl letztes besser, aber
das aktuelle JOSM ist leider für die stable Variante noch nicht stable
genug. Andererseits ist sie Dank Ulf viel schneller als die Vorgänger. :-)
On Mon, 19 Jan 2009, Torsten Leistikow wrote:
Solange man sich auf die einfachsten Faelle beschraenkt, bleibt der
Algorithmus auch noch einfach. Sobald da aber mehr als zwei Mitglieder
zugehoeren, wird die Sache doch schnell unuebersichtlich (siehe oben).
JOSM kann mit den Multipolygonen
On Mon, 19 Jan 2009, Bernd Wurst wrote:
ja, am besten waere wohl ein preprocessing, das erkennt, welche Flaeche von
welcher umschlossen ist, und das dafuer sorgt, dass zuerst die groessere
(untere/aeussere) Flaeche gerendert wird und darueber die
kleinere/eingeschlossene. Das man damit keine
solange Du nicht anfängst, Multipolygon-Objekte anderer von Hand nach
Deinem System zu zergliedern, kannst Du gerne damit weitermachen, ich
vermute allerdings, sobald die Editoren das Ganze intuitiver behandeln
und problemlos darstellen, wirst Du auch dazu übergehen. Stell Dir
vor,
2009/1/19 Holger Issle hol...@issle.de:
Erkläre das mal Garmin, daß die Überlagerungen perfekt beherrschen
müssen. Das ist nicht mehr _grenz_debil. Insofern passt der Name fast
perfekt.
Komisch, eigentlich sende ich den vollen Namen mit. Naja.
Ich glaube nicht, daß wir hier Garmin etwas
Am 19. Januar 2009 10:01 schrieb Martin Simon grenzde...@gmail.com:
2009/1/19 Holger Issle hol...@issle.de:
Erkläre das mal Garmin, daß die Überlagerungen perfekt beherrschen
müssen. Das ist nicht mehr _grenz_debil. Insofern passt der Name fast
perfekt.
Komisch, eigentlich sende ich den
Martin Simon schrieb:
Es wird nichts überlagert. es gibt verschiedene Umrisse(ways), die
sich gegenseitig abgrenzen und dadurch Flächen bilden.
Der Zusammenhang wird mit simplen tags in einer simplen Relation dokumentiert.
Nehmen wir mal als Beispiel eine Waldflaeche, die vollkommen einen See
Am 19. Januar 2009 17:23 schrieb Torsten Leistikow de_m...@gmx.de:
Martin Simon schrieb:
Es wird nichts überlagert. es gibt verschiedene Umrisse(ways), die
sich gegenseitig abgrenzen und dadurch Flächen bilden.
Der Zusammenhang wird mit simplen tags in einer simplen Relation
dokumentiert.
Hallo.
Am Montag, 19. Januar 2009 schrieb Torsten Leistikow:
Mein Konzept sieht folgendes vor:
[...]
Das kommt stark drauf an ob man ein geschlossenes Polygon also einen Weg mit
Ende == Anfang immer als Fläche bezeichnet oder ob man das erstmal nur als
Daten-Objekt sieht.
Eine Straße wird
Das einfachste für dumme Renderer die keinen Multipolygon-Support
bekommen
sollen wäre wohl, einen Algorithmus auszudenken wie man
Multipolygon-Realtionen in dein Konzept transformieren kann. Das sollte
nämlich gar nicht so schwer sein und könnte mit in die Vorverarbeitung
integriert
Hallo.
Am Montag, 19. Januar 2009 schrieb Martin Koppenhoefer:
ja, am besten waere wohl ein preprocessing, das erkennt, welche Flaeche von
welcher umschlossen ist, und das dafuer sorgt, dass zuerst die groessere
(untere/aeussere) Flaeche gerendert wird und darueber die
Bernd Wurst schrieb:
Das kommt stark drauf an ob man ein geschlossenes Polygon also einen Weg
mit
Ende == Anfang immer als Fläche bezeichnet oder ob man das erstmal nur als
Daten-Objekt sieht.
Eine Straße wird z.b. erst durch ein area=yes zu einer Fläche, selbst wenn
sie im Kreis geht
Am 19. Januar 2009 20:19 schrieb Torsten Leistikow de_m...@gmx.de:
Das stimmt sicherlich, aber bei der Diskussion hier geht es ja gerade um
...
Flaechenobjekte. Den Wald auf der Insel einfach vom restlichen Wald
abtrennen, ist ja
nicht gewuenscht. Der Wald soll ja als ein Element
Torsten Leistikow schrieb:
Garry schrieb:
Ist ein bischen nervig dass die Wasserflächen vom Wald überlagert werden.
Das Problem laesst sich aber nicht wirklich loesen. Wenn man die
Zeichenreihenfolge umkehrt, dann verschwinden die Inseln in den Seen.
Naja, besser nur die Inseln
Damit der Aufruf an alle:
Verkünstelt Euch nicht an dem Multipolygon-Kram sondern schneidet die
Flächen frei zum Wohle
aller Anwendungen! Es ist Schwachsinn mit einer Fläche zu sagen hier ist
Wald um mit einer zweiten
zu sagen hier ist aber doch keiner...
Gruss
Garry
__
Schön und
Torsten Leistikow schrieb:
Der Mehraufwand fuers Zerteilen der Flaeche beim Eintragen in die
Datenbank ist minimal. Dafuer laesst sich die grafische Darstellung dann
wesentlich einfacher realisieren (ins Besondere auf Navi-Geraeten, die
nicht speziell fuer OSM gebaut wurden).
Besonders bei
Tobias Knerr schrieb:
Besonders bei Software, die Icon oder Beschriftung in der Mitte jeder
Teilfläche anzeigt, ist die grafische Anzeige gelungen. Und bei der
Darstellung der Fläche mit Rand machen sich die Schnittkanten immer so
hübsch...
Dafuer gibt es ja die Relation, die angibt, dass die
Martin Koppenhoefer schrieb:
Damit der Aufruf an alle:
Verkünstelt Euch nicht an dem Multipolygon-Kram sondern schneidet die
Flächen frei zum Wohle
aller Anwendungen! Es ist Schwachsinn mit einer Fläche zu sagen
hier ist
Wald um mit einer zweiten
zu sagen hier
Ganz Deiner Meinung :-)
Damit der Aufruf an alle:
Verkünstelt Euch nicht an dem Multipolygon-Kram sondern schneidet die
Flächen frei zum Wohle
aller Anwendungen! Es ist Schwachsinn mit einer Fläche zu sagen hier ist
Wald um mit einer zweiten
zu sagen hier ist aber doch keiner...
Gruss
Tobias Knerr schrieb:
Torsten Leistikow schrieb:
Der Mehraufwand fuers Zerteilen der Flaeche beim Eintragen in die
Datenbank ist minimal. Dafuer laesst sich die grafische Darstellung dann
wesentlich einfacher realisieren (ins Besondere auf Navi-Geraeten, die
nicht speziell fuer OSM gebaut
Torsten Leistikow schrieb:
Wenn das auswertende Programm die Relation nicht kennt, dann ist die
resultierende Anzeige zwar nicht sonderlich schoen, aber immer noch
besser, als wenn Waelder die Seen ueberwuchern, oder umgekehrt die
Inseln im Wasser versinken, wenn die Multipolygon-Relation
Tobias Knerr schrieb:
Apropos Schnittkanten: Wenn schon z.B. ein Gebäude zersägt wird, um den
Hof darzustellen: Könnte man dann nicht wenigstens nur einen Teilschnitt
ansetzen (vom äußeren Rand auf den inneren, innen rum und auf denselben
zwei Nodes wieder zurück), so dass das Objekt eine
Tobias Knerr schrieb:
Die Idee wäre: Werden die Schnittkanten durch die Anwendung erzeugt,
weiß sie, wo es sich um künstliche Schnittkanten handelt und wo nicht,
und kann sich z.B. merken, ob sie einen Rand auf diesem Segment zeichnen
will oder nicht.
Apropos Schnittkanten: Wenn schon z.B.
Martin Simon schrieb:
Ganz Deiner Meinung :-)
Damit der Aufruf an alle:
Verkünstelt Euch nicht an dem Multipolygon-Kram sondern schneidet die
Flächen frei zum Wohle
aller Anwendungen! Es ist Schwachsinn mit einer Fläche zu sagen hier ist
Wald um mit einer zweiten
zu sagen hier ist aber
Am 18. Januar 2009 23:39 schrieb Garry garr...@gmx.de:
Es geht nicht nur um mkgmap sondern um alle Anwendungen die kein
Mutipolygon beherschen und denen
man das nicht beibringen möchte weil sie einfach bleiben sollen.
naja, was *so* einfach bleiben soll muss ja nicht unbedingt eine
perfekte
Am 18. Januar 2009 17:50 schrieb Tobias Knerr o...@tobias-knerr.de:
Torsten Leistikow schrieb:
Der Mehraufwand fuers Zerteilen der Flaeche beim Eintragen in die
Datenbank ist minimal. Dafuer laesst sich die grafische Darstellung dann
wesentlich einfacher realisieren (ins Besondere auf
Moin grenzdebil,
On Mon, 19 Jan 2009 00:50:15 +0100, grenzdebil wrote:
naja, was *so* einfach bleiben soll muss ja nicht unbedingt eine
perfekte Darstellung bieten, oder?
Erkläre das mal Garmin, daß die Überlagerungen perfekt beherrschen
müssen. Das ist nicht mehr _grenz_debil. Insofern passt
34 matches
Mail list logo
