Re: [Talk-de] JOSM Vorlage Spielstraße
Wäre es möglich, dass in der Vorlage Spielstraße fest die Geschwindigkeit Schrittgeschwindigkeit bzw. walk eingestellt ist. Nein, bitte nicht schon wieder. Nur explizite Geschwindigkeitsbegrenzungen sollten getagged werden. Ich stoße immer wieder beim bearbeiten von Spielstraßen living_street auf maxspeed=30. Wer so fährt hat wohl nicht mehr lange Freude an seinem Führerschein... ;-) Gegenvorschlag: einen Test für den Validator/OSMI, der bei highway=living_street mit maxspeed=... meckert. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Vorlage Spielstraße
On Wed, Sep 30, 2009 at 10:36:21AM +0200, Marc Schütz wrote: Wäre es möglich, dass in der Vorlage Spielstraße fest die Geschwindigkeit Schrittgeschwindigkeit bzw. walk eingestellt ist. Nein, bitte nicht schon wieder. Nur explizite Geschwindigkeitsbegrenzungen sollten getagged werden. nein, bitte nicht schon wieder! walk ist der einzige sichere und explizit eindeutige wert; mit irgendwelchen ableitungen ist keinem geholfen! Ich glaub du hast mich falsch verstanden: ich bin nicht gegen walk an sich, wenn es irgendwo explizit geschrieben steht. Ich bin aber generell dagegen, implizite Geschwindigkeitsbegrenzungen zu taggen, d.h. kein maxspeed=walk, wenn nicht explizit auf einem Schild Schrittgeschwindigkeit fahren! steht, genausowenig wie jede Straße innerorts maxspeed=50 kriegen sollte. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Vorlage Spielstraße
Ich glaub du hast mich falsch verstanden: ich bin nicht gegen walk an sich, wenn es irgendwo explizit geschrieben steht. Ich bin aber generell dagegen, implizite Geschwindigkeitsbegrenzungen zu taggen, d.h. kein maxspeed=walk, wenn nicht explizit auf einem Schild Schrittgeschwindigkeit fahren! steht, genausowenig wie jede Straße innerorts maxspeed=50 kriegen sollte. Das steht explizit auf dem Schild Verkehrsberuhigter Bereich, Blödsinn. Auf dem Schild http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_325.svg steht überhaupt kein Text. da dessen Bedeutung eine Höchstgeschwindigkeit von Schrittgeschwindigkeit für alle Fahrzeuge enthält. Bedeutung ... enthält = implizit -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Vorlage Spielstraße
Blödsinn. Auf dem Schild http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_325.svg steht überhaupt kein Text. Schön dass du deine Behauptung, auf dem Schild stehe das explizit drauf, auf die sich das Blödsinn offensichtlich bezogen hat, nicht mitzitiert hast. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
Dort werden internationale Empfehlungen erarbeitet und verabschiedet. Die wichtigsten: 1. grundsätzlich sollen Endonyme verwendet werden, also Ortsnamen sind so zu schreiben, wie sie in den dortigen Ländern geschrieben werden: München, Praha, Beijing 2. für die verschiedenen Schriften soll eine gegenseitige Umschrift erfolgen, damit die Endonyme auch für Dritte lesbar sind. Für uns also eine Umschrift der nichtlateinischen Schriften in eine lateinische, bzw von unserer Schrift in die wichtigsten nichtlateinischen. 3. wenn, dann sollen Exonyme nur in Klammer hinter dem Endonym angegeben werden. ... Um Namen in einem deutschen Rendering politisch korrekt zu verwenden ist m.E. insbesondere die Regel 1 und 3 anzuwenden. Unklar hingegen ist mir, wie die Regel 2 in OSM so umgesetzt wird, dass in der DB die Umschreibungen so in einem Schlüssel erfasst werden, dass sie vom Renderer auch eindeutig wiedergefunden werden. Ich finde, die Karten sollten sich an der Realität orientieren und nicht an politischer Korrektheit. Besonders die Regeln 1 und 3 widersprechen der Realität häufig. Bei Prag würden diese zu Praha (Prag) führen. Dies suggeriert, dass Praha der hauptsächliche deutsche Name der Stadt wäre, und Prag nur ein ebenfalls gebräuchlicher. Tatsächlich ist das Gegenteil der Fall; Praha werden die meisten deutsch-sprachigen Menschen allerhöchstens passiv verstehen, aber nicht aktiv gebrauchen. Mein Gegenvorschlag: - Auf der Karte sollte - sofern vorhanden - immer name:de erscheinen, ggf. mit dem Endonym in Klammern. - name:de sollte nur gesetzt werden, wenn der deutsche Name heutzutage auch tatsächlich in Gebrauch ist; ansonsten sollte old_name oder old_name:de verwendet werden, je nachdem, ob der deutsche Name damals der Hauptname war oder nicht. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinie automatisch aus Landsat-Bi ldern extrahieren?
Sie bestehenden Küstenlinien wurden AFAIR mit einem Script erstellt (zumindest am Anfang). Nein, die sind von irgendwo importiert worden (USGS?) und in vielen Gebieten inzwischen von Hand verfeinert worden. Ob es da jetzt ein besseres Script gibt weiss ich allerdings nicht (oder ob man ggf, nur die Parameter / die Auflösung ändern muss, das aber damals für die ganze Welt zu viel gewesen wäre). Auf das Lakewalker-Plugin wurde ja bereits hingewiesen. Keine Ahnung, ob das Tool auch mit Küstenlinien-Ausschnitten, die ja nicht geschlossen sind, umgehen kann. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgehungsstraße vs. Landstraße
Sind sie. Den Bereich prüfe ich sehr häufig. Wenn man einen Knoten nimmt, der näher an der Bahnstraße liegt, nimmt er eine andere Route: http://tinyurl.com/l3pj25 maxspeed=50 habe ich hinzugefügt. maxspeeds sollten nur getaggt werden, wenn sie explizit ausgeschildert sind. Bei Straßen innerorts ist das meistens nicht der Fall. Grüße, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgehungsstraße vs. Landstraße
maxspeeds sollten nur getaggt werden, wenn sie explizit ausgeschildert sind. Bei Straßen innerorts ist das meistens nicht der Fall. Sagt wer? Wie stellst du fest das du innerorts bist und 50 fahren musst? landuse=residential != geschlossene ortschaft boundary=administrative != geschlossene ortschaft Maxspeeds werden so getagged wie sie gelten und ausgeschildert sind, im oder auch explizit ... Die frage ist lediglich ob wir statt 50 irgendwelche dinger wie DE:citylimit oder aehnliches setzen ... Das ist eben keine Frage; nur das letztere ist eine akzeptable Lösung, wenn wir die Probleme vermeiden wollen, die in der letzten zu diesem Thema geführten Diskussion ausführlich erörtert worden sind. Wie das genau zu geschehen hat, dafür gibt es wohl noch keine einheitliche Lösung, aber das heißt nicht, dass wir stattdessen Workarounds anwenden sollten, die uns eine saubere Lösung in Zukunft verbauen. Ich möchte die Diskussion nicht schon wieder führen müssen; die Argumente von damals haben sich ja nicht geändert. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgehungsstraße vs. Landstraße
Am Donnerstag 27 August 2009 14:46:19 schrieb Bernd Wurst: Hallo. Am Donnerstag, 27. August 2009 schrieb Marc Schütz: maxspeeds sollten nur getaggt werden, wenn sie explizit ausgeschildert sind. Bei Straßen innerorts ist das meistens nicht der Fall. Falsch. Es gibt viele diskussionswürdige Ansätze, aber es absichtlich *wegzulassen* wäre wirklich dumm. Die Verfechter von kein maxspeed=50 können das jederzeit durch ihren bevorzugten Tag des Tages ersetzen, aber so lange keine Information über die Eigenschaft des Innerorts vorliegt, fehlt eine Info. Nein können sie nicht, weil man dem maxspeed=50 dann nicht mehr ansieht, ob es explizit oder implizit ist. Das alles ist bis zum Erbrechen diskutiert worden; auch diese Behauptung wurde dabei widerlegt. Ich werde deshalb ab jetzt in diesem Thread nicht mehr antworten, es sei denn es werden neue Argumente gebracht. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Das ist doch keine Länderabkürzung, sondern eine *Sprach*abkürzung? Insofern wäre ISO 639-1 relevant, ist auch so auf Key:name dokumentiert. Bei Dingen wie dem DE:urban-Vorschlag von vor einer Weile liegt die Sache übrigens anders, das sind *Länder*abkürzungen und daher in groß richtig. note:DE = deutscher Text ist für mich identisch mit name:DE = deutscher Name Wie gesagt: Es ist meine Tagging-Variante und meine Schule. Niemand muss sich danach richten. Bist du sicher, dass du seine Frage richtig verstanden hast? Es geht nicht um eine Parallelität zwischen note:xx und name:xx, sondern darum dass DE = Deutschland und de = Deutsche Sprache bedeutet (nach der ISO-Norm, auf die du dich berufen hast). name:DE wäre dann ein Name, der nur innerhalb Deutschlands gültig ist. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landratsamt will OSM
Wenn ich die Karte auf dem Navi benutze hab ich plötzlich mehrere Jugendherbergen mit Namen Stintfang. Da fehlt die datenaufbereitung... Nein, da sind die Daten falsch. Wenn es nur eine Jugendherberge gibt, darf sie nicht zweimal eingetragen werden. Ganz abgesehen davon, dass sich das gar nicht automatisch rausfiltern lässt: Wie erkennt man, welche Einträge zusammengehören und welche nicht (besonders wenn die fraglichen Objekte keinen Namen haben)? Welcher Eintrag ist der richtige oder Haupteintrag? Grüße, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landratsamt will OSM
Da fehlt die datenaufbereitung... Nein, da sind die Daten falsch. Wenn es nur eine Jugendherberge gibt, darf sie nicht zweimal eingetragen werden. Ganz abgesehen davon, dass sich das gar nicht automatisch rausfiltern lässt: Wie erkennt man, welche Einträge zusammengehören und welche nicht (besonders wenn die fraglichen Objekte keinen Namen haben)? Welcher Eintrag ist der richtige oder Haupteintrag? Dann braucht die Anwendung eben eine Option die auswählbar macht was angezeigt werden soll (z.B. POI oder Gebäudebezeichnung). Ein Universalrenderer der alle Daten gleichzeitig lesbar und schön darstellt geht eben nicht. Es geht nicht um eine Anwendung, sondern um automatische Datenaufbereitung. Und die ist nicht möglich, wenn die Daten das nicht zulassen. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] geteilte Fahrrad- Fußwege mit path
wer kennt das allgemeine Tagging für die vertikale Variante Ich empfehle, path nur zu verwenden, wenn _keine_ blauen schilder aufgestellt sind. Bei vertikaler teilung verwendet man: highway=cycleway foot=yes traffic_sign=z241 bei horizontaler: highway=cycleway foot=yes traffic_sign=z240 wenn dann bitte foot=designated und nicht nur foot=yes +1 Außerdem schadet es nicht, gleich noch bicycle=designated dazu zu setzen. highway=cycleway wird ja mal als bicycle=designated, mal als bicycle=yes interpretiert. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landratsamt will OSM
Am Sonntag 02 August 2009 07:18:34 schrieb Karl Eichwalder: Bernd Wurst be...@bwurst.org writes: Am Samstag, 1. August 2009 schrieb Karl Eichwalder: Du schuldest immer noch eine Angabe über den Grund für deine etwas obskure Meinung, dass doppelte Daten etwas besonders gutes wären! (Park-)plätze ohne highways sind mist. Hallo Kontext? Ist eben auch so was, wo man in einem polygon noch ein objekt benötigt. Das geht völlig an der ursprünglichen Frage vorbei. Der Parkplatz und die Wege darin sind unterschiedliche Objekte, deswegen sollen sie natürlich beide eingetragen werden. Aber gleichzeitig den Parkplatz als Fläche _und_ als Node einzutragen ist redundant. Übrigens ist es keineswegs immer trivial, den mittelpunkt eines polygons sinnvoll auszurechnet. Bei Fürth macht der damals nur als polygon eingetragene MD-kanal einen schönen bogen, was dazu führte, dass die beschriftung kilometerweit weg in der stadt zu finden war (bei stadtmauern ist ähnliches denkar) - hier im schema sieht es ok aus, aber auf einem plan mit anderen objekten zusammen ist so etwas doch eher befremdlich: Das ist wahrscheinlich ein ausschließliches Renderer-Problem. Aber selbst wenn es nicht praktikabel ist, das im Renderer zu implementieren (z.B. weil es keine effizienten Algorithmen dazu gibt), ist die Lösung bestimmt _nicht_, das entsprechende Objekt zweimal einzutragen, sondern z.B. die vorgeschlagene Label-Relation zu verwenden. Doppelte oder irgendwie redundante angaben sind bei uns notwendig, weil wir aus durchaus nachvollziebaren gründen keine verpflichtenden tagging-vorgaben haben. Non sequitur. Sie sind deswegen allerhöchstens zulässig, aber nicht notwendig. Aber da wir durchaus verbindliche Regeln haben (z.B. die on the ground rule), ist selbst das zweifelhaft. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plätze im städtischen Bild - wie tag gen?
Wenn wir schon dabei sind: gibt es einen Tag für eine benannte Straßenkreuzung? Es sind keine Bäume auf diesem Platz, grad mal eine Verkehrsinsel: http://maps.google.com/maps?f=qsource=s_qhl=degeocode=q=bayreuthsll=37.0625,-95.677068sspn=59.467068,107.138672ie=UTF8ll=49.950302,11.572034spn=0.001498,0.00327t=kz=19 Dieses Gebilde nennt sich Berliner Platz. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
Tagging einheitlich wie immer mit name:de=xy name=offizieller Name in Landessprache Man sollte dann noch unterscheiden zwischen dem deutschen Namen, dem Namen im Zeichensatz des jeweiligen Landes und der internationalen Transliterierung. Für die Transliteration sollte m.E. int_name verwendet werden. Leider ist dort allzu oft der englische Name untergebracht. Aber das ist niemandem vorzuwerfen, da es für die Transliteration bisher noch keine Tagging-Empfehlung gibt. Ich habe da leider auch keine Lösung. Noch einen neuen Namen-Namensraum fände ich doof. translit_name auch seltsam. Vorschläge? Hier gibt es schon einen Vorschlag im Wiki: http://wiki.openstreetmap.org/wiki/Transliteration_code Streng genommen handelt es sich dabei nicht um Transliteration, sondern Transskription, da erstere bei logographischen Schriften gar nicht möglich ist. Auf der Diskussionsseite zu Multilingual names gibt es auch noch einen Beitrag dazu: http://wiki.openstreetmap.org/wiki/Talk:Multilingual_names Und natürlich gibt es das RFC4646, das die Kombination aus Angaben für Sprache, Schrift, und Region regelt, z.B. ru-Latn. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
m.E. nein, da Königsberg halt wirklich nur der old_name ist, und daher sollte m.E. selbst in einer deutschen Karte Kaliningrad stehen (auch wenn man dt. Namen angefordert hat). In einer historischen Karte sollte da Königsberg (Kaliningrad) stehen. in diesem Fall wäre das richtige Tagging daher: name=Kaliningrad old_name=Königsberg name:de=Kaliningrad Das ist doch Unfug. Kaliningrad ist kein deutscher Name. Es ist maximal die lateinische Schreibweise. Der deutsche Name ist Königsberg. Zu entscheiden ob und in welcher Weise dieser noch gebraucht wird ist nicht die Aufgabe von OSM. Solange er überhaupt gebräuchlich ist und bei Königsberg ist dies eindeutig der Fall. Wenn es der im deutschen übliche Name ist, ist es ein deutscher Name, selbst wenn er russischen Ursprungs ist. Ich hab den Eindruck, dass Kaliningrad öfter verwendet wird als Königsberg, und letzteres eher mit dem Zusatz ehemals. Dass wir das feststellen (nicht entscheiden!) müssen, ergibt sich schon aus unserem Anspruch, die Realität abzubilden, denn die Unterscheidung zwischen aktuellen und ehemaligen Namen in verschiedenen Sprachen ist ja durchaus real. Statt also wilde Taggingregeln zu erfinden um die Karte politisch korrekt erscheinen zu lassen sollte lieber die Darstellung so angepasst werden, dass für jede Sprache die relevanten Namen angezeigt werden. Das wird insbesondere bei vielsprachigen Ortsnamen schwierig werden. Die einzige Möglichkeit, das einigermaßen richtig hinzukriegen, ist, die dafür notwendigen Informationen in der DB zu haben. Dafür, und nicht um die Karte politisch korrekt erscheinen zu lassen, ist dieses wilde Taggingschema eingeführt worden. -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
Tagging einheitlich wie immer mit name:de=xy name=offizieller Name in Landessprache Man sollte dann noch unterscheiden zwischen dem deutschen Namen, dem Namen im Zeichensatz des jeweiligen Landes und der internationalen Transliterierung. Für die Transliteration sollte m.E. int_name verwendet werden. Leider ist dort allzu oft der englische Name untergebracht. Aber das ist niemandem vorzuwerfen, da es für die Transliteration bisher noch keine Tagging-Empfehlung gibt. Ich habe da leider auch keine Lösung. Noch einen neuen Namen-Namensraum fände ich doof. translit_name auch seltsam. Vorschläge? Hier gibt es schon einen Vorschlag im Wiki: http://wiki.openstreetmap.org/wiki/Transliteration_code Streng genommen handelt es sich dabei nicht um Transliteration, sondern Transskription, da erstere bei logographischen Schriften gar nicht möglich ist. Auf der Diskussionsseite zu Multilingual names gibt es auch noch einen Beitrag dazu: http://wiki.openstreetmap.org/wiki/Talk:Multilingual_names Und natürlich gibt es das RFC4646, das die Kombination aus Angaben für Sprache, Schrift, und Region regelt, z.B. ru-Latn. Nachtrag: Von int_name halte ich nicht viel (nicht nur zur Transliteration). Zumindest aus dem Wiki geht nicht hervor, für was der eigentlich genau gut sein soll. An was erkennt man denn den internationalen Namen, z.B. von Rom: Rom, Rome, Roma, Rzim, Erroma, an Róimh, Rim, Rzym, Room, Romma... Welcher davon ist jetzt _der_ internationale Name? Der englische? Oder die Form, die in den meisten Sprachen benutzt wird? Oder irgendwas, was in einem Standard definiert wurde? -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracktype=grade1
ich kenne das (als ursprünglich Baden-Württemberger) auch aus den neuen Bundesländern: war schon erstaunt, wieviele Feld- und Waldwege da nicht nur nicht gesperrt sind, sondern auch zu vereinzelten Grundstücken und Bungalowsiedlungen führen. Die Wege sind aber klar Wirtschaftswege, keine Straßen. Nur dass da dann halt mitten im Wald irgendein FDJ-Freizeitheim liegt, das mittlerweile aufgeteilt und privatisiert ist. Teilst du auch noch die Kriterien mit uns, die dich annehmen lassen es handle sich trotzdem noch um einen Feld-/Wald-/Wirtschaftsweg und nicht um sevice bzw. unclassified? Nur so können andere beurteilen ob Dein Ergebnis auf tragfähigen Argumenten beruht. Ich kann es jedenfalls nicht nachvollziehen. Weil ein Feldweg eben ein Feldweg ist. Er wird weder zum highway=service, wenn dort ein Haus hingebaut wird, noch wird er wieder zum highway=track, wenn ein dort stehendes Haus abgerissen wird. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
Am Donnerstag 23 Juli 2009 20:15:34 schrieb Tim Alder: Hallo, ich wollte nur mal in die Runde fragen, wie man mit der möglichen politischen Brisanz eines deutschsprachigen Renderings umgehen kann. Bei den meisten Sprachen und den meisten Orten wird das sicher unkritisch sein, ich denke da aber an die Orte in Polen und Tschechien die nur bis 1945 den deutschen Namen trugen. Also Königsberg, Breslau und z.B. eine Kleinstadt namens Schneidemühl. Auf den meisten deutschen Papierkarten schreibt man da den heutigen Namen und darunter in kleinen Buchstaben und in Klammern den deutschen Namen. So mit den alten Namen könnte die Karte halt etwas reaktionär wirken. Besonders auffällig ist es, wenn sich die Wortstämme komplett unterscheiden. Vielleicht gibt es ja eine Idee wie man diese kritischen Fälle einheitlich taggen könnte. Weltweit gibt sicher noch aktuellere Problempunkte. Ich glaube, die meisten Probleme lassen sich durch geschickte Unterscheidung zwischen name, name:de, old_name und old_name:de lösen. name ist dabei immer der aktuelle vor Ort übliche Name, und old_name ein ehemaliger vor Ort üblicher Name. name:de ist dementsprechend der aktuelle im Deutschen gebrauchte Name, old_name:de wäre ein früher im deutschen gebrauchter Name, der aber oft überflüssig ist, weil er mit old_name identisch ist. Ein paar Beispiele: Für Breslau ist wohl auch heute noch die deutsche Bezeichnung üblich, so dass ich so taggen würde: name=Wrocław old_name=Breslau name:de=Breslau Für dein Beispiel Schneidemühl, dessen deutscher Name heute wahrscheinlich nicht mehr gebräuchlich ist: name=Piła old_name=Schneidemühl name:de=Piła Wahrscheinlich kann man in diesem Fall name:de auch ganz weglassen. Für Fälle wie Warschau, welches m.W. wohl schon immer traditionell polnisch- sprachig war: name=Warszawa name:de=Warschau In diesem Fall entfällt das old_name, da identisch mit name. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen kann manchmal wichtig und rich tig sein (war Routerhärtetest )
ja, in diesem Fall sollte man den einzelnen Node löschen und das Gebäude mit den tags versehen. Das sollte man nicht, weil man damit anwendungen kaputtmacht, die gebäude (noch) nicht auswerten. Man sollte vielmehr die renderer bzw. den präprozessor fixen. Wenn ein POI (node) in einem gebäude liegt und den gleichen namen hat, sollte nur ein name dargestellt werden, Ich würde den des POI bevorzugen. Man sollte auf keinen Fall den Knoten _und_ das Gebäude taggen. Jedes Feature in der Realität sollte nur _einmal_ in der Datenbank drin sein. Wenn ein Programm mit diesem einfachen Grundsatz nicht zurechtkommt, ist das nicht unser Problem. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen kann manchmal wichtig und rich tig sein (war Routerhärtetest )
Man sollte vielmehr die renderer bzw. den präprozessor fixen. Wenn ein POI (node) in einem gebäude liegt und den gleichen namen hat, sollte nur ein name dargestellt werden, Ich würde den des POI bevorzugen. Man sollte auf keinen Fall den Knoten _und_ das Gebäude taggen. Jedes Feature in der Realität sollte nur _einmal_ in der Datenbank drin sein. Das stimmt bei datenbanken im allgemeinen, aber nicht mehr solchen wildwuchsprojekten wie OSM. Eine gewisse redundanz in den daten ist bei uns geradezu überlebensnotwendig. Nein, sie ist schädlich. Wenn ein Programm mit diesem einfachen Grundsatz nicht zurechtkommt, ist das nicht unser Problem. Du bist schon lustig ;) Genau andersrum wird ein schuh draus. Manche kinder brauchen etwas länger, um schwimmen zu lernen. Deswegen nimmt man denen aber noch lange nicht die schwimmflügel weg, nur weil ein paar andere die nicht mehr brauchen... So etwas nennt man auch rückwärtskompatibel. Und warum genau das eine schlechte Idee (zumindest in unserem Stadium), hab ich mich schon mehrmals drüber ausgelassen (siehe Archiv). -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pferdestall
Was mache ich aber mit dem eigentlichen Reitstall? building=yes + horse=yes? Damit könnte man dann ja auch einen Kuh (cow=yes) oder Schweinstall (pig=yes) taggen :) horse=yes würde ich nicht nehmen, weil das schon für Zugangsberechtigungen (reiten erlaubt/verboten) in Benutzung ist. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte für Schweiz und Südtirol
Eine Route ist die Verbindung zwischen zwei Wegweisern. Wegweiser haben hier (meistens) einen Namen und referenzieren sich somit gegenseitig. Das ergibt zusammen mit den Markierungen eine ausgeschilderte, objektiv verfolgbare Route. Dann reduziert sich das Problem schlichtweg darauf: Eigentlich wollen wir das Gleiche. Nur mit unterschiedlichen Tags. Für Dich heißt es in Deiner Beispielrelation: note = Staubern-Kastensattel name = fehlt Für mich ist das ein Mißbrauch von note [1], da es keine ergänzende Mitteilung für Mapper/Bearbeiter ist sondern eine handfeste Kennzeichnung der Relation. Doch, es ist eine Mitteilung an den Mapper, dass es sich um den Wanderweg Staubern-Kastensattel handelt. Aber wenn du meinst, dass das nicht da reinpasst, solltest du es trotzdem nicht in den name-Tag schreiben. Namen sind für mich so etwas wie Jakobsweg, Via Mala etc. Viele Wanderrouten haben so etwas einfach nicht. Das was du verwendest, ist aber eher eine Beschreibung. Wenn ich dich richtig verstanden habe, brauchst du das ja sowieso nur, um die Relation von Hand in eine Liste aufzunehmen, damit sie gerendert wird. Warum renderst du nicht automatisch alle Routen? Grüße, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte für Schweiz und Südtirol
Namen sind für mich so etwas wie Jakobsweg, Via Mala etc. Viele Wanderrouten haben so etwas einfach nicht. Das was du verwendest, ist aber eher eine Beschreibung. Nein. Wenn auf der Wandertafel oder auf dem Wegweiser oder im Verzeichnis der Wanderwege steht Wanderweg nach XXX dann ist das der Name des Weges. Wenn Menschen ihn so nennen, um sich zu verständigen, dann ist es der Name des Wegs. Nein. Wenn ich eine Tierart ein schwarz-weiß gestreiftes pferdeähnliches Säugetier nenne, um mich zu verständigen, ist das eine Beschreibung, genauso wie Wanderweg nach XXX. Der Name der Tierart wäre Zebra (aber sie könnte genausogut auch keinen Namen haben). Umgekehrt: Wenn das alles nur Hinweise sind, dann ist Jakobsweg auch kein Name eines bestimmten Weges, sondern nur der Hinweis auf die Zugehörigkeit zu einem bestimmten Wegenetz. Beim Jakobsweg trifft das mit dem Wegenetz vielleicht zu, aber die Via Mala bezeichnet genau einen Weg zwischen zwei Orten. Andere Beispiele sind die diversen Rennsteige. Wenn es zwischen zwei Orten A und B mehrere Routen gibt, dann sind das alles Wanderwege von A nach B. Aber jeder davon kann einen anderen Namen haben. Wenn ich dich richtig verstanden habe, brauchst du das ja sowieso nur, um die Relation von Hand in eine Liste aufzunehmen, damit sie gerendert wird. Das hast Du falsch verstanden. Warum renderst du nicht automatisch alle Routen? Weil das nicht automatisch geht: 1. Die Symbole müssen beim Großteil der Routen von Hand eingetragen werden. Auch mit osmc:symbol müssen die Fehler in den Tags korrigiert werden Aber beides doch in der OSM-Datenbank, nicht in einer externen Liste, oder? 2. Ohne Namen kann ein Weg nicht in das Wegeverzeichnis eingetragen oder von irgendjemand wiedergefunden werden. Damit kommt man nicht mehr an die Zusatzinformationen (Wegverlauf, Betreiber, Länge, Wiki/Weblinks) ran. Da gibt es verschiedene Möglichkeiten: man könnte für diesen Zweck ein neues Tag erfinden, oder man könnte eine Bezeichnung generieren (route=hiking, symbol=Roter Kreis = Wanderweg Roter Kreis bei Heidelberg). Oder zuerst Namen, dann ref, dann selbsterzeugte Bezeichnung probieren. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenstand bei OpenRouteService.org
in letzter Zeit sind mir verstärkt seltsame Stellen bei der Routenplanung von openrouteservice.org aufgefallen. Mal wurden Wege und Straßen nicht berücksichtigt, mal lag die Route ein Stück neben dem Weg oder der Straße. Wenn ich mir an diesen Stellen die history der betroffenen Wege anschaue, komme ich zu dem Schluss, dass die Daten mittlerweile für osm-Verhältnisse ziemlich alt sind; ich schätze das Datenalter im Moment auf etwas über 3 Wochen. Laut wiki sollte eigentlich jeden Dienstag eine Aktualisierung durchgeführt werden... Was ist da los? Leider ist auch seit einiger Zeit der Menüpunkt News verschwunden, so dass man nicht mehr feststellen kann, wann die letzte Aktualisierung erfolgt ist. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kindergarten
Dann hoffe ich mal darauf, dass die Renderer entsprechend angepasst werden. Momentan wird die amenity=Kindergarten als Gebäude dargestellt, oder jedenfalls als oberster layer. Building=yes auf demselben Gelände scheint nicht durch, dafür werden die Straßen teilweise verdeckt, und die Einfärbung entspricht auch den Gebäuden (und der Namefinder findet sie nicht). http://www.openstreetmap.org/?lat=53.64181lon=10.03891zoom=17layers=0B00FTF Im Zentrum, Gelände Hummelsbüttler Hauptstraße 72A, Mikuteit Kann es sein, dass es am building=no liegt? Wahrscheinlich hat der Mapnik eine Regel, die alle building=* als Gebäude interpretiert... Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwei OSB-Seiten?
habe ich gestern mal mit gespielt und hatte meine Probleme: Karte sprang wild hin und her, Bug-Marker waren an falscher Stelle, Zoom-Regler war nicht in sync mit dem tatsächlichen Zoom. Das kann ich bestätigen, auch wenn es nur sehr selten passiert. Manchmal bleiben bestimmte Marker beim Zoomen an der Stelle stehen, wo sie im vorherigen Zoomlevel waren. Das passiert meistens bei neu angelegten Bugs, ich habe es aber auch schon bei bestehenden erlebt (dann gleich bei mehrere auf einmal). Browser: FF 3.0.11 (nicht sicher, obs bei 3.5 auch passiert) Grüße, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt Postleitzahlen
Am Sonntag 21 Juni 2009 03:36:03 schrieb Mirko Küster: Ticket habe ich nicht aufgemacht. Von jemand anderes habe ich nur gehört das diese bekannt sei und einer etwas ungenaueren Programmierung in OSM liegt. Da ich kein Programmierer bin, kann ich dazu nichts sagen. Und Tickets überlasse ich denen die Englisch können. Die Koordinaten werden in der Datenbank soviel ich weiß als 32bit-Integer gespeichert. WIMRE führt das zu einer Genauigkeit von ca. 10-20cm. Könnte es daran liegen? Punkte auf einen Meter genau festzulegen dürfte aber dann trotzdem kein Problem sein. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] User: Kraftfahrstra?e Edit-War
Achja, wie verfährt man mit einer Straße, die am einen Ende per VZ 267 gesperrt ist, jedoch am anderen Ende kein Einbahnstraßenschild hat und in der auch alle Eingeborenen in beiden Richtungen umherfahren? Bisher habe ich mich damit beholfen, am verbotenen Eingang fünf bis zehn Meter Einbahnstraße zu deklarieren. Das hab ich früher auch so gemacht; jetzt wo wir Relationen haben, benutze ich Abbiegevorschriften dafür. Grüße, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] forest wood und Layer
Zu der Problematik landuse in landuse u.ä. ist hier vor kurzem ein Ticket aufgemacht worden: http://trac.openstreetmap.org/ticket/1953 Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] forest wood und Layer
Zu der Problematik landuse in landuse u.ä. ist hier vor kurzem ein Ticket aufgemacht worden: http://trac.openstreetmap.org/ticket/1953 wobei das hier m.E. nicht relevant ist, da parks kein landuse sind (bei OSM), sondern leisure. Doch, das passt schon. Ich hätte es nur allgemeiner formulieren sollen: Fläche in Fläche. Grüße, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] area und Wegrichtung
Wie wendet man richtungsabhängige Tags (z.B. oneway) auf Straßen an, die mit area=yes getaggt sind? Soll ein zusätzlicher einfacher Weg angelegt werden, der die entsprechenden Attribute kriegt, analog zu Flüssen? Welche Tags sollen dann auf diesen Weg, welche auf die Fläche? Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] area und Wegrichtung
Wie wendet man richtungsabhängige Tags (z.B. oneway) auf Straßen an, die mit area=yes getaggt sind? Soll ein zusätzlicher einfacher Weg angelegt werden, der die entsprechenden Attribute kriegt, analog zu Flüssen? Welche Tags sollen dann auf diesen Weg, welche auf die Fläche? areas haben per se keine Richtung. Wenn da zusätzlich ein Way mit einer Richtung ist (z.B. oneway), würde ich das auch als solchen zeichnen, wie Du ja auch vorschlägst: extra Way. Die Tags jeweils an den passenden Way hängen. Was ist denn konkret die Sache, die Du darstellen / eintragen willst? Konkret geht es darum, dass ein Benutzer den Fußgängerteil der Richard-Wagner-Straße in Bayreuth in eine Fläche umgewandelt hat: http://www.openstreetmap.org/?lat=49.942973lon=11.579238zoom=18layers=B000FTF Dieser ist jedoch auch eine Einbahnstraße (wahrscheinlich für Lieferverkehr zu bestimmten Uhrzeiten; ist noch nicht getaggt). Leider geht dadurch eben diese Richtungsinformation verloren. Bei Flüssen wird aus dem Grund ja zwischen den Umrissen (waterway=river_bank) auch noch ein linearer Weg mit waterway=river angelegt. Prinzipiell ist dieses Verfahren hier auch möglich, ich bin mir nur nicht sicher, wie dann der lineare und der flächige Weg getaggt werden müssen. Erhalten beide das highway-Tag? (Wohl schon.) Erhalten beide oneway=true? (Eher nicht.) Was ist mit name, access, usw.? Grüße, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] area und Wegrichtung
Am Mittwoch 10 Juni 2009 16:09:28 schrieb Martin Koppenhoefer: Am 10. Juni 2009 15:51 schrieb Tobias Knerr o...@tobias-knerr.de: Martin Koppenhoefer schrieb: inwiefern ist es für das Routing ein Problem, wenn es 2 anstatt einer Möglichkeit gibt? An einer der 2 Möglichkeiten kann man die Einbahnstraßeneigenschaft nicht sinnvoll unterbringen (weil eine Fläche keine Richtung hat). Daher wird die Straße weiterhin in beide Richtungen befahrbar sein. daher sollte man ja auch die Erlaubnis für Lieferverkehr nur an den einzelnen way, nicht an die area hängen. Das funktioniert aber erstens nicht im allgemeinen Fall, und zweitens ist es eigentlich falsch, weil auf der Fläche der Lieferverkehr genauso fahren darf. Man bräuchte entweder eine Möglichkeit, einem flächigen Objekt eine Richtung zu geben, oder umgekehrt, einem linearen Objekt eine Fläche zuzuordnen. Vorschlag: Relation type=outline Member way = ein linearer Way (oder vielleicht mehrere?) Member outline = geschlossener Way, der die Fläche beschreibt Der Outline-Weg bleibt wohl im Normalfall ungetaggt; Renderer können dann die Attribute vom Hauptweg übernehmen, und Router können ihn ignorieren. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] meinungsbild botlauf für geordnete rel ationen - was: Neuigkeiten von der ÖPNV-Karte
Am Mittwoch 10 Juni 2009 17:30:29 schrieb Frank Sautter: hallo zusammen, Jochen Topf schrieb: On Wed, Jun 10, 2009 at 01:30:25PM +0200, Rolf Bode-Meyer wrote: Wie mache in eine Linienrelation also ordered? Das ist leider etwas schwierig und eigentlich sollte das auch automatisiert geschehen (Frank Sautter wollte sich das glaube ich mal anschauen). Wobei das nur dort automatisch gefixt werden kann, wo die Reihenfolge eindeutig ist. nachdem seit der api 0.6 relationen geordnet sein können und es von verschiedener seite die anforderung gibt, würde ich gerne hören, ob es einwände gegen eine automatische sortierung der ways anhand ihres anfangs- und endnodes gibt. später könnte auch noch eine geographische sortierung von teilstücken einer route erfolgen, bei der es noch lücken gibt. ebenso könnten einzelne, neben den ways liegende nodes geografisch sortiert werden. das ganze soll eher defensiv programmiert werden, sodass bei nicht eindeutig zu lösenden fällen die relation nicht angefasst wird, sondern im logfile eher als problemfall zur händischen bearbeitung markiert wird. Es sollte auch nur Relationen betreffen, bei denen die Sortierung überhaupt relevant ist. D.h. Routen, Buslinien ja, (advanced) Multipolygons m.W. nicht. Also lieber nicht auf Verdacht alle gefundenen Relationen sortieren. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FreieTonne - Seekarteninformationen/ Seezeichen nach OSM kopieren
tag k=minzoomlevel v=9/ Das wird wohl dafür verwendet, um eine Art von Wichtigkeit für die einzelnen Objekte festzulegen. Es ist wahrscheinlich besser, stattdessen mehrere objektive Eigenschaften anzugeben. Beispiele: - warnt das Seezeichen vor Gefahren, oder dient es nur zur Information? - wieviel Verkehr herrscht auf der jeweiligen Wasserstraße? Dann können die Auswertungsprogramme (meistens Renderer) selber entscheiden, was für ihren speziellen Anwendungsfall am wichtigsten ist, und dieses dann entsprechend ab einem niedrigeren Zoomlevel darstellen. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Workshop
Das Problem ist eher noch das Mitgliederhandling: Bei einer Linienrelation muss man die Mitglieder sortieren. Das ist bisher häufig nicht der Fall, weil das vor 0.6 ja nicht ging. Ist aber schwierig zu sehen, wenn man den Relation-Editor offen hat, wo die verschiedene Mitglieder sind. Das könnte der Editor von alleine machen. Es müsste dafür eine Liste von Relationstypen angelegt werden, mit Informationen darüber, ob automatisch sortiert werden soll, und ob Elemente doppelt vorkommen dürfen. -- Nur bis 31.05.: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Für z12-z14 bin ich zum Mapnik-Stil übergegangen, da man da anders gar nix mehr erkannt hat und nix zu optimieren ging... Diesen Stil finde ich generell ziemlich gut; die Tracks und auch die Residentials sind bei niedrigem Zoom viel besser zu erkennen. Was meiner Meinung nach nicht ganz so schön ist sind die Fuß- und Radwege (besonders letztere): http://www.openstreetmap.org/?lat=49.895lon=10.9201zoom=14layers=0B00FTF Das sieht alles aus wie ein hellgrüner Brei, man muss sich schon sehr konzentrieren, um die einzelnen Wege auseinanderhalten zu können. Wenn man rauszoomt, wirds noch schlimmer. Bei den Feldwegen (z.B. weiter nördlich in dem großen Kleingartengebiet vor Hallstadt) kommt mir das nicht so schlimm vor, deswegen vermute ich, dass es an der grellen Farbe liegt. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Daneben wird es noch mässige Geschwindigkeit, Ortsgeschwindigkeit, Richtgeschwindigkeit,etc. geben. Warum willst Du verhindern dass man auf Anwendungen mit OSM quasi verzichten muss die darauf aufbauen dass man für jeden Streckenabschnitt einen expliziten Geschwindigkeitsgrenzwert hat - und das nicht nur die nächsten paar Wochen? Damit hat man eine saubere Schnittstelle zwischen Datensammlung und Applikation. Die Applikation muss nicht unbedingt wissen wie der Wert zustande kam (welche aktuelle Gesetzgebung, Land,...) Und auf der Datenbankseite kann man Prüfmechanismen loslassen die die plausibiltät des Wertes prüfen. *gähn* Vorverarbeitung *gähn* ... (zum x-tausendsten mal) Und über das Warum bist du auch schon oft aufgeklärt worden. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Am Freitag 22 Mai 2009 21:04:11 schrieb Garry: Marc Schütz schrieb: Daneben wird es noch mässige Geschwindigkeit, Ortsgeschwindigkeit, Richtgeschwindigkeit,etc. geben. Warum willst Du verhindern dass man auf Anwendungen mit OSM quasi verzichten muss die darauf aufbauen dass man für jeden Streckenabschnitt einen expliziten Geschwindigkeitsgrenzwert hat - und das nicht nur die nächsten paar Wochen? Damit hat man eine saubere Schnittstelle zwischen Datensammlung und Applikation. Die Applikation muss nicht unbedingt wissen wie der Wert zustande kam (welche aktuelle Gesetzgebung, Land,...) Und auf der Datenbankseite kann man Prüfmechanismen loslassen die die plausibiltät des Wertes prüfen. *gähn* Vorverarbeitung *gähn* ... (zum x-tausendsten mal) Ja ich weiss dass Du dafür nichts besseres zu bieten hast... Und das von einem, der lieber unbedingt was schlechteres durchsetzen will... Und über das Warum bist du auch schon oft aufgeklärt worden. Wie kann man über etwas Aufklären was man nicht versteht? Natürlich, die Leute haben alle keine Ahnung, von was sie reden. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtung von Ways - Digitalisierungsrichtung (was: Fahrradwege)
Im naechsten Schritt sind, wie bei einem API-Versionswechsel, auch alle Editoren und sonstige Werkzeuge anzupassen, so dass einige Tags wie oneway=... und wenn man sich auf left/right, forward/backward bezieht, diese beim Drehen des Weges ebenso automatisch gedreht werden ... oder eben eine Warnung erscheint. Wenn alle, die dieses Argument bei jeder Gelegenheit vorbringen nur je eine Zeile Code schreiben wuerden, haette JOSM schon lange eine Info-Box, die einen warnt sobald man einen Weg dreht, bei dem irgend ein key oder irgend ein Wert left/right oder forward/backward enthaelt. :) Diese Funktionalität existiert bereits seit geraumer Zeit. Das betrifft oneway sowie alle Schlüssel, die mit left, right, forward und backward anfangen. Wenn man so einen Weg umdreht, kommt ein Dialogfenster, das vorschlägt, die Tags entsprechend mit umzudrehen. Man braucht nur noch auf Anwenden klicken. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
das einzige was wirklich definiert ist, ist der wert schrittgeschwindigkeit! ganz einfach, kein aufwand. ... und technisch nicht verwertbar Oder erklär mir mal wie Du einer Maschine beibringst dass sie mit Schrittgeschwindigkeit durch einen verkehrsberuhigten Bereich fahren soll... Ganz einfach: man gebe der Maschine eine konkrete Geschwindigkeit vor, die in der jeweiligen Jurisdiktion/Umgebung als Schrittgeschwindigkeit akzeptabel ist. Um das zu können, muss man natürlich erstmal wissen, dass Schrittgeschwindigkeit gilt, und nicht 7 km/h. in der stvo steht der wert kein limit, warum also irgendeine an den haaren herbeigezogene zahl benutzen?!? weil bei Lichtgeschwindigkeit bereits alles hinter Dir ist was Du wahrnimmst - Klarer Verstoss gegen §3... Man soll eine an den Haaren herbeigezogene Zahl verwenden, weil bei LG bereits alles hinter einem ist!? -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Ganz einfach: man gebe der Maschine eine konkrete Geschwindigkeit vor, die in der jeweiligen Jurisdiktion/Umgebung als Schrittgeschwindigkeit akzeptabel ist. Um das zu können, muss man natürlich erstmal wissen, dass Schrittgeschwindigkeit gilt, und nicht 7 km/h. Ja klar - ganz einfach formuliert - über die Umsetzung musst Du Dir ja keine Gedanken machen, dass Problem hast Du ja ganz einfach - abgewälzt. Ganz und gar nicht. Ich hab eine Lösung für das Problem angegeben: in die Datenbank kommt das was in die Datenbank gehört, und in die Anwendung kommt das was in die Anwendung gehört. Aber das haben dir schon genug Leute erklärt. So wird aus einer einfachen, zweckmässigen und schnell umsetzbaren Problemlösung ein riesen Projekt mit vielen schwer lokalisier- und schwer behbaren Fehlerquellen. Lieber eine Lösung mit möglichen Fehlerquellen als eine, die von vornherein falsch ist. Es ist ein bewährtes Vorgehen in der Technik dass man Wertebereich auf die realistisch vorkommende Werte einschränkt um u.a. Fehler leichter erkennen und gegebenfalls beheben zu können. Genau. Realistisch vorkommende Werte sind z.B. 100, 80, walking_speed, none, etc. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sonderzeichen beim Import von Daten
Negernb?tel 4 - ich hoffe das kommt bei Euch richtig rüber ! Kann mir einer sagen wie ich diese z.b. unter Notepad ++ abspeichern muss damit JOSM die Umlaute richtig annimmt. Keine Ahnung welchen Charset JOSm verwendet aber ich würde pauschal UTF-8 vermuten, also die Datei als UTF-8 speichern. Der Zeichensatz ist normalerweise in der ersten Zeile des XML-Files deklariert, typischerweise als UTF-8: ?xml version='1.0' encoding='UTF-8'? Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Weg-Style
Beim rendern von tracktype=gradex sah man m.E. kaum die Unterschiede auch nicht mit den Mittellinien, die irgendwann mal eingefuehrt wurden. Habe daher an den Strichstaerken geschraubt und zudem die Strichlierung des Randes geaendert, damit es besser zur Strichlierung von Mapnik passt, damit man nicht immer umdenken muss... ;-) http://daten.mueck.de1.cc/osm/grades-z15.PNG zeigt ein Beispiel, bei dem ich ie tracktypes auch noch reingemalt habe zur Orientierung. Oben am Rand und links sieht man auch noch Bereiche mit altem Rendering. Also ICH sehe im Wald keine Unterschiede der grades beim alten Rendering... Unterschiede: alt: grade1 = grau durchgezogenes casing grade2 = braun durchgezogen grade3 ff = braun strichliert in div. Varianten neu: grade1 = braun durchgezogen grade2 = braun strichliert, Strich laenger als Luecke grade3 = braun strichliert, Strich kuerzer als Luecke grade4 = braun strichpunktiert grade5 = braun punktiert ohne grade = braun strichliert mit sehr kurzer Luecke, also zwischen 1 und 2 Zu sehen in http://daten.mueck.de1.cc/osm/surface_rendering2.PNG Zoom level 15 gefaellt mir ganz gut, ich glaube, ich kann den core in 16 und 17 wieder leicht breiter machen, in: http://daten.mueck.de1.cc/osm/grades-z16.PNG http://daten.mueck.de1.cc/osm/grades-z17.PNG werden die Wege fast schon zu aufdringlich, oder? Ja, ich finde die sind zu dick. Das fällt besonders auf, wenn man sie mit den anderen Wegen vergleicht. Das erweckt den Eindruck, dass die Feldwege wichtiger sind als normale Straßen, oder irgendwie absichtlich hervorgehoben sind. http://www.openstreetmap.org/?lat=49.9213lon=10.88064zoom=17layers=0B00FTF Um die Erkennbarkeit im Wald und anderen landuses zu gewährleisten, wäre es evtl. möglich, den weißen Rand zwischen dem Casing und der Umgebung auf 2-3 Pixel zu erhöhen, und dafür die Linien wieder dünner zu machen? Es gibt im übrigen noch eine kleine Hässlichkeit (die wahrscheinlich schon vorher existiert hat, aber jetzt mehr auffällt): http://www.openstreetmap.org/?lat=49.96052lon=11.5715zoom=17layers=0B00FTF Der Feldweg zum Morethsgut und das Stück, das von dort aus Richtung Wald weitergeht, wird von abzweigenden Feldwegen niedrigerer Ordnung überdeckt. Mit surfaces und smoothness fuer alle highway-Arten bin ich nicht ganz so zufrieden... http://daten.mueck.de1.cc/osm/surface_rendering.PNG http://daten.mueck.de1.cc/osm/surface_rendering2.PNG Man erkennt die Unterschiede kaum, mit mehr Strichstaerke waere es wohl zu prominent, mehr Groesze der Symbole geht auch nicht, da die dann groeszer als die Wegbreite werden, ... Die Farben, die die smoothness bedeuten sollen (von blauelich-gruen fuer excellent ueber gelb und rot zu dunkellila fuer impassable) erkennt man auch kaum... In den Beispielen sieht man umgedrehtes Kopfsteinpflaster ;-) fuer ground und ein Muster fuer gravel auf den anderen Wegen, vereinzelt auch grass (ueber dem Kanalweg im 1.), auf den besseren asphalt und auf dem 2. auch paving_stones Sehr schade eigentlich; es wäre schön, wenn sich eine Lösung für die Oberfläche finden würde. Das Tag ist fürs Behinderten- und Fahrradrouting relativ wichtig, und es ist erfahrungsgemäß ein guter Anreiz für die Erfassung von Straßeneigenschaften, wenn man die dann irgendwo anschauen kann. Apropos: neu ist in z17 auch das Rendering von cutting=yes und embankment=yes, also EInschnitte und Daemme. Da habe ich aber gerade kein passendes Beispiel, weil der letzte Durchlauf nach alten Regeln erfolgte an der Stelle, wo ich Daemme ergaenzte. Die habe ich zudem gerade von feldwegbraun auf gruen umgestellt... Sonst koennte man einen weglosen Damm fuer einen Feldweg halten... Das gefällt mir nicht so ganz. In normalen Karten findet man die Farbe grün für sowas eigentlich nicht, eher braun und schwarz. Grün verbinde ich irgendwie mit Gras/Natur, was ja keine primäre Eigenschaft von Dämmen ist. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiles-Generierung mit Mapnik momentan wieder lahm?
ich hab mitbekommen, dass letztens das Intervall verkürzt wurde, in dem neue Tiles generiert werden. Das hat dann den erfreulichen Effekt gehabt, dass ich teilweise bereits nach 10min die ersten Auswirkungen auf der Karte gesehen hab. Jetzt scheint das aber nicht mehr der Fall zu sein. Ich hab Anfang der Woche was geändert und sehe noch immer keine Anpassung der Mapnik-Karte. Osmarender frissts aber bereits. Was ist da los? Das ist wegen Arbeiten am Server vorübergehend bis morgen außer Betrieb gesetzt: http://lists.openstreetmap.org/pipermail/talk/2009-May/036875.html -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Gebäude in Google-Pseudo-3D ?
http://artem.dev.openstreetmap.org/files/osm_3d.png weiß jemand Näheres? Das ist ein Test von Artem Pavlenko, den er hier angekündigt hat: http://lists.openstreetmap.org/pipermail/talk/2007-September/018019.html Hier geht der Thread weiter: http://lists.openstreetmap.org/pipermail/talk/2007-September/018059.html -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhlen / Höhleneingang
Wie sollte man nun eine Höhle am besten taggen? Die Höhle selbst als tourism: attraction und den (die) Eingang (Eingänge) zusätzlich als natural: cave_entrance? Ich würde den Eingang auf jeden Fall als natural=cave_entrance taggen, und falls gegeben auch noch als tourism=attraction. Nicht jede Höhle ist ja eine Touristenattraktion. Wenn es denn mal eine Möglichkeit gibt, die Höhle als ganzes zu modellieren (z.B. mit einer Relation), dann sollte natürlich diese statt dem Eingang als attraction getaggt werden. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Featurevorschlag Gewichtung für OSB
Irgendwie habe ich den Eindruck, dass wir zumindest teilweise aneinander vorbeireden. Es ging einzig und allein darum: * Es wurden weitere, komplexere Features vorgeschlagen * Ich finde, für den Einsteiger sollte OSB nicht komplexer werden Es gibt z.B. folgende Möglichkeiten: a) keine weiteren Features in OSB einbauen b) jedem die vermutlich bald kompliziertere Oberfläche zumuten c) verschiedene Seiten für expert.OSB und newbie.OSB einsetzen d) einfache Oberfläche im Web, Expertenoptionen im Editor(-plugin) e) OSB konfigurierbar machen und e1) Konfiguration einem Account zuordnen e2) Konfiguration über Cookie speichern (nur auf einem Rechner, wird eventuell gelöscht ...) Ich habe neben e1) auch e2) und d) schon erwähnt. a) und b) finde ich nicht so toll. Welche Option bevorzugst du? Ich würde bevorzugen, zum jetzigen Eingabedialog einen Link Erweitert hinzuzufügen, der die Box vergrößert und weitere Eingabemöglichkeiten sichtbar macht. Der Zustand kann dann in einem Cookie gespeichert werden (es wird ja sowieso schon eines genutzt, um den eingegebenen Namen zu speichern). Im zweiten Schritt könnte man dann für wirkliche Poweruser eine Login-Option einbauen mit den üblichen Bugtracker-Funktionen (Meine Bugs usw.), natürlich alles optional. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
1. sollte man den Namen angeben, auch wenn es eher nur ein Identifier ist? 2. gibt's hierfür ein besseres Tag als name? Nimm note. Dürfte für den Zweck, über den Sinn der Relation zu informieren, passen. Euch ist schon klar, daß wir damit anfangen uns hier richtig gut zu verzetteln? Bisher waren die Begriffe Name und Note klar - dachte ich zumindest und habe zumindest nie ein Element gesehen, wo das anders benutzt wurde als ich es auch setzen würde. - Name = Name - Note = interner Hinweis für Mapper, häufig sowas wie fixme oder mit längerem Text Jetzt bekommen wir ein Mischmasch aus: - Name_für_die_Karte - Note_als_Workaround_Name_für_Mapper - Note als Kommentarfeld für alles Während der Editor richtig bemerkt nur zur Eingabe eines Namens einlädt. Wäre es nicht sinnvoller, das Problem an der Wurzel anzupacken? Deshalb nochmal die Frage: Warum erscheint der Name einer Relation auf der Karte? Relationen an sich werden nicht gerendert, der Name muß durch einen zusätzlichen Mechanismus auf die Karte kommen, was in diesem Fall ein Fehler ist. Sollten wir in diesme Fall nicht lieber den Fehler beheben anstatt die Bedeutung von häufig verwendet Tags durcheinanderzuwürfeln? Das klappt jetzt in diesem Fall, aber: - wieviele andere Relationen müßten jetzt auch von name auf note geändert werden? - Wieviele neue Relatioen werden umgeändert müssen? - Was ist mit echten Notes mit Kommentarcharakter und Langtext? Einfach löschen? Oder ein neues Tag Note_note einführen? :-) - Wie lange funktioniert dieses Flickwerk bevor das nächste Problem es eh zu Fall bringt? - Wir taggen nicht für den Renderer? Aber wir verschmieren jetzt die Bedeutung lange benutzter Tags um diesen Effekt einzudämmen? Das ist meiner Meinung nur das erste Problem mit übereifriger Übernahme von Tags von Relationen. Wir sollten uns die Ursache ansehen, nicht an den Symptomen herumfummeln. Du hast glaub ich den aktuellen Fall völlig missverstanden. Das Problem ist nicht, dass der Name der Relation gerendert wird, sondern dass Martin den name-Tag dazu missbraucht hat, dem Objekt einen Bezeichner zu geben, um es in der Relationsliste von JOSM besser auffinden zu können (einen Bezeichner, der _nicht_ der Name des Objekts, sondern eine Beschreibung davon ist). Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Weil er ein Objekt beschreibt, das auf der Karte dargestellt wird - nämlich ein Multipolygon. Das ist Sinn und Zweck der Sache und kein Fehler. Wie sonst willst Du Waldgebiete, Teiche und andere Multipolygone mit Namen versehen? Eine Lösung des Problems könnte darin bestehen, Relationen mit einem weiteren Tag zu versehen, welches die Darstellung in der Karte beeinflusst. Ich denke dabei weniger an Tag wie osmarender:renderName sondern eher an eine generelle Bewertung zwischen allgemeinrelevant und interner Verwaltungsbezeichnung. Nein. Interne Verwaltungsbezeichnung haben im name-Tag überhaupt nichts verloren. Verwendet einfach (wie gehabt) note oder comment, und das Problem ist erledigt. Ich ärgere mich darüber, dass an der Küstenlinie (oft an unpassenden Stellen) Relationsbezeichnungen wie Schleswig-Holstein (Landmasse), Deutschland (Landmasse) oder Kreis Rendsburg-Eckernförde (Landmasse) stehen. Das sind im Grunde keine physischen Objekte, sondern nur Schnittmengen aus Deutschland und dem Inneren der Küstenlinie. Ich finde es trotzdem sinnvoll, der Relation den Namen Deutschland (Landmasse) zu geben und nicht eine namenlose Relation mit einem Kommentar zu versehen. Man braucht nur eine Möglichkeit, diesen Namen als nicht oder weniger darstellungswürdig zu kennzeichnen. Die hat man schon, nämlich im Stylesheet des Renderers. Abgesehen davon heißt das von der Relation bezeichnete Gebiet bestimmt nicht Schleswig-Holstein (Landmasse), sondern das ist eine Beschreibung und ist daher im name-Tag an der falschen Stelle. Ich kann mir viele Relationen vorstellen, die in die OSM-Datenbank passen und einen Namen haben, der aber nicht in der üblichen Karte auftauchen sollte: Historische Grenzen (vom der mittelalterlichen Staatsgrenze bis zur im letzten Jahr fusionierten Gemeinde, die noch in verschiedenen amtlichen Verordnungen genannt ist), Außengrenze der Schengen-Staaten, Wasserschutzgebiete, alte Bahntrassen, etc. Hier gilt das gleiche wie oben: wenn der Betreiber des Renderers alte Bahntrassen anzeigen lassen will, soll er sie ins Stylesheet eintragen, wenn nicht, soll er sie rauslassen. Man muss halt nur sauber zwischen name, comment und note unterscheiden. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Du hast glaub ich den aktuellen Fall völlig missverstanden. Das Problem ist nicht, dass der Name der Relation gerendert wird, sondern dass Martin den name-Tag dazu missbraucht hat, dem Objekt einen Bezeichner zu geben, um es in der Relationsliste von JOSM besser auffinden zu können (einen Bezeichner, der _nicht_ der Name des Objekts, sondern eine Beschreibung davon ist). Das sehe ich völlig anders. Das Problem ist, daß Nodes und Ways physikalische Objekte sind, aber Relationen Beziehungen zwischen Objekten. Die Beziehung kann, muß aber nicht ein physikalisches Objekt beschreiben. Wie Stephan mit weiteren Beispielen schon dargestellt hat, liegt das Problem darin, stumpf den Namen einer logischen Beziehung oder Gruppierung mit dem von physikalischen Objekten gleichzusetzen. Dieser Schluß ist ungültig. Das ist wieder ein anderes Problem, und da stimme ich dir auch zu. Trotzdem ist das, was Martin gemacht hat, ein Missbrauch des name-Tags. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
name kann ich evtl. noch abgrenzen von den beiden anderen, aber wie ist die Abgrenzung von note und comment? Und vor allem: wo ist das dokumentiert? Note wurde bisher allerorten für alle möglichen Hinweise verwendet und keineswegs nur als Identifier für Relationen. Dafür spricht auch, dass JOSM neben name sowohl comment als auch note berücksichtigt. Klar: man kann jetzt damit anfangen und alle zu einer großen Sichtungsaktion des Bestands auffordern. Am wichtigsten ist, zwischen name und den anderen zu unterscheiden. Nachdem comment hier auf der Liste (oder auf talk) ein paar mal empfohlen wurde, bin ich davon ausgegangen, dass dieses Tag irgendwo genauer definiert wäre. Im Wiki konnte ich jetzt aber auch nix darüber finden. Ich hab die beiden immer so interpretiert: note = beliebige Notiz für andere Mapper, z.B. hier fehlt noch xyz, oder dies ist Absicht, bitte nicht löschen comment = eine Art Beschreibung/Bezeichner des Objekts, z.B. um es in einer Liste leichter identifizieren zu können Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Private Wander/Rad Routen in OSM
Das interessante hierbei ist, diese Software existiert schon mehr oder weniger (JOSM/Portlach + OSM XAPI, Relation als Fileformat), aber Punkt 2 is zwar möglich, soll aber nicht gemacht werden. (= kein Abspeichern privaten Routen in OSM) Aber was spricht dagegen, die private Relation auf deiner privaten Festplatte abzuspeichern? Mir fält gerade der Pferdefuss meiner Idee auf. Wege in OSM können sich ändern (zerteilt and verbunden werden), so meine Liste von way ids wäre wahrscheinlich nach einiger Zeit falsch. Es gibt auch noch das Problem, dass Du ggf. einen way erst mal zerteilen musst, weil er vielleicht zu lange ist. Aber mit so privaten Relationen, die alle zugehörigen Elemente (ways, nodes) enthalten, könnte man doch arbeiten, oder? Das Problem ist, dass wir nicht garantieren können, dass die Wege nicht gelöscht oder (wahrscheinlicher) aufgespaltet werden. Es wäre schön, wenn es ein Programm gäbe, dem man ein GPX o.ä. übergibt, und das dann die dazu passenden OSM-Objekte raussucht. Das würde die lose Anbindung von externen Daten extrem erleichtern. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Private Wander/Rad Routen in OSM
Das Problem ist, dass wir nicht garantieren können, dass die Wege nicht gelöscht oder (wahrscheinlicher) aufgespaltet werden. Es wäre schön, wenn es ein Programm gäbe, dem man ein GPX o.ä. übergibt, und das dann die dazu passenden OSM-Objekte raussucht. Das würde die lose Anbindung von externen Daten extrem erleichtern. Das wäre schön, ist aber faktisch unmöglich, jedenfals mit GPX (oder anderen punkt-Formaten) als Input. Aus einer reinen Liste von Koordinaten die dazu am besten passenden Wege zu finden, hört sich sehr komplizier an und ist ja auch subjectiv. Is es besser auf der Strasse oder auf dem parallelen Wanderweg zu gehen ? Für diesen Fall is es realistischer dies als Routingproblem zu sehen. Also Start- und Endpunk und Vorlieben eingeben einen Weg berechnen lassen. Ich war von einer Datenbasis ausgegangen, wo sich nur Objekt-IDs ändern können, der Rest aber mehr oder weniger fest bleibt. In so einem Fall müsste man nur alle Nodes aus den OSM-Daten als Punkte in das GPX aufnehmen, um die Route relativ einfach rekonstruieren zu können. Allerdings können sich in der Realität auch die Koordinaten ändern, und dann kann es leicht zu Verwechslungen zwischen zwei parallelen Wegen kommen, wie du es beschrieben hast. Mein Vorschlag, siehe nächste Mail, geht ein wenig in die Richtung, eine subjective beste Route von einer Person erstellen zu lassen und dies mit der Community zu teilen. Innerhalb oder außerhalb der Datenbank? Bin schon gespannt... -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte wieder online
Hallo! Die Reit- und Wanderkarte mußte auf ein anderes Hosting umziehen und ist jetzt wieder online. Ihr findet sie unter http://topo.geofabrik.de Das Relief ist verfügbar und derzeit läuft ein Update aller Kartenregionen. Den Fortschritt der Wiederherstellung könnt Ihr im Wiki verfolgen. http://wiki.openstreetmap.org/wiki/DE:OSMC_Reitkarte#Regionstabelle Kleiner Bugreport: In der höchsten Zoomstufe scheinen bestimmte Beschriftungen doppelt zu sein; sie liegen direkt übereinander in zwei verschiedenen Schriftgrößen. Das betrifft zumindest Ortsnamen und Kirchennamen. Hier bei Bamberg sieht man es ganz deutlich: http://topo.geofabrik.de/?zoom=15lat=49.89215lon=10.88872layers=BT Bei der Siebenschläferkapelle sieht man das S, das b und das ll hervorspitzen: http://topo.geofabrik.de/?zoom=15lat=49.85758lon=10.83962layers=BT Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. Warum dann nicht an den Poller motorcar=no? Weil die Router aus mir auch nicht bekannten Gründen access-Tags an Nodes nicht auswerten. Vermutlich weil die intern mit Graphen arbeiten und die Nodes lediglich Verbindungen zwischen Kanten sind. *gähn* nicht für den Router mappen... -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie bezeichne ich das?
Am Donnerstag 07 Mai 2009 20:27:58 schrieb Torsten Leistikow: Ulf Lamping schrieb: Es ist ja einfach nur ein Gebäude, also viellecht einfach building=hut? Wobei das von keinem Renderer und keinem Kartenkonverter erkannt werden duerfte. Bessere Chancen haetten man da schon mit einem einfachen building=yes. Sicher? Zumindest osmarender prüft nur auf building=*. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bug plot
-1 möchte ich eigentlich nicht, da sonst der Fluss schon mal gerne vom Wald überdeckt wird Wo passiert das denn noch? Dieser Fehler sollte eigentlich inzwischen in allen Renderern behoben sein; wenn es trotzdem noch vorkommt, leg bitte einen Bugreport auf http://trac.openstreetmap.org/newticket an. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Ok, das Beispiel war blöd. Also simpler: Poller auf mittelbreiter Straße, so dass man mit 'nem Smart durchkommt, mit einem Mercedes aber nicht. Der Poller an sich stellt also m.E. keine Zugangsbeschränkung dar. Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. Wenn, dann aber andersrum. Das Wiki legt folgende Berechtigungen als Default fest: access=no foot=yes bicycle=yes. Ich finde das sehr vernünftig, denn die Beispiele, die du anführst, sind doch eher seltene Ausnahmefälle. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
So verkommt der maxspeed - tag zur Bedeutungslosigkeit weil jeder was neues dazu erfindet und die Anwendungen gar nicht so schnell hinterherkommen die neuen Tags zu erlernen um noch was sinnvolles damit anfangen zu können... Um so besser - dann entsteht wenigsten gar nicht erst der Eindruck, dass es in diesem Stadium des Projekts irgendwelche Kompatibilitätsgarantien bezüglich unseres Datenmodells gibt. Wenn man mit Beta-Software und -Daten arbeitet, muss man halt immer damit rechnen, dass sich was wichtiges ändert. Hast Du vor einen grossteil der Mapper die OSM gewonnen hat wieder zu vergraulen? Die meisten davon dürdten dabei sein um die Daten einsatzfähig zu machen und nicht um sie als programmiertechnische Spielwiese zu benutzen die man regelmässig platt macht um sie wieder anderst aufzubauen. Mapper werden dadurch nicht unbedingt verkrault, höchstens Datennutzer, die nicht damit leben können, ab und zu mal was ändern zu müssen. Und es ist ja auch nicht das gesamte Taggingschema, das sich ändert. Letztendlich sehe ich nur drei Möglichkeiten: - Man definiert von Anfang an ein gut durchdachtes Taggingschema und Datenmodell, dass möglichst schon alle Sonderfälle abdeckt und das rückwärtskompatibel erweiterbar ist. - Man lässt das Schema sich mit der Zeit entwickeln, besteht aber darauf, dass einmal eingeführte Features für immer gültig bleiben. - Man lässt das Schema sich mit der Zeit entwickeln, verbessert aber Fehler und nicht ganz ausgegorene Teile, und erklärt auch mal nicht benötigte Tags für obsolet. Das erste trifft bei uns offensichtlich nicht zu, das zweite führt letztendlich zu einem Chaos, das keiner mehr überblickt. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
So verkommt der maxspeed - tag zur Bedeutungslosigkeit weil jeder was neues dazu erfindet und die Anwendungen gar nicht so schnell hinterherkommen die neuen Tags zu erlernen um noch was sinnvolles damit anfangen zu können... Um so besser - dann entsteht wenigsten gar nicht erst der Eindruck, dass es in diesem Stadium des Projekts irgendwelche Kompatibilitätsgarantien bezüglich unseres Datenmodells gibt. Wenn man mit Beta-Software und -Daten arbeitet, muss man halt immer damit rechnen, dass sich was wichtiges ändert. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Mittwoch 29 April 2009 17:39:08 schrieb Bernd Wurst: Hallo. Am Mittwoch 29 April 2009 17:14:54 schrieb Guenther Meyer: Schade, dass du jede Parallel-Existenz von pragmatischem und korrektem Wert ausschließen möchtest. wie kommst du da drauf?! Weil maxspeed=7 und maxspeed=walk sich gegenseitig ausschließen. Man kann nicht beide Vorgehensweisen parallel nutzen. Natürlich kann man: da wo Schrittgeschwindigkeit angesagt ist, nimmt man maxspeed=walk, und da wo 7 angesagt ist, nimmt man 7. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Ich möchte gerne maschinenlesbare Daten irgendwo haben. Maschinenlesbar in dem Sinne, dass man keine Datenbanken der jeweiligen Geschwindigkeiten oder whatever mit herumtragen muss sondern einfach numerische Werte. Numerische Werte entsprechen in bestimmten Fällen nicht der Realität; du willst also nichts anderes als aus Bequemlichkeit falsche Daten eintragen... So wie es die map-Features seit Ewigkeiten spezifizieren und so wie es mit Null-Aufwand verarbeitet werden kann. Ich möchte gerne eine Möglichkeit haben, egal aus welchem Grund ein Limit gilt, das Limit numerisch aufzuschreiben. Ob es 100% korrekt ist, ist mir dabei Latte, ... und es stört dich nicht mal :-( Eigentlich müsste damit die Diskussion erledigt sein. es dient dazu, dass man eine Abschätzung treffen kann, wie schnell man da wohl unterwegs sein wird. Das man das mit den korrekten Daten noch viel besser kann, ist schon oft genug erklärt worden. Diesen numerischen Wert, den man intuitiv im tag maxspeed erwartet, kann man nicht mehr setzen wenn da jeder ein anderes Gedicht einträgt. Ich erwarte intuitiv, dass jeder Tag die Wirklichkeit abbildet. Ergo: Es schließt sich aus. Warum nutzt du nicht für deine pingelig genaue Erfassung der Theorie (ohne Rücksicht auf die Praxis) ein tag, das nicht bisher als rein numerisch spezifiziert ist? Warum nicht andersrum? Nehm halt implied_maxspeed=5.66782. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Je länger ich bei OSM dabei bin, umso mehr gefallen mir solche eigentlich total uneleganten Lösungen, denn irgendwie geht das einfach ratz-fatz, keiner muss irgendwelche hässlichen Implikationen beachten und man hat sofort ein Ergebnis. Glaubst du wirklich, dass es schneller geht, an jede Straße ein maxspeed=innerorts hinzuhängen, als schnell ein Polygon um die Stadt rumzumalen? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Dienstag 28 April 2009 17:14:07 schrieb Stefan Dettenhofer (StefanDausR): Marc Schütz schrieb: Glaubst du wirklich, dass es schneller geht, an jede Straße ein maxspeed=innerorts hinzuhängen, als schnell ein Polygon um die Stadt rumzumalen? Ja! Aber die Anzahl der Straßen steigt quadratisch mit dem Durchmesser der Stadt, der Umfang aber nur linear. Selbst mit guter Editorunterstützung (z.B. für selektives Auswählen bestimmter Straßentypen) gibt sich das bestimmt nicht viel. Ein schnell mal herumgemaltes Polygon bringt doch auch nichts. Du müsstest die Ways an der Polygongrenze auftrennen, etc.. Bei Polygonen müsste ich das grad nicht, bei maxspeed schon. Ich plädiere weiterhin dafür, bei maxspeed nur explizite Begrenzungen einzutragen. Wenn jemand unbedingt implizite Tempolimits drin haben will, soll er z.B. implicit_maxspeed verwenden, dann gehen wenigstens keine Informationen verloren. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Dienstag 28 April 2009 17:35:03 schrieb Florian Lohoff: On Tue, Apr 28, 2009 at 04:51:52PM +0200, Mario Salvini wrote: also auf deutschen Landstraßen gilt impliziertes maxspeed=100! maxspeed=none oder no da zu machen wäre schlicht falsch; Diesen Fall gibts in Deutschland nur auf blauen und gelben Autobahnen Wieso? maxspeed=none heisst das keine Geschwindigkeitsbegrenzung existiert. Das ist auf Landstraßen auch so oder steht da ein explizites Schild? Für diesen Fall würde ich eher maxspeed=implicit verwenden; maxspeed=none würde ich so interpretieren, dass hier alle Geschwindigkeitsbegrenzungen aufgehoben wurden. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Mittwoch 29 April 2009 00:10:33 schrieb Gerrit Lammert: Stefan Dettenhofer (StefanDausR) wrote: Ok, aber wie kommst Du auf den Default für *_link? Außerdem wäre es doch sinnvoll, noch die Länderkennung dazuzuschreiben, also: maxspeed=de:city maxspeed=at:motorway maxspeed=it:trunk ... Aber bitte nicht so, dass macht logisch keinen Sinn. Besser maxspeed:de=city etc. Nein, andersrum passt es schon: Die Höchstgeschwindigkeit ist die deutsche Stadtgeschwindigkeit, nicht die deutsche Höchstgeschwindigkeit ist Stadt. Allerdings sollte man dann DE groß schreiben, weil es ein Land bezeichnet und nicht eine Sprache. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] historic=castle Icons
Das Problem oder besser der Wert besteht in kulturellen Eigenheiten, die überraschend oft mit der Sprache einher gehen. Wenn Grönländer 50 verschiedene Begriffe für Scheeneweiß verwenden und Deutsche nur einen. Guckst Du, gell? Ist zwar OT, sollte man aber trotzdem so nicht stehen lassen: http://www.iaas.uni-bremen.de/sprachblog/2007/01/29/schneeschmelze/ -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing - routing über highway=path
Ich route momentan über alle Path und Service aber nicht über Track. Warum denn über path? Das ist doch eine Sammelkategorie für Wege, denen hauptsächlich gemeinsam ist, dass sie für normale Autos jedenfalls nicht bestimmt sind. path: A non-specific or shared-use path http://wiki.openstreetmap.org/wiki/Approved_features/Path http://wiki.openstreetmap.org/wiki/Key:highway Solange da kein car=no dran steht ist das ein befahrbarer Weg. Aus der von dir zitierten Approved features-Seite: The default access restriction of highway=path is open to all non-motorized vehicles, but emergency vehicles are allowed. Also nicht für Autos. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] dpa-Meldung über OSM
www.lau-net/de/baerlocher/osm/Simmelsdorf.html Die Seite scheint defekt zu sein. Jedenfalls kann sie bei mir weder vom FF noch vom IE angezeigt werden. Da war ein Tippfehler drin: http://www.lau-net.de/baerlocher/osm/Simmelsdorf.html -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kann oder darf man Wege in Kasernen oder dergl. in Openstreetmap eintragen?
André Reichelt schrieb: Tobias Wendorff schrieb: André, die Persönlichkeitsrechte in Deutschland verbieten eine Veröffentlichung. Die Frage ist nur, wer sich im Kriegsfall um das Persönlichkeitsrecht schert. Steht der Lampuke vor der Tür und droht mit Atomwaffen, ist der Regierung doch das Recht des Einzelnen egal. Wieso sollte eine europäische Regierung hochauflösende Luftbilder im Kriegsfall ins Internet stellen? Denkst Du, dass Merkel als Heeresführerin dann keine anderen Sorgen hat? Ihr redet aneinander vorbei. Der Punkt ist wohl, dass jegliche Gefahr, die durch selbstgemachte Bilder von Kasernen entstehen könnte, bereits jetzt existiert, weil die feindlichen Regierungen schon jetzt über alle Informationen verfügen, die in den Bildern enthalten sind. Wenn sich also durch Veröffentlichen der Bilder die Gefährdungslage nicht ändert, handelt es sich auch nicht um eine Gefährdung der Sicherheit der BRD. Grüße, Marc -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einschränkungen Taggen
Heisst access=agricultural nicht, dass NUR Agrarfahrzeuge da fahren dürfen? agricultural als Schlüssel bedeutet Landwirtschaftliche Fahrzeuge agricultural als Wert bedeutet zu landwirtschaftlichen Zwecken erlaubt agricultural=yes = der Bauer darf mit seinem Traktor hier entlang fahren, auch wenn er nicht aufs Feld sondern ins Wirtshaus will access=agricultural = der Bauer darf auch mit dem Auto, aber nur zu lws. Zwecken hier fahren Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offene Fragen zur Lizenzumstellung - Keine Diskussion um Lizenzen
Fabian -Patzi- Patzke wrote: Ich würde gerne einfach nur mal ein Meinungsbild dieser Mailingliste über das Vorgehen erhalten. Ich bin kein prinzipieller Gegner der neuen Lizenz, auch wenn sie in einigen Sachen für mich nicht klar genug ist (ev. hat sich das geändert): Z. B. Wenn ich auf einen OSM Ausdruck mit Hand etwas drauf male (z.B. ein Restaurant), muss ich das dann auch in der DB eintragen? Ich habe genau dieses Bsp in der Mailingliste schon einmal gebracht und da war die Antwort eher nein, aber wirklich 100% war das damals nicht. Die Intention ist, dass du das nicht musst. Dass das noch nicht klar ist, liegt einfach daran, dass die Formulierung der Lizenz noch nicht ausgereift ist. Was ich mich mehr stört ist folgendes: Wenn ich mich richtig erinnere, ist geplant, dass die Daten von allen Nutzern, die nicht zustimmen gelöscht werden sollen. Dies ist für mich aus mehreren Gründen problematisch: * Menschen werden dazu gezwungen, im Nachhinein andere Rechte zu vergeben. Ansonsten wird mit der Vernichtung ihrer Arbeit gedroht. Jein. Die Daten stehen weiterhin zur Verfügung, unter der alten Lizenz. Man kann diese also weiterhin nutzen wie bisher auch (das heißt, einschließlich aller Rechtsunsicherheiten, die die alte Lizenz mit sich bringt). Lediglich Verbesserungen an den Daten, die nach der Lizenzumstellung vorgenommen werden, sind dort natürlich nicht enthalten. Ob und wie man die alten Daten mit denen unter der neuen Lizenz kombinieren darf, bin ich überfragt. * Wenn jemand nicht mehr am Projekt teilnimmt oder gar tot ist, wird seine Arbeit vernichtet. Ev. ist OSM noch jung genug, damit das noch kein Problem ist. Wahrscheinlich (hoffentlich) ist das kein Problem. Kritischer sind da die Massenimport u.ä., die evtl. rückgängig gemacht werden müssen, oder abgemalte Luftbilder, wo der Rechteinhaber zwar die selber nichts zu OSM beigetragen hat, aber seine Bilder bereitgestellt hat unter der Annahme, dass die daraus abgeleiteten Daten unter CC-BY-SA stehen werden. * Gibt einen netten Ansatzpunkt für Vandalismus: Einfach irgend ein Tag an jeden Node in Europa hinzufügen und der Lizenzänderung widersprechen, dann werden alle Wege desjenigen User gelöscht, also ganz Europa und das Projekt steht wieder am Anfang. Erstens wird man da eine gewisse Schöpfungshöhe voraussetzen müssen; eine kleine Änderung ist ja auch urheberrechtlich meist nicht schützbar. Zweitens wird man bei deinem Beispiel dann einfach die Version vor dem hinzugefügten Tag nehmen können. Ich wäre mehr für eine Mischform: Wo nicht zugestimmt wird, gilt die alte Lizenz weiter. Ich habe auf jeden Fall keine Lust stundenlang Wege abzufahren, nur weil der frühere Mapper einer Änderung nicht zugestimmt hat. Das rechtliche Konstrukt müsste natürlich noch genau ausgearbeitet werden. Die Frage ist eher, ob es so ein rechtliches Konstrukt überhaupt geben kann. Wenn die zwei Lizenzen sich nicht vertragen, dann ist es schlicht nicht erlaubt, alte und neue Daten zusammen in der DB zu halten oder zumindest irgendwie zu verwenden. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] nur die Elemente einer Relation
wenn ich für das Kreispolygon der Kreisfreien Stadt Emden (http://www.openstreetmap.org/browse/relation/62562/full) aufrufe bekomme ich einen 404-Fehler ! Kann es daran liegen, dass es sich um ein Multipolygon handelt ?? Nein, die API ist hier zu finden: http://api.openstreetmap.org/api/0.5/relation/62562/full http://www.openstreetmap.org/browse/... ist der Datenbrowser. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur ODbl = abgeleitete Werke
Erstens einmal koennen die, die die Daten hochladen, dieses Hochladen an eine vertragliche Bedingung knuepfen, die mit Lizenzen und Schutzrechten nichts zu tun hat (Ich lade nur hoch, wenn ihr mir versichert, dass ihr unter der ODbL veroeffentlicht oder so). Das sehe ich komplett anders. An etwas, an dem ich keine Rechte habe, kann ich keine Rechte geltend machen. Das Nutzungsrecht in Deutschland setzt ein Urheberrecht voraus. Es geht in diesem speziellen Beispiel aber um einen Vertrag zwischen dem DB- Betreiber und dem Mapper. Das hat mit Urheberrecht gar nichts zu tun. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur ODbl = abgeleitete Werke
Am Mittwoch 25 März 2009 16:14:13 schrieb Tobias Wendorff: Marc Schütz schrieb: Es geht in diesem speziellen Beispiel aber um einen Vertrag zwischen dem DB-Betreiber und dem Mapper. Das hat mit Urheberrecht gar nichts zu tun. Die ODbL ist bei uns nur eine Lizenz und kein Vertrag. Mit wem gehe ich einen rechtsverbindlichen Vertrag ein? Mit der OSMF? Hafte ich, wenn ich diesen Vertrag eingehe? Von ODBL hab ich nichts geschrieben. Meine Antwort bezog sich auf deinen Einwand, dass der DB-Herausgeber (= OSMF) die Macht über die Daten hat: Tobias Wendorff: Das Nutzungsrecht räumt nur der Herausgeber der Datenbank ein, nicht der Urheber der Daten! Momentan ist der Herausgeber der Daten der Serverbetreiber. Also hat er die Macht über das Projekt. und auf Frederiks Lösungsvorschlag dazu: Frederik Ramm: Erstens einmal koennen die, die die Daten hochladen, dieses Hochladen an eine vertragliche Bedingung knuepfen, die mit Lizenzen und Schutzrechten nichts zu tun hat (Ich lade nur hoch, wenn ihr mir versichert, dass ihr unter der ODbL veroeffentlicht oder so). Worauf du erwidert hast, dass hierfür ein Urheberrecht notwendig wäre. Dem ist eben nicht so, weil es sich bei dem, was Frederik vorgeschlagen hat, um einen Vertrag zwischen dir und der OSMF (o.a.) handelt, durch den die OSMF gezwungen wird, die von dir gesammelten Daten unter ODBL zur Verfügung zu stellen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur ODbl = abgeleitete Werke
Am Mittwoch 25 März 2009 16:45:43 schrieb Tobias Wendorff: Marc Schütz schrieb: Worauf du erwidert hast, dass hierfür ein Urheberrecht notwendig wäre. Dem ist eben nicht so, weil es sich bei dem, was Frederik vorgeschlagen hat, um einen Vertrag zwischen dir und der OSMF (o.a.) handelt, durch den die OSMF gezwungen wird, die von dir gesammelten Daten unter ODBL zur Verfügung zu stellen. Könnte demnach nicht jeder Nutzung seine eigenen Bedingungen schließen? Nutzer A sagt: Ihr dürft alles damit machen. Nutzer B sagt: Ihr dürft sie nur für unkommerzielle Dinge nutzen. Wenn der Datenbankbetreiber damit einverstanden ist und in der Lage ist, alle Verträge gleichzeitig zu erfüllen, dann natürlich ja. In der Praxis wird der Datenbankbetreiber nur einen Standardvertrag haben, und wem dieser nicht passt, darf halt seine Daten nicht hochladen. So wie jetzt auch: wem unsere Lizenz nicht passt, macht einfach nicht mit. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Wir mappen NICHT die Straße, sondern die abstrakte Mittellinie. Nur der Vollständigkeit halber: es gibt auch noch mindestens eine andere Sichtweise, nämlich: Wir mappen die ganze Straße, abstrahieren diese aber zu einer Linie. Deswegen schließen wir eine Seitenstraße an einer Einmündung direkt an die andere Straße an und lassen nicht ein paar Meter Platz, obwohl die einmündende Straße schon am Rand der anderen Straße aufhört und nicht bis zur Mitte geht. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oneway=yes bei Fahrradwegen und weiteres
normalerweise sind Fahrradwege nur in einer bestimmten Richtung für den Verkehr freigegeben, außer es wird durch ein Zusatzschild so festgelegt. ACK. Überall auf der Welt? Ein Router könnte die Landesgrenzen auswerten? Ich bezweifle, dass die Grundannahme überhaupt in irgendeinem Land gilt. Kann denn mal jemand ein Beispiel einer Region oder Stadt nennen, wo das so ist? Wohlgemerkt: bei highway=cycleway, nicht cycleway=lane u.ä. Grüße, Marc -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oneway=yes bei Fahrradwegen und weiteres
normalerweise sind Fahrradwege nur in einer bestimmten Richtung für den Verkehr freigegeben, außer es wird durch ein Zusatzschild so festgelegt. ACK. Überall auf der Welt? Ein Router könnte die Landesgrenzen auswerten? Ich bezweifle, dass die Grundannahme überhaupt in irgendeinem Land gilt. Kann denn mal jemand ein Beispiel einer Region oder Stadt nennen, wo das so ist? Wohlgemerkt: bei highway=cycleway, nicht cycleway=lane u.ä. highway=cycleway ist doch alleine in Deutschland durch das Rechtsfahrgebot gegeben, welches sich auf alle Arten von Radverkehrsanlagen bezieht - außer natürlich es wird durch Beschilderung auf das Gegenteil hingewiesen. Wenn in einer Straße auf beiden Seiten ein Radweg ist, so darf immer nur der rechts gelegene benutzt werden. Aber diese Radwege machen doch nur einen kleinen Teil aller highway=cycleway's aus! -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oneway=yes bei Fahrradwegen und weiteres
Aber diese Radwege machen doch nur einen kleinen Teil aller highway=cycleway's aus! Okay, ich kenne das nur von Großstädten ... aber in Kleinstädten werden sie ja wohl meist highway=path bicycle=designated foot=designated haben. Da gebe ich Dir recht. Aber auch wenn das auf beiden Seiten steht, muss der Rechte benutzt werden. Mir geht's nicht darum, ob Fußgänger auch drauf dürfen, sondern (wie Bernd schrieb), dass die meisten nicht-straßenbegleitenden Radwege (und ein großer Teil der straßenbegleitenden) in beiden Richtungen befahrbar sind, und deshalb nicht als default oneway=true angenommen werden sollte. -- Nur bis 16.03.! DSL-Komplettanschluss inkl. WLAN-Modem für nur 17,95 ¿/mtl. + 1 Monat gratis!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oneway=yes bei Fahrradwegen und weiteres
Am Mittwoch 11 März 2009 20:31:14 schrieb Patrick Kolesa: Moin, 1] normalerweise sind Fahrradwege nur in einer bestimmten Richtung für den Verkehr freigegeben, außer es wird durch ein Zusatzschild so festgelegt. Der Router routet aber Fahrradfahrer auch entgegen der gesetzlich festgelegten Richtung, sofern highway=cycleway verwendet wird. Wie siehts in diesem Fall mit oneway=yes aus, um die sogenannten Geisterradler zu vermeiden? ;) Da wo ich herkomme (Bamberg) und wo ich mich üblicherweise aufhalte (Bayreuth) ist es genau andersrum: fast alle Radwege sind in beiden Richtungen freigegeben, die einzigen Ausnahmen die mir jetzt spontan einfallen, sind viele, aber auch nicht alle, straßenbegleitenden Radwege, wo auf beiden Seiten der Straße ein Radweg oder eine Radspur ist. Außerdem: wie soll man denn bei einem Fahrradweg, der nicht irgendwie markiert ist, erkennen, in welche Richtung man fahren darf? Oder beziehst du dich nur auf die o.g. Fahrradspuren? 2] Ich fahre öfters auf einer Straße, auf der Radfahrer von Autofahrern mit allerlei Signalen dazu bewegt werden sollen, auf dem nicht benutzungspflichtigen, abgesetzten Radweg neben der Straße zu fahren, der allerdings nicht asphaltiert, sondern nur geschottert ist (was sich nach Regenfällen als wahre Freude erweist). Kann ich dieser Straße einen Tag wie bicycle=not_recommended zuweisen, damit ersichtlich ist, dass Fahrradfahrer hier zwar fahren dürfen, es allerdings wenig Freude macht, dort entlang zu radeln? Gibt es dazu bereits Alternativen oder Möglichkeiten, sowas darzustellen? surface=unpaved oder paved=no Bei subjektiven Bewertungen wie recommended bin ich eher skeptisch. Vielleicht will ja jemand, dass die Schlagsahne, die er im Supermarkt gekauft hat, schon servierfertig ist, wenn er daheim ankommt ;-) 3] Folgende Situation: |F o R| ¦ |R o F| |F o R| ¦ |R o F| | |F :R| ¦ |R: F| | |F:R| ¦ |R:F| |F:R| ¦ |R:F| Eine Straße mit begleitendem Radweg (R), aber mit einem durch Bäume (o) abgetrennten Fußweg (F). Irgendwann hören die Bäume auf und es wird ein getrennter (:) Fuß- und Radweg. Tagge ich dies als highway=* mit cycleway=track und mit einem separat eingezeichnetem Fußweg? Oder nutze ich dieses Tagging erst ab dem ersten Baum und tagge bis dahin mit highway=* und impliziertem Fußweg und cycleway=track? Da bin ich überfragt. Das ist wohl ein Teil von der allgemeineren Problematik, dass eine Straße verschiedene Spuren haben kann, die sich in jeder erdenklichen Art und Weise verzweigen und abbiegen können, jede mit eigenen Eigenschaften. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Client von Drittanbieter deutlich schneller als OpenLayers?
Am Montag 09 März 2009 22:37:09 schrieb Tobias Wendorff: Hallo Community, der Anbieter CARDO [1] hat kürzlich eine OpenStreetMap-Erweiterung rausgebracht [2]. Mir ist nun aufgefallen, dass diese Anwendung _deutlich_ schneller ist, als OpenLayers. Ähnliches haben wir ja mit dem Google Client herausgefunden. Hier eine Demoseite [3] - die Tiles werden von unseren Servern geladen. Wieso ist das Ding so verdammt flott? Der gleiche Ausschnitt ist in OpenLayers (unter Windows XP, Firefox 3) deutlich langsamer. Das Draggen ist wohl ein bißchen schneller, aber das geht bei mir in GoogleMaps noch wesentlich performanter. Das Rein- und Rauszoomen mit dem Scrollrad ist allerdings wesentlich schneller als bei OpenLayers. Da hab ich bei mir immer 1-2 Sekunden Wartezeit. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multipolygon Building wird nicht von mapnik gerendert
hab noch mal nachgesehen, sollte aber auch mit inner und building=yes gerendert werden, hatte gerade noch mal bei mein Referenz Objekt nachgesehen. Die Aussage im Wiki, dass die inneren Grenzen nicht getaggt werden brauchen (= sie können getaggt werden), bezieht sich auf den Fall, dass sich in dem Loch ein anderes Objekt befindet (z.B. See im Wald). Dann kann die innere Begrenzung direkt als See getaggt werden. Ich habs mal deutlicher formuliert. Grüße, Marc -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multipolygon Building wird nicht von mapnik gerendert
Am Mittwoch 04 März 2009 19:07:08 schrieb Thomas Drebert: Hallo, ich hatte gerade in der Gegend gemappt, da ist mir auf gefallen das sehr viele Gebäude, in der Gegend, die Multipolygon sind, nur als ein Block gerendert weden. Kann mir mal jemad sagen wie so, ich kann keine Fehler feststellen. Wegrichtungen stimmen tags sind richtig geschrieben. http://www.informationfreeway.org/?lat=52.51637397081724lon=13.39152825156 9195zoom=17layers=0F0B0F Das Haus nördlich der Rosmarinstraße hat die Löcher (inner) ebenfalls als building=yes getaggt. Die müssen weg, es sei denn, da ist wirklich ein Haus im Haus. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ein Dorf namens Silberstraße
Am Dienstag 03 März 2009 18:02:39 schrieb malenki: Ein Bot namens is_in-bot hat als letzter dieses Node in den Klauen gehabt: http://www.openstreetmap.org/browse/node/263521832/history Auch wenn ich diese Ecke nicht genau kenne, bin ich mir sehr sicher, dass es kein Dorf namens Silberstraße gibt. Der Betreiber des Bots ist im Wiki unbekannt: http://wiki.openstreetmap.org/wiki/Category:Bots aber kennt den vielleicht jemand, der hier mitliest? Eine Korrektur des Nodes wäre nett, möglichst vom Verursacher, damit er nötigenfalls den fixbot fixen kann. Das hat aber mit dem Bot gar nichts zu tun. Der scheint nur das is_in-Tag zu erweitern. Der Node war von Anfang an falsch getaggt. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ein Dorf namens Silberstraße
Am Dienstag 03 März 2009 18:15:41 schrieb Bernd Wurst: Hallo. Am Dienstag, 3. März 2009 schrieb Marc Schütz: Der Node war von Anfang an falsch getaggt. Warum? Anders formuliert: Er wäre von Anfang an falsch getaggt gewesen, wenn es kein Dorf wäre. (Ich hab meine Antwort geschrieben, bevor ich deine gekriegt habe.) Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradstraße.
Wenn das korrekt ist, wäre highway=cycleway nicht richtig und highway = residential maxspeed = 30 bicycle=designated motor_vehicle=yes Wie wär's mit motor_vehicle=permissive? Das ist doch so im Sinne von nicht dafür gedacht, sagt aber keiner was. Eigentlich heißt das nur, dass der Eigentümer erlaubt, sein Grundstück unter bestimmten Bedingungen zu betreten/befahren. Eine Fahrradstraße ist aber definitiv öffentlich, also public, nicht permissive. Grüße, Marc -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 ¿/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf ORS - Update Webseite Hö henprofil
Dann sollte man aber an den Algorithmen arbeiten. Eine Kreuzung sollte sich doch einfach daran erkennen lassen, ob man 2x ca. 90° abbiegen kann oder dazu noch geradeaus oder ähnliches. Daraus könnte man ableiten, dass die Strecke mit dem größeren Winkel einfach teurer ist. Du hast das Problem nicht verstanden. Für viele Routing-Alorithmen wie z.B. den Standard Dijkstra gibt es kein Abbiegen von - auf sondern nur Weg von A nach B mit Kosten x und Weg von B nach D mit Kosten y. Deswegen hat er ja auch geschrieben, man sollte an den Algorithmen arbeiten = die Algorithmen ändern. Ich glaub aber, es geht auch ohne: Man könnte alle relevanten Knoten (z.B. barrier, Kreuzungen/Abzweigungen) als Wegstücke abbilden. Ich bin mir nur nicht ganz sicher, wie man am besten an Knoten mit mehreren angrenzenden Wegen verfährt. Wahrscheinlich reicht es, dort einen Kreisverkehr einzufügen. Auf diesen Graphen kann man dann die Standard-Algorithmen fast unverändert anwenden. Grüße, Marc -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gestrichelte Fläche in Braunschweig
Wenn ich mich recht Errinnere sind Drains doch die Flutcontroll Gräben die die großen Städten wie Los Angels und ähnlichen gebaut wurden um Überschwemmungen abzuleiten. Das hat mit den Abflussrinnen wie du sie meinst wenig zu tun. Ich zeichne Feldentwässerungen mit mit waterway=stream und width=x ein. http://wiki.openstreetmap.org/wiki/Proposed_features/Ditch -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umstellungen im Vorlagenmenü des JOSM
Linguisten vor, wie übersetzt man 'Scrollen'? Gar nicht, scrollen ist doch schon die deutsche Übersetzung von engl. to scroll. Grüße, Marc -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Automatischer Adressimport in Dänemark ?
ich habe gerade unter http://tools.geofabrik.de/osmi/?view=addresseslon=11.24796lat=54.61233zoom=6 geschaut, mich hat fast der Schlag getroffen, am Donnerstag sah, die Karte nochmal normal aus. Naja, die haben es ohne addr:country reingeladen und es überschneidet sich dann halt mit den österreichischen PLZ. Es müsste halt mehr kommuniziert werden, dass das addr:country für die PLZ Bereichsbestimmung relativ wichtig ist. ;-) Tagging für den OSMI ;-) Ich fände es sinnvoller, wenn der Inspector entweder Länderpolygone verwenden, oder einen Maximal-Abstand für die gleiche PLZ einführen würde (einfachste Lösung). Oder noch besser: Voronoi-Diagramme mit Maximalabstand, das kommt der Wirklichkeit am nächsten, weil man da auch nicht-konvexe Polygone kriegt. Was verwenden die UKler eigentlich für eine Technik, denn die Londoner PLZ Karte sieht ja sehr gut aus. Das Format der PLZ besteht aus Zahlen und Buchstaben; es gibt einfach zufällig keine Überschneidungen mit PLZ in anderen Ländern. -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Digest, Vol 31, Issue 105
Tagging für den OSMI ;-) Ich fände es sinnvoller, wenn der Inspector entweder Länderpolygone verwenden, oder einen Maximal-Abstand für die gleiche PLZ einführen würde (einfachste Lösung). Oder noch besser: Voronoi-Diagramme mit Maximalabstand, das kommt der Wirklichkeit am nächsten, weil man da auch nicht-konvexe Polygone kriegt. Ob man noch Verbesserung an den Polygonfindung vornehmen kann, sei dahin gestellt. Aber unter http://wiki.openstreetmap.org/wiki/Key:addr:housenumber Sieht man das das addr:country Tag dazu gehört. Das ist dort explizit als optional aufgelistet. Grüße, Marc -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] News auf/von ORS ...
Ich hab noch einen Bug: http://data.giub.uni- bonn.de/openrouteservice/index.php?start=11.5779656,49.9433629end=11.5816671,49.9371139pref=Bicyclelang=de Da wird im Fahrradmodus durch den Hofgarten geroutet, obwohl dort nur highway=footway sind. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] kleiner Durchfluss
Original-Nachricht Datum: Thu, 05 Feb 2009 00:05:23 +0100 Von: Claudius Henrichs claudiu...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] kleiner Durchfluss Am 04.02.2009 23:18, Alexander Schulze: Und zwar gibts ja im ländlichen Bereich jede Menge Gräben, die teilweise keine Brücke erfordern und deshalb nur über nen Durchfluss (unterschiedlich dicke Röhre) verfügen. Der Abflussgraben mit waterway=drain Für Wassergräben wurde waterway=ditch vorgeschlagen: http://wiki.openstreetmap.org/wiki/Proposed_features/Ditch Grüße, Marc -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kontakt zum Nachbarmapper
Am Mittwoch 04 Februar 2009 11:25:33 schrieb Johannes Haller: Wie kriege ich Kontakt zu einem Mapper, der in der selben Gegend wie ich die Karte verbessert? Ich sehe nur die Änderungen und finde den Nicknamen des Mappers. Unter nearby users auf der Karte in meinem Profil taucht er nicht auf. Unter users in Germany, dieser Liste im Wiki, scheinen auch nur Bruchteile der deutschen Beitragenden zu stehen. Unter http://www.openstreetmap.org/user/benutzername kannst du dem Benutzer eine Nachricht zukommen lassen (Send message). Der Benutzer kriegt dann eine E-Mail-Benachrichtigung und kann dir antworten. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Abbiegerelation] - wie no_u_turn anwenden
Am Dienstag 03 Februar 2009 12:54:35 schrieb Jan Tappenbeck: Hi ! ich habe das jetzt einmal (frecherweise) so hochgeladen als Relation 73386. Die Relation ist mit einem Stern gekennzeichnet, weil angeblich die Role via unbekannst ist. Vielleicht kannst Du nochmal einen Blick werfen. Das ist schon in Ordnung so, Dirk hat irgendwo geschrieben, dass der Validator einfach noch keine Wege als via-Member versteht. Allerdings weiß ich nicht, ob die via-Straße aufgesplittet werden müsste, damit sie bei from und to aufhört. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Abbiegerelation] - wie no_u_turn anwenden
Am Dienstag 03 Februar 2009 16:29:00 schrieb Johann H. Addicks: Apropos no_u_turn: Gab es nicht da mal eine Regel, keine negativen Feldbezeichner zu verwenden, um potentiell mißverständliche Monster zu vermeiden wie Jetzt alle Daten wirklich nicht löschen (J/N). Bei Abbiegeverboten beschreibt das aber schon die Realität; zumindest beim Wendeverbot gibt's auch keine sinnvolle Alternative mit only_. no_u_turn=no finde ich zumindest nicht schön. Das kann aber nirgendswo vorkommen, weil no_u_turn als Wert von restriction verwendet wird. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
