Re: [Talk-de] Zeitverschiebung auf der Karte
Am 15.01.2014 12:28, schrieb Sven Geggus: Sebastian Kurt sebastian.k...@gmail.com wrote: a) Wäre es aber nicht möglich genau diese Daten mit zu erfassen/speichern? OSM hat schließlich auch ganz andere Daten, zB ob Laternen funktionieren oder die Art eines Automaten. Es gibt einen Tag für den Startzeitpunkt, finde ich gerade nicht. Jup, es gibt die Tags bereits. Ich weiß aber nicht, ob die Renderer das dann auch schon ausblenden. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falk Verlag zeigt auch OSM Karten
Hallo, vor allen Dingen sollte man anbei noch erwähnen, dass der Stil von Falk in meinen Augen sehr gelungen ist. Leider ist der Datenbestand aber schon ein paar Monate alt. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Webservice um Kacheln zu verschmelzen
Was spricht eigentlich gegen Walking Papers? Die kann man meines wissens nach sogar einscannen und dann als Hintergrund in Josm benutzen. http://walking-papers.org/ Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D Mapping fürBahnhöfe
Thank you, I'll look into that tomorrow or on Thursday. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D Mapping für Bahnhöfe
Am 04.08.2013 09:29, schrieb Stephan Knauss: Ich würde gerne alle Interessierten dazu Aufrufen sich hier Gedanken zu machen wie das in OSM abgebildet werden kann. Die Einstiegsseite scheint mir das hier zu sein: https://wiki.openstreetmap.org/wiki/Indoor_Mapping Stephan Hallo Stephan, danke, dass Du das Thema hier einmal auf die Tagesordnung bringst. Man merkt den Tools um OSM herum derzeit noch massiv an, dass sie nicht für das Gebäudemapping vorgesehen sind. Bisher geht es hauptsächlich um das Erfassen von Straßen und Arealen. Ich würde mir für JOSM ein Plugin wünschen, dass hier einiges an Erleichterung bringt. Wichtig wäre hier das Ausblenden der Gebäudeinnereien im Standardmodus und ein spezieller Gebäudemodus, der dann nur noch die Außenmauern anzeigt und eine Ansicht mit den einzelnen Stockwerken, für die man dann jeweils einen eigenen Plan angezeigt bekommt. Außerdem sollte das Anbringen von OSM3D-Tags deutlich vereinfacht werden. Die derzeitig verwendeten Vorlagen bieten hier keine wirklich brauchbare Lösung, da sich der Funktionsumfang der fünf oder sechs angebotenen Modi teils überschneidet. Optimal wäre eine integrierte Lösung, wo man für Dachformen, Farben und Materialien eine vereinheitlichte Maske mit bildlicher Darstellung hätte. Genial wäre eine Echtzeitansicht in Form einer kleinen Vorschau im rechten Bereich (z.B. eine eingebettete Kendzi3D-Ansicht). Ich denke, gerade in Richtung 3D-Mapping gibt es noch erhebliche Anstrengungen zu unternehmen, bis das wirklich flutscht. Daher finde ich es um so begrüßenswerter, dass mal wieder eine Diskussion angestoßen wurde. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spurassistent / lanes / turn
Am 05.07.2013 17:18, schrieb chris66: Am 05.07.2013 16:22, schrieb Florian Lohoff: Ich habe da fuer mich mal ein Best common practice fuer das Autobahnzeugs gemacht - d.h. motorway_link am begin des Verzögerungsstreifens beginnend parallel fuehren etc. Nein, siehe Thread bauliche Trennung. Wo man in Realität noch lustig zwischen den Spuren hin- und her wechseln kann, darf es keine parallelen highways geben. Chris Ich habe das teilweise trotzdem gemacht, und zwar immer da, wo es mit einer einzelnen Spur nicht mehr sinnvoll editierbar gewesen wäre. Leider fehlt JOSM nach wie vor ein vernünftiges Plugin, mit dem man Spuren gestalten kann. Optimal wäre natürlich eine Lösung, in der man den kompletten Straßenzug markiert und dann für die jeweiligen Abschnitte zwischen den Krezugungen die Spuren einstellen kann. Vieles ist aber auch schlicht durch unzureichende Dokumentation unklar und schwammig. Beispielsweise ist mir völlig unklar, wie man diese Kreuzung hier according to the rules vernünftig abbilden soll: http://binged.it/11prKSr Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] F4 Map war: Re: Wochennotiz Nr. 151 4.6.-10.6.2013
Am 12.06.2013 22:59, schrieb Tobias Hobmeier: Hi hi, ich teste grade die F4 map mit FF (Aurora) 21.0. Leider verschwindet bei mir immer der Inhalt der karte sobald sie stillsteht ... man kann nur etwas sehen wenn man langsam zoomt oder scrollt ... habt ihr das gleiche problem? oder ist das ev auf meinen Graka treiber zurückzuführen. Mit FF 24.0a1 (2013-06-12) ist noch weniger zu wollen :-( Gruß Tobias Ja, bei mir funktioniert es nur in Chrome vernünftig. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eingerückte Gebäude mit Buildingtool erstellen
Am 14.06.2013 18:09, schrieb fly: Ja, vergess das building tool und benutz den internen eXtruder Modus (Tastaturkürzel: x). Leider ist dieser Modus nicht gut dokumentiert, somit heiß es ein bißchen auszuprobieren. Doppel-Klick erstellt zB einen Punkt. Grüße fly Der Extruder-Modus hat aber dann schwierigkeiten, wenn zwei Gebäude direkt aneinander sind und zueinander versetzt stehen. Dann erzeugt er nämlich ganz seltsame Wege: +---+ A | | | x| | | | B ++ | || | || +---+ C 0 D |y | || E ++ Vorgehensweise: 1 Gebäude x mit Building Tool zeichnen. 2 Punkt B setzen. 3 Bei gedrückter Alt-Taste zwischen B und C den Extruder einsetzen, um eine zweite Fläche zu erzeugen. 4 Linie zwischen C und D mit Extruder zu E ziehen. In diesem Fall reagiert der Extruder beim Schritt 4 zunächst nicht. Man muss den Schiebevorgang stets zwei mal beginnen, bis sich die Linie auch wirklich verschiebt. Beim ersten Klick passiert nichts. Ein weiterer Fehler entsteht dann, wenn man ein nebenstehendes Gebäude verkleinern will. b ++ In diesem Fall wurde Fläche B zuerst gezeichnet. Daraufhin +---+ a | wurde mit dem Extruder wieder nach links eine neue Fläche | A | B | angesetzt. Die obere und untere Kante von A wurde daraufhin +---+ c | ebenfalls mit dem Extruder nach unten gezogen. Nun kommt d ++ es allerdings zu dem Fehler, dass der geschlossene Weg von A nicht nur das Quadrat über die beiden linke Punkte sowie a und c umschließt, sondern die beiden linken Punkte wie auch (in dieser Reihenfolge) a, b, d, c. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kort Game Reloaded!
Hallo Stefan, wie oft werden denn bei Euch die Kartendaten neu eingespielt? Weil das, was ich hier vor Ort angezeigt bekomme, ist mindestens einen Monat alt. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 3D-Mapping-Plugins oder Online-Editoren?
Hallo zusammen, dank der immer besser werdenden Luftbilder und der indes sehr breit aufgestellten Nutzerbasis wird es zunehmend attraktiver, eine detaillierte Gebäudedarstellung anzustreben. Dazu gibt es ja bereits gut ausgearbeitete Schemen wie Simple 3D Buildings oder auch OSM-4D. Nun ist das Tagging allerdings oft nicht einfach, da sehr viele verschiedene Parameter gesetzt werden müssen. Die Dokus zu den Schemen im Wiki sind oft auf mehrere Seiten verteilt und im Zweifel sucht man erst fünf Minuten herum, bis ein einfaches Wohnhaus mit allen nötigen Eigenschaften versehen ist. Daher stelle ich mir die Frage, ob es in diese Richtungen bereits Bemühungen gibt, beispielsweise innerhalb von JOSM eine Art 3D-Editor zu integrieren, der den Mapper mit Vorlagen und einer Live-Vorschau unterstützt. Folgende Features wären mir dabei besonders wichtig: - Gebäude bestehend aus mehreren Teilen effektiv bearbeiten können - Farbinformationen möglichst direkt und automatisch aus Luftbildern ableiten - Materialkatalog zum einfachen Anklicken - Formular mit definierten Feldern, z.B. Gesamtgebäudehöhe, Dachhöhe (oder Wandhöhe), ... - Echtzeitvorschau Gibt es dahingegend bereits irgendwelche Lösungen, die mir entgangen sind, oder darf ich meinen Text als Handlungsaufforderung verstehen? Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Stil Fahrspur- und Straßenattribute
Am 15.03.2013 10:48, schrieb Stefan: Sehr schön. Ich denke, es ist ein super Tool um die osm-Qualität für Navis zu verbessern. Jetzt wäre es nur noch super, wenn der Stil auch mit dem graphischen TurnLanes-Generator kompatibel wäre. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fehler bei Abbiegerelation
Hallo zusammen, mir ist aufgefallen, dass das Abbiegespuren-Plugin von JOSM bei dieser Kreuzung hier aussteigt: http://osm.org/go/0DtZfEU~I-- Die Rede ist von zu vielen from-Relationen. Hat jemand eine Idee, was das sein könnte? Kann man das reparieren? Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing! Bing! Bing! Neue Luftbilder!
Am 22.11.2012 00:29, schrieb Dampfklon: Hey, danke für den Hinweis gleich mal geschaut und ich bin einfach immer wieder erstaunt... Endlich kein Pixelbrei mehr vor der Haustür ;) Dem kann ich mich nur anschließen! Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing! Bing! Bing! Neue Luftbilder!
Am 22.11.2012 00:29, schrieb Dampfklon: Hey, danke für den Hinweis gleich mal geschaut und ich bin einfach immer wieder erstaunt... Endlich kein Pixelbrei mehr vor der Haustür ;) Dem kann ich mich nur anschließen! Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Online Quality Assurance Editor
Am 04.06.2012 12:25, schrieb Adrian Stabiszewski: Ich freue mich auf euer Feedback und vielleicht den einen oder anderen Beitrag im Source code. Habe das Ganze jetzt mal zu testen versucht. Allerdings bekomme ich ständig nur Fehlermeldungen, wenn ich versuche, ein Gebiet herunter zu laden. Der Server meldet, das Gebiet sei angeblich zu groß gewesen und ich solle weite reinzoomen, was jedoch nicht geht, da ich schon maximalen Zoom gewählt habe. Vielleicht weißt Du ja, woran das liegt. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Am nächsten entfernter Punkt
Hallo zusammen, gibt es denn bereits irgendwo eine API, die ich mit einer Liste möglicher Zielpunkte und einem Startpunkt beschicke, die mir dann den Zielpunkt zurüchgibt, der streckenmäßig dem Startpunkt am Nächsten liegt? Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrspuren die 315.
Am 06.03.2012 10:14, schrieb Martin Vonwald: Solange die einzige Möglichkeit dies zu erreichen individuelle Ways sind, werden sie das machen. Wenn man ihnen die Möglichkeit gibt, das ganze einfacher zu taggen, werden sie dies tun. Der Mensch ist von Natur aus nämlich faul ;-) Es gibt doch bereits ein geeignetes Plugin für JOSM, mit dem man Abbiegespuren über Relations lösen kann. Das Plugin funktioniert graphisch und ist von hoher Bedienerfreundlichkeit. Das Problem ist wohl eher, dass die gemappten Abbiegespuren bisher nirgends dargestellt werden. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neuer OSM-Kartendienst: OpenMapSurfer
Hallo, kann man denn den transparenten Layer auch irgendwo auf einem Sat-Bild testen? Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Piratenpartei wirbt im Abgeordnetenhaus Berlin für OpenStreetMap
Hallo zusammen, der Fraktionsvorsitzende der Piratenpartei, Andreas Baum, hat heute im Berliner Abgeordnetenhaus in einer Rede OpenStreetMap beworben und kenntlich gemacht, dass er sich in Zukunft dafür einsetzen wird, dass die Website der Stadt Berlin zukünftig mit OSM-Karten arbeiten wird. http://www.youtube.com/watch?v=z48S0rh2COk (der betreffende Teil befindet sich recht weit am Ende des Videos) Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Turnlanes-Plugin
Hallo zusammen, ich bin kürzlich über das Turnlanes-Plugin gestolpert, welches ich bisher bedauerlicherweise die ganzen Monate übersehen habe. Zunächst möchte ich den Autor ausdrücklich für seine Arbeit loben. Das Programm gefällt mir außerordentlich gut, da es intuitiv zu bedienen ist und komplexe Vorgänge für den Nutzer stark vereinfacht. Mir sind jedoch zwei Dinge aufgefallen, ein Verbesserungsvorschlag und ein Fehlerbericht. Der Verbesserungsvorschlag wäre, direkt Pfeile auf die Spuren zu rendern, sodass auf den ersten Blick sichtbar wird, welche Spur für was zuständig ist. Ich spreche von solchen langgezogenen Abbiegepfeilen, wie man sie auf herkömmlichen Kreuzungen auch findet. Weiterhin ist mir aufgefallen, dass T-Kreuzungen offenbar nicht immer als Kreuzung erkannt werden. Woran das liegt weiß ich nicht genau. Vielleicht kann sich der AUtor das mal ansehen. Ich gebe auf Wunsch gerne ein paar Koordinaten weiter. Mit besten Grüßen André PS: Da wäre noch eine Sache: Separat gemappte Abbiegespuren bleiben bisher außen vor. Könnte man diese vielleicht in die Darstellung der Kreuzung übernehmen, sodass das Gesamtbild deutlicher wird? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rechtlich bedenkliche Grenzen in Berlin
Am 04.09.2011 18:09, schrieb Frederik Ramm: Ich denke, Du hast recht. Ich wuerde nicht gleich mit dem Vorschlaghammer auf den Macher losgehen - unter gestandenen Kartographen haelt sich hartnaeckig die Meinung, dass man, wenn man irgendwas irgendwo abpaust, keine Copyrightprobleme hat. Naja, der Punkt ist letztendlich der, dass der Original-Urheber keine Möglichkeit haben wird, auf irgend eine Weise einen Urheberrechtsverstoß nachzuweisen, außer die Daten sind absichtlich falsch oder fehlerbehaftet. Sind sie das nicht ist es schlicht eine Faktendokumentation. Unser OSMler könnte also genau so gut die Informationen irgendwann einmal aufgeschnappt haben, weil sie in irgend einem Buch standen. Mir scheint, dass die Grenze an einer Straße entlang verlief. Wenn ihr anderer Meinung seit müssen wir uns ernsthafte Gedanken darüber machen, wie wir in Zukunft wem auch immer erklären, woher wir diesen oder jenen Straßennamen haben. Wir hätten ein massives Problem, wenn die Aussage das weiß man halt als Ortsansässiger/Interessierter nicht mehr genügt. Das schöne an solchen Aussagen ist im Übrigen, dass man den Wahrheitsgehalt mit heutigen Mitteln nicht nachweisen kann ;) André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] My contributions to OSM shown as a heatmap
Am 16.08.2011 21:56, schrieb Pascal Neis: [...] Dabei werden sehr kleine und sehr große Changesets entfernt. Dann ergibt die Sache Sinn. Ich habe hin und wieder in meiner Gegend größere Waldgebiete abgezeichnet und die sind scheinbar durch das Raster gefallen. Außerdem habe ich mal einen ganzen Stadtteil auf einmal bearbeitet. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] My contributions to OSM shown as a heatmap
Geniale Sache! Dankeschön! Aber kann es sein, dass die Daten im Hintergrund nicht ganz akkurat sind? Teilweise fehlen da scheinbar ein paar Daten. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM auf BILD.de
Hallo, gerade bei Google News auf folgenden Artikel mit OSM-Karte gestoßen: http://www.bild.de/news/inland/freitod/verabredeten-sie-sich-im-internet-19430068.bild.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Nuklearkarte Deutschland
Am Samstag, den 02.04.2011, 14:30 +0200 schrieb Gary68: So, neu, nun mit allem, was ich gefunden habe: http://wiki.openstreetmap.org/wiki/File:MapgenGermanyNuclear.pdf Könnte man da wohl eventuell noch die Staats- und Ländergrenzen einbauen? Bisher hängt das alles etwas in der Luft. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die TileMill und die Shape-Files
Ich habe jetzt herausgefunden, dass das Problem mit dem Herauslösen der einzelnen Layer nur bei den Karten von der *Geofabrik* auftritt. Wenn ich die drei Komponentendateien aus den Cloudmade-Shapefiles löse geht es. Kann es sein, dass die Shapefiles von der Geofabrik ganz oder teilweise beschädigt sind? Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Die TileMill und die Shape-Files
Guten Abend, ich habe mir gestern erfolgreich die TileMill installiert und wollte damit auch gleich experimentieren. Da bot es sich natürlich an die freien Shapefiles von der Geofabrik und von Cloudmade zu testen. Dabei ist mir allerdings aufgefallen, dass die Tilemill nur jeweils einen Layer lädt – und zwar den mit den Straßen. Ich kann weder auf die separat gehaltenen Gebäudeumrisse, noch auf die Landuse-Eigenschaften noch auf sonst etwas zugreifen. Hat jemand eine Idee, was ich falsch mache? Ich habe die heruntergeladenen Shapefiles direkt in TileMill geladen, also keine weiteren Änderungen vorgenommen. Testweise habe ich auch ein weiteres Archiv erstellt und nur die vier Dateien eines Layers hinein kopiert; diese Dateien ließen sich dann allerdings nicht öffnen. Beste Grüße, André Reichelt ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ungemappte Straßen und Wasser im Vergleich zu Google
Am Montag, den 21.02.2011, 13:35 +0100 schrieb Stephan Knauss: sb-lis...@gmx-topmail.de writes: Hm, wenn ich mir so Köln oder Bonn anschaue, dann scheint diese Visualisierung nicht so zu funktionieren. Oh, da hat noch eine kleine Info gefehlt: Visualisierung nur für Südost-Asien. Für Europa ist es bei der guten Abdeckung in OSM nutzlos. In Asien fehlen teilweise noch die Major-Roads. Stephan Und ich habe mich schon gewundert warum die Karte auf Korea gezoomt ist und ausschließlich japanische Beschriftungen enthält. Bitte das nächste Mal den Titel eindeutig wählen um unnötige Verwirrungen zu vermeiden. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Am Dienstag, den 08.02.2011, 16:59 +0100 schrieb Henning Scholland: Da hast du natürlich auch wieder Recht. Ich dachte jetzt eher an die normalen Städte wie Prag, Warschau, Lissabon, Athen usw. Wobei die Namen aus der Nazi-Zeit egtl. nichts in OSM verloren haben. Zumindest nciht unter name:de. Wenn dann als historisches oder so. Aus der Nazizeit oder vor 1945? Viele der damaligen Namen sind auch heute noch geläufig in den jeweiligen Gegenden. Wer kann sich beispielsweise etwas unter Zelená Ruda vorstellen? Wenn ich jedoch Eisenstein sage ist jedem klar, was gemeint ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Kartenstil auf openstreetmap.de
Am Dienstag, den 08.02.2011, 23:11 +0100 schrieb Johannes Huesing: Wikipedia scheint ein ähnliches Sprachempfinden zu haben wie ich, da heißen die Lemmata Mailand und Klaipeda. So würde ich es auf einer deutschsprachigen Karte erwarten. Da gibt es auch regionale Unterschiede, auf österreichischen Straßenschildern steht Preßburg, bei der Diskussion um Stuttgart 21 heißt es hingegen Bratislava. Was hieltet ihr denn davon den lateinisch transkribierten Ortsnamen normal zu setzen und den deutschen Namen kursiv darunter zu platzieren? Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Optimierung von Zeichnungsprozessen - Reihenhäuser der besonderen Art
Am Donnerstag, den 17.02.2011, 13:41 +0100 schrieb M∡rtin Koppenhoefer: Wenn Du einen neuen Weg zeichnest, der Teil des bestehenden Buildings ist (a, 2x clicken), und dann wieder mit x in den Extrude-Modus schaltest, kannst Du direkt den eben gezeichneten Weg extrudieren. Die Selektion bleibt erhalten. Für Reihenhäuser gibt es ja schon die Funktion, das in Teile zu zerlegen. Ok, das geht natürlich auch. Durch die von mir beschriebene Methode ließe sich das ganze aber sicher noch weiter optimieren in Richtung weniger Klickerei. Vielleicht ist ja einem der Josm-Entwickler langweilig. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Optimierung von Zeichnungsprozessen - Reihenhäuser der besonderen Art
Am Sonntag, den 13.02.2011, 11:35 +0100 schrieb Steffen Wolf: Ich wuerde den Block 12-13 zeichnen, mit dem Rechtwinkeltool (x) in JOSM geht das ja schnell. Dann den zusaetzlichen gemeinsamen Punkt zwischen 13 und 14 setzen, eine Linie zum zweiten gemeinsamen Punkt ziehen, die dann mit dem Rechtwinkeltool (x) in die gewuenschte Breite ziehen. Dann nach Sueden erweitern. Wäre es denn wohl möglich, dem Extruder einen Sondermodus zu verpassen, der direkt eine neue Fläche anhängt statt die bisherige einfach nur zu erweitern? Das würde bei solchen Aufgaben viel Zeit einsparen. André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, ich sehe das Problem eher darin begründet, dass unsere Editoren nicht besonders gut für den Einsatz mehrerer Tags optimiert sind. Man müsste bei diesen Namensraumkonstruktionen mit dem Doppelpunkt dazu übergehen, mehrere Tags gleichen Namensraumes in der Software zusammenzuziehen und aufklappbar zu machen. Wenn es zu viele Tags werden kann es doch nicht ernsthaft die Lösung sein zu sagen, wir erlauben diese nicht mehr oder nur noch unter bestimmten Bedingungen. Das ist doch Käse! Als weiteren Schritt sollten wir uns überlegen eine Möglichkeit zu schaffen, bestimmte Tags komplett ausblenden zu lassen. Wer sagt denn, dass TMC-Tags überhaupt angezeigt werden müssen? Es muss ein Schalter im Optionsdialog her, mit dem man komplette Namensräume direkt wegblenden kann. Tags wie TMC dürfen auch gerne von Hause aus ausgeblendet sein, da nur die Wenigsten an diesen Tags Änderungen vornehmen werden und dann eine manuelle Aktivierung einfacher ist. Sollte ein Objekt mit versteckten Tags verändert oder gelöscht werden müsste der User über eine Warnmeldung darauf hingewiesen werden. Das ist aber, denke ich, obligatorisch. Im Übrigen sollten im selben Zuge auch direkt ein System implementieren, mit denen man als historic getaggte Objekte direkt ausblenden kann, sodass diese den Mapper nicht mehr stören. Im nächsten Schritt muss es dann auch möglich sein ganze Taggruppen auszublenden, da es im innerstädtischen Bereich mitunter schon recht unübersichtlich wird. Jedenfalls ist das Löschen der TMC-Tags für mich *keine* Lösung, zumal diese, wie ja hier mehrfach gut begründet wurde, eine außerordentliche Relevanz haben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm: Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade machen willst, kann Folgen haben, die Du nicht verstehst und die wir hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des Problems. Das wird sich aber auch nicht durch eine ID in eine externe Datenbank lösen lassen, da auch hier der User zunächst überprüfen muss, was das Tag bedeutet und wie er hier vorgehen muss. Also bringt uns auch die Geforderte ID in eine externe Datenbank keinen Schritt weiter. Außerdem haben wir bereits festgestellt, dass man von einer anderen Datenbank nicht in die OSM-Datenbank linken kann, da hier die Gefahr groß ist, dass irgendwer ein paar Nodes/Wege löscht und dadurch die externe Datenbank ständig korrigiert werden müsste. Wir stehen hier meiner Meinung nach vor einem schwerwiegenden Problem, für das wir gegenwärtig keine Lösung parat haben. Nun einfach ohne Rücksicht auf Verluste zu fordern all diese Tags wieder zu löschen wäre falsch und destruktiv. Es mag sein, dass es manchmal einfach nicht anders geht, und dann kann man mal einen Kompromiss machen, aber es sollte wenigstens klar sein, *dass* solche Tags schaedlich sind und dass man, wenn es irgend geht, an ihrer Vermeidung arbeiten sollte statt an ihrer Vermehrung. Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal ist. Wir stehen nun also an dem Punkt, an dem wir dazu angehalten sind eine *bessere* Lösung zu finden. Dieses Ziel werden wir nicht erreichen, indem wir hier in Wikipedia-Manier irgendwelchen relevanzkriterien- ähnlichen Mist veranstalten. Ich möchte das Problem noch einmal allgemein gefasst darstellen: Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden werden soll. Eine direkte Verbindung mit der OSM-ID des Objektes nicht nicht möglich, da es in der OSM-Datenbank keinen »Fertig«-Zustand gibt, der ein Löschen oder Verändern des Objektes dauerhaft ausschließt. Daher muss ein Weg gefunden werden unabhängig von zukünftigen Änderungen an der OSM-Datenbasis zuverlässig eine Verknüpfung von OSM-Daten mit einer externen Datenquelle zu gewährleisten. Ich behaupte, dass wir hier von einem komplexeren Problem sprechen, dass sich durch blinden Aktionismus nicht lösen lässt. Bevor jedoch keine zuverlässige und stabile, weniger »schädliche« Lösung gefunden ist kommt eine Löschung der TMC-Daten nicht in Frage, da dadurch die Datennutzbarkeit in erheblichem Umfang eingeschränkt wird. Gruß André *Anhang:* Meine Idee für einen Lösungsansatz Ein Lösungsansatz könnte es sein, nicht nur auf das Objekt in der OSM-DB selbst zu verweisen sondern zusätzlich auf den Revisionsstand. Auch hier könnte es allerdings zu konflikten mit zukünftigen Änderungen kommen. Von unserer Seite aus müsste bei diesem Ansatz also ein System geschaffen werden dass zwar die Datenbasis *möglichst* aktuell zur Verfügung stellt. Wird jedoch in der Dump-Abfrage ein Objekt mit Revision abgefragt muss die Blackbox in der Lage sein alle involvierten zukünftigen Änderungssätze zu ermitteln, dort eventuelle Konflikte feststellen und die betroffenen Daten vor der Ausgabe auf einen konsistenten Revisionsstand zurücksetzen. Als Zwischen-/Notlösung könnte man sich auch vorstellen, dass einfach nur eine Liste von Objekten und deren Revisionsstand an die Blackbox übergeben wird. Diese gibt dann für jedes Objekt zurück, ob es mittlerweile einen neuen Revisionsstand hat. Diese Lösung hat allerdings den Nachteil, dass ich als Betreiber der externen Datenquelle, die in OSM linkt zunächst meinen Datensatz überprüfen muss und im Konfliktfall meine Verknüpfungen zu korrigieren habe. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fehlerkorrektur in Crailsheim
Hallo zusammen, ich habe vor einigen Wochen das alte Residental-Area auf Landsat-Basis um Crailsheim herum mit mehr Details versehen und auf einen Stadtteil verkleinert. Den anderen Stadtteilen habe ich neue Areas spendiert. Aus irgend einem Grund wurde nun das veränderte Area zurückgesetzt. Könnte bitte jemand dem nachgehen und wieder die neue Version herstellen? http://www.openstreetmap.org/browse/way/39696094 Das Are sollte eigentlich z.B. unten bündig mit den Gebäuden sein. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
PS: Offenbar hat das nur wer verschoben, was man an noch nicht neu gerenderten Kacheln sehr schön sehen kann: http://www.bilder-space.de/show_img.php?img=c1bc4d-1296950851.pngsize=original Kann das jemand zurücksetzen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
Am Samstag, den 05.02.2011, 16:27 -0800 schrieb Walter Nordmann: alle Änderungen seit Januar 2010 (zweitausend-zehn) wurden von dem User AndreR gemacht. Wer könnte das wohl sein? Genau das ist ja das Seltsame an der Sache: Das Polygon wurde definitiv erst in den letzten paar Tagen oder gar Stunden verschoben (wie man zweifelsfrei an meinem Kartenausschnitt sehen kann). Gibt es denn eine Möglichkeit, Daten »um ein Changeset herum« zu manipulieren? Anders kann ich mir diesen Fehler nämlich nicht erklären. Hat jemand eine Erklärung für dieses Phänomen? Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
Am Sonntag, den 06.02.2011, 03:02 +0100 schrieb Frederik Ramm: Und die Nodes scheinen mir allesamt am Freitag um 17:25 von einem gewissen AndreR verschoben worden zu sein - mit dem Changeset-Kommentar Turn Restriction ;) Danke Euch beiden. Ich habe am Freitag mit Mapzen herumgespielt, da ich den Turn-Restrictions-Editor ausprobieren wollte. Dabei habe ich wohl versehentlich auch den Way verschoben. Kann man die Verschiebung irgendwie rückgängig machen? Oder geht es schneller, das Ding von Hand wieder hinzuschieben? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
Am Sonntag, den 06.02.2011, 04:48 +0100 schrieb Michael Bemmerl: Ich hab' deine letzte Änderung an den Nodes des landuse-ways rückgängig gemacht. Auf der (bereits neugerenderten) Karte schaut es passend aus. Vielen Dank, scheint zu passen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintragung historischer Obejkte (was: Darstellung von landuse=military in Mapnik-Karte)
Am Freitag, den 28.01.2011, 21:16 +0100 schrieb Christian H. Bruhn: Vielleicht sollte man einen Prefix für die Tags zur Beschreibung historischer Objekte verwenden. Also z.B. 'historic'. Dann hieße es nicht 'barrier=fence' sondern 'historic:barrier=fence'. Dann sollte man allerdings auch noch angeen können von wann bis wann das gegolten hat. Die Angabe historic alleine ist nicht viel Wert. War das gestern oder vor 1000 Jahren? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eintragung historischer Obejkte
Am Samstag, den 29.01.2011, 02:26 +0100 schrieb M∡rtin Koppenhoefer: Im Ernst, ein gewesenes Militärgelände interessiert schon, aber Wald war früher überall mal, das wird kaum einer machen. Ackerflächen, die es nicht mehr gibt, wird man auch selten einzeichnen. Genau so sehe ich das auch. Ob da früher ein Wald oder Feld war ist relativ irrelevant. SO etwas wird mit Sicherheit nur an ausgewählten Stellen Sinn ergeben, wo ein ehemaliges Waldstück vielleicht eine berühmte Geschichte hat (was es wiederum zu einem historischen Schauplatz macht). Hingegen ist ein ehemaliges Militärgelände, dass auch noch heute fast vollständig erhalten ist durchaus interessant zu erfassen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellung von landuse=military in Mapnik-Karte
Mir ist noch ein anderes Defizit betreffend dem Rendering von Militärarealen aufgefallen: Als aufgegeben markierte Militärareale werden dennoch rot schraffiert. Könnte das bitte behoben werden? Siehe z.B. hier: http://www.openstreetmap.org/?lat=49.13273lon=10.05143zoom=16layers=M Danke, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellung von landuse=military in Mapnik-Karte
Am Freitag, den 28.01.2011, 17:51 +0100 schrieb M∡rtin Koppenhoefer: Am 28. Januar 2011 17:41 schrieb André Reichelt andr...@online.de: Mir ist noch ein anderes Defizit betreffend dem Rendering von Militärarealen aufgefallen: Als aufgegeben markierte Militärareale werden dennoch rot schraffiert. Könnte das bitte behoben werden? Siehe z.B. hier: http://www.openstreetmap.org/?lat=49.13273lon=10.05143zoom=16layers=M Taggingfehler (oder zumindest schreit es nach Missinterpretation), das ist immer noch als Militärareal gekennzeichnet. ;-) Kannst Du das vielleicht ausformulieren? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Eine Insel im Fluss [Reparaturanfrage]
Hallo! Könnte sich bitte jemand dieser Stelle hier zuwenden: Die Inseln werden nicht gerendert obwohl ich nach meinem Kenntnisstand alles korrekt gemacht habe. Dem Flusslauf nach Norden folgend ist noch so eine Insel. http://www.openstreetmap.org/?lat=49.13586lon=10.06868zoom=17layers=M Vielen Dank! André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßen-Tags für Luftbildstraßen
Am Sonntag, den 02.01.2011, 11:04 +0100 schrieb o...@tappenbeck.net: Wie denkt Ihr darüber und wie sollten Eurer Meinung nach die Ways aus Luftbildaufnahmen gekennzeichnet werden um diese möglicht gut nutzen zu können? Ich verfahre da derzeit so, wie ich schon damals bei den Luftbildern aus der Oberpfalz vorgegangen bin: Ich versuche aus den Informationen des Bildes abzuleiten um welchen Straßentyp es sich wohl handelt und trage diesen dann ein. Bin ich mir bei einer Strecke unschlüssig wähle ich stets den am niedrigsten eingestuften Weg, der in Frage kommt. Das Vorgehen hat mehrere Vorteile: Zunächst ist die Wahrscheinlichkeit, dass eine Person über einen irrtümlich als Straße gekennzeichneten Feldweg gejagt wird recht gering. Wichtig ist aber auch, dass die Router die Leute an diese Straßen heranführen, was bei road bekanntlich aus gutem Grund nicht passiert. Dadurch fallen die Fehler vor Ort auf uns der Fehlgeleitete kann über Applikationen wie MapDust oder OSB dem Fehler zügig an uns melden. Ich habe meine Region in einem Umkreis von ca. 20 km abonniert und bessere offensichtliche Fehler dann zeitnah aus. Ich bin nun schon seit einigen Jahren dabei und die Mapperlage hier in meiner Gegend hat sich nicht gerade verbessert. Daher rechne ich auch in mittelfristiger Zukunft nicht mit einem Schwall neuer Aktiver und nehme daher alles selbst in die Hand. Ein Netz aus Roads ist verschwendete Zeit, da diese hier in der Gegend in den nächsten Monaten (und Jahren) sicherlich nicht verschwinden würden. Wenn allerdings jemand falsch navigiert wird ist die Wahrscheinlichkeit dass ein (unwahrscheinlicher) Fehler auffliegt deutlich höher. Ich denke, dass durch diese Strategie die besten Ergebnisse erzielt werden können, da die Daten einerseits sofort brauchbar sind, andererseits Fehler viel schneller auffallen. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Externe Datenbank für Gebäudemodelle (was: Image of the week - kurios - nur russische Inf ormation)
Am Mittwoch, den 22.12.2010, 09:25 +0100 schrieb Schorschi: Moin Hat jemand eine Ahnung, wie das mit den 3D-Gebäuden funktioniert, was zur Zeit im Bild der Woche angepriesen wird? Es sieht ja gut aus, aber alle weiteren Informationen scheinen nur auf russisch vorhanden zu sein. Wäre das Bild der Woche mal nur mit einer Information auf deutsch erschienen, die Reaktionen wären wohl ziemlich heftig ausgefallen ... Hallo, ich finde das Ganze ja schon spektakulär. Ich habe mir unterdessen die englischsprachige Beschreibung von diesem Jongleur durchgelesen und möchte noch meine Gedanken zu einer externen Datenbank los werden. An sich halte ich ein dreigliedriges Vorgehen für sinnvoll. Die dort vorgestellte Methode gefällt mir schon gut. Dumme renderer legen einfach alle Flächen übereinander und kommen so auf die komplette grundfläche des Gebäudes. Komplexere Renderer können diese Von-Bis-Werte verwenden um ein abstrahiertes 3D-Modell zu erzeugen. Wir sollte die einzelnen Ebenen aber auf jeden Fall in eine Relation packen um zu zeigen, dass es sich hier um ein Teil handelt. Im nächsten Schritt sollten wir aber irgendwo tatsächlich eine hauseigene Datenbank hinterlegen, in die jeder nach bekannter Manier Gebäudemodelle (auch mit Texturen) hochladen kann. Diese könnten dann beispielsweise eine ID bekommen und werden dann über die Relation (oder den Gebäudeumriss als Area, sofern keine Relation vorhanden) mit dieser ID verlinkt. Von der bisherigen Idee, die Daten einfach über einen externen Link über HTTP einzubinden halte ich sehr wenig, da hier Virenschleudern usw. Tür und Tor geöffnet wird. Außerdem kann es sein, dass personalisierte Server ausfallen oder Daten plötzlich verschwinden. Insgesamt also kein gutes Konzept für eine hohe Datenverfügbarkeit. Einzig über das Datenformat müsste sich noch der Kopf zerbrochen werden. Ich selbst bin eher für die Entwicklung eines eigenen Tools, da mir bisher kein vernünftig bedienbares quelloffenes 3D-Programm einfällt. Ich kenne nur Blender und sich darin einzuarbeiten halte ich für unzumutbar, selbst für einen OSM-Experten, da die Hürde nochmal um den Faktor Zehn höher ist als bei Josm (nach meinem Verständnis). Mir schwebt ein Programm ähnlich Google Sketchup vor. Dabei soll es irgendwo eine zentrale Texturendatenbank geben, in die man allgemeine Texturen packen kann (z.B. »verputzte Wand« oder »Holzwand« oder »U-Dachziegel«). Spezifische Texturen, welche z.B. über Photographien gewonnen wurden, sollen dann aber in dem jeweiligen Gebäudemodell gespeichert werden. Die Datenbanktexturen sollen dann über eine individuelle Färbung überblendet werden können, sodass man mit wenig Speicherverbrauch möglichst alle Standardfälle abdecken kann. Die Texturendatenbank hat den Vorteil, dass Navihersteller jene Datenbank bereits fest in die Software integrieren können. Dadurch sinkt der Datenverkehr enorm und unsere Server werden entlastet. Was haltet Ihr von der Idee? Sind natürlich nur alles grobe Skizzen, aber an sich halte ich das für den besten Weg, um vom einfachsten Renderer bis zur kompletten 3D-Umgebung alle zufriedenzustellen. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Externe Datenbank für Gebäudemodelle
Am Mittwoch, den 22.12.2010, 18:31 +0100 schrieb Tobias Knerr: In der neuen Version soll Blender etwas zugänglicher sein. Habs aber noch nicht wieder ausprobiert. Wie viel ist etwas? Bisher war das Programm ohne wochenlanges Studium irgendwelcher Fachbücher völlig unbedienbar. Selbst nach einem halben Jahr hat man noch das Gefühl gehabt, nicht angekommen zu sein. Etwas ist hier also sehr dehnbar und klingt wenig verheißungsvoll. Des Weiteren ist Blender für unsere Zwecke völlig überproportioniert und volgestopft. Wichtig ist mir, dass das Programm quelloffen ist. Dadurch fallen die meisten Möglichkeiten kostenloser Programme (wie z.B. SketchUp) bereits heraus. An brauchbarer Software bleibt nach meinem Kenntnisstand eigentlich nur der Blender übrig, bei welchen die genannten Einstiegshürden völlig unzumutbar sind (und ich übertreibe hier in keinster Weise). Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Externe Datenbank für Gebäudemodelle
Am Mittwoch, den 22.12.2010, 18:35 +0100 schrieb Peter Wendorff: Von der Idee her finde ich das gar nicht so schlecht - abgesehen, wie gesagt, von der zentralen Datenbank, bei der ich erstmal skeptisch bin. Das Ganze wird nicht meine Baustelle werden; eine Entlastung, was den Missbrauch der Multilevel Building Shapes angeht, würde ich aber begrüßen. Gruß Peter (dieser Jongleur) Hallo Peter, mir war nicht klar, wer hinter dem Spitzname steckt. Jetzt weiß ich es ;). Dass man Scripting in jenem Datenformat unterbinden kann ist natürlich wahr. Dennoch möchte ich mich als kommerzieller Verwender von OSM-Daten nicht darauf verlassen müssen, dass tausende privater Server verfügbar sind. Des weiteren wird es unzählige Mapper geben, die keinen eigenen Datenspeicher auszuweisen haben. Sind diese vom Modellieren von Gebäude ausgeschlossen oder müssen sie sich an andere Mapper mit Speicher hängen? Wer wird, wenn die ganze Sache gewachsen ist den Datendschungel noch durchblicken. Was passiert, wenn ein Server temporär über einen längeren Zeitpunkt ausfällt. Wie können Benutzer Verbesserungen der Gebäudemodelle beitragen, wenn ich doch keine Schreibrechte auf dem Quellort besitze. Das sind alles Fragen, die so eine dezentrale Speicherung mit sich bringt. Alles in allem sehe ich hier nur Probleme und keine Lösungen. Sinnvoll wäre jedoch die Überlegung, ob man nicht das Ganze weitläufiger planen sollte. Man könnte es beispielsweise ermöglichen, dass bestimmte räumlich abgegrenzte Areale oder der komplette Datenbestand auf privaten Servern gespiegelt werden kann. Unser OSM-Server würde dann auf die Anfrage nach dem Gebäudemodell XY in seiner Datenbank nachsehen, wo er das Modell finden kann und dann einen Link zum Download zurücksenden. Wichtig ist in dem Falle natürlich wieder, wie die Fremdquellen mit aktualisierten Dateiversionen umgehen. Jedenfalls hätte das Vorgehen den Vorteil, dass man einen Speicherplatzanbieter, der Schindluder treibt, sehr leicht ausschließen könnte. Trotzdem hätte man aber weniger Last am eigenen Server. Zum jetztigen Zeitpunkt halte ich jedoch Diskussionen über die angelegte Last für völlig übertrieben, da es noch keine Modelle gibt. Bis wir das an den Servern wirklich sehen würden werden sicher noch Jahre ins Land ziehen – und dann haben wir wieder ganz andere Kapazitäten. Daher bin ich eher für eine vernünftige zentrale Datenhaltung als für solch eine Fummelei mit einer unübersehbaren Zahl externer Links in der Datenbank. Nicht zuletzt sollte man natürlich auch die Datenschutzbedenken nicht vergessen, denn die Zugriffe auf jene URL können geloggt und die IPs abgeglichen werden. Da bei einer späteren Verwendung nur dort Daten geladen werden, wo man entlang fährt könnte dies zu unerwünschten Erkenntnissen führen. Man könnte aus den Datenzugriffen in Verbindung mit der IP sehr leicht ableitern wo entlang sich eine Person bewegt und noch vieles mehr. Im Übrigen finde ich die Idee, einzelne Punkte des Gebäudes an das Modell zu binden (z.B. Türen) ebenfalls toll. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] zeitweise was ausblenden
Am Samstag, den 18.12.2010, 14:47 +0100 schrieb Frederik Ramm: Weil ich das gleiche Problem hatte, gibt es seit zwei Wochen oder so bei den Darstellungs-Einstellungen auch ein Haekchen, mit dem man die Flaechenfuellung komplett abschalten kann. Kann man dem Ganzen eventuell noch einen Meüeintrag (z.B. unterhalb von »Drahtgitterdarstellung« und einen Shortcut spendieren? Danke, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Source = * - Vereinfachung der Erfassung
Am 13.12.2010 16:34, schrieb Bernd Wurst: Ich fände es sinnvoll, wenn der Editor beim Changeset automatisch Tags aufgrund der aktivierten Ebenen setzen würde, also welchen WMS ich benutzt habe oder ob ich GPS-Tracks geladen/geöffnet habe. Ich hänge den Source-Tag eigentlich nur noch an das jeweilige Changeset. Ich stimme Dir vollumfänglich zu, dass das genannte Vorgehen eigentlich nur dann sinnvoll ist, wenn man von sehr schlechtem Bildmaterial wie Landsat abzeichnet. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] josm 3695
Am 07.12.2010 16:43, schrieb Wolfgang: Hallo, bin ich eigentlich der einzige, der Probleme damit hat? Josm lädt nur noch ab und zu Daten hoch. Bricht man ab, kann man später alles manuell synchronisieren, bricht man nicht ab, kommt er nicht weiter... Gruß, Wolfgang Ich habe das Problem mit mit mehreren Versionen der letzten Tage und Wochen und offenbar hat es sich bisher nicht gebessert. Du bist also auf jeden Fall nicht alleine damit. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] josm 3695
Am 07.12.2010 19:24, schrieb SLXViper: Dann macht doch bitte einer von euch ein Ticket auf josm.openstreetmap.de auf und postet dort, wie _ihr_ es reproduzieren könnt, falls möglich, oder wann es gehäuft auftritt. Und vergesst nicht, nützliche Details wie Betriebssystem/Version, betroffene Josm-Version(en), Java-Version, etc. zu erwähnen. So lässt sich das ganze deutlich einfacher verfolgen. Das Ganze zu reprouzieren ist mir bisher noch nicht gelungen. Es scheint völlig zufällig aufzutreten und auch ein Neustart hilft nicht weiter. Ich dachte ursprünglich, die Datenbank lahmt mal wieder, aber nachdem nun offenbar nur sehr wenige dieses Problem haben macht mich das doch etwas stutzig. Ich werde mal ein Ticket aufmachen. André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Tempolimit innerorts
Hallo, ich habe hier gerade wieder eine Fehlermeldung betreffend Tempolimit innerorts 50 km/h bekommen. Soll man das denn explizit eintragen (und die innerörtlichen Straßen abtrennen) oder soll das die Software und anhand der Stadtgrenzen vorgehen? Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: Liste der bisherigen Zustimmungen veroeffentlicht
Ich hätte ja nicht im Ansatz geglaubt, dass ich so weit oben in der Liste auftauche. Das ist ja erstaunlich. 0,05 % des Datenbestandes sind also von mir… Wow! Und das ganz ohne irgendwelche Bots! Nochmals mein Appell: Ich war lange Zeit gegen die neue Lizenz, aber ich möchte auf keinen Fall, dass wir auseinanderreißen, denn davon hat keiner was. Daher habe ich auch der neuen Lizenz unterdessen zugestimmt und bitte auch alle Anderen, dies zu machen. Gruß, André signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werden Baumreihen gerendert?
Am Samstag, den 04.09.2010, 20:25 +0200 schrieb M∡rtin Koppenhoefer: Am 4. September 2010 18:51 schrieb NopMap ekkeh...@gmx.de: das magst Du so sehen. Jeder trägt das ein, was ihm wichtig vorkommt. Solange man nicht die Dinge löscht, die einem selbst nicht wichtig vorkommen, ist das kein Problem. Genau das passiert hier aber. Indem ein etabliertes Tag anders verwendet wird, werden alle vorher erfaßten Objekte, die bis zu diesem Zeitpunkt eindeutig waren, invalidiert. Das ist m.E. übertrieben, da der Zustand den Du beschreibst vermutlich nie existiert hat. Genau das ist das Problem: Der im Wiki beschriebene Zustand hat – bis auf wenige Extrema – nie existiert. Und selbst jene wenigen Ausnahmen stellten keinen großen Datenverlust dar, da aufgrund der schwammigen Formulierung nicht eindeutig ausgesagt wird, worum es sich denn nun eigentlich genau handelt. Die Formulierung spricht von einzeln stehenden ODER markanten Bäumen; Ist das nun exklusiv oder inklusiv zu verstehen? OR oder XOR, würde der Informatiker fragen. Fällt der einzelne Baum einer Allee unter diese Definition? Ab wann steht ein Baum einzeln? Welche Meterangabe ist hier relevant? Ein markanter Baum kann auch eine uralte und meterdicke Eiche mitten in einem dichten Laubwald sein, denn die Definition schreibt ja ausdrücklich nicht vor, dass beide Bedingungen erfüllt sein müssen. Ich könnte jetzt noch stundenlang auf der definition dieses Tags herumreiten und zahlreiche Beispiele aufzählen, wo nicht klar ist, ob der Tag nun gesetzt werden dürfte oder nicht – das wäre allerdings müßig. Wer nach dem obenstehenden Absatz nämlich nicht verstanden hat worauf ich hinaus will, wird es auch mit hundert weiteren Beispielen nicht kapieren (wollen). Lasst uns die Fakten analysieren: Fakt ist, dass der deutlich überwiegende Großteil der bisher getaggten Bäume NICHT der Definition entsprechen, wie sie seit Jahren im Wiki steht. Ein weiterer Fakt ist, dass der Aufbau des Tags (natural=tree) nahe legt, dass es sich schlicht um einen Baum handelt. Eine besondere Eigenschaft des Baumes oder eine Rolle als Orientierungspunkt drückt das Tag in keinster Weise aus. Weiters ist zu vermuten, dass die schwammige Definition, die bereits seit Jahren im Wiki steht, zu einer Zeit geschrieben wurde als noch niemand ernsthaft daran glaubte, dass eines Tages einzelne Bäume gemappt werden würde. Neben diesen rein strukturellen Problemen gibt es auch keinerlei technische Notwendigkeit, diese stark eingeschränkte definition beizubehalten. Orientierungsrelevante Bäume können sehr leicht mit geeigneten Zusatztags hervorgehoben werden; Diese sind nach Bedarf noch zu definieren. Eine Abstraktion ist Aufgabe der Auswertungssoftware und nicht die Aufgabe des Mappers. Dies hat schon alleine jenen Grund, dass Mapper Menschen sind und daher jedes Individuum eine andere Art der Abstraktion bevorzugen würde, weswegen die Daten mit der Zeit extrem inkonsistent werden würden. Hingegen kann ich in meinem Auswerteprogramm sehr einfach definieren, ab wann für mich der einzelne Baum im Wald zählt oder wann ich den Wald als einzelne Fläche darstellen möchte, ab welcher Zoomstufe es sinnvoll ist, die Straße flächig zu rendern und wann die Vereinfachung zu einem bloßen Linienstrang angebracht ist. Genau wie der Erfinder der Baumdefinition können wir heute überhaupt nicht abschätzen, was in zwei oder drei Jahren sein wird. Vielleicht gibt es dann wirklich eine Karte mit Zoomlevel 30 und erste Gebäude mit einem Innenplan. Spätestens dann bin ich zwingend darauf angewiesen, dass eine Straße flächig erfasst ist. Wir sollten uns nicht mit den heutigen Anforderungen beschränken und sagen, dass es für die Autonavigation irrelevant ist und daher nicht in die Datenbank gehört. Die Filterung der relevanten Informationen liegt stets beim Ersteller der Karte. Das bin aber weder ich, noch bist das Du. Wir pflegen nur eine Datenbank mit Geodaten. Die Karte wird vom Osmarender- bzw. vom Mapnik-Team und von zahlreichen Dritten bewerkstelligt; Wieder andere konvertieren das Material für die unterschiedlichsten PNA-Lösungen, die sich wiederum in Leistungsfähigkeit und Anwendungsgebiet unterscheiden. Daher ist die Abstraktion vom Konverter oder Renderer vorzunehmen, denn nur dieser kennt die genauen Spezifikationen des Anzeigegerätes und die Anforderungen. Eine Applikation für ein Mobiltelefon wird in der Regel mit der Darstellung jedes einzelnen Baumes im Wald HEUTZUTAGE überfordert sein. Ein Anderer möchte aber vielleicht den Baumbestand in einem gedruckten Katasterplan einbauen. Das Ausblenden der irrelevanten Bäume (oder anderer Objekte) auf Basis von Tags oder Algorithmen (z.B. Entfernung zum nächsten Baum, Baumdichte im Gebiet, …) ist relativ einfach, eine nicht vorhandene Information kann ich allerdings nicht aus dem Hut zaubern. Daher bin ich dafür die alte Definition möglichst bald aufzugeben und geeignete Zusatztags zu definieren um in Zukunft auch die aktuelle Definition
Re: [Talk-de] Zeichnen von Flüssen
Am Freitag, den 03.09.2010, 14:50 +0200 schrieb Fabian Schmidt: Ich habe etliche Kilometer von Bächen gemappt, die nur selten bepaddelbar sind, indem ich das Ufer abgelaufen bin. Die Tracks habe ich bewusst nicht hochgeladen, da aus dem reinen Track nicht hervorgeht, wo der Bach verläuft, auf welcher Bachseite ich mich befinde, wo das Ufer schlecht oder gar nicht zugänglich ist, wie breit der Bach ist und welche Entfernung ich vom Bach hatte. In so einem Fall sollte man dann aber unbedingt das Source-Tag sauber ausfüllen, sodass für andere Mapper erkennbar ist, woher die Daten stammen. Ohne dieses Wissen könnte man sehr leicht folgern, dass jemand das Ganze vielleicht nur grob nach Sat-Bild abgezeichnet hat oder ähnliches. Gruß, André signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werden Baumreihen gerendert?
Am Samstag, den 04.09.2010, 13:47 +0200 schrieb Peter Wendorff: [...] Ich möchte Dir vollumfänglich beipflichten! André signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Werden Baumreihen gerendert?
Am Samstag, den 04.09.2010, 04:49 -0700 schrieb NopMap: Daß es keinen Sinn macht, Tags die schon Jahre in Gebrauch sind wortwörtlich zu interpretieren, zeigt wohl am besten das verwandte natural=wood. Das komischerweise _nicht_ für jeden Wald verwendet wird. Das liegt mitunter daran, dass es in Deutschland (so gut wie) keine natürlichen Wälder gibt sondern nur vollbewirtschaftete Waldflächen. Die Diskussion gab es aber vor zwei Jahren schon einmal. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnrouting
Am Sonntag, den 29.08.2010, 19:01 +0200 schrieb Carsten Schwede: Ja, ich sehe hier den Fehler in der Karte, auch in den Garmin eigenen Karten. An der Routingsoftware in den Garmins kann man ja nun recht wenig ändern. Das ändert leider nichts an der Tatsache, dass das offenbar unvorteilhaft in der Applikation umgesetzt ist. Wir sollten uns nicht mit Workarounds für die Fehler der Softwarehersteller aufhalten sondern druck auf diese ausüben, dass jene Fehler beseitigt werden. Schlampige Programmierung ist und bleibt schlampige Programmierung. Gruß, André signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnrouting
Am Montag, den 30.08.2010, 01:03 +0200 schrieb Garry: Das klingt etwas arrogant den Herstellern hier pauschal eine schlampige Implementierung vorzuwerfen. Die implementieren das so wie es mit den von ihnen (bzw. Auftraggeber) gewählten Kartendaten funktioniert. Hier wurde bereits mehrfach angemerkt, dass dieser Fehler durchaus, wenn auch seltener, mit den Originalkarten auftritt. Daher bleibt für mich nur der einzige Schluss, dass entweder schlecht/unvorteilhaft implementiert wurde oder, dass die Verantwortlichen selbst nicht genau wissen, was sie eigentlich wollen und wo die Spezifikationen liegen. Für was anderes werden sie nicht bezahlt. Je schwieriger OSM eine Konvertierung für so ein System macht (z.B. durch zwar korrekte, aber viel zu aufwendige Relationsbeschreibungen einer Situation) um so geringer ist die Chance dass OSM-Daten auh so einem System verfügbar werden. Du darfst jedoch nicht außer Acht lassen, dass solch ein Flickwerk durchaus auch dafür sorgen kann, dass wiederum mit anderen Systemen von anderen Herstellern ein Problem auftritt, die es genau anders herum haben möchten. Beispielsweise wurde hier auch bereits angemerkt, dass es im Norden der Republik einige Autobahnen gibt, bei denen eine Aufspaltung der Wege an Abfahrten *unumgänglich* ist, da dort Umfahrungen und Ausweichstrecken einmünden. Wir stünden hier also vor der konkreten Wahl, ob wir zu Gunsten einer besseren Unterstützung der Garmin-Geräte das Tagging von Umfahrungen einschränken bzw. auslassen. Spätestens an diesem Punkt wird die Sache haarig, da wir das komplette Projekt einschränken müssten um die Funktionstüchtigkeit für einen Bruchteil der Anwendungen zu verbessern. Und spätestens wenn ein einzelner Hersteller anfängt, uns indirekt zu diktieren kann ich nur noch widersprechen. So weit darf es nicht kommen, auch wenn wir dadurch vielleicht ein paar Helfer verlieren. Gruß, André signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnrouting
Am Montag, den 30.08.2010, 00:03 +0200 schrieb Garry: Das Problem liegt nach meinen Beobachtungen weniger an den Unterbrechungen sondern am Winkel mit der eine Abfahrt abzweigt. Sonst würden ja auch auf freier Strecke dauernd Fahrtanweisungen erfolgen - dem ist aber nicht so. Wie wäre es denn mit einem Test statt vieler Worte? Wer kennt eine Stelle, an der das Problem mit dem jetzt links halten auftritt? Wer überprüft, ob dort bereits ein augenscheinlich ausreichender Abzweigewinkel vorhanden ist? Und wenn nicht, kann derjenige den Winkel zu Testzwecken erhöhen? Wer aktualisiert das Material? Wer testet die Situation erneut mit dem reparierten Material? Funktioniert es jetzt? Damit würden wir deutlich weiter kommen als mit Spekulatius… André signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ....ich bleib bei OSM !
Ich habe mich ja bekanntlich immer gegen die neue Lizenz ausgesprochen, aber mir ist das Projekt wichtiger als irgendwelches persönliches Gehabe. Daher habe ich nun beschlossen, dass ich meine Daten, falls erforderlich, auch unter der neuen Lizenz veröffentlichen werde. So lange keiner auf die Idee kommt, die Daten public domain zu veröffentlichen werde ich nicht die Spaltung des Projektes vorantreiben. Liebe Grüße André signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM für Feuerwehr
Am 28.05.2010 11:58, schrieb Ulf Lamping: c) du schützt die Daten in der OSM Datenbank gegen editieren von anderen - was aus meiner Sicht keine breite Zustimmung bei OSM finden wird (weil es letztlich dem OSM Gedanken widerspricht) Ich gehe nicht davon aus, dass dieser Widerstand eintreffen wird. Es soll ja auch kein gewähltes Gremium dieses Recht haben sondern alle Nutzer, die eine gewisse Anzahl an sinnvollen Edits gemacht haben und nicht durch Vandalismus in Erscheinung getreten sind. Des Weiteren ist es eben so, dass eine Straße nicht ständig ihren Verlauf ändert. Deshalb sehe ich ab einer bestimmten Güte keinen Sinn mehr, Änderungen vorzunehmen, da bereits alles gesagt wurde, was man sagen kann. Zusätzlich sind nachträgliche Änderungen in meinem Vorschlag bereits berücksichtigt -- diese erscheinen jedoch nicht unmittelbar sondern müssen überprüft werden. Sofern diese Änderungen die Güte der Daten erhöhen wird auch keiner die Änderung blockieren -- außer wir sind der selbe Sauhaufen, der die Wikipedia seit Jahren zerstört... Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM für Feuerwehr
Am 28.05.2010 14:16, schrieb Sven Geggus: Nun markiert man diesen als nicht verschiebbar. Nun hat aber ein Mapper seiner Gemeinde zum beispiel hochgenau referenzierte Luftbilder abgeschwatzt und kann jetzt die Straße nicht mehr verschieben, weil da ein Hydrant dranhängt. Da hast Du etwas missverstanden. Es ist nicht NICHT änderbar sondern Änderungen müssen zunächst freigeschaltet werden. Im Prinzip wird also so lange weiterhin der alte Versionsstand ausgegeben bis der neue Versionsstand von genügend anderen Mitgliedern bestätigt wurde. Dadurch behälst Du die volle Flexibilität bei, verhinderst aber aktiv Vandalismus, da solcherlei Änderungen gar nicht erst angezeigt werden. Es wird also am aktuellen Dateneingabesystem gar nichts geändert. Einzig die Ausgabe-API bekommt den Befehl, dass sie statt der aktuellsten immer nur noch die aktuellste signierte Änderung ausliefern soll. Leute, die in der Gegend wohnen bekommen dann eine Nachricht zur Verifizierung. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was kann OSM 2020?
Am 28.05.2010 23:18, schrieb Florian Gross: Ich darf mir also z.B. einfach so aus google maps einen Atlas basteln, als Quelle google maps angeben und den drucken und verkaufen? [...] Wichtiger ist mir vor allem: bei google maps und Co. sind die Daten nicht frei verfügbar. Realistische Abschätzung: Wie viele Leute basteln sich einen Atlas? Sicher, das ist ein schönes Schmankerl, aber man sollte daraus nicht das Hauptargument machen, da man damit nur eine Minderheit anspricht. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was kann OSM 2020?
Am 27.05.2010 21:54, schrieb Lothar Emmerich: Wird OSM auch eine Alternative für Google Earth? Das wird sicher nicht passieren. Wir dürfen nicht anfangen, Äpfel mit Birnen zu vergleichen. Wir haben keine Luftbilder, wir haben vektorisiertes Kartenmaterial. Ob wir eine Konkurrenz zu Google Maps werden -- ich weiss nicht. Aber zu Earth werden wir es bestimmt nicht; höchstens unser Partnerprojekt OAM. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was kann OSM 2020?
Am 28.05.2010 00:59, schrieb Bernhard Zwischenbrugger: Wirklich interessant sind doch erst die Dinge die anderswo nicht vorhanden sind. Das sehe ich mittlerweile genauso. Wir sollten uns in Zukunft nicht mehr auf die Fahne schreiben, wie Google, nur kostenlos zu sein sondern wir sollten anfangen die Dinge zu betonen, die man mit Google und Konsorten nicht machen kann. Dabei müssen wir scharf unterscheiden zwischen Geschäftskunden und Privatleuten, denn die wenigsten Normalverbraucher werden daran interessiert sein, eigene Karten zu rendern. Für diese steht die Nutzung im Vordergrund. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM für Feuerwehr
Am 28.05.2010 03:17, schrieb Peter Körner: Am 28.05.2010 03:02, schrieb Tirkon: Das Modell eäre eines, das OSM über den privaten Bereich sinnvoll nutzbar machen würde. Gefallen tut's mir nicht aber ich sehe das Problem und auch keine schönere Lösung. Fraglich ist nur, ob Rails-Port, JOSM Co. die richtigen Werkzeuge für diese Anwendung sind. Die Idee stößt auch mir bitter auf, da dies eigentlich der Idee widerstößt. Benutzergruppen und Wiki passen nicht wirklich zusammen. Das Ganze wird ja eben erst deshalb gut, WEIL alle mitmachen dürfen. Ich kann die Bedenken natürlich verstehen. Allerdings hat die Holzhammermethode noch nie funktioniert. Man sollte vielmehr einen Weg finden, wir man in Zukunft bestimmte Fakten schlicht festnageln kann. Ich stelle mir das dementsprechend vor, dass man Objekte verifizieren kann und wenn eine bestimmte Anzahl an Leuten das Ding als korrekt und vollständig markiert haben wird es für Änderungen blockiert. Falls dennoch etwas zu ändern ist (Baustelle usw.), dann landet dies nur in einem Freischaltungsmodus. Die Änderungen erscheinen dann erst auf der Karte, wenn diese von einer bestimmten Zahl an qualifizierten Nutzern genehmigt wurden. Im Prinzip also eine Adaption des kürzlich in der Wikipedia eingeführten Sichtersystems. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nutzt Google (auch) die Daten von OSM?
Am 06.05.2010 08:23, schrieb Andre Joost: Wie wärs mit ner Guhgel-Strasse? Das kann man gerne mal machen. Sollte natürlich hier vorher (OHNE Link) angekündigt werden und nur mit leicht verfälschtem Namen. Wer weiss, ob die nicht hier mitlesen. Vor allen Dingen sollte man es aber auf das Gebiet beschränken, in dem die Kopiervorwürfe stehen. Sofern das wirklich der Wahrheit entsprechen sollte müsste man mal bei Google die Rechtsabteilung konsultieren und darauf hinweisen, dass sie von irgendeinem Subunternehmer OSM-Daten bekommen und diese nicht hinreichend kennzeichnen. Dann können zwei Dinge passieren: Die Daten verschwinden oder unten erscheint auf der Karte Datenquelle: OpenStreetMap. Letzteres wäre in meinen Augen ein genialer Erfolg. Aber wir sollten der Sache ernsthaft mal nachgehen. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Arbeitsmatrix Dortmund
Am 05.05.2010 09:11, schrieb Dietmar: Die Dortmunder wollen jetzt eine eigene Matrix erstellen, da war mal was geplant gewesen und dann angehalen worden. Nächste Woche soll evtl. was verfügbar sein. Grüße Dietmar Wie ist denn der Stand? Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Frankfurt gestalten
Hallo, ist der Link eigentlich bekannt: http://frankfurt-gestalten.de/ Da wird OSM eingesetzt. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnübergang in Schilda?
Am 25.04.2010 23:33, schrieb Johann H. Addicks: Was ist das? Hm, vermutlich war das früher mal eine Ausfahrt eines verkehrsberuhigten Bereiches, der dann später dicht gemacht wurde, da die Sanierung der Überfahrt zu teuer gewesen wäre. Der Poller in der Mitte deutet das irgendwie an, dass man da nicht rein-/rauspräscht. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
Am 25.04.2010 13:00, schrieb Frederik Ramm: [...] Hallo, ich habe die anderen Beiträge nicht gelesen, kann mich aber Deiner Meinung nur anschließen: Die Wikipedia ist verkommen zu einem Haufen weniger Machthaber, die völlig undurchschaubar Regeln vordiktieren. Die bürokratischen Strukturen sind längst nichtmehr durchschaubar und die Admins handeln meistens nach gutdünken. Dies können sie, da sie nur von den 0,5% gewählt werden, die eh ihrer Meinung sind -- die Anderen umgehen die Wahlen, da sie berechtigt alleine sowieso nichts ändern könnten. Da müsste schon ein Sturm, eine Art Revolution losbrechen. Ich werde mit Kräften daran arbeiten, dass so etwas bei uns nicht passieren wird. Wir müssen alle wachsam sein und rechtzeitig gegensteuern, wenn wir merken, dass wir in eine Sackgasse laufen, wie dies mit der Wikipedia geschehen ist. Und ich sage das als aktiver Autor, der schon seit einer vierstelligen Anzahl an Tagen dabei ist. Richtig ist, dass wir auf Dauer nicht ohne Regeln klar kommen werden. Es ist jedoch um jeden Preis zu verhindern, dass sich eines Tages ein Gremium bilden wird, dass einen Alleinstellungsanspruch darauf hat, irgendwelche verbindlichen Regeln vorzuschreiben. So etwas wird wie bei der Wikipedia zwangsläufig in der Katastrophe enden. Ein weiteres Problem der Wikipedia ist es, dass die Werkzeuge zu einer Zeit geschaffen wurden, zu der das Projekt noch in den Kinderschuhen steckte. Seither liegt die Entwicklung der Werkzeuge brach! Wie sonst erklärt sich, dass seit fünf Jahren immer der selbe Editor im Einsatz ist -- unverändert. Ich als alter Hase habe keine Probleme mit mehrfach verschaltelten Vorlagen und rießigen Tabellen, dem Anfänger bricht das jedoch das Genick. Wir haben wie die Wikipedia eine gewisse Manpower zu verteilen. Diese fließt dort, wie richtig angemerkt, zu rund 90% in die Verwaltung eines Bürokratiemonsters. Unser Ziel muss es sein, die Kraft zu dritteln. Ein Teil muss in der Diskussion landen: Damit meine ich ausdrücklich nicht sinnlose Diskussionen zu Themen bei denen von vorn herein feststeht, dass die Diskussion ins Leere laufen wird; ich spreche von Diskussionen, wie man Neuerungen am Besten einsetzt, was man an den Werkzeugen verbessern kann und ähnliche Punkte. Natürlich zählt auch die Diskussion auf OSB dazu. Ein weiteres Drittel muss in die konsequente Entwicklung der Datenbasis fließen. Dazu zählt natürlich auch die Meldung von Fehlern bei OSB. Das letzte Drittel ist das Wichtigste: Die konsequente Verbesserung der Werkzeuge. Es darf nicht passieren, dass sich die Stammnutzerschaft bewusst oder unbewusst von den neuen Nutzern abkapselt, indem sie absichtlich oder unabsichtlich die Werkzeuge so unbedienbar gestaltet, dass neue Nutze mit diesen nichts mehr anfangen können. Wir als alte Hasen müssen uns immer wieder an die eigene Nase packen -- immer wieder schauen, dass die Tools bedienbar bleiben -- uns immer wieder in die Lage eines Neulinges versetzen. Die Vergangenheit hat gezeigt, dass wir es besser machen als die Wikipedia. In meinen Augen sind wir aber noch weit vom Perfekt entfernt. So ist die Bedienung durch das Aufblühen der Relations deutlich komplizierter geworden. Eine grafische Oberfläche zu deren Erzeugung fehlt jedoch bis auf wenige Presets noch gänzlich. Auch im Wiki gibt es immer wieder zu tun. Wir müssen die Informationen noch auffindbarer gestalten! Ich halte ein Regelwerk wie die Mapfeatures für unumgänglich! Allerdings dürfen wir uns nicht von den Wikipedianern verführen lassen, diese zu unserer Bibel zu erklären. Die Mapfeatures müssen das bleiben, was sie gerade sind: Der kleinste gemeinsame Nenner. Dadurch tun sie niemandem Weh und trotzdem habe ich die Möglichkeit, mir neue Dinge auszudenken. Wenn wir jedoch dazu übergehen würden zu sagen, nur was in den Mapfeatures steht darf gemappt werden, alles andere wird wieder entfernt, dann meine Freunde, dann würden wir in den selben bodenlosen Abgrund fallen wie die Wikipedia es langsam aber sicher immer schneller tut. In diesem Sinne, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karten in Wikipedia
Am 03.04.2010 12:33, schrieb Kai Krueger: Die Hike Bike map ( http://hikebikemap.de/ ) Die scheint wohl bei Detailzooms größere Probleme zu haben. Das Abrendern der fehlenden Teils dauert teils zwanzig Minuten. Ist das beabsichtigt? Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 01.04.2010 04:22, schrieb Matthias Versen: 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. Du kannst bei Vektoren allerdings nur Punktförmige Verbindungen ausdrücken. Das hilft dir etwas bei einfachen Kreuzungen, bei Einfädelspuren oder komplexeren Kreuzungsbildern ist der Ofen allerdings ganz schnell aus. Sicher, man kann Anfang und Ende verbinden und dann mittels komplizierter Relations beschreiben, dass in diesem Gebiet ein stufenloser Spurwechsel möglich ist. Allerdings liese sich dieser Umstand mit einer Fläche um Längen intuitiver, schneller und und sichtbarer verdeutlichen. Deshalb plädiere ich auf längere Sicht darauf, Vektoren nur noch da einzusetzen, wo sie wirklich sinnvoll sind und anderweitig auf Flächen und Splines aufzuwerten. Vektoren sind nach wie vor unschlagbar bei Überlandleitungen, bei denen die primitiven Möglichkeiten eines Vektors ausreichen. Der Vektor kann auch zur Beschreibung von Flächengrenzen hergezogen werden, sofern man noch keine Kurvenobjekte hat oder wenn die Strecke exakt gerade ist. Allerdings ist und bleibt der Vektor nach dem Punkt unser primitivstes Beschreibungsmedium, der in der Regel nur näherungsweise arbeiten kann. Ich will hier aber keine linienförmige Annäherung sondern eine Darstellung der Realität. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 01.04.2010 08:22, schrieb Guenther Meyer: natuerlich geht das. mit einer flaeche kannst du sowas nicht machen... Das Gegenteil ist der Fall. Und trotz dass Du es offensichtlich nicht für nötig hältst, irgendwelche Beweise für Deine Theorie anzuführen möchte ich im Sinne der Netiquette und des guten Tones auch erläutern, warum es mit einer Fläche funktioniert: Nehmen wir als Beispiel die Einfädelspur einer beliebigen Autobahnauffahrt. Um diese zu beschreiben müsste ich unter Verwendung von *Vektoren* zunächst zwei Spuren parallel zeichnen: Die Autobahnspur sowie die Beschleunigungsspur. Dann muss ich über abstrakte Elemente (Relation) beschreiben, in welchem Stück eine Überfahrt möglich ist. Sofern die Übergangsflächen rechteckig sind, geht das einfach. Spätestens wenn ich allerdings wie auf der Autobahn S-Kurven habe, muss ich über zusätzliche Vektoren beschreiben, wie die Ränder der Auffahrspur genau verlaufen. Des weiteren muss ich über ein Regelwerk festlegen, ob denn nun der Startpunkt des Auffahrspurenvektors die Straßenmitte widerspiegelt oder ob wir uns auf der Linie befinden. Wenn wir in der Mitte sind muss außerdem der Abstand zum Rand bekannt sein, den man über die abstrakte Angabe der Breite nur schwer abstrahieren kann. Bei einer *Fläche* hingegen habe ich ein sichtbares, für den Menschen intuitives Abbild der Wirklichkeit. Eine Festlegung von Regeln ist nicht notwendig, da sich alle Regeln aus der Abbildung ergeben, und auch ohne Fachwissen über das Datenformat kann Jedermann sofort erkennen, was gemeint ist. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 01.04.2010 12:31, schrieb qbert biker: Warum? Rinksbuendige Referenz + Spurbreite + Spuranzahl + Uebergangsbeschreibung (z.B. Aufweitung auf 100m Laenge) und das Ding ist sauber beschrieben. Wenn es immer so einfach wäre. Jedoch geschieht der Übergang zwische verschiebenden Straßenbreiten nicht schlagartig. Dementsprechend müsste ich die Breitenzunahme komplex als Funktion beschreiben, um exakt zu sein. Um dies zu tun muss ich nicht nur Mathematik studieren sondern auch noch diverse Regeln festlegen, um aus der abstrakten Beschreibung ein genaues Bild zu rekonstruieren. 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. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 01.04.2010 12:58, schrieb Robert S.: 2010/4/1 qbert biker qbe...@gmx.de mailto:qbe...@gmx.de Warum? Rinksbuendige Referenz + Spurbreite + Spuranzahl + Uebergangsbeschreibung (z.B. Aufweitung auf 100m Laenge) und das Ding ist sauber beschrieben. Ach, und das soll dann ernsthaft EINFACHER zu erfassen sein als das einfache Nachzeichnen einer Fläche anhand von hochauflösenden Luftbildern? +1 André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kamerabilder auswerten
Am 25.03.2010 11:36, schrieb Fabian: PS hier [1] ein beispiel fuer dein vorhaben. IMHO sind da sehr viele unnuetze bilder bei. [1] http://openstreetview.org/?lat=51.545187436765lon=8.4299039837353zoom=11 Kann man sich die Bilder eigentlich vergrößern? Draufklicken geht nicht. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kamerabilder auswerten
Am 26.03.2010 15:58, schrieb Martin Koppenhoefer: Anzahl der Fahrspuren kann man sich gerade noch vorstellen, aber Brücken? Die erkennt man auf der Autobahn ja oft nichtmal (wenn man die entspr. Schilder nicht hätte) als menschl. Autofahrer, der von höher und nach vorne raus blickt. Schilder hat man mit der Rückfahrcamera immer nur von hinten oder der Gegenseite, richtig? Doch, Du wirst sie im Videofilm in beide Fahrtrichtungen erkennen. Merkenswerte Brücken sind grundsätzlich beweglich gelagert und haben deshalb an beiden Enden Gitterroste, die je nach Brückenlänge und aktueller Position durchaus auch mal zwei Meter lang sein können. Man beachtet diese während der Fahrt zwar nicht, aber im Film würde man sie sehen und könnte so metergenau die Position bestimmen. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 22.03.2010 17:40, schrieb olvagor: 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. Das sehe ich auch so und habe das auch schon vor zweieinhalb Jahren so kundgetan. Aktuell ist es leider noch notwendig, Flächen und Wege getrennt zu erfassen. Früher oder später muss diese Tätigkeit der Erzeugung einer Mittellinie jedoch von den Konvertern übernommen werden, sofern der Router keine flächigen Straßen unterstützt. Wir haben im Prinzip noch nicht damit begonnen, weil es noch keine Daten gab, die genau genug waren. Dank der Luftbilder von Aerowest können wir nun aber zum ersten Mal metergenaue Abbilder der realen Straße erzeugen. Wir sollten das auch nutzen. Jedoch, ich sage es nochmals, bleibt auf einer separaten ebene und verwurstet es nicht mit den normalen Wegen. Verwendet wie gewohnt einen Vektor für die Straße und legt eine Fläche drum herum. Der Vektor kann später leicht automatisch gelöscht werden, sobald genügend Anwendersoftware flächige Straßen unterstützt. Aber grundsätzlich eine sehr förderliche Tätigkeit, das Pilotprojekt zu nutzen, um unsere eigenen Modelle weiterzuentwickeln. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 22.03.2010 19:26, schrieb Martin Koppenhoefer: Am 22. März 2010 17:53 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: olvagor schrieb: Ich denke, ich werde das über nen eigenen Namespace lösen. +1 Vielleicht einfach area:highway=residential area:highway=footway ich fände highway_area=residential schöner, aber egal, ist ja syntaktisch äquivalent. ;-) wie wärs mit landuse=highway ? Ist kürzer und entspricht z.B. landuse=railway. Wozu man da zwischen residential, unclassified etc. unterscheiden sollte, ist mir allerdings unklar, m.E. reicht ein landuse=highway für alle Straßen. Die beiden oberen Vorschläge gefallen mir sehr gut. Bedenken habe ich mit Deinem Vorschlag, Martin. Das Landuse für die Bahn wurde nicht aus dem Grund eingeführt, Strecken flächig zu mappen (was im Übrigen auch schwachsinnig wäre, da diese grundsätzlich ein Vektor bzw. Spline mit einer festen Breite von 1440mm sind). Ziel war es viel mehr, die von der Bahn genutzte Fläche zu kennzeichnen. Das ist beispielsweise Bahngelände oder brachliegende Landfläche zwischen den Gleisen eines Güterbahnhofs. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 22.03.2010 20:13, schrieb Guenther Meyer: und wie waers mit der einfachen abstraktion, strassen als linie zu mappen, und die breite als attribut anzugeben? Das entspricht nicht dem, was hier bezweckt werden soll: Die Erstellung einer WeltKARTE. Für mich ist das in erster Linie ein vektorisiertes Luftbild. Das schließt implizit auch flächige Straßenkörper mit ein (zumal Diese entgegen der öffentlichen Wahrnehmung entlang der Strecke doch sehr stark variieren kann). Navigationssysteme aller Art sind nur ein Anwendungsgebiet unserer Karten. Wenn ich allerdings die B999 in meinen Fahrsimulator einbinden möchte, genügt mir ein Vektor mit statischer Breite definitiv nicht. Gerade auf Bundesstraßen wird beispielsweise in Kurven die Straßenbreite häufig erhöht, um das Kurvenschneiden zu verhindern. Ich kann mir durchaus auch vorstellen, dass wir eines Tages auch einzelne Bäume in der Landschaft oder am Straßenrand erfassen werden (was schließlich an so mancher Stelle bereits getan wird). Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 22.03.2010 21:14, schrieb Torsten Leistikow: Oder geht es nicht viel mehr darum, dass man die Wirklichkeit abstrahiert und einzelne Objekte entsprechend ihrer Funktion beschreibt. Die Abstraktion der Daten ist ein zweiter Schritt, den man nicht mit dem Mappen vermischen darf! Der Grad der benötigten Abstraktion hängt vollständig von der Anwendung ab. Für eine Deutschlandkarte aller Autobahnen zum Ausdrucken auf A4 brauche ich eine deutlich geringere Präzision als wenn ich einen Plan des örtlichen Marktplatzes brauche, auf dem ich Marktstände vermerken will. Ich habe das Gefühl, einige hier haben noch nicht genau verstanden, worin das eigentliche Ziel unserer Datenbank besteht: Ein möglichst hoher Detailgrad. Welche und wie viele Details ich für meine Anwendung brauche ist dann eine andere Frage. Wir erstellen aber _ausdrücklich_nicht_ eine Datenbank für Garmin und Skobbler sondern eine freie Wiki-Weltkarte. Jedes Anwendersystem muss daher in der Lage sein, selbst eine Abstraktion herzustellen. Dies kann natürlich und ausdrücklich auch dadurch geschehen, dass wir das Projekt OpenRoutingMap starten und dort eine Kopie der aktuellen Daten einspielen und diese speziell auf die Bedürfnisse von Routern ausrichten. Jedoch dürfen wir uns _nicht_ dazu verleiten lassen, dass wir aufgrund des derzeitigen Hauptanwendungsgebietes (Routing) unsere Karte in diese Richtung trimmen. Dies würde dazu führen, dass wir alle anderen Anwendungsbeispiele behindern oder ausschließen würden -- und das darf nicht unser Ziel sein! Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 26.03.2010 15:16, schrieb Chris-Hein Lunkhusen: Für mich persönlich sind routingfähige Karten das wichtigste Produkt für OSM, deshalb bekomme ich immer Bauchschmerzen wenn ich diese Vermischung von Fläche und Vektor sehe. Entschuldigung wenn ich mich wiederhole, aber ein paar Schreiber dieser Liste, Du eingeschlossen, haben sich in eine extrem einseitige Polemik verrannt. OpenStreetMap ist eben _keine_ Karte für Router sondern eine freie Wiki-Weltkarte. Man darf sich nicht auf Router beschränken. Ziel muss es viel mehr sein, mehrere Abstraktionsebenen zu schaffen: Zunächst die Hauptkarte (Datenebene) mit allen Daten darauf (u.A. auch Gullydeckel) und dann mehrere abstrahierte Unterebenen, von denen eine speziell für Router für Kraftfahrzeuge vorgesehen ist. In der Datenebene sind Straßen, sofern möglich, grundsätzlich flächig zu erfassen. Erst in der Abstraktionsebene für Kraftfahrzeugnavigationsgeräte ist die Fläche durch einen Vektor zu ersetzen, solange wir noch keine Router haben, die auf neuronalen Netzen basieren. Ich möchte unseren alten Leitsatz etwas aufpoliert ins Gedächtnis rufen: Wir mappen nicht nur(!) für Navigationssysteme. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 30.03.2010 10:57, schrieb qbert biker: Ich frage mich z.B. bei diesen Diskussionen immer, warum keiner Kreissegmente fordert, denn einen Bogen in einzelne Segmente aufzuloesen, ist auch ungenau. Das habe ich bereits vor zwei Jahren ;). Allerdings hat die Diskussion damit geendet, dass wir bisher keine Ausgangsdaten haben, die das rechtfertigen würden. Bei einem GPS-Signal kann ich genaue Kurvenverläufe nur abschätzen. Die Sache wird dementsprechend erst jetzt dank Aerowest wieder akut, da uns _erstmals_ Bilder in einem solchen Detailgrad zur Verfügung stehen, dass man ernsthaft über echte Kurvenobjekte nachdenken kann. Jetzt ist die Stunde der Entwickler und Tüftler, die eine saubere Implementierung anbieten können. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 25.03.2010 10:45, schrieb Sven Geggus: Dann darfst Du schon mal Sponsoren für einen Server mit 200Terrabyte Plattenplatz suchen. Das ist das geringste Problem. Speicher kostet heute so gut wie gar nichts mehr. Im Übrigen neigst Du hier zur Übertreibung, da sich die Datensammelgeschwindigkeit nicht merklich erhöhen wird. Wenn jedoch eines Tages tatsächlich ein solch großer Server nötig wäre, würde ich mich selbstverständlich daran mit Spenden beteiligen. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 31.03.2010 20:35, schrieb Bernd Wurst: Ich glaube er meint die Speicherkapazität für die Luftbilder. :) Die müssen wir erstmal bekommen. Und selbst wenn Aerowest Bilder von ganz Deutschland zur Verfügung stellen würde, könnten wir diese in Etappen abarbeiten. Gruß, André PS: Steht eigentlich die Arbeitsmatrix unterdessen? signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 31.03.2010 19:21, schrieb Chris-Hein Lunkhusen: Am 31.03.2010 18:51, schrieb André Reichelt: In der Datenebene sind Straßen, sofern möglich, grundsätzlich flächig zu erfassen. Und der Algorythmus soll die Mittellinie zB. eines Kreises wie berechnen? ;-) Genau deshalb eine separate Ebene, die die Mittellinien enthält auf lange Sicht. Bis das klappt, kann man ja beide parallel auf die selbe Ebene packen und die Fkächen, wie bereits vorgeschlagen, mit einem Präfix versehen. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Details mappen in Dortmund
Am 31.03.2010 20:08, schrieb Guenther Meyer: strassen sind erstmal lineare gebilde, die lassen sich wunderbar als vektoren mit entsprechenden attributen abbilden, inkl. allem was noetig ist. 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. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aerowest-Luftbilder von Dortmund jetzt v erfügbar
Direkt die Frage, ob es denn schon eine Arbeitsmatrix gibt. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mapzen!?
Hallo, bin gerade bei CloudMade über ein Tool namens Mapzen gestoßen. Weiss da jemand etwas Näheres zu? Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapzen!?
Am 08.03.2010 19:50, schrieb Frederik Ramm: Ist alles im Wiki dokumentiert. [...] Mir ging es auch eher um Erfahrungen damit und einen kleinen Vergleich zu JOSM und Potlach. Optisch sieht das Ganze ja recht ansprechend aus. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapzen!?
Am 09.03.2010 00:05, schrieb Nick Black: Hi André, Hey! I hope you don't mind me answering in English - my German is non existant. No problem... I'm definitely not the best English speaker, but I'll try my best ;). I'm glad you have found Mapzen and have been enjoying it so far. The idea of Mapzen is to provide an easy, fun to use map editor for people who are new to OpenStreetMap. It was released in its current Beta form in November 2009 and has been developed since then. You can read more about the latest release of Mapzen including the roadmap here: http://blog.cloudmade.com/2010/02/20/mapzen-updates-and-sneak-preview-of-the-next-release/ Ah, ok. Thank you so far. My question was if it's a professional tool or if it's better for beginners. The UI quiet impressed me and it seems to be very intuitive, so I asked myself as advanced user if I should use it in the future. I saw this screenshot of the turn restrictions editor and it looked very usable to me. My first impression: Let's keep that piece of software in your viewport. Therefore I asked for some kind of a comparison between JOSM, Potlach and Mapzen. I'll try it in any case if I find some free minutes. If you need some tips (in English only for now, I'm afraid) there are some CloudMade people using Mapzen who can help: Thea - http://mapzen.cloudmade.com/user/149327783 Me (Nick) - http://mapzen.cloudmade.com/user/654502734 Yuliya - http://mapzen.cloudmade.com/user/106573939 Ok, I'll keep those persons in my mind. Thank you. Best regards, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ORS mit Trojaner?!
Hallo, liegt das an mir, oder ist da was faul? Wenn ich auf ORS gehe, meldet avast! einen Trojaner und trennt die Verbindung. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am 13.02.2010 22:22, schrieb Andreas Neumann: http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=-25.4,35.3,48.1,71.7]) Selbst bei nem winzigen Bereich wie http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=9.99,10.0,49.0,49.01] Lädt der mir 100 MB Daten runter. Was mache ich falsch? Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am 14.02.2010 21:38, schrieb Carsten Gerlach: Nabend, Am Sonntag 14. Februar 2010 21:27:09 schrieb André Reichelt: http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=9.99,10.0,49.0 ,49.01] Syntax beachten! [bbox=west,süd,ost,nord] So? Habs direkt aus JOSM rauskopiert (oben-links, unten-links, oben-rechts, unten-rechts). http://www.informationfreeway.org/api/0.6/*[railway=*][bbox=49.05407025156395,49.19067925930702,9.6514892578125,10.15411376953125] Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am 14.02.2010 23:37, schrieb Carsten Gerlach: Am Sonntag 14. Februar 2010 22:42:26 schrieb André Reichelt: Syntax beachten! [bbox=west,süd,ost,nord] So? Habs direkt aus JOSM rauskopiert (oben-links, unten-links, oben-rechts, unten-rechts). Vielleicht reden wir aneinander vorbei. Deine Angabe oben-links wäre ja schon eine Koordinatenangabe ala 47,11 Außerdem hast du oben und links usw. je zwei mal drin. Damit war die Reihenfolge im Fenster Koordinaten in JOSM gemeint. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] KML-Export
Am 14.02.2010 23:37, schrieb Carsten Gerlach: Probier mal http://www.informationfreeway.org/api/0.6/*[railway=*] [bbox=6.85067,51.47437,6.85271,51.47544] (Oberhausen HBF). Klappt das so jetzt? Prima, hat wunderbar funktioniert. Danke! Wie mache ich das denn nun in GPS-Babel? Einfaches konveriteren klappt schon, aber kann ich da Stile anhand der Tags einstellen? Also dass Bahnübergänge ein bestimmtes Symbol bekommen usw. Oder das Strecken eine bestimmte Farbe bekommen. Gruß und Danke, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] KML-Export
Hallo, gibt es denn bereits eine Möglichkeit, bestimmte Ways oder Nodes als KML bzw. KMZ zu exportieren? Hintergrund meiner Anfrage ist, dass ich jemanden kenne, der umfangreiche Bahndaten sammelt. Bisher taggt er die an selbstgeklickte Strecken an Google-Earth. Das Klicken kostet allerdings unglaublich Zeit. Er hat mich nun gefragt, ob ich ihm nicht einen KML-Export des gesamten europäischen Streckennetzes geben könnte. Er würde uns im Gegenzug sämtliche seiner Daten zur Verfügung stellen. Diese enthalten Infos über die Anzahl paralleler Gleise, den Stand der Elektrifizierung sowie Infos, ob die Strecke bereits aufgegeben oder gar zurückgebaut wurde. Die Daten hat er hauptsächlich aus alten Kursbüchern sowie Bekanntmachungen der Bahn zusammengesucht. Es wäre schön, wenn es hier zur Kooperation kommen könnte. Gruß, André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de