subject:"Re\: \[Talk\-de\] Feedback vom OpenStreetMap\-Stand auf dem GeoGames Leipzig Event"


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.


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 mindestens das Mergen der Tiles zu einem gmapsupp erfordern. 
Mit steigender Zahl der  Abrufe verlängern sich also die Wartezeiten, die 
Akzeptanz sinkt, die Nutzerzahl stagniert oder geht zurück.


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 machen.


Damit deckt man sicher weit mehr als 90% des Bedarfs der Normalnutzer ab. Für 
die Power-User, Aktualitätsfreaks und User mit ausgeprägtem Spieltrieb kann man 
ja einen OnDemand-Dienst einrichten. Aber die sind hier doch nicht das Thema.


Gruß
Rainer



___
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 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 mindestens das Mergen 
der Tiles zu einem gmapsupp erfordern. Mit steigender Zahl der  Abrufe 
verlängern sich also die Wartezeiten, die Akzeptanz sinkt, die 
Nutzerzahl stagniert oder geht zurück.


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 machen. 


Das Problem ist eher: Wie bringen wir den Nutzern die Vielfalt an OSM 
Karten näher, sodass sich jeder eine für ihn passende Karte auswählen kann.


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 bleiben die unterschiedlichen Bedürfnisse 
der Radfahrer?


Wenn man eine Auswahl trifft, dann kommt bei dem Nutzer als Botschaft 
an: Das sind DIE OSM-Karten und der Rest sind irgendetwas anderes. Das 
Problem haben wir derzeit schon bei den Online-Karten und eine 
Wiederholung sollte man sich meiner Meinung sparen.


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

2012-07-05 Diskussionsfäden Pascal Neis


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 machen.


Damit deckt man sicher weit mehr als 90% des Bedarfs der Normalnutzer 
ab. Für die Power-User, Aktualitätsfreaks und User mit ausgeprägtem 
Spieltrieb kann man ja einen OnDemand-Dienst einrichten. Aber die sind 
hier doch nicht das Thema.


ich habe nicht die ganze Diskussion verfolgt. Ich stimmt hier
aber Rainer zu. Es muss m.M. so einfach sein wie es nur geht.
+1

viele gruesse
pascal


___
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

2012-07-05 Diskussionsfäden Lars Schimmer

-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. 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.

My 2 cent:
Ich plante eine Radtour Graz-Split, also Österreich, Slovenien,
Kroatien. Ich habe einen Garmin eTrex Legend, ich wollte eine Karte
mit Routing und Höhenlinien und Radwegen für die gesamte Strecke mit
dabei haben.
Ich habe letztes Jahr im Oktober angefangen zu suchen und habe mit
Google nur so 5-6 verschiedene Garmin OSM Karten gefunden.
Die Wiki Seite habe ich erst viel später gefunden und dann waren da
meistens keine brauchbaren Links drauf.
Ich hab sogar versucht, eine eigene Karte zu bauen - was auch nicht
viel gebracht hatte.

Ich bin dann bei der reitwanderkarte Jänner 2012 hängen geblieben,
ohne Routing. Einfach weil sie einfach zu finden war, mein Gebiet
abgeckt hat und mässig aktuell war.
Jetzt nach der Tour habe ich noch einige, kleine, privaten Karten
gefunden dank der Mailingliste.

Was fehlt ist eine einfach, gute, ZENTRALE Übersichtseite auf z.b.
Openstreetmap.de mit Links zu anderen Seiten mit den Garmin Karten.
Sonst findet man die NIE. Dort sollten die Kartenersteller ihre Karten
beschreiben (Features) und den Link zur Webseite setzen.
Was nutzt es dem Kartenersteller, wenn nur 5 Leute den Link zu seiner
Karte kennen?

Dazu wäre natürlich das Bauen von Karten auf Demand interessant,
bzw. das bauen von nachgefragten Karten auf Vorrat jede Woche/Monat.

Der gemeine OSM User will halt einfach eine Karte von der Region, die
er befährt, haben mit gewissen Features.
Bei mir war das halt nord-ex-yugoslavien mit Höhenlinien und Radwegen
(und Routing).
Dem Endanwender ist es egal, ob er die direkt downloaden kann oder mit
den letztn 10 Namensänderungen neu gebaut werden muß - solange er die
Karte schnell und einfach findet!


 bye Nop

MfG,
Lars Schimmer
- -- 
- -
TU Graz, Institut für ComputerGraphik  WissensVisualisierung
Tel: +43 316 873-5405   E-Mail: l.schim...@cgv.tugraz.at
Fax: +43 316 873-5402   PGP-Key-ID: 0x4A9B1723


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/1R88ACgkQmWhuE0qbFyMGVwCggNNbjwMgk9tEUSjooW9QtN7Z
8oQAn3b+uUExUbm2E9KS7looFu7U2CJp
=K0aO
-END PGP 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 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 ist unabhängig vom Konzept. Das ist eine Finanzierungsfrage.
Ja, wir haben weniger Kapazität, wenn war alles von unserem Server
bedienen lassen als von 10+ Einzelleuten mit ihren Heimrechner,
aber was nutzt es (den Usern), wenn deren Karten nicht gefunden werden.
Ausserdem haben wir mit der Aktualisierungsrate, Abdeckung und dem
Cache ein paar gute Schrauben, an denen wir zur Auslastungsoptimierung
drehen können.


 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 machen.


1. Meiner Meinung nach kann dass Mergen und Ausschneiden nicht jeder
selber machen.
2. Du willst also die Anzahl der verfügbaren Styles beschränken, dafür
fixe Aktualisierungsintervalle festlegen und auch
Kleintupfistan vorrechnen (wenn auch selten)? Bist du sicher dass das
die richtige Richtung ist, in die du optimierst?

Bei on demand musst du die Anzahl der Styles nicht beschränken, kannst
die Aktualisierungsintervalle je nach Serverlast anpassen und
Kleintupfistan erst dann berechnen, wenn da auch wirklich jemand in
den Urlaub hin will.

Bei einer statischen Lösung musst du immer eine Konfiguration finden,
mit der du deinen Server optimal auslastest und hast dann keine
Möglichkeit mehr, etwas hinzuzunehmen. Die Last ist 95%, egal, wer
wann welche Karte haben will.

Nimmst du bei on demand dieselbe Aktualisierungshäufigkeit, Abdeckung
und Styleangebot an, hast du schonmal garantiert weniger Last, weil
zum Beispiel in dem Monat keiner sich für Grönland interessiert. Die
frei gewordene Zeit kannst du dann z.B. in einen neuen Style oder in
eine aktuellere Deutschlandkarte stecken.

Und der Rechenaufwand zur Erstellung der Karte ist bei beiden
Varianten die selbe. On demand heisst ja auch nicht, dass wir die
Karten häufiger aktualisieren.

