Qualitätssicherung

Blimp · 2016-02-05 10:06:26

fkv wrote:

geri-oc wrote:
In vielen Themen geht es um die Qualität der Daten. Es gibt hervorragende Tools zur Qualitätssicherung.
http://wiki.openstreetmap.org/wiki/Quality_assurance
Leider werden sie nicht angewandt.
Ich finde, sie werden viel zu viel angewandt. Ich würde mir mehr Mapper wünschen und weniger Datenpolizisten. Die meisten dieser vermeintlichen Korrekturen sind in Wahrheit Verschlimmbesserungen. Und fast immer läuft das ohne Absprache mit den ursprünglichen Mappern, die die eigentliche Arbeit gemacht haben.

Also das sehe ich zumindest mit Blick auf den Umkreis den ich überschauen kann eher wie geri-oc. Wenn die Karte voller Fehlersymbole ist, sollte sich das ändern.

Was meinst Du mit Verschlimmbesserungen? Und (warum) sollte man jede Ergänzung Korrektur mit dem ursprünglichen Mapper absprechen? Für mich als Anfänger wäre das schon sehr wichtig, wenn Du das näher erklären würdest.

Vielleicht schaut jeder einmal 2016 seinen Ort mit den Tools an ...
Wenn es der eigene Ort ist oder zumindest einer, wo man schon war, ok. Das Tückische an diesen Tools ist, dass man sich dann auch den Nachbarort anschaut usw., und manche Leute werden davon so süchtig, dass sie dann in ganz Mitteleuropa herumkorrigiereren ohne irgendeine Ahnung zu haben von dem, was sie tun.

Zum einen war der Aufruf so zu verstehen, dass sich jeder seinen Ort ansehen soll. Zum Anderen wird jeder seinen Ort individuell auslegen müssen. Ich kann jedenfalls nichtmals in ganz Dortmund alles mappen / korrigieren, weil der Ort einfach zu groß ist. Und ich war schon in Ecken, die der gemeine Dortmunder niemals kennen lernen wird
Darüber hinaus gibt es aber auch Fehler, für die braucht es keine Ortskenntnis. Ich hoffe sehr, dass keiner hinter mir her meine Anfängerfehler ausbügeln muss. Aber es gibt Fehler, die es massenhaft gibt und die man durchaus auch ohne Ortskenntnis reparieren kann, kreuzende unverbundene Linien etc. kann ich auch in Castrop-Rauxel fixen.

Aber ganz grundsätzlich bin ich in einem Punkt ganz bei dir: Aktuelle Ortskenntnis ist wohl durch nichts zu ersetzen.

dieterdreist · 2016-02-05 11:11:22

Vielleicht schaut jeder einmal 2016 seinen Ort mit den Tools an ...

Wenn es der eigene Ort ist oder zumindest einer, wo man schon war, ok. Das Tückische an diesen Tools ist, dass man sich dann auch den Nachbarort anschaut usw., und manche Leute werden davon so süchtig, dass sie dann in ganz Mitteleuropa herumkorrigiereren ohne irgendeine Ahnung zu haben von dem, was sie tun.

ich bin hier ganz bei meinen Vorrednern: bitte nur das korrigieren, was aus eigener Kenntnis (d.h. man ist kürzlich vor Ort gewesen) verbessert werden kann, und wo man sich sicher ist, was der Fehler ist. Tippfehler in tags zu korrigieren ist wichtig, aber tags die einem unüblich vorkommen zu "verbessern" ist oft problematisch, und sollte man m.E. erst nach Rücksprache mit dem Mapper tun. Nur weil die Tools derzeit ein bestimmtes tag nicht kennen heisst das noch lange nicht, dass das tag "falsch" ist. Luftbilder sind darüberhinaus grundsätzlich alt, livebilder gibt es derzeit AFAIK nirgendwo für OSM benutzbar. Scheinbar redundante tags zu entfernen ist eine weitere Sünde, die oft im Rahmen von solchen "Aufräumaktionen" begangen wird.

