> > > Die Styles stehen zur Verfügung. Das ist kein Problem. Das Problem sehe ich > eher in der Rechenpower. Man müsste quasi pro Karte jede Garmin-Kachel > einmal rechnen. Ich weiß nicht, ob das realistisch und sinnvoll ist.
Natürlich wieder on Demand und mit Caching, so wie das bei Lambertus jetzt auch ist. Da muss man nicht gleich die ganze Welt vorrechnen. Aber ansonsten: Ja, genau das wird ja jetzt auch gemacht. Nur halt über viele Anbieter verteilt. > > > Die Toolchain ist in der Regel einheitlich bzw. ähnlich. Wobei es natürlich > schon Unterschiede gibt. Bspw. mit Höhenlinien und ohne etc. Aber das dürfte > sich auch lösen lassen. Das Problem ist die Rechenpower ;) > Ja, das ist in der Tat das Problem. Sicher gibt keiner der bisherigen Anbieter mal eben seine Rechenpower für so einen gemeinschaftlichen Ansatz her. Ich würde mein mühsam zusammengeklöppeltes Spielzeug sicher auch nicht unter Fremdkontrolle stellen. Allerdings könnte ich mir schon vorstellen, dass das recht gnädig skaliert. Sprich: bei zu hohem Ansturm verlängern sich einfach die Wartezeiten, was automatisch den Ansturm abschwellen läst. Lambertus macht momentan ja auch nichts anderes, als die Kacheln frisch zu berechnen (und eine Weile zu cachen.) Höher wäre die Last nur, weil dass eben mehr Leute nutzen würden, wenn es vielseitiger ist und man es prominent verlinkt. BTW: ist das erzeugen großer, aussortierter Datenpakete mit der Overpass-API eigentlich effizienter als das aussortieren unbrauchbarer Objekte direkt mit mkgmap? Gruss, Chaos _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