Den einzigen Nachteil den ich sehe: Bei vorgerechneten Karten ist es
minimal einfacher, dass uns jemand 'Rechenzeit spendet', in dem er uns
eine fertige Karte von seinem Server spiegeln lässt. Bei on demand
muss die sehr genau zu unserem Anfrageverfahren passen, damit wir die
in den Cache übernehmen können.


 Damit deckt man sicher weit mehr als 90% des Bedarfs der Normalnutzer ab.
 Für die Power-User, Aktualitätsfreaks und User mit ausgeprägtem Spieltrieb
 kann man ja einen OnDemand-Dienst einrichten. Aber die sind hier doch nicht
 das Thema.


Und nochmal: wo ist der Unterschied? Die Systeme unterscheiden sich
nicht in Aktualisierungshäufigkeit, Abdeckung oder Styleangebot.
(Ich beziehe mich jetzt mal auf eine Variante, die nur die bestehenden
Styles zusammenfasst, und keine detailierte Stylekonfiguration
zulässt.)


Zum Thema Style-Verarmung:

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. Wer
'Geheimtipp' bleiben möchte, dem ist das sein gutes Recht. Auch wird
die Liste der externen Anbieter nicht verschwinden. Vielleicht wird
die eine oder andere Spezialkarte sogar besser, weil bei uns
vielleicht häufiger aktualisiert oder für mehr Länder verfügbar. Ich
seh das hauptsächlich als Gewinn.



Gruss,

Stefan

PS: Ich halte 'Wartezeit' immernoch für die Größe, bei der die Nutzer
die meisten Kompromisse einzugehen bereit sind. Wenn sie dafür einen
zentralen Anlaufpunkt und ein (fast) 1-Kilck System bis zur Karte
bekommen.

___
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

2012-07-05 Diskussionsfäden NopMap


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.
 

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 Wanderkarte angezeigt zu
erzeugen.

Von daher kann ich nur nochmal wiederholen, daß man mit so einem
Standardkartengenerator die Situation für den unbedarften Nutzer gegenüber
heute nochmal verschlechtert: Es wird noch schwerer für ihn, die Vielfalt an
Karten zu finden, weil er glaubt er hätte DIE Karte schon gefunden.
(Mapnik-Effekt).

bye
  Nop



--
View this message in context: 
http://gis.19327.n5.nabble.com/Feedback-vom-OpenStreetMap-Stand-auf-dem-GeoGames-Leipzig-Event-tp5714855p5715173.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


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
bleiben die unterschiedlichen Bedürfnisse der Radfahrer?


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 den Navi-Herstellern gibt es diese Vielfalt 
meines Wissens auch nicht. Damit will ich keineswegs die Vielfalt der 
OSM-Garmin-Karten kritisieren oder als überflüssig darstellen. Ich baue mir die 
Garminkarte mit meinem eigenen Stil auch selbst.


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. Er probiert sie dann 
alle aus, jede ist irgendwie anders, aber wie genau bleibt ihm unklar. Er hat 
ein Problem bei der Installation oder Nutzung, er schiebt es auf die Karte, 
wechselt zur nächsten, hat ein anderes Problem, und irgendwann gibt er es auf 
und geht zur Garmin Topo zurück. Wenn ich die Fragen auf dem Radreise-Forum 
sehe, dann halte ich diese Darstellung nicht für überzogen, und nicht jeder 
findet den Weg in ein solches Forum, wo ihm geholfen wird.


Mich erinnert die Situation an Opensource und Linux, wo der Durchbruch auch erst 
kam, als sich Ubuntu durchgesetzt hat. Mein Fazit ist daher: Entweder die Macher 
der verbreitetsten Karten einigen sich auf jeweils einen Karte pro Zielgruppe, 
die dann auf einem zentralen Portal als *die* Karte für die jeweilige Zielgruppe 
angeboten wird. Die anderen Karten werden weiter gepflegt, auf dem Portal wird 
aber nur auf die spezifischen Eigenschaften der Karte hingewiesen und auf die 
Macherseite verlinkt. Oder die OpenMTB/Velomap wird irgendwann von alleine zum 
Quasi-Standard für Outdoor-Navigation, dann hat sich das Thema erledigt. An eine 
breite Nutzung von OSM-basierten Karten für Pkw-, Lkw- und Motorrad-Navigation 
glaube ich ohnehin nicht.


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.


Gruß
Rainer


___
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 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 Wandermarkierungen wie in der Reit- und Wanderkarte angezeigt zu
 erzeugen.

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 breiten Feld nicht so ist.

Deshalb auch die schon erwähnte Ausrichtung durchaus auch FÜR den
(potentiellen) Kartenabieter. Das wäre auch eine Plattform FÜR ihn, wo
er seine Karte an einem zentralen 'Marktplatz' anbieten kann.

Technisch läuft das natürlich darauf hinaus, die Toolchain des
Anbieters auf dem zentralen Server zu clonen. Wo sich Gemeinsamkeiten
finden klappt das sicher sehr gut (lediglich style-/typfiles
anpassen), wo Spezialtools nötig sind ist es aufwendiger (spezielle
mkgmap-version, zusätzliche Datenimports von extern etc.). Ich denke
an technische Grnezen stossen wir erst dann, wenn die Karte mittels
Handarbeit und irgend welchen Windows-only tools erstellt wurde. Dann
bleibt uns wirklich nur das Spiegeln der fertigen Karten.

Ich sehe das Problem dann eher in der Aktualisierung der toolchain.
Wenn der Kartenanbieter einen Bug fixt, mag er uns wahrscheinlich
nicht extra Bescheid sagen oder es gar an 2 Stellen ändern (selbst
wenn er das z.B. über einen SVN Zugang könnte.) Wir bleiben dann also
auf der alten Version sitzen.



 Von daher kann ich nur nochmal wiederholen, daß man mit so einem
 Standardkartengenerator die Situation für den unbedarften Nutzer gegenüber
 heute nochmal verschlechtert: Es wird noch schwerer für ihn, die Vielfalt an
 Karten zu finden, weil er glaubt er hätte DIE Karte schon gefunden.
 (Mapnik-Effekt).

Wenn ich ihm auf so einem Portal 5+ Stile präsentieren kann, wieso ist
dass dann schlechter als die Variante, wo er immer nur 1 pro
Anbieterseite findet?
Und jede Art von hübsch sortierter Liste hätte ja das selbe Problem,
nicht alle Karten aufzulisten. Plus dass es die Karten eben nicht
'anbietet', sondern wieder nur auf verschlungene Anbieterseiten
verweist.

Jetzt kannst du dir entweder die Mühe machen, die Karten in deiner
Liste so toll zu beschreiben (Featurelisten, Screenshots auf allen
Geräten, Kompatibilität, Abdeckung, Aktualität) und das alles
up-to-date zu halten, damit der Nutzer wenigstens mit dem ersten Klick
den richtigen Anbieter trifft.

