Re: [Talk-de] Live-Map ÖPNV für Ulm/Neu-Ulm
Am Samstag, den 27.08.2016, 16:09 +0200 schrieb > Gibt es überhaupt noch derartige Live-Maps in anderen dt. Gemeinden / > für andere Verkehrsverbünde? Oder hat man sich mit dem Verweis auf > Bedrohungslagen und der Behauptung, das verunsichere Teile der > Bevölkerung, davon generell im OSM-Univerum distanziert? Kennst du TRAVIC (http://tracker.geops.ch/?z=6=1=1242914.2612=663 2341.6975=transport)? Dargestellt werden die Soll-Positionen auf Basis der Fahrplandaten. In Deutschland ist die Abdeckung relativ hoch, praktisch alles, was in der DB-Auskunft erscheint, wird auch auf der Karte dargestellt. Live-Daten gibt es aktuell leider nur in einigen Regionen außerhalb Deutschlands. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eisenbahn-Sprint(er) am Samstag, dem 13.2. u.A. in Frankfurt
Am Donnerstag, den 04.02.2016, 01:19 +0100 schrieb Hakuch: > > On 03.02.2016 12:46, Stefan Kaufmann wrote: > > Die Bahn ist so freundlich, ihren Teil dazu > > beizutragen und stellt dafuer ab dem Mittag im Bahnhof einen Raum > > mit > > Internet zur Verfuegung, > > und so freundlich, tickets auszugeben oder zu vergünstigen? Das wollte ich auch schon fragen, schließlich wurde von Vertretern der DB neulich etwas in dieser Richtung hier angekündigt: https://lists.ope nstreetmap.org/pipermail/talk-de/2015-December/112295.html Es wäre natürlich schön, wenn die DB finanziell beitragen würde, aber ich persönlich werde in jedem Fall nach Frankfurt kommen, auch wenn es keine vergünstigten Tickets für uns gäbe. Dank Semesterticket kann ich einen Teil der Strecke ohnehin kostenlos fahren. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] OpenLinkMap will be shut down
Hi everybody, some of you may know and use the project OpenLinkMap. For those who do not know it, just have a look at the wiki page http://wiki.openstreetmap.org/wiki/OpenLinkMap or try it at http://www.openlinkmap.org/. Now the bad news: On January 27, the project will be shut down. Due to technical reasons I disabled the data update some days ago, but the website will be accessible until January 27. There are the following reasons for my decision to stop the project: My focus switched to my other project OpenRailwayMap, so I have not enough time any more to develop the OpenLinkMap. The design is not up to date, the website is not responsive and the code is not very elegant, but I have not time to correct all the design mistakes. The final decision to stop the project right now was the situation that the domain expires on January 27. For a while I had the plan to stop the project in the feature, but now I do not want to spend money again to renew the domain for one or two years. The source code can be found in a repository on Github: https://github.com/rurseekatze/OpenLinkMap. You are free to take the code and continue the project on your own server. The domain openlinkmap.org will be available again soon, and there is no problem for me if someone would like to register it to continue the project under this name. I hope that you understand my decision. It is just a hobby project which takes a lot of my spare time and is mainly paid by my own money. Users who currently embed OpenLinkMap into their own websites using iframes should consider to remove that code from their websites. Thanks to all the people who supported this project by donations, code or their feedback! Regards Alex signature.asc Description: This is a digitally signed message part ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] OpenLinkMap wird eingestellt
Hallo zusammen, vielen dürfte das Projekt OpenLinkMap gut vertraut sein. Wer es nicht kennt: Einfach mal im Wiki unter http://wiki.openstreetmap.org/wiki/DE:OpenLinkMap nachlesen oder unter http://www.openlinkmap.org/ die Seite ausprobieren. Nun die schlechte Nachricht: Am 27. Januar wird das Projekt eingestellt . Aus technischen Gründen werden die Daten bereits seit einigen Tagen nicht mehr aktualisiert, die Webseite bleibt aber bis zum 27.01. erreichbar. Die Einstellung des Projekts hat folgende Gründe: Da mein Fokus mittlerweile auf der OpenRailwayMap liegt, fehlt mir die Zeit für eine Weiterentwicklung der OpenLinkMap. Das Design der Webseite ist mittlerweile nicht mehr ganz zeitgemäß, die Webseite ist nicht für mobile Geräte angepasst und der Code enthält auch so manche "Jugendsünden", die ich heute anders lösen würde, aber für deren Überarbeitung mir schlicht Zeit und Lust fehlen. Des weiteren entlastet die Einstellung der OpenLinkMap meinen Server, auf dem auch parallel die OpenRailwayMap gehostet wird. Der entscheidende Auslöser, das Projekt genau jetzt einzustellen, war das Auslaufen der Domain am 27. Januar. Da ich schon länger geplant hatte, das Projekt langsam auslaufen zu lassen, will ich nun nicht nochmal Geld in eine Verlängerung für ein oder zwei weitere Jahre stecken. Das Projekt kann gerne von einer anderen Person auf einem eigenen Server weiterbetrieben werden. Der gesamte Quellcode findet sich in einem Github-Repository: https://github.com/rurseekatze/OpenLinkMap. Da die Domain openlinkmap.org ja demnächst frei wird, kann gerne jemand anderes sie registrieren, falls derjenige das Projekt unter diesem Namen weiterführen will. Ich hoffe, meine Entscheidung ist nachvollziehbar, schließlich handelt es sich nur um ein Hobbyprojekt, das die leider begrenzte Freizeit in Anspruch nimmt und zum Großteil aus eigener Tasche bezahlt wird. Nutzer, die momentan die OpenLinkMap per iframe in eine andere Webseite einbinden, sollten daran denken, ihre Webseiten entsprechend anzupassen. Ich danke allen, die in der Vergangenheit das Projekt durch Spenden, Codebeiträge oder Feedback unterstützt haben! Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback zum Vorschlag einer möglichen Mappingaktion zu Aufzuggeodaten?
Hallo, Am Mittwoch, den 09.12.2015, 21:38 +0100 schrieb Michael Reichert: > Hallo Axel, hallo Sven, > > Am 2015-12-08 um 18:16 schrieb Sven Anders: > > > Die erste naheliegendste Idee war, einer neutralen Instanz ein > > > Kontingent Netzkarten o.ä. zu spenden. Ganz ohne erwartete > > > Gegenleistung, aber natürlich in der Hoffnung, dass die Karten > > > auch > > > für die Erhebung der Aufzugskoordinaten genutzt werden. Nach > > > welchen > > > Kriterien die Karten vergeben würden, wäre euch überlassen, da > > > wollen > > > wir keine Auflagen machen. Deswegen wäre mir auch sehr wichtig, > > > dass > > > der Spendenempfänger bzw. die Vergabestelle so unbefangen und > > > neutral > > > wie nur irgendwie möglich ist. Dieser Ansatz würde zwar die > > > Fahrtkostenproblematik für umfangreichere Bahn-Mappingaktionen > > > entschärfen. Aber wahrscheinlich haben diese Mapper bereits sowie > > > eine Bahncard. Ich bin mir auch nicht sicher, ob das ein > > > tragfähiger > > > Vorschlag ist. Einerseits könnte ich mir vorstellen, dass das zu > > > Streitigkeiten führt, wenn sich Leute bei der Vergabe übergangen > > > fühlen. Andererseits liegt auf den Empfänger/innen der Karten im > > > ungünstigsten Fall ein ganz schöner Erwartungsdruck, innerhalb > > > der > > > Geltungsdauer auch möglichst viel zu mappen, auch wenn wir diesen > > > nicht erzeugen wollen. Egal, ob der Druck dann von außen kommt > > > oder > > > sich selber auferlegt wird, unter Umständen kann das trotzdem > > > belastend sein. > > > > Ich teile da Deine/Eure bedenken. Wobei wenn Ihr das konkrete > > Gegenleistungen koppelt (also sowas wie: Wer 5 Aufzüge mit > > Koordinaten einträgt, bekommt einen 5 Euro Gutschein, bei 20 gibt > > es > > eine Freifahrt für Deutschland etc. wäre es wieder transparent und > > für mich okay.) > > Ich persönlich würde mich, obwohl ich recht viel Bahnsachen mappe, > mit > einer BahnCard 100 für drei Monate unter Druck gesetzt fühlen und > wahrscheinlich von einer Bewerbung für eine solche absehen. Wenn man > soetwas machen will, sollte es eher ein Google-Summer-of-Code > -Äquivalent > zur Datenerfassung sein, d.h. die DB spendiert Deutschlandpässe [3], > mit > denen die Mapper dann Strecken und Bahnhöfe abfahren können. (Auf > eigene > Kosten habe ich das diesen Sommer mit Alexander Matheisen zusammen > gemacht) bis auf wenige Ausnahmen betreiben Mapper ihre Arbeit als Hobby in ihrer Freizeit neben Beruf, Studium, Ausbildung, etc. Kaum ein Mapper wird also über einen längeren Zeitraum am Stück intensiver herumfahren und mappen können. Wenn man als Beispiel eine BahnCard für drei Monate nimmt, so wird also kaum ein Mapper die Zeit haben, die auch wirklich auszunutzen, sich aber gleichzeitig in gewisser Weise der DB verpflichtet fühlen. Freikarten über kürzere Zeiträume bis 4 Wochen (also z.B. Deutschlandpass bis hin zu Wochen(end)tickets) sehe ich da als sinnvoller an. Kürzere Gültigkeitszeiträume dürften nach meiner Einschätzung eher zu effektivem Mapping mit bestimmten Zielvorgaben verleiten. Bei zu langen Zeiträumen kann es passieren, dass sich ein Mapper entweder zu viel vornimmt oder aber schon nach kurzer Zeit nicht mehr weitermacht und unnvollständige Ergebnisse hinterlässt. Aktionen wie Mapping Partys oder Wochenaufgaben mit einem definierten Zeitraum und Aufgabenumfang dürften effektiver sein. > > > Die zweite Idee war, ein ganz allgemeines Kontingent an > > > Freikarten > > > bzw. Gutscheinen bereitzustellen, das dann auch einer viel > > > breiteren > > > Basis an Mapper/innen zugute kommen kann, auch über das > > > Bahnmapping > > > hinaus. Zum Beispiel für Fahrten zu OSM-Treffen, zu Konferenzen, > > > zu > > > Developertreffen, Hackathons usw. So wäre die OSM-Community > > > insgesamt > > > etwas breiter gefördert. > > > > Das fände ich wesentlich besser. > > Kleinere Einzelleistungen wären IMHO sinnvoller. Ladet doch, wenn es > (ich habe es nicht genauer untersucht) Regionen mit schlechten > Aufzugdaten gibt, dort zu einer Mappingparty ein. DB Station & > Service > dürfte bestimmt irgendwo ein Raum haben, den man als Basislager > nutzen > könnte. Von dort aus können dann die Mapper losfahren und mit > Verbunds- > oder Ländertickets die Stationen abklappern und die Daten einsammeln. > Aufzugsmapping lässt sich i.d.R. gut mit Bahnsteigmapping (auf der > Mentzschen Detaillierungstufe oder auch noch detaillierter) Wie schon erwähnt betreiben die meisten Mapper ihre Mitarbeit bei OSM als Hobby
Re: [Talk-de] tracer2 NRW-Atlas - ALK umgezogen
On Di, 2015-06-02 at 20:56 +0200, Johannes wrote:
Was ist jetzt im tracer2 Plugin einzutragen?
Wenn ich den alten Wert
wms:http://www.wms.nrw.de/geobasis/wms_nw_alk_vektor?FORMAT=image/pngVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=nw_alk_vektor_gebaeudeSTYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
den URL-Teil durch
http://www.wms.nrw.de/geobasis/wms_nw_alkis
ersetze, funktioniert das tracer2 Plugin nicht mehr. Liegt vermutlich
daran dass, das ganze anders aussieht.
du musst auch noch die Layer anpassen, sonst funktioniert das natürlich
nicht. Schau mal unter
https://josm.openstreetmap.de/wiki/Maps/Germany#NRW-Atlas:ALKIS, da
findest du die vollständige URL.
Übrigens kannst du den ALKIS-Layer auch ganz komfortabel über die
JOSM-Einstellungen hinzufügen, schließlich wurde der neue Layer ja schon
in der oben verlinkten Konfiguration eingetragen.
Gruß
Alex
signature.asc
Description: This is a digitally signed message part
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracer2 NRW-Atlas - ALK umgezogen
On Di, 2015-06-02 at 00:14 +0200, Michael Reichert wrote: Hallo Florian, Am 2015-06-01 um 15:02 schrieb Florian Lohoff: On Mon, Jun 01, 2015 at 11:06:42AM +0200, Florian Lohoff wrote: wie es scheint sind am 1.6 die URLs des NRW-Atlas e.g. ALK umgezogen dadurch funktioniert vermutlich der tracer2 auch nicht mehr. Das dingen sieht auch anders aus (Beschriftungen etc) Nur falls jemand sich wundert und hier nachfragt ;) Im RSS feed findet man auch eine Ankündigung - So auf der Webseite nicht: http://www.wms.nrw.de/rssfeeds/content/geobasis/html/030.html Danke, dass du uns das mitteilst. Ich habe https://josm.openstreetmap.de/wiki/Maps/Germany angepasst, sodass in JOSM in wenigen Minuten (Liste ggf. neuladen, wird nämlich gecacht) der neue WMS angeboten wird. ich habe gerade auch noch https://wiki.openstreetmap.org/wiki/NRW-Atlas angepasst. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hallo, On Di, 2015-04-21 at 17:16 +0200, Frederik Ramm wrote: Hallo, schade, dass diese Diskussion von allen Seiten ein bisschen überhitzt geführt wird. Ich finde, dass solche grossflächigen Edits - ob mechanisch oder nicht - mit sehr grosser Sorgfalt angegangen werden sollten. Dazu zählt, dass man sich gut überlegt, was man machen will, aber auch, dass man mit Einwänden vernünftig umgeht. die Änderungen wurden detailliert geplant und dokumentiert: http://forum.openstreetmap.org/viewtopic.php?id=30676 Die Einwände von fly bezogen sich allerdings nicht auf die geplanten Änderungen, sondern auf das Taggingschema allgemein. Fly hat die Diskussion um den mechanischen Edit zum Anlass genommen, viele grundsätzliche Dinge des Taggingschemas in Frage zu stellen. Von vorn herein nur im Forum zu posten und auf Nachfrage zu erklären, die Mailingliste sei ja eh am Sterben, ist asking for trouble - einen breiten Konsens erreicht man nicht, indem man die (nach eigenem Befinden kleinere) Hälfte der Community ignoriert. Das ist zugegebenermaßen nicht gut gelaufen. Ich selbst hätte es auch auf der Mailingliste gepostet. Die Begründung, dass die Mailingliste am Sterben sei, finde ich auch nicht wirklich passend. Ausserdem sehe ich hier eine gefährliche Tendenz von das ist OpenRailwayMap-Sache, wir haben uns das überlegt, und warum sollten wir auf jemanden hören, der nicht mal zu uns gehört. Folgerichtig hat Michael (Nakaner) seine Aktion auch nicht zur Diskussion gestellt (denn er war sich ja schon sicher, dass er alles richtig macht und sich nicht reinreden lassen wird), sondern nur angekündigt. Die geplanten Änderungen wurden ausgiebig auf unseren Treffen diskutiert (zu denen auf diversen Kanälen eingeladen wurde, aber kaum jemand gekommen ist). Nach den Treffen wurden diese Änderungsvorschläge auch nochmal auf der ORM-Mailingliste, im Forum und auf ein paar anderen Kanälen bekanntgegeben, ohne dass noch irgendwelche Einwände kamen. Deshalb darf man ja spätestens dann davon ausgehen, dass niemand mehr einen Einwand hat. Dazu sind die Änderungen wie bereits beschrieben sehr unspektakulär, da nur Fehler aus der Anfangszeit des Schemas behoben wurden. Es ändert sich ja praktisch nichts durch den Edit. Warum sollten wir also plötzlich ein funktionierendes Taggingschema auf den Kopf stellen, weil ein einziger Mapper Kritik übt, aber selbst keine brauchbaren Verbesserungen aufzeigen kann? Es ist etwas ungeschickt, dass fly selbst nicht auf der OpenRailwayMap-Mailingliste ist und sich zugleich gern an der weiteren Diskussion bezüglich Tagging von Eisenbahnanlagen beteiligen will. Wäre er auf dieser Liste gewesen, hätte er vermutlich im Vorfeld an der Diskussion teilnehmen können, statt Verbesserungsvorschläge erst einzubringen, als der Edit angekündigt wurde. Nicht nur das. Was ich fly vorwerfe ist, dass es jetzt auf einmal anfängt, nicht nur Details, sondern grundsätzliche Dinge eines Taggingschemas in Frage zu stellen, das seit Jahren etabliert und in breiter Verwendung ist. Vor allem hat seine Kritik überhaupt nichts mit dem eigentlichen Edit zu tun: * Erfassung von Signalen mit railway:signal:direction=* und railway:signal:position=* ist kaputt * Tags sind zu lang * Signaltypen sollten nicht abgekürzt, sondern ausgeschrieben werden * die Signalvorschriften sind zu kompliziert Wenn jemand begründete Einwände hat, bin ich gerne bereit, mir diese Kritik anzuhören und gegebenenfalls das Tagging zu verbessern. Voraussetzung dafür ist jedoch, dass derjenige konstruktive Vorschläge hat, wie es seiner Meinung besser gemacht werden könnte. (Dann wieder - OpenRailwayMap ist eine private Mailingliste auf einer privaten Domain, wo der private Betreiber jeden rauswerfen kann, der ihm nicht passt - insofern stellt sich die Frage, ob eine Meinungsbildung auf der OpenRailwayMap-Liste für OSM überhaupt eine Bedeutung haben sollte.) Auf sämtlichen anderen offiziellen Mailinglisten kann man doch auch jederzeit rausgeworfen werden?! Ich habe jetzt keine Lust, die hier diskutierten Edits zu reverten, aber ich erwarte künftig vom OpenRailwayMap-Team, dass sie den Rest des Projekts nicht wie Idioten behandeln, die ja eh nichts zu sagen haben, sondern dass man sie und ihre Bedenken ernst nimmt. Dazu zählt, dass man seine Edits nicht bloss ankündigt, sondern tatsächlich innerlich zu Kompromissen bereit ist, und dazu zählt auch, dass man auf talk-de nicht bloss auftaucht, um Leuten mitzuteilen, dass man mit ihnen jetzt nicht mehr spricht. Wir haben niemanden wie Idioten behandelt, allerdings sollte man Kritik auch zurückweisen dürfen. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
On Fr, 2015-04-17 at 15:58 +0200, fly wrote: Wenn schon so viele Objekte angefasst werden, können wir doch vorher uns auf geschicktes Tagging verständigen und ich sehe dieses Vorgehen immer noch als mechanischen Edit. z.B. könnten wir auch das völlig kaputte System um railway:signal:direction und railway:signal:position verbessern und dann alles auf einmal korrigieren. Du bezeichnest das etablierte Tagging als völlig kaputt, hast aber selbst bislang auch kein besseres Konzept vorgestellt. Zwar hast du immer mal wieder direction=* oder Relationen ins Spiel gebracht, aber mehr als vage Ideen waren das nicht. Erstelle doch mal eine Wikiseite, auf der du deine Ideen detailliert beschreibst, mit ein paar Taggingbeispielen anreicherst und dir Gedanken über die Praxistauglichkeit machst. Danach können wir weiter reden... Am meisten kotzt mich hier die Art und Weise des Vorgehens und die mangelnde Bereitschaft sich auf eine konstruktive Diskussion einzulassen, an. Da stimme ich dir zu. Von deiner Seite fehlen mir bislang konstruktive und durchdachte Vorschläge. Wie es scheint fehlen hier ein paar grundsätzlichen Verständnisse einer Gemeinschaft und ich müss jetzt halt doch die DWG einschalten. Habe ich bisher fast immer erfolgreich vermeiden können. Und was willst du der DWG sagen? Dass die Leute von der OpenRailwayMap ihr Taggingschema nicht nach deinen Vorstellungen ändern wollen? Und was soll die DWG dann dazu sagen? Gruß Alex, der nun ebenfalls keine Lust mehr auf diese Diskussion hat signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
On Di, 2015-04-14 at 22:34 +0200, fly wrote: Am 14.04.2015 um 21:13 schrieb Michael Reichert: Am 2015-04-14 um 19:43 schrieb fly: Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer: Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig namespace-Tags begegnen, dann ist es doch leicht anders: emergency=fire_hydrant fire_hydrant:type=underground railway=signal railway:signal:... railway:signal:main:state:forward=* Lass mich raten, das Signal stammt von rayquaza und ist – für OpenRailwayMap-Verhältnisse – schon ewig gemappt? Nein, nur meiner Logik entsprungen. du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang sei, oder wie soll ich das jetzt verstehen? Das sind Versuche, Signale zu mappen, die für verschiedene Richtungen gelten und am selben Mast hängen. Es hat sich nie durchgesetzt (das railway:signal:TYP:state:forward/backward=* werten wir nicht aus und wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung, der andere für die andere Richtung. Habe ich das im Wiki überlesen ? Welche Gründe sprechen denn dafür ? Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene Richtungen eingetragen werden können, würde die Tags noch komplizierter machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder? Mapped Ihr dann auch noch den Masten ? Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher komplizierter. Ich finde es deutlich komplizierter, als zwei Nodes zu mappen. Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir können jedes Signal einzeln eintragen. Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter auf diversen Kanälen diskutiert und sowohl für Mapper als auch die Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust, dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt plötzlich meinst, das Taggingschema der Signale in Frage zu stellen. Wenn möglich sollte doch der ein oder andere Tag auch mit weniger Pre-/Postfixen auskommen (siehe auch :lanes-Tagging). state:main:forward=* bzw wenn möglich sogar nur state=* height[:TYPE][:DIRECTION] Eindeutig ist das ganze doch schon durch railway=signal Das macht die Zuordnung interessiert mich der key für den Benutzer etwas einfacher, aber andere Dinge wir ref fallen da trotzdem aus der Reihe[1]. Welche Benutzer*innen meinst Du ? Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen Schlüssel schon eine Menge Platz aus und die wichtige Information steht am Ende. Ich sehe nicht, dass der Verzicht auf railway: bei den key-Namen eine große Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das überblicken kann, zu Kollisionen mit anderen Taggings führen würde. Wolltest wohl zu keinen Kollisionen schreiben Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in eckigen Klammern): - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken) [distant] - ein Geschwindigkeitsanzeiger [speed] und/oder Geschwindigkeitsvoranzeiger [speed_limit] - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road] - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger [route](bei Streckenverzweigungen und mancherorts auch bei Gleiswechseln) - eine Haltetafel [stop] (die mit dem H) - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals [minor]. Was war denn jetzt an meinen Vorschlägen jetzt falsch ? state:main:forward=* resp. state:main=* height[:TYPE][:DIRECTION] resp. height[:TYPE] Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ? (railway:signal:main:state=*) Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor du solchen Unsinn schreibst. Lektüreempfehlung: http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert für Nicht-Bahnaffine. Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und versuche dann mein Glück Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen. Wenn du ein wenig im Internet recherchieren würdest, würdest du recht schnell auf einfachere Erklärungen stoßen. Wikipedia ist ein guter Anfang, ebenso die auf den ORM-Wikiseiten bei jedem
Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland
Hallo, On Di, 2015-04-07 at 15:09 +0200, fly wrote: Grundsätzlich spricht nichts gegen eine Anpassung, allerdings sollten solche Änderungen möglichst breit diskutiert werden und dann bringt es nichts wenn der Autor hier nicht einmal persönlich einen Link veröffentlicht und dann auch mitdiskutiert ! ich nehme an, dass Nakaner das schlicht vergessen hat. * Wie sieht das denn im Ausland aus ? Wurde auch über den Tellerrand (Europa) hinausgeschaut ? Andere Länder sind nicht betroffen (Ausnahme: Österreich), da es anfangs nur ein Taggingschema für Deutschland gab. Somit gibt es im Ausland im Grunde keine Signale, da ja bisher ein Taggingschema dafür fehlte. Beim Entwurf des Schemas für Österreich wurde das Problem der fehlenden Eindeutigkeit erkannt und von Anfang an das Länderkürzel AT: verwendet. Da wir ja mittlerweile ein Länder-Betreiber-Präfix verwenden, ist das auch nicht mehr ganz korrekt. Da es aber nicht viele Signale mit dem alten Schema gibt und ein Großteil davon auch von mir erfasst wurden, sehe ich hier erstmal keinen Bedarf für größere Umtagaktionen. Das Taggingschema für die Schweiz, das vor wenigen Tagen fertiggestellt wurde, verwendet von Anfang an das neue Länder-Betreiber-Präfix. * Können wir kein internationales Schema entwickeln und nur länderspezifische Signale mit LC erweitern. Alle Signale sind länderspezifisch! Das Taggingschema ist ja schon weitgehend international ausgelegt, sodass die Art und Bedeutung des Signals mit einem generischen Schema abgebildet wird. Nur muss eben trotzdem bei jedem Signal der konkrete länderspezifische Typ mitgetaggt werden, weil sonst wichtige Informationen fehlen. * Warum werden den die Werte als Abkürzungen definiert ? Was spricht gegen zB Hauptsignal statt hp ? Es handelt sich dabei um offizielle Abkürzungen, die durch das Signalbuch festgelegt sind (so wie die Verkehrszeichen in der StVO). Unter Eisenbahnern sind diese Abkürzungen auch gebräuchlicher als die Langnamen. Ausgeschriebene Bezeichnungen werden z.B. bei den österreichischen Signalen verwendet, da dort die Signale keine offiziellen Abkürzungen tragen. * Wie wäre es mit operator=* anstatt der Präfixe der Werte ? Das ist nicht praktikabel. Um etwa auf einer Karte das richtige Signalicon zu zeichnen, müsste man nämlich die externe Information haben, welche Signale und welches Regelwerk bei einem bestimmten Betreiber verwendet werden. Außerdem können an einem Signalmast auch Signale verschiedener Signalordnungen hängen. Die Beispiele am Ende hängen in der Luft und genau die Unterschiede sind nicht herausgearbeitet, da nur jeweils ein Beispiel für jeden Haupttag vorhanden ist. Noch sind die Tags railway:signal:main=*, railway:signal:combined=*, railway:signal:*:states=* und was da noch so herumschwirrt gut dokumentiert. Das Hauptsignal und das stillgelegte Signal verwenden exakt das gleiche Bild ! Es könnten definitiv noch ein paar mehr Beispiele auf der Seite stehen. Mit der Zeit werden sicherlich auch noch einige dazukommen. Ansonsten verstehe ich nicht so genau, was du eigentlich kritisierst... Gibt es Proposals ? Nein. Insgesamt ist die Situation eher unbefriedigend, da es sich hier wohl eher um einen kleineren Kreis von Profis handelt und interessierte Laien schon Probleme bekommen. Mit der Verwendung der JOSM-Vorlagen kann man sich das Eintragen der Signale schonmal deutlich vereinfachen. Etwas Bahnwissen gehört aber dennoch dazu, das gebe ich zu. Das hebt zwar die Einstiegshürde und schreckt die große Masse ab, sichert aber auch eine gewisse Qualität der Daten. Auch wird, nach wie vor, an forward/backward und left/right an Punkten festgehalten, was so von keinem einzigen Editor unterstützt wird. Das ist momentan eben die beste Möglichkeit, um einerseits die Daten einfach eintragen zu können, andererseits auch gut auswerten zu können. Wenn du eine bessere Idee hast, kannst du uns die gerne vorstellen. Somit komme ich zu dem Schluss, dass es wohl immer noch an einer gelungen Ausarbeitung des Tagging-Schemas und der entsprechenden auch für normale User verständlichen Wikiseiten fehlt und ein mechanischer Edit zur Zeit zu wenig Verbesserung mit sich bringt. Hast du konkrete Verbesserungsvorschläge für die Wikiseiten? Der mechanische Edit bringt deutliche Verbesserungen. Er vereinheitlicht das Tagging und korrigiert Design-Fehler, die wir beim Entwurf des Taggingschemas gemacht haben, nämlich die fehlende internationale Eindeutigkeit der Tags. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Need help to fix? osm data in german
On Mi, 2014-12-17 at 14:07 +0100, Martin Vonwald wrote: Auszug aus dem Impressum von www.limburg-bernd.de: Der Urheber räumt Ihnen ganz konkret kein Nutzungsrecht ein, um sich eine private Kopie für persönliche Zwecke anzufertigen. wundert mich etwas, denn Bernd Limburg ist sonst aktiver Wikipedianer im Bereich Denkmäler und hat all seine Fotos Wikimedia gespendet: http://de.wikipedia.org/wiki/Benutzer:Huckety Vielleicht stammen die Nutzungsrechte noch aus einer Zeit bevor er auf Wikipedia aufmerksam wurde. Ich meine, dass es so eine Seite definitiv nicht wert ist irgendwo verlinkt zu werden. Vielleicht sollte man stattdessen lieber die Denkmallisten in der Wikipedia verlinken? Dort steht praktisch das gleiche wie auf seiner Homepage, inklusive der gleichen Bilder. Beim Verlinken privater Webseiten gibt es immer die Gefahr, dass die Inhalte irgendwann verschwinden oder die Links nicht stabil bleiben. Dieses Problem hat man bei der Wikipedia nicht. Gruß Alex Am 17. Dezember 2014 um 12:48 schrieb Martin Vonwald imagic@gmail.com: 2014-12-17 12:41 GMT+01:00 Mark Obrembalski m...@obrembalski.de: On 17.12.2014 12:13, Martin Vonwald wrote: Offensichtlich meint er, dass das website-Tag hier nicht hingehört. Und wenn ich mir das so ansehe, würde ich ihm auch eher zustimmen. Die Einzelseite zu dem Kreuz ist offenbar http://www.limburg-bernd.de/DenkUeb/Nr.%203.htm Von der angegebenen Hauptseite kommt man da nur mit ein wenig Suchen hin. So gesehen könnten wir auf jedes Objekt website=www.google.com draufgeben, oder? Mal abgesehen davon, dass der direkte Link gesetzt sein sollte, bin ich mir nicht so sicher ob unbedingt eine private Sammelwebseite verlinkenswert ist. Ist aber nicht meine Baustelle, daher nur als Denkanstoß gedacht. bg, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] priority=* an railway=*
On Mi, 2014-11-05 at 15:38 +0100, fly wrote: Am 04.11.2014 um 20:15 schrieb Michael Reichert: Hallo Fly, Am 2014-11-04 um 18:48 schrieb fly: Dachte, die wären doch zu Google gegangen. Mentz war noch nie sehr diskussionsfreudig von Doku ganz zu schweigen. Hier hat mal wieder eine Firma ihre Mitarbeiter*innen nicht unter Kontrolle. Am besten allen eine Mail schreiben und darauf hinweisen, dass so was im Vorhinein zu diskutieren ist. http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000157.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-October/000159.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000164.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000165.html http://lists.openrailwaymap.org/archives/openrailwaymap/2014-November/000166.html Danke, aber sowas gehört doch auch auf eine offizielle Mailingliste wie transit@ oder tagging@ Auch auf dieser Liste hätte ja zumindest ein Link zur Diskussion mitgeteilt werden können. Bei wievielen Mailinglisten soll ich mich denn sonst noch überall anmelden ? Rückfrage: Auf wie vielen verschiedenen Kanälen soll denn nun über Eisenbahntagging diskutiert werden? Wer an Eisenbahnthemen in OSM interessiert ist, dürfte meist ohnehin bei der ORM-Mailingliste angemeldet sein. Der Sinn der ORM-Mailingliste ist es ja, Eisenbahnthemen unter interessierten Mappern zu diskutieren. transit und tagging sind für solche Themen nicht wirklich geeignet. Unabhängig davon sehe ich im vorliegenden Fall auch überhaupt keinen Grund, das Thema auf den genannten Mailinglisten anzusprechen. Statt eines etablierten und vieldiskutierten Taggingschemas hat Mentz - warum auch immer - ein veraltetes und ungeeignetes Taggingschema angewendet. Ich sehe bei dem Thema keinen Diskussionsbedarf mehr... Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OpenRailwayMap Mappingwochenende
Hallo zusammen, die Bahnmapper rund um das Projekt OpenRailwayMap veranstalten vom 11. bis 13. Juli 2014 in Köln das erste OpenRailwayMap-Mappingwochenende. Eingeladen sind natürlich nicht nur die Bahnexperten unter den Mappern, sondern auch interessierte Neulinge, die das Thema Bahnmapping einmal näher kennenlernen möchten. Weitere Informationen findet ihr im Wiki unter https://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2014_1 - tragt euch auch bitte dort ein, falls ihr kommen wollt. Ich hoffe auf reges Interesse! Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mappingevent OpenRailwayMap
Hallo, wie einige vielleicht schon über die OpenRailwayMap-Mailingliste oder die Wochennotiz mitbekommen haben, planen wir ein Mappingevent für Bahnmapper. Zweck dieser Veranstaltung soll es sein, andere Bahnmapper einmal persönlich kennenzulernen, gemeinsam ein kleines Gebiet in einer Mappingparty zu erfassen und Neulinge an das Thema Eisenbahnmapping heranzuführen. Eingeladen sind aber nicht nur Mapper, sondern auch interessierte Bahnunternehmen und Entwicklerfirmen, um gegenseitig Kontakte zu knüpfen. Weitere Infos finden sich auf der Wikiseite. [1] Falls ihr Interesse an einer Teilnahme habt, tragt euch und eure Ortsvorschläge bitte im Wiki ein. Zur Zeit sind wir noch dabei, einen passenden Ort für diese Veranstaltung zu suchen. Sobald sich hier etwas ergeben hat, werden wir nach einem passenden Termin suchen. Ich hoffe auf reges Interesse. [1] http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Mappingwochenende_2014_1 Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue OpenRailwayMap Mailingliste
Hallo, für alle Mapper, die an Eisenbahnen und der OpenRailwayMap interessiert sind, gibt es nun eine neue Mailingliste: http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap Ich hoffe, dass sich dadurch die Bahnfreaks unter euch besser austauschen können... ;) Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Openrailwaymap zoom 11 tile rendering
Hallo Philipp, On Sa, 2014-01-18 at 11:05 +0100, Philipp Klaus Krause wrote: I noticed that Openrailwaymap seems to take a very long time to rerender the big tiles: At zoom level up to 10, changes that have been made weeks ago are still not visible. But when I zoom in to 11 or further, even changes made a day ago seem to be there. Is there any particular reason for this? Die OpenRailwayMap befindet sich ja auch noch im Entwicklungsstadium (wie auch die Hinweisbox beim Seitenaufruf verrät), daher funktioniert vieles auch noch nicht optimal und auch der Kartenstil ist noch lange nicht fertig. Seit einiger Zeit habe ich in der Tat einige Schwierigkeiten mit der Aktualisierung der Karte. Ich bin aber kurz davor, diese gelöst zu haben. Wenn soweit alles wieder funktioniert, wird auch die Meldung beim Seitenaufruf verschwinden. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vandalismus im Wiki
Hallo, hier treibt gerade ein Nutzer ziemlichen Unsinn und löscht wahllos die Inhalte von Wikiseiten: http://wiki.openstreetmap.org/wiki/Special:Contributions/Socksock Wer auch immer das Wiki administriert möge den User bitte sperren und die Änderungen zurücksetzen. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vandalismus im Wiki
Am Dienstag, den 24.09.2013, 21:12 +0200 schrieb Alexander Matheisen: Hallo, hier treibt gerade ein Nutzer ziemlichen Unsinn und löscht wahllos die Inhalte von Wikiseiten: http://wiki.openstreetmap.org/wiki/Special:Contributions/Socksock Wer auch immer das Wiki administriert möge den User bitte sperren und die Änderungen zurücksetzen. Ist wohl gerade gesperrt worden. Kann man irgendwie all seine Änderungen in einem Schritt wieder rückgängig machen? Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vandalismus im Wiki
Am Dienstag, den 24.09.2013, 21:19 +0200 schrieb Alexander Matheisen: Am Dienstag, den 24.09.2013, 21:12 +0200 schrieb Alexander Matheisen: Hallo, hier treibt gerade ein Nutzer ziemlichen Unsinn und löscht wahllos die Inhalte von Wikiseiten: http://wiki.openstreetmap.org/wiki/Special:Contributions/Socksock Wer auch immer das Wiki administriert möge den User bitte sperren und die Änderungen zurücksetzen. Ist wohl gerade gesperrt worden. Kann man irgendwie all seine Änderungen in einem Schritt wieder rückgängig machen? Thema hat sich erledigt, die Wiki-Admins haben alle Änderungen zurückgesetzt. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eisenbahnen in Korea
Hallo, ich habe umfangreiche Daten zum Bahnnetz in Nord-Korea, Asien und Japan bekommen, mit Stationen und Strecken-Kilometern. Wem kann ich das per PM schicken? Vielleicht ist ja Brauchbares dabei... das klingt interessant, vor allem für die OpenRailwayMap. Kannst mir die Daten gerne mal zuschicken. Ist denn geklärt, unter welcher Lizenz die stehen und ob sie für OSM verwendet werden dürfen? Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Drohung an Mapper
Am Dienstag, den 24.09.2013, 02:22 +0900 schrieb Max: Interessante Entdeckung: eine Drohung an Mapper (an einer Mauer des Camp George in Daegu, Südkorea). Das Schild list sich so: WARNING RESTRICTED AREA This installation has been declared a restricted area by authority of the Installation Commander in accordance with the provisions of the directive issued by the Secretary of Defense on 20th August 1954, pursuant to the provisions of Section 21, Internal Security Act of 1950. Unauthorized entry is prohibited. All persons and vehicles entering herin are liable to dearch.Photographing or making notes drawings, maps, or graphic representations of this area or its activities are prohibited unless specifically authorized by the commander. Any such material found in the posession of unauthorized persons will be confiscated. (Darunter das gleiche noch mal auf Koreanisch ) Solche Schilder findet man aber auch an US-Einrichtungen in Deutschland. Finde aber gerade leider kein Beispielbild (kein Wunder bei einem Schild, das das Fotografieren verbietet...) Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am Freitag, den 13.09.2013, 18:58 +0200 schrieb Philipp Klaus Krause: Eine Legende wäre schön. Die Geschwindigkeitskarte ist dank der Zahlen auf der Karte auch ohne verständlich, aber bei den anderen Merkmalen sieht es anders aus. Und auch für die Geschwindigkeit schadet eine Legende nicht. Ist alles in Arbeit. Die Karte ist ja auch noch nicht fertig und eher unfreiwillig hier publik geworden... Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur vom Schienenetz in Deutschland
Am Freitag, den 13.09.2013, 20:05 +0200 schrieb fly: On 11.09.2013 11:43, Alexander Matheisen wrote: Im Zusammenhang mit meiner OpenRailwayMap habe ich vor einiger Zeit ein Taggingschema entwickelt, das bereits intensiv genutzt wird: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging#Gleis Ich habe auch eine Vorlage für JOSM erstellt, die das Tagging deutlich erleichtert: https://raw.github.com/rurseekatze/OpenRailwayMap/master/josm-presets/de.xml Leider finde ich Dein Preset nicht unter den externen Presets in JOSM, dafür ist es nötig im JOSM Trac auf der Preset-Seite die URL einzutragen. Da das Preset noch nicht endgültig fertig ist, habe ich bisher auch noch nicht dort eingetragen, was aber geplant ist. Super wäre es einen eigenen Style zur Verfügung zu stellen. Das geht bereits. Dazu musst du nur die MapCSS-Dateien und das Verzeichnis icons, die unter https://github.com/rurseekatze/OpenRailwayMap/tree/master/styles zu finden sind, in JOSM einbinden. Bisher habe ich das auf der Wikiseite der OpenRailwayMap noch nicht dokumentiert, aber das kommt noch... Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am Mittwoch, den 11.09.2013, 21:22 + schrieb Sven Geggus: Alexander Matheisen alexandermathei...@ish.de wrote: Liverendering mit Mapserver oder Mapnik habe ich bisher noch nicht ausprobiert. In kleinen Zoomleveln ist das kein Problem. Der OSM Inspektor macht das zum Beispiel so. Bei Zoomstufen =10 ist die Geschwindigkeit beim Rendering im Browser ja auch kein Problem. Schwierig wird es in den niedrigen Zoomstufen bis etwa z7, bei denen ich die Datenkacheln per Cronjob vorher erzeugen und cachen muss, weil eine Live-Erzeugung zu langsam wäre. Das müsste man bei einem Liverendering von Bitmap Tiles wahrscheinlich auch. Aber dann hätte man wieder den Nachteil, dass man jede Kachel in jedem Kartenstil rendern muss... Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur vom Schienenetz in Deutschland
Hallo, Allerdings haben wir noch ein anderes Problem. Das Tagging der Gleise ist nur wenig differenziert. Das hat zur Folge, dass der Router auch mal durch einen Bahnbetriebshof oder über einen Rangierbahnhof fährt. Wenn uns jemand sagen kann, wie wir Gleise erkennen und kennzeichnen können, die nicht für den Personenverkehr genutzt werden können, wäre das hilfreich. Im Zusammenhang mit meiner OpenRailwayMap habe ich vor einiger Zeit ein Taggingschema entwickelt, das bereits intensiv genutzt wird: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging#Gleis Ich habe auch eine Vorlage für JOSM erstellt, die das Tagging deutlich erleichtert: https://raw.github.com/rurseekatze/OpenRailwayMap/master/josm-presets/de.xml Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am Mittwoch, den 11.09.2013, 13:34 +0200 schrieb Philipp Klaus Krause: Am 11.09.2013 11:43, schrieb Alexander Matheisen: Im Zusammenhang mit meiner OpenRailwayMap […] Funktioniert da bereits etwas bahnspezifisches? Mit Firefox 23 auf GNU/Debian sehe ich auf http://www.openrailwaymap.org/ nur eine OpenStreetMap (langsam ladend, mit höhenschattierung, wahlweise in Grau oder Farbe, und per default in dieser MapQuest-Darstellung die Autobahnen sehr betont). Du hast mich gerade auf einen Bug aufmerksam gemacht, den ich bisher noch nicht entdeckt habe. Bei meiner letzten Codeänderung hatte ich wohl einen Variablennamen falsch geschrieben... Jetzt sollte wieder alles funktionieren. Die Karte ist soweit fertig und benutzbar, wenn auch besonders in niedrigen Zoomstufen etwas langsam, da die Karte mit KothicJS im Browser gerendert wird. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Danke. Eine Eisenbahnkarte auf OSM-Basis scheint mir eine sehr gute Idee. Und abgesehen von der Langsamkeit ist die gefällt mir die Karte auch. Ist es geplant, da noch weitere Informationen einblendbar zu machen (z.B. Oberstromgrenzwerte, Neigetechnik, etc)? Ja, die Kartenstyles sollen nach und nach erweitert werden. Konkret geplant sind bereits Ansichten für Elektrifizierung und Spurweite, aber es können natürlich noch unzählige weitere Stile erstellt werden. Konkrete Vorschläge sind gerne gesehen und können per Mail oder als Github Issue mitgeteilt werden. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap [Was: Re: Korrektur vom Schienenetz in Deutschland]
Am Mittwoch, den 11.09.2013, 14:55 + schrieb Sven Geggus: Alexander Matheisen alexandermathei...@ish.de wrote: Die Karte ist soweit fertig und benutzbar, wenn auch besonders in niedrigen Zoomstufen etwas langsam, da die Karte mit KothicJS im Browser gerendert wird. Da man die Features ohnehin nicht anklicken kann. Spricht was dagegen mit Mapserver oder Mapnik live aus der serverseitigen Datenbank zu rendern? Grundsätzlich spricht nichts dagegen. Für KothicJS und gegen einen herkömmlichen Tileserver hatte ich mich aus folgenden Gründen entschieden: * Geringerer Rechenaufwand auf dem Server durch Rendering im Client; weniger Speicherplatzbedarf auf dem Server, da für mehrere angebotene Renderingstyles nicht jede Kachel mehrfach abgelegt werden muss * Möglichkeit des Stylewechsels und Sichtbarkeit von Änderungen am Renderingstyle, ohne die Kacheln neu rendern zu müssen Liverendering mit Mapserver oder Mapnik habe ich bisher noch nicht ausprobiert. Bis auf den höheren Rechenaufwand auf dem Server würden sich damit scheinbar auch meine Anforderungen erfüllen lassen. Wie sich beide Lösungen hinsichtlich der Performance verhalten, müsste man ausprobieren. Was ich auf die Schnelle nicht gefunden habe ist eine Legende. Die Anwendung ist ja auch noch nicht komplett fertig, sonst hätte ich hier auch schon mehr Werbung gemacht. Ach ja und railway = funicular scheint nicht dargestellt zu werden, oder hab ich da was vergessen zu taggen? Dass Standseilbahnen nicht dargestellt werden, ist so gewollt. Die Karte beschränkt sich nämlich auf die richtigen Eisenbahnen, also schienengebundene und aus eigener Kraft fahrende Verkehrsmittel. Siehe http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Projektbeschreibung. Gruß Alex signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Güterbahnhöfe / Verladestationen
Es existieren neben den normalen Bahnhöfen für Menschen auch Güterbahnhöfe oder Güterverkehrszentren (Umladestationen). Wie könnte man sowas taggen? (Mir wäre am liebsten ein railway=* Tag). In indien bin ich über railway=freight_station gestolpert, was ich gar nicht sooo verkehrt finde. Was meint ihr? Im Rahmen des Taggingschemas für meine OpenRailwayMap habe ich mit bereits einige Gedanken darüber gemacht: Für Güter- und Rangierbahnhöfe habe ich railway=yard vorgesehen. Was Containerterminals angeht: Da habe ich einfach mal man_made=container_terminal und railway=container_terminal gewählt, wobei Containerverladeterminals irgendwo auch wieder ein railway=yard sind. Daher man_made=container_terminal für alle Arten von Containerumschlag und zusätzlich railway=container_terminal für solche mit Verladung auf Güterwagen. Das Tagging von Logistikeinrichtungen bedarf aber noch eines detaillierten Taggingschemas. Bisher hat sich noch niemand eingehender mit diesem Thema beschäftigt. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen
Hallo Jimmy, mit einer public_transport=station und area=yes wird der Link (irgendwo?) an der Linie gesetzt und nicht im Schwerpunkt (oder ähnlichem). Siehe z.B. hier: http://www.openlinkmap.org/?zoom=18lat=48.34056lon=16.73432layers=BFT Das ist schon der Centroid, nur der wird bei mir von osmconvert berechnet und liegt daher nicht auf dem von Mapnik berechneten Centroid. Um das zu verbessern müsste entweder osmconvert angepasst werden, oder aber ich stelle meinen Code so um, dass die Centroids von PostGIS berechnet werden. Auf welche Weise ich das Problem löse, weiß ich noch nicht so recht... Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen
Hallo, Genau das ist das Problem, denn hier in der Region ist es eher selten das es als VVS getaggt wird sondern es wird mehr über den Verkehrsbetrieb getaggt. Ich habe herausgefunden, dass die Auskunft der Deutschen Bahn soweit auch Bushaltestellen unterstützt. Dazu sind auch keine UIC-Nummern notwendig, denn die Abfrage geht auch mit einer Kombination aus Haltestellennamen und Ort: http://reiseauskunft.bahn.de/bin/bhftafel.exe/dn?country=DEUrt=1use_realtime_filter=1productsFilter=1100boardType=Abfahrtstart=Sucheninput=tennisplatz,ludwigsburg Daher sollte es funktionieren, wenn man ein Tag uic_name=* hinzufügt, das einen Wert nach dem Schema Haltestellenname, Stadthat. Die entsprechende Regel in der Datei habe ich hinzugefügt. Wobei ich dafür wäre, zur Vereinfachung allen Haltestellen ein network=VVS zu geben, damit nicht eine lange Liste von Betreibern in allen Schreibvarianten abfragen muss. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen
Hallo Michael, Also ich hab mich jetzt mal ein wenig damit beschäftigt, jedoch reichen meine Programmierkenntnisse in XSLT und html nicht aus um die Abfrage zu gestalten, weil mit uic_ref wird das bei Bustationen nichts. translation nameVVS/name descriptionTimetables for public station stop positions operated by the traffic network Stuttgart Verkehrsverbund Stuttgart(VVS)./description match mode=and match mode=or tag k=highway v=bus_stop/ tag k=railway v=station/ tag k=railway v=halt/ tag k=public_transport v=stop_position/ tag k=public_transport v=platform/ tag k=railway v=stop/ /match match mode=or tag k=operator v=(.*;|^)SSB(;.*|$)/ tag k=operator v=(.*;|^)Stuttgarter Strassenbahnen(;.*|$)/ tag k=operator v=(.*;|^)Stuttgarter Straßenbahnen(;.*|$)/ tag k=operator v=(.*;|^)SVE(;.*|$)/ tag k=operator v=(.*;|^)LVL(;.*|$)/ tag k=operator v=(.*;|^)Schlienz(;.*|$)/ tag k=operator v=(.*;|^)Bader(;.*|$)/ tag k=operator v=(.*;|^)Böltz(;.*|$)/ tag k=operator v=(.*;|^)Dannenmann(;.*|$)/ tag k=operator v=(.*;|^)Däuble(;.*|$)/ tag k=operator v=(.*;|^)Eberhardt(;.*|$)/ tag k=operator v=(.*;|^)Eisemann(;.*|$)/ tag k=operator v=(.*;|^)END(;.*|$)/ tag k=operator v=(.*;|^)Fischle(;.*|$)/ tag k=operator v=(.*;|^)Flattich(;.*|$)/ tag k=operator v=(.*;|^)Ganter(;.*|$)/ tag k=operator v=(.*;|^)Hassler(;.*|$)/ tag k=operator v=(.*;|^)Haussmann Bauer(;.*|$)/ tag k=operator v=(.*;|^)Jäger(;.*|$)/ tag k=operator v=(.*;|^)Kappus(;.*|$)/ tag k=operator v=(.*;|^)Klingel(;.*|$)/ tag k=operator v=(.*;|^)Knauss(;.*|$)/ tag k=operator v=(.*;|^)Kniesel(;.*|$)/ tag k=operator v=(.*;|^)Ludwigsburger Verkehrslinien(;.*|$)/ tag k=operator v=(.*;|^)Melchinger(;.*|$)/ tag k=operator v=(.*;|^)Omnibusverkehr Ernst Maier(;.*|$)/ tag k=operator v=(.*;|^)Ernst Maier(;.*|$)/ tag k=operator v=(.*;|^)OVK(;.*|$)/ tag k=operator v=(.*;|^)Omnibus Verkehr Kirchheim(;.*|$)/ tag k=operator v=(.*;|^)OVR(;.*|$)/ tag k=operator v=(.*;|^)Pflieger(;.*|$)/ tag k=operator v=(.*;|^)Pflüger(;.*|$)/ tag k=operator v=(.*;|^)Römer(;.*|$)/ tag k=operator v=(.*;|^)Schefenacker(;.*|$)/ tag k=operator v=(.*;|^)Seitter(;.*|$)/ tag k=operator v=(.*;|^)Seiz(;.*|$)/ tag k=operator v=(.*;|^)Spillmann(;.*|$)/ tag k=operator v=(.*;|^)Stadtwerke Herrenberg(;.*|$)/ tag k=operator v=(.*;|^)Stadtwerke Remseck(;.*|$)/ tag k=operator v=(.*;|^)Stäbler(;.*|$)/ tag k=operator v=(.*;|^)Städtischer Verkehrsbetrieb Esslingen(;.*|$)/ tag k=operator v=(.*;|^)VBN(;.*|$)/ tag k=operator v=(.*;|^)Verkehrsbetriebe Nagoldtal(;.*|$)/ tag k=operator v=(.*;|^)WEG(;.*|$)/ tag k=operator v=(.*;|^)Wöhr(;.*|$)/ tag k=network v=(.*;|^)VVS(;.*|$)/ /match /match output copy-all/ tag from_match=uic_ref k=departures v=http://www2.vvs.de/vvs/XSLT_DM_REQUEST?Oberesslingen%2C%20Rosenau%7C50040 23%7Cstop=SpEncId=0anyMaxSizeHitList=500anySigWhenPerfectNoOtherMatches=1 command=convertPOIsITKernel2LocationServer=1convertStopsPTKernel2Location Server=1dmLineSelection=alldmLineSelectionAll=1execInst=normalitdDateTim eDepArr=depitdLPxx_agbAccepted=yeslanguage=delocationServerActive=1lsSho wTrainsExplicit=1requestID=1selectAssignedStops=1sessionID=efa04.dc.vvs.d e_614894976stateless=1submit=submittryToFindLocalityPOIs=1tryToFindLocal ityStops=1useRealtime=1w_objPrefAl=2w_objPrefAl=12w_regPrefAm=1/ /output /translation Es hat mir bereits ein anderer Mapper eine Regel für den Verkehrsverbund Stuttgart geschickt. Dort wird mit dem Tag ref:vvs=* gearbeitet. Statt mehreren operator=* Tags wird dort nur die Existenz des Tags ref:vvs=* abgefragt und wenn das vorhanden ist, wird damit die Auskunft unter www2.vvs.de aufgerufen. Vielleicht könntest du mal ausprobieren, ob das auch für die Haltestellen in deiner Umgebung funktioniert? Wie du schon schreibst wird das mit uic_ref wohl nichts (wobei streng genommen auch für Bushaltestellen solche Nummern existieren, die aber glaube ich nicht offiziell sind). Falls doch eine andere Lösung notwendig ist, können wir da sicherlich etwas passendes zusammenbasteln. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen
Hallo Jimmy, eine kleine Frage: Hast du absichtlich bei den ÖBB einen Link generiert wo nur 5 Fahrten angezeigt werden? Mit showJourneys= kannst du auch mehr draus machen. Danke für den Hinweis! Habe die Zahl jetzt auf 20 gesetzt. Für Wien und die Wiener Linien gibt es leider keinen zugänglichen Monitor. Außer man spielt es über quando.at (z.B.: http://m.qando.at/qr/00486), aber die Nummern müssten extra eingepflegt werden. Wenn es offizielle Nummern des Verkehrsunternehmens sind, sollten die meiner Meinung erfasst werden. Wenn es nur interne Nummern eines Anbieters oder einer Software sind, natürlich nicht. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen
Hallo Paule, Warum hast Du die Mobilauskunft der Bahn eingefügt und nicht die ausführlichere Abfahrtstafel auf der Homepage der Bahn direkt? Habe es korrigiert. Hatte ursprünglich vor, die Abfahrtsseite direkt in die Anwendung mit einem iframe einzubinden, wofür sich natürlich die mobile Version besser eignen würde. Hatte die Idee aber dann (vorerst) doch verworfen und vergessen, den Link zu ändern... ;) Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue Features in der OpenLinkMap: Abfahrtszeiten und Adressen
Hallo allerseits, nach langer Zeit gibt es wieder einige neue Features in der OpenLinkMap: Die wichtigste Neuerung ist der Public transport-Layer. Dies ist ein zusätzlicher Layer, der Zusatzinformationen zu Bushaltestellen, Bahnhöfen, etc. anzeigt. Die interessanteste Funktion ist dabei die Verlinkung zu Echtzeit-Abfahrtszeiten auf der Homepage des jeweiligen Verkehrsunternehmens. Die Idee zu dieser Funktion stammt von Mappern aus der belgischen Community. Beispiel: http://www.openlinkmap.org/?lat=50.87921lon=4.71299zoom=16layers=BFT Das Ganze funktioniert folgendermaßen: Die Software generiert anhand einer Regeldatei, dessen Format dem für das Tagtransform Plugins von Osmosis (http://wiki.openstreetmap.org/wiki/Osmosis/TagTransform) entspricht, ein neues Tag mit einer URL zur Seite mit den Abfahrtszeiten für diese Haltestelle. Bei der belgischen Gesellschaft De Lijn beispielsweise wird bei Auswerten der Datei ein neues Tag erzeugt, das einen Link zur Seite mit den Abfahrtszeiten für eine bestimmte Haltestelle enthält. In diesem Fall wird dabei die Haltestellen-ID aus dem Tag ref=* an eine bestimmte URL des Verkehrsunternehmens gehängt. Ich habe bereits Regeln für die Fahrplanauskunft der DB und ÖBB hinzugefügt. Dadurch wird in Deutschland bei Bahnhöfen, die mit operator=DB AG/DB/DB Regio/... und uic_ref=* getaggt sind, ein Link zur Fahrplanauskunft der Deutschen Bahn angezeigt. Da die ÖBB wie auch die Deutsche Bahn das Hafas-System zur Fahrplananzeige nutzen, brauchte ich nur die URL anzupassen. Trotzdem fehlen weiterhin noch Regeln für viele Verkehrsverbünde und Unternehmen, sowohl im Inland, als auch im Ausland. Ich würde mich sehr freuen, wenn andere Interessierte Regeln für weitere Unternehmen/Verkehrsverbünde erstellen und diese in der Datei ergänzen. Bei der Datei habe ich bewusst das bereits existierende Format gewählt, damit auch andere Anwendungen (z.B. Osmosis) diese Datei auswerten können. Ich lade andere Entwickler explizit dazu ein, die Datei in eigenen Projekten zu verwenden und rufe auf, Regeln zu allen möglichen Fahrplanauskünften in dieser Datei zu sammeln, um so das Wissen zu teilen und viel Arbeit zu ersparen. Regeldatei: https://github.com/rurseekatze/OpenLinkMap/blob/master/locales/departures.xml Außerdem gab es vor einiger Zeit einige Verbesserungen bei der Anzeige von Adressen: Zum einen wird das Tag addr:suburb nun ausgewertet, damit werden Adressen, die z.B. als addr:city=Berlin und addr:suburb=Kreuzberg erfasst sind, in den Popups als Berlin-Kreuzberg angezeigt. Eine andere Neuerung bei den Adressen betrifft die Adressformate: Dort bestand das Problem, dass diese je nach Land völlig unterschiedlich aufgebaut sein können (z.B. Unterschied Deutschland-USA). Damit die Adressen also je nach Land unterschiedlich formatiert werden, gibt es eine Datei mit Platzhaltern für verschiedene Länder. Viele Länder sind noch nicht vorhanden, wer welche ergänzen möchte, findet die Datei hier: https://github.com/rurseekatze/OpenLinkMap/blob/master/api/addressformats.php Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gesucht - einen Punkt pro BAB-Anschlusstelle (Kreuz)
Hallo Jan, mal eine Frage an unsere DB-Spezies. Ist es möglich pro Anschlussstelle (alle Fahrbahnrichtungen) einen Note mit der Ref-Nummer und dem AS-Namen zu generieren. Am einfachsten könnte ich es mir vorstellen, wenn die Nodes, der AS, einfach gemittelt werden. Der vermutlich einfachste Weg ist es, wenn du z.B. mit PostGIS eine Fläche aus den zu einer Anschlussstelle gehörenden Punkten bildest und dir dann den Centroid dieser Fläche zurückgeben lässt. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neuimport nach Lizenzwechsel?
Hallo, eine kurze Frage: der Lizenzwechsel scheint ja nun durch zu sein. Muss ich nun ein neues Planetfile herunterladen und importieren, oder kann ich einfach die normalen Diff-Updates laufen lassen? Eigentlich müsste sich ja an den Daten seit dem Durchlaufen des Redaction Bots nichts mehr geändert haben, sodass kein Neuimport notwendig wäre, aber an verschiedenen Stellen (u.a. Forum) hörte es sich so an, als sei ein Neuimport notwendig. Ich hoffe, die Experten können mich ein wenig aufklären. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Digitale Denkmal-Liste
Hallo, bin auf folgendes interessantes Projekt gestoßen: http://www.wz-newsline.de/lokales/rhein-kreis-neuss/dormagen/sisyphos-aufgabe- ehepaar-erstellt-digitale-denkmal-liste-1.1080293 OSM wäre doch eine gute Grundlage für die Erfassung, bzw. haben unser und deren Projekt einige Gemeinsamkeiten und ließen sich doch gut kombinieren: Vielleicht könnte man die Daten in OSM importieren oder die Denkmäler auf einer POI-Karte darstellen. Sie nehmen ja kein Geld für ihre Arbeit und sind eventuell sogar bereit, ihre Daten der Öffentlichkeit zur Verfügung zu stellen. Jedenfalls wäre es vielleicht ganz nützlich, wenn andere Leute ebenfalls die Daten pflegen könnten. Gibt es hier Experten für Denkmäler und historische Daten? Vielleicht kann einer von denen Kontakt zum Projekt aufnehmen, denn mir fehlt einfach die Zeit, um mich auch noch um dieses Projekt zu kümmern... ;) Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Digitale Denkmal-Liste
Schade um die Doppelarbeit. Zusammenarbeit in so einer Sache ist wirklich wichtig - aber warum mit dem naturgemäß beschränkten Projekt weniger Privatpersonen? Wäre es nicht besser, die Kräfte in einem großen Projekt zu sammeln? Genau der Gedanke, der mir beim Lesen des Artikels auch kam. Die Fotos könnte man ziemlich gut in Wikipedia brauchen oder mit einem image=* Tag in OSM verlinken. Ich vermute die beiden Projektteilnehmer haben noch nichts von OSM gehört und würden sich von den Vorteilen überzeugen lassen. Denn die Beweggründe für das Selber-Mappen sind bei denen ziemlich ähnlich wie die bei uns... Ich würde es sehr begrüßen, wenn es in der OSM-Community mehr Interesse für Kulturdenkmäler gäbe. Grundsätzlich habe ich schon ein Interesse daran - aber genauso auch z.B. an Bahnthemen. Bei letzterem gibt es auch nicht viele Experten und das finde ich für mich persönlich wichtiger. Für alle Projekte und Hobbys (sind bei mir auch noch ein paar andere neben OSM) reicht eben nicht die Zeit und man muss Prioritäten setzen. Ich wünschte, ich könnte all meine Ideen realisieren, aber ich werde wahrscheinlich selbst als Rentner nicht genug Zeit für alles haben. Daher teile ich meine Ideen lieber anderen Leuten mit, damit sich dort Leute finden können, die sich für solche Projekte einsetzen... ;) Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Funkamateur
Am Samstag, 25. August 2012, 11:44:25 schrieb Michael Kugelmann: Am 24.08.2012 11:38, schrieb Alexander Matheisen: Oder eher eine Karte, wo man die Standorte der Verbindungspartner sehen kann? Sowas habe ich nämlich schon gebaut: http://rurseekatze.bplaced.net/map/ Legst Du die Marker quasi als Liste in einer extra Dabei (mit Koordinaten) ab oder wie machst Du das? Ich lade mein Logfile als ADIF auf den Server hoch und schreibe die Daten dann mit einem PHP-Script in eine MySQL Datenbank. Dabei liest das Scipt das Locatorfeld aus und rechnet die Angabe in eine Koordinate um. Theoretisch könnte man die Daten auch von qrz.com auslesen, aber das war mir bisher zu viel Arbeit... Wenn du willst, kannst du das Script mal haben, oder ich stelle es auf Github. 73 de DO4NE (Alex) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Funkamateur
Am Freitag, 24. August 2012, 09:21:53 schrieb Markus: Gibt es hier einen funkenden OSMer? Vielleicht könnten wir ja eine Spezialkarte bauen... Ja, ich bin einer. Was willst du denn bauen? Kartenübersicht von Clubstationen, Baken, Relais und ähnlichem? Oder eher eine Karte, wo man die Standorte der Verbindungspartner sehen kann? Sowas habe ich nämlich schon gebaut: http://rurseekatze.bplaced.net/map/ Grüße Alex (DO4NE) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Funkamateur
Am Freitag, 24. August 2012, 12:01:37 schrieb Markus: Hallo Alex, Kartenübersicht von Clubstationen, Baken, Relais und ähnlichem Wäre hübsch... Die Idee dazu hatte ich schonmal, aber leider habe ich nicht genug Zeit, um so viele Projekte zu starten... Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo, siehe Lonvias Rad- und Wanderkarten, oder die ÖPNV-Karte. Wenn Relationen so unnütz oder kompliziert auszuwerten wären, würde es diese Karten nicht geben. spatialite bietet für kleinere Projekte gute Möglichkeiten mit OSM-Daten zu arbeiten, erfordert aber etwas Ahnung von SQL. Ich muss meine Aussage mal ein wenig korrigieren. Ich habe nicht gesagt, dass Relationen generell kompliziert auszuwerten sind. Das ist es nur bei der Art und Weise, wie ich bisher die Datenbank der OLM befüllt habe. Für mich waren die site-Relationen in diesem Fall im Verhältnis zum Nutzen zu schiwerig auszuwerten, der benötigte Arbeits- und Rechenaufwand lohnte sich für mich nicht unbedingt. Mittlerweile muss ich mich da aber etwas selbst korrigieren, denn mir ist noch ein einfacherer Weg der Auswertung eingefallen, als ich erst gedacht hatte. Jetzt sollte zumindest der Rechenaufwand recht klein sein. Die Sache mit dem Arbeitsaufwand verschiebe ich dann mal auf die Zeit nach dem Urlaub... ;) Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Ja sowas ruft nach einer Relation. Ich habe beschlossen, dass ich die für die Karte interessanten Firmen mit den entsprechenden Funktionen von PostGIS heruasfiltere. Das ist für den Mapper die einfachste Lösung, spart Speicher und sollte in den meisten Fällen auch korrekte Ergebnisse liefern. Ich würde mich beim taggen vom Güterverkehr eher an den public_transport=* Tags orientieren. Für die verschiedenen Haltepunkte ist dann eine Relation analog der stop_area wohl das beste. Warum manche hier die Erfassung der Beladestellen in Industrieanlagen so wichtig finden, kann ich nicht ganz nachvollziehen. Ich jedenfalls werde sie nicht in meiner Karte berücksichtigen und finde auch die Erfassung (zumindest zur Zeit) wenig sinnvoll. und für die Fabrik eine site-relation. Und von site-Relationen halte ich nicht besonders viel. Ein Polygon mit der Ausdehnung eines Fabrikgeländes erledigt das gleiche und ist weniger kompliziert. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Lizenzwechsel
On 18.06.2012 15:52, Alexander Matheisen wrote: * Wie sieht es mit dem Status der Datenbereinigung aus? Hat noch nicht angefangen. Es heisst, dass die Software, die eingesetzt werden soll, nun weitgehend fertig sei. Bevor sie loslaeuft, wird es aber einen Testlauf auf einer vollstaendigen Datenbankkopie geben. * Wann ist der Lizenzwechsel vollständig abgeschlossen? Ist nicht klar - eben dann, wenn der Bot fertig ist und die OSMF den Startschuss fuer ODbL gibt. Ich wuerd mal so Ende Juli, Anfang August damit rechnen, aber ich hab schon oft daneben gelegen ;) * Wann kommt das erste Odbl-Planetfile bzw. wann die Diffs (ich weiß, zur Zeit erscheinen sie unter http://planet.openstreetmap.org/redaction-period/), aber wann sind sie wieder unter der alten URL verfügbar? Das erste ODbL-Planetfile kommt fruehestens wenn OSMF die Verwendung der neuen Lizenz verkuendet, spaetestens einige Tage danach. Dieser Verkuendungstermin ist nicht identisch mit dem Datenbereinigung ist fertig-Termin. Da bin ich ja beruhigt. Ich dachte schon, ich hätte das alles verschlafen. Ich erhielt nämlich bereits Mails, warum die OpenLinkMap nicht mehr aktualisiert wurde, denn der Lizenzwechsel sei ja längst abgeschlossen... Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Am Samstag, 16. Juni 2012, 18:36:38 schrieb Martin Koppenhoefer: Am 16. Juni 2012 16:16 schrieb Alexander Matheisen alexandermathei...@ish.de: Am Samstag, 16. Juni 2012, 14:37:10 schrieb Martin Koppenhoefer: Am 16. Juni 2012 14:35 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 15. Juni 2012 21:11 schrieb Alexander Matheisen alexandermathei...@ish.de: Was haltet ihr von dieser Idee? ich würde das automatisch bestimmen lassen aus den Gleisen, die auf das Gebiet führen, und ggf., falls bisher Werksgleise nicht als solches erkennbar sind (gerade zu faul, das im Wiki nachzuschlagen), dann lieber die Gleise näher definieren. bzw. den Haltepunkt. Also anstatt indirekt am Gesamtgelände zu taggen: hat einen Eisenbahnhaltepunkt/ Bahnverladung, lieber konkret dieses Feature taggen. Was ist z.B. mit einem großen Stahlwerk? Wo sind da die Haltepunkte? Und wie soll man dann den Bezug zur Fabrik haben? Ich will ja auf der Karte die Fabrik mit Namen und möglichst ihre Fläche sehen und nicht eine Haltestelle als kleiner Punkt ohne Namen und Ausdehnung. das muss ja nicht unbedingt ein kleiner Punkt sein. Ich habe z.B. mal die Bahnverladung bei Mercedes in Sinderfingen gesehen, das ist ein größerer Bereich, eine Art Güterbahnhof. Wer einen eigenen Gleisanschluss hat, wird normalerweise wohl auch innerhalb des Geländes für den Umschlag einen größeren Bereich vorsehen. Vermutlich ist das auch der Anteil, der für Eisenbahnkarten interessant ist. Meist gibt es aber gerade in großen Industrieanlagen wie Stahlwerken oder Chemiefabriken über das ganze Gelände verteilt Beladeeinrichtungen. Da hat man dann wieder das Problem, dass man eine Beziehung zwischen diesen einzelnen Punkten herstellen muss. Das kann man über eine Relation machen, aber wenn man ein Tag an die Fläche hängt, lässt sich dieses Problem auch einfacher lösen. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Am Sonntag, 17. Juni 2012, 18:03:45 schrieb Jimmy_K: Am 16.06.2012 14:37, schrieb Martin Koppenhoefer: bzw. den Haltepunkt. Also anstatt indirekt am Gesamtgelände zu taggen: hat einen Eisenbahnhaltepunkt/ Bahnverladung, lieber konkret dieses Feature taggen. Finde ich eine gute Idee. Vielleicht sollte man das Tag usage erweitern oder deren Inhalt konkretisieren. Ich würde den Gleisabschnitt auf dem die Verladung stattfindet/ stattfinden kann, entsprechend mit Tags versehen. z.B.: usage=container_loading (jetzt mal als Beispiel in einem Container-Terminal) Für den von dir angesprochenen Zweck gibt es bereits das Tag service=spur. Diese Erfassungsvariante bringt aber nur Nachteile mit sich: 1. Ich habe dann meist mehrere Gleise mit diesem Tag und muss die irgendwie zusammenfassen, einen Centroid bestimmen oder eine Beziehung zueinander herstellen. 2. Auf der Karte will ich die Ausdehnung der Fabrik sehen, was hier nicht möglich ist. 3. Ich will auf der Karte den Namen der Firma haben. Um den zu ermitteln, bräuchte ich wieder eine Relation oder muss es mit Funktionen der Geodatenbank ermitteln. Ganz ehrlich: Man kann es sich auch unnötig kompliziert machen. Ein simples Tag und die Sache ist erledigt. Keine zeitraubende Erfassung mit Relationen, keine komplizierte Auswertesoftware schreiben, ganz zu schweigen vom Mehraufwand bei den Ressourcen, die bei den OSM-Projekten bekanntlich nicht im Überfluss vorhanden sind. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Status Lizenzwechsel
Hallo, mittlerweile ist bei mir einige Unklarheit zum aktuellen Status des Lizenzwechsels entstanden. Wiki, Forum und Mailingliste haben mir bei meinen Fragen nicht wirklich Klarheit verschafft: * Wie sieht es mit dem Status der Datenbereinigung aus? * Wann ist der Lizenzwechsel vollständig abgeschlossen? * Wann kommt das erste Odbl-Planetfile bzw. wann die Diffs (ich weiß, zur Zeit erscheinen sie unter http://planet.openstreetmap.org/redaction-period/), aber wann sind sie wieder unter der alten URL verfügbar? Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Am Montag, 18. Juni 2012, 15:48:49 schrieb Martin Koppenhoefer: Am 18. Juni 2012 15:28 schrieb Alexander Matheisen alexandermathei...@ish.de: Meist gibt es aber gerade in großen Industrieanlagen wie Stahlwerken oder Chemiefabriken über das ganze Gelände verteilt Beladeeinrichtungen. um so besser ist es doch, diese auch zu mappen. Klar, die könnte man auch erfassen, auch wenn es für meine Anwendung nicht von Interesse ist und es auch sonst keine Anwendung geben wird, die daran interessiert sind. Da hat man dann wieder das Problem, dass man eine Beziehung zwischen diesen einzelnen Punkten herstellen muss. das sollten die Gleise doch eigentlich tun Wie soll man anhand der Gleise eine Zusammengehörigkeit verschiedener Ladestellen herstellen? Das musst du mir jetzt mal genauer erklären... Das kann man über eine Relation machen, aber wenn man ein Tag an die Fläche hängt, lässt sich dieses Problem auch einfacher lösen. welches Problem? Das Problem ist, dass man die verschiedenen Ladestellen, die über ein Werksgelände verteilt sind, irgendwie zusammenfassen muss. In dem einen Fall ergänzt man Details in der Karte, die vielfältig genutzt werden können, und alle möglichen Probleme lösen, Wie gesagt habe ich nichts gegen die Erfassung dieser Ladestellen, aber die müssen einen Bezug untereinander und zur Firma erhalten. Jedoch kann ich mir zur Zeit auch noch keine Anwendung vorstellen, die ernsthaft an den Ladestellen interessiert wäre. Wenn, dann wären dies nur Routinganwendungen für Güterzüge, aber damit die sich zu einer Ladestelle routen lassen können, brauchen die noch weitere Informationen, an die wir von OSM nicht so leicht rankommen. im anderen Fall ein schnödes Attribut, das praktisch keine Mehrinformation bietet, da es auch automatisch ableitbar ist, und nur für eine ganz bestimmte Frage eine (grobe) Antwort liefert. Diese Information ist sonst aber nur mit einem Mehraufwand an geografischen Operationen in der Datenbank verbunden und möglicherweise auch nicht immer 100%ig korrekt. Natürlich wäre der Implementierungsaufwand nicht sehr hoch, aber der Rechenaufwand steigt und es sind eventuell größere Server nötig. Ein Tag dagegen vereinfacht das ganze sehr stark und ist völlig eindeutig. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Am Samstag, 16. Juni 2012, 14:35:41 schrieb Martin Koppenhoefer: Am 15. Juni 2012 21:11 schrieb Alexander Matheisen alexandermathei...@ish.de: Was haltet ihr von dieser Idee? ich würde das automatisch bestimmen lassen aus den Gleisen, die auf das Gebiet führen, und ggf., falls bisher Werksgleise nicht als solches erkennbar sind (gerade zu faul, das im Wiki nachzuschlagen), dann lieber die Gleise näher definieren. Solche Sachverhalte wie oben, die sich bereits aus Topologie und Lage der Daten ergeben, sollte man möglichst nicht unnötig redundant auch noch mit tags eintragen. Das ist jedoch nur mit erheblichem Rechenaufwand verbunden und würde das Rendering langsamer machen. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Am Samstag, 16. Juni 2012, 14:37:10 schrieb Martin Koppenhoefer: Am 16. Juni 2012 14:35 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 15. Juni 2012 21:11 schrieb Alexander Matheisen alexandermathei...@ish.de: Was haltet ihr von dieser Idee? ich würde das automatisch bestimmen lassen aus den Gleisen, die auf das Gebiet führen, und ggf., falls bisher Werksgleise nicht als solches erkennbar sind (gerade zu faul, das im Wiki nachzuschlagen), dann lieber die Gleise näher definieren. bzw. den Haltepunkt. Also anstatt indirekt am Gesamtgelände zu taggen: hat einen Eisenbahnhaltepunkt/ Bahnverladung, lieber konkret dieses Feature taggen. Was ist z.B. mit einem großen Stahlwerk? Wo sind da die Haltepunkte? Und wie soll man dann den Bezug zur Fabrik haben? Ich will ja auf der Karte die Fabrik mit Namen und möglichst ihre Fläche sehen und nicht eine Haltestelle als kleiner Punkt ohne Namen und Ausdehnung. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Hallo, noch eine weitere Ergänzung meinerseits für das Taggingschema: Ich habe mir gedacht, dass man Fabriken, Industriebetriebe, etc., die über einen Gleisanschluss verfügen, mit einem besonderen Tag kennzeichnet. So würde z.B. ein Chemiewerk oder ein kleiner Landhandel zusätzlich zu man_made=works (oder als was das auch immer getaggt ist) ein Tag wie etwa railway_access=yes erhalten. Mit dem Tag wäre es dann möglich, solche Betriebe auch der Karte zu rendern. So sieht man schnell, welche Firmen einen Bahnanschluss haben. Außerdem ist es etwa für Bahnunternehmen interessant, die bei einer Lieferung an Firma X schnell sehen können, wie man dort hingelangt. Auch für Bahninteressierte ist es in Simulatoren oder rein aus Interesse von Relevanz. Bereits existierende Eisenbahn-Atlanten zeigen zumindest die größeren Fabriken mit Bahnanschluss auf der Karte... Was haltet ihr von dieser Idee? Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Übrig bleiben jetzt noch folgende Möglichkeiten: * Relation Das ist noch kein Datenmodell. Je nachdem, ob Punkte oder auch Wegsegmente Relationsmitglieder sind und wie man die role-Elemente definiert, ergeben sich verschiedene Vor- und Nachteile. Ja stimmt, da muss man noch entscheiden, wie man es dann genau macht. Mit ging es jetzt erstmal grundsätzlich um die Akzeptanz einer Erfassung per Relation. Möglich wäre eine Rolle outline wie bei diesem Bridge-Proposal. Das wäre dann ein Weg, der die Fläche des BÜs beschreibt. Dann könnte man noch Schrankenpositionen und Kreuzungspunkte von Straße und Schiene als Mitglieder hinzufügen. -Vorteile: ein OSM-Objekt für einen Bahnübergang, sämtliche Sonderfälle abdeckbar, Mikromapping möglich -Nachteile: komplizierte Erfassung, in der Regel schwieriger auszuwerten - je nach Modell fehleranfällig * Fläche -Vorteile: ein OSM-Objekt für einen Bahnübergang, einfacher zu erfassen als eine Relation, gibt reale Ausdehnung wieder, Positionierung von Schranken einfach möglich (zumindest in den meisten Fällen), einfachere Auswertung als Relation - Datenmodell auf andere Verkehrswegekreuzungen (Straßenkreuzung, Klappbrücke) übertragbar Bei Straßenkreuzungen gibt es auch bereits ein Proposal für einen Ampel-Way, damit man die Zusammengehörigkeit von mehreren Ampeln an einer Kreuzung insbesondere in Routern besser auswerten kann. -Nachteile: Probleme bei manchen Sonderfällen (T-Kreuzung mit eigener Schranke vor BÜ) Alex, kannst du ein Beispiel geben? Die Fläche, die bei herannahenden Zügen geräumt werden muss, ist doch recht eindeutig. Vor allem den Mikromappern ging es ja um die genaue Positionierung der Schranken und Warnlichter. Bei Standardfällen kann man die Schranken oder Lichter automatisch auf die Schnittpunkte von BÜ-Fläche und Straße setzen. Allerdings kann es - soweit ich weiß - auch Sonderfälle wie folgenden geben: | | === - Gleis | | | |-- | |-- | | Vor dem Bahnübergang befindet sich in diesem Fall eine Einmündung, die ein eigenes Warnsignal/Schranke besitzt. Da dort aber kein Kreuzungspunkt zwischen Straße und BÜ-Fläche ist, würde nach dem Standardverhalten dort kein Warnlicht gesetzt. Ein anderer Problemfall: Ein Fußwegübergang neben einer Straße bildet zwar zusammen mit dem Straßen-BÜ einen Bahnübergang, aber die Sicherungstechnik des Fußwegüberganges kann anders sein als die des Straßen-BÜs. An die gemeinsame BÜ-Fläche lässt sich jedoch nur die Sicherungstechnik eines der beiden BÜs taggen. Auf der anderen Seite stellt sich natürlich die Frage, ob man es überhaupt so detailliert haben will... Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Am Donnerstag, 31. Mai 2012, 11:24:25 schrieb Martin Koppenhoefer: Am 30. Mai 2012 21:28 schrieb Alexander Matheisen alexandermathei...@ish.de: Nicht zu einem Bahnhof zählen danach: * Pendlerparkplatz (man kann auch ohne sie mit dem Zug fahren) * Radstation (gleicher Grund wie oben) -1, auch diese gehören m.E. nach der o.g. Definition dazu, weil sie den Zu- und Abgang ermöglichen oder fördern. Oder interpretiere ich das falsch? Sofern es sich um Einrichtungen auf Bahngelände handelt, würde ich es dem Bahnhof zuschlagen. ...Nebenbetriebsanlagen sowie sonstige Anlagen einer Eisenbahn, die das Be- und Entladen sowie den Zu- und Abgang ermöglichen oder fördern. Für mich klingt das eher nach Bahnsteigen, Beladerampen und Zugangswege. So gesehen fallen Bahnsteige nämlich nicht unter zur Abwicklung oder Sicherung des Reise- oder Güterverkehrs auf der Schiene erforderlich, denn in einen Zug kann man auch ohne Bahnsteig einsteigen (ist dann nur etwas hoch). Mit Bahnsteig dagegen ist es angenehmer, damit fördern sie den Zu- oder Abgang zum Zug. Klar, Bahnsteige gehören natürlich damit auch dazu. Ein ParkRide-Parkplatz aber auch ein beliebiger anderer Parkplatz auf Bahngelände an einem Bahnhof gehört m.E. auch dazu. Bei den Parkplätzen kann man sich wirklich streiten: Gehört ein Parkplatz für Bahnmitarbeiter zum Bahngelände oder nicht? Meiner Meinung sollte man es aber bei solchen strittigen Punkten nicht zu genau nehmen. Ob das nun zum Bahngelände gehört oder nicht liegt dann letztendlich in der Freiheit des Mappers. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Gegenvorschlag: Bahnübergänge können als Fläche erfasst werden. Die Fläche umfasst in Straßenrichtung den Bereich zwischen den Andreaskreuzen/Schranken, in Gleisrichtung den mit Platten oder Asphalt versehenen Bereich. Die Fläche und die kreuzenden Wege haben gemeinsame Punkte. Hört sich grundsätzlich nicht schlecht an, macht die Erfassung aber auch wieder schwieriger: Bei einem Gleis und einer Straße ein Punkt, bei zwei Gleisen und einer Straße einen Weg, bei zwei Gleisen und zwei Straßen eine Fläche, und was ist dann bei einem Gleis und zwei Straßen? Nein, nur als Punkt oder als Fläche. Die Flächendefinition ist genauso auf nur ein Gleis oder nur einen highway anwendbar. Oft hilft ein Bild beim Verständnis. Ich habe einen großen Bahnübergang zum Test als Fläche erfasst: [1]. Die Details habe ich von Aerowest-Luftbild übernommen. Und wie erkennt dann ein Routingprogramm den Bahnübergang? Daran, dass die Straße teilweise innerhalb einer solchen Fläche liegt. [1] www.osm.org/browse/way/163036823 Um die Diskussion noch einmal aufleben zu lassen: Eine gute Lösung haben wir ja weiterhin noch nicht gefunden, aber auf jeden Fall kann ich schonmal sagen, dass ich von der Way-Lösung Abstand genommen habe. Auch dort hat man nämlich ein Problem mit mehreren kreuzenden Straßen. Übrig bleiben jetzt noch folgende Möglichkeiten: * Relation -Vorteile: ein OSM-Objekt für einen Bahnübergang, sämtliche Sonderfälle abdeckbar, Mikromapping möglich -Nachteile: komplizierte Erfassung, in der Regel schwieriger auszuwerten * Fläche -Vorteile: ein OSM-Objekt für einen Bahnübergang, einfacher zu erfassen als eine Relation, gibt reale Ausdehnung wieder, Positionierung von Schranken einfach möglich (zumindest in den meisten Fällen), einfachere Auswertung als Relation -Nachteile: Probleme bei manchen Sonderfällen (T-Kreuzung mit eigener Schranke vor BÜ) * Einzelne Punkte -Vorteile: einfache Erfassung, einfache Auswertung für Router -Nachteile: mehrere OSM-Objekte für ein reales Objekt, Zusammengehörigkeit nicht immer erkennbar, Positionierung von Schranken etc. nicht einfach möglich Wer noch weitere Argumente findet, möge die bitte ergänzen! Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Nicht zu einem Bahnhof zählen danach: * Pendlerparkplatz (man kann auch ohne sie mit dem Zug fahren) * Radstation (gleicher Grund wie oben) -1, auch diese gehören m.E. nach der o.g. Definition dazu, weil sie den Zu- und Abgang ermöglichen oder fördern. Oder interpretiere ich das falsch? Sofern es sich um Einrichtungen auf Bahngelände handelt, würde ich es dem Bahnhof zuschlagen. ...Nebenbetriebsanlagen sowie sonstige Anlagen einer Eisenbahn, die das Be- und Entladen sowie den Zu- und Abgang ermöglichen oder fördern. Für mich klingt das eher nach Bahnsteigen, Beladerampen und Zugangswege. So gesehen fallen Bahnsteige nämlich nicht unter zur Abwicklung oder Sicherung des Reise- oder Güterverkehrs auf der Schiene erforderlich, denn in einen Zug kann man auch ohne Bahnsteig einsteigen (ist dann nur etwas hoch). Mit Bahnsteig dagegen ist es angenehmer, damit fördern sie den Zu- oder Abgang zum Zug. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Am Montag, 14. Mai 2012, 18:42:33 schrieb Garry: Am 14.05.2012 16:45, schrieb Max: n Deutschland stimmt das. In vielen anderen Ländern gibt es keine Verbindungen zwischen Hochgeschwindigkeitsnetz und regulärer Bahn. Nachtrag: mir ist ein Beispiel eingefallen. In Taiwan gibt es die High-Speed-Rail (HSR). Die wird im Linksverkehr betrieben, das restliche Schienennetz im Rechtsverkehr. Möglicherweise hat die HSR auch eine andere Spurweite und eine andere Elektrifizierung. Der Mischbetrieb dürfte dennoch häufiger sein, ist mir jetzt jedenfalls nicht bekannt dass es sehr viele Länder überhaupt mit Hochgeschwindigkeitsnetz gibt. Von daher sehe ich es als praxistauglicher ein Zusatztag für die Hochgeschwindigkeitsbereiche zu vergeben als Streitfälle zu provozieren ob das jetzt eine rail = highspeed Streckentyp ist. OK, werde es ändern. Mir ist nämlich auch aufgefallen, dass es bei den Ausbaustrecken schwierig zu definieren ist. Ich würde vorschlagen usage=main und highspeed=yes. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Wo endet ein Personenbahnhof? Am Bahnsteigende, am Ausfahrsignal oder an der letzten Weiche? Gehören das Nebengleis ohne Bahnsteig, das alte Bahnhofsgebäude mit Fahrkartenautomat, Restaurant und Bankfiliale, die Fahrradständer und der Pendlerparkplatz dazu? Ich würde sagen, man übernimmt weitgehend die Definition der EBO (http://www.gesetze-im-internet.de/ebo/__4.html). Auch wenn das Projekt international ist, lassen sich die deutschen Definitionen wahrscheinlich ohne Probleme auch auf andere Länder übertragen. Bahnhofsbegrenzung in Gleisrichtung: Die Einfahrsignale oder Trapeztafeln beider Richtungen, sonst die Einfahrweichen bzw. ersten Weichen. Im Ausland sollte sich die Definition mit den Einfahrsignalen auch anwenden lassen. Sonst nimmt man eben die Einfahrweichen. Bahnhofsbegrenzung zur Seite: Laut EBO: Bahnanlagen sind alle Grundstücke, Bauwerke und sonstigen Einrichtungen einer Eisenbahn, die unter Berücksichtigung der örtlichen Verhältnisse zur Abwicklung oder Sicherung des Reise- oder Güterverkehrs auf der Schiene erforderlich sind. Dazu gehören auch Nebenbetriebsanlagen sowie sonstige Anlagen einer Eisenbahn, die das Be- und Entladen sowie den Zu- und Abgang ermöglichen oder fördern. Es gibt Bahnanlagen der Bahnhöfe, der freien Strecke und sonstige Bahnanlagen. Fahrzeuge gehören nicht zu den Bahnanlagen. Auch diese Definition lässt sich meiner Meinung gut auf OSM übertragen. Für mich zählen nach dieser Definition zu einem Bahnhof: * Gleise * Bahnsteige * Lokschuppen * Bahnhofsgebäude * Stellwerk * Verladerampen für Autozüge Nicht zu einem Bahnhof zählen danach: * Pendlerparkplatz (man kann auch ohne sie mit dem Zug fahren) * Radstation (gleicher Grund wie oben) Unklar bin ich mir noch bei Parkplätzen für Bahnmitarbeiter, die mit Schildern als Bahngelände - Betreten verboten gekennzeichnet sind. Die sind so gesehen auch nicht für den Bahnbetrieb notwendig, aber rechtlich schon Bahngelände. Genauso wie stillgelegte oder zugewucherte Bahngelände, die mit Schildern als Bahngelände markiert sind. - Die Verbindung verschiedener Gleise sollte auch ohne Zusatztag railway=switch als Weiche ausgewertet werden. Der Sonderfall (Kreuzung ohne Kreuzungsweiche) sollte die Zusatzinformation als Tag oder Abbiegerelation bekommen. Du hast schon recht, allerdings lasse ich das lieber zur Verdeutlichung. An den anderen Tags wue würde sich ja nichts ändern und so wäre eine normale Weiche z.B. mit ref=W1 und railway:manual=yes getaggt. Für nicht-eingeweihte ist dann nicht unbedingt klar, worauf sich die Tags beziehen. Eine statistische Abfrage, wieviele Weichen erfasst sind, ist außerdem einfacher möglich (z.B. in Taginfo). Die bislang etablierte Logik, dass eine Verbindungspunkt ohne Tags als Weiche ausgewertet wird, darf man nicht umkehren. Wie bei den Abbiegerelation sollte man die Ausnahmen erfassen. Für eine einfache Kreuzungsweiche braucht man ohnehin solch ein Modell, um die möglichen Verbindung korrekt zu erfassen. Wer Details der Weiche erfassen möchte, mag railway=switch verwenden. Aber muss man nicht überall das Tag nachtragen. Ich wäre für ein explizites Tagging. Bei Weichen (dreigleisigen Gleisverbindungen) würde ich zur Kompatibilität aber vorschlagen, dass solche Gleisverbindungen ohne railway=switch als Weiche interpretiert werden. Bei Kreuzungen (viergleisigen Gleisverbindungen) ist auf jeden Fall explizites Tagging notwendig. (Doppel-)Kreuzungsweichen würden dann mit railway=switch und den entsprechenden Tags und Kreuzungen ohne Weichenfunktion mit railway=level_junction getaggt. - usage=highspeed ist inkompatibel zum etablierten usage=main Die Diskussion hatten wir bereits... Ich bleibe dabei: Eine Hochgeschwindigkeitsstrecke ist etwas anderes als eine normale Hauptstrecke und sollte daher anders getaggt werden. Eine Autobahn taggt man auch nicht highway=primary und highspeed=yes... Eine Autobahn ist keine spezielle Bundesstraße während eine Hochgeschwindigkeitsstrecke vermutlich als Hauptstrecke gilt. Aber abgesehen von Spitzfindigkeiten: wenn du ein etabliertes Tag wie usage=main umdefinieren willst, muss du das als gesondertes Proposal und nicht innerhalb eines umfangreichen Eisenbahnschemas vorschlagen. Habe es mittlerweile doch geändert (siehe entsprechender Mail). Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Am Mittwoch, 23. Mai 2012, 20:06:27 schrieb Jimmy_K: Am 14.05.2012 00:14, schrieb Stephan Wolff: Am 13.05.2012 00:45, schrieb Alexander Matheisen: - Für alle Flächen, insbesondere die Bahnhöfe/Rangierbahnhöfe, solltest du definieren, was dazu gehört Ist das nicht irgendwie selbstverständlich? (Gut, ich als Bahnexperte kann jetzt wahrscheinlich nicht nachvollziehen, wo da die Unklarheit ist. Du müsstest mir da mal auf die Sprünge helfen). Wo endet ein Personenbahnhof? Am Bahnsteigende, am Ausfahrsignal oder an der letzten Weiche? Gehören das Nebengleis ohne Bahnsteig, das alte Bahnhofsgebäude mit Fahrkartenautomat, Restaurant und Bankfiliale, die Fahrradständer und der Pendlerparkplatz dazu? Das ist das alte Problem, mit welchem auch schon die EWG kämpft. Bei der Festlegung vom ETCS hatte man schon Probleme einen Zug zu definieren. Ich bin bei der Definition sehr großzügig und würde fast alles, was nur irgendwie einen direkten Zusammenhang zum Bahnhof hat, in die Fläche integrieren. Ich würde es da auch nicht so eng sehen. Schließlich brauchen wir keine genauen Katasterdaten, sondern die Information, welche Fläche von der Bahn Wenn man Gleise, Bahnsteige, Lokschuppen, Bahnhofsgebäude und Stellwerke mit dieser Fläche erfasst hat, dann ist das auf jeden Fall nicht falsch. Ob jetzt irgendein Parkplatz dazu gehört, darüber kann man sich streiten. Und Ausnahmen bestätigen immer die Regel... In Einzelfällen kann man immer noch individuell entscheiden. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway = crossing
Ich überlege daher, ob ich ich nicht bei meinem Taggingschema zur OpenRailwayMap diese Unterscheidung herausnehme. Allerdings hat das wieder Konflikte mit den bisherigen Definitionen zur Folge. Was meint ihr dazu? Wir sollten überflüssiges nicht grundlos weiterverwenden. Im Taggingschema solltest du aber deutlich schreiben, dass dies ein Vorschlag ist, der nicht der bisherigen Definition entspricht. Da niemand auf meine Frage Welche Anwendung benötigt die Unterscheidung? ein Beispiel nennen konnte, gibt es vermutlich auch keine Konflikte zu bestehenden Anwendungen. Für welche (bisherige) Anwendung sollte diese Unterscheidung auch interessant sein? Auf einer normalen Karte wie Mapnik ist es eher unnötig, da der Standardnutzer wahrscheinlich wenig am Unterschied interessiert ist. Der will nur auf der Karte sehen, ob er da rüber kann und erkennt den Rest am kreuzenden Weg. Soweit ich das bisher gesehen habe, gibt es da auch keine Unterscheidung. Routing-Anwendungen interessiert nur, dass da ein Übergang ist. Dass er nur für Fußgänger ist, ergibt sich schon aus dem kreuzenden Weg. Einzig Bahn-Anwendungen wären vielleicht daran interessiert. Wenn man beispielsweise einen Streckenverlauf erzeugen will, auf dem in abgefahrener Reihenfolge Bahnhöfe, BÜs und anderes aufgelistet werden, braucht man zwar keine Unterscheidung zwischen Fuß-Übergang und Fahrzeug-Übergang, aber es wäre schön, wenn man keine kleinen Holzbohlen-Überwege für Bahnmitarbeiter als normale Bahnübergänge aufgelistet bekommt. Beispiel: http://upload.wikimedia.org/wikipedia/commons/e/e2/Gleis%C3%BCbergang_Bad_Kissingen_Bahnhof.JPG im Gegensatz zu solchen Bahnübergängen, die ich einheitlich mit Straßen-BÜs taggen würde: http://farm6.static.flickr.com/5039/5871036474_df23ffd879_b.jpg http://upload.wikimedia.org/wikipedia/commons/3/38/Umlaufgitter.jpg Es stellt sich aber die Frage, ob man auch diese Unterscheidung wirklich braucht. Denn auf der anderen Seite könnte man auch sagen, dass nur öffentliche Bahnübergänge eingetragen werden sollen. Kleine Überwege für Bahnmitarbeiter dagegen sind unnötig, weil sie in dem Sinne keinen Bahnübergang darstellen (keine Sicherung, kein Andreaskreuz, keine Pfeiftafel) und Bahnmitarbeiter eigentlich überall auf dem Bahngelände Gleise auf eigene Gefahr überqueren dürfen. Ich würde allerdings gleich einen Schritt weitergehen und ein Datenmodell einführen, dass auch für einen Bahnübergang aus mehreren railways und/oder mehreren highways genau ein OSM- Objekt vorsieht (entweder als Flächen- oder Relationmodell). Das würden einen Vorteil speziell für Routinganwendungen bringen. Damit beschäftige ich mich bereits und dazu läuft auch seit einiger Zeit eine Diskussion hier auf der Liste. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway = crossing
Hallo, railway = crossing -- Fußweg kreuzt mit Bahnschienen railway = level_crossing -- Straße kreuzt mit Bahnschienen Was setzt man, wenn sich ein Gleis, eine Straße und ein Fußweg im gleichen Punkt kreuzen? Im Zweifel kann man railway = level_crossing setzen. An fast jedem Bahnübergang mit Straßenverkehr kreuzen auch Fußgänger das Gleis. Welche Anwendung benötigt die Unterscheidung? Braucht man die Tags überhaupt? Die Information ist doch schon vorhanden, wenn ein Punkt sowohl in einen railway als auch highway enthalten ist. Für Router oder Bahnsimulatoren dürfte ein Objekt Bahnübergang wertvoller sein als mehrere einzelne Kreuzungspunkte (siehe Thread Mehrgleisige Bahnübergänge). Ich verstehe irgendwie auch nicht so ganz die Unterscheidung. Was ist bei einem kleinen unbeschrankten Bahnübergang an einem Feldweg? Wenn dort Traktoren fahren ist es ein level_crossing und wenn nur Fußgänger dort lang dürfen ein crossing? Für mich ist diese Unterscheidung irgendwie unnötig, da sich der Typ anhand des Typs des kreuzenden Weges herausfinden lässt. Ich überlege daher, ob ich ich nicht bei meinem Taggingschema zur OpenRailwayMap diese Unterscheidung herausnehme. Allerdings hat das wieder Konflikte mit den bisherigen Definitionen zur Folge. Was meint ihr dazu? Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned
http://wiki.openstreetmap.org/wiki/Railway die Seite nennt noch mehr Stufen, die Sinn machen wie ich finde: preserved - noch als Museumsbahn in Betrieb disused - nicht benutzt aber funktionsfähig oder mit geringem Aufwand wieder in Betrieb zu nehmen abandoned - Gleis abgebaut oder dem Verfall Preis gegeben , Strecke noch erkennbar obliterated - vollständig rückgebaut, ggf. durch Neubauten überformt, Strecke ggf. nicht mehr ohne Weiteres erkennbar Ist in meinem Schema bereits genu so vorhanden, außer, dass ich statt railway=obliterated railway=razed verwende. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned
Der Rechtsstaus dürfte für praktisch keinen Anwender von Bedeutung sein. Und Das ist für jeden relevant der sich auf dem Gelände aufhält. Bei Stillgelegt ist es nach wie vor ein Bahngelände und das Eisenbahngesetz greift. z.B. http://www.jusline.at/47._Betreten_hief%C3%BCr_nicht_bestimmter_Stellen_von_ Eisenbahnanlagen_EisBG.html Bei einer entwidmeten Strecke ist es dagegen kein Bahngelände mehr im Sinne des Eisenbahngesetz so dass dieses nich mehr greift. Es hat keinen praktischen Nutzen! Leute, für die das wichtig ist, würden dafür sowieso nicht OSM benutzen. Wenn man mit schwammigen Tags diese Unterscheidungsmöglichkeit in OSM unterbindet haben sie erst gar keine Möglichkeit OSM dafür zu nutzen. Schwammige Tags? In meinem Schema wird gibt es eine klare Definition der Tags, die auch mit bisherigen Definitionen im Wiki übereinstimmt. Und natürlich bleibt eine andere Unterscheidungsmöglichkeit offen. OSM ist frei, man kann einfach ein passendes Tag für genau diese Information definieren. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned
Spricht ja nichts dagegen wenn er den Gleiszustand einträgt, aber dafür ist disused/abandoned nicht geeignet. Doch, das Tag ist genau dafür geeignet. Was machst Du bei einer Strecke an der abschnittsweise die Gleise fehlen, (was recht häufig vorkommt)? Stillgelegt oder entwidment ist meist die komplette Strecke, nicht nur die Abschnitte an denen die Gleise (nicht)entnommen wurden. Da, wo die Gleise vorhanden sind, ist es disused (Wiki-Definition: the feature is still in working order, or could be brought back to working order easily). Auch wenn die Strecke endwidmet ist, kann rein physikalisch ohne größeren Aufwand wieder der Betrieb aufgenommen werden. An den Stellen, an denen keine Gleise vorhanden sind, taggt man es als abandoned (Wiki-Definition: The track has been removed and the line may have been reused or left to decay but is still clearly visible, either from the replacement infrastructure, or purely from a line of trees around an original cutting or embankment.). Sorry, aber mittlerweile hat diese Diskussion keinen wirklichen Sinn mehr. Diskutiere von mir aus mit anderen hier weiter, ich habe wirklich besseres zu tun... Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned
- ein Mapper den Gleiszustand sieht und einfach eintragen kann, Spricht ja nichts dagegen wenn er den Gleiszustand einträgt, aber dafür ist disused/abandoned nicht geeignet. Doch, das Tag ist genau dafür geeignet. - für typische OSM-Nutzer (Wanderer, Radfahrer, Segelflieger) der physikalische relevanter als der rechtliche Status ist +1 Zumindest im Eisenbahnatlas Deutschland (http://www.schweers- wall.de/atlas_deutschland.html), der unter anderem von der Deutschen Bahn und vielen Privatbahnen verwendet wird, unterscheidet man auch neben der aktiven Strecken nur zwischen außer Betrieb und abgebaut bzw. unbefahrbahr. Das zeigt doch, dass selbst für professionelle und geschäftliche Anwender der physikalische Zustand völlig ausreichend ist. Wir erfassen Daten für normale Menschen. Und die interessiert nur der physikalische Zustand. Der rechtliche Status ist höchstens für Katasterämter interessant. Parallel dazu ist doch bei einem Geschäft auch nur interessant, ob es etwas verkauft oder nicht. Ob die Geschäftsräumlichkeiten noch dem Besitzer gehören oder nicht, ist auch nur eine Behörde von Relevanz. Den Rechtsstatus (stillgelegt/entwidmet) kann man, sofern bekannt, in ein Zusatztag stecken. +1 Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap - disused/abandoned
Ich bin anderer Meinung. disused/abandoned sollte nach vorhandenen/ entfernten Gleisen unterscheiden, weil - dies der bisherigen Definition im Wiki entspricht - ein Mapper den Gleiszustand sieht und einfach eintragen kann, den rechtlichen Status aber meist nicht kennt - für typische OSM-Nutzer (Wanderer, Radfahrer, Segelflieger) der physikalische relevanter als der rechtliche Status ist +1 Den Rechtsstatus (stillgelegt/entwidmet) kann man, sofern bekannt, in ein Zusatztag stecken. +1 Der Rechtsstaus dürfte für praktisch keinen Anwender von Bedeutung sein. Und Leute, für die das wichtig ist, würden dafür sowieso nicht OSM benutzen. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Hallo Stefan, Am 07.05.2012 19:33, schrieb Alexander Matheisen: Das Taggingschema habe ich aufgeteilt in das vollständige http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Erweitertes_Tagging sowie eine gekürzte Version für Bahnlaien: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging Schon das vereinfachte Schema ist sehr umfangreich. Ich konnte die Texte bislang nur überfliegen, habe aber trotzdem einige Anmerkungen: - Bitte markiere, welche Tags etabliert sind und welche neue Vorschläge von dir sind OK, werde ich noch ergänzen. - Für alle Flächen, insbesondere die Bahnhöfe/Rangierbahnhöfe, solltest du definieren, was dazu gehört Ist das nicht irgendwie selbstverständlich? (Gut, ich als Bahnexperte kann jetzt wahrscheinlich nicht nachvollziehen, wo da die Unklarheit ist. Du müsstest mir da mal auf die Sprünge helfen). - Ich habe railway=station als Personenbahnhof verstanden. Die Ausweitung auf Güterbahnhöfe finde ich falsch. Dafür ist auch eigentlich railway=yard vorgesehen. Da hatte ich wohl noch eine alte Definition nicht überall angepasst. Ist nun korrigiert. - Die Verbindung verschiedener Gleise sollte auch ohne Zusatztag railway=switch als Weiche ausgewertet werden. Der Sonderfall (Kreuzung ohne Kreuzungsweiche) sollte die Zusatzinformation als Tag oder Abbiegerelation bekommen. Du hast schon recht, allerdings lasse ich das lieber zur Verdeutlichung. An den anderen Tags wue würde sich ja nichts ändern und so wäre eine normale Weiche z.B. mit ref=W1 und railway:manual=yes getaggt. Für nicht-eingeweihte ist dann nicht unbedingt klar, worauf sich die Tags beziehen. Eine statistische Abfrage, wieviele Weichen erfasst sind, ist außerdem einfacher möglich (z.B. in Taginfo). Nebenbei bemerkt: Nach deiner Argumentation könnte man bei Bahnübergängen auch das Tag railway=level_crossing weglassen, denn eine Kreuzung von Straße und GLeis kann nur ein Bahnübergang sein. - bridge_name ist bislang häufiger als bridge:name (siehe taginfo) Das ist mir bewusst, aber man wird zwangsläufig sich auf eine Variante einigen müssen. Wenn meine Karte die erste(?) Anwendung ist, die dieses Tag auswerten würde, dann ließe sich bei dieser Gelegenheit endlich eine Vereinheitlichung durchführen. Übrigens kommt tunnel:name wiederum häufiger vor als tunnel_name. Wenn, dann sollte bei beiden ein einheitliches Schema gewählt werden. Ich bin klar für die Variante tunnel/bridge:name, weil dort deutlicher wird, dass der Name auf das Tag tunnel/bridge bezogen ist (und weil ich sowieso ein Freund von Subkeys bin, siehe meinem Taggingschema). - railway:short ist kein intuitiv verständlicher Name. ref oder railway:ref wären sinnvoller. ref würde ich nicht verwenden, da es bisher oft für andere Dinge wie die ÖPNV- Linien verwendet wurde. railway:ref hört sich aber ganz gut an... - usage=highspeed ist inkompatibel zum etablierten usage=main Die Diskussion hatten wir bereits... Ich bleibe dabei: Eine Hochgeschwindigkeitsstrecke ist etwas anderes als eine normale Hauptstrecke und sollte daher anders getaggt werden. Eine Autobahn taggt man auch nicht highway=primary und highspeed=yes... Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Kannst du das mal mittels eines Beispieltaggigns untermauern? Bü-Tag kann alles und nichts bedeuten. Ich würde darunter verstehen, dass ich das kurze Wegstück als highway=secondary railway=level_crossing ref=A4 maxspeed=50 erfassen würde. Sieht irgendwie etwas komisch aus mit der Mischung aus Straßen- und Bahntags. Genau so meinte ich das. Ich glaube, die Zusammengehörigkeit lässt sich viel einfacher algorithmisch auf Grund der Nähe der Übergänge erfassen. Das ist zwar auf diese Weise möglich, aber auch wieder aufwändig. Außerdem widerspricht es ein wenig der Logik: mehrere Bü-Punkt für einen tatsächlichen Bahnübergang. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Was ist gemeint mit zwischen den Bahngleisen? Ich vermute mal, zwischen den Schnittpunkten der Schienen mit den Straßen, aber logischer wäre m.E., wenn es im Bahnübergangsbereich wäre anstatt zwischen den Schienen. Dann bräuchte man auch nicht zwischen ein- und mehrgleisigen Strecken unterscheiden. Bei unbeschrankten Bahnübergängen muss man sich ggf. eine Definition überlegen, wo der Bahnübergang anfängt, bei solchen mit Schranken würde ich diese als Grenze sehen. Ich meinte zwischen den Schnittpunkten der Schienen (abstrakter), aber man könnte sich auf darauf festlegen, die Trennung an der Position der Schranke, des Andreaskreuzes, der Haltelinie, etc. zu machen (realitätsgetreuer). Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Büs ohne Schranken, haben meist eine Haltelinie. Würde sich auch gut als Start- und Endpunkt eignen. Relationen würde ich nicht wirklich als notwendig erachten. +1 Zwischen den Schranken bzw. Haltelinien an die Straße railway=level_crossing; an die Position des Schranken ein barrier=railway_gate oder an die Haltelinie ein barrier=railway_light oder =railway_stop. Das macht es meiner Meinung wieder ein bisschen kompliziert. Trennt man den Bahnübergangsweg an den Positionen der Schranken oder am Andreaskreuz, dann kann man doch die Schranke standardmäßig an den Endpunkten des Bü-Weges setzen. Außnahme sind natürlich Sonderfälle wie eine Einmündung vor einem Bü, sodass an der einmündenden Straße auch nochmal Andreaskreuze und Warnlichter stehen. Würde man zum Bü-Weg separat nochmal die Schranken erfassen, hätte das den Nachteil, dass man dort auch wieder Voll-/Halbschranke, etc. angeben müsste, die Informationen also doppelt vorliegen. Denn am Bü-Weg müssten sie bleiben, sonst wären Abfragen wie Alle BÜs mit Halbschranken in Deutschland nicht möglich (bzw. mit etwas Schwierigkeiten schon: alle Bü-Wege, auf denen ein Node einer Halbschranke sitzt). Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Büs ohne Schranken, haben meist eine Haltelinie. Würde sich auch gut als Start- und Endpunkt eignen. Relationen würde ich nicht wirklich als notwendig erachten. Eigentlich halte ich den way-Ansatz auch für ausreichend - zumindest, wenn man sich mit einer gewissen Abstraktion abfinden kann. +1 Wenn man es abstrahiert, fallen Halteline und Schranken eh zusammen - wenn nicht, sind wir wieder beim Micro-Mapping - früher oder später wahrscheinlich sowieso. ;-) In den Normalfällen kann man wie bereits gesagt die Schranken und Lichter immer an die Endpunkte der Wege setzen. Bei Sonderfällen wäre das dann nicht exakt realitätsgetreu, aber ich wüsste nicht, wofür außer bei 3D Anwendungen die Positionen der Schranken und Lichter so wichtig ist. Für alle anderen Anwendungen ist die abstrahierte Variante völlig ausreichend. Beim Routing zum Beispiel ist doch nur die Anzahl der BÜs wichtig. Nebenbei bemerkt: Wenn man ein realitätsgetreues 3D-Abbild der Umgebung, ist es glaube ich einfacher, eine Art Streetview aufzusetzen, statt mit Tags jedes kleinste Detail zu beschreiben. Wir wollen bei OSM doch eher abstrahierte Geodaten, die vor allem für Karten (und nicht Pseudo-Luftbilder), für Suchen und fürs Routing verwendet werden sollen. Soweit meine Meinung... an die Position des Schranken ein barrier=railway_gate oder an die Haltelinie ein barrier=railway_light oder =railway_stop. Wenn man es abstrahiert, sind die Tags am crossing-way besser aufgehoben, da sie dann bereits eine Richtung beinhalten. Z. B. gelten nur Vollschranken in absolut beide Richtungen. ;-) Und beim Micro-Mapping weiß ein 3D-Renderer ohne nähere Information oder Ableitung der Gesamtsituation auch nicht weiter, wie herum er das Blinksignal und wo er die einseitige(!) Haltelinie ausrichten soll. +1 Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Es gibt aber auch Situationen wie hier [1], wo die Haltelinie für Autos vor einer Kreuzung liegt, die nicht zum Bahnübergang gehört. Darüberhinaus gibt es auch Bahnübergänge, bei denen sich der Weg zwischen den Schranken verzweigt. Das habe ich gerade letztes Wochenende gesehen, ich glaube es war hier [2]. Wenn das die richtige Stelle ist, dann ist eine Schranke auf jeder Seite der Merkelstraße (das als abandoned eingezeichnete Gleis existiert noch) und eine Schranke bei der Straße Am Bahndamm (wenn das nicht die richtige Stelle ist, dann existiert eine andere Stelle, die diese Topografie hat). Das - und ähnliche Topografien - wird schwierig mit einem Weg darstellbar sein, es sei denn, man definiert, dass keine Schranke gerendert wird, wenn der BÜ-Weg an einem anderen BÜ-Weg aufhört. Hier fände ich aber eine Relation sinnvoller. Ich glaube, ich fände es am sinnvollsten, wenn man beides zulässt - eine Relation mit BÜ-Wegen und Schranken-Knoten oder einzelne BÜ-Wege, die implizite Schranken-Knoten an jedem Ende haben. Wenn man wirklich all diese Sonderfälle abdecken will, dann ist man wieder beim Micromapping. Aber: Für welche Anwendung außer 3D-Rendering ist es denn ernsthaft interessant, wo genau nun die Schranken stehen. Beim 3D-Rendering gibt es meiner Meinung erstmal wichtigere Dinge - bevor man Bahnübergänge bis ins Detail erfasst, sollte man sich eher um eine in Ansätzen realitätsnahe Darstellung von Gebäuden oder mehrspurigen Straßen kümmern. Die beeinflussen das Aussehen einer 3D-Stadtansicht doch mehr als ein einzelner Bahnübergang, bei dem eine Schranke fehlt. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Nachteile: - Oft kreuzen mehrere highways die Gleise (Radweg, Straße, Straße-Gegenrichtung, Radqweg). Dann hätte man nicht ein OSM-Objekt sondern vier Bü-Wege. Die Zählung, wie viele BÜ es auf einer Bahnstrecke gibt, wäre falsch. Stimmt. - Bü-Wege und einfache Kreuzungspunkte lassen sich schlecht in einer universellen Renderregel zusammenfassen. Wieso? Zumindest für Mapnik wüsste ich konkret, wie man das Rendern kann. - Einen BÜ als lineares Objekt anzulegen, finde ich unlogisch Das ist dann eben die Abstraktion... So gesehen ließe sich alles als Fläche erfassen, aber schon bei den Straßen sieht man, dass ein wenig Abstraktion (Wege statt Flächen) hilfreich sein kann. Gegenvorschlag: Bahnübergänge können als Fläche erfasst werden. Die Fläche umfasst in Straßenrichtung den Bereich zwischen den Andreaskreuzen/Schranken, in Gleisrichtung den mit Platten oder Asphalt versehenen Bereich. Die Fläche und die kreuzenden Wege haben gemeinsame Punkte. Hört sich grundsätzlich nicht schlecht an, macht die Erfassung aber auch wieder schwieriger: Bei einem Gleis und einer Straße ein Punkt, bei zwei Gleisen und einer Straße einen Weg, bei zwei Gleisen und zwei Straßen eine Fläche, und was ist dann bei einem Gleis und zwei Straßen? Und wie erkennt dann ein Routingprogramm den Bahnübergang? Dass es ein Problem gibt, wenn mehrere Straßen das Gleis überqueren stimmt, aber von BÜs als Flächen bin ich noch nicht so recht überzeugt. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehrgleisige Bahnübergänge
Meine bisherigen Ideen: Relation oder Bü-Weg. Mit dem Bü-Weg sehe ich das mögliche Problem, dass gegenüber einem Tag an den einzelnen Kreuzugsnodes bei diesem Weg keine leicht nachvollziehbare Kennzeichnung an der Bahnlinie mehr dran ist. Will ich also möglicherweise eine Auswertung machen, wo ich Bahnlinien entlang fahre und ihre Bahnübergänge ansehe, dann kann ich nicht mehr nur auf die Nodes der Bahnlinie selbst schauen, sondern muss die kreuzenden Highways auch mit interpretieren. +1 Dein Einwand ist berechtigt. Es ist damit tatsächlich etwas schwieriger auszuwerten. Allerdings ist das mit ein wenig Aufwand auch möglich. Zuerst würde man alle railway=rail und railway=level_crossing aus den Daten herausfiltern. Dann könnte man bei jedem BÜ-Weg die Tags auf die Nodes vererben, aus denen er besteht. Und schon hat man die BÜs wieder als einzelne - wenn auch doppelte - Punkte auf dem Gleis. Für Anwendungen wie du sie beschreibst ist es ja ohnehin besser, auf jedem Kreuzungspunkt einen BÜ- Punkt zu haben. Ob es solche Auswertungen in der Praxis gibt, ist natürlich eine andere Frage. Noch gibt es solche Auswertungen nicht, aber ich habe durchaus den Plan, so eine Funktion zu meiner OpenRailwayMap irgendwann hinzuzufügen. Meine Vision: Man gibt Start und Ziel oder eine Streckennummer an und die Software generiert einem eine Liste ähnlich der Streckverläufe in Wikipedia: KM 12.3 Köln Hbf KM 14.7 BÜ I - Lindenstraße KM 16.1 Abzw Musterstadt - nach Beispielstadt KM 20.8 Düsseldorf Hbf Wie gesagt aber noch eine Vision... ;) Was natürlich bei einem Bü-Weg einfacher ist, ist die Ermittlung des Namens der kreuzenden Straße. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mehrgleisige Bahnübergänge
Hallo, im Zusammenhang mit dem Taggingschema meiner (geplanten) OpenRailwayMap ist wieder die Frage aufgekommen, wie man mehrgleisige Bahnübergänge sinnvoll erfassen sollte. Meine bisherige und pragmatische Lösung ist einfach ein Bü-Punkt für jede Kreuzungsstelle: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Erweitertes_Tagging#Bahn.C3.BCbergang Problem: Es ist schwierig auszuwerten, ob die einzelnen Bahnübergänge zusammengehören. Man müsste eine Lösung finden, die bei allen möglichen Anwendungsfällen (Rendering, 3D, Routing, Suche) Sinn macht. Meine bisherigen Ideen: Relation oder Bü-Weg. Bei der Relation habe ich noch keine genaueren Vorstellungen (finde ich auch etwas kompliziert), bei der zweiten Variante schwebt mir folgendes vor: Bei eingleisigen BÜs wird wie bisher der Kreuzungspunkt getaggt. Bei z.B. zweigleisigen Strecken bekommt das Wegstück zwischen beiden Gleisen die üblichen Bü-Tags. Vorteil: Der Bahnübergang ist ein Objekt (gut für Suchanwendungen), das Routing könnte solche Wegstücke vermeiden, bei 3D- Anwendungen ließen sich Schranken an den Wegenden rendern und beim normalen 2D-Kartenrendering zeichnet man das Bü-Symbol an die Mitte des Weges (also zwischen beide Gleise). Außerdem lässt sich ermitteln, mit wievielen Gleisen sich der Bü schneidet. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Hallo, Das Thema _Bahnübergänge_ wurde im Forum früher schon diskutiert. Dein Vorschlag enthält trotz der damaligen Anmerkungen nur ein Taggingkonzept für die Kreuzungsknoten und keinen Ansatz zum Zusammenfassen mehrerer Knoten - etwa über ein entsprechendes Markieren der dazwischenliegenden Wegstücke oder über eine Relation. Da aber speziell Schranken als Attribut an den Knoten stehen, lassen sie sich dann nicht so rendern, dass pro Bahnübergang nur ein Schrankenpaar erscheint. Dazu habe ich tatsächlich bisher keine Lösung gefunden. Steht daher auch unter den Todos (http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap#Bugs_.2F_Zuk.C3.BCnftige_Entwicklungen_.2F_Ideen_.2F_TODOs). Bei Bahnübergängen müsste man zusammen mit Experten für Routing und eventuell 3D eine Lösung finden, die für alle Anwendungstypen sinnvoll ist. Habe gleich mal einen neuen Thread dazu geöffnet. Dein Vorschlag zu _disused und abandoned_ schlägt vor, ein Präfix für den Wert zu verwenden, also z.B. railway=disused_signal. Auf der Wikiseite zum Schlüssel disused dokumentiert ist aber die Verwendung als Präfix für den Schlüssel - für dieses Beispiel wäre das disused:railway=signal. Was spricht aus deiner Sicht für die von dir gewählte Variante? Das kannte ich noch gar nicht, Danke für den Hinweis. Werde es bei Gelegenheit ändern. Und zuletzt: Die Tags für _Signale_ nehmen Bezug auf die Wegrichtung. Es ist also vorgesehen, dass ein solcher Knoten nur dann an der Grenze zweier Ways verwendet werden darf, wenn diese eine zusammenpassende Wegrichtung haben, richtig? Stimmt, den Fall hatte ich bisher gar nicht bedacht. Dann werde ich diesen Sonderfall mit einem Hinweis auf der Wikiseite vermerken. Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggingschema OpenRailwayMap
Hallo, Warum die Beschränkung auf: Berücksichtigt werden nur vollwertige Eisenbahnen, die Teil des internationalen Eisenbahnnetzes sind. Nicht berücksichtigt werden Straßenbahnen, Seilbahnen, Standseilbahnen, Miniaturbahnen und U-Bahnen. ? Kennst Du beispielsweise das Karlsruher Schienennetz? Da sind die Übergänge zwischen Strassenbahnen und vollwertigen Eisenbahnen sehr fliessend. Und wenn Du Dir die Schweiz anschaust - wo setzt Du da die Grenze bei den vielen Schmalspurbahnen die teils auch ehr Strassenbahn, teils aber auch ehr vollwertige Eisenbahn sind. Und oftmals sind es doch gerade die kleinen Bahnen die besonderes Interesse hervorrufen. Eigentlich wollte ich wirklich nur eine Karte für die richtige Eisenbahn. Wie du aber schon sagtest ist es etwa beim Beispiel Karlsruhe schwierig, da einen Schnitt zu machen. Straßen- und U-Bahnen würde ich daher noch mit aufnehmen. Bei Seilbahnen, Standseilbahnen und Miniaturbahnen bin ich mit aber recht unschlüssig. Seilbahnen fallen für mich definitiv raus, die haben nichts mehr mit Eisenbahn zu tun. Bei Standseilbahnen bin ich ein wenig unsicher, da sie eine Mischung aus Eisenbahn und Seilbahn sind. Da sie aber nicht an das reguläre große Bahnnetz angeschlossen sind, fallen sie für mich hinaus. Und Miniaturbahnen sind meiner Meinung einfach nur größere Modellbahnen. Ich wäre daher für die Formulierung Alle schienen-/seilgebundenen Personen- und Güter befördernde Bahnen, also alles ab der personenbefördernden Parkbahn aufwärts. Ich würde folgende Definition vorschlagen: Alle schienengebundenen und aus eigener Kraft fahrenden Verkehrsmittel, also Eisenbahnen, Stadtbahnen, U- Bahnen und Straßenbahnen. Seilbahnen sind nicht schienengebunden und haben keinen Eigenantrieb, Standseilbahnen sind zwar schienengebunden, haben aber auch keinen Eigenantrieb. Bei Miniaturbahnen greift die Definition übrigens nicht... Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Taggingschema OpenRailwayMap
Hallo, bereits seit längerem arbeite ich an dem Plan, eine Spezialkarte zum Thema Eisenbahn unter dem Namen OpenRailwayMap zu schaffen: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap Nun habe ich das Taggingschema nach meiner Meinung soweit fertig und würde gerne andere fragen, wie sie es finden und was verbessert werden könnte: Das Taggingschema habe ich aufgeteilt in das vollständige http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Erweitertes_Tagging sowie eine gekürzte Version für Bahnlaien: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Vereinfachtes_Tagging Alles genau hier zu erklären, wäre wahrscheinlich ein bisschen zu umfangreich. Schaut es euch einfach an und bei Verständnisfragen oder Fragen wie Warum soll etwas auf diese Weise getaggt/erfasst werden? kann ich euch einzelne Dinge genauer erläutern. Sollten hier vorerst keine weiteren Ergänzungswünsche oder Kritikpunkte auftreten, werde ich mir die Arbeit machen, die Seiten ins Englische zu übersetzen und als Proposal einzutragen. Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unter Denkmalschutz stehen de Gebäude
Am Samstag, 28. April 2012, 18:03:38 schrieb Steffen Heinz: Jeder Ort hat ja dutzende / Hunderte von unter Schutz stehenden Gebäuden usw. sollen die, können die vermerkt werden? Beispiel: http://de.wikipedia.org/wiki/Liste_der_Baudenkm%C3%A4ler_in_Simmerath macht das überhaupt Sinn? Ich habe vereinzelt schon Gebäude mit dem NRW-Wappen und Denkmal oder der blau-weißen Raute ganz pragmatisch mit heritage=yes getaggt. Muss nicht korrekt sein, aber man kann es später immer noch ändern. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Am Samstag, 28. April 2012, 18:58:09 schrieb Falk Zscheile: Am 28. April 2012 15:45 schrieb Peter Wendorff wendo...@uni-paderborn.de: Für OSM haben wir das häufiger diskutiert, und hängen da quasi an einem blöden Problem: Geographische Regionen haben oft nicht fest definierte Grenzen. Wo hören die Alpen auf? Wo die norddeutsche Tiefebene? Es gibt eindeutige Grenzen (z.B. bis zum Rhein), aber meist sind die Grenzen nicht eindeutig, und das lässt sich nur sehr schwer (wenn überhaupt) abbilden. Wenn Du da allerdings 'ne gute Idee haben solltest... interessieren würde mich das Thema durchaus. Da wurde etwas für API 0.7 zu Diskussion gestellt, aber nicht weiter erläutert und für mich bisher auch nicht überzeugend: http://wiki.openstreetmap.org/wiki/API_v0.7#Geografic_regions Wozu braucht man dafür eine neue API-Version? Ließe sich doch auch mit der bisherigen Software eintragen. Vielleuicht mit Relationen, die die Hierarchien nachbilden und Mulipolygonen oder Wegen, die die Bereiche grob markieren. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geografische Regionen innerhalb der Datenbank?
Geographische Regionen haben keine scharfen Ränder, sondern ziemlich schwammige Grenzen, und so etwas lässt sich momentan tatsächlich nicht abbilden. Das kann man ja beim Auswerten berücksichtigen. Etwa eine Ungenauigkeit von +/- 20km bei Mittelgebirgen vielleicht... Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erfassung Ortshistorischer Objekte
Für solche historischen Daten ist es schwierig, sie in die jetzige OSM Datenbank einzutragen. Wie willst du zum Beispiel eine Kneipe eintragen, die in den vergangenen 30 Jahren mehrmals Besitzer und Küche gewechselt hat? Ich habe da folgende Vorstellung: Man müsste eine Art Zeitachse einfügen. In JOSM ließe sich dann die Zeit über einen Regler einstellen, für die man editieren will. Das kollidiert dann nicht mit den heutigen Daten und ein Problem wie oben beschrieben hat man auch nicht, weil man auf einer Zeitachse die Gültigkeit des Objekts einstellen könnte. Der Editor müsste diese Zeitdaten bei jedem Objekt mitspeichern. Vielleicht ginge das alles jetzt schon mit einem Plugin: Mit start_date und end_date gibt man den Zeitrahmen eines Objekts an. Das Plugin würde dafür sorgen, dass der Editor nur Objekte anzeigt, die in einem vom User eingestellten Zeitintervall oder einem Zeitpunkt existent sind. Damit ließen sich z.B. auch abgerissene Gebäude eintragen, ohne, dass sie wie zur Zeit beim Editieren stören. Und Renderer, die nicht historische Daten auswerten, müssten Objekte nur rendern, wenn sie kein end_date besitzen. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Ich beschäftige mich schon seit einiger Zeit mit einem Taggingschema für Eisenbahnen: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap Die Seite hatte ich bei der Suche im Wiki nicht entdeckt. Du hast dort einige Erweiterungen vorgeschlagen, die nicht mit den Wiki-Definitionen kompatibel sind (usage=highspeed). Wieso nicht kompatibel? Es werden ja nur zusätzliche Values für usage=* definiert, die sich nicht mit den im Wiki vorgeschlagenen Werten in die Quere kommen. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am Montag, 20. Februar 2012, 14:11:41 schrieb Martin Koppenhoefer: Am 20. Februar 2012 13:42 schrieb Alexander Matheisen alexandermathei...@ish.de: Du hast dort einige Erweiterungen vorgeschlagen, die nicht mit den Wiki-Definitionen kompatibel sind (usage=highspeed). Wieso nicht kompatibel? Es werden ja nur zusätzliche Values für usage=* definiert, die sich nicht mit den im Wiki vorgeschlagenen Werten in die Quere kommen. Doch, das kommt sich potentiell mit den anderen Werten in die Quere. Warum nicht highspeed=yes (oder ggf. detaillierter bis zu welcher Geschwindigkeit, etc.)? Ist das nicht unnötig kompliziert? Schließlich taggt man eine Autobahn ja auch nicht als highway=trunk und highspeed=yes... Nach meiner Definition überschneiden sich main und highspeed nicht: main sind normale Hauptstrecken und highspeed bezeichnet Strecken wie die SFS Köln- Frankfurt (nur Hochgeschwindigkeitsverkehr, frei von Bahnübergängen, etc.) Siehe http://de.wikipedia.org/wiki/Schnellfahrstrecke wobei ich in der Regel Ausbaustrecken wie die Schnellfahrstrecke Köln-Aachen noch zu main zählen würde (auch andere Zuggattungen, mehr Bahnhöfe entlang der Strecke. Dann muss die bisherige Definition von main eben geändert werden. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenRailwayMap (war: Welche Tags für Bahngleise)
Am Montag, 20. Februar 2012, 15:02:51 schrieb Stephan Wolff: Am 20.02.2012 13:42, schrieb Alexander Matheisen: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap Du hast dort einige Erweiterungen vorgeschlagen, die nicht mit den Wiki-Definitionen kompatibel sind (usage=highspeed). Wieso nicht kompatibel? Es werden ja nur zusätzliche Values für usage=* definiert, die sich nicht mit den im Wiki vorgeschlagenen Werten in die Quere kommen. Hochgeschwindigkeitsstrecken sollten laut Wiki als usage=main getaggt werden, nach deinem Vorschlag als usage=highspeed. Wer eine Karte nur mit den Hauptstrecken erstellen will und usage=main filtert, sieht dann die Strecken mit usage=highspeed nicht. Man könnte ja in diesem Fall alle usage=main und usage=highspeed anzeigen. Trägt man dagegen auch alle Hochgeschwindigkeitsstrecken als usage=main ein, dann kann man keine Karte für solche Linien erstellen. Besser ein differenziertes Tagging, das man beim Auswerten wieder etwas zusammenfassen kann, als umgekehrt. usage=main mit highspeed=yes wäre eine kompatible Erweiterung. Aber ich will dieses Detail nicht als entscheidenden Kritikpunkt bewerten. Hochgeschwindigkeitslinien, die schon als usage=main getaggt sind, müsste man bei beiden Varianten umtaggen. Die Wikiseite ist sehr lang und enthält viele Vorschläge. Viele werden wohl spätestens ab railway:signal:main:substitute_signal nicht mehr weiterlesen, obwohl 100 Zeilen danach noch allgemein interessante und für Eisenbahnlaien erfassbare Objekte (Bahnhof, Stellwerk, Bahnübergang, Betriebsbahnhof und Containerumschlagbahnhof) beschrieben werden. Alexander, vielleicht könntest du den Text aufteilen in einen allgemeinen Teil für Eisenbahnlaien einen Spezialteil für Pufferküsser und Simulanten. OK, ich habe es etwas aufgeteilt. Das vereinfachte Schema lässt sich aber vielleicht noch weiter vereinfachen. Das Problem ist, dass das Tagging möglichst allgemein gehalten ist (vor allem das Tagging der Signale), um es international anwendbar zu machen. Damit wird es dann eben sehr komplex, aber je nach Land ergeben sich dann wieder einige Tags von selbst, sodass das Tagging dann nicht mehr so kompliziert ist. Zur Zeit erstelle ich daher JOSM-Vorlagen (getrennt für verschiedene Länder), damit das Tagging vereinfacht wird. Ich finde das Signalschema mit einer Relation pro Signal sehr kompliziert. Wäre es nicht ausreichend, einen Punkt auf dem Gleis zu setzen und den Standort (right/left/above) und Richtung in jeweils einem Zusatztag unterzubringen? Werde mal drüber nachdenken... ;) Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Nach meiner Definition überschneiden sich main und highspeed nicht: main sind normale Hauptstrecken und highspeed bezeichnet Strecken wie die SFS Köln- Frankfurt (nur Hochgeschwindigkeitsverkehr, frei von Bahnübergängen, etc.) siehst Du, Du definierst main um: das sind plötzlich nur noch normale Hauptstrecken, den Hochgeschwindigkeitsverkehr schmeisst Du raus. M.E. wäre es sowieso nicht schlecht, man könnte bei highspeed noch näher dazuschreiben, welcher Ausbau (wenn man will), d.h. auch aus diesem Grund wäre ein eigener Key besser. Dann muss die bisherige Definition von main eben geändert werden. eben, müsste. Definitionsänderungen sollten aber nicht passieren, indem jeder nach Lust und Gutdünken im Wiki rumändert, ohne sich mit den anderen abzustimmen. 1. Ich ändere nichts an der Definition, denn dort ist nur von höherer Geschwindigkeit (im Vergleich zu branch) die Rede. 2. Wenn bisherige Definitionen verbesserungswürdig sind (zum Beispiel der damalige Ersteller nicht alle Fälle bedacht hat), dann sollte man sie korrigieren und erweitern. 3. Ich ändere nichts im Wiki, sondern habe nur einen Taggingvorschlag für eine geplante Anwendung entworfen. 4. Bezüglich abstimmen: Manchmal kommt man nur weiter, wenn man ganz pragmatisch einfach etwas macht statt zu warten, bis sich irgendwann alle geeinigt haben. Spätestens wenn eine coole Anwendung ihre eigenen Tags benutzt gilt doch wieder das Prinzip wir mappen für die Renderer. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Hallo, wie viele andere Dinge sind auch Bahngleise in OSM recht unterschiedlich erfasst. Welche der folgenden Tags sind in Deutschland für Bahngleise mit railway=rail sinnvoll? - gauge=1435: brauchen wir den Standardwert in Deutschland? Ich denke, das Tag kann man weglassen, außer natürlich bei Schmalspurbahnen oder anderen abweichenden Strecken. - operator: wird manchmal für den Betreiber des Personenverkehrs genutzt (m.E. falsch), manchmal für den Betreiber des Gleises. Dabei gibt es noch unterschiedliche Schreibweisen (DB, DB-Netz,...) Ist für Ferngleise operator=Deutsche Bahn Netz AG sinnvoll? Für Industriegleise ist der Betreiber oft nicht erkennbar. Ich gebe es bisher nur bei Industrie- oder Privatbahnen an. Sonst ist ja wie bei gauge=* ein Standardwert vorhanden. - network=XYZ: ist das eine Eigenschaft des Gleises oder gehört das Tag an die Relation route=train? Kommt eher an die Relation. - lines=XY;YZ: steckt die Information nicht schon in den Relationen? Ja. - oneway: ist oneway=yes sinnvoll, wenn jedes Gleis einer zweigleisigen Strecke nur Signale für eine Fahrtrichtung hat? Ist nicht selbst in diesem Fall z.B: bei Bauarbeiten auf dem anderen Gleis das Befahren des Gegengleises möglich? - ref: was bedeutet ref bei Bahngleisen? Ist es die Gleisnummer in Bahnhöfen oder gibt es dafür ein anderes Tag? Bei Strecken nehme ich die vierstellige Streckennummer. An Bahnhofsgleisen das Gleis, wobei dann ein Konflikt mit der Streckennummer entsteht. Für den Fall muss ich mir auch noch etwas einfallen lassen. - usage: gibt usage die offizielle Einteilung in Haupt- und Nebenbahnstrecken an oder die aktuelle Verkehrsbedeutung? Beispiel: die Bahnstrecke Neumünster–Bad Oldesloe ist laut Wikipedia Hauptbahn, wird aber nur stündlich mit Triebwagen befahren. Da sollte man sich meiner Meinung nicht an länderbezogene Einteilungen halten, sondern das nach eigenem Gefühl machen, wie wir das auch schon mit primary/secondary/tertiary-Straßen machen. Bei deinem Fall würde ich die Strecke als Nebenbahn taggen. Fast alle Bahnhöfe haben mehrere getrennt erfasste Gleise. Sollte ein Punkt eines beliebigen Gleises als railway=station erfasst sein oder jeder way einen Punkt mit public_transport=stop_position, train=yes haben? Darauf habe ich auch noch keine Antwort gefunden. Ich beschäftige mich schon seit einiger Zeit mit einem Taggingschema für Eisenbahnen: http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap Grüße Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Stelle?! Läßt BING Militärgebiete zensieren!
Hallo, so viel also zum Thema Open Data... Für alle diejenigen von euch die wie ich das Forum seltener lesen möchte ich dann doch die Diskussion auch mal hierher bringen. Die Diskussion ist hier schon längst angekommen... Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Stelle?! Läßt BING Militärgebiete zensieren!
Huch hab ich einen thread übersehen? Scheinbar. Thread siehe hier: http://lists.openstreetmap.org/pipermail/talk-de/2012-January/092407.html Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
Am Montag, 30. Januar 2012, 18:23:32 schrieb Simon Poole: Und weiter [18:22] SteveC I can confirm that the blurring polygons were given to us by the government and we didn't use OSM or anything like that. Am 30.01.2012 17:54, schrieb Simon Poole: 17:52] *** SteveC has joined #osm-de [17:52] SteveC Hello osm.de [17:52] SteveC I have asked our imagery people about the blurring [17:52] SteveC And I can pass back that we were asked to do it by a branch of the German government Ich will ja keine Verschwörungstheorien aufstellen, aber ein bisschen beunruhigt mich das schon. Wenn man davon ausgeht, dass das alles so stimmt wie Steve hier schreibt, dann frage ich mich, ob es eine konkrete Bedrohung für Deutschland gibt, weshalb man ausgerechnet jetzt aus dem Nichts heraus die Luftbilder zensieren lässt. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
Ich will ja keine Verschwörungstheorien aufstellen, aber ein bisschen beunruhigt mich das schon. Wenn man davon ausgeht, dass das alles so stimmt wie Steve hier schreibt, dann frage ich mich, ob es eine konkrete Bedrohung für Deutschland gibt, weshalb man ausgerechnet jetzt aus dem Nichts heraus die Luftbilder zensieren lässt. Ach, wahrscheinlich sucht so eine Planstelle nur nach einer Existenzberechtigung. Bei einer echten Bedrohung würde man wohl auch die unzensierten WMS der Landesvermessungsämter abschalten. Das ist natürlich ein Argument... Außerdem wirkt die Verschleierung bei Licht betrachtet doch eher wie eine Markierung aller relevanten militärischen Ziele. Wo die Einrichtungen liegen, weiß sowieso jeder. Aber ohne Verschleierung könnte man gezielt ein bestimmtes Gebäude angreifen, daher ist eine Verschleierung nicht ganz unnütz. (Niederländische Militäreinrichtungen sind in Google Maps auch mit einem auffälligen Muster zensiert) Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlach 2 - kein bing-Hintergrund-Bild mehr bei Militaerflaechen
ich habe mal eine Analyse für Nordrhein-Westalen durchgeführt: * Nutzung der aktuellen Datei für NRW von der geofabrik. * Filtern mittels osmosis nach Wegen mit landuse=military. * Laden dieser Datei in JOSM. * Visueller Vergleich aller diese Gebiete mit dem Bing-Hintergrund. * Tagging der Gebiete mit blurred_by_bing=no|partly|exactly. * Lokal gesichert, aber nicht hochgeladen. * Zählung der Gebiete mittels grep. Ergebnis: Gebiete in NRW mit way landuse=military: 156. Davon sind 2 teilweise verpixelt, 89 exakt mit OSM-Konturen verpixelt und 60 Gebiete sind nicht verpixelt. 5 Gebiete sind mir wohl bei der visuellen Kontrolle durchgerutscht. Beobachtung: Es gibt noch einige andere verpixelte Gebiete in NRW. (Vielleicht als Relationen?) Es wurden auch Übungsgebiete von Bereitschaftspolizei, Technischem Hilfswerk und Deutschem Rotem Kreuz verpixelt. Fragen: Stellen die noch unverpixelt dargestellten 60 Militärgebiete in NRW ein Problem für unsere Landesverteidigung dar? Welche Behörden können wir darüber verständigen? Wieviele der unverpixelten Gebiete gehören denn zur Bundeswehr? Ich habe bisher festgestellt, dass Gelände anderer Streitkräfte nicht zensiert sind, z.B. Flugplätze der US-Armee. Gibt es überhaupt zensierte nicht- deutsche Einrichtungen? Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die neuen Google Luftbilder
habe ich gerade in Google Earth gesehen. Als ich zuerst nur den Betreff gelesen hatte, dachte ich, dass die jetzt auch schon wie Bing auf zensierte Bilder aktualisiert haben... Bin ich ja beruhigt, dass es nicht so ist, sonst wäre es beunruhigend. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Themen-Karte: Grenz- und Meilensteine
Hallo, boundary = marker oder marker = stone - was das Haupttag ? marker=* scheint nur dazu dienen, die Art des Grenzpunktes zu spezifizieren (Stein, Felsen, Pfahl, ...). http://taginfo.openstreetmap.org/keys/marker#values Von daher würde ich boundary=marker auswerten, auch wenn es Grenzpfähle statt Grenzsteinen sein könnten. Die Unterscheidung kannst du ja noch später einbauen. Thematisch würde es ganz gut passen, dann natürlich mit einem anderen Symbol zur Unterscheidung. Einen Vorschlag Wie ist http://rurseekatze.bplaced.net/grenzstein.png ? (man sieht wahrscheinlich, dass ich wenig künstlerische Begabung besitze... ;) Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einbinden von Image-Tags aus Wikimedia
Hallo, es gibt ja ein Tag im IMAGES einzubinden und wikimedia bietet sich bei historischen Dingen insbesondere an. In diesem Zusammenhang ist mir folgendes aufgefallen. Die Seite mit dem Bild hat zum Beispiel die URL: http://commons.wikimedia.org/wiki/File:Meilenstein_Chaussee_Altona-L%C3%BCbe ck_-_Altona_5M_%28Bargfeld-Stegen%29_02.jpg?uselang=de Geht man auf der rechten Seite auf den Punkt - Einbinden, dann wird für das Bild die URL: http://upload.wikimedia.org/wikipedia/commons/5/5d/Meilenstein_Chaussee_Alto na-L%C3%BCbeck_-_Altona_5M_%28Bargfeld-Stegen%29_02.jpg angeboten. Da ich nun überlege diese Bilder automatisch in einer Karte darzustellen wäre es sinnvoll den richtigen Bildnamen auch anzusetzen. Wie macht Ihr das oder liege ich mit meinem Gedanken gar falsch ? Beim Image-Tag habe ich im Wiki [1] keinen entsprechenden Hinweis gefunden. [1] http://wiki.openstreetmap.org/wiki/Image In meiner OpenLinkMap werte ich dieses Tag bereits aus. Beispiel: http://www.openlinkmap.org/?lat=51.1990129lon=6.6932413zoom=17id=28562993type=way Und dann auf Mehr Infos klicken. Ich werte nur die zweite Variante aus - die direkte URL - da ich so direkt das Bild einbinden kann. Bei der ersten Variante müsste ich erst noch die Bild-URL aus der HTML-Seite herausfiltern. Bezüglich Lizenzhinweis hatte ich das Problem, dass man den Autor und die Lizenz nicht per API abfragen kann. Daher habe ich das mit diesem Link unter dem Bild gelöst, der auf die Bildseite (die erste URL) verweist. Ob das rechtlich reicht, weiß ich nicht. Meiner Meinung sollte sich aber seitens Wikimedia keiner beschweren, dass der Lizenzhinweis nicht ausreicht, wenn die es nicht hinkriegen, diese Daten maschinenlesbar bereitzustellen. Außerdem prüfe ich noch, ob das Bild von Wikimedia stammt. Bilder von anderen Webseiten zeige ich (um rechtliche Probleme zu vermeiden) gar nicht an. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Themen-Karte: Grenz- und Meilensteine
Am Freitag, 6. Januar 2012, 15:11:31 schrieb Jan Tappenbeck: Am 06.01.2012 13:55, schrieb Alexander Matheisen: Hallo, boundary = marker oder marker = stone - was das Haupttag ? marker=* scheint nur dazu dienen, die Art des Grenzpunktes zu spezifizieren (Stein, Felsen, Pfahl, ...). http://taginfo.openstreetmap.org/keys/marker#values Von daher würde ich boundary=marker auswerten, auch wenn es Grenzpfähle statt Grenzsteinen sein könnten. Die Unterscheidung kannst du ja noch später einbauen. Thematisch würde es ganz gut passen, dann natürlich mit einem anderen Symbol zur Unterscheidung. Einen Vorschlag Wie ist http://rurseekatze.bplaced.net/grenzstein.png ? (man sieht wahrscheinlich, dass ich wenig künstlerische Begabung besitze... ;) Alex eingespielt ! Danke, sieht gut aus. Um Aachen sind schon viele Grenzsteine erfasst: http://www.tappenbeck.net/osm/maps/deu/index.php?id=1044zoom=12lat=50.67221lon=6.15871layers=BFTlang=de Man sollte vor allem die Mapper in Grenzregionen dazu motivieren, die Steine zu erfassen. Das macht nämlich Spaß und hat was von Geocaching... ;) Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Themen-Karte: Grenz- und Meilensteine
Hallo, ich habe einmal wieder gebastelt - eine Sonderkarte zu dem Thema Grenz- und Meilensteine. Für Ideen und Anregungen bin ich immer offen. Weitere Thematische Karten von mir finden sich unter http://wiki.openstreetmap.org/wiki/User:L%C3%BCbeck#Meine_Karten. Könntest du auch normale (nicht historische) Grenzsteine anzeigen? Habe schon einige eingetragen, leider werden die in keiner Karte angezeigt. http://www.openstreetmap.org/browse/node/324100655 Thematisch würde es ganz gut passen, dann natürlich mit einem anderen Symbol zur Unterscheidung. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenGeoDB eingestellt
Am Montag, 2. Januar 2012, 21:24:27 schrieb Stefan Keller: Lieber Sven, liebe Mapper Wie schon an anderer Stelle erwähnt, würde es meiner Erfahrung nach der OSM Datenbank sehr gut tun, wenn man die OpenGeoDB Tags löschen würde. Wenn's gut gemacht ist, wieso auch nicht automatisch? Bisher hatte ich mich davor gescheut. Aber wenn nun auch Sven mit Löschen einverstanden ist - wenn ich ihn richtig verstehe -, steht dem nichts mehr im Wege. Dabei habe ich nichts gegen OpenGeoDB (im Gegenteil) und auch nichts gegen solche Imports (wenn sie gut laufen :-). Die OpenGeoDB-tags jedenfalls haben bis auf wenige ihren Dienst getan und sind nun nur noch Ballast für die tag-Liste pro Node. Zu den Löschkandidaten gehören m.E. u.a. folgende: opengeodb:lat, opengeodb:lon, openGeoDB:name, openGeoDB:type,openGeoDB:is_in, openGeoDB:layer, openGeoDB:version, openGeoDB:sort_name, openGeoDB:auto_update, openGeoDB:is_in_loc_id, openGeoDB:postal_codes, openGeoDB:community_identification_number Was man behalten könnte ist: openGeoDB:loc_id population = value aus openGeoDB:population=value, falls tag population nicht schon vorhanden source:population=OpenGeoDB oder - etwas vorsichtiger: openGeoDB:loc_id openGeoDB:population Ich würde es so machen: openGeoDB:community_identification_number (Gemeindeschlüssel) = de:amtlicher_gemeindeschluessel openGeoDB:population = population openGeoDB:telephone_area_code (Telefonvorwahl) = telephone_area_code openGeoDB:license_plate_code (Autokennzeichen) = license_plate_code restliche openGeoDB-Tags löschen 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
Die Eisenbahninfrastruktur ist aber auch für die vielen Eisenbahnunternehmen oder Bahnmuseen interessant, auch wenn die vielleicht jetzt noch nicht unsere Karten nutzen. Genau deswegen sehe ich hier Handlungsbedarf und einen Grund diese Informationen einzutragen. Meine Frage ist nun: Kann ich Daten aus Führerstandsmitfahrten wie man sie z.B. auf Youtube findet, Nutzen und eintragen? Prinzipiell wird es doch sicherlich schwierig Streckendetails zu erfassen, da die wenigsten von uns im Führerstand sitzen ;-) Mich würde die praktische Erfassung der Daten daher sehr interessieren. Entweder man geht zu Fuß, etc. an die Gleise ran (wirklich nur soweit es erlaubt ist). Bei mir am Niederrhein sind die Gleise vor allem außerhalb der Bebauung leicht zugänglich, oft führen Feldwege parallel zum Gleis. Innerhalb von Bahnhöfen kann man natürlich auch von den Bahnsteigen aus alles fotografieren. Bei Videos auf Youtube würde ich immer den jeweiligen Ersteller fragen. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
