Re: [OSM-talk] Crossroad names
On 25.03.2013 22:24, Vladimir Vyskocil wrote: And there are more than 7000 nodes with highway=traffic_signals and name=* in Tokyo and its suburbs ! Another country, another solution for the same tagging problem. And how is this unexpected? Without renderer support every community will develop its own solution. The only reason we don't see this all the time is that most of this is handled by the worldwide English speaking community. cu Henry ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Wie mappe ich zeitliche Beschränkungen (z.B. Nachtfahrverbot)
On 06.02.2013 11:29, Martin Vonwald wrote: Am 6. Februar 2013 11:19 schrieb Gmbo g...@kilometerfresser.eu: Nehme ich also eine Straße mit der Beschränkung für Motorräder in der Zeit von 22 Uhr bis 6 Uhr. Für diese Beispiel sollte folgendes reichen: motorcycle:conditional = no @ (22:00-06:00) Und BTW Gmbo, lass das mit der +/- 1 Minute. Zeitpunkte haben keine Länge, d.h. (22:00-06:00) und (06:00-22:00) hat weder Lücken noch Überlappungen. Aber bei (22:01-06:00) und (06:01-22:00) gibt es zwei Lücken von jeweils 1 Minute Länge... cu Henry PS: Zumindest wenn der Programmierer, der das dann auswertet, seine Arbeit richtig gemacht hat. ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
On 19.07.2012 09:08, Jörg Frings-Fürst wrote: wenn ich mir hier bei mir z.B. Wittlich anschaue, dann bekomme ich ehrlich gesagt die Krise. Bei mir ist es nicht ganz so schlimm. Immerhin stammen 90% der Objekte hier von mir. Was mich aber richtig nervt ist, dass viele Objekte, die ich ursprünglich erstellt habe, jetzt total kaputte Punktewolken sind. Warum schafft der Bot es nicht, sie auf den letzten lizenzverträglichen Stand zurückzusetzen? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: alte Tastenbelegungen wiederherstellen
On 18.11.2011 15:10, Martin Koppenhoefer wrote: ja, würde auch auf Plugin tippen, ist mir auch schon ein paarmal vorgekommen. Bis das geändert ist (ideal wäre m.E. wenn beim Starten erst die Core-Shortcuts registriert würden, und diese dann durch Plugins nicht mehr geändert würden oder nur nach Nutzerbestätigung) Das Problem hier ist, dass alle Shortcuts erst on-demand registriert werden und nicht schon bei Programmstart. on-demand ist, wenn sie das erste Mal aktiv werden und benutzt werden können, bei Menu-Shortcuts z.B. wenn das Menü aufgebaut wird. Auf diese Weise gibt es leider einige Core-Shortcuts, die je nach Programmnutzung erst nach Stunden und Monaten der Benutzung, oder gar nie, registriert werden. Sobald ein Shortcut mal registriert ist, darf er sich nicht mehr von selbst (=ohne Benutzer-Aktion) ändern. (Ausser jemand hat das geändert seit ich es vor Jahren gecoded habe...) cu Henry PS: Die betriebssystemreservierten bzw. -typischen Tastenkürzel wie F1, CMD-?, Alt-F4, CMD-,, Strg-Alt-Entf, Alt-Tab, ... werden beim Programmstart reserviert. Das könnte man auch auf Core ausweiten, ABER dann müssen die Core-Shortcuts auch an beiden Stellen gepflegt werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern auf Gebäudeumriss ?!
On 18.11.2011 16:10, Kay Drangmeister wrote: Der Router für Autos gibt auf und sagt glücklicherweise schon auf der nächstgelegenen Straße Das Ziel liegt links. Oder routet zur Tiefgarageneinfahrt (bei Hotels), Besucherparkplatzeinfahrt (bei größeren Wohnhäusern, Geschäften und Bürohäusern) oder Vorfahrt (Hotels, Büros). Heutzutage nehm ich Streetview zur Hand bevor ich mich irgendwo hinrouten lasse, wo ich noch nicht war... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Hi, eine sehr ausführliche Diskussion zum Thema TMC löschen findet sich um den 2.2. diesen Jahres im Archiv. Und dann noch meine Meinung zum Thema zu komplex: Wenn ich Elemente merge, die widersprechende Tags haben, kommt immer Müll raus, egal ob das TMC-Tags sind oder was anderes. highway=service;motorway? cu Henry On 07.10.2011 09:36, Tobias Knerr wrote: Danke für die Erklärung der kryptischen Schlüssel. Das begründet allerdings noch nicht, warum man mehr als 1 Tag braucht, denn das sollte sich ja alles in Schlüssel und Wert mit unterbringen lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OT: Elektroantriebe sauber? WAS: Projekt DE des Monats - Tankstellen
On 10.09.2010 07:51, Bernd Wurst wrote: Am Freitag 10 September 2010, 07:47:27 schrieb Guenther Meyer: amenity=fuel fuel:electric=only richtig. Ach nee, das ist ja eine Einladung mit Handkuss für Inkonsistenzen! Jepp. warum nicht einfach: car_charging=yes (oder public/subscriber/private?) car_charging:systems=VDE;schuko car_charging:count=1;3 payment=... Das lässt sich sowohl an eine Tankstelle als auch an ein Parkhaus oder eine Straßenlaterne dazu-taggen. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
Hi, (ich häng mich mal an diese Mail, damit wenigstens etwas Bezug da ist) Diese ganze was ist eine Tankstelle-Diskussion hat irgendwie zu nichts geführt. Wie wäre es mit dieser Definition: (1) Eine Tankstelle ist eine Einrichtung, die mehrere Zapfsäulen sowie mindestens eine öffentliche Bezahlmöglichkeit vorhält. (2) Eine Zapfsäule ist ein stationäres Gerät, das dazu dient, den Energiebedarf eines Fahrzeuges zu decken. (3) Eine einzelne Zapfsäule ist keine Tankstelle, auch wenn sie über ein integriertes Bezahlverfahren verfügt. Damit könne wir dan herkömmliche Tankstellen, Elektrosapfäulen an Parkplätzen und sogar nichtöffentliche Betriebstankstellen mappen, wir brauchen nur ein neues Tag für Zapfzäulen. Sonderfälle ist das eine Elektrotankstelle mit Parkhaus oder ein Parkaus mit 3 Elektrozapfsäulen auf Parkdeck 5? löst man eben nach Primärfunktion geht vor auf. cu Henry On 06.09.2010 21:49, Jacques Nietsch wrote: ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt DE des Monats - Tankstellen
On 07.09.2010 12:48, M∡rtin Koppenhoefer wrote: (2) Eine Zapfsäule ist ein stationäres Gerät, das dazu dient, den Energiebedarf eines Fahrzeuges zu decken. Wozu braucht man das? Wikipedia finde ich da besser: Eine Zapfsäule(oder auch Tanksäule) ist ein Teil einer Tankstelle, Um (a) Eletropzapfsäulen auch zu erfassen und (b) Zapfsäulen von Tankstellen unabhängig zu machen. (3) Eine einzelne Zapfsäule ist keine Tankstelle, auch wenn sie über ein integriertes Bezahlverfahren verfügt. warum nicht? Es gibt solche Tankstellen mit nur einer Zapfsäule. Dann haben wir wieder an jeder Steckdose eine Tankstelle. Meine Definition war gerade dazu da, solche Einzelzapfsäulen von Tankstelle (mehrere Zapfsäulen, Kassenhäuschen, Minishop, PKW-Zubehör...) zu trennen. Beim Gedanken, ein Parkaus als Tankstelle zu taggen, nur weil es dort auch Eletrosapfstellen gibt, schüttelt es mich... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [OT] Re: Zukunft?
On 24.08.2010 17:56, Jörk wrote: lebt der Florian nur bei mir in der Zukunft, oder was ist da los? Drum prüfe, wer an Mailing Listen sendet, ob die Systemuhr den auch richtig ständet. Jepp, er sendet aus der Zukunft ;) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
On 23.08.2010 20:02, Frederik Ramm wrote: [...] In anderen Faellen werden wir ihre Aenderungen isoliert rueckgaengig machen koennen (z.B. einfach ein Tag an einem Way wieder entfernen). [...] Meine Güte, warum denn so einen Aufwand treiben? Wur suchen uns einfach jemanden in einem Land, in dem die CC-BY-SA für die OSM-Daten nicht greift, lassen den die Daten runterladen und under der Odl frisch einstellen. . . . Moralisch verwerfbar, aber völlig legal. Und deshalb brauchen wir den Lizenzwechsel und die Klausel 3 um auf Dauer auf Lizenzschwächen reagieren zu können. /mfg/ Henry Loénwind PS: Vorsorglich: Nein, ich befürworte so ein Vorgehen nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Software goes on, brain goes off...
On 02.06.2010 14:19, John Smith wrote: You could extend it a little and explain more specifically: unsafe:foot=narrow/fast_traffic/muggers/etc routing:hints:foot:avoid=yes routing:hints:foot:comment=fast traffic routing:hints:motorcar:avoid=yes routing:hints:motorcar:comment=street layout hard to follow for non-locals routing:hints:motorcar:prefer=yes routing:hints:motorcar:comment=faster traffic than the parallel primary routing:hints:bike:delay:1=40s routing:hints:bike:delay:1:times=mo-sa:0700-1300,mo-fr:1700-1900 routing:hints:bike:delay:2=20s routing:hints:bike:delay:2:times=su:1400-22:00 routing:hints:bike:comment=foot traffic avoidance costs time Just the seed of an idea... Henry ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] mapgen und Geo::Proj4
Einfach mal Doku lesen...: == INSTALL = Libray from scratch Geo::Proj4 uses XS to wrap the PROJ.4 cartographic projections library. You will need to have at least version 4.4.9 of the PROJ.4 library installed in order to build and use this module. You can get source code and binaries for the PROJ.4 library from its home page at http://www.remotesensing.org/proj/. On 31.05.2010 09:50, hike39 wrote: Hallo, ich suche jemanden, der sich mit CPAN auskennt. Ich wollte gestern mit mapgen 1.04 eine neue Karte rendern lassen. Dazu wird aber das Modul Geo::Proj4 benötigt. Daher erhalte ich die Meldung: ... Can't locate loadable object for module Geo::Proj4 in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at OSM/mapgen.pm line 41 Compilation failed in require at OSM/mapgen.pm line 41. BEGIN failed--compilation aborted at OSM/mapgen.pm line 41. Compilation failed in require at mapgen.pl line 91. BEGIN failed--compilation aborted at mapgen.pl line 91. ... Der Versuch dieses Modul mittels cpan-Kdo zu installieren geht auch mit folgender Meldung schief: ... CPAN: File::Temp loaded ok (v0.22) CPAN.pm: Going to build M/MA/MARKOV/Geo-Proj4-1.01.tar.gz ERROR: proj library too old or not found: require 4.4.9 Warning: No success on command[/usr/bin/perl Makefile.PL INSTALLDIRS=site] Warning (usually harmless): 'YAML' not installed, will not store persistent state MARKOV/Geo-Proj4-1.01.tar.gz /usr/bin/perl Makefile.PL INSTALLDIRS=site -- NOT OK Running make test Make had some problems, won't test Running make install Make had some problems, won't install Could not read '/home/horst/.cpan/build/Geo-Proj4-1.01-GT36NT/META.yml'. Falling back to other methods to determine prerequisites Failed during this command: MARKOV/Geo-Proj4-1.01.tar.gz : writemakefile NO '/usr/bin/perl Makefile.PL INSTALLDIRS=site' returned status 512 ... Kann mir jemand einen Tipp geben, welche Proj Library fehlt oder zu alt ist und wie ich dieses richtig stellen kann? hike39 ___ 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] frage zu josm - funktionstasten
On 23.04.2010 11:25, Georg Feddern wrote: hmm, das kann ich bei meiner Standard-3094 nicht nachvollziehen (Antwort an den Thread) Das ist alles works as designed. JOSM weist Tasten derjenigen Funktion zu, die zuerst danach fragt. Unter der Maßgabe, dass Tastenbelegungen sich niemals von selbst ändern dürfen (User: Gestern war Ctrl-S doch noch Speichern, warum ist es heute AlleS Löschen?), bleiben sie dann dort. Das heißt dann aber auch, dass verschiedene JOSM-Installationen verschiedene Belegungen haben, da verschiedene Leute die Funktionen in einer anderen Reihenfolge abbekommen haben. (Gerade bei den Tasten, die an Plugins gehen und denen, die von selten benutzten Dialogen angefordert werden, fällt das auf.) Die Belegung, die im Wiki steht, gilt für ein frisch installiertes JOSM aktuellen Versionsstands ohne Plugins. (Und falls es hier Unstimmigkeiten gibt: Man kann durchaus in den platformspezifischen Files Vorreservierungen hinterlegen, so wie das z.B. für OSX der Fall ist -- dort werden Kommandos, für die Apple in den OSX-Styleguides Tastaturkommandos vorgibt, passend vordefiniert.) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fundsache: Butzbachs Straßen werden umbenannt
Hello Openstreetmap, http://www.hr-online.de/website/rubriken/nachrichten/indexhessen34938.jsp?rubrik=36090tl=tskey=standard_document_38112086 http://www.stadt-butzbach.de/fileadmin/Stadt_pdf/Unterkunft/Strassennamen_final.pdf Fundsache, nicht meine Gegend, und ich habe keine Ahnung ob sich schon jemand drum kümmert... -- Best regards, Henry mailto:he...@loenwind.info ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fundsache: Butzbachs Straßen werden um benannt
Hello geo.osm, Monday, October 5, 2009, 3:37:27 PM, you wrote: Nicht vergessen, die alten Namen beim Umbennen in old_name speichern. sollte man das tun? Ja sicher doch, diese Information ist überaus interessant. Vor allem wenn man Adressen von vor der Umbenennung hat... Ich frage mich nur grade, wie man die alten Hausnummern aufheben kann ;) -- Best regards, Henrymailto:he...@loenwind.info ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem eine Strasse zu teilen.
Frank Jäger wrote: - Node markieren - Taste G oder - Werkzeuge / Wege trennen Beide End-Nodes liegen dann noch deckungsgleich übereinander. Oder einen Way und den Node markieren, dann ist nach dem Trennen der Node markiert, der zum vorher markierten Way gehört und kann direkt verschoben werden. Mit JOSM-latest kann man jetzt auch einen Way und viele Nodes dieses Ways markieren und vom Rest abtrennen. Oder nur den Way, wenn man ihn komplett ablösen möchte. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse übereinander.
Garry wrote: Es ist sicher nicht der richtige Wege zu viele Voraussetzungen an eine Anwendung zu stellen. Ok, dann gib doch mal bitte vor, was Dein Renderer kann und wir passen ganz OSM an Deiner Vorstellungen an. Ich finde es ja schön, dass Du eine eigene Meinung hast, aber leider läuft die in vielen Fällen konträr zum bisherigen Konsens. Versuch doch mal, Deine Änderungsvorschläge zu sammeln und am Stück diskutieren zu lassen, anstatt bei jedem zweiten Thema, das hier auf der Liste abgehandelt wird, ein kleines Stückchen einzuwerfen. Vielleicht sogar gleich auf talk statt talk-de, denn z.B. die Idee multipolygon wieder abzuschaffen, und so wie vor dessen Einführung zu taggen, betrifft nicht nur den deutschsprachigen Raum. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] fixbot-Probleme, bzw. unverbundene S
Tobias Wendorff wrote: Henry Loenwind schrieb: Vergiss nicht Wendehämmer zu ignorieren. Ein Node mit Wendehammer ist kein Kandidat um irgendwo angeschlossen zu werden. (Ich hab hier ein paar solcher Hämmer, bei denen grade mal 50cm zwischen Hammer und der nächsten Straße sind. Die 50 cm sind dann aber auch 2,5m hoch und aus Beton...g) Kenne ich ... wir haben hier auch sowas, was mal offen aussah und dann mit Beton-Kübeln und anderem Zeugs verschlossen wurde :-) Bei mir ist es ein Neubaugebiet, das direkt bis an die Umgehungsstraße rangebaut wurde. die Wendehämmer dort sind direkt vor der Lärmschutzwand. Naja, das ganze Gebiet ist unheimlich eng geworden, lauter 10x4m Grundstücke mit 4,5m Straßen dazwischen... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging Schild 250 -Verbot für Fahrze uge aller Art
Ingo Driever wrote: In diesem Zusammenhang stehlt sich die Frage ob es nicht sowieso besser wäre statt Regeln, lieber Schilder zu taggen. Wenn der Bundestag Morgen Ich habe schon länger überlegt, ob ich nicht ein Tag legal_status vorschlagen soll für sowas. Ich stelle mir das so vor, dass legal_status ein reines Zusatztag wäre, in eine Liste von definierten Werten steht. Beispiele: highway=tertiarry legal_status=de:Kreisstrasse; de:innerorts highway=motorway legal_status=at:Autobahn highway=motorway legal_status=de:Autobahn de:LkwMautFrei highway=trunk legal_status=de:3-3-2c-STVO highway=trunk motorway=yes legal_status=de:3-3-2c-STVO; de:Zeichen331; de:Zeichen295 (d.h. LWK dürfen 60 fahren) highway=trunk motorway=yes legal_status=de:3-3-2c-STVO; de:Zeichen331; de:18-STVO (d.h. LKW dürfen 80 fahren) parking legal_staus=ch:zh:blauezone cu Henry PS: Zusatztag, also die normalen Tags auf jeden Fall auch setzen. Ggf. können die Editoren da helfen, indem sie das automatisch machen. PPS: Und mit definiert meine ich gesetzlich definierte Werte, also nix, über das man sich streiten kann. Tags über deren Interpretation man sich streiten kann haben wir so schon genug g ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] fixbot-Probleme, bzw. unverbundene S
GS wrote: Nicht alle nichtverbundenen Straßen dieser Art sind wirklich verbunden. Es Vergiss nicht Wendehämmer zu ignorieren. Ein Node mit Wendehammer ist kein Kandidat um irgendwo angeschlossen zu werden. (Ich hab hier ein paar solcher Hämmer, bei denen grade mal 50cm zwischen Hammer und der nächsten Straße sind. Die 50 cm sind dann aber auch 2,5m hoch und aus Beton...g) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] denomination-tag
Frank Sautter wrote: * das tag denomination:de einführen und einen guten satz von wertevorgaben definieren Warum :de unbedingt an das Tag hängen? Wie wäre es mal zur Abwechslung de: an den Value zu hängen? Also denomination=de:evangelisch (oder legal_status=de:Autobahn vs. legal_status=at:Autobahn g)... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßen im Industriegebiet?
Marco Krage wrote: Der Ausbau dieser Straßen passt gar nicht zu dem Foto von highway=unclassified. Unclassified sind alle Straßen, die Teil des öffentlichen Straßennetzes sind, die nicht von anderen highway-Typen erschlagen werden. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Validator: nicht geschlossene Fl äche
Jan Peter Stotz wrote: Klasse wär's, wenn der Validator nicht den ganzen Wald sondern nur die Lücke rot makieren täte. ;-) Hört sich nach einem sinnvollen Vorschlag an. Ich habe den entsprechenden Kannst Du dem Fix-Button nicht einfach beibringen, den Weg zu schließen? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Validatonicht geschlossene Fläche
Dirk Stöcker wrote: Kannst Du dem Fix-Button nicht einfach beibringen, den Weg zu schließen? Lieber nicht. Wenn dann jemand auch all die Flächen schließt, welche eigentlich nicht geschlossen sein sollten ... Welche Flächen, für die der Validator warnt, sollen denn offen bleiben können? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Trackrichtung invertiert?
Martin Koppenhoefer wrote: Ich habe seit neuerem (meine Version R. 1010) den Eindruck, dass die Richtungsangaben von gpx-Tracks umgedreht sind. Könnt ihr das bei Euch bestätigen? http://josm.openstreetmap.de/ticket/1555 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRouteService
Hatto von Hatzfeld wrote: Wäre folgende Zusammenfassung okay? Ja, nur noch eine Ergänzung: Beim letztenmal waren wir uns so ziemlich einig, dass wir Straßen als trunk taggen, die von §3 (3) 2c STVO erfasst werden und kreuzungsfrei sind, sowie Straßen, die davon erfasst werden würden, wenn sie ausserorts wären. §3 (3) 2c STVO: [...] Straßen mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt sind. [... und] Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben. Quelle: http://bundesrecht.juris.de/stvo/__3.html cu Henry PS: Und motorroad entspricht 1:1 dem Zeichen 331 (Kraftfahrstraße) und ist damit komplett unabhängig von trunk. PPS: Um auch die maximal erlaubte Geschwindigkeit für LKW abzubilden reichen diese Informationen allerdings NICHT aus. Hierfür müssten wir noch unterscheiden zwischen außerhalb geschlossener Ortschaften auf Kraftfahrstraßen (Zeichen 331) mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt sind (§18 STVO) und anderen trunks und motorroads. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [josm-dev] Konstruktion von Kreiseln in JOSM
Frederik Ramm wrote: I have applied your patch. I was unsure about the shortcut key you had selected (came out funny on my machine) so made it Ctrl-O (with O being the shortcut for the existing align in circle action). Oops, I intended to revisit the shortcut after I got it working, but forgot. The MACRON was just a placeholder, because the meaning of the parameters was not obvious to me (who expects system constants to be ints and not objects?). The method you have chosen is technically incorrect because you use planar geometry operations on Eastings and Northings. This means that As I noted in code and ticket text. with other projections, things might go awry. But it's a good start and if someone wants to do it right then the code is theirs... Maybe we need a third set of coordinates on the nodes, something that can be used as a flat plane for all constructing actions. Or provides the common match to draw lines and circles etc. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Badestelle am See
René Falk wrote: landuse= basin gibt es schon. Das ist eher ein Rückhaltebecken als ein Schwimmbecken. An area of water that drains into a river. Andreas Labres wrote: Ich würde sie auch nicht einzeichnen wollen. Aber bei swimming_pool denke ich zuerst an den im Garten und eigentlich nicht an ein Freibad (das ist ein Becken Ähm, es gibt da einen winzigkleinen Unterschied zwischen Swimming Pool und swimming pool. Ok, nicht ganz so groß wie zwischen Handy und handy, aber trotzdem... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konstruktion von Kreiseln in JOSM
Tobias Wendorff wrote: Nein, sehe ich ähnlich. Kollege hat solches auch schon entwickelt(CAD-Tools), will aber 50 EUR dafür haben. 10 EUR haben wir schonzusammen. Ich bin blank für diese Investitionen, da ich auch nochandere Ausgaben für OSM habe. Lass das Geld mal stecken, andere machen sowas für umme. Jetzt muss nur noch jemand den Patch an Ticket #1580 in JSM übernehmen... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bild von Trafohaus für Mapfeatures ge sucht
John07 wrote: Hat jemand ein schönere parat? Etwas in der Richtung vllt. naja, meins ist nicht ganz so schön, aber wenigstens zeigt es eine substation g cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fwd: Returned mail: see transcript for details, Re: Konstruktion von Kreiseln in JOSM
Frag doch mal Deinen Mail-Admin, warum er mich nicht mag. (Mails an [EMAIL PROTECTED] werden auch abgewiesen, sonst würde ich nicht über die Liste gehen.) Original Message Subject: Returned mail: see transcript for details Date: Fri, 19 Sep 2008 13:26:40 +0200 From: Mail Delivery Subsystem MAILER-DAEMON To: [EMAIL PROTECTED] The original message was received at Fri, 19 Sep 2008 13:26:19 +0200 from [EMAIL PROTECTED] [85.216.118.31] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 551-Sender rejected due to local mail policy.) - Transcript of session follows - ... while talking to ip2i.hrz.uni-dortmund.de.: RCPT To:[EMAIL PROTECTED] 551-Sender rejected due to local mail policy. 551 Contact your mail admin for assistance. 550 5.1.1 [EMAIL PROTECTED]... User unknown Reporting-MTA: dns; j-e-b.net Arrival-Date: Fri, 19 Sep 2008 13:26:19 +0200 Final-Recipient: RFC822; tobias.wendorff@uni-dortmund.de Action: failed Status: 5.1.6 Remote-MTA: DNS; ip2i.hrz.uni-dortmund.de Diagnostic-Code: SMTP; 551-Sender rejected due to local mail policy. Last-Attempt-Date: Fri, 19 Sep 2008 13:26:40 +0200 ---BeginMessage--- Tobias Wendorff wrote: Nein, sehe ich ähnlich. Kollege hat solches auch schon entwickelt(CAD-Tools), will aber 50 EUR dafür haben. 10 EUR haben wir schonzusammen. Ich bin blank für diese Investitionen, da ich auch nochandere Ausgaben für OSM habe. Lass das Geld mal stecken, andere machen sowas für umme. Jetzt muss nur noch jemand den Patch an Ticket #1580 in JSM übernehmen... cu Henry ---End Message--- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bild von Trafohaus für Mapfeatures ge sucht
John07 wrote: Jo, besser als das Alte. Falls du die Originaldatei in höherer Auflösung hast, könntest du noch ein bisschen die Ränder wegschneiden, damit es Nee, Originalauflösung war 640x480, ich habs nur beschnitten. Ist eins von den Bildern, die ich beim Tracken mache, da reicht mir die Auflösung völlig. Und die sub_station war noch dazu nur zufällig im Hintergrund ;) Zum Thema Häuschen oder Kasten: sub_station lieber für die Häuschen, gibt ja noch genug. Wer unbedingt noch Teile mit unter 1m² mappen möchte, wie wäre es mit power=patch_box? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vandale sucht Unterstützung (war: Re: construction=yes bitte nicht durch h ighway=construction ersetzen!!!)
Garry wrote: Aus aktuellem Anlass möchte ich eindringlich darum bitten die mit construction=yes nicht durch highway=construction etc. zu ersetzen!!! Moment mal. highway=construction ist im Wiki auf Map_Features, construction=yes nicht. Und für Map_Features haben wir einen Proposal- und Abstimmungs-Prozess, also benutze den bitte. Einfach machen ist ja völlig ok für neue Tags, die sich dann irgendwann durchsetzen. Es ist nicht ok wenn man etablierte Tags ändern will. Rate mal, was passieren würde, wenn ich hergehen würde und alle highway=motorway in Deutschland auf highway=yes + highway:type=de:autobahn umtaggen würde. Richtig, die Leute würden es Vandalismus nennen und reverten. Wenn ich damit nicht aufhören würde, würde irgendwann ein Admin meinen Account sperren. Was Du da gerade machst, ist genau die gleiche Art von Vandalismus. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] API v7
Hi, first, the following are some half-baked ideas I just want to get out of my head because I need the space they are taking up ;) Over the last weeks I have seen many discussions about how to tag some stuff. Sometimes the solution was easy, but many times there just was no solution at all. And more often than not, someone would pull some giganto relation out of the hat, that would mean that we would have more relations than ways at the end. I wanted to add to those discussions, but I also often did not find a good solution. Then it struck me. We are clinging to our current data model really hard. Too hard. Maybe we need to start exploring how to extend it to make mapping easier, instead of trying to put everything ways and nodes cannot do into relations? (I said start exploring, emphasis on that!) Reoccurring problem 1: Way splitting. At the moment we need split ways at every point there is some change to them. While this is much better than segments were, recombining them with relations just demotes ways to segments and makes relations our new ways. Nothing gained. Going the opposite way, by not splitting the ways and giving parts of them different properties with relations is not much better---there is no support for including parts of a way in a relation, so the relations will contain one way and (hopefully) two nodes an some obscure meaning how to cut the way. (Note: obscure meaning not in the data model.) Reoccurring problem 2: Two side of a coin, oops, a way. Most ways have two sides, often they are the same, but also often they are not. Different maximum speeds, or different access rules, sometimes even different highway types (highway=residential, oneway=yes on one side, highway=cycleway the other). No clean way to model this, too. There are some tags for common cases, like cycleway=opposite, but that's all. So far for the problems. Please discuss my view on the problems (above) independently from my ideas on solving them (below). Mixing discussions on problem and solution usually lead to nothing. At the moment a way can only be tagged as a whole. There is no way to say that a tag only applies to the left side of the street, or to the second half. There are some proposals for the former, like right:maxspeed=30 or maxspeed.left.hgv.atnight=25. One of them may be the correct way to go, but my idea includes another solution for free. With API.5, a way looks like this: way id=35 ... nd ref=1/ nd ref=22/ nd ref=333/ nd ref=/ tag k=highway v=secondary/ /way Let's see how it changes with some additions: way id=35 ... nd ref=1/ nd ref=22 p=P1/ nd ref=333 p=P2/ nd ref=/ ... Not much yet, I only added a free-text field to th nd-element, p for position. It would be optional and only constrained that it must be unique within the way. Now add 2 more attributes to the tag-element: ... tag k=highway v=secondary/ tag k=bridge v=yes from=P1 to=P2/ /way Whow, we just added a bridge without cutting the way into 3 parts. Neat, but not quite where I'm headed. One more: ... tag k=bridge v=yes from=P1 to=P2 side=both/ tag k=maxspeed v=30 from=P1 to=P2 side=left/ tag k=maxspeed v=50 from=P2 to=P1 side=right/ /way Now, there is one little bit of information hidden here. Try to find out: Is this street in the UK or on mainland Europe? Ok, there's no way to find out, as there are more countries driving on the left side than just the UK. But this street would be in one of them. Why? Easy, the tags now have a direction (from, to), together with the side (that is relative to the way's direction), we can say that e.g. the maxspeed=30 part is on the left side of the way going in the direction of the way. (Some notes: (1) both would be the default for side when no value was given. (2) side/from/to may of course be abrv., e.g. to s/f/t. Maybe even both/left/right (b/l/r?)) So, this would allow us to (a) tag parts of a way diffeently, (b) tag the two directions of a way differently, and (c) tag the two sides of a way differently. (Yes, there is a difference between b and c, and it is important.) But there is still more: (d) we can now also tag nodes on a way with a direction: ... tag k=highway v=bus_stop from=P1 to=P1 side=left/ tag k=highway v=bus_stop from=P2 to=P2 side=right/ ... However, to fully use this feature, we would have to abandon the generic name tag. Or else there would be just no way to know what the name is for---the way or something tagged to a part of the way? However, there should not be that many features that can be tagged additionally onto a way in a useful and meaningful manner. Things that have their own way or node at the moment should keep it. Only some node features, like bus stops or traffic lights or gates, are really part of the way they belong to and would better be expressed that way instead of as extra nodes. Others, like lamp posts or subway entrances,---even though
Re: [OSM-talk] last person to edit?
graham wrote: and correcting them this evening, but nothing in between. Is there any kind of edit it doesn't show? Maybe someone moved the nodes? That wouldn't show up in the way's history... cu Henry ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Unterschied: residential, unclassified, service
Tobias Hägele wrote: Nun aber nochmal zu highway=unclassified: Mich stört die Definition D: breit genug, dass zwei Fahrzeuge problemlos aneinander vorbei kommen Vielleicht ganz einfach Eine sonstige Straße des öffentlichen Straßennetzes.? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namefinder geht immer noch nicht
Christoph Eckert wrote: Der Verantwortliche bist Du selbst. Lösen kannst Du das Problem, indem Du Dich hinsetzt, den JOSM-Quellcode entsprechend modifizierst und einen Patch via josm-dev einreichst. Das Danke schonmal im Voraus verkneife ich mir wohl jetzt besser. Also mich nerven solche Arschlöcher, die bei einem Problem gleich wie die wilden Affen am Code rumschrauben, und irgendwelche wirren Patches einschicken, die dazu führen, dass die Software dann nur noch bei ihnen läuft, anstatt einfach dem Original-Programmierer oder Maintainer Bescheid zu geben. cu Henry PS: Ja, das musste mal so deutlich gesagt werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur Diskussion zum BGH, I ZR 81/96
Andreas Jacob wrote: Das ist inzwischen nicht mehr richtig. Genau diese Sammlung von Daten Woraus beziehst du deine Kenntnis, dass Kartografische Werke als Datenbankwerk geschützt sind? (ja, mir sind § 4 und §§ 87a ff UrhG bekannt) Nach einem Urteil des Landgerichts München I (Urteil vom 9. November 2005, Az. 21 O 7402/02, Datenbankschutz für topografische Landkarten – Topografische Kartenblätter, GRUR 2006, S. 225 ) stellt die topografische Karte 1:25 000 (TK25) eine analoge Datenbank nach § 87a Urheberrechtsgesetz dar und genießt damit rechtlichen Schutz aufgrund der vorgenommenen Investition bei ihrer Herstellung. Eine Entnahme von Daten aus der TK25 durch Digitalisierung zum Zwecke der Weiterbearbeitung sei deshalb lizenzpflichtig. Dieses Urteil ist rechtskräftig. Quelle: http://de.wikipedia.org/wiki/Rechte_an_Geoinformationen Und für Dich korrigiere ich mich auch gerne: Es gibt dazu mindestens ein Urteil. cu henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur Diskussion zum BGH, I ZR 81/96
Tobias Wendorff wrote: Du scheinst Du da näher auszukennen. Kannst Du mir die Nein, ich kann einfach nur mit Google umgehen... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Freie Handy-Java Geotagging(Bilder) Software gesucht
[EMAIL PROTECTED] wrote: Nutzen möchte ich dies z.B. für das Geotagging mit Bilder, damit ich jene in JOSM importieren kann. Für den Zweck reicht es wenn die Kamera Datum und Uhrzeit in der Bilddatei verewigt. Die Zuordnung zu einem gleichzeitig aufgezeichneten GPS-Track kann JOSM schon selbst herstellen... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterschied: residential, unclassified, service
[EMAIL PROTECTED] wrote: Wenn der Bauer nicht mehr mit dem Trecker bzw. der Förster nicht mehr mit seinem Golf Country durchpasst ist es imho ein 'path' und kein 'Wirtschaftsweg' mehr :) Naja, durchkommen ist bei unserem Wald so eine Sache. Solange es flach ist, könnte ich hier mit meinem Sportwagen quer durch den Wald fahren. d.h. Baumabstand ist bei durchschnittlich 2,5m, Bodenbewuchs nur dort, wo Sonne einfällt... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterschied: residential, unclassified, service
Lars Francke wrote: Ueber ein paar Hinweise, Stichwörter oder ähnliches wäre ich dankbar damit ich hier mal zum zuständigen Amt stiefeln kann und dann auch Kleiner Ti noch: Wenn Du keine mit unserer Lizenz vereinbarbare Quelle findest, kanst Du Einzelabfragen machen, d.h. Dir von wem-auch-immer den Namen einer einzelnen Straße sagen lassen. Da ein einzelner Datensatz keine Datenbank sein kann, ist er auch nicht vom Datenbankrecht geschützt. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zur Diskussion zum BGH, I ZR 81/96
Tobias Wendorff wrote: ich denke mal, dass über das Urteil BGH, I ZR 81/96 schon häufig diskutiert wurde: http://www.jurpc.de/rechtspr/19990054.htm Nein, wurde es nicht, denn: Für mich persönlich ist der Fall klar: Die Kartographie, das Layout und die Darstellung einer gedruckten Karte ist urheberrechtlich geschützt - die Informationen und der dargestellte Inhalt jedoch nicht! Das ist inzwischen nicht mehr richtig. Genau diese Sammlung von Daten ist inzwischen als Datenbankwerk eigenständig geschützt. (Und zwar auch, bzw. gerade dann, wenn jede einzelne Information an sich keinen Schutz genießt.) Also Pustekuchen. cu Henry PS: Zu Karte==Datenbankwerk gibt es entsprechende Urteile. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterschied: residential, unclassified, service
Florian Lohoff wrote: On Mon, Aug 11, 2008 at 09:59:08PM +0200, Henry Loenwind wrote: Das ist eigentlich ganz einfach... scnr Das einzige problem was hier nicht reinpasst ist highway=track, tracktype=grade1 - was ja auch asphaltiert ist also in meiner definition = unclassified ist. Jedoch waere fuer mich die unterscheidung das ein track typischerweise keinen namen hat d.h. eher inoffiziellen/privaten character hat, meist auch verbunden mit belagwechseln von schotter zu asphalt und zurueck - bisher habe ich das aber nicht verwendet. Naja, ich gehe hier danach, ob es eine Straße oder ein Feld-/Waldweg ist. Und bis jetzt ist mir persönlich nichts untergekommen, das ich nicht nach diesem Schema einordnen hätte können. So gibt es hier den Sonnenweg, asphaltiert und breit genug für 2 PKW (grade=rollberlades). Aber keine Straße, sondern ein Waldweg. Von der Ausschilderung mal abgesehen, merkt man es ihm auch an, wenn man dasteht: anderes Profil, anderer Asphalttyp, andere Schultern, etc. Wo ich mehr Problem habe ist bei einem Weg hier in der Gegend zwischen track/grade5 und path/width=1m. Von der Ausschilderung wäre es ein Forstweg, aber die Breite ist teilweise bei nur einem Meter und surface=festgetrampelter Waldboden, roots=many... ;) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openstreetbugs - Umgangston
André Reichelt wrote: Hab ich ne falsche URL, oder was mache ich falsch? Bi mir sehe ich nur vereinzelt ein paar Punkte in irgend einem französichem Kff, mehr nicht... Du musst relativ weit reinzoomen damit er neue Punkte lädt. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterschied: residential, unclassified, service
Lars Francke wrote: ich habe mal eine Frage (ich wette es wird nicht die letzte bleiben). Es geht um den Unterschied zwischen residential, unclassified und service. Das ist eigentlich ganz einfach... scnr Zuerst unterscheiden wir zwischen klassifizierten und nicht klassifizierten (ja, im Amtsdeutsch heißt das tatsächlich so) Straßen. Klassifziert sind, gob gesagt alle, die eine Nummer haben, z.B. A5, B38a, B4711, etc. Alle andeen sind nicht klassifiziert und damit Kandidaten für unclassified. Jetzt wird es tricky, denn residential sind eine Untermenge von unclassified (d.h. jede residential ist eigentlich auch eine unclassified). Das Kriterium, das ich verwende um die beiden zu unterscheden ist: Ist der Hauptzweck der Straße, den Zugang zu den Wohnhäusern entlang dieser zu ermöglichen? = residential Ist der Hauptzweck der Straße, den Zugang zu anderen Straßen zu ermöglichen? = unclassified (Faustregel: Steht irgendwo ein Schild Zur Autobahn da lang, dann führt da sicher nicht über residentials.) Ausserorts wird man eher selten residentials finden, dort also unclassified bzw. klassifizierte Typen. Ein Problemfall sind Straßen in Industrie- und Gewerbegebieten. In Ermangelung eines spezellen Typs tagge ich diese auch einfach als unclassified. Es wäre schön wenn es ein Tag für unclassifed-ohne-Durchfahrtcharakter gäbe. Service sind Zugangswege, die nicht wirklich Straßencharakter haben. Üblicherweise also Straßen auf ein oder auf einem Grundstück. An dieser Stelle noch ein Wort zu tertiary: In Gegendenden in denen es Kreisstraßen gibt, empfehle ich wirklich nur diese zu zu taggen. Das sind dann übrigens meist mehr als man denkt, schließlich sind Kreisstraßen nicht als solche ausgeschldert - im Gegensatz zu z.B. Autobahnen, die übersieht man nicht so leicht. In Großstädten braucht es etwas mehr Kreativiät und Fingerspitzengefühl. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Openstreetbugs - Umgangston
Hallo, ich habe mir heute nach einer Weile mal wieder openstreetbugs angesehen, und war entsetzt. Leute, wenn jemand da meldet, dass irgendwo etwas fehlt ist es absoluter Schwachsinn, zu antworten, derjenige solle es doch gefälligst selbst eintragen. (ok, Bahnpirat mit seinem PLZ-Spam ist ne Ausnahme.) OSB ist doch gerade dazu da, dass Leute, die sich nicht in OSM einarbeiten wollen, TROTZDEM etwas beitragen können. Wenn also jemand meldet, dass irgendwo ein Fußgängertunnel ist, dann ist die einzige bruachbare Antwort: Danke für die Info, wenn ich das nächste mal dort vorbeikomme, werde ich den erfassen. und NICHT dann mach ihn rein oder Dann ändere es wenn Du merkst gleich selber oder Hol Dir ein GPS und dann mal los oder ... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik und place_of_warship!
Sven Geggus wrote: mir gefällt das neue Rendering von Kirchen überhaupt nicht! http://lists.openstreetmap.org/pipermail/talk/2008-August/028504.html cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] nochmal zu B-Plänen
Johann H. Addicks wrote: Ich mache vermutlich irgendwas verkehrt, aber mir gelingt es nicht, folgende Karte nach Referenzierung per Warp it rechnen zu lassen: Warping image... Please be patient! Das kann schonmal ein paar Minuten dauern, aber wahrscheinlicher ist, dass as Ergebnis einfach nicht in Deine Browser ankommt. Dann einfach nochmal die Seite neu laden. Manchmal hilft es auch, die Warp-Methode zu ändern... Wobei, ich seh grade, Du hast ein paar Pnkte mir teilweise bis über 500 Abweichung drin. Da rechnet der sich nen Wolf. Schmeiss mal alle, die deutlich über 100 sind, weg und mach sie frisch. (Bzw. probier, ob Du sie überhapt brauchst.) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wald überwuchert alles beim Osmarende r
GeoJ wrote: mir ist gerade aufgefallen, dass beim Osmarenderer der Wald dazu tendiert alles zu überwuchern (im Gegensatz zu mapnik). Konkret geht es um Flächen, wie military=barracks, landuse=cemetery und amenity=school. Ist das unterschiedliche Verhalten absicht, oder ein Bug? Das ist halt wie einem Luftbild, Wwenn das ein Baum ist, siehst Du den Baum, auch wenn der auf dem Dach des Schulgebäudes wächst... Wenn da kein Baum auf dem Dach ist, sollte da auch kein Wald gemapt sein. Manche Gebäude stehen ja schließlich auf Lichtungen. ;)) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Knotenpunkte vereinigen M
Raphael Studer wrote: konnte auch noch keine Reihenfolge erkennen. Ich befürchte es wird der Node mit der höheren ID auf denjenigen mit der tieferen gezogen (oder Bingo, so ist es. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Presseanfrage Tomorrow: Mapperin gesucht
Andreas Jacob wrote: Weil Frauen mit Landkarten nichts anfangen können? Böses Foul! Nicht unbedingt. Die biologischen Unterschiede zwischen Männern und Frauen sind real, und die Orientierung im Gelände gehört dazu. Eine Landkarte bildet fast genau das ab, was das männliche Gehirn auch zur Orientierung einsetzt. Das weibliche Gehirn tendiert eher dazu in Routen und Wegpunkten zu arbeiten, als in Flächen und Beziehungen. Viele der Unterschiede zwischen Mann und Frau kann man gut verstehen wenn man sich kurz das allereinfachste (und natürlich auch extrem *ver*einfachte) Ur-Modell vor Augen hält: Männer=Jäger, Frauen=Sammler. Für unser Beispiel heißt das: Wild wandert, man braucht ein komplettes Modell der Umgebung um es zu finden und zu verfolgen. Pflanzen bleiben an einem Ort, hier ist es einfacher sich Routen anhand von Wegpunkten zu merken. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Idee: Routing-Rating
[EMAIL PROTECTED] wrote: Diese Idee schwirrt mir schon so lange im Kopf herum; Mir auch eine... Die Idee beruht auf der Annahme, das kein Algorithmus sowie die Genauigkeit der Geodaten eine Strecke so routen können, dass es _uneingeschränkt subjektiv_ die beste Route ist. Auch zum subjektiven Routen: Angenommen, man verpast jeder Straße eine Zahl, die angibt wie sehr diese Durchfahrtscharakter hat. Also, z.B. die Straße, in die man wirklich nur reinfährt, wenn man dort hin will wäre 0, eine normale Wohnstraße 1, die Straße, die man benutzt um in ein Wohngebiet tief reinzufahren 3, eine Hauptstraße 10, Autobahn 100... Dann bringt man dem Router bei, dass die ideale Route aus einmal aufteigend und eimal absteigend besteht, und dess jedes hoch runter hoch schlecht ist. Und dann noch, dass er versuchen soll, jeweils so schnell wie möglich hoch zu kommen. Das würde IMHO die Ortskenntnisse der Mapper auf eine einfach zu nutzende Art und Weise abbilden. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] diffs von Bearbeitungen einsehen
Michael Wolf wrote: http://openstreetmap.org/browse/way/24859181/history Was konkret hat er das geändert? Er hat den Weg umgedreht. Mmmh, bei dieser Straße eine komplett sinnlose Aktion --- keine Einbahnstraße, keine Steigung... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[OSM-talk] Split into map and data projects, was: Re: Actually using OpenStreetMap and the usability of thecurrent maps
Someone wrote: let's keep the focus on filling up the database I'll give 100% support to the 20%, the 80% should wait some more or better still try to do some mapping, somewhere, anywhere! That sums it up rather nicely. OSM is only about collecting data, people that are interested in using the data are not really welcome very much. So I propose to start a new project, that is about using OSM data only. Transfer the current renderers and maps to the new project, and maybe it would be possible there to et up a server farm, so people interested in different rendering styles can concentrate on the rendering styles and not on the problem of serving them. Anyone interested? That new project would first need people that have time to organize it (I really don't have), and people to raise or provide funding. cu Henry ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] [EMAIL PROTECTED] furchtbar langsam
Florian Lohoff wrote: Und leider ist eben die notwendige Hardware nicht gerade Alternate off-the-shelf zeugs Amazon EC2 wäre durchaus eine Alternative, vor allem ist es skalierbar anhand des verfügbaren Geldes. Die Preise für die Rechner sind auch ok (0,10 bis 0,80 USD/Stunde), nur der Traffic ist ein wenig teuer (0,17 bis 0,10 USD/GB) für unsere Bedürfnisse. http://www.amazon.com/Instances-EC2-AWS/b/ref=sc_fe_c_0_201590011_2?ie=UTF8node=370375011no=201590011me=A36L942TSJ2AJA http://calculator.s3.amazonaws.com/calc5.html? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tennisplatz in Sportverein in Wald
GeoJ wrote: Auf leisure=sports_center wäre ich jetzt nicht gekommen. Laut Map Features DE ist das ein Fitnesscenter... mmmh, dict.leo.org sagt sports centre/center=Sportzentrum... Auch das heißt Sports Center und sieht nicht nach Fitnessstudio aus: http://de.fifa.com/mensolympic/destination/stadiums/stadium=5015625/index.html Das hier allerdings: http://www.sportscentre.org.uk/ ist vom Angebot her schon eher mit einem deutschen Fitnesscenter zu vergleichen. Ich denke, der Problem ist das deutsche Vereinswesen. Hierzulande gibt es für fast alle Freizeitsportarten einen Verein, das läßt den kommerziellen Betreibern (=Fitnesscenter) wenig über. Also alle Sportangebote sind sports_center, unsere Fitnesscenter wären am ehesten health_club. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlatch, die Siebenundzwölfigste
Richard Fairhurst wrote: I get intensely frustrated when people complain about aspects of an open source project like OSM, but don't actually _do_ anything about it. So again it boils down to we don't want any teamwork, we only want people who randomly implement stuff on their own and if you want to talk about some aspect of OSM, you are not wanted here. Funny, I always hated the part of my job about discussing ideas with the team first instead of just implementing them. Past tense. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlatch, die Siebenundzwölfigste
Richard Fairhurst wrote: So again it boils down to we don't want any teamwork, we only want people who randomly implement stuff on their own and if you want to talk about some aspect of OSM, you are not wanted here. No, it doesn't. Talking is great (like I say, especially if you talk to someone who can actually do something), but it's got past that stage now. Fair. I've seen several threads on talk-de complaining about Potlatch but not one single person actually committing patches. I'm genuinely puzzled - how do you think there are going to be any improvements if you don't muck in and help? Who do you think is actually going to do The single problem with all threads so far is, that they ended nowhere. The people who started them got chased away, any suggestions got flamewared instead of discussed, and so on. Until now, nobody came up with the one-big-answer-that-solves-all. Some good initial ideas came up, but without constructive discussion, they quickly died. Some were killed by the API-0.6-will-have-changesets hammer, some with the the-developer-will-never-implement-that axe. Oh, and quite often we had the that-would-kill-the-purpose-of-potlatch guillotine... I see 4 major problem areas with potlatch: * New users don't know realize that they change the live data. The new popup window and the start/play buttons helped, but we all know people will click anything if that helps them not reading any text. Also the map not insta-showing their changes helps here. * New users don't know how to use potlatch. Having few buttons on-screen makes a friendly UI, but it doesn't help users to realize the full potential of a tool. Together with #1, we get the oops, that was a mistake, close the browser window and restart-syndrome---that works well with e.g. Wikipedia, but not potlatch. * potlatch doesn't catch common errors, like not connecting ways or ways going A-B-A. I think someone who actually had to cleanup after a potlatch user can tell you more about this one. * potlatch does not tell the user what changes are applied. So people can, e.g., move a way without even realizing they did. There is a fifth problem, but that is not really a software problem: * Random people do random edits in random areas. Meaning, that with potlatch you can edit anywhere in the map, you don't have a home area. For all those people who have a home area, an area they build up and care for and spent hours to perfect it, the typical potlatch edit (three changes by a person who never before has edited something in that area) is very intrusive. cu Henry PS: My personal wishlist for potlatch with API 0.6 would be a big nice green(*) window saying potlatch is now going to submit the following changes into the database. Please review them and enter a comment into the edit field below. And one or two zoom levels more, I got some roundabouts here, that are uneditable in potlatch because you almost only see a grey area with some nodes ;) (*) green is a friendly colour, they say :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bundesstraßen als trunk?
Christoph Brill wrote: Wenn ich die Map-Features richtig verstehe heißt das doch, dass baulichgetrennte oder richtig große Bundesstraßen (2 und mehr Spuren jeRichtung) mit trunk gekennzeichnet werden sollen und kleinere (1 Spur,evtl. keine Begrenzung zwischen Richtungen) mit primary. Richtig? 4 Antworten, 4 Meinungen, typisch :-) Ich tagge in Deutschland dann als Trunk, wenn die Straße autobahnähnlich ausgebaut gemäß gesetzlicher Regelung ist. (Der Status Kraftfahrstraße reicht mir nicht, das passt ja gut in die access-Tags.) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bundesstraßen als trunk?
Thorsten Feles wrote: Wenn ich die Map-Features richtig verstehe heißt das doch, dass baulichgetrennte oder richtig große Bundesstraßen (2 und mehr Spuren jeRichtung) mit trunk gekennzeichnet werden sollen und kleinere (1 Spur,evtl. keine Begrenzung zwischen Richtungen) mit primary. Richtig? 4 Antworten, 4 Meinungen, typisch :-) Ich tagge in Deutschland dann als Trunk, wenn die Straße autobahnähnlich ausgebaut gemäß gesetzlicher Regelung ist. (Der Status Kraftfahrstraße reicht mir nicht, das passt ja gut in die access-Tags.) Die Autobahn-Freunde nennen diese Dinger auch gerne Gelbe-Autobahn, steht so wohl auch im Wiki. Als Trunk würde dann, wie Henry schon meinte, nur das durchgehen was sehr sehr stark an eine Autobahn erinnert, aber halt keine blauen sondern gelbe Schilder hat. Hat eigentlich jemand eine Idee, warum manche Mails bei mir ohne einzelne Zeilenvorschübe ankommen? (und doppelte werden zu einzelnen reduzert.) Zurück zm Thema: Ich habe mal nachgeschlagen, §3 (3) 2c STVO: [...] Straßen mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt sind. [... und] Straßen, die mindestens zwei durch Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340) markierte Fahrstreifen für jede Richtung haben. Quelle: http://bundesrecht.juris.de/stvo/__3.html Allerdings würde ich persönlich für trunk gerne noch Kreuzungsfreiheit (vgl. http://de.wikipedia.org/wiki/Höhenfreiheit ) als Voraussetzung hinzufügen --- ansonsten kommen viel zu viele Straßen in den Genuss dieses Tags. Ich würde auch Straßen, die obigen Kriterien genügen aber sich innerorts befinden (§3 (3) 2 bezieht sich nur auf außerorts!) als trunk taggen. Jemand da der Gegenargumente hat? Sonst kopiere ich das als Definition für Deutschland-Trunks ins Wiki... cu Henry PS: Die STVO ist schon eine Fundgrube, es gibt nämlich noch eine Definition: außerhalb geschlossener Ortschaften auf Kraftfahrstraßen (Zeichen 331) mit Fahrbahnen für eine Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen getrennt sind (§18). Der Effekt ist, dass auf einer trunk ein 8t-LKW - wie ausserorts - nur 60 fahren darf, auf einer trunk mit Zeichen 331 aber - wie auf einer Autobahn - 80 fahren darf. Mmmh, auf einer trunk mit Zeichen 331, die nur eine Trennung durch Zeichen 295 hat, darf er auch nur 60 fahren. OMG, was ein Glück, dass ich sowas nicht fahren muss (darf/kann)... g ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Bundesstraßen als trunk?
Alexander Schulze wrote: Dann sollte man das wiki eventuell mal dahingehend anpassen. Denn so wies hier steht Ist für mich jede Straße, die Das Verkehrszeichen 331 hat eine Kraftfahrtstraße und somit highway=trunk und motorroad=yes. Ja, war missverständlich formuliert. Ich habe an das zusätzlich noch ein zum passenden highway-Tag angehängt. Ausserdem habe ich die Links zu §3 und zur Kreuzungsfreiheit in Klammern zum ersten Satz hinzugefügt. Typisch deutsche Regulierungssucht, würde ich sagen. Woanders hätte man einfach geschrieben: Sieht aus wie ne Autobahn, ist aber keine. ;) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk] Names, split streets and relations
Gervase Markham wrote: Indeed. My question is: can they? :-) (The opposite problem is the very long road which is a single way. The name should regularly repeat, but I don't think it does on either Mapnik or Osmarender.) I have proof-of-concept code for Osmarender (or to be more correct: for any renderer that reads osm files) that does exactly those two things. The concept I implemented splits each way into 3 parts: (1) The original ways without name or ref. (2) A way with only the name, split into same-sized parts of a configurable maximum length. (3) A number of nodes with only the ref-tag, distributed evenly with a configurable maximum distance along the way. Example, rendered with Kosmos: http://j-e-b.no-ip.com:8080/p/map.jpg Code, Perl: http://j-e-b.no-ip.com:8080/p/cwc.pl Note: The code will output a new osm file containing the original data and new ways tagged with nameway=(any highway type) and name=*, and new nodes tagged with refway=(any highway type) and ref=*. So you need to adapt your rendering rules to (a) not render names for highway=*, (b) render names for nameway=*, (c) render little boxes for refway=*. Also: DO NOT UPLOAD THE RESULT FILE TO THE SERVER!!! cu Henry PS: The list of supported highway types has not been updated since early May. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] [EMAIL PROTECTED] furchtbar langsam
Christoph Eckert wrote: (a) Kein Geld da (b) Keine Zeit da (c) Keine Lust (d) Sonstiges (a) wird dementiert, Geld soll da sein. (b) kann es nicht sein, ich hab noch nie einen Admin gelesen, der um Unterstützng gebeten hätte, aber regelmäßig von Leuten, die sich angeboten haben. Zu (d) fällt mir nix ein (und André wohl auch nicht). Also bleibt frei nach Sherlock Holmes ja nur noch (c), oder? ich frage mich wirklich auf welcher Insel Du lebst. Wie kommst Du dazu eine solche Aussage zu treffen?!? Welche denn? Die dass quasi jeder, der sich Gedanken um die aktuellen Problem macht, zu diesen Schluss kommen muss? Und, kleiner Bericht von den Berlinstammtischen: Die Leute kommen auch auf genau diesen Schluß. Mir stellt sich vor allem die Frage welche Intention hinter Deiner Aussage steckt. Dass Du dem Projekt damit enormen Schaden zufügst muss Dir klar sein. Nein, den Schaden fügt Ihr dem Projekt zu, wenn Ihr weiter die absolute Mehrheit der User derart im Dunkeln lasst. (Ihr==die Leute, die wissen warum es klemmt) Welchen Nutzen Du Dir darüberhinaus versprichst kann ich absolut nicht erkennen. Vielleicht dass jemand mal aufwacht und merkt, dass die Leute ohne Fakten spekulieren müssen, wenn sie drüber nachdenken, warum (a) tah seit zwei Wochen Müll ausliefert(*), (b) die Haupt-API seit 1 1/2 Monaten lahm wie Sau ist. Solange jeder, der dazu eine Anfrage stellt (mal abgesehen vom Tonfall, dieser Thread ist ja nicht der erste zu dem Thema) entweder zugeflamet und ins Killfile gesteckt oder mit einem höflichen Machs-doch-besser bedacht wird, bringt uns da nirgendwohin. Wie sill man denn neue Leute einbinden, wenn alle Angebote abgewiegelt werden? Die letzten 2 Monate hieß es z.B. immer wenn jemand sich für den tah-Server angeboten hat, nee, gibts nx zu machen, neue Platten sind unterwegs, dann ist alles wieder ok. Geh heim spielen, du hast von so'nem dicken Server eh keine Ahnung. Inzwischen hat sich jemand erbarmt eine neue Serversoftware zu schreiben (nachdem 2 Wochen lang versucht wurde, alle Vorschläge zu dem Thema, schlechtzureden) und was passiert nach ein Paar Tagen? Bingo, der Server hängt wieder in den Seilen, nur diesmal nicht wegen NFS-IO sondern Webserver-Prozessen. Mmmh, vielleicht hätte jemand von den Abgewiesenen doch Ahnung von so einem dicken Server gehabt, oder Geld oder Kontakte gehabt? Ich bin mir recht sicher, wenn Anfang Juni jemand gesagt hätte ok, der tah-Server braucht Verstärkung, wir hätten heute einen zweiten Server. Und warum bist Du hier? Gibt es einen besonderen Grund, diese Diskussion auf ein persönliches Level herunterzuziehen? Ist es inzwischen so, dass man sich beweisen muss um hier mitzumachen? (vergleiche hierzu auch Sven Geggus, 26.7. 19:55: Beim ersten Subversion commit Deinerseits werde ich Dich [aus dem Killfile] natürlich gerne wieder raustun...) Aber wenn du schonmal fragst: Ich bin hier um meine freien Resourcen in ein Proejekt einzubringen, das ich persönlich unterstützen möchte weil ich es gut finde. Leider war es mir nach dem Machs-besser-Prinzip bisher nicht möglich einen schnelleren Main-API-Server aufzusetzen. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] furchtbar langsam
André Reichelt wrote: Entweder die haben überhaupt kein Geld oder die sind einfach viel zu Faul, was zu machen und lassen das Projekt auf unseren Kosten zerfallen, An alle, die sich hierrüber so köstlich aufgeregt haben: Was SIND denn die Gründe dass nichts passiert? (a) Kein Geld da (b) Keine Zeit da (c) Keine Lust (d) Sonstiges (a) wird dementiert, Geld soll da sein. (b) kann es nicht sein, ich hab noch nie einen Admin gelesen, der um Unterstützng gebeten hätte, aber regelmäßig von Leuten, die sich angeboten haben. Zu (d) fällt mir nix ein (und André wohl auch nicht). Also bleibt frei nach Sherlock Holmes ja nur noch (c), oder? PS: Eins fällt mir grade noch ein: (e) Es gibt gar keine Admins... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OpenGeoDB-Import
FreeWorld wrote: Nur für den Fall der Fälle. Wie sollte denn ein Neuimport aussehen? Ich meine, was macht man mit den bereits existierenden Ortsnamen? Soweit ich mich erinnere (stand ja alles in der Diskussion von damals) updated das Script die vorhandenen Nodes mit geodb-Tags und ändert dabei nur die geodb-Tags und die in openGeoDB:auto_update aufgeführten normalen Tags. Orte für die es keine gedodb-getaggten Nodes gibt werden hinzugefügt. Verschoben werden die Nods auf keinen Fall. Also genau so, wie's sein soll. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] WayPoints in JOSM
Bernd Wurst wrote: Straße. Es bringt also in vielen Fällen nichts, wenn die magnetisch wären, da man den POI daneben setzen will. Du weißt, dass es möglich ist, einen Node neben etwas magnetisches zu setzen, aber unmöglich einen Node genau auf etwas nicht-magnetisches zu setzen? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Humor auf talk-de
Frederik Ramm wrote: Guten Ideen gegenueber bin ich durchaus aufgeschlossen, hat jemand welche? Ja: Jeder sollte mal auf den Namen dieser Liste schauen. Sie heißt talk (-de). Es ist also eine Liste zum reden, labern, sich austauschen. Sie heißt nicht help, discussion, announce, dev, o.ä. --- auf einer solchen Liste hätte Smalltalk nichts verloren. Aber auf einer talk-Liste ist das on-topic. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?Amtl. Bebauungspläne (PDF) i n josm laden?
Sven Geggus wrote: Zunächst müsste ich aus dem PDF das Bild extrahieren und dann dieses Bild georeferenzieren. Was nimmt man denn da um ein integriertes Rasterbild in korrekter Auflösung aus einem PDF zu extrahieren? Unter OSX einfach Preview, das kann alles mögliche als alles mögliche speichern. Um eine ausreichend hohe Auflösung hinzubekommen (d.h. man kann leider die dpi für den Export nicht angeben), vorher einmal als PDF in A0 drucken und das dann als JPG speichern. Unter Windows kann z.B. das Screenshotprogramm SnagIt (Shareware/Demoware) sich als Drucker präsentieren. Wer einen hochauflösenden Monitor hat, kann aber auch einfach einen normalen Screenshot machen, bei 1980x1200 sollte das eigentlich reichen... g cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM-Plugin Vereinfache ..
Frank Jäger wrote: das JOSM Plugin 'vereinfache Weg' geht seit kurzem sehr grob mit den Wegen um. Der Bug wurde schon gefunden, siehe Archiv der josm-dev Mailingliste. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Antw: Re: Eisenbahn, die Zweiundvierzigste...
TopSpotter wrote: Problem: ich habe keinen verborgbaren GPS-Empfänger, den man mal einen Monat lang meinen Kumpels in den Führerstand legen könnte. Zumal einige davon Einfache Datenlogger bekommt man schon für 50 Euro. Wenn Dir das zuviel ist, ich denke auf hier hat's genug Leute, für die das eher Richtung Portokasse läuft --- zumindest wenn das Gerät dann auch wirklich für OSM genutzt wird und nicht nach 'ner Woche in irgeneiner anonymen Schublade vergammelt. cu Henry PS: genug==mindestens einer. ich=eins. q.e.d. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwe nden?
Sven Felix Oberquelle wrote: ich wollte mal fragen, wie man am besten Areas wie landuse mappt. In Schau mal ins Archiv der Mailingliste, dort wirst Du etwa alle 10 bis 14 Tage eine Diskussion zu dem Thema finden, aber keinen Konsens. Diese Formulierung von wegen Wege wiederverwenden scheint noch aus der Segment-Zeit zu stammen und ist heutzutage eher verwirrend als hilfreich - man kann nämlich keine Wege für Flächen wiederverwenden... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwen den?
Rolf Gehring wrote: Ich möchte meine aktuelle Meinung kurz darlegen, um diese Fraktion etwas zu stärken. Ok, wenn wir schon dabei sind, muss ich's mir ja auch nicht verkneifen... ;) Man sollte auch bedenken, wie die Karte aussieht, wenn mal NICHT alles gerendert wird. Wenn ich also eine Spezialkarte machen will, in der NUR landuse erscheint, möchte ich keine komischen weißen Korridore zwischen den Flächen. Wir haben grob gesehen 4 Informationsebenen im Datenbestand: (1) natural (Wasser, Wälder, Wiesen, bebaute Flächen) (2) landuse (Wohngebiete, Gewerbegebiete, Waldgebiete) (3) manmade (Straßen, Häuser, Plätze) (4) political (Länder, Gemarkungen) (Ebene 1 ist was wir auf einem Schülerglobus sehen wenn die Lampe aus ist, Ebene 4 dann mit Lampe. Eine Straßenkarte bildet Ebene 3 über Ebene 2 ab. Eine Wanderkarte eher Ebene 3 über Ebene 1. Beide haben wohl noch Auszüge aus Ebene 4.) Jede dieser Ebenen sollte am Ende so komplett sein, dass eine Karte, die nur ihre Ebene abbildet, keine weißen Löcher hat. (Ausnahme Ebene 3) Damit schneide ich übrigens auch die alte landuse=forest vs. natural=wood Diskussion an. landuse ist Ebene 2 (was sagt der Mensch soll dort sein), wohingegen natural Ebene 1 (was ist dort wirklich) ist. Stehe ich z.B. mittem im Wald, so ist Ebene1=Wald, Ebene2=Wald, Ebene3=n/a, Ebene4=Sandhausen/Rhein-Neckar-Kreis/Regierungsbezirk Karlsruhe/Baden/Baden-Württemberg/Deutschland/EU. Stehe ich 2 meter daneben auf dem Weg, habe ich Ebene1=Wald, Ebene2=Wald, Ebene3=Track, Ebene4=Sandhausen... Stehe ich in meiner Einfahrt: Ebene1=bebaut, Ebene2=Wohngebiet, Ebene3=n/a (bzw. Einfahrt, wenn wir mal so genau mappen wollen), Ebene4=Sandhausen... Gehe ich zur Straße, wird das zu Ebene1=bebaut, Ebene2=Wohngebiet, Ebene3=residential, Ebene4=Sandhausen... etc. Grüße von Ebene1=bebaut, Ebene2=Wohngebiet, Ebene3=building, Ebene4=Wedding/Mitte/Berlin/Berlin/... Henry PS: Landuses grenzen direkt aneinander, weil es auf Ebene 2 keine Straßen gibt. Also für angrenzende Landuses also die gleichen Ndes verwenden (genauso wie Grenzen angrenzender Länder auf den gleichen Nodes liegen, solange es kein Niemandsland dazwischen gibt). Ob die Straße auf der Grenze oder daneben liegt, ist von der Situation abhängig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] einmalige oder oder offizielle Ortsnamen?
Hatto von Hatzfeld wrote: Man müsste mal fragen, wie die das in Bangkok machen. Wenn ich recht informiert bin, dann ist dessen offizieller Name nämlich Krung Thep Mahanakhon Amon Rattanakosin Mahinthara Ayuthaya Mahadilok Phop Noppharat Ratchathani Burirom Udomratchaniwet Mahasathan Amon Piman Awatan Sathit Sakkathattiya Witsanukam Prasit bzw. in der dort üblichen Schriftกรุงเทพมหานคร อมรรัตนโกสินทร์ มหินทรายุธยา มหาดิลกภพ นพรัตนราชธานีบูรีรมย์ อุดมราชนิเวศน์มหาสถาน อมรพิมานอวตารสถิต สักกะทัตติยวิษณุกรรมประสิทธิ์ Na solange das Ding mit name:de=Bangkok getaggt ist, ist mir das egal g + scnr² cu name:osm=Henry loc_name=ich ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Brainstorming zum OpenRouteService
Bernd Wurst wrote: aber es gibt durchaus bundesstrassen, die durch ortschaften fuehren, und (zum teil wechselnde) strassennamen haben. die sollte man dann schon beruecksichtigen. du dann vom Navi wirklich an jeder Kreuzung hören Fahren Sie geraudeaus auf Bla-Blubb-Straße? Das auf der selben Straße würde ich eben am ref festmachen. Ich glaube, ich baue meine Idee zum Komplettbeschreiben einer Kreuzung per Relation doch mal aus. Aus dieser Relation könnte der Router nämlich ablesen, was er an einer Kreuzung sagen muss (nix oder geradeaus oder abbiegen)... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Kreuzungsrelation, war: Re: Brainstorming zum OpenRouteService
Bernd Wurst wrote: Voll dafür. So lange mein proprietäres Navi mehr Infos über eine Kreuzung liefert als wir erfassen können, läuft was schief. :) Das war auch bei mir der Auslöser mir diese Gedanken zu machen. Zu deinem Vorschlag vom letzten Mal: rechts halten und links halten sollte auch noch möglich sein, für den Fall wenn sich eine mehrspurige Straße teilt und es kein Abbiegen nach halb-rechts ist. Jepp, hab ich drin. Ebenso habe ich jetzt komplexere Kreuzungen vorgesehen, also welche, die viele Nodes, Abbiegespuren, Überleitungen etc. haben. Ein Autobahnkreuz läßt sich jetzt als eine Kreuzung beschreiben. Eine Kreuzung mit 6 Straßen, 9 Radwegen, 4 Fußgängertunneln und einem Zebrastreifen auch. Wichtig wäre IMHO, dass du das was du letztes mal geschrieben hast (plus das oben) in eine Wiki-Seite umformulierst. Ich wäre dein erster User dieser Relation. Erst mal hier, da bekomm ich mehr Verrisse ...ähm... Feedback ;) Und für die Kritiker: Eine 08/15-Kreuzung, die das Navi auch korrekt aus den Daten interpretieren kann, muss man natürlich nicht so erfassen. Nur weil das letztes Mal gleich als das-ist-so-viel-Arbeit-Argument kam. :) Genau. Hab ich jetzt auch oben reingechrieben. So, hier der Entwurf. Ich muss nochmal nachschauen, ob ich Crossing lasse, oder ob Junction o.ä. besser wäre. =Advanced Crossing Relation ==General The advanced crossing relation (ACR) is intended to describe all possible transitions from one street to another that can happen at a crossing. As such it is quite complicated, but it is not intended to replace existing relations or tags, but to help model crossings that can not be described correctly using these. So if a simple turn restriction relation is enough for your crossing, just use that easier tun restriction relation. ==About the model The ACR sees a crossing as a number of ways that have exactly 2 ends and a number of nodes that connect those ways. Any possible path then can be describes as a series of ways and nodes, starting and ending with a way. For any of those paths, the ACR describes how a human driving (cycling/riding/walking/...) along it would experience it. Or, to name the expected usage, what a satnav (a.k.a. GPS, a.k.a. navi) would have to announce so the human would take that path. ==Type The type of the relation is ACR. ==Roles All ways and nodes belonging to the crossing (that includes the ways that only have one end at the crossing) are included in the relation exactly once. Their tag must be an unique (within the relation) string containing numbers and letter only. Please note that that is a difference to other relations that have fixed role names. ==Tags Every tag describes one path in the crossing, that may be a complete path through the crossing, or just one step. Generally speaking one path corresponds to one announcement of the satnav system. ===Tag Keys Tag keys are constructed from the role names. Again here the ACR differs from other relations that use fixed key names. To construct the key, concatenate the role names of all parts of the path, separated with an underscore (_). ===Tag Values The value describes the path. Possible values are: no - this path cannot be taken (this is the default for all thinkable paths that are not modeled). auto - this path will be taken automatically by following the road. A satnav does not need (nor should) announce anything. straight - to take this path, you must go straight ahead, leaving the road you're on. right, left - turn right or left to take this path. sharp right, sharp left - make a sharp turn. Use this only if you've already have used up the right/left or if it would be difficult to follow the satnav's directions with a simple left/right announcement. half right, half left - see sharp uturn - this is a u-turn at a position where it is allowed and possible. Use this one for special u-turn lanes. The satnav should announce this as a definite instruction. possible uturn - here it is possible to turn, but there are no special lanes or signs. The satnav should announce this with care, e.g. by adding if possible to it's instruction. (Please note that a pedestrian can always and everywhere do a u-turn. No need to model that...) exit right, exit left - this is an exit from a motorway or trunk road, or some construct that looksfeels the same. right lane, left lane, center lane - here the driver has to chose the right lane, that later will move away from the main body of the street. No turning involved. parallel lane - this is the special lane at large motorway crossings that runs parallel to the main body and leads to the real exits. Hint: To use such a crossing you'd need to follow exit, exit or exit, parallel, exit. roundabout 1, roundabout 2, etc. - this is a path leading through a roundabout, the number says which exit from the roundabout to the, e.g. leave the roundabout at the 3rd exit. As an exception to the
Re: [Talk-de] Kreuzungsrelation
Bernd Wurst wrote: So, hier der Entwurf. Ich muss nochmal nachschauen, ob ich Crossing lasse, oder ob Junction o.ä. besser wäre. Wie Frederik schon schrieb, wäre evtl. eine Abstimmung mit http://wiki.openstreetmap.org/index.php/Proposed_features/Junction sinnvoll. Auch wenn ich eine krasse Relation dafür viel besser finde als das auf irgendwelche Wege dazu taggen zu wollen. Ich hab mir das zwischenzeitlich mal angesehen. Das geht in eine ganz andere Richtung. Sein Tagging ließe sich nutzen um das Symbolbild in der Routenliste darszustellen, aber nicht um Fahranweisungen zu geben. Auf jeden Fall bin ich gegen die Bezeichnung advances crossing relation und gegen type=acr. type=junction wäre IMHO sinnvoll(er). Einfach nur junction? Mmmh, vielleicht Compley Junction Relation (CJR)? exactly once. Their tag must be an unique ^ Du meinst role? Oops, ja. path, separated with an underscore (_). 1_to_2=left Mööp, widersprüchliche Angabe... ;-) Nein. 1 und 2 sind ways, to ist der node. Im Klartext: Um von Straße '1' auf Straße '2' zu gelangen, biege an Node 'to' nach links ab. Ein Tag setzt sich aus Way_Node_Way zusammen. Oder eben Way_Node_Way_Node_Way, oder ... possible uturn - here it is possible to turn, but there are no special Hm. possible uturn Finde ich jetzt eher unpraktisch. Damit könnte man die passende turn_restriction ersetzen, klar. Aber irgendwie hab ich hier beim Lesen Bauchschmerzen bekommen. Leider kann ich das momentan nicht formulieren. Ja, soll so --- wenn die ACR/CJR da ist, soll die Kreuzung komplett beschrieben sein. Wozu 2 unterschiedliche Relationen an eine Kreuzung hängen müssen um unterschiedliche Aspekte des gleichen Sachverhalts zu bescheiben? Der Name, ja, da hab ich auch lange gegrübelt. Mir fiel nix besseres ein. Es muss eben auf jedenfall der unterschied zwischen jetzt wenden, wenn möglich jetzt wenden und jetzt dreimal rechts und einmal links abbiegen rein. Vielleicht auch noch der Unterschied zwischen Wenden verboten und erlaubt, aber es ist nicht genug Platz auf der Kreuzung also nicht so routen? Eigentlich schließt sich exit_left und exit_right innerhalb eines Landes doch aus, oder? Nein, tun sie nicht. Es gibt in Deutschland auch auf Autobahnen Ausfahrten nach links. Und bei sonstigen Straßen, die Ausfahrten haben sicher noch mehr. Ich denke da an innerörtliche Verkehrsknoten, wie man sie öfter an Brücken findet --- 4 Stockwerke hoch und alles getrennte Fahrtrichtungen und eben Ausfahrten. right lane, left lane, center lane - here the driver has to chose the Hm. Da *muss* der Spur-Assistent mit rein. Ich will auf dem Navi sehen können, ob jetzt eine, zwei oder drei Spuren in welche Richtung weg gehen. Nein, ich hab noch keine konkrete Idee. Aber das muss da rein... Ganz einfach: Die Wege noch mit lanes=* taggen, dann passt das. Eng wird es nur, wenn sich ein Way an einem Node in mehr als 3 Ways aufteilt. parallel lane - this is the special lane at large motorway crossings Da ist mir nicht klar, wo ich ein parallel-Ziel taggen soll. Bei der Autobahn ist es exit auf die parallel-Bahn, von dieser dann exit oder right_lane auf die wirkliche Abfahrt. Von der Autobahn auf die Ausfahrtspur: exit right Von der Ausfahrtspur auf die erste Ausfahrt: exit right Von der Ausfahrtspur geradeaus: parallel lane Von der Parallelfahrbahn auf die zweite Ausfahrt: exit right Von der Parallelfahrbahn auf die Autobahn: auto Ansage von Navi zum links abbiegen: Rechts abfahren, dann der Parallelfahrbahn folgen, dann rechts abfahren. Zumindest mein Navi sagt diese 3 Manöver an. roundabout 1, roundabout 2, etc. - this is a path leading through a So kann man dann auch subjektiv einschätzen, ob das Navi besser 2. Ausfahrt sagen sollte oder im Kreisverkehr geradeaus. Ich weiß nicht, aber Richtungsangaben im Kreisverkehr (also vorher angesagt) finde ich nicht so gut. Hinterher biegen die Leute noch im Uhrzeigersinn in den Kreisverkehr ein, wenn sie besser die 3. Ausfahrt genommen hätten... Aber wenn gewünscht nehm ich noch straight/right/left als Zusatz für die Kreisverkehre rein, lso z.B. roundabout 2 straight, dnn kann das Navi entscheiden, was es ansagt. Wobei man auch sagen muss, dass das Navi die Ausfahrten auch selbst zählen könnte. :) Wenn ich für jedesmal, wenn man Navi sich bei sowas verzählt hat, nen Euro bekommen hätte, könnt ich mir davon ein neues Navi kaufen g Ich hab hier ein Navi, das bei großen Kreisverkehren sogar nochmal jetzt Kreisverkehr verlassen sagt, wenn man halb rum ist. :) Meins sagt in großen Kreisverkehren gerne mal jetzt zweite rechts abbiegen. Normalerweise bin ich abgebogen bevor es ausgesprochen hat ;) Find ich nicht gut. Es bringt IMHO keinen Mehrwert gegenüber dem Weglassen der Relation. Da man nicht die presets als Template benutzen kann, bringt es auch nichts, das so zu taggen. Steht auch auf meiner Streichliste. Jemand dafür
Re: [Talk-de] Kreuzungsrelation, war: Re: Brainstorming zum OpenRouteService
Frederik Ramm wrote: To construct the key, concatenate the role names of all parts of the path, separated with an underscore (_). Wenn Du spezielle Tags an Ways haengen willst, die nur innerhalb der Relation gelten, dann hast Du zwei Moeglichkeiten: (a) Relations in der Datenbank so erweitern, dass es statt role=x beliebig viele Nicht wirklich realistisch, oder? Tags pro Member geben kann. Oder (b) ueberall da, wo Du Ways in Deiner Relation hast, nutze stattdessen Relations (d.h. die Member Deiner Kreuzungsrelation sind Relationen, die jeweils einen Way enthalten sowie alle Spezialtags dazu). Und das erzeugt bei einer normalen X-Kreuzung 17(!) Relationen, wenn man sie komplett erfasst. Solche Monster wollte ich eigentlich vermeiden, das kann kein Mensch mehr warten. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Kreuzungsrelation
Bernd Wurst wrote: Ja, einfach nur junction. Du willst alle Situationen abbilden, also sollte es keine andere junction-relation geben müssen. Ok, ich geb mich geschlagen. ;) Ein Tag setzt sich aus Way_Node_Way zusammen. Oder eben Way_Node_Way_Node_Way, oder ... Ah, okay. So komplex ist das... ;-) Ja. Wobei ich gerade gemerkt habe, dass der Node eigentlich nur in wenigen Spezialfällen nötig ist. Nämlich nur dann, wenn 2 Ways mit jeweils beiden Enden miteinander verbunden sind. Dann gibt es nämlich 2 Möglichkeit von 1 nach 2. Ich glaube ich nehme die Nodes wieder raus un verbiete einfach den Sonderfall. Der lässt sich dadurch auflösen, dass man einen der beiden Wege teilt. Wenn möglich, bitte wenden ist ja die Standard-Anweisung wenn man mal wieder intelligenter als das Navi war. Unabhängig von einer Kreuzung. :) Nicht ganz, mein Navi unterscheidet zwichen wenden, wenden wenn möglich und 3+1. Also ich würde possible_uturn ersatzlos streichen und nur das eintragen wo man wirklich wenden kann. In Großstädten, in denen solche Maneuver gewollt vorkommen, gibt es eigentlich oft entsprechende Wende-Spuren. Das nakte uturn ist genau für solche Wendespuren. Wir brauchen also noch was für Mapper sagt hier geht's und ggf. sogar rechtlich erlaubt. Eigentlich schließt sich exit_left und exit_right innerhalb eines Landes doch aus, oder? Nein, tun sie nicht. Hm. Ich bin schon ruhig. :) *g* Du hättest mich al sehen sollen, als ich zum ersten mal an einer linken Autobahnausfahrt vorbeigekommen bin... right lane, left lane, center lane - here the driver has to chose the Das soll doch links halten abbilden, oder? Also im Sinne von jetzt links halten um im Autobahndreieck auf die A 7 zu wechseln. Ja. Das ist für Spuren in Autobahndreiecken, aber auch für mehrspurige Kreuzungen. Der Straßen-Planer, der sowas mit mehr als drei *unterschiedlichen* Spuren macht, geht als Sadist durch. :) Ich weiß nicht, gibt es sowas? Ja. Das passiert wenn nicht neue Spuren dazukommen, sondern vorhandene Spuren mit einer Richtung versehen werden. z.B. Westkreuz Frankfurt/Main von Süden. Da sind 4 Spuren und plötzlich steht über der Fahrbahn, dass eine nach rechts Richtung Osten, eine nach rechts Richtung Westen und 2 geradeaus gehen. Da hat eigentlich kein Navi eine Chance, das gut anzusagen. Selbst als Beifahrer ist es schwer den Fahrer nach Westen zu lotsen. Mein Navi sagt übrigens rechte Spur, dann Parallelfahrbahn zur zweiten Spur von rechts. Wenn man sich da mal dran gewöhnt hat, klappt das ganz gut. Von der Autobahn auf die Ausfahrtspur: exit right Von der Ausfahrtspur auf die erste Ausfahrt: exit right Von der Ausfahrtspur geradeaus: parallel lane Von der Parallelfahrbahn auf die zweite Ausfahrt: exit right Von der Parallelfahrbahn auf die Autobahn: auto Ich hab grade nen Knoten im Hirn, ich glaub ich brauch ein Beispiel... Autobahnbeispiel kommt später. Wie modellierst du diese vielen Anweisungen, die nötig sind um das zu erreichen? Jede Anweisung ist ein Tag der Relation. roundabout ist IMHO sogar redundant. steckt ja schon im Weg drin. Aber nicht, ob er auch so angesagt werden kann. Das liegt aber nur an den schlechten Karten und ist hoffentlich ein lösbares Problem. ;-) Touché. Im übrigen hab ich mal ein Beispiel fertig: http://wiki.openstreetmap.org/index.php/User:Henry_Loenwind/ACR Noch ohne die o.g. Änderungen. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Kreuzungsrelation
Henry Loenwind wrote: Im übrigen hab ich mal ein Beispiel fertig: http://wiki.openstreetmap.org/index.php/User:Henry_Loenwind/ACR Beispiel ist erweiteret (Autobahnkreuz) und der angepasste Text liegt jetzt auch da. Im übrigen habe ich nichts gegen Gegenvorschläge, die den gleichen Informationsgehalt transportieren können. Jedenfalls nicht, solange diese nicht für jeden Path eine Relation anlegen wollen. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwen den?
Garry wrote: Henry Loenwind schrieb: Und wenn ich eine Spezialanwendung habe, die mir die landwirtschaftlich genutzte Fläche eines Gebietes berechnet möchte ich keine Strassen mit in der Fläche haben. Und jetzt? Dann gesht Du zuerst her und trägst die cm-genau vermessenen Felder als Ebene 3 Objekt ein. Ebene 2 (landuse) für landwirtschaftliche Fläche ist da das falsche, denn es besagt ja nur, dass diese Fläche und Felder, Wiesen und Nebenflächen vorgesehen ist. Nebenflächen sind nur mal Hecken, Bäche, Pfade, Straßen etc. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] kan mir jemand bitte erklären wie man [EMAIL PROTECTED] zum rendern bringt
Johannes Kleine wrote: wartet. Bei der Meldung: Processing... Completed! Heißt das für mich soviel wie er ist fertig und macht nichts mehr. Stimmt ja auch. Der SVN-Client(!!!) sagt, dass er fertig ist. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Suche Mapper in Berlin für JOSM Einf ührung
Tobias Hägele wrote: Ich würde mich freuen, wenn mir mal jemand aus Berlin eine Einführungsstunde in JOSM geben würde. http://wiki.openstreetmap.org/index.php/Berlin/JOSM-Workshop cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Linienglättung, Beispiel
Tobias Wendorff wrote: Links mit 10 Nodes, rechts mit 45 Nodes. Gerendert mit osmarender. Auf jeden Fall die 45er Variante. Denn: Es ist trivial beim Datenexport die 45er in die 10er umzurechnen, umgekehrt ist es sehr schwierig und eine reine Raterei. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Hausnummern Höheninformationen
Tobias Wendorff wrote: Wieso die Höhendaten verwerfen, wenn ich sie eh per GPS-Gerät aufzeichne? Weil wir die Höhenangaben der guten GPSe nicht von denen der +/-50m-GPSe unterscheiden können. Und letztere sind nunmal in der Überzahl... Ausserdem sieht unser Datenmodel keine Punkte vor, die an der gleichen Stelle aber auf unterschiedlicher Höhe sind... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [Tilesathome] Cutover to new server? When?
Martijn van Oosterhout wrote: Err, what's wrong with the existing complexity measure which does exactly that. Well, it scales it to a number 0..15 but that's about it. I once had ma tah client patched to reject high complexity based on that number, I removed it when I found out that it was useless. There were c8 tiles my PC could not render, but c10 ones it could... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] ... NARF!
Jens Müller wrote: Eben. Und ich würde fast vermuten, daß man gegenwärtig die Server allein mit den Linux-Usern auslasten kann ... Den aktuellen Server bekommst Du sogar mit den paar wenigen Windows-Nutzern ausgelastet, die da teilnehmen g cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[OSM-talk] General tagging strategy
Hi talk, following the discussions on the mailing lists (mainly the German one g) it seems we aren't all on the same page about tagging. While OSM is set up as as open-for-everything in regard to tagging, i think we should find a common line about which tagging strategies are to be encouraged or discouraged. Or, which ones should be prioritized because they will provide the biggest gain for all usages of OSM data. Strategy 1: Legal status. (e.g. there's sign saying it's a cycleway) Strategy 2: Common usage. (e.g. people are riding their bikes there, even if it may be forbidden -or- even though it's allowed to ride a bike here, it is a really bad (suicidal) idea to do so) Strategy 3: Physical properties (e.g. gravel with a average corn size of 1/8th inch and an average of 3 bump holes between 2 and 4 inches in diameter and 1 to 2 inches deep per meter) Strategy 4: Interpreted usability (e.g. usability for bikes is 2 on a scale from 1 to 5) BTW: I did NOT make up these examples. Not even number 3. So what do you think? No follows my opinion: First of all we absolutely need #1, that is what people want to see on a all-purpose map, and this is what every routing applications must take into account. As the next step, #4 is the most useful. It is easy for both map painting applications and routing applications to take into account to deliver the little extra. While #3 could be used to generate the #4 data, that is not an easy task at all, neither is the tagging of that much details in the first place. While #2 looks interesting at first glance, most of that information can be extracted from #4 tags. Although I see the need for routing hints in the future, but that's another discussion to come. There may be applications for #3 data, but I don't see anything that could be in the Top10 of a OSM data consumer list. It is just to detailed to be useful for most applications. Just remember, humans are much better in interpreting complex data sets. cu Henry signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Cyclemap verbessern
PieSchie wrote: Das Thema speziellen Type für Fahrradwege hatten wir schon beim Thema Befahrbarkeit durch Skater. An dieser Stelle möchte ich vorschlagen, das verzuschlagene Tag nicht cycletype sondern usability:bike zu nennen. Und bei der Gelegenheit auch gleich usability:foot, usability:wheelchair, usability:snowmobile, usability:inlinescates, usability:buggy, etc. nach dem gleichen 1-5-Schema vorzuschlagen. (ggf. als Wert noch no vorschlagen, für Stellen wo einfach kein Durchkommen ist, access aber nicht greift (Zeichen 250.42: Verboten für Rollstühle aller Art? g)) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [patch] Breite von Flüssen XSL
Christian Koerner wrote: width - 9623 est_width - 489 est width - 68 width_est - 16 Also wenn est_width gekippt werden sollte, wäre es ganz nett, die vorhandene Information als width=xxx+width:source=estimated zu erhalten. Hat jemand Lust ein Proposal für *:source=estimated/meassured/* zu schreiben? cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Turn Restrictions
Frederik Ramm wrote: Turn-Restrictions auf. Was ist bei einer ganz normalen Kreuzung, also Straße1 läuft von N nach S und Straße2 von O nach W. Beide kreuzen sich an Kreuzung, gehen aber beide durch Kreuzung durch. Dann musst Du die Strassen an der Kreuzung aufteilen. Ich wuerde sogar dazu raten, das so zu machen, dass die Relation auch ohne Auslesen des Mmmh, wäre es nicht sinnvoll, *alle* Fahrmöglichkeiten einer Kreuzung zu erfassen, gleich mit der Angabe, welche Richtung ein Navi ansagen müsste? z.B.: type=crossing_layout 1=way 2=way 3=way 4=way 1_1=no 1_2=straight 1_3=half_right 1_4=right 2_1=straight 2_2=yes 2_3=sharp_left 2_4=no 3_1=straight 3_2=right 3_3=no 3_4=no 4_1=left 4_2=no 4_3=restricted(psv,bike) 4_4=maybe nur mal so als Idee in den Raum geworfen... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wo sind die Vorzeige-Orte in Deutschland?
Frederik Ramm wrote: fuer die State of the Map-Konferenz moechte ich ein paar Plakate drucken, auf denen ich besonders gute Kartenausschnitte aus Deutsch- land abbilde, um den anderen bei OSM zu zeigen, wie grossartig wir sind ;-) Wenn Du ein Vorher-Nachher Bild machen möchtest, hier war vor 8 Wochen noch gar nix, heute ist es eine brauchbare Karte: http://www.openstreetmap.org/?lat=49.34283lon=8.65628zoom=15layers=B00FT cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Heidelberger Schloss
Andreas Prieß wrote: ich kann nächste Woche mal in HD am Schloss ein wenig herumspazieren und dir den GPS-Track zukommen lassen. Das sollte helfen, das Schloss richtig zu positionieren. Danke. Wie gesagt, ein, zwei Punkte zum zurechtschieben reichen eigentlich. Wobei, wenn Du Lust hast, der Schloßgarten fehlt noch komplett ;) Nett wäre auch die Anbindung des Schlosswegs ans Schloss, aber das ist unter Umständen viel Gelaufe am Hang... Nicht dass das plötzlich in der Innenstadt rumsteht und den Verkehr aufhält - das würde mich auf Dauer auch etwas stören ;-) LOL cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Heidelberger Schloss
Hi, ich habe letztens mal das Heidelberger Schloss von historischen Plänen ( http://labs.metacarta.com/rectifier/rectify/362 ) hinzugefügt. Jetzt scheint das aber um ca 40m nach Süden verschoben zu sein - würde mich nicht wundern, da nach Luftbild rectified. Hat jemand zufällig einen GPS-Punkt (oder die Zeit welche zu machen), um das ganze korrektzurücken? Danke! Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relationen fuer gemeinsame Grenzen
Lars Kruse wrote: Unter http://wiki.openstreetmap.org/index.php/Relations/Proposed/Boundaries 2) Relationen aus den jeweiligen Grenzlinien erzeugen, wobei type=landuse, landuse=allotments und ein name-Wert die Attribute der Relation werden. Du verwechselt hier landuse mit Landesgrenzen. Selbst /wenn/ dieses Proposal irgendwann von irgendeiner Software unterstützt wird, werden Deine Kleingärten nicht gerendert werden... Und mal davon abgesehen, wenn wir jetzt anfangen Ways gemeinsem zu nutzen und sie per Relation zusammennähen, sind wir genau da, wo wir schonmal waren - als nämlich die Segmente abgeschafft wurden. Bitte nur Nodes gemeinsam nutzen, keine Ways. Also zuerst den einen Landuse-way einzeichnen, dann den zweiten und dabei immer schön auf die schon vorhandenen Nodes klicken. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tagging für Auffahrten, Kreisverkeh ren, Kreuzungen
Hi, offiziell gibt es nicht. Aber hier mal ein paar Empfehlungen: Dominik Spies wrote: Wie taggt man korrekt z.B. eine kreuzungsfreie Auffahrt auf eine Bundesstraße oder Staatsstraße? Einfach als primary oder secondary? Die Nodes gar nicht, die Ways der durchgehenden Straße ganz normal, die Ways der verbindenden Straßenstücke mit highway=primary_link bzw. highway=secondary_link. Welche ref ist dann anzugeben? Gar keine? Die der zugehörigen Straßen? Wenn das Straßenbauamt Schilder (bzw. diese Dreiecksteile) aufgestellt hat, danach taggen und eine Note setzen, dass man es gemacht hat (damit es niemand kaputtkorrigiert). Ansonsten die Links mit der ref der Straße taggen, auf die sie führen. (Das hilft dem Router die Abbiegestellen hilfreich anzusagen. Hinweis: Die Parallelfahrspur führt auf die gleiche Straße, von der sie kommt, auch wenn sie mal ausnahmsweise nicht so gebaut wurde.) Was ist wenn es eine Auffahrt von einer B auf eine andere B ist? welche ref? beide? s.o. Was ist bei Kreisverkehren? Im Endeffekt gleiche Problematik. highway=wasauchimmer, junction=roundabout, name=Name der Straße zu der der Kreisverkehr gehört. Im Detail: Wenn alle Straßen am Kreisverkehr enden: highway auf den der am höchsten klassifizierten Straße (ggf, _link!) setzen. Kreisverkehr bekommt keinen Namen und keine ref. Kreisverkehr ist eine eigene Straße mit eigenem Straßennamen: Klar, oder? Eine Straße führt durch den Kreisverkehr: Kreisverkehr taggen wie diese Straße, nur eben junction=roundabout zusätzlich. ich füge überregionale Straßen mit ref nun immer einer route=road hinzu. Sollen Auffahrten und/oder Kreisverkehre auch dazu? Kreisverkehre auf jeden Fall dann, wenn die Straße durchführt. Was ist eigentlich wenn 2 Staatsstraßen auf der selben Straße verlaufen? z.B. St 2111 und St 2141 in Mengkofen. Oft kommt das ja auch bei Staats-und Kreisstraßen auf. Soll man hier ein ref=St 1234;DGF 123 setzen? Oder hat eine Straße immer nur eine Referenz? Wie ist das offiziell? ref=St 1234;DGF 123 ist richtig - auch wenn das im Moment noch kein Renderer richtig rendert. cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse= layer=-2 ?
Martin Koppenhoefer wrote: naja, wie machst Du es, wenn Du eine mehrstöckige Landschaft hast? Dasist wohl nicht die Regel, kommt aber gelegentlich vor, z.B. hier:http://de.wikipedia.org/wiki/Bild:Expo2000_nl.jpg Das ist keine mehrstöckige Landschaft, das ist einfach ein Gebäude. Also building=yes, usage=insane ;) Aber ein wirkliches Problem sind Tiefgaragen, wie taggen wir die? tunnel=yes? (Das wäre zumindest wie ich es rendern würde.) cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse= layer=-2 ?
PS: Ich hätte wohl erst die anderen ungelesenen Mails ansehen sollen... OOOPS... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Fwd: AW: Nutzung von Luftbildern in OpenStreetMap
Sven Geggus wrote: Es gilt rechtlich zu klären, ob das Urheberrecht überhaupt derart weit reicht. Dass die Menschen von den Ämtern da erst mal vorsogrlich Das Problem ist ja, dass sie keine Rechte auf die von uns erzeugten Daten beanspruchen, sondern wir nach deren Lizenz die Luftbilder erst gar nicht vom Server ziehen dürfen, wenn wir sie für ...[irgendwas anderes als privates Anschauen]... nutzen wollen. Also der gleich Sch..., wie das was ich im Moment auf Arbeit hab - die Software, an der ich programmiere steht (viral) unter GPL, aber meine arbeitsvertragliche Weisungsgebundenheit verhindert, dass ich sie ins Netz stelle... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
