Re: [Talk-de] Hydranten
On 26.04.2013 22:33, Heinz-Jürgen Oertel wrote: Habe den Direktlink mit Firefox rechte Maus Linkadresse kopieren übernommen, anschließend wget `Einfügen` das ergibt einen ziemlich lange URL http://overpass-api.de/api/interpreter?data=%3C!--%20This . wget sagt dann event not found Wahrscheinlich sagt das nicht wget sondern deine Shell; ich denke, das liegt am Ausrufezeichen. Schließe mal alles in Hochkommas ein, dann werden die Sonderzeichen nicht von der Shell interpretiert. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie sinnvoll im Thread antworten? (Inhalticher Betreff: Open Data)
Am 22.01.2013 12:20, schrieb Wolfgang Barth: Die Mailingliste läuft also ab sofort über den Browser als Newsgroup. Die lese ich als Volltext im Browser und rufe sie vorher mit SAGE als plugin ab. Bei der Webseitendarstellung in GMANE ist allerdings standardmäßig die Schrift der Texte sehr klein. Muss mal sehen, was man da machen kann. Vielleicht nicht das Webinterface benutzen, sondern über NNTP lesen, z.B. mit Thunderbird. Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] unangekuendigte Massenedits
On 17.01.2013 20:19, Josef Latt wrote: Nee, ein highway=cycleway usw. mit oder ohne designated setzt balue Schilder voraus. Schon deshalb kann es da kein *.yes geben. Wo steht das oder wer hat das so festgelegt? Laut Wiki wird sogar empfohlen, bicycle=designated oder bicycle=yes zur Klarstellung hinzuzufügen. http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dcycleway Laut StVO gibt es nicht benutzungspflichtige Radwege (auch anderer Radweg genannt), die kein blaues Schild haben. Siehe http://www.adfc.de/files/2/110/113/Info_StVO2013_201209_mit_Lesezeichen.pdf in $2 Abs. 4 und http://www.adfc.de/files/2/110/113/Info_VwV_Novelle2009.pdf in Zu Absatz 4 Satz 3 und Satz 4, I. Radwege ohne Benutzungspflicht, 30 (vorher Andere Radwege genannt) Sollen die nicht benutzungspflichtigen Radwege alle path oder track sein? Eigentlich fände ich es logischer, wenn sämtliche Fuß- und Radwege (also auch die benutzungspflichtigen) als path oder track mit geeigneten access-Tags eingetragen würden, aber das ist eben historisch (entsprechend der britischen Rechtslage) so entstanden. Bicycle=yes ermöglich die Nutzung einer anderen Wegeart, die normalerweise für Radfahrer verboten sind (z.B. ein für Radfahrer freigegebener Fußweg). Sicher, das ist eine Anwendungsmöglichkeit. Es gibt aber auch die im Wiki (s.o.) dokumentierte Ansicht, daß bicycle=yes mit highway=cycleway kombiniert werden kann. Am 17.01.2013 17:30, schrieb Masi Master: Als drittes gibt es noch eigenständige Radwege, diese werden üblicherweise auch mit dem blauen Schild gekennzeichnet, einerseits um anzuzeigen welche Verkehrsteilnehmer erlaubt sind, und andererseits welche NICHT erlaubt sind. Und dies ist laut StVO nicht verboten. Bin mir grad nicht sicher, ob es in den VwV einen Hinweis dazu gibt. (Die Benutzungspflicht entfällt natürlich, da es keine parallele Straße gibt.) Das ist ein Widerspruch in sich, den auch die Schilderaufsteller zum größten Teil nicht begriffen haben. Es sind Gebotsschilder und dürfen laut StVO nur für benutzungspflichtige Radwege benutzt werden. Die jetzige StVO wurde AFAIK in dieser Hinsicht aufgehoben. Mit der neuen StVO wird sich dies ändern. Du solltest mal den Text der StVO zu den blauen Schildern genau durchlesen. Kannst Du angeben, wo genau das so steht, wie Du das auslegst? In StVO 2013 steht übrigens Lfd. Nr. 16: Zeichen 237 Radweg Ge- oder Verbot (und entsprechend auch bei den anderen Schildern) Ich sehe das auch so, daß die nicht zutreffenden Regelungen (Benutzungspflicht) einfach entfallen können, ohne daß die anderen (Verbot für andere Verkehrsarten) dadurch unwirksam werden. Ich habe keine Lust nochmals alles zu wiederhoeln, was ich hier dazu schon geschrieben habe. Wiederholung würde auch nicht überzeugen, sondern nur eine genauere Begründung Deiner Auslegung. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Uebermaessiges taggen von highways mit oneway=no...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03.01.2013 08:27, Werner Poppele wrote: im Bereich suedlich des Ammersees / Starnberger Sees werden nach meinem Dafuerhalten im Uebermass Tags an Strassen und Wegen eingetragen, die in diesem Umfang meiner Meinung nach nicht noetig sind. So erhalten Strassen highway=unclassified bzw highway=track die Tags: bicycle,foot,hiking,horse,mtb alle = yes, sac_scale=hiking, tracktype=grade2 und oneway=no. Strassen mit highway=secondary erhalten oneway=no Hallo Werner, die unnötigen Tags an sich finde ich nicht so schlimm, sofern sie korrekt sind. Falls es tatsächlich jemand überprüft hat, ist es meiner Ansicht nach gut, wenn auch ein Standardwert explizit eingetragen ist. Diw Wiki-Seite [1] sagt ganz klar, dass sac_scale bei Bergwanderwegen (highway=path oder footway) Verwendung finden soll. Die deutsche und englische Beschreibung im Wiki stimmen nicht überein. In der englischen Version ist auch highway=track vorgesehen und dort ist die Einschränkung auf _Berg_wanderwege nicht so deutlich. Dort steht jedoch, daß die Klassifikation nur für solche Wege benutzt werden soll, die tatsächlich zum Wandern oder Klettern verwendet werden. Ist also ein Streitfall. Im Bereich der Ortschaft Denklingen suedlich von Landsberg [2]kann man sehen, dass auch die Zufahrtstrassen zu Gebaeuden mit oneway=no getaggt sind. Gleiches gilt fuer Peiting in der Naehe von Schongau. Das ist sicher zuviel des Guten. Das halte ich für unschädlich. Es waere schoen, wenn jemand sich das mal anschauen koennte und mir die Meinung dazu bitte mitteilen wuerde und wie und ob das korrigiert werden sollte. Bei ein paar Stichproben habe ich gesehen, daß ein Teil der Daten von einem Benutzer alegria6208 stammt. Der war u.a. im genannten Bereich aktiv und ist mal aufgefallen, weil er massenweise vermutlich aus einer unerlaubten Quelle abgemalt hat. Nach Beschwerden hat er dann versucht, seine sämtlichen Daten zu löschen, und ist seit irgendwann 2010 nicht mehr aktiv. Bei dem hat Nachfragen eher keinen Sinn. Ein großer Teil stammt von einem anderen sehr aktiven Nutzer. Möglicherweise hat er die Vorgehensweise von vorhandenen Daten übernommen. Du kannst ihn ja mal fragen, warum er das so macht und ob er das vor Ort überprüft hat. Vielleicht läßt sich das so klären. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlDlT8wACgkQnMz9fgzDSqfU7ACdG3uG5eeSW+I7kS6jHi2X/muf VxgAni33vPy2e7EHBrpMolDoU1TDDwot =g+Qy -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPX-Dateien wiederfinden (was: Zurueck in die Steinzeit)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22.07.2012 20:50, Joerg Fischer wrote: Die GPX-Daten liegen ganz sicher mit chronologischem Dateinamen hier rum, aber ich merke mir nicht wann ich wo war und was ich danach dort editiert habe. Hallo Jörg, falls Du in Deinen GPX-Dateien die richtigen herausfinden möchtest, probiere mal in JOSM das Plugin openvisible. (Kann aber bei einer großen Menge an Dateien lange dauern, bis JOSM alle untersucht und die richtigen gefunden hat.) Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlAMXDcACgkQnMz9fgzDSqd41ACfTGo0NKTg1MNKcc/h767mHKNo c3oAn2uhqHz4rXEWG4bSwHrMBX9rwwCN =d7k0 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gibt es Karte mit Anzeige von Beschränkungen wie Höhe, Länge, Gefahrgut?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo alle, gibt es irgendwo eine Karte, auf der Beschränkungen angezeigt werden, die für LKW relevant sind, z.B. Höhe, Breite, Länge der Fahrzeuge, Fahrverbot für LKW, Gefahrgut usw? Ich würde gern mit einem befreundeten LKW-Fahrer prüfen, ob die Daten in OSM praxistauglich sind. Mir ist klar, daß die Daten in OSM nicht vollständig sind und daß man nicht sicher auf das Fehlen von Beschränkungen in der Realität schließen kann. Vielleicht kann ich auch die Ortskenntnis der Fahrer als Datenquelle nutzen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk/l2KIACgkQnMz9fgzDSqfkbQCdFobXION9gGyw5AQI61gQ7y4R 0j4Anjs4QHmvXCRPtL/NupOCIhbv75Pt =+/5y -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Notwendigkeit von Abstimmungsprozessen im OSM-Wiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.04.2012 18:20, schrieb Falk Zscheile: Ich hatte den Eindruck, dass die Mehrheit hier auf der Liste dahin tendiert, 1. nationale Edits nur zuzulassen, wenn man sie auch gleichzeitig in der Referenzsprache englisch tätigt. 2. nationale Edits mehr als abklatsch der englischen Referenzseite sieht. Dagegen wende ich mich. Einen Beitrag in englisch zu verfassen kostet mich mindestens das dreifache an Zeit. Das kann ich vom Aufwand her nicht leisten und stünde daher für die Wikidokumentation nicht mehr zur Verfügung. Damit schließen wir einen Benutzerkreis von vorn herein von einer Mitarbeit am deutschen OSM-Wiki aus Hallo Falk, das wäre doch der genau der Anwendungsfall für die bereits vorgeschlagenen Templates Hier müßte etwas übersetzt werden. Damit könnten einerseits Übersetzer über den Bedarf informiert werden und andererseits normale Benutzer über die Inkonsistenzen zwischen den Sprachversionen. Falls es wirklich rein lokale Besonderheiten gibt, wäre es IMHO auch ausreichend, wenn beispielsweise in der englischen Version steht Hier gibt es Besonderheiten in Deutschland, für Details siehe deutsche Version dieser Seite. Oder ohne technische Unterstützung könntest Du vielleicht in der englischen Version einen Hinweis eintragen, daß es unübersetzte Änderungen in der deutschen Version gibt. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk+fo58ACgkQnMz9fgzDSqf0/QCePRX99yEzNo8Q0gtMKmVskwwn Vw4AoIvbOUh0CIdVoaf+nN2QJ0cokQw6 =xY0O -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Notwendigkeit von Abstimmungsprozessen im OSM-Wiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 01.05.2012 15:11, schrieb Falk Zscheile: Offensichtlich sind hier alle außer mir der Meinung, der deutsche Mapper spricht englisch und mehr als auf der englischen Seite steht und übersetzt wurde braucht er beim Mappen in deutschland eh nicht zu wissen. Damit machen wir uns meiner Meinung nach selbst Probleme, die wir vermeiden könnten, indem wir auftretende Zweifelsfälle klar stellen. Kommt immer drauf an. Wenn es tatsächlich eine Klärung ist, die nur für ein Land erforderlich ist, kann man sicher die entsprechende Sprachversion erweitern. (Beispiel: Warum man in D normalerweise nicht village_green verwenden sollte.) Ist die Klarstellung allgemein interessant, sollte dies auch in der englischen Version ergänzt werden. (Beispiel: landesspezifische Auslegung von Straßenklassen.) Erst recht gilt dies für länderspezifische Uminterpretation oder andere Auslegung von Tags (sofern überhaupt sinnvoll). Für einen Nutzer der Daten oder internationale Mapper sollten alle Informationen aus der englischen Seite hervorgehen. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk+gFl8ACgkQnMz9fgzDSqd1EACfScoy/LyYF/jrgMK7C1M0VRbq 5X0An2VLbBxrzp9OkQf/PeumTs5yDqX/ =Ea2+ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Marineflächen als landuse=military
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.03.2012 11:44, schrieb Klaus-Hermann Otto Stanislaus Plöger: Das Du in der Sache unrecht hast interessiert Dich garnicht? Was legitimiert Dich als Entscheidungsinstanz? Möglicherweise haben die Abweichler, die hier ihre Meinung zur Sache vorgetragen haben, von dem entsprechenden Konsenz noch nichts mitbekommen? Ansonsten scheint (zumindest hier) die Ablehnung Deiner Ansicht häufiger vorzukommen als die Zustimmung. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9b4LAACgkQnMz9fgzDSqdYRwCeN2gmD/qHxAt0QVo3Sp1LteVM 8n4Anj0pL7/N6MLwtK4kGm1CnQMqdMoj =mrZe -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Marineflächen als landuse=military
On Fri, Mar 09, 2012 at 03:52:07PM +0100, Klaus-Hermann Otto Stanislaus Plöger wrote: Am Freitag, den 09.03.2012, 02:40 +0100 schrieb Stephan Wolff: Bislang war es üblich, auch die Wasserflächen als landuse=military zu bezeichnen (dadurch hat Bing dort sogar die Wellenstruktur unkenntlich gemacht). Die Flächen waren in fast allen Karten sichtbar. Und überdeckten alles andere. Das ist ein Renderer-Problem. Kein Grund, das zu löschen. Inzwischen wurde landuse=military teils gelöscht und durch uneinheitliche seamark-Tags ersetzt. Ich habe Hinzufügen von seamark:* würde im Gegensatz zum Löschen niemand stören. Ich finde landuse=military trotz des Namens auch für militärisch genutzte Wasserflächen sinnvoll. Zusätzliche seamark-Tags mit genaueren Unterscheidungen sind natürlich möglich. +1 Ich finde landuse im Wasser ziemlich unnatürlich. Es gibt einige Tags, bei denen die wörtiche Bedeutung nicht ganz paßt. Das ist eben historisch gewachsen. Wenn man früher an die Verwendung für Gewässer gedacht hätte, würde es vielleicht statt landuse areause heißen oder so. Und ob sich landuse über Land oder Wasser befindet, läßt sich sicher herausbekommen. Dann kann man die störende Überdeckung auch beseitigen. Weil die Werft an Land liegt, wird die Wasserfläche aber kein Land. Da gehört dann wohl eher access=private oder access=no hin. access ist aber etwas völlig anderes als landuse. Das kann man ggf. zusätzlich angeben. http://wiki.openstreetmap.org/wiki/Key:landuse sagt: Mainly used for (to) describe the primary use of land by humans. mainly heit hauptsächlich, nicht ausschließlich. Viele Grüße Bodo signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Karte mit Skipisten?
On Mon, Mar 05, 2012 at 09:30:28AM +0100, Felix Hartmann wrote: Pisten anhand schwierigkeit habe ich etwa in der Openmtbmap.org bzw VeloMap integriert... Das ist schon fast, wie ich es mir vorgestellt hätte. piste:ref werde ich zum nächsten Update auch integrieren, hab den Key noch gar nicht gekannt Super, danke. Es gibt auch noch piste:name, aber das wäre für mich weniger wichtig. (Keine Ahnung, warum für die Pisten nicht einfach ref und name verwendet wird.) Es hängt vielleicht vom Skigebiet ab, ob zur Orientierung die Nummern oder Namen besser geeignet sind. (Ich hatte bisher an den Pisten nur Schilder mit Nummern.) Ich würde mir das so wünschen, daß die Pisten-Nummern direkt sichtbar sind und die Namen als Zusatzinformation angezeigt werden, wenn man mit dem Pfeil auf die Piste zeigt. Wenn keine Nummer definiert ist, könnte möglicherweise der Name direkt angezeigt werden. Mir ist aber auf meinem GPSMAP76CSx aufgefallen, daß die Pisten mit dem Pfeil nicht selektierbar sind. Bei mir wurde immer nur eine Bezeichnung für den Hintergrund angezeigt. (Bei Höhenlinien wird in einem Mini-Popup die Höhe angezeigt, wenn der Pfeil darauf steht.) Sind die Pisten für das Gerät andere Objekte als Wege oder Höhenlinien? Viele Grüße Bodo signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Garmin-Karte mit Skipisten?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo alle, gibt es eine fertige Garmin-Karte auf der Skipisten dargestellt werden? Oder hat jemand schon eine geeignete Konfiguration, um eine solche Karte selbst zu generieren? Ich würde gern den Schwierigkeitsgrad (piste:difficulty) und die Nummer (piste:ref) erkennen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9RHskACgkQnMz9fgzDSqc3oACcD7f7lCkFTOz7W3sVHxDZEkKf SHYAniFjCXpVRwvJ5YGuJIR9ogawW8TD =VtHB -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verpixelung der Bing-Luftbilder, ausgezählt (beta 1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 02.02.2012 23:24, schrieb Johann H. Addicks: Eine Wikiseite mit Links zu den Bereichen wäre toll. http://wiki.openstreetmap.org/wiki/Bing/2012_Germany_Military_Blurring -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk8rD3wACgkQnMz9fgzDSqdWygCcDv3qUUeFnJoqHBIRP+pTH0hR Xy4An3E3G+ChqcQbif8EOzWz9hlYPWUK =ar/T -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Korrektur großflächiger Falsch-Ausrichtung an verzerrtem Luftbild (was: Kann man eine Liste von Changesets bekommen, die ein Gebiet betreffen?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.01.2012 11:15, schrieb Martin Koppenhoefer: Abgesehen von den technischen Möglichkeiten sollte man nicht aus dem Auge verlieren, dass manche der Modifikationen auch Verbesserungen sein könnten. Hallo Martin, in anderen Gebieten hat dieser User definitiv Verbesserungen gemacht, z.B. Verfeinerung von Küstenlinien. Deshalb möchte ich alles manuell prüfen. Gibt es bereits eine Möglichkeit, grafisch einen Vorher-Nachher-Vergleich eines Changesets zu bekommen? Falls nicht, könnte ich vielleicht das Reverter-Plugin für JOSM erweitern. Hier geht es um einen Bereich der bereits relativ umfangreich ist (Die rückgängig zu machenden Änderungen betreffen hauptsächlich die Position von Punkten, d.h. es betrifft potentiell die History von über 16000 Punkten.). Ich denke, ich komme über die Changesets des Users an die Menge der Punkte, die tatsächlich verschoben wurden. Die Anzahl habe ich genannt, um darzustellen, daß ein manueller Aufruf der History in JOSM nicht praktikabel ist. Ob es ein Problem ist, wenn ich die History von 16000 nodes und ein parr hundert ways per Skript abfrage, weiß ich nicht. Auch für Verbesserungen hast Du schon Beispiele angeführt: An einer Stelle habe ich gesehen, daß dieser User zweimal geändert hat, an einer anderen Stelle gab es spätere Änderungen, die darauf aufbauen. Beispiel: Die Kontur eines fehlerhaft verschobenen Gebäudes wurde verfeinert., daher ist ein komplettes Rückgängigmachen m.E. nicht angebracht. Da ist ja gerade die Schwierigkeit. Ich möchte die Nebenwirkungen eines Reverts auch in Ordnung bringen. In dem genannten Beispiel hat der fragliche User X das Gebäude und die darumliegenden Wege von der korrekten Position verschoben. Ein anderer User Y hat später Punkte zur Kontur des Gebäudes hinzugefügt. Wenn ich die Änderungen des Users X zurücknehme, muß ich die Punkte des Users Y anschließend manuell verschieben. Deshalb möchte ich mit Hilfe von Skripten oder wie auch immer Hinweise bekommen, an welchen Stellen ich prüfen und manuell nacharbeiten muß, und wen ich möglicherweise informieren sollte. Ich möchte aber nicht alle Wege, die ich mühsam in mehreren Jahren gezeichnet habe, wieder Punkt für Punkt manuell zurückschieben. Auch weiß ich nicht, ob der User möglicherweise Punkte gelöscht hat. Zugegebenermaßen sind solche Edits, wo OSM an ein bestimmtes Luftbild angepasst wird, (jetzt Bing, früher Yahoo) ziemlich lästig (ehrlich gesagt ist Bing teilweise noch auszuhalten, Yahoo war hierzulande richtig gruslig), aber vielleicht kann man ja den entsprechenden User motivieren, selbst mitzuhelfen? Die Korrektur möchte ich selbst machen, weil ich mich dort wirklich auskenne. In meiner zweiten Nachricht an diesen User habe ich angeregt, daß er sich in anderen Gebieten um eine Korrektur kümmern sollte, falls er woanders auch Objekte verschoben hat. Ich habe auch geschrieben, daß ich die unkritische Verwendung von Luftbildern aufgrund mangelnder oder schwer auffindbarer Information für die Ursache des Fehlers halte. Du könntest evtl. auch die Bounding Box hier pasten, wo die Änderungen drin sind, so dass man auf der ital. Mailing-Liste nachfragt, ob da jemand in letzter Zeit aktiv war. In meinem Fall handelt es sich um die Insel Giglio. Es sind aber vermutlich verschiedene Gebiete betroffen, nicht nur in Italien. Die Changesets dieses Users sind über Europa und Nordafrika verteilt. Ich hatte die Idee, über die Changesets herauszufinden, welche User ich kontaktieren sollte. Eine Diskussion auf der ital. Liste ist prinzipiell sinnvoll, weil dadurch die Mapper auf das Thema sensibilisiert werden (vor allem die neueren Mapper, ist nicht das erste Mal, dass man darüber schreibt). Zur Vermeidung von unkoordinierter Doppelarbeit ist es sicher eine gute Idee, auf der italienischen Liste darüber zu informieren, daß ich mich auf der Insel Giglio um die Korrektur kümmern möchte. @Martin: Es wäre gut, wenn Du das übernehmen könntest, denn ich kann nur wenig italienisch. Mein Username ist bomm. Falls jemand am meiner Ortskenntnis zweifelt, soll er meine hochgeladenen Tracks betrachten. Du kannst auch meine E-Mail-Adresse nennen für eine eventuelle Kontaktaufnahme. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk8cE7oACgkQnMz9fgzDSqe2swCglNi/cYXMQG5rr22K+7Ck469i KeQAoKWgCS9kejJ13M8dqwobaoMId3ua =qGiN -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Korrektur großflächiger Falsch-Ausrichtung an verzerrtem Luftbild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.01.2012 15:14, schrieb Martin Koppenhoefer: Am 22. Januar 2012 14:48 schrieb Bodo Meissner b...@bodo-m.de: [...] es gibt da den OSM History Viewer auf dem Fossgis server: http://osmhv.openstreetmap.de/ Danke, das ist genau das richtige. Ich würde visuell die Daten mit dem PCN abgleichen und dort nacharbeiten, wo es augenscheinlich schlecht passt, oder scharfe Kurven besonders eckig aussehen. Das wollte ich nur bei den Folgefehlern machen, wenn ich die Verschiebung rückgängig gemacht habe. Ist der andere auch ein Deutscher, oder in welcher Sprache schreibt Ihr Euch? Da seine Changeset-Kommentare deutsch sind, ist er zumindest deutschsprachig. In meinem Fall handelt es sich um die Insel Giglio. Es sind aber vermutlich verschiedene Gebiete betroffen, nicht nur in Italien. Ach so? Da habe ich in den letzten Tagen auch ein paar Punkte verschoben und ein bisschen landuse verfeinert. Durch die Verschiebungen gibt es teilweise auch Widersprüche mit dem Landuse, wenn beispielsweise ein Gebäude in einer Waldlichtung verschoben wurde, der Wald aber nicht. Viele Landuse-Bereiche basieren noch auf gröberen Luftbildern oder teilweise Schätzungen. Das wäre ja noch ein relativ überschaubares Gebiet. Etwas seltsam fand ich, dass praktisch alle Feldwege tracktype=grade2 waren, obwohl sie laut Luftbild ziemlich unterschiedliche Oberflächen zu haben schienen. Dort gibt es sicher noch Verbesserungsmöglichkeiten im Detailgrad. Die Entscheidung über tracktype ist etwas schwierig. Meistens sind es feste, leicht staubige Sandwege ohne Gras oder Pflanzen, die mit einem Fahrzeug befahrbar sind. Meiner Meinung nach passen weder die Bilder noch die Beschreibungen im Wiki so richtig zu diesen Wegen. Außerdem habe ich das im Urlaub eher nebenbei gemappt. Da habe ich keine Zeit für Notizen über die genaue Wegbeschaffenheit oder ständige Fotos. OK, ich schreibe eine Mail und informiere wie gewünscht, Danke. allerdings empfehle ich Dir, trotzdem in kurzen Abständen die Daten hochzuladen, weil aufgrund des Medieninteresses derzeit sicher noch mehr Mapper dort aktiv sind. Hoffentlich nicht nur solche, die die vorhandenen Objekte an ein Luftbild anpassen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk8cIxwACgkQnMz9fgzDSqevAwCeMjH/EpsxuR42HMByr9vZqZ5i 3lEAnROTZbCC39AAU4mu8VQCIigKtDOe =x019 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bei OSM History Viewer fehlgeschlagenen Auftrag neustarten?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.01.2012 15:14, schrieb Martin Koppenhoefer: es gibt da den OSM History Viewer auf dem Fossgis server: http://osmhv.openstreetmap.de/ Ich habe ein paar Changesets analysieren lassen und bei einem (Changeset 9486951) kam als Ergebnis nur Diese Analyse wurde am 2012-01-22T14:44:54Z erstellt. java.lang.Error: Timeout Wenn ich jetzt die Seite über Reload oder das Formular aufrufe, wird mir immer das gleiche Ergebnis geliefert. Dieses Changeset ist eines, das ich rückgängig machen möchte, aber vorher will ich prüfen, ob einige Änderungen erhalten bleiben sollten. Kann man irgendwie eine Neuberechnung auslösen? Oder wie lange muß ich warten, damit eine neue Berechnung versucht wird? Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk8cLYcACgkQnMz9fgzDSqd3HACglmo+ZsHlLAKhnlDFlWYpdAWr ohwAn2XJz7j6zhgmj/FckytUEtxhKM9i =aRzi -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kann man eine Liste von Changesets bekommen, die ein Gebiet betreffen?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo alle, ich möchte Änderungen rückgängig machen, die schon einige Zeit zurückliegen. In einem Gebiet in Italien hat ein User im Oktober 2011 Wege verschoben. Er kann sich nicht mehr an diese spezielle Änderung erinnern, aber meinte, daß er in der Regel die Wege an Bing anpassen würde. Ich habe dort viele Wege gezeichnet, überwiegend nach eigenen Tracks. Durch die gute Übereinstimmung mit den PCN-Luftbildern gehe ich davon aus, daß die Position der von mir gezeichneten Objekte relativ genau war. Jetzt liegt es an einigen Stellen deutlich versetzt und es sind Kurven entstanden, wo keine sind. Auf jeden Fall hat er das ohne Ortskenntnisse gemacht und ohne ordentliche Ausrichtung der Luftbilder. (Bei den Bing-Luftbindern [falls das wirklich die Quelle war] habe ich in diesem Bereich schon festgestellt, daß man den Versatz ziemlich oft anpassen muß.) Diese Änderungen möchte ich mit Hilfe des Reverter-Plugins in JOSM rückgängig machen. Die Schwierigkeiten dabei: An einer Stelle habe ich gesehen, daß dieser User zweimal geändert hat, an einer anderen Stelle gab es spätere Änderungen, die darauf aufbauen. Beispiel: Die Kontur eines fehlerhaft verschobenen Gebäudes wurde verfeinert. Ich denke, es ist sinnvoll, die Änderungen des betroffenen Users in umgekehrter Reihenfolge rückgängig zu machen und dann die darauf aufbauenden Änderungen manuell zu korrigieren. Die rückgängig zu machenden Änderungen betreffen hauptsächlich die Position von Punkten, d.h. es betrifft potentiell die History von über 16000 Punkten. Es wäre jetzt gut, wenn ich eine Liste sämtlicher Changesets (ab einem bestimmten Zeitpunkt) bekommen könnte und die zugehörigen User. Gibt es eine solche Möglichkeit? Damit könnte ich zum einen herausfinden, welche Changesets ich rückgängig machen möchte, und zum anderen, welche späteren Änderungen ich manuell überprüfen muß. Die normale History-Anzeige von JOSM ist da nicht geeignet, denn die erzeugt für jeden Punkt ein eigenes Fenster. Eine andere Möglichkeit wäre es, alle Changesets dieses Users zu betrachten, die den betroffenen Bereich enthalten. Leider sind die Changesets manchmal so großflächig, daß man dazu noch herausfinden müßte, ob davon Objekte im betrachteten Gebiet betroffen sind. Damit bekomme ich aber keine Information, wo danach noch von anderen Usern etwas geändert wurde. Was gibt es da für Möglichkeiten? Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk8a6xgACgkQnMz9fgzDSqcYUACeLjRoZ++MFXUshIuYU4WrMJ7g I2AAn04QUYtl3+TRpKhZUYC0L+OYUe+P =k8kp -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kann man eine Liste von Changesets bekommen, die ein Gebiet betreffen?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.01.2012 00:14, schrieb Frederik Ramm: Das geht mit OWL: http://matt.dev.openstreetmap.org/owl_viewer/ Hallo Frederik, danke für den Hinweis, aber das ist nicht ganz so, wie ich es mir vorgestellt habe. Das ist (momentan) langsam, die Tiles sind viel zu klein, und es zeigt mir alle Objekte an. Damit wird die Ausgabe zu groß und zu unübersichtlich. Ich habe es schon mit /api/0.6/changesets versucht, aber das liefert max. 100 Ergebnisse. Wenn ich nur ein Startdatum angebe, sind das wohl die neuesten Changesets. Das heißt, ich müßte da eine Schleife bauen, die jeweils einen Block abfragt, das closed-Datum des ältesten Eintrags liest und daraus die Abfrage für den nächsten Block baut, bis ich alles habe. Durch Angabe von display_name habe ich schon festgestellt, daß es 7 Changesets des Users gibt, die das betroffene Gebiet (möglicherweise) enthalten. Ich stelle mir jetzt folgenden Ablauf vor: manuelle Prüfung, welche dieser Changesets tatsächlich schädliche Änderungen im betrachteten Gebiet enthalten Generieren einer Liste der darin geänderten Objekte bilde Ermitteln aller späteren Changesets mit o.g. Schleife Auflisten der Changesets, die ebenfalls Objekte der Liste enthalten, ggf. auch Auflisten der betroffenen Objekte Wenn ich das alles erst implementieren muß, wird es doch wesentlich aufwendiger, als ich gedacht hatte. Alternativ könnte ich einfach die Changesets rückgängig machen und dann nur die Folgefehler korrigieren, die mir (oder JOSM) auffallen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk8baEcACgkQnMz9fgzDSqesygCgk5qbADjVuTzM1fb9NiEvuUzc zSYAnj2XwmJBwbQ20m6bRAg4CEv3P5jJ =ylrG -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Weg auf Insel Giglio (was: Die spinnen die OSMler ;)
On Fri, Jan 20, 2012 at 01:20:59AM +0100, Wolfgang Barth wrote: Da auf Giglio ist im Osten ein path eingezeichnet zwischen der Südspitze und dann an der östlichen Küste vorbei zum Hafen. Ich hatte wirklich geglaubt, daß es den gibt. Vor drei Jahren wollten wir dem folgen und wir haben uns zu zweit für etliche Stunden durch die weglose Macchia gequält, bis wir die ersten Häuser erreichten. Zerschunden und erschöpft erreichten wir die letzte Fähre auf das Festland. Hallo Wolfgang, die meisten Wege auf Giglio habe ich kartiert und bin diese auch wirklich gegangen. (Laß Dir mal die hochgeladenen GPS-Tracks anzeigen.) Wenn sich niemand um die Wege kümmert, sind die aber ziemlich schnell wieder zugewachsen. (Da bräuchte man einen lokalen Mapper, der regelmäßig den Zustand der Wege aktualisiert.) Der beschriebene Weg geht von der Südspitze zur Cala dei Fiori / Cala degli alberi / Pardini´s Hermitage das größte Stück unter der Stromleitung entlang und trifft dann auf den Weg, der von Castello kommt. Der Weg weiter zum Strand Caldane ist teilweise schwer zu finden und muß einige Privatgrundstücke umgehen. Im letzten Jahr fehlten an einer Stelle, wo es dicht am Meer entlanggeht die hölzernen Leitern. Ab der Caldane-Bucht ist der Weg dann wieder besser. Ich bin den Weg ab Cala dei Fiori erstmalig gemeinsam mit zwei Italienern gegangen, die eine Papierkarte hatten, auf der der Weg eingezeichnet war. Sah aus wie eine Alpenvereins- oder vieleicht Militärkarte. Falls es Dir noch nicht aufgefallen ist: Der auf einigen Karten oder Informationstafeln noch eingetragene Weg von Castello zur Südspitze ist bei OSM nicht eingezeichnet. Ich habe einmal versucht, diesen ehemaligen Weg zu finden, gemeinsam mit dem Mann, der auf der Insel für das Ausschneiden der Wege zuständig ist. Ich glaube diesen Track habe ich auch hochgeladen, das liegtt aber nur am Anfang in der Nähe des ehemaligen Weges. Dann haben wir nur noch versucht, irgendwie durchzukommen. Der Weg vom Sasso Ritto in Richtung hinunter zum Weg unter der Stromleitung ist nicht offiziell, den hatte uns ein Einheimischer beschrieben. Der war nur durch Steinmännchen gekennzeichnet und wächst auch zu. Man darf offensichtlich solchen Wegen nicht unbesehen folgen, auch wenn sie in einem Internetforum als relativ problemlos beschrieben sind. Weißt Du noch, wo der Weg beschrieben ist? Viele Grüße Bodo signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fährlinien
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.01.2012 14:59, schrieb Falk Zscheile: Am 6. Januar 2012 07:00 schrieb Jan Jesse j...@jesse.de: - Wo ist es Tief genug, daß ich da lang fahren kann - Wo muß ich mit schnellem, u.U gefährlichem Schiffsverkehr rechnen Doch, diese Routen sollten gelöscht werden. Dafür gibt es aus meiner Sicht gleich mehrere Gründe: 1. Fähr- und Ausflugsrouten sind keine Tiefeninformationen. [...] 2. Auch der Schluss von da fährt eine Fähre, dort ist es also tief genug ist mehr als fahrlässig, wenn man den den betreffenden Tiefgang der Fähre nicht kennt. [...] Die mögliche falsche Nutzung von Informationen ist kein Grund, diese zu löschen. Der zweite Punkt, daß auf der Route einer Ausflugslinie mit Schiffsverkehr zu rechnen ist, ist doch korrekt. (Der Umkehrschluß, daß daneben weniger Schiffsverkehr ist, ist allein damit natürlich nicht zu begründen.) 3. Mir ist der Mehrwert von Ausflugslinien in einer Karte/Datenbank unabhängig von deinem Argument noch nicht klar geworden. Es gibt viele Dinge, die für einen Großteil der Nutzer nicht relevant sind. Auch das ist kein Grund für eine Löschung. Für jemanden, der mit der Ausflugslinie fahren möchte, ist die (ungefähre) Route des Schiffs sicher eine nützliche Information. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk8HCwwACgkQnMz9fgzDSqf/HACfau4VEGQvVutdUPI7oswtmQjC b+kAnRhdr1sT6eTp9C61tCbRtmqsXWwO =XHDO -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf BILD.de
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 17.08.2011 06:23, schrieb Thomas Reincke: Am 17.08.2011 00:39, schrieb Michael Kugelmann: sogar mit Attribution. :-) und Lizenzhinweis. Das scheint aber eine Leistung von Stepmap zu sein. Der Link bei der Bildzeitung führt zu dieser Seite. http://www.stepmap.de/karte/bild-drei-maedchen-tot-im-wald-162049 Dort gibt es übrigens auch eine fast gleiche Kartengestaltung mit dem Fokus-Logo. Leider ist auf der Karte nur das Stepmap-Logo ein Link, die Bezeichnung OpenStreetMap und die Lizenz sind nur Grafik. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk5LYEoACgkQnMz9fgzDSqetnQCfR8xTBcrhAbokzWV9L274zPsg ZXkAoJbnZOQ3vjldSRNDAeoYCBXeTTJy =s8nW -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeichenstil
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 12.08.2011 22:34, schrieb Christian Müller: Am 12.08.2011 21:53, schrieb Albrecht Will: Aus einer Fehlermeldung fürs Hochladen: Zeichenstil für innere Linie mit Multipolygon identisch Der Text dieser Meldung ist etwas verwirrend bzw. nichtssagend, es sei denn, man weiß, was damit gemeint sein soll. Objekte in der Datenbank haben keinen Zeichenstil bzw. ein Zeichenstil hängt vom Renderer ab und kann für Objekte mit unterschiedlichen Tags auch identisch sein. Grundsätzlich sollten Löcher in Vielecken (eine innere Linie ist Grenze eines Lochs im Polygon) andere Tag-Werte haben, als das äußere Vieleck des Multipolygons - denn nur dann macht es i.d.R. Sinn, ein Loch zu erfassen. Diese Bedeutung der Fehlermeldung ist IMHO nicht erkennbar. Vielleicht wäre es besser, anstelle von Zeichenstil das Wort Eigenschaften zu verwenden: Eigenschaften der inneren Linie mit Multipolygon identisch Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk5GLJYACgkQnMz9fgzDSqevIgCeJd9mJFOc8091zBpd76LVPq3x YHIAn3I3X9mP/RK3vF3QryrxLeGAtm2d =lLUl -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutzgebiet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.07.2011 12:21, schrieb René Falk: Am 26.07.2011 12:02, schrieb bkmap: Am 25.07.2011 20:09, schrieb Michael Bemmerl: Wie wär's mit access=no? Wenn aber Wege im Gebiet verlaufen, die betreten werden dürfen, was hat dann Vorrang? Das Gebiet oder der Weg? Normalerweise sollte die spezifische Information immer Vorrang vor der allgemeineren haben, also ein Weg mit access=yes in einem Gebiet mit access=no wäre für mich benutzbar. (Vorausgesetzt, das access=no an einem Gebiet wird ausgewertet.) Zum einen gibt es bei Naturschutzgebieten immer eine begrenzte Gruppe von Menschen, die diese betreten dürfen. Das Betreten wäre daher eher erlaubnispflichtig. In den meisten Fällen, wo das Betreten/Befahren für die Allgemeinheit verboten ist, gibt es eine begrenzte Gruppe von Leuten, die das trotzdem dürfen. (Sonst wäre an der Stelle wahrscheinlich gar kein Weg.) Ich denke nicht, daß man diese Tatsache extra notieren muß. Die Berechtigten wissen schon, daß sie das dürfen. Als erlaubnispflichtig würde ich eher etwas eintragen, wenn alle/viele prinzipiell die Möglichkeit haben, eine Erlaubnis zu bekommen, beispielsweise gegen Gebühr. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4vL7IACgkQnMz9fgzDSqfKaQCeKPv4gcmRMEC17ml2nhVzjime XQcAnilS3cDu5vYeT+IrzAvob/5olZuh =W/QN -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Offnungszeiten-Auswertung (was: Postkästen-Leerungszeiten-Kontrolle)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 17.07.2011 02:31, schrieb Garry: Vielleicht ist mir was entgangen... Aber gibt es überhaupt eine braubare Auswertung dafür? Bei meiner letzten Dienstreise stand ich kurz vor 20 Uhr vor dem Problem einen Supermarkt o.ä. zu finden um noch ein paar Besorgungen zu machen. Ich wäre froh gewesen eine Anwendung zu haben die in der Lage ist mir zu sagen welcher Lebensmittelmarkt in welcher Entfernung auf hat. Ist vielleicht noch nicht ganz das, was Du Dir vorgestellt hast: http://www.netzwolf.info/kartografie/osm/time_domain/map_opening?zoom=17lat=49.79543lon=9.93238layers=B00T Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4iixgACgkQnMz9fgzDSqeySACeJ9GU0QKUh2N/DtRLixFoY+6O Vh4AnRW6U+NWqcjVilpYvJL776w2O9ae =kaPY -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 15.07.2011 20:07, schrieb Wolfgang: Am Freitag, 15. Juli 2011 15:11:28 schrieb fly: Am 15.07.2011 13:58, schrieb Henning Scholland: Der Ansatz, das Objekt mit zusätzlichen Tags komplexer zu machen ist kontraproduktiv. - -1 (siehe unten) Was ihr möchtet sind aktuelle Infos. Die erhält man, wenn viele Mapper sich daran beteiligen und Veränderungen eintragen. Das ist klar, ist aber unabhängig davon. Die Editoren sind bereits kompliziert und werden jeden Tag komplizierter. Da spielt ein einzelnes, verständliches tag keine Rolle mehr. Wer Angst hat, etwas kaputt zu machen, wird sich so sowieso nicht beteiligen. Gerade der Ansatz foo=bar foo:last_check=20110716 (o.ä.) kann doch wunderbar vom Editor ausgewertet werden. (Sofern das Datumsformat eindeutig ist.) Wenn die Tags paarweise auftreten, kann der Editor die *:last_check-Tags unterdrücken und als Zusatzinformation am zugehörigen Haupt-Tag anzeigen. Beim Hinzufügen oder Ändern eines Wertes könnte der Editor das Datum automatisch ergänzen. Zusätzlich könnte der Editor die Tabelle der vorhandenen Tags um Checkboxen ergänzen, bei denen der Anwender einfach ein Häkchen setzen kann, daß der Wert noch aktuell ist. (Optional kann man auch ein älteres Datum eintragen, falls die Daten nicht am gleichen Tag gepflegt werden.) Also könnte man das für den Anwender sehr einfach unübersichtlich machen. Eine tolle Sache um euer Ziel zu erreichen wäre bspw. ein Routenplaner, der entlang der Route ein paar Punkte vorschlägt, die man überprüfen kann und man dafür Punkte für einen Highscore erhält. Auch für einen solchen Routenplaner wäre die vorgeschlagene Kennzeichnung hilfreich zur Auswahl der zu prüfenden Objekte oder zur Score-Festlegung. Ich bleibe dabei, dass ich einen solchen tag für sinnvoll halte. Niemand wird gezwungen, sich daran zu beteiligen. +1 Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4hMT4ACgkQnMz9fgzDSqd3iwCfSaEQuowaK042eyIoUpAzD3nc SbAAn0Sa7zn2IkbOisDXnQjiHXoajTzi =Gxic -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.07.2011 09:18, schrieb Peter Wendorff: Am 16.07.2011 08:35, schrieb Bodo Meissner: [...] Beim Hinzufügen oder Ändern eines Wertes könnte der Editor das Datum automatisch ergänzen. Bitte nicht. Wenn ich einen Rechtschreibfehler finde (z.b. highway=resedential) oder einfach nur ohne Wissen über die tatsächlichen Fakten das Format der opening_hours korrigiere, weil wieder jemand deutsche Wochentage benutzt hat, dann ist das eben kein last_checked, sondern einfach eine Syntaxkorrektur. Stimmt. Mein Vorschlag ist sicher noch nicht ausreichend durchdacht. Es ist nicht sinnvoll, wenn beim manuellen Eintragen von Schlüssel und Wert automatisch zusätzliche Tags generiert werden. Hintergrund meiner Idee war es, dem weniger versierten Mapper die Arbeit möglichst einfach zu machen. Wenn der zu jedem Wert immer noch ein Häkchen setzen muß, um das Datum der Datenerhebung einzutragen, macht es mehr Arbeit. Dieser Mapper wird sich vielleicht weniger um das Korrigieren von Syntaxfehlern kümmern. Vielleicht braucht man einfach eine Konfiguration, um zu wählen, ob der Editor standardmäßig das Datum ändern soll oder nicht. Vielleicht wäre eine automatische Eintragung des Aktualitätsdatums sinnvoll, wenn man mit Presets bzw. einem speziellen Öffnungszeiten-Editor o.ä. arbeitet. Wenn der Editor das automatisch als überprüft setzt, haben wir nichts gewonnen gegenüber den Changeset-Informationen zum Änderungsdatum. Nur eine leichtere Auswertemöglichkeit, wann welches Tag geändert wurde. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4hQKAACgkQnMz9fgzDSqe6rACePg1D3qBqKpDDQp8RJhr0qJMT SfkAn0T6yAehxl5BchFx2J+XedgzruwC =ndW1 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Postkästen-Leerungszeiten-Kontrolle
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.07.2011 14:24, schrieb Jan Tappenbeck: es macht ja auch sinn Postkastenleerungzeiten zu kontrollieren. Ein Tag habe ich noch nicht gefunden - was halltet Ihr von last_check = 2011-07-12 ?? Die Tag-Bezeichnung finde ich zu allgemein. Ich würde es entweder so spezifisch machen, daß eindeutig klar ist, was da genau geprüft wurde, oder die Information einfach als note schreiben. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4fAR0ACgkQnMz9fgzDSqdtBwCfTwQp2ECWN2QwgUCsoGe0+Z2T 8R0An3mwzijuz0CRiETDUXnw6JZ67rc9 =b9/l -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kinderwagenfreundliche Wanderwege finden
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Thomas, da jetzt geklärt ist, daß es unbedingt ein Kinderwagen sein muß, kommen wir mal zurück zum ursprünglichen Thema. Ich nehme mal an, Deine Idee war, irgendwie eine Karte auf das Handy zu bekommen, auf der Du kinderwagentaugliche Wege erkennen kannst. (Wie man Karten für Dein Handy erzeugt, damit kenne ich mich nicht aus.) Ich bezweifle, daß ein Handy-Display oder das Routing auf dem Handy für eine Tourenplanung ausreicht. (Ich denke da an mein Garmin 76CSx. Entweder ich habe einen ausreichend großen Bereich auf dem Display, dann fehlen aber die kleineren Straßen und Wege, oder ich habe einen zu kleinen Ausschnitt mit genügend Details.) Deshalb kann ich mir das nur am PC oder in Verbindung mit einer Papier-Karte vorstellen. Eine entscheidende Frage ist: Wie definierst Du einen kinderwagentauglichen Weg? Ich könnte mir vorstellen, daß Wege mit highway=track und tracktype=1 oder tracktype=2 prinzipiell geeignet sind. Weitere tracktype-Werte ggf. je nach Art des Kinderwagens. Es gibt in der Gegend aber auch highway=track ohne tracktype-Angabe. Bei highway=path ist es noch schwieriger, weil Breite und Wegbeschaffenheit kaum erfaßt wird. Steigung oder Gefälle ist ein weiteres Problem. Ich nehme aber an, daß die meisten gut befestigten breiten Wege (Feld- und Forstwege) von der Steigung her geeignet sein könnten, denn da können meist auch Autos fahren. Wenn die Karte Höhenlinien enthält, kann man vielleicht die Steigung auf der Karte erkennen. Wenn Du eine Entscheidung für geeignete Kriterien hast, kannst Du vielleicht ein Werkzeug zur Erzeugung von Karten so einstellen, daß die gewünschten Wege von den anderen unterschieden werden können. IIRC kann man beim OSM-Composer einstellen, wie verschiedene Wegarten dargestellt werden sollen. (Keine Ahnung, ob das Ergebnis für Dein Handy verwendbar ist.) Unabhängig von den kinderwagentauglichen Wegen solltest Du Dich mal informieren, welche Möglichkeiten es gibt, Karten auf Dein Handy zu bekommen, und ob/wie man speziell ausgewählte Wege hervorheben kann. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4dqdUACgkQnMz9fgzDSqccHwCfQEW9Q3cFOG7agV4lI8g3HM7v AxYAmwRiALQ9RzebPVmLOy9Ll1XVIyC1 =QBLU -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kinderwagenfreundliche Wanderwege finden
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 04.07.2011 21:42, schrieb Thomas Güttler: Wie kann man per OSM kinderwagentaugliche Wege finden? Je nach Art des Kinderwagens möglicherweise nur highway=track mit tracktype = x oder möglicherweise auch highway=path oder footway mit ausreichender Breitenangabe. Vielleicht ist die Unterscheidung der Wegarten auf der Wanderreitkarte für diesen Zweck geeignet. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4SPWcACgkQnMz9fgzDSqcVAQCgm3NizMrssIOn6IZfw58/F+1L RpgAn00NMpJGHanDyXR0ECbAKcKTjD55 =fNfC -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] radlkarte.at
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.06.2011 08:53, schrieb Manuel Reimer: Wenn du in einem zweiten Schritt Deutschland mit in die DB nehmen könntest, wäre natürlich klasse. Erweiterungen der Bereichs sind immer gut. Unabhängig davon schlage ich vor, nicht an der österreichischen (oder ggf. der deutschen) Grenze aufzuhören, sondern auch einen vernünftigen Bereich drumherum ebenfalls darzustellen. Beispiel: http://www.radlkarte.at/?zoom=13lat=47.57062lon=10.5205layers=B000T Hier wäre es nützlich, den weißen Bereich (Pfronten) zu füllen, damit die Verbindung von Vils über das Engetal nach Grän oder über das Vilstal nach Schattwald vorhanden ist. Wenn Du für Radler relevante Gefahrenstellen aufnehmen möchtest, würde ich Weideroste darstellen, z.B. im o.g. Bereich Straße L261 im Engetal http://www.openstreetmap.org/browse/node/307921404 Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk4MbC0ACgkQnMz9fgzDSqeMmACfQelWe3wPQJDfQMeR8MtTpuMy ZUUAn0ZQkODdufteQlfvre70DPIwHyGh =Kvea -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problematik der Ortsnamenzusätze
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.06.2011 16:32, schrieb Igor Podolskiy: Irgendjemand, der in Montabaur wohnt, weiß, um welches Limburg es sich handelt, der sagt dann auch immer Limburg. Irgendjemand aus Passau oder London würde vielleicht an der Lahn interessieren. Also muss es auch die Anwendungen interessieren, die diese Leute benutzen. Natürlich ist die Information Limburg an der Lahn wichtig, es kann aber für die Darstellung auf einer Karte sinnvoll sein, den Teil an der Lahn wegzulassen oder kleiner darzustellen. Woher soll die Software aber wissen, welcher der Kern-Teil ist bei name=Limburg an der Lahn und name=Hansestadt Hamburg? (bzw. Freie und Hansestadt Hamburg) Mit einer Kombination name=Limburg, name:suffix=an der Lahn und name:prefix=Hansestadt, name=Hamburg wäre das wesentlich einfacher. Und die Zusammensetzung name:prefix+ +name+ +name:suffix ist in den meisten Fällen auch einfach. (aber s.u.) de:Frankfurt am Main - Transliteration - ru:Франкфурт-ам-Майн (falsch) de:Frankfurt am Main - Übersetzung - ru:Франкфурт-на-Майне (richtig) Also bräuchtest du ein name:suffix:ru, wenn du tatsächlich name=Frankfurt und name:suffix=am Main hinschreibst. Und die Bindestriche gehören im Russischen anders als im Deutschen wirklich dahin. Frankfurt ist nicht Hintertupfingen, da kannst du nicht sagen wer das anders als in Deutsch lesen will, hat Pech gehabt. Das erschwert das Zusammensetzen etwas, weil man einmal ein Leerzeichen einfügen muß und einmal nicht. Vermutlich lassen sich (sprachabhängig) Regeln definieren, bei welchen Zeichen das Leerzeichen entfällt. Ich will übrigens gar nichts aufbrechen :) Im Gegenteil, ich bin mit name=Limburg an der Lahn vollkommen zufrieden. Die Software-Entwickler wahrscheinlich nicht. Die Trennung wäre nicht nur für den Renderer nützlich, sondern auch für einen Suchalgorithmus. So könnte der Anwender wählen, ob er das Suchmuster nur im Kern oder auch im Präfix oder Suffix suchen möchte. On 08.06.2011 14:02, Walter Nordmann wrote: Entweder muss die Software den zerstückelten Namen wieder zusammensetzten, wenn sie den vollständigen Namen haben will oder sie muss den vollständigen Namen irgendwie zerstückeln wenn sie den Kern-Namen haben will; da ist mir ersteres wegen der einmaligen manuellen Bearbeitung 1000x lieber als ein Rumgerate der Software +1 Manuelles Zerstückeln und automatisches Zusammensetzen ist wesentlich einfacher als umgekehrt. Wenn man das einmal umstellt, würde die Software vorläufig nur den Kern-Namen anzeigen, bis sie entsprechend angepaßt ist. Mir ist es als Mapper lieber, eine einfache Regel zu haben, wo ich nicht jedes Mal im Wiki nachschauen muss und nachgrübeln muss, was jetzt der Zusatz ist und was nicht. Und als Anwendungsentwickler ist es mir lieber, eine (eventuell regional angepasste) Heuristik für _einen_ Tag zu entwerfen, als x Heuristiken für y Kombinationen aus z Tags für all die unterschiedlichen Variationen von der Sichtweise, was jetzt ein Zusatz ist und was nicht, die bei solchen Sachen unweigerlich aufkommen. Ich gehe davon aus, daß Du das in den meisten Fällen nach Gefühl richtig eintragen kannst und nur in Ausnahmefällen die Regeln lesen müßtest. Bisher stelle ich mir die Entscheidung recht einfach vor: Welche Bezeichnung würde ich auf einer Karte erwarten, wenn der Platz knapp ist? Das wäre der Name. Alles davor ist Präfix, alles danach Suffix. Oder hast Du ein Beispiel für einen schwierigen Fall? Wohlgemerkt: ich habe nichts gegen alternative vollständige Namen (alt_name, old_name, name:alternative, name:official, name:$YOUR_QUALIFIER, ...), nur Bedenken gegen das Zerstückeln. Einmal vollständig und einmal nur der Hauptteil wäre auch möglich, ist aber etwas redundant und hat IMHO mehr Fehlermöglichkeiten. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk3v3+YACgkQnMz9fgzDSqcDmACcCE3uSS8cR3Ll7dHvPBYQ1IIc 5Y8AoKJJdV5+swdDEBnoz3/SqheqP2tM =zlyn -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.04.2011 01:22, schrieb Felix Hartmann: Das würde mit CCBYSA und dem DRM verbot durchs Share Alike halt anders aussehen. Glaube ich nicht. Ich könnte das übersehen haben, weil die vollständigen Lizenztexte ziemlich unübersichtlich sind. Wo genau steht bei CCBYSA das DRM-Verbot? Wenn ich dem Käufer erlaube, die Karte unter CCBYSA weiterzugeben, die Daten aber nur auf einem bestimmten Gerät nutzbar sind, habe ich dann formal die Lizenz eingehalten? Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk28I3MACgkQnMz9fgzDSqez+QCfbufUG1d2Qcj5W+yCPTujsTWm 3J8AoIlZaWgac2LzhsCugmuipFARPwQW =TaMe -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.04.2011 15:33, schrieb Ulf Lamping: Sobald sich jemand hinsetzt und ein Tool schreibt, mit dem .img nach .osm Dateien gewandelt werden können, ist das Thema auf einmal für alle OSM Garminkarten ganz konkret. Gerade dadurch das dieses .img Format bekannt ist, ist das auch keine rein hypothetische Möglichkeit und könnte durchaus in kürzester Zeit Realität werden. Diese Möglichkeit gibt es bereits. Mit GpsMapEdit kann man .img-Dateien öffnen und als .mp speichern und daraus bekommt man mittels mp2osm eine .osm-Datei. (Zur Automatisierung des Schritts .img - .mp gibt es ein Skript ConvertToRus.) Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk28JHYACgkQnMz9fgzDSqdp8gCgjp2NUXpg6qoUDCF91m4kERPC 7/gAn1dJMlA3agmoG7pDwEAo8WIRfdIW =1xTV -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ICE-Relationen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 17.04.2011 17:31, schrieb Toni Erdmann: Ich die Debatte über Gleis 8 oder 13 nicht nachvollziehen. Denn die Bahn hat ja Pläne (auch wenn das keine Fahrpläne mehr sind sondern reine Absichtserklärungen). Und auf den Plänen stehen Ankunfts- und Abfahrtsbahnsteig - und die kann man für die Relationen benutzen. Auf irgendetwas müssen sich die Fahrgäste doch noch verlassen können. Klar hat die Bahn Pläne und im Normalfall halten die Züge auch am vorgesehenen Bahnsteig. Als Fahrgast würde ich mich aber eher auf die Fahrplanauskunft der Bahn, den Ausdruck vom Fahrkartenschalter oder -automaten bzw. den Abfahrtplan am Bahnhof verlassen, als darauf zu vertrauen, daß solche Angaben in OSM vorhanden und aktuell sind. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2rRQEACgkQnMz9fgzDSqcXhACgoJoOkeVwGEFQvX5kEMa1Jz2B vLsAnj/fsWhcyuQU4g4yEzCtbQPKaJtr =VAUC -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fehlermeldung OLM 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Alex, beim Ausprobieren der Karte habe ich einen Fehler produziert. Ich habe in der Gegend von Füssen ein paar Links ausprobiert, unter anderem den Link für den Gleitschirm-Startplatz Tegelberg. Bei mir geht jetzt das Popup für diesen Punkt nicht mehr weg. Ich kann weitere Popups öffnen und schließen. Wenn ich auf das rote X beim Popup Tegelberg (Startplatz) klicke, verschwinden nur die anderen, aber dieses nicht. Herausschieben aus dem sichtbaren Bereich half auch nichts. Erst nach dem Neu-Laden der Seite ist das Problem wieder weg und läßt sich (natürlich) nicht reproduzieren. Ich konnte das Phänomen einmal an einer anderen Stelle (Innenstadt Kempten) reproduzieren, aber nicht wiederholbar. Dort trat es auf, nachdem ich bei einem Link auf Mehr Infos geklickt hatte. Keine Ahnung, ob es etwas mit bestimmten Link-Objekten zu tun hat oder mit dem Ablauf, was ich gemacht habe. Ich benutze Firefox 3.6.16 unter Ubuntu 10.04.2 LTS. Und noch ein Verbesserungsvorschlag: Bei diesem Punkt http://www.openstreetmap.org/browse/node/663623454 ist mir aufgefallen, daß man manchmal nicht feststellen kann, worum es sich überhaupt handelt. Das Symbol auf der Karte -sofern vorhanden- wird durch die Link-Markierung überdeckt und ist deshalb in einigen Fällen nicht erkennbar. Oft kann man es aus dem Zusammenhang wie dem Namen, der Homepage-Adresse oder dem Wikipedia-Text entnehmen, aber bei einigen Objekten muß man die Details bemühen oder die Homepage aufrufen, um zu sehen, was es ist. Vielleicht wäre es sinnvoll, den Haupttag (z.B. Telefon, Restaurant, Laden, ...) darzustellen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk2arJYACgkQnMz9fgzDSqeZAgCfZ0msrU5oWt7TXKOzKHE7hw/p meMAoIwWNfJrHIcDIdRIDi6pHhkytTeT =ynyH -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Where a place has no name ....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.03.2011 18:43, schrieb M∡rtin Koppenhoefer: Am 5. März 2011 20:23 schrieb Rainer Kluge rklug...@web.de: Ich vermute mal, er möchte diese Punkte dann entweder löschen oder mit einem Namen versehen. soweit kann ich ja noch folgen, nur: wo bekommt Jan die Namen her? Vielleicht will er seinen nächsten Spanien-Urlaub entsprechend den fehlenden Ortsnamen planen. ;-) Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1zyhcACgkQnMz9fgzDSqfR6wCeKPXQq8qa0Ll0xI+ZWBSmGy3v eB4AnRL+Sk8VSxVDo5LE3+thJyBlgxq/ =HFQw -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohngebäude und Nebengebäude korrekt taggen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 27.02.2011 22:08, schrieb M∡rtin Koppenhoefer: so siehts aus. building=apartments ist eine Typologie, die man in einem Dorf nicht finden wird. ... die man in einem Dorf weniger finden wird. Ein paar Beispiele: http://en.wikipedia.org/wiki/File:Central_Park_during_Autumn,_NYC.jpg http://en.wikipedia.org/wiki/File:Sg_woodlands_a7_01.jpg http://en.wikipedia.org/wiki/File:Apartmentingurgaon.JPG Solche Häuser gibt es in einem Dorf natürlich nicht, aber auf dieser Seite http://en.wikipedia.org/wiki/Apartment gibt es ein Bild Garden apartments in Seattle, Washington, United States, was ähnlich auch in einem Dorf vorkommen könnte. Ich kenne in meinem Dorf zwei Häuser, in denen mehrere abgeschlossene Mietwohnungen enthalten sind. Die würde ich als building=apartments einstufen. Ich glaube nicht, daß man das ohne Ortskenntnis von anderen größeren Häusern unterscheiden kann. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1qxuEACgkQnMz9fgzDSqeu3wCcDuAVXF6oUirC5BDGLdb7+53S tAgAn0WLcumwtR44Wp6SE+A5ir0s8QmH =o0j+ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.02.2011 22:29, schrieb Stephan Knauss: Ich habe das mal direkt in der Karte in der Infobox mit dazugeschrieben, dass es nur für SEA funktioniert. Das SEA konnte ich aber auch erst nach dem weiteren Lesen dieses Threads interpretieren. (Die Karte deckt nur das Meer ab?) Vielleicht solltest Du es besser ausschreiben. Sollte ich den Rest der Welt ohne Abdeckung ausgrauen? Wäre sicher sinnvoll. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1i3p0ACgkQnMz9fgzDSqfX4gCeNGD2107VBlEOeacgvs9KhUB9 R00An10dAjvIqFgjSqR6CTLWjAEjwNn9 =KvPi -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werte in OSM besser ohne Einheit (war: BHKW)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.02.2011 04:03, schrieb Ulf Lamping: Am 14.02.2011 03:02, schrieb Frederik Ramm: Grundsaetzlich finde ich, dass der Editor dem Mapper da nicht dazwischenfunken sollte. Das ist gut für jemanden der weiß was er tut und schlecht für jemanden der sich nicht so auskennt oder sich nicht erinnert und erst nachschauen muß. Unterstützen darf der Editor ja gern. Der kann ja verschiedene übliche Einheiten anbieten, und trotzdem die Möglichkeit bieten, auch andere Werte einzutragen. Ich kann jetzt kein prinzipielles Problem erkennen sich auf kW (oder sogar W) zu einigen. Außer vielleicht, daß GW in W ausgedrückt ein wenig unhandlich wird. Aus meiner Sicht macht das letztlich allen Beteiligten das Leben leichter. Nur nicht dem Mapper, der genau die Angabe vom Schild eintragen _und_bei_einer_Überprüfung_auch_wiederfinden_ möchte. Auch wenn ich das keinem hier unterstellen möchte, gibt es Leute, die Schwierigkeiten mit Umrechnungsfaktoren haben. Bei den Zahlenwerten gehe ich davon aus, ja. Die Einträge mit unknow und fixme machen die Verarbeitung allerdings schonmal nicht leichter. Bei 550V ist die Angabe V nun wirklich redundant. Die Werte, die kleiner 10 mal vorkommen hast du gnädig unter den Tisch fallen lassen, erfahrungsgemäß lauern hier die wirklich üblen Sachen. Diese Werte sollten dann bei der Vorverarbeitung auffallen, so daß man sich Gedanken machen kann, ob man die korrigiert oder als ungültig betrachtet. Gerade solche Probleme werden aber nicht durch die Festlegung einer bestimmten Einheit gelöst. Jetzt kannst du natürlich sagen: Alles unter 10 mal interessiert mich nicht, allerdings fehlen damit laut long tail sehr viele Werte die man eigentlich schon auch haben möchte - gerade bei einer special interest map. Und da geht dann die Arbeit erst so richtig los - mit SQL möchte ich sowas nicht lösen müssen. Warum klammert Ihr Euch so an SQL? Wer kann denn beliebige Abfragen auf die Original-OSM-Datenbank ausführen? Wenn es eine eigene DB ist, kann man doch die Daten beim Kopieren aus der OSM-Quelle beliebig normalisieren. 1453 tag k=voltage v=38/ 117 tag k=voltage v=380/ Wenn ich solche Werte ohne Zusammenhang betrachte, wäre ich mir nicht sicher, daß mit 380 wirklich 380V gemeint ist und nicht 380kV. (Nach dem Motto: Das ist eine Hochspannungsleitung, hier ist nur kV sinnvoll.) Auch hier würde eine Einheit helfen. Selbst wenn man sich auf eine Einheit geeinigt hat, hätte das hinzufügen einer Einheit in der DB außer der Platzverschwendung keinen Nachteil. Das könnte ja auch der Editor automatisch hinzufügen. Viele Grüße Bodo 110 tag k=voltage v=38;22/ 100 tag k=voltage v=33/ 92 tag k=voltage v=50/ 91 tag k=voltage v=65000/ 89 tag k=voltage v=11000/ 67 tag k=voltage v=33000/ 64 tag k=voltage v=38;22;11/ 60 tag k=voltage v=3/ 49 tag k=voltage v=6/ 46 tag k=voltage v=0/ 38 tag k=voltage v=22000/ 35 tag k=voltage v=fixme/ 34 tag k=voltage v=11;2/ 33 tag k=voltage v=40;15/ 33 tag k=voltage v=13/ 29 tag k=voltage v=1200/ 24 tag k=voltage v=unknow/ 22 tag k=voltage v=3300/ 21 tag k=voltage v=1250/ 20 tag k=voltage v=75/ 18 tag k=voltage v=550V/ 18 tag k=voltage v=550/ 15 tag k=voltage v=66000/ 15 tag k=voltage v=6000/ 14 tag k=voltage v=15;6/ 13 tag k=voltage v=275000/ 13 tag k=voltage v=11;0/ 12 tag k=voltage v=900/ 12 tag k=voltage v=7/ 12 tag k=voltage v=11;35000/ 11 tag k=voltage v=1550/ 10 tag k=voltage v=38000/ 10 tag k=voltage v=35000;35000/ 10 tag k=voltage v=35000/1/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1Y2M8ACgkQnMz9fgzDSqfbQQCeJmyNunXw94c6D7TpMOGblJUR TUIAnjsXyQncwnFm+nprS2Bve9N3xBMG =peYS -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.02.2011 19:32, schrieb Frederik Ramm: Das Problem ist doch, dass da - egal wie viel ein Editor was zuklappt - irgendwelche semantisch schwer verstaendlichen Zusatzinformationen an einem Node haengen. Wieso hat diese Ampel hier Zusatztags, und die Ampel an der naechsten Kreuzung hat keine? Was tue ich, wenn diese Ampel hier abgebaut wird? André Reichelt wrote: Sollte ein Objekt mit versteckten Tags verändert oder gelöscht werden müsste der User über eine Warnmeldung darauf hingewiesen werden. Das ist aber, denke ich, obligatorisch. Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade machen willst, kann Folgen haben, die Du nicht verstehst und die wir hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des Problems. Vielleicht läßt sich das technisch so einrichten, daß sich nicht der normale User mit Änderungen an den den Spezialtags auseinandersetzen muß, sondern die Leute, die sich damit auskennen. Die Warnmeldung könnte dann aussagen: Lieber User, mit diesem Objekt hier ist irgendwas, was Du nicht verstehst, aber es macht nichts, wenn hier etwas kaputtgeht. Darum kümmern sich ggf. die Spezialisten. Könnte man vielleicht irgendwelche Trigger einbauen, daß bei Löschungen oder wichtigen Änderungen von Objekten mit Tags aus dem TMC-Namensraum eine Benachrichtigung ausgelöst wird. Das könnte vielleicht eine Mail an eine TMC-Mailingliste sein oder eine Eintragung auf einer Wiki-Seite. Dann müßten sich natürlich Leute finden, die diese Änderungsmeldungen prüfen und ggf. korrigieren. Was eine wichtige Änderung ist, müßte natürlich definiert werden. (Eine leichte Verschiebung einer Straße mit TMC-Tags gehört sicher nicht dazu.) Ähnliches könnte man für Relationen machen. Oder vielleicht gibt es externe Prüfmechanismen, mit denen man regelmäßig automatisch feststellen kann, ob die TMC-Tags noch konsistent sind. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk1OY1AACgkQnMz9fgzDSqd1qQCfVAkrUH2GX9un5U1KDZN+knvw tmAAn33mhwY9DszRQjTccosEVKDCNniD =rix2 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Liste mit möglicherweise inkorrekten Str aßennamen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 26.11.2010 08:23, schrieb Lück, Michael: also im Prinzip generieren wir eine Liste mit allen Adressen in Deutschland auf Straßenebene. Hierfür nehmen wir die OSM Daten. Dabei ist es natürlich wichtig, so viele Straßen wie möglich zusammen zu sammeln. Am 25.11.2010 17:20, schrieb Lück, Michael: Außerdem werden jetzt nicht mehr alle highway types ausgewertet, sondern nur noch 'residential', 'service','unclassified', 'track', 'tertiary', 'secondary', 'road', 'primary', 'pedestrian', 'trunk' und 'living_street' Hallo Micha, ist highway=track für Adressen relevant? In einem solchen Fall würde ich eher davon ausgehen, daß track falsch ist und stattdessen eher residential, unclassified oder service verwendet werden sollte, vielleicht mit einem geeigneten surface-Tag. Bei ein paar von mir eingetragenen Fahrwegen stehen vor Ort Schilder Rampe 1 usw. Die habe ich als highway=track mit name=Rampe 1 usw. eingetragen. Natürlich sind diese Wege keine Straßen, und die Namen gehören zu keiner Adresse. Vielleicht wäre es sinnvoll, auch highway=track zu ignorieren. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzxEiUACgkQnMz9fgzDSqcBQgCfRQsuHHZUlVaRtQMy3T70oSLe vqYAnjL2u5u7JthbFf+Y96nYy/0wvuwK =Fl9E -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] History bei Teilung von Wegen (was: Lizenz-Zustimmungskarte)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.11.2010 08:51, schrieb Frederik Ramm: Hat Fabian doch hie bereits auf Nachfrage erklaert - gelb sind Ways, die sowohl von Zustimmern als auch von noch-nicht-Zustimmern bearbeitet wurden. In meiner Gegend ist mir aufgefallen, daß diese Einteilung zwar der History in der Datenbank entspricht, aber inhaltlich nicht korrekt ist. Eine lange Straße, die ich ursprünglich eingetragen habe und die mehrmals von mir und von anderen bearbeitet wurde, hat jetzt zu einem großen Teil nur noch den letzten Bearbeiter in der History, weil die Straße geteilt wurde. Das Stück, das jetzt dem letzten Bearbeiter allein gehört, ist gerade der Teil, der unverändert ist. Eigentlich hat der letzte (und hier einzige) Bearbeiter an diesem Stück den geringsten Beitrag geleistet, denn er hat nur an dem anderen Teil, dem die komplette History zugeordnet wurde, die Zufahrtsbeschränkungen korrigiert. Kann man in einem solchen Fall die Teilung des Wegs in der Datenbank erkennen und dem neuen Stück für eine Auswertung ebenfalls die History zuordnen? Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzf5Q0ACgkQnMz9fgzDSqdV2gCgjT4hQIs3B9C9EIQzehqm5r50 L0EAn0dHl+OPz2nIWkTqmoMMRsEVGDvy =UdBh -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Prrobleme mit der Anzeige von Karten in MapSource 6.16.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.11.2010 01:21, schrieb NopMap: Ich habe von Leuten gehört, die Schwierigkeiten mit Mapsource 6.16.x haben Ich zitiere aus Beiträgen in der Mailingliste map_auth...@yahoogroups.com : The changes list of the new 6.16.3 Mapsource version released last week shows the following line: Made MapSource more robust when encountering invalid map products. Has anybody identified how this change affects third party maps, both personal and commercial? Behaviour depends on MAP ID. If Map id is more or equal 2200 it will search for a new file in the hard drive, in order to authenticate map as belonging to Garmin. Maps not authenticated are not displayed. So, change your Map ID to less then 2200. But as for this measure there is always a counter one, there are already mapsource patched versions circulating in the Net... Mapsource erwartet wohl für Karten mit Map-ID = 2200 eine zusätzliche Datei zur Freischaltung. Auch in der o.g. Mailingliste hat der Autor von cgpsmapper geschrieben, daß Garmin in Zukunft einen anderen Freischalt-Mechanismus benutzt, der auf Kryptographie basiert, und nachträgliche Manipulationen der Karten verhindern will. Also ist das vermutlich eine Maßnahme von Garmin gegen die Möglichkeit, die kommerziellen Garmin-Karten so zu ändern, daß keine Freischaltung mehr erforderlich ist. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzf8xEACgkQnMz9fgzDSqfJFACeNCXP3zoeFqA7CZnvfENlHT5F v30An3ZnrdISU6qHaWdriflZLgcfVLUI =qJY9 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Prrobleme mit der Anzeige von Karten in MapSource 6.16.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.11.2010 17:22, schrieb Felix Hartmann: On 14.11.2010 15:32, Bodo Meissner wrote: Mapsource erwartet wohl für Karten mit Map-ID= 2200 eine zusätzliche Datei zur Freischaltung. Das ist falsch. Zumindest für Karten im .img (also nicht gmap Schwachsinn) Format. mkgmap Karten mit mapid 2200 funktionieren einwandfrei. Wenn eine Karte in 6.16.3 nicht angzeigt wird, aber schon in vorherigen Versionen, dann ist dort eindeutig geschlampt worden. OK. Möglicherweise ist meine Vermutung falsch. Ich habe es nicht getestet. Das einzige Problem sind Karten mit Unlock Codes und 2200. spekulation Es wäre aber durchaus denkbar, daß Garmin mit neuen Mapsource- und Firmware-Versionen versucht, Manipulationen an kommerziellen Karten zu verhindern. Wenn Garmin bestimmte ID-Bereiche für kommerzielle Karten mit Freischaltung vorgesehen hat, könnte die Software einfach Karten mit diesen IDs sperren, wenn eine Freischaltung nicht vorhanden oder nach den Kartendaten nicht erforderlich ist. /spekulation Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkzgIBYACgkQnMz9fgzDSqdUeACgoJz6oa6gOTs8SUTCW5fTvHEX klEAoKKOUZDFuldQPSzccDEvgK1jvFte =fMi0 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Plugin: Anschlussstellen prüfe n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 16.09.2010 21:15, schrieb Jan Tappenbeck: Leider erschließt sich mir das nicht ganz - kann mir einer weiterhelfen ? Vielleicht der Autor, der am unteren Ende der Wiki-Seite einen Mail-Link eingebaut hat. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkyV/y4ACgkQnMz9fgzDSqd5nwCdH8BmSKiW31U0ygmIJunSFj67 fbEAnAkf6sA+0BJnP0MXjqrgC96DDaHs =10FH -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag access = designated kann was bedeuten?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 11.08.2010 09:47, schrieb Steffen Wolf: Wenn's von mir ist, dann ist es sicher ein Schreibfehler und sollte access=destination lauten. Diesen Fehler habe ich von anderen auch schon gesehen. Ich hab ohnehin erst spaet angefangen, motor_vehicle und die anderen Schluessel zu verwenden. D.h. eigentlich muesste ich alle meine access=* nochmal ueberpruefen. Genau. access=destination ohne mindestens foot=yes ist sehr ungewöhnlich (Gibt es irgendwo Außer Anlieger nur bzw. auch für Fußgänger?) Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxmZ+UACgkQnMz9fgzDSqeX/gCfcxWvfX0thAXK0j+2+Z7GzaFP yDUAnj1ZFjUPtcq/APXNACN04I+fBHsv =f9ZP -END PGP SIGNATURE- ___ 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] Landsat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 31.07.2010 14:13, schrieb Rolf Meyerhof: Wo ist die Verbindung von Josm zu Landsat geblieben.?? Hallo Rolf, was meinst Du mit der Frage? Werden keine Bilder mehr angezeigt (stattdessen vielleicht eine Exception) oder weißt Du nicht, wie man dem WMS-Plugin den Zugriff auf Landsat beibringt? Bei mir funktioniert derzeit der Landsat-WMS-Server nicht: Grabbing WMS http://onearth.jpl.nasa.gov/wms.cgi?request=GetMaplayers=global_mosaicstyles=format=image/jpegbbox=12.7956371,49.324,12.8229199,49.3733202srs=EPSG:4326width=500height=499 java.net.SocketTimeoutException: Read timed out Es gab auch früher schon Zeiten, in denen der Server nicht ging. (siehe auch http://onearth.jpl.nasa.gov/) Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxUdx8ACgkQnMz9fgzDSqee6wCcCDRtxTGe1POhnJFwWNMAXogO R9sAn3Ua6TCvWWA4a3dQjIjQSAfu3HQv =vekY -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprachverständis Parkplatz im Deutsche n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 25.07.2010 12:41, schrieb Guenther Meyer: Die Angabe kleine Parkmoeglichkeiten taggen wir nicht steht von Anfang an auf der Wikiseite. Ich kann mir nur vorstellen, dass damals damit verhindert werden sollte, dass alles mit Parkplaetzen zugekleistert wird. Das wird auch dadurch bestaetigt, dass damals kein separates Tag fuer diese Stellplaetze dokumentiert wurde. Aber heutzutage, wo jeder Baum und Kanaldeckel getaggt wird, und die Mapper und auch Renderer wesentlich differenzierter arbeiten, halte ich so eine Begruendung fuer obsolet. +1 Am Freitag 23 Juli 2010, 17:17:19 schrieb steffterra: und wie man das am besten Neuusern verklickert, die geneigt sind aus obigem Grund natürlich überall ein amenity=parking hinzubauen und einen Key für die Art des Parkplatzes (disabled, women, parent, motorbike) hinbauen. in dem man den Wikitext entsprechend anpasst. Was soll denn bitteschoen kaputtgehen? +1 Ich kann schon nachvollziehen, daß es Unklarheit schafft, wenn jetzt einzelne Stellplätze ohne Zusatztags als amenity=parking bezeichnet werden. Um das zu vermeiden, würde ich im Wiki dokumentieren, daß einzelne Stellplätze oder Parkplätze mit geringer Kapazität immer ein capacity-Tag haben sollen. Das könnte auch von Editor-Presets unterstützt werden. Bei Parkplätzen, die nach der bisherigen Beschreibung im Wiki keine ausreichende Größe haben, kann man nicht argumentieren, daß die Erfassung (Schätzung) der Kapazität nicht praktikabel oder zu aufwändig wäre. Bei Parkplätzen ohne capacity können wir annehmen, daß es sich entsprechend der alten Beschreibung um größere Parkplätze handelt. (Andernfalls ist es ein Fehler im Tagging.) Dann müßte man bei Bedarf nur noch den Renderern beibringen, ab irgendeiner Kapazitätsgrenze eine Unterscheidung zu machen. Insoweit sehe ich da auch kein wirkliches Problem. Allerdings wird mit diesem Vorschlag nicht die Frage beantwortet, wie man auf einem großen Parkplatz mit mehreren Stellplätzen/Parkständen die Bereiche kennzeichnet, die bestimmten Fahrzeugen oder Fahrzeugnutzern vorbehalten sind. Möglicherweise kann man das mit parking:lane lösen. Falls das zu kompliziert ist, braucht man eben (wie bereits gesagt) geeignete Presets. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxMKGoACgkQnMz9fgzDSqcpBACfTQFdvjjlJOaSOD3K5+oUtTzG h5oAn0OL9zlfCsCV7vAyaKigpiPxVTdm =dPcG -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] natural=tree und village_green
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 24.07.2010 13:24, schrieb p...@wuzel.de: Ich habe die Diskussion nicht verfolgt, aber der Feldmochinger Anger ist keine Grünfläche oder so was ähnliches, sondern ein Ortsteil. Vielleicht ist ja das gemeint? http://www.lbv-muenchen.de/Arbeitskreise/Biotope/biotop.aussen2/feldmoch.anger.htm Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkxMXdIACgkQnMz9fgzDSqcYyACgoNgj/2fE7IHl5o7wJ+3eg7K/ RPQAmwUf3KLjE4IBGYVLdIqodk4Nt39M =JJPZ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bäume (Gattung - Art)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.07.2010 12:00, schrieb fly: Ich habe kein Problem mit einem Tag species und/oder einem Tag genus, allerdings sollten wir auch das richtige beschreiben/benennen und vielleicht lernen die User auch dann mal den Unterschied zwischen Gattung und Art !? Da man die Gattung von der Art ableiten kann, reicht es die Art einzutragen. Du kannst aber nicht erwarten, daß jeder Benutzer den Unterschied kennt. Am 8. Juli 2010 11:36 schrieb fly lowfligh...@googlemail.com: So habe ich 100erte von Eichen (genus) und darunter auch die Kork-Eiche (species). Ich erkenne zwar eine Korkeiche, aber alles andere ist für mich eher nur Eiche. Wenn Du erreichen willst, daß das im letzteren Fall als Gattung und nicht als Art eingetragen wird, müßte das der Editor erledigen. Wenn die Tags nur für Leute mit Spezialkenntnissen korrekt nutzbar sind, mußt Du bzw. die Anwendung mit ungenauen oder falschen Werten leben und das beste daraus machen. Falls jemand eine Gattung als Art eingetragen hat, kann das von mir aus ein Experte korrigieren. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkw2QTUACgkQnMz9fgzDSqesYwCgjW0/NqAZNxOBSpsjV5HgvxHg 6FgAn02ARvHRzdhJ8l1YASKr4+om4mi4 =mUFd -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bäume (Gattung - Art)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 09.07.2010 00:09, schrieb Schlauchboot: Am Donnerstag, 8. Juli 2010 23:20:53 schrieb Bodo Meissner: ch erkenne zwar eine Korkeiche, aber alles andere ist für mich eher nur Eiche. Wenn Du erreichen willst, daß das im letzteren Fall als Gattung und nicht als Art eingetragen wird, müßte das der Editor erledigen. Schwierig, denn das Problem ist ja allgemeinerer Art, nicht nur auf Bäume bezogen, ja nicht einmal auf die Biologie alleine. Das wird man nicht alles (mit umgangssprachlichen und fachlichen Bezeichnungen in diversen Sprachen) durch eine Editor validieren lassen können. Angenommen, JOSM würde mir (mit einem trees-plugin?) als Presets eine Übersicht der Bäume anbieten, beispielsweise so: Bäume | +- Eiche | | | +-Korkeiche | +-Steineiche | +- ... +- ... Dann könnte ich Eiche auswählen und Josm würde das korrekt als Gattung eintragen. Wenn ich Korkeiche wähle, würde das als Art (im Sinne der Biologie) eingetragen. Wenn jetzt ein Baumspezialist genauere Daten haben möchte, muß er sich die Eiche ansehen und die Art nachtragen. Wenn die Tags nur für Leute mit Spezialkenntnissen korrekt nutzbar sind, mußt Du bzw. die Anwendung mit ungenauen oder falschen Werten leben und das beste daraus machen. Das wäre schade, denn durch viele Eintragungen von nicht-Experten könnte keine verlässliche Datenbasis von Spezialwissen in der Datenbank entstehen (wie gesagt, ganz allgemein). Gemäß dieser Argumentation würde die Qualität in jeder Hinsicht wesentlich durch das Wissen und die Fähigkeiten von Laien bestimmt bleiben. Ist auf allen Gebieten so. Eine befriedigende Lösung fällt mir so schnell nicht ein. Wäre es denkbar, auf bestimmten Gebieten zwei Arten von Tag-Sets zu verwenden, ein Set für Laien und ein Set für Experten? Dann müsste jeder in seinem Editor gemäß seinen Kenntnissen das eine oder andere Tag-Set auswählen. Experten wüssten dann auch, wo sie am ehesten präzisierend eingreifen könnten. Ich glaube nicht, daß das funktioniert. Sieh Dir mal die derzeitig verwendeten Werte für species an: http://osmdoc.com/de/tag/species/#values Da gibt es auch Werte auf englisch oder deutsch sowie Tippfehler. (Wenn ich keine Lust habe, die lateinischen Bezeichnungen zu ermitteln, ist die deutsche oder englische Bezeichnung besser als keine Information.) Da wäre es aus meiner Sicht kein Problem, ein Tool zu entwickeln, das alle Tippfehler, ungenauen oder falschen Werte durch die korrekten Werte ersetzt, soweit das möglich ist. Beispiele (meine Vermutung als Laie): Oak, oak, Kastanie - Gattung, Red Norway Maple - Art, ginko biloba - ginkgo biloba oder Ginkgo Biloba oder Ginkgo biloba ? Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkw2t4cACgkQnMz9fgzDSqcVEQCfWyUJgzd7VJroIhqyYSjQl1Kg i0QAn3vBIs8SOuSgoCP57F7qQ5ay1dUA =4nms -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit den Editierungen eines anderen Benutzers im Bereich WM/GAP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.07.2010 19:26, schrieb Frederik Ramm: Ich hatte mit dem Benutzer im August 2009 Kontakt, und er versprach damals, diese Quelle nicht mehr zu verwenden. Wie sicher ist es, dass er es dennoch tut? Das ist nicht so einfach nachzuweisen. Indizien: großflächige Changesets mit unbrauchbaren Kommentaren Objekte gemappt, die man nur schwer durch GPS-Tracks mappen kann: Hofzufahrten, Gebäudeumrisse, landuse=residential Straßen, die vermutlich vorher auf einem hochgeladenen Track lagen und jetzt besser zum Luftbild passen. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwySzMACgkQnMz9fgzDSqdLnACfe3cthsWskYhJNdaSxCHrFfBB wQAAoIJ6vTN+tvjaQUOQgi5AhBzB2f9N =P1Yr -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit den Editierungen eines anderen Benutzers im Bereich WM/GAP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.07.2010 00:13, schrieb Thorsten Kunkel: Am 05.07.2010 23:14, schrieb Bodo Meissner: Indizien: großflächige Changesets mit unbrauchbaren Kommentaren Die haben wir hier: http://www.openstreetmap.org/user/alegria6208/edits Kommentare sind generell ..., viele Changesets sind weit verstreut. So hatte ich das auch gemeint: Bei diesem User deuten die von mir genannten Indizien darauf hin, daß er Luftbilder abgemalt haben könnte. Wie krieg ich denn den LVG WMS in das JOSM WMS-Plugin rein? Das würde mir die Fehlersuche wesentlich vereinfachen. http://www.geodaten.bayern.de/ogc/getogc.cgi?REQUEST=GetMapVERSION=1.1.1LAYERS=DOPSRS=EPSG:4326FORMAT=image/pngTRANSPARENT=TRUESTYLES=; Das liefert Luftbilder bei einer Zoom-Einstellung = ca. 135m. Die höchste Auflösung wie beim BayernViewer bekommt man da leider nicht. (BayernViewer ist kein WMS. Wenn ich mich recht erinnere, ruft der JavaScript-Code die Bilder über Gauß-Krüger-Koordinaten ab. Man könnte sich evtl. selbst einen WMS bauen.) Ich werde mal in meiner Gegend ein paar seltsame highway=service überprüfen. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwyxV0ACgkQnMz9fgzDSqfAcQCgmEy0yL3vAvh7fU1WYhKGaQeu M/gAoIC/vaDUBK2A6/hmz/gGbCOP4PPq =rYls -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Post-Box Guesstimator: Wo fehlen Briefk ästen in OSM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Peter, offensichtlich wird amenity=post_office nicht ausgewertet. Ich würde davon ausgehen, daß es bei jeder Postfiliale auch einen Briefkasten gibt. Ansonsten wäre das als zusätzliche Ebene sinnvoll. Möglicherweise ist es ein Fehler im Code. In data.php ist mir diese Stelle aufgefallen: case 'post_box': $sql = SELECT ST_AsGeoJSON(ST_Buffer(way, 1000)) AS way FROM planet_point WHERE ((tags @ 'amenity=post_box') OR (tags @ 'amenity=post_box')) AND way ST_SetSRID(ST_MakeBox2D( ST_Point($bbox[0], $bbox[1]), ST_Point($bbox[2], $bbox[3]) ),900913) LIMIT 1000 ; break; Da steht zweimal die gleiche Bedingung. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwhxz4ACgkQnMz9fgzDSqfOUQCfW7jLhogFNFMFk3d2PAnGNpFZ LyIAn3xylyVJMZA65JsEFt/5LIKOP4Kl =U2HG -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Daten auf Verlangen löschen oder nicht ...?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.06.2010 11:07, schrieb Martin Hollmichel: ist das Wegenetz sehr dicht (im Mittelnkirchener Beispiel geht zum Teil alle 30m ein Weg in den entsprechenden Hof) wirst Du Probleme haben, zu bestimmen, wer von den vielen Wegen gerade derjenige ist, vor dem Du steht. Wenn das wichtig ist, würde Mitzählen auch helfen. On 23.06.2010 10:37, Jochen Topf wrote: Wenn jetzt da wirklich ein Weg bei ist, wo sich häufiger mal Leute rein verirren und man will das nicht, finde ich es nicht zu viel verlangt ein kleines Schild aufzustellen. stehen hier auch an sehr vielen Stellen, aber wenn das in der (kommerziellen) Karte eingetragen ist, dann kann man doch trotzdem da lang fahren, oder (/sarcasm). Im Mittelnkirchener Beispiel kann ich an der Karte erkennen, daß die Wege bei den Häusern enden und nicht weiter bis zur anderen Straße führen. Für den Fall, daß das jemand übersehen hat, fände ich in diesem Fall ein Schild Sackgasse sehr hilfreich. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwh0pcACgkQnMz9fgzDSqeXCgCgovciopEtlrV3ucd401wkB+CO ejcAn2CBCsWlZMJ833+6A1fVJ1jGIQUq =SbB3 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der Post-Box Guesstimator: Wo fehlen B riefkästen in OSM?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.06.2010 13:04, schrieb Fabian: Hab ein paar Kaesten aufgenommen beim vorbeifahren wo ich die die Vorderseite/Operator nie gesehen habe. Sind rot mit 49ct Aufschrift. Vielleicht wäre es sinnvoll, dort operator=FIXME zu ergänzen. verfaelscht die Wahrheitstreue vermutlich aber nur um 0.1%. Da es um die Anzeige geht aber hinnehmbar denke ich. Ich denke, in diesem Fall ist es ungünstig, wenn ein sonstiger Briefkasten als Post-Briefkasten angezeigt wird. Dann fällt es u.U. nicht auf, daß ein Post-Briefkasten fehlt. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwh7dsACgkQnMz9fgzDSqfgwgCeJrLWLiIAxy5wtbHE0hLNUr4E TWIAnRP2F7FUTW6CsQF3hW/oWv07jL5F =YG3Y -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Daten auf Verlangen löschen oder nicht ...?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 23.06.2010 11:42, schrieb Martin Hollmichel: On 23.06.2010 11:23, Bodo Meissner wrote: Für den Fall, daß das jemand übersehen hat, fände ich in diesem Fall ein Schild Sackgasse sehr hilfreich. neuer deutscher Schilderwald, Privatweg kombiniert mit dem Sackgassenschild, würde ich mich nur in Kalau trauen, :-) Jetzt wird es schon ziemlich OT. Ich meine nicht unbedingt die Verkehrszeichen. Im Wald habe ich schon Holzschilder (Stück Brett) mit dem aufgemalten Wort SACKGASSE gesehen. Das erfüllt auch seinen Zweck. (Einen vergleichbaren Schilderwald gibt es tatsächlich. An dieser Stelle http://www.openstreetmap.org/?lat=52.37884lon=13.62008zoom=17layers=B000FTF stehen an jeder kleinen Straße zwei Ortsein-/-ausgangsschilder und teilweise auch ein Sackgassenschild.) Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwh764ACgkQnMz9fgzDSqexhACfWfIOb7h9JMVp0nhB7jw4Ni1j q3cAnjWWUMSmwJHTkDeMs6YDXaa88iNu =AFet -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deisgnated / official WAR Re: Fahrrad-Access-Map
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 22.06.2010 01:21, schrieb NopMap: Klar, hab ein paar Werte für Deutschland ergänzt, für den Fall das aus dem Proposal was wird. Deshalb kann man aber noch lange nicht behaupten, das Proposal käme von mir. Tut mir leid, daß ich mich unklar ausgedrückt habe. Es ist klar, daß der Proposal nicht von Dir ist. Ich war nur verwundert, daß Du schreibst: Nö, mit designation habe nix zu tun. Offensichtlich hattest Du damals die Idee, diesen Key in D für den Zweck zu verwenden, der bisher von *=official erfüllt wird. Das wäre dann eine zusätzliche Möglichkeit, was zu noch mehr Verunsicherung führen könnte. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwgck8ACgkQnMz9fgzDSqef9QCdHASXi2FcdVfC2hJyaqtyKl9Z SzkAoIcRSQiTejknqMbo3ZIIsERcaBsU =HcGf -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deisgnated / official WAR Re: Fahrrad-Access-Map
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.06.2010 13:37, schrieb Tobias Knerr: Trotz der official-Vorstöße ist die gängige Praxis (die sich auch in dem Verkehrszeichen-Tool widerspiegelt) m.E. derzeit anders als Nops Vorgehen - nämlich so, dass * designated heißt: du darfst hier lang und bist als bevorzugter Nutzer ausgewiesen (etwa durch ein blaues Schild) Bei der Einfügung von official im Wiki durch Nop stand designated auf der englischen Seite: The route is marked as being a preferred route, usually for a specific vehicle type or types und auf der deutschen: Für diesen Transporttyp ausgewiesener Weg, meistens ausgeschildert, impliziert ein Verbot für alle anderen Transporttypen. Nop hat den deutschen Text der englischen Version angenähert: Für diesen Transporttyp vorgesehener Weg, meistens ausgeschildert. Die englische Version von designated wurde später geändert in: The way is a preferred/designated route for a specific vehicle type or types (by law or otherwise) but not compulsary, often marked by a traffic sign. Nach der deutschen Wiki-Seite wurde designated früher etwa so interpretiert, wie jetzt official. Nach der englischen Seite war und ist designated auch für andere irgendwie vorgesehene oder bevorzugte Wege verwendbar. designated heißt nicht, daß das Verkehrsmittel auf dem Weg bevorzugt ist, sondern daß der Weg für das Verkehrsmittel bevorzugt ist. Ich gehe davon aus, daß bicycle=designated auch in D zumindest teilweise entsprechend der englischen Beschreibung ausgelegt wurde bzw. wird. (Ein Weg mit Fahrrad-Wegweiser könnte also auch bicycle=designated sein.) Das war der Grund für die Einführung von *=official. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwfYmUACgkQnMz9fgzDSqfmugCfSXoGFaNmzuKRnKKVRQ9HK+ul lzsAni7faxzQ+zSYvoeSebB4FrJ8lqj+ =U8Tp -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deisgnated / official WAR Re: Fahrrad-Access-Map
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.06.2010 17:27, schrieb Sebastian Masch: Bodo Meissner wrote on 21.06.2010 15:00: Nach der deutschen Wiki-Seite wurde designated früher etwa so interpretiert, wie jetzt official. Du hast hier leider den Satz gelöscht, der dahinter stand. Eben. Und statt designated einfach richtig zu stellen, wird diese komisch schwammige Beschreibung belassen und ein neues Tag eingeführt. Als Richtigstellung wurde die Variante gewählt, die deutsche Beschreibung zu designated an die englische anzupassen. Ich habe hier einen halben Landkreis, wo zum sehr großen Teil nach Blaues-Schild-gleich-designated getagt wurde. Und in der anderen Hälfte bzw. im kleineren Teil? Klingt ja, als ob man sich da nicht einig ist. Es gibt bestimmt auch Gegenden, wo designated nach der Interpretation der englischen Wiki-Seite eingesetzt wird. Da man ohne Ortskenntnis nicht erkennen kann, welche Interpretation von designated der Mapper im Sinne hatte, ist dieser Wert in vielen Fällen wertlos. Ich werd den Teufel tun und alles ändern, nur weil jemand im Wiki wilde Sau gespielt hat. Falls es irgendwann einmal zum Konsenz kommt, kann man das immer noch tun, egal in welche Richtung. Wegen der vorliegenden Probleme wird es aber keine automatische Erkennung geben, welche Wege mit bicycle=designated in bicycle=official umgewandelt werden müßten. In Anbetracht der englischen Seite wird es international vermutlich keinen Konsenz für die (frühere/umstrittene) deutsche Interpretation von designated geben. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwfkCAACgkQnMz9fgzDSqcPBgCdEVPRWmpgr/AinCPR78PYSiI3 0JoAni2t/0bgdvO5McZVe3+OqpkzEKFO =6sIX -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deisgnated / official WAR Re: Fahrrad-Access-Map
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.06.2010 19:54, schrieb Tobias Knerr: 3. Wie ist der Zusammenhang zwischen official und designation=*? [...] [¹] http://wiki.openstreetmap.org/wiki/Proposed_features/Designation Das stammt wohl beides von Nop. Keine Ahnung, warum jetzt noch eine weitere Alternative vorgeschlagen werden soll. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwfquEACgkQnMz9fgzDSqfPaACfT9yF3fcBbt8CS1y59LIK/3dE jmkAoI/D/dpzVCfvn1yqkbzIrAmUOnav =tyet -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deisgnated / official WAR Re: Fahrrad-Access-Map
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.06.2010 22:21, schrieb NopMap: Nö, mit designation habe nix zu tun. Kann mich auch vage erinnern, daß das aus UK kam. Das Wiki dokumentiert diese Änderung: http://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2FDesignationdiff=284885oldid=284874 Warst Du das nicht? Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwfy2QACgkQnMz9fgzDSqcs9QCgibjPYeF9mXT2CfqzzEL+bNFj MNcAoI9bLYATLDgkIuSKcAJUppiA+t0G =6zcv -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 20.06.2010 14:42, schrieb Alexander Matheisen: [...] Tags der Form wikipedia:Länderkürzel=Artikelname [...] Mir erscheint es am sinnvollsten, alle Wikipediatags in die Form wikipedia=Länderkürzel:Artikelname zu bringen. Dann hätte man den gleichen Key wikipedia mehrmals mit verschiedenen Werten. Geht das überhaupt? Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkweD3AACgkQnMz9fgzDSqf6zwCfZCSwBQP7evUWX55TCHe4Dxm1 jzcAn3R1RxOR4x1NEw4ZyXf7nEOaVCQH =Mpeo -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Recycling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 13.06.2010 15:38, schrieb Florian Gross: Öhm, was würde dagegen sprechen name=Wertstoffhof [Stadt/Stadtteil] zusammen mit opening_hours= zu verwenden? Wenn es tatsächlich der Name ist, gar nichts. Zur Unterscheidung zwischen Wertstoffhof und Container ist aber eher ein Subtag erforderlich. (Ein Altkleidercontainer hat mit ziemlicher Sicherheit keinen Namen.) vielleicht etwas in dieser Art: recycling_type=container recycling_type=recycling_center Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwU8gEACgkQnMz9fgzDSqfacACfZI2ohNWSnOk+jtNZByXrmtRP TiIAn21idc+zaPECC7oAi+ErTYHyjhaJ =j4Ty -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki bzgl. ref auf motorway_link ändern/ergänzen und ref dort ersetzen/entfernen?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.06.2010 00:05, schrieb M∡rtin Koppenhoefer: Am 13. Juni 2010 19:20 schrieb steffterra steffte...@me.com: Dass der Weg eine Autobahnauffahrt ist, und wo die hinfuehrt, steht schon in den Daten. Du meinst es steht in den Daten in dem der motorway_link mit dem motorway einen gemeinsamen knoten hat, oder meinst Du etwas anderes? Im Prinzip ja, es ist aber noch mehr: der motorway-link hat ja eine Richtung, und es ist nicht irgendein node sondern der letzte Node, der gleichzeitig die Autobahn ist, wo er hinführt. Diese Redundanz, die Du vorschlägst, macht für mich an dieser Stelle daher keinen Sinn. (Bei Ausfahrten ist es das selbe in grün). Es gibt auch komplexere Konstruktionen, bei denen das nicht mehr so einfach zu verfolgen ist. Beispiel: Autobahndreieck Allgäu http://www.openstreetmap.org/?lat=47.687261lon=10.368329zoom=18 Von der A7 in nördlicher Richtung zweigt eine Parallelspur ab, die auch wieder auf die A7 führt. Davon geht dann wieder die Verbindung zur A980 ab. Hier müßte man entlang der Route alle *_link-Stücke verfolgen, bis man auf eine andere Straße (nicht *_link) trifft und ggf. das dortige ref verwenden. (Geht nur zur Laufzeit des Routers. Wenn man das bei der Karten-Generierung machen möchte, müßte man alle Kombinationen durchrechnen.) Wenn man manuell festgelegte Werte an die *_link-Stücke klebt, erleichtert das dem Router bzw. dem Routing-Karten-Generator die Arbeit. Und da scheinbar in vielen Fällen der Mißbrauch des ref-Tags gängige Praxis ist, wäre es sicher sinnvoll, die Information in ein besser geeignetes Tag wie das vorgeschlagenen destination_ref zu verlagern. Ich denke, es schadet nichts, den vorgeschlagenen Key zu verwenden, auch wenn das möglicherweise redundant ist. Da es aber bisher nicht der gängigen Praxis entspricht, würde ich das zuerst als Proposed_feature eintragen. Alternative: häufig in der DB verwenden und dann mit Verweis auf die Verbreitung direkt ohne Proposal als Key eintragen. Wenn jemand ein Programm schreibt, das die korrekten destination_ref-Werte für alle motorway_link ermitteln kann, ist das vielleicht ein Hinweis, daß man auf destination_ref verzichten kann. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwVYJEACgkQnMz9fgzDSqeX/wCfbAVt8lrTfQaIdpCu7C1PexfF jvcAmwar0IWL7qIiVqqKAHWoskFi7mIO =hIz9 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jogging-Rundstrecken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.06.2010 17:59, schrieb Thomas Ineichen: Diese Strecken sind für alle frei zugänglich und haben meistens alle paar hundert Meter einen Posten, an dem man zusätzliche Übungen machen kann, z.B. Klimmzüge, auf Holzbalken balancieren, etc. Gibt es in Deutschland/Österreich ähnliche Rundstrecken? In Italien (Colli di San Fermo) habe ich beim Spazierengehen im Wald auch mal einen Trimm-Dich-Pfad gefunden. Heißt dort percorso vita. Ich glaube, das war etwa an dieser Stelle http://www.openstreetmap.org/?mlat=45.73376mlon=9.95574zoom=14 Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwTS60ACgkQnMz9fgzDSqcL1QCeNaeEumS/JCg85c89GkbDJZO/ FXwAmQGUr2bDWaNen3ZySUhE+dg7pMbL =Y3vL -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradaufzug mit Handbetrieb / Kreativ Steigungen überwinden
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 11.06.2010 07:19, schrieb Jens Frank: *Da ist doch auf beiden Seiten eine schöne Rampe, oder interpretiere ich da was falsch? Ist da vielleicht zwischen Bahngleis und Fluß ein Weg, der an die Brücke angeschlossen werden soll? Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwR4F0ACgkQnMz9fgzDSqcFWwCgkzWrNfrtpwopIdF82VDDRiQR xNwAn3WeDPagZxib3VV7SCzqQdp50iuW =cZwQ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradaufzug mit Handbetrieb / Kreativ Steig ungen überwinden
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 11.06.2010 10:32, schrieb r...@gmx-topmail.de: Die Mapper, die vor Ort waren haben zwischen Bahn und Bach eine Treppe in OSM eingezeichnet. Beide sind erfahrungsgemäß recht zuverlässig. Ich denke, um diese Treppe geht es. Die Treppe ist auf der Radfahrerkarte nicht erkennbar, nur bei Mapnik in der höchsten Auflösung oder in den Daten. In der ursprünglichen Mail stand: [...] ist es bekanntlich notwendig, im Höhe Nierenhofer Straße irgendwie auf die Hunte-/ oder Hundebrücke zu gelangen. [...] Unsere Vorstellung ist, mit einer Art von Handaufzug Person und Rad (auch Tandem oder Rad mit Anhänger) hoch zu bekommen. Das klingt nicht so, als ob es um eine Treppe ginge. Die Person könnte doch die Treppe benutzen und nur das Rad müßte bewegt werden. Ein paar Fotos und Detailinformationen zu der betroffenen Stelle wären für die Lösungsfindung hilfreich: Wie viele Stufen? Wie steil? Wie breit? Wenn es um die Treppe geht, könnte man als kostengünstige Lösung vielleicht im Randbereich eine Schieberinne montieren. Bei Handaufzug fällt mir noch ein, daß es auf Bahnhöfen manchmal fahrbare Geräte gibt, die einen Rollstuhl zum Ein- oder Aussteigen anheben können. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwSKJ4ACgkQnMz9fgzDSqf9SACfTaJcn2FtC005RCR7WsQO2JvT 9CIAn0scRtyXfk3uXYOK/G/xwswowXnI =KDZ8 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrradaufzug mit Handbetrieb / Kreativ Steigungen überwinden
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 10.06.2010 22:10, schrieb Florian Gross: Die Frage würde ich eher in de.rec.fahrrad stellen. Oder vielleicht mal beim ADFC nachfragen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwRX7YACgkQnMz9fgzDSqcYIgCgjKSAoixFTCOSGWCNE6w4ga16 0PcAnA/zdGdPLDojynJf0Cl4umFyqJIQ =qwPI -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wehrkiche?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 09.06.2010 08:48, schrieb Andreas Labres: Irgendwie ist so ein Zusatzattribut grundsätzlich problembehaftet, weil wenn man nicht richtig danach sucht, auch alle diese ehemaligen idF Kirchen bei suche alle Kirchen rausfallen... und speziell so eine POI Suche macht bald mal jemand (eine Routing-App oder sowas). Ich denke da zB daran, was ich in NL gesehen habe: eine aufgelassene Kirche, die zum Wohnhaus umfunktioniert wurde... wäre blöd, wenn da Sonntag früh wer anläutet und, mit dem Navi in der Hand, nach der Messe fragt... ;) Damit muß man leben, wenn man in einer ehemaligen Kirche wohnt. ;-) Das Problem könnte auch ohne OSM auftreten, wenn das Gebäude schon von weitem als Kirche auffällt. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwPVFYACgkQnMz9fgzDSqfwCwCgn8g+Ad1pGYzyJMOaAtUyxxax 0VIAniy2nVybIZNgVAagqiuQ+GcAK8Et =APdm -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OT: Mindestgeschwindigkeit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.06.2010 22:47, schrieb Wolfgang: Hallo, Am Montag 07 Juni 2010 19:55:44 schrieb Bodo Meissner: Am 07.06.2010 12:02, schrieb Wolfgang: Man darf auch auf der Bundesstraße nicht weniger als 100 fahren, wenn man jemanden hinter sich hat, der nicht überholen kann und die Geschwindigkeit legal gefahren werden könnte Das ist vielleicht das Wunschdenken des Hinteren. Die Höchstgeschwindigkeit ist die Geschwindigkeit, die man auch unter günstigen Umständen nicht überschreiten darf. richtig, überschreiten verlangt ja auch niemand Ich hätte das unter günstigen Umständen etwas hervorheben sollen. (Zu diesen Umständen gehören auch Dinge, die der Nachfolgende nicht sehen kann, siehe $3 Abs. 1) Das ist keine Richtgeschwindigkeit. Richtgeschwindigkeit != Mindestgeschwindigkeit, nur empfohlen! Damit meine ich: Es gibt keine Empfehlung oder Verpflichtung, mit der Höchstgeschwindigkeit zu fahren. Die Höchstgeschwindigkeit sagt nichts über die angemessene Geschwindigkeit aus. Wenn der Vordere ohne einen _vernünftigen_ Grund den Hinteren am zügigen Weiterkommen hindert, verstößt er gegen §1 und §3 Abs 2. [...] Es gibt häufig Gründe, langsamer zu fahren. Wenn die aber _nur_ darin bestehen, das 70. Lebensjahr vollendet zu haben und einen Hut im Auto zu tragen, Der _vernünftige_Grund_ ist für den Nachfolger vielleicht nicht offensichtlich. Siehe §3 Abs. 1: Er hat seine Geschwindigkeit ... seinen persönlichen Fähigkeiten ... anzupassen. Vielleicht sollt man mal wissenschaftlich untersuchen, ob das Tragen eines Hutes im Auto mit den persönlichen Fähigkeiten korrelliert. :-) Unter Annahme eines solchen Zusammenhangs kann man den Hut als Erkennungszeichen für das Vorliegen eines zwingenden Grundes für eine reduzierte Geschwindigkeit nach §3 Abs. 1 werten. :-) (Hut gilt vermutlich nur für Männer. Bei Frauen ist mir kein so deutliches Erkennungsmerkmal bekannt. Hier besteht noch Forschungsbedarf. :-) muss derjenige eben die Bushaltestellen nutzen, um entweder die Kolonne vorbei zu lassen Genau das war Thema des Gerichtsurteils: 1. Wenn ein Fahrzeug (wie im betrachteten Einzelfall) mindestens 60% der erlaubten Höchstgeschwindigkeit fährt, zählt das nicht als langsam fahrendes Fahrzeug. Dann ist es zwar nett, die Nachfolger vorbei zu lassen, aber der Fahrer ist nicht dazu verpflichtet. 2. Ein oder zwei Fahrzeuge sind noch keine Kolonne, die man vorbeilassen müßte. (Eine Grenze wurde nicht definiert.) (Da solche Grenzen nicht in der StVO festgelegt sind, kann man sich nur auf Gerichtsurteile berufen.) oder das Verkehrsmittel zu wechseln. Du solltest mal die Busfahrpläne auf dem Land lesen. Selbst wenn man wollte, ist das oft unzumutbar. Ich möchte das aber hier nicht ausufern lassen. Für uns relevant (und hoffentlich unstreitig) ist, dass es auf Autobahnen keine (tagbare) Mindestgeschwindigkeit gibt, wenn sie nicht ausdrücklich ausgeschildert ist. ACK. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwN4XEACgkQnMz9fgzDSqcouACffteVLwHVKEIlBCW6Q38JMbMj 1agAn3/Klw5x8uNnJKBr3K7mmsCxZ8fp =NQtu -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Routing MKGMAP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 08.06.2010 08:31, schrieb Sven Sommerkamp: - Ursprüngliche Mitteilung - Am 07.06.2010 15:25, schrieb Joerg Fischer: lieber 30 m schieben oder 5km Umweg? Wenn ich ein volbepacktes Fahrrad hab Das ist sicher von den persönlichen Vorlieben abhängig. (Ich würde in diesem Fall lieber schieben.) Man bräuchte also eine Konfiguration, mit der jeder seine Gewichtung beim Erzeugen der Garmin-Karte einstellen kann, und Erfahrungswerte für sinnvolle Gewichtung. oder Velomobil würde ich evtl. 5km Umweg in Kauf nehmen. Hier gibt es vermutlich noch andere Kriterien, die berücksichtigt werden sollten. Wie gesagt, man kann auf Fußgänger umschalten, dann werden sicher auch Treppen und dergl. Geroutet Ist aber nicht optimal. Mit dem Fahrrad liegt die Grenze der akzeptablen Stufenzahl und Treppen-Häufigkeit niedriger als bei Fußgängern. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwN5koACgkQnMz9fgzDSqcviACgmUdBn/BITLTxsYlh4MA0mIKZ x1gAniHwXGGgnoMrwViiJzfVrp0uPgqK =D7JH -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OT: Mindestgeschwindigkeit (was: BAB mit no horse, bike etc.)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.06.2010 12:02, schrieb Wolfgang: Eine Mindestgeschwindigkeit gibt es nicht ausdrücklich, sie ergibt sich aber aus §1 STVO (behindern etc) und ganz deutlich §3 Abs.2 STVO und gilt nicht nur auf der Autobahn. Man darf auch auf der Bundesstraße nicht weniger als 100 fahren, wenn man jemanden hinter sich hat, der nicht überholen kann und die Geschwindigkeit legal gefahren werden könnte Das ist vielleicht das Wunschdenken des Hinteren. Die Höchstgeschwindigkeit ist die Geschwindigkeit, die man auch unter günstigen Umständen nicht überschreiten darf. Das ist keine Richtgeschwindigkeit. Es gilt auch §3 Abs. 1. Der Fahrzeugführer darf nur so schnell fahren, daß er sein Fahrzeug ständig beherrscht. Er hat seine Geschwindigkeit insbesondere den Straßen-, Verkehrs-, Sicht- und Wetterverhältnissen sowie seinen persönlichen Fähigkeiten und den Eigenschaften von Fahrzeug und Ladung anzupassen. Ich habe gerade keine Quelle gefunden, aber es gibt Gerichtsurteile, nach denen es kein Problem ist, wenn man mehr als 60% der Höchstgeschwindigkeit fährt. Das zählt auch nicht als langsamfahrendes Fahrzeug, das verpflichtet wäre, eine Schlange überholen zu lassen. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwNMqAACgkQnMz9fgzDSqcq8gCfc0phGqeUf2KE1qrY0uDHO9t9 X3IAoKArk0gOPl6exrVje7iI7ZlzfDb6 =T2qW -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Validator-Meldung bei Grenzrelation (was: Hilfe bei Grenzrelationen)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.06.2010 18:36, schrieb Florian Lohoff: Grenzen sind technisch wie Multipolygone bzw in D sind die allermeisten Grenzen als multipolygon relation angelegt nicht als boundary relation (type=boundary) In meinem Fall (siehe Ursprungsposting) ist es aber type=boundary, so wie das auch bei Vorlage der Fall war. Multipolygon ist nicht sinnvoll, da mehrere Grenzen teilweise mit der Küstenlinie zusammenfallen und deshalb die Linien andere Tags haben als die Relationen. Wenn ich multipolygon verwendet hätte, wäre die Validator-Meldung auch in Ordnung. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwLqeEACgkQnMz9fgzDSqdSrgCfaQNIaAirYmAGwoVFSK3qPckY RDYAnj4CFgfLjqec8J71R62e3sFqK1pR =12vd -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Validator-Meldung bei Grenzrelation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.06.2010 22:09, schrieb Thomas Ineichen: (Auf der englischen Wiki-Seite[1] steht allerdings inzwischen, man soll auch bei boundary-Relationen 'outer' verwenden..) Danke. Das könnte die Erklärung für die Validator-Meldung (in josm-latest von gestern) sein. Dann werde ich mal role=outer ergänzen. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwMCSwACgkQnMz9fgzDSqfe/gCfeoi9KOJYvKwZHmGhVaYSbaHI fnYAn2UQKqSrrl86xHLzysJdvBziWbjD =0Iwb -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Validator-Meldung bei Grenzrelation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.06.2010 23:09, schrieb Matthias Versen: Dann tagge die auch gleich als multipolygon um wie es im gleichen Wiki Artikel steht (Deutschland verwendet multipöolygon) Lies mal das Ursprungsposting und betrachte ggf. die dort angegebenen Links. Die Grenze befindet sich in Italien. Da werde ich nichts umtaggen. Ich frage mich wer da dauernd die tagging Regeln für die Grenzen im Wiki ändert. Im Wiki ist alles dokumentiert, wer wann was geändert hat. Ein type=boundary mit multipolygon Regeln ist erst recht bullshit. Laut englischem Wiki-Artikel scheint das aber international die häufigste Variante zu sein. Im Wiki soll die verbreitete Praxis dokumentiert werden oder bei Konsenz ggf. auch die zukünftig gewünschte Tagging-Methode. Vielleicht sollte ich mir mal ganz neue tagging Regeln ausdenken und das wiki umschreiben. Kannst Du gern als Proposal schreiben oder auf die entsprechende Talk-Seite. Wenn sich Deine Variante durchsetzt, wird sie natürlich auch als gängige Praxis dokumentiert. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwMJBoACgkQnMz9fgzDSqeZmgCeIhiYDkDOVaPaqX0CgrCZoeOS lUgAnRkk49st0RYOVLZa9Fpb4ZuaZrMO =8YDS -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Auflösung beim WMS-Plugin (was: Mass endownloads vom PCN - portale geografico nazionale)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 24.05.2010 14:34, schrieb M∡rtin Koppenhoefer: Am 23. Mai 2010 21:51 schrieb Chris66 chris66...@gmx.de: Am 22.05.2010 19:29, schrieb Robert Heel: Richtig, wenn man bei JOSM in hoher Zoomstufe einen WMS Layer aktiviert und dann rauszoomt, lädt josm die Bilder in hoher Auflösung weiter herunter ... Ja, die automatische Anpassung der Auflösung an die Zoomstufe funktioniert nur in Potlatch. M.E. ist das auf jeden Fall ein Feature, es wäre IMHO Quatsch, bei jedem Drehen am Mausrad die Auflösung zu ändern, bzw. diese vom Ausschnitt abhängig zu machen. Vielleicht wäre es sinnvoll, wenn das WMS-Plugin das Laden der Kacheln vorübergehend einstellt oder die Auflösung temporär anpasst, wenn man über eine gewisse Grenze (10x ?) rauszoomt. Für das starke rauszoomen kann ich mir zwei Anwendungsfälle vorstellen: 1. Rauszoomen und an einer anderen Stelle wieder reinzoomen geht schneller als weites Verschieben. Dabei brauche ich keine Bilder vom gesamten Bereich, sondern nur vom neuen Ziel. Das WMS-Plugin könnte also das Laden vorübergehend unterbrechen, bis ich wieder weit genug hineingezoomt habe. 2. Um einen Überblick zu bekommen. In diesem Fall brauche ich Bilder vom gesamten Bereich, aber nicht in der hohen Auflösung. Hier ist es ungünstig, wenn ich die Auflösung manuell zweimal umschalten muß, insbesondere wenn ich den Zoom-Level für die höchstmögliche Auflösung sehr genau einstellen muß. (WMS-Server, die bei zu großer Auflösung keine Bilder mehr liefern.) Das WMS-Plugin könnte in großen Schritten die Auflösung temporär automatisch verringern und nach genügendem Hineinzoomen wieder auf die ursprüngliche Auflösung zurückschalten. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwKFncACgkQnMz9fgzDSqfJJgCeL8q7SaHTGU4nOLIjV1ImXPcl fwwAn1YKvCPvn8nq1hwTj2Ab933fpkZC =J0Xd -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hilfe bei Grenzrelationen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 An die Relations-Experten: Ich habe auf der Insel Giglio die Nationalpark-Grenze eingetragen. Dazu habe ich eine neue Linie gezeichnet, wo die Grenze die Insel teilt. http://www.openstreetmap.org/browse/way/61188804 Der Rest der Nationalpark-Grenze ist identisch mit der Küstenlinie. Deshalb habe ich die Küstenlinie an den Verbindungspunkten in zwei Teile geteilt. http://www.openstreetmap.org/browse/way/61188803 Dann habe ich die Relation Grenze Isola del Giglio http://www.openstreetmap.org/browse/relation/41975 kopiert und entsprechend angepaßt, so daß sich die Nationalparkgrenze http://www.openstreetmap.org/browse/relation/950673 ergibt. (Die Insel Giannutri gehört komplett zum Nationalpark, es fehlen aber noch andere Inseln.) Ist das so in Ordnung? Das Validator-Plugin zeigt mir jetzt bei der Nationalpark-Grenz-Relation folgende Fehler an: Leere Rolle gefunden und Rolle outer fehlt. Klingt irgendwie nach Multipolygon. Ist das ein Fehler im Validator oder ist an meiner Relation etwas nicht in Ordnung? Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwKZAkACgkQnMz9fgzDSqd7RACdGPBJvgFx1Sy66aeCr7lzDqyV +C8An3LY6WAn2CfaR0ij/OuJtw/g2UFn =TVyq -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo Bernhard, die Beispielseiten gefallen mir. Das Spiel ist eine gute Idee. Könnte man für Schüler gebrauchen in Geographie. Da müßte man eine eigene Liste von Orten definieren können. Bei stufenlosen Zoom werden wohl die Kacheln mit der niedrigeren Auflösung vergrößert, bis die nächste Zoom-Stufe erreicht wird. Das sieht etwas pixelig aus. Hast Du mal probiert, ob es besser aussieht, wenn die Kacheln der höheren Auflösung verkleinert werden? Ich bekomme auf der Seite mit den OSM-Änderungen ab und zu eine Warnung Ein Skript auf dieser Seite ist eventuell beschäftigt oder es antwortet nicht mehr. Sie können das Skript jetzt stoppen oder fortsetzen, um zu sehen, ob das Skript fertig wird. Skript: http://www.khtml.org/osm/v0.52/khtml.js:1434 und manchmal wird das Firefox-Fenster für einige Zeit grau, d.h. es reagiert nicht mehr. Die Warnung über das nicht reagierende Skript kam auch mehrmals hintereinander, d.h. nach dem Schließen des Fensters mit Weiter ausführen kam ein paar mal sofort ein neues. Wenn Du mir sagst, was ich tun soll, helfe ich gern bei der Fehlersuche. (bin Softwareentwickler) Ich habe mit Firefox unter Linux (Ubuntu 64bit) getestet. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Am 21.05.2010 10:35, schrieb Bernhard Zwischenbrugger: Ich habe die Liste der Hauptstädte aus der Wikipedia geparst: http://en.wikipedia.org/wiki/List_of_national_capital_cities_by_population So eine Liste händisch zu erstellen ist glaub sehr mühsam. Wenn es aber möglich wäre solche Listen direkt aus der OSM Datenbank zu erstellen, dann wäre das schon ein Hit. Hallo Bernhard, meine Idee für Schüler wäre die Erstellung von Listen passend zum gewünschten Thema, beispielsweise europäische Hauptstädte, Hauptstädte der deutschen Bundesländer, Kreisstädte, Berge, Flüsse usw. Die Liste der zu findenden Orte könnte man manuell erstellen oder wenn eine passende Quelle (Wikipedia) vorhanden ist, auch automatisch extrahieren. Es sollte eine Möglichkeit zum automatischen Ermitteln der Zielkoordinaten geben. Vielleicht kann man eine Datei mit den erforderlichen Daten irgendwo hochladen und in der Spiel-URL einen Verweis auf die Datei angeben. So könnte man eine eigene Spielversion mit individueller Auswahl benutzen. Weitere Idee: Ziele zufällig sortieren Es ist leicht möglich die Kacheln der höheren Auflösung zu verwenden. Einfach den Zoomfaktor im Browser ändern STRG-. Das Ergebnis ist aber nicht wirklich gut. Die Beschriftung wird zu klein und ist nicht mehr lesbar. Der Zoonfaktor im Browser hat bei mir nur die Wirkung, daß generell alles skaliert wird und dadurch unscharf aussieht. Das ändert aber nichts am grundsätzlichen Verhalten. Ich meine die Umschaltung der Kacheln beim stufenlosen Zoom der Karte: Wenn ich beispielsweise den Zoom von 14 aus langsam hochstelle, werden die Grafiken immer weiter vergrößert und damit bei mir pixelig. Geht dann der Zoom von 14,9 auf 15, werden die Kacheln im nächsten Zoom-Level verwendet und sehen wieder gut aus. Auch mit geändertem Browser-Zoom wird es von 15 zu 14,9 pixelig. Wie sieht es aus, wenn bei 14,1 bis 14,9 nicht die Bilder von Zoomlevel 14 vergrößert werden, sondern die Bilder von 15 verkleinert? Oder den Sprung in die Mitte legen, beispielsweise im Bereich von 14,6 bis 15,5 die Kacheln in Zoom 15 verwenden? Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.05.2010 14:43, schrieb Bernhard Zwischenbrugger: Jetzt hab ich mal den Sprung bei 0.5 gemacht: http://www.khtml.org/osm/v0.57.5/ Das Problem ist jetzt, dass die Schrift verdammt klein wird. Zudem muss der Browser viel mehr Kacheln laden und alles wird langsamer. Ich persönlich finde es so schöner. Für den Firefox mit Linux hilft das aber alles nichts, das ist ein anderes Problem. Ich meine, es hilft doch. Die verkleinerten Kacheln sehen jedenfalls besser aus als die vergrößerten. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv2lJoACgkQnMz9fgzDSqeU2ACfbpcC4uj4z7GhL0BbREw92rvu BKYAoID6B5oQ0IDbQM5vyVvDRLcNPTA5 =SobZ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.05.2010 18:49, schrieb M∡rtin Koppenhoefer: 2010/5/21 Johann H. Addicks addi...@gmx.net: Wie war denn das Betreff der Mail? das weiss nur noch das Archiv [...] Date: Wed, 5 May 2010 16:09:27 +0200 Message-ID: i2h7acdb3651005050709h6a80838av66f8461cd6953...@mail.gmail.com From: =?UTF-8?Q?M=E2=88=A1rtin_Koppenhoefer?= dieterdre...@gmail.com Subject: [Talk-de] 2 neue WMS in Italien -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkv22iIACgkQnMz9fgzDSqdsnwCgkXXXke5zqnyp53ZOnxCDNqsv RbAAn2pDdpMPz+porO/nQl/WFk2gCJJx =00jY -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Massendownloads vom PCN - portale geografico nazionale
Am 18.05.2010 16:50, schrieb M∡rtin Koppenhoefer: OSM-Italien ist informell informiert worden, dass seit ein paar Tagen erkennbar versucht wurde, die Daten massenhaft systematisch herunterzuladen. [...] Eine übliche Nutzung z.B. mit JOSM über die WMS-Extension ist natürlich erlaubt bzw. sogar gewünscht. Kann man ausschließen, daß so etwas mit JOSM versehentlich passiert? Angenommen, ich stelle eine hohe Auflösung ein, öffne ein WMS-Layer und zoome später weit raus. Versucht JOSM dann, die ganze Fläche in der hohen Auflösung zu laden? Wenn ja, ergibt das auch einen systematischen Massendownload. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] virtueller garmin gesucht
Jonas Stein schrieb: ich lese immer wieder in verschiedenen Foren Aussagen der Art mein garnim zeigt dies oder das nicht an. Das kann von dem speziellen Gerätetyp oder sogar von der Firmware-Version abhängig sein. Beispielsweise unterscheiden sich die Geräte bei den verfügbaren Symbolen. da ich nun mal kein derartiges Gerät habe und auch kein aktueller Bedarf dafür besteht, suche ich einen virtuellen Garmin d.h. einen Emulator, der auf nem richtigen Rechner läuft. Das würde nur bedingt helfen. Wer soll sich die Arbeit machen, die Besonderheiten der verschiedenen Geräte nachzubilden. Man kann unter Linux mit qlandkarte Screenshots erstellen. Vielleicht hilft das auch. Screenshots von qlandkarte (oder Mapsource) helfen auch nur in Ausnahmefällen, wenn es ein Problem auf dem Gerät gibt. Bei einigen Geräten kann man mittels xImage oder Garmin-ScreenShot einen Screenshot vom Gerät selbst machen. Das hilft aber auch nur, wenn jemand ein Garmin-Gerät hat. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Git workflow (was: All in one Garmin Map - news)
Christoph Wagner schrieb: [...] Wenn du mit checkout in deinen spielplaetz-branch gewechselt bist, kannste da jetzt Änderungen machen, wie du lustig bist. Jedes Mal, wenn du eine halbwegs thematisch abgetrennte Änderung gemacht hast, die lauffähig ist, kannste die in deinen branch commiten Das passiert alles lokal auf deiner Platte. Da alles nur lokal passiert, kann man ohne Probleme auch unfertige oder ungetestete Zwischenstände einchecken. Gerade das ist aus meiner Sicht ein großer Vorteil, denn man kann eigene Fehler rückgangig machen. (Wenn man später nicht mehr alle Zwischenstände haben möchte, gibt es auch Möglichkeiten, diese wieder zu entfernen.) [...] Jetzt hast du das bei dir lokal gemerged und es muss noch irgendwie ins netz. [...] Zu diesem Zeitpunkt sollte natürlich ein lauffähiger Stand vorliegen. Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nauling braucht Hilfe mit Garmin und JOSM
Carsten Schwede schrieb: Am 21.04.2010 19:53, schrieb Christian Knorr: Wie bekommt er am einfachsten seine Tracks vom Garmin (GPSMAP 60 irgendwas) in JOSM? Ich dachte es würde ein Plugin geben, was das direkt kann. Im GPS-Gerät kann man einstellen, daß die Tracks auf die Speicherkarte geschrieben werden sollen, dann kann man diese entweder in den Kartenleser oder das Gerät in den massenspeichermodus bringen und dort auslesen. Es ist auf jeden Fall sinnvoll, die Tracks möglichst auf der Karte zu speichern, weil dort auch bei Speicherung im Sekundenabstand keine alten Daten gelöscht werden. Die GPX-Dateien auf der Karte enthalten aber nur die Tracks. Waypoints sind im internen Speicher und können nur über das Garmin-Protokoll ausgelesen werden. Wenn man Waypoints aus dem internen Speicher und Tracks von der Speicherkarte verwenden will, muß man die Daten in zwei Arbeitsgängen übertragen. GpsBabel kann Daten von Garmin-Geräten auslesen und es läuft auch unter Windows. Es gibt für JOSM ein GpsBabel-Plugin, ich habe es aber noch nie benutzt. Vielleicht kann man damit direkt aus JOSM die Datenübertragung mittels GpsBabel aufrufen. Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FotoMapping
Markus schrieb: Auf dem in JOSM geladenen GPX-Track werden die ebenfalls hochgeladenen Bilder aber statt am Track entlang georeferenziert verteilt, alle an einer Stelle angezeigt. Ungefähr da, wo ich den Track begonnen habe. Hallo Markus, hast Du in Josm die Funktion zur Synchronisierung benutzt? Möglicherweise ist es ein Zeitzonen-Problem. (Es ist schon länger her, daß ich das benutzt habe. Deshalb weiß ich keine Einzelheiten, wie man diese Funktion jetzt aufruft.) Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WMS von DigitalGlobe
Chris-Hein Lunkhusen schrieb: Du hattest mitbekommen, dass wir DG nur für Krisengebiete nutzen dürfen? Vergleichen darf ich überall. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WMS von DigitalGlobe
Sven Geggus schrieb: Claudius claudiu...@gmx.de wrote: http://wms.globexplorer.com/gexservlets/wms?SERVICE=WMSVERSION=1.1.1REQUEST=GetMapTRANSPARENT=TRUELAYERS=GlobeXplorer%20ImageSRS=EPSG:4326STYLES=FORMAT=image/jpeg; Wie ich bereits sagte, das ist so ein Non-Standard ESRI-Server, schreib mal ein REASPECT=false dazu, dann passt das. Ich habe genau diese Einstellung mit und ohne REASPECT=false sowie mit JOSM-Einstellungen Merkator und WGS84 Geografisch für die Insel Giglio ausprobiert. Josm-Remote-Link für den Bereich der Insel: http://127.0.0.1:8111/load_and_zoom?left=10.84367845461bottom=42.314205699637right=10.957318286149top=42.392477365724 Wenn ich das Bild an einer Stelle passend zu einer kurvenreichen Straße ausrichte gibt es nach weniger als einem Kilometer schon eine deutliche Abweichung. Mache ich etwas falsch? Beispielbild ohne manuelle Verschiebung: http://img688.imageshack.us/img688/5355/bildschirmfotojosmklein.png Ich nehme an, daß die Straßen und Wege in OSM ziemlich genau erfaßt sind. Die sind aus meinen GPX-Trackaufzeichnungen von mehreren Jahren entstanden. Mit Google-Luftbildern habe ich eine bessere Übereinstimmung als bei den DG-Bildern. Vorher hatte ich das an einer Stelle in Bayern getestet. Da waren die Abweichungen der DG-Bilder wesentlich geringer. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] village, hamlet, locality?
Bernd Wurst schrieb: Am Samstag 03 April 2010 02:04:03 schrieb Martin Koppenhoefer: - die Abgrenzung Weiler / Dorf würde ich sowohl formal (Weiler hat keine geschlossene Bebaung) als auch funktional (Weiler hat keine Gebäude mit zentraler Funktion, wie z.B. Kirche, Gasthaus, ...) machen. Autsch, nein, bitte nicht. Wenn du hier jedes Kuhdorf mit 20 Häusern und einer Kirche oder einem Gasthaus als village taggest, sieht das ziemlich beknackt aus. Was genau heißt sieht ziemlich beknackt aus? Zu viele Ortsnamen auf der Karte? Dann braucht der Renderer vielleicht Zusatzinformationen, um weniger relevante Namen zu unterdrücken. Ich denke, Martins Ansatz entspricht etwa dem üblichen Sprachverständnis in meiner Gegend (Voralpenland). Sowohl Dörfer als auch Weiler sind eher klein. Was hier als Weiler bezeichnet wird, besteht in der Regel aus weniger als 10 Bauernhöfen. Die Bewohner der kleinen Dörfer wären sicher nicht damit einverstanden, wenn Du ihre Ansiedlung als Weiler bezeichnest. Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Doppelbelegung von route=ferry
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Falk Zscheile schrieb: Am 2. März 2010 21:28 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 2. März 2010 17:53 schrieb Markus liste12a4...@gmx.de: Dass diese Relation als Verbindung gerendert wird (so wie die Hauptschifffahrtslinien im Schulatlas gezeichnet sind), macht nur auf Spezialkarten Sinn (also in kleinem Zoom und abstrahiert), oder bei strassenverbindenen Flussfähren (also in grossem Zoom bei kurzen Entfernungen und immer gleicher Streckenführung). -1, m.E. ist das ein gutes Feature das auf die Hauptkarte gehört. Eine Begründung Deiner Auffassung hätte in der Diskussion mehr geholfen als ein globales bin nicht einverstanden Hallo Falk, ich stimme Martin zu. Ich denke, es ist sinnvoll, regelmäßig genutzte Fährlinien einzutragen. Besonders im Fall von Inseln sind dies die einzigen Verkehrswege und deshalb auch für das Routing wichtig. Eine Verbindungslinie ist ein auf Papierkarten etabliertes Mittel, diese Schiffahrtslinien darzustellen. So bleibt mir Deine Auffassung leider schleierhaft. Aber Du kannst Dir ja zum Spaß mal Warnenünde anschauen, wo nur ein paar Rundfahrten und Fährlinien (bei weitem nicht alle) eingetragen sind. Rundfahrten finde ich natürlich nicht so wichtig. Das ist in meinem Verständnis auch keine Fähre. Im übrigen sind, wie Markus schon schrieb, die Fahrwasser in denen sich ein Schiff bewegen kann ausgetonnt. Die Ganze Ostsee liegt voller Tonnen, an denen sich die Schiffe entlang hangeln können, wenn sie nur wollen, z.B. Kiel--Fehmarn-Weg, Kiel-Ostseee-Weg, etc. Eine extra Linie brauch man dafür nicht. Nach meinem Verständnis soll nicht jedes Fahrwasser als Linie auf der Karte eingezeichnet werden, sondern nur regelmäßig benutzte Fährverbindungen. Siehe oben. Wobei mir immer noch nicht klar ist warum man quasi jeden Ostseehafen mit allen anderen verbinden sollte. Über kurz oder Lang wir wohl von jedem Hafen jeder andere einmal angelaufen werden. In der Ostsee sieht es wirklich schon etwas unübersichtlich aus. Bei so vielen Verbindungen wäre es vielleicht sinnvoll, auf einer Karte nicht die kompletten Verbindungslinien einzuzeichnen, sondern nur an jedem Hafen den Anfang anzudeuten und den Zielhafen anzugeben. Oder die Verbindungen mehr bündeln, wie es teilweise schon gehandhabt wird. Gibt es von jedem Ostseehafen zu jedem anderen Fährverbindungen? Wenn der Hafen irgendwann einmal angelaufen wird, ist das für mich kein Grund, dort eine Verbindungen einzutragen. Nach meinem Verständnis muß eine Fährverbindung regelmäßig bedient werden, je nach Entfernung im Bereich von mindestens wöchentlich bis mehrmals täglich. Entscheidend ist, dass keine Linien, sondern Punkte verbunden werden! Denn auf dem Wasser gibt es keine fixen Wege. Ausnahmen sind beispielsweise Flussfähren. Bitte erkläre mir den Sinn warum man einzeichnen sollte, dass eine Fähre von Rostock nach Helsinki in 8 von 10 Fällen Bornholm südlich passiert. WIr betrachten dies als idealisierte Streckenführung, weil das die häufigste Variante ist. Es gibt aber viele Fälle mit weniger Variation. Soweit ich das bisher beobachtet habe, fahren die Fähren von Porto Santo Stefano nach Giglio Porto (Insel Giglio) immer in einem Korridor von ein paar hundert Metern. Das trifft vermutlich auf viele Insel-Fähren zu. Ich gehe davon aus, daß es (derzeit) nicht möglich ist, die üblichen Fahrstrecken aus abstrakten Daten automatisch zu ermitteln. Deshalb unterstütze ich den pragmatischen Ansatz, idealisierte Verbindungslinien einzutragen. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEUEARECAAYFAkuNj0YACgkQnMz9fgzDSqeMtgCYk0mlxvXUCIQ02qrJ0k823sVs nACfUNHzrhgs4M9nmvF69W7BsMANewM= =mRcy -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schulprojekte mit OpenStreetMap?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ich habe einmal bei Projekttagen an einem Gymnasium eine zweitägige Einführung zu GPS, Geocaching und OSM für eine Gruppe von 10 interessierten Schülern gegeben. Dabei konnten alle Schüler der Schule jeweils ein paar Wunsch-Projekte auswählen und wurden dann nach Verfügbarkeit der Plätze eingeteilt. Am ersten Tag haben wir nach einer etwa einstündigen Einführung im Computerraum in zwei Kleingruppen ein paar Caches in der Umgebung der Schule gesucht, am zweiten Tag habe ich zuerst im Computerraum OSM und JOSM vorgestellt, dann haben wir in ein paar Straßen nahe der Schule das Mapping von Straßen und Hausnummern mittels Wegpunkten und Notizen sowie mit Fotos ausprobiert. Anschließend konnte ich wegen technischer Schwierigkeiten und knapper Zeit nur noch kurz die Verarbeitung der aufgezeichneten Daten mittels JOSM zeigen. Ich denke, daß für die praktische Arbeit kleine Gruppen (3-5 Schüler) sinnvoll sind. Jochen Topf schrieb: Das allerwichtigste ist, dass es einen erfahrenen OSMer gibt, der bereit ist das zu begleiten. OSM ist nicht einfach genug, als das ein Lehrer sich da mal einen Abend einliest und das alleine machen kann. Das sehe ich auch so. Es wäre ideal, wenn jeder Gruppe ein Begleiter mit OSM-Erfahrung zur Verfügung steht, um ggf. Fragen zu beantworten. Ansonsten sollte ein OSM-Kundiger per Telefon/Funk erreichbar sein und bei Hilfebedarf die Gruppen schnell vor Ort unterstützen können. Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkti4DAACgkQnMz9fgzDSqeJSQCbB8xBQPQYu3j9PwcHrZHQfwC7 SigAni8ZMWI+bpkP6QjrYcb0fb3ytfMG =aWk8 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlach/Firefox/flashplugin/Ubuntu-9.10 was ist kaputt?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joerg Fischer schrieb: Jedenfalls kann ich in o.g. Konfiguration auf der Webseite noch auf Bearbeiten klicken, mich anmelden, ich bekomme das Fenster mit der Auswahl ob ich live oder mit speichern arbeiten will und dann - ist Schluß. [...] Kann diesen Effekt jemand bestätigen oder sonst hilfreiche Hinweise geben? Bei mir tritt dieses Verhalten auch auf. Ich bin aber gerade mit einem Hardware-Wechsel von Debian testing 32-bit zu Ubuntu 9.10 64-bit umgestiegen, deshalb habe ich bisher angenommen, daß es entweder am 64-Bit-System liegt oder daß ich irgendetwas falsch installiert oder konfiguriert habe. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksgJFMACgkQnMz9fgzDSqfYBwCfX5fL3hRu2nswT8h8S5vq1GnK EkMAnAmEHVtM/nVFZ/DbI73AfH1YAF+W =IU3S -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM-Composer Beschriftungen auf Garmin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Nop, kann man einstellen, ob man bei bestimmten Objekten die Namen im Garmin angezeigt haben möchte? Und wo der Name bezogen auf das Symbol sein soll? Beispiel: Auf dem Garmin wird derzeit etwas rechts oberhalb des Wegweiser-Symbols der Name dargestellt. Es ist nicht klar zu erkennen, daß der Name zu dem Wegweiser gehört, insbesondere bei langen Namen. Es sieht etwa so aus .. NAME DES WEGWEISERS . . + (Wegweiser-Symbol) Bei Gebäuden wird der Name mittig über dem Objekt dargestellt. Da das nicht einheitlich ist, wird die Zuordnung erschwert. Ich möchte den Namen des Wegweisers nicht ständig auf der Karte sehen, sondern nur das kleine Popup wenn der Kartenzeiger darauf ist. Bei einem Berg (Poggio della Pagana auf Insel Giglio) ist mir aufgefallen, daß einmal der Name in Großbuchstaben rechts oberhalb des Symbols dargestellt wird und (scheinbar abhängig vom Zoomlevel) zusätzlich ein Kästchen mit dem Namen in Groß-Klein-Schreibung. Wenn dann der Zeiger auf dem Symbol steht, bekomme ich zusätzlich das Popup mit dem Namen. So habe ich den Namen bis zu 3x auf der Karte. Auch in diesem Fall möchte ich den ständig sichtbaren Namen (in Großbuchstaben) unterdrücken. Für meinen Geschmack ist diese verschobene Darstellung der Namen zu weit weg vom Symbol. Deshalb würde ich das gern einstellen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqOaesACgkQnMz9fgzDSqd+7wCfYN8T4rYl84sw5aknTpL/iDqo bWkAnif5mIAtTHyXAYbUI9bhXndPdKni =PJCr -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebaeude und Restaurants (Reit und Wanderkarte)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ekkeh...@gmx.de schrieb: Wichtig für das Reiten und Wandern ist eine genaue Aufschlüsselung der Tracks. Die sac_scale wird absichtlich nur so weit ausgewertet, wie sie für einen Nicht-Alpinisten nützlich ist. - footway wird nicht ausgewertet, ein Gehweg mit sac_scale macht für mich keinen Sinn - path normal oder mit sac_scale 1: rot gestrichelt - sac_scale 2 : rot gepunktet - sac_scale = 3: lila gepunktet, für Gelegenheitswanderer nicht empfehlenswert, für Pferde unpassierbar, Thema für eine echte Alpenkarte Sollte ich vielleicht mal in die Legende aufnehmen. :-) Hallo Nop, diese gepunkteten Wege sind auf dem Garmin schlecht zu erkennen. (Gestrichelt weiß ich jetzt nicht). Ich denke, daß sac_scale=hiking (T1) in der Regel genau so gut für Gelegenheitswanderer geeignet ist wie Tracks. sac_scale=mountain_hiking (T2) ist oft auch noch gut zum Wandern geeignet, vielleicht nicht mehr so gut zum Reiten. siehe Erklärung: sac_scale=hiking; T1 Wandern; Weg gut gebahnt.; Gelände flach oder leicht geneigt, keine Absturzgefahr; Keine Anforderungen sac_scale=mountain_hiking; T2; Bergwandern; Durchgehend gut ersichtlicher und gut begehbarer Weg.; Teilweise steil. Absturzgefahr möglich; Trekkingschuhe, Etwas Trittsicherheit, Etwas Ausdauer Das Problem bei sac_scale ist, daß hier mehrere verschiedene Kriterien enthalten sind. Deshalb ist die Einstufung etwas schwierig. Beispiele: Ist ein teilweise steiler Weg ohne Absturzgefahr T1 oder T2? Ist ein kaum erkennbarer, teilweise steiler Weg, bei dem man gelegentlich die Hände braucht, um eine meterhohe Stufe zu überwinden, immer T4? Auch wenn es keinerlei Absturzgefahr oder Seilsicherungen gibt? In meinem Fall (Insel Giglio) würde ich die meisten Wege als mountain_hiking einstufen, weil es manchmal steil ist und Stufen (Steine) vorkommen. Absturzgefahr gibt es eher selten.Einige der T2-Wege werden von den italienischen Urlaubern mit Badelatschen begangen. Es gibt dort eben 400m Höhenunterschied vom hoch gelegenen Hauptort zum Strand. Früher wurden nahezu sämtliche Wege mit Eseln zum Lastentransport genutzt. Auf einigen könnte man vermutlich auch reiten. Das ist dort aber nicht relevant. Ich schlage vor, die Darstellung etwas zu verändern: 1 rot durchgehend 2 rot gestrichelt 3 rot gepunktet, vielleicht etwas größere Punkte = 4 lila gepunktet Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqLn5IACgkQnMz9fgzDSqeXVACfaMpCaBPTp1Ranj/l7ymNRON9 QHcAoIp1COn372HBXfGYJi7DNumI8CCm =XlsB -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Testversion Srtm2Osm für OSM Composer bzw. Reit- und Wanderkarte
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo alle, der Ablageort der SRTM-Daten wurde zweimal geändert und der Server unterstützt jetzt nur noch HTTP, nicht mehr FTP. Deshalb hat das Programm Srtm2Osm nicht mehr funktioniert. Außerdem gab es noch Probleme mit Groß-/Kleinschreibung der Dateinamen. Ich habe das Programm so geändert, daß es mit dem neuen Server wieder funktioniert. Nop hat mir schon bestätigt, daß es damit geht. Das Programm gibt es als Testversion hier: http://bodo-m.de/Srtm2Osm/Srtm2Osm-1.6.1328.1.zip Die Änderungen sind noch nicht im SVN. Ich möchte erst noch ein paar Testergebnisse abwarten. Bitte informiert mich über Erfolg oder Fehler. Leider sind Server und Basisverzeichnis der SRTM-Daten hart codiert. Es ist nicht trivial, das auf eine Laufzeit-Konfiguration zu ändern. Bei der nächsten Änderung der Server wird das Programm wieder ausfallen. Um meine Version im OSM-Composer (mit Starthilfe-Set) zu verwenden, müssen die Dateien im Verzeichnis Tools/srtm2osm ausgetauscht werden. (Zu Details bitte Nop fragen, da ich mich mit dem OSM-Composer noch nicht auskenne.) Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpxM9EACgkQnMz9fgzDSqcdRgCdHN44qRnxpP7GIYFHyw3741Aa H8gAniWI1oJbmYegLCx/ac8bQUVhsKop =fbPZ -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wanderwege ohnen Namen (was: Wanderk arte für Schweiz und Südtirol)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc Schütz schrieb: Namen sind für mich so etwas wie Jakobsweg, Via Mala etc. Viele Wanderrouten haben so etwas einfach nicht. Das was du verwendest, ist aber eher eine Beschreibung. Da stimme ich zu, Nop schrieb: Nein. Wenn auf der Wandertafel oder auf dem Wegweiser oder im Verzeichnis der Wanderwege steht Wanderweg nach XXX dann ist das der Name des Weges. In diesem Fall halte ich das auch eher für eine Beschreibung. Auf dem Wegweiser in XXX steht dann vermutlich Wanderweg nach YYY oder YYY über ZZZ. Ich finde es durchaus sinnvoll, zwischen Name und Beschreibung zu unterscheiden und ggf. ein separates Tag für die Beschreibung zu verwenden. Manchmal gibt es auch Namen, die nicht offensichtlich sind. Beispiel (keine Relation sondern Namen am Weg) http://www.openstreetmap.org/?lat=47.56642lon=10.78012zoom=16 Hier hat jemand Beschreibungen, die möglicherweise auch auf Wegweisern stehen, als Namen eingetragen: über Rohrkopfhütte bis Tegelberghaus, alternative über Skipiste. Am Tegelberghaus wäre die passende Beschreibung für den gleichen Weg Talstation über Rohrkopfhütte. Da ich den wirklichen Namen Schutzengelweg kenne, habe ich das für den betroffenen Weg geändert. Wenn ich mich recht erinnere, steht der Name nicht auf den Wegweisern. Für einige Nutzer ist der offizielle Name sicher weniger aussagekräftig als eine Beschreibung des Wegverlaufs. In diesem Fall fände ich die Kombination aus Name Schutzengelweg und Beschreibung Tegelberg-Talstation - Rohrkopfhütte - Tegelberghaus sinnvoll. Deshalb unterstütze ich den Vorschlag von Jonas: name=Schutzengelweg description=Tegelberg-Talstation - Rohrkopfhütte - Tegelberghaus 2. Ohne Namen kann ein Weg nicht in das Wegeverzeichnis eingetragen oder von irgendjemand wiedergefunden werden. Damit kommt man nicht mehr an die Zusatzinformationen (Wegverlauf, Betreiber, Länge, Wiki/Weblinks) ran. Da gibt es verschiedene Möglichkeiten: man könnte für diesen Zweck ein neues Tag erfinden, oder man könnte eine Bezeichnung generieren (route=hiking, symbol=Roter Kreis = Wanderweg Roter Kreis bei Heidelberg). Oder zuerst Namen, dann ref, dann selbsterzeugte Bezeichnung probieren. Wenn ein description-Tag vorgesehen ist, könnte man das als Ergänzung zum Namen bzw. bei nicht vorhandenem Namen als Alternative verwenden. Das Schema für automatisch generierte Ersatz-Namen finde ich nicht praktikabel. Ich würde Wege ohne Namen (und ohne Beschreibung) einfach durchnumerieren. Dann bekommen die Wege Ersatz-Namen wie *1, *2 oder (1), (2) usw. Das gilt aber nur dann, wenn es außer Symbol und Wegfarbe weitere Zusatzinformationen vorhanden sind, so daß eine Referenzierung im Wegeverzeichnis sinnvoll ist. Wege ohne Zusatzinformationen müssen gar nicht ins Wegeverzeichnis. Trotzdem könnten Wegfarben oder Symbole auf der Karte dargestellt werden. Wenn auch fehlerhafte Relationen in der Karte dargestellt werden, führt das vielleicht auch dazu, daß die Fehler schneller auffallen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkphjNgACgkQnMz9fgzDSqeWZgCcCefN8bgC8svdNuYJXvAbvW9Q H8oAn1E/EgtDSNMIL76XgicKJ/qP5noq =+89O -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin in USB-Zustand versetzen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jan Tappenbeck schrieb: GPSMap 60 CSX! SLXViper schrieb: Jan Tappenbeck schrieb: weiß einer von Euch, ob man irgendwie den Garmin von außen in den USB-Zustand versetzen kann. Am besten immer mit demselben LW-Buchstaben um Karten hochzukopieren? Den USB-Massenspeichermodus braucht man zum Daten kopieren nur, wenn man keine Garmin-Software (oder nachgebaute) nutzen will Mir ist auch nichts bekannt, um das von außen umzuschalten. Ich vermute, es geht darum, Tracks und Wegpunkte auszulesen. Wegpunkte werden nur im internen Speicher abgelegt und können nur über das Garmin-Protokoll ausgelesen werden. Tracks werden begrenzt auch im internen Speicher abgelegt, aber überschrieben, wenn der voll ist. Diesen letzten Teil kann man auch über das Garmin-Protokoll bekommen. Wenn man die vollständigen Tracks haben möchte, muss man im Massenspeichermodus die GPX-Dateien von der Speicherkarte auslesen. Um den Ablauf zu vereinfachen, könnte man vielleicht ein Programm schreiben, das zuerst den internen Speicher ausliest, beispielsweise mittels Gpsbabel, dann auf das Erscheinen des Geräts als Datenträger wartet und automatisch die GPX-Dateien kopiert und ggf. löscht. So müßte man das Gerät anschließen, das Programm starten und nach Aufforderung durch das Programm das Gerät in den Massenspeichermodus schalten. Am Ende könnte das Programm das Gerät wieder freigeben (Hardware sicher entfernen). Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpc+OAACgkQnMz9fgzDSqdkEgCfYEwzta49XQyoQ5VnuF1OU5Rv NlYAn1g7mTOmv35G5swdUqXPy58It6RE =Aebw -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de