from:"Eckhart Wörner"

Hallo Tirkon,

Am Sonntag, 7. Juli 2013, 12:06:06 schrieb Tirkon:
 Für diese Erfassung benötigen wir einen neuen Tag. Dieser Tag
 soll globale_id_pt = * (IFOPT Nummer) heißen.
 
 Nummern, deren Bedeutung unter Verschluss ist, hätten
 in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank
 keine Berechtigung mehr hätte.

Aua!

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Dirk,

Am Sonntag, 7. Juli 2013, 10:10:26 schrieb Dirk Sohler:
  Die Modellierung soll Routing und Navigation innerhalb des Bahnhofs
  bis zum Fahrzeug erlauben und dabei speziell auch wo möglich die
  Berechnung barrierefreier Routen ermöglichen.
 
 Ist das ein Projekt, aus dem die Community ganz im Sinne von Open Data
 einen Nutzen ziehen kann, oder ist das eine interne Geschichte, auf die
 ein Normalbürger nicht ohne weiteres Zugriff bekommen kann?

Vielleicht beschäftigst du dich erst einmal mit der Materie? Die IBNR, die 
Bahnhöfe kennzeichnet, wird von den entsprechenden Leuten durchaus gewünscht, 
leider gibt es aber keine frei verfügbaren Listen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Wolfgang,

Am Sonntag, 7. Juli 2013, 15:33:07 schrieb Wolfgang Hinsch:
   Nummern, deren Bedeutung unter Verschluss ist, hätten
   in OSM nichts zu suchen, weil dann der Titel !!!Freie!!! Datenbank
   keine Berechtigung mehr hätte.
  
  Aua!
 
 Warum Aua?

Weil die Aussage auf so vielen Ebenen falsch ist, dass es einfach nur weh tut.

Erstens ist OSM keine freie Datenbank, sondern eine freie *Geo*datenbank, d.h. 
es gibt zwangsläufig Daten, die außerhalb von OSM liegen müssen (auch wenn es 
genug Leute gibt, die das nicht einsehen). Dazu braucht es aber Möglichkeiten, 
Daten innerhalb von OSM zu adressieren.

Zweitens ist es nicht das Ziel von OSM, die Verknüpfung mit Daten in 
geschlossenen Fremdsystemen zu verbieten, im Gegenteil: die ODbL ist extra so 
geschrieben, um solche Nutzungen zu ermöglichen.

Drittens gibt es jede Menge Nummern in OSM, die genau die gleichen Kriterien 
erfüllen, und an denen sich auch keiner stößt: TMC-Codes, IBNR-Nummern, 
ICAO-Codes, …

Und viertens ist die Bedeutung der Nummer (die eindeutige Identifikation von 
Haltestellen) gar nicht unter Verschluss, die Bedeutung soll ja gerade in OSM 
eingepflegt werden.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Peter,

Am Sonntag, 7. Juli 2013, 16:34:08 schrieb Peter Wendorff:
 Aber: Wenn der Fremdschlüssel als Information selbst nicht frei ist -
 und das ist die Annahme von Wolfgang, die er hier zurecht äußert, dann
 darf sie - unabhängig davon, welchen Umfang OSM hat oder haben sollte -
 nicht in OSM eingefügt werden.

Da liest du dann was anderes in die Aussagen als ich: Wolfgang hat sich 
lediglich Tirkon angeschlossen, und Tirkons Argument war m.E. eindeutig 
ideologisch motiviert und hat sich nicht an Lizenzfragen orientiert.

Abgesehen davon kann ich mir nicht vorstellen, dass Mentz Daten ihrer Kunden in 
OSM einpflegt, ohne die Kunden vorher um Erlaubnis zu fragen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Rainer,

Am Sonntag, 7. Juli 2013, 17:15:28 schrieb RainerU:
  Abgesehen davon kann ich mir nicht vorstellen, dass Mentz Daten ihrer 
  Kunden in OSM einpflegt, ohne die Kunden vorher um Erlaubnis zu fragen.
 
 Kann ich mir auch nicht vorstellen. Die Frage ist, ob sich diese Kunden über 
 die
 Tragweite ihrer Zustimmung im Klaren sind. Wenn ebendiese Kunden ihre Daten
 bisher nicht unter mit den Contributor Terms kompatiblen Bedingungen bereit
 gestellt haben, dann ist es legitim daran zu zweifeln, ob ihnen klar ist, dass
 sie das jetzt auf dem Umweg über die Firma Mentz tun.

Viele Anfragen von OSMlern an Verkehrsbetriebe, die ich gesehen habe, sehen so 
aus, dass einfach nur nach möglichst vielen Daten gefragt wird, und den 
Verkehrsbetrieben die Lizenz so um die Ohren gehauen wird, dass ich volles 
Verständnis dafür habe, wenn die Verkehrsbetriebe da einfach nein sagen.

Im aktuellen Fall ist die Situation anders: Mentz möchte das Ganze wohl 
organisieren, und die Verkehrsbetriebe haben dann auch einen greifbaren Nutzen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Tirkon,

Am Sonntag, 7. Juli 2013, 17:36:18 schrieb Tirkon:
 Nein! Ich zitiere:

Dann zitiere ich auch nochmal:
 Nummern, deren Bedeutung unter Verschluss ist, hätten
 in OSM nichts zu suchen

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Einführung eines neuen Tags (globaleID)

Hallo Tirkon,

Am Sonntag, 7. Juli 2013, 17:36:18 schrieb Tirkon:
 Nein! Ich zitiere:
 
 Bitte nur einfügen, was mit unserer Lizenz kompatibel und frei
 verfügbar ist.

Nachtrag: wenn dein Beitrag anders gemeint war als von mir interpretiert, 
entschuldige ich mich natürlich.

Trotzdem bin ich der Meinung, dass solche Antworten einfach nur kontraproduktiv 
sind: wenn die erste Reaktion auf wir würden gerne was mit OSM machen nur DIE 
LIZENZ ist, dann läuft einiges schief. Die ODbL ist eigentlich genau aus dem 
Grund entstanden, dass man nicht jeden Satz mit …unter besonderer 
Berücksichtigung DER LIZENZ abschließen muss.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Spurassistent / lanes / turn

2013-07-05 Diskussionsfäden Eckhart Wörner

Hallo Florian,

Am Freitag, 5. Juli 2013, 16:22:32 schrieb Florian Lohoff:
 ich habe diese woche mit begeisterung gesehen das Mapfactor Navigator
 die turn/lanes werte auswertet und einen Spurassistenten anzeigt.
 
 Ich habe daraufhin mal diverse Kreuzungen nachbearbeitet - mal sehen
 wie der sich so macht.
 
 Eine Frage die mir gekommen ist: Was ist mit
 beschleunigungs/verzoegerungsstreifen auf der Autobahn. Lanes = n+1 
 und dann turn=through|through|slight_right ?
 
 Oder wie gehabt einfach abzweigen lassen.
 
 Ich habe da fuer mich mal ein Best common practice fuer das
 Autobahnzeugs gemacht - d.h. motorway_link am begin des
 Verzögerungsstreifens beginnend parallel fuehren etc.
 Mit dem lanes/turn ist das dann allerdings hinfaellig denke ich.

Es ist eigentlich mehrheitlich Konsens, dass Verzögerungs- und 
Beschleunigungsstreifen *nicht* als eigene Wege erfasst werden sollen.

http://wiki.openstreetmap.org/wiki/Autobahn#Allgemeine_Hinweise_f.C3.BCr_Autobahnen

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht

2013-06-15 Diskussionsfäden Eckhart Wörner

Hallo Martin,

Am Freitag, 14. Juni 2013, 02:07:38 schrieb Martin Koppenhoefer:
 m.E. braucht man 2 unterschiedliche tags, einen für tatsächliches Gewicht
 (maxweight und weight) und einen für zulässiges Gesamtgewicht (fehlt AFAIK
 noch).

ist auch schon mehrfach vorgeschlagen worden, auch hier auf der Mailingliste 
(und auf -tagging). Steht auch z.B. hier im Wiki: 
http://wiki.openstreetmap.org/wiki/Talk:Conditional_restrictions#Addition:_Gross_vehicle_weight_rating
Das einzige, was es braucht, ist, dass man die Diskussionen mal zu Ende führt 
und nicht x-mal neu anfängt.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht

2013-06-15 Diskussionsfäden Eckhart Wörner

Hallo Ruben,

Am Samstag, 15. Juni 2013, 16:47:28 schrieb Ruben Kelevra:
 Das heißt ein Mapper würde oben DE auswählen, dann auf den
 Verbotsschildtyp, würde den LKW auswählen und dann ein Zusatzschild
 mit 7,5 Tonnen. Davon ableiten würden wir dann, das die Straße in DE
 ist und das Deutsche Recht gilt, was bedeutet hgv:no wenn über 7,5
 Tonnen.

Das funktioniert vielleicht bei ein paar Standardschildern, aber schon bei den 
Zusatzschildern wird es schwierig, weil es da variable Texte gibt. Es ist 
wahrscheinlich deutlich sinnvoller, eine gute Doku (mit guten Beispielen) zu 
schreiben, und Neulinge nicht ständig davon abzuhalten, da auch mal 
reinzuschauen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Taggingproblem: Sperrung für Fahrzeuge über 7,5 tonnen zul. Gesamtgewicht

2013-06-13 Diskussionsfäden Eckhart Wörner

Hi Burkhard,

Am Donnerstag, 13. Juni 2013, 19:18:02 schrieb bkmap:
  sorry, das hgv passt vermutlich schon, wenn es auch im Wiki nicht weiter 
  beschrieben wird, Problem ist das weight. Habe dazu zwar im Wiki nichts 
  explizit gefunden, würde aber davon ausgehen, dass das wie height 
  funktioniert, also das tatsächliche Gewicht beschreibt.
 
 
 Dann sollte ja hgv:conditional=no @ (weight7.5) passen.

nein, das passt nicht. Zwischen dem zulässigen Gesamtgewicht und dem 
tatsächlichen Gewicht ist ein großer Unterschied.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] gesperrte Anschlussstelle Halle-Peißen

2013-05-26 Diskussionsfäden Eckhart Wörner

Hallo Chris,

Am Sonntag, 26. Mai 2013, 22:32:38 schrieb chris66:
  Solche kurzzeitigen Sperrungen sind eher was für Verkehrsdienste wie
  TMC und dem demnächst verfügbaren TPEG [1]. 
 
 Oder für die eleganten temporary: Tags, die sich aber leider
 nie durchgesetzt haben.
 
 http://wiki.openstreetmap.org/wiki/Proposed_features/temporary

…oder für Conditional Restrictions (die sich zumindest bei den Mappern 
durchgesetzt haben):
http://wiki.openstreetmap.org/wiki/Conditional_restrictions

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

Hallo Wilhelm,

