Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 12.10.2011 23:47, schrieb Tobias Hobmeier: On 12.10.2011 10:00, Nils Faerber wrote: Am 12.10.2011 09:28, schrieb Sven Geggus: Tim Teulingst...@framstag.com wrote: Es hat zwar Überlegungen gegeben, libosmscout für das Map-Rendering in Monav zu integrieren, dies ist aber noch nicht geschehen. Der aktuell verwendete Renderer ist ein anderer. Von den Screenshots her ist meinem persönlichen Empfinden nach libosmscout schicker, aber so etwas ist immer Geschmackssache. Als ich Monav das letzte mal gesehen habe konnte der Renderer noch keine Straßennamen anzeigen. Geht das inzwischen? Ich habe mir gestern mal Monav 0.3 auf dem N900 installiert und die Deutschland Karte (4GB) dazu. Also das ist schon gar nicht schlecht! Die Kartendarstellung ist ganz hübsch, aber ohne Straßennamen. Die wichtigsten Einstellungen kann man im GUI machen (im Gegensatz bspw. zu Navit). Die Karte kann in der Bewegungsrichtung ausgerichtet werden. Der Hammer ist das Routing! Zum einen ist die Auswahl des Routingziels mal endlich sinnvoll an die Gegebenheiten von OSM angepaßt: Man wählt Stadt und Straßennamen - das ist etwas, was in OSM ja wirklich hinreichend gut vorhanden ist. Mit Hausnummern haben wir in OSM noch so unser Problem und Monav löst das recht elegant: Bei der Zielauswahl wird nach Eingabe von Stadt und Straßenname ein Kartenausschnitt mit der Straße gezeigt und man kann dann einfach einen Punkt auf der Straße auswählen (anclicken) wo man hin will. Das finde ich einen gelungenen Kompromiß! Die Routenberechnung anschließend dauert gefühlt 0,0 Sekunden - das ist der Hammer! Ich weiß nicht wie die das machen, aber es ist unglaublich schnell. Von dem was ich bisher gesehen habe, ist auch die ausgewählte Strecke halbwegs sinnvoll. Es ist allerdings in dieser Form noch nicht wirklich gut als Fahrzeug Navi verwendbar, da die Fahrtanweisungen nur in einer Art Statusbar klein unter der Kartendarstellung angezeigt werden - aber das ist wirklich Kosmetik. Wenn man einen Beifahrer hat, kann man dem das sicherlich in die Hand drücken und ihn/sie die Anweisungen geben lassen ;) Also suma sumarum: Monav auf mobilem Gerät (V0.3 auf N900) ist schon ein ganz schön starkes Stück! Gruss Sven Viele Grüße nils Kann mir jemand sagen wie man in MoNav das Vector Rendering an bekommt? Äh... laß'mal gucken... Einstellungen - Map Modules - Rendering: Vector Gruß Tobi Viele Grüße nils faerber -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 17.10.2011 14:57, schrieb Nils Faerber: Am 12.10.2011 23:47, schrieb Tobias Hobmeier: On 12.10.2011 10:00, Nils Faerber wrote: Am 12.10.2011 09:28, schrieb Sven Geggus: Tim Teulingst...@framstag.com wrote: [...] Also suma sumarum: Monav auf mobilem Gerät (V0.3 auf N900) ist schon ein ganz schön starkes Stück! Gruss Sven Viele Grüße nils Kann mir jemand sagen wie man in MoNav das Vector Rendering an bekommt? Äh... laß'mal gucken... Einstellungen - Map Modules - Rendering: Vector Habe nochmal etwas weiter geguckt - leider ist es nach dem Release 0.3 von Monav reichlich still geworden. Seit April 2011 keine Updates mehr im Code - schade eigentlich, die Routing-Funktion war schon brachial schnell. Bleibt mal wieder nur libosmscout - hallo Tim ;) Gruß Tobi Viele Grüße nils -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Nils Faerber nils.faer...@kernelconcepts.de wrote: Habe nochmal etwas weiter geguckt - leider ist es nach dem Release 0.3 von Monav reichlich still geworden. Seit April 2011 keine Updates mehr im Code - schade eigentlich, die Routing-Funktion war schon brachial schnell. Die Routingfunktion ist in einem separaten daemon implementiert, der z.B. auch von Marble verwendet wird. Prinzipiell sollte es daher möglich sein für Android und Konsorten native frontends zu schreiben. Gruss Sven -- Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety (Benjamin Franklin) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo allerseits, danke fuer die vielen Rueckmeldungen zu meiner Frage nach Ideen wie man mehr Entwickler an OSM begeistert, insbesondere an den Core Teilen. Ich wollte zunaechst einmal Ideen unbeeinflusst sammeln und bin desshalb noch nicht auf einzelne Ideen eingeganen. Hoffentlich werde ich in den naechsten paar Tagen dazu kommen genauer auf die Ideen einzugehen die im Rahmen der EWG zumindestens denkbar sind und versuchen zu erarbeiten was genau hilft, ob die Sachen die erreicht wurden dem entsprechen und ob wie so oft die geforderten Dinge bereits existieren nur das es keiner kennt da es auf irgendeiner wiki Seite versteckt ist. Kai -- View this message in context: http://gis.638310.n2.nabble.com/Mehr-OpenStreetMap-Softwareentwicklung-und-die-Engineering-WG-tp6879238p6900899.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und?die?Engineering WG
Sven Geggus schrieb: Robert Kaiserka...@kairo.at wrote: Ja, schon. Client-seitig gibt es Java eigentlich nur mehr auf Altlasten oder in Betrieben. Nicht alles kann man als Webapplikation programmieren. Aber das wird jetzt Off-Topic hier. Noch nicht alles, das stimmt. Viele OSM-bezogene Dinge aber sehr wohl, um zum Thema zurück zu kommen. Und eine Karten-, Tracking- und ev. sogar auf Navigation hinauslaufende Anwendung ist durchaus möglich, besonders durch die Geolocation-fähigkeit moderner Browser, die zumeist auch auf GPS-Daten eines Gerätes zurückgreifen kann. Und zu sowas wollte ich ermutigen. :) Robert Kaiser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Dimitri Junker schrieb: Und warum eine sterbende Sprache probieren? *g* Was Java stirbt auch schon? Ja, schon. Client-seitig gibt es Java eigentlich nur mehr auf Altlasten oder in Betrieben. Server-seitig scheint es relativ stabil zu sein. Robert Kaiser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und?die?Engineering WG
Robert Kaiser ka...@kairo.at wrote: Ja, schon. Client-seitig gibt es Java eigentlich nur mehr auf Altlasten oder in Betrieben. Nicht alles kann man als Webapplikation programmieren. Aber das wird jetzt Off-Topic hier. Gruss Sven -- Um Kontrolle Ihres Kontos wiederzugewinnen, klicken Sie bitte auf das Verbindungsgebrüll. (aus einer Ebay fishing Mail) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Peter Wendorff wendo...@uni-paderborn.de wrote: Also im Hinblick auf Android wäre ich vorsichtig damit, Java als tot abzustempeln. Ich bin fest davon überzeugt (bzw. ich hoffe es), dass Smartphone Apps eine temporäre Erscheinung sind, die es nur so lange gibt wie generische Programme aka Webbrowser noch nicht genügend features haben. Es ist doch faktisch ein fürchterlicher Rückschritt zur Browserbasierten Internet PC/Mac/Linux Welt, dass man im Mobilbereich Software für mindestens 3 inkompatible Plattformen in mindestens 3 inkompatiblen Programmiersprachen erstellen muß. Gruss Sven -- Das ist halt der Unterschied: Unix ist ein Betriebssystem mit Tradition, die anderen sind einfach von sich aus unlogisch. (Anselm Lingnau in de.comp.os.unix.discussion) /me ist giggls@ircnet, http://sven.gegg.us/ im WWW ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Hi. Also im Hinblick auf Android wäre ich vorsichtig damit, Java als tot abzustempeln. Gruß Peter Am 13.10.2011 16:19, schrieb Robert Kaiser: Dimitri Junker schrieb: Und warum eine sterbende Sprache probieren? *g* Was Java stirbt auch schon? Ja, schon. Client-seitig gibt es Java eigentlich nur mehr auf Altlasten oder in Betrieben. Server-seitig scheint es relativ stabil zu sein. Robert Kaiser ___ 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] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Hallo! Ich bin fest davon überzeugt (bzw. ich hoffe es), dass Smartphone Apps eine temporäre Erscheinung sind, die es nur so lange gibt wie generische Programme aka Webbrowser noch nicht genügend features haben. Es ist doch faktisch ein fürchterlicher Rückschritt zur Browserbasierten Internet PC/Mac/Linux Welt, dass man im Mobilbereich Software für mindestens 3 inkompatible Plattformen in mindestens 3 inkompatiblen Programmiersprachen erstellen muß. Ja. Aber es liegt nicht im Interesse des Herstellers, kompatibel zur Konkurenz zu sein. Aktuell ist die Wahl von Sprache, etc.. Bei mobilen Plattform offensichtlich begruendet in dem Versuch, sich abzugrenzen und Entwickler und User zu binden. -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Tach, Am 13.10.2011 um 17:57 schrieb Sven Geggus: Peter Wendorff wendo...@uni-paderborn.de wrote: Also im Hinblick auf Android wäre ich vorsichtig damit, Java als tot abzustempeln. Ich bin fest davon überzeugt (bzw. ich hoffe es), dass Smartphone Apps eine temporäre Erscheinung sind, die es nur so lange gibt wie generische Programme aka Webbrowser noch nicht genügend features haben. Es ist doch faktisch ein fürchterlicher Rückschritt zur Browserbasierten Internet PC/Mac/Linux Welt, dass man im Mobilbereich Software für mindestens 3 inkompatible Plattformen in mindestens 3 inkompatiblen Programmiersprachen erstellen muß. Gerade Apple wollte doch keine Apps zulassen, erst nachdem die Entwickler rumgenölt haben, hat Steve sich überreden lassen. Glaube auch, das Apps eine vorübergehende Erscheinung sind. Mfg Marc ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo, Ich meld' mich mal aus dem Marble Team (http://edu.kde.org/marble) zu Wort: In Marble bemühen wir uns ja auch um eine möglichst gute OSM integration. Wer Marble noch nicht kennt: Hier ist ein Flyer zur Applikation http://developer.kde.org/~tackat/marble_1_2.pdf und zur Marble-Bibliothek: http://developer.kde.org/~tackat/libmarble_0_12_0.pdf ... und natürlich suchen wir auch stets Leute, die daran interessiert sind, an Marble mit zu entwickeln (Themen gibt es ja genug): http://edu.kde.org/marble/getinvolved.php Zum eigentlichen Thema des Threads gäbe es sicherlich viel zu sagen, aber ich denke wir sind in bezug auf Marble nicht unbedingt repräsentativ für alle Projekte. Ich wollte nun hauptsächlich einen Kommentar zum Entwicklertreffen loswerden: On Tuesday, 11. October 2011 09:48:23 Jochen Topf wrote: Developer-Meetings würden sicher helfen. Hier und dort reden Leute in Deutschland seit Monaten, dass man sowas mal wieder machen sollte. Nimmt nur keiner in die Hand. Dabei haben wir mit dem Linuxhotel ne gute Location und beim FOSSGIS könnte man wegen Geldern anfragen. Kai: Wäre das nicht eine Aufgabe für Dich? :-) Wir hatten letztes Jahr ein Marble Entwicklertreffen: http://dot.kde.org/2010/11/10/kdes-marble-team-holds-first-contributor-sprint und wir haben eigentlich auch für die nächsten Monate einen weiteren Marble Sprint vorgesehen. Vielleicht könnte man das ganze mit dem Treffen anderer OSM-nutzender Projekte irgendwie kombinieren/integrieren. Oder wir würden einfach an dem Treffen teilnehmen. Ich habe noch keine Rücksprache mit unseren übrigen Entwicklern gehalten, aber so wie ich die kenne, wären wir durchaus an einem solchen vorgeschlagenen Treffen interessiert :-) Viele Grüße, Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Tim Teulings t...@framstag.com wrote: Es hat zwar Überlegungen gegeben, libosmscout für das Map-Rendering in Monav zu integrieren, dies ist aber noch nicht geschehen. Der aktuell verwendete Renderer ist ein anderer. Von den Screenshots her ist meinem persönlichen Empfinden nach libosmscout schicker, aber so etwas ist immer Geschmackssache. Als ich Monav das letzte mal gesehen habe konnte der Renderer noch keine Straßennamen anzeigen. Geht das inzwischen? Gruss Sven -- Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der Demokraten (Theodor W. Adorno) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und?die?Engineering WG
Wolfgang wolfg...@ivkasogis.de wrote: Das bezweifel ich ja gar nicht. Aber die Frage war die nach den Gründen, warum es so wenige Entwickler Abgesehen von ein paar großen Leuchtturmprojekten (Linux Kernel, ...) ist auch das bei freier Software leider eher der Normalfall. Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 12.10.2011 09:28, schrieb Sven Geggus: Tim Teulings t...@framstag.com wrote: Es hat zwar Überlegungen gegeben, libosmscout für das Map-Rendering in Monav zu integrieren, dies ist aber noch nicht geschehen. Der aktuell verwendete Renderer ist ein anderer. Von den Screenshots her ist meinem persönlichen Empfinden nach libosmscout schicker, aber so etwas ist immer Geschmackssache. Als ich Monav das letzte mal gesehen habe konnte der Renderer noch keine Straßennamen anzeigen. Geht das inzwischen? Ich habe mir gestern mal Monav 0.3 auf dem N900 installiert und die Deutschland Karte (4GB) dazu. Also das ist schon gar nicht schlecht! Die Kartendarstellung ist ganz hübsch, aber ohne Straßennamen. Die wichtigsten Einstellungen kann man im GUI machen (im Gegensatz bspw. zu Navit). Die Karte kann in der Bewegungsrichtung ausgerichtet werden. Der Hammer ist das Routing! Zum einen ist die Auswahl des Routingziels mal endlich sinnvoll an die Gegebenheiten von OSM angepaßt: Man wählt Stadt und Straßennamen - das ist etwas, was in OSM ja wirklich hinreichend gut vorhanden ist. Mit Hausnummern haben wir in OSM noch so unser Problem und Monav löst das recht elegant: Bei der Zielauswahl wird nach Eingabe von Stadt und Straßenname ein Kartenausschnitt mit der Straße gezeigt und man kann dann einfach einen Punkt auf der Straße auswählen (anclicken) wo man hin will. Das finde ich einen gelungenen Kompromiß! Die Routenberechnung anschließend dauert gefühlt 0,0 Sekunden - das ist der Hammer! Ich weiß nicht wie die das machen, aber es ist unglaublich schnell. Von dem was ich bisher gesehen habe, ist auch die ausgewählte Strecke halbwegs sinnvoll. Es ist allerdings in dieser Form noch nicht wirklich gut als Fahrzeug Navi verwendbar, da die Fahrtanweisungen nur in einer Art Statusbar klein unter der Kartendarstellung angezeigt werden - aber das ist wirklich Kosmetik. Wenn man einen Beifahrer hat, kann man dem das sicherlich in die Hand drücken und ihn/sie die Anweisungen geben lassen ;) Also suma sumarum: Monav auf mobilem Gerät (V0.3 auf N900) ist schon ein ganz schön starkes Stück! Gruss Sven Viele Grüße nils -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo, Am Dienstag, 11. Oktober 2011 19:56:16 schrieb Frederik Ramm: Hallo, On 10/11/2011 03:35 PM, Wolfgang wrote: Es liegt an den zu hohen Hürden. Für Josm kann man Plugins schreiben. Dazu gibt es sicher auch eine Schnittstelle. Um die vernünftig zu finden, die Doku zu sichten, die zur Zeit gültige Variante zu finden und den ganzen Kram zu verstehen würde ich mal locker 1-2 Monate veranschlagen. Schön, wenn jemand die Zeit und Motivation hat, sich da durchzubeißen, ich habe das nicht. Wichtig ist eine einfach verständliche Doku mit Beispielen in aktueller Form. Etwas Einfaches zum Anfüttern und keine High-End-Lösungen Ich denke, da reden wir wieder mal aneinander vorbei. Dass fuer den Anwender eines Dienstes, einer Bibliothek oder einer API diese gut dokumentiert sein muss, damit er darauf aufbauend seine Sache entwickeln kann, ist klar. Die Frage, die hier gestellt wurde, bezog sich weniger auf den Mangel an JOSM-Plugins - da herrscht mittlerweile ja eine ziemliche Flut! - oder auf ein Fehlen praktischer Applikationen, die auf XAPI/Overpass aufsetzen, sondern auf den Mangel an Entwicklern bei Kernkomponenten. Josm war nur ein Beispiel. Die Mitarbeit am Rails-Port ist nun mal nicht trivial, und ich zweifle daran, dass diejenigen, fuer die das Fehlen einer einfachen und verstaendlichen Doku mit Beispielen in aktueller Form eine Huerde ist, wirklich gute Arbeit am Rails-Port machen koennen. Und ich bezweifle, dass alle, die daran mitarbeiten könnten, bereit sind, sich zunächst mal in so ein Projekt einzuarbeiten. Da ist es viel cooler, etwas eigenes auf die Beine zu stellen, sebst wenn es die x-te app und überflüssig wie sonstwas ist. Die Entwickler müssen sich halt entscheiden: Entweder sie halten sich für eine elitäre Gruppe, die anderen weit überlegen ist und über den Dingen schwebt, dann müssen sie den Job mehr oder weniger allein bewältigen, oder sie suchen gezielt Unterstützung, dann müssen sie von dem Ross absteigen und den Interessenten entgegen kommen. Wenn im kommerziellen Leben ein Mitarbeiter gesucht wird, gibt es auch zunächst einen Wunschzettel, wie der aussehen soll. Davon bleibt allerdings meistens nicht viel übrig und es dauert je nach Job bis zu 2 Jahre, bis der Neue so weit eingearbeitet ist, dass er richtig produktiv wird. Aber das ist natürlich für denjenigen, der ihn anlernt, uncool. Daraus folgt auch, dass deutschsprachige Dokumentation in diesen Dingen relativ wenig nuetzlich ist, denn jemand, der seine Arbeit nicht in der persoenlichen Diskussion auf Englisch mit der internationalen Entwickler-Community vertreten kann, dessen Arbeit wird immer nur halb so brauchbar sein als die von jemandem, der das kann. Daraus folgt wiederum, dass hier nicht der richtige Platz ist, um solche Probleme zu beraten. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 12.10.2011 10:00, schrieb Nils Faerber: Ich habe mir gestern mal Monav 0.3 auf dem N900 installiert und die Deutschland Karte (4GB) dazu. Gibt's das auch für Android? Also das ist schon gar nicht schlecht! Die Kartendarstellung ist ganz hübsch, aber ohne Straßennamen. Die wichtigsten Einstellungen kann man im GUI machen (im Gegensatz bspw. zu Navit). Die Karte kann in der Bewegungsrichtung ausgerichtet werden. Der Hammer ist das Routing! Zum einen ist die Auswahl des Routingziels mal endlich sinnvoll an die Gegebenheiten von OSM angepaßt: Man wählt Stadt und Straßennamen - das ist etwas, was in OSM ja wirklich hinreichend gut vorhanden ist. Mit Hausnummern haben wir in OSM noch so unser Problem Meiner Meinung sind bereits so viele davon erfasst, dass man das nicht als Ausrede gelten lassen kann, Hausnummernsuche nicht zu implementieren. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hi, On 10/12/11 10:11, Wolfgang wrote: Die Entwickler müssen sich halt entscheiden: Entweder sie halten sich für eine elitäre Gruppe, die anderen weit überlegen ist und über den Dingen schwebt, dann müssen sie den Job mehr oder weniger allein bewältigen, oder sie suchen gezielt Unterstützung, dann müssen sie von dem Ross absteigen und den Interessenten entgegen kommen. Die Entwickler haben selber nur begrenzt Zeit und setzen die ein, um das Noetigste zu tun, was getan werden muss. Ausserdem sind gute Entwickler oft schlecht im Erklaeren. Deshalb gibt es wenig brauchbare Dokumentation von Entwicklern. Das hat nichts mit sich fuer cool halten zu tun, sondern damit, dass jeder das tut, was er gut kann (oder was ihm leicht faellt). Daraus folgt auch, dass deutschsprachige Dokumentation in diesen Dingen relativ wenig nuetzlich ist, denn jemand, der seine Arbeit nicht in der persoenlichen Diskussion auf Englisch mit der internationalen Entwickler-Community vertreten kann, dessen Arbeit wird immer nur halb so brauchbar sein als die von jemandem, der das kann. Daraus folgt wiederum, dass hier nicht der richtige Platz ist, um solche Probleme zu beraten. Nur dann, wenn man annaehme, dass talk-de lediglich von Leuten frequentiert wird, deren Englisch zu schlecht fuer talk ist. Das ist nach meiner Erfahrung aber nicht zutreffend. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hi, On 10/11/11 03:11, Kai Krueger wrote: Um dieser Frage nachzugehen haben sich ein paar Devs vor ein paar Wochen unter dem Schirm der Engineering Working Group (EWG) zusammen getan um zu schauen ob wir etwas tun koennen um den Einstieg in die OpenStreetMap Entwicklung zu erleichtern und mehr Leute dafuer begeistern koennen. Ich glaube, es gibt genuegend Leute, die willens und in der Lage sind, sich in diese Tools einzuarbeiten und mitzumachen. Man muss es nur schaffen, denen klarzumachen, dass ihre Hilfe willkommen ist und dass sie - in bestimmten Grenzen natuerlich - auch schnell an den Punkt kommen, wo sie Gestaltungsspielraum haben. Ich vermute, dass viele Leute von den Core-Projekten den Eindruck haben, dass diese fest in der Hand von anderen seien, und diese anderen vermutlich schon auf einer 2-Jahres-Roadmap festgelegt haben, welche Features in die heiligen Core-Projekte eingebaut werden. Was es braeuchte, waere so ein paar success stories, die man den Leuten als Wurst vor die Nase haengen kann. Z.B. als Mikel Maron - der ja in Sachen Rails-Port vorher nicht als Programmierer in Erscheinung getreten war - neulich dieses Feature gebaut hat, mit dem man per mouse-over die Changeset-Regionen in gelb auf der Karte sieht. Wenn man diese Botschaft besser rueberbringt: Es ist zwar eine ziemliche Huerde am Anfang, aber wenn Du ein bisschen Rails kannst, kannst Du in einer Woche so ein Feature bauen und eine Woche spaeter kann das schon live sein und Mappern bei der Arbeit helfen, dann ziehen wir damit auch mehr von den Leuten an, die motiviert sind. Tendenziell wuerde ich sagen, dass es uns mehr bringt, zu versuchen, die Leute anzuziehen, die diese Motivation schon mitbringen (und die bislang lediglich dachten, man will/braucht sie nicht), als dass wir versuchen, immer mehr (vermeintliche?) Huerden abzubauen, um schliesslich auch diejenigen mit geringer Motivation anzuziehen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Date: Tue, 11 Oct 2011 22:46:10 +0200 From: Dimitri Junker o...@dimitri-junker.de To: Wolfgang talk-de@openstreetmap.org Subject: Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG Message-ID: 11102011224642i2c0019rohaa9feb...@dimitri-junker.de Content-Type: text/plain; charset=ISO-8859-1 Was ich mir w?nschen w?rde w?re eine Seite mit einer Liste aller Programme f?r die Programmierer gesucht werden, am besten in Tabellenform. Nat?rlich mit Angabe von Programmiersprache, Betriebssystem, Programmierumgebung, und Links auf eine Einf?hrung wie man an die Programmierumgebung aufbaut und den Quellcode l?dt. Zus?tzlich oder auch notfalls alternativ ein Ansprechpartner der einem beim Einstieg hilft. H?tte ich so jemanden w?rde ich dann z.B. auch meine Erfahrung niederschreiben, so da? der n?chste Einsteiger weniger Probleme h?tte. Dies k?nnte ich warscheinlich besser als jemand der das System schon ewig kennt, da der sich garnicht mehr vorstellen kann wo die Probleme sind. Gru? Dimitri Hi! Ich kann dir/euch gerne beim Einrichten vom Amenity Editor (http://ae.osmsurround.org) und Relation Analyzer (http://ra.osmsurround.org) helfen. Beide Projekte sind in Java geschrieben und auf GitHub online (https://github.com/grundid). In der Readme steht auch eine Liste von Plugins, die man für Eclipse braucht. Gerne können wir hierzu auch eine Chatsession auf Skype oder IRC machen, dann geht es einfacher, falls du irgendwo hängen bleibst. Gib einfach Bescheid. Viele Grüße, Adrian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 12.10.2011 10:21, schrieb Chris66: Am 12.10.2011 10:00, schrieb Nils Faerber: Ich habe mir gestern mal Monav 0.3 auf dem N900 installiert und die Deutschland Karte (4GB) dazu. Gibt's das auch für Android? AFAIK nein: http://monav.openstreetmap.de/ Wäre vermutlich auch ein etwas seltsamer Port, da das ja schon sehr GUI-lastig ist und Android ein sehr eigenes GUI hat. Also das ist schon gar nicht schlecht! Die Kartendarstellung ist ganz hübsch, aber ohne Straßennamen. Die wichtigsten Einstellungen kann man im GUI machen (im Gegensatz bspw. zu Navit). Die Karte kann in der Bewegungsrichtung ausgerichtet werden. Der Hammer ist das Routing! Zum einen ist die Auswahl des Routingziels mal endlich sinnvoll an die Gegebenheiten von OSM angepaßt: Man wählt Stadt und Straßennamen - das ist etwas, was in OSM ja wirklich hinreichend gut vorhanden ist. Mit Hausnummern haben wir in OSM noch so unser Problem Meiner Meinung sind bereits so viele davon erfasst, dass man das nicht als Ausrede gelten lassen kann, Hausnummernsuche nicht zu implementieren. ;-) Ausrede ist das sicherlich keine ;) Aber ich finde es eine gute Lösung, um das Problem vorerst zu umgehen. Hier in Siegen würde ich mal grob schätzen, daß maximal 20% der Hausnummer erfaßt sind, d.h. mit knapp 80% Wahrscheinlichkeit, wird man hier nicht das Haus finden, wo man hin will. Chris Viele Grüße nils -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 12.10.2011 10:40, schrieb Nils Faerber: Ausrede ist das sicherlich keine ;) Aber ich finde es eine gute Lösung, um das Problem vorerst zu umgehen. Hier in Siegen würde ich mal grob schätzen, daß maximal 20% der Hausnummer erfaßt sind, d.h. mit knapp 80% Wahrscheinlichkeit, wird man hier nicht das Haus finden, wo man hin will. Eine Sinnvolle Lösung wäre, wenn er den Nutzer nur selber suchen lässt, wenn er keine Hausnummer findet. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 12.10.2011 11:20, schrieb Henning Scholland: Am 12.10.2011 10:40, schrieb Nils Faerber: Ausrede ist das sicherlich keine ;) Aber ich finde es eine gute Lösung, um das Problem vorerst zu umgehen. Hier in Siegen würde ich mal grob schätzen, daß maximal 20% der Hausnummer erfaßt sind, d.h. mit knapp 80% Wahrscheinlichkeit, wird man hier nicht das Haus finden, wo man hin will. Eine Sinnvolle Lösung wäre, wenn er den Nutzer nur selber suchen lässt, wenn er keine Hausnummer findet. Das wäre ganz klar eine Verbesserung, keine Frage. Nur ist es mir deutlich lieber auf dieser Art (in Karte) einen Punkt wählen zu können, als gar keine Adresse zu finden. Henning Viele Grüße nils -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 12.10.2011 10:40, schrieb Nils Faerber: Hier in Siegen würde ich mal grob schätzen, daß maximal 20% der Hausnummer erfaßt sind, d.h. mit knapp 80% Wahrscheinlichkeit, wird man hier nicht das Haus finden, wo man hin will. bei den Kommerziellen ist ja auch nicht jede Nummer drin, sondern nur einige pro Straße und man wählt dann die nächstgelegene aus. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Henning Scholland o...@aighes.de wrote: Eine Sinnvolle Lösung wäre, wenn er den Nutzer nur selber suchen lässt, wenn er keine Hausnummer findet. Hm vielleicht würde es helfen wenn man ein tool baut, das Hausnummern POI aus OSM Daten erzeugt. Auch wieder so ein Beispiel von parsercode, den sich sonst jeder selbst zusammenfrickelt. Die wenigsten Hausnummern liegen ja direkt als POI vor sondern sind an Gebäude drangeklebt oder liegen gar nur als interpolierte Nummer vor. Man muss mindestens zwei Dinge tun: * Bestimmung des Mittelpunktes von Gebäuden - 1*POI * Ausführen der Interpolation und Ermittlung interpolierter Punkte - n*POI Wenn zur Nummer auch noch der Straßenname ermittelt werden soll wirds aufwendig, denn dann muß man mit Hilfe eienr Geometrieoperation die nächstgelegene Straße ermitteln. Das kann man zwar z.B. mit PostGIS einfach machen aber das ist Rechenaufwendig. @Jochen: Wäre es aufwendig eine solche Liste als Nebenprodukt des OSM Inspektorlaufs z.B. als Shapefile zu erzeugen? Gruss Sven -- Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG) umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. (BVerfG, 1BvR 370/07) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Dimitri Junker schrieb: ich hab jetzt nicht alles gelesen, aber nur mal wo es so bei mir hapert: Ich programmiere bisher C++ mit VC unter Windows. Ich würde gerne mal was anderes anfangen, z.B. Java Und warum eine sterbende Sprache probieren? *g* Du könntest eine Web-Applikation probieren, so ganz in HTML+CSS+JavaScript. Ich wäre sehr glücklich, wenn es eine Anwendung gibt, die ähnlich wie Mappero (gibt es zumindest für das N900) funktioniert, aber eine Web-App ist. Mit OpenLayers usw. und den Geolocation-Schnittstellen in Browsern sollte es die nötigen Teile geben, auf die man aufbauen kann. Nur programmieren müsste es noch jemand... Robert Kaiser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Am 12.10.2011 12:00, schrieb Sven Geggus: Henning Schollando...@aighes.de wrote: Eine Sinnvolle Lösung wäre, wenn er den Nutzer nur selber suchen lässt, wenn er keine Hausnummer findet. Die wenigsten Hausnummern liegen ja direkt als POI vor sondern sind an Gebäude drangeklebt oder liegen gar nur als interpolierte Nummer vor. Man muss mindestens zwei Dinge tun: * Bestimmung des Mittelpunktes von Gebäuden - 1*POI mkgmap hat vor ein paar Tagen die Funktion, die aus Flächen einen POI erzeugt renoviert. U.a. wurde eingebaut, dass im Weg des Polygons einen Node mit dem Tag building=entrance sucht und dann dort den POI setzt. Das halte ich für einen sehr sinnvollen Schritt. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
On 12.10.2011 10:00, Nils Faerber wrote: Am 12.10.2011 09:28, schrieb Sven Geggus: Tim Teulingst...@framstag.com wrote: Es hat zwar Überlegungen gegeben, libosmscout für das Map-Rendering in Monav zu integrieren, dies ist aber noch nicht geschehen. Der aktuell verwendete Renderer ist ein anderer. Von den Screenshots her ist meinem persönlichen Empfinden nach libosmscout schicker, aber so etwas ist immer Geschmackssache. Als ich Monav das letzte mal gesehen habe konnte der Renderer noch keine Straßennamen anzeigen. Geht das inzwischen? Ich habe mir gestern mal Monav 0.3 auf dem N900 installiert und die Deutschland Karte (4GB) dazu. Also das ist schon gar nicht schlecht! Die Kartendarstellung ist ganz hübsch, aber ohne Straßennamen. Die wichtigsten Einstellungen kann man im GUI machen (im Gegensatz bspw. zu Navit). Die Karte kann in der Bewegungsrichtung ausgerichtet werden. Der Hammer ist das Routing! Zum einen ist die Auswahl des Routingziels mal endlich sinnvoll an die Gegebenheiten von OSM angepaßt: Man wählt Stadt und Straßennamen - das ist etwas, was in OSM ja wirklich hinreichend gut vorhanden ist. Mit Hausnummern haben wir in OSM noch so unser Problem und Monav löst das recht elegant: Bei der Zielauswahl wird nach Eingabe von Stadt und Straßenname ein Kartenausschnitt mit der Straße gezeigt und man kann dann einfach einen Punkt auf der Straße auswählen (anclicken) wo man hin will. Das finde ich einen gelungenen Kompromiß! Die Routenberechnung anschließend dauert gefühlt 0,0 Sekunden - das ist der Hammer! Ich weiß nicht wie die das machen, aber es ist unglaublich schnell. Von dem was ich bisher gesehen habe, ist auch die ausgewählte Strecke halbwegs sinnvoll. Es ist allerdings in dieser Form noch nicht wirklich gut als Fahrzeug Navi verwendbar, da die Fahrtanweisungen nur in einer Art Statusbar klein unter der Kartendarstellung angezeigt werden - aber das ist wirklich Kosmetik. Wenn man einen Beifahrer hat, kann man dem das sicherlich in die Hand drücken und ihn/sie die Anweisungen geben lassen ;) Also suma sumarum: Monav auf mobilem Gerät (V0.3 auf N900) ist schon ein ganz schön starkes Stück! Gruss Sven Viele Grüße nils Kann mir jemand sagen wie man in MoNav das Vector Rendering an bekommt? Gruß Tobi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Und warum eine sterbende Sprache probieren? *g* Was Java stirbt auch schon? Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
On Mon, Oct 10, 2011 at 07:11:28PM -0600, Kai Krueger wrote: Nun kann man aber lange darueber philosophieren was moegliche Gruende sind das nicht mehr Entwickler sich an diesen Projekten beteiligen, vielleicht einfacher ist es aber einfach euch zu fragen: Was wuerde euch motivieren patches zu schreiben? Was euch den Einstieg erleichtern? Wo liegen derzeit die groessten Huerden um sich zu beteiligen? Gibt es Dinge die das Leben einem erleichtern wuerde? Was wuerde diejenigen die bereits viele Patches geschrieben haben helfen noch mehr patches zu submitten? Wenn ihr zu diesen Themen Ideen, Anregungen, Vorschlaege oder Kommentare habt, schreibt sie hier nieder und ich werde sie dann in die EWG einbringen um zu sehen was man davon umsetzen kann. Developer-Meetings würden sicher helfen. Hier und dort reden Leute in Deutschland seit Monaten, dass man sowas mal wieder machen sollte. Nimmt nur keiner in die Hand. Dabei haben wir mit dem Linuxhotel ne gute Location und beim FOSSGIS könnte man wegen Geldern anfragen. Kai: Wäre das nicht eine Aufgabe für Dich? :-) Was m.E. auch fehlt sind mehr Libraries und andere Legobausteine. Viel zu viele Leute fangen immer wieder bei Null an. Die meisten Leute wissen auch garnicht, was für tolle Tools es alles schon gibt. Hier hilft besseres promoten bestehender Tools. Z.B. auch auf einem Dev-Meeting. Größtes Problem sind aber die schieren Datenmengen. Es gibt einfach nicht viele Leute, die a) die Rechnerresourcen haben und b) die Kenntnisse, wie man effizient mit so großen Datenmengen, die sich ständig ändern, arbeitet. Daher werden häufig nur Spielprobleme gelöst, das bringt uns aber nicht so recht vorran. Eine Lösung habe ich dafür nicht. Um mit den Rechner-Ressourcen zu helfen, haben wir ja den dev-Server. Aber der platzt aus allen Nähten und bräuchte mehr Admin-Ressourcen, um ihn effektiver zu nutzen bzw. weitere Server zu organisieren und in Betrieb zu nehmen. Letztlich ist aber einfach so: Sowohl das Arbeiten mit OSM-Daten generell als auch speziell die Software, die im Zentrum von OSM eingesetzt wird (also die Datenbank, Rails-Port, Renderer) ist so komplex, dass man da nur schwer reinkommt und nur schwer die nötige Zeit aufbringen kann, daran wirklich effektiv zu arbeiten. Ich persönlich würde gerne 100% meiner Zeit an irgendwelchen Open Source OSM-Projekten arbeiten. Aber solang keiner dafür zahlt, geht das halt nicht. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo! Ausnahmeweise mal ein TOFU, da der Originaltext nicht weiter zu kommentieren ist. Ich habe zwei Softwaretechnische Anliegen, die im Rahmen von OSM sicherlich auch sehr gut aufgehoben wären und IMHO besser als bisher organisiert werden könnten/müßten: 1. Effiziente lokale Datenspeicherung und für eine effiziente und schnelle lokale Abfrage. Damit meine ich einen allgemeinen Software(-stack) der es ermöglicht, möglichst effizient auf eine möglichst effizient gespeicherte lokale Datenbasis zuzugreifen. Die Installation von PostgreSQL+PostGIS ist nicht sonderlich universell oder effizient - sowohl PostGreSQL als auch die entstehende Datenbank ist zu resourcenhungrig. Für eine Tile-Rendering Anwendung auf einem Server ist das kein Problem, aber für einen kompakten, womöglich mobilen, Client schon. Es gibt dazu diverse Ansätze in diversen Projekten, doch alle entweder sehr speziell oder noch nicht sonderlich ausgereift (Spatialite, Navit, GOSmore etc.). Es wäre sehr nützlich, wenn es hier eine konzierte Aktion von Seiten OSM gäbe, die dann wiederum als eine Art OSM quasi standard API von Programmen wie Navit etc. benutzt werden könnte. 2. Effizienter und state-of-the-art lokaler Map Renderer. Auch in Zeiten von schnellem mobilem Internet ist es sehr oft nötig, Kartendaten dennoch lokal zu rendern - sei es, weil gerade keine Verbindung zum Download von Tiles besteht oder weil eine bestimmte Ansicht, die nicht als Tiles fertig existiert, dargestellt werden soll. Das ganze ist natürlich etwas schwierig allgemein zu halten, da die Zielplattformen nicht genau klar sind und man mit Rendering schnell im Bereich GUI ist. Es gibt da auch ein paar nette Ansätze, aber alle mit Haken und Ösen. Ein guter GUI-Subset könnte vielleicht mit Cairo zu erzielen sein. Warum das Ganze? Ich sehe zur Zeit, daß wir zwar mit OSM eine geniale Datenbasis haben, aber einen großen Teil der möglichen Anwendungen damit nicht abdecken können, nämlich den mobilen Bereich. Alleine das es bis heute noch keine sinnvolle Navi Software auf Basis von OSM gibt, zeigt meiner Meinung nach schon die ganze Misere. Und das beginnt, denke ich, mit den Grundlagen, wie den oben beschriebenen. Ich arbeite im mobilen Linux Bereich und was ich mir bspw. wünschen würde, wäre eben eine effiziente und kompakte lokale OSM Datenbank die ich in mein mobiles Gerät packen kann (und dort nur in etwa soviel Speicher belegt, wie dies kommerzielle Navis tun). Oben drauf dann im ersten Schritt ein simples GUI, was die Kartendaten darstellt und den oben beschriebenen Renderer dazu verwendet. Der eigene lokale Renderer erlaubt dann auch Spielereien wie einstellbaren Detailgrad, Ausrichtung der Karte nach Bewegungsrichtung (mit korrekter Beschriftungsausrichtung), die typische 3D Ansicht etc. was alles mit Tile-Downloads nur schwer bis gar nicht möglich wäre. Ist das geschafft, ist der Weg zu einer Navi Software nicht mehr weit. Und da wir die Grundlagen (Datenbank, Renderer) allgemein gehalten haben, könnte es dann von diesen Navi-Softwares dann auch schnell und einfach eine ganze Reihe geben - wie sagt man auf Neudeutsch, das heavy lifting ist ja dann schon unten drunter gelöst. Ggf. könnte man zu diesem OSM Client Framework (so könnte man es vielleicht nennen) auch noch eine Routing-Komponente hinzufügen - dann wäre es wirklich nur noch ein Anflanschen eines GUIs und wir hätten sehr schnell OSM Navi Software für Maemo, MeeGo, Tizen, Bada (?), Android, WebOS und natürlich auch für normales Linux mit KDE/GNOME/XFCE/etc. Und das ganze auf einer Basis, die dann gemeinsam weiter entwickelt und verbessert werden kann, sodaß deren Verbesserungen gleich allen angeschlossenen Applikationen zu Gute kommt. Soweit mein Traum... :) Oh - sollte soetwas wider Erwarten doch bereits existieren, und ich habe mich danach schon wund gegoogled, nehme ich sachdienliche Hinweise sehr gerne entgegen! Aus lauter Verzweiflung habe ich mir jetzt schon ein Garmin Nüvi in der Bucht geschossen, damit ich wenigstens ansatzweise OSM Karten für Navigation verwenden kann, aber das kann ja echt nicht die Lösung sein... Viele Grüße nils Am 11.10.2011 03:11, schrieb Kai Krueger: Hallo allerseits, Openstreetmap ist natuerlich vorwiegend ein mapping Projekt, aber die Software darum herum ist schon auch irgendwie wichtig, unter anderem um OpenStreetMap.org am laufen zu halten, das Leben der Mapper durch bessere Editoren und QA tools zu erleichtern oder einfach um aus einem Haufen Rohdaten nuetzliche Sachen zu basteln. Im Laufe der letzen Jahre ist bereits ein ziemlich beeindruckendes Software Oekosystem um OSM entstanden, aber dennoch gibt es viele gute und wichtige Ideen, die bislang nicht umgesetzt wurden, oder nuetzliche Programme die nicht mehr maintained werden da es oft nicht genug Entwickler gibt. Die Frage ist nun was kann man machen um mehr Entwickler fuer OpenStreetMap zu begeistern und die Entwickler unter uns in der Community davon zu ueberzeugen sich in
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo Nils, On Tue, 2011-10-11 at 10:27 +0200, Nils Faerber wrote: 1. Effiziente lokale Datenspeicherung und für eine effiziente und schnelle lokale Abfrage. [...] 2. Effizienter und state-of-the-art lokaler Map Renderer. [...] Oh - sollte soetwas wider Erwarten doch bereits existieren, und ich habe mich danach schon wund gegoogled, nehme ich sachdienliche Hinweise sehr gerne entgegen! Aus lauter Verzweiflung habe ich mir jetzt schon ein Garmin Nüvi in der Bucht geschossen, damit ich wenigstens ansatzweise OSM Karten für Navigation verwenden kann, aber das kann ja echt nicht die Lösung sein... Hast du dir libosmscout [1] schon angesehen? Eingesetzt wird das z.B. schon in MoNav [2], zusammen mit dem extrem schnellen MoNav routing daemon. [1] https://wiki.openstreetmap.org/wiki/Libosmscout [2] http://monav.openstreetmap.de/ Viele Grüße, Mitja ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 11. Oktober 2011 10:27 schrieb Nils Faerber nils.faer...@kernelconcepts.de: 1. Effiziente lokale Datenspeicherung und für eine effiziente und schnelle lokale Abfrage ... effiziente und kompakte lokale OSM Datenbank die ich in mein mobiles Gerät packen kann (und dort nur in etwa soviel Speicher belegt, wie dies kommerzielle Navis tun). Oben drauf dann im ersten Schritt ein simples GUI, was die Kartendaten darstellt und den oben beschriebenen Renderer dazu verwendet. Der eigene lokale Renderer erlaubt dann auch Spielereien wie einstellbaren Detailgrad, Ausrichtung der Karte nach Bewegungsrichtung (mit korrekter Beschriftungsausrichtung), die typische 3D Ansicht etc. was alles mit Tile-Downloads nur schwer bis gar nicht möglich wäre. macht das nicht Navit bereits alles? War am Wochenende auf der italienischen OSM-Konferenz in Padua und auf dem Weg dahin haben wir uns komplett von Navit auf einem Openmoko leiten lassen (inkl. synthetischer Sprachausgabe). Das Stylesheet wurde für den Bildschirm des Openmoko optimiert und ich fand das ganze schon quasi alltagstauglich. Was man sicher noch verbessern kann ist das Interface (und auch die Ansagen), eines der Hauptprobleme sind aber die Daten: fehlende Hausnummern sind bei sehr langen Straßen wirklich ein Problem. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo, ich bin mir nicht sicher ob VM's ein sinnvolles Mittel sind. Meines Erachtens wäre es besser, die Installation der Toolchain, die man für eine Sache braucht zu erleichtern. Ähnlich wie es gerade mit den TileServer für Ubuntu gemacht wird. Wenn es so etwas gibt, kann jeder, der meint das in einer VM machen zu wollen, sich eine VM einrichten und darin die Pakete installieren. Ein Problem sehe ich darin, dass Anwender nicht wissen welche Software es gibt und welche Software sie brauchen. Hier wäre irgendeine Übersichtsseite sinnvoll, auf der man eine Zuordnung von Das will ich machen zu diese Tools brauch ich dafür und da findest du die Hilfe zu den Tools Jochens Vorschlag mit den Libraries finde ich auch sehr sinnvoll. Für größere Softwareprojekte die OSM benötigt könnte man auch Preise ausloben und so evtl. auch neue Anreize schaffen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo, On 10/11/2011 11:39 AM, Henning Scholland wrote: Ein Problem sehe ich darin, dass Anwender nicht wissen welche Software es gibt und welche Software sie brauchen. Hier wäre irgendeine Übersichtsseite sinnvoll, auf der man eine Zuordnung von Das will ich machen zu diese Tools brauch ich dafür und da findest du die Hilfe zu den Tools Wobei Kai natuerlich ausdruecklich gefragt hatte, wie man das Mitmachen der Leute an den Kernkomponenten erleichtern koennte, und nicht, wie man der Welt den Einsatz von OSM durch praktischere Tools erleichtern koennte. Beides ist zwar wichtig, aber fuer letzteres (also den leichteren Einsatz von OSM) gibt es durchaus mehr externe Anreize - saemtliche mobile Software zum Beispiel ist allein aus der Community heraus entstanden und nicht, weil sich zentral jemand hingesetzt hat und gesagt wir muessen mal was fuer Anroid tun. Mehr Helfer fuer die internen Komponenten ist hingegen eine schwierigere Sache - damit kann man als Programmierer halt auch nicht so viel Ruhm ernten wie mit einer coolen neuen mobilen App oder einer neuen Webseite oder sowas. Das ist auch der Grund, warum sich die OSMF da Gedanken macht, wie man den Leuten das versuessen koennte. Für größere Softwareprojekte die OSM benötigt könnte man auch Preise ausloben und so evtl. auch neue Anreize schaffen. Ganz schwieriges Thema - was motiviert Leute, bei Open Source mitzumachen? Geld oder Sachpreise sind problematisch, denn wenn erstmal einer bezahlt wird, um am Rails Port zu arbeiten, wer will dann noch kostenlos mitmachen? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 11.10.2011 11:04, schrieb Mitja Kleider: Hallo Nils, Moin! On Tue, 2011-10-11 at 10:27 +0200, Nils Faerber wrote: 1. Effiziente lokale Datenspeicherung und für eine effiziente und schnelle lokale Abfrage. [...] 2. Effizienter und state-of-the-art lokaler Map Renderer. [...] Oh - sollte soetwas wider Erwarten doch bereits existieren, und ich habe mich danach schon wund gegoogled, nehme ich sachdienliche Hinweise sehr gerne entgegen! Aus lauter Verzweiflung habe ich mir jetzt schon ein Garmin Nüvi in der Bucht geschossen, damit ich wenigstens ansatzweise OSM Karten für Navigation verwenden kann, aber das kann ja echt nicht die Lösung sein... Hast du dir libosmscout [1] schon angesehen? Eingesetzt wird das z.B. schon in MoNav [2], zusammen mit dem extrem schnellen MoNav routing daemon. Recht sicher, aber mal sehen, was war das nochmal... [1] https://wiki.openstreetmap.org/wiki/Libosmscout [2] http://monav.openstreetmap.de/ Ah, ja, richtig, hatte ich! Das ist in der Tat einer der vielversprechenderen Ansätze, gefiel mir ganz gut, war nur etwas frickelig ans Laufen zu bekommen (also außerhalb von Monav. Teile davon könnte man sicherlich extrahieren und für den von mir skizzierten Zweck verwenden - oder vielleicht gleich das ganze OSMScout? Dann wäre es nur noch eine Frage, die Software zu verallgemeinern, damit sie breit eingesetzt werden kann. Also gute Trennung von Renderer, Kartendaten und Routing, damit ggf. auch mal eine der Komponenten gegen eine andere getauscht werden könnte. Das letzte mal als ich mir das angesehen hatte, war der Renderer noch stark eingeschränkt, d.h. es gab kein richtiges sinnvolles API, um von einer Applikation aus den Renderer als Widget einzubinden und zu beeinflussen (Center-Koordinate setzen, Rotation etc.). Alles machbar, keine Frage! Müßte man nur den libosmscout Author mal fragen und ggf. zusammenarbeiten. Aber vielen Dank für den Tip da nochmal zu gucken! Die Screenshots von Monav sehen verflixt gut aus, ich bin begeistert! Da hat sich doch Einiges getan, seitdem ich das letzte mal geschaut hatte. Werde ich mir gleich auf einem N900 instalieren *freu* :) Doch nach wie vor denke ich, daß die OSM Community auch Infrastruktur für Entwickler fördern sollte - also eben Bausteine fördern, die von Applikationsentwicklern einfach benutzt werden können, um interessante Applikationen zu (er-)schaffen. Libosmscout ist da schon sehr weit vorne! Viele Grüße, Mitja Viele Grüße nils -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hi, Ich das Problem ist dass an vielen stellen Viele Suppen gekocht werden und oft viel Energie in Sachen gesteckt wird die anderes leichter oder besser zu lösen wären. Eine Idee (wenn noch nicht vorhanden) wäre eine Top 10/20/50 Liste. In der die meist gewünschten Features/Bugfixes verzeichnet sind (und in der man Sachen Rauf oder Rutner wählen kann) Über Links ließen sich dann Ideen für Technische Lösungen Sammeln und Kompetenzen bündeln. (damit nicht jeder an einer anderen Stelle eine eigene Suppe beginnt) Wie werden den ATM Bugs getrackt? Gruß Tobi On 11.10.2011 03:11, Kai Krueger wrote: Hallo allerseits, Openstreetmap ist natuerlich vorwiegend ein mapping Projekt, aber die Software darum herum ist schon auch irgendwie wichtig, unter anderem um OpenStreetMap.org am laufen zu halten, das Leben der Mapper durch bessere Editoren und QA tools zu erleichtern oder einfach um aus einem Haufen Rohdaten nuetzliche Sachen zu basteln. Im Laufe der letzen Jahre ist bereits ein ziemlich beeindruckendes Software Oekosystem um OSM entstanden, aber dennoch gibt es viele gute und wichtige Ideen, die bislang nicht umgesetzt wurden, oder nuetzliche Programme die nicht mehr maintained werden da es oft nicht genug Entwickler gibt. Die Frage ist nun was kann man machen um mehr Entwickler fuer OpenStreetMap zu begeistern und die Entwickler unter uns in der Community davon zu ueberzeugen sich in Projekte einzubeziehen und patches zu schreiben z.B. um lang vermisste Funktionen zu ergaenzen oder Bugs zu beheben. Um dieser Frage nachzugehen haben sich ein paar Devs vor ein paar Wochen unter dem Schirm der Engineering Working Group (EWG) zusammen getan um zu schauen ob wir etwas tun koennen um den Einstieg in die OpenStreetMap Entwicklung zu erleichtern und mehr Leute dafuer begeistern koennen. Vorwiegend ist das Ziel mehr Leute fuer die Core Projekte zu begeistern wie z.B. Potlatch, den rails_port, xapi, nominatim, cgi_map oder anderen Projekten die derzeit auf den OSMF servern laufen, aber Dinge die die generelle Entwicklung von OSM basierter Software verbessern oder erleichtern koennen natuerlich auch Thema sein. Ein paar der Ueberlegungen die bislang angestellt wurden sind z.B. die Installationsdokumentation des rails_port zu verbessern, Virtuelle Machines mit allen noetigen Entwicklungstools und Softwaredependencies anzubieten, die Verwendung des dev-servers zu verbessern, oder hack weekends zu organisieren um Leute in Person beim Einstig zu helfen. Nun kann man aber lange darueber philosophieren was moegliche Gruende sind das nicht mehr Entwickler sich an diesen Projekten beteiligen, vielleicht einfacher ist es aber einfach euch zu fragen: Was wuerde euch motivieren patches zu schreiben? Was euch den Einstieg erleichtern? Wo liegen derzeit die groessten Huerden um sich zu beteiligen? Gibt es Dinge die das Leben einem erleichtern wuerde? Was wuerde diejenigen die bereits viele Patches geschrieben haben helfen noch mehr patches zu submitten? Wenn ihr zu diesen Themen Ideen, Anregungen, Vorschlaege oder Kommentare habt, schreibt sie hier nieder und ich werde sie dann in die EWG einbringen um zu sehen was man davon umsetzen kann. Natuerlich sind auch alle herzlich Willkomen sich direkt an der Engineering Working Group ( http://www.osmfoundation.org/wiki/Engineering_Working_Group ) selbst zu beteiligen, denn auch dort gilt das uebliche do-ocracy Prinzip. Sie trifft sich jeden Montag um 17:00 GMT (19:00 deutsche Sommerzeit) auf IRC unter #osm-ewg (Internet Relay Chat, auf dem OFTC server). Es ist insgesamt sehr informell. Logs der bisherigen Meetings gibt es unter http://www.osmfoundation.org/wiki/Working_Group_Minutes#Engineering_Working_Group Kai ___ 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] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo Nils. Ich glaube nicht, dass eine solche API sinnvoll machbar ist. Im Gegenteil würde eine solche API die Problematik des Preprocessings erneut verstecken. Eine Routing-Anwendung braucht ein anderes Datenformat als ein Renderer und wieder was anderes als eine lokale Restaurantsuche. Sinnvollerweise wird die Restaurantsuche außerdem nur ein kleines Subset der Datenbank überhaupt haben wollen, andere Anwendungen brauchen andere Teilmengen. Der Zugriff ist komplett unterschiedlich: Suche ich in erster Linie nach Namen (Lokalsuche), nach Topologie (Router) oder nach geografischer Position ohne Berücksichtigung der Topologie? Die Inhalte sind komplett unterschiedlich: Nur OSM-Editoren werden die komplette Datenbank mit den Original-Tags brauchen, alle anderen werden das vorverarbeiten. Wozu highway=residential als Tag speichern, wenn nur 8 wohldefinierte Tags gebraucht werden? Insofern bin ich mir nicht sicher, ob das so sinnvoll und machbar ist, was Du vorschlägst. Gruß Peter Am 11.10.2011 10:27, schrieb Nils Faerber: Hallo! Ausnahmeweise mal ein TOFU, da der Originaltext nicht weiter zu kommentieren ist. Ich habe zwei Softwaretechnische Anliegen, die im Rahmen von OSM sicherlich auch sehr gut aufgehoben wären und IMHO besser als bisher organisiert werden könnten/müßten: 1. Effiziente lokale Datenspeicherung und für eine effiziente und schnelle lokale Abfrage. Damit meine ich einen allgemeinen Software(-stack) der es ermöglicht, möglichst effizient auf eine möglichst effizient gespeicherte lokale Datenbasis zuzugreifen. Die Installation von PostgreSQL+PostGIS ist nicht sonderlich universell oder effizient - sowohl PostGreSQL als auch die entstehende Datenbank ist zu resourcenhungrig. Für eine Tile-Rendering Anwendung auf einem Server ist das kein Problem, aber für einen kompakten, womöglich mobilen, Client schon. Es gibt dazu diverse Ansätze in diversen Projekten, doch alle entweder sehr speziell oder noch nicht sonderlich ausgereift (Spatialite, Navit, GOSmore etc.). Es wäre sehr nützlich, wenn es hier eine konzierte Aktion von Seiten OSM gäbe, die dann wiederum als eine Art OSM quasi standard API von Programmen wie Navit etc. benutzt werden könnte. 2. Effizienter und state-of-the-art lokaler Map Renderer. Auch in Zeiten von schnellem mobilem Internet ist es sehr oft nötig, Kartendaten dennoch lokal zu rendern - sei es, weil gerade keine Verbindung zum Download von Tiles besteht oder weil eine bestimmte Ansicht, die nicht als Tiles fertig existiert, dargestellt werden soll. Das ganze ist natürlich etwas schwierig allgemein zu halten, da die Zielplattformen nicht genau klar sind und man mit Rendering schnell im Bereich GUI ist. Es gibt da auch ein paar nette Ansätze, aber alle mit Haken und Ösen. Ein guter GUI-Subset könnte vielleicht mit Cairo zu erzielen sein. Warum das Ganze? Ich sehe zur Zeit, daß wir zwar mit OSM eine geniale Datenbasis haben, aber einen großen Teil der möglichen Anwendungen damit nicht abdecken können, nämlich den mobilen Bereich. Alleine das es bis heute noch keine sinnvolle Navi Software auf Basis von OSM gibt, zeigt meiner Meinung nach schon die ganze Misere. Und das beginnt, denke ich, mit den Grundlagen, wie den oben beschriebenen. Ich arbeite im mobilen Linux Bereich und was ich mir bspw. wünschen würde, wäre eben eine effiziente und kompakte lokale OSM Datenbank die ich in mein mobiles Gerät packen kann (und dort nur in etwa soviel Speicher belegt, wie dies kommerzielle Navis tun). Oben drauf dann im ersten Schritt ein simples GUI, was die Kartendaten darstellt und den oben beschriebenen Renderer dazu verwendet. Der eigene lokale Renderer erlaubt dann auch Spielereien wie einstellbaren Detailgrad, Ausrichtung der Karte nach Bewegungsrichtung (mit korrekter Beschriftungsausrichtung), die typische 3D Ansicht etc. was alles mit Tile-Downloads nur schwer bis gar nicht möglich wäre. Ist das geschafft, ist der Weg zu einer Navi Software nicht mehr weit. Und da wir die Grundlagen (Datenbank, Renderer) allgemein gehalten haben, könnte es dann von diesen Navi-Softwares dann auch schnell und einfach eine ganze Reihe geben - wie sagt man auf Neudeutsch, das heavy lifting ist ja dann schon unten drunter gelöst. Ggf. könnte man zu diesem OSM Client Framework (so könnte man es vielleicht nennen) auch noch eine Routing-Komponente hinzufügen - dann wäre es wirklich nur noch ein Anflanschen eines GUIs und wir hätten sehr schnell OSM Navi Software für Maemo, MeeGo, Tizen, Bada (?), Android, WebOS und natürlich auch für normales Linux mit KDE/GNOME/XFCE/etc. Und das ganze auf einer Basis, die dann gemeinsam weiter entwickelt und verbessert werden kann, sodaß deren Verbesserungen gleich allen angeschlossenen Applikationen zu Gute kommt. Soweit mein Traum... :) Oh - sollte soetwas wider Erwarten doch bereits existieren, und ich habe mich danach schon wund gegoogled, nehme ich sachdienliche Hinweise sehr gerne entgegen! Aus lauter Verzweiflung habe ich mir jetzt
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 11.10.2011 11:32, schrieb Martin Koppenhoefer: Am 11. Oktober 2011 10:27 schrieb Nils Faerber nils.faer...@kernelconcepts.de: 1. Effiziente lokale Datenspeicherung und für eine effiziente und schnelle lokale Abfrage ... effiziente und kompakte lokale OSM Datenbank die ich in mein mobiles Gerät packen kann (und dort nur in etwa soviel Speicher belegt, wie dies kommerzielle Navis tun). Oben drauf dann im ersten Schritt ein simples GUI, was die Kartendaten darstellt und den oben beschriebenen Renderer dazu verwendet. Der eigene lokale Renderer erlaubt dann auch Spielereien wie einstellbaren Detailgrad, Ausrichtung der Karte nach Bewegungsrichtung (mit korrekter Beschriftungsausrichtung), die typische 3D Ansicht etc. was alles mit Tile-Downloads nur schwer bis gar nicht möglich wäre. macht das nicht Navit bereits alles? War am Wochenende auf der italienischen OSM-Konferenz in Padua und auf dem Weg dahin haben wir uns komplett von Navit auf einem Openmoko leiten lassen (inkl. synthetischer Sprachausgabe). Das Stylesheet wurde für den Bildschirm des Openmoko optimiert und ich fand das ganze schon quasi alltagstauglich. Was man sicher noch verbessern kann ist das Interface (und auch die Ansagen), eines der Hauptprobleme sind aber die Daten: fehlende Hausnummern sind bei sehr langen Straßen wirklich ein Problem. Navit - jein. Im Prinzip macht es davon schon eine Menge, aber eben nur in und für Navit. Möchte man den Renderer von Navit verwenden, der offengestanden nicht so schön ist, dann kann man den nicht als Widget einzeln extrahieren. Auch die Datenhaltung ist Navit spezifisch und nicht wiederverwendbar. Navit ist schon toll! Das soll keine Kritik sein. Aber es hilft einem anderen Entwickler eben nur wenig. Ich finde es extrem schade, wenn die gleichen Probleme von jedem neuen Projekt immer wieder auf's Neue selbst versucht werden zu lösen, anstatt zusammen an einer Komponente die allen hilft zu entwickeln. Die OSM Community könnte hier für solche Entwickler ein gutes Forum bieten, sich abzustimmen und zu koordinieren. Also nur damit da keine Mißverständnisse aufkommen - von mir aus kann auch jeder gerne aus welchen Gründen auch immer seine eigene Suppe kochen. Bei vielen jetzt existierenden Projekten war es nur einfach so, daß es immer aufs Neue gemacht wurde, weil die generischen Komponenten schlicht gefehlt haben. Navit war so ziemlich die erste Lösung in dem Bereich, also mußten die alles selbst neu machen. Doch der Code von Navit ist praktisch nicht wiederverwertbar - was auch nicht das Ziel der Autoren war, daher auch keinerlei Vorwurf! Andere Bilbliotheken sind mir nicht bekannt, außer libchamplain, was aber wieder nur Tile basiert ist und eben das libosmscout (siehe andere Mails in diesem Thread). Gosmore ist wieder so eine all-in-one Sache, nicht in Komponenten, mit eigener Datenhaltung etc. Nett, aber auch kaum wiedervertbar. Gruß Martin Viele Grüße nils -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 11.10.2011 12:08, schrieb Peter Wendorff: Hallo Nils. Moin! Ich glaube nicht, dass eine solche API sinnvoll machbar ist. Im Gegenteil würde eine solche API die Problematik des Preprocessings erneut verstecken. Eine Routing-Anwendung braucht ein anderes Datenformat als ein Renderer und wieder was anderes als eine lokale Restaurantsuche. Sinnvollerweise wird die Restaurantsuche außerdem nur ein kleines Subset der Datenbank überhaupt haben wollen, andere Anwendungen brauchen andere Teilmengen. Der Zugriff ist komplett unterschiedlich: Suche ich in erster Linie nach Namen (Lokalsuche), nach Topologie (Router) oder nach geografischer Position ohne Berücksichtigung der Topologie? Die Inhalte sind komplett unterschiedlich: Nur OSM-Editoren werden die komplette Datenbank mit den Original-Tags brauchen, alle anderen werden das vorverarbeiten. Wozu highway=residential als Tag speichern, wenn nur 8 wohldefinierte Tags gebraucht werden? Insofern bin ich mir nicht sicher, ob das so sinnvoll und machbar ist, was Du vorschlägst. Tsm tsm tsm... Das stimmt, bricht aber die Idee noch nicht ganz - vielleicht drücke ich mich da undeutlich aus bzw. sehe das nur von meinem aktuellen Wunsch nach einer plattformübergreifenden Navi Software für OSM gefärbt ;) Wenn es diese stark unterschiedlichen Teile braucht, dann müssen das eben, da wo es nicht mehr unter einen Hut zu bekommen ist, getrennte Module werden. Ich kann mir aber dennoch vorstellen, daß viel miteinander vereinbar ist. So wäre bspw. die POI Sache sicherlich auch mit dem einen Datenbank-Modul abbildbar und man könnte in die Erzeugung der Datenbank aus dem OSM File Optionen einfließen lassen, sodaß bestimmte Informationen eben weggelassen oder stark vereinfacht werden. Letztlich basieren sehr viele Anwendungen ja doch auf einer 2D Suche in dem riesigen Datenbestand - egal ob nach POIs oder Ways für die Darstellung gesucht wird. Das Routing ist in der Tat etwas, wo man anders herangehen könnte - das wäre dann mal mit Experten für solche Routing-Algorithmen zu klären, was man da wiederverwenden oder neu machen müßte. In Spatialite ist das über recht komplexe Indize (AFAIK) gelöst, d.h. die Datenbank ist immernoch die gleiche Datenbank, es kommt nur ein komplexer Index dazu, der dann das Routing ermöglicht. Ich bin da leider auch kein Experte und habe auch leider keine Zeit es zu werden... doch naiv sehe ich da immernoch mehr Schnittmenge als disjunkte Teile. Gruß Peter Viele Grüße nils -- kernel concepts GbRTel: +49-271-771091-12 Sieghuetter Hauptweg 48 D-57072 Siegen Mob: +49-176-21024535 http://www.kernelconcepts.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 11.10.2011 11:54, schrieb Frederik Ramm: Hallo, On 10/11/2011 11:39 AM, Henning Scholland wrote: Ein Problem sehe ich darin, dass Anwender nicht wissen welche Software es gibt und welche Software sie brauchen. Hier wäre irgendeine Übersichtsseite sinnvoll, auf der man eine Zuordnung von Das will ich machen zu diese Tools brauch ich dafür und da findest du die Hilfe zu den Tools Wobei Kai natuerlich ausdruecklich gefragt hatte, wie man das Mitmachen der Leute an den Kernkomponenten erleichtern koennte, und nicht, wie man der Welt den Einsatz von OSM durch praktischere Tools erleichtern koennte. Beides ist zwar wichtig, aber fuer letzteres (also den leichteren Einsatz von OSM) gibt es durchaus mehr externe Anreize - saemtliche mobile Software zum Beispiel ist allein aus der Community heraus entstanden und nicht, weil sich zentral jemand hingesetzt hat und gesagt wir muessen mal was fuer Anroid tun. Mehr Helfer fuer die internen Komponenten ist hingegen eine schwierigere Sache - damit kann man als Programmierer halt auch nicht so viel Ruhm ernten wie mit einer coolen neuen mobilen App oder einer neuen Webseite oder sowas. Das ist auch der Grund, warum sich die OSMF da Gedanken macht, wie man den Leuten das versuessen koennte. Auf so etwas wollte ich hinaus. Wenn ich ein Projekt auf die Beine stelle, möchte ich doch das das hinterher auch genutzt wird und nicht nur irgendwo auf nem Server rum liegt. Mache ich vielen Menschen das Leben mit dem Projekt leichter, steigt auch meine Motivation Zeit oder Geld in mein Projekt zu stecken um es besser zu machen. Gleichzeitig bietet diese Übersicht natürlich auch eine Art schwarzes Brett, wo man als Entwickler sieht, welche Projekte es schon gibt und kann dann besser helfen den OSM-Parser zu verbessern/ erweitern als den x-ten OSM-Parser zuschreiben. Somit kann man Programmiererkapazitäten besser bündeln. Für größere Softwareprojekte die OSM benötigt könnte man auch Preise ausloben und so evtl. auch neue Anreize schaffen. Ganz schwieriges Thema - was motiviert Leute, bei Open Source mitzumachen? Geld oder Sachpreise sind problematisch, denn wenn erstmal einer bezahlt wird, um am Rails Port zu arbeiten, wer will dann noch kostenlos mitmachen? Sicherlich ist das bei OSS ein wenig problematisch. Bei dem Umgang mit Problemen mit OSM-Daten funktioniert es doch aber auch. Geofabrik bietet Hilfe als Dienstleister an und dennoch gibt es eine recht große Community, die eben auch Hilfestellung gibt. Ich sehe dies auch nicht als Lösung für jedes kleine Problem an. Eher für so Kaliber wie Umgang mit History-Extrakten. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Am 11. Oktober 2011 12:18 schrieb Nils Faerber nils.faer...@kernelconcepts.de: Andere Bilbliotheken sind mir nicht bekannt, außer libchamplain, was aber wieder nur Tile basiert ist und eben das libosmscout (siehe andere Mails in diesem Thread). Es gibt mapsforge für Android, welches Vektor-Rendering auf dem Device macht. Die Vorverarbeitung (Konvertierung ins eigene Bin-Format) erfolgt dabei durch eine JAVA-app (AFAIR). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo, Am Dienstag, 11. Oktober 2011 03:11:28 schrieb Kai Krueger: Hallo allerseits, [...] Was wuerde euch motivieren patches zu schreiben? Was euch den Einstieg erleichtern? Wo liegen derzeit die groessten Huerden um sich zu beteiligen? Gibt es Dinge die das Leben einem erleichtern wuerde? Was wuerde diejenigen die bereits viele Patches geschrieben haben helfen noch mehr patches zu submitten? Um mal was zu der eigentlichen Fragestellung zu schreiben: Es liegt an den zu hohen Hürden. Für Josm kann man Plugins schreiben. Dazu gibt es sicher auch eine Schnittstelle. Um die vernünftig zu finden, die Doku zu sichten, die zur Zeit gültige Variante zu finden und den ganzen Kram zu verstehen würde ich mal locker 1-2 Monate veranschlagen. Schön, wenn jemand die Zeit und Motivation hat, sich da durchzubeißen, ich habe das nicht. Wichtig ist eine einfach verständliche Doku mit Beispielen in aktueller Form. Etwas Einfaches zum Anfüttern und keine High-End-Lösungen nach dem Motto seht mal was ich damit kann. Als Beispiel kann ich die neue overpass xapi anführen. Da kann zwar auch noch einiges an der Doku verbessert werden, aber nach ein paar Fehlschlägen, die zum Glück verständliche Fehlermeldungen erzeugen, habe ich brauchbare Resultate erhalten, die nach ein paar Kunstgriffen dann auch von osmosis durchgenudelt wurden. (Vielleicht kann die aktuelle Version auch so mit den Daten umgehen(?), aber ich brauche halt eine ältere). Wichtig ist bei der Doku, immer gleich ein _ganz einfaches_ praktisches Beispiel mitzuziehen. Außerdem die Doku in möglicht allgemein verständlichem Englisch halten. Sicher kann man vieles elegant ausdrücken und sein Fachwissen zur Schau stellen. Aber wenn ich Leute erreichen und motivieren will, sollte nicht jeder Satz Leo-pflichtig sein. Mit einer deutschen Übersetzung der Kernbereiche erreicht man möglicherweise noch schneller weitere Freiwillige. Das gilt im Prinzip auch für die anderen Sprachen, aber die größte nicht englischsprachige aktive Community sitzt nun mal im deutschsprachigen Bereich. These: Jede Stunde, die aktive Entwickler nicht in die eigentliche Entwicklung, sondern in die gut verstänliche Dokumentation der Entwicklung stecken, bringt die Entwicklung im Ergebnis um 10 Stunden weiter. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
On 10/11/2011 03:35 PM, Wolfgang wrote: Es liegt an den zu hohen Hürden. Für Josm kann man Plugins schreiben. Dazu gibt es sicher auch eine Schnittstelle. Um die vernünftig zu finden, die Doku zu sichten, die zur Zeit gültige Variante zu finden und den ganzen Kram zu verstehen würde ich mal locker 1-2 Monate veranschlagen. Schön, wenn jemand die Zeit und Motivation hat, sich da durchzubeißen, ich habe das nicht. och, s schlimm ist es dann IMHO auch wieder nicht, mein DirectDownload plugin für auf osm hochgeladene GPX tracks hat eher so 2-3 Tage Teilzeit gedauert ... und das obwohl ich seit über 10 Jahren JAVA nur noch mit der Kneifzange angefasst habe wenn es sich überhaupt nicht mehr anders vermeiden lässt ... Wichtig ist eine einfach verständliche Doku mit Beispielen in aktueller Form. FULLACK ... denn geflucht und mich auf falsche Fährten locken lassen habe ich mich in der Zeit trotzdem reichlich ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo Wolfgang, These: Jede Stunde, die aktive Entwickler nicht in die eigentliche Entwicklung, sondern in die gut verstänliche Dokumentation der Entwicklung stecken, bringt die Entwicklung im Ergebnis um 10 Stunden weiter. Würde ich auch so einschätzen. Ich spende gern einen Teil meiner Zeit für die Bearbeitung von Doku. Vorausgesetzt ich verstehe worum es geht, bzw der Entwickler kann mir die vorformulierte Doku so erklären, dass ich daraus etwas allgemeinverständliches und hübsch formatiertes im de:Wiki machen kann. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
On 10/11/2011 03:11 AM, Kai Krueger wrote: Die Frage ist nun was kann man machen um mehr Entwickler fuer OpenStreetMap zu begeistern und die Entwickler unter uns in der Community davon zu ueberzeugen sich in Projekte einzubeziehen und patches zu schreiben z.B. um lang vermisste Funktionen zu ergaenzen oder Bugs zu beheben. nur mal ein zufällig rausgegriffener Punkt: bei vielen (unter-)Projekten im OSM SVN ist nicht klar wer Maintainer oder zumindest Ansprechpartner ist oder ob der Kram überhaupt noch maintained wird. Als ich zB letztes Jahr den .pbf Import für osm2pgsql gebaut hab war das eines der ganz großen Fragezeichen bei der Aktion ... Alles schön dokumentiert zu haben wäre natürlich fein, aber schnell herausfinden zu können wen man direkt fragen kann wäre oft auch schon eine Menge wert ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Wolfgang wolfg...@ivkasogis.de wrote: Wichtig ist eine einfach verständliche Doku mit Beispielen in aktueller Form. Das ist aber doch wirklich ein Standardproblem von freier Software. Ich kenne kaum freie Software bei der wirklich gute Doku dabei ist (Außnahmen wie z.B. exim bestätigen die Regel). Wenn man Glück hat gibt es ein passendes Buch in Papierform, das ein dritte geschrieben haben und das die Doku ersetzen kann. Oft haben diese dann das Problem, dass sie nicht merh den Status Quo sondern veraltete Versionen beschreiben. Bei OSM ist das eigentlich auch irgendwie so. Die Beste Doku ist das Buch von Jochen und Frederik, das leider inzwischen an vielen Stellen veraltet ist. Gruss Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Hallo, Am Dienstag, 11. Oktober 2011 17:34:30 schrieb Sven Geggus: Wolfgang wolfg...@ivkasogis.de wrote: Wichtig ist eine einfach verständliche Doku mit Beispielen in aktueller Form. Das ist aber doch wirklich ein Standardproblem von freier Software. Das bezweifel ich ja gar nicht. Aber die Frage war die nach den Gründen, warum es so wenige Entwickler gibt und dieses Problem, Standard hin oder her, ist einer der Hauptgründe, insbesondere wenn es um laufende Projekte geht. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Wolfgang schrieb am 11.10.2011 18:18: Hallo, Am Dienstag, 11. Oktober 2011 17:34:30 schrieb Sven Geggus: Wolfgang wolfg...@ivkasogis.de wrote: Wichtig ist eine einfach verständliche Doku mit Beispielen in aktueller Form. Das ist aber doch wirklich ein Standardproblem von freier Software. Das bezweifel ich ja gar nicht. Aber die Frage war die nach den Gründen, warum es so wenige Entwickler gibt und dieses Problem, Standard hin oder her, ist einer der Hauptgründe, insbesondere wenn es um laufende Projekte geht. Es macht einfach mehr Spaß Funktionen zu Programmieren, als diese zu dokumentieren. Wenn es ein Projekt in deiner Freizeit ist, hat man kein Chef im Nacken, der dich zur Doku zwingt. Also kümmert man sich lieber um die nächste tolle Funktion, welche interessanter als Doku schreiben ist. -- Grüße Holger Jeromin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo, On 10/11/2011 03:35 PM, Wolfgang wrote: Es liegt an den zu hohen Hürden. Für Josm kann man Plugins schreiben. Dazu gibt es sicher auch eine Schnittstelle. Um die vernünftig zu finden, die Doku zu sichten, die zur Zeit gültige Variante zu finden und den ganzen Kram zu verstehen würde ich mal locker 1-2 Monate veranschlagen. Schön, wenn jemand die Zeit und Motivation hat, sich da durchzubeißen, ich habe das nicht. Wichtig ist eine einfach verständliche Doku mit Beispielen in aktueller Form. Etwas Einfaches zum Anfüttern und keine High-End-Lösungen Ich denke, da reden wir wieder mal aneinander vorbei. Dass fuer den Anwender eines Dienstes, einer Bibliothek oder einer API diese gut dokumentiert sein muss, damit er darauf aufbauend seine Sache entwickeln kann, ist klar. Die Frage, die hier gestellt wurde, bezog sich weniger auf den Mangel an JOSM-Plugins - da herrscht mittlerweile ja eine ziemliche Flut! - oder auf ein Fehlen praktischer Applikationen, die auf XAPI/Overpass aufsetzen, sondern auf den Mangel an Entwicklern bei Kernkomponenten. Die Mitarbeit am Rails-Port ist nun mal nicht trivial, und ich zweifle daran, dass diejenigen, fuer die das Fehlen einer einfachen und verstaendlichen Doku mit Beispielen in aktueller Form eine Huerde ist, wirklich gute Arbeit am Rails-Port machen koennen. Das ist was anderes als im eigenen Kaemmerlein eine huebsche Karte zu basteln. Da muss man nicht bloss ein wohldokumentiertes API bedienen. Da muss man mit anderen Leuten reden, mit denen besprechen, ob man ein bestimmtes Problem lieber so oder so angehen sollte, sie fragen, ob die Tatsache X einer bestimmten Architektur geschuldet oder nur Zufall ist. Die Mitarbeit an den OSM-Kernkomponenten ist nichts fuer Eigenbroetler, die einen Patch einschicken und sich dann denken irgendjemand wird den schon einbauen und wenn nicht, deren Pech - das ist nicht nur eine technische, sondern auch eine soziale Aufgabe. Daraus folgt auch, dass deutschsprachige Dokumentation in diesen Dingen relativ wenig nuetzlich ist, denn jemand, der seine Arbeit nicht in der persoenlichen Diskussion auf Englisch mit der internationalen Entwickler-Community vertreten kann, dessen Arbeit wird immer nur halb so brauchbar sein als die von jemandem, der das kann. Wichtig ist bei der Doku, immer gleich ein _ganz einfaches_ praktisches Beispiel mitzuziehen. Auch das ist eine Aussage, die vielleicht auf eine OpenLayers-Doku passt, nicht aber auf eine Programmiererdokumentation von osm2pgsql oder vom Rails-Port. Da gibt es keine einfachen praktischen Beispiele (die liegen alle im Code vor Dir). Es gibt vom Rails-Port keine 2000 verschiedenen Einsatz-Szenarien wie bei OpenLayers, es gibt genau eines. These: Jede Stunde, die aktive Entwickler nicht in die eigentliche Entwicklung, sondern in die gut verstänliche Dokumentation der Entwicklung stecken, bringt die Entwicklung im Ergebnis um 10 Stunden weiter. Das halte ich fuer ein Geruecht, zumindest dort, wo es um Software geht, die im grossen und ganzen genau einen Anwendungsfall hat. Bei sowas wie OpenLayers kann ich wenigstens noch sagen: Selbst wenn meine Doku in erster Linie erstmal mehr User ranbringt und nicht direkt mehr Entwickler, einige davon bleiben doch haengen und entwickeln was. Aber beim Rails-Port zum Beispiel gibt es praktisch keine User - der einzige nennenswerte User sind wir selbst. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
Hallo, ich hab jetzt nicht alles gelesen, aber nur mal wo es so bei mir hapert: Ich programmiere bisher C++ mit VC unter Windows. Ich würde gerne mal was anderes anfangen, z.B. Java. Aber alle Versuche eines der OSM Projekte per Eclipse o.ä. zum laufen zu bekommen sind gescheitert. Gut das ist natürlich ein zusätzliches Problem, daß ich gleichzeitig die Sprache lernen möchte, aber auch sonst dürften viele Hobbyprogrammierer Probleme mit dem Einstieg in ein Projekt das über ein CVS o.ä. funktiniert. Was ich mir wünschen würde wäre eine Seite mit einer Liste aller Programme für die Programmierer gesucht werden, am besten in Tabellenform. Natürlich mit Angabe von Programmiersprache, Betriebssystem, Programmierumgebung, und Links auf eine Einführung wie man an die Programmierumgebung aufbaut und den Quellcode lädt. Zusätzlich oder auch notfalls alternativ ein Ansprechpartner der einem beim Einstieg hilft. Hätte ich so jemanden würde ich dann z.B. auch meine Erfahrung niederschreiben, so daß der nächste Einsteiger weniger Probleme hätte. Dies könnte ich warscheinlich besser als jemand der das System schon ewig kennt, da der sich garnicht mehr vorstellen kann wo die Probleme sind. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo! Als Autor von libosmscout antworte ich mal. On Tue, 2011-10-11 at 10:27 +0200, Nils Faerber wrote: 1. Effiziente lokale Datenspeicherung und für eine effiziente und schnelle lokale Abfrage. [...] Ja. 2. Effizienter und state-of-the-art lokaler Map Renderer. [...] Bei einem Renderer, der eine Map in der Größenordnung 200ms liefert, ist die Qualität der Map immer ein Kompromiss. Zugegeben sind die Datenstrukturen und Datenqualität von OSM auch nicht immer hilfreich (aber das macht es ja nur aufregener ;-)). Mein Bestreben ist es eine gute Qualität abzuliefern bei sinnvoller Performance. Ggf. sind erweiterte Funktionalitäten, an/abschaltbar zu gestalten. Ich versuche auch eine hohe Flexibilität bzgl. der Optik der Map zu ermöglichen, aber Performance erzwingt hier eben bestimmte Kompromisse. Oh - sollte soetwas wider Erwarten doch bereits existieren, und ich habe mich danach schon wund gegoogled, nehme ich sachdienliche Hinweise sehr gerne entgegen! Aus lauter Verzweiflung habe ich mir jetzt schon ein Garmin Nüvi in der Bucht geschossen, damit ich wenigstens ansatzweise OSM Karten für Navigation verwenden kann, aber das kann ja echt nicht die Lösung sein... Hast du dir libosmscout [1] schon angesehen? Eingesetzt wird das z.B. schon in MoNav [2], zusammen mit dem extrem schnellen MoNav routing daemon. Es hat zwar Überlegungen gegeben, libosmscout für das Map-Rendering in Monav zu integrieren, dies ist aber noch nicht geschehen. Der aktuell verwendete Renderer ist ein anderer. Von den Screenshots her ist meinem persönlichen Empfinden nach libosmscout schicker, aber so etwas ist immer Geschmackssache. Recht sicher, aber mal sehen, was war das nochmal... [1] https://wiki.openstreetmap.org/wiki/Libosmscout [2] http://monav.openstreetmap.de/ Ah, ja, richtig, hatte ich! Das ist in der Tat einer der vielversprechenderen Ansätze, gefiel mir ganz gut, war nur etwas frickelig ans Laufen zu bekommen (also außerhalb von Monav. Sollte es Probleme geben, sollte man mich kontaktieren. Noch besser ist die Verwendung der entsprechenden Mailingliste. Teile davon könnte man sicherlich extrahieren und für den von mir skizzierten Zweck verwenden - oder vielleicht gleich das ganze OSMScout? Dann wäre es nur noch eine Frage, die Software zu verallgemeinern, damit sie breit eingesetzt werden kann. Also gute Trennung von Renderer, Kartendaten und Routing, damit ggf. auch mal eine der Komponenten gegen eine andere getauscht werden könnte. libosmscout ist so modular designed (die Implementierung ist da sicherlich noch nicht perfekt), dass der Import, der Zugriff auf Daten sowie das Rendering auf gemeinsamen Datenstrukturen aufbauen. Es sollte aber möglich sein, einen Import zu schreiben, der z.B. nicht auf *.osm oder *.osm.pbf Dateien aufbaut, so lange die Daten den grundlegenden OSM Strukturen entsprechen. Ebenso sollte die Schnittstelle der Datenbank (Zugriff auf die beim Import generierten Dateien) auch durch eine andere Implementierung ersetzbar sein. Schließlich greift der Renderer nicht direkt auf die Datenbank zu, so dass prinzipiell auch Daten aus einem Online-Zugriff in den Renderer gesteckt werden können. Integration von Routing ist aktuell eher provisorisch würde aber entsprechend implementiert. Das letzte mal als ich mir das angesehen hatte, war der Renderer noch stark eingeschränkt, d.h. es gab kein richtiges sinnvolles API, um von einer Applikation aus den Renderer als Widget einzubinden und zu beeinflussen (Center-Koordinate setzen, Rotation etc.). Alles machbar, keine Frage! Müßte man nur den libosmscout Author mal fragen und ggf. zusammenarbeiten. Feedback/Anwender Herzlich willkommen :-) Aktuell arbeitet der Renderer mit verschiedenen Backends (in verschiedenen Stadien). Das cairo Backend ist am fortgeschrittesten, gefolgt von einem libagg und Qt Backend. Es gibt auch Anfänge für ein SVG Backend. Neue Backends zu schreiben ist relativ unaufwändig. Eine Abstraktion über das eigentlich ich rendere in ein Canvas in Richtung Widget ist aber sehr schwierig. Ein Gtk Widget (Gtk 2 oder Gtk 3?) und ein Qt Widget (oder doch besser zur Verwendung in QML und Co.?) unterscheiden sich schon sehr, unterschiedliche APIs für Multithreading aber auch unterschiedliche Anforderungen eines Clients (Monav hätte gerne Tiles, die Beispielprogramme rendern immer den sichtbaren Auschnitt) erzeugen beliebig viele Varianten von Widgets - die dann doch nicht passen. Die Personen, die libosmscout zum Laufen und integriert bekommen haben, hatten Aufwand in T Bereich Tage. Für jemanden, der Mal eben schnell ein vollständiges Programm im Kontext Routing,POI etc... schrieben will, ist dies der geringste Aufwand und meiner Meinung nach sollte das kein Hinderungsgrund sein. Tatsächlich habe ich bereits angeboten, entsprechende Widgets zu integrieren, dann aber als Library on-Top der bestehenden libraries. Rotation ist in libosmcout aktuell die Aufgabe das Anwenders
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und die?Engineering WG
On 10/11/2011 10:46 PM, Dimitri Junker wrote: Was ich mir wünschen würde wäre eine Seite mit einer Liste aller Programme für die Programmierer gesucht werden, am besten in Tabellenform. in der Richtung fand ich die Drizzle Low hanging fruits und LibreOffice eays hacks listen nicht schlecht: https://bugs.launchpad.net/drizzle/+bugs?field.tag=low-hanging-fruit http://wiki.documentfoundation.org/Development/Easy_Hacks Vor allem der Drizzle Ansatz das über entsprechend kategorisierte Bugreports abzubilden hat den Vorteil das man auch gleich sieht wer den entsprechenden Eintrag angelegt hat und damit auch als Ansprechpartner oder auch Mentor fungieren kann ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mehr OpenStreetMap Softwareentwicklung und die Engineering WG
Hallo allerseits, Openstreetmap ist natuerlich vorwiegend ein mapping Projekt, aber die Software darum herum ist schon auch irgendwie wichtig, unter anderem um OpenStreetMap.org am laufen zu halten, das Leben der Mapper durch bessere Editoren und QA tools zu erleichtern oder einfach um aus einem Haufen Rohdaten nuetzliche Sachen zu basteln. Im Laufe der letzen Jahre ist bereits ein ziemlich beeindruckendes Software Oekosystem um OSM entstanden, aber dennoch gibt es viele gute und wichtige Ideen, die bislang nicht umgesetzt wurden, oder nuetzliche Programme die nicht mehr maintained werden da es oft nicht genug Entwickler gibt. Die Frage ist nun was kann man machen um mehr Entwickler fuer OpenStreetMap zu begeistern und die Entwickler unter uns in der Community davon zu ueberzeugen sich in Projekte einzubeziehen und patches zu schreiben z.B. um lang vermisste Funktionen zu ergaenzen oder Bugs zu beheben. Um dieser Frage nachzugehen haben sich ein paar Devs vor ein paar Wochen unter dem Schirm der Engineering Working Group (EWG) zusammen getan um zu schauen ob wir etwas tun koennen um den Einstieg in die OpenStreetMap Entwicklung zu erleichtern und mehr Leute dafuer begeistern koennen. Vorwiegend ist das Ziel mehr Leute fuer die Core Projekte zu begeistern wie z.B. Potlatch, den rails_port, xapi, nominatim, cgi_map oder anderen Projekten die derzeit auf den OSMF servern laufen, aber Dinge die die generelle Entwicklung von OSM basierter Software verbessern oder erleichtern koennen natuerlich auch Thema sein. Ein paar der Ueberlegungen die bislang angestellt wurden sind z.B. die Installationsdokumentation des rails_port zu verbessern, Virtuelle Machines mit allen noetigen Entwicklungstools und Softwaredependencies anzubieten, die Verwendung des dev-servers zu verbessern, oder hack weekends zu organisieren um Leute in Person beim Einstig zu helfen. Nun kann man aber lange darueber philosophieren was moegliche Gruende sind das nicht mehr Entwickler sich an diesen Projekten beteiligen, vielleicht einfacher ist es aber einfach euch zu fragen: Was wuerde euch motivieren patches zu schreiben? Was euch den Einstieg erleichtern? Wo liegen derzeit die groessten Huerden um sich zu beteiligen? Gibt es Dinge die das Leben einem erleichtern wuerde? Was wuerde diejenigen die bereits viele Patches geschrieben haben helfen noch mehr patches zu submitten? Wenn ihr zu diesen Themen Ideen, Anregungen, Vorschlaege oder Kommentare habt, schreibt sie hier nieder und ich werde sie dann in die EWG einbringen um zu sehen was man davon umsetzen kann. Natuerlich sind auch alle herzlich Willkomen sich direkt an der Engineering Working Group ( http://www.osmfoundation.org/wiki/Engineering_Working_Group ) selbst zu beteiligen, denn auch dort gilt das uebliche do-ocracy Prinzip. Sie trifft sich jeden Montag um 17:00 GMT (19:00 deutsche Sommerzeit) auf IRC unter #osm-ewg (Internet Relay Chat, auf dem OFTC server). Es ist insgesamt sehr informell. Logs der bisherigen Meetings gibt es unter http://www.osmfoundation.org/wiki/Working_Group_Minutes#Engineering_Working_Group Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
