Android-App OSMfocus: Quellcode veröffentlicht, weitere Entwicklung?

Wie ja schon in der Wochennotitz berichtet wurde, ist der Quellcode der Android-App OSMfocus endlich veröffentlicht worden. Denn es gab sehr lange keine Updates, und aufgrund http statt https Abfragen funktionierte die App nun gar nicht mehr.

siehe im OSM-Wiki: https://wiki.openstreetmap.org/wiki/OSMfocus

Es gibt Bemühungen, die App wieder lauffähig zu machen, und alternativ auch auf f-droid.org bereitzustellen:

https://gitlab.com/fdroid/rfp/issues/685

Falls der eigentliche Entwickler wie angekündigt kaum Zeit für eigene Weiterentwicklung hat, kann es da vielleicht Pullrequests auf github oder gitlab von anderen Android-Kundigen geben?

Was wird benötigt, um die Abfragen der App von http auf https umszustellen?

Siehe: https://github.com/MichaelVL/osm-focus/issues/1

Habe mal einen mini-Pull-Request erstellt …

https://github.com/MichaelVL/osm-focus/pull/3

ist das so richtig in github, bzw. für OSMfocus ausreichend ??

Danke fürs Öffnen eines Threads dazu. Ich hatte das Tool auch immer ganz gerne ab und zu benutzt und würde mich freuen, wenn es irgendwann wieder eine funktionierende Version gibt.

Wie ist denn dazu der Status, ich verstehe nicht ganz was hier die nächsten Schritte sind:
https://github.com/MichaelVL/osm-focus/issues/2

Ganz schön blöd von den Leuten zu verlangen, das Projekt lokal zu bauen und im Simulator zu testen (was ja an sich schon mehrere Stunden Aufwand ist, wenn man das noch nie gemacht hat) und dann im Projekt selbst alles fehlt, was für einen Build benötigt wird: es gibt weder ein build.xml geschweige denn eine gradle config.

Mein Tipp: Finger weg!

Ach, und wie issn des, muss die Tile URL (osm.org) auch auf https umgestellt werden, oder ist dort noch http erlaubt, weil das hatte ich auch im Quellcode gefunden, als ich nach http gesucht hatte.

Oje, das klingt ja nicht so optimistisch… (Danke fürs Drüberschauen)

Verstehe ich Dich richtig, es wurden nur Teile vom Quellcode veröffentlich und keine fertige vollständige Zusammenstellung um daraus eine *.apk erzeugen zu können? Auch wenn der Entwickler MichaelVL jetzt noch die weiteren fehlenden Quellcode-Dateien auf Anfrage nachliefern würde, ist ab dann immer noch ein enormer Zeitaufwand nötig bis eine apk erstellt ist? Also kann man sich die Anfrage zur Beschaffung der fehlenden Daten gleich sparen, weil die Wahrscheinlichkeit gering ist, dass damit jemand weiterarbeitet?

Also das ganze ist im alten Projekt Layout (pre-gradle Nutzung für Android), dürfte im Prinzip mit eclipse /AndMore) baubar sein, aber muss man sicher umstellen.

Bummer: es verwendet google play services, sprich auf f-droid bringt man es nicht (die ganze Problematik davon mal zu ignorieren) und man müsste um es im play store weiterzupflegen Zugriff zum Konto + Schlüssel haben (eher unwahrscheinlich).

Sprich, wie mmd es sagt, einen Haufen Aufwand für sehr wenig Nutzen und ich hab jetzt da nur an der Oberfläche gekratzt (andere Punkte: welche Version der Support Lib wird gebraucht, was ist mit nach November dieses Jahres etc etc etc). Der Aspekt, dass die OSM Entwickler sich eh aus Ego-Gründen auf viel zu viel Projekte verteilen und man um jedes Projekt das stirbt schon froh sein muss, schon gar nicht diskutiert.

Ego-Gründe … was ist damit gemeint?

Das man anstatt an bestehenden Projekten sich zu engagieren und die weiterzuentwickeln, man lieber “was neues” macht, um … zu sein.

Beispiele vom ersten lonvia mit Nominatim, mmd mit cgimap und dem rails-port, Harmut mit mapsomatic. Beispiele vom 2.: zu viele um sie aufzuzählen.

Beispiele vom ersten: SimonPoole mit Vespucci :wink:

Sicherlich ist es richtig, dass bei OSM oft das Rad neu erfunden wird, und ein Teil der Motivation ist sicher oft, dass Leute lieber “ihr eigenes Baby” haben wollen anstatt als Erzieher in einem fremden Kindergarten anzuheuern. Dass Ruhm und Ehre die Währung sind, in der Leistung im Open-Source-Bereich entlohnt wird, ist keine Neuigkeit. Oder wenn es nicht darum geht, dann wollen Programmierer es halt partout in $COOLE_SPRACHE machen statt in Perl :wink: andererseits werden die “neu erfundenen Räder” manchmal auch zu einem durchschlagenden Erfolg, so ist z.B. Rolands Overpass-API anfangs auch nur als Neuaufguss der existierenden “Xapi” wahrgenommen worden, und osmfilter/osmconvert/osmium-tool sind ja “nur” ein C/C++ nachgebautes Osmosis.

