Re: [Talk-de] Blaue Tiles
[EMAIL PROTECTED] schrieb: ich sehe ab und an einige komplett blau eingefärbte Tiles, die aber kein Wasser sind. http://www.informationfreeway.org/?lat=53.92890579295933lon=10.780846910108737zoom=13layers=B000F000 http://www.informationfreeway.org/?lat=53.92890579295933lon=10.780846910108737zoom=13layers=B000F000 Wie kann man das ändern? Liegt das an einem 'Loch' im See oder in der Riverbank? Wer hat denn da wieder dran rumgebastelt? Ich hab doch erst vor ca. einer Woche die gesamt Nord- und Ostseeküste in Ordnung gebracht. :-/ Das Problem liegt meist an unvollständigen Riverbanks. Die sollten nur an einer Stelle offen sein (U-Form), damit der Renderer sie erkennt. Thomas -- signature: http://nospam.nowire.org/signature_usenet.png ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
Ich war's nicht Aber ich hatte vor ca. 1 Jahr die Küstenlinie dahingehend abgearbeitet, dass ich gecheckt hatte, das keine Löcher vorhanden sind. Ausserdem mache ich die Riverbanks nicht U-förmig, sondern hänge immer die 2 gegenüberliegenden Seiten zu einem Way zusammen. Der Schluß des U ist dann an der Stelle, wo der Fluss zu klein wird und ein einfacher Strich reicht. Das funktioniert doch auch, oder? Und ich finde an der besagten Stelle auch kein Loch in den Riverbanks. Und wie macht man nun 'ne blaue Tile weiss? Grüße Cor On 8/1/07, Thomas Krüger [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] schrieb: ich sehe ab und an einige komplett blau eingefärbte Tiles, die aber kein Wasser sind. http://www.informationfreeway.org/?lat=53.92890579295933lon=10.780846910108737zoom=13layers=B000F000 http://www.informationfreeway.org/?lat=53.92890579295933lon=10.780846910108737zoom=13layers=B000F000 Wie kann man das ändern? Liegt das an einem 'Loch' im See oder in der Riverbank? Wer hat denn da wieder dran rumgebastelt? Ich hab doch erst vor ca. einer Woche die gesamt Nord- und Ostseeküste in Ordnung gebracht. :-/ Das Problem liegt meist an unvollständigen Riverbanks. Die sollten nur an einer Stelle offen sein (U-Form), damit der Renderer sie erkennt. Thomas -- signature: http://nospam.nowire.org/signature_usenet.png ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
[EMAIL PROTECTED] schrieb: Ich war's nicht Aber ich hatte vor ca. 1 Jahr die Küstenlinie dahingehend abgearbeitet, dass ich gecheckt hatte, das keine Löcher vorhanden sind. Ausserdem mache ich die Riverbanks nicht U-förmig, sondern hänge immer die 2 gegenüberliegenden Seiten zu einem Way zusammen. Der Schluß des U ist dann an der Stelle, wo der Fluss zu klein wird und ein einfacher Strich reicht. Das funktioniert doch auch, oder? Und ich finde an der besagten Stelle auch kein Loch in den Riverbanks. Die Riverbanks dort sind halt nicht U-förming. Ich habe letztens ca. 3h experimentiert, um den Peenestrom, das Achterwasser und die Küstenlinie von Usedom hinzubekommen, auch wenn es noch nicht ganz fertig ist, sieht es jetzt schon VIEL besser aus. Der Durchbruch gelang mir als ich das Achterwasser komplett geschlossen hatte. Es wurde plötzlich richtig gerendert. Es blieb auch so, wenn eine Stelle offen war (zwischen dem ersten und dem letzen Node. Mit zwei offenen Stellen ging es wieder schief. Danach hab ich alle Gewässer immer so eingetragen, dass sie nur eine offene Stelle hatten, das war dann immer der Übergang zum angrenzenden Stück. Thomas -- signature: http://nospam.nowire.org/signature_usenet.png ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
Thomas Krüger schrieb: Das Problem liegt meist an unvollständigen Riverbanks. Die sollten nur an einer Stelle offen sein (U-Form), damit der Renderer sie erkennt. Ja die lieben Riverbanks... So ganz begriffen habe ich es noch nicht. Ursprünglich wurden meine ersten Versuche korrekt gerendert, dann habe ich versehenltich das JOSM-Validator-Plugin die bemängelten unordered ways fixen lassen und seitdem bringe ich das nicht mehr so hin, wie es sein sollte. Siehe hier: http://www.informationfreeway.org/?lat=47.6826lon=8.61612zoom=14layers=B000F000 Nach meinen Erkenntnissen müsste eine Korrekte Riverbank so aussehen: o-(3)-o---(2)---o--(1)---o Flussrichtung o--(4)o(5)--o---(6)--o Das alles in einem Ways mit den Tags waterway=riverbank. Nun zu meinen Fragen: o Ist das oben so korrekt? o Müssen beide Ufer gleich viele Segmente umfassen? o Spielt die Richtung eine Rolle, um z.B. die korrekte Flussrichtung zu erfassen? o JOSM bemängelt fälschlicherweise das als unordered way (dann werde ich das auf die Wishlist setzen) Gruess, Andy signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
Hallo, Nach meinen Erkenntnissen müsste eine Korrekte Riverbank so aussehen: Es gibt keine korrekte Riverbank, es gibt nur lauter haessliche Workarounds, die zufaellig in vielen Faellen funktionieren. So, wie Du es gemacht hast, funktioniert es einigermassen - ist m.E. das beste, was derzeit moeglich ist (obwohl ich selbst es bevorzuge, meinen Fluss in viele kleine einzelne abgeschlossene Flaechen aufzuteilen, so dass ich keinerlei Warnungen erhalte (siehe z.B. den Rhein bei Karlsruhe), aber das ist nicht weniger krank, nur anders). Das ganze Konzept von grossen Flaechen ist derzeit nicht richtig durchdacht und auch sehr zweckorientiert (naemlich: wie sieht es auf der Karte ok aus). o Müssen beide Ufer gleich viele Segmente umfassen? Das ist egal. o Spielt die Richtung eine Rolle, um z.B. die korrekte Flussrichtung zu erfassen? Es ist im Prinzip egal, aber es waere im Hinblick auf eventuelle spaetere Aenderungen sinnvoll, sich an die Regel Wasser ist immer auf der rechten Seite des Segments zu halten. Die Flussrichtung sollte nicht durch die Riverbank, sondern durch eine *zusaetzlich* in der Mitte des Flusses verlaufende waterway=river-Linie festgelegt werden. o JOSM bemängelt fälschlicherweise das als unordered way (dann werde ich das auf die Wishlist setzen) Der Way ist nicht unordered, aber non-contiguous; beides ist problematisch, wenn wir mal auf Ways bestehen nur aus Nodes umstellen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
Habe schnell ein Experiment bezgl. Rendern gemacht: Auf welcher Seite das Wasser liegt ist eigentlich egal. Absolut wichtig ist das die Ways gegenläufig sind (und das wird scheints von den automatischen Fehlerkorrekturen geändert). Die Regel Wasser 'immer rechts' ist sicher sinnig. On 8/1/07, Frederik Ramm [EMAIL PROTECTED] wrote: Hallo, Nach meinen Erkenntnissen müsste eine Korrekte Riverbank so aussehen: Es gibt keine korrekte Riverbank, es gibt nur lauter haessliche Workarounds, die zufaellig in vielen Faellen funktionieren. So, wie Du es gemacht hast, funktioniert es einigermassen - ist m.E. das beste, was derzeit moeglich ist (obwohl ich selbst es bevorzuge, meinen Fluss in viele kleine einzelne abgeschlossene Flaechen aufzuteilen, so dass ich keinerlei Warnungen erhalte (siehe z.B. den Rhein bei Karlsruhe), aber das ist nicht weniger krank, nur anders). Das ganze Konzept von grossen Flaechen ist derzeit nicht richtig durchdacht und auch sehr zweckorientiert (naemlich: wie sieht es auf der Karte ok aus). o Müssen beide Ufer gleich viele Segmente umfassen? Das ist egal. o Spielt die Richtung eine Rolle, um z.B. die korrekte Flussrichtung zu erfassen? Es ist im Prinzip egal, aber es waere im Hinblick auf eventuelle spaetere Aenderungen sinnvoll, sich an die Regel Wasser ist immer auf der rechten Seite des Segments zu halten. Die Flussrichtung sollte nicht durch die Riverbank, sondern durch eine *zusaetzlich* in der Mitte des Flusses verlaufende waterway=river-Linie festgelegt werden. o JOSM bemängelt fälschlicherweise das als unordered way (dann werde ich das auf die Wishlist setzen) Der Way ist nicht unordered, aber non-contiguous; beides ist problematisch, wenn wir mal auf Ways bestehen nur aus Nodes umstellen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de -- --- Prof. Dr. Cor de Wit An der Falkenwiese 13 23564 Lübeck 0451 300 2630 [EMAIL PROTECTED] --- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schrieb: Hallo, ich sehe ab und an einige komplett blau eingefärbte Tiles, die aber kein Wasser sind. http://www.informationfreeway.org/?lat=53.92890579295933lon=10.780846910108737zoom=13layers=B000F000 Wie kann man das ändern? Liegt das an einem 'Loch' im See oder in der Riverbank? Sowas kann passieren wenn das Tile in der oceantiles_12.dat als coast oder sea markiert ist, und das Binnengewässer von natural=coastline auf natural=water umgestellt wird, oder wenn die Coastline unterbrochen wird, oder die Regel Wasser immer rechts vom Segment verletzt wird. Letztere Regel ist nur für natural=coastline bindend. - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsKB7FUbODdpRVDwRAjeEAJ4xzzeDBPXkUmv/0wh+ALeFwnfhqACaA9PB vuLHLj0RjAvURt/Z3YK/DhI= =uthB -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schrieb: Habe schnell ein Experiment bezgl. Rendern gemacht: Auf welcher Seite das Wasser liegt ist eigentlich egal. Absolut wichtig ist das die Ways gegenläufig sind (und das wird scheints von den automatischen Fehlerkorrekturen geändert). Die Regel Wasser 'immer rechts' ist sicher sinnig. Frederik hat den Code in [EMAIL PROTECTED] eingefügt der die coastlines zu sinnvollen (auch gelochten) Flächen zusammenfügt. Es war einmal geplant diese Funktionalität auf andere große Flächen auszuweiten (natural=water, riverbank, aber auch landuse=forest usw.) Leider ist diese Coastline-detection noch auf ein weiteres Datenfile angewiesen, dass sozusagen den Überblick bereitstellt, was denn nun Ozean und was Land darstellt, und wo sich die Küstenlinien befinden. - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsKFNFUbODdpRVDwRAojeAKCoC75e+TmJq+YDAsrm3qB4iwKfegCfelvL EbjzIIwA0Ugr3Yw6LmVmkPc= =7OF0 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flüsse, besonders Elbe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schrieb: Hallo, ich habe mir das nochmal angesehen: Auch ein Teil der Elbmündung (bei Stade) wurde nun nicht mehr richtig gerendert. Das Problem war das an einem Ufer die Richtung der Segmente geändert war. Ich habe das nun wieder verbessert. Ich habe vor einigen Wochen die Elbemündung reparieren müssen. Die Mündung ist so breit, dass sie unbedingt als coastline zu handhaben ist, sonst kommt der Renderer nicht damit klar. (Seit API 0.4 ist das zwar aufgeweicht, weil es reicht, wenn ein node des Ways in der BBox des Tiles liegt, aber die Coastline muss immer noch geschlossen bleiben). Darum folgende Bitte: Nicht an bestehende Flußufern (die korrekt gerendert werden) rumschrauben, wenn man nicht genau weiss, wie man es taggen soll. Folgende Tagging-Rules sind wichtig (nach meiner Erfahrung): 1. An große Flüssen das Ufer markieren, Way generieren und gegenüberliegende Ways zu einem Way zusammenfassen. 2. Das Wasser muss rechts vom Way liegen. D.h. Am rechten Ufer (in Flußrichtung betrachtet) ist die Richtung des Ways stromaufwärts, am linken Ufer ist die Richtung des Ways stromabwärts. Das ist (momentan) nicht zwingend, aber trotzdem eine gute Konvention. 3. Die Sortierung der Nodes ist wichtig (glaube ich): Der 1. Node liegt demzufolge stromabwärts am rechten Ufer, der letzte Node stromabwärts am linken Ufer. Zur Sortierung kann es hilfreich sein, die beiden Teile des Ways am stromaufwärts gelegenen Ende mit einem Segment zu verbinden, diese Segment in den Way mit aufnehmen, Nodes sortieren. Dann kommt dieses Segment wieder aus dem Way raus und wird gelöscht. 4. Die Validate Funktion erkennt die beiden Teile des Flusses immer als non-ordered Way, obwohl es korrekt gerendert wird. Dies sollte verbessert oder ignoriert werden. Da das im gegenwärtigen Datenmodell nur einen Workaround darstellt würde ich noch vorschlagen das Flussaufwärts (zur Quelle hin) liegende offene Ende des Polygons zu verbinden um eben diese Fehlerkennung zu verhindern. Das Flussabwärtsgerichtete Ende muss in der Mündung als natural=coastline geschlossen werden, damit die Küstenlinie korrekt gerendert werden kann. Fertig ist der Fluß Anmerkung: 1. Das Wasser bei der Küstenlinie liegt auch rechts. 2. Bei einem geschlossenen See (mit natural=water) von geringer Größe ist die Richtung des Ways in Bezug auf das Wasser egal. Es wird immer richtig gerendert. Nach Möglichkeit sollte aber auch hier die Regel Wasser immer rechts angewandt werden, da der Renderer evtl. auf solche Bereiche ausgeweitet wird, und Flächen evtl. als gerichtet definiert werden, d.h. eine Fläche, die im Uhrzeigersinn geschlossen ist ist innen gefüllt, eine Fläche gegen den Uhrzeigersinn ist innen leer (und füllt nach aussen), bzw ist ein Loch in der im Uhrzeigersinn verlaufenden Fläche. Bis jetzt wird aber jede Fläche innen gefüllt solange noch keine speziellen Regeln existieren (wie für natural=coastline) - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsKU/FUbODdpRVDwRAglKAKC+/ozuNZlZgEkjigByhCGXI9J99QCg0MNA 96uVaaDmdVozmMM0h2r4Kwc= =jF/Z -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
Hallo Frederik Ramm schrieb: Die Regel Wasser 'immer rechts' ist sicher sinnig. Das hatte ich vorgeschlagen, weil das die Regel fuer natural=coastline ist; hier haben wir einen magischen Mechanismus, der dann dafuer sorgt, dass auch da, wo nur ein Fetzen Coastline im Bild ist, immer das Meer rechts von der Coastline liegt. Danke für die Antworten. Wenn es Glücksache ist, dann werde ich nur noch dafür sorgen dass das Wasser rechts ist und dann das ganze so lassen, was auch immer die Renderer damit so anstellen. Danke noch für den Tip mit dem waterway=river in der Mitte zu lassen, das macht durchaus sinn und damit ist dann auch das mit der Flussrichtung etc. erschlagen. Diese Regel wollen wir vielleicht auch mal fuer andere grosse Flaechen, z.B. den Bodensee ;-) einbauen. Gute Idee. Der sieht teilweise ein wenig zerklüftet aus. Gruess, Andy signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flüsse, besonders Elbe
Noch ein Kommentar: Da das im gegenwärtigen Datenmodell nur einen Workaround darstellt würde ich noch vorschlagen das Flussaufwärts (zur Quelle hin) liegende offene Ende des Polygons zu verbinden um eben diese Fehlerkennung zu verhindern. Dann sollte man darauf achten, dass in der Mitte des Flusses noch ein Node eingefügt wird, um den waterway=river sauber hindurchzuführen, so dass das Validation Tool nicht immer meckert, dass sich ways kreuzen Grüße Cor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flüsse, besonders Elbe
Nach Möglichkeit sollte aber auch hier die Regel Wasser immer rechts angewandt werden, da der Renderer evtl. auf solche Bereiche ausgeweitet wird, und Flächen evtl. als gerichtet definiert werden, d.h. eine Fläche, die im Uhrzeigersinn geschlossen ist ist innen gefüllt, eine Fläche gegen den Uhrzeigersinn ist innen leer (und füllt nach aussen), bzw ist ein Loch in der im Uhrzeigersinn verlaufenden Fläche. Bis jetzt wird aber jede Fläche innen gefüllt solange noch keine speziellen Regeln existieren (wie für natural=coastline) Dann könnte man ja die Inseln (zB in der Elbe) anders rum drehen und zusätzlich mit Coastline taggen? Ich probiere das mal. Danke jedenfalls für Deine Kommentare. Cor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flüsse, besonders Elbe
Dirk-Lüder Kreie schrieb: Die richtige Methode wäre, beide Flussufer in fließrichtung zu taggen, als getrennte Wege für die Flussufer. Das könnte nur kein Renderer auseinanderhalten. Technisch richtig wäre es Flüße als vollständige Polygone darzustellen, nicht als reine Uferlinie, oder offene Ways (Polylines) , das wäre auch perfekt für den Renderer. Die U-Lösung ist ein aber ein guter Kompromiss, da Polygone beim Zeichen in den meisten Programmen zuwieso vom letzten zum ersten Punkt geschlossen werden. Ganz kann man sie nicht schließen, da die darunterliegenden Segmente Richtungen haben und die Überschneidungen zwischen zwei Teilen des Flußes immer gegenläufig sind. Das geht spätestens nicht mehr, wenn sich ein Fluß trennt und später wieder zusammenfließt (z.B. Norderlbe/Süberelbe). Thomas -- signature: http://nospam.nowire.org/signature_usenet.png ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flüsse, besonders Elbe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schrieb: Area gebe ich Dir recht, aber riverbanks sind ja ways. Ich mache es nämlich u-förmig, wobei das geschlossene Ende zur Quelle zeigt. Mehrere solcher Us geben dann den Fluß. Richtig schliessen werde ich es nur an der definitven Mündung. Nein, es sind weder das eine noch das andere. Für den Renderer sind es Areas. Dass das letzte Segment fehlt liegt daran, dass man nicht 2 entgegengesetzt zeigende Segmente zwischen zwei Nodes erzeugen kann (soll). Die Area wird letztlich durch den Renderer geschlossen. Riverbank ist ein recht übler workaround dafür, dass Flüsse recht unhandliche Gebilde abgeben. Eine Erweiterung des Coastline-Algorithmus würde hier viel helfen, allerdings auch viel Arbeit verursachen, weil viele Flüsse eben nicht nach der Regel Wasser rechts erzeugt wurden. Andererseits würde der Zwang beide Flussufer in einen Way zu tun verschwinden und damit auch das Riverbank segment, dass eigentlich kein Flussufer darstellt, sondern nur die verschiedenen Editoren mit ihren Validationsfunktionen zufriedenstellt. Die richtige Methode wäre, beide Flussufer in fließrichtung zu taggen, als getrennte Wege für die Flussufer. Das könnte nur kein Renderer auseinanderhalten. Nie nächstbeste wäre, die Flussufer immer noch als getrennte Wege aber eben mit Wasser rechts zu erzeugen, damit könnten dann die Renderer (à la coastlines) klarkommen, erfordert aber entsprechenden Code bei den Renderern. Alles andere sind Workarounds, die aber derzeit die gängige Praxis darstellen. - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsOiuFUbODdpRVDwRAvtxAJwJ+KHZeeH8haDndSzagikHXj+OrQCffvLg wWDywQBqx6Zcn2DsH/8aFBs= =eAA/ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flüsse, besonders Elbe
Area gebe ich Dir recht, aber riverbanks sind ja ways. Ich mache es nämlich u-förmig, wobei das geschlossene Ende zur Quelle zeigt. Mehrere solcher Us geben dann den Fluß. Richtig schliessen werde ich es nur an der definitven Mündung. Cor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flüsse, besonders Elbe
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] schrieb: Dann sollte man darauf achten, dass in der Mitte des Flusses noch ein Node eingefügt wird, um den waterway=river sauber hindurchzuführen, so dass das Validation Tool nicht immer meckert, dass sich ways kreuzen Das halte ich für einen Bug im Validation Tool: Ein Way sollte eine Area ohne Intersection Node kreuzen dürfen. - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsOTFFUbODdpRVDwRAihpAJ9tuJ7n9xOdAZKH6NHSaSUAxSg/XwCgvVl3 RWsqkk/fLx/FVCT0gDTFFHs= =pJV9 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Blaue Tiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Stricker schrieb: Diese Regel wollen wir vielleicht auch mal fuer andere grosse Flaechen, z.B. den Bodensee ;-) einbauen. Gute Idee. Der sieht teilweise ein wenig zerklüftet aus. Die Kanadier taggen ihre großen Seen deswegen schon als coastline evtl. sollten wir überlegen, ob es nicht sinn macht diese Regel möglichst früh einzuführen. Einziges Problem hierbei: wir bräuchten wohl analog zu den oceantiles_12.dat Hintfiles für Wasser im Allgemeinen, und dann auch für jede andere Fläche die wir in diesen Mechanismus mit aufnehmen wollen. - -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGsOVxFUbODdpRVDwRAuXwAKCCoAMxfJIarOAkN4h68u0bVKUeIgCgp0yB 6jBCrKHlY6g5oIeG3AZzRtY= =1uAE -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Gebirgspass
Ich dachte an die Passhoehe. Analog zu natural=peak, nur eben fuer Passhoehe und nicht Bergspitze. natural=pass elevation=1948 name=Klausenpass Tönt sinvoll, mach doch ein Proposed Feature draus. Wobei ich dachte, dass es bereits ein tag für elevation gibt, aber habs grad nicht gefunden. Wenn straßen oder wege ein gewisses gefälle haben (ab ca. 5%), sollten wir die höhe alle ca 2-300m taggen. Für fahrrad oder wanderrouten sind diese höhenangaben sehr relevant, wie wir alle wissen. Offiziell soll man wohl nur allgemein steigung bzw. gef#257;lle taggen, weil an derartigen stellen mit langsamfahrenden Lkw zu rechnen sei. Das ist aber zu allgemein und zu sehr auf den motorisierten verkehr ausgerichtet. Leider zeigt josm die höhenangaben an, die in meinen gpx-tracks sind. Gibt es dafür vielleicht ein plugin? Soweit ich weiss, werden Höhenangaben absichtlich nicht prioritär behandelt. Zum einen weil die Höhenangaben vom GPS weniger genau sind als Länge und Breite. Zum anderen, weil diese Höhenangaben automatisiert von einem Projekt (NASA oder so) abgezogen werden können. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Almhütten-Tag
Hi, Was muss man tun, um den Tag offiziell zu machen? ich finde gerade auf den Vorschlagsseiten folgenden Tag, den ich sogar selbst schonmal für eine Schutzhütte verbraten hatte: mountain hut/refuge Siehe http://wiki.openstreetmap.org/index.php/Proposed_features/Piste_Maps Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
