Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)

2015-01-19 Diskussionsfäden Andreas Labres
On 19.01.15 18:06, Stefan Keller wrote:
 Am 19. Januar 2015 um 17:30 schrieb Andreas Labres l...@lab.at:
 * Irgendwie weiß man nicht, in welcher Sprache man grade mit dem Tool
 interagiert. Das sollte irgendwie leicht auswählbar sein.
 Rechts oben steht eine Flagge und Deutsch. Meintest du das?

Ja, offensichtlich habe ich das komplett übersehen! Ich denke, wenn ich die
Seite aufrufe, konzentriere ich mich unwillkürlich auf das Eingabefeld. Eine
Flagge hätte ich dort in der Nähe gesucht.

 * Die Ergebnisse sollten eine sinnvolle Reihenfolge haben, z.B. eine Suche 
 nach
 Arzt sollte das treffendste amenity=doctors *weit* vor dem /Fehler/
 amenity=doctor liefern!
 Es gibt eine Reihenfolge: Zuerst diejenigen Tags, in denen der
 Suchbegriff direkt im Key oder Value vorkommt.

Naja, grade der Suchbegriff Arzt zeigt, dass da grob das Falsche herauskommt!
Zu betonen wären Hits innerhalb der description des Templates (oder im
ersten Absatz oder in der category (wieder Hinweis auf Hierarchien).

Hier hätte unbedingt amenity=doctors der erste  hervorgehobene Treffer sein
müssen, das amenity=doctor (wie gesagt, ein bekannter Fehler) hätte man eher
verschweigen sollen (oder nur ganz unten unter ferner liefen anführen).
Vielleicht wäre das auch über das Wiki erlernbar (für die Software), wenn man
konsequent eine common errors Sektion einführt. Oder man macht im Wiki eine
Ausnahmen-Seite ein, wo solche Besonderheiten aufgeführt sind (z.B. mit
Einträgen der Art ignore amenity=doctor).

 Was sinnvoll bzw. richtig ist, kann fast nur ein Mensch entscheiden.

Nein. Wenn ein tag-Hit gefunden wird und dort doctor in der description
gefunden wird, ist das ein richtiger Tag.

Und auch bei der Unterscheidung: 'Es gibt zwei Hits, wo doctor in der Value
vorkommt (mal doctor, mal doctors), welcher ist der richtige?'
muss der Hit den Vorrang haben, zu dem es auch einen Tag-Eintrag im Wiki gibt!
Aber wie gesagt, mir scheint die description im Wiki wichtiger als die Value
eines Tags.

 Wie soll das System entscheiden, welche der 100% treffende Ergebnisse
 zu wählen ist?

Ähm, wo kommt auf den Wiki-Seiten
* Tag:sport=archery
* Tag:military=range
das Wort Praxis vor? Da kann ja nur irgendeine Fuzzy-Suche zugeschlagen haben,
das meinte ich mit: 100%ig ist ein übereinstimmender Hit, nix fuzzy.

 * Das Ding sollte Hierarchien verstehen und entsprechend anschaulich/leicht
 fasslich darstellen, z.B. eine Suche nach Wohnstraße findet ja richtig den 
 Tag
 highway=living_street und den Key highway, es sollte dem Nutzer aber auch 
 sofort
 klar sein, dass der Key der Überbegriff ist, der Tag das konkrete 
 (passende)
 Key/Value-Paar.
 Das ist ein sehr interessanter Aspekt:
 Nur schon wie wir solche Modellierungs-Dinge nennen sollten, ist mir unklar.

Ich stelle mir das so vor:

Wenn ich nach Wohnstraße suche, ist der passendste Hit:
DE:Tag:highway=living_street (übrigens würde ich mir einen Link auf die DE-Seite
wünschen, wenn Sprache Deutsch und die DE-Seite vorhanden). Und dann könnte man
die hierarchische Einordnung angeben, also DE:Key:highway, dann die
group/Gruppe (idF wieder Highway).

   Tag: highway=living_street
   +--- Key: highway=*
  +--- Gruppe: highway (also Straßen/Wege)

 Ich nehme an, du meinst Hierarchien im Sinne der OSM-Tags?
 Begriffshierarchien kennt der TagFinder über einen eigens erstellten
 Thesaurus (Bevorzugter Begriff, Überbegriff, Unterbegriff).
 Bei OSM ist es leider nicht immer so, dass der Key der Überbegriff ist
 (z.B. bei building=yes)...

   Tag: building=house
   +--- Key: building=*
  +--- Gruppe: Man made

Zusatztags, sind wieder ein eigenes Thema, da müßte man wohl erst eine
Hierarchie heraussuchen, also

   Key: maxspeed=*
   +--- Zusatztag zu Key: highway=*
  +--- Gruppe: highway (also Straßen/Wege)

oder

   Tag: cycleway=opposite lane
   +--- Key: cycleway=*
  +--- Zusatztag zu Key: highway=*
 +--- Gruppe: highway (also Straßen/Wege)

Übrigens wäre auch schön, wenn man leicht (z.B. durch unterschiedliches Layout)
erfassen könnte, was ein Key und was ein Value Eintrag ist.

/al


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


Re: [Talk-de] Abwesenheitsnotiz

2015-01-19 Diskussionsfäden mail
Sehr geehrte Damen und Herren,

vom 19.01. bis einschließlich 23.01.2015 befinde ich mich im Urlaub.
In dieser Zeit werden Ihre Mails nicht weitergeleitet.
In dringenden Fällen bin ich über mein Handy zu erreichen.


Mit freundlichen Grüßen

Martin Scholtes



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


Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)

