Talk-de Digest, Vol 52, Issue 85

[Georg Verweyen]

Message: 9 Date: Sun, 14 Nov 2010 22:16:38 +0000 (UTC) From: Sven
charset=UTF-8
Ihr k?nntet mir mal einen Gefallen tun. Tagwatch frisst einen furchtbar
gro?en Anteil unserer Rechenzeit auf dem devserver. Gibt es noch
einen grund tagwatch weiterlaufen zu lassen oder ist taginfo ein
vollwertiger Ersatz.

Hallo Sven,

ich nutze das tagwatch noch intensiver, weil hier auch länderspezifische
Auswertungen möglich sind und auch Statistiken vorhanden sind, die in
taginfo noch nicht existieren. Ich wäre gegen eine entsprechende
Abschaltung.

MfG Georg V. (OSM=user_5359)

[Sven Geggus]

Post by Georg Verweyen
ich nutze das tagwatch noch intensiver, weil hier auch länderspezifische
Auswertungen möglich sind

@Jochen: Hast Du das auf der Todo-Liste?

Post by Georg Verweyen
und auch Statistiken vorhanden sind, die in taginfo noch nicht existieren.

Kannst Du das mal präzisieren?

Post by Georg Verweyen
Ich wäre gegen eine entsprechende Abschaltung.

Ich habe gar nicht vor das zeitnah abzuschalten sondern mittelfristig. Das
Problem bei Tagwatch ist dass es auf vollkommen ungeeigneter Technik
aufbaut. Meine Frage zielte daher gerade darauf welche Defizite ihr bei
taginfo noch seht, die ein abschalten von tagwatch immer noch verhindern.

Gruss

Sven

[Jochen Topf]

Post by Sven Geggus

Post by Georg Verweyen
ich nutze das tagwatch noch intensiver, weil hier auch länderspezifische
Auswertungen möglich sind

@Jochen: Hast Du das auf der Todo-Liste?

Nein. Generell ist es sehr aufwändig festzustellen, in welchem Land ein
OSM-Feature ist. Das würde den Aufwand massiv erhöhen.

Die Frage wäre jetzt: Wie wichtig ist diese länderspezifische Auswertung?
Was genau für Fragestellungen beantwortet das? Wozu werden die Infos benutzt?
Vielleicht läßt sich eine Lösung finden, die mit erträglichem Aufwand
umzusetzen ist.

Jochen

[Jochen Topf]

Post by Jochen Topf

Post by Sven Geggus

Post by Georg Verweyen
ich nutze das tagwatch noch intensiver, weil hier auch länderspezifische
Auswertungen möglich sind

@Jochen: Hast Du das auf der Todo-Liste?

Nein. Generell ist es sehr aufwändig festzustellen, in welchem Land ein
OSM-Feature ist. Das würde den Aufwand massiv erhöhen.
Die Frage wäre jetzt: Wie wichtig ist diese länderspezifische Auswertung?
Was genau für Fragestellungen beantwortet das? Wozu werden die Infos benutzt?
Vielleicht läßt sich eine Lösung finden, die mit erträglichem Aufwand
umzusetzen ist.

Was ich vergass zu sagen:

Grundsätzlich ist es natürlich schon jetzt möglich, Taginfo einfach mehrfach
laufen zu lassen mit verschiedenen Datenbank-Extrakten. Das wäre auch nicht
weiter schwierig. Tagwatch macht es, soviel ich weiss, auch nicht anders.

Aber das kostet natürlich mehr Rechenaufwand und integriert in irgendeiner
sinnvollen Form ist es dann nicht, man kann z.B. nicht die Daten verschiedener
Länder miteinander vergleichen.

Wenn das jemand machen will, dann kann er natürlich gerne den Taginfo-Source
nehmen und das machen. Ich will das selber aber ungerne anbieten, weil dann
erfahrungsgemäß alle drei Tage jemand kommt und sein Land auch noch haben will
oder sein Bundesland oder seine Insel. Und wir kommen wieder in die ganzen
Fragen rein, wo denn eigentlich die Grenze ist und wir haben verfälschte Daten,
weil die Relationen, die über die Grenze gehen nicht "richtig" aufgelöst wurden
usw.

