[Talk-de] GPS--EXIF
Hallo, Will mir gerade ein Equipment zusammenstellen, tendiere da zu einem Nokia E51 mit Wintec201. Frage ist nun, ob das E51 auch die GPS-Daten in die EXIF der Fotos mit hineinschreibt. Hat da jemand Erfahrung? Gruß, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Am Mittwoch, 4. Juni 2008 schrieb Frank Wein: Allerdings hat JOSM bemängelt, dass es sich dabei um overlapping ways handelt, da ich die selben Nodes für das Gebäude und die area verwende. Stimmt diese Meldung und ich sollte das nicht machen oder ist das bei einer area egal? Ok, ich muss zugeben es könnte schwieriger werden danach etwas am Gebäude oder der area zu ändern. Wie sieht es aus wenn die area an einer Straße endet, ist ja im Prinzip das gleiche Problem? Kann man die Nodes der Straße mitverwenden oder sollte man das lieber lassen? Soweit ich das Prinzip verstehe, sollte man Nodes wiederverwenden, wenn es die Realität abbildet. Also ein Platz grenzt an eine Straße, ein landuse=residetial geht bis zu einer Straße und ähnliches. Bedenkte bitte, dass du eine Strasse in der Mitte Mappst und nicht am Rand. Wenn du somit die Nodes wieder verwendest würdest du den Rand des Platzes in die Mitte der Strasse verlegen. Der Validator macht in diesem Punkt IMHO einfach Mist bzw. wurde diesbezüglich nicht (wirklich) auf API 0.5 umgestellt. Der Validator macht somit keinen Mist. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Soweit ich das Prinzip verstehe, sollte man Nodes wiederverwenden, wenn es die Realität abbildet. Also ein Platz grenzt an eine Straße, ein landuse=residetial geht bis zu einer Straße und ähnliches. Bedenkte bitte, dass du eine Strasse in der Mitte Mappst und nicht am Rand. Wenn du somit die Nodes wieder verwendest würdest du den Rand des Platzes in die Mitte der Strasse verlegen. Das widerrum finde ich eine nicht zutreffende Aussage. Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Ich stelle mal die zwei Haupt-Gründe für mein Vorgehen vor und warte auf tiefgründige Antworten: 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Der Validator macht in diesem Punkt IMHO einfach Mist bzw. wurde diesbezüglich nicht (wirklich) auf API 0.5 umgestellt. Der Validator macht somit keinen Mist. IMHO schon. :) Der Validator beschwert sich über jegliche Art von overlapping ways, egal für wechen Zweck. Oder willst du ernsthaft sagen, dass es nie sinnvoll ist, Nodes wiederzuverwenden? Gruß, Bernd -- Schlechter Geschmack ist kein Privilleg des Alters. - Oliver Kalkofe signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS--EXIF
Hallo Arne. Das noch, dann bin ich auch ruhig. ;-) Am Donnerstag, 5. Juni 2008 schrieb Arne Bischoff: Will mir gerade ein Equipment zusammenstellen, tendiere da zu einem Nokia E51 mit Wintec201. Nur damit du da nichts verwechselst: Der Wintec 201 zeichnet auch selbst auf. Wenn du mit dem Handy aufzeichnen willst, das also immer dabei haben willst, dann reicht ein Bluetooth-GPS (blumax oder ähnliches) für 40 €. Frage ist nun, ob das E51 auch die GPS-Daten in die EXIF der Fotos mit hineinschreibt. Hat da jemand Erfahrung? Wenn du mit dem Wintec aufzeichnest, dann hat das Handy ja erstmal gar keine GPS-Daten, die es speichern könnte. Allerdings würde ich in so ein Setup wenig Energie bzw. Geld reinstecken, da das Abgleichen von Bildern mit GPS-Tracks (Anhand der Zeitstempel) mit sehr einfachen Mitteln nachher am PC geht und es IMHO umständlich ist, das live vor Ort machen zu wollen. Gruß, Bernd -- Die Menschen glauben viel leichter eine Lüge, die sie schon hundertmal gehört haben, als eine Wahrheit, die ihnen völlig neu ist. - Alfred Polgar signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSMTracker und HTC/Xda Orbit kann GPS nicht finden
On Wed, Jun 4, 2008 at 9:00 PM, Plautzenpaule [EMAIL PROTECTED] wrote: Hallo zusammen, vielleicht hatte schon jemad ein ähnliches Problem. Ich habe OSMTracker auf meinem Xda Orbit mit integriertem GPS installiert. Die Installation verlief eigentlich problemlos, nur findet OSMTracker das GPS nicht. Ich verwende die selben Einstellungen, wie bei VisualGPSce, welches erfolgreich GPS findet und Daten aufzeichnet (COM4, 9600. Ich habe auch schon in die config.xml geschaut und manuell die Einstellungen geändert, nichts hilft. Ich hoffe, jemand kann mir helfen? Auf der Wiki Seite (http://wiki.openstreetmap.org/index.php/OSMtracker) dazu steht: Target platform : ...internal gps support not yet... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSMTracker und HTC/Xda Orbit kann GPS nicht finden
Hallo Martin, Auf der Wiki Seite (http://wiki.openstreetmap.org/index.php/OSMtracker) dazu steht: Target platform : ...internal gps support not yet... Das stimmt, aber ich spreche das GPS ja über den COM Port an, so wie die anderen Programme das auch machen. Irgendwo hatte ich gelesen, dass jemand ein Problem beim _gleichzeitigen_ Betrieb von OSMtracker und Glopus hatte, der auch ein XDA benutzt hat. Welches Programm ist denn sonst zu empfehlen, welches auch Waypoints markieren kann? Ich habe jetzt VisualGPSce ausprobiert, was ganz gut läuft, aber das eben nicht beherrscht. Vielen Dank, Christian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Mir fehlen Tags für bestimmte Fläch en, wer kann helfen?
Moin, ich habe da ein paar Probleme mit Flächen, die ich sauber zuordnen möchte. Vielleicht kann mir jemand mal den entscheidenden Tip geben: - unbewirtschaftete Grünflächen (Rasen, Büsche, Bäume, Unkraut)habe ich hier oft und in Größenordnungen landuse=farm passt definitiv nicht, landuse=forest auch nicht könnte man hier natural=scrub nehmen? - vorhandene Industrieruinen im Allgemeinen da fehlt mir generell etwas, historic=ruins ist es sicher nicht - Brachflächen nach Abriss von Industrie, die aber NICHT zur Neubebauung vorgesehen sind landuse=brownfield passt hier nicht, ist das dann auch natural=scrub? Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Routingfaehige Garminkarten
Christoph Eckert [EMAIL PROTECTED] wrote: Auch wenn Du natürlich Recht hast und die Garmins hardwareseitig derzeit das einzige/beste sind was man für den Outdoorbereich haben kann. Das allerdings zu einem echt saftigen Preis. Etrex Legend hat einen Straßenpreis von 180 Euro, ich glaube kaum, dass Du für diesen Preis einen Linux PDA bekommen wirst. Mir sind Geräte mit freier Firmware ebenfalls erheblich lieber als proprietäres Zeug a la Garmin. Fürs Fahrrad sind mir aber andere Dinge wichtiger (Batterielaufzeit, wasserdicht). Schaumermal, vielleicht wird das ja was mit dem OBiCo. Teuer wird der aber auch werden: http://www.obico.de/ Gruss Sven -- The main thing to note is that when you choose open source you don't get a Windows operating system. (from http://www.dell.com/ubuntu) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Soweit ich das Prinzip verstehe, sollte man Nodes wiederverwenden, wenn es die Realität abbildet. Also ein Platz grenzt an eine Straße, ein landuse=residetial geht bis zu einer Straße und ähnliches. Bedenkte bitte, dass du eine Strasse in der Mitte Mappst und nicht am Rand. Wenn du somit die Nodes wieder verwendest würdest du den Rand des Platzes in die Mitte der Strasse verlegen. Das widerrum finde ich eine nicht zutreffende Aussage. Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in der Mitte wie auch am Rand :) Ich stelle mal die zwei Haupt-Gründe für mein Vorgehen vor und warte auf tiefgründige Antworten: 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht nicht berurteilt werden. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Es kann nicht dein Problem sein wie das ganze gerendert wird. Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht? Ich kann nur nochmal erwähnen dass Strassen eindimensional erfasst werden und Flächen 2 Dimensional nicht. Somit macht es wenig Sin diese zu verbinden. Anders sieht es z.b. bei Grenzen aus, dort kann es durchaus sinvoll sein die Nodes sowohl für die Gesamtortsgrenze (weiss zwar nicht was für ein Tag es dazu gibt), sowie die Grenze für eine landuse=residential Fläche zu nutzen. Wobei ich eher dazu tendieren würde alle Flächen eines Ortes (an die Rechtschreibspezialisten, heisst es Orts oder Ortes?) in eine Relation zu packen. Der Validator macht in diesem Punkt IMHO einfach Mist bzw. wurde diesbezüglich nicht (wirklich) auf API 0.5 umgestellt. Der Validator macht somit keinen Mist. Der Validator beschwert sich über jegliche Art von overlapping ways, egal für wechen Zweck. Oder willst du ernsthaft sagen, dass es nie sinnvoll ist, Nodes wiederzuverwenden? Dies war in keiner Weise meine Aussage. Ich habe nur gesagt, dass Flächen und Strassen nicht die Selben Nodes verwenden sollen. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Am 5. Juni 2008 09:48 schrieb Raphael Studer [EMAIL PROTECTED]: Soweit ich das Prinzip verstehe, sollte man Nodes wiederverwenden, wenn es die Realität abbildet. Also ein Platz grenzt an eine Straße, ein landuse=residetial geht bis zu einer Straße und ähnliches. Bedenkte bitte, dass du eine Strasse in der Mitte Mappst und nicht am Rand. Wenn du somit die Nodes wieder verwendest würdest du den Rand des Platzes in die Mitte der Strasse verlegen. Das widerrum finde ich eine nicht zutreffende Aussage. Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in der Mitte wie auch am Rand :) Ich stelle mal die zwei Haupt-Gründe für mein Vorgehen vor und warte auf tiefgründige Antworten: 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht nicht berurteilt werden. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Es kann nicht dein Problem sein wie das ganze gerendert wird. Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht? Ich kann nur nochmal erwähnen dass Strassen eindimensional erfasst werden und Flächen 2 Dimensional nicht. Somit macht es wenig Sin diese zu verbinden. Anders sieht es z.b. bei Grenzen aus, dort kann es durchaus sinvoll sein die Nodes sowohl für die Gesamtortsgrenze (weiss zwar nicht was für ein Tag es dazu gibt), sowie die Grenze für eine landuse=residential Fläche zu nutzen. Wobei ich eher dazu tendieren würde alle Flächen eines Ortes (an die Rechtschreibspezialisten, heisst es Orts oder Ortes?) in eine Relation zu packen. Der Validator macht in diesem Punkt IMHO einfach Mist bzw. wurde diesbezüglich nicht (wirklich) auf API 0.5 umgestellt. Der Validator macht somit keinen Mist. Der Validator beschwert sich über jegliche Art von overlapping ways, egal für wechen Zweck. Oder willst du ernsthaft sagen, dass es nie sinnvoll ist, Nodes wiederzuverwenden? Dies war in keiner Weise meine Aussage. Ich habe nur gesagt, dass Flächen und Strassen nicht die Selben Nodes verwenden sollen. Ich verstehe eure Meinungen und denke ich weiss, wie ihr zu diesen gekommen seit. Meine persönliche Meinung ist, dass mich doppelt benutzte nodes beim Editieren oft sehr stören. Auch sind diese wesentlich anfälliger für Anfängerfehler. Ich bin heilfroh, dass es seit ein paar Wochen das unglue-plugin für JOSM gibt. Wenn ich beim Mappen auf gemeinsam genutzte nodes treffe, dann werden die getrennt. Basta! Bei mir benutzen nur physikalisch verbundene Objekte gemeinsame nodes. Dass können für mich nie Wald+Straße od. See+ Straße sein. Bei Marktplatz + Straße sollte natürlich die angrenzende Straße einen gemeinsamen node mit dem Markt haben. Mein Senf Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in der Mitte wie auch am Rand :) Die Aussage dreht sich im Kreis. Also ich verstehe was du sagen willst. Aber ich sehe keinen Grund, warum eine Quer-Straße, die in eine Straße einmündet etwas anderes sein soll als ein Platz, der an die Straße angrenzt. Denk mal wirklich drüber nach, es ist eigentlich echt kein Unterschied. Eben grade *weil* die Straße (nicht die Einmündende sondern die Ausgangsstraße) nicht zweidimensional erfasst wird. Fall 1: -- - - - - - - - - ---+ +--- | | | | Fall 2: -- - - - - - - - - + +--- | | | | +-+ Für mich sieht die obere Straße auch unterhalb der Mitte noch identisch aus bei beiden Szenarien. Nur der Rand der Straße (der gar nicht erfasst ist) ändert sich. Wenn du den Platz jetzt unabhängig erfassen würdest, wäre das Datenmodell so: -- - - - - - - - - -- +-+ | | | | +-+ Ob es ein Renderer oder ein Navi wäre, der Zusammenhang zwischen Straße und Platz (z.B. Parkplatz) wäre nicht gegeben. Es gibt keinen Anhaltspunkt, dass es hier überhaupt eine Einfahrt in den Platz gibt. Wenn der Platz baulich getrennt ist (Mauer, Grünstreifen, ...), dann ist es natürlich was anderes. Aber das war nicht die Ausgangslage. 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht nicht berurteilt werden. Mag sein, seh ich anders. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Ja, eben drum. Ich weiß ja nicht, wie breit der Renderer die Straße macht. In der Realität würde man sagen: Der Platz schließt sich direkt an die Straße an. Man sagt nicht: Der Platz beginnt 3 Meter vom Mittelpunkt der Straße entfernt. Daher komme ich zu dem Schluß, dass verbundene Elemente für jede Nutzung und für jede Art von Renderer die mir einfällt leichter zu verarbeiten bzw. einzustufen ist. Weil es eine semantische Abbildung ist. Für mich stellt sich die übergeordnete Frage, ob wir Karten mit dem Anspruch auf Vermessungs-Genauigkeit haben wollen (so dass man z.B. Flächen-Größen aus unserem Datenbestand exakt bestimmen kann) oder ob die Karten primär dafür gedacht sein sollen, semantisch die Realität abzubilden damit man einzelne Objekte in Relation zu anderen Objekten setzen kann. Ich sehe unsere gesamte Genauigkeit als so grob an, dass wir ersteren Anspruch niemals erfüllen können. Daher mappe ich semantisch. Sonst müsste man ja auch jede Kurve mit tausenden von Nodes machen, um das genau genug abzubilden. Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht? Wieso sollte das so sein? Flächen verschieben sich nicht einfach so. Also zumindest nicht in der Realität. :) Bei baulichen Veränderungen muss man ggf. die Karte korrigieren, das ist aber logisch. Und ich will ja grade vermeiden, dass Straße und Platz in irgendwelcher Darstellung auseinander gezogen werden obwohl sie in Wahrheit direkt aneinander grenzen. Ich kann nur nochmal erwähnen dass Strassen eindimensional erfasst werden und Flächen 2 Dimensional nicht. Das nicht ist zu viel, oder? ;-) Ich finde nicht, dass das was ändert. Wobei ich eher dazu tendieren würde alle Flächen eines Ortes (an die Rechtschreibspezialisten, heisst es Orts oder Ortes?) in eine Relation zu packen. Man kann laut Duden beides benutzen. ;-) Da stimme ich dir zu. Die Frage von oben ist IMHO aber auch, wie man es z.B. handhabt, wenn eine Straße links Wald und rechts Wohngebiet hat. Für mich ist die Antwort hierrauf die selbe wie für den Platz oben. Ich habe hier sehr viele Stellen, an denen jemand ganz grob den Wald unabhängig von der Straße gezeichnet hat. Das Wohngebiet auf der anderen Seite dann ebenfalls ganz
Re: [Talk-de] Overlapping ways bei einer area
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Torsten Breda: Bei Marktplatz + Straße sollte natürlich die angrenzende Straße einen gemeinsamen node mit dem Markt haben. Das klingt aber schauderhaft. Einen gemeinsamen Node oder alle an denen eine Einfahrt möglich ist? Wenn nur einen, welchen? Nach Zufallsprinzip ausgewählt? Klingt IMHO nicht überzeugend. Vorschlag für neuen Grundsatz: Mappe nicht für die Vermeidung von Anfängerfehlern. ;-)) Gruß, Bernd -- Keine zwei Menschen gleichen einander, und beide sind froh darüber signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSMTracker und HTC/Xda Orbit kann GPS nicht finden
Hallo, ich benutze gpxVP http://gpsvp.garminmapsearch.com/ funktioniert bei mir ganz gut auf meinem Orbit. leider funktionieren bei mir die POI Namen von erstellten OSM - Garminkarten nicht. als dann Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Christian Görs Gesendet: Donnerstag, 5. Juni 2008 09:35 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] OSMTracker und HTC/Xda Orbit kann GPS nicht finden Hallo Martin, Auf der Wiki Seite (http://wiki.openstreetmap.org/index.php/OSMtracker) dazu steht: Target platform : ...internal gps support not yet... Das stimmt, aber ich spreche das GPS ja über den COM Port an, so wie die anderen Programme das auch machen. Irgendwo hatte ich gelesen, dass jemand ein Problem beim _gleichzeitigen_ Betrieb von OSMtracker und Glopus hatte, der auch ein XDA benutzt hat. Welches Programm ist denn sonst zu empfehlen, welches auch Waypoints markieren kann? Ich habe jetzt VisualGPSce ausprobiert, was ganz gut läuft, aber das eben nicht beherrscht. Vielen Dank, Christian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Help! German translation for Potlatch
On Thu, Jun 5, 2008 at 11:11 AM, Claudius Henrichs [EMAIL PROTECTED] wrote: I strongly oppose a multisuer translation as in the result you are likely to end up with different translations for the same term. Better to form a core team of two people dealing with this. Two people who translate a application in every language even if they are no nativ speakers? Isn't this supposed to end up in something like Stecke Nippel A von durch Lasche in Gegenseite? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Also ich verstehe was du sagen willst. Aber ich sehe keinen Grund, warum eine Quer-Straße, die in eine Straße einmündet etwas anderes sein soll als ein Platz, der an die Straße angrenzt. Denk mal wirklich drüber nach, es ist eigentlich echt kein Unterschied. Ich glaub ich hab schon wirklich darüber nachgedacht, mit dem Resultat dass eine Strasse und ein Platz nicht das Selbe sind :) Ob es ein Renderer oder ein Navi wäre, der Zusammenhang zwischen Straße und Platz (z.B. Parkplatz) wäre nicht gegeben. Es gibt keinen Anhaltspunkt, dass es hier überhaupt eine Einfahrt in den Platz gibt. Wenn der Platz baulich getrennt ist (Mauer, Grünstreifen, ...), dann ist es natürlich was anderes. Aber das war nicht die Ausgangslage. Ich würde auch wenn der Platz baulich nicht getrennt ist, nur einen einzigen Weg zwischen Strasse und Platz markieren, damit ein Navi erkennen könnte dass man auf den Platz fahren kann. Weiter wärs wahrscheinlich auch nicht Tragisch wenn einem das Navi nur vor den Platz lotst und nicht direkt darauf. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Ja, eben drum. Ich weiß ja nicht, wie breit der Renderer die Straße macht. In der Realität würde man sagen: Der Platz schließt sich direkt an die Straße an. Man sagt nicht: Der Platz beginnt 3 Meter vom Mittelpunkt der Straße entfernt. Ich denke man sagt: Der Platz ist neben der Strasse. Für mich stellt sich die übergeordnete Frage, ob wir Karten mit dem Anspruch auf Vermessungs-Genauigkeit haben wollen (so dass man z.B. Flächen-Größen aus unserem Datenbestand exakt bestimmen kann) oder ob die Karten primär dafür gedacht sein sollen, semantisch die Realität abzubilden damit man einzelne Objekte in Relation zu anderen Objekten setzen kann. Ich sehe unsere gesamte Genauigkeit als so grob an, dass wir ersteren Anspruch niemals erfüllen können. Daher mappe ich semantisch. Sonst müsste man ja auch jede Kurve mit tausenden von Nodes machen, um das genau genug abzubilden. Ich sehe auch, dass wir den zweiten Anspruch erfüllen sollten. Daher hat die Strasse und der Platz auch nur eine einzige Verbindung :). Teilen sich Platz und Strasse die Nodes, wäre die Strasse ja ein Teil des Platzes, was IMOH nicht der Fall ist. Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht? Wieso sollte das so sein? Flächen verschieben sich nicht einfach so. Also zumindest nicht in der Realität. :) Bei baulichen Veränderungen muss man ggf. die Karte korrigieren, das ist aber logisch. In meiner Realität verschieben sich Flächen. z.B. ändert sich die Fläche des Bodensees laufend. Oder die Fläche von Indien schiebt sich laufend Richtung Fläche von Russland, so dass diese immer kleiner (und höher) wird. Die Frage von oben ist IMHO aber auch, wie man es z.B. handhabt, wenn eine Straße links Wald und rechts Wohngebiet hat. Für mich ist die Antwort hierrauf die selbe wie für den Platz oben. Ich habe hier sehr viele Stellen, an denen jemand ganz grob den Wald unabhängig von der Straße gezeichnet hat. Das Wohngebiet auf der anderen Seite dann ebenfalls ganz grob frei Hand. Die Ways schneiden sich in den OSM-Daten vor allem in Kurven recht unkoordiniert und dass das in der Karte nachher nicht scheisse aussieht liegt nur daran, dass der Renderer der Straße eine gewisse Breite gibt, sodass beide Flächen auf dem Bild nachher genau an die Straße angrenzen. Dein Beispiel find ich sehr gut. Wenn jetzt die der Wald, die Strasse und das Wohngebiet die selben Nodes teilen, heisst dies dass das Wohngebiet DIREKT neben den Wald ist. Die Strasse in der Mitte könnte also gar nicht vorhanden sein. Dass sich die Ways schneiden ist natürlich nicht wünschenswert. Da ist jedoch etwas mehr Disziplin des Bearbeitenden gewünscht. Oder der Editor sollte deutlicher darauf aufmerksam machen, dass hier eventuell ein Fehler vorliegt. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Help! German translation for Potlatch
I strongly oppose a multisuer translation as in the result you are likely to end up with different translations for the same term. Better to form a core team of two people dealing with this. That's the way I'm working on the localisation at Skype as well. I'd like to do the Potlatch translation into german. Anyone else with l10n experience/Noch jemand mit Übersetzungserfahrung? Regards, /Claudius/ Torsten Breda: 2008/6/5 Fabian -Patzi- Patzke [EMAIL PROTECTED]: Oscar Knapp schrieb: Hi Richard, I'm interested in doing some of the translations. I'd suggest to open a new page in the OSM Wiki containing the english source to be translated - so everyone will be able to contribute to this. Discussions whether a specific translation is adequate could be held on the discussion page. Hi, i'd like to contribute my part to the translation. As Oscar said, some kine of multiuser translation would be very handsome, so many users could help and the work need not be done by only one person. So if there is some kind of multiuser thing count me in. Yes, a translation on a wiki page would be good. Just post the english language file, when you have it completed. (Don't know if it already exists, or has to be generated) If there is a char-limit for some fields, then this would be interesting too, because words are normaly longer in german. An information about the context of the words to be translated could be useful. E.g the word play could mean spielen, herumspielen, ausprobieren... I think, a translation of potlatch is the right step to make it more usable to newbies and could prevent errors when editing. Do you want to implement a translation for the tags also? Greets Torsten Breda ___ 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] Tag für P+R Parkplatz
Hallo Heiko, hier ist ein P+R : http://www.openstreetmap.org/?lat=52.44111lon=9.72504zoom=17layers=0B0FT Mapnik zeigt nur ein P an, Osmarender schreibt Park Ride drüber. Gruß Christian Heiko Schack wrote: Moin Moin. Die Tagvergabe für P+R (Park and Ride) Parkplätze scheint mir ein wenig missverständlich zu sein. Normale Parkplätze werden ja als amenity=parking gekennzeichnet. Für dieses Tag gibt es noch zusätzlich den Key parking. Laut Wiki (http://wiki.openstreetmap.org/index.php/Tag:amenity%3Dparking) kann man dort auch park_ride eintragen. Laut der Wiki-Seite zu P+R (http://wiki.openstreetmap.org/index.php/Proposed_features/Park_and_Ride) gibt ein eigenes Tag amenity=park_ride mit der Class-Angabe, um was für ein ÖPNV-Übergang es sich handelt Leider habe ich in der näheren Umgebung keinen P+R Parkplatz gefunden, an dem ich mich orientieren kann. Welches Tag würdet ihr für einen P+R vergeben? Wird die amenity park_ride in Mapnik und Osmarender richtig angezeigt? Lg Heiko ___ 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] Overlapping ways bei einer area
Raphael Studer schrieb: Ich habe hier sehr viele Stellen, an denen jemand ganz grob den Wald unabhängig von der Straße gezeichnet hat. Das Wohngebiet auf der anderen Seite dann ebenfalls ganz grob frei Hand. Die Ways schneiden sich in den OSM-Daten vor allem in Kurven recht unkoordiniert und dass das in der Karte nachher nicht scheisse aussieht liegt nur daran, dass der Renderer der Straße eine gewisse Breite gibt, sodass beide Flächen auf dem Bild nachher genau an die Straße angrenzen. Dein Beispiel find ich sehr gut. Wenn jetzt die der Wald, die Strasse und das Wohngebiet die selben Nodes teilen, heisst dies dass das Wohngebiet DIREKT neben den Wald ist. Die Strasse in der Mitte könnte also gar nicht vorhanden sein. Na klar! Ein landuse=residential kann doch sehr wohl Straßen enthalten. Oder machst du da für jede Straße eine Schneise in die area? Ebenso enthält ein landuse=forrest auch Wege und Straßen. Das unterscheidet es ja von natural=wood, was explizit nur Bäume, ergo keine Straßen sind. Und in dem obigen Fall würde die Straße also halb durch den Wald und halb durch ein Wohngebiet verlaufen. Das entspricht IMHO sehr gut der Realität. Mann würde ja auch sagen, die Straße verläuft auf der Grenze zwischen Ort und Wald. Das funktioniert natürlich nur mit landuse, das per Definition eine Fläche mit verschiedenen Objekten zusammenfasst. Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Dein Beispiel find ich sehr gut. Wenn jetzt die der Wald, die Strasse und das Wohngebiet die selben Nodes teilen, heisst dies dass das Wohngebiet DIREKT neben den Wald ist. Die Strasse in der Mitte könnte also gar nicht vorhanden sein. Wieso nicht? Nicht jeder Quadratmeter eines Wohngebiets ist bebaut. :) Ich finde die Formulierung Das Wohngebiet beginnt direkt neben dem Wald nicht falsch. Die Straße ist in meinem Vorgehen halb im Wald (Straßen im Wald gibt es, da wachsen auch keine Bäume drauf) und halb im Wohngebiet (Auch da gibt es Straßen auf denen keine Häuser stehen). Ich sehe das als genau das was ich darstellen möchte. Wenn man es so sieht wie du, dann müsste man Straßen IMHO auch in 2-D mappen. sonst hat man um jede Straße ein paar Meter undefiniertes Gebiet, das der Renderer dann bitte mit der Straße abdecken soll. Das ist IMHO nicht logisch. Gruß, Bernd -- Ein Kompromiß ist nur dann gerecht, brauchbar und dauerhaft, wenn alle Partner damit gleich unzufrieden sind. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Help! German translation for Potlatch
Two people for each langauge :) Martin Thurau: On Thu, Jun 5, 2008 at 11:11 AM, Claudius Henrichs [EMAIL PROTECTED] wrote: I strongly oppose a multisuer translation as in the result you are likely to end up with different translations for the same term. Better to form a core team of two people dealing with this. Two people who translate a application in every language even if they are no nativ speakers? Isn't this supposed to end up in something like Stecke Nippel A von durch Lasche in Gegenseite? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Help! German translation for Potlatch
Uh...my bad ;) I agree that you *could* end up with a messy result if more than two people translate an application but I still think translations should be 'free for all'. I would suggest Launchpad like approach (https://translations.launchpad.net/). If potlach already uses gettext (or can be changed) ) we could even use launchpad. Otherwise we could still use the wiki and do the translation there (eventually with automatic import to potlach). After all OSM (and of course Wikipedia) are pretty impressive proves that 'intelligence of the masses' is a working concept. On Thu, Jun 5, 2008 at 12:10 PM, Claudius Henrichs [EMAIL PROTECTED] wrote: Two people for each langauge :) Martin Thurau: On Thu, Jun 5, 2008 at 11:11 AM, Claudius Henrichs [EMAIL PROTECTED] wrote: I strongly oppose a multisuer translation as in the result you are likely to end up with different translations for the same term. Better to form a core team of two people dealing with this. Two people who translate a application in every language even if they are no nativ speakers? Isn't this supposed to end up in something like Stecke Nippel A von durch Lasche in Gegenseite? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tag für P+R Parkplatz
ups, sorry, hab nicht in den Daten geschaut sondern nur auf der Karte, da ich weiß, da da einer ist. Bernd Wurst wrote: Hallo. Am Donnerstag, 5. Juni 2008 schrieb Christian Malolepszy: hier ist ein P+R : http://www.openstreetmap.org/?lat=52.44111lon=9.72504zoom=17layers=0B0FT Nein. Dort ist ein normaler Parkplatz, dem jemand den *Namen* Park Ride gegeben hat. Mit einem speziellen ParkRide-Tag hat das nichts zu tun. Gruß, Bernd ___ 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] Overlapping ways bei einer area
Am 05.06.2008 um 12:18 schrieb Dirk-Lüder Kreie: Bernd Wurst schrieb: Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Dein Beispiel find ich sehr gut. Wenn jetzt die der Wald, die Strasse und das Wohngebiet die selben Nodes teilen, heisst dies dass das Wohngebiet DIREKT neben den Wald ist. Die Strasse in der Mitte könnte also gar nicht vorhanden sein. Wieso nicht? Nicht jeder Quadratmeter eines Wohngebiets ist bebaut. :) Ich finde die Formulierung Das Wohngebiet beginnt direkt neben dem Wald nicht falsch. Die Straße ist in meinem Vorgehen halb im Wald (Straßen im Wald gibt es, da wachsen auch keine Bäume drauf) und halb im Wohngebiet (Auch da gibt es Straßen auf denen keine Häuser stehen). Ich sehe das als genau das was ich darstellen möchte. Wenn man es so sieht wie du, dann müsste man Straßen IMHO auch in 2-D mappen. sonst hat man um jede Straße ein paar Meter undefiniertes Gebiet, das der Renderer dann bitte mit der Straße abdecken soll. Das ist IMHO nicht logisch. Überall dort, wo die Straße quasi die Grenze zwischen Gebieten definiert, sollte sie IMnsHO dieselben nodes sharen,wie die angrenzenden Gebiete, da eine Korrektur der Straße auch eine Korrektur der Gebiete nach sich zieht. Die Gebilde hängen topologisch zusammen, und sollten darum auch in der Topologie in OSM genau so abgebildet werden. Bin auch dafür, dass Straßen eine Grenze zwischen Gebieten bilden können. Oder genauer: auf der Grenze zweier Gebiete kann durchaus eine Straße liegen. Was macht man denn, wenn hinter dem Wohngebiet der Wald (ohne Straße dazwischen) beginnt? Lässt man da auch ein Niemandsland, oder hängt man die über die selben Nodes aneinander? Wohl eher Letzteres. Nodes sind erstmal nur Punkte im Raum. Wer die alles als Teil seiner selbst referenziert (Briefkasten, Straße, Gebiet, Fluss) ist erstmal egal. Ob ein Renderer nur Straßen, oder auch Gebiete darstellt (und wie) ist für die Datenbasis unerheblich. Wie breit eine Straße ist, kann man mit dem Set aus Node und Way auch nicht definieren. Man könnte natürlich eine Breite beim Way zuordnen, aber ist das das Ziel einer Straßenkarte? Dafür benutzt man besser den Typ der Straße. Für perfekte Vermessung wendet Euch an das Projekt OpenSurveyAndMeasurement :P Bei den Parkplätzen sollte IMHO ein Straßenstummel hineinführen, wenn es eine dedizierte Einfahrt gibt, dann darf der P auch keine Nodes der Straße nutzen. Wenn die Parkplätze als Bucht ausgeführt sind, sollten die selben Nodes benutzt werden, da man direkt von der Straße drauf fahren kann. atze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deutsch land
Am 5. Juni 2008 13:28 schrieb Martin Thurau [EMAIL PROTECTED]: Wenn man mal von Grundstücksflächen, Städten und Wäldern absieht, besteht die restliche Fläche unseres Landes ja quasi nur aus landwirtschaftliche genutzten Flächen, die von Straßen, kleinen Bächen und Gräben sowie vereinzelt ein paar Sonderfälle wie Seen und Flüssen, unterbrochen werden. Gibt es im Hinblick auf diese Tatsache eigentlich eine Art Konsens, wie man damit umgeht? Wenn man es aml überspitzen will könnte man ja einfach mal jede Freifläche nehmen und ein landuse=farm draufklatschen...in den meisten Fällen würde es vermutlich passen ;) Mir ist durchaus klar, dass es für OSM im moment wichtigeres gibt, als Freiflächen zu benennen, aber der Gedanke schoss mir gerade in den Kopf und ich fragte mich, ob man sich darüber schonmal Gedanken gemacht hat. Hier herscht leider schon seit Ewigkeiten kein Konsenz. Worauf man sich sicherlich einigen kann, ist die Bezeichnung von landuse=farm bei innerstädtischen landwirtschaftlichen Flächen. Hier stellen sie eine Außnahme und eine Besonderheit dar. Auf dem platten Land hingegen gehen die Meinungen weit auseinander. In der Aachener Gegend haben wir versucht das so: http://wiki.openstreetmap.org/index.php/Aachen#.22landuse.3Dfarm.22 zu machen. Ich wiederhole: Hier herrscht keine Einigkeit. Das ist nur ein Vorschlag. Hole mir schon mal Popkorn Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Landwirtschaftliche Flächen in Deutschla nd
Wenn man mal von Grundstücksflächen, Städten und Wäldern absieht, besteht die restliche Fläche unseres Landes ja quasi nur aus landwirtschaftliche genutzten Flächen, die von Straßen, kleinen Bächen und Gräben sowie vereinzelt ein paar Sonderfälle wie Seen und Flüssen, unterbrochen werden. Gibt es im Hinblick auf diese Tatsache eigentlich eine Art Konsens, wie man damit umgeht? Wenn man es aml überspitzen will könnte man ja einfach mal jede Freifläche nehmen und ein landuse=farm draufklatschen...in den meisten Fällen würde es vermutlich passen ;) Mir ist durchaus klar, dass es für OSM im moment wichtigeres gibt, als Freiflächen zu benennen, aber der Gedanke schoss mir gerade in den Kopf und ich fragte mich, ob man sich darüber schonmal Gedanken gemacht hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deutschla nd
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Martin Thurau: Gibt es im Hinblick auf diese Tatsache eigentlich eine Art Konsens, wie man damit umgeht? Wenn man es aml überspitzen will könnte man ja einfach mal jede Freifläche nehmen und ein landuse=farm draufklatschen...in den meisten Fällen würde es vermutlich passen ;) Ich finde an der Tatsache, dass die beiden aktuellen Renderer landuse=farm komplett unterschiedlich rendern sieht man, dass es keinen Konsens gibt. Beispiel: http://www.informationfreeway.org/?lat=48.93925163541401lon=9.435541347388728zoom=14layers=B000F000F Osmarender macht es grün, Mapnik braun. Die Wahrheit ist, dass sich Grünland und Ackerland aber meist abwechseln und sich das auch über die Zeit immer wieder ändert. Ich denke es macht es allen Beteiligten leichter, wenn man das Gebiet einfach undefiniert lässt. Rendern sollte man das IMHO sowieso gar nicht, da beides, grün oder braun, immer falsch ist. Es gibt natürlich die andere Meinung, dass alles irgend ein landuse haben muss, sonst sind wir unvollständig. Ich seh das aber nicht so. Gruß, Bernd -- Fachbegriffe der Informatik (#286): Googlehupf Abstand zwischen zwei Suchergebnissen. (Markus Kempken) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deutsch land
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Torsten Breda: Worauf man sich sicherlich einigen kann, ist die Bezeichnung von landuse=farm bei innerstädtischen landwirtschaftlichen Flächen. Das widerspricht aber dem verlinkten Wiki-Eintrag: Landuse=farm meint den Landwirtschaftlichen Betrieb, der ja nicht als landuse=residential, industrial oder ähnlichem zu taggen ist. Gemeint ist also der Bauernhof mit direkt angrenzenden Nebengebäuden, Gewächshäusern, Jauchegrube usw. Meist ist das ganze auch umzäunt. Und der widerrum der Definition der Map-Features. ;-) Gruß, Bernd -- Wenn's an Silvester stürmt und schneit, ist das Neujahr nicht mehr weit. Stürmt und schneit's Silvester nicht, ist das Neujahr auch in Sicht. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Noch mehr Flächen
Hallo. Wollte grade unser bisher großzügig vergebenes landuse=residential etwas korrigieren. Dabei fiel mir eine Fläche auf, die aus folgendem besteht (zusammenhängend, ohne Wohnbebauung dazwischen): * Kirche * Gemeindehalle (+ Parkplatz) * Sporthalle * Schulzentrum * Sportplätze * (öffentlicher) Spielplatz und daran grenzt der Stadtpark (der bisher nur leisure=park hat und kein landuse, was ich auch korrekt finde). Hat jemand nen Vorschlag für so ein Gebiet? Gruß, Bernd -- OPERA: When a guy gets stabbed in the back and instead of bleeding he sings. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Noch mehr Flächen
Ich würde die Fläche komplett entfernen und statt dessen lieber einzelflächen an den entsprecheden Positionen angeben: Sporthalle + Schule - amenity=school Sportplatz - amenity=pitch (oder Gemeindehalle - amenity=public_building Parkplätze - amentiy=parking+ Kirche - POI mit amenity=place_of_worship Ist zwar etwas umständlicher und geht ein wenig verschwenderisch mit Punkten um, wäre imho aber am korrektesten. Gruß Martin 2008/6/5 Bernd Wurst [EMAIL PROTECTED]: Hallo. Wollte grade unser bisher großzügig vergebenes landuse=residential etwas korrigieren. Dabei fiel mir eine Fläche auf, die aus folgendem besteht (zusammenhängend, ohne Wohnbebauung dazwischen): * Kirche * Gemeindehalle (+ Parkplatz) * Sporthalle * Schulzentrum * Sportplätze * (öffentlicher) Spielplatz und daran grenzt der Stadtpark (der bisher nur leisure=park hat und kein landuse, was ich auch korrekt finde). Hat jemand nen Vorschlag für so ein Gebiet? Gruß, Bernd -- OPERA: When a guy gets stabbed in the back and instead of bleeding he sings. ___ 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] Overlapping ways bei einer area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, der Diskussion fehlt mir irgend wie ein System. Ich habe in meiner Umgebung nur Parkplätze und diese sind in der Natur baulich von der Straße abgegrenzt. Und wenn es nur ein paar Meter sind. Entweder endet die Straße im Parkplatz oder geht daneben vorbei, besitzt dann aber eine separate Zufahrt zum Parkplatz. Ich erstelle erst einmal den Parkplatz ganz isoliert aus den vier Eckpunkten. Es ist mir kein Parkplatz bekannt, bei dem die Zufahrt direkt auf einem Eckpunkt liegt. Also mache ich ein paar Meter neben der Ecke eine weitere Node in die Parkplatzumgrenzung und lasse die Straße/Zufahrt dann dort enden. Das Ergebnis sieht dann wie in der Realität aus. Habe ich hier einen Denkfehler? Ganz anders sieht die Sache bei einem (historischen) Marktplatz aus, in den mehrere Straßen münden und der eigentlich kein richtiger Platz (wie z. B. der Parkplatz) ist. Da müsste man eher so eine Art Kreisverkehrskonstukt erstellen. Mancher Marktplatz besitzt ja auch eine Mittelinsel (mit Brunnen oder Kriegerdenkmal). Echte Marktplätze sind im Augenblick für mich zu weit weg. Irgendwann werde ich mich auch damit befassen müssen, aber noch nicht gleich heute. Rolf -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Bernd Wurst Gesendet: Donnerstag, 5. Juni 2008 10:31 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Overlapping ways bei einer area Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in der Mitte wie auch am Rand :) Die Aussage dreht sich im Kreis. Also ich verstehe was du sagen willst. Aber ich sehe keinen Grund, warum eine Quer-Straße, die in eine Straße einmündet etwas anderes sein soll als ein Platz, der an die Straße angrenzt. Denk mal wirklich drüber nach, es ist eigentlich echt kein Unterschied. Eben grade *weil* die Straße (nicht die Einmündende sondern die Ausgangsstraße) nicht zweidimensional erfasst wird. Fall 1: -- - - - - - - - - ---+ +--- | | | | Fall 2: -- - - - - - - - - + +--- | | | | +-+ Für mich sieht die obere Straße auch unterhalb der Mitte noch identisch aus bei beiden Szenarien. Nur der Rand der Straße (der gar nicht erfasst ist) ändert sich. Wenn du den Platz jetzt unabhängig erfassen würdest, wäre das Datenmodell so: -- - - - - - - - - -- +-+ | | | | +-+ Ob es ein Renderer oder ein Navi wäre, der Zusammenhang zwischen Straße und Platz (z.B. Parkplatz) wäre nicht gegeben. Es gibt keinen Anhaltspunkt, dass es hier überhaupt eine Einfahrt in den Platz gibt. Wenn der Platz baulich getrennt ist (Mauer, Grünstreifen, ...), dann ist es natürlich was anderes. Aber das war nicht die Ausgangslage. 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht nicht berurteilt werden. Mag sein, seh ich anders. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Ja, eben drum. Ich weiß ja nicht, wie breit der Renderer die Straße macht. In der Realität würde man sagen: Der Platz schließt sich direkt an die Straße an. Man sagt nicht: Der Platz beginnt 3 Meter vom Mittelpunkt der Straße entfernt. Daher komme ich zu dem Schluß, dass verbundene Elemente für jede Nutzung und für jede Art von Renderer die mir einfällt leichter zu verarbeiten bzw. einzustufen ist. Weil es eine semantische Abbildung ist. Für mich stellt sich die übergeordnete Frage, ob wir Karten mit dem Anspruch auf Vermessungs-Genauigkeit haben wollen (so dass man z.B. Flächen-Größen aus unserem
Re: [Talk-de] Wie und wo Mailingliste einrichten?
Holger Schrader schrieb: Hallo Liste, Wie und wo kann ich auf einem einfachen Weg eine lokale Mailingliste einrichten ohne personalisierte Werbung zu erwarten? Ciao Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de Probiers einfach mal auf http://groups.yahoo.com/ Die sind kostenlos und zumindest früher war das auch sehr einfach einzurichten und zu admnistrieren und sehr zuverlässig. Ich hatte da auch ne ganze Weile ne Mailinglist eingerichtet. Gruß, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] GPS Tuner V5.4c ist 'Open Street Map' kompatibel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, schon wieder erhalte ich eine Mitteilung, dass neue Version vom GPS Tuner ausgeliefert wird. Da ich das Programm einmal ehrlich bezahlt hatte, brauche ich nur die neue Version herunterzuladen. Leider hinkt das PDF-Handbuch der Entwicklung hinterher. (http://pocketland.de/product.php?prod_id=13384) Weiß jemand, was man unter GPS Tuner V5.4c ist 'Open Street Map' kompatibel verstehen kann? Die Daten sind in den Wegpunkte im GPX-, LOC-, KML-Dateiformat verfügbar. Kennt jemand mehr spezifische Details? Ich verwende dieses Programm auf dem Yakumo delta 300 GPS mit Windows mobile 2003. Ich wäre richtig zufrieden, wenn der die Speicherbereiche nicht so intensiv bis zum letzten Byte belegen würde. Für das reine Datenerfassen nehme ich doch lieber Odgps. Kann auch GPX aber außer einigen Anzeigen nicht viel mehr. Eingestellt auf ein Punkt jede Sekunde. Dem GPS Turner kann ich ein JPG als Karte nach dem vergeodaten auf dem PC oder notfalls auch auf dem PDA geben. Wenn ich die Geo-Daten eintrage, wird eine *.gmi angelegt. Gleicher Name wie die *.jpg. Der Inhalt sei hier mal als Beispiel angegeben: Map Calibration data file v3.0 Buch JPG.JPG 1256 1040 50;10;13.36667;52.65 141;946;13.38333;52.56667 1166;1022;13.5;52.56667 1185;34;13.5;52.65 Border and Scale 52.6531233732431;13.3593388698909;52.5580773902482;13.5466699234652 6823.408;11526.46 Zeile drei und vier sind die Größe des JPG in Pixel In den folgenden sind vier Punkte verewigt. Jeweils die Koordinaten als Pixel und als Nautische Werte. Auf der OSM-Hauptseite kann ich ein Bild als JPG exportieren. Kann die Seite so eingerichtet werden, dass sie bei Wunsch auch gleich diese gmi-Datei anlegt? Dann sollten die vier Eckpunkte von 0;0 bis 1255;1039 oder so ähnlich angelegt werden. Die nautischen Koordinaten werden ja beim Export angezeigt. Die Datei per Hand zu erzeugen, ist doch sehr fehleranfällig. Kann jemand meinen Wunsch nachvollziehen? Rolf -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) Charset: iso-8859-1 wj8DBQFISBrUX/cdferISG0RAgQ6AJ44U7UBakz7r7CaWOu9R0dOmeIXBgCg27UH LG44CoEe2ssIPrpVFjz4QJA= =talu -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] neue Garmin Karte
Habe heute die Aktuelle Karte von Computerteddy runtergeladen, hatte noch eine 4 Wochen alte installiert. Habe dann die alten img und tdb Dateien einfach aus denen der neuen Karte ersetzt, was bisher immer klappte. Jetzt stürzt aber Mapsource ab wenn ich die OSM Karte anzeigen lasse. Ein rückersetzen der Kartendateienen hilft, aber dann hab ich ja auch die alten Karten... Hab ich was falsch gemacht, oder ist bei der Kartenerstellung was schiefgelaufen? Viele Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] neue Garmin Karte / Worldfile vom 4.6.08
Hallo Carsten wie offenbar bemerkt worden ist, ist die neue Karte online. Entschuldigung für die Dopplung sind meine ersten Erfahrungen mit einer Mailinglist. eine 4 Wochen alte installiert. Habe dann die alten img und tdb Dateien einfach aus denen der neuen Karte ersetzt, was bisher immer klappte. Jetzt Das wird der Fehler sein. Hm, in der Registry trägt man doch nur das ein: [HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\Products\OSM] LOC=E:\\Garmin\\OSM\\ BMAP=E:\\Garmin\\OSM\\6324.img TDB=E:\\Garmin\\OSM\\6324.tdb Wenn ich jetzt alle Dateien im OSM Ordner mit denen der neuen Karte ersetze (ich nenne den Ordner in OSM_alt um und mache dann einen neuen der OSM heisst, dahin entpacke ich dann die neue Karte) müsste das doch funktionieren, oder? Wenn nein, wie geht es richtig? mit dem alten typ-File getestet Ein typ-File benutze ich gar nicht. Viele Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, für mich bleibt die wichtige Frage: Steht dort ein Weißes P auf blauen Grund? Mit allen Rechten für den Kraftfahrer und allen Pflichten für die Gemeinde oder Stadt? Oder ist es nur eine Parkordnung mit allen Nachteilen für den Kraftfahrer? Ich glaube, ich war vor vielen Jahren schon einmal dort, hatte aber den Pkw unten in der Stadt stehen lassen. Ich kann mich an die Flächen noch dunkel erinnern, aber nicht mehr an die Beschilderung. Aber mal so nebenbei die Frage: Ist denn klar geworden, warum ich das so getrennt behandelt wissen möchte? Rolf -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Henry Loenwind Gesendet: Donnerstag, 5. Juni 2008 21:59 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Overlapping ways bei einer area Rolf Gehring wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, das sind in meinem Augen im eigentlichen Sinne keine Parkplätze. Ich gehe mal davon aus, dass dort auch kein Weißes P auf blauen Grund steht. Nur weil der OP kein besseres Beispiel gefunden hat, heißt das noch lange nicht, dass es solche Parkplätze nicht gibt. Mein Beispiel ist bei Google leider vor lauter Bäumen nicht zu sehen: Heidelberg, über dem Schloß. Ein richtiger Parkplatz, sogar mit eigenen Fahrspuren, der auf einer Längsseite durch nichts von der Straße getrennt ist. Naja, ausser den Begrenzungslinien der einzelnen Parkbuchten... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) Charset: iso-8859-1 wj8DBQFISFKFX/cdferISG0RAvVOAJ41+Y4iqRjIhgE3BNS1lKNVaYUn6ACfXiKD Y4ZiopSgW101ihG/HEoXNjM= =Essv -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deuts chland
Moin, Sind wir da schon zwecks Alternative weiter? Habe da noch paar provisorisch getaggte Höfe... solange das nicht besonders eindeutig ist, könntest Du doch die Bauernhöfe mit flächenverbrauch=bauernhof und flächenverbrauch=landwirtschaftlich_genutzte_fläche versehen, oder? So fügtest Du eindeutige Informtationen zu unserem Datenbestand hinzu, die sich später mal konvertieren lassen, wenn sich andere Tags durchgesetzt haben. Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wie und wo Mailingliste einrichten?
Am Donnerstag 05 Juni 2008 schrieb Holger Schrader: Hallo, Danke für die Tipps. Ich meinte schon eine ML in der OSM´ler aus einer Stadt oder einem Landkreis miteinander kommunizieren können. openstreetmap.org/.de wär natürlich sinniger, aber wenn das ein Problem darstellt, frag mich nochmal, dann kann ich das bei mir auch hosten. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flyer sind bald alle
2008/6/4 Sven Geggus [EMAIL PROTECTED]: Frederik Ramm [EMAIL PROTECTED] wrote: Die Bilder sind selbst gemacht bzw. aus zur Veroeffentlichung frei gegebenem Pressematerial. Wenn Du sowieso gerade am ändern bist, vielleicht nimmst Du statt nem GPSmap nen Etrex Vista oder Legend. hatten die nicht so komische Probleme mit Abweichungen in Tracks? Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deuts chland
Heiko Jacobs schrieb: Moin Zitat von Bernd Wurst [EMAIL PROTECTED]: Am Donnerstag, 5. Juni 2008 schrieb Torsten Breda: Worauf man sich sicherlich einigen kann, ist die Bezeichnung von landuse=farm bei innerstädtischen landwirtschaftlichen Flächen. Das widerspricht aber dem verlinkten Wiki-Eintrag: Landuse=farm meint den Landwirtschaftlichen Betrieb, der ja nicht als landuse=residential, industrial oder ähnlichem zu taggen ist. Gemeint ist also der Bauernhof mit direkt angrenzenden Nebengebäuden, Gewächshäusern, Jauchegrube usw. Meist ist das ganze auch umzäunt. Genau... Nee, das ist Unfug. Den eigentlichen Bauernhof kann man sehr gut als residential taggen und das ganze bewirtschaftete (oder auch brachliegende) Land ist landuse=farm. Mehr industrielle Höfe kann man meinetwegen auch als industrial verbuchen. Auf jeden Fall ist es sehr wichtig, das ganze Land zu taggen, damit man sieht, wo Bäume stehen und wo nicht. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Hallo! Am 5. Juni 2008 17:55 schrieb Sven Grüner [EMAIL PROTECTED]: Raphael Studer schrieb: Deine Ausführungen zu landuse=forest und natural=wood finde ich noch interessant. Somit würde das bedeuten. Ich mache eine grosse Fläche landuse=forest, darin eine etwas kleinere Fläche (ca .5 Meter weniger) natural=wood. Überall wo jetzt eine Strasse durch den Wald geht, trenne ich den natural=wood auf und zieh die Strasse durch, das landuse=forrest last ich aber (siehe Angehaengtes Bild). Ja genau. Ich will auch nicht behaupten, dass das jetzt besonders praktikabel ist, geschweige denn, dass ich es selber so machen würde. Aber rein von der Logik die natural= und landuse= woanders innehaben wäre es so. Wo genau haben sie so eine Logik inne? Wenn ich zwei Seen habe, zwischen denen ein schmaler Damm mit Straße verläuft dann mache ich ja auch nicht ein großes natural=water und lege den Highway mittenrein. Gleiches gilt bei Inseln, die man korrekterweise per Multipolygon ausschneiden sollte und nicht ein weiteres natural=land drüber klatscht. Klar, bei zwei Seen zeichnet man auch zwei Seen ein - aber das eine Straße, die durch einen Wald führt, daraus nun zwei Wälder macht, finde ich nicht unbedingt. Ein Industriegelände besteht auch nicht aus zig Flächen, nur weil man für die Straßen ein Schachbrettmuster haben. Das ist eine Fläche, in der Straßen und Gebäude liegen. Die Unterscheidung ziwschen natural=wood für Urwälder und landuse=forrest für bewirtschaftete Wälder finde ich total absurd. Das sind zwei vollkommen verschiedene Eigenschaften die da gegenüber gestellt werden. Ersteres besagt, was an einem Ort physisch anzutreffen ist und der landuse fasst die ganze Gegend thematisch zusammen, ohne zu sagen, was dort nun genau ist. Mal ganz unvoreingenommen: Was erwartest du in einem landuse=forest (Managed forest or woodland plantation / Forst, Landwirtschaftlich genutzter Wald) zu finden? Für den Laien (wie mich) unterscheidet sich das ganze von einem Naherholungsgebiet ohne forstwirtschaftliche Nutzung, oder auch einem ganz unbewirtschaftetem Gebiet nicht sonderlich - da sind halt Bäume. Den Grund warum man es trotzdem eintragen sollte wenn man es weiß was im dunklen Wald so vor sich geht, nennst du ja selber: Das eine beschreibt das Physische, das andere die Nutzung - und diese Werte werden nicht gegenüber, sondern nebeneinander gestellt. Das wäre als ob ich das Gewicht des Apfels mit der Farbe der Birne vergleiche. Nein, das wäre so als würdest du die Funktion = Frucht und die Nutzung = Nahrung für beide erfassen würdest, während ein Stechapfel die Nutzung = Gift bekommt. Wenn das dann mal jemand nach Gewicht und Farbe filtern will - bitte. Übrigens: Wenn natural nur bei Objekten verwendet werden darf, die so Menschen-fern entstanden sind wie ein Urwald, sollten wir uns schleunigst neue Tags für Seen, Küsten, Sümpfe, Strände, etc. überlegen. Sehe ich wirklich so: Ein Baggerloch sollte man schon irgendwie als solches kennzeichnen können - auch renaturierte / rekultivierte Gebiete können wir bisher nicht vernünftig eintragen. Da könnten ein paar Tags nicht schaden. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] [Leicht OT] Rekorde
Hallo zusammen, ich habe soeben meinen persönlichen Upload-Rekord von 1074 hochzuladenen Änderungen mit 5207 Änderungen um fast das fünffache überboten... Puh... ich sage euch, das war ganz schön anstrengend. Ich sitze ja auch seit neun Uhr gestern Abend über JOSM. Trotzdem ist nun meine Region um einiges reicher... Ich bin mal auf das gerenderte Ergebnis gespannt. Der Upload dauerte übrigens über 32 Minuten. Und da in letzter Zeit die Telek0m des öfteren mitten drin die Verbindung kappt waren das ganz schön spannende Minuten... Ich sah das Unheil schon vor mir: 3500 Nodes doppelt... Gut das es diesmal auf Anhieb geklappt hat. Was waren eigentlich eure persönlichen Rekorde in Sachen Änderungen zum Hochladen? Grüße und gute Nacht! Michael 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] [Leicht OT] Rekorde
Michael Bemmerl schrieb: ich habe soeben meinen persönlichen Upload-Rekord von 1074 hochzuladenen Änderungen mit 5207 Änderungen um fast das fünffache überboten... Schön, sehr schön -- aber warum machst du keine Zwischenuploads ?-) -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [Leicht OT] Rekorde
Hallo. Am Freitag, 6. Juni 2008 schrieb Michael Bemmerl: Was waren eigentlich eure persönlichen Rekorde in Sachen Änderungen zum Hochladen? Aufgrund einschlägiger Erfahrungen mit meiner DSL-Verbindung und JOSM habe ich mir angewöhnt, wann immer es geht die Änderungen sofort hochzuladen. Aber einmal habe ich eine halbe Kleinstadt offline gemapped, gespeichert und später hochgeladen. War aber nicht viel, vielleicht 200 Änderungen oder sowas... Gruß, Bernd -- Das Leben ist eine endlose Aneinanderreihung von demütigenden Niederlagen, bis man sich nur noch wünscht, Flanders wäre tot. - Homer Simpson signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Florian Lohoff wrote: Die Straße oder der Weg im Openstreetmap wiederum ist keine grenze sondern eine mitte. D.h. das wiederbenutzen von punkten der straße fuer eine angrenzende flaeche mag schoen fuer den renderer oder auch praktisch sein - aber in meinen augen eben falsch weil das waldstueck nicht in der mitte der straße beginnt (nein - es stehen keine baeume in der mitte der straße) sondern an deren seitenstreifen. Mal abgesehen davon, dass wir z.Z. jenseits der aktuellen Datengenauigkeit diskutieren: Beginnt ein Wald eigentlich am aeussersten Baumstamm, oder gehoert da auch noch die Flaeche unter seinen Aesten hinzu? Die zweite Variante entspricht eher meiner Wahrnehmung, wenn ich unter den Baeumen bin, bin ich auch im Wald. Nach dieser Auslegung, wuerde der Wald dann aber haeufig durchaus innerhalb (oder sogar jenseits) der Strassenflaeche beginnen, und auch Wege und Strassen durch den Wald wuerden innerhalb der Waldflaeche liegen. Da z.Z. die meisten Waldgebiete anhand von Luftbildern eingetragen werden, duerfte auch die haeufigere Nutzung fuer die zweite Variante sprechen. Momentan vermeide ich das mehrfache Nutzen von Nodes fuer Wege und Flaechen aus der rein praktischen Erwaegung, dass ich das bei spaeteren Erweiterungen der Daten eher hinderlich finde. Wahrscheinlich kann ich aber nur noch nicht richtig mit JOSM umgehen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Routingfaehige Garminkarten
Am Mittwoch, 4. Juni 2008 22:12 schrieb Frederik Ramm: Hallo, Ich für meinen Teil ich wäre gerne bereit jemandem 20€ zukommen zu lassen, wenn der in Zukunft regelmäßig aktuelle, routingfähige OSM Karten irgendwo zum Download bereitstellt. (Da habe ich schon mehr Geld für nutzlosere Dinge ausgegeben) Ich wuerde eigentlich gern jemandem 20€ zukommen lassen, damit der die existierende freie Software um die Faehigkeit erweitert, Routingkarten zu machen, anstatt €20 fuer eine Lizenz auszugeben ;-) Ja, ich wäre auch sehr interessiert. Wenn nur noch ein paar Bytes im Header fehlen könnte man sich die Information was diese bedeuten evtl. vom Entwickler von cGPSmapper für ein paar Euro abkaufen. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Stefan Schwan schrieb: Am 5. Juni 2008 17:55 schrieb Sven Grüner [EMAIL PROTECTED]: Die Unterscheidung ziwschen natural=wood für Urwälder und landuse=forrest für bewirtschaftete Wälder finde ich total absurd. Das sind zwei vollkommen verschiedene Eigenschaften die da gegenüber gestellt werden. Ersteres besagt, was an einem Ort physisch anzutreffen ist und der landuse fasst die ganze Gegend thematisch zusammen, ohne zu sagen, was dort nun genau ist. Ja, sehe ich auch so. Mal ganz unvoreingenommen: Was erwartest du in einem landuse=forest (Managed forest or woodland plantation / Forst, Landwirtschaftlich genutzter Wald) zu finden? Für den Laien (wie mich) unterscheidet sich das ganze von einem Naherholungsgebiet ohne forstwirtschaftliche Nutzung, oder auch einem ganz unbewirtschaftetem Gebiet nicht sonderlich - da sind halt Bäume. In einem landwirtschaftl. genutzten Wald muss man (vor allen Dingen in Hessen) damit rechnen, dass tracks regelm#257;ßig bis zur Unbenutzbarkeit verhunzt sind. Sehe ich wirklich so: Ein Baggerloch sollte man schon irgendwie als solches kennzeichnen können - auch renaturierte / rekultivierte Gebiete können wir bisher nicht vernünftig eintragen. Da könnten ein paar Tags nicht schaden. Jein ;) Manchmal ist weniger mehr. Es wäre gut, den Grundbestand der Haupttags erstmal nicht zu erweitern und stattdessen einfach zus#257;tzlich Attribute zu setzen. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