2015-01-19 Diskussionsfäden Stefan Keller
Danke für die Tipps.

Wir haben tatsächlich die Infos aus dem Taginfo API entnommen. Ich
schaue mal, was sich machen lässt - nun auch im Taginfo Code.

@Michael: Klar ist klar, dass man Thumbnails nehmen sollte, falls vorhanden :-)
Wer's ganz ohne Bilder haben will, nutzt die TagFinder API.
Aber höchste Prio. hat das nicht, da es ja primär (Desktop) Webapp ist
und keine Mobile Webapp.
Vielmehr interessiert mich, ob die inhaltlichen Resultate und die
dargebotenen Infos des TagFinders den Erwartungen entsprechen...

LG, -S.




Am 19. Januar 2015 um 16:44 schrieb Jochen Topf joc...@remote.org:
 On Mo, Jan 19, 2015 at 04:31:48 +0100, Michael Kugelmann wrote:
 Am 18.01.2015 um 23:52 schrieb Stefan Keller:
 Am 18. Januar 2015 um 23:17 schrieb Joachim Kast osm...@dd1gj.de:
 Für die Thumbnail-Darstellung wird ein
 Bild von 1.704px × 2.272px und einer Größe von 1,8 MB heruntergeladen.
 Schmalband-Anbindungen machen da schlapp.
 Hmm, stimmt.
 Ist aber etwas schwierig für den Empfänger, das vorauszusehen :-) !??
 Grundsatz: Thumbnails sind klein zu halten = sollten nicht als das große
 Bild übertragen werden sondern eine andere Datei sein, ganz einfach.
 Typische Lösung könnte sein: Pfad zum Bild: xyz/datei.jpg Pfad zum
 Thumbnail: xyz/thumbnail/datei.jpg .   Solche Dinge sind IMHO eigentlich
 basics beim Gestalten von Tools oder Webseiten...

 Ich stimme Dir zu, dass klar sein sollte, dass man die Thumbnails verwendet.

 Aber leider ist das nicht so einfach mit dem Mediawiki. Man kann nicht einfach
 aus der Bild-URL die Thumbnail-URL berechnen. Das liegt daran, dass man Bilder
 aus Wikimedia Commons einbinden kann und da ist das alles etwas anders. 
 Details
 weiss ich auch nicht mehr genau, aber ich hab in Taginfo extra einbauen 
 müssen,
 dass er die Thumbnail-URL über die Wikimedia-API vom Server sich geben läßt,
 weil es nicht funktionierte nur die URL anzupassen.

 Jochen
 --
 Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-173-7019282

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

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


Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)

2015-01-19 Diskussionsfäden Michael Kugelmann

Am 18.01.2015 um 23:52 schrieb Stefan Keller:

Am 18. Januar 2015 um 23:17 schrieb Joachim Kast osm...@dd1gj.de:

Für die Thumbnail-Darstellung wird ein
Bild von 1.704px × 2.272px und einer Größe von 1,8 MB heruntergeladen.
Schmalband-Anbindungen machen da schlapp.

Hmm, stimmt.
Ist aber etwas schwierig für den Empfänger, das vorauszusehen :-) !??
Grundsatz: Thumbnails sind klein zu halten = sollten nicht als das 
große Bild übertragen werden sondern eine andere Datei sein, ganz einfach.
Typische Lösung könnte sein: Pfad zum Bild: xyz/datei.jpg Pfad zum 
Thumbnail: xyz/thumbnail/datei.jpg .   Solche Dinge sind IMHO eigentlich 
basics beim Gestalten von Tools oder Webseiten...