Also, manchmal profitieren wir als Projekt schon auch davon…

Bye
Frederik

Klar, speziell wie bei Roland wenn auch der Willen da ist, dass ganze auch noch weiterzuführen und zu pflegen wenn der Neuigskeitswert nicht mehr so da ist (anderseits wenn Roland XAPI übernommen und sein Vorstellungen da realisiert hätte, wäre das auch nicht schlecht gewesen :-)).

Die freiwilligen Projekte sind schlussendlich nicht mal so schlimm, mir kommt die Galle heftiger hoch wenn die sogenannten Humanitären Projekte wieder mal ihr eigenes Süppchen kochen und vor allem aus finanziellen Gründen, resp. der finanziellen Gesundheit der in ihrem Dunstkreis operierenden Firmen, immer wieder das Rad neu erfinden.

Nebenfrage: Kannte bisher nur osmosis. Sind die anderen Programme schneller? Können die genauso viel?

Nein, jedes Programm hat seine Stärken. Osmosis hat immer noch ein paar Alleinstellungsmerkmale (v.a., wenn es um Arbeiten mit einer Datenbank geht), aber für viele Alltagsaufgaben wie Konvertierung von einem in ein anderes OSM-Format oder die räumliche oder tag-bezogene Selektion haben die genannten Alternativen Osmosis den Rang abgelaufen. osmfilter/osmconvert sind ein “Team”, für einige Sachen brauchst Du das eine, für einige das andere. Osmium-Tool ist das Kommandozeilenprogramm zur Osmium-Bibliothek und das modernste von allen.

Bye
Frederik

Ich würde es bestimmt schnell hinbekommen, dem einen maven-build zu spendieren analog BRouter.

Mein Problem aktuell ist nur, ich hab’ keinen aktuellen Android-SDK, und OsmFocus hat minSdkVersion=“14” targetSdkVersion=“19”

Mein letzter Versuch, einen aktuellen Android-SDK hat mich ziemlich Nerven gekostet, aber bald muss ich das ohnehin schaffen, der Google-Play Store nimmt nämlch bald keine APKs mehr an ohne aktuelle targetSdkVersion.

Hat vielleicht jemand den Android-SDK-19 (oder höher) für Windows als tar-ball für mich, damit ich nicht wieder am SDK-Manager verzweifeln muss?

Genau dafür ist der SDK-Manager da und ich bin auch noch nie daran verzweifelt. Starten, Pakete auswählen, Installieren drücken. Was gibt es denn für Probleme bei dir?

Das Original-XAPI in GT.M? Völlig unwartbar, ich kenne wirklich niemanden, der diese Sprache kann.

In den 2009er Quellen von Overpass API finden sich noch erste Gehversuche mit SQL (ich glaube noch für MySQL), das hat aber alles irgendwie nicht funktioniert. XAPI wird kurioserweise heute nur noch von Overpass API über ein Konvertierungsscript angeboten. Wo es geht versuche ich den Leuten das auszureden und sie zu einem Wechsel auf QL zu bewegen (gleiches gilt auch für die XML Variante). XAPI ist wirklich komplett tot.

Huch, wie komme ich denn zum rails-port? Ich habe wirklich gar keinen Plan von Rails und Ruby :slight_smile:

Osmosis wird schon seit einiger Zeit praktisch nicht mehr weiterentwickelt, was u.a. den Umstieg auf neuere Postgres-Versionen als 9.5 blockiert. Das ist irgendwie das Problem bei vielen Tools, oft sind das One-Person-Shows, die Lernkurve ist oft ziemlich steil, was neue Beitragende oft abschreckt, es gibt wenig bis gar keine Dokumentation und im schlimmsten Fall niemanden mehr, der einem Fragen zum Code beantworten kann. Gesund ist sowas nicht für ein Gesamt-Projekt.

Ich meinte natürlich dann auch die Innereien ersetzen.

Maven … schüttel :slight_smile: Ernsthaft, dass ist nicht wirklich sinnvoll wenn man das Projekt auf die Füsse stellen möchte, auch mit gradle kann man problemlos von der Commandline builden und behält die Kompatibilität mit AndroidStudio (nochmals Schüttel) bei.

Du musst https://developer.android.com/distribute/best-practices/develop/target-sdk so oder so (mindestens als play store Nutzer) ab 1.11.2018 gegen API 26 kompilieren (mit all den Konsequenzen die das mit sich bringt), also macht es keinen Sinn jetzt was anderes zu nehmen. Dann musst du damit rechnen, dass der Zwangsschritt bei jedem Update der API kommt, also vermutlich mindestens alle 6 Monate (es gibt IMHO noch keine offizielle Aussage von google dazu, aber ich denke das ist nicht sehr spekuliert). Sprich du musst das so oder so hinbekommen, dass das ganze bei dir flutscht (ev. halt AS installieren und den SDK-Manager daraus verwenden).

Simon

Interessant … wo finden sich zu den konkreten Problemen und Einschränkungen weitere Informationen?