Re: [Talk-de] Name oder Operator in Tags
Bernd Wurst schrieb: Hausnummern sind wichtig im Datenbestand für Routing oder spezielle (interaktive?) Karten. Aber auf einer simplen 2D-Karte muss man IMHO nicht alle erkennen. Ich könnte mir gut vorstellen, dass man eines Tages einen zusätzlichen Layer hat, mit dem man Hausnummern ein- und ausblenden kann. Das könnte man doch mit den dynamischen POIs verbinden, oder? signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Render-Fehler?
Hallo, ist das ein Render-Fehler und mache ich was falsch? http://www.informationfreeway.org/?lat=52.02490054868131lon=13.230434813026589zoom=13layers=B000F000F Außenherum ist Wald und innendrin nen Truppenübungsplatz. Ich dachte deshalb, dass ich eine Relation type=multipolygon anlege und dann den Wald als outer und den Truppenübungsplatz als inner deklariere. Allerdings entstehen dann solche Fehlstellen. Hab ich jetzt schon mehrfach beobachtet. schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
Alexander Schulze schrieb: Hallo, ist das ein Render-Fehler und mache ich was falsch? http://www.informationfreeway.org/?lat=52.02490054868131lon=13.230434813026589zoom=13layers=B000F000F Außenherum ist Wald und innendrin nen Truppenübungsplatz. Ich dachte deshalb, dass ich eine Relation type=multipolygon anlege und dann den Wald als outer und den Truppenübungsplatz als inner deklariere. Allerdings entstehen dann solche Fehlstellen. Hab ich jetzt schon mehrfach beobachtet. Fehler im Beziercurvehinting. Falls du dich ein bisschen mit Perl, SVG und Bezierkurven auskennst, schau dir den source mal an, fixes welcome. http://svn.openstreetmap.org/applications/rendering/tilesAtHome/lines2curves.pl -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik: Schriftart wechseln / Unicode Problem mit Ethiopic
André Reichelt schrieb: Hm, über das Problem mit den Schriftzeichen habe ich erst letztens gelesen und da wurde auch die von dir empfohlene Schriftart zur Lösung des Problems vorgeschlagen. Ich denke, wenn die aktuelle Schriftart tatsächlih Probleme mit gewissen Schriftzeichen haben sollte, sollten wir in jedem Fall eine Andrer verwenden - schon alleine aus Gründen der Gleichberechtigung. Viel Spaß beim Suchen eines Fonts der UTF8-Complete ist, und auch noch frei ist. Die Lösung liegt momentan eher in der Richtung, dass man passende Fallback-Fonts vordefinieren können sollte. Also statt einem für alles eine vorgegebene Gruppe an Fonts, die dann (hoffentlich) alles abdeckt, was man so an (Schrift-)Zeichen braucht. -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Regionale OSM Mailingliste für Bayern
Am Freitag, 22. August 2008 11:54 schrieb Guenther Meyer: Am Donnerstag 21 August 2008 schrieb Andreas Hubel: Hi, könnten wir nicht eine Regionale OSM Mailingliste für Bayern einrichten? ich weiss nicht, ich bin eigentlich eher gegen eine weitere zersplitterung... wichtig waere dann halt, dass dort nur lokale sachen ausgemacht/besprochen werden, und allgemeine dinge auf der talk-liste bleiben... es gibt uebrigens wohl schon eine niederbayern-liste, vielleicht kann man di auf bayern ausweiten... Ich hatte das beim Anlegen der Liste mit dem Mailinglistenverwalter für Niederbayern diskutiert. Dieser schrieb mir damals, das er lieber einen nicht so großen Bereich haben möchte, damit weniger Traffic auf der Liste ist und sich die Leute trauen darauf zu schreiben. Ich denke vielleicht wäre eine [EMAIL PROTECTED] Liste nicht schlecht auf der nur Mails zu Mappingpartys und Mappertreffen drauf kommen, aber eben keine Diskussion. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pressebericht com Magazin
Am Dienstag, 19. August 2008 20:05 schrieb André Reichelt: Sven Anders schrieb: Im Online-Shop www.com-magazin.de ist diese Ausgabe noch nicht verfügbar. Wird der Artikel denn kostenfrei online erscheinen? Ich vermute nicht. Ich hatte mit der Redaktion bislang keinen Kontakt. Das einzige was passiert war, ist das ich eine Zeitung mit einem Formbrief bekommen haben, das über mein Unternehmen/Projekt etwas auf Seite ... steht. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kantenglättung
2008/8/25 André Reichelt [EMAIL PROTECTED]: Dirk Stöcker schrieb: Das ist eine Java-Funktion, die man nur an- oder ausschalten kann. Aberkonfigurierbar ist das nicht? Könnte man villeicht selber was entwickeln, das ähnliche Ergebnise liefert? Wird das eigentlich aktuell Hardwareseitig oder SOftwareseitig gerendert? ganz schoen krasser Vorschlag, André. Gibt IMHO momentan noch ein paar andere Sachen, die wichtiger sind als Kantenglaettung. Einige. Ich wuerde sogar mal behaupten, man kann grundsaetzlich darauf verzichten, weil es einfach zu viele Ressourcen benoetigt, die man lieber fuer anderes (z.B: groesserer bearbeitbarer Bereich) einsetzen sollte. Wenn Du aber Lust drauf hast, und es Dir zutraust, ein hard- oder softwareseitiges Antialiasing (wird wohl plattformunabhaengig nur letzteres gehen) zu implementieren, nur zu. Ich finde zwar diesen allgemeinen Ruf nach selbermachen statt diskuttieren manchmal auch ein bisschen uebertrieben, aber hier scheint es mir doch angebracht... Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegeregeln und Spitzkurven
Am 25. August 2008 07:46 schrieb Andreas Pothe [EMAIL PROTECTED]: Martin Koppenhoefer wrote: warum sollte das nicht möglich sein? Es ist m.E. sogar der Standardfall, dass man bei einer baulich getrennten Straße an den Stellen, wo die Trennung aufgehoben wird, wenden kann. In welchem Land? In Deutschland jedenfalls nicht. innerorts / ausserorts? Jedenfalls sind weder OSM noch die ueblichen derzeitigen Router auf Deutschland beschraenkt. Woher sollte die Routingsoftware denn Deiner Ansicht nach wissen, dass man an diesem gemeinsamen Node (=Kreuzung) nicht von einer auf die andere Spur/Seite wechseln kann? Nur am Winkel kann es jedenfalls nicht gehen, weil es auch solche spitzwinkligen Kreuzungen gibt, wo man durchaus fahren darf. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Name oder Operator in Tags
Am 25. August 2008 06:49 schrieb Bernd Wurst [EMAIL PROTECTED]: Hallo. Am Montag, 25. August 2008 schrieb Martin Koppenhoefer: Mein Vorschlag: kleine schwarze Nummern ohne Kreis und Füllung drumrum. Wenn das Anklang findet, würde ich auch nen kleinen Patch dazu einreichen. Überzeugt mich nicht. Das wäre dann ganz normaler Text, den man nicht von vielen anderen normalen Texten unterscheiden kann (Straßennamen, Ortsnamen, Stadtteilnamen). das wuerde man ueber die Schriftgroesse erkennen. Die waere nochmal deutlich kleiner als die Strassennamen (z.B. 50%; bzw. muesste ich/man da ein bisschen rumprobieren was Groesse und Lesbarkeit angeht). Der Vorteil ist u.a., dass man gerade *nicht* ein neues grafisches Element einsetzt. Dadurch wuerde die Karte in Bereichen mit Hausnummern deutlich aufgeraeumter. Das kann man doch in der derzeitigen Form nicht guten Gewissens drucken. Seht Euch mal einen normalen Stadtplan an, dort wird es i.d.R. genauso gemacht, wenn die Hausnummern ueberhaupt dargestellt werden (normalerweise nur gelegentlich, nicht alle Haeuser). Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draisinenstrecken
Johann H. Addicks wrote: Ich würde mir wünschen, wenn light_railway nicht Normalspur bis Park-Kleinbahn umfassen würde. Ad Park-Kleinbahn: narrow_gauge gibt's wohl auch noch? Unter light_railway würde ich mir hier im Wiener Raum die Badnerbahn vorstellen, die innerstädtisch als eine Art Tram verkehrt, obwohl sie überland als Vollbahn ausgebaut ist (und auch mit normalen Güterwagen befahren wird). Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Am Montag, 25. August 2008 schrieb André Reichelt: Naja, genug abgeschweift. Versuch mal, die Einstellungen anzupassen, dann wirst Du auch insgessamt mehr Freude mit Deiner Maus haben. Nein, mehr Freude werde ich dann nicht habe. Meine rechte Hand ist in ihren Bewegungsmöglichkeiten und ihrer Kraft sehr stark eingeschränkt. Damit ich noch einigermaßen vernünftig mit der Maus arbeiten kann, muss ich die Schiebereien auf sehr kurze Strecken reduzieren, sonst fängt es nach kurzer Zeit zu schmerzen an. Einmal quer über den Desktop sollte daher nicht mehr als ca. 3-4 cm Strecke mit der Maus brauchen. Dementsprechend empfindlich muss die Maus eingestellt sein. Da bleibt es natürlich nicht aus, das bei Betätigung der Maustaste mal ein Wackler geschieht. Es ist auch keine Lösung Ellbogen oder Schulter stärker mit in die Bewegung einzubeziehen, da fängt man sich schnell das Äquivalent eines Tennisarms ein, und das kann ich nun wirklich nicht auch noch gebrauchen. Die linke Hand brauch ich für die Tastatur, da es mit rechts in eine ziemliche Quälerei ausartet. Jeder Drei-Tasten-Druck ist ausgesprochen unangenehm, weswegen ich solche Kombinationen so weit wie möglich abändere. Letztendlich sind meine Konfigurationen mit Hilfe von Ärzten und Therapeuten erarbeitet worden, ich mache das also nicht willkürlich. Mal davon abgesehen, soll es auch ein paar Leute geben, die Mobil unterwegs sind und mit JOSM arbeiten. Ich denke mal, das da Klick+Move ebenfalls nicht überall auf Begeisterung stoßen wird. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bayern: Radwege (ncn/rcn) Via Julia, Via Bavarica Tyrolensis und M-Wasserweg
[EMAIL PROTECTED] schrieb: Hi Toni! Via Julia eingetragen relation 29350 Eintrag im Wiki folgt, wenn ich reinkomme (derzeit sehr langsam). Eintrag im Wiki habe ich gerade schon gemacht. (Hoffe, das war Dir recht.) Jetzt habe ich nur das Problem, dass man bei JOSM nicht einfach eine Relation mit seinen Membern (und ggfs. der Umgebung) laden kann. Habe jedenfalls keinen Weg gefunden. :-( Um also an anderer Stelle (z. B. westlich des Chiemsees) Member der Relation 29350 hinzufügen zu können, muss ich zuerst eines Deiner Via Julia Teilstücke laden, um an die Relation zu kommen. Oder hat da jemand einen besseren Weg? Wie sucht, findet und ladet Ihr Relationen in JOSM? Hallo Leupi, ja, über das Problem habe ich auch nachgedacht. Evtl. sollte man (werde ich) eine URL zum Download einer ganz kleinen Area in JOSM (copypaste) mit angeben. Nach Download dieser Area müsste dann das Hinzufügen einfacher gehen. http://www.openstreetmap.org/index.html?mlat=47.98266mlon=11.6711zoom=14 Gruß, Toni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Am 25. August 2008 10:31 schrieb René Falk [EMAIL PROTECTED]: Am Montag, 25. August 2008 schrieb André Reichelt: Naja, genug abgeschweift. Versuch mal, die Einstellungen anzupassen, dann wirst Du auch insgessamt mehr Freude mit Deiner Maus haben. Nein, mehr Freude werde ich dann nicht habe. Meine rechte Hand ist in ihren Bewegungsmöglichkeiten und ihrer Kraft sehr stark eingeschränkt. Damit ich noch einigermaßen vernünftig mit der Maus arbeiten kann, muss ich die Schiebereien auf sehr kurze Strecken reduzieren, sonst fängt es nach kurzer Zeit zu schmerzen an. Einmal quer über den Desktop sollte daher nicht mehr als ca. 3-4 cm Strecke mit der Maus brauchen. Dementsprechend empfindlich muss die Maus eingestellt sein. Da bleibt es natürlich nicht aus, das bei Betätigung der Maustaste mal ein Wackler geschieht. Es ist auch keine Lösung Ellbogen oder Schulter stärker mit in die Bewegung einzubeziehen, da fängt man sich schnell das Äquivalent eines Tennisarms ein, und das kann ich nun wirklich nicht auch noch gebrauchen. Die linke Hand brauch ich für die Tastatur, da es mit rechts in eine ziemliche Quälerei ausartet. Jeder Drei-Tasten-Druck ist ausgesprochen unangenehm, weswegen ich solche Kombinationen so weit wie möglich abändere. Letztendlich sind meine Konfigurationen mit Hilfe von Ärzten und Therapeuten erarbeitet worden, ich mache das also nicht willkürlich. Mal davon abgesehen, soll es auch ein paar Leute geben, die Mobil unterwegs sind und mit JOSM arbeiten. Ich denke mal, das da Klick+Move ebenfalls nicht überall auf Begeisterung stoßen wird. Grüße René eine Loesung koennte wie bereits in einer vorigen Mail angedeutet sein, dass man die Variable fuer die Mindeststrecke erhoeht, die erforderlich ist, um ein Drag als Drag zu werten. Vielleicht kann Dirk uns hier helfen, indem er sagt, welchen Wert man (ueber Einstein) anpassen muss. Wenn es so eine Einstellmoeglichkeit nicht gibt, wird Dir wohl nichts anderes uebrig bleiben, als die Funktion zu deaktivieren (das geht ja in jedem Fall schon). Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
http://www.informationfreeway.org/?lat=52.02490054868131lon=13.230434813026589zoom=13layers=B000F000F Außenherum ist Wald und innendrin nen Truppenübungsplatz. Ich dachte deshalb, dass ich eine Relation type=multipolygon anlege und dann den Wald als outer und den Truppenübungsplatz als inner deklariere. Allerdings entstehen dann solche Fehlstellen. Hab ich jetzt schon mehrfach beobachtet. Fehler im Beziercurvehinting. Falls du dich ein bisschen mit Perl, SVG und Bezierkurven auskennst, schau dir den source mal an, fixes welcome. http://svn.openstreetmap.org/applications/rendering/tilesAtHome/lines2curves.pl In der Form hab ich den Fehler noch nicht gesehen. Es sieht so aus, als werde der inner gar nicht gerundet. Bis jetzt war das Problem ja eher, dass die beiden Kurven nicht deckungsgleich waren. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kantenglättung
Hi, André Reichelt schrieb: Dirk Stöcker schrieb: Kam hier bestimmt schon zum vierten Mal die Anfrage. Ja. Siehe Einstellungen Anti-Aliasing. War defaultmäßig an - ab jetzt defaultmäßig aus. Macht wohl doch zu viele Probleme. Ist eigentlich geplant, das zu verbessern? Generell finde ich die Sache ja sehr geschickt, aber es bremst eben extrem und die Texte erscheinen auch völlig unlesbar. Aber für eine Überarbeitung des ganzen wäre ich auf jeden Fall. Grundsätzlich: das Antialiasing lässt sich per Präferenz aus- und einschalten. Was die Textlesbarkeit betrifft, hängt es wohl von diversen Faktoren (Bildschirm, Auflösung) sowie persönlichen Präferenzen ab, ob es als besser oder schlechter empfunden wird. Darüber hinaus müsste man mal zur Diskussion stellen, ob es nicht sinnvoll ist, (a) die Texte größer darzustellen, bzw. die Größe konfigurierbar zu machen und (b) das Textantialiasign separat steuerbar zu machen. Mir ist nicht so ganz klar, in welchen Konstellationen das langsamer wird. Meine Tests unter Java 1.6/XP haben keinen nennenswerten Unterschied ergeben. Wenn bekannt ist, in welchen Konstellationen es langsam ist, kann man evtl. eine Heuristik bauen, die das per Default entsprechend ein- oder ausschaltet. Gruesse Joerg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
eine Loesung koennte wie bereits in einer vorigen Mail angedeutet sein, dass man die Variable fuer die Mindeststrecke erhoeht, die erforderlich ist, um ein Drag als Drag zu werten. Vielleicht kann Dirk uns hier helfen, indem er sagt, welchen Wert man (ueber Einstein) anpassen muss. Wenn es so eine Einstellmoeglichkeit nicht gibt, wird Dir wohl nichts anderes uebrig bleiben, als die Funktion zu deaktivieren (das geht ja in jedem Fall schon). edit.initial-move-treshhold Ist auch überhaupt nicht kompliziert dass selbst nachzusehen. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
2008/8/25 Raphael Studer [EMAIL PROTECTED]: eine Loesung koennte wie bereits in einer vorigen Mail angedeutet sein, dass man die Variable fuer die Mindeststrecke erhoeht, die erforderlich ist, um ein Drag als Drag zu werten. Vielleicht kann Dirk uns hier helfen, indem er sagt, welchen Wert man (ueber Einstein) anpassen muss. Wenn es so eine Einstellmoeglichkeit nicht gibt, wird Dir wohl nichts anderes uebrig bleiben, als die Funktion zu deaktivieren (das geht ja in jedem Fall schon). edit.initial-move-treshhold Ist auch überhaupt nicht kompliziert, das selbst nachzusehen. Grüsse Raphael Danke Raphael. Uebrigens mal an viele hier: wenn die Wogen nicht gleich so hochgehen, wird das Leben ploetzlich relaxt und angenehm. Einfach ein bisschen ruhig bleiben, mit seiner Wortwahl Respekt fuer die anderen zum Ausdruck bringen, konstruktiv denken und nicht wild mit Beschimpfungen und Gemaule durch die Gegend schiessen. Bringt fuer alle am meisten. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
Hi, kann das gleiche gleich nochmal anbieten. http://www.informationfreeway.org/?lat=51.98436784118599lon=13.135559736301165zoom=17layers=B000F000F aber sieht doch eher so aus, dass der Renderer krampfhaft versucht ne Kurve zu zeichnen, wo gar keine ist. Oder? Alex Raphael Studer schrieb: http://www.informationfreeway.org/?lat=52.02490054868131lon=13.230434813026589zoom=13layers=B000F000F Außenherum ist Wald und innendrin nen Truppenübungsplatz. Ich dachte deshalb, dass ich eine Relation type=multipolygon anlege und dann den Wald als outer und den Truppenübungsplatz als inner deklariere. Allerdings entstehen dann solche Fehlstellen. Hab ich jetzt schon mehrfach beobachtet. Fehler im Beziercurvehinting. Falls du dich ein bisschen mit Perl, SVG und Bezierkurven auskennst, schau dir den source mal an, fixes welcome. http://svn.openstreetmap.org/applications/rendering/tilesAtHome/lines2curves.pl In der Form hab ich den Fehler noch nicht gesehen. Es sieht so aus, als werde der inner gar nicht gerundet. Bis jetzt war das Problem ja eher, dass die beiden Kurven nicht deckungsgleich waren. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draisinenstrecken
Johann H. Addicks [EMAIL PROTECTED] wrote: Heiko Jacobs schrieb: Die S-Bahnen, sofern weitgehend unabhaengig vom Restbahnverkehr, separat zu taggen, ist aber dennoch sinnvoll... Also wenn die Tret-Draisinen railway bekommen, jedoch von BR143 befahre Trassen aber als light_railway getagt werden, dann stimmt irgendwas nicht. Wie gesagt: Es ist wohl ein Uebersetzungsfehler, der zu Kuddelmuddel insbes. in .de fuehrte... Bei Gelegenheit mus man sich ueberlegen, wie man das gerade biegt, aber dazu will ich erstmal internationaler recherchieren... Welche S-Bahn meinst Du denn? Die, die mir in den Sinn kommen und eigene restbahnunabhaengige Anlagen haben, fahren alle mit Triebwagen. Ich kenne aber nicht die Daten aller S-Bahnen auswendig mitsamt Streckenstatus... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Danke Raphael. Uebrigens mal an viele hier: wenn die Wogen nicht gleich so hochgehen, wird das Leben ploetzlich relaxt und angenehm. Einfach ein bisschen ruhig bleiben, mit seiner Wortwahl Respekt fuer die anderen zum Ausdruck bringen, konstruktiv denken und nicht wild mit Beschimpfungen und Gemaule durch die Gegend schiessen. Bringt fuer alle am meisten. Meine Wortwahl war sicherlich nicht optimal und dafür möchte ich mich entschuldigen. Ich habe mich nur daran gestört, dass du direkt Dirk angesprochen hast. Dies erweckt für mich den Eindruck als wäre JOSM inzwischen so kompliziert, dass nur noch Dirk versteht wie er funktioniert und er dann auch an allem Schuld wäre wenn er nicht funktioniert. Womit wir dann bei den von dir beschriebenen Beschimpfungen und Gemaule währen. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Draisinenstrecken
Moin, Also wenn die Tret-Draisinen railway bekommen, jedoch von BR143 befahre Trassen aber als light_railway getagt werden, dann stimmt irgendwas nicht. auch hier geht es ja darum, dass wir mit einem Tag verschiedene Dinge auszudrücken versuchen, beispielsweise um was für eine Gleisanlage handelt es sich (narrow_gauge) und was verkehrt darauf (rail, light_rail). Speziell die letzte Frage lässt sich nicht immer eindeutig beantworten. Solange wir das nicht ausdetaillieren können (was früher oder später sowohl bei Straßen als auch Bahnen kommen wird), muss man sich halt einen möglichst sinnvollen Tag ausdenken. IMO gilt daher, dass jemand, der sowas mappen möchte, die Strecke halt so auszeichnen sollte, damit später ein anderer noch weiß, was gemeint war. Beispiele: railway=draisine (würde wohl momentan nicht gerendert) railway=rail disused=yes draisine=yes highway=rail draisine=designated Die ist auch ein schönes Beispiel dafür, warum ich immer darauf hinweise dass Map Features nicht die Bibel ist. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
On Mon, 25 Aug 2008, Raphael Studer wrote: Ich habe mich nur daran gestört, dass du direkt Dirk angesprochen hast. Dies erweckt für mich den Eindruck als wäre JOSM inzwischen so kompliziert, dass nur noch Dirk versteht wie er funktioniert und er dann auch an allem Schuld wäre wenn er nicht funktioniert. Womit wir dann bei den von dir beschriebenen Beschimpfungen und Gemaule währen. Wer sagt denn, dass ich verstehe, wie JOSM funktioniert. Also ich bestimmt nicht. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
kann das gleiche gleich nochmal anbieten. http://www.informationfreeway.org/?lat=51.98436784118599lon=13.135559736301165zoom=17layers=B000F000F aber sieht doch eher so aus, dass der Renderer krampfhaft versucht ne Kurve zu zeichnen, wo gar keine ist. Oder? Richtig. Sobald zwischen 2 geraden ein bestimmter Winkel unterschritten wird, macht der Rendere Bezier Kurven daraus. AFAIR macht der Renderer in einer solchen konstellation 2 Linien aus einem Way. Je einen fürs Loch und für die Fläche darin. Vielleicht bringt man in dazu dies zu unterlassen. Ein Workaround wäre wenn man Löcher die einen Inhalt (nicht nur eine Lichtung im Wald) haben beim zeichnen der äusseren Fläche einfach ignoriert und dann die Innere Fläche darüber zeichnet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Am 25. August 2008 11:39 schrieb Raphael Studer [EMAIL PROTECTED]: Danke Raphael. Uebrigens mal an viele hier: wenn die Wogen nicht gleich so hochgehen, wird das Leben ploetzlich relaxt und angenehm. Einfach ein bisschen ruhig bleiben, mit seiner Wortwahl Respekt fuer die anderen zum Ausdruck bringen, konstruktiv denken und nicht wild mit Beschimpfungen und Gemaule durch die Gegend schiessen. Bringt fuer alle am meisten. Meine Wortwahl war sicherlich nicht optimal und dafür möchte ich mich entschuldigen. Ich habe mich nur daran gestört, dass du direkt Dirk angesprochen hast. Dies erweckt für mich den Eindruck als wäre JOSM inzwischen so kompliziert, dass nur noch Dirk versteht wie er funktioniert und er dann auch an allem Schuld wäre wenn er nicht funktioniert. Womit wir dann bei den von dir beschriebenen Beschimpfungen und Gemaule währen. Grüsse Raphael Ich hatte meinen Text mehr als auf Dich auf die vorigen Posts (und andere Threads) bezogen. Wollte niemandem eine Schuld fuer irgendwas geben und habe nur deshalb Dirk direkt angesprochen, weil er das feature programmiert hat und hier mit der Bitte um feedback vorgestellt. Daher dachte ich, dass er am besten weiss, wie man es machen kann. Ich bin uebrigens gerade dabei, mich ein bisschen einzulesen: http://de.wikibooks.org/wiki/Java_Standard:_Erste_Schritte aber fuer Nichtprogrammierer ist es weniger trivial, solche Variablen aus dem Code zu ziehen, wie man sich als Profi vermutlich vorstellen kann. Mal sehen, bald weiss ich hoffentlich mehr. ;-) Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kantenglättung
On Mon, 25 Aug 2008, jh wrote: Darüber hinaus müsste man mal zur Diskussion stellen, ob es nicht sinnvoll ist, (a) die Texte größer darzustellen, bzw. die Größe konfigurierbar zu machen und (b) das Textantialiasign separat steuerbar zu machen. Beides. Seit ich meinen neuen Laptop habe stört mich die JOSM-Schriftgröße (nicht nur im Display, sondern auch Menüs,...). Statt 1024x800 sind es jetzt 1680x1050 und immer noch 15 Zoll, da ist eine etwas größere Schrift überall notwendig. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
Am 25. August 2008 11:47 schrieb Raphael Studer [EMAIL PROTECTED]: kann das gleiche gleich nochmal anbieten. http://www.informationfreeway.org/?lat=51.98436784118599lon=13.135559736301165zoom=17layers=B000F000F aber sieht doch eher so aus, dass der Renderer krampfhaft versucht ne Kurve zu zeichnen, wo gar keine ist. Oder? Richtig. Sobald zwischen 2 geraden ein bestimmter Winkel unterschritten wird, macht der Rendere Bezier Kurven daraus. AFAIR macht der Renderer in einer solchen konstellation 2 Linien aus einem Way. Je einen fürs Loch und für die Fläche darin. Vielleicht bringt man in dazu dies zu unterlassen. Ein Workaround wäre wenn man Löcher die einen Inhalt (nicht nur eine Lichtung im Wald) haben beim zeichnen der äusseren Fläche einfach ignoriert und dann die Innere Fläche darüber zeichnet. ja, die Luecken wuerde man damit los, wobei das in dem Beispiel noch nicht der Weissheit letzter Schluss waere: die innere Flaeche sollte dort ja keine Rundung haben. Seltsam ist es aber doch, dass er in einem Fall (innen) eine Kurve vermutet (und das bei noch annaehernd 90 Grad), waehrend er im anderen Fall (aussen) davon Abstand nimmt. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegeregeln und Spitzkurven
Moin, warum sollte das nicht möglich sein? Es ist m.E. sogar der Standardfall, dass man bei einer baulich getrennten Straße an den Stellen, wo die Trennung aufgehoben wird, wenden kann. bei mir war mel einer am Stand, der sich Routing mit Navit hat zeigen lassen. Er interessierte sich für eine Bundesstraßenkreuzung bei Ettlingen. Zwei getrennte Fahrspuren vereinigen sich. Direkt nach der Vereinigung geht links eine Abfahrt weg. Rein von der Beschilderung und dem baulichen Zustand her dürfte man hier sogar links abbiegen, was sich aber aufgrund der Verkehrssituation verbietet. Stattdessen nutzt man die dafür vorgesehene Abbiegespur rechts weg. Navit erkannte aber wohl, dass Linksabbiegen die kürzere Alternative sei :-) . Insofern mag eine Art Regel bei Vereinigung zweier Fahrspuren höherer Straßen außerorts noch ein paar Meter zuwarten, bevor Linksabbiegen erlaubt ist nicht die dümmste sein. Allerdings kann Navit anhand unserer Daten derzeit nicht erkennen, ob eine Straße inner- oder außerorts ist. Für's Routing wäre das eine äußerst interessante Info. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Am Montag, 25. August 2008 schrieb Raphael Studer: edit.initial-move-treshhold Ist auch überhaupt nicht kompliziert dass selbst nachzusehen. Ist das schon drin oder muss man das noch hinzufügen? Einstein kennt das bei mir nicht. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
2008/8/25 René Falk [EMAIL PROTECTED]: Am Montag, 25. August 2008 schrieb Raphael Studer: edit.initial-move-treshhold Ist auch überhaupt nicht kompliziert dass selbst nachzusehen. Ist das schon drin oder muss man das noch hinzufügen? Einstein kennt das bei mir nicht. Grüße René wenn es drin waere, wuerde er es kennen (oder was meinst Du?), daher musst Du einen neuen Wert machen mit edit.initial-move-treshhold und dort ggf. etwas experimentieren, bis die Einstellungen fuer Deine Maus-Einstellungen passen. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Am Montag, 25. August 2008 schrieb René Falk: Am Montag, 25. August 2008 schrieb Raphael Studer: edit.initial-move-treshhold Ist auch überhaupt nicht kompliziert dass selbst nachzusehen. Ist das schon drin oder muss man das noch hinzufügen? Einstein kennt das bei mir nicht. Hat sich erledigt, habe es im englischsprachigen Wiki gefunden. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegeregeln und Spitzkurven
Am 25. August 2008 12:09 schrieb Marcus Wolschon [EMAIL PROTECTED]: Am 25.08.08 schrieb Christoph Eckert [EMAIL PROTECTED]: Moin, warum sollte das nicht möglich sein? Es ist m.E. sogar der Standardfall, dass man bei einer baulich getrennten Straße an den Stellen, wo die Trennung aufgehoben wird, wenden kann. bei mir war mel einer am Stand, der sich Routing mit Navit hat zeigen lassen. Er interessierte sich für eine Bundesstraßenkreuzung bei Ettlingen. Zwei getrennte Fahrspuren vereinigen sich. Direkt nach der Vereinigung geht links eine Abfahrt weg. Rein von der Beschilderung und dem baulichen Zustand her dürfte man hier sogar links abbiegen, was sich aber aufgrund der Verkehrssituation verbietet. Stattdessen nutzt man die dafür vorgesehene Abbiegespur rechts weg. Navit erkannte aber wohl, dass Linksabbiegen die kürzere Alternative sei :-) . Insofern mag eine Art Regel bei Vereinigung zweier Fahrspuren höherer Straßen außerorts noch ein paar Meter zuwarten, bevor Linksabbiegen erlaubt ist nicht die dümmste sein. Allerdings kann Navit anhand unserer Daten derzeit nicht erkennen, ob eine Straße inner- oder außerorts ist. Für's Routing wäre das eine äußerst interessante Info. In Großstädten wäre genau so eine Regel oft falsch. Hier gibt es gerne mal mehrspuring Durchgangs-Straßen bei denen das sehrwohl erlaubt ist. Mein Vorschlag: Nicht generell verbieten sondern da, wo es nicht geht halt eine entsprechende Relation taggen. Marcus sehe ich genauso. In der Regel sollte der Router davon ausgehen, dass er eine Verbindung auch nutzen kann. Wenn nicht, ist entweder flasch gemappt (Verbindung, wo keine ist), oder man muss durch eine Relation klar machen, dass man die Verbindung nicht nutzen darf. Wenn man hier mit Sonderregeln anfaengt (erst nach 50 m ausserorts), wird die Sache bald unuebersichtlich und undurchschaubar. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
On Mon, 25 Aug 2008, René Falk wrote: edit.initial-move-treshhold Ist auch überhaupt nicht kompliziert dass selbst nachzusehen. Ist das schon drin oder muss man das noch hinzufügen? Einstein kennt das bei mir nicht. Die Einstein-Preferences kennen einen Wert nur unter zwei Bedingungen: a) Der Wert ist konfiguriert wurden. b) Der Wert wurde in der aktuellen Sitzung schonmal benutzt. Also im Zweifelsfall die zugehörige Funktion einmal benutzen (hier Ändern) und dann die Preferences aufrufen. Dann bekommst Du im MouseOver über den Schlüssel auch den Default-Wert angezeigt. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unverbundene Radwege, jetzt ist Deutschland komplett!
GS wrote: Hi, die Liste der unverbundenen Radwege umfasst nun nach etwa 15h Rechenzeit ganz Deutschland. http://wiki.openstreetmap.org/index.php/UnverbundeneRadwege Viel Spaß beim Korrigieren ;-) Gerhard Gary68 Hallo, könnte man vielleicht die lat und lon Parameter in der URL durch mlat und mlon ersetzen, so dass am betreffenden Weg ein roter Marker zu sehen ist? JOSM scheint auch mit solchen URLs zurecht zu kommen. Gruß Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] (Nicht) an Verbote halten...
... http://www.heise.de/newsticker/Googles-Strassenansichtsdienst-missachtet-Durchfahrtverbote--/meldung/114747 Wobei ich hier in der Gegend ja bereits mehrfach das Problem hatte, dass Anwohner meinen, sie müssten nur ein Schild Privatstraße selbst basteln und aufhängen um aus der öffentlichen Zufahrtsstraße zu ihrem Haus eine Privatstraße zu machen... Tschüss, Tim. -- http://wikipedistik.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (Nicht) an Verbote halten...
Am 25. August 2008 12:48 schrieb Tim 'avatar' Bartel [EMAIL PROTECTED]: ... http://www.heise.de/newsticker/Googles-Strassenansichtsdienst-missachtet-Durchfahrtverbote--/meldung/114747 Wobei ich hier in der Gegend ja bereits mehrfach das Problem hatte, dass Anwohner meinen, sie müssten nur ein Schild Privatstraße selbst basteln und aufhängen um aus der öffentlichen Zufahrtsstraße zu ihrem Haus eine Privatstraße zu machen... Tschüss, Tim. was fuer eine Lehre ziehen wir daraus? Ich bin selbst der Meinung, mehr ist besser, d.h. Privatstrassen sollten durchaus in unseren Datenbestand (natuerlich als solche gekennzeichnet), vorbei an bellenden Wachhunden fahre ich mit dem Fahrrad hingegen eher ungern... Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Becker Z 101
Christoph Eckert [EMAIL PROTECTED] wrote: auf meinem Traffic Assist Pro l?uft ein Windows ce. Darauf sollte sich Navit zum Laufen bringen lassen. Falls ja w?rde das Deine Anforderungen erf?llen. Tipp: Nimm die Version aus dem SVN (nicht CVS) und verwende als gui nicht gtk sondern internal. Da kann man sich ?ber die Konfigurationsdatei on-screen-elemente anlegen: http://christeck.de/stuff/osd-buttons_3.png SVN... Also alles selbst compilieren... Nun gut, fuer einen alten Linuxer nicht so das Problem... Geht vermutlich auch unter dem cygwin auf meinem Vista... Dann laeuft es dort... Schlecht... Da will ich's nicht... Helf mal einem Windoofen auf die Spruenge, wie man das auf das Windows CE kriegt? Irgendwo im Wiki ist eine Seite Navit auf Windoof, aber das ist nix Win CE und internal, sondern richtiges Win und GTK vorkompiliert... Und geht das ganze dann, ohne die interne Software und Karte zu stoeren, von einer SD-Karte zu starten bzw. wenn moeglich vom USB-Stick? USB-Anschluss hat es ja, aber irgend so 'nen mickrigen, dass auch ja kein normaler USB-Stick reinpasst... :-) Oder testweise vom groszen Rechner zu starten, wenn die per USB verbunden sind? MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Name oder Operator in Tags
Hallo. Am Montag, 25. August 2008 schrieb Martin Koppenhoefer: Das kann man doch in der derzeitigen Form nicht guten Gewissens drucken. Volle Zustimmung. Aber könnte man es wenn alle Hausnummern in der von dir genannten Form drauf erscheinen würden? Also klar, wenn du das mal beispielhaft machen würdest, könnte man fundierter darüber entscheiden, aber ich denke ... Seht Euch mal einen normalen Stadtplan an, dort wird es i.d.R. genauso gemacht, wenn die Hausnummern ueberhaupt dargestellt werden (normalerweise nur gelegentlich, nicht alle Haeuser). ... das ist eher ein Grund, die Hausnummern gar nicht direkt zu rendern sondern diese per Overlay drüber zu legen wenn man sie haben möchte. Wenn jemand die Karten für einen Druck (also mehr als da muss ich noch mappen) haben will, sollte er schon manuell nochmal nachbearbeiten, sonst sieht's nicht wirklich gut aus. Hausnummern auf gedruckten Karten eignen sich doch eigentlich nur für Spezialanwendungen bzw. einige markante Nummern. Gruß, Bernd -- Fachbegriffe der Informatik (#165): SuSE Nürnberger Windows (Andreas Gradert) 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
[Talk-de] Hundesport-Plätze erfassen
Moin !! heute einmal eine Frage zum Thema Hundesport. Wie würdet Ihr Hundesportplätze taggen ??? Ich habe schon einmal etwas von Hundeschulen gelesen - aber das sind gewerbliche Firmen die sich mit dem Thema beschäftigen. Mir geht es um die Freizeit-Sportvereine zum Thema. Gruß Jan :-) --- OpenStreetMap (OSM) - das FREIE Kartenprojekt Aktuelle Karten Mitteleuropa: http://www.openstreetmap.de/karte.html Lübeck: http://www.openstreetmap.de/karte.html?zoom=12lat=53.86927lon=10.688layers=B0 Hamburg: http://www.openstreetmap.de/karte.html?zoom=11lat=53.58175lon=10.02522layers=B0 Dithmarschen (hier gibt es noch viel zu tun !): http://www.openstreetmap.de/karte.html?zoom=10lat=54.15906lon=9.16005layers=B0 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Hallo. Am Montag, 25. August 2008 schrieb René Falk: Meine rechte Hand ist in ihren Bewegungsmöglichkeiten und ihrer Kraft sehr stark eingeschränkt. Damit ich noch einigermaßen vernünftig mit der Maus arbeiten kann, muss ich die Schiebereien auf sehr kurze Strecken reduzieren, sonst fängt es nach kurzer Zeit zu schmerzen an. Das von einem nicht-betroffenen zu hören muss nach Klugscheisserei klingen, aber die Frage bietet sich hier an: Hast du schonmal nen (guten) Trackball ausprobiert? Ich kenne andere Personen, die Bewegungseinschränkungen der Hand haben und einige können mit dem Daumen ungleich besser Bewegungen durchführen als mit der ganzen Hand. Gruß, Bernd -- Nehmen wir einmal an, es gäbe keine hypothetischen Situationen... 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] Abbiegeregeln und Spitzkurven
Hallo, bin neu hier und versuche mal zur Diskussion etwas beizutragen: Aus meiner Sicht gibt es nur ein sicheres Kennzeichen ein umkehren zu verbieten: das Richtungskennzeichen (one way) Kann mir sehr gut die Situation in den Bergen vorstellen, wo zwei Straßen baulich sehr eng beieinander laufen aber höhenmäßig auseinander liegen. Meist laufen die Straßen dann recht spitz ineinander. Um von oben nach unten zu kommen muss man dann die Spitzkehre nehmen. Sicher gibt es noch andere Beispiele, an welchen man allein von der geografischen Anordnung (Projektion) nicht auf Abbiegeregeln schließen kann. Gruß Udo On Mon, 25 Aug 2008 02:04:02 +0200, Garry wrote Martin Koppenhoefer schrieb: Allerdings sollte es nicht möglich sein, eine Straße die baulich getrennt ist und dann zusammen geführt wird, an dieser Stelle als links abbiegen wieder zurück zu fahren. warum sollte das nicht möglich sein? Es ist m.E. sogar der Standardfall, dass man bei einer baulich getrennten Straße an den Stellen, wo die Trennung aufgehoben wird, wenden kann. Würde ich so nicht unterschreiben, schon gar nicht wenn sich an dieser Stelle keine Kreuzung befindet. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de P\\\ [EMAIL PROTECTED] Eichenweg 2 72535 Heroldstatt-Sontheim Tel: +49 7389 90190 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] An die Dortmunder - SEHR gute Nachrichten!
Hallo Leute, ich habe heute eine Mail vom Vermessungs- und Katasteramt der Stadt Dortmund bekommen. Herr von Stillfried schreibt dort, dass die OSM-Community mit großem Interesse verfolgt wurde und das Amt auch Kenntnis vom geplanten Mapper-Treffen hat. Und jetzt das, was mich _sehr_ überwältigt hat: Das Vermessungs- und Katasteramt möchte sich mit uns treffen und besprechen, mit welchen Daten die Aktivitäten im OSM von der Seite der Stadt Dortmund unterstützt werden können! Auch über die Thematik Lizenz- und Urheberrecht sind sie sich bewusst. Juhu! Herr von Stillfried bietet zwei Termine an: - Montag, 08.09.2008 zwischen 14 und 16 Uhr - Dienstag, 09.09.2008 zwischen 09 und 12 Uhr Ich kann an beiden Terminen, wer möchte mit? Mir würde der 1. Termin gut passen (Bequemlichkeit). Viele Grüße Tobias ps: Ich bin vermutlich am 21.09.2008 bei den GIS-Kompetenztagen in Bonn, werde aber für das OSM-Treffen einen Tag eher abreisen (außer es gibt ein gutes Mittagsbuffet). Gibt es schon TOPs? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegeregeln und Spitzkurven
Am 25. August 2008 13:33 schrieb udo.besenreuther.de [EMAIL PROTECTED]: Hallo, bin neu hier und versuche mal zur Diskussion etwas beizutragen: Aus meiner Sicht gibt es nur ein sicheres Kennzeichen ein umkehren zu verbieten: das Richtungskennzeichen (one way) Kann mir sehr gut die Situation in den Bergen vorstellen, wo zwei Straßen baulich sehr eng beieinander laufen aber höhenmäßig auseinander liegen. Meist laufen die Straßen dann recht spitz ineinander. Um von oben nach unten zu kommen muss man dann die Spitzkehre nehmen. Sicher gibt es noch andere Beispiele, an welchen man allein von der geografischen Anordnung (Projektion) nicht auf Abbiegeregeln schließen kann. Gruß Udo ja, oder ein no-U-turn (Wendeverbot), Zeichen 272 http://de.wikipedia.org/wiki/Bild:Zeichen_272.svg oder ein Verbot der Einfahrt, Zeichen 267 http://de.wikipedia.org/wiki/Bild:Zeichen_267.svg Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] noch mehr gute Nachrichten (ganzes Ruhrgebiet)
Hallo Leute, und noch eine E-Mail. Diesmal vom Regionalverband Ruhr (RVR). Hintergrundinfos: Der RVR hat sich aus dem SVR über den KVR entwickelt. Der RVR erstellt das amtliche Stadtplanwerk für die Kommunen, die im Verband teilnehmen. OpenStreetMap war dort auch intern im Gespräch, war aber wegen der Urlaubszeit auf Eis gelegt. Der Mitarbeiter wird dieses Thema aber nun wieder aufkochen und sich dann bei mir melden. Meine Güte ... es funktioniert! Viele Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bayern: Radwege (ncn/rcn) Via Julia, Via Bavarica Tyrolensis und M-Wasserweg
So, nun ist auch beim M-Wasserweg der Anfang gemacht: nummer = 29420; members = 9 name = M-Wasserweg route = bicycle network =rcn created_by = JOSM type = route ref =MWW JOSM Bounding Box http://www.openstreetmap.org/index.html?mlat=47.98266mlon=11.6711zoom=14 Toni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bayern: Radwege (ncn/rcn) Via Julia, Via Bavarica Tyrolensis und M-Wasserweg
So, nun ist auch beim Via Bavarica Tyrolensis der Anfang gemacht: nummer = 29421; members = 9 name = Via Bavarica Tyrolensis route = bicycle network =rcn created_by = JOSM type = route ref =JBT JOSM Bounding Box http://www.openstreetmap.org/index.html?mlat=47.98266mlon=11.6711zoom=14 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Am Montag, 25. August 2008 schrieb Bernd Wurst: Hallo. Am Montag, 25. August 2008 schrieb René Falk: Meine rechte Hand ist in ihren Bewegungsmöglichkeiten und ihrer Kraft sehr stark eingeschränkt. Damit ich noch einigermaßen vernünftig mit der Maus arbeiten kann, muss ich die Schiebereien auf sehr kurze Strecken reduzieren, sonst fängt es nach kurzer Zeit zu schmerzen an. Das von einem nicht-betroffenen zu hören muss nach Klugscheisserei klingen, aber die Frage bietet sich hier an: Hast du schonmal nen (guten) Trackball ausprobiert? Nee, das ist keine Klugscheisserei. Und ja, das war auch zu beginn die erste Wahl und ist tatsächlich auch einfacher in der Bedienung, hat aber einen Nachteil. Um die jetzigen Fähigkeiten meiner Hand zu erhalten, muss ich diese Fahigkeiten tranieren und auch so oft wie möglich nutzen (Wer rastet, der rostet). Dabei muss ich möglichst bis knapp unter dem Punkt kommen, wo die Schmerzen anfangen, das wäre das optimalste. Die Maus ersetzt zwar keine Physiotherapie, verlangt aber erheblich mehr und unterschiedliche Aktivität von meiner Hand. Ein Trackball würde da eher kontraproduktiv sein. Da ich ja auch im Job am Rechner sitze, ist das zeitlich gesehen ein nicht zu vernachlässigender Faktor. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Marcus Wolschon: Mein Vorschlag besteht im Kern darin, dass man im XML-Code nicht nur way ... tag k=foo v=bar / /way setzen kann sondern z.B. way ... tag k=foo v=bar tag k=bla v=blubb/ /tag /way Warum sollte das nicht mit der aktuellen Struktur als bla[bar]=blubb oder bla:bar=blubb funktionieren? Wir machen das bei den name name:en name:en_UK ja auch nicht anders und müssen dazu die Struktur nicht ändern. Ja, da sind die Werte wie en, de, ... auch aus einer halbwegs festen Menge an völlig unkritischen Zeichen. Ich bleibe bei meinem Beispiel: * Autos: Höchstgeschwindigkeit 80 km/h * LKW ab 7,5 Tonnen: Höchstgeschwindigkeit 60 km/h * LKW ab 12 Tonnen: Nur Anlieger frei Das ist übrigens ein reales Beispiel. Wie taggt man das? Bei Verwendung des bisherigen Schemas, müsste das Gewicht sowie auch die angabe, dass es ein Gewicht ist, in den Schlüssel. Das ist IMHO sehr, sehr, hässlich bzw. richtig umständlich. Mir fällt sogar grade nicht mal was vernünftiges ein, wie man das abbilden kann. Wir haben bereits die Konstrukte: Schlüssel=Wert Schlüssel:Spezialisierung=Wert Schlüssel=Wert1;Wert2;Wert2 sowie Schlüssel1=Wert1 Schlüssel1_2=Wert1_1 (z.B. highway=motorway+ref=A5) Richtig. Mit keinem der genannten kann man das obige abbilden, da man nur den Key oder nur wen Wert vererbt. Text-basierende Sprachen sind so ein mächtiges Konstrukt... Ja, aber alles was über simples tokenizing bzw. splitting hinausgeht ist ziemlich fehleranfällig (vor allem für den, der das bearbeiten soll) und aufwändig (== langsam). Gruß, Bernd -- Alles Schöne im Leben hat einen Haken: Es ist unmoralisch, illegal oder es macht dick. 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] RFC: Tags für Tags - warum so komplizi ert?
Ja, da sind die Werte wie en, de, ... auch aus einer halbwegs festen Menge an völlig unkritischen Zeichen. Sowohl Schlüssel als auch Werte dürfen alle UTF8-Zeichen enthalten. Wenn jemand chineschische Sachen mit Tag-Namen in Mandarin mappen will, gerne. Müssen die Tools eben mit klarkommen wenn sie behaupten diesem Protokoll zu entsprechen. Ich bleibe bei meinem Beispiel: * Autos: Höchstgeschwindigkeit 80 km/h * LKW ab 7,5 Tonnen: Höchstgeschwindigkeit 60 km/h * LKW ab 12 Tonnen: Nur Anlieger frei Das ist übrigens ein reales Beispiel. Wie taggt man das? maxspeed=80 maxspeed(weight=7.5t)=60 access(weight=12t)=access only Bei mehreren Bedingungen halt sowas wie: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * versteht ein Mensch, * ist trivial zu parsen, * ist trivial zu filtern (where key ='access' or key like 'access(%)') * kommt ohne Änderung unseres Datenbankschemas und damit Änderung aller geschriebenen Werkzeuge aus. Ja, aber alles was über simples tokenizing bzw. splitting hinausgeht ist ziemlich fehleranfällig (vor allem für den, der das bearbeiten soll) und aufwändig (== langsam). Unser kritischer Punkt was langsam angeht ist die Datenbank. Diese muss skalieren und darf durch eine Änderung nicht langsamer werden. Die Anwendungen bearbeiten nur eine Hand voll Wege. Das ist vergleichsweise egal. Wenn du deinen Vorschlag weiter verfolgen möchtest, bitte schlage doch ein Datenbank-Schema dafür vor, damit wir öffentlich Vergleichen können welche Auswirkungen daß auf den Betrieb von OSM als riesige, öffentliche Datenbank mit vielen Lese und Schreib -Operationen hätte im Vergleich zu den gewonnenen neuen Tagging-Möglichkeiten. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 25. August 2008 14:30 schrieb Bernd Wurst [EMAIL PROTECTED]: Hallo. Am Montag, 25. August 2008 schrieb Marcus Wolschon: Wenn du deinen Vorschlag weiter verfolgen möchtest, bitte schlage doch ein Datenbank-Schema dafür vor, damit wir öffentlich Vergleichen können welche Auswirkungen daß auf den Betrieb von OSM als riesige, öffentliche Datenbank mit vielen Lese und Schreib -Operationen hätte im Vergleich zu den gewonnenen neuen Tagging-Möglichkeiten. Wo finde ich das aktuelle Datenbankschema? Gruß, Bernd -- z.B. im Buch von Ramm/Topf? oder hier: http://wiki.openstreetmap.org/index.php/Database Hier scheint die Info out of date zu sein: http://wiki.openstreetmap.org/index.php/Database_schema es gibt noch hier die API: http://wiki.openstreetmap.org/index.php/Protocol ich kann Dir leider nichts zur Aktualitaet der angegeben Seiten sagen, und weiss daher nicht, ob Du Deine Frage in Kenntnis der obigen Seiten gestellt hast. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 25.08.08 schrieb Marc Schütz [EMAIL PROTECTED]: maxspeed=80 maxspeed(weight=7.5t)=60 access(weight=12t)=access only Bei mehreren Bedingungen halt sowas wie: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 Mehrere Bedingungen vielleicht lieber mit bzw. || verknüpft, damit sich das nicht nur auf einschränkende Bedingungen beschränkt. Gute Idee wobei ich irgendwas mit and und or leichter verständlich für Nicht-Informatiker finde. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik: Schriftart wechseln / Unicode Problem mit Ethiopic
Dirk-Lüder Kreie schrieb: Viel Spaß beim Suchen eines Fonts der UTF8-Complete ist, und auch noch frei ist. Könnte man nicht Parts aus mehreren Fonts in einem vereinigen? Also geeignete freie Quellen wählen und sich daraus einen eigenen, möglichst kompletten Font kreieren? Die Lösung liegt momentan eher in der Richtung, dass man passende Fallback-Fonts vordefinieren können sollte. Also statt einem für alles eine vorgegebene Gruppe an Fonts, die dann (hoffentlich) alles abdeckt, was man so an (Schrift-)Zeichen braucht. Das wäre natürlich auch denkbar. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik: Schriftart wechseln / Unicode Problem mit Ethiopic
Dirk-Lüder Kreie schrieb: Viel Spaß beim Suchen eines Fonts der UTF8-Complete ist, und auch noch frei ist. Könnte man nicht Parts aus mehreren Fonts in einem vereinigen? Also geeignete freie Quellen wählen und sich daraus einen eigenen, möglichst kompletten Font kreieren? Die Lösung liegt momentan eher in der Richtung, dass man passende Fallback-Fonts vordefinieren können sollte. Also statt einem für alles eine vorgegebene Gruppe an Fonts, die dann (hoffentlich) alles abdeckt, was man so an (Schrift-)Zeichen braucht. Das wäre natürlich auch denkbar. Der aktuellste Mapnik (SVN, noch nicht releast) unterstützt bereits Font Fallback. Grüße, Marc -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kantenglättung
Darüber hinaus müsste man mal zur Diskussion stellen, ob es nicht sinnvoll ist, (a) die Texte größer darzustellen, bzw. die Größe konfigurierbar zu machen und (b) das Textantialiasign separat steuerbar zu machen. Beides. Seit ich meinen neuen Laptop habe stört mich die JOSM-Schriftgröße (nicht nur im Display, sondern auch Menüs,...). Statt 1024x800 sind es jetzt 1680x1050 und immer noch 15 Zoll, da ist eine etwas größere Schrift überall notwendig. Ich finde, die Schriftgrösse müsste das darunter liegende System bestimmen. Da hat jeder andere Präferenzen. Ich möchte da nicht jedes Programm separat konfigurieren müssen nur weil ich den Bildschirm wechsle. Z.b. wenn ich den Laptop in der Dockingstation habe. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Martin Koppenhoefer: z.B. im Buch von Ramm/Topf? Nichts gegen die beiden, aber das wird hoffentlich nicht die einzige Informationsquelle sein, oder? Zusätzlich zum Sprit um auf diversen Messen OSM zu repräsentieren will ich nicht auch noch Geld für das Buch ausgeben. oder hier: http://wiki.openstreetmap.org/index.php/Database Verweist nur auf ... http://wiki.openstreetmap.org/index.php/Database_schema ...was veraltet ist. es gibt noch hier die API: http://wiki.openstreetmap.org/index.php/Protocol Die genau was mit dem MySQL-Schema zu tun hat? ich kann Dir leider nichts zur Aktualitaet der angegeben Seiten sagen, und weiss daher nicht, ob Du Deine Frage in Kenntnis der obigen Seiten gestellt hast. Du hast doch selbst gesehen, dass die Wiki-Seite veraltet ist. Das was du genannt hast, kenne ich. Außer dass ich das Buch nicht hier habe. Ich hab auch schon das SVN durchforstet. Da gibt es Ruby-Scripte, die wenn ich das richtig interprtiere die alte Datenbank passend verändern (migration), aber das war mir dann doch zu doof. Gruß, Bernd -- Es vergeht kein Tag an dem ich nicht alles wieder infrage stelle. - André Gide (frz. Schriftsteller) 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] RFC: Tags für Tags - warum so komplizi ert?
Am 25. August 2008 14:51 schrieb Bernd Wurst [EMAIL PROTECTED]: Hallo. Am Montag, 25. August 2008 schrieb Martin Koppenhoefer: z.B. im Buch von Ramm/Topf? Nichts gegen die beiden, aber das wird hoffentlich nicht die einzige Informationsquelle sein, oder? Zusätzlich zum Sprit um auf diversen Messen OSM zu repräsentieren will ich nicht auch noch Geld für das Buch ausgeben. oder hier: http://wiki.openstreetmap.org/index.php/Database Verweist nur auf ... http://wiki.openstreetmap.org/index.php/Database_schema ...was veraltet ist. es gibt noch hier die API: http://wiki.openstreetmap.org/index.php/Protocol Die genau was mit dem MySQL-Schema zu tun hat? ich kann Dir leider nichts zur Aktualitaet der angegeben Seiten sagen, und weiss daher nicht, ob Du Deine Frage in Kenntnis der obigen Seiten gestellt hast. Du hast doch selbst gesehen, dass die Wiki-Seite veraltet ist. Das was du genannt hast, kenne ich. Außer dass ich das Buch nicht hier habe. Ich hab auch schon das SVN durchforstet. Da gibt es Ruby-Scripte, die wenn ich das richtig interprtiere die alte Datenbank passend verändern (migration), aber das war mir dann doch zu doof. Gruß, Bernd -- und ich kann Dir nichtmal sicher sagen, dass die von Dir gewuenschten Informationen im Buch drin sind ;-) Am besten stellst Du Deine Frage nochmal in der dev-ML, das scheint mir die richtigere Adresse zu sein. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
ja, die Luecken wuerde man damit los, wobei das in dem Beispiel noch nicht der Weissheit letzter Schluss waere: die innere Flaeche sollte dort ja keine Rundung haben. Seltsam ist es aber doch, dass er in einem Fall (innen) eine Kurve vermutet (und das bei noch annaehernd 90 Grad), waehrend er im anderen Fall (aussen) davon Abstand nimmt. Wie meinst du dass es dort keine Rundung haben sollte? Weil das ein Typ von Fläche ist, der das nicht braucht? Dann ist der Typ ev. falsch konfiguriert. Es gibt einen Style-Typ (no-bezier) der das Bezier rendering ausschaltet, funktioniert aber nur mit TaH. Wenn der minimal Radius 90° ist, dann werden Winkel mit 90,1° gerundet. Ich denke die grüne Innenfläche wird nicht durch den Bezier Renderer gejagt, daher sind dort alle Ecken rund. Die Innere Fläche jedoch schon und dort halt nur bestimmte Winkel (blöderweise grad die falschen). Wenn ich Zeit finde, werde ich dem Problem nachgehen. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
Am 25. August 2008 14:59 schrieb Raphael Studer [EMAIL PROTECTED]: ja, die Luecken wuerde man damit los, wobei das in dem Beispiel noch nicht der Weissheit letzter Schluss waere: die innere Flaeche sollte dort ja keine Rundung haben. Seltsam ist es aber doch, dass er in einem Fall (innen) eine Kurve vermutet (und das bei noch annaehernd 90 Grad), waehrend er im anderen Fall (aussen) davon Abstand nimmt. Wie meinst du dass es dort keine Rundung haben sollte? Weil das ein Typ von Fläche ist, der das nicht braucht? Dann ist der Typ ev. falsch konfiguriert. ich meinte das bezogen auf den Post von Alexander, der das Beispiel gebracht hat: kann das gleiche gleich nochmal anbieten. http://www.informationfreeway.org/?lat=51.98436784118599lon=13.135559736301165zoom=17layers=B000F000F aber sieht doch eher so aus, dass der Renderer krampfhaft versucht ne Kurve zu zeichnen, wo gar keine ist. Oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so kompli ziert?
On Mon, Aug 25, 2008 at 02:24:47PM +0200, Marcus Wolschon wrote: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * ist trivial zu parsen, Nitpick: Das stimmt nicht, insbesondere in low-level-Sprachen ist das alles andere als trivial. Man könnte allerdings Referenz-Implementationen für die gängigen Sprachen anbieten, d.h. ein Hindernis ist es nicht notwendigerweise. Ich persönlich würde - [] statt () benutzen - Gruppierung per () erlauben - wie von Bernd vorgeschlagen oder-Verknüpfungen erlauben (wobei ich da Klartext ala or und and bevorzuge) Damit wird aus obiger, noch regulärer Sprache zwar eine kontextfreie (= deutlich schwerer zu verarbeiten), aber der Aufwand für den Mapper ist geringer (der müsste sonst die kon- oder disjunktive Normalform verwenden. Ggf. kann man ja ein Tool schreiben, was aus einem Wort der kontextfreien Sprache ein bis mehrere der regulären Sprache macht. Die Anwendungen bearbeiten nur eine Hand voll Wege. Je nach Anwendung. Einen Router mit vernünftiger Geschwindigkeit zu schreiben ist bereits jetzt nicht trivial. Obiger Vorschlag könnte das nochmal deutlich verschlechtern (trotzdem finde ich ihn gut). IMO sind derzeit die wichtigsten Ressourcen bei OSM: 1. Zeit der Mapper 2. Zeit der main db-Entwickler 3. Zeit der Anwendungsentwickler 1. lässt sich durch leicht verständliche, aber knappe Tagging-Formeln sowie Editor-Support für die gängisten Konstrukte (sogar eine Art Formel-Editor wäre denkbar) erreichen. 2. wäre bei den bisherigen Alternativvorschlägen ein Nullwert, also optimal. 3. kann durch passende Referenzimplementierungen verbessert werden. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
edit.initial-move-treshhold Ist das schon drin oder muss man das noch hinzufügen? Einstein kennt das bei mir nicht. Jetzt versteh ich das ganze. Ich hab den Wert Wahscheinlich hinzugefügt als das Feature auf der dev Liste angekündigt wurde. Daher war es bei mir drin und ich konnte einfach im Einstein-Modus nachsehen und musste nicht durch denk ganzen Code durch. In dem Sinne nochmals Entschuldigung für die scharfe Bemerkung von vorhin. Vielleicht sollten alle Möglichen Einstellungen schon von Vorhinein im Einstein-Modus ersichtlich sein. Da würden sie wahrscheinlich eher gefunden wie im Wiki. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kantenglättung
Raphael Studer schrieb: Darüber hinaus müsste man mal zur Diskussion stellen, ob es nicht sinnvoll ist, (a) die Texte größer darzustellen, bzw. die Größe konfigurierbar zu machen und (b) das Textantialiasign separat steuerbar zu machen. Beides. Seit ich meinen neuen Laptop habe stört mich die JOSM-Schriftgröße (nicht nur im Display, sondern auch Menüs,...). Statt 1024x800 sind es jetzt 1680x1050 und immer noch 15 Zoll, da ist eine etwas größere Schrift überall notwendig. Ich finde, die Schriftgrösse müsste das darunter liegende System bestimmen. Da hat jeder andere Präferenzen. Ich möchte da nicht jedes Programm separat konfigurieren müssen nur weil ich den Bildschirm wechsle. Z.b. wenn ich den Laptop in der Dockingstation habe. Die Applikationsschriftart sollte ganz klar aus dem System bezogen werden. Ein vernünftiges LF unterstützt das auch. Ein guter Punkt ist sicher die default-Schriftart und -größe aus dem UI-Manager zu erfragen und damit entsprechend der Systemschriftart zu wählen. Joerg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
2008/8/25 Martin Koppenhoefer [EMAIL PROTECTED]: Am 25. August 2008 14:59 schrieb Raphael Studer [EMAIL PROTECTED]: ja, die Luecken wuerde man damit los, wobei das in dem Beispiel noch nicht der Weissheit letzter Schluss waere: die innere Flaeche sollte dort ja keine Rundung haben. Seltsam ist es aber doch, dass er in einem Fall (innen) eine Kurve vermutet (und das bei noch annaehernd 90 Grad), waehrend er im anderen Fall (aussen) davon Abstand nimmt. Wie meinst du dass es dort keine Rundung haben sollte? Weil das ein Typ von Fläche ist, der das nicht braucht? Dann ist der Typ ev. falsch konfiguriert. ich meinte das bezogen auf den Post von Alexander, der das Beispiel gebracht hat: Hab die Frage schlecht gestellt: Aus welchem Grund sollte es dort keine Rundungen haben? Ich denke alle Winkel 90° (oder vielleicht auch 91) werden gerundet. Weil davon ausgegangen wird dass etwas entweder absichtlich rechtwinklig gemacht oder ansonsten Rund ist. Ausser es wird ihm explizit im Stylesheet mitgeteilt dass dieser Linientyp nicht gerundet werden soll. Z.B. Gebäude oder Stromleitungen. Wie ich grad sehe auch highway-xx-area, was immer eine Strassenfläche ist :) Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namefinder-Entwicklung
On Sun, Aug 24, 2008 at 10:07:10PM +0200, Tobias Wendorff wrote: Da bin ich ja mit meinem 400 Haltestellen noch gut bedient. Ja, aus Sicht des Namefinders ist das Pillepalle. :) Das ist das interessante an der Arbeit mit OSM-Daten: Es sind riesige Mengen. Da ist der Unterschied zwischen verschiedenen Ansätzen, Algorithmen, Sprachen und Containern sehr deutlich. Es lohnt sich, die komplette Kette von Prototyp (in Hochsprache) zu Gesamtsystem (Hochsprache+low-level) zu durchlaufen. Bisher dachte ich auch, es sei schneller, Vektordaten darzustellen (von wegen Beschleunigung per Graka und so) als Rasterdaten. Das sehe ich jetzt nicht mehr so pauschal. :) [Phonetik] Muss jemanden finden, der das von PHP nach C/C++ wandelt oder was benötigst Du? Für die Suche selbst muß es C(++) sein, ja, sonst wirds zu langsam (der alte Namefinder lässt das von MySQL erledigen, verwendet dafür also auch kein PHP). [Frontend] Gerne, beliebt es Dir in PHP oder suchst Du kein Website-Frontend? Da es den alten Namefinder ersetzen soll, muß es auch ein Website-Frontend geben. Ich persönlich würde Python stark bevorzugen (zumal es schon eine Python-Implementierung für das Protokoll zwischen Frontend und Suchkern gibt), aber PHP ist besser als gar nix. PS: Bitte kein CC an mich. Mein MUA setzt extra Mail-Followup-To, damit das nicht passiert. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am 25.08.08 schrieb Sascha Silbe [EMAIL PROTECTED]: On Mon, Aug 25, 2008 at 02:24:47PM +0200, Marcus Wolschon wrote: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * ist trivial zu parsen, Nitpick: Das stimmt nicht, insbesondere in low-level-Sprachen ist das alles andere als trivial. Man könnte allerdings Was bezeichnest du jetzt als low-level? PHP, Java. Python, C#,.. geht super. Sogar Shell-Script kann das ausreichend parsen regex und Funktionen) und daß hier jemand sowas in Assember parsen will glaub ich mal nicht, Referenz-Implementationen für die gängigen Sprachen anbieten, d.h. ein Referenz-Implementierung um welche Frage mit Hilfe solch eines Ausdruckes zu beantworten? Halte ich für simplex Ausdruck-Parsen für übertrieben. Klar, kann ich dir für Java in 30min super dokumentiert und objekorientiert runtertippen. Dann weis jeder wie er's in seiner Sprache machen muss und hat etwas zum Vergleichen ob er's richtig gemacht hat. Ich persönlich würde - [] statt () benutzen - Gruppierung per () erlauben - wie von Bernd vorgeschlagen oder-Verknüpfungen erlauben (wobei ich da Klartext ala or und and bevorzuge) gerne doch. Macht Vorschläge! Damit wird aus obiger, noch regulärer Sprache zwar eine kontextfreie (= deutlich schwerer zu verarbeiten), aber der Aufwand für den Mapper ist geringer (der müsste sonst die kon- oder disjunktive Normalform verwenden. Ggf. kann man ja ein Tool schreiben, was aus einem Wort der kontextfreien Sprache ein bis mehrere der regulären Sprache macht. garnicht nötig. Eine Sprache die nur aus (X), (X and X), (X or X) und x:= String [==,!=,,=,,,=] String besteh zu parsen sollte nun nicht schwer fallen. Wenn ein Programm das nicht kann, kann es diese Tags immernoch wie alle anderen ignorieren und weiter nur das default maxspeed=[0-9]* auswerten. Die Anwendungen bearbeiten nur eine Hand voll Wege. Je nach Anwendung. Einen Router mit vernünftiger Geschwindigkeit zu schreiben ist bereits jetzt nicht trivial. Obiger Vorschlag könnte das nochmal deutlich verschlechtern (trotzdem finde ich ihn gut). Was erzählst du mir wdas? Ich schreibe seit letztem Jahr an einem. 1. lässt sich durch leicht verständliche, aber knappe Tagging-Formeln sowie Editor-Support für die gängisten Konstrukte (sogar eine Art Formel-Editor wäre denkbar) erreichen. 1 Wiki-Seite mit 3 Beispiele und die gleichen 3 als Popup im Editor XYZ würden auch schon reichen. ;) Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mit jeder JOSM Version wirds schlimmer
Vielleicht sollten alle Möglichen Einstellungen schon von Vorhinein im Einstein-Modus ersichtlich sein. Da würden sie wahrscheinlich eher gefunden wie im Wiki. Siehe dazu 17-08-2008: Message-ID: [EMAIL PROTECTED] Subject: Re: [Talk-de] Kilometrierung von Autobahnen und anderen Strassen Ah da hat jemand einen Thread missbraucht :) Drum ist mir das entgangen. Dankeschön. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
Hallo, na die Rundung oder auch sonstwas ist ja nicht das eigentlich Problem. Es müßte doch aber geprüft werden, ob die Kante von der Polygone identisch ist. Wenn also eine Relation vom Type multipolygon existiert, dann sollte so gerendert werden, dass die Bedingung für beide Teilpolygone erfüllt ist. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hundesportvereine erfassen
Moin !! heute einmal eine Frage zum Thema Hundesport. Wie würdet Ihr Hundesportplätze taggen ??? Ich habe schon einmal etwas von Hundeschulen gelesen - aber das sind gewerbliche Firmen die sich mit dem Thema beschäftigen. Mir geht es um die Freizeit-Sportvereine zum Thema. Gruß Jan :-) -- Freundliche Grüße Jan Tappenbeck --- OpenStreetMap (OSM) - das FREIE Kartenprojekt Aktuelle Karten Mitteleuropa: http://www.openstreetmap.de/karte.html Lübeck: http://www.openstreetmap.de/karte.html?zoom=12lat=53.86927lon=10.688layers=B0 Hamburg: http://www.openstreetmap.de/karte.html?zoom=11lat=53.58175lon=10.02522layers=B0 Dithmarschen (hier gibt es noch viel zu tun !): http://www.openstreetmap.de/karte.html?zoom=10lat=54.15906lon=9.16005layers=B0 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Unverbundene Radwege, jetzt ist Deutschland komplett!
werde ich probieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Unverbundene Radwege, jetzt ist Deutschland komplett!
das wird schwer. es ist ja eine statische html seite. evtl. kann man auf der wiki seite eintragen, dass man sich in der woche X mit dem Land Y beschäftigt. aufgrund der langen rechenzeit kann ich das programm auch nicht jeden tag laufen lassen... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karten von Computerteddy unter 64 bit
Moin ! ich wollte mir die Karten von Computerteddy auf meinem VISTA 64 bit einrichten. Die Dateiablage habe ich genauso gemacht wie in dem dortigen REG-Beispiel. Beim Starten vom MapSource bekomme ich eine Meldung, dass die Reg falsch ist und ich neuinstallieren sollte. Entferne ich den Reg wieder, dann ist alles OK ! Hat einer von Euch Erfahrungen mit Vista 64 bit ? Gruß Jan :-) --- OpenStreetMap (OSM) - das FREIE Kartenprojekt Aktuelle Karten Mitteleuropa: http://www.openstreetmap.de/karte.html Lübeck: http://www.openstreetmap.de/karte.html?zoom=12lat=53.86927lon=10.688layers=B0 Hamburg: http://www.openstreetmap.de/karte.html?zoom=11lat=53.58175lon=10.02522layers=B0 Dithmarschen (hier gibt es noch viel zu tun !): http://www.openstreetmap.de/karte.html?zoom=10lat=54.15906lon=9.16005layers=B0 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OpenRouteService im OSM Wiki
Hi, hab mal eine schon seit längerem gewünschte Wiki Seite über OpenRouteService.org (ORS) erstellt: http://wiki.openstreetmap.org/index.php/OpenRouteService Unter: http://wiki.openstreetmap.org/index.php/Talk:OpenRouteService könnt Ihr Eure Probleme, Wünsche schreiben oder einfach was wie gut Euch der Service gefällt ;-) grüße pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Am Montag 25 August 2008 schrieb Marcus Wolschon: Am 25.08.08 schrieb Sascha Silbe [EMAIL PROTECTED]: On Mon, Aug 25, 2008 at 02:24:47PM +0200, Marcus Wolschon wrote: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * ist trivial zu parsen, Nitpick: Das stimmt nicht, insbesondere in low-level-Sprachen ist das alles andere als trivial. Man könnte allerdings Was bezeichnest du jetzt als low-level? PHP, Java. Python, C#,.. geht super. Sogar Shell-Script kann das ausreichend parsen regex und Funktionen) und daß hier jemand sowas in Assember parsen will glaub ich mal nicht, Referenz-Implementationen für die gängigen Sprachen anbieten, d.h. ein Referenz-Implementierung um welche Frage mit Hilfe solch eines Ausdruckes zu beantworten? Halte ich für simplex Ausdruck-Parsen für übertrieben. Klar, kann ich dir für Java in 30min super dokumentiert und objekorientiert runtertippen. Dann weis jeder wie er's in seiner Sprache machen muss und hat etwas zum Vergleichen ob er's richtig gemacht hat. Ich persönlich würde - [] statt () benutzen - Gruppierung per () erlauben - wie von Bernd vorgeschlagen oder-Verknüpfungen erlauben (wobei ich da Klartext ala or und and bevorzuge) gerne doch. Macht Vorschläge! ok, gut ;-) mein vorschlag zu benanntem beispiel: * Autos: Höchstgeschwindigkeit 80 km/h * LKW ab 7,5 Tonnen: Höchstgeschwindigkeit 60 km/h * LKW ab 12 Tonnen: Nur Anlieger frei limit.speedmax = 80 limit.speedmax[weight:7.5] = 60 limit.access[weight:12] = access only mit der generellen definition, dass: - geschwindigkeiten in km/h angegeben werden - gewichtsangaben in tonnen angegeben werden - das angegebene gewicht immer groessergleich mit einschliesst. eine 'oder' verknüpfung sollte nicht noetig sein, das laesst sich als separates tag schreiben, ein beispiel: limit.access[weight:7.5] = no limit.access[height:3.5] = no das wuerde bedeuten, dass fahrzeuge die schwerer als 7,5t oder hoeher als 3,5m sind, nicht reinfahren duerfen. 'und' verknüpfungen wuerde ich auch durch reines aneinanderreihen realisieren: limit.access[weight:3.5][height:2.8] = access only das sollte sich recht einfach parsen lassen, und lesbar ist es auch... 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] RFC: Tags für Tags - warum so kompli ziert?
On Mon, Aug 25, 2008 at 04:02:57PM +0200, Marcus Wolschon wrote: Was bezeichnest du jetzt als low-level? Assembler, C, C++ (ohne spezielle Libraries). PHP, Java. Python, C#,.. geht super. Sind alle nicht low-level. Referenz-Implementationen für die gängigen Sprachen anbieten, d.h. ein Referenz-Implementierung um welche Frage mit Hilfe solch eines Ausdruckes zu beantworten? 1. Um ihn überhaupt in eine Form zu bekommen, in der ein Programm Fragen beantworten kann. 2. Um bei Eingabe aller bekannten Variablen (incl. Inhalt) das Ergebnis der Formel zu bekommen (in trinärer Logik wie bei SQL). Klar, kann ich dir für Java in 30min super dokumentiert und objekorientiert runtertippen. In Python bekomm ich das auch hin (wobei ich mit den 30 Minuten vorsichtig wäre). In C würde ich aber wesentlich länger brauchen. garnicht nötig. Eine Sprache die nur aus (X), (X and X), (X or X) und x:= String [==,!=,,=,,,=] String besteh zu parsen sollte nun nicht schwer fallen. Meine Erfahrungen waren bisher eher gegenteiliger Natur. Sobald es kontextfrei wird (und bereits verschachtelte Klammern sind kontextfrei) wirds aufwendig. Wenn ein Programm das nicht kann, kann es diese Tags immernoch wie alle anderen ignorieren und weiter nur das default maxspeed=[0-9]* auswerten. Mir schon klar, daß man die unbedingten Formen auch ungeparsed verarbeiten kann. Aber es geht in diesem Thread ja genau um die Formen, die Bedingungen erfordern. [Nicht-langsamen Router schreiben nicht-trivial, Verschlimmerung durch neues Tagging-Schema möglich] Was erzählst du mir wdas? Ich schreibe seit letztem Jahr an einem. War mehr an die anderen gerichtet. 1. lässt sich durch leicht verständliche, aber knappe Tagging-Formeln sowie Editor-Support für die gängisten Konstrukte (sogar eine Art Formel-Editor wäre denkbar) erreichen. 1 Wiki-Seite mit 3 Beispiele und die gleichen 3 als Popup im Editor XYZ würden auch schon reichen. ;) Wenn die Form für die meisten Mapper (nicht Programmierer!) verständlich ist, reicht es als Erklärung vll. aus. Aber um den Zeitaufwand zu reduzieren müssen die häufigsten Formen auch ohne viel Interaktion erreichbar sein. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ein Fall fuer den divider, war: Abbiegeregeln...
Hallo, dieses Problem tritt sehr oft auf. Scheon zu beobachten, wenn z.B. eine einfache Strasse (eine Spur hin, eine zurueck, gestrichelte oder durchgezogene Mittellinie) kreuzungsfrei ausgebaut ist. Fuer einen Router ohne weitere Info ist der neachstbeste Knoten ein gefundenes Fressen und da beim Linksabbiegen die Schleifen der Abbiegespuren ganz schoen lang sein koennen, findet er es viel attraktiver (=kuerzer/schneller), die Ausfahrtsspur der Gegenfahrbahn zu nehmen. Man kann natuerlich die jetzt als baulich getrennt reinzeichnen und dann kommt er nimmer rueber, aber das verzerrt die Wirklichkeit und ist mit Kanonen auf Spatzen geschossen. Eleganter ist schon, dem Router mitzuteilen, dass er nicht rueber kann. Das kann auch die Routine uebernehmen, die das Netz fuer den Router aufbereitet - die sperrt die Option einfach. Der (legal-) divider ist schon eine tolle Sache und kann diese Dinge stilvoll loesen :) Gruesse Hubert Original-Nachricht Datum: Mon, 25 Aug 2008 11:59:17 +0200 Von: Christoph Eckert [EMAIL PROTECTED] An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Abbiegeregeln und Spitzkurven Moin, warum sollte das nicht möglich sein? Es ist m.E. sogar der Standardfall, dass man bei einer baulich getrennten Straße an den Stellen, wo die Trennung aufgehoben wird, wenden kann. bei mir war mel einer am Stand, der sich Routing mit Navit hat zeigen lassen. Er interessierte sich für eine Bundesstraßenkreuzung bei Ettlingen. Zwei getrennte Fahrspuren vereinigen sich. Direkt nach der Vereinigung geht links eine Abfahrt weg. Rein von der Beschilderung und dem baulichen Zustand her dürfte man hier sogar links abbiegen, was sich aber aufgrund der Verkehrssituation verbietet. Stattdessen nutzt man die dafür vorgesehene Abbiegespur rechts weg. Navit erkannte aber wohl, dass Linksabbiegen die kürzere Alternative sei :-) . Insofern mag eine Art Regel bei Vereinigung zweier Fahrspuren höherer Straßen außerorts noch ein paar Meter zuwarten, bevor Linksabbiegen erlaubt ist nicht die dümmste sein. Allerdings kann Navit anhand unserer Daten derzeit nicht erkennen, ob eine Straße inner- oder außerorts ist. Für's Routing wäre das eine äußerst interessante Info. Beste Grüße, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Marcus Wolschon schrieb: Bei mehreren Bedingungen halt sowas wie: maxspeed(weight=7.5t)(Mondfeuchte=grün)=60 * versteht ein Mensch, Ich dachte bisher, dass die Vielseitigkeit von OSM auf der Möglichkeit basiert, dass die Daten direkt in einer Software zu verwenden (ohne großartiges parsing). Das Beispiel ist aber auch eine schwierige Nuss, das muss ich zugeben. GeoJ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
Am 25. August 2008 15:59 schrieb Raphael Studer [EMAIL PROTECTED]: ich wuerde das Gegenteil bevorzugen: Rundung nur dann, wenn man es explizit angibt. Macht aber mehr Aufwand, weil Grundsätzlich alles Rund ist. Vor allem Strassenkurven, Wälder, Seen, Flüsse. das stimmt fuer die Natur schon (von Felsen abgesehen), aber fuer vom Menschen zurechtgebogene Natur schon nicht. Die von Dir aufgezaehlten Sachen findet man alle auch in eckig: Waelder, Fluesse, div. areas. (Felder, residential, etc.) Mir fallen nur Gebäude, Stromleitungen und Skilifte ein die normalerweise eckig sind. Zäune und Grenzen wahrscheinlich auch noch, sofern sie nicht irgend einem Fluss o.ä. folgen. Grüsse Raphael Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
2008/8/25 Martin Koppenhoefer [EMAIL PROTECTED]: Am 25. August 2008 15:59 schrieb Raphael Studer [EMAIL PROTECTED]: ich wuerde das Gegenteil bevorzugen: Rundung nur dann, wenn man es explizit angibt. Macht aber mehr Aufwand, weil Grundsätzlich alles Rund ist. Vor allem Strassenkurven, Wälder, Seen, Flüsse. das stimmt fuer die Natur schon (von Felsen abgesehen), aber fuer vom Menschen zurechtgebogene Natur schon nicht. Die von Dir aufgezaehlten Sachen findet man alle auch in eckig: Waelder, Fluesse, div. areas. (Felder, residential, etc.) Natürlich findet man auch eckige Wälder, die sind allerdings eine grosse Ausnahme. Eckige Flüsse hab ich allerdings noch nie gesehen, höchstens begradigte. Bei einigen areas könnte man den no-bezier allerdings noch hinzufügen, da geb ich dir recht. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegeregeln und Spitzkurven
Hallo, jetzt fang ich wieder damit an: baulich-getrennt heißt baulich getrennt. Wenn die Wege zusammenführen heißt das nur, dass danach eine Fahrbahn = durchgängige Asphaltierung und keine baulichen Hindernisse zwischen den einzelnen Fahrspuren. Wenn doppelt durchgezogene Linie oder Schilder das Linksabbiegen verbieten, dann sollte auch eine no-left-turn / no-U-Turn-Restriktion erzeugt werden - IMHO. Grüße, PieSchie Martin Koppenhoefer schrieb: Allerdings sollte es nicht möglich sein, eine Straße die baulich getrennt ist und dann zusammen geführt wird, an dieser Stelle als links abbiegen wieder zurück zu fahren. warum sollte das nicht möglich sein? Es ist m.E. sogar der Standardfall, dass man bei einer baulich getrennten Straße an den Stellen, wo die Trennung aufgehoben wird, wenden kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Render-Fehler?
Am 25. August 2008 17:12 schrieb Raphael Studer [EMAIL PROTECTED]: 2008/8/25 Martin Koppenhoefer [EMAIL PROTECTED]: Am 25. August 2008 15:59 schrieb Raphael Studer [EMAIL PROTECTED]: ich wuerde das Gegenteil bevorzugen: Rundung nur dann, wenn man es explizit angibt. Macht aber mehr Aufwand, weil Grundsätzlich alles Rund ist. Vor allem Strassenkurven, Wälder, Seen, Flüsse. das stimmt fuer die Natur schon (von Felsen abgesehen), aber fuer vom Menschen zurechtgebogene Natur schon nicht. Die von Dir aufgezaehlten Sachen findet man alle auch in eckig: Waelder, Fluesse, div. areas. (Felder, residential, etc.) Natürlich findet man auch eckige Wälder, die sind allerdings eine grosse Ausnahme. Eckige Flüsse hab ich allerdings noch nie gesehen, höchstens begradigte. Bei einigen areas könnte man den no-bezier allerdings noch hinzufügen, da geb ich dir recht. Grüsse Raphael nun gut, echte Fluesse wird es nicht in eckig geben, Hafenbecken, auch Binnenhaefen, Teiche und andere menschgemachte Anlagen in z.T. riesigen Dimensionen allerdings schon. Es bringt auch nichts, hier Haarspalterei zu betreiben, es gibt nunmal das meiste sowohl in eckig als auch in rund. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Deichverteidigungsdepots, Evakuierungstreffpunkte
Deichverteidigungsdepots sind (meist umzäunte) Plätze in der Nähe von Deichen, auf denen Paletten mit Sandsäcken gelagert werden, und wo eventuell Bauwagen oder Hütten mit sonstigen Materialien herumstehen. Wie tagge ich die? Wie tagge ich Bushaltestellen, die gleichzeitig als Evakuierungstreffpunkte gekennzeichnet sind? - Also die Stellen, an denen man mit Bussen abgeholt wird, wenn die Gefahr besteht, dass der Deich bei der nächsten Sturmflut bricht oder überflutet wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unverbundene Radwege, jetzt ist Deutschland komplett!
GS [EMAIL PROTECTED] schrieb: das wird schwer. es ist ja eine statische html seite. evtl. kann man auf der wiki seite eintragen, dass man sich in der woche X mit dem Land Y beschäftigt. aufgrund der langen rechenzeit kann ich das programm auch nicht jeden tag laufen lassen... Wenn außer mir noch mehr Interesse an so einer Funktion haben, könnte ich ein Sktipt schreiben, das die Liste in Webformulare umwandelt, über die man jeden Eintrag als erledigt (ggf. auch anders, etwa benötigt ortskundigen Bearbeiter) markieren kann. Oder vielleicht auch eines, das aus der Liste eine Wiki-Seite macht, die sich dann entsprechend bearbeiten lässt. All das ist aber nur so recht hilfreich, wenn die (meisten) Bearbeiter ihre Arbeiten dann auch eintragen. Von daher erst mal meine Frage nach Interesse. Gruß, Mark ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Marcus Wolschon: Wenn du deinen Vorschlag weiter verfolgen möchtest, bitte schlage doch ein Datenbank-Schema dafür vor, damit wir öffentlich Vergleichen können welche Auswirkungen daß auf den Betrieb von OSM als riesige, öffentliche Datenbank mit vielen Lese und Schreib -Operationen hätte im Vergleich zu den gewonnenen neuen Tagging-Möglichkeiten. Okay, habe das aktuelle Datenbank-Schema jetzt unter http://gweb.bretth.com/osm_schema_latest.sql gefunden. Also ausgehend von dem Schema würde ich mal sagen: Dann kann man einfach eine Tabelle tag_tags analog zu node_tags, way_tags und relation_tags anfügen, das würde auch nicht mehr ausbremsen. Auch wenn ich mir grade sehr sicher bin, dass das aktuelle Schema auch nicht der Weisheit letzter Schluß ist (Nein, ich hab so auf die schnelle keinen Alternativ-Vorschlag in der Tasche). Gruß, Bernd -- Verbesserung der Oberfläche hört sich an wie die Streichung liebgewonnener Features - bei GNOME weiss man ja nie... (gefunden auf www.prolinux.de) 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] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Bernd Wurst: Also ausgehend von dem Schema würde ich mal sagen: Dann kann man einfach eine Tabelle tag_tags analog zu node_tags, way_tags und relation_tags anfügen, das würde auch nicht mehr ausbremsen. Okay, bei nodes scheinen die tags ja gar nicht ausgelagert zu sein sondern sie werden serialisiert in ein Text-Feld geschrieben. Wenn sich das bei der Datenmenge wirklich als sinnvoll herausstellt, kann man auch sub-tags entsprechend in die einfachen tags rein codieren. Zusatzfeld subtags in der alles serialisiert wird was es gibt. Dadurch würde es weitestgehend abwärtskompatibel der Form, dass eine einfache Filter-Anfrage i.d.R. nur auf Haupt-Tags kommt und ein filtern danach identisch zu jetzt wäre. Wie die Tags bei den Nodes serialisiert werden und warum das bei nodes Sinn macht, bei ways aber offenbar nicht, ist mir weiterhin nicht ganz klar (vermutlich wegen: Es gibt viele Nodes ohne Tags, aber ganz wenige ways ohne Tags), aber das sind Details, die sich von der bisherigen Erfahrung 1:1 übernehmen lassen. Gruß, Bernd -- Wegen des Loches im Staatshaushalt wurde das Licht am Ende des Tunnels gelöscht. 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] ORS: Von Italien nach Dänemark .. .
Martin Koppenhoefer schrieb: Am 23. August 2008 21:41 schrieb Jens Müller [EMAIL PROTECTED]: Pascal Neis schrieb: Erweiterung der Abdeckung von OpenRouteService.org ... Wie wäre es mal mit Bugfixes? Das Fahrradrouting schickt mich immer noch entgegen einer Einbahnstraße (falsche Richtungsfahrbahn) und durch ein Einfahrt verboten. Vgl. Mail in dieser Liste am 21.8.2008 um 11:18 Uhr. bitte nicht ändern, oder 2 Fahrradmodi: einen für Regelpedanten, einen für Pragmatiker. In Italien können Fahrradfahrer übrigens einigermaßen alles machen, ohne von der Polizei Probleme zu bekommen, und kein Radler wird sich ein Problem daraus machen, gegen eine Einbahnstraße zu fahren (oder einen FUssweg zu benutzen, oder ein Einfahrt verboten zu passieren). Evtl. könnte man sowas über Checkboxen vorher vom Nutzer abfragen. Oder man nimmt einfach das Fußgängerrouting ... Darauf läuft Dein Pragmatismus doch hinaus, oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unverbundene Radwege, jetzt ist Deutschland komplett!
Mark Obrembalski schrieb: GS [EMAIL PROTECTED] schrieb: das wird schwer. es ist ja eine statische html seite. evtl. kann man auf der wiki seite eintragen, dass man sich in der woche X mit dem Land Y beschäftigt. aufgrund der langen rechenzeit kann ich das programm auch nicht jeden tag laufen lassen... Wenn außer mir noch mehr Interesse an so einer Funktion haben, könnte ich ein Sktipt schreiben, das die Liste in Webformulare umwandelt, über die man jeden Eintrag als erledigt (ggf. auch anders, etwa benötigt ortskundigen Bearbeiter) markieren kann. Oder vielleicht auch eines, das aus der Liste eine Wiki-Seite macht, die sich dann entsprechend bearbeiten lässt. All das ist aber nur so recht hilfreich, wenn die (meisten) Bearbeiter ihre Arbeiten dann auch eintragen. Von daher erst mal meine Frage nach Interesse. bin dafür Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [OSM Dortmund] An die Dortmunder - SEHR gute Nachrichten!
Hallo, das ist ja wirklich Klasse. Ich bin natürlich daran interessiert Dich zu begleiten. Falls es allerdings zeigt, das jemand anders mehr fachlich oder generellen Beistand leisten kann, dann einfach Bescheid sagen. Hat H. von Stillfierd vielleicht schon laut darüber nachgedacht was er sich vorstellen könnte? VG Markus Tobias Wendorff schrieb: Hallo Leute, ich habe heute eine Mail vom Vermessungs- und Katasteramt der Stadt Dortmund bekommen. Herr von Stillfried schreibt dort, dass die OSM-Community mit großem Interesse verfolgt wurde und das Amt auch Kenntnis vom geplanten Mapper-Treffen hat. Und jetzt das, was mich _sehr_ überwältigt hat: Das Vermessungs- und Katasteramt möchte sich mit uns treffen und besprechen, mit welchen Daten die Aktivitäten im OSM von der Seite der Stadt Dortmund unterstützt werden können! Auch über die Thematik Lizenz- und Urheberrecht sind sie sich bewusst. Juhu! Herr von Stillfried bietet zwei Termine an: - Montag, 08.09.2008 zwischen 14 und 16 Uhr - Dienstag, 09.09.2008 zwischen 09 und 12 Uhr Ich kann an beiden Terminen, wer möchte mit? Mir würde der 1. Termin gut passen (Bequemlichkeit). Viele Grüße Tobias ps: Ich bin vermutlich am 21.09.2008 bei den GIS-Kompetenztagen in Bonn, werde aber für das OSM-Treffen einen Tag eher abreisen (außer es gibt ein gutes Mittagsbuffet). Gibt es schon TOPs? ___ Dortmund mailing list [EMAIL PROTECTED] http://lists.openstreetmap.de/cgi-bin/mailman/listinfo/dortmund ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS: Von Italien nach Dänemark .. .
Jens Müller schrieb: Oder man nimmt einfach das Fußgängerrouting ... Darauf läuft Dein Pragmatismus doch hinaus, oder? wie siehts dann mit highway=steps aus? Gruß, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS: Von Italien nach Dänemark .. .
Hallo. Am Montag, 25. August 2008 schrieb Thomas Hieber: wie siehts dann mit highway=steps aus? Wer ein richtiger Fahrradfahrer ist, den stört das auch nicht. Die Debatte ist doch müßig, ein Radfahrer der sich per Routenplaner die Tour planen lässt, ist nicht einer, der die Verkehrsregeln als gut gemeinten Hinweis versteht. Wenn ich ne gemütliche Fahrt machen will, dann sehe ich keinen Grund darin, dass ich jetzt unbedingt gegen Einbahnstraßen oder auf mehrspurigen Landstraßen ohne Radweg fahren muss, nur weil ich es könnte. Gruß, Bernd -- Homer Simpson an der Bank: Mein Name ist Mr. Burns. Lautsprecher: Und wie ist ihr Vorname? Homer: Das hab ich vergessen! 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] RFC: Tags für Tags - warum so kompli ziert?
On Mon, Aug 25, 2008 at 07:10:52PM +0200, Bernd Wurst wrote: Okay, bei nodes scheinen die tags ja gar nicht ausgelagert zu sein sondern sie werden serialisiert in ein Text-Feld geschrieben. Ich dachte, das wäre inzwischen geändert? Bin allerdings gerade zu faul, die entsprechende Mail auf -dev rauszusuchen CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so komplizi ert?
Hallo. Am Montag, 25. August 2008 schrieb Sascha Silbe: Ich dachte, das wäre inzwischen geändert? Meine Info basiert auf besagtem DB-Schema, das keine Angabe über die Aktualität beinhaltet (latest, sic). Bin allerdings gerade zu faul, die entsprechende Mail auf -dev rauszusuchen Siehst du, ich schmolle jetzt hier auch weil ich derart grundlegende Info nicht durch Recherche finden kann. Man findet zwar Aufrufe des dev-teams, dass sie Leute suchen die das DB-Schema optimieren, aber das aktuelle ist gar nicht öffentlich. Also müssen jetzt alle die sich für begabt halten, aktiv nach dem Schema fragen ohne zu wissen wie das aktuelle aussieht und ob man da wirklich nen Tipp hat. Da vergeht mir die Lust zur aktiven Mitarbeit. Gruß, Bernd -- Keine zwei Menschen gleichen einander, und beide sind froh darüber signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegeregeln und Spitzkurven
udo.besenreuther.de schrieb: Aus meiner Sicht gibt es nur ein sicheres Kennzeichen ein umkehren zu verbieten: das Richtungskennzeichen (one way) Kann mir sehr gut die Situation in den Bergen vorstellen, wo zwei Straßen baulich sehr eng beieinander laufen aber höhenmäßig auseinander liegen. Meist laufen die Straßen dann recht spitz ineinander. Um von oben nach unten zu kommen muss man dann die Spitzkehre nehmen. Sicher gibt es noch andere Beispiele, an welchen man allein von der geografischen Anordnung (Projektion) nicht auf Abbiegeregeln schließen kann. Ich denke es geht darum wenn zwei baulich getrennte Fahrbahnen (4spurigeStrasse) zu einer zweispurigen bzw. ohne bauliche Trennung zusammengeführt wird. Serpetinen im Gebirge sollten für den Router keine Probleme machen, nur dass manchmal wegen der dichten räumlichen Lage auf die eigenen Position auf die falsche Strasse gemapped wird weil das GPS-Signal dass nicht mehr auflösen kann, aber das ist kein Kartendatenproblem. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegeregeln und Spitzkurven
Martin Koppenhoefer schrieb: Am 25. August 2008 07:46 schrieb Andreas Pothe [EMAIL PROTECTED]: Martin Koppenhoefer wrote: warum sollte das nicht möglich sein? Es ist m.E. sogar der Standardfall, dass man bei einer baulich getrennten Straße an den Stellen, wo die Trennung aufgehoben wird, wenden kann. In welchem Land? In Deutschland jedenfalls nicht. innerorts / ausserorts? Jedenfalls sind weder OSM noch die ueblichen derzeitigen Router auf Deutschland beschraenkt. Woher sollte die Hat er ja auch nicht behauptet - nur dass er in Deutschland diese Situation nicht als üblich kennt worum es hier in der Liste ja hauptsächlich geht. Routingsoftware denn Deiner Ansicht nach wissen, dass man an diesem gemeinsamen Node (=Kreuzung) nicht von einer auf die andere Spur/Seite wechseln kann? Nur am Winkel kann es jedenfalls nicht gehen, weil es auch solche spitzwinkligen Kreuzungen gibt, wo man durchaus fahren darf. Hier sollte ein Router grundsätzlich nicht zum Wenden aufforden, da gab es schon böse Unfälle, insbesondere wenn noch eine Tram-Strecke in der Strassenmitte verläuft! Und das ist unabhängig vom Land! Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abbiegeregeln und Spitzkurven
Martin Koppenhoefer schrieb: Großstädten wäre genau so eine Regel oft falsch. Hier gibt es gerne mal mehrspuring Durchgangs-Straßen bei denen das sehrwohl erlaubt ist. Mein Vorschlag: Nicht generell verbieten sondern da, wo es nicht geht halt eine entsprechende Relation taggen. Marcus sehe ich genauso. In der Regel sollte der Router davon ausgehen, dass er eine Verbindung auch nutzen kann. Wenn nicht, ist entweder flasch gemappt (Verbindung, wo keine ist), oder man muss durch eine Relation klar machen, dass man die Verbindung nicht nutzen darf. Wenn man hier mit Sonderregeln anfaengt (erst nach 50 m ausserorts), wird die Sache bald unuebersichtlich und undurchschaubar. Abbiegen in eine Strasse die links weg geht ist ja OK wenn es nicht explizit verboten ist. Aber zum Wenden auf freier Strecke (also wenn keine Strasse einmündet) sollte niocht aufgefordert werden nur weil die bauliche Trennung aufgehoben ist! Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM - Ausgabe der Mausposition als NMEA-Simulation?
Gibt es sowas schon um andere Anwendungen zu testen wie sie die aktuelle Position darstellen (z.B. Test von Routern)? Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS: Von Italien nach Dänemark . ..
Bernd Wurst schrieb: Hallo. Am Montag, 25. August 2008 schrieb Thomas Hieber: wie siehts dann mit highway=steps aus? Wer ein richtiger Fahrradfahrer ist, den stört das auch nicht. Die Debatte ist doch müßig, ein Radfahrer der sich per Routenplaner die Tour planen lässt, ist nicht einer, der die Verkehrsregeln als gut gemeinten Hinweis versteht. Wenn ich ne gemütliche Fahrt machen will, dann sehe ich keinen Grund darin, dass ich jetzt unbedingt gegen Einbahnstraßen oder auf mehrspurigen Landstraßen ohne Radweg fahren muss, nur weil ich es könnte. Öhm - daß der mehrspurige Landstraßen ohne Radweg ausschließt, will ich nun eigentlich nicht. Meist sind die eh nicht die kürzeste Strecke, aber wenn, dann sind andere Straßen meist ein großer Umweg. Und ein bicycle=no steht eh schon dran, lange bevor es ungemütlich wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hundesportvereine erfassen
Ich hab da bisher ganz kreativ sport=dog_training operator=Name des Vereins benutzt. Wird natürlich nicht gerendert, aber die Koordinaten sind erst mal in der Datenbak. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM - Ausgabe der Mausposition als NMEA-Simulation?
Hi! Am 25. August 2008 21:59 schrieb Garry [EMAIL PROTECTED]: Gibt es sowas schon um andere Anwendungen zu testen wie sie die aktuelle Position darstellen (z.B. Test von Routern)? Schau dir mal das an: http://gpsd.berlios.de/gpsfake.html bei Ubuntu ist das im Paket python-gps, bei Debian afaik gpsd-clients Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unverbundene Radwege, jetzt ist Deutschland komplett!
Mark Obrembalski schrieb: Wenn außer mir noch mehr Interesse an so einer Funktion haben, könnte ich ein Sktipt schreiben, das die Liste in Webformulare umwandelt, über die man jeden Eintrag als erledigt (ggf. auch anders, etwa benötigt ortskundigen Bearbeiter) markieren kann. Ja - sobald die Liste auch die jeweiligen Ortsnamen oder zumindest Orte in der Nähe umfasst. BTW: Wie mappt man sowas? http://failblog.files.wordpress.com/2008/08/fail-owned-sign-fail1.jpg ;-) CU Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bayern: Radwege (ncn/rcn) Via Julia, Via Bavarica Tyrolensis und M-Wasserweg
Hallo zusammen! Ich werde mal ein Schreiben aufsetzen, dass man dann an das Via Julia Team (bzw. mit leichten Änderungen vermutlich auch an die anderen) schicken könnte. So, Mail ist raus. Mal sehen was draus wird!? (Toni, hab Dich auf Bcc: gesetzt, falls Du ähnliches für die anderen Touren verwenden möchtest.) Sobald ich Feedback habe (erst recht, wenn es positiv ausfallen sollte, was ich natürlich hoffe), werde ich das Anschreiben (als Vorlage) und die Antwort irgendwo ins OSM Wiki packen. Gruss von -Leupi- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Regionale OSM Mailingliste für Bayern
Sven Anders schrieb: Am Freitag, 22. August 2008 11:54 schrieb Guenther Meyer: es gibt uebrigens wohl schon eine niederbayern-liste, vielleicht kann man di auf bayern ausweiten... Ich hatte das beim Anlegen der Liste mit dem Mailinglistenverwalter für Niederbayern diskutiert. Dieser schrieb mir damals, das er lieber einen nicht so großen Bereich haben möchte, damit weniger Traffic auf der Liste ist und sich die Leute trauen darauf zu schreiben. Falls es zu viel Traffic wird, kann man die Liste ja wieder teilen. Ansonsten eben nen München Liste... MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS: Von Italien nach Dänemark .. .
Am 25. August 2008 22:06 schrieb Jens Müller [EMAIL PROTECTED]: Bernd Wurst schrieb: Hallo. Am Montag, 25. August 2008 schrieb Thomas Hieber: wie siehts dann mit highway=steps aus? Wer ein richtiger Fahrradfahrer ist, den stört das auch nicht. Die Debatte ist doch müßig, ein Radfahrer der sich per Routenplaner die Tour planen lässt, ist nicht einer, der die Verkehrsregeln als gut gemeinten Hinweis versteht. Wenn ich ne gemütliche Fahrt machen will, dann sehe ich keinen Grund darin, dass ich jetzt unbedingt gegen Einbahnstraßen oder auf mehrspurigen Landstraßen ohne Radweg fahren muss, nur weil ich es könnte. Öhm - daß der mehrspurige Landstraßen ohne Radweg ausschließt, will ich nun eigentlich nicht. Meist sind die eh nicht die kürzeste Strecke, aber wenn, dann sind andere Straßen meist ein großer Umweg. Und ein bicycle=no steht eh schon dran, lange bevor es ungemütlich wird. wie dem auch sei, wer routing für Fahrräder nutzt, will nicht nur gemütliche Spazierstrecken, sondern sich u.U. auch einfach auf dem kürzesten, schnellsten Weg mit brauchbarem Belag routen lassen. Fussgängerrouting verbietet sich wegen der Treppen natürlich von selbst. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
