Re: [Talk-de] verschachtelte Multipolygone
On Sun, 1 Mar 2009, Torsten Leistikow wrote: Eigenschaft in einem speziellen Fall vorangig dargestellt werden sollte. Dafuer muesste man dann aber Renderer-Kontroll-Tags einfuehren und nicht die Daten kuenstlich verbiegen, wie z.B. durch falsches Anbringen von Layer-Tags. Stellt Dir vor. Das Layer-Tag ist genau dieses Render-Kontrolltag. Es sagt nämlich dass Objekt x oberhalb/unterhalb von Objekt y ist. Das manche dort unbedingt physikalische Eigenschaften hineininterpretieren wollen ändert daran nichts. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hi Torsten. Torsten Leistikow wrote: Bei dem Beispiel mit dem Park sehe ich das Problem, dass sich in meinen Augen Wald und Park eigentlich ausschliessen. Fuer Wald haben wir zwei allg. akzeptierte Tags: landuse=forest steht fuer forstwirtschaftlich genutzte Flaechen und natural=wood steht fuer naturbelassenen Urwald. Beides gehoert eigentlich nicht zu einem Park. Stattdessen sehe ich das eigentlich eher so, dass das Tag leisure=park bereits beinhaltet, dass da Baeume stehen. Das war hier letztens mal Thema: Kurzfassung: landuse=forest und landuse=park schließen sich aus (logisch). landuse=park und natural=wood schließen sich nicht aus (auch logisch, es sei denn man ist der Meinung in einem Park dürfe es keine Bäume geben). Ergebnis könnte dann etwa so aussehen: http://www.openstreetmap.org/?lat=52.26866lon=10.55489zoom=16layers=B000FTF natural=wood als Synonym für Urwald zu benutzen ist quatsch. Richtig ist, das das meiste landuse=forest auch natural=wood ist. In Deutschland treten, außer in Schutzgebieten, vermutlich beide tags meistens parallel auf... In einem Park müssen IMHO überhaupt keine Bäume stehen. Manchmal gibt es große, alte, einzelne Bäume, die würde ich aber nicht mit natural=wood taggen (sondern natural=tree auf node). Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Gerrit Lammert schrieb: landuse=park und natural=wood schließen sich nicht aus (auch logisch, es sei denn man ist der Meinung in einem Park dürfe es keine Bäume geben). Das haben hier ein paar Leute so formuliert, ein paar fanden das gut, ein paar nicht. Ich bin ein bisschen konservativ und finde es besser, wenn man sich an die Vorgaben im Wiki haelt (so es denn welche zu einem Thema gibt)und ncht einfach sein eigenes Sueppchen kocht. D.h. wenn man die Bedeutung eines etablieretn Tags aendern will (das gilt sowohl fuer natural=wood als auch fuer das layer-Tag), dann sollte man am besten dafuer den Approval-Prozess anschmeissen, da bestimmt nicht alle fuer diese Aenderung sind. Auf alle Faelle sollte man aber die Beschreibung im Wiki anpassen. OSM ist ja gewollt sehr frei gehalten und ich habe auch nichts dagegen, wenn man seine eigenen Tags definiert. Aber bei der Bedeutung von bereits etabliereten Tags sollte man doch lieber zurueckhaltend sein, denn sonst weiss ja wirklich keiner mehr, was die Sachen in der Datenbank sollen. Anstatt das Layer-Tag umzudeuten (es ist von Anfang an als physikalisches Uebereinander definiert worden), kann man ja einfach ein neues Tag render_layer einfuehren. Alternativ muessten wir naemlich sonst auch ein neues Tag fuer die physikalische Anordnung erfinden. Und statt natural=wood umzudeuten kann man ja auch ein vegetation=wood einfuehren mit der gewuenschten Bedeutung. Das liesse sich dann auch gleich auf vegetation=gras und vegetation=flowers und aehnliche Sachen erweitern und koennte als Ergaenzung problemlos neben den bisherigen landuse-Tags existieren. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hi Torsten. Torsten Leistikow wrote: Gerrit Lammert schrieb: landuse=park und natural=wood schließen sich nicht aus (auch logisch, es sei denn man ist der Meinung in einem Park dürfe es keine Bäume geben). Das haben hier ein paar Leute so formuliert, ein paar fanden das gut, ein paar nicht. Ich bin ein bisschen konservativ und finde es besser, wenn man sich an die Vorgaben im Wiki haelt (so es denn welche zu einem Thema gibt)und ncht einfach sein eigenes Sueppchen kocht. Da stimme ich im Prinzip zu, bin auch gegen Wildwuchs. Aber im vorliegenden Fall ist die ältere Festlegung für mich die sprachliche und demnach ist wood=Wald (genauer Gehölz) und keineswegs Urwald. Im übrigen war mit Urwald im Wiki nie das Zeug am Amazonas gemeint. Viel mehr steht das Wort hier wohl für einen unbewirtschafteten Wald (ur im Sinne von urwüchsig). Der nachvollziehbare Gedankengang wird gewesen sein: forest=bewirtschafteter Wald (schließt natural=wood implizit ein), wood ohne forest = unbewirtschafteter Wald. Daran soll sich ja im Prinzip auch nichts ändern. Ich würde zwar immer noch explizit natural=wood an den forest hängen, weil es IMHO völlig verschiedene Sichtweisen sind (Landnutzung, bzw. Beschaffenheit), aber ich sehe nirgendwo ausgeschlossen, das Baumbestände nicht als solche getaggt werden sollen. Man kann sicher streiten, was bewirtschafteter Wald ist und was nicht. Bäume im Park sind sicher nicht urwüchsig, aber sie dienen i.d.R. auch nicht der Holzgewinnung. Aber das ist eine andere Frage. Also kurz: Ein Wald ist ein Wald und fertig. Zu der Layer-Geschichte kann ich Dir eigentlich nur zustimmen, die würde ich hier auch nicht setzen. Da muss es eine sinnvolle Renderreihenfolge ohne layer geben, ob landuses über oder unter natural gerendert werden soll. Ich denke (ausser in einer expliziten Flächennutzungskarte vielleicht) sollte landuse so ziemlich die unterste Ebene darstellen. Sonst müsste ja auch jeder Briefkasten, der in einem landuse=residential steht ein layer=1 bekommen. :) Gerrit PS: Jetzt weiß ich auch, woher der Ausspruch den Wald vor lauter Bäumen nicht sehen kommt, vermutlich weil natural=tree über natural=wood gerendert wird und jemand sehr eifrig beim Tree-Mapping* war. ;-) * Nicht zu verwechseln mit der Datenstruktur ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Gerrit Lammert schrieb: Aber im vorliegenden Fall ist die ältere Festlegung für mich die sprachliche und demnach ist wood=Wald (genauer Gehölz) und keineswegs Urwald. Naja, andere betonen halt das natural und folgern daraus, dass mit natural=wood nur naturbelassener Wald gemeint sein kann. Ich würde zwar immer noch explizit natural=wood an den forest hängen, weil es IMHO völlig verschiedene Sichtweisen sind (Landnutzung, bzw. Beschaffenheit), aber ich sehe nirgendwo ausgeschlossen, das Baumbestände nicht als solche getaggt werden sollen. Solange im Wiki steht, dass natural=wood einen naturbelassenen Wald meint (was im Park sicherlich nicht gegeben ist), musst du aber davon ausgehen, dass andere Leute im vertrauen auf das Wiki dir dein natural=wood wieder loeschen werden. Also kurz: Ein Wald ist ein Wald und fertig. Ja, aber in den seltensten Faellen ist er auch im engeren Sinne natural. Wobei da die herrschende Meinung nicht sonderlich konsequent ist. Beim Wasser benutzt man natural=water ja auch viel freier. Ich denke (ausser in einer expliziten Flächennutzungskarte vielleicht) sollte landuse so ziemlich die unterste Ebene darstellen. Sonst müsste ja auch jeder Briefkasten, der in einem landuse=residential steht ein layer=1 bekommen. :) Auf gleicher Ebene ist das wohl egal. Aber wenn ich mich recht entsinne, verschwinden bei Osmarenderer die Strassen, wenn du dem landuse einen hoeheren Layer verpasst. Sehr sinnvoll :-( Sinnvoller Wiese sollten die Flaechen (ob nun landuse oder natural oder was auch immer) immer unter/hinter den Linien und Punktsymbolen liegen. Ganz einfach, weil man sonst ja nichts mehr von den anderen sieht. Und wenn man dann als Mapper noch darauf achtet, dass sich verschiedene Flaechenelemente nicht ueberschneiden, dann ist man schon ein ordentliches Stueck weiter. Gruss Torsten Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hi, Dirk Stöcker schrieb: Kein Stern heisst nicht richtig, sondern nur dass JOSM keinen Fehler bemerkt hat. JOSM bemerkt nur Fehler, über die er beim Zeichnen stolpert Ich dachte bisher immer der Stern bedeutet, das nicht alle Mitglieder der Relation vollständig heruntergeladen worden. Gibts denn noch ne andere Bedeutung? Spielt es ne Rolle (Unterschied) ob der Stern vor multipolygon steht oder in den Klammern (rahmt aber vermutlich nur den Namen der Relation ein, oder?). schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hallo, Alexander Schulze schrieb: und für den 2. Anwendungsfall. Hab zum Beispiel gesehen, dass die Insel Mainau im Bodensee zwar als Insel dargestellt wird, aber das zusätzliche tag leisure=park ignoriert wird, allerdings nur von Mapnik. Auch nicht definiert oder falsches tagging? da habe ich folgendes auf den wiki-Seiten gefunden http://wiki.openstreetmap.org/wiki/Tagging_FAQ. So wirds dann auch in beiden Renderern richtig dargestellt. Allerdings widerspricht das ja den MapFeatures (Die Richtung des Weges ist egal, jedoch muss eine land-Insel auf water-Wasser einen höheren Layer erhalten. ). da nach dem FAQ keine Layerangabe erfolgen soll und natural=land auch nicht notwendig ist. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
On Sat, 28 Feb 2009, Alexander Schulze wrote: Dirk Stöcker schrieb: Kein Stern heisst nicht richtig, sondern nur dass JOSM keinen Fehler bemerkt hat. JOSM bemerkt nur Fehler, über die er beim Zeichnen stolpert Ich dachte bisher immer der Stern bedeutet, das nicht alle Mitglieder der Relation vollständig heruntergeladen worden. Gibts denn noch ne andere Bedeutung? Stern vor Elementen -- JOSM hat beim Zeichnen irgendeinen Fehler festgestellt. Dzu muss aber der Kartenmodus und nicht die Drahtdarstellung aktiviert sein. Ist ein relativ neues Feature. Das unvollständig siehst Du gar nicht. Das ist zu erkennen, wenn man die Relation im Editor öffnet. Dann werden Elemente als unvollständig dargestellt. Spielt es ne Rolle (Unterschied) ob der Stern vor multipolygon steht oder in den Klammern (rahmt aber vermutlich nur den Namen der Relation ein, oder?). In den Klammern? Dass kann eigentlich nur passieren, wenn die relation * heißt. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hi, dank dir schon mal für deine Erläuterungen, will aber noch mal kurz nachhaken ;-) Dirk Stöcker schrieb: Stern vor Elementen -- JOSM hat beim Zeichnen irgendeinen Fehler festgestellt. Dzu muss aber der Kartenmodus und nicht die Drahtdarstellung aktiviert sein. Ist ein relativ neues Feature. wollte eigentlich noch fragen was denn mögliche Fehler sein könnten? Kann hier z.B. nix finden http://www.openstreetmap.org/api/0.5/relation/78864/full. Also wonach müßte ich denn suchen? Eins wären bspw. Flächen die in 2 Relationen (als inner bzw. outer) enthalten sind, aber sonst. Das unvollständig siehst Du gar nicht. Das ist zu erkennen, wenn man die Relation im Editor öffnet. Dann werden Elemente als unvollständig dargestellt. okay In den Klammern? Dass kann eigentlich nur passieren, wenn die relation * heißt. taucht wohl immer nur bei Routen auf z.B. Relation 30512 (http://www.openstreetmap.org/api/0.5/relation/30512/full). schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
On Sat, 28 Feb 2009, Alexander Schulze wrote: Stern vor Elementen -- JOSM hat beim Zeichnen irgendeinen Fehler festgestellt. Dzu muss aber der Kartenmodus und nicht die Drahtdarstellung aktiviert sein. Ist ein relativ neues Feature. wollte eigentlich noch fragen was denn mögliche Fehler sein könnten? Kann hier z.B. nix finden http://www.openstreetmap.org/api/0.5/relation/78864/full. Also wonach müßte ich denn suchen? Eins wären bspw. Flächen die in 2 Relationen (als inner bzw. outer) enthalten sind, aber sonst. Das bekommst Du mit dem Validator heraus. Die Relation mit Stern selektieren (so dass sie in der Auswahl aktiv ist) und mit dem Validator prüfen. Dann kommen die Warnungen als lesbarer Text. In diesem Fall besagt die Warnung, dass sich inner- und outer-Polygone schneiden. Das Gebilde könnte auch komplett ohne Multipolygon gelöst werden. Das unvollständig siehst Du gar nicht. Das ist zu erkennen, wenn man die Relation im Editor öffnet. Dann werden Elemente als unvollständig dargestellt. okay In den Klammern? Dass kann eigentlich nur passieren, wenn die relation * heißt. taucht wohl immer nur bei Routen auf z.B. Relation 30512 (http://www.openstreetmap.org/api/0.5/relation/30512/full). Kommt bei mir kein Stern. Da steht route (Fläming-Skate RK3, 7 Elemente) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Dirk Stöcker schrieb: Das bekommst Du mit dem Validator heraus. Die Relation mit Stern selektieren (so dass sie in der Auswahl aktiv ist) und mit dem Validator prüfen. Dann kommen die Warnungen als lesbarer Text. In diesem Fall besagt die Warnung, dass sich inner- und outer-Polygone schneiden. Das Gebilde könnte auch komplett ohne Multipolygon gelöst werden. Also ich kann nicht erkennen, wo die sich schneiden. Die überlappen an genau 5 gemeinsamen Punkten, aber schneiden sich nicht. Und wie soll ich das ohne Multipolygon lösen. Steh wohl etwas aufm Schlauch. Das ganze Gebiet ist dem Motocross zu gehörig (also outer) und die definierten Waldstücke liegen innerhalb des Gebietes, grenzen aber jeweils an die Außenkante des Motocrossgeländes. Dazu muss ich doch Multipolygon benutzen? Oder wie kann ich das sonst machen? Kommt bei mir kein Stern. Da steht route (Fläming-Skate RK3, 7 Elemente) das liegt dann wohl an den Ländereinstellungen unter XP. schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
On Sat, 28 Feb 2009, Alexander Schulze wrote: Dirk Stöcker schrieb: Das bekommst Du mit dem Validator heraus. Die Relation mit Stern selektieren (so dass sie in der Auswahl aktiv ist) und mit dem Validator prüfen. Dann kommen die Warnungen als lesbarer Text. In diesem Fall besagt die Warnung, dass sich inner- und outer-Polygone schneiden. Das Gebilde könnte auch komplett ohne Multipolygon gelöst werden. Also ich kann nicht erkennen, wo die sich schneiden. Die überlappen an genau 5 gemeinsamen Punkten, aber schneiden sich nicht. Und wie soll ich das ohne Multipolygon lösen. Steh wohl etwas aufm Schlauch. Das ganze Gebiet ist dem Motocross zu gehörig (also outer) und die definierten Waldstücke liegen innerhalb des Gebietes, grenzen aber jeweils an die Außenkante des Motocrossgeländes. Dazu muss ich doch Multipolygon benutzen? Oder wie kann ich das sonst machen? Hmm. Mit multipolygon sagst Du ja eigentlich das ist alles Motocross, ausser den Inner-Teilen, die nicht. In dem gegeben Fall könntest Du das auch erreichen, wenn Du die Außengrenze entlang der Wälder führst, deswegen mault JOSM. Das das natürlich mit Deiner Feststellung Eigentlich ist das alles Motocross-Gebiet nicht zusammenpasst ist auch klar. Es gibt zwei Möglichkeiten: a) So lassen, wie es ist (JOSM's Warnungen sind auch nicht der Weisheit letzter Schluß, ich muss es ja wissen, ich habe sie eingebaut :-) b) Multipolygon entfernen und nur den Außenrand eintragen und die Waldstücke als Layer=1. Ich würde für (a) plädieren. Die Ansicht, wie es korrekt ist, wird sich sowieso im Laufe der Zeit garantiert noch ein paar mal ändern. Um ganz sicherzugehen schreibt einfach als comment dran, wie es ist (comment=Wald ist auch Teil der Cross-Strecke). Dann kann man es später notfalls korrigieren. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Am 28. Februar 2009 20:50 schrieb Dirk Stöcker openstreet...@dstoecker.de: Es gibt zwei Möglichkeiten: a) So lassen, wie es ist (JOSM's Warnungen sind auch nicht der Weisheit letzter Schluß, ich muss es ja wissen, ich habe sie eingebaut :-) b) Multipolygon entfernen und nur den Außenrand eintragen und die Waldstücke als Layer=1. Ich würde für (a) plädieren. Die Ansicht, wie es korrekt ist, wird sich sowieso im Laufe der Zeit garantiert noch ein paar mal ändern. Moin! Ich wäre stark für b), aber ohne einen layer zu verwenden - stattdessen sollte man bei den Renderern anklopfen, damit diese einfach wald über anderen landuse-flächen rendern. Dasselbe Problem ergibt sich bei Waldflächen, die z.B. in Parks liegen und dort auch den Park nicht verdrängen, sondern auf derselben Ebene existieren. Auch hier wäre ein Multipolygon falsch, weil es den Park in seiner Ausdehnung beschneidet und ein layer=1 für den Wald wäre falsch, weil es einfach ein hack für den Renderer ist und das Waldgebiet sich nicht über dem Park befindet. Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Moin, hatte nicht gestern jemand behauptet, es ware doch allgemein klar, wie multipolygon-Relationen funktionieren ;-) Martin Simon schrieb: Am 28. Februar 2009 20:50 schrieb Dirk Stöcker openstreet...@dstoecker.de: Es gibt zwei Möglichkeiten: a) So lassen, wie es ist (JOSM's Warnungen sind auch nicht der Weisheit letzter Schluß, ich muss es ja wissen, ich habe sie eingebaut :-) b) Multipolygon entfernen und nur den Außenrand eintragen und die Waldstücke als Layer=1. Ich wäre stark für b), aber ohne einen layer zu verwenden - stattdessen sollte man bei den Renderern anklopfen, damit diese einfach wald über anderen landuse-flächen rendern. So pauschal kann man das nicht sagen. Es gibt auch den umgekehrten Fall, bei dem landuse-Flaechen innerhalb eines groesseren Waldes liegen, die dann alle von der Karte verschwinden wuerden. (In Deutschland leider sogar recht haeufig, weil es hier mal Mode war, die Mittelgebirge jeweils als riesen Waldgebiet einzutragen.) Dasselbe Problem ergibt sich bei Waldflächen, die z.B. in Parks liegen und dort auch den Park nicht verdrängen, sondern auf derselben Ebene existieren. Auch hier wäre ein Multipolygon falsch, weil es den Park in seiner Ausdehnung beschneidet und ein layer=1 für den Wald wäre falsch, weil es einfach ein hack für den Renderer ist und das Waldgebiet sich nicht über dem Park befindet. Bei dem Beispiel mit dem Park sehe ich das Problem, dass sich in meinen Augen Wald und Park eigentlich ausschliessen. Fuer Wald haben wir zwei allg. akzeptierte Tags: landuse=forest steht fuer forstwirtschaftlich genutzte Flaechen und natural=wood steht fuer naturbelassenen Urwald. Beides gehoert eigentlich nicht zu einem Park. Stattdessen sehe ich das eigentlich eher so, dass das Tag leisure=park bereits beinhaltet, dass da Baeume stehen. Allerdings kann ich auch den Wunsch verstehen, dass man bei groesseren Parks zwischen Waldflaechen und Freiflaechen in der Karte unterscheiden moechte. Zurueck zum Problem der ueberschneidenden Landnutzungen: Der Vorschlag mit dem layer-Tag ist natuerlich Bloedsinn. Ich wuenschte, die Renderer wuerde das nicht beruecksichtigen, denn schliesslich wollen sie ja Karten malen und keine Luftbilder. Wie machen wir es denn bei den Strasse? Da wuerden wir einmal die Freiflaechen im Park (ich bleibe jetzt mal bei dem Beispiel) als Polygon eintragen und als Park taggen. Die Waldstuecke wuerden wir als eigene Polygone einzeichnen und gleichzeitig als Park und als Wald taggen. Was spricht dagegen, das so zu machen? Die Information, dass es sich um einen zusammenhaengenden Park handelt, leidet ein wenig. Das haben wir bei den Strassen allerdings auch. Man kann das zwar noch ueber das name-Tag erkennen, aber das ist sicherlich ein bisschen duenn. Bei den Strassen gibt es dann noch die Relation segmented-ways, mit der man einzelne Strassenteile wieder zusammenfassen kann. Als zweites ist damit das Problem der Darstellung beim Renderer noch nicht geloest. Da kann man einmal die Sichtweise vertreten, dass das ausschliesslich ein Renderer-Problem ist, um das sich der Mapper nicht kuemmern soll. Schliesslich kann ja jeder Renderer seine Schwerpunkte anders setzen und da kann der Mapper ja keine Vorschriften machen. Auf der anderen Seite kann es natuerlich auch sein, dass die Ortskenntnisse des Mappers notwendig sind, um entscheiden zu koennen, welche Eigenschaft in einem speziellen Fall vorangig dargestellt werden sollte. Dafuer muesste man dann aber Renderer-Kontroll-Tags einfuehren und nicht die Daten kuenstlich verbiegen, wie z.B. durch falsches Anbringen von Layer-Tags. Wenn ich die verschiedenen Punkte abwaege, scheint mir folgender Ansatz am sinnvollsten: 1. In der OSM-Datenbank sollten sich keine Flaechenelemente ueberlagern. Eine Ueberlagerung bedeutet letztendlich, das es fuer die betreffende Stelle widerspruechliche Angaben gibt, da fuer solche Faelle weder eine Prioritaetenregelung noch eine Und-Verknuepfung definiert ist. Es ist also Aufgabe des Mappers, fuer klare Daten in der Datenbank zu sorgen. 2. Die Darstellung der Flaechen ist allein Sache des Renderers. Im Park-Beispiel entscheidet jeder Renderer nach seinen Regeln, ob er die Flaeche als Park oder als Wald darstellt. Es ist ja auch moeglich, dass er Flaechen, die gleichzeitig als Park und Wald gekennzeichnet sind, auf eine dritte Art zeichnet, also weder als reinen Wald noch als reinen Park (z.B. mit dem Park-Muster in etwas dunklerer Farbe). Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] verschachtelte Multipolygone
Hallo, habe 2 Anwendungsfälle, wo ich mal nen bischen Hilfe bräuchte. Fall 1: Außerhalb ist ein großes Waldpolygon, darin liegt dann ne Ackerfläche und darin einmal nen kleiner See und ne Ortschaft. landuse=forest -- multipolygon -- outer landuse=farmland -- multipolygon -- inner landuse=residential -- multipolygon -- inner natural=water -- multipolygon -- inner -- bei Mapnik ist alles ok, aber osmarender rendert das residential-Gebiet gar nicht. Habe dann nen bischen variiert und folgendes getaggt. landuse=forest -- 1. multipolygon -- outer landuse=farmland -- 1. multipolygon -- inner und 2. multipolygon -- outer landuse=residential -- 2. multipolygon -- inner natural=water -- 2. multipolygon -- inner -- bei Mapnik immer noch alles ok, bei osmarender ist jetzt die residential-Fläche sichtbar, aber hat keine residential-Farbgebung. Fall 2: Außerhalb wieder Wald, darin nen See und in dem See ne Insel mit Wald. landuse=forest -- multipolygon -- outer natural=water -- multipolygon -- inner natural=land, landuse=forest und layer=1 -- bei osmarender alles ok, bei Mapnik wird der Wald auf der Indel nicht gerendert, die Insel ist aber da. Liegt das jetzt an den Renderern oder tagge ich das ganze falsch? schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
On Fri, 27 Feb 2009, Alexander Schulze wrote: habe 2 Anwendungsfälle, wo ich mal nen bischen Hilfe bräuchte. Fall 1: Außerhalb ist ein großes Waldpolygon, darin liegt dann ne Ackerfläche und darin einmal nen kleiner See und ne Ortschaft. landuse=forest -- multipolygon -- outer landuse=farmland -- multipolygon -- inner landuse=residential -- multipolygon -- inner natural=water -- multipolygon -- inner Solange niemand definiert was bei verschachtelten Multipolygonen passieren soll (und ich glaube nicht, dass das jemand vernünftig hinbekommt) brauchst Du hier 2 Multipolygone: 1: forest(outer), farmland(inner) 2: farmland(outer), residential(inner), water(inner) Falls Du mit JOSM arbeitest: Wenn Du alles richtig gemacht hast, hat keins der Multipolygone einen Stern vor den Namen und jede Fläche wird nur einmal gemalt. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hi, Dirk Stöcker schrieb: 1: forest(outer), farmland(inner) 2: farmland(outer), residential(inner), water(inner) Falls Du mit JOSM arbeitest: Wenn Du alles richtig gemacht hast, hat keins der Multipolygone einen Stern vor den Namen und jede Fläche wird nur einmal gemalt. Empfinde ich auch als logischere Lösung. hab in Josm keine Sternchen. Also kann Osmarender das nicht richtig verarbeiten, weil es nichbt definiert ist. Gut damit kann ich dann erstmal leben. und für den 2. Anwendungsfall. Hab zum Beispiel gesehen, dass die Insel Mainau im Bodensee zwar als Insel dargestellt wird, aber das zusätzliche tag leisure=park ignoriert wird, allerdings nur von Mapnik. Auch nicht definiert oder falsches tagging? Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
On Fri, 27 Feb 2009, Alexander Schulze wrote: 1: forest(outer), farmland(inner) 2: farmland(outer), residential(inner), water(inner) Falls Du mit JOSM arbeitest: Wenn Du alles richtig gemacht hast, hat keins der Multipolygone einen Stern vor den Namen und jede Fläche wird nur einmal gemalt. Empfinde ich auch als logischere Lösung. hab in Josm keine Sternchen. Also kann Osmarender das nicht richtig verarbeiten, weil es nichbt definiert ist. Gut damit kann ich dann erstmal leben. Kein Stern heisst nicht richtig, sondern nur dass JOSM keinen Fehler bemerkt hat. JOSM bemerkt nur Fehler, über die er beim Zeichnen stolpert :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Alexander Schulze schrieb: Liegt das jetzt an den Renderern oder tagge ich das ganze falsch? Mal eine kleine Sinnfrage: Was sollen so komplizierte Konstrukte? Wozu tragen wir die Daten in die Datenbank ein? Damit sie irgenwo dargestellt werden bzw. ausgewertet werden koennen? Oder als Knobelaufgabe fuer die verschiedenen Renderer und Asuwerteprogramme? Oberste Regel sollte sein: Keep it simple!!! Wenn einem selber nach einem kurzen Blick ins Wiki nicht klar ist, ob die Eintragung in Ordnung ist, wie kann man dann erwarten, dass alle Renderer und Auswerteprogramme das so verstehen, wie man es meint? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hi, Torsten Leistikow schrieb: Alexander Schulze schrieb: Liegt das jetzt an den Renderern oder tagge ich das ganze falsch? Mal eine kleine Sinnfrage: Was sollen so komplizierte Konstrukte? Wozu tragen wir die Daten in die Datenbank ein? Damit sie irgenwo dargestellt werden bzw. ausgewertet werden koennen? Oder als Knobelaufgabe fuer die verschiedenen Renderer und Asuwerteprogramme? das liegt einfach daran, dass jemand Riesenwaldpolygone gebastelt hat und ich gerade keine Lust hatte diese gescheit aufzuteilen, aber doch gerne die bisher von Wald überdeckten anderen Flächen richtig taggen möchte. Oberste Regel sollte sein: Keep it simple!!! kann ich dir eigentlich nur zustimmen. Ich bemüh mich eigentlich immer überschaubare Polygone zu bauen. Wenn einem selber nach einem kurzen Blick ins Wiki nicht klar ist, ob die Eintragung in Ordnung ist, wie kann man dann erwarten, dass alle Renderer und Auswerteprogramme das so verstehen, wie man es meint? Aber mein 2. geschildertes problem hat durchaus nix mit ner Knobelaufgabe zu tun, den ne Insel in einem See auf der Wald oder nen Park ist, geht nicht einfacher zu taggen und Mapnik scheint das wohl noch nicht zu raffen, siehe Blumeninsel Mainau im Bodensee als prominentes Beispiel. schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] verschachtelte Multipolygone
Hallo! Torsten Leistikow schrieb: Alexander Schulze schrieb: Liegt das jetzt an den Renderern oder tagge ich das ganze falsch? Mal eine kleine Sinnfrage: Was sollen so komplizierte Konstrukte? Wozu tragen wir die Daten in die Datenbank ein? Damit sie irgenwo dargestellt werden bzw. ausgewertet werden koennen? Oder als Knobelaufgabe fuer die verschiedenen Renderer und Asuwerteprogramme? Oberste Regel sollte sein: Keep it simple!!! Das kann ich nur unterstützen! Wenn man eine Situation mit zwei einfachen Multipolygonen so darstellen kann, daß - jeder versteht was gemeint ist - alle Renderer es sauber darstellen Wozu soll ich dann was Kompliziertes basteln, wovon ich selber nicht mehr weiß was richtig ist und was in jedem Renderer anders aussieht? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