Grüße,
Michael.


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


Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)

2015-01-19 Diskussionsfäden Jochen Topf
On Mo, Jan 19, 2015 at 04:31:48 +0100, Michael Kugelmann wrote:
 Am 18.01.2015 um 23:52 schrieb Stefan Keller:
 Am 18. Januar 2015 um 23:17 schrieb Joachim Kast osm...@dd1gj.de:
 Für die Thumbnail-Darstellung wird ein
 Bild von 1.704px × 2.272px und einer Größe von 1,8 MB heruntergeladen.
 Schmalband-Anbindungen machen da schlapp.
 Hmm, stimmt.
 Ist aber etwas schwierig für den Empfänger, das vorauszusehen :-) !??
 Grundsatz: Thumbnails sind klein zu halten = sollten nicht als das große
 Bild übertragen werden sondern eine andere Datei sein, ganz einfach.
 Typische Lösung könnte sein: Pfad zum Bild: xyz/datei.jpg Pfad zum
 Thumbnail: xyz/thumbnail/datei.jpg .   Solche Dinge sind IMHO eigentlich
 basics beim Gestalten von Tools oder Webseiten...

Ich stimme Dir zu, dass klar sein sollte, dass man die Thumbnails verwendet.

Aber leider ist das nicht so einfach mit dem Mediawiki. Man kann nicht einfach
aus der Bild-URL die Thumbnail-URL berechnen. Das liegt daran, dass man Bilder
aus Wikimedia Commons einbinden kann und da ist das alles etwas anders. Details
weiss ich auch nicht mehr genau, aber ich hab in Taginfo extra einbauen müssen,
dass er die Thumbnail-URL über die Wikimedia-API vom Server sich geben läßt,
weil es nicht funktionierte nur die URL anzupassen.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-173-7019282

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


Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)

2015-01-19 Diskussionsfäden Andreas Labres
On 18.01.15 20:48, Stefan Keller wrote:
 Es freut mich, eine neue Webapp TagFinder vorzustellen. TagFinder
 ist eine Volltext-Suchmaschine für OpenStreetMap Tags

 http://tagfinder.herokuapp.com/

Gute Sache, danke!

Folgende Dinge sind mir aufgefallen:

* Irgendwie weiß man nicht, in welcher Sprache man grade mit dem Tool
interagiert. Das sollte irgendwie leicht auswählbar sein. Dementsprechend
ergeben sich eigenartige Suchergebnisse, z.B. auf der Suche nach Praxis findet
er bei weitem nicht alle Ärzte-Tags, anderseits aber auch sehr unpassende
Ergebnisse.

* Die Ergebnisse sollten eine sinnvolle Reihenfolge haben, z.B. eine Suche nach
Arzt sollte das treffendste amenity=doctors *weit* vor dem /Fehler/
amenity=doctor liefern! Letzteren sollte man wohl eher ausblenden, wenn es
mehrere 100% treffende Ergebnisse gibt.

* Das Ding sollte Hierarchien verstehen und entsprechend anschaulich/leicht
fasslich darstellen, z.B. eine Suche nach Wohnstraße findet ja richtig den Tag
highway=living_street und den Key highway, es sollte dem Nutzer aber auch sofort
klar sein, dass der Key der Überbegriff ist, der Tag das konkrete (passende)
Key/Value-Paar.

Servus, Andreas


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


Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)

2015-01-19 Diskussionsfäden Stefan Keller
Übrigens lässt sich TagFinder - wie übrigens Taginfo auch - als
Suchmaschine in die Suchleiste der meisten Browser einfügen
(OpenSearch-Standard)...

-S.