Oder du machst es einfach so einfach, die eigentliche Karte zu laden,
dass der Nutzer das auf seinem eigenen Gerät einfach für 3 Kandidaten
durchprobieren kann.

Ich bin für letzteres.

Gruss,

Chaos

PS: Ihr merkt schon, dass ich mich da ein wenig in die Idee verbissen
habe, oder?

___
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


 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.
 Er probiert sie dann alle aus, jede ist irgendwie anders, aber wie genau
 bleibt ihm unklar.

Ja, das hab ich auch bemerkt. Leider wird kaum ein Anbieter selbst die
Unterschiede so genau benennen können, weil er ja die anderen Karten
nicht kennt. Meine einzige Idee bleibt da, das selbst-ausprobieren so
einfach wie irgend möglich zu machen.



 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.

Ich denke die Unterschiede (zwischen Karten generell) betreffen auch
die Sichtbarkeit auf alten/neuen Geräten sowie oft das Routing und die
Adresssuche.
Mit/Ohne Höhenlinien, mit/ohne Symbolen an den Wegen/ welche POIs sind
dabei, welche nicht, dasselbe für ways (Stromleitungen anyone?) und
dann natürlich das weite Feld Optik.

Ich denke Möglichkeiten zur Differenzierung gibt es genug.

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


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 und der Spediteur wieder anders.


Im Kartenbild kann das aber auch unterschiedlich sein. Hervorhebung von 
Wanderwegen vs. Radwegen vs. Wasserwanderwegen. Oder Hervorhebung von 
Mautstrecken. Hier kommt es halt immer drauf an wie sehr man die Wege 
optisch unterschiedlich differenzieren möchte. Packt man alles in eine 
Karte rein, kann das auch sehr unübersichtlich werden.


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 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 breiten Feld nicht so ist.

Deshalb auch die schon erwähnte Ausrichtung durchaus auch FÜR den
(potentiellen) Kartenabieter. Das wäre auch eine Plattform FÜR ihn, wo
er seine Karte an einem zentralen 'Marktplatz' anbieten kann.

Technisch läuft das natürlich darauf hinaus, die Toolchain des
Anbieters auf dem zentralen Server zu clonen. Wo sich Gemeinsamkeiten
finden klappt das sicher sehr gut (lediglich style-/typfiles
anpassen), wo Spezialtools nötig sind ist es aufwendiger (spezielle
mkgmap-version, zusätzliche Datenimports von extern etc.). Ich denke
an technische Grnezen stossen wir erst dann, wenn die Karte mittels
Handarbeit und irgend welchen Windows-only tools erstellt wurde. Dann
bleibt uns wirklich nur das Spiegeln der fertigen Karten.

Ich sehe das Problem dann eher in der Aktualisierung der toolchain.
Wenn der Kartenanbieter einen Bug fixt, mag er uns wahrscheinlich
nicht extra Bescheid sagen oder es gar an 2 Stellen ändern (selbst
wenn er das z.B. über einen SVN Zugang könnte.) Wir bleiben dann also
auf der alten Version sitzen.
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.


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 Last ist. Dann spart man 
sich für so Standardzeug die Rechenarbeit.


Kleine Länder kann man wirklich OnDemand rechnen. Dänemark rechnet bei 
mir bspw. 2min. Die Türkei, Neuseeland und Zentralasien ist in der 
gleichen Größenordnung.


Hast du mal mit Lambertus gesprochen, wie es mit Feedback, Last und 
Hardware bei ihm ausschaut und geschaut, wie teuer die nötige Hardware 
wäre? Es lohnt ja nicht hier tolle Ideen auszugraben um dann 
festzustellen, dass das über Spenden nicht finanzierbar ist.


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


 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, 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 Last ist. Dann spart man sich
 für so Standardzeug die Rechenarbeit.

Wie gesagt, die Rechenarbeit ist dieselbe, es ginge nur ums wann. Klar
kann man z.B. Deutschland vorrechnen, dann muss halt nicht der eine,
der das zum ersten mal anfordert, so lange warten. Ab da ist es kein
Unterschied mehr.


 Kleine Länder kann man wirklich OnDemand rechnen. Dänemark rechnet bei mir
 bspw. 2min. Die Türkei, Neuseeland und Zentralasien ist in der gleichen
 Größenordnung.

Wenn ein Kartenstil für eine Region gar nicht geeignet ist (z.B. keine
Unterstützung für nicht-lateinische Zeichen), kann man da ja auch das
Angebot einschränken.

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 mal
nachgrübeln...


 Hast du mal mit Lambertus gesprochen, wie es mit Feedback, Last und Hardware
 bei ihm ausschaut und geschaut, wie teuer die nötige Hardware wäre?

Leider nein, ich hatte gestern Abend keine Zeit mehr dafür. Ich hoffe
ich komme heute noch dazu, einige Anbieter anzuschreiben.
Mag jemand von euch vielliecht noch ein bisschen die Wikiseite füllen?
Genug Alternativen mit pros und cons haben wir ja hier inzwischen
durchgekaut.

 Es lohnt
 ja nicht hier tolle Ideen auszugraben um dann festzustellen, dass das über
 Spenden nicht finanzierbar ist.


Ich fürchte, so wird es kommen. Aber ich denke, das Konzept skaliert
recht gut und mit schwächerer Hardware können wir immer über längere
Wartezeit gegensteuern. Das Spendenaufkommen kann ich eigentlich gar
nicht abschätzen, deswegen wäre es wichtig, überhaupt erst einmal
etwas Prototypenhaftes aufzusetzen. Von vorrauseilendem Pessimusmus
halte ich nämlich auch nix.

Ich wünschte ich hätte die Zeit und Expertise, sowas einfach erst mal
auf dem eigenen Server hochzuziehen (z.B. mit den deutschen
Bundesländern).


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

2012-07-05 Diskussionsfäden Andreas Titz


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 den 
Navi-Herstellern gibt es diese Vielfalt meines Wissens auch nicht.


Wenn die Navi-Hersteller alles über einen Kamm scheren, müssen wir ja nun 
nicht auch tun, sondern können uns grade durch - odentlich dokumentierte - 
Vielfalt abheben.


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 Ansprüche an das 
Routing, dass man das kaum mit einer einzelnen Garminkarte mit der begrenzten 
Zahl an routingfähigen Wegtypen abdecken kann:


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).


Der Mountainbiker freut sich dagegen, wenn er auch mal einen tracktype=grade4 
oder grade5 auf seiner Route vorfindet und hält die Rennradrouten für langweilig.


Otto Normalradfahrer ärgert sich dann sowohl über den grade4-Weg, über den 
ihn das Navi geschickt hat als auch über den Umweg, der dem Rennradfahrer 
vorgeschlagen wurde, um den gepflasterten Schlängel-Radweg zu umfahren.


Und Reitwege will ich erst gar nicht auf meiner Fahrradkarte sehen, die sind 
eh unpassierbar.



