neu hinzugefügte Keys

Das halte ich auch für die beste Lösung.
Könnte man nicht WallE (hieß doch so?) wieder aktivieren, da wurden doch Tippfehler korrigiert?

Da ist aber, IMHO, das Problem das Vorlagen vor allem in JOSM nur umständlich zu nutzen sind, ev. was für GSOC 2018.

Eins der Probleme ist schlicht, dass sich der Stand der Presets zwischen den Editoren stark unterscheidet (siehe auch https://github.com/simonpoole/beautified-JOSM-preset/issues/27 im default preset von JOSM fehlen noch ein paar mehr). Der Effekt ist weniger ausgeprägt bei den wirklich häufig vorkommenden Objekten (Strassen etc), dort sind es eher irgendwelche Subtags, aber bei den Sachen die ein paar 1000 mal vorkommen oder seltener.

Zur Info: heute haben sich Potlatch und JOSM gleichberechtigt die Klinke in die Hand gegeben, iD war aber auch vertreten…

PS: und die heutige Version von website war webiste …

So, und wieder die Liste des heutigen Tages abgearbeitet. Mal gucken wie lange ich das durchhalte … pro Tag durchschnittlich ca. eine Stunde Aufwand :confused:

Was hast du denn jetzt gemacht? User per CS-Diskussion angefragt? Keys verbessert? oder beides?

gruss
walter

Guck doch mal bei pascal neis osm discussions :wink:
Ich maße mir nicht unbedingt an, die eventuellen Fehler zu verbessern - und mir somit ein Haufen weiterer osmose, keepright, und sonstiger QA Tools aufzuhalsen - Spaß beiseite, häufig frage ich auch nach, was denn der neue Key aussagt, wenn es sich nicht um einen reinen Typo handelt.

ADD: bzw. meine erzeugten Changeset Kommentare.

Da ich die letzten Tage einiges mit iD gemacht habe:
Eigentlich nutze ich die Presets nur selten.
Meistens die Autovervollständigung in den “unteren” Roh-Feldern, also bi warten cycle tab d warten esignated …

Das bringt mich auf die Idee, ob es evtl. ein Tool gibt / jemand schreiben könnte hüstel, dass die EIGENEN Keys (und values) auflistet. womöglich entdeckt man dabei auch manche nette Neukreation wie bi=d weil man wieder zu ungeduldig war … :wink:

Immerhin die Tage zum Ausmerzen eines key-value-Paares beigetragen in Vorbereitung auf die aktuelle session. Bei taginfo bicycle=use_cycleway statt use_sidepath entdeckt in einer Region, war offensichtlich nur ein einziger Autor vor rund einem Jahr, der das nach Anschreiben binnen weniger Stunden reparierte …
Dafür mache ich gerade einen Praxistest für einen neuen value … :wink:

So, und jetzt gibt es ein Problem, bei dem auch ich nicht mehr weiter weiß. Gleich der erste Eintrag in der Liste mit dem “Nichts”, und folgender OverpassQuery Abfrage:


[out:json];(node[""];way[""];>;rel[""];);out meta;

overpass meldet natürlich einen Fehler

was ja auch richtig ist. Wer kann helfen das Element mit dem “empty” String zu finden?

PS: Ich habe in meinen letzten Beitrag hier noch die Links zu osm discussions ergänzt.

Hier hilft die Doku im Wiki weiter:

node[~“^$”~“.”]; // find nodes with empty key (“”) and any value

Das Problem wurde aber zwischenzeitlich schon gefixt: http://www.openstreetmap.org/node/5104989386/history

wenn du mir das in Pseudo-SQL übersetzt, setze ich mal meine DB drauf an.

Gruss
walter

Danke walter, hat sich aber ja mit der Antwort von mmd schon erledigt :wink:

jo gesehen - aber zu spät.

hoppala, so ganz nebenbei sticht man dann halt auch mal ein pulverfass an :expressionless:

Harald wies mich heute (zu recht) auf zwei Schreibfehler hin… ok, der eine… da vergaß ich ein kleines e… geändert.

Das andere ist aber weitläufiger…

Da änderte ich gestern den Key von “de.boundary_name” nach “de:boundary_name” tausche also Punkt gegen Doppelpunkt. Harald wies mich im Changeset zurecht hin, daß es natürlich “boundary_name:de” heißen muß. Ich schaute also nochmal genauer und sah, daß in der Ersterfassung des Steines zwei verschiedene Mapper zugange waren, Radler59 mit drei und ich mit einem Stein… Daß ließ mich vermuten, daß da ein System dahinter steckte… und richtig…

Die ursprüngliche Schreibweise “de.boundary_name” findet sich mindestens Deutschlandweit…: http://overpass-turbo.eu/s/rL3

Ich halte das für die Folge einer fehlerhaften JOSM- Vorlage…

Übrigens “de.boundary_name” findet sich derzeit 694mal in der Datenbank https://taginfo.openstreetmap.org/keys/?key=de.boundary_name#overview

Von der Sache her müsste es in einem Rusch geändert werden, was aber dann unter sie entsprechenden Massenedit-Regelungen fallen würde…

[Edit]
Ich würde es auch machen… Soweit ich es überblicke betrifft es nur D und mit 35 Value-Varianten eine überschaubare Zahl, die auf Grund des Value-Inhaltes kaum Probleme machen dürften, oder?

Ich schreibe auch Lutz nochmal.
[/Edit]

Tja, Harald: kleine Ursache, große Wirkung… Danke für den Blickiges Auge. :slight_smile:

Sven

habe de.boundary_name nach boundary_name:de wie angekündigt, geändert.

Siehe: https://forum.openstreetmap.org/viewtopic.php?pid=664575#p664575

Sven

was ist denn an

[out:json];(node["оfficial_name"];way["оfficial_name"];>;rel["оfficial_name"];);out meta;

falsch? Ich seh’s nicht.

EDIT: hat sich gerade erledigt. Ich würde mal sagen hier im Gegensatz zu overpass sieht man das etwas andere “o” :smiley:

Kyrillische Buchstaben in Keys? Hier gibt’s mehr davon, dank dem tollen ICU-Prototyp! http://overpass-turbo.eu/s/rTi

Habe hier jemanden, der gerne methane statt methanol taggen möchte. Aber bei “Gasen” - außer meinen eigenen - bin ich raus :smiley:

Naja, da gibt’s ja unterschiedliche Ausprägungen von. Für Autos könnte das Biogas sein (fuel:biogas) oder Erdgas (dann wohl am ehesten als komprimiertes Erdgas - fuel:cng). Theoretisch gibt’s auch noch Flüssigerdgas (LNG), aber eher nicht für KFZ (deshalb wohl auch ohne definiertes fuel-Tag). Oder die verkaufen da ganz was Spezielles, wer weiß?