Am Freitag, 10. Mai 2013, 07:08:32 schrieb Wilhelm Spickermann:
 Ein drittes Splittingproblem gibt es bei den Kreisverkehren. Wenn ein
 Kreisverkehr Element einer Route ist, dann ist damit nur benötigte Teil
 des Kreisverkehrs gemeint. Splittet man ihn auf, dann gilt diese
 Sonderregel nicht mehr und man muss nicht zugehörige Teile wegwerfen und
 die anderen Teile sinnvoll umsortieren. Noch schlimmer: man muss alle
 anderen betroffenen Relation ebenso laden, den Kreisverkehr ggf. weiter
 splitten und bei allen nachkorrigieren. Das unterstützt keiner der
 Editoren. (Ich halte es meist für Quatsch Kreisverkehre zu splitten,
 aber es gibt andere Ansichten/Situationen und wenn man da splittet,
 dann gibt es dieses Problem.)

mit anderen Worten: der einzige Grund, weswegen Kreisverkehre ein Problem sind, 
ist *genau* diese Sonderregel.
Wenn an Kreisverkehren von Anfang an für Routen richtig gesplittet wird, sind 
auch nachträgliche Splits kein Problem mehr.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

Hallo Wilhelm,

Am Samstag, 11. Mai 2013, 17:03:16 schrieb Wilhelm Spickermann:
  Wenn an Kreisverkehren von Anfang an für Routen richtig gesplittet
  wird, sind auch nachträgliche Splits kein Problem mehr.
 
 Ich glaube nicht, dass nur gesplittete Kreisverkehre richtig sind. Es
 ist etablierte Praxis, Kreisverkehre komplett anzugeben obwohl sie
 nicht komplett umlaufen werden und schon garnicht komplett vom Anfangs-
 zum Endpunkt.

Deine etablierte Praxis hat es noch nicht einmal ins Wiki geschafft? (Ich 
bestreite nicht, dass ein Mapper das so handhaben, aber sicher nicht die 
Mehrheit.)

 Wenn man das jetzt noch ändern wollte, dann müsste man
 eine große Abstimmung machen und dann einen Bot über die Welt laufen
 lassen wie beim Lizenzwechsel.

S.o.

Die Gründe, weswegen Kreisverkehre von vielen nicht gesplittet werden:
a) JOSM hat dann früher Kreisverkehre als Flächen behandelt und ausgefüllt 
gezeichnet
b) JOSM zeigt dann ein Kreisverkehr-Icon in Relationen an
c) JOSM kann immer noch nicht mehrere Ways im Kreis anordnen

Interessanterweise beginnen alle diese Punkte mit JOSM… (wahrscheinlich gibt 
es auch ein paar Punkte, die mit Potlatch… oder iD… beginnen). Es gibt 
keinen stichhaltigen Grund, warum Kreisverkehre so besonders sind.

 Ich hatte nur einen einzigen Fall, in dem ich einen Kreisverkehr
 splitten musste. Da war in Frankreich eine Bushaltestelle so in den
 Kreisverkehr gelegt, dass der Bus eine zusätzliche Runde drehen musste.

Oh, es gibt genügend Gründe, warum Kreisverkehre gesplittet werden müssen: Turn 
Restrictions, Spuren, …

 Außerdem: wenn alle Kreisverkehre bereits gesplittet wären, dann wäre
 das Splitten dort immer noch ein Problem, nämlich das in Punkt zwei
 erwähnte. Nicht einmal JOSM macht das immer richtig. Es entfallen dann
 nur die zusätzlichen Splits -- die hat man dann schon vorher gemacht.

Das in Punkt zwei erwähnte Problem hat erstmal gar nichts mit Kreisverkehren zu 
tun, sondern tritt überall auf. Ist aber auch ein lösbares Problem (Um den Weg 
korrekt zu splitten, müssen weitere Wege heruntergeladen werden. Jetzt 
herunterladen? o.ä.).

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

Hallo Wilhelm,

Am Samstag, 11. Mai 2013, 18:46:24 schrieb Wilhelm Spickermann:
  Interessanterweise beginnen alle diese Punkte mit
  JOSM… (wahrscheinlich gibt es auch ein paar Punkte, die mit
  Potlatch… oder iD… beginnen).
 
 Also an einem Editor-War möchte ich mich nicht beteiligen.

Ich mich auch nicht, ich wollte nur erklären, dass die Liste nicht vollständig 
war, sondern eher mein Nutzungsverhalten widerspiegelt.

  Es gibt keinen stichhaltigen Grund,
  warum Kreisverkehre so besonders sind.
 
 Doch sicher. Bei Relationen, bei denen sich die Gebrauchsrichtung aus
 der Abfolge der Member ergibt, ist der benutzte Teil des Kreisverkehrs
 auch ohne Splitting eindeutig identifizierbar. Das ist eine
 Besonderheit.

Das Argument lässt sich genauso auf eine Route A - B - C anwenden, bei der 
nur eine Teilstrecke von B verwendet wird. Auch wenn ich weiß, welches 
Teilstück von B verwendet wird, sollte ich B trotzdem passend auftrennen. Genau 
die gleiche Situation.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] ID Editor zerstört mit einem Klick tagelange Arbeit.

Hallo Ruben,

Am Samstag, 11. Mai 2013, 18:26:38 schrieb Ruben Kelevra:
 Am Sat, May 11, 2013 at 5:42 PM schrieb Eckhart Wörner ewoer...@kde.org:
  c) JOSM kann immer noch nicht mehrere Ways im Kreis anordnen
 Nicht ganz richtig, man muss blos manuell alle Nodes markieren, dann gehts.

sorry, ich wollte sagen: JOSM kann immer noch nicht *direkt* mehrere Ways im 
Kreis anordnen.
(Alternative: Wege markieren, dann nach child (selected) suchen, und dann die 
Knoten anordnen.)

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tags für die grüne Welle

2013-02-12 Diskussionsfäden Eckhart Wörner

Hallo Martin,

Am Montag, 11. Februar 2013, 10:28:07 schrieb Martin Schafran:
 ich bin ständig dabei, die Daten von offiziellen Stellen zu bekommen. Ein 
 schreibender Zugriff auf mein System ist sowieso möglich und gewünscht.
 Das Problem stellt die dunkle Seite der Macht dar.

könntest du dann evtl. einen Beispielauszug einer offiziellen Stelle zur 
Verfügung stellen, damit man sich ein Bild machen kann, was da so enthalten ist?

 Die Absoluten Zeiten bekommt man aus dem Fahrverhalten der Fahrzeuge oder vom 
 Mastersystem. Wenn du eine hast, kannst du die Restlichen mit Zwischenzeiten 
 sychronisieren. Die Sync-Strategie ist ne andere Frage und hängt von paar 
 Faktoren ab.

absolute Zeiten lassen sich aus den relativen Zeiten dann aber nur mit 
Verzögerung und mit Ungenauigkeit bestimmen, beides reduziert die Nützlichkeit 
der Daten.
(Vielleicht habe ich den letzten Absatz aber auch einfach nur falsch 
verstanden.)

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tags für die grüne Welle

2013-02-11 Diskussionsfäden Eckhart Wörner

Hallo Martin,

ein paar technische Kommentare.

Am Samstag, 9. Februar 2013, 21:22:47 schrieb Martin Schafran:
 Für eine Fahrbeziehung (relation mit members from, via, to), die am Montag 
 zw. 
 6 und 20 Uhr 35 sek. grün und 50 sek. rot ist.

rot ist als nicht grün definiert, enthält insbesondere auch gelb?

 glosa:timing:conditional=35,50 @ MONDAY @ (06:00-20:00 UTC)

*seufz* Nachdem wir so erbittert um ein geeignetes Tagging-Schema gekämpft 
haben, müssen wir es nicht gleich wieder verwässern. Also:
glosa:timing:conditional=35,50 @ (Mo 06:00-20:00)
Wieso du UTC-Zeiten verwenden willst, ist mir auch schleierhaft. UTC ist fast 
schon ein Garant dafür, dass das Tagging daneben geht.
(Abgesehen davon werden Ampeln zumindest in meiner Gegend nicht in UTC-Zeiten 
gesteuert und schalten Sommer wie Winter um 22:00 ab.)

 glosa:timing:conditional=15,20,25,25 @ MONDAY @ (06:00-20:00 UTC)

Analog oben:
glosa:timing:conditional=15,20,25,25 @ (Mo 06:00-20:00)

 Die Ampeln bzw. Fahrbeziehungen müssen untereinander synchronisiert werden, 
 dazu dient eine Zwischenzeitenmatrix (inter_green_matrix).
 Die ist hier etwas anders definiert als in der Verkehrstechnik und zwar so:
 Fahrbeziehung 1 schaltet um 0 auf Grün, Fahrbeziehung 2 schaltet auf Grün um 
 23.

Für mich ist eine Zwischenzeitenmatrix etwas ganz anderes, vielleicht sollte 
man hier einen anderen Begriff verwenden?

 Die Zwischenzeit ist also 23. Voraussetzung ist gleiche Umlaufzeit.
 Das ist eine Relation mit zwei Fahrbeziehungen (Relationen) als members. Die 
 erste ist die Referenzrelation und die zweite ist
 die referenzierte Relation.
 
 glosa:inter_green:conditional=23 @ MONDAY @ (06:00-20:00 UTC)

Analog oben:
glosa:inter_green:conditional=23 @ (Mo 06:00-20:00)

Meiner Meinung nach ist die Anzahl der Relationen auch unnötig hoch. Für eine 
Straße mit 10 Ampeln hintereinander, die synchronisiert sind, brauchst du 19 
Relationen. (Pro Ampel mindestens eine, und 9 Stück für die Abhängigkeiten.)
Alternative aus meiner Sicht wäre, alle 10 Ampeln in *eine* Relation zu stecken:

Rolle | Member
--+
0 | Ampelrelation 1
23| Ampelrelation 2
48| Ampelrelation 3
48| Ampelrelation 4
...

 Um über verkehrsabhängige Ampeln bescheid zu wissen werden Ampelknoten mit 
 tags versehen
 
 glosa:control_procedure=phase_adaptation,green_extension
 oder
 glosa:control_procedure=adaptive

Wieso sollen hier plötzlich die *Knoten* getaggt werden? Sinnvoller sind die 
Tags doch an den entsprechenden Relationen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Tags für die grüne Welle

2013-02-11 Diskussionsfäden Eckhart Wörner

Hallo Martin,

ein paar grundsätzliche Kommentare.

Wie im Forum auch schon erwähnt, glaube ich, dass du den Aufwand unterschätzt, 
um systematisch Ampeln zu erfassen. Das Problem in OSM ist nicht, dass wir zu 
wenige Daten haben, sondern, dass wir viel zu viele Daten haben, die falsch 
sind (und wir damit zu einer riesigen Datenmüllhalde werden). Auf der anderen 
Seite gibt es für Ampelschaltungen natürlich durchaus sinnvolle Anwendungsfälle 
in der Navigation.
Das Ziel sollte daher in erster Linie *nicht* die manuelle Erfassung von 
Ampelumläufen sein, sondern die Verwendung von externen Datenquellen, wie z.B. 
den Export aus einer Steuerungssoftware. Das führt dann dazu, dass in OSM 
weniger die eigentlichen Umläufe erfasst werden sollten, sondern vielmehr die 
entsprechenden Identifier aus den externen Quellen, um eine sinnvolle 
Verknüpfung der Daten zu ermöglichen.