Für spezielle LKW-Karten sehe ich auch Vorteile, erst recht wenn diese auf 
Anforderung erzeugt werden (dafür fehlt momentan aber noch die 
Infrastruktur). In der Anforderung könnte dann gleich nach Höhe, zulässiger 
Gesamtmasse, Achslast, Länge und Breite gefragt werden und beim Bau der 
speziellen Karte wird der Weg dann auf access=no gesetzt, wenn eine der 
Beschränkungen überschritten ist.


Gruß Andreas


___
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

2012-07-05 Diskussionsfäden Peter Wendorff


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 Last ist. Dann 
spart man sich für so Standardzeug die Rechenarbeit.


Kleine Länder kann man wirklich OnDemand rechnen. Dänemark rechnet bei 
mir bspw. 2min. Die Türkei, Neuseeland und Zentralasien ist in der 
gleichen Größenordnung.


Hast du mal mit Lambertus gesprochen, wie es mit Feedback, Last und 
Hardware bei ihm ausschaut und geschaut, wie teuer die nötige Hardware 
wäre? Es lohnt ja nicht hier tolle Ideen auszugraben um dann 
festzustellen, dass das über Spenden nicht finanzierbar ist.
Wenn ich das richtig verstanden habe, ist das Problem beim Garminformat 
ja die blöde Größenbegrenzung, die durch die Architektur des Formats 
vorgegeben ist.


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 geographische Region abdecken, aber nur eine bestimmte 
Anzahl an Objekten enthalten

3) Anzahl der Kacheln in einer Karte.

Wegen (3) ist die Begrenzung aus (2) ein Problem: um so viel wie möglich 
in der gleichen Karte unterbringen zu können, muss man also die Grenze 
aus (2) nach Möglichkeit voll ausnutzen.
Da das aber abhängig vom enthaltenen Inhalt unterschiedlich ist - eine 
weniger detailreiche Karte kriegt eine größere Fläche in die gleiche 
Kachel - lässt sich diese Kachelaufteilung eben nicht schön einheitlich 
festlegen.


Außerdem meine ich mal was gelesen zu haben, dass das Routing über 
Kachelgrenzen hinweg schwierig ist? bin mir da aber nicht sicher, ob das 
noch aktuell ist oder so - wäre jedenfalls ein weiterer Grund, bewusst 
unterschiedliches Kachellayout zu wählen: Fürs Fahrradrouting wäre dann 
eine Autobahn eine halbwegs sinnvolle Grenze: die kann man sowieso nur 
selten überqueren ;)


Korrigiert mich, wenn ich das falsch verstanden haben sollte!

Gruß
Peter

___
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 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 mal
nachgrübeln...
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 Zusammenfassen zur 
gmapsupp.img. Dieses Zusammenfassen würde immer Anfallen, wenn der 
Nutzer eine andere Kachelzusammenstellung wählt. Daher wäre es fürs 
cachen natürlich sinnvoll, wenn alle, die eine Deutschlandkarte wollen, 
die gleichen Kacheln herunterladen.


Meine Idee wäre jetzt eine Kombination aus fertigen, fixen Extrakten der 
frequentierten Länder und zusätzlich eine variable Auswahl der Kacheln.



Hast du mal mit Lambertus gesprochen, wie es mit Feedback, Last und Hardware
bei ihm ausschaut und geschaut, wie teuer die nötige Hardware wäre?

Leider nein, ich hatte gestern Abend keine Zeit mehr dafür. Ich hoffe
ich komme heute noch dazu, einige Anbieter anzuschreiben.
Mag jemand von euch vielliecht noch ein bisschen die Wikiseite füllen?
Genug Alternativen mit pros und cons haben wir ja hier inzwischen
durchgekaut.
Lambertus hat sich auf meine Mail auf mkgmap-dev gemeldet. Sein deutsch 
(und Google Translate) reicht nicht ganz aus, um alles zu verstehen. Ich 
werde es ihm (und evtl. auch einigen anderen, die dort mitlesen) mal 
etwas zusammenfassen.



Es lohnt
ja nicht hier tolle Ideen auszugraben um dann festzustellen, dass das über
Spenden nicht finanzierbar ist.

Ich fürchte, so wird es kommen. Aber ich denke, das Konzept skaliert
recht gut und mit schwächerer Hardware können wir immer über längere
Wartezeit gegensteuern. Das Spendenaufkommen kann ich eigentlich gar
nicht abschätzen, deswegen wäre es wichtig, überhaupt erst einmal
etwas Prototypenhaftes aufzusetzen. Von vorrauseilendem Pessimusmus
halte ich nämlich auch nix.
So war das auch nicht gemeint. Ich hab von der Serverwelt kaum Ahnung. 
Ich kann grob Abschätzen, was ein Desktop kosten würde, mit dem man fix 
Karten rechnen kann. Ich hab aber keine Ahnung, was man beim Server an 
Zusatz (Anbindung, etc.) braucht, worauf man beim Preis achten muss etc. 
Von daher kann ich auch nicht abschätzen, ob man nun 50€ im Monat 
einnehmen muss oder 500€.


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 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 geographische Region abdecken, aber nur eine bestimmte 
Anzahl an Objekten enthalten
3) Anzahl der Kacheln in einer Karte. 


Begrenzt ist die Kachelgröße über die Anzahl der Objekte darin. Das ist 
die einzige Beschränkung aus dem Format, wenn man mal die Genauigkeit 
und die Anzahl der verschiedenen Objekte außen vor lässt.


Die anderen Beschränkungen verursachen die Handgeräte. Diese schlucken 
nur FAT32, ergo maximal 4gb je Datei. Weiterhin ist die maximale Anzahl 
aller Kacheln auf einem Gerät auf ~4000 beschränkt.


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 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 Ansprüche an das Routing,
dass man das kaum mit einer einzelnen Garminkarte mit der begrenzten Zahl an
routingfähigen Wegtypen abdecken kann:


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 ein Ziel anfahren will, das nicht auf dem geplanten Track 
liegt. Das kann der Campingplatz oder das Hotel sein, welche man spontan 
aufsucht, oder das Tagesziel, das man bei Abbruch der Tour auf schnellem und 
sicherem Weg erreichen will. In beiden Fällen halte ich es für akzeptabel, dass 
auch der Bergwanderer und MTBler über Grade3-Tracks bis Tertiaries geführt werden.


Spontanes Routing auf Pfaden anhand der SAC- oder MTB-Klassifizierung halte ich 
von seltenen Ausnahmen abgesehen für unrealistisch. Und innerorts, wo ich 
Routing für Fußgänger und Radfahrer durchaus für sinnvoll halte, sind solche 
Differenzierungen ohne hin nicht relevant.


