Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo Bernhard, die Beispielseiten gefallen mir. Das Spiel ist eine gute Idee. Könnte man für Schüler gebrauchen in Geographie. Da müßte man eine eigene Liste von Orten definieren können. Bei stufenlosen Zoom werden wohl die Kacheln mit der niedrigeren Auflösung vergrößert, bis die nächste Zoom-Stufe erreicht wird. Das sieht etwas pixelig aus. Hast Du mal probiert, ob es besser aussieht, wenn die Kacheln der höheren Auflösung verkleinert werden? Ich bekomme auf der Seite mit den OSM-Änderungen ab und zu eine Warnung Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr. Sie können das Skript jetzt stoppen oder fortsetzen, um zu sehen, ob das Skript fertig wird. Skript: http://www.khtml.org/osm/v0.52/khtml.js:1434 und manchmal wird das Firefox-Fenster für einige Zeit grau, d.h. es reagiert nicht mehr. Die Warnung über das nicht reagierende Skript kam auch mehrmals hintereinander, d.h. nach dem Schließen des Fensters mit Weiter ausführen kam ein paar mal sofort ein neues. Wenn Du mir sagst, was ich tun soll, helfe ich gern bei der Fehlersuche. (bin Softwareentwickler) Ich habe mit Firefox unter Linux (Ubuntu 64bit) getestet. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am Donnerstag 20 Mai 2010 23:43:30 schrieb Bernhard Zwischenbrugger: Hallo liebe Mapper Hallo Bernhard, Wer auf der englischen Liste mitliest, kennt meine map library wahrscheinlich schon. Jetzt funktioniert die Map auf den meisten Browsern und ich poste das jetzt auch auf diese Liste. Nein, lese ich nicht, danke für die Info :) Gefällt mir gut. Vorallem der feinere Zoom. Das Nachschieben (wenn ich während des Schiebens die Maustaste loslasse) ist ein nettes Gimmick und möchte es auch gar nicht schlecht reden - Design gehört ja schließlich auch dazu. Aber das Schieben ist dadurch teilweise schwerer, da es ungewollt weiter scrollt. Bei Coordinates stehen die aktuellen Parameter, durch Komma getrennt. Ist bei meinem firefox 3.0.19 nicht vom Punkt zu unterscheiden - aber auch kein Beinbruch. Getestete Browser: o Firefox firefox 3.0.19: keine weiteren Fehler entdeckt. o Konqueror Konqueror 3.5.10 (für mich aber vernachlässigbar :D ): Aufruf funktioniert, auch mit Permalink. Aber kein schieben oder zoomen möglich, weder Maus, noch Mausrad. Wenn ich auf fly back klicke tut sich zwar logischer Weise nichts, dafür pappt die Grafik aber am Mauszeiger, als würde ich sie wegziehen wollen. Wo soll ich weitermachen? Was fehlt? Die Ortsangabe in der Suche hat funktioniert. Allerdings wird nur der Ort, mit dem Land angezeigt. Da es den mehrfach gibt, steht das scheinbar Gleiche 5 mal untereinander. Vielleicht kannst du noch Bundesland, Kreis und ähnliches anzeigen lassen. Beim Vollbild (klasse Idee) werden die Koordinaten nicht übernommen. Hast Du mal über die Einbindung und Anzeige von GPX- und anderen Files nachgedacht? Tracks, WP's... Die Software die ich gemacht habe ist eine Map Library also sowas wie openlayers oder google maps api. Das einbinden der Karte sollte aber einmal so leicht sein wie mit google maps (oder einfacher). Es gefällt mir sehr gut vom Design her (z.B. der Zoombalken sieht nach was aus) und auch die Browserunterstützung. injooosm hat z.B. große Probleme mit dem IE :( Ich werde mir das später mal näher ansehen und evtl. als Option integrieren. liebe Grüße Bernhard MfG, Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Bernhard, Bernhard Zwischenbrugger wrote: Wer auf der englischen Liste mitliest, kennt meine map library wahrscheinlich schon. Jetzt funktioniert die Map auf den meisten Browsern und ich poste das jetzt auch auf diese Liste. Kannst Du mal einen kurzen Sales Pitch fuer uns machen - warum sollte man Deine Library benutzen anstatt OpenLayers, was sind aus Deiner Sicht die Vorteile/Unterschiede - und wo hat OpenLayers Dir vielleicht noch Features voraus? Welche grundsaetzlichen Maengel bei OpenLayers haben Dich dazu bewogen, etwas eigenes zu machen? 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] Neue Slippy Map (khtmlib)
On Fri, May 21, 2010 at 08:43:50AM +0200, Christian Knorr wrote: o Firefox firefox 3.0.19: o Konqueror Konqueror 3.5.10 (für mich aber vernachlässigbar :D ): Du solltest mal über ein Update deiner Sofware nachdenken. :) (Diese Versionen sehen nach Kubuntu 8.04 LTS aus. 10.04 LTS ist jetzt echt mal wieder ne brauchbare Version, probier's aus. :) Aufruf funktioniert, auch mit Permalink. Aber kein schieben oder zoomen möglich, weder Maus, noch Mausrad. Wenn ich auf fly back klicke tut sich zwar logischer Weise nichts, dafür pappt die Grafik aber am Mauszeiger, als würde ich sie wegziehen wollen. In einem aktuellen Konqueror konnte ich keine Fehler in der Bedienung feststellen. Die Ortsangabe in der Suche hat funktioniert. Allerdings wird nur der Ort, mit dem Land angezeigt. Da es den mehrfach gibt, steht das scheinbar Gleiche 5 mal untereinander. Vielleicht kannst du noch Bundesland, Kreis und ähnliches anzeigen lassen. Vielleicht einfach Nominatim einbinden? Dann ist auch Hausnummerngenaue Suche möglich. Wie schon gesagt wurde, wäre es vielleicht eine Option, z.B. ab der Hälfte bis zur nächsten Zoomstufe das nächste Tile verkleinert anzuzeigen. Bei Zoom 17.9 sieht es einfach nicht besonders gut aus. Gruß, Bernd pgpACiVSNEOzn.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am Freitag 21 Mai 2010 09:03:21 schrieb Bernd Wurst: Konqueror 3.5.10 (für mich aber vernachlässigbar :D ): Du solltest mal über ein Update deiner Sofware nachdenken. :) (Diese Versionen sehen nach Kubuntu 8.04 LTS aus. 10.04 LTS ist jetzt echt mal wieder ne brauchbare Version, probier's aus. :) Du willst mir ernsthaft KDE4 empfehlen? :) Ein Update auf ubuntu 10.04 ist geplant (gnome), kein KDE mehr. Aber ich hab Angst um meinen 2 Schirm-Betrieb :( das wird wieder eine Gaudi... Aber 8.04 wird noch bis April 2013 supportet, zwar, wenn ich mich recht erinnere nicht für KDE, aber laufen tut es ja immer noch. Außerdem, wer surft schon mit dem Konqueror? Das Ding hat doch ohne ende Darstellungsfehler. Ist zumindest meine Erfahrung mit 8.04. In einem aktuellen Konqueror konnte ich keine Fehler in der Bedienung feststellen. Hast Du es nur getestet, oder nutzt Du den rege? Gruß, Bernd Chris.. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
NopMap schrieb: Ehrlich gesagt bin ich grade ziemlich ratlos - außer die Küstenlinie zu ignorieren und wieder auf händisch erzeugte Seepolygone zurückzugehen. Hat einer von Euch eine Idee, wie man das Problem in den Griff bekommen könnte? Hallo OSM2POWM macht es wie folgt (falls ich es noch richtig in Erinnerung habe) 1. Kuestenlinien sammeln und zusammenfuegen 2. Kuestenlinien auf die einzelnen Kacheln (hier 0.01° x 0.01°) splitten 3. Typ der einzelnen Kacheln aus der oceantiles_12.dat ermitteln (als moeglicher Typ, bzw. Vorschlag fuer einen Typ). Zu beziehen unter http://svn.openstreetmap.org/applications/rendering/png2tileinfo/oceantiles_12.dat 4. Kacheln fluten, ausgehend von den Kuesten-Kacheln und den darin enthaltenen Kuestenlinien. Dabei keine Kacheln die angeblich Land sind fluten. Hilft dann in den Alpen z.B. ;-) 5. Flaechen fuer das Wasser in den einzelnen Kacheln erzeugen 6. je nach Zoom-Stufe mehrere Kacheln (die Flaechen darin) zusamenfuegen und die Kontur und Inseln mit z.B. Douglas-Peucker vereinfachen. 7. freuen, wenn es halbwegs hinhaut... Leider funktioniert es nicht immer, da das GIGO-Prinzip immer noch guetig ist. ;-) http://de.wikipedia.org/wiki/Gigo Julian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On Fri, May 21, 2010 at 09:24:46AM +0200, Christian Knorr wrote: Konqueror 3.5.10 (für mich aber vernachlässigbar :D ): Du solltest mal über ein Update deiner Sofware nachdenken. :) (Diese Versionen sehen nach Kubuntu 8.04 LTS aus. 10.04 LTS ist jetzt echt mal wieder ne brauchbare Version, probier's aus. :) Du willst mir ernsthaft KDE4 empfehlen? :) Ich sage es ist mal wieder ne benutzbare Version. :) Nachdem es die Zwischenversionen geschafft haben, den Ruf von Kubuntu in Grund und Boden zu zerstören, ist das eben mal wieder etwas das in die richtige Richtung geht. Ein Update auf ubuntu 10.04 ist geplant (gnome), kein KDE mehr. Aber ich hab Angst um meinen 2 Schirm-Betrieb :( das wird wieder eine Gaudi... Aber 8.04 wird noch bis April 2013 supportet, zwar, wenn ich mich recht erinnere nicht für KDE, aber laufen tut es ja immer noch. Außerdem, wer surft schon mit dem Konqueror? Das Ding hat doch ohne ende Darstellungsfehler. Ist zumindest meine Erfahrung mit 8.04. Ich kenne den Gedankengang. Aber ein KDE-Nutzer wird Gnome nicht mögen. Ich habe es auch probiert. Da ist KDE4 wirklich immer noch besser. :) Ich glaube es wird OT. Probier's einfach mal aus. Am besten ist es, wenn man KDE4 vorher noch nie gesehen hat und die ganze Katastrophe um die bisherigen Releases einfach mal links liegen lässt. In einem aktuellen Konqueror konnte ich keine Fehler in der Bedienung feststellen. Hast Du es nur getestet, oder nutzt Du den rege? Ich hab grade mal Konqueror gestartet und die Karte dort laufen gelassen. Dabei konnte ich zoomen, verschieben und was man halt so mal eben mit einer slippymap macht. Nein, regulär nutzen will man Konqueror natürlich nicht, das ist mal klar. :) Gruß, Bernd pgpjcamOswnfY.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo Nop, ich bin derzeit am überlegen, ob ich mir nicht eine Küstenlinie extrahiere, diese dann soweit bearbeite, das alles passt und diese dann umtagge, negative ID's vergebe und mit dem jewiligen Planetfile merge. Über einen osmosis-Filter könnte man auch vorher natural=coastline herausfiltern, dann erspart man sich das umtaggen und Ersetzungsregeln im Composer, die wieder natural=coastline ausgeben. -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5083176.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
[Talk-de] Arbeiten mit Osmosis (war: Re: W ohnmobil-Stellplätze bei OSM)
Hallo zusammen, Um die Datenmenge mit der ich arbeite klein zu halten, habe ich zunächst aus dem osm-File mittels 'osmosis' die 'nodes' und 'ways' die als 'tourism=caravan_site' getaggt sind, extrahiert. Ich arbeite hier mit dem Schweizer Ausschnitt (ca. 80 MB). Wenn ich mit Osmosis alle Toiletten (amenity=toilets) kopiere, dann dauert das 30 Minuten - ein Import der Schweiz mit osm2pgsql klappt aber in nur 6 Minuten und ich bin danach viel flexibler.. Ist Osmosis bei grösseren Datenmengen (im Verhältnis) schneller? Oder welche Vorteile hat Osmosis? Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM und Maxspeed
gibt es in JOSM einen Schalter, mit dem ich die Maxspeed Färbung ab- und anschalten kann? Es gibt in den Einstellungen Karteneinstellungen die Option Stile zu aktivieren und deaktivieren. http://n2.nabble.com/file/n5083227/Karsteneinstellungen.jpg Ich bin mir aber nicht ganz sicher, ob Du das meinst. Ansonsonten kannst Du noch alle Elemente, die das maxspeed Tag haben inaktiv schalten oder ausblenden mit dem Displayfilter. Dann kannst Du besser sehen, welche Elemente bereits ein maxspeed-Tag haben, ohne dass alles bunt wird. In den neueren Versionen von JOSM ist der Displayfilter in der linken Auswahlliste einfach auswählbar. Gruß Oliver http://n2.nabble.com/file/n5083227/Displayfilter-maxspeed.jpg -- View this message in context: http://gis.638310.n2.nabble.com/JOSM-und-Maxspeed-tp5082802p5083227.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] Arbeiten mit Osmosis (war: Re: W ohnmobil-Stellplätze bei OSM)
Hallo, Thomas Ineichen wrote: Ich arbeite hier mit dem Schweizer Ausschnitt (ca. 80 MB). Wenn ich mit Osmosis alle Toiletten (amenity=toilets) kopiere, dann dauert das 30 Minuten - ein Import der Schweiz mit osm2pgsql klappt aber in nur 6 Minuten und ich bin danach viel flexibler.. Kommt drauf an, was Du machen willst. Osmosis erzeugt Dir halt einen echten OSM-Datensatz, den Du auch z.B. in den JOSM laden und bearbeiten und wieder hochladen kannst. *Diese* Flexibilitaet hast Du mit osm2pgsql nicht. Auch wird Osmosis Dir alle Tags extrahieren, osm2pgsql nur die, die Du per style-File anforderst (ausser natuerlich, Du bastelst mit dem neuen hstore-Zeug rum). Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo! aighes wrote: ich bin derzeit am überlegen, ob ich mir nicht eine Küstenlinie extrahiere, diese dann soweit bearbeite, das alles passt und diese dann umtagge, negative ID's vergebe und mit dem jewiligen Planetfile merge. Über sowas denke ich auch nach - das wär halt wieder ein anderer Weg zu manuell gepflegten, lokalen Seepolygonen. Falls wir nix besseres finden, laß uns zusammen dran arbeiten, das können wir dann gleich als Feature in Composer einbauen. Der knifflige Teil dabei dürfte es sein, die Küstenlinien dann wieder mit dem aktuellen Datenbestand zu mergen. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5083284.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] Neue Slippy Map (khtmlib)
Hi Bodo die Beispielseiten gefallen mir. Das Spiel ist eine gute Idee. Könnte man für Schüler gebrauchen in Geographie. Da müßte man eine eigene Liste von Orten definieren können. Ich habe die Liste der Hauptstädte aus der Wikipedia geparst: http://en.wikipedia.org/wiki/List_of_national_capital_cities_by_population So eine Liste händisch zu erstellen ist glaub sehr mühsam. Wenn es aber möglich wäre solche Listen direkt aus der OSM Datenbank zu erstellen, dann wäre das schon ein Hit. Ich werde mal osmxapi genauer anschauen - vielleicht geht es da. Ein richtiges Spiel ist es halt leider auch noch nicht. Nach 10 Hauptstädten ist es einfach nicht mehr interessant. Der Spielwitz fehlt. Vielleicht muss ich noch ein paar Monster zum abknallen einbauen ;-) Bei stufenlosen Zoom werden wohl die Kacheln mit der niedrigeren Auflösung vergrößert, bis die nächste Zoom-Stufe erreicht wird. Das sieht etwas pixelig aus. Hast Du mal probiert, ob es besser aussieht, wenn die Kacheln der höheren Auflösung verkleinert werden? Ich bin selbst Ubuntu Benutzer. Der Firefox verwendet beim Bilder Zoomen die nearest neighbor Methode. Der Firefox unter Windows verwendet da bereits eine andere Methode. Mit dem chromium wird das nicht pixelig aber dafür ein bisschen verschwommen. Es ist leicht möglich die Kacheln der höheren Auflösung zu verwenden. Einfach den Zoomfaktor im Browser ändern STRG-. Das Ergebnis ist aber nicht wirklich gut. Die Beschriftung wird zu klein und ist nicht mehr lesbar. Für Menschen mit schlechten Augen ist die Karte jetzt schon nicht verwendbar (sagt zumindest eine Freundin von mir die nicht mehr ganz gut sieht). Mit doppelclick kommt man übrigens immer auf einen richtigen (integer) Zoomlevel. Ich bekomme auf der Seite mit den OSM-Änderungen ab und zu eine Warnung Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr. Sie können das Skript jetzt stoppen oder fortsetzen, um zu sehen, ob das Skript fertig wird. Skript: http://www.khtml.org/osm/v0.52/khtml.js:1434 und manchmal wird das Firefox-Fenster für einige Zeit grau, d.h. es reagiert nicht mehr. Die Warnung über das nicht reagierende Skript kam auch mehrmals hintereinander, d.h. nach dem Schließen des Fensters mit Weiter ausführen kam ein paar mal sofort ein neues. Wenn Du mir sagst, was ich tun soll, helfe ich gern bei der Fehlersuche. (bin Softwareentwickler) Da kommt das ganze System an die Grenzen. Ein Problem das ich nicht lösen kann ist, dass die Datenbank einfach zu langsam ist. Im Moment geht das auf die OSM Hauptdatenbank und wenn das viele verwenden, dann werden das die Admins wahrscheinlich auch sperren weil die ganze DB in die Knie geht. Bei osmxapi gibt es die changesets nicht - das ist also auch keine Alternative. Hier ist ein Beispiel für eine langsame Abfrage: www.openstreetmap.org/api/0.6/changesets?bbox=104.838,11.536,105.010,11.577 Wenn viele Daten geladen werden, dann bekommen auch die Browser Probleme - das könnte ich aber vielleicht lösen. Eventuell löst sich das aber auch selbst wenn die Browser schneller werden (Firefox 3.7 bringt Hardwarebeschleunigung) liebe Grüße Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am 21. Mai 2010 09:24 schrieb Christian Knorr os...@gmx.de: Du willst mir ernsthaft KDE4 empfehlen? :) Ein Update auf ubuntu 10.04 ist geplant (gnome), kein KDE mehr. Wir haben 2010... das pauschale KDE4 ist untauglich ist schon bei 4.3 reichlich dünn gewesen, bei 4.4 meines Erachtens einfach nur noch peinlich. Wenn du ein aktuelles KDE willst, nimm KDE4, wenn du GNOME lieber magst, nimm GNOME, aber was zwingt jemanden, der eigentlich lieber KDE nutzen würde, im Jahre 2010 noch zu GNOME? Gruß, Martin (seit 4.2 umgestiegen und zwischendurch auch durchaus genervt, jetzt ziemlich glücklich mit 4.4) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am 20. Mai 2010 23:43 schrieb Bernhard Zwischenbrugger b...@datenkueche.com: Hallo liebe Mapper o iPhone/iPad mit multitouch zoom o Multitouch auf dem iPhone/iPad Da brauch ich jetzt aber Hilfe weil ich schon ein bisschen Betriebsblind bin ;-) Wo soll ich weitermachen? Was fehlt? o http://www.khtml.org/osm/v0.52/3d.html (perspekte für iPhone, iPad, Safari Mac) Wo soll ich weitermachen? liebe Grüße Bernhard Hi Bernard Tolle Sache. Prima gemacht! Auf dem IPod Touch ist diese Slippymap echt gut benutzbar (Im Gegensatz zu OpenLayers). Wünche ich mir für die Hauptseite. In der 3D Perspektive finde ich den Zoom etwas seltsam. Irgendwie verschiebt sich dabei der (gefühlte, also perspektivische) Mittelpunkt, oder irre ich mich? Netten Dank Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Häuser einzeichnen?
Am 20.05.2010 13:50, schrieb Friedhelm Schmidt: Da ich nicht kapiere wo man die BBOX Angaben machen muß, damit man einen WMS-Link für JOSM erzeugen kann, habe ich das Ergebnis runtergeladen. Das geht einfacher: Unter WMS | Berichtigtes Bild Geothings Mapwarper auswählen und darunter die ID deines Bilds eingeben. Die ID steht in der URL, z.b. für das Bild Miesbach, Germany: http://warper.geothings.net/maps/2596 ist die ID 2596 -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Hallo Friedhelm, vielen Dank für den Tipp. Funktioniert recht gut. Allerdings stört mich am Mapwarper, dass das korrigierte Bild eine sehr schlechte Auflösung hat. Gibt es dort irgendwo eine Stellschraube, damit man dieses Manko vermeiden kann? Denn wenn man in JOSM reinzoomt, dann sieht man von manchen Häusern nur noch Klötzchen. Die Datei die ich heute hochgeladen habe, war knapp 5MB groß, damit man auch noch Feinheiten sehen kann. Gruß Horst ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Häuser einzeichnen?
Am 21.05.2010 11:04, schrieb hike39: Allerdings stört mich am Mapwarper, dass das korrigierte Bild eine sehr schlechte Auflösung hat. Gibt es dort irgendwo eine Stellschraube, damit man dieses Manko vermeiden kann? Das stimmt leider. Ich habe die beste Erfahrung damit gemacht, die Bilder strikt selbst so zu re-samplen, dass die längste Kante knapp unter 1500 Pixeln liegt. Lade dir mal http://warper.geothings.net/maps/2601 in Josm (9.22259,49.14274,9.22692,49.14529) das sieht doch schon ganz ordentlich aus. Ach, noch ein Tipp: Wenn du in das Luftbild rein zoomst, kannst du mal rechts auf Ebenen, Geothings Marwarper rechtsklicken und Auflösung ändern auswählen. Dann wird das Bild in höherer Auflösung nachgeladen. -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Check Traces vs gemappte Ways?
M∡rtin Koppenhoefer schrieb: Am 15. April 2010 17:51 schrieb olvagor o...@terbrueggen.net: Ich hab hier schon öfter den Fall gehabt, dass jemand im Wald GPS-Tracks hochgeladen aber dann keine Wege gezeichnet hat. Wenn ich das so mache dann entweder, weil der Empfang schlecht war, oder weil ich gar nicht auf Wegen unterwegs war. Blind fremde Tracks nachzuzeichnen und deren Ursache raten halte ich nicht für sinnvoll. Genau. Fremde Tracks zeichne ich grundsätzlich nicht einfach nach, ohne dass ich mal dort war. Mir haben aber schon öfters fremde Tracks geholfen, wenn ich gemerkt hab, dass mein Trace mal ein Stück lang miese Qualität hat. Wie gesagt - wenn ich selber dort war! Umgekehrt habe ich auch schon Traces hoch geladen, die ich nebenbei aufgenommen hab, ohne mich bewusst dort umzusehen. Solche Nebenbei-Traces ordne ich für mich genauso ein, wie fremde. Ich kann sie nicht einfach nachzeichnen, weil ich mir gar kein Bild machen kann, wie es dort eigentlich aussah. Für den aber, der die Gegend aktiv bearbeitet, können sie eine gute Hilfe sein. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Servus Christian Danke für die super Bugreports Gefällt mir gut. Vorallem der feinere Zoom. Das Nachschieben (wenn ich während des Schiebens die Maustaste loslasse) ist ein nettes Gimmick und möchte es auch gar nicht schlecht reden - Design gehört ja schließlich auch dazu. Aber das Schieben ist dadurch teilweise schwerer, da es ungewollt weiter scrollt. Das hatte mit Design wenig zu tun, das war einfach Fehlerhaft ;-) Ich hab das jetzt geändert und das Nachschieben erfolgt nur noch aber einer gewissen Geschwindigkeit. Bei Coordinates stehen die aktuellen Parameter, durch Komma getrennt. Ist bei meinem firefox 3.0.19 nicht vom Punkt zu unterscheiden - aber auch kein Beinbruch. Jetzt ist ein | drinnen. Schaut besser aus. Die Ortsangabe in der Suche hat funktioniert. Allerdings wird nur der Ort, mit dem Land angezeigt. Da es den mehrfach gibt, steht das scheinbar Gleiche 5 mal untereinander. Vielleicht kannst du noch Bundesland, Kreis und ähnliches anzeigen lassen. Sodala, jetzt ist nominative drinnen. Mit dem alten namefinder war ich nicht zufrieden weil er einfach zu langsam war. Deshalb habe ich geonames verwendet. Nominative scheint jetzt aber gut zu funktionieren. Beim Vollbild (klasse Idee) werden die Koordinaten nicht übernommen. Sollte jetzt funktionieren. Hast Du mal über die Einbindung und Anzeige von GPX- und anderen Files nachgedacht? Tracks, WP's... Ja klar. GPX, KML, OSM-XML werd ich alles einbauen. Eigentlich hab ich es schon gemacht - allerdings halt nur als Quickhack. KML ist natürlich ein gewaltiger Standard - da werde ich wohl nicht alles machen. Die Software die ich gemacht habe ist eine Map Library also sowas wie openlayers oder google maps api. Das einbinden der Karte sollte aber einmal so leicht sein wie mit google maps (oder einfacher). Es gefällt mir sehr gut vom Design her (z.B. der Zoombalken sieht nach was aus) und auch die Browserunterstützung. injooosm hat z.B. große Probleme mit dem IE :( Ich werde mir das später mal näher ansehen und evtl. als Option integrieren. Der IE ist natürlich ein eigenes Thema. Viel getestet hab ich nicht mit dem IE - sollte aber funktionieren. Der Android Browser ist auch so ein Schmudelkind - das mögen aber die Android Handy Besitzer aber gar nicht hören ;-) lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Viel zu arbeiten ist da egtl. nicht. Ich hab mir die planet-Datei zurechtgeschnitten und daraus dann die Küstenlinien rausgefiltert. osmosis aufruf, so wie es der Composer macht, nur anstatt von --bounding-box... --tf accept-ways natural=coastline --tf reject-relations --used-node Dann hab ich die Datei in josm geladen und die entsprechenden Stellen gelöscht und wieder abgespeichert. Hilfreich finde ich dazu das Plugin slippymap. Damit sieht man dann, was der coastline-Kreis sein soll. Nun die Datei im Editor öffnen und id=' mit id='-, ref=' mit ref='- und coastline mit bspw. own_coastline ersetzen. Jeweils immer mit alles ersetzen und wiederum speichern ( und jeweils weglassen ;-)). Im Anschluss merge ich die beiden Dateien zusammen. --read-xml-0.6 file=... --sort-0.6 --read-xml-0.6 file=... --sort-0.6 --merge --write-xml file=... Mal schauen, was der Composer zu der fertigen Datei sagt... (bin gerade am mergen) Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5083608.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
[Talk-de] Mapping von maxspeed:forward und maxspeed:backward
Moin, mich würde interessieren, ob jemand von euch zu folgendem Problem noch ein paar nützliche Tipps hat: Idealer weise mappt man maxspeed indem man den selben Weg hin und wieder zurück fährt. Nur so fällt einem auf, ob die Geschwindigkeitsbegrenzungen in beiden Fahrtrichtungen synchron sind. Fährt man den Weg nur in eine Richtung ab, so kann man dies nicht feststellen und bemerkt daher in aller Regel auch nicht ob man es anstatt eines maxspeed tatsächlich mit einem maxspeed:forward bzw. maxspeed:backward zu tun hat. Fährt man die Strecke nur in eine Richtung, so erscheint alles als maxspeed= Wie lässt es sich nun am günstigsten vermeiden, dass jemand der die Strecke in Gegenrichtung abfährt und ein in seiner Richtung nicht vorhandenes maxspeed vorfindet dieses nicht löscht sondern in ein maxspeed:forward bzw. maxspeed:backward umwandelt. Mit anderen Worten wie mache ich am günstigsten darauf aufmerksam, dass sich meine Eintragungen in der Datenbank nur Beobachtungen für eine Fahrtrichtung enthalten. Alles erst einmal nur als maxspeed:forward bzw. maxspeed:backward taggen, in der Hoffnung, dass der Nächste, der die Strecke aus der Gegenrichtung abfährt ggf. die synchronen Abschnitte in ein maxspeed umwandelt? Da es deutlich mehr synchrone als asynchrone Geschwindigkeitsbegrenzungen gibt erscheint mir dieses Vorgehen nicht wirklich sinnvoll. Zumal der Gegenrichtungsfahrer eine solche Datenbankeintragung auch erst einmal richtig interpretieren muss. Danke Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo, NopMap wrote: Eigentlich ist die Aufgabenstellung ganz einfach: Ich versuche, eine Garminkarte von Mitteleuropa zu erzeugen, mit Meerespolygonen, die per mkgmap aus den natural=coastline Tags erzeugt werden. Kannst Du nicht die processed_p-Kuestenlinien nehmen und daraus schnell Pseudo-OSM-Daten fuer den mkgap bauen? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM städtisch ausgelegt. Land brauch t den cyclefootway
Martin Simon schrieb: Am 19. Mai 2010 08:35 schrieb Karl Eichwalder k...@gnu.franken.de: +1, so isses. -1, das ist falsch und das weißt auch du. Noch einmal: wenn du es nicht magst, benutze es nicht, sondern das alternative foot/cycle/bridleway-Schema - aber hör auf, hier das tag zu verbiegen. Ja, genau! Genaugenommen kann Path mit den entsprechenden Attributen alles abbilden, was schmaler als ein Weg ist. Neue Tags, die das Spektrum von highway=* noch breiter machen halte ich nicht für so sinnvoll. Für besser halte ich, Attribute zu benutzen, die z.B. highway=track genauer beschreiben. Auch dürfte das der Entwicklung der verschiedene Renderer entgegenkommen. highway=path können sie ohnehin darstellen, auch wenn sie die Attribute noch nicht komplett auswerten. Wenn man der Meinung ist, dass Pfade mit bestimmten Attributen abweichend dargestellt werden sollen, kann man das später auch in den Renderer einbauen. Man kann mit einer überschaubaren Menge an Attributen eine große Zahl verschiederer Tags mit bestimmten Eigenschaften versehen, die von der Software oft generisch behandelt werden können. Also von mir ein klares NEIN zu cyclefootway oder ähnlichen Konstruktionen. Gruß Burkhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am 21.05.2010 10:35, schrieb Bernhard Zwischenbrugger: Ich habe die Liste der Hauptstädte aus der Wikipedia geparst: http://en.wikipedia.org/wiki/List_of_national_capital_cities_by_population So eine Liste händisch zu erstellen ist glaub sehr mühsam. Wenn es aber möglich wäre solche Listen direkt aus der OSM Datenbank zu erstellen, dann wäre das schon ein Hit. Hallo Bernhard, meine Idee für Schüler wäre die Erstellung von Listen passend zum gewünschten Thema, beispielsweise europäische Hauptstädte, Hauptstädte der deutschen Bundesländer, Kreisstädte, Berge, Flüsse usw. Die Liste der zu findenden Orte könnte man manuell erstellen oder wenn eine passende Quelle (Wikipedia) vorhanden ist, auch automatisch extrahieren. Es sollte eine Möglichkeit zum automatischen Ermitteln der Zielkoordinaten geben. Vielleicht kann man eine Datei mit den erforderlichen Daten irgendwo hochladen und in der Spiel-URL einen Verweis auf die Datei angeben. So könnte man eine eigene Spielversion mit individueller Auswahl benutzen. Weitere Idee: Ziele zufällig sortieren Es ist leicht möglich die Kacheln der höheren Auflösung zu verwenden. Einfach den Zoomfaktor im Browser ändern STRG-. Das Ergebnis ist aber nicht wirklich gut. Die Beschriftung wird zu klein und ist nicht mehr lesbar. Der Zoonfaktor im Browser hat bei mir nur die Wirkung, daß generell alles skaliert wird und dadurch unscharf aussieht. Das ändert aber nichts am grundsätzlichen Verhalten. Ich meine die Umschaltung der Kacheln beim stufenlosen Zoom der Karte: Wenn ich beispielsweise den Zoom von 14 aus langsam hochstelle, werden die Grafiken immer weiter vergrößert und damit bei mir pixelig. Geht dann der Zoom von 14,9 auf 15, werden die Kacheln im nächsten Zoom-Level verwendet und sehen wieder gut aus. Auch mit geändertem Browser-Zoom wird es von 15 zu 14,9 pixelig. Wie sieht es aus, wenn bei 14,1 bis 14,9 nicht die Bilder von Zoomlevel 14 vergrößert werden, sondern die Bilder von 15 verkleinert? Oder den Sprung in die Mitte legen, beispielsweise im Bereich von 14,6 bis 15,5 die Kacheln in Zoom 15 verwenden? Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AKÜFI (was: AIO keine Adressen mehr )
Christian Knorr glaubte zu wissen: Nun zur Sache: mir fehlt absolut die Phantasie, was mit NKIN wambacher Ich hab das als Fipptehler gewertet und als NEIN gelesen. Auch wenn ich den Sinn nicht so recht entschlüsseln konnte/wollte. oder -v ausgedrückt werden soll. Einigen Programmen kann man auf der Kommandezeile die Option -v mtgeben, was für das Programm heißt Sei mal ausführlicher. flo -- Trotz mehrfacher muendlicher Anmahnung ist das Kuechenfenster bis heute noch nicht ordnungsgemaess dekoriert. [Der Rechtsanwalt eines Vermieters] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo, als Nutzer der Karten wäre es mir wichtig, dass diese einfach eingebunden werden können. Ich übergebe ihm im funktionsaufruf die BoundingBox und bspw. eine gpx-Datei und den Rest macht dann dein Skript. Das Zoomverhalten an sich finde ich super, allerdings durch die Unschärfe ist die Karte kaum zu gebrauchen. Viele Grüße, aighes -- View this message in context: http://gis.638310.n2.nabble.com/Neue-Slippy-Map-khtmlib-tp5081762p5083733.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] Neue Slippy Map (khtmlib)
Servus Frederik Kannst Du mal einen kurzen Sales Pitch fuer uns machen - warum sollte man Deine Library benutzen anstatt OpenLayers, was sind aus Deiner Sicht die Vorteile/Unterschiede - und wo hat OpenLayers Dir vielleicht noch Features voraus? Welche grundsaetzlichen Maengel bei OpenLayers haben Dich dazu bewogen, etwas eigenes zu machen? Die großen Unterschiede: o Zoom Speed o nicht integer Zoomlevel o Multitouch am iPhone/iPod Angefangen hab ich mit einer Karte für das iPhone. Multitouch macht nur Sinn wenn man fliessende Zoomlevel zulässt. Für die webkit Desktop Browser war das dann leicht zu adaptieren. Am Firefox auf Linux schaut das natürlich beschissen aus, weil die Bilder mit der nearest neighbour Methode gezoomt werden. Mit chromium funktioniert das aber schon ganz fein. Wenn man ein klares Bild will, dann kann man doppelklick auf den nächsten Zoomlevel scharfstellen. Wirklich interessant ist die map mit Chromium 5 (beta) und einem schnellen TileServer. Es kommt eine dritte Dimension dazu. Ich hoffe Google verklagt mich jetzt nicht gleich aber hier hab ich mal den Google Tileserver in Verwendung: http://www.khtml.org/osm/v0.57/google.html (das ist illegal und ich werde es wieder entfernen) OpenLayers kenn nur Integer Zoom Level. Das rein optische Navigieren finde ich bei OL eher schwierig. Bei einem doppelklick wird bei OL die Karte neu aufgebaut und ich verirre mich immer. Rauszoomen und an einer anderen Stelle wieder reinzoomen macht bei OL nicht wirklich spass. OpenLayers kann natürlich viel mehr. Ich kenne OL nicht wirklich, aber mir fallen jetzt folgende Dinge ein: o Layers o GPX o KML o andere Koordinaten Systeme (nicht WGS84) o ... Eventuell wäre es möglich meine Map in OL zu integrieren - dürfte aber doch eher schwierig sein. Andererseits denke ich, dass es recht einfach sein sollte, diese Dinge in meine Karte einzubauen. Schwierig ist aber aber wiederum die Geschwindigkeit nicht zu verlieren. Im Moment probiere ich die API richtig zu machen. Ich möchte die Dinge die für Geschwindigkeit zuständig sind klar vom Rest Trennen. Wenn Dinge nur auf Geschwindigkeit optimiert sind, dann wird der Programm Code einfach nicht schön und nicht leicht wartbar. Eine low level API ist daher wichtig. lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Das Zoomverhalten an sich finde ich super, allerdings durch die Unschärfe ist die Karte kaum zu gebrauchen. Ja leider. Man muss schon die ganzen Zoomstufen exakt treffen, damit man sich nicht die Augen reiben muss ob der Unschärfe. - Wenn die Animation so toll gefällt, dann kann man sie ja trotzdem drinlassen, aber eben nur auf ganzen Zoomstufen einrasten lassen. - Koordinateneingabe (im Suchfeld) funktioniert nicht, zumindest nicht mit den Notationen die google-maps versteht. (für osm.org gibt's da ein greasemonkey-script, was das nachrüstet.) - Wenn man über die Suche den dargestellten Bereich wechselt, dann bleiben die zuvor gesetzten Entfernungs-Marker drin, selbst wenn die Entfernung auf Grund der Projektion (andere Äquatordistanz) hier überhaupt nicht mehr passen kann. - Wenn ich im Firefox (3.6) den Zoom-Wert umschalte, verrutscht der Kartenausschnitt spontan irgendwo ins Wasser bei Grönland -jha- P.S. Was dieser Linux-Flameware unter diesem Topic auf dieser Liste soll bleibt mir ein Rätsel. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo Bernhard, die Idee von Bodo finde ich gut: Sprung in die Mitte legen, beispielsweise im Bereich von 14,6 bis 15,5 die Kacheln in Zoom 15 verwenden? Vielleicht legt man den Sprung bei #,3? 14,0..14,3 von z=14 vergrössern 14,4..14,9 von z=15 verkleinern (oder so) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo, leider mochte er Comopser meine preparierte Datei nicht. Hast du eine Ahnung, wass da falsch gelaufen sein könnte? Unter http://www.aighes.de/data/coastline_germany.7z hab ich mal die Datei mit den geänderten Küstenlinien hochgeladen. java.lang.IllegalArgumentException: nodes ids are not in ascending order Exception analyzing data for Germany java.lang.IllegalArgumentException: nodes ids are not in ascending order at nop.osm.nodeindex.NodeIndex.storeNode(NodeIndex.java:80) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:302) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:309) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copy(NodeTree.java:297) at nop.osm.nodetree.NodeTree.copyTo(NodeTree.java:285) at nop.osmc.generator.An alyzer.standardAn alysis(An alyzer.java:120) at nop.osmc.generator.An alyzer.an alyze(An alyzer.java:69) at nop.osmc.generator.Mapper.generate(Mapper.java:183) at nop.osmc.MapComposer$12.act(MapComposer.java:378) at nop.gui.MenuThreadAction.run(MenuThreadAction.java:27) at java.lang.Thread.run(Unknown Source) -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5083919.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] Neue Slippy Map (khtmlib)
Am 20.05.2010 um 23:43 schrieb Bernhard Zwischenbrugger: Features: o Schnelles stufenloses zoomen mit dem Mausrad o Multitouch auf dem iPhone/iPad o Vektor Graphik Wie wäre es mit Multitouch für die normalen Browser? Bei MacBooks hat man mit dem wunderbaren Glastrackpad die gleichen Zoomgesten wie auf dem iPhone/iPad. Bei deiner Webseite zoomt man damit aber leider nicht die Karte sondern die ganze Webseite. Falls man das umstellen kann auf nur die Karte wäre das super und viel besser nutzbar. -Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falsche(?) hamlets
Am 19. Mai 2010 16:11 schrieb René Falk li...@falconaerie.de: Die Gemeinde Bodolz daneben hat ebenfalls mehrere Ortsteile [2], doch sind manche nicht größer als ein Weiler. Wäre hier hamlet für alle Ortsteile die richtige Lösung? Hängt davon ab, wie es vor Ort ausschaut. Ist ein Ortsteil eher ein Dorf als ein Weiler, würde ich ihn auch als village taggen. Wenn der Ortsteil eher wie ein Weiler ausschaut, dann hamlet. +1, die manchen, die Weiler sind, als hamlet, und die die Dörfer sind als village. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
hi Sprung in die Mitte legen, beispielsweise im Bereich von 14,6 bis 15,5 die Kacheln in Zoom 15 verwenden? Vielleicht legt man den Sprung bei #,3? 14,0..14,3 von z=14 vergrössern 14,4..14,9 von z=15 verkleinern (oder so) Jetzt hab ich mal den Sprung bei 0.5 gemacht: http://www.khtml.org/osm/v0.57.5/ Das Problem ist jetzt, dass die Schrift verdammt klein wird. Zudem muss der Browser viel mehr Kacheln laden und alles wird langsamer. Für den Firefox mit Linux hilft das aber alles nichts, das ist ein anderes Problem. Mit Doppelklick kommt man aber immer auf einen scharfen Zoomlevel. Es wäre natürlich möglich immer automatisch auf einen ganzzahligen Zoomwert zu kommen. Also so wie bei google oder bing maps. Ich werde einen Parameter einbauen der das ermöglicht. lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] TMC Points
Hi Ich habe ich in den letzten Tagen an Taggen von TMC gemacht. Mittlerweile frage ich mich allerdings ob TMC Location Points nicht fast immer eher ein Weg ist oder sogar eine Relation mit mehreren Wegen als Mitglieder. Wie ich aus der Diskussion vor ein paar Monaten gelesen habe gibt es da ja keine einheitlichen Schemata. cu colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On Fri, May 21, 2010 at 02:43:22PM +0200, Bernhard Zwischenbrugger wrote: Jetzt hab ich mal den Sprung bei 0.5 gemacht: http://www.khtml.org/osm/v0.57.5/ Das Problem ist jetzt, dass die Schrift verdammt klein wird. Optisch ist das IMHO viel besser. Zudem muss der Browser viel mehr Kacheln laden und alles wird langsamer. Das mit den mehr Kacheln ist natürlich ein schwer zu lösendes aber valides Problem. Für den Firefox mit Linux hilft das aber alles nichts, das ist ein anderes Problem. Ich versteh das gar nicht. Wird das definitiv in 3.7 gefixed oder muss man irgendwo für einen Bugreport voten? ;-) Ist ja nicht so, dass Linux irgendwie per se keine normalen Skalierungen unterstützen würde... Mit Doppelklick kommt man aber immer auf einen scharfen Zoomlevel. Gut zu wissen. :) Es wäre natürlich möglich immer automatisch auf einen ganzzahligen Zoomwert zu kommen. Also so wie bei google oder bing maps. Ich werde einen Parameter einbauen der das ermöglicht. Das wäre vermutlich für einen Großteil der Benutzer der bevorzugte Weg, denn skalierte Pixelgrafiken sind halt immer nich ganz das gelbe vom Ei. Wäre die Frage, ob du dich hier als eierlegende Wollmichsau aufstellen willst und alle Anwendungsgebiete optimal abbilden möchtest oder ob du sagst, dir ist eine Alternative zu OpenLayers wichtig, die eben eine andere Zielgruppe hat. Ich denke mal smooth-zooming sollte sich auch in OpenLayers irgendwie einbauen lassen. Wenn jetzt also die Linux-Firefox-User nicht wirklich in deine Zielgruppe passen, weil die eher OpenLayers-Seiten anschauen solltest, dann musst du natürlich auch nicht einbauen was nur die wollen. :) Gruß, Bernd pgpX4DV40A9Y1.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo, Bernd Wurst wrote: Wäre die Frage, ob du dich hier als eierlegende Wollmichsau aufstellen willst und alle Anwendungsgebiete optimal abbilden möchtest oder ob du sagst, dir ist eine Alternative zu OpenLayers wichtig, die eben eine andere Zielgruppe hat. Wenn ich das richtig verstanden habe, ging es darum, dass das sanfte Zoomen halt besser in die iWhatever-Welt mit der Fingerbedienung passt. Vielleicht waere es ein guter Kompromiss, wenn das Standardverhalten der Library vom User Agent abhinge? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Bernhard Zwischenbrugger b...@datenkueche.com wrote: Am Firefox auf Linux schaut das natürlich beschissen aus, weil die Bilder mit der nearest neighbour Methode gezoomt werden. Rasterbilder dieser Art mit wenig Details und wenig verscheidenen Farben. Typische Kartenkacheln halt will man eigentlich nicht skalieren da finde ich ehrlich gesagt die Idee das überhaupt zu tun broken. Was man eigentlich haben will, was aber derzeit nur mit high end OpenGL Hadrware halbwegs performant geht ist on the fly rendern :) Ich hoffe Google verklagt mich jetzt nicht gleich aber hier hab ich mal den Google Tileserver in Verwendung: http://www.khtml.org/osm/v0.57/google.html (das ist illegal und ich werde es wieder entfernen) Das ist nicht vergleichbar, weil Du hier Sattelitenbilder und Luftbilder hast. Da gibt es _erhblich_ weniger Skalierungsartefakte. Wenn Du die Kartentiles von Google nimmst statt der Bilder sieht das sicher genauso besch** aus, weil eben Rasterbilder skaliert werden müssen. OpenLayers kenn nur Integer Zoom Level. Its not a bug, ... siehe oben :) Sven -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer) /me is gig...@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] Neue Slippy Map (khtmlib)
hi Ich versteh das gar nicht. Wird das definitiv in 3.7 gefixed oder muss man irgendwo für einen Bugreport voten? ;-) Das Voten ist heutzutage ganz einfach: chromium verwenden Ist ja nicht so, dass Linux irgendwie per se keine normalen Skalierungen unterstützen würde... Ich hab jetzt mit dem FF 3.7 alpha getestet. Da ändert sich leider nichts. In der Windows Version wird Direct 2D eingebaut was das zoomen von Bildern sehr verbessert. Die Linux Version ist da aber ein bisschen hinten. Es wäre natürlich möglich immer automatisch auf einen ganzzahligen Zoomwert zu kommen. Also so wie bei google oder bing maps. Ich werde einen Parameter einbauen der das ermöglicht. Das wäre vermutlich für einen Großteil der Benutzer der bevorzugte Weg, denn skalierte Pixelgrafiken sind halt immer nich ganz das gelbe vom Ei. Wäre die Frage, ob du dich hier als eierlegende Wollmichsau aufstellen willst und alle Anwendungsgebiete optimal abbilden möchtest oder ob du sagst, dir ist eine Alternative zu OpenLayers wichtig, die eben eine andere Zielgruppe hat. Ich denke mal smooth-zooming sollte sich auch in OpenLayers irgendwie einbauen lassen. Die Variante die immer auf einen ganzzahligen Zoomwert snappt ist mit openLayers sicher leicht machbar. Man müsste nur wärend der Zoomanimation die Vektor Daten ausblenden um eine flüssige Animation zu bekommen. Wenn jetzt also die Linux-Firefox-User nicht wirklich in deine Zielgruppe passen, weil die eher OpenLayers-Seiten anschauen solltest, dann musst du natürlich auch nicht einbauen was nur die wollen. :) Ich bin ja selbst Firefox Linux User. Es geht mir nicht darum OpenLayers zu verdrängen. Viel interessanter wäre es die User von Bing und Google zu gewinnen. lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.05.2010 14:43, schrieb Bernhard Zwischenbrugger: Jetzt hab ich mal den Sprung bei 0.5 gemacht: http://www.khtml.org/osm/v0.57.5/ Das Problem ist jetzt, dass die Schrift verdammt klein wird. Zudem muss der Browser viel mehr Kacheln laden und alles wird langsamer. Ich persönlich finde es so schöner. Für den Firefox mit Linux hilft das aber alles nichts, das ist ein anderes Problem. Ich meine, es hilft doch. Die verkleinerten Kacheln sehen jedenfalls besser aus als die vergrößerten. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2lJoACgkQnMz9fgzDSqeU2ACfbpcC4uj4z7GhL0BbREw92rvu BKYAoID6B5oQ0IDbQM5vyVvDRLcNPTA5 =SobZ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On 21.05.2010 13:35, Bernhard Zwischenbrugger wrote: Servus Frederik Kannst Du mal einen kurzen Sales Pitch fuer uns machen - warum sollte man Deine Library benutzen anstatt OpenLayers, was sind aus Deiner Sicht die Vorteile/Unterschiede - und wo hat OpenLayers Dir vielleicht noch Features voraus? Welche grundsaetzlichen Maengel bei OpenLayers haben Dich dazu bewogen, etwas eigenes zu machen? Die großen Unterschiede: o Zoom Speed o nicht integer Zoomlevel o Multitouch am iPhone/iPod Das sieht gut aus und fühlt sich auch gut an. Das mit dem integer-Zoom bei OL stimmt aber nicht, siehe: http://openlayers.org/dev/examples/fractional-zoom.html Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
On Fri, May 21, 2010 at 03:55:20PM +0200, Bernhard Zwischenbrugger wrote: Ich versteh das gar nicht. Wird das definitiv in 3.7 gefixed oder muss man irgendwo für einen Bugreport voten? ;-) Das Voten ist heutzutage ganz einfach: chromium verwenden Hm. Nein. :) Ist ja nicht so, dass Linux irgendwie per se keine normalen Skalierungen unterstützen würde... Ich hab jetzt mit dem FF 3.7 alpha getestet. Da ändert sich leider nichts. In der Windows Version wird Direct 2D eingebaut was das zoomen von Bildern sehr verbessert. Die Linux Version ist da aber ein bisschen hinten. Okay, Direct2D ist natürlich wenig Plattformübergreifend aber hat wohl keine direkte Konkurrenz als High-Level-2D-API. Andererseits sollte der verwendete Algorithmus ja auch locker in Software möglich sein, wir reden hier ja noch nichtmal von Gechwindigkeit. Mit freundlichen Grüßen, Bernd Wurst -- Bernd Wurst, Administration E-Mail/Jabber: be...@schokokeks.org schokokeks.org GbR, Bernd Wurst, Johannes Böck Köchersberg 25, 71540 Murrhardt http://schokokeks.org pgp4IOKpvRaX4.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Rasterbilder dieser Art mit wenig Details und wenig verscheidenen Farben. Typische Kartenkacheln halt will man eigentlich nicht skalieren da finde ich ehrlich gesagt die Idee das überhaupt zu tun broken. Als Überblend-Effekt finde ich das schon nett. Wenn die Leistung des Clients das hergibt, ist das einfach schöner als nur schöne die eingeblendete Kacheln auszutauschen. Aber das war's dann auch schon. Benutzen möchte man den Pixelmatsch nicht... -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo, Johann H. Addicks wrote: Aber das war's dann auch schon. Benutzen möchte man den Pixelmatsch nicht... Naja, ich kann mich (trotz Apple-Abstinenz) da schon reinversetzen. Wenn ich auf einer Europakarte den Zeigefinger auf Karlsruhe und den Daumen auf Muenchen lege und das beides nun scherenmaessig auseinanderschiebe, will ich ja, dass nach Ende der Bewegung immer noch der Zeigefinger auf Karlsruhe und der Daumen auf Muenchen ist - und solange man kein Force Feedback hat, um vom Geraet aus die Finger an die richtige Stelle zu schieben, muss man halt Zoomzwischenstufen benutzen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnmobil-Stellplätze bei OSM
Jan Tappenbeck schrieb: Am 19.05.2010 09:50, schrieb Martin Mainzer: Hallo, ich habe mich in den letzten Wochen mit den Wohnmobil-Stellplätzen in OSM (tourism=caravan_site) beschäftigt. Um diese Daten für Leute die mit Wohnmobilien unterwegs sind, nutzbar zu machen habe ich POI-Dateien für Navis und eine OpenLayer Karte für Europa mit den Stellplätzen erstellt (beides auf meiner User-Site: http://wiki.openstreetmap.org/wiki/User:Marmai). Bei der Arbeit mit den Daten ist mir aufgefallen, dass zwar schon eine Menge an Wohnmobilstellplätzen in Deutschland verzeichnet ist (560, Europa 1447), aber kaum weitergehende Informationen eingetragen sind. Ich denke, dass es insbesondere interessant wäre zu wissen, ob die Stellplätze kostenlos oder kostenpflichtig sind (fee=*) und ob Stromanschlüsse vorhanden sind (power_supply=*). Vielleicht können diese Informationen noch an der einen oder anderen Stelle ergänzt werden, und dadurch der Wert von OSM-Daten für Wohnmobil-Reisende deutlich erhöht werden. Viele Grüße, Martin Hi ! am besten Du erstellt ein Ticket [1] dafür und legst gleich ein Present [2] bei. Gruß Jan :-) [1] http://josm.openstreetmap.de/newticket [2] http://wiki.openstreetmap.org/wiki/DE:Anpassen_der_Vorlagen_von_JOSM Hallo Jan, ich habe nun ein Ticket erstellt, und ein 'preset' angelegt [1]. Da ich beides zum ersten Mal gemacht habe, wäre es super, wenn Du mal schauen könntest ob das so für die josm-Entwickler verständlich ist und ob im preset keine gravierenden Fehler stecken. Gruß, Martin [1] http://josm.openstreetmap.de/ticket/5056 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Am 21. Mai 2010 07:46 schrieb NopMap ekkeh...@gmx.de: Kurz gesagt: Die Küstenlinien werden ebenso schell wieder beschädigt wie sie repariert werden können und es ist mir in den letzten 3 Wochen nicht gelungen, zufällig ein Planetfile mit komplett intakten Küstenlinien zu erwischen. Ehrlich gesagt bin ich grade ziemlich ratlos - außer die Küstenlinie zu ignorieren und wieder auf händisch erzeugte Seepolygone zurückzugehen. Hat einer von Euch eine Idee, wie man das Problem in den Griff bekommen könnte? technisch fällt mir keine Lösung ein, aber man könnte auch versuchen, dem auf der comunity-Ebene beizukommen: - in den mapfeatures explizit einen Hinweis (ggf. noch prominenter) anbringen, wo coastlines _nicht_ eingesetzt werden sollen, und erklären, warum das sensibel ist - coastline aus den presets entfernen und in autocomplete nicht anbieten (dabei von der Prämisse ausgehen, dass a) die coastlines bereits irgendwie halbwegs drin sind, und daher das Tag äusserst selten an _neue_ Wege gesetzt werden muss b) das Editieren von coastlines irgendwie Profiaufgabe ist, wo man dann auch den Tag kennen wird c) das betrifft ja auch nicht diejenigen Edits, wo man bestehende Coastlines verfeinert und in der Position korrigiert) - hier (und ggf. im Forum und in den anderen Listen) eine Diskussion anstoßen/das Augenmerk darauf richten Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
Am 20. Mai 2010 14:37 schrieb Bodo Meissner o...@bodo-m.de: Am 18.05.2010 16:50, schrieb M∡rtin Koppenhoefer: OSM-Italien ist informell informiert worden, dass seit ein paar Tagen erkennbar versucht wurde, die Daten massenhaft systematisch herunterzuladen. [...] Eine übliche Nutzung z.B. mit JOSM über die WMS-Extension ist natürlich erlaubt bzw. sogar gewünscht. Kann man ausschließen, daß so etwas mit JOSM versehentlich passiert? Angenommen, ich stelle eine hohe Auflösung ein, öffne ein WMS-Layer und zoome später weit raus. Versucht JOSM dann, die ganze Fläche in der hohen Auflösung zu laden? Wenn ja, ergibt das auch einen systematischen Massendownload. Wir haben über das PCN keine weiteren Details zu der Sache bekommen, ganz ausschließen kann ich das also nicht, aber es scheint, als wäre der Verursacher schon gefunden. Jemand hat wohl versucht, die Tiles zu cachen für die Benutzung in potlatch. Vermutlich ist damit die Sache erstmal erledigt (er wird das nicht weiterverfolgen und Potlatch 2.0 soll ja WMS auch nativ einbinden können). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnmobil-Stellplätze bei OSM
Am 20. Mai 2010 14:28 schrieb Martin Mainzer mart...@gmx.de: das ist korrekt, ich habe der Einfachheit halber nicht alle tags verwendet, sondern nur diejenigen, die ich (subjektiv) für wichtig gehalten habe. Das sind: 'capacity', 'fee', 'power_supply' und 'tents'. Welche weiteren tags sind denn aus eurer Sicht noch wichtig und sollten auch noch aufgenommen werden? wie erwähnt wären m.E. Adressinformationen und Kontaktmöglichkeiten (tel, email, internetaddr.) sinnvoll, auch wenn gerade für letztere wohl kein Konsens besteht, dass sowas überhaupt eingetragen werden soll (wir sind ja kein Telefonbuch). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
da ich hier auch den Link zum PCN gepostet habe, ein kleiner Hinweis: Wie war denn das Betreff der Mail? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
2010/5/21 Johann H. Addicks addi...@gmx.net: da ich hier auch den Link zum PCN gepostet habe, ein kleiner Hinweis: Wie war denn das Betreff der Mail? das weiss nur noch das Archiv, vermutlich sowas wie Luftbilder Italien oder so. Hier nochmal ein Link auf die italienische Seite mit den JOSM-Links: http://wiki.openstreetmap.org/wiki/WikiProject_Italy/PCN Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hi! Am 21.05.2010 13:59, schrieb aighes [via GIS]: Hallo, leider mochte er Comopser meine preparierte Datei nicht. Hast du eine Ahnung, wass da falsch gelaufen sein könnte? Klar. Negative IDs sind ungültig. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Inkonsistente-Kustenlinien-tp5082833p5085367.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] Massendownloads vom PCN - portale geografico nazionale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.05.2010 18:49, schrieb M∡rtin Koppenhoefer: 2010/5/21 Johann H. Addicks addi...@gmx.net: Wie war denn das Betreff der Mail? das weiss nur noch das Archiv [...] Date: Wed, 5 May 2010 16:09:27 +0200 Message-ID: i2h7acdb3651005050709h6a80838av66f8461cd6953...@mail.gmail.com From: =?UTF-8?Q?M=E2=88=A1rtin_Koppenhoefer?= dieterdre...@gmail.com Subject: [Talk-de] 2 neue WMS in Italien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv22iIACgkQnMz9fgzDSqdsnwCgkXXXke5zqnyp53ZOnxCDNqsv RbAAn2pDdpMPz+porO/nQl/WFk2gCJJx =00jY -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falsche(?) hamlets
M∡rtin Koppenhoefer dieterdre...@gmail.com [Fri, May 21, 2010 at 02:10:03PM CEST]: Am 19. Mai 2010 16:11 schrieb René Falk li...@falconaerie.de: Die Gemeinde Bodolz daneben hat ebenfalls mehrere Ortsteile [2], doch sind manche nicht größer als ein Weiler. Wäre hier hamlet für alle Ortsteile die richtige Lösung? Hängt davon ab, wie es vor Ort ausschaut. Ist ein Ortsteil eher ein Dorf als ein Weiler, würde ich ihn auch als village taggen. Wenn der Ortsteil eher wie ein Weiler ausschaut, dann hamlet. +1, die manchen, die Weiler sind, als hamlet, und die die Dörfer sind als village. Genau, unabhängig davon, ob sie einer Stadt zugeordnet sind oder einer Samtgemeinde, einem Flecken oder sonstwas. Sag ich doch die ganze Zeit. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
Am 21.05.2010 21:08, schrieb Bodo Meissner: Wie war denn das Betreff der Mail? das weiss nur noch das Archiv Message-ID:i2h7acdb3651005050709h6a80838av66f8461cd6953...@mail.gmail.com Danke. Irgendwann werde ich mal einen Newsclient finden mit funktionsfähiger Volltext-Suche. (Nein, die vom Thunderbird3 ist broken...) -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM städtisch ausgelegt. Land braucht den cyclefootway
bkmap burkhard.kirch...@web.de writes: highway=path können sie ohnehin darstellen, auch wenn sie die Attribute noch nicht komplett auswerten. path ist im städtischen bereich völlig überflüssig und gegen den gesunden menschenverstand. Es macht die dinge nur unnötig kompliziert. Alle attribute kann man auch an die traditionellen highway-tags dranhängen (footway, cycleway, track). Also von mir ein klares NEIN zu cyclefootway oder ähnlichen Konstruktionen. Das hat ja auch niemand gefordert, jedenfalls niemand, der seine 7 sinne beisammen hat. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM städtisch ausgelegt. Land braucht den cyclefootway
Am 21.05.2010 22:33, schrieb Karl Eichwalder: Es macht die dinge nur unnötig kompliziert. Alle attribute kann man auch an die traditionellen highway-tags dranhängen (footway, cycleway, track). Bevor ich mir überlege, ob ich für einen gemeinsamen Rad- und Fußweg jetzt highway=footway bicycle=designated oder highway=cycleway foot=designated benutze hab ich den weg schon lange und äußerst unkompliziert mit highway=path foot=designated bicycle=designated getaggt. Aber darum ging es ja auch gar nicht. Es ging darum, dass bei solchen parallelen Möglichkeiten jeder das benutzen möge, was er bevorzugt, dabei aber doch bitte nicht ständig dafür wirbt, dass highway=path nur für Trampelpfade zu benutzen sei. Denn genau das stimmt nicht. Gruß: Martin Siegel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AKÜFI (was: AIO keine Adressen mehr )
so, jetzt will ich das große Rätsel mal auflösen: N.KIN ist die direkte Antwort auf die Frage: ist es Absicht, das die AIO vom 17.05 keinen Adresslayer mehr hat? und bedeutet Nein, Kann ich nicht. ich habe damit leider ungewollt bei euch die gleiche Verwirrung ausgelöst, die ich bei dieser Frage hatte. Was in der Welt ist AOI? in einem Nebenthread, der sich dann mit dem eigentlichen Problem beschäftigte, fiel dann irgendwann mal endlich der Begriff All in One und bei mir der Groschen - sorry Cent. ja, mir ist klar, dass es dann gleich heissen wird wenn Du das nicht kennst (AIO), kannst du sowieso nicht helfen und halte dich gefälligst raus da ich mir aber zumindest der ersten Beitrag eines Thread prinzipiell ansehe, auch wenn er mich nichts angeht, würde ich gerne eine chanche haben, zu lesen, worum es hier überhaupt geht. Durch diese Neugier habe ich schon einige Anwendungen/Verfahren/Webseiten/Geräte/... kennengelernt, die ich noch nicht kannte und prima gebrauchen konnte. Und manchmal konnte ich danach sogar wirklich helfen. gruß wambacher p.s. dass -v verify bedeuten sollte, hatte ich nicht geschnallt ;( - Der Fehler tritt nicht sporadisch sondern nur ab und zu auf. - aus Hotline-Eintrag -- View this message in context: http://gis.638310.n2.nabble.com/AIO-keine-Adressen-mehr-tp5066935p5086611.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] Rendering vom Ausland
Gerrit writes: Daher könnte man ja einfach den Tag name:de benutzen, was ich auch schon einige Male gemacht habe. Nicht nur könnte, sondern sollte. name=* ist der an dieser Stelle typische Name in der jeweiligen Landessprache. Das ist bis auf ganz wenige Ausnahmen eindeutig. In name:en käme der englische, name:de der deutsche, etc. Ein Renderer kann dann entscheiden welche Tags er verwendet. Beispielsweise lokale Bezeichnung und Englisch gleichzeitig. Wäre so etwas eventuell in Zukunft in Planung? Die Technik ist schon längst verfügbar. Es ist die Entscheidung der jeweiligen Anbieter der tiles was sie in welcher Art darstellen. Mein Server liefert unter anderem solche Daten, hier ein Beispiel für Thailand: http://img3.imageshack.us/img3/2798/thaienglishmixed.png Wie man das für Mapnik einstellen muss ist im Wiki beschrieben. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering vom Ausland - Schrift
Markus writes: Dem Renderer automatische Trankription/Transliteration beibringen zu wollen halte ich in den nächsten Jahrzehnten für erfolglos. warum? Ich rendere Thailand. Da hatte ich das über einen Zwischenschritt mal ausprobiert. Kein größeres Problem. Muss ja nicht live passieren. Mir fehlt noch ein wenig das passende Tool, aber prinzipiell möglich. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