Blimp · 2016-02-05 11:23:58

Also wenn es so aussieht als hätte vor Jahren jemand so ein Vektornachmaldingsbums auf die örtlichen Kirchen losgelassen und Zwischen- und Nebengebäude, Gemeindehaus, Kindergärten vergessen, dann frage ich nicht nach, sondern korrigiere falls nötig die Gebäude und beschrifte von Grund auf neu, als wenn ich es selber angelegt hätte. Inkl. Öffnungszeiten des Gemeindebüros. Und wenn jemand vergessen hat Linien zu verbinden mache ich das mal eben.

gormo · 2016-02-05 11:47:03

Blimp wrote:

Also wenn es so aussieht als hätte vor Jahren jemand so ein Vektornachmaldingsbums auf die örtlichen Kirchen losgelassen und Zwischen- und Nebengebäude, Gemeindehaus, Kindergärten vergessen, dann frage ich nicht nach, sondern korrigiere falls nötig die Gebäude und beschrifte von Grund auf neu, als wenn ich es selber angelegt hätte. Inkl. Öffnungszeiten des Gemeindebüros. Und wenn jemand vergessen hat Linien zu verbinden mache ich das mal eben.

Bitte aber nicht rein sklavisch nach NRW-Atlas. Der ist auch an manchen Stellen nicht OTG-kompatibel. Mindestens nach Luftbild, besser noch nach vor-Ort-begehung.

fkv · 2016-02-05 11:58:19

Blimp wrote:

Also das sehe ich zumindest mit Blick auf den Umkreis den ich überschauen kann eher wie geri-oc. Wenn die Karte voller Fehlersymbole ist, sollte sich das ändern.

Manche gemeldeten Fehler sind keine Fehler. Beispielsweise die "touching inner rings" in OSMI. Man müsste den Validator ändern und nicht die Daten. Die Prüfung auf "duplicate tags on inner ring" ist eine nützliche Funktion, aber auch hier sind die Tags manchmal doch richtig (z.B. barrier=wall oder source:geometry=*). Viele Validatorbenutzer (und dazu gehören anscheinend auch die JOSM-Benutzer) sind sich dessen nicht bewusst, sie möchten die Karte sauber bekommen, wie in einem Computerspiel, wo Pacman alle Pillen fressen muss. Schockierender als die Rücksichtslosigkeit, die hier an den Tag gelegt wird, ist eigentlich das blinde Vertrauen, das selbst erfahrene User wie geri-oc, die es eigentlich besser wissen müssten, in die Software haben. Mir fällt dazu Napoleons Zitat ein, dass es kein leichtgläubigeres Volk als die Deutschen gibt.

Vorbildlich finde ich den in Keepright umgesetzte Funktion, "false positives" zu markieren. Leider wird sie viel zu wenig genutzt.

Was meinst Du mit Verschlimmbesserungen?

Eben z.B. dass durch "Korrektur" von touching inner rings sich die Anzahl der Ways und Relationen in einem Gebiet verfielfacht. Oder das hier schon angeschnittene Thema, dass Brücken eingezeichnet werden, die gar nicht existieren. Das macht die Daten nicht nur falscher als vorher, sondern auch die Fehler schwerer erkennbar. An manchen Stellen muss man sich weit übers Geländer beugen oder sogar durchs Gestrüpp um zu erkennen, ob es sich um ein Rohr, eine Brücke oder eine Kombination von beidem handelt. Das macht keiner, wenn eh schon eine Brücke eingezeichnet ist.

Lästig ist es auch, wenn "alte" Tags (z.B. type=* auf Bäumen oder power=sub_station wie gerade im anderen Thread besprochen) auf neue geändert werden und dabei Information verloren geht. Oder auch umgekehrt, wenn neue Tags, die der Validator noch nicht kennt, auf ähnliche Tags geändert werden, wie z.B. vor ein paar Jahren barrier=swing_gate auf barrier=lift_gate.