Ich bin mir ziemlich sicher, dass sowohl die OpenVeloMap, Hennings Karte, die 
von Ralf Kleineisel und eine Reihe anderer Karten, jede für sich den Bedarf von 
mehr als 90% der sich zu Fuß oder per Rad fortbewegenden Navi-Nutzer ist, und 
diese Gruppe wiederum den weitaus größten Teil der potentiellen Nutzer von 
OSM-Garmin-Karten darstellt. Wir sprechen hier ja nicht über Smartphone-Apps, 
TomToms oder Online-Routinganwendungen.


Trotzdem halte ich solche Spezialkarten natürlich für sinnvoll. Mein Vorschlag 
war nur, diese Karten nicht alle auf einem zentralen Server zu erzeugen.



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).


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.



Otto Normalradfahrer ärgert sich dann sowohl über den grade4-Weg, über den ihn
das Navi geschickt hat als auch über den Umweg, der dem Rennradfahrer
vorgeschlagen wurde, um den gepflasterten Schlängel-Radweg zu umfahren.


Dito. Setzt ein flächendeckendes, einheitliches und zuverlässiges Tagging 
voraus. es gibt Grade2-tracks, die kann man problemlos mit dem Rennrad fahern 
und Grade1-Tracks, bei denen dir die Lücke zwischen den Betonplatten die Felge 
verbiegt.



Für spezielle LKW-Karten sehe ich auch Vorteile, erst recht wenn diese auf
Anforderung erzeugt werden (dafür fehlt momentan aber noch die Infrastruktur).
In der Anforderung könnte dann gleich nach Höhe, zulässiger Gesamtmasse,
Achslast, Länge und Breite gefragt werden und beim Bau der speziellen Karte wird
der Weg dann auf access=no gesetzt, wenn eine der Beschränkungen überschritten 
ist.


Darüber sollten wir diskutieren, wenn diese Daten flächendeckend erfasst sind. 
Bis dahin würde ich als Lkw-Fahrer keinem auf OSM basierenden Routing vertrauen, 
das diese Kriterien berücksichtigt.


Gruß
Rainer


___
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 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 ungeplanterweise ein Ziel anfahren will, das nicht auf dem geplanten
 Track liegt. D

Da sprich mal nur für 'deine' Masse der User. Also unter den
Geocachern (sollten auch eine gute 'Masse' von Freizeit-GPS-Nutzern
sein) ist es der Normalfall, ein festes Ziel zu haben, dass sich aber
erst unterwegs ergibt. Dann wird auch im Wald die Routingfunktion
benutzt. Man will ja nicht in Luftlinie durchs Unterholz marschieren.

Tourenplanung am PC ist mir bisher bei Anfragen am Stand oder auch im
Bekanntenkreis noch nicht unter gekommen. Wenn man die
Garmin-PC/Mac-Software auch nur erwähnt, verdrehen die meisten schon
die Augen. Das ist mir eher schon als Argument für OSM untergekommen,
weil das draufschieben der gmapsupp.img auf die SD-Karte einfacher ist
als das registrieren und übertragen der Kaufkarten.

GPSies kommt schon eher mal vor, für Wanderungen oder Fahrradtouren.
Aber auch da möchte zumindest ich, wenn ich den Weg wegen Sperrungen
o.ä. verlassen muss, wieder vernünftig zurück geroutet werden.

Das ist vielleicht etwas, dass mit der Historie zu tun hat. Wer früher
mit Papierkarten hantierte, nutzt die Funktionen seltener. Wer aus der
Technikecke kommt, hat nicht mal Verständnis für Topokarten. Ich will
schliesslich wissen, wie weit und wie lange es bis zum Ziel ist.Und da
meine ich nciht Luftlinie.

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 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 das Zusammenfassen zur gmapsupp.img. Dieses Zusammenfassen
 würde immer Anfallen, wenn der Nutzer eine andere Kachelzusammenstellung
 wählt. Daher wäre es fürs cachen natürlich sinnvoll, wenn alle, die eine
 Deutschlandkarte wollen, die gleichen Kacheln herunterladen.

Also ich hab das mal selbst gemacht, als es noch wenig fertige Karten
gab. Das ist aber schon länger her. Da hat sich sicher viel
weiterentwickelt.

Wenn ich fertige Kacheln relativ schnell zusammensetzen kann, dann
bietet sich natürlich das Cachen auf Kachel- und nicht auf Länderebene
an.
Damit bräuchte man nur eine fixe Lookup-table Land-benötigte Kacheln.
Lambertus cached dem Gefühl nach eher länderweise, rechnet Kacheln
aber immer neu (oder cached sehr kurz). (Sofortdownload, wenn Land
vorhanden, sonst immer ca 1-2h).

Für uns wäre es sicher günstiger, auch die Kacheln länger zu cachen.
Ob man dem Nutzer dann auch noch die 5min des Zusammensetzens spart,
in dem man auch Länder cached, ist dann eher Bonus. Den Plattenplatz
müsste man aber vorher mal durchrechnen.


 Meine Idee wäre jetzt eine Kombination aus fertigen, fixen Extrakten der
 frequentierten Länder und zusätzlich eine variable Auswahl der Kacheln.

Ja, so macht das auch Lambertus jetzt. Ich würde aber auch die fixen
Extrakte aus den selben Kacheln bauen, also nicht mit Länder-shapes
beschneiden.
Ob die dann nach fixem plan vorgerechnet, oder beim ersten Anfordern
erstellt udn dann gecached werden, ist geschmackssache.

Gruss
Chaos

PS: Nach so viel Diskussion will ich sowas jetzt aber auch bauen.

___
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 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 
Route wird dann in einen Track umgewandelt und auf das Gerät geschickt. 
Unterwegs findet dann primär Umleitungssuche oder Unterkunftssuche statt.


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

2012-07-05 Diskussionsfäden Andreas Titz


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).


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.


Da sind wir unterschiedlicher Meinung. Draußen sehe ich ja, dass der Weg 
entgegen der Erfassung doch befahrbar / nicht befahrbar ist und kann mich 
spontan umentscheiden - das Navi berechnet dann eine neue Route. Bei der 
Vorausplanung am Rechner bin ich drauf angewiesen, dass die Eintragungen stimmen.


Für spezielle LKW-Karten sehe ich auch Vorteile, erst recht wenn diese 
auf
Anforderung erzeugt werden (dafür fehlt momentan aber noch die 
Infrastruktur).

In der Anforderung könnte dann gleich nach Höhe, zulässiger Gesamtmasse,
Achslast, Länge und Breite gefragt werden und beim Bau der speziellen 
Karte wird
der Weg dann auf access=no gesetzt, wenn eine der Beschränkungen 
überschritten ist.


Darüber sollten wir diskutieren, wenn diese Daten flächendeckend erfasst 
sind. Bis dahin würde ich als Lkw-Fahrer keinem auf OSM basierenden 
Routing vertrauen, das diese Kriterien berücksichtigt.