Am 19. Januar 2015 um 18:06 schrieb Stefan Keller sfkel...@gmail.com:
 Am 19. Januar 2015 um 17:30 schrieb Andreas Labres l...@lab.at:
 * Irgendwie weiß man nicht, in welcher Sprache man grade mit dem Tool
 interagiert. Das sollte irgendwie leicht auswählbar sein.

 Rechts oben steht eine Flagge und Deutsch. Meintest du das?

 * Die Ergebnisse sollten eine sinnvolle Reihenfolge haben, z.B. eine Suche 
 nach
 Arzt sollte das treffendste amenity=doctors *weit* vor dem /Fehler/
 amenity=doctor liefern!

 Es gibt eine Reihenfolge: Zuerst diejenigen Tags, in denen der
 Suchbegriff direkt im Key oder Value vorkommt.
 Danach fließt das Tag-Vorkommen ins Ranking ein.
 Das Beispiel mit doctor ist ein spezieller Fall (der natürlich auch
 wichtig ist).
 Was sinnvoll bzw. richtig ist, kann fast nur ein Mensch entscheiden.
 Aber ja: Mit den vielen falschen Positiven kämpfen wir noch.

 Letzteren sollte man wohl eher ausblenden, wenn es
 mehrere 100% treffende Ergebnisse gibt.

 Wie soll das System entscheiden, welche der 100% treffende Ergebnisse
 zu wählen ist?

 * Das Ding sollte Hierarchien verstehen und entsprechend anschaulich/leicht
 fasslich darstellen, z.B. eine Suche nach Wohnstraße findet ja richtig den 
 Tag
 highway=living_street und den Key highway, es sollte dem Nutzer aber auch 
 sofort
 klar sein, dass der Key der Überbegriff ist, der Tag das konkrete 
 (passende)
 Key/Value-Paar.

 Das ist ein sehr interessanter Aspekt:
 Nur schon wie wir solche Modellierungs-Dinge nennen sollten, ist mir unklar.
 Ich stelle mir so eine Art Haupt-Tag (= in der Modellierung
 Entitätsmengen-Namen genannt) vor mit Zusatz-Tags (=
 Entitätsmengen-Attribute).

 Ich nehme an, du meinst Hierarchien im Sinne der OSM-Tags?
 Begriffshierarchien kennt der TagFinder über einen eigens erstellten
 Thesaurus (Bevorzugter Begriff, Überbegriff, Unterbegriff).
 Bei OSM ist es leider nicht immer so, dass der Key der Überbegriff ist
 (z.B. bei building=yes)...

 LG, Stefan


 Am 19. Januar 2015 um 17:30 schrieb Andreas Labres l...@lab.at:
 On 18.01.15 20:48, Stefan Keller wrote:
 Es freut mich, eine neue Webapp TagFinder vorzustellen. TagFinder
 ist eine Volltext-Suchmaschine für OpenStreetMap Tags

 http://tagfinder.herokuapp.com/

 Gute Sache, danke!

 Folgende Dinge sind mir aufgefallen:

 * Irgendwie weiß man nicht, in welcher Sprache man grade mit dem Tool
 interagiert. Das sollte irgendwie leicht auswählbar sein. Dementsprechend
 ergeben sich eigenartige Suchergebnisse, z.B. auf der Suche nach Praxis 
 findet
 er bei weitem nicht alle Ärzte-Tags, anderseits aber auch sehr unpassende
 Ergebnisse.

 * Die Ergebnisse sollten eine sinnvolle Reihenfolge haben, z.B. eine Suche 
 nach
 Arzt sollte das treffendste amenity=doctors *weit* vor dem /Fehler/
 amenity=doctor liefern! Letzteren sollte man wohl eher ausblenden, wenn es
 mehrere 100% treffende Ergebnisse gibt.

 * Das Ding sollte Hierarchien verstehen und entsprechend anschaulich/leicht
 fasslich darstellen, z.B. eine Suche nach Wohnstraße findet ja richtig den 
 Tag
 highway=living_street und den Key highway, es sollte dem Nutzer aber auch 
 sofort
 klar sein, dass der Key der Überbegriff ist, der Tag das konkrete 
 (passende)
 Key/Value-Paar.

 Servus, Andreas


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

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


Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)

2015-01-19 Diskussionsfäden Andreas Goss

Related Terms:

Also soweit ich das sehe werden die aus irgendeinem Wörterbuch gezogen, 
oder?


z.B. wenn ich gym suche...
http://tagfinder.herokuapp.com/search?query=gymlang=en
...bekomme ich leisure=sports_centre und dort ist gym nicht angegeben. 
Das finde ich etwas unglücklich, da man bei OpenStreetMap oft sehr wert 
legt auf genaues Tagging und soetwas dann sehr irreführend sein könnte.


Fände es besser, wenn man auf die Wiki related terms zugreift und 
anzeigt und vielleicht him Hintergrund noch andere Datenbanken mit 
einbezieht.


PS @ all: Die richtige Wiki Syntax ist übrigens
{{RelatedTermList| {{RelatedTerm|Begriff1}} {{RelatedTerm|Begriff2}} 
{{RelatedTerm|Begriff3}} }}

und nicht nur die related term Klammern einzeln.
__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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


Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)

2015-01-19 Diskussionsfäden Stefan Keller
Am 19. Januar 2015 um 17:30 schrieb Andreas Labres l...@lab.at:
 * Irgendwie weiß man nicht, in welcher Sprache man grade mit dem Tool
 interagiert. Das sollte irgendwie leicht auswählbar sein.