Weiters gibt es Leute, die den ganzen Tag nur Routing-Fixes machen und dabei je nach Lust und Laune Wege zusammenhängen oder noexit=yes setzen. Die Wahrscheinlichkeit, dass so eine Änderung stimmt, ist nicht mal 50%, denn es gibt in der Realität Fälle, wo der Weg aufhört und man trotzdem weitergehen kann.

Und (warum) sollte man jede Ergänzung Korrektur mit dem ursprünglichen Mapper absprechen? Für mich als Anfänger wäre das schon sehr wichtig, wenn Du das näher erklären würdest.

Erstens weil der ursprüngliche Mapper vielleicht einen guten Grund gehabt hat um es so zu mappen. Wenn das aber nicht der Fall ist, dann kommen wir zu zweitens, dass der Mapper es in Zukunft richtig macht. Einen Mapper zu überzeugen kann mehr Wirkung haben als tausend Datenfehler zu beheben.

Blimp · 2016-02-05 12:01:40

gormo wrote:

Blimp wrote:
Also wenn es so aussieht als hätte vor Jahren jemand so ein Vektornachmaldingsbums auf die örtlichen Kirchen losgelassen und Zwischen- und Nebengebäude, Gemeindehaus, Kindergärten vergessen, dann frage ich nicht nach, sondern korrigiere falls nötig die Gebäude und beschrifte von Grund auf neu, als wenn ich es selber angelegt hätte. Inkl. Öffnungszeiten des Gemeindebüros. Und wenn jemand vergessen hat Linien zu verbinden mache ich das mal eben.
Bitte aber nicht rein sklavisch nach NRW-Atlas. Der ist auch an manchen Stellen nicht OTG-kompatibel. Mindestens nach Luftbild, besser noch nach vor-Ort-begehung.

Nene, besser nicht. Ich nehme an Kirchen mit hunderten von Nodes für jede Verzierung stammen aus dem automatischen Nachmalen aus so was wie dem ALKIS ohne hinterher das Gebäude noch mal zu generalisieren. Ich finde ja es geht eh schneller so komplexe Bauten aus dem Luftbild abzumalen als hinterher hunderte überflüssige Nodes manuell zu löschen. Die Gebäudegrundform wird man eh immer nur ungefähr treffen ohne Grundrisszeichnung. Selbst wenn man den Dachüberhang nicht abziehen kann dürfte das immer noch am nahesten dran sein, oder?

Und es würde mich überraschen wenn es in Dortmund noch irgendwo eine christliche Kirche geben sollte in der ich noch nicht (mehrfach) gewesen bin...

seichter · 2016-02-05 12:30:54

Blimp wrote:

gormo wrote:
Blimp wrote:
Also wenn es so aussieht als hätte vor Jahren jemand so ein Vektornachmaldingsbums auf die örtlichen Kirchen losgelassen und Zwischen- und Nebengebäude, Gemeindehaus, Kindergärten vergessen, dann frage ich nicht nach, sondern korrigiere falls nötig die Gebäude und beschrifte von Grund auf neu, als wenn ich es selber angelegt hätte. Inkl. Öffnungszeiten des Gemeindebüros. Und wenn jemand vergessen hat Linien zu verbinden mache ich das mal eben.
Bitte aber nicht rein sklavisch nach NRW-Atlas. Der ist auch an manchen Stellen nicht OTG-kompatibel. Mindestens nach Luftbild, besser noch nach vor-Ort-begehung.
Nene, besser nicht. Ich nehme an Kirchen mit hunderten von Nodes für jede Verzierung stammen aus dem automatischen Nachmalen aus so was wie dem ALKIS ohne hinterher das Gebäude noch mal zu generalisieren. Ich finde ja es geht eh schneller so komplexe Bauten aus dem Luftbild abzumalen als hinterher hunderte überflüssige Nodes manuell zu löschen. Die Gebäudegrundform wird man eh immer nur ungefähr treffen ohne Grundrisszeichnung. Selbst wenn man den Dachüberhang nicht abziehen kann dürfte das immer noch am nahesten dran sein, oder?