Ich habe versucht mit der Karte, wo die Keys sind, so ein bischen die
Geographie mit zu berücksichtigen. Ich will das auch noch weiter ausbauen
auf Ways/Relations und auch für Values, sobald ich Zeit habe, mir zu überlegen,
wie das effizient gemacht werden kann. Aber das ergibt natürlich nicht so
viel Infos, wie man vielleicht gerne hätte.

Grundsätzlich haben alle diese Tools das Problem, dass wir die Daten
idealerweise in mehreren Dimensionen erfassen wollen:
* Über alle Typen von Objekten (Nodes, Ways, Relations, vielleicht auch weiter
unterteilt in Areas (geschlossene Ways) und spezielle Relation-Typen
* Zeitlich (Verlauf der Nutzung von Tags über die Zeit)
* Räumlich (ganze Welt, einzelne Länder, Regionen, usw.)

Das sind dann aber so viele Daten, dass man das nicht mehr schnell genug
hinbekommt. Man muss also irgendwo Kompromisse machen.

Jochen

[M∡rtin Koppenhoefer]

Post by Jochen Topf
Ich habe versucht mit der Karte, wo die Keys sind, so ein bischen die
Geographie mit zu berücksichtigen. Ich will das auch noch weiter ausbauen
auf Ways/Relations und auch für Values, sobald ich Zeit habe, mir zu überlegen,
wie das effizient gemacht werden kann.

ja, wenn bei der Suche auch Values berücksichtigt würden wäre das
nochmal ein Riesenschritt und würde einem immens dabei helfen, wenn
man ein bestimmtes (einem noch unbekanntes) Tag zu einem Feature
sucht, für das bisher noch nichts dokumentiert ist. Bisher muss man in
Taginfo schon eine grobe Ahnung haben, wo man suchen muss, und wenn es
dann eine Amenity ist, muss man ggf. zig Seiten durchbrowsen, um
festzustellen, dass es eben doch noch nichts gibt. Ich sehe die
Value-Suche mit Abstand als den wichtigsten Featurerequest (der
vermutlich auch auf Auswertungsseite am meisten Ressourcen schluckt).

Gruß Martin

[Frederik Ramm]

Hallo,

Post by M∡rtin Koppenhoefer
ja, wenn bei der Suche auch Values berücksichtigt würden wäre das
nochmal ein Riesenschritt

Stimmt,

Post by M∡rtin Koppenhoefer
und würde einem immens dabei helfen, wenn
man ein bestimmtes (einem noch unbekanntes) Tag zu einem Feature
sucht, für das bisher noch nichts dokumentiert ist. Bisher muss man in
Taginfo schon eine grobe Ahnung haben, wo man suchen muss, und wenn es
dann eine Amenity ist, muss man ggf. zig Seiten durchbrowsen,

stimmt nicht, denn es gibt ja immerhin, *wenn* du erstmal einen Key
ausgesucht hast, eine Suchfunktion in den Values (das Lupensymbol unten).

Bye
Frederik

[M∡rtin Koppenhoefer]

Post by Frederik Ramm

Post by M∡rtin Koppenhoefer
und würde einem immens dabei helfen, wenn
man ein bestimmtes (einem noch unbekanntes) Tag zu einem Feature
sucht, für das bisher noch nichts dokumentiert ist. Bisher muss man in
Taginfo schon eine grobe Ahnung haben, wo man suchen muss, und wenn es
dann eine Amenity ist, muss man ggf. zig Seiten durchbrowsen,

stimmt nicht, denn es gibt ja immerhin, *wenn* du erstmal einen Key
ausgesucht hast, eine Suchfunktion in den Values (das Lupensymbol unten).

Ooops, das habe ich jetzt erst gesehen das erleichtert einem
allerdings vieles :)
Evtl. könnte man da gleich ein bereits offenes Suchfeld draus machen?
Vermutlich haben das noch mehr übersehen...

Gruß Martin

[Tobias Knerr]

Post by M∡rtin Koppenhoefer

Post by Frederik Ramm
stimmt nicht, denn es gibt ja immerhin, *wenn* du erstmal einen Key
ausgesucht hast, eine Suchfunktion in den Values (das Lupensymbol unten).

Ooops, das habe ich jetzt erst gesehen das erleichtert einem
allerdings vieles :)
Evtl. könnte man da gleich ein bereits offenes Suchfeld draus machen?
Vermutlich haben das noch mehr übersehen...

