Re: [Talk-de] Häuser richtig oder hübsch zeichnen?
Am 13.12.2012 07:51, schrieb Peter Wendorff: Hallo Gerrit. Ich würde mich Martin und Frederik anschließen: Das eintragen, was da ist. Ecken und Kanten machen doch eine Stadt erst aus. Wenn alles gerade in einer Linie gebaut ist, sieht das entweder nach amerikanischem Hochglanzkino aus oder aber nach Sim City und Co. Ob die Karte, die man daraus erzeugt, wirklich schöner aussieht, sei dahingestellt; eine 3D-Darstellung wird dadurch langweiliger - und könnte genausogut automatisch generiert werden ohne osm-datengrundlage. Gruß Peter Mir ist das z.B. hier aufgefallen: http://www.openstreetmap.org/?lat=51.593209lon=7.665389zoom=18layers=M (Rund um die Lutherkirche) Meiner Meinung nach sieht das in vielen Fällen einfach unglaublich schlecht aus. Um solche Fälle ging es mir. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Häuser richtig oder hübsch zeichnen?
Hallo, da ich jetzt mal einige Häuser bei mir in der Stadt eingetragen habe, bin ich über folgendes Problem gestoßen: Wenn ich die Sachen von Bing Maps abzeichne, sind ja manche Häuser etwas schräg zur Straße, andere etwas versetzt zu den anderen Häusern usw. Im Grunde sieht es aber in der Straße doch schon gleichmäßig aus. Nur in OSM hat man dann bei einfachem Abzeichnen doch eher ziemlich unruhige Straßenzüge. Deswegen wollt ich fragen, ob es besser ist, solche kleinen Unregelmäßigkeiten zu ignorieren und einen Straßenzug recht gleichmäßig einzutragen, oder das alles wirklich genau wie in der Wirklichkeit zu machen? Danke! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Häuser richtig oder hübsch zeichnen?
Am 12.12.2012 20:16, schrieb Alexander Lehner: Ich arbeite zur Zeit auch gerade viel mit den Haeusern aus bing und kenne das Problem. Die Georeferenzierung der bing-Bilder ist auch nicht besser als der Weg daneben, den irgendein Mapper eingetragen hat (meistens zumindest). Ich erlaube mir deshalb, in solchen Faellen einen gewissen Trade-Off einzubauen, sowohl beim Weg als auch beim Haus. Manchmal hat jemand einen Weg grob eingezeichnet, der ganz offensichtlich durch eine Reihe Haeuser geht. Da lege ich z.B. etwas Hand an. Dann wieder sind die bing-Bilder um ein paar Meter versetzt, relativ zum Wegenetz, da verschiebe ich dann die Haeuser ein bisschen. Ortskenntnisse sind hier natuerlich von Vorteil, ggf. Kontakt zum Mapper des betroffenen Wegs und eine gesunde Einschaetzung der Qualitaet der vorhandenen Daten. Ich finde es am wichtigsten, dass bei einer Navigation das Gesamtbild der Umgebung mit dem zu korrelieren ist, was auf dem Display zu sehen ist. bing hat 'die Wirklichkeit' ja auch nicht gepachtet ;) Meine Meinung... A. Hm, das Problem ist nicht einmal, das Bing falsch wäre (Zumindest scheint es mir nicht so), sondern dass auch in Wirklichkeit die Häuser nicht 100%ig „hübsch“ nebeneinander stellen. Oft ist es ja so, dass in einem Reihenhauskomplex ein Haus ein paar Meter nach hinten verschoben ist. Oder dass die Häuser an sich etwas schräg zur Straße stehen. Das ist auf dem Luftbild auch zu sehen, und wenn man das Luftbild abzeichnet, sieht es bei OSM nachher auch so aus. Allerdings wirkt das ganze Straßenbild eben nicht so chaotisch, wenn man sich wirklich in der Straße aufhält: Da sieht es eigentlich schon so aus, als ob die Häuser alle parallel zur Straße stehen würden, auch wenn es eben in Wirklichkeit nicht so ist. Nur fällt das nicht auf. Jetzt ist mein Problem halt, ob man das wirklich 100%ig richtig zeichnen soll, oder ob es eben auf der Karte etwas „hübscher“ wirken soll. Ich glaube, ich werde da doch aber lieber dazu tendieren, das ganze grafisch etwas aufzupolieren. Sonst sieht es wirklich schlecht aus. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karten für S/W-Druck aufbereiten
Hallo, ich möchte gerne eine OSM-Karte in ein selbst gemachtes Buch von mir einfügen. Da das nur in S/W ist, sollte die Karte dann natürlich auch nur S/W werden. Einfach nur bei OSM auf Drucken gehen sieht natürlich sehr schlecht aus. Hat jemand Tipps, wie ich sowas am besten angehen kann? Oder gibt es eventuell sogar Programme, wo ich einzelne Elemente ausblenden kann, und ich so nach meinem belieben die Karte anpassen kann? Danke! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karten für S/W-Druck aufbereiten
Am 10.12.2012 20:57, schrieb Juergen Fenn: Das Feature sollte standardmäßig in OSM vorhanden sein, damit die Ausgabe auf SW-Druckern endlich auch besser wird. Die meisten Stadtpläne sind leider unbrauchbar, so daß ich mir am Ende dann doch immer wieder Pläne von Google Maps für unterwegs ausdrucken muß. Das habe ich auch gemerkt, als ich mir für den Urlaub was ausgedruckt habe. Diese Flächenbeschriftungen für Wohngebiete, Felder usw. sind ja ganz nett, allerdings stören sie unglaublich beim Ausdruck. Ein grün oder braun sieht dann eben nicht mehr wie grün aus, sondern wie irgendetwas komisches. Da würde mir kein Hintergrund besser gefallen. Auch könnte der Ausdruck allgemein höher aufgelöst sein: Man kann zwar im Druck nicht zoomen, aber dafür könnte man mehrere Zoomstufen in einem vereinen, da ein Drucker eine höhere Auflösung hat. Das würde dann z.B. bedeuten, dass vielleicht schon in der dritthöchsten Zoomstufe die Hausnummern angezeigt werden könnten. @Frederik, Max und Alexander: Danke für die Vorschläge. Einiges sieht ja ganz gut aus, ich werd mir das mal alles genauer anschauen. Mich würd das vor allem sowieso für kleinere Stadtpläne o.ä. interessieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 03.12.2012 02:38, schrieb Stephan Knauss: Das würde zumindest das Problem lösen dass manche Zeichen aus dem Unifont einfach hässlich sind. Und der Mix aus asiatischen Glyphen und arabischen Ziffern (kommt zumindest in TH sehr häufig vor) wäre auch kein Problem mehr. Ich bin aber kein Font-Experte. Die Lizenz des Fonts müsste das Mischen dann auch zulassen. Wenn sich das jemand zutraut, ein gewisser Bedarf ist sicher da. Alternative wäre eine Unterstützung in Mapnik für das Rendering abhänging von einem bounding polygon. So wie sich die Diskussion entwickelt will man ja abhängig von der Position teilweise unterschiedliche Fonts, eventuell unterschiedliche Größen und dann auch noch unterschiedliche Queries auf die zu verwendenden name-tags haben. Soll das alles in der Postgres query stattfinden? Oder geht es performanter in mapnik? Stephan Ich möchte nur mal einige Probleme eines zusammengemischten Fonts ausführen: 1. Das Problem China/Taiwan/Korea/Japan - Ich möchte da wirklich Wert drauf legen, weil das unglaublich störend ist. 2. Was ist, wenn sich eine bestimmte Unter-Schriftart mal weiterentwickelt (Besseres Hinting, größerer Zeichenumfang, andere Verbesserungen)? Dann muss die komplette Gesamtschriftart neu zusammengefügt werden. Das würde natürlich darin enden, dass das niemals passieren wird. Bei einer vernünftigen Lösung müsste einfach nur die Datei der russischen/thailändischen/arabischen Schriftart ausgetauscht werden. Ich sehe wirklich kein Problem, die Schriftartenauswahl basierend auf den name-Tags auszuführen. Es sind bereits alle Informationen da: bei name:th wird eine thailändische Schriftart benutzt, bei name:ar eine arabische, bei name:ja eine japanische. Was soll man mehr? Das einzige Problem besteht darin, eine Schriftart für den allgemeinen name-Tag zu verwenden, aber das kann doch abhängig von der Position des nodes gelöst werden. Es lässt sich doch für jeden node herausfinden, in welchem Land er sich befindet, oder nicht? Die Ländergrenzen sind doch alle eingetragen. Natürlich ist das etwas Programmieraufwand, aber so etwas ist wesentlich konsistenter, nachhaltiger und kein dirty hack. Notfalls könnte man ja auch eine Kickstarter-Kampagne aufmachen. Ich z.B. wäre gerne bereit, für eine vernünftige Typographie in OSM auch Geld zu bezahlen. Typographie ist kein „Nebenprodukt“, sondern es verbessert die Lesbarkeit (auch bei einer lateinischen Schriftart) und gehört zu einer guten Kartendarstellung genau so, wie der Rest. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 03.12.2012 12:13, schrieb Henning Scholland: Bei name:*=* ist das eindeutig. Aber woher willst du wissen, was in name=* steht? Landesgrenzen werden erstmal viele Fehler verursachen. Naja, aber sowas lässt sich doch korrigieren. Du hast es doch selbst gesagt: „erstmal“. Aber wo genau verursacht das denn Fehler (Es sei denn, das Gebiet liegt jetzt in einem politisch umstrittenen Gebiet, wie z.B. Kaschmir oder die Sentaku-/Diaoyutai-Inseln o.ä.)? Die Ländergrenzen sind doch in OSM schon alle fertig. In einem mehrsprachigen Gebiet gibt es natürlich einige Fehler, aber da könnte man immer noch mit einer Prioritäten-Liste durchgehen. In der Schweiz ist es eh kein Problem, weil Deutsch und Französisch usw. alle das gleiche Alphabet benutzen. In Israel stellt man dann zuerst eine hebräische Schriftart ein, danach eine Arabische. Also werden zuerst die Zeichen aus der ersten Schriftart gesucht, und falls dort nicht existent, aus der Zweiten. Das ergibt dann ja maximal bei den Satzzeichen Probleme. Und für alle weiteren Sachen sind ja eben genau diese Länderkennungen in den Tags richtig. Ich denke, diese mehrsprachige Auswahl sollte dann ja in Zukunft sowieso soweit gehen, dass OSM dem Ländercode des Browsers entsprechend die Karte anzeigt: Bei einem hebräischen Browser wird in Israel dann alles auf Hebräisch angezeigt, bei einem arabischen auf Arabisch, bei einem deutschen/englischen o.ä. dann in Umschrift (+ vielleicht noch die Originalsprache). Gerade die mehrsprachigen Länder benutzen doch im Moment auch schon relativ konsequent die Sprachtags, so dass eine Auswertung dort einfach vorgenommen werden kann. Und bei allen einsprachigen Ländern ergibt sich doch kein großes Problem, da die Sprache dann ja aus dem Land heraus gewählt werden kann. Natürlich wird das vielleicht in einigen Fällen Ungereimtheiten ergeben, aber wenn das System erst einmal steht, wird wohl jeder solche kleineren Fehler im Tagging korrigieren. Ich finde, man sollte dort lieber das System vernünftig einrichten, ohne auf alle möglichen Zweifelsfälle Rücksicht zu nehmen. Stattdessen sollten die inkonsistent benannten Einträge vernünftig getaggt werden. Das ist doch wesentlich besser für die Zukunft. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 01.12.2012 18:56, schrieb Max: SIL International Fonts http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiid=FontDownloads GNU FreeFont „FreeFont contains large selection of characters from other writing systems, some of which are hard to find elsewhere.“ http://www.gnu.org/software/freefont/ Ich will mich nur noch mal wiederholen: Diese Schriften sind unglaublich hässlich, sehr schlecht zu lesen, und im Grunde eine Beleidigung an jede typographische Entwicklung. Ohne es mir jetzt genauer angeschaut zu haben, scheint die Free Font auch nicht gerade gut zu sein. Die meisten guten Schriftarten sind nur auf einen kleinen Bereich spezialisiert. Normalerweise ist die Devise: „Je mehr Zeichen unterstützt, desto schlechter die einzelne Qualität“. Die SIL-Fonts haben auch nichts für Chinesisch. Muss für OSM eigentlich unbedingt eine komplett freie Schriftart benutzt werden, oder tut es auch eine einfache kostenlose? Ich habe ein bißchen herumgeschaut, und im Schriftartbereich bietet Open Source einfach nicht die Qualität, die man haben möchte. Ansonsten würde ich vorschlagen, da für jede Sprache wirklich mal die entsprechenden Landeslisten zu kontaktieren. Die Leute dort werden das noch halbwegs am besten wissen. Ich glaube kaum, dass wir hier als Deutsche ausreichend für arabische, Devanagari- oder thailändische Typographie qualifiziert sind. Am 02.12.2012 15:15, schrieb Sven Geggus: Hm, stelle ich mir das jetzt zu einfach vor wenn ich mir einfach denke wir könnten uns einen speziellen OSM-Karten-Font bauen indem wir einfach die richtigen Unicodezeichen (größe und Typ) alle in eine einzige OSM-Kerten-Font Datei mergen? Auch hier möchte ich mein Problem mit den unterschiedlichen Schriftarten für Japanisch und Chinesisch (China/Singapur und Taiwan/HK/Macao) und Koreanisch betonen: Ein zusammenmischen aller Schriftarten in ein Font funktioniert nicht. Ich bin hier sehr dafür, direkt eine anständige Schrift-Auswahlmethode im Renderer zu entwickeln. Ich würde mein Problem jetzt auch nicht als kleines Problem abtun, das betrifft immerhin knapp 150 Millionen Leute. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 02.12.2012 20:17, schrieb Martin Koppenhoefer: bei Mapnik ist es kein Problem, unterschiedliche Schriftarten einzubinden, die Herausforderung ist die Entscheidung, welchen Font für welche Sprache/Schrift man nimmt. Naja, das Problem sehe ich nicht unbedingt: Unter den zigtausend verfügbaren die am besten lesbare. Ich denke, das Hauptproblem wird eher sein, überhaupt irgendeine gute zu finden. Das Luxusproblem, zu viele zur Verfügung zu haben, wird es wohl kaum geben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 01.12.2012 10:53, schrieb Stephan Knauss: Ich vermute mal du verwendest die Font Kombination wie der offizielle Style mit DejaVu/Unifont. Da kommt dann alles was was latin-1 ist (auch die Ziffern) aus dem Vector Font DejaVu. Die restlichen Glyphen kommen aus dem Unifont als Bitmap. Das skaliert auch nicht so schön. Und die Größen der einzelnen Zeichen passen auch nicht zusammen. Wie ist es denn bei Chinesisch/Koreanisch? Sind da die kleinen Zeichen für Muttersprachler noch lesbar? Mapnik dreht dort die Zeichen ja auch auf den Straßenverlauf. Ist das so üblich, oder sollten die Zeichen immer aufrecht stehen? Wäre dann auch noch ein wichtiger Punkt für die asiatischen Sprachen. Welche Version von Mapnik verwendest du denn? Harfbuzz oder die letze offizielle? Stephan Also für Chinesisch und Japanisch kann ich zumindest sagen, dass die Schriftart unglaublich hässlich ist. Besonders das fehlende Hinting macht die Schrift unglaublich schlecht zu lesen. Leider gibt es aber nur sehr sehr wenige freie Schriftarten für die Sprachen, da die einfach so aufwendig zu machen sind. Dann noch eine freie Schriftart in guter Qualität zu finden ist fast ein Ding der Unmöglichkeit. Tendenziell sind kleine Zeichen aber für Muttersprachler noch lesbar. Es ist da nur wichtig, dass die Sachen gut gehinted werden. Das ist imho das Hauptproblem gerade bei den OSM-Sachen. Am 01.12.2012 11:04, schrieb Jochen Topf: Kann man das dann nicht im Font anpassen? Also einen neuen Font basteln, der die Zeichen aus DejaVu und Unfont enthält, aber die Thai-Zeichen halt 20% größer? Ich hab keine Ahnung, wie die Fonts intern funktionieren. Also wenn da jemand was macht, bin ich gerne bereit auf der Karte mit verschiedenen Fonts oder so zu experimentieren. Aber mehr kann ich halt auch nicht machen. Also ich würde das hier eher, wie es auch bei HTML funktioniert, mit den Sprachtags machen. Also dass für eine andere Sprache eine andere Schriftart genommen wird, anstatt alles in eine Schriftart zu quetschen. Das würde meine Sache mit Japanisch und Chinesisch möglich machen und wäre sicherlich auch einfacher zu warten. In HTML benutzt der Browser einfach je nach lang-Tag eine andere Schriftart. So etwas wäre in OSM auch am besten. Die name-tags sind doch schon vorhanden, die kann man doch für sowas prima nutzen. Wenn da name:th steht, wird einfach eine thailändische Schriftart genommen. Ich kann mir gar nicht vorstellen, dass es so schwierig ist, dem Renderer zu sagen, dass er bei jedem name:th einfach eine thailändische Schriftart nehmen soll. Ohne mich jetzt irgendwie aus dem Fenster lehnen zu wollen, aber ich glaube, das könnte sogar ich mit meinen allerwenigsten Programmierkenntnissen: if name==th font = thailändische Schriftart end if Oder nicht? Am 01.12.2012 08:28, schrieb Andreas Labres: Sorry, aber ich find's widersinnig, name:en=Aachen oder name:fr=Munich (das ist doch die engl. Sprache?) einzutragen. Entweder gibt's einen Namen in der jeweiligen Sprache (Wien|Vienna|Vienne|Wenen|Beč|Bécs|Viyana|..., vlg. http://www.openstreetmap.org/browse/node/17328659), aber wenn nicht, dann nicht. Speziell macht Irgendwasdorf als name:en|fr|... keinen Sinn. Naja, mein Beispiel war da jetzt etwas blöd, das stimmt. Fälle wie Aachen auf Englisch sollte man doch eher leer lassen. Mein Beispiel sollte dann eher name name:de name:en name:fr name:ja Berlin Berlin oder (leer) (leer) (leer) ベルリン München München oder (leer) Munich Munich ミュンヘン Aachen Aachen oder (leer) (leer) Aix-la-Chapelle アーヘン Roma Rom Rome Rome ... ローマ 東京 Tokio Tokyo Tokyo 東京 oder (leer) sein. So könnte man das dann gezielt eintragen. Ich habe gestern mal versucht, mit dem Overpass-Dingen und JOSM mehrere Städte in Taiwan zu ergänzen. Ohne eine tabellarische Ansicht ist es meiner Meinung nach unmöglich, viele Einträge lückenlos und in vertretbarem Zeitaufwand einzutragen. Man muss zuerst jeden Node auf der Karte suchen, ihn anklicken, in dem Eigenschaften-Feld auf Hinzufügen klicken, das entsprechende name:xyz-Feld heraussuchen, dann eintippen, dann wieder auf ok drücken, dann das nächste Node anklicken Das ist wirklich unmöglich. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 01.12.2012 13:09, schrieb Andreas Labres: Interessant wäre auch die Frage, wie man eigentlich sagen soll diese name Tags sind deutschsprachig? Also wenn jemand z.B. eine Karte en(de) will, dass dann eben Munich (München) dort steht, obwohl es den name:de Tag vielleicht nicht gibt. Oder sollte man für alle Orte in DE, AT und CH (dt.) ein name:de setzen wollen? Vielleicht ein konkretes Beispiel: http://www.openstreetmap.org/browse/node/240092464 hat einen name und einen name:ru Tag. Wie weiss der Renderer, was er für ru(de) hinschreiben soll? Naja, ich glaube, gängiger Konsens ist ja bislang, dass die Landessprache eben nicht besonders gekennzeichnet wird: name steht in Deutschland automatisch für name:de in England für name:en in Russland für name:ru usw. (wird dann vielleicht schwer in zweisprachigen Ländern, aber normalerweise klappt es) D.h., dass wenn es kein name:de gibt, dann das name genommen wird, solange sich der Ort in Deutschland (oder AT/CH) befindet. Das lässt sich doch aktuell schon gut bewerkstelligen, indem man einfach en|de_ (denke ich) schreibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 01.12.2012 12:32, schrieb Falk Zscheile: In welchem Format muss die Schrift denn vorliegen, ggf. könnte man sich einmal in der LaTeX-Welt umschauen. Dort sollten sich eigentlich ansehnliche Schriften finden ... Naja, Truetype passt schon. Ich glaub ich muss hier mal Hinting etwas erläutern: Dort werden für kleinere Schriftgrößen die Buchstaben absichtlich weniger detailliert gemacht, und anschließend als Bitmap in die Schriftart gespeichert. D.h. dann, wenn der Buchstabe z.B. in Schriftgröße 8 ist, wird das entsprechende Bitmap geladen. Falls die Schriftgröße allerdings 9 ist, wird entweder kein Bitmap geladen (dann sieht es hässlich aus), oder wiederrum ein anderes Bild. Das ist im Grunde genau das gleiche Problem, wie bei OSM: Dort gibt es ja für die verschiedenen Zoomstufen auch immer verschiedene Darstellungen, und je weiter man hineinzoom, desto detaillierter wird es. Würde man in der weitesten Zoomstufe alle Straßen anzeigen, wäre das Bild hoffnungslos überfüllt. Naja, jedenfalls ist der Vorgang halt sehr aufwendig. Deswegen gibt es ihn bei vielen kostenlosen Schriftarten nicht. Soweit ich weiß, gibt es in der Latex-Welt jetzt auch nichts besseres. Das Problem ist ja auch, dass Latex für den Druck ist, aber hier werden Bildschirm-Schriften gesucht. Ich kann mal zumindest für meinen Themenbereich (Japanisch und Chinesisch) nach einigen Schriften suchen, und ich werde auch mal im japanischen OSM-Talk nachfragen. Das Problem ist nur, dass alle guten (kostenlosen) Schriftarten, die ich für Japanisch kenne, nur lizensiert sind: Von MS, von Adobe oder von Epson. Bei Chinesisch sieht es zumindest etwas besser aus, aber da muss ich auch noch mal schauen. Zu Thailändisch o.ä. kann ich jetzt leider nichts sagen, da ich mich damit nicht auskenne. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 01.12.2012 13:42, schrieb Simon Poole: Die (mehrsprachige Länder) sind häufiger als du denkst: http://www.aufenthaltstitel.de/amtssprachen.html würde auf ~60 Länder mit mindestens 2 Amtssprachen hinweisen und sicher noch mehr mit mehr als eine gebräuchliche Sprache. Mir wäre so als ob die CH 4-sprachig ist :-) . Tatsächlich, hab ich jetzt gar nicht dran gedacht :D Aber das kann man da ja auch mit Regionen lösen. Ansonsten werden die meisten mehrsprachigen Länder wohl bereits jetzt schon richtig getaggt sein, so dass sich da gar kein Problem ergibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 30.11.2012 15:38, schrieb Jochen Topf: Ich arbeite an einer mehrsprachigen Karte, also einer Karte auf der Du, der User, einstellen kannst, in welcher Sprache die Namen erscheinen sollen. Unter http://mlm.jochentopf.com/ gibts jetzt eine Demo. Die Tiles für diese Demo werden auf tile.openstreetmap.de gerechnet als Software kommt der Mapquest Render Stack mit einigen Änderungen von mir zu Einsatz. Du kannst jede beliebige Sprache oder Sprachkombination auswählen. Dies ist nur eine Demo-Seite, sie kann manchmal langsam sein oder auch garnicht funktionieren. Probierts aus und sagt mir, was Euch gefällt und was Euch nicht gefällt. Mehr über dieses Projekt unter http://wiki.openstreetmap.org/wiki/Multilingual_maps_Wikipedia_project Jochen Wow, echt super. So etwas habe ich mir schon immer für OSM gewünscht (und es sogar mal als Vorschlag geschrieben). Da muss ich dir wirklich aus vollstem Herzen meinen Dank aussprechen. Da jetzt die Beschriftungen ja anscheinend dynamisch generiert werden, hätte ich aber direkt einen Vorschlag (beim normalen OSM ist das leider auf taube Ohren gestoßen): Einige Sprachen würden besser mit einer anderen Schriftart aussehen. Ich sehe das im Moment für den Raum Japan, Korea, Taiwan, China: Die normale OSM-Schrift hat dort nur chinesische Zeichen, was das ganze in Japan etwas hässlich macht (Das Problem jetzt genauer auszuführen ist etwas schwierig, aber es sieht wirklich hässlich aus :D Wer interesse hat, hier ist ein ausführlicher Wikipedia-Artikel zu dem Problem http://de.wikipedia.org/wiki/Han-Vereinheitlichung). Naja, jedenfalls, wäre es vielleicht möglich, bei dem name:ja-Feld eine japanische Schriftart zu benutzen und bei name:ko eine koreanische? Für Chinesisch müsste ich noch mal gucken, das ist vielleicht name:zh-TW und name:zh-CN, aber da muss ich noch mal recherchieren. Aber das „wichtigste“ ist im Grunde erst einmal name:ja. Wäre das vielleicht möglich? Ich würde mal nach einer guten Open-Source-Schriftart für Japanisch suchen, falls Möglichkeit an Umsetzung besteht. Gruß, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 30.11.2012 18:18, schrieb Jochen Topf: Abhängig davon, welches name:*-Tag verwendet wurde, die Schriftart anders zu setzen, wäre sehr aufwändig. Dazu müßte man komplett neue Styles und Layer für jede Sprache anlegen. Das kostet viel Aufwand in der Pflege der Styles und Aufwand beim Rendern. Wenn man sowas machen will, dann müßte man den Mapnik erweitern, dass Fonts dynamisch anhand von Daten aus der Datenbank gesetzt werden können oder sowas. Wobei man dann immernoch im Datenbank-Query irgendwie rausfinden muss, welcher Font denn nun zum Einsatz kommen soll. Das erscheint mir recht schwierig bzw. aufwändig umzusetzen. Wenn es nicht abhängig vom Tag entschieden werden muss, sondern nur anhand der Unicode-Zeichen, dann wäre das machbar. Im Moment verwende ich den Deja Vu Font und wenn der ein Zeichen nicht hat den Unifont. Da könnte man schon z.B. einen dritten Font dazwischen tun, der für bestimmte Zeichen, die in Deja Vu nicht sind und die in Unifont nicht gut aussehen, bessere Glyphen hat. Jochen'吃 Hallo, hm, schade... Naja, gut, anscheinend lässt sich das dann nicht in deiner Software angehen, sondern beim Renderer (Leider scheint da niemand Interesse an dem Problem zu haben. Deswegen dachte ich, dass ich es direkt bei dir versuche :D). Also im Grunde ist das Problem (vom Gedankengang her) relativ einfach: name:ja - Japanische Schriftart name, falls in Japan (Kann man ja anhand der Ländergrenze herausfinden): Japanische Schriftart. Das ist eigentlich alles. Das Problem ist leider, dass es eben nicht anhand der Unicode-Werte funktioniert, da dort ein einzelnes Zeichen praktisch doppelt belegt ist. Man kann sich das so vorstellen, als ob wir hier in Deutschland gerne alle Städtenamen in Frakturschrift geschrieben hätten. Aber da es eben nur eine andere Schriftart ist, mit den gleichen Codepunkten, lässt sich das nicht einfach nur anhand einer Reihenfolge heraussuchen. In manchen Ländern würde man gerne eine Schriftart verwenden, in den anderen eine andere. Naja, gut, aber ich habe jetzt die Methodik deiner Software etwas falsch verstanden, deswegen hatte ich dich da jetzt gefragt. Du kannst da wohl leider nichts machen. Naja, muss ich halt wieder hoffen, dass da irgendwann mal etwas passieren könnte. Trotzdem danke! Und die Software ist wirklich super, ich hoffe, das findet irgendwann vielleicht mal Eingang in den die normale OSM-Webseite. Was allgemein jetzt praktisch wäre: Eine tabellarische Auflistung aller Regionen, Städte, Stadtteile usw. in einem Land, in der verschiedene Sprachvarianten aufgelistet werden. Z.B. so etwas: Stadt (name) Deutsch (name:de) Englisch (name:en) Französisch (name:fr) Berlin Berlin Berlin Berlin München München Munich Munich Aachen Aachen Aachen Aix-la-Chapelle Wo man dann einfach die gesamte Tabelle abarbeiten und fehlende Sprachen ergänzen könnte. Dieses würde dann automatisch in die entsprechenden nodes eingetragen werden. Ich glaube, wenn man so etwas nicht hat, ist es unglaublich schwierig, wenn nicht sogar unmöglich, verschiedene Sprachversionen wirklich umfassend einzutragen. Gruß, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 30.11.2012 21:20, schrieb Kolossos: Das einigen Schriften wie z.B. das Koreanische[1] zu klein sind ist uns auch schon aufgefallen. Damit die Schriftgröße aber immer zur Karte passt, würde ich aber später lieber die Option anbieten alles in doppelter Größe zu rendern. Diese hat auch Vorteile im Ausdruck, auf diesen neumodische Retina/HiRes-Displays und ist sicher auch gut für Leute mit Sehschwäche. Rein technische sind das 3 Zeilen Code, es erzeugt aber mehr Serverlast und Traffic. Frederik hatte das schonmal getestet. Hier ist ja auch die Sache, dass man zwar vielleicht als Kundiger der Sprache zwar auch das fremde Alphabet lesen kann, aber es vielleicht noch nicht so gut kann, so dass man gerne die Schrift etwas größer haben möchte. Ich weiß zumindest von Chinesisch und Japanisch dass es auch sehr klein eigentlich noch lesbar ist. Allerdings ergibt sich da auch das Problem, dass im Normalfall die Schrift gehintet ist - und das ist bei OSM dann nicht der Fall. Ich habe hier mal einen Vergleich hochgeladen: http://www.abload.de/img/vergleichdwomu.png Wie man sieht, sind bei OSM die Zeichen ein bißchen zu „detailliert“ und nicht klar genug, so dass da alles zu einem schwarzen Block zusammenfällt. Ich glaube, da müsste man erst einmal ansetzen. Hier ist allerdings auch die Sache, dass wenn man das Zeichen bereits kennt, man es nicht unbedingt größer braucht. Wenn es unbekannt ist, möchte man es allerdings vielleicht eher nachschauen (Aber das Problem halte ich nur für minimalst wichtig). Die Unterstützung für Retina-Displays ist übrigens ein sehr guter Punkt. Ich hoffe ja immer noch, dass so etwas in einigen Jahren auch abseits von Apple Standard sein wird, und bin deshalb sehr dafür, sowas schon jetzt zu unterstützen. Zum Übersetzen braucht es halt echt viele Leute. Als ganz gute Vorgehensweise neben Tools wie Add-tags könnte ich folgendes empfehlen, wenn man z.B. Städte in einem bestimmten Bereich in eine bestimmte Sprache übersetzen will: *Sich die Städte-nodes über eine Overpass-Anfrage[2] in JOSM laden. Ich wollte das machen, allerdings ist bei dir nur localhost verlinkt. Kannst du das eventuell etwas genauer erläutern? Ich würde gerne _alle_ Städte aus einem ganzen Land laden, und die dann alle in einem Rutsch übersetzen. Ich denke allerdings immer noch, dass eine tabellarische Auflistung sehr praktisch wäre. Dann muss man nicht in jedes Node einzeln öffnen, sondern könnte einfach mit Cursor-unten in den nächsten Datensatz gehen. Sowas ist imho besonders nützlich, wenn man fremde Alphabete transkribiert, weil man dort ja wirklich _jeden_ Eintrag ergänzen muss. Sowas wäre als JOSM-Plugin eigentlich doch echt eine Idee wert, oder? Alternativ auch als Web-Anwendung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrsprachige Karte jetzt noch flexibler...
Am 30.11.2012 22:24, schrieb Jochen Topf: Man muss jetzt explizit angeben, ob man auf den name-Tag zurückfallen will oder nicht. Dazu gibt es den Unterstrich (_) als Bezeichner. Mit de bekommt man jetzt also nur noch den name:de-Tag. Mit de,_ bekommt man name:de oder wenn der nicht existiert name. Hier ergeben sich jetzt einige Probleme, wenn der Sprachen-Tag noch weiter mit einem Unterstrich unterteilt ist. Ich merke das gerade an ja_kana. Das funktioniert jetzt nämlich leider nicht mehr so wie es soll. Also im Moment sieht es so aus: ja_kana - das name-Feld wird angezeigt - falsch, es sollte eigentlich ja_kana angezeigt werden. ja|ja_kana - ja (ja_kana) wird angezeigt - Das stimmt. Danke für die zweisprachige Unterstützung. Das ist so eine unglaubliche Bereicherung für OSM, das kann ich gar nicht in Worte fassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Große Karte rendern ohne Zoom-Angabe
Hi. Ich würde gerne ein Image aus OSM-Daten rendern (zur Weiterverwendung im GIS). Dazu möchte ich gerne dem Renderer eine Boundingbox (lat/lon) mitgeben, sowie eine Zielgröße für das Bild (z.B. 5000px x 5000px). Ich finde nur Lösungen, die die Angabe eines Zoomlevels erfordern. Kann mich jemand in die Richtige Richtung weisen und ein Tool empfehlen? Ich habe aktuell bereits einen Tileserver (mod_tile) auf einer ubuntu-box laufen. Wenn ich die Tool-chain übernehmen könnte wäre das vorteilhaft. So oder so soll es auf einem ubuntu laufen und entsprechende Bild-Requests per HTTP/console annehmen und ausliefern können (also keine windows-clientprogramme). Danke, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Große Karte rendern ohne Zoom-Angabe
Nachtrag: Eine PHP-Lösung kommt leider nicht in Frage... :( On 23.10.2012 11:34, Gerrit Lammert wrote: Hi. Ich würde gerne ein Image aus OSM-Daten rendern (zur Weiterverwendung im GIS). Dazu möchte ich gerne dem Renderer eine Boundingbox (lat/lon) mitgeben, sowie eine Zielgröße für das Bild (z.B. 5000px x 5000px). Ich finde nur Lösungen, die die Angabe eines Zoomlevels erfordern. Kann mich jemand in die Richtige Richtung weisen und ein Tool empfehlen? Ich habe aktuell bereits einen Tileserver (mod_tile) auf einer ubuntu-box laufen. Wenn ich die Tool-chain übernehmen könnte wäre das vorteilhaft. So oder so soll es auf einem ubuntu laufen und entsprechende Bild-Requests per HTTP/console annehmen und ausliefern können (also keine windows-clientprogramme). Danke, Gerrit ___ 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] Große Karte rendern ohne Zoom-Angabe
On 23.10.2012 13:05, Lars Lingner wrote: Du verwendest bestimmt Mapnik und wenn du die mapnik-utils installiert hast kannst Du nik2img wie folgt benutzen: nik2img.py /path/to/osm.xml output_filename.png --scale-factor=3 -e 1467870.6369923 6882377.556746 1488984.3755909 6897485.2569212 -d 3990 2855 --no-open Ja, super. Das scheint genau das zu sein, was ich brauche. Leider hab ich mir in dem Prozess irgendwie den Tile-Server zerschossen (irgendwelche Rechte auf die Postgre-DB!?) ich hoffe ich bekomme das heute hin. Danke auf jeden Fall! Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verbesserung von OSM-Kartendarstellung/Rendering
Hallo, ich wollt mal fragen, ob irgendwie geplant ist, das OSM-Rendering etwas zu verbessern? Im Moment sehe ich ja vor allem als Problem, dass man beim Mappen viele tolle Zusatzinfos eintragen kann (Telefonnummer, Internetadresse, Öffnungszeiten usw.), diese dann aber nie auf der normalen Karte erscheinen. Vielleicht erscheinen die auf irgendwelchen Forks, aber da guckt ja im Normalfall niemand hin. Wenn man von Openstreetmap hört, geht man ja auf www.openstreetmap.org, nirgendwohin sonst. Daher frage ich mich schon die ganze Zeit, ob es irgendwie geplant ist, die einzelnen Objekte anklickbar zu machen, wie das z.B. auch bei Google Maps der Fall ist? Ich finde, wenn man sowas nicht macht, wird das ganze Engagement der Mapper irgendwie nicht gewürdigt (Ich hätte z.B. hier bei mir in der Umgebung schon Lust, solche Detailsachen einzutragen, aber ich frage mich, wofür ich das machen sollte, wenn es eh nie auf der Karte erscheint). Wäre super, wenn mir da jemand was zu sagen könnte :) Danke Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verbesserung von OSM-Kartendarstellung/Rendering
Hallo alle, schon mal danke für eure Antworten. Das Problem ist ja immer, dass man als Nicht-Programmierer null Chance bei sowas hat. Ich versteh das ganze Problem mit Opensource-Projekten natürlich :D Trotzdem ist es immer ein wenig frustrierend, wenn man bei sowas nicht wirklich mitarbeiten kann. Ich frage mich bei solchen Projekten immer, wieso da nicht ein wenig auf Spendenbasis gearbeitet wird. Ich kann zwar nicht programmieren, aber ich wäre bereit, Geld für solche „Unterprojekte“ zu spenden. Ich denke, einige andere Leute wären auch dazu bereit. Man fühlt sich halt immer so verloren („Hier, du musst es nur programmieren“ – „ja, aber ich kann ja gerade nicht programmieren“). Mit ein bißchen Geldanreizen würde sich dann vielleicht ein Programmierer dazu hinreißen lassen, sich da etwas mehr hineinzuknien. Man könnte ja z.B. einen Spendenticker (wie bei Wikipedia jährlich) machen, wo dann steht: „Wir brauchen 300€ für dieses Projekt“ o.ä. Ich weiß, monetäre Anreize sind bei Opensource-Sachen vielleicht ein bißchen verpönt, aber ich glaube, manchmal hilft es :) Sowas ist auch immer gut, um vielleicht notwendige, aber „unbequeme“ Jobs machen zu lassen. Aber das jetzt nur als kleiner Gedanke. Zu den Daten: Ja, ich weiß ja schon, wofür OSM eigentlich gut ist. Trotzdem ist es doch auch angenehm, wenn der gemeine Nutzer davon profitieren kann. Ich meinte jetzt auch nicht, dass man auf die Hauptkarte alle erdenklichen Infos bündeln sollte: ÖPNVKarte kenn ich z.B., die finde ich wirklich sehr gelungen, oder auch die Radfahrerkarte. Diese Auswahlmöglichkeit ist wirklich nicht schlecht, und ich denke, das ist wirklich ein guter Punkt von OSM. Problematisch ist halt nur, dass den meisten Leute das zu kompliziert ist. Da könnte man jetzt wieder von der Zielgruppe her argumentieren, aber allgemein ist es ja doch schon besser, wenn das viele Leute anspricht, oder? Eventuell wäre auf der Hauptseite eine Art Assistent praktisch: Bist du Autofahrer, Radfahrer, Fußgänger, ÖPNV-Nutzer, willst du Restaurants sehen usw.? Das wäre schon einmal einfacher, denke ich. Ich sehe gerade, das ist im Grunde ja bei openstreetmap.de der Fall. Ich finde, das wichtigste ist ja im Grunde, genau eine Webseite zu haben, auf der erst einmal alles gebündelt ist. Wenn man Openstreetmap hört, sucht man bei Google, und möchte da am besten ein Ergebnis haben, so dass man nicht verwirrt ist. Oder man tippt direkt die Adresse ein. Und solche anklickbaren Objekte sind ja genau das passende, um die Karte nicht zu überfrachten, aber trotzdem viele Infos zu bündeln. Ich denke, niemand erwartet, dass die Telefonnummer eines Geschäftes schon direkt auf der Karte erscheint. Naja, gut, das waren nur meine Gedanken :) Vielleicht verstehe ich das ganze Projekt ja falsch, aber dann bin ich wahrscheinlich nicht der einzige mit solchen Gedanken. Imho ist Benutzerfreundlichkeit auch sehr sehr wichtig. Ansonsten finde ich das Projekt natürlich sehr gut (und ich arbeite natürlich auch mit). Ah, noch eine kleine Frage zu osm.de: ist das nur auf Europa beschränkt? Das ist ja ein wenig schade... Viele Grüße, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ketten - wie taggen?
Hallo, ich habe jetzt einige Filialen der Videothekenkette „World of Video“ hinzugefügt, mich dabei aber folgendes gefragt: Wie werden solche Ketten eigentlich getaggt? Normalerweise mit dem „operator“-Tag, oder? Dieser scheint aber nach einem flüchtigen Überblick praktisch gar nicht benutzt zu werden – auch Geschäfte wie Rewe, Lidl o.ä. werden alle einzeln getaggt (sprich nur über „name“). Ist der Tag daher irgendwie nicht in Benutzung? Ich denke, es ist sehr praktisch, wenn man gezielt alle Filialen einer Kette suchen möchte – z.B. alle IKEA-Häuser, alle Sparkassen usw. Das geht doch mit dem Operator-Tag wesentlich besser, da die einzelnen Geschäfte ja manchmal auch besondere Namen haben können (Rewe Getränkemarkt usw), oder auch andere Geschäfte den Kettennamen im Namen enthalten (aber nichts mit der Kette an sich zu tun haben). Ich bin dann teilweise auch darauf gestoßen, dass es auch keine einheitlichen Beschriftungen zu geben scheint. Wäre da nicht ein Wiki-Artikel mit allen gebräuchlichen Ketten nützlich, wo man im Zweifelsfall nachschauen kann? Oder missverstehe ich da jetzt irgendwas komplett, bzw. habe irgendwas total übersehen? Viele Grüße, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ketten - wie taggen?
Am 05.10.2011 20:02, schrieb Martin Koppenhoefer: Am 5. Oktober 2011 18:33 schrieb Gerritz0idb...@gmx.de: ich habe jetzt einige Filialen der Videothekenkette „World of Video“ hinzugefügt, mich dabei aber folgendes gefragt: Wie werden solche Ketten eigentlich getaggt? Normalerweise mit dem „operator“-Tag, oder? Dieser scheint aber nach einem flüchtigen Überblick praktisch gar nicht benutzt zu werden – auch Geschäfte wie Rewe, Lidl o.ä. werden alle einzeln getaggt (sprich nur über „name“). neben operator käme evtl. auch brand in Frage. Gruß Martin Jetzt steh ich vor dem Problem: Was denn jetzt? Das ganze muss ja auch verstanden werden (Gut, ich weiß, dass OSM das im Moment anscheinend noch nicht kann). Jetzt plötzlich irgendein eigenes System aufbauen möchte ich auch nicht. Gibt es denn (natürlich auch international) irgendeine Präferenz für einen Tag? Ich denke, falls ich hier etwas Klarheit bekomme, werde ich mal einen Wikieintrag mit etlichen Ketten eröffnen, damit man im Zweifelsfall nachschauen kann. Gruß, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering vom Ausland - Schrift
Am 18.05.2010 15:19, schrieb Markus: Hallo Martin, Das ist ein hochkomplexes Gebiet. Ich verstehe davon nichts. Da müssen Fachleute ran. Hier gibt es auch keine Möglichkeit, das zu erfassen was man sieht, denn auf dem Orsschild sieht man immer nur die vor Ort gerade gültige Schrift. Ausnahme: Manche Kommunen verwenden auf einigen Ortsschildern zusätzlich zu ihrer lokalen Schrift eine lateinische Schrift (gesehen in China, Griechenland, Ägypten). Gruss, Markus Naja, das ist ja von Land zu Land unterschiedlich, anschließend auch noch von Sprache zu Sprache. In China/Taiwan ist z.B. der Fall, dass es eine allgemeingültige Lateinumschrift gibt, die könnte dann auch direkt benutzt werden. Beispiel: chin: 國立台灣大學 chin. Umschrift: Guólì Táiwān Dàxué engl.: National Taiwan University ich sehe eigentlich kein Problem, das dort zu benutzen. Problematisch wird es nur eher bei Sprachen, die keine unabhängige Umschrift haben, d.h. wo die Umschrift immer an den umliegenden Text angepasst wird, z.B. Russisch. Da müsste man die Umschrift dann eventuell immer passend in name:en bzw. name:de hinzufügen. Ansonsten könnte man eventuell schreiben: name:zh-Latn so ist eigentlich auch die normale ISO-Richtlinie Wenn man noch den Ort hinzufügen möchte, dann kann man das ja auch noch machen. z.B. heißt Bonn in China 波恩, in Taiwan aber 波昂. Das würde man dann entsprechend mit name:zh-CN=波恩 name:zh-TW=波昂 kennzeichnen. Ich sehe da eigentlich kein Problem drin. Die Regeln werden ja auch schon bei Wikipedia und allgemein im Internet angewandt. Ich denke, die Sache hängt eigentlich nur vom Renderer ab. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering vom Ausland - Schrift
Am 18.05.2010 16:48, schrieb Markus: Hallo Gerrit, danke für Deine Erläuterungen und Ergänzungen! von Land zu Land unterschiedlich, auch von Sprache zu Sprache. Wir brauchen also (in vielen Fällen) einen Dreifachschlüssel: Land, Sprache, Schrift. Beispiel: name:CH:de:latn=Biel name:CH:fr:latn=Bienne Du schreibst aber die Reihenfolge etwas falsch. Erst kommt die Sprache (in Kleinbuchstaben), dann die Region (komplett in Großbuchstaben), dann möglicherweise noch die Schrift (vierstellig, erster Buchstabe groß). Beispiel: zh-TW-Latn Das ganze halt auch im Normalfall per Bindestrich getrennt, nicht durch Doppelpunkt. Dabei gilt aber das Prinzip: Das ganze soll so kurz wie möglich sein. Sprich: Auch wenn du Deutsch mit japanischen Schriftzeichen schreiben könntest, geht man im Normalfall davon aus, dass Deutsch mit mit dem lateinischen Alphabet geschrieben wird. Daher reicht name:de aus. Wenn jetzt aber beispielsweise Österreich für Prag einen anderen Namen hätte, dann könntest du schreiben: name:de-AT=blabla http://de.wikipedia.org/wiki/ISO_15924 Das hier wären die Schrifttags In China/Taiwan gibt es eine allgemeingültige Lateinumschrift die könnte dann auch direkt benutzt werden. +1 Beispiel: chin: 國立台灣大學 chin. Umschrift: Guólì Táiwān Dàxué engl.: National Taiwan University Wie wäre dafür der Dreifachschlüssel zu bilden? name:zh=國立台灣大學 name:zh-Latn=Guólì Táiwān Dàxué name:en=Guólì Táiwān Dàxué Bei Chinesisch geht es aber noch komplizierter: Unterschiedliche Schreibweisen in China und in Taiwan: name:zh-TW=國立台灣大學 name:zh-CN=国立台湾大学 name:zh-Latn=Guólì Táiwān Dàxué name:en=Guólì Táiwān Dàxué Problematisch wird es bei Sprachen, die keine unabhängige Umschrift haben z.B. heißt Bonn in China 波恩, in Taiwan aber 波昂. Das würde man dann entsprechend mit: name:zh-CN=波恩 name:zh-TW=波昂 kennzeichnen. Vielleicht reicht ja manchmal ein Zweifachschlüssel? (Sprache, Land) Oder braucht man immer Dreifachschlüssel? (Sprache, Land, Schrift) Im Allgemeinfall reicht auch ein Einfachschlüssel. Nur in ganz komplizierten Fällen könnte auch ein Dreifachschlüssel notwendig sein, beispielsweise für oben Bonn: name:zh-CN=波恩 name:zh-CN-Latn=Bō’ēn name:zh-TW=波昂 name:zh-TW-Latn=Bō’áng (Dieser Fall ist im Grunde aber unsinnig, da Chinesen keine Lateinumschrift der Schrift brauchen. Die ist ja nur für Ausländer) Wie gesagt: Es soll so kurz wie möglich sein. Die Regeln werden auch bei Wikipedia und allgemein im Internet angewandt. Kannst Du diese Regeln ins OSM-Wiki schreiben? http://wiki.openstreetmap.org/wiki/DE:Key:name http://wiki.openstreetmap.org/wiki/DE_talk:Key:name Das würde beim Erfassen von Namen sehr helfen. Ich glaube, das wäre eher im internationalen Wiki besser aufgehoben. Meiner Meinung nach machen das ganze Länder (China, Japan, Korea, Taiwan; die restlichen Länder wahrscheinlich auch) komplett falsch. Da will ich mich jetzt aber nicht so aufspielen, dass meine Meinung die richtige ist. So sehe ich das ganze Problem nur. Und wenn das nur ins Deutsche Wiki kommt, versteht es ja keiner. Ich denke, die Sache hängt eigentlich nur vom Renderer ab. Nein, der Renderer kann nur darstellen was die DB hergibt. Wenn dort beispielsweise nicht kategorisiert historische Namen stehen würden,dann könnte der Renderer das nicht erkennen und würde sie als aktuelle Namen anzeigen. Und das könnte für OSM zu ernsthaften politischen Problemen führen. Ja, klar, aber wenn der Renderer nicht anzeigt, was die DB hergibt, ist das Interesse, die DB zu bereichen, doch ziemlich gering, oder nicht? Aber ich sehe überhaupt gar keinen Sinn dadrin, dort historische Namen einzugeben. Ich dachte, Openstreetmap zeigt die aktuelle Lage an? Wir nennen doch Istanbul auch nicht plötzlich Byzanz, oder doch? Dem Renderer automatische Trankription/Transliteration beibringen zu wollen halte ich in den nächsten Jahrzehnten für erfolglos. Das ist auch etwas utopisch. Im Grunde sollte es kein Problem sein, bei der normalen Erfassung der Straßen direkt eine Transkription einzugeben (Wird ja aktuell so oder so schon oft gemacht - nur leider in dem falschen Feld). Grundsatz für die _Darstellung_: *internationale Karte* aktuelle amtliche Namen in amtlicher Schrift des angezeigten Ortes (so wie derzeit auf OSM.org) *Weltschrift-spezifische Karten* aktuelle amtliche Namen des angezeigten Ortes als Endonym, in der jeweiligen Weltschrift der Karte (also lateinische Schrift für Karten aus Europa, Amerika, etc, bzw. chinesische/russische/arabische Schrift in chinesischen/russischen/arabischen Karten). Ich verstehe hier den Unterschied zwischen den beiden Karten nicht ganz. die internationale Karte würde doch das gleiche wie deine „Weltschrift-spezifische“ Karte sein, oder nicht? *Landesspezifische Karte* Aktuelle amtliche Namen des angezeigten Ortes als Endonym, in der jeweiligen Schrift des Herausgeberlandes. Exonyme nur wenn aktuell und amtlich. Beispiel für DE
[Talk-de] Rendering vom Ausland
Hallo, ich hätte eine Frage, die mich interessiert. Ich bin zur Zeit dabei, einiges in Taiwan zu kartographieren. Dort ist natürlich das folgende Problem: Es ist ein chinesischsprachiges Land, d.h. alle name-Tags sollten (so wie ich das verstanden habe) in der Landessprache sein, d.h. auf Chinesisch. Taipeh würde dann also 台北市 geschrieben werden. Natürlich können das die wenigstens Ausländer lesen. Daher wird oft noch in Klammern das Englische hinzugeschrieben, was aber meiner Meinung nach sehr schlecht ist: Es stört die einheimischen Benutzer, es nimmt an, dass alle Ausländer Englisch sprechen würden, und es sieht einfach schlecht aus. Für Taipeh kommt dann noch dazu, dass es im Englischen „Taipei“ heißt. Daher könnte man ja einfach den Tag name:de benutzen, was ich auch schon einige Male gemacht habe. Was mich jetzt nur wundert: Würde www.openstreetmap.de für beispielsweise Taiwan (ist aber im Grunde für jedes Ausland zutreffend) eine eigene Karte rendern, bei denen die deutschen Beschriftungen (nicht aber die englischen) verwendet werden? Ich habe es mal testweise aufgerufen, aber das war nicht der Fall. Würde das denn eventuell in Zukunft gemacht werden? Wenn ich mir im Moment Prag anschaue, ist das zwar sehr schön, leider zeigt er mir aber alles auf Tschechisch an. Dort steht dann nicht Karlsbrücke, sondern „Karlův most“. Ich denke, das ist zwar prinzipiell nicht schlecht, aber wäre denn nicht eine zweisprachige Ausschilderung am besten? Hier im Falle von Taipeh könnte ich mir folgendes Aussehen vorstellen: 台北市 Taipeh 國立故宮博物院 Nationales Palastmuseum Wäre so etwas eventuell in Zukunft in Planung? Danke und viele Grüße, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering vom Ausland
Am 18.05.2010 04:58, schrieb Frederik Ramm: Hallo, Guenther Meyer wrote: fuer openstreetmap.de, was ja in erster Linie deutschsprachige Benutzer anspricht, waere das sicher ganz sinnvoll so. Also eine zusaetzliche Angabe der Bezeichnung in fuer deutschsprachige Personen lesbarer Schrift. Ich koennte mir vorstellen, dass man das recht leicht einbauen koennte auf osm.de. Da waere ich eigentlich auch dafuer. Wir wollten ja immer auch einen gescheiten deutschen Map-Style haben (Stichwort blaue Autobahnen), dazu kam es bislang auch nie. Ich haette aber Bauchweh wegen der politischen Implikationen. Markus schrieb: Also ich finde, das ist eigentlich gar kein Problem. Städte, die im heutigen Gebrauch noch deutsche Namen tragen, sollten doch auch so benutzt werden, oder nicht? name:de ist vorgesehen für Ortsnamen in *heute deutschsprachigen* Orten. Sollte /auf der Standard-OSM-Karte/ nur in Ausnahmefällen in anderssprachigen Orten verwendet werden... Ich persoenlich habe das nie so betrachtet, ich wuerde allem, was einen deutschen Namen hat, auch ein name:de=... geben - ist ja dann die Entscheidung des Renderers, in welchen Gebieten er welchen Namen rendern will. Aber genau diese Haltung (und ich weiss, dass viele andere das genauso machen) sorgt natuerlich fuer Probleme auf osm.de, denn wenn ich nun einfach so name:de rendere, dann durften sich diverse Opfer frueherer nationalsozialistischer Eroberungen angepisst fuehlen. Also ich würde da auch nicht an solche Dinge denken. Für mich ist name:de= doch einfach für Orte wie: Prag (nicht Praha), Kalifornien (nicht California), Tokio (nicht Tokyo), Peking (nicht Beijing), Moskau, Schottland, Rom, Lissabon, Istanbul o.ä. Alles andere würde doch auch gar keinen Sinn ergeben. Ich denke, so ist das die beste Vorgehensweise. Man könnte dann ja auch einfach eine Rangfolge beim Rendern definieren: Falls name:de= verfügbar ist, sollte das benutzt werden. (Falls eine lateinische Umschrift verfügbar ist, dann das) Wenn nicht, das normale name= Wir muessten also irgendwie ein Ausschlusspolygon definieren und sagen: Bei allem, was hier drin liegt, den name:de auf keinen Fall rendern, selbst wenn vorhanden ;-) Naja, aber dabei würde ich dann einfach sagen: die deutschen Namen richten sich nach der aktuellen Benutzung. Wenn das früher einmal benutzt wurde, ist das ja schön und gut, aber da es heute nicht mehr benutzt wird, braucht man das ja auch gar nicht einzutragen. Aber Gdansk wird doch in den Medien immer noch Danzig genannt, oder? Viele Grüße, Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Piratenpartei benutzt Google Maps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A(gh)! Hi. Also, ich bin der Macher der PiratenPlakatKarte, ich bin NICHT die Piratenpartei. :) Nur ein Sympathisant, der mal nebenbei etwas halbwegs sinnvolles mit Openlayers machen wollte. Da ich auch bei OSM aktiv bin, war natürlich OSM die erste Wahl. Leider gab es da zu Beginn ein paar Performance-Probleme, bzw. Totalausfall. Deshalb hatte ich (bis gestern) Google als Eingangskarte. Aber auch da erkannte man an der Reihenfolge der Layer (GMaps, OSM, t...@h, cyclemap, Ghybrid, Gsat, Gphy), dass GMaps ausserplanmäßig vorne steht. :) Also: Keine Panik, weder ich noch die Piratenpartei ignorieren OSM. Die Karten sind IMHO besser. Nur ist eben die Verfügbarkeit/Performance des Mapservers nicht so gut wie bei google. Aber da werden wir (jetzt sprech ich als OSMler) wohl auch nicht konkurrieren können. :) - -Schnipp- Nach dem Lesen des gesamten Threads finde ich einige Dinge aber seltsam: Sehr viele regen sich darüber auf, dass gerade die Piratenpartei... Das finde ich insofern gut, als dass man den Piraten anscheinend (zu Recht) IT-Kompetenz zutraut. Was ich seltsam finde ist, dass dieselben Leute anscheinend nicht in der Lage/Willens zu sein scheinen, mal in den Quelltext zu schaun. Wie 1-2 mal (ungehört) bemerkt wurde, basiert die ganze Seite auf Openlayers und setzt sowohl OSM als auch Google (für ca 2 Stunden auch mal Virtual-Earth) ein und das seit Anfang an. Warum Google eine Zeitlang der Eingangslayer war, hab ich beschrieben. Der Rest ist eine Menge Unterstellungen, wie Die Piratenpartei kann das nicht (gleich zwei Unterstellungen), OSM ist halt zu kompliziert (regt immerhin zur Selbstkritik an) und so weiter. Dabei ist diese Seite wie gesagt ein reines Hobby von mir, um mal mit Openlayers zu basteln. Ich hab ab und zu mal Abends ne Stunde Zeit was dran zu machen und das wars. Die Seite ist voller Bugs und fehlenden Funktionen (vom grausigen Design nicht zu reden). Ich hab sie an zwei Stellen im Piraten-Forum bekanntgemacht, damit andere auch damit spielen können, mit dem Vermerk die URL nicht groß zu propagieren(!). Jungs, bis gestern hab ich nichtmal die SQL-Strings escaped und auch jetzt kann da jeder ohne Anmeldung Mist bauen, wenn er will. Fazit: Wie kann man nur zu solch einem Hobby-Projekt mit so wenig Hintergrundwissen so viele hanebüchene Behauptungen aufstellen..? Also, beruhigt Euch mal wieder alle. OSM ist von der Qualität super und auch bekannt. Eine engere Zusammenarbeit mit Openlayers (die brauchen nach meiner Erfahrung dringend bessere Doku und Beispiele!) kann sicher nicht schaden. Die Piratenpartei hat Euch lieb (geh ich zumindest stark von aus) und ich auch. Alles wird gut... Gerrit Frederik Ramm wrote: Hallo, ich surfte gerade auf den Wahlkampfseiten der Piratenpartei herum und stiess auf diese Wo-haben-wir-Plakate-Applikation: http://piraten.00l.de/plakate.php Realisiert mit Google Maps. Meine Guete: Wenn nicht mal die Piratenpartei OSM benutzt, dann haben wir PR-maessig ja noch einen langen Weg vor uns! Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqwvmYACgkQv5TZcjdId0eiwQCeN6LoPKJqswQYp2lLRe458I5D b50An25P9Gb2G7LkkU5/cFN6mDSQpYyl =3rFs -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Piratenpartei benutzt Google Maps
Hi Frederik. Gerrit Lammert wrote: Ich hab sie an zwei Stellen im Piraten-Forum bekanntgemacht, damit andere auch damit spielen können, mit dem Vermerk die URL nicht groß zu propagieren(!). Dann schau mal Deine Referer an - ich weiss nicht mehr genau, wie ich auf die Seite gekommen war, aber sie war meiner Ansicht nach irgendwo von piratenpartei.de aus verlinkt, ohne Umweg ueber ein Forum. forum.piratenpartei.de meinst Du vermutlich. :) Ist ja aber auch egal, das war kein Vorwurf an Dich! Das Forum der Piratenpartei ist öffentlich und damit auch zwangsläufig alle Links, die dort gepostet werden. Wollte damit nur sagen, dass dies keine ausgewachsene oder offizielle Kartenanwendung ist, sondern ein wachsendes kleines privates Projekt. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Export as jpg with BB
Moin. Ich bin glaub ich gerade ein bisschen blöd. Ich möchte eine BB angeben (2x lat/lng) und eine Zielgröße in Pixel (breite x höhe des bildes). Die einzige ähnliche API dazu verlangt Mittelpunkt (1x lat/lng), zoom und die Bildgröße. Kann mir jemand einen Tipp geben? Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity und Untergruppen
Bernd Wurst wrote: Würde man aber z.B. anstelle von amenity=restaurant oder amenity=pub oder amenity=fast_food (wir wissen alle: die Übergänge sind fließend) das zusammenfassen unter restaurant=* oder etwas ähnlichem, dann könnte ein Navi ohne genaue Kenntnis von vielen Unter-Typen schonmal eine Liste aller Gastwirtschaften erstellen. wer es genauer weiß, kann dann noch nach weiteren Kriterien unterteilen, aber man muss ja nicht. Ich denke auch, diese Methode ist zukunftsweisend. Ich finde hier jedoch die hierarchische Variante eine deutlich flexiblere Ergänzung. Hier also z.B. amenity=restaurant:fast_food:chinese (ob das jetzt amenity oder genauer restaurant oder allgemeiner locality/place sein sollte, steht auf einem anderen Blatt) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OePNV-Workshop in Karlsruhe
Tobias Wendorff wrote: Frederik Ramm schrieb: Wenn sich jemand fuer das Thema besonders interessiert, lohnt sich sicher auch die Anreise von etwas weiter weg - ggf. helfen wir gern bei der Vermittlung einer Uebernachtungsmoeglichkeit. Wäre eventuell auch ein LiveStream mit Webcam und Chat möglich, damit man aktiv an den Ideen teilhaben kann, wenn die Anreise zu kostenintensiv ist? Würde ich auch sehr begrüßen. Anreise kommt leider nicht in Frage, würde mich aber trotzdem interessieren, was bei dem Workshop rumkommt. Muss ja kein Livestream sein, aber danach das Material (idealerweise mit Video/Ton) im Internet verfügbar zu machen, wäre klasse. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Tobias Knerr wrote: Gerrit Lammert schrieb: maxspeed=de:city maxspeed=at:motorway maxspeed=it:trunk ... Aber bitte nicht so, dass macht logisch keinen Sinn. Besser maxspeed:de=city etc. Ohne jetzt generell die Idee bewerten zu wollen: maxspeed=de:city (oder city:de o.ä.) ist eindeutig sinnvoller, es handelt sich bei de:city um einen Wert für die Höchstgeschwindigket, nämlich deutsche Stadtgeschwindigkeit. Es handelt sich _nicht_ um eine deutsche Höchstgeschwindigkeit der Straße, in dem Sinne, dass man der selben Straße noch eine italienische Höchstgeschwindigkeit verpassen könnte -- genau das kann man mit maxspeed:de etc. aber tun. Und genau das kann man z.B. mit deutschen und italienischen Namen (name:de, name:it) tun, dort ist das aber im Gegensatz zu maxspeed gewollt. OK, nach der Logik dann aber bitte maxspeed=city:de Die Idee ist, das Dinge hinter dem ':' immer Verfeinerungen des vorherigen Merkmals sind und als Näherung auch ohne dieses funktionieren. maxspeed=city macht noch Sinn, maxspeed=de jedoch nicht. Insgesamt finde ich (wie andere auch schon gesagt haben) eine solche explizite Angabe des 'de', wenn es für alle Orte innerhalb des de-Polygons gilt, aber redundant. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Mario Salvini wrote: was spricht denn dagegen damits deutlicher zu unterscheiden ist jeden Way der kein explizit ausgeschildete Begrenzung mit mit einem implicit_maxspeed=* zu taggen statt das maxspeed mehrdeutig zu benutzen? Lieber maxspeed:implicit=* Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Stefan Dettenhofer (StefanDausR) wrote: Ok, aber wie kommst Du auf den Default für *_link? Außerdem wäre es doch sinnvoll, noch die Länderkennung dazuzuschreiben, also: maxspeed=de:city maxspeed=at:motorway maxspeed=it:trunk ... Aber bitte nicht so, dass macht logisch keinen Sinn. Besser maxspeed:de=city etc. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klassifizierung von Fußwegen
Garry wrote: Gerrit Lammert schrieb: Ich weiß nicht, ob ich Dich verstehe. Eine Plattform (also in diesem Fall ein Bahnsteig), wo eine RegioTram hält bekommt ein services=light_train (oder wo man RegioTram halt einsortiert). Das dort auch ein ICE vorbeifährt oder ein Flugzeug drüberfliegt spielt doch keine Rolle!? Wenn der ICE dort auch hält bekommt der Bahnsteig ein services=light_rail;rail. Und wenn auf der anderen Seite ein Bus hält, bekommt er services=light_rail;rail;Bus to service heiss bedienen. Alles was von dort bedient wird, kommt als Wert in services Halt alles, wo rein man von dort aus einsteigen kann. Steht doch so im Proposal!? Was nicht daraus hervorgeht ist ob im Bedarfsfall auch was grösseres als light_rail halten kann... Das ist auch nicht die Aufgabe. Wenn an der vorbeiführenden Bahntrasse eine ICE-Linie eingetragen ist, wird das doch impliziert. Ich trag doch auch nicht an Bushaltestellen ein, dass dort auch normale Autos oder Taxen mal halten oder ein Notarzt-Hubschrauber dort mal landen könnte. Manche Leute suchen auch Probleme... Gerrit PS: Nach der Logik müsste man hier leider jeden straßenbegleitenden Radweg als Parkplatz eintragen. :( ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klassifizierung von Fußwegen
Tobias Wendorff wrote: highway=platform services=train Das ist eine Platform an der etwas hält, was bei OSM als train bezeichnet wird. Ich würde darunter eher Nah-/und Fernverkehrszüge verstehen. Die regioTram ist meiner Ansicht nach eher ein light_train. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klassifizierung von Fußwegen
Garry wrote: Gerrit Lammert schrieb: Tobias Wendorff wrote: highway=platform services=train Das ist eine Platform an der etwas hält, was bei OSM als train bezeichnet wird. Ich würde darunter eher Nah-/und Fernverkehrszüge verstehen. Die regioTram ist meiner Ansicht nach eher ein light_train. Und was machst Du wenn an einem ganz normalen Nahverkehrsbahnhof der nicht umgestaltet wurde heutzutage nur noch die RegioTrams halten - auf dem gleichen Gleis auf dem auch der ICE durchrausch? Ich weiß nicht, ob ich Dich verstehe. Eine Plattform (also in diesem Fall ein Bahnsteig), wo eine RegioTram hält bekommt ein services=light_train (oder wo man RegioTram halt einsortiert). Das dort auch ein ICE vorbeifährt oder ein Flugzeug drüberfliegt spielt doch keine Rolle!? Wenn der ICE dort auch hält bekommt der Bahnsteig ein services=light_rail;rail. Und wenn auf der anderen Seite ein Bus hält, bekommt er services=light_rail;rail;Bus to service heiss bedienen. Alles was von dort bedient wird, kommt als Wert in services Halt alles, wo rein man von dort aus einsteigen kann. Steht doch so im Proposal!? Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Klassifizierung von Fußwegen
Martin Koppenhoefer wrote: Wenn der ICE dort auch hält bekommt der Bahnsteig ein services=light_rail;rail. Und wenn auf der anderen Seite ein Bus hält, bekommt er services=light_rail;rail;Bus to service heiss bedienen. Alles was von dort bedient wird, kommt als Wert in services Das Verb to service heisst pflegen, betreuen, unterhalten, ... ...und bedienen... ...hat aber direkt mit den Services nichts zu tun. Services ist ein Substantiv und heisst soviel wie Dienstleistungen, oder hier Betrieb. richtig. services ist aber auch dritte Person Singular von to service wie z.B. in this platform services trains on one side and busses on the other. Ich bin auch nicht glücklich wegen der Ähnlichkeit zu highway=service. Fällt Dir was besseres ein? Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutschlandauszug Geofabrik passt nicht so ganz
Wolfgang Schreiter wrote: a) bitte berücksichtigt, dass bei Verwendung von Bounding Box halb Süddeutschland für uns inkludiert ist (ist nur akzeptabel, wenn wir Bayern als 10. Bundesland bekommen ;-) Deal! ;-) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Ortshinweisschild taggen ?
On Fri, 3 Apr 2009 17:15:54 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 3. April 2009 16:31 schrieb Mario Salvini salv...@t-online.de: ich glaube da is ein Missverständnis. Ortsschilder sollten klar als Beginn der geschlossenen Ortschaft sein. Aber kann man das ja durch verschiedene Methoden lösen. Oft liegt der Beginn der geschlossenen Ortschaft ja 50 100 oder 200m vor der eigentlichen Ortschaft. das machen manche Kommunen zur Verkehrsberuhigung so, allerdings kann man die Rechtmäßigkeit nach den oben zitierten Gerichtsurteilen in Frage stellen: Wenn das Ortsendeschild erst 200 m NACH dem erkennbaren Ende der geschlossenen Ortschaft kommt, kann man als Autofahrer genausogut annehmen, das Ortsende-Schild sei vergessen worden, zumindest ohne Ortskenntnis. Bei der Einfahrt in den Ort geht das natürlich nicht, aber bei der Ausfahrt könnte man es da schonmal auf einen Rechtsstreit ankommen lassen (gibt ja so berüchtigte Wegelagerer-Stellen). Ich meine, mal gelesen zu haben, dass die Polizei innerhalb 150m nach dem Ortsschild nicht blitzen darf. Wenn ich mit kleinen Kindern am Ortsanfang wohnen würde, würde ich ein Versetzen des Ortsschildes um 150-200m sicherlich begrüßen... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Hi Martin. Martin Koppenhoefer wrote: Am 1. April 2009 01:06 schrieb Gerrit Lammert o...@00l.de: Das jeweils andere (car, ship, beer) sind die Produkte, nicht der Industrietyp (industrie=schiff, industrie=bier) macht ja auch keinen Sinn. :) ach so, Schiffsindustrie macht keinen Sinn? Wo liegt denn das der Unterschied zum Fahrzeugbau? Bei den Shops machen wir genau das: wir taggen den Shop nach den hauptsächlich angebotenen Produkten. Bei der Industrie würde ich eine nicht allzu kleinteilige Unterteilung vorschlagen (die man dann bei Bedarf noch mit Untertags verfeinern kann): Bitte wie? Wir taggen shop=bakery statt shop=bread shop=butcher statt shop=meat amenity=pharmacy statt amenity=drugs amenity=bank statt amenity=money und so weiter. Oder habe ich da etwas übersehen? OK, ich habe da wohl was übersehen ;-) Du allerdings auch: shop=alcohol;beverages;bicycle;books;car;clothes;computer;furniture; OSM ist ja noch nicht *so* alt, aber es gibt schon ne ganze Menge historische Besonderheiten ;-) Das stimmt allerdings. Warum pharmazy eine amenity ist, das meiste andere aber ein shop ist z.B. etwas irreführend. :) Bei Deinen shop-Beispielen fallen mir auch keine besseren Bezeichnungen ein (ich gehe davon aus das shoop=alcohol so etwas wie der system bolaget in Schweden ist, also kein normaler Getränkemarkt). Beim Verkauf mag es auch noch eher angehen, die Ware entsprechend einzugrenzen. Im Grunde kann man sich an die Sprache halten: Man sagt zwar Computerladen aber nicht unbedingt Computerfabrik sondern Halbleiterfabrik. So ähnlich würde ich das auch abbilden. Aber halt möglichst nicht im Grund-Datenbestand. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Hallo Ulf. Ulf Lamping wrote: Gerrit Lammert schrieb: office=telecommunication function=headquarter klingt sinnvoll. Auch wenn ich das alles nicht taggen würde. Ändert sich zu schnell und der Informationsgewinn für den üblich Passanten ist eher gering, wenn er weiß, was in den nichts-sagenden Büros hinter der grauen Wand passiert. wer mappt denn nur für Passanten? Der Standort der Hauptverwaltung von großen Firmen ändert sich zu schnell? Das glaube ich ehrlich gesagt auch nicht. Das ändert sich zwar hin- und wieder, dürfte aber deutlich langlebiger sein als die meisten der Bäcker, Schuhläden und Einbahnstraßen die wir sonst so taggen. Vor allem ist das dann mit dermaßen Getöse (z.B. in den Medien) verbunden, dass ein Update nicht schwer fallen sollte. Was ist Dir denn für eine Laus über die Leber gelaufen? Ich kann doch wohl noch schreiben, dass ich nicht jedes Versicherungsunternehmen oder Softwarefiliale tagge, die sich in irgendeinem Gebäude befindet. Das ist dein gutes Recht :-) Ich werde es wahrscheinlich auch nicht tun - aber ich werde auch nicht dagegen argumentieren wollen, wenn andere es machen. Und deshalb schrieb ich ja: klingt sinnvoll. Auch wenn ich das alles nicht taggen würde. Klingt für mich nicht, als würde ich anderen etwas vorschreiben wollen... :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie Ortshinweisschild taggen ?
Also, für ne Sekunde... Der erste, der mich heute fast gekriegt hätte! ...gerrit Patrick Kolesa wrote: malenki schrieb: Die Webcam am Netbook liefert 20 Bilder/s, die mit dem angeschlossenen GPS-Logger sofort georeferenziert werden. Die Bilder werden dann per Inkscape in SVGs gewandelt, die weißen Streifen aus dem XML extrahiert und per batchupload in die OSM-Datenbank injiziert. Ich habe unterm Auto eine Halterung für mein Netbook gebastelt und dort zusätzlich zwei Luxeon-LEDs montiert. Indem ich nun konsequent auf der Mittellinie fahre (auch auf der Autobahn, ist ja klar), kann ich so einfach und effektiv nach dem von malenki angesprochenem Konzept die Mittellinie taggen. Ein konstruktionstechnisches Problem war die Wärmeentwicklung, aber mit Alukühlkörpern, die den cw-Wert nur minimal verschlechterten, gings dann :) Gruß Patrick ___ 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] Handwerk, Industrie, Wirtschaft und Verwaltung
Hallo Harald. Harald Schwarz wrote: Darauf gestoßen bin ich als ich Handwerksbetriebe in meiner Umgebung erfassen wollte. Wie tagge ich dann den Schreiner, Drucker, Maler, Dachdecker, Schornsteinfeger? shop=* mag gehen, trifft aber nicht genau. Doch, ziemlich genau sogar. Eine Schmiede ist laut Leo z.B. blacksmith's shop. Shop ist im englischen nicht gleich (Super-)Markt, wie wir es hier meist benutzen. besser wäre vielleicht trade=carpenter trade=printer etc. Gar nicht. trade=printer ist eventuell ein Druckerfachgeschäft und trade=carpenter verkauft Zimmerleute. ;-) craft=mason craft= Mag gehen, ist aber IMHO überflüssig. manufactory ist ähnlich. industry=car automobile industry=ship oder industry=wharft shipyard industry=brewerey oder industry=beer brewery Das jeweils andere (car, ship, beer) sind die Produkte, nicht der Industrietyp (industrie=schiff, industrie=bier) macht ja auch keinen Sinn. :) Und dann die Verwaltungsgebäude? Die Verwaltung des Versicherungsunternehmens, das Hauptquartier des Telekommunikationsunternehmens, die Filiale eines Softwareunternehmens? office=inssurance office=telecommunication function=headquarter klingt sinnvoll. Auch wenn ich das alles nicht taggen würde. Ändert sich zu schnell und der Informationsgewinn für den üblich Passanten ist eher gering, wenn er weiß, was in den nichts-sagenden Büros hinter der grauen Wand passiert. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Handwerk, Industrie, Wirtschaft und Verwaltung
Hallo Martin. Ich glaube Du verstehst mich gründlich miss. :( Martin Koppenhoefer wrote: craft=mason craft= Mag gehen, ist aber IMHO überflüssig. manufactory ist ähnlich. sehe ich nicht so. manufactory ist eine Manufaktur=industrieller Maßstab, craft ist der kleine Handwerker. Damit meinte ich, das manufactory sich ähnlich überflüssig zu industry verhält wie craft zu shop. Nicht das beide das gleiche sind. industry=car automobile industry=ship oder industry=wharft shipyard industry=brewerey oder industry=beer brewery Das jeweils andere (car, ship, beer) sind die Produkte, nicht der Industrietyp (industrie=schiff, industrie=bier) macht ja auch keinen Sinn. :) ach so, Schiffsindustrie macht keinen Sinn? Wo liegt denn das der Unterschied zum Fahrzeugbau? Bei den Shops machen wir genau das: wir taggen den Shop nach den hauptsächlich angebotenen Produkten. Bei der Industrie würde ich eine nicht allzu kleinteilige Unterteilung vorschlagen (die man dann bei Bedarf noch mit Untertags verfeinern kann): Bitte wie? Wir taggen shop=bakery statt shop=bread shop=butcher statt shop=meat amenity=pharmacy statt amenity=drugs amenity=bank statt amenity=money und so weiter. Oder habe ich da etwas übersehen? office=telecommunication function=headquarter klingt sinnvoll. Auch wenn ich das alles nicht taggen würde. Ändert sich zu schnell und der Informationsgewinn für den üblich Passanten ist eher gering, wenn er weiß, was in den nichts-sagenden Büros hinter der grauen Wand passiert. wer mappt denn nur für Passanten? Der Standort der Hauptverwaltung von großen Firmen ändert sich zu schnell? Das glaube ich ehrlich gesagt auch nicht. Das ändert sich zwar hin- und wieder, dürfte aber deutlich langlebiger sein als die meisten der Bäcker, Schuhläden und Einbahnstraßen die wir sonst so taggen. Vor allem ist das dann mit dermaßen Getöse (z.B. in den Medien) verbunden, dass ein Update nicht schwer fallen sollte. Was ist Dir denn für eine Laus über die Leber gelaufen? Ich kann doch wohl noch schreiben, dass ich nicht jedes Versicherungsunternehmen oder Softwarefiliale tagge, die sich in irgendeinem Gebäude befindet. Ich finde auch, das hat in der DB nichts zu suchen, dann kann man gleich die kompletten gelben Seiten hinzufügen. Apotheken kann man vielleicht noch verstehen, aber Ärzte, viele Geschäfte und für allem Büros sind seperat schon wegen der Wartbarkeit besser aufgehoben. Gerrit Gruß Martin ___ 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] Lücken in Busroutenrelationen
On Mon, 30 Mar 2009 16:17:50 +0200, Stefano Kowalke blued...@gmx.net Kann man das reparieren oder ist das ein Bug des Relation Analyzer? Ist ein Bug im Analyzer. Der wertet forward/backward nicht aus und erkennt daher einen Kreisschluss. Hab das schon vor Wochen dem Entwickler geschrieben, aber entweder der hat kein Interesse oder es ist schwerer als vermutet. Gerrit PS: Nochmal anschreiben schadet sicher nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Christoph Eckert wrote: http://dodger.webfactional.com/de/tag/landuse/ Hier klcikte ich oben auf values, und farm fehlt hier. Doofe Frage, aber Du weißt, dass Du oben rechts nen Filter hast? (Oder weiterblättern kannst...) Zum N800/N810: MicroB ist im Prinzip ein Mozilla-Browser und keine komplette Eigenentwicklung. In den alten Versionen war es übrigens die Opera-Engine... ...gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstreckenrenovierung
Garry wrote: Vielleicht ein Beispiel dafür warum stillgelegte Strecken angezeigt werden sollten... Ohne mich da jetzt einmischen zu wollen, aber stillgelegt verstehe ich anders. Was Du beschreibst ist ein construction (oder repair, or temporary_unavailable) oder sowas. stillgelegt=abandoned=aufgegeben = Da war mal Bahnverkehr, jetzt aber nicht mehr. Vielleicht liegen sogar noch Gleise, aber da fährt kein Zug mehr! Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kaianlage
Torsten Leistikow wrote: Jan Tappenbeck schrieb: an den Lübecker MediaDocks gibt einen stillgelegten Kai mit Namen. Ehe man aneinander vorbei redet: geht es dir um die Wasserflaeche oder um die Landflaeche? Das ist leider bei mehreren OSM-Tags nicht ganz klar (z.B.auch Schwimmbad oder Yachthafen). Bei Deinen Beispielen stimme ich zu, aber der Kai ist eindeutig an Land. Wie würdet Ihr soetwas taggen ? In erster Linie wuerde ich es so eintragen, wie es heute genutzt wird, und nicht nach dem, was es frueher einmal war. Würde ich auch machen. Aber weil es gerade hipp ist, kann man ja auch noch ein dingens=kai;kai=disused dran machen (mir fallen die Begriffe gerade nicht ein). Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kaianlage
Hi Thorsten. Torsten Leistikow wrote: Norbert Kück schrieb: Die Wasserkante sieht gewöhnlich in einem Hafen (Kai) anders aus als an einem Fluss etc. (Uferböschung). Wenn man das dokumentieren will (man sollte es m.E.), bietet sich waterway=dock an. Der Key sagt es: Es geht um das Gewässer, nicht um die Flächen an Land. Also wenn ich mir http://wiki.openstreetmap.org/wiki/Tag:waterway%3Ddock anschaue, dann bin ich mir nicht so 100%-ig sicher, ob sich hier alle einig sind, um was es im aktuellen Fall geht und was mit dem Tag waterway=dock gemeint ist. Korrekt. Ein Kai ist kein Dock! - Kai ist ein befestigtes Stück Ufer, an dem Schiffe anlegen - Dock ist ein umbautes Stück Wasser, in dem Schiffe repariert werden. Trockendock müsste bei uns wieder ganz anders gehandhabt werden, denn waterway=dock fände ich da auch unpassend. Bei den Mediadocks in Lübeck handelt es sich (trotz des Namens) eindeutig um einen Kai, wie Jan ja auch richtig geschrieben hat. Dock hängt sicher mit andocken = anlegen zusammen, wird aber zumindest in D soweit ich weiß nur wie oben beschrieben verwendet. Man kann zwar sowas sagen wie unten an den Docks gibts gute Fischbrötchen und meint damit einen Hafen, aber wenn ein Schiff IM Dock liegt (am Dock gibt es nicht), dann wird es gebaut oder überholt. Soweit zumindest mein Sprachverständnis... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kaianlage - Hafen, Hafenbecken
Hi Markus. Markus wrote: Die normalerweise zwei Hafenmauern begrenzen den Hafen (Wasserfläche). Da dieser aber zum Meer/Fluss/See/Kanal hin offen ist, entsteht keine geschlossene Fläche, die als solche bezeichnet werden kann. Das macht man bei Seen, durch die ein Fluss fließt aber auch. Ich denke im vorliegenden Fall ist auch fast die einzige Gemeinsamkeit, dass dort Wasser ist. Wo ich im Fluß/Meer relativ frei mit meinem Ruderboot bin, bin ich im (Industrie-)Hafen wohl nicht gerne gesehen. Ein Hafenbecken hat damit für mich eine grundsätzlich andere Qualität als der Fluss. Das nur mal so eingeworfen... ...gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
On Fri, 27 Mar 2009 15:07:19 +0100, Astrid astridmuelle...@gmx.de wrote: Ein Vorschlag wäre z.B. footway:left=surface:cobblestone; footway:left=width:2; footway:right=surface:paving_stones Logischer fände ich es, das Schlüssel-Wert-System beizubehalten. Also in diesem fall: footway:left:surface=cobblestone footway:left:width=2 footway:right:surface=paving_stones Denn surface oder width ist ja nicht der Wert, sondern eine Becshreibung des Schlüssels. Anders sieht es aus bei natural=wood:oak Dieses wäre nur eine Verkürzung von natural=wood wood=oak Der Unterscheid ist, dass natural=wood auch für sich sinnhaftig ist, footway:left=surface jedoch nicht. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
On Fri, 27 Mar 2009 16:33:20 +0100, Tobias Knerr o...@tobias-knerr.de wrote: Gerrit Lammert schrieb: Logischer fände ich es, das Schlüssel-Wert-System beizubehalten. Also in diesem fall: footway:left:surface=cobblestone Gefällt mir alles ganz und gar nicht. Das sind alles wirklich gute Punkte. Mein Hauptanliegen war jedoch, dass surface (und die anderen Schlüssel) links vom = stehen sollten. Über Reihenfolge und allgemeines Aufbauschema müsste man sich tatsächlich mal kümmern. Einzelne Tags haben allerdings den Nachteil, dass sie nicht immer eindeutig zuordnenbar sind: highway=residential footway=both width=2m Breite des Fußweges oder der Straße? Eine Lösung mag hier sein, alle Hierarchieebenen explizit hinzuschreiben, also statt: footway:left:surface=cobblestone dann footway=yes footway:left=yes footway:left:surface=cobblestone Aber das ist auch suboptimal :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen vs. Recyclingstellen
Hallo. Ich denke, diese Diskussion (über 3-4 Threads verteilt) hat sich langsam totgelaufen, meint ihr nicht auch? Und dieses Verhalten jeder macht's wie er will ist in meinen Augen teilweise destruktiv. Es ist für Anwender jetzt schon schwer, alle Regeln und Ausnahmen genau zu beachten - und es gibt deutlich mehr Ausnahmen. Das sehe ich genau so. Ich war sowohl unzufrieden damit bus_stops nur neben der Straße zu taggen als auch nur auf der Straße. Und ich fand die unterschiedlichen Vorgehensweisen bei tram/zug/bus, etc verwirrend und unnötig. Und deshalb habe ich das bereits oft genannte Proposal zur unified stoparea gemacht. Es mag nicht perfekt sein, aber es sollte jedes der hier geäusserten Argumente eigentlich zufriedenstellen. Wer also maximale Infos und flexibilität hat, kann aktuell nach dem Proposal vorgehen. Wer das nicht tut und weiterhin NUR neben oder NUR auf der Straße taggt, wird sich auch nicht so leicht von einer anderen Methodik überzeugen lassen, weil er a) kein interesse hat, etwas zu ändern oder b) den Zusatzaufwand scheut. Summa summarum ist wirklich alles dazu gesagt. Ich freue mich, wenn hier ÖPNV-Themen diskutiert werden, aber bitte lieber zielführend neue Probleme angehen! Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen vs. Recyclingstellen
On Tue, 24 Mar 2009 15:21:59 +0100, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 24. März 2009 14:12 schrieb qbert biker qbe...@gmx.de: der ist bei einer Bushaltestelle per se gegeben, ausserdem wird man den Node in die Route-Relation einfügen, oder? Und dann? Dann muss man immer noch implizit voraussetzen, dass der Bus in der Naehe der Node anhaelt. DAS ist doch genau der Punkt: der Bus HÄLT in der Nähe des Nodes an. Das ist so. Ein Bus hält immer so an der Haltestelle, dass der Fahrer auf Höhe des Masten ist. Das ist auch genau der Unterschied zu einem Bahnhof, wo der Zug je nachdem, wie lang er ist, an verschiedenen Positionen anhält. Und genau das geht verloren, wenn man irgendwo in der Nähe der beiden gegenüberliegenden Bushaltestellen einen Haltepunkt auf den Way setzt (und mit Bushaltestelle beidseitig taggt). Typischer Busbahnhof/ZOB: http://commons.wikimedia.org/wiki/File:L%C3%BCbeck_ZOB.jpg http://www.trainslide.com/shh07/sl-stadtbus-luebeck-zob.jpg Innen eine Insel mit Kiosk, Fahrkartenautomaten, Bänken. Außenrum ca 10 schräge Buchten, an denen Busse halten. Bitte ausfüllen wie ihr das taggen würdet: 1. Gerrit (unified stop area) - - Eine Fläche mit highway=platform für die Insel - 10 Stop-Punkte mit highway=bus_stop auf die Straße außenrum - Alles in eine Relation um anzuzeigen, dass diese Elemente eine Einheit bilden - Buslinien-Relationen enthalten den Stoppunkt wo der entsprechende Bus hält. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen vs. Recyclingstellen
Hi Tobias. Ich hätte mir gewünscht, dass Du die Situation in dem System beschreibst, welches Du favorisierst, aber vielleicht kommt das ja noch... On Tue, 24 Mar 2009 16:23:01 +0100, Tobias Wendorff tobias.wendo...@uni-dortmund.de wrote: Gerrit Lammert schrieb: - Eine Fläche mit highway=platform für die Insel Ei Ei Ei ... da wäre ich vorsichtig. Wenn ich eine Flächenanalyse aller Bahnsteige machen will, sollen da keine Bussteige rein!!! highway = bus_platform highway:bus = platform Von mir stark favorisiert: transit:bus = platform - 10 Stop-Punkte mit highway=bus_stop auf die Straße außenrum analog: transit:bus = stop transit:train = stop transit:de:mobiler_dönermann = stop Ja, das mit dem Namen der Plattform ist so eine Sache. Mein Gedanke geht so: Das Ding ist ein von Fußgängern benutzbarer Bereich, der gewisse Eigenschaften aufweist (Bodenbelag, Nutzungsart, Aufbauten, ...) und dies egal, ob an der Seite ein zug, ein Bus oder eine Fähre vorbeifahren (oder auf der einen so, auf der anderen so). Daher ist dies ALLES highway=platform (highway scheint analog zu highway=footway etc. der defaulttag für begebare Bereiche zu sein). Was dort alles so verkehrt, kann dann flexibel per servives=bus;ferry Tag genauer bestimmt werden. Dies stieß auf Gegenwehr, Leute wollten stattdessen lieber railway=platform; waterway=platform, etc. Ich sehe das nicht so, aber meinetwegen. Prinzipiell finde ich das von dir vorgeschlagene hierarchische Tagging ja super (siehe meine anderen Posts dazu), aber erstens würden dann alle bisherigen Tags über den Haufen geworfen, statt ergänzt und zweites sehe ich das mit den Namespaces hier nicht so klar wie Du. Nach dieser logik könnte man auch highway=pedestrian mit shopping=pedestrian ersetzen, da dies der Hauptanwendungszweck von Fußgängerzonen ist. Ich finde es jedoch wichtige der allgemeine Nutzbarkeit zu benennen, also platform bei highway zu belassen. Man könnte dann die transit-Nutzung zusätzlich dranhängen, also highway=platform; transit:platform=bus Damit würde es das von mir dafür vorgesehene services=bus ersetzen = Meinetwegen. Beim Bus-Stop ist das was anderes, der ist ja im Prinzip eh schon eine Zusatzinfo zum physischen Objekt (=Straße/Weg). Also ein Stop-Node auf der Straße transit:stop=bus fände ich besser als das aktuell dafür vorgesehene highway=bus_stop. Aber das durchzudrücken wäre schwierig, da wie beschrieben alles geändert werden müsste und die Unterstützung dafür noch komplett in den renderern etc. fehlt. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen vs. Recyclingstellen
On Tue, 24 Mar 2009 18:01:42 +0100, Thomas Reincke m...@thomas-reincke.de wrote: Gerrit Lammert schrieb: 1. Gerrit (unified stop area) - - Eine Fläche mit highway=platform für die Insel - 10 Stop-Punkte mit highway=bus_stop auf die Straße außenrum ne, die 10 Masten Das wäre sehr hässlich auf der Karte, oder? Ein highway=bus_station gibt es ja auch noch. Aus meiner Sicht wäre das nach dem Bestehenden die Relation wo alles reingehört. Das ist aber laut wiki keine Relation. Jetzt wünsche ich mir nur noch eine solche Relation für jede normale Haltestelle. Bitte lesen: http://wiki.openstreetmap.org/wiki/DE:Proposed_features/unified_stoparea Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen vs. Recyclingstellen
Hi Tobias. Tobias Wendorff wrote: Gerrit Lammert schrieb: Das wäre sehr hässlich auf der Karte, oder? Masten werden nicht gerendert, sondern nur die Centeroide auf der Straße. Guck Dir mal Stadtpläne an. Also das was ich als Stop-Punkt taggen würde? Nur das die Position implizit berechnet wird? Das wird nicht immer gut gehen... Ein highway=bus_station gibt es ja auch noch. Aus meiner Sicht wäre das nach dem Bestehenden die Relation wo alles reingehört. Das ist aber laut wiki keine Relation. Soll ich es kurz umschreiben? Ja, bitte. Ich finde nur dies: http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dbus_station und dort beschreibt es einen Punkt (unsinnig) oder eine Fläche (sinnvoll, aber nur als Ergänzung zu Detailinfos zu Stoppunkten und Wartebereichen). Jetzt wünsche ich mir nur noch eine solche Relation für jede normale Haltestelle. Bitte lesen: http://wiki.openstreetmap.org/wiki/DE:Proposed_features/unified_stoparea Und in England überlaufen sie uns mit Transnet Co. OSM wird untereinander inkompatibel :-( Im Gegenteil. Transnet wird deutlich näher an dem Proposal sein als an den bestehenden Systemen. Eventuell werden Elemente umbenannt, aber auch dort sind z.B. SOWOHL Stop-Punkte AUF der Straße, als auch Orte NEBEN dem Weg vorgesehen. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bushaltestellen vs. Recyclingstellen
Hi Thomas. Thomas Reincke wrote: Gerrit Lammert schrieb: - Eine Fläche mit highway=platform für die Insel - 10 Stop-Punkte mit highway=bus_stop auf die Straße außenrum ne, die 10 Masten Das wäre sehr hässlich auf der Karte, oder? Je nach Zoomlevel würde ich die einzelnen Masten oder nur die Gesamtrelation darstellen. Aber bislang gab es keine Relation, die das konnte. Deshalb mein Proposal Ein highway=bus_station gibt es ja auch noch. Aus meiner Sicht wäre das nach dem Bestehenden die Relation wo alles reingehört. Das ist aber laut wiki keine Relation. aber ein Punkt für etwas was nach der bisherigen Diskussion überhaupt nicht dargestellt werden kann. Jein. Wenn man alle Elemente in eine Relation packt, kann man allein durch die Anzahl (und Zusammensetzung) schon grob auf die Relevanz der Haltestelle schließen. Genauere Angaben (ob z.B. als Haltestelle oder Busstation klassifiziert) gehören als Attribut an die Relation und nicht als Node irgendwo hin. Man könnte auch noch Areal oder Gebäude als amenity=bus_station taggen, aber einzelne Nodes haben keinen Informationsgewinn. Jetzt wünsche ich mir nur noch eine solche Relation für jede normale Haltestelle. Bitte lesen: http://wiki.openstreetmap.org/wiki/DE:Proposed_features/unified_stoparea Wenn das Konsens wäre -anscheinend ja nicht- wäre ich glücklicher. Nein, das habe ich vor ein paar Monaten vorgeschalgen. Gerade als Konsens, unter Anderem um solche Diskussionen mit verschiedenen Ansichten wie hier geäußert zusammenzufassen. Oder anders: Wenn es genug Leute verwenden ist es Konsens. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Hallo Thomas. Thomas Reincke wrote: Sowohl die Systeme die ich kenne, als auch die Datenaustauschformate haben, sehen diese überhaupt Masten enthalten (das Hafas-Rohdatenformat kennt diese beispielsweise nicht) sowohl für den POINT als auch für STOP bzw. AREA die Möglichkeit vor eine Koordinate zu vergeben. Ich finde es sehr gut und wichtig, sich anzusehen, was andere für Lösungen gefunden haben für ähnliche Probleme. Aber man sollte immer im Hinterkopf behalten, dass diese eventuell auf etwas andere Anwendungen oder Datenmodelle ausgelegt sind. So mögen etwa andere Anwendungen Elemente durch ein geographisches Gebilde gruppieren: Einen Rahmen, der alle zu gruppierenden Objekte einschließt. Dafür (zum Gruppieren), benutzt aber OSM i.d.R. Relationen und das ist IMHO deutlich besser. Hafas z.B. braucht quasi nur topologische Daten (wie hängen die einzelnen Punkte logisch zusammen, (wie) komme ich von A nach B?). Dahingegen haben viele Stadtpläne (incl OSM mit den Nodes-neben-dem-Weg-Tagging) einen eher graphisches Ansatz (*Hier* ist eine Haltestelle, topologische Infos wie zugehörige Straße und Zusammengehörigkeit mit anderen Stationen wird daraus abgeleitet). OSM ist insofern besonders, als dass wir nicht eine Anwendung haben und uns Daten dazu beschaffen müssen, sondern wir erheben Daten und gucken dann, was man alles damit machen kann. Das bedeutet aber auch, das wir IMO die Daten so erheben sollten, dass sie für möglichst viele Zwecke gut brauchbar sind. Das ist für mich gerade so der wichtigste Punkt - Haltestellenproposal - Hierarchisches Tagging - Aufräumen und Vereinheitlichen - Stabile Grundlagen ...herrje, ich komme immer vom Hundertsten ins Tausendste... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Hallo Tobias. Tobias Wendorff wrote: Was mein Vorschlag war: Den Punkt auf der Straße einfach aus den Punkten neben der Straße berechnen. Das sollte in JOSM realisierbar sein. Die meisten Haltestellen befinden sich an Kreuzungen. Und die Busstops (neben der Straße) sind i.d.R. nicht so eindeutig einer der beiden Straßen zuzuordnen. Ich stimme zu, dass man ab und zu den Eindruck von Redundanz hat, wenn man eine plattform neben den Weg und dann einen bus_stop direkt daneben auf den Weg malt, aber es ist die sauberste Lösung! Ich sehe es so: Der node AUF dem Weg (bei dem Proposal also bus_stop) ist die netztopologisch relevante Information (hauptsächlich für Bus/Fahreug-Routing und Verkehssimulationen) und der node/way/area daneben ist die geographisch relevante Information (schön auf der Karte rendern in hohen Zoom-Leveln; bessere bildliche Abbildung der Kreuzung). Daraus leiten sich auch die unterschiedlichen Ansprüche ab: Ersteres muss nur logisch korrekt sein (=u.U. Zusammenfassen mehrerer Punkte nötig), zweiteres muss geometrisch halbwegs genau sein. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmarender ohne Straßen?
Holger Blum wrote: Bei einigen habe ich gestern noch einen render request abgeschickt und angesichts der kaputten Tiles heute morgen nochmals, dabei hat sich nichts gebessert. Wenn das so weiter geht ist bald alles weiß :-(. Habe das Problem hier auch häufig. Die Karte ist für den tatsächlichen Einsatz auf Homepages etc. natürlich völlig unbrauchbar, wenn sowas immer mal wieder passiert... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Tobias Wendorff wrote: Die meisten Haltestellen an Kreuzungen? Kommr vor, aber doch nicht die Meisten! Nicht immer, aber aus guten Gründen oft: a) Wenn andere Linien Kreuzen - Umstieg b) Nutzer können so aus der Nebenstraße zuströmen Aber auch wenn, lassen sich hierfür Regeln erstellen. Sicher, aber die sind halt wieder implizit und setzen i.R. sehr genaues mappen voraus und sind aufwändig umzusetzen (es reicht ja nicht, etwa den Abstand zur Mittenlinie in OSM zu messen, man muss Straßenbreite 8und damit häufig Straßenklasse) mit einbeziehen... Im Übrigen widerspreche ich deinem System nicht, sondern wollte die Arbeit für den User erleichtern. Ja, das finde ich auch als den eigentlichen Nachteil des Proposals - Mehraufwand. Und ich habe versucht das so gut wie möglich in Grenzen zu halten um möglichst wenige Zwangsvogaben zu machen. Aber das Proposal deckt ja nicht nur den Punkt ab, Bushaltestellen ausreichend brauchbar zu mappen, dafür wäre es vermutlich tatsächlich over engineered. Weitere Punkte: a) Vereinheitlichung der Taggings von allen ÖPVs - Vereinfachung b) logisches Zusammenfassen von Bushaltepunkten zu Haltestellengebilden - Möglichkeit einer übersichtlicheren Darstellung c) Die meisten Tags (name/operator/...) müssen nicht mehr an jedem bus_stop stehen, sondern nur einmal in der relation - Vereinfachung Alles in allem denke ich, dass es nicht mehr Arbeit für den mapper ist und die Vorteile überwiegen. Es ist natürlich für uns Mapper erstmal eine Umstellung alter Gewohnheiten... Mir geht es aber inzwischen echt schnell von der Hand und die detaillierteren Haltestellen empfinde ich als Gewinn: http://www.openstreetmap.org/?lat=53.90181lon=10.72092zoom=17layers=0B00FTF http://www.openstreetmap.org/?lat=52.27021lon=10.50247zoom=17layers=0B00FTF Ein weiteres Argument für das geografische Tagging: Man kann anfeben, ob man die Straßenseite wechseln muss, wie lanf die Wege sind und ob Ampeln oder Treppen eine Barriere bilden. Sehe ich genau so. Grüße aus dem Zug kurz vor Rheine. Wo gehts denn hin? Holland? Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Hi. Tobias Wendorff wrote: Die Regeln, von denen ich spreche, kommen in den Editor. Man markiert mehrere, zusammenhänge Haltestellen und sagt create node on way und er berechnet dann den geeigneten Punkt. Ach so. Ja, das wäre auf jeden Fall eine gute Möglichkeit einfache Haltestellen einzutragen. So kann man im Zweifel den Knoten auf dem Weg noch zurechtschieben, falls die Automatik versagt hat und der Wartebereich besteht erstmal als Punkt an der richtigen Stelle. Ich finde es zwar nicht so aufwändig, die extra-Punkte und die Relation um alles von hand zu baun, aber eingebettet in ein bus-network-tool, welches die Erstellung von haltestellen UND Routen vereinfacht sicher sehr sinnvoll! Fahre kurz nach Leer und heute Abend wieder zurück. Bin jetzt in Salzbergen = Waypoint erstellt. Jo, da drüben ist noch alles ziemlich --- leer. Sorry, konnte nicht widerstehen. ;-) Vor allem die -fehn bestehen zu meist nur aus der Hauptstraße. Und das noch kein Blumenliebhaber durch Wiesmoor gelaufen ist... :( Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Hi Dimitri. Dimitri Junker wrote: Ja, das finde ich auch als den eigentlichen Nachteil des Proposals - Mehraufwand. Es ist ja nicht nötig immer alles einzugeben. Mal vershiedene Szenarien: Jo, das hab ich ja auch etwa so im Proposal geschrieben. Deshalb hab ich versucht möglichst viele bestehende Elemente einzubinden (Abwärtskompatibilität). Wenn man so mappt wie Du (bus_stop auf dem Weg), braucht man nur zu ergänzen, nichts zu ändern um das Proposal vollständig abzubilden. Wenn man bus_stop neben dem Weg macht, muss man noch bus_stop in platform ändern (und die anderen Elemente (i.d.R. ein node und eine relation) ergänzen). Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte ohne Feld- und Fußwege und mit k leinen Ortschaften
André Reichelt wrote: Ich war gestern auf der CloudMade-Seite. Diese bieten scheinbar auf Mapnik-Basis ein ganzes Magazin an verschiedenen Styles an. Frage mich aber bitte nicht, wie sie das genau gemacht haben... http://maps.cloudmade.com Ich muss sagen, der Fresh-Styyle gefällt mir ziemlich gut. Der ist zwar noch ziemlich buggy (Tramlinien werden wie Eisenbahn dargestellt und die Straße verschwindet bei trams ganz; Plätze fallen raus, zuviele POIs, ...), aber von der Farbwahl deutlich stimmiger als osmarender. Osmarender hat mehr Details, aber Fresh ist was Übersichtlichkeit angeht IMHO näher an Google Maps. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte ohne Feld- und Fußwege und mit k leinen Ortschaften
André Reichelt wrote: Gerrit Lammert schrieb: [...] näher an Google Maps. Was hälst du von Geagle? Ich kann nicht sagen, was es ist, aber ich finde es nicht so passig. Mir ist klar, das es an GMaps angelegt ist, aber irgendwas ist anders... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schutzgebiete in Lübeck - Anmerkungen und Anregungen für Tags
Jan Tappenbeck wrote: Folgende Elemente sind zu defninieren und ich wollte Euch um Anmerkungen bzw. Namensanregungen bitten. Sieh dies nicht als konkreten Vorschlag. Dies ist eher meine persönliche Meinung wie es sein KÖNNTE :) Als Schlüssel sollte landuse möglich sein. Ein irgendwie geartetes Naturschutzgebiet ist normalerweise weder residential, noch industrial oder so. und auch landuse=forest passt IMHO nicht, da dies eine forstwirtschaftliche Nutzung bedeutet und von nature=wood unterschieden werden sollte (hatten wir hier letztens gerade). Weiter würde ich das bereits häufiger in letzter Zeit angesprochene hierarchische Schema verwenden, also etwa: landuse=protected_area:nature:birds (~Vogelschutzgebiet) landuse=protected_area:water (~Wasserschutzgebiet) Prinzipiell könnte man so auch andere Schutzgebiete bezeichnen landuse=protected_area:culture:historic (~Weltkulturerbe) Dann passt es allerdings nicht mehr gut in landuse und man braucht einen eigenen Key oder die von Martin angesprochenen Administrative-boundary. Wie gesagt, dass war kein konkreter Vorschlag, sondern eine Gedankensammlung. :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Hi Dimitri. Dimitri Junker wrote: Und es hat dazu geführt, daß ich mir unabhängig von dieser Diskussion schon viel Gedanken über die derzeitige Methode gemacht habe. Vor allem, da ich sie ab Anfang an nicht für sehr gelungen gehalten habe. Aber mir ist bisher keine Methode eingefallen wie man das ganze effektiver hinbekommt, würde mich aber freuen wenn das einer könnte. Ich kann Dir eine sagen, aber da steckt etwas Arbeit hinter. Ich hatte selbst vor 3-4 Wochen mal gedacht, damit anzufangen, hab aber nicht die Zeit dafür. Grundsätzlich ist die Idee, das nicht die komplette Strecke eingetragen wird, sondern nur eine Abfolge von Bushaltestellen. Das ist es ja auch, was a) die Schematischen Liniennetz- und die Abfahrtszeitenpläne hergeben b) was einen als Nutzer derselben hauptsächlich interessiert. Ich habe soetwas ähnliches während meiner Diplomarbeit gemacht und konnte feststellen, dass bei Angabe der Stop-Folge und dem Verbinden dieser über einen kürzeste-Wege-Algorithmus zu 95% der tatsächliche Weg gefahren wird. Um in den Kernbereichen von Braunschweig und Lübeck (je 200.000+ Einwohner) den Busverkehr zu modellieren, brauchte ich neben den Haltestellen nur 4 Wegpunkte um die Strecken korrekt einzutragen. Wenn man nicht nur kürzeste Wege nimmt, sondern eher schnellste Wege (oder bei Bussen besser: keine besonders großen oder besonders kleinen Straßen), sollte das Ergebnis noch besser werden. Ich hatte mir gedacht, dass man dafür openrouteservive missbrauchen könnte, also ich wähle zwei Bushaltestellen und ORS gibt mir die Strecke zurück, die ich eventuell noch zurechtrücken kann. So ließen sich Linien deutlich schneller eintragen und auch beim Fahrplanwechsel ändern. Man muss nur die Abfolge von Stops bearbeiten. Idealerweise bräuchten dann auch nur die Stops gespeichert zu werden (evtl. mit den unsichtbaren Wegpunkten um Strecken zurecht zu rücken). Wenn jemand Lust hat, sowas umzusetzen: Wäre cool! :) Sorry fürs konfuse schreiben, bin gerade etwas müde... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Hatto von Hatzfeld wrote: Martin Koppenhoefer wrote: Ich möchte zu dieser Diskussion nur mal bemerken, dass mich Martins Argumente überzeugt haben. Dimitri scheint sich da eher in etwas verbissen zu haben. Vielleicht sollte ich meine Meinung auch noch kurz zusammenfassen. Ich habe (auch wenn der Eindruck hier nicht aufgekommen sein mag) die Bus-Stops NEBEN der Straße getaggt und finde das insgesamt auch sinnvoller als auf der Straße. ABER: a) Es gibt gute Gründe sie auf der Straße zu haben b) Bahnen haben sie i.d.R. AUF dem Weg, auch wenn es hier analog die gleichen guten Gründe gibt, das NEBEN der Straße zu machen. Genau diese Gründe (Quasi mein innerer Martin im Kampf gegen den inneren Dimitri) haben dazu geführt, dass ich das kombinierte/einheitliche Bus-Stop-Proposal gemacht habe. Falls das nicht klar geworden ist: bus_stop auf dem Weg mache ich NUR, weil ich platform NEBEN dem Weg habe, der alle Funktionen des alten bus_stop neben dem Weg erfüllt. Ich habe lange überlegt, ob ich bus_stop neben dem Weg lassen sollte und etwas neues auf den Weg einführen, aber sprachlich ist bus_stop für mich halt der Punkt an dem der Bus stoppt und nicht wo man auf ihn wartet. Abgesehen gab es railway=platform in dieser Bedeutung für Züge bereits vorher. Die talk-transit-Leute aus Englang schlagen nun quay statt platform vor, was ich vor allem mit Kai übersetzt hätte. Was ich damit meine: Namen sind Schall und Rauch, es gibt momentan drei Möglichkeiten: 1) Markieren AUF der Straße, mit allen Nachteilen die das hat 2) Markieren NEBEN der Straße, mit allen Nachteilen die das hat 3) Sowohl Markieren AUF, als auch NEBEN der Straße, mit dem Nachteil des erhöhten Aufwandes. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
On Fri, 20 Mar 2009 10:41:09 +0100, Martin Simon grenzde...@gmail.com wrote: Am 20. März 2009 08:27 schrieb Ulf Lamping ulf.lamp...@googlemail.com: Eine Bushaltestelle ist ein physikalischer Ort, den ich sehen kann. Ich persönlich werde weiterhin Objekte möglichst dort mappen wo sie *geographisch* sind, nicht wo sie vielleicht in einer Routinganwendung für Busfahrer am einfachsten liegen würden. Wenn Ihr jetzt die Bushaltestellen auf die Straße legt, *verliert* ihr Informationen - nämlich auf welcher Straßenseite die Bushaltestelle eigentlich ist und ob dort an beiden Straßeseiten eine Haltestelle ist. Das ist aber eine Information, die mich für Fußgängerrouting sehr wohl interessieren wird, besonders wenn die Straße recht breit ist und ich Umwege laufen muß um die andere Straßenseite zu erreichen. +1 Vielen Dank, genau so sehe ich das auch... Daß wir Straßen als deren Mittellinie erfassen ist eine Notwendige Vereinfachung, nicht notwendig (und m.E. kontraproduktiv) ist es, Punktobjekte wie Bushaltestellen oder Flächenobjekte wie landuse(Jehova!) auf diese Mittellinie zu ziehen, da wir mit diesen Typen glücklicherweise nicht dasselbe Problem haben wie mit Straßen. Wie oben geschrieben, sehe ich das ganz genau so. Und das war auch (ein weiterer) Grund für das Proposal. Bei tram-Linien wird es meist so behandelt, dass es einen Punkt (tram_stop) pro haltestelle gibt, auch wenn es 2-3 Haltepunkte gibt und diese auf verschiedenen Seiten der Kreuzung liegen. Auf der anderen Seite ist es ausgesprochen störend, wenn eine komplexe Kreuzung aus 6 Bushaltestellen besteht und auf der Karte dann 6 Mal der Haltestellennname auftaucht. Das Proposal versucht Vor- und Nachteile beider Systeme zu vereinen mit einem Minimalaufwand an Komplexität. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hallo Ulf. Ulf Lamping wrote: Dimitri Junker schrieb: Wenn Ihr jetzt die Bushaltestellen auf die Straße legt, *verliert* ihr Informationen - nämlich auf welcher Straßenseite die Bushaltestelle eigentlich ist und ob dort an beiden Straßeseiten eine Haltestelle ist. Das ist aber eine Information, die mich für Fußgängerrouting sehr wohl interessieren wird, besonders wenn die Straße recht breit ist und ich Umwege laufen muß um die andere Straßenseite zu erreichen. Das ist korrekt, deshalb gibt es ja (bei Bussen neu, bei Bahnen bereits existent) das Element highway=platform. Um genau diese Unterscheiduzng zu treffen! bus_stop (analog zu halt/tram_stop bei Schienenverkehr) = Punkt wo Bus/Tram/Zug hält platform (analog zu railway=platform bei Schienenverkehr) = Punkt/Weg/Fläche wo man auf den Bus/Zug/Schif/... wartet. Damit bleibt Deine Info erhalten, und über die Ausdehnung bekommst Du sogar MEHR Informationen: http://www.openstreetmap.org/?lat=53.89713lon=10.74956zoom=17layers=0B00FTF http://www.openstreetmap.org/?lat=52.25218lon=10.54021zoom=17layers=0B00FTF Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Thomas Reincke wrote: Gerrit Lammert schrieb: Ich benutze diese Tags auch nicht. Ich denke das Problem erledigt sich nächsten Monat ohnehin. Dann gibt es (soweit ich das Verstanden habe) mit der API 0.6 geordnete Relationen, d.h. man gibt die Reihenfolge der Stops (und damit ihre Fahrtrichtung) explizit an. Wie sähe die Reihenfolge der Haltestellen auf solch einer Linie aus? http://www.avv.de/fileadmin/sites/avv/download_FTP/Linienplaene/287_rve.pdf So wie abgedruckt? 17 verschiedene Fahrwege in der einen, 18 in der anderen Richtung. Krass! :) Ich frage mich auch, wie man sowas abbilden kann, bis jetzt kenne ich keine gute Lösung. Meine Baustelle sind aber eher die Haltestellen, mit Routen habe ich mich auch nur als Benutzer befasst. Und bestimmt gibt es Masten an denen die Fahrt an eine Mast je nach Variante mal in Hin- und mal in Rückrichtung verkehrt. Noch ein Grund, dass diese Infos besser in die Route(n?) sollten als an den Mast. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hi Mario. On Fri, 20 Mar 2009 16:39:06 +0100, Mario Salvini salv...@t-online.de was willst Du denn ausdrücken? Wenn der Wartebereich auf der Insel ist (das wird ja dann so sein), dann ist es doch richtig, dass der Router mich als Fußgänger dorthin leitet. Wenn ich dann auf beiden Seiten einsteigen kann (z.B. in verschiedene Nummern bzw. Richtungen) ist das doch auch kein Problem, den richtigen Bus findet mir der Router sowieso nicht, da muss ich mich zwangsläufig (z.B: durch die Anzeige des Busses oder beim Busfahrer) informieren. Martin könnte man diese Eindeutigkeit nicht dadurch erziehlen, dass man die Plattform mit in die jeweilige Busroute-Relation packt? Das will Martin ja im Prinzip machen. In seinem Vokabular ist ja Plattform == bus_stop. Es gibt auch Leute, die aus diesem Grund Stoppunkt und zugehörige Plattform nochmal in eine extra-relation packen wollen. Ich finde das überflüssig, da der Zusammenhang ja durch die geographische Nähe gegeben ist. Und selbst wenn aus irgendwelchen Gründen der Fahrplan für Bus X an Wartebereich A hängt (und die damit logisch zusammengehören), würde ich vermutlich dennoch am Wartebereich B warten, wenn dieser näher am Bus ist (und DIESE Beziehung ist ja bei georeferenzierten Daten immer gegeben). Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: highway=bus_stop und weitere tags f ür diesen Node
On Fri, 20 Mar 2009 17:23:35 +0100, Martin Koppenhoefer ja, Ihr habt mich jetzt doch noch überzeugen können, und die Telefonzellen, Briefkästen und Restaurants in dieser Straße auch. Wenn schon, denn schon, wie soll ein Router denn sonst jemals den Weg dahin finden. Ich bin dafür, alle POIs als Teil der Straße zu mappen. Proposal schreibe ich gerade. Davon spricht keiner. Aber Du kannst kaum in Abrede stellen, dass Bushaltestellen ziemlich straßengebunden sind. Das trifft auf Deine Beispiele nicht zu. (hoffentlich) letzter provokativer Satz von mir: Mappst Du Ampeln auch als Node neben der Straße? :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Martin Koppenhoefer wrote: Das will Martin ja im Prinzip machen. In seinem Vokabular ist ja Plattfor= m =3D=3D bus_stop. eigentlich wollte ich mich schon aus diesem Thread zurückziehen, weil mehr als meine Argumente vortragen kann ich ja nicht, aber hier möchte ich doch nochmal widersprechen: bus_stop ist die HalteSTELLE, das Schild, wo der Bus hält. Das ist ein NODE. Plattform ist linear, das ist ein WAY und könnte man je nach Verkehrsmittel als Bahnsteig oder Bussteig übersetzen. An normalen Bushaltestellen braucht man das m.E. überhaupt nicht, wenn es allerdings einen gesonderten Buswartebereich z.B. mit Häuschen gibt, spräche aber auch nichts dagegen, eine kurze plattform einzuzeichnen. Was ich meinte ist, dass da wo Du den node highway=bus_stop hin machst, ich den node highway=platform hinmache, (way und area sind quasi Ergänzungen). Auch sonst unterscheiden die sich kaum. Oder habe ich das falsch verstanden und Du meinst damit tatsächlich die Position wo das Fahrzeug hält und zeichnest den Node neben die Straße, weil dort die (nicht eingetragene) Busspur ist? Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: highway=bus_stop und weitere tags f ür diesen Node
Martin Koppenhoefer wrote: Am 20. März 2009 17:32 schrieb Gerrit Lammert o...@00l.de: (hoffentlich) letzter provokativer Satz von mir: Mappst Du Ampeln auch als Node neben der Straße? :) ich mappe Ampeln gar nicht, weil das m.E. unausgegoren ist. Man weiss weder, für wen die gelten, noch wie sie geschaltet sind. Was sollen die bringen? So sehe ich das auch. Und im Prinzip sah die Situation bislang bei den Haltestellen ähnlich aus. Route-relationen und die aufgebohrte Haltestelle sollen das verbessern. Als letzter großer Punkt fehlt eine gute öglichkeit Fahrpläne abzubilden, aber das ist wohl nicht über nodes,way und relations zu machen. :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: highway=bus_stop und weitere tags f ür diesen Node
Tobias Wendorff wrote: errit Lammert schrieb: (hoffentlich) letzter provokativer Satz von mir: Mappst Du Ampeln auch als Node neben der Straße? :) Ampeln liegen nicht neben der Straße, sondern auf der Verkehrsfläche. Wir mappen ja noch nicht mal die Straße, also zieht Dein Argument nicht. Geographisch liegen sie neben der Fahrbahn, aber logisch gehören sie (wie Du richtig sagst) zur Verkehrsfläche Straße. Busse mögen auf seperaten Spuren/Buchten halten, aber ebenso logisch gehören auch diese zur Fahrbahn. Wartebereiche hingegen gehören zwar zum Haltepunkt, aber nicht mehr unbedingt zur Fahrbahn, daher kommen diese daneben. Was anderes habe ich nie behauptet. Da viele Haltestellen zwischen Fahrbahn und Rad-/Fußweg liegen könnte man sie sogar komplett zur Verkehrsfläche Straße zählen und gar nicht als seperaten Node eintragen, aber diese position will ich gar nicht erst ins Rennen werfen. :) Ampeln müssen nicht angeroutet werden und haben derzeit in unserem Datenmodell sowie den Anwendungen nur eine geringe Bedeutung. War ja auch nur ein Beispiel. Wobei mittelfristig auch Ampeln fürs Routing (sowohl Fußgänger als auch Autos) wichtig werden. Stichwort: kürzeste Strecke. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: highway=bus_stop und weitere tags f ür diesen Node
Tobias Wendorff wrote: Mario Salvini schrieb: wieso soll man Fahrpläne nicht mit Relations (mit Ways und Nodes) abbilden können? in die Busrelation schreiben schedule:Hauptstrasse:leaving:1=1902 schedule:Hauptstrasse:leaving:2=1922 schedule:Hauptstrasse:leaving:3=1942 schedule:Hauptstrasse:leaving:4=2002 ... schedule:Schulzentrum:arrival:1=1904 ... oder wie? ;-) Fahrpläne gehören für mich nicht in den OSM-Datenbestand. Es sind externe Informationsquellen, die man nach belieben dranjoinen kann. Das wäre genauso, als ob Du das Telefonbuch von Karlsruhe an die Hausnummern hängst. Sehe ich genau so. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: highway=bus_stop und weitere tags f ür diesen Node
Tobias Wendorff wrote: Wir müssten eigentlich drei Sachen führen: 1. Die Haltestellennodes - mindestens einen pro Seite (STOP) 2. Einen dazugehörigen Node auf der Straße (AREA) Das wird in allen gängigen Verkehrsmodellen so gehandhabt und füllt die Datenbank unwesentlich, hat aber Vorteile für beide Seiten! Uh? Das ist genau mein Proposal. Also zumindest wenn die dritte Sache die Verbindende Relation mit den zugehörigen Meta-Daten ist. :) Nein, darum geht es nicht. Ampeln sind bei uns kein Ziel. Es ist egal, ob es die Ampel an der linken oder rechten Straßenseite ist. Die Bushaltestelle ist ein Ziel und ein Startpunkt, der eindeutig identifiziert werden muss. Du navigierst ja nicht zur Ampel Nr. 2 links der Kreuzung... Nein, aber wenn ich z.B. mit dem Auto oder zu Fuß möglichst schnell von a nach b will, ist nicht unbedingt der kürzere Weg mit 5 Ampeln schneller als der längere mit nur einer (oder grüner Welle). Insofern sind Ampeln gerade für die Navigation nicht uninteressant. Aber das ist jetzt eine ganz andere Baustelle... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f
Hi Martin. Martin Koppenhoefer wrote: Am 20. März 2009 18:08 schrieb Gerrit Lammert o...@00l.de: Was ich meinte ist, dass da wo Du den node highway=bus_stop hin machst, ich den node highway=platform hinmache, (way und area sind quasi Ergänzungen). Auch sonst unterscheiden die sich kaum. Oder habe ich das falsch verstanden und Du meinst damit tatsächlich die Position wo das Fahrzeug hält und zeichnest den Node neben die Straße, weil dort die (nicht eingetragene) Busspur ist? nee, ich setze den Node für die Bushaltestelle dort, wo das Haltestellenschild ist. Richtig verstanden würde ich trotzdem nicht behaupten, sonst würdest Du für platform keinen Node setzen (können). Oder ist das ein Fixme? Jain. Idealerweise (von einem Detailierungsstandpunkt aus) wird natürlich jedes Element als Fläche eingetragen. Das ist aber meist nicht gut verwertbar und ein ungeheurer Aufwand beim Eintragen. Ich habe beim Proposal versucht einen Mittelweg zwischen Details und Einfachheit, zwischen Stabilität und Offenheit zu finden. highway=platform kann sowohl an einen node, an einen way als auch an eine area gesetzt werden. Jeder Mapper kann selbt entscheiden welchen Detailgrad er a) für notwendig b) für ausreichend c) seiner Zeit würdig empfindet. Einfache Haltestellen oder nur grob bekannt, werden vielleicht erstmal als node (=Haltestellenschild) eingetragen. Wenn es Sinn ergibt, kann man auch einen way verwenden, z.B. um erste Anhaltspunkte für die Wichtigkeit des Stops zu vermitteln (langer way = mehrere Busse können gleichzeitig bedienen) oder einfach eine bessere Orientierung der Örtlichkeit zu geben. Area werde ich selbst wohl selten verwenden, aber wenn jemand lustig geformte Wartebereiche, etwa an ZOBs zeichnen will, habe ich nichts dagegen. Natürlich könnte man streiten ob statt des nodes highway=platform vielleicht ein man_made=stop_sign sinnvoller gewesen wäre, aber das würde wieder komplexität und Wildwuchs im tag-Dschungel bedeuten und so kann man im Prinzip einfach den node zu einem way vergrößern und braucht nichtmal um zu taggen. Wie gesagt, ist alles ein Mittelweg. Das ist ganz schön schwer, da stur zu bleiben, da von der einen Seite Leute kommen, die am liebsten jede Bordsteinkante als Orientierungspunkt einzeichnen können wollen und auf der anderen Seite Leute, denen ein grobes Hier irgendwo fahren ein oder mehr Busse reicht und die nicht bereit sind, einen großen Auwand deswegen zu treiben. Alles in allem kommt das vorgeschlagene System aber ganz gut an (~250 Verwendungen in D), ich muss nur ab und zu Leute davon überzeugen, dass das eigene liebgewonnene System der Weisheit letzter Schluss ist. ;-) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
On Thu, 19 Mar 2009 10:02:55 + (UTC), Sven Geggus li...@fuchsschwanzdomain.de wrote: Gerrit Lammert o...@00l.de wrote: Ich möchte die Transformation von WGS84 in GK in SQL nachbilden. Weshalb Dinge erfinden, die es schon gibt? Die Postgis Erweiterung der PostgreSQL Datenbank hat selbiges als Teil der Simple Features for SQL bereits eingebaut. Weil ich (wie bereits geschrieben) nicht PostgreSQL sondern MS SQL verwenden muss. Wenn ich frage wie ich etwas in inkscape hinbekomme, brauch ich auch keine Tipps bezüglich Auto-CAD. ;-) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hi. Thomas Reincke wrote: Und das die Haltestellen jeweils neben der Straße eingezeichnet werden ist ja auch schon länger Konsens. Nein ist es nicht, Will man nämlich eine Relation für die Buslinie erzeugen müssen alle Haltestellen auf der Straße sein nicht daneben. Ganz einfach Der Mast gehört dort hingezeichnet wo er steht. Wenn OSM das nicht hin bekommen sollte gehört das Datenmodell an dieser Stelle angepasst. Aus genau diesem Grund hab ich http://wiki.openstreetmap.org/wiki/DE:Proposed_features/unified_stoparea entwickelt. :) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
On Thu, 19 Mar 2009 11:57:06 +0100, Dimitri Junker o...@dimitri-junker.de wrote: Aus genau diesem Grund hab ich http://wiki.openstreetmap.org/wiki/DE:Proposed_features/unified_stoparea entwickelt. :) Die Frage ist ob man Dein Stop(Stop Place) nicht zweistufig machen sollte. Das mag datentechnisch sinnvoll sein, erzeugt aber zuviel Aufwand beim Eintragen. Wenn es zu kompliziert ist, nutzt es niemand. ist so wie ich es vorgeschlagen habe ja schon aufwändiger und den Nutzen merkt man häufig erst später. Ich schlage ja vor, die Stop-Nodes im einfachen fall zusammenzufassen (ohne Relation), das ist ja so ähnlich wie bei Deinem Einwand. Ein weiterer Punkt für bus_stop auf dem Weg ist übrigens, dass es bei Schienengebundenem Verkehr (TRam, Zug, U-Bahn...) bereits so gehandhabt wird. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hi Martin. On Thu, 19 Mar 2009 17:16:56 +0100, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 19. März 2009 13:10 schrieb Gerrit Lammert o...@00l.de: Ein weiterer Punkt für bus_stop auf dem Weg ist übrigens, dass es bei Schienengebundenem Verkehr (TRam, Zug, U-Bahn...) bereits so gehandhabt wird. das ist m.E. kein Punkt, da schienengebundener Verkehr komplett anders funktioniert als straßengebundener. Die Bus-Haltestellen sind nunmal meist *neben* der Straße und je nach Fahrtrichtung versetzt, wenn es überhaupt für beide Richtungen eine Haltestelle gibt. Das ist bei Schienenfahrzeugen anders. Das musst Du mir jetzt aber erklären. Bahnsteige sind bei Euch AUF den Schienen? Also hier in Braunschweig fahren die Trams ziemlich exact so wie die Busse und halten größtenteils sogar an den selben Haltepunkten. Bis auf das andere Medium sehe ich überhaupt keinen prinzipiellen Unterschied zwischen den Verkehrsträgern. Das die Ausstiegsbereiche bei längeren Fahrzeugen länger sind ist kein prinzipieller Unterschied. Und das manche Fahrzeuge auf beiden Seiten Türen haben auch nicht. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - RFC - (Erweiterte) Bedingungen für access-Tags
Tobias Knerr wrote:
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
[...]
Ich freue mich über Kommentare, Erweiterungs- und Verbesserungsvorschläge.
Finde ich wünschenswert.
Ich würde es begrüßen, wenn dieses System sich generell durchsetzen
würde und den Tag-Wald etwas lichtet.
Ähnlich wie hierarchische Ordnung auf der linken Seite, könnte man auch
auf der rechten Seite verfeinern.
Mir fällt jetzt kein Beispiel für access ein, aber, aber z.B.
natural=wood:oak:californian_red_oak
oder
landuse=industrial:harbour:fishing
Dabei kann der Auswerter auf der rechten Seite vor einem beliebigen
Doppelpunkt das Parsen abbrechen und erhält immernoch ein gültiges
Ergebnis. (hier also natural=wood oder natural=wood:oak)
Man könnte auch darüber Nachdenken andere Dinge so zu bezeichnen.
bicycle=yes:designated
aber das könnte zu Problemen führen.
Oder:
name:de:date{1933-1945}=Danzig
Auch kombiniert:
operator:time{0600-2300}=Verkehrsverbund:Stadtverkehr
Gerrit
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Hi Sven. Sven Geggus wrote: Gerrit Lammert o...@00l.de wrote: Weil ich (wie bereits geschrieben) nicht PostgreSQL sondern MS SQL verwenden muss. ich habe nochmal nachgelesen, in d177bcb986aad0b2858f779be1f7d...@imap.00l.de hattest Du das noch nicht geschrieben sondern erst in 2546fa35dc8ad73a9e33e5535f99f...@imap.00l.de. Ich habe aber auf die erste Email geantwortet. Ich pflege threads von oben nach unten zu lesen. Puh! Nein, ich habe nicht geschrieben, dass es auf dem MS SQL Server stattfinden soll. Ich habe jedoch geschrieben, dass die Transformation in _SQL_, und nicht in einer Bibliothek, einer speziellen Erweiterung, die das magisch macht, oder auf irgendeine andere Art, gemacht werden soll. Weitere Beispiele: Wenn ich frage, mit welcher Buslinie ich von a nach b komme, ist es zwar nett gemeint, wenn man mir erzählt welches Auto das beste Navi hat oder das Taxifahrer bestimmt schneller sind oder das richtige Männer zu Fuß gehen oder sowas. Aber es mag Gründe dafür geben, dass ich explizit nach einer Busverbindung frage... Es ist nett gemeint von Dir, mich darauf hinzuweisen das fertige, gut gepflegte Tools vermutlich genauer, flexibler und besser sind, aber dies war als kurze, wenn-wir-gerade-dabei-sind Frage, gedacht, mit der ich gerade NICHT den Thread übernehmen wollte. Also: Das Problem ist zu meiner Zufriedenheit gelöst. Wenn weiter jemand über proj4 oder ähnliches reden möchte, gerne. Aber ich klinke mich dann mal wieder aus... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hi Toni. Toni Erdmann wrote: Toni Erdmann schrieb: Und das die Haltestellen jeweils neben der Straße eingezeichnet werden ist ja auch schon länger Konsens. Hätte ich diesen Nebensatz doch nur weggelassen ... Kenn ich, mir ist gerade auch ein Thread dadurch entglitten. :) Und wenn ich zulasse, dass bus_stop als Node (auch neben der Straße) ein Member einer Bus:Route-Relation sein kann, dann brauche ich eigentlich den Haltepunkt des Busses auf der Straße oder in einer Busspur nicht wirklich, oder? Für Karte reicht das, aber andere Auswertungen (Fahrzeugrouting) benötigt die Punkte auf dem Weg. Außerdem war mein hauptanliegen die sehr ähnlichen Bereiche Bus/Tram/X-Bahn/Zug/Fähre zu vereinheitlichen um das übersichtlicher zu gestalten. Bushaltestellen neben dem Weg mit Linien als ttribut einzuzeichnen ist aber besser als nichts. Wenn das Proposal stabil wird (kann sein, dass sich noch was ändert, in UK wird gerade ein großer Datenimport bzgl. Bushaltestellen besprochen), kann dann auch jemand anderes leicht die Haltestelle upgraden. Nun aber endlich zu Deinem Punkt: Wie gesagt, die Linien als Attribut finde ich OK (auch wenn Bus-Route besser ist), aber ich verstehe ref= eher als so etwas wie eine ID, also einen etwas formaleren Namen. Beispiele highway=trunk, ref=A20, name=Ostseeautobahn route=bus, ref=Linie10, name=Ringbus In meinem Proposal ist ref= (an den platforms) daher auch eine Art kurzer Bezeichner für die Plattform. Also z.B. Bahnsteignummer bei Zügen oder nord/süd bei großen Haltestellen. Mir fällt aber momentan kein besseres etabliertes Tag ein. lines= vielleicht? Ich denke, die entgültige Lösung gibt es da noch nicht. Mach es so detailliert wie möglich, bzw. wie Du Lust hast. Von nem einzelnen bus_stop bis zur stop_area mit einzeln eingetragenen Mülleimern und Sitzbänken ist alles möglich. ;-) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [tagging] Feature Proposal - RFC - (Erw eiterte) Bedingungen für access-Tags
Johannes Huesing wrote:
Gerrit Lammert o...@00l.de [Thu, Mar 19, 2009 at 08:04:43PM CET]:
name:de:date{1933-1945}=Danzig
^
Die Zeitangabe stimmt aus so vielen Gründen nicht,
dass ich gar nicht weiß, wo ich anfangen soll.
Also lass ich's.
Die Zeit stimmt schon, was nicht korrekt ist, ist Deine implizite
Annahme, dass es sich bei diesem *Beispiel* um reale Jahreszahlen oder
Orte handelt. :)
Gerrit
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hi Martin. Martin Koppenhoefer wrote: Das musst Du mir jetzt aber erklären. Bahnsteige sind bei Euch AUF den Schienen? sagen wirs mal so: der Zug verlässt zu keinem Zeitpunkt die Schienen. Ein Bus hält eher in Ausnahmefällen mitten auf der Straße. In den meisten Fällen gibt es eine Haltebucht (wo z.B. auch nicht geparkt werden darf), wenn er nicht gleich eine eigene Spur bekommt. Also, das ist doch nur eine Vereinfachung, die wir momentan noch annehmen. Wenn man es genau haben will, malt man die Busspur als eigenen Weg ein und setzt den Haltepunkt dann eben auch AUF den Weg. Bei etwas weiter abseits liegenden Haltepunkten (z.B. an ZOBs etc) wird das ja bereits gemacht. Oder anders: In der Regel werden zweispurige Straßen nicht als zwei Ways gezeichnet, sondern als einer mit dem Attribut lanes=2. Betrachte ein highway=bus_stop doch einfach als ein temporäres lanes=lanes+1;access=ptv. :) Fakt ist, stoppen/halten tut ein Fahrzeug immer AUF dem Medium auf dem es sich bewegt (Straße, Schiene, Wasser). Flugzeuge sind eine Ausnahme :) Bis auf das andere Medium sehe ich überhaupt keinen prinzipiellen Unterschied zwischen den Verkehrsträgern. Bis auf das andere Medium sehe ich eigentlich keinen prinzipiellen Unterschied zwischen der Atmosphäre und den Meeren. Das andere Medium reicht mir aber schon als Unterschied (und hat nebenbei gesagt 'ne ganze Stange Konsequenzen). Ich sag ja auch nicht, dass es keine Unterschiede gibt, aber die Gemeinsamkeiten sind größer. Wenn es irgendwo ebenerdig große Ansammlungen von Luft gäbe, würde ich das analog zu natural=water auch als natural=air taggen und nicht als landuse=breathing oder color=transparent;smell=none ;-) Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Martin Koppenhoefer wrote: Am 19. März 2009 23:59 schrieb Dimitri Junker o...@dimitri-junker.de: Hallo, sagen wirs mal so: der Zug verlässt zu keinem Zeitpunkt die Schienen. der Bus verläßt auch nicht die Straße und fährt in den Grünstreifen. Die Haltebucht ist Teil der Straße. Die Straße geht normalerweise von Bürgersteig bis Bürgersteig (incl) und da ist die Haltestelle innen! der Bus verlässt die *Fahrbahn* und fährt in die *Haltestelle*. Sieh Dir doch mal die Wörter an: Bahn (linear) Stelle (Punkt), bzw. Bucht (also Teil der Straße, -Ausbuchtung, aber eben abseits des Stroms). Bei der Bahn ähnlich. Da kommen zwei Gleise an und im Bahnhof gibt es verschiedene Haltebuchten/-Stellen/-Punkte da werden die Haltepunkte dennoch AUF den Weg gesetzt. Schiffe fahren über den Fluß/das Meer und halten dann in speziellen Haltebuchten/Häfen. Diese sind natürlich immernoch im Wasser = auf dem Medium. Denk mal genau drüber nach alle Straßen-/Schienen-/Wassergebundenen verhalten sich praktisch identisch. Daher will ich die vereinheitlichen. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hi Dimitri. Dimitri Junker wrote: Weg-richtungsanhängige Tags sind nicht zu empfehlen. Mir gefällt das auch nicht, aber mach einen besseren Vorschlag wie man in der route-relation angibt für welche Richtung die Haltestelle gilt und schreib ein Programm welches alle bestehenden route-Relations ändert. Ich benutze diese Tags auch nicht. Ich denke das Problem erledigt sich nächsten Monat ohnehin. Dann gibt es (soweit ich das Verstanden habe) mit der API 0.6 geordnete Relationen, d.h. man gibt die Reihenfolge der Stops (und damit ihre Fahrtrichtung) explizit an. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hallo nochmal. Martin Koppenhoefer wrote: ...aber daraus ergibt sich noch nicht, ob nicht die Bushaltestelle (als Node in OSM) doch dort hinsoll, wo die Haltestelle (sprich das Schild auf dem Fussweg) ist. Ja, da soll auch was hin, weil es für den Benutzer vermutlich wichtoger ist, wo er sich selber aufhält, als wo der Busfahrer zum Halt kommen sollte. Dafür gibt es ja in dem Proposal die Plattform. Der Name ist dem Bahnsteig entnommen, denn entgegen Deiner Behauptung erfüllen alle drei (Bahnsteig, Buswartebereich, Schiffskai) die gleiche Funktion. Dort warte ich als Benutzer des ÖPNV, dort gibt es i.d.R relevante Infrastruktur (Sitzbank, Fahrplan, Fahrkartenautomat, Schutzdach/häusschen) und von dort steige ich in das Transportmedium ein. Die Unterschiede sind im Material und in der räumlichen Ausdehnung zu suchen. Aber das sind Dinge, die anderweitig abgedeckt sind, z.B. indem man Bahnsteige und größere Buswartebereiche als Weg/Fläche einträgt und kleine idealisiert als Punkt/Node. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Ist jetzt nicht mehr OSM-bezogen, aber soviele kundige Mitleser muss ich einfach ausnutzen. ;-) http://www.delphi-treff.de/tipps/mathematik/wiki/Geographische%20in%20Gau%C3%9F-Kr%C3%BCger-Koordinaten%20umrechnen/ Aha - den Code hatte ich auch mal vor längerer Zeit in mein Programm eingebaut, bis mir das mit dem Ellipsoidübergang aufgefallen ist. Die Formal von Grossmann liefert in erster Näherung eine Umrechnung in das Deutsche Hauptdreiecksnetz (EPSG: 4314) Die GK-Koordinaten benutzen genauso wie geogr. Koordinaten im DHDN das Ellipsoid WGS72 (Bessel 1841). Du willst aber WGS-84, daher benötigst Du noch den Übergang von Bessel auf WGS84. Ich benutze z.Zt. den Sourcecode von Geotrans. Der ist zwar nicht ganz so genau wie NTv2, aber die Abweichung liegt unter einem Meter (und hier kommen wir ja schon wieder in den Bereich der Plattentektonik und somit zu dem Problem WGS-84 - ETRS89 (GRS80). Ich möchte die Transformation von WGS84 in GK in SQL nachbilden. Ich habe eine gut funktionierende Transformation in c#, aber diese besteht aus vielen Objekten und Unterfunktionen, das ist nur sehr umständlich in SQL zu implementieren. Der Delphi-Code hinter obigem Link ist da deutlich angenehmer. Hab es nun auch schnell hinbekommen, aber natürlich die bereits angesprochene Abweichung von ein paar hundert Metern. Nachdem ich nun den ganzen Vormittag nach einer Möglichkeit gesucht habe, die Ellipsoidtransformation durchzuführen gebe ich auf und bitte Euch um Hilfe. Also, wie bekomme ich den obigen code dazu das gleiche Ergebnis zu liefern wie https://upd.geodatenzentrum.de/auftrupd/ktrans?sprache=deu bei Geo84 - GK3. Ich habe bereits versucht die Werte für e2 und c auf den WGS-ellipsoiden anzupassen, aber das hat nicht geholfen (was ist c überhaupt)? Wäre toll, wenn ihr mir helfen könntet. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gauß-Krüger WGS-84 [OffTopic]
Hi Stefan. On Wed, 18 Mar 2009 16:14:34 +0100, Stefan Dettenhofer (StefanDausR) Das geht gar nicht, da der o.g. Code keine Ellipsoid-Transformation macht! Diese kann man z.B. mit einer Helmert-Transformatiion erledigen. Du musst dazu einen ganz anderen Code nutzen: z.B. Geotrans oder Proj4 Jo, hatte inzwischen auch aufgegeben und den gut funktionierenden C#-Code transformiert. Ist zwar eine ziemliche Arbeit (Objektorientiert in SQL erzeugt Unmengen von DECLARE-Anweisungen und meine linke Hand ist ganz ausgeleiert vom @-Zeochen hinzufügen), aber funktioniert jetzt wie es soll. Wenn Du das in SQL lösen willst, dann kannst Du auch gleich eine entsprechende Datenbank nehmen, die die Koordinatentransformationen schon eingebaut hat: Oracle (spatial) kann das und die PostGIS-Erweiterung zu PostgreSQL sicherlich auch. Schön wärs. Die Koordinatentransformation ist nur eine ganz kleine Anwendung. Das ganze läuft auf MSSQL, also keine Geofunktionen (sofern ich weiß). Danke für Eure Hilfe. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=bus_stop und weitere tags f ür diesen Node
Hi Toni. Toni Erdmann wrote: auf http://öpnvkarte.de kann man ja schon seit einiger Zeit die Bus- S-Bahn und sonstige Routen sehen. Ja, das ist echt fein. Da Bus:Routes die Nummer der Busline im ref tag hat würde ich das auch so für bus_stop machen wollen und die anderen tags entfernen. Ich denke, aktuell ist, dass die Linie gar nicht mehr als Attribut des Stops eingetragen wird, sondern durch die Aufnahme des Stops in die entsprechende Route-Relation. dadurch ist die Information ja vorhanden. Und wenn mal wieder eine Buslinie umbenannt wird (geschieht hier ständig), dann brauch man das nur einmal anzupassen und nicht an jeder Haltestelle. Wie sieht es denn mit shelter=yes/no aus? Oder doch lieber amenity=shelter? Ich mache es so, dass amenity=shelter einen einzelnen Node beschreibt (wenn man sehr detailliert mapt) und shelter=yes eine Eigenschaft des Nodes ist, an den es gehängt wird (hier also des Busstop). Also einmal: Hier ist die Haltestelle und hier ist das Häusschen Und das andere mal: Hier ist die Haltestelle mit einem Wartehäusschen Und das die Haltestellen jeweils neben der Straße eingezeichnet werden ist ja auch schon länger Konsens. Guck Dir doch auch mal http://wiki.openstreetmap.org/wiki/DE:Proposed_features/unified_stoparea an... Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Alternativer Editor
qbert biker wrote: Ich halte das Konzept nach wie vor fuer einen Tschungel, der mir unheimlich ist und wende dann lieber meine gut erlernten workarounds an, statt in die Doku zu schaun, obs inzwischen wieder irgendwo eine neue Abkuerzung gibt ;) Ich muss leider zustimmen. Ich versuche mich alle paar Wochen wieder an JOSM und werde stets sehr schnell abgeschmettert. Es fängt bereits beim Download der Daten an. Bei meinem letzten Versuch gab es eine Weltkarte auf der man einen Ausschnitt laden konnte. In diese Karte konnte man jedoch nicht zoomen und jeder Ausschnitt, den man gewählt hat war zu groß. Gut, wähl ich eben den Ausschnitt auf osm.org und kopiere den direktlink in das dafür vorgesehene Fenster. Nach dem Download sehe ich einen Bruchteil es angezeigten Gebietes, irgendwas aus der unteren rechten Ecke. Gut, wähl ich nach Gefühl einen Ausschnitt, wo unten rechts klein das Zielgebiet ist. So geht es, aber... So ein Scheiss! Und die Berabeitung erschliesst sich mir auch nicht. Total überladen und (zumindest für mich) unlogisch - Aufgabe Wenn mir dann die Funktionen des sonst gut durchdachten Potlatch nicht ausreichen, versuch ichs wieder mit JOSM, aber komme zu ähnlichen Ergebnissen - Frustrierend. ...gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meine Kreisel-Liste ist abgearbeitet
On Mon, 16 Mar 2009 10:29:27 + (UTC), Matthias Merz openstreet...@merz.inka.de wrote: Doch, genau den großen Kreis meint er - das ist zwar eine kreisförmige Straße, aber kein Kreisverkehr. Die Stadtplaner hatten da wohl eine tolle[TM] Idee oder so - die Wolfartsweierer Straße geht da mit zwei Fahrstreifen je Richtung als Vorfahrtsstraße kreisförmig drüber; der Querverkehr hat Vorfahrt beachten. - Kannst Dir ja spaßeshalber mal das Sat-Bild anschauen: http://maps.google.de/maps?ie=UTF8ll=49.003248,8.424373spn=0.000977,0.002071t=hz=19 Das ist gar nicht mal so selten bei größeren Kreiseln. Sowohl in Lübeck, als auch in Braunschweig sind mir in der Stadt mehr solche gebogenen Einbahnstraßen bekannt als tatsächliche Kreisel. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