Bei Kirchen speziell ist das Mappen des Grundrisses aus dem Luftbild schwierig, da es meist Schrägbilder sind und der Grundriss oft verdeckt ist. Da würde ich lieber den ALKIS-Grundriss generalisieren, wenn ich nicht jeden Gebäudevorsprung drin haben will.
Anm.: Es ist (fast) anerkannte Regel, dass bei Gebäuden der Grundriss am Boden eingetragen wird, nicht die Dachprojektion.

streckenkundler · 2016-02-05 13:26:29

Manche Beitragsbäume haben die Kunst, einen leiche aggressiven Ton zu entwickeln dieser ist so einer... Das Ansinnen von geri-oc ist richtig und auch gut formuliert:

geri-oc wrote:

Vielleicht schaut jeder einmal 2016 seinen Ort mit den Tools an ...

Hervorhebung von mir.

@ fkv Es geht nicht um eine landstrichweise Ausmerzung von Fehlern! Es geht auch nicht darum, so zu taggen, daß keine Fehler angezeigt werden. Auch um MP-Fehler gehr es nicht, das ist eine andere Baustelle, die im Nachbarbaum durchgekaut wird.

Keine Mapping-Anwendung ist fehlerfrei, weder JOSM, noch iD, noch Merkaartor oder andere, auch Fehlerprüftools sind nicht fehlerfrei, der Mapper selbst schon garnicht. Es gibt aber sicher genug Fehler oder vermeintliche Fehler, die es wert sind, nochmal angeschaut werden zu müssen. Jeder möge seinen Ort, seinen Hauptmappingbereich mit den Tools mal anschauen. Das sind die Orte, wo der Mapper seine Regionalkenntnisse hat und nicht um die Orte wo Pacman seine Pillen gefressen hat!

Sven

Blimp · 2016-02-05 14:25:58

seichter wrote:

Bei Kirchen speziell ist das Mappen des Grundrisses aus dem Luftbild schwierig, da es meist Schrägbilder sind und der Grundriss oft verdeckt ist. Da würde ich lieber den ALKIS-Grundriss generalisieren, wenn ich nicht jeden Gebäudevorsprung drin haben will.
Anm.: Es ist (fast) anerkannte Regel, dass bei Gebäuden der Grundriss am Boden eingetragen wird, nicht die Dachprojektion.

Ich seh auch zu, dass ich so nah wie möglich an die Grundrissform heran komme, der Anfänger fragt sich aber auch jedes mal: Wie genau soll es sein und ist es nötig? Meist habe ich Luftbild und ALKIS beides geladen und vergleiche wo es den Eindruck erweckt dass man es am besten erkennen kann. Das Abziehen des Daches ist am Anfang gar nicht so einfach. Hat der erfahrene Mapper da noch Tricks auf Lager ausser dem Vergleich mir ALKIS (wobei so was ja nicht überall vorhanden zu sein scheint)?

seichter · 2016-02-05 15:25:49

Blimp wrote:

seichter wrote:
Bei Kirchen speziell ist das Mappen des Grundrisses aus dem Luftbild schwierig, da es meist Schrägbilder sind und der Grundriss oft verdeckt ist. Da würde ich lieber den ALKIS-Grundriss generalisieren, wenn ich nicht jeden Gebäudevorsprung drin haben will.
Anm.: Es ist (fast) anerkannte Regel, dass bei Gebäuden der Grundriss am Boden eingetragen wird, nicht die Dachprojektion.
Ich seh auch zu, dass ich so nah wie möglich an die Grundrissform heran komme, der Anfänger fragt sich aber auch jedes mal: Wie genau soll es sein und ist es nötig? Meist habe ich Luftbild und ALKIS beides geladen und vergleiche wo es den Eindruck erweckt dass man es am besten erkennen kann. Das Abziehen des Daches ist am Anfang gar nicht so einfach. Hat der erfahrene Mapper da noch Tricks auf Lager ausser dem Vergleich mir ALKIS (wobei so was ja nicht überall vorhanden zu sein scheint)?