Abgesehen davon weiß ich nicht, ob die Informationen, die du erfassen willst, 
bereits ausreichen, um wirklich sinnvolle Anwendungen zu ermöglichen. Ich 
möchte das an einem Beispiel demonstrieren:

Du möchtest folgende Informationen erfassen: auf einer Straße (mit 
Höchstgeschwindigkeit 60 km/h) befinden sich im Abstand von 300m Ampel A1 und 
A2. Die Ampeln besitzen beide eine Umlaufzeit von 60 Sekunden und sind 20 
Sekunden davon grün. A2 schaltet 18 Sekunden nach A1 auf grün.
⟹ Wenn wir die erste Ampel bei grün passieren, wissen wir, dass wir für eine 
grüne Welle konstant 60 km/h (alternativ knapp 14 km/h) fahren müssen. Mehr 
wissen wir nicht.

Tatsächlich schaltet die Ampel A1 aber um exakt 12:00:00 auf grün. Mit unserem 
Auto fahren wir um 12:00:03 an der Ampel A1 vorbei.
⟹ Wir wissen nun, dass wir für eine grüne Welle zwischen A1 und A2 eine 
Geschwindigkeit zwischen 31 km/h und 72 km/h (realistisch zwischen 31 km/h und 
60 km/h wegen gegebener Höchstgeschwindigkeit) fahren können.
Wir wissen aber z.B. auch, mit welcher Geschwindigkeit wir auf A1 oder A2 
zufahren müssen, ohne überhaupt vorher eine Ampel passiert zu haben.

Die absoluten Schaltzeiten bieten also einen wesentlich höheren 
Informationswert als die relativen Schaltzeiten.
Voraussetzung dafür ist, dass a) wir im Auto die exakte Zeit kennen und b) die 
Ampeln exakt schalten.
a) ist trivialerweise erfüllt, weil wir für die Navigation sowieso einen 
GPS-Empfänger benötigen, dessen Genauigkeit im µs-Bereich liegt
b) ist bei vielen Ampeln ebenfalls erfüllt, weil Ampelanlagen z.B. über DCF77 
synchronisiert werden

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Demo mehrsprachige Karte

2012-12-01 Diskussionsfäden Eckhart Wörner

Hallo Andreas,

Am Samstag, 1. Dezember 2012, 08:28:13 schrieb Andreas Labres:
 Sorry, aber ich find's widersinnig, name:en=Aachen oder name:fr=Munich (das 
 ist
 doch die engl. Sprache?) einzutragen.

http://dict.leo.org/frde?lp=frdesearch=m%C3%BCnchen

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?

2012-11-28 Diskussionsfäden Eckhart Wörner

Hallo Wolfgang,

Am Mittwoch, 28. November 2012, 10:23:57 schrieb Wolfgang Hinsch:
 Ich meine aber generell, dass man vielleicht etwas mehr an die Praxis
 als an die Theorie denken sollte. Die Position, von der aus du den
 Router neu rechnen lassen willst, wird - zumindest nach heutigem Stand -
 kaum einen Router dazu veranlassen, nach einem neuen Weg zu suchen, weil
 er noch gar nicht merkt, dass du nicht rechts abbiegst. Und wenn er das
 dann merkt und eine neue Route rechnet, bist du am Linksabbieger längst
 vorbei.

Die Praxis zeigt aber, dass Routenneuberechnungen auch durch Eingaben des 
Anwenders ausgelöst werden können., nicht nur durch Falschfahren.

 Außerdem sollte ein Router, wenn er denn so gut wäre und das merken
 würde, dich nicht vom Rechtsabbieger auf Krampf in den Linksabbieger
 schicken. Das ist ein Fall für eine bessere - und sicherere
 Routing-Software und nicht für Mapping für kaputte Routersoftware. Der
 Router muss einen Weg finden, dich über ein paar Seitenstraßen zu
 wenden. Meistens kann man auch keine Wendung oder so im Menü
 einstellen.

Das ist Unfug. Wenn eine Route fälschlicherweise, aber laut Kartenmaterial 
legal ist, dann ist nicht der Router kaputt, sondern das Kartenmaterial.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?

2012-11-28 Diskussionsfäden Eckhart Wörner

Hallo Martin,

Am Mittwoch, 28. November 2012, 09:00:13 schrieb Martin Vonwald:
 * Sehr einfach - man mappt normal und lässt nur ein paar Kreuzungspunkte aus

Sorry, aber was normal ist, darüber gehen unsere Meinungen wohl auseinander.

 * Aktuelle Router verstehen sie - keine Anpassungen notwendig

Ähm, nein. Das merkt man sofort an den Routinganweisungen.

 * Erhebliche Reduktion von Restriction-Relationen - Vereinfachung für
 Mapper und deutlich weniger fehleranfällig

Die Fehleranfälligkeit von Abbiegebeschränkungen ist hauptsächlich der Art der 
Implementierung in JOSM  Co. geschuldet.

 * Router und Renderer haben eine Chance den tatsächlichen Verlauf der
 Fahrbahnen innerhalb des Kreuzungsbereichs darzustellen, daher z.B.
 auch keine fehlerhaften Ansagen im Kreuzungsbereich

Ähm, wie bitte? Fehlerhafte Ansagen resultieren zu 99% aus Spurmapping – und 
ja, das was du vorschlägst, *ist* Spurmapping.

 Nachteil der Lösung:
 * Der Mapper muss aktuell Fehlermeldungen des Editors und div. Tools
 (OSMI, keepright) ignorieren, bis diese aktualisiert wurden und das
 Tag verstehen.

Du meinst wohl eher, bis diese Tools nutzlos werden? Auf einer solchen Kreuzung 
sind *keine* Überprüfungen mehr möglich.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?

2012-11-27 Diskussionsfäden Eckhart Wörner

Hallo Bernhard,

Am Dienstag, 27. November 2012, 21:46:51 schrieb Bernhard Weiskopf:
 Wie verhindert man nun, dass man im kleinen mittleren Quadrat drei Mal nach
 links geschickt wird, um dann doch rechts abbiegen zu können, wenn man die
 Rechtsabbiegefarbahn verpasst hat? (Linksabbiegen in der Mitte ist ja an
 allen vier Knotenpunkten erlaubt)
 http://map.project-osrm.org/?hl=deloc=49.5569,8.6483loc=49.5564,8.6487z=18
 
 Wie trägt man hier Wendeverbote ein? Soweit ich mich erinnere, darf man an
 dieser Kreuzung nicht wenden, wenn man von Norden, Westen oder Süden kommt.
 Nur von Osten kommend ist Wenden nicht verboten. (Muss ich aber nochmal
 genau vor Ort prüfen).

ich hab mal nach deiner Beschreibung entsprechende Abbiegebeschränkungen 
eingetragen.

 Über zusätzliche Kreuzfahrbahnen in der Mitte wären die Abbiege- und
 Wende-Verbote über Relationen möglich, das wäre aber Spurmapping. Oder
 muss man das hier doch machen?

Nein, muss man nicht.
Abbiegebeschränkungen können als via *statt* dem Zwischenknoten auch ein oder 
mehrere Wege enthalten. Damit lassen sich auch komplizierte Verbote erfassen.

Was man hierbei wissen sollte:
- das JOSM-Plugin unterstützt selbst keine via-Wege
- OSRM unterstützt keine via-Wege in Abbiegebeschränkungen (ist aber geplant), 
Navit unterstützt nur einen einzigen via-Weg, die einzige mir bekannte 
vollständige Implementierung hat MapQuest.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Wie Abbiegebeschraenkungen eintragen ohne Spurmapping?

2012-11-27 Diskussionsfäden Eckhart Wörner

Hallo Martin,

Am Dienstag, 27. November 2012, 23:45:42 schrieb Martin Koppenhoefer:
 Man könnte im Kreuzungsbereich die parallelen Spuren zusammenfassen,
 so dass sich 8 Straßen da in einem Punkt treffen.

…genau, und das halb-rechts abbiegen statt geradeaus gibt es dann gratis 
dazu. *sigh*

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Broken Turn Relations

2012-11-25 Diskussionsfäden Eckhart Wörner

Hallo Rainer,

Am Sonntag, 25. November 2012, 18:25:58 schrieb Rainer Dorsch:
 hier ist ein Update von Broken Turn Relations, wie sie von Navits maptool 
 berichtet werden:
 
 http://bokomoko.de/~rd/broken_turn_relations_121125.log

OSM Warning: http://www.openstreetmap.org/browse/relation/2545313 turn 
restriction: to member not found

Was ist die Bedeutung der Fehlermeldung hier genau? Die Relation sieht 
einwandfrei aus (und das schon seit dem 1. November).

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] SPON: Matthias Kremp hat Here-Net mit Google Maps und den diversen OSM basierten Webdiensten verglichen

2012-11-16 Diskussionsfäden Eckhart Wörner

Hallo Johann,

Am Freitag, 16. November 2012, 01:54:41 schrieb Johann H. Addicks:
  aus Neugier: welche zwei der richtig großen Portale sind denn gemeint?
 
 Cloudmade und Mapquest.

maps.cloudmade.com hätte ich jetzt eher unter Demo eingeordnet. Ich glaube 
nicht, dass viele Leute da rauf gehen, um ihre nächste Tour zu planen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] SPON: Matthias Kremp hat Here-Net mit Google Maps und den diversen OSM basierten Webdiensten verglichen

2012-11-15 Diskussionsfäden Eckhart Wörner

Hallo Johann,

Am Donnerstag, 15. November 2012, 15:01:22 schrieb Johann H. Addicks:
  Lobenswert ist, dass der Autor durchaus erkannt hat, dass es 
 unterschiedliche Kartenportale im Netz gibt, die mit OSM-Diensten arbeiten.
  Schade, dass zwei richtig Große dabei nicht erwähnt wurden.

aus Neugier: welche zwei der richtig großen Portale sind denn gemeint?

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Routingprobleme

2012-11-10 Diskussionsfäden Eckhart Wörner

Hallo Chris,

Am Samstag, 10. November 2012, 14:41:21 schrieb Chris66:
 Ja. Das Symbölchen sollte z.B. rot sein, wenn bei einer *_left_turn
 Restriction der Winkel vom 'from' zum 'to'-way eine Rechtskurve ist.

generell sollte das Symbol berechnet werden, dann sind solche Fehler sofort 
ersichtlich.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Routingprobleme

2012-11-10 Diskussionsfäden Eckhart Wörner

Hallo Bernd,