d.h. du würdest auch erfasste Beschränkungen erstmal beim Routing unbeachtet 
lassen und mit dem 10-Tonner erstmal bis an die mit maxweight=5t getaggte 
Brücke ranfahren, wenden, und dann wieder 10km zurück, wo du zur nächsten 
Brücke abbiegen kannst?
Dass irgendwelche Beschränkungen nicht erfasst sind, ist ja immer möglich, 
z.B. weil die Brücke gestern überprüft wurde und sofortiger Handlungsbedarf 
(= sofortige Sperrung für schwere Fahrzeuge, noch heute) erkannt wurde.


Gruß Andreas


___
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


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

Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event


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.


Da sind wir unterschiedlicher Meinung. Draußen sehe ich ja, dass der Weg
entgegen der Erfassung doch befahrbar / nicht befahrbar ist und kann mich
spontan umentscheiden - das Navi berechnet dann eine neue Route.


Das kannst du dir erlauben, wenn du jung und sportlich bist. Wenn ich unterwegs 
bin, möchte ich nicht 500 Höhenmeter in ein Tal runterfahren, um dann 
festzustellen, das der einzige mit meinem Sportgerät befahrbare Weg, der aus 
diesem Tal herausführt, derjenige ist, den ich gerade herunter gefahren bin. Wie 
ich das Navi dazu bringe, mich in diesem Fall doch noch auf den richtigen Weg zu 
führen, ist mir unklar.



Darüber sollten wir diskutieren, wenn diese Daten flächendeckend erfasst sind.
Bis dahin würde ich als Lkw-Fahrer keinem auf OSM basierenden Routing
vertrauen, das diese Kriterien berücksichtigt.


d.h. du würdest auch erfasste Beschränkungen erstmal beim Routing unbeachtet
lassen und mit dem 10-Tonner erstmal bis an die mit maxweight=5t getaggte Brücke
ranfahren, wenden, und dann wieder 10km zurück, wo du zur nächsten Brücke
abbiegen kannst?


Da gilt dasselbe wie oben: was mache ich mit meinem 10-Tonner, wenn ich vor 
einer *nicht* mit maxweight=5t aber auf 5t beschränkten getaggten Brücke stehe?


Gruß
Rainer


___
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

2012-07-04 Diskussionsfäden Carsten Schwede


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] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event

2012-07-04 Diskussionsfäden Carsten Schwede


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

2012-07-04 Diskussionsfäden Roland Olbricht

  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] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event

2012-07-04 Diskussionsfäden 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.

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

2012-07-04 Diskussionsfäden Carsten Schwede


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

2012-07-04 Diskussionsfäden Florian Lohoff

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

2012-07-04 Diskussionsfäden 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 ...

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

2012-07-04 Diskussionsfäden 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 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

2012-07-04 Diskussionsfäden Peter Wendorff


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

2012-07-04 Diskussionsfäden WanMil


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

2012-07-04 Diskussionsfäden Jochen Topf

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

2012-07-04 Diskussionsfäden NopMap

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

2012-07-04 Diskussionsfäden Lars Lingner

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

Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event

2012-07-04 Diskussionsfäden 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.

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] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event

2012-07-04 Diskussionsfäden Roland Olbricht

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

Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event

2012-07-03 Diskussionsfäden 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 wir können das
 nicht aktuell halten. Aber dennoch: Wollen wir etwas für reine
 Kartenkonsumenten tun? (In meinen Augen sind das alles immer auch
 potentielle, zukünftige Mapper.)
 WAS können wir tun, um den Zugriff auf Garminkarten zu vereinfachen?

Die FOSSGIS Server stehen zur Produktion aktueller Karten prinzipiell zur
Verfügung. Derzeitiger Stand ist, dass die Computerteddy-Karte dort
hergestellt wird. Die Erzeugung der AIO ist AFAIK leider eingeschlafen.

Das Problem, das ich hier hauptsächlich sehe ist dass es da leider wenige
gibt die sich kümmern möchten.

Gruss

Sven

-- 
/*
 * Wirzenius wrote this portably, Torvalds fucked it up :-)
 */(taken from /usr/src/linux/lib/vsprintf.c)
/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



 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 hauptsächlich sehe ist dass es da leider wenige
 gibt die sich kümmern möchten.


Mir ging es gar nicht um neue Karten. Das bestehende Angebot ist gar nicht
schlecht.
Mir ging es darum, zu den bestehenden Angeboten besseren Zugang zu schaffen.
Momentan fällt das alles noch unter 'Expertenwissen' und ist nicht für den
OSM-Nutzer 'von der Straße' praktikabel.
Zu viele halten die osm.org Karte für Die OpenStreetMap  und die
erstbeste gmapsupp.img, die sie mal per Google gefunden haben für
Die OSM-Garminkarte.

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 wie Wiki-Userseiten.

Die Frage ist: Wenn das der Kartenersteller aber nun mal so macht, haben
wir dann das Recht und/oder die Möglichkeit, das verbessern zu wollen?

Aber ja, jetzt wo du den FOSSGIS Server erwähnst: ein on-Demand Dienst, der
variabel genug ist mit verschiedenen Profilen unterschiedliche Karten zu
erstellen, würde das Problem natürlich lösen. Aber DAS wäre wirklich ein
gehöriger Entwicklungsaufwand.

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 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 wir können das
nicht aktuell halten. Aber dennoch: Wollen wir etwas für reine
Kartenkonsumenten tun? (In meinen Augen sind das alles immer auch
potentielle, zukünftige Mapper.)
WAS können wir tun, um den Zugriff auf Garminkarten zu vereinfachen?

Die FOSSGIS Server stehen zur Produktion aktueller Karten prinzipiell zur
Verfügung. Derzeitiger Stand ist, dass die Computerteddy-Karte dort
hergestellt wird. Die Erzeugung der AIO ist AFAIK leider eingeschlafen.

Das Problem, das ich hier hauptsächlich sehe ist dass es da leider wenige
gibt die sich kümmern möchten.
Das Problem sehe ich eher weniger darin, dass es zu wenig Karten gibt,
die man einfach so konsumieren kann, sondern eher da, dass der
unbedarfte Nutzer sie nicht findet. Das einzige, was wir zu bieten
haben ist eine komplett unübersichtliche Wiki-Liste [1]. Und selbst die
wird bspw. noch nicht mal von openstreetmap.de verlinkt. Diese linkt
beim Thema Karten für Garmin auf [2].

Die Verbreitung der Karten passiert derzeit primär über
Mund-zu-Mund-Propaganda in diversen Foren etc.

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). Wo man als Nutzer etwas Filtern kann (Region,
Fortbewegung) und dann wesentliche Infos zu den Karten bekommt. Evtl.
noch ein Bild. Bisher hat sich keiner gefunden, der sowas
programmieren/gestalten möchte... Das übliche Problem halt.

Henning

[1]
http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Downloadhttp://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download

[2] http://wiki.openstreetmap.org/wiki/DE:Garmin
___
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 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 wie Wiki-Userseiten.