Ich glaube mich an ein Tutorial von Marek Kleciak zu diesem Thema zu erinnern, finde es aber im Moment nicht.
Wenn so etwas wie NRW-ALKIS vorhanden ist, sollte man das immer als Basis nehmen, denn die Georeferenzierung der Katasterdaten ist idR ausgezeichnet. Da die Daten aber oft relativ alt sind, sollte man immer Luftbilder (möglichst aktuell natürlich) mit zu Rate ziehen.

gormo · 2016-02-05 16:03:11

seichter wrote:

Anm.: Es ist (fast) anerkannte Regel, dass bei Gebäuden der Grundriss am Boden eingetragen wird, nicht die Dachprojektion.

Wenn ich aus dem Luftbild die Dachfläche erfasse (statt des Bodengrundrisses), und du dann für deine Auswertung meine erfasste Fläche als Grundriss interpretierst, dann haben wir insgesamt Lagefehler in der Größenordnung, wie wenn ich ganz genau die Gebäudeeckpunkte mit meinem Consumer-GPS (oder Smartphone) einmesse.

Mein GPS hat ~5m Genauigkeit in der Lage. An Gebäudewänden weniger, weil eine Seite des Himmels durch das Gebäude verdeckt ist, und die Wand Mehrwegeffekte auf das GPS-Signal gibt.

Mein angenommenes Abmalen der Dachfläche (nicht das das jemand falsch versteht: ich nehme auch so gut es geht die Grundrisse!) führt vermutlich nicht zu mehr als 5 Meter Abweichung zwischen der falschen Fläche und der Grundrissfläche.

Blimp · 2016-02-14 14:32:11

Hallo zusammen!

Bin gerade dabei ein paar Anfängerfehler hinter mir selber her aufzuräumen. Dabei fiel mir auf, dass Osmose überall wo POI's für Geschäfte etc. gemapped sind doppelte Adressen anmeckert. Dort sind Gebäude normal und vollständig gemapped mit allen addr=* Tags, ebenso die POI's. Bisher ging ich davon aus, dass beides vollständige Adressdaten bekommt, weil sonst die anderen QS-Tools unvollständige Adressdaten bemängeln. Was soll ich denn nun davon halten?

geri-oc · 2016-02-14 14:54:27

Entscheide selbst. Manchmal meckert Validator, Osmose, keep_rigth, OSMI (für mich umsonst).

"Falscher positiv" oder "korrigiert" klicken, wenn du sicher bist.

Last edited by geri-oc (2016-02-14 15:01:03)

seichter · 2016-02-14 15:12:58

Blimp wrote:

Hallo zusammen!
Bin gerade dabei ein paar Anfängerfehler hinter mir selber her aufzuräumen. Dabei fiel mir auf, dass Osmose überall wo POI's für Geschäfte etc. gemapped sind doppelte Adressen anmeckert. Dort sind Gebäude normal und vollständig gemapped mit allen addr=* Tags, ebenso die POI's. Bisher ging ich davon aus, dass beides vollständige Adressdaten bekommt, weil sonst die anderen QS-Tools unvollständige Adressdaten bemängeln. Was soll ich denn nun davon halten?

Die Mapper sind sich nicht einig, ob die volle Adresse an Umriss/Eingang und an die POI im Haus gesetzt werden sollen, die QS-Tools halt auch nicht.
Da bleibt nur ignorieren, wenn es der eigenen Ansicht nicht entspricht.

Blimp · 2016-02-16 12:39:33

seichter wrote:

Die Mapper sind sich nicht einig, ob die volle Adresse an Umriss/Eingang und an die POI im Haus gesetzt werden sollen, die QS-Tools halt auch nicht.
Da bleibt nur ignorieren, wenn es der eigenen Ansicht nicht entspricht.