Am Samstag, 10. November 2012, 20:49:19 schrieb Bernhard Weiskopf:
 Wenn jemand no_right_turn eingibt, obwohl er meint Linksabbiegen verboten,
 und die Rolle der links abbiegende Straße als to nimmt, dann müsste das
 Routing trotzdem richtig funktionieren. JOSM (u. a.) zeigen dann aber das
 falsche Symbol an.
 
 Deshalb ist auch unkritisch, ob man einen schrägen Abzweig noch als
 geradeaus oder als Abbiegen bezeichnet.

Das ist mir durchaus bewusst, aber auch nicht der Kern meiner Aussage.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Routingprobleme

2012-11-08 Diskussionsfäden Eckhart Wörner

Hallo Peter,

Am Mittwoch, 7. November 2012, 14:24:29 schrieb Peter Maiwald:
 Es gab eine nicht abgesprochene Änderung im Wiki zu turn restrictions. Dort
 wurden alle no entfernt und durch sich überlagernde only ersetzt. Müsste
 in der History im Wiki einsehbar sein. Mittlerweile ist das Wiki reverted.

ich weiß, ich war derjenige, der das reverted hat. ;-)

Aber das Problem mit falschen Turn Restrictions hat m.E. nichts mit dem Wiki zu 
tun, sondern mit der Darstellung von JOSM, die zu solchen Fehlern geradezu 
einlädt.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Problem einer Auffahrt auf eine autobahnähnlich Straße

2012-11-07 Diskussionsfäden Eckhart Wörner

Hallo Albrecht,

Am Mittwoch, 7. November 2012, 09:25:15 schrieb Albrecht Will:
 am 3.11 habe ich mich erstmalig von Osmand navigieren lassen. Dabei fiel mir 
 ein eklatanter Fehler in der Führung auf. Es betrifft den Knoten
 
 http://www.openstreetmap.org/?lat=52.26426959037781lon=11.628706455230713zoom=16
 
 Die Navigation wollte mich von der L 44 kommend zur rechten Auffahrt auf die 
 B 
 89 in Richtung Norden (Stendal) weisen, um dann genau am nördlichen Ende des 
 trunk eine Wendung vorzuschreiben. Das ist natürlich falsch. Die Route muß 
 über die B 189 weiterführen und dann auf den trunk_link als Auffahrt auf die 
 B 
 189n. 
 
 Ich habe den Autor flierfy bisher nicht erreicht. Zum selber ändern fehlt mir 
 die Erfahrung, deshalb die Frage an Euch: Wäre es richtig, für die ways vom 
 Knoten 351 315 59 bis 351 315 72 den Wert trunk_link zu entfernen?

Nein.

Der Fehler liegt in diesem Fall bei Osmand, und zwar gleich doppelt:
1. trunk_link impliziert zwar oneway=yes, das explizite oneway=no hebt das aber 
wieder auf.
2. der U-Turn, den Osmand vorschlägt, ist falsch: seit dem 9.1.2012 ist da ein 
Wendeverbot eingetragen.

Andere Router kriegen das übrigens richtig hin:
http://osrm.at/1Fd

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Routingprobleme

2012-11-07 Diskussionsfäden Eckhart Wörner

Am Mittwoch, 7. November 2012, 11:50:16 schrieb aighes:
 bei den beiden turn-restrictions only_straight_on waren jeweils die 
 to-Member falsch gesetzt. Hab ich soeben behoben.

Inzwischen ist das leider eine der häufigsten Ursachen für Routing-Probleme.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Routingprobleme

2012-11-07 Diskussionsfäden Eckhart Wörner

Hallo Bernd,

Am Mittwoch, 7. November 2012, 17:25:31 schrieb Bernd Wurst:
 Am 07.11.2012 15:18, schrieb Eckhart Wörner:
  Am Mittwoch, 7. November 2012, 11:50:16 schrieb aighes:
  bei den beiden turn-restrictions only_straight_on waren jeweils die 
  to-Member falsch gesetzt. Hab ich soeben behoben.
  Inzwischen ist das leider eine der häufigsten Ursachen für Routing-Probleme.
 
 Was? Datenfehler? Ist zu erwarten, ja. *scnr*

Falsche to-Member bei Abbiegerelationen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] OpenStreetBugs-Einbau in Hauptseite

2012-10-16 Diskussionsfäden Eckhart Wörner

Hallo Jan,

Am Dienstag, 16. Oktober 2012, 16:50:22 schrieb Jan Tappenbeck:
 was mir gleich auffällt - der Note wird automatisch in Bildschirmmitte 
 gesetzt - das finde ich irgendwie unpassend.
 
 Der User brauch ein Hilfsmittel - glaube nicht das es so klappt mit dem 
 Zielen auf die Bildschirmmitte.
 
 Kimme - Korn - ran.

man kann den Marker doch verschieben?

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kaputte Turn Relations: Deutschland, Österreich, Schweiz, Italien, Tschechien

2012-10-12 Diskussionsfäden Eckhart Wörner

Hallo Rainer,

Am Freitag, 12. Oktober 2012, 22:04:21 schrieb Rainer Dorsch:
 ich habe einen maptool bugreport geöffnet:
 
   http://trac.navit-project.org/ticket/1076

danke. :-)

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Straßenlistenauswertung in Beta-Version verfügbar

2012-10-11 Diskussionsfäden Eckhart Wörner

Hallo Martin, hallo Dietmar,

Am Donnerstag, 11. Oktober 2012, 07:58:42 schrieb Martin Trautmann:
 Ich möchte hiermit nochmals die Bitte wiederholen, die Auflistung nicht
 nur mit grafisch unterschiedlicher Hintergrund-Farbe zu gestalten,
 sondern das auch im text-only-Modus zu unterstützen, indem nach diff-Art
 die Zeilen mit einem Präfix markiert werden:
 
  in OSM enthalten
  in der anderen Quelle enthalten
 : in beiden enthalten

wenn schon, dann unified diff, den kann man wesentlich besser lesen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Straßenlistenauswertung in Beta-Version verfügbar

2012-10-11 Diskussionsfäden Eckhart Wörner

Hallo Martin,

Am Donnerstag, 11. Oktober 2012, 14:29:05 schrieb Martin Trautmann:
 Mir geht's um die Gesamtlisten. Was hilft da das partielle unified?

unified impliziert nicht partiell. Es geht mir eigentlich nur um die 
Verwendung von + und - statt  und .

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Straßenlistenauswertung in Beta-Version verfügbar

2012-10-10 Diskussionsfäden Eckhart Wörner

Hallo Peter,

Am Mittwoch, 10. Oktober 2012, 20:53:40 schrieb Peter Wendorff:
 Die Straßenlisten stehen im Wiki.
 Wie offiziell sind die, woher kommen die?

von offizieller Stelle (Stadt, Land, …)

 Wenn die Straßenlisten selbstgeschrieben sind, haben wir durch die 
 Auswertung ja nicht so besonders viel gewonnen, aber z.B. in Paderborn 
 fehlen diverse Straßen in der Straßenliste, die dann als nur in OSM 
 auftauchen.

dann gibt es mehrere Möglichkeiten:
• die Straßenliste für die Stadt ist veraltet
• die offizielle Straßenliste ist unvollständig
• OSM hat Straßen, die es gar nicht gibt

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kaputte Turn Relations: Deutschland, Österreich, Schweiz, Italien, Tschechien

Hallo zusammen,

Am Sonntag, 7. Oktober 2012, 20:18:51 schrieb Rainer Dorsch:
 habe hier eine lange Liste mit kaputten Turn Relations (Deutschland und 
 Italien sind ca. 1 Woche alt, alle anderen sind von heute):
 
 http://bokomoko.de/~rd/broken_turn_relations_121007.log

kann es sein, dass die multiple from-members und multiple to-members alle 
von Potlatch kaputtgemacht worden sind?

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kaputte Turn Relations: Deutschland, Österreich, Schweiz, Italien, Tschechien

Hallo Franz,

Am Dienstag, 9. Oktober 2012, 00:00:39 schrieb Franz v. Gordon:
 Eckhart Wörner schrieb:
   kann es sein, dass die multiple from-members und multiple 
  to-members alle von Potlatch kaputtgemacht worden sind?
 
 Nein - hier [1] sind in Version 3 mehrere to- und via-Rollen 
 hinzugekommen - editiert wurde mit JOSM (5267.de).
 Auch hier [2] kamen in den Versionen 4 und 6 überflüssige Rollen hinzu - 
 beide editiert mit JOSM.
 
 [1] http://www.openstreetmap.org/browse/relation/169052/history
 [2] http://www.openstreetmap.org/browse/relation/287329/history

gerade mal angetestet; JOSM (5485) kriegt Abbiegebeschränkungen beim Aufspalten 
nicht kaputt, selbst ohne turnrestrictions-Plugin und mit unvollständigen 
Relationen – und erst recht fügt er keine neuen via-Knoten hinzu.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kaputte Turn Relations: Deutschland, Österreich, Schweiz, Italien, Tschechien

Hallo Rainer,

Am Sonntag, 7. Oktober 2012, 20:18:51 schrieb Rainer Dorsch:
 habe hier eine lange Liste mit kaputten Turn Relations (Deutschland und 
 Italien sind ca. 1 Woche alt, alle anderen sind von heute):
 
 http://bokomoko.de/~rd/broken_turn_relations_121007.log

Grrr, immer noch mit Fehlalarm, z.B.:
 OSM Warning:http://www.openstreetmap.org/browse/relation/3659 turn 
 restriction: multiple via member

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kaputte Turn Relations: Deutschland, Österreich, Schweiz, Italien, Tschechien

Hallo Franz,

Am Dienstag, 9. Oktober 2012, 01:04:11 schrieb Eckhart Wörner:
 gerade mal angetestet; JOSM (5485) kriegt Abbiegebeschränkungen beim 
 Aufspalten nicht kaputt, selbst ohne turnrestrictions-Plugin und mit 
 unvollständigen Relationen – und erst recht fügt er keine neuen via-Knoten 
 hinzu.

Korrektur: die zusätzlichen via-Knoten kommen wohl bei Linien trennen 
zustande, das fängt JOSM (noch) nicht ab.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Spurmapping - WAS: [Openstreetbugs] AST der ... fehlt.

2012-10-07 Diskussionsfäden Eckhart Wörner

Hallo Bernd,

Am Sonntag, 7. Oktober 2012, 15:15:38 schrieb Bernhard Weiskopf:
ich habe in der Umgebung von Mannheim gerade Probleme mit einem Mapper, der
viele sorgfältig gemappte Kreuzungen (mit lanes, Abbiegerelationen usw.)
gelöscht hat und durch eigene Kreationen ersetzt hat. Dabei haben die
kreuzenden Spuren keine gemeinsamen Knotenpunkte, Spuraufteilung erfolgt
ohne bauliche Trennung, manche Richtungen sind nicht mehr fahrbar wegen
fehlendem Knoten oder Einbahnregelung, Relationen sind unvollständig, weil
eine der beteiligten roles gelöscht wurden usw.