Die Frage ist: Wenn das der Kartenersteller aber nun mal so macht, haben
wir dann das Recht und/oder die Möglichkeit, das verbessern zu wollen?
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.


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

2012-07-03 Diskussionsfäden Frederik Ramm


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 auf mein Garmin? - die verweise ich je nach Typ an eine 
der etablierten Karten (Kleineisel, Cyclemap, OpenMTB, oder auch 
raumbezug.eu). Wenn die Leute dann aber unbedingt wissen wollen, wie sie 
denn jetzt eine Karte nur fuer Baden-Wuerttemberg machen oder so, sag 
ich immer mkgmap und bei Problemen im Forum oder auf der Liste fragen ;)


Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33



___
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 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 mir fallen da auch nur zwei Möglichkeiten ein:
- Entweder noch mehr Erklärungen, HowTos und Tutorials, damit die Leute mit
den ganzen Unterseiten klar kommen - zwecklos für den 08/15 Konsumenten
- oder ein neues Angebot unter eigener Kontrolle, welches aber das selbe
Leistungsdpektrum abdeckt wie die bestehenden Einzellösungen - unglaublich
aufwendig

Ich wollte mich halt nicht mit diesen zwei Sackgassen zufrieden geben. (Ist
echt schwer, wenn man gerade hundert Leuten sagen musste, dass es keine
'einfache' Möglickeit gibt, sich ihre Karte zu laden.) Es gibt s viele
kreative Lösungen im OSM Umfeld. Da muss doch jemand noch eine Idee haben
...


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

2012-07-03 Diskussionsfäden 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 prominenten link zu Garminkarten anlegen.

Das Problem ist doch, dass wir derzeit außer Carsten niemanden haben, der
sich um die automatische Produktion von Garminkarten kümmert. Carstens Karte
wird aber AFAIK immer noch aktuell auf dem FOSGIS Server erzeugt.

Gruss

Sven

-- 
We don't know the OS that God uses, but the Vatican uses Linux
   (Sister Judith Zoebelein, Vatican Webmaster)

/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

2012-07-03 Diskussionsfäden Sven Geggus

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 integriert und eincheckt schalte ich das gerne
sofort aktiv :)

Sven

-- 
Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der
Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der
Demokraten (Theodor W. Adorno)
/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


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 den Anbieter vorher fragen, ob das ok für ihn 
ist. Manch einer hat seine Karte evtl. absichtlich nicht prominent verlinkt.

- man darf den Leuten den Traffic nicht wegnehmen, wegen 
Werbe-/Spendenfinanzierung
- eine Übersichtsseite mit Direktlinks ist beinahe unmöglich, wegen der
extrem heterogenen und auch noch instabilen Organisationsstruktur der
Kartennabieter
Ich sehe keinen wirklichen Nachteil darin, wenn zwischen dem Portal und 
dem Download noch eine weitere Seite ist, die ansprechend aussieht. Wenn 
man dann auch nur auf einer wiki-link-Seite landet wären Direklinks 
natürlich besser. Vor allem, weil die Übersichtsseite nicht alle Details 
enthalten kann.
Bei der Fütterung eines solchen Portals sehe ich auch nur geringe 
Probleme. Bei der wiki-Übersicht hat es ja auch geklappt. Ich denke, 
dass die Kartenanbieter durchaus bereit sind, die Infos zu ihren Karten 
dort aktuell halten.


Viel mehr neue Ideen fallen mir auch nicht ein. Entweder man erklärt das 
bestehende System, man schafft ein neues, besseres System zur Auswahl 
oder man stellt eine neue Kartenserie (Rad, Auto, etc.) auf die Beine. 
Aber auch hier besteht immer die Gefahr, dass diese dann irgendwann 
einschläft und natürlich nicht zur Geltung kommt, dass OSM mehr zu 
bieten hat, als nur DIESE Karte.


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 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 prominenten link zu Garminkarten anlegen.

Das Problem ist doch, dass wir derzeit außer Carsten niemanden haben, der
sich um die automatische Produktion von Garminkarten kümmert. Carstens Karte
wird aber AFAIK immer noch aktuell auf dem FOSGIS Server erzeugt.
Ich denke das es da recht viele Karten gibt, die mehr oder weniger 
automatisch erzeugt werden. Nur halt nicht auf den FOSGIS Servern. Ich 
denke auch, dass es nicht unbedingt darauf ankommt, wo und wie die Karte 
erzeugt wird.
Ich denke es ist auch recht unrealistisch, dass man alle Karten auf 
diesem Server rechnet.


Mal eine kleine (unvollständige) Liste:
OpenFietsMap
RadReiseKarte
OpenMTBMap und VeloMap
Freizeitkarte
Kleineisel
...

Das Problem ist nicht, dass es keine aktuelle Vielfalt gibt, sondern 
dass die Nutzer diese Vielfalt anscheinend nicht finden.



___
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

2012-07-03 Diskussionsfäden Jochen Topf

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.

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

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 gibt es da sogar
schon eine mit/ohne typfile Auswahl.
Die hat ohne Screenshot allerdings noch wenig Sinn. Fehlt nur noch
eine Profildatei, die auch die Kartenfeatures anpasst.
Dazu müssten aber zB die Anbieter der Radreisekarte oder der AiO
bereit sein, ihre erarbeiteten Einstellungen und Styles zur Verfügung
zu stellen.

Da das jetzt schon auf einem Niederländischen Hochschulserver läuft,
habe ich keine Ahnung, wieviel Leistung schon dahinter steckt.
Immerhin hat die Seite schon lange ein gutes Caching der oft geladenen Länder.

Vielleicht schreib ich zu dem Thema den Herrn Lambertus mal direkt an.


Am 3. Juli 2012 17:14 schrieb aighes o...@aighes.de

 Das Problem ist nicht, dass es keine aktuelle Vielfalt gibt, sondern dass die 
 Nutzer diese Vielfalt anscheinend nicht finden.

Wie ich schon eingangs schrieb: Genau!


Am 3. Juli 2012 16:59 schrieb aighes o...@aighes.de

 Ich sehe keinen wirklichen Nachteil darin, wenn zwischen dem Portal und dem 
 Download noch eine weitere Seite ist, die
 ansprechend aussieht. Wenn man dann auch nur auf einer wiki-link-Seite landet 
 wären Direklinks natürlich besser. Vor allem,
 weil die Übersichtsseite nicht alle Details enthalten kann.

Diese Seite(n) 'dazwischen' ist(/sind) momentan die Seiten der
Anbieter. Und die sehen leider nicht immer ansprechend aus. Und bitte
jetzt nicht als Abwertung gegen die Ersteller sehen. Ich hab hohen
Respekt vor ihren Leistungen beim Erstellen von Garmin-Karten, aber
Webdesign muss ja nun nicht jedermanns Hobby sein. NOCH eine Seite
dazwischen bringt dann dem Konsumenten nichts.


 Bei der Fütterung eines solchen Portals sehe ich auch nur geringe Probleme. 
 Bei der wiki-Übersicht hat es ja auch geklappt. Ich
 denke, dass die Kartenanbieter durchaus bereit sind, die Infos zu ihren 
 Karten dort aktuell halten.