Uneinigkeit wie in vielen Sachen... Aber zumindest bin ich nicht der einzige, der (anfangs) die Sache mit noexit auf dem Way falsch verstanden hat, meine Fehler habe ich (hoffentlich alle) hinter mir aufgeräumt und alles auf den letzen Node gesetzt.
Die Karte scheint aber voll davon zu sein... Ein erstes drüber schauen scheint aber auch zu zeigen, dass oftmals (gerade im urbanen Bereich ja fast immer) die noexit's gar keine (echten) sind, weil Sackgassen von denen man zumindest zu Fuß weiter kommt. Darauf muss ich meine eigenen wohl auch noch mal prüfen...

Das Thema wäre ja schon fast ein Kandidat für eine Wochenaufgabe...

firstAid · 2016-02-16 14:33:20

Und ganz oft sind die noexit's auch nicht auf der letzten Node des Weges, sondern am gesammten Weg welbst angebracht. Zumindest scheint das bei mir in der Umgebung beliebt zu sein.

+1 für Wochenaufgabe!

slint · 2016-02-16 15:10:59

In iD gibt's nicht so wirklich eine Unterstützung für noexit=yes, das ist ziemlich mühsam von Hand einzutragen

Chrysopras · 2016-02-16 15:55:00

Blimp wrote:

Aber zumindest bin ich nicht der einzige, der (anfangs) die Sache mit noexit auf dem Way falsch verstanden hat, meine Fehler habe ich (hoffentlich alle) hinter mir aufgeräumt und alles auf den letzen Node gesetzt.
Die Karte scheint aber voll davon zu sein... Ein erstes drüber schauen scheint aber auch zu zeigen, dass oftmals (gerade im urbanen Bereich ja fast immer) die noexit's gar keine (echten) sind, weil Sackgassen von denen man zumindest zu Fuß weiter kommt.

Ja, das ist ein verbreitetes Problem; auch hier (im Heilbronner Raum) gibt es eine Menge solcher falscher bzw. "suboptimaler" noexit=yes-Tags auf dem Weg. Ein Teil davon beruht wohl auf dem Missverständnis, noexit=yes bedeute dasselbe wie "Sackgasse" -- dabei ist noexit=yes etwas viel Spezielleres.

Blimp wrote:

Das Thema wäre ja schon fast ein Kandidat für eine Wochenaufgabe...

Schlag's doch vor.

firstAid · 2016-02-16 16:00:40

Das Problem ist aber speziell dabei auch...

Wenn man nach "Sackgasse osm" sucht... z.B. findet man dann bei Google genau diese noexit-Lösung (als Wiki-Talk).
Als dritter Link ist dann sogar ein hiesiger Forumströöt angegeben...
Wer sich da nicht noch genauer informiert, macht es schnell falsch.

Ich habe das selbst auch erstmal falsch verstanden.

P.S. Für das Wort "Sackgasse" gibt es auch keinen eigenen Wiki-Eintrag.

Last edited by firstAid (2016-02-16 16:01:34)

Blimp · 2016-02-16 16:11:20

Es braucht wohl ein Tag wie deadend=yes im Sinne des Straßenverkehrs um Sackgassen von "Hier-ist-Ende-für-alle-ausser-MacGyver" auseinander zu halten.

Habe es beim fixen erst mal so gemacht wie ich an einigen Stellen als "Krücke" gesehen habe: motor_vehicle=no + noexit=yes statt alles zu löschen. Lupenrein ist das aber auch nicht.

geri-oc · 2016-02-16 17:52:28

noexit=yes löschen?
Ist doch der einfachste Weg, wenn von einer residential nur noch ein footway mit bicycle=yes zum Wald geht. Und wenn gar nichts mehr geht ist eben "Ende".

(Sonst müsste es motor_vehicle:noexit=yes heißen. Ist eine Wendestelle eingezeichnet?)

Blimp · 2016-02-16 17:58:00

geri-oc wrote:

noexit=yes löschen?
Ist doch der einfachste Weg, wenn von einer residential nur noch ein footway mit bicycle=yes zum Wald geht. Und wenn gar nichts mehr geht ist eben "Ende".

Ich acker das gerade durch, bei etlichen Sackgassen mit Wendestelle und Durchlass für Fußgänger und so ist das noexit der Löschtaste zum Opfer gefallen.

