Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19.05.2011 18:40, schrieb Torsten Leistikow: Es hat halt jeder so seine eigene Mapping-Technik, jeder Ansatz hat ja auch seine Vor- und seine Nachteile. Bei den Flussflaechen z.B. gibt es in meiner Region einen Mapper, der an den Trennstellen die beiden Teile immer ein wenig ueberlappen lasst. Das sorgt dann dafuer, dass Renderer an der Schnittstelle keinen sichtbaren Streifen erzeugt, aber ueberlappende Fluss-Abschnitte ist datentechnisch natuerlich totaler Bloedsinn. Ich verwende für Flüsse auch multipolygone. cu fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 17.05.2011 11:00, schrieb Steffen Grunewald: Gemeinsam scheint beiden Fällen zu sein, daß die Wasserfläche innerhalb einer NR liegt. Die auf www.openstreetmap.org verfügbaren Renderer stellen die Seen dar. Mapnik malt es ja schon seit einiger Zeit transparent (Schriftzug NR) über die eventuell parallel gesetzten Flächenmerkmale (Wald, Wiese, See, etc.). Ich meine, dass die Garmin Typfile auch in der Lage sind transparente Flächen zu definieren. Ansonsten muss man halt per Renderregel NR-Flächen nach unten legen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Diese Antwort bezieht sich jetzt sowohl auf die Mail von Garry als auch auf die andere Antwort von Martin. Natürlich ist das keine Optimale Lösung, und nein, ich würde dieses Tool nicht einsetzen um die manuelle Unterteilung zu ersetzen. Ich denke aber, dass es sinnvoll sein könnte, die großen landuses erstmal automatisch zu teilen, um dann manuell die Grenzen zu verfeinern. Deine Aussage, Garry, damit gingen Daten verloren, stimmt ja nur, wenn du vorher landuses zusammenfasst, wo die Daten schon genauer sind. Da, wo Wälder über Bundesstraßen etc. liegen, sind die Daten aber noch nicht in der Datenbank. Gruß Peter P.S.: Nein, ich würde das Tool auch nicht als vollautomatisches Update laufen lassen wollen, sondern z.B. als JOSM-Plugin, mit dem ich ein landuse entsprechend splitten und dann nachbearbeiten kann - und dafür stell ich mir das ganz praktisch vor, weil einiges an Arbeit entfällt, die man beim systematischen manuellen Aufteilen hätte: Den alten Grenzverlauf da nachzuziehen, wo das große landuse-Poly zu Ende war, das Erstellen einer Relation, wenn gewünscht, das Setzen der Tags auf der Relation (oder alternativ auf den einzelnen Polygonen) und so weiter. Am 19.05.2011 01:23, schrieb Garry: Am 18.05.2011 14:38, schrieb Peter Wendorff: Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: Am 18. Mai 2011 12:56 schrieb Martin Simongrenzde...@gmail.com: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. Aufgabe an gelangweilte Programmierer (falls es solche gibt): Tool, das genau das Problem löst: Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von dessen width-Tag aus. ;) Gut dass Du den Smiley nicht vergessen hast. Dass kann man als Notlösung dort machen wo die Daten noch nicht besser sind. Markante Konturen gehen so verloren da sich bestenfalls der minimale, aber nie der reale Abstand zwischen Fahrbahn und Waldgrenze angeben lässt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19.05.2011 08:50, schrieb Peter Wendorff: Diese Antwort bezieht sich jetzt sowohl auf die Mail von Garry als auch auf die andere Antwort von Martin. Natürlich ist das keine Optimale Lösung, und nein, ich würde dieses Tool nicht einsetzen um die manuelle Unterteilung zu ersetzen. Ich denke aber, dass es sinnvoll sein könnte, die großen landuses erstmal automatisch zu teilen, um dann manuell die Grenzen zu verfeinern. Deine Aussage, Garry, damit gingen Daten verloren, stimmt ja nur, wenn du vorher landuses zusammenfasst, wo die Daten schon genauer sind. Da, wo Wälder über Bundesstraßen etc. liegen, sind die Daten aber noch nicht in der Datenbank. Gruß Peter P.S.: Nein, ich würde das Tool auch nicht als vollautomatisches Update laufen lassen wollen, sondern z.B. als JOSM-Plugin, mit dem ich ein landuse entsprechend splitten und dann nachbearbeiten kann - und dafür stell ich mir das ganz praktisch vor, weil einiges an Arbeit entfällt, die man beim systematischen manuellen Aufteilen hätte: Den alten Grenzverlauf da nachzuziehen, wo das große landuse-Poly zu Ende war, das Erstellen einer Relation, wenn gewünscht, das Setzen der Tags auf der Relation (oder alternativ auf den einzelnen Polygonen) und so weiter. Achso, Du willst das Tool auf die Daten selbst loslassen, ich hatte es so verstanden dass es nur zum Rendern eingesetzt werden soll. Klingt erstmal nicht schlecht, aber ob dass auch zuverlässig in den komplexen Gebieten funktioniert wo grosszügig mit inner/outer gearbeitet wurde? Als eins der einfacheren Beispiele: Eine Ortschaft an einer Bundesstrasse die ringsum von Wald umgeben ist und deren landuse=residential als inner für das Waldgebiet angelegt wurde... Gruss Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19. Mai 2011 16:13 schrieb Garry garr...@gmx.de: Am 19.05.2011 08:50, schrieb Peter Wendorff: Als eins der einfacheren Beispiele: Eine Ortschaft an einer Bundesstrasse die ringsum von Wald umgeben ist und deren landuse=residential als inner für das Waldgebiet angelegt wurde... Da kann man als erstes mal den Wald an der Straße in 2 Teile teilen, dann braucht man meistens schon mal kein Multipolygon für die Ortschaft mehr. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19.05.2011 17:05, schrieb M∡rtin Koppenhoefer: Am 19. Mai 2011 16:13 schrieb Garrygarr...@gmx.de: Als eins der einfacheren Beispiele: Eine Ortschaft an einer Bundesstrasse die ringsum von Wald umgeben ist und deren landuse=residential als inner für das Waldgebiet angelegt wurde... Da kann man als erstes mal den Wald an der Straße in 2 Teile teilen, dann braucht man meistens schon mal kein Multipolygon für die Ortschaft mehr. Das schon, aber die Frage ist ob ,man damit auch zuverlässig die bis dahin verwendeten Multipolygon-Tags (inner) löschen kann ohne etwas anderes zu zerschiessen.. Oder was ich auch schon hatte dass bei grossen Waldgebiet die ich zerteilt hatte Grenzlinien zwischen zwei grossen Teilfächen verliefen die keine natürliche Ursache (Strasse,Gewässer,etc) hatte. Da war nicht zu erkennen ob diesel Linie einen anderen Hintergrund hatte als nur die beiden Teilfächen zu teilen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Garry schrieb am 19.05.2011 17:51: Oder was ich auch schon hatte dass bei grossen Waldgebiet die ich zerteilt hatte Grenzlinien zwischen zwei grossen Teilfächen verliefen die keine natürliche Ursache (Strasse,Gewässer,etc) hatte. Da war nicht zu erkennen ob diesel Linie einen anderen Hintergrund hatte als nur die beiden Teilfächen zu teilen. Es hat halt jeder so seine eigene Mapping-Technik, jeder Ansatz hat ja auch seine Vor- und seine Nachteile. Bei den Flussflaechen z.B. gibt es in meiner Region einen Mapper, der an den Trennstellen die beiden Teile immer ein wenig ueberlappen lasst. Das sorgt dann dafuer, dass Renderer an der Schnittstelle keinen sichtbaren Streifen erzeugt, aber ueberlappende Fluss-Abschnitte ist datentechnisch natuerlich totaler Bloedsinn. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19. Mai 2011 17:51 schrieb Garry garr...@gmx.de: Da kann man als erstes mal den Wald an der Straße in 2 Teile teilen, dann braucht man meistens schon mal kein Multipolygon für die Ortschaft mehr. Das schon, aber die Frage ist ob ,man damit auch zuverlässig die bis dahin verwendeten Multipolygon-Tags (inner) löschen kann ohne etwas anderes zu zerschiessen.. klar, das ist ein Punkt wo man sich das ganze gründlich ansehen muss. Habe neulich auch ein Multipolygon geteilt. Das ist viel Arbeit, man muss die ganzen inners von einem aufs andere schieben und zusehen, dass man nichts übersieht. Aber der Editor ist mittlerweile auch deutlich besser geworden als noch vor Jahren. Man kann die Sachen auswählen, dann aus dem einen ausschließen, und im gleichen Zug dem anderen MP zuschlagen (da sie noch selektiert sind). Über Relation selektieren kann man dann nochmal visuell prüfen, ob alles stimmt. Das macht man ein paarmal, dann sollte es hinhauen. Fehler findet in dem Bereich auch der Validator zuverlässig (inners die ausserhalb der outer liegen). Oder was ich auch schon hatte dass bei grossen Waldgebiet die ich zerteilt hatte Grenzlinien zwischen zwei grossen Teilfächen verliefen die keine natürliche Ursache (Strasse,Gewässer,etc) hatte. Da war nicht zu erkennen ob diesel Linie einen anderen Hintergrund hatte als nur die beiden Teilfächen zu teilen. wenn sie nicht getaggt ist und nicht mind. einer der Wälder einen unterschiedlichen Tag hat, dann ist es zumindest aus Datensicht erstmal egal. Wer da nichtmal einen note an seine Mitmapper hinterlässt, braucht sich hinterher auch nicht zu beschweren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 17.05.2011 16:43, schrieb Torsten Leistikow: Nicht ganz sauber ist allerdings das Multipolygon 8794: - Zwei jeweils geschlossenen, aneinandergrenzende outer-Mitglieder sind unnötig kompliziert, da sollte man lieber zwei Relationen draus machen. (In diesem Fall braucht der Weg 9719294 nicht mal ein Multipolygon sein, z.Z. gibt es da drin keine inner-Mitglieder.) - Mehrere Flaechen innerhalb des Multipolygons sind nicht als inner-Mitglieder eingetragen, obwohl sie nicht zur Waldflaeche dazugehoeren (z.B. Weg 53389956 landuse=rail oder Weg 47046253 landuse=commerial). Gerade landuse=rail (ebenso highway, insbesondere motorway/trunk) sollte kein inner einer Waldfläche sein sondern eine Trennfläche zwischen zwei einzelnen in sich geschlossenene Waldpolygonen ohne gemeinsamen nodes. U.a. würde sonst ein spätere Detailverfeinerung unnnötig kompliziert werden. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18. Mai 2011 11:30 schrieb Garry garr...@gmx.de: Gerade landuse=rail (ebenso highway, insbesondere motorway/trunk) sollte kein inner einer Waldfläche sein sondern eine Trennfläche zwischen zwei einzelnen in sich geschlossenene Waldpolygonen ohne gemeinsamen nodes. +1, sehe ich auch so. Wenn es geht, getrennte Polygone anlegen. Gemeinsame nodes können in so einem Fall eigentlich gar nicht existieren, da ja eine erhebliche Fläche dazwischenliegt. Einzelne identifizierbare Flächen würde ich als solche mappen, und nicht zusammenfassen. Letzteres führt zwar kurzfristig schneller zu einer kompletter aussehenden Karte, ist aber ungenau und führt zu erheblichem Mehraufwand bei der Ergänzung von Details und zu unnötigen Multipolygonen. Ausserdem ist der Informationsgehalt ungleich geringer. Ein (zufällig gefundenes) Beispiel, wie ich es nicht machen würde: http://www.openstreetmap.org/browse/way/91584654 Wie ich es machen würde: http://www.openstreetmap.org/browse/way/106441866 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Einzelne identifizierbare Flächen würde ich als solche mappen, und nicht zusammenfassen. Letzteres führt zwar kurzfristig schneller zu einer kompletter aussehenden Karte, ist aber ungenau und führt zu erheblichem Mehraufwand bei der Ergänzung von Details und zu unnötigen Multipolygonen. Ausserdem ist der Informationsgehalt ungleich geringer. Ein (zufällig gefundenes) Beispiel, wie ich es nicht machen würde: http://www.openstreetmap.org/browse/way/91584654 Wie ich es machen würde: http://www.openstreetmap.org/browse/way/106441866 Naja, landuse ist ja eigentlich für die Beschreibung der Nutzung größerer Gebiete gedacht, in denen durchaus auch Wege liegen können und (m.E.) sollen. Ich würde wirklich nicht an jedem track oder path (oder für jedes Feld/Flurstück) ein landuse=farmland unterbrechen, genauso wenig landuse=residential an jedem highway=residential, path oder gar der Grundstücksgrenze. Bei breiten Autobahn- oder Bahntrassen sieht es natürlich anders aus. Von daher bin ich eher bei deinem ersten Beispiel als beim zweiten, wo landuse=farmland anscheinend für einzelne Felder (oder sogar die effektiv genutzte Acker-/Weidefläche via Luftbild) genommen wird, selbst wenn sie nicht durch (eingezeichnete) Wege unterbrochen werden. In den Niederlanden gab es einen Import von Waldflächen, der die Flächen aller Waldwege aussparte - was zu tausenden Miniwäldern führte und zu dem Problem, daß man z.B. die Funktion von mkgmap, sehr kleine Landuse-Flächen in niedrigen Zoomleveln auszublenden, dort nicht nutzen kann, weil man dann praktisch alle Waldflächen verliert... Ich denke wir brauchen eher eigene tags für Feld, Flurstück etc. und sollten landuse=* eine Ebene höher belassen, bei der Nutzung eines größeren Gebietes. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18. Mai 2011 12:56 schrieb Martin Simon grenzde...@gmail.com: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: Multipolygonen. Ausserdem ist der Informationsgehalt ungleich geringer. Naja, landuse ist ja eigentlich für die Beschreibung der Nutzung größerer Gebiete gedacht, in denen durchaus auch Wege liegen können und (m.E.) sollen. m.E. kann ein Weg nicht im Landuse liegen (bzw. nur Wege auf Grundstücken). Landuse entspricht nicht dem Flächennutzungsplan (m.E.). Ich würde wirklich nicht an jedem track oder path (oder für jedes Feld/Flurstück) ein landuse=farmland unterbrechen, genauso wenig landuse=residential an jedem highway=residential, path oder gar der Grundstücksgrenze. Bei breiten Autobahn- oder Bahntrassen sieht es natürlich anders aus. Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. In den Niederlanden gab es einen Import von Waldflächen, der die Flächen aller Waldwege aussparte - was zu tausenden Miniwäldern führte ja, daran siehst Du ja schon: auch die Behörden arbeiten mit kleinen Stücken. Die sparen die Waldwege deshalb aus, weil es eben Sinn macht. und zu dem Problem, daß man z.B. die Funktion von mkgmap, sehr kleine Landuse-Flächen in niedrigen Zoomleveln auszublenden, dort nicht nutzen kann, weil man dann praktisch alle Waldflächen verliert... das ist ein kleineres Problem, das durch die derzeitige Unvollkommenheit bei der Kartenerstellung resultiert. Wir mappen ja nicht für mkgmap, und wenn es auf dem Garmin wünschenswert sein sollte, die Flächen vor (oder während oder nach) der Kartenerstellung zusammenzufassen, dann kann man das ja tun. Damit würde sich dieses Problem lösen. Ich denke wir brauchen eher eigene tags für Feld, Flurstück etc. und sollten landuse=* eine Ebene höher belassen, bei der Nutzung eines größeren Gebietes. Vorteil? Eigene Tags für Feld und Flurstück kann man ja gerne haben (z.B. um Namen und Nummern einzugeben), aber wäre es da nicht sinnvoller, auch gleich die Landnutzung mit ranzuhängen, als nochmal doppelt eine Generalisierung der Landnutzung zu überlagern, die man auch automatisch erstellen könnte? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18.05.2011 12:56, schrieb Martin Simon: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: Einzelne identifizierbare Flächen würde ich als solche mappen, und nicht zusammenfassen. Letzteres führt zwar kurzfristig schneller zu einer kompletter aussehenden Karte, ist aber ungenau und führt zu erheblichem Mehraufwand bei der Ergänzung von Details und zu unnötigen Multipolygonen. Ausserdem ist der Informationsgehalt ungleich geringer. Ein (zufällig gefundenes) Beispiel, wie ich es nicht machen würde: http://www.openstreetmap.org/browse/way/91584654 Wie ich es machen würde: http://www.openstreetmap.org/browse/way/106441866 Naja, landuse ist ja eigentlich für die Beschreibung der Nutzung größerer Gebiete gedacht, in denen durchaus auch Wege liegen können und (m.E.) sollen. Ein Problem liegt schon mal darin dass zu wenig zwischen Bodenbedeckung und Landnutzung unterschieden wird, damit könnte man sich sonst für die Zukunft viel Arbeit sparen wenn man jetzt schon konsequent unterscheidet. Ich würde wirklich nicht an jedem track oder path (oder für jedes Feld/Flurstück) ein landuse=farmland unterbrechen, genauso wenig landuse=residential an jedem highway=residential, path oder gar der Am Anfang von OSM dachte man auch nocht nicht so sehr daran einzelne Gebäude einzutragen... Meine persönnliche Grenze bei Waldflächen ist dezeit bei Strassenkategorien oberhalb residential um die Aufwand nicht zu hoch zu treiben. Landuse=residential trenne ich eigentlich nur dann wenn die Strasse nicht innerörtlich ist. Wenn die Verfügbarkeit der Grundstücksgrenzen gegeben ist wäre Martins Vorschlag eleganter. Mir geht es vor allem auch darum dass ich lokal schnell Detailverbesserungen einbringen kann ohne mir Gedanken machen zu müssen dass deswegen in 10km Entfernung etwas kaputt geht weil sich jemand mit Multipolygonen zu sehr verkünstelt hat Grundstücksgrenze. Bei breiten Autobahn- oder Bahntrassen sieht es natürlich anders aus. Landuse = rail ist ja inzwischen schon relativ gut verbreitet, bei landuse=road sieht es noch deutlich schlechter aus zumal es von den Rendereren nicht/kaum unterstützt wird. Von daher bin ich eher bei deinem ersten Beispiel als beim zweiten, wo landuse=farmland anscheinend für einzelne Felder (oder sogar die effektiv genutzte Acker-/Weidefläche via Luftbild) genommen wird, selbst wenn sie nicht durch (eingezeichnete) Wege unterbrochen werden. In den Niederlanden gab es einen Import von Waldflächen, der die Flächen aller Waldwege aussparte - was zu tausenden Miniwäldern führte und zu dem Problem, daß man z.B. die Funktion von mkgmap, sehr kleine Landuse-Flächen in niedrigen Zoomleveln auszublenden, dort nicht nutzen kann, weil man dann praktisch alle Waldflächen verliert... Probleme hat man jetzt teilweise auch mit sehr grossen Waldflächen. Abgesehen davon wäre es ja nicht besonders geschickt die erhaltenen Daten wieder zu verschlechtern... Ich denke wir brauchen eher eigene tags für Feld, Flurstück etc. und sollten landuse=* eine Ebene höher belassen, bei der Nutzung eines größeren Gebietes. Im Prinzip ja, halte ich aber nicht für durchsetzbar da schlagartig alle Anwendungen entsprechend umgestellt werden müssten. Martins Vorschlag kann dagegen fliessend umgesetzt werden Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: Am 18. Mai 2011 12:56 schrieb Martin Simongrenzde...@gmail.com: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. Aufgabe an gelangweilte Programmierer (falls es solche gibt): Tool, das genau das Problem löst: Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von dessen width-Tag aus. ;) Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Garry schrieb am 18.05.2011 11:30: Gerade landuse=rail (ebenso highway, insbesondere motorway/trunk) sollte kein inner einer Waldfläche sein sondern eine Trennfläche zwischen zwei einzelnen in sich geschlossenene Waldpolygonen ohne gemeinsamen nodes. U.a. würde sonst ein spätere Detailverfeinerung unnnötig kompliziert werden. Im Prinzip bin ich bei dir. In dem fraglichen Fall hier ist aber nicht Bahnstrecke entlang das landuse eingetragen worden, sondern nur das Bahnhofsgelaende (schaetze ich mal). Und Schritt 1 waere sicherlich erstmal, das man den Konflikt zwischen den beiden ueberlappenden Nutzungen aufloest. Ich selber wuerde auch eher den Wald entlang der Bahnstrecke teilen, da ich auch alles andere als ein Freund von multipolygon-Relationen bin. Denn schliesslich haben wir hier ja mal wieder einen der vielen Faelle, wo die Relation die Mapper ueberfordert hat. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18. Mai 2011 14:38 schrieb Peter Wendorff wendo...@uni-paderborn.de: Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. Aufgabe an gelangweilte Programmierer (falls es solche gibt): Tool, das genau das Problem löst: Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von dessen width-Tag aus. ;) Während das noch einfach ist, löst es doch das Problem nicht (oder nur dann, wenn es auch eine Straße einen Weg dort gibt, und der auch regelmäßig wie mit dem Lineal gezogen ist, es also keine Büsche und Bäume, Gräben und Feuchtgebiete gibt, und auch keine Flüsse und Bäche, deren Ufer nicht gemappt sind, und keine Sandflächen und Brachen und keine steilen Stellen, keinen Fels und wenn die Leute, die den Landuse taggen sowie die, die danach dort was mappen, konsequent alles, was nicht dieser Landuse ist, per Multipolyon ausschließen.). Ist mir ehrlich gesagt zu pauschal/approssimativ, fehleranfällig und steril. Man verliert halt praktisch sämtliche topographischen Eigenheiten des Gebiets. Eine schöne Karte sieht für mich anders aus. Gute Daten (vor allem auch stabile, die man einfach verändern/verfeinern kann, und die die Flächennutzung auch quantitativ wiedergeben, und nicht nur visuell solange die Renderreihenfolge nicht geändert wird), sehen m.E. auch anders aus. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18.05.2011 14:38, schrieb Peter Wendorff: Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: Am 18. Mai 2011 12:56 schrieb Martin Simongrenzde...@gmail.com: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. Aufgabe an gelangweilte Programmierer (falls es solche gibt): Tool, das genau das Problem löst: Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von dessen width-Tag aus. ;) Gut dass Du den Smiley nicht vergessen hast. Dass kann man als Notlösung dort machen wo die Daten noch nicht besser sind. Markante Konturen gehen so verloren da sich bestenfalls der minimale, aber nie der reale Abstand zwischen Fahrbahn und Waldgrenze angeben lässt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 18.05.2011 17:44, schrieb M∡rtin Koppenhoefer: Während das noch einfach ist, löst es doch das Problem nicht (oder nur dann, wenn es auch eine Straße einen Weg dort gibt, und der auch regelmäßig wie mit dem Lineal gezogen ist, es also keine Büsche und Bäume, Gräben und Feuchtgebiete gibt, und auch keine Flüsse und Bäche, deren Ufer nicht gemappt sind, und keine Sandflächen und Brachen und keine steilen Stellen, keinen Fels und wenn die Leute, die den Landuse taggen sowie die, die danach dort was mappen, konsequent alles, was nicht dieser Landuse ist, per Multipolyon ausschließen.). Ist mir ehrlich gesagt zu pauschal/approssimativ, fehleranfällig und steril. Man verliert halt praktisch sämtliche topographischen Eigenheiten des Gebiets. Eine schöne Karte sieht für mich anders aus. Gute Daten (vor allem auch stabile, die man einfach verändern/verfeinern kann, und die die Flächennutzung auch quantitativ wiedergeben, und nicht nur visuell solange die Renderreihenfolge nicht geändert wird), sehen m.E. auch anders aus. +1 Sehr gut die Problematik beschrieben! Gruss Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Hallo, ich benutze die OSM vor allem beim Geocaching, versuche aber auch mein Scherflein zum Mapping beizutragen. Aus den hinlänglich bekannten Gründen mußte ich eine Alternative zur bis dahin von mir bevorzugten AIO suchen, und habe jetzt die routable Deutschland-Karte von Computerteddy und die SRTM-DE von Ralf Kleineisel auf dem Oregon. Mir ist im Gelände aufgefallen, daß z.B. die Lienewitzseen (N52.312, E12.974) in der Kleineisel-Karte nicht dargestellt wird, aber in der Computerteddy-Karte. (Die kurze Verbindung zwischen beiden Seen ist in beiden Karten sichtbar.) Etwas Ähnliches findet sich zwischen Emstal und Rädel (N52.297, E12.759), auch dieser See ist nur auf einer der beiden Karten dargestellt. (Mit der originalen AIO kann ich gerade nicht vergleichen.) Gemeinsam scheint beiden Fällen zu sein, daß die Wasserfläche innerhalb einer NR liegt. Die auf www.openstreetmap.org verfügbaren Renderer stellen die Seen dar. Mir ist klar, daß bei den anderen funktioniert es doch kein besonders wertvolles Kriterium ist, aber doch ein Hinweis, daß es Interpretations- spielräume gibt (die für den Anwender möglicherweise unerfreulich sind). Als ein erstes Feedback kam der Hinweis, daß solche Fälle als Multipolygon zu erfassen seien - dabei sehe ich jedoch das Problem, daß der Mapper möglicherweise gar nicht wahrnimmt, daß er sich innerhalb einer NR-Fläche bewegt... Was tun? Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 17. Mai 2011 11:00 schrieb Steffen Grunewald steffen.grunew...@gmx.net: Als ein erstes Feedback kam der Hinweis, daß solche Fälle als Multipolygon zu erfassen seien - dabei sehe ich jedoch das Problem, daß der Mapper möglicherweise gar nicht wahrnimmt, daß er sich innerhalb einer NR-Fläche bewegt... M.E. ist ein Multipolygon dann richtig, wenn der See ausdrücklich nicht Teil des Naturschutzgebiets ist. Ansonsten ist dieses Mapping falsch, weil man ja den See damit ausschließen würde, obwohl es eigentlich Teil des Schutzgebiets ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 17.05.2011 11:00, schrieb Steffen Grunewald: [...] Was tun? Die Darstellung der Karten anpassen, bzw. dem Autor Bescheid geben, was klemmt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 17.05.2011 11:17, schrieb M∡rtin Koppenhoefer: Am 17. Mai 2011 11:00 schrieb Steffen Grunewaldsteffen.grunew...@gmx.net: Als ein erstes Feedback kam der Hinweis, daß solche Fälle als Multipolygon zu erfassen seien - dabei sehe ich jedoch das Problem, daß der Mapper möglicherweise gar nicht wahrnimmt, daß er sich innerhalb einer NR-Fläche bewegt... M.E. ist ein Multipolygon dann richtig, wenn der See ausdrücklich nicht Teil des Naturschutzgebiets ist. Ansonsten ist dieses Mapping falsch, weil man ja den See damit ausschließen würde, obwohl es eigentlich Teil des Schutzgebiets ist. +1 Die Darstellung ist eine andere Sache, und da würde ich sagen, sollten Naturschutzgebiete so gestaltet sein, dass sie andere Signaturen nicht (komplett) verdecken, da ein Naturschutzgebiet immer ZUSÄTZLICH zur vorhandenen Landschaft existiert - sei es Wiese, Wald, Moor, Industriebrache oder eben auch ein See. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 17.05.2011 11:00, schrieb Steffen Grunewald: Mir ist klar, daß bei den anderen funktioniert es doch kein besonders wertvolles Kriterium ist, aber doch ein Hinweis, daß es Interpretations- spielräume gibt (die für den Anwender möglicherweise unerfreulich sind). Als ein erstes Feedback kam der Hinweis, daß solche Fälle als Multipolygon zu erfassen seien - dabei sehe ich jedoch das Problem, daß der Mapper möglicherweise gar nicht wahrnimmt, daß er sich innerhalb einer NR-Fläche bewegt... Ich versuche immer Multipolygone bei Waldflächen zu vermeiden - eben aus dem Problem heraus dass manche Renderer damit nicht umgehen können und dann alles unter der umhüllenden Waldfläche verschwindet was nur durch die Multipolygone herausgeschnitten wurde.Dass dies auch bei NR-Flächen der Fall ist war mir bisher unbekannt. . Garry Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Steffen Grunewald schrieb am 17.05.2011 11:00: Als ein erstes Feedback kam der Hinweis, daß solche Fälle als Multipolygon zu erfassen seien - dabei sehe ich jedoch das Problem, daß der Mapper möglicherweise gar nicht wahrnimmt, daß er sich innerhalb einer NR-Fläche bewegt... Was tun? Bei den Lienewitzseen ist es schon in Ordnung so, dass das Naturschutzgebiet und die Seen nicht gemeinsam in einem Multipolygon stecken, denn schliesslich gelten auf der Ueberschneidungsflaeche ja beide Eigenschaften. Das scheint also ein Problem der Kartendarstellung zu sein. Nicht ganz sauber ist allerdings das Multipolygon 8794: - Zwei jeweils geschlossenen, aneinandergrenzende outer-Mitglieder sind unnötig kompliziert, da sollte man lieber zwei Relationen draus machen. (In diesem Fall braucht der Weg 9719294 nicht mal ein Multipolygon sein, z.Z. gibt es da drin keine inner-Mitglieder.) - Mehrere Flaechen innerhalb des Multipolygons sind nicht als inner-Mitglieder eingetragen, obwohl sie nicht zur Waldflaeche dazugehoeren (z.B. Weg 53389956 landuse=rail oder Weg 47046253 landuse=commerial). Das sollte aber eigentlich nichts mit der Darstellung der Seen auf der Garmin-Karte zu tun haben, auf meiner selbstgebauten Garmin-Karte sind sie naemlich zu sehen (im Gegensatz zur Bahnflaeche oder dem Gewerbegebiet, die vom Wald ueberdeckt werden). Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