Auf Anfrage teilte mir der Mapper mit war der Meinung, dass es für die
Navigation so eindeutiger ist

oh je, da kann ich auch ein Lied von singen.
Sieht man übrigens auch ständig auf Autobahnen – geschätzt ein Viertel der
Autobahnabfahrten in Deutschland haben Spurmapping.

Ein paar Gründe, weswegen das ständig vorkommt:
• Wie schon erwähnt: obwohl Spurmapping verpönt ist, findet sich kaum ein
Hinweis im Wiki. Auf die Schnelle habe ich nur hier was gefunden:
http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Autobahn#Allgemeine_Hinweise_f.C3.BCr_Autobahnen
• Aus Unwissenheit gehen die Leute häufig davon aus, dass sie den Routern
Arbeit abnehmen. (Das Gegenteil ist der Fall: Spurmapping erhöht die Anzahl der
Wege und damit die Dauer der Routenberechnung, Abbiegebeschränkungen reduzieren
Auswahlmöglichkeiten für den Router und verkleinern damit die Dauer der
Routenberechnung.)
• Viele, die es besser wissen, trauen sich nicht, die Fehler rückgängig zu
machen.
• Viele, die es besser wissen und den Fehler rückgängig machen, weisen den
entsprechenden Mapper nicht darauf hin.
• Viele Mapper orientieren sich beim Mappen an vorhandenen Gegebenheiten,
dadurch werden Fehler in gewissem Umfang normiert.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Help

2012-10-07 Diskussionsfäden Eckhart Wörner

Hallo Gerhard,

Am Sonntag, 7. Oktober 2012, 19:38:25 schrieb Gerhard Hermanns:
  Unsubcribe
 
 Ich vermute, es soll unsubscribe heißen (zweites s fehlt).

ich vermute mal, die Mail sollte zusätzlich eher an talk-de-request@… gehen – 
beliebter Fehler.
(Ich habe grad mal einen Unsubscribe-Code für ihn losgeschickt.)

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update von nominatim.osm.org

2012-10-03 Diskussionsfäden Eckhart Wörner

Hallo Sarah,

Am Dienstag, 11. September 2012, 18:31:15 schrieb Sarah Hoffmann:
  bin mir immer noch nicht sicher, warum es nicht funktioniert. Beispiel 
  Aystetten:
  Suche ( http://nominatim.openstreetmap.org/search.php?q=Aystetten ) liefert 
  sowohl Relation als auch Knoten, aber:
  
  – die Relation und der Knoten heißen gleich
  – die Relation ( http://www.openstreetmap.org/browse/relation/44 ) 
  enthält den Knoten mit Rolle label
  – die Änderungen sind schon vor ein paar Tagen passiert
 
 Es gab da noch ein Problem mit den Updates von Place-Boundary-Verbindungen.
 Im Code ist das bereits repariert, aber der OSM-Server wird erst in
 ca. 2 Wochen das nächste Software-Update erhalten. Es wird wegen dem
 Lizenzwechsel auch nochmal einen Neuimport der Datenbank geben in naher
 Zukunft. Spätestens dann sollten deine Änderungen sichtbar sein.

ich nehme an, den Neuimport hat es schon gegeben? Das Beispiel funktioniert 
leider immer noch nicht.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update von nominatim.osm.org

2012-10-03 Diskussionsfäden Eckhart Wörner

Hallo Sarah,

Am Mittwoch, 3. Oktober 2012, 17:59:26 schrieb Sarah Hoffmann:
 Der Neuimport steht leider immernoch aus. Wenn nichts dazwischen kommt,
 wird es wohl übernächstes Wochenende passieren.

alles klar, danke.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] MapDust, Skobbler und die Community

2012-09-20 Diskussionsfäden Eckhart Wörner

Hallo Florian,

Am Montag, 17. September 2012, 09:29:20 schrieb Florian Lohoff:
  ∙ ebenfalls seit über einem Jahr werden Fehlerberichte mit Standard-Text 
  nicht 
  mehr als solche gekennzeichnet. Das macht die Option Hide bugs with 
  default 
  text (die standardmäßig aktiviert ist) praktisch wirkungslos.
 
 Bugs mit default text schliesse ich ohne zu kommentieren. Wenn man das 
 kontinuierlich macht gehts auch mit der fehlerrate. Richtig ist

Das Problem ist, dass auch in Bugs mit Default-Text gelegentlich Fehler zu 
erkennen sind.
Schönes Beispiel hierfür gerade gefunden: http://www.mapdust.com/detail/2929755
Seit dem 16.3.2009 (!) kann man auf der Theodor-Heuss-Straße in Ingolstadt 
(Hauptverkehrsachse) wegen einer falschen Abbiegerelation nicht mehr geradeaus 
über die Kreuzung.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions

Hallo Ronnie,

Am Dienstag, 18. September 2012, 14:46:21 schrieb Ronnie Soak:
 Das erste Proposal zum Thema extended conditions das mir (von den
 Tücken der englischen Sprache mal abgesehen) intuitiv genug für den
 Otto-Normalnutzer scheint und doch auch
 verzwickte Fälle noch einigermaßen abdeckt.
 
 Bitte schaut euch das doch mal an und kommentiert Probleme auf der
 Diskussionsseite. Abstimmen schadet natürlich auch nicht.
 
 Insbesondere die Sicht von Datenkonsumenten fehlt noch ...

Aus meiner Sicht ist eine Implementierung nicht übermäßig schwierig. Im 
Gegensatz zum Extended-Conditions-Proposal ist der Preprocessing-Code des 
Routers ein bisschen kürzer (in den Conditional Restrictions ist die 
Reihenfolge schon festgelegt, für die Extended Conditions muss diese berechnet 
werden).

Viel gravierender ist, dass das Schema für Mapper zumindest in den heutigen 
Editoren eine Katastrophe ist, aber das scheint ja eher ein Randaspekt zu 
sein.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions

Hallo Ronnie,

Am Mittwoch, 19. September 2012, 10:28:19 schrieb Ronnie Soak:
  Viel gravierender ist, dass das Schema für Mapper zumindest in den heutigen
  Editoren eine Katastrophe ist, aber das scheint ja eher ein Randaspekt zu
  sein.
 
 Kannst du das genauer ausfuhren? Wo siehst du Probleme? Natürlich gibt
 es momentan noch nichts in den Editoren. Es ist ja auch nur ein
 Proposal. Aber spricht aus technischer Sicht etwas dagegen?

Okay, folgendes Beispiel (vereinfachtes Beispiel aus der Wirklichkeit): eine 
Autobahnbrücke, auf der bei Nässe langsam (80) gefahren werden muss, die 
Geschwindigkeit wird vor der Brücke schrittweise reduziert:
http://eckhart-woerner.de/~eckhart/conditional-restrictions.osm

Weil in der Nähe der Autobahn Häuser sind, wird nun beschlossen, von 22:00 Uhr 
bis 06:00 Uhr eine Geschwindigkeitsbeschränkung von 100 auf dem gesamten 
Autobahnabschnitt einzuführen. Bitte taggen!

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions

Hallo aighes,

Am Mittwoch, 19. September 2012, 11:28:37 schrieb aighes:
 Der GUI ist es doch letztlich nahezu egal, was sie in die Tags schreibt 
 und dem Auswerter ist es auch nahezu egal, was in dem Tag steht (es gibt 
 ein paar Einschränkungen, wie konstante Keys). Egal wie simpel das 
 Schema sein wird, es wird für die meisten Mapper zu kompliziert sein, 
 als das sie es von Hand eintippen.

Das halte ich jetzt für eine nicht ganz zutreffende Verallgemeinerung. Ich 
glaube nicht, dass maxspeed:wet=80 zu kompliziert ist, um von Hand eingegeben 
zu werden.
Es wird eher so sein, dass eine GUI das letzte ist, was kommt.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Fwd: [Tagging] Feature Proposal - Voting - Conditional Restrictions

Hallo Ronnie,

Am Mittwoch, 19. September 2012, 11:51:45 schrieb Ronnie Soak:
  Okay, folgendes Beispiel (vereinfachtes Beispiel aus der Wirklichkeit): 
  eine Autobahnbrücke, auf der bei Nässe langsam (80) gefahren werden muss, 
  die Geschwindigkeit wird vor der Brücke schrittweise reduziert:
  http://eckhart-woerner.de/~eckhart/conditional-restrictions.osm
 
  Weil in der Nähe der Autobahn Häuser sind, wird nun beschlossen, von 22:00 
  Uhr bis 06:00 Uhr eine Geschwindigkeitsbeschränkung von 100 auf dem 
  gesamten Autobahnabschnitt einzuführen. Bitte taggen!
 
 
 auf den Stücken vor und hinter der Brücke:
 
 maxspeed:conditional = 100 @ (22:00 - 06:00)
 
 Auf den bei Nässe reduzierten Stücken:
 
 maxspeed:conditional = 100 @ (22:00 - 06:00); 80 @ (wet)
 
 Die detailiertere Bedingung wird jeweils hinten angehägt. Es gilt bei
 Nässe nach 22Uhr als 80. Soll stattdessen 100 gelten, muss man
 andersherum taggen.
 (Sorry, ich kann gerade nicht in die .osm Datei schauen, ich hoffe es
 war so gemeint.)

Die .osm-Datei ist deutlich ausführlicher, in dem Beispiel geht es wirklich 
darum, das Tagging zu *erleben*.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] MapDust, Skobbler und die Community

Hallo Martin,

Am Sonntag, 16. September 2012, 20:15:53 schrieb Martin Vonwald:
  Die Verwendung von OSM-Daten fürs Routing, speziell fürs Auto-Routing, ist 
  – 
  aus meiner Sicht – immer noch eine mittlere Katastrophe. 
 
 Zuerst muss ich dir entschieden widersprechen: das Routing funktioniert 
 erstaunlich gut. Ich verwende Skobbler seit Version 2 regelmäßig. Grobe 
 Probleme habe ich damit keine. Weder hier im Datenschlaraffenland Großraum 
 Wien oder in Deutschland, auch in Holland und Italien kommt man damit ans 
 Ziel.

Ein Navi sollte mehr als nur zum Ziel leisten können, das kann ein 
Straßenatlas auch. Es sollte eine möglichst nahe am Optimum liegende Route 
finden, es sollte die einzelnen Schritte der Route audiovisuell aufbereiten, 
und es sollte sich bei Abweichungen von der Route vernünftig verhalten.

 In letzterem zugegebenermaßen vor allem im Süden schafft man es oft nur bis 
 zum Stadtrand,

Nur leider ist der Weg vom Stadtrand bis zum Ziel im Normalfall der 
komplizierteste Teil der Route. Von München nach Neapel kommt man zur Not auch 
mit einem Blick auf den Straßenatlas und danach nur mit der 
Straßenbeschilderung, aber ich habe keine Chance, das Einbahnstraßengewirr in 
der Innenstadt ohne Hilfe zu befahren.

 aber ein kommerzielles Navi leistete sich eine ähnliche Anzahl von Patzern.

