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 W
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.
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
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).
D
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
Am 5. Juli 2012 13:22 schrieb aighes :
> 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 das Zusamme
Am 5. Juli 2012 13:58 schrieb Rainer Kluge :
> 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 ungeplanterweise e
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 Ansp
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 große
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 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 Las
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 de
>
> 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 d
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 breite
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 u
>
> 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 neh
Am 5. Juli 2012 11:03 schrieb NopMap :
>
>
> 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 Wandermark
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
blei
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.
Am 5. Juli 2012 08:42 schrieb Rainer Kluge :
> 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 ist unabhängig
-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
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 mach
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
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 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
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
nich
Am 04.07.2012 20:09, schrieb Martin Koppenhoefer:
Am 4. Juli 2012 17:17 schrieb aighes :
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 b
Am 4. Juli 2012 17:17 schrieb aighes :
> 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 prima
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 au
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://g
>
> 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ß.
Also ICH sag das schon. Meiner Meinung nach ist der Komfortgewinn
gegen eine Wikiliste
nur unwesentlich, wenn hinter dem
aighes 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
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.
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 mkg
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.
Am 04.07.2012 14:29, schrieb Sven Geggus:
aighes 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
Am 4. Juli 2012 14:38 schrieb NopMap :
> 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 Zu
Am 04.07.2012 14:43, schrieb Sven Geggus:
aighes 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.
aighes 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 unter
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
aighes 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
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 F
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 v
aighes 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
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 Kart
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
> 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
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 P
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
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
sonstw
Am 4. Juli 2012 11:03 schrieb Roland Olbricht :
>
> 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 Mi
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 h
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 :
Mit einer guten, neutralen Übersichtsseite, die dann auf die
Downloadseiten verlinkt hat sicher keiner ein Problem.
Dennoch würde ich eine Listung
On Tue, Jul 03, 2012 at 04:24:43PM +0200, Ronnie Soak wrote:
> Am 3. Juli 2012 15:48 schrieb aighes :
>
> >
> >> 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 Anbie
> 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
Am 04.07.2012 09:40, schrieb Ronnie Soak:
Am 4. Juli 2012 09:09 schrieb Carsten Schwede :
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, meinetweg
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
Hallo,
On 07/04/12 09:40, Ronnie Soak wrote:
Das hatten wir schon mal in alten Threads und am Anfang dieser Diskussion:
ich wollte das ja auch nur nochmal zusammenfassen ohne an den Anfang des
Threads zu springen.
Aber wo du gerade den kleinen Finger reichst: Würdest du (rein
hypothetisch
Hi,
On 07/04/12 09:09, Carsten Schwede wrote:
Das Hackerwochenende wäre auch ne gute Idee, wenns nicht so sehr weit
von Frankfurt entfernt wäre. :-)
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
Am 4. Juli 2012 09:09 schrieb Carsten Schwede :
> 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
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 ei
Am 3. Juli 2012 22:00 schrieb Frederik Ramm :
> 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 basteln. Der U
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:
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
>
> 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
>
>
> 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
jet
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
Am 03.07.2012 18:58, schrieb Ronnie Soak:
Am 3. Juli 2012 17:18 schrieb Jochen Topf :
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 Lie
Am 3. Juli 2012 17:18 schrieb Jochen Topf :
>
>
> 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 gibt es
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 03.07.2012 16:43, schrieb Sven Geggus:
Ronnie Soak 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
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 de
aighes 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 integriert un
Ronnie Soak 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 Problem ist doch, dass wir
Am 3. Juli 2012 15:48 schrieb aighes :
>
>> 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 erzeug
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 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
Am 03.07.2012 14:12, schrieb Sven Geggus:
Ronnie Soak 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 h
>
>
> 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
Ronnie Soak 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 dennoch: Wollen wir etwas
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
81 matches
Mail list logo
