Re: [Talk-de] andnav.org - Android Navigation System
Hi, Matthias Brandt schrieb: > Ich programmiere gerade einen OSM Editor für Android und werde in den > nächsten Wochen eine Testversion online stellen. Cool! Lass hören, wenn Du was zum Ausprobieren hast! Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] andnav.org - Android Navigation System
Hi, On Sun, Dec 21, 2008 at 05:55, Nicolas Gramlich wrote: > auf was genau beziehst du dich mit "Lade-Geschwindigkeit" ? Ich meine die Zeit zwischen Drücken des Zoom-Buttons und Anzeigen der neuen Tiles. Das dauert bei mir über WLAN zwischen 5 und 20 Sekunden und damit 2-3x solange wie Google Maps für Android. > Grade heute hab ich ein neues Feature eingebaut, welches > ähnlich wie die SlippyMaps die Teile eines ZoomLevels aus > den des höhergelegenen interpoliert: > > http://www.andnav.org/index.php/component/content/article/37-about-andnav2/95-andnav2-new-maptile-interpolation Cool. > Das sollte die wahrgenommene "Lade-Geschwindigkeit" der > Maptiles deutlich verringern. (Falls du das meintest). Ja, das meinte ich. Zusätzlich zur wahrgenommenen Latenz ist aber auch die echte Latenz ziemlich hoch. Das Laden in Deinem Video geht viel schneller als bei mir. Woher kommen denn die Kacheln? Auch auf dem Desktop ist www.openstreetmap.org bei mir viel langsamer als Google Maps. Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] andnav.org - Android Navigation System
2008/12/19 Sven Geggus > Michael Forster wrote: > > Was mich persönlich viel mehr interessieren würde wäre ein mobiler > Editor, > > speziell für POIs. Direkt mit Hochlademöglichkeit auf den OSM-Server oder > > zum Importieren in JOSM. > > osm2go? Davon gibt's aber keine Android-Version, oder? Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] andnav.org - Android Navigation System
Hi, Gefällt mir ganz gut. Da kann was draus werden. Leider läuft es bei mir noch sehr instabil. Auch die Lade-Geschwindigkeit lässt zu wünschen übrig, sogar über Wi-Fi. Aber da steckt viel Potential drin. Was mich persönlich viel mehr interessieren würde wäre ein mobiler Editor, speziell für POIs. Direkt mit Hochlademöglichkeit auf den OSM-Server oder zum Importieren in JOSM. Mike On Fri, Dec 19, 2008 at 18:26, FrauSuhrbier wrote: > Das Handy gibt es zwar in D noch nicht zu kaufen, aber schon 2 SW > Versionen um mit OSM Daten darauf zu navigieren. :=) > > Ein frohes Weihnachtsfest > und viele km (zum Mappen!) > Jürgen > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google's neue Terms of Service
Hi, 2008/11/27 Chris66 <[EMAIL PROTECTED]> > > Lasst mich vorsichtshalber den Disclaimer vorrausschicken, dass ich > > Google-Mitarbeiter bin. Ich habe allerdings absolut gar nichts mit dem > > Google-Maps-(API) Team zu tun und beteilige mich an OSM ausschliesslich > > privat. > > Cool :-) > > Es wäre mal interessant zu wissen, ob Google mit dem Datenlieferanten > (z.Zt. TeleAtlas) Exclusivverträge hat. Ich vermute mal ja, denn sonst > hätte doch Google bei Gegenden die TeleAtlas nicht hat, schon längst > auf die OSM Daten zurückgegriffen.. Wie gesagt habe ich nichts mit dem Maps-Team zu tun. Das heisst insbesondere, dass ich nicht öffentlich über solche internen Informationen sprechen sollte. Ich würde mich selbst über eine engere Kooperation Google/OSM freuen, aber das ist meine private Aussage. Unabhängig von Google glaube ich, dass die Lizenz von OSM für Unternehmen ein großes Problem darstellt, weil sie effektiv die Zusammenführung von freien und nicht freien Daten verhindert. Mike P.S.: Alle Aussagen sind meine und nicht die meines Arbeitgebers ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google's neue Terms of Service
Hi, Siehe unten. Lasst mich vorsichtshalber den Disclaimer vorrausschicken, dass ich Google-Mitarbeiter bin. Ich habe allerdings absolut gar nichts mit dem Google-Maps-(API) Team zu tun und beteilige mich an OSM ausschliesslich privat. Mike On Fri, Nov 14, 2008 at 18:35, Dr. Franz-Josef Behr < [EMAIL PROTECTED]> wrote: > Vielleicht gut für unser Projekt: > > Google's neue TOS, insbesondere 11.1: > > http://code.google.com/apis/maps/terms.html > http://googlegeodevelopers.blogspot.com/2008/11/update-to-google-maps-api-terms-of.html Update to the Google Maps API Terms of Service Posted by Mickey Kataria, Product Manager >From time to time we release updates to the terms of service governing our products. We recently released an updated version of the Google Maps API Terms of Service. Based on feedback from that update, we are releasing a revised version today. The Google Maps API TOS is intended to satisfy several goals: it gives Google the rights needed to operate a service which overlays content on the map, gives us the ability to showcase popular mashup sites, and allows us to index and provide search over Maps API sites so that Google users can find them. What changed and why? A key goal for the November 12th revision was to eliminate a number of unpopular restrictions, including the prohibition on friend finder applications and non-"site" mashups. We also eliminated ambiguity about whether it's OK to use the API w/ password-protected free sites (it is). Additionally, we streamlined the format of the terms, eliminating the need for developers to reference multiple sets of incorporated terms of service, including the Google Terms of Service and the Google Maps Terms of Service to figure out what rights and obligations applied to their use of the Maps API. That format change appears to have called attention to the "License >From You to Google" - section 11 in the November 12th update. That content license has always been part of the Google Maps API Terms of Service, because it is contained in the Google Terms of Service. Both the original and the November 12th updated Terms of Service relied on that provision to ensure Google received a sufficient content license to provide the Maps API service and to promote the service, including by highlighting excellent mashups as we did here. That section does not provide Google a license to all of the content on your Maps API site to use for any purpose, nor is that how we have treated the content from existing Maps API sites that were developed under the terms that existed prior to the November 12th update. Section 11(b), which we initially included in the November 12th update, created a lot of confusion among our API developers who are publishing licensed content. In 11(b) we were trying to be clear that we wanted a broader license from Maps API developers for use of business listings information. However, given the confusion that resulted, we removed that language from today's revision of the terms. Thank you for using the Google Maps API. We look forward to continuing to create great products together with you. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Routen als Relationen mit Punkten (war: API 0.6)
Hi, On Wed, Nov 19, 2008 at 19:13, Christoph Eckert <[EMAIL PROTECTED]> wrote: > > Geordnete Relationen, endlich. IMO extrem wichtig. > > vor allem (schleck) kann man dann routen anhand von Nodes anlegen anstatt > Wege > immer weiter zu segmentieren. finde ich rat-ten-scharf! > Du willst also eine Relation erstellen, die als Members eine geordnete Liste von Wegpunkten hat? Das halte ich nicht für eine gute Idee. Vor allem scheint es mir nicht der Realität zu entsprechen. Wennn ich einer Route folge bewege ich mich schließlich über Wegstücke, anstatt von Punkt zu Punkt zu hüpfen. Die Route aus Wegstückchen zu erstellen trägt mehr Semantik, weil nicht nur angegeben wird, dass die Route zuerst durch A und dann durch B geht, sondern auch auf welchem Weg. Auch das Handling beim Editieren ist einfacher, wenn die Relation Wege enthält. Wenn aus irgendwelchen Gründen ein Wegstück geteilt werden muss, dann ist klar, dass die zwei neuen Teile Member aller Routen sind, in welchen der ursprüngliche Weg Member war. Bei Relationen aus Punkten ist dagegen nicht direkt klar, ob neu eingefügte Punkte automatisch in die Relation mit aufgenommen werden sollen. Ich persönlich finde "zerstückelte" *Wege* nicht problematisch. Wenn verschiedene Teile eines Weges unterschiedliche Bedeutungen haben (Teil einer Route, Teil einer bestimmten Straße, andere Beschränkungen, ...), dann sind das logisch auch zwei unterschiedliche Wege - eben weil sie unterschiedliche Tags haben. Zerstückelte *Straßen* mit Wiederholung der Tags finde ich auch nicht so toll. Dies wäre aber zu lösen, indem man die Straßen(-namen) als Relationen über ihre Wegstücke darstellt. Ich sehe da nicht so viel Unterschied. Ein Straßenname ist auch nur eine besondere Art von Route. Schließlich: Was ist der Unterschied zwischen einer Relation mit geordneten Punkten und einem Weg? Ein solcher enthält ja auch eine geordnete Liste von Punkten. Ich bin kein Fan von "gestapelten" Wegen und eine Punkte-Relation ist dasselbe in grün. Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen Europastraßen wieder zum Le ben erwecken
Hi, 2008/11/15 Doru Julian Bugariu <[EMAIL PROTECTED]> > Wie kann man das "was ist in Deutschland" (besser noch: "in welchem Land > ist dieser Way") anhand von existierenden Daten denn beantworten? > Indem man die Koordinaten mit den Landesgrenzen vergleicht? Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] country node Germany / Deutschland
Ok, lasst mich mal anders fragen: Warum ist dieser Punkt vorhanden? In Natura gibt es den ja auch nicht. Ist das also mehr als eine Darstellungshilfe? Mike 2008/10/29 Marcus Wolschon <[EMAIL PROTECTED]> > Ein Node für das kanonische Zentrum schließt ein Polygon nicht aus. > Oder in diesem Fall eine unvollständige und ungeordnete Liste an > Polygon-Bruchstückchen zum selber zusammen puzzeln. > > Marcus > > 2008/10/29 Michael Forster <[EMAIL PROTECTED]>: > > +1 > > Warum ist Deutschland überhaupt ein Node? Wäre da nicht ein Polygon > > zutreffender?- > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] country node Germany / Deutschland
+1 Warum ist Deutschland überhaupt ein Node? Wäre da nicht ein Polygon zutreffender? Mik 2008/10/29 Florian Lohoff <[EMAIL PROTECTED]> > > Hi, > ich bin beim is_in basteln auf diesen node gestossen: > > > > > > > > > > > > > > > > > ist nicht name=Germany in diesem fall falsch? IMHO sollte da der > lokalisierte > name rein d.h. "Deutschland" und wenn man es ganz richtig macht dann > doch "Bundesrepublik Deutschland" oder? > > Flo > -- > Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 >Those who would give up a little freedom to get a little > security shall soon have neither - Benjamin Franklin > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFJCJPeUaz2rXW+gJcRAoFhAKC6ByQdJv8npMJ4InbT7zTFSNUvYQCfRB7P > WRQqdo3D3F7gZCPtW3brAzg= > =uqR4 > -END PGP SIGNATURE- > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradroute über einen Platz
Hi, 2008/10/22 Karl Eichwalder <[EMAIL PROTECTED]> > Bernd Wurst <[EMAIL PROTECTED]> writes: > > Du hattest eingangs geschrieben, dass es kein dedizierter Weg ist sondern > es > > mehrere potenzielle "Wege" über den Platz gibt. > > Die Logik sagt also doch eher "Die Route geht (irgendwie) über den Platz" > und > > nicht "die Route verläuft so: [...]". > Ich wusst doch, dass mich da noch wer zitieren wird. :-) Ich hatte mich da nicht ganz richtig ausgedrückt. Nein, die Route geht nicht "irgendwie" über den Platz, sondern so ungefähr auf dem kürzesten Weg. Ein großer Teil des Platzes gehört ganz sicher nicht zur Route. Es wird schon eine Idealroute geben. Evenutell zeitabhängig. > Genau. > > Analog zum Straßen-Beispiel wäre es also so, dass du den Teil des > > Platzes, den > > der Radfahrer nutzen kann um irgendwie zu Fortsetzung der Route zu > kommen, > > abtrennen müsstest. Würde ich aber nicht machen. > > Die analogie ist falsch. Es handelt sich eher um so etwas wie pisten in > wüsten oder ski-routen im gebirge. Das, finde ich, ist eine gute Analogie. > Pack etwas wie "virtual=yes layer=-1" hinzu und es ist gut. Also layer=-1 ist IMHO falsch. Das würde semantisch ja "unterirdisch" bedeuten. Das würde ich jetzt wirklich als "für den Render mappen" bezeichnen. > In dezidierten fußgängerzonen würde ich > "highway=footway bicycle=yes" verwenden. Na ja. Am besten halt, was zu den Beschränkungen des Platzes passt... > > Allerdings ist es im Endeffekt doch eine Frage ob wir für Renderer > > mappen. > > Diese frage wird leider auch oft falsch gestellt und noch falscher ;) > beantwortet. Ich habe ein bisschen das Gefühl, ein Teil der Diskussionsteilnehmer hat da eine Art von Paranoia. > Damit ist eigentlich nur gemeint, dass man beispielsweise > kein railway-tag um ein fußballstadion legen darf, nur weil das so schön > nach einem stabilen zaun aussieht. Na, etwas breiter würde ich das schon auslegen. Grundlage des Mappings muss die Semantik sein und nicht das visuelle Erscheinungsbild. Das heißt aber nicht, dass alle Informationen der Datenbank in der Natur sichtbar sein müssen. Wir haben ja auch Grenzen und ähnliche Informationen gespeichert. Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradroute über einen Platz
Hi, 2008/10/19 Tordanik <[EMAIL PROTECTED]> > Bernd Wurst schrieb: > > Entweder ein geeigneter Weg lässt sich algorithmisch finden oder nicht. > Ich > > finde es ist möglich, also muss man keine Fake-Lösungen einbauen. > > Nebenbei: Hat das schon mal jemand algorithmisch gemacht? Das ist algorithmisch ein alter Hut: Im einfachsten Fall kann man den kürzesten Weg (Dijkstra) auf dem Sichtbarkeitsgraphen aller Punkte des Polygons berechnen. Wenn zwei Polygone an einer Seite aneinander grenzen, dann betrachtet man das als ein großes Polygon. Aber die Diskusion läuft schön langsam wieder darauf hinaus, worauf mir die meisten OSM-Diskussionen hinauslaufen zu scheinen: "Wir mappen nicht für Renderer". Dabei ging mir die Frage doch gar nicht darum. Natürlich ist wichtig, dass das ganze irgendwann mal richtig gerendert wird. Aber das war nicht meine Frage. Schon auf der rein logischen Ebene stellt sich doch die Frage wie das zu mappen ist. Es ist eben nicht der ganze Platz Bestandteil der Route, sondern nur der Teil, auf dem die Route verläuft. Damit hat der Teil worüber die Route verläuft eine andere Semantik (etwa den zusätzlichen Namen der Route!). Wenn ein Teil eines Weges andere Eigenschaften hat, dann beginnt man ja auch einen neuen Weg. Und, wenn wir schon über den Renderer reden müssen: Ein Render kann genauso einen Weg ignorieren wie einen Weg über den Platz finden. Dazu müsste man nur den Weg mit einem entsprechenden Tag versehen oder gemeinsam mit dem Polygon in eine Relation für den Platz packen. Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradroute über einen Platz
Hi, Ich schrieb: > Wie würdet ihr eine Fahrradroute mappen, die über einen (recht großen, > verwinkelten) Platz führt? > Hier übrigens zur Veranschaulichung die Situation in JOSM mit den beiden Optionen. Die Relation ist in Rot markiert. Mike (Reduzierte Qualiät wegen Größenbeschränkung der Mailingliste) <><>___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradroute über einen Platz
On Sat, Oct 18, 2008 at 13:02, Ulf Möller <[EMAIL PROTECTED]> wrote: > Michael Forster schrieb: > > > Den ganzen > > Platz aufzunehmen gefällt mir aber noch weniger, weil die Route eben nur > > mitten drüber führt. > > Wieso? Wenn der Platz zur Route gehört und man ihn auf beliebigen > Strecken überqueren kann, ist das doch genau richtig... Nun ja, der Platz ist halt groß und verwinkelt. So gesehen gehört nicht der ganze Platz dazu, sondern nur der Teil, den man benötigt um ihn zu überqueren. Dasselbe gilt ja für Straßen auch. Wenn ich eine Straße nur zwischen zwei Kreuzungen benutze, dann mache ich auch nicht die ganze Straße Teil der Relation, sondern ich teile sie auf. Das mit dem Aufteilen funktioniert halt bei Plätzen nicht. Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fahrradroute über einen Platz
Hi, Wie würdet ihr eine Fahrradroute mappen, die über einen (recht großen, verwinkelten) Platz führt? Der Platz existiert bereits und ist als Polygon mit "area=yes" versehen. Die Fahrradroute (Relation mit type=route, route=bicycle, network=lcn) führt mitten über den Platz. Der Radfahrer kann sich seinen Weg selbst suchen, wird aber sicher nicht jedes Eck des Platzes ausfahren. Ich bin versucht, einen neuen Way (highway=cycleway) mitten über den Platz zu ziehen. Ich habe ein bisschen Bedenken, weil das mehr ein "virtueller" Weg ist, der physikalisch so nicht existiert. Den ganzen Platz aufzunehmen gefällt mir aber noch weniger, weil die Route eben nur mitten drüber führt. Was denkt ihr? Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Karte in Google Maps Viewer
Hi On Thu, Oct 2, 2008 at 22:56, Sven Geggus <[EMAIL PROTECTED]>wrote: > Vermutlich halt besser optimierter Code. Google Maps API gibts AFAIK > schon etwas länger als Openlayers. Letzetres kann allerdings mehr was > die features angeht. Aus Interesse: Was denn? Mike ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