Ich hoffe, das ist nicht die Messlatte.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] MapDust, Skobbler und die Community

Hallo Martin,

Am Montag, 17. September 2012, 11:04:36 schrieb Martin Vonwald:
 Abgesehen von Italien kann ich - wie beschrieben - nichts
 gegenteiliges berichten. Skobbler funktioniert sehr gut, lieferte gute
 Route und gute Ansagen.

Sicher? Sobald man mit Skobbler die vorberechnete Route verlässt, merkt man, 
wie viele Abbiegebeschränkungen überall noch fehlen, z.B.:

http://map.project-osrm.org/1lN
http://map.project-osrm.org/1lO
http://map.project-osrm.org/1lQ

Das ist jetzt aber schon eine der guten Gegenden.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] MapDust, Skobbler und die Community

Hallo Martin,

Am Montag, 17. September 2012, 12:46:26 schrieb Martin Vonwald:
  Sicher? Sobald man mit Skobbler die vorberechnete Route verlässt, merkt 
  man, wie viele Abbiegebeschränkungen überall noch fehlen, z.B.:
 
  http://map.project-osrm.org/1lN
  http://map.project-osrm.org/1lO
  http://map.project-osrm.org/1lQ
 
  Das ist jetzt aber schon eine der guten Gegenden.
 
 Wie gesagt: aus meiner Erfahrung. Das ist wahrscheinlich von Gegend zu
 Gegend und Fahrer zu Fahrer unterschiedlich.

Ich hab die Gegend nicht ganz zufällig ausgesucht. ;-)

 Nur um eines klarzustellen: wir sind einer Meinung: es fehlt noch sehr viel.
 
 Aber ganz furchtbar schlecht ist es dann doch wieder nicht ;-) Wir
 können schon stolz sein darauf, was wir bisher zusammengebracht haben!

Deswegen hab ich ja nur von einer *mittleren* Katastrophe gesprochen. :-P

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kreuzung richtig mappen

Hallo Martin,

Am Montag, 17. September 2012, 08:00:38 schrieb Martin Vonwald:
Ich hätte nämlich ganz gerne ein Tag für eine Fläche um ganz allgemein
Features zu einem Objekt zusammenzufassen. Vielleicht so etwas wie
area=structure oder so ähnlich.

Gibt es schon, nennt sich Relation.
Wieso schaffen wir es in OSM eigentlich *nie*, Dinge dafür zu verwenden, wofür
sie geschaffen sind? Wir haben schon Relationen, die eigentlich Flächen sind
(Multipolygon), jetzt kommen dann Flächen, die eigentlich Relationen sind?

Warum eine Fläche und keine Relation?
* Sichtbarkeit: eine Fläche ist in jedem Editor sofort sichtbar. Eine
Relation muss erst ausgewählt werden. Wenn man nicht weiß, dass sie da ist,
bleibt sie unsichtbar.

Das ist ein Problem, das man eher im Editor in den Griff kriegen sollte.

* Intuitiv: die Fläche wird entsprechend der Ausdehnung der Kreuzung
gezeichnet und kann daher auch als Darstellung der Kreuzung von jemanden
erkannt werden, der das Tagging selbst nicht kennt. Die (ausgewählte)
Relation zeigt nur Punkte und Wege im Bereich einer Kreuzung: das kann eine
Kreuzung sein oder irgendetwas anderes.

Das ist genauso ein Problem, das man mit dem Editor in den Griff kriegen kann.
Abgesehen davon kann ich in dem Beispielbild die Fläche genausogut als Brücke
interpretieren.

* Robustheit: wenn jemand ohne Kenntnis Objekte innerhalb des
Kreuzungsbereichs ergänzt oder Objekte in den Kreuzungsbereich hinein
verschiebt, können diese im Fall der Fläche der Kreuzung zugeordnet werden.
Die Relation würde diese Information nicht erhalten.

Okay, dann machen wir doch mal die Probe aufs Exempel: welche Wege gehören in
diesem Bild zur Kreuzung, und vor allem, nach welchen Regeln:
http://wiki.openstreetmap.org/w/images/thumb/f/ff/Rautenweg_New.jpeg/608px-Rautenweg_New.jpeg

* Auswertung: […] Für einen Renderer, welcher den Kreuzungsbereich darstellen
will, ist eine Relation sogar aufwendiger, weil er die Fläche erst auf Basis
der Relationsdaten schätzen muss.

Hier ist das Hauptproblem des Proposals: eine Kreuzung ist kein physikalisches
Objekt, sie hat keine Fläche – oder wo würdest du die Grenze ziehen? Gehören
die Abbiegespuren zur Kreuzung dazu? Beschleunigungsstreifen? Abbiegespuren?

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kreuzung richtig mappen

Hallo Martin,

Am Montag, 17. September 2012, 14:57:25 schrieb Martin Vonwald:
  * Robustheit: wenn jemand ohne Kenntnis Objekte innerhalb des 
  Kreuzungsbereichs ergänzt oder Objekte in den Kreuzungsbereich hinein 
  verschiebt, können diese im Fall der Fläche der Kreuzung zugeordnet 
  werden. Die Relation würde diese Information nicht erhalten.
 
  Okay, dann machen wir doch mal die Probe aufs Exempel: welche Wege gehören 
  in diesem Bild zur Kreuzung, und vor allem, nach welchen Regeln: 
  http://wiki.openstreetmap.org/w/images/thumb/f/ff/Rautenweg_New.jpeg/608px-Rautenweg_New.jpeg
 
 Wenn du diese Frage nicht beantworten kannst, wie willst du dann
 wissen, was du in die Relation geben musst??

Du hast die Frage falsch verstanden: gegeben die eingezeichnete Fläche, welche 
Wege sind dann Teil der Kreuzung, und warum?

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kreuzung richtig mappen

Hallo Martin,

Am Montag, 17. September 2012, 14:59:55 schrieb Martin Koppenhoefer:
  Gibt es schon, nennt sich Relation.
 
 -1, wo eine Fläche ausreicht sollte man die Daten m.E. nicht mit einer 
 Relation belasten

eine Fläche reicht eben *nicht* aus, dazu reicht schon ein Blick auf die 
Beispielbilder.

 +1, eine Kreuzung ist dort, wo 2 Wege einen gemeinsamen Node haben. Ein 
 Kreuzungsobjekt aus mehreren Wegen macht m.E. keinen Sinn bzw. ist 
 Interpretationssache des Betrachters, wie sollte man das definieren bzw. 
 abgrenzen? Wann sind es 2 oder mehr Kreuzungen in direkter räumlicher Nähe 
 und wann ist es eine Kreuzung? Wenn man das z.B. anhand der Ampelschaltung 
 festlegen will, würde ich eher die Ampeln irgendwie zusammenfassen, nicht 
 Kreuzungen  festlegen.

Ampelschaltungen anhand von Kreuzungen halte ich auch für keine gute Idee. Wenn 
man Ampelschaltungen wirklich zur Verbesserung des Routings verwenden möchte, 
sollte man sich stattdessen erstmal jede Menge Gedanken über grüne Wellen 
machen.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kreuzung richtig mappen

Hallo Martin,

Am Montag, 17. September 2012, 15:17:23 schrieb Martin Vonwald:
 Das Proposal braucht die Schnittpunkte der Wege und eventuell Features
 wie Ampeln - also einzelne Knoten. All das ist eindeutig zuzuordnen.
 Wofür würdest du vollständige Wege brauchen?

Vielleicht dafür:
 In the future tags could be applied to the whole junction.

Das Problem ist, dass das Proposal hier immer schwammig bleibt. Die 
entscheidende Frage *Wie* ist komplett ausgespart:
 Renderers could display the junction as a single, closed area, which
 should be closer to reality.

*Wie* soll das bitteschön aussehen? Die ganze Fläche grau? Die ganze Fläche 
grün kariert? Inwiefern entspricht das mehr der Realität?

 Renderers could display e.g. traffic
 lights or similar at lower zoom level, but only one for each junction.

Da ist Clustering wesentlich sinnvoller.

 Routers could give more precise instructions, especially on complex
 junctions

*Wie* soll das gehen?

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kreuzung richtig mappen

Hallo Martin,

Am Montag, 17. September 2012, 15:51:25 schrieb Martin Vonwald:
  Renderers could display the junction as a single, closed area, which
  should be closer to reality.
  *Wie* soll das bitteschön aussehen? Die ganze Fläche grau? Die ganze Fläche 
  grün kariert? Inwiefern entspricht das mehr der Realität?
 
 So wie es am Boden aussieht: ein dicker Patzen grau - besser bekannt
 als Asphalt. Die Streckenführung kann dann angedeutet werden;
 abgeleitet aus den Wegen.

Die Kreuzung, die du auf dem Bild eingezeichnet hast, ist aber nicht nur 
Asphalt; ich sehe da auch Beton (auf den Verkehrsinseln) und Kies (?). Im 
Allgemeinen können auf einer Kreuzung noch Grünflächen oder Goldfischteiche 
dazukommen.
Und ganz ernsthaft: nimm dir mal die Kreuzung vor und färb das mal so ein, wie 
du vorschlägst, dann weißt du auch, warum ich das für keine gute Idee halte.

  Renderers could display e.g. traffic
  lights or similar at lower zoom level, but only one for each junction.
  Da ist Clustering wesentlich sinnvoller.
 
 Inwiefern?

Weil man sonst das Problem von sich überlappenden Ampeln etc. wieder bei dicht 
nebeneinander liegenden Kreuzungen hat?

  Routers could give more precise instructions, especially on complex
  junctions
  *Wie* soll das gehen?
 
 Das bezieht sich nicht auf die Fläche sondern auf die Wege durch die
 Kreuzung, die man nun so zeichnen soll, wie sie tatsächlich vorhanden
 sind; vor allem sollen damit Sternkreuzungen vermieden werden.

Was sind Sternkreuzungen?

 Der
 Router hat dann genauere Informationen über die Spurführung durch die
 Kreuzung und deshalb kann er bessere Anweisungen geben. Vor allem aber
 weiß er, dass Wegkreuzungen und -aufsplittungen zu ein und der selben
 Kreuzung gehören und muss dann nicht sagen jetzt links, dann gleich
 rechts und dann sofort scharf links sondern einfach an der Kreuzung
 links. (Das war jetzt ein Beispiel!)

Dazu muss der Router aber von jedem Weg wissen, welche Teile zur Kreuzung 
gehören – und die Frage, wie du das ermittelst, hatte ich schon mal gestellt.

 Und abschließend: nein, kein Proposal muss im vorhinein exakt
 definieren was man alles mit den dann zur Verfügung stehenden Daten
 machen kann/soll/muss und dann auch noch genau das *Wie* beschrieben.
 Proposals beziehen sich auf Daten - nicht auf Implementationen. Ein
 Proposal muss nur sicherstellen, dass diese Art der Daten verarbeitet
 werden kann.