+1, hab ich auch nicht entdeckt.

Tobias Knerr

[Ulf Lamping]

Post by Tobias Knerr

Post by M∡rtin Koppenhoefer

Post by Frederik Ramm
stimmt nicht, denn es gibt ja immerhin, *wenn* du erstmal einen Key
ausgesucht hast, eine Suchfunktion in den Values (das Lupensymbol unten).

Ooops, das habe ich jetzt erst gesehen das erleichtert einem
allerdings vieles :)
Evtl. könnte man da gleich ein bereits offenes Suchfeld draus machen?
Vermutlich haben das noch mehr übersehen...

+1, hab ich auch nicht entdeckt.

+ noch eins ;-)

Wäre es vielleicht möglich, das "Find Value" auf die Zeile "Values used
with this key" und dort ganz rechts auf die Seite (bzw. den Kasten) zu
setzen?



Zum Thema JOSM:

Das Scale min / max wird aktuell (und wohl auch in Zukunft) nicht
verwendet und daher könnte man die beiden Spalten sogar besser
rausnehmen, das es eher verwirren wird.


Ich hab zwar in letzter Zeit dran gearbeitet das die Vorlagen und
Presets sich annähern, aber da gibt es bestimmt noch genügend
Unterschiede - hast du mal überlegt das getrennt aufzunehmen? Man könnte
sich auch eine Spalte wie: "Nur im Style", "Nur in den Vorlagen", "In
Vorlagen und Style" vorstellen. Ich gehe nicht davon aus, daß die
Unterschiede zwischen Style und Vorlagen sich in Zukunft soweit
angleichen werden, daß "eine" Auswertung wirklich ausreicht. Dazu sind
beide "Aufgabenstellungen" zu unterschiedlich ...

Gruß, ULFL

[Jochen Topf]

Post by Ulf Lamping

Post by Tobias Knerr

Post by M∡rtin Koppenhoefer

Post by Frederik Ramm
stimmt nicht, denn es gibt ja immerhin, *wenn* du erstmal einen Key
ausgesucht hast, eine Suchfunktion in den Values (das Lupensymbol unten).

Ooops, das habe ich jetzt erst gesehen das erleichtert einem
allerdings vieles :)
Evtl. könnte man da gleich ein bereits offenes Suchfeld draus machen?
Vermutlich haben das noch mehr übersehen...

+1, hab ich auch nicht entdeckt.

+ noch eins ;-)
Wäre es vielleicht möglich, das "Find Value" auf die Zeile "Values used
with this key" und dort ganz rechts auf die Seite (bzw. den Kasten) zu
setzen?

Dieses Suchfeld ist an der versteckten Stelle, weil das die Flexigrid-Library,
die diese Tabellen baut, automatisch so macht. Das Ding da rauszunehmen,
bedeutet Extra-Arbeit. Ich werd mich jetzt erstmal auf die allgemeine Suche
konzentrieren und wenn die besser ist, dann wird vielleicht klarer, ob man
diese Suche innerhalb der Ergebnisse überhaupt noch braucht und wenn ja, wie
man das am besten darstellt.

Post by Ulf Lamping
Das Scale min / max wird aktuell (und wohl auch in Zukunft) nicht
verwendet und daher könnte man die beiden Spalten sogar besser
rausnehmen, das es eher verwirren wird.

Ah, das wusste ich nicht. Dann sollte das natürlich raus. Ich würde
vorschlagen, das dann auch aus dem elemstyles.xml zu entfernen.

Post by Ulf Lamping
Ich hab zwar in letzter Zeit dran gearbeitet das die Vorlagen und
Presets sich annähern, aber da gibt es bestimmt noch genügend
Unterschiede - hast du mal überlegt das getrennt aufzunehmen? Man könnte
sich auch eine Spalte wie: "Nur im Style", "Nur in den Vorlagen", "In
Vorlagen und Style" vorstellen. Ich gehe nicht davon aus, daß die
Unterschiede zwischen Style und Vorlagen sich in Zukunft soweit
angleichen werden, daß "eine" Auswertung wirklich ausreicht. Dazu sind
beide "Aufgabenstellungen" zu unterschiedlich ...

