[Talk-de] Einführung eines neuen Tags (globaleID)
Sehr geehrte OSM-Gemeinde, wir die Firma Mentz Datebverarbeitung GmbH mit dem Sitz in München ( http://www.mentzdv.de/), arbeiten gerade daran die Bahnhöfe in Bayern, NRW und Baden-Würtenberg zu überarbeiten mit dem Ziel einer vollständigen und einheitlichen Darstellung. Die Modellierung soll Routing und Navigation innerhalb des Bahnhofs bis zum Fahrzeug erlauben und dabei speziell auch wo möglich die Berechnung barrierefreier Routen ermöglichen. Wir arbeiten im Auftrag der jeweiligen Verbünde und Länder, Die Ergebnisse sollen in den einzelnen Fahrplanauskunftssystem im Internet (Bayernfahrplan, EFA-Baden-Württemberg, VRR) und in den jeweiligen Apps sichtbar werden. Wir erwarten mit der Bearbeitung in OSM eine wesentliche Verbesserung der geographischen Grundlage. Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag soll globale_id_pt = * (IFOPT Nummer) heißen. Dieser neue Tag ist die eindeutige Nummerierung der Objekte einer Haltestelle nötig. Diese Nummerierung der Haltestelle wird basierend auf dem CEN Standard CEN TC278 SG6 IFOPT (Identification of Fixed Objects in Public Transport) durchgeführt. Dieser Standard sieht für Deutschland folgende Codierung vor: Für die Plattformen in OSM: de:Landkreisnr:lokale Haltstellennummer:PlattformNr Für die Stop_Position in OSM: de:Landkreisnr:lokale Haltstellennummer:PlattformNr:SteigCode Für die Eingänge der Bahnhöfe: de:Landkreisnr:lokale Haltstellennummer:EingangNr Die Landkreisnummer kommt aus dem Amtlichen Gemeindeschlüssel. Die lokale Nummer vergibt der örtlich verantwortliche Verkehrsverbund oder der Landkreis bei Landkreisen ohne Verbund. Wir benötigen diese Nummer für 3-Objekte aus OSM, für die Plattformen (Bahnsteige), für die Stop_position auf den Gleisen und für die Zugänge/ Eingänge zu den Bahnhöfen. Es existieren bereits solche Nummern aus den Haltestellenkatastern der jeweiligen Länder, die wir und unsere Kunden in OSM durch einen neuen Tag einpflegen würden. Diese Nummer sollte nicht bearbeitet werden, da unsere Kunden diese benötigen um mit den OSM-Daten weiterarbeiten zu können. Wir würden uns sehr über die Mithilfe der OSM-Gemeinde bei der Umsetzung des Projektes freuen. Viele Grüße Taoxue (Tracy) i.A. Mentz Darenverarbeitung GmbH ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 06.07.2013 19:59, schrieb jotpe: Am 6. Juli 2013 15:00 schrieb Martin Koppenhoefer dieterdre...@gmail.com: +1, wobei man klären sollte, wie das in den Originaldaten gemacht wird (z.B. eine ehem. Lagerhalle, die jetzt bewohnt wird, taucht die als Lagerhalle oder Wohngebäude auf?). Oder eine Kirche, entweiht und jetzt als Theater genutzt, ist das in deren Daten eine Kirche oder wie ist die enthalten? Die Daten spiegeln den letzten amtlichen Stand wieder. Etwas anderes weiß die Stadt nicht. Zunächst sollten wir davon ausgehen, dass die Daten stimmen. Ich denke schon, dass wir das auch überprüfen sollten. Und wenn es nur ein Blick auf das Luftbild ist um zu schauen, ob da wirklich ein(e) Haus/Kirche/Lagerhalle ist. Wenn wir uns Fehler mit importieren, sind wir letzlich nicht viel mehr als ein Sammelbecken, in da jeder seine Geodaten rein kippt. Wenn die Daten frei sind und wir sie nicht manuell kontrollieren können/wollen, dann sehe ich keinen Sinn darin, sie in OSM reinzukippen. Jeder der die Daten nutzen möchte könnte sie dann genauso gut direkt von der Stadt nehmen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Tracy Kasperczyk schrieb: Die Modellierung soll Routing und Navigation innerhalb des Bahnhofs bis zum Fahrzeug erlauben und dabei speziell auch wo möglich die Berechnung barrierefreier Routen ermöglichen. Ist das ein Projekt, aus dem die Community ganz im Sinne von Open Data einen Nutzen ziehen kann, oder ist das eine interne Geschichte, auf die ein Normalbürger nicht ohne weiteres Zugriff bekommen kann? … und wäre es für so eine Spezialanwendung nicht sinnvoller, das intern zu machen, mit den OSM-Daten zusammenzuführen, und dann auszuliefern, ohne unzählige Spezialtags in die OSM-Daten zu bringen, die jeder jederzeit ändern kann (was laut der Projektbeschreibung nicht so gut wäre)? Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-07-07T09:59:26+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Tracy Kasperczyk kasperc...@mentzdv.de wrote: wir die Firma Mentz Datebverarbeitung GmbH mit dem Sitz in München ( http://www.mentzdv.de/), arbeiten gerade daran die Bahnhöfe in Bayern, NRW und Baden-Würtenberg zu überarbeiten mit dem Ziel einer vollständigen und einheitlichen Darstellung. Die Modellierung soll Routing und Navigation innerhalb des Bahnhofs bis zum Fahrzeug erlauben und dabei speziell auch wo möglich die Berechnung barrierefreier Routen ermöglichen. Nur vom Bahnsteiggleis zum Fahrzeug? Nicht zum örtlichen Nahverkehr und innerhalb dessen? Wir arbeiten im Auftrag der jeweiligen Verbünde und Länder, Die Ergebnisse sollen in den einzelnen Fahrplanauskunftssystem im Internet (Bayernfahrplan, EFA-Baden-Württemberg, VRR) und in den jeweiligen Apps sichtbar werden. Für den VRR Verkehrsverbund (Großraum Ruhrgebiet-Düsseldorf) finde ich diese Annäherung an OSM doch nun erstaunlich. Der hat sich meines Wissens in der Vergangenheit bei den Anfragen diverser OSMler vollkommen taub bis einsilbig ablehnend gestellt. Es wäre natürlich großartig, wenn sich das durch diese Maßnahme zumindest mittelbar und möglicherweise zukünftig auch unmittelbar ändert. Wir erwarten mit der Bearbeitung in OSM eine wesentliche Verbesserung der geographischen Grundlage. Auf jeden Fall ist es zunächst einmal erfreulich, wenn OSM für die Nutzer der Fahrplanauskunft hilfreich sein könnte. Von daher vielen Dank für diese Initiative. :-) Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag soll globale_id_pt = * (IFOPT Nummer) heißen. Bitte nur einfügen, was mit unserer Lizenz kompatibel und frei verfügbar ist. Nummern, deren Bedeutung unter Verschluss ist, hätten in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank keine Berechtigung mehr hätte. Sollte die Lizenzkompatibilität für die hier von Dir im Thread erwähnten Nummern gegeben sein, dann bitte deren Bedeutung im OSM Wiki erklären und eine zuverlässige Quelle möglichst im Internet angeben, wo diese Nummern aufgelistet sind. Denn die Daten in OSM sollten für jeden OSMler nachprüfbar sein. Alternativ kann die Erklärung auch hier im Thread geschehen, wenn Du bestätigst, dass der Text CC BY SA ist. Dann kann der Text ins OSM Wiki übernommen werden. Dieser neue Tag ist die eindeutige Nummerierung der Objekte einer Haltestelle nötig. Diese Nummerierung der Haltestelle wird basierend auf dem CEN Standard CEN TC278 SG6 IFOPT (Identification of Fixed Objects in Public Transport) durchgeführt. Dieser Standard sieht für Deutschland folgende Codierung vor: Für die Plattformen in OSM: de:Landkreisnr:lokale Haltstellennummer:PlattformNr Für die Stop_Position in OSM: de:Landkreisnr:lokale Haltstellennummer:PlattformNr:SteigCode Für die Eingänge der Bahnhöfe: de:Landkreisnr:lokale Haltstellennummer:EingangNr Sprichst Du bei Haltestellennummer, PlattformNr, Steigcode und EingangNr etc. nur von Zügen (ab S-Bahn aufwärts?) und nicht vom örtlichen Nahverkehr mit U-Bahn/Stadtbahn, Straßenbahnen und Bussen? Existieren diese Nummern dort nicht? Denn wenn wir schon mit irgendwelchen Nummern anfangen und diese nicht nur für Züge existieren, dann sollten diese zumindest im benutzten Gebiet auch komplett und nicht nur in Teilmenge verfügbar sein. Weitere Frage: Existieren diese Nummern deutschlandweit, europaweit oder gar weltweit oder nur in dem von Dir beschriebenen Gebiet? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tirkon, Am Sonntag, 7. Juli 2013, 12:06:06 schrieb Tirkon: Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag soll globale_id_pt = * (IFOPT Nummer) heißen. Nummern, deren Bedeutung unter Verschluss ist, hätten in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank keine Berechtigung mehr hätte. Aua! Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Dirk, Am Sonntag, 7. Juli 2013, 10:10:26 schrieb Dirk Sohler: Die Modellierung soll Routing und Navigation innerhalb des Bahnhofs bis zum Fahrzeug erlauben und dabei speziell auch wo möglich die Berechnung barrierefreier Routen ermöglichen. Ist das ein Projekt, aus dem die Community ganz im Sinne von Open Data einen Nutzen ziehen kann, oder ist das eine interne Geschichte, auf die ein Normalbürger nicht ohne weiteres Zugriff bekommen kann? Vielleicht beschäftigst du dich erst einmal mit der Materie? Die IBNR, die Bahnhöfe kennzeichnet, wird von den entsprechenden Leuten durchaus gewünscht, leider gibt es aber keine frei verfügbaren Listen. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tracy. Das Ziel klingt nicht schlecht - aber die ID halte ich für unnötig - Erklärung folgt unten: Am 07.07.2013 08:19, schrieb Tracy Kasperczyk: Sehr geehrte OSM-Gemeinde, [...] Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag soll globale_id_pt = * (IFOPT Nummer) heißen. Dieser neue Tag ist die eindeutige Nummerierung der Objekte einer Haltestelle nötig. Diese Nummerierung der Haltestelle wird basierend auf dem CEN Standard CEN TC278 SG6 IFOPT (Identification of Fixed Objects in Public Transport) durchgeführt. Dieser Standard sieht für Deutschland folgende Codierung vor: Für die Plattformen in OSM: de:Landkreisnr:lokale Haltstellennummer:PlattformNr Der AGS ist in OSM prinzipiell schon vorhanden und eine räumliche Zuordnung sollte möglich sein, insofern kann eine Vorverarbeitung für jede Plattform den AGS und damit auch die Landkreisnummer herausfinden. Die Lokale Haltestellennummer: Wo steht die? Wo lässt sich die für den normalen Mapper nachschlagen? Denn jeder muss prinzipiell in der Lage sein, einen Tag zu verifizieren oder zu korrigieren, sonst macht das keinen Sinn. Ich vermute mal ins Blaue (korrigiert mich, wenn ich falsch liege), dass es Listen dafür gibt, die eine Zuordnung wie Ort/Haltestellenname = Haltestellennummer enthalten. Wenn das der Fall ist, kann man aber aus Ort und Haltestellennamen auch wieder die Nummer rauskriegen. Zur Plattformnummer sagst du nichts weiter, insofern weiß ich nicht, wie die vergeben wird, aber wir haben mit ref=* die Gleisnummer, wenn vorhanden, normalerweise auch drin. Für die Stop_Position in OSM: de:Landkreisnr:lokale Haltstellennummer:PlattformNr:SteigCode Für die Eingänge der Bahnhöfe: de:Landkreisnr:lokale Haltstellennummer:EingangNr Die Landkreisnummer kommt aus dem Amtlichen Gemeindeschlüssel. Die lokale Nummer vergibt der örtlich verantwortliche Verkehrsverbund oder der Landkreis bei Landkreisen ohne Verbund. Wir benötigen diese Nummer für 3-Objekte aus OSM, für die Plattformen (Bahnsteige), für die Stop_position auf den Gleisen und für die Zugänge/ Eingänge zu den Bahnhöfen. Es existieren bereits solche Nummern aus den Haltestellenkatastern der jeweiligen Länder, die wir und unsere Kunden in OSM durch einen neuen Tag einpflegen würden. Diese Nummer sollte nicht bearbeitet werden, da unsere Kunden diese benötigen um mit den OSM-Daten weiterarbeiten zu können. Wir würden uns sehr über die Mithilfe der OSM-Gemeinde bei der Umsetzung des Projektes freuen. Ich sehe hier zwei Probleme: 1) Diese Nummer sollte nicht bearbeitet werden 2) Mithilfe der OSM-Gemeinde: Wie soll die mithelfen, wenn die Mithilfe darin besteht, nichts zu tun? Zum ersten Problem: Als sollte nicht bearbeitet werden ist das vielleicht noch halbwegs akzeptabel - ein Verbot wird daraus aber nicht werden. Ihr könnt euch als nicht darauf verlassen, dass die Nummer in OSM nicht bearbeitet wird. Ihr könnt euch aber nichtmal darauf verlassen, dass die Nummer korrekt bleibt. Nehmen wir als Beispiel eine Bushaltestelle mit zwei Bussteigen, die bisher noch nicht vollständig erfasst ist, es existiert also noch gar keine Plattform - auch wenn ihr Referenznummern dazu habt. Ich vermute, ihr würdet hier zunächst nur die Nummer einfügen, also die Haltestellennummmer und die Landkreisnummer, denn woher solltet ihr auf einmal Kartenmaterial haben, das in OSM aufgenommen werden dürfte, und genauer ist? Jetzt fängt ein Mapper (ich zum Beispiel) an und trägt die einzelnen Bussteige ein, angenommen, das sind drei. Darf ich eure ID jetzt eintragen? Wenn ja: warum sollte ich das tun? das sind doch schließlich redundante Informationen (siehe oben). Anderer Fall: Die Haltestelle ist schon mit einzelnen Bussteigen eingetragen, aber aus irgendeinem Grund zeichnet ein Mapper die einzelnen Wege neu ein, z.B. weil er aus versehen vorher was kaputtgemacht hat oder so. Darf er jetzt die IDs eintragen? Korrigieren? Ändern? Woher kriegt er die? Um sicherzugehen, dass eure Kunden nicht durch solche und ähnliche Fälle ständig fehlerhafte Daten kriegen, müsstet ihr also unabsichtliche Änderungen überwachen, kontrollieren und korrigieren. Dabei müsstet ihr aber sicherstellen, dass gültige und korrekte Korrekturen weiter möglich bleiben - also z.B. muss ich in der Lage sein, den neuen Aufzug einzutragen (der sogar für euren direkten Anwendungsfall hilfreich ist), oder die neue Pflasterung der Haltestelle, bei der die Querung auf 0 abgesenkt, aber mit taktilen Bodenindikatoren ausgestattet worden ist - und so weiter. Insbesondere beinhaltet das auch die Möglichkeit, Teile der Haltestelle zu verschieben (um z.B. die Lage zu korrigieren). Wenn ihr eine solche Überwachung aber nicht manuell umsetzen wollt, bleibt euch nicht viel mehr übrig, als sowieso - alle Haltestellenobjekte/Plattformen etc., die in OSM auftauchen, zu bemerken - jeweils die Daten zu überprüfen, - und dann eure ID da dranzupappen. ...und das unter Vermeidung aller Konflikte
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tracy, ihr wart ja schon vor ein paar Wochen bei uns auf dem Stammtisch und habe da bereits einiges an Infos und auch an möglichen Bedenken mitbekommen. Es freut mich dass es euch nicht abgeschreckt hat OSM Daten zu verwenden. Wenn ihr die PlatformNr, SteigCode und EingangNr zur Verfügung stellt ist das eine große Ergänzung zu OSM. Wir haben dadurch nicht nur sämtliche Haltestellen sondern auch noch die Eingänge dazu. Könnt ihr zusätzlich den Namen der Haltestelle beitragen und eventuell welche Linie dort fährt? Was auf jeden Fall passieren kann ist dass jemand den Tag versehentlich löscht, ändert oder bei neuen Haltestellen nicht einträgt. Es könnte auch sein dass es Abweichungen zwischen eurer Liste und der Realität gibt. Habt ihr einen Plan wie ihr damit umgehen wollt? On 07.07.2013 08:19, Tracy Kasperczyk wrote: Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag soll globale_id_pt = * (IFOPT Nummer) heißen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Am 07.07.2013 06:15, schrieb Wolfgang Hinsch: Hallo, ich habe auch noch eine Idee dazu. Kann man das nicht mit etwas Redundanz lösen? Die Schienen werden einzeln lagerichtig erfasst, wie es allgemein für Gleise üblich ist. Für das Schienenfahrzeug kann man die bauliche Trennung nicht wegdiskutieren. Die Straße wird als way erfasst, wie sonst auch. Beide folgen damit ihren eigenen Regeln. Damit hätten wir 3 oder auch 4 ways (wenn die Straße auch baulich getrennt ist). Die räumlichen Details werden mit dem Spurmapping-Modell erfasst. http://wiki.openstreetmap.org/wiki/Key:lanes Beispiel für eine Straße mit 5 Spuren, Straßenbahn in der Mitte, Richtung Osten auf eigenem Gleiskörper in der Mitte, Richtung Westen mit Bus auf Sonderspur: –– Fahrbahnrand -- - - - - - - - - Richtungsfahrbahn West -- -- Durchgezogene Linie ==BUS= Sonderspur Bus/Straßenbahn auf der Fahrbahn –– Fahrbahnrand == Gleis im eigenen Baukörper –– Fahrbahnrand -- - - - - - - - - Richtungsfahrbahn Ost -- –– Fahrbahnrand Erfassung: –– (highway=*,...) == (rail=*,...) == (rail=*,...) –– (highway=*,...) Die ways für die Fahrbahn und Gleise wie üblich in der jeweiligen Fahrbahn(Gleis)Mitte. Die Gleise werden getaggt wie sonst auch (voltage etc pp) Eventuell kann man noch ein tag wie z.B. space=separat|highway hinzufügen, so dass auch aus dem Gleis hervorgeht, ob es sich im Fahrbahnbereich befindet. Für die Fahrbahn werden die Fahrspuren erfasst. -- West: highway=* lanes=3 width=10.5 oneway=(yes|1|forward) change:lanes:forward=no|only_right|yes access:lanes:forward=tram;psv|yes|yes alternativ access:lanes:forward=no|yes|yes access:lanes:tram:forward=yes|no|no access:lanes:psv:forward=yes|yes|yes Ich würde die erste Alternative bevorzugen. Lanes immer, auch bei Einbahnstraßen, mit forward/backward, damit im Fall des Umdrehens der wayrichtung, aus welchen Gründen auch immer, die Editoren forward/backward austauschen können. -- Ost: highway=* lanes=2 width=7 oneway=(yes|1|forward) hier sind keine weiteren Angaben erforderlich, da die Bahn eine eigene Trasse hat. Das ist erkennbar aus 1. der Lage der ways, die Fahrbahn ist mit 2 Spuren -- Ost bei dem Abstand vom Gleis nicht breit genug, um den Gleiskörper mit zu erfassen, 2. aus dem Spurmapping 3. ggf. aus einem Tag am Gleis Wer mag, kann die Straße zusätzlich als Fläche erfassen. Da das aber nicht allgemein erfolgt, ist hier mit einer Auswertung nur in örtlichen Sonderfällen zu rechnen. Man sollte immer auch daran denken, dass eine Flächenerfassung eines langen und schmalen Baukörpers wie einer Straße schon im Maßstab 1:2 nicht mehr darstellbar ist. Für den Router sind solche Flächen ebenfalls nur mit hohem Aufwand (wenn überhaupt) nutzbar. Habe deine Erläuterungen nicht ganz verstanden aber mein Problem sind nicht Einbahnstraßen oder baulich getrennte Straßen, sondern Straßen ohne bauliche Trennung die in beide Richtungen Spuren haben und zusätzlich mehrere Schienen. - - - - - - - - - - - Fahrrad/Fußweg –– Fahrbahnrand --=== Tram West - - - - - - - - Richtungsfahrbahn West -- -- Durchgezogene Linie --=== Tram Ost - - - - - - - - Richtungsfahrbahn Ost -- –– Fahrbahnrand - - - - - - - - - - - Fahrrad/Fußweg Dies kann man in eine Linie packen. Wenn ich nun die Schiene separat zeichne sind sie neben der Straße. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 07.07.2013 09:11, schrieb Henning Scholland: Am 06.07.2013 19:59, schrieb jotpe: Am 6. Juli 2013 15:00 schrieb Martin Koppenhoefer dieterdre...@gmail.com: +1, wobei man klären sollte, wie das in den Originaldaten gemacht wird (z.B. eine ehem. Lagerhalle, die jetzt bewohnt wird, taucht die als Lagerhalle oder Wohngebäude auf?). Oder eine Kirche, entweiht und jetzt als Theater genutzt, ist das in deren Daten eine Kirche oder wie ist die enthalten? Die Daten spiegeln den letzten amtlichen Stand wieder. Etwas anderes weiß die Stadt nicht. Zunächst sollten wir davon ausgehen, dass die Daten stimmen. Ich denke schon, dass wir das auch überprüfen sollten. Und wenn es nur ein Blick auf das Luftbild ist um zu schauen, ob da wirklich ein(e) Haus/Kirche/Lagerhalle ist. Wenn wir uns Fehler mit importieren, sind wir letzlich nicht viel mehr als ein Sammelbecken, in da jeder seine Geodaten rein kippt. Wenn die Daten frei sind und wir sie nicht manuell kontrollieren können/wollen, dann sehe ich keinen Sinn darin, sie in OSM reinzukippen. Jeder der die Daten nutzen möchte könnte sie dann genauso gut direkt von der Stadt nehmen. +1 fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hi, Am Sun, 7 Jul 2013 08:19:17 +0200 schrieb Tracy Kasperczyk kasperc...@mentzdv.de: ... soll globale_id_pt = * (IFOPT Nummer) heißen. Ich würde es eher ifopt_ref nennen. Jede Suchmaschine liefert dann passende Ergebnisse für den verwirrten Mapper. Zum Konzept: Falls ihr dabei Bahnsteige braucht, die nur zu einem Gleis gehören -- man die Bahnsteige also längs spalten müsste -- dann habt Ihr ein Problem. OSM könnte sich gegen längsgesplittete Bahnsteige entscheiden. Falls Ihr mit Bahnsteigen in mehreren Teilen nicht klar kommt. OSM hat sie wegen der Regelung mit Brücken. Der Mainzer Hauptbahnhof hat z.B. sowas auf Gleis 5: Eine Brücke mitten im Bahnsteig sorgt für eine Quer-Aufteilung des Bahnsteigs. Auch in Mainz kann man doppelte Benennungen von Bahnsteigen sehen, die so auch in den Fahrplänen auftauchen. Es gibt sowohl ein Gleis 3 als auch Gleise 3a und 3b, obwohl das Ganze nur eine Bahnsteigsseite ist. Dann gibt es noch Halte, bei denen gleichzeitig an zwei Bahnsteigen gehalten wird. Das findet man z.B. bei der wie-auch-immer-sie-gerade-heißt-Arena in Düsseldorf. Was ist mit Ersatzhaltestellen bei Baustellen. Bei längerfristigen Baustellen nehmen wir die eine gern aus den Linienrelationen raus und die Ersatzhaltestelle kommt rein. Was sollte dann mit der Nummer passieren? Ihr braucht vermutlich die einzelnen Bahnsteige. Wo die nicht gemappt sind, könnt Ihr sie natürlich eintragen, wenn das mit der Lizenz hinkommt. Aber dabei müssen alle benutzenden Relationen angepasst werden. Man muss also plötzlich Bahnsteig- oder Bussteignummern aller Linien wissen und eintragen dürfen. Das gilt dann auch für die Fahrzeuge von Nicht-Auftraggebern! (Zum Beispiel in den Überlappungsgebieten von Verkehrsverbünden.) Ist das Problem wirklich lösbar? MfG Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 07.07.2013 12:23, schrieb Peter Wendorff: Der AGS ist in OSM prinzipiell schon vorhanden und eine räumliche Zuordnung sollte möglich sein, insofern kann eine Vorverarbeitung für jede Plattform den AGS und damit auch die Landkreisnummer herausfinden. Die Lokale Haltestellennummer: Wo steht die? Wo lässt sich die für den normalen Mapper nachschlagen? Denn jeder muss prinzipiell in der Lage sein, einen Tag zu verifizieren oder zu korrigieren, sonst macht das keinen Sinn. Ich vermute mal ins Blaue (korrigiert mich, wenn ich falsch liege), dass es Listen dafür gibt, die eine Zuordnung wie Ort/Haltestellenname = Haltestellennummer enthalten. Wenn das der Fall ist, kann man aber aus Ort und Haltestellennamen auch wieder die Nummer rauskriegen. Zur Plattformnummer sagst du nichts weiter, insofern weiß ich nicht, wie die vergeben wird, aber wir haben mit ref=* die Gleisnummer, wenn vorhanden, normalerweise auch drin. +1 Ich sehe hier zwei Probleme: 1) Diese Nummer sollte nicht bearbeitet werden Wird es in OSM nie geben. 2) Mithilfe der OSM-Gemeinde: Wie soll die mithelfen, wenn die Mithilfe darin besteht, nichts zu tun? +1 Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Am Sun, 07 Jul 2013 14:22:48 +0200 schrieb fly lowfligh...@googlemail.com: Dies kann man in eine Linie packen. Wenn ich nun die Schiene separat zeichne sind sie neben der Straße. Es ist völlig in Ordnung, Objekte wie die Straße als Linie (also mit der zeichnerischen Breite Null) darzustellen -- aber es hat Konsequenzen und mit denen muss man sich abfinden. Dann ist neben der Straße nun mal etwas anderes als neben der Linie, die die Straße darstellt. Die Wiese liegt vielleicht direkt neben der Straße, hat ja dann aber gewöhnlich mehrere Meter Abstand zur Linie, die die Straße darstellt. Das ist doch völlig OK (solange das niemand innerhalb eines Wald-Multipolygons macht und so unbeabsichtigt äußerst längliche Wälder erfindet). frohes Mappen Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] tourism = viewpoint?
--schnipp-- Ergebnis der Adresssuche: 1. Aussichtspunkt Mount Everest, Tingri County, Shigatse Prefecture, Autonomes Gebiet Tibet, Volksrepublik China --schnapp-- Also Leute ehrlich. Wie kann man nur auf die völlig bescheuerte Idee kommen 8000er Gipfel als tourism = viewpoint zu taggen? Gruss Sven -- Software is like sex; it's better when it's free (Linus Torvalds) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tourism = viewpoint?
2013/7/7 Sven Geggus li...@fuchsschwanzdomain.de --schnipp-- Ergebnis der Adresssuche: 1. Aussichtspunkt Mount Everest, Tingri County, Shigatse Prefecture, Autonomes Gebiet Tibet, Volksrepublik China --schnapp-- Also Leute ehrlich. Wie kann man nur auf die völlig bescheuerte Idee kommen 8000er Gipfel als tourism = viewpoint zu taggen? wieso nicht? Sind nicht die Bergsteiger z.T. Touristen? Andere Touristen kommen da auch nicht in die Nähe... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tourism = viewpoint?
Am 07.07.2013 15:13, schrieb Martin Koppenhoefer: 2013/7/7 Sven Geggus li...@fuchsschwanzdomain.de --schnipp-- Ergebnis der Adresssuche: 1. Aussichtspunkt Mount Everest, Tingri County, Shigatse Prefecture, Autonomes Gebiet Tibet, Volksrepublik China --schnapp-- Also Leute ehrlich. Wie kann man nur auf die völlig bescheuerte Idee kommen 8000er Gipfel als tourism = viewpoint zu taggen? wieso nicht? Sind nicht die Bergsteiger z.T. Touristen? Andere Touristen kommen da auch nicht in die Nähe... +1 Soviel ich weiß gibt mensch mit viewpoint an, dass mensch von dort eine Aussicht genießen kann. Zum Teil wird auch noch die Richtung angegeben. Auf dem Mount Everest sind doch nur Touristen. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tourism = viewpoint?
Hallo Sven, in meinen Augen (und auch in den Augen des Wikis) ist das keine Frage der Lage des Ortes. Henning Am 07.07.2013 15:07, schrieb Sven Geggus: --schnipp-- Ergebnis der Adresssuche: 1. Aussichtspunkt Mount Everest, Tingri County, Shigatse Prefecture, Autonomes Gebiet Tibet, Volksrepublik China --schnapp-- Also Leute ehrlich. Wie kann man nur auf die völlig bescheuerte Idee kommen 8000er Gipfel als tourism = viewpoint zu taggen? Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
Am Sonntag, den 07.07.2013, 14:22 +0200 schrieb fly: Habe deine Erläuterungen nicht ganz verstanden aber mein Problem sind nicht Einbahnstraßen oder baulich getrennte Straßen, sondern Straßen ohne bauliche Trennung die in beide Richtungen Spuren haben und zusätzlich mehrere Schienen. OK, vereinfachtes Beispiel, bezieht sich weitgehend auf http://wiki.openstreetmap.org/wiki/DE:Lanes Situation vor Ort, skizziert: – Fahrbahnrand Fahrbahn -- West - - - - - - - - - Fahrbahnmarkierung = Straßenbahngleis auf Fahrbahn -- West - - - - - - - - - Fahrbahnmarkierung in der Mitte = Straßenbahngleis auf Fahrbahn -- Ost - - - - - - - - - Fahrbahnmarkierung Fahrbahn -- Ost – Fahrbahnrand Mapping: – rail=* (a) – highway=* (b) – rail=* (a) Tagging: (a) rail = * wie immer, zusätzlich als Vorschlag space=highway (=dieses Gleis verläuft im Fahrbahnbereich des highway) vielleicht gibt es auch etwas Besseres. (b) highway=* lanes=2 width=7 change:lanes:forward=yes|yes change:lanes:backward=yes|yes (oder change:lanes als default weglassen) access:lanes:forward=yes;tram|yes access:lanes:backward=yes;tram|yes alternativ access:lanes:forward=yes|yes access:lanes:backward=yes|yes access:lanes:tram:forward=yes|no access:lanes:tram:backward=yes|no (a) wie oben Dies kann man in eine Linie packen. Nein, das sehe ich nicht so. Eine baulich getrennte Straße hat in der Regel mehr als eine Fahrspur pro Richtung. Dann ist die Mitte der Fahrbahn nicht identisch mit der Mitte des Gleises und sollte deshalb separat geometrisch möglichst richtig erfasst werden. Bei nur einer Fahrspur stimme ich dir zu. Wenn ich nun die Schiene separat zeichne sind sie neben der Straße. Nein, sie sind möglichst geometrisch richtig. Wenn der Renderer die Schiene neben die Straße malt, weil er das Konzept nicht rafft, ist das sein Problem. Er _kann_ es korrekt auswerten. Die Lage von Schiene und Straße zueinander ergibt sich aus: 1. Lage der beiden Mittellinien und ihren Breiten, sowohl Straßenbreite als auch Spurweite des Gleises werden gemappt. 2. Tag tram im access der jeweiligen Fahrspur 3. Tag space=highway (oder was anderes) am Gleis Was uns fehlt, ist ein Renderer, der aktueller und flexibler das Tagging umsetzt als der jetzige Mapnik. Dazu sollte es eine Testseite geben, deren Rendering in die Standardseite einfließt, sobald es mehrheitlich akzeptiert wurde. Im Moment haben wir so eine Art Diktatur, mit der Mapnik umsetzt, was dem Team gerade gefällt, und andere Entwicklungen schlicht aussitzt. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Sonntag, den 07.07.2013, 12:17 +0200 schrieb Eckhart Wörner: Hallo Tirkon, Am Sonntag, 7. Juli 2013, 12:06:06 schrieb Tirkon: Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag soll globale_id_pt = * (IFOPT Nummer) heißen. Nummern, deren Bedeutung unter Verschluss ist, hätten in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank keine Berechtigung mehr hätte. Aua! Warum Aua? Ich stimme Tirkon hier voll zu. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 06.07.2013 15:46, schrieb Martin Koppenhoefer: Bisher ist glaube ich die vorherrschende Meinung, dass alles ausser Fahrbahnmarkierungen oder explizit überfahrbaren Grenzelementen (aus Kunststoff) als baulich getrennt gilt, also z.B. ein Grünstreifen oder ein Bordstein. Also ich sehe derzeit nur eine bauliche Trennung ab einer gewissen Breite (oder evtl. Höhe) als solche an. Trennungen im Zentimeterbereich wie die von dir genannten Kunststoffelemente, aber auch Bordsteine, zähle ich nicht dazu. Den Bordstein als nicht als bauliche Trennung zu behandeln hat auch deshalb eine gewisse Logik, weil er insbesondere für diejenigen Verkehrsteilnehmer, deren Bereich damit in erster Linie abgetrennt wird - nämlich Fußgänger - kein nennenswertes Hindernis ist. Insofern ist er durchaus auch explizit überfahrbar (oder vielleicht übergehbar). Warum schreibe ich oben derzeit? Weil wir momentan noch kaum Erfahrung mit der Nutzung von Spurinformationen in Anwendungen haben und die Frage, was am besten in der Praxis funktioniert, nicht unberücksichtigt bleiben sollte. Dafür ist es in dieser Diskussion aber noch zu früh. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 07.07.2013 06:47, schrieb Wolfgang Hinsch: divider knapp 300 Einträge seit 12/2007 change:lanes knapp 5000 Einträge seit 11/2012 change:lanes und divider lassen sich nicht direkt vergleichen. Die konkrete Art der Trennung kann man nämlich nur mit divider abbilden, da ist change:lanes mit seinen nur vier möglichen Wertepaaren fürs Überfahren - beidseitig, nur von links, nur von rechts, gar nicht - kein vollständiger Ersatz. Allenfalls könnte man change:lanes als überflüssig betrachten, wenn man annimmt, dass die Anwendung die Bedeutung von doppelt durchgezogene Linie und allen anderen Trennern in dem jeweiligen Land kennt und die derzeit in change:lanes enthaltene Information daraus ableiten kann. Umgekehrt gilt das aber nicht. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Wolfgang, Am Sonntag, 7. Juli 2013, 15:33:07 schrieb Wolfgang Hinsch: Nummern, deren Bedeutung unter Verschluss ist, hätten in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank keine Berechtigung mehr hätte. Aua! Warum Aua? Weil die Aussage auf so vielen Ebenen falsch ist, dass es einfach nur weh tut. Erstens ist OSM keine freie Datenbank, sondern eine freie *Geo*datenbank, d.h. es gibt zwangsläufig Daten, die außerhalb von OSM liegen müssen (auch wenn es genug Leute gibt, die das nicht einsehen). Dazu braucht es aber Möglichkeiten, Daten innerhalb von OSM zu adressieren. Zweitens ist es nicht das Ziel von OSM, die Verknüpfung mit Daten in geschlossenen Fremdsystemen zu verbieten, im Gegenteil: die ODbL ist extra so geschrieben, um solche Nutzungen zu ermöglichen. Drittens gibt es jede Menge Nummern in OSM, die genau die gleichen Kriterien erfüllen, und an denen sich auch keiner stößt: TMC-Codes, IBNR-Nummern, ICAO-Codes, … Und viertens ist die Bedeutung der Nummer (die eindeutige Identifikation von Haltestellen) gar nicht unter Verschluss, die Bedeutung soll ja gerade in OSM eingepflegt werden. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am Sonntag, den 07.07.2013, 15:51 +0200 schrieb Tobias Knerr: Am 07.07.2013 06:47, schrieb Wolfgang Hinsch: divider knapp 300 Einträge seit 12/2007 change:lanes knapp 5000 Einträge seit 11/2012 change:lanes und divider lassen sich nicht direkt vergleichen. Die konkrete Art der Trennung kann man nämlich nur mit divider abbilden, da ist change:lanes mit seinen nur vier möglichen Wertepaaren fürs Überfahren - beidseitig, nur von links, nur von rechts, gar nicht - kein vollständiger Ersatz. Wenn du eine zusätzliche Möglichkeit kennst (überfliegen, überklettern, drunter durchtauchen ;-) ), kann man die ja noch einbauen. Allenfalls könnte man change:lanes als überflüssig betrachten, wenn man annimmt, dass die Anwendung die Bedeutung von doppelt durchgezogene Linie und allen anderen Trennern in dem jeweiligen Land kennt und die derzeit in change:lanes enthaltene Information daraus ableiten kann. Umgekehrt gilt das aber nicht. Der Unterschied besteht wohl darin, dass change:lanes direkt sagt, was du darfst und was nicht, während man bei divider, so wie du es definierst, erst mal die jeweiligen Landesgesetze zu Rate ziehen muss. Es gibt aber noch die Möglichkeit, mit barrier=* das jeweilige Hindernis einzutragen. Außerdem highway=traffic_island. Eigenartigerweise gibt es noch nichts für Sperrflächen. Gru0, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 07.07.2013 16:07, schrieb Wolfgang Hinsch: Am Sonntag, den 07.07.2013, 15:51 +0200 schrieb Tobias Knerr: change:lanes und divider lassen sich nicht direkt vergleichen. Die konkrete Art der Trennung kann man nämlich nur mit divider abbilden, da ist change:lanes mit seinen nur vier möglichen Wertepaaren fürs Überfahren - beidseitig, nur von links, nur von rechts, gar nicht - kein vollständiger Ersatz. Wenn du eine zusätzliche Möglichkeit kennst (überfliegen, überklettern, drunter durchtauchen ;-) ), kann man die ja noch einbauen. Es geht mir eher um die Information, wie die Trennung denn jetzt physikalisch umgesetzt ist. Der Trenner an sich und die daraus abgeleiteten Verkehrsvorschriften sind eben zwei Paar Schuhe, analog zum Unterschied zwischen barrier=bollard und dem daran angebrachten access=no + foot=yes + ... Der Unterschied besteht wohl darin, dass change:lanes direkt sagt, was du darfst und was nicht, während man bei divider, so wie du es definierst, erst mal die jeweiligen Landesgesetze zu Rate ziehen muss. Umgekehrt sagt einem divider direkt, wie es aussieht, während man bei change:lanes die Landesgesetze kennen muss - und bei unterschiedlichen möglichen Ausführungen auch dann noch raten muss. Daher ist change:lanes für routing-nahe Anwendungen wie den intelligenten Spurassistenten nützlich und divider für die grafische Darstellung. Insofern würde ich kein entweder-oder daraus machen. Es gibt aber noch die Möglichkeit, mit barrier=* das jeweilige Hindernis einzutragen. Außerdem highway=traffic_island. Also barrier halte ich für ungeeignet für Trenner innerhalb einer als Einzelway dargestellten Straße - für eine Leitplanke zwischen zwei Ways z.B. aber sicher nicht verkehrt. traffic_island ist natürlich sinnvoll, aber eher etwas punktuelles. Und mit dem highway-Schlüssel kenne ich das eigentlich gar nicht...? Eigenartigerweise gibt es noch nichts für Sperrflächen. Ja, ist noch eine Lücke. Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 07.07.2013 16:07, schrieb Wolfgang Hinsch: Am Sonntag, den 07.07.2013, 15:51 +0200 schrieb Tobias Knerr: Am 07.07.2013 06:47, schrieb Wolfgang Hinsch: divider knapp 300 Einträge seit 12/2007 change:lanes knapp 5000 Einträge seit 11/2012 change:lanes und divider lassen sich nicht direkt vergleichen. Die konkrete Art der Trennung kann man nämlich nur mit divider abbilden, da ist change:lanes mit seinen nur vier möglichen Wertepaaren fürs Überfahren - beidseitig, nur von links, nur von rechts, gar nicht - kein vollständiger Ersatz. Wenn du eine zusätzliche Möglichkeit kennst (überfliegen, überklettern, drunter durchtauchen ;-) ), kann man die ja noch einbauen. Soll ich mal anfangen? Überklettern (Leitplanke) Übersteigen (Bordstein) Überfahren mit PKW (Bordstein) Überfahren mit Rollstuhl, Überfahren mit Bollerwagen, ... Die letzten vier unterscheiden sich möglicherweise nur in er Bordsteinhöhe, und beim Rollstuhl kommt es außerdem stark auf die Fähigkeiten des Rollifahrers an, insofern sind das unterschiedliche Informationen. Ob man die in einen divider-Tag einbauen könnte, wage ich zu bezweifeln. Allenfalls könnte man change:lanes als überflüssig betrachten, wenn man annimmt, dass die Anwendung die Bedeutung von doppelt durchgezogene Linie und allen anderen Trennern in dem jeweiligen Land kennt und die derzeit in change:lanes enthaltene Information daraus ableiten kann. Umgekehrt gilt das aber nicht. Der Unterschied besteht wohl darin, dass change:lanes direkt sagt, was du darfst und was nicht, während man bei divider, so wie du es definierst, erst mal die jeweiligen Landesgesetze zu Rate ziehen muss. Ich denke, prinzipiell ist beides sinnvoll und schließt sich nicht aus: change:lanes ist eine rechtliche Sache divider ist eine physische Beschreibung. Beides hat konsequenzen für bestimmte Nutzer, aber die Tags sind weder austauschbar noch beliebig zusammenzuführen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Peter, Am Sonntag, 7. Juli 2013, 16:34:08 schrieb Peter Wendorff: Aber: Wenn der Fremdschlüssel als Information selbst nicht frei ist - und das ist die Annahme von Wolfgang, die er hier zurecht äußert, dann darf sie - unabhängig davon, welchen Umfang OSM hat oder haben sollte - nicht in OSM eingefügt werden. Da liest du dann was anderes in die Aussagen als ich: Wolfgang hat sich lediglich Tirkon angeschlossen, und Tirkons Argument war m.E. eindeutig ideologisch motiviert und hat sich nicht an Lizenzfragen orientiert. Abgesehen davon kann ich mir nicht vorstellen, dass Mentz Daten ihrer Kunden in OSM einpflegt, ohne die Kunden vorher um Erlaubnis zu fragen. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo, Am 07.07.2013 16:57, schrieb Eckhart Wörner: Abgesehen davon kann ich mir nicht vorstellen, dass Mentz Daten ihrer Kunden in OSM einpflegt, ohne die Kunden vorher um Erlaubnis zu fragen. Kann ich mir auch nicht vorstellen. Die Frage ist, ob sich diese Kunden über die Tragweite ihrer Zustimmung im Klaren sind. Wenn ebendiese Kunden ihre Daten bisher nicht unter mit den Contributor Terms kompatiblen Bedingungen bereit gestellt haben, dann ist es legitim daran zu zweifeln, ob ihnen klar ist, dass sie das jetzt auf dem Umweg über die Firma Mentz tun. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Tobias Knerr o...@tobias-knerr.de wrote: Am 06.07.2013 15:46, schrieb Martin Koppenhoefer: Bisher ist glaube ich die vorherrschende Meinung, dass alles ausser Fahrbahnmarkierungen oder explizit überfahrbaren Grenzelementen (aus Kunststoff) als baulich getrennt gilt, also z.B. ein Grünstreifen oder ein Bordstein. Also ich sehe derzeit nur eine bauliche Trennung ab einer gewissen Breite (oder evtl. Höhe) als solche an. Trennungen im Zentimeterbereich wie die von dir genannten Kunststoffelemente, aber auch Bordsteine, zähle ich nicht dazu. Den Bordstein als nicht als bauliche Trennung zu behandeln hat auch deshalb eine gewisse Logik, weil er insbesondere für diejenigen Verkehrsteilnehmer, deren Bereich damit in erster Linie abgetrennt wird - nämlich Fußgänger - kein nennenswertes Hindernis ist. Insofern ist er durchaus auch explizit überfahrbar (oder vielleicht übergehbar). Genau hier kommen wir an einen der haarigen Punkte, den ich in der bisherigen Diskussion als schwammig bezeichnet habe. Der Grünstreifen wird beim Übergang vom Städtischen zum Ländlichen zum Pendant des Bordsteins. Will man von einen so getrennten Rad-/Fußweg aus die Straße überqueren, darf und muss der Streifen ebenso wie der Bordstein überwunden werden. Auch der Grünstreifen zwischen zwei Richtungsfahrbahnen darf von Fussgängern überwunden werden. Für den Autofahrer hingegen ist dieser Streifen in beiden Fällen tabu. Warum schreibe ich oben derzeit? Weil wir momentan noch kaum Erfahrung mit der Nutzung von Spurinformationen in Anwendungen haben und die Frage, was am besten in der Praxis funktioniert, nicht unberücksichtigt bleiben sollte. Dafür ist es in dieser Diskussion aber noch zu früh. Den Ansatz, möglichst für viele Anwendungen nützlich zu sein, habe ich auch schon früher hier vertreten. Ich habe das damals Kundenorientierung genannt. Es heißt zwar: Wir mappen nicht für die Anwendungen. Aber welchen Sinn hat eine Datenbank ohne diese? Die Idee für eine Datenbank entspringt zunächst einmal aus einer beabsichtigten Anwendung. Derlei Begehrlichkeiten können sich natürlich ausweiten. Ob beispielsweise die Väter von OSM schon daran gedacht haben, Grundlage für einen Navi zu sein, ist fraglich. Von daher müssen Ansätze hin und wieder auf den Prüfstand. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Eckhart Wörner ewoer...@kde.org wrote: Da liest du dann was anderes in die Aussagen als ich: Wolfgang hat sich lediglich Tirkon angeschlossen, und Tirkons Argument war m.E. eindeutig ideologisch motiviert und hat sich nicht an Lizenzfragen orientiert. Nein! Ich zitiere: Bitte nur einfügen, was mit unserer Lizenz kompatibel und frei verfügbar ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Rainer, Am Sonntag, 7. Juli 2013, 17:15:28 schrieb RainerU: Abgesehen davon kann ich mir nicht vorstellen, dass Mentz Daten ihrer Kunden in OSM einpflegt, ohne die Kunden vorher um Erlaubnis zu fragen. Kann ich mir auch nicht vorstellen. Die Frage ist, ob sich diese Kunden über die Tragweite ihrer Zustimmung im Klaren sind. Wenn ebendiese Kunden ihre Daten bisher nicht unter mit den Contributor Terms kompatiblen Bedingungen bereit gestellt haben, dann ist es legitim daran zu zweifeln, ob ihnen klar ist, dass sie das jetzt auf dem Umweg über die Firma Mentz tun. Viele Anfragen von OSMlern an Verkehrsbetriebe, die ich gesehen habe, sehen so aus, dass einfach nur nach möglichst vielen Daten gefragt wird, und den Verkehrsbetrieben die Lizenz so um die Ohren gehauen wird, dass ich volles Verständnis dafür habe, wenn die Verkehrsbetriebe da einfach nein sagen. Im aktuellen Fall ist die Situation anders: Mentz möchte das Ganze wohl organisieren, und die Verkehrsbetriebe haben dann auch einen greifbaren Nutzen. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tirkon, Am Sonntag, 7. Juli 2013, 17:36:18 schrieb Tirkon: Nein! Ich zitiere: Dann zitiere ich auch nochmal: Nummern, deren Bedeutung unter Verschluss ist, hätten in OSM nichts zu suchen Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tirkon, Am Sonntag, 7. Juli 2013, 17:36:18 schrieb Tirkon: Nein! Ich zitiere: Bitte nur einfügen, was mit unserer Lizenz kompatibel und frei verfügbar ist. Nachtrag: wenn dein Beitrag anders gemeint war als von mir interpretiert, entschuldige ich mich natürlich. Trotzdem bin ich der Meinung, dass solche Antworten einfach nur kontraproduktiv sind: wenn die erste Reaktion auf wir würden gerne was mit OSM machen nur DIE LIZENZ ist, dann läuft einiges schief. Die ODbL ist eigentlich genau aus dem Grund entstanden, dass man nicht jeden Satz mit …unter besonderer Berücksichtigung DER LIZENZ abschließen muss. Eckhart ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Sonntag, den 07.07.2013, 16:57 +0200 schrieb Eckhart Wörner: Hallo Peter, Am Sonntag, 7. Juli 2013, 16:34:08 schrieb Peter Wendorff: Aber: Wenn der Fremdschlüssel als Information selbst nicht frei ist - und das ist die Annahme von Wolfgang, die er hier zurecht äußert, dann darf sie - unabhängig davon, welchen Umfang OSM hat oder haben sollte - nicht in OSM eingefügt werden. Da liest du dann was anderes in die Aussagen als ich: Wolfgang hat sich lediglich Tirkon angeschlossen, und Tirkons Argument war m.E. eindeutig ideologisch motiviert und hat sich nicht an Lizenzfragen orientiert. Abgesehen davon kann ich mir nicht vorstellen, dass Mentz Daten ihrer Kunden in OSM einpflegt, ohne die Kunden vorher um Erlaubnis zu fragen. Was mich an der Aussage von Tirkon überzeugt ist die Überprüfbarkeit oder Nachschlagbarkeit durch den Mapper. Es kann nicht sein, dass sich hier immer mehr tags einschleichen, die niemand mehr nachvollziehen kann und schon gar nicht solche, die man nicht nachschlagen darf. Insofern sollte die Bedingung für jedes neue tag sein, dass eine verständliche Erklärung und nachvollziehbare Aufschlüsselung offen vorliegt, ggf. als Verweis über das Wiki. Die Erlaubnis zum Einpflegen ist natürlich eine Voraussetzung, aber allein nicht ausreichend. Das sehe ich für tmc inzwischen genauso, allerdings sind die tags einmal drin. Da gab es auch schon einen Ansatz, über nur noch ein einzelnes tag die Zuordnung zu ermöglichen. IIRC sogar mit Erklärung. Allerings ist der tmc-Schlüssel der bei uns benutzten Daten IIRC offen verfügbar (nicht nachgeschlagen). Eine Ideologie sehe darin eigentlich nicht. Eher eine Art Benutzbarkeits-Bedingung. Zu Bedenken ist ferner, dass es innerhalb von OSM reichlich umstritten ist, unverständliche tags einzutragen. Ich sehe solche Einträge als nicht immer vermeidbar an, aber sie sollten wenigstens so verständlich wie möglich dokumentiert und so sparsam wie möglich eingeführt werden. Wenn die Bahnhofs-IDs international gültig sind, ist das schon mal ein gutes Argument. Und falls der Interessent mitliest: Solche Diskussionen sind bei uns völlig normal und kein Grund zur Sorge ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Adressbestände Köln nun als OpenData
Am 7. Juli 2013 09:11 schrieb Henning Scholland o...@aighes.de: Und wenn es nur ein Blick auf das Luftbild ist um zu schauen, ob da wirklich ein(e) Haus/Kirche/Lagerhalle ist. Ich wollte lediglich sagen, dass man den Daten grundsätzlich vertrauen sollte und nicht grundsätzlich in Frage stellen. Nichts desto trotz, gesundem Menschenverstand folgend macht man geeignete Probe von sich aus Stichproben auf Auffälligkeiten. Man muss sich ja eh jede Ecke des Import vor dem commit genau ansehen. D.h. alle spezielle NUTZUNGen auf existien / Plausibilität prüfen (Internet / vor Ort / auf eine noch zu prüfen Liste?), Hausnummern visuell checken, ob ein Gebäude auf dem Luftbild ist, oder nicht. Gruß Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Sonntag, den 07.07.2013, 17:43 +0200 schrieb Eckhart Wörner: Hallo Tirkon, Am Sonntag, 7. Juli 2013, 17:36:18 schrieb Tirkon: Nein! Ich zitiere: Dann zitiere ich auch nochmal: Nummern, deren Bedeutung unter Verschluss ist, hätten in OSM nichts zu suchen Ja und? Wo ist das Ideologie? Nachvollziehbarkeit durch den Mapper ist bei uns eins der obersten Gebote. Ich erinnere mich noch an die Diskussionen bezüglich OpenSeaMap, und da kann man die Dokumentation international genormt für jede Seekarte wirklich an fast jeder Hausecke bekommen. Eine ähnliche Diskussion gab es neulich über Farben, die auch problemlos nachschlagbar sind, aber einigen nicht verständlich genug waren. Es kann doch nicht sein, dass die Mapper jetzt die Anweisung bekommen Hier trägst du xx=y4mp35ql ein, und frage gefälligst nicht, was das heißen soll. Oder habe ich dich falsch verstanden? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Eckhart Wörner ewoer...@kde.org wrote: Hallo Tirkon, Am Sonntag, 7. Juli 2013, 17:36:18 schrieb Tirkon: Nein! Ich zitiere: Bitte nur einfügen, was mit unserer Lizenz kompatibel und frei verfügbar ist. Nachtrag: wenn dein Beitrag anders gemeint war als von mir interpretiert, entschuldige ich mich natürlich. Trotzdem bin ich der Meinung, dass solche Antworten einfach nur kontraproduktiv sind: wenn die erste Reaktion auf wir würden gerne was mit OSM machen nur DIE LIZENZ ist, dann läuft einiges schief. Genau aus diesem Grunde stand weiter oben im gleichen Beitrag zu lesen: Auf jeden Fall ist es zunächst einmal erfreulich, wenn OSM für die Nutzer der Fahrplanauskunft hilfreich sein könnte. Von daher vielen Dank für diese Initiative. :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am Sonntag, den 07.07.2013, 16:38 +0200 schrieb Peter Wendorff: Beides hat konsequenzen für bestimmte Nutzer, aber die Tags sind weder austauschbar noch beliebig zusammenzuführen. Das kann ja auch gerne beides getaggt werden. Nur hat sich der Divider aus irgend einem Grund nicht durchgesetzt. http://wiki.openstreetmap.org/wiki/Proposed_features/Divider steht seit 2008 auf Abandoned http://wiki.openstreetmap.org/wiki/Proposed_features/Divided_road seit 2012. Vielleicht kann man das Konzept des dividers mit dem barrier zusammenführen. Das ist im Moment aber nicht meine Baustelle. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 07.07.2013 17:28, schrieb Tirkon: Tobias Knerr o...@tobias-knerr.de wrote: Am 06.07.2013 15:46, schrieb Martin Koppenhoefer: Bisher ist glaube ich die vorherrschende Meinung, dass alles ausser Fahrbahnmarkierungen oder explizit überfahrbaren Grenzelementen (aus Kunststoff) als baulich getrennt gilt, also z.B. ein Grünstreifen oder ein Bordstein. Also ich sehe derzeit nur eine bauliche Trennung ab einer gewissen Breite (oder evtl. Höhe) als solche an. Trennungen im Zentimeterbereich wie die von dir genannten Kunststoffelemente, aber auch Bordsteine, zähle ich nicht dazu. Den Bordstein als nicht als bauliche Trennung zu behandeln hat auch deshalb eine gewisse Logik, weil er insbesondere für diejenigen Verkehrsteilnehmer, deren Bereich damit in erster Linie abgetrennt wird - nämlich Fußgänger - kein nennenswertes Hindernis ist. Insofern ist er durchaus auch explizit überfahrbar (oder vielleicht übergehbar). Genau hier kommen wir an einen der haarigen Punkte, den ich in der bisherigen Diskussion als schwammig bezeichnet habe. Der Grünstreifen wird beim Übergang vom Städtischen zum Ländlichen zum Pendant des Bordsteins. Will man von einen so getrennten Rad-/Fußweg aus die Straße überqueren, darf und muss der Streifen ebenso wie der Bordstein überwunden werden. Auch der Grünstreifen zwischen zwei Richtungsfahrbahnen darf von Fussgängern überwunden werden. Für den Autofahrer hingegen ist dieser Streifen in beiden Fällen tabu. Auf dem Grünstreifen können aber Straßenschilder, Straßenlampen, Plakatwände, Telefonzellen (jedenfalls zwischen Fußweg und Straße) Blitzeranlagen und vieles mehr stehen, insofern ist der Grünstreifen fürs Mappen als Tag IMHO ungeeignet. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo, On 07.07.2013 18:00, Wolfgang Hinsch wrote: Was mich an der Aussage von Tirkon überzeugt ist die Überprüfbarkeit oder Nachschlagbarkeit durch den Mapper. Es kann nicht sein, dass sich hier immer mehr tags einschleichen, die niemand mehr nachvollziehen kann und schon gar nicht solche, die man nicht nachschlagen darf. Das war auch mein Gedanke. Ueber die Lizenz mach ich mir nicht so die Gedanken, aber wenn irgendwo an einem Bahnsteig das Tag hurzelbrumpf_ref_id_code=234:119:abcd-29 ist, dann stellen sich dem Mapper natuerlich die Fragen: * bringt mir das was? * wie kann ich pruefen, ob das richtig ist? * wenn ich nebendran ein aehnliches Objekt mappe, bekommt das dann die gleiche Nummer, oder wie finde ich raus, welche Nummer es bekomt? * wenn ich ein so getaggtes Objekt verschiebe oder splitte oder mit einem anderen zusammenfuege, was geschieht dann mit der Nummer? All diese Probleme gibt es mit TMC bereits, aber das heisst ja nicht, dass wir davon noch beliebig viele weitere haben wollen. Insofern sollte die Bedingung für jedes neue tag sein, dass eine verständliche Erklärung und nachvollziehbare Aufschlüsselung offen vorliegt, ggf. als Verweis über das Wiki. Die Erlaubnis zum Einpflegen ist natürlich eine Voraussetzung, aber allein nicht ausreichend. Sagen wir: Ein Tag sollte den Mapper nicht entmuendigen. Ein Tag, das ausstrahlt: das hier lieber nicht anfassen, davon verstehst Du nichts koennen wir nicht brauchen und wollen wir nicht haben. Wenn die Sache irgendwo ausreichend dokumentiert ist, sieht es anders aus (obwohl ein *ideales* Tag auch ohne Dokumentation zumindest soweit verstehbar ist, dass der Mapper entscheiden kann, wann er es belassen und wann er es aendern muss). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 7. Juli 2013 17:43 schrieb Eckhart Wörner ewoer...@kde.org: Dann zitiere ich auch nochmal: Nummern, deren Bedeutung unter Verschluss ist, hätten in OSM nichts zu suchen Das halte ich für einen wichtigen Satz, den ich gut unterschreiben kann. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 06.07.2013 15:12, schrieb fly: Am 06.07.2013 14:56, schrieb Tirkon: Martin Koppenhoefer dieterdre...@gmail.com wrote: Worum es im Prinzip geht ist, den Unterschied zwischen physisch unmöglich und lediglich verboten aber theoretisch möglich festzuhalten (hinsichtlich eines U-Turns z.B.) Mir ist schon klar, worum es geht. Es ist aber beispielsweise zweifelhaft, wo physikalisch unmöglich anfängt. Ein Grünstreifen läßt sich problemlos überfahren oder überlaufen. Dennoch reicht ein solcher aus, um Rad- und Fußwege getrennt zu mappen. Die meisten Fußgänger kommen auch über eine Leitplanke. Beispielsweise die im Thread erwähnte Bordsteinkante wird hierzuort regelmässig von Traktoren überfahren - zigmal am Tag. Von daher sähe ich den Trenner besser im expliziten Mapping mit entsprechenden Tags aufgehoben. Dann kann jede Anwendung selbst darüber entscheiden, welche Trenner sie wie bewerten möchte. Aber genau darum geht es doch: Bordsteine, Leitplanken, Grünstreifen sind alles bauliche Trennungen und keine Linien oder Plastik-Hütchen oder -Streifen. Dass mich das ganze mit nem BMX/Fun-Bike eher herausfordert und nicht trennt ist eine andere Sache. Damit wäre auch gleichzeitig das im Thread aufgeworfene Problem gelöst, dass die Art der Trennung in verschiedenen Staaten zu einer unterschiedlichen Definition von Fahrbahn führen könnte. Was mich in diesem Zusammenhang stört sind vier- und mehrspurige Strassen bei denen verkehrlich die liniengetrennte Bauform der baulichgetrennten Bauform in nichts nachsteht. Insbesondere wenn die baulich getrennte Doppelspur nur zu Hauptverkerhszeiten zur Verfügung steht weil nur dann ein zeitlich begrenztes Halterbot für eine nicht zugeparkte rechte Spur sorgt. Bei festhalten an baulicher Trennung fürs Tagen als getrennte Ways für die Richtungsfahrbahnen wird somit dann die schlechtere Strasse besser dargestellt und umgekehrt. Klar kann man jetzt dem Renderer die Schuld geben, aber anwenderfreundlich ist das nicht... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tourism = viewpoint?
On 07.07.2013 15:18, fly wrote: Am 07.07.2013 15:13, schrieb Martin Koppenhoefer: 2013/7/7 Sven Geggus li...@fuchsschwanzdomain.de --schnipp-- Ergebnis der Adresssuche: 1. Aussichtspunkt Mount Everest, Tingri County, Shigatse Prefecture, Autonomes Gebiet Tibet, Volksrepublik China --schnapp-- Also Leute ehrlich. Wie kann man nur auf die völlig bescheuerte Idee kommen 8000er Gipfel als tourism = viewpoint zu taggen? Letztens hatte ich Namen von Berggipfeln eines Imports von 2007 überarbeitet¹ und dabei auch einige Gipfel mit tourism=viewpoint gefunden (und letzteres entfernt). wieso nicht? Sind nicht die Bergsteiger z.T. Touristen? Andere Touristen kommen da auch nicht in die Nähe... +1 Soviel ich weiß gibt mensch mit viewpoint an, dass mensch von dort eine Aussicht genießen kann. Zum Teil wird auch noch die Richtung angegeben. Auf dem Mount Everest sind doch nur Touristen. Ich würde ja eher angeben, wenn auf einem Berg /keine/ (vom wetterunabhängige) Aussicht möglich ist. Der gesunde Menschenverstand dürfte von allein darauf kommen, dass es auf einem Berggipfel Aussicht gibt. Einen natural=peak mit tourism=viewpoint zu versehen halte ich für genauso sinnvoll wie highway=footway mit foot=yes (derzeit 422.454mal vorhanden) Thomas ¹ http://www.openstreetmap.org/browse/changeset/1987 ff ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bauliche Trennung
Am 07.07.2013 um 15:40 schrieb Tobias Knerr o...@tobias-knerr.de: Den Bordstein als nicht als bauliche Trennung zu behandeln hat auch deshalb eine gewisse Logik, weil er insbesondere für diejenigen Verkehrsteilnehmer, deren Bereich damit in erster Linie abgetrennt wird - nämlich Fußgänger - kein nennenswertes Hindernis ist. Insofern ist er durchaus auch explizit überfahrbar (oder vielleicht übergehbar). Bei Bordsteinen kommt es drauf an, wenn er den Fußweg abtrennt mappe ich das auch noch nicht mit eigener Geometrie, aber zwischen zwei Fahrbahnen ist mir das Grund genug, den Highway zu splitten. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tracy, Um die ganze Diskussion hier etwas abzukürzen: 1.: ja, macht es! Verbessertes Routing an Bahnhöfen und eine eindeutige Zuordnung wäre eine tolle Sache, auch für andere Anwendungen. 2.: um die Hilfe der OSM-Community zu erhalten, tut folgendes: sorgt einfach dafür, dass eure Quelldaten irgendwo frei zugänglich sind, damit die Mapper sie genau so prüfen (und damit pflegen) können wie amtliche Gemeindeschlüssel oder Postleitzahlen. 3.: Ein Änderungs-Verbot kann es bei OSM nicht geben, aber es dürfte einfach sein, bei jedem Import der Daten in das System des Verkehrsverbunds selbst eine Prüfung auf verdächtige Änderungen vorzunehmen. 4.: Zum Namen des tags: prüft doch einmal, ob es nicht sinnvoll wäre, die einzelnen ids getrennt zu taggen, z.B. bei Plattformen nur die Haltestellennummer und PlattformNr als getrennte tags (einfacher verständlich), die LandkreisNr ergibt sich ja bereits aus dem Grenzpolygon. Damit hätte eure Anwendung auch alle Daten, die sie benötigt und fur die anderen Mapper wäre es einfacher. Vielleicht wäre es sinnvoll, die tag-findung auf die entsprechenden öpnv-Seiten im Wiki zu verlagern. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
