Re: [OSM-talk] Android program with a custom map style
Hello Mateusz, I am looking for an Android application that has bicycle-focused map style available offline. I am looking for features like - ability to distinguish road based on surface (=sand =dirt =asphalt should be easy to distinguish) - oneway arrows displayed based also on oneway:bicycle, cycleway=opposite, cycleway=opposite_lane tags, not only oneway tag - displaying bicycle routes - displaying detailed info about ferries across rivers (at least fee, opening_hours, seasonal and description tags) I am not expecting that application like this exists and I checked https://wiki.openstreetmap.org/wiki/Comparison_of_Android_applications You can use libosmscout (http://libosmscout.sourceforge.net/), which is a C++ framework/library for writing application using rendering, location lookup, routing, which should allow you to do most of the above. Challenge: C++ under Android can be tricky, if you not use Qt (which is supported) and it is a framework, so you have to write your own application based on the libosmscout APIs around it. -- Gruß... Tim ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland
Hallo Uwe, du scheinst ja ein richtiger Spätaufsteher zu sein. In der Zeit vom 10. - 16.03.2016 haben hier einige in der Liste an der Diskussion teilgenommen. Richtig. Habe ich auch gelesen. Allerdings hatte mir mein Mailclient vorgegaukelt, dass die referenzierte Nachricht neu wäre :-/ War nicht so, mein Fehler...ich jetzt aber auch nicht sooo lange her. Die Seite http://www.mobil-im-rheinland.de/lkw-navigation/index.html hast du wohl auch noch nicht gelesen, sonst hättest du dir einiges an Text ersparen können. Nein habe ich nicht. Beantwortet aber jetzt auch nicht gerade detailliert meine Fragen, oder? Für ein LKW-Routing ist erst einmal nötig dass die Daten dafür bereitgestellt werden, das fängt bei Tonnagebegrenzungen an und hört bei Gefahrgutrouten auf. Na ja, mann kann auch vorher LKW-Routing machen, aber mit mehr Informationen wird es besser, da bin ich vollkommen bei dir :-) ich sehe da aber auch keinerlei Widerspruch zu meinem Kommentar? Außerdem hatte ich nicht den Eindruck, als wenn es nur um das Mappen von zusätzlichen Daten in OSM geht, ich hatte das Gefühl, dass der Plan des Autor ein anderer - vielleicht weniger sinnvoller - gewesen wäre. Wie oft hast du denn schon ein priority_road=designated oder hazmat=designated gemappt ? Noch nie. Muss ich das? Wie viele Router hast du schon geschrieben oder LKWs gefahren ;-)? -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland
Hallo,
Hallo zusammen,
es ist echt toll, dass so Viele sich an der Diskussion beteiligen.
Ist das ironisch gemeint, in der Mailingliste habe ich schon länger
nichts mehr darüber gelesen?
Vielleicht nochmal zu den Zielen des Projekts. Der Leidensdruck in
[...]
Das Problem habe ich verstanden. LKWs fahren teilweise nicht daher, wo
sie sollen. Fahrer sind nichts ortskundig und nutzen vielleicht ein
Navi, was ggf. denkt, es handelt sich um einen normalen PKW. Das führt
dazu, dass LKWs gehäuft die gleiche und für LKWs schlecht geeigneten
Strecken nehmen. Worst case ist dann ein LKW ist einer (für LKWs)
Sackgasse, aus die er nicht mehr rauskommt ;-)
Die Vorrangrouten werden vom jeweiligen
Straßenverkehrsamt/Ordnungsamt vorgeschlagen und politisch
abgesegnet. Es malt also nicht einfach irgendjemand in den Kommunen
irgendwelche Vorrangrouten auf, die dann gelten sollen. Die
Zuständigkeiten sind nicht in allen Kommunen gleich geregelt, da es
in vielen kleineren Kommunen kein eigenes Straßenverkehrsamt gibt.
Vorrangrouten müssen sich natürlich immer an die vorhandenen
Schilder/Restriktionen halten, da Diese natürlich nicht gegen die
StVO verstoßen dürfen.
OK, aber was ist definiert eine Vorrangroute? Ist das einfach eine
vorgegebene Abfolge von zu fahrenden Straßen? So etwas wie eine
Bus-Route?
Der Vorteil ist, dass im Routing im nachgeordneten Straßennetz
(Autobahnen und Bundesstraßen sind eh Vorrangrouten) so erst einmal
auf Vorrangrouten geroutet wird, bis deren Ende erreicht ist und
dann die Restriktionen greifen. Wenn es zwei Strecken gibt, die
theoretisch in Frage kommen, kann somit die verträglichere der
Beiden als Vorrangroute definiert werden und so verhindert werden,
dass LKW-Verkehre beispielsweise durch Wohngebiete geleitet werden.
Wieso? So ein Routing-Algorithmus macht eine
Kosten-Analyse/Optimierung. Will ich die schnellste Route, betrachte
ich z.B. Geschwindigkeitsbegrenzungen, Ampeln (also alles was
verhindert, dass ich Höchstgeschwindigkeit fahren kann) als
zusätzliche Kosten. Der Algorithmus sucht dann die billigste Strecke.
Ich kann auch verbieten, bestimmte Straßen zu fahren (sehr große
Kosten). Will ich die kürzeste (nicht schnellste) Strecke, sind die
optimalen Kosten ("weniger geht nicht) die Km Luftlinie und für alle
Straßen sind Kosten=Strecke in Kilometer. (Für A* ist es wichtig, dass
ich die minimalen Kosten vorab festlegen kann, was auch noch
Einschränkungen bzgl. der Kosten ergibt).
Was für mich unklar ist: Wie sollen nun Vorrangrouten dem Router und
dem Nutzer des Navis helfen? Mann will ja sicherlich nicht, dass der
Router die Vorrangroute nur noch sklavisch abfährt, oder? Das kann man
einfacher haben ;-) Tue ich bei der schnellsten Route einfach so, als
wenn ich 10Km/h schneller fahren kann als tatsächlich erlaubt (die
Kostenfunktion kann ja komplexer sein sein, als nur die fahrbare
Geschwindigkeit abzubilden)? Was ist aber, wenn ich wo anders eben
mehr als 10km/h schneller fahren, als auf der eigentlichen
"Vorrangroute"? Oder die Vorrangroute so ein großer Umweg ist, dass
ein algorithmischer "Bonus" eben aufgezehrt wird? Die Vorrangroute
wird ja sicherlich nicht von Natur aus für LKWs optimal sein, oder?
Sonst hätten wir bei (schlauen) Navis ja gar kein Problem :-) D.h.
selbst eine Berücksichtigung von Vorrangrouten im Algorithmus wird
nicht zwingend dazu führen, dass das Navi diese auch tatsächlich
ausspuckt. Und wenn der LKW Fahrer schnackelt, dass die LKW Route weit
ab von aus seiner Sicht optimal ist, wird er das entsprechende Routing
auch gar nicht nutzen (scheiß Navi) ;-)
Ergo: Es wäre schlauer durch verkehrstechnische Maßnahmen dafür zu
sorgen (Beschilderung, Verbote), dass die Vorrangsroute sich als
"natürliche" optimale Route ergibt, sonst werden (OpenSource) Router
und OSM das Problem nicht grundsätzlich lösen - es sei denn, man
erzwingt die Nutzung.
Es würde sicherlich auch erheblich weniger Diskussion geben,
entsprechende Beschilderung in OSM einzubringen. Den "on the ground"
ist ja nicht das Problem (im Gegensatz zu virtuellen Routen deren
praktischer Nutzen unklar ist) und der allgemeine Nutzen ist dann
offensichtlich.
Der Vorschlag, dass wir oder die Kommunen die Vorrangrouten in OSM
beobachten und auf Änderungen reagieren wäre auch denkbar. Kann man
sich die Änderungen an bestimmten Attributen/Objekten herausfiltern
lassen, so dass man sich den händischen Abgleich spart?
Man sicherlich filtern. Aber ein händische Prüfung des Deltas wird
sich nicht umgehen lassen, sonst wäre man bei einer automatischen
(Rück-)Korrektur (eine Variante des Imports) - die die OSM Community
nach meinem Verständnis nicht will.
--
Gruß...
Tim
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Is there a OSM map viewer program to dynamically view OSM data?
Hello Wuzzy, I was wondering if there is some standalone application (preferable for PC) to view OSM data as a map, but dynamically and locally (not from some random computer on the Internet) rendered. [...] What I want is an application which renders OSM data directly and based on configurable user settings, i.e. switching on and off certain features (like country borders) is as simple as clicking a checkbox. You build such a tool with libosmscout (libosmscout.sf.net). It is designed for offline mobile rendering, routing and location search. But of course desktop application can also be build :-) Libosmscout allows you to generate a (local) database from a given *.osm.pbf file with a user definable content. You can then render the data in a map using a custom style which can render any subset of the data contained in the database. It would also allow you to modify the style sheet dynamically (at least this can be very easily added). The current demo however only shows the main base features so this is not yet part of the demo, but a proof of concept should be very easy and quick to achieve. -- Gruß... Tim ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Unterwasser-Seekabel im Mittelmeer gerendert :-(
Hallo! Als Input für die Diskussion: libosmscout geht für die Bestimmung von Land und Meeresflächen für Teilimporte (coastline ist keine geschlossene Linie) davon aus, dass Gegenden (Tiles), die bestimmte Wege beinhalten (deren Typ signalisiert, dass dort Land ist) Land sind und markiert dieses entsprechend. Da ist eine eindeutige Unterscheidung, ob dass nun eine Hochspannungsleitung o.ä. oder ein Seekabel ist, recht wichtig ;-) Das hat nicht auf Anhieb funktioniert und ein offensichtlich unterschiedliches Tagging mit klaren Kriterien ist da hilfreich (ja, Zonen für Seebestattungen hatten ähnliche Effekte, konnten aber glücklicherweise eben unterschieden werden von klassischen Friedhöfen...es gab auch ein paar barriers). -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Map and Programm for Offline
Hello! i search a programm which can see offline the maps and can calculate a route on my netbook. I use Gentoo Linux. I have installed navit, but the routing only with GPS Connectivity. Know someone the programm Geologger for Symbian? Which maps i can use with it. I need Germany, French, Spain (best as europe all together) and North Africa. libosmscout is a library that offer such features (offline map drawing and offline routing calculation). There are demo applications, but no ready to use applications. Depending on your (not specified in detail) requirements this is what you want...or not. -- Gruß... Tim ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo! ich möchte mal wieder eine Frage an die Allgemeinheit stellen auch auf die Gefahr hin zerrissen zu werden. doof, weil Es geht um die Frage wie ist soetwas überhaupt vernünftig und performant in der Auswertung zu realisieren. Das Beispiel kann sicherlich auch auf andere Relationen übertragen werden. Immer werden verschiedene Elemente bei Relationen zusammengeführt die irgendetwas gemeinsam haben und man so verhindern will das Redundante Daten entstehen. Die Frage die ich nun stellen möchte - ist es überhaupt irgendwie möglich solche Verbindungen performant aufzuschlüsseln? und gibt es vielleicht schon Programm(teile) dafür von denen ich nicht weiß. Relation sind nicht grundsätzlich schlecht und können performant abgearbeitet werden. Es gibt aber dennoch in der Praxis gute und schlechte Nutzung von Relationen die es einem Programm mehr oder weniger schwierig machen, diese zu verarbeiten. Leider befürchte ich, dass die Einhaltung einige Kriterien, die es einer Software einfacher machen, es einem Mapper schwieriger machen. Grundsätzlich ist das OSM-Format (im weitesten Sinne) für eine Software immer dann gut, wenn es eine eindeutige Anwendung gibt, wenn ein Problem auf eine Art gemappt wird. Mehrere Varianten zu implementieren ist doof, speziell Ergebnisse beider Ansätze dann wieder zusammenzuführen. Turn Restrictions sind daher OK, Die verschiedenen Hausnummern-Ansätze daher eher schlecht. Schlecht ist auch, wenn Relationen zu einer unscharfen oder lokalen Suche führen, da Referenzen nicht direkt sind. D.h.statt Objekte über die Id zu referenzieren werden sie über ihren Namen referenziert (Die Bahnhofsstr. vor dem Haus ist für Software leider algorithmisch nicht so simpel auf zu lösen wie für den Mapper). Ich verstehe, das direkte Objektreferenzen fragil sind, aber warum klappt bei Turn Restrictions dies, aber bei Hausnummern nicht? Multipolygon und Turn Restrictions sind daher hier OK, Hausnummern Relationen eher nicht. Ich vermute mal,dass es weitere solche Regeln gibt, die die Qualität eines Mappings -speziell von Relationen - aus der Sicht einer Software-Auswertung bewertbar macht. Eine Diskussion und eine Liste wäre ggf. hilfreich und könnte dem nicht-programmierenden Mapper Problemzonen klarer machen, Als Softwareentwickler bin ich dafür, dass jeder Mapper für seine Syntax auch einen performanten Algorithmus liefern muss ;-), aber ich kann den Widerstand der Mapper verstehen. Ich würde mir aber öfters wünschen, dass wenn man nicht für den Renderer mapped, dann doch die Software im Allgemeinen nicht ganz aus den Augen läßt, die das wieder zusammenstoppeln muss. Manches mit Liebe gemappte Feature wäre vermutlich schon längst sichtbar(er), wenn es denn einfach auszuwerten wäre. -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen aus der Sicht der Auswertung - Segen oder Fluch??
Hallo! Ich möchte in dem Zshg. auf [1] verweisen - dato hat fast jede Bundesstraße ihre eigene Relation, so auch viele Landes-, bzw. Staatsstraßen. Auch innerorts ist OSM mit immerhin rund 12.000 Relationen vom Typ street dabei [2], welche gesplittete Wege gleichen Namens explizit in Relation setzen. ich habe mal versucht, eben über Autobahn-Relationen dass Autobahnnetz vollständig aufzubauen. Das wäre hilfreich gewesen, um eine optimierte (aka punktreduzierte) Variante des Netzes für niedrige Zoomlevel zu erzeugen. Das ist kläglich gescheitert. Zum einen, weil die bestehenden Export Extrakte mit Relationen nicht pfleglich genug umgehen zum anderen(die Strategie wäre da für jeden Relationstyp auch möglicherweise eine andere), weil die Relationen einfach nicht vollständig waren. Ein Qualitätsproblem, welches dazu führt, dass ich Relationen nun nur noch für ein paar wenige Zwecke auswerte - für diesen aber eben nicht. Diese Arbeit war für meine Ziele umsonst :-/ - Robustheit - ist ein Faktum sowohl als Relation, als auch über Tags an den Primitiven gemappt, steigt z.B. die Anzahl der Methoden, die QM-Tools verwenden können, um Plausibilität und Konsistenz der Daten zu prüfen - am Beispiel der Bundesstraßen wäre z.B. denkbar, dass man das Ergebnis einer errechneten Relation (alle ways mit ref=B x) mit gemappten Relationen vergleicht, zusätzlich zu den gängigen Tests auf Lücken für Route-Relationen - im Bezug auf das Tagging entsteht eine Robustheit dadurch, dass es unwahrscheinlich ist, dass ein Mapper sowohl auf dem way als auch in der Relation versehentlich das gleiche ändert/löscht Für eine Softwarenutzung irrelevant. Automatisches Auflösen von Widersprüchen ist sehr aufwändig und eine Entscheidung hat eine offensichtliche 50/50 Chance. Da schenke ich mir die Relation gleich, wenn möglich. - Wartbarkeit / Datenmanagement - existieren sowohl Relation als auch Primitiven, kann der Mapper Information gewichten, d.h. bestimmte Informationen redundant halten, andere nicht - bsp.-weise könnte man sich der Übersichtlichkeit wegen entscheiden, auf den Primitiven nur die nötigste Information zu taggen (ref/name), während die Relation Zusatzinformation hält (tmc, name:de, name:en, name:xyz, ..) - damit bleiben die einfacheren und vermutlich häufigeren Anwendungsfälle auch ohne Relation-Lookup lösbar Das Verteilen von Daten zu einem Objekt über mehrere andere Objekte macht es Software sehr viel schwieriger diese Daten zusammenzuführen. Es sind viel mehr Daten gleichzeitig in der Luft zu halten. Das bedeutet, geringere Performance, mehr Hauptspeicherbedarf. Widersprüche (s.o.) können auftreten. Software hätte gerne Datenlokalität. Es gibt schön Gründe warum Datenbanken normalisiert sein sollen. - Zugänglichkeit - Verschiedene Leute verwenden verschiedene Mapping-Methoden. Während die strukturierteren Leute sich evtl. gezielt mit einem bestimmten Thema beschäftigen (sei es Bundesstraßen, Wasserläufe, Geschäfte, etc.) und es demnach begrüßen, wenn sie, statt einem Gebiet, gleich über eine Relation die jeweils zu bearbeitenden Daten selektiv in ihren Editor ziehen können, um den aktuellen Stand zu prüfen, interessiert diese Art des Zugangs den Pionier im relativ datenlosen Gebiet kaum. Verschiedene Zugänge zu Daten ist für Software OK, da man flexibler gegenüber mehreren Lösungsansätzen ist. Dafür muss aber alle Zugänge zu allen Daten führen. Das ist bei OSM eher nicht der Fall. Obige Aspekte spiegeln die Sicht eines Mapper wieder. Die Punkte sind aus seiner Sicht nicht falsch. Die Sicht des Mappers ist aber nur eine Sicht, die Sicht einer Software und deren Entwickler ist eine andere. Es gelten andere Kriterien,die teilweise im Widerspruch zu den Kriterien des Mappers sind. Will man nicht nur an der Bearbeitungs-Useability des Mappers arbeiten sondern auch an der Qualität des Software-erstellten Ergebnisses, sind diese Kriterien mehr in Einklang zu bringen. Zu viel Mach es wie du willst macht es der Software schwer, zu viel Genau nach Schema und mit klarer Definition und nicht anders sorgt dafür, dass die Mapper wegrennen. Haben beide Seiten mehr Fingerspitzengefühl und Verständnis für die Bedürfnisse des anderen, kann was Tolles daraus werden :-) -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entwicklung eines Navi für OSM Daten
Hallo! ... Nicht alle Projekte werden fortgeführt werden... ... könntet Ihr euch mal unterhalten ... ... und zusammen tun ... ... ich mach dann auch noch mit ... Es macht doch keinen Sinn das jeder seinen eigenen Ansatz verfolgt und keiner fertig wird. Welches ist der beste Ansatz? Können wir uns auf eine Linie einigen und alle zusammenarbeiten? Was ist eure Meinung zu den Projekten. Es hat bereits vor längerer Zeit Gespräche zwischen den Entwicklern von Monav und libosmscout gegeben (wir sind ja nicht blöd ;-)). Am Anfang ist es (berechtigt) an der mangelnden Performance von libosmscout gescheitert. Hier hat es aber signifikante Verbesserungen gegeben. Ebenso geht Monav in einfachsten Fall von einer Renderer aus, der Tiles zurückgibt. Auch dazu gab es Anpassungen in libosmscout. Gleichzeitig hat nun Monav einen Vektor-Renderer integriert (der aber nicht Fisch, nicht Fleisch ist), was wiederum den Druck dort etwas reduziert. Ich wiederum würde mir von Monav Feedback bzgl. Laufzeitverhalten wünschen, um gezielter Optimierungen an zu gehen, eine Integration als Tile-Render ist vielleicht auch nicht optimal, eine gezielte Integration wäre sicherlrich sinnvoller usw... Schlussendlich fehlt meiner Meinung nach einfach jemand, der sich um die Sache kümmert und bei der Stange bleibt. Die aktuellen Teams schaffen es einfach gerade nicht, dies zusätzlich zu stemmen. Auch hier kann man mit ein paar mal 5 Tagen möglicherweise richtig was reißen und beiden Projekten gleichzeitig Schwung verleihen. Wir haben ja gesagt, das es genug Arbeit für alle gibt ;-) -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entwicklung eines Navi für OSM Daten
Hallo! Hallo! Libosmscout sucht weiterhin Mitstreiter. Es handelt sich hierbei nicht um eine vollstaendige Navi-Software, aber doch um eine modulare Sammlung notwendiger Basiskomponenten. Ich habe auch nichts gegen weitere Module. Klasse, genau so etwas habe ich mir vorgestellt. Ich habe mir das eben einmal angeschaut. Tja, ich hab nicht viel verstanden. Ich halte mich für durchschnittlich dämlich und gehe daher davon aus, dass jemand anderes auch so seine Probleme hätte. Für mich wäre es sehr hilfreich wenn ich wüsste was die Software machen möchte und wie sie es versucht. Die Konvertierung der OSM Daten zum Beispiel wie soll denn die Binärdatei aussehen? Dabei geht es nur ums grundsätzliche Verstehen. Beispiel: * Einlesen eines OSM *.osm bzw. *.osm.pbf Datei. * Preprocessing der Daten mit dem Ziel eine Reihe von kompakten Binärdateien zu erzeugen, die in Summe eine für reine Lese-Zugriffe optimierte Datenbank bilden, die die für Rendering, Adress-Abfragen, POI-Abfragen, Routing benötigten Informationen in minimaler Zeit bei minimalem Ressourcenverbrauch bereitstellen. * Definition einer (abstrakte) Schnittstelle auf diesen Daten * Implementierung dieser Schnittstelle auf den generierten Binärdateien. * Implementierung eines Renderers, der diverse Backends unterstützt (konkret Cairo, Qt, libagg, SVG) * Implementierung einer Routers (aktuell A*, nach Monav nicht weiterverfolgt) Bzgl. des Binärformats siehe auch libosmscout/ProcessingResult.txt als grundlegenden Einstieg. Es wäre hilfreich, wenn du genauer beschreibst, was du dir angeschaut hast, was dich interessiert (und warum), damit ich gezielter deine Fragen beantworten kannst. Das würde den Einstieg erleichtern. Letztlich geht es um höchstens 2 DIN A4 Seiten für den Konverter, 2 für den Router... Vielleicht kann man so Programmierer fangen? (Nicht nur mich.) Ja, aber es werden vermutlich die zwei Seiten sein, die dich nicht weiterbringen. Die Frage nach wie geht das, kann man von verschiedenen Sichten angehen. Sei etwas konkreter :-) Das ist kein Coding Problem. Das ist ein Problem von Zeit und Leuten. Hab ich nicht vor. Die Beispiele sind aus meinen Spielereien und werden nicht veröffentlicht. Hmmm, wir sollen Sachen für dich beschreiben und du rückst deine Sourcen nicht raus ;-)? Was wuerde ich fuer 5 Stunden mehr die Woche geben... ;-) Geht mir genau so. -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entwicklung eines Navi für OSM Daten
Hallo! Ich kann mir vorstellen das es etliche Leute wie mich gibt, die gern an einem Programm mitarbeiten würden aber unter zeitlicher Begrenzung. Ich denke an langfristig 5 Std. pro Woche, in der Anfangsphase sicher etwas mehr. Damit so jemand nützlich sein kann müsste ein Projekt *** in möglichst viele abgeschlossene Module aufgetrennt sein, mit dokumentierter Schnittstelle. Geht das überhaupt? Na, wenn nicht, das Umdokumentieren nicht vergessen. Libosmscout sucht weiterhin Mitstreiter. Es handelt sich hierbei nicht um eine vollstaendige Navi-Software, aber doch um eine modulare Sammlung notwendiger Basiskomponenten. Ich habe auch nichts gegen weitere Module. *** für Neulinge dokumentiert sein. Ich meine grundsätzliche *** die alten Mitarbeiter im Projekt sollten für Neulinge Arbeiten definieren, beschreiben und die Einstiegspunkte aufzeigen. Das dient alles dazu einem Interessierten den Einstieg zu erleichtern und zu motivieren dabei zu bleiben. Auch bei libosmscout ist nicht alles dokumentiert. Mein Angebot ist daher, dass ich auf Anfrage alles erklaere und dokumentiert, was dem Fragenden unklar ist. So sind z.B. bereits eine Reihe kleinerer Demos entstanden. Aber ich habe auch schon eine Dokumentierung des Fieleformats abgelehnt, da hier der Aufwand aber eben auch die dynamik zu gross ist/war. Grundsaetzlich sollte man Open Source Projekte nicht (nur) auf Basis der exiatierenden Doku betrachten, sondern die Response auf Fragen. Kann das funktionieren? Keine Ahnung! Aber ich würde es so versuchen. Das ist kein Coding Problem. Das ist ein Problem von Zeit und Leuten. Wie ist es, wollen wir versuchen ein Navi herzustellen? Hat jemand Lust mitzumachen? Wie wollen wir starten? Fangen wir von vorne an und arbeiten Teile von monav oder gosmore ein oder bauen wir auf monav auf oder... Ich wuerde bei vermeintlich toten Projekten den Tod erst einmal sicherstellen. Sprich: hast du schon mit den Entwicklern von Monav ueber deren aktuelle Situation gesprochen? Bei einem exiatierenen Projekt mitzuhelfen ist besser, als ein neues anzufangen. Sonst bist du in einem Jahr auch nur so ein halbgares Dingen... Was wuerde ich fuer 5 Stunden mehr die Woche geben... ;-) -- 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
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
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] Tiles Downloader bremsen Server aus
Hallo! Eine Applikation, die gut und schnell selber rendert, ist halt schwieriger zu schreiben, als der 1000. Tile-Downloader, den man sich mal eben im App-Baukasten zusammenklickt ;) Hier der Hinweis auf http://libosmscout.sourceforge.net/. Dabei handelt es sich eine Library für Offline-Rendering, die in eigene Applikationen integriert werden kann. -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
Hallo! Ich habe jetzt doch noch eine Moeglichkeit gefunden, wie ich das Problem etwas eleganter und mit minimalem Extra-Aufwand loesen kann. Ab heute (in ein paar Stunden duerften alle Extrakte auf dem Downloadserver sein) sollte das Relationsproblem behoben sein, und zwar unter Beibehaltung der Sortierung. Danke :-) Das klingt nach einer Lösung, vor der alle profitieren. Ich vermute, die Aussagen gelten auch für die *.pbf Dateien? -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
Hallo! Ich habe mal unter download.geofabrik.de/tmp ein aktuelles Deutschland-File nach diesem neuen Muster hingelegt. Gibt das bei irgendjemandem Probleme? Es wird nicht moeglich sein, alte und neue Files parallel anzubieten - *entweder* die Relationen schoen geordnet *oder* vollstaendig ;) Ja, libosmscout baut Indizes über seine binären Daten auf. Während des Imports geht es davon aus, dass Nodes in aufsteigender Id Reihenfolge vorkommen. Theoretisch kann ich ein Index auch auf eine unsortierte Datei aufbauen, aber dann kann ich nicht mit relativen Offsets arbeiten :-/ Eine Sortierung ist daher sinnvoll und wenn ich sie nicht bekomme, mus ich sie mühsam selbst herstellen und kann dabei nicht davon ausgehen, das sich alle Dateien im Hauptspeicher halten kann. Das Problem, dass Relation mit Referenzen auf Relation aktuell nicht ausgewertet werden, da die Ids in den Referenzen ggf. noch nicht bekannt sind (weil sie in der Datei hinter der aktuellen Referenz liegen) ignoriere ich aktuell noch, da es drängerende Probleme gibt ;-). Allerdings sollte das für mich möglicherweise kein Problem sein, da der Import 2-stufig läuft, d.h. erst baue ich über die (binären) Rohdaten einen Index auf, dann generiere ich die tatsächlichen Daten. Unschön ist dann nur, dass ich die referenzierten Nodes und Ways in einer Referenz ggf. mehrfach auswerte... aber einen Tod muss man sterben ;-) P.S.: Suche weiterhin Mitstreiter -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
Hallo! Ja, libosmscout baut Indizes über seine binären Daten auf. Während des Imports geht es davon aus, dass Nodes in aufsteigender Id Reihenfolge vorkommen. Theoretisch kann ich ein Index auch auf eine unsortierte Datei aufbauen, aber dann kann ich nicht mit relativen Offsets arbeiten :-/ Die Nodes und Ways waeren ja weiterhin sortiert. Bloss die Relationen nicht. (Man kann auch einfach ein osmosis --sort drauf loslassen, aber das braucht halt wieder ein bisschen Zeit...) Ich nutze osmosis nicht und hatte auch eigentlich nicht vor das zu ändern ;-) Die Zahl der Relation ist natürlich relativ klein, aber ich versuche gerade den Import so schnell zu bekommen, dass man auch in sinnvoller Zeit Daten für ganz Europa generieren kann, da ist ein weiterer sortierender Processing Schritt nicht hilfreich und mit sortierem im Hauptspeicher ist es dann auch schnell wieder vorbei. Vor allem gewinne ich durch die Änderung der Reihenfolge persönlich nichts, sie löst das Problem (wa ich grundsätzlich auch sehe und auch habe) nicht für mich sondern macht mein Leben schwerer. Aktuell ist das scheinbar eine Lösung die einem Tool hilft, aber nicht grundsätzlich allen, weil deren Anforderungen anders/komplexer sind. Alternativen? (Grundsätzlich überlege ich, die Ids intern gar nicht zu verwenden, da eindeutige Ids und eine Sortierung schön ist, aber die Sortierreihenfolge (in der Reihenfolge des Anlegens) für meine Zwecke nicht optimal ist. Mir wäre eine Id-Vergabe und Sortierung lieber, wo naheliegende Objekte auch eine naheliegende Id haben. Aber ich schweife ab...) -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage an die Nutzer von Geofabrik-Extrakten
Hallo! Die Zahl der Relation ist natürlich relativ klein, aber ich versuche gerade den Import so schnell zu bekommen, dass man auch in sinnvoller Zeit Daten für ganz Europa generieren kann Wäre es da nicht generell ohnehin sinnvoller mit pbf zu arbeiten? Ja, seit dem Wochenende gibt es neben Country auch Western, sprich neben dem Importvon *.osm Dateien nun auch *.pbf :-) (bis zu 14x schneller) Ich ging aber davon aus, dass die Änderung prinzipiell beide Formate betreffen würde (ist das korrekt?) und würde die Unterstützung für *.osm auch nicht zeitnah entfernen wollen. -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Custom rendering of a small map
Hello! I'm interested in this, too, because I want to draw OSM data in my car computer as a sort of GPS satnav/realtime editor. See libosmscout.sf.net. It is designed as a library for offline map drawing (however not editing) in mobile devices. It is a renderer (and router) optimized for minimum data size and speed. Dane (of Mapnik fame) suggested I use Mapnik with the OSM data plugin. That cuts out the majority of the setup time due to PostGIS install and import of OSM data. Since libosmsocut uses cairo internally and cairo has SVG export this would should work with it, too. But I assume it needs some more time to get the required drawing quality to be usable for generating printable maps (but it is already worth a try :-)). -- Gruß... Tim ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Details mappen in Dortmund
Hallo! solange man es sauber macht, gibt es damit auch routingtechnisch keine Probleme: man wird halt aussenrum anstatt mitten drüber geleitet. In libosmcout unterscheide ich beim Routing explizit zwischen Flaechen und Wegen. Bei Flaechen kann ich von jeden Punkt auf dem Umfang zu jedem anderen Punkt des Umfangs direkt gelangen - die Flaeche also explizit queren. Ist das falsch? -- Gruß... Tim___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Request for help: libosmscout
Hello! I'm still looking for people interested in helping me with further development libosmscout (http://libosmscout.sf.net). The library steadily improves, but more people could simply get more work done faster ;-) libosmscout is a C++ library, that implements offline map drawing and routing based on OSM data. It does this by import an existing *.osm file and generating a binary, plattform independent file based database and offering an high level API on top of this database. The main target group of the library are people that are interested in developing applications based on OSM and that do not want to directly access available data using existing online APIs. Such applications of course also include offline navigation software but of course other, more specialized applications are possible. Recent discussions with interested people however have shown that libosmscout has a much broader target group. Since the library consists of separate components for import, dataaccess, routing and map drawing, other usage senarios are also possible and I'm also looking for people that want to improve libosmscout in that direction: * Generating stylable (paper) maps * Using it as a small desktop local caching tile server with very light infrastructure requirements. * Using it to tests and compare different routing alogrithm (that can share pre- and postprocessing and thus safe the developer the hassle to fiddle around with *.osm file format and generating a good textual routing description). * Use the internal data structures and map drawing for online-data API based map drawing * Statistical analysis and data test suite libosmscout currently depends on libxml and libcairo (, but even that could be abstracted ;-)) and thus should work on various platforms. If you are interested take a look at libosmscout.sf.net for further details (and a video) or simply contact me. -- Gruß... Tim ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] S: Hilfe bei Autobahnen - name per bot loeschen
Hallo! oder nur so, da das A 93 ja aus der Relation vererbt wird: highway=motorway name=Inntal-Autobahn Dann fliegt das A93 aber aus den meisten Karten raus, die sich nicht um Relationen scheren. Oder entsprechende Software muß vermehrt Informationen aus Relationen in die entsprechenden Wege (Nodes) zurückpropagieren :-/ Ist es ein Ziel das *.osm Redundanzfrei zu gestalten? Dann wäre dies ein logischer Schritt... -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Routing auf WinCE
Hallo! Die Problemstellung ist relativ einfach; wie man den kuerzesten Weg in einem Graphen sucht, das versteht jeder, und wenn jemand ein paar Semester Informatik oder Operations Research oder sowas hatte, dann sind ihm auch die einschlaegigen Algorithmen (Dijkstra, A*) schon ueber den Weg gelaufen. A* ist nicht schlecht. Die Lösung ist wohl grundsätzlich optimal - aber A* ist langsam :-/ -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing auf Navi für Anfänger
Hallo! (aus gegebenen Anlass ;-)). Ich bin seit einiger Zeit an der Entwicklung von libosmscout (http://libosmscout.sf.net). Ziel dieser Entwicklung ist das Bereitstellen von Basisfunktionalitäten für offline-fähige Navgiationssoftware. Dies beinhaltet das Zeichnen von Karten, das Suchen von Karteninhalten sowie Routing. Performance und Hauptspeicherverbrauch sollten der Ausstattung von entsprechenden mobilen Geräten angemessen sein. Es handelt sich hierbei nicht um die Entwicklung einer Navigationssoftware, sondern nur um die entsprechenden Basisdienste. Mit einer entsprechenden Bibliothek sollte aber das Entwicklen einer entsprechenden Applikation erheblich einfacher (aber sicherlich nicht einfach) sein. Weitere Informationen auf der Homepage (Screenshots, Video). Die aktuellen Anforderungen bzgl. des Betriebssystems sind realtiv gering (C++, xml-Parser, für Karten libcairo), eine Nutzung damit auch unter Windows, iXXX und Symbian prinzipiell möglich (mein Ziel ist Nokias maemo/bzw. Nokias und Intels MeeGo Plattform). Für dieses Projekt suche ich noch Hilfe. Bei Fragen/Interesse bitte an mich wenden :-) -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing auf Navi für Anfänger
Hallo! Für dieses Projekt suche ich noch Hilfe. Bei Fragen/Interesse bitte an mich wenden :-) Wäre es vielleicht sinnvoll einen Lightning Talk auf der FOSSGIS zu machen? Siehe Mail von Fred! Darüber habe ich sogar schon nachgedacht. Bonn-Osnabrück ist auch prinzipiell machbar, aber auf der Abreit geht es gerade drunter und drüber, so daß ich vermutlich nicht einen Tag freibekommen werde :-/ Ich habe aber kein Problem jemand anderes entsprechend zu briefen ;-) -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planet-Extrakt D-A-CH
Hallo! DACH ist toll aber Leute aus NRW hätten dann gerne auch Benelux zumindest teilweise dabei .. sinnvoll wäre dann doch eher ein etwas größer gefasster Deutschland -Ausschnitt bei dem das Grenzgebiert gut miterfasst ist. Nun dürft ihr euch über die Breite des Grenzgebietes (bin für das Gebiet was man zu Fuss innerhalb von 2 Tagen von der Grenze erwandern kann ;-)) ) streiten. Richtig. Es sieht so aus, als wenn nordrhein-westfalen.osm nicht die Grenzen von NRW beinhaltet. Damit sind z.B. auch die Grenzen des Regierungsbezirks Arnsberg nicht vollständig. Da wird etwas zu scharf geschnitten ;-) Unschön, wenn man versucht Städte in der Form Bergkamen/Kreis/Unna/Regierungsbezirk Arnsberg/NRW über Boundaries aufzuarbeiten :-/ -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vektorkarten auf Windows-CE/Mobile?
Hallo! Welches der vielen Programme zur Darstellung von Offline-OSM-Karten beherrscht Vektordarstellung? Die Programme, die ich bislang gefunden habe wollten alle vorher Tiles als PNG downloaden. Das mag für Großraum Eschborn noch funktionieren, aber spätestens bei Hessen Komplett in Z17 wird's mit dem Flash-Speicher eng... Aber vermutlich habe ich nur falsch geschaut, daher: Welche Empfehlung hättet Ihr für mich, um zumindest eine OSM-Deutschlandkarte dabeizuhaben, die nicht den Einschränkungen des Garminformates unterliegt? libosmscout (libosmscout.sf.net) hat dies zum Ziel. Aktuell entwickle ich unter Linux, weiss aber das ein Build unter Windows erfolgreich war. Ein Build unter Windows CE sollte daher ebenfalls möglich sein (leider habe ich selbst aber keine Entwicklungsumgebung/Gerät). libosmscout befindet sich allerdings noch in der Entwicklung (Features/Performance). -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
