Liebe Mapper,
ich bin seit geraumer Zeit im Umfeld von Luzern etwas am Mappen. Dabei gibt es hier einige Standseilbahnen (z.B. Alpnach-Pilatus, Sonnenberg Kriens), für welche es gemäss meinen Recherchen keine sinnvollen Tags gibt. Da es sich eindeutig um eine schienengeführte Bahn am Boden und nicht eine Schwebebahn handelt ist das Tag "aerialway=cable_car" nicht zutreffend. Ich habe deshalb eine der genannten Bahnen mit "railway=funicular" getaggt. Ist das i.O. oder habe ich da etwas nicht mitgeschnitten? Sollte ich das vorgeschlagene Tag irgendwo im OSM-Wiki vorschlagen/dokumentieren, und falls ja wo?
Danke für die Rückmeldungen
FischersFritz
Marc Zoss wrote:
Liebe Mapper,
ich bin seit geraumer Zeit im Umfeld von Luzern etwas am Mappen. Dabei gibt es hier einige Standseilbahnen (z.B. Alpnach-Pilatus, Sonnenberg Kriens), für welche es gemäss meinen Recherchen keine sinnvollen Tags gibt. Da es sich eindeutig um eine schienengeführte Bahn am Boden und nicht eine Schwebebahn handelt ist das Tag "aerialway=cable_car" nicht zutreffend. Ich habe deshalb eine der genannten Bahnen mit "railway=funicular" getaggt. Ist das i.O. oder habe ich da etwas nicht mitgeschnitten? Sollte ich das vorgeschlagene Tag irgendwo im OSM-Wiki vorschlagen/dokumentieren, und falls ja wo?
Ich würde einfach railway=light_rail oder gar railway=rail verwenden. Es handelt sich ja um Eisenbahnen. Dass der Antrieb per Seilzug implementiert ist, würde ich fürs Haupttag erstmal ignorieren.
Remo
Hi Remo,
Ich würde einfach railway=light_rail oder gar railway=rail verwenden. Es handelt sich ja um Eisenbahnen. Dass der Antrieb per Seilzug implementiert ist, würde ich fürs Haupttag erstmal ignorieren.
Ich find das eine wichtige Information. Funis sind keine normalen Züge, sondern sie fahren irgendwo den Berg rauf, ziemlich steil sogar. Meistens haben sie auch einen eingenen (nicht zwangsläufig mit dem restlichen Schienenverkehr abgestimten) Fahrplan.
Grüsse Raphael
Raphael Studer wrote:
Ich find das eine wichtige Information. Funis sind keine normalen Züge, sondern sie fahren irgendwo den Berg rauf, ziemlich steil sogar. Meistens haben sie auch einen eingenen (nicht zwangsläufig mit dem restlichen Schienenverkehr abgestimten) Fahrplan.
Ja, Standseilbahnen sind meist nicht ganz in das restliche Eisenbahnnetz integriert und haben seltsam steile und meist auch kurze Trassen. Dies geht aber bereits aus der geographischen Erfassung der Trasse hervor (kurzes, abgesetztes Stück Eisenbahn).
Ich habe natürlich nichts gegen ein zusätzliche Attribut-Tag, das den Typ genauer beschreibt, aber in erster Linie ist es eine Eisenbahn. Zahnradbahnen behandeln wir doch auch so.
Übrigens sind auch auf den schweiz. topographischen Karten Standseilbahnen als Eisenbahnen eingezeichnet.
Remo
Ja, Standseilbahnen sind meist nicht ganz in das restliche Eisenbahnnetz integriert und haben seltsam steile und meist auch kurze Trassen. Dies geht aber bereits aus der geographischen Erfassung der Trasse hervor (kurzes, abgesetztes Stück Eisenbahn).
Ich habe natürlich nichts gegen ein zusätzliche Attribut-Tag, das den Typ genauer beschreibt, aber in erster Linie ist es eine Eisenbahn.
Dem ist natürlich so, da aber nichts dagegen spricht, diese Bahnen genauer zu spezifizieren.
Zahnradbahnen behandeln wir doch auch so.
Da könnten wir doch auch gleich noch ein neues Tag dazu machen.
Übrigens sind auch auf den schweiz. topographischen Karten Standseilbahnen als Eisenbahnen eingezeichnet.
Da sind die von Swisstopo aber selber schuld :)
Ich bin im Moment mit qpeso daran die Darstellung der Geleise neu zu machen, damit diese besser unterschieden werden können.
Grüsse Raphael
Marc Zoss schrieb:
Gut ich habe mich über den aktuellen Stand der Diskussion kundig gemacht und railway=funicular ist tatsächlich ein proposed Feature, und eine Mehrheit spricht sich für ein railway=funicular tag aus: http://wiki.openstreetmap.org/index.php/Proposed_features/Funicular_railway. Ich finde das auch sinnvoll und verwende das mal so.
Grüsse Marc
Raphael Studer wrote:
Ja, Standseilbahnen sind meist nicht ganz in das restliche Eisenbahnnetz integriert und haben seltsam steile und meist auch kurze Trassen. Dies geht aber bereits aus der geographischen Erfassung der Trasse hervor (kurzes, abgesetztes Stück Eisenbahn).
Ich habe natürlich nichts gegen ein zusätzliche Attribut-Tag, das den Typ genauer beschreibt, aber in erster Linie ist es eine Eisenbahn.
Dem ist natürlich so, da aber nichts dagegen spricht, diese Bahnen genauer zu spezifizieren.
Zahnradbahnen behandeln wir doch auch so.
Da könnten wir doch auch gleich noch ein neues Tag dazu machen.
Übrigens sind auch auf den schweiz. topographischen Karten Standseilbahnen als Eisenbahnen eingezeichnet.
Da sind die von Swisstopo aber selber schuld :)
Ich bin im Moment mit qpeso daran die Darstellung der Geleise neu zu machen, damit diese besser unterschieden werden können.
Bin dagegen das unter "rail" zu taggen, ein Renderer soll in erster Linie darstellen dass dort Gleise liegen ohne alle unterkategorien kennen zu müssen - für Anwendungen die die Bahn nicht als Verkehrsmittel nutzen reicht dass aus - ist aber dennoch wichtig als Hinderniss oder Gefahrenstelle dargestellt zu werden.
Was auch noch fehlt ist die Information "Oberleitung". Garry
Raphael Studer wrote:
Ich habe natürlich nichts gegen ein zusätzliche Attribut-Tag, das den Typ genauer beschreibt, aber in erster Linie ist es eine Eisenbahn.
Dem ist natürlich so, da aber nichts dagegen spricht, diese Bahnen genauer zu spezifizieren.
Zahnradbahnen behandeln wir doch auch so.
Da könnten wir doch auch gleich noch ein neues Tag dazu machen.
Was würde denn gegen railway=rail in Kombination mit transmission=cable (bzw. rack) oder Ähnlichem sprechen? Die Eigenschaft, dass es sich grundsätzlich um eine Eisenbahn handelt, bleibt für alle Anwendungen erhalten, und der Typ wird trotzdem genauer spezifiziert. Es muss doch nicht für jedes Detail gleich ein neuer Haupttag erfunden werden.
Remo
Remo schrieb:
Was würde denn gegen railway=rail in Kombination mit transmission=cable (bzw. rack) oder Ähnlichem sprechen? Die Eigenschaft, dass es sich grundsätzlich um eine Eisenbahn handelt, bleibt für alle Anwendungen erhalten, und der Typ wird trotzdem genauer spezifiziert. Es muss doch nicht für jedes Detail gleich ein neuer Haupttag erfunden werden.
Würde sogar noch weitergehen und gleich ein railway=yes daraus machen und alles weitere dann in anderen 'Tags spezifizieren..
Garry
Hi Fritz,
ich bin seit geraumer Zeit im Umfeld von Luzern etwas am Mappen. Dabei gibt es hier einige Standseilbahnen (z.B. Alpnach-Pilatus, Sonnenberg Kriens), für welche es gemäss meinen Recherchen keine sinnvollen Tags gibt. Da es sich eindeutig um eine schienengeführte Bahn am Boden und nicht eine Schwebebahn handelt ist das Tag "aerialway=cable_car" nicht zutreffend. Ich habe deshalb eine der genannten Bahnen mit "railway=funicular" getaggt. Ist das i.O. oder habe ich da etwas nicht mitgeschnitten? Sollte ich das vorgeschlagene Tag irgendwo im OSM-Wiki vorschlagen/dokumentieren, und falls ja wo?
Ich bin mir sicher, dass es mal ein Funicular Tag oder was ähnliches gab. Diskussionen darüber gabs auf jeden Fall. Es wird in der Schweiz auch bereits 2 mal eingesetzt. Ich würde es so taggen und dann auch gleich noch einen Wiki Beitrag dazu.
Grüsse Raphael
Marc Zoss schrieb:
Liebe Mapper,
ich bin seit geraumer Zeit im Umfeld von Luzern etwas am Mappen. Dabei gibt es hier einige Standseilbahnen (z.B. Alpnach-Pilatus, Sonnenberg Kriens), für welche es gemäss meinen Recherchen keine sinnvollen Tags gibt. Da es sich eindeutig um eine schienengeführte Bahn am Boden und nicht eine Schwebebahn handelt ist das Tag "aerialway=cable_car" nicht zutreffend. Ich habe deshalb eine der genannten Bahnen mit "railway=funicular" getaggt. Ist das i.O. oder habe ich da etwas nicht mitgeschnitten? Sollte ich das vorgeschlagene Tag irgendwo im OSM-Wiki vorschlagen/dokumentieren, und falls ja wo?
Wo Schienen liegen sollten diese auch dargestellt werden ohne dass die Renderer dafür irgendeine Spezialform der Bahn kennen muss, das sollte einem zusätzlichen Tag vorbehalten bleiben. Diese Bahn ist ein touristisches Ziel - um dort hin zu kommen ist es in erste Linie wichtig dass man sieht dass da eine Bahn ist und wo die Stationen liegen.
Garry
Ich fasse kurz zusammen.
Wo Schienen liegen sollten diese auch dargestellt werden ohne dass die Renderer dafür irgendeine Spezialform der Bahn kennen muss, das sollte einem zusätzlichen Tag vorbehalten bleiben. Diese Bahn ist ein touristisches Ziel - um dort hin zu kommen ist es in erste Linie wichtig dass man sieht dass da eine Bahn ist und wo die Stationen liegen.
Ich bin dafür dass wir die Realität abbilden und sich dann irgendwer darum kümmert dass die Renderer dies verstehen (in diesem speziellen Fall würde ich mich dafür anbieten). Wenn in der Realität ein Funi da ist, soll dass auch so getaggt werden.
Bin dagegen das unter "rail" zu taggen, ein Renderer soll in erster Linie darstellen dass dort Gleise liegen ohne alle unterkategorien kennen zu müssen - für Anwendungen die die Bahn nicht als Verkehrsmittel nutzen reicht dass aus - ist aber dennoch wichtig als Hinderniss oder Gefahrenstelle dargestellt zu werden.
Ich versteh jetzt da den Zusammenhang nicht ganz. Eine "Nicht-Verkehrsmittel-Anwendung" sieht anhan des Rail Tags dass da ein Hindernis oder eine Gefahrenstelle sein kann. Wird das jedoch anders als mit Rail, sieht dass die "Nicht-Verkehrs-Anwendung" nicht.
Was auch noch fehlt ist die Information "Oberleitung".
Wo "fehlt" diese Information?
Grüsse Raphael
Raphael Studer schrieb:
Ich fasse kurz zusammen.
Wo Schienen liegen sollten diese auch dargestellt werden ohne dass die Renderer dafür irgendeine Spezialform der Bahn kennen muss, das sollte einem zusätzlichen Tag vorbehalten bleiben. Diese Bahn ist ein touristisches Ziel - um dort hin zu kommen ist es in erste Linie wichtig dass man sieht dass da eine Bahn ist und wo die Stationen liegen.
Ich bin dafür dass wir die Realität abbilden und sich dann irgendwer darum kümmert dass die Renderer dies verstehen (in diesem speziellen Fall würde ich mich dafür anbieten). Wenn in der Realität ein Funi da ist, soll dass auch so getaggt werden.
Klar, auch ich will die Realität abbilden. Nur sollte es nicht sein dass eine "Tagverfeinerung" dazu führt dass eine bereits erfasste Bahn wieder von den Monitoren verschwindet weil ein praktisch unbekannter Typ verwendet wurde, der unter Umständen nie in die Renderer-Regeln berücksichtigt wird. Derjenige der einen Tagtyp definiert ist mal nicht der, der auch die Anwendungen anpasst - schon gar nicht bei der Vielzahl der Anwedungen die es inzwischen gibt. Auch für den Ersterfasser ist es höchst frustrierend wenn er sich viel Arbeit mit der Geoerfassung der Bahn gemacht hat und ein Ordnungsfanatiker taggt die jetzt so um dass die wichtigste Info "Hier liegen Schienen" von den Anwendungen nicht mehr erkannt wird.
Bin dagegen das unter "rail" zu taggen, ein Renderer soll in erster Linie darstellen dass dort Gleise liegen ohne alle unterkategorien kennen zu müssen - für Anwendungen die die Bahn nicht als Verkehrsmittel nutzen reicht dass aus - ist aber dennoch wichtig als Hinderniss oder Gefahrenstelle dargestellt zu werden.
Ich versteh jetzt da den Zusammenhang nicht ganz. Eine "Nicht-Verkehrsmittel-Anwendung" sieht anhan des Rail Tags dass da ein Hindernis oder eine Gefahrenstelle sein kann. Wird das jedoch anders als mit Rail, sieht dass die "Nicht-Verkehrs-Anwendung" nicht.
Wenn es so implementiert wird dass "railway" bei unbekanntem Typ gerendert wird, ja. Allerdings wäre dann ein railway=no nicht mehr möglich, was man sich als allgemeingültige Regel aber eigentlich offenhalten sollte.
Was auch noch fehlt ist die Information "Oberleitung".
Wo "fehlt" diese Information?
'In der Kartendarstellung Osmarender/Mappnik - oder gibt es da inzwischen eine Lösung?
Garry
Ich bin dafür dass wir die Realität abbilden und sich dann irgendwer darum kümmert dass die Renderer dies verstehen (in diesem speziellen Fall würde ich mich dafür anbieten). Wenn in der Realität ein Funi da ist, soll dass auch so getaggt werden.
Klar, auch ich will die Realität abbilden. Nur sollte es nicht sein dass eine "Tagverfeinerung" dazu führt dass eine bereits erfasste Bahn wieder von den Monitoren verschwindet weil ein praktisch unbekannter Typ verwendet wurde, der unter Umständen nie in die Renderer-Regeln berücksichtigt wird. Derjenige der einen Tagtyp definiert ist mal nicht der, der auch die Anwendungen anpasst - schon gar nicht bei der Vielzahl der Anwedungen die es inzwischen gibt.
Ich find das verschwinden der Bahnen von den Monitoren weniger tragisch, als Dinge die Falsch getagt sind und nachher geändert werden müssen. Die Wahrscheinlichkeit, dass die Renderer angepasst werden ist um ein x-faches Grösser als dass die Tags angepasst werden.
Auch für den Ersterfasser ist es höchst frustrierend wenn er sich viel Arbeit mit der Geoerfassung der Bahn gemacht hat und ein Ordnungsfanatiker taggt die jetzt so um dass die wichtigste Info "Hier liegen Schienen" von den Anwendungen nicht mehr erkannt wird.
Natürlich ist es keine befriedigende Lösung wenn die Tags alle Nase lang ändern. Aber solange das Projekt nicht in einem mehr oder weniger stabilen Zustand ist (90% der Objekte einigermassen sinvoll abgebildet) wird sich das nicht ändern lassen.
Wenn der Ordnungsfanatiker weiss um was für Schienen es sich dort handelt, hab ich kein Problem damit wenn er diese anpasst. Das ist mir Lieber als dass es zwar angezeigt aber falsch getagt ist.
Bin dagegen das unter "rail" zu taggen, ein Renderer soll in erster Linie darstellen dass dort Gleise liegen ohne alle unterkategorien kennen zu müssen - für Anwendungen die die Bahn nicht als Verkehrsmittel nutzen reicht dass aus - ist aber dennoch wichtig als Hinderniss oder Gefahrenstelle dargestellt zu werden.
Ich versteh jetzt da den Zusammenhang nicht ganz. Eine "Nicht-Verkehrsmittel-Anwendung" sieht anhan des Rail Tags dass da ein Hindernis oder eine Gefahrenstelle sein kann. Wird das jedoch anders als mit Rail, sieht dass die "Nicht-Verkehrs-Anwendung" nicht.
Wenn es so implementiert wird dass "railway" bei unbekanntem Typ gerendert wird, ja. Allerdings wäre dann ein railway=no nicht mehr möglich, was man sich als allgemeingültige Regel aber eigentlich offenhalten sollte.
Im Moment finde ich es nicht seehr nütztlich wenn es "generelle" Regeln gibt. So lässt sich viel einfacher erkennen wo noch nachholbedarf bei den renderern besteht.
Was auch noch fehlt ist die Information "Oberleitung".
Wo "fehlt" diese Information?
'In der Kartendarstellung Osmarender/Mappnik - oder gibt es da inzwischen eine Lösung?
Soweit ich weiss gibts dazu im Moment nichts. Was ein ansporn sein könnte sich nochmals damit auseinander zu setzen.
Grüsse Raphael
Raphael Studer schrieb:
Ich bin dafür dass wir die Realität abbilden und sich dann irgendwer darum kümmert dass die Renderer dies verstehen (in diesem speziellen Fall würde ich mich dafür anbieten). Wenn in der Realität ein Funi da ist, soll dass auch so getaggt werden.
Klar, auch ich will die Realität abbilden. Nur sollte es nicht sein dass eine "Tagverfeinerung" dazu führt dass eine bereits erfasste Bahn wieder von den Monitoren verschwindet weil ein praktisch unbekannter Typ verwendet wurde, der unter Umständen nie in die Renderer-Regeln berücksichtigt wird. Derjenige der einen Tagtyp definiert ist mal nicht der, der auch die Anwendungen anpasst - schon gar nicht bei der Vielzahl der Anwedungen die es inzwischen gibt.
Ich find das verschwinden der Bahnen von den Monitoren weniger tragisch, als Dinge die Falsch getagt sind und nachher geändert werden müssen. Die Wahrscheinlichkeit, dass die Renderer angepasst werden ist um ein x-faches Grösser als dass die Tags angepasst werden.
Auch für den Ersterfasser ist es höchst frustrierend wenn er sich viel Arbeit mit der Geoerfassung der Bahn gemacht hat und ein Ordnungsfanatiker taggt die jetzt so um dass die wichtigste Info "Hier liegen Schienen" von den Anwendungen nicht mehr erkannt wird.
Natürlich ist es keine befriedigende Lösung wenn die Tags alle Nase lang ändern. Aber solange das Projekt nicht in einem mehr oder weniger stabilen Zustand ist (90% der Objekte einigermassen sinvoll abgebildet) wird sich das nicht ändern lassen.
Wenn der Ordnungsfanatiker weiss um was für Schienen es sich dort handelt, hab ich kein Problem damit wenn er diese anpasst. Das ist mir Lieber als dass es zwar angezeigt aber falsch getagt ist.
Da sollte man schon noch unterscheiden zwischen "falsch" und nicht "vollständig".
Ich halte es für sinnvoll den Schwepunkt auf möglichst weit in die Fläche als punktuell besoners präzise taggen zu setzen. Bei letzterem hast Du auch das Problem dass Du mehr inkonsitensen in der Datenbank hast. Die Regeln ändern sich im laufe der Zeit so dass ein heute detailiert erfasster Bereich nicht mit einem morgen detailliert erfassten Bereich kompatibel ist, aber auch nicht so schnell korrigiert wird weil die Bereiche ja als vollständig gelten,
Wenn es so implementiert wird dass "railway" bei unbekanntem Typ gerendert wird, ja. Allerdings wäre dann ein railway=no nicht mehr möglich, was man sich als allgemeingültige Regel aber eigentlich offenhalten sollte.
Im Moment finde ich es nicht seehr nütztlich wenn es "generelle" Regeln gibt. So lässt sich viel einfacher erkennen wo noch nachholbedarf bei den renderern besteht.
Inzwischen schon - die Dantenbank ist über den Status einer reinen Erfassungsdatenbank hinaus und wird mehr und mehr auch angewendet.Da ist es ehr wichtig dass alle vorhandenen Verkehrsweg angezeigt werden als nur punktuelle besonders Präzise Daten darzustellen obwohl schon viel mehr Daten in der Fläche für die Masse brauchbar wären.
Gaary