Sowohl Styles als auch Presets sollen in Taginfo rein. Dito für die anderen
Editoren. Leider sind diese Konfigurationen quasi garnicht dokumentiert, bzw.
die vorhandenen Dokus sind veraltet und es gibt keine aktuellen DTDs oder
Schema-Files. Daher ist es schwieriger als erwartet, diese Sachen einzubauen.
Es würde mir sehr helfen, wenn Leute, die sich damit auskennen, entsprechende
Dokus und Schemata schreiben.

Warum XML-Schemata? Mein Plan ist, dass der regelmäßige Import nach Taginfo
so abläuft:
* Konfigfiles des entsprechenden Programms aus SVN/Git auschecken.
* DTD oder XML-Schema aus dem Repository mit lokaler Kopie vergleichen. Wenn
sich was geändert hat, abbrechen und manuell überprüfen, ob Taginfo
angepasst werden muss.
* Konfig-Files gegen DTD oder XML-Schema checken, wenn die Files nicht valid
sind, dann abbrechen.
* Import der Daten nach Taginfo

Auf diese Art und Weise kann ich sicher sein, dass ich merke, wenn in einer
Quelle wichtige Änderungen vorgenommen werden.

Jochen

[Ulf Lamping]

Post by Jochen Topf
Dieses Suchfeld ist an der versteckten Stelle, weil das die Flexigrid-Library,
die diese Tabellen baut, automatisch so macht. Das Ding da rauszunehmen,
bedeutet Extra-Arbeit.

Ich hab's befürchtet ;-)

Post by Jochen Topf

Post by Ulf Lamping
Das Scale min / max wird aktuell (und wohl auch in Zukunft) nicht
verwendet und daher könnte man die beiden Spalten sogar besser
rausnehmen, das es eher verwirren wird.

Ah, das wusste ich nicht. Dann sollte das natürlich raus. Ich würde
vorschlagen, das dann auch aus dem elemstyles.xml zu entfernen.

Ich weiß, ich weiß, ...

Post by Jochen Topf
Sowohl Styles als auch Presets sollen in Taginfo rein. Dito für die anderen
Editoren. Leider sind diese Konfigurationen quasi garnicht dokumentiert, bzw.
die vorhandenen Dokus sind veraltet und es gibt keine aktuellen DTDs oder
Schema-Files. Daher ist es schwieriger als erwartet, diese Sachen einzubauen.
Es würde mir sehr helfen, wenn Leute, die sich damit auskennen, entsprechende
Dokus und Schemata schreiben.
Warum XML-Schemata? Mein Plan ist, dass der regelmäßige Import nach Taginfo
* Konfigfiles des entsprechenden Programms aus SVN/Git auschecken.
* DTD oder XML-Schema aus dem Repository mit lokaler Kopie vergleichen. Wenn
sich was geändert hat, abbrechen und manuell überprüfen, ob Taginfo
angepasst werden muss.
* Konfig-Files gegen DTD oder XML-Schema checken, wenn die Files nicht valid
sind, dann abbrechen.
* Import der Daten nach Taginfo
Auf diese Art und Weise kann ich sicher sein, dass ich merke, wenn in einer
Quelle wichtige Änderungen vorgenommen werden.

Nimm's mir nicht übel, aber das halte ich (zumindest aktuell) für eine
Illusion ;-)

Die bei JOSM geltenden Konventionen sind übrigens als Kommentarkopf
recht ordentlich (in Textform) beschrieben. Die Vorlagendatei findest du
unter:

http://josm.openstreetmap.de/browser/josm/trunk/data/defaultpresets.xml

Gruß, ULFL

[Jochen Topf]

Post by Ulf Lamping

Post by Jochen Topf
Warum XML-Schemata? Mein Plan ist, dass der regelmäßige Import nach Taginfo
* Konfigfiles des entsprechenden Programms aus SVN/Git auschecken.
* DTD oder XML-Schema aus dem Repository mit lokaler Kopie vergleichen. Wenn
sich was geändert hat, abbrechen und manuell überprüfen, ob Taginfo
angepasst werden muss.
* Konfig-Files gegen DTD oder XML-Schema checken, wenn die Files nicht valid
sind, dann abbrechen.
* Import der Daten nach Taginfo
Auf diese Art und Weise kann ich sicher sein, dass ich merke, wenn in einer
Quelle wichtige Änderungen vorgenommen werden.

