Re: [Talk-de] Vorschlag neuer Geometrie (relationen)-Typ: node-relation
On Thursday, 10 July 2014 15:41:03 +0200,
Martin Koppenhoefer writes:
> Am 10. Juli 2014 14:55 schrieb Tobias Knerr :
>
> > 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:
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 Heading/Nordwinkel) angeben.
Gruss,
Bernd
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://l
Re: [Talk-de] Taggen von mit Fahrradwegweisern ausgeschilderten Strecken
Hallo zusammen,
on Sunday, 13 October 2013 11:55:14 +0200,
Manuel Reimer 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 writes: > Am 7. August 2012 17:25 schrieb Bernd Wurst : > > 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: 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 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.592379&lon=8.855888&zoom=18&layers=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 writes:
> Am 14. Juli 2010 13:46 schrieb Bernd Raichle :
> > > > 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 writes: > Am 13.07.2010 um 21:07 schrieb M∡rtin Koppenhoefer: > > Am 13. Juli 2010 19:06 schrieb steffterra : [...] > >> 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 16:48:40 +0200, M∡rtin Koppenhoefer writes: > Am 13. Juli 2010 15:53 schrieb Bernd Raichle : > > 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] Durchgehende Mittellinie
On Tuesday, 13 July 2010 16:35:15 +0200, M∡rtin Koppenhoefer writes: > Am 13. Juli 2010 02:27 schrieb Tirkon : > > 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 13:32:51 +0200,
Martin Simon writes:
> Am 13. Juli 2010 00:58 schrieb Dimitri Junker :
> > 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] Kategorien-Sprach-Chaos im Wiki
On Sunday, 27 September 2009 23:07:16 +0200, Martin Koppenhoefer writes: > Am 27. September 2009 22:16 schrieb Thomas Ineichen : > > 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: [Talk-de] Routing Fehler A3-B58
On Thursday, 25 June 2009 06:16:55 +0200, Marcus Wolschon writes: > 2009/6/24 Bernd Raichle : > > On Wednesday, 24 June 2009 14:44:23 +0200, > > marcus.wolsc...@googlemail.com writes: > > > On Wed, 24 Jun 2009 12:50:37 +0200, Claudius 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] DXF-Datei Gemeindegrenze - OSM
On Wednesday, 24 June 2009 23:56:30 +0200, Mirko 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 Wednesday, 24 June 2009 14:44:23 +0200, marcus.wolsc...@googlemail.com writes: > On Wed, 24 Jun 2009 12:50:37 +0200, Claudius 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 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:
Re: [Talk-de] Freihand-Zeichnungen von Luftbildern und Kart en möglich!
On Thursday, 18 June 2009 21:42:41 +0200, Johannes Huesing 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 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 writes: > Markus 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 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: [Talk-de] Verkehrsinseln
On Friday, 30 January 2009 18:13:36 +0100, Bernd Wurst 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. > >7710525&end=6.1163058,50.7714249&pref=Fastest&lang=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 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@openstr
Re: [Talk-de] Fehlende Straßen/Wege/Pfade
On Friday, 9 January 2009 17:10:02 +0100, Jan-Benedict Glaw writes: > On Fri, 2009-01-09 16:55:52 +0100, Claudius Henrichs > 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 writes:
> 2008/12/2 Alexander Schulze :
> >> 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] qualitätsoffensive - nicht angebunden e straßen - teilweise katastrophale datenqualität
On Tuesday, 9 September 2008 02:42:24 +0200, Andre Reichelt <[EMAIL PROTECTED]> writes: > Sebastian Waschik schrieb: > > dann setze doch an die Knoten die Kreuzungen sind ein Strassenstummel > > oder setze ein FIX-Tag an den Knoten. > > Kann sein, dass ich da schonmal unbewusst was verschoben habe, als ich > den Strassenverlauf verbessert habe, da die Tracks teilweise richtig mies > sind. > > Ich mache das in der Regel so, dass ich einfach ein kurzes Stueck der > abzweigenden Strasse ansetze. Dann ist jedem sofort klar, dass da etwas ist. Wenn ich einen "normalen" Knoten vorfinde, verschiebe ich den auch ... Wenn du also markieren willst, dass an dem Knoten Strassen abgehe, haenge mal lieber kurze "Strassenstummel" (stubble) mit einem FIXME an diesen Stellen dran, dann ist das auch fuer andere eindeutig. 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] 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] 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] 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: [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] Bruecken/Node-Problem
On Tuesday, 8 April 2008 18:11:54 +0200, Dirk-Lüder Kreie <[EMAIL PROTECTED]> writes: > Bernhard Seckinger schrieb: > Nein... ich frage mich vielmehr, woher die Renderer wissen > sollen, dass dort eine Bruecke ist. Potlatch zeigt weder > ein Bruecken-Tag an geschweige denn verschiedene Layer. > Ich wuerde es an Deiner Stelle mal damit versuchen. > >>> ok, dass mit der Brücke hab' ich vergessen; aber layer=1 ist gesetzt. > >>> Und woher > >>> der Renderer das wissen soll? Am nicht vorhandenen "level_crossing" > >>> natürlich. Naja, ich schlage vor, es besser "andersherum" zu versuchen, d.h. das als Bruecke dienende Strassenstueck explizit mit "bridge=yes" (oder "tunnel=yes") taggen, damit Renderer, Router und andere Applikationen da keine Fehler machen. Die wenigsten Mapper verwenden ueberall, wo sinnvoll den "level_crossing"-Tagwert, so das man aus einem fehlenden level_crossing nicht auf eine kreuzungsfreie Verbindung schliessen kann. > >> Durch das Setzen eines gemeinsamen Nodes hast du nunmal eine Verbindung > >> zwischen Straße und Bahngleisen hergestellt. Wenn zwei sich kreuzende > >> Straßen eine Node teilen, hast du auch eine Kreuzung produziert. > > > Hmm. Ja und nein. Hängt natürlich ganz davon ab, wie man das > > interpretiert... > > Durch die unterschiedlichen Layer-Tags ist's ja im Grunde genommen klar, > > dass > > hier keine Verbindung besteht; aber ich sehe schon, dass man das nicht so > > ohne > > weiteres annehmen kann; am Ende einer Brücke hat man ja auch einen Sprung > > im > > layer und trotzdem eine Verbindung. > > Im Gegensatz zu Herkömmlichen GIS systemen benutzt OSM Topologie, wenn > du also einen gemeinsamen Node hast, bedeutet dies, dass die Features > dort auch verbunden sind, sonst wär's z.B. unmöglich innerhalb eines > Straßenverlaufs das Layer zu wechseln. > > Layer-infos sind also nur dafür da die Räumliche Ordnung von sich ohne > gemeinsamen Node kreuzenden Ways festzulegen. ... was insbesondere fuer die Renderer sehr wichtig ist, damit die wissen, was ueber/unter was gezeichnet werden sollte. Haette OSM wie GDF neben dem Knotentyp (Kreuzungs-)Node, der die Topologie festlegt, auch den Knotentyp Shape-Node (oder "Intermediate Node"), der die Geometrie einer Kante/eines Ways bestimmt, dann koennte man in diesem Fall einen Shapepoint auf dem Schnittpunkt highway/railway setzen und diesen im landuse-Area-Umriss verwenden. Gibt es aber bei OSM nicht. Aber noch eine andere Frage in diesem Zusammenhang: Sollen fuer "landuse-" und aehnliche Areas die Strassen-, Fuss- und sonstige Wege mitbenutzt werden ... oder sollte man besser Areas mit eigenem Umriss definieren? Ersteres wird durch den JOSM-Validator ja angemeckert. Und ein eigener Umriss ohne Verwendung der Strassen- und Bahntrassen-Ways haette nicht zu Bernhards Problem mit dem Kreuzungsknoten gefuehrt. 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
On Sunday, 6 April 2008 17:25:57 +0200, André Reichelt <[EMAIL PROTECTED]> writes: > Warum nicht einfach access? Genau dieses: Jede Kante, fuer die "Anlieger frei" gilt, bekommt ein "access=destination". Und wenn ich einen Ort habe, bei dem _alle Zufahrtsstrassen_ mit dem Schild versehen ist, dann haben doch _alle_ Strassen dieses Ortes diesen Status, auch wenn das Schild nicht an jeder Kreuzung wiederholt wird, oder? Dann sind auch alle Strassen, auch die innerhalb des Ortes mit "access=destination" zu versehen. 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,
On Sunday, 6 April 2008 13:28:56 +0200,
qbert biker <[EMAIL PROTECTED]> writes:
> > 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.
>
> Ich mach das so, dass die Vorgabe ist, dass erstmal alle
> 'Anlieger frei' einen Widerstand von 'undurchfahrbar' bekommen. Wenn
> keine Route möglich ist,
Mmmh, wenn du letzlich einen Dijkstra (+ Heuristiken) verwendest, dann
suchst du da unnoetig lange, bis du mit "keine Route" abbrichst.
> wird überprüft, warum das so ist und
> ob die Unerreichbarkeit aufgelöst werden kann. In diesem Sinn
> wäre das Szenario iterativ lösbar. Flags als an- abschaltbare
> Schranken würde ich meiden, da mir das Verfahren etwas zu
> fehleranfällig erscheint (Ausbruch über Feldweg, etc.).
Auch nicht fehleranfaelliger als alle andere Loesungen, nur hast du da
den Spezialfalls fuer "Anlieger-frei" (oder Privat- und Wegstrassen)
durch das Flag-Konzept sehr einfach und in einem Durchlauf abgehakt.
(Bzgl. Ausbruch ueber Feldweg: Fall 1: Wenn Feldwege als
nicht-Anlieger- Strassen getaggt sind/angenommen werden, dann ist der
Uebergang Anlieger-Nichtanlieger verboten, wenn du vorher von
Nichtanlieger nach Anlieger gewechselt hast. Fall 2: Wenn Feldwege
als Anlieger getaggt sind/angenommen werden, dann kommst du entweder
ueber diesen ans Ziel oder musst irgendwann auf eine Nicht-Anlieger
wechseln, so dass du wieder Fall 1 vor dir hast.)
> Eine andere Sache ist, welchen Aufwand man in einen derartigen
> Exoten investiert ;)
Ich habe zwar keine Statistik vorliegen, wieviel Prozent der
Haushalte, also der moeglichen Start- und Zieladresse in einer
Anlieger-Strasse wohnen, aber ganz so exotisch duerfte der Fall auch
nicht sein.
> > Damit dies klappt, muessen _alle_ Strassenbestandteile bzw. alle
> > Strassen des Gebietes zusammenhaengend und vollstaendig mit "Anlieger
> > frei" getaggt sein.
>
> Volle Zustimmung.
... andererseits muessen alle Router mit fehlerhaften Daten klarkommen
koennen (weder OSM noch die kommerziellen sind 100% fehlerfrei).
Und mit einigen Besonderheiten muss man leben oder sich ueberlegen,
wie man diese abhandelt, so dass die Ergebnis-Route so auch gefahren
werden darf. Beispiel:
| |
A B
| |
+--X---+---Y--
| |
A B
| |
Die Strassen A und B sind Durchgangsstrassen, X und Y sind
Anlieger-Strassen ("Anlieger frei"). X und Y haben damit das Tag
"access=destination" und besitzen einen gemeinsamen Knoten, da die
Kreuzung so klein ist, dass man sie nicht detaillierter abbildet.
Darf ein Verkehrsteilnehmer (also auch ein Router) nun von Strasse A
kommend ein Ziel in Y erreichen, indem er durch _X_ durchfaehrt und
dann in Y _einfaehrt_? Oder muss ich einen weg um X herum finden?
IMHO darf man nicht durch X durchfahren ... aber wie sehe ich als
Router aus den OSM-Daten, dass das Anlieger-frei-Schild von X durch
die Strasse B _beendet_ (/_unterbrochen_) wird? Waere in diesem Fall
B "nur" ein Fussweg, dann gelte X und Y als "eine" durchgehende
Strasse, so dass man durch X zu Y durchfahren darf.
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= > 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.011&lon=11.676&zoom=14&layers=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.8082&lon=9.3228&zoom=14&layers=B0FT Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
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
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//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
[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] 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 Prozentan
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
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 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
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 W
[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] 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 tagrelati
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
[Talk-de] abhaengig von der Richtung eines Ways (was: Seen und Inseln)
Hallo, on Wednesday, 16 January 2008 15:15:18 +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. > > Deshalb mal eine Frage: ist Deine Art, eine Insel zu kennzeichnen, > > einfacher? Schneller gemacht? Verbraucht weniger Ressourcen? > > Schneller gerendert? Oder...? > > 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? Die Richtung eines Weges gebe ich momentan durch die Zeichnungsrichtung, also der Digitalisierungsrichtung an, was sehr einfach, intuitiv und daher "natuerlich" ist. Da es einfach ist, kann man es natuerlich auch sehr einfach aendern. Will ich nicht die Zeichnungsrichtung als Richtung verwenden, gibt es momentan doch nur die Moeglichkeit, dies mit einer Relation zwischen einem Weg und zwei daraufliegenden Knoten zu tun. Damit bin ich zwar unabhaengig von der Zeichnungsrichtung, aber so richtig intuitiv und "natuerlich" ist ein solches Tagging nicht ... vielleicht weil es momentan nicht von den Editoren unterstuetzt wird? Mit einer solchen Relation koennte ich aber nicht nur die richtungsabhaengigen Beschreibungen abdecken, sondern auch Beschreibungen, die nur fuer Teile eines (laengeren) Weges gelten. Fuer diese muss man momentan einen langen Weg in viele kleinere Wege unterteilen (Beispiel: maxspeed, lanes; evtl. bridge + tunnel). Diese Relationen, die Tags fuer Weg-Segmente angeben, muessten in den Editoren bei der Tag-Liste eines Weges auftauchen, mit der Ergaenzung, fuer welchen Abschnitt (Start- + Endknoten) sie gelten und ob sie richtungsbezogen sind. ... jetzt aber genug der Ideen. Wer setzt es um? :-) 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 Tuesday, 15 January 2008 17:02:02 +0100, Raphael Mack <[EMAIL PROTECTED]> writes: > Am Dienstag, 15. Januar 2008 schrieb Bernd Raichle: > > * Geschwindigkeitsbeschraenkungen > > > > Beim Befahren derselben Strasse _in beide Richtungen_ faellt einem > > dann haeufiger auf, dass es Teilwege mit verschiedenen "maxspeed="- > > Eintraegen pro Fahrtrichtung gibt. Wie sollte dies getaggt werden? > > (Von den Zusatzschildern wie Lkw, Regen, Uhrzeiten etc. will ich mal > > ganz absehen.) > > > > Da ich im OSM-Wiki keinen passenden Vorschlag hierzu gefunden habe, > > behelfe ich mir momentan damit, dass ich in solchen Faellen den > > kleineren der beiden Werte mit dem Tag "maxspeed=" beim Way eintrage. > > 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 fände ein maxspeed_opposite passend, das sowas ja auch für > entgegengesetzte Radwege Verwendung findet. Mmmh, "opposite", "opposite_lane", "opposite_track" etc. wird bislang nur als Wert und nicht als Bestandteil des Tags verwendet, beispielsweise "cycleway=opposite". Ausserdem waere ein "offizieller" Tag-Zusatz, der z.B. vom JOSM bei Umdrehen eines Weges unterstuetzt wird (und wenn es nur in Form einer Warnung waere), am besten. > > * Fahrspuren > > > > Dasselbe Problem taucht bei "lanes=" auf, wo es fuer die beiden > > Fahrtrichtungen unterschiedlich viele Fahrspuren gibt (haeufig bei > > dreispurigen Bundesstrassen, in einer Richtung mit zwei Spuren, in > > Gegenrichtung mit einer Spur, wobei diese Aufteilung alle paar > > Kilometer oder bei Anstiegen wechselt). > > Da könnte ich mir grundsätzlich das selbe vorstellen, finde aber auch > passend das dann als zwei Wege zu mappen. - Es ist ja dann eh meist > verboten die "Mittellinie" zu überqueren. Aber ja, richtig begeistert bin > ich nicht, weil es ja nicht unbedingt baulich getrennt ist. Keine zwei Wege -- da nicht baulich getrennt, wuerde eine solche Strasse kaum jemand so abbilden. Ausserdem bringen parallele Ways immer weitere Probleme mit sich: Jede moegliche querende Verbindung benoetigt einen kurzen (Pseudo-)Way, der in Realitaet nicht da ist, sondern nur benoetigt wird, da ich ein zweidimensionales Gebilde (Strassenflaeche) auf ein eindimensionales Gebilde (Kantenzug) abbilde. Und diese kuenstlich eingefuehrten Wege machen beim Taggen (welcher highway-Tag, welcher Strassenname etc.?), beim Routen und den daraus erzeugten Abbiegehinweisen wieder Probleme (statt einmal links abbiegen, kommt ein "links abbiegen" und ein darauf folgendes "geradeaus" o.ae.). Ich tagge diese Pseudo-Ways, die gerade in etwas groesseren Kreuzungen gehaeuft vorkommen, gerne mit "plural_junction=yes", angelehnt an den GDF-Standard. Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Unterschiedliche Geschwindigkeitsbeschraenkungen fuer jede Fahrtrichtung
Hallo zusammen, beim Abfahren bzw. -laufen meiner Strecken nehme ich neben den ueblichen Highway-Tags auch gleich noch ein paar weitere auf, u.a. Bruecken, Tunnel, Haltestellen, Ortseingangsschilder und dazu auch gleich alle weiteren Geschwindigkeitsbeschraenkungen. * Geschwindigkeitsbeschraenkungen Beim Befahren derselben Strasse _in beide Richtungen_ faellt einem dann haeufiger auf, dass es Teilwege mit verschiedenen "maxspeed="- Eintraegen pro Fahrtrichtung gibt. Wie sollte dies getaggt werden? (Von den Zusatzschildern wie Lkw, Regen, Uhrzeiten etc. will ich mal ganz absehen.) Da ich im OSM-Wiki keinen passenden Vorschlag hierzu gefunden habe, behelfe ich mir momentan damit, dass ich in solchen Faellen den kleineren der beiden Werte mit dem Tag "maxspeed=" beim Way eintrage. 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. * Fahrspuren Dasselbe Problem taucht bei "lanes=" auf, wo es fuer die beiden Fahrtrichtungen unterschiedlich viele Fahrspuren gibt (haeufig bei dreispurigen Bundesstrassen, in einer Richtung mit zwei Spuren, in Gegenrichtung mit einer Spur, wobei diese Aufteilung alle paar Kilometer oder bei Anstiegen wechselt). * Richtungsbezogene Way-Tags Als richtungsbezogene Way-Tags habe ich im Wiki nur das Einbahnstrassen-Tag "oneway=1/yes/true/-1" gefunden. Gibt es noch weitere Tags oder Tag-Vorschlaege, so dass man hier vereinheitlichen koennte? Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
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] Kindergarten
On Wednesday, 19 December 2007 13:33:51 +0100, Lorenz Kiefner <[EMAIL PROTECTED]> writes: > Hallo! > Wie habt Ihr bisher Kindergärten getaggt? Oder lässt man das besser? ich habe die momentan als "amenity=school" drin und nur im Namen sieht man, ob es eine Schule oder ein Kindergarten/-haus/-hort ist. Wie von anderen vorgeschlagen, waere ein separater Wert oder ein Sub-Tag erforderlich/hilfreich. Gruss, -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] 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] 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] 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
[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 "Abbiege"vorgaenge
> > 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] 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
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 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 "Abbiege"vorgaenge
> > 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] 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.005458493238876&lon=8.394616854468799&zoom=17&layers=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 "Abbiege"vorgaenge
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] 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] Parkhaus
On Thursday, 29 November 2007 02:36:20 +0100, Dimitri Junker <[EMAIL PROTECTED]> writes: > Mir sind gerade einige Parkhäuser aufgefallen bei denen der Name zweimal > angezeigt wird. Da hat jemand sowohl den Umriß als auch einen Node mit > amenity=parking und name=... gesetzt. Der Grund ist wohl, daß bei der area > diese zwar farblich abgesetzt wird, aber kein P-Schild gezeichnet wird. Was > sollte also geschehen? > - die Renderer sollten auch in eine Park-area ein P zeichnen > - Wenn man beides haben will setzt man aber den Namen nur einmal. Wo? Wenn man neben einer Parking-Area den Parking-Node als Hinweis an den Renderer versteht, wo die Bezeichnung hin soll, und als Hinweis auf eine Search-Engine, wo (= Koordinate) ungefaehr das Parkhaus ist, muesste man zwischen Area und Node eine entsprechende Relation definieren, die eben dies ausdrueckt. Ich habe hier den Konjunktiv verwendet, da man IMO eher auf den zusaetzlichen Punkt verzichten sollte und die Renderer+Search-Engines eine Area entsprechend mit "P" kennzeichnen sollten, oder? > Wie müssen Parkhäuser u.a. mit der Straße verbunden werden? Wird es den > Routern reichen, wenn sie einfach neben der Straße stehen oder müssen sie > mit dieser verbuden werden? Reicht eine Verbindung zwischen der Straße und > dem Rand? Als "Router" haette ich alle Ein- und Ausfahrten und alle Ein-/Ausgaenge zum Parkplatz eingetragen, denn nur dann kann ich wirklich bis in's Parkhaus routen und anschliessend den Fussweg von dort zum endgueltigen Ziel. Hintergrund: Bei grossen "P" sind Ein- und Ausfahrten getrennt, wobei die offizielle Adresse (Strasse+Hausnummer) des Parkhauses um die Ecke liegt. Wenn dann noch Einbahnstrassen, getrennt Richtungsfahrbahnen etc. dazukommen, benoetigt der Router so oder so die korrekten Zugangspunkte. Fussweg-Ein-/Ausgaenge liegen nochmals woanders und ich habe schon erlebt, dass einige davon Nur-Ausgaenge sind, durch die man nicht mehr hinein kann (weil der Betreiber Kassenautomaten sparen wollte). Andere Frage an die Router-Ersteller: Reicht es, wenn man diese Zugaenge mit der Parking-Area verbindet, damit dorthin/von dort geroutet werden kann? Gruss, -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
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
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
[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] 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] 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
[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 mit einer Gruppe eine moegliche Darstellung als 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
[Talk-de] Brunnen ... welche Tags werden verwendet?
Hallo zusammen, da es in meiner Gegend einige oeffentliche Brunnen gibt, die teilweise Trink- und sogar Mineralwasser (u.a. in Bad Cannstatt) fuehren, wuerde ich diese gerne eintragen. Bislang habe ich "waterway=water_point" und das Proposed-Feature "amenity=potable_water" (bzw. "amenity=drinkable_water") im Wiki gefunden, das IMO aber fuer einen Brunnen, der nicht nur Wasserentnahmestelle fuer Wohnmobile etc. sondern ein sehr markanter Punkt ist, nicht so richtig passt. Uebersehe ich einen Tag? 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] 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] 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] 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] 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
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] 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] 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] 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] Genauigkeit der Tracks
On Sunday, 11 November 2007 14:31:43 +0100, Holger Issle <[EMAIL PROTECTED]> writes: > On Sat, 10 Nov 2007 14:36:40 +0100, Dimitri Junker wrote: > > Vor allem wenn ich auf eine Diskrepanz zwischen meinen neuen Daten und > > alten > > bereits in OSM gemappten stoße finde ich den Vergleich mit einer 'fertigen' > > Karte/Satbild sinnvoll um zu entscheiden welcher Messung ich mehr traue. > > Das kann man so tun, ja... nur sind Karten und Satbilder nicht immer > richtig sondern entweder leicht falsch kalibriert oder die Wege alt > oder kreativ verlegt um ein besseres optisches Bild zu haben. > Neuaufnahme ist da sicher der sinnvollst Weg... Es gibt ja einen absoluten und einen relativen Fehler ... und man sollte beiden beachten. Den absoluten Fehler des GPS-Empfaengers kann man dadurch verbessern, dass man ihn, wie schon geschrieben, nach dem Einschalten erst einmal eine Weile auf freier Flaeche die momentane Position finden laesst, dabei sollten niedrige *DOP-Werte gemeldet werden (auch wenn die nur sagen, dass der Empfaenger meint, dass er eine gute Sat-Konstellation hat, d.h. die Wahrscheinlichkeit fuer einen Fehler gering sind, aber es gibt eben die wenigen Faelle, wo man voll daneben liegt). Den relativen Fehler kann man nur selbst manuell verbessern, indem man Ausreisser und unsinnige GPS-Punktfolgen zu einer plausiblen Karte konvertiert. Das geht nur mit eigenem Wissen. Wenn ich weiss, dass ein Weg eine leichte Biegung nach links macht und dann rechtwinklig auf eine Strasse trifft, der GPS-Plot das aber nicht so zeigt, dann lege ich die Wege dennoch so, dass die relative Lage korrekt ist ... genau dieser Schritt geht eben nicht automatisch (durch Mittelung o.ae.), wie manche das gerne wuenschen. Besonders in engen Altstadtgaesschen mit Streuungen und Abschattungen meint ein SirfIII-GPS-Empfaenger noch, dass das Signal "super" sei, versetzt einen aber manchesmal um 5-20m zur Seite. Durch das eigene Wissen um die relative Lage der Wege (Kreuzungspunkte, ungefaehre Abstaende) kann man den Versatz und ein Hin- und Herspringen in den GPS-Plots ganz gut manuell korrigieren ... Ciao, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