Rechts oben steht eine Flagge und Deutsch. Meintest du das?

 * Die Ergebnisse sollten eine sinnvolle Reihenfolge haben, z.B. eine Suche 
 nach
 Arzt sollte das treffendste amenity=doctors *weit* vor dem /Fehler/
 amenity=doctor liefern!

Es gibt eine Reihenfolge: Zuerst diejenigen Tags, in denen der
Suchbegriff direkt im Key oder Value vorkommt.
Danach fließt das Tag-Vorkommen ins Ranking ein.
Das Beispiel mit doctor ist ein spezieller Fall (der natürlich auch
wichtig ist).
Was sinnvoll bzw. richtig ist, kann fast nur ein Mensch entscheiden.
Aber ja: Mit den vielen falschen Positiven kämpfen wir noch.

 Letzteren sollte man wohl eher ausblenden, wenn es
 mehrere 100% treffende Ergebnisse gibt.

Wie soll das System entscheiden, welche der 100% treffende Ergebnisse
zu wählen ist?

 * Das Ding sollte Hierarchien verstehen und entsprechend anschaulich/leicht
 fasslich darstellen, z.B. eine Suche nach Wohnstraße findet ja richtig den 
 Tag
 highway=living_street und den Key highway, es sollte dem Nutzer aber auch 
 sofort
 klar sein, dass der Key der Überbegriff ist, der Tag das konkrete (passende)
 Key/Value-Paar.

Das ist ein sehr interessanter Aspekt:
Nur schon wie wir solche Modellierungs-Dinge nennen sollten, ist mir unklar.
Ich stelle mir so eine Art Haupt-Tag (= in der Modellierung
Entitätsmengen-Namen genannt) vor mit Zusatz-Tags (=
Entitätsmengen-Attribute).

Ich nehme an, du meinst Hierarchien im Sinne der OSM-Tags?
Begriffshierarchien kennt der TagFinder über einen eigens erstellten
Thesaurus (Bevorzugter Begriff, Überbegriff, Unterbegriff).
Bei OSM ist es leider nicht immer so, dass der Key der Überbegriff ist
(z.B. bei building=yes)...

LG, Stefan


Am 19. Januar 2015 um 17:30 schrieb Andreas Labres l...@lab.at:
 On 18.01.15 20:48, Stefan Keller wrote:
 Es freut mich, eine neue Webapp TagFinder vorzustellen. TagFinder
 ist eine Volltext-Suchmaschine für OpenStreetMap Tags

 http://tagfinder.herokuapp.com/

 Gute Sache, danke!

 Folgende Dinge sind mir aufgefallen:

 * Irgendwie weiß man nicht, in welcher Sprache man grade mit dem Tool
 interagiert. Das sollte irgendwie leicht auswählbar sein. Dementsprechend
 ergeben sich eigenartige Suchergebnisse, z.B. auf der Suche nach Praxis 
 findet
 er bei weitem nicht alle Ärzte-Tags, anderseits aber auch sehr unpassende
 Ergebnisse.

 * Die Ergebnisse sollten eine sinnvolle Reihenfolge haben, z.B. eine Suche 
 nach
 Arzt sollte das treffendste amenity=doctors *weit* vor dem /Fehler/
 amenity=doctor liefern! Letzteren sollte man wohl eher ausblenden, wenn es
 mehrere 100% treffende Ergebnisse gibt.

 * Das Ding sollte Hierarchien verstehen und entsprechend anschaulich/leicht
 fasslich darstellen, z.B. eine Suche nach Wohnstraße findet ja richtig den 
 Tag
 highway=living_street und den Key highway, es sollte dem Nutzer aber auch 
 sofort
 klar sein, dass der Key der Überbegriff ist, der Tag das konkrete (passende)
 Key/Value-Paar.

 Servus, Andreas


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

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


Re: [Talk-de] Abwesenheitsnotiz

2015-01-19 Diskussionsfäden malenki
m...@martin-scholtes.de schrieb schon zweimal:

Sehr geehrte Damen und Herren,

vom 19.01. bis einschließlich 23.01.2015 befinde ich mich im Urlaub.
In dieser Zeit werden Ihre Mails nicht weitergeleitet.
In dringenden Fällen bin ich über mein Handy zu erreichen.

Mit freundlichen Grüßen

Martin Scholtes

Ist das eine wiederholte Einladung zur Facebook-Party in der
sturmfreien Bude?



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