[Talk-de] OSM-Wochennotiz Nr.2
ein Versuch, wöchentlich aus dem OSM-Universum Projekte, Neuigkeiten und Diskussionen zusammenzutragen. http://www.openstreetmap.org/user/osm%20dortmund/diary/11378 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr.2
Am 01.08.2010 08:51, schrieb Gehling Marc: ein Versuch, wöchentlich aus dem OSM-Universum Projekte, Neuigkeiten und Diskussionen zusammenzutragen. http://www.openstreetmap.org/user/osm%20dortmund/diary/11378 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de finde ich gut - die zusammenstellung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am Samstag 31 Juli 2010 22:43:57 schrieb Jonas Stein: Ich wuerde mir automatischen Plaintext wuenschen. +1 Chris. -- Mein kleiner, persönlicher OSM-Duden: +1 - bin Deiner Meinung -1 - sehe ich nicht so AIO - http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Am 1. August 2010 01:26 schrieb Frederik Ramm frede...@remote.org: Hallo, Kolossos wrote: Hallo, weiß zufällig jemand, wie oft auf die Karte von openstreetmap.org im Monat zugegriffen wird oder kennt dazu eine Quelle? Ja, munin.openstreetmap.org! Da kannst Du immerhin rausfinden, wie viele Tiles abgerufen werden (so rund 1000 pro Sekunde im Schnitt glaub ich) und daraus Schluesse ziehen. Natuerlich braucht ein Map View immer ne ganze Menge Tiles. 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 Hallo, gibt es dazu auch irgendwo Erläuterungen? So ist das für einen Normalo, wie mich ziemlich krauses Zeug. -- Mit freundlichen Grüßen Klaus Diehl ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 31.07.2010 um 23:55 schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1, da es auch webclients gibt, die plaintext _leider_ nicht können. Wäre super und es gäbe keine Diskussionen darum mehr, weil man sich einfach nicht mehr darum kümmern muss. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 01.08.2010 um 00:08 schrieb Johann H. Addicks: Am 31.07.2010 23:55, schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1 +1 Und bitte Abfilterung von Beiträgen mit 70% Quoteanteil. -1 schwierig, auch wenn ich grundsätzlich Deiner Meinung bin. Manchmal muss man Zusammenhänge aus mehreren mails zusammenquoten, dass man auch mal auf Grundlage dieser quotes einen neuen Thread beginnen kann. Gut. Wer macht das schon... Aber wo zieht man die Grenze? 70%? . k.A. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 31.07.2010 22:43, schrieb Jonas Stein: Ich wuerde mir automatischen Plaintext wuenschen. +1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJMVTbzAAoJEPT/XJzV1tNza9oH+wZD42LsACssEpV4AXsF5FVI h7BirzAe9hFVFR8lHZmqO1Xl1ZzGT066wF1DXVh1jZlLyJ7qB99I/k2Y+nldx8ir fsPs6yYaweS359XZWsOTJGBrxQVcKXAOyPX2rpNbKWfkjftVDNRH8V3pk8dejT0H vtGFSjFEAXLL0kNSbEdFpuAWcOm2ThmxkhVBsyKdVjDvI1o0vS7vIxd6lr/SV22p UKtWLKtfAYByBWi1yi4VCQAdxNLLMewHCH2zqUa/H0v9ai6jWSf28rbArzrlStgh gWyn9RX9m+IyuNdTHjYLZ4voCroIn0QAF3Ous0gC5s5GyHXHc5PnOna4EVymPi8= =wjJ+ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am Sonntag 01 August 2010 10:27:07 schrieb steffterra: +1, da es auch webclients gibt, die plaintext _leider_ nicht können. ?? Steh' ich jetzt auf'm Schlauch oder hast Du Dich verschrieben? steffterra Chris.. -- Mein kleiner, persönlicher OSM-Duden: +1 - bin Deiner Meinung -1 - sehe ich nicht so AIO - http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Hallo, Klaus Diehl wrote: Ja, munin.openstreetmap.org! Da kannst Du immerhin rausfinden, wie viele Tiles abgerufen werden (so rund 1000 pro Sekunde im Schnitt glaub ich) und daraus Schluesse ziehen. Natuerlich braucht ein Map View immer ne ganze Menge Tiles. gibt es dazu auch irgendwo Erläuterungen? So ist das für einen Normalo, wie mich ziemlich krauses Zeug. Munin richtet sich nicht an Normalos, Erlaeuterungen gibt es nicht. Immerhin gibt es aber hier eine Liste mit Servern: http://wiki.openstreetmap.org/wiki/Servers Daran kannst Du sehen, dass die wichtigsten Rechner smaug (Datenbank, http://wiki.openstreetmap.org/wiki/Servers/smaug) und yevaud (Tileserver, http://wiki.openstreetmap.org/wiki/Servers/yevaud) sind. Welche von den Myriaden von Munin-Diagrammen jetzt ausssgekraeftig sind, das ist manchmal selbst fuer einen Sysadmin schwer zu beurteilen, geschweige denn fuer einen Normalo. Ich finde, fuer Smaug ist dieses Bild eine gute Gesamtaussage: http://munin.openstreetmap.org/openstreetmap/smaug.openstreetmap/cpu.html Da sieht man in der Jahres-Ansicht auch den Trend zu immer mehr iowait, d.h. der Rechner muss immer mehr auf Platten warten. Wenn man genau hinsieht, sieht man auch die kleinen orangefarbenen Spitzen, das ist die Herstellung des Planet Dump. Fuer Yevaud ist dieses Bild hier gut: http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/apache_accesses.html Das zeigt einfach die Anzahl der ausgelieferten Tiles pro Sekunde; man sieht an der Tages- und Wochenkurve gut, dass wir im Grunde ein europaeisches Projekt sind (daher wenig Zugriffe, wenn bei uns Nacht ist). Wenn wir mal wieder im Fernsehen oder im SPIEGEL kommen, gibt es in der Regel auch sichtbare Spitzen. Wer sich fuer die Arbeit hinter den Kulissen interessiert, der sieht hier http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/renderd_processed.html wie viele Tiles tatsaechlich neu gerendert werden. Um auf Tims urspruengliche Frage zurueckzukommen; ein einfacher Besuch von www.openstreetmap.org ruft je nach Bildschirmgroesse so ca. 75 Tiles ab. Wenn man dann noch ein bisschen nach links und rechts guckt oder reinzoomt, hat man schnell 250 Tiles zusammen. Nehmen wir mal an, 250 Tiles waere ein durchschnittlicher Besuch. Aus den Munin-Grafiken geht hervor, dass wir am Tag rund 70 Millionen Tiles ausliefern, das heisst, wir haetten dann rund 275.000 Besucher am Tag. (Diejenigen, die oefter wiederkommen, sind da vermutlich nicht so gut mitgezaehlt, da sie oft die Tiles im Browser gecached haben). Die Frage, ob eine Million Besucher mehr oder weniger stark ins Gewicht fallen, wuerde ich also so beantworten: Wenn sie sich auf ein paar Wochen verteilen, wird man sie nicht bemerken, wenn sie aber an einem Tag kommen, dann schon ;) 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] Konzept für die Gruppierung von ways (ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 31.07.2010 um 21:39 schrieb Tobias Knerr: Am 27.07.2010 17:56, schrieb steffterra: Am 27.07.2010 um 15:09 schrieb Tobias Knerr: Daher eine prinzipielle Frage: Repräsentiert ein Way in deinem Modell * eine Fahrtrichtung oder * eine Fahrspur bzw. Gruppe von Fahrspuren Das Modell kann beides. Diese Eigenschaft macht es m.E. etwas verwirrend. Ein zusätzlicher Way repräsentiert eine Fahrspur wäre beispielsweise deutlich einfacher zu erklären (und im Editor darzustellen) als ein kommt darauf an. Aus dem Zusammenhang heraus gesehen stimme ich Dir zu. Doch wenn man es aus sicht des Bedarf siehst: Wenn man richtungsabhängige Tags nicht nötig wären auf _einem_ way, wozu dann Fahrspuren für jede Richtung erstellen? Einfache Logik, oder? Ebenso grundsätzlich zur Fahrspur. Wenn die Fahrspuren sich nicht unterscheiden, wozu diese dann zeichnen, wenn ein lanes=2 es auch tun würde? Auch einfache Logik, oder? Diese Beurteilung meinerseits liegt natürlich auch daran, dass ich bekanntlich :forward/:backward nicht als echtes Problem sehe, so dass die Fahrspurdarstellung aus meiner Sicht der einzige gute Grund für die Einführung eines Linienbündel-Modells ist. ;) Sehr gute Selbsteinschätzung :-) Beispiel 1: in der Wirklichkeit sieht unsere Beispielstraße so aus: ganz normale Straße mit zwei Fahrspuren (pro Richtung eine Fahrspur) ohne Unterschiede, egal aus welcher Richtung man kommt. Geschwindigkeitsbegrenzung: 50km/h. [...] Beispiel 2: die gleiche Straße bekommt eine Geschwindigkeitsbeschränkung von 60 km/hverpasst, die nur in einer Richtung (z.B. in Richtung Süden) gilt. Eingezeichnet ist der way in JOSM von Nord nach Süd. Ausserdem werden Schilder für die Fahrrichtung aufgestellt, da es eine neuralgische Verbindugnsstraße wird. Die Süd-Nord-Richtung führt nach Hamburg, die Nord-Süd-Richtung nach München und ist auch so ausgeschildert (Es ist ein Beispiel ;-) [...] -way (Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (Süd-Nord): maxspeed=50, destination=Hamburg Beispiel 2a: Dasselbe, aber die Straße hat keine getrennten Fahrspuren - ist also einspurig. Wird das dennoch mit zwei Zusatzways dargestellt? Wie jetzt - eine Spur? Dann muss es ja eine Einbahnstraße sein, oder meinst Du jetzt einen Feldweg? Ich bitte doch davon abzusehen, richtungsabhängige Tags an Feldwegen zu plazieren. Scherz beiseite. Aus Spaß wurde Ernst: Welche Straßentypen meist du - Wo hat man denn nur eine Fahrspur, auf der es Gegenverkehr gibt, die gleichzeitig richtungsabhängige Tags benötigt? Welche richtungsabhängigen Tags wären dass beispielsweise? Bitte beachte, dass nicht jede Straße, die _keine_ Mitellinien-Strichelchen besitzt automatisch einspurig ist. Darauf können selbstverständlich 2 Fahrzeuge, die sich entgegenkommen nebeneinander fahren, ohne dass einer davon zur Hälfte in den Graben ausweichen muss. Und selbst wenn so eine Straße dann von einem Radweg auf einer Seite begleitet wird, dann ist dieser baulich getrennt, weil sonst dies immer als Ausweichmöglichkeit bei Gegenverkehr genutzt würde Ich bin gespannt auf Dein Beispiel. Beispiel 3: die gleiche Straße wird um eine Fahrspur in Richtung Norden-Süden erweitert, auf der anderen Seite jedoch nicht [...] Beispiel 4: die gleiche Straße bekommt auf der äußersten Fahrspur der Richtung Nord-Süd zusätzlich zur Fahrspur aus Beispiel 3 noch einen Radweg verpasst, weil diese Straßenseite so gefährlich wurde. [...] - in meinem Modell: -way (außen eingezeichnet Nord-Süd): maxspeed=60, destination=München, cycleway=lane, bicycle=designated -way (innen eingezeichnet Nord-Süd): maxspeed=60, destination=München -daten-way: highway=secondary, name=Beispielstraße -way (Süd-Nord): maxspeed=50 Beispiel 4a: Nehmen wir weiter an, die äußere Fahrspur Nord-Süd ist 3m breit, der Radweg daneben 1,5m. Außerdem möchte ich die Oberfläche des Radwegs per surface/smoothness-Tags beschreiben. Wie werden diese diese Informationen ergänzt? So, wie man es an _einem_ way auch machen würde. Nur dass Du das _jedesmal_ dann nötige :forward weglassen kannst, weil ja schon klar ist, auf welchem Richtungsway Du das taggst. Beispiel 4b: Nehmen wir an, es gibt einen Parkstreifen zwischen dem Radweg und der Fahrbahn. Wie sieht die entsprechende Ergänzung aus? Du meinst nicht Fahrbahn, sondern Fahrspur. Denn die Fahrbahn ist das ganze, sofern keine bauliche Trennung zwischen der Radfahrspur, dem Parkstreifen oder ähnlichem vorliegt. Also kommt es darauf an, ob eine bauliche Trennung (z.b. durch Bäume zwischen den Parkständen) vorliegt oder nicht. _Wenn bauliche Trennung_ , ist es klar, wie bisher auch: dann hat der Radweg eine eigenen way verdient und dessen tags dran, parking:lane an den Richtungsway. Doch dann darf der Radweg nicht mit in die Gruppe, da er ja durch die bauliche Trennung kein Teil der Fahrbahn mehr ist. Beispiel 4c: Anders als
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am 31.07.2010 um 21:14 schrieb steffterra: Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. Ich muss mich selbst korrigieren: Natürlich ist es quatsch, durch den Editor noch forward/backward am Richtungsway zu taggen. Da hast Du mcih jetzt echt aufs Glatteis geführt. Nochmal zum Versatändnis: du schlägst einerseits vor, dass der Editor per popup-Fenster und Pfeil zum betroffenen way, an dem man das Tagging durchführt einfach die Keys einträgt, die für diesen richtugnsway gelten. Das geht aber auch so wie jetzt auch, da ja an so einem Richtugsway _keine_ richtungsabhängigen Tags nötig sind! Wenn Du Dein vorgehen an normalen ways machen möchtest, ist es dem Editor eben nicht möglich selbst zu entscheiden, was der user gerade eingibt, da eben nciht klar ist, wie er forward/backward/left/right vergeben soll, da es ja nur ein way ist. Bei senkrechten und waagrechten ways könnte man diese automatische Vergabe der richtungsanhängigen Tags noch ermöglichen, doch bei ways, die in 45° Winkel verlaufen, weiss der Renderer nicht von was Du ausgehst. Ist links jetzt die westliche Fahrbahnteil gemeint, oder der nördlich gelegene? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 01.08.2010 um 10:59 schrieb Christian Knorr: Am Sonntag 01 August 2010 10:27:07 schrieb steffterra: +1, da es auch webclients gibt, die plaintext _leider_ nicht können. ?? Steh' ich jetzt auf'm Schlauch oder hast Du Dich verschrieben? hmm, nochmal: +1 für den automatischen plain-text durch _den Verteiler_, da es web-mail-clients gibt, bei denen man eben _kein_ plain-text einstellen kann und die immer html verschicken. Dann wandelt der mailingliste-Verteiler-Server diese html-mails automatisch in plain-text um, und alle sind glücklich. Alles klar? steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr.2
Am 01.08.2010 um 09:37 schrieb Stefan Sandrock: Am 01.08.2010 08:51, schrieb Gehling Marc: ein Versuch, wöchentlich aus dem OSM-Universum Projekte, Neuigkeiten und Diskussionen zusammenzutragen. http://www.openstreetmap.org/user/osm%20dortmund/diary/11378 finde ich gut - die zusammenstellung. Super Engagement! Danke - nicht aufhören!!! :-) Vorschlag: Große laufende Diskussionen, an denen man sich vlt. beteiligen möchte, könnten ebenso Berücksichtigung finden. (Ich denke an nichts spezielles, sehe nur keine aufgenommen) steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr.2 - Toter Teillink
Am 01.08.2010 08:51, schrieb Gehling Marc: ein Versuch, wöchentlich aus dem OSM-Universum Projekte, Neuigkeiten und Diskussionen zusammenzutragen. http://www.openstreetmap.org/user/osm%20dortmund/diary/11378 http://www.openstreetmap.org/user/osm dortmund/diary/11378 ___ Dortmund mailing list dortm...@lists.openstreetmap.de http://lists.openstreetmap.de/mailman/listinfo/dortmund Hi ! der Link zur Veröffentlichung der Geofabrik ist bei mir tot ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landsat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 01.08.2010 01:09, schrieb Rolf Meyerhof: Hallo Bodo Landsat ist bei mir seit einigen Tagen weg. Ich hatte gehofft dass es sich wieder gibt. Es gibt aber mails auf osm-Talk die leider nicht richtig deuten kann. Siehe diese mail. yeah, I'm having the same issues (Read timed out) Roman From: Tomas Straupis tomasstrau...@gmail.com Subject: [OSM-talk] Landsat? Hello Is anybody else experiencing landsat problems in JOSM? For about three days now landsat images are not available to JOSM. http://onearth.jpl.nasa.gov/ says something about evil ?repetitive requests for non-cached, small WMS tiles?. Does that mean no more landsat in JOSM? Es könnte sein, daß die normalen WMS-Zugriffe wegen Server-Überlastung derzeit wieder gesperrt sind. Den Hinweis auf http://onearth.jpl.nasa.gov/ gibt es schon mindestens seit Sommer 2008. Damals hatte ich für das alte WMS-Plugin eine Erweiterung (siehe http://wiki.openstreetmap.org/wiki/User:Bomm#JOSM-WMS-Plugin_-_Tiled_WMS) implementiert. Scheinbar wäre das auch für das derzeitige WMS-Plugin sinnvoll, ich kann aber nichts versprechen. Wenn jemand Interesse und Zeit hat, das zu übernehmen, bitte melden. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxVQVYACgkQnMz9fgzDSqdDIACdHG0NrVL1aL30qBM8bG0b9TgO ungAnjwRJbTikW1qs6OCIld5wpFZfzG4 =VUzK -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 01.08.2010 11:26, schrieb steffterra: +1 für den automatischen plain-text durch _den Verteiler_, da es web-mail-clients gibt, bei denen man eben _kein_ plain-text einstellen kann und die immer html verschicken. Dann wandelt der mailingliste-Verteiler-Server diese html-mails automatisch in plain-text um, und alle sind glücklich. +1 Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxVQrIACgkQnMz9fgzDSqfm5wCfY+XU3Bm8fgppdxeNq6P5s2eD bWgAn17YI8bqsQMfF+oClbBL4NCVoD4x =C1sR -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr.2 - Toter Teillink
jan99 wrote: Hi ! der Link zur Veröffentlichung der Geofabrik ist bei mir tot ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Da sind wohl zwei Links zusammengeraten, probier sie mal einzel: http://www.geofabrik.de/data/wms.html http://blog.geofabrik.de/en/?p=50 -- View this message in context: http://gis.638310.n2.nabble.com/OSM-Wochennotiz-Nr-2-tp5360425p5360627.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] Umfrage: html-Mails und Anhang in Mailingliste
Am Sonntag 01 August 2010 11:26:21 schrieb steffterra: da es web-mail-clients gibt, bei denen man eben _kein_ plain-text einstellen kann und die immer html verschicken. Alles klar? Jetzt ja, ich wusste nicht dass es Clients gibt die kein Plaintext verschicken können sonder nur html. steffterra Chris -- Mein kleiner, persönlicher OSM-Duden: +1 - bin Deiner Meinung -1 - sehe ich nicht so AIO - http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Ja, die 1000 Tiles/sec in der Spitze decken sich mit: http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/index.html#mod_tile Nimmt man mal für einen normalen Benutzer, der ein bißchen rumzoomt, durchschnittlich 50 Tiles an, käme man also auf (1000/50 * 75% [Verteilung über den Tag] * 3600 * 24 * 30 = 3.888.000) knapp 4 Mio. Besucher pro Monat. Ok, das reicht mir erstmal. Grüße Kolossos Frederik Ramm schrieb: Hallo, Kolossos wrote: Hallo, weiß zufällig jemand, wie oft auf die Karte von openstreetmap.org im Monat zugegriffen wird oder kennt dazu eine Quelle? Ja, munin.openstreetmap.org! Da kannst Du immerhin rausfinden, wie viele Tiles abgerufen werden (so rund 1000 pro Sekunde im Schnitt glaub ich) und daraus Schluesse ziehen. Natuerlich braucht ein Map View immer ne ganze Menge Tiles. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Tim Alder wrote: Nimmt man mal für einen normalen Benutzer, der ein bißchen rumzoomt, durchschnittlich 50 Tiles an, käme man also auf (1000/50 * 75% [Verteilung über den Tag] * 3600 * 24 * 30 = 3.888.000) knapp 4 Mio. Besucher pro Monat. wie kommst du denn auf einmal auf 50 tiles pro durchschnittlichen besuch? frederik sprach von 75-250. willst du die besucherzahl pushen? mfg walter - if it's there and you can see it, it's REAL if it's there and you can't see it, it's TRANSPARENT if it's not there and you can see it, it's VIRTUAL if it's not there and you can't see it, it's GONE Roy Wilks, 1983 -- View this message in context: http://gis.638310.n2.nabble.com/Zugriffszahlen-auf-openstreetmap-org-tp5359549p5360689.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] Landsat
Am 01.08.2010 11:46, schrieb Bodo Meißner: Es könnte sein, daß die normalen WMS-Zugriffe wegen Server-Überlastung derzeit wieder gesperrt sind. Den Hinweis auf http://onearth.jpl.nasa.gov/ gibt es schon mindestens seit Sommer 2008. Damals hatte ich für das alte WMS-Plugin eine Erweiterung (siehe http://wiki.openstreetmap.org/wiki/User:Bomm#JOSM-WMS-Plugin_-_Tiled_WMS) implementiert. Scheinbar wäre das auch für das derzeitige WMS-Plugin sinnvoll, ich kann aber nichts versprechen. Wenn jemand Interesse und Zeit hat, das zu übernehmen, bitte melden. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxVQVYACgkQnMz9fgzDSqdDIACdHG0NrVL1aL30qBM8bG0b9TgO ungAnjwRJbTikW1qs6OCIld5wpFZfzG4 =VUzK -END PGP SIGNATURE- Hallo Bodo Danke für die Info. Ich lese dass es ein generelles Problem ist. Es gilt also abzuwarten bis sich einer mit diesem Problem beschäftigt. Mit freundlichen Grüßen Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
Florian Gross usenet-spam-genausoguel...@grossing.de wrote: type = multipolygon admin_level = 9 boundary = administrative de:amtlicher_gemeindeschluessel = x Ist die Gemeinde nicht admin_level=8 und die einzelnen Teilorte admin_level=9 ? Genau! Aber hier handelt es sich um Gemarkungen, die in den meisten Fällen die heutigen Ortsteile darstellen oder sich zu solchen zusammen fassen lassen. Siehe mein Originalposting: |Für das nordwestliche |Niedersachsen liegen die amtlichen Grenzen aller Kommunen und deren |Ortsteile in Form der sogenannten Gemarkungen mit einer Genauigkeit |von 5 Metern vor. Daraus werden dann die übergeordneten Grenzen von Hand erstellt. Originalposting: |Aus diesem Konstukt kann ich dann mit Ortskenntnissen und in |Handarbeit die Ortsteile-, Kommunen- und Landkreisgrenzen sowie die |Außengrenze des Importes in die niedersächsische Außengrenze und die |Grenzen der Anrainer des Importgebietes einbauen. Viele Gemarkungen |sind heute keine administrative Einheit mehr. In der Mehrheit der Fälle ist aber für die Gemarkung admin_level = 9 die richtige Wahl. Zu überlegen wäre, ob man die zu kleinen und nicht mehr administrativen Gemarkungen mit den bisher nicht existierenden admin_level = 10 taggt. Die Namen sind im täglichen Sprachgebrauch und auf Ortseingangs- bzw Ortsunterrichtungsschildern für geografisch eindeutig abgegrenzte Dörfer präsent und waren bis 1972 eigenständige Gemeinden oder Ortsteile. admin_level = 11 könnten dann (bei Bing Maps werden sie auch gezeigt) die historischen Gehöfte oder Klöster sein, sofern sie noch existieren. In meiner Gemeinde sind nahezu alle noch erhalten und zumeist bewirtschaftet, da hier die flächige Erschließung und Besiedelung erst vor gut 200 Jahren begann: http://de.wikipedia.org/wiki/Urbarmachungsedikt Möglicherweise überlegt man sich auch andere Bezeichnungen für ehemalige Administrationen. Ich fände es übrigens schade, wenn im Rahmen zukünftiger amtlicher Flurbereinigungen diese Gemarkungen aufgelöst und folglich in OSM gelöscht würden und damit verloren gingen. Wir speichern derzeit keine historischen Daten. Mir gibt es aber zu denken, dass es hier administrativ nicht geführte Dörfer gibt, die aber fremdenverkehrlich so bedeutsam sind, dass sie schon an der Abfahrt auf der fernen Autobahn ausgeschildert sind. Die Grenzen dieser Dörfer konnte ich weder bei den Gemeinden noch beim Katasteramt auftun. Insofern fände ich es erstrebenswert, die jetzt noch existierenden wenigstens bei OSM mit durchaus dokumentarischem Wert zu konservieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am Sonntag 01 August 2010, 10:27:07 schrieb steffterra: Am 31.07.2010 um 23:55 schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1, da es auch webclients gibt, die plaintext _leider_ nicht können. dann wuerde ich mich da mal direkt beschweren. schliesslich gibt es einen Emailstandard. Aber zumindest web.de macht's einem da echt schwer, wenn mal kein zahlender Nutzer ist... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 01 August 2010, 10:22:14 schrieb steffterra: Wer baut die grafische Tagging-Funktion in JOSM und Potlatch? (hier sind doch ein paar Entwickler unterwegs, oder?) Nicht dass für die Gruppierung keine Entwickler nötig wären... ;-) Beim Konzept kann ich durchaus behilflich sein, aber von Java und Flash halt ich mich fern. Ich hatte eher gehofft, falls das noch jemand ausser Dir mitliest gleich mal hier schreit ;-) Naja so ähnlich halt. Oder jemand kennt halt die Namen. Entwicklerkapazitaet ist bei OSM leider ein rares Gut. Wenn jemand nicht wirklich von einem neuen Konzept ueberzeugt wird, passiert da erst mal nicht viel - ausser man macht es selbst... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 01 August 2010, 11:22:38 schrieb steffterra: Am 31.07.2010 um 21:14 schrieb steffterra: Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Eingabefelder fuer die eigentlichen Tags zeigt man am besten gar nicht mehr an. Durch die Eingabe der Daten in einem aufpoppenden Fenster mit Pfeil auf den way, den es betrifft hätte man es einfach visualisert, an welchem way man soeben taggt. Das wäre die beste Lösung, stimmt! Super Vorschlag, wie ich finde. forward/backward/left/right könnte der intelligente Editor so wirklich automatisch vergeben. Ich muss mich selbst korrigieren: Natürlich ist es quatsch, durch den Editor noch forward/backward am Richtungsway zu taggen. Da hast Du mcih jetzt echt aufs Glatteis geführt. Nochmal zum Versatändnis: du schlägst einerseits vor, dass der Editor per popup-Fenster und Pfeil zum betroffenen way, an dem man das Tagging durchführt einfach die Keys einträgt, die für diesen richtugnsway gelten. Das geht aber auch so wie jetzt auch, da ja an so einem Richtugsway _keine_ richtungsabhängigen Tags nötig sind! das Popup kam von dir ;-) konkret muss man schauen, was die beste Methode ist, das darzustellen. Ich gehe einen Schritt weiter. Ich will nicht, dass der User (ausser er arbeitet in einem speziellen Expertmode) ueberhaupt mit Tags zu tun hat. Wenn Du Dein vorgehen an normalen ways machen möchtest, ist es dem Editor eben nicht möglich selbst zu entscheiden, was der user gerade eingibt, da eben nciht klar ist, wie er forward/backward/left/right vergeben soll, da es ja nur ein way ist. das wuerde ganz genau so funktionieren, denn auch ein way hat eine Richtung. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Hallo, meine Antwort begann ich zu schreiben, bevor die 2. Antwort von Frederik bei mir ankam, daher die verschiedenen Schätzungen. Auf meinen kleinen Laptop-Bildschirm (15 Zoll) passen 5 Kacheln in der Breite und 3 Kacheln in der Höhe auf den Bildschirm, also sieht man erstmal nur 15 Kacheln, da fand ich meine Schätzung mit 50 Kacheln schon ganzschön hoch. Ich habe aber jetzt auch gesehen, dass durch den größeren Bereich der heruntergeladen wird, gleich viel mehr Kacheln kommen. Meine Million Besucher bezog sich auf einen Monat und erscheint nun doch eine relevante Größenordnung. Hintergrund ist, dass solche Besucherzahlen ggf. aus eine Wikipedia-Anwendung[1] entstehen könnten, welche Wikipedia-Objekte auf einer OSM-Karte zeigt und wenn man die Anwendung direkt neben der Koordinate im Wikipedia-Artikel verlinken würde. (Momentan gibt es nur ein OSM-Gadget für angemeldete Nutzer.) Dabei gilt ja wohl, dass ein Tile-Cache ja umso effizienter arbeitet, je mehr Besucher darauf zugreifen und dass das Ausliefern von Tiles billiger ist und schneller geht als das Neu-Rendern. Das ganze würde aber nur funktionieren, wenn die Mehrbelastung der OSM-Server aber insgesamt vernachlässigbar wäre bzw. es massig freie Kapazitäten geben würde. So müssen wir aber wohl auf die vom Toolserver gerenderten Tiles umstellen. m.f.G. Kolossos [1] http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?zoom=13lat=45.208330230278lon=16.373063840833lang=de Walter Nordmann schrieb: Tim Alder wrote: Nimmt man mal für einen normalen Benutzer, der ein bißchen rumzoomt, durchschnittlich 50 Tiles an, käme man also auf (1000/50 * 75% [Verteilung über den Tag] * 3600 * 24 * 30 = 3.888.000) knapp 4 Mio. Besucher pro Monat. wie kommst du denn auf einmal auf 50 tiles pro durchschnittlichen besuch? frederik sprach von 75-250. willst du die besucherzahl pushen? mfg walter - if it's there and you can see it, it's REAL if it's there and you can't see it, it's TRANSPARENT if it's not there and you can see it, it's VIRTUAL if it's not there and you can't see it, it's GONE Roy Wilks, 1983 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
Moin, bundesrainer schrieb: Eine Unterscheidung zwischen Grünfläche (Wiese,Weide) und Ackerfläche fände ich wichtig. Diese Arten sind zumindest ganzjährig zu unterscheiden. Unterschiedliche Tags für Wiesen und Weiden finde ich etwas problematisch: +1, ich kann mich der Argumentation aus eigenem Erleben nur anschließen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
Jan Tappenbeck o...@tappenbeck.net wrote: shape-dateien konnte doch tobias.wendorff ins osm-format konvertieren. Konvertiert sind sie schon. siehe Originalposting: |Sven Geggus hat das amtsübliche Shapeformat |inzwischen in das *.osm Format umgesetzt. Soweit sich das mit der |OSM-typischen GPS-Genauigkeit überprüfen lässt, ist diese Umsetzung |hochgenau gelungen. Dafür erst einmal einen recht herzlichen Dank |an Sven. reicht das nicht ! Es wäre schön, wenn es mir für über 350 Gemarkungsgrenzen erspart bleiben könnte, diese von Hand an jedem Schnittpunkt (einige Tausend) aufzuteilen, die so erstellten tausenden Teilways in jeweils zwei Relationen aufzunehmen und die Taggings von den ursprünglichen Wegen in die Relationen zu übernehmen, sowie die doppelten Wege zu eleminieren. Es ist auch ein Übersichtsproblem, insbesondere weil in der JOSM Darstellung die Teilung von Wegen und die Elemination doppelter Wege nur durch Ansehen nicht festgestellt werden kann. Man muss hierfür jeden Punkt bzw way explizit besuchen. Bei Tausenden von Wegen und Verbindungspunkten kann man kaum nachhalten, ob man schon alle besucht hat. Wegen des hohen Detaillierungsgrades muss man auch sehr nahe an jeden dieser tausenden Punkte heranzoomen, um den richtigen Verbindungspunkt zu sehen. Da aber diese Punkte locker kilometerweit entfernt sind, artet das Ganze in ein ziemliches Raus- und Reingezoome aus. Und dabei muss man noch die Übersicht wahren, ob man schon alle tausende Punkte ausfindig gemacht und besucht hat - ein schwieriges Unterfangen. Ich stelle mir gerade vor, dies später für ganz Niedersachsen zu machen. Da dürfte die Zahl der zu bearbeitenden Wege und Punkte ins Fünf- bis Sechsstellige gehen. 8-/ Da das im OP beschriebene Problem bei Importen aus (amtsüblichen) Shapedateien immer wieder auftritt, wäre es auch von dorther interessant, für die Zukunft eine zumindest teilautomatisierte Lösung zu haben. Mit dieser wäre man auch einem *.osm Ausgang für ein Geokonvertierungsprogramm z.B. GDAL ein Stück näher, sofern ich das als Laie richtig verstanden habe. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: deckungsgleiche gegengerichtete Wege gezielt zugreifen
malenki o...@malenki.ch wrote: http://wiki.openstreetmap.org/wiki/JOSM/Advanced_Tricks Der erste Punkt sollte dir helfen. Nicht vergessen, dabei die Ctrl-Taste zu nutzen. Sehr schön! :-) So ein Tagging Info per Mausdrüberhalten ist in JOSM wirklich hilfreich. Könnte als reines Info ohne Auswahlfunktionalität auch durch einem Button ein- und ausgeschaltet werden. Wenn dann auch noch die beteiligten Relationen des Weges angezeigt würden, wäre es perfekt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
moin, Am 01.08.2010 14:57, schrieb Georg Feddern: Unterschiedliche Tags für Wiesen und Weiden finde ich etwas problematisch: +1, ich kann mich der Argumentation aus eigenem Erleben nur anschließen. Gruß Georg man kann Wiese/Weide schon auseinanderhalten (Zaun), aber Weiden werden selten, weil zumindest die Rinder eigentlich ganzjährig im Stall stehen. VG Jörk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
Wenn ich dies http://www.wheregroup.com/de/system/files/2009-05-19_Schmitz_BeTA2007.pdf als Laie richtig interpretiere, kommt es bei der shp2osm Umsetzung zu Fehlern in der Größenordnung von bis zu zwei Metern. Diese Abweichung kann durch die Anwendung der amtlichen Korrekturdatei BETA2007 auf wenige Zentimeter reduziert werden. In Anbetracht dessen, dass die hier in Frage stehenden Grenzen Abweichungen von bis zu fünf Metern aufweisen, ist es vielleicht nicht ganz so wichtig. Dennoch rein interessehalber und ohne Kenntnis der Einzelheiten gefragt: Frederik Ramm frede...@remote.org wrote: [...] Ist bei diesem Verfahren auch die Nutzung von BETA2007 integriert, die Sven bei seiner shp2osm Umsetzung angewendet hat? Zitat aus seinem Fossgis Vortrag: |Hohe Positionsgenauigkeit durch Verwendung von amtlicher |Korrekturdatei BETA2007 erreichbar http://www.fossgis.de/konferenz/2010/attachments/71_osm-datenaufbereitung-fossgis-2010.pdf Ist nur eine Frage - keine Kritik. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways b ei =?iso-8859-1?q?_forward/backward?=)
Am 01.08.2010 um 14:37 schrieb Guenther Meyer d@sordidmusic.com: das Popup kam von dir ;-) Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Was meinst Du dann mit graphischer Eingabe? Ich dachte Du meinst ein Eingabefenster, das an der Graphik zeigt, wo die tags angegeben werden. Mein Fehler, vergessen wir das ganze. Wie sollte Deiner Meinung nach eine graphische Eingabe aussehen??? konkret muss man schauen, was die beste Methode ist, das darzustellen. Ich gehe einen Schritt weiter. Ich will nicht, dass der User (ausser er arbeitet in einem speziellen Expertmode) ueberhaupt mit Tags zu tun hat. Damit stellst Du aber alles in Frage und schlägst ein System wie Potlatch oder Mapzen vor, bei denen Du nur Checkboxen, die die Tags tepräsentieren, anhakst, um die Eifenschaften eines ways abzubilden. Wie willst Du nun richtungsabhängige Informationen mithilfe dieser Art der Eingabe realisieren? Wenn Du Dein vorgehen an normalen ways machen möchtest, ist es dem Editor eben nicht möglich selbst zu entscheiden, was der user gerade eing ibt, da eben nciht klar ist, wie er forward/backward/left/right vergeben soll, da es ja nur ein way ist. das wuerde ganz genau so funktionieren, denn auch ein way hat eine Richtung. Diese Richtung des ways ist aber nicht definiert, noch weiss man, ob er beim Vorhandensein von richtungsabhängigen Tags noch in die richtige Richtung zeigt. Das ist ja das Motiv für eigene ways für richtungsabhängige Eigenschaften! Außerdem sind wir schon wieder bei der Diskussion, dass man eben nicht automatisiert dem Editor (dem Programm) überlassen kann, welche Richtung der user nun meinte. Der Editor kennt zwar die Richtung des eingezeichneten Way, aber nicht automatisch, was der user in welcher Richtung hinraggen möchte. Das erfährt der Editor vom user und da passieren die Fehler. Um da Fehler erkennen zu können, müsste der Edtor das aber validieren können, dazu fehlt ihm aber die Information, weil er sich auf den User verlassen muss. Verstehst Du? Auch ein graphischer Editor kann das nicht leisten, außer der User sagt ihm von welchem Node zu welchem Node das gelten soll. Und auch da darf der user nicht die nodes andersherum anklicken, sonst ist es die Gegenrichtung. Es bleibt also dabei: es hängt am User. Und diese menschliche Fehlerquelle kann man IMHO nur durch einen eigenen way minimieren. steffterra___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 01.08.2010 15:41, schrieb Jörk: man kann Wiese/Weide schon auseinanderhalten (Zaun), aber Weiden werden selten, weil zumindest die Rinder eigentlich ganzjährig im Stall stehen. Ein Zaun ist nicht unbedingt ein sicheres Unterscheidungsmerkmal: Ein fester Zaun umgibt auch schon mal Wiesen. Ebenso lassen fehlende Zäune nicht unbedingt auf eine Wiese schließen, da sie abseits der Saison auch abgebaut werden. Die Unterscheidung ist (wegen der fließenden Grenzen) nicht einfach und für die meisten Nutzer auch unerheblich. Beste Grüße, Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJMVYNBAAoJEPT/XJzV1tNzemwIAIbr9LnAR7Iap65mBonSqGT3 QBkm5SX3tkAM/hY3JGl7o/W98zUzulu5YPmfLAvayyyWPY59XrIQJsxab4XSw/wl JCydRUoShFNuFZgvSIcYH+CqT/hmDeB2XMH18d7abGWHxmo8GwHiDEHXrBoQrIMm zBenzHBr+5IU5Q2rbEi5lhZMoEs2j4B6lSJvUyuTAf1Q9M7eKf6JMUNWlCjdf/PD Vg7eqjZX9Fwy3aPtJXcUrdaZ5TAkt3ol+XsMjquT/4+4UX953GPWzuN/kCCE1Xj4 PRK3QuKgiZe76cIknzJBjo0Z6gYAevP4n6wBJqG7KYSlE32IpuSIxd7ZBz3XEMQ= =F6yL -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Flächen und Ways
Hi ! wenn man flächendefiniert dann bin ich der Auffassung das diese bis dicht an die Ways gezogen werden sollen - wenn man diese nicht gar zusammenführt. Vielfach sieht man das die Flächen bis auf 1/2 Straßenbreite an die Ways herangezogen werden. Sicherlich mappen wir nicht für die Renderer aber dort sind dann immer kleine Leerstreifen was mehr als unschön aussieht. Ich kann mir auch nicht vorstellen das Renderer diese Entscheidung - bis wo Flächen gehen in Zukunft ausgleichen werden. Wie denkt Ihr darüber bzw. wie macht Ihr das ??? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Kolossos tim.al...@s2002.tu-chemnitz.de wrote: Hintergrund ist, dass solche Besucherzahlen ggf. aus eine Wikipedia-Anwendung[1] entstehen könnten, welche Wikipedia-Objekte auf einer OSM-Karte zeigt und wenn man die Anwendung direkt neben der Koordinate im Wikipedia-Artikel verlinken würde. (Momentan gibt es nur ein OSM-Gadget für angemeldete Nutzer.) Sicherlich würde dieses Feature - auch für Nichtwikipedianer angezeigt - neben einem Trafficschub auch einen Bekanntheitsschub für OSM bringen. Dann könnte man OSM für Laien auch so erklären, dass es unter Anderem auch Karten für die Wikipedia macht. So ist mit einem Satz - z.B. in der Kommunikation mit Gemeindeverwaltungen - schon eine ganze Menge (z.B. Wikipedia Prinzip) rübergebracht. Ich warte daher schon sehnsüchtig darauf. So müssen wir aber wohl auf die vom Toolserver gerenderten Tiles umstellen. Ich hatte es laienmässig bisher so verstanden, dass bei Wikipedia die Karte mit den Tags gerendert in der jeweiligen Landessprache ausgeliefert werden soll. Diese werden von OSM jedoch nicht gerendert. Damit können die OSM.Karten apätestens dann ohnehin nicht genutzt werden, oder? Muss also im Zuge dessen nicht ohnehin auf entsprechend gerenderte Karten auf den Wikimedia-OSM Servern zugegriffen werden? Übrigens wäre so etwas sehr schön in den zweisprachigen Gebieten Belgiens zu kontrollieren, wo jede Straße mit name:fr und name:nl getaggt ist (auch in der Realität zwei Straßennamenschilder), zum Beispiel hier: http://www.openstreetmap.org/?lat=50.75522lon=4.37916zoom=15layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 um 17:20 schrieb Jan Tappenbeck: Hi ! wenn man flächendefiniert dann bin ich der Auffassung das diese bis dicht an die Ways gezogen werden sollen - wenn man diese nicht gar zusammenführt. Vielfach sieht man das die Flächen bis auf 1/2 Straßenbreite an die Ways herangezogen werden. Sicherlich mappen wir nicht für die Renderer aber dort sind dann immer kleine Leerstreifen was mehr als unschön aussieht. Ich kann mir auch nicht vorstellen das Renderer diese Entscheidung - bis wo Flächen gehen in Zukunft ausgleichen werden. Wie denkt Ihr darüber bzw. wie macht Ihr das ??? Das Problem der Rednerer liegt nicht bei den Flächen sondern bei den ways. Straßen werden nicht mit ihrer reellen kompletten Fahrbahnbreite über alle Spur-Arten hinweg zusammen gerendert (eine Linie für alles, auch wenn es eigene Parkstreifen, Fußgängerwege und Radwege gibt, einseitig oder beidseits) und alles ohne bauliche Trennung. Dennoch muss der way dort gezeichnet werden, was die Mitte mehrerer GPS-Spuren ist, da das die wahrschienlichste Mitte der Fahrbahn darstellt und GPS-Ausreisser ausgleicht. Und nicht der Schönheit halber an die Flächen heranziehen. Denn falls später einmal ein populärer Renderer sich dazu entschließen sollte, das Fahrspuren und Radwege, Gehwege, etc. in ihrer realen oder wahrscheinlichen Breite gerendert würden, wäre der way nicht mehr in der Mitte der realen Fahrbahn und der Rednerer würde Fahrspuren in die Fläche hineinzeichnen. Aus diesem Grunde schon: niemals für die Renderer die Lage von ways falsch zeichnen, wie Du auch schon sagst. Die Fläche dahin zeichnen, wo sie nunmal ist (wird ja auch so gerendert) und den way auf die wahrscheinliche Mitte der _gesamten_ Fahrbahnbreite inkl. Sonderspuren bis zur nächsten baulichen Trennung zeichnen, dann ist die Lage des way auch noch in Zukunft nutzbar und muss nicht korrigiert werden, wenn die Renderer endlich die Fahrbahnbreite/Fahrspurenangaben z.B. (lanes=4) unterstützen. steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Hallo Jan, ich hatte gerade auf der Karlsruhe Liste die gleiche Frage gestellt. Jan schrieb: Vielfach sieht man das die Flächen bis auf 1/2 Straßenbreite an die Ways herangezogen werden. Sicherlich mappen wir nicht für die Renderer aber dort sind dann immer kleine Leerstreifen was mehr als unschön aussieht. Ich kann mir auch nicht vorstellen das Renderer diese Entscheidung - bis wo Flächen gehen in Zukunft ausgleichen werden. Ich mache es in Zukunft so, dass ich landuse-Grenzen (Acker grenzt direkt an Wald, oder residential grenzt direkt an Wiese) zusammenführe. Oft liegt auch noch ein Feldweg oder ein Waldweg dazwischen, den nehme ich dann auch noch mit. Ich habe in meiner Gegend dadurch übrigens auf einer kleinen Fläche mehrere Hundert Nodes eingespart. Also es ist (meistens) nicht nur korrekt sondern sieht auch besser aus und spart dazu noch Nodes. Was ich allerdings nicht ohne Ortsbegehung mache, ist die Flächen (landuse) an größere Landstraßen heranzuziehen (zusammenzulegen). Denn da ist ja tatsächlich oft ein kleiner Streifen Niemandsland neben der Straße. Eine Böschung, ein Stück Brachland liegen dann schon mal zwischen der Landstraße und dem Wald oder der Wiese. Ich bin gespannt auf die Reaktionen. Klaus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr.2
Gehling Marc m.gehl...@gmx.de wrote: ein Versuch, wöchentlich aus dem OSM-Universum Projekte, Neuigkeiten und Diskussionen zusammenzutragen. http://www.openstreetmap.org/user/osm%20dortmund/diary/11378 Ist das nicht viel zu schade für eine Nische auf der Dortmund-OSM-Seite? Was hieltet ihr davon, das auch in der Neuigkeiten Rubrik der OSM-Wiki-Hauptseite unterzubringen. http://wiki.openstreetmap.org/wiki/Hauptseite http://wiki.openstreetmap.org/wiki/DE:Template:News Ich habe die ersten beiden Wochennotizen dort verlinkt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Moin, als ich mit OSM angefangen habe, hab ich verstärkt Flächen zusammengezogen mit den umliegenden Straßen oder anderen Wegen. Da es besser aussieht, sowie bei Landnutzung wie Wohngebiet/Schulgelände/Industriegebiet etc eher der Realität entspricht. Hat den Vorteil, das es besser im Renderer aussieht, weniger Nodes verursacht die in Potlatch zur Verwirrung beitragen und niemand Straßen/Rad- oder Fußwege ausversehen nur an die Landuse Fläche anschließt anstatt an die eigentliche Straße. Zudem bin ich der Meinung, da wir die Mitte der Straße mappen, aber diese representativ für die ganze Straße mit allen Fahrspuren etc steht alles direkt von der Straße an schon die entsprechende Landnutzung darstellt. Diese Frage tauchte in den letzten Jahren aber schon öfters auf dieser ML auf. Viele beschwerten sich, das dadurch das editieren schwieriger wird (übereinander liegende Flächen und die Tatsache das viele nicht wissen wie man in JOSM diese selektiert) Ebenso die Aussage, das eben nicht die Landfläche direkt bis an die Straße geht, da ist ja noch der Radweg etc dazwischen. Mittlerweile Mappe ich in fast allen Fällen solche Flächen bis dicht an die Straßen ran, solange bis jemand eine Lösung alla Linienbündel/Gruppierung gefunden hat oder wir die danebenliegenden Fuß- und Radwege alle einzeln einzeichnen. Ausnahmen mache ich wo zum Beispiel Häuser mit Grunflächen zusammentreffen oder größere Öffentliche Plätze (highway=pedestrian) mit Gebäuden etc direkt abschließen. Ich denke aber, hier wird es keine Aussagekräftige Meinung zu diesem Thema geben so schnell. Jeder hat da ja so seine Vorlieben und Arbeitsweisen. Bin aber ja mal gespannt ob sich die Meinung seit den letzten Diskussionen etwas verschoben hat ;) Gruß Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 schrieb Steffterra: Denn falls später einmal ein populärer Renderer sich dazu entschließen sollte, das Fahrspuren und Radwege, Gehwege, etc. in ihrer realen oder wahrscheinlichen Breite gerendert würden, wäre der way nicht mehr in der Mitte der realen Fahrbahn und der Rednerer würde Fahrspuren in die Fläche hineinzeichnen. Solange wir keine flächenhaften Wege haben fallen für mich der linke Rand des Weges, die Mitte des Weges und der rechte Rand zusammen. Aus diesem Grunde schon: niemals für die Renderer die Lage von ways falsch zeichnen, wie Du auch schon sagst. Die Fläche dahin zeichnen, wo sie nunmal ist (wird ja auch so gerendert) und den way auf die wahrscheinliche Mitte der _gesamten_ Fahrbahnbreite inkl. Sonderspuren bis zur nächsten baulichen Trennung zeichnen, dann ist die Lage des way auch noch in Zukunft nutzbar und muss nicht korrigiert werden, wenn die Renderer endlich die Fahrbahnbreite/Fahrspurenangaben z.B. (lanes=4) unterstützen. Es kann doch für die zukünftigen Renderer kein Problem sein, die an die Fahrbahn direkt angrenzenden landuse Bereiche entsprechend der realen und gezeichneten Fahrbahnbreite wieder automatisch zurückzudrängen. Gruß Klaus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
addi...@gmx.net (Johann H. Addicks) am 01.08.10: Am 31.07.2010 23:55, schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1 Und bitte Abfilterung von Beiträgen mit 70% Quoteanteil. .oO(XP meckert das doch an vor dem Versenden, bieten andere Programme etwa solchen Service nicht?) Rainer -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 um 18:02 schrieb Klaus Hanauer: Am 01.08.2010 schrieb Steffterra: Denn falls später einmal ein populärer Renderer sich dazu entschließen sollte, das Fahrspuren und Radwege, Gehwege, etc. in ihrer realen oder wahrscheinlichen Breite gerendert würden, wäre der way nicht mehr in der Mitte der realen Fahrbahn und der Rednerer würde Fahrspuren in die Fläche hineinzeichnen. Solange wir keine flächenhaften Wege haben fallen für mich der linke Rand des Weges, die Mitte des Weges und der rechte Rand zusammen. zusammen in die gemittelten GPS-Spuren, in der einen Linie des einen way - richtig. Aus diesem Grunde schon: niemals für die Renderer die Lage von ways falsch zeichnen, wie Du auch schon sagst. Die Fläche dahin zeichnen, wo sie nunmal ist (wird ja auch so gerendert) und den way auf die wahrscheinliche Mitte der _gesamten_ Fahrbahnbreite inkl. Sonderspuren bis zur nächsten baulichen Trennung zeichnen, dann ist die Lage des way auch noch in Zukunft nutzbar und muss nicht korrigiert werden, wenn die Renderer endlich die Fahrbahnbreite/Fahrspurenangaben z.B. (lanes=4) unterstützen. Es kann doch für die zukünftigen Renderer kein Problem sein, die an die Fahrbahn direkt angrenzenden landuse Bereiche entsprechend der realen und gezeichneten Fahrbahnbreite wieder automatisch zurückzudrängen. Wenn der way aber nicht in der Mitte liegt, wie er eigentlich gezeichnet werden sollte, dann liegt die gesamte Fahrbahn verschoben - dann in realer Breite, aber verschoben auf der real gezeichneten Fläche. Woher soll der Renderer denn wissen, ob die Fläche verschoben eingezeichnet ist oder der way an die Fläche geschoben wurde? Ich sehe als Kompromiss eher: den way der Straße, wie gesagt mittig auf die reale Straße zu zeichnen und die Fläche bis zu dieser zu ziehen. Denn schon jetzt wird im Renderer der way die Fläche optisch überlagern und so die Fläche mit seiner Straßenbreite übermalen. steffterrs ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 17:20, schrieb Jan Tappenbeck: Hi ! wenn man flächendefiniert dann bin ich der Auffassung das diese bis dicht an die Ways gezogen werden sollen - wenn man diese nicht gar zusammenführt. Vielfach sieht man das die Flächen bis auf 1/2 Straßenbreite an die Ways herangezogen werden. Sicherlich mappen wir nicht für die Renderer aber dort sind dann immer kleine Leerstreifen was mehr als unschön aussieht. Ich kann mir auch nicht vorstellen das Renderer diese Entscheidung - bis wo Flächen gehen in Zukunft ausgleichen werden. Wie denkt Ihr darüber bzw. wie macht Ihr das ??? Gruß Jan :-) Ok ! im allgemeinen wird meine Meinung also geteilt - was mich primär zu diesem Posting veranlaßt hat ist die Tatsache das einige Landuse etwas schlampig gezeichnet haben. Nach dem Motto Hauptsache das ist etwas definiert. Sieht meistens doof aus wegen der besagten Lücken und dann werden manchmal aneinander schließende Flächen mit großen Lücken belassen. Wenn Straßen dann einmal flächenhaft sind macht das ja nichts - überdeckt dann die landuse. Ich bin sowieso für die Ortsbegehung zur Flächenerfassung - das Satellitenbild kann dann zur Abgrenzung herangezogen werden. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Wochennotiz Nr.2
Am 01.08.2010 um 17:55 schrieb Tirkon tirko...@yahoo.de: Gehling Marc m.gehl...@gmx.de wrote: ein Versuch, wöchentlich aus dem OSM-Universum Projekte, Neuigkeiten und Diskussionen zusammenzutragen. http://www.openstreetmap.org/user/osm%20dortmund/diary/11378 Ist das nicht viel zu schade für eine Nische auf der Dortmund-OSM-Seite? Was hieltet ihr davon, das auch in der Neuigkeiten Rubrik der OSM-Wiki-Hauptseite unterzubringen. http://wiki.openstreetmap.org/wiki/Hauptseite http://wiki.openstreetmap.org/wiki/DE:Template:News Ich habe die ersten beiden Wochennotizen dort verlinkt. Wir planen die Wochennotiz zusammen mit weiteren Inhalten in Zukunft in einem eigenem Blog unterzubringen. -Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Tim Alder wrote: Meine Million Besucher bezog sich auf einen Monat und erscheint nun doch eine relevante Größenordnung. Ich wuerde sagen 1 Million Besucher ist definitiv in der Groessenordnung wo man sich schon darueber Gedanken machen muss, wie genau der Traffic letztendlich aussieht, ist aber dennoch in der realistisch moeglichen Groessenordnung. Man sollte es dann aber am besten mit einem der beiden Sysadmins des tileservers (Jon Burgess oder Grant Slater) absprechen um sicher zu stellen das es OK ist. Ein paar mehr Zahlen kann man auch unter http://wiki.openstreetmap.org/wiki/Talk:Tile_usage_policy#More_details_about_.22heavy_users.22 finden, wie sich der Traffic so auf verschiedene User aufteilt. Tim Alder wrote: Dabei gilt ja wohl, dass ein Tile-Cache ja umso effizienter arbeitet, je mehr Besucher darauf zugreifen und dass das Ausliefern von Tiles billiger ist und schneller geht als das Neu-Rendern. Wenn die wiki Anwendung durch einen der wikimedia Squid-Proxy's laufen wuerde, wuerde das moeglicherweise die Last auf den OSM tile server genuegend reduzieren, als das es nicht zum Problem werden wuerde. Man muesste sich aber wiederum ueberlegen wie effektiv das ganze gecacht werden kann. Der OSM tileserver selbst hat bereits einen Squid-Proxy (zum Teil) vor geschaltet. Zu den Zugriffs zahlen des Tile servers (Yevaud) kommen also noch einmal die Zugriffszahlen des Proxy's dazu ( http://munin.openstreetmap.org/openstreetmap/konqi.openstreetmap/#squid ), wobei der Proxy vielleicht nicht so effektiv ist wie man sich das vielleicht erhofft, mit einem hit ratio von lediglich ca 30% und einem byte-hit ration von ca. 50%. Das haengt aber auch wiederum stark von einigen Faktoren ab. Insgesammt waere es jedenfalls sehr schoen, wenn mehr OSM Karten in Wikipedia direkt eingebunden werden koennten. Den deutschen Wikipedia-geohack finde ich imho jedenfalls in der Hinsicht recht gut gelungen. (Und der laeuft im uebrigen auch ueber den OSM tile server und nicht ueber toolserver.org ohne Probleme) Kai -- View this message in context: http://gis.638310.n2.nabble.com/Zugriffszahlen-auf-openstreetmap-org-tp5359549p5361345.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] OSM-Wochennotiz Nr.2
Am 01.08.2010 um 18:17 schrieb Jonas Krückel: Wir planen die Wochennotiz zusammen mit weiteren Inhalten in Zukunft in einem eigenem Blog unterzubringen. super Idee! steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 schrieb Steffterra: Ich sehe als Kompromiss eher: den way der Straße, wie gesagt mittig auf die reale Straße zu zeichnen und die Fläche bis zu dieser zu ziehen. Denn schon jetzt wird im Renderer der way die Fläche optisch überlagern und so die Fläche mit seiner Straßenbreite übermalen. Genau so habe ich das auch gemeint, und so mache ich es, wenn die Flächen wirklich real am Straßenrand enden. Aber häufig sehe ich auch, dass Flächengrenzen nicht übereinstimmen (keine Straßen, nur landuse). Das ist wohl aus der Angst geboren, dass man sie nicht mehr auseinanderbringt (Wege trennen hat man mir auch erst spät beigebracht). Gruß Klaus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] phpMyGPX v0.6.1 veröffentlicht
Johann H. Addicks schrieb: Viele Tools verschlucken sich übrigens, wenn der GPX-Logger mal Timestamps herausgibt, die nicht in die zeitliche Reihenfolge passen. (der RGM-3800 schafft das irgendwie bisweilen) AFAIK schafft er das zuverlässig, wenn er über Mitternacht (UTC) loggt. Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] phpMyGPX v0.6.1 veröffentlicht
Thomas Ba schrieb: Am Fri, 30 Jul 2010 16:58:05 +0200, schrieb Sebastian Klemm osm-l...@freenet.de: Wie hast Du denn das hinbekommen? Eigentlich sollten Trackpoints ohne Zeitstempel gar nicht erst importiert werden. Ja, da steht überall der gleiche drin, aber so wie ich das gesehen hab, verwerfen manche Geräte den Zeitstempel beim speichern der Tracks… Mein Garmin Etrex Venture HC zum beispiel speichert nur bei der aktuellen Trackaufzeichnung die Uhrzeit, bei den gespeicherten, werden diese entfernt -.- Hier wird kurz erwähnt, was da passiert¹. Irgendwo gab es auch Informationen, wie man diese kaputten Daten mit gpsbabel repariert, ich finde das nur nicht. Schreib doch einfach auf eine Speicherkarte und das Problem hat sich erledigt. ¹ http://wiki.openstreetmap.org/wiki/Using_filters_with_GPSBabel#Remove_all_saved_tracks_filter Gruß malenki (Übrigens ist dein Zeilenumbruch bei ~ 72-80 Zeichen defekt. Eigentlich ist das das Markenzeichen der Apfel-Mailer.) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] phpMyGPX v0.6.1 veröffentlicht
Am Sun, 1 Aug 2010 19:51:13 +0200, schrieb malenki o...@malenki.ch: Thomas Ba schrieb: Am Fri, 30 Jul 2010 16:58:05 +0200, schrieb Sebastian Klemm osm-l...@freenet.de: Wie hast Du denn das hinbekommen? Eigentlich sollten Trackpoints ohne Zeitstempel gar nicht erst importiert werden. Ja, da steht überall der gleiche drin, aber so wie ich das gesehen hab, verwerfen manche Geräte den Zeitstempel beim speichern der Tracks… Mein Garmin Etrex Venture HC zum beispiel speichert nur bei der aktuellen Trackaufzeichnung die Uhrzeit, bei den gespeicherten, werden diese entfernt -.- Hier wird kurz erwähnt, was da passiert¹. Irgendwo gab es auch Informationen, wie man diese kaputten Daten mit gpsbabel repariert, ich finde das nur nicht. Schreib doch einfach auf eine Speicherkarte und das Problem hat sich erledigt. ¹ http://wiki.openstreetmap.org/wiki/Using_filters_with_GPSBabel#Remove_all_saved_tracks_filter Das ist ja mein Problem, das Garmin die Zeitstempel verwirft. Ich geh im Septmeber zwei Wochen Radfahren und da hab ich keinen Laptop, deswegen muss ich da dann auf die Speicherfunktion zurückgreifen... Da muss man dann nachträglich welche einbauen -.- Gruß malenki (Übrigens ist dein Zeilenumbruch bei ~ 72-80 Zeichen defekt. Eigentlich ist das das Markenzeichen der Apfel-Mailer.) Ähm nein, das hab ich ausgeschalten ^^ Grüße, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
On 08/01/2010 05:48 PM, Klaus Hanauer wrote: Ich habe in meiner Gegend dadurch übrigens auf einer kleinen Fläche mehrere Hundert Nodes eingespart. Also es ist (meistens) nicht nur korrekt ist es nicht, denn die Flächen links und rechts der Straße haben in Wirklichkeit keine gemeinsame Kanten sondern sieht auch besser aus das ist Geschmackssache. Im gerenderten Ergebniss mögen die kleinen weißen Streifen stören wenn die Flächen nicht nah genug an die als Linie abstrahierte Straße herangezogen wurden. Im Editor sehe ich aber lieber sofort ob da einfach nur zwei Landuse-Flächen direkt aneinanderstoßen (zB Übergang Acker-Wiese oder Acker-Wald) oder zwischen beiden noch ein Weg verläuft der die beiden deutlich voneinander trennt. und spart dazu noch Nodes. Das alleine ist nicht unbedingt von Vorteil, vor allem nicht wenn man später die Flächen wieder auseinanderdröseln muss um sie nachzubearbeiten. Ich hab am Anfang auch anders gedacht, mit der Zeit beim Verfeinern der Daten habe ich aber irgendwann dermaßen angefangen über mich selbst zu fluchen das ich schließlich 2-3 Tage drauf 'verschwendet' habe die ganzen shared ways doch wieder aufzudröseln. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] phpMyGPX v0.6.1 veröffentlicht
hi Viele Tools verschlucken sich übrigens, wenn der GPX-Logger mal Timestamps herausgibt, die nicht in die zeitliche Reihenfolge passen. (der RGM-3800 schafft das irgendwie bisweilen) AFAIK schafft er das zuverlässig, wenn er über Mitternacht (UTC) loggt. Gibt es irgendwo so eine kaputte GPX Datei? Ich bin auch gerade am GPX parsen und würde das gerne ausprobieren. lg Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 17:20, schrieb Jan Tappenbeck: Vielfach sieht man das die Flächen bis auf 1/2 Straßenbreite an die Ways herangezogen werden. Sicherlich mappen wir nicht für die Renderer aber dort sind dann immer kleine Leerstreifen was mehr als unschön aussieht. Ich kann mir auch nicht vorstellen das Renderer diese Entscheidung - bis wo Flächen gehen in Zukunft ausgleichen werden. Der way ist nach Auffassung der meisten hier eine Abstraktion der echten (zweidimensionalen) Straße, das andere ist die reale landuse Fläche. Es sind zwei verschiedene Sachen und sollten nicht zwanghaft kombiniert werden. Wenn schon richtig, dann die Straße auch als Fläche zeichnen. Dann wäre es korrekt beide Flächen zu verbinden. Beste Grüße, Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden way s bei forward/backward)
Am Sonntag 01 August 2010, 15:55:18 schrieb steffterra: Am 01.08.2010 um 14:37 schrieb Guenther Meyer d@sordidmusic.com: das Popup kam von dir ;-) Am 31.07.2010 um 13:59 schrieb Guenther Meyer: Am Samstag 31 Juli 2010, 09:38:45 schrieb steffterra: der Editor kennt die Referenzrichtung des Weges, und kann sein backward Tag danach ausrichten und entsprechend anzeigen. Wie das in der Realitaet aussieht, weiss sowieso nur der User. Die Problem ist doch, dass der user es irgendwo eingeben muss. Und da kommt es sehr darauf an, wie die Eingabefelder beschriftet werden und wie das dann vom Editor interpretiert wird, um daraus den richtigen backward/forward/left/right-tag zu machen. durch grafische Eingabe!? Der User sieht die Abbildung der Strasse, und darauf in Form eines Pfeils oder einer anderen Art der Darstellung, in welcher Richtung oder auf welcher Seite die Eigenschaft gueltig ist. Was meinst Du dann mit graphischer Eingabe? Ich dachte Du meinst ein Eingabefenster, das an der Graphik zeigt, wo die tags angegeben werden. Mein Fehler, vergessen wir das ganze. Wie sollte Deiner Meinung nach eine graphische Eingabe aussehen??? konkret muss man schauen, was die beste Methode ist, das darzustellen. Ich gehe einen Schritt weiter. Ich will nicht, dass der User (ausser er arbeitet in einem speziellen Expertmode) ueberhaupt mit Tags zu tun hat. Damit stellst Du aber alles in Frage und schlägst ein System wie Potlatch oder Mapzen vor, bei denen Du nur Checkboxen, die die Tags tepräsentieren, anhakst, um die Eifenschaften eines ways abzubilden. natuerlich. Wozu soll der User Tags direkt eingeben? Das hat nur Nachteile (Tippfehler, Missverstaendnisse, unnoetige Komplexitaet, ...). Wie willst Du nun richtungsabhängige Informationen mithilfe dieser Art der Eingabe realisieren? zum Beispiel so: Der User hat die Strasse selbst bereits gezeichnet. Dann waehlt er irgendwie Eigenschaften hinzufuegen und kann auswaehlen, was er gerne haette. Attribute, die richtungsabhaengig moeglich sind, bekommen eine Checkbox, um die Eigenschaft zu splitten. Wenn er die dazugehoerenden Werte auswaehlt/eingibt, wird grafisch (z.B. als Pfeil) oder farblich (rot/gruen) angezeigt, welche Seite er gerade berarbeitet. das waere eine Moeglichkeit. Eine andere noch schoenere Variante waere, das in einer vergroesserten Darstellung der Strasse durch Klicken direkt dort einzufuegen, wo es hingehoert. Diese Richtung des ways ist aber nicht definiert, noch weiss man, ob er beim Vorhandensein von richtungsabhängigen Tags noch in die richtige Richtung zeigt. Das ist ja das Motiv für eigene ways für richtungsabhängige Eigenschaften! ich geb's auf. Willst du allgemeines grafischen Editieren diskutieren, oder nur dein Modell? Falls letzteres, dann lass die forward/backward-Zeug aus dem Spiel, denn es funktioniert laut deiner Aussage sowieso nicht. Also irrelevant. Es bleibt also dabei: es hängt am User. Und diese menschliche Fehlerquelle kann man IMHO nur durch einen eigenen way minimieren. den Menschen kannst du gar nicht eliminieren, weil der der einzige ist, der weiss, wa wohin gehoert. Der Editor ist der, der ihm das Eingeben seines Wissens so einfach machen muss wie moeglich. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] phpMyGPX v0.6.1 veröffentlicht
bernhard zwischenbrugger schrieb: [Quoting repariert] malenki schrieb: AFAIK schafft er das zuverlässig, wenn er über Mitternacht (UTC) loggt. Gibt es irgendwo so eine kaputte GPX Datei? Ich bin auch gerade am GPX parsen und würde das gerne ausprobieren. Ich wollte mir das eh noch einmal näher anschauen und (falls alle Programme defekte Dateien auslesen) dem Hersteller eine Mail schreiben. Wenn ich ein entsprechendes Log habe, melde ich mich. (Oder du fragst in spätestens zwei Wochen nach, wo das log denn bleibt :) ) Gruß malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] opening_hours - Aufruf
Moin, Ich hab mir mal Thüringen auf meinen Server via osm2pgsql geladen. Heute stolperte ich zufällig über einen seltsamen opening_hours-Tag gestolpert und hab ihn korrigiert. Danach hab ich mir in meiner Postgre-DB mal aus Interesse alle opening_hours-Tags ausgeben lassen. Mir haben sich die Zehennägel gekäuselt. Für Thüringen hab ich die meisten Fehler ersteinmal korrigiert. Hier mal eine Sammlung, was da war: * Abkürzungen auf Deutsch * Angabe, wie vom Schild abgeschrieben (Montag - Freitag 10:00 - 18:00 Uhr) * Leerzeichen wo nun wirklich keine sein sollten (vor oder nach dem Doppelpunkt, vor oder nach dem einfachen Komma) * Punkt statt Doppelpunkt beim Stunden-Minuten-Trenner * Komma statt Semikolon als Öffnungszeitentrenner * ab xx:xx statt xx:xx+ * selten wurde auch mal das Semikolon ganz vergessen Außerdem, würde ich beim parsen die Regel: Ausnahmen zu einem Bereich von Tagen: Erst der Bereich, dann die Ausnahme (z.B. Mo-Sa 10:00-20:00; Tu off ) oder (z.B. Mo-Sa 10:00-20:00; Tu 10:00-14:00 ) beachten, würde auch folgendes drunter fallen: Mo-Fr 08:00-12:00;Th,Tu 14:00-18:00 und am Ende käme raus Mo,We,Fr 08:00-12:00;Th,Tu 14:00-18:00 (in dem Fall stands auf der Website richtig) Nu frag ich mich, ob ich die Regel in meiner Anwendung parsen sollte und die Wenigen*, die nach der Regel gehen sind glücklich, aber die vielen, die wegen Unverständnis o.a. es so gemacht haben, haben Pech. Oder soll ich's lassen... (*): xx off wird soundso priorisiert behandelt und ignoriert alle Zeitangaben ;-) Nun zum Sinn (und Unsinn) der Mail: 1. An alle, die zu viel Zeit haben, schaut mal bei euch in der Umgebung nach seltsamen opening_hours-Tags und korrigiert sie 2. die Frage nach der Bereichs-Ausnahme-Regel MfG Andreas -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] opening_hours - Aufruf
Hallo, könnte man nicht mal so eine Aktion dazu starten, wo ein Bot alle falschen Angaben auswirft und alle dann diese Fehler wieder paketweise verbessern können? Die deutschen Abkürzungen lassen sich doch relativ leicht finden, alle Werte, bei denen zum Beispiel So vorkommt. Ausgeschriebene Werte sind auch einfach zu finden. Damit hätte man ja schonmal leicht die gröbsten Fehler raus. Ganz praktisch wäre das auch in Keepright, weil eine Aktion kümmert sich ja irgendwie nicht ständig um die Dinge und ist eher so eine einmalige Verbesserungsaktion. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] place=village area Quelle
Am 31.07.2010 08:13, schrieb Holger s...@der: Hallo Liste, bin gerade dabei Dörfer zu mappen. Um die Orte auf der Karte besser einzugrenzen, möchte ich ein place=village area zeichnen. Moin, ich kann dabei nicht helfen, aber ich habe mich schon manchmal gefragt, was place=village als Fläche aussagt. Im Wiki steht etwas von bebauter Fläche, politischer Grenze und (in der englischen Version) Fläche, innerhalb derer die innerörtlichen Verkehrsregeln gelten. Letzteres wäre nur mit einigen Verrenkungen als Fläche abzugrenzen. Im allgemeinen fallen diese Definitionen nicht zusammen. Für die Bebauung haben wir landuse, für die politische Grenze boundary und für die Ortsschilder traffic_sign=city_limit. Wozu also place=village als Fläche? Gruß, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] opening_hours - Aufruf
Man möge meine Rechtschreib- und Grammatikfehler übersehen... Irgendwie ist heute bei mir der Wurm drin. Außerdem sollte ich aufhören Pausen beim Mailschreiben einzulegen :-(. -- Diese Nachricht wurde maschinell erstellt und ist daher ohne Unterschrift gültig. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei forward/backward)
Am 01.08.2010 um 20:57 schrieb Guenther Meyer: Es bleibt also dabei: es hängt am User. Und diese menschliche Fehlerquelle kann man IMHO nur durch einen eigenen way minimieren. den Menschen kannst du gar nicht eliminieren, weil der der einzige ist, der weiss, wa wohin gehoert. Der Editor ist der, der ihm das Eingeben seines Wissens so einfach machen muss wie moeglich. jetzt gebe ich diesen Zweig der Diskussion auf. Du willst mich missverstehen? Nein, aber wir kommen auch nicht weiter. Wir drehen uns im Kreis. Aber Dein Vorschlag mit der grafischen Umsetzung des Taggings ist dennoch eine gute Möglichkeit, wie ich finde, die mein Modell unnötig machen würde. Das fände ich ja auch gut. Bringe es zu einem Proposal und ich werde dafür stimmen. Bis dann, hole Dir ein paar Entwickler ins Boot und ich wünsche Dir viel Erfolg beim Erstellen des Proposal. Das meine ich ernst. Grüße, steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 17:20, schrieb Jan Tappenbeck: Hi ! wenn man flächendefiniert dann bin ich der Auffassung das diese bis dicht an die Ways gezogen werden sollen - wenn man diese nicht gar zusammenführt. Ich nehme an, du meinst insbesondere landuse-Flächen. Diese kann man prinzipiell auf zwei Arten definieren: - landuse umfasst das genutzte Gebiet inklusive der erschließenden Straßen und Wege. Dann folgt daraus, dass man die Mittellinie einer Straße auch als Grenze zweier verschiedener landuse-Flächen nutzt. oder - landuse umfasst nur die genutzte Grundstücke ohne jede Straßenfläche. Ich halte die erste Definition für sinnvoll. Bei Straßen, von denen keine Auffahrten, Feldzufahrten oder Waldwege abzweigen, lasse ich das Gebiet neben der Straße enden. In den meisten Fällen, in denen Flächen neben einer Straße enden, wird die Straßenbreite von den Mappern deutlich unterschätzt. Dann hat man die Nachteile beider Definitionen kombiniert :-) Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage: html-Mails und Anhang in Mailingliste
Am 01.08.2010 um 03:46 schrieb Rainer Knaepper: addi...@gmx.net (Johann H. Addicks) am 01.08.10: Am 31.07.2010 23:55, schrieb Dimitri Junker: Ich wuerde mir automatischen Plaintext wuenschen. +1 +1 Und bitte Abfilterung von Beiträgen mit 70% Quoteanteil. .oO(XP meckert das doch an vor dem Versenden, bieten andere Programme etwa solchen Service nicht?) LOL, XP - Crosspoint -richtig? so hiess das tolle UUCP-DOS-Programm. Ich liebte es. Es gab nie etwas vergleichbares um Mailinglisten und Newsgroups adäquat sortiert und zu lesen zu bekommen. Heutige moderne eMail-Programme können viel, aber nicht XP ersetzen. Doch es gibt modernere und effektivere Methoden vielschichtige Sachverhalte mit vielen Leuten zu diskutieren, ohne sich ständig im Kreis zu drehen: z.B. Foren mit guter Moderation. Mit diversen Ansätzen zu ein paar Diskussionen in der letzten Zeit (durchgezogene Mittellinie, Gruppierung von ways, u.v.a.m.) konnte ich bemerken, wie schwierig es hier ist - und anstrengend und letztendlich ohne outcome, ausser reinem Meinungsaustausch, der häufig darauf beruhte, dass eben nicht alles gelesen wurde. Somit gebe ich hier großflächig auf und überlege mir auch das Gruppierungs-Proposal weiter zu verfolgen. Auch das ist ein Outcome der Diskussionfähigkeit dieses Mediums. Grüße und machts gut, möglichst effektiv ;-) steffterra ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugriffszahlen auf openstreetmap.org
Hallo, Kolossos wrote: Auf meinen kleinen Laptop-Bildschirm (15 Zoll) passen 5 Kacheln in der Breite und 3 Kacheln in der Höhe auf den Bildschirm, also sieht man erstmal nur 15 Kacheln, da fand ich meine Schätzung mit 50 Kacheln schon ganzschön hoch. Ich habe aber jetzt auch gesehen, dass durch den größeren Bereich der heruntergeladen wird, gleich viel mehr Kacheln kommen. OpenLayers ist da ziemlich verschwenderisch, das muss man schon sagen. Falls man eine Anwendung baut, bei der es wenig wahrscheinlich ist, dass der Benutzer die Karte nach links und rechts verschiebt, koennte man drastisch Volumen sparen, indem man OpenLayers so patcht/konfiguriert (?), dass es etwas konservativer mit dem ich lad schon mal vorsichtshalber etwas mehr umgeht. 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] Programmierer: Importhilfe amtlicher Grenzen gesucht
Mit dem Python-Programm Ogr2Osm [1] werden automatische Multipolygone erstellt. Man kann zu dem eine Übersetzungsdatei angeben, bei der Shape-Attribute in OSM-Tags gewandelt werden. Dies lässt sich aber auch im Nachhinein mit JOSM erledigen. [1] http://wiki.openstreetmap.org/wiki/Ogr2osm Was gefällt dir an diesem Programm nicht, welches alle deine Wünsche im Gegensatz zu shp2osm erfüllt? André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
Hallo, Tirkon wrote: Wenn ich dies http://www.wheregroup.com/de/system/files/2009-05-19_Schmitz_BeTA2007.pdf als Laie richtig interpretiere, kommt es bei der shp2osm Umsetzung zu Fehlern in der Größenordnung von bis zu zwei Metern. Das hat im Grundsatz nichts mit shp2osm zu tun. Das bezieht sich auf die Reprojektion von Gauss-Krueger in die bei OSM verwendenten geographischen Laengen und Breiten. Es gilt also nur dann, wenn Du ein Shapefile in Gauss-Krueger vorliegen hast - was in Deinem Fall vermutlich zutrifft. Ist bei diesem Verfahren auch die Nutzung von BETA2007 integriert, die Sven bei seiner shp2osm Umsetzung angewendet hat? Das von mir geschilderte Verfahren besteht aus reinen Geometrieoperationen und wird deshalb keine Ungenauigkeiten einfuehren, die nicht vorher schon da waren. Man kann die Daten entweder umprojizieren, bevor man meine Aufteilungsschritte anwendet, oder danach - das macht keinen Unterschied. Im Falle Dresdens, den ich hier geschildert hatte, hatte ich, wenn ich mich recht entsinne, bereits ein von Sven mit BETA2007 reprojiziertes Shapefile als Eingabedatei benutzt. Man haette das ganze aber auch mit GK-Werten rechnen koennen und erst spaeter die Ergebnisse projizieren. 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] Konzept für die Gruppierung von ways ( ähnlich Linienbündel; Problem von drehenden ways bei =?iso-8859-1?q?_forward/backward?=)
Am Sonntag 01 August 2010, 23:20:32 schrieb steffterra: Am 01.08.2010 um 20:57 schrieb Guenther Meyer: Es bleibt also dabei: es hängt am User. Und diese menschliche Fehlerquelle kann man IMHO nur durch einen eigenen way minimieren. den Menschen kannst du gar nicht eliminieren, weil der der einzige ist, der weiss, wa wohin gehoert. Der Editor ist der, der ihm das Eingeben seines Wissens so einfach machen muss wie moeglich. jetzt gebe ich diesen Zweig der Diskussion auf. Du willst mich missverstehen? Nein, aber wir kommen auch nicht weiter. Wir drehen uns im Kreis. wir reden wohl manchmal aneinander vorbei ;-) Ich habe die Erfahrung gemacht, dass sich solche Dinge am effektivsten bei persoenlichen Treffen entwickeln lassen. Du bist nicht zufaellig aus der Muenchner Gegend? Ansonsten waere es vielleicht mal wieder interessant, einen OSM-Workshop wie damals im Linuxhotel zu veranstalten. Aber Dein Vorschlag mit der grafischen Umsetzung des Taggings ist dennoch eine gute Möglichkeit, wie ich finde, die mein Modell unnötig machen würde. Das fände ich ja auch gut. Bringe es zu einem Proposal und ich werde dafür stimmen. Bis dann, hole Dir ein paar Entwickler ins Boot und ich wünsche Dir viel Erfolg beim Erstellen des Proposal. Das meine ich ernst. dazu braucht's kein Proposal, sondern simple Entwicklungs- bzw. Programmierarbeit. Fuer beides hab ich in dieser Richtung praktisch keine Zeit, hab noch genug andere offene Baustellen. Und Leute dafuer zu finden, hab ich aufgegeben. Wenn sich jemand darum kuemmern will, steuere ich gerne ein paar Ideen bei. Was wird aus deinem Konzept? Waere schade, wenn das wie viele andere Dinge einfach verschwinden wuerde... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] opening_hours - Aufruf
Heute stolperte ich zufällig über einen seltsamen opening_hours-Tag gestolpert und hab ihn korrigiert. Danach hab ich mir in meiner Postgre-DB mal aus Interesse alle opening_hours-Tags ausgeben lassen. Mir haben sich die Zehennägel gekäuselt. ... Nun zum Sinn (und Unsinn) der Mail: 1. An alle, die zu viel Zeit haben, schaut mal bei euch in der Umgebung nach seltsamen opening_hours-Tags und korrigiert sie 2. die Frage nach der Bereichs-Ausnahme-Regel MfG Andreas Hi, für JOSM gibt es das Plugin um die Öffnungszeiten eindeutig einzugeben: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpeningHoursEditor Mit freundlichen Grüßen Stephan aka smarties ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
wenn man flächendefiniert dann bin ich der Auffassung das diese bis dicht an die Ways gezogen werden sollen - wenn man diese nicht gar zusammenführt. Wenn man neben einem Weg geschlossene Wege als Flaechen so eintraegt, wie man sie ermittelt hat sollte zwangslaeufig ein breiter Rand zwischen den Flaechen entstehen, da der ungerenderte Weg die Breite 0 hat. Ob dies nun Aesthetisch ist bleibt zu diskutieren und ist Sache des Renderers, der die Strassenbreite waehlt. Unabhaengig von den genannten Punkten sehe ich eine enorme Fehleranfaelligkeit bei zusammenklebenden Objekten. Fuer Einsteiger sind diese eine boese Falle und die meisten Fortgeschrittenen, loeschen solche Klumpen lieber ganz und zeichnen neu, weil es zig mal schneller geht. -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 17:48, schrieb Klaus Hanauer: Ich mache es in Zukunft so, dass ich landuse-Grenzen (Acker grenzt direkt an Wald, oder residential grenzt direkt an Wiese) zusammenführe. Oft liegt auch noch ein Feldweg oder ein Waldweg dazwischen, den nehme ich dann auch noch mit. Ich habe in meiner Gegend dadurch übrigens auf einer kleinen Fläche mehrere Hundert Nodes eingespart. Also es ist (meistens) nicht nur korrekt sondern sieht auch besser aus und spart dazu noch Nodes. Ich bemühe mich z.b. die Waldschneisen von Strassen- und Schienentrassen (etc.) soweit möglich in der realen Breite und Form einzutragen um sie u.a. auch für Anwendungen aus der Vogelperspektive nutzbar zu machen. Ich finde es daher nicht in Ordnung wenn ohne Not die exakteren Daten dem schöneren Rendern geopfert werden! Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
es ist (meistens) nicht nur korrekt sondern sieht auch besser aus und spart dazu noch Nodes. Trotz Wirtschaftskriese sind genug Nodes fuer alle da. Vom gesparten Node merkt man nicht mehr viel, wenn die Rohdaten einmal gerendert wurden. Wirklich verschwendete Nodes kannst Du hier sehen: http://tinyurl.com/osm-dupes-europe Da sind 100 Nodes wegen einer Flaeche Peanuts gegen. -- Jonas Stein n...@jonasstein.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 18:15, schrieb Jan Tappenbeck: Ok ! im allgemeinen wird meine Meinung also geteilt - was mich primär zu diesem Posting veranlaßt hat ist die Tatsache das einige Landuse etwas schlampig gezeichnet haben. Nach dem Motto Hauptsache das ist etwas definiert. Sieht meistens doof aus wegen der besagten Lücken und dann werden manchmal aneinander schließende Flächen mit großen Lücken belassen. Wenn Straßen dann einmal flächenhaft sind macht das ja nichts - überdeckt dann die landuse. Was ist bitte daran besser wenn exakt erfasste Landuseflächen der Optik wegen einzelner Kartendarstellungen zu Opfern? Das Ziel ist doch möglichst genaue Daten zu haben und nicht grafische Kunstwerke zu schaffen deren wahren Informationsgehalt wegretuschiert wird... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Am 01.08.2010 20:55, schrieb Simon Kokolakis: Der way ist nach Auffassung der meisten hier eine Abstraktion der echten (zweidimensionalen) Straße, das andere ist die reale landuse Fläche. Es sind zwei verschiedene Sachen und sollten nicht zwanghaft kombiniert werden. Wenn schon richtig, dann die Straße auch als Fläche zeichnen. Dann wäre es korrekt beide Flächen zu verbinden. +1 Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Job fuer einen Bot: Hoehenangabe im Namen
Am 29. Juli 2010 12:47 schrieb Jonas Stein n...@jonasstein.de: Ich finde die Höhenangabe bei Hütten und Bergen sinnvoll. Gibt es eine Festlegung das Hütten- und Bergnamen ohne Höhe erfolgen müssen? es gibt natürlich keine Festlegung, was alles nicht drin sein muss in einem Tag, aber es gibt eine Festlegung, dass in name nur der Name rein sollte, und eben nicht weitere ebenfalls informative Angaben. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiese gleich / ungleich Weide ??
bundesrainer schrieb: Am 01.08.2010 15:41, schrieb Jörk: man kann Wiese/Weide schon auseinanderhalten (Zaun), aber Weiden werden selten, weil zumindest die Rinder eigentlich ganzjährig im Stall stehen. Ein Zaun ist nicht unbedingt ein sicheres Unterscheidungsmerkmal: Ein fester Zaun umgibt auch schon mal Wiesen. Ebenso lassen fehlende Zäune nicht unbedingt auf eine Wiese schließen, da sie abseits der Saison auch abgebaut werden. Die Unterscheidung ist (wegen der fließenden Grenzen) nicht einfach und für die meisten Nutzer auch unerheblich. +1 mir ist auch eher der Zaun wichtig. Ob Tiere herumlaufen sehe ich schon und dann gibt es ja auch noch die Schäfer. colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
André Riedel riedel.an...@gmail.com wrote: Mit dem Python-Programm Ogr2Osm [1] werden automatische Multipolygone erstellt. Man kann zu dem eine Übersetzungsdatei angeben, bei der Shape-Attribute in OSM-Tags gewandelt werden. Dies lässt sich aber auch im Nachhinein mit JOSM erledigen. Ciao André [1] http://wiki.openstreetmap.org/wiki/Ogr2osm (c) Iván Sánchez Ortega, 2009 python ogr2osm.py [options] [filename] Options: -e, --epsg=... EPSG code, forcing the source data projection -p, --proj4=... PROJ4 string, forcing the source data projection -v, --verboseShows some seemingly random characters dancing in the screen for every feature that's being worked on. -h, --help Show this message -d, --debug-tags Outputs the tags for every feature parsed -a, --attribute-stats Outputs a summary of the different tags / attributes encountered -t, --translationSelect the attribute-tags translation method. See the translations/ diredtory for valid values. O.K. Ich habe mich noch nie mit der Kommandozeile richtig auseinandersetzen müssen, weil alle bisherigen Programme über die Windows XP Startfunktion gestartet und über GUIs beieinflusst werden konnten. Ich habe Python heruntergeladen und installiert. In dem runtergeladenen File ogr2osm.py wird als möglicher Startbefehl python ogr2osm.py foobar.shp -e 23030 angegeben. Das habe ich umgesetzt und bekomme folgende Fehlermeldung: E:\Programme\Python27\python E:\Programme\Pytho n27\ogr2osm.py E:\Programme\Python27\Gemarkungen.shp -e 23030 Traceback (most recent call last): File E:\Programme\Python27\ogr2osm.py, line 69, in module from SimpleXMLWriter import XMLWriter ImportError: No module named SimpleXMLWriter Folglich findet sich auch kein Gemarkungen.osm File in E:\Programme\Python27. Was ist die Ursache für die Fehlermeldung und wie kann ich sie beseitigen? Zusatzfrage: Der Term -e 23030 bedeutet, dass das *.shp-File die Projektion EPSG:23030 einsetzt. Wodurch muss ich -e 23030 ersetzen, wenn im der Begleitmail zu dem Gemarkungen.shp File angegeben war: Die Daten sind gelagert im 3. Gauß-Krüger Meridianstreifen.? Es war neben dem Gemarkungen.shp auch ein Gemarkungen.dbf und ein Gemarkungen.shx File dabei, falls das für die Beantwortung der Fragen relevant sein sollte. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Job fuer einen Bot: Hoehenangabe im Namen
Am 02.08.2010 01:32, schrieb M∡rtin Koppenhoefer: Am 29. Juli 2010 12:47 schrieb Jonas Steinn...@jonasstein.de: Ich finde die Höhenangabe bei Hütten und Bergen sinnvoll. Gibt es eine Festlegung das Hütten- und Bergnamen ohne Höhe erfolgen müssen? es gibt natürlich keine Festlegung, was alles nicht drin sein muss in einem Tag, aber es gibt eine Festlegung, dass in name nur der Name rein sollte, und eben nicht weitere ebenfalls informative Angaben. Die Höhe ist durchaus eine bezeichnende Angabe im Namen die eine Verwechslungsgefahr verringert.und in den wenigsten Fällen wir man eine Suchhilfe haben die nach der Höhe filtert. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Jonas Stein schrieb: es ist (meistens) nicht nur korrekt sondern sieht auch besser aus und spart dazu noch Nodes. Trotz Wirtschaftskriese sind genug Nodes fuer alle da. Vom gesparten Node merkt man nicht mehr viel, wenn die Rohdaten einmal gerendert wurden. Wirklich verschwendete Nodes kannst Du hier sehen: http://tinyurl.com/osm-dupes-europe was ist da denn in unseren Nachbarländern den passiert ? sehe nur noch rot ! Da sind 100 Nodes wegen einer Flaeche Peanuts gegen. +1 skyper ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Garry schrieb: Am 01.08.2010 20:55, schrieb Simon Kokolakis: Der way ist nach Auffassung der meisten hier eine Abstraktion der echten (zweidimensionalen) Straße, das andere ist die reale landuse Fläche. Es sind zwei verschiedene Sachen und sollten nicht zwanghaft kombiniert werden. Wenn schon richtig, dann die Straße auch als Fläche zeichnen. Dann wäre es korrekt beide Flächen zu verbinden. +1 +1 colliar ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programmierer: Importhilfe amtlicher Grenzen gesucht
Am 2. August 2010 01:55 schrieb Tirkon tirko...@yahoo.de: Das habe ich umgesetzt und bekomme folgende Fehlermeldung: E:\Programme\Python27\python E:\Programme\Pytho n27\ogr2osm.py E:\Programme\Python27\Gemarkungen.shp -e 23030 Traceback (most recent call last): File E:\Programme\Python27\ogr2osm.py, line 69, in module from SimpleXMLWriter import XMLWriter ImportError: No module named SimpleXMLWriter Folglich findet sich auch kein Gemarkungen.osm File in E:\Programme\Python27. Was ist die Ursache für die Fehlermeldung und wie kann ich sie beseitigen? Laut Wiki wird die OSGeo4W shell benötigt. http://wiki.osgeo.org/wiki/OSGeo_Win32_Installer Zusatzfrage: Der Term -e 23030 bedeutet, dass das *.shp-File die Projektion EPSG:23030 einsetzt. Wodurch muss ich -e 23030 ersetzen, wenn im der Begleitmail zu dem Gemarkungen.shp File angegeben war: Die Daten sind gelagert im 3. Gauß-Krüger Meridianstreifen.? Es war neben dem Gemarkungen.shp auch ein Gemarkungen.dbf und ein Gemarkungen.shx File dabei, falls das für die Beantwortung der Fragen relevant sein sollte. GK3 = EPSG:31467 Jedoch ist dies die leicht fehlerbehaftete Variante. Die Lösung mit beta2007 habe ich noch nicht probiert, sollte aber ähnlich funktionieren. Falls alle Stricke bei dir Reisen, kannst du mir es mal zuschicken und ich probiere es dir zu konvertieren. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen und Ways
Jonas Stein wrote: Wenn man neben einem Weg geschlossene Wege als Flaechen so eintraegt, wie man sie ermittelt hat sollte zwangslaeufig ein breiter Rand zwischen den Flaechen entstehen, da der ungerenderte Weg die Breite 0 hat. +1 Fuer Einsteiger sind diese eine boese Falle und die meisten Fortgeschrittenen, loeschen solche Klumpen lieber ganz und zeichnen neu, weil es zig mal schneller geht. Löschen nicht, wenn die Wege erst mal getrennt sind (ist in JOSM nur in Klick) kann man die Punkte relativ einfach auseinander ziehen, aber unnütze Mehrarbeit über die ich mich manchmal ärgere bleibt es immer. Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
