Am 09.05.2008 um 19:28 schrieb Raphael Studer:
Gibt's davon schon was was man testen kann? (hab auf anhieb kein
build
gefunden, nur ein source-repo)
Ich hab zwar kein ant build machen können, aber ich denke es
klappte trotzdem
mit dem compilieren. Damit haben die Packages auf
Am Donnerstag 08 Mai 2008 schrieb Gabriel Ebner:
Die Idee war damals, nicht benötigte
Daten nach dem Laden aus dem Speicher zu entfernen.
naja, aber oft sind eigentlich nicht benoetigte daten recht hilfreich als
orientierungsmoeglichkeit. rausschmeissen hilft da nicht wirklich weiter.
aber
Ich will jetzt ja nicht allzu sehr rumflamen, ich kann ja selbst nicht
wirklich qualifiziert programmieren, aber irgendwie ist es halt einfach so,
dass man in Java nicht seriös programmiert.
Ich dachte in josm-ng wär das ziemlich seriös in Java gelöst worden?
Leider hab ich schon länger nichts
2008/5/9 Hanno Böck [EMAIL PROTECTED]:
Am Freitag 09 Mai 2008 schrieb Raphael Studer:
Ich will jetzt ja nicht allzu sehr rumflamen, ich kann ja selbst nicht
wirklich qualifiziert programmieren, aber irgendwie ist es halt einfach
so, dass man in Java nicht seriös programmiert.
Ich dachte
On Freitag 09 Mai 2008, Hanno Böck wrote:
Am Freitag 09 Mai 2008 schrieb Raphael Studer:
Ich will jetzt ja nicht allzu sehr rumflamen, ich kann ja selbst nicht
wirklich qualifiziert programmieren, aber irgendwie ist es halt einfach
so, dass man in Java nicht seriös programmiert.
Ich
Gibt's davon schon was was man testen kann? (hab auf anhieb kein build
gefunden, nur ein source-repo)
Ich hab zwar kein ant build machen können, aber ich denke es klappte trotzdem
mit dem compilieren. Damit haben die Packages auf gpsdrive.de ab folgender
Version das compilierte josm-ng mit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mir ist neulich ein Problem aufgekommen, was sich meiner Meinung nach in
Zukunft mit wachsendem OSM-Datenvolumen noch verschlimmern wird.
Je mehr Daten in einem Gebiet sind, desto mehr wird natürlich geladen
und das Schlimmste: desto langsamer werden
On Thu, May 08, 2008 at 05:27:37PM +0200, Christoph Wagner wrote:
Mir ist neulich ein Problem aufgekommen, was sich meiner Meinung nach in
Zukunft mit wachsendem OSM-Datenvolumen noch verschlimmern wird.
Je mehr Daten in einem Gebiet sind, desto mehr wird natürlich geladen
und das Schlimmste:
Christoph Wagner schrieb:
Seht ihr das Problem genauso?
Schau dir mal die osmxapi an, die hat einen Filter eingebaut.
Gruß Christian
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Also meine ganz bescheidene Meinung dazu, das liegt nicht an der Datenmenge,
sondern an den Editoren, bzw. den verwendeten Programmiersprachen. Die
Datenmenge, die josm mal eben in die Knie zwingt, ist nichts, was von
heutigen PCs nicht problemlos bewältigbar wäre. (Vergleiche die Polygonzahl,
On Thu, May 08, 2008 at 11:38:17PM +0200, Hanno Böck wrote:
Ich will jetzt ja nicht allzu sehr rumflamen, ich kann ja selbst nicht
wirklich qualifiziert programmieren, aber irgendwie ist es halt einfach so,
dass man in Java nicht seriös programmiert.
Don't feed the troll.
Gabriel.
11 matches
Mail list logo