Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p
Am Dienstag, 30. Dezember 2008 19:18 schrieb Tobias Knerr: Bei einer Modellierung per Relation ist die Sache doch recht klar: Eine Spur entspricht genau einem primitiven OSM-Objekt: Way oder Relation. Diese lassen sich in gleicher Weise mit Tags versehen und in gleicher Weise in die zusammenfassende Relation einbinden. Können wir dann nicht wenigstens die Anzahl der Relationen begrenzen ala: 1. Hauptrelation mit highway member 2. Maximal eine weitere Ebene mit einer Relation pro Spur. Im Moment dürfte ich nach dem Vorschlag auch noch Unterrelationen von Unterlationen machen. Die Spur -Relation könnte dann auch einen anderen Typ bekommen als die Haupt-Relation z.B. * lane_group für die Gruppe und * lane_object für die einzelne Spur. ? ist durchaus eine mögliche Lösung. Ich hätte der Einfachheit halber (Sonderfälle...) allerdings bislang daran gedacht, jede Lane nur einem der Highways zuzuordnen -- bei deinem Beispiel erscheint etwa der Grünstreifen in der Mitte als plausible Trennstelle. Auch eine Möglichkeit. Aber wenn dann die Grunfläche eine Area wird, dann wird das ultrakompliziert für Renderer etc. Andere Möglichkeit ist zu sagen das es zwei lane_groups mit jeweils einem highway sind wo nur rechts davon je ein Fußweg und ein Radweg angehängt sind... Brauchen wir dann denn überhaupt lane=cycleway oder könnte man dann nicht gleich wieder highway=cycleway machen? Bei den Straßen machen wir das ja auch nicht, obwohl wir in meinem Beispiel gerade zwei Straßen haben. Dein Ansatz hat leider relative viele Fehlerquellen, wo es nicht valide Ergebnisse gibt. z.B. mehrere nicht verbundene highway member. z.B. zwei Lanes mit der gleicher Nummer (liegen die dann übereinander?) Naja das gibt sich dann mit API 0.6 z.B. illegale Nummernwerte z.B. eins oder one Auch muß der Highway auf jeden Fall unterteilt werden, wenn sich die Anzahl der Spuren ändert (z.B eine Busspur / ein Fahrradweg dazu kommt). Geht der auswertenden Software damit Information verloren, an die ich bislang nicht gedacht habe? == Was würde das für Renderer und Tools bedeuten? == * Beim drehen einer Straße müsste evtl. die Relation angepasst werden, aber warum sollte jemand die Straßen drehen wollen Das ist ein wichtiger Punkt, an den ich bislang nicht gedacht habe -- solche Spuren gehören in der Tat zu den richtungsabhängigen Informationen. Weitere Punkte: * Joinen von Wegen bei dem nur einer Member der Relation ist. Programmiertechnisch ist das auch nicht wirklich simpel, um (wie bei opencycleway.org) die Radwege rechts und links einer Straße zu zeichnen muss man: 1. Testen ob eine lane_group Relation zum highway vorhanden ist 2. Alle Member der lane_group nach lane=cycleway durchsuchen 2a Wenn der Member ein Way ist entscheiden ob man den Verlauf vereinfacht oder selbst zeichnet 2b Wennn der Member eine Relation ist, anhand der Position in der Relation selbst rechts oder links vom highway zeichnen. BTW Es ist beim Entwurf noch nicht festgelegt wo die Mitte (der Member highway), in der lane_group ist. Hast du mal Probiert das für Osmarender umzusetzen? Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienb?ndeldiskussion (Re:Kreuzung Radweg)
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Dienstag, 30. Dezember 2008 10:15:23 schrieb talk-de-requ...@openstreetmap.org: Hallo, Sicher, nur diesen einfachen fall gibt es in der realit?t nur selten. Also hier in Aachen besteht dieser einfache Fall fast ausschlie?lich. Das ist aber f?r dich kein problem; denn du hast ja bereits verk?ndet, dass dich die wirkliche kreuzungssituation nicht interessiert. Der genaue Verlauf des Fahrradsweges interessiert mich dann wenn er mehr als sagen wir 10m vom 'normalen' Verlauf abweicht. bordsteinradwege haben zwischen kreuzungen gern verengungsstellen, wechseln den belag Ich habe noch nirgendwo gesehen, da? jemand Breiten eintr?gt, und wenn w?rde ich f?r einen Abschnitt jeweils die engste Stelle und den schlechtesten Belag nehmen. haben verschwenkungen an bushaltestellen Me?genauigkeit haben absperrungen zwischen fahrbahn und radweg Und wie taggst Du die bei separatem Radweg? MAchst Du dann einen Weg fence dazwischen? Wenn Ja OK. haben abweichende oneway-regelungen cycleway=opposite wechseln zwischen z240, z239, und Radfahrer absteigen Und wie tagst Du das? haben von der fahrbahn abweichende abbiegevorschriften. bei denen gibt es bereits ein exept und man sollte meiner Meinung nach noch ein only hinzuf?gen. Zum teil hast du das ja auch schon erkannt, aber zugleich sagst du nun, dass relationen die dinge komplizierter machen. Meine Erfahrung ist, 90% der Radwege verlaufen entweder auf der Fahrbahn oder unmittelbar daneben, und es tr?gt keiner Breiten oder Fahrbahnbelege ein. Diese 90% m?chte ich m?glichst einfach taggen. Alles andere darf dann komplizierter sein. Taggt man grunds?tzlich Fahrradwege,.. als eigene Wege ist alles kompliziert. Genau! lern, mit den endlichen ressourcen auszukommen. Sie reichen nicht, entweder sehen die Karten schlecht aus oder ein Router kann damit nichts anfangen. Genau! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anlieger?
On Wed, 31 Dec 2008, Johann H. Addicks wrote: Problem sind da eher die Anwohner, die spätestens wenn man das dritte Mal mit auswärtigem Kennzeichen durch dieselbe Nebenstraße kommt (lässt sich oft ja nicht vermeiden), die Köpfe nicht nur verschämt, sondern offensichtlich verdrehen nach dem Eindringling. Das passiert Dir auf dem Dorf schon, wenn Du auf der Hauptstraße langfährst :-) Und wenn Du die Straße bis zum Ende fährst und schon wieder mal mitten auf einem Bauernhof stehst, oder die Straße hinterm Hof sogar noch weitergeht, dann guckt man selbst etwas verwirrt. Meinem Bruder (auch Vermesser) hat mal der Bauer einen Misthaufen aus dem Weg geräumt, damit er zum TP weiterfahren konnte. Sachen gibts ... Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mappen von verzweigten Wegen
Sven S. Messenger: sven...@yahoo.de sven1971sommerk...@gizmo5.com Voip: sip: 17472402163 Am Dienstag, 30. Dezember 2008 17:28:19 schrieb talk-de-requ...@openstreetmap.org: LiLi, Wie mappe ich einen verzweigten Weg? Zum Beispiel in einem Wohngebiet, wenn die Stra?e pl?tzlich noch einen Abstecher macht, um einige zur?ckgesetzte H?user anzubinden? Oder wenn die Einfahrt in eine Stra?e von einer gr??eren Stra?e aus zwei Teilen (einmal von links, einmal von rechts) besteht? Zu sehen gibt es beides im Ort Herzhausen http://openstreetmap.org/?lat=50.95015lon=8.08453zoom=17layers=0B00TTF mfG, Peter Zunächst fällt mir mal auf das da wahrscheinlich etwas nicht stimmt.. Der Bach dort, heißt Dreisbach. Die Straße heißt, An der Dresibach? Was ist denn richtig? Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mapping Quality - Frage zur Bestimmung d er Größe eines Places - Tag?
hi, mir ist die idee gekommen, für places ein tag in die db einzugeben, sodass wir dann die größe des place in etwa wissen. das ist natürlich freiwillig und kann von denjenigen benutzt werden, denen meine radien im augenblick nicht passen. ich selbst eingeschlossen :-) ich dachte an radius=1.3 oder diameter=2.6 [in km] natürlich ist das dann immer noch kreisförmig, aber besser als das, was wir nun haben. ich würde mein programm dann trimmen, auf diese infos zu hören! und es könnte bestätigte radien in einer anderen farbe eintragen und die daten als gesichert oder so kennzeichnen. markus hatte den vorschlag gemacht, eine art siedlungsgrenze einzuführen, die alle gebiete (wohn, industrie etc.) umfasst. ist aber deutlich aufwendiger... ich weiß, es ist keine 100% lösung, aber schon viel besser, als nun... probleme machen mehr so die aneinandergrenzenden vororte, weniger frei gelegene orte. was haltet ihr davon? ciao gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel -- Vorschlag lane_grou p
Sven Anders schrieb: Können wir dann nicht wenigstens die Anzahl der Relationen begrenzen ala: 1. Hauptrelation mit highway member 2. Maximal eine weitere Ebene mit einer Relation pro Spur. Im Moment dürfte ich nach dem Vorschlag auch noch Unterrelationen von Unterlationen machen. Die Spur -Relation könnte dann auch einen anderen Typ bekommen als die Haupt-Relation Kann man zugunsten der Bearbeitbarkeit tun, zugegeben ist sonst eine Handhabung ohne Sondertools wirklich kaum mehr möglich. Hab das also mal vereinfacht: http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group In dieser Version besser? Die Spur-Relationen sind type=lane, die einzige gruppierende Relation ist vom Typ lane_group. ist durchaus eine mögliche Lösung. Ich hätte der Einfachheit halber (Sonderfälle...) allerdings bislang daran gedacht, jede Lane nur einem der Highways zuzuordnen -- bei deinem Beispiel erscheint etwa der Grünstreifen in der Mitte als plausible Trennstelle. Auch eine Möglichkeit. Aber wenn dann die Grunfläche eine Area wird, dann wird das ultrakompliziert für Renderer etc. Andere Möglichkeit ist zu sagen das es zwei lane_groups mit jeweils einem highway sind wo nur rechts davon je ein Fußweg und ein Radweg angehängt sind... Das ist die sonderfallfreiste Lösung, also würde ich das für den Moment empfehlen. (Die Busspur können wir trotzdem noch ranhängen, halt links in einer der beiden lane_groups.) Brauchen wir dann denn überhaupt lane=cycleway oder könnte man dann nicht gleich wieder highway=cycleway machen? Grund für den Lane-Key ist: a) nicht jeder Highway-Typ ist auch als Spur sinnvoll. Was ist eine secondary-Spur? Und kann sie auch in einem highway=motorway vorkommen? Und so weiter. Eigentlich gibt es eine Überlappung nur bei den highways, die in der Realität halt i.d.R. nur einspurig vorkommen (Fußweg, Radweg...), so dass kaum Spur und gesamter, einspuriger Verkehrsweg unterschieden werden können. b) Wenn sich ein Renderer entscheidet (sei es in einer Zoomstufe oder generell), auch als Way gezeichnete lanes nicht separat zu zeichnen, sondern sich auf die Highways zu beschränken, dann braucht er nicht auf Mitgliedschaft in irgendwelchen Relationen zu testen. Das vereinfacht das Schreiben eines Minimal-Renderers. Bei den Straßen machen wir das ja auch nicht, obwohl wir in meinem Beispiel gerade zwei Straßen haben. Eigentlich(TM) wäre eine Modellierung als ein Highway mit zwei Lanes und einem Separator dazwischen möglich. Ist aber nicht kompatibel mit Bestehendem und fehleranfällig, also betrachten wir das halt als 2 Straßen. Bei dieser Betrachtung sind dann auch 2 Lane-Groups konsequent. Dein Ansatz hat leider relative viele Fehlerquellen, wo es nicht valide Ergebnisse gibt. z.B. mehrere nicht verbundene highway member. z.B. zwei Lanes mit der gleicher Nummer (liegen die dann übereinander?) Naja das gibt sich dann mit API 0.6 z.B. illegale Nummernwerte z.B. eins oder one Die lassen sich tendenziell leicht von einem Validator feststellen. Punkt 2 und 3 haben sich ja hoffentlich bald erledigt. Es gibt aber zugegeben noch einige kritischere, etwa: tatsächlicher Verlauf der Ways passt nicht zu ihrer Anordnung in der Relation. So etwas lässt sich nicht ohne weiteres automatisiert prüfen. Auch muß der Highway auf jeden Fall unterteilt werden, wenn sich die Anzahl der Spuren ändert (z.B eine Busspur / ein Fahrradweg dazu kommt). Das müsste er bei fast allen Lösungen -- insbesondere auch bei Tag-basierten. Halte ich aber für akzeptabel. Weitere Punkte: * Joinen von Wegen bei dem nur einer Member der Relation ist. Nicht trivial, da hast du leider recht. Im Zweifel (beide Wege haben Lanes oder es sind Way-Lanes dabei) wird man wohl den Benutzer die Reaktion wählen lassen müssen. Programmiertechnisch ist das auch nicht wirklich simpel, um (wie bei opencycleway.org) die Radwege rechts und links einer Straße zu zeichnen muss man: 1. Testen ob eine lane_group Relation zum highway vorhanden ist 2. Alle Member der lane_group nach lane=cycleway durchsuchen 2a Wenn der Member ein Way ist entscheiden ob man den Verlauf vereinfacht oder selbst zeichnet 2b Wennn der Member eine Relation ist, anhand der Position in der Relation selbst rechts oder links vom highway zeichnen. Es wird einfacher, wenn man 2a pauschal entscheidet: * Wenn man immer nur einen gefärbten Rand zeichnen will, ist die Unterscheidung zwischen Relation und Way nicht nötig. * Wenn man Ways immer separat zeichnet, kann man das Randzeichnen auf Relationen beschränken und lane=cycleway wie highway=cycleway behandeln. Schwierig wirds in der Tat, wenn man Ways nur manchmal nicht separat zeichnen will. Das liegt aber nicht am Schema, sondern dürfte, so weit ich das sehe, ein inhärentes Problem beim Verwenden eigener Ways sein. BTW Es ist beim Entwurf noch nicht festgelegt wo die Mitte (der Member highway), in der lane_group ist. Nirgends, es sei denn, er ist nicht
Re: [Talk-de] Mappen von verzweigten Wegen
Wenn ich dort auch alle Tags eintrage, wird der Name extrem hässlich in diese Wege gerendert. Es gibt da irgendein Tag um das rendern zu unterbinden, komme aber gerade nicht drauf. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
Hallo, Allerdings würde man dabei halt etwas aus dem Rahmen fallen im Vergleich zu footway=right/left/both das auch Teil des Proposals ist cycleway=track/lane ist aber schon etabliert, deshalb würde ich versuchen dieses Schema auf footway auszuweiten statt es ganz neu zu machen. Aber von mir aus kann man auch ein Programm alles alte anpassen lassen. Wir sollten eine allgemeingültige Lösung für right/left finden, damit nicht bei jedem Tag das Seitenabhängig ist wieder die Editoren angepaßt werden müssen. Deshalb sollte meiner Meinung nach das right/left am Anfang notfalls am Ende aber nicht in der Mitte stehen. Dann können die Editoren alles was mit Left: beginnt beim drehen automatisch in Right: wandeln ohne den Tag kennen zu müssen. Meiner Meinung nach sollte es also so aussehen: Jedes Key/Value Paar das so für beide Straßenseiten gilt kann durch right/left ergänzt werden um sie auf eine Seite zu beschränken. Jedes Key/Value Paar das so nur für eine Straßenseiten gilt kann durch both ergänzt werden um sie auf beide Seiten zu beschränken. Nach dem aktuellen Proposalstand macht das aber nur bei footway Sinn, da footways bei einigen highway-Typen implizit vorhanden sind OK 'both' bezieht sich auf 'beide Seiten', nicht auf 'beide Richtungen'. Insofern ist es keine Alternative zu cycleway=opposite. Doch, zumindest für einen Teil, oft gibt es Einbahnstraßen mit Fahrradwegen auf beiden Seiten, da könnte man both nutzen, ist nur ein bidirektionaler Fahrradweg vorhanden wäre oneway:bicycle=no richtig. I.W.? Über die Kleinigkeiten diskutieren wir ja gerade ;-) Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mappen von verzweigten Wegen
Hallo. Am Mittwoch, 31. Dezember 2008 schrieb Dimitri Junker: Wenn ich dort auch alle Tags eintrage, wird der Name extrem hässlich in diese Wege gerendert. Es gibt da irgendein Tag um das rendern zu unterbinden, komme aber gerade nicht drauf. Nein. Es gibt Tags um IN OSMARENDER das Namens-Rendering zu verhindern. Was bitte bringt es, wenn in Osmarender etwas mehr oder weniger hässlich ist? Fast nur Mapper benutzen momentan die Osmarender-Karten. In Mapnik sieht sowas i.A. nicht hässlich aus. Bitte keine spezifischen Renderer-Tweaks in die Daten einbauen! Gruß, Bernd -- Wenn du kritisiert wirst, dann mußt du irgendetwas richtig machen. Denn nur derjenige wird angegriffen, der den Ball hat. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] right/left
Hallo, Ich habe mal ein Proposal geschrieben: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left Bitte schaut es Euch an und korigiert formale Fehler und diskutiert es. Und wo soll ich dies jetzt außer hier noch bekannt geben? Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
Dimitri Junker schrieb: Hallo, Allerdings würde man dabei halt etwas aus dem Rahmen fallen im Vergleich zu footway=right/left/both das auch Teil des Proposals ist cycleway=track/lane ist aber schon etabliert, deshalb würde ich versuchen dieses Schema auf footway auszuweiten statt es ganz neu zu machen. Aber von mir aus kann man auch ein Programm alles alte anpassen lassen. Würdest du also statt einfach footway=left lieber immer explizit footway=left:track schreiben wollen? Eigentlich fände ich cycleway=both auch etwas einleuchtender, da es direkt zeigt, dass es auf beiden Seiten ist. cycleway=track sagt das nicht aus. Etwas problematisch finde ich auch, dass bei cycleway=track/lane im Wiki nichtmal dabeisteht, dass der Radweg damit auf beiden Seiten ist. Aber wie soll man es sonst interpretieren? Raten auf welcher Seite er ist? Vielleicht wäre es doch besser etwas ganz Neues zu machen, wenn die bisherigen Tags so uneindeutig sind. Wenn du mit alles alte anpassen die Daten in der Datenbank direkt meinst, da halte ich eigentlich nichts davon, da man nicht einfach so in die Arbeit von anderen reinpfuschen sollte. Wir sollten eine allgemeingültige Lösung für right/left finden, damit nicht bei jedem Tag das Seitenabhängig ist wieder die Editoren angepaßt werden müssen. Deshalb sollte meiner Meinung nach das right/left am Anfang notfalls am Ende aber nicht in der Mitte stehen. Dann können die Editoren alles was mit Left: beginnt beim drehen automatisch in Right: wandeln ohne den Tag kennen zu müssen. Meiner Meinung nach sollte es also so aussehen: Jedes Key/Value Paar das so für beide Straßenseiten gilt kann durch right/left ergänzt werden um sie auf eine Seite zu beschränken. Jedes Key/Value Paar das so nur für eine Straßenseiten gilt kann durch both ergänzt werden um sie auf beide Seiten zu beschränken. Da bin ich dagegen. Ich sehe kein Problem darin einfach die gesamten Schlüssel und Werte nach left/right zu durchsuchen und jeweils zu tauschen. Da man sowieso gefragt werden sollte ob man die Werte wirklich tauschen will, ist es auch nicht so schlimm wenn man mal etwas erwischt das nicht richtungsabhängig ist. Zumal man Wege auch nicht so häufig dreht. Davon ausnehmen könnte man auch Dinge die freien Text enthalten wie note, FIXME oder name. Alle anderen Schlüssel die left/right enthalten dürften dann auch tatsächlich richtungsabhängig sein. Dagegen bin ich, da es die Hierarchie durchbricht. Ich finde es besser wenn alle Schlüssel die sich auf cycleway beziehen auch mit cycleway beginnen. So hat man dann: cycleway=track cycleway:left.width=1.5 cycleway:right.width=2.5 Statt: cycleway=track left:cycleway.width=1.5 right:cycleway.width=2.5 Zumal auch noch Tags dazwischen auftauchen können, da die Tags in den Editoren meist alphabetisch geordnet sind. Würde man als Hauptschlüssel left und right nehmen, dann wäre es etwas anderes. Dann wäre eben die linke und rechte Straßenseite der Hauptschlüssel, statt der Radweg: left=cycleway:track right=cycleway:track left:cycleway.width=1.5 right:cycleway.width=2.5 Oder auch: both=cycleway:track left:cycleway.width=1.5 right:cycleway.width=2.5 Oder auch (da man sonst ja nur einen Weg angeben kann, da der Schlüssel 'both' nur einmal vorkommen darf): both:cycleway=track left:cycleway.width=1.5 right:cycleway.width=2.5 Allerdings könnte man dann auch so Scherze machen wie: both:cycleway=track left:cycleway=lane right:cycleway=track right:footway=track Was bedeutet das dann? Mit cycleway, track und footway muss man auf maximal drei Tags schauen, um zu wissen was überhaupt vorhanden ist. Etwas weiter schauen muss man dann, um die Eigenschaften der Wege zu erfahren, also ob es lane/track ist, die Breite oder was auch immer noch interessant sein könnte. 'both' bezieht sich auf 'beide Seiten', nicht auf 'beide Richtungen'. Insofern ist es keine Alternative zu cycleway=opposite. Doch, zumindest für einen Teil, oft gibt es Einbahnstraßen mit Fahrradwegen auf beiden Seiten, da könnte man both nutzen, ist nur ein bidirektionaler Fahrradweg vorhanden wäre oneway:bicycle=no richtig. Aber ein cycleway=* (außer opposite) definiert immer eine irgendwie zur restlichen Fahrbahn seperaten Radweg. cycleway=opposite gibt eigentlich nur Einbahnstraßen zur Verwendung für Radfahrer in die Gegenrichtung frei, also Einfahrt verboten mit Radfahrer frei. Eigentlich ein unlogischer Tag, eher eine Behelfslösung. Sowas wie oneway:bicycle=no wäre doch viel konsistenter und logischer. I.W.? Über die Kleinigkeiten diskutieren wir ja gerade ;-) Ich wollte eigentlich wissen was I.W. bedeutet.. ;) Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hinweise zur Qualitätskontrolle bei ecki gen Straßenverläufen
Über die stille Zeit zwischen den Jahren habe ich mal ein wenig Gelegenheit gefunden, mich an den Rechner zu setzen und das vor ein paar Wochen diskutierte Thema eckiger Verläufe aufgearbeitet. Wenn Ihr verlegen um ein paar Anregungen seid, hier ist ein kurzes Protokoll: http://derwisch.wikidot.com/blog:coarsehighways. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] INFAS Kreisgrenzen
Bernd Wurst schrieb: Hallo. Am Mittwoch, 31. Dezember 2008 schrieb Frederik Ramm: Ich habe den Import jetzt angestossen, allerdings geht der Upload doch etwas gemächlich, so dass der groesste Teil des 31.12. wohl noch damit herumgeht, die Daten hochzuladen. Die Nodes sind bei mir schon da, der Way darauf noch nicht. ;-)) Ich bin gespannt. :) Ich hab auch gerade bei mir ein paar Taglose, Waylose Nodes gefunden und war kurz davor die einfach zu löschen. Da hab ich mir grad noch angeschaut, wer die denn erstellt hat und als ich Geofabrik las wusste ich gleich Lass das in Frieden, das passt schon so. Also Glück gehabt, will gar nich wissen was der Bot macht wenn er die ways erstellen will und die nodes sind weg. Euch allen einen guten Rutsch und ein schönes 2009. Jannis ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Your whishlist for Debian Packages?
Am Dienstag 30 Dezember 2008 schrieb Joerg Ostertag (OSM Tettnang/Germany): On Dienstag 30 Dezember 2008, Rainer Dorsch wrote: Am Dienstag, 30. Dezember 2008 schrieb Joerg Ostertag (OSM Tettnang/Germany): Repository for lenny (testing) /etc/apt/sources.list # Gpsdrive Packages deb http://www.gpsdrive.de/debian etch main deb-src http://www.gpsdrive.de/debian etch main Soll das wirklich etch (für lenny?) heißen? Ja, denn noch gibt es von allem nur debian-testing packages (Das ist noch Altlast aus der Zeit als etch das debian-testing war). Aber da bin ich grad am schrauben, damit das repository dann auch wirklich mit den Namen das reflektiert, was auch wirklich drin ist. wenn du schon beim schrauben bist: es waere toll, wenn pakete die icons, skripte, und andere plattformunabhaengige dinge enthalten, auch als solche gekennzeichnet sind. sonst krieg ich das alles nur auf x86 installiert, und z.B. nicht auf armel... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hinweise zur Qualitätskontrolle bei ec kigen Straßenverläufen
hi, sehr schön, habe es gleich mal auf den QA seiten des wiki eingetragen. ciao gerhard gary68 Am Mittwoch, den 31.12.2008, 14:28 +0100 schrieb Johannes Huesing: Über die stille Zeit zwischen den Jahren habe ich mal ein wenig Gelegenheit gefunden, mich an den Rechner zu setzen und das vor ein paar Wochen diskutierte Thema eckiger Verläufe aufgearbeitet. Wenn Ihr verlegen um ein paar Anregungen seid, hier ist ein kurzes Protokoll: http://derwisch.wikidot.com/blog:coarsehighways. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frohes Neues Jahr!
Wer es noch nicht gesehen hat; seit heute ist das Neu-Jahrs-Geschenk von ITO verfügbar! Ein Video mit den Edits des Jahres. Sehr beeindruckend das ganze und ein wenig stolz macht es auch. http://www.vimeo.com/2598878 In diesem Sinne Rutscht gut Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frohes Neues Jahr!
Toll! Torsten Breda schrieb: Wer es noch nicht gesehen hat; seit heute ist das Neu-Jahrs-Geschenk von ITO verfügbar! Ein Video mit den Edits des Jahres. Sehr beeindruckend das ganze und ein wenig stolz macht es auch. http://www.vimeo.com/2598878 In diesem Sinne Rutscht gut Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de begin:vcard fn:Dr. Franz-Josef^Behr n:Behr;Franz-Josef org:Stuttgart University of Applied Sciences (SUAS);Faculty of Geomatics, Computer Science and Mathematics adr;quoted-printable:;;Schellingstra=C3=9Fe 24, ;Stuttgart;;D-70174;Germany title:Prof. tel;work:+49) 711/8926-2606 tel;home:+49 (0)721 / 453980-1 url:http://www.hft-stuttgart.de/ version:2.1 end:vcard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hallo, leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben und weil dieser halt nun doch laenger dauert, massiv Nodes, die noch nicht zu Ways verbunden wurden. Ich habe die alle angemailt und stelle die Nodes wieder her, aber falls jemand die User Ropino und Stefano kennt und mal direkt anrufen/anmailen kann, das waere hilfreich - die haben zusammen naemlich schon ueber 1000 Nodes geloescht ,-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Frederik Ramm schrieb: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben Hi Frederik, sind die Nodes denn nicht mit einem entsprechenden Hinweis versehen? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linienbündel, Radwege
Dimitri Junker schrieb: Wenn nämlich nachher doch alle Arbeit umsonst ist, stelle ich meine Mitarbeit lieber gleich ein. Mach es so wie Du es für sinnvoll hälst, shreib ggf. irgendwas als note rein, so daß Du sie einfach wiederfindest, wenn wir dann mal einen Konsens gebildet haben kannst Du sie anpassen, alles was bisher nicht tagbar ist kannst Du entweder provisorisch in eigene Tags schreiben oder auch ins Note cycleway=lane:right bzw. cycleway=lane:left getaggt, Ich wollte mal ein Proposal zu right/left machen, hab aber noch nie ein Proposal geschrieben. Ich vermute, daß es programiertechnisch geschickter ist das right/left vor den Value zu schreiben, also cycleway=left:lane Aber da werde ich die unterschiedlichen Varianten zur Diskussion stellen. Eine solche Radspur ist standardmäßig nicht für Fußgänger zugelassen, sonst foot=yes. das müßte dann um in Deiner Nomenklatur zu bleiben cycleway=foot:yes. sein, sonst kann man ja nicht unterscheiden ob Fußgänger auf diesem Fahrradweg oder auf dem daneben liegendem Bürgersteig gehen dürfen. Radweg, der von der Straße nur durch eine Kante wie eine Bürgersteigkante abgetrennt ist, insbesondere im innerstädtischen Bereich. Häufig unterbrochene schmale (1m) Grünstreifen oder Parkstreifen würde ich auch noch erlauben. Bei optisch getrenntem Rad/ Fußweg (Zeichen 241) wird segregated=yes ergänzt, Wo ist segregated definiert? Ist klar, daß es sich auf den Fußgänger-/Fahrradweg bezieht? sonst wieder: cycleway=segregated:yes. Ansonsten würde ich dafür stimmen Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ich weiß ich Wiederhole mich, aber eine Lane-Relation (mit Hilfe des Plugins für JOSM z.B.) ist IMO noch die effektivste und eindeutigste Methode diese Detaildaten zu erfassen. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hallo. Am Mittwoch, 31. Dezember 2008 schrieb Chris-Hein Lunkhusen: sind die Nodes denn nicht mit einem entsprechenden Hinweis versehen? Die Nodes sind ungetagged. Tags kommen dann an die zugehörigen Ways. Das ist eigentlich durchaus normal, nur dauert es hier scheinbar einfach etwas arg lang bis die Ways mit den Infos hochgeladen sind. Wenn man das vorher gesehen hätte, wäre es vermutlich so gemacht worden, dass man nicht erst alle nodes und dann die Ways dazu hochläd sondern immer erst ein paar Nodes, dann den betreffenden Way. Aber jetzt alles nochmal von vorne zu starten wäre auch unoptimal. Gruß, Bernd -- Mein Computer kann 1000 falsche Daten in einer Sekunde sortieren. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hallo, Chris-Hein Lunkhusen wrote: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben Hi Frederik, sind die Nodes denn nicht mit einem entsprechenden Hinweis versehen? TomH würde mir was husten, wenn ich 600.000 Nodes mit jeweils langwieriger Erklaerung hochladen wuerde ;-) - im Nachhinein war es ungeschickt von mir, den Import in einem Rutsch zu machen, ich haette lauter einzelne Nodes und dann immer gleich die dazu passenden Ways hochladen sollen statt erst alle Nodes und spaeter alle Ways. Durch den grossen Zeitabstand gibt es nun diese Probleme, die man sonst vermeiden haette koennen... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hi, Frederik Ramm wrote: falls jemand die User Ropino und Stefano kennt und mal direkt anrufen/anmailen kann Hat sich erledigt, danke. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Frederik Ramm schrieb: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben und weil dieser halt nun doch laenger dauert, massiv Nodes, die noch nicht zu Ways verbunden wurden. Da haben sich auch ein paar Leute schon im Forum beschwert, dass sie nichts davon mitbekommen haben, ich würde daher davon ausgehen, dass Nicht-Mailinglistenleser da tatsächlich unzureichend informiert wurden. Solche Löschungen sind leider also durchaus nicht verwunderlich. http://forum.openstreetmap.org/viewtopic.php?pid=12770#p12770 Tobias Tordanik Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Hi, On Wed, Dec 31, 2008 at 06:44:56PM +0100, Tobias Knerr wrote: Frederik Ramm schrieb: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben und weil dieser halt nun doch laenger dauert, massiv Nodes, die noch nicht zu Ways verbunden wurden. Da haben sich auch ein paar Leute schon im Forum beschwert, dass sie nichts davon mitbekommen haben, ich würde daher davon ausgehen, dass Nicht-Mailinglistenleser da tatsächlich unzureichend informiert wurden. Solche Löschungen sind leider also durchaus nicht verwunderlich. http://forum.openstreetmap.org/viewtopic.php?pid=12770#p12770 Weil ich eh gerade schlechte laune habe - Haben die leute die hier wirklich etwas machen und sich engagieren eigentlich fuer den letzten mapper dieser Erde eine bringschuld? Gibs auch schon eine Liste von Tageszeitugnen wo das veroeffentlicht werden muss? Oder koennten nicht alle die sich unterinformiert fuehlen hier gleich ihre twitterid, icqid, yahoo, aim, msn, openid, mailaddress, telefonnummer, pagernummer etc angeben. Dann koennte ich vorher mich mal eben hinsetzen und jeden Persoehnlich abholen. Flo der wohl bald jedem den Arsch einzeln abwischt -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
der Workaround mit dem JOSM-lane-plugin wäre - Weg auswählen. - lane links hinzufügen - lane rechts hinzufügen - attribute setzen - fertig und damit hätten wir eine ziemlich genaue Darstellung der Realität im Rahmen der möglichen Genauigkeit (5m) Dann könnte man jeder Spur Atrribute wie Breite, maxspeed, direction, etc. geben. Wenn der Radweg dann einen krassen Schlenker (z.B. weil er in einer Spirale ein Level hoch runter (Tunnel/Brücke) geführt wird, oder einfach da chaotisch sich von der STraße abwendet, dann zeichnet man ab dieser Stelle eben einen seperaten cycleway. Manchmal verstehe ich nicht, warum die Leute so komplitziert denken ;-) Guten Rutsch euch allen :-) -- Mario Sebastian Hohmann schrieb: Dimitri Junker schrieb: Versteh ich nicht. Das gibt doch nur an auf welcher Seite der Radweg liegt. Oder bemängelst du damit, dass man zusätzlich noch cycleway.type=lane angeben muss? Bisher haben wir zum Key cycleway u.a. track und lane. Das von Dir vorgeschlagene right/left ist keine Alternative dazu sondern ein Zusatz. Man muß angeben können, daß der rechte Fahrradweg ein lane und der linke ein track ist. Deshalb z.B. cycleway=left:track Ein cycleway.type=lan würde da auch nicht helfen. Natürlich könnte man auch optional einen Wert wie left:track definieren, um gleich beide Informationen auf einmal angeben zu können. Man muß sie zusammen angeben, weil es ja 2 Fahrradwege geben kann. Also wenn es dir nur darum geht, dann ist es kein Problem. cycleway.type=lane setzt den Typ auf alle cycleways, egal ob man nun right/left oder auch both angegeben hat. Möchte man nur für eine Seite den Typ angeben (das macht nur bei 'both' Sinn), dann kann man dies mit cycleway:right.type=lane machen. Das Ganze ist halt quasi hierarchisch aufgebaut: both - right - left Lässt man die Angabe von right/left im Schlüssel weg, wird automatisch 'both' angenommen. cycleway.width=2.5 setzt also die Breite für 'both' und 'vererbt' es an 'right' und 'left'. Was zuvor mit cycleway=right/left/both/none angegeben wurde ist dabei egal, es setzt einfach die Breite für beide Seiten. Wenn auf einer Seite keiner vorhanden ist, wirkt es sich logischerweise eben nur auf eine Seite aus. Gibt man keinen 'type' an, wird automatisch angenommen, dass es sich um einen 'track' handelt. Willst du allerdings den Typ ohne ein extra-Tag angeben, könnte man natürlich auch sowas wie left:lane benutzen. Allerdings würde man dabei halt etwas aus dem Rahmen fallen im Vergleich zu footway=right/left/both das auch Teil des Proposals ist und bei dem 'lane' wohl eher selten vorkommt. Nimmt man weiterhin zusätzlich an, dass ein Weglassen des Types automatisch ein 'track' ist, hätte man eben statt 4-Hauptwerten plötzlich 7: right/left/both/none/right:lane/left:lane/both:lane. Zusätzlich müsste man dann noch die bisherigen cycleway=track/lane mit einberechnen, die einen Radweg des jeweiligen Typs auf beiden Seiten definieren. Man hat dann also z.B.: - cycleway=lane für 'lane' auf beiden Straßenseiten - cycleway=both für 'track' auf beiden Straßenseiten - cycleway=right:lane für 'lane' rechts - cycleway=right für 'track' rechts Allerdings wären andere Schreibweisen wohl auch gültig, also: - cycleway=right:track für 'track' rechts - cycleway=both:track für 'track' auf beiden Straßenseiten usw. Das kann man natürlich auf die Spitze treiben. Und da sind noch nichtmal footway und path mit dabei. Das kommt halt davon wenn man zum einen versucht bisherige Tags zu berücksichtigen und es zusätzlich auch noch versucht 'einfacher' zu machen indem viele Werte impliziert werden. :) Ob man das will ist halt die Frage, das macht irgendwie alles noch komplizierter, sowohl für den Mapper als auch den Benutzer. Wobei der Mapper es natürlich auch als angenehmer weil kürzer empfinden könnte. Aber wiegesagt, irgendwie fällt es so aus dem Rahmen. Die Renderer könnte z.B. anstatt Regeln für alle Fälle zu erstellen die Wege vor dem Rendern in ein einheitliches Schema umschreibem, so wie sie es eben brauchen. Alternativ könnte man natürlich auch ganz streng sein und sagen: Wir geben immer einen Typ an. Also: - cycleway=lane für 'lane' auf beiden Straßenseiten - cycleway=track für 'track' auf beiden Straßenseiten - cycleway=right:lane für 'lane' rechts - cycleway=right:track für 'track' rechts Somit hätte man das bisherige Tagging beachtet und gleichzeitig nicht mehr so viele Ausnahmen. Oder man macht es halt einfach so wie in meinem Proposal. Was ist nun besser? Man weiß es nicht. :) cycleway=none/both:track/right/.. sollte dann aber auch möglich sein. Der Nutzen von none ist mir noch nicht klar, both wäre z.B. bei Einbahnstraße sinnvoll als bessere Alternative zu cycleway=opposite 'none' sagt einfach aus, dass sich dieser Typ nicht an der Straße befindet. Nach dem aktuellen
Re: [Talk-de] Fläche von Polygon berechnen?
Gary G: schrieb: hi, hat jemand einen algorithmus zum berechnen der (ungefähren) fläche eines polygons (gegeben durch lon/lat nodes) unter der berücksichtigung, dass die erde keine scheibe ist? perl wäre super, anderes ebenfalls willkommen! Hallo Gary, wenn du dir die komplizierte Berechnung auf einem Ellipsoid sparen willst, kannst du auch die Positionen in GK umrechnen. Dann ist die Gauß'sche Trapezformel ein Klacks: http://de.wikipedia.org/wiki/Gaußsche_Trapezformel Hat halt den Nachteil, dass es dort die Umrechnung der Koordinaten langsamer ist und du musst für GK den richtigen Meridian ermitteln. Sonst wirds mit wachsender Entfernung zum gewählten Meridian immer ungenauer. VG, ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Quality - Frage zur Bestimmung der Gr öße eines Places - Tag?
Am 31.12.08 schrieb GS gerhardschw...@yahoo.de: hi, mir ist die idee gekommen, für places ein tag in die db einzugeben, sodass wir dann die größe des place in etwa wissen. das ist natürlich freiwillig und kann von denjenigen benutzt werden, denen meine radien im augenblick nicht passen. ich selbst eingeschlossen :-) ich dachte an radius=1.3 oder diameter=2.6 Ich halte place_radium für besser, damit man sieht daß es sich der Radius bzgl des place-tags ist und nicht von irgendwas anderem (z.B. highway=mini_roundabout;radius=10). Macht die Suche einfacher, da man weniger unpassende rausfiltern muss. [in km] natürlich ist das dann immer noch kreisförmig, aber besser als das, was wir nun haben. ich würde mein programm dann trimmen, auf diese infos zu hören! und es könnte bestätigte radien in einer anderen farbe eintragen und die daten als gesichert oder so kennzeichnen. markus hatte den vorschlag gemacht, eine art siedlungsgrenze einzuführen, die alle gebiete (wohn, industrie etc.) umfasst. ist aber deutlich aufwendiger... ich weiß, es ist keine 100% lösung, aber schon viel besser, als nun... probleme machen mehr so die aneinandergrenzenden vororte, weniger frei gelegene orte. was haltet ihr davon? Schau mal auf http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing#City da ist zusammengefasst, wie das momentag läuft. Ich halte es für eine gute Idee, für den Fall, daß man nicht mal ein ungefähres Polygon um den Ort ziehen kann. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
Florian Lohoff schrieb: Hi, On Wed, Dec 31, 2008 at 06:44:56PM +0100, Tobias Knerr wrote: Frederik Ramm schrieb: leider löschen einige (rund 20) User, offenbar weil sie nichts von dem Import mitbekommen haben und weil dieser halt nun doch laenger dauert, massiv Nodes, die noch nicht zu Ways verbunden wurden. Da haben sich auch ein paar Leute schon im Forum beschwert, dass sie nichts davon mitbekommen haben, ich würde daher davon ausgehen, dass Nicht-Mailinglistenleser da tatsächlich unzureichend informiert wurden. Solche Löschungen sind leider also durchaus nicht verwunderlich. http://forum.openstreetmap.org/viewtopic.php?pid=12770#p12770 Weil ich eh gerade schlechte laune habe - Haben die leute die hier wirklich etwas machen und sich engagieren eigentlich fuer den letzten mapper dieser Erde eine bringschuld? Gibs auch schon eine Liste von Tageszeitugnen wo das veroeffentlicht werden muss? Oder koennten nicht alle die sich unterinformiert fuehlen hier gleich ihre twitterid, icqid, yahoo, aim, msn, openid, mailaddress, telefonnummer, pagernummer etc angeben. Dann koennte ich vorher mich mal eben hinsetzen und jeden Persoehnlich abholen. Eigentlich dachte ich ja, du hättest hier übertrieben. Aber wenn ich den Forumsthread lese, bist du fast komplett an der Realität drann. Wenn man das/die Prinzipien von OSM (es gibt eigentl. nur eine handvoll) nicht verstanden hat bzw. verstehen will und auch sonst nicht lernbereit ist, dann ist wirklich nicht zu helfen. Da ist nichts konstruktives bzw. halbwegs objektives dabei, da hab ich dann auch keine Lust mehr zu helfen. Allen anderen positiv eingestellen, motivierten Lesern ein erfolgreiches (OSM-) Jahr 2009! Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] INFAS Kreisgrenzen
Hallo, Frederik Ramm wrote: Ich habe den Import jetzt angestossen, allerdings geht der Upload doch etwas gemächlich, so dass der groesste Teil des 31.12. wohl noch damit herumgeht, die Daten hochzuladen. Parallel beginne ich mit dem Umtaggen der existierenden Daten. Schaun wir mal... Die Nodes haben rund 20 Stunden gedauert, die Ways und Relations waren dann fix, so dass der Import noch 2008 abgeschlossen war. Während der Import lief, habe ich ständig anhand der stündlichen Diffs kontrolliert, ob jemand importierte Nodes gelöscht hat, und diese dann wiederhergestellt (samt Nachricht an den Löscher). Insgesamt haben rund 30 verschiedene Leute rund 2500 Nodes gelöscht. Das war fuer mich zwar unerfreulich, aber andererseits ist es ein imposanter Beweis dafuer, wie viel mit unseren Daten gearbeitet wird. Das laesst hoffen, dass z.B. ein Akt von Vandalismus tatsaechlich sehr schnell bemerkt und beseitigt wuerde. - Am Ende ging fast alles gut, einige Ways haben noch Handarbeit gebraucht. Nun haben wir rund 650.000 Nodes, 1.500 Ways und 400 Relations mehr. Ich habe mir das Ergebnis noch gar nicht im Inspector Co. angeschaut. Von den manuellen Korrekturen abgesehen muessten die Aenderungen alle noch im Jahreswechsel-Diff gelandet sein, so dass sie am fruehen Nachmittag des 1.1. im Inspector und auch in den Geofabrik-Downloadfiles aufschlagen sollten. Jetzt hoffe ich mal, dass nicht irgendwo noch ein systematischer Fehler drin steckte ;-) Die Kreisreformen Sachsen und Sachsen-Anhalt haben wir insofern in die Daten eingebaut, als dass alle Kreiszusammelegungen beruecksichtigt wurden; die komplizierteren Aenderungen (Kreis Neu-1 bekommt die Stadt X aus Kreis Alt-2, der Rest von Alt-2 wird Kreis Neu-3 zugeschlagen) aber nicht, hier ist also im einen oder anderen Fall noch Handarbeit noetig, und zwar: Sachsen-Anhalt: Aufteilung von Aschersleben-Stassfurt auf LK Harz und Salzlandkreis (beide neuen Kreise schon angelegt). Anhalt-Zerbst aufteilen und LK Anhalt-Bitterfeld neu anlegen (+Bitterfeld +Koethen). Stadt Dessau-Rosslau neu anlegen. Sachsen: sollte alles komplett sein; hier ist aber die Staatsgrenze bei Görlitz zu prüfen, eventuell sind die alten Daten hier z.T. besser als die neuen, die ab und zu auf unvermittelt die Flussuferseite wechseln. Wie gewünscht, ist der gesamte Umriss von Wesel vom Import ausgenommen worden. Dadurch sind alle Kreise, die an Wesel anschliessen, unvollständig; die vorhandenen Grenzlinien von Wesel müssen von Hand in die entspr. Relationen eingefügt werden. Wenn irgendjemand irgendwo ein Problem mit dem Import hat und partiell einen alten Zustand wiederhergestellt wuenscht - das laesst sich machen. Die Diskussion im Forum ist höchst unerfreulich, aber ich sehe mich ausserstande, neben dieser Mailingliste auch noch Foren zu verfolgen. Ich verlasse mich darauf, dass es immer ein paar Wanderer zwischen den Welten gibt, die wichtige Informationen in beide Richtungen transportieren. Eventuell brauchen wir eine Super-Wichtig-Haupt-Master-Ankündigungs-Seite im Wiki, und jeder wird gezwungen, sich da einen RSS-Feed von einzufangen ;-) so dass jeder sein gewohntes Medium (Forum, IRC, Mailingliste, Wiki, was weiss ich) weiter nutzen kann, aber alle wenigstens diese Ankuendigungsseite lesen. Ich mache mir allerdings keine Illusionen - auch mit so einer Ankuendigung haette es noch Beschwerden gegeben. Und wer ist dann zustaendig, um wichtige Infos der Englaender auf die Super-Wichtig-Haupt-Master-Ankuendigungs-Seite zu schreiben? Da brauchen wir wieder die Wanderer... So, jetzt bin ich gespannt, wie die Sache aussieht, wenn sich der Staub gelegt hat. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen-Import / gelöschte Nodes
John07 schrieb: http://forum.openstreetmap.org/viewtopic.php?pid=12770#p12770 Weil ich eh gerade schlechte laune habe - Haben die leute die hier Eigentlich dachte ich ja, du hättest hier übertrieben. Oh, ich werde mich nie wieder über Diskussionskultur hier beschweren. Dort geht's fast so zu wie in den Heise-Foren. Ein frohes Neues! -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?Kreisgrenzen-Import / gelöschte Nodes
Johann H. Addicks addi...@gmx.net wrote: Oh, ich werde mich nie wieder über Diskussionskultur hier beschweren. Dort geht's fast so zu wie in den Heise-Foren. Ähm ja, wie war das mit der Realnamendiskussion auf der Mailingliste... The History repeating... Warum zum Teufel denken die Leute Webforen seien besser als Mailinglisten oder Usenetgruppen? Ich werd alt. n8 Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Quality - Frage zur Bestimmung d er Größe eines Places - Tag?
hi, also radium gibt es nicht, außer latein vielleicht? und, bei anderen dingen schreiben wir auch immer name= und nicht highway_name= amenity_name= etc. meiner meinung nach ist ein standardisiertes tag über alle ways und nodes sinnvoll. weiterhin ist die information redundant! wenn ich einen node mit place=X habe, dann brauche ich die info place nicht auch noch im namens-tag des selben nodes! kartenzeichnern wird es unheimlich schwer gemacht, weil sie überall nach anderen tags suchen müssten! ps: habe einige places in deutschland gefunden, die mit place_name= getaggt sind. finde ich nicht gut! es gibt in deutschland ~51.000 places, davon sind nur 450 mit place_name keys versehen. also weniger als 1%. pps: amenity_name gibt es in deutschland z.b. gar nicht! ciao gerhard Am Mittwoch, den 31.12.2008, 21:51 +0100 schrieb Marcus Wolschon: Am 31.12.08 schrieb GS gerhardschw...@yahoo.de: hi, mir ist die idee gekommen, für places ein tag in die db einzugeben, sodass wir dann die größe des place in etwa wissen. das ist natürlich freiwillig und kann von denjenigen benutzt werden, denen meine radien im augenblick nicht passen. ich selbst eingeschlossen :-) ich dachte an radius=1.3 oder diameter=2.6 Ich halte place_radium für besser, damit man sieht daß es sich der Radius bzgl des place-tags ist und nicht von irgendwas anderem (z.B. highway=mini_roundabout;radius=10). Macht die Suche einfacher, da man weniger unpassende rausfiltern muss. [in km] natürlich ist das dann immer noch kreisförmig, aber besser als das, was wir nun haben. ich würde mein programm dann trimmen, auf diese infos zu hören! und es könnte bestätigte radien in einer anderen farbe eintragen und die daten als gesichert oder so kennzeichnen. markus hatte den vorschlag gemacht, eine art siedlungsgrenze einzuführen, die alle gebiete (wohn, industrie etc.) umfasst. ist aber deutlich aufwendiger... ich weiß, es ist keine 100% lösung, aber schon viel besser, als nun... probleme machen mehr so die aneinandergrenzenden vororte, weniger frei gelegene orte. was haltet ihr davon? Schau mal auf http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing#City da ist zusammengefasst, wie das momentag läuft. Ich halte es für eine gute Idee, für den Fall, daß man nicht mal ein ungefähres Polygon um den Ort ziehen kann. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Erfahrung Strato virtual server?
hi, hat jemand hier erfahrungen in dem bereich? vor allem würde mich interessieren, was die sterne bei prozessor power bedeuten. und wie ist das mit max ram. wie wahrscheinlich ist es, dass ich das auch bekomme... tnx gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] kleines script, um älteste dateien z u finden?
hi, ich hätte gerne ein linux script, dass mir aus einem verzeichnis und seinen unterverzeichnissen eine liste mit den files, sortiert nach datum ausgibt. ich bin sicher, da kommt ein kurzes script raus, aber soweit bin ich mit meinem linux noch nicht :-) ls -lrtR geht in die richtung, gruppiert aber nach verzeichnissen... tnx gary68 gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