Ein Proposal sollte Use Cases definieren und eine Implementierung skizzieren.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Kreuzung richtig mappen

Hallo Martin,

Am Montag, 17. September 2012, 16:32:56 schrieb Martin Vonwald:
  Die Kreuzung, die du auf dem Bild eingezeichnet hast, ist aber nicht nur 
  Asphalt; ich sehe da auch Beton (auf den Verkehrsinseln) und Kies (?). Im 
  Allgemeinen können auf einer Kreuzung noch Grünflächen oder Goldfischteiche 
  dazukommen.
  Und ganz ernsthaft: nimm dir mal die Kreuzung vor und färb das mal so ein, 
  wie du vorschlägst, dann weißt du auch, warum ich das für keine gute Idee 
  halte.
 
 Sorry, nein. Ist wohl nicht mein Tag ;-) Aber reden wir jetzt wirklich
 schon von Problemen beim Einfärben? Gibt es sonst keine Probleme mit
 dem Proposal mehr? ;-) Cool, dann starte ich mal das Voting :-D

Nein, das ist nur ein Teilaspekt. Ich will dir eigentlich nur zeigen, dass das 
keine gute Idee ist, und dass du hier die Kreuzung mit einer merkwürdigen 
Nebenbedeutung befahrbare Fläche gefüllt hast.

  Was sind Sternkreuzungen?
 
 Sowas: http://wiki.openstreetmap.org/wiki/File:Complex-isect3.png

Ähm, ja. Da hat jemand Spurmapping mit Wegen gemacht, was an sich schon eine 
schlechte Idee ist. Das Spurmapping entfernen und eine #-Kreuzung daraus 
machen, dann sieht die Kreuzung gleich vernünftig aus. Dafür brauchts aber 
keine speziellen Flächen, nur etwas Wille zur Zerstörung. :-)

  Der
  Router hat dann genauere Informationen über die Spurführung durch die
  Kreuzung und deshalb kann er bessere Anweisungen geben. Vor allem aber
  weiß er, dass Wegkreuzungen und -aufsplittungen zu ein und der selben
  Kreuzung gehören und muss dann nicht sagen jetzt links, dann gleich
  rechts und dann sofort scharf links sondern einfach an der Kreuzung
  links. (Das war jetzt ein Beispiel!)
  Dazu muss der Router aber von jedem Weg wissen, welche Teile zur Kreuzung 
  gehören – und die Frage, wie du das ermittelst, hatte ich schon mal 
  gestellt.
 
 Öhm nein. Er muss wissen welche Kreuzungspunkte (der OSM-Wege) zur
 Kreuzung gehören. Denn nur da kann man abbiegen. Und wie ebenfalls
 schon gesagt: das ist eindeutig feststellbar.

Nein, das reicht nicht. Wenn eine Route zwei Kreuzungspunkte derselben Kreuzung 
benutzt, heißt das noch nicht, dass man die Abbiegevorgänge zusammenfassen 
kann; genauso gut kann die Route die Kreuzung zwischendurch verlassen – und ja, 
sowas kann durchaus passieren.

  Und abschließend: nein, kein Proposal muss im vorhinein exakt
  definieren was man alles mit den dann zur Verfügung stehenden Daten
  machen kann/soll/muss und dann auch noch genau das *Wie* beschrieben.
  Proposals beziehen sich auf Daten - nicht auf Implementationen. Ein
  Proposal muss nur sicherstellen, dass diese Art der Daten verarbeitet
  werden kann.
 
  Ein Proposal sollte Use Cases definieren und eine Implementierung 
  skizzieren.
 
 Die Vorteile sind aufgezählt. Und nein: Implementierungen - auch
 Skizzen - haben in einem Proposal wahrlich nichts verloren. Wir sind
 hier kein Lehrgang in die Einführung der Programmierung.

Den Effekt hab ich schon in der Extended-Conditions-/Conditional-Access-Debatte 
gesehen: jede Menge Proposals, die technisch unmöglich waren.

 Aber ich habe
 dich schon verstanden: du bist anderer Meinung und das ist ja auch
 dein gutes Recht :-)

Dass ich anderer Meinung bin, ist glaube ich nicht überraschend. (Fürs 
Protokoll: ich halte eine Relation für wesentlich sinnvoller, und ich bin auch 
gegen das Kreuzen von Straßen ohne Kreuzungspunkt.) Ich verstehe aber nicht, 
was das jetzt mit der Diskussion zu tun hat.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] MapDust, Skobbler und die Community

2012-09-16 Diskussionsfäden Eckhart Wörner

Hallo zusammen,

ich möchte eine kleine Diskussion über MapDust anstoßen.

== Für Nicht-Kenner ==
MapDust ist eine von der Firma Skobbler erstellte Karte von Fehlern, die aus 
der Navi-Software von Skobbler heraus von Endanwendern gemeldet werden; die 
Addresse ist http://www.mapdust.com/

== Ausgangslage ==
Die Verwendung von OSM-Daten fürs Routing, speziell fürs Auto-Routing, ist – 
aus meiner Sicht – immer noch eine mittlere Katastrophe. Das Problem sind 
weniger weiße Flecken auf der Landkarte als vielmehr die vielen Kleinigkeiten, 
die man auf Karten normalerweise nicht sieht, und die das Routing trotzdem 
beeinflussen: falsche Höchstgeschwindigkeiten, falsche 
Durchfahrtsbeschränkungen, fehlende Abbiegebeschränkungen, …
All diese Probleme lassen sich jedoch im Allgemeinen durch die tatsächliche 
Nutzung der Daten fürs Routing erkennen. Aus diesem Grund ist es jedoch 
wichtig, dass es eine Feedback-Kette vom Endanwender zum Mapper gibt. An 
dieser Stelle hat MapDust eine wichtige Funktion.

== Die Vorteile von MapDust ==
∙ MapDust kategorisiert Fehlerberichte nach Typ (Abbiegebeschränkung, 
Einbahnstraßenproblem, …) und reichert sie um zusätzliche Informationen 
(berechnete Route, gefahrene Route, Ansagen, …) an. Dadurch ist es z.B. 
OpenStreetBugs, das fehlende Hundekottütenhalter und fehlende Straßen mit dem 
gleichen roten Kreuz kennzeichnet, doch stark überlegen.
∙ Viele Fehler, die in MapDust aufgezeigt werden, können mit minimalen 
Änderungen (z.B. eine neue Abbiegebeschränkung) gelöst werden, die 
Verbesserungen, die dadurch erreicht werden, sind teilweise enorm.

== Das große Aber ==
∙ Die vielen hilfreichen Fehler gehen in einer Schwemme von nichtssagenden 
Fehlern, Duplikaten oder aus uraltem Kartenmaterial stammenden Fehlern unter. 
Zur Zeit sind ca. 363 000 Fehlerberichte offen.
∙ Skobbler scheint auf Tauchstation gegangen zu sein: bekannte Probleme werden 
nicht behoben, die MapDust-Foren werden von Skobbler-Mitarbeitern konsequent 
gemieden.
∙ Die Mapper können sich anscheinend mit MapDust nicht anfreunden, nach meinen 
Schätzungen kümmern sich nur ein Dutzend Mapper regelmäßig um die 
Fehlerberichte, pro Tag werden lediglich ~150 Fehlerberichte geschlossen.

== Na und? ==
Warum MapDust von Skobbler so vernachlässigt wird, darüber kann man nur 
spekulieren; ich halte das aber für sehr kurzsichtig von Skobbler. Die Firma 
lebt davon, dass OpenStreetMap in den für sie interessanten Bereichen 
(hauptsächlich Routing) konkurrenzfähiges Kartenmaterial zur Verfügung stellt, 
und MapDust ist das Werkzeug, das sie dazu benötigen.
Andererseits ist es aber auch aus der Sicht von OpenStreetMap nicht sinnvoll, 
dieses Problem zu ignorieren. Die Verbesserungen, die durch MapDust erzielt 
werden, kommen nicht nur Skobbler zugute, sondern den OpenStreetMap-Daten an 
sich; Skobbler und OpenStreetMap leben über MapDust in Symbiose.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] MapDust, Skobbler und die Community

2012-09-16 Diskussionsfäden Eckhart Wörner

Hallo Martin,

Am Sonntag, 16. September 2012, 20:15:53 schrieb Martin Vonwald:
  Warum MapDust von Skobbler so vernachlässigt wird, darüber kann man nur 
  spekulieren; ich halte das aber für sehr kurzsichtig von Skobbler.
 
 Ich spekuliere mal: Schwemme von nichtssagenden Fehlern?
 Dagegen kann nämlich auch Skobbler nichts machen.

Das ist nicht ganz richtig, und das habe in meiner Ursprungsmail vergessen. 
Skobbler ist dafür zu einem Großteil selbst verantwortlich:
∙ seit über einem Jahr landen Fehlerberichte in mehrfacher Ausführung in 
MapDust, inzwischen gibt es kaum noch Fehlerberichte, die nicht mindestens in 
doppelter Ausführung ankommen
∙ ebenfalls seit über einem Jahr werden Fehlerberichte mit Standard-Text nicht 
mehr als solche gekennzeichnet. Das macht die Option Hide bugs with default 
text (die standardmäßig aktiviert ist) praktisch wirkungslos.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update von nominatim.osm.org

2012-09-10 Diskussionsfäden Eckhart Wörner

Hi,

Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann:
 Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes
 wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre'
 in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst 
 werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, 
 welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur
 beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen
 admin-level und place-Wert gibt. Die Node explizit zur Relation
 zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein
 Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum
 der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen
 führt, als der Mittelpunkt der Relation, der bisher verwendet wurde.

