[Talk-de] Zum 1000. mal - Hausnummern und Stra ßennamen?
Hallo! Ich fürchte das kam sicherlich schon 1000+1 mal: Wie mappe ich Hausnummern richtig? Ich habe mich im Wiki und per Google schon wund gesucht. Hintergrund: In NRW speziell Südwestfalen gibt es den GDI.SW Dienst, von dem man hervorragend und legal abmalen kann - mit Häusergrundrissen und Hausnummern. Ich bin nun seit ein paar Tagen dabei, die mir bekannten Ortsteile also darauf basierend einzupflegen. Zur Zeit verpasse ich jedem Haus seine Hausnummer, aber nicht den Straßennamen. Ich finde es mehr als redundant, jedem Haus den kompletten Namen mitzugeben. Ich habe dazu nun drei Varianten gefunden: 1. Straßennamen nicht mit angeben - Algorithmen sollen bei einer Suche in der Nähe der Straße suchen. Das ist in wohl 90% der Fälle OK, schlägt aber bei Häusern an Straßenecken fehl. 2. Straßenname mit als Attribut an das Haus. Finde ich super redundant. Dann steht der Straßenname-String (n+1) mal in der OSM Datenbank - eigentlich Blödsinn. 3. Häuser zu einer Relation associatedStreet mit dem Namen der Straße hinzufügen - das klingt sinnvoll! Also eine Relation pro Straßennamen hinzufügen und dann alle Häuser an der Straße als Mitglieder dieser Relation. Nur leider kennt JOSM diesen Relationstyp nicht, was mich etwas verwirrt. Was ist also die beste und favorisierte Variante derzeit in OSM.de? Wenn ich mir schon die Arbeit mache, dann mache ich sie lieber gleich richtig ;) Und jetzt wo das Wayfinder Zeug frei ist, gibt es ja vielleicht auch bald noch mehr Navi Software die mit OSM Daten läuft! Viele Grüße nils faerber -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 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] Zum 1000. mal - Hausnummern und Stra ßennamen?
Am 15.07.2010 22:22, schrieb olvagor: Nils Faerber schrieb: Ich fürchte das kam sicherlich schon 1000+1 mal: Wie mappe ich Hausnummern richtig? Ich habe mich im Wiki und per Google schon wund gesucht. Hintergrund: In NRW speziell Südwestfalen gibt es den GDI.SW Dienst, von dem man hervorragend und legal abmalen kann - mit Häusergrundrissen und Hausnummern. Nachtag: da steht sogar explizit Die Verwertung der Dienste zum Zwecke des Aufbaus eines digitalen Datenbestandes mit der Absicht der kommerziellen Nutzung sowie die Veräußerung von Auszügen des Stadtplans sind nicht zulässig. Warum ist das legal zum Abmalen zu benutzen? Wir (Siegener User) haben, das kam auch hier mal von Peter Vitt, explizit bei denen nachgefragt. Nach Rücksprache in deren Gremien haben Sie uns die Auskunft erteilt, daß solange bei der Erstellung des digitalen Datenbestandes keinekommerzielle Absicht besteht, die Daten nutzbar wären. Sie wurden explizit auf OSM und die Zwecke und Lizenz von OSM hingewiesen und gaben die Auskunft, daß aus Ihrer Sicht der Nutzung nicht entgegen stünde. Gruß, Markus Viele Grüße nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 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] Zum 1000. mal - Hausnummern und Stra ßennamen?
Thomas Ineichen wrote: Hallo steffterra, Hi! Aber unabhängig davon würde mich interessieren (nicht als Argumentation): - Unterstützt _derzeit_ z.B. Nominatim die Adressuche in Relationen? - Außerdem wäre es natürlich super, wenn auch der OSM-Inspektor um diese Variante 3 erweitert würde. (http://tools.geofabrik.de/osmi/?view=addresseslon=9.93101lat=49.79438zoom=18opacity=0.77overlays=buildings,buildings_with_addresses,postal_code,nodes_with_addresses_defined,nodes_with_addresses_interpolated,street_not_found,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads) - Könntet ihr bitte einen Beispiellink posten, wo es so umgesetzt wurde? Danke. Ich habe bei mir das vor längerem mal ausprobiert: (Datentechnisch finde ich es die schönste Lösung, allerdings ist es wohl nicht die praktischste für die Auswertung) http://www.openstreetmap.org/browse/relation/141824 http://www.openstreetmap.org/browse/relation/139702 http://www.openstreetmap.org/browse/relation/139703 http://www.openstreetmap.org/browse/relation/334208 Ah, super, da sehe ich endlich mal, wie das aussieht ;) Ich denke, Datensatz zerrissen (siehe vorherige Mails) hin oder her, auf ein bisschen auf Datensparsamkeit sollten wir schon achten. auch finde ich die Suche via Realtionen auch nicht so fürchterlich tragisch, wenn man den Straßenrelationen noch ein paar Tags mitgeben würde, wie eben bspw. die restlichen Adreßdaten wie Ort/PLZ. Dann ließe sich die Suche komplett in den Relationen bewerkstelligen. Für den Ortswechsel innerhalb einer Straße würde ich dann schlicht zwei oder mehr Relationen anlegen. Was ich mich nur gerade frage ist, welche üblichen Attribute gibt es für Relationen? Die gleichen wie für normale Nodes und Wege? Ich finde dazu gerade keine Übersicht... Wenn ja, dann sollte man den Straßennamen nicht in den name= setzen, sondern die normalen addr:city addr:postcode addr:street verwenden. Damit ließe sich dann auch eindeutig nach Adressen in best. Orten/Ortsteilen suchen. Das sollte dann sogar recht effizient sein. Adressen werden von Nominatim mühelos gefunden: http://nominatim.openstreetmap.org/search?q=M%C3%BChlestrasse+12c%2C+Maurviewbox=-225%2C83.78%2C225%2C-77.35 Nomatim kannte ich auch noch nicht, nett! Aber gut zu wissen, daß das Teil innerhalb der Rel. suchen kann. Gruss, Thomas 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] Zum 1000. mal - Hausnummern und Straße nnamen?
Dirk-Lüder Kreie wrote: Am 15.07.2010 22:02, schrieb Nils Faerber: Wie mappe ich Hausnummern richtig? Zur Zeit verpasse ich jedem Haus seine Hausnummer, aber nicht den Straßennamen. Ich finde es mehr als redundant, jedem Haus den kompletten Namen mitzugeben. 2. Straßenname mit als Attribut an das Haus. Finde ich super redundant. Dann steht der Straßenname-String (n+1) mal in der OSM Datenbank - eigentlich Blödsinn. Redundanz ist gut! es ermöglicht z.B. automatisiert Fehler zu finden (Widersprüche). ...oder um welche zu generieren. Wie will man denn automatisiert entscheiden, ob ein Tippfehler ein Tippfehler oder vielleicht wirklich ein anderer Name ist? In der Informatik vermeidet man soetwas wie der Teufel das Weihwasser. Gleiches ist entweder wird das Gleiche oder eben etwas Anderes. Und das macht man in der Regel mit Verweisen, was eben eine Relation ist - genau wie bei einer relationalen Datenbank. Ausserdem: Sämtlicher Datenaustausch von größeren OSM Datenmengen findet eh im bz2-Format statt, was Redundanzen eher super wegsteckt, als sich daran zu stören. Wenn die Lokalität halbwegs gegeben ist, ja. Sobald geändert wird und die identischen Strings nicht mehr beieinander stehen (in einem Block), klappt das immer weniger gut. 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] Zum 1000. mal - Hausnummern und Straße nnamen?
hi flo! Florian Lohoff wrote: On Thu, Jul 15, 2010 at 10:02:50PM +0200, Nils Faerber wrote: [...] 3. Häuser zu einer Relation associatedStreet mit dem Namen der Straße hinzufügen - das klingt sinnvoll! Also eine Relation pro Straßennamen hinzufügen und dann alle Häuser an der Straße als Mitglieder dieser Relation. Nur leider kennt JOSM diesen Relationstyp nicht, was mich etwas verwirrt. Die associatedStreet relation ist kaputt. Sie ist definiert das sie nur EINE Straße beinhalten darf. Das Problem dabei ist das wir Wo ist das so definiert? Technisch wäre es doch kein Problem, einer Realtion mehrere way-Schnipsel zuzuteilen? Also ich habe in JOSM zumindest machen können... Wähle ich dann meine Straßenrelation an, werden brav alle Mitglieder markiert - alles Wegteile und alle Häuser, die ich da mit reingeworfen habe. Ich sehe auch gar keinen Sinn darin, daß man nur einen Way in eine associatedStreet stecken können soll. Das nur eine Straße im Sinne von ein Stra0enname drin sein darf, ja, das macht Sinn, klar, denn man will ja in einer Relation eben alle Teile die zu diesem Straßenzug gehören zusammenfassen. Oder bin ich hier irgendwie auf dem falschen Dampfer? die Straßen zu zerhaeckseln wegen oneway, maxspeed, width, cycleway etc so das nur noch straßenschnipsel ueber bleiben. Danach muss ich fuer einen Straßenzug dann irgendwelche 20 Relations anlegen damit jedes Haus auch zu der vor ihm liegenden Straße gehoert? Kann irgendwie nicht sein. Und was ist wenn ich dann eine Straße zerschneide? Dann sind mit einem mal beide Straßenschnipsel in der relation und die relation ist syntaktisch kaputt. Wenn ich das also reparieren moechte muss ich jedesmal beim zerteilen einer Straße die relation doppeln - die jeweiligen Straßenschnippsel aus den relationen entfernen und entsprechend auch die Haeuser. Das wäre dann wirklich vollkommen doof, ja, und auch nicht mehr praktikabel. Ich halte 1) fuer zu unklar und nicht eindeutig und 3) fuer viel zu komplex das Joe Mapper damit klar kommt. Hmm... das Millionen Fliegen Argument hat mich noch nie überzeugt ;) 2) ist nach dem KIS Prinzip - Simple - Natuerlich ist der Preis die vermeindliche Redundanz aber das kann jede Datenbank und jeder Navi preprozessor dann ja entfernen und in andere abhaengigkeiten konvertieren. Das ist wohl war - er könnte eine Relation draus machen ;) Ausserdem macht es IMHO das bearbeiten auch einfacher - Einfach im JOSM suchen nach addr:street=blah und schon hat man alle Addr Elemente einer Straße - Visuell leicht zu sehen ob sich da Fehler einschleichen. In JOSM auf die Relation doppel-Click - alle Mitglieder werden (bei mir) lila highlighted. Also das ist eigentlich gleich einfach (mindestens). Über welche Probleme man da so stolpert ;) Flo 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] Zum 1000. mal - Hausnummern und Stra ßennamen?
Thomas Ineichen wrote: Hallo steffterra Das setzen wir doch voraus. Immerhin geht es darum _Adress_informationen als Eigenschaft des Gebäudes zu taggen. Ich verstehe immernoch nicht, welchen Vorteil es hat, _Adress_-Informationen in einer Relation zusammenzufassen und nciht als Eigenschaft des Gebäudes am Gebäude zu lassen. Es geht mir wie Faust (Zwei Seelen wohnen, ach! in meiner Brust.): Eine Relation fasst zusammen, was zusammengehört und es ist (für den Informatiker) logisch dabei die Eigenschaften, welche für alle Elemente gleich sind (i.e. der Name der Strasse) in der Relation zu speichern und nicht in jedem einzelnen Element. Allerdings hat sich herausgestellt (bzw. war schon vorher klar), dass das Eintragen bzw. Auswerten einfacher ist, wenn die Daten redundant gespeichert werden. Relation vs. Gebäude einzeln taggen ist also sowas wie Theorie vs. Praxis. Theoretisch sind Relationen 'schöner', praktisch aber sehr kompliziert. Der 'Schaden' durch Tippfehler ist daher wahrscheinlich kleiner, als der 'Schaden' durch kaputte Relationen. Sehr schön zusammengefaßt, danke! So langsam dämmert es mir auch, daß die Relation, obwohl sie wie oben beschrieben die theoretisch saubere Methode, praktisch wohl doch eher hinderlich ist. Was mir weitere Schmerzen nimmt ist der Gedanke von Flo, daß natürlich ein Konverter dies Informationen wieder aggregieren kann und damit die Redundanz entfernen. Insofern werde ich es wohl nun auch so tun wie alle: Adresstag an jedes Haus. Es wäre IMHO *sehr* hilfreich, wenn diese Überlegungen mal im Wiki dokumentiert würden. Wenn sich absolut keiner findet, würde ich das notfalls auch machen. Dann kann man da endlcih mal auf eine Quelle verweisen und nicht auf eine Seite wie das Karlsruher Schema, was einen dann doch eher ratlos hinterläßt. Gruss, Thomas 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] Zum 1000. mal - Hausnummern und Straße nnamen?
Sven Geggus wrote: Tobias Knerr o...@tobias-knerr.de wrote: Vor allem hat die Relation ja keinen praktischen Vorteil! Sie ist, je nach Software, sogar umständlicher auszuwerten; sie verteilt die History-Information einer Adresse auf unterschiedliche Objekte (das Haus, die Relation und den Way); sie erhöht gerade bei langen Straßen die Wahrscheinlichkeit von Bearbeitungskonflikten; sie vergrößert den Unterschied zu anderen Ausprägungen von Adressen (nicht alles basiert auf Straßennamen, es gibt z.B. auch Block-bezogene Adressen); ... +1 OK, gute Gründe dagegen, danke! Die associatedStreet-Relation ist einer der Fälle, wo man sich und anderen mit abstrakten Prinzipien (Redundanzvermeidung), die bei näherer Betrachtung in dem jeweiligen Anwendungsfall gar nicht von Belang sind, das Leben nur unnötig schwer macht. Meine Meinung jedenfalls. Das war übrigens einer der Gründe weshalb wir uns damals beim Hausnummernworkshop eher gegen die Relation entschieden haben. Oh, sowas gab's mal? Gibt es dazu vielleicht soewtas wie ein Ergebnisprotokoll, damit Leute wie ich das nachlesen (und finden) können? Der OSM Inspektor berücksichtigt diese jedenfalls auch nicht. OK, das ist nun wieder kein Grund, den könnte man fixen ;) 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] Zum 1000. mal - Hausnummern und Straße nnamen?
Florian Lohoff wrote: On Fri, Jul 16, 2010 at 03:34:12PM +0200, Nils Faerber wrote: Die associatedStreet relation ist kaputt. Sie ist definiert das sie nur EINE Straße beinhalten darf. Das Problem dabei ist das wir Wo ist das so definiert? http://wiki.openstreetmap.org/wiki/Relation:associatedStreet Way/node RoleRecurrence Comment Way street one The associated street Node Area house one or more One or more house numbers (use house in tagging but in parsing also allow: addr:houselink, address ) OK, nicht gesehen - damit ist das wirklicher Schwachsinn. Schade... Gibt es dazu eine Begründung? Nur aus Interesse... Technisch wäre es doch kein Problem, einer Realtion mehrere way-Schnipsel zuzuteilen? Also ich habe in JOSM zumindest machen können... Wähle ich dann meine Straßenrelation an, werden brav alle Mitglieder markiert - alles Wegteile und alle Häuser, die ich da mit reingeworfen habe. Ich sehe auch gar keinen Sinn darin, daß man nur einen Way in eine associatedStreet stecken können soll. Das nur eine Straße im Sinne von ein Stra0enname drin sein darf, ja, das macht Sinn, klar, denn man will ja in einer Relation eben alle Teile die zu diesem Straßenzug gehören zusammenfassen. Oder bin ich hier irgendwie auf dem falschen Dampfer? Nein - aber sie ist anders definiert - Das JOSM alles zulaesst steckt ja in der Natur der sache - OSM ist ziemlich liberal - da kann man erstmal alles reinstecken. :) Das wäre dann wirklich vollkommen doof, ja, und auch nicht mehr praktikabel. Ich halte 1) fuer zu unklar und nicht eindeutig und 3) fuer viel zu komplex das Joe Mapper damit klar kommt. Hmm... das Millionen Fliegen Argument hat mich noch nie überzeugt ;) Das Problem ist das wenn man es zu kompliziert macht das dann Joe Mapper entweder es bleiben laesst (schlecht) oder nur inkonsistente oder falsche daten produziert (noch schlechter). Man koennte man eine auswertung machen wieviele mapper ueberhaupt schonmal eine relation angefasst haben. Relationen sind nach wie vor fuer viele ein Ding an das sie sich nicht ran trauen. Zur sehe ich auch wirklich ein großes Problem in den entstehenden Konflikten, die die Werkzeuge, wie JOSM, nicht sinnvoll darstellen können und dann auch entsprechend falsch von Leute aufgelöst werden. Das scheint wohl wirklich ein Problem zu sein. auch ist mir schon ein paar mal aufgefallen, daß wenn ich Nodes eines Objektes einer Relation anfasse, ich fast immer Konflikte bekomme, obwohl da keine sind. Solange soetwas nicht für den Benutzer in guter Art und Weise lösbar ist, ist das in der Tat eine nicht zu präferierende Lösung - leider. Obwohl ich es nach wie vor von der Abstraktion her für deutlich besser halte ;) Anders als im Linux Kernel ist die mapper clientel nicht unbedingt voellig IT oder Technikaffin. Nuja - man gewöhnt sich an allem ;) Flo 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] Zum 1000. mal - Hausnummern und Straße nnamen?
Am 16.07.2010 18:26, schrieb Bernd Wurst: Am Freitag 16 Juli 2010, 15:44:39 schrieb Nils Faerber: Das war übrigens einer der Gründe weshalb wir uns damals beim Hausnummernworkshop eher gegen die Relation entschieden haben. Oh, sowas gab's mal? Gibt es dazu vielleicht soewtas wie ein Ergebnisprotokoll, damit Leute wie ich das nachlesen (und finden) können? http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Hmm... na prima. Die Seite ist ja bekannt und leicht zu finden, doch da steht auch noch die associatedStreet Relation drin und nirgends erwähnt, daß dies depricated sei, also im Sinne von man hat sich dagegen entschieden. Das war eben auch die Seite die mich so verwirrt hatte. Was man für vglw. Neulinge wie mich braucht ist eher ein Kochrezept und nicht eine Auflistung *aller* Möglichkeiten. Darauf kann man ja gerne verweisen, aber es sollte eine Anleitung geben, die recht klare Vorgaben macht. Oder gibt es sowas? Gruß, Bernd Viele Grüße nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 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] Zum 1000. mal - Hausnummern und Straße nnamen?
Am 16.07.2010 18:44, schrieb M∡rtin Koppenhoefer: Am 16. Juli 2010 15:52 schrieb Nils Faerber nils.faer...@kernelconcepts.de: auch ist mir schon ein paar mal aufgefallen, daß wenn ich Nodes eines Objektes einer Relation anfasse, ich fast immer Konflikte bekomme, obwohl da keine sind. kommt das evtl. daher, dass Du beim Editieren einzelner Elemente, die in einer Relation stecken, den Relationen Editor mit dieser Relation offen hast? Das ist bei mir gelegentlich der Grund, und ich weiss dann manchmal nicht, ob ich lieber meine oder deren Version nehmen soll ;-) Ne, eigentlich nicht... Alles andere ist zu und ich schubse nur ein paar Nodes durch die Gegend. Ah, Moment, ich glaube mir dämmert da etwas... Was passiert, wenn ich einem Way der in einer Relation steckt einen Node hinzufüge? Landet der Neue automatisch mit in der Relation? Wenn nein, hätte man da direkt schon mindestens eines der Probleme. Nuja, zumindest für die Hausnummern habe ich es eingesehen und werde wohl wohl oder übel die alle Tags an jedes Haus variante nehmen. Gruß Martin Viele Grüße nils -- kernel concepts GbR Tel: +49-271-771091-12 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 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
[Talk-de] Wayfinder Linux? Spielt da schon jemand?
Hallo! Nachdem der Wayfinder Kram freigegeben wurde und da wohl auch schon rudimentärer OSM Support drin ist wäre es natürlich interessant, das Teil mal in Aktion zu sehen. Mich interessiert vor allem der Linux basirte Teil und dort vor allem Clients - im Zweifelsfall auch Android. Spielt damit schon jemand hier herum? Wenn ja, mit welchem Ergebnis? 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] ImportOSM2sqlite
Am 21.07.2011 02:05, schrieb Johann H. Addicks: Klaus Engelbertz hat in Perl etwas gebaut, was mit wenig Abhängigkeiten auskommt: utf8, IO, Switch, DBI und natürlich sqlite. http://www.reisenetzwerk.net/importosm2sqlite/ (klar, es geht natürlich weniger als mit PostgresCo. Aber ohne JavaCo kann man da vielleicht auch embedded was mit anfangen.) Dann sollte man an der Stelle vielleicht auch nochmal Spatialite erwähnen: http://www.gaia-gis.it/spatialite/ Das ist das Äquivalent zu PostGIS nur auf SQLite statt Postgres aufsetzend. Spatialite kommt auch direkt mit einem eigenen OSM Import Tool und ist, würde ich sagen, auch absolut embedded einsetzbar. -jha- 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
[Talk-de] Digitalradio.de - Karte ohne Attributierung?
Hallo! Hmm... mir ist eben aufgefallen, daß die Ausstrahlungskarte hier: http://www.digitalradio.de/index.php/digitale-radioprogramme verdächtig nach einer OSM basierten Karte aussieht. Wenn dem so ist, dann haben die leider die Attributierung an OSM vergessen, da stehen nur zwei Firmen drunter. Müßte da dann nicht auch ein Hinweis auf OSM stehen? Was macht man da am besten? 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] Digitalradio.de - Karte ohne Attributierung?
Moin! Am 02.08.2011 00:34, schrieb Stephan Knauss: On 02.08.2011 00:05, Nils Faerber wrote: Hmm... mir ist eben aufgefallen, daß die Ausstrahlungskarte hier: http://www.digitalradio.de/index.php/digitale-radioprogramme verdächtig nach einer OSM basierten Karte aussieht. Wenn dem so ist, dann haben die leider die Attributierung an OSM vergessen, da stehen nur zwei Firmen drunter. Müßte da dann nicht auch ein Hinweis auf OSM stehen? Was macht man da am besten? Schlimmer noch: Es werden die Tiles vom Hauptserver gezogen. Am besten eine freundliche email, gratulieren dass sie die Karte nehmen. Freundlich darum bitten einen anderen Tileserver zu verwenden, z.B. mapquest. Und dann noch bitten auch die Quelle der Karte zu nennen. Das mit dem Tileserver verstehe ich nicht - entschuldigt, aber damit habe ich mich noch nicht so recht beschäftigt. Wo ist da das Problem bzw. was ist der Vorteil, den anderen Server zu verwenden? Und Mapquest ist doch ein kommerzieller Dienst, wenn ich das richtig sehe? Das die Digitalreadio'ler OSM verwenden ist doch gut, wenn sie es richtig attributieren würden. Warum sollte man die also in die Arme eine kommerziellen Dienstes schicken? Machst du das? Mache ich gerne. Nur bräuchte ich ggf. noch etwas Info zu dme Serverproblem, da ich denen das dann gerne erlkären können wollte ;) http://www.digitalradio.de/index.php/kontakt-footer Vielen Dank! Stephan 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] Digitalradio.de - Karte ohne Attributierung?
Am 02.08.2011 11:06, schrieb M∡rtin Koppenhoefer: Schlimmer noch: Es werden die Tiles vom Hauptserver gezogen. Das mit dem Tileserver verstehe ich nicht - entschuldigt, aber damit habe ich mich noch nicht so recht beschäftigt. Wo ist da das Problem bzw. was ist der Vorteil, den anderen Server zu verwenden? der Tileserver auf OSM.org ist ein Service für die Mapper und eine Demo, was in unseren Daten steckt. Die Nutzungsbedingungen sind hier: http://wiki.openstreetmap.org/wiki/Tile_usage_policy Für private Seiten mit wenigen Zugriffen kann man den Dienst nutzen, aber wenn man eine professionelle Seite mit vielen Zugriffen betreibt, darf man das nicht mehr. Dann sollte man entweder einen Tileserver von Dritten benutzen (mapquest erlaubt z.B. die Nutzung, daher der Hinweis darauf), oder einen eigenen Server aufsetzen. Ah, verstehe, OK. Und Mapquest ist doch ein kommerzieller Dienst, wenn ich das richtig sehe? die Nutzung ist kostenlos, betrieben wird das von AOL. Aber kein OSM mehr, oder? Das fände ich dann etwas über das Ziel hinaus geschossen. es ist doch toll, wenn sie OSM weiter verwendeten. Ich würde mal tippen, daß die den Tile-Server verwenden liegt daran, daß sie keinen eigenen aufsetzen wollten. Gäbe es noch OSM basierte Alternativen? Andererseits wenn sie schon ihr Empfangsgebiete-Overlay selbst machen, dann sollten sie doch in der Lage sein Tiles zu rendern? Na gut, ich weise sie mal drauf hin, mal sehen was passiert. 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] Digitalradio.de - Karte ohne Attributierung?
Am 02.08.2011 13:52, schrieb Bernd Wurst: Am 02.08.2011 10:59, schrieb Nils Faerber: Das die Digitalreadio'ler OSM verwenden ist doch gut, wenn sie es richtig attributieren würden. Warum sollte man die also in die Arme eine kommerziellen Dienstes schicken? Das kritische dabei ist, dass die bereits in den Armen eines kommerziellen Dienstleisters sind, siehe die dort befindliche Attributierung. Vermutlich hat also dieser Dienstleister seine Aufgabe drastisch erleichtert indem er einfach OSM-Daten vom OSM-Tileserver einbindet. Wie Frederik schon sagt gibt es im OSM-Umfeld einige Dienstleister die wissen wie das mit den Tiles und der Attributierung gemacht werden kann. Daher sind sie momentan wohl nur beim falschen Dienstleister. Ja, schaut so aus... Teile deren Webseite (des Dienstleisters) sind auch 404 - echt Profis ;) Ich habe sie mal vorsichtig darauf aufmerksam gemacht, mit CC an alle Beteiligten - den Dienstleister eingeschlossen. Mal sehen was passiert... Also mindestens die Attributierung an OSM müssen sie noch einbauen, da würde ich ja echt zickig werden. Die Last auf den Tile-Server kann ich nicht beurteilen, aber professionell betrachtet, sollten sie den OSM Tile Server wohl wirklich nicht verwenden. Ich halte Euch auf dem Laufenden, wenn sie sich melden! Danke! Gruß, Bernd 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] Digitalradio.de - Karte ohne Attributierung?
Am 02.08.2011 17:04, schrieb Sven Geggus: Nils Faerber nils.faer...@kernelconcepts.de wrote: Ich habe sie mal vorsichtig darauf aufmerksam gemacht, mit CC an alle Beteiligten - den Dienstleister eingeschlossen. Mal sehen was passiert... Powered by con terra, esri OpenStreetMap Zumindest das ging wohl relativ schnell. Tse ;) Aber nichtmal irgendwie eine Antwortmail an mich schreiben - Nasen... Nuja, immerhin etwas... Aber nachhaken werde ich da trotzdem nochmal ;) Vorsichtig und freundlich versteht sich...und erstmal für die Attributierung bedankend. 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] OSM auf BILD.de
Am 17.08.2011 23:17, schrieb Kolossos: Stepmap.de sehe ich genauso kritisch wie Sven als klaren Lizenzverstoß. Hmm... Da hätte ich dann mal eine Frage bzgl. der CC-by-SA Lizenz... Jetzt ist die OSM Karte selbst recht klar CC-by-SA und die Untersagung der gewerblichen Nutzung etc. ein Verstoß degegen, keine Frage. Aber deren dargestellte Karte trägt ja noch ein Overlay, welches Informationen Dritter, also nicht OSM, darstelt.. Was passiert dann lizenztechnisch mit der gemeinsamen Darstellung? Wird dann beides zusamen auch automatisch CC-by-SA? Oder könnte man gutwillig die Einschränkung vieleicht nur auf deren kommerzielles Overlay beziehen bzw. annehmen, daß sie das meinten, es nur schlecht formuliert haben? Ich kenne mihc da nur ansatzweise mit der GPL aus, wo der Fall recht klar wäre... Grüße Tim Viele Grüße nils faerber Am 17.08.2011 10:33, schrieb Sven Geggus: Bodo Meissnerb...@bodo-m.de wrote: Das scheint aber eine Leistung von Stepmap zu sein. Der Link bei der Bildzeitung führt zu dieser Seite. http://www.stepmap.de/karte/bild-drei-maedchen-tot-im-wald-162049 Hm, die Nutzungsbedingungen unter http://www.stepmap.de/hilfe/editorinfo sind meines Erachtens aber ein Verstoß gegen die in der Attributtierung genannte CC-by-SA Lizenz. Von wegen gewerbliche Nutzung nur eingeschränkt erlaubt und so. Natürlich darf man OSM Karten gewerblich nutzen, ausdrucken und abspeichern. Gruss Sven -- 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
[Talk-de] Hausnummer taggen für Garmin?
Hi! Ich habe mir jetzt endlich mal ein Navi zugelegt, daß auch OSM gemachte Karten frißt - ein Garmin Nüvi 205T, für 40€ in der Bucht geschossen, dachte ich probier's mal. Das klappt auch soweit einwandfrei! Karte wird sauber dargestellt (cool!) und ich kann prinzipiell auch Straßen suchen, doch die Hausnummern klappen gar nicht - probiert auf einer Straße, wo ich die mal getagged hatte (und die Garmin Software läßt es irgendwie nicht zu, nur in eine Straße ohne Nummer zu navigieren, auch doof). Ich hatte seinerzeit die Hausnummern an die Gebäude gemacht, samt Straßenname. Das wird aber wohl von mkgmap nicht ausgewertet. Daher die Frage, wo muß ich die Hausnummern hintaggen, damit sowas wie mkgmap das findet? Nodes auf dem Way damit taggen? Dann wird aber rechts/links etwas schwierig zu unterscheiden... was mir auch noch rel. egal wäre, im Notfall... Ansonsten kann ich das ad-hoc mal empfehlen!Bin mal sehr gespannt, wie weit das etwas taugt. Kann ich bei Interesse gerne auch mal hier weiter berichten. Was mir spontan noch auffällt ist, daß der Bidlschirmmarker (also die Positionsmarke auf dem Display des Navi) nicht wie bei den Originalkarten auf der Straße sitzt, sondern etwas daneben. Mal sehen wie sich das verhält wenn ich fahre, noch sitze ich im Büro (direkt an der Straße). 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] Hausnummer taggen für Garmin?
Am 07.10.2011 14:18, schrieb Henning Scholland: Trag die Hausnummern so ein, wie es sich gehört ;) Äh, ja, und das wäre? Mir ist zur Zeit immernoch kein einheitliches Schema bekannt, das verwendet werden *soll*. Vorschläge gab es, Karlsruher Schema war das AFAIK: http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema Da steht aber bis heute nur Proposed dran. Die Garmnkarten auf OSM-Basis können damit derzeit nichts anfangen, da das Format an der Stelle noch nicht verstanden ist. Mit Hausnummer in den Häusern? Das kann ich ja sogar noch halbwegs nachvollziehen, da das sicherlich nicht ganz einfach zu parsen und umzusetzen ist - da muß das Tool ja wieder den Zusammenhang zwischen Adress-Tags im Haus und der Straße finden - das kann schon unlustig sein. Und welches Format ist da noch nicht verstanden? Wie Garmin die Nummern kodiert oder hat mkgmap noch nicht verstanden wie es in OSM kodiert ist? 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] Hausnummer taggen für Garmin?
Am 07.10.2011 16:26, schrieb Henning Scholland: Die Daten aus dem OSM-Format herauszulesen ist kein Problem. Ob die Adresse nun an einem Polygon oder an einem Node hängt ist da uninteressant. Die Hürde ist das Garmin-Format. Hmm...nja...ich weiß nicht... also der Garmin Teil ist klar und habe ich jetzt auch verstanden - wie die die Straßen/Hausnummernsuche machen ist noch unklar und daher klappt das noch (!) nicht. OK. Ist zwar schade, aber nuja... Der Rest sieht dennoch sehr cool aus und man kann auch zu einem Punkt den man auf der Karte antippt navigieren lassen. Wenn man also selbst weiß wo das Ziel liegt, dann ist das nicht so tragisch. Die Herstellung der Verbindung von Häuser-Polygonen zu der Straße stelle ich mir allerdings nach wie vor etwas schwierig vor. Die einzige Verbindung zwischen dem Way und dem Haus-Polygon ist ja der Name der Straße, d.h. man muß das einen String-Match von Straßenname zu dem Namen des Haus-Polygons. Das kann beliebig ungenau sein. Und was passiert dann, wenn bspw. ein Haus in einer Straßenschleife liegt und gleich weit von beiden Schenkeln entfernt? Da ist es dann nicht eindeutig, zu welcher Schenkelseite man das dann zuordnen sollte? Das wiederum wäre dann eindeutig, wenn man das Haus oder zumindest dessen Nummer am Way markieren würde (ja ja, ich weiß das taugt auch nix). Wie löst man das dann am besten auf? Für ein Navi möchte man ja eigentlich die Hausnummern entlang des Ways wissen, damit man dahin fahren kann. Wo das Haus ist und wie es aussieht ist da vollkommen irrelevant. Hier würde eigentlich die Methode mit dem Nummern-Way (ach, wie hieß das nochmal - diese automatischen Hausnummern mit Start- und Endenummer) besser passen. Die könnte man dann links und rechts direkt an die Straße machen. Doch auch die haben dann keinen direkten Bezug zur Straße, erst über zusätzliche Tags oder Relationen. Jedes mal wenn darüber nachdenke komme ich eigentlich zu dem Schluß, daß für Sinnvolle Navis noch irgendwie eine eindeutige Verbindung von der Straße/Way zu dem Haus existieren müßte... Ein Tipfehler im Namensstring oder eine andere Schreibweise (-Str. statt -Strasse oder -Straße) und schon ist der Match dahin... Gut - aber das war gar nicht mein Thema hier und ich möchte das auch keinesfalls nochmal aufkochen ;) Garmin Adresssuche auf Hausnummernebene: Geht zur Zeit nicht. Das war erstmal was ich wissen wollte. Vielen Dank! 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] DFS verwendet OSM
Am 08.10.2011 10:03, schrieb Carsten Schwede: Hallo, Moin! habe ich die Woche gefunden, die Deutsche Flugsicherung verwendet OSM in ihrem Life-Flugbewegungsprogramm. http://www.dfs.de/dfs/internet_2008/module/fliegen_und_umwelt/deutsch/fliegen_und_umwelt/flugverlaeufe/index.html (Flughafen anklicken und dann rechts auf STANLY_Track starten, ist ein Java Webstart- Programm) Dies ans ich ist ja schon spannend - solcherlei Meldungen hatten wir ja jetzt schon ein paar mal. Gibt es eigentlich schon eine Sammlung von solchen Referenzen, vielleicht im Wiki? Wenn nicht, dann sollten wir das unbedingt mal anfangen. Ich denke es ist gut, auf die Verwendung der Daten verweisen zu können. 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! 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
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
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 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
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 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 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] Entwicklung eines Navi für OSM Daten
Am 19.10.2011 19:51, schrieb hannes:
Aus dem Thema:
Re: [Talk-de] Mehr OpenStreetMap Softwareentwicklung und
die?Engineering WG
Am 17.10.2011 16:26, schrieb Sven Geggus:
Nils Faerbernils.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
Ich hab mal ein neues Thema angefangen weil im alten Thema über
verschiedene Dinge diskutiert wurde und wir Kai sein Thema geklaut
haben. Tschuldigung Kai!
:)
Weiter oben im alten Thema wurde das Problem mit den hohen
Einstiegshürden aufgezeigt, das sehe ich genau so. Die Einarbeitungszeit
um sich in die Gedanken eines anderen einzuarbeiten ist einfach zu lang.
Es ist doch schade, da macht sich jemand an die Arbeit und schreibt
z.B. ein Navi, da geht dann mehr Zeit rein als gedacht und die Arbeit
wird eingestellt. Die bis dahin geleisteten Mühen sind verloren, weil es
zu aufwändig für andere ist sich einzuarbeiten.
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.
Die Modularisierung an sich ist schon ein großer Schritt vorwärts und
IMHO fast wichtiger als Doku dazu. Wenn die Module klar abstrahiert sind
und gute APIs haben, dann sollte automatisch erzeugte API Doku jedem
Neuling schnell einen guten Einstieg ermöglichen.
*** für Neulinge dokumentiert sein. Ich meine grundsätzliche Dinge
sollten erklärt werden.
Beispiel:
Ich habe mich mal mit einem Router auf OSM-Daten beschäftigt:
typedef struct _Cross {
struct _Way *a[MAXWAYPERCROSS];
gfloat lon,lat;
gint64 id;
guchar flag;
} CrossT;
typedef struct _Way {
guchar flag;
gchar type;
GList *glp; //g list pointer
gint anznd;
guint64 id;
//gfloat length;
CrossT *from, *to;
//gchar name[100];
//gchar ref[100];
gchar *name;
//gchar *ref;
//struct _koords {gint64 nd; gfloat lon, lat;} k [MAXND];
gint64 nd[MAXND];
} WayT;
Alles klar? Wohl kaum. Dabei sind das die wichtigsten Strukturen.
/*
Der Router arbeitet auf einer Karte die aus Wegen besteht, diese haben
eine Länge, einen Namen, eine Geschwindigkeitsbegrenzung etc. Die Wege
sind am Anfang und am Ende an Kreuzungen angeschlossen. Die Kreuzungen
enthalten Zeiger auf die angeschlossenen Straßen/Straßensegmente(Way).
*/
Jetzt ist es klarer - vermute ich. Wenn man dann noch den
Standartalgorithmus zum routen kennt ist es fast klar wie das Programm
aussieht.
Entweder so, was aber meist etwas mehr Arbeit ist, oder eben API Doku
mit einem Doku Tool wie Doxygen oder GtkDoc erzeugen. Das ist dann recht
einfach und das macht auch der Entwickler des APIs sicherlich gerne mit.
*** 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.
Wenn es möglich ist, auf jeden Fall, ja!
Kann das funktionieren? Keine Ahnung! Aber ich würde es so versuchen.
Wie ist es, wollen wir versuchen ein Navi herzustellen? Hat jemand Lust
mitzumachen?
Ja!
Zeit ist begrenzt, aber ich kann von mir aus garantieren, daß ich das
sehr nahe verfolgen werde. Ob und wieviel Code ich dazu beitragen
könnte, kann ich so kaum abschätzen.
Wie wollen wir starten? Fangen wir von vorne an und arbeiten Teile von
monav oder gosmore ein oder bauen wir auf monav auf oder...
Keines der Dinger ist IMHO modular genug.
Wir sollten uns zuerst darauf konzentrien, Module zu beschaffen, zu
borgen oder die Entwickler der anderen Lösungen zu übrzeugen,
interessante Teile in einer Modulform zur Verfügung zu stellen.
Die wichtigsten Module/Teile haben wir ja schon hinreichend diskutiert:
1. Datenhaltung - also die Kartendaten möglichst effizient speichern und
darauf zugreifen
2. Map Rendering - aber so, daß es möglichst GUI Toolkit frei ist. Cairo
ist da vielleicht ein guter Ansatz, da man einen Cairo Canvas in fast
alle Toolkits irgendwie einbinden kann und die Renderingqualität einfach
gut ist.
3. Routing - muß auf den Kartendaten arbeiten und eine Schnittstelle zum
Map Rendering bieten, dazu noch die üblichen Funktionen für
Fahranweisungen etc. Letzteres sollte nur eine definierte Ausgabe
[Talk-de] Heise: Google Maps wird kostenpflichtig
Na, das ist doch unsere Chance, das für OSM Werbung auszuschlachten? http://www.heise.de/newsticker/meldung/Schluss-mit-gratis-Google-verlangt-Geld-fuer-Kartennutzung-1368176.html Haben wir eine Presse-Abteilung? Dazu wäre eine schöne Pressemitteilung gut, die heraustreicht, daß die OpenStreetMap Nutzung weiterhin kostenfrei bleibt ;) Das müßte jetzt nur *schnell* passieren. Viele Grüße nils -- kernel concepts GmbH Tel: +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] Heise: Google Maps wird kostenpflichtig
Am 28.10.2011 16:13, schrieb Simon Poole: Das ist eine Nachricht? Das Google neuerdings für das Geld verlangt, was OSM gar nicht erlaubt (massenweise Tiles downloaden)? Äh - gilt das kostepflichtig nicht auch (bzw. insbesondere) für die Einbindung der GMaps Karten in die eigene Webseiten? Das ist doch durchaus etwas, was OSM erlaubt, oder? Simon Viele Grüße nils Am 28.10.2011 14:42, schrieb Nils Faerber: Na, das ist doch unsere Chance, das für OSM Werbung auszuschlachten? http://www.heise.de/newsticker/meldung/Schluss-mit-gratis-Google-verlangt-Geld-fuer-Kartennutzung-1368176.html Haben wir eine Presse-Abteilung? Dazu wäre eine schöne Pressemitteilung gut, die heraustreicht, daß die OpenStreetMap Nutzung weiterhin kostenfrei bleibt ;) Das müßte jetzt nur *schnell* passieren. Viele Grüße nils -- kernel concepts GmbH Tel: +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] Heise: Google Maps wird kostenpflichtig
Am 28.10.2011 16:27, schrieb Hartmut Holzgraefe: On 10/28/2011 02:42 PM, Nils Faerber wrote: Na, das ist doch unsere Chance, das für OSM Werbung auszuschlachten? http://www.heise.de/newsticker/meldung/Schluss-mit-gratis-Google-verlangt-Geld-fuer-Kartennutzung-1368176.html was ist daran neu? Limit vorher 100K (AFAIR) pro Tag, nun 25K Preise vorher auf Anfrage (AFAIR), nun konkret veröffentlicht Nothing to see here, move along Oh, das war mir bspw. nicht bewußt klar. Nun gut... Viele Grüße nils -- kernel concepts GmbH Tel: +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] Night of the living maps 07.02.2012 - Globale virtuelle Mapping Party
Am 27.01.2012 09:33, schrieb Matthias Meißer: Hallo Community, Hallo! schon seit einigen Wochen ist eine Idee für eine Aktion gereift, die wir heute vorstellen wollen: www.nightofthelivingmaps.org Am Mittwoch, den 07.02.2012 wollen wir probieren gemeinsam eine ganze Nacht lang für unser Projekt Luftbilder abzupausen und zwar genau dort, wo wir bisher noch schwach aufgestellt sind: im ländlichen Raum, jenseits der großen Städte eures Bundeslandes. Bisher gibt es leider nicht so viele größere Events bei OSM, vielleicht können wir das mit dieser LAN-Party ja ändern? Nette Idee! Daher wollen wir euch bitten, doch mal bei euren lokalen Mappern zu fragen, ob ihr nicht selber solch eine kleine lokale Party auf die Beine stellen wollt. Das ist nicht viel Aufwand und in der Regel kriegt man über Unis/Hackerspaces/Stadt/... kostenlos auch einen Raum. Der FOSSGIS hat ein wenig Geld bereitgestellt, damit ihr euch mit ein paar Snacks versorgen könnt und mit Kaffee das ganze auch durchhaltet ;) Für den Raum Siegen-Witttgenstein, Olpe, Wenden, Gummersbach etc. kann soetwas auf jeden Fall in den Räumlichkeiten des Hackerspace Siegen stattfinden! http://wiki.hasi.it/ Interessierte die den Raum dann nutzen möchten sollten sich nur vorher formlos anmelden, damit auch jemand vom Hackerspace dort ist und öffnet ;) Anmeldungen können gerne an mich gehen, ich organisiere das dann. Willkommen wäre es auf jeden Fall! Eure Edits ladet bitte mit einem Kommentar, der mit #notlm ... beginnt hoch, damit wir da später ein schönes Video davon machen können und auch mal beobachten können, wo gerade gearbeitet wird. Auch wenn es nicht unmittelbares Ziel ist, für OSM zu werben und Neulinge zu rekrutieren (wir wollen ja was schaffen ;)), wäre es natürlich super, wenn ihr probiert das vor Ort bei euch ein wenig bekannt zu machen. Flyer sowie Social Media findet ihr auf der Seite/könnt ihr für alle hier hochladen: http://wiki.openstreetmap.org/wiki/Night_of_the_living_maps/promotion http://www.facebook.com/pages/Night-of-the-living-maps/163865540386200 https://twitter.com/NightOfTheMap Wir würden uns auch sehr freuen, wenn vielleicht der ein oder andere die Wikiseite übersetzen könnte, oder sich vielleicht daran macht Statistiken oder Animationen vorzubereiten. Wir sind uns natürlich bewusst, dass bingen nicht unumstritten ist, dennoch sind wir der Meinung, dass in diesem Fall die Vorteile überwiegen (siehe Hinweise im Wiki). Eine definitive Antwort, ob das gut oder schlecht ist, scheint es bisher nicht zu geben und die wird es besten Falls, wohl erst in ein paar Jahren geben, wenn wir zurückblicken. Also lasst uns einfach das machen, was wir am besten können: Zusammen eine richtig gute Karte erstellen :) Gruß Matthias (user:!i!) Viele Grüße nils -- kernel concepts GmbH Tel: +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
