[Talk-de] TMC Validator nimmt jetzt Daten von Version 9.00 / Re: TMC: new location code table version 9.0 for Germany
André Riedel schrieb: Am 10. Februar 2010 14:02 schrieb Claudius claudiu...@gmx.de: Am 10.02.2010 11:27, Marcus Wolschon: http://www.bast.de/cln_005/nn_42544/DE/Aufgaben/abteilung-f/referat-f4/Location-Code-List/location-code-list-start.html Praktische Auswirkungen auf uns bzw. auf den TMC Validator? Die IDs werden ja nur fortgeführt und nicht geändert, oder? Also müsste nur die Datenbank des Validators aktualisiert werden, korrekt? Es werden auch einige gelöscht. Aber es wäre gut, wenn die Daten im TMC Validator nicht einfach ersetzt werden, sondern besser ergänzt. Dann könnte der TMC Versions-Schlüssel auch mal einen Sinn ergeben. Dann gibt es zum Beispiel Abschnitte mit LCLversion = 8.00;9.0 und welche nur mit einen von beiden. Ich denke wir sollten nur den aktuellen Stand mappen. Ich habe deshalb heute den TMC Validator aktualisiert. Historische TMC Daten sind doch eher uninteressant. z.B. wurde in Hamburg der Finkenwerder Knoten [1] gebaut. Dabei wurden ganz neue Straßen gebaut und auch einige Kreuzungen entfernt (Dafür gibt es auch ein paar neue). D.H. z.B. die Kreuzung Waltershofer Straße / Dadenauer Deicheweg gibt es nicht mehr. (Ist allerdings noch in dem TMC Daten drinn[2]) Also ich werde den Fokus für den TMC Validator darauf legen mehr zu validieren und nicht historische Versionen auszuwerten. Das ist auch nicht Trivial: Wenn es z.B. ein Segment gibt: In Version 8.00: A --- B D--- E und jetzt kommt in Version 9.00: ein Knoten dazu: A --- B -- C --- D -- E Dann hat B einen anderen Nächsten Knotenpunkt und D einen anderen vorherigen Knotenpunkt. Wie willst du jetzt B und D taggen? Ist das Segment noch das selbe? Was wird denn eigentlich im Verkehrsfunk ausgestrahlt? Sind die immer brandaktuell? Wird da eine TMCversion Nummer mitgesendet? Gibt es eigentlich irgendwo mal ein paar Beispiel-Rohdaten von Verkehrsfunksendern? Gruß Sven [1] http://www.hamburg-port-authority.de/component/docman/doc_download/53-finkenwerder-knoten.html [2] http://osm-tmc.anders-hamburg.de/point.php?lcd=46161 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zu TMC-Punkten
Am 14. Februar 2010 07:50 schrieb Marcus Wolschon marcus.wolsc...@googlemail.com: 2010/2/13 André Riedel riedel.an...@gmail.com: Generell ist anzumerken, dass laut Marcus keine TMC-Meldungen für die TMC-Points vorgesehen sind. Das heißt, es wird keine Meldung Parkplatz ist überfüllt kommen. Wann soll ich das gesagt haben? http://lists.openstreetmap.org/pipermail/talk-de/2010-January/061728.html ;-) Wenn du deine Aussage revidierst, müssen wir das Tagging-Modell ergänzen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Hallo Rolf, Rolf Meyerhof wrote: Hallo Mein Ziel ist die Tonnen bei OSeaM in der Karte anzeigen zu lassen. Das geschieht nur wenn ich diese Tonnen mit dem OSeaM Editor bearbeite Dann hast Du aber OpenStreetMap nicht verstanden. OpenStreetMap ist eine Datenbank, in der wir Dinge erfassen, die in der Realitaet existieren. Du bist meiner Frage ausgewichen. Du hast in der OpenStreetMap-Datenbank die Information, dass diese Tonne ein rot-weisses Topzeichen besitzt, entfernt. Das ist *nur* dann zulaessig, wenn diese Tonne tatsaechlich kein rot-weisses Topzeichen hat. Hat die Tonne in der Realitaet ein rot-weisses Topzeichen, dann war deine Handlung falsch (entweder aus Irrtum oder weil Du mit fehlerhafter Software arbeitest). Öffne ich das Tonnen Menue sehe ich eine gelbe Tonne mit einem gelben Kreuz und das ist falsch. Ein anderes Topzeichen kann nicht ausgewählt werden. Darum bleibt die Tonne ohne Topzeichen. Was dann der Editor ändert oder nicht ändert ist so Du selbst schreibt ein Problem der Software. Nein. Wenn die Software aufgrund von Maengeln Dich dazu verleitet, Daten in der Datenbank zu verfaelschen, dann hat die Software ein Problem und sollte nicht mehr auf die OSM-Daten losgelassen werden - und ich weiss immer noch nicht, ob hier ueberhaupt was verfaelscht wurde, ich weiss nicht, ob die besagte Tonne ueberhaupt ein rot-weisses Topzeichen hat oder nicht, aber *wenn* sie eines hat, dann hast Du unbestreitbar Daten verfaelscht. Du musst das doch wissen: Du musst doch fuer die Bearbeitung der Tonne irgendwelche Quellen haben, vermutlich warst Du selbst vor Ort - also was ist das nun fuer eine Tonne, in der Realitaet? Du musst sie doch gesehen haben, Du musst doch wissen, ob sie ein rot-weisses Topzeichen hat oder nicht. Wenn der OSeaM-Editor ploetzlich ueberall, wo Du eine gelbe Tonne eintraegst, Telefonzellen in die Datenbank schreibt, dann ist das zwar nicht Deine Schuld, sondern die des kaputten Editors, aber in dem Moment, wo Du darauf aufmerksam gemacht wirst, dass Du hier mit kaputter Software Daten verfaelschst, musst Du damit aufhoeren, bis die Autoren der Software das reparieren konnten. Also ich mache Dich jetzt hiermit darauf aufmerksam, dass Du mit der Software, die Du im Moment verwendest, rot-weisse Topzeichen loeschst. Das ist ausschliesslich dann zulaessig, wenn Du aufgrund von eigenen Aufzeichnungen oder sonstigen Informationen weisst, dass diese Tonnen tatsaechlich kein rot-weisses Topzeichen haben. Alles andere (ich will, das die Tonne bei name von meinem Hobbyprojekt richtig angezeigt wird, deswegen habe ich so lang an den Tags rumgedreht, bis die Tonne fuer mich richtig war) entspricht nicht der Art, wie wir bei OpenStreetMap arbeiten. Ich bin ziemlich unvoreingenommen an diese Sache herangegangen, aber wenn es wirklich so ist, dass Du ohne Ruecksicht und Kenntnis der Sachlage mit einem Spezialeditor hier an irgendwelchen Tonnen herumklickst, bis sie in diesem Spezialeditor richtig sind, und dabei korrekte Information (ich weiss immer noch nicht, ob diese Tonne ein rot-weisses Topzeichen hat oder nicht...) entfernst, dann ist es nicht nur zulaessig, sondern notwendig, alle Deine Aenderungen rueckgaengig zu machen - wer weiss, was Dein Spezialeditor sonst noch alles kaputt macht, ohne dass Du es merkst. Stell Dir vor, es kommt noch jemand drittes dazu, macht eine OpenOceanMap auf, programmiert einen Spezialeditor, der aber leider die Tonnen, die Du malst, nicht anzeigt, und man muss in dem Spezialeditor erst auf diese Tonne korrigieren klicken, damit sie auf OpenOceanMap erscheint, und dabei werden dann alle OSeaM-Tags geloescht. Du sprichst einen der Benutzer darauf an, und der weist empoert alle Schuld von sich: Ich mache hier Karten fuer Seefahrer, und mir kommt es in erster Linie darauf an, dass diese Tonne in der Karte richtig enthalten ist, und das geht nur, wenn ich in meinem Editor auf den diese-Tonne-korrigieren-Button klicke. Glaubst Du, so kommen wir weiter? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
Hallo, Arne Johannessen wrote: [1] Es geht um den letzten ganz unten auf folgender Seite abgebildeten Tonnentyp (Bild 34): http://www.elwis.de/Schifffahrtsrecht/BinSchStrO/Anlagen/Anlage-8/ Aha. Also *hat* diese Tonne ein rot-weisses Topzeichen, und der Editor einen Fehler. Rolf, bitte verwende diesen Editor nicht mehr (oder zumindest nicht mehr zum Editieren gelber Tonnen), bis der Fehler verbessert wird. Ich hoffe, dass man den Editor so erweitern kann, dass er nicht einfach um diesen Sonderfall ergaenzt wird (und wir dann bei gelben Tonnen mit gruen-weissen Topzeichen im suedchinesischen Meer das gleiche Problem wieder haben), sondern dass man den Editor so entschaerfen kann, dass er Zeugs, das er nicht versteht, auch nicht kaputt macht... Olaf/Markus - es waere super, wenn es gelaenge, OpenSeaMap-Benutzer dahingehend zu sensibilisieren, dass es ausser OpenSeaMap noch andere Anwendungen der Daten gibt und dass die Daten niemandem allein gehoeren - und dass taggen fuer den Renderer auch bei OSeaM keine gute Idee ist... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JSOM: Wanderkarten-Style deaktivieren
Am 12.02.2010 21:37, schrieb NopMap: jan99 wrote: ich habe heute morgen mal den Style der Wanderkarte für JOSM installiert und wollte nun wieder zurück. Geht aber irgend wie nicht - auch mit löschen des Pfades in den Einstellungen. Kann mir einer etwas dazu sagen ? Vermutlich hat sich der Style in Dich verliebt. :-) Normal: Unter Einstellungen / 3.Icon Karteneinstellungen / Mappaint Stile solltest Du den Stil auswählen und entfernen können. Wenn das nicht hilft, Ticket einstellen und unter Einstellungen / letztes Icon Erweiterte Einstellungen den Wert hinter mappaint.style.sources löschen da steht aber gar kein Wert !!! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendern von Routen
Hallo! Gary68 wrote: 1. man könnte zusätzlich zur normalen Beschriftung von Wegen diesen die Beschriftung der Route angedeien lassen. Müsste man evtl. alle Beschriftungen erst sammeln, damit man sie später auf einmal hinzufügen kann. Damit sie sich nicht überdecken. Würde ich nicht machen. Wenn man bedenkt, daß ein Wegstück Teil von beliebig vielen Routen sein kann, wird die Karte ganz schön zugemüllt. Ich habe ein solches Verfahren in Composer zwar mal eingebaut, nutze es aber überhaupt nicht. Gary68 wrote: 3. könnte man Symbole (aus File bzw. Filename) über die verwendeten Wege legen. Diese müssten allerdings - pro Route - auch irgendwoher kommen, aber nicht aus dem RuleFile. Ist das in den Tags der Routen irgendwo hinterlegt? Z.B. für die Wanderkarte? Für Wanderrouten findest Du solche Infos teilweise im Tag osmc:symbol [1]. Viel davon steht aber auch nur als Prosa im symbol-Tag, das muß dann manuell umgesetzt werden, wenn man es auswerten will. Für manche Wanderrouten ist auch eine komplette Grafik im Wiki hinterlegt und mit wiki:symbol referenziert. bye Nop [1] http://wiki.openstreetmap.org/wiki/DE:OSMC_Reitkarte#Wandermarkierungen_direkt_per_Tag_steuern -- View this message in context: http://n2.nabble.com/Rendern-von-Routen-tp4567380p4569769.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JSOM: Wanderkarten-Style deaktivieren
Hi! jan99 wrote: Wenn das nicht hilft, Ticket einstellen und unter Einstellungen / letztes Icon Erweiterte Einstellungen den Wert hinter mappaint.style.sources löschen da steht aber gar kein Wert !!! Soweit ich weiß, ist das die einzige Stelle wo der Stil verankert ist. Bist Du ganz sicher, daß der Stil noch aktiv ist? Was mir noch einfällt: Die Hintergrundfarbe mußt Du auch noch von Hand zurücksetzen, lustigerweise habe ich keinen Weg gefunden, das im Stil zu machen. bye Nop -- View this message in context: http://n2.nabble.com/JSOM-Wanderkarten-Style-deaktivieren-tp4562800p4569778.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Hallo Frederik, die Regelung, dass dass die beiden See-Tagging-Schemata bitte friedlich nebeneinander her existieren sollen funktioniert seit einigen Monaten beidseitig richtig gut. Ich freue mich, dass dadurch endlich Ruhe eingekehrt ist. Dadurch können wir unsere Arbeit wieder auf das Wesentliche konzentrieren. Die Attribute von OpenSeaMap erkennt man am Namensraum *seamark* und *harbour* Damit werden nautische Objekte von anderen unterschieden. Zur Steuerung der objektinternen (Pseudo)Hierarchie benutzen wir seamark auch als Master-tag. Unsere Editoren bearbeiten konsequent und ausschliesslich Daten, die in diesen Namensräumen liegen. Die Editoren ändert in diesem Namensraum ausschliesslich Daten, die der Benutzer ändert. Auch wenn da nun grad zwei einander gegenseitig etwas gelöscht haben, so ist das alles kein Problem, sondern kann recht einfach gelöst werden. Voraussetzung ist, dass man in guter Absicht handelt, sich gegenseitig nichts anderes unterstellt, bereit ist zu lernen, und sich gemeinsam um Lösungen bemüht. Aufgaben löse ich am liebsten nach vorne gewandt, also nach Lösungen suchend (statt nach Schuldigen). So wie Du es ja auch machst. Wenn mit der Lösung auch noch gleich strukturelle oder methodische Fortschritte erzielt werden: umso besser! Die Erweiterung ist bereits in Arbeit :-) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
die Regelung, dass dass die beiden See-Tagging-Schemata bitte friedlich nebeneinander her existieren sollen funktioniert seit einigen Monaten beidseitig richtig gut. Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? Warum nicht wenigstens ein Schema was global läuft, wenn sich das schon direkt auf der OSM DB abspielen muss? Mir fällt keine sinnvolle Begründung ein. Wenn die Seiten jeweils anders präsentieren oder nur einen Teil verwenden dann ist das ja kein Problem. Aber warum entwickelt man nicht ein gemeinesames Schema, das man dann auch propblemlos von OSM Seite her nachlesen und anwenden kann, damit auch problemlos von eventuell weiteren Anwendungen? Damit erübrigt sich dieses total sinnlose rumgeeiere und auch der reine OSMer muss sich nicht mehr über irgendwelche Eingriffe ärgern. Auch erübrigt das manch sinnlose Redundanz. Freietonne will z.B. bei Kontaktdaten an Schleusen ein waterway:lock:phone. Damit das auch alle anderen lesen können, muss man wieder ein extra phone setzen. Sicher ist es einfacher über den ganzen Dump einfach nach diesem Schlüssel zu suchen. Aber wäre es im nicht im Sinne von OSM, einfach nur phone für alle zu setzen? Da muss die Anwendung eben die relevanten Elemete wie eben in dem Fall lock vorfiltern statt nach Namensräumen über alles zu suchen. Man stelle sich mal vor andere würde das genauso machen. Irgendwann hat man die exakt gleiche Information unter zig Namensräumen in als x facher Kopie. Die Haupt DB wird sinnlos aufgebläht und bei einer Änderung steigt der Aufwand. Statt einmal phone zu ändern, muss man meinetwegen 20 Schlüssel ändern. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Am 14. Februar 2010 13:14 schrieb Mirko Küster webmas...@ts-eastrail.de: die Regelung, dass dass die beiden See-Tagging-Schemata bitte friedlich nebeneinander her existieren sollen funktioniert seit einigen Monaten beidseitig richtig gut. Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? Warum nicht wenigstens ein Schema was global läuft, wenn sich das schon direkt auf der OSM DB abspielen muss? Mir fällt keine sinnvolle Begründung ein. Genau das selbe wollte ich gerade auch fragen! Sind es ideelle oder kommerzielle Gründe? Wenn die Seiten jeweils anders präsentieren oder nur einen Teil verwenden dann ist das ja kein Problem. Aber warum entwickelt man nicht ein gemeinesames Schema, das man dann auch propblemlos von OSM Seite her nachlesen und anwenden kann, damit auch problemlos von eventuell weiteren Anwendungen? Damit erübrigt sich dieses total sinnlose rumgeeiere und auch der reine OSMer muss sich nicht mehr über irgendwelche Eingriffe ärgern. Die beiden Projekte sollten sich mal überlegen, dass sie in OSM eine Minderheit darstellen. Nicht das jemand auf die Idee kommt zu beschließen, dass diese Dinge gar nichts mehr in der OSM Datenbank verloren haben. Bisher konnte man sich in anderen Bereichen meist gut einigen oder ein Problem mit nur geringer Redundanz aus der Welt schaffen. Um die Seekarten gibt es jedoch immer wieder Ärger. Ich wünsche mir eine Erklärung, warum das so ist. Warum gibt es zwei Projekte, die für mich als Landratte so erscheinen, als ob sie das gleiche wollen, die nicht nebeneinander, sondern gegeneinander zu arbeiten scheinen. Hat OSM das nötig? Ist es das, was die Community möchte? Bitte um Antworten, um Vorurteilen vorzubeugen und um die definitive Bestätigung, dass es nicht um kommerzielle Interessen der beiden Parteien geht. Netter Gruß Torsten Breda ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Am Sonntag 14 Februar 2010 13:14:27 schrieb Mirko Küster: Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? Warum nicht wenigstens ein Schema was global läuft, wenn sich das schon direkt auf der OSM DB abspielen muss? das hab ich mich auch schon mal gefragt... Mir fällt keine sinnvolle Begründung ein. da wuesste ich nur eine: ich halte es durchaus fuer sinnvoll, alternative tagging-schemata und neue ansaetze auszuprobieren. das zeiht nunmal auch nach sich, dass daten redundant eingetragen werden. irgendwann setzt sich vieleicht eins davon durch, man vereint beide ansaetze, oder verwirft es als untauglich. so oder so kann man dadurch nur gewinnen. wie die sachlage bei dieser seezeichengeschichte ist, kann ich nicht beurteilen. aber mir scheint, die beiden projekte existieren lange genug, um eine evaluationsphase hinter sich zu haben... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Hi! Mirko Küster wrote: Naja, das ist ja auch das erste mal, das jemand danach fragt - wäre sehr verwunderlich dazu schon ein Howto zu finden. :-) Zumindestens der erste der öffentlich fragt, dessen Frage auch beachtet wurde oder sich überhaupt traut zu fragen. Ich bin bei meinen Versuchen auf dutzende Probleme gestoßen. Einige davon unter anderem auch unbeantwortet im Forum liegend. Naja, zumindest das erste mal, daß es jemand im Zusammenhang mit OSM Composer erwähnt. Zu den ganzen Osmosis-Geschichten und Problemen mit anderen Tools auf dem händischen Weg kann ich nichts sagen. Mirko Küster wrote: Da muss ich die Bounds Schachtel aus data.osm leider wieder von Hand einfügen. Osmosis kickt die leider, gibts eventuell einen Befehl der die wieder in den Output übernimmt? Auch nur die lokale Antwort: In den Output von Composer kann ich's einbauen. Werde ich wohl auch tun weil Kosmos auch danach fragt. Mirko Küster wrote: Das ist ja im grunde das gleiche wie gestückeltes Daten nachladen in OSM. Da läuft das ohne Probleme. Nur hier im Composer nicht. Der macht 5 Kacheln und dann ist das ganze Netzwerk ausgebremst. Aber ansich kein Problem, mir gehts nur um kleine regionale Ausschnitte, kann man als File über JOSM holen und laden. Vielleicht weil Composer immer versucht, 5 Kacheln parallel runterzuladen? Auf jeden Fall funktioniert es woanders. Mirko Küster wrote: Die *_data.osm kann JOSM garnicht erst lesen Das Attribut 'version' für das OSM Element ID 2632366 fehlt. Kosmos, Osmosis, mkgamp usw. können die Daten lesen. JOSM stellt sich quer, weil die API-Version mit 0.6 angegeben ist und kein Versionsattribut. Das ist aber für die offline-Verarbeitung völlig egal. Wenn Du sie in JOSM laden willst, API-Version im Kopf auf 0.5 setzen, dann nörgelt er zwar rum, aber lädt sie. Die *_realtion.osm sind in der Tat wurscht, die hat Composer schon ausgewertet. Man könnte noch die *_poly.osm dazumergen für Multipolygone, aber die scheint Kosmos nicht zu verarbeiten. Mirko Küster wrote: Ich brauche praktisch die eigentlichen Member der Relation, aber nicht mit ihren eigenen wegbezogenen Tags, sondern blank ohne ID (Ansonsten hagelt es wegen gleicher ID Konflikte), mit den Eigenschaften bzw. Tags der Realtion selbst. Also route=hiking, name, osmc:symbol direkt am Weg. Diese so aufbereiteten Wege kann man dann über die eigentlichen Daten legen und entsprechend rendern. So kann man das Problem der nicht verabeiteten Relationen umgehen. Momentan mache ich das für jede einzelne Route von Hand. Relation separieren, Member laden, wegbezogene Tags löschen, die Mermale der Relation allen Wegen verpassen. Alles duplizieren, in neue Ebene kopieren um die IDs loszuwerden, das Wegepaket wieder auf die richtige Position schieben, File speichern. Danach alle Einzelrouten mergen und dann mit den eigentlichen Daten mergen. Das kann man mal machen, aber wenn sich Wege verschieben, Member ändern, muss man das für die betroffenen Routen jedesmal neu machen. Bei entsprechender Aktivität in den Daten wirst du irgendwann ramdösig. Desshalb suche ich einen Weg das ganze weitgehend automatisch zu verarbeiten Ich würde sagen, wir reden noch aneinander vorbei, meinen aber das Gleiche. Der ganze, mühevolle Prozeß, den Du da beschreibst, wird von Composer bereits automatisch erledigt. Bis auf die Aktivierung von Multipolygonen, falls Kosmos die überhaupt kann. Das einzige Problem ist es jetzt noch, einen Satz Renderregeln zu haben, der die Wandermarkierungen richtig anzeigt. Ich hab inzwischen auch mal ein wenig gebastelt und Composer beigebracht, einen Satz Renderregeln für Kosmos zu generieren. Hier das Ergebnis: http://topo.geofabrik.de/Beispiel_Kosmos.jpg Zum Vergleich das Original mit Mapnik gerendert http://topo.geofabrik.de/?lon=10.1742lat=49.4006zoom=15 Das ist jetzt nur ein Prototyp und ich verwende die unveränderten Renderregeln der Reit/Wanderkarte. Da sind Elemente wie z.B. die Muster für Wälder oder Steinbrüche enthaltne, die Kosmos nicht kann. Das Kartenbild läßt sich da sicher noch optimieren. Aber wenn ich das Ganze in die GUI sauber eingebaut habe, dann müßtest Du in Composer nur noch das Kosmos-Projekt als Ziel angeben und er kümmert sich um die Aufbereitung aller Wanderwege. Die generierten Renderregeln kannst Du direkt verwenden oder noch manuell ummodeln. Und falls Du Bedarf hast, kannst Du auch eine analoge Garminkarte erzeugen. bye Nop -- View this message in context: http://n2.nabble.com/KOSMOS-Beispiel-Wanderkarte-tp4554015p4569985.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planet-Extrakt D-A-CH
Hallo Stefan, Ich kann ja das Gebiet im Süden (und im Osten) noch ein wenig erweitern, das sollte kein Problem sein. Welcher Koordinatenbereich würde Dir denn nützen? Oder benötigst Du das Gebiet genau auf die Landesgrenzen ausgeschnitten? Bei mir sind es erst Ideen, die mir im Kopf herumspuken; noch nichts Konkretes.. Um D-A-CH komplett zu haben, müsstest Du nach Süden um 0.2° und nach Osten um 1.5° erweitern (bzw. wenn ich das richtig sehe für NaviPOWN immer um ganze Grade?). Du kannst ja mal einen Probe-Durchlauf mit E5-E18/N45-56 machen und schauen, wie sehr sich die Rechenarbeit/Datenmenge mit Wien, Mailand und Venedig vergrössert und dann selber entscheiden, ob Du das beibehalten möchtest. Wer weiss, vielleicht hilft Dir D-A-CH gegenüber Deutschland plus im NaviPOWN-Marketing auch etwas.. ;) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] An die Vektorgrafiker - SVG und Rendering
hallo frederik, hallo andre, vielen dank, mit path geht es wunderbar. ich hatte einige polygone m. löchern auch mit polygon hinbekommen... einfache tests waren kein problem. ciao gerhard On Sun, 2010-02-14 at 00:23 +0100, Frederik Ramm wrote: Hallo, Gary68 wrote: polygon fill-rule=evenodd fill=#919191 points=833,197 824,181 836,174 819,147 807,155 797,140 948,46 990,113 973,123 967,113 833,197 894,135 880,111 905,96 919,121 894,135 853,161 838,137 862,122 877,146 853,161 937,111 920,86 945,69 962,95 937,111 / SVG-Polygone koennen keine Loecher haben. Bildlich gesprochen, versuchst Du oben, ein Polygon mit Loechern zu zeichnen, ohne dabei den Stift abzusetzen! Richtig waere: path style=fill:#919191;fill-rule:evenodd d=M 833,197 L 824,181 L 836,174 L 819,147 L 807,155 L 797,140 L 948,46 L 990,113 L 973,123 L 967,113 z M 894,135 L 880,111 L 905,96 L 919,121 z M 853,161 L 838,137 L 862,122 L 877,146 z M 937,111 L 920,86 L 945,69 L 962,95 z / Mit dem z wird der Pfad geschlossen (Linie zurueck zum Start), und mit dem M wird ohne Linie zu einer neuen Position gesprungen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Am 14.02.2010 13:25, schrieb Torsten Breda: Sind es ideelle oder kommerzielle Gründe? Menschliche. Die Mitstreiter können schlicht nicht miteinander. Die beiden Projekte sollten sich mal überlegen, dass sie in OSM eine Minderheit darstellen. Nicht das jemand auf die Idee kommt zu beschließen, dass diese Dinge gar nichts mehr in der OSM Datenbank verloren haben. Sind wir jetzt schon soweit, Minderheiten rauszuwerfen? Ich hoffe nicht, denn dann bleibt von OSM nicht viel übrig. Bisher konnte man sich in anderen Bereichen meist gut einigen oder ein Problem mit nur geringer Redundanz aus der Welt schaffen. Um die Seekarten gibt es jedoch immer wieder Ärger. Das liegt halt daran, daß es zwei Parteien gibt, die sich nicht einigen wollen. Aber fangen wir jetzt an die Radwege rauszuwerfen, weil sich die Radfahrer nicht auf ein Schema einigen können? Ich hoffe nicht. Ich wünsche mir eine Erklärung, warum das so ist. Warum gibt es zwei Projekte, die für mich als Landratte so erscheinen, als ob sie das gleiche wollen, die nicht nebeneinander, sondern gegeneinander zu arbeiten scheinen. Hat OSM das nötig? Ist es das, was die Community möchte? Bitte um Antworten, um Vorurteilen vorzubeugen und um die definitive Bestätigung, dass es nicht um kommerzielle Interessen der beiden Parteien geht. Ich hatte bislang nicht den Eindruck, daß es um kommerzielle Interessen geht - aber das weiß man ja immer erst nachher. Das sind einfach zwei Gruppen die sich nicht einig werden und jeweils laut aufschreien wenn der eine dem anderen das Förmchen geklaut hat ;-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Vielleicht weil Composer immer versucht, 5 Kacheln parallel runterzuladen? Auf jeden Fall funktioniert es woanders. Ich weiß nun nicht wie das genau arbeitet. Vielleicht hängt er sich auf, weil er eventuell alle vorhandenen Netzwerkadapter abfragt und eben bei mehreren mit Fehlern bombardiert wird? Bei mir sind 3 davon im Einsatz. Einer nach draußen für Internet, einer intern der draht und drahtlos verteilt und einer der Daten über Sat reinholt. Letzte beide wären in dem Fall Sackgasse. Ich deaktiviere die mal und probiere es. Die *_realtion.osm sind in der Tat wurscht, die hat Composer schon ausgewertet. Man könnte noch die *_poly.osm dazumergen für Multipolygone, aber die scheint Kosmos nicht zu verarbeiten. War aber so schonmal ein automatisiserter Schritt mehr. Ansonsten musste ich die Relationen von Hand separieren. Oder entsprechend die XAPI arbeiten lassen. Ich würde sagen, wir reden noch aneinander vorbei, meinen aber das Gleiche. Der ganze, mühevolle Prozeß, den Du da beschreibst, wird von Composer bereits automatisch erledigt. Bis auf die Aktivierung von Multipolygonen, falls Kosmos die überhaupt kann. Das einzige Problem ist es jetzt noch, einen Satz Renderregeln zu haben, der die Wandermarkierungen richtig anzeigt. Die Frage ist, was muss man tun und wo findet man nun diese neuen Wege ohne ID, welche die Tags ihrer Relation geerbt haben? Das ganze reicht als normales OSM File, um es dann beispielswe per Osmosis mit Daten und SRTM verbinden zu können. Der Rest läuft über Osmarender automatisch. Renderregeln brauche ich in dem Fall nicht, die blanken Wege m,it den tags der Relation. Enstprechende Renderregeln samt Symbolen habe ich schon. Auch für die Wege die man bisher nur mit Text darstellen konnte. Alles fertig, es fehlen nur die Wege. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
-Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Frederik Ramm Gesendet: Sonntag, 14. Februar 2010 11:00 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] (kein Betreff) Hallo Rolf, Rolf Meyerhof wrote: Hallo Mein Ziel ist die Tonnen bei OSeaM in der Karte anzeigen zu lassen. Das geschieht nur wenn ich diese Tonnen mit dem OSeaM Editor bearbeite Dann hast Du aber OpenStreetMap nicht verstanden. OpenStreetMap ist eine Datenbank, in der wir Dinge erfassen, die in der Realitaet existieren. Hallo Frederik Frage: Machen dieses erfassen nur aus Selbbstzweck oder wollen wir diese Daten auch einmal benutzen? Gruß Rolf Du bist meiner Frage ausgewichen. Du hast in der OpenStreetMap-Datenbank die Information, dass diese Tonne ein rot-weisses Topzeichen besitzt, entfernt. Das ist *nur* dann zulaessig, wenn diese Tonne tatsaechlich kein rot-weisses Topzeichen hat. Hat die Tonne in der Realitaet ein rot-weisses Topzeichen, dann war deine Handlung falsch (entweder aus Irrtum oder weil Du mit fehlerhafter Software arbeitest). Öffne ich das Tonnen Menue sehe ich eine gelbe Tonne mit einem gelben Kreuz und das ist falsch. Ein anderes Topzeichen kann nicht ausgewählt werden. Darum bleibt die Tonne ohne Topzeichen. Was dann der Editor ändert oder nicht ändert ist so Du selbst schreibt ein Problem der Software. Nein. Wenn die Software aufgrund von Maengeln Dich dazu verleitet, Daten in der Datenbank zu verfaelschen, dann hat die Software ein Problem und sollte nicht mehr auf die OSM-Daten losgelassen werden - und ich weiss immer noch nicht, ob hier ueberhaupt was verfaelscht wurde, ich weiss nicht, ob die besagte Tonne ueberhaupt ein rot-weisses Topzeichen hat oder nicht, aber *wenn* sie eines hat, dann hast Du unbestreitbar Daten verfaelscht. Du musst das doch wissen: Du musst doch fuer die Bearbeitung der Tonne irgendwelche Quellen haben, vermutlich warst Du selbst vor Ort - also was ist das nun fuer eine Tonne, in der Realitaet? Du musst sie doch gesehen haben, Du musst doch wissen, ob sie ein rot-weisses Topzeichen hat oder nicht. Wenn der OSeaM-Editor ploetzlich ueberall, wo Du eine gelbe Tonne eintraegst, Telefonzellen in die Datenbank schreibt, dann ist das zwar nicht Deine Schuld, sondern die des kaputten Editors, aber in dem Moment, wo Du darauf aufmerksam gemacht wirst, dass Du hier mit kaputter Software Daten verfaelschst, musst Du damit aufhoeren, bis die Autoren der Software das reparieren konnten. Also ich mache Dich jetzt hiermit darauf aufmerksam, dass Du mit der Software, die Du im Moment verwendest, rot-weisse Topzeichen loeschst. Das ist ausschliesslich dann zulaessig, wenn Du aufgrund von eigenen Aufzeichnungen oder sonstigen Informationen weisst, dass diese Tonnen tatsaechlich kein rot-weisses Topzeichen haben. Alles andere (ich will, das die Tonne bei name von meinem Hobbyprojekt richtig angezeigt wird, deswegen habe ich so lang an den Tags rumgedreht, bis die Tonne fuer mich richtig war) entspricht nicht der Art, wie wir bei OpenStreetMap arbeiten. Ich bin ziemlich unvoreingenommen an diese Sache herangegangen, aber wenn es wirklich so ist, dass Du ohne Ruecksicht und Kenntnis der Sachlage mit einem Spezialeditor hier an irgendwelchen Tonnen herumklickst, bis sie in diesem Spezialeditor richtig sind, und dabei korrekte Information (ich weiss immer noch nicht, ob diese Tonne ein rot-weisses Topzeichen hat oder nicht...) entfernst, dann ist es nicht nur zulaessig, sondern notwendig, alle Deine Aenderungen rueckgaengig zu machen - wer weiss, was Dein Spezialeditor sonst noch alles kaputt macht, ohne dass Du es merkst. Stell Dir vor, es kommt noch jemand drittes dazu, macht eine OpenOceanMap auf, programmiert einen Spezialeditor, der aber leider die Tonnen, die Du malst, nicht anzeigt, und man muss in dem Spezialeditor erst auf diese Tonne korrigieren klicken, damit sie auf OpenOceanMap erscheint, und dabei werden dann alle OSeaM-Tags geloescht. Du sprichst einen der Benutzer darauf an, und der weist empoert alle Schuld von sich: Ich mache hier Karten fuer Seefahrer, und mir kommt es in erster Linie darauf an, dass diese Tonne in der Karte richtig enthalten ist, und das geht nur, wenn ich in meinem Editor auf den diese-Tonne-korrigieren-Button klicke. Glaubst Du, so kommen wir weiter? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Am 14. Februar 2010 12:48 schrieb Markus liste12a4...@gmx.de: Unsere Editoren bearbeiten konsequent und ausschliesslich Daten, die in diesen Namensräumen liegen. Die Editoren ändert in diesem Namensraum ausschliesslich Daten, die der Benutzer ändert. Auch wenn da nun grad zwei einander gegenseitig etwas gelöscht haben, so ist das alles kein Problem, sondern kann recht einfach gelöst werden. Voraussetzung ist, dass man in guter Absicht handelt, sich gegenseitig nichts anderes unterstellt, bereit ist zu lernen, und sich gemeinsam um Lösungen bemüht. Aufgaben löse ich am liebsten nach vorne gewandt, also nach Lösungen suchend (statt nach Schuldigen). So wie Du es ja auch machst. Wenn mit der Lösung auch noch gleich strukturelle oder methodische Fortschritte erzielt werden: umso besser! Die Erweiterung ist bereits in Arbeit :-) Das Problem im vorliegenden Fall liegt doch im Fokus von OpenSeaMap. Hier geht es primär um die Abbildung von Schifffahrtszeichen auf *See*wasserstraßen. Anlass zum Handeln von Rolf war, dass sich manche Schifffahrtszeichen auf *Binnen*wasserstraßen schlicht nicht mit dem OSeaM-Editor eintragen lassen. Das händische Eintragen von Daten im OSeaM-Syntax ist nur etwas für Fortgeschrittene und macht auch dann nicht wirklich Spaß. OSeaM muss sich also an die Ergänzung der Binnenschifffahrtszeichen (soweit nicht mit den Schifffahrtszeichen auf See identisch) im Editor machen. Dann wären auch die Verleitungen vom Tisch, denen Rolf hier offensichtlich erlegen war. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche (was: kein Betreff)
Hallo Arne -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Arne Johannessen Gesendet: Sonntag, 14. Februar 2010 06:01 An: Openstreetmap allgemeines in Deutsch Betreff: [Talk-de] Toppzeichen gesperrte Wasserflaeche (was: kein Betreff) Rolf Meyerhof wrote: Öffne ich das Tonnen Menue sehe ich eine gelbe Tonne mit einem gelben Kreuz und das ist falsch. Ein anderes Topzeichen kann nicht ausgewählt werden. Darum bleibt die Tonne ohne Topzeichen. Ist das dann nicht auch falsch? ;-) Deine Frage Hier wird durch die Binnenschifffahrtsordnung doch selbst beantwortet. Siehe den Auszug aus Elwis. (steht über dem Bild in Punkt 1). Steht in Absatz (1. Tonnen für gesperrte Wasserflächen Gelbe Tonnen mit oder ohne Radarreflektoren, mit oder ohne Toppzeichen kennzeichnen eine gesperrte Wasserfläche. Als Toppzeichen können insbesondere die Zeichen nach Anlage 7 in Form von Tafeln oder Zylindern verwendet werden.) Also warum die Aufregung? Das Bild wird zwar verändert aber nicht die Funktion. Bei den Anwendern geht es um die Aussage: Darf ich oder darf ich nicht in diesem Bereich fahren. Wenn man jetzt aus prinzipiellen Erwägungen (nur richtig mit TopZeichen) auf eine Darstellung dieser Tonnen verzichtet ist das für den Benutzer (oder machen wir die Karten nur für den Selbstzweck)nachteilig und nicht erklärbar. Also muss man Abwägen, keine Darstellung weil Topzeichen, oder lieber Darstellung dann aber ohne Topzeichen. Was dann der Editor ändert oder nicht ändert ist so Du selbst schreibt ein Problem der Software. Frederik bezog sich auf Darstellungs-Software, welche die Datenbank nur ausliest. Der Editor ist aber eine Software, welche die Datenbank verändert und dabei -- wenn ich es richtig verstanden habe -- aufgrund eines Bugs zwangsweise die in der Datenbank existierenden Daten mit falschen Werten überschreibt. Vielleicht wäre es eine gute Idee, bis zur Korrektur des Fehlers im Editor diesen nicht mehr für gelbe Tonnen [1] einzusetzen. Ich das nicht für einen Fehler des Editors. Wenn du bitte einmal das Tagging der gelben Tonnen an der Berliner Pfaueninsel betrachtest wirst du sehen dass es da in Koexistenz der Anwender gelöst ist. Warum also dieses Verfahren nicht für andere Positionen Einsetzen. Markus hat gerade über die Namensräume beim Tagging berichtet. Wenn man die Knoten Chronik für fraglich Tonne betrachtet wird man feststellen dass einer seinen Namensraum erst gepflegt hat als ich die Tonne bearbeitet habe. Leider hat er dann dabei auch meine Änderung rückgängig gemacht. Bei einer rechtzeitigen Pflege der Daten hätten wir dieses Problem überhaupt nicht. Ist der Editor Open Source, liegt der im OSM-Subversion? Wenn mir jemand den Code zeigen mag, werfe ich gern mal einen Blick darauf. Grüße, Arne [1] Es geht um den letzten ganz unten auf folgender Seite abgebildeten Tonnentyp (Bild 34): http://www.elwis.de/Schifffahrtsrecht/BinSchStrO/Anlagen/Anlage-8/ -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
Hallo Frederik, hallo Arne, Arne Johannessen wrote: [1] Es geht um den letzten ganz unten auf folgender Seite abgebildeten Tonnentyp (Bild 34): http://www.elwis.de/Schifffahrtsrecht/BinSchStrO/Anlagen/Anlage-8/ Aha. Also *hat* diese Tonne ein rot-weisses Topzeichen, und der Editor einen Fehler. Ohne es wirklich zu wissen, denke ich einmal die Tonne hat ein Topzeichen. Der Editor hat an dieser Stelle keinen grundsätzlichen Fehler. Er schreibt _alle_ Daten _unverändert_ in die Datenbank zurück. Habe ich inzwischen mehrfach getestet. Was ist jetzt hier passiert? Der Leo hat ein Seezeichen zum bearbeiten geöffnet. Der Editor hat die Daten des Seezeichens geladen und das Topzeichen als unbekannt dargestellt, da er rot weiß rote Topzeichen nicht kennt. Hätte der Leo dieses so gelassen wie es ist, wäre nichts passiert. Die Schlüssel wären genauso wieder in die Datenbank geschrieben worden. Nun hat der Leo aber, da er das rot weiß rote Topzeichen nicht auswählen konnte, gesagt dann hat die Tonne halt kein Topzeichen, und _bewusst_ das Topzeichen abgewählt. Daraufhin hat der Editor die Schlüssel des Topzeichens entfernt, da ihm ja gesagt wurde die Tonne hat gar kein Topzeichen. Was habe ich für mich daraus gelernt? Ich werde ab sofort den Editor bei bekannten Schlüssel, aber unbekannten Wert, gar nichts mehr anzeigen lassen, um Leute daran zu hindern unbekannte Einträge zu löschen. Bei unerlässlichen Informationen, werde ich diese durch ein ganz großes Fragezeichen visualisieren, das bei einem Klick ein Fenster öffnet in dem die Schlüssel-Werte Paare in einer Tabelle ähnlich der des JOSM anzeigt werden. Der Fix mit den rot weiß roten Topzeichen ist bereits in Arbeit und wird im Laufe des Tages verfügbar sein. Die weiteren oben angesprochenen Änderungen sollten Anfang bis Mitte der Woche verfügbar sein. Olaf/Markus - es waere super, wenn es gelaenge, OpenSeaMap-Benutzer dahingehend zu sensibilisieren, dass es ausser OpenSeaMap noch andere Anwendungen der Daten gibt und dass die Daten niemandem allein gehoeren - und dass taggen fuer den Renderer auch bei OSeaM keine gute Idee ist... Ich weise die Leute immer daraufhin, dass OpenStreetMap mehr als nur eine Landkarte ist und die eigentlichen Visualisierungen durch den Renderer entstehen. Bei Fehlerhafter Darstellung mögen sie bitte mir schreiben und nicht versuchen die Tonne auf Gewalt gerendert zu bekommen. Beste Grüße Olaf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Falk Zscheile Gesendet: Sonntag, 14. Februar 2010 14:31 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] (kein Betreff) Am 14. Februar 2010 12:48 schrieb Markus liste12a4...@gmx.de: Unsere Editoren bearbeiten konsequent und ausschliesslich Daten, die in diesen Namensräumen liegen. Die Editoren ändert in diesem Namensraum ausschliesslich Daten, die der Benutzer ändert. Auch wenn da nun grad zwei einander gegenseitig etwas gelöscht haben, so ist das alles kein Problem, sondern kann recht einfach gelöst werden. Voraussetzung ist, dass man in guter Absicht handelt, sich gegenseitig nichts anderes unterstellt, bereit ist zu lernen, und sich gemeinsam um Lösungen bemüht. Aufgaben löse ich am liebsten nach vorne gewandt, also nach Lösungen suchend (statt nach Schuldigen). So wie Du es ja auch machst. Wenn mit der Lösung auch noch gleich strukturelle oder methodische Fortschritte erzielt werden: umso besser! Die Erweiterung ist bereits in Arbeit :-) Das Problem im vorliegenden Fall liegt doch im Fokus von OpenSeaMap. Hier geht es primär um die Abbildung von Schifffahrtszeichen auf *See*wasserstraßen. Anlass zum Handeln von Rolf war, dass sich manche Schifffahrtszeichen auf *Binnen*wasserstraßen schlicht nicht mit dem OSeaM-Editor eintragen lassen. Das händische Eintragen von Daten im OSeaM-Syntax ist nur etwas für Fortgeschrittene und macht auch dann nicht wirklich Spaß. Hall Falk Hier irrst du etwas das Problem liegt in nicht gepflegten Daten, denn bei anderen Tonnen geht es ja Sehe bitte in die Konten Chronil dieser Tonne! Rolf OSeaM muss sich also an die Ergänzung der Binnenschifffahrtszeichen (soweit nicht mit den Schifffahrtszeichen auf See identisch) im Editor machen. Dann wären auch die Verleitungen vom Tisch, denen Rolf hier offensichtlich erlegen war. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
moin On 14.02.2010, at 13:14, Mirko Küster wrote: die Regelung, dass dass die beiden See-Tagging-Schemata bitte friedlich nebeneinander her existieren sollen funktioniert seit einigen Monaten beidseitig richtig gut. Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? Warum nicht wenigstens ein Schema was global läuft, wenn sich das schon direkt auf der OSM DB abspielen muss? Mir fällt keine sinnvolle Begründung ein. [...] dem kann ich nur zustimmen. Auch wenn ich das mit dem Datenbank aufblähen nur bedingt als problem empfinde, sehe ich es doch eher als hürde für neulinge an. es ist schon nerfig genug den leuten erklären zu müssen das sie nen z.B. Zigaretten Automaten nicht in deutsch sondern in englisch mappen sollen, irgendwelchen freizeit skippern dann noch zu verklickern das es da zwei konkurierende systeme gibt und sie sich wahlweise für eins entscheiden müssen oder sich doppelte arbeit machen müssen... ne sowas nervt. Sind diese Tonnen nicht international oder zumindestens national normiert? dann sollte es doch ohne weiteres möglich sein auf diesen normen aufzubauen und ne einheitliche struktur zu schaffen. wenn das in kooperation der beiden projekte nicht funzt dann solltet ihr euch ne schlichtergruppe anheuern die von beiden projekten keine ahnung hat und das dann für euch macht. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] (kein Betreff)
Hallo es hat sich dort keiner beschwert über den Fakt das da eine Tonne zurückgesetzt wurde. Die ursprüngliche mail war eigentlich nicht für die Talk Runde hier bestimmt. Sie ist aber leider durch einen Tippfehler veröffentlicht worden und wurde als Beschwerde verstanden. Eigentlich können jetzt wieder alle in den Hafen zurück rudern. Denn das Problem wird bestimmt schnell gelöst wenn wir Zeit dafür nutzen. Leo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Duplicate Nodes
Hi, ich glaube dieses nuetzliche Quality Assurance tool wurde hier auf talk-de noch nicht präsentiert, also tue ich es einfach mal... In der OpenStreetMap datenbank sind derzeit knap 10 Millionen sogenannte Duplicate Nodes, also Nodes, die exact die selben Koordinated haben wie ein anderer Node. Der Ursprung dieser duplicate nodes hat viele verschiedene Gruende wie z.B. nicht ideal geplante imports, fehlgeschlagene imports, (frühere) Bugs in den editor tools, oder aber auch bewusste Entscheidungen nodes zu duplizieren. Ein Grossteil dieser duplicate nodes sind jedoch ungewollt und sind entweder unschön oder führen auch zu echten Problemen wie z.B. im routing wenn verbundene Ways nicht die gleichen Nodes verwenden sondern die Nodes dupliziert wurden. Matt Amos hat nun ein tool geschrieben ( http://matt.dev.openstreetmap.org/dupe_nodes/ ) um die duplicate nodes auf einer Slippy Map anzuzeigen damit Leute hoffentlich diese nun korrigieren. Ausserdem findet man einen schoenen zeitlichen Verlauf des Vortschrittes unter http://matt.dev.openstreetmap.org/dupe_nodes/about.html http://matt.dev.openstreetmap.org/dupe_nodes/about.html Wenig überraschend sind die meisten Probleme in Regionen mit vielen Imports zu finden, aber auch in Deutschland sind noch einige zu finden. Es gibt also genug fuer eifrige mapper zu tun... http://matt.dev.openstreetmap.org/dupe_nodes/about.html Das ganze passt gut zu all den anderen Quality Assurance tools die wir inzwischen haben ( http://wiki.openstreetmap.org/wiki/Qualitätssicherung http://wiki.openstreetmap.org/wiki/Qualit%C3%A4tssicherung ) damit OSM weiterhin ein _geordnetes_ Chaos bleibt... :-) Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
moin On 14.02.2010, at 13:25, Torsten Breda wrote: Die beiden Projekte sollten sich mal überlegen, dass sie in OSM eine Minderheit darstellen. Nicht das jemand auf die Idee kommt zu beschließen, dass diese Dinge gar nichts mehr in der OSM Datenbank verloren haben. Bisher konnte man sich in anderen Bereichen meist gut einigen oder ein Problem mit nur geringer Redundanz aus der Welt schaffen. Um die Seekarten gibt es jedoch immer wieder Ärger. Naja soweit würde ich auch nicht gehen... reiter, kinderwagenschupser, fahrad-mit-hänger fahrer und was weiß ich alles solche leute stellen sicherlich eine noch geringere minderheit an personen in OSM dar. Niemand würde auf die idee kommen eine ihnen zu untersagen eine z.B. fahrad-schiebe-rinne (oder wie man die nennt) an einer treppe nicht mappen zu dürfen. Im gegenteil, ermutig sie doch dazu... wenn man selber mal über so ein teil stolpert könnte man es dann ja auch mit mappen. und genau da seh ich das problem mit den seezeichen. wenn man mal abens zufällig über ein defektes seezeichen stolpert, oder merkt das eine lampe da nicht eingetragen ist... heck wie soll ich das als nicht seefahrer mit mappen? selbst nen fix_me tag läuft da ja vermutlich ins leere. ich denke das die OSM philosopie so sein sollte das es nur einen art geben sollte wie dinge getaggt werden. ist ja nicht so als wenn es mit anderen (deutlich einfacheren) angaben nicht schon genügend probleme gibt. z.B. ob es nun Address:phone oder nur Phone oder wie auch immer sein soll und ob man +49-xxx- oder 0xxx- oder (0xxx) oder nur angeben soll. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Menschliche. Die Mitstreiter können schlicht nicht miteinander. Nicht das Problem der OSM Datenbank und deren Community. Man hat ehrlich gesagt Glück das man hier geduldig und locker ist. In anderen Projekten hätte man beide schon ausgeschlossen. Sind wir jetzt schon soweit, Minderheiten rauszuwerfen? Ich hoffe nicht, denn dann bleibt von OSM nicht viel übrig. Minderheiten sind natürlich willkommen, wenn sie denn mit und nicht gegen arbeiten. Das liegt halt daran, daß es zwei Parteien gibt, die sich nicht einigen wollen. Dann haben sie Pech, die müssen nicht nur untereinander sondern auch mit OSM ansich klar kommen. Die Daten auf OSM sind für alle da. Nicht nur für Schnick oder Schnack. Wenn es nicht geht dann müssen die jeweils ne eigene DB aufziehen. Aber fangen wir jetzt an die Radwege rauszuwerfen, weil sich die Radfahrer nicht auf ein Schema einigen können? Ich hoffe nicht. Zwei paar Schuhe. Das ist eine OSM interne Taggingauseinandersetzung die sich irgendwann über die mehrheitliche Verwendung klären wird. Die beiden Seekarten sind jeweils ein externes Grüppchen, die ihre Nickelichkeiten der OSM Community aufzwingen. Die Tags sind ja nichtmal richtig für eine Verwendung direkt in OSM dokumentiert. Nein, man nutzt OSM als bequeme Kippe fürs eigene Steckenpferd. Der Arsch ist der OSM User der auf OSM arbeitet und dann zwischen den Kindergarten gerät. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Hallo Rolf/Leo, es hat sich dort keiner beschwert über den Fakt das da eine Tonne zurückgesetzt wurde. Die ursprüngliche mail war eigentlich nicht für die Talk Runde hier bestimmt. Sie ist aber leider durch einen Tippfehler veröffentlicht worden und wurde als Beschwerde verstanden. egal wie oder warum eine E-Mail hier landet so verwende doch bitte wenigstens einen Betreff. Das ist nicht nur sehr einfach zu machen sondern erleichtert auch allen anderen das Folgen der Konversationen. Außerdem moechte ich Dich darauf hinweisen, dass Deine Antworten auf Mails hier in der Liste zumindest für mich (und damit zumindest auch die meisten anderen GMail-Nutzer) häufig unleserlich sind, da Du einen sehr wilden Zitierstil hast. Ich wäre Dir sehr dankbar wenn Du neben der Arbeit an OpenSeaMap ein wenig Zeit in die richtige Konfiguration Deines Mailprogrammes und die korrekte Verwendung dessen investieren könntest. Nach kurzem suchen fand ich einen Link[1] der das ein bisschen erklärt aber ich bin mir sicher andere hier haben konkretere Tipps. Ein erster Schritt wäre es in Outlook keine HTML-Mails sondern reine Text-Mails zu schreiben. Dies hilft nicht nur uns sondern auch Dir hier ernst genommen zu werden und vernünftige Hilfe und Antworten zu erhalten. Gruß, Lars [1] http://einklich.net/usenet/zitier.htm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Duplicate Nodes
Am 14.02.2010 15:11, schrieb Kai Krueger: Hi, ich glaube dieses nuetzliche Quality Assurance tool wurde hier auf talk-de noch nicht präsentiert, also tue ich es einfach mal... In der OpenStreetMap datenbank sind derzeit knap 10 Millionen sogenannte Duplicate Nodes, also Nodes, die exact die selben Koordinated haben wie ein anderer Node. Der Ursprung dieser duplicate nodes hat viele verschiedene Gruende wie z.B. nicht ideal geplante imports, fehlgeschlagene imports, (frühere) Bugs in den editor tools, oder aber auch bewusste Entscheidungen nodes zu duplizieren. Ein Grossteil dieser duplicate nodes sind jedoch ungewollt und sind entweder unschön oder führen auch zu echten Problemen wie z.B. im routing wenn verbundene Ways nicht die gleichen Nodes verwenden sondern die Nodes dupliziert wurden. Matt Amos hat nun ein tool geschrieben ( http://matt.dev.openstreetmap.org/dupe_nodes/ ) um die duplicate nodes auf einer Slippy Map anzuzeigen damit Leute hoffentlich diese nun korrigieren. Ausserdem findet man einen schoenen zeitlichen Verlauf des Vortschrittes unter http://matt.dev.openstreetmap.org/dupe_nodes/about.html http://matt.dev.openstreetmap.org/dupe_nodes/about.html Wenig überraschend sind die meisten Probleme in Regionen mit vielen Imports zu finden, aber auch in Deutschland sind noch einige zu finden. Es gibt also genug fuer eifrige mapper zu tun... http://matt.dev.openstreetmap.org/dupe_nodes/about.html Das ganze passt gut zu all den anderen Quality Assurance tools die wir inzwischen haben ( http://wiki.openstreetmap.org/wiki/Qualitätssicherung http://wiki.openstreetmap.org/wiki/Qualit%C3%A4tssicherung ) damit OSM weiterhin ein _geordnetes_ Chaos bleibt... :-) Kai Hallo, hmm das Tool ist gut. Habe schon auf die Schnelle die ersten doppelten Nodes vor meiner Haustür aufgeräumt. Danke, ohne dich hätte ich wohl nie etwas von dem Tool gefunden. Grüße Max ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mails blocken ohne betreff? war: (kein Betreff)
moin On 14.02.2010, at 15:17, Lars Francke wrote: Hallo Rolf/Leo, es hat sich dort keiner beschwert über den Fakt das da eine Tonne zurückgesetzt wurde. Die ursprüngliche mail war eigentlich nicht für die Talk Runde hier bestimmt. Sie ist aber leider durch einen Tippfehler veröffentlicht worden und wurde als Beschwerde verstanden. egal wie oder warum eine E-Mail hier landet so verwende doch bitte wenigstens einen Betreff. Das ist nicht nur sehr einfach zu machen sondern erleichtert auch allen anderen das Folgen der Konversationen. das bringt mich auf die idee... könnte man nicht einfach die mailingliste so einstellen das sie keine mails mehr annimmt die über keinen betreff (oder diesen unsäglichen default betreff) verfügen? mails von leuten die nicht auf der mailingliste stehen werden ja auch nicht durchgelassen. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mails blocken ohne betreff? war: (kein Betreff)
AssetBurned schrieb: On 14.02.2010, at 15:17, Lars Francke wrote: egal wie oder warum eine E-Mail hier landet so verwende doch bitte wenigstens einen Betreff. Das ist nicht nur sehr einfach zu machen sondern erleichtert auch allen anderen das Folgen der Konversationen. das bringt mich auf die idee... könnte man nicht einfach die mailingliste so einstellen das sie keine mails mehr annimmt die über keinen betreff (oder diesen unsäglichen default betreff) verfügen? mails von leuten die nicht auf der mailingliste stehen werden ja auch nicht durchgelassen. [ ] du kennst gmane Ansonsten könnten wir noch auf html-Mails, ToFu, Kammquoting, überlange Zeilen, korrekte Groß/Kleinschreibung, Rechtschreibung und Satzbau filtern, allzu technische Sachen ebenfalls außen vor lassen (verwirrt nur), GoogleMail aussperren (weil, Google ist doof), alle Mails von MS-Systemen nicht durchlassen (weil, dort sitzen Klicki-Bunti-Nutzer - obwohl das gilt eigentlich auch für Mac und X-Linuxer) - hab ich was vergessen? Hm - Liest mich noch wer? =) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import von 25'000 Haltestellen
Hallo Frank, findet in der schweiz nicht auch die haltestellennummerierung nach dem UIC (http://www.uic.org) bzw. IBNR statt? nach dem ÖPNV Schema http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema#Gesamthalt wäre der langname damit: uic_name=Zürich, Bahnhofstrasse und die DSNR uic_ref=[DSNR] Ich denke, soetwas in der Art wird es werden. uic_name wird bisher etwas über 700x verwendet. zur überprüfung bietet sich diese seite an http://www.michaeldittrich.de/ibnr/online.php Was mir bei meiner Recherche allerdings aufgefallen ist: Viele Bus-/Tram-Haltestellen in Deutschland haben einen uic_ref eingetragen. Dieser besteht aber nur aus 6 Ziffern und entspricht damit nicht dem IBNR-Schema! So heisst es z.B. auf http://home.arcor.de/estw/efaq/efaq-03-01.html | Außerdem haben die zusätzlich in Hafas integrierten Zugangsstellen | (Haltestellen von Bussen und Straßenbahnen) auch Nummern bekommen. Diese | sind jedoch länger als die IBNR und nur Hafas-Intern, helfen jedoch auch | bei der Verbindungssuche (124747 ist z. B.Darmstadt, | Willy-Brandt-Platz). Meiner Meinung nach ist es daher falsch, in diesen Fällen auch den Key uic_ref zu verwenden.. (In der Schweiz hingegen sind _alle_ Stationsnummern UIC-konform.) Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mails blocken ohne betreff? war: (kein Betreff)
... genau, am Besten alles blocken, macht das Postfach gleich viel übersichtlicher... ;-) malenki o...@malenki.ch wrote in message news:20100214154841.5766c...@c2d-sid... AssetBurned schrieb: On 14.02.2010, at 15:17, Lars Francke wrote: egal wie oder warum eine E-Mail hier landet so verwende doch bitte wenigstens einen Betreff. Das ist nicht nur sehr einfach zu machen sondern erleichtert auch allen anderen das Folgen der Konversationen. das bringt mich auf die idee... könnte man nicht einfach die mailingliste so einstellen das sie keine mails mehr annimmt die über keinen betreff (oder diesen unsäglichen default betreff) verfügen? mails von leuten die nicht auf der mailingliste stehen werden ja auch nicht durchgelassen. [ ] du kennst gmane Ansonsten könnten wir noch auf html-Mails, ToFu, Kammquoting, überlange Zeilen, korrekte Groß/Kleinschreibung, Rechtschreibung und Satzbau filtern, allzu technische Sachen ebenfalls außen vor lassen (verwirrt nur), GoogleMail aussperren (weil, Google ist doof), alle Mails von MS-Systemen nicht durchlassen (weil, dort sitzen Klicki-Bunti-Nutzer - obwohl das gilt eigentlich auch für Mac und X-Linuxer) - hab ich was vergessen? Hm - Liest mich noch wer? =) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Content Policy Scan by M+ Guardian Millions of safe clean messages delivered daily ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
On 14.02.10 14:31, Olaf Hannemann wrote: Der Editor hat an dieser Stelle keinen grundsätzlichen Fehler. Er schreibt _alle_ Daten _unverändert_ in die Datenbank zurück Ned bös sein (und ich kenne weder den Editor noch den konkreten Anlaß), aber das ist ein grundsätzlicher Design-Fehler, wenn ein Editor unveränderte Daten neu schreibt. Ein Editor muß den vollen Überblick drüber haben, was sich verändert hat und was nicht, und darf nur veränderte Dinge schreiben. Einerseits ganz grundsätzlich und anderseits speziell hier in OSM (in Bezug auf Changeset-Sauberkeit und History). Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mails blocken ohne betreff? war: (kein Betreff)
Zitat AssetBurned: [...] das bringt mich auf die idee... könnte man nicht einfach die mailingliste so einstellen das sie keine mails mehr annimmt die über keinen betreff (oder diesen unsäglichen default betreff) verfügen? Warum laesst du das nicht deinen Mail.- oder Newsclient machen? -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Import von 25'000 Haltestellen
Thomas Ineichen schrieb: So heisst es z.B. auf http://home.arcor.de/estw/efaq/efaq-03-01.html | Außerdem haben die zusätzlich in Hafas integrierten Zugangsstellen | (Haltestellen von Bussen und Straßenbahnen) auch Nummern bekommen. Diese | sind jedoch länger als die IBNR und nur Hafas-Intern, helfen jedoch auch | bei der Verbindungssuche (124747 ist z. B.Darmstadt, | Willy-Brandt-Platz). Die führende 0 fehlt. Meiner Meinung nach ist es daher falsch, in diesen Fällen auch den Key uic_ref zu verwenden.. (In der Schweiz hingegen sind _alle_ Stationsnummern UIC-konform.) Ich versuche mal etwas Licht ins Dunkel bringen. Die UIC-Nummer/IBNR setzt sich aus einem Ländercode (die ersten beiden Ziffern) und der lokalen Nummer zusammen (fünf weitere Ziffern). Aachen Hbf hat beispielsweise die 1. Der Ländercode für Deutschland ist die 80(0). Daher hat Aachen Hbf die IBNR 801. (weitere Beispiele: 10: Finnland, 24 Litauen, 51 Polen, 54 Tschechien, 81 Österreich, 82 Luxemburg, 83 Italien, 84 Niederlande, 85 Schweiz, 86 Dänemerk, 87 Frankreich, 88 Belgien, 94 Portugal). Die Anfangsziffern 01 bis 09 sind nicht im UIC-Code benannt. Diese werden innerhalb des HAFAS-Auskunftssystems für ÖPNV-Haltestellen verwendet. Während die Nummern für die Bahnhöfe genormt sind könnte eine Nummer im Busbereich in Österreich eine ganz andere Bedeutung als in der Deutschland haben. Oder im Hafas der DB AG, des RMV und des VBB. Wobei ich mir nicht so ganz im klaren bin, warum die SBB und die SNCB für Aachen Hbf die Nummer 8015345 verwenden. Bei der ÖBB funktioniert es mit der 801. Zürich Hb hat hingegen sowohl bei der DB, als auch bei der SBB die IBNR 8503000. http://reiseauskunft.bahn.de/bin/bhftafel.exe/dn?ld=212.25seqnr=3ident=5u.01067625.1266164043rt=1input=Aachen%20Hbf%23801time=18:20date=14.02.10ld=212.25productsFilter=10start=1boardType=dep; http://fahrplan.oebb.at/bin/stboard.exe/dn?seqnr=1ident=68.0175421.1266164098input=Aachen%20Hbf%23801boardType=deptime=18:23date=14.02.10 http://hari.b-holding.be/HARI/inter_gare.aspx?Lang=0stationid=8015345; http://fahrplan.sbb.ch/bin/bhftafel.exe/dn?seqnr=1ident=6y.021713247.1266164200input=8015345boardType=deptime=18:23 Es gibt auch einige Bushaltestellen in D, die aus tariflichen Gründen eine eigene IBNR haben. Diese liegt im Bereich des Ländercodes. Für Bushaltestellen würde ich eher versuchen die Nummer des lokalen Verbundes oder Unternehmen zu integrieren. Sobald diese eindeutig benannt sind spricht ja nichts dagegen, mehrere Nummern aufzunehmen. In NRW sind wir gerade dabei ein landesweites Haltestellenkataster aufzubauen. Dabei werden Naptan/Transmodel-kompatible Nummern des Schemas DE:4711:1234 verwendet, wobei DE das Länderkürzel, 4711 die Gemeidnekennziffer des Landkreises und 1234 (meist) die lokale Haltestellennummer des regional zuständigen Verbundes ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
Andreas Labres wrote: Der Editor hat an dieser Stelle keinen grundsätzlichen Fehler. Er schreibt _alle_ Daten _unverändert_ in die Datenbank zurück Ned bös sein (und ich kenne weder den Editor noch den konkreten Anlaß), aber das ist ein grundsätzlicher Design-Fehler, wenn ein Editor unveränderte Daten neu schreibt. Ein Editor muß den vollen Überblick drüber haben, was sich verändert hat und was nicht, und darf nur veränderte Dinge schreiben. Einerseits ganz grundsätzlich und anderseits speziell hier in OSM (in Bezug auf Changeset-Sauberkeit und History). Die Daten sprich der Node sind doch verändert worden. Dabei muss man den kompletten Node neu zurückschreiben inklusive aller Tags auch wenn sich einzelne Tags nicht verändert haben. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Osmosis: java.lang.NoClassDefFoundError: org/java/plugin/PluginLifecycleException
Am 8. Februar 2010 21:38 schrieb Carsten Gerlach daswaldh...@gmx.de: Hi, Am Montag 08. Februar 2010 21:14:31 schrieb Chris-Hein Lunkhusen: Hi, mach den Aufruf mal mit dem mitgelieferten Shell-Script, dort wird der CP richtig gesetzt. Das wollte ich eigentlich auch noch erwähnen... Bei der Nutzung dieses Skriptes kommt folgende Meldung ... Wenn ich die config/plexus.conf einfach mal anlege kommt dann: Das original ist übrigens hier zu finden: http://svn.openstreetmap.org/applications/utils/osmosis/trunk/config/ Jedoch ist die Fehlermeldung danach auch nciht besser: === org.codehaus.plexus.classworlds.launcher.ConfigurationException: Unhandled configuration (1): ?main is org.openstreetmap .osmosis.core.Osmosis from osmosis.core at org.codehaus.plexus.classworlds.launcher.ConfigurationParser.parse(ConfigurationParser.java:303) at org.codehaus.plexus.classworlds.launcher.Configurator.configure(Configurator.java:135) at org.codehaus.plexus.classworlds.launcher.Launcher.configure(Launcher.java:132) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:405) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) at org.codehaus.classworlds.Launcher.main(Launcher.java:31) === OpenJDK Runtime Environment (IcedTea6 1.4.1) (6b14-1.4.1-0ubuntu12) OpenJDK Client VM (build 14.0-b08, mixed mode, sharing) Besser ist das originale SUN JDK. Ist das wirklich notwendig oder kann das auch mit dem OpenJDK funktionieren? Die Frage ist, ob die Fehler von Osmosis kommen oder von Java. Mit Windows 7 und Sun Java 1.6 kommte es zu den gleichen Problemen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Landuse: Verwaltungsflächen und all gemeine Flächen
Hi ! wie würdet Ihr folgende Flächen taggen: * öffentliche Verwaltung (Arbeitsamt, Polizei, Finanzamt - teilweise in Combinutzung) * allgemeine Flächen im öffentlichen Raum - es ist nicht bekannt, ob da nicht ein anderer vielleicht Eigentümer ist. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse: Verwaltungsflächen und all gemeine Flächen
Jan Tappenbeck wrote: wie würdet Ihr folgende Flächen taggen: [...] * allgemeine Flächen im öffentlichen Raum - es ist nicht bekannt, ob da nicht ein anderer vielleicht Eigentümer ist. Was stellst du dir darunter vor? Von der Beschreibung würd ich jetzt mal tendiern in Richtung gar nicht taggen. Ich denk aber mal, ich versteh dich einfach nur falsch. Was genau meinst du also mit allgemeine Flächen? Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse: Verwaltungsflächen und all gemeine Flächen
Jan Tappenbeck schrieb am 14.02.2010 18:09: wie würdet Ihr folgende Flächen taggen: * öffentliche Verwaltung (Arbeitsamt, Polizei, Finanzamt - teilweise in Combinutzung) amenity=public_building und die Gebaeude selber dann mit building=yes Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Duplicate Nodes
Naabend, Am Sonntag 14. Februar 2010 15:11:36 schrieb Kai Krueger: ich glaube dieses nuetzliche Quality Assurance tool wurde hier auf talk-de noch nicht präsentiert, also tue ich es einfach mal... Schöne Schache, zumal keepright die doppelten Knoten nicht anzeigt, zumindest tut die Option multiple nodes nicht bei mir. Gruß, Carsten -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.piranho.de/gpg.php = www.stopptdievorratsdatenspeicherung.de signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KOSMOS-Beispiel Wanderkarte
Mirko Küster wrote: Ich würde sagen, wir reden noch aneinander vorbei, meinen aber das Gleiche. Der ganze, mühevolle Prozeß, den Du da beschreibst, wird von Composer bereits automatisch erledigt. Bis auf die Aktivierung von Multipolygonen, falls Kosmos die überhaupt kann. Das einzige Problem ist es jetzt noch, einen Satz Renderregeln zu haben, der die Wandermarkierungen richtig anzeigt. Die Frage ist, was muss man tun und wo findet man nun diese neuen Wege ohne ID, welche die Tags ihrer Relation geerbt haben? Das ganze reicht als normales OSM File, um es dann beispielswe per Osmosis mit Daten und SRTM verbinden zu können. Der Rest läuft über Osmarender automatisch. Die Wege und Punkte liegen zwischen den normalen OSM-Daten im File und haben künstliche IDs im Bereich 11. Sie haben nicht die Tags ihrer Relation, sondern neue Tags, die Farben oder Wandermarkierung direkt beschreiben. Die Tags, die Du zum Rendern auswerten mußt, findest Du in Composer in der Tabelle der Renderregeln. bye Nop -- View this message in context: http://n2.nabble.com/KOSMOS-Beispiel-Wanderkarte-tp4554015p4570959.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
Hallo, Andreas Labres wrote: Der Editor hat an dieser Stelle keinen grundsätzlichen Fehler. Er schreibt _alle_ Daten _unverändert_ in die Datenbank zurück Ned bös sein (und ich kenne weder den Editor noch den konkreten Anlaß), aber das ist ein grundsätzlicher Design-Fehler, wenn ein Editor unveränderte Daten neu schreibt. Ein Editor muß den vollen Überblick drüber haben, was sich verändert hat und was nicht, und darf nur veränderte Dinge schreiben. Da liegt aber jetzt auf Deiner Seite ein Missverstaendnis vor. Natuerlich meinte Olaf: Der Editor schreibt alle Tags zurueck, auch die, die nicht veraendert wurden (aber natuerlich nur, wenn irgendwas an dem Objekt veraendert wurde). Und genauso machen das ja alle anderen Editoren auch - obwohl man fuer 0.7 darueber nachdenkt, eventuell inkrementelle Updates zu erlauben nach Art von fuege dem Way X das Tag Y hinzu. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten - Langlaufloipe
Wie trägt man eine Langlaufloipe möglichst sinnig ein? Meist verläuft sie in grossen Bögen quer über Feld und Wiese. Manchmal folgt sie (vor allem im Wald) einem Weg. Meist ist es eine Rundloipe. Manchmal zweigen kleinere/grössere Rundloipen ab. Sie beginnen meist an einer Strasse/Parkplatz. Dazwischen gibt es manchmal weitere Zugänge. Fragen: a) Extralinie? (damit der Renderer sie im Sommer wegmachen kann) b) Halb/halb als Relation? (dem Waldweg zusätzliche Attribute geben?) piste:type=nordic Wird das von irgend einem Renderer angezeigt? a) sieht im Editor verwirrend aus, aber die Attribute sind klar. b) da vermischen sich die Winterattribute mit den allgemeinen Ideen? Am besten gleich ins Wiki: http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] frage zu tmc-areas
hi, wie detailliert sind denn die tmc-area-daten? könnte man damit die administrativen Grenzen von Gemeinden nach osm laden? mfg wambacher p.s. wenn das nicht gehen sollte, gibt es andere legale quellen dafür? -- View this message in context: http://n2.nabble.com/frage-zu-tmc-areas-tp4571076p4571076.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Normierung von Seezeichen (was: kein Betreff)
AssetBurned wrote: On 14.02.2010, at 13:14, Mirko Küster wrote: Generelle Grundsatzfrage. Warum zwei Projekte, die eigentlich das gleiche machen aber doch wieder irgendwie ein eigenes Schema verwenden? [...] [...] Auch wenn ich das mit dem Datenbank aufblähen nur bedingt als problem empfinde, sehe ich es doch eher als hürde für neulinge an. Als Neuling kann ich das bestätigen. [...] Sind diese Tonnen nicht international oder zumindestens national normiert? Ja, sicher. Aber erstens gibt es zahllose verschiedene Normen für Schifffahrtszeichen. Allein in Deutschland z. B. eine internationale (IALA-A [1]), zwei verschiede nationale (SeeSchStrO [2], BinSchStrO [3]) und schließlich einige lokale (z. B. BSO [4]). Zweitens wird allerorts von den Normen abgewichen, wenn es dem Zweck dienlich ist, gerade kein genormtes Zeichen zur Hand ist oder einfach die ausführende Person sich für Normen nicht interessiert. Vergleiche Straßenverkehr: Es gibt zwar eine internationale Norm, aber jedes Land definiert dann national doch eigene Regeln, die den internationalen widersprechen oder sie auch teils völlig ignorieren (USA). Und manchmal (vereinzelt) finden sich dann Zeichen, die so in keiner Norm stehen. dann sollte es doch ohne weiteres möglich sein auf diesen normen aufzubauen und ne einheitliche struktur zu schaffen. Klar, das ist im Prinzip durchaus möglich und wird offenbar auch von OSeaM und FT angestrebt. Unter anderem wegen der zuvor beschriebenen Komplexität der tatsächlichen Verhältnisse ist das aber nicht ganz so einfach, wie es klingt. wenn das in kooperation der beiden projekte nicht funzt dann solltet ihr euch ne schlichtergruppe anheuern die von beiden projekten keine ahnung hat und das dann für euch macht. Heh :) [1] http://de.wikipedia.org/wiki/International_Association_of_Lighthouse_Authorities [2] http://de.wikipedia.org/wiki/Seeschifffahrtsstra%C3%9Fen-Ordnung [3] http://de.wikipedia.org/wiki/Binnenschifffahrtsstra%C3%9Fen- Ordnung [4] http://de.wikipedia.org/wiki/Bodensee-Schifffahrtsordnung -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
Olaf Hannemann wrote: Hallo Frederik, hallo Arne, Arne Johannessen wrote: [1] Es geht um den letzten ganz unten auf folgender Seite abgebildeten Tonnentyp (Bild 34): http://www.elwis.de/Schifffahrtsrecht/BinSchStrO/Anlagen/Anlage-8/ Aha. Also *hat* diese Tonne ein rot-weisses Topzeichen, und der Editor einen Fehler. Ohne es wirklich zu wissen, denke ich einmal die Tonne hat ein Topzeichen. Zur Klarstellung: ich war nie vor Ort und sage nur, um diesen Tonnentyp wird hier diskutiert. Ich vermute aber auch, dass ein Toppzeichen vorhanden ist. Der Editor hat an dieser Stelle keinen grundsätzlichen Fehler. Er schreibt _alle_ Daten _unverändert_ in die Datenbank zurück. Habe ich inzwischen mehrfach getestet. Was ist jetzt hier passiert? Der Leo hat ein Seezeichen zum bearbeiten geöffnet. Der Editor hat die Daten des Seezeichens geladen und das Topzeichen als unbekannt dargestellt, da er rot weiß rote Topzeichen nicht kennt. Ich schlage als Alternative mal den Begriff benutzerdefiniert / user defined vor. Einem Editor unbekannte Werte werden zumindest am Mac normalerweise so bezeichnet. Hier halte ich das für besser, weil dadurch klarer zum Ausdruck kommt, dass tatsächlich ein Wert gesetzt ist. Hätte der Leo dieses so gelassen wie es ist, wäre nichts passiert. Die Schlüssel wären genauso wieder in die Datenbank geschrieben worden. Nun hat der Leo aber, da er das rot weiß rote Topzeichen nicht auswählen konnte, gesagt dann hat die Tonne halt kein Topzeichen, und _bewusst_ das Topzeichen abgewählt. [...] Die hier diskutierte Tonne ohne Toppzeichen _darzustellen_ ist sicherlich okay. Dazu das Toppzeichen aus der Datenbank zu _löschen_, kann aber nicht die Lösung sein. Was habe ich für mich daraus gelernt? Ich werde ab sofort den Editor bei bekannten Schlüssel, aber unbekannten Wert, gar nichts mehr anzeigen lassen, um Leute daran zu hindern unbekannte Einträge zu löschen. [...] Klingt, als löse diese Änderung das Problem aus Sicht von OSM. Allerdings sieht die Toms-GUI nur eine Checkbox für Toppzeichen ja oder nein vor. Unterschiedliche Toppzeichen für denselben Tonnentyp können daher nicht mit Toms verarbeitet werden. Oder übersehe ich etwas? Es existieren ja nun durchaus Seezeichen, die nicht IALA, BinSchStrO oder sonstigen Normen entsprechen. Die haben dann teilweise auch recht unterschiedliche Toppzeichen. Beispiele: - DW-Route Kadetrinne mit gelben Lateraltonnen - dänische Regattatonnen mit Flagge - Reisig auf Pricken im Wattenmeer - improvisierte Betonnung Marke Benzinkanister mit Gewicht dran - privat bezeichnete Gewässer Wie werden derartige Seezeichen von Toms behandelt? Momentan kommt da im Zweifel ein Parse-Error: Seezeichen unbekannt, und eine Änderung der Daten mit Toms ist nicht möglich. Ist das schon der Sollzustand, oder planst Du grundsätzlich, Toms in diese Richtung zu erweitern? -- Arne Johannessen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nationalstraße und Autobahn gleichzeit ig?
Frederik Ramm frede...@remote.org wrote: Tirkon wrote: Ich weiß nicht, ob das technisch funktioniert: Kann man die zerstückelte Relation (Unterhaltung) zusammen mit den Autobahnabschnitten in eine Vaterrelation (Netzgedanke) packen? Man kann das durchaus von Datenmodell und Editoren her. Nunja, Potlatch kennt weder kaskadierte noch sortierte Relationen. Einzig JOSM kann sie handeln. Nicht alle Programme gehen mit solchen kaskadierenden Relationen schon richtig um, aber meine Ueberzeugung ist es, dass wir grundsaetzlich ueberall beliebig viele Ebenen von kaskadierenden Relationen erlauben muessen. Eine Relation mit den Ways A, B, C, D muss gleich ausgewertet werden wie eine Relation, die die Relationen R1 (A, B) und R2 (C, D) enthaelt. Dazu müsste man im speziellen Fall die Autobahnabschnitte (Ersatzstrecken) einer Bundesstraße in eine eigene Relation packen. Ansonsten werden unsere Relationen immer groesser und unhandlicher. Fuer Staatsgrenzen sind solche kaskadierenden Relationen z.B. bereits ueblich. Damit rennst Du bei mir offene Türen ein. Dazu bedarf es aber einer besseren Unterstützung durch die Editoren, wenn das Gros der Anwender nicht davor kapitulieren soll und diese Konstrukte nur noch von wenigen Usern mit Programmiererfahrung gehandelt werden können. Das bedeutet, dass damit in der Fläche nicht mehr editiert und gepflegt wird. Ich habe mich ja schon in einem früheren ausführlichen Thread für einen Ersatz der Tags durch Relationen bei gleichzeitiger besserer Unterstützung der Relationen in den Editoren ausgesprochen. Damit müsste der User nicht auf den Renderer warten, um die ausgewertete kaskadierte Relation zu betrachten, sondern könnte dies gleich im Editor im Zuge von Änderungen nachvollziehen. Dies würde der bisher schwierig zu durchschauenden kaskadierten Relation den Schrecken nehmen, zum verstärkten Gebrauch anregen und somit einige der derzeitigen Problemfelder wie z.B. ÖPNV, Linienbündel und verkehrsfunktionell oder baulich getrennte Richtungsfahrbahnen einer Lösung näherbringen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ORS mit Trojaner?!
Hallo, liegt das an mir, oder ist da was faul? Wenn ich auf ORS gehe, meldet avast! einen Trojaner und trennt die Verbindung. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Vor zwei Tagen (am 12.02) hat bei mir AntiVir auch Alarm geschlagen (HTML/Crypted.Gen). 5 Minuten später funktionierte jedoch alles wieder. Dann lag das doch nicht an mir(?). On Sun, 14 Feb 2010 20:56:36 +0100, André Reichelt andr...@online.de wrote: Hallo, liegt das an mir, oder ist da was faul? Wenn ich auf ORS gehe, meldet avast! einen Trojaner und trennt die Verbindung. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Naabend, Am Sonntag 14. Februar 2010 20:56:36 schrieb André Reichelt: Wenn ich auf ORS gehe, meldet avast! einen Trojaner und trennt die Verbindung. Also sowohl http://data.giub.uni-bonn.de/openrouteservice/ als auch http://openrouteservice.org/ starten bei mir ohne Fehlermeldung. (Hab aber auch kein avast.) Gruß, Carsten -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.piranho.de/gpg.php = www.stopptdievorratsdatenspeicherung.de signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Hallo André, André Reichelt schrieb: liegt das an mir, oder ist da was faul? Wenn ich auf ORS gehe, meldet avast! einen Trojaner und trennt die Verbindung. Da scheint was faul zu sein: Bei mir wird sporadisch unter www.openrouteservice.org statt der normalen ORS-Seite eine Spam-Seite mit Downloadmöglichkeiten von populärer Software und Kaufmöglichkeiten diverser populärer Medikamente angeboten. Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am 13.02.2010 22:22, schrieb Andreas Neumann: http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=-25.4,35.3,48.1,71.7]) Selbst bei nem winzigen Bereich wie http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=9.99,10.0,49.0,49.01] Lädt der mir 100 MB Daten runter. Was mache ich falsch? Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Michael Bemmerl osm-t...@mx-server.de wrote: Da scheint was faul zu sein: Bei mir wird sporadisch unter www.openrouteservice.org statt der normalen ORS-Seite eine Spam-Seite mit Downloadmöglichkeiten von populärer Software und Kaufmöglichkeiten diverser populärer Medikamente angeboten. www.openrouteservice.org ist ja so ein häßlicher Frame redirect auf http://data.giub.uni-bonn.de/openrouteservice/ Gruss Sven -- TCP/IP: telecommunication protocol for imbibing pilsners (Man-page uubp(1C) on Debian/GNU Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten - Langlaufloipe
Am 14. Februar 2010 19:07 schrieb Markus liste12a4...@gmx.de: Wie trägt man eine Langlaufloipe möglichst sinnig ein? Ich mache das so wie hier beschrieben: http://wiki.openstreetmap.org/wiki/User:Langl%C3%A4ufer/Loipemap HTH Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Michael Bemmerl schrieb: Da scheint was faul zu sein: Bei mir wird sporadisch unter www.openrouteservice.org statt der normalen ORS-Seite eine Spam-Seite mit Downloadmöglichkeiten von populärer Software und Kaufmöglichkeiten diverser populärer Medikamente angeboten. Da scheint wohl der Server unter 62.67.244.29 gekapert worden sein: Der normale Frame-Redirect wird von einem Internet Information Server mit PHP 4.4.0 (sic!) ausgeliefert, während der Spam von einem Apache mit PHP 5.2.6 kommt. Wohlgemerkt unter gleicher IP Port. Wer sich's mal ohne Gefahr angucken möchte, ich habe einen Screenshot erstellt: http://osm.michis-pla.net/temp/ors-spam.png Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Nabend, Am Sonntag 14. Februar 2010 21:27:09 schrieb André Reichelt: http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=9.99,10.0,49.0 ,49.01] Syntax beachten! [bbox=west,süd,ost,nord] Gruß, Carsten -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.piranho.de/gpg.php = www.stopptdievorratsdatenspeicherung.de signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Michael Bemmerl osm-t...@mx-server.de wrote: Der normale Frame-Redirect wird von einem Internet Information Server mit PHP 4.4.0 (sic!) ausgeliefert Aua! Ich hatte Pascal schon vor längerer Zeit gesagt, dass man die Domain zu einem richtigen Provider migrieren sollte, damit das gleich auf die richtige IP zeigt. Wer sich's mal ohne Gefahr angucken möchte, ich habe einen Screenshot erstellt: http://osm.michis-pla.net/temp/ors-spam.png /me verwendet kein Windows. Gruss Sven -- Software patents are the software project equivalent of land mines: Each design decision carries a risk of stepping on a patent, which can destroy your project. (Richard M. Stallman) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Carsten Gerlach wrote: Nabend, Am Sonntag 14. Februar 2010 21:27:09 schrieb André Reichelt: http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=9.99,10.0,49.0 ,49.01] Syntax beachten! [bbox=west,süd,ost,nord] Gruß, Carsten Kleiner Tipp: Bei JOSM auf Download gehen, auf der slippy Map den Bereich auswählen. Dann kann man im zweiten Tab die Koordinaten ganz bequem kopieren. (Und gleich in der richtigen Reihenfolge :) ) __ Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Sven Geggus schrieb: Michael Bemmerl osm-t...@mx-server.de wrote: Der normale Frame-Redirect wird von einem Internet Information Server mit PHP 4.4.0 (sic!) ausgeliefert Aua! Ich hatte Pascal schon vor längerer Zeit gesagt, dass man die Domain zu einem richtigen Provider migrieren sollte, damit das gleich auf die richtige IP zeigt. Scheint tatsächlich der komplette Server kompromittiert worden sein: Unter anderen Domains wie leonhard-dittmann.de ostsee-sellin.de wird die gleiche Seite angezeigt... Ich hab' Evanzo mal eine E-Mail geschrieben. Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten - Langlaufloipe
Danke Colin für den Tip! Etwas schade finde ich, dass das ganze Winter-Zeugs nicht auf der PisteMap stattfindet; Ski, Langlauf, Skitouren, Gletschertouren, Eislaufen, Iglu-Dorf, und danach Hallenbad, Sauna, Kneipe... Aber vielleicht übernimmt die PisteMap die Loipen ja auch irgendwann. Wie kann ich die Attribute von einer Relation auf eine andere kopieren? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hosting für OSMdoc gesucht
Hallo, wie einige vielleicht wissen habe ich die letzten Monate ordentlich an osmdoc.com rumgewerkelt und einiges neues entwickelt. Ich komme jetzt in die Phase wo ich mal Alpha/Beta-Versionen ins Netz stellen würde (ich warte hauptsächlich noch darauf, dass es endlich einen korrigierten History-Export gibt). Ich habe allerdings ein großes Problem: Hosting fehlt. Der bisherige Host (Webfaction) reicht für die aktuelle Funktionalität aus aber viel mehr ist nicht drin. Was brauche ich: Minimalversion: Einen Server mit 50GB+ Festplattenspeicher und 1GB+ RAM (Solr + Webserver) Kurzversion: Ich suche einen/mehrere Server zum hosten von OSMdoc. Vor allem RAM und Festplattenspeicher kann ich benutzen/gebrauchen. RAM 4GB wäre gut, Festplattenplatz kann ich auch bis zu 500+ GB brauchen (Solr, HBase, Webserver). Je mehr von allem desto besser, je weniger desto weniger Funktionalität kann ich bieten. Langversion: Die bisherige OSMdoc Version nutzt nur einen Planetdump und lädt das ganze recht naiv in eine PostgreSQL Datenbank (insgesamt ca. 15GB). Das Frontend ist in Python mit Django geschrieben. Das ist zwar gut und die Seite ist so auch schon sinnvoll aber ich habe eine ganze Menge Featurerequests* bekommen und einiges davon auch umgesetzt. So läuft das ganze nun mit der kompletten OSM History und beachtet das auch bei der Auswertung von Tags (wieviele User benutzen ein Tag, ...). Die Suche benutzt nun Solr[1] und ich lade das ganze in eine HBase Datenbank[2]. Beides sind im Endeffekt Dienste denen man beliebig viele Ressourcen geben kann. Daher kann ich nicht ganz genau sagen was ich brauche: Ich nehme was ich kriegen kann :) Wenn ich die komplette DB mit allem was dazugehört auf den/die Server bekomme sind es am Ende sicher 500-1000GB. Wenn das klappt könnte ich minütliche Updates für die Daten geben und einen Mirror für die API anbieten (ähnlich wie XAPI, praktisch als Nebenprodukt), wenn nicht lasse ich das weiter bei mir zu Hause laufen und mache unregelmäßige Datenupdates auf dem Server. Je kleiner der Server wird desto mehr Features schalte ich ab bzw. veröffentliche sie nicht. Und wenn ich gar nichts passendes finde lade ich das ganze wie bisher in die alte OSMdoc Version dann gäbe es einfach nur neue Daten aber keine neuen Funktionen. Auch schon gut aber dies ist der Versuch ob vielleicht ein paar edle Spender mitlesen. Traffic bekommt die Seite nicht all zu viel (50 - 100 Besucher am Tag) aber ich würde damit rechnen, dass das mehr wird mit einer neuen und regelmäßig aktualisierten Version. Aber ich glaube das ist das geringste Problem. Was kann ich bieten: Leider nicht viel? Ich kann pro Monat einen kleinen Betrag zahlen aber das dürfte sich nur im Rahmen üblicher Shared-Hosting-Preise befinden. Ich weiß, dass ich dafür nicht das bekomme was ich suche daher hier die Frage. Ich bin in irgendeiner Weise auf Hilfe oder Sponsoring angewiesen wenn ich die neue Version online schalten will. Ich schalte natürlich gerne Links auf den/die großzügigen Spender. Ansonsten kann ich nur Zugriff auf die ganzen Daten bieten in der Hoffnung, dass sie für irgendwen sinnvoll sind. Da das ganze in HBase liegt ist es z.B. auch einfach per MapReduce[3] (oder auch Pig[4], Hive[5]) drauf zuzugreifen und Anfragen zu starten. Ich habe auch kein Problem damit (ich plane es eigentlich eh zu tun) den dazugehörigen Quellcode zu öffnen. Wann: - Ich bin geduldig :) Ich brauche sicher noch ca. einen Monat um etwas zu haben was ich veröffentlichen kann aber für Tests, das einlesen der Daten und Alpha-Versionen kann ich auf jeden Fall ab sofort etwas gebrauchen. Sonstiges: -- Bei Fragen hierzu einfach antworten oder mir privat schreiben. Ich bin natürlich auch immer daran interessiert was sich von einer neuen Version von OSMdoc gewünscht wird. Ich habe auch in unregelmäßigen Abständen im OSMdoc-Blog[6] berichtet. Also falls sich irgendein freundlicher Sponsor findet oder irgendeine Firma das verlangen hat ein paar Server loszuwerden freue ich mich über jeden Kontakt. Gruß, Lars [1] http://lucene.apache.org/solr/ [2] http://hadoop.apache.org/hbase/ [3] http://hadoop.apache.org/mapreduce/ [4] http://hadoop.apache.org/pig/ [5] http://hadoop.apache.org/hive/ [6] http://osmdoc.blogspot.com/ * Einige der Featurerequests in keiner speziellen Reihenfolge: - Sprachanalyse für Tags/Verknüpfen von gleichen Tags in unterschiedlichen Sprachen - Wie häufig wurde ein Tag hinzugefügt/verändert/gelöscht und von wievielen verschiedenen Nutzern (Beliebtheitswert für Tag - Mehr Aussagekraft als momentane Nutzungszahlen) - Häufigere Datenaktualisierung - Tippfehler auf korrekte Tags verlinken - Auswertung von Tags mit mehreren Werten (mit Semikolon getrennt) - Auswertung von Relationsrollen - Auswertung von Tagkombinationen (wie häufig wird X mit Y zusammen verwendet) inkl. Rollen - Welche Tags verwendet ein User - Wo wird ein Tag verwendet (geografisch) - Moeglichkeit die Elemente auf
Re: [Talk-de] Wiki: Skipisten - Langlaufloipe
Naabend, Am Sonntag 14. Februar 2010 22:21:06 schrieb Markus: Wie kann ich die Attribute von einer Relation auf eine andere kopieren? In JOSM gibt es eine Funktion Neue Relation aus Kopie der ausgewählten erstellen. Zwischen zwei bestehenden Relationen tags zu kopieren ist mir nicht bekannt. Gruß, Carsten -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.piranho.de/gpg.php = www.stopptdievorratsdatenspeicherung.de signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hosting für OSMdoc gesucht
Am Sonntag 14 Februar 2010 22:32:24 schrieb Lars Francke: Hallo, wie einige vielleicht wissen habe ich die letzten Monate ordentlich an osmdoc.com rumgewerkelt und einiges neues entwickelt. Ich komme jetzt in die Phase wo ich mal Alpha/Beta-Versionen ins Netz stellen würde (ich warte hauptsächlich noch darauf, dass es endlich einen korrigierten History-Export gibt). Ich habe allerdings ein großes Problem: Hosting fehlt. Der bisherige Host (Webfaction) reicht für die aktuelle Funktionalität aus aber viel mehr ist nicht drin. Was ist mit dem Dev-Server von OSM? Den benutze ich für meine OpenLinkMap auch. Was brauche ich: Minimalversion: Einen Server mit 50GB+ Festplattenspeicher und 1GB+ RAM (Solr + Webserver) Kurzversion: Ich suche einen/mehrere Server zum hosten von OSMdoc. Vor allem RAM und Festplattenspeicher kann ich benutzen/gebrauchen. RAM 4GB wäre gut, Festplattenplatz kann ich auch bis zu 500+ GB brauchen (Solr, HBase, Webserver). Je mehr von allem desto besser, je weniger desto weniger Funktionalität kann ich bieten. Langversion: Die bisherige OSMdoc Version nutzt nur einen Planetdump und lädt das ganze recht naiv in eine PostgreSQL Datenbank (insgesamt ca. 15GB). Das Frontend ist in Python mit Django geschrieben. Das ist zwar gut und die Seite ist so auch schon sinnvoll aber ich habe eine ganze Menge Featurerequests* bekommen und einiges davon auch umgesetzt. So läuft das ganze nun mit der kompletten OSM History und beachtet das auch bei der Auswertung von Tags (wieviele User benutzen ein Tag, ...). Die Suche benutzt nun Solr[1] und ich lade das ganze in eine HBase Datenbank[2]. Beides sind im Endeffekt Dienste denen man beliebig viele Ressourcen geben kann. Daher kann ich nicht ganz genau sagen was ich brauche: Ich nehme was ich kriegen kann :) Wenn ich die komplette DB mit allem was dazugehört auf den/die Server bekomme sind es am Ende sicher 500-1000GB. Wenn das klappt könnte ich minütliche Updates für die Daten geben und einen Mirror für die API anbieten (ähnlich wie XAPI, praktisch als Nebenprodukt), wenn nicht lasse ich das weiter bei mir zu Hause laufen und mache unregelmäßige Datenupdates auf dem Server. Je kleiner der Server wird desto mehr Features schalte ich ab bzw. veröffentliche sie nicht. Und wenn ich gar nichts passendes finde lade ich das ganze wie bisher in die alte OSMdoc Version dann gäbe es einfach nur neue Daten aber keine neuen Funktionen. Auch schon gut aber dies ist der Versuch ob vielleicht ein paar edle Spender mitlesen. Traffic bekommt die Seite nicht all zu viel (50 - 100 Besucher am Tag) aber ich würde damit rechnen, dass das mehr wird mit einer neuen und regelmäßig aktualisierten Version. Aber ich glaube das ist das geringste Problem. Was kann ich bieten: Leider nicht viel? Ich kann pro Monat einen kleinen Betrag zahlen aber das dürfte sich nur im Rahmen üblicher Shared-Hosting-Preise befinden. Ich weiß, dass ich dafür nicht das bekomme was ich suche daher hier die Frage. Ich bin in irgendeiner Weise auf Hilfe oder Sponsoring angewiesen wenn ich die neue Version online schalten will. Ich schalte natürlich gerne Links auf den/die großzügigen Spender. Ansonsten kann ich nur Zugriff auf die ganzen Daten bieten in der Hoffnung, dass sie für irgendwen sinnvoll sind. Da das ganze in HBase liegt ist es z.B. auch einfach per MapReduce[3] (oder auch Pig[4], Hive[5]) drauf zuzugreifen und Anfragen zu starten. Ich habe auch kein Problem damit (ich plane es eigentlich eh zu tun) den dazugehörigen Quellcode zu öffnen. Wann: - Ich bin geduldig :) Ich brauche sicher noch ca. einen Monat um etwas zu haben was ich veröffentlichen kann aber für Tests, das einlesen der Daten und Alpha-Versionen kann ich auf jeden Fall ab sofort etwas gebrauchen. Sonstiges: -- Bei Fragen hierzu einfach antworten oder mir privat schreiben. Ich bin natürlich auch immer daran interessiert was sich von einer neuen Version von OSMdoc gewünscht wird. Ich habe auch in unregelmäßigen Abständen im OSMdoc-Blog[6] berichtet. Also falls sich irgendein freundlicher Sponsor findet oder irgendeine Firma das verlangen hat ein paar Server loszuwerden freue ich mich über jeden Kontakt. Gruß, Lars Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am 14.02.2010 21:38, schrieb Carsten Gerlach: Nabend, Am Sonntag 14. Februar 2010 21:27:09 schrieb André Reichelt: http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=9.99,10.0,49.0 ,49.01] Syntax beachten! [bbox=west,süd,ost,nord] So? Habs direkt aus JOSM rauskopiert (oben-links, unten-links, oben-rechts, unten-rechts). http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=49.05407025156395,49.19067925930702,9.6514892578125,10.15411376953125] Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hosting für OSMdoc gesucht
Hallo! Danke für den Hinweis! Ich wollte in meiner ursprünglichen Mail noch drauf eingehen (aber die ist schon so lang genug geworden ;-) ), habe es dann aber vergessen. Ich habe allerdings ein großes Problem: Hosting fehlt. Der bisherige Host (Webfaction) reicht für die aktuelle Funktionalität aus aber viel mehr ist nicht drin. Was ist mit dem Dev-Server von OSM? Den benutze ich für meine OpenLinkMap auch. Die Server scheinen ja grundsätzlich sehr gut zu sein und das ist auf jeden Fall eine Option allerdings vermute ich, dass es ein paar Probleme mit der Ressourcennutzung gibt: Zum einen koennte ich die Festplatte(n) schon alleine fast füllen, zum anderen hat HBase keinerlei Zugriffskontrolle - jeder mit Zugriff auf dem Server koennte also theoretisch, ob absichtlich oder ausversehen beim rumspielen, Daten ändern, loeschen usw. Dann wäre das so wie es aussieht das dritte Programm gleicher Machart auf dem Server (TagWatch, tagstat) und die MapReduce-Jobs sowie HBase koennen ziemlich IO intensiv sein. Ich habe da keine Beweise für würde aber vermuten, dass das den Betrieb der übrigen Programme stoeren koennte. Aber für nur einen Solr-Server klingt das auf jeden Fall gut. Ich werde das im Hinterkopf behalten und mich mal im Wiki bewerben. Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Michael Bemmerl osm-t...@mx-server.de wrote: Scheint tatsächlich der komplette Server kompromittiert worden sein: Unter anderen Domains wie leonhard-dittmann.de ostsee-sellin.de wird die gleiche Seite angezeigt... Ich hab' Evanzo mal eine E-Mail geschrieben. Ich lande auch bei deisen Domains auf den richtigen Seiten. Sven -- Der normale Bürger ist nicht an der TU Dresden und schreibt auch nicht mit mutt. (Ulli Kuhnle in de.comp.os.unix.discussion) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ORS mit Trojaner?!
Sven Geggus schrieb: Michael Bemmerl osm-t...@mx-server.de wrote: Scheint tatsächlich der komplette Server kompromittiert worden sein: Unter anderen Domains wie leonhard-dittmann.de ostsee-sellin.de wird die gleiche Seite angezeigt... Ich hab' Evanzo mal eine E-Mail geschrieben. Ich lande auch bei deisen Domains auf den richtigen Seiten. Einfach mehrmals neu laden, die Spam-Seite wechselt sich mit der echten ab. Bei mir ist die Chance, den Spam zu treffen so ca. 20 %. Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am Sonntag 14. Februar 2010 22:42:26 schrieb André Reichelt: Syntax beachten! [bbox=west,süd,ost,nord] So? Habs direkt aus JOSM rauskopiert (oben-links, unten-links, oben-rechts, unten-rechts). Vielleicht reden wir aneinander vorbei. Deine Angabe oben-links wäre ja schon eine Koordinatenangabe ala 47,11 Außerdem hast du oben und links usw. je zwei mal drin. Brauch man ja nicht. Die Angabe [bbox=links,unten,rechts,oben] (oder halt [bbox=west,süd,ost,nord]) tut es. Beim Kopieren aus JOSM auch darauf achten, daß die Dezimaltrenner hier mit Komma kommen, die XAPI aber Punkte haben will. JOSM -- 6,85067,51,47437,6,85271,51,47544 XAPI -- 6.85067,51.47437,6.85271,51.47544 Probier mal http://www.informationfreeway.org/api/0.6/*[railway=*] [bbox=6.85067,51.47437,6.85271,51.47544] (Oberhausen HBF). Klappt das so jetzt? Gruß, Carsten -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.piranho.de/gpg.php = www.stopptdievorratsdatenspeicherung.de signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki: Skipisten - Langlaufloipe
Danke Carsten, das hat geholfen: Funktion Neue Relation aus Kopie der ausgewählten erstellen. Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am 14.02.2010 23:37, schrieb Carsten Gerlach: Am Sonntag 14. Februar 2010 22:42:26 schrieb André Reichelt: Syntax beachten! [bbox=west,süd,ost,nord] So? Habs direkt aus JOSM rauskopiert (oben-links, unten-links, oben-rechts, unten-rechts). Vielleicht reden wir aneinander vorbei. Deine Angabe oben-links wäre ja schon eine Koordinatenangabe ala 47,11 Außerdem hast du oben und links usw. je zwei mal drin. Damit war die Reihenfolge im Fenster Koordinaten in JOSM gemeint. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am 14.02.2010 23:37, schrieb Carsten Gerlach: Probier mal http://www.informationfreeway.org/api/0.6/*[railway=*] [bbox=6.85067,51.47437,6.85271,51.47544] (Oberhausen HBF). Klappt das so jetzt? Prima, hat wunderbar funktioniert. Danke! Wie mache ich das denn nun in GPS-Babel? Einfaches konveriteren klappt schon, aber kann ich da Stile anhand der Tags einstellen? Also dass Bahnübergänge ein bestimmtes Symbol bekommen usw. Oder das Strecken eine bestimmte Farbe bekommen. Gruß und Danke, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mails blocken ohne betreff? war: (kein Betreff)
moin On 14.02.2010, at 15:48, malenki wrote: AssetBurned schrieb: On 14.02.2010, at 15:17, Lars Francke wrote: egal wie oder warum eine E-Mail hier landet so verwende doch bitte wenigstens einen Betreff. Das ist nicht nur sehr einfach zu machen sondern erleichtert auch allen anderen das Folgen der Konversationen. das bringt mich auf die idee... könnte man nicht einfach die mailingliste so einstellen das sie keine mails mehr annimmt die über keinen betreff (oder diesen unsäglichen default betreff) verfügen? mails von leuten die nicht auf der mailingliste stehen werden ja auch nicht durchgelassen. [ ] du kennst gmane korrekt, muß man immer alles kennen? Ansonsten könnten wir noch auf html-Mails, ToFu, Kammquoting, überlange Zeilen, korrekte Groß/Kleinschreibung, Rechtschreibung und Satzbau filtern, allzu technische Sachen ebenfalls außen vor lassen (verwirrt nur), GoogleMail aussperren (weil, Google ist doof), alle Mails von MS-Systemen nicht durchlassen (weil, dort sitzen Klicki-Bunti-Nutzer - obwohl das gilt eigentlich auch für Mac und X-Linuxer) - hab ich was vergessen? naja ich find's ne sinnvolle frage, normalerweise landen hier mails ohne betreff ziemlich ungefragt im spam ordner und das ist meines wissens nicht nur bei mir so. was die anderen punkte angeht. jo gute idee... kann ich meinen alten C128D wieder rauskramen und meine mails über den akkustik koppler verschicken... die frage ist nur ob ich noch irgendwo ne passende gegenstelle finde die meine mails dann ans i-net weiterleiten kann. aber die vorstellung ohne diesen klicki bunti krams zu arbeiten ist irgendwie verlockend :-) cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mails blocken ohne betreff? war: (kein Betreff)
moin On 14.02.2010, at 16:52, Michael Buege wrote: Zitat AssetBurned: [...] das bringt mich auf die idee... könnte man nicht einfach die mailingliste so einstellen das sie keine mails mehr annimmt die über keinen betreff (oder diesen unsäglichen default betreff) verfügen? Warum laesst du das nicht deinen Mail.- oder Newsclient machen? weil man dann leider immer wieder irgendwelche halbwegs sinnvollen diskussionen verpasst von leuten die zu faul sind (oder es schlicht vergessen haben) einen betreff einzugeben. hab ich schon zu häufig gemacht in verschiedensten mailinglisten, immer mit dem selben ergebniss. dann lieber direkt beim betreiber der mailingliste die mails einmal bouncen lassen (analog zur falschen absender adresse) und dem sender auf seinen fehler hinweisen lassen. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Normierung von Seezeichen (was: kein Betreff)
moin On 14.02.2010, at 20:02, Arne Johannessen wrote: AssetBurned wrote: [...] Sind diese Tonnen nicht international oder zumindestens national normiert? Ja, sicher. Aber erstens gibt es zahllose verschiedene Normen für Schifffahrtszeichen. Allein in Deutschland z. B. eine internationale [...] dann sollte es doch ohne weiteres möglich sein auf diesen normen aufzubauen und ne einheitliche struktur zu schaffen. Klar, das ist im Prinzip durchaus möglich und wird offenbar auch von OSeaM und FT angestrebt. Unter anderem wegen der zuvor beschriebenen Komplexität der tatsächlichen Verhältnisse ist das aber nicht ganz so einfach, wie es klingt. ok anders ausdrücken. es gibt da zwei gruppen von leuten. die sich jeweils für sich selbst auf bestimmte verfahren geeinigt haben. hier sind also nur noch 2 parteien involviert und nicht nen halbesduzend nationaler/puselmuckeldorfer verfahren wenn die einen meinen (achtung keine sachkenntniss) da muss ne gefahrentonne nord-ost hin und die andern hätten lieber gelbe tonne mit zwei nach unten gerichteten pfeilen... heck dann ist letzteres preziser und das sollte genommen werden für die tags. vorrausgesetzt die tonne vor ort schaut wirklich so aus. ansonsten muß dann die editor software halt entsprechende alternativen anbieten und die nur anzeigende software ... nun die kann anzeigen was sie will solange die bedeutung der tonne klar wird. es sollte doch möglich sein eine auflistung aller von ihnen genutzter tags zu machen, zu schauen ob sich da tags widersprechen und dann die tags zusammen zu legen. ich meine ist ja nicht so als wenn die eine gruppe tags das backbord tonnen grün sind und die anderen meinen die sind rot. selbst wenn man sich auf die verschiedenen verfahren zum makieren von schifffahrtsstraßen in USA und Deutschland einschießen würde, könnte man ja schlicht sagen gemappt wird was man vor ort sieht egal was die theorie sagt! wenn die beiden gruppierungen aber (mal wieder drastisch geschrieben) zu blöd sind jeweils eine liste ihrer tags und wofür sie die benutzen, zu machen. dann ham sie ganz andere probleme. wobei zumindest die programmierer der jeweiligen editoren scheinen ja zu wissen welche tags es gibt und ein grundverständniss für bedeutung der tags in realer welt scheinen sie auch zu haben böse gesagt müsste man sich also nur mit den schreibern der apps zusammensetzen und in ner nacht und nebel aktion diese zu einen einheitlichen system überreden. den nutzern ist es ja egal was da im hintergrund so passiert, hauptsache auf ihrer karte erscheint nachher das richtige symbol. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Toppzeichen gesperrte Wasserflaeche
Hallo Arne, [] Der Editor hat an dieser Stelle keinen grundsätzlichen Fehler. Er schreibt _alle_ Daten _unverändert_ in die Datenbank zurück. Habe ich inzwischen mehrfach getestet. Was ist jetzt hier passiert? Der Leo hat ein Seezeichen zum bearbeiten geöffnet. Der Editor hat die Daten des Seezeichens geladen und das Topzeichen als unbekannt dargestellt, da er rot weiß rote Topzeichen nicht kennt. Ich schlage als Alternative mal den Begriff benutzerdefiniert / user defined vor. Einem Editor unbekannte Werte werden zumindest am Mac normalerweise so bezeichnet. Hier halte ich das für besser, weil dadurch klarer zum Ausdruck kommt, dass tatsächlich ein Wert gesetzt ist. Das ist eine gute Idee, ich werde sie bei den anstehenden Fixes berücksichtigen. Danke für den Tipp. Hätte der Leo dieses so gelassen wie es ist, wäre nichts passiert. Die Schlüssel wären genauso wieder in die Datenbank geschrieben worden. Nun hat der Leo aber, da er das rot weiß rote Topzeichen nicht auswählen konnte, gesagt dann hat die Tonne halt kein Topzeichen, und _bewusst_ das Topzeichen abgewählt. [...] Die hier diskutierte Tonne ohne Toppzeichen _darzustellen_ ist sicherlich okay. Dazu das Toppzeichen aus der Datenbank zu _löschen_, kann aber nicht die Lösung sein. Das Topzeichen zu löschen war ganz bestimmt nicht meine Absicht. Dies ist leider nur aufgrund einer Verkettung unglücklicher Umstände auf Seiten des Editors und des Benutzers entstanden. Hätte der Benutzer das Topzeichen nicht bewusst abgewählt wäre es nicht gelöscht worden. Hätte der Editor deutlicher angezeigt, dass Werte vorhanden sind mit denen er nicht umgehen kann, hätte der Benutzer die Werte wahrscheinlich nicht abgewählt. Daraus ergibt sich für mich ein weiterführendes Problem. Nicht wie ich mit rot weiß roten Topzeichen umgehe, sondern wie ich mit unbekannten Daten umgehe. Der Renderer hätte in dieser Situation (unbekanntes Topzeichen) die Tonne ohne Topzeichen dargestellt. Dies führt bei meinen Überlegungen immer wieder zu dem grundsätzlichen Problem Taggen für den Renderer. Sprich: Wie schaffe ich es Leute davon abzuhalten in der Datenbank an den Werten zu drehen bis sie ihre Änderungen endlich auf der Karte sehen. Ich persönlich sage immer (soweit es mich betrifft (Seezeichen)): Schreibt mir, was ihr eintragen wollt und wie es dargestellt werden soll, dann können wir über jeden Sonderfall im Detail diskutieren. Dies tun jedoch leider die wenigsten. In dem speziellen Fall trifft mich jedoch eine gewisse Mitschuld. Ich wurde vom Leo bereits Mitte Dezember auf die rot weiß roten Topzeichen angesprochen und habe dies aufgrund anderer, für mich wichtigerer Probleme, immer wieder vor mir hergeschoben. Bis es jetzt eskaliert ist und ich einen Fix für dieses Problem bereitstelle. Was habe ich für mich daraus gelernt? Ich werde ab sofort den Editor bei bekannten Schlüssel, aber unbekannten Wert, gar nichts mehr anzeigen lassen, um Leute daran zu hindern unbekannte Einträge zu löschen. [...] Klingt, als löse diese Änderung das Problem aus Sicht von OSM. Allerdings sieht die Toms-GUI nur eine Checkbox für Toppzeichen ja oder nein vor. Unterschiedliche Toppzeichen für denselben Tonnentyp können daher nicht mit Toms verarbeitet werden. Oder übersehe ich etwas? Ich bin nicht der Autor von dem Toms-Plugin für den JOSM sondern habe einen Online-Editor für OpenSeaMap unter http://map.openseamap.org/map/map_edit.php geschrieben. Auch hier besteht aber das Problem, dass es nur eine Checkbox für das Topzeichen gibt. In fast allen Fällen genügt dies auch, da das Topzeichen sich durch die Tonne selbst ergibt. Die einzige Ausnahme sind die Sonderzeichen Tonnen (SpecialPurpose). Diese können unterschiedliche Topzeichen haben. Dies berücksichtige ich, in dem bei der Auswahl einer Sonderzeichen Tonne eine weitere Auswahl-Box erscheint, in der ich das Topzeichen speziell auswählen kann. Es existieren ja nun durchaus Seezeichen, die nicht IALA, BinSchStrO oder sonstigen Normen entsprechen. Die haben dann teilweise auch recht unterschiedliche Toppzeichen. Beispiele: - DW-Route Kadetrinne mit gelben Lateraltonnen - dänische Regattatonnen mit Flagge - Reisig auf Pricken im Wattenmeer - improvisierte Betonnung Marke Benzinkanister mit Gewicht dran - privat bezeichnete Gewässer In der Kadetrinne habe ich bis jetzt noch keine gelben Lateraltonnen gesehen oder bekommen, wenn dies ein Thema wird müssen wir uns darüber Gedanken machen. Regattatonnen werden auf dem Sports-Layer dargestellt. Dort ist grundsätzlich alles erlaubt. Für Pricken gibt es ein genormtes Steuerbord bzw Backbord Symbol, das in dem Sinne keine Topzeichen beinhaltet. Diese werden auch als perch starboard bzw perch port in die Datenbank geschrieben. Topzeichen werden vom Editor bei dieser Auswahl disabled, da es in dem Sinne keine Topzeichen gibt. Improvisierte bzw. private Betonnung können wir zur
Re: [Talk-de] ref-Tags in Relationen und Wegsegmenten
Am 12. Februar 2010 22:44 schrieb Mirko Küster webmas...@ts-eastrail.de: Wenn Du eine Aussage ueber eine Sichtweise gemacht haettest (ist mir nicht zugaenglich, ist mit zu aufwendig oder ist mir nicht bekannt), haette es fuer mich keinen Grund zum Widerspruch gegeben. Ok, ich stelle ab jetzt im jedem Post ein ist mir nicht bekannt! voran oder organisiere mir eine Glaskugel. Es ist auf einer öffentlichen Mailingliste, die im übrigen ja auch im Web archiviert wird, eben nicht unwichtig, dass die Aussagen dort zuverlässig sind, insbesondere, wenn es um technische Details geht. Wenn Du Dich nicht auskennst, wie die History-informationen gespeichert werden, ist das ja nicht schlimm, nur brauchst Du dann eben auch nicht so zu tun, als wüsstest Du es, um dann halbgare Aussagen daraus abzuleiten (Ehemalige Relationszugehörigkeiten werden nicht dokumentiert.). - Sie sind nicht gerade bequem von jedermann abfragbar - aber prinzipiell dokumentiert die Datenbank über die changesets alle Änderungen. An die Entwickler: Eine Historydatenbank/Schnittstelle, die diese Daten bequemer zur Verfügung stellen könnte, würde sicher begeistert aufgenommen. (Wo man z.B: auch Changesets für ein bestimmtes Gebiet abfragen kann, Ways ermitteln, wo sich nur die Nodes geändert haben, verschiedene Stände gerendert gegenübergestellt sieht, einzelne gelöschte Nodes ermitteln, ggf. Änderungen rückgängig machen kann, etc.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landuse: Verwaltungsflächen und allgem eine Flächen
Am 14. Februar 2010 18:24 schrieb Torsten Leistikow de_m...@gmx.de: Jan Tappenbeck schrieb am 14.02.2010 18:09: wie würdet Ihr folgende Flächen taggen: * öffentliche Verwaltung (Arbeitsamt, Polizei, Finanzamt - teilweise in Combinutzung) amenity=public_building und die Gebaeude selber dann mit building=yes amenity=public_building finde ich ein bisschen unglücklich. Das soll laut Wiki für öffentliche Gebäude genutzt werden, und so klingt der Tag für mich auch. Für die Flächen wäre ein landuse nicht schlecht. Von den derzeit in den Mapfeatures befindlichen passt am ehesten noch landuse=commercial. Nach meinem Englisch-Halbwissen klingt das allerdings auch nicht allzu gut für öffentliche Ämter. Wie wärs mit landuse=administration? Passt auf die Polizei auch nicht so richtig. Andere Ideen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