(Sonst müsste es motor_vehicle:noexit=yes heißen. Ist eine Wendestelle eingezeichnet?)

Guter Hinweis, danke. Die "Krückennodes" sollten sich durch eine Overpass-Turbo abfrage finden lassen. Wieso fragst Du nach Wendestellen? Da sind natürlich etliche bei, manchmal sogar Wendeschleifen.

Blimp · 2016-02-17 09:15:04

Beim Aufräumen stellt sich die Frage, ob es die Systematik von noexit vorsieht, dass *jede(r)* Auffahrt, Parkplatzzufahrt, Parkplatzweg, Weg, kurzes Straßenstück das gemapped wurde allen Ernstes einen noexit Node am Ende bekommt? Da sind unzählige Ways wie z.B. auf Parkplätzen vier, fünf, sechs parking_aisle die vor dem Gebüsch enden am way mit noexit=yes getagged. Das wären ja Millionen Ways, wenn da überall ein noexit-Node dran müsste...

hurdygurdyman · 2016-02-17 09:59:01

"noexit=yes" ist für mich ein Relikt aus den Anfangszeit von OSM, als man noch nicht sicher sein könnte, dass Wege in ihrer Gesamtheit bis zur nächsten Anbindung erfasst waren. So wusste man: "Da musst du nicht gucken, ob es weiter geht. Das hat schon einer gemacht. Das Gegenteil war "FIXME=continue".

Heutzutage kann man "noexit=yes" in gut gemappten Gegenden weglassen, wenn man "on the ground" ermittelt hat, dass es da für nichts auf vorhandenen Wegen weiter geht (querfeldein durchs Gebüsch ausgenommen).

"FIXME=continue" sollte m.E. aber weiter verwendet werden, damit da mal einer schaut, wie und ob es weiter geht.

Für Router hat noexit sowieso keinen Bedeutung, weil die selber herausfinden sollten, ob man mit dem entsprechenden Fortbewegungsmittel da lang kann.

hfst · 2016-02-17 11:19:08

noexit=yes hilft Qualitätstools keine falschen Fehlermeldungen bei unverbundenen Wegen zu erzeugen.

Announcement

#51 2016-02-05 10:06:26

Re: Qualitätssicherung

#52 2016-02-05 11:11:22

Re: Qualitätssicherung

#53 2016-02-05 11:23:58

Re: Qualitätssicherung

#54 2016-02-05 11:47:03

Re: Qualitätssicherung

#55 2016-02-05 11:58:19

Re: Qualitätssicherung

#56 2016-02-05 12:01:40

Re: Qualitätssicherung

#57 2016-02-05 12:30:54

Re: Qualitätssicherung

#58 2016-02-05 13:26:29

Re: Qualitätssicherung

#59 2016-02-05 14:25:58

Re: Qualitätssicherung

#60 2016-02-05 15:25:49

Re: Qualitätssicherung

#61 2016-02-05 16:03:11

Re: Qualitätssicherung

#62 2016-02-14 14:32:11

Re: Qualitätssicherung

#63 2016-02-14 14:54:27

Re: Qualitätssicherung

#64 2016-02-14 15:12:58

Re: Qualitätssicherung

#65 2016-02-16 12:39:33

Re: Qualitätssicherung

#66 2016-02-16 14:33:20

Re: Qualitätssicherung

#67 2016-02-16 15:10:59

Re: Qualitätssicherung

#68 2016-02-16 15:55:00

Re: Qualitätssicherung

#69 2016-02-16 16:00:40

Re: Qualitätssicherung

#70 2016-02-16 16:11:20

Re: Qualitätssicherung

#71 2016-02-16 17:52:28

Re: Qualitätssicherung

#72 2016-02-16 17:58:00

Re: Qualitätssicherung

#73 2016-02-17 09:15:04

Re: Qualitätssicherung

#74 2016-02-17 09:59:01

Re: Qualitätssicherung

#75 2016-02-17 11:19:08

Re: Qualitätssicherung

Board footer