Re: [Talk-de] Vorschlag neuer Geometrie (relationen)-Typ: node-relation
On Thursday, 10 July 2014 15:41:03 +0200, Martin Koppenhoefer dieterdre...@gmail.com writes: Am 10. Juli 2014 14:55 schrieb Tobias Knerr o...@tobias-knerr.de: Dein Beispiel mit den Verkehrsschildern ist zudem nicht sinnvoll, da – wie bereits von anderen erwähnt – hier schon eine dokumentierte Lösung existiert: Semikolons. Da ist die Nutzung einer Relation keineswegs bequemer. Das Problem ergibt sich in der Tat nicht mit Objekten, die durch ein einziges tag beschrieben werden können, er ergibt sich aber, wenn man mehrere tags hat, die sich nicht auf alle sondern nur auf einen Teil der Objekte beziehen (z.B. Verkehrsschild und Tourismushinweiser am selben Mast, aber unterschiedlicher operator-tag, vermutlich gibt es bessere Beispiele, das Grundproblem sollte aber klar sein). Das Problem hat man immer, wenn ich mehrere Tags zur Beschreibung eines Objekts benoetige und diese Tags selbst noch einen inneren Zusammenhang haben. Beispielsweise hat man dies bei den Zusatzschildern von Verkehrszeichen wie ein allgemeines Geschwindigkeitsbeschraenkungsschild 120 und ein zweites mit 100, das nur von 22-6 Uhr gilt. Dies kann man alles irgendwie durch Ergaenzung des Tag-Keywords (also durch ein neues Keyword) ausdruecken oder durch eine Strukturierung des Tag-Wertes ... aber so richtig natuerlich ist das alles bei etwas komplizierteren Beschraenkungen nicht mehr. In GDF gibt es hierzu die Unterscheidung zwischen Simple Attributes und Composite Attributes. Dort wird einer Entitaet dann mehrere Attribute zugewiesen, die wiederum entweder einzelne Simple-Attributes sind oder die jeweils ein Composite-Attribute bestehend aus einigen Simple-Attributes sind. Mit so etwas wie taggroup (oder tagset) als Strukturierung der bisherigen flachen Tag-Menge zu einem Objekt koennte man dies deutlich einfacher handhaben: way id=... nd ref=... nd ref=... taggroup tag k=maxspeed v=120 /taggroup taggroup tag k=maxspeed v=80 tag k=time v=22:00-06:00 tag k=vehicle_type v=hgv /taggroup /way statt wie bisher dies in den Tag-Keys und Tag-Values zu kodieren, also maxspeed=120 maxspeed:conditional:hgv=80 @ (22:00-06:00) oder so aehnlich. Taggroups, die nur aus einem Tag bestehen, kann man wie bisher ohne die taggroup schreiben - das waere gleichzeitig der Weg um das Protokoll aufwaertskompatibel zu halten. Der Vorschlag deckt aber nur ab die Eigenschaft _eines_ Objekts zu beschreiben und nicht die Eigenschaften zweier Objekte ... Das ebenfalls genannte Beispiel, dass ein Objekt an einem Baum (oder einem Mast, einer Mauer, ...) befestigt ist, deckt deine Relation hingegen gar nicht zufriedenstellend ab – dafür bräuchte man eher eine befestigt an-Relation mit entsprechender Semantik. Dass beides am selben Mast hängt, könnte man z.B. dadurch mappen, dass der node man_made=pole bekommt, und alles was dran hängt dann über die Relation angehängt wird. Z.B. auch Ampeln, an denen Verkehrsschilder hängen (bzw. hängt Ampel und Schild am selben Mast). Ggf. ist die Relation hier noch nicht ausreichend spezifiziert/definiert. ... wenn man naemlich genauer hinsieht, redet ihr von zwei unterschiedlichen Dingen: 1. Wollte ihr die semantische Bedeutung, also eher die Auswirkung von Verkehrschildern, Ampeln etc. beschreiben, die sich auf die jeweilige Kreuzung bzw. die nachfolgende Strasse beziehen? Dann reicht die Repraesentation in einem Objekt (Kreuzung oder Strasse) und eine Menge von Attributen dieses Objekts aus. 2. Wollt ihr die Existenz von mehren Objekten und deren raeumliche Beziehung untereinander beschreiben? Dann benoetigt ihr auch wirklich mehrere Objekte mit eigenen Attributen und deren Beziehung (haengt an, ist oberhalb von) wird durch eine Relation mit weiteren Attributen der Relation beschrieben. In den meisten Faellen reicht 1. aus. Wenn man etwas detailreicher mappen will, geht es in Richtung 2., wobei ich bei den meisten Verkehrschildern auch die semantische Bedeutung auf die nachfolgende Strecke mit mappen wuerde, da nicht immer so eindeutig ableitbar ist, bspw. wie weit eine Geschwindigkeitsbeschraenkung wirklich gilt. Mauern sind wieder ein anderes Thema, die werden bisher (und wohl auch auf absehbare Zeit) als Linien gezeichnet, mit dem Problem, dass die Seiten nicht klar sind (kann man abstrahieren, indem man einen leichten Versatz mappt für das gehängte Punkt-objekt, und auf die Information verzichten, ob es an der Mauer hängt oder kurz davor an einer eigenen Befestigung, meist dürfte das nicht interessieren). Da jede Linie eine _Digitalisierungsrichtung_ aufweist und diese auch in OSM existiert, gibt es auch hier ein Vorwaerts/Rueckwaerts und ein Links/Rechts. Man kann also sehr wohl mappen, ob sich etwas links oder rechts von einer Linie befindet. Nur bei Punkten wird es schwieriger, aber auch hier koennte man einen Abstand und den Kompasswinkel (analog zum
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo zusammen, on Sunday, 13 October 2013 11:55:14 +0200, Manuel Reimer manuel.s...@nurfuerspam.de writes: On 10/12/2013 11:07 AM, rainerU wrote: Es geht mir um Strecken, die mit Radwegweisern [1] ausgeschildert sind, und zwar nur um solche, die nicht mit einer Nummer oder einem Namen versehen sind. Haben wir hier auch zu genüge. Soweit ich das mitbekommen habe, gab es da irgendeine Vorgabe, dass eine gewisse Anzahl solcher Wege ausgeschildert werden müssen. Ich weiß nicht ob das pro Landkreis beschlossen wurde. Auf jedem Fall sind diese Wegweiser nicht immer wirklich hilfreich. Weiterhin zeigen sie keine wirkliche Radroute an. Genausowenig wie ein Wegweiser auf einer Straße, auf dem steht Buxtehude 200km eine Route angibt. Er ist nur ein Hilfsmittel, bzw. Hinweis für den Autofahrer. +1 Fragen: - Soll wirklich jede per Wegweiser ausgewiesene Fahrradverbindung zu einer Route werden? - Wieso machen wir das nicht auch für per Wegweiser ausgewiesene Auto-Verbindungen (= befahrbare Strassen)? Manuel gibt hierfuer bereits die Antwort: Bei einer sauber gepflegten Karte kann ein mitegeführtes Navi den Job dieser grünen Radwegweiser übernehmen und oft auch übertreffen. Um eine Route zu finden, bedient man sich eines Navigationsgeraetes. Damit dieses auch wirklich eine sinnvolle/brauchbare/fahrbare Route findet, muessen die Kanten im Wegenetz sinnvoll attributiert sein (und Kanten-Kanten*-Beziehungen wie Abbiegegebote und -verbote vorhanden sein). Die Auto-Wegweiser an Straßen dienen beim Mappen als zusaetzliche Informationsquelle und koennen/sollen natuerlich auch in die Karte eingetragen werden (Attribut destination sign), damit diese in der Route/bei der Zielführung explizit erwähnt werden können (... rechts abbiegen Richtung XYZ-Stadt). Genau so sehe ich dies auch fuer Fahrrad-Wegweiser, d.h. die vom Wegweiser wegfuehrenden Kanten werden fahrrad-befahrbar attributiert und ueberprueft, ob es eine Verbindung bis zum angegebenen Ziel dadurch gibt. Was fuer die Fahrrad-Navigation jetzt noch sinnvoll waere, waere eine Abstufung der Wege, wie es aehnlich auch fuer die Strassen gibt (highway=motorway, trunk, primary, secondary, ...). Wobei es hier sinnvoller waere, ein Fahrradweg-Hierarchie-Attribut gesondert vom highway-Attribut zu fuehren. Indirekt hat man mit den Fahrrad-Routen mit den ncn-, lcn- etc.-Attributen schon so etwas, aber dies versagt IMHO auf unterer Verbindungsebene, weil es dort eben keine expliziten Routen gibt ... (Auf Autostraßen hat man mit den Autobahn- und Bundesstrassen- Relationen etwas aehnliches geschaffen wie diese Fahrrad-Routen. Und auch diese sind auf den unteren Strassenklassen immer weniger sinnvoll, obwohl man hier explizit Strassennummern auf Landes- (L...) und Landkreis-Ebene (K...) vorfindet.) Wenn schon eintragen, dann könnte ich noch am ehesten verstehen, wenn der Wegweiser an sich eingetragen wird. Eventuell so: http://wiki.openstreetmap.org/wiki/DE:Relation:destination_sign Und dann wäre da noch: http://wiki.openstreetmap.org/wiki/Key:destination:sign +1 Gruss, Bernd ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag-Gruppen
Hallo, on Tuesday, 7 August 2012 21:14:16 +0200, André Riedel riedel.an...@gmail.com writes: Am 7. August 2012 17:25 schrieb Bernd Wurst be...@bwurst.org: Am 07.08.2012 14:59, schrieb André Riedel: Mit heutigen Mitteln und API 0.6 habe ich vorgeschlagen, einen durch | getrennten numerischen Prä- oder Suffix pro Gruppe zu verwenden. Bspw. highway = primary maxspeed = 100 1|restriction = hgv 1|maxspeed = 80 2|restriction = hgv 2|minweight = 12 2|maxspeed = 60 Das erscheint mir eine Idee mit Potenzial... Gleiches funktioniert auch wunderbar bei mehreren POI pro Knoten/Fläche (diesmal als Suffix ausgeführt) name = Backerei und Fleischerei Müller addr:street = Dorfstraße addr:number = 1 shop|1 = backery opening_hours|1 = 06:00-19:00 shop|2 = butcher opening_hours|2 = 09:00-19:00 ...das allerdings finde ich unlogisch. Also zunächst: Entweder Prä- oder Suffix. Beides zuzulassen ist doch irgendwie hausgemachtes Chaos. Das ist klar. Ich wollte nur beide Varianten darstellen, welche mir in der derzeitigen API vorschweben. Wobei man die Idee dann, wenn schon, RICHTIG weiterspinnen müsste: Wieso Tag-Gruppen nicht in der OSM-Datenbank und auf XML-Format-Ebene unterstützen, also beispielsweise aus der Präfix-/Suffix-Nomenklatur im Tag-Key gleich eine offizielle Tag-Gruppe machen: way id=... ... nd ref=... / nd ref=... / tag k=name v=Bäckerei und Fleischerei Müller / taggroup tag k=shop v=backery / tag k=opening_hours v=06:00-19:00 / /taggroup taggroup tag k=shop v=butcher / tag k=opening_hours v=09:00-19:00 / /taggroup /way Dasselbe kann man nun mit zeitlichen und transportmittel-abhängigen Verkehrsbeschraenkungen (50 für Lkw ab 3,5t und von 22-6 Uhr). DB-intern kann man alles als Tag-Gruppen ablegen. DB-extern werden Einzel-Tags beim Verarbeiten zu einer Tag-Gruppe mit nur einem Tag und beim Herauslesen kann eine Tag-Gruppe mit nur einem Tag dann auch vereinfacht dargestellt werden. Dadurch hat man ein einheitliches DB-Schema und gleich eine Möglichkeit zum Umstieg. Nachteil gegenüber der Suffix-/Präfix-Lösung: Die DB, die API und alle Tools müssen entsprechend umgestellt werden, bedeutet also nochmals viel Arbeit für wenige Personen durch die Umstellung. Vorteil gegenüber der Suffix-/Präfix-Lösung: Tags, die zusammen gehören, sind explizit zusammengefasst. Der Key eines Tags wird nicht mit noch mehr impliziter Bedeutung überfrachtet. Was mich hier aber wirklich stört ist, dass kein normales Tagging mehr dran ist, also ein einfacher Datenauswerter das nicht mehr wahrnehmen kann. Es sollte also IMHO so gestaltet sein, dass weiterhin das primäre Tagging ungeändert bestehen bleibt. Grade bei dem von dir genannten anderen Beispiel mit den highway- und bridge-Tags wird deutlich, dass ohne dieses System zu verstehen wirklich nichts auswertbares mehr an dem Element dran ist. Die Grenzen der Anwendung von Gruppen sollte man noch eingehender diskutieren. Genauso ob Gruppen kaskadierend angewendet werden dürfen oder ob es eine maximale Anzahl geben soll. Welche Beispiele für solche geschachtelten Gruppen gibt es denn? (Und das obige Beispiel eines Mehrfach-Shops innerhalb eines Gebäudes legt IMHO die Verwendung von Relationen schon eher nahe als dies noch mit tiefer geschachtelten Tag-Gruppen zu repräsentieren.) Grüße, Bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hilfe für Kartenaktualisierung 71083 Herrenberg gesucht
Hallo Joachim, hallo Bernd, es gibt eine OSM-Mailing-Liste fuer den Grossraum Stuttgart ... und da wuerde ich Herrenberg, da per (S-)Bahn leicht erreichbar, mit einschliessen. (Diese Antwort geht per CC gleich mal mit an die Liste.) On Sunday, 22 January 2012 08:43:30 +0100, Bernd Wurst be...@bwurst.org writes: [...] Am 21.01.2012 19:39, schrieb Joachim Wirth: Hier sieht man einen Plan, der die neue Verkehrsführung mit Parkplätzen und neuer Halle zeigt: http://www.andreae-gymnasium.de/webnotizen/wp-content/2011/05/Parken_Markwegschulzentrum.gif Zum Vergleich, siehe OSM 71083 Schießtäle (Markwegzentrum). Also hier: http://www.osm.org/?lat=48.592379lon=8.855888zoom=18layers=M Der Plan den du online gestellt hast, darf man den zum Abzeichnen benutzen? Waere natuerlich ideal, da sich dann schon vieles vorher machen laesst. Aber selbst dann bleiben noch Punkte, die man mit Ortskenntnissen weiss/vor Ort ueberpruefen sollte. Über Hilfsangebote würde ich mich sehr freuen! Selbstverständlich möchte ich selbst für diese Aktualisierungen beisteuern, was mir möglich ist. Letztlich muss man entweder von korrekten und lizenzrechtlich akzeptablen Karten Daten übertragen oder vor Ort mit einem GPS-Gerät die neuen Wege aufnehmen. Wenn die von dir gelieferte Karte benutzt werden darf, dann wäre das ohne Ortsbegehung zu machen. Kann ich gerne machen. Wenn nicht, sollte jemand vor Ort sein. Das kann ich nicht machen. :) ... und das waere ein guter Aufhaenger fuer eine lokale Mapping-Party! Also: Aufruf starten (auf den Mailing-Listen und im Wiki), guenstigen Termin festlegen (evtl. noch Ausweichtermin), lokaler Treffpunkt vereinbaren und dann kann es losgehen. Wenn man beim Treffpunkt gemuetlich zusammensitzen kann, noch eine Netzverbindung vorhanden ist, dann ist bereits am Ende der Mapping-Party die OSM-Karte aktualisiert und somit verwendbar. Viele Gruesse, Bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unechte Einbahnstraße
On Thursday, 15 July 2010 12:58:15 +0200, M∡rtin Koppenhoefer dieterdre...@gmail.com writes: Am 14. Juli 2010 13:46 schrieb Bernd Raichle be...@dante.de: der entsprechende Knoten ist da, wo das Schild ist, das ist nie die Mitte einer Kreuzung. Das sieht vielleicht ein bisschen nach Erbsenzählerei aus, aber man darf bis zum Schild durchaus fahren. Auch wenn das ganz am Anfang steht, so ist doch noch das Stück von der Mitte der Querstraße bis zum Schild nicht betroffen. -1 An einer Kreuzung sind _alle_ Schilder ein Stueck weit von der Kreuzung entfernt plaziert. ... ja eben Das Stueck weit resultiert aber aus rein praktischen Gesichtspunkten, da man eben schlecht das Teil direkt auf die Kreuzung plazieren kann ... Ausserdem stellt sich die Frage, wie lange denn dieses Mini-Stueck ist: verlaengerter Fahrbahn_rand_ der Querstrasse bis Schild oder, so wie ich es mache, Mitte der Kreuzung bis Schild? für mich ist das keine Frage: ab da wo das Schild steht wird auch getaggt. Ein Schild, das am Beginn einer Strasse steht, steht genau da: am Beginn der Strasse. Da die Strasse am Kreuzungsknoten beginnt, gilt es daher ab dem Kreuzungsknoten. ... und ich fuege _kein_ kuenstliches Mini-Strassenstueck ohne Beschraenkung zwischen Kreuzungsknoten und Rest-Strasse ein, um eine Genauigkeit vorzugaukeln, die unser einfaches Knoten-Kanten-Modell gar nicht hergibt. Erbsenzaehlen tue ich gerne da, wo es auch notwendig und sinnvoll ist, wo ich also wirklich ausdruecken will, dass es wichtig ist, dass ein kleines Stueck Weg andere Eigenschaften hat. Ansonsten muesste ich auch alle Speed-Bumps, Zebrastreifen etc. nicht mit einem einfachen Knoten, sondern mit einem Mini-Stueck Weg modellieren, da ja alles eine gewisse Ausdehnung aufweist. Bei einer breiteren Querstrasse bekomme ich also auch eine laengeres Mini-Stueck, auch wenn das Schild immer gleich weit in die Strasse hinein versetzt steht! ja klar, bei einer breiteren Querstraße (QS) ist das Schild weiter von der Straßenmitte der QS entfernt, das auch wenn verstehe ich nicht. ... auch wenn das Schild beispielsweise immer am Ende der Eckausrundung der Fahrbahnbegrenzung aufgestellt, also gleich weit in die Strasse hinein versetzt steht. Bei einer breiteren Querstrasse als auch bei einer groesseren Eckausrundung bekomme ich damit ein unterschiedlich weit vom zentralen Kreuzungsknoten entfernt stehendes Schild, obwohl dieses Schild immer am Beginn der Strasse steht. Daher lasse ich all die Attributierungen aus diesen Schildern _ab_ dem Kreuzungsknoten gelten, auch wenn sie einige Meter von der Kreuzung entfernt plaziert sind. das verstehe ich überhaupt nicht, hattest Du oben nicht selbst geschrieben, dass die Schilder nicht ab Mitte der Kreuzung gelten? Wieso willst Du das dann in den Daten so falsch drin haben? Für mich ist das keine logische Schlussfolgerung (daher...). Wir haben ein Knoten-Kanten-Modell, d.h. wir repraesentieren den 2-dimensionalen Strassenraum mit 1-dimensionalen Objekten. Daher gibt es immer irgendwo Vereinfachungen und Unstimmigkeiten zwischen Modell und Wirklichkeit und evtl. auch Unstimmigkeiten zwischen den Modellen bei verschiedenen Modellierern. Der Knoten repraesentiert die gesamte Kreuzungsflaeche und da ergibt sich schon das Problem, dass ein Knoten keine, die Kreuzung sehr wohl eine Ausdehnung hat. Bei der Kante ist es ebenso. Bezueglich des Einfahrt-verboten-Schildes sehe ich die Ausdehnung des Knotens die Eckausrundungen der abgehenden Strasse und eines kurzen Stummels einschliessen. Ich fuege daher keine Mini-Kante ein -- zumindest nicht fuer solch ein Schild. Du siehst das deutlich eingeschraenkter, wobei mir beispielsweise nicht klar wird, wo die Strasse nun bei einer Kreuzung fuer dich nun anfaengt (bzgl. des Schildes oder allgemein): - am Kreuzungsmittelpunkt, - am Schnittpunkt der verlaengerten Fahrbahnbegrenzungen der Querstrasse mit der Mittellinie der Strasse, - am Ende der Eckausrundung, - ... sonst wo ... Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unechte Einbahnstraße
On Tuesday, 13 July 2010 22:40:06 +0200, steffterra steffte...@me.com writes: Am 13.07.2010 um 21:07 schrieb M∡rtin Koppenhoefer: Am 13. Juli 2010 19:06 schrieb steffterra steffte...@me.com: [...] 2. Da der Knoten aber (z.B. im Mindest-Falle einer T-Kreuzung) auch Teil eines weiteren ways ist, +1 -1 der entsprechende Knoten ist da, wo das Schild ist, das ist nie die Mitte einer Kreuzung. Das sieht vielleicht ein bisschen nach Erbsenzählerei aus, aber man darf bis zum Schild durchaus fahren. Auch wenn das ganz am Anfang steht, so ist doch noch das Stück von der Mitte der Querstraße bis zum Schild nicht betroffen. +1 ok. ist korrekt udn schön, dass Du es erwähnst. Aber dann machts eben eine Relation von dem way vor dem Schild über den Knoten beim Schild zum way hinter dem Schild., oder? :-) Dann spart man sich sogar die anderen turn_restrictions für die anderen ways. -1 An einer Kreuzung sind _alle_ Schilder ein Stueck weit von der Kreuzung entfernt plaziert. Dies ist schon alleine dafuer notwendig, dass man als (Rechts-)Abbieger eine Chance haben muss, das Schild beim bzw. nach dem Abbiegevorgang, das ich dann rechts oben in der Windschutzscheibe sehe, auch sicher noch erkennen zu koennen. Waere es zu nahe an der Kreuzung, dann wird es leicht uebersehen. Alternativ muesste man beidseitig Schilder aufstellen. Ausserdem stellt sich die Frage, wie lange denn dieses Mini-Stueck ist: verlaengerter Fahrbahn_rand_ der Querstrasse bis Schild oder, so wie ich es mache, Mitte der Kreuzung bis Schild? Bei einer breiteren Querstrasse bekomme ich also auch eine laengeres Mini-Stueck, auch wenn das Schild immer gleich weit in die Strasse hinein versetzt steht! Daher lasse ich all die Attributierungen aus diesen Schildern _ab_ dem Kreuzungsknoten gelten, auch wenn sie einige Meter von der Kreuzung entfernt plaziert sind. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unechte Einbahnstraße
On Tuesday, 13 July 2010 13:32:51 +0200, Martin Simon grenzde...@gmail.com writes: Am 13. Juli 2010 00:58 schrieb Dimitri Junker o...@dimitri-junker.de: Hallo, Man könnte ja auch eine Turn-Restriction restriction=no_entry einführen, allerdings müßte dann als from eine node akzeptiert werden, bisher scheint nur way vorgesehen zu sein. Man könnte auch einfach das Mitglied from weglassen, dann hätte man mit nicht (von angrenzenden Ways aus) über diesen Node(via) auf diesen Way(to) genau die Aussage, die der Realität entspricht(dieses Zeichen darf in diese Richtung nicht überfahren werden.). Ein Router kann dann einfach die Einfahrt von sämtlichen anderen Ways, die über den via Node laufen, auf den to Way untersagen. Mmmh, fuer die unechten Einbahnstrassen reicht doch sogar ein einfaches Attribut auf dem Way aus, wenn dieses abhaengig von der Fahrtrichtung angegeben wuerde. Beispiel mit einem fiktiven Tag blocked: blocked:forward = at_begin ... keine Einfahrt in den Weg am ersten Knoten blocked:backward = at_end ... keine Einfahrt in den Weg am letzten Knoten blocked:forward = at_end ... keine Ausfahrt aus dem Weg am letzten Knoten blocked:backward = at_begin ... keine Ausfahrt aus dem Weg am ersten Knoten Beim Umdrehen des Weges muesste man :forward - :backward _und_ die Werte at_begin - at_end austauschen, damit es wieder stimmt. Aus dem Grund habe ich es nicht eingesetzt. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgehende Mittellinie
On Tuesday, 13 July 2010 16:35:15 +0200, M∡rtin Koppenhoefer dieterdre...@gmail.com writes: Am 13. Juli 2010 02:27 schrieb Tirkon tirko...@yahoo.de: Eine durchgehende Mittellinie wird derzeit mit Heerscharen von Abbiegeverboten umschrieben, die in der Realität nicht als Schilder existieren. Man könnte eine durchgehende Mittellinie als Relation implementieren. Dort wo die Linie an Kreuzungen oder Abzweigungen durchgeht, wird der Knotenpunkt in die Relation einbezogen, ansonsten bleibt er draußen. das mit den Knoten halte ich nicht für sinnvoll/möglich. Man wird mit dieser Relation die Ways dann jedesmal splitten müssen, wenn die Linie unterbrochen ist. Das führt dazu, dass man es gleich mit einem Tag machen kann und keine Relation mehr braucht. Das mit dem Tag (bspw. divider=solid_line) ist nur gut, solange der Way ueber mehrere Kreuzungen geht. Sobald man den Way aber an jeder Kreuzung auftrennt (auftrennen muss), fehlt die Information, dass die Fahrstreifenbegrenzungslinie _ueber_ die Kreuzung hinweg geht. Und genau fuer diesen Fall (der eher haeufiger vorkommen wird, da Wege bspw. fuer Buslinien etc. aufgetrennt werden) ist eine Relation Way1-Node-Way2 der einzige Weg, dies eindeutig festzulegen. Alternativ wäre es auch möglich, die beiden Spuren getrennt zu mappen und die Art der Verbindung/Trennung (unterbrochene Mittellinie, durchgezogene Mittell.) in die Relation aufzunehmen (area-Relation). Je nach Situation ist das Overkill oder sinnvoll. Bei getrennten Ways pro Richtungsfahrbahn sehe ich immer das Problem, dass man bei jeder Abbiegemoeglichkeit (bspw. Supermarktparkplatz oder auch Fussgaengerueberwege!) auch daran denken muss, eine Dummy- Querkante zwischen den Fahrbahnen einzufuegen. Ansonsten haben bspw. Router an dieser Stelle ihre Probleme. Und dann: Wann hoere ich auf mit den einzelnen parallelen Ways? Jede einzelne Spur, auch Fahrradstreifen, Gehweg? (Siehe Diskussionen zu Linienbuendel) Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unechte Einbahnstraße
On Tuesday, 13 July 2010 16:48:40 +0200, M∡rtin Koppenhoefer dieterdre...@gmail.com writes: Am 13. Juli 2010 15:53 schrieb Bernd Raichle be...@dante.de: Mmmh, fuer die unechten Einbahnstrassen reicht doch sogar ein einfaches Attribut auf dem Way aus, wenn dieses abhaengig von der Fahrtrichtung angegeben wuerde. Beispiel mit einem fiktiven Tag blocked: blocked würde ich nicht nehmen, ist ja nicht blockiert sondern nur verboten. Jupp, deswegen auch der Zusatz fiktiv :-) blocked:forward = at_begin ... keine Einfahrt in den Weg am ersten Knoten blocked:backward = at_end ... keine Einfahrt in den Weg am letzten Knoten blocked:forward = at_end ... keine Ausfahrt aus dem Weg am letzten Knoten blocked:backward = at_begin ... keine Ausfahrt aus dem Weg am ersten Knoten Beim Umdrehen des Weges muesste man :forward - :backward _und_ die Werte at_begin - at_end austauschen, damit es wieder stimmt. Aus dem Grund habe ich es nicht eingesetzt. das würde halt für _einen_ Spezialfall eine Lösung bereitstellen, die die Anpassung aller Tools und Router erfordert, ausserdem durch Anfang/Ende und Richtung extrem fragil. Würde ich nicht empfehlen, obwohl es prinzipiell funktionieren könnte. Vom Prinzip her will ich einfache Dinge auch mit einfachen Mitteln abbilden koennen. Das einfachste Mittel in OSM ist ein Tag und eben keine Relation. Das Zeichen 267 Verbot der Einfahrt an einem Ende einer unechten Einbahnstrasse bezieht sich auf genau dieses Strassenstueck, es steht an einem Ende und sagt aus, dass man in die eine Richtung eben nicht an dieser Stelle einfahren darf. Fuer mich ist dies daher eine Attributierung des Ways (= Tag), das fuer eine bestimmte Richtung gilt (= :forward oder :backward), am Anfang oder Ende steht (daher der Wert des Tags). Diese Spezialloesung wuerde ich fuer alle anderen aehnlichen Zeichen auch anwenden, wenn es sich nur auf ein Strassenstueck bezieht. Mir fallen da bspw. Zeichen 272 Verbot des Wendens ein, aber auch 205 Vorfahrt gewaehren oder Stop-Schild 206 ein, die sich so auch ohne Relation abbilden liessen. Die notwendige Anpassung der Tools ist das einzige Knock-out- Kriterium, aber das war es ehemals auch fuer :forward, :backward, :left und :right. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kategorien-Sprach-Chaos im Wiki
On Sunday, 27 September 2009 23:07:16 +0200, Martin Koppenhoefer dieterdre...@gmail.com writes: Am 27. September 2009 22:16 schrieb Thomas Ineichen osm.mailingl...@t-i.ch: erstellt, manche Seiten sind in mehreren Kategorien. Koennen wir uns bitte auf _eine_ Sprache einigen? (Plural hat offenbar ggue. Singular bereits gewonnen.) ich waere fuer Deutsch, falls noch andere Sprachen in dem Gebiet offiziell sind (ich denke da z.B. an die Sorben, etc.) wird es evtl. ein bisschen schwieriger, aber allgemein kann man sich fuer das deutsche Staatsgebiet m.E. relativ problemlos auf deutsch einigen, weil alles andere schon ziemlich in der Minderheit ist, und diese i.d.R. auch Deutsch ganz gut verstehen. Prinzipiell ist Deutsch zwar gut, aber das Places-Template ist bislang nicht multi-lingual, d.h. die festen Anteile (city/cities, municipality/municipalities etc.) sind auf Englisch. Und dieses Template ist auch der Grund, wieso der Plural gegenueber dem Singular gewonnen hat, da dieses aus dem type=city die Kategorie Cities in ... bildet. Und der Wildwuchs mit englischen und/oder deutschen Namen ist nicht nur auf Nordrhein-Westfalen beschraenkt, sondern betrifft (fast) alle Bundeslaender. Einige haben halt die deutschen Namen verwendet und andere die Namen, die in der (englischen) Wikipedia zu finden sind. Ich habe vor einiger Zeit, als ich am Places-Template einige kleinere Aenderungen durchgefuehrt habe, auch ein paar Dinge in meinen Gebieten staerker zu vereinheitlichen, habe mich aber an die grossen Aenderungen nicht rangetraut. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] access=destination valid only in one direction
On Friday, 10 July 2009 15:03:32 +0100, Peter Childs pchi...@bcs.org writes: 2009/7/10 Stanislav Brabec u...@penguin.cz: Hallo. Is there a way how to map a street with access=destination valid just only for one direction? In the reverse direction it is a standard drive through street. http://www.openstreetmap.org/browse/way/30764132 The standard way to do this is with a second parallel way tagged accordingly, Like a dual carriageway. ... only if it is a dual carriageway! If it is a single carriageway without physical divider etc., only _one_ way is mapped. In this case I tag a direction depending attribute with an additional :forward resp. :backward in the key: key:forward=... key:backward=... For example, a way with maxspeed=100 and maxspeed:forward=70 is a street with a speed limit of 100 km/h in one, and 70 km/h in the other direction. Forward and backward is given in the direction the way is drawn, and these tag additions are reversed by newer version of JOSM, if the way is reversed. Best wishes, -bernd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] DXF-Datei Gemeindegrenze - OSM
On Wednesday, 24 June 2009 23:56:30 +0200, Mirko webmas...@ts-eastrail.de writes: Ich habe auch keine Information darueber, ob die Grenze in der Mitte der Strasse verlaeuuft, an einer Strassenkante, oder etwas neben der Strasse. Die 1-8 Meter machen den Kohl auch nicht dicker. Wenn man es auswerten will schon. Es macht schon einen Unterschied ob die Strasse zu Gemeinde A, B oder jeweils zur Haelfte zu beiden gehoert. Was hindert dich daran, die Zugehoerigkeit der Strasse bzw. eines Teiles davon _explizit_ beim Way zu taggen? Wenn man schon sicher weiss, dass ein Stueck Strasse die Grenze zweier Gemeinden bildet, dann kann man dies gerne zusaetzlich angeben. Diese Redundanz hat den Vorteil, dass das exakte Wissen bzgl. des Strassenstuecks/ Flusses/... in den Daten enthalten ist und dass man testen kann, wo Diskrepanzen zu vorhandenen Gemeindegrenzen vorhanden sind, beispielsweise weil jemand die Strasse oder die Grenze veraendert/ verschoben/... hat. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
On Thursday, 25 June 2009 06:16:55 +0200, Marcus Wolschon mar...@wolschon.biz writes: 2009/6/24 Bernd Raichle be...@dante.de: On Wednesday, 24 June 2009 14:44:23 +0200, marcus.wolsc...@googlemail.com marcus.wolsc...@googlemail.com writes: On Wed, 24 Jun 2009 12:50:37 +0200, Claudius claudiu...@gmx.de wrote: Am 24.06.2009 12:25, marcus.wolsc...@googlemail.com: Du sagst also, dass wir die fuer die Router einfachere Taggingvariante verwenden sollen? Ist die Unterstuetzung fuer Abbiegerelationen denn so schwer? Ja ist es. Denn das sind Einschraenkungen/Kosten-Funktionen an Knoten statt Kanten was die meisten Routing-Algorithmen incl. den beliebten Dijstra und A* nicht vorsehen. Ist es das wirklich? (Ich meine die _schwere_ Unterstuetzung ... wegen Knoten statt Kanten ...) Wenn man Durchfahrtsbeschraenkungen (wie Einbahnstrasse etc.; fuer eine Kante geltend) und Abbiegerelationen (wie Linksabbiegen verboten, nur geradeaus etc.; fuer eine Kantenfolge mit 2 und mehr Kanten geltend) als Kosten umsetzt, gebe ich dir recht. Diese Dinge sind aber _harte_ Ausschlusskriterien, d.h. im Dijkstra sorgen die Durchfahrtsbeschraenkungen und Abbiegerelationen schon beim Erweitern des Suchbaums, dass ich diese und jene Kante gar nicht erst als Folgekante in Betracht ziehe (a la Gewicht=unendlich). Damit bleibe ich doch weiterhin kanten-orientiert und verwende die Knoten nur dazu herauszufinden, welche Kante mit welche verbunden ist. Du hast Dijkstra nicht verstanden. Ich habe Dijkstra sehr wohl verstanden ... und mehr als einmal implementiert. Zu jedem spaeteren Zeitpunkt kannst du eine guenstigere Route bis zum Knoten finden. Dann kommst du aber nachtraeglich aus einer anderen Richtung in die Kreuzung rein. Klar, ist so. Und damit das eine verboten und das andere erlaubt ist, darf man nicht die einzelne Kante ansehen, sondern eine Folge von 2 und mehr Kanten (bei komplizierteren Kreuzungen mit getrennt gemappten Richtungsfahrbahnen und kleinen Verbindungszwischenkanten kommt man fuer einen verbotenen U-Turn leicht auf mindestens 3 Kanten). Die verbotenenen Kantenfolgen abzulegen und bei der Auswahl der moeglichen Folgekanten im Dijkstra zu nutzen ist zwar aufwendig, aber doch nicht so schwer zu implementieren. [...] Mal abgesehen davon: Was wuerde es denn dem Router bringen, wenn ich den gemeinsamen Abschnitt der Autobahnauf-/abfahrt mit oneway=no taggen wuerde. Er koennte doch immer noch von der Abfahrt auf die Auffahrt routen. Mein Beispiel war von der Autobahn in die Auffahrt, zurueck bis zur Abfahrt und dort wieder auf die Autobahn. Das ist ein ganz anderer Fall. ... dann doch lieber ein paar zusaetzliche oneway=yes spendieren, bevor man solch ein Routing-Ergebnis erhaelt ;-) Es steht dir frei das jederzeit auch explizit zu taggen. Solange es nicht kompliziert ist, tagge ich Dinge mittlerweile lieber explizit. Jede Redundanz in den Daten sorgt dafuer, dass Fehler (wie falsche Richtungen etc.) angemeckert und somit gefunden werden koennen. Die uralte Diskussion war, dass eine Autobahn-Ausfahrt immer implizit oneway=yes ist weil eben alle oder die meisten Ways davon Einbahnstrassen sind. immer alle oder die meisten ... zeigt doch schon, dass ich doch lieber beim expliziten Taggen von so einfachen Dingen bleibe :-). (Wobei man bei deinem beschriebenen Beispiel dieselbe Kante in derselben Richtung mehrfach befaehrt, was fast immer unsinnig ist und nur bei komplizierteren Abbiegebeschraenkungen vorkommen duerfte.) Das wuerde jedes Mal passieren, wenn man einfach seine Ausfahrt verpasst ohne das implizite oder explizite oneway=yes auf der Ausfahrt/Einfahrt. Bei einer Routenberechnung _vor_ der Fahrt duerfte dieses Ergebnis nicht berechnet werden, da die Gesamtkosten bei so einem Schlenker schlechter sind als bei einer korrekten Ausfahrt. Bei einer Routenfuehreung _wahrend_ der Fahrt ist solch ein Ergebnis nach einem Re-Routing natuerlich moeglich :-) Schon vor einiger Zeit gab es die Idee, die link-Kanten zu ueberpruefen, indem man die Richtung und evtl. vorhandene oneway-Tags mit den Ausfahrts-/Auffahrts-Winkel auf die jeweiligen Autobahn-Kanten vergleicht. Zu grosse Winkel oder falsche Richtungen sind Anzeichen, dass da korrigiert werden muss. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
On Wednesday, 24 June 2009 14:44:23 +0200, marcus.wolsc...@googlemail.com marcus.wolsc...@googlemail.com writes: On Wed, 24 Jun 2009 12:50:37 +0200, Claudius claudiu...@gmx.de wrote: Am 24.06.2009 12:25, marcus.wolsc...@googlemail.com: Du sagst also, dass wir die fuer die Router einfachere Taggingvariante verwenden sollen? Ist die Unterstuetzung fuer Abbiegerelationen denn so schwer? Ja ist es. Denn das sind Einschraenkungen/Kosten-Funktionen an Knoten statt Kanten was die meisten Routing-Algorithmen incl. den beliebten Dijstra und A* nicht vorsehen. Ist es das wirklich? (Ich meine die _schwere_ Unterstuetzung ... wegen Knoten statt Kanten ...) Wenn man Durchfahrtsbeschraenkungen (wie Einbahnstrasse etc.; fuer eine Kante geltend) und Abbiegerelationen (wie Linksabbiegen verboten, nur geradeaus etc.; fuer eine Kantenfolge mit 2 und mehr Kanten geltend) als Kosten umsetzt, gebe ich dir recht. Diese Dinge sind aber _harte_ Ausschlusskriterien, d.h. im Dijkstra sorgen die Durchfahrtsbeschraenkungen und Abbiegerelationen schon beim Erweitern des Suchbaums, dass ich diese und jene Kante gar nicht erst als Folgekante in Betracht ziehe (a la Gewicht=unendlich). Damit bleibe ich doch weiterhin kanten-orientiert und verwende die Knoten nur dazu herauszufinden, welche Kante mit welche verbunden ist. Bei Abbiegerelationen hat ein Router halt das Problem, dass sich diese auf eine Kantenfolge beziehen, d.h. ich nicht einfach nur die Eigenschaften einer einzelne Kante anschauen kann, um die Kante auszuschliessen (bzw. zu bewerten). Und das Nachschlagen/Mitfuehren von erlaubten/verbotenen Kantenfolgen erhoeht den Aufwand schon deutlich (ist aber nicht schwer). Daher sollten Mapper eine Kante mit oneway=yes/1/-1 auf keinen Fall durch die aequivalente Darstellung mit einer Menge von Abbiegebeschraenkungen von anderen Kanten in diese Kante ersetzen. Mal abgesehen davon: Was wuerde es denn dem Router bringen, wenn ich den gemeinsamen Abschnitt der Autobahnauf-/abfahrt mit oneway=no taggen wuerde. Er koennte doch immer noch von der Abfahrt auf die Auffahrt routen. Mein Beispiel war von der Autobahn in die Auffahrt, zurueck bis zur Abfahrt und dort wieder auf die Autobahn. Das ist ein ganz anderer Fall. ... dann doch lieber ein paar zusaetzliche oneway=yes spendieren, bevor man solch ein Routing-Ergebnis erhaelt ;-) (Wobei man bei deinem beschriebenen Beispiel dieselbe Kante in derselben Richtung mehrfach befaehrt, was fast immer unsinnig ist und nur bei komplizierteren Abbiegebeschraenkungen vorkommen duerfte.) Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weg vom Way, hin zur Nodes-Relation
On Monday, 22 June 2009 12:26:57 +0200, Frederik Ramm frede...@remote.org writes: Andreas Pothe wrote: Ich denke, man koennte es noch wuppen, da mit der API 0.6 alle Basisvoraussetzungen vorhanden sind, die wir braeuchten. Man muesste sich lediglich darauf einigen, dass man keine Ways mehr in die Relationen packt, sondern nur noch Nodes. Die Verbindung dieser Nodes wird dann ueber die Wegteile, die dazwischenliegen, automatisch vorgenommen. Alternativ koennte man auch den GDF-Ansatz waehlen: Knoten werden unterschieden in Verbindungs- bzw. Kreuzungsknoten und inneren Wege-Knoten (sog. Shape node). Wege gehen nur von einem Anfangs- ueber null oder mehr innere Knoten zu einem Endknoten, d.h. nur von Kreuzung zu Kreuzung. Aendert sich auf einem Wegestueck ein Attribut, so wird der Weg an dieser Stelle aufgeteilt. Ausserdem hat ein Weg eine _Richtung_, die sogenannte Digitalisierungsrichtung, so dass man sich bei allen richtungsabhaengigenn Attributen (und Relationen) auf diese beziehen kann. Du meinst sowas wie das hier: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Segmented_Tag Das gabs sogar schon vor API 0.6. Der Vorschlag stammt von mir und versucht mehrere Probleme oder Anforderungen zu loesen: 1. Ein Weg hat keine Richtung bzw. man soll die Richtung nicht verwenden, da sich u.a. beim Zusammenfuegen mehrerer Wege zu einem Weg die Richtung veraendert werden kann und die Editoren dies (damals) nicht korrigiert haben. Daher kann man mit dem Vorschlag durch explizite Angabe eines Anfangs- und eines Endknotens eine Richtung mitgeben, die sich auch beim Umdrehen des Ways nicht aendert. Mittlerweile kann JOSM richtungsabhaengige Attribute (bspw. key:left=value) mit umdrehen (= key:right=value), so dass dieses Problem nicht mehr vorhanden sein sollte ... oder? 2. Ein Attribut laesst sich nicht fuer einen Wegteil angeben. Will man wegen Bruecken, Tunnel etc. Wege nicht aufsplitten, muss man den Anfang und das Ende der Attributgueltigkeit mitgeben. 3. Eine Attribut-Menge, die zusammengehoert, kann nur einmal an einen Weg gehaengt werden. Bsp: maxspeed=100 fuer Pkw, maxspeed=80 fuer Pkw von 22:00 bis 6:00 Uhr, maxspeed=60 fuer Lkw kann man nicht so einfach taggen. Bislang geht dies nur mit maxspeed=100 direkt an den Weg und zwei Relationen an den Weg mit beispielsweise in der 1. Relation maxspeed=80, validity_period=22.00-06.00 und in der 2. Relation maxspeed=60, vehicle_type=hgv, wofuer man auch diese Segmented_Tag verwenden kann. Alternativ gibt es auch Vorschlaege a la maxspeed[22.00-06.00]=80 und maxspeed[hgv]=60, die sich meist auf Gewichts-, Hoehen- und Zeitbeschraenkungen beziehen. Ein vielleicht besserer Weg (fuer API 0.7) waere das, was in GDF als Composite Attributes verfuegbar ist, also aus mehreren Attributen zusammengesetzte Attribute. Wenn man in der API Tags mehrfach verwenden koennte (was prinzipiell jetzt schon moeglich ist) und diese auch explizit gruppieren koennte (dies ist nicht oder nur ueber Klimmzuege moeglich), waere vielleicht fuer diese Dinge ein einfaches Tagging-Schema festlegbar? Eine Umstellung des bisherigen Schemas waere gar nicht so aufwaendig, wenn ich sehe, wie viele Robots schon herumschwirren, duerfte sich sicherlich jemand finden, der auch hierfuer einen Robot schreibt. Robots schreiben ist der einfache Teil. 100.000 Nutzer gleichzeitig umzuerziehen und die Editoren und Renderer anzupassen, waere der schwierigere Teil. Zur Umstellung benoetigt man keinen Robot, das wuerde und muesste wie bei der letzten Umstellung von 0.5 auf 0.6 auf dem Server erfolgen. Das Hauptproblem sind die Nutzer, denn ein Normal-Mapper faengt mit dem Begriff Way deutlich mehr an als mit Relation ... so dass wir entweder viele potentielle Mapper verlieren oder abschrecken werden oder diesen andere Begriffe in den Editoren anbieten muessten. Es ist zu bedenken, dass dieses Proposal bei weitem auch nicht alle Probleme loest, denn in letzter Konsequenz muessten so, wie Du es formuliert hast, ja fuer eine simple Landstrasse, die heute als einziger Way mit 5 Tags existiert, ploetzlich 5 Relationen angelegt werden. Auch nicht gerade schmackhaft fuer Otto Normalmapper. ... erst recht nicht mit den momentanen Relation-Editorfunktionen :-( Oder deutlicher gesagt, eine spontane Umstellung vom einen auf das andere waere sicherlich nicht moeglich, aber man koennte die segmentierten Tags als Zusatzoption einfuehren, eventuell zunaechst verstaerkt in einem Teilgebiet wie Tempolimits o.ae. einsetzen, und dann schauen, ob sich das bewaehrt und es ggf. auf andere Gebiete ausweiten. ... so war mein Vorschlag auch gedacht. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Freihand-Zeichnungen von Luftbildern und Kart en möglich!
On Thursday, 18 June 2009 21:42:41 +0200, Johannes Huesing johan...@huesing.name writes: [...] Wie kommt man eigentlich zu Flurnamen oder Namen von Schlaegen im Wald, ohne Karte? Die stehen ja auf keinem Schild. Bei mir in der Gegend gibt es einige Schilder an Baeumen mit den jeweiligen Flurnamen. Ansonsten frage man den zustaendigen Foerster, Jaeger, Waldbesitzer ... viele geben bereitwillig Auskunft. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Richtung von Ways - Digitalisierungsrichtung (was: Fahrradwege)
On Monday, 18 May 2009 20:25:39 +0200, Bernd Wurst be...@bwurst.org writes: Am Montag 18 Mai 2009 20:17:11 schrieb Christopher K.llmayr: Am Montag, den 18.05.2009, 19:56 +0200 schrieb Falk Zscheile: Fuer nicht baulich getrennte Radwege bietet sich cycleway=left, cycleway=right, cycleway=both[1] an. Hauptkritikpunkt daran ist aber, dass man die Richtung von ways einfach umdrehen kann und damit ist der Radweg auf der falschen Seite. ... das Hauptproblem daran ist, dass irgendwann einmal festgelegt wurde, dass Wege _keine_ Richtung haben, obwohl sie im OSM-Modell doch eine Richtung haben, da die Wegeknoten eine Reihenfolge haben muessen. Diese Digitalisierungsrichtung wird darueberhinaus bei einigen Dingen, wie Kreisverkehre und oneway=yes/no/-1/... sogar explizit benutzt. Es waere nun ein erster Schritt, _explizit_ festzulegen, dass es diese Digitalisierungsrichtung gibt und man sich auf diese in Tags beziehen kann und auch sollte, wenn es angebracht ist. Damit waeren alle Eigenschaften und Dinge, die (fahrt-)richtungsabhaengig sind oder auf einer Seite laegen, sehr einfach und intuitiv abbildbar. Oder wie gebe ich unterschiedliche Geschwindigkeitsbeschraenkungen, Fahrspurzahl, Zufahrtsbeschraenkungen auf dem gleichen Strassenabschnitt an? Im naechsten Schritt sind, wie bei einem API-Versionswechsel, auch alle Editoren und sonstige Werkzeuge anzupassen, so dass einige Tags wie oneway=... und wenn man sich auf left/right, forward/backward bezieht, diese beim Drehen des Weges ebenso automatisch gedreht werden ... oder eben eine Warnung erscheint. Wenn alle, die dieses Argument bei jeder Gelegenheit vorbringen nur je eine Zeile Code schreiben wuerden, haette JOSM schon lange eine Info-Box, die einen warnt sobald man einen Weg dreht, bei dem irgend ein key oder irgend ein Wert left/right oder forward/backward enthaelt. :) Es gibt halt weniger JOSM-Programmierer als JOSM-Nutzer ;-) Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frankenweg
Hallo zusammen, on Tuesday, 10 March 2009 16:54:55 +0100, Karl Eichwalder k...@gnu.franken.de writes: Markus liste12a4...@gmx.de writes: Zur minute hat der Frankenweg 700 members und spaetestens bei 750 werde ich mit der aufteilung beginnen. Was ist der Grund fuer diese Teilung? Mit der neuen API wird sowieso bei 1000 schluss sein. Es ist bestimmt gut, wenn wir uns in jeder relation ein wenig reserve schaffen; denn man muss ja immer damit rechnen, dass noch ein paar wege geteilt werden. Ausserdem dauert es recht lang, immer wieder auch bei der kleinsten Aenderung wieder alle members abzuspeichern und es nimmt relativ viel platz in der datenbank ein, da bei jedem hochladen die relation erneut _komplett_ gespeichert wird. Je laenger ich ueber die Relation fuer solcher Art Routen nachdenke, desto sinnvoller erscheint es mir, dass - es genau _eine_ (Master-)Relation Frankenweg gibt und dass - es fuer _jeden_ Weg, der Bestandteil des Frankenweg sein soll, eine eigene Relation gibt, die die Bestandteil-Beziehung zwischen dem Weg und der (Master-)Relation Frankenweg herstellt. Diese Vorgehensweise haette den Vorteil, dass ein Update der Frankenweg-Relation im Nuh herunter- und hochgeladen werden kann (die Master-Relation enthaelt ja eigentlich keine Member) und dass jeder Weg und die daranhaengende Bestandteil-Relation ebenso schnell herunter- und hochgeladen werden kann (ist ja nur ein Weg + 1 Bestandteil-Relation + 1 Master-Relation). Ebenso ist die Ergaenzung um weitere Wege schnell geschehen. Diese Vorgehensweise haette den Nachteil, dass es _viele_ Bestandteil-Relationen gaebe. Ebenso wird das Zusammensuchen aller Wege des Frankenwegs etwas aufwendiger, da die Wege ja nicht mehr direkte Member, sondern nur noch indirekte Member der (Master-)Relation sind. ... ist nur die konsequente Umsetzung der Aufteilung der grossen Relation mit _allen_ Wegen in Relationen, die Abschnitte mit einer handhabbaren Member-Menge (Anzahl = 1000) besitzen. Wenn man diese Teilung bis zur Member-Menge-Groesse 1 fortfuehrt, landet man bei dem Prinzip pro Weg eine eigene Relation zur Route. Damit entfiele auch die willkuerliche Teilung der Route ... [...] Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Strassenschreibweise ist anzuhalten?
Hallo zusammen, On Sunday, 8 March 2009 23:49:06 +0100, Martin Trautmann tr...@gmx.de writes: [...] Oftmals reicht gesunder Menschenverstand und ein Nachschlagewerk - wobei oftmals sich auch die Frage stellt, wem man wohl folgen solle. Sehr beliebt ist z.B. der Gerhard-Hauptmann-Weg (statt Gerhart-Hauptmann-Weg). Auch die Bismarkstrasse findet sich oft statt der Bismarckstrasse. Die Albert-Schweizer-Strasse findet sich dutzendweise. Wenn es sich bei Hauptmann um den Dichter handelt, dann ist Gerhart richtig und Gerhard falsch. Wenn es sich aber um jemand anderen handelt, der nur (fast) gleich heisst, dann ist das Gerhard doch richtig. Bismarkstrasse kann richtig sein, wenn es sich bspw. um die Strasse zur Stadt Bismark (in Sachsen-Anhalt) handelt. Albert Schweizer war ein Maler, waehrend Albert Schweitzer der bekanntere Arzt und Nobelpreistraeger war. Von daher kann man auch hier nicht _ohne genauere Ortskenntnisse_ die Strassennamen korrigieren! Die meisten derartigen Fehler werden aber offiziell frueher oder spaeter korrigiert. ... wenn es denn Fehler sind! [...] In meiner eigenen Nicht-OSM-Anwendung bevorzuge ich wo immer moeglich die richtige und in der Regel ausgeschriebene Schreibweise (also statt der zig Varianten wie Frh. v. Stein-Str. lieber die Freiherr-vom-Stein-Str.), habe aber die Freiheit, beliebig viele bekanntermassen falsche Schreibweisen als Suchalternativen zuzulassen. Ja, insbesondere gibt es beide Alternativen, sowohl Freiherr-von-Stein-... als auch Freiherr-vom-Stein- Daher bitte vorsichtig mit Fern-Korrekturen oder automatischen Korrekturen! Und bei Unklarheiten ueber die korrekte Schreibweise lieber ein FIXME mehr taggen. Gruss, -bernd PS: Auch die beiden kommerziellen Anbieter sind nicht frei von Fehlern! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] [tagging] RFC :left/:right (asymmetrical roadside features)
On Tuesday, 17 February 2009 10:36:16 +, Andy Allan gravityst...@gmail.com writes: On Mon, Feb 16, 2009 at 7:11 PM, Norbert Hoffmann nhoffm...@spamfence.net wrote: Andy Allan wrote: And every time using :left and :right comes up, we all have a big discussion about it and then nobody pays any attention and it comes up again a few months later. Perhaps this is because the concept leftright is so simple - and the aversion against editors, that are not totally key-ignorant is not so easy to understand. And nobody pays attention. The main problem is that two-way roads have no inherent, real-world, direction - neither side of the road is the right or the left. Or rather, both sides of the road are the right or the left, depending on which way you are facing. Ok, if this is true, what is _your_ solution for the problem of placing something on the left or right side of a road ... or a direction-dependent tagging of a way attribute (e.g. oneway for a set of vehicles, different speed limits for both directions etc.)? Roads or ways have no ``inherent, real-world, direction'', but they have a direction within the OSM model. A way is represented by an ordered set of nodes, thus the way has something which is called digitization direction. If I want to tag attributes/properties which are true only relative to this digitization direction, I will use a _simple_ means to specify this ... and after reading all the current and past discussions about left/right or in direction/ against direction IMHO a direction relative tag _is_ a simple and normal concept. The only place that right and left has any intrinsic sense is on one-way roads, which *do* have an inherent direction (and signs to that effect). One-way roads do _not_ have an inherent direction. I am usually allowed and I can walk _against_ a one-way road. And I know a lot of one-way roads where I can cycle against the direction, or where busses are allowed to drive against the direction. This property is vehicle-dependent. Additionally the current special handling of oneway and its special cases (oneway=-1 for a oneway against the digitization direction!) shows that there is a need for a concept for direction-dependent tags. Why not use the inherent digitization direction, define and document a simple tagging concept for direction dependent tags, and add support for it to all editors and tools as it is already done for the oneway tag? [...] Now the problem is that most people at the moment in OpenStreetMap are tech-heads, and are so used to mental constructs and abstractions like every road having a completely arbitrary intrinsic direction - but that doesn't mean it's a great idea. It is not the best idea. On the other hand I have seen no other idea which is simpler to understand. Editor support is less important - and far easier to fix - than explaining to all the people who don't even realise that all roads have a direction in openstreetmap - and except for oneway roads, I have no idea which ways are pointing in which directions, and it shouldn't be important unless it *has* to be important. If I want to add a direction- or side-dependent tag/object to the map, the editors have to show the current (digitization) direction of the road. To edit a map we use a lot of mental constructs and abstractions of the real world (a real world road is not a line with a few pixel width, a real world intersection consists not only of two lines connected by a simple node etc.). -bernd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Verkehrsinseln
On Friday, 30 January 2009 18:13:36 +0100, Bernd Wurst be...@bwurst.org writes: Am Freitag, 30. Januar 2009 schrieb Mario Salvini: natuerlich muss da eine turn-restriction hin, sonst koennte da links abbiegen (in die Realitatt uebertragen also drehen). Beispielsweise z.B. hier: http://data.giub.uni-bonn.de/openrouteservice/index.php?start=6.1134704,50. 7710525end=6.1163058,50.7714249pref=Fastestlang=de Da hast du Recht. Wobei es physisch gesehen auch eher durch den Winkel verhindert wird und nicht durch ein spezielle Abbiegeverbot. Ein Winkel verbietet nichts, da man ja beim Mappen Flaechen zu Kanten vereinfacht. Und da kann leicht aus einer Kreuzung mit ausreichendem Abbiegeraum im Kantenmodell etwas sehr spitzwinkliges werden. Man koennte also auch sagen, der Router sollte niemals Winkel z.B. ueber 150Grad verwenden. Solche spitze Winkel kommen in Realitaet aber vor und bei einigen kann man tatsaechlich nicht abbiegen, bei anderen kann man dies jedoch. (Solange man nicht weiss, wie breit die Strassen sind, welchen Wendekreis das Fahrzeug hat, ob man nach links oder rechts abbiegt etc. sollte ein Router hier nichts annehmen bzw. vielleicht etwas schlechter gewichten, ausser es gibt wirklich ein Abbiege_verbot_.) Dann muesste man nur fuer wirklich knifflige Faelle eine spezielle turn-restriction eintragen. Naja, da sollen mal die Router-Fachleute noch was zu sagen ... Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] BAB - Beginn der Verzögerungsspur
Hallo, On Wednesday, 28 January 2009 19:46:16 +0100, Bernd Wurst be...@bwurst.org writes: Am Mittwoch, 28. Januar 2009 schrieb Jan Tappenbeck: nachgedacht und mir war irgendwie, als wenn ureigentlich der Beginn der Verzoegerungsspur gemappt werden sollte - leider kann ich die Seite im Wiki hierzu nicht wiederfinden. Ich kann dir auch keine konkrete Quelle nennen, aber es wurde mal irgendwo das Statement zenetiert, dass solche Spuren bitte in dem Moment abzweigen sollen, wann die Strasse auch abzweigt. Topologisch ist das korrekt ... bzw. man sollte da abzweigen, wo die Verlaengerung der Ausfahrt nach der Teilung auf die Hauptfahrbahnen stossen wuerden. Ich selbst halte das eigentlich fuer Kaese und kann das auch begruenden: 1. Mein Fahrlehrer sagte mir mal, dass man den Verzoegerungsstreifen ganz am Beginn anfahren sollte und erst *auf* dem Verzoegerungsstreifen bremsen soll, nicht schon auf der Autobahn selbst. Das geht eben nur wenn man schon zu Beginn auf den Verzoegerungsstreifen wechselt. Daher sollte dieser fruehestmoegliche Punkt auch als der Punkt zum Abfahren in den Daten sein. Bei der Beschleunigung gilt faktisch dasselbe, man soll erst am Ende der selben auf die Fahrstreifen wechseln. Das ist auch alles richtig. Als Begruendung gab mir mein damaliger Fahrlehrer noch hinzu, dass man beim Wechsel zu Beginn des Verzoegerungsstreifen nicht (aus Versehen) rechts von einem ebenso Ausfahrenden ueberholt werden kann. Meiner Meinung nach bildet man die Topologie nach, d.h. der Verzoegerungsstreifen macht aus einer n-spurigen eine n+1-spurige Fahrbahn, aber eben keine getrennte Fahrbahnen. Erst wenn ein physical divider die Fahrbahnen physisch trennt, sollte man den neuen Weg anfangen. 2. Mein (proprietaeres) Navi hat die Abzweigungen auch immer am Ende drin. Es sagt zwar schon etwas vorher an, wann ich abbiegen muss, aber wenn es sagt jetzt abbiegen, ist es fuer eine korrekte Benutzung des Verzoegerungsstreifen schon ziemlich spaet. Das stoert mich zuweilen. Die beiden grossen Kartenhersteller machen das ein bisschen unterschiedlich. Der eine trennt die Kanten frueher (ungefaehr ab der durchgezogenen Linie, die Ausfahrt von Hauptfahrbahnen trennt), der andere etwas spaeter auf (Verlaengerung der Strassenmitte der Ausfahrt in Richtung der Hauptfahrbahn). Beide haben aber in ihren Modellen mit abgelegt, wann der Verzoegerungstreifen beginnt (transition point) und wann sich die Fahrbahnen auftrennen (split point) oder wann zusaetzliche exit- bzw. entry-lanes vorhanden sind. Ein Navi kann also sehr wohl bestimmen, wo der Verzoegerungsstreifen einer Ausfahrt beginnt ... muss dies aber fuer die Karte des jeweiligen Kartenherstellers ein bisschen anders tun. Und dies geht auch bei mehrspurigen Ausfahrten, die sich kurz danach wieder auftrennen, was man ja beispielsweise bei vielen AK-Kleeblaettern vorfindet. 3. Nicht zuletzt sieht es auch auf den Karten wesentlich realistischer aus, wenn die Spur da seitlich noch 100 Meter parallel laeuft. Aber die Spur ist doch in Realitaet _nicht_ (physisch) getrennt, sondern diese Fahrbahnen sind nur durch gestrichelte Linien markiert, die man real problemlos ueberfahren kann und darf. Erst ab dem split point geht nichts mehr (sei dieser nun der physical oder nur ein legal divider) und genau an diesem Punkt sollte man die Wege topologisch trennen. Meiner Meinung nach ist es besser, die Wegstuecke beispielsweise bei einer 2-spurigen Autobahn - vor der Ausfahrt mit lanes=2, - bei Beginn des Verzoegerungsstreifen mit lanes=3, und - nach der Ausfahrt wieder mit lanes=2 zu markieren. Das Wegstueck mit Verzoegerungsstreifen kann man auch noch mit dem Tag exitlanes=1 markieren (Tag habe ich mir gerade ausgedacht!), damit die Information, dass eine der 3 Spuren eine Ausfahrtsspur ist, auch vorhanden ist. Diese Infos ueber die Spurzahl (und die evtl. Ausfahrtsspurzahl) kann man dann auch in einem Renderer realistischer darstellen und die Info, dass alle Spuren zusammengehoeren, geht dabei auch nicht verloren. Natuerlich kann ich auch die Gegenseite verstehen, denn bis zum Ende der Verzoegerungsspur ist ein Wechsel immernoch moeglich und eine Alternativroute muss erst berechnet werden wenn man an diesem Punkt vorbei gefahren ist. Eine Abbilung von hier darf man noch von highway=motorway auf highway=motorway_link wechseln fehlt bisher. Bei der Routenberechnung ist es eigentlich egal, wann der Trennpunkt ist. Der einzige Teil, der diese genaue Info benoetigt, ist die Abbiegehinweisgenerierung, die der Berechnung der optimalen Route nachgelagert ist. Aber die braucht nur die Info, an welcher Position die Anweisung gegeben werden muss und hierzu reicht eine Markierung des transition point voellig aus. [...] Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org
Re: [Talk-de] Fehlende Straßen/Wege/Pfade
On Friday, 9 January 2009 17:10:02 +0100, Jan-Benedict Glaw jbg...@lug-owl.de writes: On Fri, 2009-01-09 16:55:52 +0100, Claudius Henrichs claudiu...@gmx.de wrote: [...] Die Frage ist doch: Wo laege der Vorteil, einen unvollstaendigen Strassenstummel einzuzeichnen gegenueber gar nicht einzuzeichnen, wenn du es nicht gleich die ganze Strasse schaffst. Ich finde es besser, keine Stummel einzuzeichnen, da man dann besser bspw. in der Comparison erkennt, wo Strassen fehlen. Die Stummel haben IMHO keine Vorteile, da bin ich ganz bei Dir. Die Stummel (englisch stubble) haben mehrere Vorteile: Zum einen kann man mit ihnen dokumentieren, dass da ein Weg beginnt, der von seiner Geometrie noch nicht vollstaendig erfasst wurde ... und genau um dies geht es doch in diesem Thread, oder? Zum anderen dokumentiert man auch mit diesen Strassenstummeln, dass an dieser Stelle eine Kreuzung existiert. Und genau diese Info ist hilfreich, wenn man zum Routen spaeter Navigationshinweise der Art rechts, dann die 2. links generieren will. Deshalb ist meine eigentliche Frage ja: Wie wollen wir fehlende Strassen/Wege/Pfade taggen? Ich erzeuge ein kurzes Stueck Strasse/Weg/Fluss/Bach/... und fuege ein note-Tag mit FIXME: stubble o.ae. ein. Nach einem FIXME kann man in einer OSM-Datei oder im JOSM spaeter wieder suchen bzw. beim spaeteren Befahren kann man aus dem Stummel dann das komplette Stueck Strasse/... machen. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ortsgebiet
On Saturday, 13 December 2008 07:00:04 +0100, Marcus Wolschon mar...@wolschon.biz writes: 2008/12/2 Alexander Schulze schulzib...@web.de: Wie taggst Du die denn? also einfach name=Ortsname traffic-sign=city-limit Nicht schon wieder eine eigen-Erfindung fuer die Begrenzung von Orten. Besser ist IMHO ein eingetragenes Ortsschild als _kein_ eingetragenes Ortsschild. Wenn einem die Tags nicht passen, kann die spaeter jemand anderes immer noch entsprechend korrigieren bzw. so umsetzen, dass ein Router/Renderer/... was damit anfangen kann. Und jetzt nenn mir dochmal einen vollstaendigen und eindeutigen Algorithmus der solchen Quatsch verarbeiten soll? Mensch? Und vollstaendig ist bei OSM schon gar nicht, da vieles erst im Entstehen und Sich-zu-einem-Sinnvollen-Fuegen ist, wie man an den Diskussionen immer wieder sieht. Wie soll ich denn das in die Regel auf: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing#City einbauen? * das Schild alleine ist nutzlos, solange man nicht sagen kann auf welche Seite des Schildes denn Innen und Aussen sind. Das heisst, dass man am Schild sinnvollerweise den Weg auftrennt und das davor und dahinter entsprechend kennzeichnet. Entweder mit Tags fuer den Knoten und die beiden Wegteile oder mit einer Relation, die alle drei Dinge enthaelt. * Diese Information wird nicht nur fuer den Way mit dem Schild gebraucht sondern fuer alle Ways innerhalb und nahe der Ortschaft. Fuer's Routing reicht die Info ueber die erlaubte maxspeed und vielleicht noch, ob ein Weg innerorts (urban=yes/no) ist, oder? * Das ist doch wohl DER klassische Fall eines Polygons. Und auch wenn dies oft genug hier wiederholt wird, gibt es auch hier wieder einige Ausnahmen, die mit einem Ortspolygon zu falschen Ergebnissen fuehren. Man denke nur an Autobahnen oder Bundesstrassen, die zwar innerhalb eines Ortspolygons laegen, aber eben _nicht_ innerorts markiert werden sollten, da ich, wenn ich darauf fahre, nie an einem Ortsschild vorbeikaeme -- dies steht dann an den Abfahrten. Und in einigen Faellen koennte ich das Polygon noch nicht einmal anpassen, da (auf Bruecken/in Tunnels) kreuzende Strassen wiederum innerorts sind, so dass man den Sonderfall solcher ausserorts liegende Strassen speziell als solche markieren muesste. Ach ja: Und es macht einen Unterschied zwischen einem Polygon fuer ein bebautes Gebiet (built-up area) und einem Gebiet, das man durch Ortsanfangsschilder begrenzen moechte. Es gibt genuegend Ortsanfangsschilder, die weit vor einem bebauten Gebiet steht als auch solche, die erst spaet innerhalb eines bebauten Gebiets stehen. Fuer's Zeichnen ist aber IMHO das Polygon fuer ein bebautes Gebiet sehr sinnvoll, fuer's Routing waere aber eine Inner-/Ausserorts- Markierung (wie auch immer) ebenso sinnvoll. Ich plaediere daher dafuer, die Ortsschilder, also einen Ortsanfang explizit am Knoten zu kennzeichnen. Und solange es noch keinen sinnvollen Vorschlag fuer die Richtung (= Anfang/Ende) und zwei direkt aufeinanderfolgende Orte gibt, begnuege ich mich mit einem Kommentar fuer eine spaetere Nachbearbeitung und verwende dazu noch fleissig maxspeed, um den Routern dennoch etwas Gutes zu tun ;-}. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] noexit - wie weit anwenden
On Monday, 3 November 2008 01:27:34 +0100, Thomas Hog [EMAIL PROTECTED] writes: Guenther Meyer schrieb: nur sind osm-daten schon prinzipbedingt zur zeit unvollstaendig, und da ist es durchaus sinnvoll, unterscheiden zu koennen, ob eine strasse, die ploetzlich aufhoert, wirklich so aussieht, oder ob es nur ein fall von ich hab nicht mehr in diese richtiung weitermappen koennen, aber da kommt schon noch was... ist. Gibts dafuer denn eine allgemein genutzte Loesung? fixme=yes, incomplete=yes, note=bin nicht fertig, macht mal weiter? Wenn man sich da auf irgendwas einigt kann das ja mit autobug markiert werden. Oder sollte man seine eigenen unfertigen Sachen auf OSB ablegen? Das noexit=yes ist nicht nur fuer Personen sinnvoll, sondern auch fuer all die Programme, die das OSM-Datennetz validieren. Beispielsweise tagge ich gerne alle _Endpunkte_ eines Weges, wo es mit keinem Verkehrsmittel legal und/oder mit einfachen Mitteln mehr weitergeht, mit noexit=yes und dann noch den Weg mit noexit=yes. Damit dokumentiere ich fuer die Validierer (und fuer andere Personen), dass sie diesen Punkt bitte nicht automatisch mit dem einige Meter weiter verlaufenden Weg verknuepfen moegen, weil eben ein Validierer nicht wissen kann, ob da wieder jemand einen Punkt nicht sauber auf den Weg gelegt hat oder ob da doch ein nur schwer ueberwindbares Hindernis (Mauer, Zaun, Abgrund :-) dazwischenliegt. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags
Hallo, durch Urlaub meinen eigenen Senf hierzu mit einem Monat Verspaetung :-) On Friday, 22 August 2008 12:48:13 +0200, Bernd Wurst [EMAIL PROTECTED] writes: [...] Wir haben jetzt diverse Dinge, die wir mit dem aktuellen Tagging-Schema nicht richtig abbilden koennen. Seien es Verbote, die gezielt fuer einzelne Gruppen gelten oder aufgehoben werden (maxweight=6 / Anlieger frei), Unterschiedliche Hoechstgeschwindigkeiten fuer unterschiedliche Fahrzeuge (Autos 80, LKW 60) oder aehnliches. All das wird dann mit abenteuerlichen Konstruktionen geloest, die oft damit arbeiten, dass ein Schluessel oder Wert in mehrere Teile zerlegt werden soll. Dass das Fehleranfaellig und ungleich schwieriger zu verarbeiten ist, ist wohl klar. Die Loesung der Probleme waere IMHO damit getan, dass man Tags Baumstruktur-artig setzen kann. Damit waere es moeglich, z.B. ein access=destination unterhalb eines maxweight=6 zu setzen. Oder ein maxspeed=60 unterhalb eines hgv=yes/destination. Statt gleich ganze Baeume und damit Hierarchien aufzumachen, wuerde ich es bei einer Tag-Gruppe belassen. Sieht man sich einmal GDF an, so werden dort die Attribute in Simple Attribute und Composite Attributes unterschieden, d.h. man hat eine einzige Ebene. Und wenn ich die obigen Beispiele sehe, reicht eine Gruppierungsebene aus. Und gegen die Hierarchie von Attributen spricht auch, dass es nicht eindeutig ist, welches Attribut nun unter welches gehoert. Kommen nun die Zusatzschilder fuer Lkw ab 7,5t (hgv) _unter_ das maxspeed=60 oder so wie im obigen Beispiel das maxspeed=60 unter das fuer Lkw ab 7,5t? ;-} Wenn man sich auf eine Ebene beschraenkt und man die momentanen einfachen Tags als Sonderfall einer Tag-Gruppe mit einem einzelnen Tag auffasst, ist die Erweiterung der API als auch der Schnittstelle deutlich einfacher durchzufuehren. Uebrigens kann man Attributgruppen bereits mit dem momentanen Datenmodell angeben, indem man eine oder mehrere Relationen erstellt, dort hinein den Node bzw. Way packt und dann bei dieser Relation nur die jeweiligen Attribute hinschreibt. Aber nachdem ich dies einmal sowohl mit Potlatch (im Spielemodus) als auch mit JOSM versucht habe, habe ich diesen Weg schnell wieder aufgegeben, da diese per Relation zugeordneten Tag-Gruppen momentan nicht sehr prominent und uebersichtlich dargestellt werden und somit von einem selbst als auch von anderen Mappern sicher uebersehen und somit zerstoert werden. [...] On Friday, 22 August 2008 13:07:38 +0200, Frederik Ramm [EMAIL PROTECTED] writes: Bernd schrieb: Da die API 0.6 seit einer kleinen Ewigkeit vorbereitet wird und man aufgrund der nicht vorhandenen Fortschrittsbekundungen von einem Rohrkrepierer ausgehen muss (Sorry, Frederik), waere das IMHO eine Sache, die eingefuehrt werden sollte. Du meinst, wenn es eh nix wird, kann man es auch noch mit komplizierten Features ueberfrachten ;-) Il semble que la perfection soit atteinte non quand il n'y a plus rien `a ajouter, mais quand il n'y a plus rien `a retrancher. Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzuzufuegen gibt, sondern wenn man nichts mehr weglassen kann. (Antoine de Saint-Exupery) Ich sehe bei Baumstruktur-Tags einen Editor-Alptraum voraus. Ich will auf jeden Fall nicht der sein, der das implementieren muss ;-) Daher wuerde ich das auch nicht als Baum(-Hierarchie), sondern nur als Tag-Gruppe mit genau einer (weiteren) Ebene aufziehen. Dies duerfte IMHO voll ausreichend sein ... zumindest lebt GDF mit diesem Konstrukt schon viele Jahre ganz gut und ausreichend, um Beschraenkungen bzgl. Transportmittel, Zeit, Richtung etc. oder Plazierungen von Objekten bzgl. anderer zu beschreiben. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?qualit?tsoffensive - nicht angebundene stra?en -?teilweise katastrophale datenqualit?t
Zwar schon eine alte Diskussion, aber Urlaub etc. ... :-) On Wednesday, 3 September 2008 15:52:07 +, Heiko Jacobs [EMAIL PROTECTED] writes: Sebastian Waschik [EMAIL PROTECTED] wrote: Heiko Jacobs [EMAIL PROTECTED] writes: kommt. Am besten waere m.E. eine Art Tag, dass (dem Validator und dem menschlichen Pruefer) sagt: hier fehlt nichts, das gehoert wirklich so. a) gibt's nicht sowas wie noexit? Am Ende einer richtigen Sackgasse, also eines Weges ohne Ausgang, fuege ich an den Knoten auch einen noexit=yes an ... auch wenn der noexit-Tag im Wiki anders beschrieben wird, aber nur so kann ein automatischer Validator diese Stellen von den fehlerhaft unverbundenen highways unterscheiden. (Und auch meckern, wenn da doch noch ein Weg dranhaengt bzw. dieser Knoten nicht am Ende eines Way ist.) Was ist dann, wenn eine Sackgasse am Ende in einen Fu?weg ?bergeht? Meine Antwort bezog sich auf den Fall im vorhergehenden Beitreag, wo gerade das NICHT der Fall war! :-) Dann hat die Stra?e noexit aber es k?nnte sein, dass der Weg doch verbunden ist. Fuer solche Faelle ist das noexit derzeit etwas, aehm, unnuetz... Die Radfahrer und Fuszgaenger, die sich gerade dafuer interessieren, werden sicher irgendwann eine Loesung finden... Eine fuer Fahrzeuge ausgeschilderte Sackgasse, die aber fuer Fussgaenger (und Radfahrer) weitergeht, markiere ich _nicht_ mit einem noexit=yes. (Vielleicht sollte man besser hier ein noexit=car vewenden, also das Transportmittel, fuer den die Sackgasse gilt, nennen.) Die Sackgasseneigenschaft eines solchen Weges fuer ein bestimmtes Transportmittel kann und wird ein Router _selbst_ herausfinden und man kann sich einigermassen sicher sein, dass die OSM-Karte bei einer Fortfuehrung eines Strasse in einen Fussweg vollstaendig ist. Hoert aber eine Strasse einfach so auf, kann ich mir nicht sicher sein, ob der Weg nun tatsaechlich endet oder ob hier nur mit dem Mappen aufgehoert wurde, so dass ein explizit gesetztes Weg-Ende sinnvoll und nuetzlich ist. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Himmelrichtungsabhängige Tags? (w as: Versetzte Stadtbahnhaltestellen)
On Sunday, 3 August 2008 13:07:43 +0200, Florian Arnold [EMAIL PROTECTED] writes: Hanno Boeck schrieb am 03.08.2008 12:45: Mir schwebte da sowas wie ein left/right-prefix vor, welches dann bspw. auch der editor intelligent mitdrehen koennte wenn man die strasse dreht. Also so in der art: left:highway=bus_stop Dies ginge leider wirklich nur, wenn (a) _alle_ Editoren intelligent genug waeren und (b) man alle left/right, aber auch in_direction/against_direction/opposite u.ae. Dinge _komplett_ damit abdeckt, da sonst doch etwas vergessen wird. [...] Wie waere es denn daher, wenn man die Richtung an den Himmelsrichtungen festmacht? Also z. B. in Deinem Fall north:highway=bus_stop Ich persoenlich wuerde so was wie ein north/south/east/west-Praefix (vielleicht auch Postfix) fuer die Faelle bevorzugen, wo eine Lage seitlich des Ways gemeint ist, (Haltestelle, Radweg, Briefkasten), für eine Richtung entlang des Ways (Einbahnstrassen, Fliessrichtung von Fluessen, Steigungen) vielleicht so was wie to_north. Wieviele Himmelsrichtungen gibt es dann? Nur 4 oder auch alle Zwischen-Richtungen, also 8? Oder doch besser 16 oder ... gleich einen Nordwinkel mit 0...359 Grad im Uhrzeigersinn? Das wuerde doch die Sache sehr stabil gegenueber unabsichtliche Aenderungen machen und trotzdem noch die Moeglichkeit einer automatischen Verarbeitung durch Editoren ermoeglichen. Ich halte von der Himmelsrichtung nicht so viel, da diese Richtungsangabe auch instabil sein: Sobald jemand die referenzierte Strasse veraendert, indem er neue Knoten einfuegt und/oder bestehende Knoten verschiebt, kann sich die Himmelsrichtung der Teilkanten aendern, evtl. auch sehr drastisch, wenn die Strasse sehr kurvig ist. Im schlechtesten Fall liegt die einseitige Haltestelle oder der Briefkasten auf der falschen Strasenseite, weil jemand die Kurven veraendert hat. Daher bevorzuge ich doch gleich das Taggen mit left/right/in/opposite, auch wenn beim Umdrehen des Weges falsch schief gehen kann ... oder ich beschreibe die Richtung mit einer Relation, in der die Richtung durch 2 Wegeknoten gegeben wird. Und das ist dann unabhaengig von der Wegrichtung und aendert sich erst, wenn jemand die beiden Knoten vertauscht. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee: Routing-Rating
On Saturday, 2 August 2008 01:35:47 +0200, Henry Loenwind [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: Diese Idee schwirrt mir schon so lange im Kopf herum; Mir auch eine... Die Idee beruht auf der Annahme, das kein Algorithmus sowie die Genauigkeit der Geodaten eine Strecke so routen koennen, dass es _uneingeschraenkt subjektiv_ die beste Route ist. Auch zum subjektiven Routen: Angenommen, man verpast jeder Strasse eine Zahl, die angibt wie sehr diese Durchfahrtscharakter hat. Also, z.B. die Strasse, in die man wirklich nur reinfaehrt, wenn man dort hin will waere 0, eine normale Wohnstrasse 1, die Strasse, die man benutzt um in ein Wohngebiet tief reinzufahren 3, eine Hauptstrasse 10, Autobahn 100... Das ist das, was in GDF als functional road class bezeichnet wird. Und was im momentanen OSM-Tagging-Schema sich auch aehnlich(!) beim highway=primary/secondary/tertiary/... wiederfindet. Aber egal wie man es dreht und wendet, auch diese Klassifikationen sind _subjektiv_, daher unterscheiden sich die beiden grossen kommerziellen Anbieter in dieser Attributierung und auch wir OSMler klassifizieren die Strassen unterschiedlich. Dann bringt man dem Router bei, dass die ideale Route aus einmal aufteigend und eimal absteigend besteht, und dess jedes hoch runter hoch schlecht ist. Und dann noch, dass er versuchen soll, jeweils so schnell wie moeglich hoch zu kommen. Ueberraschung: Genau das machen viele Router bereits so. Aber so schnell wie moeglich hoch zu kommen, bedeutet sehr haeufig, dass man _nicht_ die schnellste und/oder kuerzeste Route bekommt, sondern Umwege faehrt. Beispielsweise ist die naheliegendste Autobahnauffahrt nicht immer die beste, wenn man dadurch auf der Autobahn einmal komplett um die Stadt herumfahren muesste, anstatt die etwas weiter entfernt liegende Auffahrt einer anderen Autobahn zu verwenden, die bereits in Richtung Ziel liegt. Das wuerde IMHO die Ortskenntnisse der Mapper auf eine einfach zu nutzende Art und Weise abbilden. Machen wir doch durch das highway-Tag und die Tags drumherum schon so. Wo muss da dringend was besser gemacht werden? Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Geschwindigkeiten auf Straßen
On Wednesday, 16 July 2008 23:43:56 +0200, Alexander Schulze [EMAIL PROTECTED] writes: gibt es ne Möglichkeit Geschwindkeitsbegrenzungen in Abhängigkeit von der Fahrtrichtung zu taggen, da diese ja doch ab und zu verschieden sind. Vermutlich nur wenn man getrennte Fahrbahnen hat oder? Dafuer hatte ich das Proposal der Relation Segmented Tag vorgesehen, da unterschiedliche Geschwindigkeiten abhaengig von der Fahrtrichtung doch haeufiger vorkommen. Gibt es ein Tag für Ortsschilder? Wenn du mal die Statistiken unterhalb der Wiki-Seite Tagwatch nach city-limit, city-limit-sign oder city_limit durchsuchst, findest du, wie andere es bisher gemacht haben. Ich markiere momentan den Punkt des Ortsschilds auf dem Weg (mit traffic_sign=city_limit, name=...), wenn auch noch nicht gerichtet. Da duerfte der Ansatz als boundary mit boundary=city-limit(-sign) besser sein, der auch per Tagwatch zu finden ist. -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM Sackgasse
On Thursday, 17 July 2008 13:27:16 +0200, Bernd Wurst [EMAIL PROTECTED] writes: Hallo. Am Donnerstag, 17. Juli 2008 schrieb Heiko Schack: Koennten man dieses Zeichen nicht einfach am Anfangsnode einer Sackgasse automatisch rendern? Die Anzeige bei einem getagten Node finde ich ein wenig verwirrend. Um den Anfangs-Node eines Ways herauszufinden, muesste der Renderer aber erst einmal sehen, welches der beiden Enden nicht mit einem weiteren (high-)way verbunden ist ... Das ganze Tag ist IMHO recht nutzlos, denn es bezeichnet nur den Zustand, dass die Stassenverkehrsbehoerde denkt, dass ein normaler, (ortsfremder) Autofahrer dort nicht weiter kommt. Es beinhaltet kein direktes Einfahrverbot oder aehnliches. Jedes Navi wird aus dem Datenbestand sehr gut auslesen koennen, ob es sich um eine Sackgasse handelt oder nicht, genauso der Betrachter einer Karte. Jupp. Aber genau deshalb halte ich den Tag fuer sehr sinnvoll. Er erlaubt uns einen Konsistenz-Test der Daten oder/und die explizite Markierung von noexit-Kanten (oder -Knoten). Ich verwende diesen Tag ueberall da, wo es tatsaechlich mit keinem Verkehrsmittel oder zu Fuss weitergeht. Somit kann ich auch per Validator-Plugin-Erweiterung testen, ob eine per noexit markierte Kante (oder Knoten) nur aus Unachtsamkeit _nicht_ mit dem einige Meter danebenliegenden Weg verbunden ist oder ob dies genauso gewollt ist. Ich verwende das Tag _nicht_, um das Sackgassenschild zu mappen. Dafuer wuerde ich eher etwas wie traffic_sign=cul_de_sac :-) (oder auch ...=dead_end) am Knoten, wo das Schild steht. Zudem: Die meisten Sackgassen sind in Wirklichkeit keine. Fuer Fussgaenger geht es fast immer weiter, fuer Radfahrer oft und manchmal auch fuer landwirtschaftliche Fahrzeuge oder sonstwelche individuell berechtigten. Ein noexit=yes tagge ich daher nicht, das soll der wie auch immer geartete Datennutzer IMHO bitte aus den Daten herauslesen. :) Aus diesem Grund verwende ich in solchen Situationen auch kein noexit=yes. Fazit: Wenn man noexit=yes taggen moechte, dann IMHO bitte auf einen Node, an dem das Schild steht (nur um diese Infos, dass da ein Schild steht, erfasst zu haben). Am Weg ist es sinnlos. Ich mache es genau andersherum: Das Schild als traffic_sign= o.ae. mappen, die Eigenschaft des Weges oder des (Dead-)End-Knotens als noexit=yes. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Trennen von Straßen in Richtungsfahrba hnen
On Tuesday, 17 June 2008 11:58:49 +0200, qbert biker [EMAIL PROTECTED] writes: [...] es gab doch mal so einen schoenen Vorschlag zum Divider. Damit haette man die verkehrsrechtliche Vorschrift sauber vom Bauzustand getrennt. Dann verwende den Vorschlag zum Attribut Divider doch ... und ergaenze ihn noch um die evtl. fehlenden Dinge. Mittlerweile werde ich das Divider-Attribut fuer zwei Dinge verwenden: 1. Ueberfahrbare Abgrenzung/Trennung der (Richtungs-)Fahrbahnen, also Linien, (Strassenbahn-)Schienen etc. als Attribut fuer einen Way 2. Nicht ueberfahrbare Abgrenzung/Trennung, d.h. hier bauliche Trennung, also Trennmauer, Grasstreifen, Leitplanken etc. als Attribut fuer die Relation Dual Carriageway, die zwei parallel laufenden Ways zusammenfuegt Aus einigen Attributwerten des Divider-Attributs fuer einen Way kann ein Router Wende- bzw. Abbiegeverbote ableiten, so dass man auf weitere Abbiegegebot- und/oder -verbots-Relationen verzichten kann (Bsp: durchgezogene Linie = kein Abbiegen nach links moeglich, wenn man sich gerade nicht in UK, Japan und andere linksfahrende Laender befindet, dort kein Abbiegen nach rechts). Jetzt gibt es wieder den fuer OSM typischen Mischmasch aus allem, bei dem man zusammenfuegt, was nicht zusammengehoert. Durchgezogene Linien sind etwas ganz anderes als eine echte bauliche Trennung, verkehrsrechtlich und fuers Auge. Ja! Bauliche Trennung ist eine physich vorhandene Trennung, also ein physical divider und kein legal divider wie beispielsweise ein paar aufgezeichnete Linien. Die ganze Attributierung in OSM hat das prinzipielle Problem, dass sie nicht klassifiziert, was man beschreiben will, sondern dass man immer versucht in ein Attribut oder hier eine Darstellungsform alles moegliche hineinzupacken, was nicht zusammenpasst. Tja, du stoerst dich am Grundsatz in OSM, dass jeder beliebige Tags mit beliebigen Werte verwenden kann ... und dies auch noch tut. Andere finden das gut -- mich eingeschlossen --, denn nur so lebt die OSM-Karte und nur so koennen die vielen OSMler immer mal wieder neue Dinge und Aspekte aufnehmen, ohne extra lange Abstimmungsrunden abzuwarten, die bei von vornherein festgelegten Datenmodell notwendig waeren. [...] Letztens die Spuranzahl und heute die bauliche Trennung. Wer sich bei OSM auf einen Sachstand verlaesst, hat schon verloren... Echte Mapper(TM) verwenden deshalb GDF! :-) Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM-Validator Gemeckere
On Friday, 6 June 2008 13:00:24 +0200, Frederik Ramm [EMAIL PROTECTED] writes: Hallo, Ich habe mir schon mal überlegt, ob ich dafür einen Patch schreibe, aber bis zum Sommer werde ich eher nicht dazu kommen. Francisco R. Santos ist laut Homepage der Verantwortliche für das JOSM-Validator Plugin. Weiß jemand ob er externe Patches überhaupt akzeptiert? Der Source ist im SVN, Du kannst Deinen Patch einfach selber einspielen! Ich hatte Francisco Anfang des Jahres wegen eines Patches fuer den JOSM-Validator angeschrieben und er verwies auf die JOSM-Dev-Mailing-Liste, auf der man Aenderungen diskutieren kann, und den Subversion-Server, um die Patches selbst einzuspielen. Die Idee, einzelne Objekte mit speziellen Tags fuer den Validator auszustatten, finde ich etwas grenzwertig, das hat fuer mich den gleichen Charme wie fuer den Renderer Taggen. Andererseits gibt es das ja auch im normalen Umgang, dass man hinter irgendwas ein (sic!) schreibt, um anzuzeigen, dass das wirklich so gehoert, obwohl es falsch aussieht - und insofern ist ein virtuelles sic! in unseren Kartendaten vielleicht ok. Wobei man hier die beiden Objekte (oder auch mehr als zwei Objekte), die denselben Namen tragen, explizit mit einem sic! auszeichnen sollte. Und das geht eindeutig nur ueber die Objekt-Id und damit ueber eine OSM-Relation. Nur ein Objekt mit einem extra Tag wie validator:testsamename=no zu versehen, wuerde dazu fuehren, dass dieses Objekt gar nicht mehr auf versehentliche Namensgleichheit getestet wird, auch wenn faelschlicherweise jemand spaeter dasselbe reale Ding nochmals in der OSM-Datenbank verewigen wird. Oder man laesst das Plugin eine lokale Datei anlegen, in der es diese einmal bestaetigten Sachen speichert, aehnlich wie eine Textverarbeitung mit einem lokalen Woerterbuch fuer die Rechtschreibung. Mmmh, das haette den Vorteil, dass die OSM-Datenbank nicht mit solchen nicht-realen, virtuellen Infos gefuellt wird. Haette aber den Nachteil, dass ich anderen Mappern oder Test-Programmen nicht mitteilen kann, dass es schon ok ist, wenn eine Menge von Objekten denselben Namen tragen. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Straßen virtuell zusammenfügen
Moinmoin, zwar 'ne alte Diskussion, aber dennoch folgende Anmerkungen: On Sunday, 4 May 2008 23:44:30 +0200, Christoph Eckert [EMAIL PROTECTED] writes: IMO sollte es in unserer Datenbank zu *jeder* Straße ein Datenobjekt geben, welches die Straßenstücke zusammenbindet und der Straße ihren Namen gibt. Ich hatte vor einiger Zeit mal das genaue Gegenteil vorgeschlagen, also eine Straße grundsätzlich als einen way taggen. Und nicht wegen jeder Zusatzeigenschaft wie Geschwindigkeitbegrenzung,... splitten. Für diese Zustzeigenschaften bräuchte man dann Relations, die den Weg, Anfangs- und Endnode enthalten. kann ich mich erinnern. Dein Vorschlag ähnelt mehr dem GDF[1]; soweit ich mich erinnere kann man damit sowas machen wie diese Straße ist von da bis da vierspurig und von da bis da zweispurig. ... was aber von _keinem_ der grossen Kartenhersteller in ihren GDF-Dateien verwendet wird. Stattdessen wird bei jedem Attributwechsel eine neue Kante begonnen, d.h. diese Moeglichkeit in GDF wird nicht genutzt, zumal die Positionen nicht relativ, sondern als Abstaende absolut angegeben werden muessen und noch nicht einmal festgelegt ist, wie man die Laenge einer Kante bzw. der Teile einer Kante nun berechnen soll. Dein Vorschlag hat was für sich, aber ist komplizierter zu handhaben. Bei meinem Vorschlag hat man zwar mehr Straßenschnippel, aber es bleibt beim bestehenden System, bei dem man graphisch festlegen kann wo eine Brücke ist und so weiter. Ich hatte wie Dimitri aehnliche Vorschlaege hier schon gemacht, wobei man als Anfang und Ende eben je einen Node angibt, d.h. man kann bzw. man legt graphisch ueber diese Nodes fest, von wo bis wo bspw. ein Strassenstueck eine Bruecke ist. Der Vorschlag hat ausserdem den Vorteil, dass man bei der/den Eigenschaft(en) auch angeben kann, ob diese richtungsabhaengig sind. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Fragen zum Mappen von Flächen
On Monday, 28 April 2008 19:18:15 +0200, Marco Lechner [EMAIL PROTECTED] writes: Dabei fällt mir ein: mein Dörfchen in dem ich wohne war bis vor kurzem in den OSM-Daten nur ein Polygon (also so eine frei Schnauze Grenze) - sonst gab es außer zwei Hauptstraßen nix. Das hat sich natürlich mit dem Kauf meines GPS-Geräts schnell geändert, so dass diese vorherige Dorfgrenze irgendwie unnötig oder störend erscheint. Soll ich die, jetzt wo das Dorf nahezu komplett erfasst ist, einfach wegwerfen oder kann die noch eine wichtige Funktion haben? Städte wie z.B. Freiburg haben meines Wissens nach keine Umrandung nötig, oder? Eine oder mehrere Areas fuer die bebauten Flaechen, d.h. fuer die innerstaedtischen/inneroertlichen Bereiche zu haben, ist immer gut. Damit koennen beispielsweise Router eine bessere Reisezeit fuer die dann errechenbaren inneroertlichen Kanten ansetzen, wenn diese nicht mit maxspeed=50/30/... explizit gegeben sind. Ausserdem kann man auch auf der Karte die bebauten Flaechen einfaerben, so dass das Doerfchen exakter lokalisiert werden kann. Ansonsten kann man nur ahnen, dass da wo der Ortsname steht und viele Strassen sind, auch Haeuser sein duerften. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk] Tagging climbing routes and scrambles
On Saturday, 19 April 2008 11:46:52 +1200, Robin Paulson [EMAIL PROTECTED] writes: 2008/4/18 Steve Hill [EMAIL PROTECTED]: structure=pole highway=bus_stop amenity=post_box Ok, but you still have a potential conflict here. Hypothetically, you could have a timetable tag which applies to both a bus stop (tells you when busses arrive) and a post box (when is the post collected?). A neat solution is to have bus_stop:timetable and post_box:timetable. sorry, i should have made that clearer. i would do this as 3 separate items, maybe as a relation (slight overkill, but anyway). the relation would contain 3 nodes, one for the pole, one for the bus stop and one for the post box. thus each can have it's own timetable without any confusion. i would never tag one point (or way) as two separate items, that's asking for trouble, even if the tags don't clash technically this is wrong (not all 3 nodes can easily share the same point and still be editable), but i don't see a huge problem in 2 of them being slightly offset They can share the same _position_, represented in OSM as one node. IMHO the only natural possibility in OSM to describe three different entities at the same position is by using relations. I.e., put the node to its physical location, and add three relations with this node as member to describe (a) the pole, (b) the bus stop, and (c) the post box. a lot of the disputes over tagging are caused by people confusing physical items with conceptual ones; if we thought about separating them before debating a tagging scheme, things would be a lot clearer That may be, but I still think in some cases you are going to want multiple conceptual items attached to a single item - namespacing allows this to be done without risk of conflicting tags and makes it more obvious how the tags interact with each item (conceptual or physical). The same thing _could_ be done with relations (i.e. you mark up the physical items with ways and nodes and use relations containing physical items to represent the conceptial things). But at the moment that would be even more complex than a clear set of namespaces. ... if the OSM editors support a basic set of relations to add groups of tags to a single item as easy as adding a single tag to a node/way, IMHO namespaces are not really needed. Best wishes, -bernd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Bezirke
Hallo, on Sunday, 13 April 2008 12:00:35 +0200, Rolf Gehring [EMAIL PROTECTED] writes: [...] Ehemalige Bereiche mit Namen, die sich auf der eingemeindeten Fläche befinden, haben auch ihren Namen behalten und werden jetzt Ortslage genannt. Es existieren aber auch Flächen, die sind in diesem Sinne nichts. Entspricht deim Nichts einem gemeindefreien Gebiet (siehe u.a. Wikipedia) Auf den amtlichen Karten werden für beide Namen unterschiedliche Schriftgrößen verwendet. Im praktischen Leben werden die Namen gleichwertig verwendet. Im administrativen System sind sie unbedeutend. Fanatiker können sich aber daran aufreiben. :-)) ... also ideal als Diskussion innerhalb OSM :-) Ein Nachteil der Eingemeindung sind die namensgleichen Straßen. Fast jedes Dorf hatte eine Straße, die nach Berlin führte, auch als Berliner Straße benannt. Deshalb besitzt das heutige Berlin unter anderem sehr viele Berliner Straßen. Und Postleitzahlen sind nur selten in Stadtpläne eingetragen. Selbst Havariedienste und ähnliche fahren ab und zu erst einmal in die falsche Straße. Das Problem mit mehrfachen Strassen- und Platznamen gibt es aber in allen Gegenden, in denen es Eingemeindungen gab. Und damit muss eine Adressaufloesung wie der Namefinder oder jeder Router umgehen koennen, genauso wie man an mehrfach vorkommdene Staedtenamen (Neustadt) in einem Gebiet/Land/... denken muss, wenn man eine Adressaufloesung baut. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Ganzer Ort Anlieger Frei
Hallo, andere haben ja schon was zu Anlieger frei geschrieben, aber vielleicht dies als aus Router-Implementierersicht als Ergaenzung: On Wednesday, 26 March 2008 11:10:47 +0100, Frederik Ramm [EMAIL PROTECTED] writes: es gibt hier einen kleinen Ort namens Ettlingenweier, bei dem an allen drei (oder so) Zufahrtsstrassen ein Schild steht, dass Kfze aller Art verboten sind, darunter Anlieger frei (fuer Schilderfetischisten: Zeichen 260 plus Zeichen 1020-30). Darunter steht noch mal extra: Ortsdurchfahrt Ettlingenweier gesperrt oder so. [...] Eigentlich besteht ja eine gewisse Einigkeit darueber, dass residential-Strassen ohnehin nicht zum Durchgangsrouten benutzt werden sollen, d.h. ein guter OSM-Router wuerde mich sowieso nur nach Ettlingenweier locken, wenn ich dort explizit mein Ziel setze. Dennoch muesste irgendwie der Tatsache Rechnung getragen werden, dass man diesen Ort nicht nur nicht durchfahren soll, sondern nicht durchfahren darf... wenn ich nun den Zufahrtsstrassen irgendwie ein Anlieger frei verpasse, wie soll ein Router denn damit umgehen? Du solltest _alle_ Strassen mit einem Anlieger frei versehen, denn das sagen die Schilder am Ortseingang aus ... analog zu einem Tempo-30-Zone-Schild. Muesste streng genommen ein Anlieger frei nicht mit einer Relation auf ein Gebiet verbunden werden, in dem das Anliegen sich befinden muss? Die Ortsdurchfahrt Ettlingenweier ist fuer manche Strecken, deren Start und Ziel ausserhalb Ettlingenweier liegen, durchaus attraktiv; eine allgemeine Regel beim Routing wird Anlieger frei ignoriert, denn dass eine Strecke auf dem kuerzesten Weg zwischen A und B liegt, ist bereits ausreichendes Anliegen, sie zu nutzen wuerde also durchaus fremden Verkehr durch Ettlingenweier fuehren. Nein, Router duerfen die Anlieger-frei-Beschraenkung nicht ignorieren. Eine moegliche Implementierung ist die, dass der Uebergang von normaler zu Anlieger-frei und vice versa mit einer sehr schlechten Bewertung versehen wird, so dass eine optimale Route nur einen einzigen solchen Uebergang aufweisen wird. Diese Impl.-Moeglichkeit ist aber bei einem Start in einer Anlieger-Strasse und einem Ziel in einer zweiten Anlieger-Strasse problematisch, da hier ein zweimaliger Uebergang vorkommt und bei unguenstiger Wahl, wie man den Uebergang bewertet, ein Ueberlauf stattfindet, die kleineren Gewichtungsunterschiede von moeglichen Routen in der (Gleitkomme-) Rechengenauigkeit verschwinden oder doch eine zu unterdrueckenede Durchfahrt einer Anliegerstrasse gefunden wird, weil die Bewertung zu klein gewaehlt wurde. Daher: Fuer einen Router ist ein Anlieger frei am leichtesten so zu implementieren, dass ein Uebergang in Richtung normaler auf Anlieger-frei-Strasse ein Flag gesetzt wird, das besagt, dass danach auf der Route ein erneuter Uebergang weder in die eine (Anliegerstrasse/-gebiet verlassen) noch in die andere Richtung (in selbe/neue Anliegerstrasse/-gebiet einfahren) moeglich sein darf. Damit dies klappt, muessen _alle_ Strassenbestandteile bzw. alle Strassen des Gebietes zusammenhaengend und vollstaendig mit Anlieger frei getaggt sein. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] (benutzungspflichtige) Radwege
Hallo, on Wednesday, 12 March 2008 16:04:09 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Bei Straßenbahnen mag ein eigener way sinnvoll sein, weil ide an ihren way schienen-gebunden sind. Aber selbst da ist es noch nicht einheitlich umgesetzt. Bei den Radwegen überzeugt mich das, was ich bisher mit eigenen ways sah, absolut nicht. Sehe ich aehnlich. Allerdings kranken viele der Vorschlaege, wie man einen Radweg an die Strasse drantaggen koennte, doch ein bisschen daran, dass man die Tags, die den Radweg betreffen, mit denen vermischt, die die Strasse betreffen. Das fuehrt dann manchmal dazu, dass lauter Kunst-Tags erschaffen werden, etwa: highway=secondary surface=paved cycleway=lane cycleway-surface=gravel (nicht, dass ich das den Radfahrern wuenschen wuerde, ist jetzt nur ein Beispiel), oder wenn man noch die Wege links und rechts der Strasse einzeln betrachten will: highway=secondary surface=paved cycleway=lane-left,track-right cycleway-left-surface=gravel cycleway-right-surface=sand cycleway-right-distance-from-road=5 (fuer schoenes rendering!) Naja. Es wird zumindest eklig. (Nicht zuletzt auch wegen des left/ right - irgendwer dreht den Way um, und alles ist kaputt.) Auch bei Tags wie access und so weiter muesste ja dann immer klar sein, ob sie nun die ganze Strasse betreffen samt angegliederter Radwege oder nicht. Was man eigentlich haben muesste, waere sowas wie ein Phantom-Weg, der keine eigene Geometrie hat (weil er einfach nur parallel zur Strasse laeuft), der aber durchaus Tags haben kann. Sowas *koennte* man ueber eine Relation machen, deren einziges member der Way (die Strasse) ist, an dem sich der Radweg befindet: type=cycleway member=way... surface=gravel distance-from-road=5 bearing-from-road=north Auf die Weise koennte man an eine Strasse beliebig viele Radwege, Fusswege, Standstreifen, Gruenstreifen und sonstwas antaggen, und koennte diesen allen ihre ganz eigenen Tags verleihen, ohne dass es zu Konflikten kommt. +1 Mein Vorschlag einer Segmented Tag-Relation, um an einen highway-Way oder ein Stueck davon noch weitere Weg-Eigenschaften anzuhaengen. Da man an einen Weg (bzw. Wegstueck) beliebig viele dieser Relationen haengen kann, sollte man damit auch einen Radweg bzw. die Radwege zu beiden Seiten mit ihren Tags anhaengen koennen. Segmented Tag hat ein anderes Ziel, so dass eine cycleway-Relation sehr gut waere ... bzw. man vereinigt alle aehnlichen Faelle in eine Relation oder eine Familie von Relationen mit aehnlichem Aufbau und gleicher Interpretation. Ach ja: Himmelsrichtungen als Tag-Werte (im obigen bearing-from-road-Tag) halte ich fuer ungluecklich, da nicht alle Wege schoen geradlinig verlaufen und eine Richtung besitzen, die man verwenden kann oder zu der man relativ noch andere Angaben machen kann. Was mache ich bei einem Radweg neben einer Landstrasse, die sich wunderbar ueber das Land schlaengelt? Daher ist eine Angabe wie links oder rechts des Weges eindeutiger, bedingt aber halt, dass der Weg eine Richtung hat (was er im OSM-Datenmodell ja hat) und wenn man diese Richtung im Editor aendert, die Relativangaben (automatisch) mit geaendert werden oder man wenigstens darauf hingewiesen wird. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] josm: Aufspalten von Wegen (was: Radwanderwege, Flussbreite, Zoomstufen, josm)
On Monday, 10 March 2008 17:57:26 +0100, Andreas Jacob [EMAIL PROTECTED] writes: [...] josm Wie gehe ich sinnvoll vor, wenn ich einen Knotenpunkt mehrerer Wege aufspalten will? Bisher habe ich immer in den Wegen rund um den Knotenpunkt noch zusätzlich einen Wegpunkt eingefügt, dann die Wege getrennt, und nun die freien Stücke wieder neu kombiniert. Gibt es da evtl. in josm eine einfachere Möglichkeit? Wieso willst du das tun? Wenn die Wege sich _ebenerdig_ kreuzen, dann muessen sie einen gemeinsamen Knotenpunkt besitzen. Wenn die Wege sich _nicht ebenerdig_ kreuzen (engl. grade-separated crossing), dann muss ein evtl. irrtuemlich eingefuegter gemeinsamer Knotenpunkt aufgeloest werden. Hierbei sollten die kreuzenden Wegabschnitte gleich unterschiedliche layer-Tags bekommen und evtl. mit bridge=yes oder tunnel=yes versehen werden, damit man weiss, welcher Weg ueber bzw. unter den anderen fuehrt. Ich habe das Auftrennen solcher Knoten bislang so gemacht: - bei allen Wegen bis auf einen die beiden Segmente zum Knotenpunkt loeschen (Loeschoperation bei gedrueckter Shift-Taste), - die beiden Knoten verbinden, also den Weg wiederherstellen, dabei darauf achten, dass alle Tags des Weges mit uebernommen wird, - bei Bedarf weitere Knoten einfuegen, um die Geometrie des Weges wieder herzustellen _und_ um den Anfang/Ende der Bruecke/des Tunnels festzulegen, - Wegteile mit anderem layer-Tag-Wert bzw. bridge-/tunnel-Tag vom Weg abtrennen bzw. abgetrennt lassen und mit layer/bridge/tunnel-Tags versehen. Da man so oder so die einzelnen ueber/unter-Abschnitte festlegen und mit den layer-/...-Tags versehen muss, stoert mich diese komplizierte Vorgehensweise nicht allzu sehr, aber wenn es doch einen einfacheren Weg gibt ... :-) Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wie sinnvoll ist: power=tower (be i Zoom 14, oder überhaupt)
Hallo zusammen, On Thursday, 28 February 2008 20:40:35 +0100, Toni Erdmann [EMAIL PROTECTED] writes: ich habe (habe derzeit keine neuen Tracks) einfach mal die Strommasten in der Gegend mit Hilfe von Potlatch und gut aufgelösten Yahoo Images getagged (so weit sie sichtbar sind). Strommasten und -leitungen habe ich auch schon sehr frueh mit aufgenommen: beim Unterqueren von Stromleitungen setze ich immer eine Marke, frei zugaengliche Strommasten umrunde ich kurz. Sie sind nun aber schon in Zoom 14 bei Mapnik zu sehen, was ich ehrlich gesagt so 'früh' nicht erwartet hätte. Zoom 16 wäre wohl besser. http://openstreetmap.org/?lat=48.011lon=11.676zoom=14layers=B0FT Was ist Eure Meinung? Zoom 14 ist sicherlich zu frueh, Osmarender/[EMAIL PROTECTED] zeichnet die Masten und Leitungen erst zwei Zoomstufen spaeter, also Zoom 16, mit ein, was ich ok finde. Da man den Leitungen eine kV-Angabe spendieren kann, koennte man diese Angabe nutzen, um wichtigere Stromleitungen bereits in Zoom 14 oder 15, kleinere oder nicht entsprechend ausgezeichnete erst ab Zoom 16 einzuzeichnen. http://openstreetmap.org/?lat=48.8082lon=9.3228zoom=14layers=B0FT Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [OSM-talk] displayed width of roads
On Monday, 18 February 2008 16:01:46 +, 80n [EMAIL PROTECTED] writes: It's definitely wrong to adjust the layer just to make the rendered output look better. If a renderer has deficiencies use render-specific tags to solve them ... until the renderer is fixed to make these tags obsolete. The layer tag should represent the true relative position of roads. Incidentally, if a ramp connects two roads at different levels then should it be layer=0 at one end and layer=1 at the other, with the split somewhere in the middle? I don't see how else you can correctly represent a ramp. IMHO: No, the ramp does not need a split to tag different layer values, only the crossing ways needs tags with different layer value. On the other hand: a ramp can be subclassified as exit ramp or entrance ramp of a road. If a ramp is both because it connects two motorways etc., you can split the ramp into an exit ramp part and an entrance ramp part. Best wishes, -bernd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Bach und Wege
On Monday, 18 February 2008 08:12:45 +0100, Martin Simon [EMAIL PROTECTED] writes: Am Sonntag, 17. Februar 2008 18:53:43 schrieb Dirk-Lüder Kreie: Martin Simon schrieb: Naja, jeder vernünftige Renderer wird annehmen, daß innerhalb eines Layers bäche, Kanäle u.ä. unterhalb von Wegen angeordnet sind. Nein, auch in Mitteleuropa existieren noch Furten. ...die sich einen Punkt mit dem Bach/Fluß teilen, der mit highway=ford getaggt ist. Das sollte als Unterscheidungsmerkmal genügen. Mir fiel als Sonderfall dann noch Aquaedukte ein ... und davon gibt es in Form der Waale, d.h. von Bewaesserungsgraeben, auch einige, die _ueber_ Wegen gefuehrt werden. Wie Andreas Bruecker ja schon schrieb, kann man die Bruecken von Wegen ueber einen Bach oder den Tunnel eines Baches unter einem Weg eindeutig taggen und mit entsprechenden layer=-Werten versehen ... und als Seiteneffekt bekommt man mit maplint/Validator/... dann auch gleich bei unsauber getaggte Dingen, die zu kreuzenden Wegen auf demselben Layer fuehren, einen Hinweis auf diesen Fehler. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] JOSM - Ids von Nodes, Ways anzeigen (was: Fahrradrouten als Tracks generieren)
Hallo, on Wednesday, 13 February 2008 22:20:11 +0100, Christoph Eckert [EMAIL PROTECTED] writes: Bei Ways und Nodes wäre das manchmal auch ganz hilfreich. Bisher muss ich dafür immer Potlatch bemühen. also dafür nehm' ich die mittlere Maustaste. Hilft allerdings nur bei Wegen, nicht bei Nodes oder Relationen - vor allem letztere lassen sich so schlecht anklickern :) . Tipp: Im Menue Preferences - Advanced Prefs folgende Key-Value-Paar eingeben: osm-primitives.showid = true Neu starten, das Fenster mit der aktuellen Auswahl aufmachen, falls noch nicht offen ... und schon hat man bei jeder selektierten OSM-Primitiv die entsprechende Id stehen. Use the Source! :-) ... oder hat jemand eine Aufstellung der Prefs? Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Fahrradrouten als Tracks generieren
Hiho, on Wednesday, 13 February 2008 21:58:53 +0100, Christoph Eckert [EMAIL PROTECTED] writes: http://www.openstreetmap.org/api/0.5/relation/nummer/full in einem Rutsch alle Ways und Nodes kriegen, die Du brauchst, um die Relation abzubilden. Dann noch ein winziges bisschen XSLT oder so ;-) und Du kriegst ein GPX-File daraus. Aber dieses winzige bisschen muss halt irgendjemand mal schreiben ;-) wenn man sich auf diese Weise eine Route holt, die aus einer Relation gebaut ist, stellt sich die interessante Frage, ob die Nodes in der resultierenden osm-Datei in der Reihenfolge vorliegen, wie man sie haben will. Noe, ganz sicher nicht! Waere wohl schon ein Wunder, wenn die Wege in einer bestimmten Reihenfolge vorlaegen, so dass man nur noch entscheiden muesste, welche von diesen man evtl. umdrehen muesste, damit die Knoten aufeinanderfolgend sind. Falls ja (und ich halte es für eine schlechte Idee sich darauf zu verlassen) könnte man sich ja die Koordinatenpaare 'rausgreppen und das dann irgendwie verhackwurschteln. Wenn du dir einige Routen-Relationen herausziehst und mal anzeigen laesst, wirst du feststellen, dass es da immer mal wieder Luecken gibt. -- Auch ich zerlege Wege bzw. fuege neue ein und achte nicht immer darauf, ob da eine Routen-Relation dranhaengt. Kehren wir aber lieber nochmal zur Problematik der Reihenfolge zurück. Es sei gegeben eine Routenrelation mit drei Wegen mit jeweils drei Nodes. Wer bitte sagt denn, wie die Reihenfolge der Wege sein soll? Die Relation ist ja meinem Verständnis nach unordered. Um also das Ganze in einen Track konvertieren zu können, müsste ich selbst erstmal die Topologie ermitteln. Ja. Es bleibt einem nicht anderes, als alle Wege durchzugehen und diese an gemeinsamen Endknoten zu verbinden. Dabei hat man eben nur das Problem, dass es (a) Luecken gibt, dass (b) Zirkel sich bilden koennen, dass (c) Endknoten nur visuell verbunden scheinen, aber nicht in der Datenbank (2 Knoten mit 5m Abstand o.ae.), das (d) Routen nicht linear sind, sondern sich aufspalten koennen oder muessen (z.B. wegen Einbahnstrassen oder anderer Restriktionen). Waere etwas fuer einen Validator-Test ... Falls ich das richtig sehe hier die Preisfrage: Ich könnte mir vorstellen, dass es mitunter mehrere Möglichkeiten gibt, die Route über die gegebenen Wege abzufahren. Ist folglich das Mappen von Routen über Relationen evtl. nicht immer eindeutig? Wenn die Route in der Realitaet eindeutig ist, sollte sie sich auch eindeutig in der Datenbank wiederfinden bzw. aus dieser extrahieren lassen (wobei es fuer die beiden Richtungen unterschiedliche Teile einer Route geben kann). Wenn nicht, hat man noch einen Mapping- Fehler. Oder? Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] unechte Einbahnstraße
On Tuesday, 12 February 2008 20:27:00 +0100, Heiko Jacobs [EMAIL PROTECTED] writes: Noch 'ne Frage... Wie taggt man unechte Einbahnstraßen, also welche, wo auf der einen Seite zwar mit der roten Spardose (mit oder ohne Radler frei) oder rotem Kringel (mit oder ohne Inhalt wie Kfz) die Einfahrt verboten wurde, aber auf der anderen Seite das Einbahnstraßenschild fehlt, so dass ein Autofahrer wenden könnte, wenn er wollte? Oder aus einem dortigen Parkhaus o.ä. in beide Richtungen aus der Straße raus. Beim praktischen Gebrauch dürfte echte Einbahnstr. am nächsten kommen. Ist aber nicht ganz korrekt... Kompliziert oder einfach? Kompliziert: Ueber eine Abbiegebeschraenkung (Turn-Restriktion), die ein Verbot ausdrueckt, von allen anderen Strassen in diese Strasse abzubiegen. Siehe Relations, ist aber momentan noch nicht richtig fix definiert. Einfach: Vom Weg beim Verbotsschild ein kleines Stueckchen abknapsen und dieses per oneway=yes in eine entsprechende Einbahnstrasse umwandeln. Restlicher Way ohne oneway belassen. Hat den Vorteil, dass es die Realitaet ganz gut ausdrueckt und dass man keine Relationen benoetigt. Ich habe die einfache Methode beim Mappen von Stuttgart-Bad Cannstatt an einigen Strassen im Bereich des LKA genauso eingesetzt. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Relations für Teilwege
On Monday, 11 February 2008 19:50:40 +0100, Frederik Ramm [EMAIL PROTECTED] writes: [...] Ich dachte eigentlich zuerst, dass wir das Problem durch die sogenannten Superways loesen; wie oben richtig festgestellt, gibt es da noch Probleme beim Editieren, aber das ist ja nur was Voruebergehendes. Wenn mit Superways die vorgeschlagene Relation Collected Ways gemeint ist, dann haette ich damit immer noch das Problem, nicht alles abdecken zu koennen ... bzw. dies nur mit einer Super-Super-...-Ways- Hierarchie zu koennen, d.h. die zerschnippelten Ways wieder zu einer etwas groesseren Einheit zusammenzufassen, die man wiederum zu noch groesseren Einheiten zusammenfassen kann etc. Oder war da was anderes andiskutiert? Die Verwendung einer Relation als qualifiziertes Tag hatte ich fuer andere Sachen im Hinterkopf; ich dachte, man koennte damit sowas eintragen wie dieser Way ist Einbahnstrasse, aber nur fuer LKW oder so. Mmmh, das hoert sich fuer mich wie ein Composite Tag an, d.h. eine Menge von zusammengehoerigen Tags (vgl. Composite Attributes aus GDF), wobei eben einige Kombinationen haeufiger vorkommen: (a) Beschraenkungen auf das Verkehrsmittel (Vehicle Type bzw. Means of Transport), (b) zeitliche Beschraenkungen, die sowohl exakte (Mo-Fr 22:00-6:00) als aus unscharfe (bei nasser Fahrbahn, bei Flut etc.) Zeitangaben sein koennen. Mehrere Mengen von zusammengehoerigen Tags bekommt man momentan nur ueber mehrere Relationen mit ihren jeweiligen Tag-Mengen, die man an einen Way (oder an mehrere Ways) haengt. (c) Ausserdem koennen die Tags auch noch richtungsabhaengig und im schlimmsten Fall auch noch fahrspurabhaengig (bspw. 110, 80, 60km/h auf einer dreispurigen Autobahn) sein, d.h. hier gibt es einen oertlichen Bezug. Nun wird vorgeschlagen, Tags auf andere Weise zu qualifizieren, und zwar dieser Way ist Einbahnstrasse, aber nur von Node A bis Node B. ... und genau dieser oertliche Bezug geht in OSM nur ueber den Node, der als einziger eine Koordinate besitzt, und den Way als Folge von Nodes. Da liegt dieser Vorschlag doch nahe, oder? Im Prinzip finde ich das eine gute Idee; eventuell koennte man das mit den angedachten Superways auch verbinden: * Eine Relation, die einen Way und zwei Nodes als Member hat, sagt aus, dass ein bestimmtest Tag auf dem Way von Node 1 bis Node 2 gilt. ... wobei Node1 und Node2 in der Node-Menge des Way zwingend enthalten sein muss. * Ebenso koennte eine solche Relation auch mehrere Ways als Member haben, gibt ja keine Notwendigkeit, das auf einen Way zu beschraen- ken; die Grenz-Nodes koennen optional weggelassen werden, wenn das Attribut fuer die ganze Strecke gilt. (Das waeren dann die Superways.) ... wobei alle Ways verbunden sein muessen, d.h. je zwei Wege haben einen gemeinsamen Endknoten (oder reicht ein Mittelknoten, was passiert mit den dann abstehenden, also den restlichen Way-Teilen -- sind die im Superway drin?). Darf solch ein Superway auch entartet sein, d.h. einen Baum, gar einen Zyklus oder ein Geflecht bilden? Ich denke, fuer einen Superway sollte man nur komplette Wege aufnehmen, d.h. sollen Teile von Wegen mit aufgenommen werden, dann muessen diese entsprechend zerschnitten werden. * Die Annhame, dass ein Attribut immer an einem Node beginnt und endet, ist eventuell eine ueberfluessige Einschraenkung; man koennte eventuell, wie bei GDF, auch zulassen, dass man eintraegt ab Position 800m bis Position 1200m auf dieser Strasse absolutes Halteverbot. Dann haette man allerdings wieder eine Richtungsab- haengigkeit. GDF-Kanten besitzen keine expliziten Laengen, d.h. jeder berechnet sich seine eigene Laenge einer Kante aus der Koordinatenfolge der enthalten Knoten. Und je nach Ansatz, nach Genauigkeit der Berechnung und Rundungen bekommt man unterschiedliche Ergebnisse (die alle noch in der erforderlichen Genauigkeit liegen) ... aber letzlich ist eine Positionsangabe wie 1200m auf einer errechneten 1197m langen Kante schon etwas ungeschickt, oder? Daher sind entweder relative Angaben besser (also bspw. von 66% bis 100% der Kante), oder man setzt gleich an die passende Stelle mit dem Verkehrszeichen (oder wenn die Anzahl der Spuren von 3 auf 2 wechselt) noch einen Knoten, falls noch nicht vorhanden, und gibt diesen Knoten als Position an. Die Positionsangabe durch Knoten macht es auch einfacher, wenn man einen solchen Weg spaeter doch in mehrere Wege zerschneidet (der Knoten bleibt dabei unveraendert, die Relationen werden in alle relevanten Wege uebertragen und in einem der Wege wird der Knoten als begrenzende Position in die Relation eingetragen; dto. fuer den zweiten Knoten). Ebenso wenn man mehrere Wege zusammenfasst, denn auch dies aendert nichts am Knoten und dessen begrenzender Eigenschaft fuer die Relation. Sowohl bei den Laengenangaben als auch den relativen Prozentangaben muss man erst einmal rechnen (verrechnen:-), wo die
Re: [OSM-talk] correctly mapping avenues
Hi, on Sunday, 10 February 2008 08:34:31 -0800, Karl Newman [EMAIL PROTECTED] writes: On Feb 10, 2008 4:21 AM, Frederik Ramm [EMAIL PROTECTED] wrote: Since trees lining a way/street are such a common occurence, why not have a simple additional tag to the main road. lined_by_trees=yes/no/left/right I'm a bit unhappy about needlessly inflating the importance of the direction of ways. Long-term, I would actually like to get rid of the direction and express everything in relations. This means, that you find it necessary to have something like a direction or a side, both of this features related to a way? But you don't want to express a direction or a side by the _implicit order_ of the way nodes. The reasons for this are (a) the direction is too easily changed, sometimes by mistake ... because none of the current OSM editors show direction- or side-related tags explicitly. (b) there might be multiple conflicting things that rely on the direction, e.g. a road that is oneway from A to B but has a slope from B to A Anything with left/right in it also relies on direction. I'd prefer east/west/north/south, or using an explicit relation that says trees on the right between nodes A and B along road C. I am against east/west/north/south because there are a lot of ways/areas/things which do not go straight ahead. Okay, this thread is at risk of spinning wildly off-topic, but I've been thinking about this situation recently. It seems to clamor for the use of specialized relations that are direction-aware. That way, if a way is a member of a relation and has directional properties (left/right), then the editors could look for those relations when the way is reversed and either fix them automatically or at the minimum raise a warning dialog. I also had some other ideas about enforcing referential integrity for another type of specialized relation (if one or more node relation members is required to be part of a way relation member, then enforce that rule). That rule could actually be enforced by the API. These specialized relations would just give some structure to the wide-open relation type, without implying anything about the nature of the relation. It could possibly be accomplished through special tags on the existing relation structure. Do you have any propositions how this will look like or how this should be done? A few days ago I have started a new proposal for a Segmented Tag, which relates a set of tags to a directed or undirected part of a way (I have called this part segment inspired by GDF's Segmented Attributes). I have not found the time yet to finalize the proposal adding some examples, nonetheless it can already be found in the OSM Wiki (Relations/Proposed/Segmented Tags). Best wishes, -bernd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [Talk-de] Relations für Teilwege
Hallo zusammen, On Sunday, 10 February 2008 08:24:24 +0100, Karl Eichwalder [EMAIL PROTECTED] writes: Derzeit müssen wir ja dauernd Straßen u.ä. zerschneiden weil z.B. teilweise 50km/h und teils 70 gefahren werden darf, oder weil nur ein Teil einen Fahrradweg hat oder... Diese ganzen Wegstückchen vereinfachen die Eingabe nicht unbedingt. Will man z.B. einer Straße nachträglich noch ein Atribut geben muß man alle Teile zusammensuchen. Danach geht man dann mit Relations wieder hin um Teile zusammenzufassen. Was wiederum zu Problemen führt wenn eines der Member nachträglich zerschnitten wird, wie vor kurzem berichtet. Wäre es nicht praktischer wenn man den umgekehrten Weg geht. Also möglichst eine Straße = ein way. Will man dann Tempo 50 für das Teilstück der Hauptstraße von Node xyz4 bis Node xyz7 setzen so zerschneidet man die Hauptstraße nicht an den beiden Nodes sondern macht eine Relation: way=Hauptstraße start=xyz4 end=xyz7 maxspeed=50 Haben wir diesen vorschlag eigentlich schon besprochen? Ich war auch ziemlich überrascht, als ich zum ersten mal von dem zerschnipseln hörte. Segmente durch die hintertür... Aber nun ist es wohl erstmal zu spät. Dsa mit dem Zerschnippeln von Ways wegen Bruecken, Tunneln etc. wurde in dieser Liste in der kurzen Zeit, in der ich sie lese, immer wieder angesprochen. Auch ich habe das immer wieder angesprochen, da ich wie in Dimitris zitierten Mail (von Ende Dez. 2007) einige Strassen habe, die unterschiedliche Geschwindigkeitsbeschraenkungen fuer die beiden Richtungen besitzen und diese sogar fuer unterschiedliche Abschnitte gelten, so dass ich teils alle 100-200m einen neuen Way beginnen muesste, ohne dass sich eine andere Strassen-Eigenschaft aendert. Letzlich waere man dann bei GDF, wo bei jeder Aenderung eines Line-Feature-Attributs ein neues Line-Feature begonnen wird (ein Line-Feature waere in OSM ungefaehr ein Way bzw. ein Teil-Way von Kreuzung- zu Kreuzung). Die einzige Abhilfe fuer diese Problem ist tatsaechlich, dass man das Zerschnippeln von Ways fuer diese Einfachst-Eigenschaften vermeidet, einen Teil-Way durch eine Relation festlegt und diesen Teil-Way mit einem Satz von Tags versieht. Ich habe diesen Vorschlag am Freitag mal im OSM-Wiki begonnen (Relations/Proposed/Segmented_Tag), will ihn aber noch um ein paar Dinge (off. Diskussions- und Abstimmungsteil) und konkrete Beispiele ergaenzen und danach damit auf die talk-Liste. Ach ja: Ich habe den Begriff Segment gewaehlt, obwohl er IMHO mit den alten Segmenten aus pre-0.5-API verwechselt werden kann, auch wenn er nur wenig damit zu tun hat. Im Datenmodell bis API 0.4 war ein Segment ein Weg-Atom, d.h. eine Strecke/Verbindung zwischen zwei Nodes, und ein Way bestand aus einer Folge von Segmenten. Ab API 0.5 besteht ein Way nun aus einer Folge von mind. 2 Nodes. In meinem Vorschlag ist ein Segment nun ein _beliebiger_ Abschnitt eines Way, der durch zwei Way-Nodes festgelegt wird, und den Begriff Segmented-Tag habe ich in Anlehnung an den Begriff Segmented-Attribute aus GDF verwendet. Durch ein Segmented-Tag haette man nun die Moeglichkeit, explizit 1. fahrtrichtungsunabhaengige Tags anzugeben (per Relations-Tag direction=positive,negative,both), 2. diese auch fuer den gesamten Weg anzugeben (from- und to-Node sind Start- und Endknoten des Ways) oder auf einen Teilweg einzuschraenken (from- und to-Node sind andere Knoten des Ways) und 3. gleichzeitig waere es moeglich, Composite-Tags anzugeben (man kann beliebig viele weitere Tag- und Tag-Kombinationen bei der Relation angeben). Da man beliebig viele dieser Segmented-Tag-Relationen an einen Way haengen kann, kann man so alle moeglichen Kombinationen von einfachen und zusammengesetzten(/composite) Tags fuer einen Way angeben. Offen und sicher Anlass fuer Diskussionen: Wann setzt man diese Relation ein und wann zerteilt man doch besser einen Way in mehrere Ways? Oder: welche Eigenschaften (Aenderung einer oder mehreren Eigenschaften) legen es nahe, dass man zerlegt, welche legen es nahe, dass man die Relation einsetzt und den Way nicht zerlegt? Nachtrag: Ich sehe die Relation Collected Ways zum Zusammenfassen der einzelnen Wege zu einer groessern Einheit immer noch als Ergaenzung dieser neuen Relation und als notwendig an. Nur damit kann ich Wege zu einer groesseren zusammenhaengenden Einheit auszeichnen. Schoenes Wochenende, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Radwege und Br?cken
On Monday, 4 February 2008 16:42:06 +0100, Guenther Meyer [EMAIL PROTECTED] writes: Am Montag 04 Februar 2008 schrieb Raphael Studer: 2008/2/4 Michael Bergbauer [EMAIL PROTECTED]: On Mon Feb 04, 2008 at 01:3902PM +0100, Andr? Reichelt wrote: Eine etwas leienhafte Idee wäre es einfach, den Weg auf die Straße führen zu lassen und die Straße das Stück über für Fahrräder freizugeben.a diese methode ist vor allem falsch, da der radweg ja neben der strasse und nicht darauf liegt. das muesste man den renderer auf eine andere art mitteilen... Fuer so etwas gibt es cycleway=track oder cycleway=opposite_track, siehe http://wiki.openstreetmap.org/index.php/Key:cycleway Diese Methode hat aber auch ihre Nachteile: z.B. muss man dann fuer die Bruecken jeweils eigene Highway-Abschnitte machen. Entsprechend oft werden dann auch die Strassennamen wiederholt, was die Karte nicht unbedingt schoener macht. Muss man für die Brücke nicht sowieso einen neuen Abschnitt machen? Sonst kann man sie ja gar nicht als Brücke taggen, oder hab ich da irgend etwas verpasst? ja, muss man. ... wenn man noch die alten Segmente haette, koennte man nur diese ..., aber da es nurmehr Ways als OSM-Objekt (neben Node und Relation) gibt, muss man sich etwas neues einfallen lassen: - Entweder zerpflueckt man einen Way in mehere kleine Teil-Ways, sobald sich eine signifikante Eigenschaft aendert, und anschliessend bastelt man diese Weg-Stuecke wieder mit der Relation Collected Way (siehe OSM-Wiki) zu einem ganzen Weg zusammen. - Oder man laesst den Weg so wie er ist und zerstueckelt ihn durch eine andere Relation in einzelne durch Nodes begrenzte Abschnitte mit entsprechenden Eigenschaften. (Diesen Vorschlag findet man nicht im Wiki, sondern in einer alten E-Mail von mir im Archiv. Ich hatte bislang noch nicht die Zeit, das zu den Relations/Proposed-Seiten hinzuzufuegen.) Letztlich geht es um die Frage, ob ich wie bisher eher lange durchgehende Kantenzuege bevorzuge, wobei einige Knoten die (routing-relevanten) Kreuzungspunkte mit anderen Kantenzuegen festlegen, einige bis viele andere Knoten die Geometrie bestimmen und einige Knoten wiederum Attribut-/Tag-Abschnitte festlegen. Oder ob ich bei jeder Attribut-Aenderung immer einen neuen Kantenzug beginne, je mehr Attribute vorhanden sind also eher viele kurze Kantenzuege bekomme. In diesem Falle waere zu ueberlegen, ob man die Kantenzuege nicht bei den wenigen Kreuzungsknoten nicht auch noch auftrennen kann (wie bei GDF), so dass im Kantenzug nurmehr die geometrie-bestimmenden Knoten verbleiben. Ich bin mir nicht so im klaren, welche der beiden Optionen die geeignetere, sinnvollere, einfachere ist ... zumal man fuer beide Herangehensweisen noch etwas bessere Editor-Unterstuetzung (fuer die jeweiligen notwendigen Relationen) benoetigt als momentan vorhanden, damit das Mappen schnell (und auch einigermassen fehlerfrei) von der Hand gehen kann. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] New JOSM Plugin Validator Test: UnconnectedWays (was: Reisezeiten)
Hallo zusammen, on Sunday, 27 January 2008 12:23:04 +0100, Bernd Raichle [EMAIL PROTECTED] writes: [...] Das groesste Problem aber ist leider immer noch, dass ich sehr haeufig nicht verbundene Way-Kreuzungen vorfinde, d.h. wo die Endknoten von zwei oder mehr Ways nicht verbunden sind, sondern nur knapp nebeneinander liegen. Und dies ist fuers Routing nun wirklich problematisch, da damit gerade die Routen im Nahbereich, also beim Start oder Ziel, oft unsinnige Ergebnisse liefern. Hier waere ein maplint- bzw. Josm-Validator-Test wirklich hilfreich, auch wenn ein solcher Test oefters false positives liefern wird, wo Wegenden sehr nahe beieinander liegen, aber eben doch (durch Mauern, Zaeune, unterschiedliche Hoehen) unueberwindbar getrennt sind. [...] Tja, und wer eine erste Version des oben beschriebenen Josm-Validator- Plugin-Test mal selbst ausprobieren will, lade sich validator.jar hier herunter: http://www.dante.de/~bernd/osm/ Dort findet man neben dem Jar-File auch die Quellcode-Patches. Und dort werde ich auch noch nach und nach meine weiteren Patches (area ohne closed ways, layer=+1 statt layer=1, falsche bridge/tunnel/ layer/track_type-Werte, fehlende level_crossing, ungueltige level_crossing etc.) ablegen. Ich habe damit schon einen Grossteil solcher fast- bzw. nur visuell verbundenen Wege in einigen Gebieten der bisherigen OSM-Daten gefunden. Bin an Rueckmeldungen interessiert, um den Test noch zu verbessern. Ausserdem benoetige ich noch Hinweise, wie der Test bei anderen Wegen als highway ausgedehnt werden soll. Zur Info: Dave Hansen hat in den Mailing-Listen josm-dev und dev seinen JOSM-Jumbo-Patch mit ebenso erweiterten Validator-Tests (fuer Probleme mit den TIGER-Daten) angekuendigt. Aber Achtung: Da er gleichzeitig einiges an den Innereien von JOSM aendert, laufen seine Validator-Patches nicht mit einem normalen JOSM. Schoenes Wochenende, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Offene Schnittstelle für Icons
On Tuesday, 29 January 2008 01:50:01 +0100, Ulf Lamping [EMAIL PROTECTED] writes: [...] Also erstmal, die Icons sind eigentlich nicht mehr wirklich das Problem, [...] Das Problem ist bei Osmarender / Mapnik, daß es keinen richtigen Konsens darüber gibt, was eigentlich auf die Karten soll. Die anscheinend vorherschende Meinung ist, die sollte schön aussehen - also nicht alle Icons enthalten. Ich hatte bereits mehrfach angeregt auf einer der beiden Karten in hohen Zoomlevels möglichst alles an POIs draufzubringen, damit Mapper eine Möglichkeit zur Kontrolle zu haben, aber da gibt es Widerstand sieht ja nicht schön aus. Wenn ich mit den Icons soweit fertig bin, schaue ich mir vielleicht mal eine der beiden Renderer genauer an, was da wirklich noch fehlt ... Was spraeche gegen einen oder mehrere POI-Layer, die man wie den maplint-Layer zu den Karten dazuladen kann? Ich kann nicht abschaetzen, wieviel Aufwand das ist, bei mapnik und osmarender/ [EMAIL PROTECTED] noch weitere Layer zu rechnen und in der Slippy-Map einzubinden, aber das wuerde auf alle Faelle die beiden Lager sollte schoen aussehen und will alles zur Kontrolle sehen befriedigen. Man koennte auch einen weiteren Layer fuer weitere Weg-Tags wie lanes, maxspeed etc. und/oder den vorhandenen Relationen erzeugen, um einen Ueberblick darueber zu bekommen. -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, on Sunday, 27 January 2008 17:09:03 +0100, qbert biker [EMAIL PROTECTED] writes: Jupp, auch die GDF-Daten der beiden Grossen lassen von der Functional Road Class nicht direkt auf Geschwindigkeiten bzw. Reisezeiten ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur zusammen mit anderen Attributen (Form-of-Way, innerorts vs. ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute Kanten-Reisezeiten. Stimmt und deshalb geht mein Vorschlag dahin, ein paar Attribute einzuführen, die im Gegensatz zu 'highway' einigermassen exakt definiert sind und sich mit diesen Punkten beschäftigen. 'highway' ist IMHO genau genug definiert, denn als Anfaenger kam ich mit der Beschreibung auf der englischen bzw. der deutschen Wiki-Seite ganz gut zurecht ... auch weil ich die in dieser Liste immer wieder hoch gekommene _administrative_ Zuordnung ignoriert habe (die gehoert IMHO in's ref-Tag bzw. einem weiteren noch nicht beschriebenen Tag wie ref_admin_level o.ae.). Aehnlich wie in GDF die Functional- Road-Class (FRC) ist highway halt auch ein Kuddelmuddel und schwammig ... man vergleiche nur mal die FRC-Einordnung der beiden grossen Kartenhersteller miteinander, die sind sich auch nicht immer einig! Ok, aber welche Attribute willst du denn genau, die ein Routing mit brauchbaren Ergebnissen erst ermoeglichen sollen? Ich baue keinen Router auf der highway-Info auf, weil ich nicht weiss, was sich der Mapper bei seinem Eintrag gedacht hat. Die statische Reisezeit (ohne Staus, etc.) wird ganz wesentlich von drei Bedingungen beeinflusst: Ausbau, Vorfahrt und Restriktionen wie Geschwindigkeitsbeschränkungen. Kurvigkeit ist eine ganz spezielle Geschichte und geht ja direkt aus dem Verlauf hervor. In den GDF-Daten finde ich weder Ausbauzustand, noch Vorfahrt, noch Geschwindigkeitsbeschraenkungen _flaechendeckend_ vor. Wieso koennen dann alle Router/Navis darauf brauchbar routen? In den im Markt befindlichen Releases sind Speed-Limits nur fuer die Hauptverkehrsstrassen aufgenommen, alle anderen werden aus der Inner-/Ausserorts-Beziehung abgeleitet (sprich: 50 bzw. 100 in D). Vorfahrts-Beziehungen sind nur vereinzelt vorhanden. Ausbauzustand gibt's neben den FRC und getrennte Richtungsfahrbahnen direkt nur ein paved/unpaved. Was braucht man zum Routen? Zum einen eine Optimierungsfunktion, die fuer die schnellste Route eben die aufsummierten Kanten-Reisezeiten minimiert. Zum anderen fuer jede Kante eine Reisezeit ... und genau die kann ich mit ein paar Heuristiken, sprich angenommenen Geschwindigkeiten aus den vorhandenen GDF-, aber auch aus den vorhandenen OSM-Attributen und -Relationen mir erstellen. Dazu gibt der FRC bzw. highway aber nur eine erste Grobklassifikation, die aber durch andere Attribute wie oneway (deutet bei langen Kanten auf getrennte Richtungsfahrbahnen hin), maxspeed (daraus bekommt man momentan ausserorts, innerorts, 30er-Zone), roundabout und Dingen wie kurze Kantenstuecke/viele Kreuzungen (mit/ohne Ampeln), Kreuzungen mit *_link etc. ganz gut ergaenzt einem eine Durchschnitts- geschwindigkeit ableiten lassen, die gut genug zum Routen ist! Im derzeitigen Zustand der Karte findet der Router wichtige Verkehrsbeziehungen nicht, weil sie aus der administrativen Zuordnung nicht hervorgehen. Ein schönes Beispiel ist die Umgehung von Rosenheim (OBB). Die ist derzeit als secondary drin und war schon mal tertiary. Damit ist sie nicht mehr aus dem normalen Hauptstraßengewirr herausgehoben und der Router schickt die Leute auf dem kürzesten Weg durch die Stadt, also mitten durch den Rummel mit vielen Ampeln. Dann ist die Ableitung deine Kantengewichte (sprich Kanten-Reisezeiten) schlecht. Die Umgehungsstrasse (du meinst du ihm Sued-Osten?) hat kaum Kreuzungen, und selbst die sind per oneway-Verbindungen also Auffahrten angelegt, ausserdem sollte sie ein entsprechendes maxspeed-Tag besitzen, das mit einem Wert 50 km/h eine Ausserorts-Klassifizierung zulaesst. Damit sollten die Reisezeiten hierauf entsprechend kleiner sein, so dass die inneroertlichen Strassen beim Routing schlechter abschneiden. Wo liegt da das Problem? ... ausser dass man halt etwas Hirnschmalz in eine passende heuristische Zuordnung von Kanten- Durchschnitts- geschwindigkeiten legen muss. Aber dies _muss_ man bei einer GDF- Karte (und auch bei den AND-Karten) auch tun. Eine Heuristik a la ``ich bleibe zuerst auf der Strasse mit hoeherem highway-Tag'' fuehrt einen auf alle Faelle in die Irre, da ich dann in deinem Beispiel zuerst mal von Sueden her kommend auf der B15 bis zum Eisstadion und evtl. noch weiter durchfahren werde, so dass ich dann bereits in der Stadt bin. Alles was ich will ist, dass der Mapper (und damit auch ich ;)) ein Werkzeug an die Hand bekommt um auf die Straße zu schauen und die
Re: [Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, on Monday, 28 January 2008 11:53:19 +0100, Guenther Meyer [EMAIL PROTECTED] writes: Am Montag 28 Januar 2008 schrieb Bernd Raichle: on Sunday, 27 January 2008 17:09:03 +0100, qbert biker [EMAIL PROTECTED] writes: [...] 'highway' ist IMHO genau genug definiert, denn als Anfaenger kam ich mit der Beschreibung auf der englischen bzw. der deutschen Wiki-Seite ganz gut zurecht ... auch weil ich die in dieser Liste immer wieder hoch gekommene _administrative_ Zuordnung ignoriert habe (die gehoert IMHO in's ref-Tag bzw. einem weiteren noch nicht beschriebenen Tag wie ref_admin_level o.ae.). Aehnlich wie in GDF die Functional- Road-Class (FRC) ist highway halt auch ein Kuddelmuddel und schwammig ... man vergleiche nur mal die FRC-Einordnung der beiden grossen Kartenhersteller miteinander, die sind sich auch nicht immer einig! Ok, aber welche Attribute willst du denn genau, die ein Routing mit brauchbaren Ergebnissen erst ermoeglichen sollen? ich bin kein routing-experte, drum kann ich das nicht wirklich beurteilen. aber um eine strasse einigermassen realistisch abzubilden wuerde ich auf jeden fall folgende tags als minimalen standard verlangen wollen: highway:width = breite der strasse (nicht in zentimetern, sondern in ein paar definierten abstufungen) Hast du fuer diese Abstufungen einen Vorschlag? Unter width wuerde ich als Anfaenger jedoch annehmen, dass ich hier die tatsaechliche (befahrbare) Breite in Meter oder Zentimeter angebe, evtl. halt auch geschaetzt. Du meinst da wohl eher so etwas wie width_class o.ae. Hier koennte man dann beschreiben, ob die Spuren volle Breite haben (lkw-faehig), ob es einen befestigten Seitenstreifen oder gar eine komplette Standspur gibt. Dabei waere ein Blick ueber die Grenzen auch noch wichtig, da ein Vorschlag auch fuer andere Laender passend sein sollte. highway:lanes = anzahl der fahrspuren pro richtung (default-wert = 1) Das Tag lanes=... gibt es. (Mir fehlt da eher noch eine Moeglichkeit zu sagen, dass in eine Fahrtrichtung nur eine, in die andere 2 Spuren zur Verfuegung stehen. Was gebe ich denn bei einer Bundesstrassen mit zusammen 3 Spuren, wobei die mittlere wechselweise zum Ueberholen verwendet wird, fuer lanes an? lanes=1.5? Sollte aber wohl eher die minimal number of lanes sein.) highway:ref_loc = laenderspezifische zuordnung, wie z.B. Kreisstrasse in deutschland, um z.B. eine augsburger kreisstrasse (A123) nicht als autobahn zu sehen. Man wird hoffentlich nie anhand des Praefixes der Strassennummer auf die Art schliessen, oder? Hierfuer ist highway eindeutiger! Statt ref_loc wuerde ich eher ref_type bzw. ref_level mit Werten = 1 verwenden (entsprechend nat_ref_type etc. fuer die anderen *_ref-Tags). Werte fuer D: 1=E, 2=BAB, 3=B, 4=L+St, 5=K, evtl. 6 und groesser fuer andere Laender. In einem Vorschlag sollte man zumindest fuer die wichtigsten Laender eine Zuordnung zu den nationalen Bezeichnungen aufnehmen, um ein stimmiges Bild zu bekommen. optional noch folgende: highway:ref = administrative bezeichnung, wie z.B. B22 Es gibt bereits das ref-Tag. highway:surface = Oberflaechenbeschaffenheit, angegeben in definierten kategorien, um zu unterscheiden ob die strasse z.B. schoen eben ist, oder nur aus schlagloechern oder kies besteht. Die Vorschlage Road Surface, surface values gibt es schon im Wiki. Ausserdem gibt es eine Key-Beschreibung fuer surface=... mit den Werten paved, cobblestone, unpaved. Bitte sich dort einzubringen, die Vorschlaege ergaenzen und dann darueber eine Abstimmung herbeifuehren. und dann natuerlich die nicht immer benoetigten aber durchaus notwendigen wie oneway, maxspeed, maxheight, ... oneway ist notwendig, wo gegeben, und maxspeed ist wuenschenswert und sollte man IMHO immer mit aufnehmen, da man das bereits gut auswerten kann und man damit auch spaeter andere Dinge (wie Ortsgrenzen) auf Konsistenz ueberpruefen kann. damit sollte man eigentlich alle strassen ausreichend und vor allem einigermassen eideutig beschreiben koennen. das klassische highway-tag ist dann nicht mehr noetig. IMHO wird es notwendig bleiben, um eine erste Grobklassifikation zu haben. meinetwegen kann man noch ein tag hinzufuegen, dass die relative lokale wichtigkeit angibt, damit ein router eben solche strassen bevorzugt. Was ist eine relative lokale Wichtigkeit? Das waere ja noch schwammiger als jetzt ... :-) [...] Eine Heuristik a la ``ich bleibe zuerst auf der Strasse mit hoeherem highway-Tag'' fuehrt einen auf alle Faelle in die Irre, da ich dann in deinem Beispiel zuerst mal von Sueden her kommend auf der B15 bis zum Eisstadion und evtl. noch weiter durchfahren werde, so dass ich dann bereits in der Stadt bin. aber meist hast du keine andere moeglichkeit bei dem aktuellen datenbestand. und wenn dann eben einen dieses schwammige highway-tag in die irre fuehrt, hat man halt pech
[Talk-de] Reisezeiten (was: Potlach! *kotz*)
Hallo, on Saturday, 26 January 2008 10:39:05 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Und es bleibt natürlich noch die Sache mit den Attributen, mit denen man auf eine Reisezeit schliessen kann. Da muss man faktisch bei Null anfangen, weil man das 'highway'- Attribut dafür nicht ernsthaft verwenden kann. Das ist Quatsch. Triff eine gute Abschaetzung anhand des highway-Attributes, und die Fehler in Deiner Berechnung werden garantiert geringer sein als die externen Einfluesse bei der tatsaechlichen Durchfuehrung der Fahrt (lies: Verkehr und Verkehrshindernisse). Jupp, auch die GDF-Daten der beiden Grossen lassen von der Functional Road Class nicht direkt auf Geschwindigkeiten bzw. Reisezeiten ableiten, da die FRC nur etwas die Wichtigkeit der Strasse im Gesamtnetz aussagt. Wo also kaum Autobahnen sind, wird auch eine eigentlich untergeordnete Strasse fuer eine Verbindung wichtig. Nur zusammen mit anderen Attributen (Form-of-Way, innerorts vs. ausserorts, Kurvigkeit, Anzahl Kreuzungen etc.) bekommt man gute Kanten-Reisezeiten. Wenn Du das auch nur ansatzweise mit einbeziehen wolltest, muesstest Du nicht nur speichern, wo Ampeln sind, sondern auch, wie viele Autos pro Ampelphase rueberkommen und wie viele Autos in Abhaengigkeit von der Tageszeit da stehen und so weiter. Das wird sicher irgendwann mal ein spannendes Projekt - aber *nachdem* wir ansonsten funktionierende Routingsysteme haben, nicht in Version 1.0. Ampeln etc. haben die beiden Grossen bislang auch (noch) nicht (flaechendeckend) drin, so dass alle Router/Navis die auch nicht einbeziehen koennen bzw. man mit alten Strassenkarten nicht verwendbare Ergebnisse bekommen muesste, wenn die denn so dringend notwendig waeren. Da die Navis auch schon vor Jahren (sehr) gute Ergebnisse lieferten ... :-) Viel wichtiger statt der Streit um die Brauchbarkeit der Highway-Tags ist IMHO das flaechendeckende Tagging, ob eine Strasse inner- oder ausserorts ist, egal ob dies ueber Ortsgrenzen, is_in-Builtup-Area- Tags oder per maxspeed=50/30/... passiert (ich versuche bspw. letzteres bei den von mir getaggten Strassen flaechendeckend zu tun). Wenn dann die Kantenzuege der Strasse einigermassen gut den Strassenverlauf, d.h. die Kurvigkeit und damit die tatsaechliche maximale Geschwindigkeit ableiten lassen, kann man eine brauchbare durchschnittliche Kanten-Geschwindigkeit aus all diesen ableiten, die fuer einen guten Durchschnitts-Router voellig ausreicht. Das groesste Problem aber ist leider immer noch, dass ich sehr haeufig nicht verbundene Way-Kreuzungen vorfinde, d.h. wo die Endknoten von zwei oder mehr Ways nicht verbunden sind, sondern nur knapp nebeneinander liegen. Und dies ist fuers Routing nun wirklich problematisch, da damit gerade die Routen im Nahbereich, also beim Start oder Ziel, oft unsinnige Ergebnisse liefern. Hier waere ein maplint- bzw. Josm-Validator-Test wirklich hilfreich, auch wenn ein solcher Test oefters false positives liefern wird, wo Wegenden sehr nahe beieinander liegen, aber eben doch (durch Mauern, Zaeune, unterschiedliche Hoehen) unueberwindbar getrennt sind. Das erinnert mich an die Schule, wo im Physikunterricht irgendeine komplett idealisierte Situation durchgerechnet wurde (punktfoermige Masse ohne Reibung...) und dann jemand stolz mit den vom Taschenrechner gelieferten 5 Stellen nach dem Komma ankommt. Jede praktische Anwendung wird 20% um den berechneten Wert herum schwanken, wozu also die Pseudopraezision? ... ganz zu schweigen von all den aufsummierten Rundungsfehlern, die man so bei einer ungluecklichen Implementierung machen kann :-). Die von einem Router berechnete Gesamtreisezeit wird ueblicherweise nur einige Prozent von der real benoetigten Reisezeit abweichen, solange man keine Staus und andere Stoerungen hat. Will man bessere Werte, d.h eine geringere Abweichung muss man so oder so dynamische Reisezeiten verwenden, d.h. zumindest tageszeitabhaengige Ganglinien, um so die ueblichen Pendlerstroeme mit einzubeziehen ... so wie dies auch (alle? die meisten?) aktuellen Router/Navis machen. Schoenes (Rest-)Wochenende, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Potlach // Baukasteneditor // RFC: Einschraenkung durch Relationen?
On Saturday, 19 January 2008 18:52:22 +0100, Christian Koerner [EMAIL PROTECTED] writes: [...] Eine Idee die mir schon seit einiger Zeit im Kopf rumschwirrt, ist das Sperren von Wegen durch die Verwendung von Relationen. Wir haben sie nun mal, warum sollte man sie nicht sinnvoll nutzen?! Sieht man den Streckenverlauf einer Autobahn oder eines Autobahnabschnitts als 'sicher' an, da die Wege nicht von den (sagen wir mal 50) vorhandene GPS-Traces abweichen, legt man eine Relation fuer die Autobahn an. type=lock Die 'sicheren' Wege gibt man als Mitglied (Member) der Relation an, die Rolle/Funktion koennte 'node_position_lock', 'name_edit_lock', 'ref_edit_lock' und so weiter sein, um die Verschiebung von Nodes, das Bearbeiten des 'name'- bzw. des 'ref'-Tags zu verhindern. Wann definiert man einen Wegabschnitt als perfekt, aehm :-), komplett? Momentan fahre ich bspw. einige Strecken ab, nicht um die Wege einzupflegen, denn der ist bereits komplett, sondern um Dinge wie Bruecken, Tunnel und Dinge laengs des Weges (Tempolimits und sonstige Schilder) aufzunehmen und dann nach und nach einzupflegen. Und beim Einpflegen derselbigen habe ich auch schon einige Dinge von anderen zerstoert, so dass auf der Slippy-Map Strassenteile nicht mehr sichtbar waren (mein beliebtester Fehler ist layer=+1 statt layer=1). Die Aenderung von gesperrten Wegeigenschaften erfolgt erst nachdem ein Dialog mit einer Warnmeldung positiv bestaetigt wurde. Oder, der Benutzer der die Relation anlegt wird automatisch ein Mitglied der Relation mit der Rolle 'editor', weiteren Mitgliedern kann das Aendern gestattet werden, in dem sie mit in die Relation aufgenommen werden und ihnen die Rolle 'editor' zugewiesen wird. Voraussetzung ist dafuer, dass Benutzer(-IDs) Mitglied einer Relation werden koennen. ... und dass die Low-Level-API diese Art von Sperren dann auch umsetzt, denn notfalls kann ich mit einfachen REST-Anfragen sehr leicht viel Unheil anrichten! [...] Das sind nur ein paar Ideen, sollte jemand der Meinung sein, dass sich etwas sinnvoll daraus entwickeln laesst, wuerde ich eine 'Relations/Proposed/Lock'- oder 'Relations/Proposed/Locking'-Wikiseite anlegen, auf der man diese und weitere Ideen diskutieren koennte. Prinzipiell eine gute Idee, aber ich bin mir nicht so ganz sicher, ob Sperren der richtige Weg ist oder nicht doch eher so etwas wie eine Freigabe von Aenderungen nach einem Review der fuer ein Gebiet und/oder fuer einen Object-Typ Verantwortlichen. Mit letzterem sperrt man niemanden aus, da die Aenderungen vorlaeufig aber dennoch sichtbar sind, sondern sorgt nur dafuer, dass Aenderungen einen Review-Prozess durchlaufen, bevor sie permanent werden. Und wenn sich fuer ein Gebiet niemand als Reviewer findet, wenn sich also niemand verantwortlich und/oder auf den Schlips getreten fuehlt, dann darf wie bisher wild geaendert werden. Ich hege aber Zweifel, ob dies per Relations geloest werden sollte oder nicht gleich in die OSM-API und die Datenbank rein muss, damit _alle_ Editoren diese Freigabe (oder Sperren) implementieren. Ansonsten wird es sicherlich bald dieselben Klagen wie jetzt geben ... Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mappen von kleinen Flüssen/Bächen?
On Saturday, 19 January 2008 07:10:11 +0100, Karl Eichwalder [EMAIL PROTECTED] writes: Also bleibt eigentlich nur ein Schlauchboot oder mit Gummistiefeln stunden-/tagelang neben dem Bach herzulaufen, oder? Ja ;) Ich mappe so etwas oft nur näherungsweise. Beim zweiten und dritten ablaufen mache ich mir dann notizen in der art: hier bach ~30m weg, hier direkt am weg... Richtig gut ist das freilich auch nicht. ... oder mit einem konstanten Versatz am Ufer ablaufen, um die grobe Form hinzukriegen. Bei kleinen Bachlaeufen, die man mit wenigen Punkten annaehert, ist das voellig ausreichend, zumal wenn man Wege links und rechts des Baches sauber aufnimmt. Eigentlich ist es unbedenklich, den faktischen verlauf von einer amtlichen karte abzugreifen, solange du nicht die künstlerischen aspekte kopierst oder die karte durchpaust... Wobei auch die manches Mal nicht die genaue Lage des Baches angeben, besonders wenn sich das Ufer desselbigen noch veraendern darf. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] parallele Ways (war: Re: Unterschiedliche Geschwindigkeitsbeschraenkungen fuer jede Fahrtrichtung)
On Thursday, 17 January 2008 20:49:23 +0100, qbert biker [EMAIL PROTECTED] writes: Das einzige worauf man sich bei OSM verlassen kann ist, dass man sich auf nix verlassen kann ;) Wie wahr! Aus diesem Grund gibt es bei den grossen Kartenherstellern auch genauere Digitalisierungsbeschreibungen und -richtlinien und deren Mitarbeiter werden regelmaessig geschult. ... und selbst dort findet man immer mal wieder Ausreisser ;-). [...] Deshalb zeichne ich seit einiger zeit auch immer dann parallele ways ein, wenn die fahrbahn eine gewisse breite überschreitet. So ab 15-20 meter fahrbahnbreite halte ich eine parallele ways für vertretbar; und grundsätzlich auch bei 2x2 spuren. Leider bleibt dabei die Information ob es eine wirkliche bauliche Trennung gibt oder nicht auf der Strecke. Schliess mich dem an. 2x2 Spuren ohne bauliche Trennung kommt relativ haeufig (auch innerstaedtisch) vor und das wuerde ich nur als ein Weg taggen, jedoch noch mit lanes=2 versehen. Das lanes-Tag erlaubt mir ja gerade solche breiten mehrspurigen Fahrbahnen abzubilden. Wegen baulicher Trennung bei parallelen Ways wuerde ich meinen Vorschlag eines divider-Tags auch auf diese ausdehnen, da ich bei der Relation Dual_carriageway auch ein Divider-Tag angeben koennte ... und dort ist der physical divider dann auch sinnvoll. Fürs Routing selber ist es eigentlich egal, aber die Wiedererkennung bleibt dabei mehr oder weniger schon auf der Strecke. Gerade das Wiedererkennen ist hier wichtig. Aber auch fuer Routing und die Navigation ist es nicht ganz egal: - Zum einen muss ich fuer jeden kreuzenden Querverkehr die beiden parallelen Ways mit einem Stummel-Way verbinden, so dass ich beim Routen mehr Kanten betrachten muss. (Ausserdem: Wie tagge ich diesen Verbindungs- Stummel? Da gibt es wohl zwei Schulen: entweder die Tags von der Hauptstrasse verwenden oder die vom Querverkehr.) - Zum anderen ergeben diese Stummel-Ways auch Probleme, wenn ich Abbiegevorgaenge verbieten will (z.B. Linksabbiegen verboten), da die Verbotsrelation dann immer 3 Weg-Teile statt 2 enthalten muss, was eher beim Taggen vergessen oder falsch gemacht wird. - Und dann hat ein Navi auch immer noch das Problem, vernuenftige, eindeutige und nur die notwendigen Abbiegeanweisungen dafuer zu generieren. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Unterschiedliche Geschwindigkeitsbeschraenkungen fuer jede Fahrtrichtung
On Thursday, 17 January 2008 21:03:58 +0100, Mario Salvini [EMAIL PROTECTED] writes: Bernd Raichle schrieb: Den groesseren Wert trage ich mit dem Tag mit Zusatz maxspeed:in= (in Way-Richtung) bzw. maxspeed:against= (gegen Way-Richtung) und noch einen comment= im Klartext dazu. Statt den beiden Zusaetzen :in und :against koennte ich auch :forward/:backward oder :pos(itive)/:neg(ative) verwenden, ist Geschmackssache. ich persönlich würde lieber maxspeed:left=... oder maxspeed:right=... verwenden. weil der Weg-Vektor immer eine Richtung hat und somit unabhängig von Rechts- odr Linksverkehr klar ist, welche Seite gemeint ist. ...:left und ...:right fuer die Wegrichtung ist ja gerade _abhaengig_ vom Rechts- oder Linksverkehr, wieso sollte das besser sein? Die Beschraenkung gilt fuer eine Richtung, egal wo die Fahrspur nun auf dem Weg liegt, daher ist die _Richtung_ IMO vorzuziehen. Rechts oder links wuerde ich nur fuer Dinge angeben, die rechts oder links des Weges liegen, also Flaechen oder POIs oder auch die im Wiki diskutierten Hausnummern. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] parallele Ways (war: Re: Unterschiedliche Geschwindigkeitsbeschraenkungen fuer jede Fahrtrichtung)
On Thursday, 17 January 2008 14:42:50 +0100, qbert biker [EMAIL PROTECTED] writes: So richtig habe ich mich mit dem Thema bisher nicht beschäftigt, aber gestern hatte es mich doch mal interessiert. Wann genau macht man denn nun zwei Ways, wann nur einen? Die meisten halten sich wohl an die Regel, dass sie das beschreiben, was sie sehen. In diesem Sinne macht es durchaus Sinn, wenn man nur getrennt einträgt, was auch wirklich getrennt ist. Eine bauliche Trennung bedeutet, dass es mehr ist, als die übliche durchgezogene (Doppel-)Linie. Ich selber verwende als Kriterium, dass ich getrennt eintrage, wenn zwei Dinge erfüllt sind: 1. Die Trennfläche ist so breit, dass man locker darauf stehen kann (ca. 1m) 2. Die Trennfläche ist von einem Fahrzeug nicht einfach zu überwinden, also weil z.B. Leitplanken drauf sind (- Autobahn) oder auch nur eine kleine Stufe wie bei Verkehrsinseln. Der Vorteil dabei ist, dass die Darstellung nicht nur dem Autofahrer etwas aussagt, sondern auch einem Fußgänger. Hier beschreibst du letzlich die Unterscheidung zwischen - physical divider und - legal divider, also auf der einen Seite eine bauliche, durch ein Fahrzeug nicht so leicht ueberwindbare Trennung der Fahrstreifen, auf der anderen Seite eine Fahrbahnmarkierung oder ein Verkehrszeichen, die das Wechseln der Fahrbahnen verbietet (durchgezogene Mittellinie oder Ueberholverbot). Durch eine bauliche Trennung erhaelt man ganz eindeutig den Hinweis, die Fahrbahnen durch parallele Ways abzubilden. Bei einem legal divider, also wenn nur eine Fahrbahnmarkierung vorhanden ist, bilde ich das zuerst nur als ein Way ab. Zweifelsfaelle wie Strassen mit mehrspurige Fahrrichtungsspuren, wo die doppelte Mittellinie ueber eine laengere Strecke geht, also keine oder nur vereinzelt Kreuzungen mit Querverkehr und keine Moeglichkeit fuer U-Turns, wuerde ich als 2 parallele Ways abbilden, je staerker der Charakter als Kraftfahrstrasse ausgebildet ist. Ist die bauliche Trennung sauber eingetragen, ergeben sich daraus zusammen mit der Einbahninfo viele verkehrliche Infos von selber. Der Rest kann einfach über Attribute ergänzt werden. Letztens gabs schon mal eine Diskussion um implizite Abbiege- und Umkehrverbote, die z.B. von einer durchgezogenene Mittelline her kommen. Das müsste als Streckenattribut einzutragen sein, damit die Router keinen Schmarrn machen, aber gleichzeitig nicht alles doppelt eingetragen werden muss, wenn mal irgendwo eine Verbotslinie gemalt wurde. Dazu habe ich einen Vorschlag in's Wiki gestellt, der bitte noch kommentiert, ergaenzt, veraendert werden darf: http://wiki.openstreetmap.org/index.php/Proposed_features/Divider Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] abhaengig von der Richtung eines Ways (was: Seen und Inseln)
Hallo, on Wednesday, 16 January 2008 19:38:27 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Also, ich muss bekennen: bislang hat mich noch nichts motiviert, mich mit dieser Relationen-Geschichte überhaupt zu befassen. Muss auch keiner, wenn ers nicht braucht ;-) Mmmh, sobald ich etwas beschreiben will, was mehr als ein OSM-Objekt (Node bzw. Way) referenzieren muss, kann ich das nur mit einer Relation tun, da ich genau hiermit Beziehungen zwischen zwei und mehr OSM-Objekten beschreiben kann. Habe ich nie bestritten. Ich habe die Relations ja eben deswegen ins OSM-Datenmodell eingebaut und lang dafuer gefochten, weil ich sie nuetzlich finde. Aber ich draenge sie niemandem auf, das wollte ich damit zu sagen. Nein, ich finde sie ein sehr gutes Beschreibungsmittel fuer viele Dinge, die man sonst nicht beschreiben koennte. Ich bin mir nur noch nicht ganz sicher, wo und wie man sie am sinnvollsten einsetzen kann, damit sowohl die Tagger als auch spaeter die Renderer, Sucher, Router und sonstigen Anwendungen sie einfach nutzen koennen. Habe deshalb an verschiedenen Stellen im Wiki ja auch schon meine Kommentare hinterlassen, damit mir die Antworten darauf vielleicht weiterhelfen :-). Persoenlich empfinde ich alles, was sich auf die Richtung von Ways verlaesst, als ziemlich zerbrechlich. Daten, die sich nicht darauf verlassen, sind sicherer gegen unbeabsichtige Aenderungen. Wie sollte man sonst beschreiben, was links bzw. rechts einer begrenzenden Linie liegt? Oder was bei einer Flaeche/Area nun innerhalb und was ausserhalb ist? Oder ob eine Way in eine bestimmte Richtung befahrbar ist? Oder etwas richtungsabhaengig unterschiedliche Eigenschaften besitzt? Was innerhalb und ausserhalb ist, kann man ja gut mit Relations abbilden. (Nur zur Klaerung: Ich finde Relations gut. Es war Paul, der absichtlich ketzerisch nach ihrem Nutzen fragte. Und ich antwortete, dass man mit Relations eben die Abhaengigkeit von der Richtung eines Ways aufloesen kann.) ... und je laenger ich darueber nachdenke, desto besser gefaellt mir diese Idee. In welche Richtung eine Einbahnstrasse oder ein Tempolimit oder eine Steigung gelten, haette ich persoenlich lieber auch ueber eine Relation (in der Gestalt eines erweiterten Tags) geloest, die entweder sagt von Node X bis Node Y ist das hier Einbahnstrasse, oder von mir aus auch in Richtung Norden ist das hier Einbahnstrasse. Die Aussage in Richtung Norden halte ich eher fuer schlecht als Beschreibungsmittel in den OSM-Daten. Da gefaellt mir der Gedanke, dass ich die Beschreibungen mit Tags nun aufteilen kann auf 1. Menge von einfachen Tags, die fuer den gesamten Way gelten 2. Menge von einfachen Tags, die fuer den gesamten Way mit Richtung gelten 3. Menge von einfachen Tags, die fuer einen Teilweg gelten 4. Menge von einfachen Tags, die fuer einen Teilweg mit Richtung gelten 5. mehrere zusammengehoerende Tag-Mengen, die fuer den gesamten Way gelten 6. mehrere zusammengehoerende Tag-Mengen, die fuer den gesamten Way mit Richtung gelten 7. mehrere zusammengehoerende Tag-Mengen, die fuer einen Teilweg gelten 8. mehrere zusammengehoerende Tag-Mengen, die fuer einen Teilweg mit Richtung gelten fuer sehr gut. Ohne die Relationen koennte ich nur 1. und 2. abdecken. Fuer 3. und 4. muss ich Wege teilen. Wobei ich bei 2. und 4. spaetestens dann Probleme bekomme, wenn ich Tags haben, die fuer unterschiedliche Richtungen gelten. Fuer 5., 6., 7. und 8. (das sind zeit- und/oder verkehrsmittel- abhaengige Beschraenkungen, bspw. die Beschilderung 80km/h allgemein+ 60km/h fuer Lkw oder 100km/h von 22:00-6:00) benoetige ich zusammen- gesetzte Tags/Attribute, da kaum alle Tags beispielsweise vom angegebenen Zeitraum abhaengig sind. Und genau diese 3 Tag-Beschreibungen kann man nun mit Relationen abdecken: 1. keine Relation notwendig, so wie bisher als Standard-Tag eines Weges 2. Relation mit tagrelation_type = directed way tags member type = way member type = node role = from member type = node role = to tag+ ... Die beiden Knoten koennen, muessen aber nicht der erste und letzte Knoten des Weges sein. Richtung ist von Knoten from nach to. 3. Relation mit tagrelation_type = undirected way segment tags member type = way member type = node role = from member type = node role = to tag+ ... Die beiden Knoten geben den Teil des Weges an, fuer die die Tags gelten sollen. 4. Relation mit tagrelation_type = directed way segment tags member type = way member type = node role = from member type = node role = to tag+ ... Die beiden Knoten geben den Teil des Weges an, fuer die die Tags gelten sollen. Richtung ist von Knoten from nach to. 5. Relation mit tagrelation_type = undirected way tag group member type = way tag+ ...
Re: [Talk-de] Duplicated Nodes und wie man sie los wird
On Sunday, 13 January 2008 13:55:37 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Das sehe ich nicht so. Nodes, die nur für Ways benutzt werden und sonst keine Tags haben, bekommen bei mir keine Layer. Ich würde die selben Nodes für mehrere Ways benutzen, und nur die Ways bekommen verschiedene Layer. Grundsätzliche geht Routingsoftware heute davon aus, dass, wenn sich zwei Strassen an einem Node treffen, an diesem Node ein Abbiegen moeglich ist. Layers werden dabei nicht beachtet (denn sonst wuerde ja kein Router je den Weg ueber eine Bruecke finden, da irgendwo vor der Bruecke ploetzlich der Sprung von Layer 0 auf Layer 1 ist). Deine Methode wird also dazu fuehren, dass die Routingsoftware munter im Parkhaus zwischen den Ebenen hin und her springt (falls sie je auf ein Parkhaus losgelassen würde). ... oder man fuegt explizite Abbiegeverbote hinzu -- man kann es sich und den Routern aber auch unnoetig schwer machen :-}. Ein weiteres Argumente fuer mehrere Nodes mit denselben Lat/Long-Koordinaten: Nur Nodes kann man mit ele verschiedene Hoehen mitgeben, d.h. will man zwei direkt uebereinanderliegenden Strassen unterschiedliche Hoehen zuweisen, benoetigt man jeweils zwei Nodes. Beispielsweise gibt es verschiedentlich Bruecken, deren Richtungsfahrbahnen nicht nebeneinander, sondern uebereinander liegen. Will man direkt uebereinander liegende Nodes und Ways vermeiden, muessen die Ways fuer die beiden Fahrbahnen einen kleinen Long/Lat-Offset voneinander haben. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Besenwirtschaft/Straußwirtschaft/Heck enwirtschaft/...
On Tuesday, 8 January 2008 23:52:40 +0100, Michael Kugelmann [EMAIL PROTECTED] writes: Christoph Eckert schrieb: das generelle Problem ist IMO aber schon gegeben. Es gibt Straßen, die nur zu bestimmten Uhrzeiten befahrbar sind, wie auch Fähren. Eine Routingsoftware sollte IMO davon wissen. [...] Das finde ich auch OK. Aber so weit sind wir im Moment noch gar nicht. Und: das was Christoph geschildert hatte, ist ja ein regelmäßiges bzw. wiederkehrendes Verhalten = das kriegt man in den Griff. Manches kann man sicher mit den bereits existierenden Restrictions (date_on, date_off, day_on, day_off, hour_on, hour_off) erreichen. Bei den Besenwirtschaften ist es ja eigentlich viel schlimmer. Das ist ja nicht regelmäßig = jedes Jahr anders [...] Ein aehnliches Problem hat man aber auch bei mancher Ausflugsgaststaette. Da gibt es einige, die z.B. nur an Wochenenden offen sind oder nur waehrend der Neben- und Hauptsaison. Never the less suche ich immer noch so etwas wie ein TAG für einen Besen. Hat niemand eine Idee, wie man so etwas taggen kann? Notfalls müsste man (ich) über proposed features so etwas einführen. ... und als Icon-Vorschlag dann einen Besen? :-) Momentan habe ich vor, die Besenwirtschaften in meinem Umfeld (Kernen im Remstal, da gibt es einige) als Restaurant zu taggen und die Besen-Eigenschaft im Namen aufzufuehren. Da koennte ein Fremder, der mit dem Begriff im Namen nichts anfangen kann, dann zwar oefter vor verschlossener Tuere stehen, alle anderen wissen um die unregelmaessigen Oeffnungszeiten und man kann spaeter immer noch nach diesen suchen und entsprechend (um)taggen. -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nodes oder geschlossene Pfade oder beide s für Städte, Parkplätzen u.a.?
Hallo, On Wednesday, 12 December 2007 21:02:44 +0100, Dimitri Junker [EMAIL PROTECTED] writes: Das ist ja OK, hat aber nichts mit Stadt oder Dorf zu tuen. Ich habe heute 3 Ortseingangsschilder vonn Aachen eintragen wollen und mich gewundert wie die wohl zu verbinden sind. Dabei bin ich dann auf verschiedene Karten gestoßen die die Stadtgrenze zeigen, und die war nicht da wo die Schilder stehen. Dabei wurde mir dann klar, daß wir unabhängig von der Diskussion ob: landuse=residential und place=city das gleiche sind wir noch zwischen Stadtgebiet und geschlossene Ortschaften unterscheiden müssen. Genau das letztere zeigen die Stadteingangsschilder ja an. Die eigentliche Stadtgrenze ist woanders. Mmmh, landuse=residential etc. zeigen die _bebaute Flaeche_ (durch Wohnhaeuser) an, wobei ein Ortseingangsschild oft, aber nicht immer an der Grenze dieser Flaeche steht. Es gibt einige Faelle, wo Ortsschilder weit (50m) vor der bebauten Flaeche stehen. Ausserdem auch Sonderfaelle, wo eine Strasse einseitig bebaut ist (meist Industriegebiet), das Ortsschild aber erst dort steht, wo die beidseitige Bebauung beginnt. Welche Grenze soll place=city also zeichnen? Die Stadtgrenze oder die der geschlossenen Ortschaft? So Regeln wie Tempo 50 hängen an der geschlossenen Ortschaft. Jein, die haengen in D explizit am Ortsschild bzw. an einem explizit vorhandenen Geschwindigkeitsbegrenzungsschild. IMO ist die erlaubte Geschwindigkeit so oder so separat mit maxspeed=... zu taggen und, wenn man die Ortsschilder explizit aufnehmen will, dann solltest du auch diese explizit separat am entsprechenden Node taggen (bspw. traffic_sign=city_limit). Also welche Grenze zeichnen wir mit place=city ein? Wenn place=city das Stadtgebiet beschreiben soll, dann sind auch umgebende Waelder, Felder und Wiesen, die zu diesem gehoeren mit drin. Und letzlich landet man bei den Verwaltungsgebieten (vgl. GDF, administrative areas; in GDF wird auch zwischen Admin-Areas und Built-up-Areas unterschieden). Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM mit Yahoo Bildern
Hallo, on Monday, 10 December 2007 12:05:30 +0100, =?UTF-8?B?RGlyay1Mw7xkZXIgS3JlaWU=?= [EMAIL PROTECTED] writes: Martin Simon schrieb: [...] Leider nicht - das Plugin habe Ich installiert und es funktionierte auch einmal auf meinem sudux(debian sid)-Laptop, seit längerer Zeit jedoch nicht mehr. Ich erhalte leider jedes mal die Meldung no route to host, obwohl alle Einstellungen sowohl inn JOSM als auch im firefox/iceweasel korrekt scheinen. (und das ganze auch mehrmals von Grund auf neu eingerichtet wurde) :-( Ich habe leider keine Ahnung, wo genau das Problem liegt. Wo und wann genau erscheint no route to host? kaputte /etc/hosts Datei? Firewall? kaputter DNS cache? ich hatte auch ein aehnliches Problem, da ich tagsueber hinter einem http-Proxy sitze. Hab's mittlerweile so geloest: Beim ersten Einrichten des Plugins wird ein neues Firefox-Profil angelegt. Wichtig ist hierbei, dass die Proxy-Einstellungen zu diesem Zeitpunkt korrekt sind. Wenn nicht, muss man _in diesem Profil_ die Proxy-Einstellungen nachtraeglich entsprechend aendern. Bei mir ging das nach mehrfachem Test nur manuell: - Alle laufenden Firefox-Prozesse beenden, - nach .mozilla/firefox/*.josmprofile/ wechseln (bei mir heisst das Profil josmprofile, das Standard-Profil findet man im Verzeichnis .../*.default), - in der Datei prefs.js die Eintraegungen fuer network.proxy.* _und_ network.proxy.backup.* mit den entsprechendem Proxy-Host und -Port versehen (bzw. aus ../*.default/prefs.js kopieren) und abspeichern. Nach diesen Aenderungen tat das Plugin hinter dem http-Proxy wieder korrekt bzw. liess sich korrekt installieren und einrichten. -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Et Cetera Tag
On Monday, 10 December 2007 13:45:46 +0100, Friedhelm Schmidt [EMAIL PROTECTED] writes: was haltet ihr von einem highway=etc ? Nope. Dann schon lieber stubble oder stub link verwenden. Ich würde es als Segment an unvollständige Wege anhängen und es sollte als 3 Pünktchen gerendert werden. Ich habe oft Stummel, wo ich im Vorbeifahren einen Marker setze und den Straßenamen in die Sprachaufzeichnung gebe. Oder ich sage Sätze wie ... die XY-Straße geht hier geradeaus weiter, aber ich fahre links in die ZZ-Straße ... Würde man diese Stummel in der Slippy-Map sehen, wäre das ein Anreiz mal mit dem Fahrrad in eine Ecke zu fahren und was zu ergänzen. Auch für Menschen, die sich bereits mit OSM orientieren, wäre das zumindest ein zusätzlicher Anhaltspunkt: Endet die Straße hier wirklich oder ist sie nur noch nicht erfasst? Ich habe es bislang so gemacht, dass ich einen kurzen Stummel-Weg einmale, diesen schon grob per highway/railway/waterway=... klassifiziere, damit die Renderer was einzeichnen und mit einem FIXME=... noch als unfertig markiere. Aehnliches habe ich auch fuer Bachlaeufe, Stromleitungen und Schienen gemacht, wobei man per tunnel/bridge=yes, layer=... bzw. railway=level_crossing die Ebenenverhaeltnisse gleich korrekt beschreiben sollte (aber nicht muss). Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Divider - physical/legal
Hallo on Thursday, 6 December 2007 15:56:57 +0100, Mario Salvini [EMAIL PROTECTED] writes: Bernd Raichle schrieb: Ja, dann haette man im Beispiel den Divider zwischen zwei Knoten noch vor den beiden Kreuzungsknoten an den Tunnelenden gesetzt, dort wo auch die durchgezogene Linie beginnt. Somit waeren die Abbiegerestriktionen implizit durch den nicht ueberfahrbaren Divider (egal ob legal oder physical) drin. Nett. diese Idee klingt sehr praktikabel! Denn damit könnte man dann mit Divider- und Oneway-Tags (einfach und schnell gesetzt) die eher komplizierten Junction-Relations vielerorts sparen :-) Ich habe den Vorschlag fuer divider=... gerade eben in's Wiki gepackt (mein erster :-), so dass jetzt fleissig korrigiert, kommentiert, ergaenzt und/oder vereinfacht werden kann: http://wiki.openstreetmap.org/index.php/Proposed_features/Divider Ach ja: Wenn man einen Divider nur fuer einen Teil eines Ways angeben will bzw. mehrere Divider(-Typen) auf einem Way vorkommen, so bleibt einem nichts anderes uebrig, als den Weg entweder zu zerstueckeln oder die Beschreibung durch eine oder mehrere (im Wiki noch nicht festgelegte) Divider-Relationen zu beschreiben. Eine Relation ist IMHO hier notwendig, da ich ja den Abschnitt festlegen muss, was am einfachsten und _eindeutigsten_ durch je einen Node fuer den Anfang und das Ende des Abschnittes geht. Und diese beiden Nodes eines Way kann ich bislang nur durch Relationen und nicht durch einen Tag mit dem Way zusammenbringen. Oder ginge das auch einfacher? Das Aussehen der Divider-Relation habe ich im Vorschlag angedeutet (Member: way, start_node, end_node; Tags: type=divider, divider=...), die Member- und Tag-Namen muesste man ueber einen weiteren Vorschlag unter Relations aber noch festlegen, wozu mir gerade die Zeit fehlt. Schoenes Wochenende, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Abbiegeverbote und Überquerverbote
Hallo, on Thursday, 6 December 2007 13:07:25 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Kannst Du mir dieses Layout genauer erklaeren? Da stehe ich jetzt gerade auf dem Schlauch. /-- 4 ---\ - -- 1 - ---* 2 - ---*3 - -- \---5 ---/ [...] Nun soll verhindert werden, dass man (auf der linken Seite oben) von 2 oder von 4 aus nicht nach 5 einfaehrt und dass man (auf der rechten Seite oben) von 2 oder von 5 aus nicht nach 4 einfaehrt. Achso. Was waere denn der korrekte Weg, um einen Ort auf 4 anzufahren, wenn man von links ueber 1 in das Konstrukt einfaehrt? Erst an allem vorbei, rechts ueber 3 raus, U-Turn an der naechsten Kreuzung und zurueck? Beispielsweise :-). Oder auf 1 vor dem Tunnel einen Linksabbieger, der dann von oben auf 4 fuehrt. Oder je einen U-turn von 4 nach 5 und vice versa vor den beiden Tunnelenden. Oder 4 und 5 laufen oberhalb des Tunnels in einen in beide Richtungen befahrbaren Weg zusammen. Aber das habe ich alles in der Zeichnung weggelassen, um diese nicht zu kompliziert zu machen. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Abbiegeverbote und Überquerverbote
On Wednesday, 5 December 2007 18:30:56 +0100, Mario Salvini [EMAIL PROTECTED] writes: Bernd Raichle schrieb: /-- 4 ---\ - -- 1 - ---* 2 - ---*3 - -- \---5 ---/ Sollte sich http://wiki.openstreetmap.org/index.php/Proposed_features/Routing:_turn_restrictions#Using_Relations durchsetzen. Wären nur die beiden mit * markierten Bereiche interessant. Beispiel: Image:Turn_Restriction.png http://wiki.openstreetmap.org/index.php/Image:Turn_Restriction.png Ich denke, diese werden sich durchsetzen. Sieh dir dazu die Vorschlaege in http://wiki.openstreetmap.org/index.php/Relations und http://wiki.openstreetmap.org/index.php/Relations/Proposed/Turn_Restrictions an. Ist nur noch IMHO nicht ganz klar, was alles wirklich notwendig ist, damit die Abbiegebeschraenkung _eindeutig_ und vollstaendig ist. Durch das momentane Modell mit Knoten und Wegen ist es manchesmal schwer, die from-, to- und via-Felder ganz eindeutig fuer einen bestimmten Durchfahrtsweg zu fuellen, wenn man nicht `kuenstlich' (Hilfs-)Knoten einfuegen oder einen Weg splitten will. Bislang faellt mir ausser dem Splitten in Teil-Wege nur die Angabe einer zusaetzlichen Durchfahrtsrichtung eines from/to/via-Weges ein (entweder direkt als Wegrichtung oder indirekt ueber einen Anfangsknoten per bspw. from_node neben dem schon im Vorschlag vorhandenen from-Weges und eines Kreuzungsknotens). Kreuzungen mit diesem FROM-AT-TO-Prinzip zu gestalten halte ich für sehr sinnvoll (z.B. auch an den Haltelinien einer Ampelkreuzung und plus deren Zentrum). Weil dann das Manövrieren durch eine Kreuzung deutlich genauer werden kann. Jupp, mit diesem Schema gibt es unter Relations ja schon weitere Vorschlaege, wie z.B. die Right-of-Way/Vorfahrtstrasse. Das Proposal brauchte nur noch so etwas wie restriction_member weil es ja druchaus Fälle gibt, wo LKWs oder PKWs nciht abbiegen dürfen, Radfahrer oder Fussgänger aber sehr wohl diesen Weg zur Verfügung haben (auch wenn das im konkreten Beispiel oben natürlich nicht so ist) Mmmh, statt restriction member wuerde ich eher die Bezeichnung vehicle type (wie GDF) oder means of transport verwenden. Im Turn-Restrictions-Vorschlag ist da schon die Moeglichkeit drin, mit except die Ausnahmen anzugeben. Ich wuerde da aber neben den Ausnahmen als Negativliste eher beides (Positiv- wie Negativliste) vorsehen. Ebenso wuerde ich gerne die Abbiegebeschraenkungen als Verbote/prohibited turn (no_left_turn) wie als Gebote/obligatory turn (only_straight_on, Schilder mit Pfeile auf blauem Grund) darstellbar machen wollen, da ich dann oft nur das vorhandene Strassenschild abpinseln muesste. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Divider - physical/legal (was: Abbie geverbote und Überquerverbote )
Hallo, on Wednesday, 5 December 2007 19:17:10 +0100, qbert biker [EMAIL PROTECTED] writes: Das geht aber auch nur, wenn ich fuer Fahrtrichtungen getrennte Spuren habe ... was bei so einer Tunnelstrecke meist der Fall ist, entweder durch einen physical divider' (Maeuerchen) oder einen legal divider' (einfach oder doppelt durchgestrichene Linie). Wenn die Tunnelspuren aber nicht getrennt abgelegt werden sollen, d.h. die Tunnelspuren sind in beide Richtungen befahrbar, muss man mit Relationen die verbotenen Abbiegevorgaenge unterbinden (prohibited turn restrictions) ... oder die erlaubten Abbiegevorgaenge festschreiben (obligatory turn restrictions). 'Physical divider' und 'legal devider' - gibts die schon? Bislang nichts im Wiki dazu gefunden. Aber es waere sicherlich ganz interessant, so etwas zu ergaenzen, so dass man bspw. eine durchgezogene Linie, d.h. ein Ueberholverbot oder ein nicht durch ein Verkehrsschild vorhandenes Linksabbiegeverbot dadurch abbilden kann. Entweder als Tag fuer einen Weg ... oder wenn es nur fuer einen Teil des Weges gelten soll, als Relation mit dem Weg und zwei Weg-Knoten, zwischen denen der Divider vorhanden ist. Wenn man die beginnend vor dem Anfangsknoten und nach dem Endknoten (jeweils der, bei dem die obige Straße abzweigt) setzt, kann man da schon was machen. Was genau hängt vom Router ab, bzw. der Umrechnungsroutine, die den Eingangsdatensatz für den Router errechnet. Ja, dann haette man im Beispiel den Divider zwischen zwei Knoten noch vor den beiden Kreuzungsknoten an den Tunnelenden gesetzt, dort wo auch die durchgezogene Linie beginnt. Somit waeren die Abbiegerestriktionen implizit durch den nicht ueberfahrbaren Divider (egal ob legal oder physical) drin. Nett. Bei mir ist das ein gerichteter Graph, bei dem die Gegenfahrbahn immer ein eigener Link ist. Bei reinen Stützpunkten (einer rein, einer raus), sind die sowieso nicht durchverbunden, aber bei Kreuzungspunkten wie im Beispiel schon. Mittels divider-Info könnte man das unterdrücken und der Router arbeitet richtig. Genau, das koennte deine Konverter vom ungerichteten OSM-Netzgraph in deinen gerichteten Graphen machen. Grüsse Hubert PS. Bei einem physical divider würde ich trotzdem dahin tendieren, die Fahrbahnen explizit getrennt zu setzen. Ja, aber dazu muesste man definieren, was nun ein physical Divider ist. Bei einem kleinen Maeuerchen oder den ueblichen Betontrennern bei Baustellen ist das noch klar, aber ... - Was machst du bei einer zweispurigen Strasse mit durchgezogener Linie, auf die noch eine Nagelreihe draufgeklebt wurde? Ist ganz gut ueberfahrbar, auch wenn's etwas hoppelt :-) - Was bei einer Nagelreihe, bei der noch zusaetzlich senkrecht stehende Rueckstrahlschildchen draufgesetzt wurden? Ich wuerde in beiden Faellen nur einen Weg setzen, aber eben einen Divider mit entsprechendem Wert (physical, legal=painted_line, Nagelreihe, Nagelreihe_mit_Rueckstrahlschildchen etc.) taggen ... Konjunktiv, da noch nicht so gemacht :-). Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Qualitätsoffensive
Hallo zusammen, Validierungs- und Qualitaets-Tests halte ich fuer dringend notwendig und mit maplint/Validator-Plugin gibt es ja auch schon die ersten Dinge fuer OSM. Die jetzige Diskussion ist mir aber im Moment zu router-lastig, da so uebersehen wird, dass schon mit einem Mini-Routing viele Dinge gefunden werden kann. (Als Mini-Routing bezeichne ich es, wenn man nur die Wege eines Knotenpunktes bzw. einer Folge von wenigen Knotenpunkten betrachtet.) Einige Problemfaelle sind ja schon aufgefuehrt worden, betrachtet man nur einmal die moeglicherweise falsch gedrehten Einbahnstrassen: - Basis-Tests: * An einem Knoten, wo ein Weg mit oneway=yes/1/-1 angrenzt und dieser ist mindestens highway=secondary (oder tertiary?) benoetigt einen weiteren Weg mit highway-Markierung, der einen mit weiterfuehrender oneway-Markierung hat. Annahme: das wichtige Verbindungsstrassennetz kann nicht in einer Sackgasse enden. - Zusammenfuehrung Dual-Carriageway auf Single-Carriageway: * An einem Knoten, wo drei Wege mit mindestens highway=secondary (oder tertiary?) aufeinandertreffen, einer davon ohne oneway, einer davon oneway zum, einer oneway vom Knoten weg, kann man eine Zusammenfuehrung von getrennten Richtungsspuren zu einer gemeinsamen Spur annehmen, d.h. man kann Winkel testen und testen, ob die oneway-Wege parallel verlaufen: / -- - -* \ - Auf-/Abfahrten: * Aehnliche Winkelteste kann man bei Auf- und Abfahrtsrampen durchfuehren: (link) \ \ --* - Wenn der Hauptweg nur eine Richtung zulaesst, so kann man einen als *_link markierten Weg mit einem bestimmten Abbiegewinkel als Auf- oder Abfahrt mit entsprechender Richtungsbeschraenkung annehmen. Solche Tests beduerfen nur der lokalen Betrachtung weniger Knotenpunkte und weniger Weg und benoetigen keinen Router. Zudem kann man sich auf das Fernverkehrstrassennetz (bis secondary oder tertiary) und die direkt daran anhaengenden Wege beschraenken, so dass die abzupruefende Menge auch ueberschaubar ist. Meist findet man hier schon sehr viele Fehler, die zu sonderbaren Routen fuehren werden. Kann man solche Tests schon in maplint/Validator implementieren oder benoetigt man dazu ein eigenes Tool? On Tuesday, 4 December 2007 22:03:01 +0100, qbert biker [EMAIL PROTECTED] writes: [... Einbahnstrassen, die wegen Beschraenkungen Sackgassen sind ... ] Das sind doch alles sehr spezielle Faelle, die man doch bitte erst angehen sollte, wenn die einfachen Qualitaetstests implementiert sind. Bezueglich Router waere waere mir im JOSM schon gedient, wenn ich zwei Knoten (oder Wege) als Start und Ziel markieren koennte und ich die moegliche(n) Route(n) angezeigt bekaeme, so dass ich den lokalen Ursachen bei sonderbaren Routen beheben koennte. Dies fuer unterschiedliche Verkehrsmittel (Fuss, Rad, Pkw, Lkw mit unterschiedlichen Massen etc.) fuer einen kleinen Netzauschnitt implementiert, waere schon ein enormer Gewinn ... Bei Beruecksichtigung *aller* Kanten mag das stimmen. Wendet man das aber z.B. auf das Eisenbahn-Netz an, gibt es sicherlich Inseln: Solche Ausnahmen kenne ich viele. Die Achterbahn auf der Münchner Wiesn ist auch so eines oder die Zahnradbahn auf die Jungfrau. Für das Normalspurbahnnetz der internationalen Bahnen kann man die genannte Regel schon grossflächig anwenden. Es gibt weitere Bahnen mit eigenem kleinen Schienennetz, die nicht an's grosse Bahnnetz angeschlossen sind. Deren Enden wuerde ich pragmatisch wie bei Strassen-Sackgassen mit noexit=yes (dann in der Bedeutung eines Prellbocks :-) taggen, so dass diese Ausnahmen erkennbar waeren und ein Qualitaetstest fuer lose Enden eine Warnung melden koennte. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Abbiegeverbote und Überquerverbote
On Wednesday, 5 December 2007 14:07:54 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Hallo, Hier vor der Tür teilt sich eine Straße, die inneren Spuren gehen durch einen Tunnel, die beiden äußeren (oneway) bleiben oben. So entsteht ein Kreuzungspunkt mit 4 Straßen. Wenn man das ausformuliert, dann braucht man eigentlich keine Relations dafuer, siehe z.B. http://www.informationfreeway.org/? lat=49.005458493238876lon=8.394616854468799zoom=17layers=B000F000 Das geht aber auch nur, wenn ich fuer Fahrtrichtungen getrennte Spuren habe ... was bei so einer Tunnelstrecke meist der Fall ist, entweder durch einen physical divider' (Maeuerchen) oder einen legal divider' (einfach oder doppelt durchgestrichene Linie). Wenn die Tunnelspuren aber nicht getrennt abgelegt werden sollen, d.h. die Tunnelspuren sind in beide Richtungen befahrbar, muss man mit Relationen die verbotenen Abbiegevorgaenge unterbinden (prohibited turn restrictions) ... oder die erlaubten Abbiegevorgaenge festschreiben (obligatory turn restrictions). -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Abbiegeverbote und Überquerverbote
On Wednesday, 5 December 2007 15:48:03 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Hallo, Wenn die Tunnelspuren aber nicht getrennt abgelegt werden sollen, d.h. die Tunnelspuren sind in beide Richtungen befahrbar Kannst Du mir dieses Layout genauer erklaeren? Da stehe ich jetzt gerade auf dem Schlauch. /-- 4 ---\ - -- 1 - ---* 2 - ---*3 - -- \---5 ---/ Ich habe eine Strasse (1-3), je ein Fahrstreifen pro Richtung, kein Trenner, also nur gestrichelte Linie. Im Ort gibt es einen Tunnel (2) fuer den Durchfahrtsverkehr, dieser hat auch nur je einen Fahrstreifen pro Richtung, durchgezogene Linie bzw. Ueberholverbot im Tunnel. Fuer den Anlieger- bzw. Einkaufsverkehr gibt es an den Tunneleingaengen nach links und rechts weggehend eine Einbahnstrasse (4+5), die sich ueber dem Tunnel wieder vereinigt (nicht dargestellt). Da nur ein schwacher 'legal divider' in der Tunnelstrecke und keiner davor und danach, sind die Wege 1, 2 und 3 nur als einzelner Weg ausgefuehrt, nicht als zwei parallele (Einbahnstrassen-)Wege. Nun soll verhindert werden, dass man (auf der linken Seite oben) von 2 oder von 4 aus nicht nach 5 einfaehrt und dass man (auf der rechten Seite oben) von 2 oder von 5 aus nicht nach 4 einfaehrt. muss man mit Relationen die verbotenen Abbiegevorgaenge unterbinden (prohibited turn restrictions) ... oder die erlaubten Abbiegevorgaenge festschreiben (obligatory turn restrictions). Aber der Tunnel teilt sich doch gar keinen Node mit der Strasse, die er unterquert - wie also sollte ein Router auf die Idee kommen, dass man da abbiegen kann? Wie ich es verstanden habe, geht es um die Turn-Restrictions an den Tunnel-Enden. -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] secondary_link wird nicht gerendert
On Wednesday, 28 November 2007 06:19:00 +0100, Marcus Wolschon [EMAIL PROTECTED] writes: Mario Salvini schrieb: gibts dazu irgendeinen logischen Grund? Wobei... habe gerade bemerkt, dass die nur in der deutschen OSM-Wiki vermerkt stehen auf der englischen Seite aber nicht... *strange* K?nnte die n?mlich jetzt gut gebrauchen. Ich w?re ?berhaupt daf?r, dass ein highway=link eingef?hrt wird, um bei komplizierten Kreuzungen oder Abbiegespuren (ggf. haben diese ja sogar eine seperate Ampel) eingef?hrt wird. In GDF gibt es dafuer die Auszeichnung als Slip Road (ein Form-of-Way-Wert mit verschiedenen Untertypen, die angeben, ob dies Ueberleitungen sich kreuzender oder uebereinanderliegender Strassen sind) oder auch die Auszeichnung als Ramp fuer Ein- und Ausfahrten. Und diese Auszeichnung der Strassen ist im Unterschied zu OSM unabhaengig von der Klassifizierung der verbundenen Strassen, ist also so etwas wie der vorgeschlagene highway=link mit dem oben erwaehnten linktype= also ich sehe ein highway=motorway_link für Autobahn-Auffahrten und primary_link sowie trunk_link aber das eine Sekundärstraße überhaupt Auf- und Abfahrten hat oder diese auf der Map_Features -Seite (http://wiki.openstreetmap.org/index.php/Map_Features) verzeichnet sind wäre mir neu. Jupp. Ich denke aber, es gibt Strassen, die klar Auf- und Abfahrtsrampencharakter zu einer secondary-Strassen haben. Entweder entscheidet man dann, dass diese hoeher als secondary klassifiziert werden sollte oder man laesst diese und kennzeichnet die Auf-/Abfahrt eben nicht als solche. Momentan habe ich diese meist auch einfach als secondary markiert, wenn sie zwei secondary-Strassen verbinden, ansonsten mit dem Tag der untergeordneten Strasse(n). Da solche Ein-/Ausfahrten oft keinen Namen/Ref haben, lasse ich den leer, wenn nichts richtig passt ... was leider der Validator anmeckert. Vorschlaege hierzu? Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Composite Tags (was: URL als Tag)
Hallo, on Sunday, 25 November 2007 15:27:32 +0100, Guenther Meyer [EMAIL PROTECTED] writes: [...] das einfuegen mehrerer gruppen kann durchaus sinnvoll sein, nur muss die zuordnung von beschreibung zu url auch da sein. dies ist eigentlich genau das, was man mit Gruppen von Tags bzw. den sogenannten Composite Tags erreichen will. Im OSM-Wiki werden hierzu auf Relationen verwiesen, aber so richtig gluecklich bin ich damit nicht (naja, wenn man die Implementierung der Composite-Tags mit Relationen in den Editoren versteckt, so dass die Composite-Tags als normale Tags erscheinen, duerfte es ok sein). wie waers mit folgendem schema fuer dein beispiel: name:de = Braunschweig name:en = Brunswick uri.0:de = http://www.braunschweig.de; uri.description.0:de = Deutsche Webseite der Stadt Braunschweig uri.1:en = http://www.braunschweig.de/english/; uri.description.1:de = Englische Webseite der Stadt Braunschweig uri.description.1:en = English website of Brunswick (City) uri.2 = http://braunschweig.de/webcams/live_capture.php:2342; uri.description.2:en = The View from the tower of city hall of Castle Square uri.description.2:de = Webcam-Sicht vom Turm der Stadthalle am Burgplatz Solch eine Nomenklatur der Tag-Namen ist auch eine Idee, um Composite-Tags zu implementieren. So koennte man auch Zufahrts- und Geschindigkeitsbeschraenkungen, die fuer unterschiedliche Fahrzeugklassen und Zeiten gelten, entsprechend gruppieren. Einen aehnlichen Vorschlag gibt es ja schon mit ...:left und ...:right fuer richtungsabhaengige Eigenschaften. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Organisation eurer Arbeiten
Hallo, on Sunday, 25 November 2007 17:01:37 +0100, Rainer Schulze [EMAIL PROTECTED] writes: Da ich noch kein befriedigendes Konzept für die Organisation meiner Arbeiten (Datenerfassung mit OSMtracker und Kartierung mit JOSM) gefunden habe möchte ich euch mal bitten (vor allem die alten Hasen), mir Neuling zu beschreiben, wie ihr eure Daten organisiert: - 'uploaded' (grässliches Wort!) ihr alle eure GPX-Tracks zum Server? Nope. Ich habe bislang nur die GPX-Tracks hochgeladen, die ein sauberes GPS-Signal hatten und die nicht zuviele Ausreisser aufweisen. Die meisten anderen Tracks weisen bei mir zuviele Ausreisser und hin und wieder einen Versatz auf, so dass man ohne nochmaliges Abgehen der Strecke einige (viele) Meter danebenlaege. Da ich erst vor einigen Wochen angefangen habe, kamen noch nicht soviele zusammen. - haltet ihr eine Kopie eurer Daten (.osm) lokal? Nein. (Nur fuer's Offline-Stoebern in fremden Daten habe ich lokale .osm-Dateien angrenzender Gemeinden und Staedte.) - habt ihr spezielle, bewährte Verzeichnisstrukturen für eure Arbeiten? Unterverzeichnisse nach Gebiet (Landkreis, Stadt o.ae.) und Datum (Jahr-Monat-Tag), wo GPX-Tracks und Notizen etc. liegen. Die Tracks benenne ich noch nach Verkehrsmittel + Wegstreckenpunkte (von, nach, vias). GPX-Tracks, die noch unbearbeite (Teil-)Wege enthalten, bekommen noch einen extra Marker. Meine Arbeitsweise: - In JOSM alle lokal vorhandenen GPX-Tracks eines kleinen Gebiets laden, diese evtl. in eine oder mehrere Ebenen laden und unterschiedlich einfaerben - Ausschnitt groesser als geplanten zu bearbeitenden Ausschnitt waehlen - danach OSM-Daten (+ GPX-Tracks) fuer diesen Ausschnitt vom OSM-Server herunterladen - Punkt, Wege und Flaechen anlegen/korrigieren, dabei bei Bedarf die Ebenen mit den eigenen und fremden GPX-Tracks ein- und ausblenden, um Abweichungen zwischen den Punkten besser einschaetzen zu koennen - Validieren - Daten zum OSM-Server hochladen Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Autoverlad
On Monday, 26 November 2007 13:28:09 +0100, Raphael Studer [EMAIL PROTECTED] writes: Salü Zusammen, In der Schweiz kennt man den Autoverlad. Heisst man fährt mit dem Auto auf einen Zug, und der Zug rauscht dann durch einen Bahntunnel, weil die Passstrasse gesperrt ist. Gibts so was auch in Anderen Ländern, wenn ja wie nennt man das dort? Ich habe so eine Route getrackt und suche nun ein passendes Tag dazu. Nicht dass ich ein GPS mit Gyro hätte (noch nicht), aber der Tunnel schnurzgerade. GDF hat neben den Strassen auch die Ferry bzw. Ferry Connection, mit dem Ferry Type-Attribut fuer den Transportmodus mit den Werten train und ship. Verladestationen sind Services/POIs des Typs Ferry Terminal. Damit hat man Autozuege als auch Faehrverbindungen. Hat eigentlich schon jemand Faehrverbindungen eingepflegt? Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Absolute Hoehendaten (was: Klare highway tagging Regeln f?r befestigte, Stra?en)
Hallo, on Friday, 23 November 2007 09:08:08 +0100, Joerg Ostertag (OSM Munich/Germany) [EMAIL PROTECTED] writes: On Freitag 23 November 2007, Frederik Ramm wrote: Mein GPS zeigt die Höhe zwar an, speichert sie aber dummerweise nicht ab, aber das machen andere hoffentlich besser. Schön wäre da in JOSM also ein Feature um diese Info zu übernehmen. Dafür ist die GPS-Höhenmessung zu ungenau. Ist das wirklich so. Aus meiner Erfahrung kann die absolute Höhe bis zu 50m von der echten höhe abweichen. Jedoch sollte die relative Höhe innerhalb eines Tracks recht gut sein. Im Stehen springt die Hoehe auf freier Flaeche auch so nach und nach in einer Bandbreite von 10m, 15m. Innerhalb eines Tracks sind relative Angaben ganz gut, wenn man Wege mehrfach abgeht oder im Dreieck, so dass man Vergleichsdaten hat. Daher könnte man über einen recht genauen Grunddatensatz - ich glaube das waren die freien SRTM Daten der Nasa - ein raster (alle 50Meter) mit Stützpunkten hoher Genauigkeit bekommen. Wenn man nun die Tracks anhand dieser Daten justiert, sollte das Ergebnis auch für etwas anspruchsvollere Anwendungen recht zufriedenstellend sein. Die SRTM-Daten sind nicht _so_ genau wie mancher meint. Hier gibt es insbesondere Probleme beim Versatz und der Aufloesung (besonders bei grossen Hoehenunterschieden auf wenigen Metern), und bei unterschiedlicher Bebauung/Bepflanzung (bspw. Wald). Bei Uebernahme der Daten sollte man also nicht zu sehr auf eine grosse Genauigkeit vertrauen. Was Hoehen betrifft, versuche ich alle verfuegbaren freien Hoehenangaben mit einzupflegen: Hoehen von Berggipfeln etc. findet man meist auf demselbigen (oder Wikipedia :-), bei Landmarks wie historischen Gebaeuden etc. und auch bei Neubauten findet man haeufig Hoehen-Angaben bzw. -Markierungen der Vermesser. Mit diesen kann man die GPS- und SRTM-Hoehen dann abgleichen und korrigieren. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] GPS-Hoehe (was: Klare highway tagging Regeln f?r befestigte, Stra?en)
Hallo, on Friday, 23 November 2007 00:06:03 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Mein GPS zeigt die Höhe zwar an, speichert sie aber dummerweise nicht ab, aber das machen andere hoffentlich besser. Schön wäre da in JOSM also ein Feature um diese Info zu übernehmen. Dafür ist die GPS-Höhenmessung zu ungenau. Ist das wirklich so. Kommt drauf an, was Du mit den Hoehendaten machen willst. Zum Speichern ist natuerlich nichts zu ungenau, aber zum Nutzen vielleicht schon. -Welche Genauigkeit wird denn benötigt, Das kommt auf den Anwendungszweck an. Naja, einige Anwendungen fallen einen da schon ein: beispielsweise ist fuer Radfahrer und auch Wanderer/Fussgaenger die Hoehen- oder Steigungsinformation sehr nuetzlich. - Bei meinem Navi kamnn ich auch die Zahl der jeweils empfangenen Satelliten speichern. Hierdurch ist auch eine gewisse Aussage über die Genauigkeit der Höhe möglich Mir ist natürlich bekannt, dass Reflektionen der Signale ztu Fehlern führen könnnen. Das Problem liegt darin, dass das GPS die Position um so genauer bestimmen kann, aus je unterschiedlicheren Richtungen es Signale empfaengt. Sieht es z.B. nur lauter Satelliten vor Dir und keinen hinter Dir, dann ist die Positionsbestimmung wesentlich ungenauer, als wenn es von beiden Richtungen Satelliten saehe. In diesem Fall sollten die *DOP-Werte auch entsprechend schlecht sein, selbst wenn viele Satelliten sichtbar sind. Bei der Hoehe ist es nun so, dass die Satelliten eben immer alle (grob) in der gleichen Richtung sind, naemlich oben. Koennte man Satelliten von der anderen Erdseite empfangen, so koennte man die Hoehe ebenso exakt bestimmen wie die Laenge oder Breite. ... wobei alle 3 Werte (Laenge, Breite, Hoehe) auch bei einer _sehr guten_ Satelliten-Konstellation dennoch ganz schoen danebenliegen koennen! Die GPS-Empfaenger koennen nicht herausfinden, ob ein Signal reflektiert wurde, ob also die Laufzeit entsprechend laenger ist. Am Waldrand oder neben einem Haus bekommt man daher oft einen Versatz, den man nur durch weitere Sensorik (bspw. Gyro/Drehratensensor und Odometer/Wegstreckenmesser) ausgleichen koennte ... oder eben durch lokales Wissen, wie Wege etc. verlaufen und zueinander angelegt sind. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Klare highway tagging Regeln f?r befestigte, Stra?en
Hallo, on Friday, 23 November 2007 00:20:19 +0100, Frederik Ramm [EMAIL PROTECTED] writes: Nein, eben nicht wirklich (abgesehen davon, dass Kfz-Straßen so nicht existieren). Auf kraftfahrstraßen gelten andere regeln als auf einer normalen bundesstraße; das ist der hauptgrund, warum man kraftfahrstraßen, und nur diese, als trunk taggen sollte. Kraftfahrsstrasse ist eine zusätzliche Eigenschaft einer Bundes-, Landes-, Kreis- oder Gemeindestrasse und hat von daher nichts im highway-Tag verloren sondern benötigt einen zusätzlichen Tag (Flag). Ich habe gerade nicht den Ueberblick, ob diese Diskussion gerade fertig ist oder nicht ;-) aber just for the record gebe ich meinen Senf auch noch dazu: Ein eigener Wert im Schluessel highway fuer Bundesstrassen macht keinen Sinn; die Verwendung von trunk aussschliesslich hierfuer halte ich ebenfalls fuer Unsinn. Wenn wir schon die gleichen Werte verwenden wie der Rest der Welt, dann duerfen wir nicht in einen Wert etwas hineininterpretieren (trunk = keine Mofas), was anderswo so nicht der Fall ist. +1 [...] Und zurueckkommend auf die urspruengliche Diskussion um Klare highway-tagging-Regeln: Ich denke es wird _nicht_ moeglich sein, diese so klar und eindeutig festzulegen, dass zwei Leute fuer daselbe Strassenstueck immer dieselben Tag-Werte setzen werden. Dies war fuer die beiden grossen kommerziellen Kartenhersteller schon nicht moeglich, weswegen sich deren Functional-Road-Class-Werte auch unterscheiden und selbst innerhalb eines Herstellers gibt es trotz Schulungen gebietsweise leichte Unterschiede. Wie soll das bei OSM mit einer unbekannten Menge von Freiwilligen moeglich sein? Die Regeln sollen einsichtig sein und fuer mich waren die Beschreibungen im Wiki zusammen mit den Bildern als OSM-Einsteiger einsichtig genug ... ausserdem fing ich nicht im leeren Raum an, sondern es gab Wege in meinen Gebieten, an deren highway-Klassifierung ich mich richten bzw. anlehnen konnte. Was mir vom Gefuehl her fehlt(e), waren/sind eher ein paar Faustregeln und vielleicht noch einige Abgrenzungsmerkmale zwischen den highway-Werten zusammen mit weiteren Beispielbildern. Und auch fuer's Routing ist highway ein wichtiges Kriterium zur Berechnung des Kantengewichts ... aber es ist nicht das einzige, das einfliessen darf. Beispielsweise kann ein niedriger maxspeed-Wert einen highway-Wert entsprechend abwerten. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Composite Tags - als Relationen oder doch besser durch Erweiterung des Datenmodells
Hallo zusammen, da ich noch nicht s lange bei OSM dabei bin, kenne ich mich in der Entwicklung des Datenmodells etc. nicht aus ... aber vielleicht kann mir dennoch jemand meine Fragen beantworten: Als erst kuerzlich (vor meiner Zeit :-) die Relationen als neuer Teil des Datenmodell verabschiedet wurde, las und lese ich, dass damit auch zusammengehoerende Tags als Composite Tags (http://wiki.openstreetmap.org/index.php/Relations/Proposed/Composite_Tag) erschlagen werden sollen. Aber bislang gibt es (a) noch keinen brauchbaren Vorschlag und (b) mir straeubt sich alles, eine Relation zwischen einem Element (siehe OSM-Wiki 'Elements') und einer Menge an Attributen zu definieren, um bspw. einem 'Way' ein Speed-Limit und ein zeitlich eingeschraenktes Speed-Limit verpassen zu koennen. Die Relation waere hier ja eine _unaere_ Relation, also im strengen Sinne keine. Je laenger ich darueber nachdenke (und mit meinem GDF-Hintergrund der dort vorhandenen Simple- und Composite-Attributes) waere es fuer mich das natuerlichste, wenn man die bisherige einfache Tag-Struktur (flache, ungeordnete Menge) zu einem Element einfach mit einer Gruppierungsebene versehen koennte. Also statt dem nicht moeglichen way ... tag k=maxspeed v=120 / tag k=maxspeed v=100 / tag k=hour_on v=22 / tag k=hour_off v=6 / /way mit einer Gruppe eine moegliche Darstellung als way ... tag k=maxspeed v=120 / taggroup tag k=maxspeed v=100 / tag k=hour_on v=22 / tag k=hour_off v=6 / /taggroup /way Waere aufwaertskompatibel und sicher im JOSM sehr viel einfacher zu realisieren als Composite-Tags per Relation einzufuehren. Oder uebersehe ich hier etwas? Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Ortsschild taggen
On Tuesday, 20 November 2007 03:21:14 +0100, Dimitri Junker [EMAIL PROTECTED] writes: [...] Was hat landuse mit dem Ortsschild zu tuen? Es gibt unbebaute Gebiete in Städten und bebaute außerhalb. Das Ortsschild sagt nur etwas rechtliches aus, nichts über die Bebauung. Ich tagge das Ortschild aus mehreren Gruenden: 1. Es ist ein sehr guter landmark zur Navigation (egal ob Fzg, Fahrrad oder zu Fuss), 2. es hat rechtliche Auswirkungen auf die maxspeed der Strasse, 3. es deutet auf Bebauung hin. Bezueglich Punkt 2 und 3 ist das Verkehrsschild eigentlich redundant, da die entsprechenden Areas (bebautes Gebiet bzw. Ortsgrenzen) so oder so explizit erstellt und das Way-Tag maxspeed korrekt gesetzt werden muss ... aber jede redundante Info kann man nutzen, um die Karte auf Plausibilitaet zu pruefen. Fuer mich ist Punkt 1 aber wichtig, da man dann Navi-Hinweise wie direkt nach dem Ortsanfangsschild links abbiegen erzeugen koennte oder dies aus einer entsprechende Karte herauslesbar waere. Mir geht es nicht so sehr, direkt aus der Schildinfo gleich eine abgeleitete Info (Geschwindigkeit, Area-Grenzen o.ae.) zu generieren, sondern diese Schilder sind erst einmal eigenstaendige POI. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Ortsschild taggen
On Monday, 19 November 2007 09:57:52 +0100, Damian Sulewski [EMAIL PROTECTED] writes: Am Montag, 19. November 2007 schrieb Dimitri Junker: Du malst einen kleinen Querstrich und taggst landuse=residential, Dafür gibt es doch place=city (oder town, village,...) Sowohl landuse als auch place sind für node und area vorgesehen. klar. Die Idee hinter dieser Strick-Bastelei ist wohl auch, dass irgendwann jemand kommt und den Strich zur area vervollständigt. und genau deswegen male ich auch Striche. Nicht nur am Ortseingansschild sondern auch an Schilern die Ortsteile trennen. Irgendwo steht, es wird an einer Relation gebastelt die alle Grenzen eines Landes verbindet, so das man einen Umriss hat, diese hoffe ich dann für Städte und Stadtteile ausweiten zu können. Mmmh, das Problem hierbei ist, dass da zwei Dinge miteinander vermischt werden: - Mit landuse=residential/... erstelle ich einen Fussabdruck eines bebauten oder sonstwie genutzten Gebiets. - Das Ortsanfangs- bzw. -endeschild, das gleichzeitig implizit und rechtlich bindend die Strasse auf die innerorts gueltige Geschwindigkeit fuer Fahrzeuge beschraenkt. Beide Dinge haben oft, aber eben nicht immer etwas miteinander zu tun, d.h. ein Ortsanfangsschild kann bereits auf der gruenen Wiese stehen oder auch erst recht spaet im bebauten Gebiet bei nur einseitig bebauten Strassen. (In den momentan vorhandenen Navi-Karten existiert das selbe Problem: Ein Wechsel der Geschwindigkeitsbeschraenkungen deutet auf das Schild hin, aber manchesmal findet man ein 50 auch schon vor dem offiziellen Schild oder dieses wird mit einem hoeheren Limit kombiniert, so dass alles nicht eindeutig ist.) Daher will ich fuer relevante Verkehrsschilder _immer_ explizit einen Knoten mit traffic_sign=city_limit o.ae. taggen. Momentan setze ich noch Kommentare, da ich vorher nochmals nachsehen wollte, ob es bereits entsprechende Vorschlaege gibt. Aber fuer das Ortsanfangsschild splittet man meist so oder so den Weg an der entsprechenden Stelle aufgrund des Wechsels der Geschwindigkeitsbeschraenkung, d.h. man setzt in D meist fuer den inneroertlichen Weg maxspeed=50. Zum Tagging: boundary=administrative (wie im wiki) border_type=city oder suburb (noch nicht im wiki) temporär füge ich ein (damit jeder die Ways später benutzen kann) name_right=Dortmund (name der Stadt oder des Stadtteils rechts vom Segment) name_left=Lünen falls border_type=city kommt machmal zu name_right=Dortmund: suburb_right=Dorstfeld (Name des Stadtteils der rechts vom Segement liegt) und ein is_in=Dortmund bei suburb [...] Mmmh, auch eine gute Idee. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tags für Strasse in Bau / Planung
On Saturday, 17 November 2007 12:16:12 +0100, TimG [EMAIL PROTECTED] writes: Tags für Strasse in Bau / Planung - gibt es sowas schon? Mit (geplantem)Ausführungsdatum? Eventuell mit folgenden Tags aus den Map_Features: start_date = Datum # Date feature was created end_date = Datum # Date feature was removed Mmmh, reicht aber nicht aus, da das Feature mehrere Zustaende (in Planung, in Bau, in Bau+offen, fertig) besitzt. Daher wuerde ich mich hier GDF bedienen und ein Tag construction_status=... mit den Werten planned under_construction_closed under_construction_open verwenden, zu denen man dann obige Datumsangaben hinzufuegen koennen sollte (hier im Konjunktiv, da OSM noch keine zufriedenstellende Loesung fuer eine Menge zusammengehoerender Tags aka ein Composite-Tag besitzt). Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zuordnung von Hausnummern
On Saturday, 17 November 2007 22:20:53 +0100, Dirk-Lüder Kreie [EMAIL PROTECTED] writes: Bernd Raichle schrieb: [...] Solange kein Konsens da ist, tagge ich einfach mit meinem eigenen Schema: housenumberstructure:left=regular housenumberstructure:right=regular housenumbers:left=1-10 housenumbers:right=100-109 wobei left und right die Strassenseite bezueglich der Richtung des Weges ist. Als Hausnummern verwende ich nur die Zahlen ohne Zusatz im Format first - last, also die erste zu Beginn des Weges und die letzte am Endes des Weges (kann auch 10-1 statt obiger 1-10 sein). Als Schema verwende ich none (keine Hausnummern vorhanden), regular (regulaere Folge ohne Luecke), odd (nur ungerade), even (nur gerade) und irregular (wild durcheinander, dann werden die Hausnummern explizit aufgezaehlt). Lehnt sich an GDF an, wobei dort eine Kante nur von Kreuzung zu Kreuzung geht, waehrend in OSM ein Way gleich ueber mehrere Kreuzungen gehen kann, so dass mein Schema nicht block-genau ist ... ausser man trennt einen Way an jeder Kreuzung auf. Vielerorts ist die Kennzeichnung ob die Nummern gerade oder ungerade sind über Start- und Endzahl erkennbar: Ungerade: 5-23 Gerade: 8-16 Regular: 1-10 Was mache ich aber, wenn ich eine regular-Struktur mit dem Bereich 5-23 oder 8-16 vorfinde? Implizite Kennzeichnung ist nur gut, wenn sie keine Mehrdeutigkeiten zulaesst. IMHO sollte man die Strukturierung auf alle Faelle vorgeben, zumal ich mir dadurch in obigem sehr einfachen Schema dann auch all die anderen Hausnummernschemata nicht komplett verbaue, sondern diese noch nachtraeglich hinzufuegen kann, in dem ich die moeglichen Werte des Tags erweitere und weitere (Unter-)Tags hinzufuege. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Woher bekommt man Bahnlinien?
On Friday, 16 November 2007 07:53:48 +0100, Karl Eichwalder [EMAIL PROTECTED] writes: OK, man kauft sich ein Ticket und loggt mit... aber es gibt ja auch Strecken, die nur noch von Güterzügen befahren werden. Eine Draisine habe ich leider auch nicht zur Hand - also zu Fuß ablaufen oder doch Google...? Einfach näherungsweise eingeben, nach gefühl (source=extrapolation). Nach und nach werden die strecken von begehern schon an die richtige stelle gerückt werden. Einfach mal machen und nicht so viel diskutieren oder gar problematisieren -- wir sind hier nicht an der Uni ;) Bachlaeufe, ueber die ich gehe/fahre, tagge ich bei der Begehung als kurze Stummel (Stub), aehnlich kann man es mit Bahnstrecken machen. Die kurzen Stummel dann nach Gefuehl verbinden -- ist bei Bahnstrecken mit ihren doch sehr grossen Mindestradien deutlich einfacher als bei maeandernden Baechen :-). Abschnittsweise helfen sehr haeufig auch parallel laufende Wege, die man bereits aufgenommen hat. Alternativ/zusaetzlich kann man sich eine _frei verwendbare_ WMS-Karte (bspw. Yahoo) im JOSM-/Potlatch-Editor darunterlegen und nach Abgleich des evtl. vorhandenen Versatzes als Anhaltspunkte verwenden. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Woher bekommt man Bahnlinien?
On Friday, 16 November 2007 10:40:53 +0100, qbert biker [EMAIL PROTECTED] writes: Hallo, mittels der Landsatbilder geht das auch so einigermassen. Man sollte vorher schon ungefähr wissen, wo die Bahnlinie ist und braucht ein gutes Auge. Die genannten Stummel sind da ein guter Ausgangspunkt. Ich habe mit dieser Methode schon ein paar Bahnlinien eintragen können. ... und die Stummel sind noch wichtig, um diese Teile als Wege mit bridge=yes oder tunnel=yes und anderem layer=...-Wert zu kennzeichnen, sodass sie entsprechend auf den Karten gezeichnet werden, da Bahnlinien und Wasserlaeufe sich sehr selten ebenerdig mit Strassen und Fusswegen kreuzen. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Weinberg taggen
On Friday, 16 November 2007 06:38:29 +0100, Karl Eichwalder [EMAIL PROTECTED] writes: Ich finde landuse=vineyard auch gut. Auf http://wiki.openstreetmap.org/index.php/Proposed_features/Vineyard steht allerdings (und das ist erst 10 Tage her), dass man doch landuse=farm, produce=grapes oder so machen sollte... ich schreib mal was in die Diskussion (bin dann aber nach Diktat verreist ;-) Ich wäre sehr dafür, das landuse allgemein zu halten und die präzisierung in zusätzlichen attribute abzulegen. Die highway-verwilderung sollte als warnendes beispiel dienen. ok, aber dann ist landuse=farm auch nicht gerade ideal, da ein Weinberg (in meiner Gegend) keine Farm/(Bauern-)Hof/u.ae. ist, sondern eine landwirtschaftlich genutzte Flaechem. Daher wuerde ich dies eher als landuse=agriculture; produce=grapes taggen (wollen). Bei wenigen landuse-varianten hat ein renderer die chance, tendenziell etwas sinnvolles machen zu können, auch wenn er nicht jedes zusätzliche attribut auswertet. Momentan habe ich auch landuse=vineyard verwendet, da es in meiner Gegend (Remstal) viele Weinberge gibt, mit der man die Landschaft gut gliedern kann. Falls sich ein Konsens bzgl. Tagging ausgebildet hat, ist eine automatische Ueberfuehrung in landuse=...; produce=... leicht moeglich. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tagging-Frage: Marktplatz
On Thursday, 15 November 2007 09:22:15 +0100, qbert biker [EMAIL PROTECTED] writes: Wenn da ein Hindernis ist muß es eh aus der area ausgeschlossen werden. Und da haben wir evtl. wirklich ein Problem. Bisher werden area durch eine zusammenhängende Linie umgeben. Statt eines O wird also ein C gezeichnet, bei dem die Öffnung nicht sichtbar ist, aber ein router könnte die Öffnung für ein Hindernis halten. Kurz mal zur technischen Seite: Die typischen Router können mit Flächen nichts anfangen, weil sie auf einem Graphen aufbauen. Der Graph kennt nur Knoten und die kürzeste Verbindung dazwischen. Das lässt sich bei einem Platz nicht wirklich schön umsetzen, man kann z.B. alle Zufahrten gegeneinander verbinden. Der Normalfall ist aber, dass der Router die Flächenangabe erstmal ignoriert und die Linie drumrum als Straße wahrnimmt, weil das eine recht gute Näherung darstellt. Erst bei großen Plätzen funktioniert das dann nicht mehr so richtig, aber die sind ja dann auch meistens strukturiert. Naja, ein Router, der eine Wegeverbindung _schnell_ finden soll, wird so oder so das Netz im Rohformat in einen Graphen mit Indizierung wandeln, in denen solche Plaetze entsprechend konvertiert und fuer die Navigationshinweise entsprechend markiert werden. Wie es ein Router konvertiert haben will, ist deren Sache. Das sollte daher alles kein Problem sein, solange das Ding eindeutig entsprechende Tags bekommt. In GDF gibt es das Konzept der Enclosed Traffic Area: any confined area within which unstructured traffic movements are allowed. Ist eine Area, die entsprechend markiert ist (GDF-speak: Area-Feature mit Feature-Code 4135, ein Area-Fature besteht dabei aus Faces, die wiederum durch Edges festgelegt sind). Im bisherigen OSM-Konzept waere das so etwas wie eine geschlossener Way mit area=yes und eine entsprechendes Tag highway=residential und/oder access=yes, das ein Hinweis auf die Befahrbarkeit/Begehbarkeit der Flaeche erlaubt. Letzteres muss fuer Flaechen noch vorgeschlagen und genauer beschrieben werden, da die entsprechenden Tags momentan nur fuer Ways und Points beschrieben sind. Bei echtem Flächenroutung, z.B. explizit für Fussgänger, bewegt man sich sowieso auf Neuland und muss das explizit entwerfen und umsetzen. [...] Wenn man das Navi-Geraet dabei hat, kann man auf einem Platz noch die Himmelsrichtung angeben. Ohne wird sich aber ein markanter Punkt (= Landmark wie Kirchturm, Rathaus, Brunnen, Restaurant oder sonstiger Point-of-Interest) als Hinweis besser eignen ... Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zuordnung von Hausnummern
On Friday, 16 November 2007 14:01:02 +0100, dieter jasper [EMAIL PROTECTED] writes: Sven Anders schrieb: Am Freitag, 16. November 2007 12:20 schrieb dieter jasper: Hallo, es ist sicher zukünftig vorgesehen, den Straßen auch Hausnummern zuzuordnen. Kann bzw. sollte dies jetzt schon berücksichtigt werden. Oder einen Straßenabschnitt: name=Cuxhavener Straße highway=primary place_numbers=309-512 Aber wie löse ich folgendes Problem bei Straßenabschnitt: z. B. Linke Seite: z. B. Hausnummer = 1 - 10 Rechte Seite: Hausnummer = 100- 109 Hausnummern sind Proposed_Features und werden im OSM-Wiki noch diskutiert. Solange kein Konsens da ist, tagge ich einfach mit meinem eigenen Schema: housenumberstructure:left=regular housenumberstructure:right=regular housenumbers:left=1-10 housenumbers:right=100-109 wobei left und right die Strassenseite bezueglich der Richtung des Weges ist. Als Hausnummern verwende ich nur die Zahlen ohne Zusatz im Format first - last, also die erste zu Beginn des Weges und die letzte am Endes des Weges (kann auch 10-1 statt obiger 1-10 sein). Als Schema verwende ich none (keine Hausnummern vorhanden), regular (regulaere Folge ohne Luecke), odd (nur ungerade), even (nur gerade) und irregular (wild durcheinander, dann werden die Hausnummern explizit aufgezaehlt). Lehnt sich an GDF an, wobei dort eine Kante nur von Kreuzung zu Kreuzung geht, waehrend in OSM ein Way gleich ueber mehrere Kreuzungen gehen kann, so dass mein Schema nicht block-genau ist ... ausser man trennt einen Way an jeder Kreuzung auf. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Klare highway tagging Regeln für befes tigte Straßen
On Wednesday, 14 November 2007 13:38:56 +0100, Daniel Schmidt [EMAIL PROTECTED] writes: Eben - die Bilder sollten die Wichtigkeit der Straße widergeben, das erwartet die Masse der Anwender. So sehe ich das auch. Die administrative Einteilung erhalte ich doch sowieso aus dem ref-Tag: was mit A beginnt ist eine Autobahn (Bund), was mit B beginnt, ist eine Bundesstraße (auch Bund), Staßen mit L oder St sind Landes- bzw. Staatsstraßen (Ländersache) und für die mit K beginnenden Kreisstraßen sind die Kreise zuständig. Mmmh, es gibt in D'land auch Route-Numbers, die mit A oder B beginnen und _keine_ Autobahnen und Bundesstrassen sind: In Bayern werden Kreisstrassen nicht mit K1234 sondern mit dem Kfz-Kennzeichen des Kreises angegeben, also PAF1234 oder AB1234. Daher besteht im GDF-Standard das Route-Number-Information-Attribut auch aus dem String und dem Route-Number-Type, der laenderabhaengig eine Klassifizierung (wie Kreisstrasse) unabhaengig vom String (wie AB1234) angibt. Hier kann man auch eine Priorisierung angeben, da bspw. in D'land eine Europastrasse in der Wichtigkeit (Ausbauzustand etc.) _unter_ einer Autobahn und unter oder gleichrangig mit einer Bundesstrasse steht. Wenn also die administrativen Informationen bereits enthalten sind, ergibt sich daraus für mich, dass primary, secondary, tertiary für die Qualität der Straße steht, ansonsten hätten wir ja eine Redundanz. In GDF gibt die beiden Attribute Functional-Road-Class (FRC) und Form-of-Way (FoW): Der FRC sagt etwas ueber die Wichtigkeit der Strassenverbindung im Netz aus. In D'land gilt: Autobahnen = FRC=0 (0=wichtigste Verbindungsklasse), aber es gilt nicht der Umkehrschluss, dass alle FRC=0 auch Autobahnen sind, denn in Gebieten ohne Autobahnen werden auch wichtige Strassenverbindungen mit FRC=0 markiert. Der FoW sagt etwas ueber den Physischen Ausbauzustand der Strasse aus: gemeinsame oder getrennte Richtungsfahrbahnen, Motorway, Kreisverkehr, Ueberleitung (Slip Road), Rampe, Ein-/Ausfahrt, Fusswege etc. Weitere Attribute beschreiben zusaetzliche Eigenschaften wie Freeway/Controlled Access fuer Strassen mit Mindestgeschwindigkeiten und kreuzungsfreiem Verkehr, sprich Autobahnen und autobahnaehnlich ausgebaute (Bundes-)Strassen. Momentan ist das highway-Tag in OSM ein Mischmasch aus allen diesen Dingen. Hierbei entspricht das trunk, primary, secondary, tertiary am ehestem dem FRC aus GDF. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Klare highway tagging Regeln für befes tigte, Straßen
On Friday, 16 November 2007 15:23:01 +0100, Christian Kögler [EMAIL PROTECTED] writes: Am Freitag, den 16.11.2007, 14:48 +0100 schrieb Christian Kögler: Bzgl. Kraftfahrstrasse: Das ist ein Attribut das eine Strasse näher spezifiziert bzgl. Verkehrsbeschränkungen wie es eine Gewichts- oder Geschwindigkeitsbeschränkung macht. Hat aber nichts mit der Strassenkategegorie zu tun bzw. Macht es unnötig kompliziert wenn man das in die Kategorie mit reinpressen will. Den Vorwurf das mein Vorschlag die Radfahrer benachteiligt versteh ich nicht, es gehen ja keine Informationen verloren. Den Renderer/Router muss man so oder so mit Optionen für Fahrzeugkategorien ausstatten der auf weitere Tags zugreifen sollte um eine entsprechend optimale Darstellung/Route zu bekommen. Da gebe ich dir absolut Recht. Dein Regelwerk-Vorschlag ist somit konsistent. Je länger ich über deinen Regelwerk-Vorschlag nachdenke, desto mehr bin ich davon überzeugt! Nur sollten wir ein KraftfahrtstraÃen-Tag finden. Ich würde motorroad=yes vorschlagen. http://en.wikipedia.org/wiki/Motorroad ... oder wir erschlagen die Unterscheidung zwischen normaler Bundesstrasse und autobahnaehnlich ausgebauter Bundesstrasse (= Kraftfahrtstrasse) ueber eine allgemeinere Auszeichnung _aller_ passenden Strassen mit freeway=yes http://en.wikipedia.org/wiki/Freeway liefert im Abschnitt General characteristics bereits eine gute Definition: kreuzungsfrei (no cross traffic), Zugang nur bei Ein-/Ausfahrten moeglich (controlled access), erlaubt hoehere Geschwindigkeiten, hat Verkehrsbeschraenkungen. Schoenes Wochenende, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