Nimm's mir nicht übel, aber das halte ich (zumindest aktuell) für eine
Illusion ;-)

Was genau ist da die Illusion? Notfalls schreibe ich die DTDs oder XML-Schema
selbst, wenns kein anderer macht. Dauert dann halt länger. Aber mir fällt kein
besserer Weg ein, wie ich mit Änderungen, die nicht unter meiner Kontrolle
sind, zurecht kommen kann.

Jochen

[Frederik Ramm]

Hallo,

Post by Jochen Topf
Was genau ist da die Illusion? Notfalls schreibe ich die DTDs oder XML-Schema
selbst, wenns kein anderer macht. Dauert dann halt länger. Aber mir fällt kein
besserer Weg ein, wie ich mit Änderungen, die nicht unter meiner Kontrolle
sind, zurecht kommen kann.

Das Prinzip Google:

Noch ein bisschen warten, bis niemand mehr ohne Tagstat auskommt, und
dann sagen: Leute, wenn ihr wollt, dass euer cooler Editor hier eine
Spalte in diesem coolen Tagwatch bekommt, dann stellt Eure Daten bitte
in genau diesem Interchange-Format zur Verfuegung und macht einen Link
von dieser Wikiseite und mein Crawler frisst das automatisch.

In Nullkommanix haben wir jeden obskuren Editor mit aktiver Fangemeinde
drin ;)

Bye
Frederik

[Ulf Lamping]

Post by Jochen Topf
Was genau ist da die Illusion? Notfalls schreibe ich die DTDs oder XML-Schema
selbst, wenns kein anderer macht. Dauert dann halt länger. Aber mir fällt kein
besserer Weg ein, wie ich mit Änderungen, die nicht unter meiner Kontrolle
sind, zurecht kommen kann.

Über den klassischen OSM Weg: einfach so einbauen wie es gerade ist,
wenn es später nicht mehr geht und jemand mault nochmal hinschauen ;-)

Mit Illusion meinte ich nur, das du halt nicht drauf warten solltest,
das es jemand anderes macht. Wenn du das selber in die Hand nehmen
willst spricht natürlich nichts dagegen.

Gruß, ULFL

[Matthias Julius]

On Mon, 15 Nov 2010 10:55:57 +0100, M∡rtin Koppenhoefer

Post by M∡rtin Koppenhoefer

Post by Jochen Topf
Ich habe versucht mit der Karte, wo die Keys sind, so ein bischen die
Geographie mit zu berücksichtigen. Ich will das auch noch weiter ausbauen
auf Ways/Relations und auch für Values, sobald ich Zeit habe, mir zu überlegen,
wie das effizient gemacht werden kann.

ja, wenn bei der Suche auch Values berücksichtigt würden wäre das
nochmal ein Riesenschritt und würde einem immens dabei helfen, wenn
man ein bestimmtes (einem noch unbekanntes) Tag zu einem Feature
sucht, für das bisher noch nichts dokumentiert ist. Bisher muss man in
Taginfo schon eine grobe Ahnung haben, wo man suchen muss, und wenn es
dann eine Amenity ist, muss man ggf. zig Seiten durchbrowsen, um
festzustellen, dass es eben doch noch nichts gibt. Ich sehe die
Value-Suche mit Abstand als den wichtigsten Featurerequest (der
vermutlich auch auf Auswertungsseite am meisten Ressourcen schluckt).

Was ich auch noch lästig finde, ist der Umstand, dass Listen sich ihre
Sortierung und angezeigte Seite nicht merken. Wenn man z.B. einen
Listeneintrag angeklickt hat und dann im Browser auf die Zurück-Taste
drückt, wird die Liste wieder in ihrer Standardsortierung angezeigt und
steht ganz am Anfang. Man kann sich den Eintrag natürlich auch in einem
neuen Fenster/Tab anzeigen lassen, nur muss man daran auch denken.

Ich fände auch besser, wenn die Suchergebnisse in Tabellenform angezeigt
würden.

Matthias

[Sven Geggus]

Post by Jochen Topf
Nein. Generell ist es sehr aufwändig festzustellen, in welchem Land ein
OSM-Feature ist. Das würde den Aufwand massiv erhöhen.

