mir selber passt openlayer defintiv besser als khtml. vorallem funktioniert openlayer auch mit mobilen browsern relativ gut (ist zwar auch noch verbesserungswürdig, aber definitiv besser als khtml).
und wie auch Dennis schon gepostet hat, empfinde ich khtml überhaupt nicht schneller als openlayer.
@wicking: Zur Karte von Polen: Ja, dort wird ein ganz bischen vorab geladen. Aber wirklich viel auch nicht. Es werden auch keine benachbarten Zoomlevels geladen.
Zu Fehler 3: Man sieht den Fehler sogar in der polnischen Karte, wenn man schnell zweimal hintereinander einen Doppelklick macht und die nächsten Zoomstufen noch nicht im Cache sind. Wenn gar nichts geladen ist, habe ich die 2.-Letzte Zoomstufe vergrößert. Dann kommt erst die nächste Zoomstufe auch vergrößert und erst danach die eigentliche Zoomstufe.
Die Zoomstufen könnte man über einen Schalter (wie die vielen bei keepright am linken Rand - checkbox) auf ganzzahlig: ja/nein vom Nutzer einstellen lassen.
Der Aufruf von JOSM oben rechts ist wohl auf den meisten Rechnern nicht als OSM://… ausgelegt, sondern eher als http://localhost:8111/load_and_zoom?…
Da finde ich zum Aufruf der Editoren den OSM-Inspector ganz angenehm mit den Icons zur Auswahl des Editors, der auch nicht immer einen so großen Bereich in JOSM läd, wie es keepright macht (dort finde ich die Größe fest eingestellt auf 0,002 Grad auf beiden Achsen).
Bei openlayer wird das Drehen des Mausrades nicht angenommen, wenn sich die Maus noch über einer nicht geladenen weißen kachel befindet - das behindert bei mir das Zoomen dort etwas. Auf der polnischen Seite mit khtml geht das Zoomen bei mir flüssiger als mit openlayers (Firefox).
Den Bug mit der hellen Linie in der Grafik, den Dennis hier als Bild gezeigt hat, sehe ich mit Opera auch - jedoch nicht mit Firefox. Dort wird die linke Pixelreihe einer Kachel - auch, wenn sie links außerhalb des sichtbaren Bereichs befindet, am rechten Rand der Kachel gezeichnet, wo sie garnicht hingehört - kann man gut bei den Nordseeinseln testen.
Wo erreiche ich eigentlich bei khtml den DatenLayer, den es bei openlayer rechts oben unter dem blauen Pluszeichen in der letzten Zeile gibt?
Viele Grüße,
Franz
Das Flackern laesst sich moeglicherweise recht leicht loesen in dem man beim Laden der Karte die OpenLayers Eigenschaft “transitionEffect: ‘resize’” in der Karte setzt. Es ist zwar kein annimiertes Zoomen, aber die weisen Flaechen sollte es wenn ich das richtig verstanden haben verhindern.
Also hier geht das, indem man auf die Knöpfe des Fernsehers drückt. Natürlich kann man die auch unter einem „Plus“ verstecken und den Fernseher weglassen – denke ich.
Äh, achso, Datenlayer. Ne, den habe ich noch nicht gefunden. Da musste wohl den Entwickler fragen oder in der Doku oder im Quelltext suchen.
Und wie siehts aus mit dem Zeichnen von Nodes, Ways und Relationen aus. Das wird ja auch auf der Hauptkarte benötigt.
Schaut schön aus 
Die Messfunktion wäre noch schön wenn man über mehrere Punkte eine Gesamtstrecke messen könnte.
Gruß Michael
Hallo
Ich habe khtmlib programmiert und möchte ein paar Fragen beantworten die hier aufgetaucht sind:
Prinzipiell bin ich sehr daran interessiert die Karte auf openstreetmap.org zu bringen.
Es wäre schön wenn der User zwischen openlayers und khtmlib wählen könnte.
Ich habe sehr viel Zeit in dieses Projekt gesteckt. Im Moment ist die ganze Konfiguration und das Testen
das große Problem. Ein noch größeres Problem ist es die Motivation nicht zu verlieren wenn die
Zugriffszahlen gegen 0 tendieren.
Wenn es die Möglichkeit gäbe die Karte bei openstreetmap.org unterzubringen, dann wäre das schon motivierend.
Welche Features müsst ich da einbauen?
Shift-Zoom:
Diese Animation wollte ich eigentlich nicht wirklich einbauen, die (wenigen) User wollten das aber unbedingt haben und ich hab nachgegeben 
Die Animation ist natürlich leicht abschaltbar.
Wenn man z.B. von zoomlevel 5 auf zoomlevel 15 zoomt, dann werden wirklich alle Zwischenlayers geladen.
Beim Firefox wird der Ladevorgang aber abgebrochen wenn das laden zu langsam geht. Bei den webkit Browsern lässt sich eine
Ladevorgang aber leider nicht unterbrechen. Das ist ein Webkit Bug.
Preloading:
Preloading ist komplett abgeschaltet. Alle Berechnungen sind pixelgenau. Was auf dem aktuellen Kartenausschnitt nicht gebraucht wird, das wird nicht geladen.
Diese Vorgangsweise wurde gewählt damit die Karte schnell reagiert.
Mit einem schlechten Preload wird alles langsamer.
Ein intelligentes Preload müsste aber auch abschaltbar sein weil ja nicht alle User eine Flatrate haben.
Jetzt stellt sich halt die Frage wie man ein intelligentes Preload macht. Was soll wann geladen werden?
Sinnvoller wäre wahrscheinlich den Tileserver zu tunen.
Rendering Fehler (Abstände zwischen den Kacheln):
Soweit ich das sehe handelt es sich dabei um Browser Bugs.
Bei Webkit Browsern wird das zoomen von openGL (3D CSS) übernommen und darauf habe ich keinen Einfluss.
Man könnte das mit überlappenden Kacheln lösen. Eine Kachel wäre dann z.B. 257x257 Pixel statt 256x256.
Schnelles Zoomen mit dem Mausrad:
Leider ist das von Browser, Betriebssystem und Benutzereinstellungen abhängig.
Ich habe probiert hier einen Algorithmus zu finden der mit vielen Browsern funktioniert.
Es muss aber für jede Browser Betriebssystem Kombination ein Wert gefunden werden der passt.
Bei solchen Einstellungen bin ich auf Feedback angewiesen weil ich nicht alle Betriebssysteme habe.
Internet Explorer:
Eigentlich sollte alles mit dem IE (auch 6.0) funktionieren.
Der Unterschied zwischen ie6.0 und ie8.0 ist für dieses Projekt irrelevant.
Ich verwende aber eigentlich kein Windows und das Testen ist sehr mühsam.
Tileserver:
Der Google Tileserver ist um einiges schneller. Ob das jetzt nur an den Servern oder auch am Netz liegt kann ich nicht sagen.
Android:
verschieben und Doppelklick zoom sollten funktionieren. Wenn man lange auf das Display drückt, dann sollte ein zoomout Vorgang gestartet werden.
Ich habe zwar einige Handys zum testen aber leider nicht alle.
Im Android Browser vom Legend sind z.B. verdammt viele Fehler. Da wird es schwierig etwas gscheites zu machen.
Für WebOS habe ich das sowieso aufgegeben weil der Browser nicht mal die Basics beherrscht.
Windows Mobile hab ich nicht probiert.
Im Moment habe ich ein N900 da und ich werde versuchen eine Lösung zu finden (bin aber nicht sehr optimistisch)
Entwickelt habe ich das ganze für das iPhone. Auch wenn ich nicht so der Apple Fan bin, der iPhone Browser ist ganz gut geworden. Multitouch gibt es in der
Form bei keinem anderen Handy.
Im Moment probiere ich mit “phonegap” richtige Hand Applikationen zu machen die auf meiner map library basieren. Damit sollte es möglich sein Fehler zu umgehen die z.B. HTC einbaut.
Auch der Kompass sollte funktionieren.
Stufenloser Zoom nur Spielerei?
Der Hauptunterschied zu openlayers ist in der Tat der stufenlose Zoom.
Wenn die Konfiguration passt (Mausrad…) dann kann ich jeden Ort auf der Karte in ca. 10 Sekunden erreichen.
Mit ein bisschen Übung funktioniert die komplette Navigation nur mit zoomin/zoomout.
Durch den stufenlosen Zoom wird die Anzeige natürlich verschwommen.
Wie sehr das stört hängt vom Benutzer und Monitor (DPI) ab.
Mit dem Firefox unter Linux hat das im Moment noch wenig Sinn weil das Zoomen der Bilder mit der nearest neighbor Methode gemacht wird (wird sich hoffentlich ändern)
Wenn beim zoomen immer auf integer Zoomwerte gesnappt wird (so wie Google und Bing) dann hat der
Benutzer keine Kontrolle über das Zoomverhalten. Zum navigieren ist das suboptimal.
Was aber vielleicht der Hauptgrund für das “nichtsnappen” ist: Ich wollte einen Punkt haben in dem sich diese Software erkennbar von Google Maps unterscheidet.
Vektor Rendering:
Um einen nicht verschwommenen stufenlosen Zoom zu bekommen müsste man Vektorgraphiken einsetzen.
Für Webkit Browser wäre das theoretisch auch in einer akzeptablen Geschwindigkeit machbar da man das zoomen hardwarebeschleunigt machen kann.
Das Prinzipielle Problem ist aber, dass die Datenmengen viel zu gross sind.
Zudem gibt es im Moment nur die Möglichkeit die Daten direkt aus der Datenbank zu nehmen. Das ist alles viel zu langsam.
Die Vektordaten könnte man aber vereinfachen und so ähnlich wie die Kacheln als zipfile (browser versteht gzip) zur Verfügung stellen.
Falls jemand den Serverteil macht, baue ich einen Renderer dafür
Lizenz:
Ich habe in der englischen Mailingliste gefragt, was ich da genau hinschreiben soll. Da hab ich leider keine Antwort bekommen.
Auf http://openstreetmap.org fehlt die CC-BY-SA Angabe auch, dort muss man auch weiterklingen.
Es geht mir ganz sicher nicht darum zu verschleiern, dass das auf Openstreetmap aufbaut.
Da ich hier eine Map Library bau, möchte ich die Lizenz IN der Karte anzeigen.
Wenn das jemand auf der eigenen Webpage verwenden will, dann soll sich der Webpage Betreiber nicht darum kümmern, dass er eine
Lizenz dazu schreiben muss.
Bei Google Maps wird die Lizenz auch automatisch angezeigt. Bei meiner Karte habe ich das mit dem grünen Dreieck in der unteren linken Ecke probiert.
Wenn die Lizenz auf http://openstreetmap.org richtig angegeben wäre, dann hätte ich das einfach kopiert.
In der Version die bei openstreetmap.pl verwendet wird, habe ich die Lizenz drinnen. Ich bin mir aber nicht sicher ob das dort wirklich
passt.
liebe Grüße
Bernhard Zwischenbrugger
Als ich den Thread las und auf die Seite gestossen bin, war das erste mir ein Lesezeichen zu setzen. Das Projekt hat mir auf anhieb gefallen, die Karte kann flüssig gezoomt oder bewegt werden!!!So wie man es von Google gewohnt ist. Ob Details hier oder dort fehlen ist mir momentan unwichtig, zumal klar ist, dass sich das Projekt im Beta Stdium befindet.
Klar ist es viel motivierender wenn mal ein paar Besucher vorbeischauen. Allerdings muß ich auch sagen, daß ich durch diesen Post zum erstenmal davon erfahren habe, daß es khtml überhaupt gibt. 
Die Technik macht auf jeden Fall einen recht überzeugenden Eindruck. Wenn’s nicht gleich openstreetmap.org sein muß, könnte ich das auch mal für meine Wanderkarte ausprobieren. Ich hab jetzt noch nicht in den Source geschaut, ist es aufwändig zu nutzen wenn man schon eine OpenLayers Karte hat? Kann es mit mehrschichtigen Karten umgehen?
bye
Nop
es ist natürlich toll, wenn sich jemand soviel Mühe gibt.
Ich hab´s gerade nochmal mit Firefox, Opera und IE versucht.
Die Karte läßt sich nur mit Firefox nutzen. Die beiden anderen Browser stellen die Seiten nicht oder sehr unzuverlässig dar.
In Firefox lassen sich Strassennamen erst ab der Zoomstufe 15 erkennen, darunter werden sie erst gar nicht eingeblendet.
Gruß Juson
Blöde Sache: Wo ist nun der Unterschied? Ich sehe selten was scharf, höchstens beim Zoomen zeitweise. Wo sind nun die Vorteile, abgesehen von den netten Tools oben in den Toolbar.
Das frage ich mich auch… So leid es mir tut, aber ich selber sehe überhaupt keinen Mehrwert gegenüber openlayers… Weder schöner, noch schneller. Zudem kommt noch die Inkompatibilität mit diversen Browsern.
Welche Browser nutzt ihr? Ein Update wäre ggfls. hilfreich oder versucht es mal mit Firefox! Ich sehe erhebliche Unterschiede. Mich nervt bei OSM das einfach zoomen z.B. mit dem Mausrad. Das geht mit KHTML deutlich flüssiger und flexibler!
Hallo,
bei mir läuft die khtlm super-schnell und flüssig (FF 3.6.3) - ist klar die bessere Alternative !
Gruß W.
Ich benutze Windows 7 mit Firefox 3.6.2. Bei mir ist die Ansicht eher schlechter als bei Openlayers.
Bitte nicht als maßlose Kritik verstehen. Ich habe Respekt vor Leuten, die so viel Ahnung von Programmieren haben und freiwillig ihr Talent OSM bereitstellen!
DANKE!
Wenn man es nutzen will ist man auch bereit einen anderen Browser zu installieren. Das kann aber nicht die Lösung sein, zumal es ja ein funktionierendes System gibt.
In vielen Unternehmen ist der IE, der bei Windows dabei ist der Standardbrowser udn andere kann man nicht nutzen. Auch zuhause möchte man nicht x Browser haben und für jede Website einen anderen Browser nutzen müssen. Lieber verzichtet man dann auf die eine Seite, zumal man die Karten auch anderswo bekommt (Google&Co). Das wäre schade für OSM. Von daher sollte die Hauptseite so gestaltet sein, dass jeder das gleiche sieht undabhängig von OS und Browser.
Das Angebot von Nop finde ich daher sehr gut. khtmlib kommt so zu Usern, man beommt evtl. ein breiteres Feedback, hat Motivation zur Weiterentwicklung und wenn alle “Probleme” soweit gelöst sind spricht auch nichts gegen eine Verwendung auf der Hauptseite. Nur derzeit gibt es meiner Meinung nach noch zuviele Nachteile die keine Ablösung eines funktionierenden Systems rechtfertigen.
- Im Geschäft nutze ich IE8, Opera und FF 3.6.3… Auf dem IE8 funktioniert die Zommfunktion nicht immer richtig. Opera hat extrem viele weisse Striche zwischen den Tiles. Wird nicht sauber zusammengefügt (alle 3 Browser können nicht upgedatet werden, da alles auf dem neusten Stand ist - openlayers funktioniert immer richtig)
- Privat nutze ich Firefox 3.6.3 auf Ubuntu. Kein Vorteil von khtml zu openlayers (kann nicht upgedatet werden, da es schon auf dem neusten Stand ist)
- Mobil nutze ich Opera Mini auf Android und auf WM6.1… da ist khtml dem openlayer sehr unterlegen… Zoom und verschieben geht nicht (oder nicht richtig) (Browser kann nicht upgedatet werden, da alles auf dem neusten Stand ist - openlayers funktioniert immer richtig)
Und wieso sollte man etwas ändern, wenn man schon ein funktionierendes System hat, und wenn man danach mit diversen Browsern Probleme hätte? Soll man auf der Startseite einen Vermerk - in der Art “Site ist nur kompatibel mit FF3.6.3 oder höher” - machen? So wie dazumal zu IE4- und IE5-Zeiten? Hallo? Das kann ja wirklich nicht das Ziel sein.
Das stufenlose Zoomen von KHTML sieht flüssiger aus, die Unschärfe bei nicht geraden Zoomstufen ist aber mehr als unschön. Daher sehe ich keinen Vorteil von KHTML. Die (gefühlte) Geschwindigkeit ist Ansichtsache, wie man hier im Thread sieht.
Das geht mit Openlayers auch: http://openlayers.org/dev/examples/measure.html
“auch” heißt, es können beide, also kein Vorteil
Potlatch geht geht sowieso, und einen JOSM-Remote-Link könnte man auch auf der OSM-Hauptseite einbauen. → kein Vorteil
“auch” heißt, es können beide, also kein Vorteil
OL bietet viele weitere Funktionen an, die in OSM nicht genutzt werden. Kann KHTML denn auch alle OL-Funktionen?
Ist KHTML denn ein neues Projekt? Welche Motivation haben denn die Entwickler gehabt? Konnten Sie Ihre Vorstellungen nicht in OL integrieren?
Also für mich gibt es keinerlei Gründe, warum OSM von OL auf KHTML umgestellt werden sollte. Es läuft doch. Derjenige der KHTML besser findet kann das ja in seine eigene Karte einbauen.
Christian
Hmm, und jetzt ist http://khtml.org kaputt. Ihr seid schuld.
Edit: Geht wieder. War wohl „geheist“ bzw. geOSMforumt.