Ich hab das zwar bei der Erstellung der Liste selbst nicht geglaubt,
aber ja, dass klappt recht gut.

 Viel mehr neue Ideen fallen mir auch nicht ein. Entweder man erklärt das 
 bestehende System, man schafft ein neues, besseres
 System zur Auswahl oder man stellt eine neue Kartenserie (Rad, Auto, etc.) 
 auf die Beine. Aber auch hier besteht immer die Gefahr,
 dass diese dann irgendwann einschläft und natürlich nicht zur Geltung kommt, 
 dass OSM mehr zu bieten hat, als nur DIESE Karte.

Das Erklären des bestehenden Systems bringt uns nicht (viel) weiter
als jetzt. Usability kann man nicht herbeierklären. Das wäre immer nur
eine Krücke.

Ein neues System wäre dann ein Erfolg, wenn es so flexibel ist, dass
neue Entwicklungen gleich an und mit eben diesem System erfolgen. Nach
dem Muster: shapefile, filterregeln, optionsfile, stylefile, typfile
hochladen, Aktualisierungsintervall einstellen und neue Karte vom
Server beziehen. Damit findet die Entwicklung neuer Karten direkt
zentral statt, und nicht mehr im Privatblog des 'Künstlers'. Selbst
wenn dieser die Lust verliert, bleibt die Karte (bzw. deren
Erstellungsregeln) erhalten und kann immer wieder produziert werden.
Problematisch wir es erst, wenn sich die toolchain grundlegend
unterscheidet. Aber bis jetzt ist die ja relativ gleich, oder?

Das bedeutet natürlich, dass man dann zentral eine Menge Rechenpower
braucht, und wer will die wieder bezahlen? Und ich bin natürlich weit
davon entfernt, sowas selbst implementieren zu können.

Wie war das letztens bei twitter: Moderne Grammatik: der Delegativ
Futur: jemand müsste irgendwann mal.

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


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 ist auch meine Lieblingskarte. Neuerdings gibt es da sogar
schon eine mit/ohne typfile Auswahl.
Die hat ohne Screenshot allerdings noch wenig Sinn. Fehlt nur noch
eine Profildatei, die auch die Kartenfeatures anpasst.
Dazu müssten aber zB die Anbieter der Radreisekarte oder der AiO
bereit sein, ihre erarbeiteten Einstellungen und Styles zur Verfügung
zu stellen.


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.


Ein neues System wäre dann ein Erfolg, wenn es so flexibel ist, dass 
neue Entwicklungen gleich an und mit eben diesem System erfolgen. Nach 
dem Muster: shapefile, filterregeln, optionsfile, stylefile, typfile 
hochladen, Aktualisierungsintervall einstellen und neue Karte vom 
Server beziehen. Damit findet die Entwicklung neuer Karten direkt 
zentral statt, und nicht mehr im Privatblog des 'Künstlers'. Selbst 
wenn dieser die Lust verliert, bleibt die Karte (bzw. deren 
Erstellungsregeln) erhalten und kann immer wieder produziert werden. 
Problematisch wir es erst, wenn sich die toolchain grundlegend 
unterscheidet. Aber bis jetzt ist die ja relativ gleich, oder?


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 ;)


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

2012-07-03 Diskussionsfäden Jochen Topf

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 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 eher können
wir einen weiteren Server dazustellen. Wenn Leute sehen, wofür sie Geld
geben, dann funktioniert das sogar manchmal...

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



 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

Re: [Talk-de] Feedback vom OpenStreetMap-Stand auf dem GeoGames Leipzig Event


 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 eher können
 wir einen weiteren Server dazustellen. Wenn Leute sehen, wofür sie Geld
 geben, dann funktioniert das sogar manchmal...


Warum denn kontinuierlich Updates rechnen? Das bedeutet doch wieder,
dass man sich auf ein fixes Stylepaket festlegen muss.
Warum nicht on Demand genau das Stylepaket und die Kacheln rechen, die
der Nutzer haben will.

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.
Dazu ein kleiner Hinweis: Wenn du den Schmarn mit dem
Rumkonfigurieren lässt, bekommst du die Karte gleich aus dem Cache,
ansonsten dauert's.

Der Rest klappt dann wie von dir beschrieben. Der Nutzer muss 4h auf
seine Karte warten. Will er, dass es nächstes mal schneller geht, muss
er auf den Spenden-Button drücken.

Der Server rechnet natürlich immer noch kontinuierlich, doch halt
nicht mehr auf ständige Updates, sondern auf der Anfragenqueue.

Hach, erfindet sich das leicht, wenn man's nicht implementieren muss

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

2012-07-03 Diskussionsfäden Frederik Ramm


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 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 User, der 
im Moment im Regen steht, ist mit so einer Auswahl, wie Du sie oben 
schilderst, doch total ueberfordert.


Ich glaube, was hier fehlt, ist weniger eine Vielzahl von tollen Tools, 
sondern ein Redakteur, der sagt: Ok, wenn Dein Einsatzzweck A ist und 
Dein Geraet B, dann lade genau dieses File runter.


Gerade die Vielfalt ist es doch, die die Nutzer derzeit erschlaegt.

Bye
Frederik

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33



___
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 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: Um so mehr Geld zusammen kommt, um so eher können
wir einen weiteren Server dazustellen. Wenn Leute sehen, wofür sie Geld
geben, dann funktioniert das sogar manchmal...


Warum denn kontinuierlich Updates rechnen? Das bedeutet doch wieder,
dass man sich auf ein fixes Stylepaket festlegen muss.
Warum nicht on Demand genau das Stylepaket und die Kacheln rechen, die
der Nutzer haben will.

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.
Dazu ein kleiner Hinweis: Wenn du den Schmarn mit dem
Rumkonfigurieren lässt, bekommst du die Karte gleich aus dem Cache,
ansonsten dauert's.
Um evtl. mal etwas zur Rechenzeit zu sagen: Ich rechne auf 4 Kernen 
eines AMD X6 1090T mit einer SSD und 8GB RAM für Deutschland ~40min. 
gmapsupp.img packen und einen Installer machen nochmal 30min.


Für jede Zusammenstellung an Kacheln kann man je nach Anzahl ~ 5min 
Rechnen und benötigt die Größe aller Kacheln als freien RAM für die 
Adresssuche. Für jede neue Variante müssen alle Kacheln neu gerechnet 
werden.


Es könnte klappen, wenn man Rechenpower hat und die User Geduld haben 
und warten. Je mehr Auswahl der Nutzer hat, desto verwirrter ist er aber 
auch.


Einfacher und auch kostengünstiger dürfte eine Auswahlhilfe sein.

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