bin mir immer noch nicht sicher, warum es nicht funktioniert. Beispiel 
Aystetten:
Suche ( http://nominatim.openstreetmap.org/search.php?q=Aystetten ) liefert 
sowohl Relation als auch Knoten, aber:

– die Relation und der Knoten heißen gleich
– die Relation ( http://www.openstreetmap.org/browse/relation/44 ) enthält 
den Knoten mit Rolle label
– die Änderungen sind schon vor ein paar Tagen passiert

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update von nominatim.osm.org

Hallo Georg,

Am Freitag, 7. September 2012, 07:43:00 schrieb Georg Feddern:
  - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 
  (gibt es doch gar nicht?)
 
  Sollte der Knoten auch admin_level=6 getaggt werden?
 
 
 als Regierungssitz des Regierungsbezirks Schwaben (1) müsste Augsburg 
 eher admin_level=5 bekommen.
 Zumindest der node, damit scheint das nur ein Vertipper zu sein.

Ein Vertipper ist das wohl weniger, der node hat überhaupt kein admin_level 
getaggt.
Das Problem sehe ich darin, dass ein Node grundsätzlich mehr als ein 
admin_level haben müsste, um zu den Relationen zu passen, im Beispiel 5 *und* 6.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update von nominatim.osm.org

Hallo Georg,

Am Freitag, 7. September 2012, 09:06:45 schrieb Georg Feddern:
 Am 07.09.2012 08:20, schrieb Eckhart Wörner:
  Am Freitag, 7. September 2012, 07:43:00 schrieb Georg Feddern:
  - die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 
  (gibt es doch gar nicht?)
 
  eher admin_level=5 bekommen.
  Zumindest der node, damit scheint das nur ein Vertipper zu sein.
  Ein Vertipper ist das wohl weniger, der node hat überhaupt kein admin_level 
  getaggt.
 
 Oben steht das noch anders ...

Dann habe ich mich unklar ausgedrückt. Der Knoten hat laut
http://nominatim.openstreetmap.org/details.php?place_id=17722739
Admin Level 15, aber am Knoten selber ist admin_level nicht getaggt.

  Das Problem sehe ich darin, dass ein Node grundsätzlich mehr als ein 
  admin_level haben müsste, um zu den Relationen zu passen, im Beispiel 5 
  *und* 6.
 
 Nicht unbedingt.
 Sie müssen ja nur zusammenpassen, damit Nominatim den node dann 
 ignorieren kann ;-).
 
 Der node kann ja durchaus als Regierungssitz des Regierungsbezirks 
 gefunden werden
 Als node zur Gemeinde-Relation (hier als kreisfrei Stadt AL 6) muss er 
 ja aber nun nicht unbedingt vorhanden sein.

Es geht ja nicht nur darum, dass der Knoten aus den Suchergebnissen rausfliegt, 
sondern auch, dass er zum Zentrum der Grenzrelationen wird.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update von nominatim.osm.org

Hallo Sarah,

Am Freitag, 7. September 2012, 09:39:08 schrieb Sarah Hoffmann:
 Ich würde in diesem Fall eher mit 'label' als Rolle taggen als mit 
 'admin_centre',
 weil Augsburg ja nicht das Verwaltungszentrum der kreisfreien Stadt ist, 
 sondern
 es ist ein und dieselbe Stadt. Dann ist es nicht nötig, dass admin levels
 übereinstimmen.

klingt irgendwie überzeugend. :-)

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update von nominatim.osm.org

Hi,

Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann:
 Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes
 wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre'
 in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst 
 werden, wenn Name und Admin-Level stimmen. Fehlen beide, rät Nominatim, 
 welcher Place-Node zur Relation passen könnte. Das funktioniert aber nur
 beschränkt gut, weil es keine weltweit eindeutige Zuordnung zwischen
 admin-level und place-Wert gibt. Die Node explizit zur Relation
 zuzufügen ist daher zuverlässiger. Wenn für eine Grenzrelation ein
 Place-Node gefunden wurde, werden dessen Koordinaten auch als Zentrum
 der Relation zurückgegeben, was praktisch immer zu besseren Ergebnissen
 führt, als der Mittelpunkt der Relation, der bisher verwendet wurde.

bin mal probeweise durch ein paar Landkreise durch und habe die Zuordnung 
vorgenommen; von Aach bis Zwönitz steht noch eine ganze Menge Arbeit an. :-)

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Offene Schranken

Hallo Ronnie,

Am Donnerstag, 6. September 2012, 08:09:45 schrieb Ronnie Soak:
 Auch ich gehe davon aus, dass das access Tag beschreibt, wer bei
 geschlossener Schranke passieren darf (bzw. das Recht hat, diese zu
 öffnen).

eine Schranke (bzw. jedes barrier=*) ist lediglich ein Mittel, um 
Beschränkungen punktuell zu forcieren. Ihre Funktion ist sie damit keine andere 
als die von einem Verkehrsschild, nur hat sie mehr Überzeugungskraft.
Genauso wenig würde man auf die Idee kommen, bei einem Wechselverkehrszeichen 
die Information bei angezeigten 60 muss im nachfolgenden Abschnitt 60 gefahren 
werden zu taggen - wir sind OpenStreetMap, nicht Wikipedia.
Wenn die Beschränkung, um die es geht, nicht vorher schon signalisiert wurde, 
existiert sie damit nur punktuell (nämlich genau an der Schranke). Aus diesem 
Grund wird access=* am Knoten getaggt.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Offene Schranken

Hallo Ronnie,

Am Donnerstag, 6. September 2012, 09:00:02 schrieb Ronnie Soak:
  eine Schranke (bzw. jedes barrier=*) ist lediglich ein Mittel, um 
  Beschränkungen punktuell zu forcieren. Ihre Funktion ist sie damit keine 
  andere als die von einem Verkehrsschild, nur hat sie mehr Überzeugungskraft.
  Genauso wenig würde man auf die Idee kommen, bei einem 
  Wechselverkehrszeichen die Information bei angezeigten 60 muss im 
  nachfolgenden Abschnitt 60 gefahren werden zu taggen - wir sind 
  OpenStreetMap, nicht Wikipedia.
  Wenn die Beschränkung, um die es geht, nicht vorher schon signalisiert 
  wurde, existiert sie damit nur punktuell (nämlich genau an der Schranke). 
  Aus diesem Grund wird access=* am Knoten getaggt.
 
 
 Die Analogie greift zu kurz. Die meisten Verkehrsschilder sind nun mal
 nicht 'mal da und mal weg'. Eine Schranke entspricht eher einem
 Verbotsschild, dass nur gelegentlich herausgestellt wird.

Deswegen habe ich auch Wechselverkehrszeichen untergebracht.

 Nicht umsonst gibt es inzwischen etliche Verfahren, Vorschläge und
 Diskussionen um z.B. zeitlich begrenzte Verbotsschilder (Fahrräder
 frei 18:00 - 9:00 Uhr), bedingte Schilder (120 bei Nässe) und
 dynamische Beschilderung (elektronische Anzeigen, Klappschilder) zu
 taggen. Sie alle kommen nicht nur mit dem access tag aus, sondern
 benötigen weitere Angaben.

Ich weiß, ich hab die Diskussion am Rande mitbekommen… ;-)

 Also nochmal: access=* am Knoten ist ja richtig, aber man müsste es je
 nach Zustand der Schranke mal so und mal so taggen. Beides passt nicht
 gleichzeitig in den selben Tag.

Doch, sicher.
Getaggt wird nicht das Verhalten der Schranke, sondern die Beschränkungen, die 
sich daraus ergeben. Wenn ein Autofahrer wissen will, ob er an einer bestimmten 
Stelle durchfahren kann, und du ihm sagst wenn die Schranke offen ist, ja, 
wenn sie zu ist, nein, kommt er sich leicht verschaukelt vor.

Es gibt einfach keinen Mehrwert von
wenn die Schranke offen ist, ja, wenn sie zu ist, nein, und offen ist die 
Schranke zwischen 6 und 20 Uhr, sonst geschlossen
gegenüber
zwischen 6 und 20 Uhr ja, sonst nein

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Offene Schranken

Hallo Ronnie,

Am Donnerstag, 6. September 2012, 09:31:29 schrieb Ronnie Soak:
  Getaggt wird nicht das Verhalten der Schranke, sondern die Beschränkungen, 
  die sich daraus ergeben. Wenn ein Autofahrer wissen will, ob er an einer 
  bestimmten Stelle durchfahren kann, und du ihm sagst wenn die Schranke 
  offen ist, ja, wenn sie zu ist, nein, kommt er sich leicht verschaukelt 
  vor.
 
 Ja. Nein.
 Genauer: Ja, wir taggen die Beschränkung. Nein, der Autofahrer kommt
 sich nicht verschaukelte vor. Betrachte doch mal nicht nur ein
 Verkehrsmittel. Der Radfahrer kommt zB. bei geschlossener und offener
 Schranke durch, der Autofahrer nur bei offener, der LKW-Fahrer weder
 bei offener noch bei geschlossener. Siehst du jetzt den
 Informationsgewinn?

Nein. Ich kann das genauso präzise so formulieren:
Der LKW-Fahrer kommt nie durch, der Autofahrer kommt zwischen 6 und 20 Uhr 
durch, der Fußgänger kommt immer durch.

 Die Aussagen beschreiben aber nicht die Bedeutung des bisher
 vorgeschlagenen access=yes.

Nach meinem Verständnis hat der access-Tag genau die gleiche Bedeutung, egal, 
ob er sich an einem Weg oder an einem Knoten befindet, nur sind bei einem 
Knoten die Auswirkungen nur punktuell. Den access-Tag an einer Schranke anders 
zu interpretieren, wäre ein erheblicher Bruch.

 1. Deine Aussagen musst du für alle Verkehrsmittel einzeln wiederholen
 (und natürlich anpassen)

Darum kommt man nie herum.

 2. Dass das zwischen 6 und 20 Uhr zwingend dazu gehört, mit einem
 simplen access=yes aber nicht abgedeck ist, ist gerade mein
 Standpunkt.

Natürlich ist zwischen 6 und 20 Uhr mit einem simplen access=yes nicht 
abgedeckt. Genauso wenig ist zwischen 6 und 20 Uhr aber auch mit wenn die 
Schranke offen ist abgedeckt.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Offene Schranken

Hallo Rainer,

Am Donnerstag, 6. September 2012, 11:25:55 schrieb Rainer Kluge:
 Es geht nur darum, wie man ihm mitteilt, dass normalerweise offen ist. Das 
 soll 
 und kann man nicht über access machen sondern über eine spezielles Tag wie 
 z.B.:
 
 barrier:closed=permanently|on_emergency|14:00-17:00|sunday|24.12-06.01

Es geht nicht darum, dass man dem Router mitteilt, dass die Schranke 
normalerweise offen ist. Es geht darum, dass man ihm mitteilt, dass man 
normalerweise durchfahren kann - und das ist access=yes.

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update von nominatim.osm.org

Hi,

Am Sonntag, 26. August 2012, 20:44:13 schrieb Sarah Hoffmann:
 Für das Erkennen von Duplikaten bei Grenzrelationen und Place-Nodes
 wertet Nominatim jetzt sowohl die Rolle 'label' als auch 'admin_centre'
 in den Grenzrelatioen aus, wobei Nodes mit 'admin_centre' nur zusammengefasst 
 werden, wenn Name und Admin-Level stimmen.

mir ist noch nicht ganz klar, wie das Zusammenfassen genau funktionieren soll.
Beispiel Augsburg:
Grenzrelation: http://nominatim.openstreetmap.org/details.php?place_id=148614123
Knoten: http://nominatim.openstreetmap.org/details.php?place_id=17722739

- der Knoten ist admin_centre der Grenzrelation
- beide heißen Augsburg
- die Grenzrelation hat Admin Level: 6, der Knoten hat Admin Level: 15 (gibt es 
doch gar nicht?)

Sollte der Knoten auch admin_level=6 getaggt werden?

Eckhart

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Offene Schranken