JOSM - Merkmalsvorschläge aus "interner Liste" entfernen [Erledigt]

Dank Euch. Ich setze den Status des Themas mal auf [Erledigt]

Danke in dem “Grau-Bereich” hätte ich kein Kontext-Menü erwartet :wink:

Ich habe dann dort in der Gegend mal noch etwas mehr herumgeklickt. Wenn man in der Vorschlagsliste direkt auf eine der zuletzt verwendeten Merkmalszuweisung klickt, dann bekommt man auch noch ein anderes Kontext-Menü. Dort habe ich mir die temporär störenden Merkmalsvorschläge (um mit Enter schön rasch durchklicken zu können) auf eine “Ignorier-Liste” gesetzt. Der Menüpunkt nennt sich “Ignoriere Schlüssel “direction””. Ich denke die Aktion erfüllt auch das was ich möchte…

Danke, die Datei habe ich gefunden samt des Text-Bereiches welcher sicherlich mit der Merkmal-Vorschlagsliste zu tun hat:
)
Habe aber noch nicht damit herumgespielt… Falls das andere zu unerwarten Effekten führt, werde ich das als Plan B testen…

Nebenbei, die Datei liegt bei Win7 unter: C:\Users*win_user_name*\AppData\Roaming\JOSM

https://josm.openstreetmap.de/wiki/Help/Preferences#Linux

Gut zu wissen … demnächst steht ein Umzug von 16.04.5 LTS auf 18.04.1 LTS an … muss ich also jetzt mehr als einen Ordner kopieren, kann dafür aber mein Backupskript vereinfachen und .cache wird eh schon auf die ramdisk verbannt :smiley:

Aha.

Danke und Gruß
walter

Ich würde gerne diverse tagging-vorschläge entsorgen, die nicht in der preferences stehen, sondern irgendwo voreingestellt sind.

Schönes nervendes Beispiel, was bestimmt jeder kennt:
addr:housename

Ich möchte bei “addr:h” housenumber vorgeschlagen bekommen.

Gibts da eine Lösung?

Eine einfache Lösung habe ich nicht, aber das Problem verschwindet ja, wenn erst mal addr:housenumber in der Liste der zuletzt verwendeten Tags steht. Diese Liste hat per default nur 5 Einträge, das kann man aber ändern:
properties.recently-added-tags 20
Achtung, damit wird auch der entsprechende Dialog recht lang, und mehr als 30 scheint - bei mir - nicht zu funktionieren.

Ich hab die Liste bereits auf 20, das bringt aber nichts, wenn man wild zwischen verschiedenen Objekten hin und hertaggt, dann ist die erwünschte Kombination schnell bei 21+.
housenumber war auch nur ein Beispiel, geht dann bei Adresse gleich direkt mit addr:street weiter. Und diverse andere, die immer wieder irgendwo auftauchen (willkürliche Beispiele):

building=h[angar] statt house
highway=b[ridleway] statt bus_stop
highway=p[assingway] statt path oder primary

usw. usf.

Für mich wäre der Königsweg, wenn ich alle Vorschläge von Tagging, was ich nie verwende, entweder nach hinten schieben könnte oder gar ganz löschen.

Dann müsstest Du wohl eine eigene Version von presets verwenden. Also alle eingestellten löschen und vielleicht dann eine sehr reduzierte eigene Version angeben. (Einstellungen → Karteneinstellungen → Reiter Objektvorlagen)

Das ist genau, was ich gesucht hab, danke.

Nochmal 'ne Frage dazu, möchte da kein Ticket aufmachen:
Wäre es nicht sinnvoll (bzw. ohne grossen Aufwand möglich) den Cache und die angezeigten Vorschläge zu trennen?
Also dass bspw. der Cache 50 oder 100 letzte Tags speichert, das letzte-Dingsi-fenster aber nur die letzten 20 oder 10 anzeigt?

Edit: mir fällt gerade mal wieder auf, dass geänderte Werte nicht in der letzte-Werte Liste auftaucht:
building=yes nach buildings=house ändern bspw.

Ja, die Liste merkt sich nur frisch gesetzte, keine bearbeiteten.

–ks

Ich schau mal danach, würde das aber ungern machen. Wenn Du einen Tippfehler reinbringst, z.B. surface=aspahlt, und der dann “irgendwo” wiederherkommt, sieht es genau so aus, als ob es eine Vorlage mit diesem Wert gäbe.
Und ja, dass eine Änderung nicht in die Liste übernommen wird, hat mich auch schon gestört. Insbesondere, wenn ich den o.g. Tippfehler korrigiere und dann doch wieder surface=aspahlt kommt. Dafür darfst Du gerne ein Ticket aufmachen :wink:

Wenn du einen Teppfihler aus den History-Vorschlägen löschen willst, geht das (im Tagging-Dialog) per Rechtsklick auf den betreffenden Eintrag.

–ks, sich gerade mal wieder darüber ärgernd, dass man im ICE keinen GPS-Empfang hat

Wenn ich den Code richtig verstanden habe, dann gibt es bereits zwei Limits.

  1. Anzahl der angezeigten (properties.recently-added-tags)
  2. Anzahl der gemerkten Eingaben. Diese Liste hat eine feste Länge von 30, Inhalt findet man in properties.recent-tags
    Der Wert 30 ist als Konstante MAX_LRU_TAGS_NUMBER definiert. Es wäre also einfach, den Wert höher zu setzen, zuletzt wurde er 2012 von 9 auf 30 erhöht. Warum der nicht zu konfigurieren ist, ist mir nicht klar, aber irgendeine feste Größe muss er haben, damit irgendwann was vergessen wird.

Ansonsten wird für die Automatische Vervollständigung auch noch die aktuell bearbeitete Datei verwendet. Wenn also z.B. in der Gegend irgendein Objekt das Tag source=Esri hat, dann wird nach Eingabe von E (nicht e) automatisch Esri vorgeschlagen, falls es nicht in den zuletzt eingegebenen Tags einen anderen Wert dafür gibt. Die Liste, die man mit “Pfeil runter” (cursor down) bekommt, ist ebenfalls eine Mixtur aus Presets, zuletzt eingegebenen und den in der Datei gefundenen Werten.

Im engl. ist die Überschrift “Recently added tags”, nicht “changed” oder “used”. Aber im Programmsource liest man auch recentTagsPanel, scheint also nicht unbedingt ein gewolltes Verhalten zu sein. Muss ich mir noch genauer anschauen…

Das scheint bei mir nicht zu funktionieren. Wo genau klickst Du da?

habe mal ein Ticket dazu aufgemacht: https://josm.openstreetmap.de/ticket/17333
Ich hoffe, das ist in Eurem Sinn?

Zumindest in meinem.

Hier:

–ks

Besserwisser an
Das entfernt aber nicht den Fehler sondern sorgt dafür, dass surface=* gar nicht mehr in die Liste kommt. Der mittlere Eintrag passt da besser.
So oder so ist das aber wenig intuitiv, weil man keine Wirkung im Dialog erkennt, bis man ihn schließt und wieder öffnet.
Ausserdem wird der falsche Werte weiterhin mit cursor down angezeigt.
Besserwisser aus
Mir fehlt da wirklich ein einfacher Weg, einen Fehler wieder los zu werden. Da werde ich mal ein weiteres Ticket aufmachen.

Was ich dabei nicht erwähnt habe: Die Fehlerprüfung in JOSM basiert auch auf diesen Objektvorlagen. Diverse Fehler werden nicht gefunden, wenn die entsprechenden Vorlagen fehlen.