Hallo,
Was Du dabei übersiehst, ist daß es grade bei den Kartenerstellern, die sich
besonders viel Mühe gegeben haben, technisch gar nicht machbar ist. Es ist
mit einem Standard-mkgmap schlichtweg nicht möglich, Routen-Underlays und
kombinierte Wandermarkierungen wie in der Reit- und
Hallo Henning,
Am 05.07.2012 00:50, schrieb aighes:
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.
Das Gefühl habe ich auch und da liegt auch ein gewisser Widerspruch in der
Diskussion.
Am 05.07.2012 08:42, schrieb Rainer Kluge:
Ausgangspunkt ist, dass die Nutzung der Garmin-Karten für ein breites
Publikum erleichtert werden soll, um möglichst viele Nutzer zu
gewinnen. Andererseits werden Lösungen mit flexibler Konfiguration und
Gebietsauswahl angedacht, die für jeden Zugriff
Hi,
Rainer Kluge schrieb:
Was man aus meiner Sicht braucht, sind eine Handvoll Kartentypen,
tagesaktuelle Karten für die wichtigsten Länder, wochenaktuelle Karten
für die Hauptreiseländer und für den Rest der Welt Karten on Demand mit
Wochencache. Ausschneiden und Mergen kann jeder selbst
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2012-07-04 14:38, NopMap wrote:
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.
Am 5. Juli 2012 08:42 schrieb Rainer Kluge rklug...@web.de:
Mit steigender Zahl der Abrufe verlängern sich also die
Wartezeiten, die Akzeptanz sinkt, die Nutzerzahl stagniert oder geht zurück.
Wir können nicht mehr Nutzer bedienen, als wir Kapazität haben. Da ist
halt irgend wann Schluss.
Das
Ronnie Soak wrote
Ja, die Leute werden das als 'Die OSM-Garmin-Karte' wahrnehmen. Aber
genau das suchen sie ja auch. Und ich bin dafür, dort so viele der
bestehenden Styles wie möglich zu integrieren. Das kommt natürlich
darauf an, ob die Originalanbieter sie mit uns teilen oder nicht.
Hallo Henning,
Am 05.07.2012 09:36, schrieb aighes:
Ich nehm' dich jetzt mal und mach die Hand voll, also 5 Karten. Eine Karte fürs
Motorad, eine fürs Auto, eine für den Wanderer, eine für den Radfahrer und eine
für den Wassersportler. Doch was ist dann mit dem LKW-Faher oder dem Reiter? Wo
Am 5. Juli 2012 11:03 schrieb NopMap ekkeh...@gmx.de:
Was Du dabei übersiehst, ist daß es grade bei den Kartenerstellern, die sich
besonders viel Mühe gegeben haben, technisch gar nicht machbar ist. Es ist
mit einem Standard-mkgmap schlichtweg nicht möglich, Routen-Underlays und
kombinierte
Es ist aber gerade diese Vielfalt, die dem Normalnutzer das Auffinden und
Nutzen so schwer macht. Das kann man durch ein zentrales Portal etwas
reduzieren aber der gemeine Radfahrer fragt sich dann immer noch, soll ich
die OpenMTB, die OpenVelo, die Karte vom Henning oder die vom Ralf nehmen.
Hallo Rainer,
mir geht es nicht primär um die Optik der Karte sondern um den Unterbau
(Routing). Die OpenMTBMap routet halt so, dass MTB'ler zufrieden sind,
die VeloMap eher mehr für die Rennräder.
Der Motoradfahrer möchte evtl. eher auf den Landstraßen fahren der
Autofahrer eher Autobahnen
Am 05.07.2012 11:38, schrieb Ronnie Soak:
Deshalb klappt das alles nur MIT den Kartenanbietern. Wenn diese ihre
Toolchain nicht offenlegen wollen,
dann klappt das natürlich nicht. Mag sein, dass der einen oder andere
das als 'Betriebsgeheimnis' sieht, ich hoffe aber eigentlich, dass dem
im
Wenn, dann würde ich es eher so sehen, dass die Karte dann nur dort
gerendert wird. Es macht schließlich nicht viel Sinn, eine Karte an zwei
Orten anzubieten.
Naja, das ist dann aber entscheidung des originalen Kartenanbieters.
Der wird sicher noch selbst spielen wollen.
Wie wäre es denn,
Rainer Kluge wrote:
Gut, ich bin vielleicht etwas zu sehr Fahrrad- und Fußgänger-zentriert,
aber ich glaube nicht, dass es mehr als eine Karte pro Nutzergruppe
braucht, wobei man wahrscheinlich Radfahrer, Reiter und Wanderer
zusammenfassen kann, ebenso wie Pkw-, Motorrad- und Lkw-Fahrer. Bei
Am 05.07.2012 12:19, schrieb aighes:
Wie wäre es denn, wenn man gewisse Regionen (auch abhängig von der
Kartenart) vorrendert und nur den Rest OnDemand macht. Ich meine so
Standardregionen wie Deutschland, etc. Das könnte man dann einmal in
der Woche oder im Monat rechnen lassen, wenn wenig
Am 05.07.2012 12:51, schrieb Ronnie Soak:
Leider bekomm ich die kachelweise Auswahl, wie sie Lambertus macht,
noch nicht so im Konzept unter. Wir brauchen ja die Länder als
Gruppierung und ID für den Cache. Ich persönliche finde die
Kachelweise Auswahl aber auch extrem nützlich. Ich muss da noch
Am 05.07.2012 13:01, schrieb Peter Wendorff:
Soweit ich das in Erinnerung habe, gibt es mehrere Grenzen:
1) Größe der Karte insgesamt - relativ stark begrenzt, das wurde bei
der AIO immer mal wieder zum Problem
2) Größe einzelner Kacheln innerhalb der Datei: Eine Kachel kann eine
beliebig
Am 05.07.2012 12:55, schrieb Andreas Titz:
Rainer Kluge wrote:
Aber wenn mir jemand erklären kann, warum Otto-Normalnutzer zum Rennradfahren
eine OpenVelo und zum MTBen eine OpenMTB braucht, dann revidiere ich gerne
meinen Standpunkt.
Grade die Gruppe der Radfahrer hat so unterschiedliche
Am 5. Juli 2012 13:58 schrieb Rainer Kluge rklug...@web.de:
Die Bedeutung des Routings für den Outdoor-Bereich wird überschätzt. Die
Masse der Nutzer aus diesem Bereich plant die Tour am PC oder lädt sie von
GPSies herunter. Das Routing wird nur in Ausnahmesituationen genutzt, wenn
man
Am 5. Juli 2012 13:22 schrieb aighes o...@aighes.de:
Ich weiß nicht wie sehr du beim Erstellen von Garminkarten in der Materie
drin steckst. Mal am Beispeil von Deutschland erklärt. Wenn man mkgmap die
pbf-Kacheln gibt, rechnet er bei mir ~37min diese in img-Kacheln um. Dann
folgen ~3min für
Hallo Rainer,
da bin ich mir nicht so sicher. Sicherlich radeln die meisten auf dem
Gerät via Tracks, die vorher geplant wurden. Meine Erfahrung ist aber
eher, dass diese Tracks primär übers Routing erstellt werden. Das ist
einfach viel schneller, als alle 20m einen Mausklick zu machen. Diese
Rainer Kluge wrote:
Am 05.07.2012 12:55, schrieb Andreas Titz:
Der Rennradfahrer will, dass alles, was nicht surface=asphalt hat,
abgewertet
wird und Radwege sowieso vermieden werden (weil die selten mit 30km/h
- einer
für Rennradfahrer durchaus üblichen Geschwindigkeit - befahrbar sind).
Hier die Antwort von Lambertus:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q3/014710.html
Henning
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Am 05.07.2012 14:55, schrieb Andreas Titz:
Rainer Kluge wrote:
Das setzt voraus, dass Surface flächendeckend und zuverlässig getaggt ist. ich
halte die Auswertung solcher Tags bei der Planung, z.B. mit OpenRouteService,
für durchaus sinnvoll, aber draußen würde ich mich darauf nicht verlassen.
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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,
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
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
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
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,
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
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
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
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.
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
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
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
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
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
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
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
Hallo Liste,
ich habe hier [1] mal verbloggt, was ich so an Feedback bei der
Standbetreuung und dem Vortrag auf der GeoGames in Leipzig bekommen habe.
Einige Themen würde ich druchaus gerne mal mit anderen OSMlern diskutieren.
Wilde Ideenfindung erwünscht!
1) Leidiges Thema Garminkarten und ihre
Ronnie Soak chaoschaos0...@googlemail.com wrote:
1) Leidiges Thema Garminkarten und ihre Präsentation. Das wurde schon
öfters mal diskutiert: Garminkarten sind nicht unser Fokus, das liegt bei
externen Anbieter, da haben wir keine Kontrolle drüber und wir können das
nicht aktuell halten. Aber
Die FOSSGIS Server stehen zur Produktion aktueller Karten prinzipiell zur
Verfügung.
Das ist generell schon mal ein +1 wert.
Derzeitiger Stand ist, dass die Computerteddy-Karte dort
hergestellt wird. Die Erzeugung der AIO ist AFAIK leider eingeschlafen.
Das Problem, das ich hier
Am 03.07.2012 14:12, schrieb Sven Geggus:
Ronnie Soak chaoschaos0...@googlemail.com wrote:
1) Leidiges Thema Garminkarten und ihre Präsentation. Das wurde schon
öfters mal diskutiert: Garminkarten sind nicht unser Fokus, das liegt bei
externen Anbieter, da haben wir keine Kontrolle drüber und
Am 03.07.2012 14:50, schrieb Ronnie Soak:
Viele der Leute am Stand waren völlig überrascht, dass es mehr als eine
Garmin-Karte gibt. Wenn man ihnen dann aber erklärt, wie sie da dran
kommen, winken sie ab. Ein rohes http/ftp Listing kann man heute halt
keinem Endnutzer mehr zumuten. Genausowenig
Hallo,
On 07/03/12 15:37, aighes wrote:
Die Verbreitung der Karten passiert derzeit primär über
Mund-zu-Mund-Propaganda in diversen Foren etc.
Bei mir in der Geofabrik rufen auch recht oft Leute an, die den
Geofabrik-Downloadserver gefunden haben und nun wissen wollen: Wie
kriege ich das
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
Ronnie Soak chaoschaos0...@googlemail.com wrote:
Ein rohes http/ftp Listing kann man heute halt keinem Endnutzer mehr
zumuten. Genausowenig wie Wiki-Userseiten.
Das ist nicht so sehr das Problem. Man könnte ja zumnindest auf
openstreetmap.de einen prominenten link zu Garminkarten anlegen.
Das
aighes o...@aighes.de wrote:
Neben dem Austausch des Links wäre eine übersichtliche Übersichtsseite
eine gute Sache (wurde glaub ich auch schon mal drüber hier oder im
Forum-de diskutiert).
Die http://openstreetmap.de Webseite ist im SVN. Wenn jemand da eine Seite
mit Garminkartenlistings
Hallo,
vorweg: deine beiden Sackgassen sind für mich auch keine sinnvollen
Lösungen.
Am 03.07.2012 16:24, schrieb Ronnie Soak:
Ja, das waren in etwa so die Argumente aus den vorherigen Diskussionen:
- man darf den Leuten nicht mehr Traffic schicken, wegen Begrenzungen
Nicht ganz: Man sollte
Am 03.07.2012 16:43, schrieb Sven Geggus:
Ronnie Soak chaoschaos0...@googlemail.com wrote:
Ein rohes http/ftp Listing kann man heute halt keinem Endnutzer mehr
zumuten. Genausowenig wie Wiki-Userseiten.
Das ist nicht so sehr das Problem. Man könnte ja zumnindest auf
openstreetmap.de einen
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
Am 3. Juli 2012 17:18 schrieb Jochen Topf joc...@remote.org:
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.
Ja, das ist auch meine Lieblingskarte. Neuerdings
Am 03.07.2012 18:58, schrieb Ronnie Soak:
Am 3. Juli 2012 17:18 schrieb Jochen Topf joc...@remote.org:
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.
Ja, das
On Tue, Jul 03, 2012 at 08:22:51PM +0200, aighes wrote:
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 ;)
Man setzt nen Rechner
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
Man setzt nen Rechner auf, der kontinuierlich Updates rechnet. Um so schneller
der ist, um so häufiger gibt es Updates. Wenns mehr Styles gibt, dann geht
halt für jeden einzelnen Style langsamer. Dann macht man einen Spendenbutton
auf die Seite und sagt: Um so mehr Geld zusammen kommt, um so
Hi,
On 03.07.2012 21:22, Ronnie Soak wrote:
Use Case: Nutzer wählt aus Dropdown zB. den VeloMap Style aus, klickt
sich aber noch die Höhenlinien dazu und dafür die Gebäudeumrisse raus.
Außerdem hätte er gerne Schutzhütten und Parkbänke drin, kann aber auf
die Restaurants verzichten.
Waren wir
Am 03.07.2012 21:22, schrieb Ronnie Soak:
Man setzt nen Rechner auf, der kontinuierlich Updates rechnet. Um so schneller
der ist, um so häufiger gibt es Updates. Wenns mehr Styles gibt, dann geht
halt für jeden einzelnen Style langsamer. Dann macht man einen Spendenbutton
auf die Seite und sagt:
Am 3. Juli 2012 22:00 schrieb Frederik Ramm frede...@remote.org:
Waren wir uns nicht gerade eben noch fast einig, dass das Erstellen von
Garminkarten zu kompliziert ist ;)
Was Du da schilderst, ist vielleicht ein Traum fuer den Power-User, aber der
kann sich das heute auch schon alles selbst
78 matches
Mail list logo
