Re: [Talk-de] OSMF Kontaktadresse
Markus wrote: SMTP error from remote mail server after RCPT TO: Du hast die eigentliche Fehlermeldung nicht gepostet die ab dem Punkt normalerweise folgt. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kernkraftwerke?
Torsten Breda wrote: Und die Gebiete wo ein Flugzeug abstürzen könnte, wo ein Anschlag stattfinden könnte, oder ein Bedienfehler. Ein Bedienfehler scheidet zum Glück aus denn es muss schon immer eine Kette von Bedienfehlern sein gefolgt von weiteren Fehlern. Anschläge sind auch gut, das kombiniert die Angst der Amerikaner mit der Deutschen Strahlenangst. Aber Meteoriteneinschläge sind noch ein Thema. Man könnte auch mal eine Karte mit den ganzen Bürgerinitiativen gegen neue Stromleitungen, Biogaskraftwerke, Windräder, Kohlekraftwerke und dem wegsprengen von Berggipfeln für neue und notwenige Speicherkraftwerke erstellen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kernkraftwerke?
Gary68 wrote: habe das auch für die node kraftwerke gemacht. siehe im wiki auf der mapgen.pl seite. ist beeindruckend genug. sollte mal auf ein wahlplakat - der richtigen partei. Zeichne auch die Erdbebenrisikogebiete ein (also alles wo mehr als 6.2 droht) und die Gebiete die Tsunamigefährdet sind. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnort
Markus wrote: Historisch vermute ich die Entwicklung so: Zuerst hatte man place=* als Punkt eingetragen, damit der Name in der Karte auftaucht. Und damit Orte in der Suche gefunden werden können. Später hat man landuse=residential ungefähr als Fläche eingetragen, ebenso ungefähr landuse=industrial, damit man den ungefähren Umriss auf der Karte sieht. Die kamen zwar nicht als nächstes sondern erst die Straßen aber das ist eigentlich auch nicht relevant. landuse ist nur eine Information wo WOhngebiete, Industriegebiete und sonstige Gebiete vorhanden sind. Zunehmend kamen highway=residential und higway=service hinzu, sowie einzelne POIs, damit man Routing ermöglichen kann. Das war die eigentliuch Idee von Openstreetmap (das street). Heute trägt man einzelne Häuser ein. Jeweils mit differenzierter Beschreibung und komplettem Adressen-Satz. Damit haben sich so unspezifische Angaben wie place und landuse m.E. erübrigt? Landuse hat absolut nichts mit dem Thema zu tun sondern ist eine andere Art von Information. Es sagt nur aus was dort vorhanden ist, Wald, Wohnegebiet etc. Ein Wohngebiet kennzeichnet keine Stadt/Ort. Ein landuse hat in den meisten Fällen auch keinen Namen. Du hast eine dritte Sache vergessen, die administrativen Grenzen. Eine kurze Gegenfrage: Wohin willst Du denn in die Karte springen wenn man nur noch die Häuse mit den Adressen hat und jemand sucht nur nach der Stadt ? PS: Vor allem die flächigen Attribute sind m.E. oft ziemlich willkürlich und ohne konkrete valide Aussage. Die Aussage das dort Wald, ein Wohngebiet vorhanden ist, ist keine valide Aussage ? Das sehe ich aber etwas anders. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zu viel '...more OSM coming soon'
Michael Buege wrote: Angaben zum verwendeten Browser waeren hilfreich. Aber Moment, ich schau mal in die Glaskugel... Sieht aus wie Firefox... Der Eintrag im Kontext Menü zum Blocken wurde in Firefox4 entfernt . Ich hatte OSM dort als Beispiel angegeben das es zu oft aus versehen passiert und die USer es nicht bemerken trotz der Infobar die davor warnt. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Deutsche Übersetzung Nomantim und Webseite
Hallo ! Mir sind 2 Dinge aufgefallen und ich hoffe das einer diese Fehler beseitigen könnte. Fall a) Wenn ich auf http://www.openstreetmap.com die Deutsche Hauptseite bekomme und links im Menü auf Dokumentation klicke, dann lande ich im englischen Wiki anstelle des Deutschen. b) Suche ich eine Wohngebietsstraße in Nominatim wie z.b. bahnhofstraße, Lemgo, dann erhalte ich als Ausgabe: Ortsgebiet Bahnhofstraße, Brake, Lemgo, Lippe, Regierungsbezirk . Es hat einer für highway=residential und landuse=residential die gleiche Übersetzung eingepflegt. Ich habe keine Ahnung wo mann den Fall a) lösen kann und Fall b) erfordert einen speziellen Übersetzungs-Wiki Account den man erst beantragen muss.Der Aufwand für eine Änderung erscheint mir allerdings zu extrem, vielleicht hat schon jemand dort einen Account ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Innenfläche wird nicht dargestellt
Jan Tappenbeck wrote: kann mir einer sagen warum das Gewerbegebiet innerhalb von http://www.openstreetmap.org/browse/way/69714693 nicht richtig gerendert wird trotz Multipolygon ? Ich habe mal den Tag des outer in das Multipolygon übertragen aber selbst das scheint nicht zu helfen. Ich würde einen mapnick Bug erstellen... Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Innenfläche wird nicht dargestellt
Jan Tappenbeck wrote: wo ??? Ich denke Du meinst mit wo das wo Du einen Bug Report erstellen kannst. Die Antwort lautet : http://trac.openstreetmap.org/ Allerdings hat das umsetzen des Tags vom outer auf die Relation das Problem behoben ! Ich hätte mehr Geduld haben sollen :-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ID 24502104
Hallo ! Der Mulitpolygon Relation für den Wald wurden TMC Daten hinzugefügt und das mag mapnik wohl nicht. Ich habe das TMC multipolygon mal vom eigentlichen Multipolygon getrennt, mal schaun ob es hilft. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inseln südöstl. von Indien sehr klein
o...@tappenbeck.net wrote: teilweise nicht richtig sind. Gut zu erkennen da es teilweise BING-Bilder gibt. Vielleicht sehnt sich mal einer nach Sonen ! Sind die Inseln nicht korrekt oder Bing ? Neben einem Versatz bei Bing ist beachten, das du nicht weißt, ob die Bilder bei Ebbe oder Flut aufgenommen wurden. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Manuel Reimer wrote: Ich habe verständnis dafür das man eine Straße in OSM einzeichnet wenn die Planung abgeschlossen ist und das Geld bewilligt ist aber doch nicht wenn noch an der Route rumgeschraubt wird und die Anwohner und dusseligen Bürgerinitiativen noch jahrelang dagegen klagen. Was ist daran dusselig, wenn sich die Bürger versuchen gegen das zu wehren, was die Politiker gegen ihren Willen zu beschließen versuchen? Schlimm genug, dass all diese Bemühungen viel zu oft umsonst sind. Weil heute nichts mehr geplant werden kann ohne das sich eine BI bildet. Strom will jeder haben aber ein Windrad, ein Kohlekraftwerk, ein Stausee, ein Biomassekraftwerk will keiner vor der Tür haben und eine Stromtrasse wegen der dezentralen Windenergie schon garnicht. Fast jeder hat ein Auto aber keiner will Straßen haben. Am lustigsten ist es, wenn sich bei einer Straße z.b. 2 BIs bilden die jeweils eine andere Trasse wollen und sich dann gegenseitig bekämpfen (siehe A30). Im Notfall muss dann Feldhamsterverleih.de herhalten wenn man schon vor Gericht verloren hat. Aber klar, die Schuld kann man immer auf die Politiker schieben, ist immer am einfachsten. Das gehört jetzt aber eigentlich nicht hierhin, darüber diskutiere ich gerne per Mail weiter. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Ulf Lamping wrote: Aber sei es drum . Fakten - bzw. Daten die zu Fakten werden - die sammeln wir. Planungszustände - sind keine Fakten. Auch über diesen Punkt kann man jetzt ewig diskutieren. Wenn dein Haus auf einmal viel weniger Wert (oder sogar unverkäuflich) wird, weil es zufälligerweise demnächst an einer neu geplanten (Hyperraum-)Umgehungsstraße liegt, sieht das auf einmal wieder ganz anders aus. Und was hat das mit OSM zu tun ? Zumindest so lange da nicht angefangen wird eine Straße zu bauen ? Es kann ja auch sein das die Abflugrouten des nahegelegenden Flughafens geändert werden von der DFS und schon hat man den gleichen Effekt. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
M∡rtin Koppenhoefer wrote: Am 20. Februar 2011 17:58 schrieb Stefan Sandrocksande...@gmx.de: Mapper mit dem Wald, was dann machen ? Aber sei es drum . Fakten - bzw. Daten die zu Fakten werden - die sammeln wir. Planungszustände - sind keine Fakten. durch die Wiederholung wird das nicht richtiger... Auch durch wiederholtes Abstreiten wird eine Grundlegende OSmM Regel nicht aufgehoben. Was spricht denn dagegen eine Spezialdatenbank für alle Planungen und deren Auswirkungen zu erstellen und nicht alles in die OSM Datenbank zu kippen und vollzumüllen ? Soll ich jetzt auch noch sowas in die OSm Datenbank kippen : http://de.wikipedia.org/wiki/Bundesautobahn_35 ? Es ist echt übel das selbst grundlegende Regeln in OSM von einigen verwässert wird. Das beste ist das sich hier Leute aufregen wenn es um das löschen geht. Wenn jemand etwas einfach in die DB reinkippt, wieso kann dann nicht jemand dieses auch genauso einfach wieder löschen ? Ich habe verständnis dafür das man eine Straße in OSM einzeichnet wenn die Planung abgeschlossen ist und das Geld bewilligt ist aber doch nicht wenn noch an der Route rumgeschraubt wird und die Anwohner und dusseligen Bürgerinitiativen noch jahrelang dagegen klagen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
Ulf Lamping wrote: Falls du die Regel meinst: wir mappen nur Dinge vor Ort (ich denke darauf beziehst du dich), die hat es *nie* als Regel gegeben! Da wird nichts verwässert. Glaube mir, ich bin lange genug dabei. Tja, da habe ich aber eine andere Ansicht. Wie schon gesagt, ich habe absolut kein Problem damit das man eine Straße in OSM einträgt die kurz vor dem Bau ist. Gute Idee! Radwege sind eh für mich nutzloses Kram, die lösch ich jetzt alle mal raus. Bis später ... Radwege sind existierende Objekte die auf dem Boden vorhanden sind und keine Luftstraßen, Jetsreams, Satellitenumlaufbahnen, verworfende Planungen wie http://de.wikipedia.org/wiki/Bundesautobahn_47 oder Plaungungen von Straßen die eventuell oder wahrscheinlich nie so gebaut werden. Ich habe während der ganzen Diskussion hier noch nicht ein für mich wirklich stichhaltiges Argument gegen das Eintragen gehört. Ich dagegen habe schon reichlich Argumente gehört. Sachen wie zumüllen, gehört nicht hierher, sind keine Fakten, ich habe kein Verständnis für oder kann sich ja noch ändern sind aus meiner Sicht keine guten Argumente. Besonders bei einem Projekt, das regelmäßig Hundekottütenspender und die Farbe von Parkbänken einträgt wundert mich die Einstellung aber geplante Autobahntrassen wollen wir hier nicht doch etwas. Sachen wie Hundekottütenspender sind doch vorhanden, ich meine als Objekt vor Ort. Ist mir unbegreiflich warum Dich die Einstellung von vielen verwundert, die eine Planung einer Straße die in 30 Jahren ganz anders gebaut wird nicht in OSM haben wollen. Gutes Beispiel ist die A33 bei Bielefeld. http://de.wikipedia.org/wiki/Bundesautobahn_33#Geschichte_und_Ausbau Planungen gab es 40 Jahre lang und jetzt erst ist der Bau begonnen worden. Der Bau wird in mehreren Abschnitten gemacht aber die Straße ist schon in OSM eingetragem weil es so gut wie feststeht das die Straße genau so gebaut wird. Das Geld ist bewilligt, die ersten Abschnitte werden gebaut. Das finde ich absolut ok aber eine Eintragung vor 5 Jahren (gut da gab es OSM so noch nicht) wo noch nichts feststand wäre falsch gewesen. Hilfreiche Diskussionen wie: Welche Planungsphasen gibt es eigentlich, in welcher Phase gibt es üblicherweise n Parallelpläne, wie gehen wir sinnvoll im Editor damit um, welche positiven/negativen Konsequenzen hat die Darstellung auf der Karte fehlen eigentlich völlig. Die vewrschiedenen Planungsphasen inbteressieren mich nicht. Planung fertig, Geld bewilligt, Gerichtsverfahren (die es leider mittlerweile zu fast 100% gibt) sind so gut wie durch und Baubeginn absehbar oder Bau wird begonbnen sind für mich ausschlaggebend. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geplante Straße bitte nicht rendern!
M∡rtin Koppenhoefer wrote: Wie schon gesagt, ich habe absolut kein Problem damit das man eine Straße in OSM einträgt die kurz vor dem Bau ist. man muss schon Hellseher sein, um das sicher vorsagen zu können. Höchstens kann man sagen, die Wahrscheinlichkeit ist hoch. Das hilft aber nur bedingt weiter, wenn die Mapper unter sich nicht einig sind in dieser Einschätzung. Am Bau der A33 (ja ich liebe das Beispiel) kann ich gut aufzeigen was ich meine. Der erste und zweote Abschnitt wird zur Zeit gebaut, beim dritten wird noch geklagt und das Planfeststellungsverfahren ist noch nicht abgeschlossen aber man kann relativ sicher sien das die Straße gebaut wird, eventuell mit leichten Korrekturen der Trasse. Bei der A30 gab es mehrere Trassen die diskutiert wurden. Da konnte man bis im Juli 2008 keine Trasse eintragen da es noch unsicher war wie gebaut wird. http://de.wikipedia.org/wiki/Bundesautobahn_30#Bau_der_Nordumgehung_von_Bad_Oeynhausen Was auch nicht eingetragen werden sollte ist z.b. der Ausbau der Ostwestfalenstraße http://de.wikipedia.org/wiki/Ostwestfalenstra%C3%9Fe Die Trasse ist nicht klar da es wieder klagen gibt (wie üblich) und es unklar ist ob dann noch Geld vorhanden ist- Natürlich können dann immer noch in letzter Sekunde Änderungen kommen wenn jemand sich z.b. vom Feldhamsterverleih ein paar Viecher ausleiht. Die verschiedenen Planungsphasen inbteressieren mich nicht. dann bist Du vermutlich völlig ungeeignet, geplante Straßen in OSM einschätzen zu können, weil die Wahrscheinlichkeit, mit der eine Straße gebaut wird, ja u.a. gerade davon abhängt, in welcher Phase man steckt. Die Planungsphasen interessieren mich nicht weil es tausende von Planungen gibt aber nur ein Bruchteil verwirklicht wird. Selbst wenn ein Planfeststellungsbeschluss vorliegt dann fehlt es oft an Geld. Planung fertig, Geld bewilligt, Gerichtsverfahren (die es leider mittlerweile zu fast 100% gibt) sind so gut wie durch und Baubeginn absehbar oder Bau wird begonbnen sind für mich ausschlaggebend. Die Planung ist dann fertig, wenn das Objekt eingeweiht wird ;-). Bau begonnen ist hingegen ein Grund, die Straße von highway=proposed in highway=construction zu ändern. Du hast das oder vergessen und es war auf das Beispiel A33 bezogen wo es 3 Abschnitte gibt aber erst bei 2 Abschnitten wurde mit dem Bau begonne. Durch den Baubeginn der ersten beiden Abschnitte ist es aber sehr wahrscheinlich geworden das der dritte auch gebaut wird. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benennung von Kernorten einer Gemeinde (boundary=administrative)
Georg Feddern wrote: Die Annahme, das sich der entsprechend zu rendernde Zusatz automatisch aus dem admin_level ergibt ist m. E. etwas blauäugig, wenn ich an die verschiedenen Gemeindenamen (Einheits, Samt und sonders) sowie die verschiedenen Kreisnamen denke. Es gibt bei einigen Relationen den Tag name:prefix=Gemeinde den ich sehr gut finde und der IMHO überall verwendet werden sollte. Sagst Du z.b. das Du nach Hamburg fährst oder fährst Du nach Freie und Hansestadt Hamburg ? Die Vorsätze Gemeinde, Hansestadt, Stadt werden praktisch im täglichen Leben nicht benutzt. Eine Außnahme ist oft Bad wie Bad Lippspringe, Bad Pyrmont Bedenke das der name Tag nicht nur das Rendering ändert sondern auch die Suche. Ich habe immer das Gefühl das viele hier nur auf den Renderer fixiert sind. Durch den Tag name:prefix wäre es für den Renderer leicht sich den Namen zusammenzusetzen wenn es denn gewollt ist. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benennung von Kernorten einer Gemeinde (boundary=administrative)
bundesrainer wrote: Im Falle von Landkreisen fände ich den Namen Landkreis XY trotz des Präfixes sinnvoll, denn so lautet die verbreitete Bezeichnung. Kann dann aber vom Renderer etc. bei vorhandenem name:prefix entschieden werden. Zusammensetzen ist leicht, Zerlegen schwer. Im allgemeinen wird bei den Kreisen der prefix Landkreis , Kreis mitbenutzt aber das ist nicht überall der Fall. Die Bezeichnung wird meistens nur dort benutzt wo eine verwechselungsgefahr besteht. Es gibt z.b. die Stadt Höxter und den Kreis Höxter. Bei Kreisfreien Städten hat die Relation den admin_level eines Kreises aber der prefix Kreis wird nicht benutzt. Dann gibt es noch Kreise die einen eindeutigen Namen haben, dort wird umgangssprachlich auch selten der name:prefix benutzt weil es auch so eindeutig ist. BeispielKreis Lippe Die Software kann mit dem name:prefix entscheiden ob der prefix benutzt wird oder nicht. So kann man z.b. bei 2 gleichen Namen den Prefix einblenden. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation 938868
Hi ! Die Relation 938868 is mir in Garys Relation check aufgefallen. Der Server weigert sich die Relation rauszurücken was wahrscheinlich an den 2700+ Membern liegt. Kann mir einer sagen um was es sich dabei handelt ? Der name Tag fehlt und land_area=administrative sagt mir nicht viel. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nationalpark eintragen
Steffen Heinz wrote: nicht? ich dachte Bing wäre erlaubt! Ich verwende ja Kartenmaterial nicht direkt durch kopieren z.b. ins Netz oder korrepondenz. Auf keinen Fall ! Du darfst weder von Yahoo noch von Bing Kartenmaterial benutzen ! Allerdings darfst Du von den Luftbildern der beiden Dienste abmalen, aber nur von den Luftbildern. Google Maps oder Google Earth darfst Du absolut nicht benutzen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] QA Tool gesucht
Hallo ! Ich habe bisher die Auswertung des Relationchecks von Gary benutzt um alle Relationsfehler in Deutschland zu beheben. Der Check hat als Liste alle Relationfehler von multipolygon/boundary/restriction Relation als praktische Liste ausgegeben mit einem Link für JOSM Remote. Also ähnlich wie der Area Check : http://www.gary68.de/osm/qa/some/ac_germany.htm Leider ist germany.osm mittlerweile so groß geworden das Garys Perl Tool aufgrund von OOM nicht mehr funktioniert. Kennt jemand einen Ersatz oder könnte hier aushelfen denn Fehler in den Relationen sind leider ziemlich häufig und gerade PLZ und Grenzrelationen werden immer wichtiger. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: Liste der bisherigen Zustimmungen veroeffentlicht
Frederik Ramm wrote: Das gefaehrlichste Problem in Sachen Lizenzwechsel sind diejenigen, die sich gegen den Wechsel stemmen, weil sie Datenverlust fuerchten (und nicht, weil sie gegen die Lizenz sind). Wenn es solche Leute *nicht* gaebe, dann koennte man ganz normal den Prozess fortsetzen, bis man eine bestimmte Zahl an Zustimmern hat - sagen wir 95% oder sowas - und dann sagen: Jetzt machen wir den Wechsel. Warum sind solche User gefährlich ? Ich würde zustimmen wenn ein gewisser Prozentsatz erreicht ist. 95% der Daten (Massenimports wie Tiger rausgerechnet) und ich wäre zufrieden da noch ein paar Punkte durch User wie mich hinzukommen würden. Das einzigste was ihr verliert ist die Möglichkeit die Schwelle des akzeptablen festzulegen und das es am Ende zu einen Lawineneffekt kommt. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: Liste der bisherigen Zustimmungen veroeffentlicht
Karl Eichwalder wrote: Ich würd einfach nix löschen. Bzw. erst dann, und nach prüfung, wenn sich jemand beschwert. Mit so einer Einstellung gefährdest Du OSM insgesamt, das ist Dir klar ? Es braucht sich keiner beschweren, er kann gleich eine Klage mit Schadensersatzforderung einreichen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Element-Historie.....
Jan Tappenbeck wrote: gibt es eine Möglichkeit irgendwie festzustellen wer das Element XYZ einmal erstellt hat ?? Bedingt denn beim splitten eines ways entsteht ein neuer und ein alter Teil. Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All In One - Flughafen Poi / airoway vs. amenity?
Hallo ! Das mit dem Punkt statt Flaeche auswerten finde ich eigentlich viel pfiffiger weil eben es auch durchaus mal Straßen geben koennte die am Flughafen auf der falschen Seite vorbeigehen. D.h. exakt die Position des Terminals mit einem Node zu markieren ist sicherlich pfiffig (Ich meine mein Festeinbau kennt bei den großen Flughaefen sogar die unterschiedlichen Terminals). Der Flughafen ist zum Teil nach http://wiki.openstreetmap.org/wiki/Airports getaggt. Warum findest Du den Punkt pfiffiger ? Einfach in der Airport-Fläche nach Terminals suchen und den Namen anzeigen lassen sollte doch nicht schwer sein. Dein Beispiel zeigt das Du nach dem Terminal des Flughafens suchen willst und nicht den Flughafen selber. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All In One - Flughafen Poi / airoway vs. amenity?
Florian Lohoff wrote: Das das Mathematisch nicht schwer ist mag ja sein - Welches Navi oder Konverter macht das und wo kann ich mir das ansehen? Keine Ahnung welches Navi das unterstützt aber das würde für mich zum normalen preprocessing der Daten gehören. Allerdings frage ich mich was für eine Rolle es spielt ob ein Navi das derzeitig unterstützt oder nicht. Dein Beispiel zeigt das Du nach dem Terminal des Flughafens suchen willst und nicht den Flughafen selber. Das Terminal ist auch nur ein POI. Sicher aber was sagt mir das jetzt ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Fläche =?iso -8859-1?q?umschlie=DFt?= Wald
M∡rtin Koppenhoefer wrote: da bist Du allerdings einer von Wenigen, ausser bei OSM habe ich es noch nirgendwo gesehen, dass Straßen dem landuse der angrenzenden Flächen einverleibt werden. Spielplätze sind dagegen (allgemein) anerkannter Teil eines Wohngebiets. M.E. hinkt Dein Vergleich daher etwas. Ich würde sagen das eher Du einer der enigen bist die immer alles zerschnippeln wollen. Eine allgemeine Straße ist nicht nur die eigentliche Teerfläche sondern auch Seitenstreifen und Schutzfläche an der Seite. +1 -1 Der von vielen praktizierte landuse=0 um die Straßen herum macht nicht wirklich Sinn. Landuse ist überall. nur weil manche auf der Straße wohnen, ist die Straße noch lange nicht landuse=residential. Oder anders gesagt (Du deutest es ja selbst schon oben an): nur weil es derzeit kein allgemein anerkanntes und dokumentiertes landuse=highway gibt, sollte man nicht einfach einen zufälligen anderen landuse setzen. Eine Straße ist auf jeden Fall Teil eines Wohngebietes oder auch Teil des Industriell geprägten Gebietes. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Parkplatz einzeln als Punkt (nicht Flaeche): Wie?
Hallo ! Ich plane Parkplätze als Punkte zu erfassen - zunächst in der Schweiz und angefangen mit Behinderten-Parkplätze. Ich möchte diese je einzeln als Punkte verwalten - und nicht als Flächen und auch nicht als Punkte, die für ein ganzes Parkplatzareal stehen (wie in http://wiki.openstreetmap.org/wiki/Parkplatz angegeben): Es sollte entweder Punkt oder eine Fläche vorhanden sein. Beides ist falsch weil es z.b. doppelt beim suchen auftauchen würde. Dazu kommt das eine Fläche höherwertiger ist als ein Punkt, also sind Flächen einzelnen Ounkten vorzuziehen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Name Tag im WIki
Hallo Im wiki gibt es eine Diskrepanz zwischen der englischen Beschreibung des Name Tags und der Deutschen. Im englischen: name=Channel Tunnel - Default name official_name=Principality of Andorra (where name is name=Andorra) weiter steht im Text : Name is the name only Some examples of incorrect usage: Manchester City (for a city named Manchester; note that New York City may be correct as the common name for The City of New York) Im deutschen wiki steht jedoch : name=Channel Tunnel Offizielle (amtliche) Bezeichnung und es gibt kein official_name Tag im Text. Was ist denn nun richtig ? Mir geht es im großen und ganzen um die Benennung der Grenzrelationen die kreuz und quer benannt sind. Bei Gemeinden/Städten/Hansestädten/whatever sollte IMO der Namenszusatz in den official_name Tag und die name Tag sollte nur den eigentlichen Ortsnamen enthalten. Bei den Kreisen und Regierungsbezirken bin ich jedoch der Auffassung das der Zusatz Teilk des Namens ist denn er wird zumindest hier in der Gegend benutzt um eine Verwechselung mit dem Stadtgebiet zu vermeiden. Bei den Stadtstaaten (Hamburg/Bremen/Berlin) sollte man so Bezeichnen wie die Städte (ohne Namenszusatz im name Tag). Was sind eure Meinungen dazu ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=living_street und maxspeed
M∡rtin Koppenhoefer wrote: Das ist der Geist, den einige hier kritisieren: in der (guten) Absicht, Ordnung zu schaffen, hat er massenhaft tags gelöscht, wie die BB aussieht z.T. auch im Ausland. M.E. sind für viele Tools maxspeed Angaben zwischen 1 und 14 hilfreicher als überhaupt keine Daten. Nach meiner Meinung ist das eine Fehlerkorrektur wenn nur die maxspeed Werte von 1-15km/h entfernt werden. Auch wenn Du es 1000x wiederholst das Du solche Werte für gut findest, es wird nicht richtiger. Absichtlich Fehler in die Karte einzubauen für Anwendung X ist gegen die OSM Regel Wir mappen nicht für X und das ist ein allgemeiner Konsenz. Ein revert anderer Änderungen (außerhalb von D oder von anderen Werten) befürworte ich jedoch. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=living_street und maxspeed
Tom Müller wrote: Das entspricht absolute meiner Meinung. Zumal es die Daten nach meinem Erachten verlässlicher macht. Wenn man durch ein falsches highway=living_street-Tag gleich auch noch maxspeed falsch setzt, werden die Daten schneller unbrauchbar ... Ein highway=living_street mit maxspeed=30 stellt m.M.n. eine 30er Zone immernoch erträglich dar ... Wenn man nun alle maxspeeds rauslöscht wird plötzlich eine Spielstraße draus ... Wenn vorher living_street und ein Tempo 30 gesetzt sind dann ist das sicherste dsa Tempo 30 zu löschen. Sicher von sicher in der Anwendung. Ein note mit maxpeed/Einstufung prüfen wäre allerdings nicht unbedingt verkehrt. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=living_street und maxspeed
M∡rtin Koppenhoefer wrote: einen vorhätte, dann würde ich hier garantiert nicht nachfragen. damit stellst Du Dich bewusst gegen die Community und ihre Regeln. Die sehen nämlich genau das vor: dass man automatisierte Edits vorher ankündigt. Ich hoffe, Du überlegst Dir nochmal, was Du da geschrieben hast. Man beachte das *hier* denn es gibt in OSM noch andere Kommunikationskanäle (1) denn egal was man macht, *hier* wird man garantiert keinen Konsenz finden. Selbst xybots änderungen erzielen hier keinen Konsenz obwohl die schon lange laufen. Matthias 1: Mailingliste, Forum, Blog, IRC, wiki(?) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=living_street und maxspeed
Frederik Ramm wrote: gibt es hier einen Konsens darueber, dass bei highway=living_street ein maxspeed ueberfluessig ist? Hier hat jemand bei 5620 solchen Strassen das maxspeed entfernt: http://www.openstreetmap.org/browse/changeset/5765845 Ich finde das an sich ok. Eine direkte Geschwindigkeitsbegrenzung in km/h gibt es nicht sondern nur die Anweisung Schritttempo - http://de.wikipedia.org/wiki/Schritttempo Der Begriff Schrittgeschwindigkeit ist in der Rechtsprechung nicht genau definiert. Sie liegt nach Urteilen verschiedener deutscher Obergerichte zwischen 4 und 10 km/h. Der deutsche Bundesgerichtshof spricht davon, dass sie „deutlich unter 20 km/h“ liegen muss. Eine Angabe in km/h ist somit nicht korrekt und außerdem wird Schritttempo schon durch living_street vorgegeben. Eine zusätzliche Angabe ist Datenballast wie ein oneway=yes bei einem roundabout. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=living_street und maxspeed
Wolfgang wrote: Es häufen sich im Moment leider die Massenedits, einige Mapper scheinen hier das Motto Mein Feld ist die Welt übernommen zu haben. Hast Du Dir die Edits des Users (auch außerthalb des Massenedits) mal angeschaut oder bist Du grundsätzlich dagegen ? Es wäre schön, wenn sich diese Edits auf offensichtliche Schreibfehler in tags beschränken würden und für andere Fernaktionen die osb benutzt würde, denn dafür ist sie eigentlich da. Solange so ein Edit absolut Sinn macht, solange kann ma nnichts dagegen sagen. Der User kümmert sich anscheinend um maxspeeds und ich bin froh wenn sich jemand in einem Bereich engagiert. Will man nämlich gewisse Sachen bundesweit vernünftig auserten so muss das tagging auch einigermaßen Konsistent sein. Matthiuas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=living_street und maxspeed
M∡rtin Koppenhoefer wrote: soweit ich weiss, sind Implikationen und Defaults bei OSM sowieso nicht etabliert, im Zweifel setzt man lieber mal einen Tag zuviel. Schädlich finde ich die Maxspeed-Tags nicht. Ich halte auch einen expliziten maxspeed-Wert wie z.B. 7 für sinnvoll, auch wenn das rechtlich nicht dem Wortlaut des Gesetzes entspricht. Man kann ja ggf. mit maxspeed:source=DE:walk erläutern, was eigentlich gemeint ist. Praktische Auswirkungen hat ein expliziter Wert m.E. nicht, zumindest keine negativen. Eine absolute Geschwindigkeitsangabe hat negative Auswirkungen. a) unnötiger Datenballast b) was gilt nun, Schrittgeschwindigkeit oder der angegebene Wert ? Entgegengesetzte Angaben können irreführend sein c) Eine Geschwindigkeitsangabe in km/h ist eine falsche Angabe und kann somit bedenkenlos gelöscht werden. Implikationen sind sehr wohl bei OSM etabliert, Beispiel:junction=roundabout und oneway=yes Ich bin ach einer der bei einen automatischen Massedit schreit aber man sollte nicht woirklich alles zerreden. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=living_street und maxspeed
M∡rtin Koppenhoefer wrote: das gilt nur, wenn man die Implikation für gegeben hält. DIe implikation ist ja auch gegeben (walk speed) b) was gilt nun, Schrittgeschwindigkeit oder der angegebene Wert ? Entgegengesetzte Angaben können irreführend sein ist ja nicht irreführend sondern dokumentiert: source:maxspeed=walk bedeutet genau Schrittgeschwindigkeit. Der numerische Wert, der ungefähr Schrittgeschwindigkeit eines Autos ist, erleichtert vielen Anwendungen und Anwendern die Arbeit. Ein geschätzten Richtwert wie 7km/h brauchen nur die Autofahrer. Eine Anwendung braucht eh pro Land einen Datensatz der allgemeinen Regeln wie maxspeed auf Landstraßen, Autobahnen, eventuell rechts oder linksverkehr... Vielleicht gibt es aber Länder in denen in einer licing_street andere Geschwindigkeiten als walk speed per Zeichen angeordnet werden können und dann würde bei normalen living_streets solche Werte stören. c) Eine Geschwindigkeitsangabe in km/h ist eine falsche Angabe und kann somit bedenkenlos gelöscht werden. s. b) zum Thema falsch. Zur These kann bedenkenlos gelöscht werden: genau das sollte man nicht tun, wenn es ein Thema ohne allgemeinen Konsens ist. So ganz einfach (und schnell) ist die Auswertung nach Ländern nicht, und in allen Ländern ausser Deutschland gilt meines Wissens ein höheres Limit als Schrittgeschwindigkeit, d.h. die einfacheren Anwendungen werden vermutlich 20 oder sowas annehmen, und liegen damit im Vergleich mit 7 ziemlich mehr daneben in D. Es gibt weder in Deutschland noch in den vielen anderen Ländern eine eundeutige Geschwindigkeit ! - http://en.wikipedia.org/wiki/Living_street Mit unter 20km/h liegt man nicht daneben in D, siehe Wikiartikel über Schrittempo und Meinung des Bundesgerichtshofs. Eine vorgegebene Geschwindigkeit wie 6km/h ist eindeutig Datenmüll. Du forderst einen allgemeinen Konsenz ? Einen Konsenz aller OSM User ? Dann können wir OSM dicht machen denn sowas wird es bei der Menge der Mapper nicht geben, Ich bin froh das einer sich die Arbeit macht wenn auch nicht fehlerfrei aber Fehler passieren selbst beim normalen Mappen oft genug. Das Zeit ist wesentlich besser investiert als in der Mailingliste alles zu tode zu diskutieren. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=living_street und maxspeed
Garry wrote: Eine absolute Geschwindigkeitsangabe hat negative Auswirkungen. a) unnötiger Datenballast Da findest Du sicher einiges in OSM was nach dieser Sichtweise unnötiger Datenbalast ist Stimmt aber was hat denn das jetzt damit zu tun ? Wenn ich irgendwo editiere dann entferne ich auch ggf. layer=0, oneway=yes/junction=roundabout oder zusätzliche amenity=parking Nodes in Parkplatzfächen. Ich lösche auch Multipolygon Relationen mit nur 1 inner Member und ohne outer Member und wo auch keine Fläche außerhalb existiert. Jehova - Jetzt darfst Du mich steinigen b) was gilt nun, Schrittgeschwindigkeit oder der angegebene Wert ? Entgegengesetzte Angaben können irreführend sein Solang sich der explizit Wert innerhalb der jeweiligen Rechtsprechung befindet - wo soll da bitte die ach so negative Auswirkung sein? Der Wert ist unnötig und kann entfernt werden., Es gibt keinen Grund in so einem Fall einen Wert einzutragen der in der STVO nicht vorgegeben ist. Natürlich kann den von mir aus jemand eintragen aber der darf sich nicht beschweren wenn jemand anderes den weider entfernt. c) Eine Geschwindigkeitsangabe in km/h ist eine falsche Angabe und kann somit bedenkenlos gelöscht werden. Km/h ist die gültige Einheit für eine Geschwindigkeitsangabe und mit dieser wird berechnet ob Du einen Geschwindigkeitsverstoss begangen hast oder nicht. Es ist aber keine in km/h Geschwindigkeitsangabe in der STVO vorgegeben sondern nur ein schwammiger Geschwindigkeitsbereich. Berechnen lässt sich da nichts denn die Geschwindigkeit wird von den Gerichten mal so und mal so als zulässig/nicht zulässig angesehen. Matthias PS: Ich habe noch nie einen automatischen Edit gemacht bis auf 5(?) reverts auf Anfrage und nach Begutachtung aber wenn ich unwahrscheinlichwerweise einen vorhätte, dann würde ich hier garantiert nicht nachfragen. Da kann man eher versuchen im Bundestag durch Diskussionen eine Diätensenkung zu erreichen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Changeset 5710460 zurücknehmen: wie ?
Heinz Münninghoff wrote: habe hier in Recklinghausen ein Problem entdeckt bei dem einiges durcheinander geraten ist. es geht um das Changeset: http://www.openstreetmap.org/browse/changeset/5710460 5710460 von WerWil http://www.openstreetmap.org/user/WerWil . Icvh habe es mal reverted, einen Konflikt habe ich mit Potlatch manuell behoben. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hamburg, Im Ginsterbusch 8a
Wolfgang wrote: neben dem place=region Node scheint es noch einen place=city oder so zu geben mit dem Namen Hamburg ohne das freie und Hansestadt Gedöhns : http://www.openstreetmap.org/?lat=53.543lon=10.025zoom=11layers=M Müsste man sich den Nominatim Algorithmus mal anschauen, wieso er den nicht heranzieht. In den addr:city Nodes in dem Gebiet ist auch nur Hamburg eingetragen. Da ist der Nominatim also noch verbesserungswürdig. Bei dem Stichwort Gedöhns fällt mir etwas auf: Was an unseren Adressdaten noch fehlt, ist das Bundesland. Wenn man das eintragen könnte und jemand auf die Idee käme, wie Garmin die Bundesländer aus den Daten liest, wäre das Problem der Adresssuche auf den Garmin-Geräten erledigt. Der place Nodes ist eigentlich nur für die passende Anzeige des Names auf der Karte zuständig. Es kann keine Aussage getrpffen werden welches Gebiet mit diesem Node gemeint ist. Wo eine Objekt liegt kann man an den umliegenden Grenzrelationen feststellen. Es gab auch mal auf dem dev Server so eine Anwendung die genau das angezeigt haz aber leider finde ich die nicht mehr wieder. Das Bundesland fehlt auch nicht, die Bundesländer sind schon vorhanden als Grenzrelationen. Das hier ist das Beispiel für Hamburg http://www.openstreetmap.org/browse/relation/62782 Ich bin am überlegen ob es nicht Sinnvoll ist die Titel wie Gemeinde, Stadt, Hansestadt etc entweder in ein eigenes Tag auszulagern oder es z.b. in so einer Form abzuändern Hamburg, Freie und Hansestadt Nomantin benutzt diese Grenzen im übrigen schon wie man am Beispiel Am Siek, Steinheim sehen kann. Ortsgebiet Am Siek, Vinsebeck, Steinheim, Höxter, Regierungsbezirk Detmold, Nordrhein-Westfalen, Germany Hier fallen aber 3 Sachen auf: a) fehlerhafte übersetzung von residential highway in Ortsgebiet. Wer könnte das korrigieren ? b) wieso zeigt er bei NRW den Deutschen Namen an aber benutzt dann Germany ? c) wenn Nominatim nicht so pingelig wäre dann wäre eine Suche nach Straßen in der Stadt Detmold fast unmöglich weil er dann wahrscheinlich alle Straßen in Regierungsbezirk auswerten würde. Wenn der Kreis Lippe nun aber auch Kreis Detmold heißen würde, dann hätten wir noch eine Ebene mit gleichen Namen. Ich frage mich wie man das Lösen kann. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Peter Wendorff wrote: Die OSM-Welt koennte so schoen einfach sein, wenn man sie denn nur liesse und nicht auf Krampf jeden Grashalm einzel eintragen wuerde. Die OSM-Welt kann sich auf eine Straßenkarte beschränken und entsprechend Scheuklappen aufziehen, oder eben gerade jeden für irgendjemanden interessanten Grashalm eintragen. Das macht sie so enorm wertvoll. Es kann OSM aber auch sehr leicht unbrauchbar machen für den durchschnittlichen Mapper. Manche schieben für eine Diplomarbeit irgendein Kram in die DB das normale Mapper verwirrt und sogar das mappen quasi unmöglich macht. Nach der Diplomarbeit geht auch das Interesse desjenigen verloren und nach 1-2 Jahren sind nur noch unbrauchbare Reste vorhanden. BTW: Ein Bürgersteig ist Teil der Straße solange nicht baulich getrennt und sollte ebenso wie ein Radweg (cycleway=*) nicht extra eingetragen werden. Benutzt Du das sidewalk tag dafür ? Ich wünsche mir echt verschiedene Layers in der DB. Dann kann auch jemand Flugrouten in einem eigenen Layer einbauen wenn er es unbedingt wünscht. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Querung über Spielstraße
Peter Wendorff wrote: Wie sollte man dann an einer Kreuzung die 4 (möglicherweise unterschiedlich ausgestatteten Fußgängerampeln taggen? Eine normale Straßenkreuzung sind 2 kreuzende ways mit einem Verbindungsnode in der Mitte. Dieser Node bekommt dann ein highway=traffic_signals Tag. siehe auch http://wiki.openstreetmap.org/wiki/Traffic_lights Die Ansage für Gerade Dein Beispiel mit der Spielstraße zeigt das der Ansatz der Fußgängernavigation die anscheinend metergenau erfolgen soll mit Vektoren nicht vernünftig umsetzbar ist.Als Fußgänger kann man quasi fast überall langlaufen.Dir ist auch hoffentlich bewusst das in Straßenschluchten die normale GPS genauigkeit von nur 7m+ noch wesentlich schlechter werden kann durch Reflektionen ? Selbst der Ansatz der Erfassung der Straße als Fläche würde hier nicht helfen wenn ich das richtig sehe. Du darfst nicht vergessen das solche Daten auch immer gewartet werden müssen und das von Mappern die das erst 3 Monate machen und Potlatch benutzen denn der typische OSM Mapper ist AFAIK nur 3 Monate dabei. Die Wartung der Daten wird in naher Zukunft auch immer wichtiger werden und das ergibt dann irgendwann ein Motivationsproblem denn neue Straßen erfassen macht immer mehr Spaß als an alten herumzubasteln. Deswegen mag ich es nicht das irgendjemand für sein tolles Studienprojekt, Diplomarbeit oder sonstwas einfach Daten in die DB kippen will um die sich dann später keiner mehr kümmert. Ob das bei Dir der Fall ist weiß ich nicht ganz genau aber es hört sich danach an. Dabei habe ich immer eine breite Fußgängerzone im Hinterkopf wo x virtuelle Fußgängerways eingetragen werden. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Frederik Ramm wrote: Matthias Versen wrote: a) Neue Edits werden nur angenommen wenn der User beiden Lizenzen zustimmt. Dann werden 2-3 Jahre abgewartet was dafür sorgt das durch neue Änderungen viele der alten Daten in die neue Lizenz übergehen. Das Problem ist, dass genau dies nicht passiert; wenn Du einen Node gesetzt hast, aber der neuen Lizenz nicht zustimmst, dann kann der Node in den 2-3 Jahren 10x geaendert werden, aber geht damit nicht in die neue Lizenz ueber. Es ist allerdings noch schlimmer. Wenn ich (als Beispiel) wegen dem anlegen einer Relation eine Straße splitte, dann tauche ich als Uhrheber von eimem der beiden ways auf ohne das ich allerdings das Uhrheberrecht habe. Wie will die geheiligte Führung mit dem geplanten Wechsel nicht gegen die eigene Lizenz verstoßen wenn die nichtmal auseinanderhalten können von wem ein Objekt erstellt worden ist ? Ich bin nicht gegen die Lizenz aber gegen das vorschnelle löschen. Neue Daten zwangsweise nur mit zustimmung von beiden Lizenzen annehmen ist ok, mit dem Wechsel kann man sich dann aber Zeit lassen. Ich werde einfach das Gefühl nicht los das gewisse kommerzielle Interessen dahinterstehen. Wenn ich schon diese dämliche Meldung über 40% der User mit 90% der Daten lese dann wird mir ganz anders. Man sollte die Massenimporte von den 90% der Daten abziehen und dann die Menge der Daten nennen. Das sind die Daten die wirklich Arbeit gemacht haben. Ohne Tiger und AND Importe dürfte das schon ganz anders aussehen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 1 Jahr Lähmung von OSM durch Lizenzwechs el?
Michael Kugelmann wrote: Wir diskutieren bereits jetzt VIEL zu lange an dem Thema herum weil man versucht hat es Allen recht zu machen. Aber es wird immer schlimmer = je früher der Wechsel erfolgt desto besser. Die Lizenzumstellung absagen und schon würde die Diskussion aufhören. Bei den rechtlichen Problemen sage ich nur : na und ? Ich bin zwischenzeitlich von dem Gejammer von ein paar Leuten extremst genervt. Wir verschwenden viel zu viel Energie auf diese nutzlose Diskussion. Zur Befüllung der entstehnden Lücken wäre diese Energie weitaus besser angewendet. Warum sinnlos Energie in Daten stecken die wir schon haben ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ideen Sammel, und organisieren eines CCBYSA 2.0 Forks
Frederik Ramm wrote: Zunaechst einmal ist eins klar: Je mehr Leute zustimmen, desto weniger Probleme gibt es. Es ist davon auszugehen, dass die meisten Mapper, die wir erreichen, auch zustimmen werden - die Neinsager sind nicht viele, nur laut. Das Problem koennte aber durchaus das Erreichen sein - das Projekt hat nun auch in Deutchland schon gute fuenf Jahre auf dem Buckel, und viele kriegen wir vielleicht wirklich gar nicht mehr zu fassen. Das koennte richtig Arbeit werden. Es wird mit etwas Pech mehr als richtig Arbeit geben und das wird zusätzlich noch reichlich Mapper frustrieren die dann keine Lust mehr haben weiterzumachen. Ich frage mich warum plötzlich so ein Druck gemacht wird mit der Lizenz. Es gäbe 2 alternativen die wahrscheinlich besser wären. a) Neue Edits werden nur angenommen wenn der User beiden Lizenzen zustimmt. Dann werden 2-3 Jahre abgewartet was dafür sorgt das durch neue Änderungen viele der alten Daten in die neue Lizenz übergehen. OSM hat schon 5 Jahre die alte Lizenz benutzt, da stören dann 2-3 weitere Jahre auch nicht mehr oder machen die Geldmacher von den Wolkenmachern druck ? b) Es wird immer gesagt das die alte Lizenz keinen Schutz bietet und die Daten deswegen in manchen Ländern unter PD stehen. Wenn die unter PD stehen, warum übernimmt man dann nicht einfach die Daten komplett ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen Ungarn
Thomas Steiner wrote: Hi, ich bin auf der Suche nach einer Karte mit den Gemeindegrenzen und den Grenzen der Kleingebiete und Komitate in Westungarn. Im speziellen interessieren mich die Grenzgemeinden an den Bezirk Güssing in Österreich. Wo finde ich so eine Karte, in den Rohdaten sehe ich das nicht, aber ev bin ich einfach nur ungeschickt. Es sind z.b. noch nichtmal alle deutschen Gemeindegrenzen vorhanden. Ich glaube nicht das die Gemeindegrenzen existieren außer wenn Ungarn keinen import hatte. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreckgespenst Datenverlust
Dirk-Lüder Kreie wrote: - PD/CC0 ist die bessere Lizenz für OSM Für mich ist die neue Lizenz nicht unbedingt bessser aber auch nicht schlechter. - Die Menge der nicht portierbaren Daten wird IMO verschmerzbar sein Jeder verlorene Node ist ein Node zuviel. Ich finde Deine Haltung mehr als nur arrogant wenn Du nicht weißt wieviel verloren geht weil Du offensichtlich zustimmst und bei Dir in der Gegend dadurch kaum Verlust auftreten wird. Dabei ignorierst Du aber die ganzen anderen Bereiche in denen vielleicht sher viel verloren geht. - selbst Datenverlust ist verschmerzbar s.o. - gekränkte Mapper werden durch motivierte ersetzt, wer will schon, dass seine Stadt/Dorf/Straße nur deshalb nicht in der aktuellen OSM-Karte ist, weil ein Mapper schmollt? Wieso ist jemand gekränkt nur weil er der neuen Lizenz nicht zustimmen will ? Das ist eine absolut arrogante Einstellung Der derzeitige Lizenzstand ist nicht hinnehmbar[1], und alle Möglichkeiten, daran was zu ändern, haben automatisch einen Verlust von nicht unter der neuen Lizenz nutzbaren Daten zur Folge. Das ist unausweichlich. Deshalb die ODbL abzulehnen, aus dem einzigen Grund, dass dadurch für ein unter ODbL lizenziertes OSM nicht mehr alle alten Daten zur Verfügung stehen, ist IMNSHO unverantwortlich und projektschädigend. Die 100%-Lösung kann es nicht geben. verlorene Daten sind verschmerzbar Vergrätze Mapper sind ersetzbar, oder re-motivierbar, sobald die Unausweichlichkeit der Nichtrelizenzierbarkeit der Daten und gleichzeitig die Heilungsmöglichkeiten für Lücken offenbar geworden sind. Die Nachteile der alten Lizenz sind nach meiner Meinung eher hinnehmbar als verlorene Daten. Wer also die ODbL als die Ursache von Datenverlust anprangert schadet grob Fahrlässig dem Projekt, durch Fehldarstellung der Tatsachen und aktive miese Stimmungsmache. Leute die die neue Lizenz offensichtlich durchdrücken wollen schaden dem Projekt mehr als die alte Lizenz. Deine fehldarstellungen in Deinem Posting halte ich nicht nur für fahrlässig sondern auch arrogant. Matthias PS: Ich werde wegem dem Datenverlust nicht zustimmen und dadurch noch mehr Datenverlust erzeugen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stats OSM Routing View 2010-07
steffterra wrote: Darf ich fragen was da in Hessen passiert ist? Von einem Monat (11.06.10) auf den anderen (17.07.10) wurden die Fehler um fast die Hälfte reduziert? Und davor (10.05.10) waren sie sogar weniger als am 17.07.10? Wurde da großflächig gepfuscht und dann kurz darauf alles auf einen Schlag wieder Rückgängig gemacht? Ich glaube es handelt sich dabei um die Aktion Oberförster. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (J)OSM Flickr
Alexander Menk wrote: ladet ihr eigentlich euere Bilder vom Mapping auf Flickr hoch? Wozu ? Für Bilder von Straßenschildern und Verkehrszeichen interessiert sich keiner. Man kann das Web2.0 gedöns auch übertreiben. Wenn sich beim mappen mal schöne Bilder ergeben, dann kann man die einzelnd hochladen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM 3329 ÖPNV
Hallo ! habe gerade die neuste Version vom JOSM heruntergeladen (3329). Nun hab ich ein paar Haltestellen eingezeichnet und diese in Relationen eingefügt. Nun 'meckert' JOSM bzw. Validator. Element für Rolleleer hat den falschen Typ Im Moment ist die Rolle tatsächlich leer. Nur was soll da nun rein? Du hast vergessen zu erwähnen was für einen Typ von Relation du benutzt. Verschiedene Typen von Relationen haben verschiedene Rollen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Validator-Meldung bei Grenzrelation
Bodo Meissner wrote: (Auf der englischen Wiki-Seite[1] steht allerdings inzwischen, man soll auch bei boundary-Relationen 'outer' verwenden..) Danke. Das könnte die Erklärung für die Validator-Meldung (in josm-latest von gestern) sein. Dann werde ich mal role=outer ergänzen. Dann tagge die auch gleich als multipolygon um wie es im gleichen Wiki Artikel steht (Deutschland verwendet multipöolygon) Ich frage mich wer da dauernd die tagging Regeln für die Grenzen im Wiki ändert. Ein type=boundary mit multipolygon Regeln ist erst recht bullshit. Vielleicht sollte ich mir mal ganz neue tagging Regeln ausdenken und das wiki umschreiben. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Irre viele Grenzen auf einen Haufen
Christian Knorr wrote: Hallo zusammen, habe gerade zufällig das hier gefunden [1]: grob geschätzt 20 Grenzen (NL, BE, ...), teils verschachtelt. Weiß Jemand ob das so richtig ist? Sieht mir nicht so aus, aber da bin ich nicht ortskundig. Das ist dieses Changeset [2]. Den User Ldp kenne ich nicht und er scheint aus NL zu stammen, zumindest klingt es holländisch was er schreibt. http://de.wikipedia.org/wiki/Baarle Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grenze DE-AT durchlöchert
Tirkon wrote: es wäre vielleicht hilfreich, wenn man diese proposed-Relation im Wiki erläutert. Mir ist nicht klar und ich vermisse daher Angaben dazu, warum das Segment einer Grenze eine Relation sein !!muss!! und ein Weg nicht ausreicht: http://wiki.openstreetmap.org/wiki/Relations/Proposed/boundary_segment Mir ist nicht ganz klar wie das mit einem Weg funktionieren soll ! Stichwort: Jede kleiner Grenze wie z.b. eine Gemeindegrenze sorgt dafür das der way gesplittet werden muss., Ein Grenzsegment Deutschland-Österreich kann deshalb niemals aus nur einem way bestehen außer man erstellt unnötigerweise einen eigenen Way dafür. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grenze DE-AT durchlöchert
Andreas Labres wrote: Ich würde um mehr Sorgfalt bitten, wenn man insbesondere internationale Grenz-Ways zerteilt! Das betrifft alle Grenzways, der Schaden wir nur größer je höherwertiger die Grenze ist. Diese Relationhttp://www.openstreetmap.org/browse/relation/17511 ist immer noch durchlöchert, es waren/sind(?) aber auch div. Multipolygone von österr. Bezirken und Gemeinden zerstört. :( Das passiert eihentlich auf Deutscher Seite jede Woche einige Male. Ausgelöst durech eine JOSM fehlbedienung vor die JOSM nicht warnt. Irgendwie macht's keinem Spaß, den Fehlern anderer hinterherzuarbeiten... Ich verstehe das, ich repariere innerhalb von .de die Grenzen alle 1-2 Wochen. Zum Glück gibt es noch andere die dabei helfen denn sonst wäre es nicht mehr zu schaffen die Fehler zu korrigieren. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenze Groß Grönau
Jan Tappenbeck wrote: Moin ! kennt sich einer von Euch in Groß Grönau aus? Für die Straßengrenze würde ich gerne die Ortsgrenze einzeichnen. Im Norden Lübeck und im Osten die Landesgrenze. Hilft Dir http://de.wikipedia.org/wiki/Datei:Groß_Grönau_in_RZ.svg etwas ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Christian Knorr wrote: o Firefox Firefox 3.0.19 weiß nicht, was er beim Klick auf josm machen soll, da er das Protokoll osm:// nicht kennt. Kann ich es ihm beibringen? Ich kenn' das nur mit http://localhost:port (Port weiß ich gerade nicht). Klar, JOSM muss dazu laufen und das tut er auch. Firefox fragt in der Regel das OS was es damit machen soll. siehe http://kb.mozillazine.org/Register_protocol Matthias PS: Kenne aber auch nur die localhost Variante ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO keine Adressen mehr
Walter Nordmann wrote: NKIN Nein zu der Absicht oder ob Du es bestätigen kannst ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Widemann System Hamburg - Stadtgrenze Schleswig / Schlei
Jan Tappenbeck wrote: Das Ufer ist als Relation vom Type NATURAL angelegt. Kann ich das jetzt einfach aufbrechen um den Abschnitt des Ways auch in die Grenze einzubinden. Wenn ich das mache verschwindet in meinem JOSM die Flächendarstellung. Der See ist nicht als Relation sondern als Area vorhanden. Wenn Du die Fläöche aufbrichst dann ist die Fläche kaputt weil nicht mehr in sich geschlossen. JOSM zeigt das damit an das die Fläche nicht mehr ausgefüllt wird. (btw; Danke für dieses Feature !) Du solltest die Grenzlinie IMO nicht mit anderen physisch vorhanden zusammenpacken Der See kann kleiner/größer werden, die Grenze bleibt aber normalerweise dort. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassen.NRW Layer
Frederik Ramm wrote: Wir haben von Strassen.NRW nur einmalig Daten bekommen, das ist also deren alter Stand. Ich kann mal nachfragen, ob es Updates gibt, aber ich denke fast, inzwischen sollten unsere Daten so gut sein, dass wir da kein grosses Interesse mehr haben, oder doch? Die Daten sind sehr interessant ! Es wurden als Beispiel in Lemgo und Detmold einige Bundes- und Landstraßen umgelegt. Innerhalb einer Stadt ist es schwierig dem Verlauf zu folgen und da sind solche Daten sehr hilfreich. Das Updaten der OSM Daten ist eine sehr große herrausforderung und oft werden solche Änderungen erst nach Jahren in OSM erkannt und eingetragen. Da hilft der WMS Layer schon ziemlich ! Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wirtschaftswege, die nur für bestimm te Fahrzeuge zulässig sind
Falk Zscheile wrote: Es ist Dir ein leichtes den Beweis zu führen. Bitte nenne uns ein Bundesland, in welchem die Waldwege nicht für den öffentlichen KFZ-Verkehr gesperrt sind. Bis dahin stelle bitte keine solche Behauptungen auf. Wie wäre es wenn Du uns den Beweis zeigst das Deine Argumente stützt ? Laut http://de.wikipedia.org/wiki/Wirtschaftsweg dürfte Dir das nur für Baden-Würtenberg gelingen. Bis zum Beweis des Gegenteils: In allen Bundesländern sind Waldwege für den öffentlichen KFZ-Verkehr gesperrt. Waldwege bedürfen also keines zusätzlichen access-Tags. Bis zum beweis des Gegenteils sind alle Waldwege bis auf BW für alle KFZ frei zugänglich solange nicht anders ausgeschildert. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu way id=32476642
Daniela Duerbeck wrote: Hi! Ich verstehe den Sinn dieser Area nicht. Drumrum ist auch Wald, aber hier ist der Wald mit Area=Yes getagged. Versteht das wer und kann es mir erklären? Der Wald wurde aus einzelnen Stücken wie diesem Way in einer Relation umgestaltet. Allerdings ist area=yes falsch und zweitens dürfen flächentags wie landuse nicht auf die einzelnen ways weil die ways nicht in sich geschlossen sind. Die Area Tags müssen bei solchen erweiterten Multipolygonen auf jeden Fall als Tag in die Relation. Ich habe das mal kurz umgebaut :-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderung der Landes-/Gemeindegrenze B W/BY
Sven Anders wrote: oder ob ich das selbst machen kann. Das ganze ist ja nicht unkritisch, da die betroffenen Teilstücke zu einer Vielzahl von Relationen gehören. Wenn Du es dir zutraust ist das das beste. Natürlich ist das nicht trivial, deshalb gibt es ja auch nur so wenige, die es machen. Ich würde mir SEHR wünschen das sich mehr da ran trauen!! Dieser Fall dürfte nicht so schwer sein weil man die Grenze nicht auftrennen oder die Relationen selber ändern muss sondern man muss nur die Grenzwege verschieben. Und Kritisch ist das ganze IMHO überhaupt nicht, wir haben soviele kaputte Grenzen in der DB und trotzdem stört sich kaum einer daran. Kaputte Grenzen sollte es eigentlich kaum geben denn die repariere ich jede Woche (bis auf Ausnahmen wie Stadtteilgrenzen die auf Straßen verlaufen). Oder meinst Du einen nicht korrekten Verlauf ? Das kann ich schlecht beurteilen... Dann gibt es noch nicht komplette Gemeindegrenzen aber das ist ein andere Fall. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderung der Landes-/Gemeindegrenze B W/BY
Sven Anders wrote: Ich wollte dir nicht auf die Füße treten. Gut dann gibt es keine kaputten Grenzen mehr. Das habe ich so nicht gesagt, aber das trotzdem stört sich kaum einer daran wollte ich etwas richtigstellen :-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
Hallo Frederik ich mache mir Sorgen, wenn ich die Wikipedia betrachte. Trotz allem, was die Wikipedia erreicht hat, ist das kein Projekt mehr, dass ich irgendwie sympathisch finde. Das Projekt macht auf mich den Eindruck, als ob es langsam an Buerokratie zu Grunde geht. Die Dynamik und der freie Geist, den das Projekt frueher hatte, werden erstickt in Regeln, Rechten, Hierarchien. Ich denke das dies eine Folge des Wachstums ist. Am Anfang von Wikipedia war die Form eines Artikels egal, man war froh um jeden Inhalt der erstellt wurde. Mittlerweile ist Wikipedia die einzig verbliebende Enzyklopädie. Dadurch ist der Anspruch an die Qualität extrem gestiegen und die Bedingungen eines guten Artikels werden zwangsweise durch Regeln definiert. Das sorgt einerseits für eine gewisse Qualität aber andererseits auch dafür, das es Einsteigern viel schwerer gemacht wird neue Inhalte zu erstellen. Das Projekt hat sich bedingt durch das Wachstum geändert und das ist bei sehr vielen Projekten der Fall weil es einfach nicht anders geht. Auf einzelne User kann man da immer weniger Rücksicht nehmen und die freiheiten in dem Projekt werden zwangsweise beschnitten. Ich habe sowas übrigens in abwandelter Form auch bei Mozilla miterlebt und in OSM wird etwas ähnliches passieren außer das Projekt setzte sich nicht durch. Man muss versuchen das beste daraus zu machen. faellt. Altgediente Wikipedia-Mitarbeiter wenden sich ab; Leute, die Jahre ihres Lebens wirklich mit dem Herzen am Projekt hingen, sind verbittert und enttaeuscht. Es bildet sich eine Clique, ein innerer Kreis. Das ist eine Folge der Änderung des Projektes durch das Wachstum. Die Regeln sind eine Folge des Wachstums weil dadurch die Leute sich immer mehr auf die Füße getreten haben was in unendlich langen Diskussionen endet. Ich denke die meisten werden mitbekommen haben das sich gewisse Diskussionen einfach nicht lösen lassen weil am Ende keiner mehr nachgeben will. Der Spiegel Artikel zeigt so ein extremes Beispiel. Es ist auch denkbar, dass es ab einer gewissen Projekt-Groesse einfach gar nicht mehr anders geht; eventuell ist nur 10% der Arbeit kommen dem Projekt zugute vielleicht wirklich das theoretisch moegliche Maximum. Fuer mich steht fest, dass bei der Wikipedia einiges falsch laeuft, aber es ist denkbar, dass es so, wie es laeuft, die am wenigsten falsche Moeglichkeit ist, etwas zu erreichen. Bei Wikipedia sind IMO die Regeln durch die enstandenen Diskussionen zu streng geworden und beschneiden die Freiheit des Projektes zu stark. Ich stelle mir die Frage, ob unser Projekt OpenStreetMap Gefaehr laeuft, sich aehnlich zu entwickeln, ob wir auch in eine Richtung steuern, bei der wir uns immer mehr von denen da draussen abkapseln, mehr und mehr unsere eigenen Regeln aufstellen, Buerokratie aufbauen, Hierarchien erzeugen, schliesslich bezahltes Personal beschaeftigen muessen, weil wir unseren eigenen Freiwilligen nicht mehr ueber den Weg trauen koennen, und und und. Aus Sorge vor verkrusteten Strukturen bin ich ja immer gleich einer der ersten, der dagegen argumentiert, wenn mal wieder jemand mit irgendwelchen Demokratie-Ideen fuer OpenStreetMap ankommt. Meiner Ansicht nach hat ein fehlgeleitetes Verstaendnis von Demokratie zu der Misere bei der Wikipedia beigetragen - sowas wie die Relevanzkriterien ist automatisches Produkt des verzweifelten Versuchs, irgendetwas gerecht zu machen. Viele nehmen an, dass es automatisch gerecht ist, wenn wenigstens klare Regeln existieren, nach denen entschieden wird. Relevanskriterien gibt es auch bei OSM und die sind auch notwendig. Sollen in OSM auch Flugrouten, Gullideckel, Grashalme, Bahnschwellen, unterirdische Leitungen und ganz übertrieben einzelne Atome gemappt werden ? Es gibt auch noch andere Regeln in OSM : wie tagge ich etwas (straßenschilder mit Abkürzungen oder nicht, Multipolygone..) Es gibt kaum Diskussionen in Gegenden, wo ein/zwei Mapper alles einpflegen. Kommen dann neue User ind er Gegend dazu, dann kann es durchaus Diskussionen geben und das wird immer schlimmer, je mehr User OSM gewinnt. Man muss eine gute Balance für OSM finden aber das wird nicht einfach werden. Ab einer gewissen größe wird sich die Community nicht mehr vernünftig selbst organisieren können ohne Regeln und Admins. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was kann man denn da machen?
Daniela Duerbeck wrote: Ich verstehe seine Änderungen nicht. Er scheint viel wegzulöschen um es dann fast gleich wieder hochzuladen. http://www.openstreetmap.org/browse/node/616430237/history http://www.openstreetmap.org/browse/node/706208867 Diese Relation mit den Häusern hat er mit der Zeit ganz schön auseinandergenommen : http://www.openstreetmap.org/browse/relation/59323/history Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maps fuer Garmin
Hallo Andreas ich suche mir gerade einen Ast. Es gibt zig Quellen für OSM-Karten auf Garmin. Kann sein, Garmin Karten haben nur indirekt etwas mit OSM zu tun. Nicht eine einzige kann unter Windows verwendet werden, da immer mit BZIP, GZIP oder TAR-GZIP gepackt, was Windows nicht versteht. (Oder es werden komische EXEs ausgeliefert, deren Output dann wieder die buggy Garmin-Software benötigt). Selbstverständlich können BZIP2 und andere Packformate unter Windows absolut Problemlos benutzt werden. Da die meisten Tools unter Linux arbeiten ist doch es absolut selbstverständlich das man auch dort verbreitete Formate benutzt solange es keine unüberwindbare Hürde auf anderen Platformen darstellt. Also benötigt man entweder ein *ix oder muss sich wieder irgendwelche kostenpflichtige und/oder das Windows-System kaputtmachende Drittsoftware draufpacken. Es gibt genügend freie und gute Programme um Archive unter Windows zu verarbeiten. Als Beispiel ist 7-zip zu nennen. Warum werden die Karten nicht einfach gezippt? Ein ZIP-Programm ist doch überall dabeik, egal ob bei Windows, Linux, BSD, OSX usw. - also ein echtes Universalformat mit dem jeder etwas anfangen kann. Weil ZIP nicht mehr zeitgemäß ist von der Kompression AFAIK. Da die Datenmengen bei OSM sehr groß ist macht es absolut Sinn eine gute Kompression zu benutzen. Irgendwer muss schließlich die Kosten für den Speicherplatz und den Download bezahlen. Ich würde es begrüßen, wenn diejenigen, die die sonst wirklich großartige Arbeit leisten, hierüber mal nachdenken würden. *kopfschüttel* Es fehlt nur noch die Beschwerde das bei OSM PNG Bilder benutzt werden die unter Windows (vom OS) nur unzureichend unterstützt werden. Matthias PS: Ich ein Windows Benutzer PPS: Dein Mailer ist defekt, er hat die Zeilenumbrüche vergessen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie aktuell ist die Straßenliste?
Andreas Neumann wrote: Scheint ein generelles Problem zur Zeit zu sein, andere Orte sind auch betroffen. Ich vermute mal das liegt an der XAPI. Die wirft auch mir seit Tagen nur veraltetes Material aus... Flo hat eine eigene Datenbank und importiert die minute_diffs. Vielleicht ist gerade etwas im Eimer, er ist zur Zeit wohl im Urlaub. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multipolygone bei Werlte, Emsland
dieter jasper wrote: Hallo, kann sich mal jemand mit JOSM den Bereich um Werlte/Emsland anschauen. Da ist wohl etwas mit den Grenzen (Relation 62597/62540) schief gegangen. Die beiden Relationen sehen doch gut aus. Ich kann keinen großen Fehler entdecken, nur das isn_in und ein place Tag habe ich entfernt. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] NACK Gemeindegrenzen Baden-Württemberg f ür OpenStreetMap
Christian Schmitt wrote: Vor allem muss man sich mal vor Augen führen, dass diese Leute von unseren Steuergeldern bezahlt werden. Von dieser Warte aus betrachtet müssten amtliche Kartenwerke prinzipiell Allgemeingut sein. Aber so ist es halt: wir leben leider nur auf dem Papier in einer Demokratie. Hast Du auch schonmal versucht in Angies Mercedes mitzufahren weil Du den zum Teil auch aus Steuergeldern mitfininaziert hast ? Matthias PS: Ich finde das sich die Gemeinden auch ziemlich anstellen. Uns würde sogar eine leicht ungenaue Grenze helfen/reichen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tschad-See in Osmarender
Christian H. Bruhn wrote: Woran kann das liegen? Bringt das zusätzliche Polygon [3] den Renderer durcheinander? Das zweite Polygon ist garantiert der Grund, vor allem weil beide unterschiedlich getaggt sind (natural=water, natural=coastline). Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation 18162 (Radroute D11 Ostsee - Oberbayern) ist z.Z. leer
Frederik Ramm wrote: ttp://api.openstreetmap.org/api/0.6/relation/18162/1497 die letzte gute Version holen und sie wieder hochladen - aber bitte, indem man die aktuelle Relation 18162 loescht und eine *neue* Relation anlegt, damit man die 1498 alten Versionen loswird, sonst sattelt man auf die 100 MB grosse History nur noch weitere oben drauf. Ich war mal so frei und habe die Relation unter ID 544296 neu angelegt. Es waren allerdings 5-10 Member gelöscht worden in der zwischenzeit. Da diese Relation wirklich extrem groß ist würde ich diese Relation nur zur Vorlage nehmen um kleine Stücke zu erstellen, vielleicht nach Bundesland getrennt. Ich glaube beim R1 ist man einen ähnlichen Weg eingeschlagen. Anschließend würde ich die Relation wieder löschen Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation 18162 (Radroute D11 Ostsee - Oberbayern) ist z.Z. leer
Karl Eichwalder wrote: Fazit: die GUI muss unbedingt verbessert werden. Ja, ich habe auch immer etwas Angst wenn der Dialog auftaucht. So ganz durchsichtig finde ich den Dialog nicht. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwendung von Relationen mit type=boundary
Hallo ! Und den Membern braucht man doch auch keine admin_level- und boundary-Tags geben, oder? Es wär IMO schon sinnvoll, wenn an den Wegen allgemein irgendwas dransteht, was es sein soll. Jedesmal raten, für was die Relation sein soll (und u.U. mehrere Relationen öffnen zu müssen) halt ich nicht für sinnvoll. Da geht ein gutes Stück Übersicht verloren und Zeit kostet es auch. Die admin_level Tags auf den Grenz-ways helfen extrem bei einer beschädigung der Grenzrelation. Ohne diese Information könnte ich viele defekte Grenzen nicht mehr so einfach reparieren. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] village, hamlet, locality?
Moin ! Ich weiss nicht, wie grosszügig die Deutsche Post ist, aber hier in der Schweiz hilft die Faustregel: eigene Postleitzahl = village keine eigene PLZ= hamlet Das kannst du hier nicht bringen. :) Hier gibt es oft Gemeinden mit 3-4 Dörfern und einer gemeinsamen PLZ. Als Beispiel http://de.wikipedia.org/wiki/Steinheim_(Westfalen) : Alle Dörfer und die Stadt haben die gleiche PLZ, ein Dorf hat sogar fast 1k4 Einwohner. Beim Wechsel von 4stelligen PLZ auf 5 Stellen im Rahmen der Wiederverteinigung hätte man ansonsten gleich auf 6 Stellen gehen müssen was noch schlechter zu merken ist. Die Post hat nur jedem Zustellstützpunkt mindestens eine PLZ zugesprochen, mehr war nicht nötig. Früher hätte ich gesagt das man bei mehr Schweinen als Einwohnern von hamlet ausgehen kann aber das ist in den Zeiten von Großmastbetrieben auch nicht mehr sinnvoll :-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwendung von Relationen mit type=boundary
Frederik Ramm wrote: Das ist aber ziemlich unlogisch. Wenn etwas nicht genug Informationen hat, um als Multipolygon interpretiert zu werden, dann hat es auch nicht genug Informationen fuer type=boundary. Das wiederum finde ich unlogisch. Bei boundary ohne Rolle weiß ich das ein Mitglied ohne Rolle teil des Hauptaußenrings ist denn sonst wäre es enclave oder exclave. Bei einem Multipolygon ohne Rolle weiß ich nicht was es ist und ich muss es durch einen Algorithmus ermitteln. Die Rollenangaben inner und outer im Multipolygon sind redundant, da man aus der Geometrie ablesen kann, welche Ringe innen und aussen sind, und ein gescheiter Verarbeitungsalgorithmus das sogar tun *muss*, weil sich Leute bei den Rollen doch oft irren. Man kann ziemlich viel durch entsprechend komplizierte Algorithmen deuten, mehr oder weniger Fehleranfällig und mit mehr oder weniger Rechenpower und RAM. Leider hat mein Brain eine beschränke Rechenpower und das zur verfügung stehende RAM leidet unter Altersschwäche Mit redundant meine ich nicht, dass es schlecht ist, diese Rollen zu setzen - denn dann kann ein Algorithmus das als Warnung anzeigen, wenn irgendwo eine Rolle nicht zur Geometrie passt. Zum Beispiel passier es oft, dass eine Lichtung in einem Wald versehentlich einer anderen Waldrelation als der, in der die Lichtung tatsaechlich liegt, zugeordnet wird. Das role=inner ist dann ein Hinweis auf diesen Fehler; ohne role wuerde man annehmen, dass es sich um zwei zusammengehoerige, aber disjunkte Waldstuecke handelt. Das ist z.b. einer der Gründe warum die Rolle hilft. Trotzdem ist die role nicht zwingend erforderlich fuer ein Multipolygon. Daher haette ich an Deiner Stelle einfach alles so gelassen, wie es war. Für mich sind multipolygon und boundary gleichwertig, zumindest solange im Wiki nichts anderes steht. Hätte ich durch das umtaggen etwas beschädigt, dann hätte ich das nicht gemacht. Ich habe den Fehler behoben, da ich die doppelte Sicherheit gut finde und es mir beim beheben der Relationsfehler hilft. Erst diese oder letzte Woche habe ich eine Grenzrelation korrigiert, die ich ohne vorhandene inner/outer Rollen nicht mehr hinbekommen hätte ohne mir stundenlang die History von x ways anzuschauen und zu deuten. Diese Grenze hatte sowohl eine exclave als auch eine enclave und war völlig im Eimer. Selbst Wikipedia und die admin_level auf den ways konnten in dem Fall nicht mehr helfen. Die Ursache davon war, wie es in letzter Zeit extrem häufig passiert, ein kaputtsplitten der Relation. Wie es dazu kommt: in JOSM kleinen Ausschnitt mit Grenzweg laden, eine Grenze vom dem Grenzweg aussuchen und die anderen Member im Relationseditor nachladen. Diese nachgeladenen Grenzenwege irgendwo im nicht geladenen Bereich mehrfach splitten und schon bleibt nicht mehr viel übrig von den anderen Relationen die auch über den Weg verlaufen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwendung von Relationen mit type=boundary
Frederik Ramm wrote: Für mich sind multipolygon und boundary gleichwertig, zumindest solange im Wiki nichts anderes steht. Kannst Du evtl. nochmal rausfinden, wo diese Gleichwertigkeit im Wiki beschrieben ist? Dann wuerde ich das mal aendern. Auf Anhieb finde ich nichts; im Wiki steht unter Multipolygon: http://wiki.openstreetmap.org/wiki/DE:Relation:boundary This page describes a relation. It should outline the community consensus upon how complicated Relation:boundary should be mapped using relations. Ich kenne auch die Hinweise im Wiki das man auch bzw. neuerdings multipolygone benutzen sollte aber zur Zeit sind beide Formate vorhanden und somit für mich gleichwertig. Es ist auch nicht so das neue Grenzen nicht als boundary getaggt werden, es wird beides benutzt wenn neue Grenzen eingezeichnet werden. Ansonsten müssten doch Relationen vom Typ boundary als veraltet markiert werden oder gibt es einen sonstigen, für mich nicht erkennbaren Nutzen dieses Relationstyps ? Dazu sollte man auch gleich die vorhandenen boundary Grenzen in multipolygone umwandeln damit die Struktur dann einheitlich ist. Wie gesagt, ich will boundary nicht verteidigen, mir ist es im Prinzip reichlich egal solange die Rollen dazu passen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwendung von Relationen mit type=boundary
Frederik Ramm wrote: Ich habe die Diskussion dazu eben noch einmal gelesen. Das stammt wohl aus der Zeit, als Multipolygone lediglich einen einzelnen aeusseren Ring haben konnten. Da hiess es dann oh, fuer Grenzen brauchen wir aber dann was anderes, um Exklaven modellieren zu koennen. Es gab auch das Argument, bei multipolygonen kommen ja keine Tags an die Relation, daher passt das nicht zur boundary. Stimmt ja alles nicht mehr. Mittlerweile gibt es m.E. keinen Grund mehr fuer diese boundary-Verwendung, aber einige haben sich halt dran gewoehnt, und ich kann auch nichts andres machen als andere zu ueberzeugen versuchen. Ich verstehe die Argumente vollkommen aber ich wollte mich eigentlich nicht einmischen weil ich auch keine Lust auf sinnlose Diskussionen habe. Aber egal was man macht, irgendeiner stört sich anscheinend bei OSM immer an irgendwas :-( Um das eindeutiger zu machen würde ich bei der boundary Relation Beschreibung ganz oben groß drüber schreiben, das boundary Relations veraltet sind und das nun multipolygone benutzt werden sollen. Dazu würde ich alle vorhandenen deutschen boundarys mit admin_level=x in multipolygone umtaggen inklusive richtiger vergabe der Rollen. Ich würde das so machen, wenn es mir nicht egal wäre :-) Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] richtiges Modellieren von Multipolygon-Relationen
Tobias Knerr wrote: Ich fände eine solche Aussage nachvollziehbar, wenn man beim Mappen oder Auswerten nicht sinnvoll ohne diese Konstrukte arbeiten könnte. Das ist aber nicht wirklich gegeben. Im Gegenteil sehe ich derzeit keinen überzeugenden Grund, warum ich mir die Mühe machen sollte, neben dem klassischen Schema auch advanced multipolygons in einer Anwendung zu unterstützen. Jedenfalls einer Anwendung, die nur physische Objekte und keine Grenzen oder dergleichen verarbeitet. Ich finde das keep it simple Prinzip hier eigentlich passend. Normale Areas finde ich sinnvoller solange man damit auskommt was bei Gebäuden eigentlich fast immer der Fall sein sollte. Erweiterte multipolygone habe aber durchaus einen Sinn bei großen Wäldern oder Seen weil der geschlossene way zu lang wird (spätestens beim 2k Node Limit). Ein Beispiel ist z.b. der Bodensee Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenverzeichnis von Leverkusen online - Dank an Sven!
Philip Gillißen wrote: Hallo zusammen! Endlich hat es geklappt: Das Straßenverzeichnis für Leverkusen ist online! Wieso endlich ? Unter http://osm.gt.owl.de/Strassenliste/output/62449/ gibt es das schon 1 Jahr. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verwendung von Relationen mit type=boundary
Frederik Ramm wrote: Das koennte man ja mal den Benutzer Nightdive fragen, der diese Aenderung vollzogen zu haben scheint. Es kann auch sein, dass das mit dem boundary irgendwo im Wiki steht, dann muesste man das mal finden und aendern. Für mich sind sowohl boundary als auch multipolygon als Grenzen jeglicher Art zulässig. Was verwendet wird ist mir persönlich absolut egal aber logisch korrekt sollte es sein. Ein multipolygon wo die Member keine Rolle haben finde ich falsch und ich habe das auf eine einfache weise gelöst, indem ich es zu boundary umgetaggt habe. Alternativ hätte ich jedem Member auch ein outer verpassen können aber das wäre mehr Arbeit gewesen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] richtiges Modellieren von Multipolygon-Relationen
Martin Koppenhoefer wrote: Logisch betrachtet müssten doch alle Tags, die für die komplette Fläche innerhalb gelten (z.B. Namen, etc.) auf den outer-way gelegt werden, Tags, die nur für das Gebilde [Outer-way abzüglich inner ways] gelten, sollten entsprechend auf die Relation gelegt werden, und was nur für einen inner-way gilt, wird dort getaggt. Dieses Tagging wird AFAIK von den Rendern richtig dargestellt, JOSM hat seine Probleme. Durch das Multipolygon wird geht die outer Fläche nur von vom outer ringzu dem inner Ring. Damit ist es völlig egal (IMO) ob die Tags nun auf dem outer oder auf dem inner stehen. Den Vorteil beim alles auf den outer RIng taggen ist, das man sofort beim anklicken der Area sieht, um was es sich handelt und nicht erst die Relation öffnen muss. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] richtiges Modellieren von Multipolygon-Relationen
Martin Koppenhoefer wrote: Du gehst halt nur vom einfachsten Beispiel aus: ein outer und ein inner way. Multipolygone können aber aus mehreren outer und mehreren inner ways bestehen. Tags auf dem inner-way werden von den bisher mir bekannten Auffassungen immer als Beschreibung des innerhalb des inner-way-polygons liegenden Features gesehen, und nicht als Beschreibung der Multipolygon-Fläche (die ja ausserhalb des inner liegt). Tags auf dem outer-way beschreiben die Fläche zwischen outer und inner Tags auf dem inner-way beschreiben die Fläche innerhalb von inner. Tags in der Multipolygon Relation beschreiben die Fläche zwischen outer und inner Zumindest die Area-Tags dürfen bei einem advanced Multipolygon, wo die outer Fläche aus mehreren ways besteht die zusammen erst den geschlossenen Ring bilden, nur auf der Relation hinzugefügt werden. Auf den einzelnen outer-ways wären die Area-Tags falsch weil die einzelnen Teile keine geschlossene Fläche bilden sondern erst die Relation. Einer der Gründe warum ich erweiterte Multipolygone nur in seltenen Fällen gut finde (Node Limit der ways erreicht). Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SSL-Zertifikate mit fehlender Trustcenter-Signatur
Frederik Ramm wrote: Es ist erstaunlich, wie leicht die Entscheidung von ein paar Browser-Programmierern andere zu Stuempern machen kann. Ich persoenlich boykottiere Firefox 3, weil ich mir nicht vorschreiben lassen will, welche Anforderungen ich an Zertifikate zu stellen habe. Ich finde, es gibt durchaus einen legitimen Use Case fuer Verschluesselung ohne Authentifizierung (mir ist egal, wer Du bist und wer Dich zertifiziert hat, aber mein Provider soll nicht mithoeren, wenn wir Daten austauschen). Die, die diesen Mist im FF3 zu verantworten haben, stellen sich auf den Standpunkt, dass sie den unvorsichtigen Dummusern da draussen keine Eigenverantwortung in dieser Sache zumuten koennen. Deine Einstellung ist wirklich erstaunlich denn das hätte ich von Dir nicht erwartet. Eine Verschlüsselung ist absolut wertlos wenn man nicht weiß mit wem man verschlüsselt. Eine verschlüsselung bringt Dir nichts, wenn Du keine Ahnung hast ob Du zwischen Dir-Webseite oder zwischen Dir-MITM Attacker-Webseite verschlüsselst. Im Gegenteil: Eine solche angebliche verschlüsselte Verbindung ist sogar gefährlicher als eine unverschlüsselte weil eine scheinbare Sicherheit vorgegaukelt wird. Das die Warnungen nicht nur für Dummuser sind beweist Du gerade Entweder nicht verschlüsseln oder im Notfall den CACert Root importieren und CACert Zertifikate benutzen aber in den meisten Fällen sollte StartSSL Zertifikate ausreichen. Seit FF3 kann man praktisch nirgends mehr einfach mal so ein selbstgebautes SSL-Zertifikat einsetzen, ohne dass irgendjemand aus der von FF3 generierten Warnung den Fehlschluss zieht, dass da ja wohl Stuemper am Werk sein muessen, und entsprechend auf die Kacke haut. Damit hat FF3 genbau das erreicht, was die Entwickler wollten. Früher wurden solche Warnungen einfach weggeklickt und MITM Attacken waren damit erfolgreich. Heute überlegen die User und akzeptieren solche grundlegenden SSL Fehler zum Glück nicht mehr. Immer, wenn ich FF3 benutze, denke ich daher: Nun bist Du also einer von diesen verantwortungslosen Dummusern da draussen, die FF3 vor der beosen Welt schuetzen muss. Da hab ich mich noch nicht so mit angefreundet. Ich hoffe mal, bevor der FF2 so in die Tage kommt, dass gar nix mehr damit geht, wird es eine andere akzeptable Alternative geben. Vielleicht eine Spezialrelease FF3 for Grown-Ups oder so. Wenn Dir Deine Sicherheit egal ist, dann könntest Du https://addons.mozilla.org/de/firefox/addon/79787 probieren. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SSL-Zertifikate mit fehlender Trustcenter-Signatur
Ulf Möller wrote: Damit hat FF3 genbau das erreicht, was die Entwickler wollten. Und die CAs und Browser-Hersteller verdienen kräftig daran. Dieses Argument hört man immer wieder aber es wird nicht richtiger je häufiger man es wiederholt. CAs: Mit den StartSSL Zertifikat für 0€ verdient sich die Firma dumm und dämlich Browserhersteller: Mozilla kann jedem seinen Mitarbeiter eine Weltreise bezahlen durch die Einnahmen von den integrierten Root CAs die für 0€ integriert werden. Früher wurden solche Warnungen einfach weggeklickt und MITM Attacken waren damit erfolgreich. Wie viele erfolgreiche MITM Attacken gab es denn so? Eine Zahl kann ich Dir nicht nennen aber einen solchen Fall gibt es z.b. in bugzilla.mozilla.org dokumentiert. Und wie viele der voreingestellten CAs in Asien oder Südamerika wissen, wie man einen echten deutschen Handelsregisterauszug von einem falschen unterscheidet? Die Kriterien der aufnahme von Root-CAs sind etwas anderes und ich kann mich dazu nicht äußern. Die von Motilla geforderten Kriterien sind allerdings sehr umfangreich, inklusive einem externen Security Audit (an demm CACert übrigens zur Zeit scheitert). Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SSL-Zertifikate mit fehlender Trustcenter-Signatur
Frederik Ramm wrote: Siehst Du, das ist genau die gleiche Arroganz, die ich dem FF3-Team ankreide. Wie kannst Du Dir denn anmassen, zu entscheiden, ob eine Verschluesselung mir etwas bringt? Doch nur, indem Du mir meine eigene Urteilsfaehigkeit absprichst. 100% Sicherheit wird es natürlich nie geben aber wenn etwas grundsätzlich unsicher ist, dann kann ich es nicht für sicher erklären, auch in Abstufungen. Das Vertrauenskette ist ein essentieller Bestandteil des SSL Systems und Du beschwerst Dich jetzt, das Probleme entstehen wenn Du SSL für etwas anderes missbrauchen willst wobei das Problem ist, das Du 2x mehr klicken musst. Es handelt sich nicht um Fehler. Und jemand, der sich diesem Diktat entzieht, dem ist seine Sicherheit nicht egal - der weiss vielleicht einfach selbst, wo er welchen Grad von Sicherheit will. Es hindert Dich doch keiner daran CaCert Zertifikate zu benutzen oder wenn es unbedingt sein muss für Sachen im LAN ein eigenes Root-Zertifikat zu erstellen und damit die eigenen Zertifikate zu erstellen (+ importieren des root Zertifikats im Browser). Sicherheit ist nicht, wie es gern dargestellt wird, etwas, das man entweder hat oder nicht hat. Es gibt ganz unterschiedliche Abstufungen. Damit kann man sich beschaeftigen und seine eigene Entscheidung treffen. Wie schon geschrieben: Du beschwerst Dich darüber das Du das SSL system für etwas benutzen willst, für das es nicht gemacht wurde (verschlüsselung ohne Thrust Chain) und Du dadurch 2x mehr klicken musst. Firefox bzw. Mozilla war lange Zeit der Browser fuer Leute, die lieber selbst etwas entscheiden wollten - im Gegensatz zu den benutzerfreundlichen Systemen, die dem Benutzer alles vorgeschrieben haben. Das ist heute nicht mehr so, und diesen Wandel beklage ich. Das stimmt durchaus denn Mozilla hat nicht nur noch die Experten User wie vor 8 Jahren aber es ist doch für Dich nicht unmöglich Self signed certificates zu benutzen. Das solche Zertifikate auf offiziellen Seiten nichts zu suchen haben verstejht sich von selber. Das die Benutzer für SSL sensibilisiert wurden ist ein echter Erfolg von Mozilla und bestätigt doch nur, das die Änderung in FF3 absolut richtig war. Ansonsten kann ich nur auf http://blog.johnath.com/2008/08/05/ssl-question-corner/ verweisen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
André Reichelt wrote: Und kommt mir jetzt nicht mit dem Argument, diese Genauigkeit sei gar nicht erforderlich. Ich weiss, dass ich den genauen Verlauf der weißen Linien an einer Autobahnauffahrt für die Navigation nicht brauche. Das ist aber nicht der einzige Anwendungsfall, auch wenn sich das einige hier anscheinend wünschen. Dann nenne mir mal endlich einen sinnvollen Anwendungsfall. Bei den meisten Anwendungsfällen die mir so einfallen brauchst Du eine Genauigkeit die nur Katasterdaten liefern können und diese Genauigkeit wird OSM niemals liefern können auch wenn Du Dir das so sehr wünscht. Luftbilder sind leicht verzerrt/schräg aufgenommen und können Versatz haben. Solange man solche Flöchen mit unseren mitteln (GPS) nicht nachprüfen/korrigieren kann ist das für mich eh recht sinnlos. Das kann sich mit Galileo und entsprechenden bezahlbaren GPS Geräten verbessern, ich bin nicht so im Bilde welche Genauigkeit bei einem Kombiempfang drin ist. Ich wünsche mir einen eigenen Layer für solche Flächen. Dann können sich Leute dort austoben ohne das man sich daran stören könnte. Speicherplatz in der DB dürfte eigentlich nicht das Problem sein und man könnte diesen Layer eventuell auch in einer zusätzlichenb DB auslagern. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
André Reichelt wrote: Das einfache Modell funktioniert bei der Navigation und bei groben Stadtplänen wunderbar, das habe ich schon gesagt. Spätestens wenn ich aber in die Straßenperspektive wechsle wird dir das Ding um die Ohren fliegen -- und zwar ganz massiv. Es gibt Anwendungen, da interessiert mich, wo genau in der Kreuzung eine Insel liegt und wie groß die ist. Du kannst Dir das vielleicht nicht vorstellen, da Du selbst keine Anwendungen in diese Richtung entwickelst, aber grundsätzlich müssen wir so detailiert wir möglich mappen. Wir dürfen uns nicht auf die Falle einlassen, etwas wegzulassen nur weil wir glauben, dass es gegenwärtig nicht sinnvoll nutzbar ist. Man darf nich so detailiert wie möglich mappen denn bei den vorhanden Werkzeugen wird ein bearbeiten fast unmöglich. Viele User werden überfordert wenn ich mir anschaue das ein verbinden von Vektorlinien schon Probleme macht. Das Modell darf nicht zu kompliziert werden wenn wir die Masse der OSM Benutzer verlieren wollen (die nicht Experten). Das war auch genau der Grund, weswegen man das bis heute nicht macht. Jetzt stehen allerdings die Luftbilder zur Verfügung, die uns auf ein paar Zentimeter genau erlauben, genau diese Daten zu erfassen. Wie lange stehen uns die Luftbilder noch zur Verfügung ? Begeben wir uns nicht in eine Abhängigkeit wenn wir Luftbilder als notwenige Grundlage unserer Daten nehmen und ein GPS nicht mehr ausreicht ? Ich denke das wir so eine Abhängigkeit verhindern sollten, selbst wenn Aerowest uns die Luftbilder für die nächsten Jahre zur verfügung stellt und nicht nur 3 Monate. Straßen verändern sich nämlich ständig und bei der von Dir geforderten Detailtreue sogar noch viel öfter. Die Dortmund Bilder von Aerowest sind übrigens nicht aktuell. Bei einer Abweichung von wirklichkeit und Luftbildern bleibt nur das löschen übrig. Wir mappen nicht für heute sondern für morgen. Wenn heute etwas auch noch als Speicherplatzverschwendung angesehen wird, ist es morgen der Grund, weswegen man Material bei OSM kauft und nicht zur Konkurrenz geht. Wir mappen für morgen nur ich sehe Deine Zukunft nicht als morgen an und für heute finde ich diese Daten sogar als störend an. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
André Reichelt wrote: Das mag auf Autobahnen fast immer und außerorts gelegentlich gelten, innerstädtisch wirst Du damit aber in der Regel massiv auf die Schnauze fallen. Abbiegespuren kannst Du mit deiner Methode im Übrigen auch nicht sauber darstellen. Das Spurenproblem mal außen vorgelassen denn das Problem ist nur wie man es am besten macht und nicht, das es mit Vektoren nicht möglich ist. Ich sehe da absolut nicht das man mit Vektoren irgendwo auf die Schnauze fällt, eher schon mit Flächen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Martin Koppenhoefer wrote: das liegt aber weniger an den Details. Die Tools sind in den letzten Jahren übrigens massiv besser geworden, ohne ein bisschen Einarbeitung geht es nicht. Wer das gar nicht will, muss sich eben auf Editoren beschränken, mit denen man z.B. nur nen Namen eintragen oder Nodes hinzufügen kann. Selbstverständlich sind die Tools besser geworden aber für viele ist es aktuell immer noch schwer genug. Und aktuell braucht man etwas Einarbeitung.Mit stark erhöhter Komplexität das ganze noch extrem verschlechtern wollen und dann zu sagen das die sich auf POIs eintragen beschränken sollen finde ich arrogant. Straße als Fläche und die Fläche am besten noch aus Multipolygonen zusammensetzen und schon brauche ich schon Minuten bis selbst ich das kapiert habe. in manchen Gegenden hat ein GPS noch nie ausgereicht (enge Straßenschluchten in verwinkelten Altstädten), auf Dauer werden wir vermutlich keine schlechteren oder weniger Luftbilder zur Verfügung haben. GPS reicht auch in Straßenschluchten solange man nicht mit einem Iphone die GPS Spur erzeugt und man auch mehr als eine GPS Spur an verschiedenen Tagen erzeugt. Dann braucht man nur noch Brain 1.0 zur Korrektur. NUr in Tunneln wird es etwas schierig aber da helfen Dir Luftbilder auch nicht. Woher willst Du wissen das wir in Zukunft immer solche Luftbilder zur Verfügung haben werden ? Das halte ich eher für höchst unwahrscheinlich, besonders weil es immer aktuelle Luftbilder sein müssen. Bei einer Abweichung von wirklichkeit und Luftbildern bleibt nur das löschen übrig. was meinst Du denn damit? Straße als Fläche aus Luftbild abgezeichnet, Straße wird umgebaut, Mapper vor Ort erfasst sie mit den normalen OSM Mitteln (GPS) neu als Vektor. Die Fläche kann er in dem Fall nur löschen denn die ist nicht mehr korrekt und er kann die mit OSM mitteln nicht einfach korrigieren. Beim Wohnort meines Arbeitskollegen aus Dortmund passen die Aerowest Luftbilder zum Beispiel nicht mehr. Wir mappen für morgen nur ich sehe Deine Zukunft nicht als morgen an und für heute finde ich diese Daten sogar als störend an. sprichst Du jetzt konkret von Straßenflächen, oder welche Detaildaten stören dich sonst noch? Ich mappe übrigens für heute, morgen und übermorgen. Konkret von Straßenflächen, am besten noch aus Multipolygonen bestehend. Ach ja, ich mappe auch für über-übermorgen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] boundary relations / teilgrenzen
Thomas Ineichen wrote: Insbesondere *technisch* nicht handhabbar. Frankreichs Unterrelationen haben zur Zeit zusammen 2118 Elemente - also mehr als das technische Maximum von 2'000 Mitgliedern pro Relation[1]. Eine Aufteilung nach Nachbarstaaten scheint mir da die sinnvollste Lösung: Das 2k Limit existiert nur bei Nodes in way aber nicht bei der Anzahl der Relationsmitglieder (AFAIK). Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
olvagor wrote: Matthias Versen schrieb: Erst die Straßen unter massenweise Ackerflächen verstecken und nun auch noch Straßen als Flächen, so langsam verliere ich die Lust an OSM :-( Was ist denn dein Ziel für OSM? Und was meinst du mit unter Ackerflächen verstecken? Das ist doch ein Problem des Renderers, oder versteh ich dich falsch. Wenn du keine Ackerflächen magst, dann render die halt nicht. Gemeint sind Flächen die auf die Straße gezogen werden (eine gemeinsame Linie). Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
olvagor wrote: Denkst du (uns auch andere) eigentlich auch daran, daß ein Neueinsteiger überhaupt eine Chance haben sollte, irgendwie durchzublicken? Nein, an die denke ich nicht. Das ist ein Problem, das eher von Ziemlich arrogant, findest Du nicht ? Editor-Seite angegangen werden muss. Was ich schon vorher sagte: wir können doch unsere Daten nicht künstlich schlecht halten, damit Einsteiger damit keine Probleme haben. Eine Karte ist schlicht und ergreifend ein komplexes Ding, wenn sie mal nen gewissen Genauigkeitsgrad erreich hat. Extrem arrogant finde ich ! So arrogant das ich solche Flächen wohl einfach löschen werde wenn ich denen begegne und die mich stören denn viele Daten in OSM kommen genau von solchen Anfängern und OSM lebt von Ihnen. Je komplizierter das Ganze wird, läuft es am Ende auf zwei Sachen hinaus: 1. Neueinsteiger sind gleich wieder weg, aus Angst etwas zu beschädigen Grund für eine Spielwiese Eine Spielwiese hilft gewisse dinge zu probieren ohne etwas kaputt zu machen. Es hilft aber nicht bei absolut unnötig kompliziertten Mapping. OSM ist und wird immer eine vereinfachte Form der Wiklichkeit bleiben, man sollte es einfach nicht übertreibe. Die Karte wird unbrauchbar und wertlos wenn die so kompliziert wird, das die Daten nicht mehr auswertbar sind. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
olvagor wrote: Warum? Ich schreibe doch, dass das ein Problem ist. Aber keins, dass die Datenseite angeht sondern vom Editor gelöst werden muss. Natürlich muss die Komplexität für Anfänger handhabbar bleiben aber das ist ein Editor-Problem. Und solange das Editor Problem nicht einigermaßen gelöst ist sollte man vielleicht bei grundsätzlichen Dingen wie dem Straßennetz vielleicht darauf verzichten. Editor-Seite angegangen werden muss. Was ich schon vorher sagte: wir können doch unsere Daten nicht künstlich schlecht halten, damit Einsteiger damit keine Probleme haben. Eine Karte ist schlicht und ergreifend ein komplexes Ding, wenn sie mal nen gewissen Genauigkeitsgrad erreich hat. Extrem arrogant finde ich ! So arrogant das ich solche Flächen wohl einfach löschen werde wenn ich denen begegne und die mich stören denn viele Daten in OSM kommen genau von solchen Anfängern und OSM lebt von Ihnen. Versteh ich wiederum nicht. Warum ist Genauigkeit arrogant? Ich hab noch nicht verstanden, wo du OSM in Zukunft sehen willst. Wenn wir nur als Grundlage für Router dienen wollen, dann können wir jetzt aufhören. Du schreibst, das Dir das Problem, das Anfänger probleme bekommen egal ist, es ist ganz einfach nicht Dein Problem. Und aufhören ? Schau Dich mal in OSM um, da gibt es noch mehr als genug zu tun und außerdem ist das routing nur eines der Anwendungsbeispiele von OSM. Was ist denn bitte an Flächen unnötig kompliziert? Beispiel Bürgersteig: Was ist denn bitte an einem way so kompliziert oder an einer Relation ? Trotzdem findet man ganze Städte wo hunderte von Verbindungen zwischen den Straßen nicht vorhanden sind (nicht verbundene Wege) und Anfänger die ein einfaches Multipolygon nicht begreifen. Gotha hat mich als Beispiel vor einiger Zeit 3 Tage Arbeit gekostet um es einigermaßen zu korrigieren. Natürlich kann man es nicht alles noch einfacher machen für die Anfänger und eine gewisse einarbeitungszeit gehört nunmal dazu. Aber das darf nicht als Begründung dazu dienen um alles noch komplizierter zu machen. OSM ist und wird immer eine vereinfachte Form der Wiklichkeit bleiben, man sollte es einfach nicht übertreibe. Seh ich genauso. Aber die Genauigkeit offizieller Katasterkarten sind für mich das mindeste, was ich erreichen will. OSM ist eine Vektorkarte und wird niemals auch nur annähernd die Genauigkeit der Katasterkarten erreichen denn wir haben nicht die Werkzeuge dazu selbst wenn wir bundesweit Luftbilder in 10cm Auflösung bekommen sollten. Damit solltest Du Dich vielleicht abfinden. Was gerne vergessen wird ist das die Pfelege der Daten exponentiell ansteigen wird wenn man alles in die Karte reinkloppt was geht (anderes Beispiele wären die einzelnen Bäume von einem Baumverzeichnis). Die Karte wird unbrauchbar und wertlos wenn die so kompliziert wird, das die Daten nicht mehr auswertbar sind. Erklär mir mal bitte, was an diesem Schema nicht auswertbar ist. Natürlich will ich das bestehende Schema nicht über den Haufen werfen. Hast du dir das von mir bearbeitete Gebiet mal angesehen? Wo gibt es mit der Auswertung Probleme? Die Sachen werden zu kompliziert und werden dadurch mit der Zeit beschädigt und unbrauchbar. Wenn Du Dich mit der QA außerhalb Deines kleinen Gebietes befasst hättest, dann wüsstest Du das und Du würdest erkennen das es in OSM mehr als genug Arbeit gibt. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Frederik Ramm wrote: So arrogant das ich solche Flächen wohl einfach löschen werde wenn ich denen begegne und die mich stören denn viele Daten in OSM kommen genau von solchen Anfängern und OSM lebt von Ihnen. Daten, von denen man weiss, dass sie richtig sind, aus OSM zu loeschen, halte ich - von wenigen begruendeten Ausnahmefaellen vielleicht abgesehen - fuer Vandalismus. Nenn es wie Du willst kannst Du es Vandalismus nennen, für mich ist das Notwehr denn ich habe geschrieben wenn es mich stört was für mich bedeutet, das ein Editieren sehextrem erschwert wird. Wenn Du versuchst, OSM mit den Augen eines Neulings zu sehen, dann versetze Dich bitte auch in die Lage eines Neulings, der in diese Liste blickt und der angesichts von Beitraegen wie Deinem hier den Eindruck gewinnt: Wenn mir irgendwas in OSM zu kompliziert ist, dann loesche ich es einfach. Auch nicht so der Hit, oder? Nein, die werden sich eher freuen das auch einer an sie denkt denn OSM ist schon jetzt so kompliziert. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
olvagor wrote: Florian Gross schrieb: Wenn der Nachwuchs ausbleibt, ist das Projekt irgendwann tot. Manche Gebiete wie Berlin werden auf den mm genau erfaßt sein, Aber was ist denn die Konsequenz daraus? Wenn ich deine Meinung richtig verstanden habe, dann müssten wir irgendwann (in größeren Städten schon gestern) einen Schlusstrich ziehen und nicht weiter mappen. Von Aktualisierungen mal abgesehen. Ja selbstverständlich ! Irgendwann ist ein Gebiet nunmal fertig obwohl es meistens imemr noch genug zu tun gibt durch die nötigen Updates. matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
olvagor wrote: Matthias Versen schrieb: Und solange das Editor Problem nicht einigermaßen gelöst ist sollte man vielleicht bei grundsätzlichen Dingen wie dem Straßennetz vielleicht darauf verzichten. Das seh ich das Henne-Ei-Problem. Wenn wir das ganze jetzt stoppen würden, wird es niemals Editor-Unterstützung dafür geben. Nein, es ist kein Henne-Ei Problem denn die Probleme existieren auch jetzt schon ohne die Straßen als Fläche. Unverbundene Wege sind ein Potlatch-Problem, soweit ich das in den Daten nachvollziehen kann. - Editor-Problem Es ist nich nur ein Potlatch Problem, es betrifft alle Editoren soweit ich gesehen habe. Natürlich kann man es nicht alles noch einfacher machen für die Anfänger und eine gewisse einarbeitungszeit gehört nunmal dazu. Aber das darf nicht als Begründung dazu dienen um alles noch komplizierter zu machen. Ich weiß immer noch nicht, warum Flächen komplizierter sein sollen als Linien. Ich finde Flächen wesentlich komplizierter wenn man den Verlauf folgen will. Dann düften sich solche Straßen-Flächen nicht überlappen und die müssen auch in sich geschlossen sein. Dazu kommt die Situation in 3 Monaten: Wir haben keine Luftbilder mehr und wie will ich dann die vorhanden Daten vernünftig überprüfen oder auch ändern wenn ich keine Louftbilder mehr habe ? Neue Sachen zu erfassen macht imemr mehr Spaß als Fehler zu korrigieren. Das geht mir zumindest so. Deswegen wird die Qualitätskontrolle und auch die Updates das größere Problem für OSm wenn man fertig ist. Ist das überprüfen nicht möglich so bleibt in der Konsequenz nur das löschen wenn an der Straße nur der Bürgersteig um 10cm versetzt wird. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Frederik Ramm wrote: Wenn aber andere erfahrene Mapper mutwillig komplexe Daten aus OSM entfernen, um dem betreffenden Autor zu beweisen, dass er zu viel Detail erfasst hat oder um die Sache (vermeintlich?) fuer Einsteiger leichter zu machen, dann ist das dem Projekt abtraeglich, und ich moechte darum bitten, das zu unterlassen. Du unterstellst hier etwas was nicht korrekt ist. Ich wiederhole es zum zweiten mal : Wenn ich in einem Gebiet mappen will wo so eine Fläche vorhanden sein sollte und diese Flächen mir es extrem erschweren zu mappen, dann werde ich erst ein löschen in Betracht ziehen. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
olvagor wrote: Wieder so ein Spruch, ohne das mal konkrete Kritik kommen würde. Es kam genug Kritik aber die ignorierst Du offensichtlich weil Du Deine IDee einfahc zu toll findest. Nochmal zusammengefasst : a) Alles mit Areas macht OSm noch komplexer als es jetzt schon ist. Komm jetzt nicht mit was ist an Flächen so kompliziert, das ist mehr als offensichtlich nur Du willst es nicht sehen. Zum Teil ist das Editorbedingt aber das heißt nicht das man es ignorieren kann. b) dadurch ist abzusehen das die normalen Vektoren nicht mehr eingezeichnet sind wie bei den Fußgängerzonen, das routing ist im Eimer. c) es müssen sowohl die Vektoren als auch die Flächen gewartet werden, insebesondere wenn ich da an Relationen denke. c) der Gewinn für die Karte ist minimal bis nicht existent. d) es gibt ein width Tag der benutzt wird und mehr als ausreichend ist e) Die Flächen sind nicht mehr korrigierbar nachdem die Luftbilder verschwunden sind. Ab dem Zeitpunkt müssten die eigentlich wieder gelöscht werden solange keine freie alternative zur Verfügung steht. Ich denke, ich werde zukünftig sowas nicht mehr zur Diskussion stellen sondern einfach umsetzen. Dann ist es für Dich anscheinend ok wenn man die dann auch ohne Nachfrage/Dskussion dann einfach wieder löscht. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
olvagor wrote: Dann ist es für Dich anscheinend ok wenn man die dann auch ohne Nachfrage/Dskussion dann einfach wieder löscht. Das seh ich als Vandalismus an. Ich lösche auch nicht einfach Dinge, die ich für unsinnig halte. Und was ist wenn ich die Gegend mit Daten zu Wasserleitungen, Kabeln, Abwasserleitungen, Kaugummis auf den Straßen, einzelne Pflastersteine, Vogelzugrouten, Flugzeugrouten, geologische Erdschichten, Grashalme, jedes einzelne Minischlagloch einzeichne ? Und nicht zu vergessen der geologische Aufbau des Bodens (in Schichten). Zuviele Daten können auch eine Form von Vandalismus sein unbd das beseitigen solcher Daten ist dann eben beseitigen von Vandalismus. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Martin Koppenhoefer wrote: Extrem arrogant finde ich ! So arrogant das ich solche Flächen wohl einfach löschen werde wenn ich denen begegne und die mich stören denn viele Daten in OSM kommen genau von solchen Anfängern und OSM lebt von Ihnen. DAS ist arrogant (einfach löschen, wenn sie MICH stören). Du willst Daten löschen, damit wir mehr Daten bekommen? Durchschau ich noch nicht. Das löschen ist weniger arrogant als das reinkloppen von Daten ohne Sinn und Verstand. Du durchschaust es nicht, das man nicht alle Daten in OSM reinwerfen kann damit die bestehenden Daten bearbeitbar bleiben ? Dann kann ich Dir leider nicht helfen wenn Du das nicht verstehst. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
olvagor wrote: Momentan schon. Aber meiner Meinung nach ist das Fernziel in OSM, dass highway=residential ne Fläche ist und Vektoren nur noch die Fahrspuren darstellen. Mir ist klar, dass wir da noch weit von weg sind und will das jetzt auch nicht auf Biegen und Brechen einführen. Ich sehe das absolut nicht als Ziel von OSM. Ich fände Areas für Straßen sogar absolut hinderlich. Was man allerdings machen könnte wäre ein width Tag und das könnte ein Renderer auch Problemlos auswerten und es ergäbe auch eine passende Fläche. Erst die Straßen unter massenweise Ackerflächen verstecken und nun auch noch Straßen als Flächen, so langsam verliere ich die Lust an OSM :-( Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grenze folgt der Küstenlinie
Falk Zscheile wrote: Moin, gegen die hier in der Runde vertretene These Küstenlinie=Kreisgrenze spricht In Mecklenburg-Vorpommern § 53 des Landeswassergesetzes.[1] Als Grenze zwischen Land und Wasser gilt der mittlere Wasserstand, berechnet aus dem arithmetischen Mittel der Jahresmittelwasserstände der letzten zwanzig Jahre. In OSM ist die Küstenlinie doch ebenfalls so ähnlich festgelegt : Die obere Küstenlinie trennt das Land vom Watt. Sie entspricht der natural=coastline, die den durchschnittlichen Wasserstand bei Springhochwasser (MSpHW) anzeigt. Bei Gewässern mit einem Tidenhub kleiner als 30 cm entspricht sie dem Mittleren Wasserstand. Höhenangaben in Karten beziehen sich meistens auf die obere Küstenlinie. Wenn Du jetzt den mittelwert der letzten 20 Jahre drin haben willst dann ändere doch die Regeln für die Küstenlinie. Also bitte erzählt mir nichts von Wasserstand=Küstenlinie=Kreisgrenze. Hmm, finde das aber so richtig. Im Notfall passen wir die Regeln für die Coastline an. Also wo ist das Problem nur eine Linie zu haben ? Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
