Re: [Talk-de] [bulk]: Re: Google maps nutzt Geobasisdaten
Am 09.12.2011 19:28, schrieb Wolfgang Barth: http://sautter.com/map/?zoom=18lat=51.66421lon=7.64437layers=00BT Hier gibt es in OSM m.E. einige Spuren zuviel. ;-) Sehe ich eigentlich nicht so, daß die zuviel sind. Die Spuren sind doch getrennt Also ich erkenne da jeweils nur 2 getrennte Fahrbahnen und nicht 4 wie in OSM. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM License Change Plugin Update
Am 11.12.2011 04:23, schrieb Frederik Ramm: ... Ausserdem nutzt das Plugin jetzt ein leicht unterschiedliches Interface auf dem Server. Die Datenbank auf dem Server wird demnaechst so umgestellt, dass auch das Uebersteuern von CT-Ablehnern beruecksichtigt wird und seinen Niederschlag in der Einfaerbung von Objekten findet (s. http://wiki.openstreetmap.org/wiki/WTFE). Auch zustimmende aber anonyme Nutzer werden dann beruecksichtigt. ... Seit dem letzten Update am Mittwoch unterstützen die Statistiken auf odbl.poole.ch auch Frederiks Liste. Desweiteren war das ganze auch Thema an der letzten LWG Sitzung, und deshalb möcht ich darauf hinweisen, dass es im Augenblick keine technische Lösung gibt die Daten von Mappern verlustfrei zu übernehmen und dass die LWG noch nicht darüber entschieden hat ob sie ihre ablehnende Haltung dazu etwas aufweichen wird (ich hatte ja was ähnliches schon mal vor Monaten vorgeschlagen). Das heisst mit anderen Worten, dass man wenn man einen Mapper in die Liste einträgt, man durchaus Gefahr läuft, dass die Daten am Schluss einfach gelöscht werden. Man sollte sich also genau überlegen was man macht. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 73
Hallo, die neue Wochennotiz Nr. 73 mit allen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/2011/12/wochennotiz-nr-73/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM License Change Plugin Update
Am 11.12.2011 04:23, schrieb Frederik Ramm: ich habe das License Change-Plugin fuer JOSM angepasst. Es unterscheidet jetzt nicht mehr zwischen CT-Ablehner und noch unentschieden, denn wir kommen jetzt langsam in die Phase, in der beides aufs gleiche hinauslaeuft. Danke! Gerade gestern hat bei mir ein Blick auf die ODBL Coverage Map für leichte Frustration gesorgt. Grüße Franz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Das hier dokumentierte Schema der OpenRailwayMap: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Tagging macht ein paar Vorschläge fürs Tagging, die m.E. unglücklich gewählt sind: railway:pzb (Punktförmige Zugbeeinflussung) und railway:lzb (Linienzugbeeinflussung) das sind beides Sicherheitssysteme (AFAIK), die Züge beeinflussen und notfalls stoppen können (mehr Details z.B. in Wikipedia). Unsere Grundregeln für Tags sind: britisches Englisch und keine Abkürzungen. Daher schlage ich vor, andere Schlüssel-bezeichner für diese beiden Systeme zu verwenden, die so definiert werden, dass sie jeweils auf die entsprechenden deutschen Systeme (LZB und PZB) passen. Gem. Wikipedia(en) könnte man evtl. diese Bezeichnungen verwenden: continuous_train_control anstatt railway:lzb intermittent_automatic_train_running_control anstatt railway:pzb (s. Ernst, Dr.-Ing. Richard (1989). Wörterbuch der Industriellen Technik (5th ed.). Wiesbaden: Oscar Brandstetter, p. 802. ISBN 3-87097-145-2. ) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Am Sonntag, 11. Dezember 2011, 12:02:24 schrieb Martin Koppenhoefer: Das hier dokumentierte Schema der OpenRailwayMap: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Tagging macht ein paar Vorschläge fürs Tagging, die m.E. unglücklich gewählt sind: railway:pzb (Punktförmige Zugbeeinflussung) und railway:lzb (Linienzugbeeinflussung) das sind beides Sicherheitssysteme (AFAIK), die Züge beeinflussen und notfalls stoppen können (mehr Details z.B. in Wikipedia). Unsere Grundregeln für Tags sind: britisches Englisch und keine Abkürzungen. Stimmt, die Abkürzungen sind wirklich nur auf Deutschland oder einige andere Länder beschränkt. Aber: Wieso denn keine Abkürzungen? Es werden schon einige Abkürzungen verwendet, zum Beispiel psv, hgv oder uic_ref. Die Abkürzungen haben auch ihre Berechtigung, denn ausgeschrieben wären die Begriffe ziemlich lang und anfällig für Tippfehler. Es muss nur dokumentiert werden, was die Abkürzung bedeutet. Daher schlage ich vor, andere Schlüssel-bezeichner für diese beiden Systeme zu verwenden, die so definiert werden, dass sie jeweils auf die entsprechenden deutschen Systeme (LZB und PZB) passen. Gem. Wikipedia(en) könnte man evtl. diese Bezeichnungen verwenden: continuous_train_control anstatt railway:lzb intermittent_automatic_train_running_control anstatt railway:pzb (s. Ernst, Dr.-Ing. Richard (1989). Wörterbuch der Industriellen Technik (5th ed.). Wiesbaden: Oscar Brandstetter, p. 802. ISBN 3-87097-145-2. ) Also intermittent_automatic_train_running_control oder railway:intermittent_automatic_train_running_control finde ich nicht wirklich mapperfreundlich. Klar kann man das seinem Editor beibringen, aber zum Beispiel railway:cab_signalling bzw. railway:continuous_control oder railway:intermittent_control sind eindeutig kürzer und verständlicher. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Am 11. Dezember 2011 12:43 schrieb Alexander Matheisen alexandermathei...@ish.de: Aber: Wieso denn keine Abkürzungen? Es werden schon einige Abkürzungen verwendet, zum Beispiel psv, hgv oder uic_ref. Altlasten. Zwar nicht wünschenswert, aber durch die historische Entwicklung vorgegeben und bleiben vermutlich so. Die Abkürzungen haben auch ihre Berechtigung, denn ausgeschrieben wären die Begriffe ziemlich lang und anfällig für Tippfehler. Es muss nur dokumentiert werden, was die Abkürzung bedeutet. Es stimmt schon, dass längere Key-bezeichner auch mehr Platz beim Speichern benötigen, aber der Vorteil ist, dass man sich oft schon grob was unter dem key vorstellen kann, auch ohne dass man im Wiki sucht, was sie bedeuten könnten. Auch besteht bei Abkürzungen die Gefahr von Verwechslungen (die gleiche Abkürzung hat sehr oft mehrere Bedeutungen in unterschiedlichem Umfeld), selbst unterschiedliche Definitionen für dieselbe Abkürzung wären mit unserem derzeitigen Tag-Entwicklungssystem (Anarcho-Do-cracy) zu erwarten, sollten sich mehr und mehr Abkürzungen einschleichen. Also intermittent_automatic_train_running_control oder railway:intermittent_automatic_train_running_control finde ich nicht wirklich mapperfreundlich. Klar kann man das seinem Editor beibringen, aber zum Beispiel railway:cab_signalling bzw. railway:continuous_control oder railway:intermittent_control sind eindeutig kürzer und verständlicher. Ja, das waren nur Vorschläge, welche Bezeichner man dann am Ende wirklich verwendet kann man sich ja überlegen. Ich hatte das railway-prefix übrigens absichtlich weggelassen, weil man es m.E. nicht braucht (train ist ja schon im Key), wir taggen ja z.B. auch nicht highway:surface oder amenity:name. Was die langen Bezeichner angeht: mit den etablierten Editoren sollte das kaum eine Rolle spielen, da man wg. der Autocompletion sowieso nur ein paar wenige Buchstaben eingeben muss, bei Spezialeditoren würde man sowieso Presets einbauen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Hallo, die Bezeichnung PZB und LZB sind internationaler Standard und in Fachliteratur gängig und üblich. Als Oberbegriff kann man auch „Indusi“ (Induktive Zugbeeinflussung) verwenden. Diese Abkürzung ist üblich und wird auch in anderen Ländern genutzt: http://www.sh1.org/fotos/ausl_ca.htm Fast jedes Land benutzt andere Sicherungssysteme. Die deutsche Bezeichnung ist also völlig in Ordnung und findet international Verwendung. Ein europäisches Sicherheitssystem, welches in Zukunft Länderübergreifend eingeführt werden soll heißt: European Train Control System (ETCS). Auch diese Abkürzung ist in allen Ländern gängig. Daher mein Rat: railway:pzb oder railway:lzb aus Gründen der Übersichtlichkeit so lassen. Prinzipiell haben Abkürzungen auch etwas Gutes: Sie sorgen für eine Übersichtlichkeit Grüße Rob Am 11.12.2011 12:59, schrieb Martin Koppenhoefer: Am 11. Dezember 2011 12:43 schrieb Alexander Matheisen alexandermathei...@ish.de: Aber: Wieso denn keine Abkürzungen? Es werden schon einige Abkürzungen verwendet, zum Beispiel psv, hgv oder uic_ref. Altlasten. Zwar nicht wünschenswert, aber durch die historische Entwicklung vorgegeben und bleiben vermutlich so. Die Abkürzungen haben auch ihre Berechtigung, denn ausgeschrieben wären die Begriffe ziemlich lang und anfällig für Tippfehler. Es muss nur dokumentiert werden, was die Abkürzung bedeutet. Es stimmt schon, dass längere Key-bezeichner auch mehr Platz beim Speichern benötigen, aber der Vorteil ist, dass man sich oft schon grob was unter dem key vorstellen kann, auch ohne dass man im Wiki sucht, was sie bedeuten könnten. Auch besteht bei Abkürzungen die Gefahr von Verwechslungen (die gleiche Abkürzung hat sehr oft mehrere Bedeutungen in unterschiedlichem Umfeld), selbst unterschiedliche Definitionen für dieselbe Abkürzung wären mit unserem derzeitigen Tag-Entwicklungssystem (Anarcho-Do-cracy) zu erwarten, sollten sich mehr und mehr Abkürzungen einschleichen. Also intermittent_automatic_train_running_control oder railway:intermittent_automatic_train_running_control finde ich nicht wirklich mapperfreundlich. Klar kann man das seinem Editor beibringen, aber zum Beispiel railway:cab_signalling bzw. railway:continuous_control oder railway:intermittent_control sind eindeutig kürzer und verständlicher. Ja, das waren nur Vorschläge, welche Bezeichner man dann am Ende wirklich verwendet kann man sich ja überlegen. Ich hatte das railway-prefix übrigens absichtlich weggelassen, weil man es m.E. nicht braucht (train ist ja schon im Key), wir taggen ja z.B. auch nicht highway:surface oder amenity:name. Was die langen Bezeichner angeht: mit den etablierten Editoren sollte das kaum eine Rolle spielen, da man wg. der Autocompletion sowieso nur ein paar wenige Buchstaben eingeben muss, bei Spezialeditoren würde man sowieso Presets einbauen. 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
[Talk-de] key:entrance
Im Schlüssel entrance wird entrance=emergency vorgeschlagen/definiert für einen Notausgang, aber vom Lesen des Tags bekommt man den Eindruck eines Noteingangs (das gibt's übrigens als Konzept, s. hier: http://de.wikipedia.org/wiki/Aktion_Noteingang ). Vorschlag: Ändern in entrance=emergency_exit Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnsteige
Moin Neee, es gibt jetzt doch indoormapping. ;) -- Mit freundlichen Grüßen Klaus PGP-Key: E7701DCF Am Samstag, den 10.12.2011, 18:31 +0100 schrieb Rainer Knaepper: Am 10.12.2011 16:16, schrieb Peter Wendorff: Die dritte Variante finde ich definitiv falsch, ack (mit den Fußwegen, die die ways miteinander verbinden, bin ich so auch noch nicht glücklich...) ack. Aber wie sonst? Löcher in den Bahnsteig schneiden und Relationen basteln, so daß man den Aufgang ohne Extra-Fußwege mit der Bahnsteigfläche verbindet? WIe müßte man das machen? Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance
Am 11.12.2011 13:45, schrieb Martin Koppenhoefer: Im Schlüssel entrance wird entrance=emergency Erinnert mich an Windows XP: Start-Herunterfahren. ;-) vorgeschlagen/definiert für einen Notausgang, aber vom Lesen des Tags bekommt man den Eindruck eines Noteingangs. Vorschlag: Ändern in entrance=emergency_exit http://wiki.openstreetmap.org/wiki/Key:entrance Naja, einen etablierten Tag wegen einer Unschönheit nachträglich zu korrigieren ist immer etwas kritisch. Oft läuft es darauf hinaus, dass man dann für immer beide Varianten in der DB hat. (siehe landuse=farm / farmland, amenity=fire_hydrant / emergency=fire_hydrant). Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
On 11.12.11 13:42, ssho...@gmx.de wrote: Daher mein Rat: railway:pzb oder railway:lzb aus Gründen der Übersichtlichkeit so lassen. Unterstütze ich. Ein den Spezialisten weltweit verständlicher Begriff (auch wenn's ein Akronym ist) ist als Tag ok und sinnvoll. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance
Am 11.12.2011 13:45, schrieb Martin Koppenhoefer: Vorschlag: Ändern in entrance=emergency_exit +1, emergency_exit ist deutlich klarer und wir sollten es so schnell wie möglich einführen. Die bisher gerade mal 96 existierenden entrance=emergency sollten bei einer Umstellung kein ernstes Problem sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Am 11. Dezember 2011 13:42 schrieb ssho...@gmx.de ssho...@gmx.de: die Bezeichnung PZB und LZB sind internationaler Standard und in Fachliteratur gängig und üblich. Als Oberbegriff kann man auch „Indusi“ (Induktive Zugbeeinflussung) verwenden. Diese Abkürzung ist üblich und wird auch in anderen Ländern genutzt: http://www.sh1.org/fotos/ausl_ca.htm Je nachdem, welches System genutzt wird, üblich sind wohl diese: ALSN (Russian Federation, Belarus, Estonia, Latvia, Lithuania, Ukraine) ASFA (Spain) ATB (Netherlands) ATC (Sweden, Denmark, Norway, South Korea, Japan, Australia (Queensland)) ATP (United Kingdom, United States of America, Australia (Queensland)) ATP (Ireland) AWS (United Kingdom, Queensland, South Australia) BACC (Italy) CAWS (Ireland) CBTC (United States of America, Canada, Singapore, Spain, Gabon) CONVEL (Portugal) Crocodile/Memor (Belgium, France) EBICAB (Bulgaria, Norway, Portugal, Spain, Sweden) EVM 120 (Hungary) HKT (Denmark) Integra-Signum (Switzerland) KVB (France) LZB (Germany, Austria, Spain) LS (Czech republic, Slovakia) PZB Indusi (Germany, Austria, Romania, Slovenia, Croatia, Bosnia-Herzegovina, Serbia, Montenegro, Macedonia, Israel) SHP (Poland) SCMT (Italy) TASC (Japan) TBL (Belgium, Hong Kong) TPWS (United Kingdom, Victoria) TVM (France, South Korea) ZUB 123 (Denmark) ZUB 262 (Switzerland) Fast jedes Land benutzt andere Sicherungssysteme. +1, s.oben Die deutsche Bezeichnung ist also völlig in Ordnung und findet international Verwendung. zugegebenermaßen bin ich kein Eisenbahn-fachmann. Wenn diese System alle auf jeweils andere Art funktionieren, dann hielte ich es für sinnvoll, jeweils einen dedizierten Tag zu verwenden, wenn es aber Gruppen von vergleichbaren Systemen gibt, wäre eine Normalisierung evtl. besser (Einbahnstraßen haben auch unterschiedliche Namen in unterschiedlichen Ländern und trotzdem verwenden wir denselben tag). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnsteige
Moin Nein, auf die richtigen Bezeichnungen umtaggen. Löschen ist immer ein Informationsverlust. -- Mit freundlichen Grüßen Klaus PGP-Key: E7701DCF Am Samstag, den 10.12.2011, 23:29 +0100 schrieb Stephan Wolff: Moin! Am 10.12.2011 15:52, schrieb Andreas Hubel: was ist den jetzt eigentlich die beste Art und und Weise Bahnsteige (U-Bahn, S-Bahn, Tram) zu mappen? Ich hab bisher 3 Varianten gesehen: * ein paralleler Weg pro Gleis * eine Fläche zwischen den Gleisen, sozusagen die begehbare Fläche * ein zusätzlicher Weg auf den Gleisen der sich die Nodes teilt Bei Außenbahnsteigen: Variante 1 Bei breiten Mittelbahnsteigen (etwa ab 6m Breite): Variante 2 Bei schmalen Mittelbahnsteigen (etwa bis 6m Breite): Variante 2b eine Linie zwischen den Gleisen, möglichst mit Breitenangabe (width) Damit werden auch die in den anderen Antworten beschriebenen Routingprobleme vermieden. Wo setzt man am besten den Node mit railway=station? Eine gute Frage. Bei zwei oder mehr getrennt erfassten Gleisen kann man keinen sinnvollen Punkt mehr finden, sondern sollte railway=station besser als Fläche anlegen. Aber welche Fläche umfasst der Bahnhof: - die Bahnsteige - Bahnsteige und danebenliegende Gleise - Bahnsteige, Gleise und Gebäude - den Bahnhofsbereich nach jeweiliger Bahnbetriebsordnung? Und wie verknüpft man diesen Node am besten mit dem Bahnsteig? Über eine Relation public_transport=stop_area. http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area Weil wir gerade beim Thema Bahn sind, habe ich noch eine Frage: manche Gleise (railway=rail) tragen den Namen der Städte am Streckenende (z.B. name=Hamburg - Neumünster), andere den Namen der dort verkehrenden Linien (z.B. name=A1, R11), wieder andere eine Funktionsbeschreibung (z.B. name=Güterumgehungsbahn). Sollte man solche Benennungen löschen? Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnsteige
Ack. -- Mit freundlichen Grüßen Klaus PGP-Key: E7701DCF Am Sonntag, den 11.12.2011, 01:37 +0100 schrieb Martin Koppenhoefer: Am 10. Dezember 2011 23:29 schrieb Stephan Wolff s.wo...@web.de: Eine gute Frage. Bei zwei oder mehr getrennt erfassten Gleisen kann man keinen sinnvollen Punkt mehr finden, sondern sollte railway=station besser als Fläche anlegen. sehe ich im Prinzip auch so. Aber welche Fläche umfasst der Bahnhof: - die Bahnsteige - Bahnsteige und danebenliegende Gleise - Bahnsteige, Gleise und Gebäude mind. die vorgenannten, wenn man es durch andere Quellen besser weiss (z.B. Bahnbetriebsordnung) kann man die Schätzung dahingehend verbessern. - den Bahnhofsbereich nach jeweiliger Bahnbetriebsordnung? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance
On 11.12.11 13:45, Martin Koppenhoefer wrote: Vorschlag: Ändern in entrance=emergency_exit ACK. Denselben Gedanken hatte ich beim Lesen des Vorschlags vorher auch... Ich halte es für wichtig, dass ein exit dortsteht, wenn es sich um einen reinen (Not-) Ausgang handelt. Übrigens gibt's auch andere reine (nicht Not-) Ausgänge aus Museen, Kinos o.ä. Ob entrance=exit da der richtige Tag ist?! /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance
Am 11. Dezember 2011 14:04 schrieb Andreas Labres l...@lab.at: Übrigens gibt's auch andere reine (nicht Not-) Ausgänge aus Museen, Kinos o.ä. Ob entrance=exit da der richtige Tag ist?! hatte ich mich im ersten Teil der mail (vor dem Abschicken gelöscht) auch gefragt, und mich dann doch fürs Weglassen entschieden, weil es prinzipiell verständlich ist. Dazu kommt, dass die Unterscheidung von exit und entrance sowieso nur sehr selten unveränderlich baulich bestimmt ist (theoretisch kann man technisch fast alle Ausgänge auch als Eingänge nutzen, es handelt sich eher um Übergänge von aussen nach innen bzw. viceversa), d.h. die Natur eines exits und eines entrance-Objekts ist ungefähr dieselbe. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrancepass
Moin Martin, probier das mal bei uns im Freibad. Viel Spass. ;-) -- Mit freundlichen Grüßen Klaus PGP-Key: E7701DCF Am Sonntag, den 11.12.2011, 14:11 +0100 schrieb Martin Koppenhoefer: Am 11. Dezember 2011 14:04 schrieb Andreas Labres l...@lab.at: Übrigens gibt's auch andere reine (nicht Not-) Ausgänge aus Museen, Kinos o.ä. Ob entrance=exit da der richtige Tag ist?! hatte ich mich im ersten Teil der mail (vor dem Abschicken gelöscht) auch gefragt, und mich dann doch fürs Weglassen entschieden, weil es prinzipiell verständlich ist. Dazu kommt, dass die Unterscheidung von exit und entrance sowieso nur sehr selten unveränderlich baulich bestimmt ist (theoretisch kann man technisch fast alle Ausgänge auch als Eingänge nutzen, es handelt sich eher um Übergänge von aussen nach innen bzw. viceversa), d.h. die Natur eines exits und eines entrance-Objekts ist ungefähr dieselbe. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Hallo, wenn es aber Gruppen von vergleichbaren Systemen gibt, wäre eine Normalisierung evtl. besser (Einbahnstraßen haben auch unterschiedliche Namen in unterschiedlichen Ländern und trotzdem verwenden wir denselben tag). Sie sind ja eben nicht gleich und das ist unter anderem der Grund, weshalb Lokomotiven nicht Länderübergreifend verkehren können. Mal vom Stromsystem und einigen wenigen speziellen Mehrsystemlokomotiven abgesehen. z.B. http://de.wikipedia.org/wiki/Bombardier_TRAXX Daher hat man mit dem European Train Control System (ETCS) einen Schritt hin zur Vereinheitlichung gemacht. Aber das in allen Ländern das gleiche Sicherungsystem genutzt wird, werden wir wohl so schnell nicht erleben... Ein Übersicht aller verwendeter Sicherungssystem findet man hier: http://en.wikipedia.org/wiki/Train_protection_system#Country_specific_legacy_systems Grüße Rob ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Am Sonntag, 11. Dezember 2011, 14:03:33 schrieb Martin Koppenhoefer: Am 11. Dezember 2011 13:42 schrieb ssho...@gmx.de ssho...@gmx.de: die Bezeichnung PZB und LZB sind internationaler Standard und in Fachliteratur gängig und üblich. Als Oberbegriff kann man auch „Indusi“ (Induktive Zugbeeinflussung) verwenden. Diese Abkürzung ist üblich und wird auch in anderen Ländern genutzt: http://www.sh1.org/fotos/ausl_ca.htm Je nachdem, welches System genutzt wird, üblich sind wohl diese: ALSN (Russian Federation, Belarus, Estonia, Latvia, Lithuania, Ukraine) ASFA (Spain) ATB (Netherlands) ATC (Sweden, Denmark, Norway, South Korea, Japan, Australia (Queensland)) ATP (United Kingdom, United States of America, Australia (Queensland)) ATP (Ireland) AWS (United Kingdom, Queensland, South Australia) BACC (Italy) CAWS (Ireland) CBTC (United States of America, Canada, Singapore, Spain, Gabon) CONVEL (Portugal) Crocodile/Memor (Belgium, France) EBICAB (Bulgaria, Norway, Portugal, Spain, Sweden) EVM 120 (Hungary) HKT (Denmark) Integra-Signum (Switzerland) KVB (France) LZB (Germany, Austria, Spain) LS (Czech republic, Slovakia) PZB Indusi (Germany, Austria, Romania, Slovenia, Croatia, Bosnia-Herzegovina, Serbia, Montenegro, Macedonia, Israel) SHP (Poland) SCMT (Italy) TASC (Japan) TBL (Belgium, Hong Kong) TPWS (United Kingdom, Victoria) TVM (France, South Korea) ZUB 123 (Denmark) ZUB 262 (Switzerland) Fast jedes Land benutzt andere Sicherungssysteme. +1, s.oben Die deutsche Bezeichnung ist also völlig in Ordnung und findet international Verwendung. zugegebenermaßen bin ich kein Eisenbahn-fachmann. Wenn diese System alle auf jeweils andere Art funktionieren, dann hielte ich es für sinnvoll, jeweils einen dedizierten Tag zu verwenden, wenn es aber Gruppen von vergleichbaren Systemen gibt, wäre eine Normalisierung evtl. besser (Einbahnstraßen haben auch unterschiedliche Namen in unterschiedlichen Ländern und trotzdem verwenden wir denselben tag). Im Prinzip lassen sich alle Systeme einteilen in Punktförmige- (PZB) und Ständige Beeinflussungen (LZB). Daher kann man sich das verwendete System in einem anderen Land in der Regel herleiten, da es meist pro Typ eine Entsprechung gibt. Allerdings gibt es auch Länder, in denen verschiedene Ausführungen verwendet werden. Vielleicht könnte man das Tagging so regeln: railway:pzb=yes bedeutet, dass das Gleis mit PZB (in Deutschland) bzw. der jeweiligen Entsprechung im betreffenden Land ausgestattet ist. In Ländern, in denen verschiedene oder anders arbeitende Systeme verwendet werden, lässt sich das genauer spezifizieren: railway:pzb=System Grundsätzlich interessant ist vor allem, ob die Zugbeeinflussung punkt- oder linienförmig ist, und meiner Meinung drücken die Abkürzungen PZB und LZB sehr gut diesen Unterschied aus. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Ich sehe es als großen Beitrag vom OSM, dass Google gezwungen war, da nachzubessern. Profitieren tuen so auch Leute von OSM, die unser Projekt garnicht kennen. Schön, dass der Wettstreit spannend bleibt. Mich würde mal interessieren, wieviele Euros sie dafür beim Bundesamt für Kartographie und Geodäsie hingeblättert haben. Aber als Bürger darf man ja sowas nicht erfahren. Grüße Tim Am 09.12.2011 10:51, schrieb Andi K: Ich bin gespannt, wie wir das organisatorisch auf die Beine stellen können, jetzt mit Google mitzuziehen und die Kommunen und Länder zu überzeugen, ihre Geobasisdaten zur Verfügung zu stellen. Denn Google maps nutzt die seit heute, die Vollständigkeit der Wege liegt bei fast 100% und das walk routing ist somit überall perfekt. Dazu: http://google-latlong.blogspot.com/2011/12/updating-maps-of-united-kingdom-germany.html Gruß, Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrancepass
Am 11. Dezember 2011 14:17 schrieb Klaus-Hermann Otto Stanislaus Plöger k.ploe...@gastradata.de: Moin Martin, probier das mal bei uns im Freibad. Viel Spass. ;-) -- Mit freundlichen Grüßen Klaus Klar gibt es solche Tore, aber meistens kann man deren Richtung auch mit einem oder 2 Handgriffen umdrehen (umbauen) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM License Change Plugin Update
Franz gr...@cip.ifi.lmu.de wrote: Danke! Gerade gestern hat bei mir ein Blick auf die ODBL Coverage Map für leichte Frustration gesorgt. Leider ist die ODBL Coverage Map mit mindestens einem Monat Rückstand hoffnungslos überaltert. Unglücklicherweise suggeriert sie eine Aktualität, die nicht gegeben ist. Es wird immer der letzte Tag, 12:00 Uhr als letztes Aktualisierungsdatum angegeben. Ich habe mal freundlich bei der im Impressum genannten Adresse angeklopft - leider ohne Antwort. Für die jetzt folgende Schlussphase würde man sich doch eine regelmässig aktualisierte Karte wünschen. Denn mit Potlatch und JOSM ist ein Überblick in größeren (ländlichen) Gebieten doch sehr mühselig. http://osm.informatik.uni-leipzig.de/map/ Gruß Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM License Change Plugin Update
Frederik Ramm frede...@remote.org wrote: ich habe das License Change-Plugin fuer JOSM angepasst. Es unterscheidet jetzt nicht mehr zwischen CT-Ablehner und noch unentschieden, denn wir kommen jetzt langsam in die Phase, in der beides aufs gleiche hinauslaeuft. Ist denn zu erwarten, dass die Splittings von Nicht-ODBL-Wegen richtig erkannt werden? Bakanntlich wird hierbei eine Hälfte - nämlich das neu erzeugte Objekt - als gut erkannt, obwohl es sich dabei nur um eine Kopie des alten Weges handelt. Gruß Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Andi K test9...@gmx.de wrote: Ich bin gespannt, wie wir das organisatorisch auf die Beine stellen können, jetzt mit Google mitzuziehen und die Kommunen und Länder zu überzeugen, ihre Geobasisdaten zur Verfügung zu stellen. Brauchen wir nicht. Denn Google maps nutzt die seit heute, die Vollständigkeit der Wege liegt bei fast 100% und das walk routing ist somit überall perfekt. Nö, dieselben Fehler wie in den amtlichen Karten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM License Change Plugin Update
Ich will Frederiks Anwort nicht vorweg nehmen, aber soweit ich weiss macht er da nichts. Man erkennt das an den Stützpunkten an solchen Wegstücken manuell meistens problemlos. Das ist allerdings auch der einzige Fall den man so einfach erkennt (von den möglichen Kombinationen von Split und Mergers mit Ablehner und Zustimern). Ich halte es deshalb für sehr wahrscheinlich, dass man das ganze Thema schlicht nicht automatisch behandeln wird (also auch bei der endgültigen Umstellung), nicht zuletzt weil man es so oder so nicht richtig machen kann, da die Changesets nicht genug Informationen über den eigentlichen Editvorgang enthalten. Simon Am 11.12.2011 18:10, schrieb Tirkon: Frederik Rammfrede...@remote.org wrote: ich habe das License Change-Plugin fuer JOSM angepasst. Es unterscheidet jetzt nicht mehr zwischen CT-Ablehner und noch unentschieden, denn wir kommen jetzt langsam in die Phase, in der beides aufs gleiche hinauslaeuft. Ist denn zu erwarten, dass die Splittings von Nicht-ODBL-Wegen richtig erkannt werden? Bakanntlich wird hierbei eine Hälfte - nämlich das neu erzeugte Objekt - als gut erkannt, obwohl es sich dabei nur um eine Kopie des alten Weges handelt. Gruß Tirkon ___ 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] Google maps nutzt Geobasisdaten
Am 11.12.2011 18:44, schrieb Tirkon: Ich bin gespannt, wie wir das organisatorisch auf die Beine stellen können, jetzt mit Google mitzuziehen und die Kommunen und Länder zu überzeugen, ihre Geobasisdaten zur Verfügung zu stellen. Brauchen wir nicht. So ganz pauschal würde ich das nicht ablehnen. Die ganzen offiziellen ID hätte ich schon ganz gerne. Auch gegen die Hauskoordinaten würde ich mich nicht wehren, auch wenn wir da schon besser geworden sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Am 11.12.2011 18:44, schrieb Tirkon: Andi Ktest9...@gmx.de wrote: Ich bin gespannt, wie wir das organisatorisch auf die Beine stellen können, jetzt mit Google mitzuziehen und die Kommunen und Länder zu überzeugen, ihre Geobasisdaten zur Verfügung zu stellen. Brauchen wir nicht. Finde ich schon. Da spart man sich 99,9% blöder Fleißarbeit. Es mag zwar mal entspannend sein paar Häuser über Bing zu erfassen, aber sooo geil ist das auch nicht. Sinnvoller wäre z.B. in der Zeit Wikipedia verlinkung, Namen von Läden, Öffnungszeiten, TelNr von Pois, www-seiten, ... Da nähme man besser die 99,5% guten amtlichen Daten und freut sich das in de der 'Open Data' Gedanke voran schreitet (wenn die Ämter die Daten freigeben würden, das es technisch geht haben sie ja wohl gerade bewiesen) Open Data voranzubringen ist ein guter Teil warum ich bei OSM mitmache. Wenn wir alles drin haben geben auch die Ämter nach. Irgendwie schon schade um die Mio h Fleißarbeit bereits vom Amt erfasste Daten nochmal zu erfassen. Aber warum sollte man noch weitere Mio h investieren - wenn die Daten freigegeben werden würden. Denn Google maps nutzt die seit heute, die Vollständigkeit der Wege liegt bei fast 100% und das walk routing ist somit überall perfekt. Nö, dieselben Fehler wie in den amtlichen Karten. Die kann man dann ja manuell rausnehmen. Ein Spaziergang von 1h braucht 2h+ Nachbearbeitung für's mappen. Wenn man nur noch schaut ob das alles korrekt ist wäre das weniger. Wie bereits von anderen genannt ist es auf dem Land doch schon bischen dünn. Wenn man dann noch annimmt das 100% korrekt eh nie erreicht wird so wäre ich zufriedener wenn wir die Daten auch haben könnten. Problem ist natürlich das man die nicht einfach so reinkippen kann, dafür ist .de schon viel zu gut erfasst. Aber z.B. Ortsweise als eine Möglichkeit, gerade auf dem Land ist in Örtchen zum Teil *gar nix*. Könnte man den Ort in Josm laden, prüfen, bereits erfasste Dubletten raus nehmen wäre das IMHO sehr gut. Dazu muß man beachten das außer paar Geographen die amtlichen Daten wahrscheinlich vollkommen ausreichen würden, gerade in Orten. Otto Normal User ist da eher Bodenständig, wenn er 1x in 10 Jahren was nicht gleich findet und fragen muß macht dem das gar nix. Ich weiß nicht ob die Beispiele von schlechten Daten Einzelfälle sind, die in Wald und Flur. Die könnte man ja erst nach besichtigung vor Ort rein nehmen. Nachteil ist natürlich das was wohl in .fr geschieht (soweit ich hier las). Das sich keiner Verantwortlich fühlt, nix macht da ja eh' schon da, etc. Könnte man evtl. ändern. Oder halt akzeptieren, besser als ein komplett unerfasstes Kaft. Das beste wäre (ferne Zukunft) das die Professionellen in den Ämtern ihre Daten in OSM eintragen. IMHO echtes Open Data. Ok, da wiehert dann der Amtsschimmel etwas öfter und die meinen immer recht zu haben - aber sowas gibt es heute ja auch schon in OSM. Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Andreas Neumann andr-neum...@gmx.net wrote: Und ans Aktuell halten will ich gar nicht erst denken... Hier möchte ich widersprechen. Gerade Neues zieht OSM-Mapper magisch an. Neue Straßen sind sehr häufig schon lange vor ihrer Eröffnung mit dem Fahrrad oder zu Fuß geloggt, bisweilen sogar schon in der Planungsphase bei OSM eingezeichnet. Am Tage der Eröffnung wird einfach das under construction gestrichen und schon kann sie vom Routenplaner und Navi genutzt werden. Sobald eine gewisse Grunderfassung bei OSM erst einmal vorliegt, sind die Änderungen ein Klacks. Ich finde diesen Vergleich nicht mehr, wo man die verschiedenen Kartendienste deutschlandweit auf neu eröffnete Hauptverkehrsstraßen auch auf dem Lande abgeklopft hat. In OSM waren alle - sogar die jüngsten aus den letzten Monaten drin, während andere Dienste noch nach zwei Jahren nichts davon wussten. Beispielsweise wird morgen die Toulouser Allee in Düsseldorf freigegeben, die es bei OSM schon ewig under construction gibt. Google hat sie noch nicht. Wenn das Teil dann noch von erheblicher Relevanz ist, findet man wegen der erwähnten Magie des Neuen auch gleich den Wikipedia Artikel dazu. http://sautter.com/map/?zoom=17lat=51.21005lon=6.67213layers=B00T http://de.wikipedia.org/wiki/Toulouser_Allee Gruß Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Peter peter@gmx.net wrote: Ich bin gespannt, wie wir das organisatorisch auf die Beine stellen können, jetzt mit Google mitzuziehen und die Kommunen und Länder zu überzeugen, ihre Geobasisdaten zur Verfügung zu stellen. Brauchen wir nicht. Finde ich schon. Da spart man sich 99,9% blöder Fleißarbeit. Ich bin gegen flächendeckende Importe und sehe mich da in guter Gemeinschaft mit gefühlt immer mehr OSMlern. Wer nämlich nicht 99,9% blöde Fleißarbeit in die Daten gesteckt hat, wird nicht für diese Daten brennen. Ich sehe selbst absurde Klein-Klein Diskussionen in OSM und Wikipedia als Hinweis darauf, dass die Leute brennen. Und das ist trotz allem möglicherweise damit verbundenen Ärger gut so. Und die positiven Reaktionen von außen zeigen, dass am Ende etwas Gutes dabei herauskommt. Flächendeckende Importe interessieren fast Niemanden. Es gibt dann kaum Maintainer. Ein OSMler, der Straßen abgefahren und eingezeichnet hat, der Ortsteile auf Vollständigkeit geprüft hat, wird vieles - so auch Meldungen in der Tagespresse oder im Internet im Kopf verorten und verbildlichen können. Es wird bei Autofahrten aufmerksamer sein, als gewöhnliche Autofahrer und sich dieses oder jenes aus der Nähe anschauen. Das wird nicht passieren, wenn er alles fertig vorgesetzt bekommt. Ich bin sicher: Hätten wir Deutschland importiert, würde hier kaum jemand diskutieren. Mein Fazit: Flächendeckende Importe töten die Community! Gruß Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnsteige
Moin! Am 11.12.2011 13:56, schrieb Klaus-Hermann Otto Stanislaus Plöger: Moin Nein, auf die richtigen Bezeichnungen umtaggen. Löschen ist immer ein Informationsverlust. Was sind denn die richtigen Bezeichnungen in den drei Beispielen? Ist Hamburg - Neumünster ein Name, eine Beschreibung oder nur eine Ortsangabe wie Straße Altdorf - Neudorf? A1, R11 steckt schon in Linienrelationen und wäre nicht verloren. Gibt es ein tag für Güterumgehungsbahn? usage=industrial passt nicht richtig. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
2011/12/9 Andi K test9...@gmx.de Dazu: http://google-latlong.blogspot.com/2011/12/updating-maps-of-united-kingdom-germany.html Oha, GMaps sieht jetzt etwas mehr nach einer Karte aus und nicht mehr wie eine einfache Visualisierung einer Routingdatenbank. Auch wenn GMaps für meinen Geschmack weiterhin zu blass und aktzentarm im Vergleich zu klassischen Straßenkarten ist. 2011/12/9 Andi K test9...@gmx.de Ich bin gespannt, wie wir das organisatorisch auf die Beine stellen können, jetzt mit Google mitzuziehen und die Kommunen und Länder zu überzeugen, ihre Geobasisdaten zur Verfügung zu stellen. Denn Google maps nutzt die seit heute, die Vollständigkeit der Wege liegt bei fast 100% und das walk routing ist somit überall perfekt. Also das einfache Importieren von amtlichen Kartenvektoren wäre doch langweilig. Allenfalls Daten von nicht so einfach zu mappenden Dingen wie Wasserläufe (da oft verrohrt) oder Grenzen könnten wir gebrauchen. Und Luftbilder - zum Luftbilmappen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrancepass
Martin Koppenhoefer schrieb: Am 11. Dezember 2011 14:17 schrieb Klaus-Hermann Otto Stanislaus Plöger k.ploe...@gastradata.de: Moin Martin, probier das mal bei uns im Freibad. Viel Spass. ;-) Klar gibt es solche Tore, aber meistens kann man deren Richtung auch mit einem oder 2 Handgriffen umdrehen (umbauen) Falls handelsübliche Drehkreuze gemeint sind: die mir bekannten haben eine Panikauslöse. Wenn man mit Schwung dagegenrennt (oder es sachte aushebt und nach außen drückt), klappt das Drehkreuz (reversibel) mitsamt Halterung nach außen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
2011/12/11 Peter peter@gmx.net Es mag zwar mal entspannend sein paar Häuser über Bing zu erfassen, aber sooo geil ist das auch nicht. Hey, Luftbildmapping macht durchaus Spaß! Da kann man bequem große Flächen von Zuhause erfassen. Und dann gezielt vor ort besuchen, was unklar geblieben ist. Sinnvoller wäre z.B. in der Zeit Wikipedia verlinkung, Namen von Läden, Öffnungszeiten, TelNr von Pois, www-seiten, ... Soo geil ist das aber nicht... Hey Moment, wir würden uns da gut ergänzen... :-D Und damit sind wir bei einem der Erfolgsrezepte von OSM: Jeder konzentriert sich auf das, was er am 'geilsten' findet und am Ende kommt da was ziemlich komplettes heraus. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance
Martin Koppenhoefer schrieb: Am 11. Dezember 2011 14:04 schrieb Andreas Labres l...@lab.at: Übrigens gibt's auch andere reine (nicht Not-) Ausgänge aus Museen, Kinos o.ä. Ob entrance=exit da der richtige Tag ist?! Vielleicht ein emergency_exit=yes an das entrance=main hängen? malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnsteige
2011/12/10 Peter Wendorff wendo...@uni-paderborn.de - Wenn mehr Details vorhanden sind, ist Variante 2 besser. Ich hab gestern z.B. am Paderborner Hauptbahnhof (vgl. http://www.openstreetmap.org/?lat=51.712657lon=8.740178zoom=18layers=M) von Variante 1 auf Variante 2 umgestellt, weil das für das korrekte Einzeichnen der Treppenaufgänge notwendig war. (mit den Fußwegen, die die ways miteinander verbinden, bin ich so auch noch nicht glücklich...) Ein Nachteil ist dabei natürlich, dass man die Bahnsteignummer so nicht gut erfassen kann. ref=2;3 ist doch schon ein ziemlicher Notbehelf. Und z.B. bei Blindenrouting zu Bahnsteig 2 wäre es schon wichtig, ob es am Ende heißt Jetzt links halten. oder Jetzt rechts halten.. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
am Sonntag, 11. Dezember 2011 um 20:13 schrieb Tirkon: Ich bin sicher: Hätten wir Deutschland importiert, würde hier kaum jemand diskutieren. Mein Fazit: Flächendeckende Importe töten die Community! Ja, siehe USA und Tiger-Import. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
2011/12/11 Martin Koppenhoefer dieterdre...@gmail.com Das hier dokumentierte Schema der OpenRailwayMap: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Tagging Wenn da ein neues Tagginschema entwickelt wird, sollte man das IMHO innerhalb des Proposal-Systems entwickeln. Wobei ich das als Eisenbahn-Interesierter noch nicht so toll finde. Im Prinzip lassen sich alle Systeme einteilen in Punktförmige- (PZB) und Ständige Beeinflussungen (LZB). Daher kann man sich das verwendete System in einem anderen Land in der Regel herleiten, da es meist pro Typ eine Entsprechung gibt. Allerdings gibt es auch Länder, in denen verschiedene Ausführungen verwendet werden. Vielleicht könnte man das Tagging so regeln: railway:pzb=yes bedeutet, dass das Gleis mit PZB (in Deutschland) bzw. der jeweiligen Entsprechung im betreffenden Land ausgestattet ist. In Ländern, in denen verschiedene oder anders arbeitende Systeme verwendet werden, lässt sich das genauer spezifizieren: railway:pzb=System Grundsätzlich interessant ist vor allem, ob die Zugbeeinflussung punkt- oder linienförmig ist, und meiner Meinung drücken die Abkürzungen PZB und LZB sehr gut diesen Unterschied aus. So einfach ist das nicht. Um so ein System zu nutzen braucht ein Triebfahrzeug exakt die entsprechende Ausrüstung dafür, nicht einfach eine Ausrüstung für eine punktuelle Zugbeeinflussung im allgemeinen. Oftmals ist die Ausrüstung mit einem bestimmten System zwingende Vorraussetzung um dort fahren zu dürfen. Dann hat jedes System auch noch andere Fähigkeiten und Funktionsumfang. Eine Strecke kann auch mehrere Systeme gleichzeitig haben. Und z.B. ETCS passt in dieses System überhaupt nicht hinein. Es wird im Regelfall (derzeit noch) zusätzlich zu bestehenden Systemen eingebaut und je nach Level hat es sowohl PZB-Elemente (Eurobalisen) und LZB-Elemente (Euroloop). Die Grundlage von ETCS ist aber etwas, was in Deutschland schonmal als FZB - Funkzugbeeinflussung - entwickelt wurde. Die Steuerung der Züge über ein GSM-Netz. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Hallo, On 12/11/2011 08:13 PM, Tirkon wrote: Ich bin gespannt, wie wir das organisatorisch auf die Beine stellen können, jetzt mit Google mitzuziehen und die Kommunen und Länder zu überzeugen, ihre Geobasisdaten zur Verfügung zu stellen. Brauchen wir nicht. Finde ich schon. Da spart man sich 99,9% blöder Fleißarbeit. Ich bin gegen flächendeckende Importe und sehe mich da in guter Gemeinschaft mit gefühlt immer mehr OSMlern. Ja, ich teile diese Auffassung uneingeschraenkt. Wenn uns Kommunen und Laender ihre Geobasisdaten zur Verfuegung stellen, dann koennen wir damit nette Abgleiche berechnen und rausfinden, wo uns vielleicht noch was fehlt oder so - aber einen Import wird es bestimmt nicht geben. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Frederik Ramm frede...@remote.org wrote: Ja, ich teile diese Auffassung uneingeschraenkt. Ich sehe die Probleme von Imports finde diese aber nicht unbedingt schlecht wenn sich jemand dafür verantwortlich fühlt. Letzteres geht selbstredend natürlich nur für kleinere Datenmengen. Der Datenstand in Deutschland ist ohnehin so, dass man nur ganz wenige Daten einfach so importieren könnte. Ein Beispiel könnten Hausnummern sein, aber selbst da geht das nur noch manuell. Bei Wald- und Wirtschaftswegen hingegen könnte ein Import sogar kontraproduktiv sein, denn dort wo diese Wege bei OSM erfasst sind dürfte die Übereinstimmung mit der Realität erheblich besser sein als bei den amtlichen Daten. Jedenfalls ist das die Beobachtung die ich bei meinen kurzen tests mit Google im Raum Karlsruhe gemacht habe. Fehler sollten wir definitv keine importieren, da haben wir selber schon genug davon :) Gruss Sven -- Unix is simple and coherent, but it takes a genius – or at any rate a programmer – to understand and appreciate the simplicity (Dennis M. Ritchie) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: JOSM License Change Plugin Update
Am 11.12.2011 04:23, schrieb Frederik Ramm: ich habe das License Change-Plugin fuer JOSM angepasst. Es unterscheidet jetzt nicht mehr zwischen CT-Ablehner und noch unentschieden, denn wir kommen jetzt langsam in die Phase, in der beides aufs gleiche hinauslaeuft. Kann man das für Potlatch auch so machen? Wäre toll. Das Farbschema ist nun: rot = Objekt von Nichtzustimmer erzeugt; orange = Objekt von Zustimmer erzeugt, aber spaeter von Nichtzustimmer bearbeitet; gelb = wie orange, aber die Nichtzustimmer-Bearbeitung ist vernachlaessigbar. Sehr nützlich. Es wird ausserdem eine weltweite, in den gleichen Farben gezeichnete Uebersichtskarte geben, das braucht aber noch ein paar Tage. Sehr gut. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Am 11.12.2011 um 22:20 schrieb Robert S. osm-m...@autobahnen-europa.eu: Im Prinzip lassen sich alle Systeme einteilen in Punktförmige- (PZB) und Ständige Beeinflussungen (LZB). Daher kann man sich das verwendete System in einem anderen Land in der Regel herleiten, da es meist pro Typ eine Entsprechung gibt. Allerdings gibt es auch Länder, in denen verschiedene Ausführungen verwendet werden. Vielleicht könnte man das Tagging so regeln: railway:pzb=yes bedeutet, dass das Gleis mit PZB (in Deutschland) bzw. der jeweiligen Entsprechung im betreffenden Land ausgestattet ist. In Ländern, in denen verschiedene oder anders arbeitende Systeme verwendet werden, lässt sich das genauer spezifizieren: railway:pzb=System Grundsätzlich interessant ist vor allem, ob die Zugbeeinflussung punkt- oder linienförmig ist, und meiner Meinung drücken die Abkürzungen PZB und LZB sehr gut diesen Unterschied aus. So einfach ist das nicht. Um so ein System zu nutzen braucht ein Triebfahrzeug exakt die entsprechende Ausrüstung dafür, nicht einfach eine Ausrüstung für eine punktuelle Zugbeeinflussung im allgemeinen. Oftmals ist die Ausrüstung mit einem bestimmten System zwingende Vorraussetzung um dort fahren zu dürfen. Dann hat jedes System auch noch andere Fähigkeiten und Funktionsumfang. Eine Strecke kann auch mehrere Systeme gleichzeitig haben. Da hast du mich wohl nicht ganz verstanden. Natürlich weiss ich, dass die Systeme nicjt kompatibel zueinander sind. Ich versuche nochmal kurz, meinen Gedanken zu beschreiben: Grundsätzlich lassen sich alle Systeme in punkt- und linienförmige Systeme unterteilen. Mit dem Tag railway:pzb=yes würde ich also bei einem Gleis angeben, dass ein punktförmiges System verwendet wird. Ist dieses Gleis in Deutschland, dann kann ich davon ausgehen, dass PZB verwendet wird. Liegt dieses Gleis in einem anderen Land, dann kann ich davon ausgehen, dass das punktförmig arbeitende System des jeweiligen Landes verwendet wird. Meistens existieren nämlich in anderen Ländern nach ähnlichem Prinzip arbeitende Systeme, sodass man an Land und Typ (punkt-/linienförmig) das exakte System ermitteln kann. Leider gibt es auch Sonderfälle, in denen es mehrere Systeme in einem Land gibt. Da gibt man dann statt yes den Namen des Systems an. Einfacher wäre es vielleicht, einfach railway:sicherungssystem=yes zu setzen, doch bei so vielen unterschiedlichen Systemen weltweit wäre es dann schwierig abzufragen, ob eine Strecke nun eine PZB- oder LZB-ähnliche Sicherungstechnik hat oder nicht. Und z.B. ETCS passt in dieses System überhaupt nicht hinein. Es wird im Regelfall (derzeit noch) zusätzlich zu bestehenden Systemen eingebaut und je nach Level hat es sowohl PZB-Elemente (Eurobalisen) und LZB-Elemente (Euroloop). ETCS behandle ich bereits gesondert (siehe Wikiseite). Das Sysrem ist einfach zu anders aufgebaut und passt nicht mehr richtig in das Schema wie oben beschrieben, vor allem durch verschiedene Level, etc. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taginfo zeigt jetzt Tag-Kombinationen an
Hi! Der häufigste Erweiterungswunsch für Taginfo war die Anzeige von Tag-Kombinationen (also nicht nur Key-Kombinationen, wie es das schon lange gibt). Ich hab das jetzt eingebaut. Angezeigt werden aber nur die häufigsten Kombinationen der häufigsten Tags. Alle Kombinationen der 60 Millionen verschiedenen Tags anzuzeigen, das wäre zu aufwändig. Beispiel: http://taginfo.openstreetmap.org/tags/highway=residential#combinations Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Endlich amtliche Definition der Autobahnähnlichen Straßen
Moin, ob eine Straße in Deutschland amtlich als Autobahnähnliche Straße (=OSM trunk) definiert ist, ließ sich bisher nur mutmaßen. Inzwischen haben Bundestag und Bundesrat endlich eine eindeutiges Merkmal verabschiedet. Die Quelle hierfür ist nun auch im Internet zu finden. Demnach ist das gelbe oder weiße Ausfahrt-Schild nur an Autobahnähnlichen Straßen aufzustellen. Da die meisten von uns ohnehin einen trunk von der autobahnähnlichen Beschilderung abgeleitet haben, ändert sich für OSM hier nichts. Allerdings ist die bisherige Praxis damit jetzt sozusagen amtlich bestätigt. Nähere Infos habe ich ins Wiki eingebaut: http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dtrunk#Beschilderung ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Remapping Anleitung unbrauchbar?
Moin, korrigiert mich bitte, wenn ich falsch liege: http://wiki.openstreetmap.org/wiki/Remapping sehe ich als ein bisshen blauäugig. Da wird munter drauflos gelöscht und ersetzt, ohne darauf hinzuweisen, dass jeder der gelöschten nodes und ways Mitglied einer Relation und diese wiederum Mitglied in einer Elternrelation sein kann, deren Struktur man vor irgendeinem Löschvorgang studieren und notieren sowie später wieder herstellen müsste. Zudem wird Potlatch für diese Aufgabe empfohlen. Potlatch ist aber beispielsweise nicht in der Lage, Elternrelationen oder Reihenfolgen von Mitgliedern in Relationen anzuzeigen, geschweige denn zu editieren und ist somit unbrauchbar für diese Aufgabe. Ich hatte das früher einmal näher begründet: http://wiki.openstreetmap.org/wiki/DE:User:Tirkon/ODbL-License:_How_to_avoid_Trash_Mapping#Die_schwierige_Methode Mit dieser Anleitung sowie mit Potlatch wird man also beispielsweise Relationen von ÖPNV, Autobahnen, Bundesstraßen, Radrouten und Grenzen verstümmeln. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Endlich amtliche Definition der Autobahnähnlichen Straßen
Am 12.12.2011 01:15, schrieb Tirkon: als Autobahnähnliche Straße (=OSM trunk) Ich will jetzt nicht wieder ein Monster-Diskussion anstoßen, aber der Umkehrschluss gilt sicher nicht. Wenn man sich die englische Original-Definition ansieht: http://wiki.openstreetmap.org/wiki/Key:highway Zeile **highway == trunk Important roads that aren't motorways. Typically maintained by central, not local government. Need not necessarily be a divided highway. Eigne Übersetzung: Wichtige Straßen, welche nit Autobahnen sind. Tpischerweise verwaltet durch zentraler nicht lokaler Verwaltung. Muss keine Straße mit baulicher Trennung der Fahrspuren sein. M.E. trifft die Entscheidung des Bundes-tags/-rats also viel mehr auf motorroad == yes zu! Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance
Am 11. Dezember 2011 14:00 schrieb Tobias Knerr o...@tobias-knerr.de: Am 11.12.2011 13:45, schrieb Martin Koppenhoefer: Vorschlag: Ändern in entrance=emergency_exit +1, emergency_exit ist deutlich klarer und wir sollten es so schnell wie möglich einführen. Die bisher gerade mal 96 existierenden entrance=emergency sollten bei einer Umstellung kein ernstes Problem sein. Ich habe keine Problem mit der Änderung. Jedoch habe ich, wie Martin schon angemerkt hat, die kürzerer Variante bevorzugt. Ciao ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnsteige
Am 11.12.2011 01:37, schrieb Martin Koppenhoefer: Am 10. Dezember 2011 23:29 schrieb Stephan Wolffs.wo...@web.de: Eine gute Frage. Bei zwei oder mehr getrennt erfassten Gleisen kann man keinen sinnvollen Punkt mehr finden, sondern sollte railway=station besser als Fläche anlegen. sehe ich im Prinzip auch so. Aber welche Fläche umfasst der Bahnhof: - die Bahnsteige - Bahnsteige und danebenliegende Gleise - Bahnsteige, Gleise und Gebäude mind. die vorgenannten, wenn man es durch andere Quellen besser weiss (z.B. Bahnbetriebsordnung) kann man die Schätzung dahingehend verbessern. Da sich unsere Karten vornehmlich an ÖPNV-Nutzer richten, ist ein label-Knoten am Zugang, Bahnhofsgebäude (sofern aktiv genutzt) oder Mitte der Bahnsteige IMHO am sinnvollsten. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnsteige
Am 11.12.2011 21:52, schrieb Robert S.: 2011/12/10 Peter Wendorffwendo...@uni-paderborn.de - Wenn mehr Details vorhanden sind, ist Variante 2 besser. Ich hab gestern z.B. am Paderborner Hauptbahnhof (vgl. http://www.openstreetmap.org/?lat=51.712657lon=8.740178zoom=18layers=M) von Variante 1 auf Variante 2 umgestellt, weil das für das korrekte Einzeichnen der Treppenaufgänge notwendig war. (mit den Fußwegen, die die ways miteinander verbinden, bin ich so auch noch nicht glücklich...) Ein Nachteil ist dabei natürlich, dass man die Bahnsteignummer so nicht gut erfassen kann. ref=2;3 ist doch schon ein ziemlicher Notbehelf. Und z.B. bei Blindenrouting zu Bahnsteig 2 wäre es schon wichtig, ob es am Ende heißt Jetzt links halten. oder Jetzt rechts halten.. Es heißt ja auch nicht Bahnsteig 2, sondern Gleis 2 (zumindest bei der DB). Und das liegt am gleichen Bahnsteig wie Gleis 3, nur gegenüber, oder weiter hinten. Manche Bahnsteige haben auch vier Gleise, und in Hagen Hbf halten Fernzüge an zwei hintereinanderliegenden Gleisen gleichzeitig. Deshalb gebe ich in solchen Fällen dem Gleis die Nummer, und das Routing soll auf den Bahnstieg führen, der dem Gleis am nächsten liegt. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Remapping Anleitung unbrauchbar?
Hallo, On 12/12/2011 02:06 AM, Tirkon wrote: http://wiki.openstreetmap.org/wiki/Remapping sehe ich als ein bisshen blauäugig. Da wird munter drauflos gelöscht und ersetzt, ohne darauf hinzuweisen, dass jeder der gelöschten nodes und ways Mitglied einer Relation und diese wiederum Mitglied in einer Elternrelation sein kann, deren Struktur man vor irgendeinem Löschvorgang studieren und notieren sowie später wieder herstellen müsste. Die Seite ist ja auch von jemandem geschrieben, der Relationen im wesentlichen fuer unnoetiges Beiwerk haelt ;) Und, mal ganz ehrlich gesagt, ausserhalb Deutschlands sind sie das eigentlich auch. Vielleicht von Multipolygonen mal abgesehen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
