[Talk-de] Garmin-Projekt. War: Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
On Tue, Jul 03, 2012 at 10:25:30PM +0200, Ronnie Soak wrote: Naja, ist eh nur Träumerei. Oder kannst du sowas umsetzen? Wenn man den Lambertus, den Computerteddy und den Pascal Neis mal für 24h in einen Raum sperren würde ;-) Okay, Vorschlag zu Umsetzung: Wir beantragen beim FOSSGIS Geld für ein Hackweekend, bei dem möglichst viele der Leute zusammenkommen sollen, die bisher schon an Garmin-Karten in irgendeiner Form arbeiten bzw. die mitmachen wollen. Ziel ist es eine Plattform aufzusetzen, die ähnlich garmin.openstreetmap.nl für Enduser einfach zu nutzen ist und in die alle Leute, die eigene Stile gebastelt haben, sich einbringen können. Dazu muss Software entwickelt werden, eine hübsche Seite gebastelt werden und Doku für Endanwender geschrieben werden. Wir brauchen auch irgendein Forum für Fragen der Anwender und es muss Leute geben, die bereit sind den Support zu übernehmen. An diesem Wochenende können wir auch gemeinsam die Wikiseiten angehen und komplett überarbeiten, sodass man in dem Durcheinander wieder etwas finden kann. Sicher können wir sehr viel bestehende Software übernehmen, mkgmap natürlich, vielleicht die Software hinter garmin.openstreetmap.nl. Was fehlt müssen wir entwickeln, idealerweise an dem Wochenende. Zumindest müssen wir an dem Wochenende aber gemeinsam identifizieren, was wir noch brauchen, damit das danach dann umgesetzt werden kann. Gleichzeitig beantragen wir beim FOSSGIS Geld für einen Root-Server für 6 Monate als Anschubfinanzierung. Danach muss sich der Server aus Spenden der Nutzer selbst tragen. Ich bin bereit mich auf der technischen Seite mit einzubringen, also Software schreiben bzw. anpassen und Serverbetrieb einrichten. Aber es müssen sich andere finden, die die anderen Teile übernehmen. Im ersten Schritt braucht es insbesondere den Antrag an den FOSSGIS, den jemand kalkulieren und schreiben muss und es braucht den Buy-In von möglichst vielen Leuten, die im Garmin-Bereich bisher schon was machen. Ohne die Expertise dieser Leute geht es nicht. Irgendjemand muss also bei diesen Leuten hausieren gehen. Wenn das jetzt jemand anstößt, dann kann man nach der Sommerpause das Hackweekend machen und dort in den Beta-Betrieb gehen und bis Jahresende eine zuverlässige und runde Plattform haben. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Projekt. War: Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Also ich würde schon mal das Ausfindig-machen der bisherigen Garminbastler und das Anfragen übernehmen. Am Wiki arbeite ich auch gern mit. Für Softwareentwicklung im Bereich serverseitige Dienste bin ich leider ungeeignet. Ich hab allerdings eher die Vermutung, dass das an den Modalitäten des persönlichen Erscheinens scheitert. Wer hat schon Zeit, mal eben ein Wochenende nach Karlsruhe zu kommen? Und dann auch noch alle am gleichen ... Das mag bei einem Aufruf an freiwillige funktionieren (die WOLLEN ja kommen), aber bei einer Einladung (an Leute die kommen SOLLEN )? Mit z.B. einem SVN Zugang zu einem Beta-Server ließe sich das möglicherweise etwas entspannen. Zum Thema FOSSGIS: Keine Ahnung was so ein Hacking Weekend kostet. Müssen die Räumlichkeiten gemietet werden? Oder den Leuten die Anfahrt gestellt? Bei einem Root-Server in der Leistungsklasse würde ich mal mit 70€+ im Monat Rechnen. Also 420Euro für ein halbes Jahr. Keine Ahnung ob die FOSSGIS das macht, aber auch ein ordentlicher Happen um es aus Spenden zu finanzieren. Für einen Beta-Test reichts vielleicht auch ne Nummer kleiner mit ca 50€. Ich würde mir aber trotzdem überlegen, ob wir eine Möglichkeit finden, auch Spenden in Form von Rechenzeit einzubinden. Zerlegt in Kachel ließe sich so eine Anfrage sicher auch auf mehrere Server verteilen. Ich werde mal mit ein wenig Recherchen beginnen ... Gruss Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Moin an Alle, ne Menge was ihr hier an Ideen habt, nun mal meine Meinung dazu. Am wichtigsten würde ich finden, daß endlich einen vernünftige Verlinkung oder meinetwegen eineeigene Seite bei osm.de erstellt wird, wo die ganzen Kartenpakete z.B. tabellarisch abrufbar sind, meinetwegen mit einer Bedienungsanleitung für die Verwendung der Fertigpakete (also auf die Speicherkarte und fertig) Meine Karten können sofort verlinkt werden, da mein Hauptmirror bei GwdG liegt, der verträgt einiges an Last. dazu noch Werbung bitte bei den einschlägigen Foren und vielleicht auch bei der Presse? Erfahrungsgemäß (habe dazu Feedback bekommen) installieren sich die User eher eine große Fertigkarte auf ihr GPS- Gerät, als daß sie sich einen eigenen Bereich aus einem Webinterface heraussuchen und berechnen lassen, noch dazu wo sie drauf warten müssen. Hier sind 10 Minuten Wartezeit den Leuten schon zu lange. Ich denke, die Lösung wie bei Lambertus ist zwar schön, aber nichts für die Masse der User. Ich würde vielleicht soetwas mal für DE aufbauen, aber nicht für die ganze Welt. Auch die speziellen feineingestellten Details wären für Freaks was, aber nicht für den 08/15- User. Ansonsten bin ich aber gern bereit mich einzubringen. On 07/03/12 22:25, Ronnie Soak wrote: Naja, ist eh nur Träumerei. Oder kannst du sowas umsetzen? Wenn man den Lambertus, den Computerteddy und den Pascal Neis mal für 24h in einen Raum sperren würde ;-) Ich hatte schon vor einiger Zeit versucht Kontakt wegen der AIO aufzunehmen, hat nicht wirklich geklappt. Das Hackerwochenende wäre auch ne gute Idee, wenns nicht so sehr weit von Frankfurt entfernt wäre. :-) -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 4. Juli 2012 09:09 schrieb Carsten Schwede computerte...@gmx.de: Am wichtigsten würde ich finden, daß endlich einen vernünftige Verlinkung oder meinetwegen eineeigene Seite bei osm.de erstellt wird, wo die ganzen Kartenpakete z.B. tabellarisch abrufbar sind, meinetwegen mit einer Bedienungsanleitung für die Verwendung der Fertigpakete (also auf die Speicherkarte und fertig) Das hatten wir schon mal in alten Threads und am Anfang dieser Diskussion: Wir können in der Tabelle jeweils nur die Hauptseite der Kartenanbieter angeben, keine Deeplinks zu den Karten (weil sonst zu fragil, Werbe-/Spendenumgehung, heterogene Struktur etc..) Damit sind wir nicht weiter als die Tabelle im Wiki. Meine Karten können sofort verlinkt werden, da mein Hauptmirror bei GwdG liegt, der verträgt einiges an Last. dazu noch Werbung bitte bei den einschlägigen Foren und vielleicht auch bei der Presse? Das ist doch schon mal ein netter Zug. Vielen Dank! Allerdings ist dein Fall auch noch der geeignetste für eine Direktverlinkung, du bietest ja nur eine kleine Anzahl verschiedener Karten an. Bei Anbietern mit 100+ Ländern wird das mit den Deeplinks schwieriger... Aber wo du gerade den kleinen Finger reichst: Würdest du (rein hypothetisch) neben dem Plattenplatz und der Bandbreite auch Rechenleistung 'spenden'? Also z.B. Kacheln in deinem Stil auf Anfrage rendern lassen? Und gliech noch hinterher: Würdest du deine Toolchain offenlegen? Mit allen verwendeten Optionen und Styles? Oder ist das geschütztes KnowHow? Erfahrungsgemäß (habe dazu Feedback bekommen) installieren sich die User eher eine große Fertigkarte auf ihr GPS- Gerät, als daß sie sich einen eigenen Bereich aus einem Webinterface heraussuchen und berechnen lassen, noch dazu wo sie drauf warten müssen. Hier sind 10 Minuten Wartezeit den Leuten schon zu lange. Ich denke, die Lösung wie bei Lambertus ist zwar schön, aber nichts für die Masse der User. Ich würde vielleicht soetwas mal für DE aufbauen, aber nicht für die ganze Welt. Auch die speziellen feineingestellten Details wären für Freaks was, aber nicht für den 08/15- User. Dem kann ich nur teilweise zustimmen. Du hast mit deinen Worldwide- oder Europa-Files sicher auch eine etwas andere Zielgruppe. (Der 08/15 eTrex-User mit 2GB Begrenzung kann damit eh nichts anfangen.) Ich habe SEHR viele Anfragen gehabt, wo Leute eben in einer Grenzregion wohnen oder im Urlaub nicht an Landesgrenzen halt machen. Es gibt auch noch sehr viele User mit Geräten, die nur eine Karte gleichzeitig verwenden können und Interesse an kombinierten Länderkarten haben. (Und ich stand in Leipzig, in der Mitte Deutschlands. Frag mal in Frankfurt/Oder nach, oder in Saarbrücken.) Auch hatten viele Leute eine Karte, waren aber mit der Darstellung unzufrieden (zu viele Details/zu wenigDetails/zu bunt/zu kontrastarm etc...). Einen Anwendungsfall für das einfache ausprobieren verschiedener Typfiles sehe ich da schon. Ansonsten bin ich aber gern bereit mich einzubringen. Wunderbar! Ich hatte schon vor einiger Zeit versucht Kontakt wegen der AIO aufzunehmen, hat nicht wirklich geklappt. Sehr schade. Es gibt leider viele Karten, die mehr oder weniger eingeschlafen sind. Kleineisel scheint auch keine Updates mehr zu bringen. Und die Radkarte ist auch nicht mehr verfügbar. Das Hackerwochenende wäre auch ne gute Idee, wenns nicht so sehr weit von Frankfurt entfernt wäre. :-) Ähhh, wie meinen? Ich dachte Karlsruhe läge da 'um die Ecke'. ;) Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Projekt. War: Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
On Wed, Jul 04, 2012 at 09:06:35AM +0200, Ronnie Soak wrote: Also ich würde schon mal das Ausfindig-machen der bisherigen Garminbastler und das Anfragen übernehmen. Prima. Am Wiki arbeite ich auch gern mit. Für Softwareentwicklung im Bereich serverseitige Dienste bin ich leider ungeeignet. Ich hab allerdings eher die Vermutung, dass das an den Modalitäten des persönlichen Erscheinens scheitert. Wer hat schon Zeit, mal eben ein Wochenende nach Karlsruhe zu kommen? Und dann auch noch alle am gleichen ... Das mag bei einem Aufruf an freiwillige funktionieren (die WOLLEN ja kommen), aber bei einer Einladung (an Leute die kommen SOLLEN )? Du kannst z.B. 2 Termine wahlweise anbieten und dann schauen, wo mehr Zeit haben und der ist es dann halt. Ich glaube schon, dass viele zu sowas kommen wollen. Vorallem, wenn man sie persönlich fragt und ihnen sagt, wie wichtig man ihre Arbeit einschätzt. Aber alle bekommt man natürlich nie. Mit z.B. einem SVN Zugang zu einem Beta-Server ließe sich das möglicherweise etwas entspannen. Das ist nicht das selbe. Es geht einfach drum, möglichst viele Leute und Ideen in einen Raum zu bringen. Natürlich wird man auch anderen die Teilnahme aus der Ferne ermöglichen. Zum Thema FOSSGIS: Keine Ahnung was so ein Hacking Weekend kostet. Müssen die Räumlichkeiten gemietet werden? Oder den Leuten die Anfahrt gestellt? Also eine Möglichkeit wäre die Geofabrik in Karlsruhe. Ohne da eine feste Zusage machen zu können (dazu musst Du Frederik Ramm fragen), denke ich, dass das möglich wäre. Die Räumlichkeiten würden dann nichts kosten. Andere Möglichkeit wäre das Linuxhotel (www.linuxhotel.de). Da waren wir (OSM bzw. FOSSGIS) auch schon ein paar Mal. Kostet glaube ich so 15-20 EUR pro Nase und Nacht für OpenSource-Gruppen. Dafür ist da auch die Übernachtung, Frühstück, etc. mit drin. Das sind also Fr/Sa und Sa/So * 10 Tln = 400 EUR. Ingesamt unschlagbar günstig. Termine muss man aber rechtzeitig machen, weil die sehr beliebt sind. Vorteil ist auch, dass es relativ zentral in DE liegt und auch aus den NL gut zu erreichen ist. Kontakt: m.gerwin...@villa-vogelsang.de Nimmt man das LinuxHotel würde ich vorschlagen, dass der FOSSGIS das übernimmt und jeder seine Anreise selbst zahlt. (Das ist am wenigstens Verwaltungsaufwand.) Kann jemand nur kommen, wenn wir die Anreise bezahlen, dann kann er das beantragen. Dafür sollte man im Budget dann was vorsehen. Bei einem Root-Server in der Leistungsklasse würde ich mal mit 70€+ im Monat Rechnen. Also 420Euro für ein halbes Jahr. Keine Ahnung ob die FOSSGIS das macht, aber auch ein ordentlicher Happen um es aus Spenden zu finanzieren. Für einen Beta-Test reichts vielleicht auch ne Nummer kleiner mit ca 50€. Lieber einen Server nehmen, der dann auch gleich sinnvoll im echten Betrieb arbeiten kann. 70EUR+ halte ich für realistisch. Eventuell lohnt es sich, zwei kleine Server statt einem grossen zu nehmen, weil man dann 2mal den Freitraffic bekommt. Wenn Du erstmal einen Antragsentwurf hast, dann kann man Lambertus und Co fragen, was sie dazu meinen und dann ggf. anpassen. Ich denke das kommt so auf ca. 1000 EUR raus an Förderung. Das ist in einem Bereich, der für den FOSSGIS gut zu stemmen ist. Ich würde mir aber trotzdem überlegen, ob wir eine Möglichkeit finden, auch Spenden in Form von Rechenzeit einzubinden. Zerlegt in Kachel ließe sich so eine Anfrage sicher auch auf mehrere Server verteilen. Das kannste knicken. Das ist technisch vielleicht möglich, aber organisatorisch zu aufwändig. Die knappe Ressource ist die Zeit der Entwickler und Admins. Wenn die sich damit rumschlagen müssen, mit der Uni in Posemuckel zu verhandeln, warum der Server grad nicht erreichbar ist, dann wird das nichts. Ich werde mal mit ein wenig Recherchen beginnen ... Prima. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hi, On 07/04/12 09:53, Frederik Ramm wrote: Das naechste Hack-Weekend hier in Karlsruhe ist fuer den 6./7.10. geplant. Ich mach da aber noch mal extra Werbung fuer, wenn der Termin naeher rueckt. Ich bin sicher, es wird *irgendjemand* geben, der mit dem Auto von Norden kommt und Dich mitnehmen koennte, wenn Du willst... Das hört sich doch prima an. Wo kann man in Karlsruhe günstig schlafen? -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 09:40, schrieb Ronnie Soak: Am 4. Juli 2012 09:09 schrieb Carsten Schwede computerte...@gmx.de: Am wichtigsten würde ich finden, daß endlich einen vernünftige Verlinkung oder meinetwegen eineeigene Seite bei osm.de erstellt wird, wo die ganzen Kartenpakete z.B. tabellarisch abrufbar sind, meinetwegen mit einer Bedienungsanleitung für die Verwendung der Fertigpakete (also auf die Speicherkarte und fertig) Das hatten wir schon mal in alten Threads und am Anfang dieser Diskussion: Wir können in der Tabelle jeweils nur die Hauptseite der Kartenanbieter angeben, keine Deeplinks zu den Karten (weil sonst zu fragil, Werbe-/Spendenumgehung, heterogene Struktur etc..) Damit sind wir nicht weiter als die Tabelle im Wiki. Man wäre meiner Meinung nach damit schon weiter. Weil man dem Nutzer eine Filterung anbieten könnte und eine begrenzte Vorschau. Wenn der User Fahrradkarten für Dänemark sucht, dann bleibt aus der langen Liste des wikis noch 4-5 Karten über, die er in einer Liste zu sehen bekommt. Derzeit im wiki muss man erstmal für Dänemark an 4 Stellen suchen (Worldwide, Europe, several Countries in Europe und Single Countries) und dann auf der entsprechenden Seite nach Infos suchen, ob es überhaupt eine Radkarte ist, für welche Räder sie gemacht ist usw. Ich denke jedoch, das man erstmal ein paar mehr Entwickler von Karten fragen sollte, wofür sie bereit sind und dann schauen sollte, ob ein Hackweekend sinnvoll ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
BTW: ist das erzeugen großer, aussortierter Datenpakete mit der Overpass-API eigentlich effizienter als das aussortieren unbrauchbarer Objekte direkt mit mkgmap? Zu der Laufzeit von mkgmap habe ich keine Erfahrung, kann aber gerne etwas zu der von Overpass API sagen. Es hängt von groß und aussortiert ab: (node(50.6,6.0,51.1,7.5);;);out; Das komplette Rheinland braucht 1 Min. 14 Sekunden bzw. 2 Min. 15 Sek., (node(50.6,6.0,51.1,7.5);;);out meta; wenn man die Meta-Daten mit laden will (unnötiger Ballast für die Kartenerzeugung, aber manche Tools machen einen Syntaxcheck). Mit 469 MB bzw. 873 MB für das unkomprimierte XML entsprechen sie etwa einem zwanzigstel von Deutschland und damit wohl einer mkgmap-Kachel. Für den Produktivbetrieb würde ich nötigenfalls die Tools so modifizieren, dass sie ohne Metadaten arbeiten können (Faktor 2 in der Rechenzeit und Dateigrößen). (node(50.6,6.0,52.3,9.5);;);out; Komplett NRW braucht 8 Min. 20 Sek.(ohne Metadaten) und enthält 2,97 GB Daten. Noch größere Bounding-Boxen würde ich nicht mit Overpass API auszuschneiden empfehlen. Zum Thema aussortiert: (way[highway](50.6,6.0,51.1,7.5);;node(50.6,6.0,51.1,7.5)[amenity];node(50.6,6.0,51.1,7.5)[highway];);out; Nur Wege und POIs im Rheinland brauchen 29 Sekunden und liefern nur noch 153 MB Daten. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Projekt. War: Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 09:07, schrieb Ronnie Soak: Also ich würde schon mal das Ausfindig-machen der bisherigen Garminbastler und das Anfragen übernehmen. Am Wiki arbeite ich auch gern mit. Für Softwareentwicklung im Bereich serverseitige Dienste bin ich leider ungeeignet. Ich hab auf mkgmap-dev mal auf diese Diskussion hingewiesen. Ich denke dort lesen alle größeren Entwickler mit. Evtl. wäre es auch sinnvoll, die Diskussion international durchzuführen? Allgemein wäre ich auch bei einem Hackweekend dabei. Kommt halt drauf an, ob es für einen Kartenentwickler sinnvoll ist, oder ob eher Webentwickler etc. gefragt sind. Anreise und Unterkunft ist ja auch nicht ohne für den Geldbeutel, da wäre es dann blöd, wenn man nicht wirklich mitarbeiten kann. In jedem Fall stehe ich aber dann via Skype für Fragen zur Verfügung. Henning Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
On Tue, Jul 03, 2012 at 04:24:43PM +0200, Ronnie Soak wrote: Am 3. Juli 2012 15:48 schrieb aighes o...@aighes.de: Mit einer guten, neutralen Übersichtsseite, die dann auf die Downloadseiten verlinkt hat sicher keiner ein Problem. Dennoch würde ich eine Listung dort freiwillig für den Anbieter machen. Denn man sollte nicht unterschätzen, welcher Traffic erzeugt wird, wenn genug Leute die Karten laden. Damit muss dann das Projekt auch klar kommen. Ebenso sollte man bedenken, dass viele der Projekte nur laufen können, weil sie Spenden bekommen. Von daher sollte man auch nicht einfach die Downloads direkt verlinken. Ich denke, es ist schon fair, wenn man den Weg unterstützt, den der Anbieter vorsieht oder die Karte eben nicht listet. Ja, das waren in etwa so die Argumente aus den vorherigen Diskussionen: - man darf den Leuten den Traffic nicht wegnehmen, wegen Werbe-/Spendenfinanzierung - man darf den Leuten nicht mehr Traffic schicken, wegen Begrenzungen - eine Übersichtsseite mit Direktlinks ist beinahe unmöglich, wegen der extrem heterogenen und auch noch instabilen Organisationsstruktur der Kartennabieter Also hier kann man ja durchaus mal automatisiert torrents erzeugen und den direktdownload erst nach 48 Stunden ermoeglichen - dann hat man eine menge traffic gespart - Ich habe da auch kein problem mit wenn man sich da einigt das durch aktive seeder die automatisch neue torrents holen zu unterstuetzen. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 12:15, schrieb Florian Lohoff: On Tue, Jul 03, 2012 at 04:24:43PM +0200, Ronnie Soak wrote: Am 3. Juli 2012 15:48 schrieb aighes o...@aighes.de: Mit einer guten, neutralen Übersichtsseite, die dann auf die Downloadseiten verlinkt hat sicher keiner ein Problem. Dennoch würde ich eine Listung dort freiwillig für den Anbieter machen. Denn man sollte nicht unterschätzen, welcher Traffic erzeugt wird, wenn genug Leute die Karten laden. Damit muss dann das Projekt auch klar kommen. Ebenso sollte man bedenken, dass viele der Projekte nur laufen können, weil sie Spenden bekommen. Von daher sollte man auch nicht einfach die Downloads direkt verlinken. Ich denke, es ist schon fair, wenn man den Weg unterstützt, den der Anbieter vorsieht oder die Karte eben nicht listet. Ja, das waren in etwa so die Argumente aus den vorherigen Diskussionen: - man darf den Leuten den Traffic nicht wegnehmen, wegen Werbe-/Spendenfinanzierung - man darf den Leuten nicht mehr Traffic schicken, wegen Begrenzungen - eine Übersichtsseite mit Direktlinks ist beinahe unmöglich, wegen der extrem heterogenen und auch noch instabilen Organisationsstruktur der Kartennabieter Also hier kann man ja durchaus mal automatisiert torrents erzeugen und den direktdownload erst nach 48 Stunden ermoeglichen - dann hat man eine menge traffic gespart - Ich habe da auch kein problem mit wenn man sich da einigt das durch aktive seeder die automatisch neue torrents holen zu unterstuetzen. Bei Torrents sehe ich zwei Probleme: Lohnt sich für kleinere/upopuläre Karten nicht wirklich. Aber die kann man dann ja raus nehmen und nur die großen/populären Karten auf torrent-Basis verteilen. Torrent ist bei den Leuten, die in der Regel das Problem haben, über das wir reden, mit illegalem Herunterladen assoziiert. Sprich ob sie das Angebot nutzen ist sehr fraglich. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hi, On 07/04/12 12:25, aighes wrote: Bei Torrents sehe ich zwei Probleme: Lohnt sich für kleinere/upopuläre Karten nicht wirklich. Aber die kann man dann ja raus nehmen und nur die großen/populären Karten auf torrent-Basis verteilen. Torrent ist bei den Leuten, die in der Regel das Problem haben, über das wir reden, mit illegalem Herunterladen assoziiert. Sprich ob sie das Angebot nutzen ist sehr fraglich. Ich habe torrents eine Zeitlang mit angeboten, hat gar nicht funktioniert, da durch den geringen Traffic alles veraltet war und sich keine Userbasis aufbauen konnte. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 4. Juli 2012 11:03 schrieb Roland Olbricht roland.olbri...@gmx.de: Zu der Laufzeit von mkgmap habe ich keine Erfahrung, kann aber gerne etwas zu der von Overpass API sagen. Es hängt von groß und aussortiert ab: (node(50.6,6.0,51.1,7.5);;);out; Das komplette Rheinland braucht 1 Min. 14 Sekunden bzw. 2 Min. 15 Sek., (node(50.6,6.0,51.1,7.5);;);out meta; wenn man die Meta-Daten mit laden will (unnötiger Ballast für die Kartenerzeugung, aber manche Tools machen einen Syntaxcheck). Mit 469 MB bzw. 873 MB für das unkomprimierte XML entsprechen sie etwa einem zwanzigstel von Deutschland und damit wohl einer mkgmap-Kachel. Für den Produktivbetrieb würde ich nötigenfalls die Tools so modifizieren, dass sie ohne Metadaten arbeiten können (Faktor 2 in der Rechenzeit und Dateigrößen). (node(50.6,6.0,52.3,9.5);;);out; Komplett NRW braucht 8 Min. 20 Sek.(ohne Metadaten) und enthält 2,97 GB Daten. Noch größere Bounding-Boxen würde ich nicht mit Overpass API auszuschneiden empfehlen. Zum Thema aussortiert: (way[highway](50.6,6.0,51.1,7.5);;node(50.6,6.0,51.1,7.5)[amenity];node(50.6,6.0,51.1,7.5)[highway];);out; Nur Wege und POIs im Rheinland brauchen 29 Sekunden und liefern nur noch 153 MB Daten. Danke für die Zahlen! Das klingt alles sehr gut, ich muss aber noch mal Nachfragen: Du sagts, ein Bundesland ist etwa die Grenze, die du mit der OverPass API ausschneiden würdest. Allerdingst sagst du dann, das gefiltert wesentlich weniger Daten anfallen. Bedeutet das, das gefiltert dann eine größere bbox möglich wäre? Oder ist der DatenINPUT gleich, und deswegen die Grenze konstant? Außerdem: wie skaliert das mit komplexeren Anfragen? Also nicht nur 2 Kriterien, sondern z.B. 200 ? Leider haben wir da auch einen Catch22: Die OverPass API kann nur auf Kachelgröße arbeiten. Das Tool, das von einer vorgefilterten .osm Datei profitieren könnte ist aber gerade auch der Tile Splitter, wklcher uns wiederum als einziger sagen kann, wie groß die Kacheln sein sollen, wozu er aber ein Gesamt-OSM file braucht. Ich grübele darüber mal noch ein bisschen nach ... Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
On Wed, Jul 04, 2012 at 12:25:29PM +0200, aighes wrote: Lohnt sich für kleinere/upopuläre Karten nicht wirklich. Aber die kann man dann ja raus nehmen und nur die großen/populären Karten auf torrent-Basis verteilen. Wenn der prozess automatisiert ist kann man das auch fuer 50MB Karten sonstwoher machen - Das ist eben der Punkt - ohne automatisierung macht das keinen sinn. Wenn da einer immer eine halbe stunde investieren muss das torrent file zu erzeugen und das in den tracker zu werfen ... Torrent ist bei den Leuten, die in der Regel das Problem haben, über das wir reden, mit illegalem Herunterladen assoziiert. Sprich ob sie das Angebot nutzen ist sehr fraglich. Ganz ehrlich? Dann sollen sie es bleiben lassen - Torrent ist ein distributionsmechanismuss der eben die bandbreitenverteilung zum Ziel hat. Und eben die Einstellung oben draengt bittorrent ja in diese Ecke. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
On Wed, Jul 04, 2012 at 12:51:40PM +0200, Carsten Schwede wrote: Ich habe torrents eine Zeitlang mit angeboten, hat gar nicht funktioniert, da durch den geringen Traffic alles veraltet war und sich keine Userbasis aufbauen konnte. Wir wollen ja das Problem mit dem Traffic loesen und da muss man die leute zwingen sowas zu benutzen - deshalb ja die idee das man die daten im direktdownload erst 24-48 Stunden spaeter anbietet ... Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 13:12, schrieb Florian Lohoff: On Wed, Jul 04, 2012 at 12:51:40PM +0200, Carsten Schwede wrote: Ich habe torrents eine Zeitlang mit angeboten, hat gar nicht funktioniert, da durch den geringen Traffic alles veraltet war und sich keine Userbasis aufbauen konnte. Wir wollen ja das Problem mit dem Traffic loesen und da muss man die leute zwingen sowas zu benutzen - deshalb ja die idee das man die daten im direktdownload erst 24-48 Stunden spaeter anbietet ... Hallo Florian, die Nutzer wollen nicht unbedingt die aktuellen Daten. Vielen ist auch nicht wirklich bewusst, das sich die Daten groß ändern. Bspw. wurde ich gefragt, ob ich nicht einen Changelog schreiben könnte, was sich von einer Version zur nächsten ändert. Es gibt auch diverse Nutzer, die noch mit der Radfahrer-Karte von vor 2 Jahren durch die Gegend radeln. Aktuelle Daten (bezogen auf Tage) wollen egtl. nur die Mapper, die ihre Änderungen sehen/nutzen wollen. Ich würde den Traffic auch erstmal nicht als zentrales Problem betrachten. Man sollte halt den Herausgeber fragen, ob bei so einer Übersicht seine Karte genannt werden soll, oder ob ihm das recht ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hallo Florian, die Nutzer wollen nicht unbedingt die aktuellen Daten. Vielen ist auch nicht wirklich bewusst, das sich die Daten groß ändern. Bspw. wurde ich gefragt, ob ich nicht einen Changelog schreiben könnte, was sich von einer Version zur nächsten ändert. Es gibt auch diverse Nutzer, die noch mit der Radfahrer-Karte von vor 2 Jahren durch die Gegend radeln. Das kann ich so bestätigen. Es ist eben gerade so, dass es momentan noch so kompliziert ist, sich selbst eine Karte zu besorgen, dass die Leute sich einmal haben eine Karten 'von einem Bekannten' haben aufspielen lassen und die dann seit 2 Jahren nutzen. Gerade diese Hürde wollen wir ja hier verkleinern. Das mit den Torrents ist eine nette Idee für die Poweruser, aber für die 08/15 Konsumenten kommt es nicht in Frage. Da muss es eine reine Web-Alternative geben. Schon ftp ist zu kompliziert. Das mit dem 'du bekommst einen Link gemailt' ist grenzwertig, weil 'der Bekannte' ihnen eingebläut hat, im Web nirgendwo pers. Daten (= eMail) einzugeben. Eine Zeitverzögerung oder ein langsamer Download hingegen ist ihnen egal. Dann dauerts halt. Zeit haben die meisten genug. Gruss, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hallo, Mal ein paar Zahlen zu einer Karte. Meine Deutschlandkarte besteht zur Zeit aus 155 Kacheln. Dabei arbeite ich mit statischen Kachelgrenzen. Sprich ich rechne die einmal mit einem zurecht geschnittenen Extrakt aus und lass den splitter dann direkt aus dem planet ausschneiden. Das dauert rund 1:05 h für alle meine Karten (~630 Kacheln). mkgmap dürfte kaum noch Zeit verlieren durch das aussortieren von Tags. Genaueres müsste man auf mkgmap-dev erfragen, das ist aber schon recht weit optimiert worden. Sinnvoll nutzbar wäre die Overpass-API, wenn sie direkt die Kacheln liefert. Idealerweise als pbf, mit xml ist mkgmap 5-7mal langsamer. Und die Frage ist: Ist das von der Last her sinnvoll. splitter erzeugt recht wenig Last und der RAM-Verbrauch hält sich sehr in Grenzen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hi, Meine Deutschlandkarte besteht zur Zeit aus 155 Kacheln. Dabei arbeite ich mit statischen Kachelgrenzen. Sprich ich rechne die einmal mit einem zurecht geschnittenen Extrakt aus und lass den splitter dann direkt aus dem planet ausschneiden. Das dauert rund 1:05 h für alle meine Karten (~630 Kacheln). mkgmap dürfte kaum noch Zeit verlieren durch das aussortieren von Tags. Genaueres müsste man auf mkgmap-dev erfragen, das ist aber schon recht weit optimiert worden. Ich würde dann mal testen wollen (an z.B. einem Bundesland), wie viel man an Zeit herausholen kann, wenn man splitter die von der Overpass-Api vorgefilterten Daten als Input gibt. (Natürlich inkl. der Laufzeit der Abfrage.) Sinnvoll nutzbar wäre die Overpass-API, wenn sie direkt die Kacheln liefert. Idealerweise als pbf, mit xml ist mkgmap 5-7mal langsamer. Und die Frage ist: Ist das von der Last her sinnvoll. splitter erzeugt recht wenig Last und der RAM-Verbrauch hält sich sehr in Grenzen. Wenn die (CPU?) Last gering ist und auch der RAM nicht voll, dann wird I/O die Grenze sein, an der er sich 1h aufhält. Da kann ich mir schon vorstellen, das ein vorgefiltertes .osm (ich schätze mal 50% der Originalgrösse) was bringt. Allerdings hast du recht, dass wir von der API nur XML bekommen. Wenn pbf wirklich so viel schneller ist, werden wir nichts gewinnen, wenn wir in der Toolchain noch eine Umwandlung haben. Gilt das 5-7x auch für splitter? @Roland: ist sowas mal geplant, dass die Overpass API zumdest bei lokalen Datenbanken auch pbs ausspucken kann? Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
aighes o...@aighes.de wrote: Die Toolchain ist in der Regel einheitlich bzw. ähnlich. Wobei es natürlich schon Unterschiede gibt. AFAIK ist das nicht so einfach, weil jeder Garminkartenstil eine Andere Zuordnung der osm Typen zu Garmintypen verrwendet. Dadurch sind TYP-Dateien leider nicht von einer Karte auf die andere übertragbar. Gruss Sven -- Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open Source-Betriebssystem bedenken sollten, ist, dass Sie kein Windows-Betriebssystem erhalten. (von http://www.dell.de/ubuntu) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hi! Mir scheint in dieser Diskussion werden zwei Aspekte vermischt, die durchaus separat betrachtet werden können. 1. Zentrale, automatische Produktion von Garminkarten, aktuell halten von Garminkarten 2. Einfacheres Auffinden, einfacherer Zugang für den Nutzer Für 2. würde ich mir eher einen vereinfachten Webzugang vorstellen - eine Schaufensterseite wie auf openstreetmap.de für die Online Karten - oder eine sukzessive Suche ähnlich wie bei den meisten Treiberdownloads: Auswahl des Themas/der Themen, Auswahl einer Region auf einer Karte wie z.B. hier http://www.dickemauern.de/ausland.htm und dann Anzeige aller in Frage kommenden Karten mit Link, letzer Aktualisierung usw. Dafür müßte man nur eine Datenbank von Karten analog zur jetzigen Wikiliste unterhalten und die Links auf Gültigkeit prüfen. Ggf. noch die Karten auf einen Mirror kopieren, um die Links zuverlässiger zu halten. Umgekehrt argumentiert: Wenn man sich nur auf 1. und die Karten die man selbst zentralisiert baut beschränkt, tut man dem Nutzer, für den vielleicht eine der anderen Karten im Netz die passendste ist, keinen Gefallen. Im Gegenteil, es würde eher verschleiert, daß es da noch mehr gibt. bye Nop -- View this message in context: http://gis.19327.n5.nabble.com/Feedback-vom-OpenStreetMap-Stand-auf-dem-GeoGames-Leipzig-Event-tp5714855p5715054.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Was mir bei der Diskussion grade auffällt ist: die overpass-api ist, soweit ich weiß, simpel zu installieren. Vermutlich (! Roland?) ist eine Beschränkung der Größe etc. relativ leicht rauszunehmen, wenn man das lokal auf dem Garminkarten-Server laufen lassen würde. Der Vorteil der schnellen Filterung von overpass gegenüber der vom gkmap ließe sich insofern möglicherweise mit beschränkten resourcen der overpass-api einerseits und am ehesten teurem Traffic andererseits in Einklang bringen. Gruß Peter Am 04.07.2012 14:10, schrieb Ronnie Soak: Hi, Meine Deutschlandkarte besteht zur Zeit aus 155 Kacheln. Dabei arbeite ich mit statischen Kachelgrenzen. Sprich ich rechne die einmal mit einem zurecht geschnittenen Extrakt aus und lass den splitter dann direkt aus dem planet ausschneiden. Das dauert rund 1:05 h für alle meine Karten (~630 Kacheln). mkgmap dürfte kaum noch Zeit verlieren durch das aussortieren von Tags. Genaueres müsste man auf mkgmap-dev erfragen, das ist aber schon recht weit optimiert worden. Ich würde dann mal testen wollen (an z.B. einem Bundesland), wie viel man an Zeit herausholen kann, wenn man splitter die von der Overpass-Api vorgefilterten Daten als Input gibt. (Natürlich inkl. der Laufzeit der Abfrage.) Sinnvoll nutzbar wäre die Overpass-API, wenn sie direkt die Kacheln liefert. Idealerweise als pbf, mit xml ist mkgmap 5-7mal langsamer. Und die Frage ist: Ist das von der Last her sinnvoll. splitter erzeugt recht wenig Last und der RAM-Verbrauch hält sich sehr in Grenzen. Wenn die (CPU?) Last gering ist und auch der RAM nicht voll, dann wird I/O die Grenze sein, an der er sich 1h aufhält. Da kann ich mir schon vorstellen, das ein vorgefiltertes .osm (ich schätze mal 50% der Originalgrösse) was bringt. Allerdings hast du recht, dass wir von der API nur XML bekommen. Wenn pbf wirklich so viel schneller ist, werden wir nichts gewinnen, wenn wir in der Toolchain noch eine Umwandlung haben. Gilt das 5-7x auch für splitter? @Roland: ist sowas mal geplant, dass die Overpass API zumdest bei lokalen Datenbanken auch pbs ausspucken kann? Gruss, Chaos ___ 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] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
aighes o...@aighes.de wrote: Das Problem ist nicht, dass es keine aktuelle Vielfalt gibt, sondern dass die Nutzer diese Vielfalt anscheinend nicht finden. Es ist ein Problem, dass die Vielfalt nicht konsistent ist. Viele Karten gibt es halt nur für wenige Regionen. Ein weiteres Problem ist, dass man den Karten häufig ansieht ob das Kartenbild eher für Geräte mit kleinem Display oder für Geräte mit großem Display optimiert ist. Da könnte ein WebGUI auch helfen indem es die Angabe eines Gerätes ermöglicht. Gruss Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 14:10, schrieb Ronnie Soak: Sinnvoll nutzbar wäre die Overpass-API, wenn sie direkt die Kacheln liefert. Idealerweise als pbf, mit xml ist mkgmap 5-7mal langsamer. Und die Frage ist: Ist das von der Last her sinnvoll. splitter erzeugt recht wenig Last und der RAM-Verbrauch hält sich sehr in Grenzen. Wenn die (CPU?) Last gering ist und auch der RAM nicht voll, dann wird I/O die Grenze sein, an der er sich 1h aufhält. Da kann ich mir schon vorstellen, das ein vorgefiltertes .osm (ich schätze mal 50% der Originalgrösse) was bringt. Allerdings hast du recht, dass wir von der API nur XML bekommen. Wenn pbf wirklich so viel schneller ist, werden wir nichts gewinnen, wenn wir in der Toolchain noch eine Umwandlung haben. Gilt das 5-7x auch für splitter? Hallo, primär kommt der Unterschied ja aus der I/O-Bremse. Bei xml muss deutlich mehr eingelesen werden. Die Zahlen stammen aus der Zeit, als splitter und mkgmap pbf gelernt haben. Wenn ich mich recht erinnere beziehen sie sich nur auf splitter, der ja primär Daten schaufelt. Bei mkgmap ist das Einlesen nur ein Teil der Arbeit. Hier sollte es etwas weniger werden. Aber es ist schon deutlich schneller ein pbf einzulesen als ein xml. Was mir noch eingefallen ist: Sinnvoll ist der Weg über die OverpassAPI natürlich nur, wenn das über schnelles LAN angebunden ist oder auf dem gleichen Server läuft und ob dann die OverpassAPI schneller ist als osmfilter bzw. mkgmap intern würde ich erstmal verneinen. Aber wenn du es testen willst nur zu. Wäre ja mal interessant zu wissen, wie es wirklich ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
aighes o...@aighes.de wrote: Was mir noch eingefallen ist: Sinnvoll ist der Weg über die OverpassAPI natürlich nur, wenn das über schnelles LAN angebunden ist oder auf dem gleichen Server läuft Man kann bei den meisten Serverprovidern inzwischen schnelle private VLAN mieten und dadurch die Server untereinander schnell vernetzen, das ist nicht mehr so das Problem. Sven -- Das allgemeine Persönlichkeitsrecht (Art. 2 Abs.1 i.V.m. Art.1 Abs. 1GG) umfasst das Grundrecht auf Gewährleistung der Vertraulichkeit und Integrität informationstechnischer Systeme. (BVerfG, 1BvR 370/07) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 14:43, schrieb Sven Geggus: aighes o...@aighes.de wrote: Das Problem ist nicht, dass es keine aktuelle Vielfalt gibt, sondern dass die Nutzer diese Vielfalt anscheinend nicht finden. Es ist ein Problem, dass die Vielfalt nicht konsistent ist. Viele Karten gibt es halt nur für wenige Regionen. Was durchaus auch nicht verkehrt ist. Schließlich weiß der lokale Ersteller in der Regel am besten, wie er die Daten für die Region interpretieren sollte. ;-) In speziellen Fällen hilft auch das Anschreiben des Erstellers. Wenn es unbedingt die RadReiseKarte für die Reise nach Grönland sein soll, dann hab ich damit auch kein Problem, die einmalig mitzurendern, solange es nicht überhand nimmt. Ein weiteres Problem ist, dass man den Karten häufig ansieht ob das Kartenbild eher für Geräte mit kleinem Display oder für Geräte mit großem Display optimiert ist. Wobei man dies mit einem anderen TYP-File simpel ändern kann. Da könnte ein WebGUI auch helfen indem es die Angabe eines Gerätes ermöglicht. Genau. Diverse Filtermöglichkeiten wären denkbar. Es sollte halt verständlich bleiben. Vieles kann man auch mit Icons erschlagen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 4. Juli 2012 14:38 schrieb NopMap ekkeh...@gmx.de: Hi! Mir scheint in dieser Diskussion werden zwei Aspekte vermischt, die durchaus separat betrachtet werden können. 1. Zentrale, automatische Produktion von Garminkarten, aktuell halten von Garminkarten 2. Einfacheres Auffinden, einfacherer Zugang für den Nutzer Für 2. würde ich mir eher einen vereinfachten Webzugang vorstellen - eine Schaufensterseite wie auf openstreetmap.de für die Online Karten - oder eine sukzessive Suche ähnlich wie bei den meisten Treiberdownloads: Auswahl des Themas/der Themen, Auswahl einer Region auf einer Karte wie z.B. hier http://www.dickemauern.de/ausland.htm und dann Anzeige aller in Frage kommenden Karten mit Link, letzer Aktualisierung usw. Dafür müßte man nur eine Datenbank von Karten analog zur jetzigen Wikiliste unterhalten und die Links auf Gültigkeit prüfen. Ggf. noch die Karten auf einen Mirror kopieren, um die Links zuverlässiger zu halten. Umgekehrt argumentiert: Wenn man sich nur auf 1. und die Karten die man selbst zentralisiert baut beschränkt, tut man dem Nutzer, für den vielleicht eine der anderen Karten im Netz die passendste ist, keinen Gefallen. Im Gegenteil, es würde eher verschleiert, daß es da noch mehr gibt. Wir sind auf die Behandlung von 1. als Lösung für 2. verfallen, weil eine simple neue Weboberfläche einfach das Problem nicht löst. Wir können oder wollen keine Deeplinks direkt zu den Karten, weil das die Anbieterseiten umgeht und die das möglicherweise nicht wollen. Wenn wir nur auf die Anbieterseiten verweisen, werden wir aber nicht benutzerfreundlicher, egal wie gut wir vorher filtern/erklären/vorauswählen. Also war unsere einzige Lösungsidee, eigene Karten mit den bekannten Stilen zu erzeugen, wo wir dann selbst die Kontrolle über die Anbieterseite haben. Das ist nicht ideal, schon klar, und außerdem fürchterlich aufwändig. Damit wir damit gerade nicht die Vielfalt an Karten zerstören, überlegen wir, wie wir es auch den bisherigen Kartenabietern leicht machen können, ihre Karten auch dort anzubieten. Bildlich: Statt uns eine neue Standanordnung für den Wochenmarkt zu überlegen, damit sich nicht immer die Kunden zwischen den ganzen bunten Buden auf dem Weg zu den Kartoffeln verlaufen, bieten wir den Einzelunternehmern an, ihr Gemüse gleich auf unseren Felder anzubauen, damit wir es zentral verpacken und beschriften und im gemeinsamen Hofladen vertreiben können. Probleme bei einem reinen neuen Webfrontend: Nicht alle Karten lassen sich in Länderkategorien sortieren, manche sind kachelbasiert. Die Kompatibilität zu bestimmten Geräten können wir einfach nicht überprüfen. Wir können schwer überprüfen, welche Karten aktuell sind, welche nicht. Gruss, Chaos ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 14:29, schrieb Sven Geggus: aighes o...@aighes.de wrote: Die Toolchain ist in der Regel einheitlich bzw. ähnlich. Wobei es natürlich schon Unterschiede gibt. AFAIK ist das nicht so einfach, weil jeder Garminkartenstil eine Andere Zuordnung der osm Typen zu Garmintypen verrwendet. Dadurch sind TYP-Dateien leider nicht von einer Karte auf die andere übertragbar. Die Toolchain ist schon einheitlich. osmupdate/osmosis zum updaten eines planets oder aktuelles Extrakt herunterladen - einfach zu vereinheitlichen splitten der Kacheln mit splitter - hier müsste man sich dann einigen, dass bspw. alle Deutschlandkarten die selben Kacheln nehmen mkgmap ist von Karte zu Karte unterschiedlich. Daran kann man nichts ändern. Ebenso die TYP-Files. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Hi! Mir scheint in dieser Diskussion werden zwei Aspekte vermischt, die durchaus separat betrachtet werden können. Das sehe ich auch so. 1. Zentrale, automatische Produktion von Garminkarten, aktuell halten von Garminkarten 2. Einfacheres Auffinden, einfacherer Zugang für den Nutzer Für 2. würde ich mir eher einen vereinfachten Webzugang vorstellen - eine Schaufensterseite wie auf openstreetmap.de für die Online Karten - oder eine sukzessive Suche ähnlich wie bei den meisten Treiberdownloads: Auswahl des Themas/der Themen, Auswahl einer Region auf einer Karte wie z.B. hier http://www.dickemauern.de/ausland.htm und dann Anzeige aller in Frage kommenden Karten mit Link, letzer Aktualisierung usw. Dafür müßte man nur eine Datenbank von Karten analog zur jetzigen Wikiliste unterhalten und die Links auf Gültigkeit prüfen. Ggf. noch die Karten auf einen Mirror kopieren, um die Links zuverlässiger zu halten. Umgekehrt argumentiert: Wenn man sich nur auf 1. und die Karten die man selbst zentralisiert baut beschränkt, tut man dem Nutzer, für den vielleicht eine der anderen Karten im Netz die passendste ist, keinen Gefallen. Im Gegenteil, es würde eher verschleiert, daß es da noch mehr gibt. Der zweite Ansatz erscheint mir der technisch deutlich einfachere und weniger aufwendig umzusetzende. Als ich vor einigen Jahren eingestiegen bin, habe ich auch erst mal lange rumgesucht, bis ich gefunden habe, wo man eine OSM-Garmin Karten runterladen kann. Mit einer einfachen Verlinkung sollte man die allermeisten Nutzer zufrieden stellen. Der zweite Ansatz ist interessant, allerdings schätze ich die technischen Probleme als relativ hoch ein. Wie bereits erwähnt, werden von vielen Kartenerstellern die Typ-Files an den Style (die Regeln, mit welchen Objekten die Karten gefüllt werden) angepasst. Meiner Meinung nach, wird diese Funktionalität bereits vom MapComposer (bzw. OsmComposer) abgedeckt. Leider steht die Software nicht als Opensource zur Verfügung und rechnet die Karte auf dem PC des Endanwenders, wodurch sie für die hier gewünschten Zwecke nicht in Frage kommt. Optimierungsbedarf von mkgmap: * Ich bezweifle, dass das Vorfiltern von Tags über die OverpassAPI einen Vorteil bringt. mkgmap versucht, möglichst nur diejenigen Daten zu laden, die notwendig sind. Natürlich sind auch hier noch kleinere Optimierungsmöglichkeiten vorhanden. * Eine wesentliche Optimierung (gerade was den Hauptspeicherbedarf angeht) könnte sein, wenn man beim PBF-Format am Anfang des Files einen Pointer auf den Anfang der Relationen und auf den Anfang der Ways setzen könnte. Dann könnte mkgmap das File umgekehrt einlesen, also zuerst die Relationen, dann die Ways und zuletzt die Nodes. Liest man die Datei in der richtigen Reihenfolge, hat man das Problem, das man bei einem Node zwar bestimmte Tags nicht mit einliest, weil sie nicht benötigt werden. Man muß aber trotzdem alle Nodes einlesen, da auch ein Nodes ohne Tags zu einem späteren Zeitpunkt von einem Way oder einer Relation verwendet werden könnte. In der umgekehrten Reihenfolge, weiß man beim Einlesen der Nodes bereits, ob ein Node verwendet wird oder nicht. Falls es Änderungsbedarf an mkgmap für die Umsetzung der angerissenen Funktionalitäten gibt, stehe ich gerne zur Verfügung. WanMil bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
On Wed, Jul 04, 2012 at 03:14:34PM +0200, WanMil wrote: * Eine wesentliche Optimierung (gerade was den Hauptspeicherbedarf angeht) könnte sein, wenn man beim PBF-Format am Anfang des Files einen Pointer auf den Anfang der Relationen und auf den Anfang der Ways setzen könnte. Dann könnte mkgmap das File umgekehrt einlesen, also zuerst die Relationen, dann die Ways und zuletzt die Nodes. Liest man die Datei in der richtigen Reihenfolge, hat man das Problem, das man bei einem Node zwar bestimmte Tags nicht mit einliest, weil sie nicht benötigt werden. Man muß aber trotzdem alle Nodes einlesen, da auch ein Nodes ohne Tags zu einem späteren Zeitpunkt von einem Way oder einer Relation verwendet werden könnte. In der umgekehrten Reihenfolge, weiß man beim Einlesen der Nodes bereits, ob ein Node verwendet wird oder nicht. Es ist garnicht so aufwändig ein OSM-File mehrfach zu lesen und in jedem Durchgang nur das zu verwenden, was man braucht. Natürlich wäre es besser man kann direkt an die richtige Stelle seeken, aber es geht auch mit dem bisherigen Format. Das kostet nur ein paar Minuten, wenn man die Blocks, die einen nicht interessieren garnicht erst parst. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Ronnie Soak wrote Wir sind auf die Behandlung von 1. als Lösung für 2. verfallen, weil eine simple neue Weboberfläche einfach das Problem nicht löst. Wir können oder wollen keine Deeplinks direkt zu den Karten, weil das die Anbieterseiten umgeht und die das möglicherweise nicht wollen. Wenn wir nur auf die Anbieterseiten verweisen, werden wir aber nicht benutzerfreundlicher, egal wie gut wir vorher filtern/erklären/vorauswählen. Das läßt sich ja im Einzelfall mit dem Anbieter klären ob er Link, DeepLink oder Kartenmirror haben möchte. Es sagt ja keiner, daß der letzte Link einheitlich sein muß. Aber der Nutzer hätte zumindest bis dorthin eine einfache Möglichkeit, die richtige Karte zu erzeugen. Ronnie Soak wrote Also war unsere einzige Lösungsidee, eigene Karten mit den bekannten Stilen zu erzeugen, wo wir dann selbst die Kontrolle über die Anbieterseite haben. Das ist nicht ideal, schon klar, und außerdem fürchterlich aufwändig. Damit wir damit gerade nicht die Vielfalt an Karten zerstören, überlegen wir, wie wir es auch den bisherigen Kartenabietern leicht machen können, ihre Karten auch dort anzubieten. Letztere Überlegung habe ich in der bisherigen Diskussion nicht so recht wahrgenommen. Ich würde dann erwarten, daß der gleiche Effekt wie bei den Online-Karten eintritt: Die Mapnik Karte (oder bestenfalls die Layers auf osm.org) wird als DIE OSM-Karte verstanden und die meisten Leute kommen gar nicht auf die Idee, daß es noch andere Karten geben könnte. Die zentral generierten Karten werden dann als die OSM-Garmin-Karte wahrgenommen und z.B. die Kleineisel-Karte mit der IMHO schönsten amtliche-Topokarten-Optik ist noch schwerer zu finden als heute über die unübersichtliche Wiki-Seite. Während ich das hier schreibe, kommt mir grade noch eine 3. Idee: Wäre ein gemeinsamer Server für halbfertige Karten eine Möglichkeit. Damit meine ich: Anstatt alles neu zu erfinden oder nur fertige gmapsupp.img zu handeln, könnten interessierte Anbieter auch ihre einzelnen Garminkacheln und Typdatei hochstellen. Ein Server müßte dann nur noch alle Kacheln in einem Ausschnitt auswählen und zu einer gmapsupp.img packen um eine Wunschkarte zu erzeugen. Aber es ist nicht nötig, die gesamte Erstellung aller Karten zwingend zu vereinheitlichen. bye Nop -- View this message in context: http://gis.19327.n5.nabble.com/Feedback-vom-OpenStreetMap-Stand-auf-dem-GeoGames-Leipzig-Event-tp5714855p5715077.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
aighes o...@aighes.de wrote: mkgmap ist von Karte zu Karte unterschiedlich. Daran kann man nichts ändern. Ebenso die TYP-Files. Nichts anderes habe ich ja geschrieben. Dieser Aufruf ist halt zu teuer um ihn mal schnell on demand zu machen. Christoph hatte bei der AIO AFAIR ein System verwendet, dass über Postgis geschaut hat welche Kacheln in welchen Ländern liegen und hat die dann einzeln in mkgmap reingesteckt. Gruss Sven -- The term any key does not refer to a particular key on the keyboard. It simply means to strike any one of the keys on your keyboard or handheld screen. (Compaq FAQ Entry 2859) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
On 03.07.2012 17:18, Jochen Topf wrote: On Tue, Jul 03, 2012 at 04:24:43PM +0200, Ronnie Soak wrote: - oder ein neues Angebot unter eigener Kontrolle, welches aber das selbe Leistungsdpektrum abdeckt wie die bestehenden Einzellösungen - unglaublich aufwendig Also ich finde http://garmin.openstreetmap.nl/ macht schon sehr viel von dem, was wir wollen. Da müssen nur noch die anderen Styles rein und dann ordentlich Rechenpower dahinter. Und http://extract.bbbike.org/ ist auch einfach zu bedienen. Kein direkter Download, aber man bekommt eine Email mit Downloadlink wenn es fertig ist. Viele Grüße vom OSM-Stand auf der Agit... Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 16:30, schrieb Ronnie Soak: Also ICH sag das schon. Meiner Meinung nach ist der Komfortgewinn gegen eine Wikiliste nur unwesentlich, wenn hinter dem Link wieder bunte Seiten mit unterschiedlichen Bedienkonzepten stecken. Ich habe weniger den Eindruck, dass es daran scheitert, die ausgewählte Karte herunterzuladen. Sondern eher daran, die Karte überhaupt zu finden und das könnte man mit einem prominent verlinkten Portal prima lösen. Die bisherige Wiki-Seite hat zwei Probleme. Zum einen ist sie unübersichtlich und zum anderen findet man sie kaum. Zur weltweiten Abdeckung einer Karte: Das ist nicht immer sinnvoll. Bspw. weil die Straßenverhältnisse global sehr unterschiedlich sind und sich das leider nicht immer in den Tags widerspiegelt. Eine primary in Afrika sieht anders aus als hier bei uns, ist aber vollkommen richtig als primary getagt, sollte aber anders behandelt werden. Beim erstellen einer Karte trifft man gewisse Annahmen, weil Objekte in der Regel nicht vollständig getagt sind. Diese Annahmen sind aber eher regional gültig. Das global sinnvoll in ein Style-File zu bringen ist nicht trivial. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kurzer Bericht zur OSM Schnittstelle für GE Smallworld GIS
Hi Zusammen, wenn ich schon eingeladen werde, einen kurzen Vortrag über OSM und eine verfügbare Schnittstelle (nur lesender Zugriff) für GE Smallworld GIS zu halten, möchte ich Euch diesen kurz vorstellen und eine kleine Zusammenfassung über das Feedback liefern. Meinen Blogpost findet ihr hier: http://blazejaksgis.wordpress.com/2012/07/04/openstreetmap-und-ge-smallworld-gis -- Grüße aus dem Ruhrgebeat, Matthias Blazejak für OpenStreetMap und OSMRuhr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 4. Juli 2012 17:17 schrieb aighes o...@aighes.de: Das ist nicht immer sinnvoll. Bspw. weil die Straßenverhältnisse global sehr unterschiedlich sind und sich das leider nicht immer in den Tags widerspiegelt. Eine primary in Afrika sieht anders aus als hier bei uns, ist aber vollkommen richtig als primary getagt, sollte aber anders behandelt werden. verstehe ich nicht. Klar sieht eine primary in Afrika ggf. anders aus als eine in Mitteleuropa, aber inwiefern sollte die deswegen anders behandelt werden? Das Netz fürs Routing ist halt das, was es ist. Entweder gibt es eine kleinere Alternative, dann wird man die mit dem Fahrrad nehmen wollen, oder es gibt keine Alternative, dann wird man so oder so die Primary nehmen müssen. Mit dem Auto wird man wohl die größere Straße haben wollen. Ob das dann eine Sandpiste durch die Wüste ist (da gibt es dann sowieso kaum Alternativen) oder eine 4-spurige Asphaltstraße ist prinzipiell egal. M.E. wird sich einheitlicheres Tagging vor allem dann einstellen, wenn es auch Anwendungsmöglichkeiten (sprich abgeleitete Karten) gibt. Für die POIs wird man ggf. ein paar Mappings in anderen Kulturkreisen anders haben wollen, aber sehr vieles ist auch gleich (Restaurant, Tankstelle, Fast food, Hotel, Pension, Fremdenzimmer, Flughafen, Bahnhof, Busbahnhof, Taxistand etc. sind dann zwar sicher oft, was die dort angebotenen Services und Gepflogenheiten angeht, grundverschieden, aber einen Namen und eine Position haben die auch). Gruß Martin PS: ein bisschen utopischer Beitrag angesichts der realen OSM-Abdeckung in Afrika, ist mir bewusst. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 20:09, schrieb Martin Koppenhoefer: Am 4. Juli 2012 17:17 schrieb aighes o...@aighes.de: Das ist nicht immer sinnvoll. Bspw. weil die Straßenverhältnisse global sehr unterschiedlich sind und sich das leider nicht immer in den Tags widerspiegelt. Eine primary in Afrika sieht anders aus als hier bei uns, ist aber vollkommen richtig als primary getagt, sollte aber anders behandelt werden. verstehe ich nicht. Klar sieht eine primary in Afrika ggf. anders aus als eine in Mitteleuropa, aber inwiefern sollte die deswegen anders behandelt werden? Das Netz fürs Routing ist halt das, was es ist. Entweder gibt es eine kleinere Alternative, dann wird man die mit dem Fahrrad nehmen wollen, oder es gibt keine Alternative, dann wird man so oder so die Primary nehmen müssen. Mit dem Auto wird man wohl die größere Straße haben wollen. Ob das dann eine Sandpiste durch die Wüste ist (da gibt es dann sowieso kaum Alternativen) oder eine 4-spurige Asphaltstraße ist prinzipiell egal. M.E. wird sich einheitlicheres Tagging vor allem dann einstellen, wenn es auch Anwendungsmöglichkeiten (sprich abgeleitete Karten) gibt. Das Verkehrsaufkommen ist bspw. komplett anders. In Mitteleuropa würde ich als Radfahrer primarys meiden, wo es sinnvoll geht. In vielen anderen Ländern sieht das komplett anders aus. Wenn man nur eine Straße hat, ist es ohnehin egal. Aber wenn man mehrere zur Auswahl hat ist es eben schon ein Unterschied, ob ich primarys beforzugen sollte, weil die am besten mit dem Rad befahrbar sind oder ob ich eher Nebenstraßen bevorzuge, da diese ebenso gut ausgebaut sind und nur mäßigen Verkehr bieten. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit der Kuestenlinie auf Terceira
On 01.07.2012 20:55, fly wrote: On 01.07.2012 10:32, Manfred A. Reiter wrote: Am 30.06.2012 17:08 schrieb fly lowfligh...@googlemail.com: On 06/28/12 09:18, Manfred A. Reiter wrote: Am 25.06.12 schrieb Martin Koppenhoeferdieterdre...@gmail.com: Am 25. Juni 2012 19:02 schrieb Manfred A. Reiterma.rei...@gmail.com: Da ist ja noch einiges im Argen wenn ich die einsamen Punkte ohne Merkmal und Verbindung im Bereich Praia betrachte. Dort kam es zu Konflikten, wir haben aber die .osm files gesichert... Wenn Du die haben willst, kann ich sie gerne senden ... ich komme nicht vor Mitte Juli dazu Praia zu korrigiern. ... Weiß ja nicht wie groß Deine Dateien sind und wie die Konflikte aussehen, aber mal drauf schauen kann ich gerne. Hab mir mal die changesets angeschaut und jetzt wundert es mich nicht, dass Ihr Konflikte bekommt. Das sieht ja so aus als ob mehrere user gleichzeitig die Küstenlinien bearbeitet haben. Mit JOSM gibt sowas immer Konflikte (offline Editor), es sei denn man spricht sich vorher gut ab. Jeder ein anderes Dorf oder man teilt die Küstenlinie zu erst in mehrere Wege auf und jeder bearbeitet nur einen dieser Wege. Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schlecker XL
am Freitag, 29. Juni 2012 um 12:30 schrieb Michael Kugelmann: die Schlecker XL werden jetzt sehr wahrscheinlich auch platt gemacht (war gestern in den Nachrichten), siehe auch Wikipedia. Steht das XL irgendwo am Laden, oder wie erkennt man das? In 23626 Ratekau hatte heute der Schlecker-Markt immer noch geöffnet. Ist das ein XL-Markt? Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Guten Abend zusammen, um dem ganzen eine Linie zu geben: Der Einsatz ist vor allem in dem Szenario nützlich, dass man spontan Kacheln berechnen möchte. Overpass API ersetzt dann die Extraktion und den Splitter. Auf der anderen Seite läuft extract.bbbike.org eigentlich so gut, dass man das nicht nocheinmal neu entwickeln müsste. Dass jemand eine Änderung macht und diese sofort auf einem Kartenexport haben möchte, dürfte ein sehr ungewöhnlicher Fall sein. Für Kacheln im Batchprozess macht es vermutlich keinen so großen Unterschied zwischen Overpass API und einem optimierten Splitten in alle Teile parallel, als dass sich dafür eine neue Tool-Kette lohnen würde. Nach den Zahlen von 1h für das Splitten von ganz Deutschland sollte an dieser Stelle der Leidensdruck nicht hoch sein. Das klingt alles sehr gut, ich muss aber noch mal Nachfragen: Du sagts, ein Bundesland ist etwa die Grenze, die du mit der OverPass API ausschneiden würdest. Allerdingst sagst du dann, das gefiltert wesentlich weniger Daten anfallen. Bedeutet das, das gefiltert dann eine größere bbox möglich wäre? Oder ist der DatenINPUT gleich, und deswegen die Grenze konstant? Das ist im Wesentlichen eine Frage des Hauptspeichers. Mit 4 GB RAM geht Nordrhein-Westfalen (oder ca. 2% der Daten des Planet.osm). Mit entsprechend mehr RAM würden noch größere Teile funktionieren. Außerdem: wie skaliert das mit komplexeren Anfragen? Also nicht nur 2 Kriterien, sondern z.B. 200 ? Das wäre zu erproben. Letztlich hängt es sehr von der Abfrage ab. Intern wird recht schnell nur auf die Treffer reduziert, so dass die Anzahl der Kriterien keine große Rolle spielt. Leider haben wir da auch einen Catch22: Die OverPass API kann nur auf Kachelgröße arbeiten. Das Tool, das von einer vorgefilterten .osm Datei profitieren könnte ist aber gerade auch der Tile Splitter, wklcher uns wiederum als einziger sagen kann, wie groß die Kacheln sein sollen, wozu er aber ein Gesamt-OSM file braucht. Siehe oben. Ich denke nicht, dass der Tile Splitter profitiert, da Overpass API bei der Erzeugung mehrerer kleiner Extrakte etwa gleichschnell ist zu der Erzeugung eines großen Extrakts. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event
Am 04.07.2012 22:55, schrieb Roland Olbricht: um dem ganzen eine Linie zu geben: Der Einsatz ist vor allem in dem Szenario nützlich, dass man spontan Kacheln berechnen möchte. Overpass API ersetzt dann die Extraktion und den Splitter. Hallo, kann man denn ausschließen, dass es Inkompatibilitäten zwischen den Kacheln gibt, wenn diese zeitlich unterschiedlich erstellt werden. Wenn man nun bspw. eine Deutschlandkarte erstellen möchte mit 150 Tiles und jedes Tile nur 10s braucht, so sind das zwischen dem ersten und dem letzten auch schon 25min. Viel mit cachen kann man in der Kette dann auch nicht machen. Es wäre nun nicht gerade zielführend, wenn das Routing scheitert, weil sich die Daten zwischen TileA und TileB unterscheiden. Oder man stellt die OverpassAPI so ein, dass sie sich keine Updates holt, bzw. nur einmal am Tag etc. und dann alle gecacheten Tiles gelöscht werden. Aber ich denke dann wäre es auch wieder sinnvoller für diesen fixen Zeitpunkt den splitter auf einem planet laufen zu lassen und alle nötigen Tiles zu erzeugen. Aus diesen Tiles kann man dann entweder OnDemand die angeforderten Kartentiles erzeugen und zu Karten verknüpfen oder man rechnet (auf einem performanten Server) permanent alle Kartentiles und überlässt das Zusammenfügen zu einer Karte und das ausliefern einem schwächeren Server. Wobei ich allgemein bei diesem Weg das Gefühl hab, dass man bei vielen Karten mit dem Rechnen nicht hinterher kommt. Sei es nun OnDemand oder per batch. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
