Re: [Talk-de] [talk-ch] FOSDEM Conference, 1+2 Feb. 2020, Brussels - Call for talks Geospatial (including OSM!)
FYI: Marc Vloemans schrieb auf Twitter gestern: Deadline CfP FOSDEM Geospatial DevRoom verlängert bis 7. December: Siehe https://penta.fosdem.org/submission/FOSDEM20 :Stefan [English] Marc Vloemans wrote on Twitter yesterday: Deadline CfP FOSDEM Geospatial DevRoom extended until December 7: See https://penta.fosdem.org/submission/FOSDEM20 :Stefan Am So., 1. Dez. 2019 um 18:06 Uhr schrieb Olivier Chatelain : > > PS: Wahrscheinlich geht es mit dem Zug an die FOSSGIS > (https://www.fossgis-konferenz.de/2020/), Freiburg i.B. liegt ja praktisch > vor der Tür. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSDEM Conference, 1+2 Feb. 2020, Brussels - Call for talks Geospatial (including OSM!)
Liebe alle (English below) Bevorstehende große Konferenz FOSDEM, 1+2 Feb. 2020, wie immer in Brüssel mit meinen Lieblings-"Devrooms" zu Python, PostgreSQL und Geospatial.: https://fosdem.org/2020/ . Siehe insbesondere den Devroom "Geospatial" und den Aufruf zu Talks (englisch) auch über OpenStreetMap bis So. 1. Dez. 2019 23.59 Uhr! https://lists.osgeo.org/pipermail/dutch/2019-October/001773.html . :Stefan [english] Upcoming big conference FOSDEM, 1+2 Feb. 2020, as always in Brussels with my favourite "devrooms" Python, PostgreSQL and Geospatial: https://fosdem.org/2020/ . See esp. the devroom "Geospatial" and it's call for talks also about OpenStreetMap until Su. 1st Dec. 2019 23.59! https://lists.osgeo.org/pipermail/dutch/2019-October/001773.html . :Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] "Ist ein Objekt aktuell? Am besten per URL. Mappen lohnt immer!" (Spruch des Monats)
Liebe Mapper Leider konnte ich dieses Jahr wieder nicht die FOSSGIS besuchen. Umso erfreulicher war, dass das FOSSGIS-Videoteam die Streams in Rekordzeit aufbereitet und hochgeladen hatte. Somit kann man via Programm [1] unter anderem auch Vorträge anschauen - wie denjenigen von Roland Olbricht zu "Wie aktuell sind OpenStreetMap-Daten?" [2]. Landläufig (und eigentlich einleuchtend) ist das Versionsalter eines Objekts ein Indiz dafür, dass dieses veraltet sein könnte. Doch, gemäss Roland's Untersuchungen ist das kein verlässliches Kriterium. Er schlägt dafür vor, URIs als externe Quellen zu verwenden. Denn wenn der POI verschwindet, verschwindet auch die Homepage. Viele POIs haben eine Website, wie namentlich im Key "website" [3] und vermehrt auch in Key "opening_hours:url" [4]. Sein Fazit: "Ist ein Objekt aktuell? Am besten per URL. Mappen? Lohnt immer!". Das ist für mich der Spruch des Monats März 2019 :-). :Stefan P.S. Apropos POIs: Mit OSMyBiz gibt es einen Editor, mit dem man einfach Geschäfte eintragen kann [5]. [1] Programm: https://www.fossgis-konferenz.de/2019/programm/ [2] Vortrags-Video und Folien: https://pretalx.com/fossgis2019/talk/ZTRDY9/ [3] Key "website": https://wiki.openstreetmap.org/wiki/DE:Key:website [4] Key "opening_hours:url": https://wiki.openstreetmap.org/wiki/DE:Key:opening_hours [5] OSMyBiz: https://osmybiz.osm.ch/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles Öffnungszeiten-Webtool
Lieber Harald Danke für's Feedback. Du hast geschrieben: > Wie geht ihr mit dem Thema PH (Feiertage) um? Wie meinst du das? Per default hängen wir (das Tool) das nicht hinten dran - dies auch wenn das Evaluation Tool [1] meckert und einen mit der Warnung geradezu dräng, PH einzutragent. > Und schon etwas gefunden: Ist notiert! :Stefan [1] https://openingh.openstreetmap.de/evaluation_tool/ Am Di., 19. Feb. 2019 um 20:47 Uhr schrieb Harald Hartmann : > > Und schon etwas gefunden: > Mo - Fr > 09:00 - 11:00 > Di > 14:00 - 16:00 > Do > 14:00 - 18:00 > Sa > 09:00 - 11:00 > > wird als > > Mo-Fr 09:00-11:00; Tu 14:00-16:00; Th 14:00-18:00; Sa 09:00-11:00 > > ausgegeben, sprich danach ist am Dienstag und Donnerstag nur Nachmittags > auf. Meiner Meinung nach, und des opening_hours evaluators, müsste hier > aber mit Komma getrennt werden: > > Mo-Fr 09:00-11:00, Tu 14:00-16:00, Th 14:00-18:00; Sa 09:00-11:00 > > > Am 19.02.19 um 20:37 schrieb Harald Hartmann: > > Wie geht ihr mit dem Thema PH (Feiertage) um? > > War/ist zumindest im deutschen Forum öfters mal das Thema... > > > > PS: Offensichtliche Fehler habe ich bisher nicht entdeckt, also mache > > ich mich mal auf die Suche nach versteckten Fehlern ;-) > > > > ___ > > 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Experimentelles Öffnungszeiten-Webtool
Liebe alle In meinem Lab "experimentieren" wir ja mit Software und zurzeit ist ein simples Öffnungszeiten-Webtool am Entstehen namens "Web to OSM Opening Hours" . Das Tool soll Tipp-Arbeit abnehmen und versucht die Öffnungszeiten einer Webseite die maschinenlesbare Form von opening_hours (OH) zu konvertieren. Fernziel ist u.a., den Tag "opening_hours:url" zu verwenden, um den dort verlinkten Webinhalt in opening_hours zu wandeln. Ein typischer Ablauf ist, dass man auf einer Webseite den Text zu den Öffnungszeiten mit der Maus auswählt und per Copy & Paste ins Textfeld des Webtools kopiert. Beispiel - Eingabe: Dienstag bis Freitag: 07:30 - 12:00 und 13:15 - 18:30 Uhr Samstag: 07:30 - 16:00 Der Output wäre hier "Tu-Fr 07:30-12:00,13:15-18:30; Sa 07:30-16:00". Zurzeit werden deutsch- und englisch-sprachige Eingaben unterstützt. Es gibt zwei unterschiedliche Implementationen: * A's Version https://codepen.io/AlejoFab/full/WLbBQr und v.a. * B's Version https://codepen.io/BSee/full/WLbLGW ! Feedback willkommen - hier oder als Issue im Repository! :Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass Abfrage
Hi,
> Am 28.01.2019 um 00:15 schrieb Christoph Grenz:
> > [out:csv(::lat, ::lon, name)];
Was ich mich schon lange frage bzw. wünsche ist, dass auch bei anderen
Output-Formaten als CSV (also den out settings xml,json,custom,popup)
die Rückgabe-Attribute eingeschränkt werden könnten.
Also z.B. so
[out:json(::lat, ::lon, name)];
Hab' grad nix in den Issues dazu gefunden.
Soll ich einen Issue machen auf [1]?
:Stefan
[1]
https://github.com/drolbr/Overpass-API/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+output
Am Mo., 28. Jan. 2019 um 00:19 Uhr schrieb Martin Scholtes
:
>
> Hallo Christoph,
>
> super danke für deine Antwort ;-)
>
> Am 28.01.2019 um 00:15 schrieb Christoph Grenz:
> > [out:csv(::lat, ::lon, name)];
> > (
> > node[amenity=nursing_home]({{bbox}});
> > way[amenity=nursing_home]({{bbox}});
> > relation[type=multipolygon][amenity=nursing_home]({{bbox}});
> > );
> > out center;
>
> --
> Mit freundlichen Grüßen
>
>
> Martin Scholtes
>
>
> ___
> 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] QGIS und OSM-Doku
Am Do., 20. Dez. 2018 um 20:29 Uhr schrieb Markus : > Wo finde ich ein aktuelles Dokument in Deutsch? Da empfehle ich QuickOSM. Eine kurze, deutschsprachige Anleitung gibt es auf meinem kleinen Projekt OpenSchoolMaps [1]: Siehe dort bei "Unterrichtsmaterialien" das Arbeitsblatt "OpenStreetMap-Daten beziehen und mit QGIS 3 nutzen". Gerne nehmen wir Verbesserungsvorschläge entgegen. Die aktuelle QGIS Version ist ja 3. In dessen Doku [2] ist das QuickOSM-Plugin auch beschrieben (halt englisch). :Stefan P.S. Welches veraltete OSM-Plugin meintest du genau? [1] https://openschoolmaps.ch [2] https://docs.qgis.org/testing/en/docs/training_manual/qgis_plugins/plugin_examples.html#basic-fa-the-quickosm-plugin Am Do., 20. Dez. 2018 um 20:29 Uhr schrieb Markus : > Liebe QGIS-Nutzer, > > Im Wiki finde ich unter: > https://wiki.openstreetmap.org/wiki/DE:QGIS-Tutorial > diesen Link zur Doku: > http://download.osgeo.org/qgis/doc/manual/qgis-1.8.0_user_guide_de.pdf > > Dort steht, dass es ein OSM-Plugin gibt (das aber laut QGIS nicht mehr > existiert), und dass QGIS wegen Inkompatibilitäten im Datenmodell nicht > wirklich mit OSM arbeiten kann. > > Da das Dokument über 5 Jahre alt ist, hat sich inzwischen vermutlich > viel getan... > > Wo finde ich ein aktuelles Dokument in Deutsch? > > Insbesondere interessiert mich Overpass-Integration. > Wie kann ich z.B. alle "harbour=*" (weltweit) einbinden? > So, dass ich einen zeitlich definierten Bestand anzeigen kann, und der > Rechner trotzdem nicht die Grätsche macht? > > Mit herzlichem Gruss, > Markus > > > ___ > 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
[Talk-de] OSM + Wikidata: Wikidata property proposal fuer eine OSM node ID
Liebe alle Es gibt auf talk-ch eine Diskussion über ein soeben erstelltes Wikidata property proposal: https://www.wikidata.org/wiki/Wikidata:Property_proposal/Authority_control#OSM_node_ID Dort wird vorgeschlagen, beim Wikidata-Projekt ein Property "OSM node ID" einzuführen. Obwohl klar ist, dass mangels Alternativen viele Dritt-Projekte OSM IDs verwenden, denke ich, dass das keine gute Idee ist für ein Projekt wie Wikidata, aus Gründen schon mehrmals diskutiert wurden. Ich schlage stattdessen vor, in Wikidata schlicht Koordinaten zu nutzen - wie bisher. Ob OSM "Permanent ID" bereits aus dem Experimentierstadium raus ist, ist mir unklar. :Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] WikiCon 2018, 5.-7. Oktober, St. Gallen (Schweiz)
Liebe alle Am 5.-7. Oktober, findet die WikiCon 2018 - das Treffen der Aktiven der deutschsprachigen Wikipedia und ihrer Schwesterprojekte - in St. Gallen (Schweiz) statt: https://de.wikipedia.org/wiki/Wikipedia:WikiCon_2018 . Auch die Swiss OpenStreetMap Association (SOSM) machen da voraussichtlich mit und ich habe soeben einen Stand-Vorschlag mit möglicher "Themeninsel" am WikiCon-Forum eingetragen: https://de.wikipedia.org/wiki/Wikipedia:WikiCon_2018/Forum_des_Freien_Wissens#Vorschl%C3%A4ge_f%C3%BCr_St%C3%A4nde . Ich kenne die WikiCon nicht; aber schon 2017 scheint es einen Stand gegeben zu haben. Jedenfalls gibt es offensichtlich genug Zeit und Raum für Workshops, Vorträge und Podiumsdiskussionen etc. Meine Fragen bzw. Aufforderungen dazu sind: 1. Wer war von OSM (bzw. verwandten Projekten) an der WikiCon 2017 bzw. kann von früheren Erfahrungen berichten? 2. Gibt es weitere Vorschläge und Ideen zur Themeninsel? Wir sind da offen (v.a. Wikivoage, WIWOSM). Dabei ist höchstens gut zu wissen, dass wir als SOSM uns dieses Jahr auf bestimmte Themen fokussieren wollen, namentlich das Projekt OpenSchoolMaps.ch und auf Tourismus/Reisen (inkl. Karten-Druck). 3. Wer kommt? Freiwillige, die am Stand oder sonstwie mithelfen wollen, melden sich bitte auf i...@osm.ch oder bei mir. Beste Grüsse, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dt. Kartenstil: Rendern von historic=fort
Am 1. März 2018 um 11:46 schrieb Christoph Hormann : > Zu den Vor- und Nachteilen abstrakter und weniger abstrakter Symbole > lassen sich viele Argumente finden. Bei internationalen Karten muss > man aber bei nicht abstrakten Symbolen für von Menschen gemachte Dinge > immer im Auge behalten, dass das was in einem Teil der Welt ein Ganz einverstanden mit beiden Hinweisen. Betreffend letzterem denke ich konkret z.B. an japanische Burgen, die tatsächlich sichtliche architektonische Unterschiede haben zu europäischen. Betreffend abstrakter und bildlich/ikonischer Symbole sind m.E. die Würfel im OSM Carto-Stil bereits zugunsten "bildlich/ikonisch" gefallen. Darum mein exemplarischer Hinweis auf Museum. :Stefan Am 1. März 2018 um 11:46 schrieb Christoph Hormann : > On Thursday 01 March 2018, Sven Geggus wrote: >> >> Es sind genau die Symbole, die auch schon im alten Shell Atlas (an >> den der dt. Stil angelehnt ist) für Burgen und Schlösser verwendet >> wurden. >> >> Das ist sowas ähnliches wie ein Standard in dt. Karten. Eventuell >> tatsächlich rein deutsch wie auch die Symbole für Laub und Nadelwald. > > Das Symbol wird traditionell aber nicht als Einzel-Symbol verwendet, > sondern eingebettet in eine Systematik von verschiedenen Symbolen wie > Kirche (Kreuz statt Fahne), Turm (nur ein Strich) und Windmühle > (Diagonalkreuz). > > Ich denk mal (aber das ist Spekulation) dass diese Symbole ihren > Ursprung in der Funktion derartiger Bauwerke als trigonometrische > Hochpunkte haben. > > Zu den Vor- und Nachteilen abstrakter und weniger abstrakter Symbole > lassen sich viele Argumente finden. Bei internationalen Karten muss > man aber bei nicht abstrakten Symbolen für von Menschen gemachte Dinge > immer im Auge behalten, dass das was in einem Teil der Welt ein > anschauliches repräsentatives Beispiel darstellt anderswo auf der Welt > recht wenig intuitiv oder gar irreführend sein kann. > > -- > Christoph Hormann > http://www.imagico.de/ > > ___ > 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] Dt. Kartenstil: Rendern von historic=fort
Liebe alle Die Symbole zu Burg/Ruine im aktuellen deutschen Stil sind mir etwas zu abstrakt und darum schlecht(er) (wieder-)erkennbar. Für meinen kartografischen Geschmack scheint mir das neue fort-Symbol im OSM Carto-Style nicht so schlecht und ich habe auch wenig Probleme mit Klischees und Playmobil :-). Das fort-Symbol könnte auch als Burg/Schloss-Symbol geeignet sein und passt vom Stil her m.E. z.B. auch gut zum aktuellen Museum [1]. Hingegen möchte ich Christoph Hormann's Hinweis voll und ganz unterstützen, dass - wenn schon - nicht historic=fort mit ~3000 Objekten, sondern castle mit 37628 und ruins mit 93057(!) Objekten gerendert werden sollten. Zu castle gibt es zwei(!) Issues (#744 #1176) und zu ruins einen (#331) und für beide habe ich relativ rasch einige Vorlagen gefunden [2][3]. Da sollten wir meines Erachtens ansetzen, denn Burgen (Schlösser?) und Ruinen prägen das Landschaftsbild sehr - egal auf welchem Kontinent und auch wenn es 10x weniger wären. Just my 2 cents. :Stefan [1] Museum: https://github.com/gravitystorm/openstreetmap-carto/blob/master/symbols/museum.svg [2] Castle: https://commons.wikimedia.org/wiki/File:Pictograma_Castillo.PNG [3] Ruine: https://commons.wikimedia.org/wiki/File:Symbole_carte_Belle_Ruine.svg Am 27. Februar 2018 um 13:02 schrieb Martin Koppenhoefer : > Am 24. Februar 2018 um 13:02 schrieb Sven Geggus < > li...@fuchsschwanzdomain.de>: > >> >> Die Symbole für Burgen und Schlösser im dt. Stil stammen aus ATKIS, sind >> also gar nicht mal so sehr auf Deutschland begrenzt. > > > > > wieso, wer ausser den Deutschen verwendet ebenfalls ATKIS? > > Gruß, > Martin > ___ > 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
[Talk-de] Open Source-Alternativen zu Minecraft mit OpenStreetMap?
Hallo zusammen, Hat jemand Erfahrungen a. mit dem Erzeugen von 3D-Blockwelten aus OSM für Minecraft - oder noch besser: für Open Source-Alternativen? Das Wiki [1] scheint mir da unvollständig. Habe Minetest [2][3] gefunden, wo aber kein OSM-Konverter erwähnt wird. LG, Stefan [1] https://wiki.openstreetmap.org/wiki/Minecraft [2] https://wiki.minetest.net/Minetest_in_der_Schule [3] "Minecraft-Alternative: Minetest und Mesecons für die informatische Bildung", Open Education Day 2017 https://openeducationday.ch/bisherige_events/ => https://www.ch-open.ch/wp-content/uploads/2017/01/11_Workshop-Ronny_Standtke.pdf ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Craftmapping
Am 4. Januar 2018 um 15:39 schrieb Frederik Ramm : > mich treibt seit einigen Monaten eine Idee um. Mir scheint, dass das > "Craftmapping" bei OSM und vorallem auch im "politischen" Bereich, der > OSMF, zunehmend unter den Tisch fällt. Ich hoffe nicht, dass Craftmapping unter den Tisch fällt. Andererseits sollte sich OSM nicht dem technischen Wandel verschliessen und muss ständig eine Balance finden. Ich finde es in jedem Falle gut, wenn innerhalb und ausserhalb von OSM die Bedeutung und der Nutzen davon mehr diskutiert werden. Eines der wichtigsten Merkmale von OSM sind ja eine aktive, grosse Community. Meine Ideen bzw. Beiträge dazu sind u.a. folgende: * Engagement im Tourismus zu dem OSM noch einiges mehr Beitragen kann. * Entwicklung von Softwares, die es noch einfacher machen, OSM zu bearbeiten und zu nutzen. * Dazu kommt die Organisation von Mapping Parties und ich hoffe, dass die geplante Directed Policy nicht die Freude daran dämpft :-). LG, Stefan Am 8. Januar 2018 um 09:59 schrieb markus schnalke : > [2018-01-08 07:46] Frederik Ramm >> On 07.01.2018 18:55, Mark Obrembalski wrote: >> > >> > Das spräche ja dafür, in einer Gegend, in der in Sachen Häuser noch >> > überhaupt nichts los ist, mal ein einzelnes Dorf zu mappen, in der >> > Hoffnung, dass die Bewohner der Nachbardörfer dann auch Häuser auf der >> > Karte wollen ;-) > > Durchaus! ;-) > >> Das gabs schon immer, wir haben das früher "Guerilla Mapping" genannt - >> mehr so die Idee, dass man mal in einer fremden Stadt einen Häuserblock >> supertoll mappt mit allen POIs und Ampeln und so weiter, um den Mappern >> vor Ort zu signalisieren, dass sie sich noch nicht auf dem Erreichten >> ausruhen können ;) > > Das ist auch fuer Anfaenger hilfreich, weil man dadurch viel > Inspiration und Hilfestellung bekommt. Man muss es dann naemlich nur > noch nachmachen. > > > meillo > > ___ > 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] von QGIS auf hstore Spalte in postgres Datenbank zugreifen
Ja; das geht mit QGIS 3 "nativ" als "Expression". Für QGIS 2.x habe ich eine Funktion geschrieben und diese sollte eigentlich mit diesem Plugin http://plugins.qgis.org/plugins/qgsexpressionsplus/ einfach installierbar sein. Offenbar hat da aber jemand vergessen, einen neuen Release zu machen... (ich habe nachgehakt). Inzwischen hier der Code: https://github.com/NathanW2/qgsexpressionsplus/blob/master/hstore_get_value.py LG, Stefan Am 7. Dezember 2017 um 17:06 schrieb Walter Nordmann : > manchmal (also bei bestimmten Abfragen) kann man tags->'key' verwenden, > manchmal geht (tags->'key') aber oft hilft wirklich nur ein View. > > und das schwankt sogar von release zu release. :( > > gruss > walter > > Am 07.12.2017 um 15:59 schrieb Martin Koppenhoefer: >> >> weiss jemand, wie man von QGIS aus auf hstore Werte zugreifen kann >> (osm2pgsql hstore). >> Wahrscheinlich muss man irgendwie eine virtuelle Spalte anlegen, auf die >> man dann zugreifen kann? >> >> Z.B. >> tags -> 'station' aus planet_osm_point >> >> wie kann ich eine virtuelle Spalte machen, so dass ich auf "station" in >> planet_osm_point zugreifen kann, als ob es die Spalte gäbe (obwohl das nur >> in "tags" als hstore gespeichert ist)? >> >> Vielen Dank, >> Gruß, >> Martin >> ___ >> 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF-Vorstandswahlen 2017
+1 :Stefan Am 6. Dezember 2017 um 13:35 schrieb Michael Reichert : > Hallo, > > ich habe gestern Abend im deutschen OSM-Blog einen längeren Beitrag über > die Kandidaten der diesjährigen Wahlen zum Vorstand der OSMF veröffentlicht. > > https://blog.openstreetmap.de/blog/2017/12/wahlen-zum-vorstand-der-openstreetmap-foundation-2017-teil-1/ > > In dem verlinkten ersten Teil fasse ich die Wahlprogramme, die Antworten > auf Wählerfragen sowie die Kritiker zusammen. Teil 2 des Beitrags ist > noch nicht fertig und passiert heute Abend hoffentlich die > Rechtschreibkontrolle [1]. > > Wer OSMF-Mitglied ist und es 30 Tage vor der Mitgliederversammlung am > Samstagnachmittag schon war, der möge bitte seine Stimme abgeben. Jede > Stimme zählt! Ja, wirklich! Es gibt Kandidaten, die z.B. fordern, dass > Community-Manager eingesetzt werden. Allein der Begriff passt gar nicht > zu OSM. Ich will keinen Chef, der mir in meinem Hobby sagt, was ich tun > soll. In einem unfreien Community-Projekt wie Foursquare mag es > angemessen sein, da man dort die Community bei Laune halten muss. OSM > sollte aber kein hierarchisches Projekt werden. Mehr dazu in Teil 2. > > Viele Grüße > > Michael > > > [1] Wer sich als einmaliger Lektor melden möchte, ohne sich zu > irgendeiner Wochennotiz-Mitarbeit zu verpflichten, kann sich einfach bei > mir per Mail melden. > > -- > Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten > ausgenommen) > I prefer GPG encryption of emails. (does not apply on mailing lists) > > > ___ > 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] Projekt zur Toilettensuche
Ich habe geschrieben: > Diese Daten könntest du dann validieren und in OSM einpflegen (wobei > mir grad unklar ist, ob nur der uMap-Admin an die Daten kommt). Unter "Embed and share this map" (Share-Button links) gibt es "Download Data" als GeoJSON. :Stefan Am 13. Juni 2017 um 20:08 schrieb Stefan Keller : > Es gibt mit #CHFreeWiFi ein Projekt in der Schweiz das passen könnte. > > Das funktioniert auf der Basis von uMap, bei dem Leute anonym Access > Points eintragen können: > https://twitter.com/CHFreeWiFi/status/852589100616081409 > http://umap.osm.ch/en/map/chfreewifi_588#9/47.0870/8.6627 > > uMap gibt's auch weltweit, wobei die BBox auf Deutschland > eingeschränkt werden kann: > https://umap.openstreetmap.fr/de/ > > Die Daten (beim #CHFreeWiFi ein Projekt Name, Description und > natürlich die Koordinate) landen zunächst in uMap. > Diese Daten könntest du dann validieren und in OSM einpflegen (wobei > mir grad unklar ist, ob nur der uMap-Admin an die Daten kommt). > > Du könntest die Daten auch MapRoulette übergeben, damit andere > mithelfen können, wenn es zu viele werden: > https://github.com/maproulette/maproulette2/wiki > > :Stefan > > Am 26. Mai 2017 um 18:12 schrieb Viktor : >> Hallo, >> >>> ich habe an einem Projekt für ältere Menschen gearbeitet >> >> >> Das Projekt klingt ganz interessant! >> >> >> In welcher Weise werden eigentlich bei OSM Änderungen validiert und ggf. >> verifiziert? Gibt doch sicherlich auch viel Spaminput. >> >> Viele Grüße >> Viktor >> >> >> Am 2017-05-26 10:50, schrieb Günther Meyer: >>> >>> Hallo, >>> >>> ich habe an einem Projekt für ältere Menschen gearbeitet. Die >>> Toiletten werden in der Karte angezeigt. Man kann sie in der Karte >>> anklicken. Dann werden Details angezeigt. Die Details waren zunächst >>> nur Die Knoten-Id und die Koordinaten. Das hat den älteren Menschen >>> nicht geholfen. >>> >>> Ich habe in unserem Gebiet zu jeder Toilette die Adresse hinzugefügt, >>> falls das sinnvoll war (es gibt auch Ausnahmen). Unter description=* >>> habe ich einen kurzen Hinweis eingefügt wie z.B. Gaststätte oder >>> Aral-Tankstelle. Die "Netten Toiletten" habe ich mit folgendem Tag >>> versehen: network=nette_toilette. >>> >>> Gruß gm-bremen >>> >>> >>> Am 25.05.2017 um 22:57 schrieb Viktor: >>>> >>>> Hallo, >>>> >>>> ich bin seit Jahren begeisterter Nutzer der OpenStreetMap und kannte >>>> schon von Wikipedia und Wikidata das Prinzip der freien, semantischen >>>> Datenbanken und -quellen. >>>> >>>> Hieraus entwickelte sich vor einiger Zeit ein Projekt namens "WinilooC" >>>> zur Entwicklung einer anwenderfreundlichen Suche für öffentliche Toiletten. >>>> Da der Tag "amenity=toilets" weltweit etwa 170.000 Mal verwendet wird und >>>> OSM über Overpass ziemlich elegant genutzt werden kann, bot es sich perfekt >>>> als Datenquelle an. >>>> In der Karte sollen die Toiletten übersichtlich und unterscheidbar >>>> dargestellt werden, sodass sich z.B. kostenpflichtige von frei zugänglichen >>>> auf einen Blick unterscheiden lassen können. >>>> Darüber hinaus können zukünftig weitere Eigenschaften von den Objekten in >>>> der Karte angezeigt werden. >>>> >>>> Ein Ziel meines Projektes ist es, dass Nutzer einfach Änderungen in die >>>> Karte einbringen können. Dabei denke ich von Anfang an auch daran, dass ein >>>> nachhaltiger Nutzen für das OSM-Projekt durch den Rückfluss von Daten >>>> erfolgen kann. >>>> >>>> Für Hinweise oder Überlegungen zur Gestaltung des Datenrückflusses über >>>> die APIs zur OSM bin ich sehr offen. >>>> >>>> Einen Artikel zum Projekt habe ich bereits in meinem Blog unter [1] >>>> veröffentlicht. >>>> >>>> Viele Grüße >>>> Viktor >>>> >>>> [1] https://blog.v-gar.de/2017/05/projektankuendigung-winilooc/ >>>> >>>> ___ >>>> Talk-de mailing list >>>> Talk-de@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-de >>> >>> >>> >>> --- >>> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. >>> https://www.avast.com/antivirus >>> >>> >>> ___ >>> 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt zur Toilettensuche
Es gibt mit #CHFreeWiFi ein Projekt in der Schweiz das passen könnte. Das funktioniert auf der Basis von uMap, bei dem Leute anonym Access Points eintragen können: https://twitter.com/CHFreeWiFi/status/852589100616081409 http://umap.osm.ch/en/map/chfreewifi_588#9/47.0870/8.6627 uMap gibt's auch weltweit, wobei die BBox auf Deutschland eingeschränkt werden kann: https://umap.openstreetmap.fr/de/ Die Daten (beim #CHFreeWiFi ein Projekt Name, Description und natürlich die Koordinate) landen zunächst in uMap. Diese Daten könntest du dann validieren und in OSM einpflegen (wobei mir grad unklar ist, ob nur der uMap-Admin an die Daten kommt). Du könntest die Daten auch MapRoulette übergeben, damit andere mithelfen können, wenn es zu viele werden: https://github.com/maproulette/maproulette2/wiki :Stefan Am 26. Mai 2017 um 18:12 schrieb Viktor : > Hallo, > >> ich habe an einem Projekt für ältere Menschen gearbeitet > > > Das Projekt klingt ganz interessant! > > > In welcher Weise werden eigentlich bei OSM Änderungen validiert und ggf. > verifiziert? Gibt doch sicherlich auch viel Spaminput. > > Viele Grüße > Viktor > > > Am 2017-05-26 10:50, schrieb Günther Meyer: >> >> Hallo, >> >> ich habe an einem Projekt für ältere Menschen gearbeitet. Die >> Toiletten werden in der Karte angezeigt. Man kann sie in der Karte >> anklicken. Dann werden Details angezeigt. Die Details waren zunächst >> nur Die Knoten-Id und die Koordinaten. Das hat den älteren Menschen >> nicht geholfen. >> >> Ich habe in unserem Gebiet zu jeder Toilette die Adresse hinzugefügt, >> falls das sinnvoll war (es gibt auch Ausnahmen). Unter description=* >> habe ich einen kurzen Hinweis eingefügt wie z.B. Gaststätte oder >> Aral-Tankstelle. Die "Netten Toiletten" habe ich mit folgendem Tag >> versehen: network=nette_toilette. >> >> Gruß gm-bremen >> >> >> Am 25.05.2017 um 22:57 schrieb Viktor: >>> >>> Hallo, >>> >>> ich bin seit Jahren begeisterter Nutzer der OpenStreetMap und kannte >>> schon von Wikipedia und Wikidata das Prinzip der freien, semantischen >>> Datenbanken und -quellen. >>> >>> Hieraus entwickelte sich vor einiger Zeit ein Projekt namens "WinilooC" >>> zur Entwicklung einer anwenderfreundlichen Suche für öffentliche Toiletten. >>> Da der Tag "amenity=toilets" weltweit etwa 170.000 Mal verwendet wird und >>> OSM über Overpass ziemlich elegant genutzt werden kann, bot es sich perfekt >>> als Datenquelle an. >>> In der Karte sollen die Toiletten übersichtlich und unterscheidbar >>> dargestellt werden, sodass sich z.B. kostenpflichtige von frei zugänglichen >>> auf einen Blick unterscheiden lassen können. >>> Darüber hinaus können zukünftig weitere Eigenschaften von den Objekten in >>> der Karte angezeigt werden. >>> >>> Ein Ziel meines Projektes ist es, dass Nutzer einfach Änderungen in die >>> Karte einbringen können. Dabei denke ich von Anfang an auch daran, dass ein >>> nachhaltiger Nutzen für das OSM-Projekt durch den Rückfluss von Daten >>> erfolgen kann. >>> >>> Für Hinweise oder Überlegungen zur Gestaltung des Datenrückflusses über >>> die APIs zur OSM bin ich sehr offen. >>> >>> Einen Artikel zum Projekt habe ich bereits in meinem Blog unter [1] >>> veröffentlicht. >>> >>> Viele Grüße >>> Viktor >>> >>> [1] https://blog.v-gar.de/2017/05/projektankuendigung-winilooc/ >>> >>> ___ >>> Talk-de mailing list >>> Talk-de@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-de >> >> >> >> --- >> Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. >> https://www.avast.com/antivirus >> >> >> ___ >> 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenschutz bei OSM - Schweiz
Sehe ich ähnlich wie Christoph. Einige Schweizer Datenschutzbeauftragte behaupteten damals gar, dass sämtliche räumlichen Datensätze (z.B. Froschlaichplätze) unter Personendatenschutz(!) fallen, denn sie lassen sich räumlich mit den Grundstückseigentümern verknüpfen... Nach 2004 kam dann das sog. Geo-Informationsgesetz des Bundes (2008) und bis heute sind die Kantone dran. Und das alles betrifft v.a. die Behörden-Daten! :Stefan Am 13. Juni 2017 um 09:50 schrieb Christoph Hormann : > On Tuesday 13 June 2017, Markus wrote: >> >> Zufällig stosse ich auf ein Gutachten des Eidgenössischen Datenschutz >> und Öffentlichkeitsbeauftagten der Schweiz. >> https://www.edoeb.admin.ch/datenschutz/00628/00665/00681/index.html?l >>ang=de >> >> [...] > > Bevor jetzt wieder irgendjemand Panik schiebt - der verlinkte Text > zitiert keinerlei Rechtsgrundlagen und kann wohl im Wesentlichen als > Wunschliste des Datenschutzbeauftragten von vor 13 Jahren verstanden > werden, wie die Dinge damals seiner Meinung nach zu seien hatten. > > Also bevor Leute jetzt irgendeine Laien-Interpretation so eines Textes > als Quasi-Gesetz bringen und darauf aufbauend behaupten, was bei OSM > wie sein muss bitte erst einmal auf die Gesetzeslage und die > Rechtsprechung schauen. Auch in der Schweiz muss jede Vorschrift eine > Rechtsgrundlage haben und daneben kommt es meist auch stark auf die > etablierte Interpretation der Begriffe an. > > -- > Christoph Hormann > http://www.imagico.de/ > > ___ > 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] mobiler Zielgruppen-spezifischer Editor
Lieber Markus Wie Marc geschrieben hat, ist MapContrib nicht nur eine Zielgruppen-spezifische Karte sondern ev. genau das, was du wohl suchst: https://wiki.openstreetmap.org/wiki/MapContrib#Edit_data Ich meine es lohnt sich, das mal genauer anzuschauen. Die Entwickler dort sprechen übrigens nicht nur französisch sondern auch englisch :-). :Stefan Am 12. Dezember 2016 um 10:22 schrieb Marc Gemis : > Sorry for the English. > > But mapcontrib is an editor as well. You can define a template that > users can fill in. > See my diary from June > http://www.openstreetmap.org/user/escada/diary/38884 for a bit more > detail. > > Gruss > > m > > 2016-12-12 10:11 GMT+01:00 Markus : >> Hallo Marc, >> >>> https://www.mapcontrib.xyz/ willeicht ? >> >> Das sieht eher aus wie eine Zielgruppen-spezifische Karte. >> >> Damit werden Daten auf einem Layer angezeigt. >> Möglich ist Overpass, CSV, GeoJSON, GPX. >> Die Biker könnten dort mit Overpass ihre Parkplätze anzeigen :-) >> >> Ich suche aber einen Editor... >> >> Gruss, Markus >> >> >> >> ___ >> 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wochennotiz Nr. 311 28.06.2016–04.07.2016
Hallo Wochennotiz-Team, Danke für die Erwähnung von Rapperswil - wo sich ja an meinem Geometa Lab einiges zusammenbraut wie z.B. die OSM2VectorTiles.org :-) :Stefan Am 8. Juli 2016 um 20:50 schrieb Wochennotizteam : > Hallo, > > die Wochennotiz Nr. 311 mit vielen wichtigen Neuigkeiten aus der > OpenStreetMap Welt ist da: > > http://blog.openstreetmap.de/blog/2016/07/wochennotiz-nr-311/ > > Viel Spaß beim Lesen! > ___ > 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] 1000-Augen-Prinzip
Markus,
Am 27. Januar 2016 um 22:33 schrieb Markus :
> In OSM werden Daten ja von tausenden Benutzern geprüft und ggf.
> verbessert. So entsteht iterativ eine hohe Genauigkeit und
> Detailliertheit unserer Daten.
>
> Gibt es zum "1000-Augen-Prnizip" als Methode der Qualitätsicherung in
> Opensource-Projekten schon Untersuchungen?
Ja; es gibt wissenschaftliche Papers (Haklay/Uni London) oder Zipf/Uni
Heidelberg?) über den Einfluss auf die Qualität in Bezug auf Anzahl
Changes und verglichen mit amtlichen Daten. Da wurde OSM eine gute
Qualität attestiert.
Aktuelle Forschungen von Zipf/Uni Heidelberg werten andererseits die
Tatsache, dass eine grosse Menge an "Aktiven Mapper" (d.h. die
Ungleichverteilung/"the long tail") auch als Qualitätsmerkmal.
Wie die Diskussion eben - und Fred's "I Like OSM" Idee - zeigt, gibt
können alternativ auch Leute wieder durch "Crowdsourcing" zu aktiven
Qualitätsaussagen angeregt werden.
Ich schätze aber, dass man breiter abgestützte Aussagen machen kann
nach dem Prinzip der "intrinsischen" Qualitätsuntersuchung verwendet.
Lukas (28. Januar 2016 um 13:26) verwies denn auch als weitere
Möglichkeit auf meinen Blog (mit Karte!) über die Visualisierung der
Anzahl Zugriffe auf die Startseite/Slippy Map von osm.org (siehe auch
dieses Poster [2]). Diese Untersuchung zielt darauf ab, was "Hot
Spots" sind. Die Analyse liesse sich natürlich auch umkehren, indem
man visualisiert, was NIE angeschaut wurde.
Mapbox hat schon früher versucht herauszufinden, wo potentiell
OSM-Daten fehlen und darüber berichtet ("Predicting data curation in
OpenStreetMap" [1]).
Noch früher waren wohl OSM Admins wie Grant, die eine "Tile disk
usage" berechnet haben [2]. Letztere Untersuchung besagt, dass im
Jahre 2011 auf zweitunterster Zoom-Stufe 18 nur 0.9%(!) der
Kacheln/Tiles verwendet wurden.
Mir scheint, dass man mit Statistiken von (nicht-)gebrauchten und
(nicht-)besuchten Kacheln vielversprechende Analysen machen könnte. Es
kommt aber drauf an, ob das genügt und auf das Ziel der Analysen sein
soll.
:Stefan
[1] https://www.mapbox.com/blog/osm-tracing-candidates/
[2] https://twitter.com/sfkeller/status/619954847031410688
[3] http://wiki.openstreetmap.org/wiki/Tile_disk_usage
Am 28. Januar 2016 um 14:26 schrieb Hartmut Holzgraefe
:
> On 27.01.2016 22:33, Markus wrote:
>
>> In OSM werden Daten ja von tausenden Benutzern geprüft und ggf.
>> verbessert. So entsteht iterativ eine hohe Genauigkeit und
>> Detailliertheit unserer Daten.
>
> Das wesentliche Zitat zu dem Thema war ja
>
> "Given enough eyeballs all bugs are shallow"
>
> So viele "eyeballs" haben wir aber, verglichen mit der Datenmenge,
> garnicht. Dazu kommt noch dass, anders als bei Source Code, es deutlich
> schwieriger ist sich das entsprechende Domänenwissen zu beschaffen um
> konkrete Daten überhaupt bewerten zu können.
>
> Ich denke nicht dass die Daten hier in der Gegend von tausenden
> Benutzern geprüft werden, wirklich aktive OSM-Accounts gibt es
> nur paar handvoll, und auch die Anzahl der Notes hält sich
> in Grenzen (vermutlich stammt der Großteil der anonymen davon
> sogar nur von einem einzelnen ex-User)
>
> Und ein wirklich systematisches Review findet auch nicht wirklich
> statt ... auch wenn wir immerhin ca. 1 1/2 User haben die über
> alle in der Gegend auflaufenden Changesets drüberschauen (der 1/2
> bin ich ...)
>
>> Gibt es zum "1000-Augen-Prnizip" als Methode der Qualitätsicherung in
>> Opensource-Projekten schon Untersuchungen?
>
> Die generelle Aussage war nicht dass Open Source Software dadurch
> automatisch besser wird, nur dass sie gegenüber Closed Source den
> Vorteil hat dass sie unter anderem auch auf diesem Weg besser werden
> *kann*.
>
> Allein schon das Wissen das andere hinter die Kulissen der eigenen
> Arbeit schauen können führt (bei mir zumindest) dazu dass man sich
> gewisse "passt scho'" Schludereien nicht mehr leistet.
>
> Aber auch hier gibt es unterschiedlich gelebte Vorgehensweisen,
> siehe zB. den klassischen Text "The Cathedral and the Bazaar" von
> Eric S. Raimond. Nicht alle Open Source Projekte sind da gleich
> offen, auch wenn der Quellcode bei allen öffentlich sichtbar ist.
>
> Mein früherer und auch mein aktueller Arbeitgeber (MySQL AB, MariaDB Corp.)
> sind zB. deutlich eher auf der Cathedral-Seite zu verorten.
> Mein nicht-mehr-Arbeitgeber (MySQL-Abteilung innerhalb von Oracle)
> treibt den Cathedral-Ansatz sogar auf die Spitze.
>
> OpenStreetMap dagegen empfinde ich zZ. als ein extremes Beispiel
> des Bazaar-Modells.
>
> Aber zurück zum eigentlichen Thema:
>
> Ich weiß nur von Untersuchungen zum konkreten Thema Pair Programming
> bei dem das Vier-Augen-Prinzip auf die Spitze getrieben wird. Das ist
> dann aber eigentlich schon wieder kein Open Source Thema mehr. Eher
> sogar im Gegenteil da tatsächliches Pairing mit zwei Entwicklern,
> die physisch vor demeselben Bildschirm sitzen, bei Open Source
> Projekten eher die totale Ausnahme sein werden solage keine
> Firma hinter dem Projekt
[Talk-de] TagFinder news: Update und Open Geo interview
Hallo, Hier zwei News zum TagFinder: Eine neue Version vom TagFinder wurde veröffentlicht. Diese enthält einen verbesserten "Fuzzy Text-Match"-Algorithmus, der zum Zuge kommt, wenn der Suchbegriff zuwenig Treffer erzielt. Damit sollte es weniger unsinnige Resultate (d.h. "falsche Positive") geben. Und Parkplatz, Holzhütte sowie Hundetüten werden auch gefunden. In eigener Sache: Auf dem OpenCage Data Blog ist ein Interview von mir erschienen: "Open Geo interview - TagFinder", 5. Februar 2015 (in Englisch) [1]. --S. [1] http://blog.opencagedata.com/post/110189262818/open-geo-interview-stefan-keller-tagfinder ___ 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)
Ca. 20h nach dem "starken Wunsch" von Michael K. nach Thumbnails (Mail
vom 20. Januar 2015 um 16:51) geht er schon in Erfüllung (Danke
nochmals an die Tipps von Jochen T. und Michael B.). Die
Suchresultate-Webseite lädt nun auch schneller!
Es ehrt uns, wenn ihr solch hohe Erwartungen an eine Tag-Suchmaschine
habt. Behält aber im Bewusstsein, dass das (noch) kein Produkt mit
24h-Support und dutzenden von bezahlten SW-Entwicklern ist - sondern
ein Prototyp, realisiert von einem Informatik-Studenten auf Basis
meiner Ideen...
Wir sammeln daher zurzeit v.a. euren Feedback und schauen dann mal.
Die Vorschläge und Diskussion von Andreas L. gehen in genau diese
Richtung.
Am Greifbarsten scheint mir das Feature, auch das Icon anzuzeigen von
der osm.org-Startseite/Karte (openstreetmap-carto style). Die
Voraussetzung dazu ist aber wie gesagt ein Config-File für Taginfo's
Projekt-Tab. Hier möchte ich alle ermuntern (v.a. diejenigen, die
programmieren können, aber nicht nur die) ermuntern, sich für ein
solches nützlich zu machen [1].
LG, S.
[1] https://github.com/gravitystorm/openstreetmap-carto/issues/961
Am 21. Januar 2015 um 10:50 schrieb Stefan Keller :
> Hallo,
>
> Am 21. Januar 2015 um 09:16 schrieb Andreas Labres :
>> ...
>> Und was auch noch wünschenswert wäre: dass im Suchergebnis das Icon (von
>> osm.org) angezeigt wird. Das wäre nochmal leichter überschaubar als
>> "irgendwelche" Fotos, wo man bei jedem Foto erst erfassen muss, worum's geht.
>> Vielleicht könnte man sich da mal ein Konzept überlegen, wie das definiert
>> wird,
>
> Da rennst du bei mir offene Türen ein: Eine alte Forderung und Lösung
> dazu wäre, wenn es eine Projekt-Datei gäbe für default Slippy Map
> (openstreetmap-carto) passend zu Taginfo's Projekt-Tab [1]. Mateusz
> hat da schon vorarbeit gemacht [2], nun braucht es noch einen
> Entwickler, der die Icons "herauszieht".
>
> LG, S.
>
> [1] https://lists.openstreetmap.org/pipermail/dev/2014-October/028085.html
> [2] https://github.com/gravitystorm/openstreetmap-carto/issues/961
>
>
> Am 21. Januar 2015 um 09:16 schrieb Andreas Labres :
>> Und nochwas:
>>
>> Template:Key bietet mehrere Konzepte, Subkeys zu definieren (abhängig davon,
>> wohin verlinkt wird), damit kann man sich eine Subkey-Hierarchie
>> herausziehen.
>> Und dann sollte man wieder zusammenfassen, also z.B. alle addr: Tags, statt
>> addr:street, addr:housenumber etc. explizit anzuführen.
>>
>> Und was auch noch wünschenswert wäre: dass im Suchergebnis das Icon (von
>> osm.org) angezeigt wird. Das wäre nochmal leichter überschaubar als
>> "irgendwelche" Fotos, wo man bei jedem Foto erst erfassen muss, worum's geht.
>> Vielleicht könnte man sich da mal ein Konzept überlegen, wie das definiert
>> wird,
>> letztlich bräuchte man das auf jeder Tag-Seite und auch in der Legende von
>> osm.org (dort fehlt das ja schon immer... :( ). Wenn nicht auf irgendeinem
>> API-Weg, dann in Form eines Templates im Wiki, z.B.
>> {{Rendering|Shop_supermarket.p.16.png}} *), ev. noch mit dem Zusatz, von
>> welcher
>> Karte die Rede ist (default: osm.org).
>>
>> *) und das am besten gleich mit Vektorgrafiken...
>>
>> 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)
Hallo,
Am 21. Januar 2015 um 09:16 schrieb Andreas Labres :
> ...
> Und was auch noch wünschenswert wäre: dass im Suchergebnis das Icon (von
> osm.org) angezeigt wird. Das wäre nochmal leichter überschaubar als
> "irgendwelche" Fotos, wo man bei jedem Foto erst erfassen muss, worum's geht.
> Vielleicht könnte man sich da mal ein Konzept überlegen, wie das definiert
> wird,
Da rennst du bei mir offene Türen ein: Eine alte Forderung und Lösung
dazu wäre, wenn es eine Projekt-Datei gäbe für default Slippy Map
(openstreetmap-carto) passend zu Taginfo's Projekt-Tab [1]. Mateusz
hat da schon vorarbeit gemacht [2], nun braucht es noch einen
Entwickler, der die Icons "herauszieht".
LG, S.
[1] https://lists.openstreetmap.org/pipermail/dev/2014-October/028085.html
[2] https://github.com/gravitystorm/openstreetmap-carto/issues/961
Am 21. Januar 2015 um 09:16 schrieb Andreas Labres :
> Und nochwas:
>
> Template:Key bietet mehrere Konzepte, Subkeys zu definieren (abhängig davon,
> wohin verlinkt wird), damit kann man sich eine Subkey-Hierarchie herausziehen.
> Und dann sollte man wieder zusammenfassen, also z.B. alle addr: Tags, statt
> addr:street, addr:housenumber etc. explizit anzuführen.
>
> Und was auch noch wünschenswert wäre: dass im Suchergebnis das Icon (von
> osm.org) angezeigt wird. Das wäre nochmal leichter überschaubar als
> "irgendwelche" Fotos, wo man bei jedem Foto erst erfassen muss, worum's geht.
> Vielleicht könnte man sich da mal ein Konzept überlegen, wie das definiert
> wird,
> letztlich bräuchte man das auf jeder Tag-Seite und auch in der Legende von
> osm.org (dort fehlt das ja schon immer... :( ). Wenn nicht auf irgendeinem
> API-Weg, dann in Form eines Templates im Wiki, z.B.
> {{Rendering|Shop_supermarket.p.16.png}} *), ev. noch mit dem Zusatz, von
> welcher
> Karte die Rede ist (default: osm.org).
>
> *) und das am besten gleich mit Vektorgrafiken...
>
> 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)
Michael, Am 20. Januar 2015 um 20:44 schrieb Michael Bemmerl : ... > Ich hab das gerade mal ausprobiert und die MediaWiki-API des OSM-Wikis > hat mir ohne Murren aus dem Bild-Namen die Thumbnail-URL generiert. Ausgezeichnet. Vielen Dank für die Tipps! LG, Stefan Am 20. Januar 2015 um 20:44 schrieb Michael Bemmerl : > Jochen Topf schrieb: >> On Mo, Jan 19, 2015 at 04:31:48 +0100, Michael Kugelmann wrote: > [snip] >> >> 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. > > Ich hab das gerade mal ausprobiert und die MediaWiki-API des OSM-Wikis > hat mir ohne Murren aus dem Bild-Namen die Thumbnail-URL generiert. Das > ging sowohl bei Bildern, die auf dem OSM-Wiki liegen, als auch bei > Bildern, die über Wikimedia Commons eingebunden sind. > > Beispiele: > Staffordshire_new_year_2015_mapping_walk.jpg (nur auf OSM) > > http://wiki.openstreetmap.org/w/api.php?action=query&titles=Image:Staffordshire_new_year_2015_mapping_walk.jpg&prop=imageinfo&iiprop=url&iiurlwidth=50&format=json > thumburl: > http://wiki.openstreetmap.org/w/images/thumb/2/27/Staffordshire_new_year_2015_mapping_walk.jpg/50px-Staffordshire_new_year_2015_mapping_walk.jpg > > Downtown_Charlottesville_fire_hydrant.jpg (Wikimedia Commons) > > http://wiki.openstreetmap.org/w/api.php?action=query&titles=Image:Downtown_Charlottesville_fire_hydrant.jpg&prop=imageinfo&iiprop=url&iiurlwidth=50&format=json > thumburl: > http://wiki.openstreetmap.org/w/images/thumb/5/5a/Downtown_Charlottesville_fire_hydrant.jpg/50px-Downtown_Charlottesville_fire_hydrant.jpg > > Grüße, > Michael > > > ___ > 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)
Ü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 : > Am 19. Januar 2015 um 17:30 schrieb Andreas Labres : >> * 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 : >> 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)
Am 19. Januar 2015 um 17:30 schrieb Andreas Labres : > * 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 : > 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)
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 : > 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 : >> >>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)
Hallo Peda Vielen Dank für dein rasches Feedback. Du hats am 18. Januar 2015 um 22:32 geschrieben: > zwei "Bugs" sind mir spontan aufgefallen. Erstens beachtet ihr das > Seitenverhältnis von Bildern nicht was teilweise doof aussieht (z.B. > http://tagfinder.herokuapp.com/search?query=emergency%3Dfire_hydrant). Stimmt. Das sollte einfach zu fixen sein. Hingegen wie verhindert werden soll, dass große Bilder heruntergeladen werden, wie das Joachim vorhing monierte, ist mir noch unklar. > Zweitens funktioniert bei Links in den Ergebnissen das Klicken erst > nach mehreren Buchstaben aber nicht gleich von Anfang an. Wenn dann > bei Weblinks z.B. "name=*" vorkommt, kann ich das nicht anklicken, > kommt z.B. "opening_hours=*" kann ich das erst ab ca. dem 'u' > anklicken :) Passiert im chromium und konqueror, im ff geht der Link > von Anfang an. Bisher unterstützen wir halt "nur" Firefox und Chrome. > Manchmal liefert die Suche noch sehr seltsame Werte. Kann man die evtl > noch besser aussortieren? So Dinge, die es nicht gibt oder auch gar > keinen Sinn machen? "Apfel", "Birne", "Melone" oder auch "Kindergrippe". > "Badewanne" liefert dann z.B. aber nichts. Und an sich wirkt es so als > hättet ihr Stammformreduktion, aber "Weintraube" und "Weintrauben" > liefern unterschiedliche Ergebnisse. Die Haupt-Testfälle umfassen sämtliche Presets von Id. Statt [Apfel] und [Birne] muss man da schon selber mit [Baum] versuchen. Und schon gesehen,dass bei [Kindergrippe] automatisch der Vorschlag [kinderkrippe] kommt? Aber der Suchalgorithmus ist tatsächlich noch kaum gegen unsinnige Einträge gewappnet. Es gibt dazu bereits einen Issue-Eintrag [1]. > Auf jeden Fall ein praktischer und gut gemachter Dienst. Bei den > realistischeren Tests hat das super funktioniert und auf jeden Fall > praktikabler als die Wiki-Suche. Eine schönere URL wäre noch nett. Oder > auch Integration in z.B. JOSM (als Ergänzung zu den Presets)?! Ausgezeichnete Idee. Das API wurde genau für solche Zwecke gemacht. Aber auch noch ein JOSM-Plugin zu schreiben, sprengte den Rahmen der Arbeit bei Weitem. Da sind nun weitere Freiwillige gefragt. LG, S. [1] https://github.com/geometalab/OSMTagFinder/issues/1 Am 18. Januar 2015 um 22:32 schrieb Peter Barth : > Hi, > > zwei "Bugs" sind mir spontan aufgefallen. Erstens beachtet ihr das > Seitenverhältnis von Bildern nicht was teilweise doof aussieht (z.B. > http://tagfinder.herokuapp.com/search?query=emergency%3Dfire_hydrant). > Zweitens funktioniert bei Links in den Ergebnissen das Klicken erst > nach mehreren Buchstaben aber nicht gleich von Anfang an. Wenn dann > bei Weblinks z.B. "name=*" vorkommt, kann ich das nicht anklicken, > kommt z.B. "opening_hours=*" kann ich das erst ab ca. dem 'u' > anklicken :) Passiert im chromium und konqueror, im ff geht der Link > von Anfang an. > > Manchmal liefert die Suche noch sehr seltsame Werte. Kann man die evtl > noch besser aussortieren? So Dinge, die es nicht gibt oder auch gar > keinen Sinn machen? "Apfel", "Birne", "Melone" oder auch "Kindergrippe". > "Badewanne" liefert dann z.B. aber nichts. Und ansich wirkt es so als > hättet ihr Stammformreduktion, aber "Weintraube" und "Weintrauben" > liefern unterschiedliche Ergebnisse. > > Auf jeden Fall ein praktischer und gut gemachter Dienst. Bei den > realistischeren Tests hat das super funktioniert und auf jeden Fall > praktikabler als die Wiki-Suche. Eine schönere URL wäre noch nett. Oder > auch Integration in z.B. JOSM (als Ergänzung zu den Presets)?! > > Danke und Gruß, > Peda > > > ___ > 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. Januar 2015 um 23:17 schrieb Joachim Kast : > zu dem erwähnten Hydranten-Bild: 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 :-) !?? LG, S. Am 18. Januar 2015 um 23:17 schrieb Joachim Kast : > Hallo Stefan, > > zu dem erwähnten Hydranten-Bild: 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. > > Grüße > Joachim > > ___ > 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
[Talk-de] TagFinder - eine Volltext-Suchmaschine für OSM Tags (Prototyp)
Es freut mich, eine neue Webapp "TagFinder" vorzustellen. TagFinder ist eine Volltext-Suchmaschine für OpenStreetMap Tags. Es gibt eine Demo-Seite (Prototyp deutsch und englisch) mit API auf Heroku [1]. TagFinder nutzt das unersetzliche Taginfo, Übersetzungsdienste (deutsch->englisch), Thesauren und ein adaptiertes, domänen-spezifisches Semantisches Netz. TagFinder wurde im Rahmen einer Informatik-Semesterarbeit am Geometa Lab der HSR Hochschule Rapperswil (Schweiz) entwickelt. Die Webapp ist in Python 2.7 und dem Flask Webframework geschrieben. Der Sourcecode ist auf Github [2]. Tested die App und gebt Feedback, z.B. hier, auf Twitter @geometalab [3], als Github Issue [2] oder direkt an mich. -S. [1] http://tagfinder.herokuapp.com/ [2] https://github.com/geometalab/OSMTagFinder [3] https://twitter.com/geometalab ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Ich möchte der Vollständigkeit halber auf ein ähnliche aktuelle Diskussion im Forum hinweisen. Dort wurde als Verbesserungsmassnahme das OSMantic-Plugin vorgeschlagen: https://wiki.openstreetmap.org/wiki/JOSM/Plugins/OSMantic Die dortige Umfrage ist zwar abgeschlossen und wird bald publiziert. Trotzdem bin ich interessiert zu hören, was ihr für Erfahrungen damit macht. LG, S. Am 7. Oktober 2014 14:19 schrieb Martin Koppenhoefer : > Am 7. Oktober 2014 08:46 schrieb Theodin : > >> Aber die Englische Originalseite ist da weniger klar wie die deutsche. >> Dort wird nur auf dir >> Diskussion verwiesen. Und nur weils da steht heißt das nicht viel, das >> kann auch die >> Minderheitsmeinung sein. >> > > > +1, die englische Seite ist maßgebend. Bei einem tag, der sich in den > üblichen Presets findet und der 308.000 mal in den Daten vorkommt ist es > sowieso immer ein bisschen schwierig, von "deprecated" in OSM zu sprechen, > weil wir ja vorwiegend "mit den Füßen" abstimmen. > > Gruß, > Martin > ___ > 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
[Talk-de] informatiCup: 10. Studierendenwettbewerb der Gesellschaft für Informatik gestartet (mit OSM-Daten)
Mit der Veröffentlichung der Aufgabe wurde heute der 10. Studierendenwettbewerb 2015 (informatiCup) der deutschen Gesellschaft für Informatik e.V. gestartet. Bis zum 15. Januar 2015 haben studentische Teams die Möglichkeit, Ihre Wettbewerbsbeiträge einzureichen. Der informatiCup richtet sich an eingeschriebene Studierende aller Fachrichtungen an Universitäten und Fachhochschulen in Deutschland, Österreich und der Schweiz. In der Aufgabe 2015 geht es darum, durch eine Verknüpfung von Geodaten und Metadaten (räumliches Clustering) die Geltungsbereiche sogenannter Space Usage Rules (zum Beispiel Rauchen verboten/Parken verboten/Schwimmenerlaubt) sinnvoll und zweifelsfrei für elektronische Karten zugänglich zu machen. Als Grundlage sind Daten von OpenStreetMap vorgegeben. Mehr zum Wettbewerb auf http://informaticup.gi.de/ und http://twitter.com/informaticup ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Hallo fly Am 6. Oktober 2014 16:27 schrieb fly : > Am 05.10.2014 22:16, schrieb Stefan Keller: ... >> * Einzelne Ablösungen sind offenbar noch lange nicht abgeschlossen >> (z.B. landuse=reservoir durch natural=water + water=reservoir) > > Und genau da hast Du wohl einen Fehler der deutschen Übersetzung > gefunden. landuse=reservoir wurde nie als veraltet erklärt nur die > Definition genauer. Es ist eben nicht nur der Wasserbereich sondern > zumindest auch noch der Damm bzw Begrenzung häufig auch noch ne Wiese. Moment mal: Auf der Wiki-Seite "De:Tag:landuse=reservoir" http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dreservoir steht unmissverständlich, dass das veraltet ist. Bis etwas als Deprecated bezeichnet wird, braucht's m.E. doch einiges. Willst du damit sagen, dass wir sogar über Deprecated-Tags eine Qualitätsdiskussion führen müssen? LG, S. Am 6. Oktober 2014 16:27 schrieb fly : > Am 05.10.2014 22:16, schrieb Stefan Keller: >> Ich habe kurz nachgeschaut: >> >> 1. Ablösung highway=ford durch ford=yes : >> Ist in der Wiki-Seite vermerkt: >> http://wiki.openstreetmap.org/wiki/Ford#Remarks >> Da gibt es noch 6'222 gegenüber 51'728. >> >> 2. Ablösung von landuse=reservoir durch natural=water + water=reservoir : >> Ist in der Wiki-Seite vermerkt: >> http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dreservoir >> Da gibt es noch 308'718 gegenüber 25'537. >> >> Fazit dieser (zugegebenermassen kleinen) Stichprobe: >> * Das Wiki scheint mind. für Tag-Beschreibungen aktueller als manche >> denken(?). >> * Für deprecated gibt es die Wiki-Seite "Deprecated_features" >> * Aber es gibt offenbar keine Formatvorlage (Hinweise: Manchmal ist >> auch nur ein Abschnittt "deprecated" - was dann?) >> * Deprecated_features scheint unvollständig (z.B. landuse=reservoir). >> Hinweis: Das ist m.E. keine Tag-Beschreibungsseite sondern eine Art >> "Meta-Seite". >> * Einzelne Ablösungen sind offenbar noch lange nicht abgeschlossen >> (z.B. landuse=reservoir durch natural=water + water=reservoir) > > Und genau da hast Du wohl einen Fehler der deutschen Übersetzung > gefunden. landuse=reservoir wurde nie als veraltet erklärt nur die > Definition genauer. Es ist eben nicht nur der Wasserbereich sondern > zumindest auch noch der Damm bzw Begrenzung häufig auch noch ne Wiese. > > cu fly > > ___ > 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] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Am 5. Oktober 2014 21:22 schrieb Hakuch : > ich bin auch sehr dafür deprecated öfter und deutlicher einzusetzen, ich > weiß garnicht ob es da schon eine entsprechende Formatvorlage für gibt? Es gibt diese englische Wiki-Seite: http://wiki.openstreetmap.org/wiki/Deprecated_features Am 2. Oktober 2014 22:08 schrieb Thorsten Kurz : ... > highway=ford wurde durch ford=yes abgelöst, und dann gibt's da noch das > veraltete landuse=reservoir das durch natural=water + water=reservoir > ersetzt wurde. > > Ich glaube in den meisten Fällen mit mehreren Tagging-Schemen ist eines > davon veraltet oder nicht richtig angewandt. Insofern dürfte die Suche > nach "depreciated" im OSM-Wiki zu weiteren Fällen mit unterschiedlichen > Tagging-Schemen führen. Ich habe kurz nachgeschaut: 1. Ablösung highway=ford durch ford=yes : Ist in der Wiki-Seite vermerkt: http://wiki.openstreetmap.org/wiki/Ford#Remarks Da gibt es noch 6'222 gegenüber 51'728. 2. Ablösung von landuse=reservoir durch natural=water + water=reservoir : Ist in der Wiki-Seite vermerkt: http://wiki.openstreetmap.org/wiki/DE:Tag:landuse%3Dreservoir Da gibt es noch 308'718 gegenüber 25'537. Fazit dieser (zugegebenermassen kleinen) Stichprobe: * Das Wiki scheint mind. für Tag-Beschreibungen aktueller als manche denken(?). * Für deprecated gibt es die Wiki-Seite "Deprecated_features" * Aber es gibt offenbar keine Formatvorlage (Hinweise: Manchmal ist auch nur ein Abschnittt "deprecated" - was dann?) * Deprecated_features scheint unvollständig (z.B. landuse=reservoir). Hinweis: Das ist m.E. keine Tag-Beschreibungsseite sondern eine Art "Meta-Seite". * Einzelne Ablösungen sind offenbar noch lange nicht abgeschlossen (z.B. landuse=reservoir durch natural=water + water=reservoir) LG, Stefan Am 5. Oktober 2014 21:22 schrieb Hakuch : > > > On 05.10.2014 18:54, Stefan Keller wrote: >> Am 5. Oktober 2014 14:05 schrieb ich: >>> Falls ja, dann müsste man wohl an Aktionen wie >>> Wiki-Übersetzungs-Verbesserung und Wiki-Aufräumen denken? >>> Es müsste ja nicht gleich das Ganze Wiki sein, sondern "nur" Vorschlag 3. >>> ... >> >> und man könnte vermehrt "Deprecated" und "Siehe..." einfügen. >> >> LG, S. >> > > ich bin auch sehr dafür deprecated öfter und deutlicher einzusetzen, ich > weiß garnicht ob es da schon eine entsprechende Formatvorlage für gibt? > > >> >> Am 5. Oktober 2014 14:05 schrieb Stefan Keller : >>> Am 5. Oktober 2014 11:41 schrieb Florian Lohoff : >>> >>>> Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der Natur >>>> der Sache kopiert da jeder zeugs hin und her und ändert das . >>> ... >>>> Dazu kommen noch jede menge semantische änderungen die alleine durch die >>>> Übersetzungen >>>> eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle >>>> subjektiv. >>>> >>>> Und da ja auch niemand sagt "Die Englische version der Seite ist die >>>> führende" ist >>>> am Ende das Wiki ein Oktopus mit 250 Armen. >>> >>> D.h., dass wir keine "aufgeräumte" Datenbank haben, v.a. weil das Wiki >>> nicht aufgeräumt ist? >>> Falls ja, dann müsste man wohl an Aktionen wie >>> Wiki-Übersetzungs-Verbesserung und Wiki-Aufräumen denken? >>> Es müsste ja nicht gleich das Ganze Wiki sein, sondern "nur" Vorschlag >>> 3. mit den Seiten >>> http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und >>> http://wiki.openstreetmap.org/wiki/Map_Features u >>> >>> LG, S. >>> >>> >>> Am 5. Oktober 2014 11:41 schrieb Florian Lohoff : >>>> On Sat, Oct 04, 2014 at 08:51:07PM +0200, Stefan Keller wrote: >>>>> Ok. Aber Tatsache ist m.E., dass es Verbesserungspotential gibt. >>>>> >>>>> Und wie es scheint, geht es nicht nur um Neulinge. Auch gestandene >>>>> Mapper können übersehen, dass es geläufigere und aktuellere >>>>> Tagging-Schemen gibt. >>>>> >>>>> Wenn dem so ist, wie könnte man das verbessern? >>>>> 1. Sind die Suchfunktionen von Wiki und z.B. Taginfo ungenügend (bzw. >>>>> ungenutzt)? >>>>> 2. Sind im Wiki die Seiten >>>>> http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und >>>>> http://wiki.openstreetmap.org/wiki/Map_Features ungenügend? >>>>> 3. Sollte man es mit einer interaktiven Bestimmungs-Anleitung versuchen? >>>>> 4. Oder einem Plugin (ähnlich OSMantic für JOSM => Hat das jemand >>>&
Re: [Talk-de] Verbesserung der attributiven Heterogenit ät (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Hallo Holger Am 5. Oktober 2014 19:45 schriebst du: >... > Und alternative Bezeichnungen (Dom, Kirche, Kapelle, > Gebethaus,...) in allen Sprachen pflegen, damit die Suche > immer/häufig trifft. > > Also händisch alle Seiten angucken und alle Synonyme die einem > einfallen (und zum Tag passen) hinzufügen. So etwas gibt es mit "RelatedTerms" (verwandte Begriffe), unten auf einigen Wiki-Seiten! Es wurde von mir vor 3 Jahren eingeführt :-) Siehe [1][2]. Unter nachfolgenden Voraussetzungen kann ich nur ermuntern, RelatedTerms in Wiki-Seitenzu ergänzen und weiterzupflegen. > Kann man das semi automatisch aus den synonymen von wiktionary ziehen? So etwas würde ich nicht automatisch einfügen (das können Suchmaschinen dann unabhängig davon immer noch), sondern sorgfältig einpflegen - von Hand passend zu OSM . Auch möchte ich davon abraten, Übersetzungen einzupflegen. Übersetzungen sind keine Synonyme. Die Übersetzung ergibt sich dadurch, dass die ganze Wiki-Seite in eine andere Sprache übersetzt wird. LG, Stefan [1] http://wiki.openstreetmap.org/wiki/Kirche [2] http://wiki.openstreetmap.org/wiki/RelatedTerms Am 5. Oktober 2014 19:45 schrieb Holger Jeromin : > Stefan Keller Wrote in message: >> Am 5. Oktober 2014 14:05 schrieb ich: >>> Falls ja, dann müsste man wohl an Aktionen wie >>> Wiki-Übersetzungs-Verbesserung und Wiki-Aufräumen denken? >>> Es müsste ja nicht gleich das Ganze Wiki sein, sondern "nur" Vorschlag 3. >>> ... >> >> und man könnte vermehrt "Deprecated" und "Siehe..." einfügen. > Und alternative Bezeichnungen (Dom, Kirche, Kapelle, > Gebethaus,...) in allen Sprachen pflegen, damit die Suche > immer/häufig trifft. > > Also händisch alle Seiten angucken und alle Synonyme die einem > einfallen (und zum Tag passen) hinzufügen. > > Kann man das semi automatisch aus den synonymen von wiktionary ziehen? > > -- > Holger > > > ___ > 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] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Am 5. Oktober 2014 14:05 schrieb ich: > Falls ja, dann müsste man wohl an Aktionen wie > Wiki-Übersetzungs-Verbesserung und Wiki-Aufräumen denken? > Es müsste ja nicht gleich das Ganze Wiki sein, sondern "nur" Vorschlag 3. > ... und man könnte vermehrt "Deprecated" und "Siehe..." einfügen. LG, S. Am 5. Oktober 2014 14:05 schrieb Stefan Keller : > Am 5. Oktober 2014 11:41 schrieb Florian Lohoff : > >> Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der Natur >> der Sache kopiert da jeder zeugs hin und her und ändert das . > ... >> Dazu kommen noch jede menge semantische änderungen die alleine durch die >> Übersetzungen >> eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle >> subjektiv. >> >> Und da ja auch niemand sagt "Die Englische version der Seite ist die >> führende" ist >> am Ende das Wiki ein Oktopus mit 250 Armen. > > D.h., dass wir keine "aufgeräumte" Datenbank haben, v.a. weil das Wiki > nicht aufgeräumt ist? > Falls ja, dann müsste man wohl an Aktionen wie > Wiki-Übersetzungs-Verbesserung und Wiki-Aufräumen denken? > Es müsste ja nicht gleich das Ganze Wiki sein, sondern "nur" Vorschlag > 3. mit den Seiten > http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und > http://wiki.openstreetmap.org/wiki/Map_Features u > > LG, S. > > > Am 5. Oktober 2014 11:41 schrieb Florian Lohoff : >> On Sat, Oct 04, 2014 at 08:51:07PM +0200, Stefan Keller wrote: >>> Ok. Aber Tatsache ist m.E., dass es Verbesserungspotential gibt. >>> >>> Und wie es scheint, geht es nicht nur um Neulinge. Auch gestandene >>> Mapper können übersehen, dass es geläufigere und aktuellere >>> Tagging-Schemen gibt. >>> >>> Wenn dem so ist, wie könnte man das verbessern? >>> 1. Sind die Suchfunktionen von Wiki und z.B. Taginfo ungenügend (bzw. >>> ungenutzt)? >>> 2. Sind im Wiki die Seiten >>> http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und >>> http://wiki.openstreetmap.org/wiki/Map_Features ungenügend? >>> 3. Sollte man es mit einer interaktiven Bestimmungs-Anleitung versuchen? >>> 4. Oder einem Plugin (ähnlich OSMantic für JOSM => Hat das jemand >>> ausprobiert)? >>> >>> Oder liegt es einfach daran, dass die Daten mit alten Tagging-Schemen >>> zuwenig schnell verbessert werden? >> >> Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der Natur >> der Sache kopiert da jeder zeugs hin und her und ändert das . >> >> Irgendwann gibts es 20 Tagging Schemata und jedes sieht semi-akzeptiert aus. >> Jeder mapped dann so vor sich hin und beruft sich auf das Schema was er für >> das >> richtige hält. >> >> Dazu kommen noch jede menge semantische änderungen die alleine durch die >> Übersetzungen >> eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle >> subjektiv. >> >> Und da ja auch niemand sagt "Die Englische version der Seite ist die >> führende" ist >> am Ende das Wiki ein Oktopus mit 250 Armen. >> >> Flo >> -- >> Florian Lohoff f...@zz.de >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.10 (GNU/Linux) >> >> iQIVAwUBVDESZZDdQSDLCfIvAQqocw//SsVRYvx+i+8BAmYBoISdF4kqMF9yj6Fb >> fhtfDLTx2RjoxblxpepODsIoMvFfZw5BaBQAu22CAyEtp++mpG07DmiJYr8Nk6YL >> gQxbk1aca9RIc2rfTtmhYN+n8dfR1cWIExSPRE8PVrQRzk2Ngw+9viDPIfsi4d7C >> FGEJaiWMxenQVKL9oFarwAj4phxXJ0cpNy99ttmSkPIq8XNK3Q1McVlwZIJFb8ER >> 3RrXLLtx3tq4M617Mjh34mKlfc1St4ty2epmAS/vNFewIM+EXT4Ni0OlXw1bMk5I >> kPgz6Tu+sucZiD+8auLZAq+lWLIHmwxO2WUY25LWp60f7RF+8MoBt2BuovpEwsCF >> jxsvc6TQsRspjA/GrFwwgDtnGeITmnAT1Ca/FOVt21NO0DQls0k2v9oWa/4uxNtm >> TpdAqwTpti3D7iOhmcAU0mrta1a74MyvMlL+rPL5edVyHbkeJ9c787tBBYS0yjlN >> MICIkeaYSSEMUOVli6indCcabPruHpfP+BtFG9LFJHSx6koad8FDxgsWDQSlQ42H >> YTo9ja1nxnTBK93t0a0+p/t3ZWRYUJfGlRDylv/XtoG07ti8z05JVXQAii9+ZXMC >> 0Wov5aaTI4KZQTR/RwbfNIU3hgYi7gZ9iZAm9QYP1pvem5CnvHlOKyvVuTBxBgle >> eHSlbt2ZpRo= >> =ThHy >> -END PGP SIGNATURE- >> ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Am 5. Oktober 2014 11:41 schrieb Florian Lohoff : > Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der Natur > der Sache kopiert da jeder zeugs hin und her und ändert das . ... > Dazu kommen noch jede menge semantische änderungen die alleine durch die > Übersetzungen > eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle > subjektiv. > > Und da ja auch niemand sagt "Die Englische version der Seite ist die > führende" ist > am Ende das Wiki ein Oktopus mit 250 Armen. D.h., dass wir keine "aufgeräumte" Datenbank haben, v.a. weil das Wiki nicht aufgeräumt ist? Falls ja, dann müsste man wohl an Aktionen wie Wiki-Übersetzungs-Verbesserung und Wiki-Aufräumen denken? Es müsste ja nicht gleich das Ganze Wiki sein, sondern "nur" Vorschlag 3. mit den Seiten http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und http://wiki.openstreetmap.org/wiki/Map_Features u LG, S. Am 5. Oktober 2014 11:41 schrieb Florian Lohoff : > On Sat, Oct 04, 2014 at 08:51:07PM +0200, Stefan Keller wrote: >> Ok. Aber Tatsache ist m.E., dass es Verbesserungspotential gibt. >> >> Und wie es scheint, geht es nicht nur um Neulinge. Auch gestandene >> Mapper können übersehen, dass es geläufigere und aktuellere >> Tagging-Schemen gibt. >> >> Wenn dem so ist, wie könnte man das verbessern? >> 1. Sind die Suchfunktionen von Wiki und z.B. Taginfo ungenügend (bzw. >> ungenutzt)? >> 2. Sind im Wiki die Seiten >> http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und >> http://wiki.openstreetmap.org/wiki/Map_Features ungenügend? >> 3. Sollte man es mit einer interaktiven Bestimmungs-Anleitung versuchen? >> 4. Oder einem Plugin (ähnlich OSMantic für JOSM => Hat das jemand >> ausprobiert)? >> >> Oder liegt es einfach daran, dass die Daten mit alten Tagging-Schemen >> zuwenig schnell verbessert werden? > > Das Problem ist das das Wiki leider eine menge Müll enthält. Aus der Natur > der Sache kopiert da jeder zeugs hin und her und ändert das . > > Irgendwann gibts es 20 Tagging Schemata und jedes sieht semi-akzeptiert aus. > Jeder mapped dann so vor sich hin und beruft sich auf das Schema was er für > das > richtige hält. > > Dazu kommen noch jede menge semantische änderungen die alleine durch die > Übersetzungen > eingepflegt werden. Die Übersetzungen aus dem Englischen sind halt alle > subjektiv. > > Und da ja auch niemand sagt "Die Englische version der Seite ist die > führende" ist > am Ende das Wiki ein Oktopus mit 250 Armen. > > Flo > -- > Florian Lohoff f...@zz.de > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIVAwUBVDESZZDdQSDLCfIvAQqocw//SsVRYvx+i+8BAmYBoISdF4kqMF9yj6Fb > fhtfDLTx2RjoxblxpepODsIoMvFfZw5BaBQAu22CAyEtp++mpG07DmiJYr8Nk6YL > gQxbk1aca9RIc2rfTtmhYN+n8dfR1cWIExSPRE8PVrQRzk2Ngw+9viDPIfsi4d7C > FGEJaiWMxenQVKL9oFarwAj4phxXJ0cpNy99ttmSkPIq8XNK3Q1McVlwZIJFb8ER > 3RrXLLtx3tq4M617Mjh34mKlfc1St4ty2epmAS/vNFewIM+EXT4Ni0OlXw1bMk5I > kPgz6Tu+sucZiD+8auLZAq+lWLIHmwxO2WUY25LWp60f7RF+8MoBt2BuovpEwsCF > jxsvc6TQsRspjA/GrFwwgDtnGeITmnAT1Ca/FOVt21NO0DQls0k2v9oWa/4uxNtm > TpdAqwTpti3D7iOhmcAU0mrta1a74MyvMlL+rPL5edVyHbkeJ9c787tBBYS0yjlN > MICIkeaYSSEMUOVli6indCcabPruHpfP+BtFG9LFJHSx6koad8FDxgsWDQSlQ42H > YTo9ja1nxnTBK93t0a0+p/t3ZWRYUJfGlRDylv/XtoG07ti8z05JVXQAii9+ZXMC > 0Wov5aaTI4KZQTR/RwbfNIU3hgYi7gZ9iZAm9QYP1pvem5CnvHlOKyvVuTBxBgle > eHSlbt2ZpRo= > =ThHy > -END PGP SIGNATURE- > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verbesserung der attributiven Heterogenität (War: Was gibt es für unterschiedliche Tagging-Schemen?)
Am 4. Oktober 2014 19:22 schrieb Simon Poole : > IMHO ist es auch viel weniger heterogen als behauptet. Das Beispiel das > Roland gegeben zeigt, dass es häufig auch eher daran liegt genau zu > bestimmen -was- etwas ist, nicht am Tagging selber (das ist glaube ich > das Missverständnis in dem Fall). Ok. Aber Tatsache ist m.E., dass es Verbesserungspotential gibt. Und wie es scheint, geht es nicht nur um Neulinge. Auch gestandene Mapper können übersehen, dass es geläufigere und aktuellere Tagging-Schemen gibt. Wenn dem so ist, wie könnte man das verbessern? 1. Sind die Suchfunktionen von Wiki und z.B. Taginfo ungenügend (bzw. ungenutzt)? 2. Sind im Wiki die Seiten http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A und http://wiki.openstreetmap.org/wiki/Map_Features ungenügend? 3. Sollte man es mit einer interaktiven Bestimmungs-Anleitung versuchen? 4. Oder einem Plugin (ähnlich OSMantic für JOSM => Hat das jemand ausprobiert)? Oder liegt es einfach daran, dass die Daten mit alten Tagging-Schemen zuwenig schnell verbessert werden? LG, S. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Was gibt es für unterschiedliche Tagging-Schemen?
Liebe Mapper Ich bin daran, die Heterogenität von OSM zu verbessern, in dem ich sie sammle und auf unterschiedliche Tagging-Schemen hinweise. Hier eine erste Liste in Stichworten: * Baulich getrennte/gemischte Geh- und Radwege, die entweder erfasst werden als highway = cycleway und foot = designated oder als highway= footway und bicycle = designated oder als highway = path und bicylce = designated und foot = designated. * Gebäudeadressen: Karlsruhe-Schema, ...? Weitere? LG, S. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM: ein bißchen Statistik
Hallo Pascal und Werner Habt ihr schon erste Schlussfolgerungen, was die Statistiken aussagen? Bei beiden wird offenbar ein exponentielles Wachstum angenommen, oder? Denn bei Werner's Statistik werden doppelt logarithmische Skalen angewendet und Pascal kumulierte die Objekte (= 100%). Bei Werner's ersten beiden Grafiken könnte die These interessant sein, ob neue User weniger Objekte Mappen(?). Bei Pascals erster interessanter Grafik, würde ich folgern, dass 2014 signifikant weniger neue Nodes (von 2014 ~17% auf 2014 ~12%) erzeugt wurden(?). Pascals zweiter Grafik mit dem Durchschnittsalter von OSM Objekten scheint mir die Frage zugrunde zu liegen, ob die Mapper tendenziell häufiger aktualisieren? Ich habe jedenfalls Mühe nachzuvollziehen, 1. was die Grafik aussagt und 2. wie die Aussage "55% of the Nodes, 67% of the Ways and 74% of the Relations in the OSM database do not have a timestamp dated before 2012" in der Grafik zu sehen ist, bzw. zustande kommt? --Stefan Am 27. Juli 2014 22:08 schrieb Werner Hoch : > Hi, > > spiele seit längerem mit ähnlichen Statistiken: > http://www.h-renrew.de/h/osm/osmchecks/03_Statistik/planet/statistic.html > > Die Daten sind vom April. > > mfg > Werner > > Am Dienstag, den 22.07.2014, 06:36 + schrieb Elstermann, Mike: >> Dank Pascal Neis können wir uns wieder auf eine kurzweilige und interessante >> OSM-Statistik freuen... Danke dafür! >> >> http://neis-one.org/2014/07/age-of-osm-objects/ oder >> http://geoobserver.wordpress.com/2014/07/22/osm-ein-bischen-statistik/ > > > > ___ > 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] Vorschlag neuer Geometrie (relationen)-Typ: node-relation
Hallo, Ich wäre sehr, sehr zurückhaltend mit neuen "Datentypen" - besonders im Zusammenhang mit Nodes und Ways. LG, Stefan P.S: Was mehr als überfällig ist, das ist ein echter Area-Typ. Am 9. Juli 2014 19:48 schrieb Martin Koppenhoefer : > Habe einen Vorschlag zu einem neuen Relationentyp ins Wiki gestellt: > > https://wiki.openstreetmap.org/wiki/Relations/Proposed/Node > > Es geht darum, mehrere Node-Objekte am selben Ort mappen zu können, eine > Situation, die z.B. bei Verkehrsschildern öfters auftaucht, für die es aber > sicherlich noch hundert andere Anwendungsfälle gibt. > > Gruß Martin > ___ > 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
[Talk-de] Workshop Gamification in der Geo-Information (inkl. Kort Game), 22. September 2014, Berlin
Die Kommission Angewandte Kartographie und Geovisualisierung der Deutschen Gesellschaft für Kartographie (DGFK) veranstaltet in Zusammenarbeit mit der Map Media GmbH am 22. September 2014 einen Workshop zum Thema Gamification in Berlin (Landesarchiv). Mit Gamification oder Serious Games bezeichnet man die Übernahme spielerischer Elemente in ursprünglich spielfremden Kontext. Dieses Prinzip kann auch auf Geo-Informationstechnologien angewendet werden zur stärkeren Nutzer-Bindung an GIS-Produkte sowie auch zur Erfassung und Qualitätssicherung von Geodaten. Nach drei einführenden Vorträgen am Vormittag soll der Workshop am Nachmittag mit einer Spielrunde Kort abgeschlossen werden. Kort ist ein Mobiles Web App zur Verbesserung von OpenStreetMap-Daten, das an der HSR Hochschule für Technik Rapperswil entwickelt wurde und bereits mehrere Preise gewonnen hat: http://www.kort.ch/ Weitere Informationen und Anmeldung zum Workshop unter: http://www.angewandte-kartographie.de/download/WS_Gamification_Berlin_2014.pdf ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TRAVIC [was: Wochennotiz Nr. 198 29.4.-5.5.2014]
https://www.geops.de/%C3%BCber-uns LG, Stefan Am 9. Mai 2014 12:33 schrieb Alexander Lehner : > > > On Thu, 8 May 2014, wn reader wrote: > > Hallo, >> >> die Wochennotiz Nr. 198 mit allen wichtigen Neuigkeiten aus der >> OpenStreetMap Welt ist da: >> >> http://blog.openstreetmap.de/blog/2014/05/wochennotiz-nr-198/ >> > > > Danke erstmal wieder fuer die nette Zusammenstellung! > > Kann mir jemand einen Kontakt zu den Machern der TRAVIC Karte vermitteln, > auf der Zuege live visualisiert werden? > > Ich kenne einen kleinen Eisenbahnerverein, der mit historischen Dampflocks > Touristenfahrten veranstaltet. > Das waere natuerlich nett, deren Fahrplaene dort einzuspeisen und die > TRAVIC Seite auf deren Homepage zu verlinken. > > A. > > > ___ > 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
[Talk-de] Schweizer PostgreSQL-Konferenz, Di. 24. Juni 2014, HSR Hochschule für Technik Rapperswil
Liebe alle Ich erlaube mir, Sie auf unten stehenden Anlass hinzuweisen. Das Tagungsprogramm ist nun publiziert und die Registrierung ist offen. Willkommen am schönsten Campus der Schweiz! LG, Stefan K. Swiss Postgres Conference, Di. 24. Juni 2014 Die erste Schweizer PostgreSQL-Konferenz ist eintägiger Anlass der HSR Hochschule für Technik Rapperswil zum "besten Open Source Datenbanksystem". Die Themen umfassen u.a.: - PostgreSQL im täglichen Einsatz - Vorteile und Besonderheiten von PostgreSQL - Migration zu PostgreSQL - Performance Tuning und Performance Optimization - Client/Server Programmierung - Extensions u.a. BSON, PostGIS, Full-Text Search, Foreign Data Wrappers - Vergleiche mit MySQL, MongoDB und Oracle. Die Referate sind vorwiegend deutschsprachig mit Vorträgen auch auf französisch und auf englisch. Es gibt zwei parallele Tracks, einer technisch orientiert, der andere auf Endanwender und Entscheidungsträger ausgerichtet. Programm und Anmeldung: http://www.postgres-conference.ch News: http://twitter.com/swiss_postgres #swisspgc ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] BKG nutzt OSM Daten im Verfahren TopPlus
Hallo, Bitte verlegt die juristische Diskussion mind. in einen separaten Thread mit wiederauffindbarem Subject. Ich habe ja geschrieben, dass ich keine solche vom Zaun brechen will, auch wenn sie interessant erscheint :-) LG, Stefan Am 6. Mai 2014 16:57 schrieb Martin Koppenhoefer : > > > > Am 06/mag/2014 um 14:17 schrieb Simon Poole : > > > > Wenn wir jetzt generell das anschauen, dann gehe ich im Augenblick davon > > aus, dass es nur zulässig ist (also ohne SA auszulösen) wenn die > > Manipulation algorithmisch beim Produzieren eines "produced work" > > passiert. > > > Im Ernst? Man kann mit OSM und anderen Daten zusammen ein Produced work > berechnen (d.h. die Datenquellen wären nicht unabhängig) , z.B. eine Karte, > rendern, und die nicht-OSM-Daten werden dabei nicht vom SA-Virus befallen? > Besonders viral wäre so eine Lizenz dann wohl nicht mehr zu nennen. > > M.E. wenn es um algorithmisches Mergen geht (und sei es nur temporär für > die Erstellung eines Produced works), dann ist das Resultat eine derivative > db (und sei es nur im RAM), die ggf. unter ODbL geshared werden muss. > > Gruß, > Martin > ___ > 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] BKG nutzt OSM Daten im Verfahren TopPlus
Das klingt ja sehr interessant. @Jochen: Weisst du, ob der Style/die Symbologie unter einer freien Lizenz steht? Dann möchte ich noch etwas zum Nachdenken ergänzen: Gleich nach dem von mir zitierten Abschnitt aus dem KN-Artikel steht weiter, dass die OSM-Daten durch Open Data ersetzt werden sobald diese in den umliegenden Ländern verfügbar sind. Als Beispiele werden u.a. die Niederlande genannt. LG, Stefan Am 6. Mai 2014 09:18 schrieb Markus : > Hoi Stefan, > > Das Bundesamt für Kartographie und Geodäsie (BKG) nutzt OSM Daten >> TopPlus >> > > TopPlus ist eine Planungskarte für Bundesbehörden. > Sie kombiniert die DE-Karten des BKG mit EU-Karten von OSM > um für Behörden-Einsätze eine grenzüberschreitende Karte > online und offline in einheitlichem Layout in verschiedenen Formaten > und in Druckqualität zur Verfügung zu stellen. > > Anwendungsbeipiele sind: > - Fußball Weltmeisterschaft > - Fußball Europameisterschaft > - G8-Gipfel > - Papstbesuch > - Castor-Transporte > - Grenzüberschreitende Fahndungen > etc. > > OSM hilft Grenzen zu überschreiten :-) > > Gruss, Markus > > ___ > 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
[Talk-de] BKG nutzt OSM Daten im Verfahren TopPlus
Hallo, Das Bundesamt für Kartographie und Geodäsie (BKG) nutzt OSM Daten - zusammen mit ihren (kostenpflichtigen bzw. nur Behörden zugänglichen?) Produkten! Das habe ich gefunden im aktuellen Heft der KN 2/2014 im Artikel "TopPlus – von der detaillierten Stadtkarte bis zur europaweiten Übersichtskarte" [1]. Man findet TopPlus auch auf den BKG-Seiten erwähnt. Ich werte das einerseits positiv, wird doch gesagt "Um das Gebiet der Nachbarstaaten bis zu den höchsten Auflösungen darstellen zu können, werden OpenStreetMap-Daten verwendet. (...). Erst der Einsatz dieser Daten ermöglicht (aber) die Produktion von grenz-übergreifenden Karten großer Maßstäbe. Damit wird erstmals bei einem BKG-Produkt der Versuch unternommen, amtliche Daten und freie Daten in einem Produkt zu integrieren. Andererseits wundert's mich, wie das rechtlich aussieht (bin aber kein Jurist und will keine Debatte vom Zaun brechen...). LG, Stefan [1] http://www.kartographische-nachrichten.de/kartographische-nachrichten/aktuelles-heft.html#c2044 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenFireMap
Gefunden via Wochennotiz Nr. 196 vom OSM Blog, http://blog.openstreetmap.de/blog/2014/04/wochennotiz-nr-196/ "Robert Koch hat – für Feuerwehren sicherlich sehr interessant – einen einfachen Editor für Hydranten entwickelt." Vielleicht könnten sich Openfiremap.org mit Osmhydrant.org zusammen tun? -S. Am 29. Januar 2014 11:07 schrieb Sven Geggus : > Lars Schimmer wrote: > > > Ich nehme an, da muß die API zur Abfrage des Mapnik Servers geändert > > werden. Wer ist dafür verantwortlich? > > Der Tileserver war anscheinend gerade mal kurz ausgefallen. > > Geht jetzt aber wieder. > > Gruss > > Sven > > -- > "The term "any key" does not refer to a particular key on the keyboard. It > simply means to strike any one of the keys on your keyboard or handheld > screen." (Compaq FAQ Entry 2859) > /me is giggls@ircnet, http://sven.gegg.us/ on the Web > > ___ > 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] ReMAPTCHA Demo BETA 0.2 online!
Hi,
Gerade folgender interessante Beitrag zur Diskussion rund um ReCaptchas
gesehen (via Wochennotiz Nr. 196 vom OSM Blog):
User Kerosin schrieb im OpenStreetMap Forum am 2011-12-19:
http://forum.openstreetmap.org/viewtopic.php?pid=413911#p413911
> Gerade auf golem.de gelesen:
http://www.golem.de/news/sicherheit-google-knackt-eigene-captcha-abfragen-1404-105937.html
> Google hat einen Algorithmus basierend auf Deep Convolutional Neural
Networks ("tief gefaltete neuronale Netzwerke")
> entwickelt, der eine über 90prozentige Erkennungsrate bei Hausnummern
hat. Dabei wurde auch festgestellt,
> dass sich Bilder aus dem eigenen Captcha-System recaptcha mit 99,8
prozentiger Wahrscheinlichkeit erkennen lassen.
>
> Hier das 13seitige Paper sowie ein Google-Blog-Post zum Thema recaptcha:
> http://arxiv.org/pdf/1312.6082v4.pdf
>
http://googleonlinesecurity.blogspot.de/2014/04/street-view-and-recaptcha-technology.html
Auch wir verwenden mit dem ReMAPTCHA einen "multi-faceted approach", d.h.
angepasste Strategien an.
Zudem sind unsere Texte länger, nicht im Bild zentriert und z.B. mehr
gekippt.
LG, Stefan
Am 7. April 2014 13:44 schrieb Stefan Keller :
> Am 5. April 2014 13:03 schrieb Alexander Heinlein <
> alexander.heinl...@web.de>:
>
> > Aber die aktualisierte Version ist noch nicht online, oder? Sieht für
> mich
> > aus wie die alte, oder übersehe ich etwas?
>
> Die vorherige (http://remaptcha.herokuapp.com/ ) sah gleich aus, die
> aktuelle prüft nun das zweite Kontrollwort "schärfer".
>
> Hier eine Variante 2 mit 2 Schritten: http://remaptcha2.herokuapp.com/
>
> LG, Stefan
>
>
>
> Am 5. April 2014 13:03 schrieb Alexander Heinlein <
> alexander.heinl...@web.de>:
>
> On Sat, Apr 05, 2014 at 12:24:20PM +0200, Stefan Keller wrote:
>> > Danke für euren Input! Wir haben das ReMAPTCHA [1] leicht aktualisiert.
>>
>> Aber die aktualisierte Version ist noch nicht online, oder? Sieht für mich
>> aus wie die alte, oder übersehe ich etwas?
>>
>> Grüße
>> Alex
>>
>>
>> ___
>> 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] ReMAPTCHA Demo BETA 0.2 online!
Am 5. April 2014 13:03 schrieb Alexander Heinlein : > > Aber die aktualisierte Version ist noch nicht online, oder? Sieht für mich > aus wie die alte, oder übersehe ich etwas? Die vorherige (http://remaptcha.herokuapp.com/ ) sah gleich aus, die aktuelle prüft nun das zweite Kontrollwort "schärfer". Hier eine Variante 2 mit 2 Schritten: http://remaptcha2.herokuapp.com/ LG, Stefan Am 5. April 2014 13:03 schrieb Alexander Heinlein : > On Sat, Apr 05, 2014 at 12:24:20PM +0200, Stefan Keller wrote: > > Danke für euren Input! Wir haben das ReMAPTCHA [1] leicht aktualisiert. > > Aber die aktualisierte Version ist noch nicht online, oder? Sieht für mich > aus wie die alte, oder übersehe ich etwas? > > Grüße > Alex > > > ___ > 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] ReMAPTCHA Demo BETA 0.2 online!
Hallo Danke für euren Input! Wir haben das ReMAPTCHA [1] leicht aktualisiert. Wir experimentieren nun mit einer zweistufigen Antwort: Zuerst kommt die Frage (sinngemäss): Gibt es eine Verbindung? Yes/No/Undecidable. Dann kommt ein einziges "Control Word" das es zu entziffern gilt. -S. P.S. Viel Spass bei der Schweizer Mapping Party heute ab 13:30 Uhr an der Wynigenstrasse 13 in Burgdorf! http://sosm.ch/mapping-party-burgdorf-april-5th-1330/ [1] http://remaptcha.herokuapp.com/ Am 29. März 2014 20:27 schrieb Martin Koppenhoefer : > Am 29. März 2014 18:15 schrieb Stefan Keller : > > > Wie oben erwähnt, muss eine CAPTCHA.Aufgabe in ein/zwei Sätzen erklärt > sein > > und innert wenigen Sekunden entscheidbar sein. Beides ist für die 18 > > Dachformen und deren Darstellung/Erläuterung nicht gegeben. Ich schätze, > > dass auch ein Mapper kaum ein Drittel der 18 Dachformen richtig benennen > > könnte. > > > > > man könnte eine Serie von typologischen Bildern (wo was in der Art wie oben > mal verlinkt) zum Anklicken anbieten z.B., wobei ich in gewisser Weise auch > bei Euch bin, 3D Mapping ist eher kein geeignetes Captcha Thema. Wenn es um > freie Eingaben geht, dann wird es in der Tat schwierig, weil man solche > Fachwörter normalerweise kaum auf Englisch kennt, und weil es für dieselbe > Form vermutlich gelegentlich mal mehrere Wörter passen (wenn sie auch nicht > inhaltsgleich sind, so gibt es öfters mal spezifische und allgemeine > Wörter, die beide passen), idealerweise aber derselbe Tag verwendet werden > sollte. > > Gruß Martin > ___ > 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] ReMAPTCHA Demo BETA 0.2 online!
Ich habe geschrieben: > Es ist richtig, dass man bewusst immer nur ein Wort falsch eingeben kann. Ich möchte noch folgendes ergänzen: Natürlich muss man erkennen, welches der beiden Wörter falsch eingegeben werden kann: Bei den reCAPTCHAs ist das bei Hausnummern-Bildern sehr gut erkennbar. Bei meinem ReMAPTCHA muss zuerst klar sein, welches und das ist auf der Karte nicht so einfach. Darum scheint das ReMAPTCHA für Menschen so einfach lösbar. Dann gibt es noch einen weiteren Schutz gegen Bots , der für alle reCAPTCHAs anwendbar ist (also auch für Dachformen): Nach der ca. dritten Fehleingabe schaltet man um auf Anzeigen, bei denen dem System beide Wörter bekannt sind (es gibt also kein Unknown Word mehr sondern nur noch zwei "Control Words". Das ist zurzeit beim ReMAPTCHA noch nicht implementiert. LG, Stefan Am 29. März 2014 18:26 schrieb Stefan Keller : > Hallo Henning > > Am 29. März 2014 16:57 schrieb Henning Scholland : > > ... > > Meine Gehirnleistung beim Captchaeingeben liegt primär darin, für die> > Art des Captchas die schnellste Lösung zu finden, die akzeptiert wird. > > Bei recaptcha ist das die Eingabe des verwurstelten Wortes, bei dir wäre > > es die Eingabe nur eines Wortes. Dies wäre gleichbedeutend mit einem > > "unverbunden". > > Es ist richtig, dass man bewusst immer nur ein Wort falsch eingeben kann. > > > Bei recaptcha ist das Filtern der "Faulheit" recht einfach, da es quasi > > keine Eingabe für die Aufgabe gab. Bei dir ist die Filterung meiner > > Einschätzung nach unmöglich. > > Verstehe deine Gegenüberstellung nicht: Ob nun systematisch nichts > eingegeben wird (wie bei meinem ReMAPTCHA) oder systematisch etwas > falsches, kommt doch auf dasselbe heraus. > Da G* und ich aber damit rechnen dass 4 von 5 Usern entweder ehrlich sind > oder nicht "faken", scheint mir 5 in etwa eine gute Zahl. Aber ich kann > auch auf 7 erhöhen. > Und die Diskussion was "gewagter" ist, ein freies OSM-Konto wo jeder > editieren kann was er will oder 4 von 5 User, die über etwas abstimmen, > hatten wir doch schon? > > -- Stefan > > > > Am 29. März 2014 16:57 schrieb Henning Scholland : > > Hallo, >> deine Idee, wenn x Leute das so beantworten, dann geht es "live" finde >> ich etwas gewagt. Wenn ich von meinem Captcha-Verhalten ausgehe sogar >> fatal. >> >> Meine Gehirnleistung beim Captchaeingeben liegt primär darin, für die >> Art des Captchas die schnellste Lösung zu finden, die akzeptiert wird. >> Bei recaptcha ist das die Eingabe des verwurstelten Wortes, bei dir wäre >> es die Eingabe nur eines Wortes. Dies wäre gleichbedeutend mit einem >> "unverbunden". >> >> Bei recaptcha ist das Filtern der "Faulheit" recht einfach, da es quasi >> keine Eingabe für die Aufgabe gab. Bei dir ist die Filterung meiner >> Einschätzung nach unmöglich. >> >> Henning >> >> >> ___ >> 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] ReMAPTCHA Demo BETA 0.2 online!
Hallo Henning Am 29. März 2014 16:57 schrieb Henning Scholland : > ... > Meine Gehirnleistung beim Captchaeingeben liegt primär darin, für die> Art des Captchas die schnellste Lösung zu finden, die akzeptiert wird. > Bei recaptcha ist das die Eingabe des verwurstelten Wortes, bei dir wäre > es die Eingabe nur eines Wortes. Dies wäre gleichbedeutend mit einem > "unverbunden". Es ist richtig, dass man bewusst immer nur ein Wort falsch eingeben kann. > Bei recaptcha ist das Filtern der "Faulheit" recht einfach, da es quasi > keine Eingabe für die Aufgabe gab. Bei dir ist die Filterung meiner > Einschätzung nach unmöglich. Verstehe deine Gegenüberstellung nicht: Ob nun systematisch nichts eingegeben wird (wie bei meinem ReMAPTCHA) oder systematisch etwas falsches, kommt doch auf dasselbe heraus. Da G* und ich aber damit rechnen dass 4 von 5 Usern entweder ehrlich sind oder nicht "faken", scheint mir 5 in etwa eine gute Zahl. Aber ich kann auch auf 7 erhöhen. Und die Diskussion was "gewagter" ist, ein freies OSM-Konto wo jeder editieren kann was er will oder 4 von 5 User, die über etwas abstimmen, hatten wir doch schon? -- Stefan Am 29. März 2014 16:57 schrieb Henning Scholland : > Hallo, > deine Idee, wenn x Leute das so beantworten, dann geht es "live" finde > ich etwas gewagt. Wenn ich von meinem Captcha-Verhalten ausgehe sogar > fatal. > > Meine Gehirnleistung beim Captchaeingeben liegt primär darin, für die > Art des Captchas die schnellste Lösung zu finden, die akzeptiert wird. > Bei recaptcha ist das die Eingabe des verwurstelten Wortes, bei dir wäre > es die Eingabe nur eines Wortes. Dies wäre gleichbedeutend mit einem > "unverbunden". > > Bei recaptcha ist das Filtern der "Faulheit" recht einfach, da es quasi > keine Eingabe für die Aufgabe gab. Bei dir ist die Filterung meiner > Einschätzung nach unmöglich. > > Henning > > > ___ > 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] ReMAPTCHA Demo BETA 0.2 online!
Am 29. März 2014 14:47 schrieb Martin Koppenhoefer : > > Am 29/mar/2014 um 12:32 schrieb Dirk Sohler : > > > > Ich glaube nicht, dass viele Zufällige Nutzer das richtig hin bekommen, > > und das sind nur die Grundformen :) > > > wieso nicht? sind ja wie erwähnt ein paar Grundformen, die kennt man schon, > Gauben werden bisher sowieso kaum getaggt, meistens wird es ein Satteldach > Pultdach oder Flachdach sein. Wie oben erwähnt, muss eine CAPTCHA.Aufgabe in ein/zwei Sätzen erklärt sein und innert wenigen Sekunden entscheidbar sein. Beides ist für die 18 Dachformen und deren Darstellung/Erläuterung nicht gegeben. Ich schätze, dass auch ein Mapper kaum ein Drittel der 18 Dachformen richtig benennen könnte. LG, Stefan Am 29. März 2014 14:47 schrieb Martin Koppenhoefer : > > > > Am 29/mar/2014 um 12:32 schrieb Dirk Sohler : > > > > Ich glaube nicht, dass viele Zufällige Nutzer das richtig hin bekommen, > > und das sind nur die Grundformen :) > > > > > > wieso nicht? sind ja wie erwähnt ein paar Grundformen, die kennt man > schon, Gauben werden bisher sowieso kaum getaggt, meistens wird es ein > Satteldach Pultdach oder Flachdach sein. > > > Gruß, > Martin > > > > ___ > 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] ReMAPTCHA Demo BETA 0.2 online!
Halo Christoph
> Ein richtiges OSM-CAPTCHA würde ein Mapping-Problem als Turing-Test
> verwenden. Bei den Dachformen könnte man beispielsweise 4 Häuser
> zeigen, ...
Das ReMAPTCHA würde ich aber auch zu den "richtigen OSM-CAPTCHAs zählen,
denn es verbessert das Routing.
Natürlich bin ich auch an anderen Ideen interessiert. Ein ReCAPTCHA zu
entwerfen ist aber recht anspruchsvoll.
Das Problem mit 4 Dächern ist, dass es in ländlichen Gegenden kaum 4
Gebäude hat von denen zwei Dachformen erst noch bekannt sein müssen.
> Dass es viele verschiedene Dachformen gibt ist dabei kein Problem - man
> würde einfach die häufigsten Varianten auslisten, idealerweise mit
> entsprechenden Skizzen, und dazu noch die Optionen 'andere Form'
> und 'da ist kein Haus' anbieten.
> ...
Lange Erläuterungen sind nicht praktikabel (und mit lang meine ich mehr als
ein Satz!): CAPTCHAs stören ja eigentlich die Absicht des (ehrlichen)
Users. Man muss sie in wenigen Sekunden verstehen und lösen können.
> Problematisch wäre natürlich, dass ein Spam-Bot immer noch eine
> wesentlich größere Chance hätte, per Zufallsantwort durchzukommen.
> ...
Genau: Während ein CAPTCHA für Menschen einfach sein soll, soll es für
Computer schwierig sein. Zeichenbasierte CAPTCHAs haben zig Millionen
Möglichkeiten! Ein CAPTCHA, das mit "nur" 500 Proben (d.h. 2 Dächer à 24
Formen) geknackt ist, gilt als unsicher.
LG, Stefan
Am 28. März 2014 23:42 schrieb Christoph Hormann :
> On Friday 28 March 2014, Stefan Keller wrote:
> > > Sieht für mich so aus, dass die Turing-Test-Funktion und die
> > > Mapping-Funktion im Moment vollkommen getrennt sind, also, dass es
> > > für das Ergebnis keinen Unterschied macht, ob man bezüglich der
> > > Karte die richtige oder die falsche Antwort gibt.
> >
> > Das Grundprinzip von reCAPTCHAs sind immer zwei Wörter (oder Bilder):
> > Eines (das "Control Word") ist dem System bereits bekannt, das andere
> > ist ein unerkanntes Wort ("unknown word") aus einem
> > Digitalisierungsprojekt. In Falle von meinem ReMAPTCHA sind sogar
> > beide Worte bekannt. Was tatsächlich unabhängig ist, das ist das
> > "Unknown Word" - in meinem Falle ist es die Tatsache ob das zweite
> > Wort überhaupt hingeschrieben wird.
>
> Das ist schon klar, der Turing-Test basiert dann aber ausschließlich auf
> der Texterkennung der Worte und hat nichts mit OSM und den Daten zu
> tun - die sind quasi nur schmückendes Beiwerk.
>
> Ein richtiges OSM-CAPTCHA würde ein Mapping-Problem als Turing-Test
> verwenden. Bei den Dachformen könnte man beispielsweise 4 Häuser
> zeigen, zwei davon welche, die bereits vorher mit gewisser
> Zuverlässigkeit erkannt wurden, dazu zwei neue. Wenn der Nutzer die
> beiden Referenzhäuser richtig erkennt, ist der Test bestanden und die
> Antwort zu den anderen beiden wird für die weitere Verwendung
> gespeichert.
>
> Dass es viele verschiedene Dachformen gibt ist dabei kein Problem - man
> würde einfach die häufigsten Varianten auslisten, idealerweise mit
> entsprechenden Skizzen, und dazu noch die Optionen 'andere Form'
> und 'da ist kein Haus' anbieten.
>
> Problematisch wäre natürlich, dass ein Spam-Bot immer noch eine
> wesentlich größere Chance hätte, per Zufallsantwort durchzukommen. Um
> das zu vermeiden, müsste man sich Fragen mit differenzierteren
> Antworten überlegen, man könnte den Nutzer zum Beispiel etwas im
> Luftbild markieren lassen.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] ReMAPTCHA Demo BETA 0.2 online!
Hallo Bernd Vielen Dank für den weiteren Hinweis. Das ist ein weiterer Fall, der mit Präprocessing gefiltert werden muss. Auf die "Rohdaten" (dass sind sämtliche Ways, die näher als 5m sind) haben wir bisher wenig geachtet. Wie gesagt, muss das daher noch verbessert werden. Findest du noch weitere (z.B. Situationen mit Haltestellen oder Fussgängerstreifen?) -- S. Am 29. März 2014 05:58 schrieb Bernd Wurst : > Hallo. > > Am 28.03.2014 16:48, schrieb Stefan Keller: > > Der von dir beschriebene spezifische Fall ist aber schon recht trickig - > > und es wird noch weitere trickige Fälle geben. > > Was mir grade bei einem erneuten Test begegnet ist: Ein Fußweg in einem > Gebäude. Das Gebäude ist in OSM korrekt erfasst, mit ein paar Fußwegen > innen drin. > > Da lässt sich auf dem Luftbild jetzt nicht grade eine Aussage treffen. :) > > Gruß, > Bernd > > > ___ > 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] ReMAPTCHA Demo BETA 0.2 online!
Hallo Christoph
Du hast geschieben:
> Sieht für mich so aus, dass die Turing-Test-Funktion und die
> Mapping-Funktion im Moment vollkommen getrennt sind, also, dass es für
> das Ergebnis keinen Unterschied macht, ob man bezüglich der Karte die
> richtige oder die falsche Antwort gibt.
Das Grundprinzip von reCAPTCHAs sind immer zwei Wörter (oder Bilder): Eines
(das "Control Word") ist dem System bereits bekannt, das andere ist ein
unerkanntes Wort ("unknown word") aus einem Digitalisierungsprojekt. In
Falle von meinem ReMAPTCHA sind sogar beide Worte bekannt. Was tatsächlich
unabhängig ist, das ist das "Unknown Word" - in meinem Falle ist es die
Tatsache ob das zweite Wort überhaupt hingeschrieben wird.
Wie einige schon gemerkt haben, kann man das natürlich ausnützen und das
"unknown word" (das mal das erste mal das zweite ist) falsch hinschreiben -
und den (Turing) Test trotzdem bestehen. Im Falle vom ReMAPTCHA kann man
vorsätzlich das zweite Wort hinschreiben (und den Test bestehen) im vollen
Bewusstsein dass das inhaltlich falsch ist.
Aus diesem Grund wird das reCAPTCHA (und auch meiniges) mehreren Personen
gezeigt.
> Beim Anschauen von knapp einem Dutzend Aufgaben fällt auch auf, dass die
> oft schwer lösbar sind, also dass man selbst durch gewissenhaftes
> Arbeiten nicht zuverlässig die richtige Antwort geben könnte. Oft
> liegt der entsprechende Anschnitt im Schatten oder die Auflösung reicht
> nicht aus.
Ja; das glaube ich. Das habe ich ja bei der Antwort an Bernd bereits
erwähnt, dass die Datenfilterung noch verbessert werden muss.
> ...
> Gut vorstellen könnte ich mir zum Beispiel Erkennung der
> Dachform von Häusern für das 3D-Mapping.
Die Dachform wäre das Was ist hier das Unknown Word. Wo ist das Control
Word für den Turing Test?
Meinst du, dass zwei Gebäude dargestellt werden und zwei Dachformen gefragt
werden (wobei die Dachform des einen bekannt ist)? Ich bin nicht sicher ob
man dazu genügende passende Daten findet.
Oder meinst du dass ein verzerrtes Control Word und ein Gebäudedach gezeigt
werden?
LG, Stefan
Am 28. März 2014 15:33 schrieb Christoph Hormann :
> On Friday 28 March 2014, Stefan Keller wrote:
> > Liebe alle
> >
> > Die ReMAPTCHA Demo BETA 0.2 ist nun endlich bereit zum Testen:
> > http://remaptcha.herokuapp.com/
> >
> > Sollte ja selbsterklärend sein... ;-O (ReMAPTCHA = "ReCAPTCHA for
> > MAPs")
>
> Sieht für mich so aus, dass die Turing-Test-Funktion und die
> Mapping-Funktion im Moment vollkommen getrennt sind, also, dass es für
> das Ergebnis keinen Unterschied macht, ob man bezüglich der Karte die
> richtige oder die falsche Antwort gibt.
>
> Beim Anschauen von knapp einem Dutzend Aufgaben fällt auch auf, dass die
> oft schwer lösbar sind, also dass man selbst durch gewissenhaftes
> Arbeiten nicht zuverlässig die richtige Antwort geben könnte. Oft
> liegt der entsprechende Anschnitt im Schatten oder die Auflösung reicht
> nicht aus.
>
> Vielleicht wäre es ein besserer Ansatz, mehrere einfachere Aufgaben zu
> stellen, dann könnte man auch den Turing-Test und die Mapping-Funktion
> verbinden. Gut vorstellen könnte ich mir zum Beispiel Erkennung der
> Dachform von Häusern für das 3D-Mapping.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> 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] ReMAPTCHA Demo BETA 0.2 online!
Hallo Andreas Danke für deine Tipps. Auf https habe ich noch nicht geachtet. Muss ich verbessern. LG, Stefan Am 28. März 2014 15:25 schrieb Andreas Neumann : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Moin, > > ich verwende HTTPS-Everywhere, weshalb ich automatisch auf die > HTTPS-Version[1] deiner Seite umgeleitet wurde. Dabei zeigte sich ein > Problem: Du bindest deine Scripte hart mittels HTTP-Link ein. Da > Chrome auf einer HTTPS-Seite ungesicherte Verbindungen standartmäßig > unterbindet, werden sämtlich Skripte nicht ausgeführt. > > Entweder du bindest deine Stylesheets, Skripte und Grafiken gleich via > https ein, oder du überlässt die Wahl des Protokolls dem Browser und > bindest z.B. "http://remaptcha.herokuapp.com/static/web/layout.css"; > nur als "//remaptcha.herokuapp.com/static/web/layout.css" ein. Der > Browser fügt dann automatisch das Protokoll ein, was er bereits für > den Abruf der Seite verwendet hat. > > MfG Andreas > > [1]https://remaptcha.herokuapp.com/ > > - -- > Andreas Neumann > http://map4Jena.de > http://Stadtplan-Ilmenau.de > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.14 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQGcBAEBAgAGBQJTNYZMAAoJENEKAxYRlUN9nq0L/1gtMlhl12vpmcNXKReSlJpf > CDnRHkB4F3H1aWduClOShAoa/kzK+o1umc6mjlP+sR47dTfuuIz1dVAMmGpQDfGR > nQYOYyvFTJhN+/FxNpGHQVmZnmalwcCs7SqtKOi8TdUwPL7L4mMuRoL9DuLe3nDe > +UD9V8WjCTGVcWAtFEzYnJZVk3Oc5Flu3ADXcsgFaVtz0UYEHTBzZBKoL7MIlvje > orgWo4zQvKG6P8Mfm2nRt/tbTB4xdALPUb7HMJI65hRCFXbN6gK4a0DQP/+j3DYr > ini86faaNmjANmEFy8WlTQ2gQjbaKbIqNRqI6aXZitccuHw8q7rAnvVYN+fB79pT > X61cHmNiY8aV4WSznPygQXKxVc1H4icSyNmnOkT5FnWKnfpGXOftI8pLGI1rTCpH > beODNawaDmqHFIsawFncbc8yyltDB5h49CR13P+4jTiFTxhPH+XwvXUohvH7p/yC > hzR9FsKFlKChGQCgQd3rfWWiZs4tGMznlawHWLgnWw== > =Q8Pi > -END PGP SIGNATURE- > > > ___ > 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
[Talk-de] ReMAPTCHA Demo BETA 0.2 online!
Liebe alle Die ReMAPTCHA Demo BETA 0.2 ist nun endlich bereit zum Testen: http://remaptcha.herokuapp.com/ Sollte ja selbsterklärend sein... ;-O (ReMAPTCHA = "ReCAPTCHA for MAPs") Was nicht alle realisieren: Mit der Eingabe von ein bzw. zwei Worten bestätigt man, ob die OSM-Ways eine Verbindung haben - oder eben nicht. Bei - sagen wir - 5 Übereinstimmungen betrachten wir diese Lösung als zuverlässig. Die Datengrundlage und die Performance sind noch nicht optimal: Als Datengrundlage musste ich mich beispielsweise auf die Schweiz beschränken, da ich möglichst detailreiche Luftbilder brauche (für Hinweise auf zugängliche Luft- und Satellitenbilder bin ich dankbar). Und die mangelnde Performance sieht man daran, dass man mit der Maus recht lange im Icon rechts oben warten muss, bis das Satellitenbild erscheint. Beachtet bitte, dass alles erst BETA ist und noch nichts in die OSM-DB geschrieben wird. Für Hinweise, Vorschläge und ermunternde (:-)) Kommentare bin ich dankbar. --S. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ReMAPTCHA Demo BETA 0.2 online!
Hallo Bernd > Was wäre da jetzt die richtige Antwort? Sind die verbunden oder nicht? Ja, gestützt spontan aufgrund deiner Aussage "durch einen Fußweg (geschätzt deutlich < 2 Meter breit) verbunden". Ich finde es keine falsche Strategie, "aus dem Bauch heraus" zu entscheiden falls auch ein Blick auf das Luftbild keine Klarheit bringt. Fragen dieser Art werden schätzungsweise von zwischen 3 bis 5 von 5 Benutzern mit "Ja" beantwortet - und mein Problem ist, wie damit umzugehen. Ich glaube die ReMAPTCHA DB müsste bei 3 oder weniger darauf verzichten, diese Verbindung hochzuladen. Wenn deine Frage aber rein auf das Problem abzielt, dass ein Auto angezeigt wird (weil wir das bei Service-Wegen so eingestellt haben), dann ist es eine Frage der Datenfilterung. Dieses Präprocessing muss auch noch verbessert werden (es gibt viele Fälle mit Fussgängerstreifen). Der von dir beschriebene spezifische Fall ist aber schon recht trickig - und es wird noch weitere trickige Fälle geben. LG, S. Am 28. März 2014 15:35 schrieb Bernd Wurst : > Hallo. > > Am 28.03.2014 14:56, schrieb Stefan Keller: > > Was nicht alle realisieren: Mit der Eingabe von ein bzw. zwei Worten > > bestätigt man, ob die OSM-Ways eine Verbindung haben - oder eben nicht. > Bei > > - sagen wir - 5 Übereinstimmungen betrachten wir diese Lösung als > > zuverlässig. > > Ich habe grade ein ReMaptcha gehabt das folgendermaßen aufgebaut war: > > W1: ---A->-->-->- > : > W2: -B--- > > Bei A war ein Auto-Symbol. > > Die Wege W1 und W2 sind parallele service-Wege (Parkplatz und separate > Firmen-Zufahrt), die an der fraglichen Stelle durch einen Fußweg > (geschätzt deutlich < 2 Meter breit) verbunden sind. > > Was wäre da jetzt die richtige Antwort? Sind die verbunden oder nicht? > > Gruß, > Bernd > > > ___ > 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
[Talk-de] Kort-Kampagne in Berlin anlässlich der FOSSGIS 2014
Liebe Leute Zur diesjährigen FOSSGIS gibt es in Berlin (und nur dort!) eine spezielle Kort-Kampagne: für alle gelösten oder überprüften "Objekt ohne Namen"-Aufträge gibt es 10 zusätzliche Koins! In Sachen Kort gibt es übrigens einige News, wir sind z.B. gerade dabei unsere Website komplett neu zu erstellen, endlich mit einem ordentlichen CMS dahinter. Und da CloudMade leider keine kostenlosen Tiles mehr anbietet, bereiten wir die Umstellung auf den Dienst von Lyrk [1] vor. Danach steht dann das Projekt "native App" auf dem Programm. Wir müssen die Realität anerkennen: der Durchschnittsbenutzer sucht seine Apps einfach im App Store/Play Store. Deshalb wollen wir (zumindest für iOS und Android) auch dort auffindbar sein. Und noch als Info: wir haben ab sofort ein deutschsprachiges Support-Forum beim Geoclub! [2] Für das Kort-Dev-Team Stefan [1] https://geodienste.lyrk.de/ [2] http://forum.geoclub.de/viewforum.php?f=175 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OpenStreetMap-Daten zu Karten aufbereiten: Freie Styles+Icons gesucht
Hallo! Ich bin daran, eine Dokumentation zusammenzustellen, wie man OpenStreetMap-Daten zu Karten aufbereitet [1]. Das Ziel ist, eigene "schöne" Karten erstellen zu können (mit TileMill), ev. im eigenen Ausschnitt, und zwar ohne Programmierkenntnisse (nur Skripts). 1. Falls jemand eine solche Doku. schon kennt, bitte melden. 2. Falls jemand Styles und Icons, bitte ebenfalls melden. Diese sollten idealerweise entweder auf den Shapefiles von Geofabrik-Download oder Daten von ogr2ogr, osm2pgsql oder spatialite_osm_map basieren - und in einer freien Lizenz sein. LG, Stefan [1] http://giswiki.hsr.ch/Making_Maps_from_OpenStreetMap_Data ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Telenav übernimmt Skobbler
Hallo "wn reader", liebe alle Interessante Nachrichten. Ich bin ja generell sehr für eine vermehrte kommerziellen Nutzung von OSM-Daten - dies aber immer in der Annahme, dass auch etwas in irgendeiner Form zurückgegeben wird. 1. Wenn ich mich nicht täusche, gibt gibt es beim Skobbler Navi-App ein Fehler-Rückmelde-Formular und MapDust [2] soll laut ihnen "eines der besten Verbesserungsportale für OpenStreetMap im Web" sein. Ich hoffe, das wird noch ausgebaut. => Weiss da jemand mehr? 2. Die Meldung oben wurden offenbar von Wall Street und u.a. von geoawesomeness übernommen. Da steht dann u.a. im Leadtext [2] "Telenav acquires OpenStreetMap leader Skobbler, (...). Telenav had acquired OpenStreetMap in 2013. Evidently Telenav is seeking to consolidate its position in the OSM domain." (!?!) => Dies sollte ev. berichtigt werden. LG, Stefan [1] http://www.skobbler.de/mapdust [2] http://geoawesomeness.com/telenav-acquires-openstreetmap-leader-skobbler/ 2014/1/31 wn reader : > Hallo, > > Telenav übernimmt Skobbler - http://www.skobbler.de > http://www.telenav.com/about/pr/pr-20140130.html > > Der Wert beläuft sich auf ca. 19,2 Mio. Dollar in Barmitteln plus 4,6 Mio. > Dollar in Stammaktien des Unternehmens. ( via > http://www.live-pr.com/telenav-bernimmt-mit-skobbler-das-f-hrende-r1050246598.htm > ) > > Steve hat dazu gebloggt - > http://stevecoast.com/2014/01/30/its-time-to-make-openstreetmap-your-only-street-map/ > > > ___ > 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
[Talk-de] Projekt Ahaus-Heek-Legden und Map-Wizard
Hallo Kann jemand mehr berichten über den "Map-Wizard" (http://www.map-wizard.com/) und das Touristik-/Kulturlandschafts-Kartierungs-Projekt Ahaus-Heek-Legden: http://www.ahaus.de/2328.0.html?&print=1&no_cache=1(gefunden via Wochennotiz Nr. 178 vom Dezember 2013!)? LG, S. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] WG: Vorträge für FOSSGIS/OSM Konferenz 2014 gesucht
Am 2013-11-15 19:51:40 schrieb !i! im Forum: Hallo, für die FOSSGIS Konferenz im kommenden März in Berlin, sucht unbedingt noch Vorträge. Bisher sind erst etwa 20 eingegangen und das ist ja ein bissel mau, nech wink Da es AFAIK DAS zentrale Zusammentreffen der deutschsprachigen Community ist, wäre es super, wenn auch die OSM Community zeigt, was 2013/2014 so entstanden ist, oder gerade heranreift: http://www.fossgis.de/konferenz/2014/callforpapers/ (Einsendeschluss 30.11.) Ich selbst finde es schade, dass man sich keine Themen "wünschen" kann, hört man hier doch von so vielen spannenden Sachen. Für Themen mit mehr Interessenten kann man dann ja auch mal gezielt Leute anschreiben, die sich mit der Materie befassen. Ich hab deshalb einfach mal angefangen was aufzuschreiben und bin gespannt, was euch noch so auf den Nägeln brennt: https://etherpad.mozilla.org/mx92b22SRg (auch wenn ihr nur an Videos interessiert seid, bereichert bitte unser Meinungsbild!) P.S: Leute die Interesse haben da was einzureichen, aber sich aus verschiedenen Gründen nicht trauen, die kann ich beruhigen. Die Konferenz ist von sehr angenehmer Größe und mit sehr gutem Publikum (Mapper Free-GIS ExpertenVerwaltung). Auch wer finanziell nicht so gut darstellt, kann über Fahrgemeinschaften und den FOSSGIS auf Nachfrage noch Geld sparen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KeepRight seeks volunteers to help maintaining the website
Another addendum: There is a SVN mirror on github: https://github.com/CloCkWeRX/keepright-mirror We found one person who is willing to take over. Now we need at least another one... -S. 2013/10/13 Stefan Keller > Addendum: Just in case Harald is not reachable: I'm available to answer > questions and coordinate communicatins around KeepRight for a while until > the new "project leaders" have been found. > > Yours, S. > > > 2013/10/13 Stefan Keller > >> Hi, >> >> The founder of KeepRight [1] seeks volunteers who are willing to take >> over maintaining the website! >> >> KeepRight is a well-known and important quality assurance tool for OSM >> [2]. Many projects rely on it, like the "Quality Assurance Tools script" >> for JOSM [3] or the Kort Game [4]. >> >> Please contact Harald at keepright at gmx dot at if you are interested >> or have questions. >> >> Yours, S. >> (found via german OSM forum [5]) >> >> [1] http://keepright.at/ >> [2] http://wiki.openstreetmap.org/wiki/Keep_Right >> [3] http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script >> [4] http://wiki.openstreetmap.org/wiki/Kort_Game >> [5] http://forum.openstreetmap.org/viewtopic.php?id=22784 >> > > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KeepRight seeks volunteers to help maintaining the website
Addendum: Just in case Harald is not reachable: I'm available to answer questions and coordinate communicatins around KeepRight for a while until the new "project leaders" have been found. Yours, S. 2013/10/13 Stefan Keller > Hi, > > The founder of KeepRight [1] seeks volunteers who are willing to take over > maintaining the website! > > KeepRight is a well-known and important quality assurance tool for OSM > [2]. Many projects rely on it, like the "Quality Assurance Tools script" > for JOSM [3] or the Kort Game [4]. > > Please contact Harald at keepright at gmx dot at if you are interested or > have questions. > > Yours, S. > (found via german OSM forum [5]) > > [1] http://keepright.at/ > [2] http://wiki.openstreetmap.org/wiki/Keep_Right > [3] http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script > [4] http://wiki.openstreetmap.org/wiki/Kort_Game > [5] http://forum.openstreetmap.org/viewtopic.php?id=22784 > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] KeepRight seeks volunteers to help maintaining the website
Hi, The founder of KeepRight [1] seeks volunteers who are willing to take over maintaining the website! KeepRight is a well-known and important quality assurance tool for OSM [2]. Many projects rely on it, like the "Quality Assurance Tools script" for JOSM [3] or the Kort Game [4]. Please contact Harald at keepright at gmx dot at if you are interested or have questions. Yours, S. (found via german OSM forum [5]) [1] http://keepright.at/ [2] http://wiki.openstreetmap.org/wiki/Keep_Right [3] http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script [4] http://wiki.openstreetmap.org/wiki/Kort_Game [5] http://forum.openstreetmap.org/viewtopic.php?id=22784 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tourism = viewpoint?
Nicht jeder Berg ist ein Berg :-) siehe die Kriterien hier [1]. Von daher macht "tourism = viewpoint" von mir aus schon Sinn. Ein ähnlicher Fall ist "tourism = yes". Das wird ja benutzt um die touristische Bedeutung eines, durch andere Tags beschriebenen, Objektes anzugeben. LG, Stefan [1] http://de.wikipedia.org/wiki/Berg Am 11. Juli 2013 17:09 schrieb Tirkon : > Sven Geggus wrote: > > >Also Leute ehrlich. Wie kann man nur auf die völlig bescheuerte Idee > >kommen 8000er Gipfel als "tourism = viewpoint" zu taggen? > > Und es wird noch verrückter: Wir dürfen auch all die Kioske mappen, > die dort eröffnet werden - ideal, um dort insbesondere die Bücher von > Reinhold Messner zu verkaufen. ;-) > > https://www.youtube.com/watch?v=D_pwYa58PRY > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Überarbeitung OSM Inspector Adress-Layer / OSM Inspector Address Layer revamp
Hoi Tobias Interessante Diskussion und gut dass du gefragt hast :-) Du hast geschrieben: > - Ein Voronoi-Diagramm mit Postleitzahlen. Voronoi ist m.E. bereits lösungsbezogen. Da gibt es ev. treffendere Begriffe und vielleicht gibt es ja bessere Ansätze: Bei Voronoi wird jede Region wird durch genau ein Zentrum bestimmt. Was hier doch gesucht ist, das ist die Abgrenzung zwischen "Punktwolken", bzw. Gebäudegruppen, wobei es auch Ausreisser haben kann, seien es korrekte (weil der Pöstler mal schnell den anderen Briefkasten bedient, daher ja de Name Post-Leit-Zahl) oder sei es weil es ein Fehler in den Daten ist. Ich würde von Flächen-Segmentations-Algorithmus sprechen und als Lösungsansatz z.B. Clustering-Algorithmen anschauen, z.B. [1] LG, Stefan [1] http://pointclouds.org/documentation/tutorials/cluster_extraction.php Am 2. Oktober 2013 07:43 schrieb Toggenburger Lukas < lukas.toggenbur...@htwchur.ch>: > Ich versuche mal eine Zusammenfassung vom bisher gesagten zu machen. > Folgende neue Wünsche habe ich herausgelesen: > > - Häuser als adressiert anerkennen, wenn ein oder mehrere Hausnummern auf > den Eingängen (bzw. auf dem Gebäude) getaggt sind. > > - Glaubwürdigkeitsklassen: Anzahl anderer Strassen zählen, die eine > Verbindungslinie Haus<->Zugehörige Strasse kreuzt (bzw. Anzahl Strassen > zählen, die näher liegen, als die in der Adresse eingetragene Strasse) > > - Ausgabe von nicht-getaggten Häusern als GPX, damit man diese unterwegs > anvisieren kann. Und/oder: Link generieren, der mittels Overpass das > ausgibt, was auch im OSMI sichtbar ist. > > - GUI: Shortcut um alle Fehler-Arten anzuzeigen (in der bisherigen > Version: no addr:street tag, street not found, interpolation lines with > errors) und evtl. andere Angaben gleichzeitig ausblenden > > - Fehlende Postleitzahlen (evtl. auch fehlendes addr:city=, fehlendes > addr:country=) markieren (evtl. nur dort, wo schon Adressangaben vorhanden > sind) > > - Ein Voronoi-Diagramm mit Postleitzahlen. Ich nehme an, das gibt/gab es > jedoch schon unter http://osm.wno-edv-service.de/plz . > > - Konfliktierende Adress-Angaben finden: Z.B. Postleitzahl aus > addr:postcode <-> PLZ aus PLZ-Polygon > > Habe ich etwas übersehen? > > Bezüglich den Tagging-Schemata, ob und wie z.B. PLZ erfasst werden sollen, > möchte ich niemandem Vorschriften machen. Es sollte jedoch erkannt werden, > wenn es widersprüchliche Angaben hat, damit das jemand reparieren kann. > > Grüsse > > Lukas > ___ > 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] Info zu einer Arbeit über metrische Distanzmessung
Hallo Peter Interessant. Scheint so etwas ähnliches wie der proprietäre" aber bewährte PhotoModeler zu sein [1]. Nur damit ich es richtig verstehe: 1. Der geplante Ablauf - z.B. für die Bestimmung der Höhe einer Kirchturmspitze - geht so: * Der Benutzer macht mit dem Smartphone mind. zwei Bilder im seitlichen Abstand von einigen Metern * (wie der exakte Abstand gemessen wird ist noch offen). * Der Benutzer bezeichnet (oder bestätigt) eine in den Bildern gemeinsame horizontale Kante (z.B. seitliche Turmmauer) * Wenn die SW fertig gerechnet hat, zeigt der Benutzer auf die Kirchturmspitze und erhält dessen Höhe ? 2. Und deine Idee besteht darin, die in der Studentischen Arbeit erarbeitete Desktopkomponente, welche die eigentliche 3D Rekonstruktion macht, in ein App zu packen (obschon die SW schon auf dem Desktop einige Zeit braucht und an Ressourcengrenzen stösst)? LG, Stefan [1] http://www.photomodeler.com/products/how-it-works.html Am 22. August 2013 14:46 schrieb Peter Barth : > Hallo Stephan, > > Stephan Knauss schrieb: > > > [1] http://www.forwiss.uni-passau.de/extern/doc/BA_Stier_Reimar.pdf > > > > nette Arbeit. Erinnert mich etwas an das was Marek gemacht hat. > > das muss ich jetzt aber glaub ich doch kurz nochmal klarstellen, dass > das etwas grundlegend anderes ist. Marek beschreibt da im Prinzip > Fotogrammetrie, die erhebliche Nachteile gegenüber einer richtigen 3D- > Rekonstruktion hat: > > * "schlechte" Abbildungseigenschaften der Kamera die nicht ausgeglichen > werden (Stichwort: Verzeichnung, Folge: Ungenauigkeit) > * geringe und ungenaue Grundlage für die Metrik (Höhe der Kamera, Ebene > vor Gebäude, Ausrichtung der Kamera) > * nur Höhen an Ebenen messbar (die Höhe eines Kirchturms kannst du damit > z.B. nicht bestimmen) > > Die Arbeit beschreibt bzw. vergleicht sich übrigens auch gegen andere > Methoden und stellt vor allem auch die von mir kurz angesprochenen > Vorteile heraus. Hauptnachteil ist "nur", dass es keine fertige App > gibt. Dann wäre dass nämlich erheblich einfacher als mit Fotogrammetrie. > > Gruß, > Peda > > -- > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass API 0.7.4: Differenz-Operator
Lieber Roland Hut ab wie du es schaffst, ein recht performantes und verlässliches OSM API für die weltweite OSM-DB zu implementieren - und es erst noch immer weiter auszubauen! Ich weiß, wovon ich spreche, wenn ich an den Betrieb des Kort Games denke. Der Differenz-Operator ist eine sinnvolle Erweiterung. Nur bin ich mit der Benennung nicht so glücklich - wie mit anderen Syntax-Elementen ja auch/nicht (wie namentlich print und recurse). Diese Differenz gehört zu den "Set Operationen" und gemäss SQL Standard heissen die UNION, INTERSECT und EXCEPT - und sie werden unterstützt u.a. von PostgreSQL, MySQL/MariaDB, SQLPlus sowie von MS SQL Server und DB2. Nur Oracle weicht davon ab und kennt statt EXCEPT => MINUS. "Difference" ist mir zu nahe an "Intersect". Natürlich muss die Overpass API nicht SQL übernehmen, doch gibt SQL eine schöne theoretische Basis her (z.B. dass ein weiterer Operator "INTERSECT" heissen könnte :-). Ich schlage daher vor, lieber vom EXCEPT Operator/Statement zu sprechen. Was meinst du dazu? LG, Stefan Am 2. August 2013 17:54 schrieb Roland Olbricht : > Liebe Mitmapper, > > eine neue Version der Overpass API, Version 0.7.4 steht auf > http://overpass-api.de > zur Verfügung. Auf der Rambler-Instanz folgt das Update in den nächsten Tagen. > Neben zahlreichen behobenen Bugs ist vor allem die Abfrage nach Ways und damit > auch Relationen in kleinen Bounding-Boxen effizienter geworden. Damit sollte > sich mit dem POI-Overlay-Prototyp > http://overpass.apis.dev.openstreetmap.org/ > jetzt zügig arbeiten lassen. > > An Erweiterungen der Syntax gibt es zwei: Zum einen "global deklarierte > Bounding-Boxen"; diese werde ich morgen genauer erläutern, wenn das > korrespondierende JOSM-Plugin mirrored_download sich aktualisiert hat. > > Zum anderen der Differenz-Operator. Er dient dazu, Suchen der Art "alle > Objekte die X haben/sind, aber nicht Y haben/sind" zu finden. Zum Beispiel > hier alle Nodes, die einen Wert für "maxheight" gesetzt haben, aber nicht Teil > einer Straße (d.h. eines ways mit Tag "highway") sind: > > http://overpass-turbo.eu/s/I6 > > // Neu in Overpass 0.7.4: Der Differenz-Operator > > [bbox:50.6,7.0,50.8,7.3]; > ( > node[maxheight]; // Alle Nodes mit irgendeinem Wert für "maxheight" > - > (way[highway];>;); // die nicht auf irgendeiner Form von Straße liegen > ); > out; > > Für den besonders häufigen Fall, dass es um "hat Tag X, aber nicht Tag Y" > geht, empfehle ich weiterhin die bekannte Syntax mit "[...!~...]". Diese > arbeitet effizienter als der Differenzoperator es kann. > > http://overpass-turbo.eu/s/I8 > > // Neu in Overpass 0.7.4: Der Differenz-Operator > // > // Wenn es bloß um nicht gesetzte Tags geht, sollten diese lieber > // als Bedingung aufgelistet werden und nicht als Differenz-Operator. > // Das funktioniert schneller > > [bbox:50.7,7.0,50.75,7.1]; > ( way[highway=residential][name!~'.']; // Ways mit Tag "highway", aber ohne > Tag "name". > >; > ); > out; > > Alle Details zur neuen Version gibt es im Wiki: > http://wiki.openstreetmap.org/wiki/Overpass_API/versions > > Viele Grüße, > > Roland > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?
Hallo, Es gibt zurzeit etwa drei bis vier Threads zu diesem Thema. Da blickt keiner mehr durch... Ich schlage daher vor, die Diskussion hier zu einem vorläufigen Ende zu bringen. Ich glaube, dass es einen guten Vorschlag und es eine Konvergenz der Meinungen gibt, dass es einen verbesserten Datenschutzhinweis beim Anmelden braucht. Weitere (theoretische) Möglichkeiten habe ich im Thread "Datenschutz Warnung im englischen OSM Wiki" zusammengestellt. Und ich teile auch Marc Gehling's Hinweis, dass Frederik und Simon sich schon geäussert haben. Und nur auf talk-de zu posten oder mal einfach etwas (auf deutsch) ins Wiki zu schreiben, bringt wenig! LG, Stefan Am 29. Juli 2013 22:58 schrieb Michael Paulmann : > Am 28.07.2013 21:59, schrieb Frederik Ramm: >> >> Hallo, >> >> On 28.07.2013 17:00, Kai Krueger wrote: >>> >>> Natuerlich jeder Schutz ist mit genuegend Aufwand zu ueberwinden. Die >>> Frage >>> ist wieviel Aufwand ist es dem "Angreifer" wert, und wieviel ist der >>> Schutz >>> dem Nutzer Wert in form von Einschraenkungen. Das Problem ist, das dank >>> "Big >>> Data" und der Freizugigkeit der Daten, diese Balance stark in Richtung >>> Auswertung verschoben wurde. Nun ist die Frage, kann man durch technische >>> und politische Massnahmen diese Balance wieder zum Wohle des Nutzers >>> veraendern. >> >> >> Ich denke mal, die Terminologie "Angreifer" wird der Sache nicht gerecht. >> Die meisten Leute, die irgendeine Auswertung basteln, wollen damit ja einen >> Nutzen fuer das Projekt stiften. Wenn wir denen sagen wuerden, dass sie die >> Daten nicht zu diesem und jenen Zweck nutzen sollen, dann wuerden die sich >> vermutlich auch dran halten und nicht nach Luecken suchen. >> >> Allerdings haben wir bislang darauf gebaut, dass Dritte aus eigenem >> Antrieb mit unseren Daten coole und nuetzliche Anwendungen bauen, die das >> Projekt voranbringen, ohne uns vorher um Erlaubnis fragen zu muessen. >> >> Ich kann mit ziemlicher Sicherheit sagen, dass die OSM Foundation nicht >> die Ressourcen haette, irgendeine Einzelfallpruefung vorzunehmen, um so >> einzelnen Leuten mit lauteren Absichten mehr Daten zuzubilligen als anderen. >> >> Auf Anhieb fallen mir die Untersuchungen zur Datenqualitaet den englischen >> Professors Muki Haklay ein; er hat u.a. festgestellt, dass die >> Datenqualitaet in Grossbritannien in einem betrachteten Planquadrat ab einer >> gewissen Mindest-Anzahl aktiver Mapper in aller Regel eine geforderte >> Mindestgrenze ueberschreitet - die genauen Zahlen kenn ich nicht mehr, aber >> seine Betrachtungen waren durchaus interessant und haetten ohne Zuordnung >> von Edits zu Accounts nicht gemacht werden koennen. >> >> Auch beim Analysieren groesserer Importe oder Massen-Edits kommt man oft >> schnell an den Punkt, wo man mehr braucht als das Ergebnis einer >> API-Abfrage. Ich wuerde mich sehr unwohl dabei fuehlen, wenn das Projekt >> sich in diesen Dingen kuenftig nicht mehr "selber helfen" koennte, sondern >> zwangsweise auf die Exekutive der OSMF angewiesen waere. >> >> >> Also wenn ich vor die Wahl gestellt werde, entweder die Daten aller ein >> bisschen weniger zu schuetzen oder alternativ dazu eine Machtverschiebung >> von "dem Projekt insgesamt" zur OSMF vorzunehmen, dann wuerde ich lieber den >> reduzierten Datenschutz waehlen. >> >> Bye >> Frederik >> > +100 > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenschutz Warnung im englischen OSM Wiki
Hallo Mark Ich finde deine Bemerkungen gut. Nachdem auch Frederik - als Mitglied der DWG - sich eine Verbesserung vorstellen kann, glaube ich, dass wir uns damit einer Lösung nähern. Diese sollte nun aber vom DWG vorgeschlagen werden (wohl auf englisch) und die Diskussion hier könnte damit etwas abgekürzt werden. Ich persönlich war auch ganz kurz erstaunt, realisierte dann schnell, was es heissen würde, wenn die History ohne Usernamen angegeben würde und erinnerte ich mich an meine Wikipedia-Zeiten, wo es selbstverständlich ist, dass man den Usernamen angibt. Da OSM auch vorbildlich sein soll in Sachen Datenschutz, habe ich mir kurz auch in wissenschaftlicher Literatur umgesehen und folgendes gefunden [1] S.11-12 "Auf europäischer Ebene sind derzeit Bestrebungen für einen stärkeren Datenschutz im Gang. So bemängelt die EU-Kommission insbesondere die in Onlineumgebungen oft unklaren, schwierig zu findenden und intransparenten Datenschutzhinweise. Ferner fordert sie bessere Kontrollrechte für Personen, die von der Datenbearbeitung betroffen sind. Im Hinblick auf geographische Positionsangaben empfiehlt ein beratendes Gremium der EU-Kommission, dass Ortungsdienste standardmässig – d.h. in der Voreinstellung – abgeschaltet sein müssen. Zudem sollten Personen, die der Verwendung «ihrer» Ortungsdaten zugestimmt haben, ihre Einwilligung jährlich wiederholen müssen und diese sehr einfach widerrufen können. Für Ortungsfunktionalitäten, die dem Nutzer nicht bewusst sind, müssten die Anbieter verpflichtet werden, ein ständiges Warnzeichen aufzuschalten." Eins-zu-eins auf OSM umgelegt hiesse das, dass es 1. gute Datenschutzhinweise geben soll (wie bereits vorgeschlagen), 2. dass man seine Einwilligung jährlich wiederholen muss, 3. diese einfach widerrufen können muss und 4. ein "ständiges Warnzeichen aufzuschalten" ist (in OSM: beim Editieren). Eigentlich reichen mir als erster Schritt etwas verbesserte Datenschutzhinweise! LG, Stefan [1] "Geographische Wegmarken in der Cyberwelt" (2010) http://www.empa.ch/plugin/template/empa/*/121836/---/wegmarken.pdf Am 30. Juli 2013 00:39 schrieb Mark Obrembalski : > On 29.07.2013 22:11, Tirkon wrote: > >> Ich weiß vermutlich seit der ersten Woche bei OSM, dass der Username >> an jeder Änderung hängt. Das merkt man spätestens dann, wenn man die >> Chronik aufruft. Mir war aber nicht bewusst, dass dieser mit >> herausgegeben wird. > > > An diesem Punkt war mir das auch nicht so direkt bewusst in dem Sinn, dass > das zu den ersten Dingen gehört hätte, über die ich mir groß Gedanken > gemacht hätte. Da ich aber etwa die Wikipedia schon kannte, wo man fremde > Usernamen sieht sobald man in eine Versionsgeschichte oder auf eine > Diskussionsseite schaut, war es aber sicher etwas, was ich jederzeit als > naheliegend angesehen hätte, wenn ich denn einen Grund gehabt hätte, darüber > nachzudenken. Außerdem hielt und halte ich es für normal, dass Leute, die > einen wertvollen Beitrag zu einem Publikationsprojekt leisten, in > irgendeiner Weise durch Nennung mit Namen (wenn sie sebst unter Pseudonym > auftreten, mit dem von ihnen gewählten Pseudonym) gewürdigt werden. Unter > Umständen ist das ja sogar rechtlich geboten. In OSM waren ja alle ganz > fürchterlich vorsichtig mit den Urheberrechten und ähnlichem (das ist auch > heute noch ungefähr so) - auch von daher lag es also nahe, dass die Benutzer > entsprechend als Quelle genannt werden. > > Ziemlich schnell habe ich aber auch fremde Benutzernamen gesehen, einfach > indem ich mir zu einem Objekt mal eine Versionsgeschichte angeschaut habe. > Auch auf der Mailingliste tauchte recht bald ein Hinweis der Art "Die > Bearbeitungen von xyz schauen komisch aus, kann da mal jemand nachschauen?" > auf. Spätestens an dem Punkt war es also sonnenklar, dass zumindest jeder > OSM-Benutzer nachschauen kann, welche Bearbeitung von wem stammt. Und > OSM-Benutzer kann ja jeder leicht werden. > > >> Zudem habe ich freie >> Projekte eigentlich immer als die Datenschutz-freundliche Bastion im >> Internet angesehen. > > > Das sind sie ja auch einigermaßen, einschließlich OSM im gegenwärtigen > Zustand. OSM verlangt von niemandem, dass er bei der Anmeldung seinen Namen, > seine Adresse oder sonst was (außer einer Mailadresse - kann man ja auch ne > Wegwerfadresse nehmen) angibt. OSM drängt seine Benutzer nirgends, doch ganz > viel über sich einzugeben, man wolle doch so richtig dabeisein. OSM hat auf > seinen Seiten keine Like-Buttons, kein Google Analytics, keine > Reichweiten-Zählpixel, keine Werbenetzwerke. OSM versucht auch nicht, fremde > Seiten mit Like-Buttons oder Zählpixeln zu pflastern. OSM betreibt keine > Paralleldienste, mit denen es möglich wäre, bei den Benutzern Daten aus ganz > anderem Kontext abzugreifen und zusammenzuführen (schau dir mal an, was an > einem Google-Account alles für Lebensbereiche hängen können). OSM verkauft > keinerlei Daten - alle Daten, die OSM abgibt, kann sich jeder ohne weiteres > anschauen. Bill Gates kriegt
Re: [Talk-de] Datenschutz Warnung im englischen OSM Wiki
Am 27. Juli 2013 23:03 schrieb Dirk Sohler : > Das fängt ja schon damit an, dass weder auf openstreetmap.de noch auf > openstreetmap.org von der „Landingpage“ aus ein auch so bezeichneter > Link ins Wiki zu finden ist, noch dass die Lizenzbestimmungen für Laien > ohne weiteres zu finden sind. Im Web üblich ist ein Link zur Policy. Und auf besagten „Landingpages“ - wie auf praktisch allen *.osm.* Seiten hat es das. Ich finde es gut, wenn Leute wie u.a. du und Tirkon sich für "Transparenz" einsetzen. Das Problem ist, dass man die Leute auch "zutexten" kann (auf Webseiten und allgemein), was unnötig ist und abschreckend wirkt. Gerade im Web klickt man (und damit meine ich praktisch jedermann/frau) weiter, wenn da mehr als drei Zeilen stehen. Und der Vorschlag, der hier zur Debatte steht ist mehr als drei Zeilen lang - und immer unvollständig wenn nicht seinerseits irreführend. Ich unterstütze daher ein besonnenes Vorgehen wo der Text an einer Stelle steht und darauf verlinkt wird, wie dies u.a. Simon und Frederik geschrieben haben. LG, Stefan Am 27. Juli 2013 23:03 schrieb Dirk Sohler : > Frederik Ramm schrieb: >> Und so weiter. Ich finde es daher nicht fair, davon zu sprechen, dass >> die Hauptseite ein "schiefes Bild" vermittelt. Sie geht auf viele >> Details des Projekts nicht ein, […] > > Vor allem nicht auf die negativen Details – Und dies auch anderswo > nicht deutlich. Es sollte in verständlicher Sprache (und damit meine > ich nicht verklausulierte Lizenssprache) deutlich darauf hingewiesen > werden, was (um beim Thema zu bleiben, aber das gilt natürlich auch für > alle anderen Details) mit den Daten passiert, und welche Daten das im > einzelnen sind, und was die Konsequenzen sind. > > Das fängt ja schon damit an, dass weder auf openstreetmap.de noch auf > openstreetmap.org von der „Landingpage“ aus ein auch so bezeichneter > Link ins Wiki zu finden ist, noch dass die Lizenzbestimmungen für Laien > ohne weiteres zu finden sind. > > Den Beginners Guide muss man auch erst mal suchen. Für jemanden, der > vielleicht nur ein paar Hausnummern in seiner Umgebung mappen möchte, > oder dem aufgefallen ist, dass seine Straße falsch erfasst wurde, ist > das schlicht nicht gangbar. > > Klar, es ist nicht so, das verheimlicht wird, was mit den Daten > passiert, aber es ist eben auch nicht so, dass es den Usern leicht > gemacht wird, an die Informationen zu kommen. > > Grüße, > Dirk > > -- > Local time :: Ortszeit :: DE-HH > 2013-07-27T22:54:16+0200 > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Masi Finde deine Überlegungen interessant, v.a. der Teil Am 23. Juli 2013 00:13 schrieb Masi Master : ... > Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von > Routern nicht mehr berücksichtigt werden und aufgrund des Datums können > alle "überfälligen" Baustellen aus der Datenbank gelöscht werden. Ok. Aber warum zwingend mit Relationen? > Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie > sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, > versteht sich) > Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich > taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. Stimmt. Die langen Tags sind problematisch. Aber immer noch das kleinere Übel als Tags, die voneinander abhängig sind. Könnte man z.B. eine temporäre Sperrrung nicht so erfassen - gemäss Eckharts Hinweis auf das bereits existierende [1]? motor_vehicle:conditional=no @ (2014-07-27..2014-07-28) LG, Stefan [1] http://wiki.openstreetmap.org/wiki/Conditional_restrictions Am 23. Juli 2013 00:13 schrieb Masi Master : > Am 22.07.2013, 20:25 Uhr, schrieb Frank : > > >> Am 22.07.2013 08:07, schrieb Eckhart Wörner: >>> >>> Hallo Alexander, >>> >>> Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner: Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche neuen Erkenntnisse? >>> >>> >>> • gesperrte Straßen: >>> http://wiki.openstreetmap.org/wiki/Conditional_restrictions >>> • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen >>> • zusätzliche amenities: opening_hours? >>> >>> Eckhart >>> >> >> Ich denke, es ging Alexander eher um die Frage, ob man die temporären >> Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen >> sollte. >> >> Es wäre zwar nett, wenn die Karte auch während des "Ausnahmezustandes >> Stadtfest" aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich. >> Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend >> eingerichtet wurden. >> >> Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie. >> >> Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt >> dann wochenlang mit diesen "Sonder-Anpassungen" herum. Auch andere Auszüge >> werden nicht täglich aktualisiert. >> >> Ich denke, die OSM-Datenbank sollte nur den "Normalzustand" wiedergeben >> und nicht den temporären Ausnahmezustand. >> >> Dies kann evtl. auf einer Webseite oder in Flyern durch "Overlays" >> dargestellt werden. > > > > Das Problem ist doch, dass das zeitliche Sperren nicht funktioniert und zu > lange in der Datenbank bestehen bleibt (oft wird die Sperrung vergessen > aus OSM herauszunehmen) > Angenommen eine Straße hat das Tagging motorcycle=no + mofa=yes. > Nun kommt einer und will die Straße mit access=no sperren. Funktioniert > natürlich nicht für Mofas und alle anderen (vorher überflüssigen) *=yes > Tags werden zum Verhängnis. > date_on & date_off geht genausowenig, da nicht klar ist, auf welche Tags > es sich bezieht. > > Eine mögliche Lösung ist eine Baustellen- oder Sperrungs-Relation, die > alle access tags der Wege nicht beachtet und mit access=no überschreibt. > Gleichzeitig kann die Relation weitere access tags aufnehmen, zB Freigabe > für Fußgänger und Radfahrer, oder Freigabe für Anwohner. Bei der Relation > MUSS aber mit angegeben werden, von wann - und noch wichtiger - BIS wann > gesperrt ist. > Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von > Routern nicht mehr berücksichtigt werden und aufgrund des Datums können > alle "überfälligen" Baustellen aus der Datenbank gelöscht werden. > > Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie > sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, > versteht sich) > Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich > taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. > > Falls das Enddatum unbekannt ist, sollte/muss eine Schätzung angegeben > werden, damit die Mapper nach der Frist die Baustelle nochmal > überprüfen/aktualisieren können. > > So, das war meine bisherige Überlegung. > Aber vielleicht hat jemand noch einen besseren Vorschlag? > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Joachim Vielen Dank für den Hinweis auf TPEG. Das kannte ich noch nicht. Ich befürchte aber, dass TPEG auch nicht viel einfacher ist als TMC. Die v.a. weil es sich - wie TMC - auf effiziente Übermittlung über Übertragungskanäle konzentriert. Hingegen gibt der Abschnitt "Aufbau einer RTM Nachricht" undder nachfolgende (aus deinem Link [1]) interessante Hinweise, um die Vollständigkeit der hier besprochenen Schemata zu prüfen. In die richtige Richtung geht hingegen: Eckhart's Hinweis Am 22. Juli 2013 08:07 schrieb Eckhart Wörner : > ... > • gesperrte Straßen: > http://wiki.openstreetmap.org/wiki/Conditional_restrictions Ich kläre nun ab, inwiefern das meinen Vorschlag vom 22.07.2013, 22:36 +0200 ersetzt. LG, Stefan Am 23. Juli 2013 09:30 schrieb Joachim Kast : > >> TMC scheint mind. innerhalb OSM "tot" zu sein. Vgl. [1]. >> Und so oder so, scheint mir TMC doch reichlich kompliziert, >> unzugänglich und daher ungeeignet für diese Zwecke hier. >> Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse, >> Landshut, mittels TMC für nächstes Wochenende sperren würde? >> >> LG, Stefan > > Hallo Stefan, > > TMC ist innerhalb OSM "tot", weil es für den Normalmapper zu kompliziert > und schwer nachvollziehbar ist. Solche komplexen Sachen, die nur von > wenigen Experten so richtig verstanden werden, gehören von außerhalb > integriert, ohne allzugroße Eingriffe in den OSM-Datenbestand. > > Blicken wir lieber in Richtung TPEG [1], dem TMC-Nachfolger für das > Digitalradio. Dises System ist unabhängig vom Kartenmaterial und auch > vom Übertragungskanal. Die ARD-Rundfunkanstalten stehen kurz vor dem > Beta-Test und stellen dann auch die Meldungen z.B. als RSS-Feed zur > Verfügung. > > Mit TPEG-Technologie dürfte es kein Problem sein, einzelne Straßen oder > Parkplätze kurzfristig zu sperren, besetzte Parkhäuser oder auch die > Preise an Tankstellen anzuzeigen. > > > Grüße > Joachim > > > [1] http://de.wikipedia.org/wiki/TPEG > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Lieber Wolfgang Am 22. Juli 2013 23:59 schrieb Wolfgang Hinsch : > Für diese temporären Umleitungen hat man doch die tmc-tags erfunden. > Lasst die doch endlich mal funktionieren und lasst das Gebastel an den > highways. > > Alles < 1 Jahr -> tmc TMC scheint mind. innerhalb OSM "tot" zu sein. Vgl. [1]. Und so oder so, scheint mir TMC doch reichlich kompliziert, unzugänglich und daher ungeeignet für diese Zwecke hier. Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse, Landshut, mittels TMC für nächstes Wochenende sperren würde? LG, Stefan P.S. Bitte unterlasse herablassende Ausdrücke wie "Gebastel". [1] http://wiki.openstreetmap.org/wiki/DE:TMC Am 22. Juli 2013 23:59 schrieb Wolfgang Hinsch : > Hallo, > > Am Montag, den 22.07.2013, 22:36 +0200 schrieb Stefan Keller: >> Hallo Henning, >> >> Es geht nicht darum "ein Objekt als X zu taggen, um dann im nächsten >> Tag zu sagen, es ist Y". Und es geht niemandem um den Renderer. >> >> Der aktuelle Vorschlag lautet: >> Ein highway=primary bleibt ein highway=primary. >> Es kann nun unbestrittenermassen vorkommen, dass eine Strasse zeitlich >> angekündigt und befristet für den Verkehr gesperrt ist. >> Das wird dann mit *zusätzlichen* Tags gekennzeichnet. >> Navi- und andere Projekte müssen (bzw. können und sollen) diese >> *zusätzlichen* Tags nicht auswerten. >> > Für diese temporären Umleitungen hat man doch die tmc-tags erfunden. > Lasst die doch endlich mal funktionieren und lasst das Gebastel an den > highways. > > Alles < 1 Jahr -> tmc > > > Gruß, Wolfgang > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Henning, Es geht nicht darum "ein Objekt als X zu taggen, um dann im nächsten Tag zu sagen, es ist Y". Und es geht niemandem um den Renderer. Der aktuelle Vorschlag lautet: Ein highway=primary bleibt ein highway=primary. Es kann nun unbestrittenermassen vorkommen, dass eine Strasse zeitlich angekündigt und befristet für den Verkehr gesperrt ist. Das wird dann mit *zusätzlichen* Tags gekennzeichnet. Navi- und andere Projekte müssen (bzw. können und sollen) diese *zusätzlichen* Tags nicht auswerten. LG, Stefan Am 22. Juli 2013 22:01 schrieb Henning Scholland : > Am 22.07.2013 21:41, schrieb Stefan Keller: > >> Hallo Malte und Henning >> >> Falls ihr euch auf die Lösung mit dem Abändern bestender Tags bezieht, >> muss ich euch vollkommen Recht geben: >> highway=primary vorübergehend auf highway=construction zu wechseln >> macht keinen Sinn. >> Hingegen zeichnet sich eine bessere Lösung mit zusätlichen Tags ab, >> welche "die Wirklichkeit" besser abbilden: Vgl. die anderen Mails. > > Hallo, > ich antworte dir mal auf diese Mail. Ich halte es für vollkommen verkehrt, > ein Objekt als X zu taggen, um dann im nächsten Tag zu sagen, es ist Y. > Konkret meint das: highway=primary hat eine gewisse Bedeutung. Wenn das > Objekt, was ich eintragen möchte aber gar nicht diese Eigenschaften hat, > dann ist es auch falsch, dieses Tag zu verwenden. > > Es ist für jeden Auswerter ein leichtes, highway= construction und > construction=primary genauso zu behandeln wie highway=primary. > > Bei der Sache der kurzfristigen Änderungen geht es nicht darum, wie man > einen Renderer überlisten kann, sondern dass es aktuell (meiner Meinung > nach) nicht sinnvoll ist, das zu erfassen, weil die meisten Auswertungen > ohnehin nicht rechtzeitig die Darstellung ändern und wie bereits gesagt > egtl. die Daten für die kurzfristige Änderung schon nutzbar sein müssen, > bevor man sie in OSM live schalten kann. > > Henning > > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Malte und Henning Falls ihr euch auf die Lösung mit dem Abändern bestender Tags bezieht, muss ich euch vollkommen Recht geben: highway=primary vorübergehend auf highway=construction zu wechseln macht keinen Sinn. Hingegen zeichnet sich eine bessere Lösung mit zusätlichen Tags ab, welche "die Wirklichkeit" besser abbilden: Vgl. die anderen Mails. LG, Stefan Am 22. Juli 2013 20:44 schrieb Malte Blättermann : > Am 22. Juli 2013 18:30 schrieb Henning Scholland : >> Hallo, >> evtl. ist es nicht das einzige Argument, aber ein sehr wichtiges. Die >> Mapnikkarte ist die einzige Anwendung, die nahezu in Echtzeit die Daten >> anzeigt. Allerdings hat man von der Karte nicht viel. Einzig das access >> einiger Straßen dürfte ein paar rote Punkte auf die Karte zaubern. >> Alle anderen Anwendungen hinken der Echtzeit um einiges hinterher. So >> kann es dann sein, dass das Festival eine Woche später dargestellt wird >> oder einen Monat lang. Einen wirklichen Vorteil des Eintragens >> kurzfristiger Dinge sehe ich hier nicht. Tendenziell eher einen Nachteil. > > > Sehr gut zusammengefasst! Danke! > > > Gruß Malte > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Frank und Thorsten
Vielleicht hast du beim Schreiben Thorsts Vorschlag noch nicht gesehen:
Thorsten Kurz schrieb am 22. Juli 2013 19:25:
> Wäre es vielleicht möglich, das ganze in ein Tagging-Schema zu packen,
> das man im Zweifelsfall auch komplett ignorieren kann und immer noch
> etwas einigermassen sinnvolles erhält? Wie wäre es z.B., statt
>
> highway = construction
> construction = primary
>
> vielmehr
>
> highway = primary
> construction = yes
>
> zu verwenden?
Mittlerweile ist mir klar geworden, dass z.B. der highway-Tag nur dem
eigentlichen Attributieren der
Strassenklasse vorbehalten sein soll. Ein Hin- und Zurückändern wäre falsch.
Hingegen sind zusätzliche ("optionale") Tags (construction=yes etc.) -
wie von Thorsten vorgeschlagen - für mich eine durchaus gangbare
Lösung.
construction=yes deckt aber noch nicht alle Fälle ab - insbesondere
nicht Veranstaltungen wie Alexanders Stadtfest! Wie wär's in diesem
Falle mit:
* traffic_obstruction=yes/no
Am 22. Juli 2013 20:25 schrieb Frank :
> Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie.
Der "originale" highway-Tag nicht; ein construction=yes schon.
> Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann
> wochenlang mit diesen "Sonder-Anpassungen" herum. Auch andere Auszüge werden
> nicht täglich aktualisiert.
Solche zeitlich "hinterherhinkenden" Projekte sollten sich nicht
beirren lassen von zusätzlichen Tags, die den letzten "Sperrzustand"
kennzeichnen.
Bei der Anwendung, die ich im Kopf habe - und die auch Alexander
anspricht - ist die Information ja Tage, wenn nicht Wochen im Voraus
bekannt mit offiziellem Start- und Enddatum. Dazu habe ich
ursprünglich start_date / end_date vorgeschlagen. Ob die wirklich
passend sind, bin ich mir auch nicht mehr sicher, denn diese Angaben
beziehen sich auf die Existenz des Objekts und nicht auf
Zusatzeigenschaften, auf die ich hinaus will. Besser so?
* traffic_obstruction_start=<>
* traffic_obstruction_end=<>
> Ich denke, die OSM-Datenbank sollte nur den "Normalzustand" wiedergeben und
> nicht den temporären Ausnahmezustand.
Ich glaube mittlerweile, dass sich beide Zustände nicht stören müssen.
Ich fasse zusammen:
* Strassen-Tags (highway) bleiben unberührt
* traffic_obstruction=yes/no -- Kennzeichnet eine
Verkehrsbehinderung
* traffic_obstruction_start=<>-- Beginn Verkehrsbehinderung
(falls bekannt)
* traffic_obstruction_end=<> -- Ende Verkehrsbehinderung
(falls bekannt)
* emergency=yes/no -- Blaulich-KFz. können
trotzdem durchfahren
> Dies kann evtl. auf einer Webseite oder in Flyern durch "Overlays"
> dargestellt werden.
Damit kann ich auch leben. Wie gesagt, möchte ich die Möglichkeiten ausloten.
LG, Stefan
Am 22. Juli 2013 20:25 schrieb Frank :
> Am 22.07.2013 08:07, schrieb Eckhart Wörner:
>
>> Hallo Alexander,
>>
>> Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner:
>>>
>>> Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit
>>> hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen,
>>> Umleitungen, zusaetzliche amenities etc..
>>>
>>> Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche
>>> neuen Erkenntnisse?
>>
>>
>> • gesperrte Straßen:
>> http://wiki.openstreetmap.org/wiki/Conditional_restrictions
>> • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen
>> • zusätzliche amenities: opening_hours?
>>
>> Eckhart
>>
>
> Ich denke, es ging Alexander eher um die Frage, ob man die temporären
> Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen
> sollte.
>
> Es wäre zwar nett, wenn die Karte auch während des "Ausnahmezustandes
> Stadtfest" aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich.
> Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend
> eingerichtet wurden.
>
> Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie.
>
> Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann
> wochenlang mit diesen "Sonder-Anpassungen" herum. Auch andere Auszüge werden
> nicht täglich aktualisiert.
>
> Ich denke, die OSM-Datenbank sollte nur den "Normalzustand" wiedergeben und
> nicht den temporären Ausnahmezustand.
>
> Dies kann evtl. auf einer Webseite oder in Flyern durch "Overlays"
> dargestellt werden.
>
> --
>
> Frank
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Liebe alle
Das Thema "temporäre Verkehrshindernisse (Fahrverbote, gesperrte
Strassen) v.a. wegen Bauarbeiten oder Veranstaltungen" interessiert
mich auch. Ich habe es gerade diese Tage auf Talk-ch angeschnitten
("Temporär gesperrte Strassen").
Das Argument, dass veraltete Daten in "offline" Applikationen (Navis)
landen können, ist oft zu hören. Doch ist das wirklich das einzige
Argument gegen entsprechende Tags in OSM? Mir scheint das Argument
etwas "zu fürsorglich", denn einerseits könnten Importprogramme
Baustellen herausfiltern und zweitens könnten
Qualitätssicherungsprogramme veraltete Daten durchaus aufspüren.
Ich hake hier bewusst nach, um die Möglichkeiten und Grenzen eines
eigenen Projekts abzustecken. Die Idee diese Projekts ist, solche
Informationen über eine Karte und ein Webservice/API zur Verfügung zu
stellen. Zudem können "Profis" (= Bewilligungs-Behörden) wie auch
Freiwillige (= Mapper) solche Daten erfassen.
LG, Stefan
Am 22. Juli 2013 08:57 schrieb Joachim Kast :
> Hallo Alexander,
>
>> Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit
>> hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen,
>> Umleitungen, zusaetzliche amenities etc..
>
> OSM kann wirklich sehr aktuell sein, aber bis die Informationen eines
> Wochenend-Ereignisses beim "normalen Endanwender" ankommen, ist es
> vermutlich schon längst wieder vorbei. Im schlimmsten Fall holt sich
> z.B. ein Navigationsprojekt genau an diesem Wochenende die Daten und
> berücksichtigt in den nächsten 3 Monaten die Straßensperrungen.
>
> Ein Festival-Gelände auf der grünen Wiese ist problemlos, aber innerhalb
> eines dicht gemappten Gebietes für ein Wochenende alles umzuschmeißen
> richtet bestimmt mehr Verwirrung an als dass es Nutzen bringt.
>
> Sowas sollte auf einem getrennten Datenbestand eingetragen und eine
> temporäre Veranstaltungskarte erstellt werden, die man sich auch schon
> einige Zeit im Voraus anschauen kann.
>
> Grüße
> Joachim
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Am 15. Juli 2013 14:53 schrieb Hartmut Holzgraefe : > On 07/15/2013 01:59 PM, Peter Barth wrote: > >> bitte überdenke das nochmal. Deine Dienste sind großartig, nützlich und >> auch immer top gemacht! Ich will nichts davon missen, ich will lieber >> noch mehr davon ;) +1 auch von mir. LG, Stefan P.S. An alle: Lasst mich die Gelegenheit wahrnehmen, um inne zu halten und - im Sinne der Netiquette - daran zu denken, dass erstens ein neuer Thread eröffnet wird, wenn man das Thema verlässt und zweitens bitte möglichst überlegte, nicht-ausufernde Statements gewählt werden. Am 15. Juli 2013 14:53 schrieb Hartmut Holzgraefe : > On 07/15/2013 01:59 PM, Peter Barth wrote: > >> bitte überdenke das nochmal. Deine Dienste sind großartig, nützlich und >> auch immer top gemacht! Ich will nichts davon missen, ich will lieber >> noch mehr davon ;) >> >> Dass hier einige nach jahrelangem anstandslosen Betrieb plötzlich >> allerlei Probleme sehen, illegales Datenabschnorcheln mit dem >> Auswerten einer offenen Datenbank in einen Topf werfen und ähnlich >> abstruse Zusammenhänge herstellen, sollte man sich nicht zu sehr zu >> Herzen nehmen. [...] > > > +1 > > Als nächstes kommen noch zB. große Energieversorger und beschweren sich > das es ja garnicht geht das man aus OSM Daten ihre kompleten > Hochspannungsnetze erkennen kann ... oh, moment, been there, done that > ... > > Die Daten sind da, die Daten sind nutzbar, die Tatsache das Benutzername > und Uhrzeit in den veröffentlichten Rohdaten enthalten sind (letzter > Edit je Objekt, und bei history dumps auch die gesamte Vergangenheit) > sollte bekannt sein ... > > Der Unterschied ob eine bestimmte auf diesen Daten mögliche Auswertung > direkt mundgekaut online angeboten wird, mit frei verfügbaren > Werkzeugen möglich ist (grep auf history dump, OverPass?), oder die > Möglichkeit auch nur theoretisch existiert ist damit irrelevant ... > > Entweder ist die Veröffentlichung von ID plus Timestamp generell > rechtlich fragwürdig, oder die darauf aufbauenden Auswertungen sind > es genau so wenig wie die Rohdaten selbst. > > Die gleichen Auswertungen wären auch auf dem Wikipedia-Datenbestand > möglich, oder auf jedem beliebigen öffentlichen SVN/GIT/... Source > Code Repository, auf dem Archiv jeder öffentlichen Mailingliste > oder jedem öffentlichen Chat ... und in vielen dieser Fälle kenne > ich auch entsprechende öffentlich verfügbare Auswertungen. > > PS: Rechtlich "interessant" wird es eher beim Einsatz entsprechender > Systeme im Arbeitsumfeld da die entsprechenden Rohdaten und > Auswertungen sich schnell mit dem Thema "Arbeitsüberwachung" > überschneiden ... aber auch da erst wenn die Pseudonymisierung > einfach rückgängig gemacht werden kann (AFAIK; IANAL; etc.) > > -- > hartmut > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Project of the Week und Gamification
Hallo, Ich denke wir sollten unterscheiden zwischen verschiedenen Zielgruppen, die motiviert werden sollen: 1. Aktive (erfahrene) Mapper 2. Gelegenheits-Mapper bzw. solche, die nach dem ersten Mal aufgegeben haben 3. Mapper-Kandidaten (wie z.B. Geochacher). Erste Erfahrungen mit Gamification konnten wir schon mit dem Kort Game sammeln [1]. Sie waren recht positiv. Das Spiel sprach v.a. die Zielgruppen 2 und 3 an. LG, Stefan [1] http://wiki.openstreetmap.org/wiki/KortGame Am 12. Juli 2013 23:10 schrieb Peter Barth : > Hallo Thorsten, > > Thorsten Alge schrieb: >> Weiter wäre ein bereits angesprochenes Belohnungssystem mit Badges, >> wie vielleicht von Foursquare, Diablo III oder WoW bekannt, eine coole >> Sache die sicher den einen oder anderen Mapper bei Laune hält. > > wir haben das bei uns am Stammtisch auch schon mehrfach angesprochen und > diskutiert. Ich hab mir das auch schon lange vorgenommen mal zu testen, > wenn ich nur mehr Freizeit hätte ^^ Ich habe ja auch immer boinc und > seti@home angeführt: Da gibt es dann soviele Arten von Statistiken und > Auszeichnungen, dass man einfach immer mal irgenwann irgendwo auch > erster ist. Hab da zwar persönlich nie mitgemacht aber von vielen > gehört, dass das ihr Anreiz zur Beteiligung war. Ich fände so ein System > auf jeden Fall super! > >> Hier >> könnten Badges in drei Stufen (B/S/G) > > und Platin und die aus den Bundesjugendspielen allseits bekannten und > beliebten "Teilnahmeurkunden" ;D > >> in bestimmten Kategorien (z.B. >> Hausnummern, Laternen, Straßenname, ...) für den Mapper vergeben >> werden > > Top! Und mit Hausnummern gleich mal anfangen, da bin ich nämlich > recht gut ;) Und Meta-Badges: "Hat schon 10 Gold-Badges" und so :) > >> vielleicht etwas vergleichbar mit der Seite von Pascal Neis >> (http://hdyc.neis-one.org/). >> [...] >> Wenn sich die Badges vielleicht noch in der Nutzerseite auf OSM oder >> dem OSM Wiki einbinden lassen, wäre das sicher auch nicht so verkehrt. > > Muss nicht sein. Seiten wie hdyc und OSMFight sind schließlich auch so > cool, dass man sie einfach kennt. Wie sonst würden wir ohne OSMFight > bei Tagging-Meinungsverschiedenheiten auf dem Stammtisch entscheiden > können, wer nun Recht hat (kleiner Spass ;)). So wär das auch mit dem > Badges, die kennt dann einfach jeder! :) > >> Für ganz fleißige Mapper könnte natürlich auch der Vorstand eine >> Dankespostkarte, mit dem Kartenausschnitt der Region in dem der Mapper >> aktiv ist, verschicken. > > Ich würde *dir* für so einen Dienst auf jeden Fall einen Abend Getränke > auf einem Stammtisch, Hackertreffen oder ähnlichem spendieren ;) > >> Würde einfach mal gern hören was Ihr so davon haltet und ob Ihr glaubt >> ob es sinnvoll und realisierbar ist. > > Absolut! Und Ja. > > Übrigens, da ja Pascal in seiner Antwort auch die Verknüpfung mit > Help, Wiki oder ähnlichem angedeutet hatte: Finde ich auch eine nette > Idee und wollte noch darauf hinweisen, dass OSM help ja auch massiv > von diesem "Belohnungssystem" profitiert. > > Liebe Grüße > vom baldigen Gold-Badge-Besitzer für Gebäude-in-Niederbayern mappen ;) > > Peda > > -- > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tracy
Mit grossem Interesse verfolge ich diese Diskussion, denn ich
beschäftige mich seit einiger Zeit mit dem Thema, wie man externe
Datenbanken mit OSM verknüpfen kann.
Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk :
> ...
> Hiermit unsere vorläufige Stellungnahme zu diesem Thema:
>
> ** **Zunächst eine Ergänzung unserer Beschreibung:
>
> Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
> ref_ifopt
>
> Die IFOPT Nummer (globale ID) gibt es für alle Haltestellenobjekte,
> speziell auch für alle Haltepunkte der Busse und Straßenbahnen. Das ist
> dann so was wie ein eindeutiges Nummernschild in den Ländern, die mitmachen.
>
Das was ihr mit dem IFOPT in OSM vorhabt, ist analog TCM und
entspricht der Variante 2, die ich hier zunächst für mich dokumentiert
habe: [1].
Ich meine, wenn schon eine solche "Projekt-Spezial-ID", dann würde ich
einen sinnigen Tag-Namen verwenden, wie ihn Jochen
("public_transport:ifopt:stop_id") vorschlug.
Und in jedem Falle würde ich es bei diesem Projekt-Spezial-Tag
belassen und keine weiteren Tags vorsehen (die sind ja über die ID mit
der externen DB verknüpft).
Konsequenter wäre aber m.E. ganz ohne Projekt-Spezial-ID auszukommen,
in dem die OSM-ID oder eine noch zu findende
"permanente/stabile/globale OSM IDs" verwendet wird, auf die sich die
externe Datenbank bezieht (=> vgl. Variante 4 [1]). Am 22.07.12 gab es
eine Diskussion über solche "Permanente/stabile OSM IDs!". Ich schlug
dort eine einzige zusätzliche ID-Tag pro OSM-Objekt vor. Dort war
eines der (berechtigten) Einwände, dass die "interne" OSM-ID instabil
sei und sowohl bei dieser als auch bei Projekt-Spezial-IDs die
OSM-Daten "aufgebläht" würden.
Was mir an IFOPT jedenfalls nicht gefällt, ist die Codierung durch
"sprechende" Schlüssel (die ändern können!).
Ich frage mich daher, ob nicht der Vorschlag von Wolfgang Hinsch vom
10. Juli 2013 17:04 am besten wäre ("public_transport:stop_position")
- vgl. unten. So ein Tag könnte auch ausserhalb den an IFOPT
angeschlossenen Bahnhöfen (d.h. weltweit) verwendet werden.
LG, Stefan
[1] http://giswiki.hsr.ch/OpenStreetMap_und_externe_Datenbanken#Variante_2
LG, Stefan
Am 10. Juli 2013 17:04 schrieb Wolfgang Hinsch :
> ...
> Also, wenn ich das richtig verstanden habe, werden damit Positionen auf
> dem Gleis und auf dem Bahnsteig am Gleis markiert. Wie das in
> irgendeiner Spezial-DB heißt, kann uns doch völlig schnuppe sein. Besser
> wäre ein Klartext wie:
>
> public_transport:stop_position="Gleis3_Nord';
> public_transport:stop_position="Gleis3_Mitte';
> public_transport:stop_position="Gleis3_Sued';
>
> oder ost/west, wenn der Bahnhof anders rum liegt.
>
> Falls eine Position reicht (an vielen Bahnsteigen werden mehrere Züge
> hintereinander bereitgestellt), einfach nur 'Gleis3'.
>
> Dann wird im Wiki erklärt, was das heißen soll, eine Vorlage dazu, damit
> die Rechtschreibung stimmt, ein Style für josm, damit es angezeigt wird
> und gut ist. Dann weiß jeder, was gemeint ist und kann das auch
> reparieren.
>
> Das Bundesland und der Bahnhofsname sollte sich eindeutig aus der Lage
> ergeben.
>
> Die Bahnsteigpositionen analog. Eingänge auch (Eingang_Nord,
> Eingang_Nord-Ost oder so). Aus einer separaten Tabelle geht dann hervor,
> welche ID damit gemeint ist, das muss nicht in OSM stehen.
>
> Zusätzlich hat man damit den Vorteil, dass sofort auffällt, wenn in den
> Daten etwas fehlt, weil dann für IDs die OSM-Position nicht gefunden
> wird.
>
> Vielleicht übersehe ich etwas, aber eigentlich könnte das so einfach
> sein.
>
> Gruß, Wolfgang
Am 11. Juli 2013 12:21 schrieb Tracy Kasperczyk :
> Hallo liebe OSM-Gemeinde,
>
> mit dieser Mail wollen wir uns bei Ihnen allen melden. Wir müssen intern
> erst ein paar Sachen klären, bevor wir eine Stellungnahme zu Ihren vielen
> E-Mail nehmen können. Wir bedanken uns aber schon einmal sehr dafür, daß
> Sie uns so zahlreich geantwortet haben.
>
> Hiermit unsere vorläufige Stellungnahme zu diesem Thema:
>
> ** **Zunächst eine Ergänzung unserer Beschreibung:
>
> Wir nehmen die Anregung von Stephan Wolff auf und ändern den Namen in
> ref_ifopt
>
> Die IFOPT Nummer (globale ID) gibt es für alle Haltestellenobjekte,
> speziell auch für alle Haltepunkte der Busse und Straßenbahnen. Das ist
> dann so was wie ein eindeutiges Nummernschild in den Ländern, die mitmachen.
>
>
> Wir bemühen uns um eine Veröffentlichung aller Nummern in den Portalen der
> verantwortlichen Ländern. Allerdings sind noch nicht alle Nummern
> endgültig. Vor allem in den Überschneidungsbereichen der Verbünde, z.B. VRR
> und VRS fällt noch Arbeit an. Es gibt europaweit eine Open Data Initiative
> die diese Daten öffentlich zugänglich machen will.
>
>
> Einige Verkehrsverbünde bieten kostenfreie öffentliche Schnittstellen zum
> Abruf von Fahrplaninformationen an. Die IFOPT Nummer kann in diesem
> Zusammenhang als eindeutiges Anfragekriterium genutzt werden, um
> beispielsweise alle Abfahrten
[Talk-de] Koins sammeln waehrend AGIT 25 im Land von Red Bull (Kort Game-Aktion)
Liebe Mapper! Anlässlich der AGIT 25 in Salzburg wollen wir zeigen, dass nicht nur Red Bull Kampagnen machen kann. Es gibt nämlich eine Kort-Aktion für unbekannte Wegtypen (Asphalt, Schotter...)! Die Aktion dauert noch bis Sonntag und gilt für alle Strassen und Wege in der Stadt Salzburg. Nutzt die Gelegenheit, um doppelte Koins zu sammeln. Und vergesst nicht, im OpenStreetMap-Spezialforum vorbeizuschauen (3. Juli, ab 15 Uhr, Blauer Hörsaal). LG, Stefan Kort Headquarters ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Overpass API: Gegeben id/name gesucht Area: Wie?
Hallo! Folgende Frage zum Overpass API: * Gegeben die OSM-id (oder der name) einer Relation, genauer: ein Multipolygon (z.B. http://www.openstreetmap.org/browse/relation/2135966 ). * Gesucht: Irgend ein Output mit (Area-)Geometrie zur Weiterverarbeitung (XML, GeoJSON, etc.), d.h. nicht nur die Relation mit Verweisen auf Ways, sondern ein Multipolygon mit Koordinaten. Hab's mit Overpass-Turbo und verschiedenen API-Tricks probiert, ohne Erfolg. Kann man das mit dem Overpass API und wenn ja, wie? LG, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS 2013: Nachlese in Bildern...!
Hier nebst einer News (http://bit.ly/18fPeeW ) und einem Artikel http://www.geowebforum.ch/thread.php?threadID=1110 eine erste FOSSGIS 2013-Nachlese in Bildern… Allen voran eine Panoramasicht der Ausstellung: https://twitter.com/sfkeller/status/349862446208516097 . Da waren die Konferenzvorträge in vollem Gange; daher die "wenigen" Leute. Man sieht aber, wie alle Projektstände gut besetzt waren :-) Dann: * http://eventifier.co/event/fossgis2013/ * https://twitter.com/sfkeller/media/grid * http://fotodrachen-de.tumblr.com/tagged/fossgis2013 Weitere Bilder folgen ev. noch (immer mit #fossgis2013 taggen!). An dieser Stelle möchte ich nochmals meinen Dank aussprechen, v.a. auch an die fleissigen Helfer an den Ständen! LG, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Sprache des Namens" Fehler in Kort.
Hallo Hans, Ich kann nur nochmals ganz kurz wiederholen, auf Simon Beitrag oben verweisen, und mit den Worten von Peter W. sagen: > Den name-Tag rausfliegen zu lassen halte ich für eine ganz > ganz blöde Idee. LG, Stefan Am 25. Juni 2013 23:21 schrieb fly : > On 25.06.2013 22:46, Hans Schmidt wrote: >> Am 24.06.2013 22:53, schrieb Peter Wendorff: > >> Ich habe jetzt mal eine E-Mail zur JOSM-developer-Liste geschrieben, >> zusammen mit einem Mockup, den ich in Excel gestellt habe. > > Für sowas ist https://josm.openstreetmap.de die besser Adresse, aber das > wird schon klappen. > > Auch hättest Du Dich nicht erst auf der Mailingliste anmelden müssen > sonder hättest sogar anonyme bleiben können ! > >> Ich mecker nicht nur, sondern entwerfe das auch :) > > Super. > >> Mal sehen, was daraus wird und wie die Reaktionen sind. > > Erwarte nicht zu viel. JOSM wird gerade von 1-4 Entwicklern aktiv > entwickelt. > > Grüße > fly > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Sprache des Namens" Fehler in Kort.
Am 24. Juni 2013 04:40 schrieb Dirk Sohler : > Wenn langfristig name rausfliegen soll, und durch name:de ersetzt > werden soll (was nur sinnvoll wäre), muss es irgendwann verschoben > werden (...) Nein; es gibt keinen Grund, den name-Tag rausfliegen zu lassen. Dies wegen den mehrsprachigen Ortsnamen und Strassen, wie Biel/Bienne oder Martins Beispiel: name=Bolzano - Bozen name:it=Bolzano name:de=Bozen Solche Beispiele gibt es ziemlich sicher auch in Deutschland, nicht nur in Österreichm, Italien, der Schweiz und Spanien. Vgl. oben. LG, Stefan Am 24. Juni 2013 04:40 schrieb Dirk Sohler : > Stefan Keller schrieb: >> Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und >> Renderer ohne weitere Angaben darstellen können. >> Deren Values sollten daher nicht verschoben sondern ggf. kopiert >> werden (z.B. nach name:de=München). > > Wenn langfristig name rausfliegen soll, und durch name:de ersetzt > werden soll (was nur sinnvoll wäre), muss es irgendwann verschoben > werden, spätestens mit Version N+1, wenn name nicht mehr unterstützt > wird, muss bis Version N jegliches vorkommen von name durch name:de > ersetzt werden (name:de, oder name:en, oder name:ru, etc.). > > Je eher das gemacht wird, desto besser. > > Grüße, > Dirk > > -- > Local time :: Ortszeit :: DE-HH > 2013-06-24T04:37:59+0200 > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Sprache des Namens" Fehler in Kort.
Am 23. Juni 2013 21:18 schrieb Hans Schmidt : > 2. Alle name-Tags müssen verschoben werden Die name-Tags sind dazu da, das zu erfassen, was Mapper sehen und Renderer ohne weitere Angaben darstellen können. Deren Values sollten daher nicht verschoben sondern ggf. kopiert werden (z.B. nach name:de=München). Vgl. auch meine Ausführungen zu Endonyme und Exonymen oben. LG, Stefan Am 24. Juni 2013 01:57 schrieb Dirk Sohler : > Hans Schmidt schrieb: >> Also, was gemacht werden muss: >> >> [1-5] > > Perfekt zusammengefasst! > > Grüße, > Dirk > > -- > Local time :: Ortszeit :: DE-HH > 2013-06-24T01:57:10+0200 > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Sprache des Namens" Fehler in Kort.
Eine bewusst gewählte Eigenheit von Kort ist, dass nur ein Tag aufs Mal korrigiert bzw. ergänzt werden kann (d.h. es wird z.B. zu bei name=Biel/Bienne der Tag name:de=Biel ergänzt). Bei der nächsten Aktualisierung sollte es dann immer noch als Fehler taxiert werden, weil da ein weiterer name:XX fehlt (nämlich name:fr=Bienne). Bin nun nicht unsicher, ob das keepright so handhabt. Falls ja, wird es auch in Kort nochmals fragen und man kann name:fr=Bienne eintgragen. Dann haben also Keepright und Kort doch nicht so unrecht, dass ein name:XX fehlt!? Man könnte höchstens ergänzen "dass ein oder mehrere name:XX fehlen". LG, Stefan Am 23. Juni 2013 18:47 schrieb Martin Raifer : > Am 23.06.2013, 18:36 Uhr, schrieb Stefan Keller : > > >> Ich bin immer noch nicht ganz sicher, ob wir uns verstehen, denn die >> Redundanz bei name=München und name:de=München scheint mir kaum >> vermeidbar. >> Der Tag name=München ist für mich der offizielle Name (Endonym). >> Der Tag name:de=München zeigt einem Programm, wie der Name auf >> *deutsch* heisst (ähnlich wie name:de=Peking); das ":de" ist hier >> wichtig. >> Lokalisierte Namen sind für mich ein Zusatz. Für München könnte es >> "name:gsw=Minga" sein. > > > Ich glaube dass wir uns schon verstehen, denn genau das wollte ich durch > mein Beispiel unterstreichen. > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Sprache des Namens" Fehler in Kort.
Hallo Martin Am 23. Juni 2013 17:48 schrieb Martin Raifer : > Genau davon sprechen wir hier die ganze Zeit. ;) > > Der Standard-Use-Case für die redundante Eintragung des Namens ist > beispielsweise in etwa folgender: > Man möchte eine Karte erstellen, die Labels in folgender Sprach-Reihenfolge > anzeigt: 1. Deutsch, 2. Englisch, 3. der lokale Name (siehe > http://mlm.jochentopf.com/). Wenn nun bei München kein redundantes > name:de=München angegeben ist (also nur name=München & name:en=Munich), wird > es für den Renderer sehr schwierig die Karte wie gewünscht anzuzeigen; > wahrscheinlicher würde dann der englische Name angezeigt werden. Ich bin immer noch nicht ganz sicher, ob wir uns verstehen, denn die Redundanz bei name=München und name:de=München scheint mir kaum vermeidbar. Der Tag name=München ist für mich der offizielle Name (Endonym). Der Tag name:de=München zeigt einem Programm, wie der Name auf *deutsch* heisst (ähnlich wie name:de=Peking); das ":de" ist hier wichtig. Lokalisierte Namen sind für mich ein Zusatz. Für München könnte es "name:gsw=Minga" sein. LG, Stefan Am 23. Juni 2013 17:48 schrieb Martin Raifer : > Am 23.06.2013, 15:18 Uhr, schrieb Peter Wendorff > : >> >> [...] >> >> Wenn man das also als Warnung beanstanden würde, sollte man erstmal >> generell in osm propagieren, dass generell lokalisierte Namen angegeben >> werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im >> Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens. > > > Darum geht es in bei den hier angesprochenen Kort-Aufträgen bzw. > KeepRight-Warnungen auch gar nicht. > > >> Eine Ausnahme allerdings sehe ich schon: >> WENN ein Objekt >> - ein name-Tag hat >> - und mindestens ein lokalisiertes name:** besitzt, >> - und keines der lokalisierten name:**-Tags im name-Tag enthalten ist >> (als Teil des Namens, damit auch die Kombinierten name-Tags wie >> Brüssel/Bruxxelex oder so nicht als fehler erkannt werden), >> DANN fehlt offensichtlich mindestens ein name, und der ist dann auch >> sinnvoll einzutragen, z.B., um bei textbasierten OSM-Diensten die >> Browser-Sprache bedienen zu können. > > > Genau davon sprechen wir hier die ganze Zeit. ;) > > Der Standard-Use-Case für die redundante Eintragung des Namens ist > beispielsweise in etwa folgender: > Man möchte eine Karte erstellen, die Labels in folgender Sprach-Reihenfolge > anzeigt: 1. Deutsch, 2. Englisch, 3. der lokale Name (siehe > http://mlm.jochentopf.com/). Wenn nun bei München kein redundantes > name:de=München angegeben ist (also nur name=München & name:en=Munich), wird > es für den Renderer sehr schwierig die Karte wie gewünscht anzuzeigen; > wahrscheinlicher würde dann der englische Name angezeigt werden. > > Allerdings ist dein Kritierium "keines der lokalisierten name:**-Tags [ist] > im name-Tag enthalten" auch nicht hinreichend. Das wieso werde ich in einem > weiteren Posting gleich ausführen. > > Grüße > Martin > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Sprache des Namens" Fehler in Kort.
Am 23. Juni 2013 15:18 schrieb Peter Wendorff : > Es gibt eigentlich noch eine dritte Kategorie, und das sind die > fehlenden Daten. Nicht falsch, aber eben einfach nicht vorhanden. Richtig! Die neue "Kort-Fehlerkategorie" "fehlende Küche" (= fehlender Tag "cuisine") ist so ein Beispiel. Das ist einer der Neuerungen des Kort Games. Die Daten kommen von meiner EOSMBOne (d.h. aus osm2pgsql). LG, Stefan Am 23. Juni 2013 15:18 schrieb Peter Wendorff : > Hi. > (Kürzungen in den Folgenden Zitaten nur abschnittsweise, deshalb nicht > im Einzelnen kenntlich gemacht) > Am 23.06.2013 14:04, schrieb Stefan Keller: >> Zu deinen Verbesserungsvorschlägen: >> >> Am 19. Juni 2013 10:25 schrieb Martin Raifer : >>> 3. Nie Aufträge stellen, von denen man weiß, dass diese nicht immer sinnvoll >>> sind. Vor allem dann nicht, wenn man weiß, dass der "nicht lösbare" Teil >>> lokal gehäuft vorkommt. Keine "Warnungen" als "Fehler" verkaufen! >> >> Was nun als "Fehler" gilt und was eine Warnung oder gar irrelevant >> sein soll, machmal eine Definitionsfrage. >> Solange es keine "(Mehr-)Sprachgebiete" gibt (wie oben >> vorgeschlagen), "weiss man" nicht, was nun gilt. >> Eine Dichte-Analyse scheint zwar spannend, ist aber für mich in keinem >> Verhältnis von Aufwand und Ertrag, die es betrifft. >> Dafür könnte das Fehlerkategorien-Ausblenden eine Abhilfe sein. > Klar ist das eine Definitionsfrage, was man als Fehler und was nur als > Warnung betrachtet, aber ich denke, die einzig sinnvolle Definition > hier, wenn es sich um das Bearbeiten von OSM-Daten handelt, ist die, > dass ich, um etwas einen Fehler zu nennen, schon sicher sein sollte, > dass es falsch ist. Ein Fehler sagt dem Empfänger der dazugehörigen > Meldung: So ist das falsch, pfui! > Eine Warnung ist dagegen eher: "sag mal: das, was du da grade gemacht > hast, ist zwar möglich, aber zumindest ungewöhnlich. Hast du das > wirklich so gemeint?" > > Es gibt eigentlich noch eine dritte Kategorie, und das sind die > fehlenden Daten. Nicht falsch, aber eben einfach nicht vorhanden. Fehler > werden daraus nur, wenn man in der Auswertung "Zufällig" andere > Default-Annahmen trifft als man müsste ;) > > Zu dieser Kategorie gehören die lokalisierten name-Tags. > ein nicht-lokalisierter name-Tag irgendwo mitten in Deutschland, der den > Namen auf Deutsch enthält, ist doch erstmal nicht falsch, das ist der > Name. Mitten in Deutschland wird auch jede Software, die das > berücksichtigen will, selst mit groben Heuristiken diesen Namen als > deutschsprachig interpretieren (als best-guess eben). > Deshalb alle name-Tags ohne sprachvariante als "Fehler" zu bezeichnen, > ist falsch, und auch eine "Warnung" ist zumindest regional zu hoch > gegriffen. > > Wenn wir tatsächlich wollten, dass die OSM-Datenbank für jeden Namen > mindestens einen name:xx-Tag enthält, dann wär das schonmal 'ne ganz > schöne Hausnummer: > > laut Taginfo gibt es in osm: > name: 35.535.456 mal > der verbreitetste lokalisierte Tag dazu ist > name:en: 831.929 mal - das sind 2,34% > danach kommen: > name:ru (314.898, 0,89%) > name:ja (241.130, 0,68%) > name:fr (203.957, 0,57%) > name:de (182.59, 0,51%) > und so weiter. > > Ganz grob überschlagen gibt es etwa zehnmal so viele name-Tags wie alle > lokalisierten Name-Tags zusammengenommen. > Wenn man das also als Warnung beanstanden würde, sollte man erstmal > generell in osm propagieren, dass generell lokalisierte Namen angegeben > werden sollten - und das ist, soweit ich bisherige Diskussionen dazu im > Kopf habe, zwar nicht verpönt, aber bei weitem nicht Konsens. > > Eine Ausnahme allerdings sehe ich schon: > WENN ein Objekt > - ein name-Tag hat > - und mindestens ein lokalisiertes name:** besitzt, > - und keines der lokalisierten name:**-Tags im name-Tag enthalten ist > (als Teil des Namens, damit auch die Kombinierten name-Tags wie > Brüssel/Bruxxelex oder so nicht als fehler erkannt werden), > DANN fehlt offensichtlich mindestens ein name, und der ist dann auch > sinnvoll einzutragen, z.B., um bei textbasierten OSM-Diensten die > Browser-Sprache bedienen zu können. > > Gruß > Peter > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
Kort hat als Zielpublikum nicht nur OSM-Kandidaten, sondern auch solche, die "nur mal zwischendurch ein Geografiespiel spielen" wollen. Es macht daher m.E. weder Sinn, allen ein OSM-Account zu "schenken" noch Kort als Editor für OSM auszubauen. Kort soll Spass machen und die Fleissigen (und Ehlichen!) belohnen. LG, Stefan Am 20. Juni 2013 06:56 schrieb Tobias Hobmeier : > Hi hi, > > ich habe da eine etwas Naive Idee wäre es nicht möglich jedem Knot User > auch einen OSM account zu verpassen > und Knot praktisch dann als Editor für OSM arbeiten zu lassen? Bei > Punkten die Validiert werden müssen könnte man dann den Punkt von 3. > user in OSM übernehmen lassen und im falle eines fehlers von einem > weiteren Validator (nr 4.) wieder entfernen ... > > oder Habe ich da was Wichtiges übersehen? (muss ja fast so sein Oo) > > > On 06/15/13 21:17, Frederik Ramm wrote: >> Hallo, >> >> On 15.06.2013 20:31, Stefan Keller wrote: >>> Ja, die Bedenken des automatischen Zurückschreibens werden immer >>> wieder hervorgebracht und wir nehmen sie ernst. Bei näherem Hinschauen >>> verlieren sie sich meist. Es war übrigens nicht nur Frederik, der dies >>> in diesem konkreten Fall entspannt sieht, sondern ein paar weitere >>> gestandene Mapper im Saal. >> >> Ich habe mich zu der Frage nicht geaeussert; es war Jochen, der zum >> Mikrofon griff und meinte, man sollte die Edits doch einfach >> zurueckschreiben. >> >> Meine persoenliche Haltung zu der Frage ist ein bisschen zwiegespalten. >> >> *Fuer* ein automatisches Zurueckschreiben spricht, dass die Daten in >> aller Regel vermutlich wirklich eine gute Qualitaet haben, da sie von >> mehreren ueberprueft worden sind, und es sind ja auch nicht >> irgendwelche Imports, sondern wirklich extra fuer OSM erfasste Daten. >> >> *Gegen* ein automatisches Zurueckschreiben spricht unter anderem ein >> "principiis obsta"-Argument - wenn Kort das jetzt darf, wem muessen >> wir das dann noch alles erlauben, und werden es in jedem Fall >> gruendlich recherchierte, mehrfach ueberpruefte, relativ >> vandalismus-sichere Daten sein, oder werden andere mit dem Argument >> "Kort darf das doch auch" ploetzlich auch weitreichende Anderungen von >> geringerer Qualitaet zu rechtfertigen versuchen? Das muss man im Auge >> behalten. >> >> Im allgemeinen sind unsere Hauptargumente gegen "Eintragungen durch >> Proxy" die folgenden: >> >> 1. Die Nutzer, die die Aenderungen vornehmen, sind/werden keine >> OSM-Nutzer. Sie sind Nutzer einer anderen Plattform, wissen im >> Extremfall nicht einmal was von OSM, fuehlen sich nicht als >> OSM-Contributors. Salopp gesagt, wir haben ihre Daten, aber nicht ihr >> Herz. Auch unsere Statistik kommt durcheinander - wir koennen dann >> nicht mehr zuverlaessig ermitteln, wie viele Leute mit welcher >> Intensitaet in einem bestimmten Bereich an OSM arbeiten. >> >> 2., und das folgt direkt aus 1., wir haben keine Moeglichkeit, die >> Nutzer zu kontaktieren. Haette es Kort schon vor 5 Jahren gegeben, wie >> haetten wir dann die Kort-Mitspieler erreichen koennen, um sie um >> Zustimmung zum Lizenzwechsel zu bitten? Oder wenn irgendwo doch mal >> etwas eingetragen wird, was andere Mapper falsch finden, wen koennen >> sie dann anschreiben mit einer Rueckfrage? >> >> 3. Wenn wir feststellen, dass mit einem Nutzer-Acccount >> urheberrechtlich geschueztes oder sonstwie problematisches Material >> hochgeladen wird, so muessen wir im Extremfall alle Edits dieses >> Nutzers revertieren. Es waere schade, wenn sowas mit einem >> "Gateway"-Account passiert. >> >> Im konkreten Fall ist der Punkt 1 relativ wenig relevant, denn wir >> haben gehoert, dass die allermeisten Kort-Spieler tatsaechlich >> OSM-Beitragende sind. Die Punkte 2 und 3 lassen sich vielleicht im >> konkreten Fall umschiffen oder zumindest abmildern. >> >> Ich glaube, es waere gut, wenn diese geplante naechste Projektphase >> bei Kort mit automatischem Hochspielen der Anderungen in Abstimmung >> mit der Data Working Group gestartet werden wuerde und wenn man das >> allgemein als "Erprobungsphase" deklarieren koennte; so wird Dritten >> klar, dass das Modell nicht ohne Ruecksprache nachgeahmt werden soll. >> Eventuell kann die Community dann gemeinsam zu einem Konsens kommen, >> welche Art von Edits auf welche Weise "durch Proxy" gemacht werden >> duerfen und welche nicht. >> >> Bye >> Frederik >> > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] "Sprache des Namens" Fehler in Kort.
Lieber Martin Am 19. Juni 2013 10:25 schrieb Martin Raifer : > danke für deine Antwort. Vielleicht habe ich mich bei dem einen oder anderen > Satz etwas zu stark ausgedrückt. Meine Gesamtaussage aber bleibt, dass Kort, > wie es sich zur Zeit präsentiert, in mehrsprachigen Regionen unspielbar ist. > Und das ist schade. Danke für deine Ausführungen; jetzt verstehe ich's besser. Mir ist bewusst, dass es Häufungen von einem "Fehler" geben kann. Mengenmässig sind weltweit gesehen wohl nur wenige Gebiete betroffen. Trotzdem braucht es Verbesserungen, wie du sie u.a. unten vorschlägst. > Ich komme aus Südtirol, eines der wenigen Gebiete in Europa, die "echt > mehrsprachig" sind. Dass es "echte" mehrsprachige Gebiete gibt, ist mir als Schweizer klar, wenn ich u.a. an Fribourg/Freiburg, Teile von Wallis und Graubünden oder Biel/Bienne denke. Im Kanton Fribourg/Freiburg entscheiden z.B. Gemeinden autonom, ob nun deutsch, franz. oder beides gilt). Oft ist dann immer noch unklar, welche Sprache zuerst geschrieben werden soll (und eine Regelung für Newline-Zeichen gibt es bei OSM-Tags meines Wissens nicht)! Wie Peter Wendorff schrieb, geht es hier nicht primär darum, zusätzliche Übersetzungen anzugeben. Beim name-Tag geht es um mehrere Aspekte, das letztlich in einem geografischen Namens-Schema abgehandelt und dokumentiert werden müssten: 1. Im name-Tag steht das was gemäss on-the-ground-Regel draussen zu sehen ist - und das was offizell und per Default auf der (Landes-)Karte angezeigt werden soll. Das sollte sich mit der offiziellen Schreibweise decken (sog. Endonyme, vgl. Wikipedia). Das kann mitunter auch eine chinesische Schrift sein - oder aber eben eine "echt" mehrsprachige Bezeichnung wie "Biel/Bienne". Für alle weiteren Fälle wird der name:XX-Tag verwendet. 2) Mit Blick auf (Welt-)Karten, die z.B. für uns Europäer lesbar sind, braucht es Exonyme, d.h. für uns lesbare geografische Namen, z.B. für asiatische Gebiete. 3) Mit Blick auf mehrsprachige Karten sollte eine Software erkennen können, in welcher Sprache der Name nun gilt. 4. Ausserdem gibt es eine Aussprache von Orten, wie sie inoffiziell, mundartlich oder historisch von Einheimischen verwendet werden (z.B. name:gsw=Rapperschwil für Rapperswil, vgl. nominatim). Es macht daher für mich Sinn, für alle geogr. Namen einen name:XX-Tag anzugeben auch bei mehrsprachigen name-Tags. Der Keepright-Fehlertext heißt sinngemäss "Wenn der name-Tag existiert, wäre es schön (nicht notwendig), wenn ein name:XX-Tag existierte.". Bei mehrsprachigen Namen gibt es hier nun tatsächlich ein Problem, dass Kort zurzeit fragt "In welcher Sprache ist der Name "nnn* geschrieben? (de, fr, etc.)" und dann den Tag "name=nnn" nimmt und ihn als "name:de=nnn" speichern will. Für Kort scheint mit da ein "nicht lösbar" immer noch die beste Antwort. Eine korrekte (Teil-)Lösung wären zwei (bzw. mehrere) name:XX-Tags. Eine Lösung, wie man in OSM angeben könnte, wo das es eine offizielle Ein- bzw. Mehrsprachenregelung gibt (wenn denn es eine gibt), könnten Sprach-Multipolygone sein, doch gibt es meines Wissens dazu noch keine Diskussion. Jochen Topf mit seiner Multilingual Map (http://mlm.jochentopf.com/ ) hat sich dazu ev. einige Überlegungen gemacht. Zu deinen Verbesserungsvorschlägen: > 1. Eine Möglichkeit bestimmte Fehlerkategorien auszublenden und stattdessen > andere Aufträge anzuzeigen. Ausgezeichnete Idee. Das leite ich gleich an die Kort-Developpers weiter. > 2. Immer einen ausgewogenen Mix an Aufträgen anzeigen, z.B. durch das > bewusste Zurückhalten von Aufträgen einer Kategorie ab einer festgelegten > maximalen Dichte. > > 3. Nie Aufträge stellen, von denen man weiß, dass diese nicht immer sinnvoll > sind. Vor allem dann nicht, wenn man weiß, dass der "nicht lösbare" Teil > lokal gehäuft vorkommt. Keine "Warnungen" als "Fehler" verkaufen! Was nun als "Fehler" gilt und was eine Warnung oder gar irrelevant sein soll, machmal eine Definitionsfrage. Solange es keine "(Mehr-)Sprachgebiete" gibt (wie oben vorgeschlagen), "weiss man" nicht, was nun gilt. Eine Dichte-Analyse scheint zwar spannend, ist aber für mich in keinem Verhältnis von Aufwand und Ertrag, die es betrifft. Dafür könnte das Fehlerkategorien-Ausblenden eine Abhilfe sein. > 4. Zusammenarbeit mit dem Hersteller der verwendeten > Qualitätsicherungssoftware (hier: keepright) zur Verbesserung der Qualität > der zur Verfügung gestellten Daten. Wir haben schon mehrmals mit Harald Kleiner kommuniziert. Ausserdem haben wir dank der EOSMDBOne-DB neu die Möglichkeit, selber Fehlerdaten zu extrahieren. > Für diesen speziellen Fall: Ich habe > bereits mit multilingualen Namen experimentiert und habe auch konkrete > Ideen, Das klingt interessant. Ich nehme an, die Diskussion wird hier auf Talk-de stattfinden? LG, Stefan Am 19. Juni 2013 10:25 schrieb Martin Raifer : > Lieber Stefan, > > danke für deine Antwort. Vielleicht habe ich mich bei dem einen oder anderen > Satz etwas zu stark ausgedrückt. Meine Gesamtau
Re: [Talk-de] "Sprache des Namens" Fehler in Kort. War: Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
Hallo Martin
Am 18. Juni 2013 16:44 schrieb Martin Raifer :
> Fakt ist, dass der für diesen Layer verwendete Fehlersuch-Algorithmus
> spätestens bei echt mehrsprachigen Regionen versagt und nur noch
> false-positives ausspuckt.
Die absolute Angabe "nur noch..." scheint mir etwas übertrieben.
> ...
> Das Feature in keepright mag zwar gut gemeint sein und könnte für
> nicht-mehrsprachige Regionen vielleicht auch sinvoll sein. Für mehrsprachige
> Namen bedarf es aber einer genaueren Auswertung um herauszufinden in welchen
> Sprachen der Name vorliegt.
Genau das ist Teil der Aufgabe beim Spielen.
Und sowohl bei keepright ("ignore") wie auch bei Kort ("nicht lösbar")
kann man false positives als solche angeben.
> Jedenfalls wird Kort durch das Einbinden dieser "Warnungen" in
> mehrsprachigen Regionen leider komplett unspielbar. :(
"Komplett unspielbar"?? Erstens ist es - wie du selber sagst - in
"einsprachigen Regionen" offenbar "spielbar", zweitens gibt es noch
sieben andere Fehlertypen (vgl. [1]). Warum also das Kind gleich mit
dem Bade ausschütten?
LG, Stefan
[1]
https://kort.uservoice.com/knowledgebase/articles/206970-was-f%C3%BCr-auftr%C3%A4ge-und-%C3%9Cberpr%C3%BCfungen-gibt-es-
Am 18. Juni 2013 16:44 schrieb Martin Raifer :
> Zum "language unknown" Layer von keepright hatte ich bereits vor einiger
> Zeit eine kurze Diskussion mit dem Macher von keepright. Mein Fazit:
>
> Fakt ist, dass der für diesen Layer verwendete Fehlersuch-Algorithmus
> spätestens bei echt mehrsprachigen Regionen versagt und nur noch
> false-positives ausspuckt. Beispiel: Freiburg[1] (name=Fribourg - Freiburg,
> name:de=Freiburg, name:fr=Fribourg) wird in keepright [2] fälschlicherweise
> angezeigt. Oder noch extremer: fast Alles in Südtirol[3], Brüssel, …
>
> Unter anderem deshalb befindet sich dieser Layer in keepright auch in der
> Kategorie "Warnung" und nicht unter "Fehler".
>
> Das Feature in keepright mag zwar gut gemeint sein und könnte für
> nicht-mehrsprachige Regionen vielleicht auch sinvoll sein. Für mehrsprachige
> Namen bedarf es aber einer genaueren Auswertung um herauszufinden in welchen
> Sprachen der Name vorliegt.
>
> Jedenfalls wird Kort durch das Einbinden dieser "Warnungen" in
> mehrsprachigen Regionen leider komplett unspielbar. :(
>
> Liebe Grüße
> Martin
>
> [1] http://www.openstreetmap.org/browse/node/1685926271
> [2]
> http://keepright.ipax.at/report_map.php?zoom=18&lat=46.80319&lon=7.1523&layers=B0T&ch=0%2C360&show_ign=1&show_tmpign=1
> [3]
> http://keepright.ipax.at/report_map.php?zoom=16&lat=46.67399&lon=11.15604&layers=B0T&ch=0%2C360&show_ign=1&show_tmpign=1
>
>
> Am 18.06.2013, 16:04 Uhr, schrieb Stefan Keller :
>
>> Hallo Simeon
>>
>> Vorab: Kort basiert auf Daten von keepright und neu auf mittels
>> osm2pgsql nach PostgreSQL aufbereitete Daten. "Sprache des Namens" ist
>> ein Fehlertyp von keepright.
>>
>> Wie soll ein Auswertesystem "merken" in welcher Sprache ein Name
>> geschrieben ist?
>>
>> "Sprache des Namens" finde ich sehr sinnvoll, denn es ist durchaus
>> nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden,
>> geschweige denn dass innerhalb eines Landes oder Region nur eine
>> Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR,
>> IT oder den USA immer wieder meinen ;-)).
>>
>> LG, Stefan
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
Am 18. Juni 2013 21:48 schrieb Simeon : > Checkt Kort auch die Änderungen oder woher "weiß" es ob jemand den Fehler in > OSM eingetragen hat? Kort prüft zuerst ob der Node überhaupt noch in der OSM DB vorhanden ist und dann, ob der Keys (z.B. "cuisine") fehlt bzw. der Value leer ist. Dann ist die Lösung von Kort noch aktuell. LG, Stefan Am 18. Juni 2013 21:48 schrieb Simeon : > Guten Abend Stefan und wer sonst noch so zuhört, > > Wenn das mit dem Blättern ginge. wäre das klasse. Auch die Anmerkungen > bezüglich der Sprache sehe ich jetzt nicht mehr so eng. Es kann sinnvoll > sein, die Sprache anzugeben; aber in größeren sprachlich zusammenhängenden > Gebieten ist und bleibt es unwahrscheinlich. Reicht dann eigentlich name:de > als Untergruppe von name oder sollte beides dabei sein? Vermutlich beides, > damit alle benannten Dinge ein "name=" haben. > > Checkt Kort auch die Änderungen oder woher "weiß" es ob jemand den Fehler in > OSM eingetragen hat? > > Grüße - Simeon > > Am 18.06.2013 16:38, schrieb Stefan Keller: > >> Hallo Theodin (sorry meine Namensverwechslung) >> >> Ich sehe gerade, dass es bei den Lösungen keine Möglichkeit mehr gibt, >> weitere 10 Lösungen anzuzeigen. Damit könntest du nach "spannenderen" >> Lösungen suchen und andere weglassen. Das hatten wir mal in einer >> früheren Version drin. Ich schaue mal, ob wir wenigstens dieses >> "Blättern" wieder hinkriegen. >> >> LG, Stefan >> >> P.S. Die Lösungen-Seite ist übrigens so langsam, weil es jeden der 10 >> Einträge mit einem Aufruf an OSM prüfen muss, ob das OSM-Objekt noch >> vorhanden ist. >> >> >> Am 18. Juni 2013 16:04 schrieb Stefan Keller : >>> >>> Hallo Simeon >>> >>> Vorab: Kort basiert auf Daten von keepright und neu auf mittels >>> osm2pgsql nach PostgreSQL aufbereitete Daten. "Sprache des Namens" ist >>> ein Fehlertyp von keepright. >>> >>> Wie soll ein Auswertesystem "merken" in welcher Sprache ein Name >>> geschrieben ist? >>> >>> "Sprache des Namens" finde ich sehr sinnvoll, denn es ist durchaus >>> nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden, >>> geschweige denn dass innerhalb eines Landes oder Region nur eine >>> Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR, >>> IT oder den USA immer wieder meinen ;-)). >>> >>> LG, Stefan >>> >>> Am 18. Juni 2013 15:48 schrieb Simeon : >>>> >>>> Hallo Stefan und alle anderen, >>>> >>>> Ich wollte die Tage einige Vorschläge zurück zu OSM eintragen, da fiel >>>> mir >>>> auf, dass alle aufgeführten Proposals nur von der Art "Sprache des >>>> Namens >>>> unbekannt" sind. Nach Nachfrage im Forum ( >>>> http://forum.openstreetmap.org/viewtopic.php?id=21557 ) bin ich davon >>>> abgekommen, die alle einzutragen, da sie meiner (und auch der anderen >>>> Poster) Meinung nach redundant und unnötig ist. Was hattet ihr euch >>>> überlegt >>>> als ihr die ins Spiel genommen habt? Gibt es Gründe, die alle doch >>>> einzutragen? Lohnt es sich, diese Art Fehler raus zunehmen sodass mehr >>>> sinnvollere Tasks anfallen? >>>> >>>> Grüße - Theodin >>>> >>>> >>>> Am 15.06.2013 17:13, schrieb Markus Semm: >>>> >>>>> Hallo Stefan, >>>>> >>>>> auf der Fossgis wurde diese Woche von den Kort-Entwicklern im Rahmen >>>>> der >>>>> Projektpräsentation gesagt, dass die bislang fast 25.000 Änderungen, >>>>> die >>>>> Nutzer von Kort bislang vorgenommen haben, noch gar nicht an OSM >>>>> übertragen >>>>> wurden, wohl wegen grundsätzlicher Bedenken hinsichtlich einer >>>>> automatischen >>>>> Änderung von Daten in OSM, die die schweizer Community vorgetragen hat. >>>>> Frederik hat zwar in der selben Session darauf hingewiesen, dass er das >>>>> Thema "automatisierte Updates" im Fall Kort entspannt sieht (und ich >>>>> schließe mich dem an), vom Kort-Team kam aber dann keine Aussage mehr, >>>>> ob >>>>> und wann die mühsam von mir und vielen anderen recherchierten Daten >>>>> zurückfließen ins OSM. >>>>> >>>>> Kannst Du dazu etwas Konkretes sagen? >>>>> >>>>> Gruß >>>>
Re: [Talk-de] Kort Game mit neuer Aktion/Kampagne dieses Wochenende!
Ja; in Kort gibt es die Möglichkeit "unlösbar" anzuwählen. Das sieht man auch in der Statistik der "normalen" Webseite: http://www.kort.ch/statistics.php LG, Stefan Am 18. Juni 2013 17:21 schrieb René Kirchhoff : > Hallo Stefan. > Dabei sollte man nicht vergessen, dass man in keepright einen Fehler auch > als "kein Fehler" kennzeichnen kann. > Gibt es diese Möglichkeit auch bei Kort oder ist der Fehler nur Lösbar, > indem ich den ggf. identischen Namen ein zweites mal angebe? > (Kann es selber nicht prüfen, da FF und IE leider nicht unterstützt werden.) > Gruß René > > Am 18. Juni 2013 16:04 schrieb Stefan Keller : > >> Hallo Simeon >> >> Vorab: Kort basiert auf Daten von keepright und neu auf mittels >> osm2pgsql nach PostgreSQL aufbereitete Daten. "Sprache des Namens" ist >> ein Fehlertyp von keepright. >> >> Wie soll ein Auswertesystem "merken" in welcher Sprache ein Name >> geschrieben ist? >> >> "Sprache des Namens" finde ich sehr sinnvoll, denn es ist durchaus >> nicht so, dass Ländergrenzen eine Sprachgrenze bilden würden, >> geschweige denn dass innerhalb eines Landes oder Region nur eine >> Sprache gesprochen wird (auch wenn das einige Landsmänner aus DE, FR, >> IT oder den USA immer wieder meinen ;-)). >> >> LG, Stefan >> >> Am 18. Juni 2013 15:48 schrieb Simeon : >> > Hallo Stefan und alle anderen, >> > >> > Ich wollte die Tage einige Vorschläge zurück zu OSM eintragen, da fiel >> mir >> > auf, dass alle aufgeführten Proposals nur von der Art "Sprache des Namens >> > unbekannt" sind. Nach Nachfrage im Forum ( >> > http://forum.openstreetmap.org/viewtopic.php?id=21557 ) bin ich davon >> > abgekommen, die alle einzutragen, da sie meiner (und auch der anderen >> > Poster) Meinung nach redundant und unnötig ist. Was hattet ihr euch >> überlegt >> > als ihr die ins Spiel genommen habt? Gibt es Gründe, die alle doch >> > einzutragen? Lohnt es sich, diese Art Fehler raus zunehmen sodass mehr >> > sinnvollere Tasks anfallen? >> > >> > Grüße - Theodin >> > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