AFAIK hat tagwatch eigentlich auch kein solches feature sondern importiert
einfach diverse Länder separat.

Gruss

Sven

[Tobias Knerr]

Post by Sven Geggus
Meine Frage zielte daher gerade darauf welche Defizite ihr bei
taginfo noch seht, die ein abschalten von tagwatch immer noch verhindern.

Taginfo-Seiten kann man nicht wirklich brauchbar ausdrucken oder auch
nur offline speichern. Da sind die Old-School-HTML-Tabellen von
Tagwatch doch wesentlich leichter handhabbar.

Da ich in der Vergangenheit schon z.B. bei Studienarbeiten tagwatch als
Datengrundlage für bestimmte Entscheidungen verwendet habe (und der zu
dem Zeitpunkt aktuelle Stand wegen der Flüchtigkeit der Seiten auch
dauerhaft dokumentiert werden sollte), schätze ich, dass der Bedarf
noch hin und wieder bestehen wird.

Tobias Knerr

[Frederik Ramm]

Hallo,

Post by Tobias Knerr
Da ich in der Vergangenheit schon z.B. bei Studienarbeiten tagwatch als
Datengrundlage für bestimmte Entscheidungen verwendet habe (und der zu
dem Zeitpunkt aktuelle Stand wegen der Flüchtigkeit der Seiten auch
dauerhaft dokumentiert werden sollte), schätze ich, dass der Bedarf
noch hin und wieder bestehen wird.

Wobei ich da aber sagen muss: Die Tagwatch-Skripte kann man ohne grosse
Installation auch lokal auf einen Extrakt loslassen, also wer das ganze
gerade eben nicht fluechtig und staendig aktuell, sondern nur mal eben
einmal braucht, der kann sich das auch flugs selber rechnen, oder?

Bye
Frederik

[Tobias Knerr]

Post by Frederik Ramm

Post by Tobias Knerr
Da ich in der Vergangenheit schon z.B. bei Studienarbeiten tagwatch als
Datengrundlage für bestimmte Entscheidungen verwendet habe (und der zu
dem Zeitpunkt aktuelle Stand wegen der Flüchtigkeit der Seiten auch
dauerhaft dokumentiert werden sollte), schätze ich, dass der Bedarf
noch hin und wieder bestehen wird.

Wobei ich da aber sagen muss: Die Tagwatch-Skripte kann man ohne grosse
Installation auch lokal auf einen Extrakt loslassen, also wer das ganze
gerade eben nicht fluechtig und staendig aktuell, sondern nur mal eben
einmal braucht, der kann sich das auch flugs selber rechnen, oder?

Das geht natürlich und ist in manchen Fällen ohnehin die bessere Lösung:
Gerade dort, wo die Statistiken einen inhaltlichen Kernbestandteil und
nicht nur eine Randnotiz darstellen.

Du wirst aber vermutlich zugeben, dass es noch einen Unterschied im
Aufwand zwischen diesem Vorschlag und Strg+S bzw. Strg+P gibt. ;)

Es ist kein Killerfeature, und deswegen muss Tagwatch sicher nicht extra
am Leben erhalten werden. Ein Vorteil von Tagwatch ist es aber in meinen
Augen schon, und deshalb wollte ich es mal erwähnt haben.

Tobias Knerr

[Jochen Topf]

Post by Frederik Ramm

Post by Tobias Knerr
Da ich in der Vergangenheit schon z.B. bei Studienarbeiten tagwatch als
Datengrundlage für bestimmte Entscheidungen verwendet habe (und der zu
dem Zeitpunkt aktuelle Stand wegen der Flüchtigkeit der Seiten auch
dauerhaft dokumentiert werden sollte), schätze ich, dass der Bedarf
noch hin und wieder bestehen wird.

Wobei ich da aber sagen muss: Die Tagwatch-Skripte kann man ohne grosse
Installation auch lokal auf einen Extrakt loslassen, also wer das ganze
gerade eben nicht fluechtig und staendig aktuell, sondern nur mal eben
einmal braucht, der kann sich das auch flugs selber rechnen, oder?

Oder man benutzt die API von Taginfo und schreibt sich einen Miniwrapper
drumrum, der die Daten ins gewünschte Format bringt. Vielleicht komme ich
ja sogar mal dazu, die API zu dokumentieren. :-)

Jochen