Re: [Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)
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
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)
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)
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)
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)
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)
Ü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)
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)
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
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